Tässä kirjoituksessa käsittelen sitä, miten tehdä business impact analysis (BIA) eli liiketoiminnan vaikutusanalyysi.
Kirjoitus on jatkoa aiemmin julkaisemalleni kirjoitukselle Mikä on Business Impact -analyysi (BIA) ja mitä hyötyä sen tekemisestä on? Siinä käsittelin mm. sitä, mistä liiketoiminnan vaikutusanalyysin tekemisessä on kyse ja mitä hyötä sen tekemisestä on.
Tässä kirjoituksessa keskityn siihen, miten BIA tehdään IT-järjestelmistä seuraavien ongelmien ymmärtämiseksi.
Projektin sisältö tietysti voi olla hyvin erilainen riippuen siitä, mitä projektilla tavoitellaan. Seuraavassa on kuitenkin runko, jonka mukaan etenemällä voi saada hyviä tuloksia aikaan.
Tavoitteena on IT-häiriöiden vaikutusten ymmärtäminen
BIA on työkalu, josta on hyötyä monessa asiassa. Tässä kirjoituksessa olen lähtenyt siitä, että tavoitteena on ymmärtää IT:n mahdollisten häiriöiden vaikutuksia liiketoimintaan.
Oletetaan, että toimitusjohtaja on huolissaan IT:n riskeistä liiketoimintaan ja haluaa ymmärtää mahdollisia ongelmatilanteiden vaikutuksia paremmin. Miten toimitusjohtajamme saa vastauksen kysymykseen: Kuinka haavoittuvainen IT-ympäristömme on ja mitä sen ongelmista voi seurata?
Veikkaan, että aika monessa organisaatiossa johto on yrittänyt kysyä näitä kysymyksiä tietohallinnolta. Vastaukset ovat todennäköisesti olleet epämääräisiä. Ongelmana on se, että luotettavan vastauksen antaminen on hyvin vaikeaa ilman järjestelmällistä analyysia.
Jos vastausten epämääräisyys jää kalvamaan toimitusjohtajan mielenrauhaa, ei auta kuin selvityttää asia. Miten homma voisi hoitua? Lähdetään liikkeelle projektin rajaamisesta.
1. Rajaa työ koskemaan tärkeimpiä tuotteita tai palveluja
Jos lähtee kysymään, mihin kaikkeen IT vaikuttaa, saa vastauksen, että kaikkeen. Kaikkia mahdollisia vaikutuksia ei ole mahdollista eikä järkevääkään arvioida. Siksi kannattaa keskittyä siihen, mitä vaikutuksia IT-katkoilla tai häiriöillä on yrityksen tärkeimpien tuotteiden tai palvelujen tuottamiseen.
Tässä ei siis ole kyse kriittisimmistä IT:n käyttämistä tuotteista tai tuottamista palveluista, joita se tuottaa muulle organisaatiolle, vaan yrityksen tuottamista tai myymistä tuotteista ja palveluista.
Sama analogia toimii toki myös julkisella puolella toimivan organisaation kohdalla, vaikkei kyse olekaan sellaisesta bisneksestä, jossa asiakkaat maksavat tuotteet tai palvelut.
Viittaan jatkossa kaikkeen organisaation tuottamaan tuotteina, riippumatta siitä, onko kyse fyysisestä tuotteesta, projektista tai vaikka jatkuvasta palvelusta.
Nyt pitää siis tunnistaa esimerkiksi kahdesta kolmeen tärkeintä tuotetta ja tutkia, mitä vaikutuksia IT-häiriöillä on niihin.
Seuraava askel on rajata tutkittavien skenaarioiden määrää. Lue eteenpäin, niin saat tietää, millaisia skenaarioita kannattaa tutkia.
2. Sovi alustavista BIA-skenaarioista
Kuten jo aiemmin totesin, BIA voi olla luonteeltaan hyvin laaja. Nyt kuitenkin keskitytään IT-ympäristöön liittyviin häiriöihin. Tämä helpottaa ja nopeuttaa työtä.
Jotta työssä voidaan tutkia todellisten skenaarioiden vaikutuksia, nyt pitäisi listata skenaariot, joita pidetään realistisena. Näitä voivat olla esimerkiksi seuraavat skenaariot:
- Yksittäisten komponenttien vikaantuminen konesalissa. Tässä on ideana tutkia ns. single-point-of-failure-kohteiden vikaantumisen vaikutuksia. Mihin kaikkeen yksittäisen tärkeän komponentin vikaantuminen lopulta vaikuttaa? Tämän skenaarion analysointi tuo esiin ongelmat, joita voi seurata siitä, jos keskeisiä konesalin komponentteja on säästösyistä jätetty kahdentamatta.
- Konesalin menettäminen onnettomuudessa. Tässä skenaariossa on tarkoituksena tutkia sitä, mitä seuraa siitä, jos tärkeä laitetila menetetään. Toimitusjohtajan kannalta kiinnostava kysymys on, miten kauan ympäristön toimintakuntoon palauttamisessa kestää, jos varakonesalia ei ole olemassa. Toisaalta vielä tärkeämpää on tärkeää tutkia, mitä sillä aikaa tapahtuu muualla organisaatiossa.
- Pilviympäristö joutuu vääriin käsiin. Jos yrityksellä on käytössään pilvikonesali, se voi joutua vääriin käsiin, jos esim. ylläpitotunnukset joutuvat jostain syystä vääriin käsiin. Riittävän korkean tason tunnuksilla voi esimerkiksi poistaa koko ympäristön ja siihen liittyvät varmuuskopiot. Se voi johtaa ympäristön menettämiseen. Tässä skenaariossa tutkitaan siis sitä, miten riippuvainen organisaatio on kyseisestä pilviympristöstä.
- Haittaohjelman leviäminen. Tässä skenaariossa joudutaan miettimään, mitä pahasti saastuneen IT-ympäristön perusteellinen puhdistaminen tarkoittaisi ja kauanko se kestäisi. Ja ennen kaikkea sitä, miten paljon organisaatio kärsisi siitä, jos järjestelmät eivät saastumisen vuoksi olisi käytössä.
- Cryptolocker lukitsee organisaation tiedostot. Tämä on pelottava skenaario. Jos cryptolocker onnistuu livahtamaan tietojärjestelmiin ja salaa kaikki kovalevyt, menetetään tietoja. Miten siitä toivutaan ja mitä liiketoiminnalle sillä aikaa tapahtuu?
- Yhteydet pilvipalveluun menetetään. Koska moni pilvipalvelu pyörii Keski-Euroopassa tai jopa vielä kauempana, asiakkaan kannattaa pohtia skenaariota, jossa tietoliikenneyhteydet Suomesta maailmalle huononevat merkittävästi tai ovat jopa poikki. Mitä tällaiset häiriöt tarkoittaisivat liiketoiminnalle?
Skenaarioita on toki paljon muitakin. Nämä olivat vain esimerkkejä. Muita mahdollisia ovat esimerkiksi toimittajariskien tutkiminen, omaan henkilöstöön liittyvät riskit jne.
3. Tunnista ne organisaation osat, joita tarvitaan kohteena olevan tuotteen tuottamiseen
Koska tavoitteena on ymmärtää, mitä todellisia liiketoimintavaikutuksia IT-häiriöillä on, pitää tarkastella muun organisaation toimintaa ja niiden prosessien riippuvuutta IT-järjestelmistä.
Oletetaan, että kyse on fyysisiä tuotteita valmistavasta yrityksestä. Silloin mukaan pitäisi valita esimerkiksi seuraavia yksiköitä:
- Myynti
- Tilausten vastaanotto
- Tuotannon suunnittelu
- Hankinta ja materiaalien vastaanotto
- Tuotantoyksikkö, jossa ko. tuotteita valmistetaan
- Varastointi
- Valmiiden tuotteiden lähetys
- Laskutus
Kuten nähdään, mukana on iso osa yrityksen toiminnoista myynnistä, tilausten vastaanotosta tuotteiden valmistukseen, lähetykseen ja laskutukseen. Kaiken sen pitää toimia, jotta yritys saa kassavirtaa.
Häiriö jossain näistä toiminnoista voi pysäyttää koko putken ja sitä kautta sisään tulevan kassavirran. Lisäkustannuksia voisi muodostua mahdollisista sopimussakoista tai muista korvauksista, joita organisaatio voi olla velvollinen maksamaan.
Seuraavaksi mukaan tarvitaan ihmisiä, jotka tuntevat käytännön tekemisen eri yksiköissä. Näitä ihmisiä on selvästi tarve haastatella.
4. Haastattele johtajia ja asiantuntijoita
Olennainen osa BIAn tekemistä on ihmisten haastattelu. Eri toiminnoista vastaavien johtajien kanssa käydään keskusteluja bisneksen lainalaisuuksista ja eri toimintojen tärkeydestä.
Lisäksi pitää löytää niitä ihmisiä, jotka tuntevat prosessit ja tietojärjestelmät tarkemmin. Usein nämä ihmiset löytyvät viimeistään siinä vaiheessa, kun alkaa kysymään johtajilta, kuka tietää asiasta tarkemmin.
Keskusteluissa voidaan käsitellä mm. seuraavia teemoja:
- Liiketoiminnan ja johtajien tavoitteet
- Brändin ja maineen merkitys, myynti, katerakenne, tuotannon kustannukset
- Prosessit ja niihin liittyvät järjestelmät
- Järjestelmien väliset riippuvuudet
- Mitä eri skenaarioista voisi seurata
- Miten eri tilanteisiin on varauduttu
Keskustelujen teemat tietysti riippuvat siitä, mikä on projektin tavoite ja kenen kanssa keskustellaan. Kunkin henkilön kanssa käsitellään juuri hänelle relevantteja asioita.
Asioita voi tietysti käydä läpi myös työpajoissa, jossa on eri alueiden edustajia.
5. Kuvaa suojattava kohde sopivalla tarkkuudella
Jotta erilaisia skenaarioita voi tarkastella ja vertailla, pitää piirtää tarkasteltavasta kohteesta sopivalla tarkkuudella oleva kuva tai arkkitehtuurityökalulla tehty malli.
Kun kohteena on IT-ympäristö, pitää se pystyä kuvaamaan tarkasteluun sopivalla tarkkuudella. Tämä voi tarkoittaa esimerkiksi seuraavien kohteiden kuvaamista:
- Konesalit, olennaiset laitetilat
- Konesaleja ja toimipisteitä yhdistävät verkot
- Keskeiset järjestelmät
- Järjestelmien väliset riippuvuudet
- Keskeiset infrakomponentit, joita järjestelmät tarvitsevat toimiakseen
Tässä ympäristön hyvästä dokumentaatiosta tai mallintamisesta on paljon hyötyä. Kokonaisarkkitehtuurityökalun avulla tehty mallinnustyö kantaa tässä kohtaa hedelmää, jos sellaista on tehty.
Kokonaisarkkitehtuuritiimien tekemä mallinnustyö on kuitenkin saattanut jäädä tietovirtojen, prosessien ja järjestelmien välisten riippuvuuksien tunnistamiseksi. Siitä alaspäin teknologia- ja fyysiselle tasolle ei riipuvuuksia välttämättä ole kuvattu.
Jonkinlaiset yksinkertaistukset ovat kuitenkin nyt tärkeitä. Esimerkiksi eri skenaarioiden vaikutusten laajuuden kuvaamiseksi tarvitaan jotain yksinkertaista, johon pystyy merkitsemään, missä vaikutus näkyy.
6. Arvioi eri skenaarioiden seurauksia
Tässä kohtaa pitäisi pystyä tunnistamaan, millaisia seurauksia milläkin skenaariolla voisi olla. Tämä on siinä mielessä vaikeaa, että ainakin IT-asiantuntijat ovat usein sitä mieltä, ettei näin voi käydä, koska meillä on se ja se ratkaisu käytössä.
Jotta päästään jossitteluista eroon, voi olla fiksua arvioida kahta eri alaskenaariota:
- Mitä tapahtuisi, jos mitään turvamekanismeja ei ole käytössä. Tällä saadaan selville skenaarion todelliset vaikutukset ilman mitään jossitteluita, että ”voimme tehdä sitä ja tätä, jos tapahtuu näin.” Tämä auttaa arvioimaan sitä, mitä liiketoimintaprosessissa alkaa tapahtumaan, jos jokin IT-ympäristön osa ei ole käytössä.
- Millaiset seuraukset todennäköisesti ovat, jos otetaan huomioon toteutetut suojautumismekanismit tai toipumisjärjestelyt. Tämä näkökulma ottaa huomioon sen, mitä on tehty ja miten paljon toimenpiteistä on hyötyä.
Seurausten arvioiminen vaatii yrityksen prosessien ja toiminnan tuntemista. Miten esimerkiksi tuotannon suunnittelussa tai valmistuksessa toimitaan käytännössä? Mikä on minkäkin tietojärjestelmän rooli missäkin vaiheessa?
7. Pyri arvioimaan seurauksien kustannuksia
Jotta skenaarioiden seuraukset saadaan käännettyä kielelle, jota kaikki ymmärtävät, olisi hyvä arvioida skenaarioiden euromääräisiä vaikutuksia.
Tämä osuus vaatii yrityksen kustannusrakenteen tuntemista ja vaatii siksi talouspuolen osallistumista. Tässä voidaan ottaa huomioon esim. myynnin sakkaamisen, tuotannon seisomisen tai ylitöiden vaikutuksia. Lisäksi pitää pyrkiä arvioimaan suoria kustannuksia, joita tulisi palautumisesta normaalitilanteeseen, jos jokin vakava skenaario yllättää.
Laskelma voi olla yksinkertainen tai hyvinkin monimutkainen riippuen siitä, miten tarkasti eri skenaarioita halutaan arvioida.
Osa aiheutuvista kustannuksista liittyy suoraan tilanteen korjaamiseen. Esimerkiksi haittaohjelman poistaminen tietojärjestelmistä voi vaatia projektin, jossa järjestelmiä asennetaan uudestaan. Tällaisen työn hintaa voi yrittää arvioida.
Toiset kustannukset ovat epäsuoria. Niitä ovat esimerkiksi toiminnan keskeytyksestä seuraavat ylimääräiset kulut. Näiden arviointi on paljon vaikeampaa, mutta ne muodostavat usein suuremman osan kokonaiskustannuksista.
Nyt voidaan kysyä esimerkiksi seuraavanlaisia kysymyksiä:
- Onko tuotannossa ylimääräistä kapasiteettia, jonka ansiosta katkon aiheuttama viivästys tuotannossa voidaan paikata ilman ylitöitä?
- Vaatiiko tuotannon menetyksen paikkaaminen ylitöitä?
- Menetetäänkö katkon yhteydessä raaka-aineita?
- Miten pitkä katko saa asiakkaat tilaamaan tuotteensa muualta?
- Menetettiinkö tässä yksittäinen kauppa vai kenties koko asiakas?
- Millainen katko aiheuttaa haittoja brändille?
Käytännössä tässä pitää käydä jollain tasolla läpi koko kohteena oleva ketju läpi ja tunnistaa, miten katko IT-järjestelmissä vaikuttaa eri toimintoihin.
8. Koosta toimenpide-ehdotukset ja yhteenvedot
Tässä vaiheessa pyritään arvioimaan sitä, miten suojautumista voidaan parantaa tai palautumista nopeuttaa. Tätähän voidaan tietysti tehdä pitkin projektia, mutta tässä vaiheessa pitäisi olla tiedossa se, miten paljon eri skenaariot tosiasiassa voivat maksaa. Siksi ehdotuksia on paljon helpompi arvioida nyt kuin ilman perusteellista kustannusten arviointia.
Jos esimerkiksi katko maksaa alkuvaiheessa miljoonan päivässä, mutta sen jatkuessa kustannukset nousevat 10 miljoonaan päivässä, on paljon helpompi hyväksyä järeämpiä toimenpide-ehdotuksia kuin silloin, jos vaikutusten kuvailu on epämääräistä.
Tässä vaiheessa tuloksista pyritään koostamaan sellainen kokonaisuus, että tuloksia ylipäätään voidaan kommunikoida projektiryhmän ulkopuolelle. Tämä todennäköisesti sisältää laskelmia, graafeja ja tiivistyksiä, jotka valaisevat skenaarioiden seurauksia ja tärkeimpiä oikeasuhtaisia toimenpiteitä, joilla vaikutuksia voidaan pienentää.
Lue myös Oras Groupille tehdystä projektista, jossa toteutettiin pitkälle tässä kuvatun tapainen projekti. Artikkeli löytyy täältä.
Jos pidit tästä artikkelista, myös seuraavat artikkelit voivat olla kiinnostavia: