Digitale verkrotting van de IT bij de Nederlandse overheid

Ik ben het hartgrondig eens met de stelling dat deze verspilling van overheidsbudgetten niet nodig is. Maar er is meer nodig dan een paar technische ingrepen.
Allereerst de cultuur issue in relatie tot verandering: het besef moet expliciet ontstaan dat projecten en programma’s gewoon besturingsconcepten zijn die nodig zijn naast de bestaande lijnorganisatie om bijzondere (grote/complexe/niet incrementele) veranderingen tot stand te brengen. Ze dienen elkaar te versterken en niet tegen te werken. Daarmee dient begrepen te worden dat projecten en programma’s bij opdrachtverstrekking een stuk autonome ‘macht’ meekrijgen, immers de juiste balans tussen verantwoordelijkheden en bevoegdheden is randvoorwaardelijk om hun doelen te kunnen realiseren. Als de top van een organisatie zich concentreert op de staande organisatie en de verandering delegeert zullen de projecten en programma’s altijd gedoemd zijn te falen. De top zal zich moeten persoonlijk committeren, dat houdt in : het strategische belang uitdragen, op dagbasis beschikbaar zijn voor escalaties, snel besluiten nemen. Daarnaast moeten de beste mensen vrijgemaakt worden voor de verandertrajecten. De grootste carrièremogelijkheden liggen in de verandertrajecten. Dat betekent dat het dogma ‘blijf zitten waar je zit en verroer geen lid’ een negatief effect zal hebben op carrièrepaden en dat het nemen van (verantwoorde) risico’s beloond zal worden.
Ten tweede zal er een gemeenschappelijk begrippenkader moeten komen. Alle betrokken van hoog tot laag zullen moeten investeren in het doorgronden van de (doel)businessarchitectuur. daarmee wordt de archiectuur de eerste van de pilaren onder de communicatie met betrekking tot strategische verandertrajecten. De tweede pilaar wordt de projectportfolio die gelinkt aan de architectuur het pad weergeeft om de doelen te realiseren.
Ten derde zullen we als leidend besturingsparadigma moeten kiezen voor tijd als belangrijkste stuurmiddel. Geld is kennelijk nooit het probleem, we zijn erg goed in het achteraf verklaren waarom het deze keer weer is misgegaan. Daarom is keihard sturen op opleverdata veel effectiever.
Ten vierde moet wendbaarheid als een van de belangrijkste elementen in de architectuur zijn. Dat daarbij een serieuze discussie moet plaatsvinden tussen de politiek en de overheid is evident, misschien moeilijk, maar absoluut randvoorwaardelijk om de te definiëren verandertrajecten op koers te kunnen houden. aan de ene kant dwingt het om na te denken over toekomstige scenario’s en de waarschijnlijkheid dat ze zullen optreden, aan de andere kant biedt het een kader om projecten op koers te houden doordat het een mechanisme ter inperking van keuzemogelijkheden biedt.
Ten vijfde s er moed nodig aan de top om de noodzakelijk keuzes te maken. maar ook daar zou moeten gelden dat in beweging komen de vereiste norm is en dat het niet durven je nek uit te steken als negatief beoordeeld wordt.
Ten zesde moet de ICT organisatie op kracht gebracht cq gehouden worden. Om de bovengenoemde discussies en verandertrajecten succesvol te kunnen realiseren is een zeer goede architectuur organisatie nodig en een kern van zware ervaren programma en projectmanagers. Deze dienen in dienst van de overheid te zijn. Commodities kunnen worden ingehuurd, niet de randvoorwaardelijke zwaargewichten die de strategie moeten bepalen en realiseren. Om daar te komen zal op een aantal plaatsen op zich een strategisch programma moeten worden opgestart.
Tot slot lijkt het me goed om te onderstrepen dat bovenstaande lijst geen lijstje is voor cherrypicken. Alle genoemde punten zijn randvoorwaardelijk om het tij van mislukkingen van ICT projecten bij de overheid te keren. Dat is dus niet eenvoudig (als het eenvoudig was, was het al gebeurd), maar wel mogelijk.
karel koet

Goed dat deze discussie is gestart. Ik ben stellig van mening dat de wijze waarop de overheid aanbesteed heel vaak een oorzaak is van minder optimale uitvoering. Europees aanbesteden en IT ontwikkelingen staan elkaar over het algemeen in de weg.
Daar dient een zeer creatieve, pragmatische oplossing voor te worden gevonden.

Deze lijstjes met discussiethema’s en hoofdpijnpunten zijn al best heel goed, maar ze zijn onvoldoende. In mijn ervaring zijn vrijwel alle trajecten met een IT-aspect van enige omvang belast met de normale problematiek van complexe belangenstelsels die komen uit het achterliggende politieke, beleidsmatige, maatschappelijke vraagstuk. Tegen de tijd dat we het als een overheids IT project gaan herkennen zijn daarin al zoveel bewuste en onbewuste keuzes gemaakt dat het dan concreet wordende IT-deel alleen nog moeizaam kan slagen. In dat voortraject al rekening houden met uitvoering, ook het IT-deel daarin, is iets wat verschrikkelijk lastig blijkt. De gebruikelijke werkwijze in dat stadium biedt maar heel beperkt kansen om dat beter te laten gaan en een oplossing daarvoor vereist nog meer dan deze lijstjes doen vermoeden. Het beeld dat goed programma- en projectmanagement en architectuur dat geheel op zou kunnen lossen deel ik niet.

Ik heb veel moeite met de vaak eenzijdige en negatieve benadering van projecten bij de overheid. Volgens mij gaat er ook veel goed. Dat mag ook best een keer worden gezegd!

Daar waar het outsourcing in combinatie met innovatie betreft is mogelijk een relatief nieuwe wet/aanvulling op aanbesteding het overwegen waard. Deze nieuwe wet heet innovatiepartnerschap. Deze procedure is te gebruiken voor de aanschaf van producten, werken en diensten die nog niet op de markt beschikbaar zijn (of in ieder geval niet met het gewenste prestatie niveau). De overheid definieert het probleem of de behoefte en bedrijven stellen innovatieve oplossingen voor.
https://www.pianoo.nl/nl/inkoopproces/fase-1-voorbereiden-inkoopopdracht/mogelijke-aanbestedingsprocedures/europese-specifieke-procedures-1

Vriendelijke groet,
Leon Dohmen

Ik ben het volledig eens dat er iets moet veranderen in de manier waarop overheidsprojecten, en dan niet alleen ICT gerelateerd, aanbesteed en uitgevoerd worden. Er gaat inderdaad veel gemeenschapsgeld mee gemoeid, en die behoort optimaal besteedt te worden.

Maar ik ben het volledig oneens met de opmerking dat er een “een duidelijke rode lijn” miste. Ik was 1 van die actieve participanten in de discussie op LinkedIn, en ik wil toch benadrukken dat er veel goede opmerkingen en aanknopingspunten waren, en ook veel reacties, van IT mensen die ruime ervaring hebben met die overheid, die verder gingen met vooral het zoeken naar “waarom” veel IT projecten bij de overheid mis gaan. Ik heb een Problem Management achtergrond en volgens mij zou dat in een RCA een rode draad zijn die van essentieel belang is om überhaupt de vraag te kunnen beantwoorden hoe het kan dat er zaken fout gaan. En daarnaast wat “wij”, dat is de overheid samen met de IT wereld, kunnen doen om het te verbeteren.

En het deze “wij” die mij bij een opmerking brengt die ik ook op LinkedIn ingebracht heb, en die ook hier helaas weer ontbreekt. En dat is dat veel van de projecten die misgaan bij de overheid niet “alleen” aan de overheid te wijden zijn. Veel projecten worden door (grote) externe IT partijen uitgevoerd. En bij veel van deze partijen staat absoluut “niet” de overheid, het algemeen belang, de belastingbetaler, of het slagen van het project op de eerste plaats. Op 1 staan het maken van omzetten en winst, en bij veel IT sales mensen het behalen van bonussen. Daardoor komt het teveel en te vaak voor dat gegeven adviezen, gemaakte ontwerpen, en uitvoering of implementatie door project management niet altijd gericht zijn op wat de desbetreffende overheidsinstantie vereist of benodigd heeft. En daarmee komt het dus te veel voor dat het uiteindelijke resultaat niet is wat verwacht wordt. Ik vind het dan ook niet eerlijk, en te kort door de bocht, om “alle” schuld bij de overheid te leggen en deze organisatie daarvoor solitair aansprakelijk te stellen. En ja, de overheid is als opdrachtgever verantwoordelijk voor het duidelijk zijn bij de opdracht stelling, de keuze van project partners, en uiteindelijk de kosten die daarmee gemoeid gaan. Maar gezien de organisatie, en core business van de overheid, mag je niet eisen, misschien wel hopen, dat de kennis om dat goed te kunnen beoordelen en te verwoorden daar volledig aanwezig is. De overheid is dus afhankelijk van oprechte ondersteuning en eerlijke adviezen gemaakt door mensen uit de IT wereld. En daarom zijn deze IT partners evenredig verantwoordelijk voor het slagen van projecten en correct besteden van gemeenschapsgeld. Daarom “moeten” IT partijen die zich inschrijven op overheidsprojecten als eerste hun morele en gemeenschappelijke verplichtingen boven omzetten en winsten stellen. Bij overheidsprojecten moet het om het algemene belang gaan en niet om aandeelhouders en bonussen. Adviezen moeten dus open, onafhankelijk en transparant zijn, en gericht om de overheid te helpen met wat de daadwerkelijke vraagstelling zou moeten zijn, welk probleem precies opgelost moet worden, en welke (onafhankelijke) oplossing daar het beste bij past. Het gebeurt op dit moment te vaak dat er meer naar het promoten van een (eigen of gesponsorde) technologie gekeken wordt, dan of deze technologie daadwerkelijk de beste oplossing voor het specifieke probleem, of deze specifieke overheidsinstantie is.

Wat zouden “wij” kunnen doen om de 10 hoofdpunten te verbeteren.
1: Dit is een cultuur ding, en de IT wereld zou de overheidsorganisatie kunnen ondersteunen met mensen en middelen die meer gericht zijn op de mens binnen deze organisaties dan op de technologie die geleverd wordt. Wees positief over de organisatie, zie je als betrokken voor de problemen van de overheidsmensen, en wees ten aller tijden gedienstig en een luisterend oor. Helpen is het sleutelwoord.
2: De grootste uitdaging voor de overheid is het juist beschrijven van het probleem en daarmee de verwoording van de opdracht. De IT wereld moet pro-actief assisteren met de specifieke vraagstelling zodat opdrachtmanagement beter beslagen ten ijs gaat. En leert zodat er voor toekomstige projecten meer zelfvertrouwen ontstaat en kennis aanwezig is.
3: Wees een “echte” partner in projecten en ondersteun project- en programma-management zonder vooroordeel of commercieel oogpunt. Zie het falen van het project als een persoonlijke falen en laat project- en programma-management zien dat je dat ook echt meent.
4: Help de overheidsarchitecten met het beter beschrijven en definiëren van architectuur. Focus niet alleen op technologie maar ook op de organisatie en de (organisatie en technologische) problemen die de regeringsbeslissingen veelal met zich meebrengen. Wij zijn de technology experts dus denk vooruit. Indien nog niet toegepast probeer ze meer KISS te maken en introduceer eventueel Togaf principes en Agile denken.
5: Probeer meer algemeen toepasbare architecturen te adviseren om hiermee een meer doelmatige en onafhankelijk uitbreidbare architectenpopulatie te creëren. Help met het voorkomen van vendor, supplier of platform lock-in.
6: Adviseer en ondersteun in het versimpelen van (systeem)ontwikkeltrajecten. Schroom niet om ze eens in je eigen keuken te laten kijken, of door ze adhv voorbeelden een andere gedachte te tonen. Wees respectvol, maar durf kritisch te zijn ten aanzien van hiaten of verbeteringen (waar dan ook).
7: Zorg dat mensen die beslissingen mogen nemen onderdeel zijn van het project, dit om oeverloos praten en eindeloze discussies te voorkomen. Dwing, eventueel door meer toepassing van Agile projectmanagement, meer en snellere beslismomenten en milestones af. Voorkom waterval waar mogelijk.
8: Zorg dat stakeholders en andere betrokkenen ook echt betrokken zijn, en niet alleen “geïnformeerd” worden. Maak ze verantwoordelijk voor deeltrajecten en laat ze participeren tijdens uitvoeringen en implementaties. Ook excecutives zodat ze zien wat beslissingen voor effect hebben.
9: Werk binnen overheidsprojecten “samen” met andere IT partners, ook al zijn ze in de normale commerciële wereld je grootste concurrent. Denk samen na over hoe je de overheid het beste van dienst kan zijn, en laat deze vorm van samenwerking ook blijken in gemeenschappelijke verantwoordelijkheden, adviezen en onderling vertrouwen.

In het kort, “wees” als IT partner tijdens overheidsprojecten tijdelijk even “die” overheidsinstantie…… Hierdoor ontstaat onderling vertrouwen, en hiermee zal de overheid zich beter gaan presteren en daarmee ook beter bestand raken tegen de dynamische grillen van de Nederlandse regering of andere invloeden van buiten af.

Ben van Ackooy

Ik ben het eens met de analyse en bovenstaande reacties. Onze ervaring is dat er drie belangrijke aspecten zijn die de uitvoering van projecten ernstig belemmeren:
1) De wijze en condities waaronder wordt aanbesteed. Dit leidt tot veel administratieve overhead en een onjuiste startpositie van het uit te voeren werk.
2) Het feit dat ICT afdelingen budget houder zijn terwijl de business vraag niet bij IT vandaan komt.
3) Aansturing neerleggen bij een externe leverancier die niet de uitvoerder is van de opdracht . Daardoor heeft de opdrachtgever te weinig sturing op het project en komt het regelmatig voor dat de belangen van de aansturende partij worden gediend in plaats van de belangen van de opdrachtgever.

Ik ben het in grote lijnen eens met de analyse van Daan. Het issue is niet nieuw, er is zelfs een parlementaire enquete aan gewijd onder leiding van Ton Elias. De conclusies waren:

1. 1. Gebrek aan realiteitszin
Grote, moderne veranderingen krijgen vrijwel onvermijdelijk te maken met de alomtegenwoordige ICT. Net als elke technologie heeft die zijn beperkingen en kosten, maar politici begrijpen deze niet en willen ze niet begrijpen. Kamerleden komen met onrealistische eisen, ministers doen toezeggingen die ze niet waar kunnen maken, ambtenaren durven vervolgens geen ‘nee’ te zeggen en de enkele welwillende ICT-leverancier die de overheid durft te waarschuwen voor problemen, wordt genegeerd. Om megalomane projecten een halt toe te roepen wil de commissie dat een team van onafhankelijke experts, dat rapporteert aan de premier, elk project van meer dan 5 miljoen euro op basis van vaste criteria gaat toetsen. Het nieuwe ‘Bureau ICT-toetsing’ (BIT) moet controleren of de overheid wel helder heeft wat ze met een project wil bereiken, of dit technisch haalbaar is en of de kosten goed zijn onderbouwd. Als dit niet zo is, kunnen de plannen worden tegengehouden.

2. Gebrek aan kennis
De overheid heeft onvoldoende kennis in huis om grote en risicovolle ict-projecten te sturen. Hoge ambtenaren zijn ‘onbewust onbekwaam’, ofwel: ze hebben geen idee hoeveel kennis ze eigenlijk ontberen. Daarnaast heeft de overheid onvoldoende echte experts in dienst. Het rapport spreekt van een ‘bijna onoverbrugbare kloof’ tussen ict- en beleidsafdelingen. Daarom moet de overheid meer ict-experts zoeken, een centraal opleidingsprogramma starten voor interne medewerkers en ict een vast onderdeel maken van de training van rijksambtenaren.

3. Perverse prikkels
De ict-aanbestedingstrajecten van de overheid bevatten perverse prikkels. Ambtenaren denken het beter te weten dan de ict-leveranciers en geven deze te specifieke en vaak onmogelijke opdrachten mee. Wanneer de afspraken niet haalbaar blijken leidt dit tot extra werkuren voor de leverancier en daarmee hogere kosten voor de overheid, waarna in het geheim wordt geschikt – vaak met nonchalance over de hoogte van de bedrage.
Volgens het rapport zouden ambtenaren de technische details van aanbestedingen aan de leverancier moeten overlaten en getekende contracten vaker gebruiken om gemaakte afspraken daadwerkelijk te laten naleven.

4. Onbestuurbaarheid
De verantwoordelijkheid voor de sturing van ict-projecten is versnipperd. Wanneer iedereen verantwoordelijk is, neemt niemand verantwoordelijkheid, en dat is bij de overheid de norm. Voor het projectmanagent wordt geen deskundig personeel ingezet, en bestuurders zijn marginaal betrokken en worden slecht over de projecten geïnformeerd. De commissie-Elias adviseert om altijd één persoon uit de ambtelijke top eindverantwoordelijk te maken voor een project, resultaatafspraken te maken met betrokken leveranciers en ambtenaren, en hen af te rekenen op het resultaat van het project.

5. Geen inzicht in kosten
In de politiek is geen overkoepelend gezag over ict-projecten. De ict-portefeuille is verdeeld over vier verschillende ministers, en het geheel van instanties dat zich met het onderwerp bezig houdt is chaotisch en onoverzichtelijk. Hierdoor is het niet alleen onmogelijk om projecten onder controle te krijgen, maar ook om te bepalen hoeveel geld precies verloren gaat door mislukte projecten. De commissie vindt 1 à 5 miljard euro echter een veilige schatting. Het rapport raadt daarom aan de verantwoordelijkheid voor het ICT-beleid te centraliseren en de ICT-portefeuille onder te brengen bij één enkele minister, die de kosten en baten van projecten inzichtelijk moet maken.

Deze conclusies stemmen mij ook niet hoopvol over het überhaupt kunnen slagen van ICT-projecten bij de overheid. Wat m.i. een fundamentele fout is in ons parlementaire systeem is dat verantwoordelijke ministers en controlerende volksvertegenwoordigers allen uit de bestaande politieke partijen worden gerekruteerd. Er is in Nederland een buitengewoon klein deel van de bevolking lid van een politieke partij (het aantal leden is per 1 januari 2018: 317.325 op een bevolking van ruim 17 miljoen burgers). Dus in zekere zin hebben we het falen van projecten aan onszelf te danken. Het controlerende orgaan in Nederland (de Tweede Kamer) faalt dus.

Bedrijfsarchitectuur is hierin cruciaal. VNG-KING (nu:VNG-Realisatie) maakte voor de invoering van de Omgevingswet een bedrijfsarchitectuur. Gemeenten Zwolle en Amsterdam ook, maar op een heel andere manier. Interessant misschien om hiervoor te vergelijken?

Overheidsprojecten worden denk ik nog te vaak als traditionele projecten uitgevoerd. Uiteindelijke functionaliteit van systemen en de bijbehorende requirements zijn tot in elk detail beschreven. Hierin wordt er geen rekening gehouden met een steeds sneller veranderende wereld waarin traditionele waterval projecten niet meer thuishoren Tegen de tijd dat delen of het geheel worden opgeleverd voldoet het al niet meer aan nieuwe inzichten . De overheid moet naar een modus die door een groot deel van de markt al wordt gehanteerd, namelijk een agile manier van projecten doen. Beter is het met een Minimum Viable Product te komen dat voor verbetering vatbaar is, dan met een uitgekauwd systeem of platform dat niet meer voldoet aan de gewijzigde vraag tegen de tijd dat het “geshowed” kan worden. Een MVP dat iteratief wordt uitgebreid met releases is de beste manier om op koers te blijven in de digitale wereld. Aanbesteding van agile projecten is natuurlijk lastig voor een traditioneel opgezette projectorganisatie omdat het einddoel beweegt. De voordelen van agile wegen alleszins op tegen de nadelen van een bewegend doel. Want iedere release of feature die wordt toegevoegd aan een MVP is gestuurd vanuit een business case, is bijgesteld aan de laatste wensen en eisen, en heeft een vastgestelde doorlooptijd. Sturing onder architectuur blijft daarnaast prima mogelijk ondanks dat de Enterprise Architecten zullen moeten accepteren dat architectuur ook bottom-up vanuit de spint teams ontstaat. Naast Enterprise Architecten zullen Agile Architecten nodig zijn. Of deze van de overheidsorganisatie zelf komen, ingehuurd zijn of van een hoofdaannemer komen is niet zo spannen. Echter het uitbesteden van agile projecten aan één hoofdaannemer is geen optie tenzij deze een redelijk ecosysteem aan innovatieve partners met zich meebrengt.

Het is toch te bizar voor woorden dat een partij met een omvang, budget en relevantie als de overheid er niet in slaagt om lijn te krijgen in de eigen IT. Natuurlijk is het landschap versnipperd qua aansturing, budgetten en functionaliteit en ontbreekt centrale aansturing.
Wat mij voor ogen staat is een proeftuin / innovatielab waar een aantal prototypische oplossingen wordt uitgewerkt als referentie voor echte projecten. Belangrijk is een goede balans tussen innovatie en realisme, weerstand tegen (grote) partijen met een drang om het eigen belang voorrang te geven boven het overheidsbelang en de bewaking dat de proeftuin geen (betaalde) speeltuin wordt. Ja, een uitdaging op zich maar kost een fractie van de faalkosten nu en dit geeft ruimte aan nieuwe ideeën…

Informatievoorziening is inmiddels strategisch, ook voor de BV Nederland. We zouden erg gebaat zijn bij een minister van Informatievoorziening met zijn eigen departement.

Beste Daan,

Goed dat je deze blog begonnen bent.

IT moet niet op zich staan. Het moet een uitvloeisel van een heldere misie, visie en strategie zijn.
En om de strategische doelstellingen te bereiken zijn goede, heldere, flexibele (!) en meetbare processen nodig.
Dit alles moet onder business en procesarchitectuur vorm gegeven worden, anders blijft en wordt het een fiasco.

Ik wilde een reactie schrijven, maar na lezing van al het bovenstaande concludeer ik dat de belangrijke punten al zijn gemaakt en kan ik me vooral buitengewoon goed vinden in de reactie van @Dick van Dijk.

Als na een dergelijke diepgaande studie van het eigen falen, men nog steeds op zoek is naar ‘waarom het niet lukt’, dan bevalt het gevonden antwoord kennelijk niet. Want ik heb niet de indruk dat de problemen die door de ‘Tijdelijke commissie ICT’ zijn geconstateerd al effectief aangepakt, laat staan verholpen zijn. En een serieus te nemen verwerping van de bevindingen is er ook niet.

Daarmee is het probleem er eerder één van cultuur en (politieke) wil, dan van technisch of theoretisch vermogen. Natuurlijk kunnen (en moeten) architecten daar ook een bijdrage leveren, maar moet er wellicht worden gezocht naar die architecten die het probleem onder woorden kunnen brengen op een manier die de inhoud en urgentie zichtbaar en aantrekkelijk maakt voor bestuurders en eindverantwoordelijken.

En wellicht is het de moeite waard om een vergelijkbaar diepgaand onderzoek te doen naar de projecten bij de overheid die wel slagen en uitgesproken succesvol zijn, om de lessen die daar worden geleerd tot norm te verheffen.

Beste Daan,
dank voor je uitnodiging om nog iets explicieter in te gaan op de noodzaak van Bedrijfsarchitectuur.

In mijn notitie voor de commissie Elias betoogde ik in 2014, dat opdrachtgevers maar heel weinig over ICT hoeven te weten. De enige vraag, die alleen de opdrachtgevers van ICT-voorzieningen kunnen en moeten beantwoorden is: “Welke bedrijfsrollen moeten over welke bedrijfsobjecten (onderwerpen, die voor het bedrijf van belang zijn) welke informatie kunnen registreren en ontsluiten en berichten kunnen verzenden en ontvangen?”.

Dat is ook de vraag, die een Bedrijfs(informatie)-architectuur moet beantwoorden. De vraag, en het antwoord zijn inrichtingsonafhankelijk, dus onafhankelijk van de organisatie (welke actor speelt welke rol(len)?) en van de systemen (in welke gegevensverzameling wordt de informatie bewaard, met welke applicaties wordt de informatie bewerkt, geregistreerd en ontsloten, en via welke communicatiekanalen wordt de informatie (in berichten) verzonden en ontvangen). In de inrichting kan vanalles veranderen zal ook onder invloed van nieuwe technieken veel meer veranderen dan in de bedrijfs(informatie)architectuur.

De bedrijfsarchitectuur voor de omgevingswet, die ik opstelde in opdracht van de gemeenten Zwolle en Amsterdam laat zien hoe die vraag systematisch en logisch consistent kan worden beantwoord. De architectuur, die VNG-KING liet opstellen, slaagt daar niet in. Dat ligt niet aan de architect, die de opdracht uitvoerde, maar aan de beperking, die hem door VNG-KING werd opgelegd in de te volgen aanpak.

De VNG-KING-architectuur is te vinden op het ROM-netwerk en kan worden opgevraagd bij VNG-KING.
De architectuur, die ik voor Zwolle en Amsterdam opstelde kan worden opgevraagd bij Marianne Wouters:

Ik werk zelf niet bij de overheid, en ook niet bij bedrijven die door de overheid worden ingehuurd.
Wel ken ik een paar mensen die dat wel doen/deden. Wat zaken die me in gesprekken m.b.t. hun situatie opvielen:
– De vraag van politici (nieuwe wetten, regelingen, etc.) verandert nogal snel
– De tijd tussen het aankondigen van de maatregel, en de invoering ervan in de praktijk, is kort
– Er zijn veel externe partijen bij de ontwikkeling betrokken (uitbesteding, etc.).

Naar mijn mening zouden de eerste 2 punten (veranderende vraag, korte tijd tot invoering) tot een aanpak moeten leiden waarbij er een flexibel framework ontstaat, waarop je op een (min of meer) vóórgedefiniëerde manier kan aansluiten. Technisch gezien zou je aan een plug-in-achtig framework kunnen denken.
Het issue hiermee is, dat je voor het bedenken van zo’n framework eerst goed overzicht moet hebben op de inhoud, en daar structuur in moet gaan vinden. En die structuur moet dus veel flexibiliteit toelaten. Dat vereist veel inhoudelijke kennis.
Daarnaast zal het realiseren van zo’n framework zélf al veel tijd gaan kosten, qua implementatie. M.a.w. ook voor het ontwikkelen van zo’n framework zal een soort van flexibele aanpak moeten worden gekozen.
En je moet nog een manier vinden om zo’n aanpak te laten passen bij wat er al is (o.a. om een zo’n vloeiend mogelijke migratie te faciliteren).

Nu het derde punt. Er is veel inhuur, vaak van hele projecten, als ik de reacties hierboven mag geloven.
Deze partijen kunnen in de praktijk nooit een goed overzicht hebben van wat er bij de overheid allemaal gaande is (zowel qua business/politiek als qua bestaande IT-componenten), en kunnen dus ook moeilijk goed aansluiten op wat er al is. Dus zo’n aanpak zal in de praktijk nooit tot een samenhangend IT-landschap leiden.
Gevolg is waarschijnlijk chaos, en waarschijnlijk “vinger-wijzen” om zelf niet de schuld te krijgen. Er staan namelijk ook nog contractuele belangen op het spel. Logisch, maar niet altijd handig.

Mijn conclusie zou zijn dat je “kennis op moet bouwen”.
Dit doe je door een groep mensen vertrouwen te geven, en ze diep onderzoek te laten doen naar wat er al is, naar de omstandigheden waaronder ze moeten werken (business kennis en kennis van het huidige IT-landschap en -plannen), en continu te werken aan kennis management bij die interne club mensen.
Deze mensen zullen met een framework moeten komen, waarvan ze denken dat het flexibel is, zowel om erop aan te sluiten, als om het neer te zetten, in het huidige business en IT landschap.

Vanzelfsprekend zal daarbij af en toe ook kennis moeten worden ingehuurd. Niemand heeft alle kennis in huis, en dus maak je graag gebruik van externe kennis. Echter, die externe kennis gaat weer weg. Dus dit moet je die inhuur zien als een manier om externe kennis over te dragen op die interne club.

Zo’n interne club moet een heel open cultuur ontwikkelen, en een “team” gaan vormen, waarbij er vertrouwen kan ontstaan tussen de leden ervan. De leden moeten inhoudelijke kennis hebben, of op willen doen.
Zorg binnen de club zowel voor sterke business analisten/architecten als IT-architecten, en zorg voor voldoende “overlap van kennis”. Dat helpt om elkaar te kunnen begrijpen, en dus zinvol te kunnen communiceren, en op z’n minst misverstanden zullen herkennen.
Samen, als team, zullen ze zo’n “framework” moeten neerzetten.
Daarbij zal het team ook liefst zoveel mogelijk “zelfsturend” moeten zijn, om de focus op de inhoud te kunnen houden, en afdelingspolitieke argumenten goed te kunnen onderscheiden van (business- en IT-) architectuur-technische.

Hoe dit precies binnen de overheid past, weet ik vanzelfsprekend niet. Hierover moeten vooral anderen iets roepen.
Heb ik hier “gelijk”? Geen idee. Ik denk dat ik hier een aantal verstandige aandachtspunten noem, maar nogmaals, ik ken de overheid niet direct, dus het zijn aannames.

In ieder geval, klagen over de aansturing van IT helpt niet veel.
– Je hebt met de politiek als business te maken, dus je weet van tevoren al dat er nogal eens wijzigingen zullen plaatsvinden. Dat is de “business situatie”. Vandaar zo’n flexibel framework, in wat voor vorm dan ook.
– Je weet ook dat je die wijzigingen zult moeten kunnen duiden. Vandaar een bestendig centraal kennisteam met zowel IT- als business architecten (en misschien ook andere inhoudelijke functies, zoals business analisten en IT-engineers) waar kennis actief wordt opgebouwd, gedeeld en gemanaged.
– Je weet ook dat je alléén iets bereikt als je goed samenwerkt. Dus vandaar “team building” en “inhoudelijke” samenwerking.
– Externe partijen kunnen dat ondersteunen (aanvullende kennis, creativiteit, nieuwe ontwikkelingen aandragen, meedenken), maar zouden nooit hoofdpartij moeten zijn in enig project/initiatief.

oeps de link en het mailadres zijn – kennelijk door een of ander algoritme – weggelaten uit bovenstaand bericht:
je vind de notitie aan de Elias-Die op http://adosh.nl/?p=4
En het mailadres van Marianne is m.wouters@amsterdam.nl

Hoewel ik al een tiental jaren geen rijksoverheid-ICT heb gezien, valt mij op als ik naar de huidige werkelijkheid kijk, dat het denken over ICT rond 2001 is blijven steken – en dan doel ik met name op het vooral academische denken rond de basisregistraties, in SOA/MDM en middleware. Ook elders hebben architecten deze neigingen, maar daar is de praktijk gewoon SaaS en Shadow-IT – de business schuift de ICT terzijde als de resultaten uitblijven. Oftewel, bij het rijk heeft de ICT vooral teveel macht en vrijheid. Elk voorstel qua oplossing gaat uit van het oplossend vermogen van de ICT club – maar helaas al te vaak is de ICT club met hoogdravende ideeen nu net het probleem. Ik zou de heren politici graag ontvangen in Zaandam waar we een best grote retailer hebben met de ICT-spullen omvang van de Benelux en een IT afdeling ter grootte van die van één ministerie.

Beste Daan, Ik vind dit een goede discussie vanuit het gezichtspunt dat wij, als ingezetenen van Nederland, allemaal meebetalen aan verspilling door falende IT projecten bij onze eigen overheid. Ik vind het een goed idee om in werkgroep vorm ideeën aan te leveren om daar iets aan te doen. Het lijkt me ook een interessant onderwerp om met een aantal mensen in te duiken. Maar voordat ik me vol in de discussie stort zou ik wel graag van je willen weten wie onze “executive champion” is bij de organisatie waar het om gaat – in casu de overheid. Met wie zijn we in gesprek en vinden we daar een luisterend oor? De overheid is bovendien niet één homogene organisatie – het is een federatie van heel veel niet op elkaar afgestemde onderdelen. Je hebt landelijke, regionale en gemeentelijke overheden. De belastingdienst is iets heel anders dan defensie. Het is daarom misschien raadzaam een bepaalde case bij de kop te pakken. Zonder deze zaken geregeld te hebben loop je het risico in hetzelfde patroon te vervallen als langs de lijn van de gemiddelde voetbalwedstrijd….de beste stuurlui (voetbal-coaches) staan immers altijd aan wal (langs de lijn) maar het effect van advies is twijfelachtig.

Ik heb even naar de Blog gekeken en reageer allereerst met de opmerking dat er denk ik hele goede overheidsinitiatieven zoals bijvoorbeeld NORA.

Wat m.i. de hoofdoorzaak is van de ICT problematiek bij de overheid is niet zozeer de ICT zelf maar de besluitvorming en de politiek daaromheen in samenhang met een kennelijk grootschalige aanpak.

Bij automatisering van overheidsdiensten zou telkens het besef de boventoon moeten voeren dat wat vandaag voor eeuwig geld morgen achterhaald is. De wind kan zo maar uit een andere hoek waaien waardoor allerlei architectuur principes herijkt zouden moeten worden. Daar is geen tijd en geld voor dus raakt de belastingdienst in moeilijkheden als ze naast inning ook – op dat moment wezensvreemd – uitkeringen moeten gaan verzorgen.
Een ander debacle enkele jaren geleden gold de politie automatisering. Vanaf de zijlijn leek het er op neer te komen dat de automatiseerder zich aan zijn planningsafspraken had gehouden maar dat zij inhoudelijk vanuit de politie niet ondersteund werden…. dus ja, wat lever je op als je – vage – requirements hebt en weinig ondersteuning bij het specificeren en bouwen. Als automatiseerder moet je dan natuurlijk de opdracht teruggeven maar dat maakt je als programmamanager niet geliefd bij je werkgever.
Het zijn maar 2 voorbeelden.

De oplossingsrichting ligt in het rekening houden met deze menselijke en politieke gebreken; houd het klein, houd het kort, houd het simpel. Oftewel denk goed na over de korrelgrote van het aan te pakken probleem maak/koop deelsystemen en deelservices en knoop die – voor de totaal oplossing – aan elkaar (api raamwerk). Daarbij zouden een paar simpele vuistregels kunnen helpen. Laat je korrelgrote bepalen door wat – functioneel gesproken – altijd (in ieder geval langjarig) zo zal blijven (een debiteurenadministratie bijvoorbeeld zal qua functionele structuur niet gauw veranderen), maak voor elke zo ontwikkelde functionele component een aansluitcontract (functioneel interface). Huldig het principe van het huisje bij het schuurtje; bouw aan een goed werkend systeem geen wezensvreemde elementen. Nieuwe behoeftes? Dan nieuwe systemen! Dat nieuwe systeem kan dan voor overlappende gegevens behoeften gebruik maken van de aansluitcontracten die reeds bestaande andere deelsystemen publiceren.

Automatisering is een handwerk waarbij een trial en error methodiek (rond principes en uitgangspunten) sneller tot vooruitgang leidt dan eindeloos specificeren en testen.
Houd de te realiseren subsystemen/systeemelementen dus klein en overzichtelijk en combineer die systeemelementen op basis van hun aansluitcontracten naar behoefte. Is er een element, op basis van politieke wending bijvoorbeeld, niet meer valide? Vervang het element en pas het nieuwe element in in het netwerk van onafhankelijke subsystemen.

Feitelijk gaat het dus om automatisering per – min of meer – onveranderlijke (overheids-) businessfunctie. Dat kan per businessfunctie vrij makkelijk tot een goed werkend (sub)systeem leiden. Op termijn – niet exact planbaar mede omdat specificaties gedurende de ontwikkeling om meerdere redenen in beweging zullen zijn- zullen de gezamenlijke – geautomatiseerde – businessfuncties het gewenste resultaat opleveren.

Volgens mij niets nieuws maar politiek, bestuurlijk en juridisch lastig omdat deze werkwijze veel minder bestuurbaar lijkt. Daar staat tegenover dat de kennelijk bestuurbare aanpak niet tot resultaten leidt.

De basis voor succes (resultaat) is het accepteren van een zekere mate van onplanbaarheid. Politiek is dat beter verkoopbaar door niet te focussen op plannen en programma’s. Budgeteer, in plaatst daarvan, voor “onderhoud” en leidt uit de politieke afwegingen en wetten de vigerende principes af … en de wijzigingen daarop en verwerk deze in de – niet politieke – automatiseringsagenda.

Met belangstelling de interessante ervaringen en analyses gelezen. De rode draad is wel herkenbaar. Problemen met de kwaliteit van ICT in complexe organisaties hebben veelal te maken met traditionele randvoorwaarden die niet goed zijn ingevuld zoals een compleet ingerichtte IT governance, een éénduidig besturingsmodel alsmede duidelijke IT kaders en richtlijnen. Het IT antwoord op een organisatie zoals de overheid die regelmatig wisselt van visie en strategie is flexibiliteit en schaalbaarheid. Dus het adapteren van een moderne architectuur die dit ondersteunt lijkt dan logisch. Tot zover de inkoppers.
De oorzaak van bovengenoemde problematiek is echter lastiger op te lossen. Dit heeft alles te maken met organisatie en cultuur. Bij de overheid heeft dat een extra dimensie die politiek heet. Daar waar complexe organisaties in staat zijn om focus aan te brengen en invulling te geven aan bovenstaande randvoorwaarden is de kans op succes groter. Wat zou er organisatorisch moeten gebeuren bij de overheid om de kwaliteit van ICT te verbeteren ? Dat lijkt me een mooie uitdaging om op te pakken.

De problematiek is zeker herkenbaar. Toch ook even de kanttekening dat m.i. het in het bedrijfsleven ook lang niet altijd beter is. En zowel IT-projecten als andere waaronder de bouw vertonen deze problemen. Maar dan toch even een aanvulling op de analyse. Ja de aansturing speelt absoluut een rol. Daar is een belangrijke component de regeerperiode van max. 4 jaar. En ook in het bedrijfsleven, in de grotere organisaties, speelt de regeerperiode een rol. Veelal blijft de aansturing beperkt tot resultaten waarmee binnen die periode gescoord kan worden. De situatie wordt bovendien verergerd daar waar er een aantal bestuurlijke lagen tussen top en project liggen, ook wel de kleilaag genoemd. Daarin spelen allerlei, voor het project meestal niet relevante, afwegingen een rol. En uiteraard etaleert elke politicus zijn eigen visie op wat “de burger” wenst. Dit alles laat onverlet de rest van de analyse, maar het leek me een nuttige aanvulling.

Daan,

Goed initiatief.

Ik heb weinig concreet bij te dragen. Maar ik zie de genoemde symptomen ook bij sommige grote bedrijven.

Misschien is er een sterk driemanschap nodig:

– gedreven lead vanuit de ‘business’ (vergeef me de aanduiding, maar dat is hoe als ICT meestal onze counterpart in de bedrijfsinformatieprocessen aanduiden): iemand (misschien meerderen) met mandaat, autoriteit en duidelijk inzicht in het onderwerp en een visie waarheen

– sterke project manager (misschien een team), die zowel het proces als de financiën bewaakt: wat krijgen we voor ons geld, wanneer en hoe zeker is dat

– de enterprise architect, die weet hoe bedrijfsinformatieprocessen, organisatie en ICT landschap verweven zijn en welk van de drie wanneer leidend is; met voldoende autoriteit om sturing te geven

En vergeet nooit het verander management: mensen moeten anders gaan werken, moeten hun denken aanpassen en de cultuur moet om.

Maar dat zullen alle die ervaren senioren waaraan je refereert, weten.

Veel succes!

Dank en Vriendelijke groet,

Klaas Z