Hur modellen kan bli en plattform för det gemensamma lärandet

Verksamhetsutveckling är ett gemensamt lärande, i betydelsen utforskande. I detta lärande är våra modeller centrala verktyg. Att modellera innebär att utforska, och modellen manifesterar vår gemensamma förståelse av verksamheten. En modell fungerar ofta som en ögonblicksbild (”snapshot”) av vår aktuella uppfattning och förståelse verksamheten. Men lärande är en kontinuerlig process och en modell kan bära mer än just bara vår tillfälliga (miss-)förståelse. Våra modeller kan bli något mer än de är idag; de kan bli en plattform för fördjupat lärandet och insikt.  

/Peter Tallungs, IRM, 2025-01-16

Våra modeller kan få en större roll

Denna artikel bygger vidare på föregående artikel ”Modellernas viktiga roll i utvecklingen av en verksamhet, publicerad”, publicerad 2024-12-19, där jag beskrev hur vi kan göra modeller så att de bättre stödjer det gemensamma lärandet i verksamheten. I artikeln lyfte jag fram hur vi kan utveckla våra modeller med avseende på vad de visar, och hur de visar det de visar. Jag angav tre områden där jag tycker att vi kan bli bättre. De två första områdena handlade om att modellerna kan uttrycka mer (bli ”rikare”), och dessutom uttrycka det de uttrycker på ett bättre sätt (bättre gestaltning). Men det tredje området antydde jag bara i den artikeln. Jag skrev så här:

”Vi kan utveckla hur våra modeller inte bara blir till snapshots, inte bara uttrycker vår gemensamma förståelse just nu, utan också varför vi är där vi är i vår gemensamma förståelse, vad har hänt på vägen, vad är osäkert och vad händer just nu i vår utforskningsresa. Vilka beslut tog vi, när och varför. Vilka synsätt har vi förkastat på vägen och varför. På det sättet blir en modell mer än en modell, den blir en plattform för det gemensamma lärandet. Detta tredje område är värd en egen text.”

Nedan fokuserar jag på detta tredje område.

Från snapshot till plattform

En begränsning med de modeller vi vanligen gör är att de lever i ett vacuum, de saknar nästan hela sin kontext. De visar inte sitt sammanhang: de är utan en historia, utan alternativ, utan motivering, utan plats för dialog och värdering. På det sättet stödjer vi inte riktigt vårt gemensamma lärande. Ty detta gemensamma lärande är en process över tid. I verksamhetsutveckling behöver vi minnas hur vi kom fram till dagens förståelse: vilka antaganden vi gjorde och varför, vad vi lämnade på vägen, samt vilka antaganden vi gjort just nu och vilka frågeställningar vi har utestående och hur vi hanterar dessa. Vi behöver kunna dela denna kunskap med varandra – både med nuvarande och framtida medarbetare, samt omgivande intressenter – det är nyckeln till ett levande, gemensamt lärande.

Jag vill i denna artikel visa hur vi kan inkludera detta i våra modeller. Man kan då faktiskt säga att modellen blir mer än en modell, den blir en plattform för det gemensamma lärandet.

Varför är detta viktigt?

Verksamhetsutveckling är ingen ”one night stand”. Det handlar inte om att göra en förutbestämd förändring, för att sedan vara klar. Det handlar om en ständigt löpande utveckling av vår kunskap, där verksamheten i sig är avspeglingen av det vi vet och förstår just nu. I denna utveckling spelar organisationens gemensamma minne en central roll: Vad har hänt? Vad har vi gjort tidigare? Vad har vi inte gjort? Hur gick vi till väga? Vad har visat sig fungera? Vad har inte fungerat? Vilka beslut togs och varför? Var i denna process är vi just nu? Och allt detta inte bara i stort, utan i varje liten detalj, ”The devil is in the details”.

Det mänskliga minnet är kort och selektivt om det inte stöds av det som vi har skrivit ner.

Jag kan förstå att detta låter osannolikt eller utopiskt, att en modell ska kunna bli till en sådan plattform för lärande. Men med tre enkla och effektiva åtgärder kan vi komma mycket långt.

Tre åtgärder för att skapa en lärande plattform

Åtgärd 1: Versionshistorik

Spara varje version av modellen. Ofta behöver man göra ett omtag eller gå tillbaka för att återta något man tidigare tagit bort eller ersatt. Eller bara se efter vad det var man skippat. Om det är en större modell som är delad i många delar, till exempel en informationsmodell med flera ämnesområden, är det lämpligt att ha en egen versionshistorik per ämnesområde.

Observera att vi inte, som med versionshantering av programkod, behöver rendera en ny version för varje liten ändring. Vi är inte intresserade av de versioner som endast betyder en rättning av stavfel och liknade. Därför är ett vanligt automatiserat versionshanteringssystem inte det mest lämpade. Det räcker att spara din modell som en ny fil med aktuellt datum i namnet.

I de verksamheter där jag har jobbat brukade vi ha en filkatalog för äldre versioner och en separat för den aktuella, publicerade versionen. ”Publicerad” betydde bara att modellen (eller modelldelen) var tillgänglig för konsumtion av andra. Vi hade även en filkatalog för versioner under pågående arbete, ty om jag exempelvis var mitt i en halvfärdig ändring, ville jag vänta med att publicera den tills arbetet var klart.

Åtgärd 2: Ändringshistorik

För att förstå hur modellen utvecklats är det viktigt att dokumentera vad som ändrats, när det gjordes, varför och av vem. På detta sätt kan vi följa och minnas vad som hänt på vägen, och hitta tillbaka till äldre versioner.

Om det är en stor modell så är det nödvändigt att dela upp den i olika delar där var och en har en egen ändringshistorik.

Det är viktigt att denna historik finns i själva modelldokumentet och inte någon annanstans. Vi bör se historiken som en integrerad del av modellen.

Då jag gör en informationsmodell över en hel verksamhet har den kanske ett 30-tal ämnesområden. Då gör jag en separat fil för varje ämnesområde där vart och ett av dessa områden har sin egen ändringshistorik. Ett ämnesområde är ju utvalt som något som kan ses och förstås som en egen helhet.

Exempel på hur ändringshistorik (här benämnd ”Versionshistorik”) kan se ut i en informationsmodell. I detta fall är modellen så liten att historiken omfattar hela modellen. Men det blir ingen skillnad i hur det ser ut i det fall varje ämnesområde behöver en separat historik.

Åtgärd 3: Kommentera direkt i modellen

Gör plats för noteringar direkt i modellen. Inte på separat plats i modelldokumentet utan precis vid det modellelement som noteringen avser. Däremot behöver noteringarna vara tydligt separerade från själva modellinnehållet, lämpligen genom eget typsnitt och avvikande färg. Noteringarna behöver vara daterade och signerade.

En notering kan till exempel säga vilket beslut vi tagit, när det gjordes, av vem och varför. Den kan också säga vad som är oklart och idéer om vad vi bör göra för att ta oss vidare.

I mina informationsmodeller har jag alltid en strukturerad textdel för varje modellelement, det vill säga ämnesområde, entitet, attribut, relation och ibland uppräknat värde. (Se exempel i bilden nedan för attributet ”Organisationsnummer” i entiteten ”Organisation”) Där finns det avsedda utrymmen för normerat namn, förekommande synonymer, definition, beskrivning, regler, format etcetera. Var som helst kan man tillfoga kommentarer. Ibland blir det en serie av kommentarer, som bildar en dialog över tiden.

På det sättet kan vi hålla reda på hur en frågeställning utvecklats över tid, och var vi är just nu i vår dialog med olika intressenter.

Jag minns första gången jag började spränga in noteringar i modelldokumentet på detta sätt. Det var i en informationsmodell för ett systemutvecklingsprojekt. Reaktionerna från projektmedlemmarna blev som en uppenbarelse för mig. Vid varje projektmöte, liksom i andra typer av möten, uppstod en mängd frågeställningar kring olika detaljfrågor. En del frågeställningar utvecklades över tid till längre dialoger med många vändor fram och tillbaka. Man hade saknat en struktur för att hålla reda på allt detta. Det vanliga var annars att både stort och smått blandades ihop i olika mötesprotokoll, anteckningar i kollegieblock, lösa lappar och mejl.

Den informationsmodell jag tog fram för projektet blev den struktur som behövdes för att hålla reda på stort och smått. Den möjliggjorde detta genom att rymma löpande noteringar, signerade och daterade. Ty i stort sett allt som kom upp hade en naturlig plats i den struktur som informationsmodellen utgjorde. De frågor som kom upp och de beslut som togs rörde nästan alltid en viss entitet, ett visst attribut, eller en egenskap hos dessa såsom namn, definition, värdeförråd, regel mm. Till exempel kunde man i det avsnitt som hette ”Customer” följa alla frågeställningar som hade haft med kund att göra och hur de hade utvecklats över tiden. Om frågeställningen bara hade med definitionen av kund att göra fanns dessa noteringar i definitionsrutan för entiteten Customer. Om frågeställningen hade med regeln för hur vi satte kundstatus återfanns noteringen i rutan för definitionen för ”Customer Status”.

Jag har sedan dess fortsatt att göra på detta sätt och tycker att arbetssättet är värt att sprida. Jag tror inte att vi kan hitta en bättre struktur för att hantera den myriad av detaljfrågor som dyker upp under utvecklingen av en verksamhet.

Men syftet är större än att bara hantera frågeställningarna under ett enskilt projekt. Jag vill kunna se hur man kom fram till det man kom fram till, vad man gjorde och inte gjorde tidigare inom en verksamhetsfunktion. Annars är vi dömda till att varje nytt projekt måste börja från noll.

Exempel på hur signerade och daterade noteringar kan se ut i en informationsmodell och ibland växa ut till hela diskussionstrådar.

Bättre modeller!

Jag tror att våra modeller har en nyckelroll i det gemensamma lärande som verksamhets- och it-utveckling innebär. Låt oss använda deras fulla potential! Ett sätt att göra det är som jag visat i dessa två artiklar. Tror du att det kan fungera i er verksamhet? Har du egna idéer om hur vi kan utveckla våra modeller ytterligare? Hör av dig!