Het cluster Functionaliteitenbeheer is een cluster dat vier processen op uitvoerend niveau omvat. Doel van dit procescluster is het op een gestructureerde manier aanbrengen van wijzigingen in de informatievoorziening. Natuurlijk omvat het aanpassen van de informatievoorziening een flink aantal IT-componenten en -werkzaamheden. Binnen BiSL worden de activiteiten belicht die aan de klantzijde moeten worden uitgevoerd in geval van wijziging van de informatievoorziening.

Positie Functionaliteitenbeheer in BiSL
Positie Functionaliteitenbeheer

Het cluster Functionaliteitenbeheer bevindt zich zoals te zien rechtsonder in het schema. Kern van dit cluster is “changing the business”. Kortom, expliciet is hier de bedoeling de bestaande informatievoorziening aan te passen vanwege veranderende interne behoeften, externe factoren als wetswijzigingen of simpelweg omdat is gebleken dat een aanpassing van de informatievoorziening een beter werkproces mogelijk maakt. Welke aanleiding er ook is voor een wijziging, een gestructureerde aanpak zoals in BiSL beschreven zorgt er mede voor dat wijzigingen binnen tijd/budget worden uitgevoerd en de resultaten ook naar verwachting zijn. Dat dit in de praktijk nog steeds de nodige hoofdbrekens kan kosten mag duidelijk zijn.

Schema cluster Functionaliteitenbeheer

In het cluster Functionaliteitenbeheer zijn de processen Specificeren, Vormgeven niet-geautomatiseerde informatievoorziening, Toetsen en testen en Voorbereiden transitie te onderkennen. Op aparte pagina’s worden deze processen nader uitgewerkt. Via het menu aan de linkerzijde op deze pagina zijn deze te vinden.

Korte beschrijving processen in het cluster Functionaliteitenbeheer

De processen binnen het cluster Functionaliteitenbeheer kennen een behoorlijk nauwe samenhang. Hoewel er wel een volgtijdelijkheid tussen de processen is te onderkennen, zijn sommige activiteiten in de verschillende processen ook itererend (ze worden dus herhaaldelijk in samenhang uitgevoerd).

Het proces Specificeren geeft in de naam al aan welke activiteit de hoofdmoot van dit proces vormt: het helder formuleren van de gewenste wijziging. En deze zodanig eenduidig en gedetailleerd maken dat niet alleen aan de klantzijde geen misverstand over de wijziging meer kan bestaan, maar ook aan de IT-zijde niet. In het proces Wijzigingenbeheer, dat voor Specificeren komt, is een wijziging al zodanig beschreven dat een goed besluit kon worden genomen. Na het proces Specificeren moet de wijziging zodanig zijn beschreven dat een goede uitvoering mogelijk is.

Het proces Vormgeven niet-geautomatiseerde informatievoorziening geeft eveneens in de naamgeving van het proces de kern van de activiteiten al heel goed aan. Een steeds groter deel van de informatievoorziening is geautomatiseerd, maar over het algemeen zijn er toch ook niet-geautomatiseerde delen te onderkennen. Indien het geautomatiseerde deel wordt aangepast, kan dat ook gevolgen hebben voor het niet-geautomatiseerde deel. Te denken is daarbij aan het aanpassen van formulieren, (gebruikers)handleidingen en werkinstructies. Hoewel in de praktijk met name het maken en aanpassen van gebruikershandleidingen nog steeds vaak aan de IT-zijde wordt uitgevoerd, is binnen BiSL terecht de klantzijde gekozen.

Het proces Toetsen en Testen geeft in de naam wederom de inhoud ook alweer goed aan. Testen aan de gebruikerszijde omvat hier expliciet de acceptatietest. Omdat veel bedrijven wel onderscheid maken in verschillende soorten acceptatiestests (gebruikers-, productie-); binnen BiSL wordt uiteraard gedoeld op de gebruikersacceptatietest.

Tot slot in dit procescluster wordt het proces Voorbereiden transitie beschreven. Het woord transitie wordt in BiSL gebruikt om de daadwerkelijke inproductiename van de gewijzigde informatievoorziening mee aan te geven. Bij de voorbereidende werkzaamheden, waar in dit proces sprake van is, wordt uiteraard vooral stil gestaan bij de informatievoorziening richting eindgebruikers en bijvoorbeeld ook bij gegevensconversies.

In de praktijk – Volgorde processen rondom een wijziging

Binnen BiSL zijn er twee procesclusters te vinden die te maken hebben met (functionele) wijzigingen: Verbindende processen (uitvoerend) en Functionaliteitenbeheer. In het basisboek van BiSL zijn deze twee clusters in twee aparte hoofdstukken beschreven.

In de praktijk leidt dat wel eens tot verwarring over de volgorde van de verschillende processen. Deze loopt namelijk door deze twee procesclusters heen. De hoofdvolgorde van een wijzigingstraject loopt als volgt:
1. Wijzigingenbeheer
2. Specificeren
3. Vormgeven niet-geautomatiseerde IV
4. Toetsen en testen
5. Voorbereiden transitie
6. Transitie
Uiteraard is dit de hoofdstroom; er zijn feitelijk dwarsverbanden tussen alle processen te benoemen. Door deze hoofdstroom voor ogen te houden zijn alle activiteiten binnen alle processen echter makkelijker op een rij te zetten en vervolgens te matchen met de processen en activiteiten binnen met name ASL en in iets mindere mate ook met ITIL.

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