Resan från förmågekartor till verksamhetskarta

Förmågekartor sägs beskriva vad en verksamhet gör, inte hur. Men vad kan betyda olika saker. Läs om hur vi strävat mot att reda ut begreppen runt verksamhetsförmågor. Och om hur vi steg för steg utvecklat vårt sätt att beskriva verksamheter till där vi är idag.

Hur det började

För 15 år sedan, runt 2011, började det bubbla kring ett nytt sätt att analysera och beskriva verksamheter: Business Capability Maps, eller förmågekartor. De sades beskriva vad en verksamhet gör snarare än hur.

Detta väckte vårt intresse. Vi hade sedan 80-talet haft processmodeller för att beskriva hur något utfördes. Och sedan 70-talet informationsmodeller som visade vilken information man hanterade.

Vi såg något vi saknat, möjligheten att beskriva verksamheten i sig själv, hur den i praktiken fungerade operativt i sina olika delar. Viktigt var framför allt att kunna visa hur dessa delar var integrerade med varandra och omgivningen.

Men snart uppstod frågor. Vad menade man egentligen med en verksamhetsförmåga? Hur relaterade verksamhetsförmågor till processer, organisation och andra aspekter på en verksamhet?

I denna artikel vill jag belysa hur jag och mina kollegor resonerat kring dessa frågor och vad vi så småningom kom fram till. Det har varit en resa i flera steg.

Artikeln vill också visa hur vi först gick vidare från konventionella förmågekartor till mer utvecklade sådana. Samt var vi är idag, hur vi landat i något annat, det jag idag kallar för verksamhetskartor.

Det började med ett antal frågeställningar.

Hur förhöll sig förmågor till processer?

Runt 2011 tänkte vi, liksom många andra vid den tiden, att förmågeperspektivet kunde fylla ett behov vi såg. Att det kunde bli en grund för vårt arbete med att analysera och utveckla verksamhet och it som en helhet.

Det första som hände var att vi mötte invändningar från mer erfarna kollegor. De menade att detta behov redan var fyllt. Vi hade ju redan processkartor. Var inte verksamhetsförmåga egentligen bara ett nytt ord för process? Varför uppfinna något som redan fanns?

Vi förbryllades, men förstod snart vad motståndet handlade om. Det visade sig att de mer erfarna kollegorna länge sett delvis samma behov, att kunna skapa överblick över en hel verksamhet. Det de hade till hands var processer, och deras lösning hade då blivit att utvidga processbegreppet. De hade på så sätt börjat använda processer inte bara för hur saker utfördes utan också som byggstenar för en övergripande beskrivning av en verksamhet.

De hade då behövt utvidga begreppet verksamhetsprocess så att det kunde omfatta även sådant som inte var processer i dess ursprungliga och etablerade mening. På så sätt kunde man omfatta även sådant som vi nu ville se som verksamhetsförmågor.

Processer i ursprunglig mening I sin ursprungliga och etablerade mening beskriver en process hur ett objekt av något slag går igenom ett antal steg, där objektet förändras och förädlas över tid. Detta gäller både för processer i naturen, som till exempel fotosyntesen i växternas blad, och processer i processindustrin, som till exempel produktion av pappersmassa genom kokning av träflis, blekning och torkning. Denna definition gäller också för processer i våra administrativa verksamheter, även om de objekt som förädlas i dessa sammanhang vanligen är mer immateriella och abstrakta. Objektet i fråga kan till exempel vara ett kundbehov som blir känt och hanteras i fler steg till dess att behovet är tillgodosett.

De hade alltså börjat använda processbegreppet för i stort sett vad som helst i en verksamhet som kunde avgränsas och hade mening.

Vi menade att begreppet process då användes till sådant det var mindre bra för, sådant som inte kunde ses som ett antal tydliga steg. Funktioner som Marknadsföring, Försäljning, Ekonomi och Personalhantering kunde av dem kallas processer. Dessa kunde dessutom, vid utzoomning, samlas som delprocesser i än större processer.

Man hade sålunda lämnat det egentliga processbegreppet. Ty marknadsföring kommer bara före försäljning i en mycket abstrakt mening, och inte som steg i en och samma process. Marknadsföring skapar visserligen möjligheter till försäljning, så de finns ett visst beroende. Men mycket säljs utan föregående marknadsföring, så de kan inte sägas vara steg i en och samma process.

Vår åsikt var att vi inte ville överanvända processbegreppet. Vi menade att vi borde använda respektive verktyg för det som det är lämpat för, inte göra det alltför fluffigt. Processmodeller var användbara för att beskriva hur något gick till. Men inte för övergripande beskrivningar av en verksamhet. Då behövde vi i stället något i stil med vad vi då såg som förmågekartor.

Vi gick nu vidare på vår upptäckarresa. Det fanns fler frågor om termen verksamhetförmåga och hur den användes i olika betydelser. Tvetydigheten och förvirringen gjorde att man kunde ifrågasätta om termen egentligen var användbar för det vi eftersökte.

Hur förhöll sig förmågor till funktioner?

Den första tiden letade vi fram allt som skrevs om detta nya perspektiv. Vi ville verkligen förstå. Alla som hade skrivit något om det var överens om att en förmåga beskrev vad och inte hur. Men detta framstod för oss som otillräckligt och kunde knappast vara hela svaret. För vad kunde, om man tittade närmare, betyda olika saker.

Det visade sig att det i litteraturen, både från akademin och bland praktiker, fanns två olika läger med olika syn på vad en verksamhetsförmåga var. Skiljelinjen verkade gå mellan de som främst arbetade med affärsutveckling och de som sysslade med verksamhetsarkitektur.

Bland aktörer inom affärsledning och affärsutveckling definierade man en förmåga som vad en verksamhet behövde kunna göra. En förmåga kunde till exempel vara att ta hand om personal i verksamheten, en annan att ta hand om ekonomin.

Bland verksamhetsarkitekter handlade det i stället om hur en verksamhet var uppbyggd, alltså vilka avgränsade delar den bestod av.

Nu är det lätt att tro att den skillnaden bara var en lek med ord, att det fanns en ett-till-ett-koppling mellan vad verksamheten gjorde och hur den var uppbyggd.

Men så var det inte. En HR-funktion är ett bra exempel. Det är lätt att tro att den ”tar hand om personalen”. Men det ansvaret finns egentligen inte hos HR utan i stället hos alla i organisationen med någon form av personalansvar. HR:s roll är begränsad till att stödja personalansvariga i sina uppgifter.

Samma sak gäller ekonomin. Ekonomifunktionen har inget egentligt ansvar för företagets ekonomi, utan stödjer alla roller i organisationen som har någon form av ekonomiansvar.

Alltså, så här långt kommet fanns det två olika saker som termen ”verksamhetsförmåga” kunde betyda. För affärsfolk kunde det handla om vad verksamheten behövde åstadkomma. För verksamhetsarkitekter kunde det handla om hur en verksamhet var uppbyggd av avgränsade delar, funktioner om man så vill.

När samma ord betyder olika saker Än idag ser man ibland den ena definitionen av verksamhetsförmåga, ibland den andra. Och inte så sällan båda två i samma mening, vilket blir en självmotsägelse. Jag tror det är viktigt att vi är noga med begreppen så vi slipper simma i en semantisk soppa, där vi pratar förbi varandra eller upptäcker först långt senare att vi talat om olika saker. Med ett mer krispigt och exakt språk blir alla våra dialoger mer produktiva.

Hur kunde då denna förvirring uppstå, och hur kan den fortsätta?

Det fanns förstås en koppling mellan dessa två betydelser, men det betydde inte att denna koppling var ett-till-ett. För en och samma förmåga, i betydelsen vad vi behöver kunna göra, krävdes det vanligen flera förmågor, i betydelsen avgränsade delar av verksamheten, som tillsammans kunde bidra.

Att två olika communities gav termen olika betydelser var förklarligt då de var helt fokuserade på olika aspekter av våra verksamheter. Affärsutveckling handlade om de stora existentiella frågorna: Vilka är vi? Vad erbjuder vi? Vilka finns vi för? och Hur når vi dessa parter?

För oss som jobbade med verksamhetsarkitektur var det i stället det andra perspektivet, det som beskrev hur verksamheten var uppbyggd och fungerade operativt, som hade fokus. Vi behövde kunna skapa en karta över verksamheten, se maskineriet eller ekosystemet, vilka olika delar det bestod av och hur delarna relaterade operativt till varandra och till omgivningen.

Men för denna andra betydelse, den vi som arkitekter var intresserade av, var namnet ”förmåga” egentligen illa valt, eftersom den allmänna betydelsen av termen handlade om vad någon eller något kan och inte hur man är organiserad för att åstadkomma detta något.

Det hade i andra sammanhang använts andra namn för det vi var intresserade av, dessa avgränsade byggklossar i en verksamhet.

Roger Sessions introducerade termen Autonomous Business Components i sin bok Simple Architectures for Complex Enterprises. Inom systemteori för organisationer pratade man om system och delsystem i denna mening. I äldre varianter av verksamhetsarkitektur pratade man om verksamhetsfunktioner. Om jag fått välja skulle jag kallat det vi är ute efter för verksamhetsfunktioner.

Varför jag säger verksamhetsfunktion Jag har genom åren försökt etablera termen verksamhetsfunktion i stället för verksamhetsförmåga för de delar en verksamhet är uppbyggd av. Men det är svårt. Termerna business capability och verksamhetsförmåga har fått fäste, trots tvetydigheten. Fast är vi verkligen betjänta av en sådan luddighet? Är det inte viktigare att vi reder ut detta ordentligt och är mer noga med våra begrepp och termer?

I resten av denna artikel använder jag för tydlighetens skull verksamhetsfunktion eller funktion när jag avser en avgränsad del av en verksamhet. Om du väljer att använda ordet verksamhetsförmåga men var då noga med vilken av betydelserna du avser.

Kunde begreppet förmåga beteckna en kvalitetsegenskap?

Vi upptäckte också att det bland aktörer inom affärsledning och affärsutveckling förekom en tredje betydelse av termen verksamhetsförmåga, nämligen vilka kvalitetsegenskaper man ansåg att verksamheten behövde ha. Det kunde till exempel röra sig om egenskaper som att vara flexibel, innovativ eller hållbar. Ibland skilde man ut detta som ”Strategic Capabilities”.

Det rörde sig alltså om en tredje, delvis annorlunda betydelse än de tidigare. Här handlade det inte om en avgränsad del av verksamheten, utan om egenskaper hos verksamheten som helhet. Snarare handlade det om kvaliteter som behöver genomsyra mer eller mindre alla delar av verksamheten.

Hur förhöll sig funktioner till organisationsenheter?

När vi talade om verksamhetsfunktioner, alltså hur arbetet i en verksamhet kunde ses som avgränsat i olika områden, var det lätt att tro att vi då menade den formella organisationen som framgick av organisationsschemat. Men det var inte riktigt samma sak. Med verksamhetsfunktioner avsåg vi snarare hur arbetet faktiskt fungerar i verkligheten, vilka avgränsade sammanhang vi såg i praktiken, oavsett om dessa fullt ut avspeglades i organisationsschemat eller inte.

Visserligen fanns det vanligen en viss samstämmighet mellan funktion och hur man formellt var organiserad, ty det vore annars besvärligt om ansvarsfördelningen helt skilde sig från hur arbetet faktiskt gick till. Men det var också vanligt att funktion och organisation inte fullt ut sammanföll. Det var något vi alla nog varit med om. Av historiska skäl, personliga kompetenser och intressen, personaltillgång eller andra tillfälligheter hade man behövt klumpa ihop ansvar som inte fullt ut speglade vad som egentligen hörde ihop, bortsett från dessa tillfälligheter.

Inom organisationsteori talade man om en ideal organisation. Det begreppet låg nära det vi här sökte: en beskrivning utifrån hur verksamheten faktiskt fungerade, snarare än enbart hur ansvar råkade vara formellt fördelat.

Kunde termen förmåga beteckna en kapacitet?

Inom olika krigsmakter, bland annat i svensk militärdoktrin, hade man strävat mot ett så kallat förmågebaserat försvar. Det innebar att man tydligt beskrev vilken kapacitet varje operativ enhet hade. Man kallade denna kapacitet för förmåga.

Om jag som infanterist behövde begära eldunderstöd av en artillerienhet ville jag veta vad just denna enhet kunde leverera. Det kunde handla ett visst slags eldverkan, med en viss volym, under en viss tid. Det intressanta var då inte hur detta åstadkoms, utan vad som fanns tillgänglig för mig.

Här fick termen förmåga ännu en betydelse: en slags kvalificering och kvantifiering. Detta är det fjärde exemplet på vad termen förmåga kunde stå för.

När amerikanska militären först började resonera i termer av förmågor var en förmåga man pekade ut att man behövde kunna utkämpa två krig samtidigt och vinna båda. Det var baserat på erfarenheterna från andra världskriget då USA deltagit i stridigheterna både i Stilla Havet och i Europa. Här var det tydligt att termen syftade på kapacitet. Det var också just från militära sammanhang som mycket av förmågeperspektivet emanerat, innan det letat sig vidare in i vår värld av verksamhets- och affärsutveckling.

För de flesta av dessa betydelser tyckte jag termen förmåga eller capability fungerade väl, då de avsåg olika aspekter av en förmåga, de vill säga vad något eller någon faktisk kunde eller behövde kunna. Undantaget var just den betydelse som vi verksamhetsarkitekter var intresserade av, som själva beteckningen för en avgränsad del av en verksamhet. Då blev det mindre lyckat. Då handlade det inte längre om en förmåga som verksamheten hade, utan snarare om en komponent i det maskineri eller ekosystemet som var själva verksamheten. Det var dessa komponenter som, ibland var för sig, fast oftast flera tillsammans, bidrog till en eller flera förmågor.

Hur användes förmågeperspektivet vid disruptiv affärsutveckling?

Som en parentes vill jag nämna ett något annorlunda sammanhang där förmågeperspektivet lyftes fram. Det var vanligt att man när man ville utveckla sin affär utgick från frågan: ”Vad behöver våra kunder?”.
Men ibland kunde det vara mer fruktbart att vända på perspektivet och i stället fråga: ”Vad är vi riktigt bra på?” eller ”Finns det fler som kan ha nytta av detta?”. Detta synsätt ledde ofta till att företag fann nya affärsområden och innovativa möjligheter.

Ett ofta använt exempel är när bokhandeln Amazon insåg att den interna kapacitet man byggt upp kring datalagring kunde erbjudas externt som en tjänst.
Det betyder att man i stället för att blint fokusera på befintliga kunder och affärer utgick från sina förmågor, det vill säga vad man är bra på. Det är mer eller mindre en förutsättning för framgång för ett företag – att slå mynt av sina särskilda styrkor. Detta sluter an till den första betydelsen av termen verksamhetsförmåga: vad vi är bra på att åstadkomma.

Kunde vi se begreppet funktion som lika med begreppet system i systemteorin?

Verksamhetsarkitekturområdet saknade en gemensam teoretisk grund. Det var mer en lös samling analys- och beskrivningsmetoder som vi plockat upp från olika håll. Det var inte nödvändigtvis fel. Men jag tyckte ändå att vi borde undersöka om vi kunde ge området en fastare teoretisk bas som bättre kunde knyta ihop de olika perspektiven.

Systemteorin var beprövad inom många områden och jag menade att den kunde bli den grunden för oss. Bara vi aktade oss för att bli alltför ivriga så att vi övertolkade de samband vi hittade.

För oss blev systemteorin särskilt relevant när vi ville hitta gemensamma mönster för hur organisationer faktiskt fungerade, hur vi kunde se vilka delar de var uppbyggda av och hur de interagerade.

Systemteori i korthet Systemteorin är en tvärvetenskaplig inriktning som studerar generella mönster hos system i både natur och samhälle. Det man väljer att se som ett system kan vara mycket olika saker: jordens ekosfär, ett organ i kroppen, en familj, en organisation eller en samhällssektor. Några centrala grundteser är: Ett system är alltid avgränsat och självstyrande Ett system består av delar som själva också kan ses som system System samverkar vertikalt och horisontellt med andra system Synsättet är alltså fraktalt: samma grundmönster återkommer när vi zoomar in eller ut. Jag går inte djupare in på systemteorin här, men har utvecklat detta mer utförligt i tidigare artiklar på irm.se under Artiklar.

Jag hade inspirerats av de speciella inriktningar av systemteori som handlade om organisationer, och detta inspirerade till att utveckla en typ av kartor som avbildade hur verksamheter egentligen var uppbyggda och fungerade. Det vill säga vilka komponenter (funktioner, it-applikationer, roller och tjänster) verksamheten bestod av och hur dessa samverkade med varandra och med externa parter.

Det som blev särskilt intressant var den generella systemteoretiska modell för organisationer som heter Viable System Model (VSM). Där betonades att varje avgränsad operativ enhet i en organisation i praktiken är ett eget självstyrande system.

Viable System Model (VSM) I VSM är styrning betydligt bredare än traditionell toppstyrning. Styrning omfattar allt från: daglig koordinering intern samverkan utveckling strategi identitet Varje operativ del av en organisation behöver därför förstås som en egen verksamhet med eget självstyre. Det innebär också att organisationer inte i praktiken enbart styrs uppifrån. Självstyre i varje del är en grundförutsättning för anpassningsförmåga och överlevnad. Jag går inte djupare in på VSM-teorin här, men har utvecklat detta mer utförligt i tidigare artikel på irm.se under Artiklar.

För mig blev detta ett sätt att förstå verksamheter, och därmed hur vi kunde kartlägga och utveckla dem.

Kunde vi se it-applikationer och deras integrationer som en spegling av verksamhetens funktioner och hur de samverkade?

En viktig iakttagelse om sambandet mellan organisation och it-arkitektur gjordes redan på sextiotalet av it-utvecklaren Melvin Conway. Den formulerades snart som en allmängiltig lag, Conways lag, och säger följande: En programvaras arkitektur avspeglar strukturen hos den organisation som byggt den. Detta kunde också tillämpas bredare på en verksamhets samlade it-miljö. It-landskapet tenderade att spegla verksamhetens operativa struktur, alltså vilka funktioner den bestod av och hur dessa samverkade med varandra och med omgivningen. Om det fanns en it-applikation så fanns det normalt också en verksamhetsfunktion som stödde denna. Per definition var ju en it-applikation en programvara för en viss verksamhetsfunktion.

Men här behövde vi vara noga med begreppen. Vi borde skilja på it-system och it-applikation. Ett it-system kunde bestå av flera olika it-applikationer. Samtidigt kunde en enkel Excelsnurra eller ett script på en integrationsplattform vara en it-applikation, så länge den innehåller någon form av verksamhetslogik.

Eller mer precist uttryckt: En it-applikation var alltid att se som en integrerad del av en verksamhetsfunktion. Verksamhetsfunktionen kunde vara tydligt definierad och formellt uttalad, eller mer dold och styvmoderligt behandlad, men den fanns där ändå. Någon, någonstans, gjorde jobbet. Kanske inte alltid så strukturerat, men det gjordes.

Vidare kunde varje integration mellan it-applikationer, oavsett teknik och meddelandemönster, ses som en tjänst där en verksamhetsfunktion var producent och en eller flera andra var konsumenter.

På så sätt kunde vi, utifrån en karta med it-system och integrationer, härleda en första version av en verksamhetskarta. Detta var inte bara ett snabbt sätt att få fram ett första utkast till en karta.
Det viktigaste var att it och verksamhet fick samma karta. Därmed kunde man redan från början få en gemensam dialog. It blev nu på allvar betraktat som en integrerad del av verksamheten.

Och för oss informationsarkitekter blev kartan viktig. Vi kunde nu kartlägga dataflöden, dataproduktion och konsumtion på ett mer sammanhållet sätt. Det som kallas technical linage, alltså hur it-system är integrerade och business linage, hur funktioner och externa parter samverkar kunde nu ses som två detaljeringsnivåer av i grunden samma struktur.

Vi saknade något

För att kunna utveckla något som bestod av olika delar som samverkade behövde man en ritning eller karta över detta något. Detta gällde inte bara maskiner, städer eller ett it-system. Det gällde också verksamheter.

Trots detta var det väldigt ovanligt med den typen av ritningar. Ty det var inte organisationsschemat vi var ute efter. Det visade bara en ansvarsstruktur, det som ibland kallas ”blame structure”, alltså vem ansvarar för vad. Det var inte heller informationsmodellen som visade verksamheten i sig själv vi var ute efter. Den visade vår domän, det vill säga vilka företeelser, inklusive deras egenskaper, vi hanterade liksom vilka data vi behövde för att spegla dessa företeelser och egenskaper. Inte heller processkartan räckte. Den visade hur vissa saker gick till, det som följde tydliga flöden.

Affärsmodeller svarade på något annat, de grundläggande existentiella frågorna: Varför vi finns, vad vi erbjuder, för vem och hur vi når dessa. En traditionell förmågekarta kom inte heller närmare egentligen. En tolkning var att en sådan skulle kunna visa vad vi vill kunna göra. Enligt en annan tolkning skulle den visa vilka avgränsade delar verksamheten bestod av. Tyvärr blev resultatet alltför ofta en sammanblandning av båda perspektiven.

Ett annat problem var att den traditionella förmågekartan plattade till världen, att den inte tog hänsyn till att en verksamhet alltid var fraktal. Att den bara såg den styrning som fanns i toppen av organisationen, när det i själva verket fanns styrning i varje del, i varje operativ funktion av en organisation.

Alla dessa modeller hade sitt värde, såvida de inte rörde ihop perspektiv som processer och funktioner, eller vad vi åstadkom med hur vi var uppbyggda.

Inom parentes sagt får man gärna blanda flera perspektiv i samma modell. Det kan ge förståelse för samband. Men då måste vi ovillkorligen hålla perspektiven tydligt åtskilda, både i våra huvuden och i vår grafik.

Men vi saknade ändå själva kartan över verksamheten. En karta som gav översikt och sammanhang för allt som skedde, i alla dess delar och mellan dessa. En karta som visade hur det ekosystem som en verksamhet faktiskt är hängde ihop och fungerade.

Vad vi behövde

Vi behövde kunna avbilda hur verksamhetens funktioner relaterade till varandra och till omgivningen. Vi ville kunna se vilka delar som var närmast kunderna, vilka som låg där bakom och utgjorde själva kärnan i verksamheten, samt vilka som var stödfunktioner.

Vi behövde också kunna avbilda vad våra funktioner bestod av, särskilt it-applikationer och roller.

Vi behövde kunna avbilda hur funktioner, tjänster, it-applikationer och roller samverkade, vilka beroendena var och hur data och information flödade.

Kort sagt: Vi behövde en riktig karta, med geografi och dimensioner, där vi kunde visa strukturer och sammanhang. Vi behövde skapa en sådan karta över verksamheten, en gemensam bild där verksamhet och it inte längre betraktades som två separata världar, utan där informationstekniken på riktigt började förstås som en integrerad del av verksamheten.

Ofta mötte vi något som kallades för förmågekarta, men som egentligen avbildade det jag rätteligen vill kalla för funktioner. Men de var inte heller den typen av modeller som vi efterfrågade. Ty de är inga kartor i egentlig mening, de har ingen geografi eller struktur utan är egentligen bara en listning av funktioner.

Vad vi gjort

Jag och mina kollegor har därför, genom åren arbetat fram det vi menar är ett mer användbart beskrivningssätt. En verksamhetskarta med funktioner och tjänster. Arbetet var från början inspirerat av förmågekartor men utvecklades snart i en egen riktning präglad av systemteori för organisationer, Conways lag tillämpad på organisationer, och med tiden också ett tjänsteorienterat synsätt. Vi har funnit arbetssättet värdefullt och använt det i våra kundorganisationer för att skapa både överblick och detaljförståelse i all typ av strategiskt och praktiskt utvecklingsarbete.

Kartan kan omfatta:

• en organisation med en eller kanske flera parallella verksamheter
• en del av en verksamhet
• flera organisationers samverkande verksamheter.

Det är idag svårt för oss att tänka oss hur vi skulle kunna göra ett bra jobb utan den gemensamma plattform och spelplan som verksamhetskartan ger.

Vidare läsning

Jag har skrivit ett antal artiklar om detta, där jag går igenom hur man kan tänka och arbeta för att på riktigt skapa en verksamhetskarta. Observera att de flesta artiklarna kallar kartan för en förmågekarta.

Men jag menar idag att det är tydligare och mer korrekt att ta steget till att lämna den luddiga termen förmåga och i stället säga ”verksamhetskarta”. Detta eftersom kartan dels är mycket mer än det som brukar kallas förmågekarta, dels att verksamhetsförmåga är ett vilseledande namn för det som kartan visar.

Några lästips:

• En serie på tio artiklar som bit för bit beskriver arbets- och beskrivningssättet.
  Första artikeln i serien hittar du här: Förmågekartor för informationsarkitekter del 1
• Hur kan en verksamhetskarta integrera verksamhets- och it-perspektiv i samma vy? Läs artikeln Vi behöver modeller som integrerar fler dimensioner
• Läs om Roger Sessions bok Simple Architectures for Complex Enterprises i artikeln Informationsarkitektens bokhylla del 10: En bok om att bygga verksamhetsarkitektur för komplexa verksamheter
• Varför är verksamhetskartan viktig vid kartläggning av verksamhetens dataflöden?
  Läs artikeln Så kartlägger du verksamhetens dataflöden
• En bok om systemteori för organisationer, Viable System Model:
  The Fractal Organization: Creating sustainable organizations with the Viable System Model av Patrick Hoverstadt

Hör av dig!

Som arkitekter tycker vi att det är viktigt att reda ut begrepp, skapa ett tydligt gemensamt språk och utveckla synsätt och arbetssätt som ger klarhet och riktning. Vi behöver styra bort från onödigt skapad komplexitet, utan att för den skull dölja den komplexitet som faktiskt finns där naturligt och nödvändigt.

Detta är något vi försöker göra ute i de verksamheter vi arbetar med. Men det är också något vi behöver göra i vår egen verksamhet som arkitekter.

Vi vill gärna dela med oss av det vi lärt oss, sprida våra erfarenheter och föra en dialog.

Kanske ser du på saken annorlunda?
Kanske har du gjort en liknande resa?

Ta gärna kontakt med oss. Vi visar och diskuterar gärna hur vi arbetat med verksamhetskartor i olika sammanhang. Vi behöver bli fler i landet som tillsammans utvecklar arbetssätt runt verksamhetsutveckling.