Så strukturerar ni produktdata i en PIM-datamodell

Samma artikel har tre priser ute hos er just nu. Webbshopen visar ett. Återförsäljarportalen visar ett annat. Databladet, orört i två år, visar ett tredje. Kunden frågar vilket som gäller, och svaret beror på vem som öppnar filen.

Informationen bor i tre system. Varje system har sin version av sanningen. Sälj rättar portalen. Marknad skriver om webben. Ekonomi låter affärssystemet styra priset. Felet är tillbaka nästa vecka, ofta i en fjärde fil. Ett produktregister som bara lagrar ett artikelnummer räcker inte när samma vara ska synas i flera kanaler samtidigt.

Varför ett produktregister inte räcker längre

PIM är platsen där ni hanterar och berikar produktinformationen en gång. Sedan går den vidare till webb, kundportal och återförsäljarkanal. En datamodell för PIM är ritningen för vad en produkt består av. Den säger vilka fält som finns, vilka värden som är tillåtna och hur produkter hör ihop.

Tänk ett bibliotekskort. Boken är produkten. Fälten på kortet är attributen. Utan fasta fält katalogiserar två personer samma bok på olika sätt, och hyllan blir omöjlig att söka i.

Tre frågor styr resten av arbetet. Vilka delar modellen har. Vem som äger varje del. Var en för enkel modell brister. En kort genomgång av vad PIM är i praktiken hjälper om orden fortfarande blandas ihop med affärssystemet.

Sex byggstenar i en PIM-datamodell och vem som äger dem

Modellen har sex byggstenar, och varje byggsten har en ägare som får ändra värdet. Produkt och variant knyter artikelnumret i affärssystemet till variantrelationen i PIM. Attribut, förpackningsnivåer, relationer och berikning ägs av PIM. Pris och lager ägs av affärssystemet.

Ta en installationskabel som en industrikund säljer. Grundartikeln samlar det som är gemensamt, till exempel varumärke och ledararea. Svart, blå och grå är varianter. Varje variant får en egen identitet, normalt ett GTIN, så att kartong och styck kan skiljas åt i kedjan.

GS1 Sverige beskriver GTIN som global identifierare för handelsartiklar. I svensk kontext är Validoo den lokala datapoolen, och GDSN är nätverket för synkroniserad produktdata. Modellen ska därför skilja produkt, förpackningsnivå, kanal och marknad.

En platt artikelpost lägger kartongmått, konsumentmått och pallinformation i samma fält. Ett mått som gäller pallen publiceras då som konsumentmått. Felet följer med till webbshop, portal och datablad.

Varje attribut behöver datatyp, enhet, obligatorisk nivå, giltighetsperiod och källa. Mått i millimeter läses då lika i alla kanaler. Vikt i kilogram blandas inte med gram. Ett fält utan källa går inte att försvara när en återförsäljare ifrågasätter värdet.

Relationen är nästa rad. Kabeln pekar på ett tillbehör, en kontakt, och på en reservdel som ersätter en äldre variant. Kopplingen är en strukturerad länk, med egen typ. Fritext i ett kommentarsfält går inte att filtrera på.

Berikningen ligger kvar i PIM. Datablad, monteringsanvisning och säljtext kan finnas per språk och per kanal. De ska inte skrivas tillbaka till affärssystemet, eftersom en marknadstext inte är en grundartikel.

Pris och lager stannar i affärssystemet. Kundpris, saldo och leveransstatus ändras i transaktioner. PIM läser värdena, och affärssystemet äger dem. Den vanliga gränsen är enkel. Affärssystemet, till exempel Business Central eller Monitor, äger artikelnummer, pris och lager. PIM äger berikning, klassificering och relationer. Om två system kan ändra samma fält har ni två sanningar, så välj en ägare innan fältet skapas.

Kanalerna avgör vilka fält som måste finnas

Samma kabel ska finnas på fyra ställen. Den egna webbshopen. Kundportalen. Återförsäljarportalen. Ett externt datanät. Fälten är inte desamma, och en kopia per kanal skapar just de tre priser ni redan har sett.

Webbshopen filtrerar på mått, kompatibilitet och användningsområde. De värdena måste vara strukturerade attribut. En lång säljtext går inte att filtrera på. Rubrik och sökord får vara kanalunika, men de får inte skriva över benämningen i kärnan.

Kundportalen behöver datablad, manualer och ritningar, ofta per variant. Vissa dokument ska bara vissa kundgrupper se. Synligheten är en publiceringsregel, kopplad till samma fil. En egen kopia per kundgrupp blir inaktuell så fort ritningen byts.

Återförsäljarportalen behöver namn, bilder och specifikationer per språk. Samma kabel heter ofta olika på olika marknader. Valutan hör hemma i prislogiken, tillsammans med kundavtal. Produktnamnet hör hemma i PIM.

Det externa datanätet kräver standardiserade enheter och kodlistor. Mottagaren ska kunna läsa posten utan specialregler för just ert bolag. Saknas koden, eller står vikten i fel enhet, faller posten i mottagarens kontroll.

Varje kanal pekar tillbaka på samma källa genom en publiceringsregel. Kanalen får en egen vy med egna tillåtna fält och delar produktposten med övriga kanaler.

Gör en enkel kontroll. Välj tre fält per kanal och skriv vem som äger vart och ett. Saknas ägaren är fältet inte redo att publiceras. Samma kontroll gäller när ni senare lägger till ett digitalt produktpass, där dokument och egenskaper måste gå att spåra till en källa.

Emballageenhet, minsta orderkvantitet, tillgänglighet, säkerhetsdokument och kompatibilitet väger ofta lika tungt som säljtexten. De fälten hör hemma i modellen från start om era köpare beställer i förpackningar och behöver underlag till sitt eget system.

Så modellerar ni attribut och relationer steg för steg

Börja med en produktfamilj, till exempel belysning och kablage, och arbeta igenom sju steg innan ni fyller på fler artiklar.

Först listar ni produkttyperna och avgör vilka som behöver egna attribut. En lampa och en kabel får var sin fältuppsättning. Fallgropen är en enda gemensam mall där varje tänkbart fält finns med. Då står det mesta tomt, och folk slutar fylla i det som faktiskt krävs.

Sedan definierar ni attributen per produkttyp. Varje attribut får namn, datatyp, enhet, obligatorisk nivå och källa. Skriv "vikt i kilogram", aldrig bara "vikt". Annars hamnar gram och kilogram i samma kolumn, och filtret ljuger. Källan är också ert sätt att markera ägarskapet fält för fält: artikelnummer, grunddata och prislogik kommer från affärssystemet, medan texter, specifikationer, bilder och dokument berikas i PIM.

Därefter samlar ni de gemensamma kärnattributen för alla produkter. Identitet, benämning, varumärke och måttenhet räcker långt. Om artikelnumret ägs av affärssystemet behöver det ändå finnas i kärnan. Fältet finns i modellen så att varje kanal kan visa det, men värdet flödar in via integration och ändras aldrig för hand. Det som bara gäller lampan stannar på lampans typ. Det som bara gäller kabeln stannar där.

Nästa steg är varianter och förpackningsnivåer som egna poster. Färgen är en variant med egen identitet. Kartongen med tolv styck är en förpackningsnivå med egna mått och eget antal. Lägger ni pallens höjd på styckposten publicerar ni fel mått i varje kanal.

Sedan kopplar ni relationer. Tillbehör, ersättningsprodukt och kompatibilitet är länkar med en tydlig typ. Skrivs kompatibiliteten som fritext går den inte att filtrera, och reservdelen kan inte visas vid rätt variant.

Därefter sätter ni kanalregler per fält. Varje fält vet vilka kanaler som får publicera det, och på vilket språk. En säljtext för webbshopen ska inte läcka till datanätet, och ett säkerhetsblad ska nå portalen även när säljtexten saknas.

Slutligen testar ni modellen på produktfamiljen innan fler läggs till. Lägg in tio riktiga artiklar, inklusive en variant, en kartong och en reservdel. Justera fält som ingen fyllde i. Ta bort fält som ingen kanal läser.

I testet brukar samma fel visa sig först. Vikt utan enhet, så att gram och kilogram blandas. Kompatibilitet som fritext, så att filtret inte kan användas. Ett attribut utan ägare, där värdet blir kvar från en gammal import.

En fungerande modell känns igen på ett enkelt prov: en ny produkt kan läggas in utan att någon behöver fråga vilket fält som gäller, vem som äger det eller var den får publiceras.

Kontroller som stoppar ofullständiga produkter före publicering

En produkt i en viss GPC-klass ska ha de mått, den vikt eller det material som klassen kräver. GPC är GS1:s sätt att gruppera handelsvaror, så att regler kan hänga på typen. Saknas vikten stoppas posten. Står måttet i en fri enhet stoppas den också.

Kvaliteten uppstår när modellens regler prövas före publicering. Obligatoriska attribut, kodlistor, enheter och beroenden måste kunna testas innan en artikel släpps, annars lämnar en halv artikel byggnaden.

GS1 Sverige anger att den manuella kvalitetssäkringen i Validoo testar 70 olika attribut. Det är ett riktmärke för era egna kontroller. Välj de kontroller som era kanaler faktiskt läser.

Gränsen mellan systemen bör vara synlig i kontrollerna. Artikelnummer, basdata, prislogik och transaktionsinformation kommer från affärssystemet och ska inte skrivas om i PIM. Texter, attribut, bilder och dokument berikas i PIM och kan godkännas där, men de ska aldrig tysta ett motstridigt värde i affärssystemet.

Bilder och tekniska dokument behöver språk, användningsområde och giltighetsdatum. Ett datablad utan datum går inte att lita på efter en materialändring. En bild utan språk kan hamna på fel marknad. Dokument som bara ska nå partners eller inloggade användare behöver en synlighetsregel.

Spårbarheten hör till samma lager. Varje värde bör ha datakälla, ansvarig roll, ändringshistorik, godkännandestatus och versionsnummer. När en regel ändras ser ni vilka artiklar som berörs, och vem som ska granska dem igen.

AI-stödd berikning kräver samma gräns. Skilj källvärde, AI-förslag, godkänt värde och språkversion. AI får föreslå en säljtext. Mått, vikt och artikelnummer ska komma från affärssystemet eller en standardkälla. Ett förslag blir ett giltigt värde först efter mänskligt godkännande, med roll och datum.

Samma spärr läggs på tre nivåer. Obligatoriska fält för produkttypen måste vara ifyllda, med rätt enhet. Kodlistor ska användas, så att färg och status inte stavas fritt. Dokument behöver språk, användning och giltighet, och beroende fält ska finnas med när ett styrande fält är satt. Ett fält utan godkänd status ska inte kunna publiceras, oavsett hur bråttom lanseringen är.

När en enkel modell räcker och när den spricker

En enkel modell räcker när ni har få produkter, en kanal och ett språk. Ett kalkylblad med en rad per artikel och fasta kolumner bär den lasten. Där är ett PIM-projekt en omväg, och kalkylbladet är ett hederligt verktyg.

Gränsen avgörs av hur komplext datat är. Varje grundartikel med många varianter kräver en struktur som kalkylbladet saknar. Flera språk och valutor som ska publiceras samma vecka tvingar fram parallella versioner av samma fält. När flera bolag delar sortimentet ändrar var och en "sin" kopia, och snart vet ingen vilken som gäller. Säsongstoppar avslöjar resten: sortimentet ändras snabbare än filerna hinner rättas.

Underhållet har en kostnad. Modellen behöver en ansvarig roll och ett beslut varje gång attributlistan ändras. Utan den rollen växer listan okontrollerat inom några månader. Nya fält läggs till för en kampanj och blir kvar.

Ett PIM rättar inte dåliga grunddata. Motsäger sig artikel, pris eller enhet i affärssystemet visar PIM felen snabbare, eftersom samma fel nu når varje kanal samtidigt. Då behöver affärssystemet städas först. Den ordningen beskrivs i arbetet med integration mot affärssystemet.

Styrningen kostar också löpande. Rollen, granskningen och uppgraderingarna hör hemma i förvaltningen, vid sidan av licensen. Glanser Care täcker löpande förvaltning, plattforms- och ERP-uppgraderingar samt felrättningar, så att modellen inte faller vid nästa versionsbyte.

Ett enklare arbetssätt passar bättre när en enda produktfamilj publiceras till en enda kanal, och ingen annan väntar på samma data. Börja där. Lyft in PIM när den andra kanalen, det andra språket eller det andra bolaget faktiskt finns.

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

En fältlista kan se komplett ut och ändå falla i första kanalen. Använd frågorna som prov på hur modellen beter sig i drift.

Börja med obligatoriska attribut per produkttyp: vilka fält måste vara ifyllda för att en produkt får publiceras, och vem godkänner att listan ändras efter go-live. Ett bra svar namnger typen, fälten och rollen, och visar ett värde som måste vara entydigt, till exempel måttenhet. "Vi sätter upp fälten i projektet" räcker inte om ingen äger listan i förvaltningen.

Gå vidare till varianter och förpackningsnivåer. Be leverantören skilja GTIN per variant från artikelnumret i affärssystemet och visa kartong och pall som egna poster. Låt dem sedan visa giltighetsdatum på ett dokument. Saknas datumet kan ni inte veta vilken version som är ute hos återförsäljare eller i portalen.

Lägg ägarlistan bredvid er kanallista och ställ tredje frågan från köparsidan: vilka regler kan vi själva ändra när PIM och affärssystemet är oense, utan att beställa utveckling. Testa svaret mot en verklig kanal, till exempel filtrering, variantdokument och filer som bara partner ser.

Be leverantören visa ett attribut som bytt ägare under ett år. Kan de peka på fältet, beslutet och datumet finns förvaltningen på riktigt. Svarar de med en fältlista utan ägare har de levererat en lansering. Det är något annat än en modell som tål förvaltning.

Bestäm vem som äger varje fält innan ni väljer plattform

Ett fält som ofta lämnas utan ägare är produktbladet. Datablad, manual och deklaration kan komma från leverantören, ligga i en mapp hos säljaren eller laddas upp av marknad utan att någon ansvarar för versionen. När filtret, produktsidan och kundportalen alla läser samma fält blir varje lucka i ägandet synlig direkt i kanalen.

Ordningen är kort. Lista de fält som faktiskt säljer, de som filtret, portalen och datanätet läser. Välj en produktfamilj eller en marknad som pilot. Låt modellen växa därifrån, familj för familj. Samma grund bär nästa marknad när den första håller. Ägarlistan är ert beslut, och den ska ligga fast före upphandlingen.

Vi inför PIM som en gemensam källa för produktdata. Kopplingen går via PIM-integration och, när det behövs, integration mot affärssystemet, så att artiklar, varianter, specifikationer och dokument hålls uppdaterade. Hur den kopplingen samspelar med order och pris syns i e-handel kopplad till affärssystemet.

Upplägget kräver att er organisation utser en ansvarig roll och fattar besluten om attributen. Den delen kan en leverantör inte göra åt er. Utan rollen blir modellen en startpunkt som ingen vågar ändra. Dokument som bara ska synas för partners eller inloggade användare behöver dessutom en egen behörighetsregel, så ägandet rör inte bara innehållet utan också vem som får se det.

Glanser

På sidan om PIM ser ni hur vi delar upp produktdata i attribut, kanaler och ägare, så att ni kan ta med en produktfamilj och se hur den bör struktureras.