Zaakgericht werken is een procesgerichte manier van werken met digitale uitvoering van de ondersteunende informatievoorziening als uitgangspunt. Het wordt vooral toegepast bij dienstverleningsprocessen en maakt dan twee verbeteringen mogelijk:
• intern: de aansturing van het werk en de bewaking van de voortgang, en dat door het krijgen van overzicht van het werk en inzicht in de voortgang;
• extern: de dienstverlening, en dat door de voortgang te bewaken waardoor er op tijd wordt geleverd, én door de klant met statusinformatie inzicht te geven in de voortgang van zijn zaak.

Wat is zaakgericht werken?
Een zaak is een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en een welgedefinieerd eindresultaat, waarvan kwaliteit en doorlooptijd bewaakt
worden. ... Een organisatie kan zaakgericht werken heel uitgebreid invullen tot en met het volledig herontwerpen van bestaande werkprocessen. Maar de kern ervan is:

1. Uit te voeren werk wordt benoemd als een zaak met een begin en een einde en die zaak wordt als zodanig geregistreerd.

2. Tussen begin en einde wordt het werkproces verdeeld in een aantal fasen of processtappen, zeg maar brokstukken werk. Elke fase heeft een statusaanduiding. Een simpel voorbeeld bij dienstverlening is de reeks ‘aanvraag ontvangen’, ‘aanvraag toegewezen aan afdeling’, ‘aanvraag in behandeling genomen’ en ‘aanvraag afgehandeld’. Zodra een nieuwe fase wordt bereikt of start, wordt dat digitaal vastgelegd als statusinformatie.

3. Intern wordt de statusinformatie gebruikt om de voortgang te bewaken en het werkproces aan te sturen en extern om de klant te informeren over de voortgang van zijn zaak, bijvoorbeeld de behandeling van een aanvraag.

4.  Alle informatie die relevant is voor een zaak, wordt gebundeld in een zaakdossier.


Wat is een zaakdossier?
Een zaakdossier is de bundeling van alle voor een zaak relevante informatie. Informatie is relevant voor een zaak als deze voor kortere of langere tijd beschikbaar moet zijn om het werkproces te ondersteunen en/of als deze nodig is om de zaak later te kunnen reconstrueren, bijvoorbeeld om verantwoording af te leggen over het handelen van de organisatie.

Zie ook: Zaakgericht werken volgens Adrie Spruit (1)

Bron: Wat hoort er in een zaakdossier en wat zijn de bronnen? Adrie Spruit, in: Od #10 2012

Basisprogrammatuur

De verzameling programmatuur die samen met de apparatuur en de communicatievoorzieningen de technische infratstructuur vormt.

• Besturingssoftware
• Programmeringssoftware
• Productiebesturingssoftware
• Utility software
• Beveiligingssoftware
• Datbabase-managementsysteem

Alias: systeemprogrammatuur, systeemsoftware

Communicatievoorzieningen

Deel van de technische infrastructuur dat wordt gebruikt voor het onderling uitwisselen van gegevens tussen verschillende computersystemen.

Gegevensverzamelingen

Verzameling gegevens met een bepaalde samenhang.

Informatiesysteem

Het geheel van technische infrastructuur, applicaties en technische voorzieningen (samen informatietechnologie geheten) en de mensen ter besturing en ondersteuning van de bijbehorende bedrijfsprocessen.

Informatietechnologie

Het geheel van te beheren objecten benodigd voor het beschikbaar stellen van een of meerdere informatiesystemen.

Technische infrastructuur

Alle gemeenschappelijk te gebruiken of te coördineren automatiseringsmiddelen voor het kunnen opslaan, bewerken en transporteren van gegeven en het voorzien van informatie.

Technische voorzieningen

Het geheel van voorzieningen op het gebied van beveiliging, brandpreventie, huisvesting, elektriciteit en koeling, noodzakelijk om applicaties in combinatie met de technische infrastructuur te laten functioneren.

Toepassingsprogrammatuur

Programmatuur die ten behoeve van de gebruiker wordt beheerd en beschikbaar gesteld.

Alias: applicatiesoftware

Bron: Compendium IT Beheer - een verklarend begrippenkader

In het artikel Valkuilen bij het modelleren van bedrijfsprocessen - Toestanden vermijden met toestanden (1998) bepleiten Wil van der Aalst en Jaap Rigter dat het modelleren van processen foutieve of inefficiënte processen kan helpen voorkomen. Voorwaarde hierbij is dat binnen de procesmodellering expliciet aandacht wordt besteed aan:  (a) het modelleren van toestanden en, (b) gebruik van goede analysetechnieken. Volgens Van der Aalst en Rigter is de techniek van Petri-ntten een goed hulpmiddel.

Hieronder een aantal fragmenten uit het artikel die nog steeds relevant zijn voor het ondersteunen en analyseren van processen:

Tot voor kort werden informatiesystemen vooral gebruikt ter ondersteuning van individuele taken. Het komt echter steeds vaker voor dat een informatiesysteem het bedrijfsproces zelf moet ondersteunen. Het gaat hierbij vooral om de logistieke besturing van het proces: het informatiesysteem bepaalt welke taken er uitgevoerd moeten worden, in welke volgorde en door wie. (...) Tot voor kort waren er echter weinig generieke gereedschappen voor het ondersteunen van de logistieke besturing van bedrijfsprocessen. Hierdoor zijn er veel informatiesystemen gebouwd waarin het proces verborgen is in de code van de diverse applicaties. Indien bijvoorbeeld twee taken na elkaar uitgevoerd moeten worden, stuurt de applicatie ter ondersteuning van de ene taak een signaal naar de applicatie ter ondersteuning van de andere taak. De ene applicatie moet dus op de hoogte zijn van het bestaan van de andere. Dit is niet gewenst, omdat het niet mogelijk is het onderliggende bedrijfsproces aan te passen zonder ook de applicaties aan te passen.
Er zijn meer nadelen verbonden aan het 'verstoppen' van het bedrijfsproces in de applicaties. Zo is het niet mogelijk om op een generieke manier managementinformatie te verzamelen en het proces bij te sturen. Ook worden stukjes functionaliteit op meerdere plaatsen gerealiseerd en wordt hergebruik onvoldoende ondersteund.

Volgens Van der Aalst en Jaap Rigter zijn er een aantal gereedschappen op de markt gekomen voor het ondersteunen van bedrijfsprocessen:

Voor de administratieve organisatie zijn er workflowmanagement-systemen ontwikkeld. Een wfm-systeem is een pakket ter ondersteuning van het ontwerp, de analyse, de besturing, de registratie en de uitvoering van werkstromen. Banken, verzekeringsmaatschappijen en overheidsinstellingen zijn de organisaties waar dergelijke systemen op dit moment worden toegepast. Ook voor de meer industriële omgevingen zijn gereedschappen ontwikkeld ter ondersteuning van de logistieke besturing van bedrijfsprocessen. In deze omgevingen worden vaak systemen voor enterprise resource planning (erp) gebruikt....

Dit artikel concentreert zich op twee belangrijke eisen waaraan een procesmodelleringstechniek moet voldoen. Enerzijds moeten toestanden expliciet gemodelleerd worden. Verder zijn goede analysetechnieken essentieel.

(...)

Het belang van 'toestanden'

In een bedrijfsproces moeten er voor elke casus, zoals een bestelling of een verzekeringsclaim, taken worden uitgevoerd, bijvoorbeeld 'controleer polisgegevens'. Met behulp van een procesmodelleringstechniek is aan te geven welke taken er uitgevoerd moeten worden en in welke volgorde. We spreken in dit verband ook wel over routering. De WfMC onderkent de volgende routeringsvormen: sequentiële, parallelle, conditionele en iteratieve routering. De meeste wfm-systemen ondersteunen deze vier routeringsvormen.

(...)

Voor het modelleren van bedrijfsprocessen is het expliciet onderkennen van toestanden echter van het grootste belang. Er is een aantal goede redenen voor het expliciet modelleren van toestanden. In de eerste plaats hebben toestanden meestal een duidelijke betekenis die helder en zinvol is voor de personen die participeren in het proces. Een bestelling kan bijvoorbeeld in de toestand 'geaccepteerd' zijn; bepaalde taken mogen alleen uitgevoerd worden indien de bestelling in deze toestand is. Met name in omgevingen waar men te maken heeft met stringente regelgeving is het onderkennen van toestanden zinvol. Binnen veel overheidsinstellingen heeft men bijvoorbeeld te maken met wettelijke toestanden. Ook vanuit een logistiek standpunt is het onderkennen van toestanden van belang. De doorlooptijd van een casus is vaak vele malen groter dan de tijd die feitelijk besteed wordt aan de casus. Het afhandelen van een belastingaangifte kost bijvoorbeeld weken terwijl de feitelijke bedieningsduur misschien maar enige minuten is. Dit betekent dat een casus meestal in rusttoestand is. Het is dus merkwaardig om juist dit aspect niet expliciet te modelleren. Ook zijn bepaalde routeringsvormen niet of moeilijk te modelleren indien men abstraheert van toestanden.

(...)

Ook het modelleren van mijlpalen is niet mogelijk zonder het expliciet opnemen van toestanden in het procesmodel.

(...)

Het expliciet onderkennen van toestanden is ook van belang zodra wfm-systemen gaan samenwerken. Voor het overhevelen van een casus van het ene naar het andere systeem is het immers noodzakelijk dat de toestand op een eenduidige wijze geëxporteerd kan worden.

Het op een verantwoorde wijze invoeren en/of veranderen van processen vraagt om een grondige analyse vooraf. Volgens Van der Aalst en Rigter zijn er drie vormen van het analyseren van processen:

1. Validatie: proefondervindelijk vaststellen of het proces correct gemodelleerd is. Bij validatie worden een aantal typische cases doorlopen. Validatie wordt vooral gebruikt om vast te stellen of de werking van het proces overeenkomt met het verwachtingspatroon van de gebruikers.

2. Verificatie: volledig controleren op logische fouten. Elk bedrijfsproces moet voldoen aan een aantal basisvoorwaarden. Zo heeft elk proces waarin een casus afgehandeld wordt een begin- en eindpunt. Elke casus die start in het beginpunt moet na verloop van tijd terechtkomen in het eindpunt. Op het moment dat het eindpunt bereikt is, moet de casus volledig afgehandeld zijn. Ook mogen er geen 'dode' taken zijn, dat wil zeggen taken die nooit uitgevoerd kunnen worden. Voor verificatie is het nodig dat bewezen kan worden dat het proces deze essentiële eigenschappen bezit.

3. Prestatie-analyse: onderzoeken of er knelpunten in het procesontwerp zitten die leiden tot lange doorlooptijden of een ineffectieve inzet van capaciteit. De prestatie-analyse van een proces richt zich op een aantal prestatie-indicatoren zoals gemiddelde doorlooptijd, gemiddelde wachttijd, gemiddelde bewerkingstijd, gemiddelde bezettingsgraad, en het percentage dat binnen een bepaalde tijd kan worden afgehandeld (serviceniveau).

Valkuilen bij het modelleren van bedrijfsprocessen - Toestanden vermijden met toestanden, Wil van der Aalst & Jaap Rigter

Het tolmodel van Oscar van Leeuwen (1996) gaat in op de factoren  die  van invloed zijn op de  informatiebehoefte  van  het  management, voor zover er informatiebehoefte is voor het nemen van periodieke besluten. Anders gezegd: het tolmodel van Oscar van Leeuwen legt expliciet de link tussen de kenmerken van de organisatie en de vorm en inhoud van de managementinformatie.

Volgens Van Leeuwen worden de vorm en inhoud van managementinformatie bepaald door zeven factoren:

1. Missie.

2. Kritieke succesfactoren.

3. Doelen.

4. Doelstellingen.

5. Aard proces & structuur.

6. Managementstijl.

7. Cultuur.

Het tolmodel bestaat uit twee piramides die met elkaar verbonden zijn door een tussenlaag. De bovenste, rechtop staande, piramide geeft de zogenaamde 'harde' onderdelen van het tolmodel weer. Deze onderdelen zijn duidelijker en rationeler te omschrijven en/of te kwantificeren dan de onderste. Het 'tussenstuk' vormt de verbinding met de onderstaande, omgekeerde, piramide, bevat de 'zachte' onderdelen. Di betreft de niet-kwantificeerbare, wat vagere en moeilijker vast te stellen onderdelen: managementstijl en cultuur.

De bestuurlijke informatieverzorging is primair gericht op het verstrekken van informatie aan mensen in organisaties die op grond daarvan hun werk kunnen doen. Bij het vormgeven (inrichten) van een systeem voor de bestuurlijke informatieverzorging is daarom de eerste vraag die beantwoord moet worden: welke informatiebehoeften bestaan in de organisatie ofwel welke informatie is nodig?

(...)

Het blijkt dat de informatiebehoeften worden bepaald door zoveel factoren dat het moeilijk is om door de bomen het bos te zien. Met het oog daarop is het tolmodel ontwikkeld. Dit model brengt alle factoren die bij het vaststellen van de informatiebehoeften in ogenschouw moeten worden genomen op overzichtelijke wijze in kaart. ... Het tolmodel is ontwikkeld door Oscar van Leeuwen Het tolmodel kent de volgende onderdelen:

De bovenkant
De informatiebehoeften worden benaderd vanuit de vraag: ‘Waar wil de onderneming naar toe’. De missie, strategie en doelstellingen van de onderneming zijn immers belangrijke objecten waarover managers willen worden geïnformeerd: ‘gaan we de goede kant op’, ‘liggen we nog op koers’ en ‘waar moet eventueel een bijstelling plaatsvinden’ enz..

Het midden
De informatiebehoeften worden benaderd vanuit de vraag: ‘Hoe werkt de onderneming’. Informatie over de structuur, de bedrijfsprocessen en de activiteiten is nodig om in de dagelijkse praktijk juist datgene te doen dat bijdraagt aan de bedrijfsdoelstellingen. Managers willen antwoord op de vragen: ‘wie moest wat doen en is dat goed gegaan’, ‘welke orders zijn er en welke afspraken hebben we met klanten gemaakt’, ‘zijn de voorraden nog toereikend’ enz.

De onderkant
De informatiebehoeften worden benaderd vanuit de vraag: ‘Wat heeft een manager nodig als we zijn persoonlijke wijze/stijl van werken bekijken. In dit kader zijn de managementstijl en de cultuur van de onderneming van belang.

Bij het vormgeven van al deze factoren is niet voor niets gedacht aan een tol. Een tol kan immers pas goed draaien indien de onderdelen daarvan goed op elkaar zijn afgestemd ofwel: in balans zijn. Is aan deze voorwaarde niet voldaan, dan gaat de tol ‘zwabberen’ en ligt hij al gauw omver. Ook bij het in kaart brengen van de gewenste informatie dient aan alle factoren van het tolmodel aandacht te worden geschonken. Te veel of te weinig aandacht voor één van de onderdelen van het model zal er toe leiden dat de geleverde informatie (later) niet of niet voldoende wordt gebruikt.

Bron: Vorm van de bestuurlijke informatieverzorging, prof. drs P.L.A.M. (Paul) van Kessel RE RA, Tolleren - lern van de toltheorie, E.E. de Wagt

Bewaren

Mastering the Unpredictable
How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done
Keith D Swenson 

Bij Bol.com

Wiel Pollaert en Kees Ruigrok beschrijven in het boek <Informatieanalyse> de techniek van de clusteranalyse.

Clusteranalyse is één van de technieken uit de BSP-school. BSP staat voor Business Systems Planning, een door IBM ontwikkelde methode voor het verkrijgen van een betere afstemming tussen informatiesystemen en bedrijfsprocessen.

Uitgaande van grote lijsten van processen en objecten moet de informatieanalist clusters kunnen ontdekken waarbinnen veel interactie is vanwege een sterke samenhang (cohesie), en waarbij tussen de clusters onderling weinig interactie is (zwakke koppeling).

(...)

[1] Noteer alle processen als rijen van een matrix en alle objecten als kolommen.

[2] Vul de cellen van de matrix met een C voor Create/Modify en een U voor Use. Hiermee geven we aan welke processen op welke wijze gebruik maken van de objecten.

Na de 2e stap heb je een ingevulde matrix met de relatie tussen entiteitetypen en bedrijfsprocessen. In de praktijk wordt een matrix als deze vaak aangeduid met Create/Use-matrix.

[3] De eerste twee stappen leiden tot een ongeordende matrix. Hierna ga je de matrix ordenen, waarbij de C's langs de diagonaal staan. Je gaat hierbij uit van de volgorde waarin goederen zich bewegen.

[4] Tenslotte benoem je de clusters (linksboven naar rechtsonder). Elk cluster stelt een mogelijk te ontwikkelen informatiesysteem voor.

Bron: Informatieanalyse, de brug van bedrijfsdoelen naar ICT-oplossingen, Wiel Pollaert en Kees Ruigrok

Nictiz (voluit: Nationaal ICT Instituut in de Zorg) is het Nederlandse kenniscentrum voor landelijke toepassingen van ICT in de zorg. Nictiz ontwikkelde in samenwerking met een aantal ziekenhuizen het referentiedomeinenmodel ziekenhuizen (RDZ).

Het referentiedomeinenmodel ziekenhuizen (RDZ) ondersteunt ziekenhuizen bij de inrichting van de informatievoorziening. Het RDZ biedt de ziekenhuizen een hulp- en communicatiemiddel bij vraagstukken op het snijvlak van zorg en inrichting van de informatievoorziening. Het\is een referentieoverzicht van de samenhang tussen bedrijfsactiviteiten en informatieobjecten in een ziekenhuis, de domeinen. De domeinen vormen logische bouwblokken voor de inrichting van de informatievoorziening.

Referentiemodel ziekenhuizen ontwikkeld. Binnen dit model worden informatiedomeinen onderkent.

Volgens Nictiz begint de vormgeving van de informatievoorziening bij een goed begrip van de essentie van de organisatie. Wat is de missie, visie en strategie? Welke producten en diensten worden geleverd? Welke bedrijfsactiviteiten, bedrijfsprocessen en bedrijfsfuncties zorgen hiervoor? Welke informatie is nodig om de bedrijfsactiviteiten uit te kunnen voeren.

• Een bedrijfsactiviteit is een handeling die kan worden toegekend aan één persoon of aan één rol.
• Een bedrijfsproces is een reeks van activiteiten, met een duidelijk startpunt en eindput, met een duidelijk vastgesteld doel.
• Een bedrijfsfunctie is een set van bedrijfsactiviteiten die samenhang vertonen in de benodigde kennis, vaardigheden of middelen. Bedrijfsfuncties hebben vaak een meer permanet karakter dan bedrijfsprocessen.
• Een informatieobject is een eenheid van informatie die relevant is vanuit een bedrijfsperspectief. Een informatieobject heeft betekenis voor de doelstelling en voor het functioneren van een organisatie.
• Een informatiedomein is een set van bedrijfsactiviteiten met een maximale samenhang in de informatie die door de activiteiten wordt geproduceerd en gebruikt.

Informatiedomeinen vormen logische bouwblokken voor de informatievoorziening van een organisatie en kunnen als basis worden toegepast voor bijvoorbeeld applicatiearchitectuur. Hiermee kan de informatievoorziening maximaal op de behoeften van de organisatie afgestemd worden.

(...)

[Het Referentiedomeinenmodel ziekenhuizen bevat een CU-matrix. Deze matrix is op te stellen nadat eerst de bedrijfsactiviteiten en informatieobjecten zijn geïnventariseerd.] Vervolgens [worden] de bedrijfsactiviteiten en informatieobjecten in een matrix gezet en op de kruispunten te beoordelen of er sprake is van een Create-relatie of Use-relatie (CU matrix).
Een Create-relatie wil zeggen dat een activiteit een informatieobject produceert, leest, bijwerkt of verwijdert (Create, Read, Update en Delete). Een Use-relatie geeft aan dat een activiteit het object slechts leest (alleen Read).

Na het vullen van de matrix zijn de bedrijfsactiviteiten en informatieobjecten geordend, zodat er (informatie)domeinen ontstaan. Horizontaal staan de informatieobjecten, verticaal staan de bedrijfsactiviteiten. De gekleurde vlakken in de matrix zijn de informatiedomeinen; een set van bedrijfsactiviteiten met een maximale cohesie in de informatieobjecten.
Wat opvalt in de matrix is dat er veel relaties tussen bedrijfsactiviteiten en objecten bestaan buiten de informatiedomeinen. Dit weerspiegelt de complexiteit en hoge mate van informatie-uitwisseling binnen de zorg in ziekenhuizen.

Zie ook: Bluff Your Way Into Bedrijfsfuncties

Bron: Referentiedomeinenmodel ziekenhuizen (versie 2| 21-06-2012) op www.nictiz.nl

Willem Sprink stelt dat "Met behulp van excellente proceskennis wordt de basis gelegd voor een IT-systeem dat niets te wensen over laat en dat echt aansluit bij de behoefte van de organisatie."

Volgens Sprink leveren IT-(vernieuwings)projecten vaak niet op waar een organisatie behoefte aan heeft. Hij onderkent hiervoor een vierledige oorzaak (het ontbreken van een duidelijke scope, vage  requirements, een slechte afstemming over (on)mogelijkheden en onvoldoende monitoring tijdens de bouw van het systeem) en pleit voor een integrale procesgerichte aanpak voor IT-projecten bestaande uit vier stappen:

1. Baken de scope af.

2. Match proces met IT-systeem.

3. Maak programma van eisen.

4. Monitor tijdens de bouw.

(1) Baken de scope af

De eerste stap van een succesvolle systeemvernieuwing is het bepalen van de duidelijke scope van het te vernieuwen IT-systeem. Dit door allereerst te bepalen in welke processen het IT-systeem een rol moet gaan spelen. Om in de analogie van de puzzel te blijven: leg de kantstukjes. Tegelijkertijd ontstaat er een eerste beeld van de hoeveelheid stukjes waaruit de puzzel moet bestaan.

Aan de hand van de strategie en het beleid van de organisatie kunnen vervolgens alle processen worden geïdentificeerd. Hiervoor bestaat een succesvolle methode: het
ontwerpen van het bedrijfsprocesmodel. Dit is een overzicht waarin de gehele organisatie is gevat in een totaalverzameling van processen. Omdat de organisatie meer activiteiten verricht dan
alleen het voortbrengen van een product of dienst, wordt hierbij een onderscheid gemaakt in:

1. Primaire processen: alle activiteiten die direct een product of dienst voortbrengen.

2. Ondersteunende processen: de activiteiten die het primaire proces faciliteren/ondersteunen.

3. Besturingsprocessen: alle activiteiten die richting of sturing geven aan primaire en ondersteunende processen.

Het te bouwen IT-systeem speelt een cruciale rol in de informatie-uitwisseling tussen de verschillende geëxpliciteerde processen. Door het bedrijfsprocesmodel is de totale afbakening van de organisatie vormgegeven (in de analogie van de puzzel is de rand gelegd). Is een proces niet geïdentificeerd, dan draagt het ook niet bij aan de doelen van de organisatie.

(...)

(2) Match proces met IT-systeem

Een tweede belangrijke oorzaak voor het falen van een IT-project is, dat er te weinig expliciet gemaakt is wat het IT-systeem precies moet kunnen, op welk moment, en voor wie, voor wat en met welke gegevens. De tweede succesfactor is daarom het (her)ontwerpen van elk van de processen uit het bedrijfsprocesmodel en, als afgeleide daarvan, het bepalen van de ideale systeemondersteuning.

(...)

(3) Maak programma van eisen

Een derde belangrijke oorzaak voor het falen van IT-projecten is namelijk dat er onvoldoende wordt afgestemd tussen organisatie en IT-leverancier over de haalbaarheid van de beschreven wensen. Het is de verantwoordelijkheid van de organisatie zelf om zo precies mogelijk te definiëren wat de IT-leverancier moet gaan bouwen en opleveren.

(...)

(4) Monitor tijdens de bouw

In de vorige stap is de interactie tussen proces en systeem al gedefinieerd; nu moet met behulp van de proces-IT interactie zo specifiek mogelijk worden aangegeven wat er verwacht wordt van het op te leveren IT-systeem. In termen van de puzzel worden hier alle losse puzzelstukjes zo concreet mogelijk gedefinieerd in de vorm van een totaallijst van wensen en eisen, die directzijn gekoppeld aan specifieke activiteiten in de processen. Een voorbeeld van een eis is: "Bij activiteit x: Het kunnen opvragen van een totaaloverzicht van aanvragen, met onderscheid naar type aanvraag, status en ontvangstdatum".

Nu de deksel van de puzzel is gedefinieerd in afstemming met de IT-leverancier, kan gestart worden met de bouwfase. De puzzel is bekend, de rand ligt er al en alle stukjes zijn in gezamenlijkheid besproken. Nu ligt de bal bij de IT-leverancier om te bouwen wat is afgesproken. In voortgangsoverleggen gedurende de bouw van het nieuwe systeem kan de IT-leverancier in workshops terugkoppelen hoever er is gevorderd met de bouw van het systeem. Daarbij biedt de blauwdruk (de deksel) met daarin de achterliggende eisen (de stukjes) een concreet kader voor bespreking. De IT-leverancier toont de voortgang, terwijl de organisatie kan afvinken welke eisen uit de blauwdruk zijn opgeleverd.

(...)

Bron: Vernieuwen IT-systeem kansloos zonder excellente proceskennis, Willem Spronk; in: Kwaliteit in bedrijf, december 2013

Jeroen Stoop, Sjoerd Staffhorst, Remco Bekker en Tjerk Hobma gaan in het boek Business- & Informatieplanning - Een raamwerk voor organisatieverbetering in op het nut en de noodzaak van een bedrijfsobjectenmodel en een informatiedomeinenmodel. Hieronder een beknopte weergave van hoe beide modellen kunnen helpen bij het optimaliseren van de ondersteuning die de informatievoorziening biedt aan processen.

Bedrijfsobjectenmodel

Informatievoorziening levert de informatie die nodig is voor de uitvoering en besturing van processen. De uitvoering en besturing processen heeft informatie nodig. In deze informatiebehoefte wordt voorzien door informatiesystemen.
Voor elk proces kunnen de informatiebehoeften in beeld worden gebracht. Voor het in kaart brengen van de informatiebehoeften is het nodig te weten wat de 'onderwerpen van gesprek' zijn. Waarover praten de deelnemers aan het proces en wat willen ze hier dan van weten.

[De] 'onderwerpen van gesprek' noemen we bedrijfsobjecten. Het zijn de 'dingen' waarvan we de eigenschappen in de vorm van gegevens willen vastleggen, gebruiken en beheren. Deze 'dingen' kunnen betrekking hebben op fysieke objecten die we kunnen aanwijzen, zoals gebouwen, mensen of producten, maar ook op abstracte objecten, zoals verzekeringspolissen, organisaties of vorderingen. Objecten kunnen ook betrekking hebben op gebeurtenissen, bijvoorbeeld, een levering of een uitvaart.

Voor het verkrijgen van een gestructureerd overzicht van de objecten waarvan we eigenschappen in de vorm van gegevens willen vastleggen, kunnen we gebruik maken van een bedrijfsobjectenmodel. In het bedrijfsobjectenmodel draait het om het definiëren van de objecten, het begrijpen hoe de bedrijfsobjecten samenhangen en het onderkennen van de belangrijkste eigenschappen van die objecten.

(...)

Het is ook mogelijk om een model uit de datamodellering te gebruiken, zoals een entiteitsrelatiediagram (ERD). Bij het kiezen van de manier waarop de gegevens worden beschreven is het van belang om het doel van het model in de gaten te houden. Meestal is veel detaillering niet nodig en gaat het om de belangrijkste objecten met hun belangrijkste eigenschappen. Een bedrijfsobjectenmodel leent zich hiervoor het best. Het hoeft namelijk geen ontwerp van een informatiesysteem te zijn.

Informatiedomeinenmodel

Novius stelt dat voor het maken van toekomstvaste keuzes voor de inrichting van de informatievoorziening het nodig is te beschikken over een ideaaltypische afbakening van de informatiedomeinen.

"Stel dat we van een organisatie de end-to-end-processen (op hoofdlijnen) in kaart hebben gebracht. En stel vervolgens dat we ook van deze processen de informatiebehoeften (op hoofdlijnen) in kaart hebben. Dan kan de vraag worden gesteld welke informatiesystemen idealiter geïmplementeerd moeten worden om in de informatiebehoeften van de processen te voorzien. Deze vraag draait om een optimale afbakening van de informatiesystemen van een organisatie. Een optimale afbakening van de informatiesystemen zorgt voor flexibiliteit in processen en informatiesystemen enerzijds en voor samenhang en uniformiteit tussen processen en informatiesystemen anderzijds.

... Processen krijgen hun informatie aan de hand van gegevens  die eigenschappen van bedrijfsobjecten representeren. Maar in processen komen ook nieuwe gegevens beschikbaar over bedrijfsobjecten die vastgelegd moeten worden. Informatiesystemen beheren samenhangende clusters van gegevens voor de processen om tijd en plaats te overbruggen (tijd: gegevens die we vandaag vastleggen hebben we ooit in de toekomst weer nodig; plaats: gegevens kunnen we op verschillende locaties nodig hebben). Het is hierbij wenselijk om clusters van processen te bepalen met een sterke interne samenhang voor wat betreft de informatiebehoeften en met zwakke externe informatie-uitwisselingen (loose coupling en tight cohesion). Dergelijke clusters worden ook wel informatiedomeinen of logische informatiesystemen genoemd.

We onderscheiden twee technieken die kunnen helpen bij het onderkennen van informatiedomeinen:

(1) Gebruik van het bedrijfsfunctiemodel als startpunt voor het informatiemodel.

Bedrijfsfuncties zijn ook logisch afgebakende clusters van activiteiten, mensen en middelen. In gegevensverwerkende organisaties heeft die afbakening dan ook logischerwijs veel te maken met de gegevensverwerking die plaats dient te vinden in een bedrijfsfunctie. Vandaar dat dit een goed startpunt is om per bedrijfsfunctie een informatiedomein te onderkennen.

(2) Opstellen van een CU- of CRUD-matrix

We kunnen processen ook in een matrix afzetten tegen de gegevensverwerking van die processen. Dit wordt ook wel een CU- of CRUD-matrix genoemd. De letters C en U staan voor Create en Use en de letters CRUD voor Create, Read, Update en Delete. In deze matrices staan op de verticale as de werkprocessen of processtappen, en op de horizontale as de bedrijfsobjecten. In de cellen van deze matrix wordt dan vastgelegd welke acties (C en U dan wel C, R, U of D) het betreffende werkproces of de betreffende processtap uitvoert op het betreffende bedrijfsobject of de betreffende entiteit. Door te schuiven met de kolommen en rijen van de matrix kunnen we op zoek gaan naar clusters van grote samenhang tussen een groep werkprocessen of processtappen enerzijds en een groep bedrijfsobjecten of entiteiten anderzijds. Een dergelijk cluster representeert een informatiedomein.

In de praktijk blijkt het dat met de tweede techniek moeilijker is om tot goede resultaten te komen dan met de eerste. Om die reden wordt de tweede techniek dan ook aanvullend ingezet, als dat nodig is, om discussies over de afbakening te slechten.

(...)

Het informatiedomeinenmodel is een belangrijk model voor de afstemming van de bedrijfsvoering en de informatievoorziening. Het is de stap naar de functionaliteiten en informatie die nodig zijn voor de uitvoering van de processen. Het informatiedomeinenmodel biedt een overzicht van de benodigde informatievoorziening los van de fysiek invulling met applicaties. In de praktijk is dit een zeer handige tussenstap. Vaak is men geneigd om te blijven denken in termen van het huidige applicatielandschap. Met het informatiedomeinenmodel komt men hier meer los van, wordt het gemakkelijker om discussies over applicatiegrenzen te voeren en wordt het denken in scenario's vergemakkelijkt.

De kapstokfunctie van het informatiedomeinenmodel (dat overigens vaak op één A4-tje is weer te geven) is erg nuttig. De huidige en in ontwikkeling zijnde applicaties, de gegevensstromen, de verantwoordelijkheden voor informatiedomeinen, de huidige knelpunten: allemaal voorbeelden van zaken die op het informatiedomeinenmodel 'geplot' kunnen worden.

Het applicatielandschap en de gewenste functionaliteiten van de informatievoorziening

[Applicaties geven] een fysieke invulling aan (een deel van) één of meerdere informatiedomeinen. Een applicatie is een verzameling van geautomatiseerde en verwante functionaliteiten, samen met de gegevens die door die functionaliteiten worden beheerd, met een eigen planning van nieuwe versies, release en aanpassingen.

Een applicatie kan door een organisatie zelf zijn ontwikkeld, maar vaak worden applicaties gekocht. Het geheel van applicaties wordt ook wel het applicatielandschap genoemd.

(...)

Als we het applicatielandschap vanaf de grond zouden opbouwen en zouden willen optimaliseren voor samenhang en flexibiliteit, dan zou het applicatielandschap bestaan uit applicatie(module)s, die elk één informatiedomein afdekken. Het applicatielandschap ziet er dan hetzelfde uit als het informatiedomeinenmodel.

Bron: Business- & Informatieplanning - Een raamwerk voor organisatieverbetering, Jeroen Stoop, Sjoerd Staffhorst, Remco Bekker, Tjerk Hobma