Därför behöver ni förstå iPaaS innan ni bygger

Ni lägger upp en artikel i affärssystemet och fyller sedan i samma uppgifter i e-handeln. Produktteamet kompletterar en separat databas. När lagersaldot blir fel börjar någon leta efter filen som skulle ha skickats under natten.

En leverantör föreslår iPaaS för att samla kopplingarna. Det kan vara ett bra vägval. Men innan ni väljer behöver ni veta vem som sköter flödena när affärssystemet uppdateras och ett fält byter betydelse.

iPaaS samlar kopplingarna mellan era system

Anta att ekonomin ligger i affärssystemet, försäljningen i e-handeln och produktinformationen i en separat databas. Samma artikelnummer registreras på flera ställen. När någon ändrar en uppgift behöver kollegorna veta vilka kopior som också ska uppdateras.

iPaaS är en molnbaserad integrationsplattform som kopplar samman system. Den kan innehålla färdiga anslutningar, översättning mellan dataformat och regler för hur information skickas vidare. Där finns också verktyg för att följa körningar och upptäcka fel.

Tänk på elnätet. Ett hus ansluts till ett gemensamt nät och behöver ingen egen kabel till varje grannhus. På liknande sätt kan systemen anslutas genom ett gemensamt integrationslager, även om varje flöde fortfarande behöver utformas och testas.

SCB att fyra av tio svenska företag köpte molntjänster

Enligt SCB:s statistikdatabas köpte 72 procent av svenska företag med minst tio anställda molntjänster 2025. När företag använder fler fristående tjänster behöver information passera fler systemgränser. Separata direktkopplingar kan då bli svåra att överblicka, särskilt när dokumentationen finns hos en enda person.

Plattformen tar hand om gemensamma tekniska uppgifter. Er organisation behöver fortfarande bestämma vilka uppgifter som gäller, vart de ska skickas och vad mottagaren får göra med dem. En färdig anslutning känner sällan till alla era kundvillkor och artikelregler.

Börja därför med att räkna systemen som behöver utbyta information. Markera sedan flödena som bara en person kan förklara eller starta om. Den bilden visar om ni behöver samla många beroenden eller lösa en avgränsad koppling.

iPaaS passar när flödena ska styras samlat

Valet av integrationslösning avgör också vem som ansvarar när ett system ändras. En punkt-till-punkt-koppling kan passa ett stabilt, avgränsat flöde med tydlig förvaltning. Varje ny direktkoppling behöver dock hantering av fel, behörigheter och ändringar.

En lokal integrationsmotor samlar flöden i er egen driftmiljö. Den kan passa interna system med särskilda nätverkskrav, men då behöver ni själva ordna drift, licenser, säkerhetsuppdateringar och rätt kompetens.

Affärssystemets API eller filgränssnitt kan räcka när systemet är navet och få mottagare behöver anslutas. Ett API är ett gränssnitt där program hämtar eller lämnar information. Mappningen kan ligga i anslutande kod eller i affärssystemet, och behöver testas när någon del uppdateras. En tekniskt enkel koppling behöver ändå någon som kan ändra, testa och återställa den.

iPaaS blir relevant när flera tjänster och flöden ska styras samlat. Plattformen ger ett gemensamt arbetssätt för anslutningar, körningar och övervakning. När affärssystemet eller webben uppdateras måste någon bedöma om förändringen påverkar flödena, kontrollera mappningen och se till att den fortsätter stämma.

Det praktiska glappet uppstår ofta när den som byggde en koppling inte längre förvaltar den. En undantagsregel för kundpriser kan finnas i koden utan att verksamheten vet varför den behövs. Innan flödet flyttas till iPaaS behöver någon beskriva regeln och godkänna om den ska finnas kvar.

Räkna därför systemen, flödena och beroendena före plattformsvalet. Utse också den som godkänner verksamhetsreglerna. Personen behöver förstå följden av ett felaktigt pris eller en utebliven order, även om någon annan skriver integrationskoden.

Så är ett iPaaS-lager uppbyggt mellan ERP och webb

Närmast systemen finns anslutningarna. De hanterar exempelvis autentisering, tillåtna anrop och hämtning av ändrade poster. En anslutning till affärssystemet kan läsa artiklar, medan en annan lämnar berikat innehåll till webben.

Därefter kommer transformering och mappning, alltså översättningen mellan systemens datamodeller. Ett artikelnummer kan ha olika fältnamn hos avsändaren och mottagaren. Även enheter, prisformat och tomma värden behöver få en bestämd betydelse.

Orkestreringen styr ordning och beroenden. En kund behöver kanske finnas innan ordern kan registreras. Reglerna ska då beskriva när flödet får fortsätta och vilken information nästa steg behöver.

En API-gateway kan samla åtkomstregler och begränsa anrop. Övervakningen visar status och historik. Med ett gemensamt korrelations-ID kan förvaltaren följa samma order genom systemen och se vilken information varje steg tog emot.

eSams vägledning om molntjänster rekommenderar en DMZ eller annan säkerhetszon mellan publika molntjänster och interna system. Trafiken passerar internet och behöver bedömas utifrån det. Flöden för produktdata, priser, lager och order bör därför avskiljas från webbplattformens publika yta.

Varje anslutning bör ha egen klientidentitet och minsta möjliga behörighet. Hemligheter ska kunna bytas, inkommande data valideras och transporten krypteras med TLS. Ett kapat webbkonto ska därmed få så begränsad räckvidd som möjligt in i affärssystemet.

Flödena har olika takt och olika källa till sanning

Produktinnehåll som texter, bilder, attribut och dokument kan ha PIM som huvudkälla. Publiceringen kan ofta ske schemalagt eller efter ett godkännande. Då får produktteamet kontroll över vilket innehåll som faktiskt når kanalerna.

Artikelnummer, grunddata och prislogik kan ägas av affärssystemet. Uppdateringstakten behöver följa hur verksamheten ändrar sortiment och priser. Ett nytt artikelnummer måste finnas hos mottagaren innan någon försöker sälja artikeln.

Lagersaldo och leveransstatus hämtas vanligtvis från systemet som hanterar lager och leverans. Behovet av snabba uppdateringar beror på vad ni lovar kunden. Om webben visar tillgänglighet behöver ni bestämma hur gammal uppgiften får vara och hur ett avbrott ska visas. Ange för varje flöde huvudkälla, mottagare, utlösande händelse och längsta accepterade fördröjning.

Order skapas i webben och lämnas till affärssystemet för fortsatt behandling. Webben äger kundens inskickade beställning, medan affärssystemet kan äga orderns bekräftade status. En mottagningsbekräftelse bör visa att beställningen har kommit fram, även om fortsatt behandling återstår.

Kundunika priser och villkor behöver följa den källa där avtalen förvaltas. Portalen kan behöva hämta dem vid inloggning eller köp. Om uppgifterna mellanlagras måste ni bestämma hur en avtalsändring slår igenom.

SCB:s e-handelsstatistik skiljer mellan webb och EDI, vilket också är en användbar uppdelning vid kartläggningen. Webben behöver stödja visning och kassa, medan EDI behöver överenskomna meddelandestrukturer och kvittenser. Beskriv era motsvarande flöden före leverantörsmötet och markera vilka orderregler som ska gälla oavsett kanal.

Data som passerar integrationslagret behöver en ägare

Integrationslagret kan hantera kontaktuppgifter, orderhistorik, priser och produktinformation. Om AI används kan även genererade svar eller instruktioner passera där. Dessutom kan loggar innehålla kopior av hela meddelanden.

Bestäm vilka uppgifter som får lämna varje system. Ett lagersaldoflöde behöver exempelvis sällan kundens kontaktuppgifter. Ju tydligare avgränsning ni gör, desto lättare blir det att granska både normal körning och ett felmeddelande.

Dokumentera var behandlingen sker, vilka underleverantörer som deltar och vilka personer som får åtkomst. Klargör rollerna för personuppgiftsansvarig och personuppgiftsbiträde med er dataskyddsansvariga. Den som förvaltar kopplingen kan behandla uppgifter för er räkning, beroende på uppdragets utformning.

En logg behöver hjälpa förvaltaren att hitta felet utan att samtidigt visa fler kunduppgifter än arbetet kräver. Ni behöver kunna visa var loggarna sparas, när de raderas och vem som får läsa dem. Maskera känsliga fält och skilj teknisk felsökning från verksamhetens åtkomst. Bestäm också hur supportpersonal får tillfällig behörighet och hur den avslutas.

Sambandet mellan e-handel och affärssystem behöver därför beskrivas med både dataflöden och ansvariga personer. En teknisk skiss räcker sällan för att avgöra vem som ska hantera en begäran om rättelse eller utreda ett misstänkt läckage.

Någon i ert bolag behöver äga dessa beslut från start, ofta IT-chefen tillsammans med verksamheten. Lägg in regelbunden behörighetsgranskning och loggning av lyckade och nekade anrop. Om AI ingår behöver samma ägare klargöra hur indata och resultat får sparas.

iPaaS sparar tid men flyttar ansvar till er

En gemensam plattform kan minska antalet separata direktkopplingar. Förvaltaren får en samlad plats för flöden och kan återanvända anslutningar mellan bolag eller kanaler. När en färdig anslutning passar behovet kan teamet också minska arbetet med den grundläggande kommunikationen.

Samtidigt tillkommer en licens och en leverantörsrelation. Kostnaden kan påverkas av vilka anslutningar ni använder och hur körningen debiteras. Kontrollera därför vad som händer vid fler transaktioner, nya miljöer och ytterligare kanaler.

Den dyrare risken uppstår när samma affärsregel byggs på flera ställen. Om kundrabatten beräknas i både affärssystem, integrationslager och webb måste förvaltaren förstå alla varianter. Ett prisfel blir då svårare att avgränsa.

TCO-kalkylen behöver omfatta arbetet efter go-live. Ta med övervakning, datamappning, testmiljöer och ändringar vid uppgraderingar. Lägg också in arbetet med manuella reservrutiner när en koppling står stilla.

Ni behöver utse en verksamhetsägare för varje flöde och dokumentera huvudkällorna. Bestäm var affärslogiken ska ligga och vem som får ändra den. Leverantören kan sköta det tekniska arbetet, men behöver era beslut om exempelvis prisavvikelser och ofullständiga order.

Ett stabilt flöde mellan få system kan fungera bättre med en enklare koppling. Detsamma gäller när befintliga gränssnitt redan täcker behovet. Om ingen vill äga mappningen bör ni lösa den bemanningen innan ni inför ytterligare en plattform.

En koppling är klar först när den klarar fel

Affärssystemet har registrerat ordern, men svaret försvinner på vägen tillbaka. Avsändaren vet inte om ordern finns och skickar om den. Utan skydd i mottagaren skapas en dublett, och förvaltaren får rensa manuellt i båda systemen.

Skyddet heter idempotenta operationer. Samma meddelande kan behandlas igen utan att skapa en extra order eller produkt, förutsatt att det bär ett stabilt unikt ID och att mottagaren kontrollerar om åtgärden redan är genomförd. Vid ett nytt försök känner mottagaren igen beställningen och lämnar tillbaka det befintliga resultatet.

Meddelanden som fortsätter misslyckas behöver hamna i en separat felkö. Återförsöken bör glesas ut successivt när mottagaren är otillgänglig, så att flödet inte överbelastar ett system som redan ligger nere. Förvaltaren ska kunna rätta orsaken och köra om meddelandet kontrollerat, med spårning på vad som redan lyckats. Testa avbrottet genom att bryta kommunikationen efter att mottagaren har sparat ordern, och kontrollera vad nästa försök gör.

Versionshantera mappningen och testa förväntade fält och datatyper. Ett ändrat prisfält kan annars stoppa flödet eller skicka felaktiga värden vidare i kedjan. Det här arbetet är inte ett engångsmoment. Varje ny version av affärssystemet eller webbplattformen kan flytta på fälten, så mappningen behöver testas på nytt varje gång. Sätt larm på växande köer och uteblivna körningar, så att även tystnad upptäcks.

FOI:s analys av molnincidenter beskriver bland annat risker med publikt åtkomliga resurser som saknar tillräckligt skydd. Även felsökning och återkörning behöver därför ske med kontrollerad åtkomst. Tillfälliga lösningar under ett avbrott får inte lämna meddelanden öppet åtkomliga.

Planera bemanningen före go-live och ange vilka tider någon följer larmen. När ni bedömer en integration för e-handel behöver även återställningstestet ingå. Ett lyckat test visar att förvaltaren kan hitta, rätta och återköra felet utan att skada redan behandlade order.

Leverantörens svar avslöjar mer än demon

Vem ansvarar för mappningen och ändringarna när ert affärssystem eller er webbplattform uppdateras? Be om ett namngivet ansvar i erbjudandet. Svaret behöver omfatta analys, ändring, test och godkännande innan den nya versionen tas i drift.

Ett svar som enbart hänvisar till support lämnar flera moment öppna. Supporten kanske tar emot felanmälan, medan arbetet med anpassningen måste beställas separat. Det behöver ni känna till när ni jämför kostnaden mellan olika erbjudanden.

Hur hanteras fel, köer och återförsök, och vem kan läsa loggarna en fredag kväll? Leverantören bör kunna beskriva vägen från larm till återställd körning. Kontrollera också vilket ansvar ni själva har utanför avtalad bemanning. Ett tydligt svar beskriver vem som agerar, vilket underlag personen har och hur ni får veta att flödet fungerar igen.

Vilka kopplingar är testade mot er exakta systemversion och vad kostar det att lägga till nästa kanal? En färdig anslutning kan ändå kräva arbete med era egna fält och villkor. Be därför leverantören skilja grundanslutningen från den mappning som behövs i er lösning.

Vaga svar kan betyda att omfattningen ännu inte är utredd. Det behöver inte säga något om leverantörens avsikter, men det gör er kalkyl osäkrare. Kontrollera särskilt vilka antaganden som ligger bakom priset och vad som utlöser en ny beställning.

Svaren på frågorna ska stå i det skriftliga erbjudandet före ert val. Då kan ni jämföra vad leverantörerna faktiskt tar ansvar för när något förändras.

Börja med en nulägesbild av era flöden

Rita först upp systemen som är i drift och flödena mellan dem. Markera manuella exporter, kalkylblad och moment som kräver att någon trycker på en knapp. Kartan brukar visa beroenden som ingen enskild medarbetare har hela bilden av.

För varje flöde räcker fyra uppgifter långt: vilket system som är källa, vilken information som passerar, hur ofta det sker och vad som händer när något går fel. Notera också vem som kan förklara dagens undantag, till exempel varför vissa priser sätts manuellt eller varför en order stoppas för kontroll innan den når affärssystemet.

Komplettera med konsekvenserna vid ett avbrott. Ekonomichefen behöver kunna bedöma följderna av uteblivna order, medan försäljningen behöver veta vilka priser kunderna ser. Den bilden ger bättre beslutsunderlag än en demonstration med förberedda exempel.

En integrationsstrategi med affärssystemet som utgångspunkt hjälper er att hålla ihop systemens roller. Använd nulägesbilden för att välja vilka beroenden ni vill behålla och vilka ni behöver ändra. Låt sedan leverantören förklara hur uppgraderingar ska genomföras med dessa beroenden kvar.

Hos oss omfattar arbetet integrationer mot affärssystem som Business Central och Monitor. Glanser Care är ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet genom uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning. Det är ett sådant avtalat ansvar ni bör kunna bedöma hos varje leverantör.

Ta med er kartläggning till en kostnadsfri 72-timmarsanalys. Ni avsätter två timmar och får inom 72 timmar en inventering av funktioner och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan.