Nyt kun tutkimuksesta löytyneet konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat on tunnistettu – voidaan lähteä tutkimaan löydettäisiinkö jotain kehitysideoita, joilla riskienhallintaa saataisiin parannettua konfiguraationhallinnan avulla. Aloitetaan tarkastelemalla sekä konfiguraationhallinnan että riskienhallinnan kehitysideoiden ristiintaulokoituja tuloksia (Taulukko 14), jotta löytäisimme kehitysideoita, jotka ristileikkaisivat toistensa kanssa.
Taulukko 14. Kehitysideoiden yhtäläisyyksien tutkimista.
Riskienhallinnan kehitysideat Konfiguraationhallinnan kehitysideat Riskienhallinnan tulisi ottaa
konfiguraationhallinta mukaan riskienhallintaprosessiin.
CMDB:n ja konfiguraationhallinnan käyttöä tulisi laajentaa muiden liiketoiminnan osa-alueiden tukemiseksi.
Toiminnan jatkuvuussuunnitelmia ja järjestelmien kriittyksien kartoittamista tulisi kehittää.
Savon Voima Oyj:n pitäisi luoda oma liiketoimintatason CMDB, jossa kuvattaisiin prosessien ja IT-ympäristön yhteys. Tarkemmat kuvaukset löytyisivät IT-palvelutarjoajalta.
Kuten huomaamme, näiden kahden IT-palvelunhallinnan prosessien eniten samoja haasteita käsittelevät, eniten kaivatut kehitysideat leikkaavat toisiaan varsin hyvin.
Riskinhallinnan tarve konfiguraationhallinnan mukaanottamisesta
71
riskienhallintaprosessin parantamiseksi korreloi hyvin CMDB:n ja konfiguraationhallinnan käytön laajentumisesta liiketoiminnan osa-aluiden tukemiseksi. Sama pätee riskinhallinnan tarvetta kehittää liiketoiminnan jatkuvuussuunnitelmia ja tehdä IT-järjestelmille kriittisyyksien kartoituksia. Täten tunnistamme kaksi prosessia, joilla konfiguraationhallinta voisi auttaa riskienhallintaa:
1) Liiketoimintaprosessien ja IT-ympäristöjen yhteiskartoitus.
2) Liiketoimintatason CMDB:n luominen, jossa olisi kaikki palvelut ja prosessit kuvattu suhteessa järjestelmiin. IT-palveluntarjoaja A:n CMDB:stä säilytettäisiin tarkempia kuvauksia.
Prosessien ja IT-ympäristöjen yhteiskartoittamiseen tutkija ehdottaa jokaiselle liiketoiminnan osa-alueelle IT-osastojen kanssa yhteistyön tekemistä, jotta jokaiselle prosessille pystyttäisiin tunnistamaan kaikki siihen liittyvät järjestelmät, komponentit, palvelimet ja kaikki IT-infrastruktuuria käsittävät osat, josta kyseinen prosessi koostuu ja johon se liittyy. Täten voidaan tehdä yksityiskohtainen prosessikaavio, johon sisältyy kaikki IT-elementit ja niistä koostuvat riskit, euromäärät niiden toteutuessaan ja riskien hallintakeinot. Alla on kuvattu Savon Voima Oyj:n nykyinen riskien arviointiprosessi (Kuva 16).
Kuva 16. Nykyinen riskiarviomalli (Savon Voima, 2018c, mukaillen)
72
Kuvasta voimme havainnoida, että riskienhallinta on määrittänyt organisaatiolle tärkeiden prosessien riskit ja riskiarviot ylätasoisesti. Euromääräiset arviot löytyvät mutta prosessien linkitystä IT-järjestelmiin ja -ohjelmiin ei ole luotu. Tämän suppeamman riskiarvion tukemiseksi tutkija ehdottaa jokaiselle kriittiselle prosessille sen IT-järjestelmien ja -ohjelmien linkitystä kuvan 17 mukaisesti.
Kriittinen prosessi A
Prosessi A:lle kriittinen palvelin 1
Prosessi A:lle kriittinen palvelin 2 Prosessi A:lle
kriittinen sovellus B
Kriittisten palvelimien välillä oleva integraatio 1
Kriittisen palvelimen ja sovelluksen välillä oleva integraatio 2
Kuva 17. Tarkempi prosessikaavio riskienhallinnan tueksi
73
Kuvassa tarkempi prosessikaavio, jossa on yhdistetty liiketoiminnan osa-alueen x kriittinen prosessi ja sen kriittisimmät IT-ympäristön osat. Tästä on helppo jatkaa tekemään prosessin ja siihen liittyvän IT-ympäristön osien perusteella tarkempia riskiarvioita (Kuva 18).
- Todennäköisyys että riski 1 toteutuu: 10%
- Riski 1 euromääräiset vahingot: 100 000e
- Todennäköisyys, että riski 3 toteutuu: 15%
- Riski 3 euromääräiset vahingot: 10 000e Ehkäisevät toimenpiteet:
palvelimen kahdentaminen
Tunnistettu riski 2:
- Todennäköisyys, että riski 2 toteutuu: 17%
- Riski 2 euromääräiset vahingot: 12 000e
Kuva 18. Tarkentunut riskiarviointi prosessille A
74
Tarkentunut riskiarviointi osoittaa kriittiselle prosessille kriittisimpien palvelimien ja sovelluksen riskien toteutumisien todennäköisyydet, euromääräiset kustannukset, jos riskit toteutuisivat sekä niiden ehkäisevät toimenpiteet. Seuraavaksi voidaan luoda esimerkiksi kriittisille palveluille jatkuvuussuunnitelmia, jotka pohjautuvat tarkentuneisiin riskiarviohin, jotka kattavat laajemmat prosessikaaviot ja riskiarviot (Kuva 19).
Prosessi A:
- Syöttää palvelulle D kriittistä tietoa Y:stä - On palvelun D tärkein
prosessi
Prosessi B
Henkilöstö:
3 ihmistä osaa suorittaa prosessi A:ta
Sovellus B:n häiriö vaikuttaa vakavasti palvelu D:n
suorittamiseen
Pieni riski: Palvelin 1 tai 2 kaatuu
Lyhyt katkos -> vaikutus vähäinen
Pidempi katkos alle 24h ->
vaikutus riippuu olemassa olevasta tilanteesta
Pidempi katkos 1-2 vrk ->
Vaikutus merkittävä
Prosessia A ei voida suorittaa, kesto yli 2vko
Prosessille A kriittinen palvelin 2 prosessi A:lle kriittinen sovellus B
Kriittisten palvelimien integraatio 1välillä oleva Kriittisten palvelimien välillä oleva integraatio 2 Tunnistettu riski 1:
- Todennäköisyys että riski 1 toteutuu: 50%- Riski 1 euromääräiset vahingot: 1000e Ehkäisevät toimenpiteet: vaihtoehtoisen toimintatavan kehittäminen
Tunnistettu riski 3:
- Todennäköisyys että riski 1 - Riski 1 euromääräiset vahingot: 100 000etoteutuu: 5%
Ehkäisevät toimenpiteet:
palvelimen 1 toimivuuden varmistaminen Tunnistettu riski 2:
- Todennäköisyys että riski 1 - Riski 1 euromääräiset vahingot: 12 000eEhkäisevät toimenpiteet: toteutuu: 10%
palvelimen 2 toimivuuden varmistaminen Kriittisen prosessin A kriittisimmät riskit ovat: -Sovellus B- Palvelin 2 - Palvelin 1
- Palvelimien kahdentaminen- Sovelluksen toiminnallisuuden kahdentaminen
Palvelu D:n jatkuvuussuunnitelma
Kuva 19. Prosessi A Palvelu D:n jatkuvuussuunnitelmassa (Savon Voima, 2018c, mukaillen)
75
Edeltävällä sivulla on kuvattu palvelu D:n jatkuvuussuunnitelman prosessin A:n yksityiskohtainen käsittely, joka koostuu tekemiseen liittyvistä toimenpiteistä ja osapuolista, tunnistetuista riskeistä, riskien hallittavuuksista ja riskien suuruuksista.
Kuva on hyvä määrittämään kaikkien prosessien roolit, tunnistetut riskit ja niiden kriittisyydet, riskien vaikutuksen laajuus, jos prosessi katkeaa ajaksi x, ennustetut tapahtumat, jos riskit realisoituvat ja niiden lieventämisen prosessit sekä euromääräiset riskiarviot, joiden liitteenä on tarkentunut riskiarvio. Kun tämä prosessi kuvataan jokaiselle palvelun D kriittiselle prosessille, saadaan lopulta kattava palvelun D jatkuvuussuunnitelma (Kuva 20).
Palvelu D:n jatkuvuussuunnitelma
Kuva 20. Palvelu D:n jatkuvuussuunnitelma kaikkine prosesseineen (Savon Voima, 2018c, mukaillen)
Kun jokaiselle palvelun D sisältävälle prosessille tehdään samanlaiset prosessikaaviot ja riskiarviot ja ne nivotaan yhteen – saadaan palvelun D jatkuvuussuunnitelma kaikkine riskiarvioineen ja komponentteineen.
Liiketoimintatason CMDB:n luominen kannattaa aloittaa ensiksi jokaisen kriittisen palvelun tai muun liiketoiminnalle kriittisen osa-alueen kartoittamisesta niiden muodostaviin IT-ympäristön osiin. Kun kartoitukset on tehty, niin voidaan kaikille liiketoiminnan kriittisille osille tehdä tarkemmat riskiarviot suhteessa IT-ympäristöön
76
ja jatkuvuussuunnitelmat, jotka tulisi koota yhteen tietokantaan. Tarvittaessa voitaisiin peilata tarkempia tietoja IT-palveluntarjoaja A:n CMDB:stä. Seuraavalla sivulla on kuvattu liiketoimintatason CMDB:n, riskienhallinnan ja IT-palveluntarjoaja A:n CMDB:n väliset suhteet (Kuva 21).
IT-palveluntarjoaja A:n CMDB Liiketoimintatason CMDB
Tarjoaa tarkempaa CI-tietoa tarkempien prosessikaavioiden,
riskiarvioiden ja jatkuvuussuunnitelmien
muodostamiseksi Sisältää kattavat prosessikaaviot, riskiarviot
ja jatkuvuussuunnitelmat liiketoiminnan osa-alueiden kriittisimmistä prosesseista
Riskienhallinta
Käyttää molempien CMDB:den tietoja
tarkempien prosessikaavioiden,
riskiarvioiden ja jatkuvuussuunnitelmien
muodostamiseksi
Kuva 21. Liiketoimintatason CMDB suhteessa muihin prosesseihin
77
6 Pohdinta ja yhteenveto
Tämän Pro Gradu -tutkielman tavoitteena oli vastata luvussa 4.1.1 asetettuun päätutkimuskysymykseen: Miten konfiguraationhallinta tukee riskienhallintaa ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä? Tämä jaettiin aihetta tukeviin, pienempiin tutkimuskysymyksiin: Miten konfiguraationhallintaa suoritetaan Savon Voima Oyj:llä? Miten riskienhallintaa suoritetaan Savon Voima Oyj:llä? Mitä haasteita konfiguraationhallinnan suorittamisessa Savon Voima Oyj:llä ilmenee? Mitä haasteita riskienhallinnan suorittamisessa Savon Voima Oyj:llä ilmenee? Perustuen teorialukuihin konfiguraationhallinnasta ja riskienhallinnasta sekä tekemällä tapaustutkimusta Savon Voima Oyj:lle voidaan todeta että tutkija pystyi useisiin aineistolähteisiin pohjautuen vastaamaan tutkimuskysymyksiin ja lisäksi luomaan interventiokeinoja, joilla konfiguraationhallinta voisi tukea riskinhallintaa.
Tutkimuksen kulku oli luvun 5 mukainen:
1) Puolistrukturoidut haastattelut Savon Voima Oyj:n IT-palvelunhallintaprosesseista parhaiten tietäville asiantuntijoille, joiden pohjalta saatiin kartoitettua yhdessä muun aineiston kanssa konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet, kehitysideat sekä konfiguraationhallinnan hyödyt riskienhallinnalle.
2) Konfiguraationhallinnan ja riskienhallinnan nykytilanteiden, haasteiden ja kehitysideoiden kartoittaminen.
3) Tarkempien prosessikaavioiden, riskiarvioiden ja jatkuvuussuunnitelmien luominen sekä liiketoimintatason CMDB:n ideoiminen konfiguraationhallinnan hyödyttämiseksi riskienhallinnalle.
Kohdassa yksi pidettyjen puolistrukturoitujen haastatteluiden, luotujen teorialukujen ja Savon Voima Oyj:ltä kerätyn aineiston perusteella, saatiin kasaan kattava ja monipuolinen tutkimusaineisto. Tutkimuksen tuloksia oli helppo todentaa, sillä monesti ne tulivat esille monista eri lähteistä luoden tutkimukselle hyvän pohjan.
Kohdassa kaksi kartoitettiin tämän edellä mainitun aineiston pohjalta konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat.
78
Tutkimustuloksia taulukoitiin jokaisessa tutkimuksen vaiheessa sekä ristiintaulukoitiin haasteiden ja kehitysideoiden vertaamiseksi kummankin IT-palvelunhallintaprosessin kohdalla ja myös molempien prosessien kehitysideoita ristiintaulukoitiin, jotta löydettäisiin kriittisimmät kohdat joissa konfiguraationhallinta voisi tukea riskienhallintaa. Tutkimuksen kohdassa kolme luotiin löydettyjen kriittisten tukemiskeinojen perusteella interventiokeinoja, jotka parantaisivat riskienhallintaa ensisijaisesti ja konfiguraationhallintaa toissijaisesti.
Interventiokeinoina esitettiin ylätasoisten riskiarvioiden pohjalta kriittisempien prosessien prosessikaavioiden tekemistä, jotta prosessit ja IT-ympäristöt osattaisiin kartoittaa yhteen, tämän jälkeen laajemman riskiarvion tekemistä liittyen edellä mainittuihin prosessikaavioihin, josta kävisi ilmi kriittisen prosessin kriittiset IT-ympäristön komponentit, niiden riskien realisoitumisen todennäköisyydet, haittavaikutukset ja hallintakeinot. Täten olisi helppoa määrittää jollekin tietylle kriittiselle prosessille tarkempi euromääräinen riskiarvio, kun IT-ympäristöt olisi otettu myös huomioon.
Näitä laajentuneita riskiarvioita taas voitaisiin käyttää hyödyksi kun luotaisiin esimerkiksi palvelutasoisia jatkuvuussuunnitelmia, jotka sisältäisivät tarkemmat riskiarviot. Nämä prosessikaaviot, laajemmat riskiarviot ja jatkuvuussuunnitelmat voitaisiin säilöä liiketoimintatason CMDB:hen, jotta jokaisella liiketoiminnan osa-alueen kriittisellä palvelulla tai muulla kriittisellä osalla olisi jatkuvuussuunnitelmat, jotka takaisivat liiketoiminnan jatkuvuuden sekä nopean palautumisen häiriöiden tai katastrofien ilmentyessä. Liiketoimintatason CMDB:n ei tarvitsisi välttämättä olla mikään laaja IT-järjestelmä, vaan jokin yksinkertainen tietokantaratkaisu olisi varmasti riittävä, sillä se sisältäisi vain ”kevyempää” tietoa liiketoiminnasta ja IT-ympäristöistä ja niiden välisistä yhteyksistä. Tarkempaa tietoa voitaisiin tarvittaessa hakea IT-palveluntarjoaja A:n CMDB:stä.
Tämän tapaustutkimuksen luonne (yksi tutkimusmenetelmä ja yksi tapausorganisaatio) rajoittavat tutkimuksen kehittymistä teoriaa tai yleistämistä rakentavaksi tutkimukseksi. Tämän tapaustutkimuksen tuloksia tulisi tarkastella vain
79
Savon Voima Oyj:n prosessien kehittämisen kannalta, eikä tuloksia voida suoranaisesti liittää muiden toimialojen organisaatioiden prosessien kehittämiseen.
Jotta prosessit voisivat auttaa toisiaan, tulisi molempien itsessään olla riittävällä tasolla. Kun molempia prosesseja kehitetään ja ne yhdistetään oikealla tavalla, saa liiketoiminta siitä valtavia hyötyjä. Näkyvimpiä hyötyjä ovat riskienhallinnan tarkentuminen (liiketoimintaprosessit osataan pilkkoa IT-rakenneosien tasolle, jolloin euromääräiset kulut riskien lieventämisestä ja realisoitumisesta saadaan esille), liiketoiminnan ja IT-jatkuvuudensuunnitelmien parantuminen, konfiguraatiohallinnan merkityksen huomaaminen organisaatiotasolla sekä oikeantyyppisen dokumentaation ja konfiguraatiotietojen ylläpitämisen prosessien käyttöönottaminen.
Konfiguraationhallinta voi auttaa riskienhallintaa myös muillakin tavoilla kuin tutkijan esittämillä interventiokeinoilla. Esimerkiksi konfiguraationhallinta voi auttaa riskienhallintaa löytämään riskejä helpommin konfiguraatiotietokannan avulla.
Konfiguraatiotietokannasta voidaan tunnistaa mahdollisia riskejä liittyen laitteistoihin, ohjelmistoihin, tietokantoihin tai näitä yhdistäviin suhteisiin. Esimerkkejä tällaisista riskeistä olisi esimerkiksi jonkun henkilön, laitteen tai yhteyden puuttuminen liittyen johonkin kriittiseen palveluun.
Konfiguraationhallinta auttaa riskienhallintaa myös luomalla ja ylläpitämällä oikeaa konfiguraatiotietoa IT-infrastruktuurista. Kun tiedetään kaikkien konfiguraatioiden rakenneosat ja niiden väliset yhteydet, ymmärretään IT-infrastruktuuria paremmin.
IT:stä johtuvat riskit voivat olla helppoja hallita kun organisaation IT-infrastruktuuri on pieni ja yksinkertainen, mutta kun se kasvaa ja monimutkaistuu, on infrastruktuurissa piilevien riskien tunnistaminen ja hallitseminen vaikeampaa. On myös muistettava että riskienhallinnalla on hyötyjä konfiguraationhallinnalle. Se toimii validoivana prosessina, jossa riskiarvio IT-infrastruktuurista voi paljastaa heikkoja kohtia tai parannuskohteita konfiguraationhallinnassa.
Konfiguraationhallinnan ja riskienhallinnan toteuttaminen korkealla tasolla on Savon Voima Oyj:llä haastavaa, koska Savon Voima koostuu emoyhtiöstä ja kahdesta tytäryhtiöstä, hajautetusta ja toimintaympäristöstä sekä ulkoistetusta
IT-80
palvelunhallintaympäristöstä ja ulkoisista toimittajista. Jokaisella liiketoiminnan osa-alueella on omat ainutlaatuiset riskinsä ja intressinsä, joihin jokainen liiketoiminnan osa-alue keksittyy näin heikentäen yhtenäistä liiketoiminnan fokusoitunutta riskienhallintaa. Riskienhallintaa on tehty liiketoimintatasolla ja sitä ei ole yhdistetty tai prosesseja ei ole tarkennettu IT-infrastruktuuriin ja siitä koostuviin rakenneosiin.
Tämän korjaaminen vaatii henkilöstöltä valtavia panostuksia sekä se vaatii prosessien ja toimintatapojen uudelleen määrittämistä, mutta silti se olisi tarvittava muutosprosessi käydä läpi, jotta konfiguraationhallinta ja erityisesti riskienhallinta saataisiin liiketoiminnallisesti yhteiselle tasolle ja näiden prosessien hoitaminen olisi henkilöstölle vakiotoimenpide. Toisin sanoen, ideaalitilanne olisi se, että riskienhallinnan ja konfiguraationhallinnan suorittaminen olisi integroituna Savon Voima Oyj:n yrityskulttuuriin ja niitä noudatettaisiin organisaation jokaisella tasolla.
Tutkija haluaa vielä mainita, että vaikka tutkimus keskittyi riskienhallinnan parantamiseen konfiguraationhallinnan avulla, tulisi Savon Voima Oyj:n myös kehittää konfiguraationhallintaa omana prosessinaan. Tapaustutkimuksen aikana luvuissa 5.1 ja 5.2 havaittiin konfiguraationhallinnan haasteet organisaatiossa sekä prosessia parantavat kehitysideat.
Tutkimusta IT-palvelunhallinnan ja liiketoiminnan riskienhallintaan on tutkittu laajasti, mutta maailman muuttuessa yhä monimutkaisemmaksi ja teknologisemmaksi tuo tämä digitaalisaation aikakausi tarvetta näiden kahden riskienhallinnan tutkimuksen yhdistämiseksi. Lisäksi konfiguraationhallinta omana prosessinaan vaatii lisätutkimusta, sillä alan tutkimuskirjallisuus aiheesta on varsin rajoittunutta. Lisäksi konfiguraationhallinnan ja riskienhallinnan yhteyttä tulisi tutkia lisää, sillä kun nämä kaksi prosessia yhdistetään riskienhallintaprosessia tehdessä, voivat lopputulokset olla varsin positiivisia ja kattavia.
81
Viitteet
Baxter, P & Jack, S. (2008). Qualitative case study methodology: Study design and implementation for novice researchers. The qualitative report, 13.4, 544-559.
BMC Software. (2005). Focus on: CMDB. Viewpoint Magazine, Volume 1.
Bon, J. V., de Jong, A., Kolthof, A., Pieper, M., Rozemeijer, E., Tjassing, R., Van der Veen, A. & Verheijen, T. (2007). IT service management: An introduction. 3rd ed.
Zaltbommel: Van Haren Publishing.
Bon, J. V., Nugteren, M. & Polter, S. (2006). ISO/IEC 20000: A pocket quide. Van Haren Publishing.
Bosch, J. (2009). From software product lines to software ecosystems. In Proceedings of the 13th international software product line conference (pp. 111-119). Carnegie Mellon University.
Brooks, P. (2006). Metrics for IT Service Management. Van Haren.
Camilleri, E. (2011). Project success: Critical factors and behaviours. Farnham:
Gower.
Davies, J., Finlay, M., McLenaghen, T., & Wilson, D. (2006). Key risk indicators–
their role in operational risk management and measurement. ARM and RiskBusiness International, Prague, 1-32.
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of management review, 14(4), 532-550.
82
GCM Securities Limited. (2018). Risk & Responsibilities of Risk Management
Committee. [Online] Available from:
https://www.gcmsecuritiesltd.com/investor/policy/Roles%20&%20Responsibilites%
20of%20Risk%20Management%20Committee.pdf [Accessed: 05th April 2018].
Hanseth, O. & Ciborra, C. (2007). Risk, complexity and ICT. Cheltenham, UK;
Northampton, MA: Elgar.
Hunnbeck, L., Rudd, C., Lacy, S. & Hanna, A. (2011). ITIL service design. 2nd ed., 2011 ed. London: TSO (The Stationery Office).
Information Systems Audit, Control Association & Isaca. (2012a). COBIT 5: For Information security. Rolling Meadows, IL: ISACA.
Information Systems Audit, Control Association & Isaca. (2012b). COBIT 5:
Implementation. Rolling Meadows, IL: ISACA.
ISO/IEC. (2012a). Information technology: Process assessment. Part 8, An exemplar process assessment model for IT service management. First edition. Geneva.
ISO/IEC. (2012b). Information technology: Security techniques. Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1. First edition.
Geneva.
ITSMF. (2014). ITIL-sanasto ja lyhenteet. [Online] Available from: http://itsmf.fi/wp-content/uploads/2014/03/ITIL_2011_Finnish_Glossary_v1.0.pdf. [Accessed: 16th August 2017].
Johnson, B. & Higgins, J. (2007). ITIL® and the Software Lifecycle: Practical Strategy and Design Principles. Van Haren Publishing, Zaltbommel.
83
Keel, A. J., Orr, M. A., Hernandez, R. R., Patrocinio, E. A. & Bouchard, J. (2007).
From a technology-oriented to a service-oriented approach to IT management. IBM Systems Journal 46.3. (pp. 549-564).
Klosterboer, L. (2007). Implementing ITIL configuration management. 1st Ed. Pearson Education.
Komarek, A., Sobeslav, V., & Pavlik, J. (2015). Enterprise ICT transformation to agile environment. In Computational Collective Intelligence (pp. 326-335). Springer, Cham.
Marquis, H. (2007). ITIL and the evolving CMDB. Business Communications Review 37.2. (pp. 54-57).
McKim, V. L. (2017). Operational risk assessment. Journal of business continuity &
emergency planning, 10(4), 339-352.
Mosimann, R. (2007). The performance manager: Proven strategies for turning information into higher business performance. Ottawa, Canada: Cognos.
Office of Government Commerce. (2002a). ICT Infrastructure Management. London:
TSO.
Office of Government Commerce. (2005b). Introduction to ITIL. London: TSO.
Office of Government Commerce. (2002c). Planning to Implement Service Management. London: Stationery Office.
Office of Government Commerce. (2007d). Service transition. London: TSO.
84
Sahibudin, S., Sharifi, M., & Ayat, M. (2008). Combining ITIL, COBIT and ISO/IEC 27002 in order to design a comprehensive IT framework in organizations. Modeling
& Simulation, 2008. AICMS 08. Second Asia International Conference on (pp. 749-753). IEEE.
Sallé, M. (2004). IT Service Management and IT Governance: review, comparative analysis and their impact on utility computing. Hewlett-Packard Company, 8-17.
Savon Voima. (2018a). Savon Voima Oyj:n avainhenkilöille 04.04. – 06.04.2018 pidettyjen haastatteluiden muistiinpanot. Viitattu 07.04.2018.
Savon Voima. (2018b). Savon Voima Oyj:n 05.04.2018 järjestämän keskeytysriskien ja riippuvusriskien kartoituksen palaverin muistiinpanot. Viitattu 07.04.2018.
Savon Voima. (2018c). Savon Voima Oyj:n dokumentaatio ja artefaktit liittyen konfiguraation- ja riskienhallintaan. Viitattu 07.04.2018.
Savon Voima. (2018d). Tietoa meistä. [Online] Available from:
https://www.savonvoima.fi/konserni/tietoa-meista/ [Accessed: 01th April 2018].
ServiceNow. (2018a). Establishing good reporting practices and effective
management dashboards. [Online] Available from:
https://www.slideshare.net/servicenowdotcom/establishing-good-reporting-practices-and-effective-management-dashboards [Accessed: 05th April 2018].
ServiceNow. (2018b). Integrating a Discovery Tool With Your Express CMDB
Through XLS. [Online] Available from:
https://express.servicenow.com/support/integrating-discovery-tool-express-cmdb-xls/
[Accessed: 26 th February 2018].
85
Servicetonic. (2018). IT Asset Management and CMDB. [Online] Available from:
https://www.servicetonic.com/help-desk-software/asset-management-and-cmdb/
[Accessed: 08 th February 2018].
SFS. (2015). Information technology: Security techniques. Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors. Helsinki: Suomen standardisoimisliitto.
Stake, R. E. (1978). The case study method in social inquiry. Educational researcher, 7(2), 5-8.
Taylor, S. (2007). The official introduction to the ITIL service lifecycle. London: TSO.
Thalmann, S., Manhart, M., Ceravolo, P. & Azzini, A. (2014). An integrated risk management framework: measuring the success of organizational knowledge protection. International Journal of Knowledge Management (IJKM) 10.2. (pp. 28-42).
The art of service. (2007). ITIL®: Factsheets. Brisbane.
Tivi. (2011). [Online] Available from: http://www.tivi.fi/Uutiset/2011-05-
02/Amazonin-pitk%C3%A4-anteeksipyynt%C3%B6-ja-selitys-lepytti-pilviasiakkaat-3184377.html. [Accessed: 16th August 2017].
Tivi. (2014). [Online] Available from: http://www.tivi.fi/Arkisto/2014-12-15/Elisan-
kaivinkonetapauksen-syy-l%C3%B6ytyi-Ruotsista-Olemme-pahoillamme-3151486.html. [Accessed: 16th August 2017].
86
Verism. (2018). Verism in a VUCA world. [Online] Available from:
https://verism.exin.com/2017/12/13/verism-in-a-vuca-world/ [Accessed: 05th April 2018].
Vilarinho, S. & Mira da Silva, M. (2011). Risk management model in ITIL.
International conference on ENTERprise information systems. Springer, Berlin, Heidelberg.
Yin, R. K. (2014). Case study research: Design and methods. 5th ed. Los Angeles:
SAGE.
Ying, L., Lijun, X. & Wei, S. (2009). Configuration management process design and implementation. 2009 ISECS International Colloquium on Computing, Communication, Control, and Management. (pp.4-7).
87