Det nya synsättet på verksamhet
FÖRSTA DELEN AV TRE
Verksamhetsarkitektur-området befinner sig mitt i ett paradigmskifte. Processer har fått konkurrens av förmågor som verksamhetens grundläggande byggblock.
Under de senaste åren har ett nytt synsätt växt fram bland verksamhetsarkitekter. Ett synsätt som sätter fokus på verksamhetens stabila byggblock och hur de kan samverka med varandra och med omvärlden. Därmed vill man skapa en mer flexibel verksamhet, som snabbare och effektivare kan reagera på förändringar i omvärlden
Verksamhetens meningsfulla delar
En Business Capability är en del av verksamheten som man kan se och hantera som en självständig och avgränsad komponent. Det är en komponent som består av processer, information, verksamhetsregler, it-funktionalitet och kompetenta, samtränade personer.
Tanken är att dela in en verksamhet i meningsfulla delar, där varje del till sin natur har en så stark inre koppling - det vill säga många, täta och ömsesidiga beroenden mellan sina interna delar - att den bör ses och hanteras som en helhet.
Och samtidigt är kopplingen till andra Business Capabilities lösare och kan tillåtas vara mer växlande med tiden. Dessa komponenter kan flexibelt och dynamiskt samverka sinsemellan och även med externa komponenter för att bilda snabbt växlande värdekedjor.
Vi tycker det är dags att göra en ordentlig presentation av det nya perspektivet. Vi vill tränga igenom de olika marknadsaktörernas namnsättning och metoder och se vad som är gemensamt. Det vi hittat är radikalt annorlunda jämfört med den konventionella synen på verksamhet inom verksamhetsarkitektområdet och har en potential att förändra arkitekturarbetet i grunden.
Det som här presenteras är vårt försök till en syntes av synsätten i branschaktörernas respektive metoder, att beskriva den kärna i synsättet som förenar tvärs över branschen. Vi har delat upp presentationen i tre delar.
- Del 1: Vad är Business Capabilities? (denna del)
- Del 2: Business Capabilities: Verksamhetens stabila komponenter
- Del 3: Business Capabilities: En gemensam grund för verksamhet och IT
Många namn på samma sak
Det handlar om något som går under olika namn. Oftast kallas det Business Capabilities, verksamhetsförmågor.
Gartner, Forrester och Microsoft använder just det namnet medan IBM i stället talar om Business Components, verksamhetskomponenter. Arkitekturramverket Modaf benämner samma företeelse Capability Configuration, det vill säga en konfiguration av förmågor.
Vi har även stött på den nygamla benämningen Business Functions, verksamhetsfunktioner. Det finns alltså skillnader i vad man kallar sakerna och olikheter i angreppssätt hos de olika aktörerna på området.
Men om man inte låter sig bortkollras av de ytliga skillnaderna framträder en tydlig gemensam bild. Det vi då får syn på är inget mindre än ett nytt sätt att förstå och hantera verksamheter.
Business Capability är egentligen ett dåligt namn
De flesta skriver att en Business Capability är "en förmåga som verksamheten har eller önskar sig", alltså vad verksamheten gör eller behöver göra. Vanligen kontrasterar man det mot en verksamhetsprocess som beskriver hur verksamheten gör något.
Men när man studerar de olika ansatserna närmare ser man att den skrivningen inte stämmer med det man verkligen menar. Det finns en subtil men viktig distinktion att göra som många inte har lyckats med. Det framkommer ändå tydligt från beskrivningar och exempel vad man i själva verket menar. Det man i själva verket avser med en Business Capability är en sammanhållen, avgränsad och självständig komponent av verksamheten. Det är en komponent som utgörs av resurser som processer, information, kompetenser, it-stöd med mera.
Vad är det då som skiljer en sådan komponent från vad som är en förmåga i ordets rätta mening? Jo, en komponent av verksamheten kan i själva verket tillhandahålla fler än en förmåga. Eller tillsammans med andra komponenter bidra till en gemensam förmåga. Det finns en viktig koppling mellan förmåga och komponent men kopplingen är inte en-till-en och det är inte alls så att en komponent är lika med en förmåga.
Därmed är "Business Capability" egentligen ett dåligt valt namn och "Business Component" ett bättre. Men namnet "Business Capability" har fastnat, därför är det svårt att undvika det. Fast lite olyckligt är det eftersom det bland affärsstrateger också finns något som kallas "Business Capabilities" och som verkligen står för förmågorna i sig. Den troliga förklaringen är väl att EA-samhället har lånat namnet därifrån för att underlätta insäljning till affärsfolk. För sent har man upptäckt att det faktiskt finns ett många-till-många-förhållande mellan förmågor och de grupperingar av resurser som står för förmågorna.
Komponenter i komponenter
En Business Capability kan ingå som en del i en större Business Capability och kan själv också bestå av komponenter i form av mindre och mer avgränsade Business Capabilities.
När en Business Capability är innesluten i en annan betyder det att den inte har mening utanför det sammanhanget, att den tillhandahåller tjänster som endast används internt. På så sätt kan en verksamhet delas ner hierarkiskt i allt mindre komponenter.
Vissa ansatser (som till exempel Microsofts) utnyttjar den möjligheten maximalt och förordar en hierarkisk nedbrytning i många nivåer. Andra (som IBM) föredrar att stanna på en mycket övergripande nivå.
Det viktiga är att en Business Capability alltid är en helhet av processer, it-stöd, information, verksamhetsregler, tjänster, kompetenser med mera. Det är ett sätt att hantera som en helhet det som behöver hanteras som en helhet. Det är inte minst ett sätt att samtidigt kunna hantera olika helheter på olika nivåer.
Business Capabilities samverkar genom verksamhetstjänster
Business Capabilities samverkar i kedjor för att producera värde. Samverkan mellan Business Capabilities går till på följande sätt. En komponent av verksamheten i form av en Business Capability tillhandahåller en eller flera tydligt definierade tjänster till sin omvärld, det vill säga till andra komponenter. En Business Capability kan konsumera en eller flera andra tjänster som andra Business Capabilities tillhandahåller.
En verksamhetstjänst är ett erbjudande om att producera ett specifikt resultat av värde för en verksamhet. Det finns alltid någon part som tillhandahåller, producerar tjänsten och det finns en eller flera parter som drar nytta av, det vill säga konsumerar tjänsten. Vi talar här om verksamhetstjänster, Business Services, som inte är direkt översättbara till de elektroniska tjänster vi har inom it-arkitekturområdet.
Samverkan mellan en verksamhets olika delar och med omvärlden - som ses som ett antal Business Capabilities - sker alltid via tjänster, i form av tillhandahållandet och nyttjandet av tjänster. Därmed ger ett Business Capability-perspektiv på en verksamhet en bas för tjänstebaserad verksamhetsarkitektur.
Verksamhetsprocesser gör jobbet
En Business Capability har på insidan alltid en eller flera processer som representerar det som utförs i denna. Sedan använder sig en process alltid av en eller flera tjänster exponerade av Business Capabilities. På så sätt är processer både överordnade och underordnade Business Capabilities. Det beror på hur man zoomar in bilden. Verksamhetsprocesser är inte alls överspelade med det här nya synsättet men har fått en tydligare kontext.
I bilden nedan har vi tecknat hur man kan se en lånehanteringsfunktion på en bank som en komponent, en "Business Capability". Den tillhandahåller flera verksamhetstjänster till sin omgivning, två av dessa är att ta hand om en inkommen låneansökan och att förnya ett befintligt lån.
Internt har den två olika funktioner, en för att bedöma kredit och en annan för att administrera lån. Var och en av dessa har sina egna processer, sin egen specifika kompetens och sitt specifika behov av it-stöd med mera, och bör ses och hanteras som en sammanhållen helhet.
I nästa två EA-spaningar ska vi se närmare på varför många ser Business Capability-perspektivet som så viktigt.
Som vanligt är läsarkommentarer mycket välkomna. Vad tycker du att det nya perspektivet tillför? Är det verkligen ett nytt perspektiv? Var det inte just dessa stuprör vi försökte komma ifrån med verksamhetsprocesser?