Voiko toiminnanohjausjärjestelmästä ja ketteryydestä puhua samassa lauseessa?

Erityisesti IT-maailmassa kaiken pitäisi olla nykypäivänä ketterää, jopa perinteisen toiminnanohjauksen. Yritysten IT-osasto jää helposti liiketoiminnan ja IT-toimittajan puristuksiin, kun liiketoiminta haluaa nopeita muutoksia ja ketterää kehitystä, mutta ERP on kuin iso ratas, joka pyörii hitaasti päivityssyklien mukaan.

Perussyynä hitaudelle on se, että ERP on vuosien saatossa rakennettu asiakaskohtaiseksi monoliitiksi ja muutosten tekeminen on vaikeaa. ERP-ratkaisun elinkaari on vähintään kymmenen vuotta, joten monet yritykset elävät nykyjärjestelmien ehdoilla vielä pitkään. Jossain vaiheessa järjestelmät kuitenkin päivitetään, ja silloin on hyvä hetki tehdä asiat uudella tavalla.

Nykyaikaiset toiminnanohjausjärjestelmät ovat standardeja pilvituotteita tai vähintään hyvin tuotteistettuja ohjelmistoja. Valmisohjelmistojen käyttöönotto ei ole varsinaista ohjelmistokehitystä, joten ketterän kehityksen menetelmät eivät ole suoraan sovellettavissa niihin.

Olen tutkinut mielenkiinnolla, miten ketteriä ohjelmistokehityksen menetelmiä voidaan hyödyntää myös toiminnanohjaus- ja valmisohjelmistomaailmassa. Käsittelen alla muutamaa hyödynnettävää periaatetta.

1. Joustava määrittely

Valmisohjelmisto on VALMIS, ja sen käyttötavoissa on rajoituksia, joita kannattaa noudattaa. Yrityksen nykyprosessien yksityiskohtaisen kuvaamisen sijaan kannattaa keskittyä kaksisuuntaiseen ymmärryksen jakamiseen pitkin käyttöönottoa. Asiakkaan ymmärrys liiketoiminnasta ja toimittajan ymmärrys järjestelmästä täytyy yhdistää. Paras tapa on käydä asiakkaan toimintoja läpi järjestelmää vasten ja kuvata käyttäjätarinat.

2. Tiivis yhteistyö ja suora keskustelu välillisen viestinnän sijaan

Kiinteä projektitiimi ja suora keskusteluyhteys eri osapuolten välillä vähentää merkittävästi väärinymmärrysten riskiä ja parantaa projektin laatua. Yhteistyötä ja jatkuvaa vuorovaikutusta voidaan lisätä muun muassa yhteisellä projektitilalla ja päivittäisillä läpikäynneillä.

3. Käyttäjä- ja roolipohjainen suunnittelu

Valmisohjelmistoprojektien perisynti on ollut liika asiakaskohtainen räätälöinti ja siitä johtuva raskas järjestelmän ylläpito tulevaisuudessa. Nykyisin räätälöinti nähdäänkin pahana läpi linjan. On kuitenkin tarpeellista ymmärtää hyvän ja pahan räätälöinnin ero. Esimerkiksi nykyaikaisten ERP:ien käyttöliittymät voidaan muokata käyttöön sopivaksi ilman, että taustalla olevia prosesseja muutetaan.

4. Iteratiivinen kehitys ja jatkuva testaaminen

Perinteisesti toimitusprojektit ovat liian pitkiä, maailma ehtii muuttua ja järjestelmä on vanha tai vääränlainen jo syntyessään. Käyttöönoton tulee koostua lyhyistä iteraatiovaiheista. Aluksi voidaan toteuttaa integroidut perusprosessit eli ns. luuranko-mallit ja laajentaa niitä iteraatioiden myötä. Iteraatioiden tuotoksia testataan vaiheittain niiden valmistuttua.

5. Aikaiset julkaisut

Ajoittain kuulee sanottavan, ettei käyttöönottoa ole mahdollista vaiheistaa. Usein tämä kuitenkin onnistuisi rakentamalla väliaikaisia integraatioita vanhan ja uuden järjestelmän välille tai siirtämällä tietoja manuaalisesti. Tämä tulisi nähdä ylimääräisen kustannuksen sijaan vakuutusmaksuna ja mahdollistajana aikaisemmalle käyttöönotolle pienemmillä riskeillä.

Toiminnanohjausjärjestelmien toimituksissa voidaan siis hyödyntää ketteriä menetelmiä soveltaen. Muutokset toimintatavoissa eivät ole välttämättä suuria, mutta niiden merkitys projektille voi sitä olla. Suurin haaste muutokselle on ERP-projektien perinteiset toimintamallit ja niistä poisoppiminen.