ERP Go Live Tjekliste for en problemfri start

Go-Live er det øjeblik, hvor godt ERP-projektarbejde betaler sig - eller fejler på småting. Ikke på den store strategi, men på ting som åbne brugerrettigheder, halvfærdige stamdata, uklare godkendelser eller manglende kontaktpersoner på den første arbejdsdag. Derfor har I ikke brug for en teoretisk projektpræsentation, men en erp go live tjekliste, der fungerer i hverdagen.

Især i små og mellemstore virksomheder er der ofte lidt spillerum omkring starten. Teamet arbejder videre parallelt, kunderne venter ikke, leverandørerne heller ikke, og regnskabsafdelingen har brug for pålidelige tal. Hvis ERP-starten vakler her, mærker I det straks i ordrer, beholdninger, fakturaer og rapportering. En god tjekliste er derfor ikke en ekstra, men en sikring mod unødvendig friktion.

Hvad en god ERP Go Live Tjekliste skal kunne

Mange tjeklister er for generelle. Der står så noget som “Kontroller data” eller “Træn brugere”. Det lyder rigtigt, men hjælper ikke meget i alvorlige tilfælde. En brugbar ERP Go Live Tjekliste skal være mere konkret. Den skal fastlægge, hvad der præcist kontrolleres, hvem der godkender det, hvornår det skal være afsluttet, og hvad der sker, hvis et punkt forbliver åbent.

Forskellen er afgørende. Hvis I før Go-Live opdager, at artikelstamdata er ufuldstændige, er det stadig løseligt. Hvis den samme fejl først opdages ved den første levering, bliver det hektisk. Det samme gælder for prislister, skatte-logikker, bankforbindelser, e-mail-skabeloner, udskriftslayouts eller rolle-rettigheder. Starten fejler sjældent på et enkelt stort problem. Det er ofte flere små huller, der tilsammen bliver kritiske.

Før Go-Live: De faglige grundlag skal være på plads

Før I taler om selve skiftedagen, skal der være faglig ro i systemet. Det betyder ikke, at enhver tænkelig optimering allerede er implementeret. Det betyder bare, at kerneprocesserne for jeres hverdag fungerer pålideligt.

Dette omfatter normalt salg, indkøb, lager, finansprocesser og rapportering. Hvis I producerer, kommer styklister, arbejdsprocesser og tilbagemeldinger til. Hvis I arbejder med service, skal også billetter, kontrakter eller serviceforløb være testet. Det afgørende er ikke, om hundrede særtilfælde allerede er modelleret. Det afgørende er, om 80 procent af jeres daglige forretning kører uden workaround.

En almindelig fejl er at knytte Go-Live til for mange nice-to-haves. Det forsinker projekter og skaber usikkerhed. Lige så risikabelt er det modsatte ekstrem: at gå live for tidligt, selvom kerneprocesser kun så godt ud i workshops, men aldrig blev realistisk gennemspillet. Her gælder som så ofte: Det kommer an på. Hvis en randproces stadig mangler, kan man følge op på den. Hvis vareudgang, fakturering eller betalingsafstemning ikke er stabile, er det ikke længere et randemne.

Stamdata: Ikke et glamourøst punkt, men ofte det vigtigste

Stamdataarbejde er sjældent noget, nogen gør med glæde. Alligevel afgør det massivt, om starten forløber roligt. Kunder, leverandører, artikler, priser, enheder, skatteangivelser, konto-tilordninger og lagerparametre skal ikke kun være til stede, men også konsistente.

Det bliver særligt kritisk med voksede Excel-strukturer. Så eksisterer der ofte dobbelte kundekonti, gamle artikelnumre, uens betalingsbetingelser eller fritekstfelter, der i årevis har erstattet individuel logik. Hvis I blot overtager disse uklarheder i det nye ERP, følger det gamle kaos med.

Derfor bør jeres ERP Go Live Tjekliste ikke slutte med “Import afsluttet” ved dataene. Vigtigere er spørgsmål som: Er de førende datakilder klare? Er dubletter ryddet op? Er aktive og inaktive datasæt adskilt? Stemmer priser, skatte-koder og bogføringslogikker? Er der en endelig godkendelse fra fagområdet? Uden denne klarhed bliver Go-Live unødvendigt dyr, fordi fejl derefter lander direkte i driften.

Tests: Ikke teste mere, men teste rigtigt

Kort før starten kommer mange teams i aktionisme. Så testes alt igen, ofte hektisk og uden ordentlig dokumentation. Det beroliger kortvarigt, men erstatter ikke en pålidelig godkendelse.

Bedre er en klar testtilgang med reelle forretningstransaktioner. En ordre bør ikke kun oprettes. Den bør gennemspilles til levering, faktura og betaling. En indkøbsproces bør dække bestilling, varemodtagelse, fakturakontrol og betaling. På finansområdet handler det ikke kun om bogføringer, men også om evalueringer, periodelogik og afstemning.

Det er også vigtigt at tænke på undtagelser. Hvad sker der ved returneringer, prisafvigelser, delleverancer eller blokerede kreditorer? I behøver ikke sikre hver eksotisk særtilfælde fuldstændigt før starten. Men de mest almindelige afvigelser hører til i testen. Ellers virker systemet stabilt i workshoppen og vælter i hverdagen.

Brugere, rettigheder og træning

Et ERP-system kan være teknisk godt forberedt og alligevel blive ubrugeligt på den første dag, fordi brugerne ikke kan arbejde. Rettigheder er for stramme, godkendelser mangler, printere er ikke tildelt, eller teamet kender kun de nye processer overfladisk.

Derfor er træning ikke en pligttermin kort før slutningen, men en del af Go-Live-forberedelsen. Det afgørende er, at hver rolle ved, hvad de konkret skal gøre på den første dag. Salg har brug for sikkerhed ved tilbud, ordre og faktura. Lageret skal vide, hvordan bogføringer, pluklister og beholdningskontroller kører. Regnskabsafdelingen skal mestre bilag, konti, betalingskørsler og evalueringer.

Med rettigheder gælder: hellere målrettet og kontrolleret end generelt åbent. For brede rettigheder skaber senere kontrolproblemer, for snævre rettigheder lammer processer. Den bedste vej er en rollemodel med reelle praktiske tests. Hvis en bruger ikke kan udføre sin opgave fuldstændigt, er det løseligt før Go-Live. Derefter koster det tid, nerver og ofte tillid til systemet.

Cutover-planen: Hvem gør hvad, hvornår og i hvilken rækkefølge?

Selve skiftet kræver en klar procedure. Det er her, ren projektstyring adskiller sig fra håb. En cutover-plan definerer, hvilke opgaver der skal udføres i de sidste dage før starten, hvem der er ansvarlig, og hvilke afhængigheder der eksisterer.

Dette omfatter typisk den sidste dataeksport fra ældre systemer, endelige dataimporter, kontrol af åbne bilag, systemgodkendelser, brugeraktivering, udskrifts- og e-mail-kontroller samt beslutningen om, fra hvilket tidspunkt der kun arbejdes i det nye system. Uden denne klare timing opstår der parallelverdener. Så registreres ordrer stadig i det gamle værktøj, fakturaer skrives delvist i det nye system, og Excel lever pludselig videre.

Især i mindre virksomheder undervurderes dette punkt ofte, fordi alle “alligevel ved, hvad der skal gøres”. I praksis er det netop det, der er risikabelt. Hvad der virker klart i hovedet, er ofte ikke længere entydigt under tidspres. En skriftlig, afstemt procedure sparer her flere problemer, end den skaber besvær.

Support på den første dag: Ikke kun tilgængelig, men handlingsdygtig

Mange Go-Lives fejler ikke ved selve starten, men i de første 48 timer derefter. Teamet arbejder reelt, spørgsmål dukker op i minutintervaller, og pludselig er ingen klart ansvarlig. Derfor bør jeres tjekliste også dække hypercare-fasen.

I har brug for faste kontaktpersoner, klare reaktionstider og en enkel regel for, hvordan billetter prioriteres. En blokeret vareudgang er ikke det samme som en kosmetisk layoutjustering. Hvis alt virker lige vigtigt, kommer det forkerte til sidst.

Pragmatiske ERP-partnere planlægger denne fase bevidst tæt ledsaget. Ikke med koncernritualer, men med hurtig tilgængelighed og klart ansvar. Især med SAP Business One viser det sig her, hvor værdifuld en partner er, der ikke overengineerer, men straks placerer og løser operationelle problemer. RConsult arbejder netop i denne stil - direkte, planlagt og uden overraskelser.

Den egentlige tjekliste: Hvad I bør basere starten på

Når I frigiver Go-Live, bør mindst disse punkter være pålideligt afklaret: Kerneprocesser er fagligt godkendt, stamdata endeligt kontrolleret, brugere og rettigheder testet, åbne gamle bilag vurderet, grænseflader kontrolleret, udskrifts- og e-mail-udgange godkendt, finanslogikker kontrolleret, og support for de første dage er bindende organiseret.

Dertil kommer et punkt, der ofte glemmes: Hvem må stoppe starten? Der er brug for en klar beslutningsinstans. Hvis der opstår kritiske fejl aftenen før, må det ikke blive til en endeløs diskussion. Enten er risikoen acceptabel, eller starten udsættes. Begge dele kan være rigtigt. Forkert er kun at gå ind i mandagen med uklar ansvarlighed.

Hvad I bevidst ikke behøver at gøre perfekt

En Go-Live er ikke en skønhedskonkurrence. Ikke hvert dashboard, ikke hver evaluering og ikke hver særproces skal være på slutudvikling ved starten. Den, der venter på, at alt virkelig er færdigt, udsætter ofte i måneder og holder unødvendigt fast i gamle workarounds.

Vigtigere er, at jeres system bærer den daglige forretning rent, og at det er klart, hvilke punkter der kommer i fase to efter Go-Live. Denne adskillelse skaber fokus. Den forhindrer, at projektet kort før slutningen overbelastes med ekstra ønsker. En ren start slår næsten altid et forsinket perfektionistisk krav.

Hvis I vil sikre jeres ERP-implementering seriøst, så behandl Go-Live ikke som en kalenderdato, men som en driftsoptagelse. Netop med dette synspunkt bliver en ERP Go Live Tjekliste ikke et papir til projektmappen, men et værktøj, der lader jer arbejde roligt på den første dag.