Data management

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?

/Peter Tallungs, IRM, 2021-03-04

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:

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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