Toiminnanohjausjärjestelmän onnistuminen edellyttää oikeaa kehitysmetodologiaa

ERP-hankkeet ovat tunnetusti monimutkaisia ja riskialttiita. Gartner arvioi, että 55-75% ERP-hankkeista ei saavuta tavoitteitaan. Panorama Consulting:n (2015) tutkimuksessa 75% ERP-hankkeista ylitti aikataulun, 55% kustannukset ja 41% saavutti alle puolet tavoitelluista hyödyistä. Hankkeen epäonnistumisen tai vaihtoehtoisesti sen onnistumisen taustalla on useita tekijöitä. Yrityksen tarpeisiin vastaava kehitysmetodologia ja sitä kautta tehokkaasti hoidettu toteutus on yksi keskeinen onnistumisen edellytys.

Vesiputousmallissa työ etenee vaihe vaiheelta vaatimusmäärittelystä toteutukseen, testaukseen ja käyttöönottoon. Toteutettavan toiminnallisuuden ollessa suuri, kunkin vaiheen kesto on useita kuukausia. Ongelmaksi erityisesti toteutuksen osalta voi tulla näkyvyyden puute – ei voida olla varmoja aikataulun pitävyydestä ja siitä, vastaako toteutumassa oleva ratkaisu tunnistettuja tarpeita ja onko kaikki tarpeet osattu huomioida kerralla. Iteratiivisissa kehitysmenetelmissä tämä ongelma pyritään ratkaisemaan jakamalla työ muutaman viikon jaksoissa määritettäviin, toteutettaviin, testattaviin ja käyttöön otettaviin kokonaisuuksiin. Puhtaan iteratiivisten menetelmien soveltaminen laajoihin toiminnallisiin muutoksiin on kuitenkin haasteellista, jos ensimmäinen käyttökelpoinen, kokonaisuutena testattavissa tai käyttöönotettavissa oleva ratkaisu vaatii useiden kuukausien toteutustyön.

Yksi käytännössä hyväksi koettu menetelmä on iteratiivisen ja vesiputousmallin välimuoto. Tässä mallissa vaatimusten määrittelytyö tehdään keskeisiltä osin yhtenä kokonaisuutena, ainakin karkealla tasolla. Tämän jälkeen toteutus kullakin toiminnallisella osa-alueella jaetaan 2-4 viikon jaksoihin (sprintteihin), jolloin kunkin jakson sisältö tiedetään pääpiirteissään kehitystyön alkaessa. Toteutuksen suunnittelu tehdään projektijohdon, kehittäjien ja liiketoiminnan yhteistyönä, jolloin aikataulu pysyy realistisena ja tekijät saadaan sitoutettua aikatauluun. Kukin kehityskierros tarkentaa tarvittaessa määrittelyitä. Kunkin jakson lopussa on valmiina käyttäjäorganisaatiolle esiteltävissä (demottavissa) oleva toiminnallisuus, joka laajenee jokaisen kehitysjakson myötä. Hyväksyntätestaus voidaan aloittaa viimeisten kehitysiteraatioiden ollessa vielä meneillään, jos jäljellä olevalla kehitys ei aiheuta olennaista uudelleentestauksen tarvetta. Avoimien muutosten määrä voi olla suurempi, jos käytettävissä on automatisoitu testitapausten joukko, joka voidaan helposti ajaa läpi kunkin iteraatiokierroksen jälkeen. Tällaisen testauksen hyödyntäminen on parhaimmillaan regressiovaikutusten pitämiseksi kurissa.

Työn pilkkomisella iteraatioihin on useita etuja. Käyttäjät pääsevät näkemään ja saavat tuntuman tulossa olevasta toiminnallisuudesta jo ennen testausta ja voivat antaa palautetta kehityksen aikana. Kehittäjillä on selkeät välitavoitteet ja samalla saadaan pidettyä yllä kiireen tuntu läpi projektin. Hankkeen vetäjä voi välietappien myötä varmistaa, että projektissa ollaan aikataulussa ja saavutetaan tavoitellut toiminnalliset ratkaisut.

Iteratiivinen kehittäminen soveltuu parhaiten tilanteisiin, joissa tavoitetila ei ole täysin hahmottunut. On myös tilanteita, joissa tarpeet ovat varsin yksiselitteisesti tiedossa. Esimerkiksi sopii järjestelmän laajentaminen kymmenenteen tehtaaseen vakiokaavaa noudattaen. Tällöin ratkaisua ei tarvitse tarkentaa matkan varrella, toteutus on suoraviivaista ja vesiputousmalli voi olla paras vaihtoehto.

Ilkka Töyrylä, Midagon Oy

Lähde: Midagon Oy