Syv tegn på, at I ikke har så godt styr på jeres produktdata, som I tror

Det hører jeg ofte.

Og i mange tilfælde er det også rigtigt – hvis det at have styr på produktdata betyder, at produkterne er oprettet, webshoppen fungerer, og de vigtigste specifikationer er udfyldt.

Men det er ikke nødvendigvis det samme som, at virksomheden har reel kontrol over sine produktdata.

Reel kontrol betyder blandt andet, at virksomheden ved:

• hvor en oplysning kommer fra
• hvad den præcist betyder
• hvem der ejer og godkender den
• hvordan kvaliteten bliver kontrolleret
• hvilke systemer og kanaler der anvender den
• hvordan en rettelse bliver distribueret til de relevante steder

Det er sjældent de tomme felter, der afslører, at der er et problem. Det gør de små arbejdsgange omkring dataene.

Det er produktchefen, der har sit eget regneark. Webshopansvarlige, der retter en fejl direkte på produktsiden. Sælgeren, der ved, at en bestemt specifikation ikke helt betyder det, der står. Eller udvikleren, der har bygget en særregel, som ingen længere kan forklare.

Hver enkelt situation kan virke harmløs. Men tilsammen kan de være tegn på, at organisationen ikke har så godt styr på sine produktdata, som den tror.

En webshopansvarlig, der retter en forkert værdi direkte på produktsiden, fordi det er hurtigere end at finde ud af, hvor fejlen kommer fra.

Eller en produktchef, der har sit eget Excel-ark med de oplysninger, som ikke passer ind i virksomhedens øvrige systemer.

Hver enkelt handling kan virke både fornuftig og nødvendig.

Problemet er, at de tilsammen kan udgøre en skjult driftsmodel, hvor medarbejderne hver dag kompenserer for produktdata, der er ufuldstændige, inkonsistente eller dårligt strukturerede.

Fordi arbejdet er fordelt mellem flere afdelinger og budgetter, bliver den samlede omkostning sjældent gjort op.

Derfor undervurderer mange virksomheder, hvad dårlige produktdata faktisk koster.

Her er syv tegn, I bør være opmærksomme på.

TEGN 1

Excel-arket er den egentlige sandhed

Excel er ikke i sig selv et problem. Det er et fleksibelt og effektivt værktøj til analyser, masseændringer, import, datavask og midlertidig bearbejdning. Problemet opstår, når et personligt eller lokalt regneark bliver virksomhedens reelle datakilde.

Det kan eksempelvis være et ark med:

• de nyeste tekniske specifikationer
• korrekte produktrelationer
• leverandørens originale værdier
• manglende oversættelser
• oplysninger om kompatibilitet
• markering af udgåede produkter
• særlige regler for enkelte produktserier

Oplysningerne findes altså, men ikke nødvendigvis i det system, som resten af organisationen forventer er master.

Det skaber flere versioner af sandheden. Produktchefen har én version. PIM-systemet har en anden. ERP-systemet har en tredje. Webshoppen viser måske en fjerde.

Så længe den medarbejder, der forstår regnearket, er tilgængelig, fungerer processen måske nogenlunde. Men virksomheden bliver afhængig af, at den pågældende medarbejder husker:

• hvilket ark der er det nyeste
• hvilke kolonner der er gældende
• hvilke værdier der ikke må overskrives
• hvem der skal modtage den opdaterede fil
• hvordan data efterfølgende kommer videre til systemerne

Det er ikke kun et teknisk problem. Det er en organisatorisk risiko.

Det afgørende spørgsmål er derfor ikke, om I bruger Excel. Det gør de fleste virksomheder. Spørgsmålet er:

Hvis svaret er ja, fungerer Excel ikke længere bare som et værktøj. Det fungerer som et skjult mastersystem.

TEGN 2

Den samme egenskab har flere navne – og det samme navn har flere betydninger

Et klassisk tegn på manglende produktdatastyring er, at den samme egenskab findes under flere navne. Det kan eksempelvis være:

• Diameter
• Ø
• Produktdiameter
• Udvendig diameter
• Diameter i millimeter

Nogle af felterne er måske reelt ens. Andre ligner hinanden, men beskriver forskellige egenskaber.

Det modsatte problem findes også: Det samme attributnavn bruges om forskellige ting. "Længde" kan eksempelvis betyde produktets samlede længde, arbejdslængde, skærelængde, kabellængde, pakkens længde eller transportlængde.

Hvis betydningen ikke er klart defineret, kan et system godt flytte værdien fra ét sted til et andet. Det kan bare ikke afgøre, om værdien bliver brugt korrekt. Det skaber problemer i blandt andet produktfiltre, sammenligningstabeller, integrationer, produktfeeds, oversættelser, rapportering, søgning og tekniske dokumenter.

En webshop kan eksempelvis ende med at lade kunden filtrere på "længde", selv om værdierne i praksis repræsenterer tre forskellige former for længde.

Dataene er udfyldt. De er bare ikke entydige.

Løsningen er heller ikke nødvendigvis at samle alt i én global attribut. Nogle egenskaber skal være fælles på tværs af sortimentet, mens andre kun giver mening inden for bestemte produktkategorier. Det afgørende er, at virksomheden bevidst har defineret:

• hvad attributten betyder
• hvilke produkter den gælder for
• hvilken datatype den anvender
• hvilken måleenhed der forventes
• hvordan den må bruges
• om den kan sammenlignes på tværs af kategorier

Et godt testspørgsmål er:

Hvis ikke, har virksomheden ikke bare et navngivningsproblem. Den har et definitionsproblem.

TEGN 3

Fejl bliver rettet i kanalen – ikke ved kilden

Når en produktinformation er forkert på en webshop, markedsplads eller forhandlerportal, er det naturligt at ville rette fejlen så hurtigt som muligt. Det er ofte også det rigtige at gøre akut.

Problemet opstår, når den lokale rettelse bliver den permanente løsning.

En produkttitel ændres direkte i webshoppen. En specifikation korrigeres i et marketplace-feed. En beskrivelse tilpasses i CMS'et. En produktrelation oprettes manuelt i den enkelte salgskanal.

Fejlen er væk dér, hvor den blev opdaget. Men kilden er ikke nødvendigvis blevet rettet.

Ved næste synkronisering kan rettelsen blive overskrevet. Eller den forkerte information lever videre i andre kanaler, fordi ingen ved, at den er blevet korrigeret ét sted.

Efterhånden opstår der kanalversioner af produktdataene: én titel i PIM, en anden i webshoppen, en tredje på markedspladsen og en fjerde i det trykte katalog.

Det betyder ikke, at alle kanaler skal vise præcis den samme tekst. Kanaltilpasset indhold kan være både relevant og nødvendigt. En kort produkttitel til en markedsplads kan eksempelvis være anderledes end overskriften på virksomhedens egen webshop.

Forskellen er, om variationen er bevidst og styret, eller om den er opstået som en lokal nødreparation. En styret kanaltilpasning har et defineret formål, et ejerskab og en tydelig placering i datamodellen. En lokal korrektion eksisterer, fordi det var den hurtigste måde at få problemet til at forsvinde på.

Det centrale spørgsmål er:

Hvis svaret afhænger af, at en medarbejder husker at sende en mail eller opdatere et ekstra system, er processen sårbar.

TEGN 4

Ingen kan svare entydigt på, hvem der ejer dataene

Når en produktinformation er forkert på en webshop, markedsplads eller forhandlerportal, er det naturligt at ville rette fejlen så hurtigt som muligt. Det er ofte også det rigtige at gøre akut.

Problemet opstår, når den lokale rettelse bliver den permanente løsning.

En produkttitel ændres direkte i webshoppen. En specifikation korrigeres i et marketplace-feed. En beskrivelse tilpasses i CMS'et. En produktrelation oprettes manuelt i den enkelte salgskanal.

Fejlen er væk dér, hvor den blev opdaget. Men kilden er ikke nødvendigvis blevet rettet.

Ved næste synkronisering kan rettelsen blive overskrevet. Eller den forkerte information lever videre i andre kanaler, fordi ingen ved, at den er blevet korrigeret ét sted.

Efterhånden opstår der kanalversioner af produktdataene: én titel i PIM, en anden i webshoppen, en tredje på markedspladsen og en fjerde i det trykte katalog.

Det betyder ikke, at alle kanaler skal vise præcis den samme tekst. Kanaltilpasset indhold kan være både relevant og nødvendigt. En kort produkttitel til en markedsplads kan eksempelvis være anderledes end overskriften på virksomhedens egen webshop.

Forskellen er, om variationen er bevidst og styret, eller om den er opstået som en lokal nødreparation. En styret kanaltilpasning har et defineret formål, et ejerskab og en tydelig placering i datamodellen. En lokal korrektion eksisterer, fordi det var den hurtigste måde at få problemet til at forsvinde på.

Det centrale spørgsmål er:

Hvis svaret afhænger af, at en medarbejder husker at sende en mail eller opdatere et ekstra system, er processen sårbar.

TEGN 5

Produktbeskrivelserne bliver brugt som database

En produktbeskrivelse skal hjælpe kunden med at forstå produktet. Men i mange virksomheder bliver beskrivelsen også det sted, hvor oplysninger ender, når der ikke findes en tydelig struktur til dem.

En beskrivelse kan eksempelvis indeholde, at produktet:

• kan anvendes udendørs
• tåler en bestemt temperatur
• passer til en bestemt maskinserie
• ikke bør bruges til en bestemt opgave
• leveres med et bestemt tilbehør
• overholder en bestemt standard
• erstatter en tidligere model

Oplysningen findes altså, men kun som en del af en tekst. Det skaber flere problemer.

Et webshopfilter kan ikke uden videre bruge informationen. En integration kan ikke sikkert udtrække den. En markedsplads kan ikke modtage den som en entydig egenskab. Og hvis oplysningen ændrer sig, skal virksomheden finde alle de beskrivelser, hvor den er blevet kopieret ind.

Det bliver særligt tydeligt, når den samme beskrivelse eller tekstblok kopieres mellem mange produkter. Kopiering er effektivt, når produkterne minder om hinanden. Men den skaber også en skjult vedligeholdelsesopgave. Hvis en fælles oplysning ændrer sig, skal nogen vide:

• hvilke produkter teksten er kopieret til
• om den er tilpasset lokalt
• hvilke sprogversioner der skal ændres
• om samme information også findes i dokumenter og feeds

Det betyder ikke, at alle produktbeskrivelser skal sammensættes mekanisk af felter. God formidling kræver stadig sammenhængende tekst, kontekst og redaktionel kvalitet. Men fakta, der skal kunne genbruges, filtreres, valideres eller vedligeholdes centralt, bør som udgangspunkt ikke kun eksistere inde i en beskrivelse.

Spørgsmålet er:

Hvis svaret er "mange", bruger virksomheden sandsynligvis sine beskrivelser som en uformel database.

TEGN 6

Én kategoristruktur forsøger at løse alle opgaver

En kategoristruktur ser umiddelbart enkel ud. Produkterne skal bare placeres de rigtige steder. Men kategorier anvendes ofte til mange forskellige formål på samme tid. De kan blandt andet bruges til:

• navigation på webshoppen
• intern produktklassifikation
• rapportering
• tildeling af attributter
• produktansvar
• publiceringsregler
• leverandørimport
• integrationer
• markedspladsfeeds
• dokumentstruktur

Problemet er, at de forskellige formål ikke nødvendigvis kræver den samme struktur. En kunde leder måske efter produkter ud fra anvendelse. Produktorganisationen arbejder ud fra tekniske produktfamilier. Økonomiafdelingen rapporterer efter varegrupper. Leverandøren leverer data efter sin egen klassifikation.

Hvis én kategoristruktur skal tilfredsstille alle behov, opstår der kompromiser. Et produkt placeres måske i en kategori, fordi det skal arve bestemte attributter – ikke fordi kategorien giver mening for kunden. Eller produktet placeres dér, hvor kunden forventer at finde det, men dermed bliver den interne rapportering upræcis.

Det kan også føre til, at samme produkt kopieres ind i flere kategorier, selv om virksomheden reelt forsøger at beskrive forskellige relationer:

• Hvad er produktet?
• Hvad bruges det til?
• Hvilken branche er det relevant for?
• Hvilke andre produkter hører det sammen med?
• Hvor skal kunden kunne finde det?

Det er ikke nødvendigvis spørgsmål, der bør besvares af den samme hierarkiske struktur. Nogle behov løses bedre gennem separate klassifikationer, egenskaber, produktrelationer, anvendelsesmærkninger eller kanalbestemte kategorier.

Det centrale spørgsmål er:

Hvis svaret er "dem alle sammen", er strukturen sandsynligvis blevet belastet med flere opgaver, end den kan håndtere.

TEGN 7

Datakvalitet opdages først, når produktet skal publiceres

I mange virksomheder bliver webshoppen eller produktfeedet det sted, hvor datakvaliteten reelt bliver testet. Det er ved publiceringen, man opdager, at:

• obligatoriske felter mangler
• måleenheder er inkonsistente
• produktbilledet har forkert format
• en oversættelse ikke er lavet
• en variant mangler en central specifikation
• en kategori ikke er tildelt
• en relation peger på et udgået produkt
• leverandørens data ikke kan bruges direkte

Det betyder, at kvalitetssikringen sker sent i processen, hvor fejlene er dyrest og mest synlige. Produktet er måske allerede annonceret. Salgsorganisationen venter. Kampagnen er planlagt. Eller en kunde har fundet den mangelfulde information.

Kvalitet bør ikke være en kontrol, der først sker, når produktet står ved udgangen til en salgskanal. Den bør være en del af hele produktets informationsflow:

1. når data modtages
2. når de bliver normaliseret
3. når de bliver beriget
4. når de bliver godkendt
5. før de distribueres

Det kræver, at virksomheden har defineret, hvad "klar" betyder. Og det vil sjældent være det samme for alle produkter og kanaler. Et produkt kan være klar til et internt salgsværktøj, men ikke til en offentlig webshop. Det kan være klar til det danske marked, men mangle lovpligtig dokumentation til et andet land. Det kan være 100 procent udfyldt og stadig indeholde forkerte eller meningsløse værdier.

Spørgsmålet er:

Hvis webshoppen fungerer som kvalitetskontrol, ligger kontrollen for sent.

Tegnene er forskellige – men problemet er det samme

De syv tegn kan umiddelbart se ud som forskellige problemer.

Men ofte er de forskellige udtryk for det samme grundlæggende forhold:

Når den forståelse mangler, begynder organisationen at kompensere. Medarbejderne laver lokale filer. De husker undtagelser. De kopierer tekster. De retter data i kanalerne. De spørger den kollega, der "plejer at vide det". Og de bygger særregler ind i integrationerne.

Det kan fungere i lang tid. Faktisk kan organisationen blive så god til at kompensere, at den ikke længere ser arbejdsgangene som tegn på et problem. De bliver bare opfattet som den måde, arbejdet udføres på.

Et enkelt produktdata-tjek - prøv selv

I behøver ikke begynde med en stor analyse af hele sortimentet. Vælg én vigtig produktfamilie, og følg dens data fra kilde til kunde.

Bed repræsentanter fra produktorganisationen, e-commerce, salg, marketing og IT om hver især at svare på følgende spørgsmål:

Det interessante er ikke kun svarene. Det interessante er, om afdelingerne giver de samme svar.

Hvis produktchefen, IT, e-commerce og marketing har forskellige opfattelser af, hvor data kommer fra, hvem der ejer dem, og hvornår de er korrekte, har I identificeret et centralt produktdataproblem. Ikke nødvendigvis et systemproblem. Men et styringsproblem.

At have data er ikke det samme som at have styr på dem

De fleste virksomheder mangler ikke produktinformation. De har ofte store mængder af den fordelt mellem ERP, PIM, webshop, leverandørfiler, dokumenter, regneark og medarbejdere.

Udfordringen er, om informationen hænger sammen og kan anvendes uden konstant menneskelig fortolkning.

At have styr på produktdata betyder derfor ikke, at alle felter er udfyldt, eller at der ikke findes fejl. Det betyder, at organisationen har kontrol over:

• hvad informationen betyder
• hvor den kommer fra
• hvem der har ansvaret
• hvordan kvaliteten vurderes
• hvordan den bliver genbrugt
• hvordan ændringer slår igennem

De syv tegn fortæller, at der sandsynligvis er et problem. Men de fortæller ikke alene, hvad gode og anvendelige produktdata bør bestå af.

Det kræver en fælles model.