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.

IT tulee töpselistä, eikun pilvestä

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

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.

Äläkä saata meitä IT-ekosysteemiin

Helsingin kaupungin laskutuksessa oli haasteita sen jälkeen, kun kaupungin taloushallinto siirtyi vuoden 2012 alussa käyttämään uutta tietojärjestelmää. Julkisuuteen tihkuneiden tietojen mukaan noin 250 000 laskua jäi lähettämättä kaupunkilaisille. Tuon perusteella voi arvioida, että saatavien arvo oli yhteensä muutamia kymmeniä miljoonia euroja, mikä ei aiheuttanut korkokuluja kuin parikymmentätuhatta euroa viikossa. Sehän ei ole Helsingin kokoiselle kaupungille paljon mitään!

IT-toimittajat levittelivät näyttävästi käsiään – ainakin silloin, kun eivät olleet niitä pesemässä. Ohjelmistotoimittajan edustaja oli 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 kuulostivat 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 ne olisi vähintään 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ä tässä 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.

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.

THL:n pääjohtaja: ”Joku ohjelmoija on mokannut…”

Terveyden ja hyvinvoinnin laitoksen (THL) pääjohtaja Pekka Puska joutui valittelemaan ja selittelemään tapahtumasarjaa, jossa lääkeyhtiö GlaxoSmithKlinen (GSK) pneumokokki-rokotetutkimuksessa noin 200 lasta sai tutkimuksen aikana liikaa rokotetta ohjelmistovirheen takia. Ylen mukaan Puska kommentoi: ”On käsittämätöntä, että isossa lääkefirmassa voi tapahtua tällainen virhe. Tällaiset asiat pitäisi tarkistaa moneen kertaan.”

Puskan kommentti on hyvä esimerkki siitä, kuinka tietojärjestelmien ongelmat tuntuvat monesti liiketoiminnan edustajille ja päättäjille käsittämättömiltä. Kuitenkin on tärkeää myös kysyä, mitkä ovat THL:n ja GSK:n tietojärjestelmien laadunvarmistukseen ja riskien hallintaan tekemät panostukset? Millä ennakoivilla toimenpiteillä ja tietojärjestelmien hallintointimalleilla nämä tapahtumat ylipäätään yritettiin estää?

Harmillisen usein oletuksena tuntuu olevan, että mitään erillisiä toimenpiteitä tietojärjestelmien laadun varmistamiseksi tai riskien hallitsemiseksi ei tarvita, vaan kaiken pitäisi sujua kuin elokuvissa ilman sen kummempia panostuksia – ikään kuin sattumalta. Tämä on vaarallinen harhakäsitys.

Tietojärjestelmistä voidaan saada laadukkaita ja luotettavia. Tämä vaatii kokonaisvaltaisen asiantuntemuksen ja riippumattoman laatu- ja riskinäkökulman tuomista mukaan tietojärjestelmiin liittyvään työskentelyyn. Näin saadaan selkeyttä monimutkaisuuteen, saadan ymmärrystä riskeistä ja voidaan suunnata resurssit oikein riskien hallisemiseksi.

Laatua ja riskittömyyttä ei voi saavuttaa ilman panostuksia ja sen arvoa voi olla haastava mitata. Joka tapauksessa panostukset ennakoitavuuteen, laatuun, hallittuihin riskeihin kannattavat, sillä kukaan vastuullinen johtaja ei halua tilanteeseen, jossa joutuu toteamaan ”joku ohjelmoija on mokannut”.

Toki tässäkin oli onni onnettomuudessa, että rokotesekoilun seuraukset jäivät vähäisiksi. Potilastietojärjestelmät, joihin upotetaan julkista rahaa satoja miljoonia vuodessa, uhkaavat vielä vakavammin ja vielä useamman terveyttä. Potilastietojärjestelmistä kirjoitan näkemykseni joku toinen kerta.

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.

Tervetuloa Cheetah-blogiin!

Tervetuloa! Tämä blogi käsittelee tietojärjestelmien ihmeellistä maailmaa. Useimmiten tuon blogeissa tekniseen, projektinjohtamiseen ja liiketoiminnalliseen kokemukseeni perustuvan näkökulman johonkin tapahtumaan, josta olen lukenut tai teemaan, johon olen tutustunut.

Blogin kirjoittajalla Teemu Leppäsellä on vahva kokemus vaativista liiketoiminnan tietojärjestelmistä ja kymmenistä suurille organisaatioille toteutetuista IT-projekteista. Koulutukseltaan Teemu on tekniikan tohtori (TKK). Teemun perustama Cheetah Consulting Oy on erikoistunut liiketoiminnan tietojärjestelmiin liittyvään neuvonantoon ja IT-toimittajayhteistyön kehittämiseen. Yritys tarjoaa kokonaisvaltaista, toimittajista riippumatonta palvelua pohjautuen kattavaan teknologia-, projekti- ja liiketoimintaosaamiseen.