IT-hankinnan sudenkuoppa #1: monimutkaistaminen

Esittelin aiemmassa blogissa Riippuvaisen IT-toimittajan keittokirjasta käytännön haasteita, joita kohdataan erityisesti riippumattoman neuvonannon puuttuessa IT-ratkaisuiden hankinnoista. Tässä ja muutamassa seuraavassa blogissa esittelen tarkemmin riippuvaisten IT-toimittajien usein käyttämien kikkojen sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Useimmat IT-toimittajat eivät johda asiakastaan tarkoituksellisesti harhaan. Ongelmiin myötävaikuttavat myös ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Uutta tietojärjestelmää hankittaessa monimutkaistaminen on usein ensimmäinen eteen tuleva sudenkuoppa, johon on vaara ajautua. Kyse on siitä, että IT-toimittaja tarjoaa asiakkaalle monimutkaisempaa ratkaisua kuin asiakas oli alunperin ajatellut hankkivansa ja todellisuudessa olisi asiakkaan etu. Ratkaisun monimutkaisuus voi syntyä esimerkiksi laajemmasta toiminnallisuudesta, edistyneemmästä teknisestä toteutuksesta tai heikosta sopivuudesta kokonaisarkkitehtuuriin. Joka tapauksesa ratkaisun monimutkaisuus vähentää sen luotettavuutta ja kustannustehokkuutta.

Miksi sitten toimittaja tarjoaa monimutkaisempaa ratkaisua asiakkaalle? Siinä, missä asiakkaan etu on saada liiketoimintatarpeen täyttävä, luotettava ja kustannustehokas ratkaisu, IT-toimittajan yksioikoinen etu on myydä ratkaisu, jonka toteuttaminen ja ylläpito vaativat mahdollisimman paljon laskutettavaa työtä. Tähän tavoitteeseen toimittaja pääsee monimutkaistamalla. Monimutkaistaminen tapahtuu huomaamatta, koska ratkaisun luotettavuuden ja kokonaiskustannuksen (total cost of ownership) arviointi ennen ratkaisun toteutustyön aloittamista ja osin myös toteutuksen jälkeen on erittäin haastavaa.

Varsinkin silloin, kun tietojärjestelmähanke on liiketoimintakriittinen ja investointina suuri, niin myös liiketoimintajohto on mukana hankinnassa. Kun kyseessä voi olla yrityksen tärkein IT-investointi vuosikymmeneen, asiakas joskus jopa haluaa kuulla IT-toimittajalta, että ratkaisua voidaan laajentaa uusilla toiminnallisuuksilla, joita ei alun perin ollut otettu huomioon määrittelyssä. Koska asiakkaan odotuksena on, että hankkeesta tulee suuri ja haastava, toimittaja mielellään ruokkii tätä odotusta tarjoutumalla toteuttamaan ratkaisun teknisesti edistyneemmin (esim. korkean käytettävyyden arkkitehtuurilla (high availability architecture, HA) tai geneerisin palvelurajapinnoin (service-oriented architecture, SOA)).

Miten monimutkaistaminen voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. tekemällä ratkaisun vaatimusmäärittely toimittaja- ja teknologiariippumattomasti sekä liiketoimintalähtöisesti (sis. toiminnalliset ja ei-toiminnalliset vaatimukset),
  2. arvioimalla tarjousvaiheessa toimittajien vaatimusmäärittelyyn ehdottamat laajennukset/muutokset sekä ratkaisun luotettavuuden että projektitoteutuksen kustannustehokkuuden kannalta,
  3. panostamalla projektityöskentelyn tuottavuuteen ja tehokkuuteen sekä laadun ja riskien hallintaan edistyneiden teknisten ratkaisuiden sijaan (jos tekniset ratkaisut eivät kriittisesti arvioiden läpäise listan kohtaa 2).

IT-hankinnoissa usein tahattomastikin syntyvän monimutkaistamis-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää määrittely- ja hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohto kokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio voi tehostaa viestintää IT-toimittajien kanssa ja saada hankkeen valmistelu- ja toteutusvaiheisiin riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

Valhe, emävalhe, IT-KPI?

Usein sanotaan, että et voi johtaa, mitä et mittaa. Tämä pätee myös IT-projekteihin, tietojärjestelmiin ja tietohallintoon. Hyvin valittuja ja jalkautettuja mittareita (Key Performance Indicator, KPI) seuraamalla voidaan varmistaa, että tiettyyn IT-projektiin, IT-palveluun tai tietojärjestelmään sijoitetut resurssit tuottavat odotettuja tuloksia odotetulla riskitasolla. Jotta KPI:sta saadaan maksimaalinen hyöty, organisaation tavoitteisiin ja toimintatapoihin kytkeytyvien KPI:den valitseminen ja määrittely tulee tehdä huolellisesti.

Yleisimmin käytössä olevat IT-KPI:t liittyvät kustannus- ja aikatauluseurantaan tai esimerkiksi toimittajasopimusten kriteereihin, kuten tietojärjestelmän palvelutasoon tai tukipalvelun vasteaikoihin. Varsinainen hyöty KPI:sta syntyy laajentamalla mittaristo kattamaan myös tietohallinnon muita tavoitteita sekä määrittelemällä seuranta- ja raportointiprosessi KPI:den ympärille.

KPI:ta voidaan luokitella ylätason kategorioihin esim. IT:n liiketoimintahyödyn (strateginen, taktinen, operatiivinen), IT-elinkaaren vaiheen (konsepti, projekti, palvelu) tai raportin käyttäjän (liiketoimintajohto, IT-johto, IT-päällikkö) mukaan. Organisaation tavoitteita vastaava mittaroinnin kehittämisen painopistealue on hyvä määritellä KPI-kategorian tasolla. Kun fokus on selvillä, olemassa olevia viitekehyksiä ja KPI-kirjastoja voidaan käyttää pohjana organisaatiolle parhaiten sopivien KPI:den määrittelemiseksi.

KPI:t eroavat muusta raportointitiedosta niiden jalostusasteen ja kontekstuaalisuuden kautta. KPI:t jalostetaan saatavilla olevasta tiedosta siten, että ne tiivistävät tietyn toiminnon tavoitteiden kannalta keskeiset tiedon yhteen tai muutamaan arvoon (esim. satojen erillisten numerojen sijaan). Toisaalta, KPI:hin liittyy aina konteksti, joka kertoo onko KPI:n arvo tavoitetason yläpuolella vai alapuolella, ja kuinka paljon (esim. meneekö hyvin vai erittäin hyvin).

KPI:den haasteet liittyvät usein esimerkiksi tiedon laatuun tai mittarointiprosessin jalkauttamiseen. Mittaroinnin keskeisin tavoite on tuottaa tietoa päätöksenteon tueksi. Tätä tavoitetta ei saavuteta, jos KPI-arvot eivät ole uskottavia raportin käyttäjälle (validiteetti) tai luvut heittelevät viikosta toiseen (reliabiliteetti). Tällöin voidaan ajautua tilanteeseen, jossa KPI:t eivät toimikaan tehokkaan viestinnän ja johtamisen välineenä, vaan ovat jatkuvan väittelyn kohteena esimerkiksi niiden vaikean tulkitsemisen tai epäluotettavuuden takia.

Reliabiliteetti ja validiteetti ovat erityisesti haasteena, jos mittarointia lähdetään kehittämään liian massiivisesti (mahdollisimman paljon KPI:ta) tai työkalukeskeisesti (mahdollisimman visuaalisia raportteja). Tällöin oikeiden KPI:den valitseminen ja tehokas raportointi- ja seurantaprosessin jää liian vähälle huomiolle. Lisäksi KPI:iden tulkinnanvaraisuuksia ja keskinäisiä riippuvuuksia ei tällöin useinkaan ymmärretä tarpeeksi hyvin korjaavia toimenpiteitä ja johtamista varten.

Hyvin määriteltyjen ja jalkautettujen KPI:den avulla yritys voi seurata suunnitelmien ja budjettien toteutumista, hallita suorituskykyä ja riskejä sekä varmistaa korjaavien kehitystoimenpiteiden vaikutukset. KPI:sta on suurta hyötyä myös toiminnan tavoitteiden asettamisessa ja viestinnässä IT:n suorituskyvystä organisaatioin eri sidosryhmille.

Tärkeintä on muistaa, että IT:n mittarointiinkin pätee: sitä saa mitä mittaa.

Suuri, suurempi, IT-projekti…

Projekti on olemassaoloajaltaan ja resursseiltaan rajattu tilapäinen organisaatio, joka tuottaa määritetyt tuotokset. Juuri ajan ja resurssien rajallisuuden takia yksi projektinhallinnan tärkeimmistä osa-alueista on projektin laajuuden hallinta (scope management). Se tarkoittaa projektin tuotosten (deliverables) riittävän tarkkaa määrittelyä (projektin alussa) ja rajaamista (projektin aikana).

Panostus projektin laajuuden hallintaan on kriittistä projektin onnistumiselle, koska projektin laajuuteen sisältyvien tuotosten lukumäärän lisääminen tai monimutkaistaminen kasvattaa projektin laajuutta. Projektin laajuuden kasvattamisella on lähes poikkeuksetta vaikutusta projektin budjettiin ja aikatauluun. On yhtä tärkeää (tai jopa tärkeämpää) määritellä, mitä projektin laajuuteen ei sisälly kuin mitä siihen sisältyy. Yhden projektin laajuuteen sisältymättömät tuotokset voivat sisältyä toisen projektin laajuuteen.

IT-projektin tuotos on usein käyttöönotettu tietojärjestelmä. IT-projektin laajuuden voi määritellä esimerkiksi sen mukaan, mitä ominaisuuksia tietojärjestelmä tarjoaa käyttäjälle tai mitä tehtäviä (työtä) projektiin kuuluu. Esimerkiksi CRM-järjestelmän toteuttavan projektin laajuuteen voi sisältyä asiakkaiden yhteystietojen hallinta (=ominaisuus) ja asiakas master datan laadun parantaminen (=tehtävä), kun taas CRM:n integraatio ERP:hen (=ominaisuus) ja järjestelmän suorituskykytestaus (=tehtävä) voivat olla projektin laajuuden ulkopuolella.

Juuri IT-projektien riittävän tarkan määrittelyn haastavuuden takia ennen projektin aloittamista IT-projekteissa on usein kova paine projektin laajuuden kasvamiselle projektin aikana. IT-projektin laajuutta määriteltäessä on hyödyllistä tarkastella sitä kolmesta näkökulmasta:

  • liiketoiminnallinen laajuus (business scope)
  • prosessilaajuus (process scope)
  • tekninen laajuus (technical scope)

IT-projektin liiketoiminnallinen laajuus kuvaa projektin tuotoksia liiketoiminnan tavoitteiden ja tarpeiden kannalta. Esimerkki projektin liiketoiminnallisesta laajuuden määrittelystä voisi olla asiakastilausten syöttäminen asiakaskäynnin yhteydessä.

IT-projektin prosessilaajuus kuvaa projektin tuotoksia toiminnallisuuksien ja vaatimusten kannalta. Esimerkki projektin prosessilaajuuden määrittelystä voisi olla asiakkaan pyytämien tuotteiden varastosaldojen tarkastaminen ERP-järjestelmästä.

IT-projektin tekninen laajuus kuvaa projektin tuotoksia IT-arkkitehtuurin, toimintojen ja konfiguraatioiden kannalta. Esimerkkejä projektin teknisen laajuuden määrittelystä voisivat olla sovelluksen käytettävyys Android-älypuhelimella tai vaikkapa asiakastilauksen two-phase commit ERP-järjestelmään (tilaus tallennetaan vain, jos kaikki tilausrivit voidaan täyttää suoraan varastosta).

Tyypillisimmät IT-projektien laajuuden hallinnan haasteet johtuvat siitä, että projektin laajuus on projektin ohjausryhmän kannalta selkeintä linjata korkeammalla tasolla (liiketoiminnan laajuus). Toisaalta projektin onnistumisen kannalta projektin laajuus on kriittisintä määritellä prosessi-tasolla ja laajuutta on kriittisintä rajata teknisellä tasolla.

Seuraavat IT-projektin laajuuden hallinnan tasoihin liittyvät haasteet ovat tyypillisiä:

  • jos projektin liiketoiminnallista laajuutta korostetaan, projektin prosessilaajuutta ja teknistä laajuutta on vaikea määritellä ja rajata (koska ”kaikki” sisältyy liiketoiminnalliseen laajuuteen)
  • jos projektin prosessilaajuutta ei määritellä tarpeeksi tarkasti, sitä on vaikea rajata projektin aikana, kun ilmenee uusia tarpeita ja kehitysideoita (koska ei ole riittävän tarkkaa lähtökohtaa)
  • jos projektin teknisen laajuuden rajaamiseen ei kiinnitetä tarpeeksi huomiota, tuloksena voi olla tilanteesta riippuen joko liian yksinkertainen (käyttökelvoton) tai liian monimutkainen (tarpeeton) tekninen ratkaisu (koska ei huomioida projektin laajuuden ylempiä tasoja)

Projektin laajuuden hallinnan tärkeys korostuu erityisesti jo lähtökohtaisesti laajuudeltaan suurissa projekteissa, riippuvuuksien hallinnassa projektien välillä sekä projekteissa, joiden toteutukseen osallistuu useita toimittajia. Projektipäälliköltä vaaditaan huolellista projektin laajuuden muutosten hallintaa (change control) ja projektin ohjausryhmältä ymmärrystä kaikista kolmesta projektin laajuuden tasosta. Näin päätökset projektin laajuuden muutoksista voidaan tehdä perustellusti.

Tietojärjestelmäintegraatioiden ihanuus ja hurjuus

Kaikki nykypäivän tietojärjestelmäkokonaisuudet sisältävät integraatioita useiden eri tietojärjestelmien välillä. Käytännössä tietojärjestelmäintegraatiossa on kyse järjestelmissä olevan tiedon (datan) siirtämisestä järjestelmien välillä tietoverkon avulla. Integraatiossa tieto luetaan ohjelmallisesti lähdejärjestelmästä, jonka jälkeen tietoa voidaan muokata ennen sen tallentamista kohdejärjestelmään.

Integraatioiden avulla useista tietojärjestelmistä koostuva kokonaisuus saadaan tarjoamaan käyttäjilleen haluttu toiminnallisuus. Esimerkiksi verkkopankissa asioidessaan käyttäjän käyttöliittymä integroituu useisiin taustajärjestelmiin, joista yhdessä voi hallita maksuja, toisessa tehdä osakekauppaa ja kolmannessa käsitellä laina-asioita. Lisäksi kaikki edellä mainitut taustajärjestelmät integroituvat tilitransaktioiden hallintajärjestelmään, joka edelleen integroituu mm. vähittäiskauppojen maksupäätteisiin, pankkiautomaatteihin ja toisten pankkien tietojärjestelmiin.

Tietojärjestelmäintegraatiot ovat haastavia, koska integroitavat tietojärjestelmät voivat käyttää samaa tietoa eri tarkoituksiin, käsitellä samaa tietoa eri tavoin ja perustua eri teknologioihin. Halutun kokonaistoiminnallisuuden varmistamiseksi integraatioita toteutettaessa täytyy määritellä:

  1. tietosisällön rakenne (tietomalli, keskinäiset suhteet, attribuutit)
  2. tiedon käsittelysäännöt (tiedon oikeellisuus, omistajuus, transaktiosäännöt)
  3. tiedonsiirron tekniset periaatteet (väylät, standardit, protokollat, tilallisuus)

Esimerkkinä tietosisällön rakenteeseen (kohta 1 yo. listassa) liittyvistä integraatiohaasteista toimii e-reseptin suunnitteluvirhe, jonka takia osa reseptille tarkoitetusta tekstistä voi jäädä puuttumaan reseptiltä. Ongelman syynä lienee, että tietosisältö (mm. tietokenttien pituudet) ei ollut yksiselitteisesti ja yhtenäisesti määritelty kaikille e-reseptin tietoja käsitteleville järjestelmille ja osassa tietoa käsittelevistä järjestelmistä reseptin tekstikenttien merkkimääriä on rajoitettu (ks. YLE). Tästä seuraa, että vaikka lääkäri pystyykin onnistuneesti syöttämään reseptin tiedot järjestelmään käyttöliittymänsä kautta, jossain integraatioketjun vaiheessa järjestelmä ei pystykään tallentamaan tiedosta kuin esim. ensimmäiset 50 merkkiä. Tämän seurauksena apteekin käyttöliittymässä näkyy tietyssä kentässä vain 50 merkkiä.

Esimerkkinä tiedon käsittelysääntöihin (kohta 2 yo. listassa) liittyvistä integraatiohaasteista toimii Puolustusvoimien SAP HR –järjestelmän käyttöönotto puutteellisesti testattuna, jonka takia tuhansien työntekijöiden palkanmaksussa oli virheellisyyksiä ja viivästymisiä. Ongelman syynä lienee, että tiedon käsittelysäännöt (mm. tiedon oikeellisuuden varmistaminen) oli puutteellisesti määritelty ulkoisen tiedon tuonnin kannalta (toisista järjestelmistä), jonka takia uudessa järjestelmässä oli työntekijöiden peruspalkassa, tehdyissä työtunneissa ja pankkitileissä virheellisyyksiä (ks. HS tai Tietokone ). Tästä seurasi, että ajettaessa palkanlaskenta-ajo SAP HR –järjestelmässä tulokset olivat virheellisen tiedon takia väärin, vaikka itse ajon logiikka olisikin oltu testattu toimivan täydellisesti.

Esimerkkinä tiedonsiirron teknisiin periaatteisiin (kohta 3 yo. listassa) liittyvistä haasteista toimii suomalaisten teleoperaattoreiden kapasiteetin, VR:n maksupäätelaitteiden ja maksukorttien EMV-standardin vaatimusten keskinäiset riippuvuudet, jonka takia VR:n päätti lopettaa Visa Electronin hyväksymisen junissa (ks. YLE). Ongelman syynä lienee, että joko Visa Electron-kortille pankin online-tarkistuksen vaativa EMV-standardi tai VR:n maksupäätelaite ei salli sellaisia teknisiä viiveitä (latensseja), pakkausta tai protokollaa, jolla tietojärjestelmäkokonaisuus toimisi varmuudella suomalaisten mobiiliverkkojen kattavuudella ja kapasiteetilla. Tästä seuraa, että Visa Electron ei toimi aina junassa, vaikka tietosisällön rakenne ja tiedon käsittelysäännöt onkin pilkuntarkkaan määritelty.

Riippuen IT-projektista tietojärjestelmien väliset integraatiot saattavat muodostaa jopa puolet projektin kokonaistyömäärästä (verrattuna siihen, että tehtäisiin yksi monoliittinen sovellus, mikä ei usein ole edes käytännössä mahdollista). Siksi on tärkeää, että järjestelmän toiminnalliset vaatimukset ja käyttötapaukset kytketään integraatioiden suunnitteluun jo projektin aikaisessa vaiheessa. Tietojärjestelmäintegraatioissa onnistumisen varmistamiseksi on olemassa lukuisia teknisiä ja metodologisia hyviä käytäntöjä. Mikään ei kuitenkaan korvaa tärkeintä menestystekijää eli avointa, selkeää ja tehokasta osapuolten (usein eri toimittajien) välistä viestintää.

Onko tavoitteenasi IT:n tuottavuus vai tehokkuus?

Edellisessä blogissani kirjoitin IT-hankintojen arvioimisesta kolmen keskeisen kriteerin eli laadun, kustannusten ja riskitason kannalta. Tässä blogissa käsittelen IT:n laatua, jossa voidaan erottaa kaksi ulottuvuutta: tehokkuus ja tuottavuus. Käytännön kannalta voidaan ajatella, että tehokkuus liittyy IT-projektin (= järjestelmän aikaansaamiseksi tehtävä työ) laatuun ja toisaalta tuottavuus liittyy IT-ratkaisun (= tekninen tietojärjestelmä) laatuun.

Ensimmäinen laadun ulottuvuus, tehokkuus, liittyy siihen, että tehtäväksi päätetyt asiat tehdään oikein (”do the things right”). Tehokkuuteen liittyviä käytännön tavoitteita ovat esimerkiksi IT-projektin pysyminen aikataulussa, parhaiden käytäntöjen mukainen tekninen työ (esim. toteutettavan IT-ratkaisun ylläpidettävyys ja skaalautuvuus) sekä riittävä ratkaisun toiminnallisen laadun varmistaminen kattavalla ja järjestelmällisellä testauksella.

Toinen laadun ulottuvuus, tuottavuus, liittyy siihen, että lähtökohtaisesti suunnitellaan tehtävän oikeita asioita (”do the right things”). Tuottavuuteen liittyviä käytännön tavoitteita ovat esimerkiksi IT-ratkaisun toimintojen kattavuus ja helppokäyttöisyys, järjestelmässä käsiteltävän tiedon oikeellisuus sekä investoinnin takaisinmaksuajan (business case) toteutuminen konkreettisten hyötyjen kautta.

Seuraavaksi kaksi projektiesimerkkiä, joista ensimmäisessä on haasteita tehokkuuden ja jälkimmäisessä tuottavuuden kanssa.

Arevan Olkiluotoon rakentama ydinreaktori on myöhästymässä seitsemän vuotta (YLE). Projektin tilanne on seurausta tehokkuuteen liittyvistä laadullisista haasteista. Projektin aikataulu venyy, koska vaadittuja asioita ei ole tehty oikein eli tehokkaasti. Projektin haasteena ei ole varsinaisesti tuottavuus, koska (toivottavasti) projektin tuotoksena lopulta saadaan toimiva ja vaatimukset täyttävä ydinvoimala. Osin nimenomaan tuottavuuteen liittyvän riskin minimointi (eli sen välttäminen, että saadaan epäluotettavasti toimiva ydinvoimala) vähentää tehokkuutta. Näennäisesti projektin kustannusriski on hallittu kiinteähintaisella sopimuksella. Mutta kai tilaajaorganisaation omien resurssien sitominen projektiin suunniteltua pidempään, investoinnin rahoituskustannukset ja menetetty sähkön myynnin liikevaihto maksavat jotakin? Kyllä, TVO:n ja Arevan meneillään olevasta välimiesmenettelystä päätellen noin kaksi miljardia euroa.

Toinen käytännön esimerkki edustaa tuottavuuteen liittyvää laadullista haastetta. Yhdysvalloissa on ollut viime vuosina meneillään mittava armeijan ERP-järjestelmien uudistus. Viimeisimpänä ”virstanpylväänä” voidaan pitää sitä, että ilmavoimat päätti lopettaa projektinsa kesken seitsemän vuoden jälkeen (Tietoviikko). Projektin tilanne on seurausta realisoituneesta tuottavuus-riskistä, mikä on jokaisen projektin tilaajan painajainen: joudutaan palamaan takaisin lähtöruutuun. Ilmavoimien projektin tapauksessa aikaa menetettiin noin 7 vuotta ja rahaa yli miljardi dollaria. Projektin haaste ei ollut, että lopputuloksena olisi saatu laadullisesti huonompi ratkaisu kuin mitä tavoiteltiin, vaan se, ettei saatu yhtään mitään.

Usein tuottavuuteen liittyviin haasteisiin yhdistyy myös tehokkuus-haasteita, mutta ei aina. Se, että projekti ei tuota oikeita tuotoksia, ei tarkoita välttämättä sitä, etteikö tekeminen olisi itsessään voinut olla tehokasta. Esimerkiksi tehokkaasti toteutetut osakokonaisuudet voidaan saada valmiiksi ajallaan (=tehokkaasti) ja tekemään suunniteltuja asioita (=tuottavasti) kokonaisuuden silti toimimatta.

Edellä kerrotut projektiesimerkit ovat äärimmäisiä ja vastaavanlaisia tilanteita kohdataan melko harvoin. Esimerkit kuitenkin auttavat konkreettisesti ymmärtämään tehokkuuden ja tuottavuuden eron. IT-projekteissa tuottavuus on tyypillisesti tehokkuutta tärkeämpää, kun tuotettavan IT-ratkaisun hyödyt ovat merkittäviä (lyhyt takaisinmaksuaika) tai investointi on erittäin suuri (ei varaa epäonnistua). Tehokkuus on puolestaan usein tuottavuutta tärkeämpää, kun projektin tuotos on liiketoiminnan kannalta vähämerkityksellinen (kunhan se toimii) tai projekti nähdään suurena kulueränä (tiukka ja suurehko budjetti).

Helppo nakki: 1,8 miljardin IT-projekti

Pääkaupunkiseudun kunnat ja HUS ovat lyöneet viisaat päänsä yhteen ja alkavat nyt toden teolla valmistelemaan kaikkien aikojen suomalaista IT-hanketta: uutta potilastietojärjestelmää, jonka kokonaisarvoksi on arvioitu Sitran selvityksessä 1,2-1,8 miljardia euroa 10 vuoden ajalle. IT-alan mediassa ja blogeissa hanketta on ihmetelty, ja virkamiesten kunnianhimoisia suunnitelmia on verrattu mm. avaruussukkulan rakentamiseen. Käyn tässä blogissa hanketta läpi kolmen aiemmin esittelemäni IT-hankinnan tyypillisten sudenkuoppien valossa. Sudenkuopat aiheutuvat oikeanlaisen osaamisen ja riippumattoman näkökulman puuttumisesta hankkeen valmistelussa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta).

IT-hankinnan 1. sudenkuoppa: monimutkaistaminen

Tässä sudenkuopassa kyse on siitä, että päädytään monimutkaisempaan ja/tai laajempaan ratkaisuun kuin todellisuudessa olisi asiakkaan etu. Potilastietojärjestelmä-hankkeessa monimutkaistaminen on nähtävissä mm. siten, että

  • yksioikoisesti pyritään valmisohjelmiston (COTS) käyttöön arvioimatta niiden soveltuvuutta kokonaisuuden kannalta (kun pitäisi harkita myös vaihtoehtoa kehittää koko ratkaisu tai osia ratkaisusta räätälöitynä ohjelmistokehityksenä)
  • tavoitellaan maantieteellistä (kaikki kunnat) ja 100% toiminnallista kattavuutta alusta asti (kun pitäisi aloittaa ratkaisun pilotoinnilla yhdessä kunnan osassa / rajatulla toiminnallisuudella, ja laajentaa siitä)

IT-hankinnan 2. sudenkuoppa: vähättely

Tässä sudenkuopassa kyse on siitä, että projektin aikataulua ja/tai budjetin arvioinnissa tehdään vääriä arvioita ja päätöksiä ilman perusteita. Potilastietojärjestelmä-hankkeessa arviointivirheet ovat nähtävissä mm. siten, että

  • hankkeen suurta budjettia perustellaan vertaamalla sitä Suomen terveydenhuollon kokonaiskustannuksiin (kun pitäisi arvioida hanketta itsenäisesti top-down ja bottom-up sekä benchmarkata muihin vastaaviin IT-hankkeisiin)
  • vertailut Viroon, jossa vastaavia hankkeita on tehty muutamien kymmenillä miljoonien euron budjeteilla teilataan epäsopivina (kun pitäisi ymmärtää, että Virosta voitaisiin oppia parhaita käytäntöjä lain, toimintatapojen, toimittajien arvioinnin ja hankejohtamisen suhteen).

IT-hankinnan 3. sudenkuoppa: osaamisharha

Tässä sudenkuopassa kyse on siitä, että projektin vaatimaa osaamista arvioidaan väärin perustein ja projektiorganisaatio resurssoidaan tekijöillä, joilla ei ole tarpeeksi tai oikeanlaista osaamista projektin läpi viemiseksi. Potilastietojärjestelmä-hankkeessa arviointivirheet ovat nähtävissä mm. siten, että

  • hankkeen ohjaus on hajautettu kuntien terveyslautakuntiin ja hankejohtajana toimii lääketieteen tohtori, jonka tausta on terveysasemien operatiivisella puolella (kun valtion pitäisi ottaa hanke keskitettyyn ohjaukseen ja resurssoida projektitoimisto osaavilla tietohallinnon, toimialan prosessien ja tietojärjestelmäkehityksen ammattilaisilla).
  • ratkaisun pohjaksi vahvimpana kandidaattina oleva Epic-ohjelmisto perustuu 60-luvulla kehitettyyn MUMPS-ohjelmointikieleen, joka on rakenteeltaan monimutkainen, ohjelmointiprosessiltaan vanhanaikainen ja jonka osaamista ei ole Suomessa, eikä sitä ole järkevää hankkia (kun pitäisi harkita modernimpia esim. J2EE tai .NET-pohjaisia teknologioita).

Lopuksi

Julkisuudessa esitettyjen tietojen valossa täytyy valitettavasti todeta, että hyväntahtoisimmankin mahdollisen arvion perusteella Suomen potilastietojärjestelmä-hankkeeseen liittyy erittäin todennäköisiä ja vaikutuksiltaan katastrofaalisia riskejä. Esimerkiksi Iso-Britanniassa terveysministeriö kuoppasi viime syksynä vastaavanlaisen hankkeen sen jälkeen, kun siihen oli käytetty 10 vuotta ja yli 15 miljardia euroa. Mutta: mitä isot edellä, sitä pienet perässä!

Suurtenkaan tietojärjestelmähankkeiden toteuttaminen ei ole mahdotonta, mutta se on haastavaa. Tärkeintä on tehdä hankkeen valmistelutyö hyvin, määritellä projektin laajuus yksiselitteisesti tavoitteiden mukaiseksi, suunnitella projektin aikataulu ja tuotokset realistisesti sekä löytää projektiorganisaatioon oikeanlaista osaamista kuhunkin rooliin. Aloittaminen pilotoimalla ratkaisua paikallisesti, ratkaisun iteratiivinen kehitys ketterillä menetelmillä (agile), jämpti projektin laajuuden hallinta (scope management), keskitetty projektiohjaus sekä oikeaoppinen toimittajien työn johtaminen ja laadunhallinta takaavat suurenkin projektin onnistumisen. Näiden saavuttamisessa kokenut ulkopuolinen neuvonantaja voi olla tarpeen.

Riippuvaisen IT-toimittajan keittokirjasta…

Sitra teetti suurella palvelutoimittajalla selvityksen kuinka Suomessa voitaisiin yhtenäistää terveydenhuollon potilastietojärjestelmät ostamalla ulkomailta valmis järjestelmä. Selvityksessä parhaiten tarkoitukseen soveltuvaksi todettiin Epic-ohjelmisto. Myöhemmin selvisi, että selvityksen tehnyt palvelutoimittaja on merkittävä asiakkaalle suosittelemansa Epic-ohjelmiston toimittaja, ja jopa ainut mahdollinen toimittaja Suomessa.

”Riippumaton” selvitys, jossa päädytään selvityksen tehneen toimittajan omaan ratkaisuun on IT-toimittajien vanha kikka. Toinen pidemmälle viety versio samasta kikasta on ratkaisun vaatimusmäärittely ”riippumattomasti” – siis tarkoituksena määritellä vaatimuksia, ei vielä tehdä teknologiavalintaa. Vaatimusten valmistuttua joudutaan monesti toteamaan, että oikeastaan vain vaatimusmäärittelyn tehnyt toimittaja ymmärtää asiakkaan vaatimusten sisällön, ja että yllättäen vaatimukset tehneen toimittajan projektitarjous täyttää vaatimukset parhaiten. Tämän jälkeen toimittajavalinta onkin sitten helppo.

Muita asiakkaan kokonaisedun vastaisia kikkoja IT-toimittajan keittokirjasta:

  • monimutkaistaminen (ratkaisun tarpeeton monimutkaistaminen ja/tai kasvattaminen)
  • vähättely (budjetin ja/tai aikataulun aliarviointi)
  • osaamisharha (toimittajan ja/tai asiakkaan osaamisen yliarviointi)
  • monitoimittajaparadoksi (avaimet käteen, mutta 100% kontrolli alihankkijoihin)
  • toimittajalukot (suljetut rajapinnat, teknologia ja/tai toimintatavat)

Nämä termit eivät ole vakiintuneita, vaan allekirjoittaneen itse keksimiä. Käyn tulevissa blogeissa läpi termien sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Vaikka nämä ovatkin toimittajien kikkoja, on tärkeä ymmärtää, että ongelmien välttämisessä on keskeistä myös ostavan tahon puolella vallitsevan vääristyneen ajattelutavan korjaaminen tai osaamisen kehittäminen. Kaikki IT-työ on toimittajan ja asiakkaan yhteistyötä, ja tärkeää on huomioida molempien osapuolten intressit.

Suurin osa IT-toimittajista ei tarkoituksellisesti johda asiakastaan harhaan, mutta ohjelmisto- tai palvelutoimittajan näkökulma on väistämättä rajoittunut ja intressit asiakkaan kanssa osin ristiriitaiset. Olipa organisaatiossa työn alla sitten tarvekartoitus, vaatimusmäärittely, toimittajavalinta, projekti tai palvelutuotannon kehittäminen, hankkimalla aidosti riippumatonta neuvonantoa organisaatiot voisivat välttää yllämainitut sudenkuopat, ja tehdä kokonaisvaltaista IT:n laadun, kustannusten ja riskien hallintaa.

Lisätietoa: Otso Kivekkään blogikirjoitus

”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

Verottajan uudet IT-kujeet

Verohallinnossa on lähdössä käyntiin massiivinen IT-projekti, jossa uudistetaan lähes kaikki verotuksessa käytettävät tietojärjestelmät. Verohallinnon nykyinen tietojärjestelmäkenttä on monimutkainen ja hajanainen, mikä aiheuttaa ylläpitoon kustannuspaineita (ylläpidon kokonaiskustannukset ovat 40 miljoonaa euroa vuodessa). Verohallinnon tietojärjestelmäuudistusprojekti tulee olemaan noin viisivuotinen ja budjetiltaan kymmeniä miljoonia euroja.

Uudistuksella tavoitellaan verohallinnon tietojärjestelmien kokonaiskustannuksista (total cost of ownership) leijonan osan muodostavien ylläpitokustannusten alentamista 20-40%. Lisäksi tavoitteena on parantaa tietojärjestelmien ketteryyttä (time-to-live) sekä pyrkimys kasvattaa verovirkailijoiden työn tuottavuutta (productivity).

Erityisen verohallinnon projektista tekee sen suuren koon lisäksi ratkaisun pohjaaminen kaupallisiin valmisohjelmistoihin (commercial-of-the-shelf, COTS). Valmisohjelmistoilla pyritään ratkaisun sisäiseen standardointiin ja rakentamaan järjestelmä, joka on muuallakin vastaavan laajuisessa vaativassa käytössä.

Tarkoituksena on valjastaa suuri määrä valmisohjelmistoja verohallinnon tarpeisiin. Haasteen asettaa se, että mikään valmisohjelmisto ei luonnollisesti voi suoraan paketista tukea suomalaisen verohallinnon prosesseja, joten tarvitaan ratkaisujen räätälöintiä. Julkisuudessa lausuttujen tavoitteiden mukaan räätälöinnit pyritään minimoimaan, mutta kysymys kuuluukin, miten tämä käytännössä saavutetaan?

Kun projektin tavoitteena on toteuttaa tietojärjestelmä valmisohjelmistoilla, hyvän ratkaisuarkkitehtuurin (solution architecture) suunnittelu sekä projektin laajuuden hallinta (scope management) ovat avainasemassa. Tavoitteena on, että valmisohjelmistojen ominaisuuksia käytetään optimaalisesti ja ratkaisun räätälöintiä tehdään sopivasti.

Ratkaisuarkkitehtuurin tulee määritellä, millä valmisohjelmistolla kukin kokonaisratkaisun toiminnallinen vaatimus (functional requirement) toteutetaan, miten ei-toiminnalliset vaatimukset (non-functional requirement) otetaan huomioon, huolehtia valmisohjelmistojen keskinäisestä yhteensopivuudesta (interoperability) sekä tarpeen mukaan määritellä täydentäviä ratkaisun komponentteja, jotka eivät perustu valmisohjelmistoihin. Ratkaisuarkkitehtuurin puutteellisuudesta johtuvia tyypillisiä ongelmia ovat valmisohjelmistojen epäselvät tehtävät, epärealistiset ei-toiminnalliset vaatimukset, valmisohjelmistojen yli- tai aliräätälöinti tai niiden yhteensopimattomuus.

Projektin laajuuden hallinnan tulee pitää huolta, että tietojärjestelmän kokonaisuudistustavoitteesta huolimatta ei sorruta valmisohjelmistojen yliräätälöintiin. Joskus projektin tilaaja (liiketoiminta) voi nähdä, että projektin suuri koko oikeuttaa myös toiminnallisten vaatimusten monimutkaistamisen tai lukumäärän kasvattamisen, jopa projektin aikana. Tämä on usein myös toimittajan intressi, koska se tietää toimittajalle lisää työtä. Tällaisessa tilanteessa projektipäällikön ja projektiohjausryhmän tulee kysyä: onko todella niin, että valmisohjelmiston standardina (tai pienellä räätälöinnillä) tarjoama toiminnallisuus ei riitä, vaan suurempaa räätälöintiä todella tarvitaan. Päätöksissä on tärkeää huomioida, että räätälöimällä ratkaisua menetetään joka askeleella valmisohjelmistojen tuomia ratkaisun standardointiin ja ylläpitokustannusten alentamiseen liittyviä hyötyjä.

Verohallinnon edellinen tietojärjestelmäuudistus 1990-luvulla tuotti kansalaisille sähköisen veroehdotuksen ja jatkokehitys 2000-luvulla on entisestään parantanut verohallinnon sähköisiä palveluita. Verohallinnon aiempia uudistusprojekteja voisi pitää jopa julkishallinnon malliesimerkkinä asiakasprosesseista lähtevästä tietojärjestelmäkehityksestä. Toivotan verohallinnolle ja toimittajille voimia ja onnea seuraavaan vaativaan hankkeeseen!

Lisätietoa: Tietoviikko

IT tulee töpselistä, eikun pilvestä

Muutamia vuosia sitten alkanut pilvilaskenta-trendi ei ota laantuakseen. Trendin huipulla suurten IT-talojen johtajat parhaimmillaan (tai pahimmillaan) yksinkertaistivat pilvilaskennan siten, että pilvet tekevät IT:sta yhtä helppokäyttöistä kuin sähkö. Vertaus on ihailtavan visionäärinen, mutta pilvilaskentaan liittyy vielä runsaasti sekä hallinnollisia että teknisiä käytännön haasteita.

Mitä pilvilaskenta sitten oikein on? Pilvilaskenta tarkoittaa tietoteknisen palvelun suorittamista palvelun käyttäjälle läpinäkymättömässä virtuaalisessa ympäristössä. Pilvipalvelun käyttäjä ottaa yhteyden palveluun tietoverkon yli. Pilvipalvelut jaetaan hierarkkisesti kolmeen luokkaan (edeltävä taso sisältää jälkimmäiset tasot): 1) Software as a Service (SaaS), 2) Platform as a Service (PaaS), 3) Infrastructure as a Service (IaaS).

Pilvilaskenta ei ole sama asia kuin palvelinten virtualisointi, jossa yksittäinen fyysinen palvelin abstrahoidaan käyttöjärjestelmän kannalta näkymättömäksi. Jo alimmalla IaaS-tasolla pilvipalvelu abstrahoi koko fyysisen infrastruktuurin sisältäen tallennusratkaisut ja verkon konfiguraatioineen. Ylimmällä SaaS-tasolla abstraktio ulottuu aina sovellustasolle asti.

Käytännön esimerkki SaaS-pilvipalvelusta on internet-sähköposti, joka ei vaadi mitään asennuksia käyttäjän koneelle internet-selainta lukuunottamatta. PaaS-pilvipalvelu puolestaan voi olla esimerkiksi webhotelli, jonne käyttäjä voi luoda internet-sivut (HTML), ohjelmoida dynaamista sisältöä (esim. PHP) ja rajoitetusti asentaa ohjelmistoja (kuten tietokanta tai blogi). IaaS-pilvipalvelu sen sijaan tarjoaa vain teknisen virtuaalisen ympäristön, mutta kaikki ohjelmistot ovat käyttäjän vastuulla.

Pilvipalveluilla voidaan korvata perinteisiä konesaleja ja liiketoimintasovelluksia sekä tehostaa palvelutuotantoa. Kapasiteetinhallinnan näkökulmasta pilvipalveluiden arvolauselma on ilmeinen: 1) fyysisen infrastruktuurin ja alustojen hankinta- ja ylläpitokustannus on toimittajan volyymiedun ansiosta matalampi, 2) toimittajan kapasiteettijouston ansiosta muutoksia on mahdollisuus tehdä nopeasti tilannekohtaisen tarpeen mukaan, 3) toteutunut kustannus perustuu todelliseen käyttöön ja kiinteä kustannuskomponentti on ennakoitavissa.

Haasteita pilvipalveluiden käyttöönotolle asettavat kuitenkin siihen liittyvät migraatiokustannukset sekä yritysten riskienhallinnalliset vaatimukset. Peruskysymys on, miten ulkoisia pilvipalveluja tulisi ylläpitää ja hallinnoida, jotta laadulliset vaatimukset täyttyvät hyväksytyllä riskitasolla, mutta kuitenkin kustannusedut saavutetaan. Kaikkia liiketoimintasovelluksia ei voida teknisistä, integraatio- tai suorituskykysyistä siirtää ulkoiseen pilvipalveluun.

Yhtenä ratkaisuna pidetään esim. nk. hybridimallia, jossa osa pilvipalveluista tuotetaan yrityksen sisäisestä pilvestä ja osa ulkoisesta pilvestä palvelukohtaisista kustannussäästömahdollisuuksista ja vaatimuksista riippuen. Aina sovelluksia jää myös kokonaan pilvien ulkopuolelle. Erityisesti ulkoisten pilvipalveluiden hallinnoinnissa tulee kiinnittää erityistä huomiota tietoarkkitehtuuriin, selkeisiin tietoturvalinjauksiin, oikean palvelutason valintaan.

Pilvilaskennan kehitys tulee jatkumaan ja se tulee varmasti jäämään osaksi yritysten IT-arkkitehtuureita ja palvelutuotantomalleja. Viimeksi tällä viikolla Forrester hämmensi keskustelua väittämällä, että pilvilaskenta ei olekaan IT:n tulevaisuus – ainakaan kokonaisuudessaan. Aika näyttää.

Lisätietoa: cio.com