Mikä IT-projekteissa oikein maksaa?

Klassisessa Kummeli-sketsissä (YouTube) rakennustyömaan vastaava mestari neuvoo määrätietoisin ottein ahkeria, mutta taitamattomia rakennusmiehiä. Alkuvaiheessa rakennusmiesten virheet aiheuttavat tehottomuutta: ”Tääl on poijaat sisällä niin paljon romua vielä, ettei näitä pääsisäänkäynnin laseja olis vielä missään nimessä pitänyt laittaa.” Työmaan edetessä virheet vaativat jo kalliimpia korjauksia: ”Nää LVI-putket piti tulla tonne kattoon betonin sisään.” Lopulta farssi kärjistyy virheeseen, joka ei ole edes korjattavissa: ”Se on poijjaat nyt kolmekymmentä metriä sivussa. Koko toi talo!” Kuulostaako tutulta? Ethän toivottavasti ole itse koskaan joutunut IT-projektissa hämilläsi tokaisemaan virheen ilmetessä: ”Selvä!”

Tuhansista satoihin tuhansiin tehtäviin

IT-projektissa projektitiimin jäsenet suorittavat projektin koosta riippuen tuhansia tai jopa satojatuhansia tehtäviä, jotka projektisuunnittelussa ketjutetaan tehtävien välisten riippuvuuksien perusteella (tietyt tehtävät on suoritettava ennen muita). Peukalosääntönä voidaan arvioida, että yhtä projektiin tehtyä henkilötyöpäivää (htp) kohden suoritetaan noin 2 – 10 erillistä tehtävää. Jokaisella tehtävällä on vaikutus jonkin seuraavan tehtävän suorittamiseen tai suoraan lopputulokseen.

”Miljoonan euron IT-projektissa tehtävien määrä voi nousta jopa useisiin kymmeniin tuhansiin.”

Edellinen tarkoittaa, että esimerkiksi budjetiltaan miljoonan euron IT-projektissa tehtävien määrä voi nousta jopa useisiin kymmeniin tuhansiin. Syntyvien virheiden määrän kertoo laatuprosentti eli se kuinka moni tehtävä suoritetaan ilman virheitä (first-time-right). Projektin koon kasvaessa virheiden määrä kasvaa vähintään lineaarisessa suhteessa tehtävien määrään, mutta kokonaisuuden monimutkaistuessa ja riippuvuuksien kasvaessa virheiden määrä alkaa kasvaa tehtävien määrää nopeammin.

Virheiden vaikutus IT-projektissa

Myös virheiden seuraukset kasvavat projektin edetessä. Virheiden takia saatetaan joutua tekemään uutta työtä huteralle pohjalle, korjaamaan aiemman työn tuotoksia tai pahimmassa tapauksessa tekemään jo kertaalleen tehty kokonaan uudelleen. Virheet viivästyttävät aikataulua ja lisäävät kustannuksia sitä enemmän mitä myöhemmässä projektin vaiheessa virheet ilmenevät.

On helppo ymmärtää virheen vaikutus, kun seuraavien tehtävien aloittaminen / valmistuminen viivästyy edellisessä vaiheessa tehdyn virheen vuoksi. Lisäksi virheen korjaaminen tarkoittaa tuplatyötä eli tuplakustannusta. Pohdittaessa panostuksia projektin eri vaiheisiin on tärkeää huomioida, että on paljon edullisempaa tehdä muutos rakennuspiirustuksiin kuin valmiiksi rakennetun talon perustuksiin.

Virheiden kustannukset

IT-projekteissa tehtävien virheiden kustannuksia on selvitetty tutkimuksissa. Esimerkiksi Capers Jones on esittänyt virheiden kustannuksen kasvavan IT-projektin eri vaiheissa oheisen kuvaajan esittämällä tavalla (kirja). 

Projektityön virheiden aiheuttaman kokonaiskustannuksen määrittää oheisen tutkimuksiin perustuvan graafin perusteella kolme tekijää:

  1. miten paljon virheitä tehdään (eli mikä on yleinen työn tuotosten laatu eri vaiheissa)
  2. missä projektin vaiheessa virheet tehdään (eli miten aikaisessa vaiheessa virheet korjataan)
  3. mikä on virheiden keskimääräinen ”yksikkökustannus” (eli miten pahoja virheitä tehdään)

Otetaanpa esimerkki virheiden kustannusten konkretisoimiseksi: oletetaan, että budjetiltaan miljoonan euron IT-projektissa tehdään töitä yhteensä 1250 htp:tä. Oletetaan edelleen, että projektitiimi suorittaa keskimäärin 90 % laadulla neljä tehtävää per htp (eli tehtäviä on yhteensä 5 000 kpl virheitä tehdään yhteensä 500 kpl). Oletetaan edelleen, että puolet virheistä ajoittuu kehitysvaiheen aloittamisen jälkeiseen aikaan.

Kasvattamalla tehtävien laatu 98 %:iin ja ratkaisemalla puolet testausvaiheen virheistä jo suunnitteluvaiheessa projektin kustannuksia voitaisiin alentaa noin 20 % eli 200 000 euroa.

Voit arvioida vastaavalla tavalla omalla vastuullasi olevan IT-projektin tai koko yrityksesi kehitysprojektiportfolion kustannussäästöpotentiaalia tällä Cheetah-laskurilla.

Virheiden aiheuttamat lisäkustannukset eivät aina näy suoraan toimittajien kasvaneessa laskutuksessa tai sisäisten kustannusten seurannassa, vaan voivat ilmetä vaikeammin seurattavina, eriteltävinä ja laskettavina piilokustannuksina, kuten esim.

  • projektiaikataulun viivästymisenä (liiketoimintahyödyn viivästyminen ja muuttuvien kustannusten kasvu)
  • ratkaisun heikompana käytettävyytenä tai soveltuvuutena (tehdään vain pakollinen ja minimilaadulla)
  • kompromisseina teknisten vaatimusten osalta (tingitään esim. ratkaisun ylläpidettävyydestä tai dokumentaatiosta)
  • korkeampana riskitasona (joka voi realisoitua projektin aikana tai sen jälkeen ratkaisun elinkaaren aikana)
  • projektiorganisaation henkilöiden ylikuormituksena (sairaslomina tai burn-outeina)

Varmista projektitiimin riittävä osaaminen

IT-projektit ovat liiketoiminnallisesti monimutkaisia ja teknisesti vaativia kokonaisuuksia. Kaikissa IT-projekteissa tapahtuu lukuisia virheitä, eikä kaikkia virheitä ole mahdollista estää asetetun aikataulun ja käytettävissä olevien resurssien puitteissa.  

On kuitenkin täysin mahdollista vähentää virheiden määrää ja ratkaista virheitä ennakoivasti projektin aikaisemmissa vaiheissa varmistamalla projektitiimin riittävä osaaminen koulutuksilla, parantamalla projektipäällikön työn edellytyksiä tarjoamalla valmennusta sekä käyttämällä IT-projekteissa kinkkisimmissä vaiheissa ulkopuolista neuvonantajaa. Tällä tavalla virheiden projektille aiheuttama kokonaiskustannus alenee merkittävästi.

Haluatko tietää tarkemmin, miten voit parantaa IT-projektien kustannustenhallintaa projektityön laadun parantamisena kautta? Tutustu neuvonanto- ja koulutuspalveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Mikä IT-projekteissa oikein kestää?

Tämä tarina on tosi. IT-konsultilla oli kotona ongelma; keittiön lamppu oli alkanut välkkyä. Ongelman ratkaisemiseksi hän joutui yrittämään useita eri tapoja ja päätyi ratkomaan haastavaa ongelmaa useaan otteeseen monen päivän ajan. Lopulta ratkaisu löytyi ja lamppu paloi välkkymättä. Kuinka monta IT-konsulttia tarvitaan korjaamaan lamppu? Vain yksi, mutta siinä menee todella kauan.

Lamppuongelman ratkaisuun kului IT-konsultilta kokonaisuudessaan kalenteriaikaa 177 tuntia (reilu viikko) ja työn suorittamiseen kului bruttoaikaa yhteensä 1,5 tuntia (kuudessa eri osassa). Kun toimiva ratkaisu löytyi, sen toteutus kesti alle minuutin. Ongelman nettoratkaisuaika oli siis alle sadasosa työhön käytetystä kokonaisajasta ja 1/10000 osa aloittamisesta valmistumiseen kuluneesta kalenteriajasta!

Miten ihmeessä puolen minuutin hommaan voi kulua viikko kalenteriaikaa ja puolitoista tuntia erinäköistä ”työskentelyä”? Aika tuhlaantui mm. seuraaviin:

  • vitkasteluun epämiellyttävän ongelman edessä
  • väärien ratkaisuvaihtoehtojen kokeilemiseen
  • sen pohtimiseen, mitä ratkaisua seuraavaksi kannattaisi yrittää

Onneksi tämä kertomus on vain arkinen esimerkki kyvyttömän yrityksestä tehdä mahdottomia, eikä vastaavaa koskaan tapahdu IT-ammattilaisia IT-projekteissa. Eihän?

Viiveet tehtävien läpimenoajoissa

Valitettavasti raaka totuus on, että suurin osa IT-projektien aikataulu- ja kustannushaasteista johtuu nimenomaan edellä kuvatun kaltaisista viiveistä tehtävien läpimenoajoissa. Yksittäisen tehtävän kokonaisläpimenoajan määrittelee kolme elementtiä:

  • resurssien ajankäytön suunnittelu (paljonko aikaa käytössä, miten pitkä aika kerrallaan, mikä on muu työkuorma)
  • projektiympäristön ja tavoitteiden selkeys (paljonko ajasta kohdistuu tehtävän suorittamiseen)
  • asiantuntijaosaaminen (kuinka nopeasti tehtävä suoritetaan valmiin määritelmän (”definition of done”, DoD) mukaisesti)

Oheinen kuva selkeyttää eroja yksittäisen tehtävän suorittamisen kalenteriajan, bruttoajan ja nettoajan välillä:

IT-projekteissa tehtävien välillä on pitkiä riippuvuusketjuja (eli tehtävät täytyy suorittaa tietyssä järjestyksessä).  Ennen kuin seuraavan tehtävän voi suorittaa, pitää edelliset tehtävät suorittaa oikein.

Monesti tehtävien valmiin määritelmäkin (”definition of done”) on epäselvä. Tehtävät vaativat erilaista osaamista, joten peräkkäiset tehtävät suorittaa usein eri henkilö tai jopa eri organisaatio, mistä aiheutuu koordinaatioviiveitä. Kun IT-projektissa on useita tuhansia vaativia tehtäviä, jokainen ymmärtää, että viiveet tehtävien suorittamisessa kertautuvat ja vaikuttavat merkittävästi projektin aikatauluun ja sitä kautta myös kustannuksiin. Projektin kokonaistuottavuuden määritteleekin yksittäisten tehtävien läpimenoajan minimoinnin lisäksi tehtäväketjujen hukka-aikojen minimointi. Tässä avainasemassa on tehtävien suunnitelmallinen, keksinäinen priorisointi ja proaktiivinen työnohjaus.

Oheinen kuva selkeyttää viiveiden vaikutusta ja kalenteri-, brutto- ja nettoajan jakautumista kolmen tehtävän ketjussa:

IT-projekteissa on loppujen lopuksi kyse hyvin yksinkertaisesta asiasta: tuhansien ongelmien ratkaisemisesta pienin viivein, mahdollisimman nopeasti ja riittävän oikein. Käytännössä ongelmien ratkaisussa on kuitenkin aina viestinnästä tai ajanpuutteesta johtuvia viiveitä, asioiden monimutkaisuudesta tai epäselvyydestä johtuvia hitauksia ja huolimattomuudesta tai osaamisvajeesta johtuvia virheitä. Muilta osin IT-projektit ovat yhtä helppoja kuin lampun vaihto.

IT-projekteissa on loppujen lopuksi kyse hyvin yksinkertaisesta asiasta – tuhansien ongelmien ratkaisemisesta pienin viivein, mahdollisimman nopeasti ja riittävän oikein.

Haluatko tietää tarkemmin, miten voit parantaa IT-projektien ajanhallintaa projektityön laadun parantamisena kautta? Tutustu neuvonanto- ja koulutuspalveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Miten valitsen osaavan IT-projektipäällikön ja vältän huithapelit, jyrääjät ja tuuliviirit?

Mies meni eläinkauppaan. Häkissä oli kolme apinaa. ”Miten tuo apina voi maksaa 10.000 euroa?”, mies kysyi myyjältä. ”Se osaa koodata”, vastasi myyjä. ”Entä tuo toinen apina?”, kysyi mies. ”Se maksaa 15.000 euroa. Se osaa IT-arkkitehtuuria”, vastasi myyjä. ”Entä tuo kolmas sitten?”, kysyi mies. ”Se maksaa 20.000 euroa.”, vastasi myyjä. ”Mitä se oikein osaa?!?”, kysyi mies. Myyjä vastasi: ”En tiedä, mutta nuo kaksi muuta sanoo sitä projektipäälliköksi.”

Apina tietokoneella

Projektipäällikön valinta on yksi IT-projektin ohjausryhmän tärkeimmistä päätöksistä. Osaava projektipäällikkö on IT-projektin keskeinen menestystekijä. IT-projektipäälliköiden osaamisen arviointi ja vertailu on haastavaa, joten ohjausryhmät eivät useimmiten kiinnitä projektipäällikön valintaan riittävästi huomiota. IT-projekteihin liittyy useita epävarmuuksia, eikä edes osaava projektipäällikkö voi estää kaikkia ongelmia, minkä takia projektipäällikön merkitystä projektin onnistumiselle aliarvioidaan liian usein. Osaava projektipäällikkö osaa kuitenkin ennakolta estää monia ongelmia ja lieventää ennakoimattomien ongelmien vaikutusta, mikä näkyy pienempinä kustannus- ja aikatauluylityksinä.

Käytännön IT-arjessa kamppaillaan taivaita hipovien tavoitteiden, rajallisten resurssien ja tiukkojen aikataulujen ristipaineessa. Seuraavan kerran, kun olet nimittämässä IT-projektiisi projektipäällikköä, pysähdy hetkeksi ja varmista, ettet ole tietämättäsi syyllistymässä johonkin seuraavista virhearvioista IT-projektipäällikön valinnassa:

  • valitset huithapelin, jolla on kirkas visio, mutta jolle työn suunnittelu on utopiaa ja prioriteetit turhuuksia
  • valitset ahertajan, joka ratkaisee ongelmat nopeasti, mutta ei estä niiden syntymistä ennakoimalla
  • valitset hurmaajan, joka uskoo ilmapiirin, fiiliksen ja yhteishengen vievän vaikka läpi palomuurin
  • valitset kauppiaan, joka pitää ohjausryhmän ja sidosryhmät tyytyväisenä syöttämällä niille paskaa
  • valitset kylmäkallen, joka tehokkuuteen pyrkiessään kohtelee tiimiä mekaanisina suorittajina ja korvattavissa olevina resursseina
  • valitset ohjeistamispäällikön, jolle projektissa tärkeintä on hallinnollinen tarkkuus ja metodologinen kuri
  • valitset törmäysnuken, joka tietää kestävänsä palautetta, joten projektin onnistumisesta ei ole tarvetta stressata
  • valitset norsunluutornilaisen, jolle liiketoiminnan tavoitteet ovat selkeitä, mutta tekniikka-, arkkitehtuuri- ja vaatimusasiat ovat epämiellyttävää nippeliä
  • valitset propellipään, joka pyrkii edistykselliseen tekniseen ratkaisuun, mutta ei ymmärrä liiketoiminnan tarpeita
  • valitset höpöttäjän, joka osallistaa kaikki projektityöhön, mutta mittaa projektin etenemistä palaverien ja niiden osallistujien määrällä
  • valitset jyrääjän, joka toimittaa ala-arvoisen ratkaisun sovitussa aikataulussa ja budjetissa
  • valitset jokapaikanhöylän, joka on aina tekemisessä mukana ja ilmestyy mikromanageeraamaan myös silloin, kun ei tarvita
  • valitset tuuliviirin, joka etsii kompromisseja, mutta ei tee päätöksiä, koska ei halua sanoa kenellekään vastaan
  • valitset konkarin, jolla on pitkä kokemus teknisenä asiantuntijana, mutta jolle ei löydy enää muitakaan hommia
  • valitset juniorin, joka vakuuttaa olevansa motivoitunut IT-projektipäälliköksi, mutta ei ole aiemmin ollut IT-projektissa mukana

Vaikka IT-projektipäällikköjen osaamisen arviointi on haastavaa, kannattaa muistaa se tosiasia, että toiset projektipäälliköistä todella ovat osaavampia. Lisäksi erilaiset IT-projektit vaativat projektipäälliköltä erilaista osaamista riippuen esimerkiksi projektin liiketoimintakeskeisyydestä, ratkaisun teknisyydestä, projektin riskiprofiilista, projektiorganisaation muodosta tai ratkaisun loppukäyttäjistä. Nimenomaan vaativissa olosuhteissa projektipäällikön osaamisella on suurin vaikutus projektin onnistumiseen tai epäonnistumiseen.

Mount Everestin valloitus

Vaatii huomattavasti vähemmän osaamista retkenjohtajalta johtaa patikointia vehreälle kukkulalle kauniina kesäpäivänä kuin kiipeämistä Mount Everestille lumimyrskyn uhatessa. Kesäpäivänä kukkulalla voi olla vaikeaa nähdä eroja retkenjohtajien osaamisessa tai huonojen päätösten seurausten merkitystä. Sen sijaan Mount Everestilla jokainen retkenjohtajan päätös voi tehdä eron koko retkikunnan elämän ja kuoleman välillä. Valitsisitko itsellesi Mount Everestille retkenjohtajaksi joviaalin jutustelijan, joka patikoi ruohikolla kerran vuodessa aurinkoisessa säässä vai sherpan, joka on aiemmin vetänyt retken huipulle parikymmentä kertaa?

Kaikissa IT-projekteissa projektipäälliköltä vaaditaan monipuolista osaamista tasapainoisessa suhteessa. Projektinhallinnollisten menetelmien lisäksi mm. liiketoiminnan tavoitteiden syvällinen ymmärtäminen, organisaatiorajat ylittävät viestintätaidot, kokonaisuuden tilannekuvan säilyttäminen ja konkreettisten priorisoitujen toimintasuunnitelmien valmisteleminen ovat arvokkaita taitoja.

Älä ainakaan valitse seuraavan IT-projektiisi projektipäällikköä, jolta löytyy kovin monia aiemmin listatuista piirteistä. Muuten saatat pian löytää itsesi ja projektisi perinteisen sananlaskun kuvaamasta tilanteesta, jossa kyvyttömät yrittävät saada haluttomat tekemään mahdottomia.

Tarvitsetko apua IT-projektissa tai etsitkö koulutusta IT-projektien parissa työskenteleville ammattilaisille? Tutustu neuvonanto- ja koulutuspalveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

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 oli vuonna 2013 myöhästymässä seitsemän vuotta (YLE). Projektin tilanne oli seurausta tehokkuuteen liittyvistä laadullisista haasteista. Projektin aikataulu venyi, koska vaadittuja asioita ei oltu tehty oikein eli tehokkaasti. Projektin haasteena ei ollut varsinaisesti tuottavuus, koska projektin tuotoksena lopulta saatiin 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ähensi tehokkuutta. Näennäisesti projektin kustannusriski oli hallittu kiinteähintaisella sopimuksella. Mutta kai tilaajaorganisaation omien resurssien sitominen projektiin suunniteltua pidempään, investoinnin rahoituskustannukset ja menetetty sähkön myynnin liikevaihto maksoivat jotakin? Kyllä, TVO:n ja Arevan välimiesmenettelystä päätellen noin kaksi miljardia euroa.

Toinen käytännön esimerkki edustaa tuottavuuteen liittyvää laadullista haastetta. Yhdysvalloissa oli aiempina 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. Projektin tilanne oli 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 tehokkuushaasteita, 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).

Tarvitsetko apua tai haluaisitko kysyä neuvoa IT-projekteihin tai -hankintoihin liittyen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

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ä prosessitasolla 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.

Tarvitsetko apua IT-projektissa tai etsitkö koulutusta IT-projektien parissa työskenteleville ammattilaisille? Tutustu neuvonanto- ja koulutuspalveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

IT-hankinnan sudenkuoppa #3: osaamisharha

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta hankkeen valmistelussa ja toimittajavalinnassa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta). Kerron näkemykseni tyypillisistä haasteista, mistä ne johtuvat ja miten sudenkuopat vältetään. Haasteisiin vaikuttavat sekä IT-toimittajan yksipuolinen etujen ajaminen että ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun aiemmissa blogeissa käsitellyt IT-hankinnan sudenkuopat monimutkaistaminen ja vähättely on onnistuttu välttämään, toteutettavalla IT-ratkaisulla on todellisen asiakastarpeen mukainen laajuus ja realistinen projektisuunnitelma. Tämän jälkeen projektiin pitää löytää resurssit eli asiantuntijat, jotka toteuttavat projektin. IT-hankintojen kolmas sudenkuoppa osaamisharha liittyykin näiden asiantuntijoiden nimittämiseen eli projektien resursointiin.

Osaamisharha-sudenkuoppaan ajaudutaan, jos projekti resursoidaan tekijöillä, joilla ei ole tarpeeksi tai oikeanlaista osaamista projektin läpi viemiseksi projektisuunnitelman mukaisesti. Parhaiden osaajien saaminen projektiin on usein haastavaa, joten tärkeää on, että resursointiin liittyvät kompromissit tehdään oikealla tavalla ja samalla tiedostetaan päätösten vaikutukset projektin aikatauluun ja laadunvarmistustarpeisiin. Osaamisharha pätee myös organisaation sisäisten resurssien osaamiseen, eikä pelkästään IT-toimittajan resursseihin.

Mikä sitten aiheuttaa osaamisharhan? Se, että projektiin tarvittavan osaamisen hahmottaminen ja tarjolla olevien resurssien osaamisen arviointi on erittäin haastavaa. Kukapa asiakas ei haluaisi projektiinsa parhaita mahdollisia osaajia? Toimittajat saattavatkin myyntivaiheessa esitellä asiakkaalle projektin tulevia toteuttajia osaavammat ja kokeneemmat resurssit. Jos asiakas tilaa projektin, resurssit muutetaan kokemattomampiin ja kokeneet resurssit katoavat vähin äänin taka-alalle.

Joskus resurssien osaamisen arvioinnissa ajaudutaan numero- ja termipeliin eli lasketaan ja vertaillaan resurssien CV:iden perusteella kokemusta kuukausissa tai etsitään tiettyjä IT-alan erikoistermejä pyrkimättä sen syvemmin tai laajemmin ymmärtämään tarvittavaa tai tarjolla olevaa osaamista. Projektit ovat aina erilaisia (vaikka olisi sama teknologia), joten myös tiimityötaidot sekä kokonaisuuksien ymmärtäminen ovat arvokasta osaamista. Harvoin ymmärretään, että asiantuntija, joka on aiemmin tehnyt teknologian X versiolla Y viisi projektia ei ole (useimmiten) viisi kertaa parempi osaaja kuin asiantuntija, joka on tehnyt samalla teknologialla vain yhden projektin ja neljä muuta projektia.

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

  1. arvioimalla kattavasti resurssien kokemusta ja toiminnallista osaamista (kokemuksen kesto vs. sisältö, tekninen erikoistuminen vs. monipuolisuus, prosessiosaaminen, organisaatio-osaaminen)
  2. ottamalla huomioon myös resurssien ei-toiminnallinen osaaminen (tiimityö, viestintä, projektityö, kokonaisuuksien ymmärtäminen) sekä motivaatiotekijät (asenne, oppimishalu, oppimiskyky)
  3. valitsemalla ja sitouttamalla projektin avainhenkilöt (esim. projektipäälliköt, ratkaisun tekninen omistaja, laadunvarmistusroolit) sekä sopimuksellisilla että johtamistekijöillä.

IT-hankinnoissa usein tahattomastikin syntyvän osaamisharha-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohtokokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio saa hankkeen valmisteluun riippumattoman näkökulman, jolla varmistetaan hankkeen onnistuminen.

Tarvitsetko neuvoa IT-hankinnoissa ja haluatko varmistaa IT-hankintojen onnistumisen? Tutustu palveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Helppo nakki: 1,8 miljardin IT-projekti

Pääkaupunkiseudun kunnat ja HUS löivät vuonna 2012 viisaat päänsä yhteen ja alkoivat valmistelemaan kaikkien aikojen suomalaista IT-hanketta: uutta potilastietojärjestelmää, jonka kokonaisarvoksi arvioitiin Sitran selvityksessä 1,2 – 1,8 miljardia euroa 10 vuoden ajalle. IT-alan mediassa ja blogeissa hanketta ihmeteltiin, ja virkamiesten kunnianhimoisia suunnitelmia verrattiin 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 aiemmin 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.

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

Verottajan uudet IT-kujeet

Verohallinnossa käynnistettiin vuonan 2013 massiivinen IT-projekti, jossa lähdettiin uudistamaan lähes kaikki verotuksessa käytettävät tietojärjestelmät. Verohallinnon silloinen tietojärjestelmäkenttä oli monimutkainen ja hajanainen, mikä aiheutti ylläpitoon kustannuspaineita (ylläpidon kokonaiskustannukset olivat 40 miljoonaa euroa vuodessa). Verohallinnon tietojärjestelmäuudistusprojektin arveltiin olevan noin viisivuotinen ja budjetiltaan kymmeniä miljoonia euroja.

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

Erityisen verohallinnon projektista teki 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 oli valjastaa suuri määrä valmisohjelmistoja verohallinnon tarpeisiin. Haasteen valmisohjelmiston valinnassa 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 pyrittiin 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!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.

300 miljoonan euron sairasta IT-leikkiä terveydellä

Eduskunnan tarkastusvaliokunta iski kyntensä vuoden 2012 selvityksessä julkisen terveydenhuollon tietojärjestelmiin. Esimerkiksi vuonna 2010 näiden kehittämiseen käytettiin veronmaksajien rahoja noin 300 miljoonaa euroa. Mitä sillä saatiin? Huonosti yhteensopivia ja käytettävyydeltään monimutkaisia järjestelmiä, jotka tuhlaavat hoitohenkilökunnan aikaa ja pahimmillaan vaarantavat potilasturvallisuuden.

Hovitoimittajat olivat varmasti tilanteesta kiitollisia; ensin TEKES tukee heidän ”tuotekehitystään”, sitten näitä ”tuotteita” otetaan käyttöön massiivissa konsultointiprojekteissa veronmaksajien rahoilla ilman kunnon kilpailutusta ja lopulta, kun ”tuotteet” osoittautuvat kelvottomiksi, niin toimittajat pääsevät kuin koira veräjästä veronmaksajien kuittatessa laskun. Asian saaman julkisuuden takia saattoi näiden vastuuttomien toimittajien perävalotakuu-taktiikka kuitenkin lopulta epäonnistua.

Aiemmin myös Valtiontalouden tarkastusvirasto kunnostautui terveydenhuollon tietojärjestelmähankkeiden moittimisessa: tietojärjestelmät eivät ole käyttäjäystävällisiä, ja sama tieto pitää kirjata useaan järjestelmään, koska tiedot eivät siirry virheettömästi järjestelmien välillä. Arvioitiin, että vuodessa menee tietojärjestelmien takia hukkaan noin 600 lääkärityövuotta. Tämäkin arvio saattoi olla alakanttiin!

Mistä ongelmat sitten johtuivat ja mitä asialle olisi pitänyt tehdä? Täysin ulkopuolisen näkemykseni mukaan ongelmat olivat erityisesti hankkeiden valmistelussa. Hankkeita ei valmisteltu tarpeeksi liiketoiminta- ja käyttäjälähtöisesti ratkaisujen konseptoinnin ja kokonaisarkkitehtuurisuunnittelun kautta, vaan hankkeet toteutettiin teknisistä lähtökohdista ja vailla kokonaisymmärrystä todellisista liiketoiminnan tavoitteista ja tarpeista. Koska toimittajat valittiin pienestä sisäpiiristä ilman todellista kilpailua, toimittajien intressi oli pönkittää omaa asemaansa paisuttamalla projekteja ja tekemällä järjestelmistä entistä yhtyeensopimattomampia ja suljetumpia, jotta toimittajista tuli korvaamattomia.

Ehdotukseni kolmeksi keskeisimmäksi painopisteeksi julkisen terveydenhuollon tietojärjestelmien kehitykseen tulevaisuudessa on:

1) vahvan liiketoiminta-, prosessi-, arkkitehtuuri- ja konseptointiosaamisen ottaminen mukaan järjestelmien määrittelyyn

2) toimittajien aito kilpailuttaminen ja arviointi kompetenssin perusteella toteuttamaan määrittelyjen mukainen tietojärjestelmä

3) toimittajien teknisen työn ja projektinhallinnan ohjaus ja valvonta toteutusvaiheessa, jotta hankkeen etenemisestä on selkeä käsitys, toimittajalukot (vendor lock) voidaan välttää ja ongelmatilanteessa vaihtaa toimittajaa ajoissa.

Näissä kolmessa menestystekijässä on kyse toimintatapojen muuttamisesta, tuottavuudesta ja tehokkuudesta enemmän kuin merkittävistä taloudellisista lisäinvestoinneista. Ulkopuolisen riippumattoman neuvonannon kustannus on tyypillisesti vain muutamia prosentteja investointien kokonaisuudesta. Se ei ole suuri kustannus, kun tuloksena on käyttäjäystävällinen, työskentelyä tehostava ja luotettava tietojärjestelmäkokonaisuus.

Lisätietoa: Yle

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.