”Oho”, sanoi IT-asiantuntija

IT-asiantuntijan tehtävä: Pankin suurtietokoneen (mainframe) CA-7 eräajo-ohjelmiston rutiinipäivitys. Asiantuntijatyön lopputulos: Inhimillinen virhe ja arviolta 100 miljoonan euron suorat kustannukset ja korvausvaatimukset pankille, jonka 17 miljoonaa asiakasta ei pystynyt käyttämään pankkitilejään viiteen päivään. Tällaisia IT-haasteita koki juhannusviikolla Iso-Britanniassa The Royal Bank of Scotland (RBS) pankki.

RBS:n pääjohtaja Stephen Hester on liiketoimintajohdolle tyypillisesti päässyt valittelemaan tapahtunutta: ”Asiat menevät joskus pieleen. Asiat menevät pieleen IT:n kanssa.” On luontevaa selitellä jälkikäteen ikään kuin mitään ei olisi ollut tehtävissä ja vedota IT-asioissa ”force majeure”-ajatteluun. Todellisuudessa kuitenkin oikein suoritetuilla laadun (quality management) ja riskien hallinta (risk management) toimenpiteillä sekä selkeällä IT-hallinnointimallilla (IT governance model) voidaan kustannustehokkaasti ehkäistä sellaisten riskien realisoituminen, joilla on potentiaaliset 100 miljoonan euron kustannukset.

Ohjelmistopäivityksen onnettomaan lopputulokseen ovat todennäköisesti vaikuttaneet ainakin tehtävän tyyppi (rutiinitehtävä), tehtävän määrittely (epäselvät toimintatavat), tehtävä suorittajan osaaminen (puutteellinen), tehtävän suorittamisen olosuhteet (kiire), tehtävän hallinnointi (epäselvät vastuut), tehtävän riskikategoria (väärin arvioitu) sekä tehtävän laatukriteerit (puutteellisesti hallittu).

Käytännössä tapahtumassa oli kyse siitä, että eräajo-ohjelmiston päivitys ei syystä tai toisesta onnistunut. Julkinen tarina ei kerro oliko päivityksen toimivuus ennen tuotantoympäristöä varmistettu testiympäristöissä. Oli tai ei, niin joskus IT:n kanssa tulee yllättäviä ongelmia ja niihin vain pitää varautua. Päivityksen epäonnistumisen jälkeen palautusohjeistusta (roll-back procedure) ei noudatettu, vaan jostain syystä asiantuntija poisti järjestelmästä 100 miljoonaa jonossa odottavaa transaktiota (tilisiirtoa) ja ilmeisesti myös eräajo-ohjelmiston koko konfiguraation.

Julkinen tarina ei myöskään kerro oliko palautusohjeistusta ylipäätään laadittu, oliko se ymmärrettävä ja tunsiko asiantuntija kyseisen ohjeistuksen. Ongelman laajuuden selviämisen jälkeen ympäristöön piti asentaa toimiva versio CA-7 ohjelmistosta, ohjelmiston konfiguraatio piti tehdä uudelleen ja tuhotut transaktiot piti palauttaa jonoon. Samalla jonossa olevien transaktioiden määrä kasvoi noin 100 miljoonalla päivässä. Lisähaasteen selvitykseen toi se, että transaktiot piti ajaa tileille alkuperäisessä järjestyksessä (tuhotut tiistain transaktiot ennen keskiviikon transaktioita jne.). Kolmen päivän päästä eräajojen tekniset ongelmat oli korjattu, mutta transaktioiden järjestyksessä oli edelleen korjattavaa.

Iso-Britanniassa RBS:n IT-ongelmat ovat herättäneet keskustelua paitsi pankin asiakkaille aiheutuneista käytännön haitoista, myös RBS:n vuonna 2010 tekemästä päätöksestä siirtää IT-toimintojaan Intiaan. RBS:lta aiemmin irtisanotut isobritannialaiset IT-asiantuntijat ovatkin kärkkäästi kommentoineet julkisuudessa, että nyt kohdatut ongelmat ovat väistämätöntä seurausta RBS:n johdon aiemmista päätöksistä luopua paikallisesta edistyneestä IT-osaamisesta, jolla oli kymmenien vuosien kokemus kyseisistä tietojärjestelmistä. RBS on jyrkästi kiistänyt, että intialaisilla olisi mitään tekemistä ongelmien kanssa. Eihän IT-asioissakaan ole kyse olekaan siitä kuka tekee vaan siitä mitä ja miten tehdään.

Tietoviikko

Äläkä saata meitä IT-ekosysteemiin

Helsingin kaupungin laskutuksessa on ollut haasteita sen jälkeen, kun kaupungin taloushallinto siirtyi viime vuodenvaihteessa käyttämään uutta tietojärjestelmää. Julkisuuteen tihkuneiden tietojen mukaan tällä hetkellä noin 250.000 laskua on lähettämättä kaupunkilaisille. Tuon perusteella voi arvioida, että saatavien arvo on yhteensä muutamia kymmeniä miljoonia euroja, mikä ei aiheuta korkokuluja kuin parikymmentätuhatta euroa viikossa. Sehän ei ole Helsingin kokoiselle kaupungille paljon mitään!

IT-toimittajat levittelevät näyttävästi käsiään – ainakin silloin, kun eivät ole niitä pesemässä. Ohjelmistotoimittajan edustaja on selvittänyt tilannetta medialle: ”Me olemme myyneet järjestelmän. Ekosysteemi on sen toimittanut.” Asiakkaan kuullen, kun ei voi toimittaja sanoa, että asiakas ei vain osaa.

Projektitoimittajan edustajan lausunnot kuulostavat yhteistyöhaluisemmilta: ”Helsingin kaupunki on meille tärkeä asiakas. Laitamme asiat kuntoon.” Mutta mikä on uskottavuus, kun sama toimittaja on yrittänyt laittaa asioita kuntoon jo puoli vuotta. Ja sitä ennen toimittaja on tehnyt yli vuoden kestoisen toteutusprojektin, jossa piti tehdä asiat kerralla kuntoon. Asiakkaan kuullen, kun ei voi toimittaja sanoa, että emme vain osaa.

Mutta mitä Helsingin kaupunki olisi voinut tehdä toisin? Ottamatta kantaa ohjelmistovalintaan, lopputuloksen perusteella vaikuttaa, että A) projektitarjous on ollut epärealistinen (kattavuus, aikataulu, budjetti tai resursointi), tai B) projektin toteutuksen aikana ei ole tehty kokonaisvaltaista laadunvarmistusta ja riskienhallintaa. Hankkimalla ulkopuolista riippumatonta neuvonantoa riskien- ja laadun hallitsemiseksi ongelmilta olisi vältytty, tai vähintään ne olisi huomattu ja hoidettu aiemmin.

Joskus projektin ohjausryhmä päättää laskelmoidusta liiketoiminnallisesta riskistä ottamalla tietojärjestelmän käyttöön ilman täyttä varmuutta sen toimivuudesta. Näin toimimalla yleensä priorisoidaan kustannukset, aikataulu tai hallitaan organisatorisia riippuvuuksia. Useimmiten tällainen päätös kuitenkin tehdään kovassa paineessa tiedostamatta päätökseen liittyviä riskejä. Niinpä säästöstä, joka saavutetaan ottamalla keskeneräinen järjestelmä käyttöön, tulisi vähentää odotettavissa olevan hätätyön sekä muut kustannukset – Helsingin kaupungin tapauksessa pääoman korkokustannukset. Mainehaittaa ei varmaan ainakaan julkisella sektorilla laskelmissa huomioida.

Entä mitä Helsingin kaupungin pitäisi tehdä nykyisessä tilanteessa? Tietojärjestelmien tuotanto-ongelmien selvittäminen on hyvin harvoin syvällistä teknistä työtä – toiminnan johtamiseen tekninen yleissivistys riittää. Ongelmaselvityksessä onnistuu, kun huolehditaan kokonaisuuden ymmärtämisestä, kommunikoinnin avoimuudesta ja selkeydestä, yli organisaatiorajojen toimimisesta ja erilaisten ristiriitojen sovittelemisesta. Ulkopuolinen riippumaton neuvonantaja voi auttaa asiakasta edellä mainituissa tehtävissä sekä tuoda ongelmanselvitykseen läpinäkyvyyttä, tavoitteellisuutta ja tehokkuutta.

No, töitä tehrähän ja veroja maksetaha… Päästä meidät IT-ekosysteemistä. Aamen.

Lisätietoja:
HS, IT-viikko