Vad är Business Capabilities?

Jag tycker det är viktigt att uppehålla sig lite mer kring "de riktiga förmågorna" kontra verksamhetskomponenterna som ni talar om. Om arkitekturarbete med verksamhetsförmågor ska ge verkligt mervärde är det viktigt att inte bara se förmågor som komponenter. Absolut går det att använda förmågor för att gruppera tjänster, processer och andra resurser men det verkliga mervärdet ligger i att grupperingen ska ske utifrån VAD som ska ske och VARFÖR (syfte/affärsvärde). Förmågorna ska beskriva vad som ska/måste utföras för att uppnå ett syfte (varför) och det är styrningen mot vad och varför som ger värdet, medans resursgrupperingen är sättet att styra hur och med vilka resurser det ska ske. På en detaljerad nivå är förmågor komponenter men värdet kommer av grupperingens syfte och styrningen mot detta syfte. Görs en indelning av en verksamhets förmågor utifrån vad och varför och styrs utifrån detta får man en mer renodlad och flexibel verksamhet. Den mer komponentorienterade vyn av (realiseringen av) förmågor borde nog kallas komponenter eller funktioner.

Det vi skriver om är verksamhetens komponenter i form av naturliga och mer eller mindre autonoma resursgrupperingar. Det är som vi, och också du nu, har påpekat bara en av betydelserna av termen ”Business Capability” och också som vi har påpekat egentligen ett missvisande namn.

Vi tvekade länge innnan vi valde att använda namnet ”Business Capabilities”. Som du påpekar är namnen ”Business Components” eller ”Business Functions” egentligen mer rättvisande benämningar. Det som gjorde att vi valde att använda namnet ”Business Capabilities” var att det är det mest använda namnet på företeelsen inom EA-världen.

Vi hittade faktiskt ingen inom EA-communityn som verkligen hade intresserat sig för verksamhetens förmågor och benämnt detta ”Business Capabilities”. (Inom Business Strategy-communityn står däremot ”Business Capability” verkligen för en förmåga och inte för en resurskomponent).

Men det var ett val som stod och vägde, och nu när du i samma andetag vill diskutera (de verkliga) förmågorna framstår valet som mindre lyckat.

Vi vill inte på något sätt motsäga dig när du säger att det är viktigt att ta reda på och beskriva vilka (verkliga) förmågor verksamheten har och behöver, men vi kan väl vara överens om att det inte står i motsats till att beskriva och hantera verkamheten i form av autonoma komponenter/funktioner.

Vi vill lyfta fram komponentperspektivet därför att vi tror det är viktigt ur många aspekter. Det är sant att det handlar om realisering, men tro inte att det därför är en ointressant och utbytbar teknikalitet.

Verksamhetens realisering ÄR verksamheten i allt väsentligt och på riktigt. Det är där verksamheten lever sitt liv, det är där verksamheten slapar nytta. Det är också där vi kan observera hur verksamheten fungerar och därmed utveckla verksamheten baserat på fakta.

Svar på #2. Jag håller helt med om att komponent- och realiseringsperspektivet är mycket viktigt. Det jag försöker lyfta fram är att "den andra sortens" förmågor är en viktig förutsättning för att kunna effektivisera verksamheter genom att beskriva dess förmågor. Det jag vill poängtera är att den verkliga nyttan med verksamhetsförmågor uppstår när de är definierade av nyttan de ger. Om uppdelningen av verksamheten (och därmed realiseringen och styrningen) är baserad på den affärsnytta de olika delarna ska ge finns en mycket bra grund för att optimera realiseringen. Realiseringen beskrivs med fördel i komponenter.

När du nu ändå tar upp MODAF kanske det är på sin plats att nämna att "Capability" och "Capability Configuration" är två olika begrepp enligt dess metamodell. Capability Configurations kan sägas realisera Capabilities. MODAF är ju modellbaserat (good or bad) och det är en N:N-relation begreppen emellan. Tolkar jag metamodellen rätt är Capability Configurations också fysiska resurser (IT-relaterade eller andra). "Capability Maps" däremot är en relation mellan capability och process (operational activity).

Rättfärdigar både Peter's och Erik's perspektiv. Om det nu var någon skillnad dem emellan :-)

Svar till Anders: Det är intressant att du nämner Modaf. I vintras var jag med i en arbetsgrupp som gick igenom allt vi kunde hitta som fanns skrivet om Business Capability-perspektivet, både inom affärsstrategi och inom verksamhetsarkitektur. Vi kom då fram till att man använde termen ”Business Capability” i två helt olika betydelser i dessa communities, vilket vi också har beskrivit i spaningen ovan.

Dessutom fanns det ingen inom respektive community som tycktes känna igen användningen av termen inom den andra communityn. Det framstod som två världar med vattentäta skott emellan.

Men Modaf var faktiskt ett undantag. Modaf hade begrepp både för förmågor i sig och för det som man kan se som autonoma komponenter. Modaf är intressant i detta sammanhang också av en annan orsak. Hela angreppsättet med Business Capabilities kommer ju från militära sammanhang från början, och Modaf är ju ett ramverk som har en bakgrund i hur Brittiska försvarsminiseriets satsning på nätverksbaserat försvar.

Därmed kan man kanske anta att Modaf ger en bild av Business Capability-perspektivet som ligger närmare ursprunget. Jag får lust att titta lite närmare på Modaf…

Hej.

Jag vill skilja på förmåga och realisering av förmåga. Har ni utvecklat någon form av notationsspråk som kan stödja detta perspektiv?

Det jag skriver är ingen nyhet utan en fullt ut fungerande praxis inom produktutveckling. Behov, värde/nytta, nyckelegenskaper/capabilties, övergripande design, implementation, test, etc. Jag vill se på verksamheten som en produkt men har inte funnit en terminologi som svarar upp mot detta. Det bästa jag funnit so far är BPMN 2.0, även om denna fokunserar mer på att beskriva just realiseringen.

Organosationer kommer och går, de kapabiliteter som man behöver består. Hör gärna av er om ni: inte förstår vad jag skriver; har något bra förslag och har en ide om hur jag och vi bäst skall tillänga oss detta.

mvh,

Hans Christensen

Svar till Hans: Vi i den arbetsgrupp som studerade Business Capabilities tog inte fram någon metodik. Det vi gjorde var att ta fram en gemensam beskrivning av det som finns där ute, närmare bestämt de företeelser/begrepp som är mer eller mindre gemensamma för de ansatser som handlar om Business Capabilities inom verksamhetsarkitekturområdet och affärsstrategiområdet.

Det vi fann var att de olika ansatserna och det som skrivs i allmänhet inte identifierar eller skiljer på förmågor i sig och de verksamhetskomponenter som levererar förmågan. Det enda undantaget vi fann var Modaf som faktiskt har begrepp för båda perspektiven.

Jag ser så här på kopplingan mellan dessa saker. Det är ett många-till-många-förhållande mellan förmågor och komponenter. En komponent levererar alltid minst en förmåga, men har ofta flera förmågor. En förmåga kan realiseras av en viss komponent men det finns förmågor som inte kan lokaliseras till en specifik komponent utan till några eller ibland alla komponenter. Man kan beskriva förmågor på olika sätt och komponenter på olika sätt.

Kanske kan man säga att då det gäller operativa förmågor, det vill säga den löpande verksamheten, så kan man i högre grad hänföra en viss förmåga till en komponent. ”Det är denna del av verksamheten som används för fakturering av kunder(dvs kompetens, personal, it-stöd, information, processer mm”.

Men om man talar om de förmågor som man brukar fokusera på i affärsstrategisammanhang , till exempel förmågan att utveckla verksamheten eller att vara flexibel och reagera snabbt och effektivt på möjligheter och hot så tycker jag det är fel att säga att de kan lokaliseras till en speciell avgränsad del av verksamheten. De berör alla eller nästan alla delar i någon grad.

Och visst kan man mappa förmågor mot var och hur (i vilka komponernter) de realiseras.

1. Reflekterar inte ordet Capability enterpriseperspektivet ? (med tanke på Microsoft MSBA model http://msdn.microsoft.com/en-us/architecture/aa479368.aspx, med top capabilities är Develops products and services,Generates demand for those products or services etc...) Ordet Funktion mer speglar org.chart perspektivet... Sedan finns det tredje perspektivet - IT capabilities, med det menar jag till ex. Doc managment, BI, Collaboration... Det finns säkert fler perspektiv. De alla behövs för att gruppera den realisering som finns/planeras (system, komponenter, services) för att visualisera arkitektur från den rätta perspektivet. Men finns det verktyg för detta? Excel som Microsoft föreslår är inte underhållsbar lösning - för mycket manuellt arbete, för lång bort från verkligheten... Det behöves en verktyg som uppnår integration med de realiserade 'komponenter' (typ med CMDB, SOA registry ...)

2.Andra frågan - IRM verksamhetsarkitektsutbildning mappar processer dirket till system. Det är alldeles för förenklad och även riskabelt sätt att se på IT som är mer komplex än så. Kommer ni utveckla vidare den? Det skulle vara nytting att koppla verksamhetsarkitektursperspektivet med resten av arkitektur, lösningsarkitektur, service-orientering, enterprisearkitektur.

Svar till Marina: Om skillnaden på Business Function och Business Capability: Som vanligt kan termer ha flera olika innebörder. ”Business Function” (verksamhetsfunktion) kan betyda olika saker. Ofta har man - som du skriver - menat organisatorisk enhet. Men en annan betydelse som inte är ovanlig är ungefär ”en uppsättning logiskt relaterade aktiviteter eller uppgifter som utförs tillsammans”. Och den betydelsen ligger mycket nära den vanligaste betydelsen av ”Business Capability” inom EA-världen. Det finns flera EA-ansatser som använder termen ”Business Function” i den betydelsen. Då har vi sett det som en synonym till det som i andra ansatser kallas ”Business Capability”.

Intressant att ni försöker granska detta begrepp. TOGAF 9 säger sig ju vara ett "Business Capability driven framework" men definierar aldrig termen. Klart att det behövs ett funktionellt perspektiv på affärsverksamhet, svårigheten uppstår när flera blandas. Funktioner, tjänster, capabiliteter, funktionella domäner. Till syvende och sist blir det en ramverksfråga att belsluta vilka byggblock man jobbar med och att definiera dessa. Om vi tittar på låneverksamheten i exemplet så är det ju en typisk "funktionell domän" som "alla är överens om" och som "kan organsierar på olika sätt och med olika IT-support". Sådana arbetar vi ju i praktiken alltid med. Det är ju ofta för sådana avsnitt som vi i praktiken tar fram målarkitekturer. Mera diskussion om detta område!

Svar till Marina på fråga nummer 2: Jag har vidarebefordrat din fråga till Håkan Edvinsson, IRM som är rektor för Dataföreningens/IRMs kurs "Certifierad verksamhetsarkitekt".

Han svarar så här: "Det stämmer inte att vi gör en direktkoppling mellan processer och system. Det förekommer i andras metoder, men alltså inte i vår. Alltsedan starten 1991 har vi gjort kopplingen mellan verksamhet och system via information. Genom att koppla processerna till informationsobjekt och även systemen till informationsobjekt får man en mycket användbar bild av hur situationen ser ut och vad som behöver göras.

Definitivt mycket mer användbar än att direktkoppla processer till system vilket, som du själv framhåller, är alldeles för förenklat.

Informationsmodellen är sedan starkt påverkande i utformningen av målarkitekturen, även vid serviceorienterad arkitekturansats. När det gäller utformning ur mer tekniskt perspektiv tar man naturligtvis hänsyn till många fler aspekter men ska inte utelämna informationsperspektivet.

Svar till Lars Littorin. Ja, som du skriver har vi egentligen alltid haft ett funktionellt perspektiv, på det ena eller andra sättet, speciellt på övergripande nivå. Så det är inget nytt under solen.

Men vi har vanligen inte jobbat med funktionell nedbrytning inom EA-området, dvs funktioner i funktioner. I och med det stora genomslaget för processmodellering på 90-talet blev processer allt vi såg, och att identifiera eller se funktioner eller liknande sågs som felaktigt. Man ville komma ifrån stuprören (suboptimerade funktioner utan helhetsperspektiv) och hamnade i stället i motsatta diket. Vi fick hängrännor, dvs enbart processer.

Nu kanske vi är mogna för att se BÅDE funktioner och processer. Processer för att optimera värdekedjor och funktioner (a.k.a ”Business Capabilities”, ”Business Capability Configurations”, ”Business Components” etc) som meninsfulla byggblock.

Svar till Håkan Edvinsson: Fick jag svar på min fråga? Delvis. Bra att du nämner tjänsteorientering. Min fråga gällde Verksmhetsarkitektcertifiering: hur kommer ni vidareutveckla den ? Tänker ni annamma BC approach eller liknande? Håller med, informationaspekten är en av de grundläggande viewpoints (zachman). Tillsammans med processer, resurser, roller, mål (andra likvädriga viewpoints). Men för att modellera "tjänsteorienterad" behöver alla aspekter 'inkapsuleras' i en enhet vilket en tjänst är. Då Business capability/komponent passar in i bilden. Att verksamhetsarkitekter tänker och modellerar business capabilities innan den går in på process- och informationsdetaljer underlättar kommunikation mellan verksamhets- och lösningsarkitekter. Speciellt när tjänsteorientering ska annamas på företagen.

@Marina P: Tack för kommentaren. Svar ja, tjänsteorienteringen vävdes in för några år sedan. Det finns sedan förra året en formation med representanter bl a från akademiska världen, industrin och IRM som tydliggör Business Components och Business Capabilities - det är ännu mycket otydliga företeelser. De har presenterat ett delresultat vid DAMA:s EA-konferens i Stockholm och ska jobba vidare. Från kursledningen följer vi med spänning på resultatet för att väva in det i utbildningen.

Mycket intressant diskussion det här. Ligger väldigt nära idealet för hur jag vill jobba med verksamhets- och IT-utveckling i samklang.

@Peter: Dina kommentarer om att ha många till många mellan capabilities och komponenter håller jag delvis med om. Eller kan det vara så att komponenter kan använda sig av komponenter och att det finns relationer mellan olika capabilities? Att hela tiden ställa frågan varför en capability behövs tror jag leder till att det finns sub-capabilities. Och jag tror verkligen att allt arkitektur-/utvecklingsarbete ska börja med frågan varför. Jag vill helt enkelt undvika att relationen mellan komponenter och capabilities blir otydlig och i värsta fall meningslös. Kan det här synsättet hjälpa till att förenkla - verkar det vettigt?

Hej! Jag undrar lite mer specifikt kring det ni nämner här:

"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."

Hur tänker ni här? Vad är det som gör att en kapabilitet endast har ett syfte i en kontext? Kan inte samma kapabilitet återanvändas av andra Business Services/kapabiliteter/komponenter?..

Tack Andreas för att du ställer frågan, för jag tror att det är fler som undrar. Din undran berör en kärnpunkt tror jag, det som är något av nyckeln till komponentperspektivet. Jag tar hjälp av exemplet som vi har avbildat i artikeln.

I bildens nedre vänsta hörn finns en verksamhetsförmåga (eller om man vill kalla det verksamhetskomponent eller verksamhetsfunktion) vars uppgift är att göra kreditbedömning av personer och företag som ansöker om kredit (Credit Scoring). Det vill säga att den komponenten tillhandahåller en verksamhetstjänst man får en fråga om en person eller företag och beräknar utifrån de kreditmodeller de har sannolikheten för att personen eller företaget inte kommer att betala tillbaka krediten. Det ingår som en del i den bedömning som görs av låneansökningar eller låneförnyelser. De kanske gör andra saker också, till exempel har vi ritat in att de också behöver rapportera statistik på hur väl de modeller de använder fungerar.

Nu till det viktiga. Om (jag säger om) det är så att de tjänster de tillhandahåller endast är intressanta för lånehanteringen och inte används i något annat sammanhang så är det samma sak som att säga att den komponenten är en helt innesluten del av lånehanteringen (dvs Loan Management). Den har inga tjänster som erbjuds utanför själva lånehanteringen. (Men märk att komponenten faktiskt återanvänds inom själva lånehanteringen, dvs den använd även vid förnyelse av lån.)

Om det i stället är så att kreditbedömning behöver göras även i andra sammanhang (jag kan inte komma på något bra exempel), och att det väsentligen är samma förmåga vi talar om, så innebär det lämpligen att Credit Scoring återanvänds utanför lånehanteringen. Credit Scoring bryts då ur Loan Management. Man kan då säga att Credit Scoring blir en gemensam infrastruktur som flera kan använda. Den ingår dock fortfarande i ett context, den är del av en större förmåga, kanske hela bankverksamheten, som ju faktiskt också är en komponent.

Ett annat alternativ är att Credit Scoring även fortsatt är en del av Loan Management men att Loan management exponerar dess tjänster direkt externt. Det är fallet om vi anser att Credit Scoring har ett så pass nära och ömsesidigt beroende (vad avser resurser, kompetens, information mm) av övriga delar av lånehanteringen så att det är bäst att även fortsatt se den som en integrerad del av lånehanteringen.

Varför det här är viktig är för att det är ett sätt att hantera komplexitet. I artikel 2 i serien går vi in mer på vad det innebär. om det här fortfarnade inte är tydligt är det jag som har förklarat dåligt. Kom gärna tillbaka med fler funderingar.

Tack för snabbt svar =)

Så om Credit Scoring blir en "gemensam infrastruktur" som flera kan återanvända, innebär inte detta då att denna kapabilitet kan förekomma och ha ett värde inom flera komponenter/kontexter?

Ett exempel skulle kanske kunna vara just Credit Scoring ändå, då den kanske bör kunna användas både för kreditbedömning av privatpersoner och företag?

Ett annat exempel jag tänker på är förmågan Visa kunduppgifter, eller Söka kunduppgifter, vilka verkligen känns som om de skulle kunna vara återanvändbara för olika komponenter inom ett företag, och isåfall behövas och vara värdefulla i flera kontexter. Eller hur tänker ni där?

Andreas skriver: ”Så om Credit Scoring blir en "gemensam infrastruktur" som flera kan återanvända, innebär inte detta då att denna kapabilitet kan förekomma och ha ett värde inom flera komponenter/kontexter?”

Peter svarar: Jag skulle hellre vilja se det som att ”kreditbedömning” blir en förmåga som förekommer i en kontext som är mer vid än lånehanteringen, det vill säga den kontext som omspänner både lånehantering och alla andra delar av verksamheten där kreditbedömningen har mening. Den finns alltså fortfarande i precis en kontext fast en större, Den kontexten skulle kunna vara bankverksamheten kanske. Det kan ju vara så att detta företag också har en försäkringsverksamhet och där gör man ingen kreditbedömning eller så handlar den om något helt annat. Nu var just detta ett dåligt exempel för jag kan inte se det som annat än troligt att kreditbedömning vore densamma i både bank och försäkring, men du förstår nog ändå vad jag menar. Kontext är viktigt och vi har alltid att göra med olika kontext. Många av dessa kontext går att ordna hierarkiskt, fast en del skär på andra håll. (Men det har vi inte kommit in på…)

Andreas skriver: Ett annat exempel jag tänker på är förmågan Visa kunduppgifter, eller Söka kunduppgifter, vilka verkligen känns som om de skulle kunna vara återanvändbara för olika komponenter inom ett företag, och isåfall behövas och vara värdefulla i flera kontexter. Eller hur tänker ni där?

Peter svarar: Att tillhandahålla uppgifter om en kund är ett klassisk exempel på en infrastrukturförmåga dvs en grundfunktion som används i många olika syften. Den finns alltså i en kontext som är mycket vid, dvs den yttre kapabilitet där tjänsterna exponeras torde vara hela verksamheten (vilket ibland är en del av det ett företag sysslar med, allt ett företag sysslar med eller gemensamt för flera företag). Men man kan tänka sig att man av olika skäl, bra eller dåliga, har två olika slags kunder och inget intresse eller i varje fall inte realiserad möjlighet av att dessa två kundkategorier finns i samma databas. Till exempel om man har två helt olika verksamheter där det inte finns några samband mellan. (ja, jag vet att jag hittar på sökta exempel..) I så fall har man två olika kontext med två olika förmågor att tillhandahålla kunduppgifter. Speciellt är det fallet om vi pratar realiteter och inte målbilder. Om två företag går ihop kommer de ganska länge att forstsätta att ha skilda kunddatabaser. Vi måste ju även kunna hantera verkliga fall inte bara målbilder… Eller om ett företag har verksamhet på två helt olika ställen i världen med helt olika möjligheter att lagra kunduppgifter. Då är du nog tvungen att se det som två olika funktioner, i varje fall om du inte ska leva i en teoretisk värld.

Hoppas det gav något /Peter

Tack Peter för snabba och bra svar, jag är med i ditt resonemang om att en kontext (om än vid) är hemvist för en förmåga.

Jag tror min fråga reflekteras av att jag vill kunna "instansiera" en förmåga (inkl kravmängden på densamma) inom den kontext där jag vill använda den (dvs en annan kontext än dess naturliga "hemvist/kontext"..), för att på så sätt modellera en samlad kravbild för den aktuella kontexten...

Förlåt Andreas, men där tappade du nog mig… Du kanske kan ge ett exempel...

Tack iaf för tålamodet =). Jag inser att min fråga är rent modelleringstekniskt.

Min utgångspunkt för resonemanget/frågorna är att jag vill fånga krav på mina förmågor, t.ex. inför en realisering av ett nytt system. Iom detta vill jag försöka få en samlad kravbild på de förmågor systemet behöver inneha för att stödja aktuell process. Om jag då inom denna process (som i sig ligger inom en egen kontext) behöver en förmåga som ligger "utanför" kontexten (visa kund t.ex.), så känns det som jag får problem rent modelleringstekniskt att visualisera den samlade kravbilden på förmågor om jag inte får återanvända samma förmåga i flera kontexter.. eller kanske är det just detta som exponering av tjänsten kan lösa (i detta fall rent modelleringstekniskt)?

Andréas: Att du kallar din fråga modelleringsteknisk gör den inte mindre viktig i mina ögon. Modeller är det media vi arbetar med när vi utvecklar verksamheter. Vi bygger gemensamma språk som blir de verktyg som vi behöver. Därför är det avgörande hur vi avbildar saker i modeller, för det blir så vi uppfattar saker och det blir också det vi kan tala om. (Ja jag vet att det osar Wittgensteins språkfilosofi lång väg, men också Eric Evans Domain Driven Modelling.)

Men nu till din fråga. Jag tror att du försöker blanda två mycket olika företeelser i ett och samma begrepp. Å ena sidan har vi det som vi i serien har benämnt ”Business Capability”, men som också kan heta ”Business Component” eller verksamhetsfunktion. Det är en del av en verksamhet som vi i vår gemensamma analys av en verksamhet uppfattar som naturligt avgränsad och självständig, och därmed lämplig att se som en ”komponent” av verksamheten. Vi befinner oss alltså i verksamhetsanalysens och verksamhetsarkitekturens domäner.

Å andra sidan har vi en viss funktionalitet som erbjuds av en programvara till någon. Det är en företeelse av ett helt annat slag, och ska inte blandas ihop med en verksamhetskomponent. Men det finns samband mellan dessa två företeelser för det är ofta med hjälp av funktionalitet i programvara som en verksamhetskomponenter samverkar.

För att närma sig ditt exempel kan man tänka sig att det finns en verksamhetsfunktion som har till uppgift att förvalta, vidareutveckla och tillhandahålla uppgifter om kunder som en gemensam resurs. (Jag har aldrig sett ett formaliserat ansvar för detta, utan det brukar ske mer på en höft. Fast lite mer formellt ansvar för detta vore nog bra i de flesta fall. Men låt oss för exemplets skull, föreställa oss ett sådant team, eller enskild person.) Denna verksamhetsfunktion (eller business capability) ha en egen intern informationsresurs, som borde vara betydligt fylligare än den information man är satt att förvalta. Man har kanske mätetal för informationskvalitet, statistik på användning av kundinformationen etcetera. Man har flera processer, bland annat för informationsinhämtning, kvalitetsförbättring, rapportering etcetera. Man har förståss ett it-stöd, tex den kunddatabas som man har ansvar för samt ett antal verktyg för sitt arbete. Man har kompetens för allt detta. Man erbjuder ett antal tjänster till sina ”kunder”. Flera av dessa är de mest centrala och handlar om att erbjuda kundinformation i olika former. Andra tjänster handlar kanske om att rapportera statistik till interna och externa parter. Man använder sig av tjänster som andra erbjuder, kanske man får addressuppdateringar från statens personuppgifter.

Kort sagt, en verksamhetsfunktion är som en hel liten verksamhet i sig. Och om man tror på det här perspektivet anser man att de interna processerna, de tjänster man erbjuder, kompetenserna, informationen, verksamhetsreglerna och it-systemen är tätt sammaflätade på så sätt att det är lämpligt att analysera, hantera och utveckla hela funktionen som en helhet.

En av de tjänster (verksamhetstjänster) som man erbjuder kanske är pakterad som en programvarubaserad tjänst dvs nu börjar vi närma oss tjänster i SOA-mening. En sådan SOA-tjänst används av programvaror som tillgodoser behov i andra verksamhetsfunktioner, interna eller externa.

Vi har alltså helt olika slags företeelser som vi bör hålla isär: Verksamhetsfunktioner (eller Business Capabilities), verksamhetstjänster, SOA-tjänster och funktionalitet i programvara. Sedan har vi olika förekomster av samma slag av företeelse som bildar olika kontext. Vi modellerar för att tillsammans skapa ett gemensamt språk och en gemensam förståelse för allt detta.

Jag vet inte om det blev glasklart, men kanske det gav lite hjälp framåt…

=) Ja, absolut.

Tack för fötydligandet. Om jag förstår rätt, och vi avgränsar oss från IT-komponenter och SOA-tjänster - Två företag som utbyter tjänster/varor går att jämföra med två "interna" Business Capabilites som samverkar genom verksamhetstjänster? Innebär detta oxå då att jag kan forma/anpassa mina verksamhetstjänster genom att välja vilka Business Capabilites som ska samverka för att uppnå önskat resultat?

Jag tror att mina frågetecken har löst sig isåfall, dvs grundfrågan "om capabiliteter i endast en kontext".. den kan jag köpa, förutsatt att det är verksamhetstjänsterna som "lyfter in" capabiliteterna där de behövs för att skapa ett värde till en mottagare.. kanske konstigt uttryckt, men låter det rimligt?

Fråga: Går två företag som utbyter tjänster/varor går att jämföra med två interna Business Capabilites som samverkar genom verksamhetstjänster?

Svar: Det är korrekt uppfattat, det finns ingen tydlig skillnad, vare sig i teorin eller i praktiken, och det är en viktig poäng. Om du köper din lunch i personalmatsalen eller i restaurangen tvärs över gatan gör inte att vi får radikalt olika företeelser. Fortfarande finns det en producent (restaurangen), en konsument (lunchgästen), en tjänst (Dagens Vegetariska), en ersättningsmodell (lunchkupong, avdrag på lönen, löneförmån eller kontant betalning), krav på tjänsten (näringsinnehåll, smaklighet, miljö mm.) Vi behöver samma uppsättning modelleringsbegrepp för båda företeelserna och samma tillvägagångssätt i verksamhetsarkitekturen)

Fråga: Innebär detta också då att jag kan forma/anpassa mina verksamhetstjänster genom att välja vilka Business Capabilites som ska samverka för att uppnå önskat resultat?

Svar: Ja, fast det är mer än själva tjänsterna som omformas då. Om man byter interna leverantörer så innebär det att ansvarsförhållanden blir annorlunda. Man omformar nätverket av samverkande parter. Man organiserar då om verksamheten.

Fråga: Om verksamhetstjänsterna ”lyfter in capabiliteterna”.

Svar: Nja, jag vet inte vad det betyder. Men man kan väl säga så här. Om det finns en kaffemaskin på marknadsavdelningen som bekostas och bara är avsedd för marknadsfolket så är det en verksamhetstjänst som tillhandahålles i en viss kontext, nämligen den capability som utgörs marknadsavdelningen. Kaffemaskinen ”finns inte” som en tjänst utanför marknadsavdelningen. Inom marknadsavdelningen finns både producenten och konsumenterna, alla processer som har med kaffehanteringen att göra med mera. Och så är det egentligen med precis alla tjänster. De finns i en viss kontext.

@ Peter. Du skrev -- "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."

Fråga 1: Kan du motivera varför verksamhetstjänster inte är direkt översättbara till elektroniska tjänster?

Jag arbetar för närvarande med att modellera en IT-avdelning enligt denna metamodell. En IT-avdelning kan ju också beskrivas som en uppsättning komponenter, precis som lånehanteringen ovan. Även om tjänsterna som exponeras är IT-tjänster finns det ett behov (bland annat för att fastställa lämplig organisatorisk struktur) av att enkapsulera dem i funktioner där det finns ett nära samband mellan information, kompetens mm. Jag upplever att det blir ett väldigt nära samband mellan IT-arkitekturen och verksamhetsarkitekturen om det är en IT-avdelning som är föremålet för analysen.

Fråga 2: Anser du att finns någon konceptuell skillnad i metamodellen ifall det är en IT-avdelning som ska beskrivas? En sak jag funderar på är att en IT-tjänst ofta "ligger och väntar" på att besvara ett anrop, medan tex låneförnyelsen har en mer tydlig instans av processen (trigger->aktiviteter->output). Kanske det är så att IT-tjänster alltid mynnar ut i det som du benämner "IT-stöd" i modellen.

Svar till Anders: Försök till svar på fråga 1: En verksamhetstjänst är något en verksamhetsfunktion erbjuder en annan verksamhetsfunktion. Det kan till exempel vara att logistikavdelningen erbjuder försäljningsavdelningen att se till att en leverans skeppas. Det är något som inte helt och hållet kan utföras digitalt, så vida det inte handlar om digitala produkter. Men låt oss säga att det verkligen handlar om en digitala produkter , som till exempel försäkringar, bankkonton, musikfiler. Då kanske man kan tänka sig att en viss verksamhetstjänst helt och hållet kan implementeras som en elektronisk tjänst. Åtminstone om den verksamhetstjänsten är helt automatiserad. Men det betyder knappast att man utan vidare kan anta att precis samtliga tjänster den verksamhetsfunktionen tillhandahåller, det vill säga all interaktion med omvärlden är elektronisk. Det kan ju vara så även om jag inte har något bra exempel, men jag menar att vi i så fall måste gå igenom verksamhetstjänsterna en efter en för att se hur de kan implementeras eller är implementerade.

Försök till svar på fråga 2: Jag kan inte se att om man skulle vilja se en it-avdelning som en verksamhetsfunktion, avviker på något sätt från andra verksamhetsfunktioner. På hög nivå erbjuder väl en it-avdelning saker som ”förvaltning och utveckling av it-stöd”, ”drift och användarstöd”, vilket är tjänster som levereras i form av att människor dyker upp och gör saker och därmed inte har speciellt många möjligheter att levereras elektroniskt.

Men jag tycker att det är en dålig idé att betrakta en it-avdelning som en funktion som är avskild från verksamheten, även om det är mycket vanligt. Skälet är att man inte ska dela på saker som naturligt hör samman, dvs saker som behöver interagera ömsesidigt, bredbandigt, tätt och ömsesidigt. Och det gäller för allt som görs av it-avdelningar, inte bara för utveckling utan även för applikationsdrift och stöd. Det vill säga att all it-utveckling egentligenm är verksamhetsutveckling, all applikationsdrift egentligen är drift av en verksamhetsprocess, och allt användarstöd egentligen är stöd till en verksamhetsfunktion. Därmed är alla vi som jobbar med it verksamhetspersoner, har verksamhetskunskap och bör jobba tätt ihop med de som vi behöver arbeta med i respektive verksamhetsfunktion.

Så skrota it-avdelningen, och flytta personerna dit de hör hemma. Om du utvecklar it-stöd till en viss verksamhet är du verksamhetsutvecklare och eftersom en verksamhet bör utvecklas av de som jobbar i den kan du på ett enkelt sätt bli mycket mera produktiv genom att du flyttar över dit.