Een specialist in een ziekenhuis heeft een afgebakend vakgebied. Als hij of zij zich voorstelt als KNO-arts weet u waar hij u mee kan helpen. Ook heeft u ook een aardig idee wat buiten zijn vakgebied valt. Van specialisten binnen de it-sector is dat vaak veel minder duidelijk. Dit moet veranderen.
Zoveel anders dan in een ziekenhuis gaat het in de it-sector. Menigeen weet inmiddels wel wat het werk van een programmeur of ontwerper omvat. Functiebenamingen worden in toenemende mate echter vervangen door ‘modernere’ varianten zoals business analist, business intelligence architect, et cetera. Het wordt hoog tijd dat we elkaar beter begrijpen en duidelijkere afspraken maken over de wat ons vakgebied omvat en wat er buiten valt. In de context van de boodschap beperkt dit artikel zich tot de besturing van it. Dit neemt niet weg dat de boodschap breder kan worden toegepast dan hier wordt geschetst.
Een samenhangende besturing van IT
Het toenemende gebruik van concepten als sourcing, de cloud en ‘X’aas resulteert in forse veranderingen binnen de it-functie van menige organisatie. Systeem integratie wordt service integratie en het belang van een adequate besturing neemt verder toe.
Integratie en samenhang zijn populaire termen om een organisatie te helpen het hoofd te bieden aan de toenemende complexiteit. Net als er ooit een tijd was dat iedereen zich manager ging noemen zo zie je nu een wildgroei aan architectuur-, portfolio- en governance rollen ontstaan. Zo kent besturing zijn verschillende eilandjes waarbij iedereen vanuit zijn eigen vakgebied roept wat er moet gebeuren. Wat in de praktijk opvalt is dat er nogal verschillende ideeën zijn over wat er wel of juist niet tot een vakgebied behoren. Menigeen kan door de bomen het bos niet meer zien en dit geldt zowel voor medewerkers binnen als buiten de IT.
Elk vakgebied zijn eigen oplossing
Een belangrijke oorzaak hiervan is dat veel vakgebieden zichzelf beschouwen als het middelpunt van de ‘wereld’. Elk vakgebied beschrijft een recept of ‘oplossing’ waarin het vakgebied zelf centraal staat. Dit maakt integratie verre van eenvoudig. Om maar enkele voorbeelden te noemen:
– TOGAF voor architectuur van de Open group;
– PRINCE2, MSPTM en P3O gebaseerd op het gedachtegoed van OGC ;
– Cobit, Val IT en Risk IT voor it-governance van het ITGI .
Een organisatie met een beetje omvang ontkomt er niet aan aandacht te besteden aan bijvoorbeeld architectuur, portfoliomanagement en governance. Het kan hiervoor alles zelf ontwikkelen maar kiest meestal voor hergebruik op basis van enkele marktstandaarden zoals TOGAF, P3O of Cobit. Vervolgens staat de organisatie voor de uitdaging deze omvangrijke standaarden te integreren. Het probleem is dat ze vrij complex zijn, elkaar deels overlappen en meestal niet goed op elkaar aansluiten. Organisaties hebben juist behoefte aan eenvoud en beter geïntegreerde oplossingen.
De besturingsparaplu
Een eerste stap in de goede richting is om te vertrekken vanuit een gemeenschappelijk vertrekpunt. Een voorbeeld van zo’n gemeenschappelijk vertrekpunt is besturing. Dit noemen we de besturingsparaplu:
Het principe van de besturingsparaplu komt neer op het hanteren van de besturing van it als gemeenschappelijk perspectief voor integratie. De besturingsparaplu wordt hiermee de ‘oplossing’ voor de besturing van de it-functie. Geen integratie van alles, want dat is ook niet mogelijk, maar wel de integratie van die elementen die ook daadwerkelijk bij elkaar horen als we het hebben over besturen. Elementen waarover al eerder vertelt is dat het de kunst is deze eenvoudig te houden. Het doel is tenslotte een eenvoudige besturing, maar wel een besturing die werkt!
Het is ondoenlijk om bij de ontwikkeling van de betrokken vakgebieden alle neuzen in dezelfde richting te laten wijzen. Een stuk eenvoudiger is het om een vertaling te maken van de relevante vakgebieden vanuit een gemeenschappelijk perspectief (besturing) en dit te combineren tot een praktisch geheel. De uitwerking hiervan is eigenlijk helemaal niet zo moeilijk, maar vergt wel duidelijke afspraken over de afbakening per vakgebied. Juist hier gaat het in de praktijk vaak fout.
Twee voorbeelden:
– Een architect heeft een set van gedetailleerde architectuurplaten uitgewerkt over de huidige en de gewenste situatie. Hij heeft goed werk geleverd. In de praktijk blijkt echter dat projecten zich niet aan de architectuur houden.
– Tijdens het portfolio-overleg wordt een projectvoorstel besproken. Er is nog voldoende geld beschikbaar en de business case zit goed in elkaar. Toch wordt de business case niet geaccordeerd en voor een ander voorstel gekozen. Als motivatie wordt gegeven dat de beslissers niet geloven dat de business case wordt waargemaakt.
Voor beide voorbeelden is de vraag natuurlijk: wiens probleem is de ontstane situatie? In de praktijk blijken de meningen hierover nogal eens te verschillen.
In het eerste voorbeeld moet de architect zijn visie natuurlijk goed kunnen uitleggen en verdedigen. Ook is het tegenwoordig gangbaar dat projecten geholpen worden met de toepassing van architectuur door middel van een project-start-architectuur (PSA). Maar als hij zijn werk goed heeft gedaan blijft het de verantwoordelijkheid van de bestuurders er voor te zorgen dat men er zich ook aan houdt. De architect hiermee belasten is niet de meest effectieve oplossing. Een spijker kun je met een tang in een stuk hout slaan maar een hamer is stukken effectiever!
Bij het tweede voorbeeld laten we bedrijfspolitieke overwegingen buiten beschouwing, al spelen die natuurlijk vaak een rol. Het gaat in dit voorbeeld om de motivatie waarom de business case wordt afgekeurd: de beslissers geloven er niet in. Dat kan liggen aan de kwaliteit van de onderbouwing maar vaak is er nog wat anders aan de hand. Het presenteren van een business case is gewoon te vrijblijvend voor de betrokkenen! De business case wordt vooral gebruikt om het project te mogen starten. Duidelijke afspraken over wie er verantwoordelijk voor is dat de baten ook daadwerkelijk worden gerealiseerd ontbreken in de praktijk regelmatig.
Vaak wordt binnen één vakgebied gezocht naar een ‘oplossing’ voor veel te veel verschillende soorten problemen. Dit lijkt op de specialist in een ziekenhuis die elke patiënt wil genezen. De oplossing begint met het maken van duidelijke afspraken welke competenties nodig zijn, welke rollen en functies hierbij horen en hoe deze elkaar aanvullen.
Kortom pas de vakgebieden toe waarvoor ze het best geschikt zijn. Bijvoorbeeld: architectuur om de samenhang in beeld te brengen, portfoliomanagement voor kwantitatieve informatie ten behoeve van de besluitvorming en governance voor de inrichting van de besturing. Een belangrijke vaardigheid van de specialist is, dat hij ook weet wanneer hij een patiënt moet doorverwijzen. Binnen de IT sector doen wij dit onvoldoende.
