Op zoek naar de essentie van een bedrijf: het modelleren van business capabilities

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2012 – 2013

Op zoek naar de essentie van een bedrijf: het modelleren van business capabilities

Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur

Peter Depypere onder leiding van Prof. dr. Geert Poels

II

UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 2012 – 2013

Op zoek naar de essentie van een bedrijf: het modelleren van business capabilities

Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur

Peter Depypere onder leiding van Prof. dr. Geert Poels

III

PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Peter Depypere

IV

WOORD VOORAF Deze masterproef is het sluitstuk van mijn vijfjarige studie Handelsingenieur aan de Universiteit Gent. Mijn naam staat onder deze masterproef, maar ik zou oneer aandoen aan alle mensen die hebben meegeholpen om dit eindwerk tot een goed einde te brengen. Vooreerst zou ik prof. dr. Geert Poels willen bedanken. Hij was de persoon die sinds mijn eerste academiejaar op de universiteit mijn interesse in IT aanwakkerde en ik ben dan ook dankbaar om deze masterproef onder zijn begeleiding te kunnen afwerken. Zonder zijn stimulerende feedback zou dit eindwerk niet hetzelfde zijn. Verder mag ik zeker mijn ouders niet vergeten die me de best mogelijke opvoeding gegeven hebben en die me altijd hebben gesteund om mezelf verder te ontwikkelen. De vele gesprekken die we hebben gehad over dit onderwerp hebben zeker meegedragen tot deze masterproef. Ten slotte wil ik nog mijn vriendin bedanken die er altijd voor me was als ik het moeilijk had en die me doorheen deze studie altijd door dik en dun heeft gesteund.

V

INHOUDSTAFEL WOORD VOORAF ............................................................................................................................................... V INHOUDSTAFEL ................................................................................................................................................. VI LIJST VAN FIGUREN ........................................................................................................................................... XI LIJST VAN TABELLEN ........................................................................................................................................ XIII LIJST VAN GEBRUIKTE AFKORTINGEN.............................................................................................................. XIV 1

INLEIDING ................................................................................................................................................. 1 1.1

Probleemstelling ............................................................................................................................ 1

1.2

Structuur........................................................................................................................................ 2

DEEL 1: LITERATUURSTUDIE ............................................................................................................................... 4 2

BUSINESS CAPABILITIES: WAT EN WAAROM? .................................................................................................... 4 2.1

Wat zijn capabilities? ..................................................................................................................... 4

2.1.1

Definities ..............................................................................................................................................................4

2.1.2

Het concept capability ........................................................................................................................................5

2.1.2.1

Stabiliteit ...................................................................................................................................................6

2.1.2.2

Horizontale structuur ................................................................................................................................6

2.1.2.3

Interactie ...................................................................................................................................................7

2.1.2.4

Verticale structuur ....................................................................................................................................7

2.1.2.5

Abstractie van middelen ...........................................................................................................................9

2.1.2.6

UML weergave van een capability ...........................................................................................................9

2.1.3

Capabilities vs. Processen .................................................................................................................................10

2.1.3.1

Kritiek op capabilities ..............................................................................................................................11

2.1.3.2

Definitie van proces ................................................................................................................................12

2.1.3.3

Verschil in karakteristieken ....................................................................................................................12

2.1.3.4

Capabilities en processen in synergie ....................................................................................................14

2.2

Waarom modelleren we business capabilities? ............................................................................ 17

2.2.1

Stabiel beeld van de onderneming...................................................................................................................18

2.2.2

Capabilities als bron van kerncompetenties ....................................................................................................18

2.2.2.1

Competitief voordeel ontwikkelen .........................................................................................................19

2.2.2.2

Competitief voordeel behouden ............................................................................................................20

2.2.2.3

Toe-eigenen van voordeel ......................................................................................................................20

2.2.3

2.3

Hulpmiddel voor business/IT alignment ..........................................................................................................20

Toepassingen van capabilities modellen....................................................................................... 21

2.3.1

Heat mapping ....................................................................................................................................................22

2.3.2

Investeringsbeslissingen ...................................................................................................................................24

2.3.3

Gap-analyse voor business/IT alignment .........................................................................................................25

VI

2.3.4

Outsourcen ........................................................................................................................................................25

2.3.5

Strategische uitvoering .....................................................................................................................................26

2.4 3

Conclusie...................................................................................................................................... 26

MODELLEN EN TECHNIEKEN OM CAPABILITIES TE MODELLEREN ............................................................................. 27 3.1

Inleiding ....................................................................................................................................... 27

3.2

Algemeen capabilitymodel ........................................................................................................... 28

3.2.1

Oorspronkelijk doel van Model ........................................................................................................................29

3.2.2

Definitie van capability .....................................................................................................................................29

3.2.3

Organisatie van de capability map ...................................................................................................................29

3.2.4

Visualisatie van de capabilities .........................................................................................................................31

3.2.5

Beschrijving van capabilities .............................................................................................................................32

3.2.6

Doelpubliek .......................................................................................................................................................34

3.3

Microsofts visie ............................................................................................................................ 34

3.3.1

Oorspronkelijk doel van model ........................................................................................................................35

3.3.2


3.3.3


3.3.3.1

Foundation capabilities ...........................................................................................................................36

3.3.3.2

Capability groepen ..................................................................................................................................38

3.3.3.3

Business capabilities ...............................................................................................................................38

3.3.4


3.3.5


3.3.6

Doelpubliek .......................................................................................................................................................42

3.4

IBMs visie ..................................................................................................................................... 43

3.4.1


3.4.1.1

Interne specialisatie ................................................................................................................................43

3.4.1.2

Externe specialisatie ...............................................................................................................................44

3.4.1.3

Component Business Model (CBM)........................................................................................................45

3.4.2


3.4.3


3.4.3.1

Business competenties ...........................................................................................................................46

3.4.3.2

Verantwoordelijkheid/toerekenbaarheid ..............................................................................................46

3.4.4


3.4.5


3.4.6

Doelpubliek .......................................................................................................................................................48

3.5

Klinkmüller et al. .......................................................................................................................... 49

3.5.1


3.5.2


3.5.3


3.5.4


3.5.5


3.5.6

Doelpubliek .......................................................................................................................................................54

VII

3.6

Value Delivery Modeling Language (VDML) ................................................................................. 54

3.6.1


3.6.2

Definities ............................................................................................................................................................56

3.6.2.1

Value en Value Proposition .....................................................................................................................56

3.6.2.2

Collaboratie, organisatie, rollen en activiteiten ....................................................................................57

3.6.2.3

Capability, Capability Offer en Capability Method ................................................................................57

3.6.2.4

VDML Metamodel ...................................................................................................................................58

3.6.3


3.6.4


3.6.5


3.6.5.1

Capability taxonomie ..............................................................................................................................60

3.6.5.2

Capabilities in combinatie met andere concepten ................................................................................61

3.6.6

3.7

Doelpubliek .......................................................................................................................................................62

Conclusie...................................................................................................................................... 62

DEEL 2: MODELLEREN VAN CAPABILITIES IN EEN GEVALLENSTUDIE ................................................................ 63 4

GEVALLENSTUDIE ...................................................................................................................................... 63 4.1

Inleiding ....................................................................................................................................... 63

4.2

AB InBev: een voorstelling ............................................................................................................ 63

4.2.1

4.2.1.1

Productie van bier ...................................................................................................................................64

4.2.1.2

Verkoop en distributie van bier ..............................................................................................................64

4.2.1.3

R&D binnen AB InBev ..............................................................................................................................65

4.2.1.4

Wereldwijde organisatie .........................................................................................................................65

4.2.2

5

Wat doen ze?.....................................................................................................................................................64

Visie, missie en strategie...................................................................................................................................65

4.2.2.1

Visie..........................................................................................................................................................66

4.2.2.2

Missie .......................................................................................................................................................66

4.2.2.3

Strategie ..................................................................................................................................................67

4.3

AB InBev: Business Motivation Model .......................................................................................... 68

4.4

Conclusie...................................................................................................................................... 69

TOEPASSING VAN MODELLEN OP GEVALLENSTUDIE ............................................................................................ 70 5.1

Inleiding ....................................................................................................................................... 70

5.2

Criteria voor een capabilitymodel................................................................................................. 70

5.3

Capabilities van AB InBev volgens Microsoft ................................................................................ 71

5.3.1

Omschrijving van de capabilities ......................................................................................................................74

5.3.2

Bepalen van Service Levels ...............................................................................................................................75

5.3.3

Inkapseling van mensen, processen en technologie .......................................................................................77

5.3.4

Omschrijving van interacties ............................................................................................................................78

5.3.5

Bepalen van de eigenaar...................................................................................................................................79

5.3.6

Meten van attributen........................................................................................................................................80

5.3.6.1

Strategische waarde................................................................................................................................81

VIII

5.3.6.2

Performance ............................................................................................................................................82

5.3.6.3

Rijpheid ....................................................................................................................................................83

5.3.6.4

Verbondenheid met andere capabilities................................................................................................83

5.3.6.5

Capabilities binnen Lever Product met attributen ................................................................................84

5.3.7

Visualisatie en heat maps .................................................................................................................................84

5.3.7.1

Ontwikkel Product...................................................................................................................................85

5.3.7.2

Creëer Vraag............................................................................................................................................85

5.3.7.3

Lever Product ..........................................................................................................................................85

5.3.7.4

Plan en Beheer Onderneming ................................................................................................................86

5.3.7.5

Beheer Samenwerking ............................................................................................................................87

5.3.8

ondersteuning van tools ...................................................................................................................................89

5.3.9

Evaluatie ............................................................................................................................................................89

5.4

Capabilities van AB InBev volgens IBM ......................................................................................... 90

5.4.1

Omschrijving van de capabilities ......................................................................................................................93

5.4.2

Bepalen van Service Levels ...............................................................................................................................95

5.4.3

Inkapseling van mensen, processen en technologie .......................................................................................96

5.4.4

Omschrijving van interacties ............................................................................................................................96

5.4.5

Bepalen van de eigenaar...................................................................................................................................97

5.4.6

Meten van attributen........................................................................................................................................98

5.4.7

Visualisatie en heat maps .................................................................................................................................98

5.4.8

ondersteuning van tools .................................................................................................................................100

5.4.9

Evaluatie ..........................................................................................................................................................100

5.5

Capabilities van AB InBev volgens Klinkmüller et al. ................................................................... 101

5.5.1

Omschrijving van de capabilities ....................................................................................................................102

5.5.2

Bepalen van Service Levels .............................................................................................................................102

5.5.3

Inkapseling van mensen, processen en technologie .....................................................................................102

5.5.4

Omschrijving van interacties ..........................................................................................................................102

5.5.5

Bepalen van de eigenaar.................................................................................................................................102

5.5.6

Meten van attributen......................................................................................................................................102

5.5.7

Visualisatie en heat maps ...............................................................................................................................104

5.5.8


5.5.9

Evaluatie ..........................................................................................................................................................107

5.6

Capabilities van AB InBev volgens VDML .................................................................................... 109

5.6.1

Omschrijving van de capabilities ....................................................................................................................109

5.6.2

Bepalen van Service Levels .............................................................................................................................109

5.6.3

Inkapseling van mensen, processen en technologie .....................................................................................110

5.6.4

Omschrijving van interacties ..........................................................................................................................111

5.6.5

Bepalen van de eigenaar.................................................................................................................................112

5.6.6

Meten van attributen......................................................................................................................................112

5.6.7

Visualisatie en heat maps ...............................................................................................................................112

5.6.8


5.6.9

Evaluatie ..........................................................................................................................................................113

IX

5.7 6

7

Conclusie.................................................................................................................................... 114

RELATIE MET ANDERE BEDRIJFSMODELLEN ..................................................................................................... 116 6.1

Relatie met het Business Motivation Model ............................................................................... 116

6.2

Relatie met procesmodellen en servicemodellen ........................................................................ 117

6.3

Conclusie.................................................................................................................................... 119

ALGEMEEN BESLUIT ................................................................................................................................. 120 7.1

Literatuurstudie ......................................................................................................................... 120

7.2

Gevallenstudie ........................................................................................................................... 122

BIBLIOGRAFIE ................................................................................................................................................... XV BIJLAGE A: BUSINESS MOTIVATION MODEL METAMODEL ............................................................................. XIX BIJLAGE B: GENERIEKE LIJST VAN CAPABILITIES VOLGENS MICROSOFT ........................................................... XX BIJLAGE C: GENERIEKE COMPONENT BUSINESS MAP VAN IBM .................................................................... XXIII

X

LIJST VAN FIGUREN Figuur 2.1 Business capabilities taxonomie (Homann, 2006) .......................................................... 9 Figuur 2.2 Business Capabilities als UML model (Klinkmüller, Ludwig, Franczyk, Kluge, 2010) ......................................................................................................................................................................... 10 Figuur 2.3 Processen als implementatie van capabilities (1) (Malik, 2008) .......................... 15 Figuur 2.4 Processen en capabilities delen unieke activiteiten (Malik, 2008) ...................... 16 Figuur 2.5 Processen als implementatie van capabilities (2) (Rosen, 2010) ......................... 17 Figuur 2.6 Capabilities als bron voor competitief voordeel (Grant, 2009) .............................. 19 Figuur 2.7 Heat map op basis van twee attributen (Microsoft, 2006)....................................... 24 Figuur 3.1 Capability map georganiseerd volgens activiteiten van de value stream (Scott et al., 2010) ............................................................................................................................................................. 32 Figuur 3.2 Beschrijving capability (Scott et al., 2010)....................................................................... 33 Figuur 3.3 High level capability map volgens Microsoft (Tuna, 2009) ...................................... 39 Figuur 3.4 Capability map in detail (Doig, 2007) ................................................................................. 40 Figuur 3.5 Volledig uitgewerkte generieke capability map (Lloyd, 2006) .............................. 41 Figuur 3.6 Capability met attributen (Doig, 2007) .............................................................................. 42 Figuur 3.7 drie niveaus in interne specialisatie (Pohle et al., 2005) .......................................... 44 Figuur 3.8 drie niveaus in externe specialisatie (Pohle et al., 2005).......................................... 45 Figuur 3.9 Component Business Map (Pohle et al., 2005) ............................................................... 47 Figuur 3.10 Beschrijving van een Business Component (Pohle et al., 2005) ......................... 48 Figuur 3.11 Voorstelling van capabilities op een hemisfeer (Klinkmüller et al., 2010) .... 53 Figuur 3.12 Vier opties om attribuutwaarde weer te geven (Klinkmüller et al., 2010) ... 54 Figuur 3.13 VDML Metamodel (de Man, Berre, 2012) ...................................................................... 59 Figuur 3.14 voorbeeld capability taxonomie in VDML (de Man, Berre, 2012) ...................... 61 Figuur 3.15 Capabilities binnen het S&D departement (de Man, Berre, 2012) ..................... 62 Figuur 4.1 BMM voor AB InBev .................................................................................................................... 68 Figuur 5.1 Vragenlijst om attributen van capabilities te bepalen (Microsoft, 2006).......... 81 Figuur 5.2 Heat Map van AB InBev volgens Microsoft ...................................................................... 88 Figuur 5.3 Component Business Map van AB InBev .......................................................................... 92 Figuur 5.4 Ontvangen en Geleverde services van Beheer Transport .......................................... 97 Figuur 5.5 Heat Map voor IT Ondersteuning van AB InBev volgens IBM ................................ 99 Figuur 5.6 Lever Product gevisualiseerd volgens Klinkmüller et al. ........................................106 XI

Figuur 5.7 Capabilities in organisatorische eenheid Bierproductie..........................................111 Figuur 6.1 Link tussen capability, proces en service (Antunes en Borbinha, 2013) ........118 Figuur 6.2 Proces Brouw Bier .....................................................................................................................119

XII

LIJST VAN TABELLEN Tabel 3.1 Voorbeeld beschrijving capabilities ....................................................................................... 52 Tabel 5.1 Capabilities van AB InBev (3 niveaus) .................................................................................. 73 Tabel 5.2 Omschrijving van capabilities binnen foundation capability Lever Product ...... 75 Tabel 5.3 Service Levels van capabilities binnen foundation capability Lever Product .... 76 Tabel 5.4 Mensen, processen en technologieën binnen foundation capability Lever Product ..................................................................................................................................................................... 78 Tabel 5.5 Interacties tussen capabilities binnen foundation capability Lever Product ..... 79 Tabel 5.6 Eigenaars van capabilities binnen foundation capability Lever Product ............. 80 Tabel 5.7 Attributen van capabilities binnen foundation capability Lever Product ............ 84 Tabel 5.8 Evaluatie capabilitymodel Microsoft ..................................................................................... 90 Tabel 5.9 Beschrijving Componenten binnen Productie en Distributie ................................... 95 Tabel 5.10 Evaluatie capabilitymodel IBM............................................................................................101 Tabel 5.11 Attributen met numerieke waarden en geaggregeerde waarde .........................104 Tabel 5.12 Evaluatie capabilitymodel Klinkmüller et al. ................................................................108 Tabel 5.13 Evaluatie capabilitymodel VDML .......................................................................................114 Tabel 5.14 Evaluatie van de vier modellen op basis van de criteria ........................................114

XIII

LIJST VAN GEBRUIKTE AFKORTINGEN COO

Chief Operating Officer

ERP

Enterprise Resource Planning

KPI

Key Performance Indicator

MECE

Mutually Exclusive, Collectively Exhaustive

OMG

Object Management Group

SLA

Service Level Agreement

SLE

Service Level Expectation

UML

Unified Modeling Language

VDML

Value Delivery Modeling Language

XML

Extensible Markup Language

XIV

1 INLEIDING 1.1 PROBLEEMSTELLING In een economisch klimaat waarin de complexiteit steeds groter wordt, is het voor een onderneming belangrijk om het bedrijf zo beheersbaar mogelijk te houden. Bedrijfsleiders maken daarom gretig gebruik van modellen. Door middel van allerlei modelleertechnieken bekijken ze hun bedrijf vanuit een vereenvoudigd perspectief waardoor verschillende aspecten van het bedrijf geanalyseerd kunnen worden. Uiteraard vergt het enige tijd alvorens een model van een bedrijf vervolledigd is. En daar knelt nu net het schoentje. In een constant veranderende wereld kan een model al snel niet meer relevant zijn. Het lijkt dus duidelijk dat men op zoek moet naar een model dat stabiel blijft doorheen de tijd. Aldus kunnen de bedrijfsleiders snel inspelen op een veranderende markt. Een manier om een bedrijf stabiel te modelleren is door gebruik te maken van business capabilities. Een capability is de mogelijkheid van een entiteit om een bepaalde activiteit uit te voeren volgens bepaalde objectieven. Deze modellen bekijken een bedrijf als een netwerk van business capabilities die elk op zich op een of andere manier waarde creëren voor het bedrijf. De grote sterkte van een capabilities model is dat we de capabilities kunnen zien als een soort ‘black box’. We zijn niet geïnteresseerd in hoe we een bepaalde activiteit uitvoeren. We kijken enkel naar welke activiteit we uitvoeren en dus enkel naar wat we doen. Er is op dit moment echter nog niet veel geweten over hoe business capabilities gemodelleerd kunnen worden en hoe business capabilitymodellen in de praktijk gebruikt kunnen worden. Deze masterproef zal deze tweeledige vraag beantwoorden. Ten eerste wordt er onderzocht welke modellen en technieken er gebruikt worden om business capabilities te modelleren. Ten tweede zal aan de hand van een gevallenstudie bekeken worden hoe elk van de modellen in de praktijk gebruikt kunnen worden. De vraag is dus hoe we gebruik kunnen maken van een business capabilitymodel om beleidsbeslissingen te nemen. Met behulp van vooraf opgestelde criteria kunnen we elk model kritisch evalueren. Ten slotte zal er gekeken worden hoe we deze modellen

1

kunnen gebruiken in relatie met andere bedrijfsmodellen zodat duidelijk kan blijken hoe een capabilitymodel een meerwaarde biedt aan de beleidsmakers. Om deze vragen te kunnen beantwoorden is het vooreerst belangrijk dat we een goede kennis hebben van alle concepten die gebruikt zullen worden. Daarom zal deze masterproef beginnen met een duidelijke definiëring van het begrip business capabilities vanuit verschillende standpunten.

1.2 STRUCTUUR Deze masterproef bestaat uit twee grote delen. Een eerste deel is de literatuurstudie waarbinnen in een eerste hoofdstuk aandacht zal geschonken worden aan het definiëren en de omkadering van business capabilities en in een tweede hoofdstuk een overzicht gegeven zal worden over de bestaande modellen en technieken om business capabilities te modelleren. Aangezien de literatuur over business capabilities nagenoeg uitsluitend in het Engels is, zullen de meeste termen zo accuraat mogelijk vertaald worden. Uiteraard is het niet de bedoeling dat er dubbelzinnigheden ontstaan door een slechte vertaling. Daarom zullen sommige essentiële of moeilijk te vertalen termen (vb. capability, …) onvertaald blijven om twijfel geen kans te laten1. Het tweede deel omvat de gevallenstudie waarbij elk van de besproken modellen zal worden toegepast op een bedrijf. Met behulp van criteria opgesteld vanuit de literatuur kunnen we dan een kritische analyse maken van de modellen. In een eerste hoofdstuk binnen dit deel zal het bedrijf voor de gevallenstudie worden voorgesteld. Dat zal in eerste instantie gebeuren door het bedrijf tekstueel te beschrijven. Vervolgens zal een bedrijfsmodel worden gebruikt dat de doelen van het bedrijf weergeeft. Hiervoor zal het Business Motivation Model gebruikt worden uitgegeven door OMG. In het tweede hoofdstuk zal de eigenlijke gevallenstudie uitgewerkt worden waarbij de business capabilities van het voorbeeldbedrijf zullen gemodelleerd worden aan de hand van de verschillende gevonden modellen. Dat zal ons in staat stellen om een vergelijking te maken tussen elk model. Om een zo objectief mogelijke analyse te maken is het nodig 1

Deze onvertaalde termen staan cursief gedrukt.

2

om elk model te evalueren met behulp van criteria waaraan een goed capabilitymodel moet voldoen. Deze criteria zullen opgesteld worden vanuit de reeds bestaande literatuur. Vervolgens zal in een derde hoofdstuk onderzocht worden hoe de verschillende capabilitymodellen

kunnen

worden

gebruikt

in

combinatie

met

andere

bedrijfsmodellen. Ten slotte zal deze masterproef worden afgesloten met een algemeen besluit waarbij aanbevelingen worden gedaan voor de praktijk.

3

DEEL 1: LITERATUURSTUDIE 2 BUSINESS CAPABILITIES: WAT EN WAAROM? 2.1 WAT ZIJN CAPABILITIES? Alvorens we enige analyse kunnen maken over de bestaande modellen, is het belangrijk dat er een eenduidig beeld gevormd kan worden over wat een business capability precies is. We bekijken achtereenvolgens welke definities we vinden vanuit verschillende perspectieven, hoe business capabilities verschillen van processen en welke soorten business capabilities er zijn.

2.1.1 DEFINITIES Om de leesbaarheid van deze masterproef te verhogen zal in het vervolg capability gebruikt worden als synoniem voor business capability2. Om een eerste definitie te krijgen van wat een capability precies is, bekijken we de definitie die in de Cambridge Dictionary staat. Volgens dit woordenboek is een capability “the ability to do something”. Vrij letterlijk vertaald: de mogelijkheid om iets te doen. Hoewel deze definitie de essentie van wat een capability nu precies is weergeeft, blijft het bij al een vrij summiere definitie en helpt het ons niet echt verder om te begrijpen wat een capability is. Er bestaat een vrij grote consensus in de literatuur over volgende definitie voor een capability geleverd door Homann: “Een capability is een bepaald vermogen of capaciteit dat een bedrijf kan bezitten of verhandelen om een specifiek doel of uitkomst te bereiken. Een capability beschrijft wat een onderneming doet (zowel uitkomsten als service levels 3) om waarde te creëren voor de klanten. […] Een capability abstraheert en kapselt de mensen, processen en procedures, technologie en informatie in, in essentiële bouwstenen die nodig zijn om een analyse te ondersteunen voor zowel prestatieverbetering als herontwerp.” (Homann, 2006, p.5) In essentie is een business capability een capability toegepast op de zakenwereld. Een service level is een bepaald niveau van dienstverlening. Men kan service level agreements (SLAs) met andere bedrijven aangaan waar wordt overeengekomen welk niveau er moet worden behaald en wat de uitkomst van de dienst precies moet zijn. Binnen een bedrijf kunnen ook zulke overeenkomsten bestaan maar dan spreekt men eerder over service level expectations (SLE’s) of verwachtingen. Deze overeenkomsten zijn minder bindend dan de agreements. 2 3

4

Deze definitie kan best worden opgesplitst in kleinere stukken die beter te verstaan zijn. Het eerste deel zegt hetzelfde als wat in het woordenboek staat. Het is een vermogen of een capaciteit die wordt bezit door iets of iemand om bepaalde activiteiten naar behoren uit te voeren. Deze capaciteit kan vervolgens worden aangewend om iets te bereiken. Dat is ook wat bedrijven doen en zij wenden deze capabilities aan om waarde te creëren. In de definitie van Homann staat dat ze deze waarde creëren voor klanten maar mijns inziens kan de definitie worden uitgebreid tot waarde creëren voor hetzij klanten, hetzij aandeelhouders. Deze toevoeging vinden we ook terug bij Greski (2009). Elke capability wordt ook gekenmerkt door een uitkomst en een service level dat moet worden bereikt. Dus als we een capability beschrijven moeten we duidelijk maken wat er van verwacht wordt en welk service level er bereikt moet worden. Dat is nodig om te kunnen zien welke capabilities er goed presteren en welke minder. Het laatste deel toont ons dat capabilities worden beschreven als een ‘black box’. We weten welke mensen, processen en procedures, technologie en informatie de capability bezit maar hoe deze worden aangewend is van geen belang als we met capabilities werken. We beschouwen capabilities dus als de bouwstenen van ons bedrijf. Deze bouwstenen worden aangewend om de prestatie van het bedrijf te verbeteren of om een nieuw ontwerp van de structuur van de onderneming te maken.

2.1.2 HET CONCEPT CAPABILITY Nu we het woord capability gedefinieerd hebben kunnen we de karakteristieken van het concept capability verder onderzoeken. Een capability vervult volgende vijf karakteristieken (Freitag, Matthes, Nowobilska, Schulz, 2011), (Homann, 2006) : -

Stabiliteit

-

Horizontale structuur

-

Interactie

-

Verticale structuur

-

Abstractie van middelen

Elk van deze vijf karakteristieken zal vervolgens kort worden belicht.

5

2.1.2.1 Stabiliteit De capabilities van een bedrijf zijn stabiel. Om zaken te doen volgens een bepaald bedrijfsmodel heeft een bedrijf nood aan een aantal fundamentele capabilities. Deze capabilities wijzigen weinig of niet doorheen de tijd. Uiteraard kan het soms voorkomen dat er nieuwe capabilities worden toegevoegd of verdwijnen maar dat gebeurt zelden op het hoogste hiërarchisch niveau van de capabilities. Enkel wanneer er een radicale verandering wordt doorgevoerd op het hoogste niveau van het bedrijf (bijvoorbeeld van productiebedrijf naar distributiebedrijf) kan het gebeuren dat er wijzigingen gebeuren in de capabilities. Een mooi voorbeeld over de stabiliteit van capabilities vinden we bij Merrifield (2009). Het voorbeeld speelt zich af binnen de atletiekwereld, meer bepaald binnen het hoogspringen, maar kan zo worden gerelateerd met de bedrijfswereld. Het probleem dat de atleten voorgeschoteld krijgen, is dat ze over de lat moeten. We kunnen dus volgende capability beschouwen: Spring over de lat. Lang werd er gesprongen kijkend naar de lat volgens de zogenaamde schaarsprong. Atleten werden beter in deze sprong en het record ging geleidelijk aan omhoog maar het was maar tot een zekere Dick Fosbury het idee had om op een andere manier over de lat te springen dat men echt beduidend hoger kon springen. Hij sprong niet meer kijkend naar de lat maar met zijn rug naar de lat toe en hij gooide zichzelf als het ware over de lat met zijn hoofd eerst. Met deze vernieuwde techniek won Fosbury goud op de Olympische Spelen in 1968 in Mexico City. De manier waarop deze sprong word uitgevoerd (de ‘hoe’) onderging een drastische verandering maar de uitkomst (de capability of de ‘wat’) bleef hetzelfde. Met dat voorbeeld wordt meteen duidelijk gemaakt wat de sterkte is van een capability. Doordat we enkel naar de uitkomst kijken en niet naar de manier waarop iets wordt gedaan kunnen we een stabiel beeld krijgen van het bedrijf. Indien we een model kunnen maken waarbij we het bedrijf zien als een netwerk van stabiele bouwstenen dan hoeven we ons geen zorgen te maken over nieuwe organisatiemodellen of nieuwe technologieën die worden ontwikkeld. Het model van ons bedrijf zal niet wijzigen terwijl we wel die nieuwe technologieën kunnen toepassen in de uitvoering van de activiteit. 2.1.2.2 Horizontale structuur Capabilities zijn mooi afgelijnde bouwstenen van het bedrijf. We hebben op elk niveau dus een complete decompositie van het bedrijf zonder overlap tussen de verschillende 6

bouwstenen. Dat is het MECE-principe (Mutually Exclusive, Collectively Exhaustive). Alle bouwstenen samen vormen het volledige bedrijf maar we ondervinden geen ambigue situaties waarbij twee capabilities hetzelfde zouden zijn. 2.1.2.3 Interactie Verschillende capabilities kunnen met elkaar verbonden zijn en gaan in interactie met elkaar. We kunnen een bedrijf dus zien als een netwerk van capabilities waarbij de verschillende capabilities samenwerken en in interactie met elkaar gaan om de doelstellingen van het bedrijf te bereiken. Volgens Homann (2006) is dat een van de belangrijkste aspecten als we werken met capabilities. Het ontdekken van welke capabilities met welke andere in interactie gaan en op welke manier is misschien zelfs waardevoller dan het oplijsten van de capabilities. Om deze relaties te modelleren maakt Microsoft gebruik van capability connectors terwijl we bij IBM services zien die worden gedeeld en verbruikt. Welke benaming er ook wordt gebruikt. Het is belangrijk om te weten dat capabilities niet onafhankelijk zijn. Bij een reorganisatie zijn het immers vaak de interacties die worden gewijzigd terwijl de bouwstenen zelf onveranderd blijven. Een voorbeeld kan bijvoorbeeld zijn dat de capability Planning van Voorraad in interactie zal moeten treden met de capability Planning van Vraag. Om te bepalen wat de voorraad zal zijn zal er immers data nodig zijn die in de capability Planning van Vraag wordt gegenereerd. Om ervoor te zorgen dat duidelijk is wat van elke capability wordt verwacht moeten er service levels worden opgesteld. Op die manier kunnen we op een objectieve manier bepalen welke capabilities naar behoren presteren. 2.1.2.4 Verticale structuur Een zeer belangrijke karakteristiek van capabilities is de verticale structuur. Met verticale structuur wordt het hiërarchische karakter van capabilities bedoeld. We kunnen een taxonomie opstellen van capabilities elk op verschillende niveaus. Als basis vinden we drie niveaus (Homann, 2006). Het eerste niveau zijn de foundation capabilities. Dat zijn de basisbouwstenen van het bedrijf. Deze zullen vaak ook de functionele departementen zijn binnen een bedrijf en deze zijn voor elk bedrijf min of meer gelijk. Vaak gebruikte foundation capabilities zijn: Ontwikkel Product/Dienst, Creëer Vraag, Produceer of Lever Product/Dienst, Plan en Beheer Onderneming en ten slotte Beheer Samenwerking.

7

Het volgende niveau capabilities zijn wat we noemen de capability groepen. We kijken hoe we de foundation capabilities verder kunnen verfijnen in kleinere deelactiviteiten. Dit is een eerste belangrijk niveau want vanaf hier kunnen we bijvoorbeeld eigenaars van capabilities beginnen aanduiden. We kunnen op dit niveau ook de prestatievereisten (SLE’s) beschrijven en de gebruikers van de capability toewijzen. Het is dus het eerste niveau waarop analyse mogelijk is. Als voorbeeld kunnen we dieper duiken in de foundation capability Creëer Vraag. Deze capability kan worden verfijnd in drie meer gedetailleerde capabilities: Beheer Partner Relaties, Marketing, Verkoop. Elk van deze capability groepen kan nu worden toegewezen aan een bepaalde eigenaar. Bijvoorbeeld kunnen we de Vice-President van Verkoop als eigenaar toewijzen aan de capability Verkoop. Deze persoon (of departement) draagt dan de verantwoordelijkheid. Ten slotte hebben we het derde niveau waar we de effectieve business capabilities vinden. Dat zijn de uiteindelijke bouwstenen van ons bedrijf. Deze capabilities kunnen verder worden verfijnd tot specifiekere capabilities indien nodig. Op dit niveau zal de analyse met een heat map (infra p.22) het best tot zijn recht komen. Hier zullen we dus de attributen moeten meten en moeten we duidelijke service levels bepalen. Als voorbeeld gaan we dieper in op de hierboven vermelde capability groep Verkoop. Business capabilities die Verkoop verder verfijnen zijn bijvoorbeeld Beheer Order, Beheer Verkoop, Product/Prijs Configuratie en Validatie, Beheer Contract, Kwalificeer Prospecten. Als we de capability Beheer Order bekijken kunnen we bijvoorbeeld als service level stellen dat 80% van de orders binnen de maand moeten leiden tot een verkoop. Verder kunnen we als attributen strategische waarde, performance, IT ondersteuning, verbondenheid met andere capabilities,… bekijken. Indien we deze hiërarchische structuur willen voorstellen kunnen en zullen we vooral gebruik maken van capability maps. Deze worden gebruikt om capabilities op een visuele manier voor te stellen. Freitag et al. definiëren een capability map als “de visuele voorstelling van de voornaamste functies in het bedrijf die nodig zijn om het business model van het bedrijf te ondersteunen en die de strategische richting van het bedrijf reflecteren. Meestal wordt een business capability map voorgesteld als een set van capabilities die geleidelijk aan gedetailleerder worden en aldus een hiërarchie vormen” (Freitag et al., 2011, p.5). Voor de meeste vormen van analyse zullen drie niveaus volstaan voor een capability map (Scott, Cullen, An, 2010). 8

Rond niveau drie beginnen de capabilities ook goed gealigneerd te geraken met high level processen. (infra p.15) Figuur 2.1 geeft een overzicht van de verschillende niveaus.

Figuur 2.1 Business capabilities taxonomie (Homann, 2006)

2.1.2.5 Abstractie van middelen Een laatste karakteristiek van capabilities is dat deze zich abstraheren van de middelen die nodig zijn om de activiteit uit te voeren. Voorbeelden van middelen zijn mensen, processen en technologieën. De middelen worden wel ingekapseld in de capability. 2.1.2.6 UML weergave van een capability Figuur 2.2 geeft een UML weergave van het concept capability waarbij we opnieuw alle elementen zien uit de definitie van Homann en de besproken karakteristieken: a. Een organisatie bezit capabilities. Het bedrijf zal dus een aantal capabilities bezitten die worden aangewend om waarde te creëren. b. Een capability kan worden onderverdeeld in andere capabilities. Capabilities zullen dus hiërarchisch kunnen worden voorgesteld waarbij we met verschillende niveaus werken. Dat is de verticale structuur. c. Een capability abstraheert zichzelf van middelen (fysieke activa), processen en mensen. Ze zijn element van de capability maar de combinatie van deze elementen kennen we niet. 9

d. We kunnen een capability karakteriseren met verschillende attributen. Deze attributen zijn elementen die gekwantificeerd kunnen worden. Als we voor elke capability een zelfde attribuut kwantificeren kunnen we capabilities vergelijken met elkaar. Voorbeelden van attributen zijn performance, waardecreatie, IT ondersteuning, … e. Een capability wordt door een klant geconsumeerd en wordt geleverd door een leverancier. De klanten kunnen departementen of personen zijn, zowel binnen het bedrijf als buiten het bedrijf. f. Business capabilities staan niet alleen binnen een bedrijf. Ze werken op elkaar in en gaan in interactie met elkaar. We herkennen de horizontale structuur

Figuur 2.2 Business Capabilities als UML model (Klinkmüller, Ludwig, Franczyk, Kluge, 2010)

2.1.3 CAPABILITIES VS. PROCESSEN De term capability binnen het domein van bedrijfsmodellering is nog vrij nieuw. Getuige daarvan is het gebrek van een gestandaardiseerde definitie van een capability. Vele mensen weten nog niet precies waarom capabilities nu precies nodig zijn en waarin ze verschillen van reeds bestaande concepten. De grootste verwarring ontstaat wanneer men capabilities met processen probeert te vergelijken. Verder is het ook niet duidelijk waarin een capabilitymodel verschilt van een procesmodel. Voor we verder gaan, bekijken we eerst wat we precies moeten verstaan onder een capabilitymodel. Homann definieert een capabilitymodel als “een geneste hiërarchie van business capabilities. Het onthult alle business capabilities binnen het relevante ecosysteem.” (Homann, 2006, p.8) In deze definitie is de term ecosysteem belangrijk. We modelleren 10

niet enkel binnen de fysieke grenzen van een bedrijf maar we modelleren de capabilities van een business. Meerdere bedrijven kunnen samen één business hebben. Met procesmodellen is dat moeilijker aangezien we daar vooral binnen een bedrijf modelleren. Scott, Cullen, An vinden een capabilitymodel “een model dat een business beschrijft in termen van de capabilities en relatie die nodig zijn om de missie van de organisatie te ondersteunen.” (Scott, Cullen, An, 2009) Belangrijk hier is de link die we vinden tussen enerzijds de capabilities en anderzijds de missie van de organisatie. 2.1.3.1 Kritiek op capabilities In de wereld van business architecten (BA) en enterprise architecten (EA) is er veel onenigheid over het gebruik van capabilities. De meest gehoorde kritiek op capabilities is dat het eigenlijk veredelde processen zijn. Procesmodellering is al vele jaren standaard in vele bedrijven en men vraagt zich af waarom men nu ook capabilitymodellen moet maken en hoe deze relateren met procesmodellen. Enkele voorbeelden maken duidelijk dat er nog geen consensus is dat capabilities modelleren wel degelijk verschilt van processen modelleren. “Het is al moeilijk genoeg om binnen een organisatie een business proces architectuur op te stellen dat gebruikt kan worden om effectief het management en het meten van de efficiëntie van het bereiken van de organisatorische doelen te organiseren. Het idee om eerst nog een map of hiërarchie van capabilities te maken en dat dan te gebruiken om een hiërarchie van processen te maken is gedoemd om verwarring te zaaien bij een reeds nu al zeer moeilijke taak.” (Harmon, 2011, p.7) De auteur van dat citaat vindt het niet nodig om capabilities te modelleren. Volgens hem zorgt het alleen maar voor verwarring en is het tijdverlies. “Wanneer ik voorbeelden zag van capability maps van klanten werd ik bezorgd. Ik herinner me dat ik op een gegeven moment dacht ‘dit lijkt op een proces architectuur ontwikkeld door iemand die niet erg goed is in proces architecturen.’ De capabilities waren vlees noch vis.” (Sharp, 2011, p.1) Sharp vindt dat de capabilities geen meerwaarde brengen ten opzichte van processen.

11

2.1.3.2 Definitie van proces Laten we nu eens onderzoeken hoe capabilities en processen van elkaar verschillen. We beginnen met de definitie van een proces. Davenport (1993, p.7) definieert een proces als volgt: “Een proces is een gestructureerde, gemeten reeks van activiteiten ontwikkeld om een bepaalde uitkomst te produceren voor een specifieke klant of markt. Er wordt een sterke nadruk gelegd op hoe het werk wordt gedaan binnen een organisatie. Aldus is een proces een specifieke rangschikking van activiteiten doorheen tijd en ruimte, met een duidelijk begin en einde en duidelijk gedefinieerde in- en outputs. Het is dus een structuur voor actie. Indien men een proces perspectief gebruikt moet men vanuit het oogpunt van de klant kijken. Processen zijn de structuur waarmee een organisatie doet wat het moet doen om waarde te produceren voor zijn klanten.” Een proces wordt duidelijk afgelijnd door een begin en een einde, waartussen alle nodige activiteiten vallen. We weten precies hoe we elke stap moeten uitvoeren om waarde te creëren. 2.1.3.3 Verschil in karakteristieken Capabilities en processen lijken inderdaad gemeenschappelijke kenmerken te hebben en de verwarring die momenteel heerst over deze twee concepten is verstaanbaar. Desalniettemin kunnen we duidelijk een onderscheid maken tussen capabilities en processen tussen de verschillende karakteristieken: a. Stabiliteit: een proces is een reeks van activiteiten doorheen tijd en ruimte. Met deze reeks van activiteiten willen we output creëren die meer waarde heeft dan de input. We hebben ook een bepaalde uitkomst voor ogen, maar de focus van processen is om in kaart te brengen hoe dat wordt gedaan. En dat kan doorheen de tijd drastisch veranderen. Dat is waar capabilities een meerwaarde kunnen bieden ten opzichte van processen. Bij capabilities wordt er wel degelijk gefocust op die stabiliteit. Als voorbeeld kunnen we een high level capability vergelijken met hetzelfde high level proces. Als we Ontwikkel Nieuw Product als capability bekijken dan zijn we niet geïnteresseerd in de stappen en de interacties tussen personen die nodig zijn om een product te ontwikkelen. Daarvoor gebruiken we procesmodellen. We zijn wel geïnteresseerd in wat er als eindresultaat wordt 12

verwacht, welke middelen daarvoor nodig zijn, wie de verantwoordelijkheid heeft,… Het proces kan dermate veranderen. Zo kan er bijvoorbeeld tegenwoordig veel meer met de computer worden gedaan en kan er veel sneller een 3D prototype worden gemaakt en feedback worden gevraagd aan de toekomstige eindgebruiker. Het proces zal dus wel worden gewijzigd maar de capability blijft onveranderd want het eindresultaat is en blijft gewoon een nieuwe product. b. Horizontale structuur: processen worden gedefinieerd door een duidelijk begin en einde. Dat wil zeggen dat de output van een proces de input kan zijn van een ander proces. Er is dus een grote mate van afhankelijkheid tussen processen onderling. Als één proces niet de nodige input levert voor een ander proces dan stopt dat tweede proces. Dat in tegenstelling tot capabilities die in interactie met elkaar treden maar die wel onafhankelijk van elkaar kunnen opereren. Als een bepaalde interactie niet plaats vindt door een bepaalde reden dan kan deze capability wel nog steeds worden vervuld. c. Verticale structuur: een procesmodel kan ook hiërarchisch worden opgemaakt waarbij een proces verfijnd wordt in een proces van een lager niveau. Hier zien we gelijkenissen tussen procesmodellen en capabilitymodellen. Het is ook hier dat er veel verwarring ontstaat. Mensen ontwikkelen procesmodellen en zeggen dat ze processen modelleren maar eigenlijk modelleren ze capabilities. Volgend citaat bewijst dat punt duidelijk: “Ongeveer iedereen werkzaam in de procesarchitectuurwereld geeft toe dat een goede procesarchitectuur, of het resultaat van een goede procesidentificatie, start met een aantal lagen die enkel en alleen focussen op ‘wat’ er wordt gedaan. […] Er is geen indicatie van welke delen van de organisatie betrokken zijn, hoe het proces wordt geïmplementeerd en of het proces goed presteert. Het doel is enkel en alleen duidelijk te maken ‘wat we doen’ of ‘wat we zouden moeten doen’. Dat lijkt vrijwel niet te onderscheiden van capability volgens mij.” (Sharp, 2011, p.3). Uiteraard lijkt dat vrijwel niet te onderscheiden want die eerste lagen zijn effectief een capabilitymodel. d. Abstractie van middelen: Volgens mij ligt hier het grootste verschil tussen capabilities en processen aangezien we om een proces te definiëren duidelijk moeten zeggen welke stappen doorlopen moeten worden. We moeten duidelijk maken welke middelen er nodig zijn om tot het eindresultaat te komen. Indien 13

we capabilities modelleren hechten we geen belang aan de middelen en de manier waarop ze samenwerken. We abstraheren de capability van de middelen die erin ingekapseld zitten. Volgend voorbeeld toont aan dat capabilities en processen duidelijk twee verschillende concepten zijn en van elkaar verschillen. In de luchtvaartindustrie werden passagiers vroeger ingecheckt door personeelsleden van de luchthaven. Het proces om in te checken bestond uit een reeks activiteiten die de personeelsleden moesten uitvoeren. De uitkomst was dat de passagier was ingecheckt. De capability is dus Check in Passagier. De manier waarop deze uitkomst werd verwezenlijkt werd door een proces beschreven. De focus van het proces was dus op hoe het gedaan werd. Na de opkomst van computers, smartphones, … bedachten luchtvaartmaatschappijen een volledig nieuwe manier van inchecken. De passagier kan zich thuis inchecken en hoeft zijn ticket zelfs niet meer af te printen maar op te slaan op zijn smartphone. Op het eerste zicht lijkt dit niets te maken te hebben met de eerste manier van in te checken. Maar als we ons abstraheren van de manier waarop de passagier zich incheckt en de stappen die hij volgt, dan zien we dat er uiteindelijk net hetzelfde wordt gedaan. De uitkomst is volledig hetzelfde, namelijk Check in passagier. Het proces om dat te bereiken is volledig veranderd en vereist nieuwe procesmodellen en implementatie, maar de essentie blijft hetzelfde. (Merrifield, Calhoun, Stevens, 2008) 2.1.3.4 Capabilities en processen in synergie Er is een duidelijk verschil tussen capabilities en processen maar de vraag is dan of we ze naast elkaar kunnen gebruiken. Verder moeten we kijken hoe we ze naast elkaar kunnen gebruiken. Ook hier is er weer geen consensus over het simultaan gebruik van capabilities en processen. Sommige business architecten vinden capabilities modelleren geen meerwaarde omdat ze geen verschil zien tussen de processen en capabilities. Anderen zien wel degelijk een verschil maar vinden het niet de moeite waard om nog een nieuw model te gaan ontwikkelen. De toegevoegde waarde van capabilities modelleren voor hen is dus beperkt. Als we kijken naar diegenen die er wel een meerwaarde in zien dan hebben we enkele verschillende visies. 14

Een eerste mogelijke manier om beide concepten te combineren is door processen te zien als de implementatie van capabilities. Capabilities van het derde niveau kunnen ongeveer meteen gelinkt worden aan processen. We limiteren dus het aantal capability niveaus en we stappen op een bepaald niveau over op procesmodellen. Deze processen gebruiken activiteiten die op hun beurt worden ondersteund door services. Figuur 2.3 verduidelijkt dit.

Figuur 2.3 Processen als implementatie van capabilities (1) (Malik, 2008)

Een tweede optie die we kunnen veronderstellen is door het capability model en het procesmodel te laten overlappen in het laagste niveau van hun modellen, namelijk bij de activiteiten. In dat opzicht beschouwen we de activiteiten als de unieke elementen binnen het bedrijf. We kunnen nu onze capabilities veel verder opsplitsen in kleinere elementen tot we uitkomen op de activiteiten. Bij het procesmodel gebeurt net hetzelfde tot we uitkomen bij de activiteiten. Hier hebben we een overlap tussen de twee modellen. De activiteiten worden vervolgens ook weer ondersteund door services. Figuur 2.4 geeft een visuele representatie van deze visie.

15

Figuur 2.4 Processen en capabilities delen unieke activiteiten (Malik, 2008)

De eerste optie is de meest voor de hand liggende optie. Capabilities zijn een nog grotere abstractie dan processen. Het is als het ware een film bovenop de procesarchitectuur. Vele procesarchitecten beschouwen deze visie als een volledig procesmodel en zien dus het nut niet in van capabilities (supra p.13). Hun procesmodellen beginnen ook met enkele niveaus met wat ze doen en pas dan gaan ze effectief over in processen. Dat is wat we ook zien in de raamwerken SCOR en eTom. Dat zijn raamwerken waar domeinof sectorspecifiek (respectievelijk supply chain en telecommunicatie) wordt gekeken welke activiteiten er nodig zijn om aan de vraag van de klanten te voldoen. Ze modelleren zogezegd enkel processen maar de eerste niveaus van deze modellen lijken heel sterk op capabilities. Als we de eerste optie volgen van Malik dan bekomen we volgende denkwijze. De capabilities die worden gemodelleerd, worden gelinkt met elementen van de value stream. Deze elementen hebben nood aan capabilities om te verwezenlijken wat ze moeten verwezenlijken. Deze capabilities worden dan hiërarchisch opgesplitst in beter behandelbare capabilities. Op een bepaald niveau kunnen deze dan mooi worden 16

gemapt op processen. Die worden dan op hun beurt weer gelinkt met de services. ( Figuur 2.5)

Figuur 2.5 Processen als implementatie van capabilities (2) (Rosen, 2010)

2.2 WAAROM MODELLEREN WE BUSINESS CAPABILITIES? We hebben nu een goed idee over wat een capability precies is maar de vraag blijft nu nog waarom dit concept belangrijker aan het worden is binnen het domein van bedrijfsmodellering. Zoals hierboven reeds werd duidelijk gemaakt, is er nog steeds twijfel over de meerwaarde van capabilities en waarom we ze zouden moeten modelleren. Er zijn drie grote redenen waarom capabilities modelleren een meerwaarde kan leveren aan een bedrijf. Ten eerste stelt het in staat om een stabiel beeld te krijgen van de onderneming (Scott, 2009). Voor een bedrijf is het ook belangrijk om te weten welke capabilities het heeft, aangezien deze de bron zijn om kerncompetenties op te bouwen (Grant, 2009)(Hafeez, Malak, Zhang, 2007). Ten slotte is het een hulpmiddel voor business/IT alignment (Ulrich, Rosen, 2011).

17

2.2.1 STABIEL BEELD VAN DE ONDERNEMING Indien een bedrijf de moeite doet om zijn capabilities te modelleren dan heeft dat bedrijf een overzicht van wat het doet. Dat overzicht blijft gedurende vele jaren min of meer ongewijzigd aangezien capabilities zelf stabiele elementen zijn. Nieuwe technologieën, nieuwe leveranciers, veranderende marktomstandigheden, … zorgen er niet meer voor dat het model al snel niet meer relevant is (zoals wel het geval kan zijn bij procesmodellen). De vraag blijft nu waarom men een stabiel beeld wil hebben van zijn onderneming. Het is duidelijk dat een model maken geen werk van korte adem is. Er worden veel manuren in gestoken en vaak wordt er een externe consultant aangenomen om deze modellen te maken. Er hangt dus een zeker prijskaartje aan bedrijfsmodellen. Het is logisch dat bedrijven niet elk jaar een nieuw model laten maken maar vaak blijft men dan achter met een model dat niet meer up to date is. We moeten dus proberen een model te vinden dat relevant blijft. Uiteraard kunnen en moeten andere modellen ook worden gebruikt maar het loont zeker de moeite om een mooi stabiel overzicht te krijgen van het bedrijf.

2.2.2 CAPABILITIES ALS BRON VAN KERNCOMPETENTIES In het vakgebied van strategisch management zijn er ontzettend veel naslagwerken en handleidingen. In elk van deze handleidingen vinden we min of meer hetzelfde verhaal terug. Een bedrijf is succesvol en maakt bovengemiddelde winsten indien er twee condities zijn voldaan: een attractieve industrie en een competitief voordeel, waarbij het competitief voordeel het belangrijkste is. Een competitief voordeel kunnen we opbouwen met behulp van de middelen en capabilities aanwezig binnen een bedrijf. Met behulp van capabilities die uitermate goed presteren kan een bedrijf competenties opbouwen. Een succesvol bedrijf eindigt dan met enkele kerncompetenties waarop zijn strategie gebaseerd is (Grant, 2009). Volgens Prahalad en Hamel (1990) zijn kerncompetenties de elementen die centraal staan binnen de strategie en die zorgen voor de winstgevendheid. Een competentie moet aan drie voorwaarden voldoen om een kerncompetentie te zijn: -

De competentie moet toegang geven tot een brede waaier aan markten

-

De competentie moet een significante bijdrage leveren aan de waarde voor de klant 18

-

De competentie moet moeilijk na te bootsen zijn

Het is dus belangrijk om te weten wat de kerncompetenties zijn aangezien deze als bron van de strategie moeten dienen. Daarvoor hebben we nood aan een lijst van capabilities waarmee we dan kunnen verder werken. Om te bepalen welke capabilities (of combinatie van capabilities) kunnen of zullen leiden tot kerncompetenties vinden we bij Grant een aantal voorwaarden. Verder moeten we ook zeker kijken naar de middelen die nodig zijn om de capability te implementeren aangezien het deze middelen zijn die vereist zijn om een bepaalde capability te benutten. Zonder deze middelen is er geen bruikbare capability. Figuur 2.6 geeft een overzicht van de voorwaarden.

Figuur 2.6 Capabilities als bron voor competitief voordeel (Grant, 2009)

2.2.2.1 Competitief voordeel ontwikkelen Ten eerste moet de capability in staat zijn om een competitief voordeel op te bouwen. Hiervoor moet er aan twee voorwaarden worden voldaan. Ten eerste moeten de middelen die de capability implementeren schaars zijn. Verder moet de manier waarop deze middelen worden gecombineerd om het resultaat te behalen niet triviaal zijn. We kunnen pas beter zijn dan onze concurrenten indien wij iets hebben dat zij niet hebben en kunnen doen. Met schaarste wordt niet alleen het niet bezitten van middelen bedoeld 19

maar ook het slecht presteren van een capability. Zo zullen vele bedrijven een capability Verzend Product hebben maar Fedex of DHL zal hierin veel beter presteren dan de lokale pakjesbezorger in het dorp. De moeilijkheden die er zijn om goed te presteren in deze capability zorgen ervoor dat Fedex of DHL een competitief voordeel kunnen ontwikkelen. Indien er geen schaarste is kan het wel nodig zijn om een bepaalde capability te hebben enkel en alleen om mee te kunnen doen in de markt. Ten tweede moet de capability relevant zijn ten opzichte van de key success factors in de markt. DHL kan bijvoorbeeld uitermate goed presteren in een capability Ontwikkel Nieuwe Producten/Diensten. Dat is uiteraard een zeer belangrijke capability maar in de markt van distributie is deze capability minder relevant. Indien DHL deze capability toch wil gebruiken als een competitief voordeel zal het misschien een andere markt moeten opzoeken. 2.2.2.2 Competitief voordeel behouden Om het competitief voordeel te behouden moet er aan drie voorwaarden worden voldaan. Ten eerste moeten de middelen of de capability duurzaam zijn zodat we lange tijd beter zijn dan concurrenten. Ten tweede moeten deze moeilijk na te bootsen zijn. Zo kunnen concurrenten ons niet zomaar afkijken. Ten slotte moet het moeilijk zijn om de middelen of capabilities te kopen of over te nemen. Voor capabilities is dat sowieso al zeer moeilijk dus aan deze voorwaarde is min of meer altijd voldaan. 2.2.2.3 Toe-eigenen van voordeel Als laatste punt is het belangrijk dat men zich ook effectief de voordelen van het competitief voordeel kan toe-eigenen. Het zou zonde zijn om iemand anders met de winst te laten lopen.

2.2.3 HULPMIDDEL VOOR BUSINESS/IT ALIGNMENT De derde reden om capabilities te modelleren is waarschijnlijk ook de meest belangrijke en nuttige reden. IT begint meer en meer een drijvende kracht te worden binnen de bedrijven. Men ziet IT niet alleen meer als een ondersteunende functie maar men geraakt er van overtuigd dat IT ook waarde moet creëren binnen het bedrijf. Dat verklaart ook de groeiende interesse in modellen zoals het Strategic Alignment Model 20

van Venkatraman en Henderson (1999) waarin er vier verschillende paden worden uitgelegd waarmee business en IT met elkaar gelinkt kunnen worden. Business/IT alignment is een complex probleem zoals we kunnen lezen in volgende beschrijving door Ulrich over wat alignment precies is: “De staat waarin business strategieën, capabilities, semantiek, processen, regels en governance structuren in harmonie met elkaar interageren met geautomatiseerde systemen en data” (Rosen, 2010, p.2). Deze beschrijving geeft duidelijk weer dat business/IT alignment een complex probleem is. Om de complexe werkelijkheid te begrijpen maken we vaak gebruik van modellen. Om de complexiteit van business/IT alignment beter te begrijpen kunnen we een capability map gebruiken. Business capabilities kunnen immers duidelijk de link leggen tussen business architecturen en IT architecturen. Ze vereenvoudigen het probleem niet maar door ze te modelleren krijgen we nieuwe inzichten die kunnen helpen om alignment te verkrijgen. We vinden de capabilities tussen business en IT als volgt. Langs de business zijde kunnen we capabilities linken met de strategie, de goals, de objectieven die ze ondersteunen en aan de IT zijde linken we de capabilities aan de processen en IT middelen (oa. applicaties en systemen) die de capabilities implementeren. (Rosen, 2010) Ten slotte zorgen capabilities er ook voor dat businessgerelateerde mensen en ITgerelateerde mensen een gemeenschappelijke taal hebben om met elkaar te praten (Ulrich en Rosen, 2011). Volgens Rik Maes (2007) is het gebrek aan goede communicatie tussen business en IT een van de grootste redenen dat de alignment tussen beiden niet goed loopt. Als men aan de hand van capabilities praat dan zal zowel business als IT weten waarover het gaat en is het probleem van slechte communicatie voor een deel opgelost.

2.3 TOEPASSINGEN VAN CAPABILITIES MODELLEN Het is nu wel duidelijk dat er wel degelijk nood is om capabilities te kunnen modelleren. Nu kunnen we kijken welke toepassingen er nu effectief zijn voor deze modellen in de praktijk. Men kan immers wel zeggen dat men een stabiel beeld heeft van zijn bedrijf, of dat men capabilities gebruikt voor business en IT te aligneren, maar er moeten uiteraard ook duidelijke toepassingen zijn alvorens men de moeite zal doen om de capabilities te

21

modelleren. Volgende toepassingen zorgen ervoor dat een bedrijf waarde kan creëren door gebruik te maken van het capability concept (Keller, 2009)(Scott, 2009): -

De focus bepalen voor investeringsbeslissingen

-

Gap analyse voor business/IT alignment

-

Ondersteunen van beslissingen omtrent het outsourcen van niet-kernfuncties

-

De te volgen route bepalen voor strategische uitvoering

Elk van de toepassingen steunt op het gebruik van een techniek genaamd Heat Mapping (Keller, 2009) (Doig, 2007). Alvorens we elke toepassing toelichten bekijken we eerst wat heat mapping is en hoe dat ons kan helpen.

2.3.1 HEAT MAPPING Een heat map is een map waarin bepaalde items (vb. capabilities, applicaties, systemen, …) staan geordend. Aan de hand van attributen voor elk van deze items kunnen we een kleurencode toekennen die ons in staat stelt om te bepalen welke items (in ons geval capabilities) meer aandacht nodig hebben dan anderen. We krijgen dus een map waarin de verschillende capabilities als blokken worden voorgesteld. Elk blok heeft vervolgens een kleur gekregen waarbij we snel en eenvoudig een analyse kunnen maken. We kunnen een heat map als het ware beschouwen als een foto in infrarood van een huis. Met deze foto kunnen we dan zien welke plaatsen slecht geïsoleerd zijn en waar we moeten investeren. Als we een heat map van ons bedrijf hebben gebaseerd op capabilities kunnen we zien welke capabilities slecht presteren en dus investeringen nodig hebben (Keller, 2009). Er zijn verschillende manieren om deze kleurencodes toe te kennen. Aangezien we voor elke capability verschillende attributen kunnen bepalen kunnen we ook verschillende heat maps opstellen. Zo kunnen we bijvoorbeeld een heat map opstellen waarbij de kleur wordt bepaald door de mate waarin de capability strategische waarde heeft. Maar vaak willen we weten hoe een capability presteert op basis van een aantal attributen. Dan zijn er twee mogelijkheden. Ten eerste kunnen we de kleur aanpassen waarbij we de verschillende relevante attributen met een gewogen gemiddelde samennemen. Aldus kunnen we belangrijkere attributen meer gewicht geven en krijgen we toch een algemeen beeld van de prestatie van de capabilities (Keller, 2009). Een tweede 22

mogelijkheid is om naast het blok ook de rand van het blok een kleur te geven. Op die manier kunnen we twee attributen met elkaar vergelijken. Dat is een techniek die we terugvinden bij Microsoft (infra p.85) (Microsoft, 2006). Figuur 2.7

geeft een mooi voorbeeld waarbij we heel snel kunnen zien welke capabilities

aandacht vereisen en waar een meer diepgaande analyse nodig is. Bijvoorbeeld de capabilities Provide Partner Pricing Information scoort ‘slecht’ op de twee gebruikte attributen (vb. Veel strategische waarde en slechte performance) waardoor dit een capability is waar we dieper op moeten ingaan. De capability Create Territory Plan scoort bijzonder goed op beide aspecten en zal dus weinig aandacht vereisen. Dat wil evenwel niet zeggen dat er geen projecten moeten worden opgestart om deze capabilities te verbeteren. Wel is het zo dat deze projecten vooral gebaseerd zullen zijn op kostenreductie.

23

Figuur 2.7 Heat map op basis van twee attributen (Microsoft, 2006)

Nu we weten hoe we capabilities kunnen analyseren kijken we welke toepassingen we vinden en wat we dus precies met deze heat maps kunnen doen.

2.3.2 INVESTERINGSBESLISSINGEN Een eerste toepassing van een capabilitymodel is om deze te gebruiken bij grote investeringsbeslissingen. Vaak zijn er verschillende projecten voorhanden waarin kan worden geïnvesteerd. Een beperkt budget kan ervoor zorgen dat er moet gekozen worden welke projecten het interessantst zijn om in te investeren. Uiteraard bestaan er traditionele technieken zoals de netto huidige waarde, de terugverdienperiode of het interne rendement. Dat zijn methodes die goed werken maar die tekort kunnen schieten voor grotere projecten. Voor elk van deze methodes moeten we immers de toekomstige kasstromen bepalen. Aldus kan ter toevoeging aan deze klassieke technieken een capabilitymodel worden gebruikt. 24

Indien men immers een model heeft van de capabilities, dan kan men voor elke capability bepalen welke strategische waarde deze heeft voor de onderneming. Verder kan ook worden bepaald wat de huidige performance is, hoe IT deze capability ondersteunt, … Er zijn vele verschillende attributen mogelijk die kunnen worden gemeten voor verschillende situaties. Indien nu zou blijken dat een bepaalde capability zeer veel strategische waarde heeft maar slecht presteert, dan kan er worden beslist dat een investering in die welbepaalde capability gerechtvaardigd is. Ook kan een capability die veel waarde heeft slecht ondersteund worden door IT. Er moet dan worden geïnvesteerd om die IT ondersteuning te optimaliseren. Het kan echter ook gaan over een desinvestering. Een capability die weinig strategische waarde heeft maar waar heel veel wordt in geïnvesteerd kan een heuse “cash drain” zijn. Het is dus belangrijk dat dit op tijd wordt ontdekt.

2.3.3 GAP-ANALYSE VOOR BUSINESS/IT ALIGNMENT Aansluitend op de investeringsbeslissingen kan een capability model worden gebruikt om de business/IT alignment te verhogen. Door voor de verschillende capabilities de strategische waarde en IT ondersteuning te bepalen kan men ontdekken waar er sterk kan worden gewerkt aan de business/IT alignment. Dat kan ook op de andere manier gebeuren waarbij men capabilities ontdekt die zeer goede IT ondersteuning krijgen maar waaraan men op dit moment weinig strategische waarde geeft. Men kan dan een nieuwe strategische richting uitvaren waarbij die bepaalde capability een verhoogde strategische waarde krijgt.

2.3.4 OUTSOURCEN Een derde toepassing van een capabilities map is als hulpmiddel voor het nemen van outsourcingbeslissingen. Reeds in 1999 beschreef Quinn dat bedrijven waarde kunnen creëren door bepaalde activiteiten te outsourcen. Hij legt de nadruk dat het grootste voordeel van outsourcen niet wordt behaald door een korte termijn kostenreductie outsourcingstrategie te volgen maar door een lange termijn strategisch gebaseerde strategie te volgen. De capabilities die geoutsourcet moeten worden volgens Quinn zijn deze die geen kerncompetenties zijn en die niet essentieel zijn voor de klanten. Opnieuw 25

kunnen we aan de hand van de capability map bepalen welke capabilities strategische waarde leveren en welke capabilities als kerncompetenties kunnen worden beschouwd. De capabilities die buiten deze categorieën vallen kunnen worden beschouwd als mogelijke doelen voor outsourcing. Uiteraard dient er dan een meer uitgebreide analyse te worden gemaakt welke capabilities effectief geoutsourcet zullen worden.

2.3.5 STRATEGISCHE UITVOERING Als laatste voorbeeld van een toepassing bekijken we de strategisch uitvoering. Men kan een as-is capability map opstellen en een to-be capability map. De capability map is dan een hulpmiddel bij de uitvoering van de strategie. Zoals we later zullen zien hebben zowel Microsoft als IBM een methode ontwikkeld om capabilities te modelleren. Deze initiatieven waren echter een deel van een groter project. Microsoft had de bedoeling om business/IT alignment te vergemakkelijken door ondernemingen te helpen service georiënteerd te worden. IBM bekeek het van een iets strategischer oogpunt en probeert bedrijven te helpen om zich zowel intern als extern te specialiseren. (infra p.43)

2.4 CONCLUSIE Het concept capability is nu duidelijk gedefinieerd. Naast de definitie hebben we ook vijf specifieke karakteristieken van capabilities bepaald. Deze karakteristieken zijn eigen aan elke capability. Verder hebben we duidelijk gemaakt waarin processen van capabilities verschillen en hoe beide concepten in combinatie met elkaar kunnen gebruikt worden. Ten slotte werd een overzicht gegeven waarom we capabilities moeten modelleren en welke toepassingen er zijn. Het is immers belangrijk om de echte relevantie met de praktijk vast te stellen. In het volgende hoofdstuk nemen we de vergaarde kennis mee en kijken we welke modellen en technieken er zijn om capabilities te modelleren.

26

3

MODELLEN

EN

TECHNIEKEN

OM

CAPABILITIES

TE

MODELLEREN 3.1

INLEIDING

In het vorige hoofdstuk hebben we kennisgemaakt met het begrip capability en zijn we ook dieper ingegaan op de verschillende karakteristieken. Ook hebben we een onderscheid gemaakt tussen capabilities en processen. Ten slotte hebben we enkele redenen gegeven om capabilities te modelleren en enkele toepassingen die capabilitymodellen hebben. In dit hoofdstuk bouwen we verder door te kijken op welke verschillende manieren we capabilities kunnen modelleren. We beginnen het hoofdstuk met een algemeen model waarbij er nog veel vrijheidsgraden zijn. Hierop zullen we de structuur baseren waarmee we de andere modellen zullen beschrijven. Uiteraard zullen we voor elk model een stap terug moeten zetten en kijken hoe zij capabilities definiëren. Dat is noodzakelijk, want er heerst min of meer een consensus over de definitie van Homann maar deze is niet absoluut. Eens we deze herdefiniëring hebben, kunnen we verder met het beschrijven van het model. Achtereenvolgens zullen we volgende modellen bekijken: -

Microsoft met Microsoft Services Business Architecture (vroeger Motion)

-

IBM met het Component Business Model

-

Visualising business capabilities volgens Klinkmüller et al.

-

Value Delivery Modeling Language (VDML)

Voor elk van de modellen bekijken we volgende onderdelen: 1. Oorspronkelijk doel van model 2. Definitie van capabilities: hoe worden capabilities gedefinieerd en waarin verschilt deze definitie met de algemene definitie.

27

3. Organisatie van de capabilities: op welke manier worden de capabilities georganiseerd. 4. Visualisatie van de capabilities: hoe visualiseren we de capabilities tot we effectief een capability map verkrijgen. 5. Beschrijving van de capabilities: Hoe worden capabilities voorgesteld en beschreven. Bijvoorbeeld ook welke elementen worden gelinkt en welke maatstaven kunnen worden gebruikt. 6. Doelpubliek van de capability map: Wie zijn/zullen de gebruikers van de capability map zijn. In welke mate zullen ze deze map gebruiken? In hoofdstuk 4 zullen we dan elk van deze modellen en technieken toepassen op een gevallenstudie. Als dusdanig kunnen we beter evalueren aan de hand van de criteria vooropgesteld hoe elk model zijn werking vindt in de praktijk.

3.2 ALGEMEEN CAPABILITYMODEL Capabilitymodellen worden steeds belangrijker binnen de wereld van business architecten. Desalniettemin blijken er nog geen echte standaardmodellen beschikbaar, die business architecten kant en klaar kunnen gebruiken om een capability map te maken van hun bedrijf. Veel consultingbedrijven hebben hun eigen techniek ontwikkeld om capabilities te modelleren en gebruiken die als competitief voordeel om nieuwe klanten aan te trekken. Het probleem hiermee is dat er weinig informatie over te vinden is en dat deze modellen meestal aangepast zijn om binnen het domein van het respectievelijke consultingbedrijf te werken. Jeff Scott, Alex Cullen en Mimi An (2010) – werkzaam bij Forrester – hebben geprobeerd om een synthese te maken van de reeds bestaande modellen. Door met de verschillende consultingbedrijven te praten en met business architecten die werkzaam zijn rond dit onderwerp hebben ze een aantal algemene richtlijnen en principes opgesteld die kunnen worden gebruikt om een eigen capabilitymodel op te stellen. Onder andere met deze richtlijnen zullen we de criteria opstellen die zullen worden gebruikt om de verschillende modellen te evalueren.

28

3.2.1 OORSPRONKELIJK DOEL VAN MODEL De richtlijnen die zij voorstellen dienen in acht genomen te worden indien men zelf een capabilitymodel wil opstellen. Ze zijn gebaseerd op best practices uit vorige modelleeroefeningen.

3.2.2 DEFINITIE VAN CAPABILITY In een eerder artikel beschrijft Scott (2009) capabilities als de fundamentele elementen die de organisatie de capaciteit geven om een bepaalde uitkomst te bereiken. Ze kunnen worden beschouwd als het potentieel van de organisatie. Als we de capabilities samen bekijken dan vormen ze een model die alle functionele mogelijkheden voorstelt van het bedrijf. Deze capabilities heeft een bedrijf nodig om zijn business model en missie uit te voeren. Voor Scott moet elk capability model aan volgende drie principes voldoen: 1. De capabilities moeten de essentie van de business weergeven. Met behulp van het model moeten leiders nieuwe inzichten kunnen krijgen. 2. Het model moet een stabiel beeld geven van de onderneming. Capabilities veranderen weinig als ze goed gedefinieerd zijn. 3. De capabilities moeten gemakkelijk te linken zijn met de middelen die worden gebruikt en de activiteiten die het ondersteunt. Dat is waar de link tussen strategie, processen en middelen plaatsvindt. We zien dus dat de definitie en karakteristieken van Scott vrij goed in lijn liggen met wat we hebben gedefinieerd in hoofdstuk 2.

3.2.3 ORGANISATIE VAN DE CAPABILITY MAP Het is mogelijk om een lange lijst van capabilities die aanwezig zijn in het bedrijf op te stellen maar hierdoor krijgen we geen overzicht en zal het moeilijk zijn om efficiënt gebruik te maken van deze capabilities. Daarvoor hebben we enerzijds nood aan een verticale opsplitsing van onze capabilities. Dat gebeurt aan de hand van het hiërarchische beeld dat we ook al hebben gevonden in de karakteristieken van een capability. De vraagt blijft nu wel hoe diep we moeten gaan binnen deze hiërarchie. Volgens Scott et al. (2010) is een capability map met drie hiërarchische niveaus optimaal 29

voor de meeste situaties. Dat geeft ons genoeg detail om mee te werken maar we krijgen toch geen overdaad aan informatie te verwerken waardoor we worden gezogen in nutteloze (in ons geval) details. Indien nodig kunnen bedrijven meer niveaus en details toevoegen indien ze dat nodig achten maar in principe zal meer detail de communicatie tussen bijvoorbeeld business en IT vermoeilijken. Anderzijds hebben we ook nood aan een horizontale organisatie van de capabilities. Dat zal ons helpen om een goed overzicht te bewaren waarbij we als het ware met een helikopter boven het bedrijf zweven. De manier waarop deze horizontale decompositie gebeurt is vrij te kiezen volgens Scott et al. (2010) maar de meest gebruikte manieren om te organiseren zijn de volgende: -

Organisatiestructuur: Een eenvoudige en meest voor de hand liggende methode is om de capabilities te organiseren volgens de organisatiestructuur. Vooral KMO’s en grote bedrijven met een eenvoudige organisatiestructuur gebruiken deze methode. Bijvoorbeeld kan een logistiek bedrijf zijn capabilities organiseren in categorieën als logistiek, klantendiensten, marketing en verkoop, algemeen bedrijfsbeheer. Het is duidelijk dat indien de structuur niet al te ingewikkeld is deze methode de gemakkelijkste is.

-

Value streams: Indien we een ingewikkelde structuur weervinden binnen een bedrijf, bijvoorbeeld als we te maken hebben met verschillende business units, dan is de organisatiestructuur niet altijd de beste oplossing. Vaak wordt dan teruggegrepen naar de value stream van het bedrijf. Niet alleen bij complexe structuren is deze methode aangewezen maar ook bij bedrijven die zeer procesmatig werken kan dat een ideale oplossing zijn. Figuur 2.5 op pagina 17 geeft zo een structuur aan waarbij we de capabilities per activiteit in de value stream organiseren.

-

Een derde methode om capabilities te organiseren die Scott et al. aanbevelen is de ‘diensten naar klanten’-methode. Deze vorm van classificatie kan vooral worden gebruikt

voor

overheidsinstanties

en

non-profit

organisaties.

Ook

dienstenbedrijven kunnen deze methode gebruiken om hun capabilities te ordenen rond de manier waarop zij hun diensten leveren. Het voorbeeld dat Scott et al. aanhalen is dit van het US Governement’s Business Reference Architecture 30

(Federal Enterprise Architecture, 2007). Met dat model kunnen we capabilities classificeren in volgende categorieën: diensten voor burgers, leveringswijze, ondersteuning van levering van diensten, management van overheidsmiddelen. Deze methode voor classificeren zullen we vooral kunnen gebruiken wanneer er een uniforme klantenbasis is waarbij verschillende instanties binnen het bedrijf producten en diensten leveren aan die klantenbasis.

3.2.4 VISUALISATIE VAN DE CAPABILITIES Eens we een duidelijke definitie hebben van de capabilities en eens we weten hoe we ze gaan organiseren kunnen we kijken op welke manier we effectief een map kunnen maken van onze capabilities. Dat is een belangrijke stap want het is deze map waarmee er zal worden gecommuniceerd, waarmee men met een oogopslag kan zien welke capabilities er precies zijn en waarmee we een analyse kunnen uitvoeren. Het is dus belangrijk dat deze map genoeg informatie bevat om mee te kunnen werken maar toch eenvoudig genoeg is om geen te gecompliceerd beeld te krijgen van het bedrijf. Indien we echt alle informatie willen incorporeren moeten we gebruik maken van een UML-achtig model maar dat is niet de bedoeling. Het allerbelangrijkste volgens Scott et al. (2010) is dat we gebruik maken van ‘granulariteit’. Dat wil zeggen dat we capabilities verder verfijnen tot een bepaald niveau. Dat is dus de verticale structuur van de capabilities weergeven. Het is een fijne oefening om toch genoeg detail in de map te steken om ze werkbaar te maken maar toch niet overvol te steken zodat men door het bos de bomen niet meer ziet. Er is ook geen juist of fout model, voor bepaalde situaties zal een model met meer detail nodig zijn. Er is dus een mate van flexibiliteit aanwezig tijdens het maken van de capability map. In het vorige punt hebben we bepaald hoe we onze capabilities gingen organiseren dus bij de visualisatie proberen we de capabilities die we kunnen definiëren in het bedrijf in te vullen in de gekozen structuur. Figuur 3.1 toont een voorbeeld van een capability map waarbij de capabilities zijn georganiseerd volgens activiteiten van de value stream. Uiteraard is het de bedoeling dat we van elk van de capabilities een meer gedetailleerde beschrijving krijgen. In volgend punt wordt bekeken hoe we dat het best aanpakken.

31

Figuur 3.1 Capability map georganiseerd volgens activiteiten van de value stream (Scott et al., 2010)

3.2.5

BESCHRIJVING VAN CAPABILITIES

Nu we een map hebben waarop al onze capabilities geordend zijn volgens een horizontale en verticale structuur (de hiërarchie), kunnen we elke capability in meer detail gaan beschrijven. We gebruiken een aantal attributen waardoor we elke capability op een gelijkaardige manier kunnen beschrijven. We weten reeds uit hoofdstuk 2 dat capabilities zichzelf abstraheren van de middelen die ze nodig hebben om tot de uitkomst te komen. Dat wil zeggen dat we geen idee hebben hoe deze middelen worden ingezet maar we zijn wel op de hoogte welke middelen een bepaalde capability heeft. Deze middelen zijn mensen, processen en technologie (supra p.9). Scott et al. (2010) vinden het nodig om capabilities te beschrijven aan de hand van deze drie middelen, maar een uitbreiding met de informatie die de capability ondersteunt en de operationele maatstaven die we gebruiken om het succes te meten, zijn aan te raden. Elke capability zou volgens Scott et al. (2010) idealiter moeten worden weergegeven zoals Figuur 3.2 toont.

32

Figuur 3.2 Beschrijving capability (Scott et al., 2010)

We zien hierin volgende elementen: -

Naam: elke capability heeft een naam nodig. Deze naam hoeft niet per se de naam te dragen van een bepaalde functie binnen het bedrijf maar de naam moet verstaanbaar zijn voor iedereen die de capability map zal gebruiken. Deze naam zal ook worden gebruikt in de capability map. Dit voorbeeld toont de capability met als naam Marketing.

-

Beschrijving: Een korte beschrijving die uitlegt wat de capability precies inhoudt. Deze beschrijving moet zo kort mogelijk zijn maar toch genoeg informatie bevatten om de capability te onderscheiden van andere capabilities. In het voorbeeld wordt deze capability kort beschreven zodat het duidelijk is voor iedereen waar we over praten.

-

Mensen: we krijgen een korte lijst van personen of functies die de capability ondersteunen. Voor de Marketing capability zien we dat er verschillende mensen in betrokken zijn. Bijvoorbeeld marktstrategen, marktanalisten, statistici, …

-

High-level processen: we lijsten hier op welke processen betrokken zijn bij de capability. Vaak is het eenvoudig om een proces toe te wijzen aan één enkele capability maar ook vaak zal een proces verschillende capabilities met elkaar linken. Dan is het belangrijk om een goed overzicht te bewaren. Verschillende processen worden gelinkt aan de Marketing capability, vb. marktsegmentatie, competitieve analyse, …

-

Ondersteunende technologieën: capabilities worden vaak ondersteund door verschillende

technologieën.

Daarbij

denken

we

niet

alleen

aan 33

informatietechnologieën maar ook aan andere. Zo zien we voor de marketing capability dat we gebruik maken van sociale media, maar ook traditionele media. Het is niet de bedoeling om hier in te gaan op de effectieve applicaties aangezien dat te gedetailleerd is. -

Ondersteunende informatie: we beschrijven de data die gebruikt worden, en niet de bronnen van deze data. Zo zien we bijvoorbeeld dat de Marketing capability gebruikt maakt van data over de trends bij de klanten en klantenprofielen. De bronnen van deze data, bijvoorbeeld de bedrijfsdatabase of een extern bedrijf, kennen we niet. We kunnen dat eventueel wel opnemen in een appendix.

-

Operationele maatstaven: een laatste element dat we toevoegen zijn maatstaven. Deze vertellen ons hoe we kunnen meten hoe de capability presteert. Uiteraard is het vaak moeilijk om een maatstaf te vinden die enkel en alleen de prestatie van de capability meet. Daardoor zijn deze maatstaven vaak indicatoren van de prestatie aangezien deze maatstaven worden gedreven door een proces die verschillende capabilities overspant.

3.2.6

DOELPUBLIEK

Zoals reeds gezegd is dit model opgesteld om te worden gebruikt door iedereen die capabilities wil modelleren. Het moet worden beschouwd als een aantal richtlijnen gebaseerd op best practices. Wij zullen het gebruiken als raamwerk om de andere modellen mee te beschrijven.

3.3 MICROSOFTS VISIE Microsoft is een bedrijf dat heel vroeg op de kar is gesprongen aangaande het modelleren van capabilities. Onder impuls van Ulrich Homann hebben zij een techniek ontwikkeld om capabilities te modelleren. De oorspronkelijke naam van dit project was Motion maar later is dit omgevormd tot Microsoft Services Business Architecture (MSBA). Microsoft voert consultingactiviteiten uit bij bedrijven waarbij ze helpen om een capability map op te stellen (als onderdeel van het MSBA-process). Er is dus maar een gelimiteerde bron aan informatie beschikbaar die ons kan helpen om te begrijpen hoe Microsoft te werk gaat bij het modelleren van capabilities.

34

3.3.1

OORSPRONKELIJK DOEL VAN MODEL

Service oriëntatie begint meer en meer ingeburgerd te geraken in de bedrijfswereld. Eerst werd het vooral gebruikt om systemen en applicaties flexibeler te maken maar tegenwoordig wordt het service-concept meer en meer gebruikt binnen de context van de business. Indien men er in slaagt om een service georiënteerde onderneming op te bouwen kan een bedrijf veel wendbaarder worden in veranderende markten. Maar veel bedrijven hebben problemen om service georiënteerd te worden en om ervoor te zorgen dat business en IT met elkaar gealigneerd geraken. Homann (2006) vroeg zich af wanneer een investering in service oriëntatie te verantwoorden is. Hierbij stelde hij zichzelf de volgende drie vragen: -

Hoe zorgen we ervoor dat we niet dezelfde fouten maken bij het implementeren van service oriëntatie als in het verleden bij gelijkaardige initiatieven?

-

Hoe zorgen we ervoor dat de implementatiearchitectuur een duidelijke link heeft met de business benodigdheden?

-

Hoe zorgen we ervoor dat de implementatie geen al te kort leven beschoren is?

Vanuit deze drie vragen zocht Homann naar een oplossing. De oplossing werd gevonden binnen de capabilities die door hun stabiliteit gebruikt kunnen worden op lange termijn. Verder bieden ze een manier aan om zowel over business als over technologie te praten.

3.3.2

DEFINITIE VAN CAPABILITY

De definitie die door Microsoft wordt voorgesteld is de definitie van Homann. Deze definitie wordt over het algemeen aanvaard als de basisdefinitie voor een capability (supra p.4). Verder definieert Homann (2006) nog enkele andere concepten die zullen worden gebruikt in het model van Microsoft. Ten eerste definieert hij capability connectors. Deze stellen de link voor tussen de verschillende business capabilities. Deze connecties bevatten een rijke vorm van semantische informatie. Volgens Homann en Tobey (2006) bestaan er drie types van connecties: -

Input/Output: deze vorm van connectie beschouwt een capability een leverancier van een service aan een andere capability. De interactie tussen de capabilities 35

bestaat eruit dat de ene capability een service aanvraagt waar de andere op antwoordt. -

Ondersteunend: bij het ondersteunend connectietype wordt informatie doorgegeven van een capability naar een andere. In tegenstelling tot het vorige type, vindt de interactie maar plaats in één richting.

-

Controle: deze vorm van connectie zorgt ervoor dat een capability impact heeft op een andere capability met betrekking tot de performance. Er worden geen services uitgewisseld maar de ene capability stelt richtlijnen of prestatievereisten op voor de andere. De ene capability beheert de andere als het ware.

Een van de belangrijkste aspecten van capabilities is de relatie met elkaar. Het is belangrijk om zo snel mogelijk de connecties tussen de capabilities te vinden. Het zijn immers de connecties de we wijzigen en beheren terwijl de capabilities op zich stabiel blijven. Opnieuw vermeld ik hier even het belang van Service Level Expectations (SLEs). Deze zorgen ervoor dat de kwaliteit van het werk dat wordt uitgevoerd goed genoeg is. Ten slotte geven zowel Cook (2007) als Merrifield (2009) ons de raad om elke capability te benoemen met de vorm werkwoord – zelfstandig naamwoord. Bijvoorbeeld Verzenden zou geen goede naam zijn voor een capability. We gebruiken dan beter Verzend Product.

3.3.3

ORGANISATIE VAN DE CAPABILITY MAP

Microsoft organiseert zijn capabilities aan de hand van de organisatiestructuur. Figuur 2.1 (p.9) toont hoe Microsoft de verticale structuur implementeert. We hebben ten eerst de foundation capabilities. Deze worden opgesplitst in capability groepen en ten slotte vinden we de effectieve business capabilities. We bekijken nu hoe Microsoft elk van deze niveaus organiseert. 3.3.3.1 Foundation capabilities Op het allerhoogste niveau vinden we de foundation capabilities. Deze vormen de allerhoogste structuur en Microsoft splitst deze op in enerzijds operationele capabilities en anderzijds omgevingscapabilities. De operationele capabilities zijn alle capabilities die zich binnen de fysieke businessgrens van het bedrijf bevinden. Dat wil niet zeggen dat de leverancier van de capability per se het bedrijf zelf is. Deze capabilities zijn nodig om 36

waarde te creëren voor het bedrijf, opgesteld aan de hand van de doelen van het bedrijf. Zo is de capability Vervoer Product een capability dat kan worden uitgevoerd door een extern bedrijf maar we vinden deze capability wel weer binnen de operationele capabilities aangezien het waarde creëert voor het bedrijf. Volgende capabilities worden door Microsoft naar voor gebracht als generieke operationele capabilities: -

Ontwikkel producten en diensten

-

Creëer vraag voor die producten en diensten

-

Produceer/Lever de producten en diensten

-

Werk samen en communiceer met partners

-

Plan en beheer de business

Uiteraard kan de naamgeving wijzigen maar deze basis kan vrijwel in elke business worden gebruikt. De omgevingscapabilities zijn dan de capabilities die zich niet binnen de fysieke businessgrens bevinden. Deze capabilities bevinden zich buiten de operationele werking van het bedrijf maar ze kunnen enerzijds een invloed hebben op de waardelevering of anderzijds opportuniteiten bieden om te differentiëren. Microsoft beschouwt volgende generieke omgevingscapabilities: -

Klanten

-

Klantgerichte kanalen

-

Logistieke leveranciers

-

Infrastructuur

-

Verschaffers van financiële diensten

-

Leveranciers

Vaak vinden we ook een iets andere configuratie – afhankelijk van de industrie – van de omgevingscapabilities. We vinden dan Business Partners in plaats van Leveranciers, IT 37

leveranciers in plaats van Logistieke leveranciers en Regelgevende instituties in plaats van Verschaffers van financiële diensten 3.3.3.2 Capability groepen Op het volgende niveau vinden we capability groepen. Deze groepen zijn een verder opsplitsing van de foundation capabilities. Op dit niveau kunnen we al beginnen spreken over service levels, toerekenbaarheid, … Ook zien we op dit niveau verschillen ontstaan tussen verschillende bedrijven. Op het foundations niveau zien we dat immers nog niet ontstaan aangezien dat voor elke business min of meer gelijk is. 3.3.3.3 Business capabilities Op het volgende niveau vinden we de business capabilities. Dat zijn de bouwstenen van de capability map. We kunnen deze business capabilities verder in detail onderzoeken door ze op te splitsen in granulaire business capabilities. Het is belangrijk om te weten dat niet elke business capability op dit niveau verder moet worden opgesplitst in lagere niveaus. Enkel indien een grondige analyse dit vereist kan dat nodig zijn. Sykes en Clayton (2009) vindt de eerste twee niveaus noodzakelijk om een raamwerk op te stellen om de business te verstaan. Maar het derde niveau is het niveau waar we echt kunnen werken aan specifieke projecten. Op dit niveau vinden we genoeg details om een analyse aan te vatten en waar we attributen en meetwaarden zullen toevoegen aan de verschillende capabilities. Opnieuw zien we dat drie niveaus hier als voldoende wordt beschouwd, net zoals Scott et al. (2010) beschreef.

3.3.4

VISUALISATIE VAN DE CAPABILITIES

Microsoft probeert deze capability map op een simpele manier weer te geven. In Figuur 3.3

zien we de foundation capabilities met aan de rand de omgevingscapabilities en

centraal de operationele capabilities. Dit is de generieke map die Microsoft voorstelt en die, mits eventueel een andere benaming, voor nagenoeg elk bedrijf geldt.

38

Figuur 3.3 High level capability map volgens Microsoft (Tuna, 2009)

Uiteraard biedt zo een map wel een goed startpunt maar we moeten proberen om de visualisatie verder door te trekken. Voor elk van de vijf operationele capabilities gaan we een niveau lager en dit kunnen we ook gemakkelijk visualiseren. We kunnen dan op zijn beurt weer verder gaan tot het gewenste niveau. Door middel van minimaliseren en maximaliseren van capabilities moet het mogelijk zijn om in detail te gaan op een bepaalde capability terwijl we de andere foundation capabilities als dusdanig zien. Figuur 3.4

toont hoe in detail wordt gegaan binnen één foundation capability. Deze wordt dan

verder opgesplitst in granulaire capabilities. De foundation capability Voldoe aan Vraag bestaat uit de capability groepen Lever Dienst, Produceer Product, Koop Middelen aan, Beheer Planning en Beheer Logistiek. De capability groep Koop Middelen aan bestaat vervolgens uit twee capabilities, namelijk Beheer inkoop en leverancier contracten en Aankopen. Dit kan op zijn beurt weer verder worden opgesplitst.

39

Figuur 3.4 Capability map in detail (Doig, 2007)

Alhoewel het op het eerste zicht vrij eenvoudig is om de capabilities en hun hiërarchie te visualiseren, blijkt het toch niet voor de hand liggend om een simpele figuur te bekomen als men het hele bedrijf modelleert. Men bekomt dan een map die op z’n zachtst uitgedrukt nogal chaotisch lijkt. Figuur 3.5

toont een generieke map die ze bij Microsoft gebruiken als startpunt voor elk

bedrijf. Het is duidelijk dat een eenvoudig beeld krijgen van de onderneming met zo een map niet vanzelfsprekend is. Daarom lijkt het mij noodzakelijk om te werken met een goede tool die het mogelijk maakt om de map te bekijken op verschillende niveaus en in en uit te zoomen waar nodig. Welke tool Microsoft daarvoor gebruikt is niet duidelijk. Wel zijn er tools op de markt, zoals bijvoorbeeld PlanningIT van Alfabet die het mogelijk maken om capabilities te modelleren. Dat kan dan gebeuren aan de hand van de visie die Microsoft heeft maar dat is niet noodzakelijk het geval.

40

Figuur 3.5 Volledig uitgewerkte generieke capability map (Lloyd, 2006)

3.3.5


Voor elke capability kunnen er tot 180 attributen worden gevonden. Voorbeelden van mogelijke attributen zijn SLE, locatie, eigenaar, doel, performance, type, … Uiteraard zullen enkel die attributen beschreven worden die men nodig acht.

41

Figuur 3.6

toont de capability Communiceer Status weer met drie attributen: de totale

benodigde tijd, de kost per transactie en de interfaces die het heeft. Deze figuur geeft ook mooi aan hoe Microsoft een capability echt als een ‘black box’ beschouwt. De technologie, processen en mensen die nodig zijn om de capability te implementeren zitten ingekapseld in de capability maar hoe ze met elkaar in interactie gaan blijft onbekend.

Figuur 3.6 Capability met attributen (Doig, 2007)

Indien we vergelijken hoe Microsoft capabilities beschrijft ten opzichte van hoe het volgens Scott et al. (2010) idealiter zou moeten zijn, zien we dat dat in essentie gelijkaardig is. Zowel de mensen, processen en technologieën worden beschreven. Doordat er tot 180 attributen kunnen worden beschreven gaat Microsoft zelfs iets dieper dan wat Scott et al. beschrijven.

3.3.6 DOELPUBLIEK Aangezien deze vorm van capability modellering is ontstaan om service oriëntatie binnen het bedrijf gemakkelijk te implementeren is het primaire doelpubliek de business architecten onder leiding van de CIO. Deze kunnen een Motion project opstarten waarbij onder andere een capability map wordt opgesteld. Nu blijkt het wel nuttig om deze capability map niet alleen te gebruiken om service oriëntatie gemakkelijker te implementeren maar ze kan ook gebruikt worden voor 42

eerder strategische doeleinden. In hoofdstuk 2 hebben we mogelijke toepassingen van een

capability

map

beschreven

en

daarbij

waren

outsourcing–

en

investeringsbeslissingen belangrijke toepassingen. Dus oorspronkelijk kunnen we als doelpubliek de business architecten beschouwen maar ook voor topmanagers (eventueel zelfs CEO) kan een capability map een nuttig instrument zijn.

3.4 IBMS VISIE Een tweede grote speler die een model heeft ontwikkeld om capabilities te modelleren is IBM. Zij hadden een ander doel voor ogen bij het ontwikkelen van een capability map dan Microsoft.

3.4.1


IBM vertrekt vanuit het standpunt dat bedrijven, door de alomtegenwoordige groei van IT

en

internet,

geconfronteerd

worden

met

constant

veranderende

marktomstandigheden. Pohle, Korsten, Ramamurthy (2005) geven enkele voorbeelden hoe IT de businesswereld heeft veranderd. Ten eerste hebben internet en daarmee gerelateerde technologieën de communicatiemogelijkheden drastisch verhoogd. Verder hebben ERP-systemen en open data standaarden zoals XML ervoor gezorgd dat door automatisering de transactiekosten drastisch verlaagden en dat bedrijven veel flexibeler werden. Pohle et al. concluderen dat deze elementen leiden tot, wat hij noemt, een globaal connectiviteitsplatform. De drempel om tot een markt toe te treden vervaagden helemaal en men kan wereldwijd toetreden tot dit platform. Overal ontstaan bedrijven die gelijkaardige diensten bieden als de huidige leveranciers van bedrijven. Er wordt meer en meer gezocht naar de beste partner die het meest waarde kan creëren. Het is dus duidelijk dat bedrijven moeten specialiseren op een paar activiteiten die ze zeer goed kunnen. Aldus kunnen ze maximale waarde creëren voor zowel klanten, personeel als voor aandeelhouders. Volgens Pohle et al. moet er zowel intern als extern gespecialiseerd worden. 3.4.1.1 Interne specialisatie Binnen interne specialisatie beschrijven Pohle et al. drie verschillende niveaus van specialisatie. In Figuur 3.7 zien we de drie niveaus waar op gefocust wordt. In de jaren ’80 lag de focus op het optimaliseren van de business unit. In de jaren ’90 werd deze vorm 43

van optimaliseren als achterhaald beschouwd en begon men processen te optimaliseren. Sinds het begin van de jaren 2000 is men deels afgestapt van procesoptimalisatie. De focus begon meer en meer te liggen op het optimaliseren van het bedrijf. Men bekijkt het bedrijf als een bouwwerk waarbij de individuele bouwstenen in interactie zijn met andere bouwstenen zowel binnen het bedrijf als buiten het bedrijf.

Figuur 3.7 drie niveaus in interne specialisatie (Pohle et al., 2005)

3.4.1.2 Externe specialisatie Ook binnen externe specialisatie vinden Pohle et al. drie verschillende niveaus. Figuur 3.8 toont de evolutie van externe specialisatie in de tijd. Op het eerste niveau zijn bedrijven vooral intern geïntegreerd. Ze proberen intern zoveel mogelijk te stroomlijnen door onder andere verticaal te integreren in de waardeketen. Later stapten bedrijven over naar strategische partnerschappen. In plaats van verticaal te integreren gingen veel bedrijven zich specialiseren in een bepaald deel van de waardeketen. Strategische partners worden dan gebruikt om meer waarde te creëren door hogere marges en nieuwe markten en nieuwe verkoopskanalen aan te boren. Veel bedrijven zitten nu nog op dat niveau van externe specialisatie. Indien men echter teveel strategische partners heeft, kunnen de coördinatiekosten die volgen uit die relaties de pan uit swingen. Daarom vinden we nog een derde niveau van externe specialisatie, namelijk de bedrijven die werken binnen een industrie netwerk. In deze fase gaan bedrijven zich positioneren binnen een netwerk. Ze voeren de kernactiviteiten uit die ze het best kunnen en als volgt zijn ze dus een deel van een ecosysteem. 44

Figuur 3.8 drie niveaus in externe specialisatie (Pohle et al., 2005)

3.4.1.3 Component Business Model (CBM) IBM kwam met een model om bedrijven te helpen om zich intern en extern te specialiseren. Dat model is het Component Business Model en beschouwt het bedrijf als een samenstelling van componenten. Dit model helpt het bedrijf om een compleet beeld te krijgen van de organisatie waardoor men aan niveau drie van de interne specialisatie kan werken. Verder worden welafgelijnde bouwstenen beschouwd die als het ware zelfstandig kunnen werken. Hierdoor kunnen bedrijven zich extern specialiseren door componenten van andere leveranciers te gebruiken. De insteek van IBM is dus eerder van een strategisch oogpunt in vergelijking met Microsoft. Desalniettemin is het ook bij IBM de bedoeling om hun capabilitymodel te linken met een service georiënteerde onderneming. De verschillende componenten binnen een CBM vinden interactie met elkaar door het uitwisselen van services. Dat is wat Cherbakov et al. (2005) service orientation noemt.

3.4.2


IBM spreekt niet letterlijk van een capability. Zij modelleren componenten. Maar als we er eens bijhalen wat componenten precies zijn dan is de vergelijking tussen beiden treffend. Crippa (2004) definieert een business component als “een deel van de onderneming dat het potentieel heeft om semi-onafhankelijk te functioneren. Een business component is een logische weergave van een deel van de onderneming dat middelen, mensen, technologie en kennis bevat die noodzakelijk zijn om waarde te leveren.” We zullen dus componenten als synoniem voor capabilities gebruiken indien we praten over het Component Business Model van IBM. 45

3.4.3


De verschillende componenten aanwezig binnen een bedrijf worden door IBM georganiseerd volgens twee criteria. Op de ene as vinden we business competenties en op de andere as vinden we verantwoordelijkheid/toerekenbaarheid. De organisatie aan de hand van twee aspecten is een uitbreiding van wat Scott et al. (2010) aanbevelen en wat we vinden binnen Microsoft. We bekijken nu elk van de twee aspecten en hoe deze samen worden geïntegreerd in een map. 3.4.3.1 Business competenties De componenten worden om te beginnen georganiseerd volgens de verschillende highlevel business competenties. Deze zijn vrij generiek en zijn vergelijkbaar met de verschillende foundation capabilities van Microsoft. In het generiek model gebruikt IBM de volgende competenties: Beheer, Ontwerp, Koop, Maak, Verkoop. Uiteraard kunnen deze per industrie of bedrijf verschillen. Van Diessen, Sierman, Lee (2008) definiëren een business competentie als “grote zakelijke gebieden met gelijkaardige objectieven”. Volgens hen moeten deze competenties worden bepaald door te kijken wat de strategische objectieven zijn van het bedrijf. Om de uiteindelijke map leesbaar en duidelijk te maken moeten deze competenties simpel, logisch en praktisch gekozen worden (Pohle et al., 2005). 3.4.3.2 Verantwoordelijkheid/toerekenbaarheid Op de verticale as zien we drie niveaus van toerekenbaarheid: Sturen, Controleren en Uitvoeren. Deze niveaus zorgen ervoor dat er een onderscheid wordt gemaakt binnen de componenten met betrekking tot het beslissingsniveau. Componenten op het niveau van Sturen zijn componenten die worden gebruikt voor strategische beslissingen te nemen, structuren voor governance op te stellen en collaboratie met andere componenten te ondersteunen (Cherbakov et al. 2005). Op het Controleniveau vinden we componenten die dienen als “management checks”. Ze bieden ondersteuning bij het controleren, beheren van uitzonderingen en bij tactische besluitvorming (Van Diessen et al., 2008). Ze zijn de link tussen de componenten op het Sturenniveau en Uitvoerenniveau.

46

Op dit laatste niveau vinden we componenten die het echte werk doen. Deze componenten bieden de acties aan die voor waardecreatie zorgen binnen de onderneming (Cherbakov et al., 2005).

3.4.4


Indien we deze twee assen nu combineren en de componenten op de gepaste plaats invullen krijgen we een map zoals in Figuur 3.9. Deze zeer eenvoudige map past op een A4-blad maar geeft toch een volledig overzicht van het bedrijf. Dat is een van de sterktes van zo een model. Op een zeer beknopte manier kan men toch een volledig bedrijf op een nuttige manier modelleren.

Figuur 3.9 Component Business Map (Pohle et al., 2005)

3.4.5


Elke component wordt door vijf dimensies beschreven (Cherbakov, 2005): -

Businessdoel: deze dimensie geeft in essentie weer wat de component doet. Dat komt dus als het ware neer op wat we eerder hebben gelezen in Cambridge woordenboek als definitie van een capability.

-

Activiteiten: alle activiteiten die binnen een component worden of kunnen worden uitgevoerd, worden hier beschreven. Deze activiteiten leveren of maken gebruik van services.

-

Middelen: we krijgen een abstractie van de middelen, mensen, kennis en technologie die de component nodig heeft om goed te kunnen functioneren. Opnieuw is de link met vorige definities vrij duidelijk. Hoe deze middelen met 47

elkaar worden gecombineerd is van ondergeschikt belang bij het modelleren van de componenten. -

Governance: Een component kan semi-onafhankelijk functioneren en heeft aldus een aantal regels, procedures, maatstaven, … nodig. Deze worden voor elke component neergeschreven.

-

Business services: Elke component heeft een aantal business services die het aanbiedt of gebruikt. Deze services zijn het gevolg van een service georiënteerde onderneming. Om hun businessdoel uit te kunnen voeren wisselen componenten services uit met andere componenten. Door middel van SLAs wordt er voldaan aan de vereisten van de componenten.

Figuur 3.10 Beschrijving van een Business Component (Pohle et al., 2005)

3.4.6 DOELPUBLIEK Het doelpubliek dat IBM voor ogen heeft zijn de topmanagers van een bedrijf. Het moet worden gebruikt als een strategische tool om het bedrijf te sturen naar een gespecialiseerd bedrijf (zowel intern als extern). Het proces om tot een gespecialiseerde onderneming

te komen bestaat uit drie stappen. Ten eerste moet er een

componentgebaseerd overzicht worden opgesteld van de bestaande onderneming. Hiervoor kan men zich baseren op een analyse van het bedrijf en een marktanalyse. Door het bedrijf in een netwerk van componenten te modelleren kunnen we gaten zien en de problemen die moeten worden opgelost om een componentgebaseerde 48

onderneming te worden. Ten tweede moeten er stappen worden gezet richting specialisatie door een plan op te stellen. Dat plan is gebaseerd op de vorige analyse. De derde stap is dan de infrastructuur van de onderneming dusdanig aanpassen dat er effectief een componentgebaseerde onderneming bestaat.

3.5 KLINKMÜLLER ET AL. Een derde model dat we bekijken is het model ontwikkeld door Klinkmüller et al. (2010). De focus van dit model ligt meer op het aspect van visualisatie van capabilities dan de vorige modellen.

3.5.1


Klinkmüller et al. (2010) vertrekken van het punt dat door globalisatie bedrijven zichzelf moeten specialiseren om te weerstaan aan de extra druk die ontstaat door die globalisatie. Om zich te focussen op de kerncompetenties moeten bedrijven nietkernactiviteiten outsourcen. Welke processen en activiteiten zullen geoutsourcet worden moet worden beslist aan de hand van een business analyse. Deze analyse moet volgens de auteurs gebaseerd worden op een model dat een stabiel beeld geeft van de onderneming. Maar een business analyse gebaseerd op capabilities leidt heel vaak tot een overdaad aan informatie aangaande de structuren, de relaties tussen de capabilities en de attributen. Om dat probleem tegen te gaan hebben Klinkmüller et al. een model ontwikkeld dat zich minder focust op de fundamentele concepten en het gebruik, maar eerder op de visualisatie van business capabilities. In plaats van de capabilities weer te geven in een lijst of in tabellen, geven de auteurs deze weer in een driedimensionaal diagram. In dit diagram kunnen zowel de complexe relaties tussen de capabilities worden weergegeven, maar ook verschillende attributen van de capabilities.

3.5.2


Klinkmüller et al. geven volgende definitie aan een business capability : “Een capability is een manier om het potentieel van een organisatie weer te geven om een bepaald doel of bepaalde uitkomst te bereiken. Capabilities stellen de structuur voor van een business en abstraheren zichzelf van processen, middelen en mensen die nodig zijn om de capability uit te voeren. […] Specifieke capabilities kunnen vergeleken worden op basis van hun attributen.” (Klinkmüller et al. , 2010, p.243) 49

Verder beschouwen de auteurs capabilities als hiërarchisch waardoor we een capability kunnen opsplitsen in meerdere capabilities. Vervolgens beschrijven horizontale relaties hoe capabilities met elkaar in interactie gaan. De combinatie van een verticale en horizontale structuur zorgen voor de mogelijkheid om een driedimensionaal model te maken van capabilities. We zien dat Klinkmüller et al. zich grotendeels baseren op de definitie van Homann (2006).

3.5.3


Een business analyse gebeurt aan de hand van vier stappen. Deze analyse is zoals reeds gezegd een hulpmiddel dat gebruikt wordt bij het nemen van beslissingen aangaande outsourcing. Ook de allocatie van budget kan worden gebaseerd op deze analyse. De eerste stap van de analyse is het creëren van een business capability map. Tijdens deze stap wordt de structuur bepaald die we gebruiken om onze capability map te organiseren. Klinkmüller et al. gebruiken dezelfde structuur als deze die Homann voorstelt. Als basis vinden we dus de volgende vijf capabilities op het hoogste niveau: Ontwikkel Producten/Diensten, Creëer Vraag, Produceer/Lever de Producten of Diensten, Plan en Beheer de Onderneming en Werk Samen met Partners. Elk van deze basiscapabilities worden dan verder opgesplitst in fijnere capabilities. De auteurs zijn van mening dat – zoals we reeds enkele malen hebben gezien – we verder moeten gaan met de decompositie tot we drie tot vijf niveaus hebben. Eens we dat gedaan hebben, hebben we capabilities die kunnen worden weergegeven als een hiërarchische structuur. Om nu de driedimensionaliteit mogelijk te maken moeten de horizontale relaties ook worden toegevoegd. De manier waarop dat gebeurt wordt niet duidelijk uitgelegd door Klinkmüller et al. 4

3.5.4


De tweede stap is de attributen bepalen die we zullen gebruiken bij de verdere analyse. Afhankelijk van welke analyse we willen maken, kiezen we andere attributen. Voorbeelden van attributen zijn performance, strategische waarde, IT ondersteuning, maandelijks gebruik, … Om capabilities met elkaar te kunnen vergelijken aan de hand Dit blijkt uit volgend citaat: “de horizontale relaties worden toegevoegd door een zorgvuldige inspectie van de capabilities” (Klinkmüller et al, 2010, p.245) 4

50

van deze attributen moeten we de attributen meten aan de hand van een ordinale schaal. Bijvoorbeeld zouden we voor het attribuut strategische waarde de schaal zeer laag, laag, gemiddeld, hoog en zeer hoog. Deze schaal wordt dan omgezet in numerieke waarden zodat er een rangschikking kan worden opgesteld. Eens we alle capabilities en de attributen hebben bepaald aan de hand van interviews en literatuuronderzoek kan er in stap 3 een tabel worden opgesteld. Verticaal worden alle capabilities neergeschreven waarbij de hiërarchie wordt weergegeven door met nummers te werken. Bijvoorbeeld de capability Beheer Inkomsten op niveau vier wordt als volgt neergeschreven: 1.1.1.1. Beheer Inkomsten. Op de horizontale as worden ten eerste de capabilities weergegeven die een relatie hebben met de eerstgenoemde capability. Ten tweede krijgen we een opsomming van alle attributen met de gevonden waarden. Als voorbeeld kunnen we een producent van toetsenborden bekijken. Deze producent koopt grondstoffen aan en verwerkt deze tot halffabricaten (bijvoorbeeld toetsen, behuizing, …). De toetsenborden worden dan geassembleerd en onderworpen aan een kwaliteitscontrole. Als we deze capabilities beschrijven en in een tabel weergeven zoals Klinkmüller et al. (2010) voorschrijft bekomen we Tabel 3.1. Als attributen bekijken we de strategische waarde en de mate van automatisering. Capability

Horizontaal

Beschrijving

gerelateerde

relatie

van

Strategische

Automatisering

waarde

capability 1. Produceer en

Zeer hoog

Gemiddeld

Zeer hoog

Hoog

Zeer hoog

Zeer hoog

Zeer hoog

Laag

Lever Product 1.1. Produceer

1.2. Inkoop

De benodigde grondstoffen moeten

Product

worden aangekocht.

1.1.1. Fabriceer

1.1.2. Assembleer

De geproduceerde

Halffabricaten

Product

halffabricaten moeten worden geassembleerd tot een eindproduct.

1.1.2.

1.1.1. Fabriceer

De assemblage hangt af

Assembleer

Halffabricaten

van de geproduceerde

Product

halffabricaten.

51

1.1.3. Controleer

1.1.1 Fabriceer

De kwaliteit hangt af van

Kwaliteit

Halffabricaten

de kwaliteit van deze

Hoog

Gemiddeld

halffabricaten. 1.1.2. Assembleer

De eindkwaliteit is

Product

afhankelijk van de kwaliteit van het assemblageproces.

Tabel 3.1 Voorbeeld beschrijving capabilities

Klinkmüller et al. (2010) stellen voor om de verschillende attributen met behulp van gewichten te reduceren tot één waarde die een algemeen beeld geeft over hoe goed een capability het doet. Zo is het makkelijk om binnen een bedrijf de problemen te identificeren. De auteurs zullen in de toekomst eraan werken om de gewichten van de verschillende attributen aan te passen aan de noden van de gebruiker. Zo is het voor iemand die een onderzoek doet naar de mate van IT ondersteuning veel belangrijker om te weten hoe goed deze ondersteuning is dan iemand die zoekt naar mogelijkheden om te outsourcen.

3.5.5 Tabel 3.1

VISUALISATIE VAN DE CAPABILITIES is nog maar een beschrijving van vijf capabilities en we bekeken maar twee

attributen en zelfs nu is deze tabel al niet meer al te overzichtelijk. De auteurs zijn van mening dat het gezegde “een beeld zegt meer dan duizend woorden” hier ten zeerste van toepassing is. Door de capabilities op een visuele manier voor te stellen kan er veel intuïtiever gewerkt worden en kan de business analist een veel beter beeld vormen van de onderneming. De visualisatie die door Klinkmüller et al. wordt voorgesteld pakt twee aspecten aan. Ten eerste kan er een duidelijk beeld worden gevormd van de horizontale en verticale relaties tussen de capabilities. Zeker voor de horizontale relaties is dat een meerwaarde ten opzicht van de vorige modellen. Zoals reeds gezegd, is dat een belangrijk punt maar mislukken de andere modellen om dat op een eenvoudige manier weer te geven. Ten tweede moet het mogelijk zijn om de capabilities te bepalen waar men verbeteringen kan aanbrengen. Dat gebeurt door een analyse te maken van de attributen afzonderlijk of door de gewogen som te nemen en deze algemene graadmeter te bekijken. De metafoor die de auteurs gebruiken is deze van een hemisfeer. Door business capabilities te bekijken als knopen en de relaties ertussen als lijnen, kunnen we het 52

netwerk van capabilities als een graaf zien. Indien we enkel de verticale relaties zouden bekijken zouden we evenwel gewoon te maken hebben met een boom met takken. Om een duidelijke analyse te kunnen maken moeten we evenwel weten welke knopen op welk niveau staan. Indien we een tweedimensionale graaf gebruiken kan dat zeer moeilijk blijken. Daarom projecteren de auteurs deze graaf op een hemisfeer. Om te beginnen wordt de eenvoudige boom (zonder de horizontale relaties) geprojecteerd op de hemisfeer waarbij de wortel als pool fungeert. Het laagste niveau binnen deze verticale decompositie vinden we op het niveau van de evenaar. Daartussen bevinden zich de andere niveaus. De verticale relaties worden weergegeven door lijnen op de oppervlakte van de hemisfeer. Vervolgens worden de horizontale relaties toegevoegd door de knopen te verbinden binnenin de hemisfeer. Op deze manier zorgen de auteurs ervoor dat er een duidelijk onderscheid kan worden gemaakt tussen deze verschillende relatievormen. In Figuur 3.11 zien we enkele capabilities weergegeven op een hemisfeer. De rode lijnen zijn de hiërarchische relaties en de groene lijnen geven de horizontale connecties voor.

Figuur 3.11 Voorstelling van capabilities op een hemisfeer (Klinkmüller et al., 2010)

Eens we deze hemisfeer hebben kunnen we verder met de analyse door elke capability te bekijken aan de hand van de verschillende attributen, of aan de hand van het geaggregeerde attribuut. De auteurs stellen vier verschillende opties voor die kunnen worden gebruikt om een knoop een bepaalde attribuutwaarde mee te geven. Optie 1 is om elke capability een kleur te geven afhankelijk van wat de geaggregeerde 53

attribuutwaarde is. Optie 2 maakt gebruik van een verschillende hoogte van de knopen en optie 3 maakt gebruik van verschillende vormen. Bij optie 4 worden de verschillende capabilities gegroepeerd volgens hun waarde. De capabilities

worden vooreerst

gerangschikt volgens de waarde en dan wordt deze reeks in gelijke delen opgesplitst. Er worden dus groepen gemaakt van gelijke grootte. Figuur 3.12 toont hoe elk van deze methodes werkt.

Figuur 3.12 Vier opties om attribuutwaarde weer te geven (Klinkmüller et al., 2010)

3.5.6 DOELPUBLIEK Klinkmüller et al. (2010) ontwikkelden deze visualisatiemetafoor als hulpmiddel voor business analisten. In plaats van ellenlange lijsten en tabellen te hebben met capabilities waarbij er vele tientallen attributen worden vergeleken met elkaar, kunnen de analisten op deze manier zeer snel en gemakkelijk relaties zien en attributen met elkaar vergelijken.

3.6 VALUE DELIVERY MODELING LANGUAGE (VDML) Het laatste model dat zal worden besproken is de Value Delivery Modeling Language. Dit model wordt op dit moment nog ontwikkeld en zal deel uitmaken van de modellen die OMG ondersteund.

3.6.1


De modelleertaal VDML werd ontwikkeld naar aanleiding van twee observaties die zich voordoen. Ten eerste is er nog geen gestandaardiseerde manier om de “gedachtegang van hoe een organisatie waarde creëert, levert en ontvangt, te analyseren en te 54

modelleren” (de Man, Berre, 2012, p.6) Ten tweede is het nog steeds moeilijk om de reeds uitgebreide proces- en servicemodellen te koppelen aan die gedachtegang. Reeds in 1985 beschreef Michael Porter (1985) hoe waarde werd gecreëerd en geleverd aan de eindgebruiker doorheen de value chain. We kunnen hier gretig gebruik van maken om te bepalen welke activiteiten bijdragen tot de uiteindelijke waarde. Elke deelnemer in de waardeketen geeft en krijgt waarde van andere deelnemers maar uiteindelijk moet elke deelnemer een positieve waarde verkrijgen. VDML probeert door gebruik te maken van capabilities het concept van value chain uit te breiden. Capabilities worden vaak geanalyseerd op een hiërarchische manier (zoals we hebben gezien in de vorige modellen) maar zonder echte link met de waardecreatie naar de eindgebruiker toe. Door deze twee concepten te linken met elkaar kan er een beter model gemaakt worden van het bedrijf. Het model dat wordt opgesteld is gelijkaardig aan wat we doen in procesmodellering maar “een VDML capability methode focust op de stroom van te leveren resultaten en bijdragen van waarde ten opzichte van de stroom van controle, en dus biedt een hoger niveau van abstractie van wat het bedrijf precies doet…” (Cordys en CSC, 2012, p.14) Naast deze twee concepten probeert VDML ook het groeiende belang van collaboratie te modelleren. Een collaboratiemodel modelleert hoe mensen – door gebruik te maken van capabilities – samen werken om waarde te creëren. VDML gebruikt naast de reeds genoemde concepten en modellen (Value chain analysis, value stream analysis, capability analysis, value network analysis) ook concepten uit e³value modeling, REA (Resource Event Agent) en business models. Cordys en CSC (2012) geven een lijst van 13 objectieven die VDML vervult. De drie belangrijkste objectieven zijn -

het linken van waardecreatie met de activiteiten die daartoe bijdragen

-

de karakteristieken van capabilities bepalen

-

een abstractie maken van de organisatie

Het ultieme doel van VDML is een uniforme taal ontwikkelen die het mogelijk maakt om value delivery models te maken. “Een value delivery model is een model dat business 55

analyse en ontwikkeling ondersteunt gebaseerd op de evaluatie van performance en stakeholder satisfactie. Dat wordt bereikt door activiteiten en interacties tussen mensen en organisaties door gebruik te maken van business capabilities om middelen toe te passen en waarde voor de stakeholders te leveren.” (de Man, Berre, 2012, p.6)

3.6.2

DEFINITIES

Alvorens we kijken hoe een capability wordt gedefinieerd, is het belangrijk om enkele andere kernbegrippen binnen deze modelleertaal te definiëren. We bekijken achtereenvolgens value, value proposition, collaboratie, organisatie en activiteiten. Ten slotte zien we hoe capabilities binnen dat plaatje passen. 3.6.2.1 Value en Value Proposition In VDML wordt een value gedefinieerd als “een meetbaar voordeel geleverd aan een ontvanger in combinatie met een business item of te leveren resultaat5.” (Cordys en CSC, 2012, p.29). In meer simpele woorden is het dus eigenlijk een element van een bepaald product of dienst die door een ontvanger gewenst is. Voorbeelden van values zijn de betrouwbaarheid van het product, de kost, het nut, het gebruiksgemak, … Value wordt toegevoegd aan een product of dienst door gebruik te maken van activiteiten. Elke activiteit voegt waarde toe en door dat te modelleren stijgt de traceerbaarheid van het eindproduct. We weten sneller waar er problemen zijn en hoe we de waarde nog meer kunnen verhogen. Een uitwisseling vindt plaats tussen twee partners die waarde uitwisselen. De waarde die elke partner aan een bepaald product of dienst zal hechten zal waarschijnlijk niet dezelfde zijn aangezien dat een subjectief gegeven is. Wel is het belangrijk dat beide partijen een positieve toename zien van hun waarde. Anders zou er geen uitwisseling mogelijk zijn. We kunnen nu een value proposition definiëren als “het concept dat de waarden die gelinkt zijn met de te leveren resultaten beschrijft en de transformatie levert om van een maat die bij elke waarde hoort om te zetten tot een bepaald satisfactieniveau van die value voor de beschouwde ontvanger (vb. een klant of marksegment).” (Cordys en CSC, 2012, p.29). We verkrijgen dus één waarde die het verwachte satisfactieniveau van de ontvanger beschrijft. We kunnen deze value proposition nu vergelijken met deze van andere bedrijven en aldus bepalen welke values moeten worden toegevoegd om een competitief voordeel te hebben. 5

Een te leveren resultaat is de vertaling voor een deliverable

56

3.6.2.2 Collaboratie, organisatie, rollen en activiteiten Een collaboratie is “de interactie van meerdere deelnemers om een gedeeld doel te bereiken. Elke deelnemer bevindt zich in een rol die voorstelt hoe de relatie is met de rest van de deelnemers. […] Een rol wordt vervuld door een deelnemer die de capability heeft die vereist is om een bepaalde activiteit uit te voeren.” (Cordys en CSC, 2012, p.30) Een onderneming wordt aldus aanzien als een hiërarchie van collaboraties die samen werken om de doelen te bereiken binnen het bedrijf. Voorbeelden van collaboraties zijn een departement binnen een bedrijf, maar dat kunnen ook teams van enkele personen zijn of individuen. 3.6.2.3 Capability, Capability Offer en Capability Method Het woord capability is reeds gevallen bij de definiëring van een collaboratie. We kijken nu hoe de concepten capability, capability offer en capability method worden gedefinieerd binnen VDML. We lezen dat “een capability de mogelijkheid is van een organisatie om een specifiek type werk uit te voeren waarbij dat kan gepaard gaan met mensen met specifieke vaardigheden en kennis, intellectuele eigendom, gedefinieerde werkwijzen, operationele faciliteiten, gereedschappen en materiaal.” (Cordys en CSC, 2012, p.30) Capabilities worden ingezet om producten of diensten te produceren of te leveren. Dat gebeurt aan de hand van activiteiten die waarde toevoegen. Om zo een activiteit uit te voeren dienen de nodige capabilities aanwezig te zijn. VDML probeert een bibliotheek aan te bieden waarbinnen we een uniforme definitie vinden van de capabilities en waarin we een taxonomie vinden. Aldus kunnen capabilities worden opgebroken in meer specifieke capabilities. Deze taxonomie is de basis voor een capability map en een heat map. VDML maakt gebruik van deze taxonomie zodat er consistentie is, zowel binnen de organisatie als buiten de grenzen van de organisatie. Men kan op een consistente manier gelijkaardige capabilities definiëren en verder kan men zien welke capabilities in andere organisaties ook worden ingezet. Dat kan een basis zijn om strategische partnerships aan te gaan. Een capability uit de taxonomie kan door een of meerdere organisatorische eenheden door middel van een capability offer aangeboden worden. De relatie tussen een capability en een capability offer is dus een nul op veel-relatie. De capability offer 57

beschrijft met welke middelen het doel van de capability zal worden bereikt, maar we hebben geen idee van de collaboratie tussen die middelen. Daarvoor hebben we het concept van capability method nodig. We definiëren een capability method als een groep mensen of organisaties die samenwerken om een bepaalde capability te leveren. Het is als het ware een sjabloon dat dient om het vereiste werk aan te duiden om het resultaat van de capability te bereiken (Cummins, 2012). Een capability method wijst mensen een bepaalde rol toe, de vereiste activiteiten worden uitgevoerd, middelen worden gebruikte en resultaten worden geproduceerd. Dat kan eigenlijk ook allemaal worden beschreven in een collaboratie maar we gebruiken een capability method aangezien dit bij herhaling kan worden gebruikt. Zo heeft dit een eigenaar (een organisatorische eenheid) en wordt deze capability method ondersteund door mensen en middelen die horen tot deze unit. Een capability offer kan dus door nul of meerdere capability methods ondersteund worden. Die nul is in het geval dat de capability offer vrij atomair is en dan zullen de benodigde middelen rechtstreeks aan de capability offer gelinkt worden. Als we deze concepten vergelijken met de definities van capabilities in de vorige modellen dan zien we dat de term capability kan worden opgesplitst in een capability offer en een capability method. De capability offer geeft de beschrijving van wat de capability precies is en is dus eigenlijk de omschrijving of het doel van de capability zoals we het hebben gezien in de vorige modellen. De capability method is dan de beschrijving van de mensen, activiteiten, technologie, … en hun collaboratie die nodig is om het doel te bereiken. 3.6.2.4 VDML Metamodel Figuur 3.13 geeft een metamodel waarin de belangrijkste concepten van VDML worden weergegeven met hun relaties met andere concepten.

58

Figuur 3.13 VDML Metamodel (de Man, Berre, 2012)

3.6.3


Het grote verschil tussen VDML en de drie vorige modellen is het plan van aanpak. Bij de vorige drie modellen was het startpunt van het modelleren van capabilities telkens een generieke map, al dan niet gebaseerd op de specifieke industrie. Aangezien deze al voor 80% de capabilities van het bedrijf modelleerden was de oefening meer een aanpassingsoefening dan een echte modelleeroefening. VDML vertrekt vanuit een ander standpunt en begint echt met een leeg blad papier. Het model wordt stap voor stap opgebouwd en er kan dus veel meer genuanceerd en eigen interpretatie gelegd worden in het model. We kunnen dan ook echt spreken van een modelleertaal. Dat heeft als gevolg dat de organisatie van de capabilities en de structuur veel minder vastligt dan bij de vorige modellen. We hebben meer vrijheid in de organisatie van de capability map. De manier waarop structuur wordt gebracht kan vrij worden gekozen door

de

gebruiker.

Deze

structuur

zal

echter

vaak

gebaseerd

zijn

op

industriestandaarden of op de organisatiestructuur. Deze structuur zal dan worden gebruikt om de bibliotheek op te bouwen.

3.6.4


In VDML vinden we naast het gewone concept capability ook de concepten capability offer en capability method. De capabilities die we hebben gedefinieerd zitten in de bibliotheek en we kunnen deze gebruiken indien we dat nodig achten. Organisatorische 59

eenheden binnen een bedrijf kunnen een capability offer aanbieden om een bepaalde capability te leveren. Er kunnen dus meerder instanties in een bedrijf zijn die dezelfde capability aanbieden op een andere of dezelfde manier. Deze zullen hetzij ad hoc worden uitgevoerd door de unit of ze kunnen een capability method voorstellen. Een capability method is “een herbruikbaar sjabloon voor een collaboratie, geconfigureerd voor deelnemers om activiteiten uit te voeren die nodig zijn om een capability te leveren en om bij te dragen tot de waarde in een specifieke situatie” (de Man, Berre, 2012, p.115). Een capability method ontstaat doordat er een patroon ontstaat van activiteiten binnen een collaboratie. We kunnen een capability method deels vergelijken met een proces. Het grote verschil is dat we bij een capability method meer aandacht besteden aan statistische aspecten van bijvoorbeeld activiteiten, de stroom van te leveren resultaten, contributie aan waarde. In plaats van dus te kijken naar de uitzonderingen en mechanismen die daarmee gepaard gaan kijken we eerder naar het grote geheel en we krijgen dus een abstracter beeld van wat het bedrijf doet, hoe het iets doet en wie verantwoordelijk is. (Cordys en CSC, 2012) Het doel van een bepaalde capability method is het ondersteunen van een capability offer wiens doel is beschreven aan de hand van de definitie van de capability die deze offer ondersteunt, die we vinden in de bibliotheek. Deze omschrijving in de bibliotheek omvat wat er precies gebeurt. De capability

in de bibliotheek heeft gerelateerde typen

middelen, inputs/outputs, technologieën,… . Maar deze elementen worden niet afgedwongen in een capability offer, ze dienen eerder als leidraad. Het is pas in de capability offers dat we te weten komen welke middelen er effectief zullen worden ingezet. In vergelijking met de vorige modellen is deze beschrijving eerder karig maar we moeten wel onthouden dat het standpunt van waaruit we werken verschilt.

3.6.5


3.6.5.1 Capability taxonomie We hebben al veel nieuwe concepten leren kennen maar de essentiële vraag binnen deze masterproef blijft toch hoe we capabilities moeten modelleren. Figuur 3.14

geeft een voorbeeld van hoe een typische taxonomie eruit ziet binnen VDML.

Deze gestandaardiseerde capabilities maken het gemakkelijker om te vergelijken met andere bedrijven. Zoals gezegd is er wel structuur binnen de map maar is deze minder uitgesproken dan in de vorige modellen. Aangezien het ultieme doel van een bedrijf 60

waardecreatie is en VDML zich deels baseert op value chains zal het waarschijnlijk voorkomen dat de structuur grotendeels gebaseerd is op deze waardeketen.

Figuur 3.14 voorbeeld capability taxonomie in VDML (de Man, Berre, 2012)

Deze taxonomie in relatie met een analyse van de toegevoegde waarde die een capability biedt stelt ons in staat om gebruik te maken van heat mapping. Opnieuw kunnen we zo bepalen welke capabilities moeten worden verbeterd of welke er eventueel geoutsourcet kunnen worden. 3.6.5.2 Capabilities in combinatie met andere concepten Naast de taxonomie waarbij we definities hebben van capabilities kunnen we ook kijken hoe we capabilities in relatie met andere concepten zien binnen VDML. Binnen een bedrijf vinden we departementen die bepaalde capabilities bezitten. Als voorbeeld zien we een Sales & Delivery departement die enkele van de capabilities bezitten die in Figuur 3.14 zijn weergegeven.

In Figuur 3.15 zien we dat de capability offer Fulfillment Management (de groene zeshoek) wordt geïmplementeerd door een capability method (de blauwe rechthoek). Binnen Fulfillment Management vinden we twee andere, meer gedetailleerde capabilities, namelijk Fulfillment Planning en Product Delivery. Dat zien we door de stippellijntjes die de method met de offers verbindt.

61

Figuur 3.15 Capabilities binnen het S&D departement (de Man, Berre, 2012)

3.6.6 DOELPUBLIEK Het doel van VDML is “om een abstractie te maken van de operaties van een onderneming die geschikt is voor bedrijfsleiders. Daarenboven biedt het ook de mogelijkheid om ondersteunende details weer te geven die voor de business analist interessant zijn. Aldus linkt VDML de activiteiten en capabilities die de onderneming draaiende houden met de bestuursorganen.” (Cordys en CSC, 2012, p.25) Het is dus duidelijk dat het doelpubliek van deze modellen niet alleen business analisten zijn, maar ook de bedrijfsleiders. De sterkte van deze modelleertaal is namelijk dat ze een link biedt tussen het enerzijds abstractere van doelen, objectieven, waardecreatie dat zich afspeelt binnen de bestuurskamer en anderzijds de meer concrete activiteiten en middelen. Het concept om de link tussen beiden te maken is opnieuw dat van de capability.

3.7 CONCLUSIE We hebben een overzicht gemaakt van de verschillende modellen die er zijn om capabilities te modelleren. We zijn gestart met een algemeen model van Scott et al. (2010) dat we verder hebben gebruikt als raamwerk om de overige modellen mee te beschrijven. Deze vier modellen zijn het Microsoft Services Business Architecture, het Component Business Model van IBM, een visualisatiemodel van Klinkmüller et al. en VDML. Voor elk van deze modellen hebben we gekeken hoe deze capabilities opvatten en beschrijven en hoe ze worden weergegeven op een bevattelijke manier. 62

DEEL 2: MODELLEREN VAN CAPABILITIES IN EEN GEVALLENSTUDIE 4 GEVALLENSTUDIE 4.1 INLEIDING In het vorige hoofdstuk hebben we enkele modellen bekeken die kunnen gebruikt worden om capabilities te modelleren. We zijn gestart met een algemeen model dat eerder bestond uit algemene richtlijnen en principes die best worden gevolgd. Vervolgens hebben we het model van Microsoft bekeken dat gebaseerd is op de implementatie van service georiënteerde ondernemingen. Ten derde hebben we het Component Business Model van IBM onder de loep genomen. Dit model modelleert componenten en heeft als doel om gebruikt te worden door de beleidsmakers om strategische beslissingen te nemen. Vervolgens hebben we gekeken naar hoe we capabilities gemakkelijk visueel kunnen voorstellen aan de hand van een hemisfeer, ontwikkeld door Klinkmüller et al. Ten slotte hebben we onderzocht op welke manier capabilities hun plaats vinden binnen de nieuw ontwikkelde taal VDML. Hierin staat waardecreatie centraal en worden capabilities gebruikt om de activiteiten die waarde creëren te kunnen uitvoeren. In dit hoofdstuk verlaten we even de modellen zelf en wordt het bedrijf geïntroduceerd dat zal worden gebruikt in de gevallenstudie. Ten eerste zullen we het bedrijf leren kennen en de operaties die ze uitvoeren. In een tweede deel zal dit meer gestructureerd worden weergegeven aan de hand van het Business Motivation Model. Met behulp van dit model kunnen we onderzoeken hoe capabilitymodellen het hiaat opvullen tussen strategische aspecten en de meer operationele aspecten zoals services en processen. In het volgende hoofdstuk zullen we dan elk van de beschreven modellen toepassen op deze case en aan de hand van criteria zullen we dan een objectieve evaluatie maken.

4.2 AB INBEV: EEN VOORSTELLING Als bedrijf voor de gevallenstudie zullen we ons baseren op AB InBev. Deze multinational met Belgische wortels is door zijn bekendheid een perfect bedrijf om te 63

evalueren wat de sterktes en zwaktes zijn van de verschillende capabilitymodellen. Aangezien deze gevallenstudie ter illustratie dient zullen we enkele elementen vereenvoudigd voorstellen om het modelleren te vergemakkelijken.

4.2.1 WAT DOEN ZE? Alvorens we kijken naar de strategie en de doelstellingen, is het belangrijk om te weten wat ze precies doen. AB InBev is een producent van bier en is dus werkzaam binnen de zogenaamde consumptiegoederen. In essentie bestaat hun business uit twee grote blokken. Ten eerste produceren ze een grote hoeveelheid aan verschillende bieren. Ten tweede verkopen en distribueren ze deze bieren naar hun klanten. Ter ondersteuning van deze twee grote blokken houden ze zich ook bezig met R&D en met de wereldwijde integratie van hun operaties. We bekijken nu elk van deze elementen in meer detail. 4.2.1.1 Productie van bier Het eerste grote blok dat AB InBev als business heeft is het produceren van bier. Ze produceren niet één enkel bier in één fabriek maar ze produceren verschillende bieren in verschillende fabrieken wereldwijd. Zo zijn er in België alleen al vier fabrieken waar tientallen bieren en varianten worden gebrouwen. Het proces binnen AB InBev begint bij de aankoop van grondstoffen voor het bier en andere materialen (vb. voor verpakking, …) Dat is een zeer belangrijk element binnen AB InBev want de kwaliteit van het bier wordt grotendeels bepaald door de kwaliteit van de grondstoffen. Vervolgens wordt het bier gebrouwen, gebotteld en opgeslagen, klaar voor vervoer naar de klanten. Uiteraard dienen de nodige kwaliteitscontroles uitgevoerd. Verder moeten we ook aanstippen dat dit hele proces wordt aangestuurd vanuit de vraag die er zal zijn. De juiste grondstoffen moeten worden aangekocht zodat op het juiste moment een juiste hoeveelheid merk van bier kan geproduceerd worden om aan de marktvraag te voldoen. De productie van bier staat dus niet los van de verkoop en distributie van bier. 4.2.1.2 Verkoop en distributie van bier Eens het bier is gebrouwen dient het nog te worden verkocht. In deze vereenvoudigde gevallenstudie gaan we ervan uit dat AB InBev zijn bier enkel en alleen verkoopt aan retailers6 die het op hun beurt weer verkopen aan zowel particulieren als bedrijven uit de horecasector. Aangezien ze werken met andere grote bedrijven is het voor AB InBev

Bij de retailers beschouwen we zowel de grote distributeurs zoals Colruyt, Delhaize, … als de onafhankelijke brouwers. 6

64

belangrijk om goede relaties te onderhouden met hun klanten en met potentiële klanten. Een grote drijver van verkoop is prijs en kwaliteit en dus zal AB InBev zijn prijspolitiek goed in de hand moeten houden. Uiteraard is de eindgebruiker diegene die de vraag zal drijven en dus dient AB InBev naast de relaties met de klanten ook de eindgebruiker toe te spreken. Dat gebeurt aan de hand van marketingcampagnes. De productie wordt grotendeels bepaald door wat de toekomstige vraag zal zijn dus men moet deze vraag zo goed mogelijk proberen voorspellen. Eens de verkoop is gesloten met de retailers, dient het bier nog gedistribueerd te worden naar de klant. Aangezien AB InBev actief is in verschillende landen en verschillende fabrieken heeft, is deze organisatie niet eenvoudig. Om de kwaliteit te onderhouden dient deze distributie zo gestroomlijnd mogelijk te verlopen. 4.2.1.3 R&D binnen AB InBev Zoals reeds gezegd bestaat het gamma van AB InBev uit meer dan 200 verschillende merken geproduceerd in 23 verschillende landen in 141 verschillende fabrieken. Het lijkt logisch dat niet in elk land dezelfde smaken worden geapprecieerd en dat binnen een bepaalde markt met vernieuwende producten moet introduceren om de groei van het bedrijf te onderhouden. Hiervoor heeft AB InBev een uitgebreide R&D-cel die onderzoekt welke variaties van bier kunnen aanslaan, welke bieren hun beste jaren hebben gehad en welke nieuwe bierconcepten een marktsucces kunnen worden. 4.2.1.4 Wereldwijde organisatie Aangezien AB InBev een wereldspeler is, is het niet verwonderlijk dat er veel aandacht en energie moet worden gestoken in de globale integratie van het bedrijf. Het gaat niet enkel over de operaties en het financiële aspect maar zeker ook over de cultuur van het bedrijf, over de mensen en over globale projecten. Door de wereldwijde scope van het bedrijf dienen de verschillende departementen en business units op elkaar afgestemd te worden.

4.2.2 VISIE, MISSIE EN STRATEGIE Nu we een idee hebben over de scope van hun business is het interessant om te kijken wat hun visie, missie en strategie is. Dat zijn immers de concepten die op het hoogste niveau worden bepaald. Thompson et al. (2011) definiëren deze concepten als volgt:

65

-

Visie: “Een visie beschrijft de aspiraties van het management voor de toekomst en omschrijft de strategische koers van het bedrijf en de lange termijn richting” (Thompson et al., 2011, p.71)

-

Missie: “Een missie beschrijft het doel en de huidige business van het bedrijf – wie zijn we, wat doen we, waarom zijn we hier?” (Thompson et al., 2011, p.74)

-

Strategie: “Een strategie bestaat uit de competitieve bewegingen en business aanpakken die managers gebruiken om succesvol te concurreren, de prestaties te verbeteren en de business te laten groeien.” (Thompson et al. 2011, p.52)

4.2.2.1 Visie De visie van AB InBev die we kunnen lezen in het jaarverslag van 2012 luidt als volgt: “Bij AB InBev koesteren we de droom om het beste bierbedrijf in een betere wereld te zijn” We vinden hierin twee grote dromen terug. Ten eerste willen ze het beste bierbedrijf zijn en ten tweede willen ze dat zijn in een betere wereld. Het eerste deel – het beste bierbedrijf zijn – is van operationele aard en vertaalt zich in doelen zoals meer verkoop, hogere winst, kosten drukken,… Het tweede deel over de betere wereld heeft een eerder maatschappelijk aspect. AB InBev wil iets terugdoen voor de maatschappij waarin ze opereert. Hiervoor hebben ze enkele punten opgesteld die ze willen bereiken om een betere wereld te creëren. Ten eerste willen ze verantwoorde consumptie promoten. AB InBev is er zich goed van bewust dat ze alcoholhoudende dranken produceren en daarom willen ze sterk inzetten op dit punt. Zo was AB InBev de drijvende kracht achter de BOB-campagne (AB InBev, 2011). Ten tweede willen ze het milieu beschermen. Dat doen ze door minder grondstoffen te verspillen, door minder water te verbruiken bij het productieproces, door verpakkingen te recycleren, … Ten slotte willen ze iets teruggeven aan de maatschappij waarin ze wonen en werken. Dat doen ze door allerlei ontwikkelingsprojecten op poten te stellen. 4.2.2.2 Missie AB InBev heeft geen welafgelijnde missie maar we vinden wel drie kernelementen die omschrijven wat ze doen en hoe ze gekomen zijn op de plaats waar ze nu staan.

66

Het succes van AB InBev is grotendeels gebaseerd op innovatie. Deze innovatie is niet enkel nieuwe producten ontwikkelen maar ook efficiënter bier produceren of betere klantenrelaties uitbouwen. Doordat AB InBev innovatief is en betere producten en diensten kan bieden kan het zichzelf profileren als een bedrijf dat premium bieren produceert. Verder steunt AB InBev zeer sterk op zijn mensen. Werknemers van AB InBev hebben allen hun neuzen in dezelfde richting en iedereen werkt volgens de sterke bedrijfscultuur die er heerst. Doordat ze de beste mensen rekruteren en ontwikkelen, zijn ze succesvol gebleken in het verleden. Ten slotte is een heel belangrijke hoeksteen van hun succes hun financiële discipline. Vele bedrijven kunnen innovatief zijn en een sterke bedrijfscultuur hebben met goede mensen. Maar er zijn maar weinigen die dat ook combineren met een sterke financiële discipline. Doordat ze elk jaar opnieuw die financiële discipline aan de dag konden leggen, kunnen ze elk jaar opnieuw betere resultaten voorleggen. 4.2.2.3 Strategie Steunend op de drie elementen uit de missie baseert AB InBev zich op vier volgende pilaren om hun strategie te verklaren. -

AB InBev haalt zijn resultaten met behulp van een sterk merkenportfolio. Door de grote verscheidenheid aan merken en producten heeft AB InBev een sterke reputatie.

-

AB InBev zet sterk in op het halen van resultaten aan de Point of Connection (POC). Door goede relaties met de klanten te onderhouden staan ze sterk.

-

AB InBev opereert met het doel om efficiënt te zijn op wereldklassenniveau. Een groot deel van de groeiende winst is door elk jaar efficiënter en efficiënter te werken.

-

AB InBev vergroot zijn verkoopscijfer door extern te groeien. Zelf al zitten ze in gesatureerde markten, zullen ze toch nog groeien door externe bedrijven over te kopen en nieuwe markten aan te boren.

67

4.3 AB INBEV: BUSINESS MOTIVATION MODEL We kunnen deze aspecten nu modelleren met behulp van het Business Motivation Model uitgebracht door de Business Rules Group. Zij definiëren het Business Motivation Model als “een schema voor het ontwikkelen, communiceren en beheren van business plannen op een georganiseerde manier.” (Business Rules Group, 2010, p.1) We kunnen dus met behulp van dit model het business plan van AB InBev op een gestructureerde manier weergeven. In een volgende stap kunnen we dan kijken hoe we het Business Motivation Model en elementen daaruit kunnen linken met concepten uit de capabilitymodellen. In Bijlage A zien we het metamodel van het Business Motivation Model maar voor deze gevallenstudie zullen we ons vooral focussen op de meer high-level elementen uit dit model. We willen immers weten hoe we operationele concepten zoals processen en services gemakkelijk kunnen linken aan strategische concepten zoals visie, missie, strategie, doelen. MEANS Missie AB InBev wil succesvol zijn voor alle stakeholders door innovatief te zijn op verschillende aspecten. Dat kunnen ze doen door de beste mensen te rekruteren en deze te ontwikkelen. Verder steunen ze bij AB InBev op een sterke financiële discipline om positieve resultaten te halen.

END Visie

AB InBev heeft als droom om het beste bierbedrijf in een betere wereld te zijn

Strategie - Het onderhouden van een sterk merkenportfolio

Doelen - groei van volume boven het industriegemiddelde

- Goede relaties onderhouden met de klanten aan Point of Connection

- groei van winst sneller dan de groei van volumes

- Effeciënte processen hebben op wereldklassenniveau

- sterke discipline behouden en kosten onder inflatie blijven

- groei stimuleren door extern te groeien

- verantwoorde consumptie promoten - het milieu beschermen - iets teruggeven aan gemeenschappen waar we wonen en werken

Figuur 4.1 BMM voor AB InBev

68

4.4 CONCLUSIE We hebben nu een goed beeld van de operaties en de business waarin AB InBev opereert. Met behulp van deze gegevens kunnen we in het volgende hoofdstuk de capabilities van AB InBev modelleren. We hebben deze gegevens vervolgens ook gestandaardiseerd in een vereenvoudigde versie van het Business Motivation Model. Met behulp van dit model kunnen we dan immers zien hoe de verschillende capabilities modellen zich relateren met dit Business Motivation Model.

69

5 TOEPASSING VAN MODELLEN OP GEVALLENSTUDIE 5.1 INLEIDING In het vorige hoofdstuk hebben we kennis gemaakt met AB InBev, het bedrijf waarvan we aan de hand van de modellen uit hoofdstuk drie, de capabilities gaan modelleren. Alvorens we beginnen met modelleren, is het belangrijk dat we eerst duidelijke criteria opstellen waaraan elk model moet voldoen. Aldus kunnen we een objectieve analyse maken waarin we de sterktes en zwaktes van elke methode kunnen weervinden.

5.2 CRITERIA VOOR EEN CAPABILITYMODEL Aangezien we een objectieve vergelijking willen maken van elk van de vier modellen is het nodig om objectieve criteria op te stellen. Deze criteria moeten bevatten waaraan een goed capabilitymodel moet voldoen. Voor elk van de modellen zullen we dan bepalen op welke manier ze een criterium al dan niet vervullen. We kunnen dan ten slotte een overzicht krijgen van elk van de modellen met de criteria. Volgende lijst geeft de criteria die gebruikt zullen worden: -

Omschrijving wat de capability doet: elke capability moet omschreven worden zodat duidelijk is wat de capability bereikt als deze wordt aangewend. (Scott et al. 2010)

-

Service level: het prestatieniveau dat moet worden bereikt moet duidelijk worden bepaald. (Homann, 2006)

-

Inkapseling van mensen, processen en procedures, technologie: het moet duidelijk zijn welke van deze elementen de capability bezit en dus kunnen worden aangewend om het resultaat te behalen. (Homann, 2006) (Freitag et al., 2011)

-

De interacties tussen verschillende capabilities moet worden bepaald: we weten uit hoofdstuk twee dat capabilities zowel verticaal als horizontaal met elkaar verbonden zijn. (Homann, 2006)(Freitag et al., 2011)

70

-

De eigenaar van een capability moet worden vastgesteld: we moeten weten wie de eigenaar is van een capability en wie dus de eindverantwoordelijkheid draagt. (Homann, 2006)

-

Attributen van een capability: een van de sterktes van capabilitymodellen is dat we de verschillende capabilities kunnen vergelijken met behulp van attributen. (Homann, 2006) (Klinkmüller et al., 2010)

-

Visualisatie van de capabilities: om eenvoudig te gebruiken moeten deze capabilities op een eenvoudige manier kunnen worden voorgesteld zodat we met behulp van bijvoorbeeld heat maps een snelle analyse kunnen uitvoeren

-

Ondersteuning van tools: Aansluitend op het vorige punt is het belangrijk dat er tools beschikbaar zijn die kunnen worden gebruikt. Indien we een goed werkbare tool hebben voor een model, zal dit model sneller in gebruik genomen worden.

5.3 CAPABILITIES VAN AB INBEV VOLGENS MICROSOFT Microsoft start bij het modelleren van capabilities altijd van een generieke lijst van capabilities die voor 80% de business bestrijkt. Daarin zijn ze nog een stukje verder gegaan door sectorspecifieke lijsten van capabilities op te stellen. Aldus kunnen ze door hier en daar wijzigingen door te voeren, heel snel een capability map hebben van het bedrijf. Hetgeen dan nog moet gebeuren is de karakteristieken van deze capabilities bepalen binnen het bedrijf zelf. Voor deze gevallenstudie starten we met een generieke lijst van capabilities die niet specifiek voor de consumptiegoederenindustrie is (zie Bijlage B). Alle capabilities op deze lijst worden afgegaan en we kijken vervolgens of deze capabilities aanwezig zijn in het bedrijf en of er capabilities zijn die ontbreken in een bepaalde capabilities groep. Hierbij is het belangrijk dat alle operaties vertegenwoordigd zijn volgens het MECEprincipe. Om deze oefening op een goede manier te volbrengen is het daarom belangrijk om de business goed te kennen en indien nodig samen te werken met iemand die de business goed kent. Verder passen we de naamgeving aan zodat deze in lijn is met wat AB InBev doet. Zo is het duidelijker als we een capability Brouw Bier hebben in plaats van Produceer Product.

71

We bekomen uiteindelijk Tabel 5.1 waar we een volledige lijst van capabilities hebben tot drie niveaus diep. Deze tabel kan nog verder worden uitgediept indien nodig maar we vinden op het derde niveau al 56 capabilities. Voor deze eenvoudige gevallenstudie is dat al ruim voldoende. 1.0 Ontwikkel Product 1.1 Ontwikkel Product 1.1.1 Ontwikkel Concept en Plannen Nieuw Product 1.1.2 Design Nieuw Product en Processen 1.1.3 Beheer Bestaand Product 1.1.4 Lanceer Nieuw Product 1.1.5 Trek Bestaand Product terug 2.0 Creëer Vraag (CRM) 2.1 Beheer Partner Relaties 2.1.1 Kanaal Beheer 2.2 Marketing 2.2.1 Marketing Beheer 2.2.2 Business Intelligence voor Marketing 2.3 Verkoop 2.3.1 Order Beheer 2.3.2 Verkoop Beheer 2.3.3 Configuratie en Validatie Prijs 2.3.4 Contract Beheer 2.3.5 Kwalificeer Prospecten 2.3.6 Business Intelligence voor Verkoop 3.0 Lever Product 3.1 Plan LT Uitvoering 3.1.1 Planning van Vraag 3.1.2 Planning van Aanbod 3.1.3 Planning van Voorraad 3.1.4 Productie Schema Opstellen 3.2 Onderhoud Business Intelligence 3.2.1 Vervul Analyse van Vraag 3.3 Aankoop 3.3.1 Beheer Leveranciers 3.3.2 Aankopen van Grondstoffen 3.3.3 Ontvangen van Grondstoffen 3.4 Produceer Product 3.4.1 Brouw Bier 3.4.2 Bottel Bier 3.4.3 Kwaliteitscontrole 3.5 Lever Bier 3.5.1 Order Vervulling

72

3.5.2 Beheer Transport 3.5.3 Beheer Voorraad 3.5.4 Beheer Magazijnen 4.0 Plan en Beheer Onderneming (ERP) 4.1 Financieel Beheer 4.1.1 Beheer AP 4.1.2 Beheer Treasury 4.1.3 Beheer Handelsvorderingen 4.1.4 Verwerk Elektronische Betalingen 4.1.5 Budgetteer 4.1.6 Beheer Grootboek 4.1.7 Beheer Kapitaal 4.1.8 Business Intelligence voor Financieel Beheer 4.2 Project Beheer 4.2.1 Beheer Project 4.2.2 Project Accounting 4.2.3 Business Intelligence 4.3 Beheer Human Resources 4.3.1 Beheer Tijd en Uitgaven 4.3.2 Betaal Werknemers Uit 4.3.3 Administratie van Voordelen (Benefits) 4.3.4 Beheer Personeel 4.3.5 Business Intelligence voor HR 4.4 Beheer IT Diensten 4.4.1 Lever IT Gebaseerde Diensten 4.5 Beheer Cultuur en Bedrijfswaarden 4.5.1 Beheer Bedrijfswaarden 4.5.2 Stimuleer Cultuur 5.0 Beheer Samenwerking 5.1 Beheer Strategische Samenwerking 5.1.1 Beheer Partnering Strategie 5.1.2 Beheer en Plan Product/Dienst Concept 5.2 Beheer Cross-groep Planning 5.2.1 Design en Ontwikkel Producten en Processen 5.2.2 Beheer Policies 5.2.3 Beheer Vraag 5.2.4 Beheer Aanbod 5.3 Beheer Operaties 5.3.1 Beheer Visibiliteit Middelen 5.3.2 Beheer Visibiliteit Fulfillment Tabel 5.1 Capabilities van AB InBev (3 niveaus)

73

5.3.1 OMSCHRIJVING VAN DE CAPABILITIES Tijdens het opstellen van deze lijst is het belangrijk om data te verzamelen over deze capabilities die eventueel later nog nuttig kan blijken. Uiteraard is het allereerste wat moet worden gedaan, bepalen wat de capability nu juist doet. Binnen deze case zullen we verder werken met de foundation capability Lever Product en al de onderliggende capabilities aangezien het produceren van bier één van de twee grote pijlers is van de operaties van AB InBev. Volgende tabel geeft de omschrijvingen van wat elke capability of capability groep precies doet of wat het doel is. Capability

3.0 Lever Product

3.1 Plan LT Uitvoering

3.1.1 Planning van Vraag

3.1.2 Planning van Aanbod

3.1.3 Planning van Voorraad

3.1.4 Productie Schema Opstellen

Omschrijving De capability Lever Product bevat alle aspecten met betrekking tot de levering van het bier. Dit gaat zowel over de eigenlijke productie van het bier als alles wat daar voor nodig is zoals planning en aankoop van grondstoffen. Verder is ook het leveren van het bier aan de klant deel van deze capability. De Plan LT Uitvoering capability bevat alle aspecten betreffende de planning van de productie. Hierbij wordt rekening gehouden met zowel de vraag als het aanbod. Ook wordt gekeken naar huidige voorraden. Deze capability staat ook in voor het opstellen van een productieschema. Het doel van deze capability is het opstellen van de planning van de vraag. Dit is de vraag van de verschillende productlijnen. Met behulp van de capability Vervul Analyse van Vraag kan dit worden gedaan. Het doel van deze capability is het opstellen van het aanbod dat kan worden geleverd. Afhankelijk van bepaalde factoren (vb. grondstoffen) zal er een beperkt aanbod mogelijk zijn en deze capability plant dit in. Het doel van deze capability is het opstellen van een voorraadplanning. Gebaseerd op data verkregen van oa. Planning van Vraag kan een voorraadplanning worden opgesteld. Het doel van deze capability is het opstellen van het productieschema. Rekening houdend met de vraag, aanbod en voorraad kan een optimaal productieschema worden opgesteld.

3.2 Onderhoud Business Intelligence

De Onderhoud Business Intelligence capability vervult een ondersteunende rol binnen de Lever Product capability. Ze biedt business informatie aan met betrekking tot de vraag van het bier.

3.2.1 Vervul Analyse van Vraag

Het doel van deze capability is om een grondige analyse te maken van de toekomstige vraag. Dit zal een basis zijn voor de capability planning van vraag.

3.3 Aankoop

De Aankoop capability behandelt alle aspecten die nodig zijn bij de aankoop van goederen. Dit gaat zowel over de effectieve aankoop als het beheren van de leveranciers.

3.3.1 Beheer Leveranciers

Het doel van deze capability is om alle leveranciers die AB InBev heeft te beheren. Dit gaat zowel over het sluiten van nieuwe contracten als het vergelijken van alternatieve leveranciers.

74

3.3.2 Aankopen van Grondstoffen

3.3.3 Ontvangen van Grondstoffen

Het doel van deze capability is het aankopen van grondstoffen waar prijs/kwaliteit belangrijk is. De prijs/kwaliteit wordt bepaald door de keuze van leverancier. Bij de aankoop moet rekening worden gehouden met voorraden, productieschema's, … Het doel van deze capability is het afhandelen van de ontvangst van de grondstoffen. Naast het verwerken en opslaan van de grondstoffen is ook kwaliteitscontrole belangrijk.

3.4 Produceer Product

De capability Produceer Product omvat zowel het effectieve brouwen als het bottelen. Het uiteindelijke doel is het bekomen van een eindproduct met de juiste kwaliteit.

3.4.1 Brouw Bier

Het doel van deze capability is het effectief brouwen van het bier zelf. Hierbij moet rekening worden gehouden met de vraag, het aanbod, productieschema,… Het doel van deze capability is na het brouwen, het bier op de fles zetten. Hierbij komen ook aspecten als etikettering, … aan te pas. Het doel van deze capability is ervoor zorgen dat het bier en verpakking van goede kwaliteit is.

3.4.2 Bottel Bier 3.4.3 Kwaliteitscontrole

3.5 Lever Bier

De Lever Bier capability bevat alle aspecten die nodig zijn om het geproduceerde bier aan de klant te leveren. Daarbij wordt gekeken naar het transport maar ook naar de huidige voorraad bij klant en bij AB InBev zelf.

3.5.1 Order Vervulling

Het doel van deze capability is ervoor zorgen dat een klant de juiste producten zal krijgen op het juiste moment. 3.5.2 Beheer Transport Het doel van deze capability is het transport regelen in België en daarbuiten. De bedoeling is dat dit zo efficiënt mogelijk verloopt. 3.5.3 Beheer Voorraad Het doel van deze capability is het beheren van de voorraad gebottelde bieren. Bieren moeten in voorraad zijn om geleverd te kunnen worden. 3.5.4 Beheer Magazijnen Het doel van deze capability is om naast een algemeen voorraadbeheer ook een beheer van magazijnen te hebben zodat we precies weten waar welke hoeveelheid bier zit van welk merk. Verder worden ook paletten klaargezet voor vervoer naar de klant. Tabel 5.2 Omschrijving van capabilities binnen foundation capability Lever Product

We zien dat hoe dieper we in de hiërarchie gaan, hoe gedetailleerder de omschrijving is. Op het derde niveau kunnen we al vrij duidelijk bepalen wat de capability precies inhoudt. Belangrijk is om reeds in de omschrijving te zien welke capabilities met welke andere in interactie treden of kunnen treden.

5.3.2 BEPALEN VAN SERVICE LEVELS Nu we weten wat elke capability precies inhoudt en wat het doel is, kunnen we daar dieper op ingaan en bepalen welk service level moet worden behaald opdat die capability goed presteert. Dat zijn concrete maatstaven waarop capabilities kunnen geëvalueerd worden. Bij het opstellen van deze service levels kan het zeer nuttig zijn om te kijken naar de doelen (en eventueel objectieven) die werden gesteld rekening houdend met de visie. Zo weten we dat als AB InBev als doel heeft het milieu te beschermen, dat zich vertaalt in objectieven als het waterverbruik terugdringen, recycleren van flesjes, … We

75

moeten dat dan ook terugzien in de service levels die we opstellen. Deze elementen vinden we weer in het Business Motivation Model. Voor de AB InBev case bekijken we opnieuw de foundation capability Lever Product en alle capabilities die onder deze hiërarchie vallen. Capability 3.0 Lever Product

Service Level

3.1 Plan LT Uitvoering 3.1.1 Planning van Vraag 3.1.2 Planning van Aanbod 3.1.3 Planning van Voorraad


Tweewekelijks moeten we een forecast van de vraag hebben die een accuraatheid heeft van 80% Tweewekelijks moeten we een forecast van het aanbod hebben die een accuraatheid heeft van 90% We hebben een wekelijkse planning van de voorraad van grondstoffen en eindproducten waarbij er maximum 1 aankoopmoment per week is. Productieschema moet 1 week op voorhand klaar zijn waarbij er per week maximaal 2 verschillende bieren worden gebrouwen.

3.2 Onderhoud Business Intelligence 3.2.1 Vervul Analyse van Vraag

Vraaganalyse moet 3 dagen na een aanvraag klaar zijn

3.3 Aankoop 3.3.1 Beheer Leveranciers

3.3.2 Aankopen van Grondstoffen 3.3.3 Ontvangen van Grondstoffen

Leveranciersportfolio wordt beheerd waarbij elke 2 maanden een ranking wordt opgesteld van geprefereerde leveranciers gebaseerd op prijs/kwaliteit Grondstoffen worden aangekocht bij de leverancier met de beste prijs/kwaliteit gebaseerd op de ranking van leveranciers. Bij elk ontvangst van grondstoffen wordt een staaltje genomen en gecontroleerd op de kwaliteit. Indien deze inferieur is wordt de grondstof geweigerd.

3.4 Produceer Product 3.4.1 Brouw Bier 3.4.2 Bottel Bier 3.4.3 Kwaliteitscontrole

Bier wordt gebrouwen waarbij maar 3,5 Hl water per liter bier wordt verbruikt. Elke fles wordt gebotteld waarbij we 99% van de flesjes recycleren. Om de 2000 flesjes wordt een steekproef genomen waarbij de kwaliteit van het bottelen wordt gecontroleerd. Om de 10000 flesjes wordt het bier geanalyseerd op onzuiverheden.

3.5 Lever Bier 3.5.1 Order Vervulling 3.5.2 Beheer Transport 3.5.3 Beheer Voorraad 3.5.4 Beheer Magazijnen

90% van de orders moet binnen de week correct worden vervuld. Vrachtwagens moeten een capaciteit hebben van min 75% alvorens ze uitrijden. Ten allen tijde moet er twee weken voorraad beschikbaar zijn. Elk magazijn onderhoudt nog eens zijn eigen voorraad en maakt paletten klaar om te transporteren naar de klant. 95% van deze paletten moeten correct zijn.

Tabel 5.3 Service Levels van capabilities binnen foundation capability Lever Product

76

5.3.3 INKAPSELING VAN MENSEN, PROCESSEN EN TECHNOLOGIE De volgende stap is het linken van de middelen die gebruikt worden om de capability te implementeren. Zoals reeds meermaals gezegd is het niet de bedoeling dat we weten hoe deze met elkaar in interactie treden maar we willen wel een lijst van deze middelen die ingekapseld zitten in de capability. Indien we dan een capability willen verbeteren of meer IT ondersteuning geven, dan weten we ten minste bij wie we terecht moeten en welke processen beïnvloed zullen worden. We vinden volgende tabel. Capability 3.0 Lever Product 3.1 Plan LT Uitvoering

Mensen

Processen

Technologie


Planner; Sales Vertegenwoordiger; Business Analist Planner; Business Analist

Analyseer Marktrapporten; Stel Planning op; Analyseer vroegere Vraag

Spreadsheet; ERP

Stel Planning op

ERP

Planner

Stel Voorraadplanning op

ERP

Scheduler; Operations Manager

Stel Productieschema op; Wijzig productieschema; Onderzoek Beschikbaarheid Personeel

Manufacturing Planning System; ERP

Business analist

Verkrijg Marktrapporten; Voer Marktonderzoek uit

Markt Onderzoekstool ;

3.3.1 Beheer Leveranciers 3.3.2 Aankopen van Grondstoffen

Key Account Manager; Procurement Manager Procurement Manager

Evalueer Leveranciers; Onderhandel Voorwaarden; Beheer Contracten Bestel Grondstoffen; Kies Leverancier

CRM system


Procurement Manager

Ontvang Grondstoffen; Controleer Kwaliteit

3.4.1 Brouw Bier

Brouwmeester; Operations Manager

3.4.2 Bottel Bier

Brouwmeester; Operations Manager Quality Manager; Laborant

Controleer Brouwproces; Reinig apparatuur; Bepaal Grondstoffenmix; Verwissel Bier Reinig Flesjes; Bottel Bier; Etiketteer Flesjes Neem Steekproef; Controleer Botteling; Controleer Bier

3.1.2 Planning van Aanbod 3.1.3 Planning van Voorraad 3.1.4 Productie Schema Opstellen


3.3 Aankoop

Electronic Ordering System -


3.4.3 Kwaliteitscontrol e

Manufacturing System; Automatisch Vulsysteem -

3.5 Lever Bier

77


Sales Vertegenwoordiger; Operations Manager, Key Account Manager Operations Manager

Verwerk Orders

ERP

3.5.2 Beheer Bepaal Optimale Route; Beheer ERP; Route Transport Wagenpark; Systeem 3.5.3 Beheer Operations Manager; Tel Voorraad na; Geef Bestelorder ERP Voorraad Magazijnier 3.5.4 Beheer Operations Manager; Stel Palet samen; Verwerk Verouderde Magazijnen Magazijnier Producten Tabel 5.4 Mensen, processen en technologieën binnen foundation capability Lever Product

5.3.4 OMSCHRIJVING VAN INTERACTIES We hebben gezien dat de interacties (zowel verticaal als horizontaal) tussen capabilities een belangrijk element van de analyse zijn. Het is dus belangrijk om deze interacties in kaart te brengen. De verticale relaties worden heel duidelijk in kaart gebracht door Microsoft aangezien we met een hiërarchische structuur werken. Het nummer voor de capability duidt aan op welk niveau we ons bevinden en welke capability de ‘ouder’ is. De horizontale structuur zien we niet meteen op het eerste zicht terug. Homann en Tobey (2006) vonden drie vormen van horizontale connecties tussen capabilities:

Input/Output-

connecties, Ondersteunende connecties en Controle connecties. Opnieuw kijken we welke connecties we hebben in de foundation capability Lever Product. Zoals blijkt uit Tabel 5.5 is dat een vrij onoverzichtelijk overzicht. Zo zien we dat 3.1.1 Planning van Vraag hetzij een service opvraagt, hetzij levert aan 3.1.4 Productie Schema Opstellen. Maar in welke richting deze interactie gaat of welke service er wordt uitgewisseld is niet duidelijk. Op dit moment is het vooral de bedoeling om te weten welke capabilities kunnen worden beïnvloed als er wijzigingen worden doorgevoerd aan de implementatie van een bepaalde capability. Om echt goed weer te geven hoe de interacties verlopen hebben we nood aan een UML-achtige weergave. Wanneer we visualisatie bekijken (5.3.7) zal duidelijk blijken dat Microsoft geen vorm van UML gebruikt waardoor deze interacties toch deels verborgen blijven.

78

Capability Input/Output

Connecties Ondersteunend

Controle

3.0 Lever Product 3.1 Plan LT Uitvoering 3.1.1 Planning van Vraag

3.1.2 Planning van Aanbod 3.1.3 Planning van Voorraad


3.1.4 Productie Schema Opstellen; 3.2.1 Vervul Analyse van Vraag 3.3.3 Ontvangen van Grondstoffen 3.1.4 Productie Schema Opstellen; 3.5.3 Beheer Voorraad 3.1.1 Planning van Vraag; 3.1.3 Planning van Voorraad

3.4.1 Brouw Bier



3.3 Aankoop 3.3.1 Beheer Leveranciers 3.3.2 Aankopen van Grondstoffen 3.3.3 Ontvangen van Grondstoffen

3.3.2 Aankopen van Grondstoffen 3.3.1 Beheer Leveranciers 3.1.2 Planning van Aanbod

3.4 Produceer Product 3.4.1 Brouw Bier

3.4.2 Bottel Bier

3.4.2 Bottel Bier

3.4.1 Brouw Bier

3.4.3 Kwaliteitscontrole


3.4.3 Kwaliteitscontrole 3.4.3 Kwaliteitscontrole 3.4.1 Brouw Bier; 3.4.2 Bottel Bier

3.5 Lever Bier 3.5.1 Order Vervulling

3.5.4 Beheer 3.5.2 Beheer Magazijnen Transport 3.5.2 Beheer Transport 3.5.4 Beheer 3.5.1 Order Magazijnen Vervulling 3.5.3 Beheer Voorraad 3.1.3 Planning van Voorraad; 3.5.4 Beheer Magazijnen 3.5.4 Beheer Magazijnen 3.5.1 Order Vervulling; 3.5.2 Beheer Transport; 3.5.3 Beheer Voorraad Tabel 5.5 Interacties tussen capabilities binnen foundation capability Lever Product

5.3.5 BEPALEN VAN DE EIGENAAR Indien we na de analyse bepaalde capabilities meer IT ondersteuning willen geven, of willen outsourcen of een betere performance laten behalen, dan is het belangrijk dat we 79

weten wie de eigenaar is van die capability en dus wie we verantwoordelijk kunnen stellen voor de performance van een capability. Voor de foundation capability Lever Product en de onderliggende capabilities is dat vrij eenvoudig te bepalen. We zitten vooral in de operationele sfeer en dus de COO (Chief Operating Officer), Operations Manager en Procurement Manager zijn de voornaamste eigenaars van deze capabilities. Capability

Eigenaar

3.0 Lever Product

Chief Operating Officer


Planning Manager


Planning Manager


Planning Manager


Planning Manager


Planning Manager


Business Intelligence Manager


Business Intelligence Manager

3.3 Aankoop

Procurement Manager


Procurement Manager


Procurement Manager


Procurement Manager


Operations Manager

3.4.1 Brouw Bier

Operations Manager

3.4.2 Bottel Bier

Operations Manager


Operations Manager

3.5 Lever Bier

Operations Manager


Operations manager

3.5.2 Beheer Transport

Operations manager

3.5.3 Beheer Voorraad

Operations manager

3.5.4 Beheer Magazijnen

Operations manager

Tabel 5.6 Eigenaars van capabilities binnen foundation capability Lever Product

5.3.6 METEN VAN ATTRIBUTEN Een van de belangrijkste elementen bij het gebruik van capabilities is het bepalen en het meten van attributen. Met attributen bedoelen we bijvoorbeeld performance, IT ondersteuning, maar ook de reeds besproken elementen zoals eigenaar, SLE, … Microsoft beschouwt al deze element als attributen en het is aan de analist om te bepalen welke attributen hij wil opnemen. Aangezien we in 5.2 (Criteria voor een 80

capabilitymodel, p.70) als criterium hebben opgesteld dat deze elementen expliciet moeten gemodelleerd worden, nemen we deze apart in de analyse hier. Voor deze gevallenstudie bekijken we volgende attributen: Strategische waarde, Performance, Rijpheid en Verbondenheid met andere capabilities. Dat zijn ook de attributen die worden voorgesteld door Microsoft in hun handleiding voor heat mappen (Microsoft, 2006). Aan de hand van volgende vragen uit Figuur 5.1 kunnen we waarde bepalen voor deze attributen.

Figuur 5.1 Vragenlijst om attributen van capabilities te bepalen (Microsoft, 2006)

5.3.6.1 Strategische waarde Met Strategische waarde wordt hetzij bedoeld dat deze capability voor het bedrijf een belangrijke impact heeft of kan hebben op de performance, hetzij kan deze capability 81

ervoor zorgen dat het bedrijf zich kan differentiëren, hetzij dat verbeteren van de performance mogelijk is. Een hoge waarde betekent dus dat het interessant is om deze capability meer aandacht te geven dan anderen. Maar het is eveneens zeer belangrijk om goed te weten hoe die capability in elkaar zit want indien we een project starten waarbij er verandering plaatsvindt is dat een risicovol project indien we niet weten wat de gevolgen zullen zijn. Zo zien we in Tabel 5.7 (p.84) dat 3.4.1 Brouw Bier een hoge strategische waarde krijgt aangezien de kwaliteit van het bier hier wordt bepaald en dus de impact op het resultaat sterk kan beïnvloeden. Ook kan het bedrijf zich hier differentiëren door veel efficiënter te produceren dan anderen. Aan de andere kant hebben we 3.4.2 Bottel Bier dat een lage strategische waarde heeft aangezien deze capability weinig impact heeft op het uiteindelijke resultaat, ze zorgt voor weinig differentiatie en het verbeteren van performance is moeilijk. Dat wil evenwel niet zeggen dat we geen aandacht moeten besteden aan 3.4.2 Bottel Bier, maar zolang deze capability naar behoren presteert zijn we enkel geïnteresseerd in projecten die hetzij de kost verlagen hetzij het risico verlagen. Bij het bepalen van de strategische waarde is het zeer belangrijk dat de juiste informatie wordt geïncorporeerd. Hier kan het Business Motivation Model een rol spelen. Aangezien we daarin zien wat de strategie is van AB InBev en wat de doelen zijn, kunnen we die doelen en strategie linken aan de overeenkomstige capabilities. Zo zien we in Figuur 4.1

(p.68) dat AB InBev de strategie heeft om efficiënte processen te hebben op

wereldklassenniveau en dat er een doel is om de kosten onder de inflatie te houden. Aangezien de capability 3.4.1 Brouw Bier vrij belangrijke en kostelijke processen bevat, moeten we duidelijk terugvinden dat deze capability een zeer hoge strategische waarde heeft. Voor elk van de capabilities kijken we dus of er een relatie is met het Business Motivation Model. 5.3.6.2 Performance Een lage score in performance betekent dat er problemen zijn met performance of dat we de drijvers achter de performance niet kennen en dus ook niet kunnen meten. Dat is dus een teken dat we ons meer moeten focussen op deze capability, zeker als een lage performance samengaat met een hoge strategische waarde. Zo zien we in Tabel 5.7 p.84 dat 3.1.1 Planning van Vraag een lage performance heeft maar wel een hoge strategische waarde. Dat wil dus zeggen dat het service level niet wordt 82

bereikt terwijl het wel een zeer belangrijke capability is voor het succes van het bedrijf. Deze capability zal dus een geschikte kandidaat zijn om in te investeren. Het tegenovergestelde zien we ook bij 3.4.2 Bottel Bier. Deze capability presteert zeer goed maar heeft een lage strategische waarde. Er moet uiteraard moeite gedaan worden om deze situatie te behouden maar heel veel focus moet hier niet op worden gelegd. 5.3.6.3 Rijpheid Met rijpheid wordt het gebruik van IT in de capability gemeten alsook de rijpheid van de capability zelf. Een capability is IT rijp indien er gesofisticeerde software wordt gebruikt (ERP, business application software, …) en is niet rijp indien er nog gebruik wordt gemaakt van eenvoudige faxen, e-mail, spreadsheets, … Verder is de capability in het algemeen rijp indien de uitkomst voorspelbaar is. Zo is een capability Ontwikkel Nieuw Product veel meer onvoorspelbaar dan een capability Betaal Werknemers Uit. Afhankelijk van de score kunnen we meer focus leggen op bepaalde capabilities. Indien een capability een lage rijpheid heeft, samen met hoge strategische waarde, dan is er waarschijnlijk nood aan meer aandacht zodat we die capability meer voorspelbaar kunnen maken en beter kunnen ondersteunen met IT. Een capability met een hoge score voor rijpheid is een uitstekende kandidaat voor proces standaardisatie. Zo is 3.1.1 Planning van Vraag niet echt rijp aangezien veel nog wordt gedaan met een spreadsheet. Dat is evenwel een capability met een hoge strategische waarde. 5.3.6.4 Verbondenheid met andere capabilities Een laatste attribuut dat we bekijken is de verbondenheid met andere capabilities. Hoe hoger deze waarde, hoe meer verbonden die capability is met andere capabilities en hoe moeilijker het dus is om deze capability bijvoorbeeld te outsourcen. Indien er een lage verbondenheid is en dat wordt gecombineerd met bijvoorbeeld lage strategische waarde of lage performance, dan zal deze capability kandidaat nummer één zijn voor te outsourcen. Typische capabilities die een lage verbondenheid met een lage strategische waarde combineren zijn Betaal Werknemers Uit of Beheer Personeel. Ook Beheer Transport is vaak een capability die wordt geoutsourcet, maar in het geval van AB InBev is deze capability wel van strategisch belang.

83

5.3.6.5 Capabilities binnen Lever Product met attributen Tabel 5.7 geeft nog eens een overzicht van alle capabilities binnen de foundation capability Lever Product, elk met hun waarde voor de vier attributen. Capability Strategische waarde

Attributen Performance Rijpheid

3.0 Lever Product

Hoog

Gemiddeld

Hoog

Verbondheid met andere capabilities Gemiddeld


Hoog

Gemiddeld

Hoog

Gemiddeld


Hoog

Laag

Gemiddeld

Gemiddeld


Laag

Gemiddeld

Hoog

Laag


Hoog

Gemiddeld

Hoog

Gemiddeld


Gemiddeld

Gemiddeld

Hoog

Hoog


Laag

Gemiddeld

Laag

Laag


Laag

Gemiddeld

Laag

Laag

3.3 Aankoop

Hoog

Hoog

Hoog

Laag


Hoog

Hoog

Hoog

Laag


Hoog

Hoog

Hoog

Laag


Gemiddeld

Gemiddeld

Gemiddeld

Laag


Hoog

Hoog

Hoog

Gemiddeld

3.4.1 Brouw Bier

Zeer Hoog

Hoog

Zeer Hoog

Hoog

3.4.2 Bottel Bier

Laag

Hoog

Hoog

Gemiddeld


Gemiddeld

Zeer hoog

Hoog

Laag

3.5 Lever Bier

Hoog

Gemiddeld

Gemiddeld

Gemiddeld


Zeer Hoog

Gemiddeld

Gemiddeld

Gemiddeld

3.5.2 Beheer Transport

Hoog

Gemiddeld

Hoog

Gemiddeld

3.5.3 Beheer Voorraad

Hoog

Laag

Hoog

Gemiddeld

3.5.4 Beheer Magazijnen

Laag

Laag

Laag

Gemiddeld

Tabel 5.7 Attributen van capabilities binnen foundation capability Lever Product

5.3.7 VISUALISATIE EN HEAT MAPS Voor de vorige elementen die capabilities beschrijven hebben we tabellen gebruikt. Dat heeft als voordeel dat er veel informatie instaat maar vaak hebben we nood aan een eenvoudige weergave waarbij we snel de meest belangrijke elementen kunnen zien. Met behulp van heat maps kunnen we alle capabilities op een blad krijgen en twee verschillende attributen meten. Aldus zien we in een oogopslag welke capabilities meer aandacht vereisen en waar we aandacht op moeten vestigen. In 2.3 Toepassingen van

84

capabilities modellen (p.21) zagen we welke toepassingen we hebben om deze heat maps mee te gebruiken. In Figuur 5.2 (p.88) zien we een heat map voor alle capabilities van AB InBev tot het derde niveau. Hierop zien we twee attributen gemeten. Enerzijds zien we de strategische waarde (de kleur binnen de capability) en anderzijds zien we de performance (de rand van de capability). Met behulp van deze heat map zien we meteen welke capabilities er aandacht vereisen (hoge strategische waarde en/of lage performance) en welke capabilities eventueel in aanmerking kunnen komen om te worden geoutsourcet (lage strategische waarde). Ook kunnen we oplijsten welke projecten er mogelijk kunnen worden uitgevoerd en of we deze kunnen stroomlijnen. We overlopen nu elk van de foundation capabilities en kijken welke conclusies we kunnen trekken. 5.3.7.1 Ontwikkel Product We zien dat de strategische waarde van de capabilities die we hierin terugvinden niet zo hoog is. Dat ligt ook volledig in lijn met de strategie van AB InBev om te groeien door nieuwe markten aan te boren en niet echt door nieuwe producten op de markt te brengen. Dat wil evenwel niet zeggen dat deze capabilities verwaarloosd mogen worden. De service levels moeten nog steeds behaald worden dus voor 1.1.5 Trek Bestaand Product terug zal moeten gekeken worden hoe de performance kan stijgen. 5.3.7.2 Creëer Vraag Elk van de capabilities binnen Creëer Vraag heeft een gemiddelde tot zeer hoge strategische waarde. Maar we zien ook meteen dat de meeste capabilities een hoge performance hebben. Dat is dus een positief beeld dat we zien. Desalniettemin zien we voor 2.2.1 Marketing Beheer dat deze capability een zeer hoge strategische waarde heeft maar niet zo goed presteert. Projecten die invloed hebben op deze capability zullen dus met meer drang moeten worden uitgevoerd. 5.3.7.3 Lever Product Binnen Lever Product zien we enkele capabilities met een hoge strategische waarde en twee met een zeer hoge strategische waarde. Het brouwen van het bier en het vervullen van de orders zijn twee belangrijke elementen in de operaties van AB InBev. De performance van 3.4.1 Brouw Bier is goed maar deze capability kan toch onder handen 85

worden genomen door een project om bijvoorbeeld nog efficiënter te werken. We zien ook dat 3.4.2 Bottel Bier een lage strategische waarde heeft. Men zou dus kunnen denken dat we deze capability kunnen outsourcen maar de verbondenheid met 3.4.1 Brouw Bier is te sterk om dat gemakkelijk te doen. De processen van beiden lopen immers vlot in elkaar over. Het is dus belangrijk om zich niet blind te staren op deze heat map maar ook andere bronnen te raadplegen. De capabilities binnen de capability groep 3.5 Lever Bier presteren niet naar behoren. Uit deze heat map blijkt dat de levering van het bier niet zo goed loopt. Er zal dus aandacht moeten geschonken worden aan deze capabilities en de oorzaak van de lage performance moet in kaart worden gebracht. 5.3.7.4 Plan en Beheer Onderneming Binnen 4.0 Plan en Beheer Onderneming kunnen we vier opmerkelijke dingen ontdekken. Ten eerste bezit 4.1 Financieel Beheer enkele belangrijke capabilities. Aangezien AB InBev groeit door in nieuwe markten bedrijven op te kopen, hebben ze nood aan veel geld. Hoge cashflows zijn dus van strategisch belang en dat is net wat deze capabilities doen. Over het algemeen presteren ze vrij goed op deze elementen behalve 4.1.3 Beheer Handelsvorderingen. Ze hebben blijkbaar moeite om geld te krijgen van hun klanten. De oorzaken hiervan moeten gevonden worden. De oorzaak kan eventueel ook te maken kunnen hebben met 4.1.4 Verwerk Elektronische Betalingen, een capability die een lage performance heeft. Ten tweede zien we dat de capabilities binnen 4.3 Beheer Human Resources van weinig strategisch belang zijn, behalve 4.3.4 Beheer Personeel. Indien deze capabilities ook een lage verbondenheid hebben en indien deze een hoge rijpheid hebben, zijn deze capabilities een uitstekende keuze om te outsourcen. Dat zijn dan ook meestal de capabilities die worden geoutsourcet in bedrijven. Eventueel kan 4.3.4 Beheer Personeel door AB InBev zelf worden gedaan aangezien dat toch het rekruteren en opleiden van hun personeelsleden is. Ten derde zien we dat de twee capabilities 4.5.1 Beheer Bedrijfswaarden en 4.5.2 Stimuleer Cultuur een zeer hoge strategische waarde hebben. AB InBev zet sterk in op hun waarden en verwacht van alle werknemers dat ze binnen de bedrijfscultuur passen.

86

De cultuur om de maatschappij te ondersteunen uit zich dan ook in allerhande projecten zoals de BOB-campagne. Ten slotte zien we dat 4.4.1 Lever IT Gebaseerde Diensten geen al te sterk punt is van AB InBev. Ook hier kan outsourcen een oplossing bieden zodat een bedrijf wiens core business het leveren van IT Gebaseerde Diensten de performance kan verhogen. 5.3.7.5 Beheer Samenwerking De laaste foundation capability handelt over de samenwerking binnen de AB InBev groep. Aangezien AB InBev geregeld nieuwe bedrijven overneemt zien we dat het beheren van policies binnen de groep een grote strategische waarde heeft.

87

Figuur 5.2 Heat Map van AB InBev volgens Microsoft

88

5.3.8 ONDERSTEUNING VAN TOOLS Zoals reeds herhaaldelijk aangehaald kan een ondersteunende tool het gebruiksgemak van een model sterk verhogen. Microsoft heeft intern waarschijnlijk zijn eigen tool ontwikkeld waarmee capabilities kunnen gemodelleerd worden maar het is niet duidelijk welke tool ze gebruiken en welke alternatieven er zijn. Op zich is het mogelijk om capabilities te modelleren in Excel of zelf op een blad papier maar de werklast is een stuk hoger en de consistentie kan niet gegarandeerd worden. PlanningIT – een Business IT management software van Alfabet – heeft sinds kort een extra module om capabilities te modelleren. De manier waarop capabilities worden gemodelleerd in planningIT leunt vrij sterk aan bij de aanpak van Microsoft. Met behulp van deze software kan meteen ook de link worden gelegd tussen capabilities en processen.

5.3.9 EVALUATIE Microsoft is een van de gangmakers van het modelleren van capabilities en dat zien we ook in hun model. Elke capability moet vrij goed geanalyseerd worden en alle elementen die we willen kennen, komen aan bod. De manier waarop die analyse moet gebeuren is onbekend en we kunnen dus zeker nog niet spreken over een methode om capabilities te modelleren. Met betrekking tot de interacties blijven we een beetje op onze honger zitten. Er zijn drie verschillende vormen van interactie maar hoe de capabilities dan exact met elkaar in interactie gaan blijft een beetje vaag. Qua visualisatie zien we dat Microsoft hier goed werk levert. In een oogopslag kan met behulp van een heat map snel gezien worden welke capabilities aandacht vereisen. Het enige minpunt in deze visualisatie is dat er geen mogelijkheid is om de interacties tussen de verschillende capabilities weer te geven. Verder dient ook gebruik te worden gemaakt van tools om het modelleren te vergemakkelijken en deze tools zijn tot op heden vrij beperkt. Volgende tabel geeft een samenvatting voor elk van de criteria hoe Microsoft deze implementeren.

89

Microsoft Omschrijving van de capability

Op een duidelijke manier wordt omschreven wat het doel is van de capability en welke aspecten die allemaal omvat.

Service levels

Het is belangrijk om service levels te bepalen voor elk van de capabilities.

Inkapseling

van

mensen,

Elk van de drie elementen wordt duidelijk omschreven

processen en technologie

binnen dit model.

Interacties tussen capabilities

De verticale relatie wordt duidelijk aangehaald. Er zijn drie vormen van horizontale relatie maar deze worden niet sterk uitgewerkt.

Meten van attributen

Er zijn tot 180 attributen die kunnen gemeten worden voor elke capability afhankelijk van het doel van de gebruiker.

Visualisatie van capabilities

Capabilities

worden

in

een

duidelijke

structuur

gevisualiseerd waardoor een heat map maken zeer envoudig wordt. Er kunnen tot 2 attributen worden opgenomen in de heat map. Tool ondersteuning

Tool van Microsoft onbekend. Een onafhankelijk tool is planningIT van Alfabet.

Tabel 5.8 Evaluatie capabilitymodel Microsoft

5.4 CAPABILITIES VAN AB INBEV VOLGENS IBM Ook hier vertrekken we niet vanaf nul maar gebruiken we een generieke map als startpunt. Voor deze gevallenstudie gebruiken we een combinatie van een generieke Component Business Map en een generieke Component Business Map voor bedrijven die werkzaam zijn in de business van consumptiegoederen (zie Bijlage C). Beginnend met deze generieke map kijken we waar er aanpassingen nodig zijn en passen we de naamgeving aan zodat iedereen binnen AB InBev weet waarover we praten. Aldus krijgen we een Component Business Map zoals in Figuur 5.3 (p.92). Hierin staan alle componenten weergegeven geordend per verantwoordelijkheid/toerekenbaarheid op de verticale as en competenties op de horizontale as. Deze competenties werden zo gekozen zodat ze de strategische objectieven van het bedrijf weergeven (Van Diessen et al., 2008). Zo zien we Productontwikkeling aangezien het portfolio van merken moet worden beheerd om succesvol te zijn. AB InBev is heel sterk begaan met de relaties die 90

ze hebben, zowel met klanten, eindgebruikers als leveranciers (Relatie Beheer). Verkoop & Marketing zorgt ervoor dat ze hun producten kunnen verkopen. Productie en Distributie is één van de peilers van AB InBev waarin ze zorgen dat ze kwaliteitsvol bier hebben en dat op een gepaste manier aan de klant kunnen leveren. Ten slotte hebben we nog Business Administratie dat de componenten bevat die de algemene bedrijfsvoering omvatten en Financiële Controle en Accounting dat als kapstok dient voor componenten die betrekking hebben op het financiële beheer waardoor overnames gemakkelijk kunnen worden gefinancierd. Eens we deze map hebben kunnen we elk van de componenten verder uitspitten.

91

Figuur 5.3 Component Business Map van AB InBev

92

5.4.1 OMSCHRIJVING VAN DE CAPABILITIES Elk component wordt beschreven volgens de structuur voorgesteld in Figuur 3.10 (p.48). We bekijken voor het CBM de competentie Productie en Distributie. Deze leunt namelijk het dichtst aan bij de foundation capability Lever Product uit het model van Microsoft. Aldus is een vergelijking tussen deze modellen het gemakkelijkste. De 11 componenten van Productie en Distributie worden beschreven in Tabel 5.9. Zo zien we voor elke component het doel, de activiteiten, de middelen die nodig zijn (zowel mensen als technologie en andere), hoe we de component kunnen beheren (maatstaven, principes,…) en welke services de component aanbiedt en gebruikt. Supply Chain Strategie De Supply Chain Strategie heeft als einddoel een welafgelijnde strategie te bepalen voor de Supply Chain. Waar produceren we, welke capaciteit, waar hebben we magazijnen, hoe werken we zo efficiënt mogelijk, ... Analyseer Markt; Stel Projecten Voor; Marktprospectie; Onderzoek Bedrijsstrategie

Strategische consultants; COO; Sales Operations Mgr; Marktrapporten

Jaarlijkse Evaluatie van Strategie; Cascade van Doelen tot aan de arbeiders; Lagere doorlooptijd dan concurrentie;

Verkrijg Bedrijfsstrategie; Lever SC Strategie; Verkrijg Transportrapport; Verkrijg efficiëntie-analyse

Planning Voorraad Deze component heeft als doel een LT planning van de voorraad op te stellen gebaseerd op de toekomstige vraag en productie en de huidige voorraad. Stel Voorraadplanning op; Evalueer Vorige Periode; Incorporeer secundaire data

Planner; Sales Operations Mgr; Planningtool (ERP); voorraadgegevens; productieschema

Wekelijkse voorraadplanning; 1 aankoopmoment per week;

Lever voorraadplanning; verkrijg productieschema; data magazijnen

Planning Productie Deze component heeft als doel een planning voor de productie op te stellen, rekening houdend met vraag, voorraad, aanbod,… Stel Productieschema op; Wijzig Productieschema

Scheduler; Operations Mgr; Manufacturing Planning System; ERP; voorraadplanning; personeelsplanning

Een week op voorhand klaar en max 2 bieren per week; Scheduler moet afstemmen met Brouwmeester

Controleer beschikbaarheid personeel; Stuur productieschema door; Controleer voorraad; Controleer Toekomstige vraag

Beheer Orders Deze component heeft de orders die binnenkomen te beheren. Deze moeten op tijd en correct

93

worden geleverd. Verwerk Orders; Controleer Status Orders; Krijg feedback klant

Key Account Manager; Sales Vertegenwoordiger; Operations Mgr; ERP

De order moeten binnen de week vervuld worden (90%), zoniet, Key Account Manager handelt verder af;

Status orders; krijg transportroute; Voorraadgegevens

Beheer Transport Deze component staat in voor het beheer van alles wat met transport te maken heeft. Zowel het wagenpark als de optimale route bepalen. Stuur Wagenpark op onderhoud; Controleer status vrachtwagens; Stel route op;

Scheduler; Operations Mgr; Routing Systeem

Vrachtwagens moeten een capaciteit van min 75% hebben eens ze uitrijden; Elk jaar onderhoud van vrachtwagens

Controleer beschikbaarheid personeel; Controleer voorraad; Krijg status orders; lever transportroute

Controleer Productie Binnen Controleer Productie wordt zowel de kwaliteit van het productieproces als de efficiëntie beheerd. Voer kwaliteitscontrole uit; Voer efficiëntiemetingen uit; Onderzoek Klachten

Quality Manager; Laborant; Proces Analist; Procesmodel

Dagelijkse controle van bier en botteling; Proces wordt continu geanalyseerd en verbeterd

Verkrijg Procesmodellen; Lever kwaliteitsrapport af;

Beheer Aankopen Deze component behandelt alle aspecten die plaatsvinden voor en na het aankopen van goederen. Vb Optimale leverancier bepalen; Voorwaarden onderhandelen; klachten en kwaliteitscontrole verwerken Verwerk kwaliteitscontrole; Lever klachten; Evalueer Leveranciers;

Key Account Manager; Procurement Manager; CRM System

Elke aankoop wordt voorbereid door een analyse van de leveranciers en de benodigde grondstoffen.

Verkrijg vraagplanning; Lever kwaliteitsrapport af; verkrijg voorraadplanning; verkrijg productieschema; lever evaluatie leveranciers

Brouw Bier Brouw Bier is het component dat alles omvat met betrekking tot het brouwproces. Het doel is om een portfolio bieren te brouwen met voldoende kwaliteit. Prepareer Grondstoffen; Reinig Machines; Controleer Brouwproces; Bepaal Grondstoffenmix;

Brouwmeester; Operations Mgr; Brouwketels; Brouw Systeem

Bier wordt gebrouwen met een zo miniem mogelijke hoeveelheid water (3,5Hl/l Bier);

Verkrijg productieschema; Lever Informatie Bier; Verwerk Kwaliteitsrapport;

94

Koop Grondstoffen aan Deze component omvat de activiteiten die plaatsvinden bij het aankopen van grondstoffen waarbij rekening wordt gehouden met de prijs/kwaliteit van de leveranciers. Voer aankooporder uit; controleer status order; voer kwaliteitscontrole uit

Procurement Manager; Electronic Ordering System

Grondstoffen worden aangekocht bij de leverancier met beste prijs/kwaliteit;

Bepaal Status order; Verkrijg kwaliteitsrapport; lever kwaliteitscontrolecijfers; verkrijg evaluatie leveranciers

Beheer Voorraad Beheer Voorraad staat in voor het beheer van de bestaande voorraad.

Controleer Voorraadpeil; Geef Bestelorder;

Operations Manager; Magazijnier; Voorraadbeheerder; ERP; MRP

Minimum twee weken voorraad ten allen tijde; Vanaf onder vereist niveau, dag zelf bestelling doorgeven

Geef voorraadniveau door; Verkrijg voorraadplanning; verkrijg orders;

Beheer Magazijnen De component Beheer Magazijnen staat in voor het algemene beheer van de magazijnen alsook voorraadbeheer van de magazijnen zelf en voorbereiden orders. Verwerk Verouderde Producten; Tel Voorraad na; Stel Palet Samen;

Operations Manager; Magazijnier; Magazijnmanager; ERP

95 % van de orders moet correct worden voorbereid; Magazijnmgr is verantwoordelijk voor goede werking en rapporteert aan operations mgr.

Geef voorraadpeil magazijn door; Verkrijg orders; Verkrijg status orders Tabel 5.9 Beschrijving Componenten binnen Productie en Distributie

Deze tabel geeft eigenlijk een beknopt maar toch compleet overzicht van de componenten. Hierin staat alles uitgeschreven dat we willen weten van de verschillende componenten. We bekijken nu elk element apart.

5.4.2 BEPALEN VAN SERVICE LEVELS De service levels van de componenten binnen het Component Business Model van IBM vinden we terug in het vak van governance. Daarin staan immers de maatstaven die worden gehanteerd om de performance van de componenten te meten alsook eventuele regels en richtlijnen. Die regels en richtlijnen vonden we niet terug bij Microsoft. Zo zien we bijvoorbeeld voor Beheer Orders in het vakje governance staan: De orders moeten binnen de week vervuld worden (90%), zoniet, Key Account Manager handelt 95

verder af. We zien dus dat elk order binnen de week moet worden vervuld (met 90% zekerheid). Dat is het service level of de maatstaf die wordt gebruikt. Het tweede deel is dan eerder een procedure of richtlijn die zegt dat indien het order niet vervuld is binnen de week, een Key Account Manager het order verder beheert en afhandelt. We vinden ook SLAs binnen de services zelf maar daar gaan we later dieper op in.

5.4.3 INKAPSELING VAN MENSEN, PROCESSEN EN TECHNOLOGIE Een capability – of in het geval van IBM een component – moet een duidelijke omschrijving hebben van de mensen, processen en technologie die nodig zijn om het doel te bereiken. Het vak dat middelen beschrijft kunnen we beschouwen als de beschrijving van de mensen en technologie die nodig is om het resultaat te bereiken. In deze gevallenstudie is de opsplitsing niet gemaakt tussen mensen en technologie maar men zou die opsplitsing gerust kunnen maken indien men meer gedetailleerd wil werken. De inkapseling van processen is niet eenduidig. Er is geen apart vakje voor processen maar we vinden wel activiteiten die worden uitgevoerd door de component. We zouden deze activiteiten kunnen beschouwen als processen maar we kunnen ook de visie aannemen die Malik voorstelt en die we weervinden in Figuur 2.4 op p.16. Hier worden capabilities verder opgesplitst in kleinere delen tot we op activiteiten botsen. Hetzelfde gebeurt met processen in een procesmodel. Het zijn net deze activiteiten die capabilities en processen met elkaar delen. Indien we deze visie aannemen kunnen we de beschreven activiteiten beschouwen als de bouwstenen van processen en hebben we dus deels een lijst van processen. Zo zien we voor Beheer Orders de volgende activiteiten in de tabel staan: Verwerk Orders, Controleer Status Orders en Krijg feedback klant. Als we dat als activiteiten beschouwen dan zouden we volgens de tweede optie die Malik voorstelt processen kunnen samenstellen met deze activiteiten. Die processen kunnen dan bestaan uit activiteiten afkomstig uit verschillende componenten.

5.4.4 OMSCHRIJVING VAN INTERACTIES Componenten gaan met elkaar in interactie door het uitwisselen van services (Cherbakov et al. , 2005). Elke component heeft services die geleverd kunnen worden en elke component maakt gebruik van services van andere componenten. Een component 96

kan een service request sturen naar een andere component waarop deze de service levert. Aan de hand van service level agreements wordt het niveau van de service gegarandeerd. De manier waarop deze service geleverd wordt is dan van ondergeschikt belang. Dat is de essentie van services. In het voorbeeld van AB InBev zien we bijvoorbeeld de component Beheer Transport. De services die Beheer Transport levert is het leveren van de transportroute aan Beheer Orders. Maar deze component maakt wel gebruik van services van drie andere componenten. Van HR Administratie gebruikt deze beschikbaarheid personeel, van Beheer Voorraad voorraadpeil en van Beheer Orders is dat status orders. We zien dit grafisch weergegeven in Figuur 5.4.

Figuur 5.4 Ontvangen en Geleverde services van Beheer Transport

De hiërarchische structuur die we wel terugvonden bij Microsoft is hier niet echt te vinden. We hebben wel de kerncompetenties die de horizontale rij vormen waardoor we wel een vorm van verfijning hebben maar dit is toch veel beperkter. Wat betreft de horizontale relaties, zien we dat IBM daar duidelijker in is dan Microsoft. Door het uitwisselen van services krijgen we een goed beeld van de interacties die componenten met elkaar hebben.

5.4.5 BEPALEN VAN DE EIGENAAR Er is geen rechtstreekse verwijzing naar wie de eigenaar is van de componenten. Wel hebben we door de verticale as een idee op welk niveau binnen de hiërarchie van het bedrijf de component zich bevindt. De verticale as geeft immers het niveau van verantwoordelijkheid aan. 97

5.4.6 METEN VAN ATTRIBUTEN Opnieuw kunnen we voor elke component enkele attributen opstellen en deze meten. Met behulp van deze attributen kunnen we dan een heat map opstellen waarbij we onze prioriteiten stellen met betrekking tot transformatie van de business. De keuze van welke attributen we meten is opnieuw (net zoals bij Microsoft) vrij aan de gebruiker van het model, maar vaak gebruikte attributen zijn strategisch belang, financiële prestatie en IT ondersteuning (Cherbakov et al., 2005). Om deze attributen te meten moet gebruik worden gemaakt van procesmodellen, kosten- en waardedrijvers, KPIs (Key Performance Indicators), … Het is niet de bedoeling om een tabel te maken van alle componenten en alle attributen en dan elke cel te bepalen. Component Business Modelling is een praktisch hulpmiddel en dus worden enkel de relevante elementen gemeten. Deze worden dan ook meteen in de heat map weergeven en niet in aparte lijsten.

5.4.7 VISUALISATIE EN HEAT MAPS Zoals we in het vorige punt konden lezen worden de gemeten attributen meteen weergegeven in een heat map. In tegenstelling tot de aanpak van Microsoft, gebruiken ze bij IBM telkens maar één attribuut in de heat map. Zo kijken ze bijvoorbeeld enkel naar het strategische belang waarbij dan kan bepaald worden welke componenten nietdifferentiërend zijn en dus mogelijk kandidaten voor outsourcing zijn. Ook vaak gebruikt is de IT ondersteuning zodat kan worden gezien welke componenten meer aandacht nodig hebben op het vlak van IT. Maar zoals gezegd kunnen deze attributen zijn wat de gebruiker wenst. Voor de gevallenstudie van AB InBev zullen we als attribuut IT ondersteuning gebruiken. Figuur 5.5 geeft de heat map die we dan verkrijgen.

98

Figuur 5.5 Heat Map voor IT Ondersteuning van AB InBev volgens IBM

99

We zien dat er twee componenten zijn met zeer lage IT ondersteuning en negen met een lage IT ondersteuning. De gebruiker van deze map zou aldus kunnen concluderen dat projecten moeten worden opgestart om deze componenten beter te voorzien van IT ondersteuning. We zien bijvoorbeeld dat drie aspecten met betrekking tot marketing een lage tot zeer lage IT ondersteuning hebben. Dat wil zeggen dat het waarschijnlijk wel interessant is om te kijken hoe men deze drie componenten kan ondersteunen met nieuwe technologieën. We moeten wel opletten dat we deze heat map niet gebruiken zonder kritisch te zijn en andere bronnen en technieken te gebruiken. Het is een hulpmiddel en een extra perspectief met betrekking tot investeringsproblemen maar het zal geen bestaande technieken compleet vervangen.

5.4.8 ONDERSTEUNING VAN TOOLS Net als bij Microsoft is het niet duidelijk welke tools IBM gebruikt ter ondersteuning van het Component Business Model. Opnieuw is het ook mogelijk om de componenten te modelleren in Excel of op een blad papier. Dit gaat zelfs iets gemakkelijker dan bij Microsoft aangezien er niet moet gewerkt worden met de hiërarchie. Tools van derden die we kunnen gebruiken om een CBM op te stellen zijn niet te vinden dus hier blijven we wel wat op onze honger zitten.

5.4.9 EVALUATIE IBM neemt een andere insteek dan Microsoft en probeert op een A4-bladzijde hun componenten weer te geven. Elke component wordt beschreven aan de hand van de juiste criteria waardoor we de benodigde informatie snel kunnen vinden voor elke component. Met betrekking tot de interacties scoort IBM beter dan Microsoft aangezien ze de componenten in interactie laten gaan door middel van uitwisseling van services. We kunnen deze interacties ook visualiseren in een aparte weergave (naast de Component Business Map). Desalniettemin vinden we geen (of in ieder geval een beperkte) vorm van verticale structuur in de componenten. Dat is evenwel iets dat wel nodig is en helpt om meer granulair na te denken. De Component Business Map, waarin we effectief op een A4-blad alle componenten gerangschikt zien biedt de mogelijkheid om een heat map te genereren waarbij we één attribuut kunnen weergeven in tegenstelling tot de twee bij Microsoft. Voor elk attribuut 100

zouden we dus een aparte heat map moeten genereren. De tools beschikbaar om een CBM te maken zijn niet vrij beschikbaar en dus is dat wel een minpunt. IBM Omschrijving van de capability

IBM beschrijft voor elke component het doel.

Service levels

Als deel van de governance-omschrijving vinden we service levels die de componenten moeten bereiken.

Inkapseling

van

mensen,


Mensen en technologieën worden in een omschrijving voor middelen weergegeven. We vinden geen echte processen weer maar wel activiteiten.


De verticale relatie ontbreekt deels aangezien alle componenten naast elkaar staan in de CBM. Horizontaal vinden we wel duidelijk de interacties door uitwisseling van services.


Er kunnen verscheidene attributen worden gemeten afhankelijk van de interesse van de gebruiker.


Capabilities

worden

in

een

duidelijke

structuur

gevisualiseerd. Dat kan zelfs op een A4-blad worden weergegeven. Een heat map maken is dus niet zo moeilijk al hebben we hier wel de beperking dat we maar één attribuut kunnen opnemen. Tool ondersteuning

De tool van IBM is onbekend maar het is mogelijk dit op papier of in Excel te maken.

Tabel 5.10 Evaluatie capabilitymodel IBM

5.5 CAPABILITIES VAN AB INBEV VOLGENS KLINKMÜLLER ET AL. Het derde model dat we zullen onder de loep nemen is het model van Klinkmüller et al. In de literatuurstudie hebben we gezien dat dit model zich vooral focust op het visualiseren van de capabilities aangezien dat volgens de auteurs een probleem is bij andere modellen. We moeten dus vertrekken vanuit een ander model en dit model zal worden herwerkt waardoor de visualisatie beter is. De auteurs stellen voor om het model van Microsoft te gebruiken als basis. We kunnen dus de capability map die we verkregen hebben in 5.3 (Capabilities van AB InBev volgens Microsoft, p.71) opnieuw gebruiken. We werken dus verder met Tabel 5.1 (p.73). 101

5.5.1 OMSCHRIJVING VAN DE CAPABILITIES Klinkmüller et al. geven geen specifieke manier om capabilities te omschrijven. Het is voornamelijk de bedoeling om de capabilities te visualiseren. Aangezien we ons hier baseren op het model van Microsoft nemen we de omschrijving van de capabilities ook mee in dit model van Klinkmüller et al.

5.5.2 BEPALEN VAN SERVICE LEVELS Hier opnieuw vinden we geen referentie in de manier waarop we dat moeten weergeven. We zullen dus weer verder werken met de service levels die we bij Microsoft hebben gevonden.

5.5.3 INKAPSELING VAN MENSEN, PROCESSEN EN TECHNOLOGIE We gebruiken opnieuw de data die we hebben bekomen bij de gevallenstudie volgens Microsoft.

5.5.4 OMSCHRIJVING VAN INTERACTIES De omschrijving van interacties omvat enerzijds het verticale aspect en anderzijds het horizontale aspect. De visualisatie van Klinkmüller et al. heeft als doel om gemakkelijker te zien welke interacties er plaats vinden tussen capabilities, zowel op het horizontale vlak als het verticale vlak. Bij Microsoft konden we in de capability map gemakkelijk zien hoe de verticale structuur in elkaar zat, maar de manier waarop de capabilities met elkaar in interactie gingen was niet mogelijk om te zien. Die informatie moesten we uit een tabel halen. Uiteraard moeten we voor we visualiseren eerst de nodige data hebben en dus gebruiken we hier opnieuw de tabellen uit de gevallenstudie van Microsoft.

5.5.5 BEPALEN VAN DE EIGENAAR We vinden geen referentie in Klinkmüller et al. (2010) over wie de eigenaar is van een capability. Opnieuw ligt dat aan het feit dat de auteurs vooral focussen op de visualisatie dus opnieuw kunnen we de gegevens uit het model van Microsoft gebruiken.

5.5.6 METEN VAN ATTRIBUTEN Voor het meten van attributen nemen Klinkmüller et al. een andere aanpak. Bij de vorige twee modellen zagen we dat er een lijst van attributen werd opgesteld die interessant waren voor de gebruiker. Dat is ook wat we gaan doen in dit model, maar een volgende stap is het toewijzen van numerieke waarden aan deze attributen en het vervolgens aggregeren van deze attributen. De gewichten waarmee we de attributen samenvoegen zijn afhankelijk van de situatie. Zo zal iemand die geïnteresseerd is in de IT 102

ondersteuning veel meer gewicht geven aan dit attribuut dan aan bijvoorbeeld strategische waarde. Het grote verschil met de vorige modellen is dus dat we alle attributen in beschouwing nemen en dus een genuanceerder beeld krijgen welke capabilities interessant zijn om verder te onderzoeken. De auteurs wijzen erop dat het evenwel niet verplicht is om één enkele geaggregeerde waarde te beschouwen. Het kan ook zijn dat er meerdere waarden worden berekend die dan allebei in rekening genomen moeten worden. Voor de gevallenstudie bekijken we opnieuw de foundation capability Lever Product en alle capabilities die onder die hiërarchie vallen. Deze keer willen we onderzoeken welke capabilities in aanmerking komen om te worden geoutsourcet. We vertrekken van Tabel 5.7

(p.84) en we geven numerieke waarden aan de attribuutwaarden uit deze tabel. We

zijn geïnteresseerd in de capabilities die we kunnen outsourcen dus we kijken welke capabilities een lage strategische waarde hebben, rijp zijn en een lage verbondenheid hebben met andere capabilities. De performance is van minder belang voor deze analyse. Dat zien we dan ook terug in de gewichten die we geven aan elk van de attributen om tot een geaggregeerde waarde te komen. Strategische waarde en verbondenheid met andere capabilities zijn de twee belangrijkste attributen dus deze krijgen het grootste gewicht (40%). De rijpheid speelt ook een rol en krijgt de overige 20% als gewicht. De huidige performance wordt dus niet in rekening genomen. Indien we deze waarde aggregeren krijgen we volgende waarden (Tabel 5.11). Capability Gewichten

3.0 Lever Product

Attributen (Numeriek) 0,4 0 0,2 0,4 Strategische Performantie Rijpheid Verbondheid Totaal waarde met andere capabilities 2 3 4 3 2,8


2

3

4

3

2,8


2 4 2 3 4

2 3 3 3 3

3 4 4 4 2

3 4 3 2 4

2,6 4 2,8 2,8 3,6

3.3 Aankoop

4 2

3 4

2 4

4 4

3,6 3,2


2

4

4

4

3,2

3.1.2 Planning van Aanbod 3.1.3 Planning van Voorraad 3.1.4 Productie Schema Opstellen


103

3.3.2 Aankopen van Grondstoffen 3.3.3 Ontvangen van Grondstoffen

3.4 Produceer Product 3.4.1 Brouw Bier 3.4.2 Bottel Bier 3.4.3 Kwaliteitscontrole

3.5 Lever Bier 3.5.1 Order Vervulling 3.5.2 Beheer Transport 3.5.3 Beheer Voorraad 3.5.4 Beheer Magazijnen

2 3 2

4 3 4

4 3 4

4 4 3

3,2 3,4 2,8

1 4 3 2

4 4 5 3

5 4 4 3

2 3 4 3

2,2 3,6 3,6 2,6

1 2 2 4

3 3 2 2

3 4 4 2

3 3 3 3

2,2 2,8 2,8 3,2

Tabel 5.11 Attributen met numerieke waarden en geaggregeerde waarde

Op basis van deze tabel zien we dat er enkele capabilities in aanmerking kunnen komen om te worden geoutsourcet, nl. 3.2.1 Vervul Analyse van Vraag, 3.4.2 Bottel Bier en 3.4.3 Kwaliteitscontrole. We kunnen geen beslissing nemen op basis van deze tabel alleen, er zijn nog vele andere aspecten die we in rekening moeten houden maar het geeft ons al een indicatie. Het grote probleem is dat we toch nog steeds vast zitten in tabellen die vaak oeverloos lang kunnen zijn. Daarom stellen de auteurs voor om alle capabilities te visualiseren op een hemisfeer als een boom.

5.5.7 VISUALISATIE EN HEAT MAPS Klinkmüller et al. argumenteren dat er in veel modellen wel een poging wordt gedaan om de capabilities te visualiseren maar de wijze waarop dit gebeurt is vaak vrij beperkt. Voornamelijk de interacties kunnen zeer moeilijk te ontdekken zijn in vorige modellen. En dat is net een van de twee punten dat een analist wil terugvinden: de organisatorische structuur van de capabilities en de capabilities die interessant zijn met betrekking tot een bepaald aspect (Klinkmüller et al., 2010). We zagen reeds dat ze dit aanpakken door de capabilities te beschouwen als een boom en deze te projecteren op een hemisfeer. Dat stelt ons in staat om de verticale structuur te zien op de schil van de hemisfeer. Verder worden de capabilities die in interactie met elkaar treden (horizontaal niveau) met elkaar verbonden binnenin de hemisfeer. Op deze manier kunnen we de organisatorische structuur gemakkelijk zien. In de gevallenstudie zullen we de verticale verbindingen weergeven met een rode lijn en de horizontale met een groene lijn. De capabilities die interessant zijn met betrekking tot 104

een bepaald aspect worden bepaald door de geaggregeerde waarde van de attributen weer te geven. We hebben enkele technieken gezien om deze waarde weer te geven maar in deze gevallenstudie zullen we werken met kleurschakeringen. We gaan van groen naar rood waarbij groen niet interessant is voor het beschouwde aspect en rood zeer interessant. Indien we deze visualisatietechniek toepassen op de foundation capability Lever Product bekomen we volgende figuur.

105

Figuur 5.6 Lever Product gevisualiseerd volgens Klinkmüller et al.

106

Met behulp van deze visualisatie zien we opnieuw dat er vier capabilities zijn die zeer sterk in aanmerking kunnen komen om te worden geoutsourcet, namelijk 3.1.2 Planning van Aanbod, 3.2.1 Vervul Analyse van Vraag, 3.4.2 Bottel Bier en 3.4.3 Kwaliteitscontrole. Maar daarnet moesten we dat uit een tabel halen en hadden we geen idee met welke capabilities deze in interactie gingen. Nu zien we duidelijk dat 3.4.2 Bottel Bier zeer sterk verbonden is met 3.4.1 Brouw Bier, wat een capability is met een zeer hoge strategische waarde. Het zal dus moeilijk zijn om deze capability te outsourcen. Hetzelfde verhaal voor 3.4.3 Kwaliteitscontrole maar de aard van deze interactie is anders. We weten immers uit onze data die we voorheen hebben verzameld dat deze interactie controlerend van aard is. Het kan misschien interessant zijn om in toekomstige versies van dit model de verschillende soorten van interactie op een verschillende manier weer te geven, bijvoorbeeld met een ander kleur. Zo krijgt de analist nog meer informatie. Ten slotte moet ik nog vermelden dat het gebruik van tools niet mogelijk was voor deze gevallenstudie. Daarom hebben we enkel de foundation capability Lever Product gevisualiseerd. Uiteraard is het mogelijk om dat voor de vier andere foundation capabilities te doen en dat allemaal op dezelfde hemisfeer te plaatsen waardoor we een compleet beeld krijgen.

5.5.8 ONDERSTEUNING VAN TOOLS Zoals reeds gezegd is het gebruik van tools hier nodig om een duidelijk en compleet beeld te krijgen van de volledige onderneming. De auteurs geven geen duidelijke vermelding met welke tool ze deze hemisfeer hebben gecreëerd. Zoals te zien is in Figuur 5.6

(p.106) is het perfect mogelijk om dit handmatig te doen met pen en papier maar dat

is uiteraard niet handig om op een dynamische manier de capabilities te modelleren en te visualiseren.

5.5.9 EVALUATIE Klinkmüller et al. proberen vooral een hiaat in de andere modellen op te vullen, namelijk het visualisatieaspect. Het beschrijven van de capabilities moet met behulp van een ander model gebeuren en dat is in hun geval volgens Microsoft hun aanpak. Alles wat gezegd is over Microsoft kan dus hier herhaald worden tot aan de visualisatie. Met behulp van een hemisfeer en een boom modelleren ze de capabilities op zo een manier dat de verticale structuur mooi wordt weergegeven alsook de horizontale interacties. 107

Een punt dat hier nog zou kunnen wijzigen is een onderscheid maken tussen de verschillende soorten interacties. Verder bekijken Klinkmüller et al. één enkele geaggregeerde attribuutwaarde in plaats van twee attributen op een heat map te plaatsen. Dat heeft als voordeel dat alle relevante elementen in rekening kunnen genomen worden. Qua toolondersteuning blijven we ook hier op onze honger zitten. Klinkmüller et al. Omschrijving van de capability

Op een duidelijke manier wordt omschreven wat het doel is van de capability en welke aspecten die allemaal omvat. (zie Microsoft)

Service levels

Het is belangrijk om service levels te bepalen voor elk van de capabilities. (zie Microsoft)

Inkapseling

van

mensen,

Elk van de drie elementen wordt duidelijk omschreven


binnen dit model. (zie Microsoft)


De verticale relatie wordt duidelijk aangehaald. Er zijn drie vormen van horizontale relatie maar deze worden niet sterk uitgewerkt. (zie Microsoft)


De verschillende mogelijk attributen worden bepaald en gemeten. Er wordt dan één geaggregeerde waarde bepaald waarbij

de

individuele

attributen

worden

gewogen

afhankelijk van hun relevantie. Aldus bekomen we één algemene graadmeter om te zien welke capabilities extra aandacht vereisen. Visualisatie van capabilities

We zien de capabilities op een hemisfeer als een boom afgebeeld waardoor de verticale structuur zeer duidelijk is. Door ook de horizontale relaties weer te geven krijgen we een beter beeld dan bij Microsoft. Een soort van heat map ontstaat doordat we de geaggregeerde attribuutwaarde weergeven door middel van kleurschakeringen.

Tool ondersteuning

De tool die we kunnen gebruiken is niet gekend.

Tabel 5.12 Evaluatie capabilitymodel Klinkmüller et al.

108

5.6 CAPABILITIES VAN AB INBEV VOLGENS VDML Het laatste model dat we zullen bekijken in deze gevallenstudie is VDML. Het is belangrijk om op te merken dat capabilities maar een deel zijn van VDML. Het hoofddoel is om te modelleren welke waarde er wordt geleverd, aan wie en op welke manier. De manier waarop is waar capabilities hun plaats vinden. Binnen deze gevallenstudie zullen we voornamelijk aandacht hebben voor capabilities, capability offers en capability methods maar het is belangrijk om in het achterhoofd te houden dat dit maar een deel van een groter geheel is. VDML werkt met een hiërarchisch structuur van capabilities en ze starten met een bibliotheek van capabilities waarin alle capabilities van een bedrijf staan. De manier waarop de capabilities worden gestructureerd is een vrije keuze voor de gebruiker van het model. Indien we nu de organisatiestructuur zouden nemen als basis om onze capabilities te structureren dan zouden we een hiërarchie bekomen die min of meer gelijk is aan deze die we bekomen zijn bij Microsoft. Om geen dubbel werk te doen zullen we dus als vertrekpunt beginnen met de lijst van capabilities zoals we ze vinden in Tabel 5.1 (p.73).

5.6.1 OMSCHRIJVING VAN DE CAPABILITIES Voor de omschrijving van de capabilities zoals we het gezien hebben in de vorige modellen, moeten we ons vooral focussen op enerzijds de capability uit de bibliotheek en anderzijds de capability offers. De capability methods neigen al meer toe naar echte processen maar in plaats van te focussen op de uitzonderingen en de manier waarop daarmee wordt omgegaan wordt meer gekeken naar de statische aspecten van activiteiten. Het is dus een iets abstracter concept dan processen maar het is al een stap verder dan het gewoon modelleren van capabilities. Het doel van een capability wordt in VDML beschreven in de bibliotheek van capabilities. Dat is vrij gelijkaardig aan de omschrijving die we reeds maakten bij Microsoft en we hoeven deze oefening dus niet opnieuw te maken.

5.6.2 BEPALEN VAN SERVICE LEVELS De capabilities helpen mee met het leveren van een value proposition en zo worden ze ook weergegeven in VDML. Expliciete service levels die een capability (die in de bibliotheek omschreven staat) moet behalen vinden we niet terug in het huidige model 109

en kunnen we dus ook niet modelleren. Wel vinden we in de capability bibliotheek inputs en outputs die capability methods moeten hebben om de capability te ondersteunen. Maar deze outputs (en ook inputs) worden niet hard afgedwongen en kunnen dus niet echt als service levels worden beschouwd.

5.6.3 INKAPSELING VAN MENSEN, PROCESSEN EN TECHNOLOGIE De plaats waar we zien welke mensen, processen en technologie nodig zijn om een capability te leveren is in de capability method. Zoals reeds gezegd neigt deze method meer toe naar een proces maar dan eerder statisch. In de capability bibliotheek vinden we wel capability resources die gebruikt kunnen worden om de capability te leveren maar zoals de outputs worden deze niet hard afgedwongen en kunnen we dus niet zeker zeggen dat deze middelen ook effectief worden ingezet. We bekijken nu als voorbeeld de capability group Produceer Product uit het voorbeeld van Microsoft. Deze capability offer vinden we weer in de organisatorische eenheid Bierproductie. We zien dat elke capability offer (de zeshoek) wordt ondersteund door een capability method (de rechthoek met twee kleine rechthoekjes in de linkerbovenhoek). De puntlijn duidt aan dat de capability method Produceer Product, die de capability offer Produceer Product ondersteunt, op zijn beurt ondersteund wordt door

drie

andere

capability

offers

(namelijk

Brouw

Bier,

Bottel

Bier

en

Kwaliteitscontrole). Dit zien we weer in Figuur 5.7.

110

Figuur 5.7 Capabilities in organisatorische eenheid Bierproductie

Het zijn in deze capability methods dat wordt opgenomen welke mensen, technologieën en processen nodig zijn en samenwerken op het resultaat te behalen. In VDML worden geen processen opgenomen in een capability method maar de activiteiten worden wel weergegeven. Dat is dus gelijkaardig aan IBM waar ook de activiteiten worden weergegeven in plaats van processen bij Microsoft. De manier waarop mensen en technologie worden opgenomen in de tool (infra p.112) is niet bekend.

5.6.4 OMSCHRIJVING VAN INTERACTIES De verticale interacties tussen capabilities kunnen we weervinden in de bibliotheek waar er duidelijk wordt gewerkt met een hiërarchie. Ook in Figuur 5.7 is duidelijk hoe de verticale structuur werkt. De capability method Produceer Product wordt ondersteund door drie capability offers die op een lager niveau in de hiërarchie voorkomen. De horizontale interacties tussen capabilities worden niet weergegeven op het eerste zicht. De interacties komen pas in beeld als we de capability methods bekijken waarin de activiteiten zitten. Deze activiteiten kunnen dan samenwerken in een soort van proces maar we vinden geen gestructureerde interacties zoals we bij de vorige modellen wel vonden. Er is geen uitwisseling van services tussen de verschillende capabilities. 111

5.6.5 BEPALEN VAN DE EIGENAAR Er is geen eigenaar van een capability maar we vinden wel een organisatorische eenheid die een capability offer aanbiedt om een resultaat te behalen. Dat offer kan dan ondersteund worden door enerzijds een capability method of anderzijds rechtstreeks via de middelen die ervoor nodig zijn. Deze organisatorische eenheid is dan de leverancier van het capability offer en de eigenaar van de capability method. Binnen VDML is het immers mogelijk dat er meerdere capability offers zijn door verschillende organisatorische eenheden voor een en dezelfde capability. Als voorbeeld bekijken we de organisatorische eenheid Bierproductie die we reeds zagen in Figuur 5.7. Deze organisatorische eenheid is de leverancier van het capability offer Produceer Product, alsook van de capability offers Brouw Bier, Bottel Bier en Kwaliteitscontrole. Bierproductie is eigenaar van de capability methods Produceer Product, Brouw Bier, Bottel Bier en Kwaliteitscontrole.

5.6.6 METEN VAN ATTRIBUTEN VDML is een modelleertaal die niet als hoofddoel heeft om capabilities te modelleren en het heeft dus ook niet als hoofddoel om bepaalde aspecten te meten van capabilities en dan te bepalen waar meer aandacht aan moet besteed worden. Het belangrijkste concept binnen VDML is de value proposition en de manier waarop deze waarde wordt gecreëerd en geleverd. De mate waarin een capability bijdraagt tot deze waardecreatie is belangrijk binnen VDML. We zouden dat dan ook als een attribuut kunnen beschouwen, maar we zien geen gestructureerde manier om een aantal attributen op een objectieve manier te meten per capability.

5.6.7 VISUALISATIE EN HEAT MAPS De capability bibliotheek kan op een gelijkaardige manier worden weergegeven als we bij Microsoft hebben gezien. Aldus krijgen we een compleet overzicht van alle capabilities die kunnen worden geleverd binnen de business. Wat betreft heat maps kunnen we kort zijn. In de huidige versie van VDML is nog geen plaats voor heat maps maar dat is zeker iets waar in de toekomst naar gewerkt zal worden. De vraag die zich stelt is welke attributen dan zullen worden gemeten en weergegeven in deze heat map. Enerzijds kan men het houden op het ene attribuut dat meet in welke mate er wordt bijgedragen tot waardecreatie. Anderzijds kan men meerdere nieuwe attributen meten zoals we reeds zagen in vorige modellen. 112

Uiteraard zijn er in VDML veel meer visualisatiemogelijkheden waarbij capabilities, capability offers en capability methods worden gebruikt maar deze vallen buiten het analysedomein van deze masterproef. Deze sluiten immers meer aan bij enerzijds goal modellen en anderzijds procesmodellen.

5.6.8 ONDERSTEUNING VAN TOOLS Het gebruik van een tool voor deze modelleertaal is vrijwel onmisbaar. VDML is een taal die nog in ontwikkeling is en de tool die gebruikt kan worden is bijgevolg ook nog in ontwikkeling. Aangezien vele concepten met elkaar gelinkt zijn en weerkomen in verschillende delen van de taal is een tool noodzakelijk. Anders verliest men meteen alle overzicht en wordt er alleen maar complexiteit toegevoegd aan de analyse.

5.6.9 EVALUATIE VDML is een modelleertaal die als doel heeft de waardecreatie in een business te modelleren. Daarvoor maakt ze gebruik van het capabilityconcept. Deze capabilities zorgen ervoor dat organisatorische eenheden waarde kunnen leveren. Aangezien dat de focus van VDML ligt op het modelleren van deze waardecreatie is er minder aandacht voor de capabilities op zich. Er wordt geen echte analyse gemaakt waarin we het doel vinden met de nodige service levels, waarin we gestructureerd zien welke processen, mensen en technologieën nodig zijn, waarin we attributen meten en waarin we de interacties tussen de verschillende capabilities duidelijk kunnen ontdekken. Indien we dus echt enkel en alleen geïnteresseerd zijn in een analyse van de capabilities dan biedt VDML te weinig om dit op een gefundeerde manier te doen. Indien men echter eerder geïnteresseerd is in de manier waarop capabilities bijdragen tot de waardecreatie en de doelen van een bedrijf en hoe dit praktisch wordt gerealiseerd, dan is VDML een echte meerwaarde. VDML Omschrijving van de capability

Capabilities worden omschreven in de capability bibliotheek waar duidelijk is wat het doel precies is.

Service levels

We vinden geen omschrijving van service levels die de capabilities moeten behalen.

Inkapseling

van

mensen,


De inkapseling van deze elementen vinden we terug binnen de capability methods maar niet op een gestructureerde manier zoals we wensen.

113


De verticale relatie vinden we terug in de capability bibliotheek. We vinden geen directe interactie tussen capabilities maar wel door interactie van activiteiten binnen de capability methods.


Er worden geen verschillende attributen bepaald en gemeten binnen VDML. De mate waarin de capability bijdraagt tot waardecreatie kan eventueel gemeten worden.


Capabilities worden weergeven in een structuur gelijkaardig aan die van Microsoft in de bibliotheek. Heat maps zijn in de huidige versie van het model nog niet beschikbaar maar daar zal in de toekomst verandering in komen.

Tool ondersteuning

Er wordt een tool ontwikkeld die VDML volledig ondersteund.

Tabel 5.13 Evaluatie capabilitymodel VDML

5.7 CONCLUSIE We hebben nu vier verschillende modellen gezien en toegepast op een gevallenstudie. Deze modellen werden geëvalueerd op basis van criteria die we hebben opgesteld. We krijgen vervolgens een overzicht in Tabel 5.14 van hoe elk model scoort met betrekking tot een bepaald criterium. Microsoft

IBM

Klinkmüller et al.

VDML

Omschrijving van de capability

++

++

++

++

Service levels

++

+

++

-

Inkapseling van mensen, processen

++

+

++

-


+

++

+(+)

-


++

++

++

-


+

+

++

-

Tool ondersteuning

+-

+-

-

++

en technologie

Tabel 5.14 Evaluatie van de vier modellen op basis van de criteria

We zien dat op basis van deze vooropgestelde criteria het model van Klinkmüller et al. het best scoort. Maar uiteraard weten we dat zij zich grotendeels baseren op Microsoft en dus moeten we ook concluderen dat het model Microsoft goed scoort. IBM heeft een lichtjes andere aanpak en werkt met componenten en dat kan toch voor een beetje 114

verwarring zorgen soms. Om echt capabilities te modelleren lijkt Microsoft iets beter te zijn. Desalniettemin scoort IBM wel goed op het modelleren van de horizontale relaties tussen de capabilities. Ten slotte zien we dat VDML qua modelleren van capabilities tekort schiet ten opzichte van de anderen. Het is niet het hoofddoel van deze modelleertaal en dat blijkt ook in de gevallenstudie waar het moeilijk is om op een eenvoudige manier de capabilities op te lijsten en te beschrijven. In het volgende hoofdstuk bekijken we hoe we capabilitymodellen nu kunnen gebruiken in relatie met andere bedrijfsmodellen.

115

6 RELATIE MET ANDERE BEDRIJFSMODELLEN In het vorige hoofdstuk hebben we de eerder beschreven modellen toegepast op een gevallenstudie waarbij we als bedrijf AB InBev hebben gemodelleerd. Zoals reeds herhaaldelijk opgemerkt is het niet de bedoeling dat we een capabilitymodel gebruiken buiten enige andere context. Het dient gebruikt te worden in combinatie met reeds bestaande bedrijfsmodellen en technieken. De vraag blijft dan evenwel hoe we capabilities nu kunnen gebruiken in relatie met modellen die enerzijds nog abstracter zijn, zoals het Business Motivation Model of anderzijds modellen die praktischer zijn zoals procesmodellen of servicemodellen. In dit hoofdstuk kijken we hoe deze relatie precies in elkaar zit.

6.1 RELATIE MET HET BUSINESS MOTIVATION MODEL Om te kijken hoe de relatie tussen capabilitymodellen en abstractere modellen is, maken we gebruik van het Business Motivation Model dat we reeds hebben gebruikt in hoofdstuk 4 om de gevallenstudie uit te werken. In dit model zien we de visie, missie, strategie en doelen. In een meer uitgewerkte versie van het model komen daar ook procedures en beperkingen bij maar zoals reeds gezegd zullen we in deze masterproef enkel focussen op de 4 eerste concepten. De grote meerwaarde om een Business Motivation Model op te stellen alvorens men begint met modelleren van capabilities is dat men een eerste structuur brengt in de complexiteit die een bedrijf met zich meedraagt. Door op een consistente manier weer te geven wat het uiteindelijke doel is van een bedrijf kunnen we in een latere fase veel gemakkelijker bepalen hoe alle elementen relateren met dat uiteindelijke doel. We beginnen ons capabilitymodel immers door een structuur te bepalen waarin we onze capabilities zullen structureren. Vervolgens bepalen we aan de hand van een generiek model of door zelf na te denken, al de capabilities die aanwezig zijn binnen de business. Hier kunnen we al een eerste keer gebruik maken van het Business Motivation Model aangezien elke capability direct of indirect moet kunnen gelinkt worden aan de elementen uit het Business Motivation Model. Ook kunnen we al meteen opmerken of de strategie en visie die het bedrijf voor ogen heeft wel haalbaar is. Indien immers geen enkele capability kan worden gelinkt met een strategisch doel, dan is deze strategie misschien niet de beste optie. Bijvoorbeeld zou een strategisch doel kunnen zijn van AB 116

InBev om marktleider te worden in besturingssoftware voor Pc’s. Meteen zien we al dat dat een onmogelijke zaak is want geen enkele capability stelt hen in staat om ook maar iets te betekenen in deze markt. Moest AB InBev een strategisch doel hebben om een grote speler te worden in de frisdrankindustrie, dan is dat een gewaagde sprong maar zeker niet onmogelijk. Veel (zo niet alle) capabilities die nodig zijn in de frisdrankenindustrie vinden we terug in de bierindustrie. Een tweede moment waar het Business Motivation Model kan worden gebruikt, is wanneer we attributen meten, in het bijzonder het attribuut strategische waarde. Opnieuw kunnen we elke capability relateren aan de strategie of de doelen die we hebben opgesteld in het Business Motivation Model. Sommige capabilities zullen een zeer duidelijke en directe link hebben terwijl anderen een indirecte link hebben met de strategie en doelen. Aldus is het gemakkelijker om dat attribuut te meten.

6.2 RELATIE MET PROCESMODELLEN EN SERVICEMODELLEN Reeds in hoofdstuk 2 onderzochten we hoe capabilities verschillen van processen en hoe we deze twee concepten naast elkaar kunnen gebruiken. We vonden twee mogelijke manieren waarop capabilities en processen met elkaar konden vereenzelvigd worden (supra p.14) . De eerste optie was dat de laagste niveaus in het capabilitymodel gemakkelijk overgaan in een proces. Dat is ook de optie die door de meeste mensen in de praktijk wordt gevolgd. De tweede optie is dat capabilities en processen activiteiten met elkaar delen. Dus activiteiten zijn dan de bouwstenen van zowel de processen als de capabilities. Indien we verder werken met optie 1, dan geeft Figuur 6.1 een overzicht over de relaties tussen de verschillende concepten die we reeds zijn tegengekomen doorheen deze masterproef. We zien dat capabilities dan gerealiseerd worden door processen waarbij de middelen en de strategie van een bedrijf de drijvers (of de beperkingen) zijn. Een proces bestaat op zijn beurt uit services. Deze kunnen dan een informatiesysteem zijn en verbruiken data entiteiten. We kunnen services min of meer gelijkstellen aan capabilities maar daar waar capabilities de link leggen tussen de strategie en de business, leggen services de link tussen de business en de technologie. Indien we dus de concepten capabilities en services (eventueel met processen als tussenelement) samen bekijken binnen een bedrijf kunnen we sterk bijdragen aan business/IT alignment (Antunes en Borbinha, 2013). 117

Figuur 6.1 Link tussen capability, proces en service (Antunes en Borbinha, 2013)

We keren nog een laatste keer terug naar AB InBev om te zien hoe we een procesmodel kunnen zien in combinatie met een capabilitymodel. We bekijken de capability Brouw Bier die we zowel in het model van Microsoft als het model van IBM weervinden. Deze capability kan meteen ook als een proces worden aanzien waarbij we de samenwerking tussen de verschillende activiteiten stap voor stap weergeven.

Figuur 6.2

geeft het

procesmodel van dat proces. We zien dat er verschillende subprocessen aanwezig zijn (Bepaal grondstoffenmix, Controleer Kleur Bier, Reinig Apparatuur,…) die we reeds hadden bepaald in de analyse van de inkapseling van processen. Hier komen deze elementen dus terug. Indien we nu zouden bepalen dat we een capability willen optimaliseren, dan kunnen we dit procesmodel bij de hand nemen en moeten we onderzoeken hoe we dit proces efficiënter kunnen laten verlopen. Dat is evenwel niet de enige manier om een capability te optimaliseren met betrekking tot de performance. We kunnen immers ook andere mensen aannemen of technologie gebruiken om bepaalde taken uit te voeren.

118

Figuur 6.2 Proces Brouw Bier

6.3 CONCLUSIE We zien dat een capabilitymodel niet losstaat binnen een bedrijf. Er is zowel een relatie met meer abstracte modellen zoals het Business Motivation Model als met meer praktische modellen zoals een procesmodel. We kunnen en moeten dus gebruik maken van deze relaties om optimaal gebruik te maken van capabilities in de bedrijfsvoering. Een capabilitymodel kunnen we gebruiken om onze strategie die we in het Business Motivation Model hebben bepaald te valideren. Verder dient het Business Motivation Model als input voor de analyse van de capabilities, met name bij het meten van de attributen. Capabilities worden gerealiseerd door processen en het is dus ook belangrijk om te weten welke processen een capability omvat. De inkapseling van processen is dan ook een van de belangrijke elementen bij het modelleren van capabilities. Een model van het proces zelf stelt ons dan verder in staat om te analyseren waar we een capability kunnen verbeteren. Uiteraard dient er een grondigere analyse te gebeuren om de echte synergie tussen de verschillende modellen te achterhalen.

119

7 ALGEMEEN BESLUIT Met dit algemeen besluit wordt een antwoord geformuleerd op de gestelde onderzoeksvragen. Verder wordt gekeken welke beperkingen dit onderzoek heeft en welke aanbevelingen er kunnen worden gedaan voor toekomstig onderzoek. Het doel van deze masterproef was onderzoeken hoe business capabilities gemodelleerd kunnen worden en hoe business capabilitymodellen in de praktijk gebruikt kunnen worden. Deze masterproef bestaat uit twee delen waarbij in het eerste deel een grondige analyse werd gemaakt van de huidige literatuur rond capabilities. Daarin werd het concept capability duidelijk gedefinieerd en werden de redenen gegeven waarom dit concept interessant is om te modelleren. Vervolgens werd een overzicht gegeven van de verschillende modellen die we kunnen gebruiken om capabilities te modelleren. In het tweede deel van deze masterproef werd de analyse verder gezet en werden de gevonden modellen toegepast op een gevallenstudie. AB InBev, het voorbeeldbedrijf dat werd gebruikt voor deze gevallenstudie, werd eerst uitvoerig besproken alvorens over te gaan tot de eigenlijke gevallenstudie. Daarin werden de capabilities van AB InBev gemodelleerd met de verschillende modellen en technieken. Deze werden vervolgens geëvalueerd met behulp van vooropgestelde criteria. Deze criteria werden opgesteld gebaseerd op de literatuurstudie. Ten slotte werd gekeken hoe een capabilitymodel kan gebruikt worden in relatie met andere bedrijfsmodellen.

7.1 LITERATUURSTUDIE In het eerste hoofdstuk binnen de literatuurstudie hebben we een capability gedefinieerd als “een bepaald vermogen of capaciteit dat een bedrijf kan bezitten of verhandelen om een specifiek doel of uitkomst te bereiken. Een capability beschrijft wat een onderneming doet (zowel uitkomsten als service levels) om waarde te creëren voor de klanten. […] Een capability abstraheert en kapselt de mensen, processen en procedures, technologie en informatie in, in essentiële bouwstenen die nodig zijn om een analyse te ondersteunen voor zowel prestatieverbetering als herontwerp.” (Homann, 2006, p.5) Deze definitie werd vervolgens uitgebreid waarbij we vijf specifieke karakteristieken van capabilities hebben bepaald. Capabilities zorgen voor een stabiel beeld van de onderneming, ze zijn gestructureerd volgens een hiërarchie waarbij alle aspecten van het bedrijf op elk niveau worden belicht. De individuele capabilities gaan met elkaar in 120

interactie om resultaten te behalen. Ten slotte wordt een capability onafhankelijk van de middelen die nodig zijn om deze capability te implementeren, bekeken. Deze middelen zitten ingekapseld in de capability. Na deze analyse werden capabilities met processen vergeleken en zijn we tot de conclusie gekomen dat er wel degelijk een verschil is tussen de beide concepten. Deze twee concepten kunnen in combinatie met elkaar gebruikt worden. Ten slotte werden drie redenen gegeven waarbij we capabilities kunnen gebruiken: als stabiel beeld van de onderneming, als bron van kerncompetenties en als hulpmiddel voor business/IT alignment. Daarop aansluitend werden vier toepassingen van een capabilitymodel bekeken waarbij bleek dat elke toepassing gebaseerd is op het gebruik van heat maps. In het tweede hoofdstuk binnen de literatuurstudie werd op zoek gegaan naar modellen die ons in staat stellen om capabilities te modelleren. Ten eerst werd een algemeen model bekeken van Scott et al. dat gebaseerd is op de huidige best practices maar dat vooral dienst doet als richtlijn. De focus van dit deel lag op vier modellen die capabilities modelleren: Microsoft met Microsoft Services Business Architecture (vroeger Motion), IBM met het Component Business Model, Klinkmüller et al. met een visualisatiemodel en VDML. Microsoft was een van de koplopers in het modelleren van capabilities en dit model toont dat ook duidelijk aan. Alle elementen die aanwezig moeten zijn, vinden we terug in het model. Ze beginnen de analyse met een generiek model en passen dit aan, aan de business van hun klant waarna ze een model van het bedrijf zelf krijgen. De visualisatie van de capabilities in hun hiërarchische structuur stelt ons in staat om een heat map te maken. De interacties tussen capabilities blijven wel deels verborgen. IBM begint met een gelijkaardige strategie door een generiek model te gebruiken als startpunt. Zij modelleren in principe componenten, maar deze kunnen eigenlijk beschouwd worden als capabilities. In hun Component Business Map worden de componenten volgens twee assen gestructureerd waardoor we opnieuw in staat zijn om gemakkelijk een heat map te genereren. De interacties tussen capabilities worden door middel van uitwisseling van services goed gemodelleerd. Klinkmüller et al. proberen het gebrek aan goede visualisatie in andere modellen aan te pakken door een nieuwe metafoor voor te stellen. Zij projecteren de hiërarchische 121

structuur van capabilities als een boom op een hemisfeer. Hierdoor kunnen de relaties gemakkelijk worden weergegeven (zowel de verticale als de horizontale). Dit model steunt evenwel op andere modellen met betrekking tot het opstellen van de hiërarchische structuur. Ten slotte werd de Value Delivery Modeling Language bekeken dat als doel heeft om weer te geven hoe waarde wordt gecreëerd en uitgewisseld binnen een ecosysteem. Bedrijven maken gebruik van capabilities om deze waarde te creëren. Het hoofddoel van dit model is evenwel niet om specifiek capabilities te modelleren. We zijn er ons van bewust dat deze analyse zijn tekortkomingen heeft. Aangezien de term capability nog maar recent begonnen is aan zijn opmars, komen er elke dag nieuwe visies naar boven. Het is onmogelijk om deze allen te incorporeren. Dat heeft als gevolg dat sommige conclusies die we maken niet meer relevant zijn op het moment van schrijven. Toekomstig onderzoek zal dus voornamelijk moeten worden toegespitst op het verder uitdiepen van het kennisveld rond capabilities. In de toekomst zal moeten gegaan worden naar een uniforme definitie van capabilities waar er geen twijfel is tussen een capability en een proces, en waarbij er moet gestreefd worden om een model te ontwikkelen waarin alle visies zich kunnen vinden.

7.2 GEVALLENSTUDIE Het tweede deel van deze masterproef omvat een gevallenstudie waarbij elk van de vier besproken modellen werden toegepast op een voorbeeldbedrijf. Aldus zien we hoe elk van de modellen in de praktijk zijn werking vindt. Aan de hand van deze gevallenstudie werden dan ook de modellen geëvalueerd aan de hand van enkele opgestelde criteria. In het eerste hoofdstuk binnen dit deel werd het voorbeeldbedrijf AB InBev voorgesteld en onder de loep genomen. Dit werd gedaan door de operaties, de visie, missie, strategie en doelen van AB InBev te beschrijven. Deze laatste vier concepten werden vervolgens geformaliseerd aan de hand van het Business Motivation Model. Het tweede hoofdstuk omvat dan de eigenlijke gevallenstudie waarbij gestart werd met het opstellen van criteria waaraan een goed capabilitymodel moet voldoen. De elementen die aanwezig moeten zijn in een goed capabilitymodel zijn de volgende: 122

-

Omschrijving wat de capability doet

-

Service level

-

Inkapseling van mensen, processen en procedures, technologie

-

De interacties tussen verschillende capabilities

-

De eigenaar van een capability

-

Attributen van een capability

-

Visualisatie van de capabilities

-

Ondersteuning van tools

Deze criteria werden vervolgens gebruikt als structuur om de gevallenstudie aan te vatten. Zowel Microsoft en IBM modelleren elk op hun eigen manier capabilities en elk van de twee modellen bevatten alle elementen die we hebben vooropgesteld. IBM scoort iets beter wat betreft het weergeven van de horizontale interacties van de capabilities. Wat betreft ondersteuning van tools scoren beide modellen niet uitermate hoog. Microsoft en IBM zullen intern wel tools gebruiken maar voor derden is het niet duidelijk hoe dit het beste wordt aangepakt. Klinkmüller et al. bouwen verder op andere modellen en pakken eigenlijk alleen de attributen en het visualisatieaspect aan. Daarin geven ze een duidelijk beeld van de hiërarchie van de capabilities alsook van de horizontale interacties. Aangezien de visualisatiemetafoor van Klinkmüller et al. kan voortbouwen op andere modellen (bijvoorbeeld Microsoft), kan dit een duidelijke meerwaarde bieden. Ten slotte vinden we ook hier weinig tot geen tools ter ondersteuning. VDML ten slotte is een model dat niet als doel heeft om capabilities te modelleren. In deze taal vinden we eerder concepten terug die gebruikt worden om de manier waarop waarde wordt gecreëerd en geleverd weer te geven. Aldus is de uitwerking van het concept capability niet erg uitgebreid. Veel elementen die we nodig achten in een goed capabilitymodel blijken niet aanwezig te zijn. Dat wil evenwel niet zeggen dat dit geen goed model is, want het is het enige model dat probeert om capabilities complementair 123

te gebruiken met andere bedrijfsmodellen zoals value modeling, REA, … Verder wordt VDML ondersteund door een tool die mee ontwikkeld wordt met de taal zelf. Het derde en laatste hoofdstuk belicht kort hoe een capabilitymodel kan gebruikt worden in combinatie met meer abstracte modellen zoals het Business Motivation Model en meer operationele modellen zoals procesmodellen of servicemodellen. Daaruit bleek dat het Business Motivation Model en een capabilitymodel sterk gebruik kunnen maken van elkaar in beide richtingen. Het Business Motivation Model kan een capabilitymodel gebruiken ter validatie van de strategie terwijl een capabilitymodel het Business Motivation Model kan gebruiken om attributen te meten. De link met procesmodellen wordt vervolgens bekeken waarbij we zien dat capabilities op een lager niveau rechtstreeks kunnen gelinkt worden aan een proces dat in een procesmodel kan worden omschreven. Projecten om de performance van capabilities te verhogen kunnen worden opgestart door te kijken of er iets kan veranderd worden aan het proces zelf. Uiteraard zijn we ons ook hier bewust van de beperkingen waarmee we te maken hadden. In deze masterproef werd maar één enkele gevallenstudie bekeken waarbij we een multinational binnen de context van consumptiegoederen hebben gebruikt als voorbeeld. Toekomstig onderzoek zou kunnen kijken of een bedrijf dat bijvoorbeeld diensten levert en qua omvang stukken kleiner is, ook baat heeft bij een capabilitymodel. Verder hebben we ons moeten beperken tot delen van het capabilitymodel verder uit te diepen. Het is mogelijk dat we hierdoor bepaalde aspecten niet hebben kunnen bevatten. Toekomstig onderzoek kan hierop inspelen door een gevallenstudie volledig uit te werken. Ten slotte hebben we maar heel kort onderzocht hoe de relatie is tussen een capabilitymodel en verschillende andere modellen. Het is duidelijk dat alvorens capabilitymodellen een brede toegang tot de praktijk zullen vinden, eerst bepaald moet worden hoe deze op een relevante manier kunnen bijdragen tot het reeds bestaande pallet van bedrijfsmodellen.

124

BIBLIOGRAFIE AB InBev, 2011, Global Citizenship Report, URL: Antunes G., Borbinha J., 2013, Capabilities in Systems Engineering: An Overview, 4th International Conference, IESS 2013, Porto, Portugal, February 7-8, 2013, Proceedings, p.29-42 Bredemeyer D., et al. , 2002, Enterprise Architecture as Business Capabilities Architecture, Bredemeyer Consulting, URL: (16/12/2012) Cook D., 2007, Business-Capability Mapping: Staying Ahead of the Joneses, MSDN Library, URL: Cordys, CSC, 2012, Value Delivery Modeling Language (VDML), OMG Submission Document, OMG Document Number bmi/2012-11-06, 12/11/2012 Crippa A., 2004, From CBM to SOA: the successful way to reach flexibility and keep costs controlled, IBM Institute for Business Value, URL: (24/04/2013) Cummins F., 2012, Value Delivery Modeling Language (VDML): An Update, Building the Agile Enterprise, URL: (02/04/2013) Davenport T., 1993, Process Innovation: Reengineering work through information technology, Harvard Business School Press, Boston De Man H., Berre A.J., 2012, VDML Manufacturing Use Case, OMG Document, bmi/202-1110 Doig G., 2007, Microsoft Services Business Architecture (MSBA) – getting started with SOA, Microsoft consulting service, URL:

XV

(18/12/2012) Federal Enterprise Architecture, 2007, FEA Consolidated Reference Model version 2.3 Freitag A., Matthes F., Nowobilska A., Schulz C., 2011, A method for business capability dependency analysis, International Conference on IT-enabled Innovation in Enterprise (ICITIE2011), Sofia Grant R., 2009, Chapter 5: Analyzing Resources and Capabilities, Contemporary Strategy Analysis 7th Edition, London, Willey, p.120-149 Greski L., 2009, Business capability modeling: Theory & Practice, Architecture & Governance magazine, Volume 5 Issue 7, URL: (16/12/2012) Hafeez K., Malak N., Zhang Y.B., 2007, Outsourcing non-core assets and competence of a firm using analytic hierarchy process, Computers & Operations Research, Vol. 34 Iss. 12, December 2007, p.3592-3608 Harmon P., 2011, Capabilities and Processes, BPTrends Vol. 9 No. 13, July 2011 Henderson J.C., Venkatraman N., 1999, Strategic Alignment: Leveraging information technology for transforming organizations, IBM Systems Journal, Vol. 38 Iss. 2.3, p.472-484 Homann U., 2006, A Business-Oriented Foundation for Service Orientation, MSDN Library, URL: (16/12/2012) Keller W., 2009, Using Capabilities in Enterprise Architecture Management, Version of 18/12/2009, URL: (24/04/2013) Klinkmüller C., Ludwig A., Franczyk B., Kluge R., 2010, Visualising Business Capabilities in the Context of Business Analysis, Business Information Systems 13th XVI

International Conference, BIS 2010, Berlin, Germany, May 3-5, 2010, Proceedings, p.242-253 Lloyd M., 2006, Microsoft Motion business architecture methodology, Microsoft Architect Insight Conference, Newport, Gwent, March 2006, URL: (24/04/2013) Maes R., 2007, An Integrative Perspective on Information Management, PrimaVera Working Paper 2007-09, April 2007 Malik N., 2008, Merging Capability Modeling with Process Modeling, MSDN Blog, Inside Architecture, URL: (15/02/2013) Merrifield R., 2009, Rethink: A business manifesto for cutting costs and boosting innovation, FT Press 1st Edition, 244 p Merrifield R., Calhoun J., Stevens D., 2008, The next revolution in productivity, Harvard Business Review, June 2008, Vol. 86 Iss. 6, p.72-80 Microsoft, 2006, Microsoft Motion: Heat Mapping Tool, Microsoft Services, URL: < blogs.microsoft.co.il/files/folders/2034/download.aspx> (24/04/2013) Pohle G., Korsten P., Ramamurthy S., 2005, Component business models: Making specialization real, IBM Institute for Business Value Porter M.E., 1985, The Competitive Advantage: Creating and Sustaining Superior Performance, New York Free Press Prahalad C.K., Hamel G., 1990, The Core Competence of the Corporation, Harvard Business Review, Vol. 68 No. 3, p.79-91 Quinn J.B., 1999, Strategic Outsourcing: Leveraging Knowledge Capabilities, Sloan Management Review, Vol. 40 No. 4, p.9-21

XVII

Rosen M., 2010, Business Processes Start with Capabilities, BPTrends Columns and Articles, URL: (15/02/2013) Scott J., 2009, Business Capability Maps: The Missing Link Between Business Strategy and IT Action, Architecture & Governance magazine, Vol. 5 Iss. 9, p.1-4 Scott J., Cullen A., An M., 2009, Business Capabilities Provide The Rosetta Stone For Business-IT Alignment, Forrester Research Scott J., Cullen A., An M., 2010, The Anatomy Of A Capability Map, Forrester Research Sharp A., 2011, Capabilities, Agile and “Process Blindness”, BPTrends Columns and Articles, URL: (16/02/2013) Sykes M., Clayton B., 2009, Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture, The Architecture Journal, Vol. 20, p.20-25 The Business Rules Group, 2010, The Business Motivation Model, Release 1.4, May 2010 Thompson A., Peteraf M., Gamble J., Strickland A., 2011, Crafting and Executing Strategy: the quest for competitive advantage 18th edition, McGraw-Hill Education, New York Tuna H., 2009, Service Oriented Modeling, Microsoft Architect Insight Conference 2009, Microsoft London, 8th May 2009 Ulrich W., Rosen M., 2011, The Business Capability Map: The “Rosetta Stone” of Business/IT Alignment, Enterprise Architecture, Vol. 14 No. 2, March 2011, p.1-23 Van Diessen R., Sierman B., Lee C., 2008, Component Business Model for Digital Repositories: A Framework for Analysis, Proc. iPRES 2008

XVIII

BIJLAGE A: BUSINESS MOTIVATION MODEL METAMODEL

XIX

BIJLAGE B: GENERIEKE LIJST VAN CAPABILITIES VOLGENS MICROSOFT 1.0 Ontwikkel Product/Dienst 1.1 Ontwikkel Product/Dienst 1.1.1 Ontwikkel Nieuw Product/Dienst Concept en Plannen 1.1.2 Design Nieuwe Product/Diest en Processen 1.1.3 Beheer Bestaand Product/Dienst 1.1.4 Lanceer Nieuw Product/Dienst 1.1.5 Ontwikkel Nieuwe Product/Diest 1.1.6 Trek Bestaand Product/Dienst terug 2.0 Creëer Vraag (CRM) 2.1 Partner Relaties Beheer 2.1.1 Kanaal Management 2.2 Marketing 2.2.1 Marketing Beheer 2.2.2 Business Intelligence 2.3 Verkoop 2.3.1 Order Beheer 2.3.2 Sales Beheer 2.3.3 Onmiddellijk Gevulde Sales (POS) 2.3.4 Product en Prijs configuratie/validatie 2.3.5 Contract Beheer 2.3.6 Kwalificeer Prospecten 2.3.7 Business Intelligence 3.0 Lever Product/Dienst 3.1 Lever Dienst 3.1.1 Klanten Interactie 3.1.2 Service Ter Plaatse 3.1.3 Lever Diensten aan specifieke klanten 3.1.4 Business Intelligence 3.2 Plan LT Uitvoering 3.2.1 Planning van Koopwaar 3.2.2 Planning van Vraag 3.2.3 Planning van Aanbod 3.2.4 Planning van Voorraad 3.2.5 Productie Schema Opstellen 3.3 Aankoop 3.3.1 Bron en Leverancier Beheer 3.3.2 Aankopen 3.3.3 Ontvangen van Indirecte/Kapitaalgoederen

XX

3.4 Produceer Product 3.4.1 Fabriceer Product 3.4.2 Assembleer Product 3.4.3 Test Product 3.4.4 Kwaliteitscontrole 3.5 Lever Product (Logistiek) 3.5.1 Order Vervulling 3.5.2 Beheer van Transport 3.5.3 Beheer van Voorraad 3.5.4 Beheer van Magazijn 3.6 Onderhoud Business Intelligence 3.6.1 Vervul Analyse van Vraag 4.0 Plan en Beheer Onderneming (ERP) 4.1 Financieel Beheer 4.1.1 Beheer AP 4.1.2 Beheer Treasury 4.1.3 Beheer AR 4.1.4 Verwerk Elektronische 'Funds' 4.1.5 Budgetteer 4.1.6 'General Ledger' 4.1.7 Beheer Kapitaal 4.1.8 Business Intelligence 4.2 Project Beheer 4.2.1 Beheer Project 4.2.2 Project Accounting 4.2.3 Business Intelligence 4.3 Beheer Human Resources 4.3.1 Beheer Tijd en Uitgaven 4.3.2 Betaal Werknemers Uit 4.3.3 Administratie van Voordelen (Benefits) 4.3.4 Human Resources 4.3.5 Business Intelligence 4.4 Beheer IT Diensten 4.4.1 Lever IT Gebaseerde Diensten 4.5 Beheer Cultuur en Bedrijfswaarden 4.5.1 Beheer Bedrijfswaarden 4.5.2 Stimuleer Cultuur 5.0 Beheer Samenwerking 5.1 Beheer Strategische Samenwerking 5.1.1 Beheer Partnering Strategie 5.1.2 Beheer en Plan Product/Dienst Concept 5.2 Beheer Cross-groep Planning 5.2.1 Design en Ontwikkel Producten en Processen 5.2.2 Beheer Policies

XXI

5.2.3 Beheer Vraag 5.2.4 Beheer Aanbod 5.3 Beheer Operaties 5.3.1 Beheer Visibilitieit Middelen 5.3.2 Beheer Visibiliteit Fulfillment

XXII

BIJLAGE C: GENERIEKE COMPONENT BUSINESS MAP VAN IBM Generieke Component Business Map:

Generieke Component Business Map (consumptiegoederen):

XXIII

Op zoek naar de essentie van een bedrijf: het modelleren van business capabilities

Recommend Documents