Fornyelsesefterslæb er summen af de opgraderinger og udskiftninger, som I ved burde være gjort, og som er blevet skubbet år for år. Det står ikke i noget regnskab, og derfor kan en direktion ikke se det, før et system falder ud af support, eller et stort program pludselig haster. Svaret er at gøre efterslæbet synligt: en liste pr. system med dato, konsekvens og ejer, lagt frem for direktionen en gang om året og koblet til budgettet. Så bliver hver udskydelse en beslutning, ledelsen selv har truffet. Artiklen er uden tal, for I skal bruge jeres egne.
Hvorfor det opstår
Efterslæb opstår sjældent, fordi nogen har sovet i timen. Der er gode grunde hvert år. Et ERP-program trækker på alle folk, et sparemål skal nås, og opgraderingen af et system, der virker, giver ingen ny funktion at vise frem. Sammenlignet med projekter, som forretningen beder om, taber fornyelsen hver gang i prioriteringen.
Med flere selskaber bliver det sværere at få øje på. Hvert selskab har sit eget tempo, og en fælles opgradering kræver, at alle er klar samtidig. Efter opkøb arver I desuden andres efterslæb, og det viser sig ofte først, når IT-afdelingerne arbejder sammen.
Hvad der hører til
Efterslæbet omfatter det, der skal fornyes, for at det eksisterende kan fortsætte:
- systemer på versioner, der er tæt på at miste support,
- udstyr, netværk og servere, der har passeret den planlagte levetid,
- tilpasninger, der forhindrer en opgradering,
- integrationer, der er bygget til en gammel version,
- platforme, kun få medarbejdere stadig kan arbejde med.
Teknisk gæld i kode er en beslægtet størrelse, som hører hjemme hos dem, der laver software. Hos jer handler det om standardsystemer og infrastruktur, som skal forvaltes, og om de valg, der er truffet om at vente.
Sådan gør I det synligt
Saml listen. Tag udgangspunkt i applikationsporteføljen og i oversigten over infrastruktur. Noter for hvert element, hvornår leverandøren stopper support, og hvornår det er planlagt fornyet. Spørg systemejerne, og spørg driftsleverandøren. Ved nyere produkter kan den supportperiode, leverandøren oplyser efter EU’s regler, bruges som dato, se CRA set fra køberen. Medtag alle selskaber, selv om tallene bliver ujævne i første omgang.
Vurder konsekvensen. Hvad sker der, hvis vi venter et år mere? Beskriv det i forretningens ord: en proces, der står stille, et kundekrav, der ikke kan opfyldes, en risiko for sikkerheden, eller at systemet kun kan rettes af én medarbejder.
Skøn størrelsen. Et groft skøn over arbejde og udgift er nok. Skriv, hvor usikkert skønnet er. Pointen er at vise, om efterslæbet vokser eller falder, og et fast skøn hvert år giver netop det.
Sæt ejer på. Hvert element skal have en ejer i forretningen eller IT, der kan svare for det.
Sådan viser I det til en direktion
Direktionen behøver ikke listen. Den skal bruge tre ting på én side:
- Hvor stort er efterslæbet? Sammenlignet med sidste år. Vokser det, bruger I mere af fremtiden, end I lægger tilbage.
- Hvad er det mest kritiske? De få elementer, hvor en dato eller en konsekvens kræver en beslutning snart.
- Hvad er valget? Hvad der kan gøres med det nuværende budget, hvad der kræver mere, og hvad I foreslår at leve med.
En tidslinje over de næste år virker ofte stærkt. Når flere fornyelser falder sammen, ser direktionen en pukkel, længe før den rammer. Et tænkt eksempel: Tre systemer mister support inden for samme år, og alle tre kræver de samme to specialister. Hver for sig så de håndterbare ud, men samlet kan de ikke gennemføres uden at stoppe andre projekter.
Det, I vælger at leve med, skal stå som en accepteret risiko med navn og dato. Står det kun i en mail, er det blot en forsømmelse, der venter. De største punkter hører med i IT-rapporteringen til direktionen.
Sådan får I efterslæbet ned
Læg fornyelse ind som sin egen del af IT-budgettet, så den ikke konkurrerer med hvert nyt projekt. Beslut en fast ramme, og lad porteføljen vise fornyelse på lige fod med udvikling, for den trækker på de samme folk.
Vælg, hvad der skal fornys, og hvad der skal fjernes. Det, der kan lukkes, skal ikke opgraderes, og nogle ældre systemer skal hellere erstattes end holdes i live. Valget er beskrevet i legacy-systemer. Saml opgaver, hvor det giver mening, så en opgradering ikke rammer de samme fagfolk gentagne gange.
Pas på, når direktionen vil skære. En pause i fornyelsen ligner en besparelse og er det sjældent, som beskrevet i direktionen vil spare på IT.
Efter et opkøb eller en sammenlægning er det et godt tidspunkt at lave en fælles liste. Det samlede billede giver et bedre grundlag for at vælge, hvad der skal bestå.
Det skal I lade være med
· At fortælle om efterslæbet første gang, når systemet er ved at stoppe.
· At lade fornyelse konkurrere med hvert nyt projekt i hver budgetrunde.
· At opgradere noget, I burde lukke.
· At lade en udskydelse stå uden navn og dato.
Det skal I kræve af dem, der leder IT
- ☐ En liste over efterslæbet pr. system og selskab med ejer og dato.
- ☐ Konsekvensen beskrevet i forretningens ord.
- ☐ En årlig status, der viser retningen.
- ☐ En tidslinje med de fornyelser, der falder sammen.
- ☐ Et forslag til, hvad der fornys, fjernes eller accepteres.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Totalomkostninger: sådan regner I TCO · For mange projekter på én gang
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
