Lessen uit ICT-projecten bij de overheid

De Algemene Rekenkamer (http://www.rekenkamer.nl) heeft op 29 november aan de Tweede Kamer een eerste rapport opgeleverd over de mislukte IT-projecten bij de overheid sinds het jaar 2000: http://www.rekenkamer.nl/9282000/d/ p425_rapport1.pdf.
Aanleiding tot haar onderzoek was een artikel in Trouw: http://www.trouw.nl/hetnieuws/economie/ article723232.ece#readmore. Hier komen twee hoogleraren aan het woord (Jan Friso Groote en Chris Verhoef), die op grond van metrieken beschouwingen tot uitspraken komen over de mogelijke omvang van de mislukte projecten. Hun onderbouwingen zijn enigszins twijfelachtig. Interessant en veel realistischer vond ik de beschouwing van Bas Linders in zijn blog http://www.blproductions.nl/ kamer_kijk_eens_in_de_spiegel.

Volgens mij zijn er geen ingewikkelde beschouwingen nodig met software metrieken om te kunnen constateren wat er mis is met de automatisering bij de overheid en wat er aan gedaan zou moeten worden.
Twee belangrijke zaken moeten worden geregeld: IT-Governance en Digitale Architectuur.
Om die laatst genoemde maatregel, het opstellen van een digitale architectuur, start ik in dit E-Magazine een forumdiscussie over het rapport van de Algemene Rekenkamer. Graag verneem ik van jullie of jullie nog andere oorzaken zien van het mislukken van projecten bij de overheid dan de Algemene Rekenkamer heeft opgesomd. Kijk s.v.p. ook even in de Automatisering Gids van 30 november op de voorpagina 'Rekenkamerrapport laat feilen in opdrachtgeverschap onderbelicht " onkunde, onwil, opportunisme'
Als tweede vraag zou ik van jullie willen weten welke maatregelen de overheid dient te nemen om mislukkingen te voorkomen of de gevolgen te verkleinen. Kijk s.v.p. ook even in de Automatisering Gids van 7 december op de voorpagina en pagina 7.

Mijn persoonlijke drijfveer achter deze discussie is mijn hoop op een slanke, flexibele, burgervriendelijke overheid voor mijn kleinkinderen. Door de juiste IT-enabling is dat zeer zeker mogelijk, maar in de transformatiefase moet een berg aan oude structuren, oude procedures, fysieke dossiers, oude ambtelijke patronen etc. etc. worden geslecht. Hiervoor zijn opdrachtgevers vereist die houden van eenvoudige oplossingen en een nuchter, zakelijk projectmanagement. Voorts is een goede digitale architectuur een absolute must.

Post edited by: architectuur, at: 2007/12/14 10:06

Hieronder een eerste poging om commentaar te leveren op het rapport van de Algemene Rekenkamer 'Lessen uit ICT-projecten bij de overheid; deel A'

De taalzetting van de Algemene Rekenkamer is nogal diplomatiek. Daarmee bedoel ik: correct, maar alle partijen sparend. Dit heeft als nadeel dat men nog te veel kanten op kan met de observaties en aanbevelingen. Ik bespeur ook in de reactie van de minister dat zij nog niet de echte sense-of-urgency lijkt te voelen. Voorts blijkt uit de lange literatuuropgave bij het rapport dat de Algemene Rekenkamer al vele malen heeft gewaarschuwd voor misstanden die zich hebben voorgedaan bij grote IT-projecten in de overheid. Het effect daarvan is tot nog toe 0,0.
Mijn advies aan de Algemene Rekenkamer: houd op met lief zijn! Leg duidelijker de schuld neer. Hoe vaak is al niet gesteld dat de Tweede Kamer moet ophouden als een verwend kind allerlei zaken te wensen. Wens niet meer dan je eigen portemonnee groot is. Goed nieuws is dat CDA en SP een parlementair onderzoek willen naar IT-projecten bij de overheid. Ik ben razend benieuwd of dat er werkelijk komt en of dan de onderste steen boven zal komen.

Hoe kan een groot project dat aan het mislukken is weer op de rails worden gezet?
De volgende stappen:
1. De hoogste opdrachtgever geeft onomwonden, en plein publique, toe dat het project daadwerkelijk is mislukt.
2. Een extern bureau (niet zijnde een bouwer/provider) neemt voor een periode van ongeveer zes maanden het roer over met volledige bevoegdheid, carte blanche dus.
3. Dat bureau zet een zeer ervaren projectleider neer met duidelijk mandaat en installeert een eigen, extern projectbureau.
4. Na dat halfjaar wordt het project weer teruggegeven aan de organisatie met duidelijke richtlijnen om het op de rails te houden.
Het moeilijkste hierbij is punt 1. Ik heb zelden een politicus/hoge ambtenaar schuld zien bekennen. Er wordt altijd een beetje om de hete brij heen gedanst.

De Algemene Rekenkamer onderscheidt drie soorten actoren (zeg maar key p_layer_s): de minister, de Tweede Kamer en de ICT-leveranciers. Ik mis daarbij de (digitale) architecten. Belangrijker dan een goede relatie tussen opdrachtgever (i.c. de minister) en de ICT-leverancier(s), vind ik de relatie tussen de opdrachtgever en de architect. Ik zie bij de overheid nauwelijks digitale architecten die worden vertrouwd door de opdrachtgever. Er worden dealtjes afgesloten tussen opdrachtgever en ICT-leveranciers. Die laatsten, zoals de Algemene Rekenkamer ook in haar rapport weergeeft, houden er soms hun eigen agenda op na. Dit wordt mede gestimuleerd omdat de overheid op een te vrijblijvende manier werk uitbesteed (zwak opdrachtgeverschap).
De Algemene Rekenkamer stelt expliciet dat boven genoemde drie partijen elkaar gevangen houden in soms te hoge ambities, daar ben ik het roerend mee eens. Zet daarom die digitale architect er tussen. Een opdrachtgever wenst vaak een droomkasteel, een bouwer/ICT-leverancier heeft soms de neiging een kaartenhuis te leveren. De architect zit daar tussen in en zorgt voor een bruikbaar, maakbaar product met een gezonde dosis beleving (lees Menselijke Maat).

De Algemene Rekenkamer stelt voorts dat je de spiraal van steeds hogere ambities zou kunnen doorbreken door de minister daar nadrukkelijker op aan te spreken. Bij een juridisch conflict staat de rechter echter meestal aan de kant van de zwakste partij, de sterkste partij had de ander moeten voorlichten/adviseren/helpen op het rechte pad te blijven. Daarom zou ik zeggen dat je de spiraal doorbreekt door de ICT-leverancier explicieter verantwoordelijk te maken voor het resultaat. Zo concreet zelfs dat zij in de toekomst weigeren om al te complexe dan wel overambitieuze zaken aan te nemen. Trouwens als je het _object_ief bekijkt zijn de grote IT-leveranciers toch op z'n minst medeschuldig aan de ontstane situatie bij de overheid, of niet soms?

Ik vind het heel goed dat de Algemene Rekenkamer in paragraaf 1.2 het lawaai in Trouw aan de kaak stelt. Je kunt toch niet op grond van gedateerde gegevens, uit een andere cultuur een metriekencircus optuigen aangaande software engineering en daaruit conclusies trekken over opdracht-/projectmanagementachtige zaken. De beide hoogleraren waarop Trouw zich _base_ert hebben wellicht hun sporen verdiend in software engineering en _embed_ded systems, maar bij mij weten nog nooit wat gedaan op het gebied van projectmanagement. Hun conclusies zijn ge_base_erd op drijfzand. Trouw had dat moeten natrekken!
Overigens denk ik dat de omvang van de mislukte overheidsprojecten ergens ligt tussen de calculatie in Trouw en de schatting van de Algemeen Rekenkamer. Ik vermoed dat de Trouw-hoogleraren nogal onnauwkeurig en weinig wetenschappelijke bezig zijn geweest. Aan de andere kant denk ik dat de Algemene Rekenkamer niet ver genoeg heeft gekeken. In zijn column, getiteld 'Hulp gevraagd bij inventarisatie' van 16 november vraagt Chris Verhoef niet voor niets of een ieder hem informatie wil sturen over de grote mislukte IT-projecten bij de overheid. De lijst is nog lang niet compleet en er is een groot interpretatieverschil in wat gelukt en wat mislukt is. De overheid doet het wellicht rooskleuriger voorkomen dan het in werkelijkheid is.

Ik vind bijlage 1 'Overzicht van conclusies, aanbevelingen' te summier verwoord. Het rapport is beter dan deze bijlage. Dit is jammer. Te meer daar veel beleidsmakers wellicht dit belangrijke rapport niet echt lezen, maar alleen de samenvatting en bijlage 1.
De opmerking van de minister dat zij het vervolgonderzoek afwacht, vind ik onbegrijpelijk. Gaan wij nog zes maanden zitten wachten met het aanpakken van de grote problemen bij de overheidsautomatisering?

Als ik de vijf belangrijkste succesfactoren mag noemen die ik in de praktijk ben tegen gekomen bij grootschalige automatisering:
1. Heldere, eenvoudige, zakelijke IT-Governance.
2. Digitale Architectuur.
3. Zakelijk opdrachtgeverschap.
4. Opdeling van programma's en projecten. Sturing op basis van een zakelijke business case en benefit tracking.
5. Duidelijk auditschema; 5 soorten auditinstrumenten: voor, tijdens en na het project.

Ik vind het jammer dat er geen maatregelen zijn opgesomd voor de korte termijn (lees: direct ingaand!). Of komt dat pas in rapport B over een half jaar?
Mijn persoonlijke filosofie luidt dat je eerst de kraan dicht draait alvorens te beginnen met dweilen. Wat betekent dit:
1. Zakelijke audits wellicht onder de supervisie van de Algemene Rekenkamer, waarvan de resultaten worden gepubliceerd op de externe website van de Algemene Rekenkamer.
2. Verbetering opdrachtgeverschap, door een aantal personal IT-coaches neer te zetten bij de belangrijkste opdrachtgevers binnen de overheid.
Voor de middellange termijn (lees: binnen een halfjaar!) zou ik de volgende maatregelen nemen:
1. Opzetten/afstoffen van de IT-Governance, inclusief een CIO gepositioneerd in het ministerie van Algemene Zaken.
2. Opzetten van een volwassen architectuurfunctie, inclusief een Digitale Rijksbouwmeester (zie http://www.via-nova-architectura.org/forum/view- 5.html) ook gepositioneerd in het ministerie van Algemene Zaken.
3. Inrichten van Shared Services Centra voor de overheid (evt. joint ventures met providers). De overheid is groot genoeg om niet te hoeven outsourcen

Ik begrijp trouwens niet dat er zo weinig aandacht in het rapport wordt geschonken aan de noodzaak van digitale architectuur. Zonder digitale architectuur zal de overheid nooit als een geheel kunnen gaan functioneren.
Ook vind ik dat er te weinig concrete opmerkingen over de te zwakke IT-Governance in het rapport worden geplaatst. In sommige situaties zie je bij de overheid een zeer groot aantal stuurgroepen over elkaar heen en is het niet meer duidelijk waar de echte besluitvorming plaats vindt. Ook zie ik soms een te grote macht bij zogenaamde stafafdelingen, waardoor de voortgang van een project wordt belemmerd/gefrustreerd.

Als ik de verschillende IT-producten en documenten van de overheid analyseer, krijg ik het gevoel dat er zeer capabele (IT-)professionals werkzaam zijn bij de overheid maar dat het mist aan regie. Die zou moeten worden hersteld met externe hulp. Ik vind het daarom weinig realistisch dat Jan Kees de Jager in een interview met Computable (16 november 2007, pagina 17) stelt geen externe regieorganisatie te willen opzetten om de Belastingdienst uit de problemen te halen. Ongetwijfeld heeft de Belastingdienst vele, uiterst competente professionals. Zij zijn echter zo ondergesneeuwd door de bestaande gang van zaken en gevangen in het politieke spel van het moment, dat het nauwelijks doenbaar is om het roer resoluut om te gooien. Daar is echt externe assistentie voor nodig. De Belastingdienst, in het bijzonder haar IT-functie, moet weer terug van horizontale, collegiale besluitvorming naar verticale, hierarchische aansturing. Anders is geen deugdelijke IT-Governance te implementeren.

Het zou overigens een zeer interessante exercitie zijn de observaties en aanbevelingen van het rapport van de Algemene Rekenkamer eens toe te passen op het Toeslagensysteem dat bij de Belastingdienst op 1 januari 2009 operationeel dient te zijn. Dit is een uiterst politiekkritisch systeem.

-------------------------------------------------- -------------------------------------------------- ----

Bijlage: kleine inhoudelijke opmerkingen in het rapport

In plaats van de opmerking op pagina 4 'ICT is geen quick fix voor een probleem', had ik neergezet 'ICT is geen oplossing voor een business probleem, op z'n hoogst een meer efficiente invulling'.

Op pagina 6 had ik expliciet neergezet dat de gevolgschade van mislukte projecten ook aanzienlijk is. Om te transformeren naar een slankere, meer flexibele overheid is een weloverwogen applicatielandschap nodig. Het uitstellen daarvan kost heel veel geld.

Op pagina 12 wordt een ICT-project duidelijk gedefinieerd. Gezien de opdracht van de Tweede Kamer had ik wel verwacht dat de Algemene Rekenkamer ook grote outsourcingsdeals in haar beschouwing zou hebben meegenomen. Ik heb de indruk dat de Algemene Rekenkamer dat niet heeft gedaan. Ik vraag mij af wat daar de reden voor is?

De opmerking op pagina 20 dat ICT-systemen relatief rigide zijn, vind ik onbegrijpelijk. Software is flexibeler dan beton. Dus, mits goed en onder architectuur geconcipieerd, kan een informatiesysteem uiterst adaptief zijn.

De opmerking op pagina 21 dat men last heeft van de snelle ontwikkelingen in het vakgebied, in het bijzonder de technologische mogelijkheden, is geen enkel argument voor mislukte IT-projecten. Een goede digitale architectuur borgt immers toekomstvastheid. Dus er zou hier moeten staan dat bij de overheid de architectuur nog onvoldoende op toekomstvastheid wordt gevalideerd.
Onderaan diezelfde pagina staat dat standaard software een oplossing is om complexiteit te reduceren. Dit hoeft niet waar te zijn. Juiste modularisatie of componentisering kan complexiteit reduceren. Standaard software zorgt dat de software sneller en vaak tegen betere kwaliteit kan worden geimplementeerd.

Op pagina 22 wordt gewag gemaakt dat sommige zaken voor alle burgers tegelijkertijd moeten worden uitgevoerd. Dit is niet complex, maar massaal. Daar zijn andere oplossingsmogelijkheden voor, die veel simpeler zijn dan het reduceren van complexiteit.

Beste Daan,


Een paar opmerkingen over je reactie:

1. Als je wil dat met vingers gewezen wordt naar schuldigen, dan zal je vooral de IT-leveranciers gaan aanwijzen en in veel mindere mate de vragende overheid. De IT push is gewoon veel en veel te groot en overspoelt een degelijke vraagstelling. Natuurlijk is goed opdrachtgeverschap belangrijk, en daar bestaan ook reeksen problemen. Maar het is niet de belangrijkste oorzaak waarom IT-projecten fout gaan.

2. Ja, het wordt inderdaad tijd dat er een Parlementaire Enquete IT komt. Als dat goed gebeurd zullen de kosten daarvan teruggehaald worden in de opbrengsten in de verbeteringen die resulteren.

3. Je idee om projecten die fout gaan voor 6 maanden onder controle van een derde met carte blanche te geven is ridicuul. Alleen al de vraag wat die derde dan gaat doen, wie dat gaat betalen en wat dan bereikt moet worden is volledig onduidelijk. Sterker nog, het is vrijwel onmogelijk dat dat ergens toe gaat leiden. Laat de controle van projecten alsjeblieft bij de vragende organisatie en denk niet dat een Deus-Ex-Machina bestaat.

4. Jij noemt IT-architecten of personal IT-coaches digitale architecten. IT is echter niet waar je dit soort problemen mee oplost. Wat nodig is is de juiste kennis van de informatie van een organisatie als (4e) bedrijfsmiddel. Die kennis kan je niet buiten een organisatie beleggen. Het is dus niet een "digitale architect" die hier nodig is, maar een informatiekundige die sub-strategisch werkt en op alle niveaus in de organisatie bezig zal zijn. Pas als daar de kracht mee ontwikkeld is kan echt iets met IT of een digitale wereld gedaan worden. En in de tussentijd zo goed en zo kwaad als dat gaat gewerkt moeten worden.

5. IT-governance is tactisch management.

6. Nederland (en andere landen) hebben geen behoefte aan een digitale bouwmeester. Als zo iemand er al zou moeten zijn, dan via een organisatie als ICT~office. Alleen wordt dan het coordineren van de activiteiten van IT-leveranciers wel erg duidelijk, zodat we iets vergelijkbaars krijgen als wat in de bouwfraude enquete als probleem boven tafel is gekomen.

7. Een CIO is maar zeer ten dele manager van IT of van een digitale wereld. Dat is maar een klein deel van haar of zijn werk.

8. Het is verbazend dat de Rekenkamer alleen naar IT-projecten kijkt, en niet naar de exploitatie. Dat is toch 70 a 80 procent van de totale kosten.


Steven van 't Veld

Steven,

Dank voor je opmerkingen. Ik ben het met enkele eens, bij de andere bespeur ik dat jij zaken anders leest dan ik bedoel.

Ad 1: Er staat toch duidelijk in mijn tekst dat de IT-leveranciers explicieter verantwoordelijk dienen te worden gesteld. Zo concreet zelfs dat zij in de toekomst weigeren om al te complexe dan wel overambitieuze zaken aan te nemen. Voorts staat er toch dat ik vind dat de grote IT-leveranciers op z'n minst medeschuldig zijn aan de ontstane situatie bij de overheid.
Dit heb ik ook al een aantal keren recent in de Automatisering Gids geschreven. Maar noch de grote IT-leveranciers, noch het ICT~Office liggen daar wakker van.

Ad 2: Ook ik hoop op een parlementaire enquete. Maar ik vraag mij af of die er werkelijk komt. Volgens mij heeft de SP er wel zin in. Ik hoor niets meer van het CDA en de PvdA zit er met de huidige problemen (minister van BZK en DG/Belastingen) zeker niet op te wachten.

Ad 3: Uit deze reactie blijkt dat je weinig daadwerkelijke ervaring hebt in het weer op de rails zetten van mislukkende projecten. Het lijkt mij onredelijk aan te nemen dat zij die het project hebben laten ontsporen, de kracht en discipline hebben om de zaak weer op de rails te zetten. Zie ook mijn opmerkingen over Jan Kees de Jager en de regieorganisatie van de Belastingdienst.

Ad 4: Ik denk dat je hier terminologisch het een en ander door elkaar haalt.
In mijn verschillende recente publicaties in de Automatisering Gids geef ik duidelijk aan dat de problemen liggen in een verkeerde formulering van het business probleem. Dus niet primair in de IT. Wat ik onder digitale architectuur versta kan je zien op de website http://www.digital-architecture.net. Een personal IT-coach is geen digitale architect, heb ik ook nergens beweerd.
In SDM-1 stond reeds de wijze raad: reorganiseer eerst, alvorens je gaat automatiseren, anders ben je de chaos aan het automatiseren. Dit geldt nog steeds. Eerst het business probleem duidelijk krijgen, daarna het informatieverkeer op orde brengen en dan kan je IT gaan toepassen. IT is slechts een middel tot efficiency verhoging.

Ad 5: Natuurlijk, want IT-Governance is een inrichtingszaak!

Ad 6: Jouw suggestie om de digitale Rijksbouwmeester te plaatsen bij ICT~Office is net zo geloofwaardig als dat wij de fysieke Rijksbouwmeester zouden plaatsen bij Bouwend Nederland de club van Eelco Brinkman. Ik neem aan dat je hier het een en ander door elkaar hebt gehaald.

Ad 7: Het managen van het informatieverkeer is wel zijn/haar primaire taak. Natuurlijk kunnen er wat bijtaken zijn.

Ad 8: Ben ik roerend met je eens. Daar ligt ook wellicht de oorzaak van de miscalculatie van Chris Verhoef. Persoonlijk heb ik de Rekenkamer ook geadviseerd om de outsourcingsrelaties ook mee te nemen in haar beschouwingen.

Post edited by: architectuur, at: 2007/12/18 21:08

Beste Daan,

Ik heb geen idee meer hoe het hier werkt. Alles lijkt er dubbel op te staan. Maar goed, ik pak maar een thread en zie wel waar we uitkomen. Tenminste, als ik je antwoord ergens terug kan vinden.

Mooi als we het eens zijn. Als ik iets anders lees dan jij bedoelt, dan ben ik benieuwd wat je bedoelt.

Ik volg mijn punten, zoals jij dat ook gedaan hebt.

Ad 1: IT-leveranciers zijn grote spelers in dit gebeuren. Zij hebben macht tot in de haarvaten van de samenleving en daar worden we niet gelukkig van. IT-leveranciers (softwarehuizen, systeemhuizen, IT-consultancy bureaus en IT-opleidingsinstituten) zijn immers de aannemers van de IT-wereld. Zij hebben baat bij het leveren van hun ideeen over IT, en die zijn vrijwel altijd en vaak met opzet anders dan die van de concurrenten. Volgens mij onderschatten zij hun rol, cq, vervelend geformuleerd, kennen zij hun rol en gebruiken zij die. Ik heb de laatste jaren echt honderden organisaties gezien, en overal zijn vergelijkbare problemen. En die zijn veroorzaakt door, vooral, het project denken van IT-leveranciers.
Je moet het, als vrager, niet aan je aannemer overlaten om grotere projecten te weigeren. Juist omdat het fout gaat wordt daar geld verdiend, dus waarom zou je als aannemer dat soort werk afwijzen? Je laat het toch ook niet aan je kinderden over om een te hoog zakgeld af te wijzen?
IT-leveranciers hebben geen historie in dienstbaar zijn. 70 jaar in een steeds belangrijker wordend glazen huis heeft dat veroorzaakt. Als je vergelijkbare industrieen bekijkt, dan is de IT-sector volledig doorgeschoten. En die slinger komt echt terug, waarbij de zaak hopelijk niet weer geheel doorschiet naar de andere kant.
Je vertelt me hier dat je mening over IT-leveranciers anders is dan ik gelezen heb. In alle eerlijkheid: het past niet bij je achtergrond. Maar goed, ik ben er blij mee en ben het dus met je idee eens. Al heb ik veel teveel gezien om niet heel erg kritisch te zijn.


Ad 2: Een Parlementaire Enquete is een dure zaak, en zal het imago van de professionele IT zeker schaden. Tja, en zo lang Jan Kees nog roept dat SOA de oplossing voor de Belastingdienst is.... Je zou ook gewoon aan het werk kunnen gaan en de zaken wel goed kunnen gaan opzetten. Maar dan moet er wel een zinderende oekaze moeten komen, met een hele grote kans dat ook die niet werkt. Want in Nederland worden nog steeds nergens informatiekundigen opgeleid. Vroeger wel, maar IT, zoals Risseeuw bijvoorbeeld, heeft dat in 1999 teniet kunnen doen. Je kunt verordonneren dan iedereen moet lopen, maar als niemand dat geleerd heeft wordt het hoogstens kruipen. Dus dan misschien toch maar beter een Parlementaire Enquete IT. Maar dan hopelijk wel investeringen EN exploitatie.
De truc van de Rekenkamer om nog een deel B aan te kondigen kan ook wel eens tegenwerken. Want waarom zou je anticiperen op informatie die in de maak is. Wordt dus misschien om die reden medio 2008 voordat de partijen beslissen om al of niet door te drukken.


Ad 3. Tja, ik doe toch al jaren niet veel anders. Denk je heus dat je bijvoorbeeld een project als SPEER weer op de rit kan krijgen door zelf projectleider te worden en carte blanche te krijgen voor een half jaar? Het doel van dat project is nooit IT geweest, altijd logistiek. En dat wordt nu door IT-leveranciers "geregeld". Kom nou, Daan, wil je de Verdonk van de IT worden?


Ad 4. Daan, ik hoef geen college van je te volgen. Ik ken de hoofdlijnen van je ideeen.
Digitaal, persoonlijke IT-coach, IT-architect, Enterprise Architect, Solution Architect en zelfs de IT-definitie van informatiearchitect: het draait maar om een ding: IT. Je hebt absoluut gelijk dat het niet in de IT ligt, al is de hele wereld bezig er IT-problemen en IT-projecten van te maken. Zoals de Rekenkamer ook zegt. Maar het is ook echt geen business-probleem. Dat woord is een dooddoener, een excuus-truus die IT-ers gebruiken. Zeker, er zijn organisaties die hun business niet goed genoeg kennen, maar dan moeten ze zeker geen IT-ers hebben die het op gaan lossen. Daar ga je failliet aan, namelijk. Business analyse is dus ook geen IT-vak. Werkelijke business analyse wordt gedaan door business specialisten. Geinig is dan altijd dat als je gaat praten met goede business specialisten en je open stelt je altijd heel snel kan zien wat je voor hen, als informatiekundige, kunt doen. En vaak is dat juist grip krijgen op die IT-ers die door de organisatie lopen alsof ze de wijsheid in pacht hebben, en daarmee de meest elementaire fouten maken.
Informatiekunde is iets kompleet anders dan IT. Misschien ben je zo langzamerhand de IT, het digitale gekomen en zie je wat bedoeld wordt. Het magische voorbeeld: een bank kan duizenden bedrijfsprocessen hebben, en ondersteund worden door duizenden applicaties, maar een bank werkt al zo'n 5000 jaar met dezelfde 3 soorten informatie. Die zitten dus verspreid over die duizenden applicaties. IT-probleem? Business-probleem? Ja, die zijn gecreeerd. Maar kennis van informatie is iets anders dan hypotheken verstrekken of een applicatie programmeren.
SDM-1 was de beste van de SDM's, en als we die lijn doortrekken zijn we nu aan versie 5 of 6 (incl. IAF en TOGAF). De essentiele fout in SDM zit echter in het in het centrum zetten van projectmatig denken. Dat is dus echt fout, want daarmee creeer je chaos omdat projecten alleen mondjesmaat met elkaar communiceren. Wat je beschrijft is gemiddeld ongeveer 20% van de kosten, en het houdt de 80% in gijzeling. Weet goed dat ik een goede projectaanpak belangrijk vindt, het is echter maar een klein deel van waar we mee bezig zouden moeten zijn. Het is belangrijk omdat IT-aannemers het belangrijk achten omdat ze er geld aan verdienen. Sterker nog, ze verdienen nog meer geld als IT-projecten niet al te goed gaan. Het is echt een absolute denkfout om de verandering in het centrum te zetten, net als dat applicatiegericht denken fout is. A paradigm shift is nodig, maar dan een echte. Kan dat via een Parlementaire Enquete? Misschien.....


Ad 5. Fijn dat je IT-management ook als tactisch management ziet. Maar waarom denken IT-ers dan nog steeds dat de CIO een IT-er is? Waarom is IT strategisch? Jazeker, zoals een vliegtuig voor KLM en een trein voor NS, maar niet als bedrijfsmiddel.


Ad 6. Neen, dat haal ik niet. Maar mijn opmerking was inderdaad nogal cynisch. Vergelijk het eens met HRM en Personeelsbeheer. Personeelsbeheer doe je, net als IT, tactisch, maar HRM zitten de nodige zaken in die strategisch moeten, zelfs afgestemd over organisaties heen. Het is zo ontzettend simpel wat je strategisch rond de informatievoorziening moet doen, en dat heeft echt niet te maken met IT of een digitale wereld. Dat is belangrijk als tweede plan, maar niet essentieel.
Daarom zie ik niet wat een digitale bouwmeester zou moeten doen binnen Nederland. Als zo'n functie al zou moeten gaan bestaan, dan gaat het om het managen van kennis van informatie, en dat heeft niets met digitaal te maken. En in feite ook weinig met bouwmeester, want kennis managen waarmee oplossers, aannemers, aan de gang kunnen om bijvoorbeeld IT-applicaties vorm en inhoud kunnen geven is een kompleet ander soort taak.
Maar misschien zit het gewoon in het woord digitale bouwmeester. Zoals gezegd gaat wat je met zo iemand zou willen niet om digitaal en niet om bouwen.


Ad 7. Neen, een CIO gaat niet alleen over het managen van informatieverkeer. Dat zou wel heel erg beperkt zijn. Die fout wordt trouwens ook in NORA gemaakt met de gegevens-grachten en -rivieren die zij proberen te forceren. CIO is een rol van een strategisch manager. Die rol houdt in dat zij/hij er voor moet zorgen dat de informatie en communicatie in de organisatie goed geregeld is/wordt, net als dat anderen verantwoordelijk zijn voor de financien, het personeel, het primaire proces enz. En natuurlijk zal de CIO het nodige van IT moeten weten; hij/zij zal immers IT-ers goed van repliek moeten kunnen dienen.
De CIO is trouwens een manager, en geen kennisbeheerder. Geen architect/adviseur, dus.


Ad 8. Ik denk dat Chris teruggegrepen heeft op ouder onderzoek en daarmee een verkeerd beeld heeft doorgezet. De praktijk laat al jaren zien dat investering:exploitatie ongeveer 20 a 30 : 80 a 70 is. Maar IT-projecten zorgen wel voor de kosten in de exploitatie.
Outsourcing is alleen maar een manier waarop geinvesteerd of geexploiteerd wordt. Het zijn gewoon euros die op een andere manier uitgegeven worden. De chaos daar zal trouwens binnenkort wel echt boven komen drijven. Is die hype tenminste ook weer in een normaal kanaal te zetten, en op de echte waarde te beoordelen. Weer een snerpend rapport van de Rekenkamer....

Steven van 't Veld

Commentaar op Guusje ter Horst naar aanleiding van haar brief over grote IT-projecten, als tweede antwoord op het rapport van de Algemene Rekenkamer

Op 25 februari gaf Guusje ter Horst (BZK) inzicht aan de Tweede Kamer (zie brief: http://www.minbzk.nl/actueel/110815/brief-aan-de- tweede_0) over de maatregelen die zij gaat nemen om grote IT-projecten bij de overheid meer in de hand te houden. Zij stelt voor een aparte directie Informatiseringsbeleid op te richten binnen het DG Organisatie en Bedrijfsvoering. Deze directie zal zich richten op de gezamenlijke programma's in de bedrijfsvoering van de ministeries en op de bevordering van de kwaliteit van de I-kolom binnen de ministeries en de kwaliteit van de aansturing van grote IT-projecten.

In het tweede punt van bovenvermelde brief, getiteld ‘elke minister zelf verantwoordelijk’, stelt zij dat het kabinet het geen goed idee vindt om één minister verantwoordelijk te maken voor aansturing en uitvoering van IT-projecten. Dat ben ik met het kabinet eens. Benoem niet een minster die komt en gaat, maar benoem een CIO en een Digitale Rijksbouwmeester (zie: http://www.via-nova-architectura.org/forum/ overheidsarchitectuur/de-digitale- rijksbouwmeester/view.html) met een beperkte staf bij het ministerie van AZ.
Voorts is het kabinet bang dat zo'n minister een heel legertje ambtenaren nodig heeft om ten behoeven van de projecten mee te denken, mee te sturen en toe te zien op de uitvoering. Ik heb het gevoel dat het kabinet te ouderwetse opvattingen heeft over hoe je de automatisering van de totale rijksoverheid zou kunnen inrichten. Zij denkt nog te veel in termen van een soort inlichtingendienst, zoals in het voormalige Oostblok. En terecht, zoals Guusje opmerkt, zou dat leiden tot een afname van de slagvaardigheid. Voorts merkt zij op dat centralisatie bij één minister zou in druisen tegen de integrale verantwoordelijkheid van de vakminister voor alles op zijn of haar ministerie. Dit laatste argument is niet logisch. Een minister is verantwoordelijk als opdrachtgever! De automatisering kan je elders beleggen.

In het vierde punt, getiteld ‘verbeteringen’ stelt zij voor dat in het nieuwe directoraat-generaal Organisatie en Bedrijfsvoering op haar ministerie een directie Informatiseringsbeleid zal worden gecreëerd. Deze directie zal zich bezig houden met de start van grote IT-projecten of projecten met een grote IT-component, Second opinion, ICT- haalbaarheidstoets, Kwaliteit van de I-kolom binnen de ministeries, Architectuur en Standaardisatie en operabiliteit. Dit k_link_t toch een beetje als een CIO + Digitale Rijksbouwmeester bij BZK, of niet zo? En wat wordt dan de relatie met ICTU?
Middels een uitgebreide startbrief of projectinitiatie wil zij duidelijkheid krijgen over welk probleem met de nieuwe IT toepassing op welke wijze wordt opgelost. Ik zou dit graag een stapje concreter zien: een duidelijke opdrachtformulering, aangegeven waar het onderhavige project past in de totale architectuur en een zakelijke Business Case.
Zij pleit voor een second opinion door onafhankelijke derden die regelmatig dient te worden uitgevoerd. Ik hoop dat zij bedoelt dat een auditschema wordt afgesproken bij aanvang van het project, in de zin zoals door mij al vaker bepleit. Vijf soorten audits: projectdiagnose alvorens het project begint om te onderzoeken of het onderhavige project goed op de rails worden gezet, tijdens het project drie soorten audits: projectmanagement audits om de voortgang te meten, product audits om een inhoudelijk oordeel te geven over de (tussen)resultaten en kwaliteitsinspecties om de daadwerkelijke toepassing van het kwaliteitssysteem te controleren. Na afloop het van het project een projectevaluatie om onder andere de geleerde zaken herbruikbaar te maken voor toekomstige projecten. Dus systematisch onderzoek en beslist geen hapsnap second opinions. Op basis van de uitkomsten van deze audits dienen projecten te kunnen worden bijgesteld in alle aspecten dan wel worden gestopt.
Voorts maakt zij gewag van een ICT-haalbaarheidstoets, die door haar collega van Economische Zaken samen met het bedrijfsleven wordt ontwikkeld. Ik neem aan dat ze met bedrijfsleven bedoelt het ICT~Office. Dat k_link_t nobel. Maar ik neem aan dat de softwareleveranciers deze haalbaarheidstoets willen voor hun eigen nachtrust. Want vanuit een professioneel opdrachtgeverschap kan ik de haalbaarheid ook anders afdwingen.
Het verheugt mij dat Guusje ter Horst erkent dat er dient te worden gewerkt onder architectuur. Zij overschat daarbij de kwaliteit en bruikbaarheid van NORA (Nederlandse Overheids Referentie Architectuur), al middels versie 2.0 en de voortgang en volwassenheid van MARIJ. Dit laatste document is nog slechts in een conceptfase.
Expliciet benoemt zij het bevorderen van standaardisatie en interoperabiliteit. Hieraan wordt gewerkt door het College en Forum Standaardisatie. Ik begrijp niet dat zij dit buiten de architectuur plaats, deze zaken lijken mij toch een integraal onderdeel van architectuur.

Tenslotte stelt zij voor dat bovenstaande zaken niet een vrijblijvend en vrijwillig proces wordt, maar een voorwaarde waar elke minister zich aan houdt voor het starten en uitvoeren van grote IT-projecten. Zeer goed idee, ik bedoel de niet-vrijblijvendheid. Maar laat dan ook documenten als NORA stelliger formuleren.