Sådan udfaser du et system under kontrollerede former
At udfase et gammelt system kræver tre ting når afløseren er i drift: en kortlægning af afhængigheder og integrationer før du slukker, en beslutning om hvad der skal arkiveres eller slettes efter bogførings- og databeskyttelsesreglerne, og en opsigelse af aftaler og licenser som ellers bliver ved med at koste. Sjusker du med én af dem, får du efterskælv.
Når et nyt system endelig er i drift, fejrer man det, og det gamle bliver ofte overladt til sin skæbne. Men et halvt udfaset system er ikke væk. Det er en glemt risiko med gamle persondata, ubetalte licenser og afhængigheder som ingen længere husker. Slutfasen fortjener samme omhu som lanceringen. Her er de tre dele du ikke må springe over.
Kortlæg afhængigheder før du slukker
Den farligste antagelse ved en udfasning er at et gammelt system står alene. I praksis er det ofte koblet sammen med andet på måder som ingen længere har fuldt overblik over.
Et aldrende system kan sende data til andre tjenester, modtage filer fra en integration eller være den tavse kilde bag en rapport som en afdeling støtter sig til hver måned. Trækker du stikket uden at vide det, kan du slå noget helt andet ud, og fejlen dukker først op uger senere når sammenhængen er svær at få øje på.
Lav derfor en kortlægning før nedlukningen: Hvilke integrationer går ind og ud, hvilke systemer henter data herfra, og hvem bruger det egentlig? En sikker metode er først at køre det gamle system i skrivebeskyttet tilstand i en periode. Systemet er der stadig og kan læses, men modtager ikke nye data. Savner nogen det, opdager man det dér mens skaden er let at udbedre.
Arkivere eller slette: et juridisk valg
Når systemet først kan lukkes, står spørgsmålet om data tilbage. Og det er ikke et spørgsmål om at gemme alt eller smide alt ud, men om to adskilte og bevidste beslutninger.
Arkivering er at bevare data i et læsbart format til fremtiden fordi loven kræver det eller fordi der kan blive brug for dem. Sletning er bevidst at fjerne data som ikke længere må eller skal gemmes. Bare at lade systemet gå ud er hverken det ene eller det andet og kan være i strid med regler i begge retninger.
De to krav trækker desuden ofte i hver sin retning:
- Bogføringsloven kræver at regnskabsmateriale opbevares i en lovbestemt periode. Det må du ikke slette før tid selvom systemet skal væk.
- Databeskyttelse (GDPR) kræver omvendt at personoplysninger ikke gemmes længere end nødvendigt. At arkivere hele den gamle database af bekvemmelighedshensyn, “for en sikkerheds skyld”, kan altså være et brud på dataminimeringen.
En ordentlig udfasning gennemgår derfor hvilke data der er hvad: hvad der skal bevares, hvad der skal slettes, og i hvilket format arkivet skal ligge for at kunne læses, også når selve systemet er væk.
| Datatype | Hvad der styrer beslutningen |
|---|---|
| Regnskabsmateriale | Skal arkiveres i den lovbestemte opbevaringstid |
| Personoplysninger | Skal slettes når formålet er ophørt, må ikke gemmes unødigt |
| Forretningsdata uden krav | Bevar dem hvis de har værdi, ellers slet dem |
Opsig de aftaler der ellers tikker videre
Den tredje del er den mest direkte økonomiske og alligevel den der oftest bliver overset. At holde op med at bruge et system stopper ikke udgifterne til det.
Licenser, cloudkonti, supportaftaler, domæner og integrationstjenester løber videre indtil nogen aktivt afslutter dem, og mange har opsigelsesvarsler der gør at den sidste faktura kommer længe efter at systemet er gået ud. Et udfaset system som ingen har lukket kontraktmæssigt, kan i det stille koste penge i årevis, en post som ingen tænker på at sætte spørgsmålstegn ved, for “det system bruger vi jo ikke længere”.
Gennemgå derfor alle tilknyttede aftaler som en del af nedlukningen: Hvad betaler vi for, hvilke bindingsperioder og opsigelsesvarsler gælder, og hvornår kan hver enkelt afsluttes? Det er ofte her hele udfasningen betaler sig selv hjem.
Et scenarie: systemet der aldrig døde
En virksomhed skifter ERP-system og lancerer det nye med pomp og pragt. Det gamle bliver stående tændt “indtil videre”. Ingen kortlagde afhængighederne, så en natlig fil til lønsystemet holder i det stille op med at komme, hvilket først opdages ved næste lønkørsel. Ingen tog stilling til data, så den gamle kundedatabase ligger tilbage med personoplysninger længe efter at den burde være slettet. Og ingen opsagde aftalerne, så licensen bliver ved med at blive trukket hvert kvartal i to år før en ny økonomichef spørger hvad posten er.
Intet af det var uundgåeligt. Det var bare slutfasen der aldrig blev gennemført.
Sådan bruger du det her
Behandl udfasning som et lille projekt for sig med tre spørgsmål: Ved vi hvad der er afhængigt af systemet før vi slukker? Har vi besluttet hvad der skal arkiveres og hvad der skal slettes? Og har vi opsagt alle aftaler og licenser? Kan du svare ja til alle tre, er udfasningen kontrolleret i stedet for en glemt risiko.
Vi hos Weapp tager gerne en ordentlig udfasning med når vi hjælper med at erstatte et system så det gamle bliver lukket lige så omhyggeligt som det nye bliver åbnet. Se vores ydelser eller kontakt os, så gennemgår vi forløbet.
Ofte stillede spørgsmål
Hvornår er det sikkert at lukke et gammelt system?
Først når afløseren kører stabilt og du ved at intet andet er afhængigt af det gamle. Mange systemer sender i det stille data til andre via integrationer, og en forhastet nedlukning kan slå noget helt andet ud. Kør hellere det gamle system i skrivebeskyttet tilstand parallelt i en periode indtil du er sikker på at intet har brug for det.
Hvad er forskellen på at arkivere og at slette data?
At arkivere er at gemme data i et læsbart format til fremtiden, f.eks. fordi loven kræver det. At slette er bevidst at fjerne data som ikke længere må eller skal gemmes. Begge dele er aktive beslutninger. Bare at trække stikket er hverken det ene eller det andet og kan være i strid med både bogførings- og databeskyttelsesreglerne.
Hvor længe skal data gemmes?
Det afhænger af datatypen. Regnskabsmateriale har en lovbestemt opbevaringstid efter bogføringsloven mens personoplysninger omvendt ikke må gemmes længere end nødvendigt efter GDPR. De to krav kan trække i hver sin retning, og derfor skal en udfasning gennemgå hvilke data der er hvad, i stedet for at behandle det hele som én bunke der enten skal gemmes eller smides ud.
Hvad sker der med aftaler og licenser hvis vi bare holder op med at bruge systemet?
De bliver som regel ved med at koste. Licenser, cloudkonti, supportaftaler og integrationstjenester løber videre indtil nogen aktivt opsiger dem, og mange har opsigelsesvarsler. Et udfaset system som ingen har lukket kontraktmæssigt, kan tikke videre i budgettet i årevis. Gennemgå alle tilknyttede aftaler som en del af nedlukningen.
Hvorfor tæller udfasning som en selvstændig fase?
Fordi den næsten altid bliver glemt. Projektet bliver fejret når det nye system er i drift, og det gamle overlades til sin skæbne. Men et halvt udfaset system er en glemt risiko: gamle persondata, ubetalte licenser og afhængigheder som ingen længere har styr på. En ordentlig udfasning lukker de risici i stedet for at lade dem ligge og gære.