Home Innovatie & Strategie Digitale verkrotting van de IT bij de Nederlandse overheid

Digitale verkrotting van de IT bij de Nederlandse overheid

801

Door Daan Rijsenbrij, architectuurkenner & -auditor in de Digitale Wereld

Als belastingbetaler, als burger en als auditor van digitale architectuur, maak ik mij al jaren zorgen over de ineffectiviteit van de maatregelen van de Nederlandse Overheid aangaande de verbetering van haar IT.
Ik weet dat IT beslist geen sexy onderwerp is in de Tweede Kamer, maar je zou zoveel nuttige zaken kunnen financieren door te voorkomen dat belastinggeld wordt weggegooid aan nodeloze IT-mislukkingen.

Het nieuwe jaar is alweer triest begonnen met de ontboezemingen van Menno Snel (Staatssecretaris Belastingdienst, D66) en Sander Dekker (Minister voor Rechtsbescherming, VVD).
Het vermoeden is, dat er vanuit enkele andere overheidsorganisaties (wellicht Politie en UWV) op korte termijn soortgelijke geluiden naar buiten zullen komen.
Sommige politici worden gelukkig nu wakker en accepteren het niet meer dat het ambtenarenapparaat doorgaat met het laten mislukken van IT-trajecten.

Nieuw elan

Hoe zou de overheid kunnen worden geholpen haar IT in rustig vaarwater te krijgen?
Gezien mijn ervaring en achtergrond denk ik niet aan grootscheepse uitbesteding, maar ook niet aan 100% op eigen kracht verder gaan.
Ik geloof in een mix van (1) het betrekken van losse externe IT-veteranen, (2) het gebruik maken van kennis en ervaring in het bedrijfsleven, (3) externe, actieve coaching i.p.v. het werk extern te laten overnemen, en (4) een fris, nieuw elan in de IT-community van de overheid.

Er zijn bij de overheid meer dan voldoende vakbekwame IT’ers, alleen de aansturing en de besturing (opdrachtmanagement resp. projectmanagement) zijn soms nogal zwak. De derde klassieke boosdoener is de te vage digitale architectuur.

Rode lijn

Met bovenstaande boodschap startte ik op 5 mei jl. een discussie op LinkedIn (https://www.linkedin.com/feed/update/urn:li:activity:6398433844185354241)
Deze digitale discussie was zeer geanimeerd, maar mist een duidelijke rode lijn. Samen met de redactie van BlogIT wil ik langs deze weg het platform inzetten als katalysator voor een gestructureerde, gemodereerde digitale brainstorm.

In samenspraak zijn de volgende 10 discussiethema’s gekozen.

  1. De huidige problematiek in het IT-gebeuren van de overheid;
  2. De gewenste digitale situatie voor burgers, bedrijfsleven en de ambtenaren (korte termijn; lange termijn) en de daarvoor benodigde IT-kerndisciplines;
  3. De aanpak van het transformatietraject (een overall road map) en de financiering;
  4. Een eenvoudiger besturingsmodel van het IT-gebeuren (op alle lagen), incl. de continuïteit van de benodigde geldstromen;
  5. Een zakelijke en nuchtere auditing-aanpak van projecten en programma’s, en wellicht ook het portfolio-management;
  6. Enkele simpele uitgangspunten voor architectuur en engineering;
  7. De rol en plaats van de data-infrastructuur (incl. kennis);
  8. Een moderne vorm van systeemontwikkeling, beheer (incl. kwaliteitsclassificatie van de bestaande applicaties/apps) en exploitatie.
  9. Security-, privacy- en wellicht andere compliancy-zaken.
  10. Communicatie en publieke etalering van de (tussen)resultaten.

Participanten

Wij beginnen deze gemodereerde blog met het eerste gespreksthema: ‘De huidige problematiek in het IT-gebeuren van de overheid’.
U als digitale participanten worden uitgenodigd te antwoorden/aan te vullen. BlogIT zal bewaken dat de antwoorden relevant zijn, dus horen bij het gespreksthema.

Wij hopen uit elk van de 10 gespreksthema’s voldoende respons te krijgen om er een verhaal van te maken dat informatief en inspirerend zal zijn voor de (top)ambtenaren en de politiek.
Bij voldoende succes zullen wij de 10 verhalen, netjes opgemaakt, als open brief aanbieden aan de politiek.

Anoniem

Mocht u bij de overheid op de loonlijst staan en niet willen/durven reageren onder eigen naam, stuur dan uw bijdrage naar Blogit (redactie@blogit.nl), vanuit uw overheids-emailadres met de opmerking ‘anoniem’. Dan wordt de bijdrage als deze passend is bij het fungerende gespreksthema, geplaatst onder de naam ‘anoniem’.

10 hoofdpunten

De huidige problematiek in het IT-gebeuren van de overheid:

  1. Onvoldoende doorzettingskracht naar binnen.
  2. Zwak opdrachtmanagement naar buiten.
  3. Onvoldoend zakelijk project- en programma-management.
  4. Te wollige architectuur.
  5. Ondoelmatige architectenpopulatie.
  6. Vaak een te ingewikkeld systeemontwikkeltraject
  7. Eerste Hollandse ziekte: praten, praten, praten; eindeloze discussies, poldermodel.
  8. Tweede Hollandse ziekte: kijken, kijken, niet doen. Uit mijn netwerk blijkt dat de halve wereld op uitnodiging al langs is geweest bij de overheid voor lezingen, brainstormingssessies en korte adviezen, maar het beklijft niet.
  9. Te zwakke aansturing en motivering van eigen talent. Toch zie ik redelijk wat individueel vakmanschap, dat waarschijnlijk lichtelijk dient te worden gepolijst.
  10. Onvolledige, onduidelijke etalering naar stakeholders en andere betrokkenen

Dwangbuis

De overheid lijkt klem te zitten in de dwangbuis van haar eigen legacy. Legacy in de software, maar wellicht ook legacy tussen de oren van vele van haar IT-managers en de betrokken politici. Zo kan bij voorbeeld de Belastingdienst in haar huidige IT-toestand nauwelijks een broodnodige stelselvernieuwing aan.
Effectiviteit, efficiency, security en adaptiviteit zijn basaal voor een bruikbare IT. Vooral adaptiviteit is cruciaal bij de uiteenlopende wensen van de Tweede Kamer.

Ik heb de stellige overtuiging dat als gemeenschappelijke noemer achter al deze punten een mentaliteitshouding zit. Naast het oplossen van bovengenoemde zwakheden (lijkt mij inhoudelijk trouwens niet zo moeilijk), is er een fris, nieuw elan nodig in de IT-community van de overheid.

Ik kijk uit naar uw reacties!

15 REACTIES

  1. 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

  2. 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.

  3. 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.

  4. 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

  5. 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

  6. 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.

  7. 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.

  8. 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?

  9. 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.

  10. 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…

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

  12. 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.

  13. 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.

  14. 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:

  15. 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.

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here