Both business and programmers are tempted to fall into the trap of premature precision. Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision simply cannot be achieved, and are often willing to waste a fortune trying to attain it.

Robert C. Martin

De parlementaire onderzoekscommissie (Ton Elias, Paul Ulenbelt, Manon Fokke, Hanke Bruins Slot en Paul van Meenen) kwam tot de conclusie dat de rijksoverheid haar ICT-projecten niet onder controle heeft. Om de besturing en beheersing van ICT-projecten op orde te krijgen stelt (lees: orde in de chaos te brengen) stelt de commissie voor een tijdelijke ICT-autoriteit op te richten: Het BIT (Bureau ICT-toetsing) die alle projecten van de rijksoverheid boven de 5 miljoen euro (waarbij de ICT-component een belangrijke rol speelt) voorafgaand aan een aanbesteding te toetsen op 10 zgn. BIT-regels:

1. Stel een zakelijke rechtvaardiging op waar alle belangrijke onderdelen om een besluit gedegen te kunnen nemen in voorkomen.

2. Toon de meerwaarde van het project aan voor de eindgebruiker en de samenleving.

3. Zorg voor draagvlak bij alle betrokken partijen, inclusief de eindgebruikers, en toets op organisatorische, bestuurlijke en technische haalbaarheid.

4. Reorganiseer en standaardiseer eerst de werkprocessen die met ICT worden ondersteund en ga pas daarna automatiseren.

5. Breng de technische, organisatorische en bestuurlijke risico's en risicomaatregelen in kaart en elimineer «doormodderen» op voorhand.

6. Zorg ervoor dat de verantwoordelijkheid voor het budget én de opdracht bij één persoon liggen.

7. Faseer de ontwikkeling van het ICT-project zo efficiënt mogelijk en probeer daarbij per fase direct bruikbare producten op te leveren.

8. Sluit aan op de standaarden bij de rijksoverheid en toon de technische haalbaarheid aan.

9. Toon aan hoe er van het begin tot het einde van een project voor gezorgd wordt dat kritiek en tegengeluiden mogelijk zijn en ter harte genomen worden. Openheid en transparantie zijn hierbij het uitgangspunt.

10. Neem een heldere aanbestedingsstrategie op in de zakelijke rechtvaardiging.

Ergo: het venijn zit in de start! Zelfs bij ICT-projecten van de rijksoverheid lijkt bezinnen voor het beginnen dé beste insteek. Misschien iets voor een tegeltje....

Zie ook: 8 gouden regels bij IT-investeringen: Raines Rules

Bron: Eindrapport Parlementair onderzoek naar ICT-projecten bij de overheid

In een poging te komen tot een inrichtings-, organisatie-onafhankelijke indeling van de informatievoorziening ('domeinindeling'), was ik me er in eerste instantie niet van bewust dat ik bezig wat met het praktiseren van de strategische BiSL-processen: informatie lifecycle management en informatie portfoliomanagement. Hieronder een selectieve samenvatting van mijn BiSL-samenvatting en een aantal fragmenten uit het boek De functioneel beheerder en BiSL om helder te krijgen hoe een beschrijving van het opdelen van de informatievoorziening in zgn. informatiedomeinen (lees: het opstellen van een informatie-architectuur) past binnen de strategische BiSL-laag.

Binnen de strategische BiSL-processen wordt het procescluster Opstellen informatiestrategie onderscheiden. Dit procescluster heeft als doel het bepalen hoe de toekomstige informatievoorziening er uit gaat zien (waarbij de informatievoorziening op lange(re) termijn de bedrijfsprocessen optimaal blijft ondersteunen) en bestaat uit vijf processen:

1. Bepalen ketenontwikkelingen: inventariseren ontwikkelingen op het gebied van de informatie-uitwisseling met andere organisaties (keten) + het vertalen naar gevolgen voor eigen informatievoorziening.

2. Bepalen bedrijfsprocesontwikkelingen: inventariseren ontwikkelingen in de organisatie en de bedrijfs-processen + het vertalen naar gevolgen voor de informatievoorziening.

3. Bepalen technologie-ontwikkelingen: bepalen welke technische ontwikkelingen interessant kunnen zijn voor de organisatie en informatievoorziening.

4. Informatie lifecycle management: vaststellen van de hoofdlijnen van de (toekomstige functionaliteit van de) informatievoorziening voor een specifiek informatiedomein.

5. Informatie portfoliomanagement: zorg dragen voor een, vanuit bedrijfsbrede optiek, optimale inzet van middelen en opzet en invulling van de informatievoorziening.

Ad (4) Informatie lifecycle management

Informatie lifecycle management heeft als doel het opstellen van een strategie voor de informatievoorziening voor alle specifieke informatiedomeinen (vaak zijn deze gekoppeld aan specifieke bedrijfsprocessen). Voor elk domein wordt vastgesteld wat de behoeften voor beheer, onderhoud en vernieuwing. Bij het bepalen van de behoeften wordt aan de ene kant rekening gehouden met de ontwikkelingen op langere termijn op het vlak van: (a) de bedrijfsprocessen, (b) met de omgeving van de organisatie, en (c) met de technologie. Daarnaast wordt ook rekening gehouden met de huidige staat van de informatievoorziening per domein en de daarbinnen bestaande structurele knelpunten en problemen en het organisatiebeleid. De concrete output van dit proces bestaat uit: (i) een statusrapport (status informatievoorziening per informatiedomein), en (ii) een informatiestrategie (schetsen van toekomstige informatievoorziening + scenario’s per informatiedomein). Het proces informatie lifecycle management geeft dus invulling aan een onderdeel van het totale informatiebeleid van de organisatie, namelijk de toekomstbepaling voor de afzonderlijke onderdelen van de totale informatievoorziening.

Het proces Informatie portfoliomanagement zorgt voor de overkoepelende afstemming over het geheel van de informatievoorziening + het opstellen van een portfolio van alle IV-objecten op hoofdlijnen. Dit resulteert in drie concrete producten: (i) informatiearchitectuur (indeling/structuur informatievoorziening), (ii) informatiebeleid (beleid voor de informatievoorziening), en (iii) een portfolioplanning (incl. besluitvorming over veranderingsbehoeften).

Hét verschil tussen informatie lifecycle management en informatie portfolionmanagement is dan ook dat informatie lifecycle management zich richt op specifieke informatiedomeinen, terwijl informatie portfoliomanagement gericht is op het bepalen van de strategie voor het geheel van de informatievoorziening. De uiteindelijke output van informatie portfoliomanagement is een informatiestrategie met een beschrijving (schets) hoe de informatievoorziening er op lange termijn uit gaat zien per informatiedomein, welke stappen en activiteiten (scenario’s) nodig zijn, wat de impact is voor andere delen van de informatievoorziening (relaties) en inschatting van de kosten en baten.

De overeenkomst tussen beide processen is dat beide zich bezig houden met het opstellen van informatiebeleid. De relatie tussen deze twee ‘informatiebeleidprocessen’ is dat elke voorgestelde strategie voor de informatievoorziening van betrokken informatiedomeinen moet worden afgestemd met het grotere geheel (en dat gebeurt binnen informatie portfoliomanagement). 

Ad (5) Informatie portfoliomanagement

Het proces informatie portfoliomanagement draagt zorg voor een overkoepelende afstemming en uniformiteit over het geheel van de informatievoorziening. Het gaat hierbij om het geheel en samenhang tussen de verschillende delen van de informatievoorziening. Doel van informatie portfoliomanagement is het – vanuit bedrijfsbrede optiek – zorgen voor een optiek optimale inzet van middelen en opzet van de informatievoorziening en het afstemmen van verschillende (deel)plannen voor de toekomstige ontwikkeling van de informatievoorziening. Belangrijk hulpmiddel hierbij is het opstellen en onderhouden van een portfolio met daarin de objecten van informatievooziening op hoofdlijnen (incl. veranderingsbehoefte). Het werken met een portfolio maakt het mogelijk bedrijfsbrede en bedrijfsbreed gedragen beslissingen genomen over uit te voeren veranderingen.

Binnen informatie portfoliomanagement spelen drie hoofdonderwerpen:

(1) Structuur van de informatievoorziening
Het proces informatie portfoliomanagement houdt zich bezig met de structuur van de informatievoorziening door te bepalen op welke wijze de informatievoorziening wordt opgedeeld (in informatiedomeinen) en wat de samenhang (relaties, koppelvlakken) is tussen de verschillende delen: de zgn. informatiearchitectuur. Een informatiearchitectuur kan worden gedefinieerd als een beschrijving/visualisatie van de gehele informatievoorziening waarbij de informatievoorziening is opgedeeld in zgn. informatiedomeinen.

(2) Portfolio: het geheel aan veranderingen in de informatievoorziening
Het proces informatie portfoliomanagement houdt zich – op een overkoepelend niveau – bezig met het afstemmen van alle gewenste en voorgenomen veranderingen voor de gehele informatievoorziening en het waarborgen dat ook in de toekomst een optimale aansluiting tussen de bedrijfsprocessen en de informatievoorziening bestaat.  De kern van portfoliomanagement is het inzichtelijk krijgen van alle veranderingen en oplossingsmogelijkheden op het geheel van de informatievoorziening en het afstemmen over het gehele domein van informatievoorziening heen, welke veranderingen wel doorgezet gaan worden en welke niet.

(3) De gebruikte middelen van de informatievoorziening: standaardisatie
Het proces informatie portfoliomanagement definieert welke afspraken gemaakt worden over de inzet van ICT-hulpmiddelen. Het gaat dan over het opstellen van de infrastructuurarchitectuur en een ontwikkelarchitectuur.

Informatie portfoliomanagement resulteert - in lijn met de drie hoofdonderwerpen - in drie concrete producten:
-    Informatie-architectuur (indeling op hoofdlijnen van de informatievoorziening)
-    Informatiebeleid (beleid ten aanzien van informatievoorziening)
-    Portfolioplanning (besluitvorming grootschalige veranderingsbehoeften)

De richtinggevende processen houden zich bezig met de (middel)lange termijn: binnen deze processen wordt beschreven hoe de informatievoorziening zich de komende drie tot vijf jaar zal (moeten) ontwikkelen. Er wordt ook bepaald, hoe de organisatie van business informatiemanagement zal worden vormgegeven; dat wil zeggen wat voor ondersteuning wenselijk is en hoe dit kan worden gerealiseerd. De processen worden door de informatiemanager uitgevoerd in nauw overleg met iedereen die daarvoor nodig is: zoals business management, bedrijfs- en procesarchitecten en informatiearchitecten, want informatievoorzieningsplannen zijn afgeleid van het bedrijfsbeleid, maar ook IT-serviceverleners zijn bij het opstellen van de strategie betrokken. Meerjarenplannen worden dus gemaakt voor de informatievoorziening en voor de wijze waarop die zal worden ingericht en ondersteund.

(...)

Informatie-lifecylemanagement

Voor specifieke informatiedomeinen (gekoppeld aan bedrijfsprocessen) worden scenario's ontwikkeld. Deze scenario's geven aan hoe de huidige situatie van de informatievoorziening zich in een aantal stappen zal gaan evolueren tot de gewenste informatievoorziening en de bijbehorende systemen die zo nodig ondersteund worden door applicaties. Vanzelfsprekend zullen een globaal beeld van kosten, baten, sterkten, zwakten en ruwe planning niet mogen ontbreken. Kortom, er ontstaat een rapport voor de informatiestrategie.

Informatie-portfoliomanagement

Dit proces dient ervoor om een overkoepelend beeld te krijgen van de ontwikkelingen van de informatiedomeinen, vastgelegd in scenario's. Het resultaat is een portfolio van het geheel van de veranderingen en hun onderlinge samenhang: de portfolioplanning.

Afstemming van de afzonderlijke scenario's vindt plaats waarbij afspraken worden vastgelegd over standaarden en richtlijnen. Het informatiebeleid bevat een compleet beeld ten aanzien van de kosten en baten en bevat ook een overall-planning. Ook een informatiearchitectuur is een resultaat van dit proces.

Er is overleg tussen functioneel beheerder(s) (het uitvoerende niveau), de systeemeigenaar (het sturende niveau) en de informatiemanager (het richtinggevend niveau) over de te verwachten ontwikkelingen in de organisatie en de producten of diensten, zodat (meer-)jarenplannen voor de portfolio van systemen en onderliggende applicaties kunnen worden gemaakt en bijgesteld. Het zal duidelijk zijn, dat bij het opstellen van van de informatiestrategie overleg met de IT-serviceverleners (IT-servicemangement en Applicatiemanagement) noodzakelijk is. De behoeften van de gebruikersorganisatie zijn primair, maar de IT-serviceverleners zijn bij de realisatie betrokken.

Bron: Samenvatting BiSL (incl. mindmap) en De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers

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

Informatieobjecten

Het klassieke begrip document of archiefstuk wordt geassocieerd met de papieren wereld en verwijst naar een specifieke categorie informatieobjecten terwijl er in toenemende mate sprake is van informatieobjecten die niet aan de (traditionele) kenmerken van het begrip document voldoen. Van papieren informatieobjecten geldt dat ze bestaan, dat ze tastbaar en distribueerbaar zijn. In de digitale wereld heeft het begrip document een andere betekenis gekregen. Tekens afgebeeld (in een weblay-out) op een beeldscherm worden ‘digitaal document’ genoemd.

Als je met een pc of een tablet werkt kunnen de gegevens rechtstreeks vanaf het scherm worden gelezen. Als het van het scherm verdwijnt, is het niet (meer) tastbaar. Het ‘digitale document’ leidt derhalve een tijdelijk bestaan. Het digitale document geeft meestal weer hoe het er uit zou zien als het op papier wordt afgedrukt. De termen document en archiefstuk worden overigens niet door iedereen op dezelfde manier gedefinieerd. In het rapport Record Management Terminologie vinden we zestien verschillende definities van het woord document en niet minder dan vierentwintig van het woord ‘archiefbescheiden’.

Definities zijn ook niet altijd eenduidig zoals blijkt uit de definitie die NEN-ISO 15489-1 hanteert: ‘een document is vastgelegde informatie die of een vastgelegd object dat als een eenheid kan worden behandeld.’ In het Engels: ‘recorded information or object which can be treated as a unit.’ Object wordt niet nader gedefinieerd. Is een object geen informatie? Jeurgens et al beschouwen overigens op grond van deze definitie databanken wel ‘als document in de zin van de Archiefwet’.

De definitie van document is volgens de Archiefterminologie ‘het geheel van samenhangende gegevens vastgelegd op een of meer gegevensdragers. Gegevensdrager kan hier gebruikt worden in de vorm van papier of een beeldscherm. In een papieren document zijn inhoud en vorm geïntegreerd. In een digitaal document is dat niet zo. MacKenzie Owen  stelde in 1999 al vast dat in de digitale wereld de koppeling tussen inhoud en vorm verbroken is: ‘Gebruikers kunnen met behulp van technische middelen hun eigen vormgeving creëren.’

In een digitaal document zijn inhoud, structuur en verschijningsvorm niet alleen logisch maar in beginsel ook fysiek gescheiden. Ik vermijd in dit onderzoek het woord ‘document’; ik kies voor het abstracte begrip ‘informatieobject’. Archiefstukken zijn een deelverzameling van informatieobjecten. Zij verschillen van informatieobjecten op een punt; zij kunnen als archivistisch bewijs dienen.

...

Hoogstens maak ik onderscheid tussen een papieren informatieobject en een digitaal informatieobject om het verschil aan te geven tussen ‘iets op p apier’ en ‘iets op een beeldscherm’. Een papieren informatieobject kan ook een afdruk of ‘hardcopy’ zijn van ‘iets op een beeldscherm’. Een papieren informatieobject is een geheel van informatie (met uitzondering van bewegend beeld en geluid) dat is geschreven of afgedrukt op papier. En een digitaal informatieobject is de weergave van een informatieobject op het scherm van een pc of tablet.

Archiefstuk

In de archivistiek wordt onderscheid gemaakt tussen het informatieobject en het archiefstuk. Ik heb eerder aangegeven de voorkeur te geven aan de term informatieobject boven document. Een informatieobject is gedefinieerd als ‘een geheel van gegevens met een eigen identiteit.’ Een archiefstuk is ‘een informatieobject, ongeacht zijn vorm, met de bijbehorende metadata ontvangen of opgemaakt door een natuurlijke en/of rechtspersoon bij de uitvoering van taken [...]’ Ofwel informatie die gebonden is aan een werkproces . De wettelijke term is archiefbescheiden. Een archiefstuk is een informatieobject, maar niet ieder informatieobject is een archiefstuk. Een informatieobject wordt een archiefstuk als het wordt gecreëerd of ont-
vangen bij de uivoering van werkprocessen en als het als bewijs kan dienen voor deze processen. De overgang van informatieobject naar archiefstuk valt samen met de overgang van twee gebruiksniveaus van het Records Continuümmodel. In de eerste dimensie van het Records Continuüm vindt documentatie van de handeling plaats en ontstaat het informatieobject. In de tweede dimensie is een informatieobject een archief stuk dat als bewijs dient.

Een interessant vraagstuk is wat de criteria zijn voor het archiveren van informatieobjecten. Anders gezegd: wat maakt een informatieobject een ‘archiefstuk’? De theorie zegt: archiefbescheiden zijn die bescheiden (informatieobjecten) d
ie ‘naar hun aard’ bestemd zijn te berusten onder de organisatie die ze heeft opgemaakt of die ze heeft ontvangen. De vraag is op basis van welke criteria zijn informatieobjecten ‘naar hun aard’ bestemd zijn te berusten. Anders gezegd, hoe maken we onderscheid tussen informatieobjecten (alles waarvan de organisatie vindt dat het niet hoeft te worden vastgelegd) en archiefstukken (informatieobjecten die vanuit een goed te omschrijven bedrijfsvoerings-, verantwoordings- of bewijsbelang wel vastgelegd en beheerd moeten worden).

Bron: De organisatie van duurzaam digitaal bewijs, Frits Derksen

In de Zembla-uitzending Wie is de mol? wordt de publieke ICT-wereld onderzocht. Conclusie is dat er iets grondig mis is met de hele ICT-branche:

De ICT-markt in de publieke sector is totaal verziekt. Omdat ICT zo verschrikkelijk complex is en je altijd een hocus pocus-verhaal kan vertellen en de mensen die het aanhoren hun gezond verstand uitschakelen, want het gaat over moeilijke dingen, dat - al die dingen samen - leiden tot dit soort wantoestanden.

René Veldwijk

Bron: Zembla-aflevering 2/10/2014: Wie is de mol?

Rob van de Wetering en Gerard van der Zaal definiëren in hun boek Werken onder architectuur een proces als een 'ordening van activiteiten met een expliciet begin en einde, gericht op het doelbewust tot stand komen van een tussen- of een eindresultaat (product) voor een interne of externe klant.' Ze onderscheiden vijf niveaus van processen:

1. Ketenproces: alle werkzaamheden die door een combinatie van (opeenvolgende) bedrijven worden uitgevoerd om voor een (externe) afnemer een eindproduct te realiseren. De betrokken bedrijven vormen samen een bedrijfsketen.

2. Bedrijfsproces: alle werkzaamheden die binnen een bedrijf worden uitgevoerd om voor een in- of externe afnemer een product te realiseren. Een bedrijfsproces valt bestuurlijk onder de verantwoordelijkheid van één lijnmanager (= proceseigenaar) en kan onderdeel zijn van een bedrijfsketen.

3. Werkproces: deel van een bedrijfsproces dat onder verantwoordelijkheid van één operationele manager (= de procesmanager) een concreet (tussen)resultaat oplevert. Deze operationele manager betreft veelal een afdelingshoofd..

4. Processtap: deel van een werkproces dat zonder onderbreking, zonder op een andere actor (mens of machine) te hoeven wachten, door één actor (= procesuitvoerder) op dezelfde plaats kan worden uitgevoerd. Bij een processtap is soms een combinatie van actoren betrokken (medewerker en applicatie, medewerker en klant, klant en internetsite, etc.) maar slechts één hiervan is de initiërende en eindverantwoordelijke actor.

5. Activiteit: kleinste verzameling van werkzaamheden die voor een goed begrip binnen een processtap wordt onderscheiden. Als de activiteit wordt uitgevoerd door een medewerker, spreken we ook wel van een 'handeling'.

Het geheel van procesniveaus noemen Wetering en Van der Zaal de decompositiehiërarchie van processen: een proces op een bepaald niveau is volledig opgebouwd uit processen op het onderliggende niveau. Alle processen op de verschillende hiërarchische niveaus hebben expliciet een begin en een expliciet einde, en leveren een (bijdrage aan het) resultaat voor de afnemer of een andere belanghebbende, zoals de opdrachtgever, de toezichthouder of de aandeelhouder.

(...)

Bedrijfsprocessen

Een bedrijf staat niet op zichzelf, maar bevindt zich in een omgeving die de verwachting heeft bepaalde producten van dit bedrijf te kunnen afnemen. Per definitie start een bedrijfsproces als reactie op een 'event' en heeft een bedrijfsproces de levering van een product tot doel. Een 'event' is een gebeurtenis die plaatsvindt in het leven of de ontwikkeling van een klant (een 'life event') of het passeren van een bepaalde datum (een 'clock event'). Voorbeelden van 'life events' zijn de geboorte, een huwelijk, een ongeval en het winnen van een loterij. Een bedrijf kan op een 'event' reageren, zodra deze daarvan kennis neemt. Dat kan een binnenkomende melding zijn of een waarneming door het bedrijf zelf. Deze melding of waarneming vormt de 'trigger' voor het proces. Door in reactie op het 'event' een bedrijfsproces te starten (via de trigger) en deze volledig uit te voeren, worden een of meer producten geleverd. (...) De afbakening van de bedrijfsprocessen in de procesarchitectuur is er primair op gericht om naar aanleiding van een 'event' (in- en externe) producten te leveren aan van te voren gedefinieerde (in- of externe) afnemers. Deze afbakening is bedoeld om als manager of medewerker op processen te kunnen sturen. De sturing op de processen is bepalend voor de waardering van afnemers (tijdigheid, kwaliteit en kosten). Met de procesafbakening wordt zo een basis gelegd voor een besturingsmodel dat uitgaat van de te onderscheiden product-markcombinaties.

(...)

Werkprocessen

De identificatie en de afbakening van de verschillende bedrijfsprocessen moeten aansluiten op de wijze waarop het bedrijf de buitenwereld van dienst wil zijn. De identificatie en de afbakening van werkprocessen, als eerste decompositielaag binnen de bedrijfsprocessen, worden bepaald door de wijze waarop het werk binnen de muren van het bedrijf uitgevoerd en bestuurd moeten worden. Bij de afbakening van werkprocessen moet de architect, evenals bij de bedrijfsprocessen, de vraag stellen: 'Waarop moet worden gestuurd?' De afbakening van werkprocessen is in principe de eenheid waarop de proceseigenaren afspraken maken met de operationele managers (= procesmanagers).

(...)

De processtappen en activiteiten zijn geen onderdeel van de procesarchitectuur ... maar worden in het procesontwerp vastgelegd.

Zie ook:

• Belangrijke LSS-begrippen - Procesarchitectuur
• Bedrijfsproces-architectuur volgens Dijkman, Vanderfeesten & Reijers
• Procesarchitectuur als veranderinstrument (boekentip)
• Procesarchitectuur volgens GEMMA (1)
• Procesarchitectuur volgens GEMMA (2)
• Procesarchitectuur volgens GEMMA (3)
• Procesarchitectuur volgens Van de Wetering en Van der Zaal (2)

Bron: Werken onder architectuur, Rob van de Wetering en Gerard van der Zaal

In het boek De functioneel beheerder en BiSL gaan Kees Ruigrok en Ernst Bosschers in op de drie vormen van beheer:

Het is gebruikelijk om een onderscheid te maken tussen drie typen van beheer:

1. IT-servicemanagement: beheervorm die verantwoordelijk is voor het tegen overeengekomen kosten en kwaliteit beschikbaar stellen en in stand houden van de technische infrastructuur, waarvan de applicaties gebruik maken, en het leveren van de services die daarvoor nodig zijn.

2. Applicatiemanagement: beheervorm die verantwoordelijk is voor het tegen overeengekomen kosten en kwaliteit in stand houden en onderhouden van de bedrijfsapplicaties en de bijbehorende gegevensverzamelingen tijdens de gehele levenscyclus van de informatiesystemen.

3. Business informatiemanagement: beheervorm die verantwoordelijk is voor het tegen aanvaardbare kosten en kwaliteit in stand houden van de gewenste informatievoorziening ten behoeve van de bedrijfsprocessen van de gebruikersorganisatie tijdens de gehele levenscyclus van die bedrijfsprocessen en het ondersteunen van de gebruikersorganisatie bij de informatievoorziening. Het onderwerp waarop business informatiemanagement zich richt is de functionaliteit van de informatievoorziening.

Deze driedeling is in 1986 gebaseerd door prof. M. Looijen. In bovenstaande figuur zijn de drie typen en hun onderlinge relaties geïllustreerd en in hun omgeving geplaatst.

IT-servicemanagement en applicatiemanagement zijn de twee typen van beheer die zich aan de IT-zijde van de informatievoorziening bevinden. Business informatiemanagement behoort tot de gebruikersorganisatie. De eerste twee kijken met een IT-technische blik naar de infrastructuur, de applicatie en de IT-services, terwijl business informatiemanagement een bedrijfsmatige blik (de gebruikersoptie) heeft op de informatievoorziening.

Business informatiemanagement draagt zorg voor een juiste afstemming van de informatievoorziening op veranderingen in de gebruikersorganisatie die door de omgeving (zoals markten, klanten en producten) worden opgelegd. Ook door veranderende wet- en regelgeving is het vaak nodig om de informatievoorziening aan te passen. Business informatiemanagement draagt zorg voor zowel de geautomatiseerde als de niet-geautomatiseerde informatievoorziening. Een goede afstemming van beide is een belangrijk aandachtspunt. Ook dat is een taak van business informatiemanagement.

(...)

In de omschrijving van business informatiemanagement staat het woord 'informatievoorziening' en niet het woord 'applicaties'. Het werkterrein van business informatiemanagement is niet beperkt tot de geautomatiseerde systemen (de IT), maar strekt zich ook uit over de informatievoorziening (soms afgekort tot IV), die (nog) niet geautomatiseerd is, of niet geautomatiseerd zal worden.

(...)

De drie typen van beheer zijn naast elkaar gezet, maar 'kunnen niet zonder elkaar'. Het maken van het onderscheid helpt om de verantwoordelijkheden duidelijk te maken.

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

Blumenthal beschouwt een organisatie als een open systeem, dat verschillende relaties heeft met zijn omgeving. In de organisatie zelf onderscheidt hij drie deelsystemen: het besturingsysteem, het primaire transformatiesysteem en het informatiesysteem.

Het primaire transformatiesysteem vormt in wezen het bestaansrecht van de organisatie, het bestaat uit de bedrijfsprocessen die producten of diensten aan de omgeving leveren. Het besturingsysteem dirigeert en corrigeert waar nodig de bedrijfsprocessen. Er zijn in de visie van Blumenthal drie niveaus van beslissingscentra: beleid, bestuur en beheer. Deze niveaus komen overeen met wat in de organisatiekundige literatuur als strategisch, tactisch en operationeel wordt aangeduid.

Het informatiesysteem neemt gegevens uit en over de bedrijfsprocessen op, maar vangt ook signalen uit de omgeving op. Het zet deze om in bestuurlijke informatie op grond waarvan het management beslissingen neemt. De aard en de mate van detaillering van de informatie die het besturingsysteem nodig heeft is onder meer afhankelijk van het niveau.

Beheerscentra richten zich doorgaans op een enkel proces, of een deel daarvan en hebben behoefte aan gedetailleerde informatie over de toestand van het betreffende proces. Bestuurscentra zijn vooral coördinerend, ze stemmen aanbod op vraag af, ze zorgen ervoor dat de bedrijfsprocessen onderlinge samenhang vertonen en dat afdelingen van de organisatie de juiste bevoegdheden hebben. Beslissingscentra hebben behoefte aan informatie op hoofdlijnen. Het blikveld van beleidscentra, tenslotte, is breed en alles omvattend. De informatie komt voor een groot deel van buiten de organisatie en is dikwijls informeel van aard.

Bron: Abuysen ende desordiën : archiefvorming en archivering in Dordrecht, 1200-1920, P.J. Horsman