En exit-plan holdes opdateret med to mekanismer: en fast gennemgang på en dato, I selv vælger, og en ekstra gennemgang, når noget bestemt ændrer sig. Én navngiven person ejer begge dele og får systemejeren til at bekræfte, at planen stadig passer.
En plan, der lå rigtigt i fjor, kan være forkert i dag, uden at nogen har gjort noget galt. Systemer vokser, kontrakter fornyes, og folk skifter job. Opdatering af exit-planen er sjældent en stor opgave. Den skal blot have en plads i kalenderen, for ellers bliver den glemt, indtil nogen spørger.
Det, der forælder planen
De fleste planer bliver forkerte på de samme steder:
- Integrationer. En ny kobling er hurtigt lavet og kommer sjældent på listen.
- Kontrakten. Fornyelse, nye vilkår, et nyt bilag eller en ændret bindingsperiode ændrer tider og muligheder.
- Personer. Den ansvarlige, stedfortræderen eller kontakten hos leverandøren er stoppet.
- Data. Mængder og typer vokser, og nye moduler lægger nye data i systemet.
- Leverandøren. Ejerskifte, nye underleverandører, nye versioner og ændrede eksportfunktioner.
- Forretningen. En funktion er blevet vigtigere, tolerancen er ændret, eller en kunde er kommet til med nye krav.
- Formater og værktøjer. Eksporten, I testede sidste år, findes måske ikke i samme form.
Den faste gennemgang
Hvor ofte I skal gennemgå planen, afgør I selv. DORA gælder kun finansielle enheder, men er en brugbar model. Art. 28, stk. 8, nævner regelmæssig gennemgang og test i tilstrækkeligt omfang og sætter intet interval for exitplaner. Den delegerede forordning 2024/1773 bruger i art. 10 ordene “periodisk gennemgang og test”. Sitets egen vurdering er, at de fleste kan nøjes med én fast gennemgang om året for hvert kritisk system, og oftere for det, der ændrer sig meget.
En gennemgang kan klares på et enkelt møde. Den, der ejer planen, og systemejeren læser felterne igennem og stiller fire spørgsmål:
- Er noget i planen forkert i dag?
- Er noget tilføjet, som ikke står der?
- Passer tiden ud stadig med varsel og tolerance?
- Er overslaget stadig troværdigt?
Rettelser laves på stedet. Større fund får en ansvarlig og en dato. Gennemgangen afsluttes med ny dato i dokumentet, og med hvem der har set den.
Ekstra gennemgang ved ændringer
Faste datoer fanger ikke det, der sker mellem dem. Skriv derfor en kort liste over hændelser, som fører til, at planen åbnes:
- Kontrakten fornyes eller ændres.
- Leverandøren meddeler opkøb, ny version eller udfasning.
- Et større system kobles på, eller et modul tages i brug.
- Systemejeren eller planens ejer stopper.
- Et længere nedbrud eller en sikkerhedshændelse rammer leverandøren.
Knyt listen til de steder, ændringerne alligevel passerer. Lad indkøb og IT stille spørgsmålet “skal exit-planen rettes?” ved hver ny aftale og større ændring. Det er langt mere pålideligt end at bede nogen om at huske det. Mange af de samme hændelser er udløsere i selve planen, og forskellen er, at her skal planen blot ses igennem.
Hvornår der skal testes igen
Test og opdatering er to forskellige ting, men de hænger sammen. Niveauet vælges efter skrivebord, delvis eller fuld test. Test igen, når noget af dette gælder:
- Eksportvejen, formatet eller leverandørens værktøj er ændret.
- Datamængden er vokset, så den målte tid ikke længere holder.
- Modtagersystemet eller stedet for gendannelse er skiftet.
- Den sidste test havde fund, der nu er rettet.
- Det aftalte interval er gået.
Lad resultatet gå tilbage i planen. En tid, der er målt, afløser et skøn, og overslaget får ny dato. Det er her, planen bliver bedre, år for år.
Hvem gør hvad
Planens ejer holder kalenderen, indkalder og samler rettelser. Systemejeren bekræfter, at forretningens tal stadig passer. Den IT-ansvarlige retter integrationer og tekniske felter. Kontraktejeren melder fornyelser og nye vilkår. Ledelsen får en kort status på én side og godkender ændringer i tolerance.
Har I ikke egne IT-folk, kan IT-leverandøren bidrage med de tekniske felter. Ejerskabet skal stadig ligge hos jer.
Læg tre ting ét sted: gældende version, ændringslog og seneste testrapport. Versionsstyring behøver ikke være mere end en dato i filnavnet og en linje om, hvad der er ændret. Trinnet er beskrevet kort på digital-suveraenitet.dk, og her er det årets arbejde, der står skrevet ud.
Hvad det kræver, og hvad det koster at lade være
Den årlige gennemgang kræver et møde på en time eller to pr. kritisk system og lidt efterarbejde. Dertil kommer de ekstra gennemgange og testene. Sæt et spænd i timer op, og skriv det ind i budgettet som en fast post, så det ikke skal begrundes hver gang.
En forældet plan kan være værre end ingen, for den giver en tryghed, der ikke er dækning for. Ledelsen tror på en tid, der ikke holder, og kunder får dokumentation, der ikke passer. Skal planen genskrives efter nogle år, koster det næsten det samme som første gang. Holder I den ved lige, beholder I overblikket, svartiden og dokumentationen, også selv om intet nogensinde flytter sig.
Det skal I lade være med
- At vente på, at nogen melder en ændring · byg spørgsmålet ind i indkøb og ændringer.
- At overskrive den gamle version · historikken er en del af dokumentationen.
- At kalde en læsning for en test · de to svarer på forskellige spørgsmål.
- At lade datoen stå uændret · en plan uden ny dato ser opgivet ud.
Det skal planen kunne vise
- ☐ Dato for seneste gennemgang og hvem der var med.
- ☐ Dato for næste gennemgang.
- ☐ Hændelser, der udløser en ekstra gennemgang.
- ☐ Ændringslog og gældende version.
- ☐ Dato for seneste test og hvad der udløser den næste.
Kilder
- DORA, forordning (EU) 2022/2554: art. 28, stk. 8. Gælder finansielle enheder og bruges her som model.
- Delegeret forordning (EU) 2024/1773: art. 10. Gælder finansielle enheder og bruges her som model.
Senest gennemgået: november 2026.
Næste skridt
Sæt i dag én dato i kalenderen for hvert kritisk system, og send listen over hændelser til indkøb og IT. Har I endnu ingen ejer, er det det første, der skal på plads.
Læs også: Testrapporten · Hvem ejer exit-planen?
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
