ICT-varautuminen, osa 1 – Tavoitteiden asettaminen

ICT-varautuminen lähtee tavoitteiden asettamisestaDigitalisaatio asettaa suuria vaatimuksia IT-järjestelmien toiminnalle. Käsittelin aiemmin sitä, kuinka elämämme on muuttunut digitalisaation myötä riippuvaisemmaksi järjestelmistä. Löydät kirjoituksen täältä. Avasin jatkuvuuden hallinnan termejä toisessa kirjoituksessa, jonka löydät täällä. Tässä kirjoituksessa pureudun siihen, miten ICT-varautumishanketta voi käytännössä viedä eteenpäin. Monessa organisaatiossa herätään tietojärjestelmien kriittisyyteen sen jälkeen, kun on koettu käyttökatko, josta on ollut merkittävää haittaa. Katkon jälkeen käynnistetään projekti, joka tähtää varautumistilanteen parantamiseen. Projekti tai hanke lähtee tässä kohtaa usein väärille raiteille, koska liiketoiminnalle sen paremmin kuin IT:llekään ei ole täysin selvää, mitä oikeastaan ollaan tekemässä. Olen kuvannut tähän liittyviä ongelmia kirjoituksessa, jonka löydät täältä.

Jos luit linkittämiäni kirjoituksia, sait selville, että tarkoittamani ongelmat projekteissa liittyvät siihen, että liiketoiminnan tavoitteita ei ole ollut helppoa kääntää IT:n tavoitteiksi. Pohjimmiltaan ongelma johtuu liiketoiminnan ja IT:n välisistä kommunikaatio-ongelmista. Tämä on todellinen riski myös varautumiseen tähtäävissä projekteissa, koska ICT-varautuminen vaatii tyypillisesti mittavia investointeja. Jos nämä investoinnit tehdään väärin lähtötiedoin, rahaa palaa, mutta tulokset eivät välttämättä ole toivottuja.

Käsittelen tässä lähestymistapaa, joka lähtee johdon kanssa asetettujen tavoitteiden asettamisesta. Sitä seuraa uhkien ja niiden toteutumisen todennäköisyyden tarkastelu. Tästä päästään erilaisiin ratkaisuvaihtoehtoihin, joita voidaan arvioida tavoitteiden ja uhkien perusteella. Kirjallisuudessa puhutaan myös riskianalyysin tekemisestä hankkeen alkuvaiheessa. Se on tarpeen silloin, kun katkoja ei ole ollut ja halutaan ymmärtää, millaiset katkot muodostavat riski liiketoiminnalle. Usein näihin hankkeisiin kuitenkin ryhdytään siinä vaiheessa, kun jo tiedetään, että riski on selkeä ja vaatii reagointia. Sen vuoksi olen tässä jättänyt varsinaisen puhtaan riskianalyysin pois. Tässä kuvattu malli on myös käytännönläheisempi, kuin VAHTI 2/2016 Toiminnan jatkuvuuden hallinta -ohjeessa on kuvattu. VAHTI-ohje käsittelee jatkuvuuden hallintaa koko organisaation kannalta. Tässä kirjoituksessa käsitellään jatkuvuuden hallintaa ICT:n näkövinkkelistä.

ICT-varautuminen
Jotta hankkeessa lähdetään tekemään oikeita asioita, tämäkin hanke pitää aloittaa tavoitteiden selkiyttämisellä.

Sitouta ylin johto hankkeeseen

Tämä tapahtuu parhaiten osallistamalla johtajia. Olen itse käyttänyt kahta menetelmää: haastatteluita sekä yhteistä työpajaa. Haastattelut mahdollistavat luottamuksellisen keskustelun ja niiden avulla päästään syvemmälle eri ihmisten tavoitteisiin ja näkemyksiin. Työpajan etu taas on siinä, että se vie vähän kalenteriaikaa ja voi työpaja mahdollistaa osallistujien keskustelun, joka on arvokasta. Työpaja sopii myös tiedon jakamiseen. Jos pääsen itse valitsemaan, hyödynnän alkuvaiheessa mieluiten haastatteluita, koska niiden avulla sitouttaminen on tehokkainta. Haastatteluihin ei kuitenkaan koskaan kannata mennä tyhjin käsin, vaan johdolta saatava aika on syytä hyödyntää valmistautumalla huolellisesti. Yleensä keskusteluita pitää pohjustaa nostamalla esille potentiaalisia riskejä ja skenaarioita. Tämä saa osallistujat orientoitumaan oikein ja ajattelemaan asioita hetken jatkuvuudenhallinnan kannalta.

Tässä vaiheessa voidaan haastateltaville kertoa riskeistä karkeasti ja pyrkiä hakemaan johdon näkemystä siitä, millaisia katkoja liiketoiminta heidän näkökulmasta kestää. Tämä näkökulma on erittäin tärkeä, koska alemmalla tasolla työskentelevät tyypillisesti yliarvoivat oman toimintonsa tärkeyden. Johdon näkökulma tuo asioihin perspektiiviä. Samalla saadaan johdon näkemystä siitä, mikä on organisaatiolle viime kädessä tärkeää.  Keskustelun myötä johtajat myös tyypillisesti sitoutuvat hankkeeseen, koska he ovat päässeet kertomaan näkemyksiään.

Tulokset on syytä dokumentoida. Itse suosin yhteenvetojen laatimista. Tämä säästää työaikaa verrattuna siihen, että dokumentoidaan tarkasti jokainen haastattelu. Kun kasaa yhteen eri ihmisten esittämiä ajatuksia, saa hyvän käsityksen siitä, mikä on organisaatiossa tärkeää ja millaiset näkemykset painottuvat. Usein näitä yhteenvetoja luetaan innolla ja niihin saa paljon kommentteja.

 

Järjestelmien kriittisyyden arvioiminen

Seuraava mahdollinen vaihe on tietojärjestelmien kriittisyyden arvioiminen. Tässä vaiheessa voidaan tehdä myös liiketoiminnan vaikutusanalyysi eli BIA. Kun keskustelen asiakkaiden kanssa, vain osa on luokitellut järjestelmänsä kriittisiin ja vähemmän kriittisiin. Kun kysyn, onko luokittelu tehty yhdessä liiketoiminnan kanssa, myöntävästi vastaa vielä harvempi joukko. Olisi erittäin tärkeää tehdä tämä vaihe nimenomaan liiketoiminnan kanssa. IT on tyypillisesti hyvä arvaamaan järjestelmien kriittisyyttä. Ongelma piilee siinä, että kriittisyydestä ei ole sovittu yrityksessä yhdessä liiketoiminnan ja IT:n välillä. Tämä vaihe on haastatteluiden ohella hyvä työkalu yhteistyön tiivistämiseen liiketoiminnan ja IT:n välillä.

Järjestelmien kriittisyyden arvioimisen yhteydessä voidaan kerätä monia tietoja: Sallittujen käyttökatkojen lisäksi voidaan kerätä tietoa siitä, milloin sovelluksia käytetään, millaisia arkistointi- tai tietoturvavaatimuksia sovelluksen tietoihin kohdistuu, miten sovellukset keskustelevat keskenään ja mitä IT-infraa sovellukset käyttävät. Tämä on tärkeää, koska yhden sovelluksen kriittisyys vaikuttaa muiden sovellusten kriittisyyteen.

Käytännössä homma menee niin, että pidetään tarpeellinen määrä työpajoja, joissa kerätään järjestelmien perustietoja, tietoja sovellusten kriittisyydestä ja sovellusten välisiä integraatioita. Työpajat onnistuvat parhaiten, jos mukaan saadaan sekä IT:n edustajia, että liiketoiminnan edustajia. Mikäli sovellusarkkitehtuuri ei ole erittäin monimutkainen, jo yhden päivän aikana voidaan usein käydä monia sovelluksia läpi.

Työ jatkuu IT:n kanssa. Nyt piirretään auki, mitä IT-infraa sovellukset käyttävät. Tämän tiedon keräämisestä on hyötyä jatkuvuuden hallinnan lisäksi IT:n muutoksenhallinnassa. Kun tiedetään mitä infrakomponentteja kukin sovellus tarvitsee, on helpompi suunnitella muutoksia ja tietysti selvitellä mahdollisia vikatilanteita.

Tulokset dokumentoidaan siten, että saadaan kuvattua liiketoiminnan edustajien näkemys järjestelmien kriittisyydestä . Tästä voidaan johtaa infran kriittisyys yksittäisille infrakomponenteille. Tämä menetelmä on erittäin hyödyllinen työvaihe myös kaikille, jotka ostavat IT-palveluita, koska menetelmä mahdollistaa SLA-vaatimusten johtamisen liiketoiminnan tavoitteista. Lue lisää järjestelmien kriittisyyden arvioimisesta täältä.

Johtopäätösten tekeminen ja tavoitteista sopiminen

 

Kun yhdistetään johdon haastatteluiden tulokset ja järjestelmien kriittisyysanalyysin tulokset, saadaan yrityksen ylimmän johdon näkemys yhdistettyä liiketoimintayksiköiden näkemykseen. Parhaassa tapauksessa tulokset ovat yhdenmukaisia, mutta joskus tuloksia pitää “normalisoida” eli sovittaa yhteen niin, että kokonaisuus on linjassa.

Tässä vaiheessa on jo yleensä hyvin selvillä se, miten kaukana tai lähellä tavoitteet ovat IT-ympäristön nykytilasta. Tulokset on hyvä käydä läpi yhdessä johdon kanssa ja sopia realistisista tavoitteista hankkeelle. Näin asetetut tavoitteet kuvastavat organisaation näkemystä tavoitteista, jotka voidaan perustella liiketoiminnan näkökulmasta. Kun myöhemmin päästään tekemään päätöksiä investoinneista, on keskustelu huomattavasti helpompi, jos jo tavoitteet on asetettu liiketoiminnan etua katsoen.

Vielä ei kuitenkaan olla valmiita päättämään sopivista ratkaisuista. Kerron maaliskuussa julkaistavassa kirjoituksessa siitä, miten ratkaisuihin päädytään niin, että ratkaisuihin johtava ketju kestää kriittisenkin tarkastelun.

 

Jos pidit tästä artikkelista, myös seuraavat artikkelit voivat olla kiinnostavia:

Tilaa uutiskirjeeni

Saat tiedon uusista artikkeleista suoraan sähköpostiisi.

Annan luvan tallentaa tietoni ja hyväksyn tietosuojakäytännön.