Inlägg

Data management – se hela kedjan

För att en organisation ska få nytta av sina data behöver en hel kedja av förutsättningar vara uppfyllda. Vi behöver se och förstå hela kedjan för att hitta och förstärka svaga länkar.

En organisations data är en tillgång. Om vi kan hantera den tillgången på ett bra sätt så ger den mångfalt tillbaka. Data kan inte bara stödja verksamheten operativt utan också användas analytiskt, det vill säga ge insikter och kunskap och därmed ligga till grund för beslut och handling. Men för att en datatillgång verkligen ska ge nytta måste den tas om hand, den måste förvaltas aktivt. Det är det vi kallar Data Management.

En modell i form av en kedja

Data Management är ett område med stor spännvidd och som inkluderar alla de åtgärder som behövs för att ta hand om en dataresurs för att maximera dess värde.
För att få överblick över området kan vi använda oss av en modell över en tänkt kedja av förutsättningar, från det att data registreras någonstans tills det att man får nytta av dessa data i organisationen. Modellen är en uppräkning av förutsättningar som tillsammans bildar en kedja, där varje förutsättning behöver uppfyllas. Jag har ofta visat denna modell i olika sammanhang för att visa vad Data Management kan omfatta. Modellen kan dock kännas en aning konstlad. Man har försökt pressa in lite för mycket, speciellt i slutet av kedjan. Som jag skrev i artikeln ”Data eller information” skapas sällan kunskap direkt ur data på ett linjärt sätt vilket modellen ger sken av. Kunskapsprocessen i en organisation är en växelverkan mellan flera olika handlingar och källor, där data visserligen är en viktig källa men ändå endast en av de inblandade faktorerna. Så vi ska ta modellen med en nypa salt. Men jag tycker ändå att modellen, trots sina begränsningar, har sin poäng i att den positionerar Data Management i förhållande till angränsande och överlappande discipliner. Modellen presenteras i det följande.

Kedjan av förutsättningar

Nyttan av data uppstår bara om en serie av förutsättningar är uppfyllda. Dessa förutsättningar bildar länkar i en kedja. Varje förutsättning blir meningsfull endast om alla föregående förutsättningar i kedjan är uppfyllda. Som bekant är det den svagaste länken i en kedja som avgör om den håller. Det spelar då ingen roll hur starka de andra länkarna är. Svagheten i en länk vägs inte upp av styrkan i de andra.

Kedjan av förutsättningar kan listas som nedan. För varje förutsättning ger vi exempel på faktorer som kan bidra till att den förutsättningen kan uppfyllas.

  1. Att rätt data finns
    Att det någonstans (innanför eller utanför organisationen) finns rätt data, det vill säga som handlar om rätt saker och är anpassade till situationen.
    Bidragande faktorer: Dataplanering, dataanalys, processutveckling, utveckling av applikationer för registrering, Business Intelligence, givare för insamling av data, givare för maskindata med flera.
  2. Att man känner till att dessa data finns och var de finns
    Det händer ofta att data finns men att de som behöver den inte vet om det. Då stoppar det redan här.
    Bidragande faktorer: Aktivt sökande av datakällor och datatjänster, datakataloger, Data Dictionary, utbildning, kommunikation, informationsmodeller/- kartor med flera.
  3. Att man kan nå och få fram dessa data
    Kan vara via maskinella eller manuella tekniker.
    Bidragande faktorer: Applikationer, intranät, internet, sökmotorer, SQL, Data Warehouse, API-er, datatjänster, presentationstekniker med flera.
  4. Att man kan förstå dessa data
    Det vill säga att man kan tolka dess innebörd och syfte med stöd av sina egna referensramar.
    Bidragande faktorer: Utbildning, erfarenhet, definitionsarbete, namngivning, modeller/kartor, metadata, dokumentation, informationsanalys med flera.
  5. Att man kan lita på informationen
    Att man kan lita på att den information man tagit till sig stämmer med verkliga förhållanden.
    Bidragande faktorer: Metadata, källhänvisningar, goda erfarenheter, datakvalitetsarbete, redundans med flera.
  6. Att man kan vidarebearbeta data
    Att man kan sortera, filtrera, kombinera, summera och sammanställa data och därmed bilda sig ytterligare sammanfattad/komplex information som blir mer användbar för att dra kunskaper ur.
    Bidragande faktorer: Data-analysverktyg och metoder, Data Science, rapportverktyg, aktivt arbete med framtagning och förvaltning av rapporter med flera.
  7. Att man kan dra korrekta slutsatser från informationen
    Från informationen man fått fram behöver man sedan kunna dra slutsatser som är relevanta i sammanhanget.
    Bidragande faktorer: Domänkunskap, erfarenhet, överblick, logisk förmåga, abstraktionsförmåga, konkretionsförmåga med flera.
  8. Att man kan besluta sig för ett handlingsalternativ
    Detta baserat på slutsatserna, intuition, beslutsstil och personliga faktorer.
    Bidragande faktorer: Beslutstil, beslutsförmåga, belöningssystem, rekrytering, organisationskultur, personlig utveckling med flera.
  9. Att man kan gå från beslut till handling
    Det vill säga verkställa och agera.
    Bidragande faktorer: Genomförandekraft, motivation, handlingsberedskap, inräkning och kultur för att agera med flera.

Se hela kedjan

Varje gång en nytta av dataförsörjningen har uppstått har varje länk i kedjan hållit. Om en enda länk i kedjan brister blir värdet noll. Det vill säga ingen nytta, endast kostnader. Helheten är därmed viktig. Inom Data Management behöver vi se hela kedjan, hitta de svaga länkarna och stärka dessa. Vi behöver därmed satsa brett på informationsteknik och verksamhet samt människa och teknik i samverkan.

Var kommer Data Management in?

Vi kan succesivt dela in kedjan i större sträckningar, vilka var och en kan ges en rubrik. Låt oss se var vi som jobbar med Data Management kommer in.

  • Länk 1-3: Utdata till användaren
    Det är det som it- funktionen i organisationer vanligen avgränsar sin uppgift till. Man ser vanligen inte det som sin uppgift att tala om vad data betyder eller vilken kvalitet de har.
  • Länk 1-5: Informationsförsörjning
    Det bör vara vår uppgift inom Data Management att lyfta organisation och arbetssätt till att omfatta hela informationsförsörjningen. Vi informationsarkitekter kan kanske göra störst nytta då det gäller att stärka länk fyra och fem så att hela informationsförsörjningen håller.
  • Länk 1-7: Informationsförsörjning och användning
    Det bör även ingå i informationsarkitektens uppgift att bidra till att analytiska användare har verktyg för att bearbeta de data de har tillgång till. Vi behöver av många skäl samarbeta nära med den typen av användare. Inte minst för att det ger insikter i hur vi kan bidra med att få mer data och i rätt form.
  • Länk 1-9: Hela kedjan till och med att nytta uppstår
    Hur användarna av data drar slutsatser, beslutar och agerar, på basis av data, kan vi inte direkt påverka. Dock behöver vi observera och arbeta tätt ihop med de som gör det. För det ger insikter om vad vi som arbetar med informationsarkitektur eller Data Management behöver bidra med.

Hur långt sträcker sig ditt intresse?

Hur långt sträcker sig ditt intresse och engagemang? Hur ser du på din eller ditt teams roll? Vilken länk är svagast i din organisation? Kan du göra något för att stärka den?
Dina erfarenheter och tankar är välkomna.

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 15 april. Då inleder vi en liten serie i serien. Den kommer handla om hantverket informationsmodellering.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Data management

De data som en organisation äger är en värdefull resurs. Hur kan vi bygga en förmåga att ta hand om denna resurs?

Data är inte bara en bas i den dagliga operativa verksamheten, data används också för att monitorerna, analysera, styra och förbättra verksamheten. Ofta kan data ge innehåll till nya tjänster för kunder och andra intressenter. Det finns många exempel på datadrivna tjänster som skapar helt nya affärsmöjligheter.

Men precis som andra resurser behöver dataresursen tas om hand. För detta behöver vi ett strukturerat arbetssätt. Vi behöver ägarskap och förvaltningsansvar på olika ställen i organisationen. Tillika behöver vi en stödfunktion som stödjer och utvecklar arbetssättet.

Vi kan ju jämföra med hur vi gör med andra resurser. För personal har vi en personalavdelning. För ekonomiska värden har vi en ekonomiavdelning. För informationsteknik har vi en it-funktion. För varje slag av resurs har vi vanligen någon form av stödfunktion. Men var har vi den funktion som stödjer vårdandet och utvecklandet av organisationens data? Om den inte finns i vår organisation idag behöver vi på något sätt skapa den, vilket innebär att bygga kompetens, kultur och arbetssätt för data management.

Jo, men borde inte det vara it-avdelningens ansvar, kanske du invänder? Jovisst, det kan man tycka. Men det sker inte idag, i alla fall inte i de organisationer jag har insikt i. Ansvaret faller mellan stolarna. It-folket tycker att det är verksamhetens data och därmed verksamhetsfolkets ansvar. Verksamhetsfolket å sin sida har svårt att på egen hand verkligen ta hand om data på ett bra sätt.
Det är en resurs de har otillräcklig insikt i då den ligger dold för dem i databaser och flyttas runt och misshandlas i en spaghetti av integrationer.

Verksamheten har också sällan den kompetens som behövs för att hantera data. Det har visserligen inte alltid it-folket heller, annars skulle det inte se ut som det gör på många ställen idag. Men it-sidan har åtminstone de grundläggande förutsättningarna och verktygen för att ta itu med uppgiften om de bara ville ta det ansvaret.

I vilket fall som helst, var ansvaret än bör placeras, behöver vi få ett grepp om vad det innebär att ta hand om data. Först därefter kan vi bygga en förmåga för detta, med lämpliga kompetenser.

För övrigt är det hög tid att it-sidan inte ser sig som en servicebyrå till verksamheten. Man bör se sig som en lika tätt integrerad del av verksamheten som övriga stödfunktioner. Som till exempel ekonomi- eller personalavdelningarna. Men det är en annan frågeställning som vi får ta en annan gång.

Masterdata

Jag har tidigare skrivit om att det är lämpligt att skilja på masterdata, global referensdata och händelsedata, i artikeln ”Det är skillnad på data och data”. Vi vill förstås få koll på all data. Arbetssättet är ungefär lika för alla typer av data men det finns skäl att prioritera masterdata. Första skälet är att masterdata är grundläggande för övriga data. Har du inte koll på masterdata går det inte att få koll på övriga data. Har du koll på masterdata blir det relativt enkelt att få koll på resten.

Det andra skälet är att det är mer oklart var ansvaret för varje typ av masterdata ska ligga än för andra typer av data. Det är en delad resurs och är därmed utsatt för de krafter som inom ekonomi brukar kallas för ”tragedy of the commons”. Det vill säga att alla vill utnyttja det gemensamma men ingen vill ta ansvar för att vårda det.

Masterdata är vanligen kund- och produktdata, men kan också vara andra data.
Vi går i det följande igenom några masterdatadomäner.

Kunddata

Den centrala informationen om kunder är en typisk kategori av masterdata. Dit kan man räkna alla uppgifter om kunder (både privatkunder och organisationskunder) som namn, kontaktuppgifter, status med mera. Normalt omfattar det både befintliga och tidigare kunder. Ofta även prospekts, det vill säga personer eller organisationer som ännu inte är kunder men som man har valt ut som kandidater till att bli kunder.

Uppgifter om enskilda kontakttillfällen med en kund eller köptransaktioner klassas emellertid inte som masterdata eftersom det representerar händelser i tiden och därmed är händelsedata.

Alla verksamheter har eller borde ha en centraliserad hantering av kunddata. Ofta brukar det finnas i ett ERP-system eller CRM-system. Om kunddata finns spritt behöver vi ha mekanismer som håller ihop detta.

Något som vi brukar stöta på är att man saknar en tydlig livscykelmodell för kunder. När blir en kund en kund? Är det vid första köpet? Eller tidigare? När blir en kund en tidigare kund? Är en kund som inte handlat på tre år fortfarande kund? Om man inte har tydliga regler för detta går det inte att veta hur många kunder man har eller att räkna på det som kallas ”churn rate”, det vill säga kundbortfall. Sedan bör man ju också hålla reda på orsaken till att kunder slutar. Det kan vara vårt val, kundens val eller helt enkelt att kunden avlidit eller konkursat. 

De senaste årens lagstiftningar har också gjort att organisationer behöver ha bättre koll på kunduppgifter. Ett exempel är krav på skydd av personuppgifter (GDPR). Ett annat exempel är de krav finansorganisationer har på sig att ha noggrann kännedom om sina kunder för att kunna reagera på signaler om penningtvätt. 

Data om övriga intressenter

Nästan alla verksamheter behöver hålla reda på också andra intressenter än kunder. Det kan vara leverantörer, partners eller andra. Medarbetare i den egna organisationen och kontaktpersoner hos olika intressenter är också intressenter. Då behöver man bestämma sig för om man ska ha en så kallad intressentmodell (party model), det vill säga att man har entiteter som representerar alla organisationer och personer man behöver hålla reda på oavsett roll dessa har till ens verksamhet. Där finns de uppgifter som inte har med den specifika rollen att göra, som organisationsnummer och namn och typ av organisation.

Därutöver behöver man separata rollspecifika entiteter för varje roll i förhållande till vår verksamhet som intressenten har. En och samma organisation kan ju vara både kund och leverantör. En och samma person kan på samma gång vara kund, representant för ett kundföretag eller anställd hos oss. Dessa rollspecifika entiteter rymmer det som har att göra med just den specifika relationen.

En intressentmodell behöver man i de fall då det är viktigt att ha en direkt överblick över vilka roller en och samma part har i förhållande till oss. Det brukar vara fallet i sammanhang där man behöver ha direkt koll på dubbla roller hos sina intressenter, som fallet ofta är i finansiella verksamheter. För andra verksamheter är en intressentmodell ofta overkill.

Produkter

De flesta verksamheter har produkter eller tjänster av något slag som man erbjuder omvärlden. Ofta går tjänster under namnet produkter, och ur informationssynpunkt är det ingen större skillnad. Så även jag kallar här tjänster för produkter.

Ofta har man en hel flora av produkter och ofta har man oordning i namngivning, klassificering, livscykelhantering med mera. Ofta har man inte definierade begrepp för ”produkt”, ”produktvariant”, ”produktversion”, ”produktkomponent”, ”produktlivscykel”, ”produktgrupp”, ”produkttyp”, ”produktindivid”, ”produktstatus”, ”externt namn”, ”internt namn”, ”leverantörens produktnamn” med mera. Det här är viktigt att reda ut, liksom regler för namngivning.

Om man utvecklar en befintlig produkt är resultatet att betrakta som en ny produkt eller är det en ny variant av en den befintliga produkten? Vad är det som kännetecknar en produkt, till skillnad från en variant på en produkt? Och det här som vi säljer, är det en produkt som består av ett antal komponenter, eller är det en paketering av flera produkter? Allt detta måste redas ut och standardiseras om man ska få ordning på en produktflora.

Tillverkare och försäljare av fysiska produkter har ofta behov av omfattande data om sina produkter, baserat på olika branschspecifika regelverk. Det kan vara dokumentation av olika slag som materialdata, testdata med mera.

Data management öppnar för mer än management av data

Det är lätt att inse att det inte går att isolera uppgiften att ta hand om data från att fånga, formulera, dokumentera begrepp och terminologi liksom verksamhetslogik. Vanligen blir det även påkallat att driva arbetet att inte bara dokumentera utan även utforma och standardisera begrepp, benämningar och verksamhetslogik. Detta är något bra. En informationsmodell och arbetet med den är, om det görs på ett bra sätt, en utmärkt plattform för det.

Roadmap för data management

Hur kan man då ta sig an jobbet att bygga upp data management i en organisation? Så här brukar vi gå till väga i de sammanhang jag jobbat i:

1. Kartlägg verksamhets- och systemlandskapet

Vi skapar en gemensam karta av vilka funktioner verksamheten består av och hur de samverkar med varandra och med omgivningen. Vi ritar in applikationer och hur de är integrerade så att vi får en karta som visar hur applikationer och dataströmmar är djupt integrerade delar av verksamheten. Vi gör detta genom en serie mindre arbetsmöten med verksamhets- och it-specialister. Kartan behöver vi för att förankra och ge kontext till alla övriga dialoger och modeller.

Det här är ett arbete som brukar gå förvånansvärt fort. På ett medelstort företag tar det kanske två till tre arbetsveckor att få fram en karta som är tillräcklig för att gå vidare med. Men naturligtvis kommer den att fortsätta förfinas under resans gång.

Resultatet brukar bli att verksamhet och it för första gången ser en ritning över hur verksamheten hänger ihop i alla sina delar, och får en gemensam spelplan för den dialog som behövs för all gemensam utveckling av it och verksamhet. Vilket är grundläggande, inte bara för data management, utan för all verksamhets- och it-utveckling.

2. Kartlägg datastrukturerna

Vi gör en eller flera detaljerade informationsmodeller för att förstå vilka företeelser som hanteras, deras egenskaper och hur de representeras i data.

Det här är inget annat än informationsmodellering, fast mer detaljerat och noggrant än vad som är vanligt. Arbetet går vanligen fort om man har tillgång till material och kunskap från it-kunniga. Säg att det tar återigen i storleksordningen två till tre arbetsveckor att få fram en tillräckligt säker modell för att kunna gå vidare. Arbetet kan göras delvis parallellt med steg 1 ovan. Modellen kommer naturligtvis att uppdateras efter hand ju mer vi lär oss. Arbetssättet består i koncentrerade mindre möten med kunniga personer, kombinerat med egen genomgång av databas- och filbeskrivningar.

Modellerna ger oss en tänkt bild, en hypotes, om hur det ser ut men ännu har vi egentligen inte studerat verkligheten närmare, det vill säga data i sig. När vi verkligen dyker ner i data upptäcker vi saker som gör att vi får ändra i modellerna.

3. Prioritera datadomän

Vi väljer ut en viss datadomän att fokusera på. Normalt är det en masterdatadomän, vanligen kund- eller produktdata. Ofta är kriteriet det som känns mest akut, men egentligen borde man kanske också väga in var man enklast kan få tidig nytta. Normalt är det redan bestämt eftersom själva orsaken till att vi blev inkallade berodde på ett visst problem man känt av. Men det händer ändå ganska ofta att vi ser att det finns ett mer akut behov eller en mer grundläggande datadomän, så att vi gärna vill styra om ordningen.

4. Kartlägg data

Vi går metodiskt igenom all data för den utvalda domänen i de centrala databaserna, samt hur de hanteras i integrationer. Resultatet blir en rapport över hur tillståndet är för datadomänen.

Detta moment kan ta längre tid. Det är ett ganska mekaniskt, rakt och enkelt arbete, men det tar tid att verkligen traska igenom stora datamängder ur alla möjliga aspekter. Men låt mig säga att det tar i storleksordningen fem arbetsveckor. Arbetssättet är en genomgång av data i databaser med enkla verktyg som SQL eller liknande.

5. Kartlägg produktion och användning av data

Vi kartlägger hur och var data skapas, hur de transporteras, och hur det används. Ofta får vi gå vidare till externa leverantörer av data, ibland leverantörens leverantör. Likaså får vi ofta söka upp externa konsumenter av data. Vi får en bild av vilka behov som finns, hur de tillgodoses, vilka verkliga brister som finns i praktiken och hur dessa uppstår. Vi intervjuar då de som känner till integrationerna och de som har kunskap om de olika applikationerna och hur de används. Det kan ta från ett par arbetsveckor beroende på hur stort ekosystemet visar sig vara.

Det är först nu vi har en tillräckligt tydlig problembild för att veta vad som behövs göras. Tills nu har det handlat om kunskapsinsamling.

6. Planera åtgärder

Nu har vi en klar bild av var och hur problemen känns av och var de uppstår. Då är det lämpligt att sätta samman en åtgärdsplan. Av nödvändighet är den endast preliminär. Ju längre vi kommer i arbetet desto tydligare blir det vad vi behöver göra.

7. Bygg organisation och arbetssätt och sätt igång

Vi bygger en rudimentär organisation för data management av den aktuella datadomänen och sätter igång med de åtgärder som prioriterats. Det handlar om en rad åtgärder, från rent tekniska till förändrade beteenden i verksamheten. Både engångsåtgärder för att åtgärda brister och nya rutiner för att förebygga nya brister.

Det här arbetet tar egentligen aldrig slut utan fortsätter som ett lågintensivt arbete för alltid. En datadomän behöver alltid vårdas mer eller mindre kontinuerligt. Så det här är mer en första enkel och prövande uppstart av en förmåga i organisationen.

När vi har fått rull på den första datadomänen sätter vi igång med nästa. Nu har jag beskrivit arbetet övergripande men mycket mer finns förstås att säga om varje steg. Jag planerar att beskriva varje steg mer i detalj, i olika artiklar, framöver.

Men viktigt att påpeka redan nu är att inget av arbetet handlar i grunden om teknik. Tvärtom vad många system- och konsultleverantörer påstår finns det inga speciella systemplattformar som gör jobbet och det är sällan andra verktyg än de enklaste är till hjälp. Det säljs speciella masterdatasystem, men enligt vår erfarenhet skymmer de uppgiften i stället för att hjälpa.

Och tvärt om en vanlig uppfattning behöver inte en masterdata-satsning vara stor, dyr och konsultintensiv. I själva verket motverkar det syftet. Det handlar om ett uthålligt lågintensivt agilt arbete, en mognadsprocess, en resa där vi tillsammans utforskar våra data och vår gemensamma förståelse för vad de representerar och steg för steg bygger ett sätt att bättre ta hand om data. 

Invändning 1: Bör man inte ta fram problembilden först?

Jag tror att man kan invända följande: Bör man inte först och främst ta reda på vad problemen är, innan man sätter igång? Mitt svar blir att det är sällan de i organisationen har en tydlig överblick över sin dataresurs. Olika personer upplever problem i olika situationer men de är inte på det klara med hur orsakssambanden ser ut. Det krävs en kartläggning. Och det är vad vi gör i steg 1 till 5. Det är först när vi vet hur saker hänger ihop som vi lite mer utförligt kan intervjua olika nyckelpersoner och representanter för användare. Det är först då vi kan ställa rätt frågor, förstå svaren, samt sätta samman och presentera en tydlig gemensam problembild. Och det är faktiskt sällan som den första beskrivningen är speciellt intressant.

Det är som att gå till läkaren. Jag har ett symptom jag söker för. Läkaren börjar med att skicka mig till blodprov, sedan röntgen av lungor och hjärta, ultraljud av levern och så vidare. Vid återbesöket får jag veta att jag har begynnande diabetes, högt blodtryck och dåliga levervärden. Läkaren sätter utifrån dessa resultat samman en åtgärdsplan i dialog med mig.

Det jag sökte för var endast ett symptom, den ytliga signalen på att allt inte var bra. Den verkliga problembilden behövde vi komma fram till tillsammans. Läkaren ställde inte direkt en diagnos utifrån mitt symptom, utan skapade sig först en helhetsbild genom de olika testerna för att kunna ge rätt hjälp. Det är alltså inte så att hon bara frågar om det jag söker för och fixar det.

På samma sätt är det med en dataresurs. En stor del av arbetet handlar om att ta reda på hur saker och ting hänger ihop, vad de olika aktörerna behöver och har respektive inte har idag, och hur de olika orsakskedjorna hänger ihop. Att åtgärda handlar sedan om ett uthålligt arbete.

Invändning 2: Bör man inte bygga organisation först?

Vi behöver bygga en central stödfunktion och vi behöver bygga roller och arbetssätt i olika delar av organisationen. Ska vi inte börja med det och först därefter sätta igång? Det är en vanlig uppfattning, men min erfarenhet är att det inte fungerar. Kultur, arbetssätt och roller behöver mogna fram. Det behöver få ta tid. Det är en dålig idé att stressa fram detta. Det som fungerar är att börja med enklast möjliga process och organisation och låta det hela växa fram efter hand. Den kände dataspecialisten Bob Seiner kallar den hållningen för ”Non-invasive Data Management”. Och visst borde egentligen all verksamhetsutveckling vara icke-invasiv! Det vill säga att coacha individer och team så att arbetssätt får mogna fram på individerna och teamens egna villkor.

Invändning 3: Varför smådutta? Vi behöver en större transformation, och det genast!

Jag tycker att vid det här laget borde vi ha lärt oss att stora projekt är en dålig idé. Många små steg betyder inte att verksamhetsutvecklingen går långsammare. Det gör att förändringen över huvud taget fungerar och att förändringen går precis så fort som är möjligt. Vilket ofta är överraskande snabbt. Och att det blir bra.

Vi ser fram mot din syn på data management. Kommentera gärna!

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 11 mars under rubriken ”En informationsmodell istället för flera”. Peter Tallungs visar hur vi kan kombinera flera perspektiv i en och samma modell  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Det är skillnad på data och data

När vi ska bygga upp Data Management i en verksamhet, det vill säga verksamhetens förmåga att vårda och utveckla sin dataresurs, behöver vi en grundläggande indelning av data i kategorier. Ty olika kategorier av data behöver lite olika ansatser.

Det är praktiskt att dela in data i olika kategorier. Man stöter också på många olika indelningssätt i litteraturen. Varje sätt har sina styrkor och svagheter och passar därmed sina speciella syften.

Säg att vi ska bygga upp någon form av Data Management, det vill säga förmågan att vårda och utveckla vår organisations data som en värdefull resurs. Då finns det en grundläggande och praktisk indelning som jag tror är allmänt accepterad och som visat sig användbar tvärs över alla verksamheter.

Det är en grov indelning av verksamhetsdata i tre kategorier som skiljer sig åt beträffande vilka typiska problemställningar respektive kategori är förknippad med då det kommer till att ta hand om dataresursen. Därmed behöver varje kategori av data hanteras på lite olika sätt och med olika prioritet. Det som i grunden skiljer kategorierna i det avseendet är vilken livscykel verksamhetobjekten (som data i fråga representerar) har, i vilken mån data i den kategorin refereras eller uppdateras från olika funktioner i verksamheten samt i vilken grad dessa data har ett naturligt ägarskap.

De tre kategorierna är masterdata, globala referensdata och händelsedata. Dessa kommer jag nu gå igenom och ge exempel på.

Masterdata

Masterdata är vanligen kund- och produktdata, men kan också vara andra data. Det är data som uppfyller följande kriterier:

  1. Representerar centrala verksamhetsobjekt som har en livscykel över tid.
    Exempel: En och samma kund finns i vår verksamhet över en längre tid och kan ändra adress, status och till och med namn och andra uppgifter under sin livstid som kund och ändå ha kvar samma identitet. Ett annat exempel: En och samma produkt lever över en längre tid trots att den kan ändra status och andra egenskaper under sin livstid.
    Observera att det här inte handlar om hur länge man behöver spara data över tid, utan bara om hur länge verksamhetsobjektet har en aktualitet. 
  2. Refereras av många andra dataobjekt, särskilt händelseobjekt, och bildar därmed en bas för övriga data.
    Exempel: Kunder refereras av offerter och transaktioner, produkter likaså. Man kan säga att de verksamhetsobjekt som representeras av masterdata är centrala för verksamheten i det att de är mer eller mindre beständiga och refereras från många håll. Data som representerar dessa fungerar därmed som en slags bas och ankare i dataresursen. 
  3. Saknar ofta naturligt ägarskap. Många behöver kund- och produktdata men det är oklart vem som ska vara ansvarig för dessa. Masterdata är i likhet med gemensamma tillgångar i övrigt utsatt för det ekonomisk-sociala fenomen som kallas ”tragedy of the commons”: Hur en gemensam resurs riskerar att misshushållas, då ingen känner ansvar.
  4. Uppdateras ofta från olika verksamhetsfunktioner. Till exempel kan både sälj och marknad registrera nya kunder. Ofta har man ännu helt separat hantering av olika säljkanaler vilket betyder att online-kunder läggs upp helt separat. Eller så har man slagit ihop två verksamheter med överlappande kundregister. Adresser behöver kanske uppdateras både från offentliga källor och av kunden själv, via kundtjänst eller självbetjäning. Allt detta skapar typiska masterdataproblem som vi behöver hantera.

Globala referensdata

Referensdata är data som är till för att vara värdeförråd för egenskaper hos andra dataobjekt, det vill säga uppräkningar av giltiga värden. Det kan till exempel vara listan med Sveriges postnummer, alla produkttyper vi har, SNI-koder (Svensk Näringslivsindelning), länder i världen etcetera.

Kanske känns referensdata bäst igen som ”koder”, men en kod är egentligen endast ett av attributen för en förekomst av referensdata.

Vi inkluderar här inte lokala referensdata, till exempel de olika kundstatuskoder som finns ifall de endast används som värdeförråd för attributet kundstatus för kund. Skälet är att lokal referensdata har en naturlig hemvist. Ansvaret för vilka kundstatuskoder som finns hänger naturligt samman med ansvaret för kunddata. Det ingår i beskrivning av attributet kundstatus.

Referensdata har likt masterdata en livscykel. En statuskod kan till exempel ändra namn, börja vara giltig vid en tidpunkt eller upphöra vid en annan.

Globala referensdata har ofta inte ett naturligt ägarskap. Postnummer har visserligen en naturlig källa, Sveriges postnummerregister, men man behöver ändå se till att någon tar ansvaret för att tillhandahålla, tillgängliggöra och uppdatera listan internt i organisationen.

Referensdata representerar inte några egentliga verksamhetsobjekt i kontext av den aktuella verksamheten, utan varje entitet representerar bara en lista av giltiga värden för en viss egenskap hos ett eller flera verksamhetsobjekt.

Speciellt för referensdata är att de har en typisk uppsättning attribut som gäller för de flesta fall. Oftast ser man bara kod och namn, men en bruttolista över möjliga attribut borde kanske se ut enligt nedan. Detta gäller för alla referensdata, både globala och lokala.

Attribut för referensdata – bruttolista

AttributBeskrivning
KodKod eller id. Kan också fungera som kortnamn.
NamnFullständigt namn.
KortnamnEtt kortare namn för användning i de fall hela namnet inte får plats i något sammanhang, som till exempel i en valbar lista i ett användargränssnitt eller i en kolumnrubrik i en rapport.
DefinitionDefinition av värdet. Viktigt, men glöms ofta bort. Bör finnas med i informationsmodellen, och också vara tillgänglig i användargränssnitt.
BeskrivningBeskrivning utöver definition, i de fall det behövs.
NoteringEventuella noteringar i övrigt.
SorteringsordningEn siffra som anger i vilken ordning värdet ska listas, i en valbar lista eller dylikt, för det fall att sorteringsordningen inte ska vara alfabetisk. Glöms ofta bort, men behövs för att värdena ska listas i en naturlig ordning och på samma sätt överallt där de visas.
Gäller från och med – datumFör de fall att listan med giltiga värden ändras.
Gäller till och med – datumFör de fall att listan med giltiga värden ändras.

Händelsedata

Data som inte är masterdata eller referensdata avser vanligen något som är en händelse i tiden, som en transaktion av något slag, till exempel ett köp eller en order. Hit kan man också hänföra sådant som en offert eller faktura. De har kanske en viss giltighet över tid, men ändrar aldrig någon egenskap utöver status.

Händelsedata har därmed till skillnad mot masterdata och referensdata ingen längre livscykel. De är att betrakta som ett snapshot i tiden och kan därmed aldrig ändras, utöver möjligen sin status. Dessutom hör händelser tydligt hemma i speciella verksamhetsfunktioner, då de inträffar i ett speciellt sammanhang. Därmed är de inte på samma sätt en delad resurs som masterdata och globala referensdata. Sist men inte minst viktigt, om du har fått ordning på masterdata och globala referensdata har du en fast grund att stå på. Allt detta talar för att händelsedata blir smidigare att hantera.

Viktigt att veta är att det som i en verksamhet har kort livslängd och därmed kan klassas som händelsedata kan i en annan verksamhet ha en beständighet och därmed behöva klassas som masterdata. Ett exempel kan vara avtal. I en verksamhet kan ett avtal gälla för endast en leverans och därmed snabbt vara överspelat. I en annan verksamhet löper avtal över lång tid och används för många leveranser. I det första fallet är det händelsedata, och i det andra fallet masterdata.

Jämförelse mellan kategorierna av data

Vi kan nu jämföra de tre kategorierna av data beträffande de faktorer som bör påverkar i vilken ordning vi bör adressera att ta hand om dataresursen. De fyra faktorer som jag kan se redovisas i tabellen nedan.

Vilka faktorer som påverkar prioriteringen för Data management för en datatyp

PåverkansfaktorMasterdataGlobal referensdataHändelsedata
Lever över tidJaJaNej
Refereras från många ställenJaJaNej
Saknar ofta naturligt sällskapJaJaNej
Uppdateras ofta från flera ställenJaNejNej

Syftet med indelningen

Varför är det bra att dela in data på detta vis? Jo, om vi verkligen ska ta hand om våra datamängder så ställer de här kategorierna olika krav på oss som verksamhetsförmåga. Masterdata och global referensdata utgör grunden och själva förankringen för all data. Det vill säga all övriga data är beroende av masterdata och global referensdata. Därför behöver vi först få ordning just där. Har vi gjort det så faller det övriga på plats ganska naturligt. Att däremot börja med händelsedata när vi har en skakig grund i till exempel kund- och produktdata är ogörligt.    

Jag brukar jämföra det med strategin för att röja hemma i villan. Om man först skapar ordning i förvaringsutrymmena, det vill säga på vinden, i källaren och i garaget, så blir det mycket lättare att ordna upp i resten av huset. Tvärt om är ingen bra idé.

Masterdata kommer som sagt först i prioritet, tillsammans med global referensdata. Händelsedata kommer naturligt senare i prioritet.

Detta är förstås en förenkling. Det kan finnas annat som gör att man behöver prioritera annorlunda. Men då blir det kanske till ett pris. Utan en fast grund är det svårt att göra någonting bra.

Data management

Vi bör givetvis ta hand om all data. De olika kategorierna av data har mer gemensamt än som skiljer i detta avseende. Men masterdata har ändå en nyckelroll i detta arbete. Därför brukar man se masterdatahantering som ett eget område. Globala referensdata har i viss mån liknande problem men är vanligen lättare att komma till rätta med.

Vi ska i nästa artikel titta på vad Data Management handlar om.

Till dess, vad anser du om indelningen som jag beskriver här? Har du en annan syn? Eller bättre beskrivning av respektive kategori?

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 4 mars. Peter Tallungs tittar närmare på vad Data management handlar om och ställer frågan: Hur kan vi bygga en förmåga att ta hand om den resurs som vårt data är?  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.