Tietojärjestelmäprojektin kustannukset yllättävät usein. Budjetti tehdään liian optimistisesti tai liian kapeasta näkökulmasta. Tässä artikkelissa käymme läpi, mistä kustannukset yleensä muodostuvat ja miten hyvin tehty esiselvitys auttaa rakentamaan realistisen budjetin.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
Kustannukset eivät synny vain teknologiasta
Kun tietojärjestelmähankkeen budjettia arvioidaan, huomio kiinnittyy usein yhteen asiaan: tietojärjestelmän teknisen toteutuksen hintaan. Todellisuudessa tämä on vain osa kokonaiskustannuksista.
Tyypillisesti kustannukset jaetaan kolmeen näkyvään osa-alueeseen. Ensimmäinen on lisenssit tai palvelumaksut, jotka riippuvat valitusta ratkaisusta. Toinen on varsinainen toteutus – eli järjestelmän kehitystyö, konfigurointi ja käyttöönotto. Kolmas on integraatiot, jotka yhdistävät uuden järjestelmän olemassa olevaan kokonaisuuteen.
Näistä syntyy helposti karkea budjetti. Ongelmana on, että se on lähes aina liian optimistinen, koska se sisältää vain keskeiset tekniset kulut.
Organisaation oma työ täytyy laskea mukaan
Suurimmat budjettiylitykset yleensä johtuvat asioista, joita ei ole osattu huomioida budjetoinnissa ollenkaan.
Yksi tärkeimmistä laskettavista asioista on organisaation oma työ. Projekti ei etene ilman sisäistä panosta: päätöksentekoa, osallistumista työpajoihin, määrittelyä ja testausta. Tämä työ on usein merkittävä kustannus, vaikka sitä ei osteta ulkoa. Nykyisin laajasti käytössä olevat ketterät projektimenetelmät myös vaativat asiakkaan omalta tiimiltä aktiivista osallistumista hankkeen kaikissa vaiheissa. Tämä voi tarkoittaa jopa useamman henkilön lähes täysipäiväistä sitoutumista hankkeen keston ajaksi.
Toinen aliarvioitu osa-alue on koulutus ja käyttöönotto. Uusi järjestelmä ei tuo hyötyjä, jos sitä ei osata käyttää. Käyttöönotto vaatii aikaa, suunnittelua ja usein myös muutoksia toimintatapoihin. Uuden järjestelmän sisäänajo voi kestää isossa organisaatiossa helposti vuoden, ja jotta järjestelmä tulee käyttöön oikealla tavalla, pitää tätäkin prosessia tukea aktiivisesti, joko kumppanin toimesta tai sisäisten asiantuntijoiden avulla.
Kolmas keskeinen kustannus liittyy ylläpitoon ja jatkokehitykseen. Mikään järjestelmä ei ole täysin valmis käyttöönoton jälkeen, vaan järjestelmät vaativat päivityksiä ja pienkehitystä joka vuosi. Tämä tarkoittaa jatkuvia kustannuksia, jotka pitäisi huomioida jo alkuvaiheessa, jotta päätöksentekijöille syntyy oikeanlainen kuva investoinnista.
Tietojärjestelmien kohdalla kustannusten jakautuminen käyttöönoton ja elinkaaren välille myös vaihtelee paljon. Esimerkiksi palveluna ostettavat ratkaisut ovat usein edullisia ottaa käyttöön, mutta mitä pidemmälle katsotaan, sitä kalliimmaksi ne tulevat, koska yleensä kustannukset eivät laske elinkaaren aikana, vaan päinvastoin.
Hyvä kustannuslaskelma sisältääkin aina arvioidut kustannukset vähintään 3-5 vuoden aikajänteelle, koska vain tällä tavalla voidaan saada erilaiset ratkaisumallit edes kohtuullisesti samalle viivalle vertailussa.
Sisäinen työ on usein suurin yksittäinen kustannus
Monessa hankkeessa sisäinen työ jää budjetoinnissa sivurooliin, vaikka käytännössä se voi olla yksi suurimmista kustannuseristä.
Esimerkiksi projektinhallinta vie aikaa. Päätöksiä pitää tehdä jatkuvasti, ja projektia pitää ohjata aktiivisesti. Tämä ei tapahdu oman työn ohessa ilman vaikutuksia muuhun tekemiseen.
Testaus on toinen merkittävä kokonaisuus. Järjestelmän toimivuus varmistetaan vasta käytännössä, ja tämä vaatii organisaatiolta aikaa ja resursseja. Usein testausta pitää tehdä jo aktiivisesti toteutustyön aikana.
Lisäksi sisällöt ja tietojen siirto vaativat työtä. Vanhojen tietojen siirto, laadun parantaminen ja rakenteiden uudistaminen ovat usein työläämpiä kuin aluksi arvioidaan. Usein sisältöjä halutaan myös parantaa tai luokitella dataa uusiksi ennen uuden järjestelmän käyttöönottoa, onko tämä työ osa hankkeen kustannuksia vai jotain muuta työtä? Ja onko tälle työlle varattu riittävästi aikaa?
Usein tietojärjestelmähankkeilla on näitä rinnakkaisia projekteja tai työkokonaisuuksia, joiden toteutuminen luo myös riippuvuuksia varsinaiselle päähankkeelle. Budjetinkin näkökulmasta syntyy usein väärä kuva, jos näitä rinnakkaisia työkokonaisuuksia ei oteta mukaan kokonaislaskentaan.
Miten esiselvitys auttaa rakentamaan realistisen budjetin?
Tietojärjestelmän esiselvityksen yksi keskeinen tehtävä on tuottaa realistinen käsitys hankkeen kustannuksista.
Kun tavoitteet, laajuus ja vaihtoehdot on määritelty, kustannuksia voidaan arvioida huomattavasti tarkemmin. Samalla tunnistetaan ne osa-alueet, jotka vaikuttavat eniten budjettiin – kuten integraatiot, datan migraatio tai organisaation oma työ.
Esiselvitys auttaa myös rajaamaan hanketta. Kun kaikkea ei yritetä tehdä kerralla, budjetti pysyy paremmin hallinnassa ja investointi voidaan jakaa vaiheisiin.
Usein johto haluaa nähdä hankkeen kokonaiskuvan mahdollisimman realistisesti, mutta se ei tarkoita sitä, että kaikkia kustannuksia pitäisi yhdistää loppusummaan. Yleensä tärkeintä on, että kaikki tarvittavat tehtävät on tunnistettu ja kuvattu, ja eri tehtäväkokonaisuuksilla on jonkinlaiset kustannusarviot, vaikka niitä ei olisikaan laskettu osaksi pääprojektia.
Hyvä esiselvitys sisältää myös markkinakartoituksen, jollakin tavalla tehtynä, jotta teknisen toteutuksen ja tarvittavien lisenssien hinta-arviot perustuvat todelliseen markkinatietoon. Kun tiedetään, millaisia ratkaisuja on tarjolla ja mitä ne maksavat, budjetti ei perustu pelkkiin oletuksiin.
Usein esiselvityksen tärkein tehtävä onkin tehdä realistinen kustannusarvio, jossa on tunnistettu kaikki keskeiset tehtäväkokonaisuudet.
Hyötyjen arviointi – mitä investoinnilla saadaan?
Hyvä budjetti ei ole kuitenkaan vain kustannusten lista. Yhtä tärkeää on ymmärtää, mitä investoinnilla saadaan.
Osa hyödyistä on suoraan mitattavissa. Esimerkiksi manuaalisen työn väheneminen tai prosessien nopeutuminen voivat näkyä konkreettisina säästöinä. Joskus uudistus mahdollistaa vanhan ja kalliin järjestelmän alasajon. Tällöin budjetin tulee huomioida se, että jossain vaiheessa vanhan järjestelmän kustannukset loppuvat.
Toinen osa liittyy työn tehostumiseen. Työ sujuu paremmin, virheet vähenevät ja tieto on helpommin saatavilla. Usein johtoa kiinnostaa, kuinka isoon joukkoon henkilöstöä uudistus vaikuttaa – kuinka monen ihmisen työ tehostuu ja kuinka paljon esimerkiksi viikkotasolla? Euroiksi näitä lukuja ei kannata väkisin vääntää, usein riittää kun osaa kuvata sen, millaista tehostumista tavoitellaan ja kenelle.
Kolmas näkökulma on laadullinen. Parempi asiakaskokemus, parempi työntekijäkokemus tai parempi tiedolla johtaminen voivat olla ratkaisevia, vaikka niitä ei mitata suoraan rahassa. Usein nämäkin asiat on syytä tuoda esille, kun puhutaan investoinnin kokoluokasta ja tarvittavasta rahasta. Johto kyllä tietää hyvin, että laadullisten parannusten kääntäminen euroiksi on vaikeata, mutta se ei tarkoita sitä, etteikö niillä olisi merkitystä. Joskus miljoonan euron järjestelmäinvestointi on järkevä ihan vain siksi, että jonkun asian laatua saadaan parannettua, jollakin tavalla.
Hyvin tehty esiselvitys auttaa tunnistamaan nämä hyödyt ja suhteuttamaan ne kustannuksiin.
Realistinen budjetti syntyy ymmärryksestä
Tietojärjestelmäprojektin kustannukset eivät ole yksinkertainen luku, vaan kokonaisuus, joka koostuu monesta osasta. Suurin virhe ei ole se, että budjetti on liian pieni tai liian suuri – vaan se, että se perustuu puutteelliseen ymmärrykseen. Jos budjetti on perusteltu, hankkeen keskeiset tehtäväkokonaisuudet ja riippuvuudet on tunnistettu, on eurojen esittäminen yleensä aika suoraviivaista, ja keskustelu kääntyy sen jälkeen hankkeella saavutettaviin hyötyihin ja muutoksiin.
Kun puhutaan isoista hankkeista, isoimmat riskit liittyvät aina yllätyksiin, johonkin mitä ei olla osattu ennustaa tai ennakoida. Siksi jo budjetointivaiheessa kannattaa olla hyvä ymmärrys tavoitteista, hankkeen laajuudesta, teknisistä vaihtoehdoista ja hankkeen reunaehdoista. Näin vähennetään riskiä yllätyksille ja varmistetaan, että investointi tuottaa odotettua arvoa ja hyödyt toteutuvat.