Systemintegration som kopplar ihop ERP, PIM och webben

Ni kan ha en order som syns i webben, ett lagersaldo i affärssystemet och en produkttext i PIM, men ändå sakna en fungerande helhet. När någon ändrar prisregeln eller uppgraderar ett system blir det tydligt vem som faktiskt ansvarar för att uppgifterna fortfarande stämmer.

Systemintegration är därför ett löpande åtagande om hur data ska röra sig, vad uppgifterna betyder och vem som agerar när något förändras. Tekniken transporterar informationen. Verksamheten behöver äga reglerna och arbetet efter go-live.

Fyra mönster för systemintegration och när de passar

Tänk på en integration som en postrutt mellan system. En enskild order är ett brev, men själva rutten behöver fungera även när mottagaren är upptagen, adressen ändras eller leveransen misslyckas.

SCB beskriver affärssystem som system som delar information mellan interna funktioner, exempelvis order, lager, inköp och projektstyrning. Det gör affärssystemet till en gemensam informationsbas som behöver utbyta uppgifter med andra system och kanaler. SCB:s definition av affärssystem ger en användbar utgångspunkt när ni avgör vilka uppgifter som ska lämna systemet och när.

Punkt-till-punkt är lätt att förstå när två system ska utbyta en begränsad mängd uppgifter. Kopplingen blir mer besvärlig när ytterligare system ska ha samma information. Varje ny förbindelse kan skapa ännu en plats där fält, regler och felhantering måste hållas i takt. Den största risken är att varje ny koppling binder fler system till varandra.

Batchöverföring passar när uppgifterna inte måste vara aktuella varje sekund. En nattlig produktfil kan fungera för ett sortiment som sällan ändras, men ett pris som ändras efter överföringen kan visas fel fram till nästa körning. Synkrona API-anrop ger snabbt svar när kunden väntar på exempelvis behörighet eller pris, men kundens flöde blir beroende av att mottagande system svarar.

Med händelser och kö kan avsändaren lämna över ett meddelande utan att alla mottagare måste vara redo samtidigt. Det passar när flera system ska reagera på en order eller lagerändring. Ni behöver samtidigt kunna upptäcka växande köer och hantera en händelse som levereras mer än en gång. För en jämförelse med en mer modulär uppbyggnad kan ni läsa om komponerbar handel. Den största risken där är dubbla leveranser eller köer som växer obemärkt.

Välj mönster utifrån vem som väntar på svaret i varje flöde och vad som händer om svaret uteblir.

Vem äger datat mellan affärssystem, PIM och webb

Varje dataobjekt behöver en bestämd master. Ett artikelnummer i tre system skapar inte automatiskt tre likvärdiga källor. Det skapar tre möjliga svar när någon frågar vilket värde som gäller.

En vanlig uppdelning är att affärssystemet äger artikelnummer, grunddata, prisregler, lager och kundregler. PIM förvaltar den berikade produktinformationen, som texter, attribut, bilder och dokument. Webbplatsen visar uppgifterna och skickar tillbaka order och kunddata enligt överenskomna regler.

Lagersaldot ägs ofta av lagersystemet via affärssystemet och ändras av lagerprocessen. Kundbehörighet och kundspecifika prislistor ligger i affärssystemet eller CRM och visas i kundportal och återförsäljarportal. Orderstatus ägs av affärssystemet och förs tillbaka till kundportal och kundservice via integrationen.

Fördelningen ovan är vanlig men behöver anpassas till er. Om ert lagersystem äger saldot ska det stå i er modell. Bestäm också vem som får ändra varje objekt och vem som godkänner ändringar i dess betydelse.

En semantisk skillnad kan ge ett fel som ingen teknisk kontroll fångar. Anta att ett system räknar styck och ett annat förpackningar. Om en beställning på en pall tolkas som ett antal styck kan både lagersaldo och pris bli fel, trots att API-anropet lyckas.

Digg beskriver teknisk interoperabilitet som en del av helheten och pekar också på betydelsen av juridisk, semantisk och organisatorisk interoperabilitet. Ett fungerande API garanterar alltså inte att systemen tolkar artikelstatus, enhet, pris eller kundbehörighet likadant. Därför behöver ni testa både gränssnittet, affärsbetydelsen och kompletta processer före produktionssättning, enligt Diggs uppföljning av digitalisering och interoperabilitet.

Fyll i ägarskapet tillsammans med ansvariga för affärssystem, PIM och webb, och dokumentera vem som beslutar när ägarskapet ändras. För praktisk vägledning om informationsmodellering finns även genomgången av hur PIM-data struktureras.

Så går en order från webben till affärssystemet och tillbaka

En orderprocess fungerar först när hela resan är definierad. Följande flöde visar vad som behöver hända från kundens klick till en uppdaterad orderstatus.

Kunden lägger ordern i webbutiken. Webben behöver spara ordern så att den inte försvinner om nästa steg tar tid. Därefter kontrollerar webben behörighet, pris och lager mot de senast synkroniserade uppgifterna. Om lagret uppdateras mer sällan än priserna kan kunden se ett saldo som hunnit ändras.

Webben skickar ordern med ett stabilt affärs-ID, en tidsstämpel och ett korrelations-ID. Dessa uppgifter gör det lättare att följa samma order genom loggar och system. Affärssystemet använder affärs-ID:t för att upptäcka om ordern redan tagits emot. Det förhindrar att ett nytt försök skapar en dubblerad order.

Affärssystemet returnerar sitt ordernummer. Webben kan då visa en bekräftelse som går att hänvisa till vid frågor. Lagerreservation och orderstatus går tillbaka till webben. Kunden och kundservice får då samma aktuella besked.

Om överföringen misslyckas väntar meddelandet i en kö och skickas om med längre pauser mellan försöken. Om felet kvarstår flyttas det till en särskild felkö som någon ansvarar för att granska. Dubbletter uppstår ofta när affärssystemet tar emot ordern, men svaret försvinner på vägen tillbaka. Webben kan då tolka väntan som ett misslyckande och kunden kan försöka igen. Ett stabilt order-ID och en mottagare som känner igen upprepade meddelanden gör skillnad.

EDI-order följer en annan väg än ett köp i en webbutik. SCB definierar e-handel så att den omfattar beställningar via webbplats, app eller särskilt utformade EDI-meddelanden, enligt SCB:s statistik om företagens IT-användning. Webbordern behöver hantera presentation och kundinloggning. EDI-flödet måste kunna tolka strukturerade format, identifierare, bekräftelser och felkoder.

API-strategi som tål versionsbyten

Ett REST-API ger ett tydligt sätt att fråga efter och uppdatera resurser som artiklar, order och kunder. Diggs REST API-profil och vägledning för standardiserade API:er ger en svensk referens för enhetlig utformning och validering. Det avgörande är ändå vilka regler ni dokumenterar och följer.

Börja med autentisering. Ge varje anslutet system ett eget tjänstekonto med den behörighet som flödet behöver. Om flera system delar samma konto blir det svårare att begränsa åtkomst och spåra vilket system som utförde en ändring.

Bestäm sedan versionsregeln. Bakåtkompatibla tillägg kan ofta rymmas i samma version, medan ändringar som bryter befintliga anrop behöver en tydlig migreringsväg. Versionsmodellen och identifierarstrukturen blir kostsamma att ändra när många flöden redan förlitar sig på dem.

Fel behöver ett gemensamt format med felkod och korrelations-ID. När en order skapas ska mottagaren kunna hantera en idempotensnyckel eller motsvarande stabilt ID, så att ett omsänt anrop inte skapar en ny order. Stora kataloger bör hämtas sidindelat. Förfrågningar som hämtar lager för varje artikel en och en kan belasta systemen i onödan. Samla i stället uppgifterna i ett lämpligt anrop.

Varje meddelande bör gå att följa från webb till affärssystem och tillbaka. Logga latens, fel och köernas storlek, och se till att någon får larm när meddelanden behöver hanteras manuellt. Det gör det möjligt att skilja transportfel från fel i mappning eller affärslogik.

Datakontrakt och ansvar när systemen förändras

Stabiliteten i en integration avgörs av datakontraktet: vilka fält som finns, deras datatyper, enheter, betydelse, tillåtna värden och versionsregler. Minst lika viktigt är ägarskapet. När affärssystemet eller plattformen ändras ska det stå klart vem som godkänner ändringen, vem som anpassar mappningen och vem som svarar om flödet bryts.

Om ett fält tas bort i affärssystemet returnerar mappningen ett tomt värde, och om ett nytt fält blir obligatoriskt avvisas ordern. Kontraktet behöver därför ange vilka fält som är obligatoriska, vem som godkänner ett borttag och vilket standardvärde och vilken övergångsperiod som gäller.

En ändrad enhet, till exempel från styck till kartong, kan ge fel lager och pris utan felmeddelande, och en ändrad prislogik kan visa gamla priser i webben. Kontraktet behöver ange omräkningsregler, en ägare för prisreglerna och godkända testfall. För nya releaser och avvecklade API-versioner behöver det ange versionsbesked, testmiljö, återställningsplan, avvecklingsdatum och migreringsväg.

Även externa datakällor ändrar sina gränssnitt. SCB beskriver att variabler i företagsregistrets API kan läggas till eller tas bort, och att ett kommande API ska ersätta det nuvarande. SCB:s dokumentation om företagsregister-API:t understryker grundregeln: planera för förändring redan när kopplingen byggs.

En tyst kvalitetsförsämring syns sällan som ett tekniskt fel. Följ antalet avvisade ordrar, jämför stickprov mot affärssystemet och notera om de manuella korrigeringarna ökar. Vid en ändrad prisstruktur ska en namngiven ägare godkänna regler och testfall. Kontraktet bör också ange hur länge en äldre version stöds.

Ansvaret behöver vara avtalat och fortsätta i den löpande förvaltningen efter projektfasen. Glanser Care omfattar versionsuppföljning, kompatibilitet genom uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning till fast månadskostnad. Oavsett leverantör är modellen densamma: en ägare per dataobjekt och en part som svarar när det andra systemet ändras. Ett kontrakt utan ägare är bara dokumentation.

Vad en pålitlig koppling kräver av er

En order på en pall passerar genom en koppling som väntar sig styck, och affärssystemet reserverar 40 enheter.

Först schema och API: fältnamn, datatyper, obligatoriska värden, felkoder och autentisering. Där syns fel i själva överföringen. Nästa nivå är affärssemantik: enheter, prisregler, artikelstatus och kundbehörighet. Kontrollera både värdet som skickas och hur mottagaren ska tolka det. Sista nivån är hela processen. Skicka en order från webb till affärssystem, reservera lager, genomför en retur och skicka samma meddelande igen efter en simulerad timeout. Då ser ni om reglerna fungerar tillsammans, inklusive att en återsändning inte skapar en dubbelorder.

Testerna ställer krav på er sida. Ni behöver en testmiljö med representativa affärssystemdata, avsatt tid för test före varje release och en namngiven ägare för varje dataobjekt. Ägaren är den som svarar när det andra systemet ändras. När testerna ingår i varje release blir en uppgradering en verifiering av det som redan finns.

Ibland är en avancerad koppling för tung. Vid låg ordervolym, en katalog som sällan ändras eller en engångsimport kan en kontrollerad filimport med avstämningsrapport räcka. Den lösningen kräver fortfarande någon som granskar avvikelserna, men den kan vara rimligare än att drifta en realtidslösning. Genomgången av integrationen mot Business Central visar hur en koppling kan ingå i ett större flöde när volymen växer.

Tre frågor att ställa till leverantören

Vem beslutar att ett fält får tas bort, och hur länge stöds den gamla API-versionen? Ett tydligt svar anger både ansvarig roll och hur förändringen kommuniceras.

Vad händer med en order som hamnar i felkön, vem får larmet och inom vilken tid ska den hanteras? Svaret visar om leverantören har en faktisk rutin för fel eller bara en teknisk möjlighet att lägga meddelandet åt sidan.

Vilka testfall kör ni mot den affärssystemversion vi använder innan en uppgradering går live? En skriftlig testlista visar om leverantören provar verkliga flöden som order, lager och retur.

Jämför svaren från två leverantörer med samma frågor och be att få dem skriftligt. Ett datum, en namngiven roll och tydliga testfall visar hur ansvar fördelas. Formuleringen att fel hanteras vid behov lämnar däremot utrymme för att kostnaden hamnar hos er när en förändring redan har stört verksamheten.

Välj mönster efter vem som äger datat

Avgör per dataobjekt om synkroniseringen ska ske i batch eller via API. Data som ändras sällan och kan vänta till nästa körning, till exempel produkttexter, attribut och dokument, klarar sig bra i schemalagda batcher. Data som styr ett beslut i realtid, som pris och lagersaldo vid orderläggning, behöver ett direkt anrop så att webben alltid frågar den aktuella källan. Samma objekt kan dessutom bära bägge: artikelstammen kan replikeras i batch medan prissättningen hämtas först när kunden faktiskt handlar. Välj mönstret utifrån vad det kostar verksamheten om informationen är en timme gammal.

Samla ansvariga för affärssystem, PIM och webb i en enda arbetsgrupp, identifiera vilka dataobjekt som saknar ägare och dokumentera vilket mönster som gäller för varje flöde.

Glanser

Vi levererar webb, produktwebb, PIM och portaler med färdigutvecklade och testade integrationer till fast omfattning och fast pris, och tar långsiktigt produktansvar efter go-live. På sidan om integrationer mot affärssystemet ser ni hur vi kopplar affärssystem, PIM och webb och vem som ansvarar när systemen ändras.