Sådan laver du en ERP-omlægningsplan

Kort fortalt

• Prøvekør omlægningen mindst én gang med produktionslignende data, og mål tiden.
• Frys det gamle system før det endelige udtræk, og angiv, hvad der er frosset.
• Indlæs stamdata før åbne transaktioner, og afstem derefter begge dele.
• Aftal go/no-go-kriterier og tilbagerulningsplanen på forhånd.
• Afslut hypercare på exitkriterier og ikke på en dato.

Planlæg portene og ikke kun opgaverne

En omlægningsplan begynder som regel som en opgaveliste, og den detaljerede liste har betydning: flere hundrede opgaver med ejere, varigheder og afhængigheder. Men et go-live fejler sjældent, fordi en opgave manglede. Det fejler, fordi en port var uklar: ingen var enige om, hvad afstemt betød, go/no-go-kriterierne blev fastlagt om natten, eller tilbagerulningsplanen kun fandtes som en sætning på et slide.

Planlæg derfor portene først. Tegn omlægningen som et procesflow med beslutningspunkterne i: mål for prøvekørslen nået, afstemning godkendt, go eller no-go, hypercare-exit. Aftal kriterierne for hver med styregruppen uger før go-live. Byg derefter den detaljerede opgaveliste under hver fase.

Eksemplet nedenfor er en generel ERP-omlægning, der virker til SAP S/4HANA, Oracle Fusion, Dynamics 365 eller NetSuite. Det viser portene og de veje, der kører, når en port fejler.

ERP-omlægning med sine porte

Fra en driftsbog på baseline til overdragelse. Hold øje med de fire beslutninger: prøvekørsel, afstemning, go/no-go og hypercare-exit.

1. Prøvekør, til det passer ind i vinduet

   Prøveomlægningen kører den rigtige driftsbog mod en kopi af produktionen og tidsmåles. Hvis den ikke når målene for tid eller fejl, rettes driftsbogen, og prøvekørslen køres igen. To eller tre prøvekørsler er normalt ved et stort go-live.

2. Frys, træk ud og indlæs

   Forretningstransaktioner og ændringer af stamdata standser i det gamle system, de endelige saldi og åbne poster trækkes ud, stamdata indlæses før transaktionerne, og det tekniske team omlægger interfaces, batchjob og autorisationer.

3. Afstem og skriv under

   Forretningen og ikke datateamet afstemmer antal poster og saldi mod det gamle system og skriver under. Differencer går tilbage til datateamet til rettelse og genindlæsning. Den underskrift er den vigtigste port i planen.

4. Go eller no-go

   Styregruppen beslutter ud fra kriterier, der er aftalt på forhånd. No-go udløser tilbagerulningsplanen og en ny dato, hvilket er et planlagt udfald og ikke en fejl i projektet.

5. Åbn systemet og kør hypercare

   Brugerne begynder at arbejde, supportteamet sorterer sager dagligt, og hypercare slutter, når exitkriterierne er opfyldt, som regel inklusive den første månedsafslutning i det nye system.

Sådan fungerer det

1. Tegn portene først

   Start med et procesflow over omlægningens faser og beslutningerne imellem dem: mål for prøvekørslen, godkendelse af afstemning, go/no-go og hypercare-exit. Aftal det med styregruppen, før I skriver opgaver.

2. Skriv den detaljerede driftsbog

   List under hver fase hver opgave med ejer, forudgående opgave, planlagt start, varighed og den person, der bekræfter, at den er færdig. Tag forretningsopgaver med, for eksempel lagertælling og sidste fakturering, og ikke kun tekniske.

3. Definér, hvad der fryses, og hvornår

   Skriv ned, hvilke transaktioner og hvilke stamdata der standser i det gamle system, fra hvilket tidspunkt, og hvad forretningen gør i mellemtiden, for eksempel manuelle ordrer eller forsendelse på papir.

4. Planlæg dataindlæsning og afstemning

   Fastlæg rækkefølgen i indlæsningen (stamdata, derefter åbne poster og saldi), definér afstemningsrapporterne for hvert objekt, og angiv den forretningsejer, der skriver under på hver af dem.

5. Aftal go/no-go-kriterier og tilbagerulningsplan

   Skriv målbare kriterier og det seneste tidspunkt, hvor tilbagerulning stadig er mulig. Øv tilbagerulningstrinnene lige så vel som omlægningen.

6. Prøvekør og forfin

   Kør mindst én fuld prøveomlægning med produktionslignende data, tidsmål hver opgave, og opdatér planen. Gentag, til omlægningen passer ind i vinduet med margin.

Faldgruber du skal undgå

• Kriterier fastlagt om natten

  Hvis go/no-go-kriterierne ikke er aftalt på forhånd, bliver beslutningen en forhandling under pres. Aftal dem uger før.

• En plan, der kun er teknisk

  Omlægningsplaner skrevet af IT overser forretningsopgaver som sidste lagertælling, åbne indkøbsordrer og kundekommunikation. Hvert forretningsområde har brug for sine egne opgaver i driftsbogen.

• Ingen prøvekørsel

  En omlægning, der aldrig er tidsmålt, passer ikke ind i vinduet. Den første prøvekørsel løber næsten altid over.

• Tilbagerulning som en eftertanke

  En tilbagerulningsplan, der aldrig er afprøvet, er ikke en plan. Kend det punkt, hvorefter der ikke er vej tilbage, og øv trinnene før det.

Åbn ERP-omlægningsflowet

Åbn omlægningsflowet som dit eget diagram, skriv dine go/no-go-kriterier på beslutningen, og send det til styregruppen til godkendelse.

Åbn ERP-omlægningsflowet

Relaterede guides

• ERP fit-gap-analyse: sådan kører du en med procesflow
• Dynamics 365 business process catalog: fra katalog til procesflow
• Sådan dokumenterer du en forretningsproces

Ofte stillede spørgsmål

Hvad indeholder en ERP-omlægningsplan?

Den tidsfastsatte liste over opgaver til flytningen fra det gamle system til det nye ERP, med ejere og afhængigheder, frys af det gamle system, dataudtræk, indlæsning og afstemning, teknisk omlægning af interfaces og job, forretningsopgaver som lagertælling, go/no-go-kriterier, tilbagerulningsplanen, kommunikation og hypercare-ordninger.

Hvor lang tid tager en ERP-omlægning?

Selve omlægningsvinduet er som regel fra en weekend til en uge, afhængigt af datamængder og hvor mange lokationer der går live samtidig. At planlægge og prøvekøre den tager flere måneder og begynder allerede i opbygningsfasen.

Hvad er typiske go/no-go-kriterier?

Dataafstemning godkendt af forretningen, ingen åbne fejl af alvorlighed 1, en aftalt liste over kendte problemer af lavere alvorlighed, uddannede brugere, bemandet support og hypercare, interfaces testet fra ende til anden og bekræftelse af, at tilbagerulning stadig er mulig.

Hvad er hypercare efter go-live?

En periode med intensiv support lige efter go-live, som regel fire til otte uger, med daglig sortering af sager, projektteamet ved hånden og hurtige rettelser. Den slutter, når de aftalte exitkriterier er opfyldt, og supporten overgår til det almindelige driftsteam.