Utbenat: Masterdata

Inledning – Den digitala kalendern

Sebastian:

‍Tänk dig att ni i familjen har skaffat en gemensam digital kalender, synkad till allas telefoner. Syftet är glasklart: att få ihop vardagen och slippa dubbelbokningar. Det fungerar fantastiskt till en början.

Men en fredagseftermiddag kollar du i appen, ser att kvällen är helt tom, och planerar in en lugn hemmakväll. Du hinner precis sätta dig i soffan när din partner kommer hem och säger: "Varför sitter du där, jag har ju bokat in att vi ska på middag hos grannarna ikväll! Jag sa ju det i tisdags, jag hann bara inte lägga in det i appen..."

Och där står ni. Appen fungerar tekniskt sett felfritt, men kalendern hjälper ju inte om inte processen efterlevs. Om inte regeln "står det inte i kalendern, så finns det inte" följs till hundra procent av alla inblandade, så urholkas värdet av att ha en gemensam kalender väldigt snabbt.

Idag ska vi prata om den där digitala kalendern, fast i företagsvärlden. Vi ska prata om masterdata. Begreppet som handlar om ambitionen att få en säkrad källa till sanning. En "single source of truth". Men vi ska också kika på varför det här konceptet ofta faller isär när vi frestas att ta genvägar i vardagen.

Definitionen: Ensamrätten att bestämma

Sebastian:

‍Masterdata handlar om att få ordning på er allra viktigaste information. Era kunder, produkter och leverantörer. För att uppnå det målet måste vi förstå en grundläggande princip: om ett system ska anses vara master för något, då måste det systemet ha ensamrätt att bestämma över den datan.

Om man tillåter att andra system uppdaterar informationen lite från sidan, eller om medarbetare rundar processen, så bryts masterdata-kedjan. Det är exakt som med familjekalendern: tillåter ni att viktiga planer bara kommuniceras muntligt vid sidan av, ja, då förlorar systemet sitt syfte och sanningen glöms bort och går förlorad.

Insamling vs. ägarskap – adressexemplet

Sebastian:

‍Hur ser det här ut i praktiken? Ofta handlar det om att vi måste skilja på var information samlas in, och vem som faktiskt äger den "officiella" sanningen.

Låt oss ta kundens adress som exempel. När en kund lägger en order i e-handeln är det helt rimligt att de anger en adress, typiskt en leveransadress. Kanske hjälper de sina föräldrar med en renovering och vill ha varorna skickade dit, eller så köper de en present som ska levereras hem till någon. För företag kan det handla om leverans till en byggarbetsplats.

Här uppstår en vanlig fälla. Om verksamheten tillåts hämta kundinformation från e-handeln istället för från CRM-systemet – som bör vara master för kunden – så riskerar vi att tro att kunden har flyttat. Plötsligt tror vi att föräldrarnas adress är kundens permanenta hemadress eller att företagets huvudkontor har flyttat till en byggarbetsplats. CRM-systemet måste vara den säkrade källan för kundens faktiska adress – oavsett om det är en hemadress, ett huvudkontor eller en faktureringsadress.

E-handeln samlar in data för den specifika affären. CRM-systemet om kunden i sin helhet. Om vi tappar den här distinktionen kan marknadsmaterialet hamna hos föräldrarna och fakturan på byggarbetsplatsen. Vi måste veta vem som äger sanningen om kundens adress, utifrån vårt behov, och se till att bara hämta information därifrån.

Valideringsspärren – produktexemplet

Sebastian:

‍Samma sak gäller produktdata, som ofta samlas in från många olika håll samtidigt. En del information hämtas kanske från leverantören via en leverantörsportal, annat dras in från externa branschdatabaser, och en tredje del skapas manuellt av en arbetsgrupp direkt i ert PIM- eller ERP-system.

Här är det ofta PIM-systemet, om man har ett, som är master för produktdata. När en produkt väl ligger i PIM, så spelar det ingen roll om en leverantör går in och gör en ändring i leverantörsportalen. Den ändringen börjar inte gälla ute i bolaget förrän den har validerats och godkänts inne i PIM-systemet. Det är först då den träder i kraft. Inget annat system får hämta produkter från en annan källa än just PIM, hur lockande det än kan vara att gå direkt till källan.

För tappar vi kontroll över flödet så spelar våra rigida och kvalitetssäkrade processer ingen roll, det blir ändå fel data som används.

Distribuerat ägarskap – objekt vs. attribut

Sebastian:

‍Men... verkligheten är dock sällan helt svartvit. Ibland måste vi dela på ansvaret, och då behöver vi prata om objekt och attribut. Produkten i sig är ett objekt. PIM är master för objektet produktdata. Men produkten har också en mängd attribut, och ett av dessa kan vara ett ERP-ID, alltså det artikelnummer produkten har inne i affärssystemet.

Här är det affärssystemet, ert ERP, som är master för just den specifika pusselbiten. PIM får inte hitta på ett eget ERP-ID. Så även om ett system ska vara källan vi hämtar helheten ifrån, så kan rätten att uppdatera och ändra specifika detaljer – attributen – vara distribuerad. Det gäller bara att ha stenkoll på vilket system som äger vad.

Det är när den här verkligheten blir tillräckligt komplex som vi behöver dedikerade masterdata-system. Men för de flesta är processerna problemet, inte bristen på systemstöd.

Respektera hierarkin – dirigenten i orkestern

Sebastian:

‍För att få det här att fungera i längden måste vi sätta gränser. Det upplevs ofta som oundvikligt att bygga små, snabba genvägar mellan system för att spara tid här och nu. Men varje genväg är en risk som sakta urholkar ett masterdata-koncept.

Föreställ dig en stor symfoniorkester. Hundra musiker som alla sitter med sina egna noter och instrument. De spelar fantastiskt var och en för sig. Men för att det ska bli ljuv musik måste alla fästa blicken på en enda punkt: dirigenten.

Om trummisen och basisten tycker att tempot är för långsamt och kör sitt eget race... ja, då tar det tre sekunder innan hela symfonin låter som en tågolycka. Masterdata handlar om att tvinga alla era system, och processer, att ständigt titta på dirigenten. Även om man gärna hade jammat med systemet bredvid.

Konkret handling: Så börjar du på måndag

Sebastian:

‍Så här kan ni göra på måndag. Välj ut ett av era viktigaste begrepp, till exempel "produkt". Rita upp en enkel skiss över var informationen samlas in idag, och vilket system som faktiskt är er dirigent, er master.

Leta sedan efter tjuvkopplingarna. Hämtar e-handeln information direkt från affärssystemet ibland? Då har ni kanske hittat en genväg som urholkar er sanning, som förstör symfonin. Stäng den, och led tillbaka flödet så att master-systemet ensamt får hålla taktpinnen.

Summering

Sebastian:

‍För att sammanfatta: Masterdata handlar om att få en enda, säkrad källa till sanning. För att lyckas måste det utvalda systemet ha ensamrätt att bestämma över datan. Skilj på de system som samlar in information och de som äger sanningen, och respektera processen. Det är så ni gör familjekalendern trovärdig och värdefull.

Tack för att du lyssnade på dagens avsnitt av Utbenat. Vill du prata mer om dagens ämne eller bara prata data, hör av er till oss – vi finns på LinkedIn. Eller kontakta oss via vår hemsida, fiwe.com – med ett dubbel-v. Vi hörs, och ta hand om er där ute!

Du har lyssnat på Syntra, en podd från Fiwe.