Ny software er ikke færdig ved go-live: sådan bevarer I overblikket bagefter

I artiklen 10 afsnit

1. Hvorfor er ny software ikke færdig ved go-live?
2. Hvad skal leve videre efter launch?
3. Hvordan hænger det sammen? Fem trin
4. Gælder det kun software?
5. Hvad sker der, hvis ingen tager sig af det?
6. Før og efter: seks måneder efter leveringen
7. Hvordan kan jeg hjælpe, fra behov til drift?
8. Hvor bevarer I overblikket?
9. Hvad kan I gøre nu?
10. Ofte stillede spørgsmål

Hvorfor er ny software ikke færdig ved go-live?

Go-live er dagen, hvor et system tages i brug. Det er ikke dagen, hvor arbejdet slutter. Fire ting sker, efter systemet er leveret:

• Omgivelserne ændrer sig. Leverandører opdaterer, systemer skifter, og regler ændrer sig.
• Behovene ændrer sig. Brugerne vil have noget nyt, og processen udvikler sig.
• Fejl dukker op i brug. Ikke alt kan afprøves, før rigtige brugere og rigtige data er med.
• Folk skifter. Den, der byggede det, eller den, der kender det, er ikke der for evigt.

Teknisk gæld er de genveje og mangler i en løsning, der gør fremtidige ændringer dyrere, ligesom gæld, der skal betjenes. Den opstår, når man bygger hurtigt uden dokumentation, test og orden. Den er usynlig for de fleste, indtil nogen vil ændre noget.

Hvad skal leve videre efter launch?

Fjorten ting skal leve videre efter launch. Tabellen viser dem som spørgsmål, en ikke-teknisk leder kan stille, og hvor I kan læse mere.

Arkitektur betyder blot, hvordan delene i løsningen hænger sammen: hvilke systemer, hvilke forbindelser og hvilke data der går hvorhen. Den bedste dokumentation er en tegning på én side med få bokse og pile. Versioner betyder, at I kan se, hvilken udgave af løsningen der kører, hvad der er ændret siden sidst, og om I kan gå tilbage, hvis noget går galt.

Hvordan hænger det sammen? Fem trin

Modellen har fem trin: Byg → Lancér → Driv → Dokumentér → Forbedr. Den er min egen måde at holde overblikket på, ikke en standard. De 14 punkter fordeler sig sådan:

1. Byg: formål, arkitektur, leverandører, integrationer og data. Det er dem, der bestemmer, hvad I får.
2. Lancér: ejer, adgang og versioner. Nogen tager ansvaret, og det er klart, hvem der må hvad, og hvad der kører.
3. Driv: drift og fejl. Nogen holder det kørende og tager imod problemer.
4. Dokumentér: dokumentation. En anden kan overtage løsningen.
5. Forbedr: ændringer, review og videreudvikling. Løsningen vurderes og udvikles, i stedet for at stå stille.

Trinene er ikke en lineær rækkefølge. Drift og dokumentation skal planlægges i det første trin. Vælger I at bygge selv, hjælper artiklen om skræddersyet software og om at købe, tilpasse eller bygge.

Gælder det kun software?

Nej. Samme tankegang gælder, uanset om I har fået ny software, en integration, en automatisering, AI eller en AI-agent. Tabellen viser, hvad der især skal leve videre for hver:

Er I i tvivl om, hvilken type løsning I har brug for, hjælper AI-agent, automatisering eller integration.

Hvad sker der, hvis ingen tager sig af det?

Hvis ingen tager sig af det, sker det langsomt:

• Personafhængighed. Viden om løsningen sidder hos få personer.
• Viden forsvinder. Folk skifter job, og forklaringerne følger med.
• Integrationer bryder. Et system opdateres, og forbindelsen holder op med at virke uden besked.
• Ingen ejer fejl. Et problem ender i en mailtråd, og ingen er ansvarlig.
• Systemet bliver dyrere at ændre. Hver ændring kræver først, at nogen finder ud af, hvordan det hænger sammen.
• Teknisk gæld vokser. Små rettelser hober sig op, og til sidst er det billigere at bygge forfra end at ændre.

Det er ikke dramatisk, men det er en udgift, der vokser, uden at nogen ser den. Hvad uafklarede opgaver koster i tid, står i artiklen om hvad manuel administration koster.

Før og efter: seks måneder efter leveringen

Hvordan kan jeg hjælpe, fra behov til drift?

Jeg arbejder i denne rækkefølge: forstå processen → udvikle løsningen → integrere den → hjælpe med drift og videreudvikling. Udgangspunktet er, hvad systemerne skal gøre for jeres arbejde, ikke teknologien. Brug, data, adgang og relevante krav er en del af arbejdet hele vejen.

• Forstå processen. Først finder vi ud af, hvad der skal fungere bedre. Se hvordan I kortlægger en arbejdsgang.
• Udvikle og integrere. Når standarden ikke passer, bygger jeg integrationer, AI-funktioner og specialudviklede systemer. Det, jeg bygger, kører i jeres egne konti og er dokumenteret.
• Drift og videreudvikling. Efter første forløb kan I hyre mig til opfølgning, vurdering af nye værktøjer og videreudvikling af de løsninger, vi har bygget.

Se mine ydelser. Jeg giver ikke juridisk rådgivning og garanterer ikke compliance.

Hvor bevarer I overblikket?

En løsning kan være godt bygget og alligevel miste overblikket, fordi det, der skal kunne findes igen, ligger forskellige steder. Det er den del, SPOR er bygget til. Ud fra det, SPOR-siden beskriver, samler SPOR omkring en løsning:

• et register over software, AI-værktøjer og egne løsninger med formål, ansvarlig, pris og aftaler
• løsninger fra behov til drift, hvor beslutninger og dokumentation følger det, der bygges
• risiko pr. system og dataflowet vist som diagram
• hændelser, som registreres, og opgaver med ansvarlig og frist, så review ikke glemmes

SPOR driver, hoster og vedligeholder ikke løsningen og er hverken juridisk rådgivning, certificering eller garanti for, at alle krav er opfyldt. Jeg bygger, SPOR bevarer overblikket. Se SPOR og hvem der ejer systemet.

Hvad kan I gøre nu?

Gør dette:

1. Tag en løsning, I allerede har, og gå de 14 punkter igennem. Markér, hvad der mangler.
2. Navngiv en ejer og en stedfortræder.
3. Sæt drift og videreudvikling ind i budgettet, ikke kun udviklingen.
4. Ved nye projekter: Skriv driftsspørgsmålene ind i kravene, før projektet starter.

Kort sagt: En leveret løsning er en begyndelse. Skal I bygge noget nyt, så bør spørgsmålet om drift komme før den første linje kode, ikke efter den sidste.

Ofte stillede spørgsmål

Hvad koster drift og vedligehold af ny software?

Det afhænger af løsningen. Prisen drives af licenser, hosting, hvor mange systemer den er koblet til, hvor tit noget ændrer sig, og hvor meget der skal rettes. Bed om en pris for drift og vedligehold sammen med prisen for udviklingen, og regn begge med i business casen.

Hvem skal vedligeholde software, når udvikleren er væk?

Det skal aftales, før projektet starter. Kræv dokumentation, der gør det muligt for en anden at overtage, og aftal, hvem der har teknisk ansvar. Ejeren i virksomheden beholder ansvaret for formål og beslutninger.

Hvad er teknisk gæld?

Teknisk gæld er de genveje og mangler i en løsning, der gør fremtidige ændringer dyrere. Den vokser, når der bygges hurtigt uden dokumentation og test, og når små rettelser hober sig op.

Skal alle systemer have samme dokumentation?

Nej. Et lille internt værktøj kan nøjes med én side. Jo vigtigere systemet er, og jo flere andre systemer det er koblet til, jo mere skal dokumenteres.

Artiklen er generel vejledning og ikke juridisk rådgivning. Udgivet 3. oktober 2026.