Så styr ett PIM er produktdata till kanal

Ni har kanske redan ett affärssystem, en webbplats, en kundportal och flera filer med produktdata. När en teknisk egenskap ändras behöver någon kontrollera var informationen finns, vem som äger den och vilka kanaler som ska uppdateras.

Det fungerar tills sortimentet växer, marknaderna blir fler eller AI börjar producera innehåll i hög takt. Då blir produktdata en fråga om styrning, ansvar och risk.

Produktinformation som grund för digital försäljning

En kund står på en produktsida, jämför mått, material och kompatibilitet, och ska fatta beslut direkt. Om samma artikel visas med olika specifikationer i webb, portal och återförsäljarkanal uppstår friktion direkt, både i köpet och efteråt.

E-handeln i Sverige växte med 5 procent under 2024, vilket var den första positiva helårstillväxten sedan 2021, enligt PostNords E-barometer för 2024. När fler köp sker digitalt får fel i produktinformationen direkt effekt på försäljningen.

I praktiken fungerar PIM som styrskikt mellan affärssystemet och kanaler. Där säkras att rätt attribut, bilder, dokument och kanalregler följer samma masterdata, även när format, språk och urval skiljer sig mellan mottagare. Det blir ännu viktigare när AI ska användas för att skapa eller berika innehåll. AI höjer tempot, men utan kontrollerade grunddata skalar den också fel.

Transportföretagens Paketindex för fjärde kvartalet och helåret 2024

Systemarkitektur och masterdatahantering

Ett PIM-system bör fungera som ett styrande masterdatalager mellan affärssystemet, digitala kanaler och externa återförsäljare.

Affärssystemet bör fortsätta vara källa för artikelnummer, priser, lager och order. PIM ansvarar i stället för kanalberikning, till exempel titlar, säljtexter, tekniska attribut, bilder, dokument, SEO-fält och kanalregler.

När samma pris kan ändras i både affärssystemet och PIM har ni ett styrningsproblem. När teknisk dokumentation kan ändras i flera lokala filer har ni ett spårbarhetsproblem. PIM löser inget av detta automatiskt. Modellen måste ange vilken källa som vinner och hur ändringar godkänns.

En bra arkitektur skiljer på fyra saker. Artikeldata kommer från affärssystemet. Kanalinnehåll berikas i PIM. Transformationer anpassar formatet för mottagaren. Publiceringsregler avgör när produkten får gå vidare.

För organisationer med webb, produktwebb, kundportal, återförsäljarportal och reservdelsportal blir gränsen särskilt viktig. En teknisk manual kan behöva visas för en inloggad kund och en återförsäljare, medan en anonym besökare bara ser ett begränsat urval.

Integrationer ska beskrivas som ansvar och flöden. Dokumentera fält, riktning, frekvens, felhantering och återkörning i arbetet med ERP och integrationer. Då blir det möjligt att felsöka utan att börja med gissningar.

Modellering av attribut och produktstrukturer

Den mest underskattade delen av ett PIM-projekt är ofta produktmodellen. Ett system kan vara tekniskt stabilt och ändå ge dåliga resultat om produktfamiljer, varianter och attribut har modellerats fel.

En rekommenderad struktur har tre lager. Källfält från affärssystemet beskriver operativa fakta. Berikade fält i PIM innehåller innehåll och tekniska egenskaper. Distributionslagret formaterar sedan informationen för respektive kanal.

Tänk på längd som ett enkelt exempel. I den kanoniska modellen bör längd lagras som ett numeriskt värde med en standardiserad enhet. Den svenska kanalen kan sedan visa formatet på ett sätt, medan norska och danska kanaler använder sina egna presentationer.

Det är bättre än att lagra tre separata textfält. Tre manuella texter kan börja likna varandra, men de kan också få olika värden, sakna enhet eller blandas ihop vid en uppdatering.

Validering ska ske före publicering. Per kategori kan ni kräva vissa attribut, begränsa enheter och tillåta värden från definierade listor. Språkstatus måste visa om texten är klar, under arbete eller saknas. Relationer mellan huvudprodukt och varianter behöver också vara tydliga.

En produktfamilj samlar produkter som delar kommersiell eller teknisk struktur. En variant kan skilja sig genom exempelvis storlek, färg eller kapacitet. En attributgrupp samlar fält som hör ihop, till exempel mått, material eller anslutningar.

Den strukturen påverkar filtrering, jämförelse och kanalexport. Om en egenskap ligger i fritext blir den svår att filtrera på. Om samma egenskap finns med olika stavning blir resultatet inkonsekvent.

Produktmodellen ska också hantera språk, marknad och kanal. En svensk teknisk text kan behöva en norsk översättning, men samma tekniska värde ska fortfarande ha en gemensam källa. Därför bör översättningen vara ett eget arbetsflöde.

Syndikering och distribution till kanaler

När produktdata är berikad ska den distribueras på ett kontrollerat sätt. API-baserad synkronisering är en bra grund, men den behöver kompletteras med händelser eller schemalagda deltaflöden. Då skickas ändringar vidare utan att hela katalogen måste behandlas varje gång.

Idempotenta uppdateringar, alltså uppdateringar som kan köras flera gånger med samma resultat, är centrala. Samma meddelande ska kunna köras igen utan att skapa dubbla eller motstridiga poster. Fel ska hamna i en felkö med begriplig kodning, och någon behöver följa fördröjning mellan källsystemet och mottagaren.

Åtkomststyrning blir ofta avgörande i portaler. En anonym besökare kan behöva se grundläggande produktinformation. En inloggad kund kan få tillgång till dokument och kundspecifika priser. Säljare och återförsäljare kan behöva andra urval.

DHL:s Handelskollen 2024

Syndikering kräver därför mer än att skicka samma dataformat till alla mottagare. Varje export behöver ett kontrakt med schema, obligatoriska fält, versionsnummer och felkodning. Det ska framgå vad som händer när ett attribut saknas och vem som godkänner en ändring.

För produktwebbens innehåll bör ni därför definiera både gemensam information och lokala avvikelser. En produktwebb med strukturerad produktdata blir lättare att förvalta när samma modell kan leverera till flera presentationer.

AI-integration och styrsystem för produktdata

Ett vanligt läge är att affärssystemet innehåller artikelnummer, pris och lagerstatus, medan marknad vill använda AI för att skriva texter, översätta innehåll och föreslå kategorisering. Om grunddata inte hänger ihop blir PIM ett filter som måste stoppa fel innan de når kanal.

Det är därför AI i PIM måste styras som en del av masterdataförvaltningen. SCB visar att 35,0 procent av svenska företag med minst tio anställda använde någon AI-teknik under 2025, jämfört med 25,2 procent 2024. Bland företag som använde AI var marknadsföring och försäljning det vanligaste området, med 41,7 procent, enligt SCB:s statistik om it-användning i företag 2025.

I praktiken behöver ni sätta tydliga regler för vad AI får göra. Den kan föreslå formuleringar, översättningar och ibland klassning. Den ska inte avgöra fakta som hör hemma i affärssystem, teknisk dokumentation eller godkända specifikationer.

En fungerande modell börjar med källprioritet och ansvar. Artikelnummer, pris och lager hämtas från rätt system. Tekniska värden måste kunna spåras till dokumentation eller ansvarig funktion. Först därefter bör AI få arbeta inom definierade ramar, med regler för vilka attribut som får påverkas och vilka ändringar som kräver godkännande.

Ni behöver också versionshistorik som visar vad som ändrades, av vem, på vilket underlag och när det publicerades. Om en AI-genererad text visar sig vara fel ska den gå att stoppa per marknad eller kanal och återställa utan manuell brandkårsutryckning.

Mät därför kvaliteten operativt, valideringsgrad, avvisade förslag, fel per export och hur ofta redaktörer korrigerar AI:s utkast. Då blir PIM ett styrsystem mellan affärssystem och kanaler, och AI ett kontrollerat lager ovanpå en hållbar datamodell.

Affärsvärde för tillverkande företag och varumärken

Ni märker värdet när samma produkt ska fungera i flera verkligheter samtidigt, säljarens kundportal, den egna webbplatsen och återförsäljarens flöde. Då räcker det inte att informationen finns. Den måste ha en ägare, en prioriterad källa och regler för hur den får publiceras.

För tillverkande företag uppstår affärsnyttan därför i styrningen mellan affärssystem och kanaler. SCB visar att 21 procent av svenska tillverkningsföretag bedrev webbförsäljning via egen webbplats, app eller e-handelsplattform under 2024. 4 procent sålde via en gemensam e-handelsmarknadsplats eller app, enligt SCB:s tabell över webbförsäljning 2024.

PostNords sammanfattning av E-barometern för 2024

Den egna kanalen och externa kanaler kräver ofta olika fält, format och ansvar. Utan en gemensam modell börjar team kopiera data manuellt. Då glider innehållet isär mellan produktwebb, kundportal och återförsäljare, och varje lansering tar längre tid än den borde.

Ett PIM gör att den tekniska kärnan kan hållas gemensam medan kanaltext, dokumenturval och synliga attribut styrs per mottagare. Det är också grunden för AI-användning som går att lita på. Om masterdata, attributlogik och godkännanden inte håller, skalar AI bara upp fel snabbare.

Implementeringsprocess och integration med affärssystem

Ett PIM-projekt bör börja med nuläget. Kartlägg var artikelnummer, priser, lager, dokument, bilder och texter finns. Markera vilka uppgifter som är dubblerade och vilka flöden som saknar ägare.

Nästa steg är att definiera produktmodellen. Utgå från produktfamiljer, varianter, attributgrupper, språk och kanaler. Bestäm samtidigt vilka fält som ska vara obligatoriska före publicering.

Affärssystem som Business Central, Monitor och Jeeves kan leverera olika strukturer. Därför behöver integrationen hantera identifierare, ändringar, fel, återkörning och versionshantering. Ett importflöde måste också fungera när data förändras, när fel uppstår och när flöden behöver köras om.

Bygg testfall för en komplett produkt, en variantfamilj och medvetet felaktig data. Kontrollera saknade attribut, ogiltiga enheter, fel språkstatus och brutna relationer. Testa sedan hur felet visas för den person som ska rätta det.

Följ mätvärden som valideringsgrad, API-fel, synkroniseringslatens och korrekt rendering i prioriterade kanaler. Det gör go-live till ett beslut baserat på observerbara resultat.

Glanser arbetar med ett Funktionsbibliotek av färdigutvecklade, testade och kompatibla funktioner och integrationer. De kan levereras som Standard, Anpassad eller Kundunik, där den kundunika delen isoleras från övriga funktioner vid uppgraderingar. Läs whitepaperet om PIM i praktiken när ni vill fördjupa arbetet med modell, ansvar och flöden.

Förvaltningen ska planeras från början. Produktansvar omfattar ändringar i attribut, nya kanaler, release notes, integrationer och korrigeringar efter go-live. Glanser Care är ett avtalat ansvar till fast månadskostnad över tid för versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning utan ny offert vid uppgradering.

Frågor som visar hur leverantören arbetar

Be leverantören beskriva exakt vilken källa som äger pris, lager, artikelnummer och tekniska attribut. Svaret visar om de arbetar med tydlig masterdatastyrning eller lämnar ansvaret otydligt mellan flera system.

Be om ett konkret exempel på hur ett felaktigt attribut stoppas före publicering. Svaret visar om de har praktiska kontroller för kvalitet eller främst förlitar sig på manuella rutiner.

Fråga vem som ansvarar för kompatibilitet efter uppgradering. Svaret visar hur långt leverantörens ansvar sträcker sig när lösningen ska fungera över tid.

Bedömning av genomförbarhet och nästa steg

Ett PIM-system passar bäst när produktportföljen har komplexa relationer, informationen ändras ofta eller samma data ska publiceras i flera kanaler. Behovet blir tydligare när produktteam, marknad, försäljning och IT delar på ansvaret.

Ett enklare upplägg kan räcka om sortimentet är litet, kanalerna är få och informationen ändras sällan. Att införa PIM utan tydligt ägarskap skapar däremot ett nytt lager att underhålla. Vänta hellre tills ni har definierat vilka problem systemet ska lösa.

En bra start är en avgränsad analys av nuläge, integrationer och produktmodell. Då kan ni avgöra om PIM ska införas nu, börja med en kanal eller vänta tills datans ägarskap är tydligare.

Med Glansers 72-timmarsanalys avsätter ni två timmar för ett möte och får inom 72 timmar en inventering av funktionalitet och integrationer, en funktionsspecifikation, en prototyp och en komplett kostnadsbild med tidsplan. Underlaget är kostnadsfritt och blir ert, oavsett vad ni bestämmer er för.