Egne IT-folk kan teste det meste af det, der afgør, om en exit-plan holder: eksport, læsning af data uden for systemet, gendannelse af dele og overdragelse af viden. De er bundet på to punkter, som er tid ved siden af driften og adgang til det, leverandøren styrer. Derfor skal testene passes ind i driften med ledelsens opbakning, og planen må aldrig afhænge af én person.
Har I en intern IT-afdeling, er udgangspunktet bedre end hos de fleste. I kender systemerne og kan selv se, hvad der virker. Intern IT og exit-arbejde støder alligevel tit sammen, fordi planen handler om noget, der måske aldrig sker, mens driften kalder i dag. Forholdet mellem egne folk og outsourcing er behandlet under fordele og ulemper ved at outsource IT. Her handler det om, hvad der kan testes. Fremgangsmåderne er generel viden, og fordelingen er vores vurdering.
Det, egne folk kan teste selv
De fleste prøver kræver administratorrettigheder og en plan, og ikke meget andet.
- Eksport. Træk data ud, mål tiden, og læs dem. Se test en eksport nu.
- Fuldstændighed. Sammenlign antal, historik, vedhæftede filer og rettigheder med kilden. Se er det hele kommet med?.
- Gendannelse et andet sted. Læg en kopi op i et adskilt miljø, så produktionen ikke berøres. Se gendannelse et andet sted.
- Integrationer. Find ud af, hvad der stopper, når ét system falder bort, uden at slukke noget. Gennemgå logs og opsætning.
- Login. Afprøv, om I kan komme ind i de vigtigste systemer, hvis den centrale loginløsning er væk.
- Skrivebordsøvelse. Sæt systemejeren og to teknikere om et bord med et scenarie, se skrivebord, delvis eller fuld.
Det hele kan laves i små bidder. En times prøve om måneden giver mere end et stort projekt, der aldrig finder plads.
Det, de ikke kan teste alene
Nogle ting ligger uden for jeres hænder, også med dygtige folk.
Leverandørens side af sagen kan I kun få oplyst. Det gælder gendannelse af platformen, tider for dataudtræk og den bistand, I har krav på. Skriv det i planen som oplyst og adskilt fra det, I selv har målt. Det samme gælder en tjeneste, I ikke driver, se gendannelse i SaaS.
Forretningens side kræver forretningen. Teknikere kan vise, at data er kommet over. Kun brugerne kan sige, om arbejdet kan udføres med dem. Sæt en bruger på testen, og lad vedkommende godkende resultatet, se brugerne i planen.
Kontrakten er en tredje grænse. Egne IT-folk bør læse den for tekniske vilkår, og de skal ikke afgøre juridiske spørgsmål. Dem giver I videre til en advokat.
Når driften tager pladsen
Den reelle hindring er sjældent viden. Testene taber til det, der brænder, og det gør de hver uge, hvis ingen har sagt andet. Tre greb hjælper.
Læg testene i årshjulet, med faste uger og et navn, se årshjul for exit. Læg dem sammen med noget, der alligevel sker. En opgradering, en ny testkopi eller et servicevindue kan bære en prøve med. Få ledelsen til at bekræfte timerne, så det er aftalt, at driftsopgaver kan vente en dag.
Vælg også, hvornår og hvor testen må køre. Egne folk kender belastningen og de stille timer bedst. Se test uden at forstyrre driften.
Når planen hviler på én person
Her gemmer der sig en afhængighed, de fleste overser. Mange exit-planer hviler på den ene tekniker, der har bygget integrationerne. I har flyttet risikoen fra leverandøren til en medarbejder, og den er mindst lige så reel. Vedkommende kan sige op, blive syg eller holde ferie den uge, det gælder.
Lad derfor en anden end systemets ekspert køre testen ud fra planen, uden hjælp i lokalet. Det er den bedste prøve på, om teksten kan bruges. Alt, der må spørges om, skal bagefter skrives ind. Tjek samtidig disse punkter.
- Står alle konti og nøgler i en fælles boks, så de kan hentes af mindst to?
- Findes scripts og opsætning i et fælles arkiv, og ikke på én maskine?
- Er der beskrevet, hvad integrationerne gør, i et sprog en ny kan læse?
- Har to personer prøvet hver kritisk procedure?
Den samme øvelse gør det lettere at tale om. Ingen skal føle sig mistænkt for noget. Der er tale om almindelig omtanke, og de fleste teknikere er glade for at slippe for at være den eneste.
Hvem skal godkende?
Egne folk bør ikke både skrive, teste og godkende. Systemejeren godkender resultatet, og den, der ejer planen, afgør, om det er godt nok. Hvem det er, står i hvem ejer exit-planen?. Skriv resultatet i testrapporten, så det kan bruges uden at spørge teknikeren bagefter.
Hvad det kræver, og hvad det koster at lade være
Regn i timer for hvert system, og skriv et lavt og et højt tal med dato. Posterne er forberedelse, kørsel, en brugers tid, miljøet til test og oprydning. Skriv dem i jeres eget ark. Den skjulte post er det, der ikke bliver lavet imens, så spørg driften, hvad der skubbes.
Springer I testene over, tror I, at I kan noget, som ingen har prøvet. Regn på to udfald i egne tal. Hvad koster det, hvis eksporten ikke virker den dag, I har brug for den? Hvad koster det, hvis den ene tekniker er væk? Hold det op imod de timer, testene tager. Arbejdet betaler sig også, selv om I bliver hos leverandøren, for dokumentationen gør afløsning, ferier og nye medarbejdere lettere.
Det skal I lade være med
- At lade eksperten køre sin egen test · så prøver I personen frem for planen.
- At lægge test oven i driften uden aftale · så forsvinder de ved første hændelse.
- At kalde en teknisk succes for et bestået resultat · en bruger skal have sagt ja.
Det skal planen kunne vise
- ☐ Hvilke tests egne folk kører, og hvornår.
- ☐ Hvad der er målt, og hvad leverandøren har oplyst.
- ☐ Mindst to personer, der kan hver kritisk procedure.
- ☐ En test kørt af en anden end systemets ekspert.
- ☐ Godkendelse fra en bruger og fra systemejeren.
- ☐ Timer aftalt med ledelsen.
Senest gennemgået: november 2026.
Næste skridt
Vælg den enkleste test til det vigtigste system, og lad en anden end eksperten køre den i næste måned. Skriv det, der måtte spørges om, ind i planen, og sæt næste test i årshjulet.
Læs også: Exit-plan for en IT-chef uden tid · Hvem gør arbejdet?
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
