Konfiguraationhallinnan hyödyt riskienhallinnalle ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä: Tapaustutkimus Savon Voima Oyj

Transkriptio

1 Konfiguraationhallinnan hyödyt riskienhallinnalle ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä: Tapaustutkimus Savon Voima Oyj Tuukka Miettinen Pro gradu -tutkielma Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Huhtikuu 2018

2 ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Kuopio Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Opiskelija, Tuukka Miettinen: Konfiguraationhallinnan hyödyt riskienhallinnalle ulkoistetussa IT-palvelunhallinnassa ja hajautetussa IT-ympäristössä: Tapaustutkimus Savon Voima Oyj Pro gradu -tutkielma, 87 s., 1 liite (1 s.) Pro gradu -tutkielman ohjaajat: FT Marko Jäntti ja Tietotekniikan Insinööri Niko Pehkonen Huhtikuu 2018 Liiketoimintojen IT-ympäristöiden monimutkaistuessa ja pirstaloituessa nousevat riskienhallinta ja konfiguraationhallinta tärkeiksi prosesseiksi näiden ilmiöiden hallitsemiseksi. Konfiguraationhallinnan pitäessä yllä tietoa kaikista ITinfrastruktuurin osista ja niiden välisistä yhteyksistä riskienhallinta taas pyrkii tunnistamaan kaikki liiketoimintaa koskevat riskit, niiden vaikutukset ja niiden hallintakeinot. Molempia prosesseja on vaikea ylläpitää korkealla tasolla ja tämän saavuttamiseksi tulee organisaatiossa sitoutuminen prosessien suorittamiseksi koskettaa kaikkia. Aikaisempaa tutkimusta molemmista prosesseista itsessään on tehty, mutta niiden yhteisvaikutuksen merkitystä ei ole laajasti tutkittu. Tämän Pro Gradu -tutkielman tarkoituksena on selvittää konfiguraationhallinnan hyödyt riskienhallinnalle. Tutkimuksessa käytettiin tapaustutkimusta sekä kahta teorialukua tunnistamaan sekä riskienhallinnan että konfiguraationhallinnan hyötyjä. Tapausorganisaationa toimi Savon Voima Oyj, jonka konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat kartoitettiin tutkimuksen ensivaiheessa. Aineistoa näiden kartoittamiseksi kerättiin puolistrukturoitujen haastatteluiden, keskeytysriskien kartoituksen palaverin sekä muun Savon Voima Oyj:n aineiston avulla. Tämän jälkeen tulokset ristiintaulukoitiin, jotta kriittisimmät haasteet ja kehitysideat organisaation sisällä tunnistettaisiin. Tutkimuksen tuloksena tunnistettiin konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat. Näiden tulosten pohjalta pystyttiin tunnistamaan konfiguraationhallinnan hyödyt riskienhallinnalle ja luomaan interventiokeinoja niiden toteuttamiseksi. Interventiokeinoja olivat: prosessikaavioiden, tarkempien riskiarvioiden ja jatkuvuussuunnitelmien luominen. Lisäksi esitettiin liiketoimintatason CMDB:n idea. Tämän tutkimuksen tuloksia hyödynnettiin Savon Voima Oyj:n prosessien parantamisessa. Avainsanat: tapaustutkimus ITIL, IT-palvelunhallinta, konfiguraationhallinta, riskienhallinta, ACM-luokat (ACM Computing Classification System, 2012 version): Applied computing, Enterprise computing, IT governance ii

3 UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Kuopio School of Computing Computer Science Student, Tuukka Miettinen: The benefits from Configuration Management to Risk Management in a outsourced IT Service Management and in a fractured IT environment: Case Study Savon Voima Oyj Master s Thesis, 87 p., 1 appendix (1 p.) Supervisors of the Master s Thesis: PhD Marko Jäntti and B.Eng Niko Pehkonen April 2018 As IT environments for different types of businesses get more complicated and fractured, organizations need good Configuration Management and Risk Management to manage them properly. While Configuration Management is responsible for keeping track for all the parts of the IT environment and all their connections, Risk Management is responsible for identifying all the risks, their impacts and ways of controlling them associated with the business of the organization. It s hard to maintain a high level of performance regarding both of these processes and it can only be achieved if the whole organization is committed to executing these processes properly. There have been studies conserning both of these processes individually but there has been a lack of research regarding the benefits of executing them together. The purpose of this Master s Thesis is to find out the benefits that Configuration Management has for Risk Management. Case study and two theory chapters where used to discover the benefits of Risk Management and Configuration Management. The case organization for this research was Savon Voima Oyj which current states, challenges and development ideas for Configuration Management and Risk Management where found in the first stage of the study. The research material used to find these answers was collected from semistructured interviews, from a risk mapping meeting and from the other research materials available at Savon Voima Oyj. After this, the results were cross tabulated to find the most critical challenges and development ideas within the organization. As a result of this study, the current state, challenges and development ideas for Configuration Management and Risk Management where found. From these findings, we identified the benefits that Configuration Management provided to Risk Management defines intervention methods to do so. The intervention methods included: a flowchart, a more precise risk assessment process and the creation of contingency plans. Finally, an idea for a business level CMDB was also formed. The results from this study can t be used for creating theory or generalization and can only be used to improve the processes in question at Savon Voima Oyj. Keywords: ITIL, IT Service Management, Configuration Management, Risk Management, Case Study CR Categories (ACM Computing Classification System, 2012 version): Applied computing, Enterprise computing, IT governance iii

4 Esipuhe Tämä tutkielma on ohjattu ESR-rahoitteisen Tuottavuutta ja Digitaalisia Palveluita Liiketoiminnan Avuksi -hankkeen (S21138) aikana keväällä Tutkielmassa tutkittiin Savon Voima Oyj:n konfiguraationhallinnan hyötyjä riskienhallinnalle tapaustutkimuksen keinoin. Tutkielman ohjaajana toimi FT Marko Jäntti ja Savon Voima Oyj:n ohjaajana ICT- ja digitalisaatiopäällikkö Niko Pehkonen, joita haluan kiittää jatkuvasta opastuksesta ja kannustuksesta IT-maailman pariin. Lisäksi haluan kiittää Savon Voima Oyj:n työkavereitani, perhettäni ja ystäviäni jatkuvasta tuesta tämän koko prosessin aikana. Kuopiossa Tuukka Miettinen iv

5 Lyhenneluettelo AM Availability Management. Saatavuudenhallinta. (ITSMF, 2014). BCM BIA CFIA Business Continuity Management. Liiketoiminnan jatkuvuudenhallinta. (Hunnbeck et al., 2011). Business Impact Analysis. Liiketoiminnan vaikutusanalyysi. (Hunnbeck et al., 2011). Component Failure Impact Analysis. Komponentin vikaantumisen vaikutusanalyysi. (Hunnbeck et al., 2011). CI Configuration Item. Konfiguraation rakenneosa. (ITSMF, 2014). CM Capacity Management. Kapasiteetinhallinta. (ITSMF, 2014). CM Change Management. Muutoksenhallinta. (ITSMF, 2014). CM Configuration Management. Konfiguraationhallinta. (ITSMF, 2014). CMDB CMS Configuration Management Database. Konfiguraatiotietokanta. (ITSMF, 2014). Configuration Management System. Konfiguraationhallintajärjestelmä. (ITSMF, 2014). CM Configuration Model. Konfiguraatiomalli. (ITSMF, 2014). COBIT Control Objectives for Information and related Technology. Tiedon ja siihen liittyvän teknologian kontrollitavoitteet. (ITSMF, 2014). CSF Critical Success Factor. Kriittinen menestystekijä. (ITSMF, 2014). DML Definitive Media Library. Definitiivinen mediakirjasto. (ITSMF, 2014). v

6 ERMC FCMDB FM Enterprise Risk Management Committee. Riskienhallintakomitea. (Information Systems Audit, Control Association & Isaca, 2012a). Federaded Configuration Management Database. Federoitu konfiguraatiotietokanta. (Office of Government Commerce, 2007). Financial Management. Taloushallinto. (Office of Government Commerce, 2005). GDPR General Data Protection Regulation. Tietosuoja-asetus. (SFS, 2015). IM Incident Management. Häiriönhallinta. (ITSMF, 2014). ISM ISO ITIL ITSCM ITSCP Information Security Management. Tietoturvan hallinta. (ITSMF, 2014). International Organisation for Standardization. Kansainvälinen standardointiorganisaatio. (ITSMF, 2014). Information Technology Infrastructure Library. Kokoelma parhaita käytäntöjä IT-palveluiden hallintaan ja johtamiseen. (ITSMF, 2014). IT Service Continuity Management. IT-palvelun jatkuvuudenhallinta. (Hunnbeck et al., 2011). IT Service Continuity Plans. IT-jatkuvuussuunnitelma. (Hunnbeck et al., 2011). ITSM IT Service Management. IT-palvelunhallinta. (ITSMF, 2014). KB Knowledge Base. Tietämyskanta. (ITSMF, 2014). KM Knowledge Management. Tietämyksenhallinta. (ITSMF, 2014). KPI Key Performance Indicator. Keskeinen suorituskykymittari. (ITSMF, 2014). KRI Key Risk Indicator. Avainriskimittari. (Davies et al., 2006). M_o_R Management of Risk. Riskienhallinta. (Hunnbeck et al., 2011). vi

7 ORA Operational Risk Assessment. Operationaalisten riskien arviointi. (McKim, 2017). PB Problem Management. Ongelmanhallinta. (ITSMF, 2014). RA Risk Assessment. Riskien arviointi. (Hunnbeck et al., 2011). RFC Request For Change. Muutospyyntö. (ITSMF, 2014). RM Release Management. Jakelunhallinta. (ITSMF, 2014). RM Risk Management. Riskienhallinta. (Hunnbeck et al., 2011). SE Software Ecosystem. Ohjelmiston ekosysteemi. (Bosch, 2009). SLA Service Level Agreement. Palvelutasosopimus. (ITSMF, 2014). SLM Service Level Management. Palvelutasonhallinta. (ITSMF, 2014). SPL Software Product Line. Ohjelmiston tuotantolinja. (Bosch, 2009). SO Service Operation. Palvelutuotanto. (Mosimann, 2007). vii

8 Sisällysluettelo 1 Johdanto Konfiguraationhallinta IT-palvelunhallinnassa Konfiguraationhallinnan ydinkäsitteet Konfiguraatiomalli Konfiguraationhallintajärjestelmä Konfiguraatiotietokanta Konfiguraation rakenneosa ja perustaso Kriittiset menestystekijät ja suorituskykymittarit Definitiivinen mediakirjasto Konfiguraationhallinnan suunnittelu ja hallinta Konfiguraationhallinnan tietokannat Hyödyt muille palvelunhallintaprosesseille Konfiguraationhallinnan haasteet Riskienhallinta IT-palvelunhallinnassa Riskienhallinnan ydinkäsitteet Riskienhallinnan tehtävät ja tukitoimet liiketoiminnalle Riskienhallintakomitea Riskien arviointi Komponentin vikaantumisen vaikutusanalyysi Avainriskimittari Liiketoiminnan vaikutusanalyysi IT-jatkuvuussuunnitelma Operationaalisten riskien arviointi Kriittiset menestystekijät ja suorituskykymittarit Riskienhallinnan suunnittelu ja hallinta Riskienhallinnan hyödyt muille palvelunhallintaprosesseille Riskienhallinnan haasteet Tutkimusmenetelmät Tutkimusasetelma Tutkimusongelma ja tutkimuskysymykset Tutkimusaineisto Tutkimusmenetelmät Savon Voima Oy Tiedonkeruumenetelmät Tiedon analysointi Konfiguraationhallinnan hyödyt riskienhallinnalle Konfiguraationhallinnan nykytilanne Savon Voima Oyj:llä Konfiguraationhallinnan haasteet Savon Voima Oyj:ssä Konfiguraationhallinnan kehitysideat Riskienhallinnan nykytilanne Savon Voima Oyj:llä Riskienhallinnan haasteet Savon Voima Oyj:llä viii

9 5.6 Riskienhallinnan kehitysideat Konfiguraationhallinnan hyödyt riskienhallinnalle Pohdinta ja yhteenveto Viitteet Liite 1: Haastattelulomake ix

10 1 Johdanto Konfiguraationhallinnan (Configuration Management, CM) tarkoituksena on tunnistaa ja ylläpitää kaikkien tunnistettujen palvelukomponenttien eheyttä. Konfiguraationhallinnan hyötyjä ovat muun muassa se, että konfiguraationhallintaa tarvitsevat konfiguraation rakenneosat (Configuration Item, CI) tunnistetaan ja ne säilötään yhteen paikkaan, konfiguraatiotietokantaan (Configuration Management Database, CMDB). Kaikki toimenpiteet, jotka suoritetaan rakenneosille, on suoritettu kontrolloidusti (sama pätee myös tehtyihin muutoksiin). Konfiguraationhallinta takaa järjestelmien, palveluiden ja palvelukomponenttien oikeellisuuden ja julkaistujen omaisuuksien konfiguraatioiden hallinnan (ISO/IEC, 2012a). Vaikka konfiguraationhallinta on kuvattu prosessina varsin kattavasti parhaiden ITpalveluiden hallinnan ja johtamisen käytäntöjen kokoelmassa (Information Technology Infrastructure Library, ITIL), sitä ei tulisi käyttää ainoana ohjenuorana. Konfiguraationhallinta IT-palvelunhallinnassa (IT Service Management, ITSM) vaatii usein asioiden yhdistämistä monista eri viitekehyksistä, standardeista ja malleista. Siksi organisaatioiden tulisi valita omiin tarpeisiinsa sopivimmat käytännöt. Konfiguraationhallintaa kehittäessä voidaan hyödyntää mm. seuraavien viitekehysten ja standardien sisältämien osien yhdistämistä: ITIL, COBIT, ISO ja ISO Lisäksi voidaan käyttää palvelunhallinnan ulkopuolisia standardeja ja parhaita käytäntöjä optimaalisen konfiguraationhallinnan saavuttamiseksi, kuten tuotteenhallinnan ja ohjelmistotekniikan käytäntöjä ja malleja (Sahibudin et al., 2008). Hyvä esimerkki ulkopuolisesta parhaasta käytännöstä olisi ohjelmiston tuotantolinja (Software Product Line, SPL). Ohjelmiston tuotantolinjan tarkoituksena on rakentaa organisaation sisällä uudelleen käytettäviä komponentteja tuleviin ohjelmistoihin ja palveluihin. Täten ei työtä tarvitse aloittaa alusta vaan voidaan käyttää olemassa olevia komponentteja hyödyksi uuden kehitysprojektin alkaessa. Tämä metodi on mahdollistanut monien yritysten liikevaihdon positiivisen kasvun. 1

11 Kun organisaatio päättää laajentaa alustansa ulkopuolelle, siirtyy organisaatio ohjelmiston tuotantolinjasta ohjelmiston ekosysteemiksi (Software Ecosystem, SE). Metodissa ohjelmistoa tai palvelua ei kehitetä pelkästään sisäisesti, vaan käytetään ulkoisia kehittäjiä näiden kehittämiseksi. Ekosysteemi syntyy ohjelmiston tai palvelun luoneen organisaation tietoverkosta, ulkopuolisista kehittäjistä, jakelijoista ja kuluttajista. Sekä ohjelmiston tuotantolinja että ekosysteemi luovat organisaation tuotteille hyvän mahdollisuuden konfiguraation vaihtelevuuteen komponenttien jakamisen ja vapaan kehityksen takia. Syitä siirtyä ohjelmistojen ekosysteemiin ovat esimerkiksi organisaation havainnot siitä, että tiettyä tuotetta ei pystytä kehittämään tarpeeksi nopeasti tai tarpeeksi alhaisilla kustannuksilla organisaation sisällä sekä asiakkaiden tarve räätälöidä tuotteita (Bosch, 2009). Hyvin toteutetun konfiguraationhallinnan avulla voidaan tunnistaa käytössä olevia ITkomponentteja, rakenneosien versioita ja käyttöaikoja, palvelutrendejä, rakenneosien päivitysten ja poistojen tarpeita, käytettyjä lisenssejä ja niitä koskevia tarpeita, päivitys/huoltotoimenpiteiden tarpeita sekä standardoinnin tiloja koskien koko ITinfrastruktuuria (Office of Government Commerce, 2005). Konfiguraationhallinnan käytännön tuloksia ovat CI-arkistot, auditointiraportit, CI-muutosten lokikirjat sekä CI-tilojen raportit, jotka saadaan luotua muutospyyntöarkistoista, julkaisujen muistiinpanoista sekä CI-auditointien aikatauluista (ISO/IEC, 2012a). Riskienhallinnan (Risk Management, RM) tarkoituksena on jatkuvasti tunnistaa, analysoida, arvioida, käsitellä ja tarkkailla riskejä. Onnistuneen riskienhallinnan lopputuloksena riskit on tunnistettu, tunnistetut riskit on kategorisoitu, arvioitu ja priorisoitu, jotta resurssit osataan jakaa oikein korkeimman prioriteetin riskin hoitamiseksi. Riskit ja näiden hoito- ja ennaltaehkäisykeinot ilmoitetaan eteenpäin, arvioituja riskejä tarkkaillaan ja oikeanlaisia hoitokeinoja käytetään jotta vältytään pahimmilta arvioiduilta riskeiltä tai ne korjataan jo ennen kuin niistä muodostuu riski (ISO/IEC, 2012a). Kuten muidenkin IT-palvelunhallintaprosessien kohdalla, ei myöskään riskienhallintaa tulisi ottaa käyttöön yhden standardin tai käytännön pohjalta tai ainoana prosessina. Riskienhallinnan hyödyllisiä standardeja ja käytäntöjä ovat: ITIL, M_o_R, ISO 31000, ISO/IEC ja Risk IT (Hunnbeck et al., 2011). 2

12 Konfiguraationhallinnan aikaisemmat tutkimukset ovat keskittyneet konfiguraationhallinnan suunnitteluun (Ying et al., 2009), konfiguraationhallinnan yhdistämiseen COBIT:n ja ISO/IEC standardin kanssa (Sahibudin et al., 2008) ja konfiguraationhallinnan käyttöönottamiseen (Klosterboer, 2007). Riskienhallinnan aikaisemmat tutkimukset ovat taas keskittyneet riskienhallinnan ja tiedonhallinnan (Knowledge Management, KM) yhteen integroimiseen (Thalmann et al., 2014), avainriskimittarien (Key Risk Indicators, KRI) rooliin operationaalisessa riskienhallinnassa (Davies et al., 2006) ja operationaalisten riskien arvioimiseen (Operational Risk Assessment, ORA) (McKim, 2017). Tämän tutkielman tavoitteena on kartoittaa konfiguraationhallinnan ja riskienhallinnan nykytilanteet, haasteet ja kehitysideat Savon Voima Oyj:llä sekä tunnistaa konfiguraationhallinnan hyödyt riskienhallinnan parantamiseksi. Tuloksena syntyi interventiokeinoja, jotka voidaan ottaa käyttöön organisaation sisällä, parantaen riskienhallintaprosessia. Tutkijan tavoitteena on parantaa Savon Voima Oyj:n ITSMprosesseja luomalla uusia toimintatapoja organisaation sisällä. Tutkimuksen tavoitteena ei ole yleistävän teorian tai tutkimuksen luominen, vaan Savon Voima Oyj:lle tutkimuksen tekeminen tapaustutkimuksen keinoin. Tutkielma koostuu johdannon lisäksi viidestä muusta luvusta. Luvussa 2 esitellään konfiguraationhallinnan teorialuku, luvussa 3 luodaan riskienhallinnan teorialuku, luvussa 4 määritetään tutkimusmenetelmät tälle tutkimukselle, luvussa 5 tutkitaan tapaustutkimuksen avulla konfiguraationhallinnan hyötyjä riskienhallinnalle ja luvussa 6 pohditaan tutkimuksen tuloksia, niiden vaikutuksia Savon Voima Oyj:n sisällä ja luodaan yhteenveto tutkimuksesta. Tutkimusprosessin tavoitteena on luoda interventiokeinoja, joilla konfiguraationhallinta voi tukea riskienhallintaa. Tutkimus on hyvin ainutlaatuinen, sillä konfiguraationhallinnan ja riskienhallinnan välisestä suhteesta ei ole tehty laajasti tutkimusta ja siksi, koska Savon Voima Oyj:n fyysisien komponenttien että IT-ympäristön voisi sanoa olevan hajautettu ja Savon Voima Oyj on myös ulkoistanut IT-palvelunhallintansa näin luoden varsin ainutlaatuisen toimintaympäristön tutkimuksen tekemistä varten. 3

13 2 Konfiguraationhallinta IT-palvelunhallinnassa IT-palvelunhallinnassa konfiguraationhallinnan tarkoituksena on (Office of Government Commerce, 2007): Tunnistaa ja hallita konfiguraatioiden rakenneosia sekä kaikkia niihin liittyviä olennaisia komponentteja ja suhteita. Pitää kirjaa konfiguraatioiden rakenneosista sekä säilyttää rakenneosien oikeellisuutta koko palvelun elinkaaren ajan varmistaen, että vain oikeutettuja muutoksia tehdään ja oikeanlaisia komponentteja käytetään. Suojella konfiguraatioiden rakenneosien oikeellisuutta koko palvelun elinkaaren ajan. Varmistaa konfiguraatioiden oikeellisuus tarkalla ja eheällä konfiguraationhallintajärjestelmällä. Konfiguraationhallinnan tavoitteina ovat virheettömät palveluiden konfiguraatiot; konfiguraatioiden, kapasiteetin ja resurssien optimointi; tarkan konfiguraatiotiedon tarjoaminen oikeiden ratkaisujen tekemiseksi sekä liiketoiminnan ja asiakkaiden tavoitteiden tukeminen. Konfiguraationhallinnan päämäärinä ovat palveluiden ja ITinfrastruktuurin määrittäminen sekä kontrollin ja tarkan konfiguraatiotiedon ylläpitäminen näiden tukemiseksi (Office of Government Commerce, 2007). Konfiguraationhallinnan alaisuuteen kuuluvat varmistukset siitä, että kaikki osa-alueet palvelusta, järjestelmästä tai tuotteesta on hallittu riittävän hyvin, jotta kaikki tehdyt muutokset ovat mahdollisimman kontrolloituja. Konfiguraationhallinta myös varmistaa, että kaikki julkaisut on tehty oikein. Se luo loogisen mallin kaikista palveluista, omaisuuksista ja infrastruktuurista pitämällä yllä tietoa niiden kaikkien suhteista toisiinsa (Office of Government Commerce, 2007). Kuvassa 1 on esitetty esimerkki loogisesta konfiguraatiomallista. 4

14 Kuva 1. Esimerkki loogisesta konfiguraatiomallista (Office of Government Commerce, 2007, mukaillen). Konfiguraationhallinta tuo lisäarvoa liiketoiminnalle, sillä optimoimalla konfiguraatioita parannetaan yleistä palvelutasoa sekä samalla optimoidaan huonosti hallituista omaisuuksista johtuvia riskejä ja kuluja kuten palvelukatkoksia, sanktioita, ylimääräisiä lisenssimaksuja ja epäonnistuneita auditointeja. Vastaavasti konfiguraationhallinnan hyötyjä ovat muutosten ja julkaisujen parempi suunnittelu, ennustaminen ja julkaiseminen, häiriöiden ja ongelmien parempi ratkominen, palvelutasojen ja takuiden parempi toimitus sekä lakien, sääntöjen, velvollisuuksien ja standardien parempi noudattaminen. Hyvin toimivan konfiguraationhallinnan avulla muutokset ja jakelut voidaan tunnistaa, suunnitella ja toimittaa tuotantoon paremmin. Muita lisähyötyjä ovat: palveluiden riittävän tason takaaminen, jäljitettävyys ja helpompi palveluiden hinnoittelu (Office of Government Commerce, 2007). Konfiguraationhallinnan tavoitteena on tarjota luotettavaa ja ajantasaista tietoa ITinfrastruktuurista. Tämä tieto yleensä saadaan isojen IT-projektien tuotoksina. Tieto koostuu tarkoista konfiguraation rakenneosista sekä niiden välisistä yhteyksistä. CItietoa käytetään suunnitteluun, päätöksen tekemisen tukemiseksi ja muutosten 5

15 hallitsemiseksi. Nämä yhteydet luovat pohjan vaikuttavuuden arvioinnille, sillä konfiguraationhallinta tarkistaa, että IT-infrastruktuuriin tehdyt muutokset on tehty oikein ja valtuutetusti. Lisäksi konfiguraationhallinta varmistaa, että rakenneosien suhteet ja IT-komponenttien tilat on kirjattu oikein, minkä johdosta organisaatiolla on käytössään oikeat versiot kaikista sen rakenneosistaan (Office of Government Commerce, 2005; Bon, 2006). Konfiguraationhallinnan hyötyjä ovat muun muassa (Office of Government Commerce, 2005): IT-komponenttien parempi hallittavuus. Koska jokainen IT-palvelu koostuu yhdestä tai useammasta rakenneosasta, on tärkeää, että konfiguraationhallinta valvoo kaikkia sen ulottuvuuteen kuuluvia rakenneosia. Laadukkaiden IT-palveluiden tarjoaminen asiakkaille. Konfiguraationhallinta tukee käyttäjiä, helpottaa ongelmien tunnistamisessa ja korjaamisessa, muutosten käyttöönottamisessa sekä kaksoiskappaleiden vähentämisessä. Toimiva ongelmien ratkominen. Konfiguraationhallinta toimii suurena apuna viallisten rakenneosien löytämisessä sekä hallitsee kaikkia viallisille rakenneosille tehtyjä muutoksia tai korvauksia. Muutosten parempi käsittely. Konfiguraationhallinta luo pohjan toimivalle vaikutusanalyysille, joka taas vaikuttaa muutosten parempaan prosessointiin. Laitteistojen ja ohjelmistojen parantunut kontrolli. Laitteisto- ja ohjelmistopakettien julkaisut voidaan yhdistää, jotta kokonaisuutta pystyttäisiin testaamaan etukäteen. Testaus- ja jakelusuunnitelmien luomisessa voidaan käyttää konfiguraatiotietokantaa hyödyksi. Lisäksi konfiguraatiotietokanta sisältää tietoa luotettavista ohjelmistojen versioista varmuuskopiointia varten. Parempi turvallisuus. Tuotantoympäristössä olevia versioita hallinnoimalla saadaan tietoa rakenneosille tehdyistä oikeutetuista muutoksista sekä käytössä olevista ohjelmistoversioista. CI-tietoa voidaan myös käyttää hyödyksi lisenssien valvomisessa. 6

16 Laillisten vaatimusten noudattaminen. Auditoinneilla voidaan helposti tunnistaa ohjelmistojen laittomat kopiot, kun ohjelmistoja verrataan CMDB:ssä oleviin CI-tietoihin. Täten konfiguraationhallinta voi mahdollisesti estää uusien virusten pääsemisen organisaation sisälle. Lisäksi auditointi mahdollisesti vähentää laittomien ja saastuneiden ohjelmistojen pääsemistä organisaation sisälle työntekijöiden toimesta, kontrollin ja sanktioiden takia. Kustannusten tarkempi suunnittelu. Konfiguraationhallinta voi auttaa kustannusten paremmassa suunnittelussa konfiguraatiotietokannassa olevan CI-tiedon avulla koskien esimerkiksi huoltokustannuksia, sopimuksia tai lisenssejä. Tuki saatavuuden- ja kapasiteetinhallinnalle. Nämä prosessit luovat analyyseja ja edistävät palveluiden suunnittelua korrektin konfiguraatiotiedon avulla. Pohja hyvälle IT-palveluiden jatkuvuudenhallinnalle. Katastrofin sattuessa konfiguraatiotietokannalla on tärkeä rooli palveluiden palautumisessa sekä palautumista vaativien rakenneosien löytämisessä. 2.1 Konfiguraationhallinnan ydinkäsitteet Konfiguraationhallinta sisältää monia ydinkäsitteitä, jotka ovat tärkeitä ymmärtää, jotta saataisiin kokonaiskuva kyseisestä palvelunhallintaprosessista. Aliluvussa käsitellään konfiguraatiomallia, aliluvussa konfiguraationhallintajärjestelmää, aliluvussa konfiguraatiotietokantaa, aliluvussa konfiguraation rakenneosaa ja perustasoa, aliluvussa kriittisiä menestystekijöitä ja suorituskykymittareita sekä aliluvussa definitiivistä kirjastoa Konfiguraatiomalli Konfiguraationhallinnan määränpäänä on luoda konfiguraatiomalleja (Configuration Model, CM) organisaation IT-infrastruktuurista sekä sen kaikista palveluista, omaisuuksista, rakenneosista ja näiden välisistä yhteyksistä. Konfiguraatiomalli taas vuorostaan tukee muita palvelunhallintaprosesseja taaten näille pääsyn tärkeään ja 7

17 oikeelliseen tietoon. Tätä tietoa taas käytetään hyödyksi esimerkiksi häiriöiden selvittämisessä, ongelmien syiden etsimisessä ja niiden vaikuttavuuden arvioinnissa, esitettyjen muutosten arvioimisessa, palveluiden muuttamisessa, uusien palveluiden luomisessa, teknologisissa uudistuksissa ja ohjelmistopäivityksissä. Lisäksi konfiguraatiomalleja voidaan hyödyntää julkaisu- ja kehityspakettien luomisessa, palveluomaisuuksien siirtämisessä sekä omaisuuksien optimoimisessa. Konfiguraationhallinta siis luo loogisen mallin organisaation infrastruktuurista ja kaikista sen palveluista joita muut IT-palvelunhallinnan osat sitten käyttävät (Office of Government Commerce, 2007) Konfiguraationhallintajärjestelmä Konfiguraationhallintajärjestelmä (Configuration Management System, CMS) on konfiguraationhallinnan tukijärjestelmä, jolla hallitaan suuria ja monimutkaisia ITjärjestelmiä ja -infrastruktuureja. Konfiguraationhallintajärjestelmä koostuu kaikista organisaation sisällä olevista rakenneosista ja niiden välisistä suhteista. Nämä rakenneosat sisältävät muun muassa tarkentavaa tietoa IT-infrastruktuurin osista kuten tietoa ohjelmista, työasemista, palvelimista tai dokumenteista. Esimerkkinä tästä voisi olla työasema-rakenneosa, joka sisältäisi tietoa valmistajasta, mallista, tyypistä (tehokannettava, kevyt kannettava), tietoa lisensseistä ja huoltosopimuksista, sekä muuta dokumentaatiota kuten palvelutasosopimuksia ja ulkoisia tai sisäisiä hankintasopimuksia (Office of Government Commerce, 2007). Käytännössä konfiguraationhallintajärjestelmä pitää sisällään useita eri tietovarastoja (konfiguraatiotietokantoja), jonne organisaatiokohtaista tietoa tallennetaan. CMS voi ottaa tietonsa monesta eri fyysisestä CMDB:stä, sekä useista muista tietolähteistä. CMS tyypillisesti pitää sisällään kaikkia IT-infrastruktuurin rakenneosia ja tietoa muista lähteistä, jotka voidaan yhdistää liiketoiminnan eri osa-alueita kiinnostavien näkymien muotoon (Office of Government Commerce, 2007). 8

18 2.1.3 Konfiguraatiotietokanta Konfiguraatiotietokannat pitävät sisällään kaikki organisaation konfiguraation rakenneosat, joilla on merkitystä liiketoiminnalle. Konfiguraatiotietokannan tehtävänä on pitää kirjaa organisaation kaikista IT-komponenteista, niiden versioista ja tiloista sekä niiden välisistä suhteista. Konfiguraatiotietokannan olomuodot vaihtelevat organisaatioiden välillä. Yksinkertaisimmillaan konfiguraatiotietokanta voi koostua paperilomakkeista, laskentataulukoista tai sharepoint-listoista. Alla olevassa kuvassa (Kuva 2) on esitetty yksinkertainen Excelillä toteutettu CMDB. Kuva 2. Esimerkki Excel-pohjaisesta CMDB:stä (ServiceNow, 2018b). Hieman monimutkaisempi versio konfiguraatiotietokannasta koostuisi esimerkiksi useammasta fyysisestä tietokannasta, jotka yhdessä muodostaisivat loogisen kokonaisuuden organisaation IT-infrastruktuurista. Konfiguraatiotietokannan tyyppisiä tietokantoja käytetään myös mm. kehitysosastojen toimesta ohjelmamoduulien versionhallintaan (Office of Government Commerce, 2005). 9

19 2.1.4 Konfiguraation rakenneosa ja perustaso Konfiguraation rakenneosa on jokin konfiguraationhallinnan kontrollissa oleva palvelun komponentti, omaisuus, fyysinen artefakti tai muutospyyntö, joka liittyy ITinfrastruktuuriin komponenttiin tai johonkin muuhun liiketoiminnan tärkeään osaan. Rakenneosat voivat olla hyvin erilaisia. Oli sitten kyse isoista käsitteistä kuten esimerkiksi palveluista tai järjestelmistä tai pienemmistä käsitteistä kuten ohjelman yksittäisestä moduulista tai pienestä laitteiston osasta. Konfiguraation rakenneosia voidaan yhdistää ja hallita esimerkiksi julkaisun muodostamiseksi. Konfiguraation rakenneosien käsitteleminen on tarkkaa. Niitä käsitellessä tulisi niiden valintakriteerit, yhdistettävyys, luokittelu ja tunnistaminen olla toteutettu siten, että ne olisivat helposti hallittavissa ja jäljitettävissä koko palvelun elinkaaren ajan. Konfiguraation rakenneosia on eri tyyppisiä, kuten (Office of Government Commerce, 2007; Office of Government Commerce, 2002a) palvelun elinkaaren konfiguraation rakenneosat palvelun konfiguraation rakenneosat organisaation konfiguraation rakenneosat sisäiset konfiguraation rakenneosat ulkoiset konfiguraation rakenneosat rajapinnan konfiguraation rakenneosat. Palvelun elinkaaren konfiguraation rakenneosalla tarkoitetaan rakenneosaa, joka kohdistuu johonkin tiettyyn palvelun elinkaaren (palvelustrategia, palvelusuunnittelu, palvelutransitio, palvelutuotanto, palvelun jatkuva parantaminen) vaiheeseen. Konfiguraation perustaso (Configuration Baseline, CB) on jonkin tuotteen, palvelun tai IT-infrastruktuurin konfiguraatio, joka on katselmoitu huomioiden, että jatkoaktiviteetin perustasoa voidaan muuttaa vain muutosprosessien kautta. Konfiguraation perustason keskeisenä ajatuksena on kirjata konfiguraation rakenne, sisältö ja yksityiskohdat sekä esittää kaikki siihen liittyvät CI-yhteydet. Konfiguraation perustason määrittäminen mahdollistaa (Office of Government Commerce, 2007) 10

20 tärkeän tapahtuman merkitsemisen palvelun kehitysvaiheessa palvelukomponentin rakentamisen määritetyistä syötteistä tietyn version muuttamisen tai uudelleen rakentamisen myöhemmällä ajanjaksolla kaikkien tärkeiden komponenttien yhdistämisen muutosta tai julkaisua varten konfiguraatioiden auditointien tai perumisien perusteiden tarjoamisen Kriittiset menestystekijät ja suorituskykymittarit Kriittiset menestystekijät (Critical Success Factors, CSF) määrittävät palvelunhallinnan tärkeimmät hallittavat kohteet (strategisesti, teknisesti ja organisaatio- tai prosessitasolla), jotta saavutettaisiin kontrolli kaikista organisaation IT-prosesseista (Sallé, 2004). Konfiguraationhallinnan kriittisiä menestystekijöitä ovat (Office of Government Commerce, 2007; Office of Government Commerce, 2002b; Brooks, 2006) tiedon kerääminen ja ylläpitäminen potentiaalisten epäonnistumisen kohtien tunnistaminen oikeellisen tarkkuuden määrittäminen konfiguraationhallinnan tukeminen automatisoidulla teknologialla IT-omaisuuksien hallinnointi IT-palveluiden tukeminen palveluiden taloudellinen toimittaminen muiden ITSM-prosessien tukeminen asiakastyytyväisyys. Keskeiset suorituskykymittarit (Key Performance Indicators, KPI) ovat yleensä mitta jostain kriittisestä menestystekijästä, jonka avulla voidaan mahdollisesti parantaa jotain tiettyä prosessia. Keskeiset suorituskykymittarit ovat yleensä ytimekkäitä ja mitattavia elementtejä jonkun prosessin suorituskyvystä suhteessa siihen, kuinka hyvin prosessi saavuttaa sille annetut tavoitteet (Sallé, 2004). Konfiguraationhallinnan suorituskykyä tulisi tarkkailla, raportoida ja jatkuvasti parantaa, jotta palveluomaisuuksien ja konfiguraatioiden kustannuksia ja suorituskykyä voitaisiin 11

21 paremmin optimoida. Tätä varten seuraavia keskeisiä suorituskykymittareita tulisi hallita (Office of Government Commerce, 2007; Office of Government Commerce, 2002b; Brooks, 2006) CI-komponenttien korjaamiseen ja palauttamiseen kuluva aika palveluhäiriöiden lukumäärä virheellisten rakenneosien tunnistamisen ja palveluiden palauttamisen taso häiriöiden ja virheiden vaikutukset rakenneosiin auditointien lukumäärä ja taso konfiguraatiotiedon laadun ja oikeellisuuden taso ihmisten aiheuttaman virheellisen konfiguraatiotiedon lukumäärä häiriöiden ja ongelmien tunnistamiseen kuluva aika ja resurssit valtuuttamattomien muutosten lukumäärä oikein auditoitujen rakenneosien lukumäärä väärästä CI-tiedosta johtuvien palveluvirheiden lukumäärä asiakastyytyväisyyden taso suhteessa palveluihin ja laitteistoon kadonneiden ja kopioituneiden rakenneosien lukumäärä huoltokustannusten ja lisenssimaksujen budjetissa pysyminen rakenneosien ja konfiguraatiotietokannan ylläpitämiseen menevät kulut virheellisestä konfiguraatiotiedosta johtuvien muutosten epäonnistumisien lukumäärä väiriöiden selvittämiseen kuluva aika tarkemmat tulokset riskianalyysiauditoinneilla käyttämättömien lisenssien lukumäärä huonosta CMDB-tiedosta seuranneiden epäonnistuneiden muutosten lukumäärä luvattomien konfiguraatioiden lukumäärä häiriöiden lukumäärä johtuen väärin dokumentoiduista rakenneosista konfiguraatiotietokannan virheistä johtuneiden palvelutasosopimusrikkomusten määrä muutospyynnöt, joihin ei ole päivitetty CI-tietoja 12

22 virheellisten konfiguraation rakenneosien prosentuaalinen osuus. Taulukossa 1 on annettu esimerkki konfiguraationhallinnan kriittisistä menestystekijöistä, avainsuorituskykyindikaattoreista ja mittareista. Taulukko 1. Esimerkki häiriönhallinnan CSF-KPI-Mittari -taulukosta (ServiceNow, 2018a, mukaillen) CSF Ylläpidä IT-palvelun laatua KPI #1 Kohdistettu prosenttimäärä ajallaan selvitettyjä häiriöitä prioriteetin mukaan Mittari Häiriöt, jotka on ratkaistu SLA:n puitteissa prioriteetti tasoittain Taulukossa 2 esitetään kysymyksiä, joita tulisi pohtia, kun rakennetaan CSF-KPI- Mittari -taulukkoa. Taulukko 2. Kysymyksiä CSF-KPI-Mittari -taulukon rakentamiseen (ServiceNow, 2018a, mukaillen) Kysymys Perusteltu vastaus Miksi häiriönhallinta on tärkeää ja mitä se Se mahdollistaa kyvyn häiriöiden kertoo meille? käsittelemiseen oikeassa priorisoidussa järjestyksessä, se takaa parantuneen häiriönhallintaprosessin sekä paremman asiakastyytyväisyyden. Miten sitä voidaan mitata ja analysoida? Tarkastelemalla häiriöraportteja prioriteettimallia ja SLA:n sovittuja suoritusaikoja vasten. Kuinka usein häiriönhallintaprosessia tulisi mitata? Kuinka tuloksia tulisi esitellä ja jakaa? Kuinka tulosten analysointi voisi auttaa jatkuvan parantamisen prosessia? Kuinka suoriutumisen mittareita voidaan asettaa ja tarkastella? Aluksi viikottain, sitten kuukausittain. Kriittisten asiakkaiden kohdalla mittausta voidaan suorittaa useammin. Esittelyssä tulisi käyttää taulukoita ja graafeja, jakamisessa pitäisi huomioida tarkempi häiriöiden analysoiminen. Tunnistamalla heikkoja kohtia prioriteettimallissa tai tarpeissa esimerkiksi SLA:n tarkentamiseksi. Määritellään suoriutumisen mittarit SLA:ssa ja tarkastellaan niitä sen mukaisesti Definitiivinen mediakirjasto Definitiivinen mediakirjasto (Definitive Media Library, DML) on turvallinen kirjasto, joka sisältää kaikki tallennetut ja suojellut lopulliset versiot kaikista mediarakenneosista. Sinne tallennetut kopiot ovat alkuperäisiä versioita rakenneosista, jotka ovat menneet laadunvarmistuksen tarkastusten läpi. Definitiivinen mediakirjasto 13

23 koostuu yhdestä tai useammasta kirjastosta tai tiedontallennusalueesta sisältäen alkuperäiset kopiot kaikista ostetuista ja organisaation sisällä kehitetyistä ohjelmistoista sekä erilaisista dokumentaatioista elektronisessa muodossa (Office of Government Commerce, 2007). Definitiivisen mediakirjaston käsitteeseen sisältyy myös fyysinen tallennuspaikka kaikille alkuperäisille kopioille, jotta kyseiset kopiot selviäisivät esimerkiksi mahdollisen tulipalon syttyessä ja tulipalon tuhotessa elektronisen definitiivisen kirjaston. Konfiguraationhallinta kontrolloi vain sallitun median sisällytystä definitiiviseen kirjastoon. Tämä sallittu media definitiivisessä kirjastossa luo perusteet julkaisun- ja käyttöönotonhallinnalle. Definitiivisen mediakirjaston konfiguraation suunnittelussa tulisi ottaa seuraavia asioita huomioon (Office of Government Commerce, 2007) käytettävät laitteistot ja ohjelmisto, fyysinen sijainti ja tiedotusvälineet tallennusalueiden ja fyysisen median käytäntöjen nimeäminen definitiivisen kirjaston tukemat ympäristöt turvallisuusjärjestelyt koskien muutoksia, dokumentaatioita ja ohjelmistoja sekä näihin liittyvät varmuuskopiot sekä palauttaminen definitiivisen kirjaston ulottuvuus säilytyksen ja arkistoinnin ajanjaksot auditoinnin prosessit definitiivisen kirjaston virheiltä ja epäoikeutetuilta muutoksilta suojaavat prosessit definitiivisen kirjaston kapasiteettisuunnitelmat ja kasvun tarkkailu. 2.2 Konfiguraationhallinnan suunnittelu ja hallinta Konfiguraationhallinnan pääaktiviteetteja ovat (Office of Government Commerce, 2005): 14

24 Suunnittelu. Määrittää strategian, käytännöt ja prosessin tavoitteet, tiedon analysoinnin, työkalujen ja resurssien löytämisen, rajapintojen luomisen, projektit sekä toimittajat. Tunnistaminen. Määrittää prosessit, joilla tietokantaa pidetään ajan tasalla. Näihin prosesseihin kuuluu tietomallin kehittäminen komponenttien ja niiden välisten suhteiden, tilojen ja dokumentaation tallentamiseksi sekä prosessit uusille rakenneosille ja niiden muutoksille. Hallinta. Konfiguraatiotietokannan ajantasaisuuden varmistaminen oikeutettujen CI-lisäysten, tallennuksien ja valvonnan avulla. Hallinta varmistaa, että CI-muutoksia ei tapahdu ilman asianmukaisia toimenpiteitä. Rakenneosien tilojen valvonta. Nykyisten ja menneiden tilojen tallentaminen rakenneosien elinkaarten aikana esimerkiksi tilojen muutosten tunnistamiseksi. Esimerkkejä tiloista ovat Kehityksessä, Testattavana, Varastossa, Tuotannossa sekä Lopetettu. Vahvistus. Konfiguraatiotietokantaa auditoimalla vahvistetaan tallennettujen rakenneosien olemassaolo ja tietokannan oikeellisuus. Raportointi. Tiedon tarjoaminen muille prosesseille sekä rakenneosien kehityksistä ja trendeistä raportoiminen. Konfiguraationhallinnan suunnittelussa tulisi ainakin seuraavat asiat ottaa huomioon (The art of service, 2007) konfiguraationhallinnan tavoitteet, ulottuvuus ja päämäärä standardit, käytännöt ja prosessit, jotka liittyvät konfiguraationhallintaan ja tulisi ottaa huomioon roolit ja vastuut konfiguraationhallinnan sisällä rakenneosien yksilöinti kaikki konfiguraationhallintaprosessin suorittamiseen liittyvät asiat, jotka liittyvät rakenneosien tunnistamiseen, kontrollointiin, tilojen määrittämiseen, auditoimiseen ja vahvistamiseen rajapintojen kontrollointi muiden osa-alueiden kuten muutoksenhallinnan ja jakelunhallinnan kanssa 15

25 konfiguraationhallintajärjestelmän kattavuuden ja sen rajapintojen määrittäminen ja suunnitteleminen. Tilojen kirjaamisessa ja raportoinnissa, rakenneosan elinkaari luokitellaan eri vaiheisiin. Esimerkiksi julkaisu menee elämänsyklissään seuraavat vaiheet läpi: rekisteröity, hyväksytty, asennettu ja peruttu. Tilaraportit antavat tietoa nykyisistä ja menneistä CI-tiedoista sekä tilamuutoksista. Erilaisia konfiguraatioraportteja tarvitaan konfiguraationhallinnassa. Raportit voivat liittyä yksittäisiin rakenneosiin tai kokonaisiin palveluihin. Tällaiset raportit voivat koostua muun muassa: rakenneosista ja niiden perustasoista, nykyisistä tiloista ja muutoshistoriasta, valtuuttamattomista rakenneosista tai epäoikeutetuista laitteistojen tai ohjelmistojen käytöistä (Bon et al., 2007). Vahvistamisessa ja auditoinnissa konfiguraationhallinta tekee auditointeja, jotta vältettäisiin ristiriitaisuudet dokumentoitujen perustasojen ja todellisten konfiguraatioiden välillä. Kaikki poikkeukset, jotka havaitaan auditoinnin yhteydessä, tulisi dokumentoida ja niistä tulisi raportoida eteenpäin. Korjaustoimenpiteet tapahtuvat muutoksenhallinnan johdosta. Auditointeja suoritetaan esimerkiksi: CMDB:ssä tapahtuvia muutoksia ennen ja niiden jälkeen, sattumanvaraisesti ja valtuuttamattomien rakenneosien löytämisien jälkeen (Bon et al., 2007). 2.3 Konfiguraationhallinnan tietokannat Konfiguraationhallintajärjestelmän käyttötarkoitus on monipuolinen. Esimerkki tästä voisi olla konfiguraationhallintajärjestelmän sisällä oleva tieto, jota käytetään finanssipuolen omaisuudenhallintajärjestelmälle tarkkojen omaisuudenhallintaprosessien raportoimiseksi. Konfiguraationhallintajärjestelmä sisältää tietoa rakenneosista ja niiden välisistä suhteista sekä kaikista niihin liittyvistä häiriöistä, ongelmista, tunnetuista virheistä ja julkaisudokumenteista. Konfiguraationhallintajärjestelmään voidaan sisällyttää myös muuta organisaatiota koskevaa tietoa kuten tietoja työntekijöistä, toimittajista, asiakkaista ja käyttäjistä (Office of Government Commerce, 2007). Konfiguraationhallintajärjestelmä koostuu 16

26 yleensä neljästä kerroksesta: Esittelykerros (joka sisältää eri näkymiä eri ryhmille), tiedon prosessointikerros (raporttien ja kyselyiden luominen), tiedon integraatiokerros (tiedon koonti ja järjestäminen) ja tietokerros (sisältää tietoa eri lähteistä kuten konfiguraatiotietokannasta, havainto- ja inventointityökaluilta tai projektitietoa) (Bon et al., 2007). Konfiguraationhallintajärjestelmä voi saada tietoa useammasta fyysisestä konfiguraatiotietokannasta, jotka yhdessä muodostavat federoidun konfiguraatiotietokannan (Federated Configuration Management Database, FCMDB). Muina tietolähteinä konfiguraationhallintajärjestelmä käyttää esimerkiksi definitiivisiä mediakirjastoja. Konfiguraationhallintajärjestelmä pyrkii siihen, että sen tietokannoissa olisi mahdollisimman paljon liiketoiminnan kannalta olennaista ja päivitettyä tietoa, ilman kahdennuksia. Palveluiden kehittyessä niiden elinkaaren aikana kehittyy myös niiden konfiguraatiotieto. Tämä tieto yhdistetään integroiduiksi tietueiksi, jota eri sidosryhmät käyttävät koko palvelun elinkaaren ajan. Tämän takia konfiguraationhallintajärjestelmän tulee rakentua oikeanlaisen tiedon ympärille toimittaakseen muille palvelunhallintaprosesseille tilanteeseen sopivat kysely- ja raportointityökalut käytettäväksi (Office of Government Commerce, 2007). Nykypäivän isoissa ja monimutkaisissa järjestelmissä ei organisaatioiden ole järkevää ylläpitää vain yhtä konfiguraatiotietokantaa, koska tämän skaalautuvuuden rajat tulisivat nopeasti vastaan. Tämän takia organisaatioiden olisi järkevää pitää osaa rakenneosatiedoistaan paikallisesti tallennetuissa paikoissa ja loppuja tietojaan etäisellä tallennuspaikalla. Tiedon tallennuspaikan ei tulisi näkyä loppukäyttäjälle, vaan tietoon pitäisi päästä käsiksi nopeasti ja vaivattomasti yhden rajapinnan kautta (Keel et al., 2007). Alla olevassa kuvassa (Kuva 3.) on mallinnettu IT-infrastruktuuri, joka voidaan lisätä konfiguraatiotietokantaan. 17

27 Tulostin Tietokone-1 Tietokone-11 Modeemi Tietokone-3 Tietokone-2 Tietokone-10 Tietokone-4 Palvelin Tietokone-9 Kannettava tietokone-1 Reititin Tietokone-5 Tietokone-7 Tietokone-8 Käyttäjä Kannettava tietokone-2 Kannettava tietokone-3 Kuva 3. Esimerkki IT-infrastruktuurin mallintamisesta (Servicetonic, 2018, mukaillen). Monilla organisaatioilla on jo käytössään tiettyjä elementtejä konfiguraationhallinnasta, kuten arkistot dokumenteista, laskentataulukoita tai paikallisia tietokantoja, joita voidaan käyttää konfiguraationhallintajärjestelmässä. Konfiguraatiotietokantojen lataamiseksi ja ylläpitämiseksi tulisi kehittää automatisoituja prosesseja, joilla voitaisiin vähentää virheiden määrää sekä optimoida kustannuksia. Erilaisia työkaluja kuten havainnointityökaluja, auditointityökaluja ja verkonhallintatyökaluja voidaan käyttää, jotta konfiguraatiotietokannat saataisiin täytettyä. Näitä työkaluja voidaan myös käyttää konfiguraatiotiedon vertaamiseen konfiguraationhallintajärjestelmän ja tuotantoympäristön välillä (Office of Government Commerce, 2007). Koska muut ITSM-prosessit (kuten häiriön-, ongelman-, muutoksen-, julkaisun-, palveluntason- ja saatavuudenhallinta) hyödyntävät konfiguraatiotietokannan tietoa, tulee tiedon, jolla konfiguraatiotietokanta toteutetaan (konfiguraatiotietokannan ulottuvuus), olla tarkasti määritetty. Tämän määrittämiseksi tulisi organisaatioiden miettiä, mitkä kaikki asiat sisällytetään konfiguraatiotietokannan ulottuvuuteen. 18

28 Otetaanko kaikki laitteisto kuten tulostimet, näytöt, näppäimistöt tai henkilökunta mukaan? (Office of Government Commerce, 2005). Konfiguraatiotietokantaa ei tulisi nähdä pelkästään tietokantana, joka sisältää tietoa organisaation rakenneosista, vaan ratkaisuna, joka mahdollistaa kriittisten liiketoimintafunktioiden toteuttamisen IT:n tuella (BMC Software, 2005). Konfiguraatiotietokanta on paljon muuta kuin vain tietokanta, johon tallennetaan tietoa eri laitteistojen ja ohjelmistojen rakenneosista. Todellinen konfiguraatiotietokanta on meta-tietokanta tai tietokantojen tietokanta. Se tarjoaa kontekstia IT-infrastruktuurin sisällön kuvauksien kartoittamiseen, jotka on tallennettu muihin tietokantoihin. Jotkut organisaatiot pitävät konfiguraatiotietokantoinaan Excel-taulukoita, itse luotuja relationaalisia tietokantoja tai Visiolla luotuja kaavioita, kun taas todellinen konfiguraatiotietokanta on definitiivinen. Toisin sanoen, konfiguraatiotietokannan sisällä olevaa tietoa ei tulisi tarvita varmistaa tai todentaa. Konfiguraatiotietokannan tarkoituksena on olla uskottava lähde konfiguraation rakenneosille (Marquis, 2007). Konfiguraatiotietokanta täytetään erilaisilla rakenneosilla, jotka voivat olla esimerkiksi: fyysisiä artefakteja, IT-omaisuutta, -palveluita ja näiden komponentteja, turvallisuuskomponentteja tai dokumentaatiota kuten palvelutasosopimus, proseduureja, ohjekirjoja, teknisiä määrittelyjä, organisaatiokarttoja, lisenssejä, ihmisiä ja projektisuunnitelmia. Konfiguraatiotietokannassa sijaitsevat rakenneosat sijaitsevat fyysisesti jossain muualla. Konfiguraatiotietokantaan lisättävät rakenneosat sisältäisivät versionumeron, julkaisupäivän, tekijän sekä muun tarpeellisen tiedon (Office of Government Commerce, 2005; Bon, 2006). Konfiguraatiotietokannan tarkkuuden parantamiseksi tulisi kaikki siihen liittyvät virheet tunnistaa ja laskea. Varmin tapa löytää virheitä olisi tehdä pistotarkistuksia tai tieto-auditointeja konfiguraatiotietokannalle. Toisin sanoen konfiguraatiotietokannassa olevaa tietoa verrataan muihin tietoihin (kuten havainnointityökalun tietoihin) virheiden löytämiseksi (Klosterboer, 2007). Kuvassa (Kuva 4.) on listattu konfiguraatiotietokannan virheiden havainnointikeinoja. 19

29 Kuva 4. Virheiden aktiivinen etsiminen konfiguraatiotietokannasta (Klosterboer, 2007, mukaillen). Pistokokeen otoskoon tulisi kattaa 5 prosenttia tietokannan koosta. Jos virheitä ei löydetä, voidaan tätä otoskokoa pienentää ja jos virheitä löydetään, voidaan sitä kasvattaa, kunnes virheitä aiheuttavat syyt löydetään. Joka kerta kun muutosta ehdotetaan, tulisi arvioida miten muutos vaikuttaa konfiguraatiotietoihin. Usein muutoksen ehdotuksen yhteydessä mahdollisia virheitä paljastuu konfiguraatiotietoa tarkastellessa. Yleensä häiriön ilmetessä sitä hoitavat henkilöt paneutuvat syvälle organisaation tiettyyn osa-alueeseen. Tällöin olisi hyvä panostaa löydösten vertaamiseen CMDB-tietoja vasten. Mitä useampi henkilö tuntee olevansa vastuussa konfiguraatiotietokannan tarkkuudesta, sitä tarkempi se tulee olemaan (Klosterboer, 2007). Kaikki rakenneosista johtuvat häiriöt on mahdollista paikantaa nopeasti konfiguraatiotietokannassa olevan tiedon perusteella, koska sen sisälle on tallennettu IT-infrastruktuurin rakenneosat ja niiden väliset suhteet. Konfiguraatiotietokannassa sisältävästä tiedosta voidaan luoda palveluraportteja, joita voidaan käyttää esimerkiksi 20

30 palveluiden parantamiseksi. Esimerkkinä tästä voisi olla yhden palvelun rakenneosien seuraaminen konfiguraatiotietokannassa, joka voisi mahdollisesti paljastaa meille, että kyseinen palvelu ei olisi täysin konfiguraatiotietokannan ulottuvuuden sisällä (jotain rakenneosaa esimerkiksi tarjottaisiin ulkoisen toimittajan puolesta, eikä sitä olisi kirjattu konfiguraatiotietokantaan). Tämä kyseinen palvelu ei olisi täysin tuettu ja sen puuttuvat rakenneosat tulisi liittää konfiguraatiotietokantaan ja sen ulottuvuuteen (Office of Government Commerce, 2005). Kun konfiguraatiotietokannan laajuus on määritetty oikein, voidaan määrittää rakenneosien elinkaarten elementit. Tärkeä päätös tässä vaiheessa on päättää, että otetaanko keskeneräiset rakenneosat konfiguraatiotietokantaan vai ei. Mukaan ottaminen takaisi paremman kontrollin rakenneosia koskeviin muutoksiin ja niiden siirtyminen tuotantoympäristöön sujuisi sulavammin. Toisaalta tämä kuormittaisi rakenneosien tilojen valvontaa ja mahdollisesti laajentaisi konfiguraationhallinnan ulottuvuutta suhteessa tuotteen elinkaareen (Office of Government Commerce, 2005). Konfiguraatiotietokannan avulla organisaatiot pystyvät paremmin kohdistamaan ITresurssejaan tukemaan liiketoimintojensa tarpeita. Konfiguraatiotietokanta auttaa organisaatioita hallitsemaan IT-infrastruktuuria asiakaskeskeisestä näkökulmasta, koska konfiguraatiotietokannasta saatava tieto auttaa pitämään tarjottujen palveluiden tason optimaalisella tasolla. Konfiguraatiotietokannan avulla varmistetaan rakenneosien kontrollointi ja saavutetaan valmius auditoinnille. Näin konfiguraatiotietokanta luo pohjaa muiden IT-palvelunhallintaprosessien toteuttamiselle ja käyttöönotolle (BMC Software, 2005). 2.4 Hyödyt muille palvelunhallintaprosesseille Konfiguraationhallinnan tarkoituksena on tukea muita palvelunhallintaprosesseja kuten häiriön-, ongelman-, muutoksen-, riskien- ja julkaisunhallintaa tarjoamalla tarkkaa ja oikeellista tietoa konfiguraatioista ja niiden dokumentaatioista (The art of service, 2007). 21

31 Jotta häiriöitä voidaan kirjata oikein, häiriönhallintaa (Incident Management, IM) suorittavat henkilöt, esimerkiksi palvelupisteen (Service Desk, SD) ammattilaiset tarvitsevat pääsyä CI-tietoihin rakenneosan fyysisen sijainnin ja omistajan tunnistamiseksi, jotta tunnetut virheet tai ongelmat voitaisiin linkittää tiettyyn rakenneosaan. Sama koskee asiakkaiden, palveluiden ja palvelutasosopimusten liittämistä tiettyihin rakenneosiin (Office of Government Commerce, 2005). Ongelmanhallinta (Problem Management, PB) tarvitsee CMDB-tietoa ja rakenneosia, jotta se voisi linkittää ongelmat ja tunnetut virheet niitä aiheuttaviin rakenneosiin sekä analysoida niitä. Muutoksia ja virheitä löydetään, kun konfiguraatiotietokannassa sijaitsevaa konfiguraatiotietoa verrataan IT-infrastruktuurissa sijaitsevaan todelliseen konfiguraatioon (Office of Government Commerce, 2005). Muutoksenhallinta (Change Management, CM) tunnistaa toimenpantujen muutosten vaikuttavuutta konfiguraatiotietokannan avulla. Muutoksenhallinta valtuuttaa muutokset ja liittää muutokset niihin liittyviin rakenneosiin. Muutoksenhallinnan vastuulla on myös muutospyyntöjen tallentaminen ja täten sillä on suurin vastuu konfiguraatiotietokannan päivityksiin liittyen. Muutoksenhallinta on tärkeä onnistuneen konfiguraationhallinnan kannalta (kuten myös toisinpäin) (Office of Government Commerce, 2005; Johnson et al., 2007). Jakelunhallinta (Release Management, RM) tarjoaa tietoa rakenneosien versioista ja niiden tiloista kuten julkaisusuunnitelmia sekä tietoa toteutetuista muutoksista. Julkaisunhallinta tarvitsee konfiguraationhallinnalta tietoa rakenneosien tiloista, sijainneista tai lähdekoodien sijainneista definitiivisessä mediakirjastossa muutoksien toteuttamiseksi (Office of Government Commerce, 2005). Palvelutasonhallinta (Service Level Management, SLM) tarvitsee tietoa palveluista ja niiden välisistä yhteyksistä IT-infrastruktuurin rakenneosiin. SLM-tietoa voidaan tallentaa konfiguraatiotietokantaan ja linkittää siihen liittyviin rakenneosiin. Palvelutaso voidaan tallentaa sitä vastaaviin palvelu-tyyppisiin rakenneosiin, laitteiston komponentteihin tai ohjelmisto-rakenneosiin (Office of Government Commerce, 2005). 22

32 Taloushallinto (Financial Management, FM) tarvitsee tietoa palveluista ja rakenneosista, esimerkiksi tunnistamaan mikä osasto käyttää mitäkin prosessointipalveluita tai että kenellä on hallussaan joku tietty tietokone. Se yhdistää tämän tiedon palvelutasosopimuksessa sijaitsevan tiedon kanssa veloitettavien kulujen määrittämiseksi. Tällä prosessilla myös monitoroidaan IT-komponentteja ja ITomaisuutta kuten lisenssejä (Office of Government Commerce, 2005). Saatavuudenhallinta (Availability Management, AM) tarvitsee konfiguraatiotietokannassa olevaa tietoa rakenneosista, tunnistaakseen mitkä rakenneosat ovat yhteydessä mihinkin palveluun ja tehdäkseen komponentin vikaantumisen vaikutusanalyysin (Component Failure Impact Analysis, CFIA). Saatavuudenhallinta tekee suunnitelmia muutoksille tunnistettujen heikkouksien parantamiseksi. Konfiguraationhallinta tarjoaa tietoa palvelun koostumuksesta ja sen jokaisesta elementistä (Office of Government Commerce, 2005). IT-palveluiden jatkuvuudenhallinta (IT Service Continuity Management, ITSCM) käyttää konfiguraatioiden perustasoja konfiguraatiotietokannassa tarkentaakseen katastrofista palautumisen vaatimuksia ja varmistaakseen, että nämä konfiguraatiot ovat saatavilla katastrofista palautumisen yhteydessä. Laadunvarmennustarkastuksen läpäisseitä alkuperäisiä kopioita kaikista organisaation rakenneosista säilytetään sekä fyysisessä että elektronisessa DML:ssä palautumista varten (Office of Government Commerce, 2005; Office of Government Commerce, 2007). Kapasiteetinhallinta (Capacity Management, CM) tarvitsee tietoa konfiguraatiotietokannasta suunnitellakseen IT-infrastruktuurin optimointia, jakaakseen työtaakkaa ja kehittääkseen kapasiteettisuunnitelman (Office of Government Commerce, 2005). Tietoturvan hallinta (Information Security Management, ISM) vaatii, että konfiguraatiokannassa oleva tieto on oikeellista ja riittävästi suojeltu korruptioilta tai muutoksien vaikutuksilta. Konfiguraationhallinta auttaa tietoturvan hallintaa tarjoamalla oikeellista tietoa rakenneosista, joita voidaan käyttää hyödyksi kun järjestelmien, palveluiden ja palvelukomponenttien hyväksyttäviä riskitasoja 23

33 arvioidaan (ISO/IEC, 2012b). Konfiguraationhallinnan riippuvuudet ja hyödyt suhteessa muihin IT-palvelunhallintaprosesseihin on kuvattu kuvassa (Kuva 5.). Liiketoiminnan arvioiminen Asiakkaiden hallinta Muutoksenhallinta Häiriönhallinta Käyttöpalvelun hallinta IT-strategian kehittäminen CMDBkysely CMDB:n datan päivitys Muutostietue CIattribuutit ja -suhteet Työnumero Kustannusdataa Muutospyyntö Työnumeron status CMDB:n datan päivitys CMDBkysely CMDBkysely CMDB:n datan päivitys Ongelman hallinta CIattribuutit ja -suhteet Kustannus dataa Kustannusdataa Konfiguraationhallinta Kustannusdataa Palvelun mittaridataa CIattribuutit ja -suhteet Palvelusuunnittelu CMDB:n datan päivitys Palvelun toimintakyvyn dataa CMDB:n datan päivitys Kustannusdataa CIattribuutit ja -suhteet Palvelutasonhallinta CMDBkysely CMDBkysely CIattribuutit ja -suhteet Komponenttien käyttödataa Resurssien toimintakyvyn dataa Rakenna ja testaa Julkaise tuotantoon Saatavuuden hallinta Kapasiteetin hallinta Kulujen hallinta Tuotantoympäristö Laukaisija Syöte/tuotos Kuva 5. Konfiguraationhallinnan hyödyt muille ITSM-prosesseille (Ying et al., 2009, mukaillen). 2.5 Konfiguraationhallinnan haasteet Kaikista ITIL:n palvelunhallinnanprosesseista konfiguraationhallintaa voidaan pitää yhtenä vaikeimmista prosesseista ottaa käyttöön ja suorittaa oikein. Myös digitalisaation myötä nopeasti muuttuvat IT-ympäristöt ja liiketoiminnan muuttuvat 24

34 tarpeet tuovat konfiguraationhallinnalle lisähaasteita esimerkiksi uusien palveluiden ja näiden rakenneosien syntymisien kasvavasta tahdista, joka näkyy taas tiedon suurenemassa määrässä. Tiedon valtavan määrän hallinta onkin yksi konfiguraationhallinnan suorittamisen suurista haasteista. Tästä johtuen joutuvat palvelunhallinnan ammattilaiset miettimään esimerkiksi seuraavaa kysymystä: Miten CI-tieto olemassa olevista järjestelmistä saadaan siirrettyä uuteen ITSMjärjestelmään? Jopa pienillä yrityksillä on tuhansia yksilöllisiä tietueita ja niiden välisiä suhteita seurattavanaan, ja isoilla yrityksillä tietueiden määrä nousee miljooniin. Tämä tiedon määrä itsessään luo haasteita konfiguraatiotietokannan luomiselle ja toteutumiselle. Mitä tietueita lasketaan mukaan? Mitä teknologista tietämystä tarvitaan tietueiden laskemiseksi ja vielä oikeassa järjestyksessä? Miten tietueet kategorisoidaan, jos potentiaalisia kategorisointeja on useita erilaisia? Tästä käy selväksi, että konfiguraatiotietokannan luominen ja ylläpitäminen on haastavaa tiedon määrän ja sen kategorisoinnin takia (Klosterboer, 2007). Hyvänä esimerkkinä tästä on uutisoitu artikkeli Elisan kaivinkonetapauksesta Ruotsissa (Tivi, 2014). Kun kaivinkone nirhaisi runkokaapelin, syntyi siitä jälkiseurauksia nettiyhteyden tarjoamiseen johtuen virheellisestä konfiguraatiotiedosta. Inhimillisen virheen takia varayhteys ei lähtenytkään automaattisesti päälle, vaan se piti käynnistää manuaalisesti. Tästä koitui pidennetty palveluhäiriö Elisalle. Elisa korjasi palveluhäiriön, pyysi anteeksi asiakkailtaan ja lupasi tulevaisuudessa parantaa konfiguraationhallintaansa. Toinen esimerkki tästä on uutisoitu tapaus Amazonin pilvipalveluiden vioista ja sen aiheuttaneesta konfiguraatio-ongelmasta. Pilvipalvelut hidastuivat ja jotkin ylläpidetyt verkkopalvelut, kuten Foursquare ja Reddit kaatuivat tai vastasivat hitaasti. Tämä johtui siitä, että tietoliikenne ohjattiin vahingossa kulkemaan pienemmän kapasiteetin yhteyksien kautta. Asiakaskuntaa tyydyttääkseen Amazon julkaisi 5700 sanaisen dokumentin tapauksesta, joka vastaanotettiin hyvin asiakkaiden keskuudessa (Tivi, 2011). 25

35 Dynaamiset ympäristöt. IT-ympäristöjen jatkuvat muutokset ja näiden muutosten hajaantunut luonne luovat omat haasteensa konfiguraationhallinnalle. Erilaisia muutoksia voivat olla käyttäjien asentamat ohjelmat työkoneilleen tai organisaation yhteiselle, jaetulle kiintolevylle, huolto- ja päivitysjulkaisut koskien kaikkia organisaation ohjelmistoja ja laitteistoja, tekniikan vanhentumisesta johtuva tarve uudistaa laitteistoa nykyaikaisemmaksi ja projekteista syntyvät uudet automaatioteknologiat ja monimutkaisuuden tasot koskien niitä. Kaikkia näitä voidaan kontrolloida enemmän tai vähemmän, mutta varmaa on se, että jokainen muutos, joka tapahtuu IT-ympäristössä, tulee olla kirjattuna konfiguraatiotietokantaan (Klosterboer, 2007). Epäonnistumiset työkalujen integroimisessa. On olemassa hyviä laitteistoja ja ohjelmistoja löytäviä työkaluja sekä integroituja työkaluja, jotka mahdollistavat häiriö- ja muutosrekisterien linkittämisen konfiguraatiorekistereihin. Haaste työkaluihin liittyen on siinä, että pitäisi löytää tai rakentaa työkalu, joka löytää tietoa, siirtää sen varastoon, linkittää sen muiden palvelunhallintaprosessien tietoihin ja mahdollistaa sen noutamisen ja visualisoinnin varastosta. Ongelma siis on siinä, että on tarve suodattaa löydettyä tietoa sekä samalla liittää se löytämättömään tietoon. Lisäksi turvallisuuskysymykset nousevat näiden työkalujen haasteiksi. Kuinka saada tietoa laitteistoista ja ohjelmistoista koko organisaation kautta, jos palomuurit estävät työkaluja toimimasta tiettyyn pisteeseen asti näin ollen estäen tiedon siirtymistä muihin organisaation osiin. On äärimmäisen tärkeää että organisaatio valitsee käytettävät työkalunsa varovaisesti, tietäen tasan tarkkaan mikä näiden työkalujen funktionaalisuus on ja mitä rajoituksia niillä on (Klosterboer, 2007). Manuaaliset attribuutit. Manuaalisten attribuuttien käyttämistä tulisi välttää, jos vain mahdollista, koska niiden ylläpitäminen voi vaatia liikaa panosta sekä samalla avautuu mahdollisuus tehdä inhimillisiä virheitä, joita voi olla vaikea huomata. Kaikki manuaalisesti täytetyt attribuutit tulisi merkata epäilyttäväksi ja niitä tulisi auditoida usein, jotta saavutettaisiin mahdollisimman pieni virheellisyys. Konfiguraatiotietokannan suurimpia virheellisiä tietueita ovat juuri manuaalisesti 26

36 täytetyt attribuutit, joten niiden määrä pitäisi pitää mahdollisimman vähäisenä (Klosterboer, 2007). Muita haasteita konfiguraationhallinnan suorittamisessa voi olla muun muassa ihmisten vakuuttaminen siitä, että he eivät voi kiertää konfiguraationhallintaprosesseja (esimerkiksi lataamalla luvattomia ohjelmia työkoneelle tai laiminlyömällä konfiguraatioiden attribuuttien täyttämistä), riittävien taloudellisten resurssien saaminen, tiedon liiallisen määrän kerääminen (koska sitä on saatavilla paljon) sekä johdon hyväksyntä ja tuki liittyen konfiguraationhallinnan käyttöönottamiseen ja suorittamiseen (Bon et al., 2007). Lisäksi haasteita luovat heterogeenisen infrastruktuurin ja pilviympäristön hajauttava vaikutus (koska infrastruktuuri on hajautettu, tarkoittaa tämä useita eri käyttöjärjestelmiä, laitteistoja ja ohjelmistoja, jotka taas vaativat omia hallintatyökalujaan ja asiantuntijoitaan) sekä järjestelmien ylläpitotiimien erikoistumisesta johtuva nopeuden ja tehokkuuden väheneminen (Komarek et al., 2015). 27

37 3 Riskienhallinta IT-palvelunhallinnassa Riskienhallinnan päätehtävät (ISO/IEC, 2012a): 1) Tunnista riskejä. Uuden prosessin tai palvelun rakentuessa tunnista kaikki mahdolliset riskit. 2) Kategorisoi ja arvioi riskit. Tunnistetut riskit kategorisoidaan, arvioidaan ja priorisoidaan jotta tunnistetaan että minkä riskien korjaamiseen resursseja kannattaa investoida. 3) Tuo tunnistetut riskit ja suunnitellut hoitokeinot tietoon tarpeellisille tahoille. 4) Valvo riskejä. Arvioituja riskejä valvotaan. 5) Oikeanlaisia hoitokeinoja käytetään riskien korjaamiseksi tai turhien riskien välttämiseksi. Vaikka tutkimusta IT-riskeistä tai IT:stä johtuvista riskeistä on tehty ja työkaluja ja tekniikoita on kehitetty, ovat IT-riskit silti esillä monissa organisaatioissa. Riskit eivät ole vähentyneet, vaan päinvastoin, ne ovat lisääntyneet. Tähän on kaksi syytä. Ensinnäkin, IT on jatkuvasti monimutkaistunut ja täten tuonut lisää riskejä tunnistettavaksi ja hallittavaksi. Toiseksi, kehitystä tapahtuu myös muilla alueilla, joka myös synnyttää lisää riskejä. Tämä tarkoittaa sitä, että IT-riskeistä on tullut yhä enemmän vallitseva osa meidän yhteisöämme samalla, kun luonnolliset riskit ovat vähentyneet. Kun vanhojen riskien syypäät olivat luonnolliset katastrofit, uusien riskien syypäät ovat meidän itsemme luomat tekniset järjestelmät sekä organisaatiojärjestelmät (Hanseth et al., 2007). Yhteiskuntamme tulee yhä monimutkaisemmaksi johtuen teknologisen kehityksen ja sen käytön lisääntymisestä. Tämä näkyy myös yritysmuotojen monimutkaistumisessa. Nämä seikat ovat tärkeitä jatkuvalle globalisaatiolle. Tästä monimutkaisesta maailmasta on tulossa enemmän ennustamattomampi ja hallitsemattomampi. IT on käytännössä jokaisen teknologisen kehityksen keskuksena tai vähintäänkin sen osa- 28

38 alueena. IT, internet ja sen päälle rakennut sovellukset ovat globalisaation ydinosa. Täten voidaan sanoa, että IT on muuttunut kontrolliteknologiasta riskiteknologiaksi eli siis teknologiaksi, joka luo enemmän riskiä kuin kontrolloi sitä (Hanseth et al., 2007). Termi VUCA (Volatility, Uncertainty, Complexity, Ambiguity, Epävakaisuus, Epävarmuus, Monimutkaisuus, Monitulkintaisuus) on termi, joka kehitettiin kuvamaan maailmankuvaa kylmän sodan aikana. Samaa termiä voidaan käyttää myös nykypäivän IT-maailmasta (Verism, 2018). Riskienhallinnan ei pitäisi pelkästään keskittyä tiedon ja prosessien suojelemiseen, vaan sen tulisi ottaa myös tiedonhallinta (Knowledge Management, KM) huomioon. Tämä seikka on tullut yhä ajankohtaisemmaksi 2000-luvulla älypuhelinten ja kannettavien tietokoneiden yleistyessä. Organisaatioiden henkilöstö käy jatkuvaa dialogia erilaisilla laitteilla, ohjelmistoilla sekä erilaisissa sosiaalisissa medioissa. Tämä itsessään luo riskin sille, että joku organisaation henkilö esimerkiksi vuotaa vahingossa yrityksen herkkäluontoista tietoa julkisuuteen unohtamalla jonkun laitteensa julkiselle paikalle, joutumalla hakkeroinnin uhriksi tai tartuttamalla viruksen omaan laitteeseensa ulkopuolisia ohjelmia tai tiedostoja laitteelleen ladatessaan (Thalmann et al., 2014). 3.1 Riskienhallinnan ydinkäsitteet Riskienhallinta (Management of Risk, M_o_R) on riskien kontrolloimisen pääprosessi, jonka päämääränä on määrittää toimien tai tapahtumien yhteisten vaikutusten seurauksena todennäköisyyksiin pohjautuvat riskien toteutumat, jotka voivat olla sekä positiivisia että negatiivisia lopputuloksia, sekä näiden toteutumien mahdolliset seuraukset (Bon et al., 2007). Aliluvussa käsitellään riskienhallinnan tehtäviä ja tukitoimintoja liiketoiminnalle, aliluvussa käsitellään riskienhallintakomiteaa, aliluvussa riskien arvioimista, aliluvussa komponentin vikaantumisen vaikutusanalyysia, aliluvussa avainriskimittareita, aliluvussa liiketoiminnan vaikutusanalyysia, aliluvussa ITjatkuvuussuunnitelmaa, aliluvussa operationaalisten riskien arviointia sekä aliluvussa kriittisiä menestystekijöitä ja suorituskykymittareita. 29

39 3.1.1 Riskienhallinnan tehtävät ja tukitoimet liiketoiminnalle Riskienhallinnan tehtävänä on tukea päätöksentekoa samalla antaen ymmärrystä riskeistä ja niiden todennäköisistä seurauksista. Riskienhallinta tarjoaa yleisen viitekehyksen organisaation jokaiselle osa-alueelle käytettäväksi, oli sitten kyseessä strategiseen, ohjelmistoihin, tietoturvaan, projekteihin tai operatiiviseen toimintaan liittyvät alueet. Riskienhallinta sisältää kaikki tarvittavat aktiviteetit riskien tunnistamiseksi ja kontrolloimiseksi, jotta kaikki liiketoimintaan vaikuttavat riskit löydettäisiin ja käsiteltäisiin oikealla tavalla. Käytännössä tämä tarkoittaa oikeanlaisten lähestymistapojen, tarkastuslistojen, mittareiden, työkalujen ja tekniikoiden tuomista yhteen, jotta organisaatio voisi paremmin hallita tunnistettuja ja toistaiseksi tunnistamattomia riskejä (Bon et al., 2007). Riskienhallinnan suhde muihin liiketoiminnan osa-alueisiin on kuvattu kuvassa (Kuva 6.). Strategian hallinta Liiketoiminnan tulevaisuuden suunta Muutoksenhallinta Strategian muuttamista toiminnaksi (sisältäen ohjelmistojen, projektien ja muutosten hallinnan) Operationaalinen hallinta Päivittäiset operaatiot liittyen ihmisiin, prosesseihin, tietoturvaan, terveyden ja turvallisuuden hallintaan sekä liiketoiminnan jatkuvuuteen Kuva 6. M_o_R:n vaikutus liiketoiminnan eri osa-alueille (Bon et al., 2007, mukaillen). Riskienhallinta tukee pääsääntöisesti kolmea liiketoiminnan osa-aluetta: strategista, muutoksellista ja operationaalista hallintaa. Täten riskienhallintaa tulisi toteuttaa organisaation yläportaasta alaspäin jalkauttaen, samalla integroiden parhaimpia 30

40 käytäntöjä normaaleihin työrutiineihin ja -aktiviteetteihin organisaation jokaisella tasolla. Riskienhallinnan tavoite ei ole välttämättä riskien vähentäminen tai eliminointi liiketoiminnan sisällä vaan riskien tunnistaminen ja hallitseminen parhaalla mahdollisella tavalla, jotta osakkeenomistajien arvoa suhteessa liiketoimintaan pystyttäisiin suojelemaan ja kasvattamaan. Hyvä riskienhallinta mahdollistaa isompien riskien ottamista kontrolloidusti hyödyntäen organisaatiota ja sen osakkeiden omistajia (Bon et al., 2007) Riskienhallintakomitea Riskienhallintakomitea (Enterprise Risk Management Committee, ERMC) on vastuussa koko organisaation päätöksenteosta liittyen eri lähteistä saatavien riskien arvioimiseen, kontrolloimiseen, optimoimiseen, rahoittamiseen ja valvomiseen. Riskienhallintakomitean tehtävä on lisätä liiketoiminnan lyhyen ja pitkän tähtäimen arvoa sen sidosryhmille (Information Systems Audit, Control Association & Isaca, 2012a). Riskienhallintakomitea varmistaa, että avainriskeihin liittyvät prosessien tuotokset katselmoidaan systemaattisesti vähintään kerran vuodessa (GCM Securities Limited, 2018). Lisäksi riskienhallintakomitea vastaa siitä että organisaatio ottaa tarkasti laskelmoituja riskejä, riskienhallinnan dokumentaatio tehdään oikein, organisaation sisällä on oikeanlainen riskienhallinnan kulttuuri ja siitä että organisaation hallituksen tulisi arvioida riskienhallintakomitean toimintaa vuosittaisella tasolla (GCM Securities Limited, 2018) Riskien arviointi Riskien arviointi (Risk Assessment, RA) on riskienhallintaa edeltävä prosessi. Riskien arvioinnin tarkoituksena on virallisesti arvioida jonkun IT-palvelun konfiguraatioiden tai kyvykkyyden häiriöiden vaikuttavuutta ja tukea organisaatiota arvioinneilla mahdollistaen paremman päätöksenteon liiketoiminnan jatkuvuuden turvaamiseksi. On suositeltavaa, että kaikki osa-alueet koskien IT-infrastruktuuria, palveluita ja niiden konfiguraatioiden rakenneosia, palveluiden suunnittelua ja tukevaa 31

41 organisaatiota kohdistettaisiin virallisiin riskienarviointiharjoitteisiin. Riskien arvioinnin ja riskienhallinnan suhde on kuvattu kuvassa 7. Omaisuus Uhkat Haavoittuvuudet Riskien arviointi Riskit Vastatoimenpiteet Riskienhallinta Kuva 7. Riskien arviointi ja riskienhallinta (Hunnbeck et al., 2011, mukaillen). Riskien arviointi on vahvasti yhteydessä riskienhallintaan. Yhdistettynä ne tarjoavat organisaatiolle kyvyn tunnistaa ja määrittää riskit ja niiden oikeutetut vastatoimet suojellakseen IT-järjestelmien saatavuutta. Riskien tunnistaminen ja vastatoimien tarjoaminen näiden vaikutusten poistamiseksi tai minimoimiseksi voivat palvella suurta roolia tarvittavien palveluiden saatavuuksien saavuttamiseksi uusille tai muutetuille palveluille. Riskien arviointia tulisi suorittaa IT-teknologian tai - palveluiden suunnitteluvaiheessa jotta tunnistettaisiin (Hunnbeck et al., 2011): Riskit, joista voi johtua erilaisten teknologisten tai palveluita koostavien ITkomponenttien saavuttamattomuudesta. Riskit, joista voi koitua ongelmia IT-teknologioiden ja -palveluiden luottamuksellisuuden tai oikeellisuuden suhteen. 32

42 3.1.4 Komponentin vikaantumisen vaikutusanalyysi Komponentin vikaantumisen vaikutusanalyysi on työkalu, jolla voidaan ennustaa ja arvioida IT-palveluiden komponenttien vikaantumisien vaikuttavuuksien seuraamuksia organisationaalisella tasolla. Analyysin tuloksia voidaan käyttää tunnistamaan minne lisäresursseja tulisi panostaa, jotta komponenttien vikaantumisen vaikuttavuutta liiketoimintaan ja käyttäjien päivittäiseen arkeen voitaisiin estää tai minimoida (Hunnbeck et al., 2011). Komponentin vikaantumisen vaikutusanalyysi olisi tärkeää tehdä palvelun suunnitteluvaiheessa, jolloin on tarpeen ennustaa ja arvioida IT-palvelun saatavuuden häiriöiden vaikutuksia johtuen jonkun komponentin vikaantumisesta. Vaikutusanalyysi on myös hyödyllistä suorittaa jo olemassa oleville tai muutetuille ITpalveluille ja -infrastruktuurille (Hunnbeck et al., 2011) Avainriskimittari Avainriskimittarit ovat mitattavia mittareita tai osoittimia, jotka seuraavat altistumista, menetystä tai yleisiä ongelmia. Kaikki keinot ja tavat jotka mittaavat edellä mainittuja prosesseja, voidaan sanoa olevan riskimittareita. Mittarista tulee avainroolissa oleva, kun se seuraa erittäin tärkeää altistumista tai se tekee jonkin asian seuraamista hyvin, tai molempia. Operationaalisia riskejä voidaan määritellä menettämisen riskinä johtuen huonosta tai epäonnistuneista prosesseista, järjestelmistä, ihmisten suoriutumisesta tai ulkoisista tapahtumista. Asiakasvalitusten lukumäärä on esimerkki avainriskimittarista. Kun asiakasvalitusten lukumäärä kasvaa, todennäköisyys sille, että niiden takana olisi olemassa jotakin piileviä tai systemaattisia virheitä kasvaa. Jos asiakasvalitusten syytä ei tutkita, voidaan alkaa tekemään mahdollisesti virheellisiä ratkaisuja päätöksenteossa, kun asiakasvalitusten määriä yritetään vähentää. On siis loogista ajatella, että muutokset tässä mittarin arvossa liittyvät muutoksiin operationaalisien riskien altistumiselle tai operationaalisen menetyksen kokemiseen (Davies et al., 2006). 33

43 3.1.6 Liiketoiminnan vaikutusanalyysi Liiketoiminnan vaikutusanalyysi (Business Impact Analysis, BIA) on hyvä työkalu, kun yritetään tunnistaa liiketoiminnan tarpeita, vaikutuksia ja riskejä. Liiketoiminnan vaikutusanalyysi on keskeinen tekijä liiketoiminnan jatkuvuuden prosessissa. Liiketoiminnan vaikutusanalyysi määrittää strategiaa koskien riskien vähentämistä ja katastrofista toipumista. Tärkein toiminto liiketoiminnan vaikutusanalyysilla on katastrofin vaikutuksen tunnistaminen koskien liiketoimintaa. Se näyttää mihin osaalueisiin laajavaikutteinen häiriö vaikuttaisi eniten ja mitä tämä tarkoittaisi kokonaisvaltaisen liiketoiminnan kannalta. Täten se tunnistaa liiketoiminnan selviytymisen kannalta kriittisimmät liiketoimintafunktiot sekä minne tämä kriittisyys kohdistuu ajankohdasta riippuen. Liiketoiminnan vaikutusanalyysi myös auttaa organisaatiota ymmärtämään sen palveluitaan paremmin (Hunnbeck et al., 2011). Liiketoiminnan vaikutusanalyysilla on kaksi aluetta (Hunnbeck et al., 2011): Ensimmäinen alue koskee liiketoiminnan hallintaa, jonka täytyy keskittyä tutkimaan jonkun liiketoiminnan prosessin tai funktion menetyksen vaikutusta. Tämä sisältää myös menetyksen korjaamiseen vaadittavien tuntimäärien ja kustannusten selvittämistä. Toinen alue sijaitsee palvelunhallinnassa, jonka täytyy selvittää palvelun menetyksen vaikutukset liiketoiminnalle. Tässä alueessa otetaan huomioon keinot hallita ja vaikuttaa palveluihin palvelunhallinnan avulla. Liiketoiminnan vaikutusanalyysi on suuressa roolissa uuden tai muuttuneen palvelun suunnitteluvaiheessa sekä liiketoiminnan jatkuvuuden strategian kehittämisessä. Liiketoiminnan vaikutusanalyysin avulla organisaatio voi määrittää (Hunnbeck et al., 2011) mitkä ovat kriittisiä palveluita, mistä rakenneosista niitä koskettava laajavaikutteinen häiriö koostuu ja tällaisen toteutuessa mikä olisi sen vaikutus ja laajuus liiketoimintaa miettiessä palvelukatkoksien hyväksyttävät tasot ja ajat 34

44 kriittiset liiketoiminnan ja palveluiden ajanjaksot palvelun menetyksen kustannukset mahdolliset tietoturvan seuraukset johtuen palvelun menetyksestä IT-jatkuvuussuunnitelma IT-jatkuvuussuunnitelma (IT Service Continuity Plan, ITSCP) on tärkeä osa ITpalvelun jatkuvuudenhallintaa (IT Service Continuity Management, ITSCM), joka taas tukee liiketoiminnan jatkuvuudenhallintaa (Business Continuity Management, BCM). IT-jatkuvuussuunnitelmia täytyy kehittää, jotta kriittisten järjestelmien, palveluiden tai tietovarastojen jatkuvuus ja palautuminen saadaan toteutettua liiketoiminnan jatkuvuuden kannalta riittävässä aikaikkunassa. Yleensä liiketoiminnan jatkuvuudenhallinnan suunnitelmat nojautuvat IT-palveluiden, tietovarastojen ja erilaisten resurssien saatavuuteen. Tästä johtuen ITjatkuvuudenhallinnan suunnitelmien pitää taata, että edellä mainitut IT-palvelut, tietovarastot ja muut resurssit toimitetaan hyväksyttävässä operationaalisessa tilassa ja että ne ovat hyväksytty liiketoiminnan osana. Tämä ei tarkoita pelkästään pelkkää palveluiden ja tietovarastojen palauttamista vaan myös niiden välisten yhteyksien kartoittamista, testauksen suorittamista ennen toimitusta ja tiedon oikeellisuuden ja jatkuvuuden validoimista (Hunnbeck et al., 2011). IT-jatkuvuussuunnitelman tulisi myös mahdollistaa nopea pääsy palautusta vaativaan tietoon, sisältää kaikki dokumentoitu tieto ja tarkistuslista IT-palvelun palautumiseen liittyen, sisältää kaikki tekniset suunnitelmat mitä organisaatiolla on liittyen sen ITinfrastruktuuriin ja lisäksi IT-jatkuvuussuunnitelman pitäisi olla jatkuvasti saatavilla sitä tarvitseville organisaation henkilöstön jäsenille (Hunnbeck et al., 2011) Operationaalisten riskien arviointi Operationaalisten riskien arviointi sisältää eri tyyppisiä riskikategorioita kuten rakennuksien, järjestelmien ja toimintaympäristöjen riskit, luonnon tai asiakkaiden aiheuttamat riskit, sääntelyiden noudattamisesta johtuvat riskit, tietoverkosta tai tietoturvasta johtuvat riskit. On yleistä, että liiketoiminnan vakuuksia tehtäessä 35

45 arvioidaan liiketoiminnan sisäiset riskit, mutta operationaaliset riskit jätetään kokonaan arvioimatta. Monissa säännellyissä ympäristöissä riskien arvioinnit ovat pakollisia, mutta operationaaliset riskit jäävät käsittelemättä. Tästä syystä haavoittuvuudet saattavat jäädä huomaamatta pitkäksi aikaa tai jäädä kokonaan huomaamatta ja toteutuessaan ne voivat pysäyttää liiketoiminnan suorittamisen kokonaan. Tästä palautuminen voi olla paikoittain vaikeaa tai mahdotonta. Kattava operationaalisten riskien arvioiminen auttaa löytämään edellä mainitut haavoittavuudet, altistumiset tai uhkat, jotta riskejä voidaan minimoida tai poistaa kokonaan (McKim, 2017) Kriittiset menestystekijät ja suorituskykymittarit Riskienhallinnan kriittisiä menestystekijöitä ovat (Office of Government Commerce, 2002b) IT-palveluiden tarjonnan ja palautumisen vastaaminen liiketoiminnan tarpeisiin liiketoiminnan ja IT-palveluiden jatkuvuuden suunnitelmien saattaminen koko organisaation tietoisuuteen oikeanlaisten liiketoiminnan ennusteiden tekeminen IT-palveluiden saatavuuden ja luotettavuuden hallinta ongelmien vaikuttavuuden minimoiminen IT-palveluiden laadun ylläpitäminen häiriöiden nopea ratkaiseminen. Riskienhallinnan keskeisiä suorituskykymittareita ovat (Brooks, 2006): Riskejä vähentävien tekojen lukumäärä. Prosenttiosuus konfiguraatioiden rakenneosista, jotka löytyvät liiketoiminnan vaikuttavuuden analyysista. Prosenttiosuus prosesseista, jotka on määrätty operationaalisten riskien määrittelyn piiriin. 36

46 Prosenttiosuus CI:stä, joiden käyttökatko oli suurempi kuin mitä operationaalisten riskien arvioinnissa oli arvioitu. Tunnistettujen uusien riskien lukumäärä. Prosenttiosuus CI:stä, joita ei ole otettu huomioon ITjatkuvuussuunnitelmassa. 3.2 Riskienhallinnan suunnittelu ja hallinta Riskejä on monenlaisia. Tietoturvaan liittyviä riskejä ovat muun muassa arkaluontoista materiaalia sisältävän kannettavan tietokoneen varkaus, tietokeskuksen tuhoutuminen ilkivallan tai jonkun muun syyn takia, tärkeiden tietoturvalaitteiden vahingonomainen säätäminen, virushyökkäykset, palvelunestohyökkäykset, tietokannassa olevan herkän tiedon vahingossa vaurioittaminen. IT-palvelunhallintaan liittyviä riskejä ovat väärän ohjelman valitseminen yrityksen strategian ja prioriteettien vastaisesti, vääränlaisten IT-investointien tekeminen johtuen oikeiden henkilöiden puuttumisesta päätösprossesissa, IT-arkkitehtuurin kehityksen ja laajenemisen estyminen johtuen monimutkaisesta ja joustamattomasta nykyarkkitehtuurista, SLA:sta poikkeavien tukien ja palveluiden saanti tuottajilta, tuottajan vaihtuminen, uudet asiakkaat tai palvelut ja lisenssittömien tuotteiden käyttäminen. Liiketoiminnan johtamiseen liittyviä riskejä ovat IT-henkilökunnan jäsenten poislähteminen tai pidentynyt poissaolo, liiketoiminta-ajattelun puuttuminen IThenkilökunnalta, tärkeän tiedon käyttämättä jättäminen liiketoimintaa koskevissa päätöksissä johtuen tiedon hautautumisesta tai vanhojen tietokantajärjestelmien käyttäminen. Lisäksi aina on mahdollisuus luonnollisten katastrofien (kuten maanjäristysten ja tsunamien) esiintymiselle. Vain mielikuvitus on rajana. Näistä edellä mainituista riskeistä olisi kuitenkin tärkeää tunnistaa omalle organisaatiolle kriittisimmät ja siihen suorasti tai epäsuorasti vaikuttavat riskit (Information Systems Audit, Control Association & Isaca, 2012b; Taylor, 2007; Mosimann, 2007). Riskienhallinnan suunnittelua ja hallintaa on kuvattu kuvassa 8. 37

47 Kuva 8. Riskienhallintaprosessi (Vilarinho et al., 2011, mukaillen). Riskienhallinnan suunnittelussa ja päivittämisessä otetaan huomioon organisaation riskienhallinnalle kriittisiä kohtia, joihin tulee saada ratkaisu. Näitä esimerkiksi ovat muutospyyntöjen arviointikriteerit, tietoturvallisuutta koskevien muutospyyntöjen arvioimiskriteerit, tietoturvan riskiarvio, uusi tai muuttunut palvelusuunnitelma, riskilogit, palvelun saatavuuden riskien arvioinnin kriteerit, palvelun jatkuvuuden riskien arvioinnin kriteerit ja palveluriskien arvioinnin kriteerit. Näistä saadaan synnytettyä tietoturvan muutospyynnön arvioinnin raportti, päivitetty riskilogi, riskienhallinnan strategia ja palveluriskien arvioinnin raportti (ISO/IEC, 2012a). Riskien käsittelyyn on neljä mahdollisuutta: välttäminen, siirtäminen, lieventäminen ja säilyttäminen. Välttämisen strategia on vaihtoehtoisen keinon kehittäminen riskin välttämiseksi. Palvelusuunnittelua voidaan esimerkiksi muuttaa, jotta jokin tietty riski vältetään kokonaan. Riski voidaan myös välttää esimerkiksi lisäämällä henkilöstöresursseja ja aikaa riskin välttämiseksi. Siirtämisen strategia siirtää riskin 38