Miksi ERP-hanke epäonnistuu: tyypilliset syyt ja miten ne estetään

ERP-hanke epäonnistuu harvoin siksi, että ohjelmisto olisi kokonaan väärä. Tavallisimmat syyt ovat epäselvä tai kasvava laajuus, aliarvioitu tiedonsiirto, liian vähän omaa aikaa, heikko testaus ja sopimusehdot, joiden merkitys huomataan liian myöhään. Epäonnistuminen tarkoittaa pk-yrityksessä yleensä sitä, että aikataulu venyy kuukausilla, budjetti ylittyy tai järjestelmä otetaan käyttöön, mutta odotettu hyöty jää saamatta, koska vanhat käsityövaiheet jäävät rinnalle. Julkisuudessa olevat prosenttiluvut epäonnistuneiden hankkeiden osuudesta vaihtelevat paljon määritelmän ja otoksen mukaan, joten niihin ei kannata nojata. Hyödyllisempää on tuntea toistuvat mallit. Tämä on osion pilariopas, joka linkittää osion kaikkiin oppaisiin.

Seitsemän toistuvaa mallia

Malli	Miltä se näyttää	Ennaltaehkäisy
Laajuus kasvaa	Uusia raportteja ja toimintoja lisätään viikoittain	Muutospyyntömenettely ja vaiheistus
Data on huonompaa kuin luultiin	Koesiirrossa tuhansia virheitä	Datan puhdistus ennen projektia
Avainhenkilöillä ei ole aikaa	Palaverit siirtyvät, päätökset viipyvät	Kirjallinen resurssivaraus
Prosessia ei muuteta	Vanha tapa rakennetaan uuteen järjestelmään räätälöiden	Vakioprosessit ensin
Testaus on ohut	Virheet löytyvät vasta tuotannossa	Hyväksymistestaus omilla tapauksilla
Koulutus jää kesken	Käyttäjät palaavat Exceliin	Pääkäyttäjät ja jatkokoulutus
Sopimus ei suojaa	Korotukset, lukittuminen ja kalliit muutokset	Sopimusehtojen tarkistus ennen allekirjoitusta

1. Laajuus kasvaa

Kun ERP:n mahdollisuudet avautuvat, jokainen osasto keksii uusia toiveita. Jokainen lisäys näyttää pieneltä, mutta ne kasautuvat. Sovi muutospyyntömenettely: jokainen lisäys kirjataan, hinnoitellaan ja hyväksytään erikseen, ja vähemmän tärkeät siirretään vaiheeseen kaksi.

2. Data on huonompaa kuin luultiin

Asiakasrekisterin kaksoiskappaleet, puuttuvat Y-tunnukset, vanhentuneet nimikkeet ja täsmäämättömät avoimet erät tulevat esiin vasta koesiirrossa. Datan puhdistus on usein yrityksen omaa työtä. Katso tiedonsiirron sudenkuopat.

3. Avainhenkilöillä ei ole aikaa

Talouspäällikkö, varastovastaava ja myyntijohtaja tekevät hanketta päivätyön ohessa. Kun kiire kasvaa, hanke jää. Varaa aika kirjallisesti ja harkitse sijaisjärjestelyjä.

4. Vanha prosessi rakennetaan uuteen järjestelmään

Räätälöinti nostaa käyttöönoton hintaa ja tekee tulevista päivityksistä kalliimpia. Kysy jokaisen räätälöintitoiveen kohdalla, voisiko prosessia muuttaa vastaamaan järjestelmän vakiotoimintoa.

5. Testaus on ohut

Toimittajan testit osoittavat, että järjestelmä toimii. Hyväksymistestaus osoittaa, että se toimii sinun prosesseillasi. Tee testitapaukset todellisista tilanteista: hyvityslasku, osatoimitus, palautus, palkkakorjaus.

6. Koulutus jää kesken

Jos käyttäjät eivät osaa järjestelmää, he palaavat vanhoihin taulukoihin, ja hyöty katoaa. Kouluta pääkäyttäjät ensin ja varaa jatkokoulutus muutaman kuukauden päähän.

7. Sopimus ei suojaa

Moni ongelma nousee esiin vasta uusimisessa tai vaihtaessa: suuri korotus, automaattinen jatko tai tietojen vaikea vienti. Katso ERP-sopimuksen ehdot, hinnankorotus sopimuskauden vaihtuessa ja tietojen vienti ja toimittajan vaihto.

Varoitusmerkit kesken hankkeen

Määrittelyvaihe on venynyt yli puolella suunnitellusta.
Toimittajan tuntiraportit ylittävät arvion, eikä syytä ole kirjattu.
Koesiirtoa ei ole tehty kuukausi ennen suunniteltua tuotantoonsiirtoa.
Hyväksymistestauksen testitapauksia ei ole kirjoitettu.
Projektin ohjausryhmä ei ole kokoontunut kuukauteen.
Käyttäjät eivät ole nähneet järjestelmää ennen koulutusta.

Kun kaksi tai useampi merkki täyttyy, pysähdy ja arvioi aikataulu ja budjetti uudelleen. Siirtäminen kuukaudella on lähes aina halvempaa kuin keskeneräisen järjestelmän ottaminen tuotantoon.

Esimerkki budjetin ylittymisestä (havainnollinen)

Alkuperäinen budjetti: käyttöönotto 40 000 €. Laajuuden kasvu lisää 60 tuntia, datan korjaus 50 tuntia ja ylimääräinen testauskierros 30 tuntia. Yhteensä 140 tuntia × 120 € = 16 800 €. Toteutunut käyttöönotto: 56 800 €, eli 42 % yli budjetin. Lisäksi kolmen kuukauden viive siirtää säästöjen alkua. Aikataulun vaikutus on laskettu oppaassa käyttöönoton kesto ja aikataulu.

Jos budjettiin oli varattu 20 %:n riskivaraus (8 000 €), ylitys olisi silti 8 800 €. Siksi pelkkä varaus ei riitä, vaan laajuutta on hallittava.

Kevyt ohjausmalli pk-yritykselle

Suuryritysten projektimallit ovat pk-yritykselle usein raskaita, mutta jokin ohjaus tarvitaan aina. Toimiva minimimalli:

Rooli	Kuka	Tehtävä
Hankkeen omistaja	Toimitusjohtaja tai talousjohtaja	Päättää laajuudesta, budjetista ja tuotantoonsiirrosta
Projektivastaava	Nimetty avainhenkilö	Aikataulu, päätösten valmistelu, yhteys toimittajaan
Pääkäyttäjät	Yksi per prosessi	Määrittely, testaus, koulutus
Toimittajan projektipäällikkö	Toimittaja	Toimittajan työn suunnittelu ja raportointi

Ohjausryhmä (omistaja, projektivastaava ja toimittajan edustaja) kokoontuu kerran kuukaudessa ja käy läpi kolme asiaa: aikataulu suhteessa välitavoitteisiin, kustannukset suhteessa budjettiin ja avoimet riskit. Päätökset kirjataan lyhyesti muistioon. Tämä vie vähän aikaa, mutta estää tilanteen, jossa ongelmat huomataan vasta laskusta.

Sovi myös eskalaatiopolku: jos projektivastaava ja toimittajan projektipäällikkö eivät pääse sopuun, asia nousee ohjausryhmään viikon sisällä. Pitkäksi venyvät erimielisyydet laajuudesta ovat yksi yleisimmistä syistä aikataulun venymiseen.

Osion muut oppaat

Hyvä nyrkkisääntö on, että jokainen tunnistettu riski kirjataan, sille nimetään vastuuhenkilö ja se käydään läpi ohjausryhmässä, kunnes se on suljettu. Lyhyt riskilista on pk-yrityksessä tehokkaampi kuin raskas riskienhallintamalli, jota kukaan ei päivitä.

Usein kysytyt kysymykset

Voiko epäonnistuneen hankkeen keskeyttää?

Sopimuksesta riippuu, voiko käyttöönoton keskeyttää ja mitä tehdystä työstä maksetaan. Tarkista keskeytys- ja irtisanomisehdot ennen allekirjoitusta, ja pyydä tarvittaessa juristin arvio.

Kuka on vastuussa, jos toimittaja ei toimita sovittua?

Vastuu määräytyy sopimuksen ja sopimusoikeuden yleisten periaatteiden mukaan. Vastuunrajoitusehdot rajoittavat usein korvauksia, joten virheistä kannattaa reklamoida kirjallisesti ja viipymättä.

Auttaako ulkopuolinen projektipäällikkö?

Usein auttaa, jos yrityksellä ei ole kokemusta ERP-hankkeista. Kustannus kannattaa laskea mukaan TCO:hon ja verrata riskiin.

Miten tunnistan, että hanke on epäonnistumassa jo valintavaiheessa?

Varoitusmerkkejä ovat esimerkiksi se, ettei kukaan johdossa omista hanketta, laajuutta ei ole kirjattu, budjetti perustuu vain lisenssihintaan tai toimittaja valitaan pelkän demon perusteella. Nämä on helpompi korjata ennen sopimusta kuin sen jälkeen.

Lähteet ja lisätiedot

Finlex — laki varallisuusoikeudellisista oikeustoimista (228/1929) ja laki elinkeinonharjoittajien välisten sopimusehtojen sääntelystä (1062/1993)
Suomen Yrittäjät — sopimusneuvonta jäsenille
Kyberturvallisuuskeskus — tietoturva käyttöönoton aikana