Det er sjældent selve ERP-systemet, der vælter projektet — det er alle de “små” tilretninger og integrationer rundt om, som ingen fik risikovurderet ordentligt.
I denne artikel får du et praktisk overblik over, hvor virksomheder typisk undervurderer risici ved ERP-udvikling, tilpasninger og tredjepartsintegrationer, og hvad du konkret kan gøre for at mindske dem. Vi går fra de første designvalg til drift og compliance, med eksempler fra virkelighedens ERP-projekter: datamigrering der går skævt, integrationer der bryder ved opdateringer, og custom kode der bliver en teknisk gældsfælde.
Du får også en håndfuld “kontrolspørgsmål”, simple tommelfingerregler og en realistisk forståelse af, hvad det ofte reelt koster, når man undervurderer kompleksiteten. Målet er ikke at skræmme, men at hjælpe dig med at tage bedre beslutninger tidligt.
Hvad mener vi med ERP-udvikling, tilretninger og tredjepartsintegrationer — og hvorfor betyder det noget?
En ERP-løsning (Enterprise Resource Planning) er virksomhedens centrale platform til at styre økonomi, lager, indkøb, salg, produktion og ofte også rapportering og masterdata. Når vi taler om ERP-udvikling og tilretninger, handler det typisk om udvidelser, speciallogik, workflows, rapporter, datafelter og automatiseringer, der tilpasses virksomhedens processer. Tredjepartsintegrationer er koblinger til fx webshop, PIM, WMS, fragt, EDI, bank, løn, CRM eller BI.
Det betyder noget, fordi ERP’en bliver et “system of record”. Hvis der opstår fejl i dataflow, adgangsstyring eller transaktionslogik, rammer det hurtigt alt fra fakturering og lagerbeholdning til compliance og kundetillid. Risikoen vokser ikke lineært: hver ny integration og hver ny tilretning øger antallet af afhængigheder, som kan fejle ved opdateringer, ændrede krav eller leverandørskift.
Mini-konklusion: ERP-projekter fejler sjældent på ambitionen — de fejler på uforudsete konsekvenser i ændringer og integrationer.
Hvorfor risici undervurderes: de 7 klassiske blinde vinkler
Mange organisationer oplever, at ERP-projektet ser overskueligt ud på papiret, men bliver tungt i udførelsen. Det skyldes ofte systematiske blinde vinkler i planlægning og governance.
- “Det er bare en lille tilretning” (men den påvirker proces, data og fremtidige opdateringer).
- Integrationer vurderes som “kabler mellem systemer” frem for forretningskritiske produkter med livscyklus.
- Man undervurderer datakvalitet: “vi rydder op under migreringen”.
- Test reduceres til brugeraccepttest, mens integrationstest, regressions- og belastningstest nedprioriteres.
- Ejerskab er uklart: hvem ejer data, hvem ejer integrationer, hvem godkender ændringer?
- Man baserer estimater på happy path og glemmer undtagelser (krediteringer, del-leverancer, tilbageførsler, valutascenarier).
- Man forventer, at leverandørens standardpakker dækker edge cases uden at læse begrænsningerne i detaljer.
Et konkret mønster: det, der i kickoff kaldes “tilpasning”, ender med at blive et særskilt udviklingsprogram med egne releases, teknisk gæld og driftsrisici.
Mini-konklusion: Undervurdering opstår, når man planlægger for systemet — men ikke for adfærden, dataen og forandringerne omkring systemet.
Tilretninger: når “forretningskritisk” bliver til teknisk gæld
Tilretninger kan være helt legitime. Problemet opstår, når tilretninger bliver standardløsningen på procesvariationer, der i virkeligheden burde standardiseres, eller når man bygger så tæt på kernefunktioner, at opdateringer bliver risikable.
Faldgrube 1: Over-customization og “kopi af gammel verden”
En af de dyreste fejl er at genskabe gamle arbejdsgange 1:1 i det nye ERP. Det føles trygt, men du betaler ofte med kompleksitet. I praksis ser jeg tit 20–40 små specialregler i ordre- eller fakturaflowet, som hver især giver små gevinster, men samlet gør systemet svært at teste og vedligeholde.
Et eksempel: En virksomhed havde speciallogik for rabatter afhængigt af kundetype, sæson, leveringsland og “historiske aftaler”. Det fungerede, indtil de skiftede prislister og integrerede en ny webshop. Pludselig var der tre sandheder om pris — og rabatfejl blev først opdaget ved kundeklager.
Faldgrube 2: Manglende designprincipper og kodeejer
Hvis tilretninger laves “feature for feature” uden fælles principper (navngivning, fejl-håndtering, logging, teststrategi), bliver koden hurtigt uigennemskuelig. Og hvis ingen internt ejer løsningen, er du låst til eksterne konsulenter for selv små ændringer.
Et praktisk pejlemærke: hvis en tilretning ikke har en tydelig “owner”, en testbeskrivelse og en rollback-plan, er den en risiko, ikke en forbedring.
Mini-konklusion: Tilretninger er ikke farlige i sig selv — men uden arkitektur, standarder og ejerskab bliver de en dyr forpligtelse.
Tredjepartsintegrationer: den skjulte kompleksitet i dataflow og ansvar
Integrationer er ofte der, hvor drift og forretning mødes. Når de fejler, fejler processerne. Den hyppigste undervurdering er at tro, at integrationen “bare skal sende data” én gang, hvorefter den passer sig selv.
API’er, EDI og filudveksling: forskellige risikoprofiler
API-integrationer er typisk mere fleksible, men kan bryde ved versionsskift, rate limits eller ændrede felter. EDI er robust, men tungt at ændre og kræver streng governance. Filudveksling (CSV/FTP) kan være hurtigt at komme i gang med, men giver ofte svag validering og dårlig sporbarhed.
Et simpelt sammenligningsbillede: API’er er som en motorvej med mange afkørsler (hurtigt, men kræver skiltning og regler). Filudveksling er som at sende pakker uden tracking (det virker, indtil noget forsvinder).
“Hvem har skylden?”: ansvarsgrænser ved fejl
Når en ordre ikke lander, eller en faktura ikke bogføres, er det ofte uklart, om fejlen ligger i ERP, i middleware, i webshoppen eller hos leverandøren. Hvis du ikke har aftalt ansvarsgrænser, eskaleringsveje og SLA’er, ender du med dyre fejlsøgningsforløb og driftstop.
Mini-konklusion: Integrationer er produkter, ikke projektdelopgaver — de kræver drift, overvågning og klare kontrakter.
Datamigrering og masterdata: der hvor “95% korrekt” stadig giver kaos
Datamigrering bliver ofte planlagt som et teknisk step, men det er en forretningskritisk ændring. 95% korrekt data lyder godt, men hvis de 5% ligger i vareenheder, momsopsætning, kundekreditter eller lagerplaceringer, kan konsekvensen være massiv.
Typiske risici, der undervurderes:
- Dubletter og inkonsistente nøgler (kunde-id, varenummer, GL-konti).
- Uklare ejerskaber for masterdata (hvem godkender ændringer i varekort?).
- Historik der mangler eller ikke kan afstemmes (åbne poster, lagerværdi, saldi).
- Enheder og konverteringer (stk/krt/kg) der skaber skæve lagertal.
- Manglende afstemningsmetode før/efter go-live.
Et praktisk råd: planlæg migreringen baglæns fra afstemningerne. Hvis du ikke kan beskrive, hvordan økonomi, lager og åbne poster afstemmes efter cutover, er migreringsplanen ufuldstændig.
Mini-konklusion: Datamigrering er ikke en filflytning — det er en kontrolleret transformation, der kræver forretningsbeslutninger.
Sikkerhed, compliance og leverandørrisiko: når ERP bliver en del af angrebsfladen
ERP-integrationer trækker ofte data på tværs af systemer og leverandører. Det betyder, at adgangsstyring, logging, patching og secure development ikke kun er “IT’s problem” — det er en forretningsrisiko. Særligt når ERP’en håndterer persondata, prisstrategi, bankintegrationer eller leverandøraftaler.
Hvis du arbejder i eller leverer til kritiske sektorer, eller hvis du er påvirket af nye krav til softwareleverandørkæden, giver det mening at se ERP-tilretninger og integrationer gennem en governance- og sikkerhedslinse. Midt i dette krydsfelt er det værd at læse mere om ERP-systemer under NIS2 og CRA, fordi krav til secure SDLC, leverandørstyring og dokumentation i stigende grad spiller ind på, hvordan ERP-løsninger bygges og driftes.
En undervurderet detalje: servicekonti og API-nøgler lever ofte “for evigt”. Hvis de ikke roteres, logges og begrænses (least privilege), har du en stille risiko, der kan ligge i årevis.
Mini-konklusion: Sikkerhed i ERP handler ikke kun om rettigheder i systemet, men om hele kæden af integrationer, nøgler og leverandører.
Test og kvalitetssikring: hvorfor regressionsfejl er den dyreste type fejl
ERP-projekter har mange afhængigheder. Derfor er regressionsfejl (noget der virkede i går, men ikke virker efter en ændring) både hyppige og dyre. Den typiske undervurdering er at fokusere på “kan vi gennemføre processen?” og glemme “virker den stadig efter næste release?”
Hvad skal testes — ud over happy path?
Overvej at bygge test ud fra forretningshændelser, ikke kun skærmbilleder. Fx: “ordre → levering → faktura → kreditnota → retur → genfakturering”. Og test de scenarier, der gør ondt, når de fejler: periodisering, lagerregulering, valutadifferencer, del-leverancer, EDI-afvisninger.
Hvordan gør man test realistisk uden at drukne?
Du behøver ikke 500 testcases. Men du har brug for et lille sæt “kritiske flows” (ofte 15–30), der automatiseres eller i det mindste køres som fast regression ved hver release. Hvis du har integrationer, bør du have overvågning og testdata, så du kan simulere fejl: timeouts, dubletter, manglende felter.
Mini-konklusion: Test er ikke et projektstep — det er en driftskompetence, især når du har tilretninger og integrationer.
Hvad koster det typisk, når man undervurderer risikoen?
Det præcise tal afhænger af branche og kompleksitet, men et mønster går igen: undervurdering koster mest i drift og efter go-live, ikke i udviklingen. Et “billigt” projekt kan blive dyrt, hvis du skal leve med manuelle workarounds, fejlretninger og brandslukning.
Her er konkrete omkostningsdrivere, jeg ofte ser i praksis:
- Forlænget go-live: ekstra 4–12 uger er ikke unormalt, når data og integrationer ikke spiller.
- Fejlretning under pres: akut udvikling og hotfixes koster mere og giver højere risiko.
- Manuelle processer: 1–2 fuldtidsressourcer i måneder kan “spises” af manuelle afstemninger og rettelser.
- Tabt omsætning: fx hvis webshop-ordreflow eller leverancer stopper i spidsbelastning.
- Eksterne konsulenter: hvis du ikke har intern viden eller dokumentation, bliver du afhængig.
En enkel tommelfingerregel: hvis din ERP-løsning er tæt integreret med salg og logistik, kan selv få timers driftsstop skabe en kædereaktion, der tager dage at rydde op efter.
Mini-konklusion: Den dyreste risiko er ikke “ekstra udvikling” — det er tab af stabil drift og forretningskontrol.
Bedste praksis: sådan reducerer du risikoen uden at kvæle fremdriften
Du kan ikke eliminere risiko, men du kan gøre den synlig, styrbar og billigere. Her er en praktisk tilgang, der virker i de fleste ERP-programmer:
1) Skab en simpel risikomodel for tilretninger og integrationer
Klassificér hver ændring efter fx påvirkning (økonomi/lager/sikkerhed), kompleksitet og reversibilitet. En tilretning, der påvirker bogføring eller priskalkulation, bør automatisk have højere krav til test, dokumentation og godkendelse end en UI-tilpasning.
2) Indfør “change governance light”
Du behøver ikke tung bureaukrati, men du skal have faste beslutningspunkter: Hvem godkender? Hvilke testkrav gælder? Hvordan ruller vi tilbage? Hvilke målepunkter overvåger vi efter release?
En brugbar tjekliste til hver integration/tilretning kan være:
- Formål og forretningsværdi (hvad forbedres, og hvordan måles det?)
- Dataejerskab og datakontrakt (felter, validering, fejlhåndtering)
- Sikkerhed (rettigheder, nøgler, logning, audit)
- Test (kritiske flows, regression, testdata)
- Drift (overvågning, alarmer, runbooks)
- Rollback-plan og cutover-plan
3) Design for opdateringer og leverandørskift
Spørg tidligt: Hvad sker der ved næste version? Kan vi opdatere uden at alt knækker? Brug standardudvidelsesmodeller, hvor det er muligt, og undgå at “hacke” kernestrukturer. Og sørg for at integrationer har klare versioner og dokumenterede kontrakter, så et leverandørskift ikke bliver et genimplementeringsprojekt.
Mini-konklusion: De bedste ERP-løsninger er dem, der kan ændres sikkert — ikke dem, der er “færdige”.
Konkrete faresignaler: sådan spotter du problemer, før de bliver dyre
Hvis du vil lave en hurtig sundhedstest af dit ERP-projekt eller din nuværende løsning, så kig efter disse faresignaler:
- Der findes ingen opdateret integrationsoversigt (hvad taler med hvad, og hvorfor?).
- Fejl opdages af brugerne, ikke af overvågning.
- Tilretninger beskrives i mails og mødenoter, ikke i versioneret dokumentation.
- Ingen kan forklare, hvordan man afstemmer lager og økonomi efter cutover.
- Der er mange “midlertidige” workarounds, som har været i drift i mere end 3 måneder.
- Releaseplanen mangler regressions- og rollback-aktiviteter.
Hvis du kan nikke gen
