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

- 2 -

Voorwoord Deze scriptie is geschreven als eindopdracht in het 3e jaar 2007-2008 voor de studie EDP-auditing 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 ....................................................................................................................... 4

1.1 Probleemstelling ........................................................................................................ 4 1.2 Doelstelling ............................................................................................................... 4

2.0 De invloed van groei op de ICT organisatie .................................................................. 5 2.1 Groei van organisaties ............................................................................................... 5 2.2 Groei van organisaties volgens het model van Greiner ............................................... 5 2.3 Fasen in de ICT volgens Boonstra ............................................................................. 7 2.4 Groei ICT .................................................................................................................. 8

3.0 Complexiteit en risico ................................................................................................. 11 3.1 ICT Complexiteit en risico ...................................................................................... 11 3.2 Organisatie complexiteit en ICT .............................................................................. 12 3.3 Verminderen risico’s ICT ........................................................................................ 12

4.0 ITIL............................................................................................................................ 14 4.1 Changemanagement ................................................................................................ 14 4.2 Incidentmanagement ............................................................................................... 17 4.3 ITIL implementaties in relatie tot de grootte van de organisatie ............................... 18

5.0 CobiT Maturity Model................................................................................................ 20 5.1 Maturity, voorspelbaarheid, complexiteit en risico................................................... 21 5.2 Maturity en business alignment ............................................................................... 21 5.3 Veranderingen in maturity level bij groei organisatie ............................................... 22

6.0 Bestendigheid incident en changemanagement proces ................................................ 24 6.1 Bepalen maturity van Incident en changemanagement ............................................. 26

7.0 Casus Bank X ............................................................................................................. 28 7.1 Inleiding Casus Bank X ........................................................................................... 28 7.2 Doel Casus Bank X ................................................................................................. 28 7.3 Werkwijze ............................................................................................................... 28 7.4 Groeifase Bank X .................................................................................................... 28 7.5 Maturity en controls ................................................................................................ 30 7.6 Werking Incident en changemanagement bij Bank X ............................................... 30 7.7 Conclusie Bank X ................................................................................................... 31

8.0 Eindconclusie en reflectie ........................................................................................... 32 8.1 Conclusie ................................................................................................................ 32 8.2 Reflectie .................................................................................................................. 32

Bijlage I Referenties ........................................................................................................ 34 Bijlage II Controls in relatie tot groeifase en maturity ...................................................... 35 Bijlage III Cobit Maturity Levels..................................................................................... 41 Bijlage IV Casus Bank X Controls .................................................................................. 43 Bijlage V Maturity Levels Bank X .................................................................................. 50

- 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 Gr einer 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

- 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

Divisiestructuur en diverse ondersteunende afdelingen.

Organisatie ICT Eén ICT afdeling

ICT bestaat uit meerdere afdelingen, specialisten als teamleiders.

Mogelijk meerdere autonome ICT afdelingen.

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

Meerdere afhankelijke en geïntegreerde systemen

Ondersteuning ICT Core business Core business en secundaire bedrijfsprocessen

Core business, secundaire bedrijfsprocessen en management informatie

Kennis Brede kennis over het ICT landschap

Specialisaties op ICT deelsystemen

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 risico-indicatoren [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 onafhankeli jk 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 Indicat oren 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 Indic atoren 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 v an 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 (www.itgi.org). 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

- 21 -

Het proces is gestandaardiseerd, gedocumenteerd en wordt uitgedragen. Het proces is nog steeds reactief en het is aan de uitvoerende persoon om het proces te volgen. Het is niet waarschijnlijk dat afwijkingen van het proces worden geconstateerd.

• Level 4, Managed and Measurable Het proces wordt continu verbeterd en er wordt gebruik gemaakt van best-practices. Mijlpalen en KPI’s zijn beschreven. Daar waar resultaten afwijken in de uitvoering, wordt actie ondernomen.

• Level 5, Optimised Het proces is geoptimaliseerd door continue verbetering en benchmarking aan vergelijkbare organisaties. Het proces is een integraal onderdeel van de beheermaatregelen, organisatiedoelen en plannen.

5.1 Maturity, voorspelbaarheid, complexiteit en ris ico Harrison, Settle en Raffo [10] en het SEI [11][12] leggen een sterke relatie met de voorspelbaarheid en risico van het proces en het maturity level van, in dit geval, de projectorganisatie volgens het Capability Maturity Model van SEI. Een direct verband met het Cobit Maturity level wordt niet gelegd, echter het Cobit maturity model is een afgeleide van het Capability Maturity Model dat ontwikkeld is door het Software Engineering Institute (SEI) voor bepaling van de mate van volwassenheid van de software ontwikkeling. Kort gezegd stellen zij, dat naarmate het volwassenheidsniveau hoger wordt het risico afneemt en de voorspelbaarheid toeneemt. Voorspelbaarheid en productiviteit moeten niet worden verward. Productiviteit gaat over de hoeveelheid werk die is verzet binnen een bepaald budget en tijdsbestek en is relatief eenvoudig te meten. Voorspelbaarheid gaat over het in staat zijn van te voren vast te stellen wat de uitkomst is, de hoeveelheid resources en tijd die nodig is. In hoofdstuk 2 is het verband gelegd tussen complexiteit van ICT en toenemend risico op factoren. We kunnen dus stellen dat met toenemende complexiteit van ICT een hoger maturity level is gewenst om het risico van verstoringen op een voor de organisatie acceptabel niveau te brengen. 5.2 Maturity en business alignment Zoals de mate van voorspelbaarheid een afhankelijke is van de volwassenheid van de organisatie ligt ook een relatie te tussen de mate van alignement tussen ICT en de business en de volwassenheid van de organisatie. Des te lager de volwassenheid, des te minder de ICT/Business alignement [13]. Business/ICT alignment laat zich omschrijven als het matchen van de business noden en IT services [14], in andere worden; hetgeen de business verwacht

- 22 -

dat ICT levert en hetgeen ICT daadwerkelijk levert. Business/ICT Alignment beslaat alle diensten die ICT levert. 5.3 Veranderingen in maturity level bij groei organ isatie Literatuur gaat uit van het bereiken van een bepaald maturity level in de organisatie. Informatie over de kosten en investeringen die gepaard gaan met een veranderende organisatie die nodig zijn om een maturity level te behouden lijkt niet aanwezig in de gangbare literatuur. Veranderingen in het Maturity level gaan in mijn overtuiging niet per definitie omhoog. Het laten verslappen of onvoldoende investeren in processen kunnen een neerwaartse beweging inzetten. Groei van een organisatie betekend ook een grotere investering in het behouden van het maturity level. Wanneer geïnstalleerde processen niet meegroeien met de organisatie en steeds minder passen bij de grootte en complexiteit van de organisatie zal dit zijn weerslag hebben op het maturity level van de organisatie en van de processen. Naarmate proces en organisatie meer en meer uit de pas gaan lopen, zullen de investeringen om het maturity level te behouden navenant hoger worden, tot op het moment dat investeringen te hoog worden om vol te houden. Concreet betekent dit extra investeren in het behoudt van het maturity level dat eens is bereikt. Gartner [15] geeft aan dat de maturity van security management kan afnemen door acquisities waarbij veel systemen gekoppeld moeten worden, management wisselingen en veranderende focus. Gartner legt geen koppeling met de natuurlijke groei van een organisatie. In mijn overtuiging en gesterkt door Gartner poneer ik de stelling dat veel organisaties niet bezig zijn met het verhogen van het maturity level, maar met het herstellen van het maturity level wat ooit in een vroeger stadium is neergezet . Hieronder beschrijf ik de zes thema’s binnen het CobiT maturity model en de negatieve beïnvloeding van de groei van de organisatie; 1. Communication en awareness Bij een groeiende organisatie neemt het aantal afdelingen, functies, belangen en communicatiekanalen toe. De cultuur veranderd van informeel naar formeel. Communicatie veranderd en wordt meer ingewikkeld. Ingerichte communicatiestructuren houden rekening met een beperkt aantal kanalen en belangen. Met het aantal kanalen neemt ook het volume van de informatie toe, waarmee de efficiëntie verloren gaat en ruis in de communicatie ontstaat. Het wordt voor de organisatie steeds moeilijker om de informatie juist te gebruiken en te verspreiden. Als de afname in het maturity level langzaam gaat en de problemen langzaamaan verergeren is het mogelijk dat niemand voldoende doorheeft dat er problemen zijn ontstaan. De invloed op change management en incident management zijn navenant. Change management is afhankelijk van communicatie met de business voor het plannen en stellen van prioriteiten. Actoren met invloed op de communicatie en bewustzijn zijn:

• Complexiteit organisatie • Cultuur • Aansturing

- 23 -

2. Policies, planning and procedures Eens ingestelde policies en procedures passen niet meer bij de complexiteit van organisatie, niet alle sleutelactiviteiten zijn er meer in opgenomen en houdt geen rekening met toegenomen complexiteit van de organisatie. Met de toegenomen complexiteit neemt ook het aantal parameters toe waarmee een procedure en policy rekening moet houden. De policies en procedures houden geen rekening met subprocessen die zijn ontstaan. Het gevolg is dat policies en procedures vaker worden gepasseerd en de organisatie uiteindelijk afhankelijk word van individuele initiatieven en de processen onregelmatigheden gaan vertonen. Actoren met invloed op policies, planning en procedures zijn:

• Complexiteit ICT • Complexiteit organisatie • Aansturing

3. Tools and automation Bij een groeiende organisatie neemt de complexiteit toe. De inrichting en gebruik van tooling is meestal een weerspiegeling van hoe de organisatie ingericht is en functioneert. Bij een groeiende complexiteit van de organisatie zal bestaande tooling moeten worden aangepast. Wanneer deze niet meegroeit zien we dat meer en meer processen buiten de gebruikte tooling omgaat of tooling niet meer efficiënt functioneert. Doordat tools niet meer voldoen worden her en der eigen individuele oplossingen bedacht om knelpunten op te lossen en zien we een teruggang in het geïntegreerd gebruik van tools. Change- en incidentmanagement processen zijn afhankelijk van het gebruik van tools voor registratie, het sturen van de workflow en bewaking. Waar in een kleine organisatie misschien een spreadsheet voldeed is in de grotere organisatie dit geen oplossing meer. Actoren met invloed op tools and automation zijn:

• Complexiteit ICT • Complexiteit organisatie

4. Skills and expertise Door de toegenomen complexiteit is het voor individuen niet meer mogelijk de volledige ICT infrastructuur te overzien en te kennen. Specialismen ontstaan. De kleine organisatie heeft een opleidingsplan nodig om de medewerkers breed op te leiden zodat geen kennis bij enkele individuen komt te liggen en er gevaar voor de continuïteit van kennis ontstaat. De grote organisatie daarentegen heeft specialisten en dient er voor te zorgen dat deze kennis is geborgd en er geen hiaten in het kennisveld ontstaan. Actoren met betrekking tot skills en expertise zijn:

• Complexiteit ICT

- 24 -

• Complexiteit organisatie 5. Responsibility and accountability Het aantal verantwoordelijkheden is met de gegroeide organisatie ook toegenomen. Wanneer deze niet duidelijk opnieuw belegd en herbelegd worden zal verwarring ontstaan over deze verantwoordelijkheden. Actoren van invloed op de responsibility en acountability zijn:

• Complexiteit ICT • Complexiteit organisatie • Cultuur • Aansturing

6. Goal setting and Measurement Bij groei veranderen de doelen en de focus van het bedrijf. Past ICT niet zijn doelen aan, aan deze veranderde wensen van het bedrijf zal ICT de organisatie steeds minder ondersteunen. Het aantal soorten dienstverlening en parameters zijn toegenomen. Meetinstrumenten dienen aangepast te worden aan de veranderde dienstverlening. Daarnaast is met de toegenomen complexiteit en grootte van ICT het aantal te meetbare variabelen ook toegenomen. De informatie die hieruit voortkomt zal opnieuw op waarde geschat moeten worden. Actoren van invloed op Goal setting and Measurement zijn:

• Complexiteit ICT • Complexiteit organisatie • Aansturing

Er kan gesteld worden dat naarmate een organisatie groeit factoren en actoren veranderen. Bij het niet inspelen op deze veranderende actoren en factoren zal de maturity van een proces afnemen. Met 6.0 Bestendigheid incident en changemanagement proc es Door deze scriptie heen zijn een aantal punten naar voren gekomen die van invloed zijn op de organisatie en de inrichting en maturity van het change en incidentmanagement. Deze zijn:

• Met de groei van de organisatie neemt complexiteit van ICT en organisatie toe.

• Naarmate de complexiteit toeneemt wordt het risico op ongewenste neveneffecten en incidenten op de ICT infrastructuur bij wijzigingen groter.

• Bij een toenemend maturity level wordt het risico van processen lager en de voorspelbaarheid hoger.

• Bij toenemende complexiteit van ICT en organisatie neemt maturity van processen af (aangenomen dat geen tussentijdse bijsturing plaatsvindt).

- 25 -

Gedurende de groei van een organisatie waarbij complexiteit toeneemt zien we dat er een divergente beweging is tussen enerzijds de verhoging van het risico en anderzijds de terugval in maturity. Impliciet houdt dit in dat een organisatie in een hogere groeifase een incident en changemanagement proces met een hoger maturity level nodig heeft om het risiconiveau acceptabel te houden. In figuur 5 is de groei en risico tegen het maturity level ter illustratie grafisch weergegeven.

In figuur 6 wordt als voorbeeld het Maturity level 3 genomen om de grafiek toe te lichten. Op enig moment is besloten om een incident en changemanagement proces in te richten op het maturity level van 3. Het snijpunt van de gestreepte lijn dat het aantal controls weergeeft met de CMM 3 curve is het startpunt waar de implementatie is gestart. Gedurende de groei van een organisatie zien we dat om het maturity 3 level te behouden een steeds groter aantal controls nodig is. De curve loopt op. Bij gelijk aantal controls zien we een afname in het maturity level en toename in het restrisico. Tot op het moment dat de rest risico’s zodanig toenemen dat van een efficiënt en effectief change en incidentmanagement geen sprake meer is.

- 26 -

Bij een afnemend maturity level neemt het risico toe en de voorspelbaarheid af voor processen. Meer wijzigingen mislukken en het aantal incidenten en dus productieverstoringen als gevolg van deze wijzigingen nemen toe. Het gevolg is ongepland meerwerk om alsnog de gevraagde functionaliteit op te leveren. De voorspelbaarheid zegt wat over de mate waarin de organisatie in staat is de impact op resources en systemen juist te beoordelen. Bij een verlaagde voorspelbaarheid lopen wijzigingen uit en is plannen van wijzigingen moeilijker en onnauwkeuriger. Dit ligt in lijn met de afname van de ICT/Business alignement. De business krijgt steeds minder hetgeen zij wenst van ICT. Uiteindelijk wordt een situatie bereikt dat incident en changemanagement niet meer aansluiten op de organisatie en een herinrichting van incident en changemanagement noodzakelijk is. Tijdig herkennen van terugval in maturitiy level voorkomt dat rigoureuze aanpassingen van incident- en changemanagement noodzakelijk zijn. In het volgende hoofdstuk is een methode beschreven waarmee een meting kan worden verricht naar het maturity level van de processen incident- en changemanagement. 6.1 Bepalen maturity van Incident en changemanageme nt Een groot aantal methoden voor het bepalen van de maturity van een proces zijn beschreven op een hoog abstractieniveau en maken geen onderscheid tussen de grootte van een organisatie en de in te richten controls. In vorige hoofdstukken zijn de typeringen van organisaties van verschillende groottes aan de orde geweest, waarbij de terugval in maturity

- 27 -

level door groei is behandeld. Deze terugval ontstaat onder andere doordat geïmplementeerde controls niet meer toereikend zijn. De conclusie kan getrokken worden dat er geen aanwijsbare set van controls is die voor elke organisatie onafhankelijk van de grootte geldt. Bij het herstellen van het maturity level hoort een nieuwe set van controls die bij de grootte van de organisatie past. Om te bepalen welke set van controls past bij de grootte van een organisatie en bij het (gewenste) maturity level zijn de controls gekwantificeerd naar fase van de organisatie en het maturity level. Tabel 7 en 8 in bijlage II geven de gekwantificeerde controls weer. Het uitgangspunt van tabel 7 en tabel 8 zijn de key controls die in hoofdstuk 4.2 en 4.3 zijn gedefinieerd. Bij deze controls zijn een aantal requirements beschreven die in een organisatie van toepassing zijn, afhankelijk van de fase waarin het bedrijf verkeerd en de maturity levels van de processen van ICT. Er is geen literatuur gevonden die op deze manier controls kwantificeert bij grootte en maturity van een organisatie. Wel is literatuur gevonden die de risico’s en problemen kwantificeert. Deze beschreven risico’s zijn als uitgangspunt gebruikt voor het bepalen van de controls en middels deductie van deze risico’s en problemen zijn de controls vastgesteld. Vanuit deze controls zijn de normenkaders samengesteld. Discussie en verder onderzoek is noodzakelijk om deze matrix verder uit te bouwen en te verfijnen. De matrix is gebaseerd op controls uit ITIL en CobiT [4][5][6][7][8][9] en risicomatrixen gebaseerd op maturity modellen [17][18], waarbij de relatie is vastgesteld tussen CobiT en ITIL [16]. De grijsgemaakte vakjes geven weer in welk stadium de requirements niet aanwezig zijn. Bij de fasen (1 t/m 3) van het bedrijf zijn de vakjes grijs gekleurd omdat vanwege de grootte van het bedrijf de requirement niet noodzakelijk is voor een efficiënt en effectief incident en change management. De grijze vakjes bij het maturity level geven aan dat het requirement nog niet is geïmplementeerd. Bij een hoger maturity level is het waarschijnlijk dat het requirement wel is geïmplementeerd. Tabel 9 en 10 geven een uitwerking van het incident en change management volgens de behandelde thema’s van het CobiT maturity level in hoofdstuk 5.3. Hoewel het eenvoudiger is de maturity snel te bepalen via de toegesneden maturity models in CobiT 4.1 (AI6 en DS8) is deze wijze toch uitgewerkt om de koppeling te leggen met de besproken terugval in maturity level en het incident en changemanagement proces.

- 28 -

7.0 Casus Bank X 7.1 Inleiding Casus Bank X Bank X heeft als activiteit het aanbieden van online bankactiviteiten. Bank X kent een onstuimige groei en heeft op het ogenblik ca 350 mensen in dienst waarvan 50 bij ICT werkzaam zijn. Bank X kan gezien worden als een middelgroot bedrijf dat volop innovaties doorvoert en een hoog volatiele ICT omgeving heeft. De laatste tijd wordt Bank X steeds meer geconfronteerd met het feit dat de afdeling ICT niet meer in staat is deze groei bij te benen en het incident- en changemanagement steeds minder functioneren. Het aantal verstoringen is toegenomen en wijzigingen veroorzaken steeds vaker ongepland meerwerk en lopen uit de tijd. De vraag is of de huidige vorm van de implementatie van het changemanagement en het incidentmanagement van deze organisatie nog wel toereikend is voor de grootte van het bedrijf. 7.2 Doel Casus Bank X Het doel van deze casus is het toetsen van het in hoofdstuk 6 opgestelde normenkader aan Bank X. Daarnaast word vastgesteld welke controls voor het changemanagement en incidentmanagement van toepassing zijn in relatie tot de groeifase waarin Bank X nu verkeert. 7.3 Werkwijze Aan de hand van tabel 1, Groeifasen Organisatie, en de behandelde theorie in hoofdstuk 2 wordt vastgesteld in welke groeifase Bank X verkeert. In het normenkader, tabel 7 en 8 worden de aanwezige controls van Bank X geplot. Met behulp van tabel 9 en 10 en de maturity levels in CobIT hoofdstukken AI6 (Manage Changes) en DS8 (Manage Service Desk and Incidents) wordt het maturity level van Bank X vastgesteld en wordt getoetst aan het normenkader. Uit dit normenkader kunnen vervolgens de nodige controls gedestilleerd worden die nodig zijn voor het bereiken van een hoger maturity level. 7.4 Groeifase Bank X Aan de hand van de tabel groeifasen organisatie wordt de groeifase van Bank X bepaald. Bank X heeft een zeer innovatieve periode doorgemaakt waarbij nieuwe producten op de markt zijn gezet en expansie naar het buitenland is gezocht. De ICT richt zich voornamelijk

- 29 -

op deze nieuwe producten en ondersteuning van bedrijfsprocessen speelt een kleine rol. Applicaties voor ondersteuning van bedrijfsprocessen zijn weinig geïntegreerd en de koppeling van data vindt veelal handmatig plaats. De huidige focus van ICT laat zich het best plaatsen in de tweede groeifase. De organisatie van Bank X bestaat uit het bestuur, waaronder de directie plaatsneemt. Teamleiders en managers zijn voornamelijk meewerkend voormannen en zijn vanuit hun kennis op het vakgebied op die positie geplaatst. Wel is een verzuiling in de organisatie waar te nemen naar de verschillende productgroepen die Bank X bedient. De organisatie van de business laat zich het best plaatsen op de rand van fase 2 en 3. Beide typologieën zijn hierin waar te nemen. De ICT organisatie staat duidelijk midden in fase 2. Eén hoofdproduct en specialisten zijn geplaatst als teamleiders. De aansturing is van Bank X laat zich het best plaatsen tussen fase 2 en 3 in. Communicatie is weinig formeel en tussen de afdelingen wordt direct en zonder formele afspraken gecommuniceerd. Wel wordt er op dit moment een inhaalslag gemaakt om communicatie structuren helder en formeler te maken. Communicatie valt het best te plaatsen in fase twee, neigend naar de 3e groeifase. De complexiteit van het kernsysteem waarop de business draait is hoog. Echter opereert kernsysteem solitair en zijn handmatige acties nodig voor de overdracht van data naar ondersteunende bedrijfsprocessen. Acties zijn ontplooid om efficiënter gebruik te maken van beschikbare data. Het huidig gebruik van systemen wijst op een fase 2 organisatie. Door de huidige ontwikkelingen waarbij datasystemen worden gekoppeld zien we typeringen die neigen naar een organisatie in de 3e fase. Kennis en specialisaties binnen de ICT afdeling zijn onderverdeeld naar de verschillende infrastructurele componenten, zoals; netwerk, Windows, desktops en UNIX. Deze afdelingen beheren ook de business applicaties die op de desbetreffende systemen draaien. Hier is geen differentiatie aangebracht. Bij een fase 3 organisatie mag verwacht worden dat differentiatie van specialisaties is aangebracht tussen infrastructurele componenten en applicaties. Bij kennis valt Bank X onder te brengen in fase 2. Tabel 6 op de volgende pagina, dat een direct afgeleide is van tabel 1, wordt gebruikt voor een visuele weergave van de groeifasen in de verschillende aspecten van Bank X. Bank X is voor het grootste gedeelte onder te brengen in fase 2 met neigingen naar fase 3 toe. Volgens de theorie van Greiner is de overgang tussen fase 2 “Aansturing “en 3 “Delegeren” de turbulente evolutie “Autonomie crisis”. Bank X ondergaat nu een turbulente periode die inderdaad kenmerken heeft van de Autonomie crisis.

- 30 -

7.5 Maturity en controls De geïmplementeerde controls voor het incident- en changemanagement voor Bank X zijn bepaald aan de hand van het vastgestelde normenkader. Deze controls zijn geplot in de tabellen 7 en 8 in bijlage IV. Alle aanwezige controls bij Bank X zijn aangegeven met een vinkje. De niet aanwezige controls zijn aangegeven met een kruis. Kijken we goed naar de controls dan valt op dat voornamelijk controls zijn geïmplementeerd die bij een fase 1/2 organisatie horen op een maturity level van 2. Bank X is zelf als organisatie te plaatsen in groeifase 2/3. Daarnaast viel op dat 2 controls wel waren ingericht voor wijzigingen op applicaties, maar niet voor wijzigingen op de infrastructuur. Deze controls zijn zowel aangegeven met een vinkje als een kruis. De maturity levels van incidentmanagement en changemanagement zijn geplot in de tabellen 9 en 10 in bijlage V. Nemen we het CobiT Maturity Model in ogenschouw (bijlage V) dan valt op dat de maturity van de organisatie voornamelijk level 1 ad-hoc is. 7.6 Werking Incident en changemanagement bij Bank X Voor Bank X zijn de in hoofdstuk 4 vastgestelde Key Performance Indicatoren niet te bepalen. Changes en incidenten worden weliswaar vastgelegd in een centrale tool, maar zijn vaak niet als zodanig herkenbaar. Noodzakelijke gegevens worden niet vastgelegd in de tool en registraties worden niet altijd na uitvoering gesloten. De tool wordt voornamelijk als een

- 31 -

communicatiemiddel gebruikt om het werk te verdelen. Op basis van gesprekken met de business en de ICT organisatie zijn de belangrijkste problemen van het incident en changemanagement in kaart gebracht. De belangrijkste tekortkomingen die vanuit de business worden aangegeven zijn:

Incidentmanagement; • Incidenten worden niet in behandeling genomen. • Herhaaldelijk aandringen op het verhelpen van het incident is noodzakelijk. • Oplossingen geven vaak niet het gewenste resultaat. Changemanagement; • Aangevraagde wijzigingen worden niet in behandeling genomen. • Projecten komen niet op tijd af. • De business heeft het gevoel zelf de wijzigingen te moeten sturen.

Daarnaast geeft de business aan dat het niveau van de dienstverlening vanuit de ICT organisatie in de laatste periode is afgenomen. De ICT organisatie zoekt voornamelijk de problemen bij de business, zij geven aan dat:

Incidentmanagement; • Bij elk incident de business over de vloer komt • De business direct ICT medewerkers belt om incidenten aan te melden. • Incidenten oplossen de voornaamste taak is en er niet aan regulier beheer

wordt toegekomen. Changemanagement; • Wijzigingen altijd op het laatste moment worden aangemeld • Er veel te veel wijzigingen zijn. • Projecten niet integraal worden opgepakt.

De ICT organisatie geeft aan dat de laatste tijd zij veel vaker last heeft van ongeplande wijzigingen en er veel meerwerk nodig is om mislukte wijzigingen op te lossen. Het incident en changemanagement beleid en de gebruikte tools binnen de ICT organisatie zijn een aantal jaren geleden ingericht en eigenlijk niet wezenlijk veranderd in de laatste 4 jaar. In deze tijd is Bank X wel zeer snel gegroeid. Het is evident dat de gebruikte tools en het vigerend beleid niet meer aansluiten bij de grootte van de organisatie. 7.7 Conclusie Bank X Bank X heeft de processen en controls ingericht toen het een kleine, maar snel groeiende organisatie was. De toen ingerichte controls en processen sloten aan op de doelstelling en de grootte van het bedrijf die het in die periode had. De controls duiden op een bedrijf in de 1e groeifase met een maturity level van 2. In de huidige situatie bestaan nog steeds deze zelfde controls, maar is het maturity level afgezakt naar 1. Dit ondersteunt de stelling dat met de groei van een organisatie het maturity level afneemt bij een gelijkblijvend control level.

- 32 -

Voor een financiële instelling heeft de DNB een minimaal maturity level van 3 vastgesteld. Uit de tabellen in bijlage IV zijn de controls aangegeven met het symbool � welke nodig zijn voor het bepalen van een maturity level van 3 voor een organisatie in de 3e groeifase. 8.0 Eindconclusie en reflectie 8.1 Conclusie De maturity van de ITIL processen incident en changemanagement is geen statisch gegeven. Er bestaat een relatie met de groei van de organisatie en het maturity level volgens CobiT van incident en changemanagement. Groeiende organisaties nemen in complexiteit toe en geeft een neerwaartse invloed op het maturity level van de processen incident en change- management waarbij het risico op verstoringen ten gevolge van wijzigingen en de oplossingstijd van incidenten toeneemt. De casus van Bank X onderschrijft deze conclusie. Daarnaast is de conclusie te trekken dat een kleine organisatie kan functioneren met een relatief laag maturity level. Een grotere organisatie heeft een relatief hoger maturity level nodig om goed te functioneren. In het tijdig herkennen en onderkennen van een neerwaartse beweging van het maturity level en daarbij gepaard gaande achteruitgang van de dienstverlening van de ICT is een grote rol weggelegd voor de IT-Auditor. In deze scriptie worden aan de IT-auditor een set van hulpstukken aangeleverd maarmee hij kan determineren of de ingerichte controls passen bij het gewenste maturity level en de groeifase van de organisatie. 8.2 Reflectie Tijdens mijn onderzoek ben ik op veel informatie gestuit dat vertelt hoe een hoger maturity level is te bereiken. Ik ben zeer weinig informatie tegengekomen over hoe een bedrijf zijn huidige maturity level kan behouden. Een hoger maturity level is niet altijd gewenst en blijft een afweging van de kosten tegen de baten. Geen informatie ben ik tegen gekomen over de factoren binnen organisaties die een neerwaartse beweging in maturity level kunnen bewerkstelligen. Ik denk dat het te rechtvaardigen is hier meer onderzoek naar te verrichten. Tijdens het onderzoek naar de controls passende bij het maturity level en de groeifase van de organisatie heb ik gemerkt dat er in sommige literatuur onderscheid wordt gemaakt tussen infrastructuur en applicaties. Voornamelijk tussen het 2e en 3e maturity level wordt opgemerkt dat controls wel in plaats zijn voor incidenten en wijzigingen op applicaties, maar nog niet voor incidenten en wijzigingen op de infrastructuur. Dit onderscheidt heb ik bewust niet meegenomen om de lengte en daarmee overzichtelijkheid van de controlematrix niet te verliezen. Bij Bank X bleek dat een aantal controls op applicaties wel en op infrastructuur niet zijn geïmplementeerd. Verder onderzoek in de praktijk zal moeten uitwijzen of dit

- 33 -

gegeven op meer organisaties van toepassing is en een verdere verfijning van de controlematrix nodig is. Verder ben ik mij er van bewust dat de controlematrix niet voor elke organisatie zal gelden. Wel is mijn geloof dat deze controlematrix gekwantificeerd naar maturity level en groeifase een hulp kan zijn in het determineren van maturity gaps in een organisatie en een richting aangeeft op een vrij concreet niveau welke controls noodzakelijk zijn voor een organisatie.

- 34 -

Bijlage I Referenties [1] Larry Y Greiner, “Evolution and Revolution as Organisations Grow”, 1972 [2] Albert Boonstra, “ICT, Mensen en Organisaties: Een Managementbenadering” , 2005 [3] Ole Hanseth, Claudio Ciborra, “Risk Complexity and ICT”, 2007 [4] IIA, “ Global technology Audit Guide; Change and Patch Management Controls:

Critical for Organistional Success”, 2005 [5] ITGI, “ CobiT IT Assurance Guide”, 2007 [6] OGC, “Best Practice for Service Support, ITIL the key to Managing IT Services”,

2000 [7] Norea, PvIB, “Studierapport Normen voor de beheersing van uitbestede ICT-

beheerprocessen”, 2007 [8] Sharon Taylor, Ivor Macfarlane, “ITIL, Small-scale Implementation”, 2005 [9] ITGI, “ CobiT 4.1”, 2007 [10] Warren Harrison, John Settle en David Raffo, “Assessing the Value of Improved

Predictability Due to Process Improvements”, Mei 2001 [11] Dennis R. Goldenson, Diane L. Gibson en Robert W. Ferguson, Presentatie SEI;

“Why make the switch? Evidence about the benefits of CMMI.” , September 2004: 38 http://www.sei.cmu.edu/cmmi/presentations/sepg04.presentations/evidence.pdf [12] Bjorn Cumps, Stijn Viaene, Guido Dedene, Jacques Vandenbulcke, “An Empirical

Study on Business/ICT Alignment in European Organisations”, 2006 [13] Roel Wieringa, Jaap Gordijn en Pascal van Eck, “Value-Based Business-IT Alignment

in Networked Constellations of Enterprises”, 2005 [14] Terry White, “What business really wants from IT, a collaborative guide for business

directors and CIOs”, 2000 [15] Gartner, “Toolkit: Security Program Maturity Timeline Update” , 2007 [16] ISACA, “CobiT Mapping, Mapping of ITIL with CobiT 4.0”, 2007 [17] Prosci, “Prosci’s Change Management Maturity Model”, 2004 [18] GenerationE, “Infrastructure Maturity Matrix”, 2008

- 35 -

Bijlage II Controls in relatie tot groeifase en ma turity Tabel 7: Changemanagement controlematrix Key objective Requirement fase Maturity Key objective Beleid, procedures en standaarden. Key control 1 Het Change management proces is gedocumenteerd en alle verantwoordelijkheden zijn beschreven. Risk - Ongeautoriseerde changes worden doorgevoerd. - Verstoringen door ongeautoriseerde wijzigingen

Change management procedure is vastgelegd.

1 2 3 1 2 3 4 5

Change management procedure is geïmplementeerd in de organisatie en sturing vindt plaats om deze op te volgen.

1 2 3 1 2 3 4 5

Rollen en verantwoordelijkheden zijn vastgelegd met in acht neming van functiescheiding.

1 2 3 1 2 3 4 5

Aparte procedure is vastgesteld voor emergency changes

1 2 3 1 2 3 4 5

Formele externe (naar business toe) communicatiekanalen, overlegstructuren en procedures zijn vastgelegd.

1 2 3 1 2 3 4 5

Formele interne (ICT intern) communicatiekanalen overlegstructuren en procedures zijn vastgelegd.

1 2 3 1 2 3 4 5

Standaard werkbeschrijvingen voor wijzigingen op kritische applicatieve componenten zijn beschreven.

1 2 3 1 2 3 4 5

Standaard werkbeschrijvingen voor wijzigingen op alle, zowel infrastructurele als applicatieve componenten zijn beschreven.

1 2 3 1 2 3 4 5

Een change manager is aangesteld om het wijzigingsproces te coördineren en aan te sturen.

1 2 3 1 2 3 4 5

De bevoegdheden en mandaat van de change manager is formeel vastgesteld.

1 2 3 1 2 3 4 5

Een Change Advisory Board (CAB) is formeel aangesteld.

1 2 3 1 2 3 4 5

Een vergaderschema voor het CAB is vastgelegd en notulen van de vergadering worden vastgelegd.

1 2 3 1 2 3 4 5

Bevoegdheden, mandaat en ingezetene van het CAB zijn formeel vastgelegd.

1 2 3 1 2 3 4 5

Key objective Registratie en tooling Key control 2 Alle wijzigingsverzoeken worden centraal aangenomen en

Alle wijzigingen worden geregistreerd in een daarvoor bestemde tool

1 2 3 1 2 3 4 5

Alle wijzigingen worden centraal geregistreerd en zijn integraal benaderbaar.

1 2 3 1 2 3 4 5

- 36 -

geregistreerd bij een voor de klant bekend loket. Risk - Proces wordt niet gevolgd

Alle wijzigingen worden centraal geregistreerd in geïntegreerde tooling met andere ITIL processen

1 2 3 1 2 3 4 5

Formeel vastgelegd wie wijzigingen mogen aanvragen.

1 2 3 1 2 3 4 5

Changemanagement tools zijn direct gelinkt met configuration-management en de CMDB.

1 2 3 1 2 3 4 5

Tooling wordt effectief ingezet als workflow manager.

1 2 3 1 2 3 4 5

Van alle wijzigingen wordt extra informatie vastgelegd bij registratie, zoals:

• Categorie • Aanvrager • Prioriteit • Effect • Etc.

1 2 3 1 2 3 4 5

Key objective Prioriteit en impact Key control 3 Prioriteit van de wijziging wordt bepaald onafhankelijk van de uitvoerders en de bouwers. Key control 4 Van alle wijzigingsverzoeken wordt de prioriteit van de wijziging en de impact op ICT en organisatie bepaald. Risk - Wijzigingen hebben niet voorziene effecten. - Wijzigingen lopen uit de planning en te weinig resources zijn beschikbaar.

Er is formeel vastgelegd wie prioriteit en impact bepaalt van wijzigingen.

1 2 3 1 2 3 4 5

Van grote wijzigingen op kritische componenten wordt de impact op de ICT en organisatie bepaald.

1 2 3 1 2 3 4 5

Van alle wijzigingsverzoeken wordt de impact op ICT en organisatie bepaald.

1 2 3 1 2 3 4 5

Standaarden zijn ontwikkeld voor het bepalen van de impact van wijzigingen.

1 2 3 1 2 3 4 5

Van alle wijzigingen wordt de urgentie en prioriteit bepaald.

1 2 3 1 2 3 4 5

Formeel is vastgelegd welke functionaris of orgaan de prioriteit van wijzigingen stelt.

1 2 3 1 2 3 4 5

Standaarden voor het bepalen van de prioriteit zijn vastgesteld.

1 2 3 1 2 3 4 5

Randvoorwaarden voor escalatie voor bepalen van prioriteit naar hoger orgaan (CAB, Board) zijn formeel vastgelegd.

1 2 3 1 2 3 4 5

Key objective Autorisatie Key control 5 Wijzigingsverzoeken worden geautoriseerd met in acht name van de impactanalyse. Risk - Geen consensus met de

Alle wijzigingsverzoeken worden geautoriseerd door belanghebbenden voordat deze gebouwd gaat worden.

1 2 3 1 2 3 4 5

Een proces voor de technische goedkeuring van wijzigingen vastgelegd en is gebaseerd op de impactanalyse.

1 2 3 1 2 3 4 5

Een proces voor de financiële goedkeuring van wijzigingen is vastgelegd en gebaseerd op de

1 2 3 1 2 3 4 5

- 37 -

business en andere belanghebbenden

impactanalyse Een proces voor de goedkeuring vanuit de business voor wijzigingen is vastgelegd en gebaseerd op de impactanalyse.

1 2 3 1 2 3 4 5

Formeel is vastgesteld, afhankelijk van de significantie van de impact op welke niveau wijzigingen worden goedgekeurd (CAB, Board).

1 2 3 1 2 3 4 5

Afgekeurde wijzigingen worden helder onderbouwd en worden gecommuniceerd naar de business.

1 2 3 1 2 3 4 5

Key objective Planning Key control 6 Alle wijzigingen worden met in acht name van de impactanalyse en beschikbare resources gepland. Risk - Wijzigingen veroorzaken productieverstoringen. - Wijzigingen interfereren met businessplanning

Wijzigingen worden gepland in overleg met alle belanghebbenden.

1 2 3 1 2 3 4 5

Formele service windows zijn met de klant belegt waarin wijzigingen mogen plaatsvinden.

1 2 3 1 2 3 4 5

Formeel worden service windows bepaald en er wordt pro-actief naar afwijkingen daarop gekeken door acties vanuit de business.

1 2 3 1 2 3 4 5

Formele procedures zijn vastgelegd voor wijzigingen die buiten service windows moeten plaatsvinden.

1 2 3 1 2 3 4 5

Uitloop op de planning wordt formeel naar de business gecommuniceerd.

1 2 3 1 2 3 4 5

Voortgang van de wijziging wordt formeel naar de business gecommuniceerd.

1 2 3 1 2 3 4 5

Formele change cycles zijn opgesteld en een change schedule waarin wijzigingen worden samengevoegd wordt gecommuniceerd naar de business.

1 2 3 1 2 3 4 5

Voor standaardwijziging zijn van te voren criteria en standaardtijden opgesteld.

1 2 3 1 2 3 4 5

Key objective Testen en implementeren Key control 7 Alle wijzigingen worden voor in productiename getest. Key control 8 Testen van geplande wijzigingen vinden onafhankelijk plaats van de bouwers van de wijziging. Risk - Wijzigingen vertonen ongewenste bijeffecten en

Alle wijzigingen worden voor in productiename getest.

1 2 3 1 2 3 4 5

Formeel is vastgelegd wie de wijziging test.

1 2 3 1 2 3 4 5

Testcriteria zijn van te voren opgesteld. Onder de testen vallen: - De software of hardware zelf - Installatiescripts - Afhankelijkheden - Rollback voorzieningen - Documentatie

1 2 3 1 2 3 4 5

Testresultaten worden vastgelegd en formeel goedgekeurd door een onafhankelijke functie.

1 2 3 1 2 3 4 5

- 38 -

verstoren de productie Testplannen zijn formeel goedgekeurd door belanghebbenden.

1 2 3 1 2 3 4 5

Fouten in de testen worden geregistreerd en onafhankelijk beoordeeld (Change manager, CAB) op gevolgen voor implementatie.

1 2 3 1 2 3 4 5

Implementatie op productie gaat in fases waarbij de eerste fasen als testcase worden gebruikt.

1 2 3 1 2 3 4 5

Een separaat platform is ingericht om wijzigingen te testen. Dit platform is een representatieve afspiegeling van productie.

1 2 3 1 2 3 4 5

Key objective Bewaking Key control 9 Het change management proces wordt bewaakt. Bewaken van de voortgang vindt onafhankelijk plaats van de uitvoering. Risk - Wijzigingen worden niet bewaakt - Ongecontroleerde en ongeautoriseerde wijzigingen in productie

Het is formeel vastgelegd welke functie verantwoordelijk is voor het bewaken van het change-management proces en ziet er op toe dat alle stappen in het proces worden juist en volledig doorlopen.

1 2 3 1 2 3 4 5

Bevoegdheden en mandaat van de monitoring functie zijn vastgelegd.

1 2 3 1 2 3 4 5

Kanalen en criteria voor escalatie voor de monitoring functie zijn vastgelegd.

1 2 3 1 2 3 4 5

Indicatoren zijn vastgesteld waarlangs de prestaties van het changemanagement worden gemeten.

1 2 3 1 2 3 4 5

Key objective Afsluiting Key control 10 Wijzigingen worden afgesloten nadat gebleken is dat de wijziging het beoogde resultaat heeft behaald. Risk - Wijzigingen hebben niet het gewenste effect gehad.

Na elk grote wijziging is een nazorgperiode, waarin extra gelet wordt op incidenten als gevolg van de wijziging.

1 2 3 1 2 3 4 5

Incidenten als gevolg van de wijziging worden geëvalueerd en geregistreerd.

1 2 3 1 2 3 4 5

Een evaluatie van de wijziging wordt uitgevoerd om vast te leggen of aan de verwachtingen van de business is voldaan.

1 2 3 1 2 3 4 5

Een evaluatie van de wijziging wordt uitgevoerd om vast te leggen of geen ongewenste bijeffecten zijn opgetreden.

1 2 3 1 2 3 4 5

Kosten en doorloop van de wijziging worden geëvalueerd.

1 2 3 1 2 3 4 5

Wijziging wordt gesloten wanneer de uitkomst van de evaluatie naar tevredenheid is.

1 2 3 1 2 3 4 5

- 39 -

Tabel 8: Incidentmanagement controlematrix Key objective Requirement fase Maturity Key objective Beleid, procedures en standaarden. Key control 1 Het Incident management proces is gedocumenteerd en alle verantwoordelijkheden zijn beschreven. Risk - Geen tijdig herstel van productieverstoringen

Incident management procedure is beschreven.

1 2 3 1 2 3 4 5

Incident management procedure is geïmplementeerd in de organisatie en sturing vindt plaats om deze op te volgen.

1 2 3 1 2 3 4 5

Rollen en verantwoordelijkheden zijn belegt binnen het incident management.

1 2 3 1 2 3 4 5

Er is een duidelijk onderscheidbare functie verantwoordelijk voor het incident management proces.

1 2 3 1 2 3 4 5

Eigenaarschap van incidenten is belegt bij de servicedesk.

1 2 3 1 2 3 4 5

Bevoegdheden en mandaat van de service desk zijn vastgelegd.

1 2 3 1 2 3 4 5

Een dienstenniveau is met de klant formeel afgesproken en vastgelegd.

1 2 3 1 2 3 4 5

Een dienstenniveau is integraal vastgelegd op basis van bedrijfsbehoeften en risico’s en wordt actief beheerd.

1 2 3 1 2 3 4 5

Key objective Registratie en tooling Key control 2 Alle wijzigingsverzoeken worden centraal aangenomen en geregistreerd bij een voor de klant bekend loket. Risk - Incidenten worden niet tijdig opgepakt of dubbel aangemeld en behandeld

Een centraal loket is ingericht waar de klant problemen kan melden.

1 2 3 1 2 3 4 5

Elk incident wordt centraal geregistreerd in een centraal workflow managementtool.

1 2 3 1 2 3 4 5

Vastgestelde en standaard details worden opgenomen in het incident record.

1 2 3 1 2 3 4 5

Incidenten worden gekoppeld aan items in de CMDB, waardoor analyse van trends op systemen mogelijk wordt.

1 2 3 1 2 3 4 5

Key objective Impact en urgentie Key control 3 Van alle incidenten wordt de impact en urgentie in overeenstemming met het afgesproken serviceniveau. Risk - Subjectieve bepalingen van urgenties - Verkeerde urgenties

Impact en urgentie van incidenten worden bepaald.

1 2 3 1 2 3 4 5

Criteria op basis van het afgesproken dienstenniveau voor het geven van urgenties en classificaties aan incidenten is formeel vastgelegd.

1 2 3 1 2 3 4 5

Kanalen en criteria voor escalatie van hoog urgente incidenten zijn vastgelegd en gecommuniceerd naar de business.

1 2 3 1 2 3 4 5

- 40 -

Key objective Uitvoering Key control 4 Uit incidenten voortvloeiende noodzakelijke wijzigingen worden via het change management proces behandeld. Risk - Ongeautoriseerde wijzigingen

Standaard oplossingen worden in een knowledgebase opgenomen.

1 2 3 1 2 3 4 5

Voor standaardincidenten zijn maximale oplostijden afgesproken.

1 2 3 1 2 3 4 5

Een procedure is aanwezig voor escalatie naar het change management proces.

1 2 3 1 2 3 4 5

Key objective Bewaking Key control 5 Bewaken van de voortgang vindt onafhankelijk plaats van de oplosgroep. Risk - Incidenten worden niet tijdig opgelost - Afwijkingen ten opzichte van het afgesproken dienstenniveau worden niet opgemerkt

De servicedesk is verantwoordelijk voor het incidentmanagement en bewaakt de voortgang.

1 2 3 1 2 3 4 5

Terugmelding wordt gegeven wanneer blijkt dat het incident niet tijdig kan worden opgelost

1 2 3 1 2 3 4 5

Criteria voor escalatie bij langdurige oplostijden is opgesteld.

1 2 3 1 2 3 4 5

Key Performance Indicatoren zijn opgesteld en worden gerapporteerd.

1 2 3 1 2 3 4 5

Afwijkingen van het afgesproken dienstenniveau door incidenten worden gerapporteerd.

1 2 3 1 2 3 4 5

Grootschalige incidenten worden achteraf formeel geëvalueerd.

1 2 3 1 2 3 4 5

Trends in het voorkomen van incidenten worden gesignaleerd en geëvalueerd.

1 2 3 1 2 3 4 5

Key objective Afsluiting Key control 6 Afsluiten van een incident vindt plaats nadat is verzekerd da het incident voor de melder naar tevredenheid is opgelost. Risk - Oplossing is niet naar tevredenheid van de klant

Incidenten worden alleen gesloten door de service desk en onafhankelijk van de oplosgroep.

1 2 3 1 2 3 4 5

Voordat het incident gesloten wordt is een analyse van de achterliggende oorzaak van het incident gemaakt.

1 2 3 1 2 3 4 5

Voordat het incident gesloten wordt geconfirmeerd dat het incident naar tevredenheid is opgelost.

1 2 3 1 2 3 4 5

Controle op juistheid en volledigheid van de ingevulde informatie bij incidenten wordt uitgevoerd.

1 2 3 1 2 3 4 5

Incident wordt gesloten. 1 2 3 1 2 3 4 5

41

Bijlage III Cobit Maturity Levels

Tabel 8: Maturity Levels Change Management Level Awareness and

Communication Policies, plans and procedures

Tools and automation Skills and Expertise Responsibility and Accountability

Goal setting and Measurement

1

Aankomende wijzigingen worden alleen gecommuniceerd wanneer deze uitgevoerd moeten worden. Achtergrond informatie wordt niet gegeven.

Een changemanagement procedure is niet aanwezig. Wijzigingen worden ad hoc opgepakt en uitgevoerd.

Wijzigingen worden niet centraal geregistreerd en zijn daardoor niet centraal benaderbaar. Sommige tools kunnen aanwezig zijn, maar worden alleen lokaal gebruikt.

Wijzigingen worden uitgevoerd zonder te kijken of de noodzakelijke kennis om het uitvoeren van de change aanwezig is. Change-management skills zijn niet aanwezig.

Geen personen zijn verantwoordelijk voor of hebben een formele taak binnen change-management.

Geen doelen zijn geformuleerd en wijzigingen worden niet gemonitored. Er zijn geen cijfers over succes of falen van wijzigingen en gerelateerd werk.

2

Sommige grote wijzigingen worden van tevoren gecommuniceerd. Echter De meeste kleine wijzigingen worden niet gecommuniceerd.

Changemanagement procedures zijn aanwezig. Of ze gevolgd worden is afhankelijk van het individu dat de wijziging uitvoert.

Tools worden gebruikt op sleutelplaatsen in het proces, maar worden beheerd door individuen. Lang niet alle wijzigingen worden hierdoor geregistreerd. Een integraal overzicht van wijzigingen is niet uit de tools te halen.

Kennis om wijzigingen uit te voeren berust op individuen. Planning van wijzigingen worden niet aangepast op beschikbaarheid van kennis en hiaten in kennis over de ICT zijn aanwezig. Kennis over change-management zelf is afhankelijk van individuen.

Werknemers voelen zich verantwoordelijk voor de wijziging die zij zelf uitvoeren. Problemen ontstaan als meer expertises noodzakelijk zijn waarbij verwarring ontstaat wie verantwoordelijk is.

Doelen alleen bekend bij hoger management. Wijzigingen worden af en toe gemonitored, afhankelijk van externe factoren.

3

Formele communicatie lijnen zijn aanwezig voor het bespreken van wijzigingen.

Gestructureerde change-management procedures zijn aanwezig en worden gebruikt bij applicatieve wijzigingen. Infrastructurele wijzigingen vallen hier vaak nog niet onder.

Standaard changemanagement tools worden gebruikt. Echter niet geïntegreerd met andere processen zoals incident en configuration management.

Bij wijzigen van de ICT wordt gestuurd op beschikbare kennis over kritische ICT componenten. Kennis van het change management proces is bekend onder managers, projecten en change managers.

Een change manager is verantwoordelijk voor het hele changemanagement proces, maar mist de juiste bevoegdheden om taken volledig te kunnen uitvoeren.

Wijzigingen worden utgevoerd met in acht neming van bedrijfsbehoeften. De performance van change monitoring wordt gemeten, echter nog niet op alle vlakken.

4

Formele communicatie is ingericht op verschillende lagen.

Changemanagement procedures zijn volledig geadopteerd en worden onderhouden.

Standaard changemanagement tools worden gebruikt en zijn geïntegreerd met andere gerelateerde processen. Change-management tools worden gebruikt voor het monitoren en controleren van het proces.

Beschikbaarheid van kennis wordt volledig meegenomen tijdens het plannen van wijzigingen. Training wordt geven aan sleutelpersoneel binnen het changemanagement.

De change manager is verantwoordelijk voor het gehele changemanagement proces en heeft het benodigde mandaat om de taken volledig uit te kunnen voeren.

Wijzigingen worden uitgevoerd waarbij direct gekeken wordt naar bedrijfsbehoeften en strategie. Effectiviteit en efficiëntie van wijzigingen wordt gemeten en gecommuniceerd.

5

Niet alleen wijzigingen zelf worden besproken, maar ook strategische beslissingen in de nabije toekomst die tot wijzigingen op de ICT kunnen leiden.

Changemanagement procedures zijn volledig geïntegreerd binnen het bedrijf en verworden tot standaard workflows.

Changemanagement tools zijn volledig geïntegreerd en het changemanagement wordt volledig gesupport door de tools. Changemanagement gegevens uit de tool worden gebruikt om het proces te verbeteren.

Van te voren wordt nagedacht over de benodigde kennis voor wijzigingen in de toekomst. Werknemers binnen ICT begrijpen het change-management proces en en is meegenomen in het opleidingsplan voor medewerkers.

Changemanagement is volledig doorgevoerd binnen de ICT. Beslissingsbevoegdheden zijn op alle niveaus geformaliseerd en het is duidelijk wanneer escalatie noodzakelijk is.

De efficiëntie en effectiviteit van wijzigingen en de impact op het bedrijf wordt gemeten. Uitkomsten worden gebruikt om het proces verder te verbeteren.

42

Tabel 9: Maturity Levels Incident Management Level Awareness and

Communication Policies, plans and procedures

Tools and automation Skills and Expertise Responsibility and Accountability

Goal setting and Measurement

1

Communicatie met de business is afwezig over lopende incidenten. Incidenten worden voornamelijk via escalatie aangemeld en opgelost. Terugkoppeling over incidenten aan de klant is niet aanwezig. Actie op veel voorkomende incidenten wordt niet ondernomen omdat deze niet besproken worden.

Een incident management procedure is niet aanwezig. Incidenten worden op ad hoc behandelt. Uitkomsten zijn onzeker.

Tooling voor incidenten kan aanwezig zijn maar lokale registratie. Sturing van incidenten over het algemeen niet mogelijk met de tooling,

Incident management skills zijn niet geïdentificeerd. Skills noodzakelijk voor het oplossen van incidenten zijn niet geïdentificeerd. Veel heen en weer sturen van incidenten is het gevolg.

Geen verantwoordelijke is aangesteld voor het incident management. Oppakken van incidenten is op eigen initiatief en verantwoordelijk.

Service levels zijn niet vastgesteld. Geen metingen worden verricht er is niet bekend in hoeverre incidenten de dienstverlening schaden

2

Grote incidenten worden besproken, echter ad-hoc en reactief. Veelvuldige kleine incidenten worden niet besproken. Terugmelding van incidenten wordt door de servicedesk uitgevoerd.

Incident management procedures zijn aanwezig echter dekken niet het hele proces. Coördinatie van incidenten en bewaking is niet aanwezig. Behandeling van incidenten is afhankelijk van individuen en daarom is de urgentie inschatting subjectief.

Tools raken ingeburgerd en worden gebruikt voor het sturen en registreren van incidenten. Tools worde niet ten volle benut en bewaking wordt niet via tools uitgevoerd.

Minimale eisen aan skills worden gesteld, Nog niet geidentificeerd. Incidenten worden veel heen en weer gestuurd.

Verantwoordelijkheid wordt genomen door individuen, formeel is dit niet vastgelegd. Incidenten worden hierdoor onregelmatig opgepakt afhankelijk van oplosgroep en moeilijkheidsgraad.

Minimale service levels zijn besproken op basis van direct merkbare functionaliteit. (Accounts, printers, desktop problemen etc.)

3

Formele communicatie over incidenten achteraf. Terugmelding van incidenten en vertragingen worden vermeld aan de klant.

Gestructureerde incident management procedures zijn beschreven.

Standaard incident management tools worden gebruikt. De tools zijn niet geïntegreerd met andere processen zoals incident en configuration management. Service desk managed incidenten via tooling.

Service Desk is in staat om kleine problemen direct op te lossen. 1e, 2e en 3e lijns helpdesk is aanwezig. Benodigde skills in grote lijnen gedefinieerd voor het oplossen van incidenten.

Incident management (service desk) is verantwoordelijk voor het hele incident management proces. Echter mist het mandaat om te sturen bij vertragingen of problemen.

Service levels zijn geïsoleerd vastgesteld en niet gecommuniceerd naar de business. Verwarring over dienstenniveaus is het gevolg. Bedrijfskritische applicaties zijn geïdentificeerd en service levels zijn gediversifieerd.

4

Communicatie over meerdere niveaus over incidenten. Bij aanmelden wordt direct de verachte oplostijd gecommuniceerd.

Procedures volledig en dekken de hele organisatie. Input vanuit andere processen en gebruik van input is vastgelegd.

Incident management tools zijn gedeeltelijk geïntegreerd met andere processen. Proactief monitoren is mogelijk zodat daadwerkelijke productieverstoringen voorkomen worden.

Klein aantal incidenten worden geëscaleerd naar hogere lijnen voor oplossing.

Incident management (service desk) is verantwoordelijk voor het hele incident management proces. Benodigde mandaat is aanwezig om sturend op te treden.

Service levels zijn volledig en op basis van risico analyses vastgesteld. Achterliggende oorzaken van incidenten worden standaard onderzocht.

5

Communicatie over incidenten op meerder niveaus waarbij change management is geïntegreerd.

Incident management proces van integraal beschreven en verworden tot standaard workfows

Standaard incident tools worden gebruikt en zijn volledig geïntegreerd met andere processen.

Minimaal aantal incidenten worden geëscaleerd naar hogere lijnen voor oplossing.

Incident management is volledig doorgevoerd binnen de ICT. Beslissingsbevoegdheden zijn op alle niveaus geformaliseerd en het is duidelijk wanneer escalatie noodzakelijk is.

Geavanceerde data over performance en events aanwezig, waardoor proactief handelen mogelijk wordt.

43

Bijlage IV Casus Bank X Controls Legenda

� Control is geïmplementeerd

� Control niet geïmplementeerd � Control nodig voor behalen maturity level 3 Tabel 7: Changemanagement controlematrix Key objective Requirement fase Maturity Key objective Beleid, procedures en standaarden. Key control 1 Het Change management proces is gedocumenteerd en alle verantwoordelijkheden zijn beschreven. Risk - Ongeautoriseerde changes worden doorgevoerd. - Verstoringen door ongeautoriseerde wijzigingen

Change management procedure is vastgelegd.

1 2 3 1 2 3 4 5

�

Change management procedure is geïmplementeerd in de organisatie en sturing vindt plaats om deze op te volgen.

1 2 3 1 2 3 4 5

� � Rollen en verantwoordelijkheden zijn vastgelegd met in acht neming van functiescheiding.

1 2 3 1 2 3 4 5

� �

Aparte procedure is vastgesteld voor emergency changes

1 2 3 1 2 3 4 5

� �

Formele externe (naar business toe) communicatiekanalen, overlegstructuren en procedures zijn vastgelegd.

1 2 3 1 2 3 4 5

�

Formele interne (ICT intern) communicatiekanalen overlegstructuren en procedures zijn vastgelegd.

1 2 3 1 2 3 4 5

� �

Standaard werkbeschrijvingen voor wijzigingen op kritische applicatieve componenten zijn beschreven.

1 2 3 1 2 3 4 5

�

Standaard werkbeschrijvingen voor wijzigingen op alle, zowel infrastructurele als applicatieve componenten zijn beschreven.

1 2 3 1 2 3 4 5

�

Een change manager is aangesteld om het wijzigingsproces te coördineren en aan te sturen.

1 2 3 1 2 3 4 5

� �

De bevoegdheden en mandaat van de change manager is formeel vastgesteld.

1 2 3 1 2 3 4 5

�

44

Een Change Advisory Board (CAB) is formeel aangesteld.

1 2 3 1 2 3 4 5

� �

Een vergaderschema voor het CAB is vastgelegd en notulen van de vergadering worden vastgelegd.

1 2 3 1 2 3 4 5

�

Bevoegdheden, mandaat en ingezetene van het CAB zijn formeel vastgelegd.

1 2 3 1 2 3 4 5

�

Key objective Registratie en tooling Key control 2 Alle wijzigingsverzoeken worden centraal aangenomen en geregistreerd bij een voor de klant bekend loket. Risk - Proces wordt niet gevolgd

Alle wijzigingen worden geregistreerd in een daarvoor bestemde tool.

1 2 3 1 2 3 4 5

�

Alle wijzigingen worden centraal geregistreerd en zijn integraal benaderbaar.

1 2 3 1 2 3 4 5

� �

Alle wijzigingen worden centraal geregistreerd in geïntegreerde tooling met andere ITIL processen

1 2 3 1 2 3 4 5

�

Formeel vastgelegd wie wijzigingen mogen aanvragen.

1 2 3 1 2 3 4 5

� �

Changemanagement tools zijn direct gelinkt met configuration-management en de CMDB.

1 2 3 1 2 3 4 5

�

Tooling wordt effectief ingezet als workflow manager.

1 2 3 1 2 3 4 5

� �

Van alle wijzigingen wordt extra informatie vastgelegd bij registratie, zoals:

• Categorie • Aanvrager • Prioriteit • Effect • Etc.

1 2 3 1 2 3 4 5

� �

Key objective Prioriteit en impact Key control 3 Prioriteit van de wijziging wordt bepaald onafhankelijk van de uitvoerders en de bouwers. Key control 4 Van alle wijzigingsverzoeken wordt de prioriteit van de wijziging en de impact op ICT en organisatie bepaald. Risk - Wijzigingen hebben niet voorziene effecten. - Wijzigingen lopen uit de planning en te weinig resources

Er is formeel vastgelegd wie prioriteit en impact bepaalt van wijzigingen.

1 2 3 1 2 3 4 5

� �

Van grote wijzigingen op kritische componenten wordt de impact op de ICT en organisatie bepaald.

1 2 3 1 2 3 4 5

�

Van alle wijzigingsverzoeken wordt de impact op ICT en organisatie bepaald.

1 2 3 1 2 3 4 5

� �

Standaarden zijn ontwikkeld voor het bepalen van de impact van wijzigingen.

1 2 3 1 2 3 4 5

� �

Van alle wijzigingen wordt de urgentie en prioriteit bepaald.

1 2 3 1 2 3 4 5

� �

Formeel is vastgelegd welke functionaris of orgaan de prioriteit van wijzigingen stelt.

1 2 3 1 2 3 4 5

� �

45

zijn beschikbaar. Standaarden voor het bepalen van de prioriteit zijn vastgesteld.

1 2 3 1 2 3 4 5

�

Randvoorwaarden voor escalatie voor bepalen van prioriteit naar hoger orgaan (CAB, Board) zijn formeel vastgelegd.

1 2 3 1 2 3 4 5

�

Key objective Autorisatie Key control 5 Wijzigingsverzoeken worden geautoriseerd met in acht name van de impactanalyse. Risk - Geen consensus met de business en andere belanghebbenden

All e wijzigingsverzoeken worden geautoriseerd door belanghebbenden voordat deze gebouwd gaat worden.

1 2 3 1 2 3 4 5

� �

Een proces voor de technische goedkeuring van wijzigingen vastgelegd en is gebaseerd op de impactanalyse.

1 2 3 1 2 3 4 5

� �

Een proces voor de financiële goedkeuring van wijzigingen is vastgelegd en gebaseerd op de impactanalyse

1 2 3 1 2 3 4 5

� �

Een proces voor de goedkeuring vanuit de business voor wijzigingen is vastgelegd en gebaseerd op de impactanalyse.

1 2 3 1 2 3 4 5

�

Formeel is vastgesteld, afhankelijk van de significantie van de impact op welke niveau wijzigingen worden goedgekeurd (CAB, Board).

1 2 3 1 2 3 4 5

�

Afgekeurde wijzigingen worden helder onderbouwd en worden gecommuniceerd naar de business.

1 2 3 1 2 3 4 5

� �

Key objective Planning Key control 6 Alle wijzigingen worden met in acht name van de impactanalyse en beschikbare resources gepland. Risk - Wijzigingen veroorzaken productieverstoringen. - Wijzigingen interfereren met businessplanning

Wijzigingen worden gepland in overleg met alle belanghebbenden.

1 2 3 1 2 3 4 5

� �

Formele service windows zijn met de klant belegt waarin wijzigingen mogen plaatsvinden.

1 2 3 1 2 3 4 5

�

Formeel worden service windows bepaald en er wordt pro-actief naar afwijkingen daarop gekeken door acties vanuit de business.

1 2 3 1 2 3 4 5

�

Formele procedures zijn vastgelegd voor wijzigingen die buiten service windows moeten plaatsvinden.

1 2 3 1 2 3 4 5

� �

Uitloop op de planning wordt formeel naar de business gecommuniceerd.

1 2 3 1 2 3 4 5

� �

Voortgang van de wijziging wordt formeel naar de business gecommuniceerd.

1 2 3 1 2 3 4 5

�

Formele change cycles zijn opgesteld en een change schedule waarin wijzigingen worden samengevoegd wordt gecommuniceerd naar de business.

1 2 3 1 2 3 4 5

�

46

Voor standaardwijziging zijn van te voren criteria en standaardtijden opgesteld.

1 2 3 1 2 3 4 5

�

Key objective Testen en implementeren Key control 7 Alle wijzigingen worden voor in productiename getest. Key control 8 Testen van geplande wijzigingen vinden onafhankelijk plaats van de bouwers van de wijziging. Risk - Wijzigingen vertonen ongewenste bijeffecten en verstoren de productie

Alle wijzigingen worden voor in productiename getest.

1 2 3 1 2 3 4 5

�/� �

Formeel is vastgelegd wie de wijziging test.

1 2 3 1 2 3 4 5

�/� �

Testcriteria zijn van te voren opgesteld. Onder de testen vallen: - De software of hardware zelf - Installatiescripts - Afhankelijkheden - Rollback voorzieningen - Documentatie

1 2 3 1 2 3 4 5

�

Testresultaten worden vastgelegd en formeel goedgekeurd door een onafhankelijke functie.

1 2 3 1 2 3 4 5

� �

Testplannen zijn formeel goedgekeurd door belanghebbenden.

1 2 3 1 2 3 4 5

�

Fouten in de testen worden geregistreerd en onafhankelijk beoordeeld (Change manager, CAB) op gevolgen voor implementatie.

1 2 3 1 2 3 4 5

� �

Implementatie op productie gaat in fases waarbij de eerste fasen als testcase worden gebruikt.

1 2 3 1 2 3 4 5

�

Een separaat platform is ingericht om wijzigingen te testen. Dit platform is een representatieve afspiegeling van productie.

1 2 3 1 2 3 4 5

�

Key objective Bewaking Key control 9 Het change management proces wordt bewaakt. Bewaken van de voortgang vindt onafhankelijk plaats van de uitvoering. Risk - Wijzigingen worden niet bewaakt - Ongecontroleerde en ongeautoriseerde wijzigingen in productie

Het is formeel vastgelegd welke functie verantwoordelijk is voor het bewaken van het change-management proces en ziet er op toe dat alle stappen in het proces worden juist en volledig doorlopen.

1 2 3 1 2 3 4 5

� �

Bevoegdheden en mandaat van de monitoring functie zijn vastgelegd.

1 2 3 1 2 3 4 5

�

Kanalen en criteria voor escalatie voor de monitoring functie zijn vastgelegd.

1 2 3 1 2 3 4 5

� �

Indicatoren zijn vastgesteld waarlangs de prestaties van het changemanagement worden gemeten.

1 2 3 1 2 3 4 5

�

Key objective Afsluiting Key control 10 Wijzigingen worden afgesloten nadat gebleken is dat de

Na elk grote wijziging is een nazorgperiode, waarin extra gelet wordt op incidenten als gevolg van de wijziging.

1 2 3 1 2 3 4 5

� �

47

wijziging het beoogde resultaat heeft behaald. Risk - Wijzigingen hebben niet het gewenste effect gehad.

Incidenten als gevolg van de wijziging worden geëvalueerd en geregistreerd.

1 2 3 1 2 3 4 5

�

Een evaluatie van de wijziging wordt uitgevoerd om vast te leggen of aan de verwachtingen van de business is voldaan.

1 2 3 1 2 3 4 5

�

Een evaluatie van de wijziging wordt uitgevoerd om vast te leggen of geen ongewenste bijeffecten zijn opgetreden.

1 2 3 1 2 3 4 5

�

Kosten en doorloop van de wijziging worden geëvalueerd.

1 2 3 1 2 3 4 5

� �

Wijziging wordt gesloten wanneer de uitkomst van de evaluatie naar tevredenheid is.

1 2 3 1 2 3 4 5

�

Tabel 8: Incidentmanagement controlematrix Key objective Requiremen t fase Maturity Key objective Beleid, procedures en standaarden. Key control 1 Het Incident management proces is gedocumenteerd en alle verantwoordelijkheden zijn beschreven. Risk - Geen tijdig herstel van productieverstoringen

Incident management procedure is beschreven.

1 2 3 1 2 3 4 5

�

Incident management procedure is geïmplementeerd in de organisatie en sturing vindt plaats om deze op te volgen.

1 2 3 1 2 3 4 5

� �

Rollen en verantwoordelijkheden zijn belegt binnen het incident management.

1 2 3 1 2 3 4 5

� �

Er is een duidelijk onderscheidbare functie verantwoordelijk voor het incident management proces.

1 2 3 1 2 3 4 5

� �

Eigenaarschap van incidenten is belegt bij de servicedesk.

1 2 3 1 2 3 4 5

� �

Bevoegdheden en mandaat van de service desk zijn vastgelegd.

1 2 3 1 2 3 4 5

�

Een dienstenniveau is met de klant formeel afgesproken en vastgelegd.

1 2 3 1 2 3 4 5

� �

48

Een dienstenniveau is integraal vastgelegd op basis van bedrijfsbehoeften en risico’s en wordt actief beheerd.

1 2 3 1 2 3 4 5

�

Key objective Registratie en tooling Key control 2 Alle wijzigingsverzoeken worden centraal aangenomen en geregistreerd bij een voor de klant bekend loket. Risk - Incidenten worden niet tijdig opgepakt of dubbel aangemeld en behandeld

Een centraal loket is ingericht waar de klant problemen kan melden.

1 2 3 1 2 3 4 5

�

Elk incident wordt centraal geregistreerd in een centraal workflow managementtool.

1 2 3 1 2 3 4 5

� �

Vastgestelde en standaard details worden opgenomen in het incident record.

1 2 3 1 2 3 4 5

�

Incidenten worden gekoppeld aan items in de CMDB, waardoor analyse van trends op systemen mogelijk wordt.

1 2 3 1 2 3 4 5

�

Key objective Impact en urgentie Key control 3 Van alle incidenten wordt de impact en urgentie in overeenstemming met het afgesproken serviceniveau. Risk - Subjectieve bepalingen van urgenties - Verkeerde urgenties

Impact en urgentie van incidenten worden bepaald.

1 2 3 1 2 3 4 5

� �

Criteria op basis van het afgesproken dienstenniveau voor het geven van urgenties en classificaties aan incidenten is formeel vastgelegd.

1 2 3 1 2 3 4 5

�

Kanalen en criteria voor escalatie van hoog urgente incidenten zijn vastgelegd en gecommuniceerd naar de business.

1 2 3 1 2 3 4 5

�

Key objective Uitvoering Key control 4 Uit incidenten voortvloeiende noodzakelijke wijzigingen worden via het change management proces behandeld. Risk - Ongeautoriseerde wijzigingen

Standaard oplossingen worden in een knowledgebase opgenomen.

1 2 3 1 2 3 4 5

� �

Voor standaardincidenten zijn maximale oplostijden afgesproken.

1 2 3 1 2 3 4 5

�

Een procedure is aanwezig voor escalatie naar het change management proces.

1 2 3 1 2 3 4 5

� �

Key objective Bewaking Key control 5 Bewaken van de voortgang vindt onafhankelijk plaats van de oplosgroep. Risk - Incidenten worden niet tijdig opgelost - Afwijkingen ten opzichte van het afgesproken dienstenniveau worden niet opgemerkt

De servicedesk is verantwoordelijk voor het incidentmanagement en bewaakt de voortgang.

1 2 3 1 2 3 4 5

� �

Terugmelding wordt gegeven wanneer blijkt dat het incident niet tijdig kan worden opgelost

1 2 3 1 2 3 4 5

� �

Criteria voor escalatie bij langdurige oplostijden is opgesteld.

1 2 3 1 2 3 4 5

�

Key Performance Indicatoren zijn opgesteld en worden gerapporteerd.

1 2 3 1 2 3 4 5

� �

49

Afwijkingen van het afgesproken dienstenniveau door incidenten worden gerapporteerd.

1 2 3 1 2 3 4 5

�

Grootschalige incidenten worden achteraf formeel geëvalueerd.

1 2 3 1 2 3 4 5

� �

Trends in het voorkomen van incidenten worden gesignaleerd en geëvalueerd.

1 2 3 1 2 3 4 5

�

Key objective Afsluiting Key control 6 Afsluiten van een incident vindt plaats nadat is verzekerd da het incident voor de melder naar tevredenheid is opgelost. Risk - Oplossing is niet naar tevredenheid van de klant

Incidenten worden alleen gesloten door de service desk en onafhankelijk van de oplosgroep.

1 2 3 1 2 3 4 5

� �

Voordat het incident gesloten wordt is een analyse van de achterliggende oorzaak van het incident gemaakt.

1 2 3 1 2 3 4 5

�

Voordat het incident gesloten wordt geconfirmeerd dat het incident naar tevredenheid is opgelost.

1 2 3 1 2 3 4 5

� �

Controle op juistheid en volledigheid van de ingevulde informatie bij incidenten wordt uitgevoerd.

1 2 3 1 2 3 4 5

�

Incident wordt gesloten. 1 2 3 1 2 3 4 5

�

50

Bijlage V Maturity Levels Bank X Legenda

Werkelijk maturity level Gewenst Maturity level

Tabel 8: Maturity Levels Change Management Level Awareness and

Communication Policies, plans and procedures

Tools and automa tion Skills and Expertise Responsibility and Accountability

Goal setting and Measurement

1

Aankomende wijzigingen worden alleen gecommuniceerd wanneer deze uitgevoerd moeten worden. Achtergrond informatie wordt niet gegeven.

Een changemanagement procedure is niet aanwezig. Wijzigingen worden ad hoc opgepakt en uitgevoerd.

Wijzigingen worden niet centraal geregistreerd en zijn daardoor niet centraal benaderbaar. Sommige tools kunnen aanwezig zijn, maar worden alleen lokaal gebruikt.

Wijzigingen worden uitgevoerd zonder te kijken of de noodzakelijke kennis om het uitvoeren van de change aanwezig is. Change-management skills zijn niet aanwezig.

Geen personen zijn verantwoordelijk voor of hebben een formele taak binnen change-management.

Geen doelen zijn geformuleerd en wijzigingen worden niet gemonitored. Er zijn geen cijfers over succes of falen van wijzigingen en gerelateerd werk.

2

Sommige grote wijzigingen worden van tevoren gecommuniceerd. Echter De meeste kleine wijzigingen worden niet gecommuniceerd.

Changemanagement procedures zijn aanwezig. Of ze gevolgd worden is afhankelijk van het individu dat de wijziging uitvoert.

Tools worden gebruikt op sleutelplaatsen in het proces, maar worden beheerd door individuen. Lang niet alle wijzigingen worden hierdoor geregistreerd. Een integraal overzicht van wijzigingen is niet uit de tools te halen.

Kennis om wijzigingen uit te voeren berust op individuen. Planning van wijzigingen worden niet aangepast op beschikbaarheid van kennis en hiaten in kennis over de ICT zijn aanwezig. Kennis over change-management zelf is afhankelijk van individuen.

Werknemers voelen zich verantwoordelijk voor de wijziging die zij zelf uitvoeren. Problemen ontstaan als meer expertises noodzakelijk zijn waarbij verwarring ontstaat wie verantwoordelijk is.

Doelen alleen bekend bij hoger management. Wijzigingen worden af en toe gemonitored, afhankelijk van externe factoren.

3

Formele communicatie lijnen zijn aanwezig voor het bespreken van wijzigingen.

Gestructureerde change-management procedures zijn aanwezig en worden gebruikt bij applicatieve wijzigingen. Infrastructurele wijzigingen vallen hier vaak nog niet onder.

Standaard changemanagement tools worden gebruikt. Echter niet ge•ntegreerd met andere processen zoals incident en configuration management.

Bij wijzigen van de ICT wordt gestuurd op beschikbare kennis over kritische ICT componenten. Kennis van het change management proces is bekend onder managers, projecten en change managers.

Een change manager is verantwoordelijk voor het hele changemanagement proces, maar mist de juiste bevoegdheden om taken volledig te kunnen uitvoeren.

Wijzigingen worden utgevoerd met in acht neming van bedrijfsbehoeften. De performance van change monitoring wordt gemeten, echter nog niet op alle vlakken.

4

Formele communicatie is ingericht op verschillende lagen.

Changemanagement procedures zijn volledig geadopteerd en worden onderhouden.

Standaard changemanagement tools worden gebruikt en zijn ge•ntegreerd met andere gerelateerde processen. Change-management tools worden gebruikt voor het monitoren en controleren van het proces.

Beschikbaarheid van kennis wordt volledig meegenomen tijdens het plannen van wijzigingen. Training wordt geven aan sleutelpersoneel binnen het changemanagement.

De change manager is verantwoordelijk voor het gehele changemanagement proces en heeft het benodigde mandaat om de taken volledig uit te kunnen voeren.

Wijzigingen worden uitgevoerd waarbij direct gekeken wordt naar bedrijfsbehoeften en strategie. Effectiviteit en effici‘n tie van wijzigingen wordt gemeten en gecommuniceerd.

5

Niet alleen wijzigingen zelf worden besproken, maar ook strategische beslissingen in de nabije toekomst die tot wijzigingen op de ICT kunnen leiden.

Changemanagement procedures zijn volledig ge•ntegreerd binnen het bedrijf en verworden tot standaard workflows.

Changemanagement tools zijn volledig ge•ntegreerd en het changemanagement wordt volledig gesupport door de tools. Changemanagement gegevens uit de tool worden gebruikt om het proces te verbeteren.

Van te voren wordt nagedacht over de benodigde kennis voor wijzigingen in de toekomst. Werknemers binnen ICT begrijpen het change-management proces en en is meegenomen in het opleidingsplan voor medewerkers.

Changemanagement is volledig doorgevoerd binnen de ICT. Beslissingsbevoegdheden zijn op alle niveaus geformaliseerd en het is duidelijk wanneer escalatie noodzakelijk is.

De effici‘ntie en effectiviteit van wijzigingen en de impact op het bedrijf wordt gemeten. Uitkomsten worden gebruikt om het proces verder te verbeteren.

51

Tabel 9: Maturity Levels Incident Management Level Awareness and

Communication Policies, plans and procedures

Tools and automa tion Skills and Expertise Responsibility and Accountability

Goal setting and Measurement

1

Communicatie met de business is afwezig over lopende incidenten. Incidenten worden voornamelijk via escalatie aangemeld en opgelost. Terugkoppeling over incidenten aan de klant is niet aanwezig. Actie op veel voorkomende incidenten wordt niet ondernomen omdat deze niet besproken worden.

Een incident management procedure is niet aanwezig. Incidenten worden op ad hoc behandelt. Uitkomsten zijn onzeker.

Tooling voor incidenten kan aanwezig zijn maar lokale registratie. Sturing van incidenten over het algemeen niet mogelijk met de tooling,

Incident management skills zijn niet ge•dentificeerd. Skills noodzakelijk voor het oplossen van incidenten zijn niet ge•dentificeerd. Veel heen en weer sturen van incidenten is het gevolg.

Geen verantwoordelijke is aangesteld voor het incident management. Oppakken van incidenten is op eigen initiatief en verantwoordelijk.

Service levels zijn niet vastgesteld. Geen metingen worden verricht er is niet bekend in hoeverre incidenten de dienstverlening schaden

2

Grote incidenten worden besproken, echter ad-hoc en reactief. Veelvuldige kleine incidenten worden niet besproken. Terugmelding van incidenten wordt door de servicedesk uitgevoerd.

Incident management procedures zijn aanwezig echter dekken niet het hele proces. Cošrdinatie van incidenten en bewaking is niet aanwezig. Behandeling van incidenten is afhankelijk van individuen en daarom is de urgentie inschatting subjectief.

Tools raken ingeburgerd en worden gebruikt voor het sturen en registreren van incidenten. Tools worde niet ten volle benut en bewaking wordt niet via tools uitgevoerd.

Minimale eisen aan skills worden gesteld, Nog niet geidentificeerd. Incidenten worden veel heen en weer gestuurd.

Verantwoordelijkheid wordt genomen door individuen, formeel is dit niet vastgelegd. Incidenten worden hierdoor onregelmatig opgepakt afhankelijk van oplosgroep en moeilijkheidsgraad.

Minimale service levels zijn besproken op basis van direct merkbare functionaliteit. (Accounts, printers, desktop problemen etc.)

3

Formele communicatie over incidenten achteraf. Terugmelding van incidenten en vertragingen worden vermeld aan de klant.

Gestructureerde incident management procedures zijn beschreven.

Standaard incident management tools worden gebruikt. De tools zijn niet ge•ntegreerd met andere processen zoals incident en configuration management. Service desk managed incidenten via tooling.

Service Desk is in staat om kleine problemen direct op te lossen. 1e, 2e en 3e lijns helpdesk is aanwezig. Benodigde skills in grote lijnen gedefinieerd voor het oplossen van incidenten.

Incident management (service desk) is verantwoordelijk voor het hele incident management proces. Echter mist het mandaat om te sturen bij vertragingen of problemen.

Service levels zijn ge•soleerd vastgesteld en niet gecommuniceerd naar de business. Verwarring over dienstenniveaus is het gevolg. Bedrijfskritische applicaties zijn ge•dentificeerd en service levels zijn gediversifieerd.

4

Communicatie over meerdere niveaus over incidenten. Bij aanmelden wordt direct de verachte oplostijd gecommuniceerd.

Procedures volledig en dekken de hele organisatie. Input vanuit andere processen en gebruik van input is vastgelegd.

Incident management tools zijn gedeeltelijk ge•ntegreerd met andere processen. Proactief monitoren is mogelijk zodat daadwerkelijke productieverstoringen voorkomen worden.

Klein aantal incidenten worden ge‘sca leerd naar hogere lijnen voor oplossing.

Incident management (service desk) is verantwoordelijk voor het hele incident management proces. Benodigde mandaat is aanwezig om sturend op te treden.

Service levels zijn volledig en op basis van risico analyses vastgesteld. Achterliggende oorzaken van incidenten worden standaard onderzocht.

5

Communicatie over incidenten op meerder niveaus waarbij change management is ge•ntegreerd.

Incident management proces van integraal beschreven en verworden tot standaard workfows

Standaard incident tools worden gebruikt en zijn volledig ge•ntegreerd met andere processen.

Minimaal aantal incidenten worden ge‘sca leerd naar hogere lijnen voor oplossing.

Incident management is volledig doorgevoerd binnen de ICT. Beslissingsbevoegdheden zijn op alle niveaus geformaliseerd en het is duidelijk wanneer escalatie noodzakelijk is.

Geavanceerde data over performance en events aanwezig, waardoor proactief handelen mogelijk wordt.

52