Groei in organisaties: De relatie met incident- en changemanagement volgens CMM en ITIL

Transcriptie

1 Groei in organisaties: De relatie met incident- en changemanagement volgens CMM en ITIL Hessel Mooiman Amsterdam, 2008 EDP Audit opleiding Vrije Universiteit Amsterdam Studiebegeleider: Bedrijfscoach: B. Van Staveren B. Van Meegeren

2 Voorwoord Deze scriptie is geschreven als eindopdracht in het 3 e jaar voor de studie EDPauditing aan de Vrije Universiteit. Deze scriptie is een toets voor de opgedane kennis in het werkveld EDP-auditing en reflectie van zowel de opgedane kennis aan de opleiding als de kennis opgedaan in de dagelijkse praktijk die ik als IT auditor. Uit de werkervaring die ik heb opgedaan bij verschillende banken als security officer en IT Auditor is het mij opgevallen dat het implementeren van ITIL soms op grote moeilijkheden en weerstand in de organisatie stuit. Zeker organisaties in de beginfase van hun bestaan hebben grote moeite met het juist inschalen van ITIL op de grootte en behoeften van hun bedrijf en zijn bang dat ITIL een te grote bureaucratie met zich meeneemt. Het is mij vaker opgevallen dat ITIL grootschalig en precies zoals voorgeschreven in de ITIL handleidingen werd geïmplementeerd. Meer dan eens heb ik daardoor een ITIL implementatie zien falen. Mijn stellige overtuiging is altijd geweest dat ITIL een uitstekende best-practice is voor grote ICT organisaties met grote twijfels over de schaalbaarheid naar kleinere organisaties. Daarnaast rees de vraag of ITIL na implementatie groeibestendig is. In bedrijven hoort men vaker de reactie vroeger werkte het toch ook zo, en dat ging altijd goed, vergetend dat de organisatie is gegroeid, andere of meerdere belangen zijn ontstaan en de aansturing veranderd is. Als eerste wil ik mijn vrouw en mijn dochtertje (14 maanden) bedanken die mij vele avonden hebben moeten missen omdat ik boven aan het werk was om deze scriptie te kunnen afronden. Daarnaast wil ik mijn begeleiders, Bart van Staveren en Bas van Meegeren, bedanken voor de hulp die zij hebben geleverd bij het maken van deze scriptie

3 Inhoudsopgave 1.0 Inleiding Probleemstelling Doelstelling De invloed van groei op de ICT organisatie Groei van organisaties Groei van organisaties volgens het model van Greiner Fasen in de ICT volgens Boonstra Groei ICT Complexiteit en risico ICT Complexiteit en risico Organisatie complexiteit en ICT Verminderen risico s ICT ITIL Changemanagement Incidentmanagement ITIL implementaties in relatie tot de grootte van de organisatie CobiT Maturity Model Maturity, voorspelbaarheid, complexiteit en risico Maturity en business alignment Veranderingen in maturity level bij groei organisatie Bestendigheid incident en changemanagement proces Bepalen maturity van Incident en changemanagement Casus Bank X Inleiding Casus Bank X Doel Casus Bank X Werkwijze Groeifase Bank X Maturity en controls Werking Incident en changemanagement bij Bank X Conclusie Bank X Eindconclusie en reflectie Conclusie Reflectie Bijlage I Referenties Bijlage II Controls in relatie tot groeifase en maturity Bijlage III Cobit Maturity Levels Bijlage IV Casus Bank X Controls Bijlage V Maturity Levels Bank X

4 1.0 Inleiding Een vast gegeven is dat grote organisaties als kleine organisaties zijn begonnen. Organisaties groeien. Tijdens de groei van een organisatie worden nieuwe producten ontwikkeld en geïntroduceerd aan de klant. Nieuwe ondersteunende bedrijfsprocessen ontstaan of bestaande breiden uit. Deze ontwikkelingen gaan niet voorbij aan de ICT organisatie. Van de ICT organisatie wordt verwacht dat zij de business ondersteunt en de groei faciliteert. Nieuwe producten betekenen wijzigingen op de ICT voorzieningen. Niet alleen volgens Gartner is één van de grootste factoren die de business kunnen verstoren het mislukken van wijzigingen en daarmee gepaard gaande verstoringen op de ICT. Voor ICT afdelingen is het van belang om wijzigingen gecontroleerd door te voeren met een minimaal aantal verstoringen. Een veel gebruikte proces methodiek voor het doorvoeren van wijzigingen en oplossen van incidenten is ITIL. ITIL is alleen vaker beschuldigd van het feit dat deze vooral is gericht op grote rekencentra en te uitgebreid is voor kleinere organisaties. Toch wordt ITIL veel gebruikt, met aanpassingen, in kleinere organisaties. Impliciet betekent dit voor een groeiende organisatie dat zij uiteindelijk met ITIL implementatie zit die geschikt is voor een kleine organisatie terwijl zij zelf in grootte is toegenomen. Aan de hand van het CobiT Maturity Model wordt gekeken wat de effecten van groei op een ITIL implementatie zijn. 1.1 Probleemstelling Naar aanleiding van bovenstaande schets kunnen de volgende vragen worden gesteld: Ligt er een relatie tussen de grootte van een organisatie en de eisen van ITIl changemanagement en incident management. Welke invloed heeft groei van de organisatie op het maturity level, volgens CobiT, van de processen incident en changemanagement. 1.2 Doelstelling Het doel van deze scriptie is te bepalen of een relatie bestaat tussen de groei van de ICT organisatie en de business en de volwassenheid van de ITIL processen Incident en Change management volgens het COBIT Maturity Model. Naast het onderzoeken van de relaties zal een model worden uitgewerkt waarmee op een eenvoudige wijze een scan op de organisatie kan worden uitgevoerd welke is gebaseerd op het kwantificeren van controls binnen het CobiT Maturity Model

5 2.0 De invloed van groei op de ICT organisatie 2.1 Groei van organisaties Grote bedrijven zijn ooit als kleine bedrijven begonnen. Grote bedrijven kenmerken zich door een complexe organisatie met zeer veel afdelingen en organen en leveren over het algemeen een groot aantal diensten of producten. Kleine bedrijven zijn eenvoudiger van aard, ondersteunen een weinig aantal producten of diensten waarbij de organisatie relatief eenvoudig is. Middelgrote bedrijven vallen qua complexiteit van ICT en organisatie ergens tussenin en bevatten elementen van zowel kleine als grote organisaties. Deze scriptie is beperkt tot de groei van kleine, eenvoudige bedrijven naar middelgrote bedrijven met een complexere bedrijfsstructuur. Gedurende de groei van een bedrijf verandert de structuur en complexiteit van een bedrijf aanzienlijk. Nieuwe producten worden door het bedrijf geleverd, het aantal personeel en afdelingen neemt toe. Deze veranderingen binnen het bedrijf laat de ICT organisatie niet ongemoeid en krijgt in grote mate te maken met deze veranderingen. Binnen bedrijven heeft de ICT tegenwoordig niet meer alleen meer een ondersteunende rol. Primaire bedrijfsprocessen zijn tegenwoordig afhankelijk van de ICT dienstverlening. Dit geldt zeker voor die bedrijven waarbij diensten voornamelijk digitaal van aard zijn. 2.2 Groei van organisaties volgens het model van Greiner De groei van een bedrijf gaat niet altijd geleidelijk en gaat gepaard met horten en stoten. Greiner [1] beschrijft een groeimodel voor organisaties waarin hij stabiele perioden van groei afwisselt met perioden van rumoer en turbulentie, zie figuur 1. Greiner beschrijft weliswaar niet specifiek de groei van een ICT organisatie, maar het groeimodel kan wel worden gespiegeld aan de ICT organisatie. Greiner onderscheidt in zijn model vijf fasen die een bedrijf meemaakt. Elke fase wordt gestart met een rustige stabiele periode waarin de groei van het bedrijf stabiel is en geen problemen geeft. Het bedrijf is in staat met de huidige inrichting de groei te verwerken. Deze rustige periode wordt de evolutie genoemd. Uiteindelijk zal het bedrijf in zijn huidige structuur de grenzen van zijn groei tegenkomen. Verandering binnen het bedrijf is noodzakelijk om door te kunnen groeien. Een periode van rumoer en turbulentie wordt ingeluid. Deze rumoerige periode wordt als de revolutie gekenmerkt. De snelheid va opeenvolging van deze fasen is afhankelijk van de snelheid van de groei. Hoe sneller het bedrijf groeit, hoe sneller de fasen opeenvolgen. In deze scriptie behandel ik de groei van kleine tot middelgrote organisaties, daarom volsta ik met het bespreken van de eerste drie fasen van het model van Greiner. De overige fasen, 4 coördinatie en 5 samenwerking, zijn van toepassing op grotere bedrijven en worden derhalve in deze scriptie niet behandeld

6 Fase 1: Creativiteit De eerste fase wordt door Greiner de fase van de creativiteit genoemd. In deze fase is het bedrijf net gestart en wordt alle energie gestoken in het creëren van een product en afzetgebied. De ondernemers zijn zeer gericht op hun klanten. De feedback die deze klanten geven wordt gebruikt voor de controle op en de aansturing van bedrijfsprocessen. Formele processen worden dan ook vaak niet ingericht. In feite geeft Greiner zelfs aan dat het inrichten van al te formele processen de groei kan belemmeren. De organisatie is zeer reactief en naar buiten op de markt gericht. Gedurende de groei die het bedrijf doormaakt is het klantenbestand toegenomen en zijn bedrijfsprocessen te groot en complex geworden om bestuurd te worden door de oorspronkelijke eigenaren van het bedrijf. De oorspronkelijke eigenaren zien zich steeds meer bedolven worden onder managementtaken en raken verwijderd van hun eigenlijke taak; ondernemen en de strategie bepalen. De eigenaren zien zich genoodzaakt om managers aan te stellen en hun leiderschap te delegeren. Deze periode wordt gekenmerkt als de revolutie en luidt het einde van de eerste fase in. Fase 2: Aansturing Tijdens de revolutie in fase twee is een functionele organisatie ingericht. Deze organisatie is dusdanig gegroeid dat ondersteuning van de secundaire bedrijfsprocessen door ICT noodzakelijk wordt. De onlangs aangestelde managers, specialisten op hun vakgebied, richten systemen in voor het beheren van de interne bedrijfsprocessen. Onder interne bedrijfsprocessen wordt verstaan de boekhouding, inkoop en verkoop en inventarisbeheer. Door de functionele organisatiestructuur ontstaat een meer formele en onpersoonlijkere communicatie. De grootste verantwoordelijkheid voor het nemen van beslissingen ligt bij de topmanagers. De functioneel specialisten hebben over het algemeen een grotere kennis gekregen van de bedrijfsvoering op hun vakgebied. Echter deze functioneel specialisten hebben geen beslissingsbevoegdheid. Doordat de beslissingsbevoegdheid op een hoog niveau ligt en hiërarchisch gecentraliseerd is gaat het proces stroef en duurt het lang voordat beslissingen zijn genomen. De revolutie van de fase koers dient zich aan. Om deze stroefheid en bureaucratie van de organisatie te doorbreken wordt bij het overgrote deel van de bedrijven gekozen voor het vergroten van de autonomie van de bedrijfsonderdelen. Bij de bedrijfsonderdelen komen de beslissingsbevoegdheden op lagere niveaus te liggen. Fase 3: Delegeren De decentrale organisatie waarbij de nieuwe managers een grotere verantwoordelijkheid hebben gekregen is neergezet. De organisatie bestaat nu uit verschillende autonome zuilen gericht op het afzetgebied en de functionaliteit die zij leveren. Nieuwe producten en acquisities worden simpelweg aangelijnd aan de bestaande organisatie structuur naast de bestaande zuilen. Meer en meer zuilen ontstaan. Top managers verliezen het overzicht terwijl de zuilen ongecoördineerd en autonoom richting bepalen in de werkzaamheden die zij verrichten. De zuilen verschaffen zichzelf een grote vrijheid die onderdeel is geworden van de bedrijfscultuur. De topmanagers zoeken een manier om weer in control te komen van hun eigen bedrijf. De revolutie van fase 3 is aangebroken. Hierbij wordt vaak gekeken naar het opnieuw centraliseren van de macht. Dit blijkt vaak geen oplossing. De bedrijfsprocessen liggen te verankerd in de verschillende zuilen. De oplossing wordt gezocht in het samenvoegen van de decentrale zuilen in productgroepen. De sturing vindt plaats door het - 6 -

7 invoeren van coördinatietechnieken, waarin formele processen, rapportage en planning een grote rol vervullen. 2.3 Fasen in de ICT volgens Boonstra Bij het model van Greiner groeit de organisatie niet geleidelijk, maar gaat gepaard met een aantal typische fasen. Deze fasen zoals is opgemerkt hebben een grote invloed op de ICT omgeving. Boonstra [2] omschrijft een model voor de toename van de complexiteit van de ICT omgeving, waarbij met veranderend gebruik van ICT in de organisatie rekening wordt gehouden. In dit model worden 6 fasen ten aanzien van het gebruik en de daarbij veranderende infrastructuur gedefinieerd. Deze fasen van de ontwikkeling tonen een grote gelijkenis met de fasen die worden beschreven in het model van Greiner. In de eerste fasen is de ICT afdeling gericht op één product, wat overeen komt met de fase creativiteit. Het bedrijf is gericht op het primaire product dat voor de klant van het bedrijf is ingericht. In de tweede fase van Boonstra zien we dat meer systemen en applicaties ingericht zijn. De applicaties zijn ingericht door de aangestelde topmanagers ter ondersteuning van hun eigen bedrijfsprocessen. In fase drie waar volgens Greiner de nadruk komt te liggen op het koppelen van data voor de aansturing met gebruik van geaggregeerde data binnen het bedrijf, beschrijft Boonstra de noodzaak om systemen te koppelen vanwege data en bestanden die elders in de organisatie ook handig of noodzakelijk zijn om te gebruiken. De koppeling van systemen is ingezet. Figuur 2 geeft een weergave van de fasen volgens Boonstra

8 2.4 Groei ICT In de vorige paragrafen zijn twee verschillende modellen behandeld, namelijk het model van Greiner en het model van Boonstra. Het model van Greiner dat de groei van de organisatie behandelt heeft als nadeel dat het de gevolgen voor de ICT organisatie en de ICT als zodanig onderbelicht. Het model van Boonstra behandelt voornamelijk het verschillend gebruik van ICT in de organisatie. De koppeling naar de groei van een organisatie ontbreekt. In de volgende paragrafen wordt de groei van de ICT organisatie geschetst aan de hand van de modellen van Greiner en Boonstra. Fase 1: Creativiteit In deze eerste fase is de ICT organisatie verantwoordelijk voor een relatief klein aantal omgevingen en ICT componenten. Het bedrijf is gericht op een klein aantal producten en dienstverleningen aan de klant. De ICT afdeling ondersteunt een beperkt aantal producten, en beheert een relatief eenvoudige omgeving. Communicatielijnen zijn kort en het credo is hier over het algemeen; U vraagt wij draaien. De ICT organisatie wordt direct aangestuurd door de eigenaren, die op hun beurt een direct contact met hun klanten hebben. ICT is hierdoor sterk naar buiten gericht en kent een grote mate van flexibiliteit en innoverende activiteiten

9 Plannen van activiteiten wordt zelden gedaan en de activiteiten van de ICT afdeling zijn vooral reactief. De organisatie staat alleen niet stil. De ICT organisatie groeit mee met het bedrijf en krijgt ook te maken met een groter klantenbestand en meer diensten en producten die door de ICT ondersteund worden. De ICT organisatie wordt langzaam complexer. In de ICT organisatie ontstaan specialisaties. De kennis van de ICT infrastructuur is niet meer te bevatten voor één medewerker. In de turbulente fase krijgt de afdeling ICT, evenals andere afdelingen, een manager omdat de eigenaren niet meer in staat zijn de ICT nog te besturen. Inherent aan de aanstelling van managers is het langer en complexer worden van de communicatie. Fase 2: Aansturing Met het begin van deze tweede fase breekt ook voor de ICT organisatie een nieuwe periode aan. In de eerste fase was de ICT afdeling verantwoordelijk voor een relatief eenvoudige omgeving met een beperkt aantal producten. Nu de verschillende managers binnen het bedrijf hun interne bedrijfsprocessen laten ondersteunen door ICT gerelateerde oplossingen heeft dit een groot effect op de ICT afdeling. De ICT afdeling wordt geconfronteerd met een grote toename van te beheren systemen en applicaties, voor niet alleen de primaire bedrijfsprocessen, maar ook voor de interne secundaire bedrijfsprocessen. Een woud van systemen ontstaat dat beheerd moet worden door de ICT afdeling. De ICT afdeling ziet naast de bestaande externe klant een tweede interne klant, het bedrijf zelf, ontstaan. Niet alleen het systeemlandschap kent een grotere diversiteit, ook de te leveren diensten aan de organisatie is gediversifieerd. In dit proces zien we dat de belangen van de verschillende afdelingen niet altijd meer hetzelfde zijn. De ICT afdeling ziet zich genoodzaakt in overleg met het bedrijf de belangen en prioriteiten te gaan bepalen. Een andere aanpak van beheer is nodig om de ICT in control te houden. Door de toename van de hoeveelheid en diversiteit van systemen zijn er mogelijk ook verschillende ICT afdelingen ontstaan. De technisch specialisten die voornamelijk in de techniek zaten en geen beslissingsbevoegdheid hadden worden nu aangesteld als de managers die beslissingen moeten nemen. Fase 3: Delegeren ICT Deze derde fase heeft een grote weerslag op de ICT dienstverlening. De veranderde structuur van autonome zuilen naar gecoördineerde productgroepen is alleen mogelijk wanneer geaggregeerde data en rapportages opgeleverd kunnen worden. De geaggregeerde data en rapportages zijn alleen op te leveren aan het management wanneer ICT systemen worden gekoppeld en data centraal beschikbaar wordt gesteld. Een extra moeilijkheid is dat de acquisities en de grote autonomie van zuilen ervoor heeft gezorgd dat de ICT organisatie met vele standaarden rekening moet houden. De mogelijkheid bestaat dat ICT gedecentraliseerd is opgezet en autonoom beheerd wordt door één van de zuilen. De systeemintegratie die noodzakelijk is voor het opleveren van geaggregeerde data geeft een probleem van een heel andere orde. Systemen worden afhankelijk en primaire bedrijfskritische applicaties zijn afhankelijk van schijnbaar onbelangrijke secundaire systemen. Verstoringen in deze schijnbaar onbelangrijke secundaire systemen kunnen ineens grote gevolgen hebben voor de bedrijfskritische processen

10 Gedurende de groei van een bedrijf neemt de complexiteit van de organisatie en van het ICT landschap toe. Daarnaast zien we een constant veranderend eisenpakket wat aan de ICT organisatie wordt gevraagd. In fase 1 wordt voornamelijk flexibiliteit en innovatie verwacht. Fase 2 verwacht naast innovatie van producten voor de klant ook de ondersteuning van secundaire bedrijfsprocessen. In fase 3 wordt verwacht dat de ICT organisatie bestaande systemen integreert zodat het verkrijgen van geaggregeerde data en rapportages voor het management mogelijk wordt. Onderstaande tabel (tabel 1) geeft een schematische weergave van de groei van een organisatie en de invloed op ICT. Tabel 1: Groeifasen organisatie Fase 1 Fase 2 Fase 3 Verschuiving focus ICT Innovatie, klantgericht Bedrijfsprocessen Informatievoorziening Organisatie Business Eén afdeling Eén business afdeling en diverse ondersteunende afdelingen Organisatie ICT Eén ICT afdeling ICT bestaat uit meerdere afdelingen, specialisten Divisiestructuur en diverse ondersteunende afdelingen. Mogelijk meerdere autonome ICT afdelingen. als teamleiders. Aansturing Direct Top Management. Gelaagd Management model, coördinatie op basis van management informatie. Communicatie Informeel, eenvoudig Formeel, redelijk eenvoudig Formeel, complex Complexiteit ICT Gering, één systeem Redelijk, meerdere onafhankelijke systemen Ondersteuning ICT Core business Core business en secundaire bedrijfsprocessen Kennis Brede kennis over het ICT landschap Specialisaties op ICT deelsystemen Meerdere afhankelijke en geïntegreerde systemen Core business, secundaire bedrijfsprocessen en management informatie Specialisaties op ICT deelsystemen

11 3.0 Complexiteit en risico In de vorige paragrafen is de groei van een organisatie behandelt waarbij duidelijk naar voren komt dat groei een grote verandering bij de ICT organisatie te weeg brengt. Deze groei en toenemende complexiteit van de ICT en organisaties verhogen ICT risico s. De volgende paragrafen geven een weergave van de toename van complexiteit in een organisatie en de daarmee gepaard gaande risico s. 3.1 ICT Complexiteit en risico We kunnen gevoeglijk aannemen dat naarmate de organisatie verder groeit de complexiteit van systemen toeneemt. Dit wil overigens niet zeggen dat de producten en systemen die ICT van oudsher beheert eenvoudig van aard zijn. Dit kunnen ingewikkelde real time omgevingen zijn waaraan hoge eisen aan beschikbaarheid, betrouwbaarheid en integriteit worden gesteld. Naarmate het aantal ICT componenten groeit zien we dat de benodigde kennis voor het beheren van de ICT omgeving de capaciteit van individuele medewerkers overstijgt. Eén persoon is niet meer in staat het hele ICT landschap te overzien en te beheren. In de ICT organisatie ontwikkelen zich specialisten die niet in de breedte de kennis over het ICT landschap bezitten, maar een diepe kennis bezitten van een beperkt aantal systemen. Omdat kennis niet meer gedeeld wordt over een grote groep medewerkers, maar in handen komt van individuen, ontstaan hiaten in de kennis over de ICT infrastructuur. Voor de ICT organisatie wordt het moeilijker het hele ICT landschap te overzien, waardoor de organisatie minder in staat is om de effecten van wijzigingen op de omgevingen te voorspellen. Door de vergrote complexiteit zal het aantal onvoorspelbare bijeffecten van wijzigingen groter worden. Naarmate de complexiteit van ICT systemen toeneemt wordt het risico van verstoringen en andere ongewenste bijeffecten groter [3]. Deze verstoringen en bijeffecten zorgen onder andere voor een verminderde beschikbaarheid van systemen. De ICT organisatie loopt tegen het feit aan dat veranderingen die vanuit het bedrijf gevraagd worden kunnen leiden tot verstoringen en verminderde dienstverlening aan klanten. Daarnaast wordt het zoeken naar de oorzaak van de verstoringen eveneens bemoeilijkt door de complexiteit van het ICT landschap. Waar eerder direct oorzaak en gevolg aangewezen konden worden heeft men te maken gekregen met een woud aan systemen die afhankelijk zijn van elkaars output. Oorzaak en gevolg zijn niet meer direct te determineren en het gevolg is dat de oplossingstijd van incidenten toeneemt. Onderzoek van Gartner [4] wijst uit dat bij onvoldoende beheerst invoeren van wijzigingen tot 70% van de ingevoerde wijzigingen mislukt. Tot 80% van de incidenten is te wijten aan wijzigingen op de ICT omgeving. Dit

12 resulteert in een besteding van over de 50% aan tijd aan ongepland meerwerk omdat wijzigingen niet die functionaliteit leveren die gevraagd was door het bedrijf. Het is evident dat wanneer een ICT organisatie voornamelijk bezig is met incidenten en het oplossen van oud zeer, niet meer de tijd heeft om de business in bedrijfsvoering en strategie te ondersteunen. 3.2 Organisatie complexiteit en ICT Zoals eerder omschreven zijn kleine organisaties relatief eenvoudige organisaties. Communicatiekanalen zijn overzichtelijk, iedereen streeft hetzelfde doel na en deelt de belangen van de organisatie. Er zijn weinig mensen met beslissingsbevoegdheid en de aansturing is direct via korte kanalen. Naarmate de organisatie groter wordt, stijgt het aantal afdelingen en mensen met bevoegdheden. Het aantal communicatiekanalen nemen toe in lengte en in aantal. Er moet gecommuniceerd worden over meerdere organisatorische schijven, waarbij de belangen niet meer allemaal even inzichtelijk zijn. De ICT afdeling behartigt niet meer de belangen van één klant, maar van vele kleine klanten die elk hun eigen belangenafwegingen en prioriteiten maken. In feite is het denkbaar dat verschillende afdelingen verschillende belangen vertegenwoordigen en zelfs tegenstrijdigheden kunnen bevatten. De belangen van partij A zijn tegenstrijdig aan de belangen van partij B binnen de organisatie terwijl beiden hun eigen agenda opleggen aan ICT. Het aantal toegenomen communicatiekanalen en meerdere belangenafwegingen maakt het voor de ICT afdeling niet gemakkelijk om een consistente planning te maken en de prioriteiten af te wegen. Ook is het voor de ICT organisatie moeilijk te bepalen wanneer ICT systemen beschikbaar moeten zijn. Waar eerst in de kleine organisatie direct contact was met de eigenaar en snel kon worden bepaald op welke tijdstippen wijzigingen konden plaatsvinden of moesten worden afgelast vanwege bijvoorbeeld de jaarafsluiting of een demonstratie aan klanten, is dat in een grote organisatie een stuk moeilijker te bepalen. Het risico bestaat dat wijzigingen worden doorgevoerd op een tijdstip dat voor de organisatie niet uitkomt en activiteiten frustreert. Niet alleen het bedrijf is in grootte toegenomen, maar ook de ICT organisatie zelf is meegroeid. Wanneer bij de kleine organisatie de telefoon ging werd deze opgenomen en de klant werd geholpen met zijn probleem. Dit was voor de ICT afdeling geen probleem. Iedereen had voldoende kennis en men wist van elkaar wie waarmee bezig was. Nu de hoeveelheid personeel en aantal afdelingen binnen de ICT organisatie is toegenomen en specialismen zijn ontstaan worden problemen doorgeschoven en raakt men het overzicht kwijt. Het risico bestaat dat hierdoor problemen lange tijd blijven liggen en incidenten en verstoringen langer duren dan nodig is. Wanneer de ICT organisatie niet anticipeert op de veranderende communicatie, zal zij het overzicht verliezen en minder in staat zijn de ICT wijzigingen te coördineren en incidenten snel en efficiënt af te handelen. 3.3 Verminderen risico s ICT

13 Bij een toenemende complexiteit en een hoger risico op verstoringen door wijzigingen op de ICT omgeving wordt de noodzaak hoger om het toegenomen risico op deze verstoringen bij wijzigingen te verminderen. Niet alleen de klanten ondervinden hinder van de verstoringen maar ook de ICT afdeling zelf kan zich niet meer richten op hun eigenlijke werk namelijk; het ondersteunen van het bedrijf in het ontplooien van bestaande en nieuwe activiteiten. Effectief changemanagement kan helpen de controle over wijzigingen terug te krijgen, terwijl een effectief incidentmanagement helpt bij het snel en efficiënt herstellen van de dienstverlening bij incidenten die de productie verstoren. Het is vrij gemakkelijk te bepalen of change- en incidentmanagement faalt binnen de organisatie. Om te bepalen of change- en incidentmanagement onvoldoende in de organisatie aanwezig is kunnen een aantal risico indicatoren gebruikt worden. De top 5 van risicoindicatoren [4] van een slecht functionerend change management zijn: Ongeautoriseerde wijzigingen vinden plaats Ongeplande wijzigingen vinden plaats Lage succes factor van wijzigingen Hoog gehalte aan nood wijzigingen Vertraagde project implementaties Herkenbare symptomen als gevolg van deze risico s zijn: Wijzigingen interfereren met geplande bedrijfsprocessen en geplande werkzaamheden van externe leveranciers. Onbeschikbaar zijn van applicaties en netwerk door incidenten. IT organisatie is voornamelijk bezig met onderhoud en dagelijkse operatie in plaats van het bedrijf te helpen met nieuwe mogelijkheden. Hoog gehalte aan brandjes blussen en ongepland werk, waardoor projecten en gepland werk uitlopen. Hoog verloop in IT medewerkers. Verslechterende relatie met het bedrijf, gewoonlijk door slechte kwaliteit of uitlopen van het leveren van functionaliteit. Medewerkers van de ICT afdeling worden gestoord in hun werk door dwingende en dringende telefoontjes vanuit het bedrijf. De risico-indicatoren [5] van een falend incident management zijn: Onopgeloste incidenten Onbehandelde incidenten Ongewenste uitkomst oplossing Onbekende oorzaak incidenten Herkenbare symptomen als gevolg van deze risico zijn: Langdurige onbeschikbaar zijn van bedrijfsfuncties Aangemelde incidenten zingen rond in de ICT organisatie Klanten worden niet gebeld over incidenten en bellen daarom zelf ICT

14 Incidenten worden niet geregistreerd. Wijzigingsverzoeken worden behandeld als incidenten en krijgen dezelfde prioriteit De best-practice ITIL reikt processen aan om de controle terug te krijgen over de ICT dienstverlening. 4.0 ITIL ITIL is een best practice standaard uitgegeven door het itsmf [6] en wordt wereldwijd erkent als de standaard voor inrichting van IT beheer organisaties. ITIL is een werkwijze waarmee op een gestructureerde, reproduceerbare en traceerbare manier de effectiviteit en efficiëntie van de servicegraad van ICT-systemen zijn gewaarborgd. Dit onderzoek legt de focus op twee ITIL processen; namelijk incidentmanagement en changemanagement. Incident- en changemanagement zijn twee sterk aan elkaar gerelateerde processen. Volgens Gartner en IIA ontstaan de meeste incidenten bij een organisatie door mislukte wijzigingen. Bij organisaties met een falend changemanagement kan dat oplopen tot 80% van de incidenten. Incidenten daarentegen leiden via het ITIL proces problem management tot wijzigingen op de ICT infrastructuur. Deze keuze is gemaakt omdat groeiende bedrijven veelal volatiel van aard zijn, de ICT-omgeving is weinig stabiel en sterk aan verandering onderhevig om de groei van het bedrijf mogelijk te maken. In dit hoofdstuk worden kort de ITIL processen Incident en Changemanagement behandelt waarbij kort de Key controls en Key Performanace Indicatoren worden geïntroduceerd. 4.1 Changemanagement Changemanagement heeft als doelstelling wijzigingen op de ICT infrastructuur en applicaties op een controleerde en gestandaardiseerde manier door te voeren zodat de impact van wijzigingen en gerelateerde incidenten minimaal is en de dagelijkse operatie niet verstoren. Om deze doelstelling te behalen dienen alle wijzigingen tijdig, volgens planning ingevoerd te worden. Alvorens de wijziging kan worden ingevoerd dient deze getest en geautoriseerd te worden. Ongeautoriseerde wijzigingen kunnen tot ongewenste bijeffecten leiden die de productie verstoren omdat deze niet getest is en degene die de wijziging heeft gemaakt niet alle consequenties heeft overzien. Daarnaast is het van belang dat wijzigingen worden beoordeeld op doeltreffendheid voor de organisatie om te voorkomen dat de kosten van de wijziging de baten overstijgen. Figuur 3 geeft een schematische weergave van de processtappen van het changemanagement. Veel schematische voorstellingen geven louter een beeld van de processtappen binnen ICT

15 In dit schema staan de stappen waarbij input vanuit de business noodzakelijk is doorgetrokken in het domein van de business. Deze weergave is niet zozeer een volledige weergave van changemanagement, maar benadrukt de rol van de business bij het changemanagement proces. ITIL gaat uit van een strikte scheiding van verantwoordelijkheden waarin tegengestelde belangen zijn gecreëerd zodat met een redelijke mate van zekerheid gezegd kan worden dat het volledige proces wordt doorlopen en de juiste medewerkers, afdelingen en functies zijn geïnformeerd en hun goedkeuring hebben verleend. Door de verschillende processtappen heenlopend zijn een aantal keycontrols [7] te definiëren waaraan een changemanagement proces moet voldoen

16 Tabel 2: Change Management: Key Controls Nr Key control 1 Het Change management proces is gedocumenteerd en alle verantwoordelijkheden zijn beschreven. 2 Alle wijzigingsverzoeken worden centraal aangenomen en geregistreerd bij een voor de klant bekend loket. 3 Prioriteit van de wijziging wordt bepaald onafhankelijk van de uitvoerders en de bouwers. 4 Van alle wijzigingsverzoeken wordt prioriteit van de wijziging en de impact op ICT en organisatie bepaald. 5 Wijzigingsverzoeken worden geautoriseerd met in acht name van de impactanalyse. 6 Alle wijzigingen worden met in acht name van de impactanalyse en beschikbare resources gepland. 7 Alle wijzigingen worden voor in productiename getest. 8 Testen van geplande wijzigingen vinden onafhankelijk plaats van de bouwers van de wijziging. 9 Het change management proces wordt bewaakt. Bewaken van de voortgang vindt onafhankelijk plaats van de uitvoering. 10 Wijzigingen worden afgesloten nadat gebleken is dat de wijziging het beoogde resultaat heeft behaald. In hoofdstuk 3.3 is al geschreven over de risico indicatoren van het change management. Uit de risico indicatoren en de key controls zijn de volgende key performance indicatoren te reduceren: Tabel 3: Change Management: Key Performance Indicatoren Nr Key Performance Indicator 1 Aantal wijzigingen per tijdseenheid. 2 Percentage mislukte wijzigingen. 3 Aantal ongeautoriseerde wijzigingen. 4 Percentage incidenten dat uit wijzigingen voortkomt. 5 Percentage wijzigingen dat na de geplande datum ingevoerd wordt. 6 Percentage spoedwijzigingen of ongeplande wijzigingen. 7 Percentage van de tijd gespendeerd aan spoedwijzigingen of ongeplande wijzigingen

17 4.2 Incidentmanagement Incidentmanagement heeft als doelstelling de dienstverlening na een verstoring zo snel mogelijk te hervatten en de impact op de business zo minimaal mogelijk te houden. Het incident management is erop gericht incidenten te managen op een consistente wijze waarbij alle incidenten gelogd en bewaakt worden. Zonder een gestructureerd incidentmanagement proces bestaat het risico dat incidenten niet of niet tijdig behandeld worden waardoor verstoringen op de productie omgeving langer dan noodzakelijk duren. Figuur 4 geeft een schematische weergave van de processtappen van het incidentmanagement. Veel schematische voorstellingen geven louter een beeld van de processtappen binnen ICT. In dit schema staan wederom de stappen waarbij input vanuit de business noodzakelijk is doorgetrokken in het domein van de business

18 Voor het incident management zijn de volgende keycontrols [7] te definiëren: Tabel 4: Incident management: key Controls Nr Key control 1 Het Incident management proces is gedocumenteerd en alle verantwoordelijkheden zijn beschreven. 2 Alle incidenten worden centraal aangenomen en geregistreerd bij een voor de klant bekend loket. 3 Van alle incidenten wordt de impact en urgentie bepaald in overeenstemming met het afgesproken serviceniveau. 4 Uit incidenten voortvloeiende noodzakelijke wijzigingen worden via het change management proces behandeld. 5 Bewaken van de voortgang vindt onafhankelijk plaats van de oplosgroep. 6 Afsluiten van een incident vindt plaats nadat is verzekerd da het incident voor de melder naar tevredenheid is opgelost. In hoofdstuk 3.3 is al geschreven over de risico indicatoren van het incident management. Uit de risico indicatoren en de key controls zijn de volgende key performance indicatoren te reduceren: Tabel 5: Incident Management: Key Performance Indicatoren Nr Key Performance Indicator 1 Aantal incidenten per tijdseenheid naar impact en urgentie. 2 Doorlooptijden incidenten van aanmelden tot afsluiten. 3 Percentage opgelost binnen afgesproken tijdseenheid (SLA). 4 Percentage heropende incidenten. 5 Percentage van de tijd gespendeerd aan incidenten 4.3 ITIL implementaties in relatie tot de grootte van de organisatie Organisaties van verschillende groottes hebben te maken met hele verschillende problemen op het gebied van change- en incidentmanagement. Kleine organisaties verschillen in cultuur, business en ICT focus, organisatie opbouw, ICT en in aansturing sterk van grotere organisaties. De ITIL best-practice is geschreven, althans wordt daarvan beschuldigt, met grote rekencentra in het achterhoofd. In de literatuur [8] zijn verschillende kleinschalige

19 implementaties te vinden van de ITIL processen. Implementaties van ITIL processen zijn gebaseerd op het samenvoegen van rollen waarbij rekening wordt gehouden met de kleinschaligheid, korte communicatielijnen en informele karakter van de organisatie. De uitgangspunten voor de implementatie van ITIL processen zijn een aantal karakteristieken van de organisatie: Grootte en organisatiestructuur bedrijf Aantal medewerkers ICT Complexiteit ICT Cultuur Aansturing Focus Bedrijf en dus focus ICT Volatiliteit van de ICT Door de fasen van een bedrijf heen zien we dat deze karakteristieken sterk veranderen. Een implementatie van change- en incidentmanagement in een kleine organisatie zijn met weliswaar dezelfde doelstelling geïmplementeerd, het voorkomen van incidenten door wijzigingen en snel herstel van dienstverlening, de basis van de ITIL processen zijn totaal anders. Een bedrijf in de eerste fase heeft weinig medewerkers, ICT staat dicht tegen de business, de aansturing is direct en de ICT is relatief weinig complex. Voor het changemanagement betekent dit concreet dat niet alle rollen en functies die in ITIL staan vermeld volledig zijn ingevoerd. De business heeft nauw contact met ICT, plannen en het stellen van prioriteiten is relatief eenvoudig. Impact van een wijziging is snel bepaald omdat alle ICT medewerkers de nodige kennis van het ene systeem bezittenen en er geen afhankelijkheden zijn. Daarnaast zullen een aantal keuzes zijn gemaakt ten aanzien van het beschikbare personeel. Bijvoorbeeld ontwikkelaars met operationele bevoegdheden. Testen kan door de business worden uigevoerd. De bewaking van wijzigingen kan zijn samengevoegd met andere functies zoals het incident management en andere ITIL functies. Een bedrijf in de tweede fase kent meer afdelingen, een complexere ICT en de aansturing is niet meer direct. Binnen het changemanagement worden planning en het stellen van prioriteiten belangrijker omdat het aantal afdelingen en belangen is toegenomen. Topmanagement heeft de aansturing overgenomen en vanuit meerdere afdelingen worden wijzigingen aangevraagd met verschillende doelstellingen. Een implementatie van changemanagement zal met dit gegeven ingericht zijn. Een bedrijf in de derde fase waar de ICT afhankelijkheid toeneemt en het bedrijf verder diversifieert zal naast plannen en het stellen van prioriteiten het bepalen van de impact en het testen in gewicht gaan toenemen. We kunnen verwachten dat in een organisatie als deze speciale functies zijn ingericht voor de bewaking van het changemanagement proces en een changemanager is aangesteld. Geformaliseerd overleg met de business en ICT onderling is te verwachten voor het bepalen van planningen, prioriteiten en impact. Bij het incidentmanagement hebben we te maken met dezelfde factoren. ITIL gaat ervan uit dat het oplossen is onderverdeeld in meerdere lijnen. Elke lijn onderzoekt het probleem en

20 probeert deze op te lossen. Hoe moeilijker het probleem hoe dieper deze in de organisatie terecht komt. De meerdere lijns helpdesk is ingericht om te voorkomen dat specialisten, waar er altijd een beperkt aantal van zijn, overspoeld worden met kleine incidenten. Een bedrijf in de eerste fase heeft geen specialisten en een dusdanig groot aantal medewerkers dat een meerdere lijns helpdesk valt in te stellen. Bij bedrijven in de tweede en derde fase zal het waarschijnlijk zijn dat daar wel een meerdere lijns helpdesk is gevormd. In de verschillende groeistadia zien we dat verschillende implementaties van incident en changemanagement veranderen. In het volgende hoofdstuk wordt het CobiT Maturity level aangehaald om weer te geven wat de impact van groei is op het changemanagement en incident management proces. 5.0 CobiT Maturity Model Het CobiT maturity model is een breed geaccepteerd model voor de mate van volwassenheid van processen binnen de ICT organisatie. CobiT [9] is uitgegeven door het IT Governance Institute ( Het CobiT Maturity Model stelt de organisatie in staat te bepalen te identificeren waar in de ICT processen verbeteringen noodzakelijk zijn. Het maturity model van CobiT is opgebouwd uit 6 niveaus waarin een gedeelte van het proces zich kan bevinden. Elk van deze 6 niveaus is onderverdeeld in 6 thema s welke elk een eigen aandachtsgebied in het proces zijn. Bijlage 1 geeft de volwassenheid en de thema s weer waarbij genoteerd moet worden dat niveau 0 Non-existent niet is meegenomen in deze tabel. Op niveau 0 is een volledig gebrek aan herkenbare processen, daarnaast is binnen de organisatie geen noodzaak gezien deze in te richten. De zes gedefinieerde niveaus binnen het CobiT maturity level zijn: Level 0, Non-existent Het proces wordt niet uitgevoerd door de organisatie en het belang wordt niet onderkend van het proces. Er wordt niet gestreefd naar inrichting va het proces. Level 1, Initial/Ad Hoc Het management is zich bewust van het belang van het proces, methodes en procedures zijn echter niet vastgelegd. Het proces is reactief en afhankelijk van individuen. Level 2, Repeatable but intuitive Het managemnt is bewust van het belang van het proces. Formeel zij er geen methodes of procedures vastgelegd, wel is er een eerste aanzet tot een eenduidig beleid. Verantwoordelijkheden en raamwerk zijn nog niet vastgelegd. Succes en kwaliteit van het proces hangen af van de kunde van de medewerker die het proces uitvoert. Level 3, Defined proces