Kortlægning af datakilder før migrering til nyt system

Hvorfor kortlægning af datakilder skal ske før migrering

Ved migrering flyttes eksisterende data til det nye system. Data skal ofte renses og konverteres for at sikre nøjagtighed og kompatibilitet med det nye system. Det kan først planlægges, når kilderne, deres indhold og sammenhæng er kendt. Kortlægningen er optegnelsen: en liste over kildesystemer, tabeller, felter, datastrømme og integrationer med ejere.

Ifølge guiden til implementering af nyt ERP-system på obtain.dk er første skridt i en datamigrationsplan at identificere de data, der skal flyttes fra det gamle system til det nye. Det kan fx være kunder, ordrer, fakturaer, lagerbeholdning, produktionsprocesser og andre forretningskritiske data.

SAP's migreringstjekliste beskriver samme øvelse teknisk: Virksomheder bør kortlægge data fra kildeplatforme og løsninger til strukturen i deres nye ERP-system.

Kortlægningen er ikke et selvstændigt dokument, men input til de øvrige migreringstrin. Kvalitetsvurdering, migreringsplan med tidsplan og ressourceoversigt samt beskrivelsen af validering og verifikation efter migrationen bygger alle på en kendt og afgrænset liste over kilder og felter.

Kortlægningen bør også dække de dele af det nuværende system, som er tilpasset virksomheden. Konfiguration af et nyt ERP-system omfatter oprettelse af brugerdefinerede felter, processer og rapporter. De eksisterende tilpasninger er en del af grundlaget for at vurdere, hvad der skal genopbygges, og hvad der skal konverteres.

Afgræns og prioritér forretningskritiske data

Afgrænsningen tager afsæt i den liste, en datamigrationsplan typisk starter med: kunder, ordrer, fakturaer, lagerbeholdning, produktionsprocesser og andre forretningskritiske data. Gennemgå desuden kritiske processer for at få med, hvilke data der er forudsætningen for, at en proces kan gennemføres i det nye system.

Placér hvert datasæt i en af tre kategorier: skal med fra dag ét, kan med i en senere bølge, eller skal ikke med. Spørg om datasættet er nødvendigt for transaktioner i det nye system, om der findes åbne poster, der skal videreføres, om dataene kun bruges til historisk rapportering, og om de alene understøtter et system, der udfases samtidig med migreringen. Notér begrundelsen for hver beslutning, så den kan genbesøges, når migreringsplanen kvalitetssikres.

Afklar samtidig omfanget i tid og bredde: hvilke årgange skal med, og skal alle selskaber, afdelinger eller lokationer med i samme bølge? Markér datasæt og felter med personoplysninger, så de håndteres særskilt gennem hele kortlægningen og senere i adgangsstyringen af det nye system.

Resultatet af afgrænsningen er den liste, som teknisk kortlægning og mapping arbejder videre med. Uden den bliver kortlægningen en fuldstændig registrering af alle eksisterende data, og både kvalitetsvurdering og migreringstest vokser tilsvarende.

Dokumentér nuværende systemarkitektur, datastrukturer og integrationer

Den tekniske dokumentation skal dække fire områder, som en artikel om migrering fra et ældre system til et nyt ERP-system opsummerer: eksisterende systemarkitektur, datastruktur, arbejdsgange og integrationer. Start med en liste over alle kildesystemer – også regneark, Access-databaser, lokale løsninger og systemer ejet af en ekstern part. Notér teknisk kontakt, hosting og planlagt udfasning for hvert system.

For hvert system dokumenteres datastrukturen på tabel- og feltniveau: tabelnavn, feltnavn, datatype, længde, obligatorisk felt, primære og fremmede nøgler samt eventuelle kodeværdier og opslagstabeller. Beskriv også, hvordan data opstår og ændres – hvilke arbejdsgange der opretter, retter og sletter poster, og hvem der gør det manuelt. Manuelle registreringer er ofte der, hvor formater og værdier afviger mest fra systemets egne.

Kortlæg integrationerne enkeltvis: hvilke systemer udveksler data, i hvilken retning, hvor ofte, via hvilken mekanisme (fil, batch, tjeneste eller direkte databaseadgang), hvem der ejer grænsefladen, og hvordan fejl i overførslen håndteres i dag. Beslut for hver integration, om den videreføres uændret, genopbygges mod det nye system eller udfases. Integrationer er typisk det, der gør en migrering dyrere, end datamængden alene antyder.

Medtag tilpasningerne i den nuværende løsning – brugerdefinerede felter, processer og rapporter – og notér for hver, hvilket forretningsbehov den dækker. Det giver grundlaget for at vurdere, om behovet dækkes af standardfunktioner i det nye system, skal konfigureres igen eller kan bortfalde.

Vurder datakvalitet, mangler og afhængigheder

Datamigrationsplanen kræver, at kvaliteten af de data, der skal migreres, vurderes, og at data er korrekte, fuldstændige og konsistente uden mangler eller fejl. Profilér derfor pr. tabel og felt frem for at give en overordnet bedømmelse.

Hvor mange poster? Hvor mange tomme felter? Hvor mange værdier ligger uden for det forventede sæt?

Findes der dubletter på kundenummer eller CVR-nummer? Er dato-, beløbs- og enhedsformater ens på tværs af kilder?

Kortlæg afhængighederne mellem data, før der rettes noget. Poster, der kun giver mening sammen med en anden tabel – ordrelinjer under et ordrehoved, fakturalinjer under en faktura, bevægelser under en vare – skal kunne følge hinanden gennem migreringen; ellers opstår hængende referencer i det nye system. Notér også felter, der i praksis kun vedligeholdes af en integration eller af et system uden for det, der migreres, da de skal håndteres særskilt.

Beslut for hvert fund, om fejlen rettes i kilden før udtræk, rettes under konverteringen eller accepteres som den er. Beslutningen skal have en begrundelse og en ansvarlig og skal logges, så den kan genbruges ved næste migreringsbølge. Springes trinnet over, flytter fejlene med ind i det nye system, hvor de er sværere at rette, fordi de nu er en del af den daglige drift.

Sæt et målbart kvalitetsniveau for, hvornår et datasæt er klar til overførsel – fx en aftalt andel poster uden manglende obligatoriske felter og uden brudte referencer. Niveauet skal være aftalt med forretningen, før migreringen testes, fordi valideringen efter overførslen skal vise, at dataene er korrekte og fuldstændige.

Map kildedata til målstrukturen i det nye system

Mappingen forbinder kilde og mål på feltniveau. For hver post angives kildesystem, tabel og felt.

Angiv tilsvarende objekt og felt i det nye system, datatype og længde. Notér om feltet er obligatorisk i målet, konverteringsregel, eventuel standardværdi og ejer af reglen. Dokumentér også felter uden modpart – i begge retninger.

Gap-analysen dækker fire typiske situationer: kildedata uden mål i det nye system og felter i målet uden kilde. Også felter, der skal deles op eller slås sammen (fx navn og adresse), og kodeværdier med forskellig betydning i de to systemer.

Så skal opslagstabeller og statusser oversættes. Enheder, valuta og datoformater hører med i samme gennemgang.

Konverteringsreglerne skal beskrives, så de kan testes og gentages. Data skal muligvis renses og konverteres for at sikre nøjagtighed og kompatibilitet med det nye system – og rensningen skal stå i mappingen som en regel med et resultat, ikke som en løs bemærkning. Afklar samtidig, om konverteringen skal respektere forretningsregler i det nye system, fx hvilke felter der udløser en ny status på en ordre.

Test mappingen på et lille, repræsentativt udtræk, før den sættes i drift. Kør reglerne igennem, sammenlign antal poster og nøgletal mod kilden, og gennemgå fejlende poster. Fejler en regel på mere end en håndfuld poster, er det som regel afgrænsningen eller reglen – ikke dataene – der skal justeres.

Fastlæg ejerskab, roller og beslutningspunkter

Hver datakilde skal have en dataejer i forretningen og en teknisk kontakt. Dataejeren svarer på, hvad dataene betyder, og om en fejl kan accepteres; den tekniske kontakt svarer på, hvordan dataene er struktureret, og hvordan de udtrækkes. Uden begge roller ender spørgsmål om feltbetydning og kvalitet hos det samme team, som også skal bygge migreringen.

Knyt ejerskab til de konkrete fund fra kvalitetsvurderingen. Hvert fund får ansvarlig, beslutning og frist, og beslutningen skrives ind i datakildekataloget og mapping-dokumentet, så den ikke skal træffes igen. Det gælder beslutninger om at rette data, acceptere en fejl og udelade et datasæt fra migreringen.

Placér beslutningspunkterne tidligt: hvilke data skal med, hvilket kvalitetsniveau accepteres, hvordan skal mapping og konverteringsregler se ud, og hvem godkender valideringsresultatet efter overførslen? Et fast, reelt beslutningsforum med mandat til at træffe disse valg holder kortlægningen fri af, at hvert enkelt spørgsmål skal hele vejen op i organisationen. Tidsbokse og en løbende log over trufne beslutninger gør det synligt, hvor forløbet står.

Ressourcerne skal afsættes tilsvarende. Ifølge guiden til nyt ERP-system kræver implementering af et nyt system, at der afsættes tilstrækkelig tid og ressourcer til test og validering samt til træning af brugere – og den tid skal indgå i migreringsplanen, ikke lægges oveni bagefter.

Omsæt kortlægningen til migreringsplan og validering

Ifølge guiden til implementering af nyt ERP-system skal migreringsplanen indeholde en tidsplan for datamigreringen, en oversigt over de involverede ressourcer og en beskrivelse af, hvordan dataene valideres og verificeres efter migrationen. Kortlægningen leverer grundlaget for alle tre dele: kildelisten giver rækkefølgen, mappingen arbejdsomfanget, og kvalitetsrapporten de opgaver i datarensning, der skal ligge før selve overførslen.

Fastlæg rækkefølgen efter afhængigheder, ikke efter hvad der er nemmest at udtrække. Stamdata – kunder, leverandører, varer og opslagstabeller – etableres typisk før transaktionsdata som ordrer og fakturaer, så referencerne findes, når de efterfølgende poster indlæses. Åbne poster, der skal videreføres, håndteres som et selvstændigt spor, fordi de både skal stemme med kilden og kunne behandles videre i det nye system.

Vælg metode eksplicit: fuld overførsel af hele historikken, selektiv overførsel af aftalte årgange eller en kombination, hvor stamdata migreres samlet, og ældre historik kun gøres læsbar. Metodevalget påvirker både tidsplanen og den manuelle indtastning for data, der ikke kan konverteres maskinelt.

Valideringen efter overførslen skal være konkret og gentagelig: antal poster pr. tabel mod kilden, kontrolsummer på beløb, afstemning af åbne saldi og stikprøver på tværs af gamle og nye sager. Kør migreringen flere gange i testmiljøet, og brug fejlraten mellem kørslerne som styringsværktøj – den skal falde, før produktionskørslen godkendes. Migreringen lukkes først, når valideringen viser, at dataene er korrekte og fuldstændige.

Leverancer: datakildekatalog, mapping og kvalitetsrapport

Datakildekataloget er den samlede oversigt over kilder: system, tabel, felt, datatype, ejer, teknisk kontakt, årgange, omfang, integrationsafhængigheder og markering af personoplysninger. Det er opslagsværket, som kortlægning, mapping og senere validering henviser til.

Mapping-dokumentet indeholder kilde-til-mål-oversættelsen pr. felt med konverteringsregler, standardværdier, opslag og accepterede undtagelser med begrundelse. Kvalitetsrapporten indeholder fundene fra profileringen med alvor, beslutning, ansvarlig og status og opsummerer det aftalte kvalitetsniveau for klar-til-overførsel.

Den fjerde leverance er migreringsplanen med tidsplan, ressourcer og valideringsbeskrivelse. De fire dokumenter hænger sammen: en ændring i kataloget skal slå igennem i mappingen, og et nyt fund i kvalitetsrapporten kan ændre både rækkefølge og tidsplan.

Hold leverancerne opdaterede frem til migreringen med fast kadence og en navngiven redaktør for hvert dokument. Enhver ændring i kildesystemerne undervejs – nye felter, nye integrationer, ændrede arbejdsgange – skal ind i kataloget og vurderes mod mappingen; ellers migreres der på et grundlag, der ikke længere svarer til virkeligheden. Versionsnummerér dokumenterne og log ændringer, så det er muligt at se, hvilket grundlag en given test- eller produktionskørsel blev godkendt på.