Volgens Kees Ruigrok en Ernst Bosschers speelt business informatiemanagement een sleutelrol bij het voorbereiden, doorvoeren en verifiëren van wijzigingsvoorstellen. Business informatiemanagement bepaalt samen met de gebruikers de eisen, behoeften (requirements) en de prioriteiten en stelt het budget voor de wijzigingen ter beschikking. De systeemeigenaar beoordeelt samen met de functioneel beheerder de business case op basis van de wijzigings- én onderhoudskosten, baten, neveneffecten en risico's. Hierdoor kan de systeemeigenaar een verantwoorde beslissing nemen over de haalbaarheid van het wijzigingsvoorstel.

Er kunnen allerlei redenen zijn om de bestaande infomratievoorziening te wijzigingen. (Zelfs) vanuit de richtinggevende processen (lees: informatiemanagement) kan er een aanleiding ontstaan voor functionele wijzigingen. Wanneer er om strategische redenen nieuwe functionaliteit wordt voorgesteld, wordt dit via het proces Behoeftemanagement (op sturend niveau) geaccordeerd waarna het wijzigingsproces in gang wordt gezet.

Om wijzigingen van de informatievoorziening goed te laten verlopen is een wijzigingsprocedure nodig: "Door een gestandaardiseerde afhandeling gaat dat over het algemeen sneller, is de kwaliteit van de afhandeling controleerbaar en gebeurt dat efficiënter: het behandelen van wijzigingsvoorstellen is beheersbaar."

Allereerst zal een wijzigingsvoorstel in functionele termen moeten worden beschreven: wat wil de gebruikersorganisatie bereiken. Bovenstaand schema geeft weer via welke procedure een wijzigingsvoorstel wordt afgehandeld.

"De eerste beoordeling en filtering van wijzigingsvoorstellen gebeurt meestal door business informatiemanagement. Een wijzigingsvoorstel wordt bijvoorbeeld als niet-zinvol beschouwd, als deze al eens is afgewezen en de reden daarvoor nog steeds actueel is. Maar ook als bij business informatiemanagement bekend is dat in een toekomstige release het voorstel al wordt ingewilligd of al worden achterhaald. De functioneel beheerder moet dus een overzicht hebben van alle wijzigingsvoorstellen. Zowel van de actuele voorstellen als van die uit het verleden. Business informatiemanagement moet de wijzigingsvoorstellen dus beheren, ook de voorstellen die zijn afgewezen. Een gegevensbestand met alle wijzigingsvoorstellen en hun actuele status is daarbij essentieel."

De functionele beheerder overlegt met de systeemeigenaar over de ingediende wijzigingsvoorstellen. Voor elk wijzigingsvoorstel moet er een eigenaar (sponsor) zijn die de business-verantwoordelijkheid draagt. "Tijdens dit overleg zal een business case op hoofdlijnen vastgesteld worden. Een business case op hoofdlijnen moet voldoende duidelijkheid geven over kosten en baten (financieel en niet-financieel) om te beslissen of het wijzigingsvoorstel realistisch is en/of een nader onderzoek zal worden uitgevoerd.

"Voor een realistisch wijzigingsvoorstel wordt een impactanalyse uitgevoerd. Dit betekent dat zowel de kosten als de baten, waarbij de systeemeigenaar verantwoordelijk is voor de inventarisatie van de baten. De IT-dienstverlener zal onderzoeken wat de impact is voor het geautomatiseerde deel van de informatievoorziening, de applicatie-impact. (...) Het uitvoeren van de impactanalyse betreft activiteiten van het proces Specificeren uit het procescluster Functionaliteitenbeheer. Applicatiemanagement voert dit onderzoek uit. Als er ook gevolgen zijn voor de infrastructuur, zal ook IT-servicemanagement hierbij worden betrokken. In veel gevallen is er sprake van een zogenoemd RfP, een Request for Proposal. Daarmee wordt de serviceverlener(s) verzocht een offerte voor de realisatie te doen.

Een wijziging zal vaak gevolgen hebben voor de gebruikersorganisatie, denk aan veranderde procedures, aan extra opleidingen enzovoort. Ook daarvoor wordt een impactanalyse uitgevoerd, de gebruikersimpact. Dit is de verantwoordelijkheid van business informatiemanagement.

Bij grote veranderingen zal business informatiemanagement die impactanalyse laten uitvoeren door een procesanalist of een informatieanalist, eventueel geassisteerd door een AO-adviseur. Dan worden vaak ook informatiemanagers en architecten bij het project betrokken, want een belangrijk aandachtspunt is het onderzoek naar de gevolgen van de wijziging elders in de keten van applicaties of voor andere bedrijfsprocessen.

De gebruikersimpact betreft veel aspecten: het moet COPAFEITHJ-breed worden uitgevoerd. Dit acroniem bestaat uit de beginletters van de onderwerpen waarvan de impact onderzocht moet worden: Commercie, Organisatie, Personeel, Administratie, Financiën, Ecologie/ergonomie, Informatie, Technologie, Huisvesting en Juridisch."

(...)

"Als de gebruikersimpact en de applicatie-impact bekend zijn, zal de business case op hoofdlijnen worden herzien en zal het mogelijk zijn een aangescherpte business case, de uitgewerkte business case, te maken. Deze is dan de basis voor de definitieve beslissing over het wijzigingsvoorstel door de systeemeigenaar."

"Is het wijzigingsvoorstel haalbaar, dan zal het worden voorgedragen aan het releaseoverleg voor invoering. Er wordt vanaf dat moment niet langer per wijzigingsvoorstel gekeken, maar naar alle wijzigingsvoorstellen van een toekomstige release. In veel organisaties is er sprake van een Change Advisory Board (CAB) conform ITIL. Het belang van de gebruikersorganisatie staat bij de beslissingen steeds voorop.

Welke personen aan het releaseoverleg deelnemen, zal per organisatie anders kunnen zijn, maar in ieder geval komen business informatiemanagement, applicatiemanagement en IT-servicemanagement hier samen. Wanneer de rol en samenstelling van het overleg goed beschreven zijn en bij iedereen bekend, is het doorvoeren van wijzigingen beheersbaar. Het releaseoverleg zal vanuit de sturende processen van BiSL een mandaat hebben gekregen over planningen, budgetten en behoeften. Door de IT-serviceverlener wordt een releasemanager verantwoordelijk gesteld voor de coördinatie van de realisatie."

Gedurende zijn bestaan doorloopt een informatiesysteem een aantal stadia. De meeste informatiesystemen doorlopen de stadia meerdere keren voordat ze buiten gebruik worden gesteld. Bovenstaande figuur geeft de betrokkenheid aan van de functioneel beheerder bij de verschillende fasen van de levenscyclus. In de oriëntatiefase is de centrale vraag: 'Waarom wil de gebruikersorganisatie deze verandering en hoe kan ze dit bereiken? "In dit stadium - ook wel definitiestudie of vooronderzoek genoemd - gaat het om twee zaken. Ten eerste worden de behoeften (problemen en kansen) van de organisatie, of een deel daarvan, in kaart gebracht. Ten tweede worden mogelijke oplossingsrichtingen onderzocht en deze worden beoordeeld op haalbaarheid met betrekking tot de business case en tot de gebruikers- en applicatie-impact. Dat onder meer een analyse van de bedrijfsprocessen essentieel is, zal duidelijk zijn.

(...)

Bij de verandering van de informatievoorziening wordt door ASL het woord impactanalyse gebruikt voor de applicatie-impact. De activiteiten van het vooronderzoek maken deel uit van de BiSL-processen Specificeren en Vormgeven niet geautomatiseerde Informatievoorziening.

(...)

De betrokkenheid van de functioneel beheerder is onontbeerlijk tijdens het oriëntatiestadium. Dit geldt ook tijdens het realisatiestadium, onafhankelijk voor welke oplossingsrichting gekozen is. Immers daar waar het gaat om de gebruikersbehoeften en -wensen kan men de functioneel beheerder niet uitsluiten. De functioneel beheerder spreekt namens de systeemeigenaar en de toekomstige gebruikers met applicatiemanagement (de informatieanalisten respectievelijk de functioneel ontwerpers) en brengt de wensen in. ... De functioneel beheerders zijn nauw betrokken bij de stadia Acceptatietest, Implementatie en Gebruik & Evaluatie. Immers, zij bemiddelen tussen (toekomstige) gebruikers en leverancier over de functionaliteit en kwaliteit van de applicatie en de bijbehorende diensten. Het is mede de verantwoordelijkheid van de functioneel beheerder om het resultaat van de acceptatietest te beoordelen en te adviseren aan de systeemeigenaar of tot ingebruikneming kan worden overgegaan.

Ten slotte wordt de applicatie - als onderdeel van de gewijzigde informatievoorziening - in beheer genomen, waarbij de functioneel beheerder verantwoordelijkheid draagt voor een optimale beschikbaarheid van de functionaliteit van de informatievoorziening."

Specificeren

"Het sturende proces Behoeftemanagement zorgt ervoor, dat er voor de informatiebehoeften van de bedrijfsprocessen jaarplannen zijn. Die plannen bevatten nieuwe behoeften, of veranderingen in de bestaande informatievoorziening en applicaties. Die behoeften aan veranderingen zullen leiden tot wijzigingsvoorstellen. Binnen het proces Wijzigingenbeheer worden de wijzigingsvoorstellen gekozen die ingevoerd gaan worden. Behoeftemanagement geeft voor die keuzes de kaders en prioriteiten.

Voor de systeemeigenaar een definitieve beslissing kan nemen over het al dan niet realiseren van een wijzigingsvoorstel moet er een business case op hoofdlijnen zijn. Daarvoor krijgt hij een globaal inzicht in de consequenties (impact) en haalbaarheid van een wijzigingsvoorstel. Voor het bepalen van een business case op hoofdlijnen is een onderzoek nodig. Alle activiteiten van zo'n onderzoek behoren tot het vooronderzoek of de definitiestudie; dat komt overeen met het stadium Oriëntatie. Het proces Specificeren hoort bij dat stadium en dient ervoor om de behoeften te concretiseren, de gewenste doelen duidelijk vast te leggen, de mogelijke oplossingsrichtingen te onderzoeken en de haalbaarheid voor de gebruikersorganisatie te valideren (behoefte, oplossing, validatie).

(...)

De meeste wijzigingsvoorstellen maken een ontwikkeling door, want aanvankelijk zijn ze vaak nog niet duidelijk genoeg geformuleerd. De behoeften (aanleiding, doel en randvoorwaarden) moeten nauwkeurig worden gespecificeerd. Het formuleren van de behoeften moet in functionele termen gebeuren: wat wil de gebruikersorganisatie bereiken? Dat is het eerste doel van het proces Specificeren. Maar er zijn ook randvoorwaarden.

(...)

Tijdens Specificeren wordt het wijzigingsvoorstel nader uitgewerkt. De functioneel beheerder begeleidt de gebruikers bij het nauwkeurig formuleren van de behoeften. Business informatiemanagement (meestal de systeemeigenaar, of een door hem gemandateerde functioneel beheerder) geeft de opdracht aan applicatiemanagement en vraagt aan hen te onderzoeken hoe de eisen in de applicatie kunnen worden gerealiseerd; daarvoor zijn duidelijk vastgelegde behoeften nodig: requirements.

(...)

Het onderscheid tussen gebruikersimpact en applicatie-impact is van belang omdat er bij een oplossing meestal een geautomatiseerd deel en altijd een niet-geautomatiseerd deel is. De applicatie-impact is primair een taak van applicatiemanagement, soms samen met IT-servicemanagement. ... Parallel aan de applicatie-impact wordt de gebruikersimpact uitgevoerd en worden de gevolgen voor de gebruikersorganisatie in kaart gebracht. Daarvoor dient het proces Vormgeven niet-geautomatiseerde informatievoorziening.

Door beide impactanalyses ontstaat duidelijkheid over de vraag of een oplossing realistisch is. ... BiSL gebruikt het begrip niet-geautomatiseerde informatievoorziening voor de gevolgen binnen de gebruikersorganisatie. Het is de taak van de business informatiemanagers om die zijde van de oplossingsrichting te (laten) onderzoeken."

Requirements

Ruigrok en Bosschers onderscheiden twee soorten requirements: functionele requirements en niet-functionele requirement. "Functionele requirements betreffen de gewenste functionaliteit: wat moet de applicatie kunnen doen voor de gebruikers De applicatie bezit de vastgelegde en vanzelfsprekende (!) functies. Vermeden moet worden dat de gebruikersorganisatie de eisen formuleert in de vorm van (technische) oplossingen. Niet-functionele requirements zijn kwaliteitseisen, de eisen die gesteld worden aan het gebruik, zoals verwerkingssnelheid, frequentie van gebruik, vormgeving van de user interface, enzovoort.

(...)

Bij het formuleren van requirements is het belangrijk het volgende onderscheid te maken: (i) business requirements (beschrijven de behoeften geformuleerd vanuit de businessdoelen), en systeemrequirements (beschrijven wat van een applicatie wordt verwacht).

(...)

Goede business requirements identificeren behoeften van de organisatie en moeten afleidbaar zijn uit de business strategie. De businessstrategie is de manier waarop de organisatie haar doelen wil bereiken. Door het proces Behoeftemanagement ligt er een jaarplan voor de informatievoorziening."

Releasematig werken

De frequentie waarmee bedrijfsprocessen moeten worden aangepast aan veranderingen in de omgeving is steeds hoger geworden. Vandaar ook dat de ondersteunende informatievoorziening bijna continu aan verandering onderheving is. (...) Het is belangrijk, dat er een bepaalde rust is in de werkomgeving. Als de stroom van wijzigingen niet wordt beheerd en gereguleerd, worden de gebruikers en beheerders continue met veranderende applicaties en werkinstructies geconfronteerd. Daarom werken de meeste organisaties releasematig.

Een release is een nieuwe of gewijzigde applicaties en/of IT-infrastructuur met bijbehorende documentatie en werkinstructies, die op een beheerste manier als een eenheid wordt ingevoerd in de gebruikersomgeving. Releasematig werken houdt in dat met een vaste frequentie wijzigingen, aanvullingen en verbeteringen worden doorgevoerd in de informatievoorziening. De systeemeigenaar spreekt vooraf een releasekalender af met applicatiemanagement en IT-servicemanagement. Dit betekent voor zowel business informatiemanagement (met name de functioneel beheerder) als voor de gebruikers ene periode van stabiliteit in de informatievoorziening tussen de releasedata.

Bron: De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers