Datakonvertering er en uundgåelig del af så godt som alle projekter der omfatter implementering af forretningssystemer – især ERP-systemer. Typisk en opgave der i starten af projektet lever stille og måske lidt hensygnede, men før eller siden rammer virkeligheden og opgavens helt centrale betydning bliver klar. Det er meget vanskeligt at gradbøje datakonverteringen, dvs. mulighederne for short-cuts er ofte begrænset, ligesom kompromisser mht. kvaliteten er et sjældent ønske. Det er en ”Make it or Break it” type af opgave. En fejlbehæftet datakonvertering kan give katastrofale følger for ibrugtagning af et nyt forretningssystem, og i så fald flyttes fokus fra at tage et i øvrigt godt system i brug til brandslukning af problemer forårsaget af en fejlslagen datakonvertering. Et problem der kan ende med ”udfordringer” i forhold til medarbejdere, kunder og leverandører.

En typisk fejl er at opgaven betragtes som en ren teknisk problemstilling, hvor data skal flyttes fra et system til et andet. Opgaven bliver derfor bemandet med teknikere uden synderlig involvering af forretningen. Det er naturligvis også korrekt at opgaven kræver ”teknik” og at data skal ”flyttes”, men opgaven skal tage udgangspunkt i forretningen og den kræver centrale forretningsmæssige beslutninger. Hele formålet med datakonverteringen er at sikre forretningsmæssig kontinuitet – virksomheden der implementere et nyt ERP-system ønsker selvfølgelig at fortsætte fakturering af kunder, betaling af leverandører, udlevering fra lagre og udførelse af projekter på tværs af en systemudskiftning – helst som om intet var hændt. Så derfor er der vigtige forretningsmæssige beslutninger i forhold til, hvordan denne kontinuitet skal sikres og dette bliver styrende for hvordan datakonverteringen skal gribes an.

En anden fejl er at opgavens omfang i kalendertid undervurderes. Med datakonvertering er det bedre at starte stort og slutte småt end at forsøge det modsatte. Dvs. sørg for at alle sten vendes til at starte med for at finde ud af, hvilke opgaver der skal løses. Dette kræver at opgaven starter tidligt i et implementeringsforløb således at der er tid til at komme godt rundt om opgaven.

En tredje fejl er at undervurdere ressourcebehovet. Opgaven kan for hurtigt reduceres til noget med dataudlæsnings- og indlæsning. Men der er typisk behov for at afklare og dokumentere de forretningsmæssige behov. Til at planlægge, forberede og gennemføre tests. Til at rydde op i og klargøre gamle data. Til at verificere data.

Der er min anbefaling altid at starte med udarbejdelse af en datakonverteringsstrategi. Dette er nøglen for at komme godt i gang. I datakonverteringsstrategien gælder det om at identificere kildesystemer, og at kortlægge behovet for datakonvertering, dvs. hvilke forretningsobjekter er i scope og hvordan påvirkes og håndteres forretningskontinuiteten. Hvad forventes af forretningen f.eks. mht. ”vask” og klargøring af data.

Forretningen har behov for at verificere tilgangen til datakonverteringen, dvs. der typisk er et behov for detaljeret stillingtagen til om konverteringen giver den kontinuitet i forretningen som der er behov for. Det betyder at der bør udarbejdes dokumentation for, hvordan konverteringen gennemføres og hvilke forretningsregler der skal benyttes. Blot som eksempel – hvis der nu skal konverteres åbne kundefakturaer så åbnes der op for en række problemstillinger som der skal tages stilling til. Hvad med delvist betalte fakturaer? Hvordan skal finansposteringerne håndteres? Ønsker vi at konvertere linje for linje? Hvad gør vi hvis der er tilskrevet renter og gebyrer? Skal fakturaen fortsat kunne sendes via EDI eller printes? Måske ender det med en simpel løsning, men der gælder om at komme godt rundt om problemstillingen.

Sørg også for tidligt at fastlægge tilgangen til tests, dvs. hvordan skal datakonverteringen verificeres. Det er næppe nok at kigge på indlæste data. Konverterede data skal benyttes operationelt og de nye processer bør verificeres på data skabt gennem datakonverteringen. F.eks. om der kan registreres timer og faktureres for konverterede projekter, om lageroperationer kan gennemføres på konverterede lagerdata, om lønnen kan beregnes korrekt osv.

Jeg håber ovenstående har givet lidt inspiration til håndtering af datakonverteringen når det drejer sig om implementering af forretningssystemer.