Dit proces maakt onderdeel uit van het operationele procescluster Verbindende processen – uitvoerend niveau. Wijzigingenbeheer is een van de meest bekende en toegepaste processen in de praktijk. Echter, een waarschuwing is op zijn plaats. Doorgaans wordt de ITIL-versie van dit proces gebruikt. Die is wezenlijk anders dan de BiSL-versie, waarop hieronder wordt ingezoomd.

Opmerking: Hieronder worden doel, activiteiten, resultaten en relaties van dit proces kort samengevat. Deze zijn uitgebreider te vinden in boeken die reeds op dit terrein zijn verschenen. Zie hiervoor de pagina boeken op deze website. Wat u in die boeken niet vindt en hieronder wel, zijn de KPI’s, proces- en procedure schema’s en ervaringen c.q. opmerkingen uit de praktijk.

Doel proces Wijzigingenbeheer

Het proces Wijzigingenbeheer heeft als doelstelling te komen tot een juiste besluitvorming aangaande het wijzigen / vernieuwen van de informatievoorziening.

In het proces Wijzigingenbeheer wordt aldus vanuit de klantzijde gekeken naar de reden van de wijziging, voor welke gebruikersgroep de wijziging is bestemd, de prioriteit vanuit de klant gezien, de impact op de eindgebruikersorganisatie en natuurlijk ook naar de kosten / baten analyse. Vanuit IT wordt evengoed naar een wijziging gekeken, maar wel degelijk op een andere wijze. De impact wordt aan de IT-zijde ingevuld als zijnde de impact op de bestaande IT-systemen. Dat is zeker ook een nuttig aspect, maar wel een heel andere invalshoek om een wijziging te beschouwen.
Uiteindelijk is het logischerwijs aan te bevelen een wijziging zowel vanuit de klantorganisatie als vanuit IT te beschouwen en daarna een weloverwogen besluit te nemen. Er is bij het proces Wijzigingenbeheer dus een zeer nauwe relatie met het gelijknamige proces aan de IT-zijde, maar de invulling kent aanzienlijke verschillen.

Activiteiten proces Wijzigingenbeheer

Het proces Wijzigingenbeheer kent samengevat de volgende activiteiten:
1. Inventariseren. Alle gewenste wijzigingen worden verzameld, uit welke bron deze ook afkomstig zijn. Zo is een goed totaaloverzicht te krijgen van alle wensen, of ze nu groot of klein, rijp of groen zijn. Vanzelfsprekend hoort in deze fase een goede registratie daarbij, en ook moeten indieners van de wijzigingen op de hoogte worden gehouden van de voortgang van de besluitvorming
2. Beoordelen / besluiten. De kern van het proces bestaat uit een juiste besluitvorming. Die kan alleen worden gedaan indien de input op orde is: het wijzigingsvoorstel moet compleet en eenduidig zijn, de impact op de gebruikersorganisatie moet zijn bepaald (vergt de aanpassing ook een aanpassing in het werkproces bijv.), wat zijn de kosten (input van IT nodig), wat zijn de verwachte baten?
3. Bewaken. De uitvoering van de activiteiten vinden in processen in het cluster Functionaliteitenbeheer plaats. Vanuit Wijzigingenbeheer wordt de voortgang bewaakt en vindt eventueel bijstelling plaats.

Wijzigingstraject in de praktijk

Een voorbeeld van wijzigingsafhandeling is in dit schema te vinden:

Het schema spreekt grotendeels voor zichzelf. Belangrijk is wel om te beseffen dat hier de activiteiten aan de klantzijde worden benoemd. In de praktijk vervult de Functioneel beheerder vaak een spilrol.

Resultaten proces Wijzigingenbeheer

De resultaten van dit proces zijn:
1. Concrete besluiten (goedgekeurd/afgekeurd/retour afzender i.v.m. onvolledigheid etc.) rondom de ingediende wijzigingsvoorstellen
2. Bewaking van de uitvoering van de goedgekeurde wijzigingen
3. Administratie van alle wijzigingen, de uitgevoerde haalbaarheidsonderzoeken etc.
4. Goede communicatie met zowel indieners van de wijzigingen, IT en eventueel andere betrokkenen.

KPI’s / rapportage items proces Wijzigingenbeheer

Voorbeelden van Key Performance Indicatoren (KPI’s) voor het proces Wijzigingenbeheer zijn:
– Aantal wijzigingen (ingediend, goedgekeurd, succesvol uitgevoerd, bijgesteld, teruggedraaid)
– Aantal wijzigingen die zijn ingediend omdat de oorspronkelijke wijziging niet de gewenste resultaten gaf (kwaliteitscriterium, niet eenvoudig te meten, wel essentieel)
– Aantal wijzigingen die zijn bijgesteld omdat de input achteraf gezien toch niet volledig en/of juist bleek
– Aantal openstaande wijzigingen (werkvoorraad komende periode)
Deze KPI’s kunnen als input dienen voor een rapportage.

Relaties met andere processen

Vanuit diverse andere processen in BiSL komen wijzigingsvoorstellen in Wijzigingenbeheer binnen. Met name zijn te noemen de processen in het cluster Gebruiksbeheer, en vanuit de Sturende laag komen wijzigingsvoorstellen via Behoeftemanagement binnen.

Met het proces Specificeren bestaat een bijzondere en intensieve relatie. Binnen dit proces worden wijzigingsvoorstellen gedetailleerder ingevuld, waardoor binnen Wijzigingenbeheer een beter besluit kan worden genomen. Dit kan indien nodig een itererend proces zijn, waardoor een wijziging meermalen heen en weer gaat voordat een definitief besluit kan worden genomen.

De relatie met het procescluster Sturende processen is eveneens tweeledig. Aan de ene kant leveren de Sturende processen kaders waarbinnen Wijzigingenbeheer opereert: de financiële ruimte die ter beschikking staat, de afspraken die met leveranciers zijn gemaakt, de overall planning. Andersom levert Wijzigingenbeheer terugkoppeling over het daadwerkelijk verloop van wijzigingen en de consequenties hiervan op met name financieel en planningsgebied.

In de praktijk – Wijzigingenbeheer vanuit ITIL ingericht

De meeste bedrijven kennen wel een op een of andere manier ingericht proces Wijzigingenbeheer (of indien u Engelse termen gebruikt: Change Management). Vrijwel altijd is dit dan ingericht volgens een ITIL-achtige wijze. En dat is geen probleem, het is een van de meest gebruikte ITIL-processen en er is ook ruime praktijkervaring mee opgedaan.

Is er dan geen probleem? Toch wel, en dat zit in de insteek van het ITIL-proces Wijzigingenbeheer. Die is echt anders dan van BiSL, waar vanzelfsprekend het klantperspectief nadrukkelijk in aanwezig is. Met andere woorden; binnen BiSL liggen accenten anders, zoals veel meer aandacht voor de intake en uitwerking (“Wat willen we nu eigenlijk aangepast hebben?”), kosten-baten afweging en goede besluitvorming (“We hebben tien wijzigingen op ons lijstje, maar helaas maar geld voor zes…”).

De oplossing: het is natuurlijk niet handig om twee aparte processen Wijzigingenbeheer in te richten. Een combinatie van elementen uit ITIL en BiSL (en als u wilt ook nog uit ASL), is zeker mogelijk. Dan ontstaat één proces met alle activiteiten hierin verenigd en waarin zowel business- als IT-zijde evenwichtig hun rol kunnen invullen.

In de praktijk – De term wijziging in ITIL en BiSL

In de praktijk kan ook nog wel eens discussie ontstaan over wat nu feitelijk een wijziging is en wat niet. Binnen BiSL wordt een wijziging gedefinieerd als een functionele aanpassing van een systeem. Dat is een logische en heldere lijn, die in de praktijk ook goed hanteerbaar is. Het betekent echter wel dat de aanschaf van een aantal extra PC’s of laptops voor een afdeling i.v.m. personeelsuitbreiding in BiSL-termen geen wijziging is. Binnen IT wordt dit echter vaak wel als wijziging gezien, hoewel natuurlijk geen wijziging waar heel veel onderzoek voor nodig is. Veelal worden dit soort wijzigingen binnen IT als standaard-wijziging afgehandeld.

Maar….het punt is dan natuurlijk wel dat een issue dat binnen BiSL niet als wijziging wordt gezien, dat binnen IT wel zo wordt behandeld en andersom kan natuurlijk evengoed. De verwarring kan daarmee behoorlijke vormen aannemen. De beste oplossing is hier om toch tussen business en IT een eenduidige definitie te bepalen betreffende de term wijziging.

Onze aanraders

Het basisboek “BiSL, een framework voor business informatiemanagement” en de bijbehorende courseware kunnen wij van harte aanbevelen. De pocketguide biedt een compact overzicht van het model. Voor de praktijk is de zelfevaluatie een mooi startpunt:

BiSL – Een framework voor business informatiemanagement
 – 2de, herziene druk
Remko van der Pols, Ralph Donatz, Frank van Outvorst
BiSL® – Pocketguide – 2de herziene druk
Remko van der Pols
BiSL Zelfevaluatie
 – BiSL-diagnose voor business informatiemanagement – 2e herziene druk
Ralph Donatz
BiSL® Foundation Courseware
Frank van Outvorst, René Sieders
Cover BiSL 1 versie 3
BiSL – Een Framework voor business informatiemanagement
3e editie
Remko van der Pols, Ralph Donatz, Frank van Outvorst, René Sieders
Cover BiSL1 versie 3 courseware
BiSL® Foundation Courseware
3e editie
Frank van Outvorst, René Sieders
BiSL® next in uitvoering
Yvette Backer, Machteld Meijer