Dit proces maakt onderdeel uit van het operationele procescluster Functionaliteitenbeheer. De naam van ook dit proces geeft goed aan wat het takenpakket is: het gedetailleerd uitwerken van de gewenste wijziging(en).
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 Specificeren
Het proces Specificeren heeft als doelstelling het vastleggen van oplossingsrichtingen naar aanleiding van een door Wijzigingenbeheer aangegeven wijzigingsverzoek.
Dit proces zorgt aldus voor een gedetailleerder uitwerking van het wijzigingsverzoek dat door wijzigingsbeheer is goedgekeurd.
Activiteiten proces Specificeren
Het proces Specificeren kent de volgende activiteiten die naar gelang de omstandigheden sequentieel of iteratief kunnen worden doorlopen:
1. Voor zover nog niet eerder (bij het opstellen van de RFC) gedaan: bepalen aanleiding, doelen en randvoorwaarden
2. Bepalen oplossingsruimte
3. Bepalen ICT vereisten
4. Bepalen ICT-oplossing
5. Bepalen impact gebruikersorganisatie
6. Valideren en accorderen
Resultaten proces Specificeren
De resultaten van dit proces zijn:
1. Uitgewerkt vooronderzoek waarin aanleiding, doelen en randvoorwaarden worden aangegeven
2. Oplossingsrichting(en) en gemaakte keuzes
3. De goedgekeurde specificaties
KPI’s / rapportage items proces Specificeren
Voorbeelden van Key Performance Indicatoren (KPI’s) voor het proces Specificeren zijn:
– Aantal opgeleverde specificaties (uitgesplitst naar binnen / buiten afgesproken tijd)
– Aantal aangepaste specificaties naar aanleiding van opmerkingen van de ICT-organisatie i.v.m. onvolledigheid, onduidelijkheid etc.
– Aantal specificaties die nog moeten worden gemaakt ultimo periode (werkvoorraad)
– Aantal onjuiste functionele aanpassingen veroorzaakt door (naar achteraf blijkt) onjuiste / onvolledige specificaties
Deze KPI’s kunnen als input dienen voor een rapportage.
Relaties met andere processen
Uiteraard is er een sterke relatie met het proces Wijzigingenbeheer, omdat dit proces de initiator is van het opstellen van specificaties. Andersom zijn soms specificaties (+ bijbehorende impactanalyse) nodig om een afgewogen beslissing te kunnen nemen. Soms zijn de activiteiten in deze processen dus sequentieel, soms parallel of iteratief. Enige souplesse in de workflow van deze processen is dus wel noodzakelijk.
Het proces Specificeren heeft ook met de andere processen in het cluster Functionaliteitenbeheer vrij sterke relaties. Het proces Vormgeven niet-geautomatiseerde IV zal aan de hand van specificaties het niet geautomatiseerde deel van het systeem verder uitwerken. In Toetsen en testen kunnen de opgestelde specificaties worden gebruikt om te controleren of is gerealiseerd wat werkelijk de bedoeling was en in Voorbereiden transitie kan aan de hand van de specificaties de omvang van de wijzigingen en dus ook de omvang van de transitie worden vastgesteld en daar actie op worden ondernomen.
Verder is uiteraard de IT-leverancier hier een belangrijke relatie omdat deze aan de hand van de specificaties de impact op de applicaties en infrastructuur zal bepalen en het Functioneel ontwerp zal gaan aanpassen.
In de praktijk – Het verschil tussen een RFC en specificatie
Sommigen vragen zich wel eens af wat het verschil is tussen een RFC, die immers ook al voldoende gedetailleerd moet zijn om een beslissing te kunnen nemen, en een specificatie zoals bedoeld in dit proces.
Wel is soms, zeker bij eenvoudige wijzigingen, in de RFC al meteen duidelijk wat er moet worden aangepast en ook hoe en waar. De oplosruimte is vrijwel nihil en de behoefte aan aanvullende specificaties daarmee ook.
Bij meer gecompliceerde wijzigingen kan er echter een groot verschil bestaan tussen de informatie die nodig is voor het nemen van een goed besluit en de informatie die nodig is voor het juist uitvoeren van de wijziging. En daar zit nu precies het verschil tussen een RFC en een Specificatie. Bij een RFC moet de vraag zijn of deze voldoende uitgebreid is om een weloverwogen besluit te nemen. Bij een Specificatie is de vraag of deze zo is uitgewerkt dat de IT-leverancier er mee uit de voeten kan.
In de praktijk – Vorm van een specificatie
Vanwege de sterk uiteenlopende aard van wijzigingen is de vorm waarin specificaties moeten worden opgesteld niet vastgelegd. Daarmee is er dus, afhankelijk van de aard van de wijziging, veel variatie mogelijk. Toch is het aan te bevelen binnen een bedrijf een template te gebruiken waarin specificaties, uitzonderingen daargelaten, passen. Door het gebruik van een template zijn een aantal zaken af te dwingen die van belang zijn bij het verdere gebruik binnen de IT-leverancier. Gedacht hierbij kan worden aan volledigheid (is alles aanwezig, dus is de template volledig ingevuld), juistheid (de ingevulde template kan eenvoudiger door een collega worden gereviewd), voldoende gedetailleerdheid (door de IT-leverancier kan makkelijker in de template worden aangeven waar de specificatie nog te globaal is).
In het algemeen wordt een dergelijke template in de loop van de tijd gevormd door ervaringen in het gebruik. Met andere woorden, in de loop van de tijd evolueert een template naar een vorm die voor iedereen het best werkbaar is. Zeker in de eerste periode van gebruik is dus een flexibele omgang met een eerste versie van een template wel vereist.
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: