Digitaliseringen måste få en central roll i klimatpolitiken

IRM är medlemmar i föreningen och branschorganisationen Digitaliseringskonsulterna. Under våren har Digitaliseringskonsulterna utvärderat hur de uppmaningar som vi överlämnade till regeringen i mars 2019 har mottagits av politiken, och skrivit en debattartikel som publicerats i Computer Sweden. Digitaliseringskonsulterna ger tre konkreta förslag till regeringen.

Det finns risk för att Sverige missar möjligheter till snabba och radikala utsläppsminskningar som ökad digitalisering kan möjliggöra. De övergripande målen i Sveriges digitaliseringspolitik är att Sverige ska vara bäst i världen på att använda digitaliseringens möjligheter. Trots det saknas många av dessa möjligheter i regeringens klimatpolitiska handlingsplan. Detsamma gäller omvänt där digitaliseringspolitiken skulle kunna ha större klimatambitioner än idag.

IRM är medlem i föreningen och branschorganisationen Digitaliseringskonsulterna. Under våren har Digitaliseringskonsulterna utvärderat hur de uppmaningar som vi överlämnade till regeringen i mars 2019 har mottagits av politiken.

I samband med utvärderingsresultatet presenterades publicerade Computer Sweden en debattartikel som signerats av Digitaliseringskonsulternas styrelse. Läs den här. 

Digitaliseringskonsulternas medlemmar förenas i ambitionen att hjälpa samhället att se och använda digitaliseringens möjligheter. Vi jobbar aktivt för att stötta politiken, näringslivet och offentlig sektor i att förstå hur vårt land, genom digitalisering och innovation snabbt kan transformeras till fossilfritt välfärdssamhälle och med ökad konkurrenskraft och tillväxt som resultat. Vi vill också stötta våra kunder i strävan att bidra till ett mer hållbart samhälle med inspiration, verktyg och rekommendationer.

Gör som oss – bli medlem!

Som medlem får du möjlighet att:

  • Utveckla er roll som lösningsaktörer i omställningen till ett fossilfritt samhälle.
  • Synliggöra er kompetens genom att bidra i strategiska processer och initiativ där Digitaliseringskonsulterna är inbjudna att delta.
  • Stärka er kompetens inom digitalisering, innovation och klimat.
  • Ta del av gemensamma satsningar och initiativ arrangerade av Digitaliseringskonsulterna.
  • Ta del av kundnära dialoger med andra branscher om deras förändrade behov av digitalisering i relation till klimatomställningen.
  • Påverka Digitaliseringskonsulternas fortsatta arbete genom engagemang i en arbetsgrupp
  • Accelerera det egna hållbarhetsarbetet genom kunskapsdelning och nätverkande.
  • Utveckla ert eget värde-erbjudande kopplat till digital transformation, innovation och klimat.
  • Få insyn i och möjlighet att påverka framtida politiska beslut som påverkar vår bransch.
  • Använda gemensamt framtagna debattartiklar, pressmeddelanden etc i ert eget kommunikationsarbete.

Anslut er här

Certifierad verksamhetsarkitekt – för vem?

Certifierad verksamhetsarkitekt är en utbildning för dig som vill vara en del av det team som skapar förutsättningar för verksamheten att förändras i takt med omvärlden. I den nödvändiga, ständigt pågående, verksamhetsutvecklingen är verksamhetsarkitektens roll central för en innovativ och lättrörlig organisation.

Verksamhetsarkitekten knyter ihop olika verksamhetsutvecklingsinitiativ och IT-satsningar i den riktning som verksamheten strävar genom att synliggöra och beskriva strukturen så som den ser ut, de värdeströmmar som finns, visualisera målbilder och alternativa scenarios samt genom att ta fram en plan för hur man ska kunna nå det önskade läget.

Om du vill ha smarta strategier och effektiva verktyg för att driva ett sådant arbete så är utbildningen Certifierad verksamhetsarkitekt för dig. En av förra terminens elever uttryckte det så här:

”Jag har fått nya perspektiv, en ny verktygslåda och massa energi. Känner att jag redan innan kursen var slut börjat göra saker på ett annat sätt, tänka på annat sätt, se saker på nytt sätt – en personlig utvecklingsresa!”

Utbildningen upplevs ibland som tuff. Det kan vara en utmaning att börja tänka i nya banor och utveckla nya tankesätt i hyffsat högt tempo. Därför får varje elev stöd av erfarna verksamhetsarkitekter som till vardags arbetar i olika branscher, företag och organisationer. Eleverna får även personlig feedback på en övningsuppgift som löper genom utbildningen där de beskriver och arbetar med en angelägen del av sin egen verksamhet, eller i någon annan de har god insikt i. 

Vill du veta mer om vad det innebär att utbilda sig till certifierad verksamhetsarkitekt? 

Boka en plats på vårt kostnadsfria webbinarium, som vi levererar i samarbete med Dataföreningen Kompetens, 23 april där verksamhetsarkitekt och utbildningsansvarig Lars Thomasson tillsammans med en f d elev presenterar utbildningen Certifierad verksamhetsarkitekt samt ger inblick i verksamhetsarkitektens vardag.

Försvar för enkla verktyg – del 1

En serie i serien. Med denna artikel inviger vi en artikelserie på fem artiklar om informationsmodelleringsverktyg i artikelserien Informationsarkitektens tankar.

Informationsmodellering är ett hantverk. För en hantverkare är verktygen viktiga. Låt oss se över vår verktygslåda. I den här artikeln vill jag försvara de enkla modelleringsverktygen.

Det finns ett antal specialiserade modelleringsverktyg, för både informationsmodeller och andra modeller. De är egentligen hela verktygsplattformar tänkta att stödja modelleringsarbetet genom att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. De ger ofta även stöd för att bygga upp ett förråd för en organisations samtliga modeller, ett repository.

En annan väg att gå är att använda sig av en kombination av vanliga generella verktyg, såsom basala rit-, -skriv, dokumenthanterings- och samarbetsverktyg där man själv får bygga upp de strukturer man behöver. Det är en ”best of breed”- strategi, de vill säga att man strävar efter att använda det bästa verktyget man kan finna för varje enskild arbetsuppgift i modelleringsarbetet.

Jag och mina kollegor har hjälpt många team och organisationer att bygga upp verksamhets- och informationsarkitektur samt Data Management. Vi har därmed erfarenheter från många olika sammanhang och förutsättningar.

Mot denna bakgrund har jag kommit till att förorda det senare alternativet då en kombination av enkla verktyg inte bara är gångbart utan det enda verkligt framgångsrika jag känner till. Enkla verktyg är inte enkla i den meningen att de är simpla. Tvärtom! De ger den flexibilitet och uttrycksfullhet vi behöver för att göra ett bra jobb som informationsarkitekter.

Jag har upplevt att denna ståndpunkt är kontroversiell bland enterprise- och it-arkitekter. Jag vill därför i denna artikel, och fyra efterföljande, tydligt och noggrant argumentera för den vägen. Kanske kan jag få någon att bli mer öppen för det alternativet. Eller också blir jag avfärdad som Luddit. (Ludditer var de engelska teknikfientliga väveriarbetarna som bjöd våldsamt motstånd till de nya effektiva vävstolarna i början av 1800-talet.)

Den enkla verktygslådan

Här är listan på de typiska verktyg jag rekommenderar. Det finns förstås likvärdiga alternativ, men då av samma enkla slag.

  • Microsoft Visio: För att rita
  • Microsoft Word: För textdokument och för att integrera text och bild
  • Katalogstruktur på server, eller liknande: Som repository för modeller
  • Ändringshistorik i dokument samt rutin för att spara versioner i katalogstrukturen: För versionshantering
  • Wiki eller det samarbetsverktyg som används i den organisation jag jobbar: För att publicera modeller samt kommunicera ut vad som händer
  • Storformatskrivare: För utskrift av modeller
  • Whiteboard och digitala samarbetsverktyg: För modelleringssessioner.

Jag kommer i följande fyra artiklar motivera och beskriva hur man kan använda respektive verktyg i verktygslådan. I denna inledande artikel ger jag generella motiveringar för kombinationen av enkla verktyg i motsats till de specialiserade.

Motivering för enkla verktyg

Här följer ett antal motiveringar till att välja enkla verktyg.

Motivering 1: Enkla verktyg ger frihetsgrader och möjliggör den rikare och mer kraftfulla gestaltning som vi behöver

Våra modeller kan bli mycket bättre gestaltade än vad som är vanligt idag. Det gäller alla slags modeller. Om vi ska lyckas få en organisation att samlas kring modellerna och låta dem representera en gemensam förståelse måste de bli mycket mer överskådliga, tydliga och tillgängliga. Samtidigt behöver de ges ett rikare uttryck genom att kombinera olika slags kunskap. Det handlar om hur vi ritar. Det vill säga struktur, disposition, färger, gråskalor, linjetyper, typsnitt, symboler, samt hur vi integrerar text och bild. Vi behöver kombinera och integrera olika slags diagram med varandra samt med textuella beskrivningar.

Det sätt vi i branschen idag arbetar med våra modeller har en stor potential till förbättring. Det handlar också om hur vi hanterar våra modeller, och hur vi tillgängliggör dem. För att kunna göra allt detta på ett bra sätt behöver vi verktyg som ger frihetsgrader, som inte begränsar oss, låser in oss och hindrar oss i det vi behöver göra.

Motivering 2: Enkla verktyg främjar experimenterande och därmed utveckling av alla våra områden där modellering är en viktig del.

Som yrkesgrupp behöver vi utveckla informationsmodelleringsområdet. För det behöver vi verktyg som ger oss den friheten.

Jag vill jämföra med vad som hände inom systemutveckling kring millennieskiftet. Vid slutet av 90-talet var tron på specialiserade modelleringsverktyg stor. Rational Unified Process var den förhärskande utvecklingsmetoden och Rational Rose var det modelleringsverktyg som skulle stödja hela utvecklingsprocessen. De organisationer som var ambitiösa och anammade detta arbetssätt fick det svårt. Metoden framställdes och tolkades på ett sätt som gjorde den överlastad och rigid. Själva metoden och verktyget styrde tänkandet och arbetssättet i stället för att vara en verktygslåda. Det blev att man fokuserade på att betjäna verktyget och utvecklingsmetoden i stället för att koncentrera sig på vad användare och verksamhet behövde. Man blev på så sätt en operatör av ett verktyg utan egen agens och ansvar.  

I det sena 90-talet växte missnöjet hos utvecklare och utifrån några individer växte det fram en motrörelse. Några utvecklare, på lite olika ställen, började tänka på vad de själva verkligen behövde och vad som fungerade. De tog fram mer basala och hantverksmässiga arbetssätt som parprogrammering, test-first design, scrum-tavlor med mera. Det nya tänkesättet grodde och spred sig i utvecklarsamhället. Ett par år efter millenniumskiftet fick det etiketten agila rörelsen. Utvecklare byggde själva enkla verktyg för att stödja sitt arbete. Mest kända blev testverktyg för att automatisera tester samt så kallade refactoring-verktyg för att snabbt och enkelt göra ändringar i kod.

Jag menar att vi behöver en liknande rörelse bland oss informationsarkitekter. Det vi behöver är en ny vår för arkitektarbetet som ett hantverk, precis det som agila rörelsen var för systemutvecklare för två årtionden sedan. Vad gäller arbetssätt så har vi redan lärt av agila rörelsen och alla förstår nog nu att vi behöver smidiga och mer kommunikativa arbetssätt. Men då det gäller verktyg återstår att överge de stora tunga modelleringsverktygen och i likhet med systemutvecklarna gå till oss själva, och ställa oss frågan vad vi egentligen behöver. Tillbaka till hantverket, och vad som verkligen stödjer det.

Jag har sett organisationer där arkitekterna varit som slavar under avancerade verktyg. De har varit upptagna med att mata verktygsmonstret. Resten av organisationen har inte haft nytta av arkitekterna, som befunnit sig i en parallell värld utan kontakt med verksamhetsutvecklingen.

Och denna nya vår jag hoppas på har faktiskt redan grytt på en del ställen. Jag har sett organisationer där verksamhets- och informationsarkitekter till sist givit upp sina tunga arbetssätt och verktyg. De har lämnat sina slutna rum, klivit ner från elfenbenstornet och gått ut där verksamhetsutvecklingen sker, bland utvecklarna och i verksamheten. De har sett hur de kan stödja utvecklingsarbetet. De har då, för första gången, känt sig välkomnade av utvecklare och domänexperter. De modellerar fortfarande, men nu med enkla tekniker som tjänat syftet på ett helt annat sätt.

I de fall de trots allt behövt lite mer verktygsstöd har de, precis som utvecklarna, själva experimenterar och byggt de verktyg de behövt. Jag ska försöka ge exempel på sådana verktyg framöver.

Dessa egenbyggda verktyg kan sedan i likhet med vad som hänt inom utvecklarvärlden så småningom kommersialiseras och bli standard. Det är egentligen alltid så det sker då ett yrkesområde utvecklas på riktigt. Alltid utifrån professionen och hantverket. Aldrig från verktygsleverantörerna.

Motivering 3: Enkla verktyg sätter fokus på uppgiften

Att ta ansvar för något stort, till exempel en informationsarkitektur, kan vara skrämmande. Det är många saker man måste ta ställning till och kanske behöva försvara. Då är det lockande att gömma sig bakom ett ramverk, en industrimodell, en metod eller ett verktyg som synes ge objektiva svar. Det är att fly undan det ansvar vi har. Då blir jag en operatör av ett verktyg i stället för informations- eller verksamhetsarkitekt.

Vi behöver i stället fokusera på vad som behöver lösas i verksamheten och använda de verktyg som gör jobbet. Inte först välja verktyg för att sedan bara mata detta.

Motivering 4: Enkla verktyg minskar beroendet

Om man i en organisation har tagit in ett avancerat modelleringsverktyg så medföljer det ett antal metamodeller, vilka styr hur de modeller man tar fram måste se ut och relatera till varandra. Om man senare vill ändra detta kan det bli mycket dyrt och svårt. Verktygen är i själva verket ofta en hel plattform av verktyg som hänger samman. Man blir på flera sätt, på gott och ont, beroende av leverantören och dennes utveckling av plattformen.  

Vanliga argument för specialiserade verktyg

När man argumenterar för en enkel verktygslåda får man ofta mothugg. Här följer ett antal argument som man stöter på och hur jag vill bemöta dem. 

Argument 1: Specialiserade verktyg ger konsistens

Specialiserade verktyg har en metamodell som styr hur vi kan modellera. Det gör att vi alla ritar och beskriver på samma sätt vilket är viktigt. Om vi inte gör på samma sätt blir resultatet spretigt, återanvändningen svår och kvaliteten lidande. Det följer vanligen med metamodeller vi kan välja mellan och i de mer avancerade verktygen kan vi själva, eller med hjälp från konsulter, ta fram en egen metamodell som passar oss.

Mitt motargument: Sättet vi modellerar behöver utvecklas för att på allvar bli relevant för våra verksamheter. Vi behöver alltså se det som ett hantverk i utveckling. Då är experimenterandet viktigt, att vi söker oss fram och lär oss. Vi ska då inte standardisera arbetssätt, notationer, metamodeller med mera. Det skulle frysa all utveckling och fortsätta hålla oss fast på det stadium vi är idag. Däremot ska vi dela erfarenheter och inspireras av varandra. Men det är något helt annat.

Det finns alltid, inom alla områden en motsats mellan utveckling och standardisering. Vi ska standardisera det vi tycker att vi nått en mognad inom. Men bara där. Där vi behöver utveckling ska vi tvärtom befrämja att vi gör olika, inte bekämpa. Vi behöver tåla och bejaka spretigheten. Utveckling innebär experimenterande.

När vi har lärt oss vad som verkligen fungerar kommer saker och ting att mogna och vi kommer naturligt att gravitera mot något av en de facto-standard. Men att gå utvecklingen i förväg och bestämma en standard innan vi har nått den mognaden är fel. Det är att frysa all utveckling. Därför behöver vi frihetsgrader. Det betyder inte kaos, utan bara att vi i får vara beredda på varianter och förbättringar i små steg. Och även något vilt försök ibland! Det är så utveckling går till. Överallt och alltid.

Argument 2: Specialiserade verktyg ger struktur och ordning

Specialiserade verktyg styr hur och var vi spar, versionshanterar och publicerar modeller. De ger oss ett strukturerat repository. Det gör att resultatet inte bara blir högar av osorterade modeller på olika ställen med oklara syften och sammanhang.

Mitt motargument: Vi behöver alltid ett strukturerat repository. Vi vill inte ha oordning. Men det är mycket lätt att ordna det på ett enkelt sätt och på vilken lagringsyta som helst där man kan ha filkataloger av något slag, och något slag av enkel åtkomstkontroll och versionshantering.

Det är fel att tro att ett specialiserat repository krävs för ordning och reda. Ett specialiserat repository ger heller inte ordning och reda av sig självt. Vi behöver även då tänka igenom och komma överens om saker och ting. Den största faran med verktyg som styr oss är kanske just den tankefällan, att vi tror att vi inte behöver tänka själva. Vi har sett modellbibliotek som varit total kaos i verktygsbaserade repositories och jag tror faktiskt att vi sett fler välordnade bibliotek bland de som byggs mera manuellt. Jag är övertygad om att när jag behöver bygga något själv leds jag in på att tänka igenom och ta ansvar för vad som behövs.   

Argument 3: Specialiserade verktyg ökar produktiviteten

Verktyget hjälper mig. Jag kan återanvända delar av andra modeller när jag gör en ny, eller referera till befintliga. När jag vill göra en ändring av något som manifesterar sig på många ställen behöver jag bara ändra på ett ställe. När jag vill publicera en modell gör jag det automatiskt. Versionshanteringen är inbyggd vilket gör att den går lätt och smidigt. Jag behöver inte fundera så mycket på hur jag ska göra rent praktiskt med dessa hushållsbestyr så jag kan koncentrera mig på själva modellerandet.

Mitt motargument: Jo, verktyget hjälper dig förvisso med några enkla uppgifter. Men inte alls så mycket som man kan tro, och inte alls med det som är det väsentliga; hur du gör riktigt bra modeller och hur du når ut med dem. Tvärt om hindrar det dig. Så triviala uppgifter går kanske något snabbare – men till ett mycket högt pris.

Om vi definierar produktivitet som hur mycket nytta vi gör, hur bra vi når ut och hur vi hjälper människor och team att hantera sin komplexitet så vinner de enkla verktygen överlägset. 

Det finns ett talesätt som säger ”A fool with a tool is still a fool”. Det brukar motvilligt citeras av verktygssäljare när man pekar på misslyckade införanden av deras produkter. De vill betona att deras fina verktyg trots allt inte garanterar ett bra resultat, utan att det kan finnas dumma människor som inte begriper hur de ska användas. Det finns ett tillägg till talesättet som säger ”A fool with a tool makes a faster fool”. Det vill säga att om ett verktyg ökar produktiviteten utan att verktygsanvändaren gör ett bra jobb hamnar man snabbt i ett dåligt läge.

Argument 4: Specialiserade verktyg stödjer samarbete

Verktyget stödjer att flera kan jobba samtidigt med samma modell, kanske även från olika geografiska platser.

Mitt motargument: Jo, verktyget har funktioner för detta. Men det fungerar bättre med de generella samarbetsverktygen vi använder i övrigt i våra distansarbeten.

Konflikten mellan viss automatisk hantering och stöd för rik gestaltning

Jag menar att om vi använder de specialiserade verktyg som finns så får vi visserligen stöd för vissa enkla uppgifter.

Men vi väljer samtidigt bort möjligheten till att göra riktigt bra modeller.

Vi kan inte få både och. Åtminstone inte idag. Och inte förrän vi själva inom professionen bidrar till den utveckling som kanske kan ge oss sådana verktyg.

Och vi tenderar till att både övervärdera nyttan av den lilla automatisering vi kan få samt att undervärdera vikten av att göra riktigt bra modeller som når fram.

I själva verket är det så krasst att om vi inte når fram har vi inget som motiverar vår existens.

De ivrigaste proponenter för specialiserade verktyg jag mött har nästan i samma mening beklagat att de inte har gehör hos it- och verksamhetspersoner för vad de gör, utan blir ständigt kringrända av utvecklingsprojekten. Det kanske skvallrar om något?

Fortsättning följer

Jag är medveten om att den här posten väcker många frågor. ”Peter pratar mycket om att vi ska göra bättre modeller men inte hur det går till.” Det är ett stort område, men jag vill steg för steg i den här artikelserien ge mitt bidrag till det.

Vad är din erfarenhet? Vilka verktyg använder du? Handen på hjärtat, vad fungerar på riktigt?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 22 april. Vill du prenumerera på artikelserien Informationsarkitektens tankar? 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

Det är skillnad på data och data

När vi ska bygga upp Data Management i en verksamhet, det vill säga verksamhetens förmåga att vårda och utveckla sin dataresurs, behöver vi en grundläggande indelning av data i kategorier. Ty olika kategorier av data behöver lite olika ansatser.

Det är praktiskt att dela in data i olika kategorier. Man stöter också på många olika indelningssätt i litteraturen. Varje sätt har sina styrkor och svagheter och passar därmed sina speciella syften.

Säg att vi ska bygga upp någon form av Data Management, det vill säga förmågan att vårda och utveckla vår organisations data som en värdefull resurs. Då finns det en grundläggande och praktisk indelning som jag tror är allmänt accepterad och som visat sig användbar tvärs över alla verksamheter.

Det är en grov indelning av verksamhetsdata i tre kategorier som skiljer sig åt beträffande vilka typiska problemställningar respektive kategori är förknippad med då det kommer till att ta hand om dataresursen. Därmed behöver varje kategori av data hanteras på lite olika sätt och med olika prioritet. Det som i grunden skiljer kategorierna i det avseendet är vilken livscykel verksamhetobjekten (som data i fråga representerar) har, i vilken mån data i den kategorin refereras eller uppdateras från olika funktioner i verksamheten samt i vilken grad dessa data har ett naturligt ägarskap.

De tre kategorierna är masterdata, globala referensdata och händelsedata. Dessa kommer jag nu gå igenom och ge exempel på.

Masterdata

Masterdata är vanligen kund- och produktdata, men kan också vara andra data. Det är data som uppfyller följande kriterier:

  1. Representerar centrala verksamhetsobjekt som har en livscykel över tid.
    Exempel: En och samma kund finns i vår verksamhet över en längre tid och kan ändra adress, status och till och med namn och andra uppgifter under sin livstid som kund och ändå ha kvar samma identitet. Ett annat exempel: En och samma produkt lever över en längre tid trots att den kan ändra status och andra egenskaper under sin livstid.
    Observera att det här inte handlar om hur länge man behöver spara data över tid, utan bara om hur länge verksamhetsobjektet har en aktualitet. 
  2. Refereras av många andra dataobjekt, särskilt händelseobjekt, och bildar därmed en bas för övriga data.
    Exempel: Kunder refereras av offerter och transaktioner, produkter likaså. Man kan säga att de verksamhetsobjekt som representeras av masterdata är centrala för verksamheten i det att de är mer eller mindre beständiga och refereras från många håll. Data som representerar dessa fungerar därmed som en slags bas och ankare i dataresursen. 
  3. Saknar ofta naturligt ägarskap. Många behöver kund- och produktdata men det är oklart vem som ska vara ansvarig för dessa. Masterdata är i likhet med gemensamma tillgångar i övrigt utsatt för det ekonomisk-sociala fenomen som kallas ”tragedy of the commons”: Hur en gemensam resurs riskerar att misshushållas, då ingen känner ansvar.
  4. Uppdateras ofta från olika verksamhetsfunktioner. Till exempel kan både sälj och marknad registrera nya kunder. Ofta har man ännu helt separat hantering av olika säljkanaler vilket betyder att online-kunder läggs upp helt separat. Eller så har man slagit ihop två verksamheter med överlappande kundregister. Adresser behöver kanske uppdateras både från offentliga källor och av kunden själv, via kundtjänst eller självbetjäning. Allt detta skapar typiska masterdataproblem som vi behöver hantera.

Globala referensdata

Referensdata är data som är till för att vara värdeförråd för egenskaper hos andra dataobjekt, det vill säga uppräkningar av giltiga värden. Det kan till exempel vara listan med Sveriges postnummer, alla produkttyper vi har, SNI-koder (Svensk Näringslivsindelning), länder i världen etcetera.

Kanske känns referensdata bäst igen som ”koder”, men en kod är egentligen endast ett av attributen för en förekomst av referensdata.

Vi inkluderar här inte lokala referensdata, till exempel de olika kundstatuskoder som finns ifall de endast används som värdeförråd för attributet kundstatus för kund. Skälet är att lokal referensdata har en naturlig hemvist. Ansvaret för vilka kundstatuskoder som finns hänger naturligt samman med ansvaret för kunddata. Det ingår i beskrivning av attributet kundstatus.

Referensdata har likt masterdata en livscykel. En statuskod kan till exempel ändra namn, börja vara giltig vid en tidpunkt eller upphöra vid en annan.

Globala referensdata har ofta inte ett naturligt ägarskap. Postnummer har visserligen en naturlig källa, Sveriges postnummerregister, men man behöver ändå se till att någon tar ansvaret för att tillhandahålla, tillgängliggöra och uppdatera listan internt i organisationen.

Referensdata representerar inte några egentliga verksamhetsobjekt i kontext av den aktuella verksamheten, utan varje entitet representerar bara en lista av giltiga värden för en viss egenskap hos ett eller flera verksamhetsobjekt.

Speciellt för referensdata är att de har en typisk uppsättning attribut som gäller för de flesta fall. Oftast ser man bara kod och namn, men en bruttolista över möjliga attribut borde kanske se ut enligt nedan. Detta gäller för alla referensdata, både globala och lokala.

Attribut för referensdata – bruttolista

AttributBeskrivning
KodKod eller id. Kan också fungera som kortnamn.
NamnFullständigt namn.
KortnamnEtt kortare namn för användning i de fall hela namnet inte får plats i något sammanhang, som till exempel i en valbar lista i ett användargränssnitt eller i en kolumnrubrik i en rapport.
DefinitionDefinition av värdet. Viktigt, men glöms ofta bort. Bör finnas med i informationsmodellen, och också vara tillgänglig i användargränssnitt.
BeskrivningBeskrivning utöver definition, i de fall det behövs.
NoteringEventuella noteringar i övrigt.
SorteringsordningEn siffra som anger i vilken ordning värdet ska listas, i en valbar lista eller dylikt, för det fall att sorteringsordningen inte ska vara alfabetisk. Glöms ofta bort, men behövs för att värdena ska listas i en naturlig ordning och på samma sätt överallt där de visas.
Gäller från och med – datumFör de fall att listan med giltiga värden ändras.
Gäller till och med – datumFör de fall att listan med giltiga värden ändras.

Händelsedata

Data som inte är masterdata eller referensdata avser vanligen något som är en händelse i tiden, som en transaktion av något slag, till exempel ett köp eller en order. Hit kan man också hänföra sådant som en offert eller faktura. De har kanske en viss giltighet över tid, men ändrar aldrig någon egenskap utöver status.

Händelsedata har därmed till skillnad mot masterdata och referensdata ingen längre livscykel. De är att betrakta som ett snapshot i tiden och kan därmed aldrig ändras, utöver möjligen sin status. Dessutom hör händelser tydligt hemma i speciella verksamhetsfunktioner, då de inträffar i ett speciellt sammanhang. Därmed är de inte på samma sätt en delad resurs som masterdata och globala referensdata. Sist men inte minst viktigt, om du har fått ordning på masterdata och globala referensdata har du en fast grund att stå på. Allt detta talar för att händelsedata blir smidigare att hantera.

Viktigt att veta är att det som i en verksamhet har kort livslängd och därmed kan klassas som händelsedata kan i en annan verksamhet ha en beständighet och därmed behöva klassas som masterdata. Ett exempel kan vara avtal. I en verksamhet kan ett avtal gälla för endast en leverans och därmed snabbt vara överspelat. I en annan verksamhet löper avtal över lång tid och används för många leveranser. I det första fallet är det händelsedata, och i det andra fallet masterdata.

Jämförelse mellan kategorierna av data

Vi kan nu jämföra de tre kategorierna av data beträffande de faktorer som bör påverkar i vilken ordning vi bör adressera att ta hand om dataresursen. De fyra faktorer som jag kan se redovisas i tabellen nedan.

Vilka faktorer som påverkar prioriteringen för Data management för en datatyp

PåverkansfaktorMasterdataGlobal referensdataHändelsedata
Lever över tidJaJaNej
Refereras från många ställenJaJaNej
Saknar ofta naturligt sällskapJaJaNej
Uppdateras ofta från flera ställenJaNejNej

Syftet med indelningen

Varför är det bra att dela in data på detta vis? Jo, om vi verkligen ska ta hand om våra datamängder så ställer de här kategorierna olika krav på oss som verksamhetsförmåga. Masterdata och global referensdata utgör grunden och själva förankringen för all data. Det vill säga all övriga data är beroende av masterdata och global referensdata. Därför behöver vi först få ordning just där. Har vi gjort det så faller det övriga på plats ganska naturligt. Att däremot börja med händelsedata när vi har en skakig grund i till exempel kund- och produktdata är ogörligt.    

Jag brukar jämföra det med strategin för att röja hemma i villan. Om man först skapar ordning i förvaringsutrymmena, det vill säga på vinden, i källaren och i garaget, så blir det mycket lättare att ordna upp i resten av huset. Tvärt om är ingen bra idé.

Masterdata kommer som sagt först i prioritet, tillsammans med global referensdata. Händelsedata kommer naturligt senare i prioritet.

Detta är förstås en förenkling. Det kan finnas annat som gör att man behöver prioritera annorlunda. Men då blir det kanske till ett pris. Utan en fast grund är det svårt att göra någonting bra.

Data management

Vi bör givetvis ta hand om all data. De olika kategorierna av data har mer gemensamt än som skiljer i detta avseende. Men masterdata har ändå en nyckelroll i detta arbete. Därför brukar man se masterdatahantering som ett eget område. Globala referensdata har i viss mån liknande problem men är vanligen lättare att komma till rätta med.

Vi ska i nästa artikel titta på vad Data Management handlar om.

Till dess, vad anser du om indelningen som jag beskriver här? Har du en annan syn? Eller bättre beskrivning av respektive kategori?

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 4 mars. Peter Tallungs tittar närmare på vad Data management handlar om och ställer frågan: Hur kan vi bygga en förmåga att ta hand om den resurs som vårt data är?  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Ny endagskurs i Vintergatan

Du har väl inte missat? En dag räcker för att få grepp om hur du arbetar med modellen och metoden. Anmäl dig till ”Vintergatan – kartan för navigering och förändring”. Kursen är digital och går på måndag 15 februari. Läs mer om kursen och anmäl dig här

Vi levererar kompetensutveckling i samarbete med Dataföreningen Kompetens.

Informationsarkitektur – ”To make sense of any mess”

Ett försök att ringa in vad det handlar om.

Jag och mina kollegor är informationsarkitekter. Vi tar uppdrag där man vill ha hjälp med att få koll på verksamhetens data och dess struktur. Det här är ett försök att ringa in vad det handlar om.

När efterfrågas en informationsarkitekt?

De flesta organisationer hamnar förr eller senare i ett läge där man inte har så bra koll på sina datamängder som man behöver. Problemen kommer smygande och accelererar. Tyvärr sker tillvänjning parallellt, och det är svårt att få till kraft att ta tag i saken. Det är svårt att motivera ledningen att satsa på något så föga hajpat, något som i bästa fall ger ett resultat som ser ut som status quo. Att bara städa upp i det befintliga när det finns nya spännande tekniker och affärsmöjligheter.

Man har dragit på sig något som kan liknas vid en teknisk skuld, men som borde kallas verksamhetsskuld. Hur stor en verksamhetskuld är kan bedömas av frekvensen av ”What the F—k” som hörs närhelst man behöver rota i kökkenmöddingen av begrepp och data. 

Triggers

Vanligen är det något annat som triggar till handling, så att man kallar in oss, något som känns som trängande eller attraktivt. Här följer några vanliga triggers. Man:

  • behöver byta ut sitt centrala affärssystem (ERP-program)
  • vill införa ett säljstödsystem (CRM-införande)
  • behöver få kontroll över sina kunddata (Masterdata-projekt, Kunddata)
  • vill bygga datatjänster som externa parter kan använda
  • har nya krav på rapportering till myndigheter (Compliance-projekt)
  • vill lägga en ny grund för dataanalys och rapportering (Business Intelligence-program)
  • vill lägga en grund för analys av ostrukturerade datamängder (Data Science-/Maskininlärning-/AI-/IoT-projekt)
  • behöver strukturera sin produktportfölj för bättre ordning (Product Lifecycle Management-projekt).
  • vill bygga upp en integrationsplattform och ett integrationsteam för att lättare integrera interna och externa funktioner, processer och system (Integrationsprogram)

Det dessa initiativ har gemensamt är att de ställer krav på att man har kontroll på vilka data man har, hur data hanteras och vad data representerar. Det är då vi efterfrågas. Fast inte alltid från början i ett sådant projekt utan först en bit in, när man börjat köra fast. Man vill gärna tro att projektet bara handlar om teknik, men har nu upptäckt att grundproblemet är att man inte har koll på sina datamängder, begrepp och språk.

Det är just den typen av problem vi går igång på. Den amerikanska informationsarkitekten Abby Covert är den som sagt det bäst, det vi gör: Det handlar om att ”make sense of any mess”: ”att göra en röra begriplig”.

Vad gör jag som informationsarkitekt?

Arbetet brukar följa några vanliga spår:

  • Kartlägga vilka data som hanteras, eller behöver hanteras, i en verksamhet, vad de representerar för företeelser som verksamheten behöver hålla reda på, liksom företeelsernas egenskaper och relationer.
  • Kartlägga hur centrala datamängder skapas, fångas, lagras, distribueras, hanteras och används, idag.
  • Ge förslag på vad man behöver göra och på vilket sätt, för att hantera data och komma tillrätta med brister.
  • Etablera ett tydligt och effektivt gemensamt språk för de företeelser som representeras av data, inklusive företeelsernas egenskaper och verksamhetsregler.

Det som vi vill se som den egentliga uppgiften ligger samtidigt som en underström i arbetet: att skapa en gemensam förståelse för hur man kan ta hand om sina data och sina begrepp och att få till arbetssätt och organisation för att kontinuerligt vårda och utveckla detta.

Kultur och arbetssätt behöver få mogna fram så att organisationen i fortsättningen själv ska kunna hantera kunskapen om sina data, sina begrepp och sitt språk på ett hållbart sätt. Vi vill alltid vara ”spelande tränare” till individer, team och hela organisationen. Vi utvecklar kultur och arbetssätt, inte genom att bara prata utan genom att själva dela vardagen med medarbetarna. Framför allt kan vi praktiskt visa hur, inspirera och stödja.

Vad bör en informationsarkitekt kunna?

En informationsarkitekt kan ses som en specialiserad verksamhetsarkitekt, en som har inriktning mot data, information, språk och begrepp. Som sådan behöver jag röra mig tvärs över verksamhet och it. Jag behöver:

  • tillgång till databaser och filer, då det är där data finns.
  • intervjua it-folk, för det är de som vet var data skapas, lagras, transporteras och transformeras.
  • tala med och förstå verksamhetsfolk, särskilt de i praktiska operativa och analytiska funktioner, för det är de som använder och skapar data.

Därmed behöver jag vara bekväm med att gräva i datastrukturer i databaser och filer. Jag behöver vara analytisk och envis, hitta samband åt olika håll, knyta ihop delar med varandra och till helheter. Jag behöver tycka att det är roligt att skapa krispiga definitioner och korrekta namn på saker och ting. Men samtidigt behöver jag lyssna och kunna kommunicera pedagogiskt, både brett och djupt. Allt detta målar upp bilden av en nörd, en kommunikativ nörd.

Det jag som driver mig är det där lilla pirret när man börjar ana hur saker hänger ihop. Det får mig att gräva vidare. Till aha-upplevelsen när det plötsligt faller på plats. Bara för att strax därpå se att det öppnar upp för nya frågeställningar!

Vilka är informationsarkitektens verktyg?

I likhet med övriga arkitekter arbetar vi med modeller. Modeller är arkitekters viktigaste verktyg. Modeller är – rätt använda – kraftfulla sociala tanke- och kommunikationsverktyg. De kopplar ihop våra hjärnor, alla vi som deltar i arbetet, och hjälper oss att skapa gemensam förståelse, gemensamt språk och kan också bli den gemensamma arbetsplattform vi behöver för vårt kontinuerliga arbete. 

Den vanligaste typen av modell för en verksamhetsarkitekt är informationsmodellen. Den bär vår framväxande gemensamma förståelse för vilka data som finns och vad de betyder, samt språket för allt detta.

Utöver informationsmodellen, till och med före denna, brukar jag ta fram en funktions-/applikationskarta. Den visar vilka operativa delar verksamhetens är uppbyggd av samt hur de samverkar som ett ekosystem med varandra och med omgivningen. Den visar också hur systemportföljen är en djupt integrerad del i verksamhetens funktioner. Kartan kan jag sedan använda för att kartlägga hur data strömmar genom verksamhetens delar och it-system.
Kartan ger översikt och sammanhang. Därmed förankrar den alla övriga modeller och dialoger i sin relevanta kontext.

I övrigt behöver vi bygga upp ett bibliotek för dessa dokument samt en plattform för att publicera och kommunicera resultat och underrättelser till alla berörda parter.

Hur stort är arbetet med informationsarkitektur?

Det här är ett arbete som mår bäst av att drivas agilt. En eller ett par personer är drivande och involverar de som de behöver efter hand. Den första nyttan kommer snabbt, men det är viktigt att få till en kontinuitet. Det handlar om att med tiden få organisationen rustad för att kunna ta hand om sina data, sina begrepp och sitt språk. Det är något som inte kan forceras utan bör få tid att mogna fram. Och man blir aldrig klar. Det finns alltid nya frågor att ta sig an. Med framgång kommer hunger efter mer.  

Vad ger en informationsarkitektur?

Informationsarkitekturen ger en grund för hela organisationens hantering och utnyttjande av data, inte minst då det gäller utveckling av nya sätt att använda data. Om man verkligen tänker efter vad det betyder att ha koll på sina data och ha tydliga begrepp, så inser man hur viktigt det är.

Det första värdet av arbetet är att all utveckling, vare sig i projekt eller löpande, där data är en väsentlig del går lättare, snabbare och med mindre risk.

Ett exempel från verkligheten

I ett av mina uppdrag som informationsarkitekt på en bank fick vi så småningom ordning på hanteringen av data och alla tusentals begrepp. Då gav vi oss på att försöka uppskatta den kostnads- och tidsbesparing som detta gav, vad beträffande den ständigt pågående verksamhets- och systemutvecklingen, som var en stor del av den totala budgeten.

Som en grund tog vi först reda på hur många mantimmar per år som gick till utvecklingsarbete, vare sig det var under arbetsformen projekt eller förvaltning, eller det var tid som hamnade på verksamhet eller it. Sedan intervjuade vi verksamhets- och it-utvecklare av olika slag och resonerade oss fram på följande sätt: Första frågan var hur stor del av all utvecklingstid som omfattade funktioner där förståelsen av data var en central del av problematiken. Svaret vi kom fram till blev en uppskattning på 60 procent. Nästa fråga blev följande: Hur mycket tid spar du i ett sådant arbete om vi har koll på data och begrepp? Uppskattningen blev 60 procent av tiden, tvärs över alla faser i arbetet, från analys och krav till implementation, test och förvaltning, liksom tvärs över alla involverade roller.

Det kan tyckas mycket, men alla som varit inblandade i utvecklingsprojekt i en dataintensiv verksamhet vet hur stor del av arbetet som handlar om att försöka förstå vad saker och ting egentligen betyder och hur man ska hantera det. För att inte tala om de överraskningar som kommer sent i projektet då man inser att man har pratat förbi varandra.

Mångmiljonbesparing

Detta innebar att den totala tids- och kostnadsbesparingen för utveckling, i den koncernen skulle bli 60 procent x 60 procent, vilket blir runt 36 procent. Vi multiplicerade den siffran med hela den årliga utvecklingskostnaden och fick fram en uppskattad årlig besparing på runt 70 miljoner kronor. Den summan vågade vi nästan inte visa för ledningen då de kunde se oss som orealistiska.

Men alla inblandade såg det som helt rimligt. Och man såg också att denna besparing egentligen bara var den lilla effekten. Det finns en större effekt av att kunna ta hand om sina data, och att ha ett väldefinierat språk för sina analyser och rapporter. Det visade sig att risken för försenade eller misslyckade projekt minskade dramatiskt. Vi kunde komma ut med datadrivna tjänster snabbare och smidigare. Vi kunde nu göra saker som inte tidigare var möjliga. Dessutom kunde vi använda data till nya tjänster och produkter. Det är svårt att överskatta vad det betyder.

Än idag, tio år senare, är de begrepp, språk, förståelse och arbetssätt vi tillsammans byggde upp, en självklar kärna i företagets it- och verksamhetsutveckling.

Jag har svårt att tänka mig någon annan satsning som ger mer tillbaka per spenderad krona och med större säkerhet.

Det förutsätter förstås att man som informationsarkitekt vet hur man gör. Hur man kan bygga ett effektivt och förståndigt arbetssätt. Hur man kan skapa engagemang och driva arbetet på ett hållbart sätt.

Om detta vill jag skriva.

Vad tycker du? Har du en annan syn på området Informationsarkitektur? Vill du att vi tar upp något specifikt inom området? Kommentera gärna! Vi ser fram mot en dialog

/Peter Tallungs IRM

Nästa artikel i ämnet informationsarkitektur publicerar vi torsdag 11 februari. Det handlar då om rollen informationsarkitekt. En roll med namnet informationsarkitekt har uppstått två gånger i historien i två olika sammanhang och med olika tyngdpunkt. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Vill du komma i kontakt med någon av irm:s informationsarkitekter?

Lär dig skapa samsyn, bättre beslutsunderlag och öka förändringstakten

Kostnadsfritt webbinarium 15 januari 2021. Se hur du snabbt lär dig att skapa en unik samsyn, bättre beslutsunderlag samt ökad förändringstakt och kundnöjdhet med hjälp av Vintergatan. Anmäl dig till det kostnadsfria webbinariet fredagen den 15:e januari där vår Vintergata-guide Ceclia Nordén presenterar vårens två Vintergatakurser. 

Två kurser presenteras

Vårens första Vintergatakurs är en dag online där du får grundläggande kunskaper i modellen och metoden samt hur du navigerar och bedriver förändringsarbete med Vintergatan som grund. Kursdatum: 15 februari 2021.

Vårens andra Vintergatakurs är en tredagarskurs, online, där du får bygga upp en första version av en Vintergata över din egen verksamhet. Kursstart: 23 mars

Ta del av tidigare kursdeltagares erfarenheter

Under webbinariet får du även får möta två tidigare kursdeltagare och ta del av deras erfarenheter av kursen Vintergatan – skapa din verksamhetskarta. Det kommer finnas möjlighet att ställa frågor till kursledare och fd kursdeltagare under webbinariet.

Plats: Online

Tid: 15 januari 2021. Presentationen pågår kl 8.30 – 9.30, därefter frågestund till kl 10.00

IRM önskar alla en God Jul och ett bättre 2021

IRM önskar alla en God Jul och ett bättre 2021! Vi har också en särskild önskan om att alla barn som drabbas av cancer ska få bli bättre och helt friska. Därför har vi valt att ge årets julklappspengar till Barncancerfonden.

Året som gått har verkligen utmanat oss alla på olika sätt. När IRM summerar 2020 så kan vi ändå tacksamt konstatera att vi går stärkta in i 2021 med många värdefulla nya erfarenheter, nyvunnen kunskap och förtroendet att leverera till många nya kunder.

I alla våra uppdrag tar vi sikte på en bättre framtid och tar stegen i den riktningen tillsammans med våra kunder. Stegen går längs väldigt olika vägar beroende på omvärld, bransch och kund.  Utmaningarna skiftar. Det är en av faktorerna som gör vår vardag så stimulerande och arbetet meningsfullt. Vi ser fram emot att fortsätta resa framåt tillsammans 2021!

God Jul och Gott Nytt År

från oss alla på IRM

Barncancerfonden arbetar för att bekämpa barncancer och se till att drabbade barn och deras föräldrar får den vård och stöd de behöver.

Maxad endagskurs i Vintergatan!

För dig som vill se poängen med Vintergatan innan du testar den i din egen verksamhet.