ERP-prosjekter har et dårlig rykte av en grunn: en stor andel går over tid, over budsjett, eller leverer mindre enn lovet. Det interessante er at årsakene sjelden er tekniske. Systemene fungerer som regel. Det som sprekker er forståelsen mellom forretning og system.
Her er de seks mønstrene jeg ser igjen og igjen.
1. As-is ble hoppet over
Den vanligste enkeltårsaken. Prosjektet starter på to-be (fremtidsbildet) uten et ærlig bilde av nåtilstanden. Da designes løsningen på antakelser, og avviket oppdages i UAT — sent og dyrt. Les mer om hvorfor as-is er det viktigste steget.
2. Scope creep
«Kan vi bare også få med …» Hver lille tilleggsønske virker rimelig isolert, men summen sprenger tidsplanen. Uten en tydelig scope forankret i et prosesskart, blir hver endring en forhandling uten referansepunkt.
3. Kompleksiteten bor i regneark og hoder
Mye av forretningslogikken kjøres faktisk utenfor det gamle ERP-et — i Excel-mellommodeller og hos enkeltpersoner. Når dette ikke er dokumentert, antar både kunde og integrator at «systemet gjør det». Det gjør det ikke, og hullet dukker opp i drift.
4. Uklart eierskap
Hvem bestemmer hvordan innkjøpsprosessen skal være i det nye systemet? Hvis svaret er uklart, blir beslutninger trege eller tas av integratoren. Uklart prosess- og dataeierskap er en garantert forsinkelse.
5. Datakvalitet undervurdert
Skitne master-data tar 1,5–2 ganger så lang tid å rydde som planlagt, og blir ofte skjøvet til slutten. Resultatet er enten utsatt go-live eller migrering av søppel. Se datavask før ERP-bytte.
6. Testing som hake-i-boks
UAT gjøres på «happy path» — de enkle tilfellene som alltid fungerer. Unntakene, som er der reelle prosesser feiler, testes ikke. Da går systemet «live» uten å være testet på det som faktisk er vanskelig. Se UAT-sjekkliste.
Det røde tråden
Fem av seks årsaker handler om prosessforståelse, ikke teknologi. Et ERP-prosjekt er i bunn og grunn en oversettelse: fra hvordan forretningen faktisk fungerer, til hvordan systemet konfigureres. Når oversettelsen baseres på antakelser i stedet for dokumentasjon, sprekker prosjektet.
Hvordan unngå mønstrene
- Gjør en uavhengig as-is-mapping av kjerneprosessene før design-fasen.
- Forankre scope i prosesskartet — bruk det som referanse når endringer foreslås.
- Dokumenter regneark og manuelle steg eksplisitt, ikke bare systemstegene.
- Avklar prosess- og dataeierskap før kontrakt med integrator.
- Start datavask tidlig, med en egen eier.
- Test unntakene i UAT, ikke bare happy path.
Felles for alle seks: de forutsetter at du faktisk vet hvordan prosessene dine fungerer i dag. Det er hele poenget med prosessdokumentasjon før et bytte. Se også ROI av ERP-migrasjon.
Oppsummering
ERP-prosjekter sprekker forutsigbart, og nesten alltid på prosess og forståelse — ikke teknologi. As-is hoppes over, kompleksiteten bor i regneark, eierskapet er uklart, dataene er skitne, og testingen treffer ikke unntakene. Alle seks lar seg forebygge med ett grep: et ærlig, dokumentert bilde av hvordan forretningen faktisk fungerer før konsulentene begynner å designe.