Projektimenetelmä, joilla isoja toiminnanohjaus- eli ERP-hankkeita viedään läpi, on tuskin koskaan yksinään ainoa syy, miksi hanke epäonnistuu. Sillä voi kuitenkin olla suurempi vaikutus, kuin on osattu etukäteen ennustaa. Vaiheesta toiseen etenevä, kankea vesiputousmalli on jo monen ammattilaisenkin toimesta haukuttu huonoksi ja toiveissa on ollut heittää koko malli vanhentuneena romukoppaan. Vaikka sinänsä allekirjoitan vesiputousmallissa piilevät isotkin heikkoudet, olen viime vuosina törmännyt useampaan ns. ketterään ERP-hankkeeseen, joissa aikataulut ovat venyneet ja budjetit paukkuneet. Ketteryys on niissä tapauksissa tarkoittanut sitä, ettei päämäärä ole ollut tiedossa tai suunniteltu lainkaan, kehitys on ollut täysin kontrolloimatonta hankeen laajuuden räjähtäessä käsiin ja lopulta pakettiratkaisuna hankittu ERP on räätälöity pilalle ja kaatuu omaan monimutkaisuuteensa. 

Kun pyrkimyksenä kaikilla on kuitenkin toteuttaa hankkeita, jotka pysyisivät aikataulussa ja budjetissa, parhaisiin lopputuloksiin päästään hyödyntämällä elementtejä molemmista projektimalleista.  Alla on listattuna kolme tärkeintä elementtiä, miksi tällainen hybridimalli sopii parhaiten ERP käyttöönottoihin. 

Ketterät menetelmät lähtevät usein siitä, että ratkaisua kehitetään pienissä palasissa. Tämä onkin niiden heikkous laajojen toiminnanohjaushankkeiden kohdalla. Isot ERP-arkkitehtuurit ovat monimutkaisia kokonaisuuksia, joihin linkittyy usein satoja integraatiovirtoja. Lisäksi relaatiotietokantoihin perustuvan ERP-pakettiratkaisun sisällä kaikki vaikuttaa kaikkeen ja tietokantarakenteet ovat äärimmäisen monimutkaisia. Näin ollen koko käyttöönotettava kokonaisuus on tärkeää hahmottaa prosessitasolla, ennen kuin kehitystä lähdetään viemään eteenpäin. 

Detaljin tason konfiguraatiota taas ei kannata yrittää lukita liian aikaisessa vaiheessa, koska osaaminen ja ymmärrys ratkaisusta kasvaa projektin edetessä. Toimittajan ymmärrys kasvaa liiketoimintatarpeista ja asiakkaan ymmärrys kasvaa järjestelmän tuomista mahdollisuuksista. Tässä onkin syy, miksi moni puhdas vesiputoushanke epäonnistuu: yritetään määritellä projektin alussa jotain, mistä ei ole tarkemman tason ymmärrystä. Tämä ei tarkoita sitä, etteikö päämäärää voisi silti suunnitella hyvin.

Prosessit tulisikin käydä liiketoiminnan ja toimittajan edustajien kanssa tarkasti läpi heti hankkeen alussa ja mallintaa ne uuteen ratkaisuun, sekä sopia yhteinen tavoitetila tältä osin ennen etenemistä projektissa. Missä liiketoiminnan kohdissa tunnistetaan uuden ratkaisun puutteet ja missä erityiset hyödyt? Näin voidaan jo alkuvaiheessa tunnistaa kohtia, joissa tarvitaan kenties välttämätönkin räätälöinti, tai voidaan argumentoida sen puolesta, pitäisikö nykyistä tapaa toimia muuttaa sen sijaan. Joka tapauksessa päämäärä, johon haluamme edetä, on näin tiedossa jo hyvissä ajoin prosessitasolla.  

Vesiputousmallin heikkous on sen kankeus muutoksille. Vaikka prosessit olisi mietitty tarkastikin, voi niihin väistämättä tulla muutoksia matkan varrella, kun ymmärrys ja osaaminen kasvavat puolin ja toisin.  Ketterän mallin heikkous taas on se, jos lähdetään ilman kunnollista kokonaissuunnittelua sprintteihin ja kehitetään pakettiratkaisua lennosta pienissä prosessien pätkissä. Tästä voi syntyä hallitsematon räätälöintien vyyhti. Ketterän projektimallin etu tulee kuitenkin tässä: kun projektissa on suunniteltuna tavoitetilan prosessit ja ratkaisun kokonaisuus on käyty hyvin yhdessä lävitse, voidaan ERP:in määrittely tehdä ns. parhaan arvauksen logiikalla ja alkaa testaamaan ensimmäisiä kierroksia ensimmäisellä mahdollisella konfiguraatiototeutuksella heti projektin alussa. Siten asiakas pääsee kokeilemaan järjestelmää ja sen toiminnallisuuksia kädet savessa. 

Näin kummankin osapuolen oppi kasvaa projektin alusta saakka yksityiskohtaisella tasolla ja ratkaisua voidaan iteratiivisesti testaten säätää konfiguraation näkökulmasta paljonkin. Näin jo sovittujakin prosesseja voidaan muokata yksityiskohtaisella tasolla useaankin otteeseen ja päädytään siten lopulta tekemään vain ne täysin välttämättömät räätälöinnit standardiratkaisuun. Konfiguraatiolla voi ”leikkiä” ilman, että heti rynnätään tekemään koodausta standardiratkaisuun. 

Tällä keinoin tuttu mantra ”minimoidaan räätälöinnit” saadaan aidosti toteutumaan ja projektin laajuuden muutoksia hallitaan läpi projektin.  

Yksi vesiputousmallin suurimpia heikkouksia on se, että tuotos luovutetaan vasta siinä vaiheessa testaukseen asiakkaalle, kun kokonaisuus on määritelty ja kehitetty toimittajan toimesta. Määrittelyvaiheen ja hyväksymistestausvaiheen väliin voi jäädä helposti puolikin vuotta, jonka aikana aktiivinen testaus kohdistuu puhtaasti teknisen toteutuksen testaamiseen prosessien sijaan. Tästä aiheutuu se, että hyväksyntätestauksen (UAT) rooli on vesiputousmallissa äärimmäisen korostunut, ja koko projektin painopiste helposti keikahtaa ko. testivaiheeseen projektin loppupäähän. Hyväksymistestausvaiheessa aloitetaan tällöin helposti uusi kehitysvaihe, kun kaikki esille tulleet bugit korjataan, ja uudet tunnistetut muutostarpeet kehitetään. Tällöin projekti väkisinkin venyy, ja budjetti karkaa käsistä.  

Kun hyödynnetään ketterän menetelmän ideaa määrittely- ja kehitysvaiheessa, vesiputousmallin kaltaisesta hyväksymistestausvaiheesta tulee luonteeltaan kevyempi. Tällöin UAT-testivaiheen tarkoituksena on lähinnä (tupla)varmistaa koko kokonaisuuden tekninen oikeellisuus, prosessien saumattomuus ja datan laatu konvertoidun datan avulla.   

Malleja toimia on varmasti useita, mutta yhdistelemällä elementtejä molemmista projektimalleista päästään ERP projekteissa parhaisiin lopputuloksiin. Tämä uudenlainen tapa toimia vaatii kuitenkin kaikilta toimijoilta kykyä muuttua. Asiakkaan panoksesta tulee paljon kriittisempi ja suurempi projektin edistämisessä kuin puhtaassa vesiputousmallissa. Ketterät toimintatavat taas voivat vaatia toimittajaosapuolilta paljonkin työtä, jotta konsultit osaavat ottaa fasilitoivampaa ja ohjaavampaa roolia projekteissa.  Alla on kuvattuna yhdenlainen esimerkki käyttöönottohankkeen läpiviemisestä hybridimallilla. 

Lopuksi mainittakoon, että liittymäkehitys on usein kriittisessä roolissa ERP-hankkeissa. Liittymäkehityksen ja -testauksen läpivieminen onkin yleensä merkittävä ponnistus, johon tässä kirjoituksessa ei ole pureuduttu. Liittymäkehitystäkin voidaan tehdä ketterästi osana ERP-hankkeiden kokonaisuuksia, mutta toiminnallisen määrittelyn tärkeys liittymäkehityksessä on edelleen yksi niiden kehityksen tärkeimpiä kulmakiviä.


Kirjoittaja:

Kati Kolehmainen
Senior Manager, ERP Advisory
BearingPoint Finland

Toggle search
Toggle location