Bra lösningar
När ramverket möter verkligheten – varför DMBOK behöver ritningar
DAMA-DMBOK ger organisationer ett gemensamt ordförråd och pekar ut vad som måste finnas på plats. Men när måndagen kommer och IT ska integrera system med verksamheten behövs något annat: konkreta ritningar.
Publicerad · 4 min läsning

De flesta som arbetar seriöst med data management har någon gång bläddrat i DAMA-DMBOK. Boken – en drygt 600 sidor tung referensbibel från DAMA International – är ett imponerande standardverk. Den sätter ord på de elva kunskapsområdena i det välkända DAMA-hjulet, från Data Governance och Data Architecture till Reference & Master Data Management.
Ändå händer det förbluffande ofta att en organisation som stolt köpt in DMBOK, etablerat ett ”Data Office” och certifierat sina strateger, ett par år senare står med precis samma datakaos i verksamheten: behörigheter som slirar, chefsled som inte stämmer, och enheter som förväxlas med kostnadsställen.
Varför blir det så? Och hur fyller informationsmönster gapet mellan standardens teori och vardagens system?
1. DMBOK beskriver förmågan – inte ritningen
DMBOK är i grunden ett kapabilitetsramverk. Det är utformat för att svara på frågorna: Vilka discipliner behöver en modern organisation behärska? Vilka principer och aktiviteter ingår i Data Governance? Vad skiljer referensdata från masterdata i teorin?
Men DMBOK är medvetet neutralt. Boken ritar inte upp hur en svensk organisation faktiskt ska skilja på en Enhet och ett Kostnadsställe. Den visar inte hur relationen mellan Person, Medarbetare och Chef ska struktureras för att både HR-systemet, lön och IAM ska förstå vem som attesterar en licens.
Att försöka bygga ett fungerande IT-landskap enbart utifrån DMBOK är lite som att försöka bygga ett energieffektivt flerbostadshus med enbart Boverkets byggregler i handen. Reglerna är nödvändiga och talar om vad som krävs för bärighet och brandskydd – men snickaren och konstruktören behöver fortfarande en konstruktionsritning.
2. De tre glappande skarvarna i teorin
När DMBOK möter en organisations vardag uppstår tre typiska glapp.
a. Silobildning mellan kapitlen
I DMBOK ryms Data Architecture i kapitel 4, Data Governance i kapitel 3 och Master Data i kapitel 10. I den praktiska verkligheten kan dessa discipliner aldrig separeras: En arkitekturritning utan förankrade affärsregler är bara en teckning. En datastyrningsregel som inte vet vilken applikation som är System of Record blir tandlös. En masterdatalösning utan processkoppling saknar livscykel.
Varje byggblock i Informationsmönster tvingar ihop dessa trådar: definition, affärsregel, livscykelprocess och systemkälla visas på samma ställe.
b. Det anglosaxiska abstraktionsfiltret
DMBOK är författat ur ett globalt, anglosaxiskt perspektiv. Det tar inte hänsyn till den unika svenska infrastrukturen: Vi har starka, lagstadgade basregister (Skatteverket för personer, Bolagsverket för juridiska personer, Lantmäteriet för fastigheter). Vi har etablerade nationella kodverk (SSYK, SOSNYK). Vi har en offentlig sektor där kommuner och regioner har komplexa, dubbla uppdrag med strikta offentlighets- och sekretesskrav.
En fungerande informationsarkitektur måste rita in den skarpa rådighetsgränsen: Vad äger vi själva, och vad är ett externt nationellt basregister som vi bara lånar in?
c. Språkbarriären mot verksamheten
DMBOK talar ett språk för specialister: data stewardship, canonical schemas, surrogate keys, semantic consistency. Det språket fungerar sällan i ledningsgruppen, hos HR-chefen eller hos verksamhetsutvecklaren i hemtjänsten eller produktionen.
När man däremot visar ett visuellt mönster – där en röd ring tydligt visar att ansvaret följer chefskoden och inte en godtycklig titel – förstår verksamheten direkt. Datastyrning flyttas från en teknisk abstraktion till ett samtal om verksamhetsansvar.
3. Mönstret: Det saknade lagret mellan ramverk och kod
Informationsmönster ersätter inte DMBOK. Tvärtom: sajten vilar tryggt på dess teoretiska fundament. Men den tillför det saknade mellanlagret – mönsterbiblioteket.
Återanvändbara lösningar på kända problem: I stället för att varje projekt återuppfinner hur en B2B- eller B2C-kundrelation ska modelleras, finns ett testat mönster.
Hårda regler för svåra gränsdragningar: Tydliga principer för varför en person aldrig bär ett chefskap direkt, varför intern befattning hålls isär från yrke, och varför applikationstilldelning kräver både enhet, chef och kostnadsställe.
Källstyrning med verkliga roller: En katalog som skiljer på Egen organisation och Extern organisation, och som pekar ut exakt vilket system som har auktoritativ rådighet över vilken uppgift.
Medarbetare med chefskod. Chef är inget eget informationsobjekt. Den röda ringen visar en Medarbetare med chefskod, och relationerna anger vilken enhet, vilket kostnadsställe eller vilka medarbetare personen är chef för.
Sammanfattning: Standarder ger riktning – mönster ger leverans
Internationella ramverk som DAMA-DMBOK är ovärderliga för att sätta gemensamma begrepp och förstå vilka kompetenser en organisation måste bygga upp. Men ett ramverk driftsätter inga integrationer och löser inga felaktiga fakturor.
För att gå från strategi till fungerande digitalisering behövs färdiga, genomtänkta informationsmönster. När ramverkets principer möter konkreta arkitekturritningar upphör datastyrning att vara en pappersprodukt – och blir i stället en motor för verklig automatisering.
Taggar
- #DMBOK
- #datastyrning
- #masterdata
- #informationsmönster
- #automatisering