Den første test er enkel: tag ét kritisk system, eksporter en afgrænset del af data, og åbn resultatet et andet sted. Den kræver intet projekt og ingen bevilling, og den fortæller mere end en lang gennemgang af kontrakten. Det eneste, I behøver, er en, der ved, hvor eksportfunktionen er, en time eller to, og en systemejer, der ved, at det sker.
Dansk Industri nævner i sin vejledning om plan B, at virksomheden “har testet, hvordan data kan eksporteres og importeres”. Den sætning findes mange steder, men få beskriver, hvordan det gøres. Her er fremgangsmåden. Den er generel viden, og I tilpasser den til jeres system.
Formål
Testen skal svare på tre spørgsmål. Kan vi få data ud selv? Kan andet end det oprindelige system læse dem? Hvor lang tid tog det? Svarene gør en antagelse i planen til en iagttagelse. Testen siger intet om hele vejen ud, kun om det første led holder. Det næste led er gendannelse et andet sted.
Forudsætninger
- Et system, der er vigtigt, men ikke det sværeste. Et lidt enklere system giver et hurtigt resultat.
- En person med rettighed til at eksportere. Kræver det en administrator, er det i sig selv et fund.
- En systemejer, der er orienteret.
- Et sted at lægge filen med adgangskontrol. Rummer eksporten persondata, er det stadig persondata, så vælg en lille del, og følg persondata på vej ud.
- Et blik i vilkårene, så I ved, at eksporten er tilladt og ikke rammer en kvote.
Fremgangsmåde i trin
- Skriv kriterierne. Se næste afsnit. Det tager ti minutter.
- Vælg omfang. Tag en datatype, der betyder noget, fx kunder med ordrer for et afsluttet år.
- Find tallene i kilden. Notér antal poster, før I går i gang.
- Start uret, og eksporter. Brug den vej, I ville bruge i en reel situation, gerne den funktion, der står i leverandørens dokumentation. Skriv, hvad der blev klikket på, og hvilke rettigheder det krævede.
- Stop uret, når filen ligger hos jer. Notér størrelse og format.
- Åbn filen et andet sted. Brug et regneark, en teksteditor eller et andet almindeligt værktøj. Læs den.
- Sammenlign. Tæl posterne. Tag fem konkrete poster, og se dem i systemet ved siden af filen.
- Prøv at importere. Findes der et testmiljø eller en prøvekonto hos en anden løsning, så forsøg at indlæse en lille del. DI’s sætning nævner begge veje, og importen viser tit, hvor formatet driller.
- Ryd op. Slet filen, når notatet er skrevet, eller læg den et aftalt sted.
Findes der ingen eksportfunktion, er det resultatet af testen. Så er næste skridt at spørge leverandøren, og der findes en måde at gøre det på, uden at det lyder som en opsigelse: sådan spørger I leverandøren om exit.
Kriterier, skrevet på forhånd
Skriv kriterierne, inden eksporten startes, så I ikke tilpasser dem til resultatet. For den første test er fire nok:
- Antallet af poster i filen svarer til antallet i kilden.
- De fem udvalgte poster er korrekte, også datoer og danske tegn.
- Filen kan læses uden det oprindelige system.
- Den, der lavede testen, kan gentage den alene ud fra sine egne notater.
Det er helt i orden, at testen dumper. Formålet er at finde ud af det, mens det er billigt. Mere om kriterier står i hvad er en bestået test?.
Det, der skrives ned
Et halvt ark er nok: system, dato, hvem der gjorde det, datatype, omfang, antal poster i kilde og fil, format, tidsforbrug, nødvendige rettigheder, de kørte trin, hvad der gik godt, hvad der manglede. Beregn også, hvor lang tid den samlede eksport ville tage, hvis tempoet holder, og læg det ind i tiden for overførslen. Skriv desuden ét forslag til næste test. Notatet er det første bilag til planen, og felterne kan vokse til en testrapport.
Hvem der godkender
Ingen behøver give lov til testen ud over den, der svarer for systemet. Resultatet skal til gengæld læses af nogen. Systemejeren skriver under på, at notatet er retvisende, og den, der ejer exit-planen, afgør, hvad fundene betyder. Rummer de en mangel, der kræver penge eller en kontraktændring, skal det videre til ledelsen. Fundene hører med på exit-status til ledelsen.
Hvad det kræver, og hvad det koster at lade være
Testen kræver et par timer for én person og en halv time af systemejeren. Skriv en lav og en høj vurdering, når I ruller den ud på flere systemer, og sæt dato på. Det kan blive lidt mere, hvis rettigheder eller adgang skal skaffes.
Uden testen hviler planen på det, der står i salgsmaterialet og kontrakten. Det koster jer intet, indtil dagen kommer, og da er en fejl dyr, fordi tiden er knap. Sammenhold de to timer med jeres eget tal for en dag uden systemet. DI’s undersøgelse fra marts 2026 blandt 357 medlemmer viser, at to tredjedele enten slet ikke eller kun i mindre grad kan skifte forretningskritiske systemer uden større barrierer, og en test er en hurtig måde at finde ud af, hvor I selv står. Testen giver desuden noget, selv om intet flytter: et konkret svar, når kunder og bestyrelse spørger.
Det skal I lade være med
- At vælge det sværeste system først · så når I aldrig til et resultat.
- At lade leverandøren lave testen for jer · den skal vise, hvad I selv kan.
- At lade filen ligge bagefter · en glemt eksport er en risiko.
Det skal planen kunne vise
- ☐ Dato og resultat af den seneste eksporttest pr. kritisk system.
- ☐ Kriterier, der blev skrevet før testen.
- ☐ Format, tidsforbrug og nødvendige rettigheder.
- ☐ Fund og hvad der er besluttet om dem.
- ☐ Hvem der har godkendt notatet.
- ☐ Hvornår testen gentages.
Kilder
- DI: Plan B for kritiske teknologier. Brancheorganisation, sekundær kilde.
- DI Analyse, maj 2026: spørgeundersøgelse blandt 357 virksomheder, 25. til 31. marts 2026, s. 4 og 6.
Senest gennemgået: november 2026.
Næste skridt
Sæt to timer af i denne uge, vælg ét system, og kør trinene. Gå derefter videre til gendannelse, eller lad ledelsen afgøre, hvor meget der skal testes.
Læs også: Er det hele kommet med? · Det, der mangler i eksporten
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
