
Integrationer og API
Sådan vælger du integrationsmønstre mellem systemer og datakilder
Et typisk systemlandskab er ikke designet på én gang. Løsninger er kommet til efterhånden, som behovene ændrede sig, ofte uden en samlet struktur.
Start med forretningsbehovet og systemlandskabet
Et typisk systemlandskab er ikke designet på én gang. Løsninger er kommet til efterhånden, som behovene ændrede sig, ofte uden en samlet struktur. Ifølge Evidi fører det ofte til parallelle systemer, manuelle processer, fragmenterede data og arbejdsgange, der afhænger af enkeltpersoner – alt imens kravene til tilgængelige data, automatisering, analyse og AI stiger.
Vælg derfor integrationsmønster ud fra de arbejdsgange, der skal hænge sammen – ikke ud fra en enkelt teknologi. Tag en konkret proces, fx fra kundeemne til faktura, fra ordre til levering eller fra sag til afslutning, og noter for hvert trin: Hvilke systemer indgår? Hvor opstår data? Hvor skal de bruges videre? De trin, hvor en medarbejder i dag kopierer data mellem systemer, er netop der, integrationen gør en forskel.
Afklar også, hvad I spørger om: Skal integrationen understøtte en eksisterende proces uændret, eller skal den muliggøre en ny måde at arbejde på? Det bestemmer, hvor meget fleksibilitet mønstret skal levere. Arbejdsgange, der afhænger af enkeltpersoner, er svære at skalere og sårbare ved ferie, sygdom og jobskifte; fragmenterede data giver et dårligere grundlag for analyse og beslutninger.
Virksomhedsintegration er praksissen med at forbinde forretningsapplikationer, data, clouds, processer, enheder og mennesker på tværs af hele IT-landskabet. Det er den praksis, mønstervalget skal strukturere, så arbejdsgange, data og beslutninger hænger sammen.
Guiden er trinvis: start med forretningsbehovet, kortlæg datadomænerne, vælg mellem de fire mønstre, afklar hastighed, skalering, drift og datakvalitet, og træf til sidst valget. De fire konkrete mønstre er en-til-en-integration, centralt knudepunkt, API-baseret snitflade og iPaaS.
Kriterierne, du skal vælge efter, er antal systemer nu og om to år, antal datadomæner, hvor ofte systemerne ændrer sig, antal parter og ejere samt flowets forretningskritiske betydning. Værktøjerne er de fire mønstre og de navngivne platforme, du kan sammenligne.
Kortlæg data og ansvar på tværs af systemer
CRM og ERP holder styr på hver sit. CRM styrer relationerne – kundeemner, salgsmuligheder, samtaler og købsintentioner – og viser salgspipeline, potentiale og det momentum, salgsteamet opbygger nu. ERP styrer realiteterne – fakturaer, ordrer, betalinger og marginer – og viser omsætning, omkostninger og den økonomiske virkelighed. Som SuperOffice siger: to systemer, to versioner af sandheden.
De fleste vækstvirksomheder har mindst to centrale platforme. I praksis indtastes data i CRM og derefter igen i ERP, mens rapporter trækkes separat, og tallene afstemmes manuelt. Kortlægningen bør derfor handle om datadomæner – kunde, kontaktperson, aftale, ordre, faktura, betaling – ikke kun om systemer. For hvert domæne skal I beslutte, hvor posten opstår, hvilket system der er master, hvilken retning data flyder, og hvad der udløser en opdatering.
Lav feltmapping, før I vælger teknologi: Hvilket felt i det ene system svarer til hvilket i det andet? Hvilke felter er obligatoriske? Hvad sker der, når en post ændres eller slettes i kildesystemet? Uden den afklaring ender ejerskabet hos medarbejderen mellem systemerne – altså hos en enkeltperson.
Systemerne vejer ikke lige tungt. CRM-software er generelt billigere og nemmere at implementere end ERP, fordi det kræver mindre tilpasning og færre komplekse integrationer med eksisterende systemer. Den forskel er et vilkår, mastervalget skal tage højde for.
Et konkret eksempel er CRM til ERP: Når en aftale lukkes i CRM, overføres relevante data direkte til ERP til fakturering, ordrehåndtering og regnskab. Uden integration indtastes data først i CRM og derefter igen i ERP.
For hvert datadomæne skal beslutningen stå klart: Hvor opstår posten, hvilket system er master, hvilken retning flyder data, og hvad udløser en opdatering? Det gælder kunde, kontaktperson, aftale, ordre, faktura og betaling.
Vælg mellem en-til-en-integration og centralt knudepunkt
Guiden arbejder med fire integrationsmønstre: en-til-en-integration, centralt knudepunkt, API-baseret snitflade og iPaaS. Hvert mønster besvarer et andet spørgsmål – hvordan systemer kobles sammen, hvordan snitfladen stilles til rådighed, og hvor integrationen drives.
En-til-en-integrationer forbinder to systemer eller apps direkte. Plug-ins og enkeltstående koblinger kan være fine, men hvad sker der, når noget går galt, eller når tredje og fjerde system skal med? Hver ny kobling er en selvstændig løsning, der skal bygges, overvåges og vedligeholdes, og antallet af forbindelser vokser hurtigere end antallet af systemer.
Ifølge BusinessWith har en integrationsplatform langt større kapacitet til at håndtere flere systemer på én gang og giver bedre overblik og kontrol. Platformen fungerer som hub, tolk eller knudepunkt, så systemerne taler samme sprog, kan kommunikere, og processerne automatiseres. Dermed kan logik, mapping og fejlhåndtering genbruges på tværs af koblinger i stedet for at blive bygget igen for hver snitflade.
Tommelfingerregel: Ved få systemer, stabile koblinger og ingen forventning om, at flere parter skal genbruge de samme data, kan en-til-en være nok. Når antallet af systemer vokser, eller behovet for overblik og ensartet fejlhåndtering melder sig, holder et centralt knudepunkt arkitekturen håndterbar.
De fire mønstre har hver sin rolle. En-til-en-integration passer til få systemer og stabile koblinger. Centralt knudepunkt passer, når flere systemer skal tale sammen med overblik. API-baseret snitflade dækker en enkelt veldefineret snitflade. iPaaS passer til mange koblinger og ønsket om at undgå dyre licensomkostninger.
Et konkret varsel om at skifte mønster er tredje og fjerde system. Plug-ins og enkeltstående koblinger kan være udmærkede, men de løser ikke forbindelsen, når flere systemer skal med. Så bliver hubben, tolken eller knudepunktet nødvendig.
Eksempel på en-til-en: CRM og ERP forbindes, så en lukket aftale i CRM overføres til ERP til fakturering, ordrehåndtering og regnskab. Eksempel på centralt knudepunkt: Integrationsplatformen sikrer, at systemerne taler samme sprog, kan kommunikere, og at processerne automatiseres.
Eksempel på API-baseret snitflade: Et system stiller data og funktioner til rådighed for andre systemer via API'er. Eksempel på iPaaS: Platformen og integrationerne ligger i skyen, og leverandøren styrer drift og alle opdateringer.
Overvej API-baserede og platformbaserede integrationsmønstre
API'er er den standardiserede måde, hvorpå et system stiller data og funktioner til rådighed for andre systemer. Evidi arbejder med systemintegration og API'er, integrationsarkitektur, Azure Integration Services samt dataplatforme og dataflow. Evidi beskriver integration og arkitektur som grundlaget for sammenhæng, fleksibilitet og videre udvikling på tværs af virksomheden.
Den platformbaserede variant er iPaaS – integrationsplatform som en service. Her ligger platformen og integrationerne i skyen, og leverandøren styrer drift og alle opdateringer. Ifølge BusinessWith er det en af flere fordele ved at flytte integrationerne til skyen; en anden er at undgå dyre licensomkostninger.
Enkelte API-kald kan løse en veldefineret snitflade mellem to systemer. Uden en fælles arkitektur gentages mapping, fejlhåndtering og forretningslogik dog for hver ny kobling.
Evidi peger på, at moderne integrationsarbejde sjældent kun handler om at sammenkoble systemer. Det handler om at etablere en digital serviceplatform, der gør data, processer og tjenester tilgængelige på tværs af organisationen. Det skaber grundlag for hurtigere udvikling og større fleksibilitet, når nye behov opstår.
Arbejdet foregår i Microsofts økosystem. Azure Integration Services, Power Platform og Dynamics 365 er de bærende dele, når integrationer, API'er og digitale serviceplatforme bygges. Dataplatforme og dataflow hører med i samme billede.
Værktøjerne i Microsofts økosystem er Azure Integration Services, Power Platform og Dynamics 365. Dertil kommer dataplatforme og dataflow, som Evidi arbejder med sammen med integrationer og API'er.
Når I skal vælge platform, står BusinessWiths sammenligning af 24 integrationsplatforme centralt. Blandt de navngivne er Antalys, Flowfactory og Arrigoo, men valget bør følge mønstret, ikke omvendt.
Afklar om data skal deles i realtid eller i et kontrolleret flow
CRM- og ERP-integration forbinder de to systemer, så de automatisk deler data – i realtid og uden manuel dobbeltindtastning. Når en aftale lukkes i CRM, overføres relevante data direkte til ERP til fakturering, ordrehåndtering og regnskab. Det fjerner manuelle trin mellem salg og økonomi og gør forecasts mere pålidelige.
Realtid er ikke et krav i alle snitflader. Spørg for hver datavej: Hvor længe må data være forældede i modtagerprocessen, før de ikke kan bruges? En natlig synkronisering kan være nok til stamdata, mens ordrer og fakturering ofte kræver, at posten er overført, inden næste aktivitet starter. Opdages en fejl først timer senere, skal en rutine fastlægge, hvem der retter den, og hvordan berørte parter orienteres.
Uanset hastighed skal flowet designes kontrolleret: Er det hændelsesdrevet eller tidsstyret? Hvordan håndteres rækkefølge og dubletter? Hvad sker der ved genforsøg, og hvor lander poster, der fejler? En synlig fejlliste med en navngiven ejer er en del af mønstret, ikke et tillæg til det.
Hastigheden er i sig selv et mønstervalg. Realtidsintegration overfører posten, når den opstår. Tidsstyret synkronisering samler ændringer op med faste intervaller, fx natligt, og kræver, at modtageren kan arbejde videre med data, der er et døgn gamle.
Et typisk realtidskrav er en lukket aftale i CRM, der skal overføres til ERP, før fakturering, ordrehåndtering og regnskab kan fortsætte. Her kan modtageren ikke arbejde videre med et døgn gammelt data.
Fejlhåndteringen skal være en del af mønstret. En synlig fejlliste med en navngiven ejer, faste rutiner for dubletter, rækkefølge og genforsøg gør flowet kontrolleret. Uden det bliver hastigheden et problem i stedet for en fordel.
Vælg mønster efter antal systemer, kompleksitet og fremtidig vækst
Brug en beslutningsramme frem for en værktøjsliste. Kriterierne, der reelt afgør valget, er antal systemer nu og om to år, antal datadomæner, hvor ofte systemerne ændrer sig, antal parter og ejere samt flowets forretningskritiske betydning, hvis det står stille i et døgn.
Evidi peger på, at systemlandskabet er vokset over tid, efterhånden som behovene ændrede sig. Kravene til data, automatisering, analyse og AI stiger løbende.
Test før beslutningen: Forestil dig, at I tilføjer et tredje og et fjerde system. Hvor mange nye koblinger skal bygges, overvåges og vedligeholdes? Hvor mange steder skal den samme forretningslogik vedligeholdes? Antallet af koblinger og vedligeholdelsespunkter er et godt mål for, hvor meget fleksibilitet mønstret skal levere.
Kriterierne peger hver især på et mønster. Få systemer, stabile koblinger og ingen genbrug på tværs af parter taler for en-til-en-integration. Voksende systemantal og krav om overblik og ensartet fejlhåndtering taler for et centralt knudepunkt. En enkelt veldefineret snitflade kan dækkes af et API-kald, mens mange koblinger og ønsket om at undgå dyre licensomkostninger taler for iPaaS.
Tærsklen er ikke et fast tal, men et konkret spørgsmål: Kan en-til-en stadig håndtere tredje og fjerde system uden at skabe nye selvstændige løsninger? Hvis nej, taler det for centralt knudepunkt.
Mål fleksibiliteten i antal koblinger og vedligeholdelsespunkter. Hver ny kobling er en selvstændig løsning, der skal bygges, overvåges og vedligeholdes, og antallet af forbindelser vokser hurtigere end antallet af systemer.
Vurder drift, ejerskab og økonomi bag integrationsmønstret
Placeringen af integrationen afgør, hvem der driver den. Ved cloudbaseret iPaaS ligger driftsansvaret hos leverandøren. Intern drift kræver egne kompetencer og en vagtordning.
Uanset model skal I beslutte, hvem der overvåger integrationerne, hvem der får alarm om natten, hvem der retter fejl, og hvordan ændringer i de tilsluttede systemers snitflader håndteres. Clouddrift kræver, at I har aftaler om svartider, opdateringer og adgang til fejlhistorik. De fleste vil kun implementere en integrationsplatform én gang, og BusinessWith anbefaler derfor at sammenligne platformene, før valget træffes – deres oversigt dækker 24 forskellige integrationsplatforme.
Blandt de 24 integrationsplatforme i oversigten er Antalys, Flowfactory og Arrigoo. Antalys er et webbaseret værktøj til salgsprocesser, Flowfactory en cloudbaseret low-code-platform, og Arrigoo en Customer Data Platform (CDP). Platformene sorteres efter BW Score og popularitet og er angivet med størrelsesintervaller som 11-500+ og 101-500+.
Opdel økonomien i abonnement eller licens, implementering og opsætning samt løbende drift og vedligehold. Medregn den manuelle arbejdskraft: dobbelt indtastning og manuelle afstemninger mellem CRM og ERP er en løbende omkostning, som integrationen erstatter. Sæt de to beløb op over samme periode, og tag stilling til, hvem der har ansvaret, når leverandøren eller det interne team ikke leverer.
Et økonomisk pejlemærke fra samme oversigt er, at automatisering af arbejdsopgaver kan reducere personligt arbejde. Det er ikke en pris, men et bud på den manuelle arbejdskraft, integrationen kan erstatte.
Sikr datakvalitet og tillid i det samlede flow
Uden integration bliver medarbejderne broen mellem systemerne. Ifølge SuperOffice giver det ikke én version af virksomheden, men to, som sjældent stemmer overens.
Med integration vender billedet: Virksomheder med integrerede CRM- og ERP-systemer rapporterer om betydeligt færre fejl i forecasts, mindre manuel dataindtastning og bedre samarbejde på tværs af teams. Effekten kommer ikke af sig selv, men af hvor kontrollen placeres. Læg validering tæt på kilden, hvor data opstår; aftal hvilke felter der er obligatoriske, og hvem der retter en post, når den er forkert.
Mønstervalget afgør, hvor kontrollen kan placeres. Et centralt knudepunkt giver ét sted at håndtere dubletter, rækkefølge og fejl. En-til-en-koblinger kræver, at den samme kontrol bygges for hver snitflade.
Tillid er et selvstændigt mål, ikke kun teknisk oppetid. Digitaliseringsstyrelsen gennemfører årligt en undersøgelse af borgernes tillid til offentlige digitale løsninger sammen med Danmarks Statistik.
I 2024 viste den, at 88 pct. af borgerne mellem 15 og 89 år anvender offentlige digitale løsninger. Ifølge samme undersøgelse er 78 pct. enige eller meget enige i, at de generelt har tillid til løsningerne. Ca. 24 pct. oplever udfordringer af forskellig art i mødet med den digitale offentlige sektor.
I et integrationsflow er tillid tæt knyttet til, at data er korrekte og sporbare. Læg validering tæt på kilden, aftal obligatoriske felter, og bestem hvem der retter en forkert post. Et centralt knudepunkt giver ét sted at håndtere dubletter, rækkefølge og fejl.
Datakvalitet og tillid i den digitale offentlige sektor
Sådan træffer du beslutningen trin for trin
- Beskriv arbejdsgangen, ikke teknologien. Vælg én konkret proces, og noter hvert trin, hvert system og hver manuel overførsel eller afstemning. Det er de trin, integrationen skal fjerne eller understøtte.
- Kortlæg datadomænerne. For hver posttypekunde, aftale, ordre, faktura – fastlæg, hvor den opstår, hvem der ejer den, hvilket system der er master, og i hvilken retning data skal flyde. Lav feltmappingen med det samme, inklusive hvad der sker ved ændring og sletning.
- Tæl systemer og parter. Noter antallet af systemer nu og forventet om to år, antallet af ejere og den forretningsmæssige kritikalitet. De tal afgør, hvor meget mønstret skal kunne håndtere.
- Beslut hastigheden. Afgør for hver datavej, om modtageren kan arbejde videre med en forsinkelse, eller om posten skal overføres med det samme. Definer samtidig, hvordan fejl, dubletter og genforsøg håndteres, og hvor fejlene ses.
- Beslut drift og økonomi. Vælg mellem intern drift og cloudbaseret platform, og afklar driftsansvar, svartider og omkostninger. Fordel omkostningerne på abonnement, implementering samt løbende drift og vedligehold, og sammenlign platforme, før I vælger, da implementeringen typisk kun gøres én gang.
- Fastlæg datakvalitetsansvaret. Aftal validering ved kilden, obligatoriske felter, hvem der retter fejl, og hvordan I følger kvaliteten over tid. Uden det vender de manuelle trin tilbage – bare et andet sted i processen.
- Vælg mønster og platform med navn. Beslut grundformenen-til-en, centralt knudepunkt, API-baseret snitflade eller iPaaS – før leverandøren. Sammenlign de 24 integrationsplatforme, heriblandt Antalys, Flowfactory og Arrigoo, og bedøm dem efter BW Score, størrelse og driftsmodel.
De fire mønstre, du skal vælge imellem, er en-til-en-integration, centralt knudepunkt, API-baseret snitflade og iPaaS. Værktøjerne omfatter Azure Integration Services, Power Platform og Dynamics 365 samt BusinessWiths oversigt over 24 integrationsplatforme, heriblandt Antalys, Flowfactory og Arrigoo.
Brug kriterierne aktivt: antal systemer nu og om to år, antal datadomæner, ændringshastighed, antal parter og ejere samt kritikalitet. Tredje og fjerde system er det praktiske varsel, der ofte vælter en ren en-til-en-tilgang.
Vælg mønsteret før platformen. Beslut grundformen ud fra kriterierne, og sammenlign derefter platformene efter BW Score, størrelse og driftsmodel. Implementeringen af en integrationsplatform er noget, de fleste kun gør én gang.


