Modelltyp - Förmågekarta
- Arkitekturgemenskapen
Beskrivning | Arkitekturperspektiv | Verksamhetsområde | Publicerad/ version |
|---|---|---|---|
Denna sida beskriver modelltypen förmågekarta. | Strategi |
| 2020-11-12/40 |
Innehållsförteckning
Summering
En förmågekarta presenterar en organisations förmågor, grupperade i olika områden och förmågetyper. Dessa områden skiljer sig åt för olika organisationer, men två huvudtyper är verksamhetsförmågor och stödjande förmågor. Verksamhetsförmågor är sådana som är specifika för en viss del av verksamheten. Dessa har ofta kopplingar till värdeskapande tjänster som är synliga för externa intressenter, exempelvis förmågan till social omsorg. Stödjande förmågor är sådana som stödjer flera verksamhetsförmågor, dvs värdet de skapar är främst för andra förmågor snarare än kunder/patienter eller andra intressenter. Exempel är lokalvård, tvättservice, men också tekniska förmågor såsom distansmöte, patientövervakning etc.
Verksamhetsförmågor och stödjande förmågor kan i sin tur betraktas ur en strategisk betydelse, det vill säga hur strategisk förmågan är för organisationen. Att identifiera strategiska förmågor kan fungera som ett verktyg för prioritering av resurser för verksamhetsutveckling. Strategiska förmågor kan ses som centrala förmågor som behövs för att uppnå organisationens målsättningar.
Förmågeområdeskartan finns utförligare beskriven här och har som funktion att namnge områden inom ledning och styrning, kärnverksamhet och verksamhetsstöd för regioners och kommuners uppdrag. Det översta (ledning och styrning) och nedersta (verksamhetsstöd) är gemensamt för hela organisationen. I mitten visas kärnverksamheter som i detta fall kallas verksamhetsområden. Relationen mellan förmågeområdeskartan och en förmågekarta för exempelvis ett verksamhetsområde ligger i att man normalt definierar en förmågekarta per verksamhetsområde (nivå 1 i bilden nedan) och i de fall då det behövs, bryts förmågorna ner i underförmågor (nivå 2). Om behov finns för ytterligare nedbrytning så rekommenderas primärt textuella beskrivningar.
Om man avser att bryta ned en organisations verksamhetsstöd eller styrning och ledning i förmågekartor så använder man avsedd typ på nivå 1 respektive nivå 2 enligt bilden ovan.
En förmågekarta skall ha en visuell- och en textuell beskrivning för att vara komplett och tjäna sitt syfte vilket exemplifieras under rubriken “Exempel” nedan.
Som stöd för ert arbete med förmågekartor så finns mallar för PowerPoint, Word och SPARX EA lite längre ner på sidan.
Exempel
Övergripande förmågekarta (mall):
Förmågekarta inom området Verksamhetsstöd:
Textuell beskrivning:
________________________________________
3.1 Informationshantering
Förmågan att förvalta organisationens information och data som en strategisk resurs och att tillgängliggöra fullständig, pålitlig och relevant information enligt gällande lagkrav, principer och standarder. (eng. Enterprise Information Management)
3.1.1 Informationsstyrning och efterlevnad
Förmågan att styra och följa upp organisationens övergripande informationshantering i enlighet med regelverk, lagkrav, gällande principer och standarder.
3.1.2 Informations- och datamodellering
Förmågan att utforma, modellera och visualisera krav för organisationens information, för att möjliggöra leverans av informationsobjekt. Informationsarkitekturen beskriver regler för informationens struktur, språk och inbördes relationer, och är en förutsättning för semantisk interoperabilitet.
3.1.3 Metadatahantering
Förmågan att beskriva innehåll, sammanhang och struktur i organisationens data och deras hantering över tid. Metadata definierar hur data struktureras, samlas in, delas, integreras, analyseras, underhålls, spåras och lagras samt etablerar relationer mellan information, processer och system.
__________________________________________
För fler exempel, se arbetsmaterial förmågekartor: Förmågeområdeskarta
Relevanta intressen
Här beskrivs de intressen som modelltypen kan hjälpa till att adressera. Intressen är viktiga eftersom de hjälper arkitekten att identifiera om modelltypen kan vara lämplig för den aktuella arkitekturen.
Intressent | Intresse |
|---|---|
Strateger (IT och verksamhet) |
|
Ledning och direktörer, exempelvis kommundirektör, landstingsdirektör, generaldirektör, verkställande direktör, CIO. |
|
Verksamhetschef |
|
Koncernarkitekt / Chefsarkitekt |
|
Verksamhetsutvecklare/ Verksamhetsarkitekt |
|
Projektportföljsansvarig |
|
Objekt/tjänst/produkt -ägare |
|
Ingående element och relationer
En förmågekarta innehåller normalt sett följande element:
Element | Syfte | Attribut |
|---|---|---|
Förmåga | Används för att visualisera de förmågor som kartan omfattar. | I förmågekartan ingår förmågans Namn och Beskrivning. Förmågor kan även ha attributet Typ, med följande möjliga värden:
Det är också möjligt att indikera tillstånd eller mognad hos förmågan. Dessa attribut finns för närvarande inte specificerade i Arktitekturgemenskapens metamodell, men kan läggas till av respektive organisation. |
Gruppering
| Används vid behov för att visa samhörighet för vissa förmågor. | Gruppens namn, dvs förmågeområdet. |
Relationer:
Från element | Relation | Till element | Syfte |
|---|---|---|---|
Förmåga | del av | Förmåga | Används för att bryta ner förmågor i delförmågor och på så sätt skapa en karta. |
Förmåga | ingår i | Gruppering | Används för att gruppera förmågor. En förmåga kan vara del av flera grupper. Notera att gruppering inte är samma sak som nedbrytning. |
Gruppering | grupperar | Förmåga | Som ovan. |
Form och notation
Vid modellering av förmågor rekommenderas både en grafisk och textuell beskrivning. Förmågekartan är en strategisk vy och bör därmed hållas på en relativt hög abstraktionsnivå. För många nivåindelningar kan vara svåra att följa och tenderar att bli alltför detaljerade. En utgångspunkt kan vara att inte göra mer än två nivåer av förmågor. Den textuella beskrivningen ska utgöra den mer uttömmande förklaringen av förmågan och mer detaljerade beskrivningar av en förmåga och dess realisering görs genom andra elementtyper, som till exempel processer och informationsobjekt. Se även beskrivningen av elementet Förmåga i Metamodell Strategi . I avsaknad av en komplett modell kan detaljer kring realiseringen beskrivas i den textuella beskrivningen.
Mallar
Mall för förmågekartor (Powerpoint) finns här:
Mall för förmågebeskrivning (Word) :
Mall för SPARX Enterprise Architect:
Metoder och modelleringstekniker
När förmågekartor utvecklas finns tre huvudaspekter som bör beaktas för att säkerställa att förmågorna hamnar på rätt nivå. Erfarenheter visar att det är lätt hänt att förmågemodeller blir för detaljerade och överlappar med de saker i arkitekturen som möjliggör förmågorna, exempelvis processer.
Det rekommenderas därför att utföra följande tre steg och iterera dom tills en bra balans uppnås:
Ge förmågan ett namn
Namnet utformas genom att tänka ”förmåga till...”. Se även nedanstående principer för utformning av verksamhetsförmågor.
Skapa textuell beskrivning
Beskriv förmågan i en eller ett par meningars löptext som förklarar vad förmågan omfattar eller inte omfattar. Undvik dock att beskriva dess realisering, dvs hur förmågan skapas. Detta beaktas i nästa steg.
När förmågan definieras är det viktigt att tänka på långsiktigheten. Beskrivning och namn bör därför inte innehålla organisationsenheter eller andra saker som kan ändras ofta. Tanken med förmågekartan är att den ska vara oberoende av hur man för närvarande delat in sin organisation.
Se även principer för utformning av verksamhetsförmågor nedan för ytterligare vägledning.
Analysera relation till andra element
Beskriv sedan kopplingen till andra element, exempelvis processer, verksamhetstjänster och applikationer. Syftet med detta är att beskriva hur förmågorna realiseras och hitta överlapp mellan realiseringselement och förmågorna. Ett klassikt exempel är var gränsen går mellan förmågor och processer. Arkitekturen bör inte definiera samma sak både som en process och en förmåga eftersom det skapar otydlighet, så genom att fundera på vilka processer som bidrar till en förmåga kan man avgöra om det faktisk är en förmåga eller i själva verket en process man definierat.
Om det redan finns en modellbaserad arkitektur arbetar man med fördel i denna för att skapa dessa relationer. I annat fall beskrivs elementen och relationerna i text vilken i ett senare steg kan överföras till modellform om så önskas.
Mer detaljer om relationer mallen förmågor och andra element finns i kapitlet Förmågeimplementationen i Metod för förmågebaserad planering.
Tänk också på att det är möjligt att skapa förmågekartor för olika områden. Dessa kan därmed innehålla förmågor på olika nivåer. Exempelvis kan en förmågekarta omfatta en hel verksamhet, flera verksamheter (samverkansarkitektur), eller delar av en verksamhet.
Eftersom relationen till andra element är centralt och förmågekartor kan bli komplexa rekommenderas det att skapa en modell med förmågor och andra element för att kunna hantera många relationer och enkelt skapa olika utsnitt ur modellen.
Principer för utformning av verksamhetsförmågor
Förmågor beskriver vad en verksamhet gör. Det en verksamhet kan, eller behöver kunna, göra – kan beskrivas som en förmåga, även om förmågan i dagsläget har en stor utvecklingspotential eller är obefintlig. För att skapa en förståelse och acceptans för förmågorna är det viktigt att fokusera på verksamhetsfrågor, inte systemfrågor.
Förmågor beskrivs med verksamhetsord. En verksamhetsförmåga namnsätts med ett specifikt, kort, och koncist namn. Personer i verksamheten, hela vägen från utförare till höga chefer, ska kunna se en verksamhetsförmåga och förstå vad dess innebörd.
Förmågor namnges och definieras av personer och organisationer som utför förmågorna. Om denna princip ignoreras medför det ofta en långdragen, ofta teoretisk, diskussion kring namnsättning på verksamhetsförmågor. Detta resulterar ofta i en förmågekarta som verksamheten inte förstår eller använder och därför känner de inte heller ett ägarskap över den.
Namnsätt en förmåga med ett substantiv. Använd substantiv som anger namn för förmågan, vad som görs med verksamhetsobjekt (ex vis "fastighetsadministration". Använd inte rena substantiv som anger en ”sak” (ex vis "fastighet"). Använd inte verb-substantiv (kan förväxlas med aktivitet eller process, ex vis ”administrera fastighet”). En kontrollfråga för namnsättningen kan göras genom att tänka ”förmåga till...”.
Förmågeindelningen är stabil över tiden. Eftersom att förmågor baseras på vad verksamheten gör, och inte hur, är en av huvudprinciperna med förmågor att de ska vara stabila över tiden. De grundläggande förmågorna för en verksamhet ska sällan förändras om vi inte står inför en större förändring av vår verksamhet (exempelvis öppna ett helt nytt verksamhetsområde).
Förmågor ska möjliggöra planering. Framförallt på strategisk nivå. Eftersom förmågeindelningen är stabil över tid så behöver förmågorna beskrivas på en sådan nivå för att kunna relateras till mål och indikatorer i förmågeutvecklingen.
En automatiserad förmåga är fortfarande en verksamhetsförmåga – inte en IT-förmåga. Ett allt för vanligt misstag är att se automatiserade verksamhetsförmågor som en IT-förmåga. En automatiserad verksamhetsförmåga är precis lika viktig att synliggöra som en helt manuell verksamhetsförmåga. Fokus ska vara på vad verksamheten gör.
En förmåga har en tydlig slutprodukt. En förmågas slutprodukt är något som tydligt visar nyttan med förmågan. En högnivåförmåga skapar en slutprodukt som är mer generell och övergripande, jämfört med en mer detaljerad och specifik förmåga.
En förmåga är inte en process. En förmåga behöver kunna stå för sig själv, utan att vara del av en värdekedja. Trots detta går det givetvis bra att skapa flöden för att beskriva hur förmågor samverkar med varandra.
Minimera redundans. Försök att sträva efter att hålla ihop förmågorna i syfte att minimera redundans där två förmågor beskriver samma sak. Genom att hålla nere redundansen minskar komplexiteten i den övergripande arkitekturen.
Generalisera inte för tidigt. Även om det är av stort värde att minimera redundans, var försiktig med att generalisera för tidigt då det kan leda till att komplexitet göms i begreppsförvirring. Skapa hellre två förmågor initialt och vid mer kunskap om förmågorna besluta om de bör hållas isär eller konsolideras.
Om ledningen planerar att göra något, identifiera det som en förmåga. En önskan att ha en ny förmåga som idag inte finns är ett bra tillfälle att synliggöra en jämförelse mellan nuläge och nyläge. Förmågekartan är ett kraftfullt redskap för att visa på nya förmågor som behöver utvecklas, dessa kan med fördel synliggöras genom olika färgkoder.
Användning av förmågekartan
Förmågekartor skapas och används ofta som del i Metod för förmågebaserad planering där den kan representera både nuläge och nylägen.
I nulägesperspektivet används förmågekartan ofta för s.k. heatmapping där förmågors mognad analyseras och visualiseras på förmågekartan.
För att visa förflyttning från nuläge till nyläge rekommenderas att använda Modelltyp - Förmågeutvecklingsplan som ger en överblick över förmågor och hur dom planeras utvecklas över tiden.