De parlementaire commissie Elias heeft aangetoond dat ICT governance een onderbelicht onderwerp is. Dat geldt niet alleen voor de overheid maar ook voor het bedrijfsleven. Het komt te vaak voor dat de governance (besturing) van ICT niet goed is ingericht. Hierdoor sluit ICT onvoldoende aan op de bedrijfsdoelstellingen van een organisatie. Terwijl overal om ons heen duidelijk te zien is wat het belang van ICT is, hebben bestuurders nog steeds moeite om te wennen aan het ICT jargon, de ingewikkeldheid en de risico’s verbonden aan ICT projecten. Het liefst besteden bestuurders het uit of delegeren zij het weg, bijvoorbeeld naar een CFO of een COO. Immers de onderneming moet bezig zijn met handel, productie en niet met ICT. Toch is er veel voor te zeggen om hier nog eens bij stil te staan. Er is immers geen handel en geen productie zonder ICT. Het is echter eigen aan bestuurders om gericht te zijn op mensen, klanten en medewerkers en minder op technologische ontwikkelingen die snel veranderen en toegepaste technologie die gegoten is in beton, duur is en moeizaam zijn geld opbrengt, niet doet wat het moet doen en diep in de onderneming is geworteld. Zowel bij de (semi)overheid als bij bedrijven en coöperaties. Laten we dit eens nader bekijken en in een begrijpelijk en eenvoudig perspectief zetten. Wij gebruiken daarvoor een belangendriehoek die beschrijft hoe de besluitvorming gelaagd kan zijn per onderwerp (beleid-projecten-changes- incidenten). Verder gaan we in op projectmatig werken omdat dat immers van belang is bij het managen van veranderingen. Na de oplevering van het project komt het functioneel beheer te liggen in de lijn en het technisch beheer bij ICT. In het eerste artikel werd al beschreven dat het werken onder architectuur noodzakelijk is om een open visie te houden op de toekomst. Hierna gaan we in op het belang van interne service level overeenkomsten en het hebben van een service catalogus. Tot slot bespreken we de sleutel tot beheersing en dat is het demand management overleg.
De drie belangen in balans
Onderstaand model geeft de drie functies weer die een rol spelen in de governance van ICT met ieder een ander belang. Dit zijn de strategiefunctie (top/RvB), de informatiseringsfunctie (lijn) en de automatiseringsfunctie (ICT afdeling). De pijlen geven de onderlinge relaties tussen deze drie functies aan. De top (het hoogste management) zorgt voor regie en kaders op het gebied van beleid, architectuur, standaarden en werkafspraken op voordracht van de IT functie. Binnen deze verhoudingen dient het afstemmingsproces tussen de top, de lijn en de ICT functie te gebeuren.
In veel organisaties is dit model in onbalans geraakt. Een voorbeeld: goede richtinggevende kaders en daadwerkelijke aansturing en prioritering vanuit de top is matig ingevuld en bovendien naar de lijn toe vaak versnipperd en ook nog eens met verschillende prioriteiten. Gevolg is willekeurige en individuele aansturing door management, dus ad hoc. Daardoor krijgt het operationeel management en de ICT functie niet de kaders mee waarbinnen ze moeten bewegen.
De ICT-organisatie heeft beperkingen, dat wil zeggen dat er grenzen zijn aan wat de organisatie doet en kan beheren en ondersteunen. De lijn heeft veel vrijheid waardoor die zich focust op functionele aspecten en het kiezen van oplossingen (applicaties). De ICT organisatie kan dat niet aan en moet vaak nee verkopen vanwege beperkingen in resources, capaciteit of deskundigheid. De effecten hiervan zijn dat de lijn de ICT zelf gaat regelen, met eigen mensen of door inhuur van ICT dienstverleners buiten de ICT organisatie om. Er worden keuzes gemaakt die mogelijk goed zijn voor een gedeelte van de organisatie maar niet voor de gehele organisatie. Zo ontstaat wildgroei in applicaties. De effecten zijn inefficiënte administraties en tekortkomingen in managementinformatie en ondersteuning van het bedrijfsproces. De lijn ontwikkelt een negatief beeld van de ICT organisatie. Dat is onterecht maar een gevolg van gebrekkige regie vanuit de top. De board moet de balans tussen vraag en aanbod herstellen door enerzijds met de lijn realistische ambities af te spreken en de ICT organisatie de ruimte te geven om meer variatie van de vraag aan te kunnen. Het helpt als daarbij de besluitvorming zo wordt ingericht dat er sprake is van gelaagdheid per onderwerp zoals beleid, projecten, changes en incidenten.
Besluitvorming gelaagd per onderwerp
IT kwesties kunnen globaal worden ingedeeld in een hiërarchie van vier onderwerpen: beleid, projecten, changes en incidenten. Het plaatje laat zien hoe governance en intern accountmanagement in een communicatie schema kunnen worden afgebeeld. Kenmerkend is vooral dat we uitgaan van een marktmodel: de verdeling in demand en supply. Vraag en aanbod moeten op elkaar worden afgestemd op de vier niveaus te weten: De board bepaald op strategisch niveau het beleid ofwel de kaders, het budget en de projecten die invulling geven en ondersteunend zijn aan de bedrijfsstrategie. Uit dit beleid volgen projecten die leiden tot veranderingen in de architectuur, die na elke verandering een stabiele fase moet bereiken door het oplossen van incidenten. Daarna zal het management als eigenaar van de projecten tot realisatie moeten overgaan en opdrachten geven tot het wijzigen van de architectuur. Eindgebruikers verhelpen met de IT afdelingen functioneel en technisch applicatie beheer de incidenten op dagelijkse basis.
Projectmatig werken
Het behoeft weinig betoog dat projecten moeten worden gerealiseerd middels projectmatig werken en toch is dat nog steeds een lastig onderwerp. Change management en bedrijfstransformatie zijn als evenknie van beheersing veel interessanter en lastiger. Hoe vaak horen we niet dat een project niet meer onder controle is. In onze praktijk wordt ons met regelmaat gevraagd om deze situaties bij te sturen. Ook is dit niet zelden onderwerp van een interne machtsstrijd. Wie heeft hier nu gelijk? En wie moet welk probleem oplossen? Het lijkt haast onmogelijk dit te combineren in een rol of een governance model. Toch willen we een lans breken voor het volgende model.
Het begint met het instellen van een informatie stuurgroep, voorgezeten door de top om vorm te geven aan het portfolio management van de grote projecten. Dit gremium dwingt ook primair af dat er gewerkt wordt aan de borging van principes van projectmatig werken. Dus eerst de beheersing van tijd, geld, resources en scope regelen en daarna pas zorgen dat het change management en de business transformatie in lijn worden gebracht. Dit voelt paradoxaal aan en vraagt enige wijsheid en stevigheid om overeind te houden. Echter: de kost gaat voor de baat uit.
Om zover te komen is het goed om oog te hebben voor een gefaseerde implementatie van de projectmanagement methode bij top, lijn en ICT. Methode is middel en geen doel! Verder is het goed om voldoende tijd te besteden aan de projectdoelstelling. Deze moet smart zijn. Dus specifiek, meetbaar, acceptabel, realistisch en tijdgebonden. Vervolgens gaat het om de juiste samenstelling van de stuurgroep. Denk hierbij aan sfeerbepalende keuzes als ownership en leiderschap. De temperatuur van een project verschilt nogal eens per fase. Als het senior management geen geloof uitstraalt zullen de medewerkers zich niet achter het project scharen.
Elk project komt tot een einde, goed of slecht. Van elk project kunnen we leren. Het is daarom essentieel om tijd te besteden aan een gezamenlijke terugblik. Er moet ruimte zijn voor evaluatie van projecten en acties voor verbetering.
Als het project is opgeleverd gaan we over tot de volgende stap: beheer. Dat is de grootste kostenpost.
Functioneel en technisch beheer
Hier betreden we de wereld van de afkortingen en het jargon en een vaak onnavolgbare complexiteit. Het betreft functioneel beheer waarvan het eigendom bij de lijn ligt en het technisch beheer waarvan het eigendom bij ICT ligt. Als we aan ICT de functionele toegevoegde waarde component toevoegen praten we over Informatie Voorziening of IV.
We beginnen met het functioneel applicatie beheer ofwel FAB. Dit ziet erop toe dat de systemen voldoen aan de eisen die vanuit het business proces zijn gesteld. Deze unit is het aanspreekpunt voor de gebruikersorganisatie en draagt zorg voor het juiste gebruik en is verantwoordelijk voor functionele acceptatietesten. FAB beslist over wijzigingsverzoeken en stelt prioriteiten binnen de randvoorwaarden van de functie Informatie Voorziening ofwel IV zoals de detaillering van het IV beleid, zorg voor de beschikbare capaciteit en het handhaven van de procedures.
We vervolgen met het technisch applicatie beheer ofwel TAB. Dit ziet erop toe dat de applicatie in technische zin voldoen aan de functionele eisen. TAB is het aanspreekpunt binnen de IV organisatie en draagt zorg voor het beheer zoals dat is afgesproken en de stabiele inrichting daarvan. TAB is verantwoordelijk voor de kwaliteit en uitvoering van de technische acceptatietesten.
FAB en TAB kunnen niet zonder periodiek overleg over wijzigingen. Wat is daarvoor nodig? Ten eerste het opstellen en communiceren van een applicatieoverzicht met contactpersonen aan gebruikers- en IV-zijde en vervolgens het houden van de overleggen. Opgemerkt moet worden dat per applicatie de taken tussen FAB en TAB applicatie beheerders kunnen verschillen. Kantoor applicaties en logistieke applicaties zijn immers niet hetzelfde maar wel verbonden. Die verbondenheid komt tot uitdrukking in de architectuur. In het vorige artikel hebben we hier reeds bij stilgestaan.
Werken onder architectuur
De architectuur moet horizontaal en verticaal kloppen. Processen en functie moeten op elkaar aansluiten en op alle lagen, van infrastructuur tot eindgebruikersplatform, samenwerken om tot een geïntegreerd product of dienst te komen.
Architectuur is een bijzonder belangrijk strategisch concept en stuurmiddel. Architectuur is het geheel aan middelen dat mensen gebruiken om functies aan te spreken. Functies vormen een essentieel onderdeel van processen zoals het primaire bedrijfsproces. Functies worden beschikbaar gesteld middels een infrastructuur van gegevensbronnen, programma’s en hardware waaronder middelen om data te transporteren. Deze lagen moeten horizontaal en verticaal op elkaar aansluiten.
Simpel gezegd: bedrijfsprocessen, software of applicaties en hardware of de technische infrastructuur. Nog simpeler: de business, de programma’s en het ketelhuis. Het is goed om een afbeeldingstechniek of methode te kiezen en alle discussies te laten afbeelden in eenvoudige plaatjes om scherp te krijgen hoe functies samenhangen en welke relaties er bestaan en gaan veranderen. Er wordt gemakkelijk iets vergeten of dubbel gedaan. Aan de hand van deze simpele plaatjes kan de discussie scherp en integer gevoerd worden.
Interne Sla’s en service catalogus
De meeste organisaties willen werken met een diensten- en productencatalogus, service level overeenkomsten (Sla’s) en een prijskaartje. Prijzen zijn belangrijk in verband met doorbelastingen, activering van kosten en show back. Toch is zo’n catalogus meestal niet aanwezig omdat er geen tijd aan wordt besteed. De kosten van IT lopen dan al snel uit de hand. Het is de moeite waard om deze instrumenten in te richten. Overigens worden het project management office en daarbij inbegrepen de control functie vaak zeer zwak ingevuld. Deze overhead is, mits goed ingericht, het geld meer dan waard. In dit kader is het bijvoorbeeld zinvol om functies in te richten als vendor management en performance dashboarding of kpi reporting als het gaat om verdere industrialisatie. Op basis van deze voortgangs- en efficiëntierapportages kan het demand overleg met de eindgebruikers, senior management, de board en de raad van bestuur systematisch en onderbouwd worden ingericht.
Demand management overleg
In de Board, de raad van bestuur en met het senior management wordt overleg gevoerd over de volgende stappen in het uitrolschema, de verdere uitbouw van de architectuur, de volgende behoefte vanuit de bedrijfsvoering en de groeistrategie van het bedrijf. Dit overleg moet zorgvuldig en met aandacht worden gevoerd, op basis van schema’s, een gestructureerde agenda en voortgangsrapportages.
What’s next? Na al deze inspanningen komt het ongeduld en de zorg om de continuïteit. Het gaat hier om reputaties, beloftes en commitments. Meerjarige programma’s kunnen leiden tot fatigue: projectmoeheid. Het is immers niet zelden avond- en weekendwerk. Vier daarom samen uw successen.
Governance: een voorkeurs oplossing
Wat is nu het beste model? De CIO in de board, een IT commissaris of een non executive IT director met een IT manager in de lijn? Plus de voorzieningen die hierboven zijn beschreven? Het maakt niet uit. Zolang de principes van gedegen governance maar worden toegepast!
Auteurs: Peter van der Veer & Henk Zomer