Så väljer tillverkande företag affärssystem efter dataflödet

En ny variant av en pump får ett nytt artikelnummer i affärssystemet. Inköp och lager ser den nya artikeln, men gamla bilder och reservdelslistor ligger kvar i kundportalen en vecka. Kunderna ser en produktversion som verksamheten redan har ändrat.

Det här brukar inte bero på att företaget saknar system. Samma artikel kan finnas i affärssystemet, produktblad, webbshoppen och en återförsäljares kopia. När varje register uppdateras på sitt eget sätt blir det svårt att veta vilken information som gäller.

Därför bör ni bedöma affärssystem för tillverkande företag utifrån hur artikel-, pris-, lager- och orderdata når webb, kundportal och återförsäljare. Ni behöver se hur flödet fungerar genom hela kedjan.

Affärssystemet är navet för produkt, lager och order

I ett tillverkande bolag skapas affärskritisk information på flera håll. Affärssystemet hanterar vanligtvis transaktioner som order, lager och priser. Ett PIM-system samlar produktbeskrivningar, bilder, dokument och kanaltexter för publicering. Kundportalen visar informationen vidare till kunderna.

När samma fält finns i flera register måste någon hålla dem lika. Om artikelnumret ändras i affärssystemet, men produktbladet och portalen inte följer med, kan kunden beställa med fel information. Om lagersaldot uppdateras för sent kan portalen visa en vara som inte går att leverera. Manuella avstämningar vid månadsskiftet blir då ett sätt att hitta skillnader som borde ha fångats tidigare.

SCB beskriver affärssystem som programvara som delar information mellan funktioner som redovisning, planering, produktion, marknadsföring och inköp. För tillverkningen innebär det att systemets nytta beror på hur väl samma artikel-, kund-, order- och lagerdata följer med genom verksamheten.

En bra utgångspunkt är en tumregel: varje datafält bör ha en tydlig ägare. Affärssystemet kan äga artikelnummer, pris och saldo, medan PIM äger beskrivningar och bilder. Den exakta ansvarsfördelningen behöver ni bekräfta utifrån era processer och system.

När ni jämför lösningar behöver ni därför reda ut vilka dataobjekt som styrs var, hur ändringar förs vidare och vem som hanterar ett avbrott. Den kartläggningen visar om systemet som redan finns faktiskt kan leverera rätt information till rätt kanal.

Sex krav som avgör om systemet passar tillverkningen

Ta med konkreta scenarier till demon. Be leverantören följa en riktig order och visa hur informationen rör sig.

Stycklistor och varianter: Fråga om varianter och revisioner hanteras i samma artikel. Ett vanligt hål är att varianter lagras som kopior av artikeln.

Lagersaldo: Fråga om saldot uppdateras i portalen i realtid. Ett vanligt hål är att det uppdateras först vid en nattlig körning.

Produktattribut: Fråga var attribut ändras och av vem. Ett vanligt hål är att samma fält redigeras i två system.

Integrationsyta: Fråga om det finns dokumenterade gränssnitt och vilka versioner som stöds. Ett vanligt hål är att kopplingen bygger på en version som inte längre underhålls.

Kundunika priser: Fråga om kundspecifika priser och villkor styrs i systemet. Ett vanligt hål är att priserna ligger i ett separat kalkylblad.

Uppgraderingar: Fråga hur kompatibiliteten testas före en ny version. Ett vanligt hål är att testerna körs först i produktion.

Stycklistor och varianter kräver tydlig revisionshantering. Om en ny variant blir en kopia av en befintlig artikel får ni två poster att underhålla. I demon bör leverantören visa vad som händer när en komponent eller produktversion ändras.

Lagersaldot behöver också prövas mot er faktiska användning. En nattlig uppdatering kan fungera för en kanal med få order, men skapa problem när kunder förväntar sig aktuell tillgänglighet. Samma princip gäller produktattribut. Om en vikt eller förpackningsenhet ändras på två ställen riskerar ni att publicera motstridiga uppgifter.

Tillväxtverket visar en skillnad mellan att digitalisera administration och att använda digitalisering strategiskt: nio av tio svenska företag använder IT eller digitalisering i administrationen, medan 16 procent uppger att de använder digitalisering i stor utsträckning för affärsutveckling (Tillväxtverkets resultat om företagens digitalisering). Ett affärssystem kan alltså vara etablerat utan att produkt- och orderdata når rätt kanal.

Bedöm därför integrationsgränssnitt, kundspecifika villkor och uppgraderingar med samma omsorg som produktionsfunktionerna. En svag signal är ett svar som stannar vid att kopplingen finns, utan att visa hur fel upptäcks och hanteras.

Avsluta demon med ett sammanhängande scenario: en kund lägger en order i portalen, ordern går vidare till lager och affärssystem, och kunden får tillbaka en begriplig status. Då ser ni om hela flödet fungerar.

Kartlägg vem som äger varje dataobjekt före valet

En Excel-fil med sortiment och priser som skickas till återförsäljaren varje måndag är ett vanligt fynd i den här kartläggningen. Filen fungerar tills en prisändring kommer på tisdagen, och då säljer återförsäljaren en vecka på gamla villkor. Den typen av manuellt steg är det ni letar efter. Det avslöjar vilka dataflöden som faktiskt når era kanaler och vilka som stannar i en persons inkorg.

Där sitter också det egentliga urvalet. Bedöm systemet efter vilka flöden det faktiskt matar ut till webb, portal och återförsäljare.

Följande ansvarsfördelning är en utgångspunkt att bekräfta i ert bolag, inte en universell regel. Affärssystemet äger normalt artikelnummer, enheter och stycklistor som förs vidare till PIM och webb vid ändring i affärssystemet. Det äger också lagersaldot som går till webb och portal maskinellt, händelsestyrt eller enligt schema, samt priser och kundspecifika villkor som går till webb och portal vid prisändring. Ordrar och orderstatus hör till affärssystemet och flödar i båda riktningarna vid händelser.

PIM äger normalt produktbeskrivningar, bilder och dokument som går till webb, portal och återförsäljare vid publicering. Kanalanpassade texter och attribut går från PIM till kanalerna vid publicering. Vem som äger reservdelsrelationer, vart de ska skickas och när de ska uppdateras bestäms i ert projekt, utifrån hur produktinformation och eftermarknad sköts.

Gå igenom kedjan från artikel och stycklista till offert, order, lager, leverans och reservdelar. För varje objekt dokumenterar ni vilket system som är källa i dag och vilka andra system eller filer som kopierar uppgifterna. Markera varje steg där en människa flyttar data för hand, som veckofilen till återförsäljaren, och notera hur ofta steget sker.

Bestäm vilken fördröjning verksamheten kan acceptera. En senare uppdatering av en produktbild kan vara hanterbar, medan ett gammalt lagersaldo kan leda till en order som inte kan levereras. Rita därefter flödet från datakälla till kanal och notera vilka fält som måste vara identiska i båda ändar.

Ta med kartan till leverantörens genomgång och be att få se samma flöde i demon. En genomgång av affärssystem och e-handel kan också hjälpa er att identifiera var ansvar och informationsflöden möts.

Kartan visar var integrationen sitter, och där hamnar ofta både kostnad och risk. Om reservdelsordern är korrekt men portalen visar gammalt saldo har ni ett tydligt felställe att undersöka. Arbetet tar tid och kräver att produktion, inköp och e-handel deltar i samma möte.

Integrationer som håller data lika i alla kanaler

Ett affärssystem i en tillverkande miljö bedöms efter vilka dataflöden som når webben, portalen och återförsäljarleden. En direkt koppling mellan varje system kan vara enkel att börja med. När fler kanaler tillkommer blir varje ny koppling ännu ett flöde att testa och underhålla. Ett integrationslager med definierade flöden för produktmaster, priser, tillgänglighet, order och kundspecifika villkor gör ansvaret tydligare.

Det viktigaste märks när något går fel. Idempotens gör att ett återförsök inte skapar en dubblerad order. Versionshantering visar vilken struktur ett meddelande följer. Loggning ger en spårbar bild av vad som skickades, medan återkörning låter er behandla ett misslyckat flöde på nytt.

Tänk på ett saldo som inte hinner uppdateras efter en order. Portalen visar då en vara som redan är reserverad, och nästa kund kan lägga en order som verksamheten behöver hantera manuellt. Utan loggar blir felsökningen långsam. Utan ett säkert återförsök kan korrigeringen skapa en ny avvikelse.

Mät driftens hälsa från start med datakvalitet per obligatoriskt fält, integrationsfel per tusen meddelanden, synkroniseringslatens och andelen order som behandlas utan manuell korrigering. Det här är förslag på mått, inte uppmätta branschvärden. De hjälper er se om integrationen fungerar i vardagen, inte bara om den tekniskt har driftsatts.

En färdig standardkoppling mot ert affärssystem kan passa när standardflödena täcker era processer och ansvarsfördelningen är tydlig. Den kan behöva byggas ut om ni har ovanliga orderflöden, specialvillkor eller produktrelationer som inte ryms i standardmodellen. Be leverantören räkna upp exakt vilka fält som når återförsäljaren, och med vilken fördröjning. En genomgång av ERP-integration visar hur ett sådant lager kan struktureras i praktiken.

Vad förvaltningen efter go-live kräver av er

Ta ett exempel. En plattformsrelease ändrar hur ett prisfält exponeras i gränssnittet mot webben. Orderflödet mot affärssystemet fortsätter fungera, men återförsäljarnas priser i portalen slutar uppdateras. Releasen gick igenom eftersom ingen hade i uppgift att godkänna den mot era dataflöden, och felet upptäcktes först när en kund ringde och undrade varför priset på skärmen inte stämde.

Scenariot visar vad förvaltning faktiskt handlar om. Varje ny version kräver arbete även när ni vill behålla dagens beteende, eftersom någon måste bedöma påverkan innan den släpps vidare. Det som avgör om en version är säker är att pris, saldo och order når webb, portal och återförsäljare oförändrade.

I praktiken innebär det en namngiven produktägare hos er, avsatt tid för acceptanstest och en dokumenterad regel för vem som godkänner en ny version. En genomgång av integrationsarbetet visar vad som behöver finnas på plats för att kompatibiliteten ska hålla mellan systemversioner.

Upplägget passar sämre när scope fortfarande är oklart, när ni vill äga all kod själva eller när integrationen är så unik att ingen leverantör kan garantera kompatibilitet. Då behöver ni reda ut ansvar, dokumentation och intern kapacitet innan ni binder er till en förvaltningsmodell.

När lösningen fungerar och kan stå kvar kan Glanser ta över den som den är, sköta den löpande och göra förbättringar till fast pris när det behövs. Glanser Care omfattar versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning till fast månadskostnad, och ansvaret för att lösningen fortsätter fungera när plattformarna uppdateras ligger i avtalet. Modellen kräver ändå att ni kan beskriva vad som fungerar och vem hos er som godkänner ändringar.

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

Fråga först: hur ser flödet ut från en ändrad produkt i affärssystemet till portalen, och vem får veta om synken stannar? Svaret visar om leverantören kan beskriva en dokumenterad koppling eller bara en kedja av enskilda lösningar.

Fråga sedan: vilka versioner av affärssystemet och plattformen har testats tillsammans, och vad händer med ert scope vid nästa uppgradering? Ett konkret svar visar om förvaltningen bygger på ett avtalat ansvar eller en förhoppning om att allt fortsätter fungera.

Fråga till sist: vad kostar varje funktion innan arbetet börjar, och vad ingår inte i priset? Svaret hjälper er se var osäkerheten ligger och vem som bär den när omfattningen förändras.

Frågorna är användbara, men svarens precision säger mer. Namngivna system, tydliga flöden och konkreta versioner är bättre tecken än allmänna löften. En leverantör som vill avsluta med att granska er faktiska webb, e-handel eller portal har bättre förutsättningar att svara utifrån er verksamhet.

Ta beslutet utifrån er nuvarande lösning

Demomiljöer visar flöden som alltid fungerar. Er egen webb, e-handel eller portal visar i stället var produktdata, priser och lagersaldon faktiskt når fram till kunder och återförsäljare, och var de stannar. Den skillnaden säger mer än någon presentation.

I en 72-timmarsanalys lägger ni två timmar av er tid. Resultatet blir ett av tre besked: lösningen kan stå som den är, den är i grunden bra, eller den behöver byggas om. Varje väg leder vidare. En lösning som står kan tas över som den är och förbättras till fast pris när det behövs, och en som byggs om kan sättas ihop av beprövade delar om en stor del av behoven passar i Funktionsbiblioteket.

Starta en 72-timmarsanalys om ni vill ha beslutsunderlag utifrån er verkliga lösning i stället för en demo.