4.6. Hoe richt u applicatiemanagement zo in dat ze aan de steeds

Uitvoering van IT-diensten De nieuwe generatie applicatiemanagement-outsourcing: multi-client

4.6

De nieuwe generatie applicatiemanagement-outsourcing: multi-client

251

oe richt u applicatiemanagement zo in dat ze aan de steeds nieuwe en hogere eisen van de klant kan voldoen en ook op strategisch niveau toegevoegde waarde levert? Kees de Wit en Pieter Essing geven u met hun beschrijving van het multi-clientmodel de handvatten om deze uitdaging aan te gaan.

H

INLEIDING Applicatiemanagement speelt al sinds langere tijd een belangrijke rol in de ondersteuning en instandhouding van de businessoperaties van organisaties. In toenemende mate speelt applicatiemanagement ook een sleutelrol in de verandering van organisaties. De business ziet de IT-functie – en het daar onder vallende applicatiemanagement - steeds meer als een volwaardige partner om samen veranderingen mee door te voeren en zo de operationele, tactische en strategische doelstellingen van de organisatie te verwezenlijken (zie figuur 1: Toenemend business-IT-alignment). Modern management van applicaties betekent dus anticiperen op de actuele ontwikkelingen in de inrichting en besturing van organisaties. Hedendaagse organisaties, die zijn ingericht als dynamische netwerken en voortdurend hun applicatieportfolio innoveren, stellen nieuwe, hoge eisen aan de inrichting van applicatiemanagement. Flexibiliteit, continuïteit, kostenefficiëntie, businesswaarde en ondersteuning van transitieprocessen zijn succesfactoren waar applicatiemanagement rekening mee zal moeten houden. Dit artikel beschrijft een model voor applicatiemanagement dat klaar is voor deze uitdaging: het multi-clientmodel. Dit model dient als illustratie voor de wijze waarop applicatiemanagement zich als volwaardige partner aan de business kan binden. Het model heeft zich in de praktijk bewezen en is inzetbaar door zowel externe dienstverleners (‘service providers’) als door interne dienstverleners (de interne IT-afdeling).

SUCCESFACTOREN VAN APPLICATIEMANAGEMENT Organisaties zijn in toenemende mate georganiseerd als dynamische netwerken van geografisch verspreide organisatieonderdelen in relatie met al dan niet tijdelijke partners. Organisaties breiden uit, nemen andere organisaties over, fuseren, en transformeren met steeds korter durende cyclus. Bedrijfsapplicaties moeten deze dynamiek van organisaties kunnen ondersteunen en dit vereist een voortdurende innovatie van de applicatieportfolio. Innovatie van de applicatieportfolio heeft echter zijn weerslag op de inrichting van applicatiemanagement en op de wijze waarop dienstverleners applicatiemanagement als service aanbieden. Deze impact komt tot uiting in verschillende factoren en in verschillende dimensies .

4

In de eerste plaats vereist het een hoge mate van flexibiliteit om tegemoet te komen aan de voortdurend veranderende doelstellingen, eisen en wensen van de business. Dienstverleners - zowel externe dienstverleners als interne dienstverleners - fungeren steeds meer als sparringpartner van de business om voortdurend een transitie door te maken: verandering is de enige zekerheid. Daarbij wordt de complete applicatieportfolio ingezet om de operationele, tactische en strategische bedrijfsdoelstelling te realiseren. Flexibiliteit speelt een belangrijke rol in vijf verschillende dimensies: 1. flexibiliteit in de ondersteuning van de soort technologie of het type applicatie: product-

IT Service Management, best practices, deel 4 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

Shared service centra

252

Businessalignment

Hoog

IT-afdeling

Middel

Laag

Rekencentra

1970-80

1990-2000

2000-

Tijd Figuur 1 Business-IT-alignment: van operationele ondersteuning naar businesspartner

bereik (‘product scope’) en ‘capability’; 2. flexibiliteit in het type services: het servicebereik (‘service scope’); 3. flexibiliteit in de eisen aan de service (‘servicerequirements’); 4. flexibiliteit in het volume van de service (‘servicevolume’); 5. flexibiliteit in de wijze waarop en waarvandaan dienstverleners de services aanbieden: het ‘deliverymodel’. De dienstverlener moet in elk van deze dimensies de gewenste of noodzakelijke veranderingen snel kunnen opvangen en adequaat kunnen doorvoeren in zijn dienstverlening. Typische voorbeelden van veranderingen die een organisatie in elk van de vijf dimensies initieert (businessdrivers) zijn: • Productbereik - Na overname of fusie is er behoefte aan applicatiemanagementservices voor extra applicaties of voor andere type applicaties of technologieën. • Servicebereik - Door de verschuiving van de vraag van operationele naar tactische en strategische services is er behoefte aan extra services zoals capaciteits- of beschikbaarheidsmanagement.

• Servicevereisten - Meer bedrijfskritische applicaties vereisen het verder aanscherpen van de servicelevels voor de servicedesk (bijvoorbeeld de responsetijden) of de oplostijden voor incidenten. • Servicevolume - De behoefte aan meer capaciteit om een (tijdelijke) verandering in volume te kunnen opvangen, bijvoorbeeld tijdens een drukke periode van de organisatie (bijvoorbeeld jaarafsluiting). Een ander voorbeeld is de vraag naar het uitvoeren van wijzigingsverzoeken (changerequests) bovenop de reguliere ‘break/fix’ werkzaamheden. Dit verandert overigens ook in de dimensie servicebereik. • Deliverymodel - De behoefte om services op een andere wijze of vanuit een extra of andere locatie geleverd te krijgen, bijvoorbeeld vanuit een nearshore- of offshorelocatie. Driver van deze behoefte kan kostenreductie zijn, of de noodzaak van lokale aanwezigheid. Deze dimensie van flexibiliteit heeft dus een sterke relatie met de factor kostenefficiëntie. Flexibiliteit is direct gerelateerd aan een andere belangrijke factor, namelijk continuïteit. Stabiliteit en betrouwbaarheid van kwalitatief

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


hoogwaardige diensten vereist het vinden en behouden van goed opgeleid personeel dat zich kan aanpassen aan de veranderende omstandigheden. In de tweede plaats ziet de business de ITfunctie steeds meer als een volwaardige partner met de bijbehorende kosten-batenanalyses en key performance indicatoren (KPI’s). De business verwacht van de IT-functie dat ze zo kostenefficiënt mogelijk diensten levert en ziet applicatiemanagement nog steeds (te) vaak als louter een kostenpost. Kostenefficiëntie is dus een belangrijke factor. Organisaties kijken echter ook steeds kritischer naar de werkelijke toegevoegde waarde (‘businessvalue’ of bedrijfswaarde) van applicatiemanagement voor de business. Dit betekent dat de organisatie de toegevoegde waarde steeds vaker meet aan de mate waarin applicatiemanagement de bedrijfsdoelstellingen ondersteunt. Een gevolg hiervan is dat de KPI’s die gerelateerd zijn aan applicatiemanagement verschuiven naar KPI’s die meer aan bedrijfsdoelstellingen zijn gerelateerd. Daarnaast verwachten organisaties dat externe dienstverleners steeds meer de rol van ‘service integrator’ vervullen. In deze rol neemt de dienstverlener het management van het hele spectrum van de (uitbestede) services over en integreert deze op de operationele, tactische en strategische niveaus. De servicelevelrapportages bevatten dan de geaggregeerde en geconsolideerde gegevens. Operationele data worden hierbij omgezet naar bedrijfsgerelateerde KPI’s. Op de derde plaats besteden organisaties naast applicatiemanagement ook hun applicatieontwikkeling steeds vaker volledig uit aan externe dienstverleners. Deze partijen staan vaak volledig ‘los’ van de toekomstige applicatiemanagement-organisatie. Dit betekent dat bedrijven veel aandacht moeten besteden aan de transitie van de nieuw ontwikkelde of aangepaste applicaties vanuit de projectsituatie naar de operationele situatie. Vroegtijdige betrokkenheid van de applicatiemanagementorganisatie en een geïnstitutionaliseerd transitieproces zijn daarbij sleutels tot succes.

Alle hierboven besproken aspecten - flexibiliteit, continuïteit, kostenefficiëntie, bedrijfswaarde, en transitie - vormen de belangrijkste succesfactoren van hedendaags applicatiemanagement. Adequaat invulling geven aan deze factoren is van groot belang voor goed applicatiemanagement. Een model voor applicatiemanagement zal dus rekening moeten houden met de succesfactoren zoals hierboven zijn geïntroduceerd.

253

Een goed voorbeeld van een succesvol model voor applicatiemanagement dat zich in de praktijk heeft bewezen, is het multi-clientmodel. Het multi-clientmodel Het multi-clientmodel is een innovatief model voor applicatiemanagement. Een applicatiemanagementorganisatie die is opgezet volgens dit model levert eenduidige, uniforme en consistente services aan klanten zonder dat er afbreuk wordt gedaan aan de specifieke eisen en wensen. De crux van het model is het voortdurend optimaal inzetten en delen van ‘capabilities’ (resources, capaciteit, kennis en kunde) gestuurd op basis van ‘demand’ (vraag). Het anticiperen op verandering in ‘demand’ – bijvoorbeeld het aansluiten van een nieuwe klant – is eenvoudig omdat de organisatie gebruikmaakt van reeds bestaande ‘capabilities’ die, afhankelijk van de specifieke eisen en wensen, in meer of mindere mate kunnen worden ingezet. Het model heet ‘multi-client’ omdat een applicatiemanagement-organisatie volgens dit model verschillende klanten kan bedienen zonder dat ze de structuur en inhoud van het model voor een specifieke klant moet aanpassen. Het model biedt één uniforme oplossing voor het leveren van services aan meerdere klanten (multi-client). Het multiclientmodel is ontwikkeld en in gebruik genomen door een externe dienstverlener maar kan ook heel goed door interne dienstverleners worden gebruikt.

4

De succesfactoren en het multi-clientmodel De succesfactoren van een succesvol model voor applicatiemanagement zijn in een vorige


254

paragraaf uitgewerkt. Het multi-clientmodel vertaalt en interpreteert deze belangrijke succesfactoren als volgt: • Flexibiliteit - Dit is een aspect van servicemanagement. Het gaat hier om het snel en adequaat kunnen inspelen op verandering in de vijf dimensies van flexibiliteit: − productbereik - bijvoorbeeld SAP IS-U / CRM, ABAP, Documentum, of FileNet; − servicebereik - bijvoorbeeld servicedesk, incidentmanagement, changemanagement; − servicevereisten - bijvoorbeeld responsetijden of oplostijden; − servicevolume - bijvoorbeeld het aantal af te handelen calls of wijzigingsverzoeken per tijdseenheid of het aantal inzetbare FTE’s; − deliverymodel - bijvoorbeeld de locaties Almere, Malaga, of Mumbai. • Continuïteit - Dit is een aspect van service-operations. Het gaat hier om borging van de toegang tot de juiste kennis en behoud van toegang tot gekwalificeerd personeel.

• (Kosten)efficiëntie - Dit is een aspect van service-operations. Het gaat hier om het gebruik maken van geïnstitutionaliseerde, gestandaardiseerde en geoptimaliseerde processen gebaseerd op ‘industry best practices’. • Bedrijfswaarde: Dit is een aspect van servicedelivery en servicemanagement - Het gaat hier om het sturen op geaggregeerde meetinstrumenten (de juiste KPI’s) en geconsolideerde rapportages, gelieerd aan bedrijfsdoelstellingen en bedrijfsprocessen. • Transitie - Dit is een aspect van servicetransitie. Het gaat hier om naadloze aansluiting van applicatiemanagement op de projecten en vroegtijdige betrokkenheid van applicatiemanagement bij deze projecten. Een belangrijk proces hierbinnen om transitie te beheersen is releasemanagement.

SM

SM

TL

SAP IS-U

X

X

TL

SAP – R/3

X

X

X

X

TL

SAP CRM

X

X

X

X

TL

EAI

X

X

X

X

TL

Klanten

ABAP

Operation Lead

Services Cluster Lead

Derde partijen Legenda: SM (Service Manager) TL (Team Lead) SAP, SAP-R3 etc. Services Cluster Lead Operations Lead

SM

SM

SM

SLA

X

X X

= servicemanager, stuurt de klant aan = teamleider, stuurt een of meer capabilityteams aan = capabilityteams = senior management: stuurt servicemanagement en operationsmanagement aan = verantwoordelijk voor service-operations, stuurt teamleiders aan

Figuur 2 Structuur van het multi-clientmodel



DE STRUCTUUR VAN HET MULTI-CLIENTMODEL In deze sectie kunt u lezen hoe een model voor applicatiemanagement dat is gebaseerd op het multi-clientconcept concreet invulling kan geven aan de succesfactoren van applicatiemanagement. Generieke opzet De opzet en inrichting van een multi-clientmodel vergt zorgvuldige aandacht. Het model is goed te vergelijken met een tweedimensionale matrixorganisatie. Zoals eerder aangegeven is het model toepasbaar voor zowel externe dienstverleners als interne dienstverleners. Bij externe dienstverleners spreken we over klanten (of klantgroepen, indien een aantal klanten min of meer dezelfde eisen hebben). Bij inzet van een multi-clientmodel bij interne dienstverleners spreken we over afdelingen of bedrijfseenheden die intern als klant worden beschouwd. De eerste dimensie van de matrix is de dimensie ‘kunde’ (‘capability’). De tweede dimensie is ‘klant’, dus de interne of externe klant die wordt bediend (klantgroep, afdeling, of bedrijfseenheid). De drivers van flexibiliteit en schaalbaarheid werken langs deze twee dimensies van het model. In de klantdimensie (verticale richting) werken de drivers van verandering in servicebereik en servicevereisten via servicemanagement. In de kennisdimensie (horizontale richting) werken de drivers voor verandering in productbereik en servicevolume via service-operations. Besturing De besturing van het model is cruciaal voor een goede onderlinge afstemming tussen de dimensies ‘klant’ en ‘capabilities’, die een natuurlijk spanningsveld met elkaar hebben. De aansturing in het model vindt vanzelfsprekend ook in twee dimensies plaats: serviceoperations stuurt de dimensie ‘capabilities’ aan en servicemanagement stuurt de dimensie ‘klant’ aan. Servicemanagement heeft primair de verantwoordelijkheid om met de klant de services in alle servicedimensies

met alle bijhorende (commerciële) aspecten af te stemmen (contract, SLA). Service-operations heeft primair de verantwoordelijkheid voor servicedelivery: om de diensten te leveren conform de afspraken die servicemanagement met de klant heeft gemaakt. Beide besturingsdimensies staan natuurlijk niet los van elkaar maar zijn volledig op elkaar afgestemd. De organisatie, de besturing- en overlegstructuren zijn zo ingericht dat er een continue afstemming plaatsvindt (zie figuur 2). Serviceoperations én servicemanagement hebben een gezamenlijke overlegstructuur en rapporteren beide aan het senior management (services cluster lead). De verantwoordelijkheden binnen services-operations liggen bij de operations lead die de verschillende teamleiders (TL) van de capabilityteams aanstuurt. Binnen servicemanagement ligt de verantwoordelijkheid bij de servicemanager (SM). Door strikte opvolging van deze rollen en verantwoordelijkheden, optimale samenwerking en zoveel mogelijk gestandaardiseerde contracten en/of afspraken samen met servicemanagement, kan de klant continu de beste oplossing krijgen. Organisaties kunnen zo op basis van veranderingen in de markt of de organisatie tijdig prioriteiten bijstellen.

255

4

SUCCESFACTOREN VAN HET MODEL Het multi-clientmodel geeft invulling aan de beschreven succesfactoren voor hedendaags applicatiemanagement. In de volgende paragrafen geven we hiervan een praktische interpretatie. Flexibiliteit Veranderende behoefte in productbereik, servicebereik en servicevereisten Het multi-clientmodel maakt gebruik van teams met verschillende kennisdomeinen (‘capabilityteams’), en maakt gebruik van verschillende diensten en past de servicelevels aan. Kennisgebieden omvatten de verschillende technologieën (bijvoorbeeld Java/J2EE, ABAP) en/of type applicaties (bijvoorbeeld SAP, Documentum). Wat betreft de diensten


Projects Separately planned, agreed to Business value-based

256

New Modules/functionality Additional businesss units Software upgrades

Discretionary Capacity based Adjusted periodically based on joint planning session Schedule/budget measured

Minor enhancements Minor upgrades User training Ad-hoc user requests

Non-Discretionary Service based SLA-measured and committed Problem management Release management

Break/fix Tier 2 helpdesk Vendor patch management Documentation support Change control

Service Management Figuur 3 Indeling in typen services

werkt een applicatiemanagementteam binnen het multi-clientmodel in een ideale situatie uitsluitend met een ‘menukaart’ met standaarddiensten. Deze standaarddiensten zijn goed omschreven en laten zich uitstekend inplannen in de werkroosters van de teams. Behoefte aan flexibiliteit is echter realiteit en u zult dus in mindere of meerdere mate van de standaard moeten kunnen afwijken. De verhouding tussen gestandaardiseerd en niet-gestandaardiseerde diensten laat zien in hoeverre de dienstverlener de achterliggende functionaliteit en dagelijkse bedrijfsvoering van de klant inziet en begrijpt. Het multi-clientmodel deelt de diensten op in de volgende typen services: • Non-discretionary – gestandaardiseerde werkzaamheden. Deze werkzaamheden maken deel uit van de reguliere diensten die in (contractuele) afspraken zijn vastgelegd en moeten ervoor zorgen dat de overeengekomen servicelevels worden gehaald. Een kenmerk van deze werkzaamheden is de relatief korte horizon waarop ze betrekking hebben. Het betreft hier over het algemeen preventieve (‘patch’) en correctieve (‘break-fix’) werkzaamheden ‘to keep the lights on’. • Discretionary – niet-gestandaardiseerde werkzaamheden, vernieuwingen in de vorm van (kleine) wijzigingen.

De uitvoering van deze werkzaamheden is gebaseerd op inzicht in de bedrijfsplanning, prioriteiten en capaciteit. Discretionary werkzaamheden zijn gericht op kleinere wijzigingen en hebben een middellange horizon. • Projecten – vernieuwingen in de vorm van projecten. De planning, en grotendeels ook de uitvoering van deze werkzaamheden valt vaak tot het moment van oplevering buiten het multi-clientmodel. Het kan voorkomen dat specifieke kennis of vaardigheden vanuit het multi-clientmodel nodig zijn om een rol in de projectuitvoering in te vullen. Deze werkzaamheden hebben een middellange tot lange horizon. Servicevereisten zijn sterk aan verandering onderhevig. Als de vragende en de aanbiedende partij elkaar nog niet goed kennen is het belangrijk afspraken te maken over de onderdelen waar geen misverstanden over kunnen ontstaan. Dit moeten onderdelen zijn die goed zijn te meten en definiëren. Voorbeelden hiervan zijn: beschikbaarheid van een applicatie en een vaste afname van capaciteit. Naarmate de relatie tussen de partijen zich verder ontwikkelt moet de focus verschuiven van applicaties naar de eindgebruiker van de diensten en/of functionaliteit. Dan spreekt de dienstverlener de taal van de klant en kan hij



Vertaling van technologie en applicaties naar diensten

Losse technologie applicatie

Clustering van diensten

257 Type dienstverlening Figuur 4 Toegevoegde waarde en beschrijving van de dienstverlening

prioriteiten proactief behandelen. De definitie van diensten of functionaliteiten van de eindgebruiker is precisiewerk en vergt een goede verstandhouding en wederzijds begrip tussen klant en dienstverlener. Als de servicevereisten diensten en functionaliteiten bevatten spreken we van volwassenheid in de relatie tussen vrager en aanbieder. Dit verduidelijkt ook de toegevoegde waarde van applicatiemanagement. Veranderende behoefte aan servicevolume Het multi-clientmodel maakt gebruik van afgemeten capaciteit van de ‘capabilityteams’. Zoals figuur 3 de indeling in type diensten laat zien, kunt u op basis van afgesproken beslissingscriteria in overleg kiezen tussen de verschillende werkzaamheden van applicatiemanagement. Zo kan vanuit het multiclientmodel een voorstel komen om voorrang te verlenen aan de oplevering van nieuwe functionaliteit boven bijvoorbeeld oplossing van incidenten bij gelijkblijvende inzet. Zo krijgt de klant keuzes voorgelegd. Een duidelijke vereiste hierbij is dat u de gemaakte keuze goed documenteert in de servicesupport-tooling en de daaruit voortvloeiende servicelevelrapportage. Veranderende behoefte aan deliverymodel Het multi-clientmodel maakt gebruik van een wereldwijd netwerk van applicatiemanagementlocaties. Verschillende factoren kunnen ten grondslag liggen aan de behoefte om verschillende locaties te gebruiken. Kostenbesparing kan een van de redenen zijn voor de inzet van offshorelocaties. Het is dan van be-

lang om een goede kosten-batenanalyse te maken om te bepalen waar het omslagpunt ligt. Met andere woorden: op welk moment wegen de extra investeringskosten op tegen de baten van het lagere arbeidsloon van de medewerkers op de offshorelocatie. Een andere reden kan zijn dat de benodigde kennis en capabilities niet voorhanden zijn in een near-shorelocatie. Of dat de klant een bepaalde lokale aanwezigheid in een bepaald deel van de wereld wenst. Het multi-clientmodel beschikt over een wereldwijd netwerk van beheerlocaties en dit is noodzakelijk om aan de flexibiliteitseisen van de klant tegemoet te komen. Continuïteit Toegang tot kennis Succesvol applicatiemanagement bestaat aan de ene kant uit het efficiënt beheren van de bestaande functionaliteit. Aan de andere kant is geen omgeving statisch – door ontwikkeling van applicaties en vernieuwing van de applicatieportfolio - en zal applicatiemanagement op gepaste en tijdige manier wijzigingen moeten invoeren. Door applicatiemanagement in te richten volgens de splitsing van deze verantwoordelijkheden, ontstaat er een natuurlijk spanningsveld waar de betrokkenen flexibel in kunnen opereren. In beide ‘poten’ van applicatiemanagement is kennis van cruciaal belang. Kennis voor de instandhouding van de applicatie en kennis van de markt en de steeds weer wijzigende eisen. Het multi-clientmodel borgt kennis op verschillende manieren: • training - zowel interne als externe training, gericht op inhoud en op vaardigheden;

4


258

• skill mix - optimale mix van niveaus in kennis en ervaring; • job rotation - roulatie van verantwoordelijkheden; • meritocratie - de beste mensen op de juiste plaats door continue performance-evaluaties en feedback. Gekwalificeerd personeel De kwaliteit van personeel is ook in het multiclientmodel een zeer belangrijke factor voor de kwaliteit van de totale dienstverlening. Maar wat maakt het dat iemand zich binnen het multi-clientmodel optimaal inzet voor de resultaten? Het omvormen van lokale ‘kennishelden’ tot een optimaal samenwerkend en synergetisch opererend team behoeft meer dan alleen een aantrekkelijk salaris. Wanneer het multi-clientmodel een bepaalde kritische massa of omvang bereikt, kan het zich ontplooien als een interessant werkgebied voor meerdere jaren waarin de ontwikkeling van het individu centraal staat. Deze persoonlijke ontwikkeling is natuurijk wel in belangrijke mate afhankelijk van leeftijd, kennisniveau en persoonlijke voorkeuren. Door het onderkennen, bijsturen, bespreken en vastleggen van deze ontwikkeling zal het multi-clientmodel dé keuze van een persoonlijke carrière zijn. Niet alleen verdieping in de technologie behoort tot de mogelijkheden, ook doorgroei naar specifieke industriegroepen of klanten is mogelijk. De vooraf beschikbare definitie van deze rollen en carrièrepaden is cruciaal voor de uiteindelijke afstemming van vraag en aanbod binnen het multi-clientmodel. Een duidelijke definitie van rollen en verantwoordelijkheden over een periode van drie tot zes maanden maakt het bovenstaande wederzijds transparant en is daarmee een onmisbare basis voor persoonlijke groei hetgeen een sleutelfactor is bij het behouden van gekwalificeerd personeel. (Kosten)efficiëntie Gestandaardiseerde en geoptimaliseerde processen Het multi-clientmodel richt applicatiemanagementprocessen in op basis van ITIL 1

met de randvoorwaarden en de context van CMMI1. Hoewel het CMMI-model niet primair is ontwikkeld voor applicatiemanagement, biedt CMMI een uitstekend raamwerk voor de inrichting van: 1. management en beheerprocessen op organisatieniveau; 2. een meetbare en stuurbare organisatie; 3. een organisatie waarin de voordurende verbetering van processen (en de output van de processen!) centraal staat. Implementatie van juist deze belangrijke (CMMI-)concepten tillen de applicatiemanagement-organisatie naar een hoger niveau. Op dit hogere niveau is de continue verbetering van de kwaliteit van dienstverlening een ‘natuurlijk’ proces omdat de CMMI-concepten zijn verankerd in de organisatie. De specifieke inrichting van de processen zelf kan prima op basis van best-practicemodellen. Voor de inrichting van de meeste beheerprocessen in het multi-clientmodel is gekozen voor ITIL. Waar CMMI dus de gehele applicatiemanagement-organisatie helpt bij het groeien naar het volgende volwassenheidsniveau, helpt ITIL bij de inrichting van geoptimaliseerde operationele beheerprocessen. Bij voldoende volwassenheid van de applicatiemanagement-organisatie (minimaal CMMIlevel 3) leiden de voordurende optimalisatiecycli tot gestandaardiseerde processen. Gestandaardiseerde processen zijn eenvoudige werkwijzen waarin de verantwoordelijkheden tussen vrager en aanbieder eenduidig zijn vastgelegd zodat beide partijen hier van meet af aan een helder beeld van hebben. De processen zijn ook noodzakelijk om tijdelijk of structureel personeel in te kunnen zetten van bijvoorbeeld applicatiemanagement-centra elders in de wereld. Hoewel het dan mogelijk is dat er niet dezelfde taal wordt gesproken, bieden de processen duidelijkheid over de wijze waarop het personeel moet samenwerken en wat de wederzijdse verantwoordelijkheden zijn. De kracht van de gestandaardiseerde processen ligt in de eenvoud. Eenvoud in het

Zie http://www.sei.cmu.edu/cmmi/general voor informatie over CMMI.



gebruik binnen het multi-clientmodel en eenvoud in de uitleg naar de deelnemers of de belanghebbenden (‘stakeholders’) van het proces. De grondslag van de toegevoegde waarde van deze processen ligt in de jarenlange ervaring met continue verbetering en simplificering van de werkwijzen. Bedrijfswaarde Geaggregeerde meetinstrumenten (en KPI’s) en geconsolideerde rapportage Het multi-clientmodel maakt servicelevelrapporten en gebruikt meetinstrumenten. Rapporteer niet alleen maar over KPI’s voor applicatiemanagement (bijvoorbeeld aantal incidenten) maar ook over KPI’s gerelateerd aan bedrijfsdoelstellingen (bijvoorbeeld het verwerken van een verkooporder, of de impact op de productieplanning). In het multi-clientmodel gebruikt u rapportage die in lijn is met de matrixorganisatie. Dat wil zeggen dat u zowel horizontaal (klanten bedrijfsspecifiek) als verticaal (technologie- of applicatiespecifiek) rapporteert. Afzonderlijke groepen die een gemeenschappelijk doel willen halen moeten hun doelstellingen definiëren en vertalen naar resultaten. Hoe vertaalt u de KPI’s die aan de bedrijfsdoelstelling zijn gerelateerd naar voor iedereen begrijpelijke en bestuurbare (technische) resultaten? 1. Maak de gehele keten naar de uiteindelijke functionaliteit zichtbaar. Het ‘ontleden’ van de keten kan veel tijd in beslag nemen. Het is echter de moeite waard hierin te investeren omdat u hiermee de basis legt voor het wederzijdse begrip tussen aanbieder en klant. 2. Stel de juiste prioriteiten van de componenten onderling en tussen de gewenste eindgebruiker diensten/functionaliteit. 3. Bewaak en rapporteer (bijna) real-time. Hierbij moet u een tijdslijn in acht nemen die zinvol is voor de dienst. Dit kan variëren van uren, dagen tot weken, maanden. Inzicht in de meetresultaten is de basis voor aansturing op het gebied van vaardigheden, aantallen resources en prioriteiten. Een transparante rapportage zal ook de klant direct toegang geven tot de meest actuele informatie over de dienstverlening.

Ondersteunende tools Ter ondersteuning van de hierboven beschreven processen zet u een tool in die alle belanghebbenden kunnen gebruiken. De aanbieder gebruikt de tool om alle serviceverzoeken goed bij te houden (dit is essentieel voor de aansturing van de capabilityteams). De klant kan de tool gebruiken om inzicht te krijgen in de actuele status van de dienstverlening in het multi-clientmodel. Ook kan het voordelen hebben als de andere aangesloten partijen gebruikmaken van of inzicht hebben in de gebruikte tool. De tool moet verder gaan dan alleen het bijhouden (‘loggen’) van serviceverzoeken. De impact op de SLA’s van de dienstverlening zou een standaardfunctionaliteit van de tool moeten zijn. Hiermee blijft de focus van het multi-clientmodel daar waar hij moet zijn: op de resultaten voor de klant door optimale IT-dienstverlening. Transitie Aansluiting op projecten Het multi-clientmodel faciliteert de inbeheername van (vernieuwings)projecten door de applicatiemanagement-organisatie, wat in de de praktijk een nogal onderbelicht deel van projectuitvoering is. Het model houdt de transitie op de volgende manieren laagdrempelig: • vroegtijdige deelname aan de projecten waarmee de applicatiemanagement-organisatie inzicht krijgt in het bereik en de mijlpalen en tijdig kennis krijgt overgedragen; • formele ‘sign-offs’ gedurende oplevermomenten in het project; • gestandaardiseerde en waar nodig geautomatiseerde kennisoverdracht; • gestandaardiseerde werkwijze waarmee een transparante intake kan worden gedaan met vragenlijsten; • transparante ‘exit-entrycriteria’. Dit betekent dus vastleggen van heldere criteria waaraan de betrokkenen moeten voldoen om een succesvolle overdracht tussen project en operations te waarborgen. Criteria om het transitieproces te starten maar ook duidelijke criteria om het proces te beeindigen.

259

4


260

Kennisoverdracht kunt u grotendeels automatiseren met gespecialiseerde tools. Vooral in een situatie waarin kennisoverdracht tussen verschillende internationale locaties moet plaatsvinden, kan dit grote kostenbesparingen opleveren. Besparingen kunnen oplopen tot wel 30% van de totale transitiekosten.

PRAKTIJKCASE De navolgende case illustreert de werking van het multi-clientmodel in de praktijk. Het geeft weer hoe een verandering - geïnitieerd door de business - gemakkelijk binnen het model kan worden opgevangen door rekening te houden met de belangrijke succesfactoren van applicatiemanagement. Situatieschets Een bedrijf in the energiebranche (klant A) initieert een splitsingstraject waarbij ze de netwerkactiviteiten willen behouden maar de leveringsactiviteiten willen afsplitsen en overdragen aan een ander energiebedrijf (klant B). Energiebedrijf A maakt gebruik van een klantenrelatiebeheersysteem en facturatiesysteem, met applicatiemanagement op basis van het multi-clientmodel. Ondanks dat het twee organisatorische eenheden (klanten) werden, was de wens van beide klanten om de impact van de splitsing te minimaliseren en zoveel mogelijk van de bestaande systemen en van de bestaande infrastructuur voor applicatiemanagement in stand te houden. Het multi-clientmodel in werking Na de verzelfstandig van klant A heeft er een project plaatsgevonden dat heeft geleid tot de implementatie van een ERP-systeem. Deze oplossing wordt voor klant A al ruim een jaar beheerd vanuit het multi-clientmodel. Vertaald naar de verschillende dimensies van flexibiliteit betekent bovenstaande situatie concreet: de toevoeging van een nieuwe klant met de instandhouding van het bestaande productbereik, servicebereik, en deliverymodel, echter met kleine aanpassingen aan de servicevereisten en een herverdeling van het servicevolume. Hieronder per dimensie van

flexibiliteit een beschrijving de praktische werking ervan binnen het multi-clientmodel. • Productbereik. Als basis voor klant B werd de template gebruikt van klant A. Concreet betekende dit dat de systemen werden gekloond, resulterend in twee identieke systemen voor klant A en klant B. Daarna werden bij iedere klant de niet meer benodigde functionaliteiten uitgezet: de leverantiefunctionaliteit in de systemen van klant A en de netwerkfunctionaliteit in de systemen van klant B. Een gedeelte van de functionaliteit was gedeeld, deze bleef operationeel in beide systemen. Daarnaast werden de data deels gesplitst en gemigreerd van het systeem van klant A naar het systeem van klant B. Omdat het totale productbereik niet was gewijzigd, kon gebruik gemaakt worden van de bestaande (gedeelde) capabilityteams. Met andere woorden de teams die eerst alleen klant A bediende, bedienen nu zowel klant A als klant B. • Servicebereik. De gewenste services (incidentmanagement, changemanagement) waren voor beide klanten identiek. Omdat beide klanten dezelfde processen en systemen gebruikten kon klant B eenvoudig meeliften op de bestaande infrastructuur. Het enige wat moest gebeuren was het kenbaar maken van een nieuwe klant in het servicesupportsysteem. • Servicevereisten. De servicevereisten voor servicelevels en servicelevelrapportages verschilden op detailniveau tussen klant A en klant B. Omdat de initiële servicelevelvereisten van klant A één op één konden worden overgenomen in het servicesupportsysteem was dit slechts een kwestie van het achteraf aanbrengen van wijzigingen. • Servicevolume. Het totale servicevolume was toegenomen door het bedienen van twee in plaats van één klant. Echter, door het gebruik te maken van dezelfde capabilityteams, dezelfde infrastructuur voor applicatiemanagement (servicedesk, processen, tools), en het delen van functionaliteit was de benodigde toename in menscapaciteit (FTE’s) veel lager dan je zou ver-



wachten bij het toevoegen van een tweede klant. • Deliverymodel. Er waren geen wensen in het wijzigen van het deliverymodel, zowel klant A en klant B maken gebruik van hetzelfde model. Een groot voordeel was dat ook dat klant B volledig gebruik kon maken van de bestaande capaciteit van technisch beheer (‘hosting’), die is uitbesteed aan een derde partij.

vereisten, servicevolume, en deliverymodel), continuïteit, kostenefficiëntie, bedrijfswaarde, en transitie. In de praktijkcase is een voorbeeld gegeven van hoe het multi-clientmodel functioneert in een reële praktijksituatie. Hieruit blijkt dat organisaties door de schaalbaarheid en flexibiliteit van het model snel en adequaat kunnen anticiperen op verandering in de praktijk van alle dag.

En wat de andere succesfactoren betreft: Continuïteit. Door hergebruik van de bestaande capabilityteams kon klant B volledig profiteren van de bestaande expertise, wat tot een stabiliteit van 100% heeft geleid. (Kosten)efficiëntie. Door optimaal hergebruik van systemen, mankracht, kennis, ervaring, processen, tools , enzovoort, konden de services zeer kostenefficiënt (30% lager) aan de nieuwe klant worden aangeboden. Transitie. Door het gebruik van een standaard transitiemethodologie met ondersteunende tools kon klant B naadloos worden ingebed in het multiclient-model.

Het multi-clientmodel kan door zijn structuur en opzet dus gemakkelijk anticiperen op de voortdurende dynamiek van organisaties. Schaalbaarheid en flexibiliteit in alle belangrijke dimensies en gebruik van business-KPI’s voor het leveren van toegevoegde waarde en continuïteit, zorgen ervoor dat applicatiemanagement met dit model klaar is om als volwaardige partner van de business te kunnen opereren.

Conclusie case Uit deze case blijkt dat het multi-clientmodel direct en adequaat kan inspelen op de veranderende behoeften van een organisatie. Door de flexibiliteit en schaalbaarheid van het model in de verschillende dimensies vergt dit geen aanpassing aan de structuur en opzet van het model. Hierdoor kunnen IT-afdelingen en - organisaties services zeer concurrerend aanbieden, en daar profiteren alle klanten van!

CONCLUSIES EN AANBEVELINGEN In dit artikel zijn de belangrijkste succesfactoren van hedendaags applicatiemanagement besproken en is een koppeling gelegd met de ‘businessdrivers’ die in belangrijke mate sturing geven aan applicatiemanagement. Het multi-clientmodel is besproken als een innovatief model voor applicatiemanagement dat adequaat invulling geeft aan de besproken succesfactoren. Deze succesfactoren zijn: flexibiliteit (in vijf verschillende dimensies: productbereik, servicebereik, service-

Voor de inrichting en toepassing van het multiclientmodel in uw eigen organisatie geven we u de volgende aanbevelingen mee: • Zorg voor voldoende schaalgrootte, ook per ‘capability’. Er is een bepaalde kritische massa nodig om dit concept effectief en efficiënt in te zetten. De minimale omvang van een ‘capabilityteam’ is 5 FTE. Met een lagere capaciteit is flexibiliteit in servicevolume bijvoorbeeld lastig te realiseren. • Standaardiseer de beheerprocessen en institutionaliseer deze processen op organisatieniveau. Ook verschillende capabilityteams met verschillende technische capabilities dienen volgens gestandaardiseerde processen te werken. Richt hiervoor een Quality Management System (QMS) in op organisatieniveau en gebruik CMMI als raamwerk voor de inrichting en sturing van organisatie en processen. Pas vanaf CMMI-level 3 kan het multi-clientmodel goed functioneren. Onder dit niveau werkt elk team nog teveel onafhankelijk van elkaar, ontstaat er geen geïntegreerd geheel en kan het model niet voldoende ‘bewegen’. Schenk naast de beheerprocessen ook voldoende aandacht aan de managementprocessen, zoals projectplan-

261

4


262

ning en risicomanagement. Bij een adequate CMMI- referentie komt dit echter in voldoende mate aan de orde. • Zorg voor een adequaat meetprogramma dat zowel interne gerichte (applicatiemanagement-organisatie) als extern gerichte (klant-)KPI’s meet. De interne KPI’s dienen aan te sluiten bij de doelstellingen van de applicatiemanagement-organisatie, de externe KPI’s bij de doelstellingen van de klant. Kees de Wit is Senior Executive bij Accenture Technology Solutions, en verantwoordelijk voor de Outsourcing Services. Hij heeft meer dan 15 jaar ervaring in IT - en applicatie-outsourcing in de professionele dienstverlening, zowel lokaal als in combinatie met offshore. Pieter Essing is Operations Manager bij Accenture Technology Solutions en heeft meer dan 14 jaar ervaring op het gebied van projectmanagement, transitie- en applicatiemanagement. Deze ervaring heeft hij opgedaan in de verschillende industriesectoren, in binnen- en buitenland.


4.6. Hoe richt u applicatiemanagement zo in dat ze aan de steeds

Recommend Documents