For dyrt, for sent og for lidt: To ud af tre ERP-projekter skuffer fælt

Blot 35 procent af ERP-projekter holder tidsplan, budget og giver de ønskede forbedringer, viser dansk undersøgelse. Man skal ikke holde til i campingvognen, mens leverandøren er på førersædet, siger ERP-konsulent.

Hvis en virksomhed beslutter sig for at skifte eller opgradere ERP-systemet, er der god chance for, at det ikke bliver nogen succes.

Implementeringsprojekterne går nemlig oftest over budget og over tidsrammen - og leverer sjældent den gevinst, som firmaet ønskede, viser en undersøgelse blandt danske ERP-projekter, som konsulenthuset Herbert Nathan og Co har lavet.

Læs også: Bimodal ERP: Kombination af Best of Breed og Best of Suite – hvilken ERP-strategi passer bedst til dig?

Ifølge undersøgelsen falder 65 procent af projekterne slår fejl - og i 46 procent af tilfældene opnår virksomheden mindre end halvdelen af den gevinst, man satsede på.

»Det er typisk manglende ledelsesfokus, ringe change management, dårlig scope-kontrol, manglende træning og alt for mange ændringer. Det er det, vi høre igen og igen som årsager til, at man fejler,« fortæller Herbert Nathan-konsulent Klaus Stange ved ERP-konferencen Forretningssystemer 2016, som blev afholdt i København i går.

Fra græsslåmaskine til mejetærsker

Dårlig skope-styring alene får æren for en fjerdedel af de ERP-projekter, der bryder budgettet.

»Forretningen starter med at bede om en græsslåmaskine, men ender med at bede om en mejetærsker,« forklarer Klaus Stange.

En ting er, at projektet ikke kan holde sig inden for budget- og tidsramme, når scopet går af fløjten. Et andet problem er, at når projektet bliver større, stiger risikoen for fiasko.

»Der er lavet talrige undersøgelser, som viser snorlige sammenhæng mellem projektets størrelse, og hvor meget det ender med at afvige fra budgettet. Jo større projekt, jo større problem bliver det at nå i mål,« siger Klaus Stange.

Læs også: It-konsulent: Problemer med ERP-systemer bliver fejldiagnosticeret

I konsulenthuset ser man ofte, at virksomheder starter ud med en ambition om at holde sig til standardløsninger. Men når det kommer til stykket ender løsningen alligevel med at skulle tilpasses i stor stil.

"Et andet er, at mange leverandører tilbyder rabat på licenser, hvis de købes oveni, siger Klaus Stange og fortsætter:

»Det kan gøre alle projekter mere komplekse, hvis der lige bliver smidt et business warehouse oven i.«

Nogen skal læse instrumentbrættet

I det hele taget skal virksomhederne være varsomme med at overlade tøjlerne til leverandøren fremfor selv at definere scopet og styre projektet. Når alternativet er at bruge de interne ressourcer, så er det fristende at lade leverandørens konsulenter tage slæbet i implementeringen - men det er en fejl, mener Klaus Stange.

»Hav som minimum en intern løsningsarkitekt med erfaring inden for løsningen. Ellers kan man komme på bagsædet af sit eget projekt,« siger han og fortsætter:

»Man skal have nogen, der kan læse instrumentbrættet, og ikke folk der sidder omme i campingvognen. Vi ser ofte, at virksomheder kan blive så forhippet på, at det ikke skal gå ud over forretningen, at de lader leverandøren tage hele styringen.«

Læs også: It-konsulent: Accepter aldrig at blive lænket til et milliondyrt ERP-projekt

Ifølge Herbert Nathan-konsulenten bør forholdet mellem leverandøransatte og interne i projektet være som minimum 1 til 2.

A-holdet sælger - og forsvinder

Når en virksomhed står over for den store beslutning at købe nyt ERP-system, er det typisk et hold af ekstremt dygtige sælgere og de bedste løsningsarkitekter, der sælger leverandøren. Men sådan bliver det ikke nødvendigvis ved med at være, advarer Klaus Stange

»Når projektet er i gang, kommer b-holdet ind - mens a-holdet rykker videre for at sælge et nyt projekt.«

For at undgå, at hele holdet erstattes med reservebænken skal virksomheder få skrevet ind i kontrakten, at leverandøren skal holde det samme hold medarbejdere på projektet i dets levetid, påpeger konsulenten.

En god kontrakt er bare en del af det forarbejde, som skal sikre, at ERP-projektet ikke bliver en hovedpine, understreger Klaus Strange, der har set mange projekter starte uden et ordentligt forarbejde og uden en egentlig strategi.

Læs også: ERP-cheferne troede at eget serverrum var lykken - men så kom cloud-ERP forbi

»Nogle gange spørger man til strategien, og så kommer der en ni år gammelt dokument op af skuffen, og personen bag den har forlængst forladt virksomheden,« beretter konsulenten.

Skuffe-taktikken bliver også brugt til risikoanalysen, bemærker Klaus Stange.

»Alle ERP-projekter har en indbygget risici. Ofte laver virksomheder en risikoanalyse, lægger den i skuffen og går i gang. Og det er ikke måden at gøre det på.«

Live med ufærdigt system

En af de mere fatale fejl, virksomheder laver i kuldsejlede ERP-projekter er at følge tidplanen uanset hvad - og gå live med et ufærdigt eller utestet system.

»Det at gå live til tiden kan være langt dyrere end at udskyde,« understreger Klaus Stange.

Læs også: Kontraktkrig: Hver fjerde virksomhed rager uklar med leverandøren

Hvis der fx er problemer med datakvalitet eller der mangler test, tænker projektlederen måske, at det kan forbedres undervejs. Men det kan være sindsygt farligt med et kritisk it-system, fastslår konsulenten.

»Pludselig kan det true virksomheden på livet - i stedet for at man bare udskyder.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Kirk

Det er oftest billigst at tilpasse sin forretning til et standard system, end det er at hyre en flok konsulenter til at tilpasse systemet til forretningen.

og det er her mange går galt i byen.

Hvis man fx tager Microsoft Dynamics Ax - så har den næsten med sikkerhed samtlige funktioner man har brug for i en større virksomhed af en hvilken som helst art, der er ikke brug for at genopfinde den dybe tallerken, eller brug for at viderfører custom kode fra ældre versioner.

Det er også nemmere at opgradere hvis man har fulgt standarden fra starten, da alt custom kode ikke skal gen-opfindes/skrives.

Log ind eller Opret konto for at kommentere