BiSL-goeroe Remko van der Pols doet in het boek Naar een vraaggestuurde informatievoorziening samen met René Sieders en Ben Stoltenborg een poging theorie te combineren met de gezondheidszorg als praktijkcase om concrete handvatten te geven voor de inrichting van businessinformatiemanagement (BIM) in zorgorganisaties.

Persoonlijk vindt ik de case minder interessant. Hieronder een paar veralgemeniseerde 'losse flodders' uit het boek.

Organisaties staan volgens Van der Pols & co. voor drie uitdagingen:

1. Vernieuwing van de informatievoorziening: de informatievoorziening is een kritische succes- en productiefactor geworden, met het disfunctioneren van de informatievoorziening als bedrijfsrisico. Het landschap met vooragl centrale, gesloten systemen staat voor grootschalige vernieuwing.

2. Inrichting van businessinformatiemanagement: gezien het (toenemende) belang van de informatievoorziening voor het primaire proces, vraagt de organisatie van zowel IT als beheer expliciet aandacht. Vraagsturing is hierbij belangrijk en de inrichting van de vraagorganisatie, het businessinformatiemanagement vormt hierbij een belangrijke activiteit.

3. Professionalisering van de vraag en vraagorganisatie: om de omslag te maken van aanbodgedreven naar vraaggedreven wordt het essentieel kennis en vaardigheden te verkrijgen om leveranciers goed aan te sturen (incl. outsourcing).

Volgens Van der Pols & co. zijn er twee manieren waarop de informatievoorziening kan worden aangestuurd:

1. Aanbodsturing: de IT-organisatie onderkent de ontwikkelingen en beslist over de te gebruiken middelen en investeringen ten aanzien van de informatievoorziening. De gebruikersorganisatie heeft (alleen) een inhoudelijke en adviserende rol.

2. Vraagsturing: het besturen van de informatievoorziening vanuit gebruikers- en bedrijfsperspectief; de organisatie is zélf (eind)verantwoordelijk voor wat zij nodig heeft en het nemen van investeringenbeslisingen over de informatievoorziening.

De keuze voor vraagsturing of aanbodgedreven sturing is afhankelijk van het belang van de informatievoorziening. Van der Pols & co. onderscheiden hierbij vier categorieën:

1. IT als hulpmiddel: automatisering speelt nauwelijks een rol (ledenadministratie)

2. IT als ondersteuning: automatisering begtreft alleen ondersteundend processen (financiële en personeelsadministraties)

3. IT als bedrijfskritisch: primaire proces is afhankelijk van IT (bedrijfspakketten zoals ERP)

4. IT als bedrijfsproces: informatieverwerking is het primaire bedrijfsproces (banken, verzekeraars of overheid)

Dé aanleiding om over te stappen op vraagsturing is als de informatievoorziening te belangrijk is om ICT'ers over te laten. Dit is het geval als de informatievoorziening bedrijfskritisch wordt óf het bedrijfsproces vormt.

Zodra een organisatie ervoor kiest over te gaan van aanbod- naar vraaggestuurd, wordt de vraagorganisatie expliciet en krijgt zij ook de macht. De structuur van de vraagorganisatie moet expliciet worden ingericht (governancestructuur). Volgens Van der Pols & co. moet de structuur van de vraagorganisatie passen in de (informele) machtslijnen van de organisatie zelf. De inrichting wordt daarmee primair machts- en invloedgedreven, waarbij de structuur primair afhankelijk is van de inrichting van de gebruikersorganisatie en de personen daarin. Omdat in veel organisatie de macht verspreid is en de omvang van zgn. informatiedomeinen verschillend is, is de sturing op de informatievoorzienining nooit uniform. De invulling en uitwerking is - aldus Van der Pols & co. - situationeel bepaald.

Volgens Van der Pols & co. zijn gelden drie wetten bij het het inrichten van de besturingsstructuur van de informatievoorziening in een organisatie (governancestructuur):

1. De structuur van de sturing over de informatievoorziening moet een afgeleide zijn van de machtsstructuur van de organisatie: effectieve vraagsturing veronderstelt dat de betrokken manager in staat is, het voor hem of haar relevante deel van de informatievoorziening direct te sturen.

2. Kennis van het bedrijfsproces is essentieel: de businessinformatiemanager moet dezelfde taal spreken als de businessmanager en moet het bedrijfsproces goed kennen.

3. De invulling van informatiemanagement volgt de lijnen van de baas: sturing van de informatievoorziening is baasafhankelijk, waarbij de persoon en stijl van de manager van invloed is op de governance, en dus voor de relatie tussen businessinformatiemanagement en management.

Bij het inrichten van de governancestructuur moet aandacht besteed worden aan:

1. Opdeling applicatielandschap en afbakening informatiedomeinen: het applicatielandschap beschrijft op hoofdlijnen de samenhang van de verschillende applicaties van een organisatie. Dit landschap vormt de basis voor de opdeling en vaststelling van de informatiedomeinen en het beleggen van de domeinverantwoordeliijkheid door één persoon (functie) aan te wijzen die de verantwoordelijkheid krijgt voor de informatievoorziening in een informatiedomein.

2. Afspraken over belangen: afspreken wat de rechten en plichten zijn voor andere belanghebbenden dan de vastgestelde, verantwoordelijke domeineigenaar. Een belangrijke voorwaarde is dat de belangrijkste belanghebbenden geïnventariseerd zijn, waarbij wordt onderkend welke belanghebbenden belangen hebben in welke delen van de informatievoorziening, wat die belangen inhouden en hoe zwaarwegend die zijn.

3. Overkoepelende autoriteit: het kan noodzakelijk of wenselijk zijn om een domein-overstijgende, overkoepelende autoriteit te benoemen.

4. Corporate-informatiemanager: benoemen van corporate-informatiemanager die verantwoordelijk is voor het bewaken, coördineren en afstemmen van samenhang van de informatievoorziening.

5. Ophanging van businessinformatiemanagement: ophangen van businessinformatiemanagement in de organisatie (in de afdeling, werkzaam vanuit een aparte afdeling of ingehuurd vanuit de IT-afdeling). Bij grote organisaties kan het wenselijk zijn verschillende modellen naast elkaar te gebruiken gebruiken.

Businessinformatiemanagement moet borgen dat de informatievoorziening goed aansluit en blijft aansluiten op de bedrijfsprocessen. Een belangrijjk onderdeel van businessinformatiemanagement is het inventariseren van de veranderbehoefte, zowel vanuit de huidige situatie (functionele kwaliteit, technische kwaliteit en exploitatiekwaliteit) en de ontwikkelingen in de keten, het bedrijfsproces en op technologisch gebied.

Van der Pols & co. stellen dat elke keuze die je maakt, voorafgegaan wordt door een afweging van kosten, baten en de ellende die je je op de hals haalt met het al of niet doorvoeren van een wijziging. Deze afweging illustreren zij met een zgn. ellendedriehoek:

Bron: Naar een vraaggestuurde informatievoorziening, Remko van der Pols René Sieders en Ben Stoltenborg

In een interview in De Volkskrant (6/12/2011) gaat Chris Verhoef, hoogleraar informatica aan de VU, in op de rol van de (overheids als) opdrachtgever bij het mislukken van ict-projecten. Verhoef spreekt over echecs 'die iedereen met kennis van zaken van verre ziet aankomen'.

Verhoef gaat in op het belang van de Amerikaanse Clinger-Cohen Act; een harde wet op de financiering en ontwikkeling van ict-systemen uit 1996 die de boel vooral wakker heeft geschud: "De echte betekenis van de Clinger Cohen wet is dat het de voorwaarden opsomt waaraan een ict-project moet voldoen. Als we in Nederland zo'n regelgeving hadden gekend, had dat veel zeperds gescheeld.'

De reden waarom we in Nederland dergelijke regels (nog) niet hebben is - aldus Verhoef - '[o]mdat bij ons de bom nog niet gebarsten is en we de politieke discipline ontberen die nodig is om debacles te vermijden.' Met deze politieke discipline bedoelt hij '[d]at je als opdrachtgever niet elke dag iets anders zegt over wat je verlangt van je nieuwe systeem.'

Verhoef stelt dan ook dat de eerste vraag aan een opdrachtgever zijn: "Wat wilt u precies? Maar de politiek is volgens hem vaak (te) opportunistisch: "Ict'ers moeten meer weerstand bieden. Politici moeten zich beperken tot de wat-vraag en de hoe-vraag overlaten aan de lui die kennis hebben van creatieve problemen." "Verder waarschuwt hij voor een te hoog ambitieniveau: "We moeten niet meteen voor 100 procent gaat, 80 procent is al geweldig. Daarvoor kiezen, vergt politieke discipline. En die is ver te zoeken. Zo blijven we mislukkingen genereren."

Verhoef noemt als voorbeeld het rekeningrijden. "Er zijn files in het land. De vraag voor de politiek moet zijn: wat kan gedaan worden om doorstroming te bevorderen? Goeie vraag. Maar dan voegt de politiek er meteen aan toe dat er kastjes moeten komen in auto's, en dat het ons 3,5 miljard gaat kosten en een half miljard aan jaarlijks onderhoud. Dan kunnen we rekeningrijden. 'Maar wat is nodig voor rekeningrijden? Je moet weten wie wanneer waar op de weg is. Zo iemand moet je een rekening kunnen sturen. Je hebt dus een klantrelatie nodig. 'Nou, zo'n systeem hebben we al. Het heet trajectcontrole. Het stelt de overheid in staat te zien of jij te hard hebt gereden op een bepaald stuk weg. Zo ja, dan krijg je de rekening thuis gestuurd. Er is dus een klantrelatie. Ik zeg: stuur altijd een rekening, namelijk voor het gebruik van de weg in spitsuren. Rekeningrijden ingevoerd! Wat is nog het probleem'"

Ook het Electronisch Patiëntendossier noemt Verhoef als voorbeeld van een overbodig systeem. "Wat wilde men? Geautomatiseerde uitwisseling van gegevens tussen artsen om medische missers te voorkomen. Prima. Het draaide uit op enorm geharrewar. 'Het ergste is: we hebben al een geautomatiseerd systeem van medische informatie. het heet Vecozo, Veilige Communicatie in de Zorg en is een portaal van de vereniging van zorgverzekeraars. Ik denk dat 90 procent van alle declaraties van dokters via dat portaal loopt. (...) Het is een systeem waarvan ik zeg: petje af. En weer blijkt dat het probleem is opgelost en met bestaande middelen kan worden gerealiseerd."

In de Clinger-Cohen Act is geregeld dat het Office of Management and Budget (OMB) gaat over de spelregels voor nieuwe ict-projecten. Het OMB kwam met een set van zgn Raines Rules (genoemd naar de auteur), "een setje van acht regels; zo helder als glas en zo hard als staal. Regels als: kijk eerst of er een alternatief is. Lever een businesscase, een financieel-economische onderbouwing. Ontwikkel het project in kleine stapjes, zodat je tussentijds kunt bijstellen. Wie niet aan alle acht regels kan voldoen, krijgt geen geld en kan fluiten naar zijn project."

"Verhoef: 'Waar de kromming van een banaan gespecificeerd is in een Europese richtlijn is er voor ict gewoon niks in Nederland. Dat is echt te weining. Zo'n lijstje als dat van Raines inspireert: acht of tien harde heldere regels. Ik zou er meteen al een van Raines invoeren: ga niet een systeem bouwen dat al bestaat."

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

Bron: interview met Chris Verhoef in De Volkskrant (6/12/2011) "Mijn eerste regel zou zijn: bouw geen ict-systeem dat al bestaat"; Jan Tromp

Bart de Best beschrijft in een BEA-stappenplan hoe 'beheren onder architectuur' kan worden vormgegeven:

Het BEA-raamwerk

De basis van het boek wordt gevormd door het BEA-raamwerk. Dit raamwerk maakt een onderscheid in drie niveaus (aspectgebieden):
• Richten (beleid)
• Inrichten (ontwerp)
• Verrichten (uitvoering)

Per aspectgebied zijn stappen gedefinieerd. Elke stap is een hoofdactiviteit die plaats dient te vinden om onder architectuur tot een goed ingerichte beheerorganisatie te komen. Per stap worden vervolgens best practices beschreven voor zowel een beheerorganisatie als een projectorganisatie (ten behoeve van projectbeheersing).

Op het niveau ‘Richten’ is de eerste stap dat een ICT-beleid en ICT-beleidsplan worden opgesteld. In de tweede stap worden, uitgaande van het ICT-beleidsplan de architectuurprincipes die richtinggevend zijn voor de inrichting van de beheerprocessen opgesteld. De principes worden in de derde stap uitgewerkt in modellen.

Het aspectgebied ‘Inrichten’ bestaat uit twee deelgebieden, ‘Structuur’ en ‘Vormgeving’. Per deelgebied zijn ook weer drie stappen gedefinieerd. In deelgebied structuur wordt in de eerste stap het organogram, met bijbehorende functies en rollen beschreven. In de tweede stap worden de doelen van de beheerprocessen beschreven en zodanig uitgewerkt dat bewaking van deze doelen mogelijk wordt. In de derde stap worden de requirements beschreven die worden gesteld aan de beheerprocessen. Deze requirements zijn voorschrijvend voor de inrichting van beheerprocessen.

De eerste stap in deelgebied vormgeving is het opstellen van procesontwerpen voor de diverse beheerprocessen. Vervolgens wordt in de tweede stap de taakverdeling over de processen vormgegeven. Hierbij zijn ondermeer een logische groepering van taken en essentiële functiescheidingen
van belang. Tot slot worden in de derde stap de ontworpen processen verder ingericht waarbij methoden, middelen en mensen aan de taken worden gekoppeld.

Binnen het laatste aspectgebied ‘Verrichten’worden afspraken gemaakt over de uitvoering van het beheer. In de eerste stap van dit aspectgebied worden afspraken beschreven over de toepassing van beheermiddelen. Voorbeelden hiervan zijn afspraken over hergebruik en richtlijnen voor vernieuwing. In de tweede stap worden de competenties van de beheermedewerkers opgesteld, c.q. aangepast op basis van bestaande functiebeschrijvingen. Ten slotte wordt in de derde stap het sluitstuk van het beheer opgezet door afspraken te maken over audit en review. Het definiëren van meetpunten en het inrichten van een terugkoppelingsmechanisme om verbeteringen uit de audits en reviews door te voeren zijn hier voorbeelden van. Bij deze laatste stap is een auditor de aangewezen persoon om vanuit zijn vaktechnische kennis de architect te adviseren.

Door middel van een RASCI-tabel, dat wil zeggen een tabel waarin rollen worden af gezet tegen de verantwoordelijkheden Responsible, Accountable, Supportive, Con sulted en Informed, zijn per stap de acti viteiten die hierin plaatsvinden uitgezet tegen de bij de stappen betrokken rollen. Hierdoor ontstaat een helder overzicht van de diverse verantwoordelijkheden en taken die nodig zijn bij het inrichten en uitvoeren van een beheerorganisatie onder architectuur.

Bron: IT Beheer Magazine nummer 10, 2007

In de whitepaper "Ten steps to better requirements management" van Dominic Tavassoli (IBM) wordt gesteld dat de impact van slecht geformuleerde requirements verwoesten kan zijn: "(I)t can have a domino effect that leads to time-consuming rework, inadequate deliveries and budget overruns." en worden de onderstaande 9 kenmerken genoemd van goede requirements:

1. Correct (correct): technisch en juridisch mogelijk

2. Volledig (complete): express a whole idea

3. Duidelijk (clear): eenduidig en helder

4. Consistent (niet conflicterend)

5. Verifieerbaar (verificable): het is mogelijk vast te stellen óf de oplossing voldoet aan de gesteld eisen

6. Traceerbaar (traceable): uniek identificeerbaar en herleidbaar

7. Haalbaar (feasible): realiseerbaar binnen tijd en budget

8. Modulair (modular): aanpasbaar zonder drastische gevolgen (excessive impact)

9. Ontwerp-onafhankelijk (design-independent): beperken zich tot het 'wat' (en gaan dus niet over het 'hoe').

Bron: Ten steps to better requirements management, Requirements Management Whitepaper, Dominic Tavassoli (Juni 2009, IBM)

Volgens James Robertson zijn er zeven mythes op het gebied van requirements:

1. Mythe-1: Requirements gaan over requirements: de waarheid is dat requirements gaan over problemen van de business. Kijk dus - als business analist - niet te veel naar de software, maar blijf oog houden voor het bedrijfsprobeem 'achter de software'.

2. Mythe-2: Luister naar de gebruikers: gebruikers komen niet op de proppen met innovaties, maar vragen vaak alleen om aanpassingen en verbeteringen van de bestaande situatie. De beroemde uitspraak van Henry Ford is dat als hij de mensen zou vragen wat ze zouden willen, ze naar alle waarschijnlijk hadden gezegd: snellere paarden.

3. Mythe-3: Testers testen software: testers moeten niet alleen het eindproduct testen, maar ook de tussenproducten (end-to-end), zodat je fouten in requirements vroegtijdig ontdekt.

4. Mythe-4: Schrijf altijd een complete set aan requirements: de 80/20 regel geldt ook voor requirements.

5. Mythe-5: Ruim tijd in for het debuggen: debuggen doe je pas op het eind, besteed in plaats daarvan juist meer tijd aan het goed krijgen van je requirements. Dit verdient zichzelf qua doorlooptijd en kosten zeker terug.

6. Mythe-6: Begin met use cases: use cases gaan over de oplossing, begin eerst met het begrijpen van het probleem.

7. Mythe-7: Met agile heb je geen requirements nodig: ook al kent agile geen requirementsfase, requirements blijven cruciaal (bijv. voor het visiedocument, je initiële requirementsset, de gesprekken en het testen).

Bron: http://it-maintenance.blogspot.com/2011/04/7-requirements-myths.html en http://www.reaco.nl/kenniscentrum/requirementsMythes.asp

Volgens Dororthy Graham kan er veel tijd en geld bespaard worden als testers betrokken zijn bij het testen van requirements. Zij benoemt zeven misvattingen over het verband tussen testen en requirements:

1. Requirements aan het begin, testen aan het eind: het vroegtijdig betrekken van testers is juist een garantie voor goede requirements.

2. Testen is pas mogelijk als het systeem bestaat: benut de mogelijk om requirements 'op papier' te testen.

3. Requirements worden gebruikt bij het testen, maar omgekeerd niet: goede testanalyse leidt tot betere requirements.

4. Het opstellen van testscripts is slechts een testprobleem: vage specificaties zijn moelijk meetbaar en (dus) testbaar te maken

5. Kleine wijzigingen beïnvloeden project minimaal: 'klein' vanuit requirementsperspectief , kan test-technisch grote gevolgen hebben

6. Tester hebben requirements niet écht nodig: requirements zijn dé testbasis omdat ze de verwachte uitkomst voorspellen

7. Testers kunnen niet testen zonder requirements: bij inadequate requirements resteren 'exploratief testen' en goede testware om te testen.

Bron: Requirements and Testing: Seven Missing-Link Myths, Dorothy Graham, IEEE Software (sept/oct 2002)

'De Belastingdienst vroeg me in 2015 na te denken over de digitale architectuur daar. Ik vroeg hoeveel architecten ze hadden. Dat wisten ze niet precies: 200, 250. Dat vind ik een een gek antwoord. Jan en alleman is daar architect. Ik schat dat er in Nederland circa twintigduizend IT-ers rondlopen die zich architect noemen. Ik neem er slechts duizend serieus.'

Zijn ideaal is dit: 'De hoofdregel in de automatisering luidt: eerst reorganiseren en vereenvoudigen, dan pas IT. Anders ben je bezig chaos te automatiseren. Dat doet de overheid nu. Er zitten te veel ambtenaren in Den Haag. Er zijn te veel ingewikkelde besluitvormingsprocessen. Het idee van de compacte overheid is in de kast gestopt en daar ligt nu een laag stof op. met goede IT kun je die compacte overheid wel bereiken.'

Bron: Interview met Daan Rijsenbrij, in: Elsevier 5 oktober 2019

Kotler (2000) definieert dienstverlening (service) als volgt: ‘A service is any act or performance that one party can offer to another that is essentially intangible and does not result in the ownership of anything. Its production may or may not be tied to a physical product.’ Deze definitie wordt door Kotler vervolgens vertaald naar de navolgende eigenschappen van diensten:

1. Ontastbaarheid (intangibility): afnemer kan niet de precieze resultaten zien voor af aan de dienstverlening.

2. Ondeelbaarheid (inseparability): diensten worden gelijktijdig geproduceerd en geconsumeerd.

3. Variabiliteit (variability): diensten worden door personen geproduceerd en zijn daardoor van deze persoon afhankelijk, hierbij beseffend dat geen twee personen exact gelijk of even goed zijn in de aangeboden dienst.

4. Vergankelijkheid (perishability): er kan geen voorraad van de dienst worden aangelegd. Hierdoor kan de benodigde capaciteit voor het opvangen van piekmomenten hoger zijn dan bij gelijkmatige vraag.

Op basis hiervan onderkent Kotler vijf categorieën van product- of dienstaanbiedingen (offerings):

1. ‘Pure tangible goods. The offering consist primarily of a tangible good such as soap, toothpaste, or salt. No services accompany the product.

2. Tangible with accompanying services. The offering consists of a tangible good accompanied by one or more services.

3. Hybrid. The offering consists of equal parts of goods and services. For example: people patronize restaurants for both food and service.

4. Major service with accompanying goods and services. The offering consists of a major service along with additional services or supporting goods. For example
   airline passengers buy transportation service. The trip includes some tangibles, such as foods and drinks, a ticket stub, and an airline magazine. The service requires a capital-intensive good – an airplane – for its realization, but the primary item is a service.

5. Pure service. The offering consists primarily of a service. Examples include baby-sitting, psychotherapy, and massage.

Bron: Kluskens, P. en I. van der Wijst, (2005), Typologie van informatie: een voorzet tot verandering, Maandblad voor Accountancy en Bedrijfseconomie

In zijn artikel in Informatie stelt Jan Truijens dat flexibilteit een belangrijke kwaliteit is van de informatie-huishouding: "Processen en functies veranderen voortdurend en de functionaliteit van de ondersteunende applicaties moet mee veranderen". Hij introduceert de term 'kwalitijd' om te benadrukken dat het belangrijk is de veranderende processen passend én tijdig te ondersteunen.

Volgens Truijens is flexibiliteit mogelijk met eenvoudige maatregelen: "Niet door uit te gaan van allerlei instelbare, parametriseerbare of veranderbare ICT-componenten, maar door juist de níét te veranderen onderdelen op te sporen, krijgt de informatiehuishouding haar flexibiliteit".

Het begrip informatie-architectuur definieert Truijens als de min of meer bestendige onderdelen, zowel applicatieve als technische, die het skelet vormen van de informatiehuishouding. Flexibiliteit is - aldus Truijens - mogelijk door slechts enkele skeletonderdelen te identificeren en implementeren.

Truijens definieert architectuur als 'the arrangement of things': "Onderdelen of producten die onderling een relatie hebben, worden door architectuur geordend, ingedeeld en met elkaar verbonden tot een ordelijk werkend geheel waardoor het geen willekeurige maar een zinvolle samenstelling is van technische componenten. Archiectuur maakt dat het geheel méér is dan de som der delen omdat dóór die relaties samenhang ontstaat en samenwerking kan plaatsvinden."

Op basis van zijn definitie concludeert Truijens dat het bij architectuur gaat om drie aspecten:

1. Samenstelling

2. Samenhang

3. Samenwerking

Volgens Truijens zijn er drie voorwaarden voor passende ondersteuning met ICT-middelen:

1. Passende en evenwichtige ondersteuning: concretiseren van ondersteuningseisen.

2. Complexiteitsbeheersing:

3. Flexibiliteit

Architectuur moet - als communicatie-instrument - concretiseren wat ICT betekent en kan betekenen voor een organisatie. De architect moet hierbij kunnen soepel kunnen schakelen tussen twee beschouwingsniveaus: de 'enterprisearchitectuur', die ordent, en de 'solution-architectuur', die helpt bij het implementeren: "'Solutions' moeten immers in het grotere geheel passen, op straffe van complexiteitstoename door digitale versnippering en willekeur".

Truijens stelt "architectuur is nodig, niet als doel maar als noodzakelijke voorwaarde voor complexiteitsbeheersing en voor passende en evenwichtige ondersteuning van bedrijfsactiviteiten, zowel de primaire (waar het geld wordt verdiend) als de secundaire (die overzicht, besturing en beheersing mogelijk maken). Díé ondersteuning moet, simpel gezegd, niet alleen vandaag maar ook morgen en overmorgen werken".

Truijens stels dat de inzet van ICT zowel technische maatregelen (platformen, netwerken) als applicatieve maatregelen (applicaties, informatie) vereist om het geheel te laten werken en blijvend te laten samenwerken.

Wanneer flexibiliteit centraal staat, is het nodig naast de functionele eisen ook de niet-functionele eisen expliciet te maken omdat de wijze waarop deze al dan niet worden geïmplementeerd, bepalend is voor hoe flexibel de informatiehuishouding is. Volgens Truijens zijn er belangrijke 'verticale verbanden tussen de applicatieve bovenwereld en de technische onderwereld'.

Truijens maakt een uitstapje van de digitale naar de civiele wereld en citeert Leupen: "het is juist het onveranderbare, het permanente dat de voorwaarden schept voor veranderbaarheid, het is het permanente dat vrijheid geeft aan het tijdelijke. Dit permanente is het kader en definieert de ruimte waarbinnen de verandering plaats kan vinden. (...) Zo is bijvoorbeeld een niet-dragende scheidingswand snel te plaatsen dankzijk de aanwezigheid van een draagconstructie die de wand vrij te plaatsen maakt door de taak van het dragen van de wand over te nemen. (...) Een laag wordt een kader door een andere laag - de ingekaderde laag - te bevrijden. De ingekaderde laag is echter pas vrij om te veranderen indien deze ontkoppeld is van de laag die het kader vormt. In het voorbeeld van de kolom en de wand is het de draagconstructie - de kolom - die de enscenering - de wand - bevrijdt onder de voorwaarde dat ze van elkaar ontkoppeld kunnen worden. (...) Door ontkoppeling krijgt een laag zijn zelfstandigheid. (...) Voorwaarde voor de ontkoppeling van een laag is dat de betreffende laag geen taken meer vervult die bij een andere laag horen." Volgens Truijens vormen op deze manier "[d]e permanente voorzieningen, nodig voor een gebouw ... een skelet dat, als het goed is uitgevoerd, ruimten mogelijk maakt die op verschillende manieren te gebruiken zijn."

De (min of meer) permanente voorzieningen van de informatiehuishouding vormen de kaders die bepalend zijn voor de inrichtingsvrijheid en zicht geven op de flexibiliteit van de informatiehuishouding. "Het is dus belangrijk de permanente voorzieningen, de invarianten, op te sporen, die (toevallig of door intelligent ontwerp of door eigenwijs optreden) de 'kaders' van de informatiehuishouding vormen".

Volgens Truijens helpt standaardiseren complexiteit beheersen: "Hoe meer verschillende onderdelen, hoe groter de complexiteit. En ook: hoe meer verschillende relaties, des te groter de complexiteit. Bij complexiteit gaat het om diversiteit en afhankelijkheid. Standaardiseren brengt zowel die diversiteit terug als het aantal verschillende afhankelijkheden. En dat geldt zowel voor de technische als voor de applicatieve onderdelen van de informatiehuishouding en de organisatorische inbedding."

Truijens stelt dat een informatiehuishouding voortdurend verandert, maar niet alles en zeker niet tegelijk: "Een verandering laat vaak een aantal structuren en generieke onderdelen ongemoeid, ja, drááit daar zelfs om ... juist omdat er 'vaste waarden'in de informatiehuishouding zijn, (kunnen) veranderingen succesvol verlopen." Truijens verwijst naar Rijsenbrij's model voor de informatiehuishouding waarbinnen vier lagen worden onderscheiden: de bedrijfsproceslaag, de informatielaag, de applicatielaag en de technologielaag. De (meer) generieke elementen vervullen een spilfunctie bij veranderingen (...) Het geheel van die basisvoorzieningen, van die generieke onderdelen van de informatiehuishouding noemt men de informatie-infrastructuur."

Volgens Truijens kan de informatie-infrastructuur worden onderverdeeld in drie onderdelen:

1. Kernvoorzieningen, die iedereen mag/moet gebruiken

2. Collectieve voorzieningen, die iedereen hetzelfde heeft omdat afwijkingen geen zin hebben

3. Conditionele voorzieningen, die constructieve orde in de ontwikkelingen brengen

De informatie-infrastructuur vormt het skelet van de informatievoorziening. Deze structuur komt niet in korte tijd tot stand maar ontwikkeld zich stapsgewijs. "[I]n de hectiek van allerlei bedrijfskunidge en technologische veranderingen kan, bij goed management, ... een structuur worden ontwikkeld met pijlers die de kern van de bedrijvigheid draaiend houden."

De belangrijkste consequenties van Truijens betoog is dat het niet nodig is de eigenschappen van honderden applicaties en installaties te inventariseren om overzicht en inzicht te krijgen in de te bewerkstelligen en te behouden flexibiliteit, maar dat je kunt volstaan met het identificeren en implementeren van 'slechts enkele skeletonderdelen'. "Dit betekent minder werk, meer kwaliteit, meer zekerheid over tijdige aanpasbaarheid, oftwel: kwalitijd."

Bekijk en beluister de Gesproken samenvatting dissertatie Jan Truijens (28:43 min) of download de volledig dissertatie 'De Informatie-Infrastructuur – waarborg voor de kwalitijd van de informatiehuishouding'.

Bron: De kwalitijd van de informatiehuishouding, Jan Truijens, Informatie / november 2011,

Arjan Otter (DNV) hield op 10 juni 2008 een inleiding op IT opdrachtgeverschap en waarin hij opdrachtgeverschap definieert, positioneert en aandachtspunten geeft voor zowel de opdrachtgever als de opdrachtnemer.

IT Opdrachtgeverschap is volgens Otter "het richting geven, aansturen en bewaken van de IT-activiteiten van een organisatie en het onderhouden van de relatie met leveranciers".

Otter positioneert opdrachtgeverschap ("Regie") allereerst tussen de bedrijfsvoering en technologie:

Met de bovenstaande figuur lijkt Otter het zwaartepunt van opdrachtgeverschap te plotten op 'tactisch' niveau; ookwel 'inrichten' genoemd:

In het onderstaande negenvlak voorziet Otter opdrachtgeverschap van een bredere context en geeft hij aan dat het bij opdrachtgeverschap vooral gaat om het "ontwerpen en plannen informatievoorziening en regie". Het werkt wel verwarrend dat hij de term "Regie" gebruikt voor de hele tweede kolom, maar het is wel een verhelderende invulling van het bekende negenvlaksmodel.

Aandachtspunten voor de opdrachtgever

1. Formuleer heldere eisen.

2. Stel de juiste vragen.

3. Kom niet met nieuwe eisen tijdens het project.

4. Focus op strategische waarde IT.

5. Zorg voor voldoende onderlinge afstemming tussen IT-projecten.

6. Realiseer je dat uitbesteden geen problemen oplost.

7. Wees je bewust dat de aanbesteding(sregels) geen garantie zijn voor succes.

8. Gebruik prijs niet als hoofdcriterium bij gunning.

9. Zorg ervoor dat het mandaat niet versnipperd is.

10. Voorkom dat je een speelbal wordt van de leverancier.

11. Zorg ervoor dat je kennis hebt van de (on)mogelijkheden van ICT.

12. Wees je bewust van risico’s (kosten/baten).

13. Zorg ervoor dat je in staat bent oplossingen te beoordelen.

Aandachtspunten voor opdrachtnemer

1. Spreek de taal van de business (en dus niet in vaktaal).

2. Geef de juiste antwoorden.

3. Beoefen de kunst van het binnenkomen.

4. Beoefen de kunst van het binnenblijven.

5. Voorkom dat als sprake is van meerdere leveranciers onduidelijk is wie de baas is.

6. Zorg voor voldoende kennis van het proces van de opdrachtgever.

7. Wissel niet te veel in de bezetting (klassieke 'wissel-truc': senior wordt junior).

8. Voorkom dat je als leverancier opdracht bepaalt (gebruik de opdrachtgever niet als speelbal).

9. Focus niet alleen op de realisatie van het project.

10. Voorkom dat je steeds in situationele relatie(s) zit met opdrachtgever.

Bron: http://www.dnv.nl/binaries/opdrachtgeverschap_tcm141-322729.pdf