Tässä blogissa käsittelemme merkittävimpiä syitä miksi räätälöintien minimointi on ERP-projektien onnistumisen kannalta tärkeää ja pitkällä aikavälillä se on myös tekijä, joka lisää asiakkaiden tyytyväisyyttä järjestelmään. ERP-järjestelmien suunnittelu ja kehittäminen on haastavaa, sillä suunnitteluvaiheessa on vaikea vielä hahmottaa konkretiaa. Lähdetään liikkeelle konkretiaa hahmottavan esimerkin kautta:

Kuvittele tilanne, että olet hotellissa ja haluat tehdä myöhäisen uloskirjautumisen. Asiakkaana saat olla kaksi tuntia pidempään huoneessa ja muutos ei tunnu kovin suurelta tavallisen kello 12 uloskirjautumiseen verrattuna. Hotellin tukitoiminnoissa se kuitenkin vaatii joustamista ja ylimääräistä työtä. Ensin respatyöntekijän täytyy varmistaa, että samaan huoneeseen ei ole tulossa uutta asiakasta samana päivänä, tämän lisäksi hänen täytyy kirjata järjestelmään ja ilmoittaa hotellisiivoojille, että huonetta ei saa siivota vielä. Siivoojan täytyy aikatauluttaa huoneiden siivous uudestaan ja järjestellä aikataulu niin, että hän palaa siivoamaan ko. huoneen tavallista myöhemmin. Jos respatyöntekijä kuitenkin unohtaa ilmoittaa siivojalle tai jostain syystä myöhäinen uloskirjautuminen ei näy järjestelmässä voi kokemus olla asiakkaalle negatiivinen kun siivoja pamahtaa huoneeseen liian aikaisin.

Pieni asiakkaalle näkyvä muutos siis aiheuttaa taustatyötä paljon enemmän normaaliin tilanteeseen verrattuna – ja kokonaisuudessaan yhteen asiakkaaseen käytetty aika on suurempi. Myös ERP-järjestelmien asiakaskohtaiset räätälöinnit lisäävät projektiin kuluvia resursseja ja riskiä, että jotain voi mennä pieleen. Räätälöidyt ominaisuudet ovat perusteltuja tietyissä projekteissa ja järjestelmissä, mutta monessa tapauksessa asiakkaalla ei ole käsitystä, mitä seurauksia räätälöidyillä ominaisuuksilla saattaa olla.

Räätälöinnit venyttävät lähes poikkeuksetta projektien aikataulua

Räätälöityjen ominaisuuksien kehittämiseen kuluvaa aikaa on todella vaikea arvioida, joten ne venyttävät lähes poikkeuksetta toteutusprojekteja. Ja kun räätälöintivaiheeseen kuluu liikaa aikaa, usein se aika on jostain muusta pois – esimerkiksi testauksesta, joka on erittäin kriittinen vaihe koko projektin onnistumisen kannalta.

Räätälöinnit aiheuttavat jatkuvia kustannuksia

Asiakkaille räätälöity kehitystyö aiheuttaa ylimääräisiä kustannuksia ja viivästyksiä toteutusprojektissa, joskus siihen saakka, että projekti vaarantuu. Lisäksi räätälöity kehitys johtaa tekniseen velkaan, josta joudut maksamaan lähivuosina lisää ylläpito- ja päivityskustannuksia. Eli räätälöintien tekeminen, ylläpito ja päivittäminen maksavat jatkuvasti, ei riitä että räätälöinti on tehty kerran, vaan siitä voi aiheutua asiakkaan näkökulmasta odottamattomia “piilokustannuksia”. Odoon toimitusjohtaja Fabien Pinckaers arvio, että tällainen tekninen velka maksaa noin 25 % kehityskustannuksista joka vuosi (~ 17% ylläpidossa + ~ 8% päivityksissä).

Kuten todettu, usein asiakas näkee vain räätälöidyn ominaisuuden kertakustannuksen. Todellisuudessa tämän kustannuksen voi kertoa kahdella tai kolmella, koska on otettava huomioon useita tekijöitä: testausaika, virheet ja ylimääräiset viivästykset projektissa, dokumentaation mukauttaminen, koska se ei ole vakiomallin mukainen, tulevat huollot ja päivitykset seuraavien viiden seuraavan vuoden aikana… Räätälöintien kohdalla pitää siis aina pohtia onko kannattavaa käynnistää monimutkainen kehitys räätälöintiin, joka säästääksesi muutaman tunnin työtä kuukaudessa? Tämä ominaisuus nimittäin maksaa noin 10 päivää kehitystä sekä jatkuvat ylläpito- ja päivityskustannukset.

Räätälöinti voi olla tulevaisuudessa haitta

Räätälöinti vaikuttaa ERP-järjestelmän elinkaareen merkittävästi ja sitouttaa räätälöinnin tekijään. Kun ainoastaan yhdellä toimittajalla on tieto miten toteutettu räätälöinti toimii, usein ainoa vaihtoehto räätälöidyn ominaisuuden mennessä rikki on jatkaa saman järjestelmätoimittajan kanssa tai aloittaa uudestaan pitkä järjestelmäprojekti.

Ennen räätälöinnin toteuttamista testikäyttö perusjärjestelmällä

Ennen kuin lähdetään tekemään räätälöintiä, kannattaisi järjestelmää kokeilla 3 kuukauden ajan perusominaisuuksilla. Tällöin nähdään, onko toivotut räätälöinnit perusteltuja ja tuovatko ne aidosti hyötyä verrattuna “perusjärjestelmään”. Muutoksenhallinnan kannalta on parempi ottaa liiketoimintaprosessien muutokset käyttöön asteittain.

Asiakas on harvoin ostamansa järjestelmän asiantuntija

Saamalla haluamansa räätälöidyn ominaisuuden asiakkaat ovat lyhyellä aikavälillä tyytyväisiä, mutta pitkällä aikavälillä tyytyväisyys laskee kun projektissa tulee viivästyksiä ja kustannukset nousevat. Asiakas ei todennäköisesti ole vielä ostamansa järjestelmän asiantuntija, eikä myöskään ERP-toteutusprojektien. Järjestelmätoimittajan tulisi aina kyseenalaistaa asiakkaan tarpeet, jos niissä ei ole projektin kannalta järkeä ja kysyä joka räätälöinnin kohdalla seuraavat kysymykset:

• Onko se oikeasti välttämätön? 
• Onko se oikeasti kehitys- ja ylläpitokustannusten arvoinen?
• Onko siitä saatava hyöty riittävän merkittävä?
• Voiko samaan lopputulokseen päästä eri lähestymistavalla?