ITIL V3 is complexer en abstracter dan voorgaande versies, zo lijkt het. Niets is echter minder waar als we kijken naar het proces Request Fulfillment. Dit proces is bedoeld om de efficiëntie in het afhandelen van standaard aanvragen te vergroten en daarmee bureaucratie rondom de afhandeling van standaard wijzigingen te voorkomen. Elmer Pouw van Getronics PinkRoccade beschrijft de voordelen en succesfactoren.
Veel bedrijven hebben hun it-organisatie ingericht volgens ITIL en hebben daarmee het change management-proces ingeregeld. Vanuit klanten wordt over veel van deze it-organisaties nogal eens geroepen dat ze niet flexibel of zelf bureaucratisch zijn in de afhandeling van wijzigingen.
Lange doorlooptijd
Dit komt doordat in veel gevallen het uitgebreide change management-proces niet alleen gebruikt wordt voor de complexe wijzigingen, maar ook voor het uitvoeren van eenvoudige en standaard wijzigingen. Omdat de it-organisatie de totale impact van deze wijzigingen inzichtelijk wil hebben, om deze gecontroleerd door te kunnen voeren, kan de doorlooptijd van een wijziging behoorlijk oplopen.
Klanten zullen dit in veel gevallen overdreven vinden en ervaren het als een bureaucratisch-proces. Door op een juiste manier het change management-proces voor standaard wijzigingen te vereenvoudigen is deze vorm van bureaucratie eenvoudig te voorkomen. Request Fulfillment faciliteert hierin. Het is onderdeel van de service operation-processen en dus losgekoppeld van het change management proces, dat zich nu volledig kan richten op complexere wijzigingen.
Met het vooraf definiëren van standaard wijzigingen kunnen veel processtappen uit het change-proces proactief worden uitgevoerd. Dit houdt in dat deze stappen worden uitgevoerd op het moment dat de wijziging als standaard wijziging wordt gedefinieerd in plaats van op het moment dat de klant de aanvraag voor deze wijziging doet.
Hierdoor kunnen deze wijzigingen nog steeds op een gecontroleerde wijze worden doorgevoerd. De afhandeling is hierdoor in de ogen van de klant veel efficiënter, omdat bij het uitvoeren van deze standaard wijzigingen via het proces Request Fulfillment alle proactief uitgevoerde processtappen kunnen worden weggelaten.
Uitwerking processtappen
Een voorbeeld om te laten zien welke stappen proactief kunnen worden uitgevoerd is een aanvraag voor een Blackberry. Een apparaat dat een stijgende populariteit geniet en vanuit het perspectief van de klant zeker niets bijzonders meer is. Vanuit een it beheer-organisatie wordt hier echter vaak anders over gedacht.
De technologie is relatief nieuw en veranderd snel. Het opnemen van de Blackberry in de Service Catalogus vergt dan ook een aantal beslissingen binnen de it beheer-organisatie. Er moet bijvoorbeeld een analyse gedaan worden welke versies van de Blackberry voldoen aan de wensen van de business. Vanuit de techniek moet gekeken worden of de hosting van de dienst centraal (in eigen beheer) of decentraal (door bijvoorbeeld KPN) gedaan kan worden en of er voldoende kennis aanwezig is om het beheer en support op deze veranderende omgeving te doen. Vanuit beveiligingsoogpunt is het van belang dat bepaald wordt of het ontvangen en versturen van e-mail via een Blackberry wel is toegestaan?
Door deze vragen proactief (dus nog voordat de klant de aanvraag doet) te beantwoorden kan (via goedkeuring in het normale change proces) een keuze gemaakt worden of en hoe deze oplossing wordt opgenomen in de service catalogus. Ook kan de gekozen oplossing gebouwd en getest worden en eventueel zelfs een werkinstructie gemaakt worden voor het implementeren van de oplossing.
Op het moment dat de klant de aanvraag doet, hoeft alleen de (financiële) goedkeuring nog gegeven te worden en kan de uitlevering en installatie (met behulp van de gemaakte werkinstructie) op een efficiënte en standaard wijze worden uitgevoerd.
Voorbeelden van andere diensten waarbij het definiëren van standaard aanvragen van nut is, zijn aanvragen van pc, laptop, printer, (mobiele) telefoons en (mail) accounts. Minder voor de hand liggende, maar wel degelijk valide voorbeelden zijn standaard wijzigingen die doorgevoerd moeten worden op applicaties of databases.
Afhandeling standaard aanvragen
In het begin van dit artikel is al aangegeven dat het grootste voordeel van Request Fulfillment in de efficiëntie van de afhandeling zit. Dit efficiëntievoordeel ontstaat doordat een aantal processtappen proactief wordt uitgevoerd.
Zoals het Blackberry voorbeeld laat zien kan het goedkeuren van een wijzigingsverzoek binnen change management een behoorlijke stap zijn. De praktijk bij Nederlandse multinationals is ook dat bijvoorbeeld ‘even’ een nieuw model Blackberry introduceren er niet meer bij is. Veel partijen (beheerders, techneuten, service managers, account managers, procesmanagers, it security managers) zijn betrokken bij het maken van dit soort keuzes. Dit is bedoeld om de risico’s van het uitvoeren van wijzigingen te verkleinen maar resulteert in de praktijk vaak in een lange doorlooptijd. Dit wordt nogal eens versterkt omdat bij veel bedrijven de governance structuur niet helder is (en dus niet duidelijk is wie waarover zou moeten meebeslissen).
Ook het beschikbaar maken van nieuwe of aangepaste diensten kan een behoorlijke doorlooptijd hebben. In het Blackberry-voorbeeld zou het bijvoorbeeld goed kunnen dat er geïnvesteerd moet worden in nieuwe infrastructuur of dat er afspraken met een externe leverancier gemaakt moeten worden. Zelfs het beschikbaar stellen van een nieuw type Blackberry zal relatief veel tijd kosten, omdat uitgezocht moet worden of het werkt op de bestaande infrastructuur en of er training gevolgd moet worden in het kader van support.
Met het implementeren van Request Fulfillment worden deze stappen niet overgeslagen (en de genoemde problemen niet structureel opgelost), maar wel op een moment uitgevoerd dat deze ‘vertraging’ nog geen invloed heeft op de beleving van de klant.
Grotere klanttevredenheid
Met het implementeren van standaard aanvragen kunnen deze wijzigingen worden opgenomen in een service catalogus en kan eenvoudig aan de klanten inzichtelijk worden gemaakt welke diensten aan de klant aangeboden worden en hoe deze aangevraagd kunnen worden.
Klanten hoeven dan niet meer zelf te bedenken wat ze willen, maar krijgen keuzes voorgelegd. Dit geeft als resultaat dat klanten het gevoel krijgen dat de it-organisatie met hen mee denkt en het hen zo gemakkelijk mogelijk probeert te maken. Ook kan gemakkelijker het verschil aan de klant worden uitgelegd tussen standaard aanvragen en niet standaard aanvragen. Hiermee kan aan de klant worden uitgelegd dat (hoe klein het verschil vanuit de klant ook is) voor niet-standaard wijzigingen een langere doorlooptijd geld omdat daar een ander proces gevolgd moet worden.
In het Blackberry voorbeeld zal de klant eerder accepteren dat het beschikbaar maken van een nieuw type meer tijd kost dan het beschikbaar maken van de standaard aanvraag, omdat de klant zelf een keuze heeft tussen de standaard-oplossing of maatwerk.
Voorkoming van wildgroei
Bij het ontvangen van wijzigingsverzoeken wil de it-organisatie graag een functionele vraag van de klant ontvangen. De it-organisatie kan die functionele vraag dan vertalen naar de beste (lees: op de functionele vraag aansluitende, goedkoopste en voor de organisatie beheersbare) oplossing. In praktijk is het echter zo dat klanten vaak deze vertaling zelf al gemaakt hebben of zelfs direct een oplossing aanvragen.
In het Blackberry voorbeeld zal de klant zelf al een type hebben gevonden (waarschijnlijk met de mooiste uitstraling en de meest moderne opties of zelfs een compleet andere oplossing zoals een Smartphone). Omdat it-organisaties het vaak lastig vinden voordelen van beheersbare oplossingen te beargumenteren en klanten te overtuigen van de nadelen van de gevraagde oplossing, laten it-afdelingen zich vaak verleiden mee te gaan in de wensen van de klant.
Dit kan resulteren in grote verscheidenheid aan oplossingen (die uiteindelijk allemaal dezelfde functionaliteit bieden), waardoor het beheer een onmogelijke of zeer kostbare (denk aan alle verborgen kosten van het ondersteunen van niet standaard-oplossingen). Omdat voor standaard wijzigingen de vertaling van functionaliteit naar de geboden oplossing al gemaakt is, zal de klant sneller geneigd – en makkelijker te overtuigen – zijn om te kiezen voor de aangeboden oplossing.
Door de (vanuit functionaliteit, kosten en beheer oogpunt) goede oplossingen proactief beschikbaar te maken krijgt de it-organisatie dus een goed middel in handen om te sturen op de aangeboden oplossingen.
Succesfactoren en valkuilen
Het klinkt eenvoudig, maar voor het succesvol implementeren van Request Fulfillment zijn een aantal zaken van belang.
Goede definitie en publicatie. De definitie van wat wel en geen standaard aanvragen zijn moet voor zowel de it-organisatie als de klanten duidelijk zijn. Dit is van belang om te voorkomen dat aanvragen die eigenlijk standaard zijn alsnog via het change management proces worden afgehandeld (wat de voordelen van het proces teniet zal doen) of andersom (wat kan leiden tot incidenten). Een goede definitie van standaard aanvragen kan worden bereikt door deze op te nemen in de service catalogus en zo concreet mogelijk beschrijven wat deze precies inhoud.
Proactief beheer. Request Fulfillment heeft de grootste meerwaarde als het lukt de standaard wijzigingen proactief te definiëren, dus voordat ze voor de eerste keer worden aangevraagd. Het is dus van groot belang je te verdiepen in de wensen van de klant en de klant voor te blijven. Verder moet het proces benut worden om standaard wijzigingen te definiëren voor wijzigingen die al aangevraagd zijn en vaker terug zullen komen. Hiermee verliest het proces een deel van de toegevoegde waarde, maar blijft het voordeel van efficiënte afhandeling in volgende gevallen behouden.
Change proces. De efficiëntie die behaald wordt bij het uitvoeren van de standaard aanvraag mag niet worden verward met het op een beheersbare en gecontroleerde manier doorvoeren van de wijziging. De processtappen die worden overgeslagen bij de uitvoering moeten dus te worden uitgevoerd bij het definiëren van de standaard wijziging. Voor het definiëren van een nieuwe standaard wijziging moet dus het change proces worden gevolgd.
Werkinstructie. Efficiëntie is genoemd als grootste voordeel van het Request Fulfillment proces. Door voor elke standaard aanvraag een werkinstructie voor de afhandeling beschikbaar te hebben, wordt geborgd dat de afhandeling daadwerkelijk efficiënt gebeurt. Daarbij is dit een risicobeperkende maatregel omdat geborgd wordt dat de uitvoering van de standaard aanvraag wordt gedaan zoals afgesproken bij het definiëren ervan.
Duidelijke afspraken. Een eerder genoemde valkuil binnen het change management-proces is het hebben van onduidelijke afspraken op het gebied van governance. Hoewel de goedkeuring binnen het Request Fulfillment proces vereenvoudigd is, blijft het belang van duidelijke afspraken groot. Duidelijke afspraken over de goedkeuring die voor de uitvoering van de standaard aanvraag nodig is (in veel gevallen de financiële goedkeuring en soms een goedkeuring vanuit security oogpunt) zijn van belang om een efficiënte afhandeling van de aanvraag te borgen.
Elmer Pouw, Getronics PinkRoccade
Meerdere voordelen
Binnen ITIL v3 wordt een efficiënte afhandeling van standaard aanvragen genoemd als het voornaamste voordeel van Request Fulfillment. Dit is inderdaad het wel grootste voordeel, maar de praktijk laat zien dat er ook andere voordelen uit het implementeren van Request Fulfillment te halen zijn. Zo vergroot het de efficiëntie in afhandeling van standaard aanvragen. Ook neemt de klanttevredenheid toe door meer inzicht in beschikbare diensten. Tot slot is het een mechanisme ter voorkoming van wildgroei aan aangeboden diensten.
Waardevolle aanvulling
Request Fulfillment is een praktische en waardevolle aanvulling in ITIL. Het kan IT Organisaties helpen om snelle stappen te maken in het vergroten van de klant tevredenheid omdat een groot deel van de bureaucratie die door klanten ervaren wordt in het Change Proces wordt weggenomen voor "Standaard Aanvragen".
Rekening houdend met de succesfactoren en valkuilen van het proces kan snel begonnen worden met de implementatie van het Request Fulfillment Proces door te beginnen met het definiëren van de eerste "standaard wijzigingen". Hierdoor kunnen deze aanvragen efficiënt worden afgehandeld. Het definiëren van nieuwe "standaard wijzigingen" zal een continu proces worden waarmee de "standaard" dienstverlening steeds beter zal aansluiten op de wensen van de klanten.
Hiermee is de implementatie van Request Fulfillment een relatief eenvoudige stap in het bereiken van Continual Service Improvement.
ITIL v3 pakt de bureaucratie helemaal niet aan. Net zo min als v2 dat deed. Of juist bureacratie in de hand zou werken. Hoe je ook wend of keert ITIL 3 is (!) complexer en is (!) abstracter dan voorgaande versies.
Dat neemt niet weg dat ITIL 3 goede, soms heel goede, elementen bevat en Request Fulfillment zou er daar een van kunnen zijn. Echter alles valt of staat met hoe het past bij jouw/uw organisatie en of een ieder die er mee te maken krijgt zijn houding en gedrag wenst te veranderen. Een cultuurverandering dus (ABC van Paul Wilkinson). ITIL 3, de auteur heeft het al over multinationals, is inderdaad bij voorkeur geschikt voor die multinationals, mits hun ICT al voldoende volwassen is. Voor heel veel andere organisaties blijft ITIL 3 te complex. Al kan het proces Request Fulfillment een welkome aanvulling zijn.
Organisaties die met ITIL v2 hun wijzigingsproces bureaucraties hebben gemaakt gaan dit met v3 oplossen? Waarom zouden deze organisaties met v3 opeens hun gezonde verstand terug krijgen? Alsof v2 oplegt dat je voor elke wijziging hoe laag de impact ook is een hele molen doormoet. Blijkbaar heeft meneer Pauw v3 nodig om van dit idee af te komen.
Goed artikel want het is een positieve benadering van een ontwikkeling. Request Fulfillment als voorbeeld te nemen om het verschil tussen V2 en V3 te onderbouwen is slecht gekozen omdat in V2 reeds de procedure voor “standaard wijzigingen” is ge?ntruduceerd ter bestrijding van bureaucratie. En als je alle processen en procedures met verstand in de context van de organisatie inricht kan je bureaucratie in zijn algemeenheid tot het hoogst noodzakelijke terug brengen. Dit geldt uiteraard voor alle methodes, modellen, frameworks etc.
Het verschil tussen v2 en v3 is wel meer als alleen Request Fulfillment. Het hele concept is verschoven van het beheersaspect in v2 naar de levencyclus van diensten in v3. En om een goede dienstverlener te zijn zul je door gebruik te maken van processen je diensten betrouwbaar en afgestemd op de vraag moeten gaan leveren. En v3 biedt hiervoor naast Request Fulfillment ook andere handvaten, die je natuurlijk altijd nog moet inrichten op je eigen organisatie. Als een organisatiestructuur met procedures en processen bureaucratie genoemd wordt, hoeft dat zeker niet per definitie negatief te zijn.
Mijn reactie wordt hopelijjk door de redactie nu wel gelezen en dat is ook mijn doel:
Leuk stuk om te lezen, maar wat stikt het van de spelfouten! Erg irritant voor een professionele site met redactie en journalistieke waarde.
Hopelijk kunt u in de toekomst meer spellingscontrole doen?
Groeten,
Rob (een standaard lezer, geen taalkundige of wat dan ook)
Leuk stuk. Ben niet volledig op de hoogte van ITIL v3, echter in v2 werd ook al gesproken over standaard changes die in het begin van het proces uitgefiltert worden. Daarnaast bestonden in het incidentproces ook al standaard service requets waarmee hetzelfde gedaan kan worden. Het benoemen van een apart proces hiervoor maakt het wel explicieter moet ik zeggen. Maar wie managed/ coordineert dit proces?? Welke rollen horen erbij? Wie bepaalt of een change een standaard change is? Wat is het doel van het proces? Toch maar eens een ITIL V3 boek kopen. Wellicht staan daar de antwoorden. Vooralsnog nog even inrichten volgens een niet bureaucratische wijze van v2.