Jasper Vandegaer. Academiejaar:

Transcriptie

1 : Naam: Jasper Vandegaer Klas: 3 SWM Academiejaar: Bedrijf: Ordina Belgium Provinciale Hogeschool Limburg (PHL) Departement Handelswetenschappen en bedrijfskunde Elfde-Liniestraat Hasselt t +32(0) e h&b@phl.be w

2 Page 2

3 Het sluitstuk van de opleiding toegepaste informatica aan de Provinciale Hogeschool Limburg is een bedrijfsstage van 12 weken in het derde jaar. Na wat opzoekwerk naar de kandidaat stagebedrijven kwam ik terecht bij Ordina. Zij konden een stage aanbieden die perfect aansloot bij mijn afstudeerrichting, Software Management. De opdrachten dat ik heb uitgevoerd situeren zich in het kennisdomein IT Service Management. Dit stagerapport is een weergave van mijn stage bij Ordina. Een stage die ik weliswaar niet alleen had kunnen verwezenlijken en daarom wil ik nu ook een aantal mensen bedanken: In de eerste plaats mijn stagementor bij Ordina, Niels Coninx. Door zijn expertise en opdrachten heb ik zeer veel bijgeleerd in deze 12 weken. Daarnaast wil ik hem ook bedanken voor zijn uitstekende begeleiding tijdens mijn stage. Vervolgens wil ik mijn stagelector Marijke Sporen, docent aan de Provinciale Hogeschool Limburg, bedanken voor de opvolging van mijn stage. Ten slotte zou ik ook Tom Verstraeten, Ordina ICT Recruiter, willen bedanken. Hij gaf mij uiteindelijk de mogelijkheid om mijn stage te doen bij Ordina. Page 3

4 1. Voorwoord Lijst afkortingen en begrippen Samenvatting Introductie Stagebedrijf: Ordina Ordina Group Kernactiviteiten Ordina Belgium Organisatie IT Service Management (ITSM) Introductie ITSM Ordina ITSM Organisatorische structuur ITSM binnen Ordina: Service Desk Organisatie Services en klanten Service Desk Improvement(SDI) Programma ITSM Best-Practice: ITIL Introductie Beste practice? Ontstaan? Hoe gebruikt? Het ITIL Framework ITIL V ITIL V V2 of V3 of? De Stageopdracht Situering: ITIL fase, functie en processen De opdrachten Planning Werkomgeving Resultaten Incident Management: Adviesrapport procesuitvoering Problem Management: Rapport Problemidentificatie Request Fulfillment: Top 10 Service Requests Standardisatie Persoonlijke reflectie Page 4

5 Onderstaand een lijst met de belangrijkste begrippen(en afkortingen) die het lezen van mijn stagerapport vereenvoudigen. Woordenlijst 1 Information Technology Infrastructure Library(ITIL ) Een set Best-Practice richtlijnen voor IT Service Management. ITIL is eigendom van OGC en bestaat uit een reeks publicaties die richting geven aan het leveren van IT Services van hoge kwaliteit en de benodigde processen en faciliteiten. IT Service Management (ITSM) Implementatie en Management van Servicekwaliteit die in de behoefte van de business voorziet. IT Service Management wordt uitgevoerd door IT Service Providers in een toepasselijke mix van mensen, processen en IT. Zie Service Management. Activiteit Een serie acties waarmee een bepaald resultaat wordt gerealiseerd. Activiteiten worden meestal als onderdeel van processen of plannen gedefinieerd, en worden gedocumenteerd in procedures. Incident Management Het proces dat verantwoordelijk is voor het managen van de levenscyclus van alle incidenten. Het primaire doel van Incident Management is om de IT Service zo snel mogelijk weer bij de gebruikers te brengen. ISO 9001 Een generieke term die refereert aan een aantal internationale standaarden en richtlijnen voor kwaliteitsmanagementsystemen IT Service Service geleverd aan één of meer klanten door een IT Service Provider. Een IT Service is gebaseerd op het gebruik van IT en ondersteunt de bedrijfsprocessen van de klant. Een IT Service is ontwikkeld vanuit een combinatie van mensen, processen en technologie en moet gedefinieerd zijn in een Service Level Agreement Levenscyclus(lifecycle) De verschillende fasen in het leven van een IT Service, CI, Incident, Problem, Change, et cetera. De lenscyclus definieert de categorieën voor de status en de statusovergangen die zijn toegestaan. Bijvoorbeeld: De levenscyclus van een applicatie bevat eisen, ontwerpen, samenstellen, ontwikkelen, bedienen en optimaliseren De levenscyclus van een server kan bestaan uit: besteld, ontvangen, testen, live, afgeschreven, et cetera. Incident Ongeplande onderbreking of kwaliteitsvermindering van een IT Service. Storing van een CI die nog geen impact op de Service heeft is ook een Incident. Bijvoorbeeld een storing van één disk van een mirror set. 1 Gebaseerd op de ITIL V3 Glossary v van 11 mei 2007 Page 5

6 Woordenlijst Problem Een oorzaak van één of meer incidenten. De oorzaak is gewoonlijk niet bekend op het moment dat een Problem Record wordt aangemaakt, en het Problem Management proces is verantwoordelijk voor verder onderzoek. Problem Management Het proces dat verantwoordelijk is voor het managen van de levenscyclus van alle Problems. De primaire doelstellingen van Problem Management zijn te voorkomen dat zich incidenten voordoen en de impact te beperken van incidenten die niet kunnen worden voorkomen. Impact Bepaald het effect van een Incident, probleem of change op bedrijfsprocessen. Impact is vaak gebaseerd op wat het effect zal zijn op de Service Levels. Impact en urgentie worden gebruikt om prioriteit aan te geven. Urgentie Geeft aan hoe lang het zal duren tot een Incident, Problem of Change een significante impact op de Business heft. Zo kan een Incident met een hoge impact een lage urgentie hebben, als het pas impact krijgt aan het eind van het financiële jaar. Impact en urgentie worden gebruikt om ene prioriteit toe te kennen? Proces Een gestructureerd gehaal van activiteiten dat is ontworpen om een bepaalde doelstelling te bereiken. Een proces gebruikt vooraf bepaalde input en zet deze om in vooraf bepaalde output. Een proces kan alle rollen, verantwoordelijkheden, tools en Management Controls omvatten die nodig zijn voor de betrouwbare levering van de output. Een proces kan beleid, standaarden, richtlijnen, activiteiten en werkinstructies vaststellen als deze nodig zijn. Request Fulfillment Het proces dat verantwoordelijk is voor de gestandaardiseerde afhandeling van wederkerende Service Requests. Rol Verantwoordelijkheden, activiteiten en autoriteiten die aan een persoon of een team worden toegekend. Een rol wordt bepaald in een proces. Eén persoon of team kan meerdere rollen hebben. Bijvoorbeeld de rollen van configuratiemanager en changemanager kunnen door één persoon worden uitgevoerd. Service Level Agreement(SLA) Een overeenkomst tussen de IT Service Provider en een klant. De SLA beschrijft de IT Service, documenteert Service Level Targets en specificeert verantwoordelijkheden van de IT Service Provider en de klant. Single Point Of Contact(SPOC) Leveren van een enkele consistente manier om met een Business Unit of een organisatie te communiceren. Een SPOC voor een IT Service Provider wordt gewoonlijk een Service Desk genoemd. Service Provider Een organisatie die Services levert aan één of meer interne of externe klanten. Service Provider wordt vaak gebruikt als een afkorting voor een IT Service Provider. Page 6

7 Dit stagerapport is een weergave van mijn stage bij Ordina. Ordina is een bekende marktspeler voor ICT Consultancy en Outsourcing. Een voorstelling van de organisatie komt aan bod in de inleidende hoofdstukken. De stageopdracht situeert zich in het kennisdomein IT Service Management(ITSM); het inrichten van IT afdelingen op basis van Best-Practices, zoals Information Technology Infrastructure Library (ITIL ). De Best-Practice bestaat uit een framework van processen en functies. Ook Ordina s interne Service Desk hanteert ITIL als Best-Practice voor IT dienstverlening. In deze omgeving heb ik mijn stage uitgevoerd. Mijn opdrachten waren een onderdeel van het Ordina Service Desk Improvement programma. Dit project, uitgevoerd door ITSM Professionals, heeft betrekking op Ordina s interne Service Desk. Een overzicht van het framework, meer bepaald de processen waarrond ik gewerkt heb komen vervolgens aan bod. De doelstellingen van de stage waren enerzijds kennismaken met ITSM & ITIL en de toepassing binnen Ordina s interne Service Desk. Daarnaast werd mij gevraagd een adviesrapport op te maken voor verbetering van volgende ITIL processen: Incident Management: een adviesrapport voor de verbetering van procesuitvoering Incident Management Problem Management: een analyse van Incident records ter identificatie van potentiële Problems en preventieve maatregelen Request Fulfillment: efficiënte afhandeling door standaardisatie en uitwerking van TOP10 wederkerende Service Requests Aanvullende informatie rond ITSM en hoe ik de verschillende vraagstukken hierin heb aangepakt kan u lezen in mijn stagerapport. Page 7

8 Ordina is een kennis gedreven, specialistische dienstverlener die met Consulting, ICT en Outsourcing klanten ondersteunt om hun doelen te bereiken. Ordina telt circa 4000 medewerkers in de Benelux die voor grote, toongevende organisaties in de finance- en public markt werken. In België en Luxemburg hebben ze een sterke positie in de industriemarkt. In Nederland concentreren ze zich vooral op de deelterreinen klanteninteractie, organisatiebesturing, bedrijfsvoering en risk & compliance. Onderstaand een visueel overzicht van de organisatiestructuur van Ordina: De Ordina Group is opgesplitst in Holdings: Ordina Nederland Ordina België/Luxemburg Deelnemingen(kleinere ondernemingen die door Ordina gedreven worden) De verdere voorstelling van het bedrijf blijft beperkt tot de holding waarbinnen ik actief was, Ordina Belgium. In paragraaf 4.2 wordt hier verder op ingegaan. Page 8

9 Ordina voert 3 kernactiviteiten uit en legt zich voornamelijk toe op een aantal kernmarkten en focusdomeinen. In dit hoofdstuk worden deze kernactiviteiten opgesomd zodat u een concreet beeld krijgt van wat Ordina doet. Ordina voert drie kernactiviteiten uit: Consultancy: advies geven over optimalisatie van bedrijfsprocessen van klanten; ICT: ontwikkeling, implementatie en beheer van applicaties die dat ondersteunen; Outsourcing: overname van complete bedrijfsprocessen en ICT. Het beperkt zich voornamelijk tot vier kernmarkten: Banken en verzekeringsbedrijven; Industrie en handel; Overheden; Telecommunicatie- en nutsbedrijven. Ze bieden end-to-end-oplossingen op basis van de volgende specialisaties: Applicatiebeheer; Business intelligence; Enterprise resource planning; Financial business consultancy; ICT landscape optimalisatie; Infrastructuurbeheer; Kwaliteitsborging en validatie; Supply chain oplossingen; Toepassingsontwikkeling. Ordina Belgium is de Belgische dochter van de Ordina Group die werd opgericht in Vandaag bedient zij de Belgische en Luxemburgse markt vanuit 3 vestigingen, dicht bij de klanten: Mechelen(HQ), Hasselt en Luxemburg. Mijn plaats van tewerkstelling binnen Ordina Belgium was het kantoor in Hasselt. Dit is een nieuw kantoor, uitgerust met de laatste nieuwe technologieën. Het is gevestigd langs de grote ring in Hasselt. Hieronder ziet u een foto van dit kantoor: Page 9

10 Ordina Belgium is onderverdeeld in een aantal divisies. Elk van deze divisies zijn op hun beurt onderverdeeld in Business Units. Een BU heeft betrekking tot een bepaalde productgroep/technologie en bestaat uit een aantal Competence Centers. Competence Centers zijn gespecialiseerd in een bepaald kennisdomein. Ordina Professionals maken deel uit van een Competence Center, gebaseerd op hun geliefkoosd kennisdomein en verdere carrière. Aan het hoofd van een Competence Center staat een Competence Leader die ervoor zorgt dat men steeds op de hoogte blijft van de laatste nieuwe ontwikkelingen binnen de verschillende kennisdomeinen. Deze vorm van organisatie zorgt ervoor dat Ordina Professionals hun kennis continu kunnen bijschaven en verbreden en maakt van Ordina een kennisintensieve organisatie. Het IT Service Management Competence Center maakt deel uit van de Business Unit Innovative Technology Solutions & Services (ITS 2) De Business Unit ITS 2 bestaat uit verscheidene Competence Centers die Service Management en Infrastructure Technology als expertise hebben. Deze unit bestaat uit 80 professionals. Binnen het Competence Center IT Governance en IT Service Management heb ik gedurende drie maanden mijn opdrachten uitgevoerd. Page 10

11 ITSM houdt zich bezig met het effectief en efficiënt inrichten van de IT dienstverlening in een Organisatie. Bij ITSM gaat het allemaal om het effectief managen van de 3 P s: People Proces Products(Technology) Ordina ITSM focust zich op deze 3p s voor het efficiënt en effectief beheren van een ITSM organisatie. Waar andere bedrijven maar al te vaak focussen op processen en technologie, gaat het belang van Ordina ITSM vooral naar de People uit. De hoofdobjectieven van ITSM zijn: Structuur brengen in de IT organisatie door middel van processen en duidelijke rollen en verantwoordelijkheden. IT Services afstemmen op de huidige en toekomstige noden van de Business en klanten Kwaliteit van IT Dienstverlening verbeteren Het reduceren van lange termijn kost van IT Services Voor het bereiken van de objectieven gaat ITSM beroep doen op Best-Practices, zoals ITIL. De implementatie van ITSM in een organisatie kan beschouwd worden als een continue verbeteringsproces. Verandering is een gevolg van dit verbeteringsproces. Wanneer men iets wilt verbeteren, zal dit een organisatorische verandering veroorzaken in de manier dat mensen werken. ITSM doet dit door processen te definiëren. Veranderingen zullen continu optreden bij het invoeren van ITSM want de optimale situatie zal nooit bestaan, er is altijd ruimte voor de verbetering. Page 11

12 Aan het hoofd van Ordina IT Service Management staat Business Unit Manager Patrick Muylaert. De Unit zelf bestaat uit 3 lead ITSM Consultants: Roel, Johan en Niels. De opdrachten die ik heb uitgevoerd gedurende mijn stage, heb ik telkens gerapporteerd aan mijn stagementor: Niels Coninx. De voornaamste taken van Ordina s ITSM consultants zijn: Pre-sales offertes maken: samen met de klant naar de juiste oplossing zoeken Servide Desk Improvement projecten: projecten voor de verbetering van de IT dienstverlening met betrekking tot de interne Service Desk Consultancy opdrachten bij klanten: uiteenlopende opdrachten bij klanten voor bepaalde duur Gedurende 12 weken heb ik opdrachten uitgevoerd die in de lijn lagen van de opdrachten die de ITSM consultants van Ordina uitvoeren Onderstaand krijg je een visueel overzicht van het ITSM team bij Ordina, waarmee ik opdrachten heb uitgevoerd. De opdrachten die ik heb uitgevoerd hadden allemaal te maken met de functie Service Desk. Deze functie wordt in het volgende hoofdstuk besproken. Page 12

13 Ordina s Service Desk verzorgt de dienstverlening voor een uitgebreide klantenportefeuille in verschillende bedrijfssectoren (30+ klanten anno 2010, ~2500 eindgebruikers). Daarnaast staan zij ook garant voor de continuïteit van Ordina s eigen bedrijfsactiviteiten als Service Provider en bijbehorende support van de ~800 interne Ordina medewerkers. Op een procesmatige en gestructureerde manier worden Service Requests door onze Service Desk afgehandeld. Bovendien worden de diensten continu verbeterd en bijgestuurd conform Best-Practice benaderingen zoals ITIL. Ordina s Competence Center ITSM zorgt voor de uitwerking en integratie van Service Support processen, training en awareness van Service Desk Operators, en de implementatie van complementaire Service Capabilities; ondersteunende middelen die bijdragen aan de effectiviteit en efficiëntie van de dienstverlening. Voorbeelden van deze capabilities zijn: Kennisbeheer: Gestructureerde documentatie en onderhoud van kennis in de vorm van Procedures, Werk Instructies, Policies etc. die gebruikt worden als middel voor kennisoverdracht om een Skilled Service Desk te realiseren. Communicatie: Gerichte en heldere communicatie doorheen het oplossingsproces. Algemene communicatie van outages, geplande interventies, major incidents, etc. inclusief beschrijvende informatie zoals impact en root cause. Transparantie: Heldere en consistente monitoring en rapportage aangaande de diensten, uitgevoerd door Ordina s Service Desk. Ordina s Skilled Service Desk verzorgt de dienstverlening vanuit verschillende kennisdomeinen. De kennisdomeinen worden continue verbreed vanuit Competence Centers die zich door middel van kennisdeling en certificatie steeds verder bekwamen in hun expertise. Op deze manier is de klant steeds verzekerd van kwalitatieve oplossingen voor de problematiek in hun bedrijfsomgeving. Bovendien verzorgt het Competence Center IT Service Management de organisatorische omkadering van Ordina s Service Desk: Duidelijke rollen en verantwoordelijkheden, procesmatig werken, key performance indicators (KPI), Service level management, etc. als middelen in het streven naar Operational Excellence voor hun klanten. 2 Ordina CC ITSM Workspace Page 13

14 Ordina s interne Service Desk en bijhorende verbeterprojecten zijn als volgt georganiseerd: Voor de Service Desk ligt de focus op Support en Service Delivery. Verschillende teams met elk hun eigen rollen en verantwoordelijkheden verschillende Competence Centers, Services en Solutions realiseren, via kennisoverdracht, Best-Practices en een Servicegerichte aanpak: Service Desk Service Delivery Support Engineer Competence Centers & Solution Architects Bijhorend bij dergelijke structuur zijn volgende rollen en verantwoordelijkheden: Coordination Administration Support Beheer Projects Changes Solution architectures Customer proposals Tijdens mijn stage heb ik aan projecten meegewerkt vanuit het Comptence Center IT Service Management, onder begeleiding van Solution Architects en Comptence Leaders. Page 14

15 Het Competence Center IT Service Management verzorgt de organisatorische omkadering van Ordina s Service Desk: Duidelijke rollen en verantwoordelijkheden, procesmatig werken, key performance indicators (KPI), Service level management, etc. als middelen in het streven naar Operational Excellence voor hun klanten. De Services, aangeboden door Ordina s Service Desk, worden als volgt gecategoriseerd: Managed Services (SLA) Support contracten waarbij hun Service Manager vooraf in samenspraak met de klant een Service Level Agreement opmaakt. Concrete Service Levels en bijbehorende indicatoren worden gedetailleerd in kaart gebracht en via maandelijkse rapportage en overleg momenten, zorgt de Service Manager voor de bewaking van de SLA om kwaliteit van de dienstverlening te garanderen. Een overzicht van enkele klanten via Managed Services. Service-Oriented Best Effort Services (SOPM) Ordina beschikt over een flexibel uitgewerkte Service-Oriented support formule om tegemoet te komen aan diensten op aanvraag; support diensten volledig in lijn met de noden en behoeften van de klant. Hierbij wordt een flexibele opzet gehanteerd waarmee de klant enkel beroep doet op de Service Desk van Ordina en bijbehorende technische profielen wanneer ze dit nodig achten. Uitgaande van een Best-Effort dienstverlening voorziet Ordina ITSM ook in de mogelijkheid om gegarandeerde Service levels aan te vragen die vervolgens extra in rekening gebracht worden. Een overzicht van enkele klanten via Service-Oriented Best-Effort Services. Corrective Services Vanuit het Competence Center Code Migration & Tools, biedt Ordina s Service Desk ook corrective Services aan; als klant voorziet Ordina Denkart u van intelligente systemen en tools die u de mogelijkheid geven om uw applicatieve code te migreren naar een nieuw platform. Wanneer deze systemen functionele beperkingen vertonen kan u middels onze corrective Services een aanvraag doen tot verruiming van functionaliteiten. Ordina Denkart is hiermee uniek op de markt en biedt deze oplossingen en levert deze diensten aan internationale klantenportefeuille. Een overzicht van enkele klanten via Corective Services. Page 15

16 Het SDI Programma bestaat uit projecten die ITSM Lead Consultants intern uitvoeren. Het omvat momenteel 2 projecten: 1 ste project: Incident Management 2 de project: Request Fulfillment Aan de implmentatie van het 2 de project heb ik het grootste deel van mijn stage meegewerkt. Het is belangrijk een goede, duidelijke structuur te hebben bij het verwezenlijken van projecten Ordina ITSM hanteert de ITIL structuur voor de uitvoering van hun projecten en voorziet bij elk werkgebied de nodige instrumenten: Structuur Implementatie processen Kennisbeheer Knowledge Base, user faqs, procedure templates, Perceptie Tevredenheid Ordina medewerkers over SD. Communicatie Procescommunicatie Transparantie Key Performance Indicator Dashboard Bij elk project zullen deze werkgebieden anders ingevuld worden, naargelang de verreisten van het project. De instrumenten hierboven aangegeven zijn een voorbeeld van ondersteunende middelen. Deze middelen verschillen van proces tot proces. Page 16

17 In dit hoofdstuk wordt ITIL nader omschreven. Wat is ITIL? Hoe is het ontstaan? Hoe wordt het gebruikt? Deze en vele andere vragen zullen beantwoord worden in dit hoofdstuk. De Information Technology Infrastructure Library, ITIL, biedt een systematische benadering van IT dienstenverlening kwaliteit en een aanpak voor efficiënte IT Service Management. ITIL is gekend als een framework van Best-Practices, het bestaat uit een brede waaier van praktische benaderingen voor ITSM met reeds bewezen resultaten en voordelen voor een groot aantal bedrijven. Het moet worden beschouwd als een leidraad; het is geen theorie maar een framework dat organisaties begeleidt bij de uitvoering van ITSM in hun IT afdeling. Praktisch; het ITIL framework bestaat uit een reeks van samenhangende processen, gestructureerde en gestandaardiseerde stroom van activiteiten. Een proces-gebaseerde IT-organisatie maakt controle en sturing mogelijk en is de basis naar continue verbetering. Bovendien, heeft elk proces goed gedefinieerde rollen en verantwoordelijkheden om duidelijke participatie en prestaties van elke deelnemer aan een proces te garanderen en continuïteit te ontwikkelen. Tot slot, door middel van duidelijk gedefinieerde Key Performance Indicators voor processen biedt ITIL de mogelijkheid voor het managen, controleren en verbeteren van processen. Beoogde voordelen van ITIL zijn: Reduceren van kosten Verbetering in dienstverlenende organisatie door gebruik van de beste praktijkoplossingen Verbetering in klanttevredenheid door een meer professionele benadering Standaardisering en begeleiding Verhoging productiviteit Verhoging van gebruik van ervaring en vaardigheden De beoogde voordelen worden soms niet bereikt. De belangrijkste redenen hiervoor zijn: Onvoldoende oog voor bedrijfscultuur Onvoldoende draagvlak bij management en medewerkers Geen continue overwaking van processen ITIL beschrijft deze belangrijke componenten in een framework van Pest-Pratices. Het framework is gekend in twee versies, v2 en v3. In het volgend hoofdstuk worden beide versies ruim besproken. Page 17

18 ITIL is begin jaren negentig in Engeland ontstaan toen de CCTA(Central Computer Telecommunication Agency), een adviesorgaan van de Britse overheid, de opdracht kreeg om een aanpak te ontwikkelen voor efficiënte en economische inzet van ICT-middelen bij de ministeries en andere organisaties van de Britse Overheid. Het is ontstaan uit een verzameling van Best-Practices die in het werkveld van de ITdienstverlening werden aangetroffen. OGC Sinds 2001 is ITIL een product van de OGC(Office of Gouvernement Commerce). Voorheen was het eigendom van een organisatie van de Britse overheid: CCTA. Dit is nu de OGC is geworden. OGC stimuleert het gebruik van Best-Practices op tal van gebieden, zoals Project Management, Programma Management, inkoop, Risico Management en IT Service Management. Daarnaast geeft de OGC zelf een aantal boeken uit die geschreven worden door experts uit diverse bedrijven en organisaties. itsmf Het itsmf(information Technology Service Management Forum) is een Britse vereniging, opgericht in Dit is een vakorganisatie die zich speciaal bezig houdt met de ontwikkeling van het vakgebied IT Service Management. In meer dan veertig landen zijn er ondertussen onafhankelijke itsmf organisaties die samen werken in de overkoepelende organisatie itsmf International(itSMF-I) itsmf heeft betrekking tot het hele vakgebied IT Service Management. Zij bevordert de uitwisseling van informatie en ervaring waarmee IT Organisaties. Het zijn ook zij die zich bezig houden met onder meer de standaard ITIL. APM Group In 2006 heeft OGC het beheer van de ITIL-rechten, de certificering van ITIL -examens en accreditatie van trainingsorganisatie uitbesteed vaan de APM Group(APMG), een commerciële organisatie. APMG bepaalt de certificering en accreditatie voor de ITIL examens en publiceerde het nieuwe certificeringsstelsel. Page 18

19 Alles wat ik moet doen is te lezen al die ITIL boeken In veel opzichten is dit de grootste misvatting. ITIL is een verzameling van Best-Practices. ITIL voorziet een systematische aanpak voor het leveren van de gewenste kwaliteit van IT Services. Het geeft een gedetailleerde omschrijving van de(meest) belangrijke processen in een ITorganisatie en omvat checklists voor taken, procedures en verantwoordelijkheden, die elke ITorganisatie als basis kan gebruiken om ITIL op maat te maken aan de eigen bedrijfsbehoeften. De brede dekking van het ITIL -materiaal maakt het tevens mogelijk om er op elk tijdstip naar terug te grijpen en er nieuwe verbeterdoelen voor de IT-organisatie uit af te leiden. Hierdoor kan de organisatie groeien en volwassen worden. ITIL is niet in die vorm, dat je het kunt aanbieden aan een gehele organisatie, en vervolgens verwachten dat iedereen weet welke zaken hij het eerst moet aanpakken, en wat ieders rol zou moeten zijn. ITIL bevat een enorme schat aan nuttige informatie, waarmee IT Professionals hun eigen kennis en ervaring kunnen aanvullen. Het gebruik van ITIL verschilt van organisatie tot organisatie en moet worden toegepast naar de noden en behoeften van een organisatie. Elke organisatie vereist dus een afzonderlijke aanpak van ITIL. ITIL blindelings toepassen in een organisatie zal leiden tot situaties als onderstaande illustratie weergeeft: Dit is een gevolg van een verminderde focus op de P(eople) en een traditionele grotere focus op processen en technologie. Page 19

20 ITIL V2 is een ITSM framework dat momenteel in een breed scala van bedrijven wordt toegepast. Het is ontwikkeld in 2001 en wordt vandaag in de meeste bedrijven gebruikt. ITIL V2 focust zich voornamelijk op 2 categorieën van processen: Service Support processes: De dagdagelijkse werking en ondersteuning van IT Services. Het bevat de Service desk functie alsook 5 andere processen. Service Delivery processes: De langetermijnplanning en verbetering van IT dienstenverlening. De sterkte van deze versie van het ITIL framework is de structuur in de zin van goed gedefinieerde processen, rollen en verantwoordelijkheden en Key Performace Indicators(KPI s). De onderliggende afhankelijkheden tussen de processen en complementaire karakteristieken verzekeren de toegevoegde waarde aan de kwaliteit van de IT Service. Page 20

21 ITIL V3 is de nieuwste versie van het Best-Practices framework en bestaat uit de recente trends en benaderingen van ITSM, gebundeld in een herziende versie, gepubliceerd in De focus van het framework is de integratie van processen in een Service georiënteerde levenscyclus dat bestaat uit 5 fasen. Daarboven zijn enkele nieuwe processen en functies gedefinieerd en geïntegreerd. De afstemming tussen de IT-organisatie en de klant is daarmee steeds belangrijker geworden. Het is deze trend, dat onder de naam Business IT Alignement verschenen is, de hoofdfocus is geworden in ITIL V3 De nadruk komt meer te liggen op horizontale processen, en beslissingsbevoegdheden worden in toenemende mate neergelegd bij de medewerkers. De verschillende fasen in het leven van een IT-Service zijn beschreven in de levenscyclus. De levenscyclus bestaat uit vijf fasen: 1. Service Strategy - de fase van het ontwerpen, ontwikkelen en implementeren van Service Management als strategisch middel. 2. Service Design - de fase van het ontwerpen van passende en innovatieve IT-Services, waaronder architectuur, processen, beleid en documenten. Het doel van het ontwerp is voldoen aan de huidige en toekomstige eisen van de Business. 3. Service Transition - De fase van de ontwikkeling en verbetering van capabilities voor de transitie van nieuwe en gewijzigde Services naar de productie. 4. Service Operation - De fase van het bereiken van effectiviteit en efficiëntie in de levering en ondersteuning van Services, om waarde te garanderen aan de klant en de Serviceprovider 5. Continual Service Improvement - De fase van het creëren en behouden van waarde voor de klant door verbetering van het ontwerp, de introductie en productie van Services. Service Strategy is de as van de levenscyclus. Alle andere fasen gaan hierop verder. In deze fase worden de doelstellingen en beleidsvorming bepaald. De fasen Service Design, Service Transition, Service Production implemeteren deze strategy. Ze zijn voortdurend onderhevig aan wijziging en verandering. De fase Continual Service Improvement beschrijft het leren en verbeteren van alle andere fasen van deze levenscyclus. Page 21

22 Ondertussen zijn we al aan de derde uitgave en ITIL toe: versie 3. Tussen versie 2 en versie 3 zijn een heel aantal verschillen terug te vinden die in deze paragraaf worden toegelicht. Tijdens mijn stage heb ik mij voornamelijk toegelegd op versie 3 van ITIL. Het was belangrijk dat ik de verschillen goed wist tussen beide versies, omdat bij Ordina(en vele andere bedrijven) niet alles volgens versie 3 wordt benaderd en je daardoor te maken krijgt met ITIL v2. Sinds het verschijnen van ITIL v2 zijn de rol en organisatie van de informatievoorziening gegroeid en veranderd. IT ondersteunt en maakt deel uit van een toenemend aantal goederen en diensten. Ook in het bedrijfsleven is de rol van de informatievoorziening veranderd: IT heeft niet langer slechts een ondersteunende rol, maar is de basis geworden voor het creëren van bedrijfswaarde. ITIL v2 heeft meer aandacht voor de relatie IT en klant. ITIL v3 gaat een stap verder en start van bovenaf met het formuleren van een Service Strategy die goed moet aansluiten op de Business- en IT-strategie. Voordeel hiervan voor organisaties is, dat er gemakkelijk en aantoonbaar een zinvolle bijdrage kan worden geleverd aan de bedrijfsdoelstellingen. Concreet bestaat versie 2 voornamelijk uit de fasen: Service Design, Service Operation en Service Design. Vanaf versie 3 komen daar nog 2 fasen bij: Service Strategy en Service Design. ITIL V3 wil de nieuwe rol van IT in al zijn complexiteit en dynamiek omvatten en inzichtelijk maken. Daarvoor is een nieuwe benadering van Service Management gekozen, waarin niet alleen de processen centraal staan, maar ook de levenscyclus van een Service. In versie 2 komen de bedrijfsdoelstellingen minder aan bod, en is de benadering veeleer procesgericht: de processen en hun onderlinge relaties, rollen en verantwoordelijkheden. Versie 3 hanteert niet meer de processen als uitgangspunt (zoals versie 2), maar dienstverlening (Services) en genereren van toegevoegde waarden voor de Business. Je kiest niet voor versie 2 of versie 3, maar onderdelen ervan afhankelijk van de behoeften van het bedrijf. De V3 insteek is om op Service niveau waarde te genereren, in lijn met de specifieke bedrijfsdoelstellingen van de organisatie. Page 22

23 In dit hoofdstuk ga ik mijn stageopdrachten bespreken. In de eerste paragrafen wordt er wat dieper ingegaan op de ITIL fase, functie en processen waarrond ik gewerkt heb. Vervolgens worden mijn opdrachten, planning en werkomgeving beschreven. Tot slot mijn concrete uitwerkingen. Zoals eerder uitgelegd bestaat de Service levenscyclus uit een aantal fasen. Tot elke fase behoren een aantal processen en functies. Onderstaand vind u een overzicht van deze fasen met bijhorende functies en processen. Omcirkeld zijn de processen en functie waarmee ik aanraking ben gekomen. Mijn stage bleef beperkt tot de fase Service Operation. In deze fase heb gewerkt rond volgende processen: Incident Management Problem Management Request Fullfilment Bij de functies bleef mijn aanraking beperkt tot de functie Service Desk. Het zijn bovengenoemde processen en functie waar ik nu verder in ga, zodat het verband tussen mijn persoonlijk uitgevoerde activiteiten en deze processen/functie duidelijk is. Page 23

24 De Service Desk(SD) is de functie die de processen van de Service Operation fase gaat uitvoeren. De SD speelt een zeer belangrijke rol bij de operationele uitvoering van ondersteunende processen. Concreet heb ik een aantal uitwerkingen rond elk van deze processen moeten maken: Incident Management: een adviesrapport voor verbetering van de procesuitvoering Incident Management Problem Management: een analyse van Incident records ter identificatie van potentiële Problems en preventieve maatregelen Request Fulfillment: efficiënte afhandeling door standaardisatie en uitwerking van TOP10 wederkerende Service Requests Page 24

25 Het is heel belangrijk een goede planning te hebben. De planning voor mijn stageperiode is opgesteld in samenspraak met mijn stagementor. Dit is een overzichtelijke, grafische voorstelling in Excel. Mijn stage is ingedeeld in een aantal fasen: Inleiding & planningsfase Literatuurstudiefase Analysefase Incident Management fase Problem Management fase Request Fulfillment fase Deze fasen zijn ook terug te vinden in de planning. In mijn planning zijn mijn deliverables aangeduid, zodat ik steeds een overzicht had wat wanneer klaar moest zijn. De volledig uitgewerkte planning in Excel, is terug te vinden in Appendix A. Naast processen zijn er andere ondersteuningsmiddelen die erg belangrijk zijn om te komen tot een performante Service Desk. Deze middelen worden Service Capabilities genoemd: complementaire middelen die bijdragen aan een efficiënte en effectieve dienstverlening. De tools waarmee ik gewerkt heb tijdens mijn stage zijn voornamelijk TOPdesk en het KPI Dashboard. TOPdesk De implementatie van IT Service Management verreist ondersteunende tools om de proces flows en gerelateerde Service capabilities te integreren. Ordina gebruikt TOPdesk en integreert alle processen en Service capabilities hierin volledig. TOPdesk is een web-based ondersteuningstool dat procesgeoriënteerde practices toelaat. De tool bestaat uit gescheiden modules, dat ingaan op de verschillende ITIL processen. De belangrijkste voordelen van TOPdesk zijn: Geschikt om ITIL processen en gerateerde Service capabilities te integreren. Geïntegreerde Self Service Desk, toegankelijk door gebruiker voor incident aanmelding. Web-based Rapporterende functionaliteiten. Page 25

26 KPI Dashboard Het KPI Dashboard is een Reporting tool van Ordina die behoort tot het deelgebied transparantie van de structuur die Ordina ITSM hanteert. Transparantie: dashboards en performance reporting op basis van Key Performance Indicatoren als middelen voor sturing en verbetering Het KPI dashboard zorgt voor rapportering van bepaalde processen. Door middel van grafieken en parameters is dit een ideale rapporteringstool. Voor mijn analyses heb ik beroep gedaan op deze tool. Ik heb deze tool gebruikt voor: Incident Management: grafische voorstellingen van procentuele verhoudingen tussen bepaalde categorieën, incidenten tussen bepaalde periode op te zoeken in een bepaalde categorie, Problem Management: incidenten op te zoeken voor een bepaalde periode en categorie. Exportfunctie om lijsten te exporteren naar Excel. Deze lijsten zijn vervolgens bewerkt en verwerkt in mijn analyse. Page 26

27 In dit hoofdstuk worden mijn uitwerkingen besproken. Hoe ik te werk ben gegaan en wat het resultaat is. Ook worden mijn persoonlijke bevindingen, conclusies, etc. beschreven in dit hoofdstuk. Mijn eerste opdracht was een adviesrapport voor de verbetering van de procesuitvoering Incident Management maken. In de volgende paragraaf wordt het proces Incident Management beschreven Incident Management ITIL definieert een Incident als volgt: Een Incident is een ongeplande interruptie of kwaliteitsreductie van een IT-Service. Verlies van een CI die nog geen impact heeft op de Service is ook een Incident. De primaire doelstelling: Het zo snel mogelijk hervatten van de normale gang van zaken en het minimaliseren van de impact op de bedrijfsprocessen. Waarde voor de business: De mogelijkheid incidenten op te sporen en op te lossen leidt tot een lagere storingstijd voor de business. Hierdoor is de Service langer beschikbaar De mogelijkheid om IT-activiteiten op één lijn te brengen met de business-prioriteiten. Dit omdat Incident Management de mogelijkheid kent business-prioriteiten te identificeren en resources dynamisch te verdelen De mogelijkheid om potentiële verbeteringen voor Services vast te stellen. Incident Management is een Service Operation Process. Het Incident Management Process concentreert zich op het zo snel mogelijk herstellen van verstoorde Services voorgebruikers, zodat de invloed op de business minimaal is. Incidenten kunnen storingen of vragen zijn. Incident Management omvat ieder event dat een Service verstoort of kan verstoren. Dit zijn dus ook events die direct door gebruikers worden gemeld, hetzij door de Service Desk of via verschillende tools. Page 27

28 Het Incident Management process bestaat uit de volgende activiteiten: Opzet Mijn eerste opdracht was een adviesrapport voor de verbetering van de procesuitvoering Incident Management binnen Ordina schrijven. Om dit adviesrapport uit te schrijven moest ik beginnen met een analyse van de procesuitvoering Incident Management. Het Incident Management Process bestaat uit een aantal activiteiten die de Service Desk uitvoert. Het was de uitvoering van deze activiteiten die ik eerst moest evalueren. Page 28

29 Dit zijn de activiteiten visueel voorgesteld die de Servicedesk moet uitvoeren gedurende de levenscyclus van het incident: Bijvoorbeeld: een gebruiker zijn computer start niet meer op(ram geheugen slot is stuk) De activiteiten die 1 st line Support zal uitvoeren: Het incident loggen(een ticket in TOPdesk aanmaken) Een diagnose stellen om de mogelijke oorzaak te achterhalen Het incident escaleren naar het 2nd line support team, indien het de oorzaak niet vindt 2 nd line Support gaat dan: Het Incident oplossen (Nieuw moederbord plaatsen in dit voorbeeld) De oplossing documenteren in het ticket(oplossing en oorzaak in de ticket-info noteren) Vervolgens het ticket terug doorsturen naar het eerste lijns team 1 Th line Support: De oplossing evalueren Accepteren, als het een correcte oplossing is(in dit geval: als de computer terug werkt) Het incident afsluiten(de computer aan gebruiker bezorgen) Het rapport is gebaseerd op de evaluatie van de operationele uitvoering in functie van het voorgeschreven proces. Er zijn voor dit rapport 50 willekeurige calls geëvalueerd. Dit zijn allemaal calls die aangemeld zijn in het jaar 2010 omdat men in 2009 nog bezig was met het Incident Managementproces te implementeren. Er is gebruik gemaakt van de Service desk tool Topdesk en het incident dashboard van Ordina. Uit de evaluatie van deze calls zijn de conclusies en adviezen opgemaakt die in dit rapport zijn terug te vinden. Binnen het proces Incident Management zijn volgende activiteiten geëvalueerd: - Incident Registration; - Incident Categorization; - Incident Prioritization; - Incident Diagnoses; - Incident Escalation; - Incident Communication. Page 29

30 Voor de evaluatie van elke call per activiteit is onderstaande beoordeling gehanteerd. Er wordt ook telkens 1 case per activiteit uitgelegd waarbij het proces beter zou kunnen worden uitgevoerd. Beoordeling Kleurcode Goed Gemiddeld Slecht Beschrijving Procesactiviteit werd goed uitgevoerd Gebrekkige uitvoering zonder impact op de klanttevredenheid Gebrekkige uitvoering met impact op de klanttevredenheid Aan de hand van bovenstaande beoordelingsgrafiek zijn de taartdiagrammen per activiteit opgesteld. Deze taartdiagrammen geven een procentuele voorstelling van het totaal aantal calls per activiteit die goed, gemiddeld en slecht werden uitgevoerd. Hierdoor krijg je dus een algemeen overzicht van de uitvoering van elke activiteit(=het resultaat) % % % Goed Gemiddeld Slecht Door het gebruik van kleuren kon ik op het einde van de analyse meteen zien waar de problemen zich situeerden. Wanneer een kolom maar weinige groene cellen bevatte kon je meteen concluderen dat deze activiteiten slecht wordt uitgevoerd. In de afbeelding hierlangs kan je al onmiddellijke zien dat de 2 de, 3 de en laatste kolom veel gebrekkige uitvoeringen bevat. De volledige analyse vindt u in appendix C Resultaat Uit mijn analyse ben ik tot een adviesrapport gekomen waarbij mijn conclusie voor de verbetering van de procesuitvoering Incident Management als volgt luidt: De incidenten worden meestal goed geregistreerd. Het is vaak aangewezen een gedetailleerdere omschrijving van het Incident. De categorisatie dient meer op basis van de onderliggende oorzaak te gebeuren. Uit de evaluatie van de activiteiten blijkt dat vooral de activiteit Incident Diagnoses beter moet worden uitgevoerd om de vooropgestelde objectieven te bereiken. Zoals eerder vermeld dient elke stap in het Incident Record te worden opgenomen. Elke persoon die met deze activiteit te maken krijgt moet zich hiervan bewust zijn. De escalatie verloopt vrijwel altijd correct. De communicatie naar de gebruiker kan nog wat beter. Zo dient het incident meer gelogd te worden(bij telefonische aanmelding en binnenkomst per mail ) en zou men meer gebruik moeten maken van status updates om de gebruiker op de hoogte te houden zodat deze zelf geen contact dient op te nemen wat tot overbodige communicatie leidt. Voor het hele rapport te lezen, verwijs ik u door naar appendix C van dit stagerapport. Page 30

31 Mijn 2 de opdracht kaderde in het proces van Problem Management. Het was een rapport schrijven met een top 10 van wederkerende incidenten, mogelijke Problems. In de volgende paragraaf wordt het proces Problem Management nader verklaard Problem Management ITIL definieert een Problem als volgt: Een Problem is de onbekende oorzaak van één of meer incidenten. De primaire doelstelling: Het voorkomen van Problems en Incidenten, het elimineren van wederkerende incidenten en het minimaliseren van de impact van incidenten die niet voorkomen kunnen worden. Waarde voor de business: Zorgt dat de kwaliteit van de IT-dienstverlening toeneemt Het aantal incidenten en afhandelingstijd vermindert Kortere storingstijd en mindere storing van de bedrijfskritieke systemen Problem Management is verantwoordelijk voor het beheren van de levenscyclus van alle problems. Het omvat alle activiteiten die nodig zijn om een diagnose te stellen van de onderliggende oorzaak van incidenten en om een oplossing te vinden voor die problems. De hoofdactiviteiten van Problem Management zijn: - Problem control: Het onderzoeken van het probleem - Error control: het bewaken van known errors - Procatief beheer: het voorkomen van problemen - Trendanalyse: het vroegtijdig opsporen van mogelijke fouten - Rapportage: het verschaffen van informatie Page 31

32 Het Problem Management Process: Informatiestromen uit andere processen Analyse Problem control Identificatie & registratie Clasificatie en allocatie Voortgang bewaken Onderzoek en diagnose Error identificatie en registratie Onderzoek naar oplossing Problems Vastleggen van de gekozen oplossing Change mangement Evaluatie/ review probleem Afsluiten probleem Error control! Dit is niet als proces uitgewerkt binnen Ordina, maar wordt als activiteit uitgevoerd. Page 32

33 Opzet Om 10 wederkerende Incidenten te vinden, moest er een analyse gemaakt worden. In deze analyse zijn alle interne Ordina calls van 1 januari 2010 tot 15 april 2010 geëvalueerd. De analyse is enkele stappen gebeurd: Stap 1: De calls herindelen op een correcte aanmelding en categorisatie (identificatie review) Stap 2: De incidenten van de Requests scheiden (herindeling) Stap 3: De categorieën analyseren waarin het meest aantal incidenten zijn terug te vinden (top categorieën) Stap 4: De subcategorieën met het meest aantal incidenten isoleren(top sub categorieën) Stap 5: De incidenten evalueren op trends in de top subcategorieën (top 10 terugkerende incidenten) Page 33

34 Door stap 1 en 2 uit te voeren zijn we tot onderstaande verdeling gekomen: Door de soort aanmelding te verbeteren zijn we van 819 incidenten naar 793 gegaan. Indien dit niet was gebeurt, hadden we een vertekend beeld gekregen. Bijvoorbeeld: Wanneer een bepaalde categorie 90% incidenten bevat, gaat men denken dat hier een probleem is. Door verkeerde aanmelding blijkt achteraf dat dit maar 40% zou moeten zijn en er dus helemaal geen probleem is. Hier was dan sprake van een vertekend beeld geweest. Na de herindeling hebben we een onderscheid gemaakt tussen de Requests en incidenten. De incidenten zijn het uitgangspunt voor de Problem Management Analyse, de Requests voor de Change Templates Analyse (Request Fulfillment). Door stap 3 uit te voeren hebben we de 10 categorieën met het meest aantal incidenten verkregen. Page 34

35 Wanneer we hier de top 10 categorieën uithalen en het aantal incidenten optellen komen we aan 678 incidenten. Dit betekent dat 85% van alle incidenten tot deze categorieën behoort. De analyse beperkt zich tot deze 10 categorieën. Door verdere eliminatie van subcategorieën binnen deze top 10 categorieën zijn we tot volgende 15 top subcategorieën gekomen: Categorie Subcategorie Aantal 1 Ordina application CV tool 76 2 Ordina application Topdesk 60 3 Ordina application Sharepoint/intranet 48 4 Ordina application Evobizz 41 5 Facility Equipement 36 6 Server configuration Other 35 7 Workstation software MS Outlook 31 8 Account Login 30 9 Laptop hardware Other SAP Software Technical Other Other hardware Printer/scanner Workstation software Other Workstation software OCS Laptop hardware Adapter Network VPN 12 In de top subcategorieën hebben we de incidenten geëvalueerd op trends om zo tot een top 10 van terugkerende incidenten te gaan. Deze top 10 wordt in het volgende hoofdstuk individueel per incident besproken. Per Incident is dan ook een preventieve maatregel te vinden die een mogelijke oplossing voor het probleem biedt Resultaat Uiteindelijk ben ik tot een TOP 10 van wederkerende incidenten gekomen. Voor elk van deze incidenten heb ik een beschrijving gegeven en een preventieve maatregel voorgesteld om deze incidenten in de toekomst te beperken of vermijden. Mijn algemene conclusie van dit Problem Management Rapport geldt als volgt: Vaak zijn de incidenten te wijten aan netwerkproblemen of slechte testing van de software. Aangewezen voor deze incidenten te vermijden naar nieuwe applicaties toe in de toekomst is wat meer te investeren in software testing en pas een release doen als de meeste bugs uit de applicatie zijn. Momenteel zouden problemen met een bepaalde tool opgelost kunnen worden door even samen te zitten als ontwikkelaarsteam en te kijken naar de onderliggende oorzaak van deze incidenten en dit aan te pakken. Ook komt het wel meerdere keren voor dat een incident een gevolg is van een netwerkprobleem. Hier geldt de conclusie dat er wat meer geïnvesteerd moet worden in de netwerkinfrastructuur of het beheren van het huidige netwerk zodat deze incidenten vermeden kunnen worden. Het uitgewerkt resultaat van mijn Problem Management rapport is terug te vinden in Appendix E. Page 35

36 Mijn laatste opdracht was de implementatie van Change Templates voor de TOP 10 Service Requests bij Ordina in het kader van Request Fulfillment Request Fulfillment ITIL definieert een Service Request als volgt: Een Service Request is een verzoek van een gebruiker om informatie, advies, een standaard change, of toegang tot een Service. De primaire doelstelling: Efficiënte afhandeling van Service Requests door standaardisatie van deze Requests. Request Fulfillment verwerkt Service Requests van de gebruikers. De doelstelling van het Request Fulfillment proces zijn: Gebrukers een kanaal bieden waar ze standaard Services kunnen aanvragen en ontvangen. Hiervoor moet een afgesproken goedkeurings- en kwalificatieproces bestaan Informatica bieden aan gebruikers en klanten over de beschikbaarheid van Services en procedure om ze te verkrijgen Het leveren van de componenten van standaard Services(bijvoorbeeld licenties en softwaremedia) Helpen met algemene klachten of opmerkingen Waarde voor de Business: Een snelle en effectieve toegang bieden tot standaard Services die de Business kan gebruiken om de productiviteit of de kwaliteit van de Business Services en producten te verbeteren Het vermindert bureaucratie bij het verzoeken om en ontvangen van toegang tot bestaande of nieuwe Services. Hierdoor dalen de kosten voor het leveren van deze Services. Page 36

37 Opzet Eerst moest ik een analyse opstellen om te komen tot een top 10 van Service Requests. Periode: Alle calls aangemeld in 2010 De aanpak: Alle incidenten geëvalueerd Categorisatie gecorrigeerd Requests geïsoleerd Vertegenwoordigd: 33% van alle Service Requests Door het wegvallen van enkele Requests in de top 10 die niet gestandaardiseerd kunnen worden, heb ik deze top 10 uitgebreid tot een top 15. Deze top 15 vertegenwoordigt 33% van het totaal aantal Service Requests. Page 37

38 Resultaat Om deze Requests te kunnen standaardiseren was er een analyse nodig per Request waarin volgende zaken geëvalueerd werden: Category Tot welke categorie behoort de Request?(Acces/Hardware/Software/Other Request) User Info Welke informatie dient de gebruiker te geven om de Request uit te kunnen voeren? Activiteiten Welke teams handelden de Request af? Welke activiteiten zie je terugkeren en in welke volgorde? Waren er afhankelijkheden tussen de activiteiten? (Eerst X alvorens Y kan starten) Verwachte werkinstructies Welke teams handelden de Request af? Welke activiteiten zie je terugkeren en in welke volgorde? Waren er afhankelijkheden tussen de activiteiten? (Eerst X alvorens Y kan starten) Afhandelingsinfo Welke teams handelden de Request af? Welke activiteiten zie je terugkeren en in welke volgorde? Waren er afhankelijkheden tussen de activiteiten? (Eerst X alvorens Y kan starten) Timing Hoelang schat je op basis van de info in de tickets dat het uitvoeren van een request kan duren. (exclusief de tijd dat er gewacht wordt op de gebruiker, dus puur het uitvoeren van de Request als alle info beschikbaar is) Approval Werd er om approval gevraagd alvorens de Request uitgevoerd werd en aan wie? (gewoonlijk BUM) Ondersteunende middelen Werden er middelen gebruikt bij het uitvoeren van de request? Welke? Procedures? Indien niet, welke middelen zou je verwachten om de requesten uit te kunnen voeren. Beschrijvende info Wat houdt de activiteit precies in? Waarom is de activiteit nodig? Wie voert de activiteit uit? Hoe wordt de activiteit uitgevoerd? Raadpleeg Appendix F voor de volledige analyse. Page 38

39 Door deze analyse uit te voeren kwam ik tot een Excel document waarin de nodige informatie in verwerkt was voor de implementatie van de Change Templates in TOPdesk. Het uiteindelijke resultaat van de invoering van het proces Request Fulfillment is een medium waar mensen Service Requests kunnen aanvragen en informatie kunnen terug vinden over de beschikbaarheid van Services. Alle Service Requests in de Request Catalog zijn gestandaardiseerde Requests. Dit geeft de organisatie volgende voordelen: Versnelde afhandelingstijd Besparing in opleiding Verhoogde klanttevredenheid Transparantie over afhandelingsproces Onderstaand ziet u de Request Catalog, waarvoor mijn analyse en sjablonen diende: De Ordina medewerkers kunnen in de toekomst deze catalogus dan gebruiken voor het aanvragen van Serivce Requests. Page 39

40 Voor dat ik mijn stage begon had ik enkel wat theoretische kennis over ITIL en was mij de waarde van ITIL en ITSM geheel niet duidelijk. Dankzij mijn stage heb ik nu een hele persoonlijke visie ontwikkeld hierover, die ik in deze paragraaf ga toelichten. Vandaag is ITSM niet meer weg te denken in een organisatie. Alles staat en valt met structuur. Voor structuur in een organisatie zorgen, is één van de objectieven waar ITSM naar streeft. Technologie is voor een organisatie zeer belangrijk. Maar technologie moet ondersteund worden. ITSM zorgt voor deze ondersteuning. ITSM brengt veranderingen teweeg in een organisatie. Het is mij opgevallen, hoe moeilijk het is om een verandering in een organisatie te brengen. De meeste mensen veranderen niet graag en zien of willen de voordelen ervan niet inzien. Ze doen graag verder hoe ze bezig zijn. Het is bijgevolg een zware taak van ITSM professionals om projecten op te zetten in een bedrijf. Het zijn zij die de overige medewerkers van het bedrijf moeten overtuigen van het nut van de verandering. Door mijn bedrijfsstage heb ik een bijzonder goed inzicht gekregen in het werk en belang van ITSM Professionals. ITSM professionals kan ik na afloop van mijn stage als volgt beschrijven: Uitstekende motivators Communicatie-experten Duizendpoten Enthousiastelingen ITSM Professionals moeten nauw samenwerken met Service Desk Engineers. Het is in het bijzonder naar deze medewerkers dat ze hun enthousiasme moeten overbrengen. Zij gaan moeten veranderen en het is daarmee heel belangrijk dat deze mensen enthousiast worden en de voordelen en het nut van de projecten inzien. De Service Desk is daarboven de as van de organisatie. Als deze mensen kwalitatief hoge IT dienstverlening kunnen uitvoeren, dan zal dit een positief gevolg hebben op heel de organisatie. Ik vond mijn stageperiode een uitstekende leerschool. Op school krijg je de kans om met technologie in de praktijk te werken, en Service Management in theorie. Met Service Management kennismaken in de praktijk, komt niet aan bod. Deze bedrijfsstage heeft mij deze mogelijkheid gegeven om kennis te maken met Service Management in de praktijk. Waar ik het moeilijk mee had was de ontbrekende ervaring. ITSM bestaat uit eigen ervaring + Best Practices. Zonder de eigen ervaring is het praktisch onmogelijk om aan de slag te gaan als ITSM medewerker. Maar wie weet is dit voor mij weggelegd na enkele jaren werkervaring. Page 40

41 Cartlidge A., e.a. An Introductory Overview of ITIL V3,The UK Chapter of the itsmf, UK - Wokingham, 2007 Cartlidge A., e.a. IT Service Management,itSMF ltd, Reading, 2001 Van Bon J. e.a. Foundations of IT Service Management op basis van ITIL V3, Van Haren Publishing, Zaltbommel, 2009 Van Bon J. e.a. Service Operation op basis van ITIL V3, Van Haren Publishing, Zaltbommel, 2009 Ordina, Service Desk Improvement Workspace Ordina, Compentece Center IT Service Management Workspace Ordina, Kennissysteem Ordina, Procesdocumentatie IT Service Management

42

43 Planning stage Jasper Vandegaer Inleiding & Planning Literatuurstudie Analyse Problem ManagemIncident Manag Stageverdedigin Uitwerking rapport Request fulfil Taak Inleiding Invulling opdracht Inleiding topdesk Inleiding KPI dashboard Inleiding Service improvement project Planning Versie 1 Eindversie Planning voltooid Literatuurstudie 'Introductory Overview of IITIL V3' van OGC 'IT Service Management' pocket guide ITSMF 'Foundations of ITSM' pocket guide ITSMF Literatuurstudie voltooid FASE 1 FASE 2 Fase 3 Fase 4 Fase 5 Fase 6 Fase 8 Fase 9 Maart April Mei Juni WEEK 1 WEEK 2 WEEK 3 WEEK 4 WEEK 5 WEEK 6 WEEK 7 WEEK 8 WEEK 9 WEEK 10 WEEK 11 WEEK 12 WEEK 13 WEEK Analyse ITSM binnen ORDINA Vergelijking ITIL best practices & procesuitvoering SD ORDINA Kennissysteem Procedures, werk instructies FAQ's Proces documentatie Analyse voltooid 5 Incident management Evaluatie procesuitvoering per activiteit in excel Uitschrijven adviesrapport Adviesrapport Incident Management 6 Incident Management voltooid 7 Problem management Evaluatie calls op soort aanmelding en categorisatie in excel Top 10 problems opstellen Oplossingen per problem voorstellen Analyserapport problem Management 8 Problem Management voltooid 9 Request fulfilment Vaak voorkomende requests analyseren Analyse Requests gebaseerd op Ticket info Top 10 change templates in TOPdesk implementeren 10 Request fulfilment voltooid 11 Uitwerking stagerapport Overlegmomenten(ordina) 13 Terugkeermomenten naar school Stagerapport uitwerking Inleveren stagerapport abstract 14 Inleveren stagerapport 15 Uitwerking stagerapport voltooid 16 Stageverdediging Voorbereiden presentatie Dry run Stage verdediging uitvoeren 17 Stage verdediging voltooid 18 Legende 1. Versie 1 planning afhebben 2. Eindversie planning af hebben 3. Planningsfase voltooid 4. Literatuurstudiefase voltooid 5. Analysefase voltooid 6. Adviesrapport voltooid 7. Incident mgt voltooid 8. Analyserapport problem mgt klaar 9. Problem mgt fase voltooid 10. Top requests +eventuele uitwerking klaar 11.Request fulfilment fase voltooid 12. Meedraaien op SD voltooid 13.Elke vrijdag een overlegmoment met stagebegeleider 14. Stagerapport klaar 15. Inleveren stagerapport abstract op school 16. Inleveren stagerapport op school 17. Stageverdedeging op school 18. Stage verdediging en stage voltooid

44

45 ACTIVITEITENVERSLAG Naam: Klas: Jasper Vandegaer 3 Software Management Academiejaar: Stageplaats: Ordina Belgium Provinciale Hogeschool Limburg (PHL) Departement Handelswetenschappen en bedrijfskunde Elfde-Liniestraat Hasselt t +32(0) e h&b@phl.be w

46 Stagerapport: Activiteitenverslag Week 1 Maandag 8 maart 2010 Kennismaking met de stagementor, Inleiding bedrijf en bespreking stageopdracht. Presentatie rond informaticarecht voorbereiden, inleiding ITSM 1 door Niels Coninx Problemen: Opdracht niet in de lijn van mijn afstudeerrichting(netwerkopdracht) opgelost door nieuwe stagebegeleider, opdracht rond ITIL Dinsdag 9 maart 2010(Mechelen) Vergadering omtrent stage opdrachten Kennismaking met TOPdesk programma/service Desk werking Problemen: / Woensdag 10 maart 2010 Lectuur(pocket guides) over ITIL doornemen. Kennismaking met Service Desk Improvement project Ordina, review presentaties hieromtrent. Problemen: / Donderdag 11 maart 2010 Het boek foundations of ITSM van OGC 2 lezen met de nadruk op ITIL levenscyclus Fase Service Operation. Service Operation methodes uit het boek ITIL v3 vergelijken met de gebruikte methodes binnen Ordina. Problemen: / Vrijdag 12 maart 2010 Doornemen presentaties Knowledge Base 3 + vergadering verdere invulling opdracht met de nadruk op Request Fulfillment. Verdere documentatie doornemen Knowledge base, bekijken procedures op TOPdesk. Problemen: / 1 Information technology Service management: het implementeren en managen van Servicekwaliteit. 2 Office Government Commerce: departement van de Britse overheid en eigenaar van ITIL. 3 Kennisbeheersysteem binnen Ordina: hier worden alle procedures en activiteiten bewaard Page 1 / 14

47 Stagerapport: Activiteitenverslag Week 2 Maandag 15 maart 2010 Doornemen boek Service Operation van OGC. Analyse calls januari 14 maart in Excel. Problemen: KPI 4 dashboard niet beschikbaar daarom nog wat lectuur doornemen Dinsdag 16 maart 2010 Analyse calls/subcategorie adv top 10 categorieën. In kaart brengen interne Requests. Problemen: geen toegang tot reportserver. vrijdag aankaarten tijdens vergadering. Woensdag 17 maart 2010 Pocket guides An introductory Overview of ITIL v3 en ITSM doornemen. Requests verder analyseren Problemen: TOPdesk en dashboard zijn niet beschikbaar, dus kan ik niet verder met het onderzoek van meest voorkomende Requests. Daarom nog wat literatuur doornemen. Donderdag 18 maart 2010 Requests verder analyseren Problemen: / Vrijdag 19 maart 2010 Review van de top Requests op het gebied van doorlooptijd, kost, welke afdelingen de Request betrekking heeft... Vergadering: review afgelopen week, verder plannen stage opdracht, Problemen/ vragen/ opmerkingen bespreken... Problemen: / 4 Key performance indicator: een meeteenheid die gebruikt wordt bij het managen van een proces, IT Service of activiteit Page 2 / 14

48 Stagerapport: Activiteitenverslag Week 3 Maandag 22 maart 2010 Planning verder opstellen. Deze planning opsplitsen in elke fasen en mijn deliverables voor Ordina en de school toe hierin opnemen. Werkinstructies doornemen + start opdracht Incident Management. Deze opdracht heeft als doel een adviesrapport te schrijven voor de verbetering van de procesuitvoering Incident Management. Problemen: / Dinsdag 23 maart 2010 Incident Management: alle calls voor een bepaalde op soort aanmelding reviewen en de Requests elimineren zodat enkel met de Incidenten wordt verder gegaan. Problemen: / Woensdag 24 maart 2010 Verder review calls op soort aanmelding. Problemen: / Donderdag 25 maart 2010 Idem aan woensdag. Review opvolging werkinstructies in de praktijk. Eerste terugkeermoment naar school waarbij een presentatie gegeven werd en de winnaar bekend gemaakt van het project dat plaats vond voor de thuisblijvers van de CEBIT reis. Problemen: Soms onduidelijkheid over type Incident. om raad vragen bij stagebegeleider tijdens wekelijkse meeting. Vrijdag 26 maart 2010 Vergadering: review afgelopen week, verder plannen stageopdracht, Problemen/ vragen/ opmerkingen bespreken.planning verder uitwerken, voorgeschreven categorisatie vergelijken met uitvoering in de praktijk, knelpunten vaststellen en bevindingen noteren. Page 3 / 14

49 Stagerapport: Activiteitenverslag Week 4 Maandag 29 maart 2010 Categorisatie verder analyseren & laatste details aan de planning leggen. Problemen: / Dinsdag 30 maart 2010 Verdere categorisatie reviewen, oplossingen en adviezen bedenken. Idem + de werkinstructies doornemen en kijken hoe ze worden uitgevoerd en kijken waar er tekortkomingen zijn(=adviesrapport) Problemen: / Woensdag 31 maart 2010 Idem aan dinsdag Procedures doornemen en de uitvoering vergelijken Problemen: Incident dashboard geeft weer errors verder via TOPdesk gewerkt Donderdag 01 april 2010 Categorisatie verder reviewen. Voorstel verbeterde categorisatie uitwerken in Excel. Problemen: / Vrijdag 02 april 2010 Geen activiteiten uitgevoerd wegens ziekte. Page 4 / 14

50 Stagerapport: Activiteitenverslag Week 5 Maandag 19 april 2010 Bestaande procesdocumentatie Ordina doornemen. Begin evaluatie calls Problemen: / Dinsdag 21 april 2010 Uitwerking adviesrapport: evaluatie opvolging van de bestaande procesdocumentatie(incident registration, categorisation, prioritisation, diagnosis, escalation en closer) en dit voor een 50tal calls. Dit zijn allemaal activiteiten die uitgevoerd worden bij het proces Incident Mangement. Problemen: / Woensdag 22 april 2010 Idem Dinsdag + grafisch voorstellen van geëvalueerde calls. Problemen: / Donderdag 23 april 2010 Uitschrijven adviesrapport Problemen: Concrete opbouw van het adviesrapport nog niet rond. Dit bespreken op de vergadering van vrijdag. Vrijdag 23 april 2010 Verder uitschrijven adviesrapport Vergadering: review adviesrapport, verder plannen stage opdracht, Problemen/ vragen/ opmerkingen bespreken. Problemen: / Page 5 / 14

51 Stagerapport: Activiteitenverslag Week 6 Maandag 26 april 2010 Uitschrijven adviesrapport cases opstellen om verbeterpunten aan te halen. Voor mijn adviesrapport een conclusie uitschrijven. Problemen: / Dinsdag 27 april 2010 Begin Problem Management analyse: calls beoordelen op een juiste categorisatie en soort aanmelding Problemen: / Woensdag 28 april 2010 Geen activiteiten uitgevoerd wegens medisch onderzoek in ziekenhuis Donderdag 29 april 2010 Verder de calls beoordelen op een juiste categorisatie en soort aanmelding Problemen: / Vrijdag 30 april 2010 Geen activiteiten uitgevoerd wegens afspraak resultaat medisch onderzoek ziekenhuis. Wekelijkse vergadering: review adviesrapport, verbeterpunten bespreken, uitwerking Problem Management analyse, Problemen: / Page 6 / 14

52 Stagerapport: Activiteitenverslag Week 7 Maandag 3 mei 2010 Adviesrapport afronden: verbeterpunten uitwerken die besproken zijn tijdens de review van het adviesrapport Problemen: / Dinsdag 4 mei 2010 Problem Management analyse: calls beoordelen op een juiste categorisatie en soort aanmelding(request/incident) in Excel, om deze daarna te filteren zodat er daarna met de Incidenten verder kan gewerkt worden om tot een top 10 van potentiële Problems te komen binnen Ordina. Problemen: / Woensdag 5 mei 2010 Idem aan dinsdag + bezoek stagelector: bespreking van de uitgevoerde activiteiten, het verdere stageverloop, mijn persoonlijke planning, het laatste terugkeermoment, het stagerapport en de stageverdediging. Problemen: / Donderdag 6 mei 2010 Laatste categorieën verder analyseren op correcte aanmelding en categorisatie. Problemen: / Vrijdag 7 mei 2010 Wekelijkse vergadering: bespreking opbouw Problem Management analyse, review uitwerkingen afgelopen week. Meeting om de opzet en aanpak te evalueren om zo begin volgende week gericht van start te kunnen gaan met de volledige procesimplementatie en integratie van Request Fulfillment Problemen: / Page 7 / 14

53 Stagerapport: Activiteitenverslag Week 8 Maandag 10 mei Uitschrijven rapport Problem Management analyse in word: hoofdstukken Inleiding, Problem Management, objectieven, opzet uitschrijven. Problemen: / Dinsdag 11 mei Verder filteren van de categorieën waar het meeste Incidenten in voorkomen. Daarna deze filteren om tot de subcategorieën te komen waar de meeste Incidenten bevinden. De Incidenten in deze subcategorieën dan doorlopen op zoek naar een trend van Incidenten. Vergadering met stagebegeleider: bespreking uitgevoerde activiteiten Problemen: / Woensdag 12 mei Zoeken naar potentiële Problems in de top subcategorieën van mijn analyse. Het aandeel van de Incidenten grafisch voorstellen per categorie/subcategorie. Het Problem Management Analyse rapport verder uitschrijven. Eén case per gevonden probleem opstellen, waarbij het probleem wordt omschreven + mogelijke oplossingen bedenken. Donderdag 13 mei Vrije dag Vrijdag 14 mei Problem Management rapport verder uitschrijven: mogelijke oplossingen beschrijven. Afronding rapport: cases verder uitwerken + conclusie Page 8 / 14

54 Stagerapport: Activiteitenverslag Week 9 Maandag 17 mei Begin Request Fulfillment fase. De Requests van de Incidenten gaan scheiden om hier uiteindelijk een top 10 van meest voorkomende Requests uit te halen. Deze top 10 kan dan later worden opgenomen in een Request Catalog. De analyse van Requests voor een bepaalde periode is nodig om te zien wat veelvoorkomende Requests zijn. Deze analyse ga ik deze week uitvoeren zodat we een top 10 hebben en kunnen beginnen met de implementatie van Request Fulfillment binnen Ordina. Grafisch voorstellen van Requests per categorie maken om te zien in welke categorieën de meeste Requests bevinden. Deze topcategorieën verder analyseren. Problemen: / Dinsdag 18 mei De subcategorieën van de topcategorieën grafisch voorstellen zodat men een overzicht heeft in welke subcategorieën de meeste Requests bevinden. Deze subcategorieën zijn het vertrekpunt voor de top 10 Requests. De top subcategorieën analyseren en dezelfde Requests groeperen zodat men uiteindelijk tot een top 10 komt van meest voorkomende Requests. Van deze top 10 zullen de volgende weken sjablonen worden aangemaakt. Problemen: / Woensdag 19 mei Afwezigheid wegens operatieve ingreep Donderdag 20 mei Afwezigheid wegens operatieve ingreep Vrijdag 21 mei Afwezigheid wegens operatieve ingreep Page 9 / 14

55 Stagerapport: Activiteitenverslag Week 10 Maandag 24 mei Feestdag Dinsdag 25 mei Review van de al aanwezige wijzigingssjablonen en ondersteunend materiaal. Dit is een ruw voorbeeld van de sjablonen die ik ga moeten uitwerken de komende weken. Laatste cases verder uitschrijven Problem Management rapport. Begin uitwerking stagerapport. De inhoud bepalen + het rapport indelen in verschillende hoofdstukken. Problemen: / Woensdag 26 mei tot en met vrijdag 28 mei Per Request uit mijn TOP 10 lijst Requests die gestandaardiseerd gaan worden een overzicht maken met daarin onderstaande informatie: USER INFO Welke informatie dient de gebruiker te geven om de Request uit te kunnen voeren? AFHANDELINGSINFO Welke teams handelden de Request af? Welke activiteiten zie je terugkeren en in welke volgorde? Waren er afhankelijkheden tussen de activiteiten? (Eerst X alvorens Y kan starten) TIMING Hoelang schat je op basis van de info in de tickets dat het uitvoeren van een Request kan duren. (exclusief de tijd dat er gewacht wordt op de gebruiker, dus puur het uitvoeren van de Request als alle info beschikbaar is) APPROVAL Werd er om approval gevraagd alvorens de Request uitgevoerd werd en aan wie? (gewoonlijk BUM) ONDERSTEUNENDE MIDDELEN Werden er middelen gebruikt bij het uitvoeren van de Request? Welke? Procedures? Indien niet, welke middelen zou je verwachten om de Requests uit te kunnen voeren. BESCHRIJVENDE INFO Wat houdt de activiteit precies in? Waarom is de activiteit nodig? Wie voert de activiteit uit? Hoe wordt de activiteit utigevoerd? Page 10 / 14

56 Stagerapport: Activiteitenverslag HUIDIGE UITVOERDER Wie voert de activiteit momenteel uit? Probeer per activiteit een persoon te vinden die je aanvullende info kan bezorgen over de activiteit / Request Deze informatie dient als uitgangspunt voor de sjablonen op te stellen voor de uitvoering van Request Fulfillment. Deze sjablonen gaan volgende week worden opgesteld. Het is de bedoeling dat deze sjablonen worden gebruikt door de Service Desk van Ordina voor het afhandelen van Requests. Page 11 / 14

57 Stagerapport: Activiteitenverslag Week 11 Maandag 31 mei De meeting voorbereiden van de namiddag. Voorbeeldmail opstellen en analyse top 10 Requests gebaseerd op ticket info verder aanvullen in Excel. Meeting met mijn stagementor. Tijdens deze meeting hebben we volgende zaken besproken en uitgevoerd: Een mail opgesteld om aanvullende informatie te vragen aan Ordina medewerkers die bepaalde Requests uitvoeren. Deze aanvullende informatie wordt opgenomen in mijn analyse. Deze informatie zal op zijn beurt verschijnen in de change templates in TOPdesk. We hebben samen 1 sjabloon aangemaakt in TOPdesk zodat ik een voorbeeld heb voor het verder aanmaken van sjablonen in TOPdesk. Er is afgesproken dat ik een werkinstructie How To Create A Change Template In TOPdesk ga maken, zodat andere medewerkers dit ook kunnen na het lezen van deze werkinstructie. We hebben ook enkele naamconventies afgesproken voor het schrijven van een werkinstructie. Problemen: / Dinsdag 01 juni De aanvullende informatie die ik verkregen heb door mijn mails van maandag verwerkt in mijn Request FulFillment Analyse. De werkinstructie How To Create A Change Template In TOPdesk opstellen. Een werkinstructie beschrijft een aantal handelingen die de gebruiker stapsgewijs moet uitvoeren zoals in de werkinstructie. Problemen: TOPdesk staat in het Nederlands. De screenshots voor mijn werkinstructie moesten in het Engels zijn. Dit probleem heb ik gemeld aan mijn stagementor die mij dan heeft uitgelegd hoe ik de taal van TOPdesk kon wijzigen naar het Engels. Woensdag 02 juni Begin aanmaken Change Templates in TOPdesk voor de top 10 Requests die in mijn analyse terug te vinden zijn. Problemen: Aanvullende informatie verreist voor het aanmaken van de Change Templates in TOPdesk. Opgelost door extra mails te versturen naar medewerkers met de vraag om aanvullende informatie + een meeting voorzien met de Service Desk van Ordina in Mechelen waardoor ik aanvullende informatie zou moeten bekomen. Page 12 / 14

58 Stagerapport: Activiteitenverslag Donderdag 03 Juni(Mechelen) Werken aan stagerapport + implementatie top 10 sjablonen. Deze dag in het kantoor in Mechelen doorgebracht om nog wat aanvullende informatie te verkrijgen via de Service Desk. Kijken naar de activiteiten die Service Desk medewerkers uitvoeren bij het afhandelen van Requests en deze opnemen in de Templates. Problemen: / Vrijdag 04 Juni Wekelijkse meeting met stagementor: review uitwerkingen afgelopen week. Namiddag een meeting met Internal IT. In deze meeting concreet ingaan op het implementatietraject; planning, resources en deliverables van het Request Fulfillment project. Problemen: / Week 12 Maandag 07 juni Uitwerken Change Templates in TOPdesk en verder werken stagerapport. Deze Change Templates dienen voor het standaardiseren van de afhandeling van een aantal Requets. Hierdoor zal de Service desk Request op een consistente manier afhandelen. Als er bijvoorbeeld een nieuwe medewerker komt kan hij direct aan de slag met deze sjablonen omdat daar alle activiteiten + werkinstructies in staan voor het afhandelen van een bepaald Request. Problemen: / Dinsdag 8 juni Idem Maandag Woensdag 9 juni(mechelen) Agenda presentatie stage verdediging maken in PowerPoint. Meeting met de Service Desk waar we iets dieper inzoomen op de praktische kant van het proces: Opzet van de Request Catalog Praktische afhandeling van Requests: High-level process flow Uitwerking en optimalisering van Request Templates in TOPdesk Uitleg rond Request Ownership Jullie vragen en opmerkingen Problemen: / Page 13 / 14

59 Stagerapport: Activiteitenverslag Donderdag 10 en 11 juni Deze laatste 2 dage zijn volledig aan het stagerapport gespendeerd. Vrijdagvoormiddag heb ik mijn abstract ook geschreven en voorgelegd aan mijn stagementor. We hebben dit samen besproken en vrijdagnamiddag heb ik dit abstract verder afgewerkt. Vrijdagvoormiddag hebben we ook de opzet van mijn stagerapport besproken en nog enkele afspraken gemaakt voor de komende weken om dit rapport eens voor te leggen en een dry run van mijn presentatie van de stagverdediging te doen voor de ITSM Lead Consultants van Ordina Page 14 / 14

60

61 Jasper Vandegaer Account Manager Details Intellectual Property Rights and Copyright Statement Copyright ORDINA Belgium, All Rights Reserved. Ordina Belgium NV Blarenberglaan 3B B-2800 Mechelen

62 Inhoud 1. Inleiding Objectieven Opzet Incident Management Procesevaluatie Incident Registration Beschrijving Case Resultaat Incident Categorization Beschrijving Case Resultaat Incident Prioritization Beschrijving Case Resultaat Incident diagnosis Beschrijving Case Resultaat Incident Escalation Beschrijving Case Resultaat Incident communication Beschrijving Case Resultaat Conclusie Bijkomende informatie Bronnen Page 2 / 14

63 1. Inleiding Dit rapport gaat over de procesuitvoering Incident Management binnen Ordina. Dit is een proces dat omschreven staat in ITIL 1. ITIL beschrijft een standaardaanpak voor effectieve en efficiënte levering van IT-services. Het is ontstaan uit een verzameling best practices die in het werkveld van de IT-dienstverlening werden aangetroffen. ITIL biedt een systematische aanpak voor het leveren van gewenste kwaliteit van ITservices. Sinds het verschijnen van ITIL V2 zijn de rol en organisatie van de informatievoorziening gegroeid en veranderd. IT ondersteunt en maakt deel uit van een toenemend aantal goederen en diensten. Ook in het bedrijfsleven is de rol van de informatievoorziening veranderd: IT heeft niet langer slechts een ondersteunende rol, maar is de basis geworden voor het creëren van bedrijfswaarde. ITIL V3 wil de nieuwe rol van IT in al zijn complexiteit en dynamiek omvatten en inzichtelijk maken. Daarvoor is een nieuwe benadering van servicemanagement gekozen, waarin niet de processen centraal staan, maar wel de levenscyclus van een service. ITIL definieert een service als volgt: Een Service is een manier om waarde te leveren door een klant te helpen bij de gewenste eindresultaten te bereiken, zonder dat deze aansprakelijk is voor specifieke kosten of risico s. Services ondersteunen de uitvoering van taken(of voeren de taak zelf uit) en reduceren de druk van beperkingen. Hierdoor effenen ze de weg voor de eindresultaten die de klant wenst. De verschillende fasen in het leven van een IT-service zijn beschreven in de levenscyclus. De levenscyclus bestaat uit vijf fasen. Incident management is een proces binnen de fase Serviceproductie. Serviceproductie is de fase van het bereiken van effectiviteit en efficiëntie in de levering en ondersteuning van services, om waarde/kwaliteit te garanderen aan de klant en de serviceprovider. Vanaf ITIL V3 onderscheid men volgende Service productieprocessen: Event Management Incident Management Request fulfilment Problem Management Acces Management Monitoren en beheersen IT productie Levenscyclus 1 Information Technology Infrastructure Library, een referentiekader voor het inrichten van beheersprocessen binnen een ICT-organisatie. Page 3 / 14

64 Deze belangrijke service productieprocessen dienen op elkaar afgestemd te worden om een effectieve IT-supportstructuur te beiden. De Service Desk is de uitvoerende kracht van het proces Incident Management. Het is een erg belangrijk onderdeel in de IT-afdeling van een organisatie. Zij moeten het enige aanspreekpunt zijn voor IT gebruikers en alle incidenten en service requests afhandelen. 2. Objectieven De bedoeling van dit adviesrapport is de bestaande afhandeling van calls in kaart te brengen om vervolgens tot adviezen te komen voor de verbetering van de procesuitvoering Incident Management en zo voor gerichte coaching te zorgen door de servicedesk coördinator te ondersteunen. Vele organisaties beschouwen een Service Desk als het beste middel voor eerstelijnssupport. Door verbetering van de procesuitvoering incidentmanagement levert de Service Desk de volgende voordelen op: Een verbeterde klantenservice, betere klantperceptie van de service en hogere klanttevredenheid Klant- en gebruikersverzoeken worden beter en sneller opgelost De samenwerking en communicatie verbeterd Een verbeterde focus en een proactieve benadering van dienstverlening Minder negatieve impact op de business Een beter beheerde infrastructuur en beheersing Een beter gebruik van resources voor IT-support en toegenomen productiviteit van bedrijfsmedewerkers Zinvollere managementinformatie voor beslissingen over support Page 4 / 14

65 3. Opzet Dit document is een adviesrapport voor de verbetering van de procesuitvoering incident Management binnen Ordina. Het rapport is gebaseerd op de evaluatie van de operationele uitvoering in functie van het voorgeschreven proces. Er zijn voor dit rapport 50 willekeurige calls geëvalueerd. Dit zijn allemaal calls die aangemeld zijn in het jaar 2010 omdat men in 2009 nog bezig was met het Incident Managementproces te implementeren. Er is gebruik gemaakt van de service desk tool Topdesk en het incident dashboard van Ordina. Uit de evaluatie van deze calls zijn de conclusies en adviezen opgemaakt die in dit rapport zijn terug te vinden. Voor het process Incident Management zijn volgende activiteiten geëvalueerd: - Incident Registration; - Incident Categorization; - Incident Prioritization; - Incident Diagnoses; - Incident Escalation; - Incident Communication. Voor de evaluatie van elke call per activiteit is onderstaande beoordeling gehanteerd. Er wordt ook telkens 1 case per activiteit uitgelegd waarbij het proces beter zou kunnen worden uitgevoerd. Beoordeling Kleurcode Goed Gemiddeld Slecht Beschrijving Procesactiviteit werd goed uitgevoerd Gebrekkige uitvoering zonder impact op de klanttevredenheid Gebrekkige uitvoering met impact op de klanttevredenheid Aan de hand van bovenstaande beoordelingsgrafiek zijn de taartdiagrammen per activiteit opgesteld. Deze taartdiagrammen geven een procentuele voorstelling van het totaal aantal calls per activiteit die goed, gemiddeld en slecht werden uitgevoerd. Hierdoor krijg je dus een algemeen overzicht van de uitvoering van elke activiteit(=het resultaat) % % % Goed Gemiddeld Slecht Page 5 / 14

66 Incident Managementproces 4. Incident Management Incident Management is een Service Productieproces. Het Incident Managementproces concentreert zich op het zo snel mogelijk herstellen van verstoorde services voorgebruikers, zodat de invloed op de business minimaal is. Incidenten kunnen storingen of vragen zijn. Incident Management omvat ieder event dat een service verstoort of kan verstoren. Dit zijn dus ook events die direct door gebruikers worden gemeld, hetzij door de Service Desk of via verschillende tools. Het Incident Managementproces bestaat uit de volgende activiteiten: REGISTRATION Registratie van de beschrijvende informatie en permanente onderhoud van het Incident Record gedurende de hele incident levenscyclus. Klare en up to date registrate is cruciaal voor het opvolgen van 2nd level support teams en monitoring/reporting. 2 CATEGORIZATION Categorizatie van incidenten gebaseerd op informatie verstrekt door de eindgebruiker en hoofdoorzaak van het incident Juiste categorizatie is cruciaal voor het verdere onderzoek in Problem Mangement DIAGNOSIS De initiële diagnose en het oplossen van het probleem(<15). Mogelijke oorzaken zijn systematisch gecontrolleerd om escalatie te vermijden Diagnose en het oplossen van het probleem is gebaseerd op informatie uit het kennissysteem. PRIORITIZATION Prioriteit drukt de relatieve belangrijkheid van het incident uit en is gebaseerd op de impact en urgentie criteria zoals beschreven in de SLA. De oplostijd van dit incident is bepaald door de mensen en de tijd waarop het incident betrekking heeft. ESCALATION Functionele escalatie naar de passende 2de lijns support group Hierarchische escalacatie volgens voorgafgedefineerde procedures DIAGNOSIS & RESOLUTION De werkelijke oplossing van het incident door 2nd level support gebruiker met documentatie over de oplossing in het incident record binnen Topdesk CLOSURE Afsluiting van het incident, nadat eindgebruiker de succesvolle oplossing accepteerd Evaluatie van de categorizatie en verandering van categorie indien nodig Escalatie naar het geschikte support team in plaats van weigering van de eindgebruikeroplossing 2 Procesdocumentatie Competence Centre ITSM Ordina Page 6 / 14

67 Dit zijn de activiteiten die de servicedesk moet uitvoeren gedurende de levenscyclus van het incident. De activiteiten die 1 st line Support zal uitvoeren: Het incident loggen(een ticket in TOPdesk aanmaken) Een diagnose stellen om de mogelijke oorzaak te achterhalen Het incident escaleren naar het 2nd line support team, indien het de oorzaak niet vindt 2 nd line Support gaat dan: Het Incident oplossen (Nieuw moederbord plaatsen in dit voorbeeld) De oplossing documenteren in het ticket(oplossing en oorzaak in de ticket-info noteren) Vervolgens het ticket terug doorsturen naar het eerste lijns team 1 st line Support: De oplossing evalueren Accepteren, als het een correcte oplossing is(in dit geval: als de computer terug werkt) Het incident afsluiten(de computer aan gebruiker bezorgen) 5. Procesevaluatie De operationele uitvoering van de volgende activeiten in functie van het voorgeschreven proces worden in dit hoofdstuk geëvalueerd. Incident Registration Incident Categorization Incident Prioritization Incident Diagnoses Incident Escalation Incident Communication. Page 7 / 14

68 5.1. Incident Registration Beschrijving Incident Registration heeft betrekking op de registratie en het onderhoud van een incident record doorheen de incident levenscyclus. Duidelijk omschreven en up to date incident registratie is cruciaal voor latere onderzoeken en rapportering van incidenten. Alle relevante informatie die te maken heeft met de aard van het incident, zodat er een volledig historisch record is dient geregistreerd te worden. Als het incident aan andere supportgroepen wordt overgedragen hebben zij alle relevante informatie ter beschikking Case Onderstaand screenshot toont een voorbeeld van een incorrect geregistreerde call. Dit kreeg bijgevolg een beoordeling van gemiddeld op de uitvoering van deze procesactiviteit. Zoals aangeduid met de pijlen moet voor een betere registratie de soort binnenkomst en het telefoonnummer worden ingevuld. De omschrijving netwerkproblemen is ook te vaag, dit had in dit geval beter kunnen omschreven worden als kan niet met het netwerk verbinden, wat representatiever is Resultaat Voor de registratie van incidents valt algemeen weinig aan te merken, dit verloopt meestal correct(84%). Verbeterpunten voor registratie: - Een meer gedetailleerde omschrijving van het incident (zie case hierboven) - Soort aanmelding(requests vaak als incidents en omgekeerd beoordeeld) 16% 84% Goed Gemiddeld Page 8 / 14

69 5.2. Incident Categorization Beschrijving Voor gedetailleerde en representatieve rapportage en categorisatie van het incident in functie van de onderliggende oorzaak. Bij de registratie van een incident kunnen de beschikbare gegevens soms onvolledig, misleidend of onjuist zijn. Het is daarom belangrijk dat de categorisatie van het incident wordt gecontroleerd en bijgewerkt tijdens het afsluiten van een call Case Onderstaande afbeelding toont een voorbeeld van een verkeerd gecategoriseerd incident. Incident categorisatie gebaseerd op de onderliggende oorzaak is noodzakelijk. Zoals uit de afbeelding af te leiden, is dit incident onder Ordina Application CV tool gecategoriseerd. Uit een mail van de gebruiker blijkt echter dat het om een login probleem gaat, meer bepaald een error i.v.m. autorisatie. Bijgevolg zou dit dus onder Account Authorization moeten gecategoriseerd zijn. De onderliggende oorzaak is dus een autorisatie probleem. De huidige categorisatie duidt op een functioneel probleem met de CV tool. Dit geeft een vertekend beeld Resultaat Regelmatig(20%) worden de incidents verkeerd gecategoriseerd. Zo worden bijvoorbeeld nog steeds te veel requests voor rechten of autorisatie( hoort bij de categorie account ) onder de subcategorie van de applicatie zelf gecategoriseerd wat een vertekend beeld geeft. Het is dus zeer belangrijk de incidents te categoriseren aan de hand van de ondeliggende oorzaak. 20% 80% Goed Gemiddeld Page 9 / 14

70 5.3. Incident Prioritization Beschrijving Een belangrijk aspect van het registreren van ieder incident is het toekennen van een juiste prioriteit. Aan de hand van de prioriteit bepalen de supportmedewerkers en tools namelijk hoe ze het incident afhandelen. De prioriteit van een incident kan normaal worden vastgesteld door de urgentie van het incident(hoe snel de business een oplossing nodig heeft) en de impact ervan vast te stellen. Een aanwijzing voor de impact is meestal het aantal gebruikers dat door een incident wordt getroffen Case Onderstaand probleem doet zich bij de meerderheid van de calls voor. Het veld urgentie is niet ingevuld. Het gevolg hiervan is dat er geen prioriteit wordt gegenereerd en er bijgevolg niet geweten is hoe snel de business een oplossing nodig heeft Resultaat Bijna alle calls(92%) hebben een beoordeling van gemiddeld gekregen voor de uitvoering van de activiteit Incident Prioriteren. Dit is het gevolg van de urgentie die zelfden of nooit was ingevuld. Dit komt dan weer verder door het ontbreken van interne SLA s zijn voor Ordina calls. Als deze er wel zijn dan kunnen calls die aandacht vereisen omwille van impact en urgentie ook voorrang krijgen. 92% 8% Goed Gemiddeld Page 10 / 14

71 5.4. Incident Diagnosis Beschrijving Als een gebruiker een incident via de servicedesk aanmeldt, moet de servicedesk medewerker een eerste diagnose proberen te stellen om zoveel mogelijk symptomen van het incident vast te leggen. Ook probeert hij vast te stellen wat er verkeerd is gegaan en hoe dat opgelost moet worden. Bij het afhandelen van een incident onderzoekt iedere oplosgroep wat er verkeerd is gegaan. Ook stelt zij een diagnose. Al deze activiteiten dienen volledig gedocumenteerd te worden in het incidentrecord, zodat er een compleet overzicht is van alle uitgevoerde acties Case De gebruiker had een probleem met zijn profiel op zijn laptop. Hoogstwaarschijnlijk is er een nieuwe call ingelegd voor een nieuwe laptop voor de gebruiker. Wat men echter vergeten is op de service desk is te noteren dat de eerste call gesloten mocht worden waardoor er overbodige communicatie ontstaan is. Er moest dus genoteerd worden dan er een nieuwe call was ingelegd en dat de eerste gesloten mocht worden Resultaat Uit de globale evaluatie blijkt dat deze activiteit wel meerdere 12% keren slecht wordt uitgevoerd waardoor er misverstanden ontstonden en overbodige communicatie moest ondernomen worden wat resulteert in het verlies van kostbare tijd. 18% Elke persoon op de servicedesk dient netjes te registreren welke 70% acties hij/zij heeft uitgevoerd. Wanneer bijvoorbeeld een klant is langs geweest op de service desk wordt al eens vaak vergeten dit te noteren waardoor de volgende dag andere personen dit niet weten. Bij 12% van de geëvalueerde calls waarbij de activiteit een beoordeling slecht heeft was dit telkens het geval. Verder dient men ook aan te geven hoe het probleem is opgelost, want nu zegt men vaak dat het incident is opgelost zonder in detail aan te geven wat het probleem was en hoe het is opgelost. Goed Gemiddeld Slecht Page 11 / 14

72 5.5. Incident Escalation Beschrijving Indien het 1 ste lijns support team het incident niet direct kan oplossen moet het incident geëscaleerd worden. Hier gaat het vooral om het toewijzen van de call aan het juiste oplossende 2 de lijns team Case Dit voorbeeld toont het Pingpong effect aan. Dit wil zeggen dat de call meerdere keren heen en weer geëscaleerd wordt tussen de service desk en Internal IT applications wat voor een hoge doorlooptijd van het incident zorgt. Dit is vaak het gevolg van een slechte diagnose van het incident waardoor er bijkomende vragen gesteld moeten worden tussen de support teams Resultaat Het escaleren verloopt vrijwel telkens goed. Bij 98% van de calls was dit het geval. Eén maal is het bekende escalatieprobleem het Pingpong effect terug te vinden door ontbrekende informatie(diagnose). Dit benadrukt wederom de belangrijkheid van een goede diagnose. 2% 98% Goed Slecht Page 12 / 14

73 5.6. Incident Communication Beschrijving Incident Communication is geen expliciete procesactiviteit maar een aspect dat continue aandacht vereist. Het gaat hier over de communicatiemomenten die de servicedesk heeft ondernomen, en in het bijzonder de communicatie naar de eindgebruiker toe. De klant moet voldoende geïnformeerd worden gedurende de hele afhandeling van het incident. De communicatiemomenten moeten voldoende zijn, rekening houdend met de doorlooptijd. Een incident kan pas gesloten worden wanneer de eindgebruiker de oplossing van het incident aangeboden door de service desk bevestigd en accepteert Case In dit voorbeeld is een incident telefonisch aangemeld. Het incident dient dan gelogd te worden, wat hier niet gebeurd is. Zolang een call niet rechtstreeks via de Topdesk tool(web interface) binnenkomt, moet incident logging worden uitgevoerd. Het is belangrijk dat dit gebeurd zodat de gebruiker weet dat de service desk naar een oplossing zal zoeken Resultaat 10% Bij maar 54% van de calls was de communicatie perfect verlopen. Incident logging wordt nog vaak vergeten alsook Goed incident user feedback follow-up. Bij bijna alle calls die telefonisch 34% Gemiddeld zijn aangemeld is er geen enkele aantekening terug te vinden. Dit dient 56% Slecht te gebeuren zodat men kan meten of de user al dan niet tevreden was met de aangeboden oplossing. Status updates moet ook meer gedaan worden, want de gebruiker neemt hiervoor nu regelmatig zelf contact op met de service desk. Page 13 / 14

74 6. Conclusie De incidenten worden meestal goed geregistreerd. Het is vaak aangewezen een gedetailleerdere omschrijving van het Incident. De categorisatie dient meer op basis van de onderliggende oorzaak te gebeuren. Uit de evaluatie van de activiteiten blijkt dat vooral de activiteit Incident Diagnoses beter moet worden uitgevoerd om de vooropgestelde objectieven te bereiken. Zoals eerder vermeld dient elke stap in het Incident Record te worden opgenomen. Elke persoon die met deze activiteit te maken krijgt moet zich hiervan bewust zijn. De escalatie verloopt vrijwel altijd correct. De communicatie naar de gebruiker kan nog wat beter. Zo dient het incident meer gelogd te worden(bij telefonische aanmelding en binnenkomst per mail ) en zou men meer gebruik moeten maken van status updates om de gebruiker op de hoogte te houden zodat deze zelf geen contact dient op te nemen wat tot overbodige communicatie leidt. 7. Bijkomende informatie De individuele evaluatie per call is terug te vinden in het document adviesrapport.xls. 8. Bronnen - Foundations of IT Servicemangement op basis van ITIL V3. Zaltbommel, Van Haren Publishing, 2009, p Procesdocumentatie Innovative Technology Solutions and Services (CC), ITSM Ordina Belgium - Service Operation op basis van ITIL V3 Een mangementguide. Zaltbommel, Van Haren Publishing, 2009, 186. Page 14 / 14

75

76 Jasper Vandegaer Account Manager Details Intellectual Property Rights and Copyright Statement Copyright ORDINA Belgium, All Rights Reserved. Ordina Belgium NV Blarenberglaan 3B B-2800 Mechelen

77 Inhoud 1. Inleiding Problem Management Objectieven Opzet Top Overzicht EvoBizz account locked Beschrijving Preventieve maatregel Adapter laptop stuk Beschrijving Preventieve maatregel VPN connectie onmogelijk Beschrijving Preventieve maatregel Taalproblemen CV tool Beschrijving Preventieve maatregel Intranet down Beschrijving Preventieve maatregel Badge vervallen Beschrijving Preventieve maatregel Exportissue cv tool probleem Beschrijving Password reset account Beschrijving Preventieve maatregel Uren/verlofdagen boeken probleem EvoBizz Beschrijving Preventieve maatregel Reportingservices EvoBizz probleem Beschrijving Preventieve maatregel Conclusie Bijkomende informatie Bronnen Page 2 / 12

78 1. Inleiding ITIL benadert servicemanagement vanuit de servicelevenscyclusrdelen van het systeem en op s. De servicelenvescyclus is een organisatiemodel dat inzicht biedt in: De wijze waarop servicemanagement gestructureerd is De wijze waarop de verschillende componenten met elkaar samenhangen Welke impact veranderingen in één onderdeel hebben op andere onderdelen van het systeem en op het gehele systeem. ITIL definieert een service als volgt: Een Service is een manier om waarde te leveren door een klant te helpen bij de gewenste eindresultaten te bereiken, zonder dat deze aansprakelijk is voor specifieke kosten of risico s. Services ondersteunen de uitvoering van taken(of voeren de taak zelf uit) en reduceren de druk van beperkingen. Hierdoor effenen ze de weg voor de eindresultaten die de klant wenst. De ITIL service-levenscyclus bestaat uit zes fasen. Eén fase is de service productiefase. Deze fase bevat een aantal processen, waaronder: problem management. Serviceproductie is de fase van het bereiken van effectiviteit en efficiëntie in de levering en ondersteuning van services, om waarde/kwaliteit te garanderen aan de klant en de serviceprovider. Vanaf ITIL V3 onderscheid men volgende Service productieprocessen: Event Management Incident Management Request fulfilment Problem Management Acces Management Monitoren en beheersen IT productie Levenscyclus Page 3 / 12

79 2. Problem Management ITIL definieert een problem als volgt: Een problem is de onbekende oorzaak van één of meer incidenten. Problem management is verantwoordelijk voor het beheren van de levenscyclus van alle problems. Het omvat alle activiteiten die nodig zijn om een diagnose te stellen van de onderliggende oorzaak van incidenten en om een oplossing te vinden voor die problems. De hoofdactiviteiten van Problem Management zijn: - Problem control: Het onderzoeken van het probleem - Error control: het bewaken van known errors - Procatief beheer: het voorkomen van problemen - Trendanalyse: het vroegtijdig opsporen van mogelijke fouten - Rapportage: het verschaffen van informatie Informatiestromen uit andere processen Analyse Problem control Identificatie & registratie Clasificatie en allocatie Voortgang bewaken Onderzoek en diagnose Error identificatie en registratie Onderzoek naar oplossing Problems Vastleggen van de gekozen oplossing Change mangement Evaluatie/ review probleem Afsluiten probleem Error control! Dit is niet als proces uitgewerkt binnen Ordina, maar wordt als activiteit uitgevoerd. Page 4 / 12

80 Problem Management werkt samen met Incident Management en Change Management om ervoor te zorgen dat de beschikbaarheid en kwaliteit van IT-dienstverlening toeneemt. Het Incident Management en het Problem Managementproces hebben een verschillend belang. Het Incident proces heeft er belang bij de dienstverlening zo snel mogelijk te herstellen. Problem Management heeft er belang bij de oorzaak te achterhalen, en vervolgens het probleem op te lossen en te voorkomen. Deze doelstellingen hebben vaak een tegengestelde prioriteit. Er zijn veel problemanalyse-,diagnose- en oplossingstechnieken beschikbaar, zoals: Chronische analyse Pain Value Analyse Kepner en Tregoe Brainstormen Ishikawa-diagrammen Parette-analyse Dit rapport is gebaseerd op een chronische problem management analyse. 3. Objectieven De primaire doelstelling van onze Problem Management analyse is het voorkomen van problems en incidenten, het elimineren van herhalende incidenten en het minimaliseren van de impact van incidenten die niet voorkomen kunnen worden. Waarom Problem Management? Het identificeren van problemen Om snel en doeltreffend problemen op te lossen. Om proactief problemen en bekende fouten te herkennen en op te lossen met als resultaat dat er minder incidenten voorkomen. Om de productiviteit van de support afdeling te verhogen. Om te voorzien in relevante management informatie. Enkele voordelen van problem management voor de business: Verbeterde ICT dienstverlening Afname van de hoeveelheid incidenten Definitieve oplossingen Page 5 / 12

81 4. Opzet De analyse voorafgaand aan dit rapport is het uitgangspunt om 10 mogelijke problems te vinden. In deze analyse zijn alle interne Ordina calls van 1 januari 2010 tot 15 april 2010 geëvalueerd. De analyse is enkele stappen gebeurd: Stap 1: De calls herindelen op een correcte aanmelding en categorisatie (identificatie review) Stap 2: De incidenten van de Requests scheiden (herindeling) Stap 3: De categorieën analyseren waarin het meest aantal incidenten zijn terug te vinden (top categorieën) Stap 4: De subcategorieën met het meest aantal incidenten isoleren(top sub categorieën) Stap 5: De incidenten evalueren op trends in de top subcategorieën (top 10 terugkerende incidenten) Door stap 1 en 2 uit te voeren zijn we tot onderstaande verdeling gekomen: Door de soort aanmelding te verbeteren zijn we van 819 incidenten naar 793 gegaan. Indien dit niet was gebeurt, hadden we een vertekend beeld gekregen. Page 6 / 12