Digitale dokumenter udfordringer

Guide til dokumentmigrering

TAGS:

Nyt system! Vi mangler bare at få dokumenterne overført fra det gamle system. Det er bare ikke  helt så enkelt, som man troede. Projektet forsinkes, brugerne kan ikke finde dokumenterne, data er mistet osv. Måske kan guiden her hjælpe dig med at undgå netop det.

·

Introduktion

 

Denne guide dækker migrering af dokumenter. Migrering af dokumenter afviger på en række punkter fra migrering af (strukturerede) data, og netop disse forskelle fører jævnligt til fejlvurdering af en forestående dokumentmigrering. Vi gennemgår en migrering fra A til Å.   

Alle brancher - også de regulerede

Vores erfaringer og de metoder, vi har udviklet og deler her, stammer i høj grad fra den svært regulerede farmaceutiske industri. Vi vælger dog her at forklare vores metoder bredt anvendeligt, og noterer blot i bemærkninger steder, hvor der er særlige forhold i de regulerede virksomheder. Desuden afslutter vi med et afsnit, som kun er interessant for regulerede virksomheder. 

Dokumenter migreres i forskellige situationer

  • Et nyt system på vej, og indholdet fra det gamle skal lægges ind i det nye. Det kalder vi systemmigrering 
  • En større leverance af dokumenter fra en leverandør eller samarbejdspartner skal ind i egen løsning. Det kalder vi import 
  • Dokumenter fra en kørende løsning skal flyttes i arkiv. Det kalder vi arkivering.   

Guiden tager udgangspunkt i det, vi kalder systemmigrering, men i praksis vil forskellen i metode være ret lille mellem de tre. 

Hent den sidst nye guide

Guiden opdateres løbende her på vores website, og du er altid velkommen tilbage efter en PDF-udgave af seneste version. Hvis du abonnerer på vores nyhedsbrev, vil du sammen med nyt om andre faglige artikler fra vores hånd, modtage oplysninger betydelige opdateringer til vores guides. 

Indholdsfortegnelse

Man touching a data connection concept on a touch screen with his finger

Nyt system lige på trapperne

 

Det nye system er på trapperne. Forretningsbrugerne har været involveret i at ønske, designe og etablere den nye løsning og glæder sig til at tage det i brug. Fokus har været på forretningsprocesser, funktionalitet og brugervenlighed. Det skal det også være.

Historikken

Men der er også historikken i det gamle systemNogle dokumenter skal måske på arkiv, andre kasseres kontrolleret – det kan vi tage os af efter go-live på det nye system. Lige nu skal vi have migreret de dokumenter, som skal med over i det nye system på en mådeså de i det nye system kan findes, bruges og versioneres.

Modtagelsen af det nye system

Det er væsentligt for modtagelsen af det nye system, at dokumenterne kommer derover på en måde, som gør det nye system ret. Vi har i ærgerlige tilfælde set, at ellers udmærkede systemer simpelthen erklæres ubrugelige af brugerne, fordi de ikke kan finde og bruge deres dokumenter efter migrering. Det skal ikke ske. 

Nyt system – all inclusive

Men det er der heller ingen grund til at tro, vil ske. Leverandøren af det nye har ofte tilbudt en god deal på migrering, hvor de har lovet at importere dokumentere lige inden go-live, hvis blot I leverer dokumenter og metadata i et specielt format. Så nu har vi en plan. 

Se tidligt migreringen i øjnene

Indtil nu lyder det meget tilforladeligt. Leverandøren skal blot lige inden golive have udleveret en masser filer og nogle regneark. Og nogle gange er det faktisk heller ikke værre end det. Men desværre ser vi jævnligt – når vi så tilkaldes – at det ikke gik så let. Hvad er det så, der kan være årsagen, og hvordan undgås det?

Dokument

Komplekst og kritisk

Dokumentmigrering har nogle aspekter som er særligt komplicerede, og disse hænger i høj grad sammen med forskellen på dokument- og datamigrering. Det er centralt at forholde sig til, at et dokument består af flere dele – en (eller flere) indholdsfil(er) og de metadata, som beskriver det. Nogle af disse metadata er blot beskrivende og bruges til fremsøgning. Andre metadata må betragtes en integral del af dokumentet, idet de dokumenterer, at dokumentet er autentisk for eksempel. Der er rigtige og forkerte måder at behandle dokumenter med metadata på, og det kan du læse mere om i denne artikel. 

Dokumenter ikke bare er filer med metadata, men der er også relationer til andre dokumenter. Andre versioner, andre formater, andre akter på samme sag osv. Dertil handler det ofte om store voluminer. Fordi der er store mængder, og det dermed tager tid, kompliceres det hele yderligere af, at man ofte må migrere i etaper. Migrering er en kompleks operation. 

Migrering er ikke bare komplekst – det kan også være virkelig alvorligt, hvis processen ikke er kontrolleret nok til, at man bagefter har dokumenter med integriteten bevaret. Migrering er en kritisk operation. 

Datakvalitet og oprydning

Den historiske dokumentation kalder ikke på samme opmærksomhed, som det nye spændende system. Forståeligt nok, men ærgerligt. Det er nemlig en helt fantastisk mulighed for at få ryddet op og få rigtig høj kvalitet af data i det nye system, og det vil smitte positivt af på systemet.  

Selvom det gamle system er brugt med omhu, så viser der sig ofte – vi tør næsten sige altid – at der alligevel er noget, der ikke er, som man troede i data. Måske er en væsentlig mængde dokumenter arkiveret under ”diverse”, måske er dokumenter helt uden fremtidig værdi arkiveret, måske er ejeren på dokumenterne for længst fratrådt osv. Nogle af disse ting er småting, men typisk er mængden af den slags ting overvældende og det gør at det med at levere regnearket og filerne til systemleverandøren vokser over ørerne på projektet.

tied folders

Hvad kan man så gøre?

Først og fremmest er det en god ide at komme i gang tidligt og dedikere folk til opgaven. I næste afsnit vil vi nævne, at det ikke er helt ligegyldigt, hvilke folk.  

Men dertil må man kigge dybere i sine dokumenter og data, og de forhold de skal flyttes under. De tre artikler vi linker til i afsnittet om kompleksitet og kritikalitet ovenfor, kan meget vel læses med det formål at blive inspireret til at identificere hvor i din egen migrering, noget komplekst eller kritisk kan ligge og vente.  

Er det for tungt at læse her?

Klik for at få guiden i PDF

Sæt det rigtige hold

 

Ofte følger en migrering implementeringen af et nyt system, og ofte bliver migreringen en opgave i implementeringsprojektet, som “IT skal tage sig af”.

Selvom der er rigtigt meget og tung IT i en migrering, er det ikke en god idé, at betragte en migrering som en IT øvelse. Det er mest af alt en forretningsøvelse, hvor værdien skabes, ved at der på helt systematisk vis bliver taget stilling til dokumenter og data og renset og beriget dem i forløbet.  

En migrering har brug for en bred pallette af viden: 

  • Teknisk kundskab til den gamle system og til det nye system 
  • Forretningsforståelse for brugen af den gamle system og tilsigtet brug af det nye system 
  • Kendskab til organisationens master data 
  • Kendskab til de regler og regulativer, som virksomheden er underlagt (særligt for stærkt regulerede virksomheder) 
  • Dokumentfaglig viden 

Ofte udnyttes det ikke, at der sidder en arkivar, records manager eller informationsspecialist et sted i organisationen, men det er her og nu i migreringen, at en kompetence som den for alvor skal i spil. Modsat resten af holdet vil denne typisk rent faktisk interessere sig voldsomt for den historiske dokumentation – og der er virkelig brug for den kompetence. 

Migrerings faser

 

Virkeligheden omkring migrering indeholder et væld af trial and error og tilbagevenden til overraskelser i data. Den virkelighed kommer vi ikke udenom, men vi opdeler migreringen i faser, og derved sikrer, at vi ret systematisk når fra A til B. Vi synes at strukturen er en stor hjælp, men deskal bruges med en forståelse af virkeligheden som den er; der dukker helt sikkert noget op man må analysere selvom analysefasen for længst er færdig osv.  

Som figuren viser, består vores struktur af en foranalyse og et metode- og teknologivalg baseret på udkommet af foranalysen. Rundkørslen i figuren skal illustrere at analyse, konfiguration og afprøvning af den metode og teknologi, man har valgt, er noget der foregår iterativt. Når afprøvningen er lovende fortsætter den mere formelle proces med test, og hvis den er tilfredsstillende, er man klar til at udføre migreringen. Afslutningsvist følger rapporteringen. Hver fase gennemgås i det følgende.

Foranalysen

 

Formålet med foranalysen er at finde frem til hvilke overordnede krav migreringen skal leve op til således, at der kan træffes oplyste valg med hensyn til teknologi og metode.

En foranalyse kan godt blive meget lang, for der er hele tiden mere at analysere. Men man må sætte sig nogle klare mål og stoppe, når man ved nok til at kunne træffe en beslutning.

De emner, man typisk vil skulle berøre, er: 

  • Cirka hvilket scope (hvilke dokumenter og data) 
  • Overordnede tekniske og strukturelle forskelle på kilde- og modtagesystem 
  • Fornemmelse for datakvaliteten i source systemet 
  • Regulatoriske krav 
  • Hvordan skal modtagesystemet skal tages i brug (fx gradvist eller big bang)  
  • Forretningsmæssige krav fx vedr. timing, mulig nedlukning osv 
  • Økonomiske, ressourcemæssige eller tidslige begrænsninger 

Metode- og teknologivalg

 

På baggrund af foranalysen besluttes, hvordan man vil migrere. Tre hovedspørgsmål skal besvares.

Teknologi – Vil man bruge et migreringsværktøj, eller er det dump and load eller kode-selv osv.

Opdeling af migreringen –  Skal migreringen være en big bang eller faseinddelt, og i givet fald hvordan. Skal alle objekter af bestemte typer flyttes eller er der andre mere logiske inddelinger.

Kvalitetssikring – Hvordan vil vi kvalitetssikre vores migrering (i life science= definere vores validation approach) og hvordan vi vil rapportere på migreringen.

Teknologi

I forbindelse med teknologivalget har vi følgende råd og erfaringer at dele: 

Hvis systemerne er strukturelt ens, fx at det nye system er en nyere udgave af det gamle system, så kan dump eller detach af databasen og load eller attach af databasen være en reel mulighed. I så fald er migreringsopgaven rent tekniskog nogle af ovenstående bekymringer vedrørende integritet og de rigtige kompetencer i projektet bliver gjort til skamme. 

En migrering er ganske vist eksport fra kilden og import til det nye system. Og ofte har leverandøren af det nye system tilbudt at importere til det nye system. I de tilfælde hvor leverandøren er i stand til at importere det, som I kan eksportere, er det fint. Så kan en eksportmulighed, som evt allerede findes i kildesystemet være den helt rigtigt løsning. 

Ofte er der dog nogle forskelle i de properties, der skal udfyldes i det nye system ifht dem, der var i det gamle system. Det betyder at metadata skal transformeres i processen. Der kan også være et reelt behov for berigelse eller oprydning i forbindelse med migreringen. Hvis det er tilfældet, anbefaler vi at benytte et kommercielt værktøj, som er lavet til at håndtere mapning af properties og transformationer af metadataværdier. IT-afdelingen vil nok kunne tilbyde at udvikle noget, men kun i de relativt enkle tilfælde kan de betale sig ifht at købe et eksisterende værktøj. 

Afhængig af hvilke platforme, der skal migreres til og fra, er der et varieret udbud af værktøj i markedet. Vi har en favorit, som vi gerne tyr til, hvis ikke omstændighederne taler for noget andet. Det er værktøjet migration-center fra den tyske virksomhed fme AG, som vi af samme grund har indgået et partnerskab med i Skandinavien, således at vier deres forlængede arme her i forhold til at rådgive om migrering. I rigtigt mange tilfælde er det værktøj et rigtigt godt bud. Det har en bred vifte af teknologier, det som standard kan forbinde til. Dertil har det al den funktionalitet vi har haft brug for ifht mapning og transformation og rapportering

Opdeling af migreringen

Der er fysiske grænser for hvor meget data der kan flyttes på en given tid. Vi ser, at det ind imellem ikke i praksis er muligt at lukke ned fredag aften, migrere over weekenden og være klar mandag morgen. Det er ellers meget ofte ønsket. Der kan også være andre grunde til, at migreringen må brydes ned i mindre bidder, som fx at brugerne af det nye system kommer på i etaper og data skal migreres svarende dertil. Man vælger ofte også at undlade at migrere noget, der er i proces, men tillade, at det bliver gjort færdigt i det gamle system, og følger så op med en opsamlingsmigrering efter en aftalt periode. Først herefter lukkes det gamle system så helt. 

Man ender altså meget ofte med at skulle migrere i etaper, og det øger kompleksiteten af migreringen, idet man skal kunne holde styr på hvad der er migrering og håndtere evt. ændringer til dokumenter i det gamle system, siden man migrerede sidst. Værre bliver det, hvis man er nødt til at tillade at dokumenter potentielt kan ændres i begge systemer af to forskellige brugergrupper, og de skal synkroniseres. Det bør undgås, hvis det overhovedet er muligt, for kompleksiteten er vanvittigt høj.  

Beslutningen man her skal træffeer altså, hvordan man vil underinddele migreringen i del-migreringer – eller om man vælger big bang. Hvis der skal underinddeles, er det sædvanligvis en god indikator for at der er behov for et kommercielt migreringsværktøj.

Kvalitetssikring

Hvis de dokumenter, man har med at gøre, er records, er migrering en kritisk handling. Her lader vi det blive ved påstanden, men artiklerne refereret i afsnittet ”Komplekst og kritisk” ovenfor, forklarer og begrunder påstanden. 

Det betyder, at vi skal have et apparat op at stå, som sikrer – og kan dokumentere – at dokumenterne er korrekt migreret. Der er to spor til det: 

  • Det ene er at sikre at metoden og teknologien er testet og virker korrekt  
  • Det andet er at kvalitetssikre og dokumentere migreringens udførsel  

Hvis teknologien er hjemmelavet, vil testarbejdet naturligvis være ganske omfangsrigt.

Er det for tungt at læse her?

Klik for at få guiden i PDF

Analyse, konfiguration og afprøvning

 

Denne fase består af, at man konstant undersøger, prøver af og forbedrer indtil, man opnår det resultat, man ønsker.

  1. Det første, der skal arbejdes på, er at kunne afgrænse den delmængde af kilden, som man ønsker at migrere. Det kan fx være alle dokumenter af en bestemt typefra en bestemt afdelingi en bestemt tilstand, relaterende til bestemte produkter eller sager eller meget andet.  
  2. Det næste, der skal styr på, kalder vi klassifikationsmapning. Det dækker over, hvordan objekter i det ene system og det andet system passer sammen. Ofte opererer systemerne med nogle grundlæggende typer af dokumenter, og det er dem, vi skal matche i nyt og gammelt system. I det gamle system opdeler vi måske logisk vores system efter typen af rapport, mens i det nye system opdeler vi logisk efter hvilken type produkt rapporten beskriver.  
  3. Derefter skal fokus på properties på hver af de ovennævnte klasser eller typer. I det gamle system var der fx en “title” på en rapport, mens i det nye hedder det “name“. Den værdi, der står i title skal blot mappes til name således, at værdien under import sættes ind i name propertien. Men det kan være – og er typisk – langt mere komplicerede regler og transformationer, der er tale om. Nogle gange giver reglen, når den møder dokumentets metadata ikke det forventede resultat. Reglen kan selvfølgelig være forkert, men oftest er det nu fordi det viser sig, at der er en del af dokumenterne, der alligevel er anderledes, end man troede. Typisk opdager man så at reglen skal være lidt anderledes for en undergruppe. 
  4. Endelig er der værdierne. I mange properties er der en liste af tillade værdier. Ugedagene, månederne, lande, produktnumre, kundenavne osv. Det betyder at de værdier man migrerer ind i pågældende property gerne skulle passe med de tilladte. Det kan føre til at der er behov for at mappe værdierne i hver værdiliste (banalt eksempel: Mandag skal blive til Monday, Tirsdag til Tuesday osv.) Resultatet af denne fase er, at de her regler og mapninger fungerer for den eller de delmængde(r), man har arbejdet med.  I det værktøj vi ofte bruger, er der en mulighed for at simulere en migrering. Det er en rigtig rar ting. Først og fremmest har man haft mulighed for at indsamle al information fra kildesystemet og eksperimentere med det uden at forstyrre kildesystemet imens. Når man har sat sine regler op, kan man påtrykke dem på alle dokumenter i den delmængde man arbejder med og se resultatet. Opførte det sig, som jeg forventede? Og uden af afsløre en stor hemmelighed kan jeg røbe, at svaret er nej de første rigtigt mange forsøg. På et tidspunkt får man brug for at få resultatet kontrolleret af andre, som måske har mere forstand på det faglige omkring dokumenterne, og da er det bekvemt, at man kan tække sine simuleringer ud i regneark. På et tidspunkt er man tilfreds, og så kan man gå videre til at forberede endnu en gruppe dokumenter, eller også går man videre og gør klar til at importere disse dokumenter i modtagesystemet. 
  5. Næsten. Vi er simpelthen nødt til at overveje, om vi har brug for en strategi for roll back. Skal der fx konstrueres et script som fjerne og rydder op efter en fejlslagen migrering.

Formel test / pilot

 

Hidtil har vi afprøvet og tjekket resultatet. Nu gælder det en formel test, som fører til, at vi er klare til starte migreringen. Hvad en formel test så bør indeholde, er brancheafhængig og meget afhængig af teknologi- og metodevalg.  

Det vil være almindeligt at lave en pilotmigrering, hvor få, men repræsentative dokumenter migreres i en mængde, så man kan gå dem efter i sømmene og sikre, at der sker det, man håber. Og det bør typisk ikke være teknikerne og forretningsanalytikerne, der har siddet med migreringen, der tester her. Det bør være forretningen. Det kan opfattes som en bruger accept test (user acceptance test) af resultatet af migreringen – fuldstændigt som man typisk laver en sådan accept test af selve systemet.

I den farmaceutiske industri må man forvente at skulle kvalificere teknologi og metode og derefter validere migreringen. Her er vi så nået til kvalifikationen. Strator har skabeloner klar til både IQ, OQ og PQ/UAT, som kan tilpasses omstændighederne og jeres QMS.

GxP

Resultatet af dette – uanset branche og form – er naturligvis, at vi tør starte vores migrering.  

Migrering

 

Det er nu tid til at igangsætte selve migreringen. Der kan være tale om en big bang migrering, hvor vi lukker det gamle system for bestandigt fredag aften og åbner det nye mandag morgen, og i mellemtiden er migreringen foretaget. 

Oftere er det tilfældet, at migreringen består af mindre migreringer. Måske er det muligt at migrere alle godkendte versioner af dokumenter i god tid inden det nye system tages i brug, og så følge op med en anden migrering som indeholder de dokumenter, der er kommet til siden.

Uanset, vil man ofte have en lukkeweekend, og i løbet af weekenden få klaret migreringen og lukket for det gamle system eller dele af det gamle system. 

Så kort fortalt handler denne fase om at gøre det vi har øvet os på – migrere dokumenterne og teste, at det gik godt. 

I nogle situationer skal man have en stram tidsplan kørende og have regnet sig frem til, hvornår det er sidste chance for en tilbagerulning. Det er en faldgrube i tilfælde af problemer at blive ved med forsøge at løse problemer så længe, at man ikke kan nå at have et system fungerende mandag morgen. Der kan ikke siges noget generelt om det, andet end at være opmærksom på om det kunne være et problem i dit tilfælde. 

Der kan også være nogle obligatoriske skridt i udførslen fra et kvalitetssikringssynspunkt. Fx vil man typisk kræve at migreringen er testet og godkendt inden man tillader at åbne for adgang for brugerne til de nyet system.

Man må desuden være klar til at håndtere, at der vil være dokumenter, der fejler. Der vil altid ske noget, og det er centralt at man på forhånd er klar over, hvad man gør ved det. Ofte vil man samle dem op i en liste og slutte migreringen af med en mangelliste, som man så håndterer bagefter, men der kan være grunde til at det ikke er en god praksis.

Rapportering

 

Efter migreringen er det god praksis at samle dokumentation for migreringens gennemførsel. I mange sammenhænge vil det være et eksplicit krav.  

Dokumentationen kan blandt andet være en log fra den teknologi, man har brugt. Ideelt set dokumenterer denne hvilke transformationer data har gennemgået undervejs og viser, at indholdsfilerne i modtagesystemet er identiske med dem i kildesystemet. Her kan fx en checksum komme i anvendelse.  

Andet relevant rapportering er dokumentation af testen af den endelige migrering, og hvor relevant også dokumentation fra den fase, hvor vi formelt testede systemet.  

Al denne dokumentation bør gemmes. Den udgør nemlig beviset for, at dokumenterne har bevaret deres integritet under migreringen.

Er det for tungt at læse her?

Klik for at få guiden i PDF

Migration-center

 

Som nævnt tidligere i guiden har vi et favoritværktøj, som vi benytter / foreslår, når det er relevant. Det hedder migration-center og ejes af den tyske konsulentvirksomhed fme AG. 

Ligesom os i Strator har fme AG historisk arbejdet meget med den store dokumentplatform Documentum

Migreringsværktøjet er oprindeligt udviklet til at migrere dokumenter ind i Documentum, og vi i Strator har som sådan kendt det i rundt regnet 15 år.

migration-center service partner

Det er ikke nogen skidt oprindelse at have. Documentum er en meget stor platform som understøtter meget komplekse sammenhænge mellem dokumenter, så når værktøjet kan klare den kompleksitet, er der ikke meget på markedet, det ikke kan understøtte. Dertil har Documentum historisk været meget udbredt i den farmaceutiske industri, hvorfor værktøjet også i sin oprindelse har evnen til at leve op til strenge regulatoriske krav.

GxP

Værktøjet er nu blevet generaliseret og den begavede migrerings motor i kernen af toolet kan nu bruges med forskellige forbindelser mellem kilde og destination, de såkaldte migration paths.   

Værktøjet er – endnu – et gammeldags klient-server værktøj, der er lavet til at blive installeret indenfor kundens firewall. Det er nemlig indtil videre sådan, at kilden for en migrering sædvanligvis er on-prem (altså ikke cloud), og så får man den bedste hastighed ud af at have migreringsværtøjet ved siden af. Værktøjet opereres fra en klient, og bagved kører en migrerings server og en database.  

Værktøjet fungerer set fra operatør-synspunkt som herunder beskrevet.

Notebooks file transfer. Concept of information exchange

Skanning

  • Kilden skannes for dokumenter  
  • Al tilgængelig metadata for dokumenterne hentes ind i migreringsdatabasen fra kilden 
  • Man kan også vælge at hente selve dokumentfilen ind i migreringsværktøjets filsystem

Bearbejding

  • En delmængde af dokumenterne udvælges 
  • For den delmængde mappes metadata, og der sættes regler op for transformationer 
  • Der udføres en transformation, hvilket betyder at migration-center simulerer migreringen for den udvalgte delmængde og præsenterer resultatet  
  • Der udføres en validering, hvilket betyder at migration-center kontrollerer om de beregnede værdier er tilladte. Den vil altid tjekke, at datatypen er i orden, fx at der i et datofelt står en dato.  
  • Man har mulighed for at opsætte yderligere valideringsregler. Det kunne være at vi har en liste over afdelingsnavne, og kun disse må optræde i feltet for afdeling. Hvis man sætter sådanne regler op, kan migration-center tjekke for os og pointere de fejl, der måtte være.  
  • Man bliver ved med at rette regler og mapning, transformere og validere til man har et tilfredsstillende datasæt.  
  • Nu vil det give mening at få forretningskyndige på banen og validere, at de får, hvad de forventer.  
  • Man arbejder med og forbereder en delmængde af dokumenterne ad gangen – delmængder som gør det enklest muligt, at sætte regler op for hele delmængden.

Import

Efter utallige simuleringer er selvtilliden nu der, at man er klar til, at importen til destinationssystemet sættes i gang. Ifølge den faseopdeling vi præsenterede i tidligere i guiden, vil man her udføre den formelle test inden man skrider til at igangsætte importen.  

Når importen startes, er der grundlæggende to muligheder. Den ene er, at man importerer de data, som man indlæste ved skanningen. Den anden er, at man her ved importen beder systemet foretage en ny skanning, hente dokumenterne i deres tilstand lige nu og bearbejde dem efter de regler, man har sat op. Forskellen er om man skal og vil have det sidste nye med.

Undervejs i importen vil alle transaktioner blive logget, og loggen kan bagefter drages frem og formateres til en rapport over migrering.

Gate-model

Der er en finesse mere ved værktøjet, som er værd at fremhæve. Det er bygget op efter en gate model. Det betyder, at der er en stribe tilstande et dokument kan være i inde i migreringsværktøjet. Det kan fx være transformeret, valideret eller importeret, og det er umuligt for et dokument at blive valideret inden det er tranformeret, eller importeret inden det er transformeret og valideret.  

Dvs at migration-center holder styr på hvert eneste dokument for os, om det er klart til at blive importeret, og også hvordan det gik med importen. Når et dokument er fejlet ved migration-center det, og hvis du retter noget i en regel og kører din migrering igen, så vil den forsøge at migrere det dokument igen – men den undlader at migrere de andre, som allerede er migrering med succes. Det er en kolossal aflastning og støtte i den rent praktiske afvikling af migreringen.  

Screenshot 2020-09-29 at 11.59.37
Illustration by fme AG

Komplekst og stort værktøj

Migration-center er ikke et værktøj, man lærer at bruge på en dag. Det kan meget og er derfor også komplekst. Men med lidt assistance og træning fra folk som os, kan man selv blive i stand til at udføre sine migreringer, hvis man ønsker det.  

Nu bekommer det ikke os at skrive priser på andre virksomheders værktøjer, men giv ikke op på forhånd ved tanken om, at det nok er meget dyrt. Det var det, dengang det var eksklusivt til Documentum, men for de fleste er prisen en positiv overraskelse. Desuden gives nogle forskellige fleksible licensmodeller.

Life science

 

Det er særligt at håndtere GxPkritisk materiale. Så naturligvis kræver det særlig omtanke. Alt hvad vi ovenfor har gennemgået, gælder også her – eller måske bør formuleringen være i særdeleshed her.

GxP

Strator arbejder i princippet i alle brancher, men i praksis er life science vores hjemmebane. Det er i life science, at der især er behov for vores dybe ekspertise, og vi er vant til at forholde os til det regulerede miljø.  

Værktøjet migration-center, som vi oftest finder nyttigt, har været brugt i mange store farmaceutiske virksomheder. Leverandøren – fme AG – lader sig auditere og kan på forespørgsel fremvise SOP for udviklingen af værktøjet 

Det er med andre ord et værktøj og en leverandør, der er formelt egnet til life science.  

Funktionelt er det også særligt egnet til life science. Især den grundige logning vil vi fremhæve. Der er ganske enkelt fuld sporbarhed på dokumentniveau. Dertil kan værktøjet udføre en dokumenterbar test, hvor det efter migreringen smager på samme dokument i både kilde og destination og verificerer at de er identiske (ved checksum). 

Strator har så ovenpå – eller udenom – værktøjet udviklet dels en process med også en konkret en pakke med dokumentation, som kan bruges som udgangspunkt for den dokumentation, jeres QMS kræver. Vi har fx skabeloner til kravsindsamling til migreringen og til en operation handbook for migreringstoolet og til IQ og OQ.

Afslutning

Migrering er en disciplin, der ofte undervurderes til skade for datakvaliteten eller for et evt. nyt system. Migrering er i manges perspektiv “bare lige” og “noget IT kan fikse”. Virkeligheden er at det ikke ret tit er tilfældet. Hvis denne guide har bidraget til, at du ser den migrering, du står overfor tydeligere og fornemmer hvor, der kan ligge problemer gemt, så har den opfyldt sit formål.

Data Migration on Red Puzzle on White Background.

Erfaringen bag

Konsulenterne i Strator har arbejdet som specialister i styring af dokumenter fra en teknisk eller procesvinkel i vores nuværende og tidligere jobs, vi har fået grå hår (eller mistet håret) af de mange – typisk 15-20 – års erfaring med feltet. Vi har gang på gang set, at migreringer bliver fejlhåndteret.  

Til sidst blev vi enige om at sætte migrering på formel. Vi samlede vi alle vores erfaringer og skabte en model, som vi arbejder ud fra og konstant forbedrer. Vi rakte ud til fme AG, som mange af os kendte fra vores fælles fortid med systemet Documentum, og fik lov at bruge deres værktøj, der på fineste manér bakker op om vores behov for fuld kontrol i hele processen.

Vil du vide mere

Denne guide er et vores forsøg på at dele ud af vores erfaringer og metoder. Guiden er ingenlunde udtømmende, men dog forhåbentlig en hjælp for dig.  

Vores videnscenter indeholder flere artikler om genvordighederne ved migrering, konvertering og styring af dokumenter, og det problem du har, genfinder du sikkert et sted i videnscenteret. Gør du ikke, så kontakt os meget gerne – dine spørgsmål velkomne.  

Kurser

Vær opmærksom på at Scandinavian Document Control, der tilbyder uddannelse og kurser, med mellemrum udbyder kurser i dokumentmigrering, og jævnligt udbyder kurser i formalia omkring korrekt håndtering af dokumenter. Kursusvirksomheden er et fælles datterselskab mellem Strator og en anden specialistvirksomhed, Scandinavian Information Audit. Scandinavian Document Controls hjemmeside kan du muligvis finde kurser eller flere gratis materialer, der interesserer dig.

Holdet fra Strator ønsker dig:  

Held og lykke  

med din migrering

Værd at gemme?

Klik for at få guiden i PDF