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.

Informationsmodellen som domänmodell

En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar. Det vill säga allt det som verksamheten behöver hålla koll på, med andra ord verksamhetens domän.

Varje gång jag säger att informationsmodellen beskriver information så skorrar det lite falskt i mig. För jag tycker inte att det är helt rätt beskrivet, eller i varje fall inte speciellt klargörande.
Ja faktiskt till och med missledande, på sätt och vis. För då utelämnar vi det viktigaste. Låt mig förklara.

Det är sant att en informationsmodell beskriver strukturen hos informationen i något sammanhang. (Eller ofta snarare hur den bör vara.) Det kan vara data i en databas, i en fil, i en applikation eller en tjänst. Men det kan också vara den konceptuella strukturen av den information som delas av en verksamhet eller en verksamhetsfunktion.

Så långt är allt väl. Lätt att förstå och prata om. Men sedan kommer det som komplicerar, men som också gör det hela mer intressant. Mycket mer intressant i min mening.

Data i sig representerar i sin tur något som finns där ute i verkligheten. Varje entitet i en informationsmodell representerar en klass av företeelser som verksamheten behöver hålla reda på förekomster av. Det kan vara kunder, produkter, produkttyper, ordrar med mera.

Den dubbla rollen

Alltså, informationsmodellen avbildar både strukturen hos data i sig och utgör samtidigt en modell av domänen det vill säga de företeelser som verksamheten behöver hantera.

Informationsmodellen är följaktligen lika mycket en domänmodell som en modell över informationen som behövs för att hantera domänen.

En domänmodell beskriver verksamhetens ”värld”, de företeelser som behöver hanteras av verksamheten, beskrivna och benämnda på ett sätt som passar verksamhetens sammanhang och syfte. Den vill uttrycka den gemensamma förståelsen av det som hanteras och utgöra det gemensamma språket. Det är svårt att överdriva betydelsen för en organisation av att utveckla och vårda den förståelsen och det språket.

Det här är något som sällan kommer upp på bordet, men som jag menar är väsentligt för att förstå vad vi egentligen håller på med när vi modellerar.

Informationsmodellens största potential

Det är just där, som domänmodell, informationsmodellens största potential ligger menar jag, och samtidigt den hittills mest underutvecklade. Vi har, om vi blir skickliga i vårt värv, en förmåga att beskriva, hantera och utveckla hela verksamhetslogiken på ett sätt som annars inte är möjligt.

Jag har sett hur informationsmodellen enkelt och naturligt kan fylla en central och viktig roll i en verksamhet. En informationsmodell kan bli en gemensam karta över det som verksamheten hanterar, en domänmodell. Den kan bli bäraren av de gemensamma begrepp och det gemensamma språk som vi behöver. Jag har till och med sett att den kan bli bäraren av hela den grundläggande verksamhetslogiken. Och inte bara det, den kan även bli plattformen för utforskandet och utvecklandet av verksamhetslogiken och språket. Och det med överraskande enkla medel.

Informationsmodellering kan därmed fylla en mycket mer central roll i analys och utveckling av en verksamhet och dess informationssystem än den gör idag. Inte bara vad gäller analys och utveckling. Vi har ju i alla sammanhang behov av att arbeta för en gemensam förståelse, krispiga begrepp och ett gemensamt språk.

Fast i så fall behöver vi tänka om och tänka nytt. Vi behöver öppna upp beskrivningstekniken till en helt annan kraftfullhet. En huvudtanke med denna artikelserie är att föreslå hur vi kan få till detta.

Vad säger ”information” egentligen?

Nu till något helt annat. Ett annat sätt som namnet ”informationsmodell” skorrar lite falskt för mig har med förledet ”information” att göra. Ett måhända mindre problem, men ändå irriterande.

Om jag säger till min granne att jag jobbar med informationen på ett företag så skulle hon anta att jag är informatör eller skribent av något slag. Och kanske skulle jag sedan försöka förtydliga genom att fortsätta med att jag arbetar med en modell över informationen. Då skulle hon nog, om hon inte ryckte på axlarna och gav upp, göra sig en bild av att jag på något sätt ser över hur företaget ska informera externa eller interna intressenter. Eller kanske ser hon framför sig hur jag tar fram en modell för omvärldsbevakning. Så låt oss vara överens om att ”information” inte är en tillräckligt specifik benämning på det vi modellerar.

I själva verket beskriver en informationsmodell inte strukturen på information i största allmänhet utan endast strukturen och meningen hos den information som behöver listas i en verksamhet. Det vill säga den data som beskriver klasser av företeelser som har förekomster av något slag. Förekomster av saker som verksamheten behöver hantera och därmed behöver lista på något sätt. Till exempel kunder, ordrar, produkter, anställda, postnummer och tusen andra saker.

Och egentligen aldrig det som man i första hand tänker på som företagets information som företagets historia, affärsplan, årsredovisning, ägarförhållande, affärsidé, verksamhetsbeskrivning, kundvärde, marknad, kreditvärdighet med mera.

Kanske det skulle vara tydligare att prata om ”datamodell” som amerikanarna gör?

Så vad blir mitt förslag på namn på de modeller vi gör? Tja, traditionen gör väl att vi får fortsätta att säga ”informationsmodell”, fast det inte är speciellt förklarande och måhända tar emot lite grand. Och vi kan väl tillstå att ”datamodell” är en synonym. Och vara medvetna om att vi i själva verket modellerar en domän i sig utöver informationen och språket om domänen. Även om vi kanske ännu inte är mogna för att kalla det för domänmodell?

Vad tycker du? Kan du se informationsmodellens roll som domänmodell?  

/Peter Tallungs, IRM

Prenumerera på artikelserien om informationsarkitektur

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 25 februari. Det handlar då om skillnaden mellan data och data.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Informationsarkitekter: De två kulturerna

En roll med namnet informationsarkitekt har uppstått två gånger i historien i två olika sammanhang och med olika tyngdpunkt. Det kan skapa förvirring. Men det kan också vara en möjlighet.

Informationsarkitekten – sprungen ur databasadminstratörens roll

Den första gången någon kallades ”informationsarkitekt” var på mitten av 1970-talet, men professionen växte först fram på allvar ur databasadministratörernas värld på 1980-talet. I början handlade det om att designa databaser. Rollen utvecklades så småningom till att handla om det större perspektivet, att bringa ordning i en verksamhets data och information tvärs över olika källor, verksamhetsfunktioner, databaser, applikationssystem, integrationer, tjänster, rapporter med mera.

Tack vare den nära kopplingen som en verksamhets data har till begreppen och språket i en verksamhet så växte det fram så småningom på sina håll ett ansvar för begrepp och språk. Men fortfarande handlar det oftast om en nära koppling till informationstekniska system, och vanligen med ett mycket brett fokus över många enskilda tillämpningar, databaser, integrationer, rapporter. Ibland är uppgiften att skapa en gemensam grund tvärs över flera verksamheter.

Det är i det skrået jag och mina kollegor på IRM arbetar. Det finns ingen särskild utbildning för detta, men det finns branschorganisationer som DAMA (Data Management Association International) med konferenser och på webbplatser som TDAN (The Data Administrators Newsletter) finns ett rikt material att ta del av.

Informationsarkitekten – sprungen ur webbdesignerns roll

Den andra rollen med samma namn uppstod ett par decennier senare.  Boken ”Information Architecture for the World Wide Web” av Louis Rosenfeld med flera som kom 1998 brukar nämnas som startpunkt. Boken brukar kallas för ”Isbjörnsboken” med anledning av förlaget O’Reillys gimmick med djur på omslaget. Den manifesterade informationsarkitektens roll som en utbrytning ur webbdesignernas skrå. Författarna skrev om hur man skulle strukturera information på en webbplats. Rollen har sedan breddats till att handla om hur man strukturerar information för en viss tillämpning, vilken som helst, inte bara webbsidor.

För denna roll finns det idag flera utbildningar på svenska och utländska universitet. När man googlar på ”Informationsarkitekt” eller liknande får man nästan bara träff på rollen eller kunskapsområdet i denna nyare betydelse.

Två skilda skrån

Vi behöver för den fortsatta diskussionen kunna skilja dessa två rörelser åt. Det finns de som har börjat kalla vårt äldre område för Enterprise Information Architecture” vilket jag tycker är klargörande. Ty vårt arbete är ju inte begränsat till en specifik tillämpning utan spänner över en hel verksamhet, eller i alla fall stora delar av en verksamhet. En svensk översättning av termen kunde vara ”Verksamhetsinformationsarkitektur” om det inte vore så långt och tungvrickande. Den andra nyare inriktningen skulle kanske kunna heta Service Information Architecture” eftersom den handlar om hur information presenteras inom en enskild tjänst, till exempel en webbapplikation, en webbsida, en elektronisk tjänst, en broschyr eller liknande. Men som sagt, det är endast min egen tanke.

Det finns förstås ingen motsättning mellan dessa roller. Det finns beröringspunkter, men också skillnader i tyngdpunkt. Det märkliga är att det här är två olika kulturer som sällan möts. Vi inom dessa två områden borde interagera mera, men i stort sett har det fortsatt som två olika yrkesgrupper utan vidare kännedom om varandra.

Vad skiljer oss åt?

Det finns mycket som är gemensamt mellan rollerna eftersom det i båda fallen handlar om information och data.

Den stora skillnaden ligger i den yngre rollens fokus på hur man som användare brukar någon form av interaktiv tjänst. Rollen har ju sitt ursprung inom interaktionsdesign. Detta avspeglas i utbildningsinnehållet som har fokus på olika typer av användargränssnitt som kurser i webbutveckling och interaktionsdesign.

Detta saknas nästan helt och hållet i den äldre rollen som jag och mina kollegor är en del av. Den fokuserar på struktur, mening och egenskaper hos data och information i sig, gemensamt över alla tillämpningar, liksom över hela datadistributionen vilket naturligtvis ändå är en nödvändig grund för användbarheten för alla tillämpningar av data. Man kan säga att vi är ”presentationsagnostiker”. Det vi tar fram måste fungera för en hel verksamhet (eller ibland flera samverkande verksamheter eller hela branscher) tvärs över alla enskilda kommunikationskanaler och sammanhang.

Jag har också förstått att eftersom informationsarkitekter av den yngre rollen ligger så nära interaktionsdesigners i sitt arbete har de haft och har kanske fortfarande svårt att urskilja sig från de senare och motivera sin existens i den världen.

Kan vi närma oss varandra?

Om jag fick önska något skulle det vara att vi informationsarkitekter, oavsett inriktning kunde jobba närmare varandra och lära av varandra. Jag är säker på att vi av den äldre skaran skulle behöva bli bättre på informationsdesign och att de av den nya skaran skulle må bra av att lyfta blicken från enskilda tillämpningar till det större sammanhanget.

Men första steget måste då bli att vi känner till varandras existens. Det är med förhoppningen att bidra till den kännedomen jag skriver detta.

Vad säger du? Vad gör vi åt detta?

/Peter Tallungs IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 18 februari. Det handlar då om informationsmodellen som domänmodell. En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

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. 

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 är några typiska triggers:

Man:

  • behöver byta ut sitt centrala affärssystem (ERP-program)
  • vill införa ett säljstödsystem (CRM-införande)
  • vill bygga upp en integrationsplattform och ett integrationsteam för att lättare integrera interna och externa funktioner, processer och system (Integrationsprogram)
  • vill bygga datatjänster som externa parter kan använda
  • 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)
  • har nya krav på rapportering till myndigheter (Compliance-projekt)
  • behöver få kontroll över sina kunddata (Masterdata-projekt, Kunddata)
  • behöver strukturera sin produktportfölj för bättre ordning (Product Lifecycle Management-projekt).

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.

Samtidigt ligger som en underström i arbetet det som vi vill se som den egentliga uppgiften:

  • Skapa 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. Vi kan 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. Jag behöver intervjua it-folk, för det är de som vet var data skapas, lagras, transporteras och transformeras. Jag behöver 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.

Jag drivs av det där lilla pirret när man börjar ana hur saker hänger ihop. Det som 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 behövs 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.

Låt mig ge ett exempel. 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 användes för 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.

Det innebär 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 för att inte misstänkas för att vara 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. Vi kunde 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 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 publiceras 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.

Vad är Business Agility

Med Business Agility avses ett företags eller en organisations förmåga att snabbt anpassa sig till marknads- och omvärldsförändringar på träffsäkra och kostnadseffektiva sätt. Det är ett sätt att utveckla en verksamhet, att leda en organisation eller en grupp medarbetare, och att tillvarata kunskap.

Tre grundstenar

Det agila företaget vilar på tre grundstenar; utveckling av kollektiv intelligens, hypotesdriven utveckling och agilt ledarskap. I mötet dem emellan formas kultur och struktur.

Kollektiv intelligens

Kollektiv intelligens uppstår i olika grad när individer samarbetar i grupp för att lösa uppgifter. I organisationer och verksamheter verkar individer och grupper i komplexa sammanhang där lärande, återkoppling och intelligenta prestationer är en förutsättning för framgång. Denna intelligens ska inte ses som ett tillstånd, på det sätt som en individs intelligens kan uppmätas, utan som resultatet av den process där individer mer eller mindre framgångsrikt samarbetar. Utveckling av kollektiv intelligens skapar förutsättningar att tillvarata, integrera och kapitalisera på en mångfald av perspektiv och möjliggöra distribuerat beslutsfattande och genomförande.

Begreppet kollektiv intelligens myntades i boken ”Kunskapsintegration” skriven och Philip Runsten och Andreas Werr och författarna definierar begreppet på följande sätt: 

”En process i vilken ett antal interagerande individer, i en given situation, integrerar sina tillgängliga individuella kunskapsresurser, för att tolka och övervinna mångtydiga utmaningar, genom att använda en blandning av delat abstrakt tänkande och koordinerande handlingar ” 

Agilt ledarskap

Det agila ledarskapet är en process, eller interaktion, mellan ledare och ledda där de ledda har inflytande. Det agila ledarskapet är en förutsättning för att skapa en kultur som präglas av nyfikenhet, experiment och lärande.

I en agil organisation är de ledda inte passiva utan i allra högsta grad delaktiga i att skapa ledarskapet. Ledarskapet blir därigenom till och utvecklas i en relation av ömsesidig påverkan mellan ledda och ledare. Den kollektiva intelligensen gynnas genom växelverkan mellan ledare och ledda. Vi kan genom den växelvisa påverkan ta del av hela organisationens potential. 

Det agila ledarskapet behöver finnas i olika former och funktioner; ledningen av mig själv som individ, coachen som individer och team att lära och växa, mentorn som fungerar som lärare och i det formella chefskapet. 

I grunden baseras det agila ledarskapet, oavsett form och funktion, i självledarskap.

Hypotesdriven utveckling

Hypotesdriven utveckling är en av förmågorna för att nå Business Agility. Namnet leder oss direkt in på vad det handlar om – att driva sin utveckling utifrån en hypotes. Hypotesdriven utveckling sker på strategisk, taktisk och operativ nivå. Det behöver inte vara synonymt med strategisk, taktisk och operativa nivåer i en organisationsstruktur, men det kan vara det. Självklart kan det vara ett team, med alla ingående kompetenser, som hanterar samtliga nivåer.  

Vad är det då för hypotes och utveckling vi menar? Utvecklingen handlar i grunden om att utveckla befintliga eller nya värdeerbjudanden. I detta omfattas affärs-, verksamhet och IT-utveckling/digitalisering. Utgångspunkten tas i ett kund- eller brukarperspektiv i konsumtionen eller användningen av våra tjänster och produkter.  Hypotesen formuleras således utifrån våra antaganden om kundens eller brukarens önskemål kring dess.

Poängen med Business Agility

Business Agility bygger de förmågor som vi ser många aktörer, såväl inom privat som offentlig sektor, ha behov av. De förmågor vi syftar på är att:

  • snabbt kunna svara på marknadsförändringar där vi anpassar oss för att dra nytta av nya möjligheter med innovativa affärslösningar
  • kunna omvandla marknadsstörningar till konkurrensfördelar som leder till hållbar lönsamhet och ett backstage som följer marknadsförväntningarna
  • genom kundåterkopplingsdriven affärs- och verksamhetsutveckling stänga leveransgapet mellan kundförväntningar och leveransförmågan
  • skapa direkt koppling och återkoppling mellan företagets strategiska hypoteser och det operativa genomförandet för att snabbt kunna anpassa riktningen
  • ta tillvara på anställdas engagemang och potential för att få ut mer av den och skapa möjlighet till låg personalomsättning
  • främja en adaptiv organisationskultur som är motståndskraftig över tid och förändrade förutsättningar

Är detta förmågor din organisation vill träna upp? Kontakta oss!

Vad gör en verksamhetsarkitekt?

Vad är verksamhetsarkitektur?

För att kunna förklara vad en verksamhetsarkitekt gör behöver vi först klargöra vad verksamhetsarkitektur är.
Med verksamhetsarkitektur avses verksamhetens struktur, alla delar och hur de interagerar, samt gränsytorna mot omgivningen; kunder, leverantörer, partner mm. Verksamhetsarkitekturen beskriver vilka förutsättningar som finns i verksamheten, vilka förmågor verksamheten har, hur verksamhetens processer ser ut samt vilka informationsresurser och IT-stöd som hanteras i verksamheten. Med en väl dokumenterad arkitektur har vi en gemensam bild av verksamheten och en bra grund för beslutsfattande och effektivisering av verksamheten.

Varför verksamhetsarkitektur?

Syftet med verksamhetsarkitektur är att möjliggöra en snabb och enkel verksamhetsutveckling, åstadkomma hög informationskvalitet samt att se till att rätt system stödjer verksamheten.

Verksamhetsarkitektens uppgift

Verksamhetsarkitektens uppgift är att synliggöra och beskriva strukturen så som den ser ut, de värdeströmmar som finns, att visualisera målbilder och alternativa scenarios samt att ta fram en plan för hur vi ska kunna nå det önskade läget. 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 initiativ till verksamhetsutveckling och IT-satsningar i den riktning som verksamheten strävar.

Verksamhetsarkitektens verktyg

Verktygen verksamhetsarkitekten använder för att skapa bilden av verksamhetens delar och inbördes samband, är ofta olika typer av modeller. Det kan exempelvis vara processmodeller, informationsmodeller, förmågekartor, organisationsscheman eller systemkartor. Modellerna visar verksamheten utifrån olika perspektiv.

Vintergatan

IRM har arbetat fram en modell som vi kallar Vintergatan. Vintergatan är ett exempel på en förmågekarta som rymmer alla olika verksamhetsperspektiv i en och samma karta. Med kartan som underlag gör verksamhetsarkitekten en mängd olika analyser för att kunna se effekterna av olika typer av scenarios.

Utbildning

IRM har utbildat verksamhetsarkitekter sedan 1989. Tillsammans med DF Kompetens levererar vi utbildningen Certifierad Verksamhetsarkitekt. Sveriges största utbildning inom området.

Boktips

Vintergatan – din verksamhetskarta av Cecilia Nordén Visualising

Enterprise Design Patterns av Wolfgang Goebl, Milan Guenther, Annka Klyver och Bard Papegaaij

How to develop a Sustainable Digital Platform

By Eskil Swende and Svein Oliver Vedaa, IRM,

“The digital world is here but our old companies are simply not yet designed for digital.”
  – stated by Jeanne Ross in her new book “Designed for Digital”

The article below is based on our assistance since 2016 to the Data Architect at Cambridge University and their global assessment business. It is also based on our experience of more than 50 Business Architecture Plans developed for both Private and Public businesses in Scandinavia starting at Scandinavian Airlines (SAS) in 1980.

The development of our approach was inspired by the Swedish Professor Bo Sundgren and his close relationship with Ted Codd; the British mathematician that developed the Normalization Theory, that still is very important to achieve the sustainability in your IT Portfolio.

The authors Eskil Swende can be reached at eskil.swende@irm.se and Svein Oliver Vedaa at svein.oliver@irmconsult.no both looking forward to your comments!

1 Introduction

Your business may need to develop a new digital platform to replace your existing application-centric IT solution. Your current application portfolio may have reached a size and level of complexity that is expensive and difficult to develop further. You are then on a non-sustainable track. If you want your new digital platform to be sustainable, you have to be very careful and understand the capabilities needed to achieve such a sustainability.

This article does not cover the Information Technology needed to establish a Sustainable Digital Platform.

2 Why sustainability

In our rapidly changing environment the business, need to be agile. Our new digital platform must allow for changes in the Organization, the Business Processes and the Capabilities when new products or services are developed, and even when new strategies are decided.

A Digital Platform based on a high-quality Information Architecture is sustainable and flexible, allowing these changes to be made without adding complexity. Your Digital Platform will consist of a number of modules, where the same data is only captured and updated in one and only one module.

Allowing the same data to be captured in more than one module, may after a few years result in the same “unsustainable level of complexity” as your current IT systems have reached after 20+ years of application-centric development. (Further reading see 8.1)

3 Achieving sustainability

In your business, you may have 10.000+ different data elements like customer address or product price. To group these data elements into the correct module must not be done randomly. Together with your business experts, you, as an architect, must establish a number of Information Groups – say 30-50 groups, divided into Master Data like Customer, Personnel or Product and Event Data like Customer Order, Delivery or Supplier Invoice. (Further reading see 8.2)

Your information architecture must be based on your business, and not derived from your IT solutions. Your current IT solution came with an architecture often deviating from the one in your business.

The Business Model Canvas developed by Alexander Osterwalder is based on Building Blocks that easily can be related to your Information Groups. A new Value Proposition may reuse existing Building Blocks and existing Modules in your Digital Platform. This will add speed and keep complexity and Integration at a low level. (Further reading see 8.3)

Designed for Digital is a new book by Jeanne Ross, written for management to understand the importance of the digital transformation and to leave the application-centric legacy systems behind us. She was also co-author of EA as Strategy; the first management book to describe Business Modularity based on shared data. (Further reading see 8.4)

4 Consequences

A new sustainable digital platform has to be built from scratch. The existing legacy systems have to be eliminated step-by-step, and replaced by modules in a new digital platform. The current legacy system cannot be transformed into a digital platform in a step-by-step approach.

5 The Architecture and Development Cooperation

You will need a loose coupling between application and data. No application will be allowed to own its own data. Data is a common resource and will be available for all applications. Data bases will be designed and implemented based on the Information Groups.

You should establish a number of autonomous Development Teams. Spotify has several hundred teams working in three continents. You will need a number of teams to take care of applications and Information Groups. One team can have responsibility for one or more applications and one or more database (based in Information Groups). However, responsibility for one application or one database (Information Groups) must not be divided between teams. 

The development teams will have to work in close cooperation with the Business Architecture Team including Data and Process Architecture.

The autonomous development teams (Scrum) delivers speed and quality, the Business Architecture Teams secures direction, and a sustainable solution prepared for future changes. The Business Architect will support Development Teams, but also further develop the overall architecture. (Further reading see 8.5)

The Business Information Models are the key artefact to combine the Development with the Business Architecture. The Overall Business Information Model shows the total Digital Platform and the Detailed Business Information Models show the structure of each module.

One development team may be responsible for one Master Data Module like “Customer” or an Event Data Module like “Delivery”. An Event Data Module will be related to your Business Processes like the “Delivery Process”.

6 Ten Critical Success Factors

Many IT-managers, CIOs and CEOs agree that the old application-centric approach does not support a digital world. However, the transformation is very difficult and there is no guarantee for success. There are a number of very critical success factors (CSF) to handle when developing your future Sustainable Digital Platform.

Below we have listed and described some of these very critical success factors. You may try to evaluate them, discuss them, and start the transformation process being fully aware of which CSFs are most critical in your own busines

1. Executive level support

Develop a new sustainable digital platform; in order to achieve speed and high quality when delivering new customer values, will require full support and understanding from your executive management, all the way from the IT Manager and CIO to the CEO and the Board. Do not hesitate to keep them informed, and at the same time develop their capabilities in an area where they so far are not the experts.

2. Internal and external forces working against the digital transformation

In your business, you have many highly qualified people that daily depend on a set of application-centric solutions. A transformation from this old approach to something new, may cause a lot of internal fear and resistance. Try to engage them in the transformation and make them understand that the digital transformation is necessary for the survival of your business. Keep them informed and try to develop their capabilities. The Milky Way, described below, is a good way to engage everyone.

3. Financing the digital transformation

Long-term and stable financing of the Digital transformation is important. At the same time, you should reduce financing of the current legacy systems to a minimum – only covering very critical adjustments. When you finance your digital transformation, it is important to avoid sub optimisation that will lead to new application silos. Building on a common Business Architecture with a quality Information Architecture does not imply any common expensive infrastructure – it just stops you from financing redundancy and unnecessary complexity. 

4. Culture change

The hierarchical organization can be transformed into more self-organizing teams. Today the main knowledge exists down in the organization and less at the top and middle level. This transformation of decision-making must be aligned with a change of mind-set in the organization. IKEA is a global successful business based on a number of common culture principles established already 1976 by Ingvar Kamprad. Microsoft and the new CEO Satya Nadella is a current example of such a transformation of culture and new business model that goes hand in hand. (Further reading see 8.6)

5. Autonomous development team

Autonomous development teams with responsibility of both development and operation, makes it possible to deliver new customer values continuously, whenever they are ready to be released. In the classic application-centric approach a new release is risky and may take hours or days to accomplish, and will only happen a few times a year.

The autonomous team approach was first developed by Henrik Kniberg at Spotify and later also introduced at LEGO. Now it is widely introduced, at least in Scandinavia.

SBAB, a Swedish Bank, has established a number of development teams also responsible for the operations, called ”Dev-Ops” teams. It took them only one month to have a new product on the market and their market share grew in one year from 9 to 17%. So far, they have got rid of 50% of their old integration making the business very agile. The teams are very close to the market and deliver new customer values every day.

6. The Milky Way – map, navigate and accelerate change

The Milky Way is a method and navigational tool showing the work of the entire enterprise and how to move from strategic considerations to results. The tool demonstrates how processes, information and IT support work together to support the company’s value stream, and how the company interacts with its suppliers, partners and customers. It uses geographic maps as a metaphor to illustrate why and how an enterprise work. Building Milky Way models is largely done in workshops, where it becomes clear how different parts affect each other and how change initiatives can be coordinated. (Further reading see 8.7)

7. Common Information Model

Today many applications have their own data structures based on local data definitions, some of them are expressed explicitly, but most are only implicit. To make the transformation to a sustainable digital platform we need a common Overall Business Information Model (OBIM) divided into a number of Information Groups; some are Master Data, like customer or product, and some are Event Data like customer order, invoice or delivery. We call it an Information Model when it describes the business itself and a Data Model when it describes a specific IT Solution (existing or planned). These Information Groups are an important part of the information architecture. They are keys in design and planning to avoid data to be captured and managed by more than one development team. This avoids unnecessary duplication of work and solutions, and it saves complexity and money. Members of DAMA Chapter Scandinavia developed the OBIM approach in 2010.

8. Integration

The integration between the various Service Modules must be based on the Service Choreography approach with an Event Stream. Read more at https://specify.io/concepts/microservices#choreography.

An Orchestration approach may after a few years result in the same complexity as you have today, and it will not result in a sustainable digital platform.

9. Process Components and Processes/Capabilities

Today we have to provide a Process & Capability Architecture that works in large companies that may have development, production and deliveries of IT solutions in several countries.

Avoiding redundancy is necessary in order to achieve effectivity. We need to combine both reuse of solution at the same time as we offer easy adoption to local conditions. A set of Common process components will handle a well-defined part of the total business flow. They should be easily combined in many different ways where changes can be handled fast. This will create flexibility and a more agile business.

10. Application Lifecycle

To be able to replace existing applications, we need a good description of our application portfolio (both legacy and new). Stages in their lifecycle may be; 1. Under development, 2. Installed to be finished, 3. Installed and finished 4. To be replaced and 5. Planned to be replaced. To keep track of which Information Groups are handled in each specific application is a key factor to facilitate the transformation.

7 Summary – The Inca Foundation and your Platform Foundation

When building a sustainable house, the foundation is the most critical part. The Inca people learned that the hard way. Their foundation stones were cut so precisely, and wedged so closely together, that a credit card cannot be inserted between them. When an earthquake occurred, the stones in an Inca building are said to “dance;” that is, they bounce through the tremors and then fall back into place. Without this building method, many of the best-known buildings at Machu Picchu would have collapsed long ago.

When creating a sustainable Digital Platform, the foundation consists of a number of Information Groups; they will not dance when the “earthquake” happen. Instead, you may just add or take away a data element or an entity. You may even have to add or take away an Information Group. Then you may change the Platform to achieve new requirements needed to continuously deliver your new customer value.

To establish a Platform Foundation Capability may take some time. If you need any assistance, we may offer mentoring, education, second opinion or direct support; just send a mail to Svein Oliver Vedaa (svein.oliver.vedaa@irmconsult.no).

8 Further reading

Below we recommend some further reading.

If you do not know the reasons why we have a lot of problem with our current legacy systems, Dave McComb has made an excellent analysis in his book. You may also find an interview with him in TDAN.

Knowing these reasons will motivate you not to repeat these mistakes again!

  1. Software Wasteland – How the Application-Centric Mind-set is hobbling our Enterprises”, 2018, by Dave McComb. Know what´s causing application development waste so you can turn the tide.
  2. Overall and Detailed Business Information Models – Developed by the DAMA Chapter Scandinavia in 2010. http://tdan.com/defining-and-naming-data-models-related-to-the-zachman-framework/12655
  3. Business Model Generation – By Alexander Osterwalder in 2010. His Business Model Canvas (BMC) is very important when designing a new Sustainable Digital Platform
  4. Designed for Digital – How to Architect your Business for Sustained Success, by Jeanne Ross, 2019, also co-author of “EA as Strategy”. The Digital World is here but our old companies are simply not designed for digital.
  5. Agile EA in Practise – At Swedish Board of Agriculture (SBA) published in JEA, 2015, https://www.irm.se/2018/09/27/agile-in-practice/. This ambitious program at SBA may be regarded as a global breakthrough to achieve an Agile EA in Practice with the Chief Architect acting as the Program Manager.
  6. Hit Refresh – The Quest to Rediscover Microsoft´s soul” by Satya Nadella, CEO, 2017. He asked everyone to identify their innermost passions and connect them to the new mission and culture.
  7. The Milky Way – map, navigate and accelerate change – By Cecilia Nordén, 2019. It uses geographic maps as a metaphor. The work is largely done in workshop form, where it becomes clear how change initiatives can be coordinated and how to move from strategic considerations to results.

9 Your feedback!

So far, we have a lot of very useful comments, questions and feedback from our global network of experts.

Please, do not hesitate to mail us your comments, questions or other feedback on this article.

Our next article on “How to develop a Sustainable Digital Platform” will focus on the Information Modelling and Information Architecture including a number of example of Information Groups from various types of Business. Please send us your email address and we will mail you our draft before publishing.

Svein Oliver Vedaa: svein.oliver.vedaa@irmconsult.no

Eskil Swende: eskil.swende@irm.se

10 Bios

Eskil Swende, IRM Sweden

Eskil is a co-founder of IRM Sweden in 1982, a Scandinavian consulting company focusing on Business Architecture. He initiated the education of Certified Business Architects already 1991 and so far 1500+ Architects has been educated. He is now focusing on the business use of new technologies like digital development. Eskil has been mentor to the Data Architect at Cambridge University and their assessment business since 2017. It has resulted in an approach “How to Develop a Sustainable Digital Platform”. Our article is based on this approach. Eskil started DAMA Chapter Scandinavia in 1995 and was their President until 2016. He is also a co-founder of IRM UK and  has developed a global network of leading expert of EA. Eskil has written a number of articles for TDAN since 2008.

Svein Oliver Vedaa, IRM Norway

Svein Oliver founded IRM Norway in 2000. Already as a University student in the 80s, Svein Oliver was interested in data and information as the core of value creation within IT. Despite all the brilliant technology that has emerged since then, data and information must still be managed as a resource to fully exploit its value. He believes fully that we must start with architecture to accomplish this. Today he focus on architectural debt (inspired by the theory of technical debt) with the goal of designing sustainable digital platforms. Svein Oliver has participated in many business architecture projects, many of them in the Oil & Gas industry. The ground for a sustainable digital platform will be described in more detail in our next article for TDAN.

Download the article

Processutveckling- inte bara processer

Processutveckling handlar inte bara om processer. Syftet med processutvecklingen är ju att utveckla vår verksamhet, och tittar man närmare på en process så innefattar den så mycket mer; processen är en del av en verksamhets förmåga, den styrs av regler och är beroende av information i olika former och allt som oftast är det människor inblandade.

Så låt oss lyfta blicken och se det som den verksamhetsutveckling det är när vi snackar processutveckling.

Många av våra kunder vänder sig till oss när de behöver komma loss från gamla stela arbetssätt och system. Det kan upplevas som svårt att rulla ut på rätt bana för att nå sina mål och att realisera nya idéer.

9 checkpoints

För att veta att vi är på banan har vi identifierat 9 avgörande checkpoints längs utvecklingsresan:

  1. Vi vet varför vi beskriver våra verksamhetsförmågor eller processer och vad vi vill uppnå med det.
    Ett par frågor som ofta kommer upp inför ett utvecklingsarbete är: Varför gör vi det här? Kommer de metoder och arbetssätt vi har valt verkligen att ta oss dit vi vill?De är bra frågor, som tyvärr oftast tappas bort när man väl är igång med utvecklingsarbetet. Glöm inte; vi måste kontinuerligt ifrågasätta varför vi gör vi det vi gör – under hela utvecklingscykeln.
  2. Vi beskriver så mycket av vår verksamhet, omfattning såväl som djup, som syftet ställer krav på. Inte mer, inte mindre
    Är det en övergripande bild vi behöver? Eller är det detaljerade djupdykningar i specifika processer? Vad vi ska uppnå styr detaljgraden. Ett tips är att börja med att snabbt få upp en helhetsbild över verksamheten, t.ex. i form av en förmågekarta/Vintergatan och att därefter beskriva processflöden och informationsbehov för de mest prioriterade områdena.
  3. Vi har syftet i tankarna när vi kommunicerar vårt utvecklingsarbete; vem ska förstå och varför ska personen förstå våra verksamhetsbeskrivningar? 
    Gör arbetet visuellt och lätt att förstå. Använd verksamhetens eget språk och synliggör gärna synonymer så du når ut brett.
  4. Vi ser till att individerna känner igen sig i verksamhetsbeskrivningarna. Detta gör vi genom att involvera människor.
    När det gäller processer är det också viktigt att vi fokuserar på processernas resultat och vad detta resultat i nästa steg ska användas till. Det leder till en starkare känsla av delaktighet. Att som individ få vara med och skapa ett resultat föder så mycket mer engagemang jämfört med att bara utföra ett antal steg i en process.
  5. Vi förstår vår egen verksamhets ambition. 
    Hur processorienterade vill vi bli? Ska vi använda processer för att lösa ett specifikt problem eller utveckla ett visst verksamhetsområde? Eller vill vi gå mot en mer processorienterad organisation? Vill vi utse processägare etc.Om vi vill gå mot en mer processorienterad organisation måste vi se över vår incitamentsmodell. Vad belönar vi våra medarbetare för? För att de bidrar till att våra värdeflöden utvecklas och förbättras, eller att de håller sig inom sina organisatoriska ramar?
  6. Vi förstår att införandet av nya idéer i de flesta fall handlar om att människor behöver ändra sitt arbetssätt eller beteende och vi ser till att vi har rätt kompetens för att hantera detta. 
    I ett verksamhetsutvecklingsarbete har vi mycket fokus på människan och företagskulturen. Det gäller att säkra att rätt förutsättningar finns för förändringen. Vi använder gärna Kotters 8-stegsplan som stöd vid förändringsarbete. Det första steget är enormt viktigt: Förändringsarbetet ska kännas angeläget!
  7. Vi arbetar agilt med utveckling av vår verksamhet och vi levererar nytta i tydliga mindre leveransomgångar. 
    Detta är avgörande för att ha med sig alla på tåget och för att komma framåt utan obehagligt kostsamma överraskningar.
  8. Vi lär känna kunden, på riktigt!
    Kunskap om kunden är ovärderlig när vi utvecklar vår verksamhet. När vi väl förstår hur kunderna upplever sina resor i användandet av våra tjänster och produkter, så kan vi också lättare prioritera var vi ska sätta in vår egen utvecklingsinsats. Sluta anta kundernas upplevelse, ta reda på fakta istället!
  9. Information is da shit!
    Ja, ni har väl hört talas om datadriven verksamhetsutveckling? När vi utvecklar våra förmågor eller processer så måste vi förstå vilken information som är viktig; vilken information vi behöver, vilken information vi har, vilken information vi kan införskaffa och hur det ska gå till. Vi behöver också säkerställa att kvaliteten och tillgängligheten på vår information är tillräcklig för syftet. Alla i verksamheten använder information i det dagliga arbetet och omvandlar den för att dra nya slutsatser och starta nya aktioner. Att jobba informationsdrivet innebär att vi tar hand om informationen som genereras i verksamheten och medvetet använder den för att optimera våra värdeflöden och skapa nya värden. Så, att jobba med verksamhetsutveckling är lika mycket att jobba med informationsutveckling, glöm inte det alla verksamhetsutvecklare! 🙂

Kompetensutveckling

Om du vill få metoder och verktyg för att hålla utvecklingsinitiativen på banan – kolla in våra utbildningar inom process- och verksamhetsutveckling:

Certifierad verksamhetsutvecklare – en utbildning på tolv dagar uppdelade på sex tillfällen

Spela en avgörande roll och ta ett starkt grepp om verksamhetsutvecklingen. Denna utbildning är en skola med praktisk kundorientering.  För att hänga med i dagens snabba utvecklingstakt och för att kunna öka kundnöjdheten och den interna effektiviteten ställs nu mer än tidigare krav på en kontinuerlig och lättrörlig verksamhetsutveckling. Certifierad verksamhetsutvecklare ger dig kompetensen att utveckla processer, tjänster och förmågor samt att leda förändringen. Certifierad verksamhetsutvecklare – ubildningsbeskrivning

Processutveckling – en kurs på två dagar

Lär dig kartlägga och beskriva processer. Genom att kartlägga hur vi jobbar för att uppnå kundvärde, identifiera målen för varje process och sedan införa mätetal får vi en nödvändig grund för att styra verksamheten emot övergripande mål. Kursen bygger på en väl utprövad teoretisk grund i kombination med praktisk processutveckling. Du får mycket övning samt tillfälle att reflektera över konkreta exempel och ta lärdom av praktisk erfarenhet från verkliga case. Kursen ger dig förmågan att praktisera dina nya kunskaper på ett professionellt sätt, direkt i din egen verksamhet. Processutveckling – kursbeskrivning

Informationsmodellering – en kurs på två dagar

Lär dig att identifiera, definiera och strukturera information i modellform genom övningar. Du får lära dig teorin bakom objekt, relationer och nycklar, och vi ger även en genomgång av informationsmodellens användning och visar på samband med förmågemodellering och processutveckling. Informationsmodellering – kursbeskrivning

Vintergatan – en kurs på 2 +1 dag

Lär dig ta fram en översiktlig bild över hela eller delar av din egen verksamhet i en förmågekarta. Modellen har en unik syn på verksamhetsutveckling och låter dig kombinera och visualisera flera perspektiv i samma karta som processer, business capabilities, applikationssystem, kundresor, etc. Vintergatan – skapa din verksamhetskarta – kursbeskrivning

Vi levererar våra utbildningar i samarbete med Dataföreningen Kompetens AB

Vad innebär det att arbeta som verksamhetsutvecklare?

Ett frukostseminarium med inblick i en verksamhetsutvecklares vardag.

En regnig morgon i början av mars gav Lena Dohrnér och Johanna Aadde från IRM tillsammans med Isabel Blomqvist från Arbetsmiljöverket ett stort antal intresserade inblick i verksamhetsutvecklarens vardag, samt en kort presentation av utbildningen Certifierad verksamhetsutvecklare.

Vad innebär det att vara verksamhetsutvecklare?

Som svar på seminariets största fråga Vad innebär det att vara verksamhetsutvecklare? Inledde Johanna Aadde med att visa på verksamhetsutvecklingens bredd. Det handlar om så mycket; processutveckling, förändringsledning, tjänsteutveckling, kartläggning, kravställning, mm, men framför allt handlar det om människor.

”Att verksamhetsutveckla utan att ha med sig människorna i förändringen är värdelöst”

För att beskriva hur utbildningen Certifierad verksamhetsutvecklare fångar rollens alla perspektiv presenterade Johanna och Lena utbildningens sex avsnitt, sk ”block”. Sammantaget bygger de upp det helhetsgrepp och den verktygslåda en verksamhetsutvecklare behöver för att lyckas med förändringsinitiativ.

Helhetsperspektivet är viktigt i utbildningen. Verksamhetsutveckling handlar om att utveckla organisationens olika förmågor. Som verksamhetsutvecklare behöver vi kunna ta reda på var i förmågan det brister utifrån en mängd olika perspektiv; affärsmål, klimatmål, trender, arbetsmiljö mm.

Verksamhetsutvecklare på Arbetsmiljöverket arbetar behovsdrivet

Isabel Blomqvist från Arbetsmiljöverket gick utbildningen Certifierad verksamhetsutvecklare under hösten 2018. Sedan dess har hon tillsammans med sina kollegor kommit in i en intensiv förändringsperiod. I och med att många av Arbetsmiljöverkets regler skrivits om samtidigt som alla verkets kontor ska bytas ut och att det nu finns en nollvision för arbetsplatsolyckor så är det mycket som ska förändras. Nya processer, metoder och arbetssätt ska sättas och it-stöd ska utvecklas. ”Det känns lite som i tomtens verkstad dagarna innan jul” sa Isabel Blomqvist.

För Isabel och hennes team innebar detta mycket kartläggning. Ett behov av att se hur fungerar det idag och hur vill våra användare att det ska fungera i framtiden. Här lyfter Isabel fram ett verktyg från utbildningen som varit avgörande – Tjänstedesign. Metoden som kartlägger kundresan och som snabbt avslöjar brister och klargör användar- och kundbehov. Metoden gav Isabel och hennes team ovärderliga insikter i var de största utvecklingsbehoven fanns.

Många workshops har det varit. ”Jag tyckte jag var bra på att leda workshops innan, men har blivit ännu bättre efter utbildningen”. Under utbildningen får man mycket träning i att planera och leda workshops för att driva arbetet effektivt framåt.

Läs mer om utbildningen här.

En gemensam bild av verksamheten gör oss mer framgångsrika

Att inom organisationen ha en gemensam bild över var vi är och vad vi gör är en förutsättning för att lyckas skapa en framgångsrik verksamhet. På samma sätt som en grupp människor i skogen snabbare når sitt mål om alla utgår från samma karta så blir organisationen mer effektiv om vi har en samstämmig bild av verksamheten, dess utgångsläge och vart vi är på väg.

Det är lätt att tro att bilden jag har av min verksamhet och hur vi tar oss framåt, är densamma som min kollega har. Men faktum är att den bilden många gånger ser väldigt olika ut beroende på vem i organisationen man pratar med.

Om vi har olika utgångspunkter med olika mentala bilder av var vi är tar vi olika vägar mot målet. Vi ser olika hinder på vägen och navigerar olika. Det medför även stora problem med att försöka koordinera alla med olika bilder att ta sig till samma mål.

En förutsättning för att lyckas

Att ha en gemensam bild över var vi är och vad vi gör är en förutsättning för att lyckas med en verksamhet.

På samma sätt som en grupp människor i skogen snabbare når sitt mål om alla utgår från samma karta och går åt samma håll, så blir en organisation mer effektiv om vi har en samstämmig bild av verksamheten och dess utgångsläge.

Samsyn är grunden. När vi skapat samsyn är alla  på samma bana ,och vi kan navigera, prioritera och styra mer effektivt. Vi är därmed rustade för att lyckas genomföra snabbare förändringar och snabbare kursändringar.

Förenkla och förtydliga en komplex verklighet

För att uppnå samsyn använder vi oss av modeller av olika slag. Att ta fram en modell eller karta är att skapa ett verktyg för att förstå en komplex verklighet. För att förstå behöver vi kunna se samband. För att göra det tydligt behöver vi förenkla, lyfta fram vissa delar och tona ned andra.

Därför är det inte så konstigt att vi använder en mängd olika modeller för att beskriva en verksamhet; hur vi arbetar, vilken information vi behöver, hur IT-lösningarna ser ut eller hur vi organiserar oss. Dessa modeller används i sitt sammanhang för att klargöra ett visst område och fyller sin uppgift inom den delen. Men hur hänger dessa modeller samman? Hur navigerar jag mellan dem? Exempelvis – Hur avgör jag vilka delar av verksamheten som påverkas av företagets nya vision?

Vintergatan – en karta, en modell och en metod

IRM har arbetat fram en metod och en modell, en sorts karta som innehåller just alla dessa perspektiv och som tillåter oss att navigera mellan dem. Vi kallar den Vintergatan.

Den visualiserar en organisations olika funktioner som förmågor i ett cirkulärt, kretsloppsliknade system. Vintergatan ger en tydligare, kraftfullare överblick och bättre kapacitet att navigera och arbeta strategiskt med verksamhetsutveckling inom organisationen. Vintergatan är också en metod som förenklar den del av verksamhetsarkitekturarbetet som visas upp mot verksamheten och bidrar till förståelse för de konsekvenser ett förändringsarbete kan få för andra delar organisationen.

Pension & Försäkring i SEB började kartlägga sin verksamhet och navigera utifrån Vintergatan i samband med en stor översyn av föråldrade IT-stöd.

” När jag först kom i kontakt med Vintergatan kände jag, wow, det här kan verkligen hjälpa oss att överbrygga gapen i vår verksamhet och ge oss bättre verktyg för att ta mer medvetna designbeslut. Vi började först använda den för att skapa övergripande analyser.”  – Cecilia Klöfverskjöld Nyberg, Pension & Försäkring i SEB.

Läs mer om SEBs erfarenheter av Vintergatan

IRMs kunder delar med sig av sina erfarenheter av Vintergatan:

För de som snabbt vill få upp en första version av en Vintergata över hela eller delar av sin verksamhet så rekommenderar vi vår öppna kurs som vi levererar i samarbete med Dataföreningen kompetens. 

Läs kursbeskrivningen och se kommande kursdatum för Vintergatan – skapa din verksamhetskarta.