Hur kan vi bygga upp Data Management i våra organisationer?

Du kanske är en av de som nu ställts inför att behöva bygga upp er organisations förmåga att ta hand om era data- och informationsresurser på ett bra sätt. Här kommer en road map. Råd nummer ett: Börja i rätt ände!

/Peter Tallungs, IRM 2023-11-16

Det bubblar i våra verksamheter

I många organisationer behöver man nu satsa på att få bättre ordning på sina data. Fram tills nu har man ofta kunnat duckat för frågan och ignorera röran. Ingen i organisationen har kunnat eller velat ta sig an problemet. Men när data på många sätt hamnar i centrum för verksamhetens utveckling blir behovet påträngande.

Ett stort hinder för en bättre ordning har varit att ansvaret hamnat mellan stolarna. It-sidan har sett datakvaliteten som verksamhetssidans ansvar. Det är ju rimligen verksamheten som äger dessa data, och man har sett det som att it-folket endast ansvarar för informationsteknikens rent tekniska aspekter.
Verksamhetsfolket å sin sida har knappast kunnat göra något åt bristerna eftersom alla data har sin hemvist i djupet av it-systemens databaser och dit har man inte tillgång. Ej heller har man verktyg, kunskap eller arbetssätt för att analysera och hantera dessa data.

Hur gör man?

I många organisationer vill man nu börja bygga en data management-förmåga, det vill säga organisation, ansvar och arbetssätt för att ta hand om sina data på ett bra sätt. Det är bra. Men min uppfattning är att man på många håll börjar i fel ände. Man tar sig an uppgiften top-down. Vanligen delar man ner verksamhetens hela dataresurs i data- eller informationsdomäner med utpekade data- eller informationsägare som man kan fördela ansvar till.

Varför är det fel? Jag tycker visserligen att det är rätt tänkt att man behöver stycka elefanten och att man behöver fördela ansvar på detta vis. Men jag menar att det inte är rätt sätt att börja om man vill utveckla en förmåga, och att det försvårar chanserna att lyckas. Låt mig förklara.

Vi behöver en central stödförmåga

För att data- och Informationshantering (data management) ska fungera behöver vi en central stödförmåga i organisationen, en data management-funktion med all den kompetens, arbetssätt och verktyg som behövs för att stödja verksamheten i detta.

Vi behöver förvisso också vissa roller utspridda i organisationen, inte minst data-/informationsägare (Data Owners), men också dataförvaltare (Data Stewards) eller vad man vill kalla det. Men dessa utspridda befattningar kan och bör vi vänta med att etablera, ty utan den centrala stödförmågan kan dessa knappast introduceras, förstå och fungera i sina roller. Det är en mer framkomlig väg att först etablera och få igång den centrala stödförmågan för att först därefter etablera ägarskap och representation ute i organisationens olika delar.

Vad är en central stödförmåga?

Vad menar vi med en central stödförmåga? Vi kan jämföra med hur vi hanterar andra gemensamma resurser i våra organisationer; information i form av data är en gemensam resurs likt andra, och det finns erfarenheter att ta vara på gällande hur vi hanterar andra gemensamma resurser.

Ta till exempel personal; vem har ansvar för dem? Ja det är förstås alla chefer med personalansvar, utspridda i hela organisationen. De sköter dock inte alla personalärenden helt själva utan har stöd och hjälp från en HR-avdelning, i varje fall i en större organisation. De behöver inte själva kunna allt och ta hand om alla detaljer, men de bär ändå det yttersta ansvaret. HR-funktionens ansvar, å sin sida, är att ge stöd till de personalansvariga i form av rutiner och kompetens.

Eller ta ekonomin; vem bär ansvaret? Ja det är alla chefer som är ansvariga för någon typ av kostnads- och intäktsbärande enhet i verksamheten. De behöver dock inte hantera allt jobb med ekonomin själva, utan de har en ekonomiavdelning som är ett stöd i form av rutiner, regler, resurser, it-stöd med mera. Men ansvarig chef bär ändå det yttersta ansvaret för ekonomin för sina enheter.

En del av ett organisationsmönster

Mönstret går igen överallt vad gäller gemensamma resurser i våra verksamheter. Ansvaret ligger utspritt i organisationen, och det finns en central stödfunktion som tar hand om de dagliga rutinerna, liksom de mer kniviga frågorna. Med andra ord: ansvaret utspritt i organisationen men en stödfunktion centralt placerad. Denna stödfunktion kan vara liten eller mycket stor beroende på behovet. Ekonomifunktioner är ofta mycket stora eftersom de spänner över så mycket. It-funktioner, som ju också är en slags stödfunktioner är mycket stora i organisationer som är digitaliserade till stor del. Andra stödfunktioner kan vara mycket små, som till exempel tidrapportering.

Det är ett framgångsrikt organisationsmönster. Det är svårt att tänka sig att det skulle fungera på något i grunden annorlunda sätt. I varje fall inte då det gäller en större organisation, och någon lite mer omfattande resurs som ska hanteras.

Vi behöver följa samma organisationsmönster för data- och informationshantering, det vill säga en central funktion/förmåga som gör mycket av det praktiska jobbet och som står för den djupare kompetensen. Här behövs det heltidare, så som en eller flera informationsarkitekter samt andra specialiserade roller så som data engineers.

Roller och ansvar

Som nämnts behöver vi även ett antal andra roller utspridda i organisationen, inte minst data-/informationsägare vilka har det yttersta ansvaret. Att vara ägare till något innebär att ha en långtgående bestämmanderätt över något, inte nödvändigtvis samma som att man gör jobbet för att underhålla och hantera detta något. Inte heller nödvändigtvis att man är den som styr precis vad som görs. Det kan delegeras så länge man har överblick och tillit. Det behövs även dataförvaltare utspridda i organisationen som på olika sätt bevakar intresset för sina användare och intressenter. Ingen av dessa roller är på heltid, utan är ett ansvar man har utöver sitt ordinarie arbete.

Data-/informationsägare behöver dessutom referensgrupper, så att de kan beakta det bredare intresset i organisationen för sina respektive data-informationsdomäner.

Bygg stödförmågan först!

Men var ska vi då börja, vi som tar på oss uppgiften att bygga upp en data management-förmåga i vår organisation? Jag menar på att det är bättre att börja med att bygga upp en central stödförmåga i stället för att direkt delegera ansvar ut i organisationen. Och det av flera skäl.

Följande är de fallgropar vi vill undvika:

1. Smitväg

Om vi som ska leda uppbyggnaden av förmågan bara delar ut ansvar blir det gärna ett sätt för oss att slippa undan ansvaret att utveckla arbetssätt och kultur. Vi riskerar då att se det som varje dataägares ansvar att ta tag i arbetet, och vi själva slipper undan allt det jobbiga.

2. Motvilja

Ingen kommer villigt ta på sig rollen som dataägare. De tillfrågade förstår säkert att det behövs, men hur ska de kunna bygga upp något som de inte har kunskap och erfarenhet av? De har fullt upp med sina vanliga uppgifter, och det finns ingen praktisk möjlighet att ta sig an uppgiften. Det enda de får är pressen och skulden.

3. Saknad kompetens

De som trots allt skulle acceptera rollen har ingen möjlighet att göra något vettigt. De har ingenstans att ta hjälp och stöd ifrån då det inte finns någon etablerad och inarbetad stödfunktion. Betänk att detta är ett nytt område. Kunskapen och erfarenheten är liten i våra organisationer om vad data management innebär och hur arbetet med detta kan fungera.

4. Otillräckliga resurser

Det räcker inte långt med att ha ägare. Att ta hand om data är mycket mer än att utöva ett ägarskap. Att vara ägare till något innebär att ha långtgående rättigheter över något, och därmed också ett stort ansvar. Man tar det slutliga beslutet i de stora frågorna, men ägarskap omfattar sällan att man i praktiken, i den praktiska vardagen, utför jobbet med att ta hand om resursen. Man behöver egentligen inte ens var så insatt i detaljerna, utan tar råd och hjälp av sakkunniga. Utan resurser kan man inte utöva sitt ansvar. Och dessa resurser bör vara centrala i organisationen, för effektivitetens och för kunskapsdelningen.

Hur klarar vi oss utan data-/informationsägare tills vidare?

Märk att jag inte är emot att man behöver data-/informationsägare, bara att etablerandet av dessa kan och bör vänta tills vi har kommit längre i vår mognad. Vi bör i stället kavla upp ärmarna och sätta igång själva jobbet. Annars blir det lätt en smitväg för oss, ett sätt att delegera ansvaret till andra som inte har möjlighet att klara jobbet, och utan att ge dessa minsta möjlighet till stöd.

Hur kan vi då klara oss utan ägare? Måste inte någon bestämma ändå? När jag har varit med om att bygga upp data management har vi som utgjort embryot till en central data management-funktion tagit ägaransvaret tills vidare. Vi har deklarerat tydligt och klart allt vi gjort, och sagt att om någon misstycker får de kliva fram. Med tiden har vi hittat lämpliga ägare, och dessa har först när de sett att det finns en fungerande stödfunktion med arbetssätt som fungerar varit beredda att ta det ansvaret.

Hur bygger vi stödförmågan?

Hur ska vi göra då? Jo som alltid när man utvecklar något nytt behöver man pröva sig fram i liten skala. Det handlar om att vi behöver lära oss hur vi ska göra genom att experimentera. Det är så all utveckling går till, egentligen. Vi ska skapa något som ännu inte finns i sinnevärlden. I varje fall inte just här och med precis dessa förutsättningar. Och när något inte finns i sinnevärlden så finns det inte heller färdigt i tankevärlden, annat än som hypoteser. Hypoteser som behöver prövas, verifieras och falsifieras för att därefter modifieras och prövas igen. Det är så utveckling går till, överallt och med allting. Det är själva definitionen av utveckling, egentligen, fast man ofta framställer det annorlunda.

Så vi behöver ta oss an en lämplig munsbit av verksamhetens hela datadomän, och börja ta hand om denna. Det är då viktigt att gå hela vägen, både med informationsarkitektur, organisation, datakvalitet med mera. Detta för att få så bra lärande som möjligt. Lärande är återkoppling från verkligheten, att vi observerar resultatet och lär oss.

Dataägare ute i verksamheten kan vi vänta med anser jag, om det inte råkar dyka upp någon som både vill och kan ta ansvar. Men det är inte vanligt att någon verkligen kan ta ansvar för något utan att ha de rätta verktygen till hands, det vill säga allt detta som en fungerande stödförmåga i full drift innebär.

Var börjar vi?

Börja i liten skala. Välj en domän som verkar lämplig. Vad är då lämpligt? Jag menar att du då behöver väga samman två kriterier.

Kriterium 1: Data som är grundläggande för verksamheten.

Det vill säga masterdata eller globala referensdata. Det är sådana som ingen riktigt vill äga men som refereras till från många håll. Därför är kvaliteten oftast lidande och det är svårt att få ordning på annan data innan man fått ordning på dessa.

Exempel på masterdata i många organisationer är kunder och produkter. Det kan också vara annat med ganska lång livslängd, som leverantörsavtal, i den mån de existerar över tid.

Globala referensdata kan vara listan över kommuner i Sverige, regioner i världen, branschkoder och liknande, i de fall dessa refereras från många ställen.

Kriterium 2: Något verksamheten behöver få ordning på just nu

Detta beror på vilka utvecklingssatsningar som går i gång. Det som är aktuellt får fokus och resurser.

För finansiell verksamhet har regelefterlevnad alltid hög prioritet. För service och handel är sådant som stärker kundupplevelsen och ger merförsäljning viktigt.

Ägna all kraft åt den domän ni valt och se till att få resultat där. Här följer en skiss till en road map. I de sammanhang jag varit inblandad i är det just så vi gått till väga då vi lyckats.

Road map för att bygga upp data management för en datadomän

1. Kartlägg datastrukturer

Kartlägg datastrukturer, skapa en detaljerad konceptuell informationsmodell med termer och definitioner för begrepp, och verksamhetsregler. Se till att modellen är gestaltad så bra som möjligt, och utforma den så att den blir en plattform för gemensamt lärande.

Exempel – Om produktdata:

Var finns produktdata? Hur ser den fysiska strukturen ut? Hur mappar den mot den konceptuella? Vilka produktbegrepp finns det och hur kan vi benämna dessa? (Produktgrupp, produkttyp, produkt, produktvariant, produktversion, produktkomponent, komponentversion, komponentvariant, produktegenskaper produkt-id, produktnamn externt, produktnamn internt, leverantörsprodukter, produktindivider etcetera). Skapa en gemensam ändamålsenlig nomenklatur, men tillåt och dokumentera de synonymer som förekommer.

2. Kartlägg datalogistiken

Kartlägg datalogistiken, det vill säga hur och var data skapas, och hur data transporteras, integreras och används i förmågor, applikationer och tjänster.

Exempel – Om produktdata:

Var skapas produktdata? Var finns master för produktdata? Hur propageras produktdata genom integrationer tjänster applikationer och förmågor, internt och externt? Vem använder produktdata och till vad?

Punkt ett och två är typiskt sådant som omfattas av det vi kallar informationsarkitektur och är grundläggande för data management-området. Följande punkter är sådant som har med själva effektskapandet att göra, så som datakvalitetsarbete, datastyrning, organisationsutveckling med mera. Det är strikt sett inte informationsarkitektur, men som informationsarkitekt kommer du bli djupt inblandad och kanske också bli den som praktiskt gör mycket av jobbet, speciellt under denna uppbyggnadsfas.

3. Kartlägg dataförekomsterna

Kartlägg dataförekomsterna i sig, delmängd för delmängd, attribut för attribut, katalogisera brister. Intervjua applikationsförvaltare och användare, vilka brister ser de vad är deras behov och vad skulle de behöva?

Exempel – Om produktdata:

Vilka anomalier och brister finns det? Vilka lider av bristerna och på vilket sätt? Hur skulle de vilja att det fungerade?

4. Implementera åtgärder för att avhjälpa befintliga brister och automatisera regler

Implementera åtgärder för att avhjälpa befintliga brister och automatisera regler som gör att dessa brister inte uppkommer eller propageras i fortsättningen.

Exempel – Om produktdata:

Gå igenom brist för brist, städa och rätta. För varje brist genomför åtgärder så att bristen inte uppkommer på nytt. Det kan vara automatiska kontroller eller bättre instruktioner för de som registrerar.

5. Bygg organisation

Bygg organisation dels för den centrala stödfunktionen och dels för den som behöver finnas ute i organisationen bland användare, så som dataägare, data stewards och liknande. Sätt igång arbetet med ständiga förbättringar.

Exempel – Om produktdata:

Vem ska äga produktdata? Vem bestämmer hur en ny produkt ska namnges, identifieras och kategoriseras? Ska det verkligen bli en ny produkt och inte ses som en variant på en befintlig? Vilka regler gäller? Vem ska i praktiken monitorera produktdata och göra de ständiga förbättringarna? Vem ska stå i kontakt med användare och utvecklingsprojekt och kontinuerligt se till att deras behov tillfredsställs?

Dags för nästa domän

När vi kommit tillräckligt långt i detta arbete, när vi har arbetssätt och kultur på plats, både för den dagliga driften och kontinuerliga förbättringar kan vi se det som att vi har hela den nya fungerande data management-förmågan på plats för denna domän. Då är det dags att vi tar oss an nästa domän, kanske blir det kunddata.

Komna så här långt har vi kultur, arbetssätt, erfarenhet och mall för organisation på plats, vilket gör fortsättningen enklare och snabbare. Vi stöter förmodligen på andra brister och andra behov för denna andra domän, men i grunden kan vi använda vår första domän som mall.

Vilka är motargumenten mot att börja med den centrala stödförmågan?

Om vi i stället skulle börja med att utnämna dataägare för varje domän, ge dem ansvarsbeskrivningar och tro att det skulle ordna sig själv, skulle vi lätt hamna illa till. Vi kan inte ens ge de nya befattningarna exempel och föredömen annat än i mycket grova drag och rent teoretiskt, inget som vi har egen erfarenhet av. Ett antal dataägare skulle sitta och klia sig i huvudet och desperat köra i gång olika åtgärder utan att veta vad de egentligen bör göra och vad som egentligen fungerar.

Argumentet mot det angreppsätt som jag förespråkar, att bygga den centrala funktionen först, brukar vara att man inte har den tid som krävs. Man måste jobba på bred front, parallellt med alla domäner samtidigt.

Men det är ett missförstånd att det skulle gå fortare om man gör allt samtidigt. Det är inte så utveckling fungerar. Man kan skala upp och ut först då man lärt sig. Annars kommer det inte bara att gå långsammare utan bli helt omöjligt, och vi bränner våra chanser att verkligen göra en skillnad. Att gör en sak i taget och i liten skala går dessutom mycket snabbare än man kan tro. Allt man gör bygger på den tidigare erfarenheten. De misstag man råkar göra ger inga större konsekvenser, allt är ett kontinuerligt lärande. Man kan då gå från klarhet till klarhet och snart har man kommit mycket långt.

Alltså: bottom up i stället för top down. Börja litet, göra en sak i taget men gå hela vägen. Att vi lär oss samtidigt som vi gör.

Det är så utveckling går till. Genom experimenterande. Egentligen överallt och i alla sammanhang. Trots att det ofta inte är så det lärs ut.