Varför en industrimodell är en dålig idé

Varför inte en standardmodell i stället för en hemmasnickrad? Varför uppfinna hjulet på nytt? Är det inte bättre med en etablerad och beprövad standard? 

Det finns många generella standard-informationsmodeller för olika branscher, så kallade industrimodeller. De täcker alla upptänkliga aspekter av en bransch och finns för i stort sett alla branscher, till exempel transport-, telekom-, finans- och försäkringsbranschen. De är internationella och generella, och tänkta att kunna anpassas till de specifika behov man kan tänkas ha i sin egen organisation. Varför inte anamma en sådan modell för vår verksamhet i stället för att ta fram en egen?  

Lockelsen hos en industrimodell

I många organisationer har man sett det som en bra idé att införa en industrimodell. De fördelar man tänker sig är följande

  • Slipper besväret med att ta fram en själv
  • Får tillgång till all den kunskap och erfarenhet som finns inarbetad i modellen
  • Får kontrollerade och exakta begrepp
  • Det blir lättare att utbyta information med andra i branschen.
    (Förutsatt att modellen är accepterad av tillräckligt många.)

Ofta är man frustrerad över alla försök som gjorts med att få till gemensamma begrepp i organisationen. Då ser en redan färdig modell ut som en enkel lösning. Man påhejas av konsultföretag som har som affärsidé att erbjuda en industrimodell, och konsulter för att hjälpa till att implementera. Varför bygga något själv när det finns en färdig standard? Man förstår förstås att det ändå blir ett arbete med att anpassa sig till standarden och att man ibland även måste göra avsteg från själva standarden för sina egna specifika behov. Konsultföretagen brukar nämna att det brukar röra sig om runt tjugo procent egna anpassningar.

Allt verkar bra. Det känns tryggt att luta sig mot något etablerat. Därför har också många organisationer valt den vägen.

Det finns gott om misslyckanden

I själva verket är den vägen allt annat än trygg. Alla sådana satsningar jag känner till har misslyckats. I bästa fall har de runnit ut i sanden efter ett tag, då satsningen har tappat fart och inte visat sig ge den nytta man trodde. Ibland har satsningen ändå fortsatt, eftersom projekt har en tendens att bara fortsätta fastän de inte fungerar.

I många fall har industrimodellen då satt sin prägel på begreppen och språket i verksamheten. Men inte på ett bra sätt. Tvärtom har man då skadat organisationens möjlighet att få till en gemensam förståelse och ett gemensamt språk. Detta eftersom arbetet har varit mer inriktat på att matcha ihop företeelserna i domänen med modellen, än att verkligen skapa en förståelse av verksamheten.

Organisationen har då inte bara slösat pengar, kraft och tid samt missat möjligheter utan också hamnat i ett betydligt sämre läge än innan. Man har då förstört något av det viktigaste man har, de gemensamma begreppen och det gemensamma språket.

Ibland hör man förklaringen att de industrimodeller som finns än så länge är för dåliga, vilket inte är sant. Eller att de är för generella, vilket är sant, men den förklaringen missar ändå själva kärnproblemet. Jag vill nu försöka förklara varför hela tanken med att köpa in en industrimodell är en dålig idé.

Första skälet: Det är vägen som är mödan värd

Som jag beskrivit i min tidigare artikel, ”Om modeller på papper och modeller i huvudet”, så har modellen i sig inget värde så länge den inte representerar en gemensam förståelse. Det är modellering som skapar en gemensam förståelse och ett gemensamt språk. Det är detta som är det verkliga värdet. Det finns ingen smitväg förbi detta.

Modellen i sig är vilseledande och skadlig om den inte representerar en gemensam förståelse som är tillräckligt krispig och genomtänkt. Och det kan den bara bli genom att vi verksamhets- och it-kunniga arbetat fram den själva, tillsammans.

Det är förstås möjligt att använda en industrimodell som referens och inspiration, något att plocka begrepp, benämningar och mönster från när de passar vår förståelse av vår domän. Men det är något helt annat än att implementera industrimodellen som vår egen. Vi som modellerar har alltid olika källor för inspiration, det är inget nytt och det är inte det vi pratar om här.

När man inför en industrimodell för sin verksamhet brukar det gå till så här. Man försöker matcha ihop de företeelser och begrepp man hittar i den egna verksamheten, med begrepp och mönster i standardmodellen. Men man saknar då den djupa förståelse för de egna företeelserna som bara en modellering av den egna verksamheten kan ge. Matchningen blir ytlig, grov och skev.

Andra skälet: En modell har alltid en viss kontext

Det som ofta glöms bort är att en modell aldrig är universell. En modell är framtagen för ett visst sammanhang, det vi kallar för kontext. Kontext kan vara smalare eller bredare, utefter olika dimensioner. En modell för en viss verksamhet passar sällan en annan verksamhet trots att de är i samma bransch. Om man håller sig på en mycket generell nivå passar den förstås, men då är ju kontexten inte längre samma. Kontexten är då mer allmän, den som är gemensam för verksamheterna. Därmed kan man naturligtvis skapa en gemensam standard för en hel bransch. Men då avgränsar vi oss till just det som ska delas mellan organisationerna, det som är en delad kontext, inte hela deras respektive interna världsbild.

Vi kan förstås matcha ihop begrepp för två eller flera olika verksamheter, det gör vi ju ofta som informationsmodellerare. Det gör vi genom att först skaffa oss en djup förståelse för respektive verksamhet, det vill säga att vi först behöver modellera respektive verksamhets begreppsvärld och först därefter kan vi ta fram den gemensamma modellen.

En industrimodell är extremt generell, eftersom den ska passa alla varianter av verksamheter i branschen i fråga, i alla länder med olika lagstiftning, kultur och språk. Det blir ”one size fits all” eller snarare ”one size fits no one”.

Resultatet

Resultatet av en satsning på att implementera en industrimodell för sin verksamhet blir att hopmatchningen mellan de egna företeelserna och begreppen i industrimodellen blir slarvig och skev. Begreppen blir för vida eller smala. Namnen blir missvisande. Man har helt enkelt inte tillämpat det enda arbetssätt som kan skapa den gemensamma förståelsen. Med andra ord: man har inte modellerat. I min tidigare artikel ”Om modeller på papper och modeller i huvudet” förklarar jag vikten av att bygga gemensam förståelse i en verksamhet och ett gemensamt språk som speglar den förståelsen.

Detta gör att man, om man inte ger upp tidigare, får en begreppsvärld och ett språk som blir trubbigt, skevt och missvisande. Det blir motsatsen till vad man behöver uppnå. I stället för att bygga en gemensam förståelse och ett krispigt språk så fryser man förståelsen och förstör språket. Och det är något som skadar en verksamhet för lång tid, ofta decennier. Jag har sett verksamheter där man inte kan använda allmänna termer som ”transaction”, ”agreement” och ”service” eftersom de har låsts fast i alldeles för specifika och missvisande betydelser. Jag har sett det hända gång på gång.

Specifika standarder

Det betyder inte att standarder är en dålig idé rent allmänt. Utan standarder kan vi inte kommunicera effektivt mellan organisationer. Men då handlar det om specifika mycket smalare standarder för vissa typer av data. Till exempel hur en order ser ut inom en viss bransch, eller hur ekonomiska data rapporteras. Vanligen har de mognat fram under många år. Och det handlar då aldrig om hur en hel bransch fungerar, tvärs över alla företeelser som hanteras i de respektive verksamheterna.

Och en sådan standard ersätter aldrig vår interna modell. Den interna modellen är tvärtom en förutsättning för att vi ska kunna matcha våra egna data mot standarden.

Orsaken till övertron på industrimodeller

Jag tror att det finns flera samverkande orsaker till föreställningen att en industrimodell kan ersätta en egen modell:

  1. Fokusering på konkret synligt resultat
    En tendens att fokusera på det synliga yttre resultatet i ställe för på det vi verkligen vill ha. Man ser bara själva modellen som det viktiga, utan att förstå att den inte har något värde om den inte representerar en gemensam förståelse och ett gemensamt språk i verksamheten.
  2. Saknad förståelse av kontextens betydelse
    Man har inte har förstått att en modell alltid avser en viss kontext, det vill säga hela det sammanhang där den är giltig. Det kan vara en bred kontext, men ändå alltid en viss kontext. En modell för en hel bransch kan aldrig vara en modell för en specifik verksamhet. En modell kan inte passa överallt och ändå vara tillräckligt specifik i alla lägen.
  3. Oseriösa leverantörer
    Leverantörer säljer in industrimodeller som om det vore en beprövad och framgångsrik lösning. Leverantörernas säljare har dock inte den kunskap som krävs för att ge bra råd.
  4. Saknad förståelse hos it-ledningar
    It-ledningar har vanligen inte den förståelse för informationsmodellering som krävs för att rätt bedöma säljarnas utsagor.
  5. Akuta behov
    Man har ofta misslyckats med tidigare försök att skapa en gemensam modell, och behovet blir alltmer trängande.
  6. Invändningar framstår som flummiga
    Det är svårt att argumentera för vad modellering egentligen handlar om och hur den bör bedrivas. Det låter flummigt och svårt och det kräver erfarenhet och kunskap som man saknar. Det alternativet står sig slätt mot ett mer konkret alternativ, att bara köpa in något så är problemet snart löst.

Vad kan vi göra?

Vad kan vi göra åt det? Ja, vi som är verksamma i branschen, skriver och undervisar om modellering har uppenbarligen inte lyckats förmedla en förståelse av vad vi egentligen håller på med. Men det är aldrig för sent att göra rätt. Låt oss hjälpas åt. Det här är i mitt bidrag.

Har du varit med om att införa en industrimodell? Hur gick det? Har du andra erfarenheter? Kommentarer är välkomna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 1 april. Då handlar det om skillnaden mellan data och information.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Om modeller på papper och modeller i huvudet

Med ”modell” i ”Informationsmodell” menar vi vanligen en konkret gestaltning av något. Boxar och linjer på ett papper eller liknande. Det jag gestaltar är det jag har i huvudet, en mental modell, de vill säga min föreställning av hur saker och ting hänger ihop. För att rätt förstå vad vi egentligen håller på med då vi modellerar behöver vi först prata om vad en mental modell är.

Det här är kanske den viktigaste text jag skrivit. Jag försöker förmedla det jag menar är den springande punkten i allt modelleringsarbete.

Mentala modeller

En mental modell är min uppfattning om en viss företeelse eller ett system av flera sammanhängande företeelser. Vad de har för egenskaper, hur de hänger ihop och hur de fungerar.

För oss människor är de mentala modeller vi har i huvudet helt grundläggande för oss. Det är på det sättet vi har en uppfattning om saker och ting över huvud taget. Vi har mentala modeller för allt vi kan föreställa oss och allt vi därmed kan tänka något om och hantera. Om hur tvättmaskinen fungerar, vad min partner gillar för mat och hur man hittar i kvarteret. Från abstrakta saker som hur det politiska systemet hänger ihop till konkreta saker som hur Eiffeltornet ser ut. Och kanske till och med saker som hur den tyska 1800-talsromantiken har satt spår i dagens litteratur. Varje gång jag tänker på, pratar om, medvetet förnimmer eller hanterar något använder jag mig av en mental modell av företeelsen.

Jag har med tiden, alltifrån jag föddes, ja förmodligen redan i livmodern, bit för bit byggt upp mentala modeller av min omvärld. När jag lär mig något, antingen genom erfarenhet, eller teoretiskt, så innebär det att jag prövar, verifierar och falsifierar, bygger upp och bygger om min egen mentala modell av företeelserna i fråga.

En mental modell kan aldrig vara en exakt avbildning av något. Den är alltid en abstraktion, det vill säga en förenkling. Den lyfter fram och renodlar vissa egenskaper och ignorerar andra. Det är därför meningslöst att fundera på om den är sann eller falsk. Den har både styrkor och svagheter. Den kan bara vara mer eller mindre ändamålsenlig, de vill säga huruvida den passar det jag behöver använda den till. Då kan den vara allt från helt värdelös och missledande till högst adekvat. Hur den blir beror på det sammanhang jag befann mig i när jag skapade och utvecklade den. Vad som var framträdande då, i det sammanhanget. Samt av mina sinnen och mentala förmåga.

Den modell jag har i huvudet om något styr hur jag kan tänka om detta något. Den både möjliggör och hindrar. Mina mentala modeller blir min världsbild, på gott och ont. Vi formar våra modeller. Sedan formar de oss. 

Modellering

För att kunna arbeta med något, inte alltför enkelt, låt oss säga de företeelser som en verksamhet hanterar, behöver jag forska och bygga upp en mental modell av dessa företeelser, vilka egenskaper som är relevanta och hur företeelserna relaterar till varandra. Det är där modellering kommer in. För att utforska något och effektivt bygga upp en mental modell av detta något, hjälper det att jag modellerar. Det vill säga skapar mig någon form av konkret representation av företeelserna för att hålla reda på allt det jag ser som relevant och tydligare kunna se hur allt detta hänger ihop. Jag gestaltar således min mentala modell, genom att modellera. Jag har normalt inte bilden klar i huvudet när jag ritar den. Det går inte till så att jag först har bilden i huvudet och sedan bara ritar den. När jag ritar boxar och relationer, delar in saker i ämnesområden, namnsätter och definierar företeelser, egenskaper och relationer så blir jag tvungen att bli tydlig och konsekvent.  

Ritandet hjälper mig att se saker och att formulera de frågor jag behöver besvara. På så sätt bygger jag också upp min mentala modell genom att modellera. Modellerandet blir ett mycket kraftfullt tankeverktyg. Det är ping-pong-matchen mellan vad som finns i mitt huvud och på papperet som är själva grejen.

Men hittills har vi bara berört förhållandet mellan modellen som finns i mitt huvud och dess gestaltning på papper eller liknande. Vanligen är vi fler personer inblandade i ett modelleringsarbete. Och då blir modellerandet än viktigare.

Modellering som social företeelse

Min mentala modell av något är förmodligen aldrig precis samma som din mentala modell av samma sak. I bästa fall, om vi båda är i ett och samma sammanhang och har någorlunda samma syfte, stämmer de tillräckligt mycket med varandra för att vi ska kunna resonera oss fram om saker och ting. Det är i varje fall målet med att vi modellerar gemensamt. När vi modellerar tillsammans blir modellen ett socialt tankeverktyg, en plattform för att tänka tillsammans. Våra olika mentala modeller möts och påverkar varandra, vår kollektiva intelligens skapar så småningom en gemensam bild. Eller i varje fall tillräckligt överensstämmande för att vår dialog ska bli meningsfull. Vi koordinerar våra respektive mentala modeller. Den modell vi då skapar blir med alla sina begrepp, samband och regler ett gemensamt domänspecifikt språk.

Mitt språk är min värld

Det här med språk är viktigare än man kanske tror. Det är faktiskt så att det vi inte har exakta begrepp för blir svåra att över huvud taget uppfatta och tänka på. Min fru kan mycket om växter och fåglar. Efter alla skogsvandringar med henne, där jag frågat och fått svar, uppfattar jag nu fler växter och fåglar. Ja, jag ser och upplever mer i skog och mark än jag gjorde tidigare.

Så ett språk är inte bara något för att kommunicera med varandra. Språk är också något vi använder för att tänka med, även som individer. Det vi har begrepp för kan vi föreställa oss. ”Mitt språks gränser är mitt universums gränser.” sade filosofen Wittgenstein.

Modellen är ett språk, och där är namn och definitioner viktiga beståndsdelar. Vi kan egentligen inte ha en gemensam förståelse utan att också ha gemensamma namn på saker och ting, så att vi inte pratar förbi varandra. Modellen hjälper oss med detta, att skapa gemensamma begrepp, med definitioner och benämningar.

Informationsmodellen som plattform för det gemensamma utforskandet av domänen och bärare av det gemensamma språket

På så sätt blir den gestaltade modellen, det vill säga den modell vi har på papper eller liknande, inte bara ett tankeverktyg, utan den kopplar också ihop våra hjärnor på ett mycket effektivt sätt. Den gestaltade modellen blir, rätt använd, plattformen för det gemensamma utforskandet av domänen och utvecklingen av det domänspecifika språket. Att i möjligaste mån ha samma mentala modell och att den är ändamålsenlig för vad vi vill göra är helt grundläggande för att vi ska kunna hantera och utveckla något tillsammans. 

Informationsmodellens värde

Nu till det viktiga. Informationsmodellen får sitt värde av att den korresponderar med vad vi har gemensamt i våra huvuden. Den har egentligen inget värde i sig själv, fristående från vår gemensamma förståelse. Den är en representation av, och ett språk för, denna vår gemensamma förståelse. Processen är lika viktig som resultatet.

Det är processen, själva modellerandet, som mer än något annat, sammanlänkar våra hjärnor. Sedan är informationsmodellen den som även fortsatt skapar en permanens i förståelsen, språket och lärandet. Vi kan ta vid där vi slutade även efter ett uppehåll. Vi kan också lättare få upp en ny deltagare på banan.

Allt det här kan kanske tyckas självklart. Men det är något det inte brukar pratas om. Det kanske känns för flummigt? Jag är ganska övertygad om att det är få som verkligen har förstått detta på djupet och vad det betyder för oss. Trots att det är själva kärnan inom allt det vi håller på med som informationsarkitekter och som verksamhetsarkitekter. Jag är övertygad om att det är denna bristande förståelse som ligger bakom fatala missförstånd inom vårt område. Till exempel tron att vi kan köpa en standardmodell för vår verksamhet i stället för att själva ta fram en.  Mer om detta i nästa artikel.

Vad tänker du kring detta? Kommentarer är välkomna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 25 mars. Peter Tallungs utvecklar sina tankar kring informationsmodeller och jämför industrimodellen med den hemmasnickrade modellen Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

En informationsmodell istället för flera

Vi behöver inte separata konceptuella, logiska och fysiska modeller. Vi kan kombinera perspektiven i en och samma modell och därmed få ett gemensamt språk och en gemensam förståelse tvärs över verksamhet och it.

/Peter Tallungs, IRM, 2021-03-11

Inom informationsmodellering har man vanligtvis delat in modeller efter vilken aspekt av en datadomän de beskriver. Man har tänkt sig att samma domän behöver beskrivas på olika sätt för olika intressenter. Ofta har man då skilt mellan konceptuella, logiska och fysiska modeller. Det finns andra indelningar och benämningar, men tanken är i grunden densamma. 

  • Konceptuell modell En översiktlig konceptuell beskrivning på hög nivå, för att diskutera med verksamhetsfolk. Den konceptuella modellen avbildar ”verkligheten” eller rättare sagt en översikt av de företeelser som verksamheten behöver hantera. Då är inte detaljer viktiga menar man.
  • Logisk modell För att ställa krav på vilka data som behöver hanteras behöver man en logisk datamodell. Det är en modell som visar hur till exempel en databasstruktur är designad och visar all data fullständiga i alla sina detaljer. Dock innan man gjort tekniska anpassningar och prestandaoptimeringar.
  • Fysisk modell För att visa exakt hur man implementerat en databas på en specifik plattform behöver man en fysisk modell. Den visar precis hur databasen ser ut.

Tanken är (åtminstone som den ofta har framställts) att man arbetar mer eller mindre sekventiellt när man designar en databas eller någon annan datahantering. Först tar man fram den konceptuella modellen och sedan den logiska modellen som en detaljering av den konceptuella. Till sist tas den fysiska modellen fram med de avsteg man gjort för den logiska modellen av tekniska skäl. Alla tre modeller ska sedan leva vidare tillsammans. Ty alla tre perspektiven på samma datamängd behöver fortleva kontinuerligt.

Dessutom behöver man kunna spåra alla samband mellan dessa, det vill säga att man på något sätt behöver bevara alla kopplingar mellan dessa modeller. När något förändras behöver den eventuella påverkan mellan modellerna hanteras.

Problemen med separata modeller för samma domän

Synsättet ser bra ut i teorin, men jag menar att det för det första hindrar möjligheten att skapa ett gemensamt synsätt och en förståelse tvärs över it och verksamhet, och för det andra att det är ogörligt i praktiken att ha tre olika modeller för olika perspektiv på samma sak och dessutom kopplingar däremellan.

Anledningen till att vi över huvud taget skapar en modell är för att alla inblandade ska få samma gemensamma karta i huvudet, samma spelplan för att bygga vårt forskande och lärande runt. En modell ska vara vårt gemensamma språk oavsett om man är systemutvecklare eller verksamhetsexpert. När alla intressenter har olika kartor i huvudet slöar det ner all kommunikation. Kanske inte om de bara skulle röra sig om enstaka skillnader, men små skillnader på många ställen ger en kognitiv och kommunikativ friktion som kraftigt hämmar den samverkan som vi behöver.

Jag har aldrig i praktiken sett att det fungerat med att parallellt hantera och arbeta med tre olika modeller över samma domän på detta sätt. Jag vill argumentera för ett annat synsätt och ett annat sätt att lösa att vi faktiskt behöver hantera flera perspektiv samtidigt. Vi kan göra det i en och samma modell. Det går alldeles utmärkt att förena alla tre perspektiven i en och samma modell.

Jag påstår inte att alla andra typer av modeller över en verksamhet kan ersättas av en enda. Det finns perspektiv som verkligen behöver beskrivas separat. Vi kan till exempel inte trycka in en funktionskarta eller en processmodell i en informationsmodell. Men vi kan faktiskt hantera de olika perspektiven för informationsmodellering i samma modell. Jag har gjort så i många år och jag visar gärna hur, men det får bli i senare artiklar. I denna artikel ger jag en första inblick i tankesättet.

Men först, låt mig ta stöd i min argumentation från två olika håll. Det handlar om inflytelserika tankeriktningar vad gäller modellering och informationsdesign inom två delvis andra områden. De har båda varit viktiga inspirationskällor för mig.

Inspiration 1: Modellering inom programvarudesign – Domändriven design

Det finns en filosofi inom modern programvarudesign som heter ”domändriven design” (förkortat DDD), beskriven i boken Domain-Driven Design av Eric Evans. Den handlar om hur man designar den del av programkoden som representerar domänen i fråga. Det vill säga där vi har klasser som heter saker som ”Customer”, ”Product”, ”Product type”, ”Order” etcetera. Den delen av programkoden är en domänmodell, det vill säga en modell av det som verksamheten behöver hantera med hjälp av programvaran i fråga. Författaren hävdar att när man designar den delen av programkoden bör den i största möjliga utsträckning vara identisk med den mentala modell som man vill att alla inblandade, både från it och verksamhet, ska ha i huvudet. Det innebär att när man designar domänmodellen i programvaran, designar man samtidigt den mentala modell som verksamheten behöver. Det vill säga att domänmodellen i programkoden verkligen blir det gemensamma språket, tvärs över verksamhet och it. De konceptuella och logiska modellerna (vad folk i verksamheten har i huvudet) blir samma som den fysiska modellen (hur programkoden som representerar detta är strukturerad och namngiven).

Detta är i skarp kontrast till en vanlig tidigare uppfattning bland systemutvecklare där man ofta såg det som att koden gjorde man på sitt eget sätt (den fysiska modellen), sedan översatte man fram och tillbaka i användargränssnitten till hur användarna behövde se det hela (den konceptuella modellen).

Domändriven design är allmänt accepterat inom systemutveckling idag, även om tankesättet kanske inte helt och hållet har nått ut till alla systemutvecklare i sin fulla innebörd.

Boken Domain-Driven Design är även i övrigt en av mina största inspirationskällor då det gäller informationsmodellering (trots att den egentligen handlar om programvarudesign). Det är en bok jag varmt vill rekommendera till alla som arbetar med informationsmodellering. Eric Evans har en förmåga att förmedla djupa klokheter om modellering.

Det finns dock några allvarliga begränsningar med idéerna inom domändriven design:

  1. Domänmodellen är manifesterad i programkoden och därmed otillgänglig för andra än programmerare och egentligen bara de programmerare som arbetar med just den applikationen. Vi behöver en gestaltning av modellen som är tillgänglig för alla.
  2. Domänmodellen är endast uttryckt i programkod, vilket inte ger samma överblick som en grafisk beskrivning. Vi behöver en gestaltning av modellen som både ger visuell överblick och detaljerade definitioner och beskrivningar.
  3. Domänmodellen omfattar endast en enda applikation. Vanligen har vi i en verksamhet att göra med många samverkande applikationer, databaser, integrationer med mera. Vi behöver modeller som sträcker sig över flera samverkande applikationer.

Det är här jag menar att informationsmodellen kommer in. Vi kan låta den vara en domänmodell för hela den domän vi behöver hantera, tillgänglig för alla.

Inspiration 2: Informationsdesign – Multidimensionella grafer

Edward Tufte

Informationsdesignern Edward Tufte har betytt mycket för hur synen på hur man designar grafer och kartor för att förmedla data, information och kunskap ser ut idag. Han argumenterar, med många olika exempel, att alla riktigt intressanta grafer sammanför flera olika typer av kunskap eller information. Han kallar det för multidimensionella grafer. Tänk bara på vanliga geografiska kartor som sammanför naturgeografi (sjöar, höjdkurvor, naturtyper), politisk geografi (landskap, län, kommuner) och transportinfrastruktur (vägar, järnvägar, färjelinjer) i samma karta. Tufte har skrivit många böcker i ämnet men beskriver just detta bäst i boken Beautiful Evidence.

Hur hanterar vi då alla tre perspektiv i en och samma modell?

Okej, säger du. Så om vi översätter detta till databasdesign så behöver strukturen i databasen så mycket som möjligt stämma överens med hur vi tror att verksamheten behöver se på sakerna? Men i verkligheten har vi inte så ofta lyxen att designa en ny databas. Oftast finns det redan en databas, där saker heter som de gör och är strukturerade som de är, ofta med inkonsekvent och inte så bra namngivning och struktur. Då måste jag väl ha två olika modeller? Dels en fysisk som visar hur det ser ut i databasen samt en konceptuell som visar hur vi tror att verksamhetens personer behöver se på sakerna i verkligheten? Det vill säga att vi både skapar ett korrekt, tydligt och användbart gemensamt språk för verksamheten och samtidigt dokumenterar hur det ser ut rent fysiskt i datalagringen?

Ja, det stämmer att vi behöver beskriva och hantera de två perspektiven, fast det betyder inte att vi rent fysiskt behöver två informationsmodeller. Vi kan hantera båda perspektiven i samma modell. Det underlättar mycket om vi på detta sätt kan koppla ihop vad verksamheten faktisk hanterar med hur informationen om detta är strukturerad.

Jag går tillväga på följande sätt. Den informationsmodell jag tar fram är i grunden konceptuell. Det vill säga att den struktur jag visar och de namn jag använder är det vi kommer överens om som det mest korrekta, användbara och tydliga sättet att se på och benämna företeelserna och deras egenskaper och relationer. Så om jag hittar en tabell i en databas som heter ”Customer”, men jag inser att det inte bara finns kunder i denna utan även leverantörer, så skapar jag två entiteter för dessa. Fast jag anger också att de båda återfinns i tabellen ”Customer”. Om jag sedan hittar att någon har lagt kundens personnummer i den kolumn som heter ”PhoneNbr2” (jo det har faktiskt hänt!) så skriver jag in ett attribut i min modell som heter ”Personnummer” men anger att den ligger i kolumnen  ”PhoneNbr2”.

På så sätt blir modellen alltså i grunden konceptuell, och blir med tiden det gemensamma språket för verksamheten. Men den har också krokar ner i var och hur informationen om dessa företeelser ligger lagrade. Den blir på detta sätt en modell som verkligen kan bygga ihop de två perspektiven.

Synonymer

I verkligheten har ett och samma informationsobjekt ofta fler än två namn. Det kan heta olika saker i databasen, i programkoden, i API-er, i filer och i Data Warehouse och i rapporter. Det hanterar jag i informationsmodellen som synonymer, att en och samma egenskap heter olika saker i olika sammanhang. Det spelar mindre roll om det är av bra eller dåliga anledningar, det måste i varje fall hanteras. Då redogör jag i informationsmodellen för vilka olika synonymer som förekommer och i vilka sammanhang de förekommer. På det sättet får vi spårbarhet åt alla håll.

Informationstätheten

Det hävdas ofta att vi inte ska ha för mycket information i en och samma modell. Överblicken blir lidande. Allt flyter ihop till en enda röra. Men då kommer vi in på området grafisk gestaltning. Vi kan bli mycket mycket bättre på hur vi ritar. Vi kan få både överblick, tydlighet och detaljrikedom i samma graf om vi gör på rätt sätt. Det handlar om disposition, struktur, gråskalor, färger, linjebredder med mera. Det är ett område som är sorgligt eftersatt inom informationsmodellering. Där finns mycket att lära från andra discipliner som behöver kommunicera grafiskt, som byggnadsarkitektur, grafisk design, informationsdesign, ritteknik, kartritning. Jag planerar att visa hur i artiklar framöver.

Skillnad på modell och diagram

När vi resonerar om hur vi gestaltar modeller behöver vi skilja på ”modell” och ”diagram”. En och samma modell kan vara gestaltad i flera diagram. Jag brukar, när jag tar fram lite mer omfattande modeller, göra ett översiktsdiagram över hela modellen. Där har jag med alla ämnesområden och entiteter, men inga attribut, och bara de viktigaste relationerna. Det blir som en översiktskarta. Sedan tar jag fram flera detaljerade diagram, ett för varje ämnesområde eller sammanhållen grupp av ämnesområden. På så sätt får jag både en ”ut-zoomad” vy och en ”in-zoomad” vy på en och samma modell. I varje diagram samsas det logiska perspektivet (vad data representerar i verksamheten) med det fysiska (hur data lagras och transporteras).

Kanske är det hopblandningen av begreppen ”modell” och ”diagram” som har skapat behovet av att vilja skilja ut vad man kallar för en konceptuell modell från en logisk modell? Det vill säga att behovet av att ha olika detaljeringsgrad vid olika tillfällen har tvingat fram två separata modeller?

Men vad är då villkoret för att flera diagram ska kunna sägas vara samma modell? Jo, de måste beskriva samma domän och ha samma kontext (det vill säga sammanhang) och vara konsistenta (de vill säga inte säga emot varandra).

Vi behöver ju kunna använda alla uttrycksmedel som står oss till buds då vi modellerar. Då måste vi lämna begränsningen att en gestaltning av en modell består av endast ett diagram. Den kan bestå av flera diagram och flera olika typer av diagram, den kan bestå av diagram och text integrerat.
Mer om detta beskriver jag i artiklar framöver.

Att skapa en världsbild

På det här sättet kan vi få en och samma modell att avbilda inte bara informationen i sig utan även det som informationen handlar om, de företeelserna som informationen representerar. Vi får en och samma verklighetsbild, som omfattar både vad och hur saker hanteras i verksamheten samt hur detta representeras i informationssystemen, inklusive de diskrepanser vi tyvärr kan ha däremellan.

På så sätt riskerar vi inte att få det som vi så ofta ser i våra verksamheter, två grupper av individer med olika världsbild. En på it-sidan som ser ”verkligheten”, det vill säga hur det verkligen ser ut i databaserna. Och en annan på verksamhetsidan som också ser ”verkligheten”, och då en annan verklighet, det vill säga hur det fungerar i verksamheten utanför it.

Det är dags att vi börjar se det som en och samma verklighet. It-systemen är idag en integrerad del av verksamheten, inte som tidigare bara ett ”stöd” till verksamheten.  

Modellen blir ett gemensamt språk för alla parter. Detta är i min mening det mest intressanta och kraftfulla med informationsmodellering. Som modellerare skapar du faktiskt, tillsammans med de berörda, en gemensam världsbild över allt det som behöver hanteras i en verksamhet. Det är ett stort ansvar med stora möjligheter om vi tar det ansvaret på allvar. Liksom stora missade möjligheter om vi inte gör vårt bästa, utan bara fortsätter på samma sätt som vi en gång lärt oss.

Det skulle vara intressant att få höra dina synpunkter på detta. Kommentarer är välkomna.

/Peter Tallungs /IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 18 mars. Då handlar det om modeller på papper och modeller i huvudet.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Data management

De data som en organisation äger är en värdefull resurs. Hur kan vi bygga en förmåga att ta hand om denna resurs?

Data är inte bara en bas i den dagliga operativa verksamheten, data används också för att monitorerna, analysera, styra och förbättra verksamheten. Ofta kan data ge innehåll till nya tjänster för kunder och andra intressenter. Det finns många exempel på datadrivna tjänster som skapar helt nya affärsmöjligheter.

Men precis som andra resurser behöver dataresursen tas om hand. För detta behöver vi ett strukturerat arbetssätt. Vi behöver ägarskap och förvaltningsansvar på olika ställen i organisationen. Tillika behöver vi en stödfunktion som stödjer och utvecklar arbetssättet.

Vi kan ju jämföra med hur vi gör med andra resurser. För personal har vi en personalavdelning. För ekonomiska värden har vi en ekonomiavdelning. För informationsteknik har vi en it-funktion. För varje slag av resurs har vi vanligen någon form av stödfunktion. Men var har vi den funktion som stödjer vårdandet och utvecklandet av organisationens data? Om den inte finns i vår organisation idag behöver vi på något sätt skapa den, vilket innebär att bygga kompetens, kultur och arbetssätt för data management.

Jo, men borde inte det vara it-avdelningens ansvar, kanske du invänder? Jovisst, det kan man tycka. Men det sker inte idag, i alla fall inte i de organisationer jag har insikt i. Ansvaret faller mellan stolarna. It-folket tycker att det är verksamhetens data och därmed verksamhetsfolkets ansvar. Verksamhetsfolket å sin sida har svårt att på egen hand verkligen ta hand om data på ett bra sätt.
Det är en resurs de har otillräcklig insikt i då den ligger dold för dem i databaser och flyttas runt och misshandlas i en spaghetti av integrationer.

Verksamheten har också sällan den kompetens som behövs för att hantera data. Det har visserligen inte alltid it-folket heller, annars skulle det inte se ut som det gör på många ställen idag. Men it-sidan har åtminstone de grundläggande förutsättningarna och verktygen för att ta itu med uppgiften om de bara ville ta det ansvaret.

I vilket fall som helst, var ansvaret än bör placeras, behöver vi få ett grepp om vad det innebär att ta hand om data. Först därefter kan vi bygga en förmåga för detta, med lämpliga kompetenser.

För övrigt är det hög tid att it-sidan inte ser sig som en servicebyrå till verksamheten. Man bör se sig som en lika tätt integrerad del av verksamheten som övriga stödfunktioner. Som till exempel ekonomi- eller personalavdelningarna. Men det är en annan frågeställning som vi får ta en annan gång.

Masterdata

Jag har tidigare skrivit om att det är lämpligt att skilja på masterdata, global referensdata och händelsedata, i artikeln ”Det är skillnad på data och data”. Vi vill förstås få koll på all data. Arbetssättet är ungefär lika för alla typer av data men det finns skäl att prioritera masterdata. Första skälet är att masterdata är grundläggande för övriga data. Har du inte koll på masterdata går det inte att få koll på övriga data. Har du koll på masterdata blir det relativt enkelt att få koll på resten.

Det andra skälet är att det är mer oklart var ansvaret för varje typ av masterdata ska ligga än för andra typer av data. Det är en delad resurs och är därmed utsatt för de krafter som inom ekonomi brukar kallas för ”tragedy of the commons”. Det vill säga att alla vill utnyttja det gemensamma men ingen vill ta ansvar för att vårda det.

Masterdata är vanligen kund- och produktdata, men kan också vara andra data.
Vi går i det följande igenom några masterdatadomäner.

Kunddata

Den centrala informationen om kunder är en typisk kategori av masterdata. Dit kan man räkna alla uppgifter om kunder (både privatkunder och organisationskunder) som namn, kontaktuppgifter, status med mera. Normalt omfattar det både befintliga och tidigare kunder. Ofta även prospekts, det vill säga personer eller organisationer som ännu inte är kunder men som man har valt ut som kandidater till att bli kunder.

Uppgifter om enskilda kontakttillfällen med en kund eller köptransaktioner klassas emellertid inte som masterdata eftersom det representerar händelser i tiden och därmed är händelsedata.

Alla verksamheter har eller borde ha en centraliserad hantering av kunddata. Ofta brukar det finnas i ett ERP-system eller CRM-system. Om kunddata finns spritt behöver vi ha mekanismer som håller ihop detta.

Något som vi brukar stöta på är att man saknar en tydlig livscykelmodell för kunder. När blir en kund en kund? Är det vid första köpet? Eller tidigare? När blir en kund en tidigare kund? Är en kund som inte handlat på tre år fortfarande kund? Om man inte har tydliga regler för detta går det inte att veta hur många kunder man har eller att räkna på det som kallas ”churn rate”, det vill säga kundbortfall. Sedan bör man ju också hålla reda på orsaken till att kunder slutar. Det kan vara vårt val, kundens val eller helt enkelt att kunden avlidit eller konkursat. 

De senaste årens lagstiftningar har också gjort att organisationer behöver ha bättre koll på kunduppgifter. Ett exempel är krav på skydd av personuppgifter (GDPR). Ett annat exempel är de krav finansorganisationer har på sig att ha noggrann kännedom om sina kunder för att kunna reagera på signaler om penningtvätt. 

Data om övriga intressenter

Nästan alla verksamheter behöver hålla reda på också andra intressenter än kunder. Det kan vara leverantörer, partners eller andra. Medarbetare i den egna organisationen och kontaktpersoner hos olika intressenter är också intressenter. Då behöver man bestämma sig för om man ska ha en så kallad intressentmodell (party model), det vill säga att man har entiteter som representerar alla organisationer och personer man behöver hålla reda på oavsett roll dessa har till ens verksamhet. Där finns de uppgifter som inte har med den specifika rollen att göra, som organisationsnummer och namn och typ av organisation.

Därutöver behöver man separata rollspecifika entiteter för varje roll i förhållande till vår verksamhet som intressenten har. En och samma organisation kan ju vara både kund och leverantör. En och samma person kan på samma gång vara kund, representant för ett kundföretag eller anställd hos oss. Dessa rollspecifika entiteter rymmer det som har att göra med just den specifika relationen.

En intressentmodell behöver man i de fall då det är viktigt att ha en direkt överblick över vilka roller en och samma part har i förhållande till oss. Det brukar vara fallet i sammanhang där man behöver ha direkt koll på dubbla roller hos sina intressenter, som fallet ofta är i finansiella verksamheter. För andra verksamheter är en intressentmodell ofta overkill.

Produkter

De flesta verksamheter har produkter eller tjänster av något slag som man erbjuder omvärlden. Ofta går tjänster under namnet produkter, och ur informationssynpunkt är det ingen större skillnad. Så även jag kallar här tjänster för produkter.

Ofta har man en hel flora av produkter och ofta har man oordning i namngivning, klassificering, livscykelhantering med mera. Ofta har man inte definierade begrepp för ”produkt”, ”produktvariant”, ”produktversion”, ”produktkomponent”, ”produktlivscykel”, ”produktgrupp”, ”produkttyp”, ”produktindivid”, ”produktstatus”, ”externt namn”, ”internt namn”, ”leverantörens produktnamn” med mera. Det här är viktigt att reda ut, liksom regler för namngivning.

Om man utvecklar en befintlig produkt är resultatet att betrakta som en ny produkt eller är det en ny variant av en den befintliga produkten? Vad är det som kännetecknar en produkt, till skillnad från en variant på en produkt? Och det här som vi säljer, är det en produkt som består av ett antal komponenter, eller är det en paketering av flera produkter? Allt detta måste redas ut och standardiseras om man ska få ordning på en produktflora.

Tillverkare och försäljare av fysiska produkter har ofta behov av omfattande data om sina produkter, baserat på olika branschspecifika regelverk. Det kan vara dokumentation av olika slag som materialdata, testdata med mera.

Data management öppnar för mer än management av data

Det är lätt att inse att det inte går att isolera uppgiften att ta hand om data från att fånga, formulera, dokumentera begrepp och terminologi liksom verksamhetslogik. Vanligen blir det även påkallat att driva arbetet att inte bara dokumentera utan även utforma och standardisera begrepp, benämningar och verksamhetslogik. Detta är något bra. En informationsmodell och arbetet med den är, om det görs på ett bra sätt, en utmärkt plattform för det.

Roadmap för data management

Hur kan man då ta sig an jobbet att bygga upp data management i en organisation? Så här brukar vi gå till väga i de sammanhang jag jobbat i:

1. Kartlägg verksamhets- och systemlandskapet

Vi skapar en gemensam karta av vilka funktioner verksamheten består av och hur de samverkar med varandra och med omgivningen. Vi ritar in applikationer och hur de är integrerade så att vi får en karta som visar hur applikationer och dataströmmar är djupt integrerade delar av verksamheten. Vi gör detta genom en serie mindre arbetsmöten med verksamhets- och it-specialister. Kartan behöver vi för att förankra och ge kontext till alla övriga dialoger och modeller.

Det här är ett arbete som brukar gå förvånansvärt fort. På ett medelstort företag tar det kanske två till tre arbetsveckor att få fram en karta som är tillräcklig för att gå vidare med. Men naturligtvis kommer den att fortsätta förfinas under resans gång.

Resultatet brukar bli att verksamhet och it för första gången ser en ritning över hur verksamheten hänger ihop i alla sina delar, och får en gemensam spelplan för den dialog som behövs för all gemensam utveckling av it och verksamhet. Vilket är grundläggande, inte bara för data management, utan för all verksamhets- och it-utveckling.

2. Kartlägg datastrukturerna

Vi gör en eller flera detaljerade informationsmodeller för att förstå vilka företeelser som hanteras, deras egenskaper och hur de representeras i data.

Det här är inget annat än informationsmodellering, fast mer detaljerat och noggrant än vad som är vanligt. Arbetet går vanligen fort om man har tillgång till material och kunskap från it-kunniga. Säg att det tar återigen i storleksordningen två till tre arbetsveckor att få fram en tillräckligt säker modell för att kunna gå vidare. Arbetet kan göras delvis parallellt med steg 1 ovan. Modellen kommer naturligtvis att uppdateras efter hand ju mer vi lär oss. Arbetssättet består i koncentrerade mindre möten med kunniga personer, kombinerat med egen genomgång av databas- och filbeskrivningar.

Modellerna ger oss en tänkt bild, en hypotes, om hur det ser ut men ännu har vi egentligen inte studerat verkligheten närmare, det vill säga data i sig. När vi verkligen dyker ner i data upptäcker vi saker som gör att vi får ändra i modellerna.

3. Prioritera datadomän

Vi väljer ut en viss datadomän att fokusera på. Normalt är det en masterdatadomän, vanligen kund- eller produktdata. Ofta är kriteriet det som känns mest akut, men egentligen borde man kanske också väga in var man enklast kan få tidig nytta. Normalt är det redan bestämt eftersom själva orsaken till att vi blev inkallade berodde på ett visst problem man känt av. Men det händer ändå ganska ofta att vi ser att det finns ett mer akut behov eller en mer grundläggande datadomän, så att vi gärna vill styra om ordningen.

4. Kartlägg data

Vi går metodiskt igenom all data för den utvalda domänen i de centrala databaserna, samt hur de hanteras i integrationer. Resultatet blir en rapport över hur tillståndet är för datadomänen.

Detta moment kan ta längre tid. Det är ett ganska mekaniskt, rakt och enkelt arbete, men det tar tid att verkligen traska igenom stora datamängder ur alla möjliga aspekter. Men låt mig säga att det tar i storleksordningen fem arbetsveckor. Arbetssättet är en genomgång av data i databaser med enkla verktyg som SQL eller liknande.

5. Kartlägg produktion och användning av data

Vi kartlägger hur och var data skapas, hur de transporteras, och hur det används. Ofta får vi gå vidare till externa leverantörer av data, ibland leverantörens leverantör. Likaså får vi ofta söka upp externa konsumenter av data. Vi får en bild av vilka behov som finns, hur de tillgodoses, vilka verkliga brister som finns i praktiken och hur dessa uppstår. Vi intervjuar då de som känner till integrationerna och de som har kunskap om de olika applikationerna och hur de används. Det kan ta från ett par arbetsveckor beroende på hur stort ekosystemet visar sig vara.

Det är först nu vi har en tillräckligt tydlig problembild för att veta vad som behövs göras. Tills nu har det handlat om kunskapsinsamling.

6. Planera åtgärder

Nu har vi en klar bild av var och hur problemen känns av och var de uppstår. Då är det lämpligt att sätta samman en åtgärdsplan. Av nödvändighet är den endast preliminär. Ju längre vi kommer i arbetet desto tydligare blir det vad vi behöver göra.

7. Bygg organisation och arbetssätt och sätt igång

Vi bygger en rudimentär organisation för data management av den aktuella datadomänen och sätter igång med de åtgärder som prioriterats. Det handlar om en rad åtgärder, från rent tekniska till förändrade beteenden i verksamheten. Både engångsåtgärder för att åtgärda brister och nya rutiner för att förebygga nya brister.

Det här arbetet tar egentligen aldrig slut utan fortsätter som ett lågintensivt arbete för alltid. En datadomän behöver alltid vårdas mer eller mindre kontinuerligt. Så det här är mer en första enkel och prövande uppstart av en förmåga i organisationen.

När vi har fått rull på den första datadomänen sätter vi igång med nästa. Nu har jag beskrivit arbetet övergripande men mycket mer finns förstås att säga om varje steg. Jag planerar att beskriva varje steg mer i detalj, i olika artiklar, framöver.

Men viktigt att påpeka redan nu är att inget av arbetet handlar i grunden om teknik. Tvärtom vad många system- och konsultleverantörer påstår finns det inga speciella systemplattformar som gör jobbet och det är sällan andra verktyg än de enklaste är till hjälp. Det säljs speciella masterdatasystem, men enligt vår erfarenhet skymmer de uppgiften i stället för att hjälpa.

Och tvärt om en vanlig uppfattning behöver inte en masterdata-satsning vara stor, dyr och konsultintensiv. I själva verket motverkar det syftet. Det handlar om ett uthålligt lågintensivt agilt arbete, en mognadsprocess, en resa där vi tillsammans utforskar våra data och vår gemensamma förståelse för vad de representerar och steg för steg bygger ett sätt att bättre ta hand om data. 

Invändning 1: Bör man inte ta fram problembilden först?

Jag tror att man kan invända följande: Bör man inte först och främst ta reda på vad problemen är, innan man sätter igång? Mitt svar blir att det är sällan de i organisationen har en tydlig överblick över sin dataresurs. Olika personer upplever problem i olika situationer men de är inte på det klara med hur orsakssambanden ser ut. Det krävs en kartläggning. Och det är vad vi gör i steg 1 till 5. Det är först när vi vet hur saker hänger ihop som vi lite mer utförligt kan intervjua olika nyckelpersoner och representanter för användare. Det är först då vi kan ställa rätt frågor, förstå svaren, samt sätta samman och presentera en tydlig gemensam problembild. Och det är faktiskt sällan som den första beskrivningen är speciellt intressant.

Det är som att gå till läkaren. Jag har ett symptom jag söker för. Läkaren börjar med att skicka mig till blodprov, sedan röntgen av lungor och hjärta, ultraljud av levern och så vidare. Vid återbesöket får jag veta att jag har begynnande diabetes, högt blodtryck och dåliga levervärden. Läkaren sätter utifrån dessa resultat samman en åtgärdsplan i dialog med mig.

Det jag sökte för var endast ett symptom, den ytliga signalen på att allt inte var bra. Den verkliga problembilden behövde vi komma fram till tillsammans. Läkaren ställde inte direkt en diagnos utifrån mitt symptom, utan skapade sig först en helhetsbild genom de olika testerna för att kunna ge rätt hjälp. Det är alltså inte så att hon bara frågar om det jag söker för och fixar det.

På samma sätt är det med en dataresurs. En stor del av arbetet handlar om att ta reda på hur saker och ting hänger ihop, vad de olika aktörerna behöver och har respektive inte har idag, och hur de olika orsakskedjorna hänger ihop. Att åtgärda handlar sedan om ett uthålligt arbete.

Invändning 2: Bör man inte bygga organisation först?

Vi behöver bygga en central stödfunktion och vi behöver bygga roller och arbetssätt i olika delar av organisationen. Ska vi inte börja med det och först därefter sätta igång? Det är en vanlig uppfattning, men min erfarenhet är att det inte fungerar. Kultur, arbetssätt och roller behöver mogna fram. Det behöver få ta tid. Det är en dålig idé att stressa fram detta. Det som fungerar är att börja med enklast möjliga process och organisation och låta det hela växa fram efter hand. Den kände dataspecialisten Bob Seiner kallar den hållningen för ”Non-invasive Data Management”. Och visst borde egentligen all verksamhetsutveckling vara icke-invasiv! Det vill säga att coacha individer och team så att arbetssätt får mogna fram på individerna och teamens egna villkor.

Invändning 3: Varför smådutta? Vi behöver en större transformation, och det genast!

Jag tycker att vid det här laget borde vi ha lärt oss att stora projekt är en dålig idé. Många små steg betyder inte att verksamhetsutvecklingen går långsammare. Det gör att förändringen över huvud taget fungerar och att förändringen går precis så fort som är möjligt. Vilket ofta är överraskande snabbt. Och att det blir bra.

Vi ser fram mot din syn på data management. Kommentera gärna!

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 11 mars under rubriken ”En informationsmodell istället för flera”. Peter Tallungs visar hur vi kan kombinera flera perspektiv i en och samma modell  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

IRM deltar i arbetet för ett fossilfritt samhälle

IRM har valt att ansluta sig till den nybildade föreningen Digitaliseringskonsulterna i syfte att accelerera vårt strategiska arbete för ett smart och fossilfritt samhälle efter Coronakrisen.

För att Sverige ska bli fossilfritt kommer det krävas en transformation av hela samhället. De lösningar som digitalisering möjliggör och som vi hjälper våra kunder att implementera har mycket stor potential att minska de globala utsläppen av växthusgaser.

Genom vårt medlemskap i föreningen vill vi hjälpa samhället att se och använda digitaliseringens möjligheter. Medlemskapet innebär att vi aktivt stöttar politik, näringsliv och offentlig sektor i att förstå hur Sverige, genom digitalisering och innovation, snabbt kan transformeras till ett fossilfritt välfärdssamhälle med ökad konkurrenskraft och tillväxt som resultat.

Lär dig mer om föreningens ambition här

Digitaliseringskonsulterna accelererar sitt strategiska arbete för ett smart och fossilfritt samhälle efter Coronakrisen – Digitaliseringskonsulterna.se