05.04.2017 | Blogi

Utopiasta Mordoriin – suunnittelujärjestelmän hankinta

Kerron teille yhden ennuste- ja seurantajärjestelmän tavallisen tarinan. Tämä ei vastaa välttämättä suoraan yhtä todellista järjestelmäprojektia, vaan on kokoelma useista ja usein toistuneista tapauksista. Miten suunnittelujärjestelmä kannattaa hankkia, miten vältät harhapolut ja säilytät matkan määränpään kirkkaana?

Matkalla Utopiaan

Yrityksen (joka voisi ihan yhtä hyvin olla julkisyhteisö) talousjohtaja on vaihtunut. Uusi johtaja haluaa laittaa organisaation suunnittelu- ja seurantajärjestelmät ajan tasalle, sillä hän huomaa, ettei nykyinen (mahdollisesti Excel-pohjainen) järjestelmä enää riitä.

Uudistaminen on perusteltua, sillä hyvät suunnittelu- ja raportointijärjestelmät tukevat suoraan johdon strategiaa, mikäli suunnittelussa käytettävät elementit linkitetään strategiassa sovittuihin tavoitteisiin. Prosessimielessä talousjohtaja haluaa keventää ennusteprosessia ja lisätä prosessin läpinäkyvyyttä.

Talousjohtaja tapaa eri toimittajia jo alkuvaiheessa ennen varsinaista hankintapäätöstä ja tarjouspyynnön tekemistä. Hän käy muun muassa messuilla ja kutsuu eri järjestelmätoimittajia käymään. Tällöin hänelle muodostuu yhä selkeämpi kuva tilanteesta – yritys tarvitsee järjestelmän, joka kannustaa vielä paremmin yhtiön tavoitteiden saavuttamista.

Ensimmäinen harharetki on sääntö, ei poikkeus

Kun talousjohtaja on tehnyt järjestelmän hankintapäätöksen ja ryhtynyt kirjoittamaan vaatimusmäärityksiä, muuttuu strategiaa tukeva järjestelmähanke kuin taikaiskusta ’prosessien viilaus’ -hankkeeksi ja ’ominaisuuskarkki’-toivelistaksi. Sen sijaan, että hän kysyisi tarjouspyynnössä toimittajan kokemuksesta toteuttaa ajuripohjaisia rullaavan ennustamisen järjestelmiä, hän kysyy kahta asiaa: pystyykö järjestelmä tallentamaan useita valuuttoja (kaikki järjestelmät pystyvät tähän) tai onko mahdollista saada x kappaletta automaattisia raportteja ottamatta kantaa niiden sisältöön tai mielekkyyteen. Se tärkein, eli strategiaa tukevan saumattoman integraation tarve on mainittu johdannossa.

Määrittelyvaiheessa talousjohtaja jää taka-alalle ja tilalle tulee eri osa-alueiden vastuuhenkilöitä tuoden mukanaan omat vaatimuksensa, jotka yleensä tarkoittavat joidenkin vanhojen käytäntöjen tuomista mukaan uuteen järjestelmään. Tämä tarkoittaa muun muassa tietyn raportin tuottamista järjestelmästä samanlaisena kuin ennenkin.

Lopulta projektin tavoitteeksi kirjataan suunnitteluprosessin tehokkaampi läpivienti. Tämä jää kuitenkin sanahelinäksi, koska alkuperäinen muutosagentti ei ole enää aktiivisesti mukana.

Revitään kartta, kyllä kauppalistallakin perille päästään

Toteutusvaiheessa ehdottomat must -jutut alkavat tulla esiin. Ne, jotka unohtuivat tarjouspyynnöstä eivätkä nousseet esiin määrittelyvaiheessa. Niiden joukossa joidenkin yksiköiden osalta on muun muassa liiketoimintaloogisia poikkeuksia, mikä pakottaa pahimmassa tapauksessa määrittelemään muutaman osan toimintalogiikan täysin erilaiseksi. Myös järjestelmän sisäiset siirrot nousevat esiin tässä vaiheessa.

Talousjohtaja kuulee projektin etenevän suunnitellusti, vaikka todellisuudessa projektissa yritetään keksiä keinoa kopioida budjetti PTS:n pohjaksi automaattisesti, vaikka suunnittelutarkkuus onkin PTS:ssä täysin erilainen. Tämä on projektiryhmän sisällä top1-prioriteetti, vaikka määrittelyvaiheessa tästä ei keskusteltukaan.

Alkuperäinen tavoite strategisten tavoitteiden paremmasta integraatiosta on jo unohtunut. Talousjohtajalle kerrotaan saavutuksena: ”Nyt saadaan laskettua ennustettu poistoeron muutos seuraavalle kuudelletoista kuukaudelle”.

Käyttöönottovaiheessa keskitytään prosessin läpimenoaikoihin ja ihmetellään, miten kuukausittainen ennuste saadaan valmiiksi kuun neljäs arkipäivä, kun kirjanpito valmistuu viides arkipäivä. Tässä vaiheessa projektiryhmä on työllistynyt niin monen pienen yksityiskohdan hiomiseen, että minkään korkeamman tason tarkastelu ei ole edes mahdollista.

Projekti päätetään vihdoin ja siirretään ylläpitoon. Lopputuloksena on järjestelmä, joka ei erityisesti ole tehostanut prosesseja, mutta sisältää paljon ominaisuuksia, joita ei käytetä. Päätöspalaverissa todetaan, että raskasta oli, mutta päästiin maaliin. Lopulta myös huomattiin, että kun matkan varrella oppia tuli lisää puolin ja toisin, myös tavoitteet muuttuivat jossain kohtaa.

Miten suunnittelujärjestelmän hankinnassa olisi voitu toimia toisin? Tässä kolme vinkkiä, joista kannattaa aloittaa:

  1.  Ota iso kuva haltuun. Kirkasta itsellesi ja kaikille suunnitteluun osallistuville osapuolille, miksi suunnittelua tehdään. Organisaation eri tasojen tarpeet voivat luonnollisesti vaihdella, mutta jos ne ovat ristiriidassa keskenään, ei kukaan tule olemaan lopputulokseen tyytyväinen.
  2. Määrittele onnistumiselle tavoitteet ja mittarit. Projektissa mittarit voidaan pilkkoa tarvittaessa pienemmiksi tavoitteiksi. Mittarien valinnassa tehdään myös arvovalintoja. Mikäli prosessi halutaan saada nopeammaksi, ei samaan aikaan ole mahdollista laajentaa kerättävien tietojen määrää.
  3. Tee toteutus pala kerrallaan. Vaikka lopullisena tavoitteena olisi uudenlaisen laskennan toteuttaminen, kuten esimerkiksi henkilöryhmätasoinen palkkasuunnittelu, ei sitä välttämättä kannata toteuttaa ennen kuin muu järjestelmä toimii. Vaikka tämä saattaa aiheuttaa asioiden tekemistä kahteen kertaan, saadaan järjestelmä lopulta tuotantoon nopeammin, kun toteutuksessa voidaan keskittyä yhden osan kuntoon laittamiseen.
Utopiasta Mordoriin – eli mistä mihin? Utopia (muinaiskreikan kieltävä etuliite u- sekä topos ’paikka’ – sananmukaisesti siis ”paikka, jota ei ole”) tarkoittaa jonkinlaista tulevaisuuden ihanneyhteiskuntaa. Mordor on paikka J. R. R. Tolkienin luomassa fantasiamaailma Keski-Maassa. Kirjassa se on karua joutomaata.

Kiinnostuitko? Tutustu ratkaisuihimme verkkosivuillamme ja lue lisää ajankohtaisista blogeistamme. Lisäksi mikäli haluat päästä nopeasti liikkeelle tai kaipaat apua, ota rohkeasti yhteyttä!

Kurkkaa myös avoimet työpaikkamme. Etsimme jatkuvasti uusia kollegoita joukkoomme. Oletkohan sinä seuraava solitalainen?