DATAMIGRERING OG TEST I ET PROJEKTFORLØB
Denne artikel er en kort beskrivelse af nogle af de tanker jeg har gjort mig gennem mange års arbejde med IT-projekter. Artiklen er skrevet til alle der arbejder med større IT-projekter, og jeg håber den kan give anledning til eftertanke – måske især hos projektledere.
INTEGRER TEST OG DATAMIGRERING I PROJEKTET FRA STARTEN
Migrerings rollen har ofte status af projektets “efternøler”: Kommer ind i billedet lige som man tror at nu er alle børnesygdomme overstået og man kan se enden på det hele, stiller en masse dumme spørgsmål og er i det hele taget lidt til besvær. Jeg har set projekter hvor man først startede processen med datamigrering når man havde en (forholdsvis) sikker formodning om Go-Live dato, eller hvor der (som udgangspunkt) kun var afsat under 1% af projektets ressourcer til migrering.
Denne strategi kan godt benyttes, men man skal gøre sig klart at det har konsekvenser. En migreringsekspert udtrykte det en gang således: “Fint; når al opsætning, udvikling og testning er klar så frys systemet, og vi skal nok sørge for at alle data er migrerede og konverterede i løbet af 9 måneder”. Det skabte spredt munterhed i lokalet indtil det gik op for folk at han mente det alvorligt!
Ovenstående kunne faktisk også godt beskrive testningens rolle i et projekt, så hvorfor ikke slå dem sammen? Nedenstående figur illustrerer (meget forenklet) hvordan man efter min mening ved at inddrage testning og migrering fra starten i projektet kan opnå et mere stabilt projektforløb.
Test og migrering bør følge udviklingen af systemet så man løbende kan evaluere design og udvikling med data fra det gamle system. Ved løbende at udvide både test- og migrerings-scope i takt med at det nye systems udvikling, vil integrationen til data sikres og afprøves løbende og fejl/mangler afdækkes tidligere.
DET GAMLE SYSTEM: DATA RENSNING OG MIGRERINGS SCOPE
Næsten alle nye systemer erstatter et eller flere eksisterende systemer, så at migrere data er en essentiel del af projektet. Datamigrering kan sammenlignes med at flytte fra et hus til et andet: Alt pakkes ned og mærkes, køres i store lastbiler til det nye hus og pakkes ud og placeres på rette plads. Eksperter i organisering anbefaler dog at man luger grundigt ud i sine ejendele inden man pakker dem ned: Der er f.eks. ingen grund til at flytte alt det skrammel med man har haft stående på loftet siden man sidst flyttede!
At rense det gamle system for forældede data før man migrerer er selvfølgelig vigtigt for at sikre datakvaliteten i det nye system, men der er et andet hensyn som et mindst lige så vigtigt: at overholde EU’s Databeskyttelsesforordning (“General Data Protection Regulation” eller GDPR). Denne trådte i kraft i maj 2018 og selv om alle systemer burde have implementeret reglerne i forordningen, er det nok umagen værd at sikre at de data der migreres, i det mindste, gør det.
Det er også vigtigt at se kritisk på hvilke data der migreres (og bruges til test). Ved fra starten at begrænse scope, både hvad angår entiteter og attributter, og kun udvide når systemet har behov for det, opnår man at begrænse migreringen til det nødvendige (“Need-To-Have”) og ikke alt det mulige (“Nice-To-Have”). At migrere attributter der ikke understøttes af det nye system er en ofte forekommende fejl, og kan medføre at man senere kan få problemer når man vil føje ny funktionalitet til systemet.
UDVIKLINGSPROCESSEN: INTEGRER TEST OG DATAMIGRERING!
Når man alligevel skal forberede datamigreringen, er det en fordel at udpege et test-scope der kan benyttes under udviklingen af det nye system. Ved hovedsageligt at basere testen på migrerede data opnår man dels et bredt og sammenhængende test-scope og dels en løbende mulighed for at udbygge og afprøve migreringen. I starten vil det formentlig især være stamdata der er fokus på, men hvis man efterhånden udbygger med transaktionsdata kan man ende op med en migreringsproces der skulle kunne gennemføres uden overraskelser ved Go-Live.
For at sikre at det nye system hele tiden spiller sammen med de migrerede data, bør man fra starten tænke i automatiserede testforløb, f.eks. i SolMan og TDMS. SAP Solution Manager (SolMan) Test Suite kan benyttes som base dels for manuelle test og automatiserede test, og SAP Test Data Migration Server (TDMS) kan benyttes til at automatisere oprettelsen af test-miljøer.
EFTER GO-LIVE: RYD OP OG ARKIVER!
Go-Live er vel overstået, og projektdeltagerne spredes for alle vinde. Men lige som til en fest, er det vigtigt at nogen bliver tilbage og hjælper med at rydde op så værten ikke står tilbage med det hele alene!
Selv om man (selvfølgelig…) har sat det nye system op til at arkivere automatisk, er der alligevel meget der skal gøres lige efter Go-Live. Især datamigreringen har ofte “efterladt” en række programmer (og midlertidige filer) som det vil være klogt at rydde op mens de er i frisk erindring, men derudover har erfaringen vist at data fra migreringens Savepoints bør gemmes indtil man er HELT sikker på ikke at få brug for dem! Disse filer er ofte placeret uden for SAP, men min anbefaling er at importere dem (ukonverteret) til SAP og derefter arkivere dem.
Intelligent automatiseret arkivering er et kapitel for sig, som jeg ikke vil komme nærmere ind på her.