Den omöjliga drömmen om den allomspännande informationsmodellen

Det är vanligt att stora organisationer startar ambitiösa modelleringssatsningar, med målet att skapa en informationsmodell som spänner över hela verksamheten och integrerar alla upptänkliga behov de olika delarna av verksamheten kan ha. Men det är ingen bra idé! Det är inte genomförbart att uppnå och kontinuerligt bevara total enighet över en större domän. Denna artikel beskriver varför. 

/Peter Tallungs, IRM, 2021-11-25

Att uppnå och behålla total enighet över en större domän är inte genomförbart och bör inte vara ett mål

Varför fungerar det inte att ha en enda informationsmodell för en verksamhet större än den allra minsta? För att förstå detta måste vi släppa tanken på att en verksamhet är som en maskin och i stället se en verksamhet som ett organiskt ekosystem. Att ha en enda informationsmodell för en mer omfattande verksamhet skulle fungera om verksamhetens alla delar hade helt och hållet samma mål och samma prioriteringar, det vill säga att verksamheten var som en maskin där alla kugghjulen gick i takt. Men så är inte fallet, så kan en verksamhet aldrig fungera, och det vore inte heller önskvärt. En verksamhet är något helt annat, ett nätverk av olika funktioner med olika fokus och prioriteringar. Egna agendor, om man vill hårdra det (även om många skulle studsa på de orden). Och så måste det vara. Det är något bra och något vi ska bejaka.

Denna, som det kan tyckas, spretighet är inte en brist på samordning utan det är en högst ändamålsenlig organisationsform i en föränderlig värld. Så har egentligen alla organisationer fungerat i alla tider, även om många managementkurser försöker påstå något annat. Varje affärsområde, funktion, avdelning, team och individ är specialiserad på en egen aspekt av verksamheten. Det kan vara ett produktområde, ett kundsegment, en aspekt av de produkter eller tjänster man producerar, någon leverantör eller något annat i omvärlden. Många delar av en verksamhet stödjer interna kunder och är helt koncentrerade på den uppgiften. Varje del av en organisation behöver, för att kunna reagera och verka effektivt inom sitt område, ett stort mått av självständigt agerande. Genom den mångfald som på detta sätt uppstår har organisationen förmågan att snabbt upptäcka och effektivt anpassa sig till nya möjligheter och hinder. En verksamhet är därmed inte som en maskin utan som ett ekosystem, en dynamisk och levande helhet, i ständigt omstöpande. Detta är inget nytt utan välkänt inom organisations- och managementteori, och har faktiskt varit så allt sedan den moderna organisationsteorin uppstod för ca hundra år sedan. Även om populära managementkurser och böcker har försökt tuta i oss motsatsen, att det är toppstyrning som är grejen.

I och med detta kan heller inte alla delar av verksamheten ha gemensamma begrepp och strukturer för allting. Inte ens förr, då de verksamheter vi modellerade var relativt enkla och statiska jämfört med idag, lyckades vi skapa allomspännande modell för en hel verksamhet. I varje fall om den skulle vara användbar, det vill säga ge mer än en mycket ytlig, överförenklad och ofta bedräglig bild.

En större verksamhet består av ett antal deldomäner som aldrig kan vara helt synkade

Jag brukar dra en liknelse: ”Om det vore en så bra idé att skapa en enda modell för en större verksamhet, varför har vi då inte en enda databas med en enda datastruktur som täcker alla behov i en verksamhet?”. När man hör detta tror jag att man tänker lite djupare och inser att olika delar av verksamheten har olika behov och olika prioriteringar. Och att det måste vara så om man inte ska låsa in hela verksamheten i något statiskt och extremt trögrörligt. Något som bara, i bästa fall, kan bli halvbra för de olika behoven.

Med andra ord; en större verksamhet måste ses som ett antal deldomäner som inte alltid går helt i takt och är helt synkade. Skillnaden mellan olika deldomäner beror mer på att olika delar av organisationen har olika historia, olika kulturer, ser olika saker som viktiga och har olika prioriteringar än av rena tekniska orsaker.

Förändring kräver erfarenhet och insikt

Förresten, om vi föreställer oss att vi efter långa och hårda mödor verkligen skulle lyckas ena en hel organisation runt en gemensam syn på allting av väsentlighet. Vad händer då när företaget köper upp ett annat företag, ingår ett branschsamarbete eller outsourcar några verksamhetsfunktioner? Jo, då blir vi tvungna att överge vår snygga enhetliga modell och gå tillbaka till att hantera att olika delar av verksamheten har olika modeller som vi behöver sy ihop på olika sätt.

Jag påstår inte att alla skillnader i begrepp och strukturer inom en och samma verksamhet är bra. Vissa diskrepanser mellan olika verksamhetsfunktioner är nödvändiga. Andra skillnader är kanske onödiga och till besvär, vilket kanske mest beror på att man har olika ursprung och inte har jobbat tillräckligt med att samordna och förenkla. De olikheterna behöver kanske i längden arbetas bort.

Men det är inte möjligt att utan den insikt som en längre tids arbete med modeller, data och funktioner ger oss, skilja på vad som bör få vara som det är mot vad som faktiskt bör förändras. Och för det som bör samordnas krävs det ännu mer insikt om alla olika aspekter om just denna verksamhet, för att förstå vad som krävs för att samordna och hur vi kan få det att hända. Insikt som vi får först efter ganska lång tid av praktiskt arbete inom domänen. Det första som krävs är i vilket fall att vi verkligen förstår de olika delarna av verksamheten, hur de fungerar och hur deras data ser ut och används. Det vill säga att vi modellerar de olika delarna av verksamheten som egna avgränsade domäner. Så hur vi än vänder oss måste vi börja med att modellera de olika delarna av en verksamhet med separata modeller. Det kommer vi inte ifrån. I alla fall inte i en hyfsat stor verksamhet.

Vi kan dock behöva en översiktlig horisontell modell

Den här artikeln bör inte tolkas som att jag påstår att man inte kan skapa en gemensam ”tunn” horisontell modell för en hel verksamhet, eller en hel bransch. ”Tunn” i meningen att den inte tränger så djupt i området, inte tar med alla förekommande begrepp utan tar ett mer ytligt grepp. Det kan man, och det gör vi ofta, men då för ett avgränsat syfte, till exempel för analys och uppföljning tvärs över en eller flera verksamheter. Det är till exempel grundbulten inom rapportering och Business Intelligence. Det kräver visserligen ett envist och långvarigt arbete, men går att göra. Men detta är något annat än att man i grunden förändrar de olika verksamhetsfunktionernas egna begrepp och sätt att fungera. Vad vi gör när vi tar fram en modell specifikt för rapportering, analys och uppföljning är att vi skapar ett gemensamt språk ett ”lingua franca” för de aspekter av en verksamhet som man har behov att analysera och följa upp. Det kan vara mycket men långtifrån allt. Och man förändrar då inte samtidigt de olika lokala begreppen och synsätten i de olika operativa delarna av verksamheten.

Varför vi ofta har svårt att acceptera

Vi har ofta svårt att acceptera den förbistring det innebär att olika delar av vår verksamhet har olika begrepp och olika syn på saker och ting. Det är förklarligt då det ju orsakar uppenbara problem. Olika begrepp och sätt att definiera dessa försvårar kommunikationen och är egentligen det enda som gör integration besvärlig. Det känns inte så elegant, utan mer som en fullösning. Det är detta som ligger bakom alla ambitiösa försök att ena en större domän under en gemensam modell. Men riskerna är många. Låt mig nämna några.

Risker med försök till en gemensam modell för en större domän

• För stort grepp. Man försöker åstadkomma för mycket på en gång, till exempel då man försöker ersätta flera äldre it-system med ett gemensamt nytt system. Projektet blir nedtyngt när arbetet med att koordinera så många olika intressenter överstiger förmågan och resurserna. Vi har sett många stora och spektakulära it-haverier på grund av detta genom åren.

Att bara öka på resurserna, det vill säga mer personal, är aldrig en lösning. Det bara ökar behovet av koordinering, och snart går all tid åt till möten. Projektet står helt stilla samtidigt som det bränner pengar och resurser i hög takt. Alla som varit med i större organisationer har nog upplevt detta. Som den kände projektledaren Fred Brooks sa redan på 70-talet: ”To add people to a late project makes it later” eller “Nine women can´t deliver a child in one month”.

Projekt måste hållas små för att lyckas. Stora projekt har en mycket liten chans att lyckas. Små projekt har däremot en bra track record. Men vad gör man då när uppgiften är stor? Måste man inte driva ett stort projekt då. Nej, hävdar jag bestämt. Stora uppgifter går alltid att dela ner i flera mindre självständiga som var och en levererar nytta i sig självt, menar jag. Även om många inte tror det.

• Modellen försöker få in alla behov i samma grova mall, vilket leder till att behoven tillfredsställs mycket fyrkantigt, om alls. Många kommer inte att kunna använda modellen utan tvingas ta fram egna modeller ändå.
• Modellen försöker verkligen tillgodose alla, vilket gör att den får många alternativ och specialfall, vilket gör den mycket svår och omständlig att använda.
• Arbetet med den stora modellen som ska lösa allt skymmer eller blockerar all annan viktig modellering. Man får då ofta höra: ”Nej, lägg inte ner något arbete på det, det kommer att lösas av den stora kommande (eller pågående) satsningen, som ska leverera om två år!”

Hur gör vi då?

Vi kan alltså inte komma ifrån att vi behöver hantera flera olika modeller i en större verksamhet, där varje modell faktiskt lever sitt eget liv, mer eller mindre.

Om vi helt lämnar tanken på en stor gemensam modell kommer vi att ha ett antal mindre omfattande modeller där var och en beskriver en del eller en aspekt av verksamheten. Utmaningen blir då att se till att de olika modeller vi har ska kunna samverka tillräckligt bra för att stödja gemensamma processer. Det handlar då mycket om förhandling och beslut mellan team.

Det är ett löpande arbete i skärningen mellan design (modellering) och politik. Med andra ord är vi inne på ett ämnesområde som är strategi vad gäller informationsarkitektur. De närmast följande artiklarna handlar om just detta. Då kommer jag att resonera om hur vi på ett mer realistiskt och hållbart sätt kan möta behovet av att få grepp om företeelser, begrepp och information i en verksamhet.