GUIDE TIL DOKUMENTMIGRERING

Nyt system! Så skal dokumenterne bare overføres fra det gamle system.
Det kan lyde nemt, men det er ikke nødvendigvis så enkelt, som man skulle tro…
Projektet bliver forsinket, brugerne kan ikke finde dokumenterne, data går tabt osv.
Forhåbentlig kan denne guide hjælpe jer med at undgå disse ting.

1. Introduktion

Denne vejledning dækker migrering af dokumenter. Migrering af dokumenter adskiller sig på flere måder fra migrering af (strukturerede) data. Disse forskelle medfører ofte fejlvurderinger af en forestående dokumentmigrering. Vi gennemgår og gennemgår her en migrering fra A til Z.  

1.1. Alle sektorer – herunder regulerede

De erfaringer og metoder, der deles i denne guide, stammer i vid udstrækning fra den stærkt regulerede medicinalindustri. Vi vil dog forklare vores metoder bredt anvendeligt og kun i kommentarer bemærke, hvor særlige forhold gælder for regulerede industrier. Til sidst runder vi af med et afsnit, specifikt for regulerede industrier.

1.2. Årsager til migrering

Dokumenter migreres hovedsagelig af tre årsager:

  • Et nyt system er ved at blive implementeret, og indholdet fra det gamle system skal overføres til det nye.
    Det kalder vi (system) migrering.
  • En større volumen af dokumenter fra en leverandør eller partner skal indlæses i eget system.
    Det kalder vi import.
  • Dokumenter fra et kørende system skal flyttes til arkivet.
    Det kalder vi arkivering.  

Guiden fokuserer på det, vi kalder (system)migrering, men de fleste pointer, vil være lige så gyldige i de to andre situationer.

2. Indholdsfortegnelse

  1. Introduktion
  2. Indholdsfortegnelse
  3. Nyt system – appendix migrering
  4. Inden du går i gang
  5. Migreringens faser
  6. Migration-center
  7. Life science
  8. Konklusion

3. Nyt system – migrering som appendix

I en system-implementering er der ofte mest fokus på design og opsætning af det nye system. Brugerne involveres i processen omkring forretningsprocesser, funktionalitet og brugervenlighed. Det er naturligt og vigtigt, men betyder desværre også at migreringen ofte overses.

3.1. Historie

Det gamle system er fyldt med dokumenter og dokumenthistorik, og det er ikke nødvendigvis alt der skal med over i det nye system. Noget skal måske arkiveres, og andet kasseres. Alt, hvad der skal overføres til det nye system, skal altså identificeres. Det er sjældent klogt eller korrekt at antage, at alt blot skal migreres. Der bør gennemføres et særskilt projekt til håndtering af de dokumenter, der ikke migreres, men vi vil behandle disse overvejelser et andet sted. Fokus i denne artikel er på migrering. Hvordan man migreret dokumenterne på en måde, så de kan findes, bruges og versioneres i det nye system.

3.2. Brugernes accept af det nye system

Det er afgørende for brugernes accept af det nye system, at dokumenterne migreres, på en måde, der yder det nye system retfærdighed. Alternativt kan et ellers udmærket system nærmest blive erklæret ubrugelige af brugerne, fordi de ikke kan finde og bruge deres dokumenter ordentligt. Det bør af indlysende årsager undgås.

3.3. Nyt system – alt inklusive

Leverandøren af det nye system har ofte givet et godt tilbud på migrering med et løfte om at importere dokumenterne fra det gamle system inden idriftsættelsen. Dokumenter og metadata skal blot leveres i et bestemt format, så klarer de resten. Det lyder enkelt nok, men der hører meget mere til processen.

Det virker meget acceptabelt, at leverandøren blot skal have udleveret en masse filer og nogle regneark lige før go-live. I sjældne tilfælde er det faktisk også det eneste der skal gøres, men det hører desværre til sjældenhederne.
Leverandørernes tilbud er såmænd reelt nok, og de vil ofte også være de bedste til at få dokumenterne sikkert ind i deres system. Men er der tale om et standardsystem, er leverandøren ikke nødvendigvis det bedste valg.
Vi vil gerne fokusere på det, der synes at være den lette del af opgaven, nemlig “bare at levere” dokumenter og metadata. Mange lader sig mislede af dette, og konsekvenserne kan være enorme. Lad os starte fra begyndelsen.

4. Inden du går igang

4.1. Forstå din migrering

Migrering kan være problematisk, hvis den undervurderes og tages for let. Det er derfor først og fremmest nødvendigt at forstå den migrering, man står over for. Nedenfor følger nogle korte opmærksomhedspunkter, samt henvisninger til andre artikler, der går mere i dybden med de enkelte aspekter og krav.

Anbefalede artikler:

4.1.1. Den korte udgave

Dokumentmigrering har nogle komplekse aspekter, som i høj grad hænger sammen med forskellen mellem dokument- og datamigrering. Nemlig at et dokument består af både selve indholdet og det tilhørende metadata.

Nogle af disse metadata er blot beskrivende og bruges til at søge efter dokumentet. Andre metadata skal betragtes som en integreret del af dokumentet, f.eks. til at bevise dokumentets autenticitet. Endelig findes der metadata af typen der beskriver relationer til andre dokumenter, andre versioner, andre formater, andre filer i samme sag osv.

Dokumenter har således to dele og en masse relationer, som skal håndteres uden at miste forbindelserne. I nogle af de artikler, der er refereret ovenfor, beskrives hvordan dokumenter kan miste deres anvendelighed og integritet – og dermed f.eks. deres juridiske gyldighed – hvis dette håndteres forkert.

Resultatet er, at vi står over for en kritisk og kompleks operation, som alt for let bliver undervurderet.

4.2. Værdiskabende migrering

Den historiske dokumentation tiltrækker ikke den samme opmærksomhed som det spændende nye system. Forståeligt nok, men også lidt synd. En migrering er en fantastisk mulighed for at rydde op og få data af høj kvalitet ind i det nye system. Det afspejler sig igen positivt i brugeroplevelsen og værdisystemet. 

Selv om det gamle system er blevet brugt med omhu, viser det sig ofte – vi tør næsten sige “altid” – at der stadig alligevel gemmer sig overraskelser i datagrundlaget. Det kan være dokumenter der er registreret under “diverse”, eller som er gemt uden egentligt formål eller værdi, eller hvor dokumentejeren for længst har forladt virksomheden. Nogle af disse ting er mindre vigtige, men typisk er mængden af sådanne ting overvældende, hvilket gør opgaven med at levere regnearket og filerne til systemleverandøren til en kæmpe opgave.

Hvis vi ser videre end det nye system og dets brugere, er en forbedring af dokumentkvaliteten noget, der bidrager til effektivitet, kvalitet og overholdelse af reglerne i almindelighed.

Migrering kan ses som en irriterende ekstraudgift i forbindelse med implementeringen af et nyt system. Men man kan også vende det om og se det som en værdiskabende aktivitet. Hvis den skal skabe værdi, skal de rette kompetencer bringes i spil, og opgaven skal tages alvorligt.

4.3. Sammensæt det rigtige hold

Selv om IT er en stor del af en migrering, bør det betragtes som en forretningsmæssig øvelse. Værdien skabes ved at behandle dokumenter og data systematisk og ved at rense og berige dem i processen.

En vellykket migrering kræver en bred vifte af viden: 

  • Teknisk viden om det gamle og det nye system.
  • Forretningsmæssig forståelse af brugen af det gamle system og den planlagte brug af det nye system
  • Kendskab til organisationens stamdata
  • Viden om de regler og bestemmelser, virksomheden er underlagt (især for regulerede virksomheder)
  • Generel viden om dokumenthåndtering

Mange organisationer har en uddannet arkivar, records manager, informationsspecialist eller lignende et sted i organisationen. Det er en kompetence, som med fordel kan inddrages i migrationsprocessen. I modsætning til resten af teamet vil denne person typisk være interesseret i den historiske dokumentation, sporbarhed og kritiske metadata – detaljer som andre typisk vil have mindre fokus på. 

5. Migreringens faser

I virkeligheden består en migrering af en række forsøg, med fejl og uventede overraskelser i dataene. Det er et faktum vi ikke kan ignorere, men som vi til gengæld kan vælge at håndtere rigtigt. Det bedste at starte med er at opdele migreringen i faser, og give den struktur. Strukturen er en stor hjælp, men skal anvendes med respekt for den omkringliggende virkelighed. Der vil altid dukke noget nyt op, som skal analyseres, længe efter analysefasen er overstået osv. 

Vi anbefaler altid en struktur der starter med for-analyse og med efterfølgende metodevalg. Næste skridt er en iterativ proces med analyse, konfiguration og afprøvning. Når afprøvningen giver et tilfredsstillende resultat, gennemføres en mere formel test. Hvis den er vellykket, udføres den egentlige migrering. Slutteligt følger rapporteringen.

I de følgende afsnit vil hver af disse faser blive gennemgået.

5.1. Foranalyse

Formålet med for-analysen er at fastlægge de overordnede krav til migreringen, så der kan træffes kvalificerede beslutninger om teknologi og metodologi.

En for-analyse kan risikere at trække ud, da man altid kan gå et spadestik dybere. Det er derfor vigtigt at sætte sig klare mål og stoppe, når man ved nok til at træffe en beslutning.

Typiske emner, der skal adresseres, er følgende:

  • Estimeret scope (hvilke dokumenter og data)
  • Overordnede tekniske forskelle mellem kilde- og målsystemer
  • Overordnede strukturelle forskelle mellem kilde- og målsystemer
  • Datakvaliteten i kildesystemet
  • Regulatoriske krav
  • Målsystemets implementeringsstrategi (f.eks. trinvis eller big bang) 
  • Forretningsmæssige krav, f.eks. tidsplan, eventuel nedlukning osv.
  • Finansielle, ressourcemæssige eller tidsmæssige begrænsninger

5.2. Valg af metode og teknologi

På baggrund af for-analysen besluttes det, hvordan der skal migreres. Der er tre hovedspørgsmål, der skal besvares:

  • Teknologi:
    Bruger man et migreringsværktøj, hjemmelavede scripts eller er det “dump and load”?
  • Segmentering:
    Skal migreringen være “big bang” eller trinvis, og i givet fald hvordan?
  • Kvalitetssikring:
    Hvordan sikrer vi kvaliteten af migreringen (valideringsmetode i life science), og hvordan vil vi rapportere på migreringen?

5.2.1. Teknologi

I forbindelse med valg af teknologi, har vi følgende råd og erfaringer:

  • Hvis de to systemer er strukturelt ens, f.eks. hvis det nye system er en nyere version af det gamle, kan man måske detache/dumpe hele databasen og attache/loade den i det nye system. I så fald er migreringsopgaven en rent teknisk opgave, og nogle af de ovenfor nævnte bekymringer om integritet og de rette kompetencer i projektet er irrelevante.
  • En migrering er grundlæggende en eksport fra kildesystemet, og en import til målsystemet. Ofte har leverandøren af det nye system tilbudt at importere til det nye system. Hvis kildesystemet har en tilstrækkelig eksportmulighed, og hvis output kan bruges af importfunktionen, kan denne fremgangsmåde være den rigtige løsning.
  • Ofte er der imidlertid forskel på metadata, i det nye og det gamle system. Det betyder, at metadata skal transformeres i processen. Der kan også være behov for berigelse eller oprydning under migreringen. Hvis det er tilfældet, anbefaler vi at bruge et kommercielt værktøj, udviklet til at håndtere mapping og transformationer af metadata. Det er en mulighed at udvikle noget selv, men det kan sjældent betale sig i forhold til at købe eller lease et eksisterende værktøj.
  • Afhængigt af hvilke platforme, der skal migreres fra og til, findes der en række værktøjer på markedet. Vi har en favorit som vi foretrækker, medmindre omstændighederne taler for noget andet. Det er migration-center fra det tyske firma fme AG. I mange tilfælde er dette værktøj et rigtig godt valg. Det kan forbinde til en lang række systemer ”out of the box”. Derudover har det alle de funktioner, som vi hidtil har haft brug for med hensyn til mapping, transformation og rapportering. Kunstig intelligens til klassificering er begyndt at dukke op i værktøjet som en mulighed. De er ikke frontløbere på AI, men udviser snarere bevidst forsigtighed for at bevare værktøjets kernefunktionalitet og dokumentere fuld kontrol under hele migreringen.

5.2.2. Segmentering af migreringen

Der er en fysisk grænse for, hvor mange data, der kan flyttes, på en given tid. Det er derfor ikke altid muligt at lukke ned fredag aften, migrere i løbet af weekenden og så være klar mandag morgen. Det er imidlertid meget ofte et ønske fra forretningen. Når det er tilfældet, må migreringen opdeles i mindre bidder.

Hvis brugerne skal onboardes til det nye system i faser, og dokumenterne skal migreres i takt med det, er det også nødvendigt med en segmentering af migreringen.

Man vælger tit at dokumenter fra igangværende projekter, ikke skal migreres med det samme. Disse forbliver i det gamle system, indtil projektet er afsluttet. Dette vil forstyrre forretningen minimalt, men vil til gengæld betyde at der skal laves en opsamlende migrering når projektet er færdigt. Først derefter kan det gamle system lukkes helt.

Kort sagt ender man meget ofte med at skulle migrere i etaper, hvilket øger kompleksiteten af projektet. Du skal holde styr på, hvad der er blevet migreret, håndtere nye dokumenter og dokumenter der, er blevet redigeret i det gamle system efter den første migrering.

Det bliver naturligvis endnu værre, hvis der er brug for at dokumenter kan ændres i begge systemer af to forskellige brugergrupper, og disse så skal synkroniseres. Dette bør undgås så vidt muligt, simpelthen fordi kompleksiteten bliver meget høj. 

Man skal beslutte sig for, om man vil opdele migreringen i mindre dele eller om man vil gå efter at migrere alt på en gang. Hvis man vælger at underopdele, er det normalt en god indikator for, at det kan være en god ide med et kommercielt migreringsværktøj.

5.2.3. Kvalitetssikring

Hvis de dokumenter man har med at gøre, er ’records’ [LINK], bliver migreringen en kritisk proces. Her lader vi det blive ved påstanden, men i artiklerne refereret til i afsnit 4.1 ovenfor, forklares og begrundes det nærmere.

Det betyder, at der skal etableres en proces, der sikrer – og kan dokumentere – at alle records er korrekt migreret. Der er to spor til dette:

  • Test af metode og teknologi
  • Test, kvalitetssikring og dokumentation af migreringen

Hvis den anvendte teknologi er hjemmelavet, vil testarbejdet naturligvis blive temmelig omfattende.

5.3. Analyse, konfiguration og test

Denne fase består af iterative cyklusser med undersøgelse, afprøvning og forbedring, indtil der opnås et tilfredsstillende resultat.

  1. Første skridt er, at definere den delmængde af data, man ønsker at migrere. Det kan være alle dokumenter af en bestemt type, fra en bestemt afdeling, i en bestemt tilstand, relateret til bestemte produkter, osv.
  2. Dernæst skal der styr på klassifikation og mapping. Det handler om, hvordan objekter i det ene system passer med objekter i det andet system. Ofte opererer systemerne med nogle grundlæggende dokumenttyper, som skal matches mellem det nye og det gamle system. Det gamle system opdelte måske efter dokumenttypen, fx rapport, mens vi i det nye system opdeler efter det produkt rapporten beskriver.
  3. Herefter er der fokus på metadata for hver af de ovennævnte klasser eller typer. I det gamle system var der måske ‘title’ på en rapport, mens det i det nye system er ‘name’. Feltet “title” skal så mappes til feltet “name”, så værdien ender i det rigtige felt under migreringen. 
    Men det kan være – og er typisk – langt mere kompliceret. Nogle gange giver reglen ikke det forventede resultat, når den anvendes. Selv om reglen er korrekt, kan der være et antal dokumenter, der opfører sig anderledes end forventet. Det betyder typisk, at reglen skal justeres, eller at dokumenterne måske skal underopdeles yderligere.
  4. Endelig er der selve værdierne. I mange systemer findes der en liste over tilladte værdier for de forskellige felter. Måneder, lande, produktnumre, kundenavne osv. Værdierne, der migreres til et givet felt, skal altså matche de tilladte værdier i målsystemet.
    Hvis værdierne er forskellige imellem de to systemer – og det er de næsten altid – skal værdilisterne mappes op imod hinanden. Det kan f.eks. være oversættelser, stavefejl, nye afdelingsnavne, ændrede produktnavne osv.
    Det værktøj, vi ofte bruger, har en mulighed for at simulere en migrering. Det kan indsamle alle oplysninger fra kildesystemet og eksperimentere med dem, offline fra det egentlige system. Når reglerne er opsat, kan de anvendes på dokumenter i delmængden og give resultatet. I de første par forsøg vil resultatet sandsynligvis ikke blive som forventet. På et tidspunkt skal resultaterne gennemgås af en person med forretningsmæssigt kendskab til dokumenternes indhold. Her kan det være praktisk at kunne eksportere resultaterne til et regneark. Når alle datasæt giver et tilfredsstillende resultat, kan den egentlige import til målsystemet forberedes.
  5. Før en egentlig migrering påbegyndes, anbefales det at opstille en roll-back-strategi. Det kan f.eks. være et script, der fjerner og rydder op, hvis en migrering fejler. Roll-back-scripts og -processer kan skrives manuelt eller opsættes som en funktion i et egnet migrationsværktøj.

5.4. Formel test/pilot

Indtil videre har vi afprøvet og testet resultatet. Nu er det tid til en formel test, forud for den egentlige migrering. Indholdet af en formel test er både afhængigt af branchen og valg af teknologi og metode. 

Sædvanligvis laver man en pilotmigrering, hvor der migreres nogle få, men repræsentative dokumenter. Mængden skal være tilstrækkelig til at man kan sikre sig, at det man forventer sker, også sker. Testen af pilotmigreringen bør udføres af slutbrugere fra forretningen, og ikke de teknikere og forretningsanalytikere der udførte migreringen. Man kan se på det som en acceptance test af migreringen – på samme måde som man typisk laver en sådan acceptance test af et nyt system.

I life science-branchen må man forvente at skulle kvalificere teknologien og metodologien og efterfølgende validere migreringen. Pilotmigreringen kan betragtes som en del af kvalificeringen. Strator har et sæt skabeloner til både IQ, OQ og PQ/UAT, som kan tilpasses din migrering og dit QMS.

Med et positivt resultat af formelle test – uanset branche og form – kan den egentlige migrering udføres.

 5.5. Migrering

Nu er det tid til selve migreringen. Det kan være en big bang-migrering, hvor vi lukker det gamle system fredag aften, migrerer alt, og åbner det nye system mandag morgen. Oftere består migreringen dog af flere mindre migreringer, som angivet ovenfor. Uanset hvad, vil der som regel være et lukkevindue, i løbet af hvilket man får gennemført migreringen og lukker det gamle system.

Kort sagt handler denne fase om at gøre det vi har øvet os på – migrere dokumenterne og teste at det er gået godt.

Det kan være nødvendigt med en stram tidsplan og en klar plan for sidste chance for en roll-back. Det er naturligt, at når der opstår problemer, forsøger man at løse dem uden at fokusere på ret meget andet. Her er den gode plan vigtig, så man får stoppet i tide til at rulle tilbage. Der er ikke noget generelt at sige om det, andet end at man skal være opmærksom på det potentielle problem.

Det er også vigtigt at være opmærksom på, at der kan være obligatoriske krav til kvalitetssikring. F.eks. vil man typisk kræve, at migreringen skal verificeres (testes) og godkendes, før man kan åbne for adgang til brugere på det nye system.

Man skal forberede sig på at håndtere fejlbehæftede dokumenter. Der vil altid ske noget uforudset, og det er vigtigt at være klar til at håndtere det. Det kan være en god ide at lave en liste over eventuelt problematiske dokumenter og håndtere disse efter hovedmigreringen. På den måde sikres fremdrift i migreringen og tidsplanen kan overholdes. Der kan dog være brancher eller forhold der gør at dette ikke er en at dette ikke er god praksis.

5.6. Rapport

Efter migreringen er det god praksis, hvis ikke et direkte krav, at dokumentere migreringen.

Hvis der er benyttet et migreringssystem, vil det være oplagt at basere sin dokumentation på en log fra dette. Den bør vise, hvilke transformationer dataene har gennemgået, og at filerne i målsystemet er identiske med dem i kildesystemet. Rapporten bør indeholde dokumentation fra både pilotmigreringen og den endelige migrering. Rapporten og den tilhørende dokumentation bør gemmes som bevis for dokumenternes integritet under migreringen.

6. Migration-center

Som tidligere nævnt, bruger vi værktøjet ‘migration-center’ fra tyske fme AG. Migration-center blev oprindeligt udviklet til at migrere dokumenter til Documentum, og vi har i Strator mere end 15 års erfaring med værktøjet.

Documentum er en meget stor platform, der understøtter meget komplekse relationer mellem dokumenter. Migration-center er udviklet til at håndtere den kompleksitet, og vil derfor kunne understøtte langt de fleste produkter på markedet. Derudover har Documentum historisk set været meget udbredt i life science-branchen, hvilket betyder at migration-center også understøtter de strenge regulatoriske krav der stilles til den branche.

Værktøjet er nu blevet generaliseret, kan bruges med forskellige forbindelser mellem kilde- og mål-system, de såkaldte “migration paths”.  

6.1. Værktøjets opbygning

Migration-center er – indtil videre – et traditionelt klient-server-værktøj, der installeres inden for kundens firewall. Kilden til en migrering er normalt on-premises (altså ikke cloud), og derfor det giver den bedste performance at have migreringsværktøjet ved siden af. Værktøjet betjenes fra en klient, med en migrerings- og en database-server nedenunder. 

Værktøjet fungerer fra operatørens synspunkt som beskrevet nedenfor.

6.1.1. Scanning

  • Kilden scannes for dokumenter 
  • Alle tilgængelige metadata indlæses til databasen
  • Hvis det er relevant, kan selve filerne fra kilden også indlæses

6.1.2. Processering

  • Dokumenterne opdeles i passende delmængder
  • Metadata kortlægges for en udvalgt delmængde, og der opstilles regler for transformationer
  • Transformationerne udføres – Migreringen simuleres og resultatet præsenteres 
  • Resultatet valideres – En teknisk kontrol af de beregnede værdier og datatyper (indeholder datofelter fx en dato?) 
  • Iterationer over regler, mapping, transformation og validering, til man har et tilfredsstillende resultat. 
  • Eksperter med forretningsviden inddrages til review.

Processen gentages for de øvrige delmængder. Ved at arbejde med passende delmængder, er det lettere at opstille enkle regler for hver delmængde.

6.1.3. Import

  • Efter simuleringerne importen til målsystemet påbegyndes. I overensstemmelse med den faseinddeling, præsenteret tidligere i denne guide, skal der stadig udføres en formel test, inden der importeres til produktionssystemet. 
  • Når importen påbegyndes, er det vigtigt at sikre sig at man arbejder med opdateret data. Hvis det data der blev indlæst fra det oprindelige scan stadig er validt, kan dette umiddelbart importeres. Alternativt må man foretage et nyt scan, eksekverer de opstillede regler og transformationer og endelig importere det nye datasæt.
  • Under importen vil alle transaktioner blive opsamlet i en log, som efterfølgende kan bruges i en migreringsrapport.

6.2. Gate-model

Migration-center har en feature de kalder gate-modellen. Det betyder, at dokumenterne kan have forskellige tilstande i værktøjet, som f.eks. transformeret, valideret eller importeret. Tilstandene er forbundne, så det ikke er muligt for et dokument at blive valideret, før det er transformeret, eller importeret, før det er valideret. 

Med den funktion kan migration-center holder styr på hvert enkelt dokument. Det bliver tydeligt vist om et dokument er klar til at blive importeret, og hvordan en import er gået. Når et dokument fejler, holder migration-center styr på dette. Det vil automatisk forsøge at migrere det igen i en efterfølgende kørsel, mens de dokumenter, der er blevet succesfuldt migreret, springes over. Det er en kæmpe hjælp og støtte i den praktiske udførelse af en migrering.   

6.3. STORT OG KOMPLEKST VÆRKTØJ

Migration-center er ikke et værktøj, som man lærer at bruge på en dag. Det kan rigtigt meget og er derfor relativt komplekst at bruge. Det kræver hjælp og træning, hvis man skal blive i stand til at udføre migreringer. 

Tidligere var migration-center og andre lignende værktøjer designet til et eller to bestemte systemer, og derfor relativt dyre. Men efterhånden som værktøjerne er modnet og blevet mere generelle, er prisen faldet betydeligt og har fleksible licensmodeller.

7. Life Science

Dette afsnit er specifikt for håndtering af GxP-kritisk materiale, som kræver særlig opmærksomhed. Alt, hvad vi har drøftet ovenfor, gælder også her, eller måske endda i særdeleshed også her.

Strator arbejder på tværs af en række industrier, men life science-industrien har altid fået særlig opmærksomhed. Det er her, der i udpræget grad er brug for vores dybe ekspertise, og vi har lang erfaring med at begå os i dette regulerede miljø.

Migration-center-værktøjet er gennem tiden blevet brugt til migreringer i mange store medicinalvirksomheder. Leverandøren er åben for auditering og kan på anmodning stille SOP’er for udviklingen af værktøjet til rådighed. Der er med andre ord tale om både et værktøj og en leverandør, der er rettet mod medicinalindustrien. 

Værktøjet er også funktionelt set absolut egnet til life science industrien. Det gælder for eksempel den grundige logning af alle aktiviteter. Der er ganske enkelt fuld sporbarhed på dokument- og metadata-niveau.

Strator har udviklet en proces og en dokumentationspakke til migration-center. Dette kan bruges som udgangspunkt for den validering og dokumentation, der kræves i dit QMS. Vi har forskellige skabeloner for best practice, som vi bruger til at indsamle de krav Vi har også en “håndbog” til migrationsværktøjet og et sæt skabeloner til IQ- og OQ-test cases.

8. Konklusion

Migrering bliver ofte undervurderet på bekostning af datakvaliteten eller udbyttet at et eventuelt nyt system. Migrering er i mange menneskers perspektiv “ligetil” eller “noget IT kan ordne”. Virkeligheden er, at det sjældent er tilfældet. Vi håber, at denne vejledning har hjulpet dig til at se mere klart på den migrering, du står over for, og til at forudse, hvor problemerne og udfordringerne kan ligge.

8.1. Erfaringerne bag

Vores konsulenter hos Strator har arbejdet som dokumenthåndteringsspecialister med et teknisk- eller proces-perspektiv gennem det meste af deres karriere. Nogle med helt op til 10-20 års erfaring. Vores anbefalinger, ’best practices’ og ikke mindst vores erfaringer med fejlhåndterede migreringsprojekter, stammer fra denne lange og kollektive erfaring.

Det er også derfor, at vi har besluttet at sætte migrering på en formel. Vi har samlet vores fælles erfaringer og skabt en driftsmodel med indbygget løbende forbedring. Vi henvendte os til fme AG og indarbejdede deres værktøj i vores metodologier.

8.2. Vil du vide mere?

Denne vejledning er vores forsøg på at dele vores erfaringer og metoder. Den er på ingen måde udtømmende, men vi håber du finder den nyttig.

Videnssektionen på vores hjemmeside indeholder artikler om ulemperne ved migrering, ‘do’s and don’ts’ og andre emner inden for håndtering, vedligeholdelse og flytning af dokumenter. Vi forsøger at dele vores erfaringer med det, vi gør bedst: Håndtering, organisering, klassificering og migrering af store mængder elektroniske dokumenter.

Besøg vores videnssektion for yderligere information, og du er naturligvis velkommen til at tage kontakt – dine spørgsmål er velkomne.