Incident Management in de GrexxBoxx

Transcriptie

1 Incident Management in de GrexxBoxx Door Dennis van Roy Begeleiders: Ir. W.F. Rietveld (TU/e) Prof. Dr. K.M. van Hee (TU/e) Dr. S. Angelov (TU/e) Drs. P.G.M. Hufen (Grexx) Eindhoven, April 2010 Dennis van Roy - Opleiding: Business Information Systems TU/e

2 Samenvatting Dit rapport beschrijft de ontwikkeling van het incident management systeem bij Grexx. Grexx ondersteunt sinds 1999 bedrijven bij organisatieveranderingen op het gebied van strategie, besturing, processen, systemen en cultuur. Grexx is begonnen als consultancybureau, maar heeft in de loop der jaren de dienstverlening uitgebreid en is in 2007 Grexx gestart met een nieuwe dienstverlening: de GrexxBoxx. Dit is een online workflowomgeving omgeving gebaseerd op servicegeoriënteerde technologie, die te gebruiken is voor alle soorten bedrijfsprocessen. Deze workflowomgeving omgeving wordt op een SaaS-platform aangeboden en dient momenteel al ter ondersteuning van tientallen bedrijfsprocessen bij onder andere Air France KLM, KPN, Robeco en SOS International. Het Incident Management Proces dat de incidenten omtrent deze GrexxBoxx implementaties ondersteund is erg ad-hoc. Aangezien Grexx een groeiend bedrijf is en naar verwachting steeds meer GrexxBoxxen onder zijn beheer krijgt, is het van belang dit proces te structureren. In dit rapport wordt de aanpak van het project beschreven evenals een uitgebreid ontwerp van het nieuwe Incident Management Proces en het systeem dat ter ondersteuning hiervan in de GrexxBoxx wordt geïmplementeerd. 2

3 Voorwoord Dit afstudeerrapport sluit een periode af van de studie Business Information Systems binnen de vakgroep Informatiesystemen van de faculteit Wiskunde en Informatica aan de Technische Universiteit Eindhoven. Het ontwerp en de implementatie die worden beschreven in dit verslag zijn uitgevoerd in opdracht van Grexx, als onderdeel van een professionaliseringsslag in de organisatie. Mijn speciale dank gaat uit naar mijn begeleider Pieter Hufen, afstudeerbegeleiders Erica Rietveld en Kees van Hee voor hun kritische blik en inspirerende ideeën. Als laatste wil ik alle andere collega s bij Grexx bedanken voor de ondersteuning en samenwerking tijdens het traject. 07 April, 2010 Dennis van Roy 3

4 Inhoudsopgave Samenvatting... 2 Voorwoord... 3 Inhoudsopgave Inleiding Grexx Ambitie GrexxBoxx SaaS Kritieke Succes Factoren Grexx Huidige Werkwijze Incident Management bij Grexx Groeiscenario s Initiële Probleemstelling Randvoorwaarden: Leeswijzer Theoretisch Onderbouwing Information Technology Infrastucture Library (ITIL) Release Release Release Waar te beginnen Incident Management Verschil Incident Management in ITILv2 en ITILv Servicedesk Incident Management ent bij Grexx Goed Incident Management voor Grexx Evaluatie Huidige Situatie Verscherpte definitie van de probleemstelling Randvoorwaarden Doelstelling Business Ontwerp in het kader van Incident Management Governance Architectuur Business Architectuur Toelichting per partij in de context

5 4.3 Incident Management Platform Operationele Proces Besturing Statussen Casedata ten behoeve van het Incident Management Proces Dashboards Beheer Proces Ontwikkel Proces Ontwerp in de GrexxBoxx Formulier voor de case-objecten Vertaling GrexxBoxx naar Petrinet Triggers Cancel met behulp van triggers Status Uniforme vertaling Configuratie keuzes Case-objecten Niveau van een GrexxBoxx Niveau van een incident Automatische acties Verificatie en validatie Evaluatie Incident Management Proces Oordeel GrexxBoxx Ondersteuning procesconfiguratie Ondersteuning Operationeel Proces Literatuur

6 1 Inleiding In dit hoofdstuk wordt een inleiding gegeven van het bedrijf Grexx, waar het onderzoek wordt verricht. Er wordt uitgelegd in welke markt Grexx opereert en wat de gevolgen hiervan zijn voor het Incident Management. Vervolgens worden de probleemstelling en de opbouw van het rapport behandeld. 1.1 Grexx Grexx is een innovatief bedrijf dat sinds 1999 bedrijven bij organisatieveranderingen ondersteunt op het gebied van strategie, besturing, processen, systemen en cultuur. Grexx is gestart als consultancybureau, maar heeft de dienstverlening in 2001 verder uitgebreid met het leveren van software ter ondersteuning hiervoor. De ontwikkelingen werden doorgezet en in 2007 is Grexx gestart met een nieuwe dienstverlening: de GrexxBoxx. Het is een online workflowomgeving omgeving gebaseerd op servicegeoriënteerde technologie, die te gebruiken is voor alle soorten bedrijfsprocessen. Deze workflowomgeving wordt op een SAAS-platform aangeboden. Omdat het systeem wordt aangeboden op een SaaS-platform en het systeem vitale bedrijfsprocessen van andere organisaties ondersteunt zijn vertrouwen en beschikbaarheid belangrijke factoren. Dit zal in sectie verder worden uitgewerkt. Om het vertrouwen van klanten te vergroten, de klanttevredenheid hoog te houden en de continuïteit te blijven garanderen wil Grexx een Incident Management Systeem invoeren om de incidenten met betrekking tot de GrexxBoxx implementaties te ondersteunen. Dit Incident Management Systeem omvat de totale afhandeling van incidenten op de GrexxBoxx implementaties en heeft als doel om een duidelijk overzicht te geven van de incidenten en de impact van deze incidenten te minimaliseren. Definities van een incident en Incident Management worden gegeven in sectie Ambitie De ambitie van Grexx is het realiseren van verbetering in performance van alle soorten maar, vooral complexe, bedrijfsprocessen. Met complexe bedrijfsprocessen worden processen bedoeld die: Aan veel verandering onderhevig zijn veel actoren hebben veel scenario s hebben veel regie vereisen Hierbij neemt Grexx zowel de rol van consultant, bouwmeester als platform provider op zich, wat een vrij nieuwe vorm van dienstverlening is. Voor de klant heeft dit dus als voordeel dat er één leverancier is voor zowel de consultancy als de implementatie, wat de doorlooptijd verkort, communicatie vergemakkelijkt en kosten vermindert. De Grexx-propositie luidt dan ook: BPM-SaaS: één oplossing met één aanpak, één team en één platform GrexxBoxx Het platform dat is ontwikkeld voor het realiseren van de propositie is de GrexxBoxx. In de GrexxBoxx staat niet langer het bedrijfsproces centraal, maar de activiteiten die worden uitgevoerd. Medewerkers krijgen in de GrexxBoxx een overzicht van de cases waar zij bij betrokken zijn en de taken die uitgevoerd moeten worden. Alle informatie en tools die nodig 6

7 zijn voor het uitvoeren van deze taken worden gegeven. Werk wordt als het ware gezien als een behandeling van cases. De doelstelling van het werk is het succesvol afhandelen van deze cases, wat voor elke soort case anders kan worden gedefinieerd. Voor de afhandeling van deze cases zijn bepaalde acties nodig. Deze acties kunnen via een strak geregistreerd proces verlopen, maar de volgordelijkheid van de acties kan ook voor elke case uniek zijn. Een caseklasse is een verzameling cases die dezelfde karakteristieken hebben. Deze caseklasses worden beschreven in de GrexxBoxx. Voor een verder uitleg van de casegeoriënteerde visie van Grexx verwijs ik naar de white paper van (Ton Romeyn, 2009). Van de caseklassen wordt onder andere de volgende data vastgelegd: Casedata: Dit zijn de attributen van een case. Deze attributen kunnen gestructureerde en ongestructureerde informatie bevatten. Gestructureerde informatie zoals integer, float, datetime en ongestructureerde informatie zoals text en file, wat gebruikt wordt voor vrije tekst en het invoegen van documenten. Actierepertoire: Dit is een beschrijving van de mogelijke acties die uitgevoerd kunnen worden op een case. Deze acties kunnen als verplichte taken of als optionele taken worden aangeboden. De verplichte taken worden aangeboden op basis van het triggermodel. Dit wordt gebruikt als vastligt welke acties op elkaar moeten volgen. Optionele taken zijn taken die worden aangeboden en geïnitieerd kunnen worden door de gebruiker. Rollen: In de definitie van een rol wordt bepaald welke personen rechten hebben op het zien van informatie of het uitvoeren van activiteiten. De GrexxBoxx regelt de authenticatie op basis van een inlognaam en wachtwoord. Autorisatie kan in de GrexxBoxx voor een gehele caseklasse of voor individuele cases worden bepaald. Triggermodel: In dit model wordt aangegeven wat de gevolgen zijn als een bepaalde state is bereikt. Verschillende states zijn bijvoorbeeld dat een bepaalde actie is uitgevoerd, maar het kan ook een zelf gedefinieerde state zijn die de status van een case representeert. Aan triggers kunnen condities worden verbonden die bepalen of een trigger al dan niet wordt uitgevoerd. Door deze triggers is het mogelijk om acties volgens een vaste procedure te laten verlopen. Door het weglaten van deze triggers, kan ruimte worden gelaten aan gebruikers om hun eigen werk te organiseren. In sectie 5.1 wordt een ontwerp gegeven van een formulier om deze case-objecten te definiëren. Daar zal ook meer gedetailleerde informatie worden gegeven van deze objecten SaaS Het platform wordt aangeboden als een Software as a Service (SaaS)-dienst wat inhoudt dat de software als een online dienst via internet wordt aangeboden. De klant hoeft de software niet aan te schaffen, maar betaalt abonnementskosten voor het gebruik. Grexx zorgt verder voor de installatie, het onderhoud en het beheer. De service wordt extern gehost op de servers van Grexx-partner SaaSPLAZA (Siennax BV). Voor de klant blijft deze externe partij echter onzichtbaar en is Grexx de enige contact- en contractpartij. Door deze vrij nieuwe manier van dienstverlening is het belangrijk dat de continuïteit van de SaaS-infrastructuur kan worden verzekerd. SaaSPLAZA heeft hiervoor voor de bedrijfsvoering en infrastructuur een SAS 70 Type II certificering. SAS 70 staat voor 'Statement on Auditing Standards number 70, Service Organizations'. Het is een internationaal geaccepteerde auditingstandaard die is ontwikkeld en wordt onderhouden door het American Institute of Certified Public Accountants (AICPA). Dit houdt in dat het operationeel- en risicomanagement via 7

8 standaardprocedures wordt uitgevoerd. Dagelijks maken meer dan een miljoen eindgebruikers in 50 landen gebruik van bedrijfskritische SaaS oplossingen geleverd via SaaSplaza. In gesprekken met werknemers en het management van Grexx is gebleken dat vertrouwen en beschikbaarheid voor de SaaS-dienstverlening belangrijke factoren zijn. Zonder vertrouwen van de klant zal deze meer geneigd zijn voor zekerheid te kiezen en dus voor een aanpak die zich in de praktijk al heeft bewezen. Het Incident Management Proces is het proces dat het meest zichtbaar is voor de klanten. Hierdoor is het voor Grexx belangrijk om te zorgen dat het Incident Management proces professioneel wordt ingericht. In sectie 2.3 wordt behandeld welke voordelen de invoering van een goed Incident Management Systeem kan hebben. Op basis van drie veel voorkomende vormen van IT-dienstverlening wordt hieronder beschreven wat de gevolgen zijn van het type dienstverlening voor de incidentafhandeling. Dit om aan te geven waarom een goed incident management bij het SaaS-model extra belangrijk is. Traditioneel model In het traditionele model wordt software (eventueel van externe leverancier) door de eigen IT afdeling van een organisatie beheerd. De software staat fysiek op de servers van de klant. De IT-afdeling kan zowel intern als extern zijn gepositioneerd. De klant (de business) communiceert alleen met de eigen IT-afdeling. In Figuur 1-1 is dit illustratief weergegeven. IT gebruiker 2de-lijns incident afhandeling IT-afdeling (klant) 1ste-lijns incident afhandeling Klant (Business) gebruiker Software Leverancier IT Figuur 1-1 Incidentafhandeling bij het traditionele model gebruiker In bovenstaande figuur zijn de communicatielijnen voor de incidentafhandeling weergegeven. Incidenten die de gebruikers ervaren worden eerst geanalyseerd en veelal opgelost door de eigen IT-afdeling. Alleen in het geval dat er een fout in de software wordt geconstateerd, zal de IT-afdeling contact opnemen met de software leverancier. ASP model In het ASP model wordt de software door een Service Provider aangeboden. De software bevindt zich fysiek op de servers van de Service Provider en is via het internet beschikbaar. De ASP is voor de klant contact- en contractpartij en is verantwoordelijk voor de software. In Figuur 1-2 is dit illustratief weergegeven. 8

9 gebruiker Internet 3th party software 2de-lijns incident afhandeling Service Provider 1ste-lijns incident afhandeling Gebruikers (klanten klanten) gebruiker gebruiker Figuur 1-2 incidentafhandeling bij het ASP model Incidentmeldingen van gebruikers worden rechtstreeks aan de Service Provider gericht. De Service Provider neemt dus de 1 ste -lijns incidentafhandeling voor zijn rekening. Wanneer nodig zal de Service Provider escaleren naar de leverancier van de software, maar de Service Provider blijft verantwoordelijk voor de afhandeling. SaaS model In het SaaS-model biedt de softwareleverancier zijn software aan als een service. Bij Grexx is de infrastructuur uitbesteed aan een host. De host van het SaaS-platform is voor de klant onzichtbaar en de klant communiceert alleen met de Saas-leverancier zoals in Figuur 1-3 is weergegeven. Het grote verschil met het ASP model is dat de communicatie rechtstreeks verloopt van de gebruikers naar de SaaS-leverancier, waarbij de host wordt overgeslagen. De 1ste-lijns incidentafhandeling zal dus uitgevoerd worden door de SaaS-leveranciers ongeacht of de oorzaak bij de software of de infrastructuur van de host ligt. Als de oorzaak bij de host ligt, zal de SaaS-leverancier het probleem escaleren naar de host, maar zelf het contact onderhouden met de klant. Het is hierdoor belangrijk bij het Incident Management proces rekening te houden met de mogelijkheid dat de incidenten regelmatig door een externe partij (de host) wordt veroorzaakt. Deze incidenten worden ook door de externe partij opgelost zonder direct contact tussen de klant en deze partij. Figuur 1-3 Incidentafhandeling bij het SaaS model 9

10 1.2 Kritieke Succes Factoren Grexx Zoals eerder aangegeven is Grexx een dienstverlener die ondersteunende software als een SaaS-dienst aanbiedt. Hierdoor zijn de factoren Vertrouwen en Beschikbaarheid specifiek voor hen van essentieel belang. Vertrouwen is een belangrijke factor omdat een klant zonder vertrouwen eerder geneigd is om te kiezen voor zekerheid en voor een aanpak die zich in de praktijk al heeft bewezen. Beschikbaarheid is bij een SaaS-dienst belangrijk omdat in tegenstelling tot het traditionele model, waar de software in de eigen organisatie is geplaatst, de klant hiervoor totaal afhankelijk is van de softwareleverancier. Hierdoor is het belangrijk te onderzoeken wat het Incident Management Proces voor positief resultaat kan hebben op deze twee factoren. De theoretische verdieping in hoofdstuk 2 behandelt de voordelen van een goed Incident Management Proces. Vervolgens zal in hoofdstuk 3 worden beschreven wat deze voordelen voor effect hebben op de Kritieke Succesfactoren van Grexx. 1.3 Huidige Werkwijze Incident Management bij Grexx Door eigen ervaring bij de Grexx Servicedesk en gesprekken die ik heb gevoerd met klanten, werknemers en het management van Grexx is een duidelijk beeld verkregen over de huidige situatie van het Incident Management bij Grexx. Deze bevindingen worden hieronder kort uiteengezet. De klant maakt gebruikt van de GrexxBoxx die gehost wordt op het platform van Siennax en via het internet wordt aangeboden. De klant heeft geen contact met de hostingpartij Siennax. In Figuur 1-4 is grafisch weergegeven hoe de incidentafhandeling verloopt. Figuur 1-4 Huidige werkwijze Incidenten worden gemeld via mail en/of telefoon. De mail wordt naar de servicedesk gestuurd of naar de betreffende consultant die de applicatie heeft geïmplementeerd. De mail van de servicedesk wordt vervolgens automatisch doorgestuurd naar zes mensen, waaronder de servicedeskmedewerker, de technisch consultant, de Chief Technical Officer (CTO) en de configuratieconsultants. consultants. Het gevolg hiervan is dat er geen overzicht is wie de mail van de servicedesk afhandelt. Dit kan de servicedeskmedewerker zijn, maar veelal wordt het snel opgepakt door de consultants die de mail ook binnen krijgen in de mailbox. 10

11 Vervolgens wordt er vaak via de telefoon en/of mail gecommuniceerd wie er met het incident bezig is. De enige documentatie van het incident bevind zich in de mailbox van degene die het incident heeft opgepakt, waardoor verbeteringen slecht te realiseren zijn. Bij telefonische meldingen wordt gebruikelijk direct naar de betrokken consultant gebeld. Ook in dit geval is er nagenoeg geen documentatie en is mailcorrespondentie achteraf de enige manier om bepaalde gegevens en afspraken terug te zoeken. Doordat de incidenten door verschillende personen worden opgepakt, bestaat er ook de kans dat er op elkaar wordt gewacht. Dit heeft negatieve gevolgen voor de reactietijd en de snelheid waarmee het incident kan worden opgelost, maar is door de huidige omvang bij Grexx nog goed te overzien. De huidige situatie zorgt ook voor onwenselijke situaties als personen met vakantie gaan. De servicedeskmedewerker eskmedewerker is namelijk onvoldoende op de hoogte van de standaardincidenten en is daardoor onbekend met de gebruikelijke afhandeling hiervan. Dit kan extra vertraging in de incidentafhandeling veroorzaken. Incidenten die gemeld worden door eigen medewerkers worden op dit moment ook niet geregistreerd en worden al dan niet in samenspraak met een collega direct door de desbetreffende medewerker of CTO opgelost. Incidenten die worden geïnitieerd vanuit automatische controlescripts, komen op dit moment ook via de mail binnen. Hiervan wordt de afhandeling ook door verschillende mensen uitgevoerd, zonder regie en registratie. Ondanks bovenstaande werkwijze blijkt uit de feedback van klanten dat de klanttevredenheid erg hoog is. Dit komt doordat Grexx een klein team heeft met hoge professionaliteit. Dit komt terug in zowel de attitude als in kennis. De consultants hebben een hoge inzet en zijn daardoor ook buiten werktijd bereid om incidenten snel op te lossen. Verder bezit het kleine team alle kennis om de incidenten die niet het gevolg zijn van storingen door de hostingpartij zelf op te lossen. Hiervoor zijn ze dus niet afhankelijk van anderen, waardoor zowel de communicatielijnen als de reactietijden kort zijn. Dit neemt niet weg dat verbetering noodzakelijk is om in de toekomst de klanttevredenheid hoog te houden. Bij verdere groei van Grexx zal de huidige werkwijze met betrekking tot Incident Management niet meer voldoen. Dit op zowel operationeel niveau als op het niveau van de sturing. Om de kwaliteit en klanttevredenheid bij verdere groei minimaal op hetzelfde niveau te houden, moet de effectiviteit en de efficiëntie gewaarborgd blijven. Hiervoor moet het proces explicieter worden gedefinieerd Groeiscenario s Er zijn twee groeiscenario s bij Grexx die van invloed kunnen zijn op het Incident Management proces. Een eerste scenario is het opleiden van configuratiepartners. Deze partners zijn externe bedrijven die worden opgeleid tot GrexxBoxx configuratieconsultants. Dit houdt in dat deze partners ingeschakeld worden om GrexxBoxxen voor klanten te configureren. Deze partners zijn bij aanvang en wellicht langer het contactpersoon van de klant. Het verschil ten opzichte van de huidige situatie is dat de communicatie verloopt tussen de klant en de configuratiepartner. Bepaalde incidentmeldingen ontstaan namelijk door fouten in de configuratie en zullen wellicht ook door deze partners (moeten) worden opgelost. Dit is een belangrijk aspect waarbij tijdens het Incident Management proces rekening gehouden moet worden. Zowel de besturing als het proces zullen zodanig moeten worden ingericht dat dit mogelijk is. 11

12 Een andere mogelijkheid is om het proces door de klant zelf te laten configureren in de GrexxBoxx. Op dit moment wordt de interface voor configurators van de GrexxBoxx eenvoudiger en intuïtiever gemaakt, zodat dit in de toekomst mogelijk is voor de klanten. Dit zal ook een duidelijke verandering in de afhandeling van incidenten betekenen. De oorzaak van eventuele configuratiefouten fouten kan bij de klant zelf liggen. Dit houdt net als bij het vorige scenario in dat na een incidentmelding onderzocht moet worden of een configuratiefout hiervan de oorzaak is. In sectie 4.1 wordt beschreven hoe de besturing wordt ingericht om dit probleem te ondervangen. 1.4 Initiële Probleemstelling Hoe kan Grexx het Incident Management Proces inrichten om bij verdere groei de kwaliteit te garanderen en de klanttevredenheid hoog te houden Randvoorwaarden: Bij aanvang van het project zijn de volgende randvoorwaarden door Grexx met betrekking tot de oplossing opgelegd: Het ontwerp moet ITILv2- en/of ITILv3-compliant worden ingericht. Dit omdat een hogere professionaliteit de geloofwaardigheid van de incidentafhandeling vergroot wat met name bij een klein bedrijf als Grexx extra van belang is. Implementatie van de het Incident Management systeem geschiedt in de GrexxBoxx. Grexx gebruikt dus het eigen product wat participatie van klanten in het Incident Management Proces mogelijk maakt. Als eerste zal hiervoor in hoofdstuk ofdstuk 2 een literatuuronderzoek gedaan worden naar ITIL ten einde te bepalen wat de verschillen tussen de twee versies met betrekking tot het Incident Management Proces zijn en welke versie als leidraad dient voor het proces. Vervolgens worden in hoofdstuk 3 de factoren beschreven waaraan een goed Incident Management Proces moet voldoen. Op basis van deze eisen zal een meer gedetailleerde probleemstelling worden gedefinieerd gevolgd door de doelstelling van dit project. 12

13 1.5 Leeswijzer De opbouw van het onderzoek en de aanpak wordt in Figuur 1-5 op een grafische manier weergegeven. Figuur 1-5 Leeswijzer 13

14 2 Theoretisch Onderbouwing In dit hoofdstuk is als eerste het ontstaan en de betekenis van de Information Technology Infrastructure Library uitgewerkt. Daarna zijn kort de verschillende versies besproken, gevolgd door verdieping van het Incident Management proces en de functie servicedesk. 2.1 Information Technology Infrastucture Library (ITIL) In de jaren 80 van de vorige eeuw kwam het besef en de erkenning dat organisaties in toenemende mate afhankelijk werden van IT om doelstellingen te bereiken. Hierdoor werd de kwaliteitbeheersing van de IT-dienstverlening belangrijk. De Central Computer en Telecommunications Agency (CCTA) heeft destijds in opdracht van de Britse overheid onderzoek gedaan om een efficiënte en effectieve inzet van IT middelen bij organisaties van de Britse overheid te bewerkstelligen. Het resultaat van het onderzoek is gedocumenteerd in de Information Technology Infrastructure Library (ITIL). Deze reeks gepubliceerde boeken is een raamwerk van best practices voor IT Service Management. ITIL geeft als definitie voor IT Service Management: het geheel van capabilities waarmee een organisatie met haar IT- diensten waarde levert aan de klant (L. Peeters, 2008). Een goed IT Service Management leidt volgens (H. Kisters, 2003) onder andere tot de volgende voordelen: Toename van efficiëntie en effectiviteit Betere afstemming van ICT op de wensen van de business Betere inzicht in de IT dienstverlening Betere communicatie tussen business en IT Duidelijke gedefinieerde rollen en verantwoordelijkheden ITIL is gebaseerd op best practices uit de praktijk en de bibliotheek is gepubliceerd in een reeks boeken die sinds de invoering zijn opengesteld voor publiek. Het biedt een gestructureerde aanpak voor IT Service Management en wordt wereldwijd erkend als de standaard voor het inrichten voor kwalitatief goed IT Service Management. ITIL is bedoeld als raamwerk voor het inrichten van IT Service Management en wordt voortdurend aangepast aan de behoeften van de industrie. Door de nieuwe behoeften en het voortschrijdend inzicht zijn er van ITIL al 3 versies uitgebracht, die telkens aan nieuwe behoeften voldoen. ITIL moet dus absoluut niet worden gezien als kant en klare oplossing, wat meteen de kracht en de zwakte van de bibliotheek bloot legt. Het raamwerk biedt best practices, waarbij voor elke specifieke organisatie moeten worden bekeken welke onderdelen van belang zijn en hoe deze moeten worden aangepast. Hierdoor is ITIL op elke organisatie toepasbaar, maar moeten de bedrijven zelf de vertaling maken van abstracte processen naar de eigen concrete operatie, wat veelal een tijdrovend implementatietraject inhoudt Release 1 De eerste versie van ITIL, ontstond in 1988 in de UK onder de naam: Government Infrastucture Management Method (GITMM). De focus lag hierbij op het Service Level Management, maar al snel werd het raamwerk uitgebreid met de functie Helpdesk, Contingency Planning en Change Management. Een jaar later (1989) werden hier de processen Problem Management, Configuration Management en Cost Management aan 14

15 toegevoegd. In 1991 werd de bibliotheek uitgebreid met Software Control and Distribution en een jaar later werd ook Capacity en Availability Management toegevoegd. De bibliotheek met best practices groeide op deze manier uit tot een veertigtal boeken en begon ook gedaante te krijgen buiten overheidsinstellingen. Mede hierdoor, maar ook omdat de Central Computer and Telecommunications Agency (CCTA) de boeken als richtlijn in plaats van een formele methode wilde neerzetten, werd de GITMM hernoemd naar ITIL (wik09). De focus van deze eerste versie lag voornamelijk op het bieden van een functiegerichte aanpak op het gebied van operationele beheerprocessen. De kern bestond hierdoor uit een twintigtal boeken die de Service Support en de Service Delivery processen beschreven Release 2 Om ITIL toegankelijker en beter betaalbaar te maken, werd de bibliotheek in 2000 herzien en opnieuw uitgegeven. Deze nieuwe uitgave werd verkleind tot 11 boeken met een procesgerichte aanpak die het gat tussen technologie en business dichtte door zich sterk te concentreren op processen voor effectieve dienstverlening aan de klanten ((OGC), 2007). Steeds meer bedrijven schaarde zich achter het gedachtegoed van ITIL, waardoor ITIL vooral in Nederland is uitgegroeid tot een defactostandaard voor het invullen van de technische beheerprocessen (Janssen, 2003). De 11 boeken van ITILv2 zijn: 1. Introduction to ITIL 2. Service Support 3. Service Delivery 4. Security Management 5. Business Perspective Volume 1 6. Business Perspective Volume 2 7. Planning to Implement Service Management 8. Application Management 9. Software Asset Management 10. ICT Infrastructure Management 11. Small Scale Implementations De kern van deze versie bestaat net als bij versie 1 uit de onderwerpen Service Support en Service Delivery. Dit is terug te zien in de ITIL trainingen, die behandelen alleen de onderwerpen uit deze twee boeken. In het onderstaande schema staan de onderwerpen die in de twee kernboeken aan bod komen. De functie Servicedesk esk en het proces Incident Management worden in secties 2.3 en 2.4 van dit rapport verder uitgewerkt. Service Support: Service Delivery: Servicedesk (functie) Service Level Management Incident Management Availability Management Problem Management Capacity Management Change Management IT Service Continuity Management Release Management Financial Management for IT Services. Configuration Management 15

16 2.1.3 Release 3 ITILv2 geeft een gedetailleerde en effectieve omschrijving omtrent de support en delivery van diensten aan de business, maar heeft weinig aandacht voor het ontwerpen van diensten die voldoen aan de behoeften van de business. V2 geeft verder advies over het managen van de servicelevels, maar mist advies over het verbeteren van de kwaliteit. Behalve de verbetering op deze punten, is in ITILv3 ook rekening gehouden met hedendaagse uitdagingen zoals outsourcing, off-shoring en het gebruik van internet. Om te voldoen aan bovenstaande eisen is ITILv3 uitgegaan van een lifecycle benadering en is ITILv3 geëvolueerd van een procesgeoriënteerde aanpak naar een servicegeoriënteerde aanpak. Niet het invoeren van een bepaald proces staat centraal, maar de zorg dat de services die een organisatie aanbiedt continu worden verbeterd. Verder is er ook meer nadruk op de Return On Investment (ROI), waardoor het voor IT-managers gemakkelijker wordt om investeringen aan de business te verklaren. De lifecycle van een IT-dienst wordt geïntroduceerd met 4 fasen en de Continual Service Improvement (CSI). De CSI zit, zoals in figuur 2.1 te zien is, als een schil om de 4 fasen heen. De vijf fasen van de lifecycle benadering zijn: Service Strategy: beschrijft strategieën en policies om IT Service Management in te voeren die in lijn is met de globale business strategie. Service Design: beschrijft hoe de strategie gebruikt moet worden om ontwerpen en specificaties es voor de service te ontwerpen Service Transition: beschrijft hoe de transitie van specificatie naar een live omgeving moet gebeuren. Service Operation: beschrijft hoe het dagelijkse verloop in een live omgeving van de service geregeld moet worden. Continual Service Improvement (CSI): Deze wordt in elke fase bekeken en gemeten om ervoor te zorgen dat IT aansluit bij de behoefte van de business. Waarnodig worden er aanpassingen gedaan om te zorgen dat IT blijft aansluiten bij de business. Van elk van deze fasen is een boek verschenen. Hiermee is de nieuwe release redelijk compact gehouden ten opzichte van zijn voorgangers. In Tabel 2-1 is weergegeven waar de processen van ITILv2 gepositioneerd zijn in ITILv3 en in welk deel de nieuwe processen van ITILv3 zich bevinden. Zoals te zien is in het schema, zijn de processen uit ITILv2 in ITILv3 overgenomen en zijn er in de lifecycle fasen nog enkele nieuwe onderwerpen toegevoegd. Versie 3 is dus geen herschrijving, maar een effectieve reorganisatie van alle V2 onderwerpen met als aanvulling het concept van Service Lifecycle. Hierin wordt de service ondersteund van aanvang tot pensionering. Verder zijn een aantal 16

17 processen, waaronder Incident Management, opgesplitst in meerdere processen omdat uit de praktijk blijkt dat het overzichtelijker is om deze los te herkennen. De grootste verschuiving is echter dat de focus niet meer ligt op de efficiëntie en de kosten, maar op het ontwerpen van de waarde van de service en het verbeteren van de kwaliteit van de service. ITILv3 is behalve in het Engels ook beschikbaar in meerdere erdere talen waardoor deze versie een stuk toegankelijker voor IT-managers in niet-engels sprekende gebieden. 17

18 Processen/Functies in ITILv2: Servicedesk Configuration Management Incident Management Problem Management Change Management Release Management Service Level Management Availability Management Capacity Management Financial Management for IT Services IT Service Continuity Management Security Management Service Strategy Financial Management Service Portfolio Management Demand Management Fasen In ITILv3: Service Design Service Transition Service Operation Continual Service Improvement Servicedesk Service Asset & Configuration Management Incident Management Problem Management Change Management Release & Deployment Management Service Level Management Availability Management Capacity Management IT Service Continuity Management Information Security Management Service Catalogue Management Supplier Management Service Portfolio Management Service Validation & Testing Access Management Transition Planning & Support Event Management Knowledge Management Request Fulfillment Tabel 2-1 Verschilllen tussen ITILv2 en ITILv3 (L. Peeters, 2008) The 7-step improvement process Service Measurement 18

19 2.2 Waar te beginnen ITIL is een set van best practice aanbevelingen, die je kan aannemen en aanpassen zodat ze aan de specifieke wensen van je bedrijf voldoen. Hierdoor kunnen bedrijven zich nog steeds richten op de elementen die voor hen het meest waardevol zijn. Pink Elephant (bedrijf dat ITIL introduceerde in Nederland) adviseert om ondanks de nieuwe lifecycle benadering van ITILv3 eerst de pijnpunten te analyseren en op basis van quick wins te beginnen met de implementatie van een aantal basisprocessen. Deze snelle verbeteringen zijn noodzakelijk om de motivatie op peil te houden (Peeters, 2003). Volgens (H. Kisters, 2003) wordt bij de inrichting van ITIL-processen vaak gestart met het Incident Management Proces. Het is een front-office proces dat wordt gezien als visitekaartje van het achterliggende IT-beheer omdat het erg zichtbaar is voor de business. Hierdoor is de waarde van een goed Incident Management systeem eenvoudiger aan te tonen dan bij andere processen in de Service Operation. Verder kan het Incident Management Proces gebruikt worden om verbeterpunten van andere processen boven water te krijgen en te onderbouwen met data (Commerce, 2007). In sectie 2.3 wordt de meerwaarde van een goed Incident Management Proces in het algemeen verder uitgewerkt en vervolgens zal in hoofdstuk 3 worden bekeken wat een verbeterd Incident Management Proces voor Grexx kan betekenen. 2.3 Incident Management Het Incident Management Proces omvat de totale afhandeling van incidenten. Daarbij kan een incident worden gedefinieerd als een ongeplande interruptie of kwaliteitsreductie van een IT-dienst (Bon, 2007). Het doel van Incident Management is het zo snel mogelijk herstellen van de IT-service ten einde de impact van het incident op de bedrijfsprocessen te minimaliseren. Een goed ingericht Incident Management Proces kan onder andere de volgende voordelen opleveren: Betere en snellere afhandeling van incidenten. Dit zorgt voor een verminderde business impact door minder downtime en dus een hogere bereikbaarheid van de geleverde diensten. Kostenreductie door het efficiënter inzetten van IT-medewerkers in het kader van het Incident Management Proces. Betere managementinformatie doordat incidentenregistratie zinvolle rapportages oplevert. Een duidelijk overzicht van de incidenten en de data van de incidenten, geeft een goede basis voor verbeteringstrajecten. Het is belangrijk dat voldoende rollen worden gespecificeerd om zodoende de verantwoordelijkheden duidelijk aan te geven. De verschillende rollen in het Incident Management Proces zijn: de Incident Manager, eerste lijnmedewerkers (servicedeskmedewerker), tweede lijnmedewerkers en bij grote organisaties N-de lijnmedewerkers. De verantwoordelijkheden van de Incident Manager zijn: De efficiëntie en effectiviteit van het proces bewaken en verbeteringen aandragen Het leveren van managementinformatie Besturen van de werkzaamheden van de lijnmedewerkers Het onderhouden van het incident management proces en ondersteunende systemen Afhandelen van Major Incidenten 19

20 De verantwoordelijkheden van de eerste lijnmedewerkers variëren sterk per organisatie. Er kunnen niet-vakkundige mensen werken waarvan de werkzaamheden zich beperken tot het registreren van incidenten, toewijzen aan een oplosgroep, communiceren met de klant en het afsluiten van een incident. Vakkundig personeel kan werkzaamheden als classificatie, oplossen van incidenten en het escaleren ervan voor zijn rekening nemen. In hoofdstuk 4 wordt uitgelegd voor welke vorm bij Grexx wordt gekozen en wat de specifieke verantwoordelijkheden per rol zijn. Aan de hand van ITIL (Commerce, 2007) zijn de volgende eigenschappen van belang om de efficiëntie en de effectiviteit van het Incident Management Proces de controleren: Totaal aantal Incidenten Aantal Incidenten per stadium Totaal aantal Incidenten, en, onderverdeeld per categorieklasse Gemiddelde doorlooptijd van incidenten, onderverdeeld per prioriteitsklasse en aangevuld met de spreiding. Aantal en percentage incidenten opgelost binnen afgesproken tijd Aantal en percentage incidenten dat heropend is Aantal en percentage incidenten dat verkeerd wordt toegewezen Aantal en percentage incidenten dat verkeerd wordt gecategoriseerd Aantal en percentage incidenten dat door de Servicedesk wordt opgelost zonder hulp van andere oplosgroepen De kritieke succesfactoren van Incident Management zijn (Commerce, 2007): Servicedesk waarbij de rollen en verantwoordelijkheden duidelijk gespecificeerd zijn Duidelijke doelen, die beschreven zijn in de Service Level Agreements (SLAs) Klantgericht en goed onderlegd personeel eel in alle stadia van het proces Ondersteunende software om het proces te begeleiden Operational Level Agreements (OLAs) en Underpinning Contracts (UCs), die het handelen van het ondersteunend personeel bepalen Omdat een goede Servicedesk esk essentieel is voor het goed functioneren van een Incident Management Proces, zal de afdeling servicedesk in sectie 2.4 worden behandeld Verschil Incident Management in ITILv2 en ITILv3 Het Incident Management Proces van ITILv2 is in ITILv3 opgesplitst in twee processen, namelijk Incident Management en Request Fulfillment. De meldingen van beide processen komen binnen via de servicedesk. Bij Request Fulfillment betreft het echter geen acute verstoring van de dienstverlening. Het zijn verzoeken die in tegenstelling tot incidenten gepland kunnen worden afgehandeld. Onder Service Requests vallen verschillende verzoeken van de gebruikers aan de IT-afdeling. Over het algemeen zijn dit kleine veel voorkomende aanpassingen met lage risico s zoals het wijzigen van een paswoord. Door het behandelen van deze verzoeken in een ander proces dan Incident Management, wordt het Incident Management Proces niet vervuild met standaardverzoeken. In tegenstelling tot het proces Request Fulfillment is het Incident Management Proces is namelijk niet bedoeld voor deze verzoeken en er ook niet optimaal voor ingericht. Het doel van de Request Fulfillment is: (Commerce, 2007) Het bieden van een kanaal voor gebruikers waar ze standaarddiensten kunnen aanvragen en ontvangen 20