Systemintegration innebär att koppla ihop olika IT-system så att de kan utbyta information automatiskt. I stället för att samma uppgifter matas in manuellt i flera system flödar data direkt mellan dem, vilket gör att alla system arbetar mot samma uppdaterade information.
I praktiken handlar det om att låta systemen prata med varandra utan att en människa behöver agera budbärare. När en order registreras i affärssystemet uppdateras lagersaldot, kundkortet i CRM och underlaget i ekonomisystemet automatiskt, utan export till Excel och utan att någon knappar in samma siffror en gång till.
De system som kopplas ihop är sällan bara två. I en typisk verksamhet handlar det om affärssystemet som nav, tillsammans med CRM, e-handel, lagersystem, transportbokning, fakturaväxel och olika rapporterings- och analysverktyg. Även kalkylark, kommunikationsverktyg och interna databaser räknas in. Så länge ett system kan nås via ett API eller en standardiserad filöverföring går det i regel att integrera.
Varför behovet uppstår
Nästan inget företag börjar med ett komplext systemlandskap. Det växer fram ett system i taget. Ett affärssystem införs, ett CRM läggs till när säljorganisationen växer, en e-handelsplattform startas, ett lagersystem kommer in när volymerna ökar. Varje enskilt val är rationellt, och varje system löser det problem det köptes in för.
Problemet uppstår när systemen inte längre är synkade. Kunddata finns i tre system, med tre olika versioner av samma sanning. Rapporter byggs ihop för hand från flera källor och stämmer inte överens. Beställningar dubbelregistreras. Ingen är riktigt säker på vilket system som har rätt.
Det här är sällan något som märks som ett akut problem. Det växer långsamt och kostar i det tysta, i form av administrativ tid, felaktiga beslut på osäkra underlag och medarbetare som lägger timmar på att flytta information mellan system i stället för att arbeta med verksamheten.
Systemintegration är svaret på det problemet. Målet är inte tekniken i sig, utan att information bara ska behöva registreras en gång och sedan finnas tillgänglig, korrekt och uppdaterad, överallt där den behövs.
Systemintegration handlar om mer än teknik
Det är lätt att se systemintegration som ett IT-projekt. I praktiken är det ett verksamhetsprojekt med teknisk implementation, eftersom en integration alltid speglar ett affärsflöde. En koppling mellan e-handel och affärssystem är egentligen en fråga om hur en order ska hanteras från att kunden klickar på köp till att fakturan är bokförd.
Det gör att de mest lyckade integrationsprojekten sällan börjar i tekniken. De börjar i vardagen, i frågan om var tid faktiskt försvinner idag och vilka flöden som orsakar mest friktion. Först därefter blir det relevant att välja metod, och det är där skillnaderna mellan olika tillvägagångssätt börjar spela roll.
Olika typer av systemintegration
Innan man väljer metod är det värt att skilja på vad som faktiskt ska integreras. Systemintegration används ofta som ett samlingsbegrepp, men i praktiken sker integrationen på tre olika nivåer. De löser olika problem, kräver olika mycket arbete och ger olika typer av värde.
Skillnaden spelar roll eftersom många integrationsprojekt börjar med en ambition på processnivå men levereras på datanivå. Resultatet blir att systemen visserligen delar information, men att arbetssättet i vardagen ser ungefär likadant ut som förut.
Dataintegration
Dataintegration är den mest grundläggande nivån. Här handlar det om att flytta och synkronisera information mellan system så att samma uppgifter finns tillgängliga på flera ställen. Kundregister, artikelregister, prislistor och saldon är typiska exempel.
Utmaningen ligger sällan i själva överföringen, utan i att systemen beskriver samma verklighet på olika sätt. Ett datum kan lagras i olika format, en artikelkod kan ha olika struktur och en kund kan identifieras med organisationsnummer i ett system och ett internt kundnummer i ett annat. Dataintegration innebär därför alltid ett moment av transformation och mappning, där informationen översätts till den struktur som mottagande system förväntar sig.
Den här nivån löser problemet med parallella versioner av samma sanning. Den ger bättre datakvalitet och tillförlitligare rapporter, men den automatiserar inte nödvändigtvis något arbetsmoment i sig.
Applikationsintegration
Applikationsintegration går ett steg längre. Här utbyter systemen inte bara data, utan anropar också funktioner hos varandra. Ett system kan trigga en åtgärd i ett annat, hämta ett svar och agera på det.
Ett konkret exempel är en fraktbokning. Affärssystemet skickar inte bara orderinformation till transportsystemet, utan begär också en bokning, tar emot ett kolliid och en fraktsedel i retur och sparar dem på ordern. Ett annat är en kreditkontroll, där affärssystemet frågar en extern tjänst om en kund får handla på faktura och sedan låter svaret styra hur ordern hanteras.
Applikationsintegration kräver oftast API:er och är mer krävande att bygga än ren dataöverföring, eftersom flödet är dubbelriktat och beroende av svar i realtid. Till gengäld är det här mycket av den faktiska automatiseringen uppstår.
Processintegration
Processintegration är den högsta nivån och den som ger störst verksamhetsnytta. Här är utgångspunkten inte enskilda system utan ett helt affärsflöde, som löper genom flera system från början till slut.
Ett orderflöde i en e-handel kan involvera fem eller sex system. Ordern skapas i webbutiken, valideras och kreditkontrolleras, skapas som order i affärssystemet, plockas i lagersystemet, bokas för transport, faktureras och skickas till fakturaväxeln för elektronisk leverans. Processintegration innebär att hela den kedjan hanteras som ett sammanhängande flöde, med regler för vad som händer i varje steg och vad som ska ske när något går fel.
Det är också här affärslogiken kommer in. Valideringar, beräkningar, undantagshantering och beslutsregler behöver ligga någonstans. Om de byggs in i ett enskilt system blir hela processen beroende av just det systemet. Om de i stället hålls i ett eget lager, frikopplat från de anslutna systemen, kan processen leva vidare även när ett system byts ut. Den skillnaden är avgörande på längre sikt och något vi återkommer till längre ned.
Metoder för systemintegration
Det finns flera sätt att koppla ihop system, och de skiljer sig kraftigt åt i fråga om kostnad, flexibilitet och vad de kräver av er över tid. Ingen metod är objektivt bäst. Det som avgör är hur många system som ska kopplas ihop, hur ofta systemlandskapet förändras och hur mycket ansvar ni vill och kan bära själva.
Nedan går vi igenom de sju vanligaste metoderna, med hur de fungerar, när de passar och vad de kostar er i form av begränsningar.
Manuell filöverföring och export/import
Så fungerar det: Data exporteras ur ett system som en fil, oftast CSV eller Excel, och importeras därefter i ett annat. Ibland sker det via ett schemalagt filsläpp till en delad mapp eller en FTP-server, ibland genom att en medarbetare gör det för hand enligt rutin.
Det här är strängt taget inte systemintegration i teknisk mening, men det är fortfarande så många verksamheter faktiskt löser informationsutbytet mellan sina system. Metoden förtjänar därför att tas med, om inte annat som referenspunkt.
När det passar: Vid låga volymer, för engångsöverföringar, vid migreringar eller när ett system helt saknar tekniska möjligheter till integration.
Fördelar: Kräver ingen utveckling, ingen investering och ingen teknisk kompetens. Det går att komma igång omedelbart.
Nackdelar: Manuellt arbete som skalar linjärt med volymen. Hög risk för fel eftersom ingen validerar innehållet. Ingen spårbarhet över vad som faktiskt överfördes och när. Data är per definition inaktuell mellan överföringarna. Rutinen blir dessutom personberoende, och när den som brukar sköta filerna är sjuk eller slutar stannar flödet.
Punkt-till-punkt-integration
Så fungerar det: En skräddarsydd koppling byggs specifikt mellan två system. Lösningen kan byggas som ett plugin eller en anpassning i ett av systemen, eller som ett fristående program som hanterar just den kopplingen.
Det här är den klassiska integrationsmetoden och fortfarande den vanligaste för mindre systemlandskap. Varje koppling är sin egen lösning, med egen kod, egen felhantering och egen livscykel.
När det passar: När ett fåtal system ska kopplas ihop, när flödet är stabilt över tid och när systemlandskapet inte förväntas växa nämnvärt.
Fördelar: Kan byggas exakt efter behov utan kompromisser. Ofta snabb och billig att få på plats när det handlar om en enda koppling. Inga plattformsavgifter.
Nackdelar: Antalet kopplingar växer snabbare än antalet system. Redan vid fem system som ska prata med varandra kan det handla om tio separata kopplingar att underhålla. Kunskapen sitter ofta hos den som byggde lösningen, vilket skapar personberoende. Varje förändring i något av de anslutna systemen kan bryta kopplingen, och vid ett systembyte måste i praktiken samtliga kopplingar mot det systemet byggas om. Den tekniska skulden växer för varje ny integration.
API-integration
Så fungerar det: Systemen kommunicerar via API:er, alltså definierade gränssnitt som gör att applikationer kan skicka och hämta data från varandra. Ett system anropar ett annat systems API, skickar med information och tar emot ett svar, oftast i realtid och i ett strukturerat format som JSON eller XML.
API är i grunden inte en arkitektur utan en teknik. Det säger något om hur systemen kommunicerar, men inte hur kopplingarna organiseras. En API-integration kan därför byggas som en punkt-till-punkt-lösning eller som en del av en integrationsplattform. Det är en viktig skillnad som ofta blandas ihop.
När det passar: När moderna system med väldokumenterade API:er ska kopplas ihop och när flödet kräver att data är aktuell direkt, inte i slutet av dagen.
Fördelar: Data överförs i realtid. Strukturerade format minskar tolkningsproblem. De flesta moderna system, särskilt molntjänster, är byggda med API som primär integrationsväg. Dubbelriktad kommunikation gör det möjligt att både skicka och hämta information samt trigga åtgärder.
Nackdelar: Kvaliteten varierar kraftigt mellan leverantörer. Vissa API:er är begränsade i funktionalitet, andra har anropsbegränsningar som gör dem olämpliga för stora volymer. Äldre system saknar ofta API helt. API:er förändras dessutom över tid, och när en leverantör släpper en ny version behöver integrationen uppdateras. Utan ett samlande lager blir varje API-koppling ännu en enskild integration att förvalta.
EDI och filbaserad standardintegration
Så fungerar det: Affärsdokument som ordrar, fakturor och leveransaviseringar utbyts i standardiserade format enligt överenskomna regelverk, ofta via en operatör snarare än direkt mellan parterna.
Här är det värt att skilja på två saker som ofta blandas ihop. EDIFACT är en meddelandesyntax, alltså ett sätt att strukturera själva dokumentet, och är fortfarande dominerande i många branscher. Peppol är både och: Peppol BIS är formatfamiljen, byggd på XML-standarden UBL, medan Peppol samtidigt är en transportinfrastruktur där parterna ansluter via certifierade accesspunkter och når varandra genom sina Peppol-ID. Att ”skicka via Peppol” syftar på infrastrukturen, inte på formatet.
Till skillnad från API-integration, som handlar om att koppla ihop era egna system, används EDI framför allt för att utbyta dokument med externa parter, alltså kunder, leverantörer och myndigheter. Kravet kommer därför ofta utifrån. En större kund ställer krav på EDI-order som villkor för att handla, eller så säljer ni till offentlig sektor.
Just offentlig sektor är värt en egen not, eftersom kravet där är reglerat. Fakturor som utfärdas till följd av offentlig upphandling påbörjad från och med 1 april 2019 ska vara elektroniska och följa den europeiska standarden EN 16931. PDF-fakturor och inskannade pappersfakturor räknas inte som e-faktura i lagens mening. Upphandlingsmyndigheten rekommenderar formatet Peppol BIS Billing 3 för att uppfylla kravet.
När det passar: Vid dokumentutbyte med handelspartner, i branscher där EDI är etablerad praxis och vid all försäljning till offentlig sektor.
Fördelar: Standardiserade format innebär att samma integration i grunden fungerar mot många motparter. Väl etablerat och beprövat över lång tid. Uppfyller regulatoriska krav på elektronisk fakturering. Hanterar stora dokumentvolymer effektivt. Med Peppol tillkommer fördelen att ni bara behöver en anslutning för att nå samtliga parter i nätverket, i stället för separata överenskommelser med varje motpart.
Nackdelar: Standarderna är omfattande och tolkas dessutom olika av olika parter, vilket i praktiken gör att varje motpart kan kräva viss anpassning trots att formatet är standardiserat. Filerna är sällan läsbara utan verktyg, vilket försvårar felsökning. Uppdateringar av standarder och regelverk kräver löpande underhåll. Ofta krävs en extern operatör, vilket lägger till ytterligare en part i kedjan och en kostnad som är lätt att missa i kalkylen.
Integrationsplattform (iPaaS)
Så fungerar det: En integrationsplattform löser samma grundproblem som ett ESB, alltså att samla integrationerna i ett gemensamt lager, men levereras som en tjänst där leverantören ansvarar för drift, uppdateringar och infrastruktur. Systemen kopplas till plattformen, som hanterar anslutningar, datatransformation, affärslogik, schemaläggning och felhantering.
Begreppet iPaaS etablerades av det amerikanska analysföretaget Gartner, som definierade kategorin i en forskningsrapport 2011. Gartner definierar iPaaS som en leverantörsdriven molntjänst som gör det möjligt att bygga integrationer mellan applikationer, tjänster och datakällor, både inom och utanför den egna organisationen. Modellen är alltså i grunden molnbaserad, och just leverantörsansvaret för driften är en definierande egenskap snarare än ett säljargument. On-prem-varianter förekommer när systemlandskapet eller säkerhetskraven inte tillåter molndrift.
Det som skiljer en plattform från enskilda integrationer är återanvändbarheten. Nya kopplingar byggs med färdiga integrationsmoduler och byggblock som redan är testade i drift, kompletterat med det som är unikt för verksamheten. Varje ny integration blir därför i regel billigare än den förra i stället för dyrare.
Affärslogiken kan dessutom hållas i ett eget lager, frikopplat från de anslutna systemen. Valideringar, beräkningar och flödesregler ligger i plattformen, inte inbyggda i affärssystemet. Konsekvensen märks vid förändring: byts ett system ut behöver bara kopplingsskiktet mot det systemet skrivas om, medan flöden och regler lever kvar.
När det passar: När fler än ett par system ska kopplas ihop, när systemlandskapet blandar molntjänster och lokala system, när verksamheten förväntas växa eller byta system, och när ni inte vill bygga upp egen integrationskompetens internt.
Fördelar: Samlad överblick över samtliga flöden, oftast via en dashboard i realtid som visar vad som körs, när det körs och varför. Färdiga moduler ger snabbare uppsättning. Jobbköer, schemaläggning, felhantering och återförsök är inbyggt, så flöden fortsätter fungera även om ett system tillfälligt är nere eller når sina anropsgränser. Leverantören ansvarar för drift och förvaltning, vilket sänker personberoendet. Uppdateringar och förbättringar kommer alla kunder till del. Lägre teknisk skuld över tid.
Nackdelar: Innebär ett beroende till en leverantör och en löpande kostnad snarare än en engångsinvestering. Kräver att man väljer partner med omsorg, eftersom plattformen blir en central del av verksamhetens infrastruktur. För en verksamhet med två system och ett enda enkelt flöde kan en plattform vara mer struktur än behovet motiverar.
RPA och robotisering som genväg
Så fungerar det: En mjukvarurobot utför samma steg som en människa skulle göra i systemens användargränssnitt. Roboten loggar in, klickar sig fram, läser av fält, kopierar värden och matar in dem i nästa system. Ingen teknisk koppling upprättas mellan systemen, utan automatiseringen sker på ytan.
RPA används ofta som lösning när ett system saknar API eller när IT-avdelningen har långa ledtider. Verksamheten löser problemet själv, och på kort sikt fungerar det ofta förvånansvärt bra.
När det passar: Mot äldre system som helt saknar integrationsmöjligheter, som en tillfällig lösning i väntan på riktig integration, eller för lågvolymsflöden som är svåra att motivera ekonomiskt på annat sätt.
Fördelar: Fungerar mot i princip vilket system som helst, eftersom roboten bara behöver kunna se skärmen. Kräver ingen medverkan från systemleverantören. Kan sättas upp snabbt och ofta av verksamheten själv.
Nackdelar: Metoden är ömtålig. Ändras ett fält eller en knapp i användargränssnittet slutar roboten fungera, och det upptäcks ofta först när något redan gått fel. Ingen egentlig validering av data sker. Felhanteringen är svag, eftersom roboten inte förstår vad den hanterar. Prestandan är begränsad av gränssnittets hastighet, vilket gör metoden olämplig för volym. Framför allt döljer RPA det underliggande problemet i stället för att lösa det, och organisationen bygger successivt upp en flora av robotar som ingen har full överblick över. Betrakta det som ett plåster, inte som en arkitektur.
Jämförelse av integrationsmetoder
Tabellen nedan sammanfattar skillnaderna mellan metoderna. Notera särskilt kolumnen för underhållsansvar, eftersom det är den post som oftast underskattas när ett integrationsprojekt kalkyleras.
| Metod | Komplexitet att komma igång | Skalbarhet | Underhållsansvar | Passar bäst när |
|---|---|---|---|---|
| Manuell filöverföring | Mycket låg | Ingen | Ni, som manuell rutin | Låga volymer, engångsbehov, system utan integrationsstöd |
| Punkt-till-punkt | Låg till medel | Låg | Ni, eller konsult per uppdrag | Två till tre stabila system, litet systemlandskap |
| API-integration | Medel | Medel | Ni, eller konsult per uppdrag | Moderna system, behov av realtid |
| EDI och Peppol | Medel till hög | Medel | Delat med operatör | Dokumentutbyte med kunder, leverantörer, offentlig sektor |
| Middleware och ESB | Hög | Hög | Ni, med egen kompetens internt | Stora organisationer, lokala miljöer, höga säkerhetskrav |
| Integrationsplattform (iPaaS) | Låg till medel | Hög | Leverantören | Flera system, blandad miljö, verksamhet i förändring |
| RPA | Låg | Mycket låg | Ni, löpande och ofta oplanerat | System utan API, tillfällig lösning |
Ett mönster framträder tydligt. Metoderna längst upp i tabellen är billigast att komma igång med och dyrast att leva med. Metoderna längre ned kräver mer eftertanke i början men flyttar kostnaden från löpande underhåll till en förutsägbar struktur.
Det är också viktigt att komma ihåg att metoderna inte utesluter varandra. De flesta verksamheter använder flera parallellt, exempelvis API mot molntjänster, EDI mot handelspartner och filöverföring mot något äldre system. Frågan är sällan vilken metod ni ska välja, utan om de olika kopplingarna ska hanteras var för sig eller samlas i ett gemensamt lager.
Batch eller realtid, hur data flödar mellan systemen
Vid sidan av valet av metod finns ett annat beslut som påverkar både kostnad och användarupplevelse: hur ofta data ska flöda. En integration kan köras kontinuerligt eller i schemalagda omgångar, och skillnaden märks direkt i verksamheten.
Frågan ställs sällan explicit i början av ett projekt, men den avgör hur ett flöde upplevs i vardagen. En order som syns i lagersystemet inom några sekunder ger en helt annan arbetssituation än en order som dyker upp först nästa morgon.
Batchöverföring
Vid batchöverföring samlas data upp och överförs i omgångar enligt ett schema. Det kan vara varje natt, varje timme eller flera gånger per dag. Alla poster som skapats sedan förra körningen skickas som ett paket.
Modellen är resurseffektiv och lämpar sig väl för stora datamängder. Den belastar systemen mindre eftersom överföringarna sker koncentrerat, gärna vid tidpunkter med låg aktivitet. Felsökningen blir dessutom enklare, eftersom en körning går att granska som en avgränsad enhet med tydlig start och tydligt slut.
Nackdelen är fördröjningen. Mellan två körningar är mottagande system per definition inaktuellt. Om något går fel i en nattkörning upptäcks det ofta först på morgonen, när felet redan hunnit påverka arbetet. Batch passar därför sämre för flöden där någon fattar beslut baserat på informationen i realtid.
Realtidsintegration
Vid realtidsintegration skickas informationen i samma stund som händelsen inträffar. En order som registreras utlöser omedelbart nästa steg i kedjan.
Tekniskt sker det på några olika sätt. Direkta API-anrop är vanligast, där ett system anropar ett annat och väntar på svar. Webhooks vänder på logiken genom att ett system aktivt meddelar övriga att något har hänt, i stället för att någon behöver fråga. Meddelandeköer används när flödet ska vara robust snarare än omedelbart svarande: den sändande parten lägger meddelandet i en kö och kan gå vidare, medan mottagaren hämtar det när den är redo. Den sista modellen är ofta den mest hållbara i praktiken, eftersom den klarar att mottagande system är tillfälligt otillgängligt.
Fördelen med realtid är uppenbar. Alla system speglar samma verklighet vid samma tidpunkt. Kunden ser rätt lagersaldo, säljaren ser rätt kreditgräns och supporten ser rätt orderstatus. Fel upptäcks dessutom direkt, medan sammanhanget fortfarande är känt och det går att åtgärda innan konsekvenserna sprider sig.
Priset är högre komplexitet. Realtidsflöden ställer krav på att mottagande system är tillgängligt, och när det inte är det behövs en genomtänkt hantering av köer och återförsök. Utan den infrastrukturen riskerar poster att tappas bort utan att någon märker det. Många system har dessutom anropsbegränsningar, både i form av tak för antalet samtidiga anrop och gränser per minut och dygn. NetSuite är ett tydligt exempel, där samtliga integrationer mot samma konto delar på ett gemensamt utrymme. Det gör att höga volymer i ren realtid sällan fungerar utan någon form av styrning av flödestakten.
Så väljer ni rätt för olika flöden
Valet är sällan antingen eller. De flesta verksamheter behöver båda, och nyckeln ligger i att bedöma varje flöde för sig.
Utgå från en enkel fråga: vad kostar det om informationen är en timme gammal? För ett lagersaldo i en e-handel som säljer i hög takt kan svaret vara överförsäljning och besvikna kunder, alltså realtid. För en huvudbokssammanställning till ekonomisystemet är svaret oftast ingenting alls, alltså batch varje natt.
En användbar tumregel är att flöden som någon väntar på ska gå i realtid, medan flöden som ingen väntar på kan gå i batch. Ordrar, saldon, kreditkontroller och fraktbokningar hamnar i den första kategorin. Bokföringsunderlag, artikeluppdateringar, statistik och rapportunderlag hamnar oftast i den andra.
Det är också värt att notera att valet inte behöver vara permanent. I en integrationsplattform är frekvensen en konfigurationsfråga snarare än en arkitekturfråga, vilket gör att ett flöde kan flyttas från nattkörning till realtid när verksamheten kräver det. I en skräddarsydd punkt-till-punkt-lösning innebär samma förändring ofta en ombyggnad.
Fördelar med systemintegration
Nyttan med systemintegration beskrivs ofta i övergripande termer som effektivitet och digitalisering. Nedan är fördelarna brutna ned i det som faktiskt går att mäta och märka.
Mindre manuellt arbete
Den mest omedelbara effekten är att administrativa moment försvinner. Information som registreras en gång finns tillgänglig överallt där den behövs, utan export, import eller dubbelregistrering.
Effekten underskattas ofta eftersom arbetet är utspritt. Tio minuter här och en kvart där ser inte ut som ett problem i en enskild vardag, och det syns sällan i någon rapport. Ett enkelt sätt att få grepp om storleken är att räkna på ett konkret flöde: hur många gånger i veckan utförs momentet, hur lång tid tar det och hur många personer är inblandade? Multiplicerat över ett år brukar summan förvåna, även när varje enskild insats är liten.
Värdet ligger inte enbart i besparingen. Det ligger i vad tiden används till i stället, alltså kundkontakt, analys och utveckling snarare än att flytta data mellan fönster. Till det kommer en effekt som är svårare att kvantifiera, nämligen att arbetsdagen slutar fragmenteras av småuppgifter som bryter koncentrationen.
Högre datakvalitet
Varje manuell överföring är ett tillfälle för fel att uppstå. En siffra som blir fel, ett fält som glöms bort, en rad som hamnar på fel plats. Felen är sällan dramatiska var för sig, men de ackumuleras och urholkar successivt förtroendet för systemen.
När data flödar automatiskt försvinner den felkällan. Lika viktigt är att en integration kan validera information innan den släpps vidare. Saknas ett obligatoriskt fält eller stämmer inte ett värde mot förväntat format kan flödet stoppa posten och flagga den, i stället för att låta felet spridas vidare i kedjan.
Resultatet är att organisationen slutar arbeta mot flera parallella versioner av samma sanning. Frågan om vilket system som har rätt behöver helt enkelt inte längre ställas.
Snabbare processer och kortare ledtider
Integration komprimerar tid som annars går åt till väntan. En order som tidigare låg och väntade på nästa manuella körning kan behandlas direkt. En faktura som tidigare skickades i en veckovis omgång kan gå ut samma dag.
Effekten på kassaflödet är konkret. Kortare tid från leverans till fakturering innebär kortare tid till betalning. Automatiserad e-fakturering och digital leverans förkortar dessutom det sista steget, från att fakturan skapas till att den faktiskt når mottagaren.
För kunden märks det i form av snabbare orderbekräftelser, mer träffsäkra leveransbesked och färre situationer där ingen kan svara på var en order befinner sig.
Bättre beslutsunderlag
När rapporter byggs manuellt från flera källor uppstår två problem. Sammanställningen tar tid, vilket gör att den görs sällan, och den bygger på data som redan är inaktuell när den är klar.
Med integrerade system kan rapportering och analys hämta data från en enda, uppdaterad källa. Det gör underlagen både snabbare att ta fram och mer tillförlitliga. Verksamheten kan gå från månatliga tillbakablickar till löpande uppföljning.
Det finns också ett underskattat värde i insynen i flödena i sig. När det går att se vad som körs, när det körs och varför, blir det möjligt att upptäcka flaskhalsar som annars är osynliga.
Ökad skalbarhet
Manuella rutiner skalar linjärt. Dubbla ordervolymen och behovet av administrativ tid dubbleras med den. Det innebär att tillväxt kräver nyanställningar i funktioner som inte skapar värde i sig.
Automatiserade flöden bryter det sambandet. Volymökningen kräver inte fler händer, eftersom flödet kör samma logik oavsett om det handlar om hundra eller tusen poster. Däremot är det en missuppfattning att automatiserade flöden skalar helt utan eftertanke. Vid högre volymer blir de anropsbegränsningar som beskrivs ovan verkliga, och flödet kan behöva köras annorlunda, exempelvis genom att poster samlas i grupper, fördelas över tid eller går via en kö i stället för som direkta anrop.
Skillnaden ligger i vad den anpassningen kostar. I en integrationsplattform är takt, batchstorlek och köhantering konfigurationsfrågor som justeras i den befintliga lösningen. I en skräddarsydd punkt-till-punkt-lösning innebär samma anpassning ofta att integrationen behöver byggas om, eftersom den infrastrukturen sällan finns på plats från början.
Skalbarheten gäller också systemlandskapet i stort. Med rätt arkitektur går det att lägga till ett nytt system, en ny försäljningskanal eller en ny marknad utan att bygga om det som redan fungerar.
Nackdelar och utmaningar med systemintegration
Systemintegration löser verkliga problem, men det vore missvisande att beskriva det som friktionsfritt. De flesta utmaningarna handlar mindre om att bygga integrationen och mer om att leva med den.
Teknisk skuld som växer med varje ny koppling
Den vanligaste fallgropen är också den mest smygande. Varje enskild integration som byggs som en fristående lösning är fullt rimlig i stunden. Problemet uppstår i summan.
Räkna på det. Tre system som ska prata med varandra kräver upp till tre kopplingar. Fem system kräver upp till tio. Åtta system kräver upp till 28. Varje koppling har egen kod, egen felhantering och egen dokumentation, och varje koppling behöver underhållas när något av de anslutna systemen förändras.
Efter några år har många verksamheter en väv av kopplingar som ingen har full överblick över. Ingen vet säkert vad som händer om en av dem stängs av, vilket gör att ingen vågar röra något. Systemlandskapet blir svårt att förändra just när verksamheten som mest behöver kunna förändra det.
Personberoende och kunskap som försvinner
Integrationer byggs av någon, och den kunskapen har en tendens att stanna i huvudet på den personen. I en traditionell konsultmodell blir det extra tydligt: konsulten bygger lösningen, levererar den och går vidare till nästa kund. Dokumentationen är i bästa fall skriven vid leverans och i praktiken sällan uppdaterad efter det.
Samma sak gäller internt. När den utvecklare eller systemansvarige som byggde flödena byter jobb försvinner ofta förståelsen för varför saker är byggda som de är. Kvar finns kod som fungerar, men som ingen vågar ändra i.
Konsekvensen är att förändringar blir dyra och riskfyllda. En liten justering kräver att någon först återskapar förståelsen av hela flödet.
Äldre system och begränsade API:er
Inte alla system vill bli integrerade. Äldre affärssystem och branschspecifika lösningar saknar ofta API helt, och där det finns ett API är kvaliteten ojämn. Vissa täcker bara en del av funktionaliteten, andra har anropsbegränsningar som gör dem olämpliga för volym, och en del är knapphändigt dokumenterade.
Det finns också ett affärsmässigt lager i problemet. Alla systemleverantörer ser inte integration som något önskvärt, eftersom öppenhet gör det enklare för kunden att byta ut delar av landskapet. Integrationsmöjligheter kan därför vara begränsade eller prissatta separat.
Praktiskt innebär det att integrationsarbetet ofta kräver kreativitet, exempelvis filbaserade lösningar, direkt databasåtkomst eller mellanlager som kompenserar för det som API:et inte klarar. Det går att lösa, men det är sällan lika elegant som dokumentationen antyder.
Vad som händer vid systembyte
Den utmaning som kostar mest, och som märks tydligast, uppstår vid ett systembyte. Byts affärssystemet ut måste varje enskild koppling till det systemet i regel byggas om från grunden, oavsett hur väl den fungerade tidigare.
Orsaken är att affärslogiken i många lösningar sitter hårt knuten till det specifika systemet. Valideringsregler, beräkningar och flödeslogik är byggda direkt i eller mot ERP-systemet, och när systemet försvinner följer logiken med.
Det innebär att ett ERP-byte i praktiken blir två projekt: ett systembyte och ett fullständigt omtag på integrationerna. Det senare underskattas nästan alltid i kalkylen, både i tid och i kostnad, och det är inte ovanligt att integrationsarbetet blir den dyraste delen av bytet.
Det finns arkitekturer som hanterar detta betydligt bättre, och skillnaden ligger i var affärslogiken placeras. Hålls den i ett eget lager, frikopplat från det enskilda systemet, påverkas inte reglerna och flödena av att ett system byts ut. Då behöver bara kopplingsskiktet mot det nya systemet skrivas om, medan konfigurerade flöden, valideringar och regler lever kvar.
Säkerhet och GDPR vid systemintegration
Det finns en aspekt av systemintegration som sällan tas upp i tekniska diskussioner men som nästan alltid dyker upp i beslutsprocessen: vad som händer med personuppgifter när data börjar röra sig automatiskt.
Frågan är befogad. En integration förändrar inte bara hur snabbt information rör sig, utan också hur många ställen den finns på. Det som tidigare låg i ett system ligger efter integrationen i tre, och det som en person tidigare aktivt valde att exportera flyttas nu utan att någon fattar ett beslut vid varje tillfälle.
Integration flyttar personuppgifter, inte bara data
I praktiken innehåller de flesta affärsflöden personuppgifter. En order rymmer namn, adress, telefonnummer och e-post. Ett kundregister rymmer kontaktpersoner. Ett supportärende kan rymma betydligt mer än så.
Den vanligaste fallgropen är också den enklaste att undvika. När en integration byggs är det frestande att synka hela poster, eftersom det är mindre arbete än att välja fält. Resultatet blir att personnummer, födelsedatum eller fritextfält med känsligt innehåll följer med till system som aldrig behövt dem.
Principen om uppgiftsminimering i dataskyddsförordningen säger att personuppgifter ska begränsas till vad som är nödvändigt för ändamålet. Översatt till integrationsarbete betyder det en konkret fråga vid varje fält: behöver mottagande system faktiskt den här uppgiften för att göra sitt jobb? Ett lagersystem behöver leveransadress, men sällan personnummer.
Att välja fält medvetet vid uppsättningen är dessutom betydligt billigare än att rensa i efterhand, när uppgifterna redan spridit sig till fem system.
Vem ansvarar för vad
När en extern leverantör hanterar era flöden uppstår en ansvarsfördelning som behöver vara dokumenterad. Ni förblir personuppgiftsansvariga, eftersom det är er verksamhet som bestämmer ändamålet med behandlingen. Leverantören blir personuppgiftsbiträde, eftersom de behandlar uppgifterna för er räkning.
Det kräver ett personuppgiftsbiträdesavtal, och avtalet bör vara på plats innan det första flödet driftsätts, inte efteråt. Det ska bland annat reglera vad leverantören får göra med uppgifterna, vilka underbiträden som anlitas, vilka säkerhetsåtgärder som gäller och hur ni informeras vid en incident.
Fråga också hur leverantörens egen personal hanterar åtkomst. Vid felsökning behöver någon i praktiken kunna se innehållet i ett meddelande som fastnat, och det innehållet kan vara en kunds fullständiga uppgifter. Det ska finnas rutiner för det, inte bara god vilja.
Var data behandlas
Geografin spelar roll. För uppgifter som stannar inom EU och EES är utgångspunkten okomplicerad. Så snart behandlingen sker utanför området tillkommer krav på en giltig överföringsgrund.
För överföringar till USA finns ett särskilt regelverk, och det är i skrivande stund giltigt. Samtidigt är det överklagat till EU-domstolen, som tidigare har ogiltigförklarat två föregångare till samma regelverk. Utfallet är alltså inte givet.
Slutsatsen för er del bör inte vara att undvika amerikanska tjänster, utan att veta var era uppgifter faktiskt behandlas och att inte bygga en arkitektur som förutsätter att dagens regler gäller för evigt. Det är i grunden samma resonemang som gäller vid ett systembyte: det som är löst kopplat går att flytta, det som är hårt inbyggt gör det inte.
Konkret betyder det tre frågor till varje leverantör. Var lagras och behandlas data? Vilka underleverantörer är inblandade, och var finns de? Vad krävs för att flytta behandlingen om förutsättningarna ändras?
Loggar, felköer och testmiljöer
Här finns de problem som oftast förbises, eftersom de uppstår vid sidan av det egentliga flödet.
En integrationsplattform loggar vad som körs, vilket är själva poängen med spårbarhet. Men loggarna innehåller ofta hela meddelanden, och därmed personuppgifter. Utan en genomtänkt gallringsrutin byggs ett parallellt arkiv upp som ingen räknat med och som ingen gallrar. Ta reda på hur länge loggar sparas och om innehållet kan maskeras.
Samma sak gäller meddelanden som fastnar. När en post inte går att leverera hamnar den någonstans, ofta i en felkö där den kan ligga kvar länge. Det är i praktiken ett register över personuppgifter utan tydlig ägare. Det behöver ingå i era rutiner.
Testmiljöer är den tredje. Att kopiera produktionsdata till test är bekvämt och mycket vanligt, men det innebär att skarpa personuppgifter hamnar i en miljö med lägre säkerhet och bredare åtkomst. Använd anonymiserade eller syntetiska testdata i stället.
Rätten till radering blir både svårare och enklare
Ett splittrat systemlandskap gör raderingsbegäranden besvärliga. När en kund begär att uppgifterna tas bort måste någon leta rätt på dem i varje system, och risken att missa ett är påtaglig när ingen har full överblick.
Integration förvärrar det problemet om den byggs oreflekterat, eftersom kopior sprids till fler ställen. Men den kan också lösa det. Ett kartlagt systemlandskap där det är dokumenterat vilka uppgifter som flödar vart är i sig en förutsättning för att kunna svara på frågan var en persons uppgifter finns. Och ett flöde som kan skapa och uppdatera en kundpost kan i regel också raderas eller anonymiseras genom samma väg.
Vilket av utfallen ni får avgörs vid designen, inte i efterhand. Ta med raderingsflödet som ett eget krav från början, i stället för att upptäcka behovet vid första begäran.
Säkerhet i praktiken
Utöver de rättsliga frågorna finns de tekniska grundkraven, som är desamma oavsett bransch. Data ska vara krypterad både under överföring och i vila. Autentisering ska ske med hanterade nycklar eller tokens, inte med lösenord som ligger i klartext i en konfigurationsfil. Åtkomst till plattformen ska vara personlig och rollstyrd, så att det går att se vem som gjort vad. Och en integration ska ha ett eget konto med minsta möjliga behörighet i varje anslutet system, inte administratörsrättigheter för att det var enklast vid uppsättningen.
Det sista är värt att understryka. Integrationskonton med för breda rättigheter är en av de vanligaste svagheterna i annars välbyggda systemlandskap, just för att de sätts upp en gång och sedan aldrig ses över.
Vanliga misstag vid systemintegration
Fem fallgropar återkommer i projekt efter projekt.
- Att börja i tekniken i stället för i verksamheten. Frågan om vilket protokoll som ska användas är ointressant innan någon kartlagt var tiden faktiskt försvinner idag. Integrationer som byggs utan förankring i ett verkligt flöde tenderar att automatisera fel saker.
- Att glömma bort felhanteringen. Många integrationer byggs för att hantera det normala fallet. Vad som händer när ett system är nere, när en post saknar obligatoriska fält eller när samma order skickas två gånger avgörs först när det inträffar i produktion.
- Att underskatta datakvaliteten i källsystemet. En integration flyttar det som finns, inklusive dubbletter, felstavade kundnamn och inaktuella artikelregister. Utan städning innan driftsättning sprids problemet i stället för att lösas.
- Att inte planera för förvaltning. Ett integrationsprojekt har ett slutdatum, men en integration har inte det. API:er versioneras, standarder uppdateras och verksamheter förändras. Utan ett tydligt svar på vem som ansvarar för flödet om ett år blir underhållet något som hanteras först när det redan gått fel.
- Att bygga för det systemlandskap ni har idag. Om lösningen förutsätter att inget någonsin byts ut kommer den att behöva byggas om. Fråga alltid tidigt vad som händer med flödena den dag ett av systemen ersätts.
Så går ett systemintegrationsprojekt till
Även om omfattningen varierar kraftigt följer de flesta integrationsprojekt samma grundstruktur. Nedan är stegen i den ordning de brukar behöva komma.
Kartläggning av systemlandskapet
Arbetet börjar med att förstå nuläget. Vilka system finns, vilken information hanteras i vilka, och var uppstår friktionen i vardagen?
Kartläggningen bör utgå från flöden snarare än från system. I stället för att lista integrationer som vore önskvärda är frågan hur en order, en faktura eller en kund faktiskt rör sig genom verksamheten idag, och var i den resan någon manuellt flyttar information.
Det är också här prioriteringen görs. Sällan är allt lika angeläget, och det finns nästan alltid ett eller två flöden som står för merparten av den förlorade tiden. Att börja där ger snabbast effekt och skapar dessutom förtroende för fortsättningen.
Design och val av metod
När flödena är kartlagda blir de tekniska valen konkreta. Vilken metod passar varje koppling, ska flödet gå i realtid eller batch, hur ska data mappas mellan systemen och var ska affärslogiken ligga?
I det här skedet avgörs också hur mycket som kan byggas med befintliga, redan testade komponenter och hur mycket som behöver skräddarsys. Ju mer som vilar på standardiserade byggblock, desto lägre blir både uppstartskostnaden och den långsiktiga förvaltningskostnaden.
En förutsättning för att lösningen ska gå att förvalta är att besluten dokumenteras och versionshanteras löpande. Varför ett fält mappas på ett visst sätt är trivialt när beslutet fattas och närmast omöjligt att rekonstruera två år senare.
Test och driftsättning
Integrationer testas i en separat testmiljö innan de går i produktion. Det låter självklart, men steget hoppas över oftare än man tror, särskilt när tidsplanen är pressad.
Testerna behöver täcka mer än det normala fallet. Vad händer med ofullständiga poster, med dubbletter, med stora volymer och med ett mottagande system som inte svarar? Det är i undantagen som integrationer vanligtvis havererar, inte i standardflödet.
Driftsättningen sker med fördel stegvis, gärna med ett första flöde i drift innan nästa byggs. Det ger möjlighet att fånga problem tidigt och låter organisationen vänja sig vid det nya arbetssättet i lagom takt.
Drift och förvaltning över tid
Här börjar den längsta fasen, och det är den som avgör om investeringen håller. Flöden behöver övervakas, avvikelser behöver upptäckas och åtgärdas, och när ett API ändras eller en standard uppdateras behöver integrationen följa med.
Den avgörande frågan är vem som bär det ansvaret. I en projektbaserad modell landar det hos er när konsulten är klar. I en plattformsmodell ligger det hos leverantören, som ansvarar för drift, övervakning och uppdateringar löpande.
Insyn är lika viktig som ansvar. Utan möjlighet att se vad som körs, när det körs och varför, blir det svårt att felsöka och ännu svårare att lita på att flödena faktiskt fungerar som de ska.
När räcker enskilda integrationer och när behövs en plattform?
Alla verksamheter behöver inte en integrationsplattform. Frågan är var brytpunkten går, och den handlar mindre om företagets storlek än om systemlandskapets karaktär.
Enskilda integrationer räcker oftast när ni har två eller tre system som ska kopplas ihop, när flödena är stabila och sällan förändras, när systemen inte förväntas bytas ut inom överskådlig tid och när ni har någon internt som både kan och hinner underhålla lösningen.
En plattform blir motiverad när något av följande stämmer in. Antalet system har passerat en handfull och kopplingarna börjar bli svåra att överblicka. Systemlandskapet blandar molntjänster och lokala system. Verksamheten växer, antingen i transaktionsvolym, till en ny marknad eller genom en ny försäljningskanal. Ett systembyte ligger i korten inom några år. Eller ni saknar helt enkelt interna resurser att förvalta integrationer löpande och vill lägga det ansvaret hos någon annan.
Ett enkelt sätt att pröva frågan är att räkna kopplingar i stället för system. Så länge det handlar om ett par kopplingar är enskilda lösningar rimliga. När antalet närmar sig tio, och särskilt när flera av dem berör samma system, blir kostnaden för att underhålla dem var för sig snabbt högre än kostnaden för att samla dem.
Historiskt avvaktade mindre och medelstora företag med den investeringen, eftersom traditionella integrationsplattformar var kostsamma och krävde egen kompetens att förvalta. Med iPaaS-modellen, där leverantören ansvarar för drift och underhåll, har tröskeln sänkts betydligt.
Vill ni gå djupare i hur en plattform fungerar, vad den innehåller och hur den skiljer sig från traditionella lösningar rekommenderar vi vår kompletta guide: Vad är en integrationsplattform (iPaaS)?
Vanliga frågor om systemintegration
Vad är skillnaden mellan systemintegration och API-integration?
Systemintegration är det övergripande begreppet för att koppla ihop IT-system så att de kan utbyta information. API-integration är en av flera metoder för att göra det, där kopplingen sker via systemens API:er. Andra metoder är exempelvis filöverföring, EDI och integration via en plattform.
Vad kostar systemintegration?
Kostnaden varierar kraftigt beroende på antalet system, flödenas komplexitet och vilken metod som väljs. En enskild koppling mellan två moderna system med väldokumenterade API:er är betydligt billigare än ett flöde som löper genom fem system med mycket affärslogik. Räkna alltid med två poster: en uppstartskostnad för kartläggning och uppsättning, samt en löpande kostnad för drift och förvaltning. Den senare glöms ofta bort i kalkylen.
Hur lång tid tar ett integrationsprojekt?
Ett avgränsat flöde mellan två system kan vara i drift på några veckor. Ett större projekt som omfattar hela orderflödet genom flera system tar vanligtvis några månader. Den största tidsfaktorn är sällan utvecklingen i sig utan kartläggningen, datakvaliteten i källsystemen och tillgången till rätt personer i verksamheten.
Kan alla system integreras?
I de flesta fall ja. Så länge ett system kan nås via ett API eller en standardiserad filöverföring går det i regel att ansluta. Äldre system utan API kräver mer kreativa lösningar, exempelvis filbaserad överföring eller databasåtkomst, vilket påverkar både kostnad och robusthet.
Vad händer med våra integrationer om vi byter affärssystem?
Det beror helt på hur de är byggda. Sitter affärslogiken inbyggd i affärssystemet måste integrationerna i regel byggas om från grunden. Ligger logiken i ett eget lager, frikopplat från systemet, behöver bara kopplingsskiktet mot det nya systemet skrivas om, medan flöden och regler lever kvar.
Behöver vi egen IT-kompetens för att integrera våra system?
Inte nödvändigtvis. Med en iPaaS-lösning ansvarar leverantören för drift, övervakning och uppdateringar, vilket gör att verksamheten kan integrera sina system utan att bygga upp egen integrationskompetens internt. Det ni behöver bidra med är kunskap om era egna processer och flöden.
Hur påverkas GDPR när vi integrerar våra system?
En integration flyttar ofta personuppgifter, vilket gör att de finns på fler ställen än tidigare. Det ställer krav på att bara nödvändiga fält överförs, att ett personuppgiftsbiträdesavtal finns med leverantören, att ni vet var uppgifterna behandlas geografiskt och att loggar och felköer omfattas av era gallringsrutiner. Rätt uppbyggd kan integrationen samtidigt göra det enklare att hantera raderingsbegäranden, eftersom systemlandskapet blir kartlagt.
Sammanfattning
Systemintegration innebär att koppla ihop IT-system så att information flödar automatiskt i stället för att flyttas manuellt. Det sker på tre nivåer, från ren datasynkronisering till hela affärsprocesser som löper genom flera system.
Metoderna skiljer sig kraftigt åt. Manuell filöverföring och punkt-till-punkt-lösningar är enklast att komma igång med men dyrast att leva med, eftersom underhållet växer för varje ny koppling. API-integration och EDI löser specifika behov väl. En integrationsplattform kräver mer eftertanke i början men flyttar kostnaden från löpande underhåll till en förutsägbar struktur, med leverantören som ansvarig för drift och förvaltning.
Den viktigaste frågan att ställa tidigt handlar inte om teknik utan om förändring: vad händer med era flöden den dag ett system byts ut, en volym tiodubblas eller en ny kanal ska in? Svaret på den frågan avgör om ni bygger en engångslösning eller något som håller över flera systemgenerationer.
Ett bra första steg är att kartlägga systemlandskapet och identifiera var tid faktiskt försvinner idag. Vill ni se hur era flöden skulle kunna se ut i en integrationsplattform är ni välkomna att boka en kostnadsfri och förutsättningslös demo, så går vi igenom förutsättningarna tillsammans.