12 steg för att bygga data management

Alla vill ha koll på sina data – men få vet hur. Genvägar funkar inte. Ska du bygga en data management-förmåga krävs ett inkrementellt, iterativt och lärande angreppssätt.
Så här gör du.

/Peter Tallungs, IRM, 2025-03-13

Behov av välordnat data

Allt fler företag och organisationer inser att de måste få bättre koll på sina data. Det är flera faktorer som driver den insikten. För att nämna några; nya regulatoriska krav, nya affärsmöjligheter och nya möjligheter med artificiell intelligens. Gemensamt för dem alla är att de kräver välordnade data.

Men behovet har inte uppstått först nu, det har funnits där hela tiden. Vi har alltid behövt vårda och utveckla data som en värdefull resurs. Det är heller inte något helt nytt att behovet ökar. Behovet har växt fram under lång tid. I decennier har trender som it-integration, digital ekonomi med API-er, Internet of Things och Business Intelligence ställt krav på en effektiv hantering av data.

Läget idag: Medvetenheten har ökat – men inte kunskapen

Många har börjat förstå att data är viktigt. Men förståelsen om vad som krävs för en bra datahantering har inte mognat i samma takt utan är fortsatt låg, både bland it-konsulter och kunder. Den enda skillnaden mot tidigare är just att medvetenheten har ökat. Vi såg den trenden att intresset ökade, först sakta runt år 2010, sedan lite snabbare, för att nu börja rusa i höjden.

Idag finns en diskrepans mellan, å ena sidan, vad man behöver och vill, och å andra sidan, vad man faktiskt kan. Det akuta behovet, i kombination med bristande kunskap och förmåga, gör att företags- och IT-ledningar famlar efter snabba lösningar – lösningar som inte existerar. Istället riskerar de att falla i fallgropar som slukar tid och resurser, vilket i sin tur förvärrar problemen.

Dags för en riktig dialog

Därför är det viktigt idag att vi får till en dialog om hur man kan gå till väga för att bygga upp data management-förmågan i sin verksamhet. En ärlig dialog baserad på verklig kunskap och erfarenhet.

Bara så kan vi bli bättre. Som individer, som team, som organisationer, som bransch, som land.

Här är mitt bidrag. Det handlar om grundläggande tänkesätt, men det handlar också om konkret handling.

Strategi: Fem grundläggande råd

Vad ska man tänka på för att lyckas? Här är det viktigaste enligt mig:

Råd 1: Arbeta långsiktigt

Att få koll på organisationens datahantering handlar inte om ett enstaka projekt. Det är inget ”one-night stand” vi ska få till. Vi behöver bygga en ny verksamhetsförmåga – med allt vad det innebär av kultur, kunskap och arbetssätt.

Det betyder inte att saker och ting behöver dras i långbänk och gå i snigelfart. Det betyder att vi behöver arbeta genomtänkt och långsiktigt.

Det går att kombinera långsiktigt tänkande med att komma i gång snabbt. Vi kan få nytta redan från början. Och det med små resurser.

Råd 2: Bygg ett utforskande arbetssätt

Det är en dålig idé att forcera, att slänga in ett stort antal personer. Det går inte fortare, tvärtom!

Satsa i stället på ett mindre men spetsigt team som först koncentrerar sig på ett avgränsat dataområde, och lär sig längs vägen. Först när ni har ordentlig koll på detta första dataområde kan ni ta er an nästa.

Råd 3: Fall inte för teknikleverantörernas löften

Att bygga upp en förmåga i en verksamhet är inte ett tekniskt problem och har därmed inte en teknisk lösning. Lyssna inte på leverantörernas löften om tekniska lösningar som gör jobbet. Teknik kan vara till stöd, men kan inte ta huvudrollen. Och först när man vet vad som verkligen behövs.

Råd 4: Fall inte för löften om snabba lösningar

Det finns inget konsultbolag som kan göra jobbet åt er. Punkt.

Ni kan få råd, hjälp och stöttning av erfarna konsulter, men ni måste själva vara aktiva i arbetet. Det handlar om att bygga upp en egen förmåga som ska finnas där, fungera och vidareutvecklas framöver.

Råd 5: Bygg utifrån vad som redan finns

I varje organisation finns det alltid en eller flera eldsjälar som brytt sig om begrepp och datakvalitet – måhända informellt, ofullständigt och utan adekvat stöd. Var inte för ivrig så ni kör över dessa. En organisationsutveckling, som ju detta är, bör alltid bygga vidare på som redan finns. Börja där. Annars blir det bara tomma ord.

Filosofi: Lär från andra områden

Att utveckla en välordnad, effektiv och hållbar data management-förmåga är för de flesta att göra något nytt, som få har erfarenhet av. Och när vi gör något nytt är det värdefullt att inspireras av hur vi tidigare har löst liknande problem i våra organisationer.

Så vad handlar det här egentligen om?

Data är en gemensam resurs som vi behöver hantera. Hur har vi gjort med gemensamma resurser av andra slag? Varje organisation har ju redan utvecklat förmågor för att hantera olika slags resurser. Frågan är: kan vi hitta generella mönster som vi kan lära oss av? Det finns saker som går igen tvärs över områden.

Ett sådant mönster är att varje sådan förmåga en organisation behöver för att hantera en gemensam resurs kräver två parallella strukturer:

1. Ett utspritt ansvar i olika delar av organisationen,
2. En central stödfunktion för allt det som är ett gemensamt behov.

Det här mönstret går igen i flera områden.

Exempel 1: Ekonomi

För att sköta ekonomin krävs två saker:

• Utspritt ansvar: Varje kostnads-och intäktsansvarig hanterar sin del av ekonomin.
• Central stödfunktion: Ekonomifunktionen ger stöd och säkerställer enhetlighet.

Exempel 2: Personal

För att hantera personal krävs samma upplägg:

• Utspritt ansvar: Varje chef har ansvar för sina anställda.
• Central stödfunktion: HR-funktionen hanterar övergripande stöd och riktlinjer.

Samma princip gäller för data

Det finns ingen anledning att tro att data management skulle vara annorlunda.
För att ta hand om data som en gemensam resurs behöver vi även här två parallella strukturer.

• Utspritt ansvar: Dataägare (Data Owners) och vanligen också dataförvaltare (Data Stewards).
  Dessa roller är vanligen som till-lika-befattningar, det vill säga något man gör utöver sitt vanliga arbete.
• Central stödfunktion. En kärngrupp (kernel team) som hanterar allt det som är ett gemensamt behov.

Vi kan alltså se de utspridda rollerna som ett ”extended team” och den centrala stödfunktionen som ett ”kernel team”.

Samma problem, samma lösning. Det handlar bara om att applicera rätt tänk på ett nytt område.

Taktik 1: Börja med den centrala stödfunktionen

I vilken ände ska vi då börja för att bygga upp en fungerande data management-förmåga?

Ska vi börja med att utse dataägare och dataförvaltare och sätta dem arbete? Så gör många. Det är ingen bra idé menar jag.

Hur ska de förstå och hantera sin uppgift, utan hjälp i form av en central stödfunktion och utan att vi först har skapat någon slags grundläggande ordning i data?

Det är att skyffla över ansvar på personer utan att ge dem förutsättningarna. Det är att sopa problemet under mattan, så att det blir ett ”blame game” i stället för att bygga en förmåga på riktigt.

Bör vi i stället bygga upp central datahanteringsfunktion utan att vi ännu etablera ett formellt dataägarskap? Det kan kännas som en bakvänd ordning, men min erfarenhet är att det är rätt väg att gå.

När vi har gjort detta i olika organisationer har vi börjat med ett litet men spetsigt team och ett avgränsat dataområde och byggt kultur och arbetssätt efter hand. För att först senare, då vi fått till en fungerande stödstruktur, identifierat och formellt utnämnt lämpliga dataägare och dataförvaltare i verksamheten. Vi har tydligt kommunicerat att vi tagit tillfälligt ägarskap tills vidare och är transparenta med allt vi gör.

Först då vi fått ordning på ett dataområde har vi gått vidare till nästa.

Det är alltid bra att låta saker mogna fram i naturlig takt, speciellt när det är något nytt och okänt.

Ett vanligt argument emot detta är att det skulle vara för långsamt. Vilket är en missuppfattning. Det kan gå snabbt, särskilt då man blivit varm i kläderna och fått till ett arbetssätt som fungerar.

Att bara utnämna personer utan stöd och struktur kan kännas snabbt – men innebär egentligen inte att man verkligen byggt upp en fungerande förmåga.

Taktik 2: Ett område i taget

Som redan nämnts är det lämpligt att välja ut ett dataområde (data domain) att börja med, och göra mer eller mindre klart innan man går till nästa. På så sätt vinner man erfarenhet och får tydlig återkoppling på vad som fungerar. Det handlar ju om lärande, att utveckla arbetssätt som fungerar. ”Learning by doing”. Det handlar inte bara om att få koll på data i sig utan viktigast är att utveckla och etablera arbetssätt, det vill säga hela förmågan att ta hand om data.

Vilket dataområde ska man då börja med? Det bör vara någon slags masterdata, eftersom masterdata är en grund för (det vill säga refereras från) så mycket andra data. I många verksamheter är kunddata, produktdata eller anläggningsdata exempel på masterdata.

Vi behöver ha ett litet och kompetent team som tar itu med detta – att bygga upp arbetssätt för att ta hand om verksamhetens data inom området. Teamet behöver ha en eller flera informationsarkitekter till att börja med, eftersom det speciellt i början handlar om att kartlägga och modellera. Man kan sedan bygga ut teamet med fler roller efter hand.

Poängen? Gör det litet, gör det smart, gör det rätt – och skala upp när ni vet vad som funkar.

Process: Tolv steg

Hur kan då gången se ut för att bygga upp arbetssätt för att hantera ett första dataområde?

I de organisationer jag och mina kollegor fått förtroendet att medverka har följande process visat sig fungera. Processen beskrivs här som en sekvens av steg, fast, i likhet med allt annat utvecklingsarbete, handlar det mer om faser än steg. Fokus flyttas efter hand mellan olika arbeten, men det sker hela tiden iterationer, de vill säga nya insikter ger omtag med tidigare steg.

Låt oss för exemplets skull säga att vi väljer att börja med kunddata som första område att ta oss an.

Steg 1: Ta fram en verksamhetskarta

Som en grund behöver vi förstå och skapa oss en gemensam bild av hur verksamheten är uppbyggd och hänger ihop. Verksamhetskartan visar vilka funktioner verksamheten består av och hur de är belägna beroendemässigt i förhållande till varandra.

Kartan ger en gemensam överblick över verksamhetens operativa struktur i alla sina delar. Den behövs för två ändamål. Dels ge en kontext och orientering för alla dialoger framöver: exakt var är vi nu i verksamheten, hur förhåller sig denna komponent (funktion, it-applikation, roll) till alla andra komponenter.

Det andra ändamålet är för att längre fram i arbetet mappa in datalogistiken för, i detta fall, kunddata.

Vissa funktioner betjänar kunder direkt. Andra står mera för de centrala funktionerna och återigen andra är stödfunktioner. För varje funktion visar kartan vilka it-applikationer, tjänster och roller funktionen består av. Framför allt visar den hur olika funktioner och it-applikationer och roller samverkar, både med varandra och med omgivningen, via verksamhetstjänster.

Som jag beskrivit i andra artiklar är det lämpligt att tillämpa ”arkeologi”, det vill säga utgå från beskrivningar av it-landskapet för att ur detta ”re-engineera” verksamhetslandskapet.

Denna första version av verksamhetskartan är lämpligen koncentrerad på de delar av verksamhet och omgivning som levererar, hanterar eller brukar kunddata i någon form. Övriga delar är kanske mer skissade än så länge.

Steg 2: Ta fram en gemensam informationsmodell för kunddata

Även här är ”arkeologi” en snabb och enkel ansats. Utgå från datastrukturerna i centrala databaser och filer, analysera fram en modell som i grunden blir konceptuell men som ändå behåller kopplingar till centrala fysiska datastrukturer.

Modellen blir på så sätt det gemensamma språket och förståelsen av inte bara kunddata utan även (viktigt) alla begrepp, regler och benämningar om och runt alla kundbegrepp.

Den gemensamma informationsmodellen är nu endast en första ansats. Den kommer, i likhet med verksamhetskartan, att utvecklas och förfinas under arbetets gång.

Steg 3: Bygg skyltfönster

Det vi bygger är en central stödfunktion, och en sådan är som en egen liten verksamhet som erbjuder tjänster till ”kunder” i resten av organisationen. För att lyckas behöver vi tydligt visa vad vi gör och kan bidra med. Det innebär många saker som intern marknadsföring, försäljning och leverans.

Den funktion vi bygger får inte bli ett elfenbenstorn, utan vi måste arbeta nära många individer och team inom verksamhet och it.

En bas för detta är någon form av intranätplats eller wiki. Där kan vi presentera oss och komma åt och ladda ner de senaste versionerna av de modeller vi tar fram. Efter hand bygger vi ut med fler funktioner.

Observera att detta skyltfönster inte är samma sak som det bibliotek eller arkiv där vi förvarar och hanterar modellerna. Ett sådant strukturerat arkiv behövs också i bakgrunden för en effektiv modellhantering.

Steg 4: Bygg kommunikation med olika delar av organisationen

Vi behöver också kommunicera brett med de som är våra ”kunder” och ”partners”, det vill säga olika intressenter i organisationen som behöver våra tjänster.

Det är lämpligt att fortsätta bygga vår intranätssida eller wiki som bas för detta. Där kan vi lägga upp mer eller mindre statisk information som att vi finns, vilka vi är, vad vi gör, kontaktuppgifter med mera. Samt vilka tjänster vi kan tillhandahålla som att hjälpa till med modellering, handledning med mera.

Men vi behöver även berätta vad vi gör löpande, frågeställningar, framsteg i arbetet, förändringar i modeller med mera. Som sagt är intranätssidan basen i vår kommunikationsplan, men vi behöver också blogga samt ge oss ut och presentera vad vi gör i olika sammanhang. Ofta har vi också haft någon form av push-tjänst så man kan prenumerera på notifieringar då det hänt något.

Särskilt viktiga intressenter och partners är BI-team och BI-användare som analytiker av olika slag, som vanligen har mer kunskap om data och mer ingående krav.

Steg 5: Kartlägg kunddata i detalj

Informationsmodellen visar vilka slags data som finns, men säger inget om dataförekomsterna i sig. Vi behöver veta vilka data som verkligen finns. Det gör vi genom att i detalj gå igenom och kartlägga innehållet i tabeller och filer, både poster som helhet och innehållet i varje attribut (fält eller kolumn).

Det är dels en inventering av vilka brister i data vi har, vilket ger en grund för det kommande datakvalitetsarbetet. Men det ger dessutom en djupare förståelse för vilka data som finns och vad de representerar, vilket ofta ger anledning till att förfina informationsmodellen.

Steg 6: Kartlägg datalogistiken för kunddata

Vi behöver få en fullständig bild av hur, var, när och av vem kunddata skapas, transporteras, transformeras och används. Detta brukar kallas ”data linage” det vill säga datahärkomst.

Historiskt har man skiljt mellan ”business linage”, som har att göra med datas väg genom organisationer, verksamhetsfunktioner och roller, och ”technical linage”, som har att göra med dataflöden inom it-system och systemintegrationer av olika slag.

Men eftersom vi använder oss av verksamhetskartan som ser it-landskapet som en integrerad del av verksamhetslandskapet blir dessa två typer av ”linage” sammanvävda till en och samma vy.

Steg 7: Kartlägg och bygg relationer med personer i roller runt kunddata

För att kunna hantera kunddata behöver vi bygga relationer och ha ett regelbundet samarbete med representanter för de personer och team, både i och utanför organisationen, som på olika sätt har roller runt kunddata. Det vill säga som skapar, transporterar, transformerar och (inte minst) använder kunddata. Det gäller både olika användarroller och it-roller, såsom systemansvariga med flera, samt även ledningsroller som till exempel ansvarig för informationssäkerhet.

Steg 8: Kartlägg användning, upplevda brister och behov hos användare av och andra intressenter till kunddata

Vi behöver nu mer i detalj intervjua användare och andra intressenter och kartlägga hur kunddata används, vilka brister man upplever och vilka behov man har nu och framöver.

Vi intervjuar olika intressenter och kartlägger behov, både behov som uppfylls idag och de som inte är uppfyllda, samt upplevda brister.

Steg 9: Ta fram plan för hantering av kunddata

Nu vet vi vilka behov och brister som finns, vad som är prioriterat att åtgärda och kan ta fram en plan för det fortsatta arbetet.

Det handlar inte bara om att rätta fel i data, utan också att vidta åtgärder för att felen inte ska uppstå igen. Det handlar också om att tillgodose behov som vi ser och som inte är lösta idag. Det kan innebära nya tekniska lösningar, nya eller förändrade dataintegrationer.

Steg 10: Åtgärda fel och brister i befintliga data

Vi kan nu enligt plan rätta felaktigt data och åtgärda de brister som finns i övrigt.

Steg 11: Bygg mekanismer och rutiner för upptäckande och åtgärder av fel

Det räcker inte att åtgärda brister i befintligt data, utan det gäller även att se till att samma brister inte kan uppkomma igen. För detta kan vi bygga automatiska kontroller och manuella rutiner.

Steg 12: Etablera en formell organisation

Nu är det dags att göra hanteringen av kunddata mer formell – både i organisationen och i det centrala teamet.

Det centrala teamet bör bygga vidare på de personer som redan varit med i arbetet. Varför? För att det fortsatta arbetet inte skiljer sig nämnvärt från det vi redan gjort.

Det handlar alltså inte om att lämna över till någon ny grupp, annat än i en rent formell mening. Eller om vi vänder på det: De som ska ta hand om kunddata framöver bör vara samma personer som varit med och byggt upp arbetssättet.

Vi bör alltså redan tidigt ha hållit utkik efter, och till vårt team rekryterat, personer i organisationen som visar sig ha fallenhet för denna typ av arbete.

Roller ute i de olika verksamhetsfunktionerna som använder kunddata bör på motsvarande sätt grunda sig på de som vi haft regelbunden kontakt med under utvecklingsarbetet.

Sålunda är förvaltning av kunddata en naturlig och nästan osynlig övergång från utveckling av kunddata. Det är ju samma arbete som rullar vidare, men i en mer etablerad form.

Process: Fortsättning med nästa dataområde

När vi har gått igenom alla dessa faser för kunddata, säkert itererat några gånger, och tycker att vi nu har kontroll på kunddata och organisation och arbetssätt för att jobba med ständiga förbättringar, både med data i sig och med arbetssätt och organisation, är det dags att vi tar oss an nästa dataområde.

Kanske blir det produktdata.

Eftersom vi nu övergår till en aktiv förvaltning av kunddata och sannolikt kan minska bemanningen i det centrala kunddatateamet, får vi loss nu erfarna teammedlemmar att börja gå igenom samma process för produktdata. Denna gång bör gå mycket lättare, eftersom vi nu har erfarenhet och det i stora delar är liknande arbete som med kunddata.

Detta gäller dock inte de roller som är utspridda i organisationens olika funktioner. Förmodligen är det andra personer som använder och har ingående kunskap om produktdata än om kunddata.

När vi på detta sätt jobbar oss igenom dataområde efter dataområde är det lämpligt att först få kontroll på de olika områdena av masterdata – såsom kunder, produkter och anläggning – samt de gemensamma referensdata, som koder av olika slag som används i många sammanhang.

Varför? Två skäl:

1. Masterdata och referensdata är grunden

• Transaktions- och händelsedata bygger på dessa, så det är alltid bäst att få ordning på grunden först.

2. De saknar naturligt ägarskap

• Medan andra datatyper ofta har tydliga ägare i verksamheten, saknar masterdata och referensdata en självklar hemvist.
• Därför måste vi etablera särskilda verksamhetsfunktioner för att hantera de

Börja med grunden – så står resten stadigare.

Att få koll på masterdata är nästan alltid det tyngsta arbetet. Fortsättningen med transaktions- och händelsedata brukar vara enklare.

Låt oss dela erfarenheter!

Det här var bara en översiktlig beskrivning av tillvägagångsättet. Många av stegen i arbetsgången finns mer grundligt beskrivna i en mängd andra artiklar. Du hittar dom här i vår artikelsamling. Botanisera där.

Den beskrivna utvecklingsprocessen är således både inkrementell och iterativ. Inkrementell i och med att vi tar oss ann ett dataområde åt gången, och iterativ i och med att vi går tillbaka och förfinar tidigare steg i takt med nya insikter. Processen är också agil i och med att den betonar samarbete, lyhördhet, anpassning och resultat framför att följa en stel plan.

Processen är resurssnål och effektiv eftersom den bara kräver ett litet vasst team utöver ordinarie resurser. Arbetet går som sagt inte att forcera genom att öka bemanningen.

Processen ger nytta från första dagen. (Nåja, första veckan då).

Den är också snabb, det vill säga så snabb det går.

Men klar blir man aldrig – och det är hela poängen. Att ta hand om sina data är ett permanent arbete. Och ju mer framgång man har, desto mer jobb skapar det. Ty när verksamheten får ordning på sin datahantering öppnas så många nya möjligheter – både affärsmässigt och effektiviseringsmässigt. Aptiten växer med matsäcken.

Men satsningen förutsätter att man har kunskap och erfarenhet om de ingående arbetssätten och metoderna. Som informationsmodellering, begrepps- och termarbete, verksamhetsmodellering, analys av datainnehåll, arbete med ”data linage”, hur man samarbetar, hur man gestaltar, kommunicerar och dokumenterar med graf, text och verbalt.

Och vi är för få som jobbar med det här. Men vi kan alla bli bättre – och det är egentligen varken svårt eller tidskrävande. Om vi delar kunskap och erfarenheter.

Vad tror du om detta? Hur gör ni i er organisation? Har ni liknande eller andra tankar? Hör gärna av dig och berätta. Hoppas vi kan byta erfarenheter.