Hvis du nogensinde har stået i en driftssituation, hvor “den lille ERP-tilretning” pludselig var den eneste forklaring på et databrud, et nedbrud eller en fejl i regnskabet, så ved du, hvor dyrt dårlig dokumentation kan blive.
I denne artikel får du en praktisk, struktureret metode til at dokumentere tilretninger og integrationer i ERP-systemer, så den holder til nye cyberkrav, audit og driftsoverdragelser. Vi gennemgår, hvad der skal dokumenteres, hvordan du gør det ensartet, hvilke faldgruber du skal undgå, og hvad det typisk koster i tid og ressourcer.
Hvorfor dokumentation af ERP-tilretninger pludselig er et cyberkrav (ikke bare “nice to have”)
De nye cyberkrav (bl.a. NIS2, øget fokus på leverandørkæder og dokumenterbar sikker udvikling) betyder i praksis, at virksomheder i langt højere grad skal kunne bevise, hvad der er ændret i kritiske systemer, hvorfor det er ændret, hvem der godkendte det, og hvordan risikoen er håndteret. ERP-systemer er næsten altid forretningskritiske: de rummer økonomi, masterdata, kunder, leverandører, priser, lager og ofte persondata.
En kort definition: struktureret dokumentation af ERP-tilretninger og integrationer er en standardiseret beskrivelse af ændringens formål, design, sikkerhed, test og driftseffekter, koblet til versionsstyring, godkendelser og sporbarhed. Det betyder noget, fordi det reducerer nedetid, fejl og sikkerhedsrisiko – og gør audit og incident-håndtering markant hurtigere.
Mini-konklusion: Hvis du ikke kan forklare en ændring hurtigt og præcist, kan du heller ikke kontrollere risikoen – og det er netop det, nye cyberkrav lægger pres på.
Hvad skal dokumenteres? Overblik over tilretninger, integrationer og afhængigheder
Dokumentation fejler ofte, fordi man kun beskriver “hvad der blev lavet” og glemmer kontekst: dataflow, rettigheder, drift, overvågning og rollback. Under skærpede krav bør dokumentationen dække både ændringen og dens konsekvenser i hele værdikæden.
Tilretninger: fra forretningslogik til sikkerhed
Tilretninger kan være alt fra felter og rapporter til valideringsregler, workflows, extensions, batchjobs og automatisering. For cyberkrav er det især vigtigt at få med: adgangskontrol, logning, fejlhåndtering og påvirkning af data (herunder persondata og finansdata).
Integrationer: det skjulte attack surface
Integrationer er ofte det svageste led: API’er, filudveksling, middleware, EDI, Power Platform, RPA, SFTP, webhooks eller direkte databasekald (som du helst vil væk fra). Her skal dokumentation tydeligt vise, hvilke systemer der taler sammen, hvilke credentials der bruges, og hvilke data der flyder hvorhen.
- Formål og scope: hvorfor findes ændringen/integrationen, og hvad er “out of scope”?
- Data og klassifikation: hvilke felter/tabeller, hvilke datatyper (fx persondata), og hvor længe gemmes data?
- Adgang og rettigheder: roller, servicekonti, least privilege, MFA/keys, certifikater.
- Teknisk design: komponenter, endpoints, skemaer, mappings, kø-mekanismer, idempotens.
- Drift og overvågning: alarmer, logs, dashboards, fejlscenarier, retry/timeout.
- Test og kvalitet: testcases, testdata, sporbarhed til krav, sign-off.
- Rollback og recovery: hvordan ruller vi tilbage, og hvad gør vi ved datakonsekvenser?
Mini-konklusion: Dokumentation skal beskrive både “ændringen” og “systemets nye adfærd” – ellers er den ikke brugbar i drift, audit eller under et angreb.
Den strukturerede dokumentationsmodel: et minimumssæt der holder til audit
Du behøver ikke skrive romaner. Du skal skrive ensartet. Den mest effektive tilgang, jeg har set i praksis, er at indføre et fast “dokumentationskit” per ændring, så alle ved, hvad der forventes, og så du kan genbruge indhold på tværs af releases.
Skabeloner der kan genbruges uden at blive tungt
Lav 3–5 skabeloner afhængigt af ændringstype. Ét eksempel: “ERP-tilretning”, “Integration/API”, “Rapport/BI”, “Adgang/rolletilpasning” og “Drift/overvågning”. Hver skabelon skal kunne udfyldes på 30–90 minutter for normale ændringer og være mere dyb for højrisko-ændringer.
De 10 felter, der næsten altid bør være med
- Change-ID (koblet til ticket/issue og repository-tag/commit)
- Risiko- og dataklassifikation (fx lav/middel/høj + persondata/finans)
- System- og versionsinfo (ERP-version, extension-version, integration-version)
- Arkitektur/dataflow (beskrevet i tekst: kilde → transformation → mål)
- Sikkerhed (authN/authZ, secrets, kryptering, logning)
- Test (hvad er testet, hvad er ikke testet, og hvorfor)
- Godkendelser (forretning + IT, og evt. sikkerhedsgodkendelse ved høj risiko)
- Drift (monitorering, alarmer, supportvejledning, kendte fejl)
- Rollback (teknisk rollback + datahåndtering)
- Dato og ejerskab (hvem vedligeholder dokumentet efter go-live)
Mini-konklusion: Det afgørende er ikke mængden af tekst, men at hvert change har en sporbar, ensartet “pakke” med sikkerhed, test og drift.
Sådan kobler du dokumentation til cyberkrav og compliance uden at drukne i papir
Et typisk spørgsmål er: “Hvordan dokumenterer vi, så det faktisk matcher kravene?” Svaret er at tænke i sporbarhed: fra krav → design → implementering → test → drift. Når du kan trække den linje, står du stærkt ved audit og ved hændelser.
Mange organisationer samler det under en samlet praksis for change management og secure development. Hvis du arbejder med Business Central eller tilsvarende ERP-platforme, kan det være nyttigt at orientere sig i, hvordan sikker udvikling og dokumentation typisk mappes til rammeværk og standarder. Se fx ERP-systemer og compliance for perspektiv på, hvordan krav ofte omsættes i praksis.
Praktisk mapping: dokumentationsfelter til kontrolpunkter
Du behøver ikke citere standarder i hvert dokument. Men du kan indføre et enkelt “kontrolkort” i skabelonen, hvor du markerer relevante emner: adgangskontrol, logning, ændringsstyring, leverandørstyring, backup/recovery og sårbarhedshåndtering. På den måde kan du hurtigt dokumentere, at ændringen er vurderet mod relevante sikkerhedskontroller.
Bevisførelse: hvad en auditor typisk spørger efter
- Kan I vise, hvem der godkendte ændringen, og hvornår?
- Er der testbeviser, og er de relevante for risikoen?
- Er der styr på rettigheder til servicekonti og integrationer?
- Er logs tilstrækkelige til at efterforske en hændelse?
- Kan I rulle tilbage, og ved I, hvad det betyder for data?
Mini-konklusion: Det handler om at kunne dokumentere “vi har tænkt os om” på en måde, der kan efterprøves – ikke om at producere mest muligt materiale.
Best practices: versionering, sporbarhed og “single source of truth”
Det mest undervurderede greb er at samle dokumentation der, hvor arbejdet allerede sker: i jeres ticket-system og repository. Det giver færre døde dokumenter og bedre aktualitet. I praksis ser jeg tre mønstre, der virker:
- Docs-as-code: dokumentation ligger versioneret sammen med koden (fx i repo), og ændres via pull requests.
- Ticket-first: alt starter i en change-ticket med fast skabelon, og repo-links, testlinks og release-notes hæftes på.
- Hybrid: korte beslutninger og godkendelser i tickets, teknisk specifikation og drift i repo-dokumenter.
Et konkret tip: Gør det til en regel, at et change ikke kan lukkes, før dokumentationsfelter er udfyldt, og at release ikke kan køre, før der er link til test og rollback-plan. Det er en simpel “quality gate”, der flytter adfærd.
Mini-konklusion: Når dokumentation følger versionering og releaseflow, bliver den automatisk mere sand og mere brugbar.
Typiske fejl (og hvordan du undgår dem) i ERP-dokumentation under nye cyberkrav
Spørgsmålet “hvilke fejl ser du oftest?” har et kedeligt svar: de samme fem igen og igen. Det gode er, at de er til at rette op på med få procesgreb.
Fejl 1–3: Utydeligt ejerskab, manglende dataflow og “tribal knowledge”
Hvis dokumentation kun kan forklares af én konsulent, er risikoen høj. Sørg for at hvert dokument har en ejer (rolle, ikke person), og at dataflow altid beskrives med kilde-mål og transformationslogik. Brug faste ord: “kilde”, “destination”, “format”, “frekvens”, “fejlhåndtering”.
Fejl 4–5: Ingen testbeviser og ingen rollback
Mange skriver “testet OK” uden at beskrive hvad. Under cyberkrav er testsporbarhed et centralt bevis. Lige så vigtigt: rollback er ikke bare at “deploye tilbage”. Hvis ændringen påvirker data (fx bogføringslogik eller synkronisering), skal rollback-planen også beskrive datakonsekvenser og evt. oprydning.
- Undgå “skærmbilleder uden kontekst” som eneste testbevis – beskriv testcase og forventet resultat.
- Undgå hardcoded credentials og u-dokumenterede secrets – dokumentér hvor secrets ligger, og rotationspraksis.
- Undgå uovervågede integrationer – dokumentér alarmer, og hvem der reagerer.
- Undgå at logge for lidt (ingen spor) eller for meget (persondata i logs) – dokumentér logniveau og filtrering.
Mini-konklusion: De største risici opstår sjældent i “koden”, men i manglende sporbarhed, test og driftssikring omkring ændringen.
Hvad koster struktureret dokumentation – og hvad koster det at lade være?
“Hvad koster det?” afhænger af modenhed og kompleksitet, men du kan godt estimere. For en normal ERP-tilretning eller integration ser jeg typisk:
- 30–90 minutter for basisdokumentation ved lav risiko (når skabeloner er på plads)
- 2–6 timer for højrisiko-ændringer (persondata, finans, eksterne integrationer, nye servicekonti)
- + løbende 10–20% ekstra ved de første 5–10 changes, mens teamet lærer formatet
Til gengæld er besparelsen ofte markant ved fejl og hændelser. En enkelt incident, hvor du sparer 4–8 timers “detektivarbejde” på at finde dataflow, credentials, deployments og ændringer, kan betale en stor del af indsatsen. Og ved audit er forskellen mellem “vi tror” og “vi kan vise” ofte forskellen på et roligt forløb og et dyrt opfølgningsarbejde.
Mini-konklusion: Dokumentation koster timer nu, men kan spare dage senere – især når nogen skal fejlfinde under pres.
Implementér det i praksis: en 30-dages plan der kan køre uden store projekter
Den største barriere er sjældent vilje, men friktion. Her er en pragmatisk plan, der kan indføres uden at stoppe udvikling og drift.
- Uge 1: Vælg 3 skabeloner (tilretning, integration, drift). Definér “done”-kriterier og ejerskab.
- Uge 2: Indfør quality gate i ticket-flow: ingen lukning uden links til test og rollback-plan.
- Uge 3: Kortlæg top-10 integrationer og deres credentials, data og overvågning. Luk de største huller først.
- Uge 4: Gennemfør en mini-audit på 5 nylige changes: kan I finde design, test, godkendelse og drift på 10 minutter?
Et ekstra råd fra praksis: start med de ændringer, der har størst konsekvens ved fejl (bogføring, betalingsfiler, bruger-/rolleændringer, masterdata-synkronisering). Når teamet mærker, at det gør hverdagen nemmere, kommer adoptionen langt hurtigere.
Mini-konklusion: Små, faste gates og genbrugelige skabeloner giver hurtigere effekt end store dokumentationsprojekter.
Kontrolspørgsmål du kan stille i morgen (for at afsløre dokumentationsgæld)
Hvis du vil teste, om jeres nuværende dokumentation kan stå distancen under nye cyberkrav, så brug disse spørgsmål i et teammøde eller ved næste change:
- Kan vi på 10 minutter forklare præcis, hvilke data en integration flytter, og hvorfor?
- Ved vi, hvor servicekonti og nøgler ligger, hvem der ejer dem, og hvornår de roteres?
- Kan vi dokumentere, hvem der godkendte ændringen, og hvad der blev testet?
- Har vi en konkret rollback-plan, inkl. dataoprydning, hvis noget går galt?
- Er logning og overvågning beskrevet, så drift kan reagere uden udvikleren?
- Hvis nøglepersonen er væk i morgen, kan en anden overtage uden gætteri?
Mini-konklusion: Hvis svarene kræver, at “Peter lige kigger på det”, har I sandsynligvis dokumentationsgæld, der bør nedbringes før næste audit eller hændelse.
About the Author
