Master Data: Headless, men inte huvudlöst

Det har alltid varit viktigt med genomtänkt utformning av master data för sina produkter, men nu i en tid där IT-plattformar byggs enligt principer som Headless och Composable Commerce ställs högre krav på god medvetenhet kring ämnet. Vad är det då framför allt som man behöver hålla koll på, och varför?

Vad är master data?

En lämplig startpunkt för det här samtalet är att definiera vad som egentligen menas med “master data”. I en produkt-kontext innebär det strukturerad information som på ett vitalt sätt särskiljer en produkt från övriga, och tydliggör dess karaktärsdrag. I begreppets själva kärna ligger lagerhantering och SKU (stock keeping unit) vilket handlar om vilken vara det är som kunden faktiskt lägger i sin varukorg vid ett köp. Det kan således handla om information så som produktkategori, varumärke, färg, storlek, etcetera.

Vad utgör bra master data?

Vad har då en bra master data-uppsättning för kännetecken? Till att börja med bör det understrykas att det inte finns någon vedertagen, global “alltid rätt”-standard. Det finns olika metoder med olika för- och nackdelar, både avseende hur man bygger sin produkthierarki och hur man administrerar artikelnummer.

Utifrån de syften produktdata används för, behöver man hur som helst oavsett val av lösning möjliggöra unik identifikation av produkten, och det över tid. Även om sortimentet förändras och utökas, och fler system som använder produktdata läggs till i portföljen, behöver varje produkt ha en beständig unik identifierare.

Utöver detta kan en klok datastrategi ge flera andra fördelar. En genomtänkt produkthierarki med logiska hierarkiska “våningsplan” kan underlätta på flera sätt, till exempel avseende intern förståelse bland personalen, enklare samarbete över avdelningar, logisk uppbyggnad av navigering på en försäljningssajt, skapandet av SEO-vänliga produktlänkar, samt smidigare rapportering kring hur olika delar av sortimentet presterar försäljningsmässigt.

Tillåt mig försöka exemplifiera lite, genom att jämföra två fiktiva och väldigt olika angreppssätt. Antag att vi har ett företags två första produkter, ett par svarta sneakers för dam i storlek 38 och ett par bruna boots för herr i storlek 44.

Setup 1: Enklast möjliga

Här har vi som artikelnummer enbart unika ID, i löpnummer-format. Unika master data-attribut omfattar enbart huvudkategori och kön, resten återfinns i produktbeskrivning i fritext.

Väldigt snabbt och enkelt att sätta upp, men med uppenbara utmaningar så fort antalet produkter börjar växa. Artikelnumret ger ingen som helst information kring vad det är för produkt, och det kommer heller inte att utan manuell sammanställning få fram försäljningssiffror för till exempel alla sneakers eller alla bruna skor.

Setup 2: Mer utförlig

Här kan den första strängen läsas som “SN/W/0001/BL/38” vilket i tur och ordning motsvarar underkategori, kön, löpnummer, färg och storlek.

En sådan här modell kräver lite mer eftertanke innan uppsättning, för att över tid säkerställa möjligheten att bibehålla unika kombinationer. Resultatet blir dock artikelnummer som är i hög grad självförklarande. Den utökade berikningen av produkten möjliggör också en enklare och mer strukturerad uppföljning samt enklare uppskapande av SEO-vänliga URL-slugs.

Andra faktorer som påverkar

Datastrukturen bör även ta prissättningsstrategier i beaktande. Vissa varor säljs inte i antal, med pris per styck, utan kan behöva definieras utifrån volym- eller viktmått som liter, gram eller kilo. Här bör då hänsyn tas till hur man vill prissätta och till kund kommunicera pris, när man väljer att definiera vad som utgör “en” produkt.

Internationellt verksamma företag bör även ta hänsyn till hur namn på produktkategorier, färger och annat som kan ingå ett produktnamn och/eller URL-slugs. Engelska ordval kan sannolikt vara att föredra, då de har högst internationell gångbarhet vid verksamhet med stor global spridning.

En sista aspekt är att hålla valet av faktiska tecken så enkelt som möjligt. Många IT-system har svårt att hantera vissa specialtecken, varför till exempel “/” eller “_” eller “%” bör undvikas. Den enda vanligtvis trygga avdelaren är i så fall ett hederligt dash, “-”. Av samma anledning bör inledande nollor (t.ex. ett artikelnummer som “0012345”) undvikas då alla IT-system inte kan hantera det formatet, och man bör även säkerställa att det inte finns begränsningar kring antal tecken som kan ställa till det.

Headless-eran och dess utmaningar

Genom en fras som “många IT-system” här ovan kommer vi in på en om än inte ny så kanske tilltagande utmaning. Dagens IT-miljöer är ofta uppbyggda utifrån de premisser som brukar kallas headless, composable commerce, MACH eller liknande buzzwords. Vad det betyder är i praktiken att man istället för en monolitisk plattform för att hantera alla delar av sin verksamhet bygger en kedja av bästa möjliga verktyg för respektive funktion.

En styrka med detta är så klart att man kan få vassare verktyg för specifika uppgifter, och bli mer lättrörlig och utvecklingsbar i sin verksamhet. En utmaning kan dock vara vad det ställer för krav på eftertanke och utformning avseende just master data.

Det som ovan nämndes om formatregler så som tillåtna tecken, stränglängd för olika fält, språkstöd etcetera, blir ju mångfalt mer relevant om det är fem olika IT-systems krav som skall efterlevas och inte bara ett. Lägg därtill att många företag idag också använder externa försäljningskanaler så som Marketplaces, vilket innebär att även deras krav på master data behöver tillgodoses.

En viktig uppmaning här är att även hålla koll på sina obligatoriska fält. Jag har själv varit med och hjälpt företag att felsöka problem i produktberiknings-kedjan, där rot-orsaken visat sig vara att information som är obligatorisk längre ner i kedjan inte varit det i system uppströms. Detta har då också ibland råkat förbises när produkter har satts upp, vilket ställt till det för användare i helt andra system.

Sett till allt det ovanstående, är en noggrann kartläggning och analys innan man sätter sin produktdatastruktur alltså mer på sin plats än någonsin.

Konfigurerbara produkter

En sista aspekt av ämnet är konfigurerbara produkter. Vissa företag har produkter där kunderna kan skräddarsy dem i så stor utsträckning att det inte går att sätta upp “fasta” artiklar för alla tänkbara konfigurationer, särskilt inom B2B. Här kan man behöva bygga förmågan att skapa dynamiska (men fortfarande unika och härledbara) artikelnummer, och/eller använda sig av någon form av CPQ, en produktkonfigurator som ger metodstöd för en sådan process. Det är ett ämne du kan läsa mer om i vår artikel “Vad är CPQ?”.

Summering

Hur man ska utforma sina produkters master data och artikelnummer är inte en 100% exakt vetenskap, utan nödvändig nivå av komplexitet beror på sådant som:

• Sortimentets omfång och föränderlighet över tid

• Aktiva samt eventuellt kommande försäljningskanaler

• Graden av global verksamhet

• Organisationens rapporteringsbehov

• Hur den IT-systempark som stödjer verksamheten ser ut

Oavsett hur man väljer att göra, bör valet vara ett medvetet beslut och utfallet av en analys där man tar hänsyn till de faktorer vi här har diskuterat. Har du frågor eller funderingar kring ämnet, hör gärna av dig så kan vi bollplanka!