I forbindelse med implementering af et nyt ERP-system eller udvidelse af eksisterende ERP-system til nyt forretningsområde følger der med garanti én eller anden grad af datamigrering med. Der skal skabes en række data, hvoraf mange kan tage udgangspunkt i eksisterende systemer, regneark osv., og det sker sjældent uden udfordringer, for i takt med at ERP-systemerne udvider deres funktionalitet, udvides kravene til data også. Således er strukturen og kravene til data sjældent de samme fra ét ERP-system til et andet, og derfor kræver det et solidt stykke arbejde at få lagt en strategi, mappet og overført dataene, så de er retvisende og værdiskabende.
Læs med her, hvor vi har talt med nogle af vores erfarne datamigreringskonsulenter, der giver råd og vejledning om, hvordan man kommer godt i mål med en succesfuld datamigrering.
Processen for en god datamigrering ved nyimplementering af IFS
Rollefordeling
Én af de første ting, man skal tage stilling til, er, om man som forretning ønsker selv at migrere, eller dette skal gøres eksternt. Der er ikke ét rigtigt svar, da dette kommer an på de ressourcer og kompetencer, man har in-house. En konstellation, vi hos Curit ofte oplever, er en hybrid, hvor kunden sørger for udtræk fra eksisterende systemer, og Curit sørger for at migrere disse udtræk ind i IFS.
Når dén beslutning er taget, skal der tilrettelægges en proces for, hvordan migreringen skal være. Planen for dette introduceres for konsulenter og deltagere på projektet, så der ikke er nogen tvivl om, hvad der forventes af dem.
Mapningen af data fra gammelt til nyt system er ofte den største del af arbejdet, og her er en tæt dialog mellem konsulent og forretning vigtig, så man ved, hvordan forretningsprocesserne skal være i det nye system, da disse kan have betydning for datakravene og vice versa.
Typer af data og mapning
Næste skridt er, at grupperne skal identificere, hvilke data der skal oprettes. Her sondrer vi mellem grunddata, stamdata og transaktionsdata:
- Grunddata er blandt andet opsætninger og værdilister, som bruges i efterfølgende stamdata. F.eks. varegrupper eller momskoder.
- Stamdata er data, som typisk kommer fra et eksisterende system, og hvor der er så mange records, at det ikke kan betale sig at taste det manuelt. F.eks. kunder, leverandører og varer. Involverede skærmbilleder, faner og felter være mange, og rækkefølgen, de skal indlæses i, kan have betydning. Ofte vil dette kræve, at man prøver at lave en manuel oprettelse, for at se om det kan lade sig gøre, eller om der mangler grunddata. Når det lykkes manuelt, er lakmusprøven bestået, og datasættet er klar til automatisk indlæsning.
- Transaktionsdata er levende data, som ofte er meget tidsfølsomme. Man kan yderligere splitte dem op i Historiske data og Åbne poster:
- Historiske data: Dette kan f.eks. være gamle lukkede indkøbsordrer osv. Denne type afsluttede poster vil man ikke medtage i nyt system.
- Åbne poster: I forbindelse med et skift til et nyt ERP-system, vil denne form for data normalt være det sidste man migrerer lige inden ibrugtagning af det nye system. Eksempel på åbne poster er lagerbeholdninger.
Næste skridt, efter identifikation af hvilke data, der skal migreres på hvilken måde og i hvilken rækkefølge, vil være, at migreringskonsulenten opretter skabeloner for de data, som er blevet identificeret og overleverer disse til konsulenterne for de forskellige grupper. Nu kan selve mapningen gå i gang, hvor konsulent og forretning i fællesskab får mappet eksisterende data til datafelterne i det nye system. Det er her, det hårde benarbejde skal laves, men det er også dét, der er fundamentet for, at resten af processen bliver korrekt, og for at man kan holde iterationerne af datamigrering på et minimum.
Undervejs i mapningen vil man støde på felter, som ikke umiddelbart kan overføres direkte til det nye system, men skal gennemgå yderligere processering først, eller omvendt felter der er obligatoriske i det nye system, men som man ikke har haft nogen værdier til før. Disse scenarier er dér, hvor det kan være ekstra udfordrende, og hvor det er vigtigt, at man har en tæt dialog med forretningen, så den rette beslutning bliver taget.
Ud fra det gamle, ind i IFS
Når mapningen er færdig, overleveres det til kundens IT-ansvarlige, som laver udtrækkene fra det eksisterende system. Disse kan så blive migreret ind i IFS, og herefter kan grupperne i projektet begynde at teste deres forretningsflow, for at se om samspillet mellem data og processer også i praksis virker, som man forudså på tegnebrættet.
Best practice vil altid være at køre migreringen på et testmiljø minimum én gang og teste det grundigt, inden man migrerer ind på det rigtige miljø. Hvis datakvaliteten ikke er god nok fra begyndelsen, kan det have store konsekvenser for en virksomhed, og derfor er og bliver migrering en kritisk del i forbindelse med implementering af et nyt ERP-system.
Andre datamigreringsopgaver
Migreringen er selvfølgelig en vigtig del af en ny implementering, men vigtigt er der også at huske på at værktøjet kan bruges til mange andre mindre ad hoc-opgaver også. Det kunne f.eks. være når forretningen skal have alle salgspriser til at stige med 10% eller når man får ny leverandør og ønsker at oprette en større mængde af deres varer i sit ERP-system.
I IFS findes der udover migreringsværktøjet i selve applikationen også en mere simpel udgave, som man kan benytte direkte fra Excel. Det betyder, at du kan sidde med dine data, som du ønsker at opdatere i IFS, rette til og validere, inden du til sidst udfører handlingen, som sætter selve migreringen i gang. Nemt og hurtigt til de mindre opgaver, der opstår i forretningen løbende.
Står du overfor en større eller mindre migreringsopgave, og kunne tænke dig noget sparring i den forbindelse, så skal du være meget velkommen til at kontakte os.