ERP-hankkeissa törmätään toistuvasti ongelmiin, jotka aiheutuvat yrityksen sisäisen toimintaympäristön puutteista. Yrityksen prosesseja ei ole määritelty, data on kuralla, kehitys- ja testiympäristöt puuttuvat, projektikulttuuria ei ole, pääkäyttäjät puuttuvat ja määrittelystä ja testauksesta vastaavilla henkilöillä ei ole osaamista rooleissaan toimimiseen. Jos tekemisen puitteet joudutaan laittamaan kuntoon osana ERP-hanketta, voi tästä aiheutua merkittäviä aikatauluviiveitä ja ERP-hankkeen kustannukset myös nousevat, kun varsinaisen ERP-tekemisen lisäksi joudutaan hankkeen aikana korjaamaan rästiin jääneet asiat.

Ideaalitilanteessa edellä mainittujen asioiden kunnossa pitäminen on osa jatkuvaa toimintaa. Jos näin ei ole, tulisi puitteiden kunnostus aloittaa viimeistään ERP-hankkeen valmistelu- ja suunnitteluvaiheessa. Valitettavan usein perusasioiden kuntoon laitto kuitenkin unohdetaan, jolloin ongelmat joudutaan ratkaisemaan pakon edessä kesken toteutuksen.

Ratkaisun ja hankkeen perustukset kuntoon ennen kuin potkaiset hankkeen käyntiin

Ennen varsinaisen hankkeen aloitusta on määriteltävä perusperiaatteet niin valitun ratkaisun kuin hankkeen läpiviennin osalta. Hankkeen suunnittelun, sovellusratkaisun ja implementointikumppanin valinnan rinnalla tai jo tätä ennen tulisi tehdä valmistelutöitä useilla eri osa-alueilla.

Äärimmäisen tärkeää on selkeän hallintamallin määrittäminen ja sen varmistaminen, että kaikki päätöksentekoon osallistuvat sisäistävät omat roolinsa ja vastuunsa. Yksi osa hallintamallia on mm. päätöksenteon foorumeista sekä hankkeen etenemisen seurannasta ja raportoinnista sopiminen riittävällä tarkkuudella. Silloin kun hallintamalli ei ole kunnossa, päätöksiä ei saada tai niiden saaminen kestää liian kauan. Hankkeissa törmätään jatkuvasti tilanteisiin, jossa liiketoiminnan puolelta esitetään erilaisia, keskenään ristiriitaisia mielipiteitä siitä, miten järjestelmän tulisi toimia, mutta kenelläkään ei ole valtuuksia tehdä asiassa lopullista linjausta. Hankkeen kannalta tämä on kestämätön tilanne, ja päätöksentekomallin tulisikin olla kunnossa heti alkumetreiltä lähtien.

Tutustu ja lataa: Midagonin projektitemplateja hankesuunnittelun tueksi

Jotta järjestelmäprojekti tuottaisi liiketoimintahyötyjä ja olisi muutakin kuin vanhan ERP-ympäristön tekninen päivitys, toimintamallit ja prosessit tulisi määritellä hyvissä ajoin. Vanhan ERP:n prosessit voivat olla 20 vuoden takaa. Vastaavasti, uuden ERP-toteutuksen vaikutukset ulottuvat helposti 10-20 vuoden päähän. Sen vuoksi vanhan kopiointia sellaisenaan tulisi varoa ja rakennettava uusi liiketoimintamalli tulisi miettiä huolella hyvissä ajoin. Tilanne, jota tulisi välttää on se, jossa perustavanlaatuisia linjauksia joudutaan tekemään lennosta projektin toteutuksen yhteydessä tai ICT-organisaatio joutuu päättämään asioista, joihin liiketoiminta ei ole ottanut kantaa.

Sovellus- ja integraatioarkkitehtuuri on ERP-hankkeen kannalta keskeinen työkalu, jota käytetään mm. tarvittavien integraatioiden suunnitteluun. Ennen ERP-hanketta tulisi varmistaa, että arkkitehtuurikuvaukset ovat kunnossa. Muutoin ne joudutaan laatimaan hankkeen aikana. Erään ERP-hankkeen esiselvitysvaiheessa liittymien määrä – ja siten kustannukset – oli estimoitu ilman riittävää käsitystä olemassa olevasta arkkitehtuurista. Sen lisäksi, että arkkitehtuurikuvaukset jouduttiin tekemään osana ERP-hanketta, jouduttiin liittymätyön kustannusarvio yli kaksinkertaistamaan, kun todellinen työmäärä selvisi. 

Perustietojen (master datan) laatu vaikuttaa lähes kaikkeen, mitä ERP:llä ja muilla järjestelmillä tehdään. Huonolaatuinen data voi esimerkiksi estää tuotteiden myynnin, johtaa vääriin varastotasoihin tai virheelliseen talousraportointiin. Olemassa olevan datan kuntoon laittaminen ja tulevien rakenteiden määrittäminen kestää minimissäänkin kuukausia, usein merkittävästi pidempään. Esimerkkeinä näistä vaikkapa asiakas- ja toimittajarekisterin puhdistaminen tai uuden tilikartan ja tulosyksikkörakenteen määritys. Sen vuoksi työ tulisi aloittaa jo hyvissä ajoin ennen ERP-hanketta. Jotta laadun paraneminen olisi pysyvää, tulisi perustietojen ylläpitoon liittyvien vastuiden ja prosessien olla kirkkaita. Perustietojen kuntoon laittamisen rinnalla, tulisi vanhan ERP:n transaktiodata käydä läpi ja tehdä tietojen poisto tai arkistointi, jotta uuteen ERP:in ei tarvitsisi siirtää tarpeetonta tietoa.

Hankeorganisaation kannalta ensisijaisen tärkeää on realistinen ja tarkoituksenmukainen resursointi. Projektiin nimettävien henkilöiden tulee tarvittavan kompetenssin lisäksi pystyä antamaan projektille riittävästi aikaa. Heidän kokonaistyökuormansa tulee arvioida ja selkeästi määrittää, mitkä linjatehtävät (ellei jopa kaikkia) siirretään projektin ajaksi jonkun toisen, mahdollisesti erikseen palkatun tuuraajan, toimenkuvaan. Ylioptimismi sen suhteen, kuinka paljon projektitöitä linjaorganisaatio pystyy hoitamaan oman roolinsa ohessa, on tyypillinen viivästyksiä aiheuttava sudenkuoppa hankkeissa. Toinen tyypillinen kompastuskivi on projektityön edellyttämä osaaminen. Yrityksen projektikulttuuri voi olla heikko, jolloin projektimuotoisessa työskentelytavassa toimiminen kangertelee. Usein osaaminen vaikkapa määrittelyiden tekemiseen tai testausroolissa toimimiseen ei ole riittävää. Organisaatiota tulisikin valmentaa etukäteen näissä rooleissa toimimiseen. 

Myös hankesalkkuun on syytä luoda kriittinen katse. Mitä muita hankkeita on käynnissä tai suunnitteilla samaan aikaan ERP:n kanssa? Usein samat henkilöt ovat mukana monessa kehityshankkeessa, onko heillä ja organisaatiolla kykyä toteuttaa nämä kaikki yhtä aikaa rinnakkain ja lomittain? Entä linjaorganisaation ja liiketoiminnan muutoskyky, kyky sulattaa monta uutta työkalua ja toiminnan muutosta samaan aikaan? Organisaation ja ihmisen muutoskyky on aina rajallinen, joten linjaorganisaation toimintakyky hankkeen aikana tulee varmistaa mahdollisuuksien mukaan muita karsimalla ja lykkäämällä.

Ratkaisun kannalta tärkeitä suunnitteluvaiheessa huomioitavia tekijöitä ovat muun muassa yrityksen laitekanta ja sen sopivuus valittuun ratkaisuun. Eräässä esimerkkitapauksessa huomattiin, että juuri hankitut päätelaitteet eivät olleetkaan yhteensopivia valitun ratkaisun kanssa. Oman ulottuvuutensa tuovat lisäksi jo olemassa olevat järjestelmät, joiden kanssa uusi ERP integroidaan keskustelemaan. Uuden ERP:n lisäksi tulee varmistaa myös jo käytössä olevien sovellusten kehitys- ja testiympäristöjen olemassaolo, sillä ERP-kehitys ja testaus koskettaa väistämättä myös ympäröivää järjestelmäkokonaisuutta, ei pelkästään uutta ERP:iä. Jos kunnollisia testiympäristöjä ei ole, joudutaan joko tinkimään testauksen laadusta tai rakentamaan ympäristöjä hankkeen aikana lisäten sen työkuormaa, kustannuksia ja kestoa.

Myös hankkeeseen liittyvät lasku- ja kustannusvirrat on hyvä avata selkeästi ruohonjuuritasolle asti, jotta projektin kustannusseuranta on kunnossa heti alusta alkaen. Mistä projektin kustannukset koostuvat? Mitä kustannuksia huomioidaan? Missä ja miten laskut kirjataan? Entä miten sisäiset kustannukset allokoidaan projektille? Mitä monimutkaisempi yritysrakenne, sitä oleellisempaa on varmistaa sisäisen laskutuksen käytännöt; miltä yksiköiltä projektin kustannuksia viime kädessä laskutetaan ja millaisilla periaatteilla? Myös työkalut niin kustannusten kuin kaiken muunkin hallintaan ja raportointiin tulee selkiyttää ja suunnitella etukäteen.

Minkä taakseen jättää, sen edestään löytää

Käytettävissä olevista resursseista ja hankkeen laajuudesta riippuen valmistelu- ja suunnitteluvaiheelle tulisi varata keskimäärin 6-12 kuukautta. Tämän ohittaminen tai läpi juokseminen johtaa vääjäämättä hankkeen venymiseen, toteutuksen laadun heikkenemiseen ja sitä kautta kustannusten kasvuun. Pahimmassa tapauksessa vaiheita joudutaan toistamaan, kun kiireessä ja kokonaisuutta katsomatta tehdyt päätökset osoittautuvat huonoiksi ja niitä joudutaan muuttamaan hankkeen varrella. Epäonnistunut hanke realisoituu käyttöönoton jälkeen pahimmillaan asiakkaille asti näkyvänä notkahduksena, joka voi kestää hyvinkin pitkään.

ERP-hankkeeseen ryhtyvän painajainen on päätyä lehtiotsikoihin ja selittelemään asiakkaille ja yhteistyökumppaneille, miksi tuotteet, palvelut, laskut ja raha eivät liikukaan suunnitellusti uuden ERP:n myötä. Perusteellisella suunnittelulla ja valmistelulla painajaisen todennäköisyys pienenee jo merkittävästi. 

Yritysten sisältä ei välttämättä löydy tarvittavaa ERP-kokemusta, henkilöitä, jotka olisivat olleet mukana saatikka vieneet läpi vaativia ERP-muutoksia. ERP-hankkeet ovat laajuudeltaan ja vaativuudeltaan omaa luokkaansa, ja juuri aiemmista hankkeista saadun kokemuksen avulla maksimoidaan onnistumismahdollisuudet ja vältetään tunnetut sudenkuopat. Jos oma kokemus ja resurssit eivät riitä kaikkeen tarvittavaan, tukea voi ostaa riippumattomalta toimittajalta itse toteutuksen lisäksi myös valmisteluun.