Bygg kultur och arbetssätt för att ta hand om data

Allt fler inser vikten av att ta ett bättre grepp om verksamhetens dataresurs. Det är tydligt. Om man känner att det är dags att ta kontrollen – Hur börjar man? Här följer ett strukturerat förslag på detaljerad guide för hur vi kan bygga kultur, arbetssätt och fördela ansvar med syftet att ta hand om data, information och språk i vår verksamhet.

/Peter Tallungs, IRM, 2026-01-15

Vi ser ett växande intresse för informationsarkitektur

Intresset för informationsarkitektur och data är stort och växande, efter många år i träda. Ledningarna i myndigheter och företag känner nu att de behöver ta bättre hand om sina organisationers dataresurser. De vill transformera sin informationshantering, genom att sätta data i centrum för arbetet, i stället för teknik och it-applikationer.

Det är en god sak, om man är seriös och inte stannar vid tomma slagord som att man ska bli en ”datadriven” organisation. Vad det borde handla om är att odla fram en genomtänkt, kompetent och medveten datahantering (data management), med allt vad det innebär.

Men ofta har man för bråttom, vill visa handlingskraft och tror att detta går att kommendera fram. Man vill göra det enkelt för sig, utnämna dataägare och dataansvariga för sina datadomäner och sedan bara lämna över. Mission acomplished. Men det är inte så man transformerar en verksamhet.

Organisation, arbetssätt och kultur måste få växa fram organiskt, genom ett stegvis lärande. Ja egentligen sker all fungerande verksamhetsutveckling så, överallt och vad det än gäller.

Här kommer råd från oss som hjälpt många organisationer med detta. Råden framstår kanske inte alltid helt intuitiva, och ibland till och med på tvären mot det som brukar förespråkas. Men i min erfarenhet är det detta som fungerar för att lyckas med den transformation vi behöver.

Råden är formulerade i elva steg ordnade i tiden. De två första stegen sätter scenen för hela resan, och får därför lite mer utrymme här.

Steg 1:    Etablera ett team

Förändring av en organisation av detta slag är ett organisatoriskt lärande som behöver odlas fram. Man behöver så frön, vattna, göda och låta gro. Det är inget som bara kan införas uppifrån eller beställas fram, och inte heller något som fungerar att angripas på bred front.

I stället behöver vi etablera ett litet vasst team för att driva förändringen, en datadomän i taget. Det kanske kan kännas för långsamt och inte så kraftfullt. Men det är ett misstag att tro att en sådan här transformation av en verksamhet går snabbare med en bred ansats.

Det betyder inte att förändringen behöver ta så lång tid egentligen. När något fått fäste kan det gå förvånansvärt fort.

Några viktiga saker att tänka på:

Res med lätt packning

Det är lagom med ett kärnteam på tre till fyra personer, gärna med lite olika spetsar i sina kompetenser. Till exempel två informationsarkitekter, en projektledare och en kommunikatör/bibliotekarie, som tar hand om allt material de tar fram.

Senare, när behov uppstår, kan ni utöka teamet. Men betänk att ett större team kräver mer samordning, vilket blir overhead utan att kanske ge mer tillbaka. Det handlar inte om ett mekaniskt arbete, utan om ett gemensamt utforskande. Ett litet team kan röra sig snabbare, och med den lättrörlighet som krävs.

Marknadsför er

Det är viktigt att teamet gör sig synligt och transparent, och marknadsför sig brett i organisationen. Berätta vilka ni är, vad ni ska göra, hur man kan nå er, och informera löpande om vad som händer i ert arbete. Skapa en wikisida eller liknande på intranätet och publicera månadsbrev.
Det behövs också riktad marknadsföring. Ofta väcker man snart nyfikenhet och blir inbjuden till olika forum i organisationen för att presentera vad man gör.

Börja smått, med ett avgränsat informationsområde

Fokus ska vara lärande, ett stegvis prövande och experimenterande med kultur, arbetssätt och roller. Ni kommer att ta fel beslut ibland. Allt blir inte som man tänkt. Men eftersom ni är ett litet team och arbetar med ett begränsat område lär ni er snabbt och justerar därefter.

Det är så lärande ser ut. Egentligen fungerar all utveckling så, som ett gemensamt experimenterande i små, effektiva steg. (All utveckling, överallt, i alla sammanhang, om man tänker efter.) Om man i stället slår på stora trumman och går ut brett, blir oundvikliga misstag till publika misslyckanden. Det är inte så bra. ”Fail fast” är en god princip, som innebär att man experimentera sig fram i små steg.

Idealt är att börja med någon slags masterdata, till exempel kund- eller produktdata, eftersom nästan alla övriga data har beroende till masterdata. Något som utmärker masterdata är att de saknar naturligt ägarskap. Ägarskapet behöver etableras, men det är viktigt att inte ha för bråttom, utan låta organisation och ansvar mogna fram över tid. Mer om det senare. Tills vidare kan ni i teamet ta ägarskap.

Om det råkar finns ett projekt på uppseglande som fokuserar på en ny lösning för någon typ av masterdata, är det en stor fördel att haka på detta. Då får ni draghjälp.

Låt oss, för exemplets skull, säga att ert team tar sig an kunddata som första område. Alla följande steg i artikeln kommer därför att handla om kunddata. Om ni väljer ett annat område, byt bara ut ordet ”kunddata” mot till exempel ”produktdata”, ”persondata” eller ”anläggningsdata”.

Försök inte ta er an flera områden samtidigt

Kom ihåg: ni rör er på okänd mark. Ingen har gjort det här förut, inte i just er organisation, med just dessa personer. Er satsning handlar om att pröva er fram, lära er vad som fungerar här och nu. Och ni får tydlig återkoppling och konkret nytta först när ni gått hela vägen med ett informationsområde.

Det går både enklare och snabbare, och blir mera rätt, om ni koncentrerar er på ett område i taget och följer det hela vägen. Först därefter är ni mogna att ta er an nästa.

Er framgång i det första området bygger både erfarenhet och förtroende i organisationen för att ta itu med nästa. Det ni lärt er blir då en slags arbetsmodell att bygga vidare på. Det bör gå betydligt snabbare tack vare erfarenheterna, de upparbetade arbetsformerna formerna och det vunna förtroendet.

Steg 2:    Ta fram informationsmodell för kunddata

Bygg partnerskap med it- och verksamhetskunniga, och samarbeta tätt med dessa

Ni behöver börja med att utveckla partnerskap med dem som är mest kunniga om kunddata i organisationen. Det handlar om både it-utvecklare och verksamhetsspecialister.

Utvecklarna hjälper er att identifiera kunddata i databaser, filer och api:er. Olika kategorier av verksamhetsspecialister bidrar med förståelse för vad olika dataposter och fält egentligen betyder.

Särskilt viktiga är de analytiska användarna, de som tar fram analyser och rapporter. Det är de som har störst behov av tydliga namn och definitioner samt datakvalitet i övrigt. Det är de som snabbast märker när ni är rätt ute. Med dem behöver ni kroka arm.

Det är vanligt att möta motstånd och skepsis i början. Många har sett konsulter komma och gå genom åren, som har lovat stort men inte levererat bestående värde. Partnerskap bygger på förtroende och förtroende är inte något som delas ut på förhand utan något man behöver vinna.

Man behöver visa att man lyssnar, att man hjälper, att det är deras individuella behov man företräder. Då får ni deras hjälp och engagemang. Det är så man bygger partners, och så småningom entusiastiska supporters.

Jobba nära och interaktivt

Det mest effektiva sättet att samarbeta är genom intervjuer, dialoger och små riktade workshops. Det underlättar om man kan placera sig fysiskt nära de person man behöver samarbeta med. Ty frågor och följdfrågor poppar upp hela tiden, och kan inte skjutas på till schemalagda möten, utan behöver svar direkt för att inte stoppa upp den läroprocess ni nu är inne i.

Om man sitter på olika ställen behöver man hitta sätt att kompensera för den kommunikativa friktion som avståndet skapar. Det kan vara genom täta, spontana och korta videomöten.

Strävan bör alltid vara densamma: att eliminera friktion i kommunikationen, att etablera en sömlös och levande dialog.

Rekrytera

En viktig bieffekt av samarbetet är att man nästan alltid hittar medarbetare man vill knyta till teamet framöver. Det brukar alltid dyka upp guldkorn, talanger med särskilt intresse för begrepp, struktur och data. Det är dessa som blir nyckelpersoner i de olika Data Management-teamen ni så småningom kommer att behöva lämna över till.

Se till att modellen kombinerar aspekter

Om modellen verkligen ska bli plattformen för ert gemensamma lärande behöver den inte bara beskriva data om kunder, utan också själva företeelserna som data representerar.

Det handlar alltså om hur ni tillsammans formar hur ni vill se på kunder och det som finns runtomkring: egenskaper, begrepp, benämningar och verksamhetsregler. Det är den gemensamma förståelsen av verksamhetsdomänen ni bygger, det som data representerar och inte bara hur data är strukturerat.

Med andra ord: modellen ska inte bara beskriva en datadomän, den ska också beskriva själva domänen Kund.

Låt inte verktygen begränsa er

Arbeta med en kombination av enkla verktyg och den grafik som bäst stödjer det ni behöver gestalta. Låt er således inte styras av ett specifikt verktyg eller metod, utan sök, kombinera och utveckla de verktyg och arbetssätt ni faktiskt behöver.

Arbeta med begrepp och språk

Analysera och definiera begrepp. Normera benämningar, det vill säga skapa gemensamma namn som är tydliga och korrekta.

Arbeta med begrepp och språk samtidigt som med data. Dess två arbeten driver varandra ömsesidigt, som kommunicerande kärl.

Det vi gör är de facto att definiera och normera ett gemensamt verksamhetsspråk. Det är egentligen det viktigast vi gör, och det har långtgående verkan för verksamhetens framtid. Namn och begrepp påverkar hur vi ser på verksamheten. De både möjliggör och begränsar utveckling, ofta långt efter att de it-system vi bygger har bytts ut.

Överlåt inte detta viktiga arbete till löst tyckande från olika personer i verksamheten, utan se detta som den viktigaste uppgiften ni leder.

Dokumentera även alla andra benämningar som förekommer parallellt som synonymer, vare sig de är bra eller dåliga. Vad saker råkar heta i olika sammanhang, som intern jargong, vardagliga benämningar, vad saker kallas hos partners, samt termer i databaser, filer och applikationer. Ty detta är inget vi kan ändra på, i varje fall inte inom överskådlig tid. Bara för att vi skapar ett normerat språk kommer vi inte att få detta tillämpat överallt. Alla förekommande synonymer behöver dokumenteras i informationsmodellen.

Inkludera verksamhetsregler

Ni behöver hantera mer av den operativa verksamhetslogiken än begrepp, språk och data.
Ni behöver dokumentera verksamhetsregler i tydlig text. Informationsmodellen ger strukturen att hänga upp verksamhetsreglerna på. Ty en verksamhetregel har alltid att göra med någon entitet eller något attribut. Alla regler runt kund har till exempel att göra med kunder.

Exempel: En aktiv kund är en kund som genomfört ett köp de senaste 6 kalendermånaderna, räknat inklusive innevarande månad.

Dokumentera bestämda värden i uppräknade listor

Statuskoder och andra uppräknade värden är en viktig del av verksamhetslogiken. Dokumentera dem tydligt. med kod, namn och definition. Det hör hemma i informationsmodellen.

Lägg er vinn om gestaltning av modellen i grafik och text

För att modellen ska fungera som tanke- och kommunikationsverktyg behöver den effektivt förmedla den konceptuella strukturen inom området. Det gäller både form och innehåll. Till exempel:

• Strukturera diagrammen genom att dela in dessa i ämnesområden.
• Skilj ut regelplan från operativt plan.
• Visa beroenden och parallellitet genom hur entiteter placeras i förhållande till varandra.
• Visa existentiella beroenden med beroendeobjekt.
• Använd gråskalor, färger och olika typsnitt för att särskilja olika typer av information.
• Linjera grafiska element, för att slippa den kognitiva belastning som oreda skapar.
• Komplettera ER-diagram med tillstånds- och förekomstdiagram, där de behövs.
• Kombinera grafik med strukturerad text: namn, synonymer, definitioner, regler, beskrivningar och så vidare.

Komplettera modellen med noteringar

Vi behöver mer än en ögonblicksbild av hur vi ser på världen just nu. Modellen bör också visa hur vi kommit dit – varför vi gjort vissa val, vem som tillfrågats, vad som sagts, oklarheter, vilka frågor som återstår.

Ge plats i modellen för daterade och signerade noteringar: beslut, ändringar, utestående frågor, kommentarer med mera.

Placera noteringarna tätt intill det de berör, i textdelen av modellen. På så sätt kan modellen gå från att vara en ögonblicksbild endast till något mycket mera: en plattform för gemensamt lärande över tid.

Utgå från fakta, i samarbete med både it och verksamhet

Utgå från befintliga datastrukturer. Det är som arkeologi, data visar vad som faktiskt har hänt i verksamheten, om än de behöver tolkas. Gå igenom databaser, filer och applikationer systematiskt. Samarbeta med både it och verksamhetskunniga för att tolka, definiera, benämna och beskriva det ni hittar.

Om man gör tvärtom, utgår från vad som kommer fram i workshops med verksamhetsfolk, blir det svårare att koppla ihop resultatet med de data som faktiskt finns i systemen.

Steg 3:    Kartlägg kunddata

Nu är det dags att ta reda på vad ni faktiskt har för data. Gå igenom relevanta dataförråd, kolumn för kolumn. Dokumentera:

• datatyper
• max- och minimivärden
• fältlängder
• orimliga eller inkonsekventa värden
• avvikelser och anomalier.

Det är först nu ni verkligen lär känna era data på riktigt. Informationsmodellen vi jobbat med hittills är ju fortfarande lite av en hypotes i sina detaljer.

Kartläggningen ger inte bara kunskap om brister i datakvalitet. Ofta leder kartläggningen till att vi även förstår både domän och data bättre. Med nyvunnen insikt behöver vi gå tillbaka och justera informationsmodellen.

Steg 4:    Ta fram en verksamhetskarta

Det räcker inte med att vi känner våra data. Vi behöver också förstå hur data lever, var de kommer ifrån, vilken väg genom verksamhet och it-miljö de tar, vad som händer på vägen och vem användarna är. Vi behöver kartlägga datalogistiken. För detta krävs en verksamhetskarta där vi kan dokumentera alla dataflöden (i detta fall för kunddata).

Verksamhetskartan är en karta över verksamhetens inre och yttre ekosystem, där it-applikationer och integrationer är en integrerad del av verksamhetens funktioner och tjänster.

Kartan visar:

• verksamhetsfunktioner
• externa parter (kunder, kunders kunder, leverantörer, leverantörernas leverantörer och partners)
• it-applikationer
• roller
• integrationer (filer, api:er med mera) som tjänster
• dataflöden – vem tillhandahåller, bearbetar, använder våra data: var, vem, vad, hur och varför.

En snabb och effektiv metod för att ta fram kartan är det jag kallar it-arkeologi, att utgå från det som brukar kallas Conways lag: att it-applikationer och integrationer i en verksamhet i stort är en spegling av verksamhetens funktioner och tjänster. Genom att analysera it-kartor kombinerat med intervjuer, får vi fram en bild av hur verksamheten de facto är strukturerad funktionellt.

Om man däremot enbart skulle utgå från workshops med verksamhetsfolk riskerar man få en karta som inte stämmer överens med hur it-miljön faktiskt ser ut.

Se till att verksamhetskartan verkligen avbildar it-miljön som en integrerad aspekt av verksamheten.
Principerna är följande:

• En it-applikation är alltid en del av en verksamhetsfunktion.
• En it-integration är alltid en tjänst, något en verksamhetsfunktion erbjuder andra parter, i form av interna verksamhetsfunktioner eller externa parter.

Det är först när vi ser denna karta, som vi på riktigt börjar tänka och agera utifrån att it är en integrerad del av verksamheten.

Observera att verksamhetskartan är användbar för många olika syften inom verksamhets- och it-utveckling. Men i detta sammanhang fokuserar vi bara på den roll den spelar för informationsarkitektur och data management.

Steg 5:    Spåra dataflöden för kunddata (data linage)

Använd verksamhetskartan för att spåra vad en viss datamängd kommer ifrån och vilken väg den tar genom leverantörer, verksamhetsfunktioner, databaser, it-applikationer, integrationer (filer eller api:er), tjänster, roller och till kunder och ibland även vidare till kunders kunder.

Eftersom verksamhetskartan visar it-miljön som en integrerad del av verksamheten blir dataflödet samtidigt ett flöde genom verksamhet och it.

Det är annars vanligt att skilja på business linage och technical linage, men verksamhetskartan gör att vi kan betrakta dessa som ett och samma flöde, beskrivet ur två olika aspekter, i samma vy.

Steg 6:    Bygg relation med intressenter runt kunddata

Med verksamhetskartan kan vi se vem som skapar kunddata, vem som hanterar kunddata på vägen och, inte mins viktigt, vem som använder kunddata. Vi behöver etablera kontakt med representanter för dessa intressenter och intervjua dem.

Vi är intresserade av deras behov, nu och framöver, och hur vi bäst kan till godo se dem. Det här blir grunden och sammanhanget för allt vi behöver göra framöver inom data management-arbetet.

Steg 7:    Kvalitetssäkra kunddata

För varje brist vi hittar i data behöver vi göra två saker:

1. Rätta till det som redan är fel. Det vill säga komplettera eller korrigera bristfällig eller felaktig information.
2. Förhindra att bristen uppstår igen. Vi behöver åtgärder som upptäcker och stoppar problemet innan det får fäste. Det kan handla om skript som kontrollerar inkommande data och flaggar avvikelser från definierade regler.
   Men det kan också handla om tydligare namn och definitioner på datafält, eller om att ge bättre stöd till dem som registrerar data i olika sammanhang.

Steg 8:    Etablera explicita kontrakt för samtliga tjänster (integrationer) som innehåller kunddata

För varje tjänst eller integration som innehåller kunddata behöver man ha ett tydligt kontrakt. Kontrakt bör omfatta både tekniska och verksamhetsmässiga aspekter, och kontraktet gäller åt båda håll: både producenten och konsumenten av data har förväntningar och åtaganden.

Kontraktet bör ha flera nivåer och täcka in:

• teknik (vilken teknik som används)
• meddelandestandard
• syntax (hur meddelanden är strukturerade)
• semantik (vad allt betyder)
• frekvens (hur ofta något levereras eller uppdateras)
• felhantering (hur fel ska hanteras)
• ägarskap, ansvar och administration.

Kontrakt finns egentligen alltid, fast de är odokumenterade, underförstådda, otydliga, missförstådda och ofullständiga. Jobbet blir att lyfta fram och dokumentera dessa.

Steg 9:    Säkerhetsklassa kunddata

Det är först nu, när vi verkligen känner våra kunddata – hur de ser ut, var de finns, hur de flödar och hur de används – som vi kan säkerhetsklassa dem på ett seriöst sätt. För när data kombineras i olika sammanhang får de nya betydelser, och därmed krävs en annan säkerhetsklassning.

Steg 10: Se över informationssäkerheten för kunddata

Det är först nu, när vi har en genomtänkt och förankrad säkerhetsklassning av kunddata, som vi kan börja ta itu med informationssäkerheten på ett seriöst sätt.

Steg 11: Etablera ägarskap och förvaltning för kunddata

Det är viktigt att vänta med att utse dataägare och förvaltningsteam tills allt det föregående är på plats. Det är svårt att ta ansvar för något man inte känner till, och som det inte finns etablerade arbetssätt eller resurser för att hantera.

Många gör misstaget att börja med att utse dataägare direkt, innan det finns någon struktur för förvaltning. Resultatet blir då ett ägarskap som bara finns på pappret, vilket snarare hindrar än främjar ansvarstagande. Det är ett vanligt misstag som effektivt saboterar det man ville uppnå.

De som nu kliver in i förvaltningsteamet bör ha varit med längs vägen. Förhoppningsvis har ni redan identifierat dem under resans gång, jobbat tätt tillsammans och sett deras engagemang växa fram.

Nu kan ni tryggt och smidigt lämna över ansvaret för kunddata till dem. De fortsätter arbetet, i lite lugnare takt, med ungefär samma uppgifter som tidigare. Fast det finns nog en hel del att arbeta vidare med då. Verksamheter behöver alltid utvecklas vilket ofta innebär nya krav på kunddata.

Ni som varit kärnteamet, ett slags avantgarde, kan nu gå vidare till nästa område. Kanske produktdata. Arbetssättet blir i stort sett detsamma, även om varje område förstås har sina egna utmaningar.
Det viktiga är att ni nu byggt upp både kunskap och förtroende i organisationen. På riktigt, genom det ni faktiskt levererat.

Hör gärna av dig

Vi är många just nu som jobbar med detta i våra företag och organisationer. Mycket behöver göras och än så länge är vi ganska få som har verklig erfarenhet.
Allt blir bättre när vi delar med oss.
Så hör gärna av dig!