Kan vi gifta ihop it-sidan med verksamheten?
Om Business Capabilities – det nya synsättet på verksamhet
2011-09-28: Peter Tallungs och Robert Elm
TREDJE DELEN AV TRE Komponentperspektivet ger en ny infallsvinkel på klassiska problem inom EA-området.
Vi har i två spaningar skrivit om ett nytt sätt att se på en verksamhet. I stället för att skiva hela verksamheten rakt över i ett antal aspekter, som processer, information med mera, kan vi se den som ett antal autonoma parter som nätverkar.
Det synsättet har många styrkor. Vi tror att det kan bidra till att lösa upp klassiska knutar inom EA-området. Vi ger här två exempel.
Problem 1: SOA har inte levererat
Det senaste decenniet har det funnits en strävan att bryta upp it-landskapet i våra företag och organisationer. Man har önskat omforma det från ett antal monolitiska it-system till fler mindre och autonoma komponenter i form av elektroniska tjänster. Det har kallats SOA, Service Oriented Architecture.
Det stora löftet med SOA var att det skulle ge en systemportfölj som bättre avspeglar och följer verksamhetens behov över tiden. Diskursen har handlat om hur en tjänst bör utformas, för största möjliga oberoende i syfte att bli tålig och flexibel. Ämnet är förstås viktigt men också grundligt genomtröskat vid det här laget. Vi har hyllmetrar hemma som handlar om design av SOA-tjänster.
Men när det kommer till vilka tjänster vi egentligen ska bygga, hur vi ska komma fram till planen för tjänsteportföljen, blir det märkligt tyst. Alla är överens om att tjänsteportföljen ska baseras på en väl utformad och korrekt verksamhetsanalys. Men ingen har kunnat visa hur en sådan ska tas fram eller vilka delar som ska ingå. Och ingenstans har vi heller sett att man tagit fram en plan för en tjänsteportfölj som har haft mening för en verksamhet.
Det har visserligen gjorts försök att få ihop tjänster med de traditionella företeelser inom verksamhetsarkitektur, som processer och informationsobjekt. Men inget har varit övertygande som gemensam plattform och språk för it- och verksamhetsfolk.
De SOA-satsningar som har gjorts har följaktligen varit interna övningar för it-arkitekter. Man har i bästa fall fått det som brukar kallas JBOWS, ”Just a Bunch of Web Services”, vilket knappast är en tjänstebaserad enterprise-arkitektur.
Vi har saknat ett gemensamt språk och en gemensam plattform mellan verksamhet och it för att bygga tjänster som verkligen kan bli verksamhetens gemensamma tillgångar. Således har EA-samhället misslyckats, och det på det som borde vara hemmaplan, att få it och verksamhet att lira ihop.
Vi tror att det komponentsynsätt på verksamhet som nu växer fram är den saknade länken som kan få SOA att leverera. Vi motiverar det i det följande.
Lösning: Förankra tjänsterna i verksamhetens förmågor
En SOA-tjänst behöver förankring i en verksamhet, den är alltid en implementation av en verksamhetstjänst eller en del av en verksamhetstjänst. Med verksamhetstjänst menar vi något som en verksamhetsfunktion erbjuder andra verksamhetsfunktioner, interna eller externa till organisationen.
En tjänst har alltid en producent och ett antal konsumenter. Kedjan producent-tjänst-konsument manifesterar sig samtidigt på flera nivåer i en stack. På låg nivå är det ett it-system som använder en tjänst hos ett annat it-system. På hög nivå är det en verksamhetsfunktion som använder en tjänst som en annan erbjuder. Om ett it-system skickar information till ett annat betyder det att något händer i verksamheten. Det kanske är Produktion som meddelar Logistik om att ett ordernummer är klart att skeppa.
Vi har sett att det är naturligt för människor att betrakta och hantera sitt område som en avgränsad funktion med ett visst ansvar och att det är naturligt att se det som att man har interna och externa kunder man erbjuder tjänster. Tjänster existerar inte i vakuum. En tjänst är något som en part erbjuder andra parter.
För att tänka och tala om tjänster behöver vi tänka och tala om subjekten, det vill säga de parter som är producenter och konsumenter av respektive tjänst. Inom verksamheten är det de naturliga funktionerna, Business Capabilities, som är producenter och konsumenter. Därmed har vi fått ett synsätt på verksamhet som i grunden är tjänstebaserad. Den består av avgränsade funktioner som samverkar genom tjänster.
Om verksamhetsarkitekter verkligen börjar anamma komponentperspektivet och börjar stötta it-sidan i arkitekturarbetet kanske SOA sent omsider kan leverera vad som så länge lovats.
Vad är då trenden? Det är vanligt att bygga tjänster, men vi har inte sett att det bli något annat än en teknisk design och således inget som får it och verksamhet att spela i samma match. Vi tror fortfarande fullt och fast på SOA, men bara om vi får till en helt annan förankring av SOA-satsningarna i verksamheten än den vi sett hittills.
Problem 2: Avstånd mellan it-sidan och verksamheten
Vi lever i en tid då många säger att it-sidan inte ska vara en leverantör till verksamheten utan en integrerad partner. Ambitionen finns säkert där men det är än så länge tomma ord. Ofta undrar vi om man verkligen har förstått vad integration innebär. Det innebär ju faktiskt att ens ursprungliga identitet och tillhörighet upplöses mer eller mindre och man får en ny hemvist. Det innebär att du faktiskt måste ta din stol och gå över till andra sidan.
Är du it-utvecklare som jobbar med kreditsystem måste du börja se dig som utvecklare av kreditverksamheten och sitta med och jobba med kreditanalytikerna och de som utvecklar kreditmodeller och kredithanteringen!
Sköter du Data Warehouse-supporten måste du börja se dig som en del av verksamheten, nämligen en expert på verksamhetens information, hur man kommer åt den, vad den betyder, vad man kan göra med den och hur man ställer de frågor mot informationen man behöver ställa och tolka de svar man får. Du är helt enkelt en verksamhetsexpert och bör sitta med dina kollegor på andra sidan, de marknads-, risk-, och finansanalytiker som du behöver samverka nära med. Det kan till och med bli så att du får lämna Foppa-tofflorna hemma och ta på en kavaj!
Vi ser dagligen hur organisationer hämmas i sin funktion och utveckling genom att vi fortfarande drar en gräns tvärs igenom funktioner som vi inte borde dra och kalla den ena delen för it och den andra för verksamhet.
För oss är drömmen och målet att lösa upp it-avdelningen och flytta över allt it-folk dit de hör hemma, ihop med dem de behöver jobba tätt ihop med. Men då måste vi ju också säga vilka som ska sitta hos vilka?
Lösning: Samgruppera it och verksamhet baserat på förmåga
De autonoma verksamhetsförmågorna vi har beskrivit är de naturliga enheterna, de som behöver dela kompetens, it-system, intern information, tjänster, kunder med mera. Där har vi förstås svaret. Det är de vi bör gruppera runt, och inte som nu separerat på ”it” och ”verksamhet”, där allt som klassas som ”it” också fösts ihop i en flock .
Men en sådan förändring kräver att vi förmår släppa det nedärvda axiomet som säger att it-arbete är att vara underleverantör till verksamheten.
Vad är då trenden? Är det här något som händer i dag eller i närtid eller är det en orealistisk dröm?
Det vi har sett är snarare en mottrend att man från 90-talet och framåt, inom managementkretsar, starkt har betonat synen att it-sidan är en leverantör. Det är svårt att överdriva hur mycket övertro på outsorcing av it har skadat våra myndigheter och företag de senaste 20 åren.
På senare år har vi börjat se en svängning. Fler och fler börjar äntligen tvivla på att it är en nyttighet man kan köpa på kran. En del it-avdelningar har organiserat om sig från resurspooler baserade på teknik till mindre team baserade på vilken del av verksamheten man stödjer.
Vi har också sett specifika områden där man vill gå mot att samgruppera it och verksamhet. Exempel är Data Warehouse-området där man de senaste åren har byggt upp Business Intelligence Competence Centers, BICC, på en del håll. Så nog finns det en trend mot att it-sidan närmar sig verksamheten baserat på vilken verksamhetsfunktion man stödjer. Det är dock en rännil. Ge oss en kraftfull ström!
Två sidor av samma mynt?
Kanske kan man se problem ett och två ovan som två sidor av samma mynt. De handlar båda om it-sidans tendens att se sig som leverantör och därmed dess oförmåga att jacka in i verksamheten på rätt plats, det vill säga i alla de enskilda funktioner verksamheten består av - vare sig det gäller systemportföljen (problem 1) eller det dagliga arbetet (problem 2).
Och lösningen är densamma: Vi behöver finna verksamhetens naturliga delar och se till att punktmarkera dem.
Och en sak till: Denna gång kommer vi inte undan med powerpoint-bilder som det står ”Business-IT Alignment” på, utan det krävs daglig och handfast gärning på plats i verksamhetens vardag.
Det här var sista delen av vår spaning om Business Capabilities. Vi är tacksamma för den dialog vi har fått med läsarna runt detta utvecklingsspår inom verksamhetsarkitekturområdet. Vi hoppas på fler kommentarer.
Håller du med om att it-sidan bör sträva mot att bli en integrerad del av verksamheten? Vad gör it-folket i din organisation för att komma dit? Tror du att det kan hjälpa att samarbeta nära runt enskilda funktioner? Bygger ni SOA idag? Hur ser ni till att SOA-tjänsterna uppfattas som en gemensam resurs och verkligen hanteras som en sådan?
Vi arbetar med utveckling av affär, verksamhet och IT. Det handlar om att coacha IT- och verksamhetsutvecklare att arbeta tillsammans och leverera värde dag för dag. Vi tror att vi lever i en tid av uppvaknande. Det som nu händer i relationen mellan IT och verksamhet är större än allt som hänt tidigare. Detta vill vi skriva om.
Vi är anställda på konsultföretaget IRM som startades med modelldriven verksamhets- och systemutveckling som bärande idé år 1982. IRM driver utbildningarna Certifierad verksamhetsarkitekt sedan 1994 samt Certifierad process- och verksamhetsutvecklare.
Du når oss på peter.tallungs@irm.se och robert.elm@irm.se.
Peter Tallungs och Robert Elm
#1 Patrik Lager |
torsdagen den 29 september 2011 kl. 07:43 |
En intressant artikelserie.
En av mina käpphästar när det gäller EA är relationen Process och IT och övertron på Process och IT relationen.
I mina ögon så är t ex EII, SOA, MDM och Enterprise Data Warehouse arkitekturella lösningar som försöker bota "symptom" och inte "orsak" till de problem/utmaningar vi har idag.
Orsaken till att man måste använda sig av dessa arkitekturella mönster är att man inte har ett professionellt handhavande av information inom företag.
Information är en tillgång men ytterst få företag tar hand om den. Vi har Finance för monetära tillångar, HR för mänskliga tillgångar, och sedan så har man dumpat ansvaret för Informations tillgångar på IT, på grund av att....man lagrar informationen i ett system som IT driftar? För att IT anställda kan rita datamodeller?
Varför håller man på med EII/SOA/EDW? Jo för att man vill kunna använda och dela information över system/process/avd/org/lands- gränser. Så vaför bygger vi då inte ett ett Informationslandskap som stödjer detta istället för att för att behöva slå knut på oss för att skapa informationsintegration.
Min tro är att IT bör ses för vad den är till stor del idag, Teknik, hårdvara, mjukvara, och istället lyfta fram Information Management som en fristående stödprocess organisation placerad där den hör hemma, hos affären.
Dock så saknas det idag på arbetsmarknaden till stor del den kompetens som behövs för att i framtiden säkerställa att vi kan utnyttja vår informationstillgång på rätt sätt och utbildningarna som finns på universitet/högskolor är för IT inriktade. Även kurser från leverantörer är antingen för teknikorienterade, modellorienterade eller processorienterade, istället för att vara informationsorienterade.
Det är i grund och botten processernas fel att vi har informationsintegrationsproblem idag. Vi har implementerat processer i 50 år som informationsautonoma enheter med sina unika IT system som stöd och vi är fortfarande kvar där men vi har i 20 år velat dela på informationen. Ser ni vart det går fel? Utan en gemensam informationsyn så kan inte processer "nätverka" hur bra de än är designade, iaf inte utan avancerade integrationslösningar, typ SOA, vilket är helt omöjliga att bygga utan en gemensam informationssyn. Gör om, gör rätt och sluta tro att information är ett IT ansvar.
Nä jag får sluta nu...ni fattar nog poängen.
mvh /Patrik
#2 Peter Tallungs |
torsdagen den 29 september 2011 kl. 19:52 |
Tack för din snabba kommentar. Vi skrev inte explicit om informationsperspektivet inom EA, men ändå nappade du. Och nog finns det en viktig koppling till det området.
*** Om övertro på processer Jag håller med om att processer har varit och fortfarande ofta är ensamt dominerande inom verksamhetsanalys på bekostnad av andra modeller, inte minst begrepps- och informationsmodeller. Många gånger har vi sett att man har trott att man beskrivit sin verksamhet när man har modellerat sina processer. Vi har också upplevt att en del verksamhetsarkitekter visserligen har förstått att det inte räckt med processer men inte vetat hur man arbetar med informationsmodeller mellan verksamhet och it. Även i övrigt har det funnits en övertro på processer. Till exempel har en processorienterad verksamhet framställts som slutmålet, för alla typer av verksamheter. Detta har skymt bättre mål.
*** Om att informationsperspektivet har hamnat mellan stolarna Absolut är det så. Fast det skulle inte varit lika stort problem om it-sidan hade försökt och växa in i ansvaret. Nu ser vi ofta bara en uppgivenhet eller total blindhet. Jag har länge jobbat som informationsarkitekt tvärs över it och verksamhet. Som spelande tränare lär jag individer, team och hela it-organisationer att ta ansvar för informationsarkitekturen och jobba nära verksamheten. Det fungerar. Det är en mognadsprocess. Om man kan få till synligt resultat tidigt ger det ett självförtroende och det blir en god spiral.
*** Om att ex EII, SOA, MDM och EDW är fulfixar i stor skala Mycket bra sagt. Men det går faktiskt att inom ramen för sådana satsningar bygga upp en kunskap, teamwork och en mogen organisation som tar sig an själva grundproblemet på ett bra sätt. Det vill säga bygger upp ett arbetssätt och en filosofi där man tar gemensamt ansvar för informationen. Det är egentligen ingen som hindrar oss. Om vi kan visa ett övertygande positivt resultat i något mindre skala får vi snart carte blanche. Om vi har lyckats bör du också kunna lyckas med det.
*** Om att it-sidan bör ägna sig åt teknik enbart Nej vad tråkigt det skulle vara! Här skiljer vi oss i syn på taktik/strategi. Vi har samma slutmål, men vi har valt motsatta vägar. Jag jobbar dagligen för att it-folk ska se sig som verksamhetsfolk och jag ser att det fungerar. Inte i morgon utan nu och här. Vad skulle det hjälpa att flytta problemet?
***Om att vi i branschen saknar informationsarkitekter mm Absolut är det så och vi har lyft frågan i en tidigare spaning. Det här är en hjärtefråga för oss. Vi gör vad vi kan för att få till utbildning, coachning, erfarenhetsutbyte. Men vi behöver hjälp av de få människor som har den kompetens och erfarenhet som behövs. Jag vet att det finns mycket vi kan göra med enkla medel. Vi kommer då i varje fall ur den låga nivå vi befinner oss i, i branschen nu. Vi har idéer. Vi kan väl hjälpas åt.
#3 Kristian Karre |
torsdagen den 29 september 2011 kl. 21:53 |
Lite öppna dörrar att slå in här: Informationen är oftast relativt stabil över tid, så det ger oss ledtråd till vad vi ska bygga runt, oavsett om vi tittar på förmågor, organisation eller tjänster. Helt med där. Köra Info Mgmt separat och reducera IT till teknik... Tjaa... Om du menar att företaget ska ha noga kontroll på sin information oavsett ifall man kör IT inhouse eller outsourcat, håller jag med. Jag är väl lite trött på alla olika debatter kring organisatoriska indelningar, om vad som ska vara var. För mig är det centralt att man någonstans behåller helhetsperspektivet och bevakar att olika områden i sin optimeringsiver inte suboptimerar för företaget. Sen kan informationen skötas på olika sätt, bara den sköts! Separation av begrepp och information samt regler gör det hela än mer framtidssäkrat. Ibland är IT leveransslavar som hjälper till att realisera affärens strategier, ibland finns stort förtroende för IT och man är med och diskuterar vilka strategier som är möjliga med aktuellt systemstöd etc. I den förra typen av företag bör man förstås göra allt för att placera strategiskt viktiga funktioner utanför IT, i den senare är det inte viktigt. Så, jag rundar väl av med... det beror på (förlåt).
#4 Patrik Lager |
fredagen den 30 september 2011 kl. 15:07 |
*** Om att it-sidan bör ägna sig åt teknik enbart Nej vad tråkigt det skulle vara! Här skiljer vi oss i syn på taktik/strategi. Vi har samma slutmål, men vi har valt motsatta vägar. Jag jobbar dagligen för att it-folk ska se sig som verksamhetsfolk och jag ser att det fungerar. Inte i morgon utan nu och här. Vad skulle det hjälpa att flytta problemet? *** Bra vinkling med att få IT ses som en del av verksamheten. Det skulle uppnå samma sak. Det viktiga är förståelsen att Information måste hanteras proffessionellt och att det inte är en biprodukt av processer utan en strategisk/taktisk/operationell tillgång inom företaget.
För bra feedback på mina åsikter.
/Patrik
#5 Anders Danielsson |
fredagen den 7 oktober 2011 kl. 15:54 |
Håller med om att den högsta graden av samarbete är att samgruppera IT och verksamhet baserat på förmåga. Detta låter dock sig inte göras med mindre än att man stegvis "mognar" IT-organisationen från teknikfokus -> tjänstefokus -> kundfokus -> fokus på kundens verksamhet (grovt indelat). Först därefter kan man fullt ut nå en samgrupperingen. De flesta misslyckas redan i steget tjänstefokus, tyvärr. Att ge sig på samgrupperingen utan att stegvis ha genomgått de tidigare mognadsstegen tror jag är dömt att misslyckas, eftersom förändringssteget då blir för stort.
Jag skulle inte säga att detta är en orealistisk dröm, däremot en lång resa som kräver att man verkligen vet vad man håller på med. Det krävs också att ledningen är beredd att sponsra IT-organisationen med ytterligare resurser i varje steg, eftersom fler roller successivt måste skapas. Och huruvida det sker beror på vilken mognadsgrad ledningen önskar hos IT inom sin organisation (en förutsättning är att ledningen är medveten om mognadsgrader i denna kontext).
/Anders
#6 Peter Tallungs |
fredagen den 7 oktober 2011 kl. 17:09 |
Tack för dina kloka ord Anders. Det är sant att det är en mognadsresa för en organisation och att en resa alltid går en steg i taget.
Jag håller också grovt med om stegen som du har angivit, fast jag har någon undran där. När man säger "tjänstefokus" kan man mena minst tre olika saker, för "tjänst" används i (minst) tre olika betydelser i detta sammanhang.
1. De tjänster som en it-funktion levererar till en "kund" dvs till verksamheten. 2. De tjänster som finns i form av programvara då man strukturerar sin systemportfölj som "tjänster", dvs it-fokuserad SOA. 3. De tjänster som verksamhetsfunktioner/komponenter/förmågor tillhandahåller till sin omgivning.
Jag är osäker på vilken betydelse du avser, men håller nog med om alla tre (mer eller mindre), fast de representerar en mycket stor skillnad i mognad.
Och när du säger "kundfokus" så vill jag nog säga att så länge vi tycker att verksamheten är en "kund" så har vi inte börjat se oss som en del av verksamheten.
Vi vill gå längre än så. Vad kommer bortom kundfokus? En slags identitetsupplösning. Fraternisera med kunden så mycket att du tappar den affärsmässiga distansen. När du börjar säga "vi" är du på rätt väg.
Om att man behöver ledningen med sig: Det är sant men jag tror att förtroende får man inte det förtjänar man. Man jobbar ihop till det. Jag tror att it-sidan inte ska sitta och vänta på att ledningen ska fatta, de ska i stället dagligen och stundligen visa att de kan ta ansvar och att det fungerar. Man ska inte be om lov för att jobba på ett proffsigt sätt.
Det jag vill komma ifrån är att vi fortsätter vänta på att ledningen ska bli klokare och förstå hur fantastiskt bra det blir när vi får vara med och ta ansvar. Jag tycker att vi ska visa det i stället genom att redan nu leverera det som egentligen behövs. Det är tråkigt och inneffektivt när vi skyller på andra, oftast på "ledningen", i stället för att själv förändra det vi kan i vår omgivning.
Håller du med? Vad säger alla andra läsare?
#7 Anders Danielsson |
måndagen den 10 oktober 2011 kl. 08:36 |
Här syftade jag inte på tjänst i SOA-bemärkelsen, utan som gränssnitt mellan två aktörer. För övrigt ser jag ingen principiell skillnad mellan 1 och 3?
Jag håller med dig and det du skriver om "kund". Jag menar också på att vi bör gå längre än så, och att denna "identitetsupplösning" motsvarar den högsta graden av mognad.
Tack för intressanta artiklar förresten!
/Anders
Ser du någon kommentar som du tycker är kränkande eller olaglig? Då kan du anmäla den här >>
Skriv en kommentar...