Et ERP-projekt er et omkostningskrævende projekt, der ofte er baseret på vandfaldsmodellen, som har vist sig anvendelig til dette formål. Ikke fordi den er perfekt – mange ERP-projekter fejler ved brug af modellen – men i højere grad, fordi den passer til nyudvikling og ERP-systemer, der kræver mange tilretninger. De mere agile projektmodeller er typisk bedre til mindre projekter eller projekter, hvor kompleksiteten er forholdsvis lav.
Metoden hvor mange fejler
Vandfaldsmodellen er en god forretning. Ikke nødvendigvis for dig, men for ERP-leverandørerne. De er med i hele forløbet og sidder tungt på de fleste faser. Projektet starter typisk med en foranalyse af din virksomhed og jeres systemer for at skabe et fundament for estimering af projektet. Herefter bliver planlægningsfasen iværksat baseret på foranalysen. Denne fase skal planlægge og strukturere design- og udviklingsfasen, så alt bliver udført i den rette rækkefølge.
Designfasen starter ofte med at opliste og dokumentere din virksomheds processer. På den baggrund bliver der udarbejdet en større kravspecifikation. Efter afstemning af kravspecifikationen genbesøges og genberegnes byggefasen, inden ERP-leverandøren kan gå i gang med at udvikle tilpasninger. Når alt er bygget, bliver det præsenteret for dig som kunde og herefter frigivet til en større systemtest. Desværre går der typisk lang tid fra design til test. Derudover kan der opstå mange fejl undervejs. Det ender derfor ofte med at blive en dyr løsning eller med et projekt, der fejler.
Vandfaldsmodellen lægger stor vægt på designfasen og dernæst udviklingsfasen. Det har ikke ændret sig, selvom de fleste ERP-systemer i dag er komplekse standardsystemer, der i stor udstrækning kan konfigureres til virksomhedens behov. Men når funktionaliteten er standard, hvorfor er det så nødvendigt, at ERP-konsulenten analyserer, dokumenterer og designer den?
Derfor skal du anvende en modelbaseret projektmetode
I stedet for vandfaldsmetoden anbefaler vi, at du anvender en modelbaseret projektmetode. En forudsætning er dog, at ERP-systemet er en komplet pakke, der kan standardkonfigureres i så høj en grad, at du uden problemer kan påbegynde en test. Et eksempel kan være Dynamics Business Central eller Dynamics F&O. Den modelbaserede metode forudsætter også, at foranalysen går et spadestik dybere, så den giver dig en indikation af, hvilke moduler og processer ERP-systemet skal dække.
Fordele ved den modelbaserede projektmetode
-
- Hurtigere og mere agilt projektforløb
- Modelejerskabet bliver i virksomheden
- Høj involvering af SME sikrer opbakning samt forankring
- Genkendelighed af system, processer og data gennem hele projektet
- Gennemtestede masterdata
Da de enkelte hovedprocesser bliver bærende gennem projektet, er det muligt at planlægge projektet ret detaljeret allerede i forbindelse med foranalysen.
Model og masterdata
Baseret på foranalysen sætter du en pilotmodel op. Piloten skal konfigureres til at anvende de moduler og den standardfunktionalitet, som foranalysen afdækker. Derudover skal det være din virksomheds egne masterdata, der benyttes, og ikke generiske testdata fra softwareleverandøren.
Derfor skal din virksomhed levere masterdata. Hermed begynder produktionsmodellen at forme sig og skabe fundamentet for succesfulde workshops.
Masterdata
I den modelbaserede projektmetode er det en forudsætning, at virksomheden klargør masterdata meget tidligt i projektet.
Dermed skal der vedligeholdes en ændringslog, så der eksisterer samhørighed mellem masterdata i driftssystemerne og masterdata i den nye ERP-model. Når der implementeres et nyt ERP-system, har virksomheden en enestående mulighed for at rydde op i masterdata.
Workshops og udvikling
Når pilotmodellen er sat op, påbegynder I workshops. Her gennemgår I funktionaliteterne, der primært vedrører virksomhedens hovedprocesser.
Subject Matter Expert (SME), som er den medarbejder, der er mest vidende om den hovedproces, som workshoppen vedrører, skal deltage.
Funktionaliteten og de væsentligste processer bliver gennemløbet i modellen, og der laves justeringer i konfigurationen ”on the fly”, så SME ser løsningerne og bliver overbevist om funktionaliteten. Dermed minimeres forekomsten af overraskelser senere i forløbet. Hvis funktionaliteten mangler, eller hvis I må ændre på processer, skal I dokumentere det på workshoppen.
Umiddelbart efter workshoppen udarbejder I kravspecifikation på funktionaliteten – alternativt change management til en ændret proces – så I får behandlet det enkelte udestående øjeblikkeligt. For at minimere projektperioden skal udviklingen ske agilt sideløbende med rækken af workshops. Dermed bliver udviklingen iterativ, og I kan rulle nyudviklinger på løbende, som I herefter sender til test hos jeres SME.
For at sikre, at SME er godt klædt på til at håndtere ERP-systemet og tager ansvar for udrulningen, skal han/hun inddrages tidligt i forløbet gennem relevante workshops og udvikling.
User acceptance test og training
Efter udviklingen skal I teste den samlede løsning. Det kan I gøre i forbindelse med slutbrugertesten kombineret med træning af slutbrugerne. Da den overordnede funktionalitet er afprøvet under workshops, bør der ikke opstå udfordringer inden for de enkelte funktioner.
Dog er der typisk behov for justeringer, når I kører end-2-end-processerne igennem med slutbrugerne. Men da SME har deltaget løbende i projektet, bør der ikke være udeståender, der kræver de store ændringer.
Sådan kommer du videre.
Hvis du vil vide mere om, hvordan den modelbaserede projektmetode kan sætte fart på dit ERP-projekt, er du velkommen til at kontakte os.
Få en uforpligtende samtale og sparring om dine udfordringer og muligheder med dit ERP-system.