Så lyckas ni med ert PIM-införande

Ni ska skicka en offert, men produktens mått skiljer sig mellan säljunderlaget och webben. Återförsäljaren har en äldre bild. Ingen vet om dokumentet i den gemensamma mappen fortfarande gäller.

Samtidigt ligger nya artiklar och väntar på publicering. Ett PIM-införande behöver börja med besluten som håller dem tillbaka: vem som äger uppgifterna, vilka värden som gäller och när informationen får lämna huset.

PIM-införandet startar i er vardag

En säljare hittar en teknisk specifikation i ett kalkylblad. Marknad använder texten från förra lanseringen. Den som ansvarar för kundportalen hämtar ett dokument från produktavdelningen. Alla försöker göra rätt, men arbetar med olika versioner av samma artikel.

När kunden upptäcker skillnaden behöver någon reda ut vilken uppgift som gäller. Under tiden väntar offerten eller publiceringen. Produktansvarig får kontrollera underlagen igen, trots att informationen redan har hanterats på flera håll.

Det här kan uppstå även när varje avdelning sköter sitt arbete väl. En ändring av material kan påverka specifikationen, bilden och monteringsanvisningen samtidigt. Om ingen håller ihop ändringen kan en kanal få rätt dokument medan en annan behåller det gamla.

En ny eller ändrad produkt kräver fler beslut än ett nytt artikelnummer. Attribut, specifikationer, bilder, dokument och översättningar behöver stämma överens. Dessutom behöver någon avgöra vad respektive kanal ska visa och när uppgifterna är godkända.

Ett typiskt exempel är en produkt som får en ny anslutning. Sälj behöver rätt kompatibilitet i offerten. Webbansvarig behöver kunna filtrera på anslutningen. Återförsäljaren behöver veta vilken äldre variant som ersätts och vilka tillbehör som fortfarande passar.

Produktinformation behöver därför skötas som ett löpande verksamhetsarbete. PIM ger er en gemensam plats att hantera uppgifterna, men ni behöver fortfarande fatta besluten. Förmågan blir användbar när produktförändringar går att följa hela vägen till det kunden ser.

Kartlägg källor innan ni modellerar

Börja med att följa en artikel genom dagens arbete. Ta fram posten i affärssystemet, kalkylbladet som kompletterar den och underlaget från leverantören. Jämför sedan med vad som faktiskt visas på webben och i portalen.

Anteckna var varje uppgift skapas, vem som ändrar den och vem som godkänner den. Ett fält kan finnas i flera system utan att någon har bestämt vilken källa som gäller. Just den oklarheten behöver ni lösa innan integrationen börjar flytta värden.

Kartlägg även produktfamiljer, språk och mottagande kanaler. En produktwebb kan behöva tekniska filter, medan en återförsäljarkanal kräver ett bestämt filformat. Lokala kalkylblad kan innehålla uppgifter som aldrig har nått den centrala organisationen.

Utgå från er faktiska försäljning. Enligt SCB:s statistik över webbförsäljning under 2024 sålde 30 procent av företagen i de redovisade branscherna via egen webbplats, app eller e-handelsplattform. Andelen var 21 procent inom tillverkning och 54 procent inom handel och service av motorfordon.

Er kanalstruktur behöver bedömas utifrån vilka uppgifter kunder och återförsäljare faktiskt använder. En kanal som kräver mycket manuellt arbete kan vara viktig att prioritera även om den hanterar en begränsad del av sortimentet.

Fördela sedan besluten tydligt. Produktägaren beslutar om affärsdefinitioner. Domänansvariga äger attribut och klassificering inom sina produktområden. IT ansvarar för integration och drift, medan marknad och sälj godkänner kanal- och språkkrav.

Samma person kan ha flera roller, men rollerna behöver vara uttalade. Annars riskerar en enkel fråga om en måttenhet att fastna mellan avdelningar. Leverantören kan hjälpa er dokumentera ansvar, men mandatet måste komma från er.

Kartläggningen är färdig när ni kan följa ett kritiskt fält från ursprung till publicering. Ni ska känna till källan, ägaren och mottagarna. Uppgifter som fortfarande saknar ägare behöver få ett tydligt beslut innan ni modellerar dem.

En datamodell ni kan återanvända

En produkts längd kan stå som fri text i ett underlag och som ett tal i ett annat. För kunden kan båda se begripliga ut. För filtrering, jämförelser och kanalexport behöver ni bestämma ett gemensamt sätt att lagra värdet.

En kanonisk datamodell är er överenskomna struktur för produktinformationen. Den beskriver attribut, datatyper och tillåtna värden. Där ingår också varianter, produktrelationer och förpackningshierarkier, så att exempelvis styck, förpackning och pall kan skiljas åt.

Definiera vilka egenskaper en variant får ärva från huvudprodukten. En gemensam beskrivning kan fungera för hela familjen, medan mått och kompatibilitet behöver följa den enskilda varianten. Otydliga arvsregler gör det svårt att se var ett fel behöver rättas.

Produktrelationer behöver också ha en bestämd betydelse. Ett tillbehör, en reservdel och en ersättningsprodukt beskriver olika förhållanden. Om allt lagras som relaterade produkter får mottagande kanaler svårt att visa rätt rekommendation.

Bestäm därefter vad publiceringsklar betyder per kanal. Saknad kompatibilitet kan behöva blockera en teknisk artikel. En kompletterande inspirationsbild kan få tillkomma senare. Den skillnaden behöver finnas i valideringsreglerna så att redaktören slipper tolka varje produkt från början.

Flera språk och enheter kräver uttryckliga regler. Ett godkänt svenskt fält säger inget om den norska översättningen. Dokumentera även källa, ändring och godkännande så att ni kan kontrollera hur ett värde har kommit till.

Livscykeldata behöver få plats i modellen redan när ni bestämmer strukturen. GS1 Sweden beskriver digitala produktpass som en produktidentitet kopplad till en eller flera datakällor inom EU:s förordning om ekodesign för hållbara produkter. Informationen kan omfatta hållbarhetsprestanda, ursprung, garanti, återvinning samt monterings- och reparationsinstruktioner.

Det betyder inte att samtliga uppgifter måste samlas in före första publiceringen. Identifierare och relationer bör däremot kunna koppla rätt underlag till rätt produktversion. Markera vilka uppgifter som väntar på leverantören eller produktutvecklingen och vem som ska verifiera dem.

Arbetet med strukturerade PIM-data hör nära ihop med dessa beslut. Första leveransen kan omfatta webb och kundportal. Modellen bör samtidigt kunna utökas med nya uppgifter utan att befintliga fält byter betydelse.

Skilj affärssystemets fält från PIM

Priset i kundportalen ska följa affärssystemets prislogik. Produktbeskrivningen behöver kunna bearbetas av den som ansvarar för innehållet. Om samma fält får ändras fritt i båda systemen kan nästa synkronisering skriva över ett godkänt värde.

Låt affärssystemet bära artikelnummer, grunddata, pris, lager och orderrelaterade uppgifter. PIM hanterar berikade texter, attribut, bilder och dokument. Varje fält behöver ändå ett uttryckligt beslut om vilket system som är auktoritativ källa.

Beskriv varje flödes riktning och frekvens. Ange vad som händer när ett värde saknas, när mottagaren avvisar posten och när systemen säger olika. Fel behöver få en ansvarig mottagare och en begriplig orsak, så att någon kan rätta dem.

Kräv också idempotens. Det innebär att en omkörning av samma meddelande inte skapar dubbletter eller upprepar en ändring felaktigt. En avbruten körning ska kunna återupptas utan att någon manuellt behöver gissa vilka poster som redan har behandlats.

Sambandet mellan e-handel och affärssystem behöver prövas med verkliga artikeldata. Välj ett pilotsortiment som innehåller enkla produkter, varianter, reservdelar och ofullständiga leverantörsunderlag. Ett urval med enbart välstädade artiklar döljer problemen ni behöver upptäcka.

Normalisera pilotens värden och kör hela flödet mot en faktisk publiceringskanal. Kontrollera att artikelns innehåll visas korrekt och att en avvisad uppgift går att följa tillbaka. Bestäm godkännandekriterierna före testet, så att bedömningen inte ändras när problem dyker upp.

Testa dataschema, transformationer och integrationer. Behörigheter, prestanda och användarnas acceptans behöver också ingå. En tekniskt lyckad överföring kan fortfarande ge fel filtrering eller göra dokument synliga för fel mottagare.

Mät en egen baslinje innan ni börjar. Följ kompletthetsgrad, importfel, tid till publicering, manuella korrigeringar och godkännanden utan återarbete.

Antalet importerade artiklar säger för lite om kvaliteten. Följ även andelen publiceringsklara artiklar och vilka regler som blockerar resten. Om ni använder ett sammanvägt kvalitetsmått behöver blockerande fel fortfarande stoppa publiceringen, även när övriga fält är kompletta.

Vad ett PIM-införande kräver av er

Produktägaren behöver kunna fatta beslut när avdelningarna använder olika definitioner. Den tiden måste finnas i kalendern. Om alla frågor skjuts till nästa möte fortsätter arbetet att vänta, även när systemet är färdigkonfigurerat.

Ni behöver också acceptera gemensamma definitioner. En lokal benämning kan vara invand och fungera väl inom en avdelning. När flera kanaler ska återanvända samma fält behöver organisationen enas om vad värdet betyder och vilka undantag som tillåts.

En blockerande regel måste få konsekvenser även när lanseringen är nära. Om någon alltid kan publicera ändå blir regeln svår att lita på. Eventuella undantag behöver ha en namngiven beslutsfattare, dokumenterad orsak och plan för rättning.

Ett separat PIM-system passar inte varje verksamhet. Har ni ett litet, stabilt sortiment och en enda kanal kan tydliga rutiner i affärssystemet räcka. Ett nytt system tillför då administration som behöver vägas mot den faktiska nyttan.

Flera språk, återförsäljare och återkommande variantändringar ger andra förutsättningar. Bedöm hur mycket arbete ni lägger på att kontrollera, komplettera och skicka samma uppgifter. Välj omfattning efter de arbetsmoment som behöver förändras och de personer som kan ta ansvar för dem.

AI kräver ytterligare beslut om tillåtna ändringar. Enligt SCB:s statistik om företagens AI-användning ökade användningen från 25,2 procent 2024 till 35,0 procent 2025. Bland de AI-användande företagen använder 41,7 procent tekniken för marknadsföring och försäljning.

Låt AI föreslå sammanfattningar och sökord utifrån godkända underlag som en försiktig start. Tekniska attribut behöver en kontrollerbar källa eller produktägarens godkännande. Logga förslaget, ändringen och vem som godkände resultatet.

Även en sammanfattning kan innehålla ett felaktigt löfte. Mät därför fel per publicerad produkt innan fler fält automatiseras. Ökad textproduktion kan innebära att fler uppgifter behöver granskas, särskilt när samma innehåll ska användas i flera kanaler.

Tre frågor innan ni väljer väg

Be leverantören svara med era egna artikeldata framför sig. Vem äger varje fält när affärssystem och PIM visar olika värden? Svaret behöver ange vilket system som gäller och vem hos er som får besluta om ett undantag.

Hur stoppas en artikel när en blockerande regel fallerar? En genomgång behöver visa att artikeln faktiskt hålls tillbaka, att felet blir begripligt och att rätt person kan åtgärda det. En varningssymbol utan tydlig hantering lämnar mycket arbete åt redaktören.

Vem tar funktions- och kompatibilitetsansvar när plattformen eller affärssystemet får en ny version? Svaret behöver omfatta hela flödet, inklusive beroenden mellan systemen. Svaren på frågorna avslöjar vilket ansvar som ligger kvar hos er efter go-live.

Be att ansvarsfördelningen skrivs in i omfattningen och förvaltningsavtalet. Formuleringar om hjälp vid behov säger begränsat om vem som utreder ett fel. Det behöver framgå vem som driver ärendet när flera delar av lösningen berörs.

Hos oss samlas berikat innehåll i PIM för hantering och distribution till webb, kundportaler och återförsäljarkanaler. Affärssystemet bär artikelnummer, grunddata, prislogik och transaktionsrelaterad information. Vi håller därmed isär innehållsarbetet och de affärsregler som styr kundens köp.

Glanser Care innebär att vi tar funktions- och kompatibilitetsansvar för lösningen som helhet, även när plattformen eller affärssystemet får en ny version. Ansvaret omfattar versionsuppföljning, kompatibilitet genom uppgraderingar och buggrättning till avtalad fast månadskostnad. Uppgraderingar kräver ingen ny offert.

När ni bedömer en Litium-plattform behöver därför även ansvar efter lanseringen finnas med i underlaget. Plattformens möjligheter och leverantörens åtagande behöver gå att bedöma var för sig. Er organisation behåller ansvaret för produktuppgifternas riktighet och de personer som får godkänna dem.

En fungerande överlämning behöver till sist prövas av dem som ska arbeta i lösningen. De ska kunna hitta ett stoppat fält, förstå orsaken och veta vem som fattar nästa beslut. Där blir det tydligt om arbetssättet håller även efter att projektgruppen har lämnat.

På sidan om PIM ser ni hur vi styr, berikar och distribuerar produktinformation till webb, kundportaler och återförsäljarkanaler.