Hvis du stadig tænker ERP-tilpasninger som “lidt ekstra felter og et par integrationer”, så overser du sandsynligvis den største risiko: du driver reelt softwareudvikling i produktion — ofte uden de sikkerheds- og dokumentationskrav, du ville acceptere i et almindeligt udviklingsprojekt.
I denne artikel får du et praktisk overblik over, hvorfor ERP-tilpasninger og integrationer bør behandles som sikker softwareudvikling (ikke kun drift), hvilke krav til dokumentation der typisk følger med, og hvordan du undgår de klassiske fejl. Du får også konkrete takeaways til proces, roller, test og estimering, så du kan løfte både compliance og stabilitet uden at drukne i bureaukrati.
Kort definition: ERP-tilpasninger og integrationer er ændringer i og omkring dit ERP-system (fx nye udvidelser, API-koblinger, datamigreringer og automatiseringer), der påvirker forretningsprocesser og dataflow. Det betyder noget, fordi de ændringer kan skabe nye angrebsflader, fejl i regnskab/data og driftsstop — og derfor kræver samme disciplin som anden softwareudvikling: krav, design, test, release-styring og dokumentation.
ERP-tilpasning er udvikling, uanset hvad du kalder det
I praksis ser jeg ofte, at ERP-området bliver behandlet som “drift”: man har et ticketsystem, en backlog og en idé om, at leverandøren “fikser det”. Men når du tilføjer en integration til et WMS, ændrer validering på fakturalinjer eller bygger en automatisk kreditkontrol, så har du skabt ny funktionalitet med forretningslogik. Det er software.
Forskellen på drift og udvikling er ikke, om det foregår i et ERP-system, men om du ændrer adfærd og data. Selv små ændringer kan have stor effekt: Et ekstra felt på en salgsordre er ufarligt i sig selv, men hvis feltet styrer en integration, der automatiserer levering eller fakturering, kan en fejl give alt fra forkerte leverancer til bogføringsfejl.
Mini-konklusion: Hvis ændringen kan påvirke data, integrationer eller beslutningslogik, skal den behandles som udvikling med sikkerhed og dokumentation.
Hvorfor sikkerhed pludselig er et ERP-anliggende
ERP er ofte virksomhedens “system of record” for kunder, priser, bankoplysninger, lager og finans. Det gør ERP til et attraktivt mål for angreb, og integrationer til resten af systemlandskabet skaber mange ind- og udgange. Når man kobler ERP til e-commerce, EDI, betalingsløsninger, BI, HR eller produktionssystemer, opstår et netværk af afhængigheder, hvor et svagt led kan kompromittere helheden.
Integrationer udvider angrebsfladen
Hver gang du åbner et API, opretter en servicekonto, eller flytter data via filudveksling, udvider du angrebsfladen. Typiske risici er overprivilegerede brugere, hårdkodede nøgler, manglende rate limiting, utilstrækkelig logning og uvalideret input. Særligt ved ældre integrationer ser jeg ofte “quick fixes”, hvor et delt brugernavn eller en statisk nøgle bare bliver genbrugt i årevis.
Tilpasninger kan skabe forretningskritiske fejl
En sårbarhed er ikke kun et datalæk. I ERP kan det også være en fejl, der ændrer økonomi eller logistik. Et konkret eksempel fra praksis: En tilpasning, der automatisk beregnede rabat, afrundede forkert på bestemte valutaer. Det var ikke “bare en bug” — det gav afvigelser i dækningsbidrag og krævede efterfølgende korrektion af fakturaer. Den type fejl opstår typisk, når man springer test, code review og sporbarhed over.
Mini-konklusion: ERP-sikkerhed handler lige så meget om integritet og korrekthed som om klassisk “cyber”.
Dokumentationskrav: hvad skal du faktisk kunne vise?
Dokumentation bliver ofte misforstået som tunge dokumentpakker. I virkeligheden handler det om at kunne svare klart på: Hvad ændrede vi? Hvorfor? Hvem godkendte? Hvordan testede vi? Hvad blev sat i drift? Og hvordan kan vi rulle tilbage?
For mange organisationer er det især aktuelt pga. regulatoriske og kontraktuelle krav, samt forventninger fra revision og kunder. Hvis du arbejder med krav og rammer som NIS2, ISO 27001 eller produktrelaterede sikkerhedskrav, bliver Secure SDLC-principper hurtigt relevante. Midt i den diskussion giver det mening at læse mere om Business Central og Secure SDLC, fordi det tydeliggør, hvordan governance og udviklingspraksis hænger sammen i et ERP-miljø.
Den dokumentation, der typisk giver mest værdi
- Krav og acceptkriterier (hvad er “done”, og hvad må ikke ændre sig?)
- Teknisk design på et niveau, hvor andre kan vedligeholde (dataflow, endpoints, rettigheder)
- Trusselsvurdering light: hvad kan gå galt, og hvordan reducerer vi risiko?
- Testdokumentation (cases, testdata, resultater og afvigelser)
- Release note og ændringslog (hvad blev deployet hvornår?)
- Rollback-plan og driftsinstruks (hvordan genskaber vi stabil drift?)
Sporbarhed: fra ticket til kode til release
Sporbarhed er ofte det, der mangler. Du behøver ikke et tungt værktøj, men du skal kunne forbinde en ændring til dens formål. En enkel praksis er at kræve, at alle commits og pull requests refererer til et ticket-id, og at release-notes genereres ud fra merge-historik. Når en auditor eller en intern kontrolfunktion spørger “hvorfor ændrede vi dette?”, skal du kunne svare uden at lede i mails.
Mini-konklusion: God dokumentation er ikke et ekstra lag — det er det, der gør ændringer kontrollerbare og revisionsklare.
Secure SDLC i ERP: sådan oversætter du principper til hverdag
Secure SDLC lyder for mange som noget, der hører til i produktudvikling. Men principperne er universelle: planlæg sikkerhed, byg med standarder, test systematisk, og dokumentér beslutninger. I ERP-kontekst handler det om at gøre det praktisk og skalerbart.
Minimal, men effektiv proces (der kan køre sprint for sprint)
- Afklar scope: hvilken proces/data/integration påvirkes?
- Lav risikovurdering: dataklassifikation, rettigheder, eksponering (intern/ekstern)
- Design: dataflow, fejlscenarier, logging, idempotens i integrationer
- Implementér med code review og standarder (navngivning, fejl- og undtagelseshåndtering)
- Test: unit/integration + regression på kritiske flows (ordre til cash, purchase to pay)
- Godkend: business sign-off + teknisk sign-off
- Deploy: plan, overvågning, rollback og post-release verifikation
Hvad betyder “sikker kodning” i integrationer?
I integrationsarbejde er de typiske sikkerheds- og kvalitetsgreb konkrete: valider input (også fra “betroede” systemer), brug mindst mulige rettigheder på servicekonti, roter nøgler, undgå at logge følsomme data, og håndtér fejl deterministisk. I praksis ser jeg fx ofte, at en integration fejler “stille” og efterlader en kø af ubehandlede transaktioner. Det er både drifts- og sikkerhedsrisiko, fordi du mister overblik over dataintegritet.
Mini-konklusion: Secure SDLC i ERP er en række små, konsekvente vaner — ikke et stort compliance-projekt.
Typiske faldgruber (og hvordan du undgår dem)
Mange ERP-projekter fejler ikke pga. teknologien, men pga. manglende kontrol med ændringer. Her er de mest almindelige faldgruber, jeg møder, og hvad der virker i praksis:
- “Bare en lille ændring”: behandles uden test. Løsning: fast minimumspakke (krav + test + release note), uanset størrelse.
- Ingen miljødisciplin: ændringer bygges direkte i produktion eller uden repræsentative testdata. Løsning: dev/test/prod-adskillelse og anonymiserede data.
- Overprivilegerede integrationer: én servicekonto kan alt. Løsning: mindst mulige rettigheder og separate konti pr. integration.
- Manglende ejerskab: ingen kan forklare dataflow eller konsekvenser. Løsning: udpeg system- og integrationsansvarlige med dokumentationsansvar.
- Uklare krav: “det skal bare virke hurtigere”. Løsning: målbare acceptkriterier (fx svartid, fejlrate, afstemningskrav).
- Ingen logning/monitorering: fejl opdages først ved klager. Løsning: alarmer på køer, fejlrate og afstemningsdifferencer.
Mini-konklusion: De fleste problemer kan forebygges med få standarder, der håndhæves konsekvent.
Hvad koster det at gøre det rigtigt?
Spørgsmålet “hvad koster det?” dukker altid op, især når dokumentation og sikkerhed kommer på bordet. Mit erfaringsbaserede svar er, at en letvægts Secure SDLC-tilgang typisk lægger 10–25% oven i udviklingsindsatsen for en change, afhængigt af modenhed og værktøjer. Det lyder af meget — men alternativet er ofte langt dyrere.
Sammenligningen jeg plejer at bruge: En ekstra dag til test og release-styring kan spare uger i fejlsøgning, hotfixes og efterregulering. Ved økonomiske processer kan selv små fejl give stor regningsmæssig konsekvens. Hvis en integration fx duplikerer 0,5% af fakturaer i en periode, kan det koste betydeligt mere i kreditnotaer, kundedialog, afstemning og revisionstid end selve udviklingsopgaven.
Omkostningen afhænger især af:
- Antal integrationer og afhængigheder
- Datakritikalitet (persondata, finans, pricing)
- Krav til oppetid og RTO/RPO
- Hvor meget der kan genbruges (templates, pipelines, testpakker)
Mini-konklusion: “Sikker udvikling” er sjældent dyrt i sig selv — det er billigere end uforudsete fejl i forretningskritiske flows.
Bedste praksis: sådan får du styr på governance uden at bremse tempoet
En praktisk model er at etablere et fast “change kit” for ERP-tilpasninger og integrationer. Tænk det som en standardpakke, som alle changes skal igennem, men med mulighed for at skrue op/ned efter risiko.
Et simpelt change kit, der virker
- Skabelon for krav og acceptkriterier
- Skabelon for teknisk design (inkl. dataflow og rettigheder)
- Risiko-checkliste (dataklasse, eksponering, tredjepart, logging)
- Testpakke for kritiske end-to-end flows
- Release checklist (backup, deploy, verifikation, rollback)
Rollefordeling: hvem gør hvad?
Uklare roller skaber huller. En robust minimumsopdeling er:
- Product owner/procesejer: prioritering, accept og konsekvens for forretning
- Teknisk ansvarlig: arkitekturvalg, sikkerhedskrav, code review
- Driftsansvarlig: deployment, overvågning, incidentberedskab
- Compliance/revision (ved behov): krav til sporbarhed og evidens
Mini-konklusion: Governance handler ikke om flere møder, men om klare standarder og tydeligt ejerskab.
Sådan kommer du i gang: 30-60-90 dages plan
Hvis du vil løfte ERP-tilpasninger fra “drift” til kontrolleret, sikker udvikling, kan du gøre det trinvist. Her er en realistisk plan, der kan gennemføres uden at stoppe leverancerne.
- 0–30 dage: Indfør krav + acceptkriterier på alle changes, og kræv release notes. Etabler dev/test/prod-disciplin, hvis den halter.
- 31–60 dage: Standardisér code review, minimumstest og en enkel risikovurdering pr. change. Få styr på servicekonti og rettigheder i integrationer.
- 61–90 dage: Byg monitorering på integrationsfejl og afstemninger. Etabler sporbarhed fra ticket til release og en fast rollback-procedure.
Det vigtigste er at starte med de changes, der har højest risiko: eksterne endpoints, finansposter, betalings- og bankdata, prisstyring, masterdata og automatiseret bogføring. Når det først er standard, føles det ikke som ekstra arbejde, men som “måden vi gør det på”.
Mini-konklusion: Små, faste krav på alle ændringer skaber hurtigere forbedring end store engangsprojekter.
