Förmågekartor för informationsarkitektur – del 10: Mönster för den storskaliga strukturen
Hur fångar vi vår verksamhets struktur i vår karta? Hur ser vi skogen för alla trän? Vi kan ta hjälp av strukturmönster som återkommer i våra verksamheter.
/Peter Tallungs, IRM 2023-03-09
Varje verksamhet har en egen struktur. Verksamhetsförmågorna har operativa beroenden till varandra som ger en ordning som utmärker just den verksamheten.
Varje verksamhet har en unik operativ uppbyggnad, men det finns generella mönster som återkommer. Strukturella mönster, som uppträder tvärs över alla branscher.
Om vi känner igen dessa mönster kan vi lättare få syn på och förstå vår verksamhets särskilda struktur, som är ett specialfall av ett sådant mönster, eller ibland en kombination av flera mönster.
Då kan vi lättare och tydligare analyserar och avbilda vår verksamhet i en förmågekarta. Vi får en gemensam karta över verksamheten, som har en logisk struktur som stämmer överens med hur verksamheten fungerar. Kartan blir på så sätt logisk, tydlig och användbar, det vill säga en sann och tydlig representation av hur verksamhetens olika delar hänger ihop. Med en sådan övergripande struktur ser vi ”skogen för alla träden”. Vi får inte en slumpartad samling av förmågor utan en struktur som förmedlar den mening som finns i verksamheten.
Jag menar att vi som arkitekter har en fundamental uppgift att utveckla och etablera en sådan gemensam bild och struktur, som förmedlar den övergripande operativa verksamhetslogiken, så att vi kan se och förstå den ”maskin” eller ”ekosystem” som en verksamhet i grunden är.
Var hittar man dessa mönster?
Mig veterligen har ingen beskrivit sådana mönster någonstans. Därför vill jag redovisa de mönster jag har kommit fram till i mitt eget arbete med olika verksamheter. För när jag tittar på de förmågekartor jag ritat genom åren så ser jag att de kan kokas ner till ett fåtal generella strukturmönster som återkommer.
Hur kan man beskriva mönster?
Men först något om hur man kan beskriva mönster på ett strukturerat sätt. Detta går tillbaka till byggnadsarkitekten och designteoretikern Christopher Alexanders arbeten på 70-talet. Det var han som formulerade idén med det han kallade designmönster. I enlighet med detta beskriver jag här varje mönster med rubrikerna namn, generellt problem som mönstret löser, den generella lösningen, exempel på lösningen, samband till andra mönster samt kommentarer. Alexanders tanke är att en uppsättning gemensamt förstådda och namngivna mönster tillsammans bildar ett språk (ett ”pattern language”) för oss inom ett område, för att diskutera och värdera olika lösningar på designproblem.
I en föregående artikel i denna serie ”Förmågekartor för informationsarkitektur – del 7: Integrationskartan” beskrev jag hur jag vanligen placerar förmågorna i kartan i tre horisontella rader, uppifrån och ner. Det är inte viktigt att det just är uppifrån och ner, men låt mig använda den geografin i denna artikel, för enkelhetens skull. Jag ser det som ett lämpligt grundmönster att på detta sätt se en verksamhetsstruktur som skiktad. Vi har således vårt första mönster, mönster 0, Tre-skiktad verksamhet, vilket är det första mönstret som presenteras här nedan. Det är ett grundmönster, så till vida att de följande mönstren 1–4 är varianter på detta.
Mönster 0 (grundmönster): Tre-skiktad verksamhet
Problem
De direkta beroendena mellan verksamhetsförmågor följer ofta ett mönster. De förmågor som direkt tjänar externa intressenter (som till exempel kundtjänst) bildar en kategori. De har beroenden till de förmågor som står för de centrala operativa funktionerna (det vill säga själva produktionen av det som verksamheten gör). Den motsatta riktningen av beroenden är mer sällsynt.
Båda dessa kategorier av förmågor har beroenden till en tredje kategori av förmågor, de som tillhandahåller stödfunktioner som används på många ställen.
Dessa kategorier är viktiga att tydliggöra, och det av flera skäl. De har generellt olika karaktärer och olika livscykler, och måste därför förstås och hanteras på olika sätt. Fast det viktigaste skälet att särskilja dessa är nog hur beroendena går. Ty beroenden styr hur vi kan hantera verksamheten på ett strukturerat sätt, inte minst då det gäller när vi ska utveckla verksamheten. Det är därför viktigt att den strukturen finns representerad i våra förmågekartor. Hur gör vi det?
Lösning
Inför en skiktad struktur i din förmågekarta som visar denna skiktning i verksamheten. Du gör det lämpligen genom att placera förmågorna i separata rader i kartan.
Du bör ge skikten namn. Till exempel:
- Front capabilities (eller Customer facing capabilities, Frontoffice, eller liknande)
- Main capabilities (eller Business kernel, eller liknande)
- Supporting capabilities (eller Business infrastructure)
Exempel
Alla verksamheter kan ses som att de har dessa tre skikt. Alla verksamheter har mer eller mindre förmågor som direkt tillgängliggör tjänster för sina kunder, eller ”kunder” i vid mening, det vill säga de som är beroende av de tjänster man tillhandahåller. Alla verksamheter har sedan centrala förmågor som är de som gör det jobb som är centralt för denna verksamhet. Sedan finns det stödfunktioner, ofta ett stort antal, som ofta används på många ställen i verksamheten.
Samband med andra mönster
De efterföljande mönstren som beskrivs i denna artikel är alla möjliga varianter på detta grundmönster.
Kommentar
Man ser ofta förmågekartor som utöver dessa kategorier har förmågor för Ledning och styrning (Management). Det är visserligen förmågor i en mer allmän betydelse av termen, men inte i den mening vi använder termen här. Ledning och styrning är inte några avgränsade autonoma förmågor, utan aspekter som är integrerade i alla förmågor. Därför behöver de inte ritas ut. Det ligger i själva begreppet att vara en avgränsad autonom del, att den har sin egen ledning och styrning. Varje förmåga är till sin kärna operativ, men har också sin egen inbyggda ledning och styrning. Det finns förstås också en ledning och styrning som omfattar hela verksamheten, men eftersom kartan är fraktal så är även hela verksamheten en operativ förmåga i sin egen rätt, och har en egen ledning och styrning inbyggd utan att vi behöver peka ut den.
Jag har ibland sett att man även har en förmåga som heter ”Utveckling”. Men jag menar att varje förmåga behöver ha, och har i praktiken, om verksamheten har kunnat anpassa sig till en föränderlig verklighet, sin inbyggda förmåga att utveckla sig, och ibland även sin omvärld. Utveckling omfattar många saker och ses lämpligen som en del av ledning och styrning.
Men det finns förstås ofta förmågor som utgör stöd för den ledning och styrning samt utveckling som alla de andra förmågorna behöver ta eget ansvar för. Men dessa förmågor är i så fall stödförmågor. De stödjer den ledning, styrning och utveckling som sker i varje förmåga. Det är skillnad på att stödja något och att ansvara för detsamma.
Ibland ser jag att man har specifika it-förmågor. Men jag tycker även här att dessa bör ses som integrerade delar i varje verksamhetsförmåga, om det inte handlar om specifika stödförmågor som till exempel någon som tillhandahåller en specifik teknisk kompetens till många andra förmågor.
Jag tycker att detta är ett vanligt missgrepp, att blanda ihop vad som är stöd till något med vad som verkligen är ett ansvar för något.
Mönster 1: Shared front – Shared main (Homogen verksamhet)
Problem
Många verksamheter är enkla. En sådan verksamhet har en homogen grupp av intressenter som använder dess tjänster och ungefär samma återkommande behov hos dessa. Hur representerar vi det i förmågekartan?
Lösning
Låt alla tre skikten vara obrutna
Exempel
En restaurang, tillhandahåller mat och restaurangupplevelser till sina gäster. Om man inte har andra tjänster som till exempel catering så tillhandahåller man endast en typ av tjänster till en typ av intressenter.
Samband med andra mönster
Detta mönster är en av flera möjliga varianter av Mönster 0 (grundmönster): Tre-skiktad verksamhet.
Kommentar
Obrutna skikt är mindre vanligt än man kanske tror. Ofta har man flera typer av kunder (eller ”kunder”, intressenter som man vill se som kunder i bred mening) vars behov man behöver tillgodose med olika typer av tjänster. I så fall är något av de övriga mönstren som presenteras här tillämpligt.
Mönster 2: Split front – Shared main (Gemensam basfunktionalitet)
Problem
En del verksamheter tillgodoser olika kategorier av intressenter med olika behov, men vars olika behov möts av en i grunden gemensam funktionalitet. Hur strukturerar vi förmågekartan för att visa den strukturen?
Lösning
Dela upp front-skiktet i två eller fler separata kolumner, en för varje kategori av intressent på kund-sida, men låt main-skiktet vara gemensamt.
Exempel
Arbetsförmedlingen har två kategorier av kunder; arbetsgivare som tillhandahåller arbetstillfällen, och arbetssökande som söker arbetstillfälle. Arbetsförmedlingen tillhandahåller helt olika tjänster för dessa två kundkategorier, men sedan möts deras olika behov i gemensam verksamhetslogik för att matcha deras behov mot varandra.
En restaurang erbjuder både restaurangbesök, hämtmat och catering. De centrala förmågorna är då samma; inköp och lagring av råvaror samt tillredning. Men kunderna måste mötas på helt olika sätt; bordsbokning med matsal och bordsservering, hämtmat med beställning och utlämning, och catering med beställning och leverans.
Samband med andra mönster
Detta mönster är en av flera möjliga varianter av Mönster 0 (grundmönster): Tre-skiktad verksamhet.
Kommentar
Det här är en av de varianter av brutna skikt som är vanligt bland våra verksamheter.
Mönster 3: Shared front – Split main (One-stop shopping)
Problem
En del verksamheter tillgodoser en enda kategori av intressenter, men de kan ha behov helt olika tjänster vilka behöver hanteras av olika typer av funktionalitet. Man vill möta samma kategori av intressenterna på ett enhetligt sätt, trots att de behöver olika tjänster vid olika tillfällen.
Lösning
Håll ihop front-office men separera main-skiktet i två eller fler separata kolumner, en för varje kategori av behov som behöver hanteras separat.
Exempel
En kommun strävar efter att ha en och samma ingång, en kundtjänst, där man samlar alla tjänster man erbjuder medborgarna. Men de tjänster man erbjuder behöver sedan hanteras helt olika beroende på kategori av tjänst. Principen kallas ibland one-stop-shopping, då man vill att medborgarna ska kunna göra allt på ett ställe, det vill säga allt som kommunen erbjuder, oberoende av vad det gäller.
Skadeverksamheten hos ett sakförsäkringsbolag hanterar skador på både personer, djur och föremål. Enklare skador, som cykelstöld, kan man ta hand om redan i kundtjänst. Mer komplicerade skador behöver slussas inåt i organisationen och hanteras av specialiserade back-office-funktioner, kanske en för motorskador, en annan för personskador, en tredje för djurskador och en fjärde för egendomsskador.
Samband med andra mönster
Detta mönster är en av flera möjliga varianter av Mönster 0 (grundmönster): Tre-skiktad verksamhet.
Kommentar
Det här är en annan av de varianter av brutna skikt som är vanligt bland våra verksamheter.
Mönster 4: Split front – Split main (Skilda verksamheter)
Problem
En del organisationer tillgodoser flera olika kategorier av intressenter, som var och en har skilda behov av lösningar, som man både behöver möta på olika sätt, och sedan även hantera på olika sätt. Det betyder att man i praktiken har flera separata verksamheter, men som kanske delar en del infrastruktur, som olika stödförmågor. Men det är ändå önskvärt att representera detta i en och samma förmågekarta, för att se hur de olika verksamheterna delar på samma stödförmågor. Hur gör man?
Lösning
Separera både front-skiktet och main-skiktet i två eller fler separata kolumner, en för varje kategori av intressenter som behöver hanteras separat.
Exempel
En och samma organisation har egentligen två skilda verksamheter, utan mycket samband med varandra, men vi vill ändå hålla ihop dessa. Detta händer om en och samma myndighet hantera mer eller mindre separata behov hos mer eller mindre separata kategorier av intressenter.
Det kan också hända när man slår ihop två företag utan att integrera dessa fullt ut. Antingen för att deras olika verksamheter verkligen har olika behov eller för att man inte lyckas integrera dessa. Man kan ändå få fördelar av att dela stödfunktioner.
Samband med andra mönster
Detta mönster är en av flera möjliga varianter av Mönster 0 (grundmönster): Tre-skiktad verksamhet.
Kommentar
Vi behöver överväga om vi ska hantera denna verksamhet som två helt skilda verksamheter, som det ju de-facto handlar om. Men kanske vi har ett behov av att hantera gemensamma stödförmågor som en gemensam tillgång, och därför ändå vill hålla ihop det i en och samma förmågekarta.
Kombination av mönster
I våra verksamheter är ofta dessa mönster kombinerade på olika sätt. Vi kan ta ett exempel där man på högsta nivån har Mönster 4 (Split front – Split main (Skilda verksamheter)). Då är det vanligt att man har stödförmågor på två nivåer. Dels stödförmågor för hela verksamheten och dels stödförmågor för en del av verksamheten.
Exempel: Ett it-konsultbolag har två olika verksamheter: konsultverksamhet och utbildning. Man har stödförmågor som är gemensamma, som Ekonomi, HR, Administration, med flera. Fast sedan har utbildningsdelen, om man bryter ner denna, vissa egna stödförmågor så som Hantering av utbildningslokaler, Stöd för lärare och handledare, Bokning av kurser, Framtagning av utbildningsmaterial, med mera. Andra stödförmågor är specifika för konsultverksamheten.
Det är mycket vanligt att det finns stödförmågor på olika nivåer i en verksamhet.
Sista artikeln om förmågekartor
Detta är den tionde och sista artikeln i serien ”Förmågekartor för informationsarkitektur”. Jag hoppas att artiklarna kan inspirera till hur du kan använda mer rika förmågekartor, som verkligen avbildar verksamhetens struktur och hur de olika delarna samverkar i denna.
Behovet är mycket stort hos våra verksamheter att kunna kartlägga hur data och information av olika slag strömmar i en verksamhet, och vi behöver ett sätt att rita verksamhetskartor som fungerar för det. Det här är det enda sättet jag vet.
Du får gärna bidra till utvecklingen genom att berätta hur du gör i din verksamhet och hur det fungerar. Det här är ett område som behöver utvecklas och det kan bara göras genom att vi delar kunskap och erfarenheter fritt. Jag skulle vilja att de här artiklarna inspirerade till en sådan dialog bland oss alla som arbetar inom området.
Nästa artikel kommer att handla om något helt annat.
/Peter Tallungs, IRM
Välkommen att maila mig på peter.tallungs(at)irm.se eller kommentera artikelns post på IRM:s linkedin.
Vill du prenumerera på denna artikelserie? Det innebär att du får ett nyhetsbrev, samtidigt som vi publicerar en ny artikel i ämnet informationsarkitektur, med länk till den senaste artikeln. Skriv ett mail till info@irm.se med namn och e-postadress. Skriv IA-artikelserie i ämnesraden.
