Sidegenskaper | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Hitta på sidan JIRA-ärenden Publicerad/ version | RedaktörerDeltagare
| |||||||||
Sidegenskaper | ||||||||||
| ||||||||||
|
Innehållsförteckning
Innehållsförteckning |
---|
...
|
...
2020-11-12/40
|
...
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.
...
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.
...
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.
...
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.
...