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

Digitale verkrotting van de IT bij de Nederlandse overheid

2604

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!

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

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

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

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

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

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

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

  22. Daan, hoe krijg je het toch weer voor elkaar om zoveel toetsaanslagen uit te lokken, chapeau.

    Het is enigszins verwonderlijk dat we ons verwonderen over het ‘mislukken’ van ICT projecten en de gebrekkige staat van een belangrijk aantal systemen omdat dat door veel van de betrokkenen (soms indirect) in de hand gewerkt wordt. Hieronder mijn observaties en analyse.

    1. Zwalken

    Er zijn meerdere zwalkbewegingen van invloed op de staat van de IT systemen, ieder met zijn eigen ritme. Ten eerste, tweede en derde waarschijnlijk de drie belangrijkste: twee slingerbewegingen van de politiek zelf. Er is de vierjaarlijkse wisseling van politieke macht waarbij een links-rechts slinger zorgt voor het meer of minder bij de overheid halen van taken en het verleggen van prioriteiten. Dat zorgt voor een regelmatige verandering van de opdracht van de ‘business’ bij de overheid.

    Vervolgens is er de meestal aanwezige geldingsdrang van de dienstdoende minister en stas die hun kiezers beloofd hebben ‘iets te veranderen’. Da’s de tweede slinger die afbreuk doet aan de lange termijn stabiliteit van de organisatie en haar doelen.

    De derde slinger wordt aangedreven door punt 3 van Dick van Dijk (uit enquetecommissierapport), “perverse prikkels”. Er schijnen leveranciers te zijn die hun diensten en producten graag aan de overheid verkopen. Dat doen ze met wisselend succes, beïnvloed door de dienstdoende manager / directeur die vaak ook een eigen agenda heeft.
    Ter illustratie, tijdens een van mijn werkperiodes bij UWV, zo’n tien jaar geleden, was de dienstdoende directeur IT (CIO) begonnen met het op grote schaal uitbesteden van álle systemen naar IBM (HRC in België). Dit om beheerkosten in de hand te houden. Deze meneer was in eerste instantie zelfstandig, maar omdat er bij UWV een reductie van extern personeel gaande was is hij toen zelf in dienst gekomen. Du moment dat de outsourcing compleet was ging hij uit dienst bij UWV en in dienst bij IBM. Over eigen agenda gesproken. Nu zeg ik niet dat ik dat niet zou doen als ik de kans kreeg. Het feit dat dit soort kansen er zijn is teleurstellend en hangt samen met Dick’s punt 2: gebrek aan kennis.

    Overigens ben ik bij UWV zeer positief verrast door de inzet en kennis van personeel/collega’s, ik denk dat het bedoelde kennisgebrek vooral op het directieniveau zit.

    2. Het politieke proces binnen een kabinetsperiode.

    Wetgeving kan tijdens de ontwikkeling van de (of aanpassing van bestaande) wet sterk veranderen. De systemen die de uitvoering van die wetten moeten ondersteunen moeten op ieder amendement worden aangepast. Daarbovenop kan de wet nog worden weggestemd in de tweede en éérste kamer, daarom moet voor ieder systeem een fall-back scenario worden ingericht. Dan gebeurt het regelmatig dat een wet per direct of zelfs met terugwerkende kracht ingaat. Ga daar maar eens klaar voor zijn, is lastig. Deze beschrijving is vooral van toepassing op uitvoeringsinstanties zoals DUO, UWV en Belastingdienst.

    Met dit gegeven, ben ik het niet helemaal eens met Rob van Dort die het te bizar voor woorden vindt dat de overheid er niet in slaagt lijn te krijgen in eigen IT. Ik ben het wél zeer eens met zijn idee van een proeftuin/innovatielab. Dat zorgt namelijk voor eigen kennis en zelfvertrouwen bij die overheid.

    3. Managementziekte

    De wens om overheidsorganisaties kleiner en daarmee goedkoper te maken leidt er bij veel instanties toe dat het een club van managers wordt zonder enige in-house kennis. Het kan bijna niet anders dan dat je je dan overgeeft aan leveranciers die kunnen vragen wat ze willen omdat de kennis niet voldoende aanwezig is in de overheidsorganisatie zelf. De gedachte dat we het wel kunnen ‘managen’ is verkeerd. Zeker als je punten 1 en 2 hierboven in aanmerking neemt.

    Een ander aspect van die ziekte is dat trajecten die innovatie vereisen niet de kans krijgen zich op een onderzoekende/lerende manier te ontwikkelen omdat alle activiteiten ‘gemanaged’ moeten worden. Van tevoren gepland, gemeten, voorzien van een dead-line, kortom vermoord (of in ieder geval ernstig gehandicapt) moeten worden.

    Als er een rode draad in de discussie is, dan is dat volgens mij dat we minder managers en meer leiders nodig hebben. Leiders die vanuit hun kennis (en ervaring) leiding geven, geen urentellers. Opleidingen zouden hier meer op gericht moeten zijn. Ik lees dit ook in de commentaren op deze blog terug, soms tussen regels.

    4. Cultuur, ethiek en eigenaarschap

    Het punt cultuur is al gemaakt door anderen in deze, waarschijnlijk binnenkort in boekvorm te verschijnen commentaarpagina. En terecht want zeer belangrijk. Ik wil daarnaast nog wijzen op ethiek en eigenaarschap.

    Met ethiek bedoel ik eigenlijk dat doen wat juist is in het licht van lange-termijn houdbaarheid versus dat doen wat handig is voor korte termijn resultaat. Dat zorgt voor beslissingen die beter zijn voor medewerkers, milieu en uiteindelijk de organisatie als geheel. Ik snap dat het moeilijk is voor managers om daarmee om te gaan, het is immers moeilijk te meten. Daar komt de ‘cultuur’ weer om de hoek, die overigens heel goed is uit te leggen.

    Eigenaarschap, ik zie het woord hier gek genoeg nog niet terug, is nodig om motivatie te hebben om een functie (zoals innen van belastingen) goed te beheren. Het hangt samen met leiderschap: in een ideale wereld is de eigenaar tevens de ‘leider’ van de club die aanpassingen aan het (basis)systeem doet. Door politiek (zie Zwalken hierboven) is het een lastige opgave om continuïteit in het eigenaarschap te houden. En, projectmanagers zijn geen eigenaars.

    Het neoliberale beleid van de afgelopen regeringen sinds Lubbers, wat er op gericht is overheidstaken te privatiseren, doet afbreuk aan het vermogen om eigenaarschap te kweken bij die overheidsdiensten.

    5. Ik wil graag ‘complexiteit’ en ‘onderschatting van complexiteit’ toevoegen aan de lijst oorzaken. Dit is iets chronisch en heeft te maken met kennis, maar ook met verstand en bevattingsvermogen. Als je als vragende partij enig zicht hebt op de gevolgen voor de ontwikkelaars van systemen, van je zwalkbewegingen, zul je misschien minder extreme eisen stellen / vragen stellen, of in ieder geval in overleg gaan. Andersom geldt natuurlijk ook. Opdrachtnemers- én gevers overschatten soms gezamenlijk de mogelijkheden van techniek en kennis en kunde van de opdrachtnemer(s).

    Onder- en overschatting is gevolg van de beperkingen van de menselijke maat. U kunt zelf in dit onderwerp de puntjes wel verbinden vermoed ik.

    Verder worden kosten in samenhang met die complexiteit volledig niet begrepen. In dit punt (5) zit een belangrijke taak voor de ‘ICT wereld’, wat dat ook mag zijn. Die taak is het mogelijk maken inzicht te kunnen krijgen in hoe complexe vraagstukken verantwoord opgedeeld kunnen worden in begrijpbare delen.

    Ten eennalaatste: de tien punten van dit blog.

    ‘Onvoldoende doorzettingskracht naar binnen.’ en ‘Zwak opdrachtmanagement naar buiten.’, ‘Onvoldoende zakelijk project- en programma-management.’, ‘Te wollige architectuur.’ en ‘Ondoelmatige architectenpopulatie.’
    Hangen m.i. samen met mijn punt 3, meer leiderschap uit kennis nodig.

    ‘Onvoldoende zakelijk project- en programma-management.’
    Hier wordt denk ik bedoeld dat er geen sanctie is op falen. Deze stelling mag wat mij betreft iets positiever gemaakt worden. Immers overheid en leveranciers hebben elkaar nodig maar het moet wel zo zijn dat contracten gehonoreerd dienen te worden. Is daarmee een cultuur/ethiek ding (zie mijn punt 4).

    ‘Te wollige architectuur.’ en ‘Ondoelmatige architectenpopulatie.’
    De beroepsgroep waarvan je zou verwachten dat ze in staat zijn een visie kunnen formuleren, kunnen omzetten naar implementatie, regels en structuur én dit in de breedte te communiceren is de groep enterprise architecten / informatie (en business) architecten.

    ‘Vaak een te ingewikkeld systeemontwikkeltraject’
    Zie mijn punt 5, complexiteit. Het lukt zelden een groot project in kleine stukken op te delen. Ik denk dat dit aan te pakken is met onderzoek en opleidingen in het domein projectmanagement.

    ‘Eerste Hollandse ziekte: praten, praten, praten; eindeloze discussies, poldermodel.’ en ‘Tweede Hollandse ziekte: kijken, kijken, niet doen.’
    Zie ik niet zozeer als oorzaak maar als gevolg van onvoldoende kennisgebaseerd leiderschap aan de kant van de opdrachtgever. Zie mijn punt 3. Dit soort leiderschap hoeft niet altijd op het directieniveau te zitten maar kan ook uitgedragen worden door bijvorbeeld architecten.

    ‘Te zwakke aansturing en motivering van eigen talent.’
    Leiderschap in samenhang met eigenaarschap en ethiek. Eigen agenda en houding van “na ons de zondvloed”.

    Onvolledige, onduidelijke etalering naar stakeholders en andere betrokkenen
    Ik weet niet op wie dit van toepassing is, maar zou van toepassing kunnen zijn op de opdrachtgever en de leverancier. Indien van toepassing op vragende kant zou ik willen verwijzen naar mij ‘Ten laatste: Eigen boezem’. Indien van toepassing op leverancier/aannemer, zie tekst over eigen agenda etc.

    Ten laatste: Eigen boezem.
    De ICT wereld waarin ik in de afgelopen 30 jaar mee bekend ben geraakt zie ik als een onvolwassen, opportunistisch, visie-arm en zelfvoldaan vakgebied waarin het over het algemeen vreemd gevonden wordt dat mensen die buiten ICT of techniek staan, niet snappen hoe iets werkt, terwijl we het zelf niet goed uitgelegd hebben. Tenminste niet in de taal die begrepen wordt. Uitzonderingen daargelaten.

    Wim Kok, minister-president, houdt (in 1994) een muis voor het computerscherm in de hoop dat er iets gebeurt en hij wordt uitgelachen. Ik denk dan dat we als IT gemeenschap vreselijk tekort geschoten zijn in het simpelweg vertellen waarom het er is, wat het doet, hoe het dat doet en hoe je het gebruikt.

    Als dat te wijten is aan de communicatiekloof tussen hele technische mensen en normale stervelingen (inclusief politici), dan is dus het probleem dat we het communiceren niet op dezelfde wijze vervolmaakt hebben als de slimme oplossingen die bedacht zijn. Als je denkt dat een computermuis daar niet onder valt dan heb ik mijn punt niet goed kunnen maken en heeft men zich niet goed verplaatst in de potentiële muisgebruiker.

    Ik vind dan ook dat wanneer een ‘it-er / it-ster’ een persoon spot die met gebruik van een IT toepassing in de problemen is, hij / zij hulp zou moeten bieden, net zoals een iemand uit de beroepsgroep gezondheidszorg gehouden is om mensen in gezondheidsnood te helpen.

    Afsluitend

    Als er qua kennis, niet enig level playing field is bij aanbestedingen van complexe IT projecten, is de kans van slagen vrij klein. Dat straalt ook af op de aannemer.

    Architectuur, waaronder communicatie, helpt en verder gezond verstand. Creëer dus een omgeving waar gezond verstand als methode gebruikt kan worden.

  23. IT malaise en meer

    1. De narigheid
    De malaise met de toepassing van informatietechnologie (IT) bij de overheid is maar al te goed bekend. Malaise bij andere organisaties loopt veel minder in het oog. Echter, veel literatuur leert dat bij vele organisaties het succesvol toepassen van IT problematisch is. Vele initiatieven op dit gebied mislukken: leveren niet het beoogde resultaat, of zijn zelfs contraproductief. Om het geheugen even op te frissen: onder het label ‘business en IT alignment’ worden reeds decennia lang allerlei benaderingen gepropageerd die de IT malaise beogen te voorkomen. Betrekkelijk vruchteloos overigens, want van ‘alignment’ is weinig terecht gekomen. Sterker nog, mislukkingen betreffen niet slechts IT initiatieven, maar evenzeer (strategische) organisatorische veranderingsinitiatieven in het algemeen. Ook daar is uitgebreid in de literatuur over gerapporteerd. Om een recent voorbeeld te noemen: de Ombudsman rapporteerde onlangs over de poging van de overheid de zorgverlening ‘dichter bij de burger’ te brengen. Zorgverlening ging bij dit organisatorische initiatief van de centrale overheid naar decentrale gemeenten. Van de beoogde doelstellingen is nagenoeg niets terechtgekomen. Integendeel: de burger is slechter af en verdwaalt in een ondoorgrondelijk woud van regels, loketten, en bureaucratie (waar ook de professionals niet meer uitkomen), en waarbij allerlei instanties volkomen langs elkaar heen werken [Dagblad Trouw, 14 mei 2018]. De historie van organisatorische veranderingsinitiatieven kan met recht worden gekarakteriseerd als de ‘caleidoscoop van mislukkingen’.

    2. Het conceptuele kader
    Over de kernoorzaken van deze caleidoscoop heb ik elders uitgebreid geschreven. Aan die kernoorzaken gaan de in dit blog genoemde discussiethema’s en hoofdpunten betreffende de IT problematiek in belangrijke mate voorbij. Waarom? Omdat de validiteit van die thema’s en hoofdpunten een conceptueel kader veronderstellen waarmee het belang of de irrelevantie kan worden geargumenteerd. Aangezien dit conceptuele kader ontbreekt vraag ik aandacht voor twee aspecten: (1) de essentiële karakteristieken van een niet-triviale organisatieverandering, en (2) de wijze waarop een gewenste organisatieverandering uiteindelijk in de organisatorische werkwijze wordt geoperationaliseerd.
    Ten aanzien van het eerste aspect het volgende. Om talrijke redenen wordt elke niet-triviale organisatieverandering initieel gekarakteriseerd door (aanzienlijke) complexiteit en onduidelijkheid. De eerder genoemde transitie naar decentrale zorgverlening is daar een evident voorbeeld van. Voorts, een organisatieverandering kent twee principieel verschillende fases. Ten eerste de fase van het creatieve proces dat, gegeven de initiële complexiteit en onduidelijkheid, de gewenste verandering concretiseert en conceptueel realiseert. Dit creatieve proces is daarmee essentieel een emergent proces. De emergente uitkomst van dat proces is de conceptuele realisatie – het ontwerp in al zijn multidimensionele facetten – van de nieuwe organisatorische werkwijze. De tweede fase betreft bouw/implementatie van het ontwerp en betreft een algoritmisch proces. Dit proces is planbaar. Immers, er is een bekende uitkomst: de (fysieke) realisatie van het ontwerp. Planning is, in tegenstelling tot ontwerpen, reductionistisch: gaat uit van een bekend resultaat. De organisatorische competentie betreffende adequate organisatieverandering – waarbinnen voornoemde fases dus essentiële aspecten zijn – wordt aangeduid als enterprise governance (waarbinnen de aandachtsgebieden traditioneel behorend bij IT en Corporate governance zijn begrepen).
    Het tweede aspect van het conceptuele kader betreft de wijze waarop de nieuwe organisatorische werkwijze tot stand komt. Daar is veel over te zeggen, maar de essentie is ontwerpen. Deze essentie wordt bij nagenoeg alle artefacten onderkent: van bruggen tot vliegtuigen staat een valide ontwerptheorie centraal. Dit serieus nemen betekent voorts de erkenning dat elke adequate ontwerpwetenschap gefundeerd is in de geassocieerde fundamentele wetenschappen. Om maar wat te noemen: een adequate theorie voor het ontwerpen van een antenne is (mede) gefundeerd in de fundamentele theorie over elektromagnetische velden. Ook een adequate ontwerptheorie voor organisaties dient dus gebaseerd te zijn op een valide organisatietheorie. Fundamentele theorieën uit de sociale en organisatiewetenschappen zijn dus mede van belang. De ontwerptheorie betreffende organisaties wordt aangeduid als enterprise engineering. Begrippen als requirements, architectuur, modellen, etc. worden binnen de ontwerptheorie geoperationaliseerd. Het toepassen van deze theorie, methodologie en methoden is daarmee een belangrijk facet van enterprise governance.

    3. Kernoorzaken van de malaise
    3.1 Inadequate governance
    De twee verschillende fases van organisatieverandering, hoe kort-cyclish de fases ook kunnen zijn, dienen conceptueel onderkent te worden en methoden van de algoritmische fase kunnen niet gebruikt worden bij de creatieve fase. Hier stuiten we al op de eertse kernoorzaak van de (IT) malaise: inadequaat governance. Allerlei methoden worden geïntroduceerd die de essentiële karakteristieken van de creatieve ontwerpfase ontkennen of negeren. Ik noem slechts een paar twijfelachtige voorbeelden: vraag/aanbod management, contract management en de daarbij geldende aanbestedingsregels, project portfolio management, business case management, etc. De relatieve onbelangrijkheid van dit soort benaderingen voor het vermijden van de eerder genoemde malaise wordt al duidelijk als men zich probeert voor te stellen van het begrip ‘management’ hier precies inhoudt. Laat ik over deze methoden kort iets zeggen.
    Bij vraag/aanbod management is veronderstelling dat de klant beschikt over een helder, duidelijk omschreven ‘vraag’ die de leverancier vervolgens beantwoordt met het ‘aanbod’. Indachtig dit eerder beschreven karakteristieken van een niet-triviale organisatieverandering is dit een even gevaarlijke als naïeve vooronderstelling. Er kan immers initieel geen duidelijkheid bestaan omtrent wat de vraag precies is. Dat moet, in samenspraak met alle betrokkenen, nog worden uitgezocht (denk aan de transitie naar decentrale zorg). De interface tussen ‘vraag’ en ‘aanbod’ wordt veelal gevormd door offertes die – indachtig hetgeen eerder is geargumenteerd – bol staan van inhoudelijke en financiële schijnzekerheden, vooronderstellingen en wensdenken. Dit alles gebaseerd op de illusie van concreetheid en correctheid. Zaken worden als juist en begrepen beoordeeld die dat volstrekt niet zijn en ook niet kunnen zijn (in de woorden van Taleb: ‘epistemische arrogantie’). Niet zelden worden de schijnzekerheden vastgelegd in een ‘business case’ die vervolgens wordt ‘gemanaged’ (wat dat dan ook moge betekenen). Contract management en aanbestedingsregels dragen ook hun steentje bij aan de malaise daar die regels een heldere klantvraag veronderstellen en dwingen contractuele vragen te beantwoorden die, zoals eerder gesteld, (nog) niet beantwoord kunnen worden. Geïnstitutionaliseerd bedriegen en schijnzekerheden worden aldus ook contractueel verankerd, met alle narigheid van dien.
    Niet zelden wordt in zichzelf overschattende managementtaal ook over de SMART onzin gesproken: initiatieven (ten onrechte projecten genoemd) moeten ‘specific, measurabel, attainable, realistic, en time-based’ zijn. Om het wat scherp te stellen: als een initiatief aan de ‘SMART’ criteria voldoet stelt het qua omvang en complexiteit van verandering weinig voor, terwijl een niet-triviaal veranderingsinitiatief niet aan die criteria kan voldoen. Dit blijkt overigens geen beletsel om de portfolio van ‘projecten’ te ‘managen’. Op grond van welke criteria dat zinvol kan gebeuren blijft veelal onduidelijk evenals hoe de inhoud van projecten tot stand komt.
    Voorgaande past naadloos in de managementgedreven planning and control benadering. Daarbij gaat het vooral om budgetten, targets, prestatiecontracten, verantwoordelijkheden, alsook het hele circus van gegevensverzameling, rapportage, evaluatie, en bespreking van de aldus gecreëerde schijnwereld. Het geloof dat dergelijke geïnstitutionaliseerde managementrituelen primair succesvol kunnen zijn bij het voorkomen van de onderhavige malaise, zoals het eerder genoemde fiasco in de zorgverlening, toont een verbluffende onbekendheid met het wezenlijke karakter van organisaties en hun ontwikkelingen.

    3.2 Geen aandacht voor ontwerp
    Zoals gezegd, de nieuwe organisatorische werkwijze komt tot stand via ontwerpen. Het gaat dus niet over de bovengenoemde traditionele management trivia betreffende planning en control, verantwoordelijkheden, bevoegdheden, besluitvorming en de structuren daarbij, maar eerst en vooral over ontwerpen. Het eerder genoemde voorbeeld omtrent de malaise bij de transitie naar decentrale zorgverlening in herinnering roepend: het feit dat de overheid dit heeft besloten en de Tweede Kamer dit heeft geaccordeerd betekent nog geen succes. Integendeel, door het fiasco wordt schrijnend duidelijk dat geen aandacht besteed wordt aan het ontwerpen van de gewenste vorm van zorgverlening zodanig dat duidelijk wordt hoe die moet gaan werken en aldus voornoemde misère wordt voorkomen. Opnieuw: de ontwerpfocus staat bij alle artefacten centraal, variërend van bruggen tot vliegtuigen, zo niet lijkt het bij sociale artefacten. De gevolgen zijn navenant. Voorts, studies betreffende strategisch en operationeel succes van organisaties, of het ontbreken daarvan, tonen het belang aan van organisatorische samenhang en integratie (coherentie en consistentie). Zoals het voorbeeld in de zorgverlening laat zien: instanties die langs elkaar heen werken bevorderen geen adequate zorg. Ontwerp moet dus holistisch zijn en alle multidimensionele aspecten van organisaties omvatten, ook qua gehanteerde concepten. Het heeft geen zin organisatieveranderingen op het gebied van ziekteverzuim of de motivatie van medewerkers te initiëren met slechts de traditionele concepten ‘processen’, ‘informatie’, ‘applicaties’ en ‘infrastructuur’.
    Binnen het holistisch organisatorisch ontwerpperspectief zijn de informatievoorziening en IT integrale aspecten. Immers, het organisatorisch ontwerp, zoals dat van de decentrale zorgverlening, bepaalt de informatiebehoefte en dus de informatievoorziening voor de verschillende belanghebbenden. Daar het bepalen van de informatiebehoefte volgt uit diepgaand inzicht in de organisatorische inrichting en operatie heeft het definiëren van de ‘IT vraag’ niets van doen met IT governance, maar met enterprise governance betreffende de organisatie als geheel. IT governance als aandachtsgebied voor het realiseren van ‘business en IT alignment’ is dus betrekkelijk nutteloos. Het gebleken geringe effect van CIO functies kan dus tevens vanuit voorgaand perspectief worden begrepen.
    Gebrek aan adequate aandacht voor organisatorisch ontwerp is wijdverbreid, gedreven en in stand gehouden door het structuur- en managementgeoriënteerde governance perspectief dat hiervoor is bekritiseerd. Dit wordt in de hand gewerkt door personen op management posities die geen affiniteit hebben met (of benul van) ontwerpen. Problemen met infrastructurele ‘projecten’ hebben hier niet zelden mee te maken. Voor de overheid speelt hier nog mee dat de (eenzijdige) professionele achtergrond van leden van de Tweede Kamer ook niet bijdraagt aan inzicht in het belang van ontwerpen. Ook interesse daarvoor lijkt afwezig, want wij konden uit het blad ‘De Ingenieur’ van enige tijd gelden vernemen dat een van de weinige ingenieurs (wellicht de laatste) na enige jaren toch teleurgesteld de Tweede Kamer verliet daar men aldaar wel bezig is met allerlei beleidsvoorstellen maar volstrekt niet geïnteresseerd bleek in de vraag hoe dit alles organisatorisch adequaat gerealiseerd moest worden. Het echec met de decentrale zorgverlening is daarvan een voorbeeld.
    In het licht van voorgaande blijkt ook het onvermogen van de Tweede Kamer om de IT malaise bij de overheid werkelijk te doorgronden. De indertijd ingestelde parlementaire enquêtecommissie kwam niet verder dan een aantal traditionele structuur- en managementgeoriënteerde aanbevelingen zonder enige aandacht voor adequaat governance en integraal organisatorisch ontwerp. Allemaal betrekkelijk vruchteloos en net zo zinvol als denken dat problemen met het besturingssysteem van een auto op te lossen zijn via andere besluitvorming over investeringen! Het is om te lachen, ware het niet dat de ernst van de materie dit nauwelijks verdraagt.

    4. Resumé van de hoofdpunten
    Afgezien van pathologische redenen zoals politieke druk, management scoringsdrang, probleemontkennende cultuur, group think, wensdenken, of incompetentie, heeft de malaise betreffende organisatieverandering, en IT introducties daarbij, vooral te maken met:
    • Het denkraam. Een beperkt en in belangrijke mate onjuist conceptueel kader waardoor de kernoorzaken van de geschetste malaise eenvoudigweg niet doorgrond en dus niet aangepakt kunnen worden. Essentiële karakteristieken van organisatieverandering (governance) alsook de noodzaak voor een ontwerpfocus worden dus niet onderkent en begrepen.
    • Blussen met brandstof. Geprobeerd wordt de malaise te bestrijden met middelen die juist de malaise veroorzaken: de planning en control benadering met de daarin verankerde structuur- en managementgeoriënteerde ondoelmatigheden. Aandacht voor ontwerpen is daarin afwezig.
    • De myopie. Het idee dat de problemen met informatievoorziening en IT systemen primair een issue omtrent informatietechnologie betreft en dus iets voor de CIO (een functie die bijdraagt aan de myopie). Dus niet inzien dus dat adequate informatievoorziening begint bij organisatorisch ontwerp waarin die voorziening en het ontwerp van IT systemen integrale onderdelen zijn. De focus moet dus liggen op holistisch organisatorisch ontwerp.
    • Het onvermogen. Ondanks het enorme volume aan evidenties dat ‘het anders moet’ heerst het collectieve onvermogen het roer drastisch om te gooien. De burger, patiënt, consument, kortom het individu is uiteindelijk de dupe.

  24. Enkele geautoriseerde opmerkingen van Piet de Kam, ter overdenking.

    Daan, Het doet mij goed dat je nog steeds gespitst bent op goede oplossingen voor de IT bij de overheid. Ik deel je zorgen. Je volharding om tot verbeteringen te komen is aansprekend en inspirerend.

    Toch vind ik je analyse teveel IT-gerelateerd, terwijl het in feite om bedrijfsproblematiek gaat.
    Neem de Belastingdienst als voorbeeld. De opdracht is het belastingstelsel uit te voeren. Het Belastingstelsel is grotendeels functioneel ingericht met wetgeving per aangrijpingspunt voor de heffing, zoals inkomstenbelasting, omzetbelasting, enz. De processen van de Belastingdienst zijn hoofdzakelijk ingericht volgens de lijnen van de wetgeving.
    De dienstverlening aan particulieren en bedrijven vergen echter een integrale benadering van particulieren en bedrijven. Hetzelfde geldt voor het toezicht op de verplichtingen van particulieren en bedrijven.

    De oplossing van de IT -problematiek vergt in eerste instantie een integrale visie op de uitvoering van de verschillende bedrijfsprocessen in samenhang. Bij veel overheidsorganisaties en bedrijven ontbreekt het daaraan.
    Hoe complexer de bedrijfsprocessen in samenhang zijn, hoe complexer ook de IT-problematiek.

    In eerste instantie heb ik dus een bedrijfsarchitectuur nodig vanuit het perspectief van de wetgever, het perspectief van de belastingplichtigen (de particulier, de ondernemer), het perspectief van de processen van uitvoering, het perspectief van het toezicht op de verplichtingen van particulieren en bedrijven.
    Mede onder invloed van de digitalisering zijn de perspectieven op hoe je dienstverlening en toezicht invult, de laatste decennia enorm gewijzigd. Een integrale visie op de bedrijfsarchitectuur ontbreekt nog al eens, laat staan een goede vertaling van de bedrijfsarchitectuur in een IT-architectuur. En juist op dat punt wreekt zich de situatie dat de IT-architectuur op een verouderd concept van bedrijfsarchitectuur is ontworpen en gerealiseerd.
    Dat geldt nog eens te meer als de processen van de overheidsorganisaties via een keten van overheidsorganisaties moeten worden uitgevoerd.

    In feite zie ik de afstemming van bedrijfsarchitectuur en IT-architectuur als een cyclisch transformatieproces van zowel de bedrijfsarchitectuur en IT-architectuur die elkaar wederzijds beïnvloeden. Dat betekent in mijn visie dat zowel de bedrijfskennis als de IT- kennis binnen een overheidsorganisatie en bedrijf op een hoog kwalitatief niveau moeten zijn belegd.
    Het vorenstaande is voor mij een eerste orde problematiek. Daar wordt helaas binnen de overheid veel te weinig over gesproken, omdat het publicitair veel eenvoudiger is te spreken over mislukte IT-projecten of te hoge kosten van de projecten.

    Een tweede orde problematiek is vervolgens de organisatie van de IT-organisatie en de project- en programma-aanpak binnen de IT-wereld. De punten die je daar noemt zijn logisch en vereisen een intensieve aandacht. Op dit niveau komt het evenzeer primair aan op kennis en de organisatie van kennis binnen de IT en dan in het bijzonder op innovatie-mogelijkheden.

    Jouw 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, vind ik te naïef. Het samenwerken met het bedrijfsleven in vele verschillende vormen heeft de IT bij de overheid maar matig verder geholpen, omdat de bedrijven vaak niet instaat waren goed te doordenken wat er in feite werd gevraagd aan IT-oplossingen.
    Het mislukken van bv een pakketoplossing voor de incasso bij de Belastingdienst vind ik daarvan een sprekend voorbeeld. Daarom moet worden begonnen met een intern sterke IT organisatie die in meerjarenperspectief een samenwerkingsverband kiest met enkele bedrijven, bv voor architectuur, systeemontwikkeling en infrastructuur. Maar dan moet een bedrijf zich ook willen verbinden aan resultaten en niet alleen aan mensen wegzetten bij de overheid op basis van uurtje factuurtje. Om die reden vind ik dat benadering van IT-problematiek bij de overheid ook moet inhouden een benadering van de deskundigheid bij de IT-bedrijven in Nederland, met andere woorden bedrijven moeten dan kunnen aantonen dat zij in staat zijn tot externe, actieve coaching.

    Naar mijn mening weten de deskundigen bij de overheid heel goed hoe ze de trein weer op de rails kunnen krijgen. Het is niet echt een IT-probleem, maar veel meer een bestuurlijk en financieel probleem. De korte termijn politiek van de zaken bij de overheid binnen de financiële grenzen te houden, spoort niet met een lange termijn aanpak voor de IT- infrastructuur in ruime zin bij de overheid. Het wisselvallige beleid inzake het betrekken van externe deskundigheid, aanbestedingen e.d. werken evenzeer belemmerend.

    Omdat ook de hoogste managementposities bij de overheid voortdurend wisselen, ontbreekt de consistentie in een adequate aansturing van de uitvoering. Dit geldt m.i. overheidsbreed, bij de politie, defensie, de Belastingdienst en overige overheidsorganisaties.

    Ook de ervaringen met de leveranciers van voornamelijk softwarediensten in Nederland stemmen mij niet hoopgevend. Ook zij zijn in het algemeen gefocust op de korte termijn verdiensten en hebben veelal weinig oog voor een consistente lange termijn aanpak. De leveranciers kunnen soms ook niet anders, willen ze voor opdrachten in aanmerking komen.

    Uit mijn gesprekken met de huidige verantwoordelijken voor IT bij de Belastingdienst heb ik de indruk gekregen dat ze het verdomd goed weten waar de schoen wringt en zitten ze niet op aanvullende adviezen van buiten te wachten. De resultaten van de commissie- Elias en de instelling van een regeringscommissaris hebben alleen maar tot nieuwe bureaucratische controles geleid.
    Om die reden zie ik weinig fiducie in een kernteam, omdat uiteindelijk het schip toch wel op de klippen loopt en men gedwongen is de zaak structureel op te pakken. Dat is altijd jammer, maar soms onvermijdelijk. Hoewel dit fatalistisch klinkt, blijf ik toch optimistisch omdat uit mijn gesprekken binnen de Belastingdienst toch wel duidelijk naar voren is gekomen dat de deskundigen binnen de overheid het zelf ook wel weten en een structurele aanpak bepleiten.

  25. Wat me opvalt in de reacties is dat ze veelal over IT gaan. Als ik eerlijk ben krijg ik een wat machteloos gevoel als ik ze lees.

    Ik heb nooit voor de overheid gewerkt maar wel voor grote organisaties die sterk werden beïnvloed door overheidsregulering en samenwerkingsverbanden. En ik heb zeker bij hele grote administratieve organisaties gewerkt, met veel inhuur en een constante drive om te veranderen. Ik denk dat ik dus wel degelijk enig recht van spreken heb in deze discussie.

    Bij mijn grote ex-werkgevers konden we in den beginnen grote business vernieuwingen in een half jaar live krijgen. Nog maar 5 jaren later duurde het al 2 jaren om stabiel te worden en nog 5 jaren later bijna 4 jaren. We waren business vernieuwing op vernieuwing aan het stapelen en noodoplossing op noodoplossing. Daar tussendoor liepen pogingen om nieuwe IT- en organisatie technieken in te zetten die eerlijk gezegd soms bijna contra productief waren omdat ze nooit de tijd kregen om tot wasdom te komen. Ik kan alleen maar schatten welke prijskaartjes aan die business vernieuwing hingen. Des te hoger de kosten werden des te gekker de pogingen om die kosten te laten dalen. Het gevolg was alleen maar hogere kosten en nog complexere IT.

    Onder invloed daarvan ben ik in de loop van de jaren radicaal anders gaan denken. IT is niets anders dan business kennis omgezet in programma code. In organisaties waar de IT uit de hand loopt kijk ik dan ook eerst naar business kennis. Als dat ondoorzichtig, onduidelijk, ongecontroleerd, rommelig, etc is, dan kan IT alleen maar falen in haar missie.

    Ik ben, in een tijd dat ik nog heilig geloofde in IT als wondermiddel, met name beïnvloed door Taiichi Ohno en Shigeo Shingo van Toyota. Als een afdeling niet goed liep gingen lieten ze heel radicaal het proces stil leggen en vanaf de basis opnieuw opbouwen. Pijnlijk? Jazeker!, Kostbaar? Gek genoeg niet echt. Niet op langere termijn althans. Het is gewoon gezond boeren verstand wat ze bij Toyota toepasten. Ik stel het bij klanten wel eens voor. Haal iedereen uit het gebouw en laat ze in volgorde van proces weer opnieuw binnen waarbij we voor het binnen laten de betreffende processtap en de zin daarvan doorspreken. Uiteraard durft niemand dat aan en eerlijk gezegd tref ik ook nauwelijks organisaties die hun eigen proces voldoende begrijpen om dat te kunnen overwegen.

    Wil je de verkrotting bij de overheids ICT tegenhouden, dan moet je bij het begin beginnen. IT op zich heeft geen waarde. De waarde van ICT is datgene dat het toe voegt aan de business processen. Dat is namelijk waar de dienst geleverd wordt en het geld verdient. Voor de meeste IT’ers is dat al heel moeilijk om toe te geven. Dat komt omdat ze de business rules en proces logica bij de IT in trekken maar dat is een forse fout. IT is er geen eigenaar van maar alleen maar de partij die het automatiseert.

    Zolang we de IT verkrotting bij de organisaties (alle grote organisaties hebben er last van) als een IT probleem zien, gaan we het niet oplossen. IT verkrotting is het symptoom. Wanorde in regelgeving, werkwijze, verantwoordelijkheden en de daaruit volgende onmogelijke missie waar organisaties voor staan is de oorzaak.

    De oplossing vergt moed en ik vermoed dat we daar dan ook op gaan stranden. De oorzaak van IT verkrotting is een gebrek aan moed.

  26. Wat mij altijd opvalt is dat falen van projecten bij de overheid (trouwens ook in veel andere organisaties) schijnbaar niet is toegestaan. In dit streven naar 100% succes, gaat er uiteindelijk juist tamelijk veel mis zoals we in het rapport van de commissie Elias hebben kunnen lezen. Projecten worden vaak tegen beter weten in voortgezet terwijl het veelal beter zou zijn de stekker er vroegtijdig uit te trekken. Politieke inmenging helpt hier ook niet echt: dat betekent meestal wachten met het nemen van moeilijke beslissingen tot na de volgende verkiezingen. Het probleem is dat je vervolgens ook geen lering kunt trekken uit mislukkingen als een reguliere processtap – het mag immers niet- en dus weer externe adviseurs of een hele commissie moet optuigen in een poging de put te dempen.

    Daarnaast lijkt het dat externe adviseurs niet worden geselecteerd op de broodnodige complementaire vaardigheden, maar eerder op basis van de laagste tarieven – hieruit spreekt ook een beetje persoonlijke frustratie ;-). Hierdoor ontstaat al snel een zichzelf instandhoudende ‘inner circle’ van adviseurs waarbij weinig vernieuwend gedachtengoed binnenkomt.

    Ten slotte, ik vind het veel te gemakkelijk om de aanbestedingsregels als oorzaak van de problemen aan te wijzen. Zoals al eerder opgemerkt, het is met name de manier waarop deze regels bij de overheid worden toegepast – mensenwerk dus.

  27. De opmerking van Piet de Kam: “Omdat ook de hoogste managementposities bij de overheid voortdurend wisselen, ontbreekt de consistentie in een adequate aansturing van de uitvoering. Dit geldt m.i. overheidsbreed, bij de politie, defensie, de Belastingdienst en overige overheidsorganisaties”.

    Precies.
    Dit is m.i. de wortel van alle kwaad bij de overheid. Sinds eeen jaar of 15, 20, wanneer is het precies begonnen? is er bij de overheid een systeem waarbij managers boven een bepaalde schaal in een pool bij BZK terechtkomen, waarvanuit ze gerouleerd worden naar nieuwe functies. De norm: niet langer dan 3 jaar op één plek, anders is de carriere niet meer in de lift.
    Het effect laat zich raden.
    1) de managementlagen die niet voor roulatie via BZK in aanmerking komen, hebben wel de norm overgenomen: niet langer dan 3 jaar op één plek.
    2) aangezien de manager toch binnen 3 jaar weer ergens anders komt te zitten, heeft het nauwelijks zin om zich verdiepen in de inhoud. Bovendien leeft er nog steeds het hardnekkig beeld dat managers en inhoud niet samengaan. Resultaat: succesvolle managers hebben en krijgen geen verstand van de inhoud en blijven op afstand van datgenen wat ze moeten managen.
    3) Het 1-2-3 effect. Jaar 1 = maak kwartier en verzin een oplossing, Jaar 2= voer maatregelen door, Jaar 3 = Glansrijke zelfevaluatie en op naar de volgende klus. Veni Vidi Vici – Julius Caesar deed het al.

    Het overal effect is dat voor een aantal hardnekkige en complexe problemen een soort roulatie van oplossingen is ontstaan: dezelfde oplossing komt in de loop der tijd meerdere keren langs. Het enige verschil is dat de oplossing bedacht is door een ander manager en meestal een ander naampje of jasje heeft.
    Protesteren helpt niet. We kunnen het ook niet goed, protesteren. We zijn een gehoorzaam volkje, wij ambtenaren, tenslotten doen we gewoon wat de baas zegt al weten we dat het nergens toe leidt. Geschiedschrijven lukt ook niet. Zelfs de Tweede Kamer lijkt niet te zien dat sommige probleemanalyses en projecten al meerdere keren onder een andere naam zijn langsgekomen.

    Ik ben er persoonlijk van overtuigd dat het enige wat helpt, is om bestuurders en managers (en architecten zoals ikzelf 🙂 en ander volk dat dingen in werking zet zonder ze – in de regel – af te maken) te verbinden aan een project voor de vollledige looptijd. Pas dan krijg je echte verantwoording en echte (ver)binding.
    Veel van de projecten waar we het nu over hebben in de Overheid IT duren 10 jaar of meer. So be it. Dan maar niet elke 3 jaar verkassen. Mooi levenswerk, lijkt me, om van de IT voor de overheid iets goeds. Kunnen de carrieremakers naar het bedrijfsleven.

  28. De digitale verkrotting, gesignaleerd door Daan Rijsenbrij, levert inderdaad een erg triest beeld op. Als je zomaar een schatting maakt van tien grote IT drama’s bij de overheid dan kom je (met inbegrip van het Speer project met een geraamde schade van ruim 1 miljard Euro), op een enorme verspilling die wij als belastingbetalers bijeen hebben gebracht.
    Naast genoemd Speer-drama is het niet zo moeilijk om nog negen andere projecten over de afgelopen tijd te noemen met een verspilling van boven de €100 miljoen. Het bleken waardeloze investeringen die een claim op de belastingbetalers hebben veroorzaakt van meer dan twee miljard Euro.

    Hoe dit te voorkomen:
    Allereerst is het de attitude die moet veranderen. Door het managen van te complexe projecten vanuit het verleden hebben we een framework van regelgeving veroorzaakt waarbij de aanbestedingsregels misschien wel zorgen voor het grootste drama. Uit de laatste onderzoeken blijkt dat het effect hiervan nauwelijks financieel resultaat oplevert, laat staan kwalitatieve verbeteringen, terwijl de drama’s hiervan niet zijn te overzien. Eisen en wensen zijn niet wat de gebruiker nodig heeft maar worden beïnvloed in waar de aanbieder zich kan differentiëren van zijn concurrenten om de logica achter de waarderingen alleen naar zichzelf te beïnvloeden.

    Steeds opnieuw blijft men doordenken vanuit de legacy systemen die met complexe en verouderende technieken vanuit het verleden moeten worden voortgezet, inplaats van te denken aan het ontkoppelen van deze complexe systemen en deze dan verder te verrijken met nieuwe technologie die zich heeft bewezen om op een veel krachtige manier nu meer kleine en veel betere beheersbare oplossingen te ontwikkelen.

    Inplaats van de kennis alleen nog maar van buiten in te huren bij met name de grote System Integrators (SI’s) die belang hebben bij de voorzetting van het huidige beleid, zou men de beschikbare interne kennis moeten mobiliseren om met support van een enkele deskundige vernieuwingen te realiseren.

    Externe IT-veteranen zijn in staat om te helpen bij het doorbreken van de huidige verkeerde koers. Daarnaast, versterkt met actieve coaching, zijn kleine teams nu veel effectiever aan te sturen. Alleen zij kunnen het bewijs leveren dat deze op nieuwe leest gebaseerde oplossing niet alleen veel eenvoudiger (en bovendien tegen totaal andere kosten) binnen een enorme tijdsversnelling en bovendien kwalitatief veel effectiever kunnen worden gerealiseerd.

    Alleen meetbaar resultaat telt en kan overtuigingen dat het nu totaal anders kan. Alleen hierdoor is het mogelijk om een trendbreuk te realiseren met als resultaat om te komen tot fris elan waarbij bovendien gemotiveerde (vaak jonge) medewerkers zien dat hierdoor hun carrièrekansen enorm zullen toenemen en de beloning van vandaag dan veel minder belangrijk wordt in het licht van hun persoonlijke ontwikkeling in de komende jaren. Net zoals men vroeger trots was om een mooi uniform te tonen wat de professie van de persoon uitstraalde, zal jong IT-talent er trotst op zijn om te participeren in de meest vernieuwende weg naar de digitalisering van de samenleving.

    Deskundigen hebben de overtuiging dat dit zal resulteren in tenminste een verdubbeling van de productiviteit van de nieuwe generatie kenniswerkers en met daarnaast een top-serviceverlening voor de burger die de rekening betaald. Met dit digitale speerpunt kunnen we in ons mooie land vooruit lopen bij het realiseren van een digitale delta voor de European Westcoast. Wij zijn hier de drivers die de wereld van morgen effectiever maken hetgeen dan een zeer positieve inbreng zal hebben op de ontwikkeling van de mensen die binnen dit speerpunt vernieuwend participeren.

    Aanpak huidige problematiek IT-gebeuren van de overheid
    Mijn inziens vormen deze suggesties de basis voor een verbetering van de 10 tien hoofdpunten die Daan Rijsenbrij heeft benoemd als de veroorzaker voor de huidige problematiek in het IT-gebeuren van de overheid.
    Onvoldoende doorzettingskracht kan worden doorbroken door het inzichtelijk brengen van kleine successen die disruptive en veelbelovende verbeteringen inzichtelijk maken, waardoor er een soort van elite groepjes (groene baretten teams) ontstaan die door zelfbewustheid een autoriteit weten te vormen die niet meer (zoals nu) door de huidige politieke maatregelen en kleilagen in de organisatie zijn te negeren.
    Het huidige zwakke opdrachtmanagement naar buiten veranderd in een zelfredzame executie waarbij snelheid van handelen zal zorgen voor verassende inzichten die dan vooral durf oplevert om haalbare vernieuwingen steeds kleinschalig, maar zeer snel, op te pakken. Natuurlijk gaan dan soms dingen fout, maar wel snel en tegen nauwelijks te noemen kosten, waarvan we bovendien snel van leren. De mentaliteit zal moeten veranderen van het nederig vragen om toestemming vooraf naar het wat meer zelfbewust vragen om vergeving achteraf.
    Onvoldoende zakelijk project- en programmamanagement, zal altijd een probleem blijven als we de interne kennis van de processen overlaten aan externe ‘deskundigen’ die bovendien alleen maar zijn gemotiveerd om hun huidige honorarium te continueren. Inplaats van uitbesteding van grote projecten via aanbestedingen, waarbij de interne verantwoordelijkheid via de regelgeving is afgedekt, zal het veel effectiever zijn om persoonlijke verantwoordelijkheid te stimuleren, die dan bovendien inzicht geven in de persoonlijke prestaties van betrokkenen en niet zoals voorheen generiek verdwijnen. Bij resultaat lacht het betrokken personeelslid een goede carrière toe, waarbij versnellingen in mijn loopbaan niet meer traditioneel via bestaande schalen met doorlooptijd van jaren duren. Talent wordt direct opgemerkt en kan hierdoor veel beter kan worden ingezet met veel meer verantwoordelijkheid bij innovatieve projecten. De overheid zal dan veranderen van traditionele opdrachtgever naar een actieve launching customer die aan de buitenwereld laat zijn waartoe de digitalisering van morgen in staat is. Dit zal dan een enorme katalysator zijn voor innovatieve vernielingen in het midden en klein bedrijf. Zijn de huidige talentvolle medewerkers na jaren van productieve bijdrage niet allen meer in te schalen? Geen probleem het bedrijfsleven wil dan graag een gedeelte van hen overnemen waardoor veel andere jongere talentvolle krachten intern graag hun posities willen innemen. Denk aan vroegen het model van korte termijn vrijwilligers die binnen defensie een goede leerschool ontvingen en als waardevolle kracht de industrie verder konden brengen.
    Inderdaad is de architectuur te wollig. Als men meer consequent het Pace Layer Strategy Model van Gartner zou gebruiken en de desbetreffende layers zou gebruiken voor deeloplossingen die goed zijn ontkoppeld zou men in staat zijn om in de innovatieve 3e layer, veel eenvoudiger dan nu, vernieuwingen door te voeren die de productiviteit van de kenniswerkers drastisch beïnvloeden, alsmede de services voor de burger sterk verbeteren, terwijl de bestaande legacy systemen stap voor stap beheerste worden afgepeld. ‘Sunset of legacy’. Hierdoor worden de grote risico’s bij de huidige aanpak vermeden.
    Ondanks veel talent en een ruime architectenpopulatie wordt er niet effectief gewerkt door de huidige architecten. Er is geen eensluidende visie en ieder zit op zijn eigen manier gekluisterd in de vele en complexe legacy projecten, waardoor deze architecten hun handen bovendien vol hebben aan de bedreigen van de op winst bejaagde System Integrators. Vaak moet veel schaarse energie worden besteed in een juridisch steekspel.
    Bovenstaande opmerkingen resulteren door de steeds blijvende verouderde aanpak van de grote en complexe opdrachten in een zeer complex systeemontwikkeltraject. Hierdoor ontstaan er veel onzekerheden waardoor de verantwoordelijke managers geen keuzes meer kunnen maken en bovendien de politiek bij verre na niet meer in staat is om deze mega projecten te overzien. Denk o.a. aan het drama van SPEER waardoor nog steeds niemand in staat is (bovendien niet de durf heeft) om op een bepaald moment projecten te stoppen.
    De traditionele Hollandse praatziekte is bij mijn bovengenoemde lean aanpak verdwenen. Inplaats van praten kunnen we nu snel executeren.
    Niet meer de kat uit de boom kijken en bovendien te bang zijn voor het nemen van acties. Korte adviezen veranderen bovendien nu in korte executies waarbij de resultaten direct meetbaar zijn in productiviteitsverbeteringen van de kenniswerkers alsmede in serviesverbeteringen voor de burger.
    De zwakke aansturing van talent moet worden opgelost. Het lijkt dat nu alleen de kneuzen voor de overheid willen werken en de talentvolle medewerkers weggekocht worden. Dit kan nu fundamenteel veranderen. Er is gelukkig (nog) ruim voldoende vakmanschap aanwezig. Maar bovendien is de kennis van de interne processen bij de eigen medewerkers veel beter beschikbaar en bovendien beklijven ze veel beter. Hierdoor zijn ze nu in staat zijn om permanent (ongoing improvement), en ook snel, nieuwe workflow processen op te leveren. Bovendien zijn deze workflow processen niet meer zo complex en door de nieuwste tools nu vaak op een tien keer snellere manier te vertalen naar smart apps. Hierdoor gaat het huidige ondergesneeuwde talent schijnen. Dit geeft deze mensen een veel meer elitaire houding en bovendien trotst om deel uit te maken van een speerpunt van waaruit de meest innovatieve vernieuwingen op het gebied van digitalisering in Nederland plaats vind. Schoolverlaters zullen dan in de rij staan om hieraan voor een aantal jaren deel te nemen om dan na enige jaren hun carrière verder door te zetten bij toonaangevende bedrijven. De overheid fungeert dan als launching customer voor innovatieve vernieuwingen.
    De onduidelijkheid naar stakeholders en andere betrokkenen kan worden verbeterd door directe participatie van eindverantwoordelijken, die in het huidige systeem door de onduidelijkheid in de complexe projecten, met de handen in de zakken aan de zijlijn staan. Een Digidelta of een Innovatieplatform 4.0 onder leiding van de huidige minister president en omringd door financieel onafhankelijke deskundigen zou hiervoor een aanzet kunnen geven. De focus moet liggen bij het versterken van kleine innovatieve projecten, die niet meer complex zijn. Tegelijkertijd zorgt dit voor het terugdringen van de huidige schijnbare verbeteringen middels veel te complexe projecten. Onzekerheden en de risico’s worden dan drastisch beperkt en bovendien wordt de drain van de nutteloze geldstroom van de belastingbetaler beperkt of kan eventueel meer effectief worden ingezet op strategische gebieden. Dan is er nog hoopvol ons mooie land om een vooraanstaande rol te spelen op eGovernace 4.0 in de wereld van morgen.

  29. Als aanvulling op bovenstaande zaken ben ik van mening dat er twee fundamentele issues spelen waar de politici zelf schuldig aan zijn.

    1. De onnodige complexiteit van wetgeving, neem bijvoorbeeld het hele stelsel van toeslagen van de Belastingdienst. Dit heen-en-weer schuiven van potjes met alle bijbehorende regeltjes, voorwaarden en controles kost klauwen met geld, maakt de ICT van de Belastingdienst onnodig complex en levert niets op. Kortom sterke vereenvoudiging van het systeem waarbij de (financiële) impact voor de burger minimaal moet blijven.

    2. Beperking van Europese bemoeienis. De EU bemoeit zich meer en meer met zaken die veel beter op nationaal niveau afgehandeld kunnen worden, en zo onnodig complex worden en extra ICT voorzieningen vereisen. Door deze bemoeizucht af te houden en kritisch te beoordelen of extra wetgeving ons als land wel helpt, kan de impact worden beperkt.

    Kortom voordat we starten met slimme ICT maatregelen, aanpak van de cultuur op de werkvloer, moet de basis wel op orde zijn. ICT is geen wondermiddel om alle hersenspinsels van politici vorm te geven, het wordt een rommeltje als je je wetgeving niet eenvoudig en doelmatig houdt.

  30. Een aantal reflecties op wat ik als (extern) dienstverlener zie binnen de overheid.

    Cloud
    Nog afgezien van inhoudelijke aspecten als security, heb ik de indruk dat wetgeving (regels voor aanbesteding erg achterlopen). Er is iig bij ons in de organisatie enige onduidelijkheid hoe we diensten af moeten nemen bij een CSP. De regelgeving schrijft voor dat we deze over drie jaar contant moeten maken (terwijl we voor servless computing nauwelijks weten wat de kosten zijn na drie jaar). Dit impliceert dat we aan moeten besteden bij een Broker. Die moet daar een fee voor hebben, terwijl daar geen toegevoegde waarde voor wordt geboden.

    Cloud en BIR
    Ik merk dat overheidsinstanties erg krampachtig reageren op public cloud. Die angst zorg er ook voor dat er argumenten tegen worden aangedragen vanuit de brief van Donner (2011) waar overheid in de richting van een gesloten branch-cloud wordt geduwd. Het zou niet veilig zijn, BIR compliant etc. Wij maken als overheidsorganisatie gebruik van Public cloud en hebben op basis van assessments door KPMG vastgesteld dat deze deployement 98% compliant is met de BIR. Het is vooral boeiend om vast te stellen dat het merendeel van de overheidsorganisaties met een onprem datacenter of datacenter partner misschien net over de 50% komen. Dat heeft vooral te maken met het ontbreken van patronen als ‘security tiering’ en ‘application isolation’, authenticatie en encryptie van data in transfer en at rest.

  31. Er zijn al veel goede aanvullingen gemaakt. Ik zou nog willen toevoegen dat de bestuurlijke- en organisatorische structuren vaak onnodig complex zijn waardoor het lastig is om besluiten te nemen. De complexiteit van de organisatie bepaalt de kwaliteit van de output. Een eenzijdige focus op IT gaat de problemen mi daarom niet oplossen: overheidsorganisatie moeten eerst eenvoudiger en slimmer kunnen opereren…

  32. Beste Daan en alle anderen,

    Zelf nu werkende (bijna 1 jaar) bij een middelgrote gemeente in Nederland als architect met juist als opdracht de architectuur op een hoger plan te tillen vallen me natuurlijk wel een aantal dingen op. Overigens heb ik 20 jaar ervaring als “consultant” werkende vanuit het bedrijfsleven, waarbij ik vele commerciële als overheidsorganisaties als “klant” heb gehad. Ik heb geen blad voor de mond, voor diegene die mij niet kennen, maar probeer mij wel zoveel mogelijk op objectieve feiten te baseren.

    In vele commentaren kan ik mij vinden, in vele anderen niet. Het zou te ver voeren om dit allemaal op te gaan voeren. Ik zie voor mijzelf en pratende met veel andere collega’s binnen de gemeentewereld en daar buiten en met leveranciers een aantal observaties:
    – allereerst (en daarmee probeer ik niet de gehele blog van Daan onderuit te halen) is het maar de vraag of alle IT-projecten mislukken. Daar zitten drie aspecten aan deze stelling. De eerste twee zitten hem in de definitie. Wat is een IT-project en wat is mislukken? Een wellicht nog veel belangrijkere vraag is: is er dan een lijst van alle IT-projecten met hun uitkomsten?
    – stel dat de stelling waar is (aanname 1), dan rijst de vraag waar je het antwoord moet gaan zoeken. Dat kun je puur vanuit de stelling doen, maar je zou ook alle resultaten van IT-projecten op een rijtje kunnen zetten en alleen inzoomen op de faalaspecten. De rest laat je dan ongemoeid.
    – Een andere manier om tot antwoorden te komen is alle beperkingen weg te halen: dus wat zou je morgen doen, als je het complete alleenrecht had over de complete overheids-IT, je had een ongebreideld budget en de beste IT-ers. Mijn eigen stelling zou dan zijn dat je antwoord dan nog niet vindt.

    Inhoudelijk doe ik de volgende constateringen en stellingen:
    – Voor mij bestaat er niet iets als een IT-project. En dat is nogal een dingetje. Het woord project zegt mij iets dat er blijkbaar iets in de staande organisatie moet gebeuren (aan activiteiten en middelen) om die te “verbeteren”. Daar begint eigenlijk bij mij elke vermeend project en ik zou het op dat moment in de tijd geen project noemen, maar een idee/suggestie. Probleem is dat het idee vaak in de vorm van een oplossing word gepresenteerd. Mijn eerst antwoord op dit soort ideetjes of gedachtenspinsels is: “Welk probleem wil je ermee oplossen, en dan niet in de zin van dat er iets NIET werkt, maar ook entamerend op dat er ook iets SLIMMER, EFFICIENTER of GOEDKOPER kan”. Vaak zie je mensen dan schrikken of achter hun oren krabben, omdat ze zich niet eens realiseren of het idee wel enig soelaas voor IETS biedt. Het onderwerp waar ik het hier over heb, is vraagarticulatie. Dat is het deelvakgebied van de informatiemanager en/of architect. Een goede opdrachtgever zou deze tot in zijn haarvaten moeten beheersen. Mijn ervaring (en die van vele collega’s) leert dat dit niet het geval is. Het vereist meer dan gemiddelde vakinhoudelijke kennis en vaardigheden om een ideetje/suggestie te promoveren naar een daadwerkelijk initiatief (een vastgestelde behoefte die een daadwerkelijk probleem adresseert, dus GEEN oplossing). Wat het ook vereist is een sterke persoonlijkheid en onafhankelijkheid in doen en laten. De ideetjes/suggesties die vaak op tafel komen zijn vaak stokpaardjes en hebben een zware politieke lading. Ze hangen vast aan enorme ego’s en staan bol van de hyperbolen. Om daar weerstand tegen te bieden, moet je wel je mannetje staan.

    Binnen de overheid zijn het vaak politici of directies die met dergelijke ideetjes komen. Politici neem ik niets kwalijk, zij zijn gekozen en niet in dienst. Dat zegt nogal wat: er word geen enkele inhoudelijk eisen gesteld aan politici. M.a.w vakvolwassenheid, vaardigheden en houding/gedrag zijn compleet niet getoetst. Dat is waar we blijkbaar voor gekozen is in onze democratie.

    De ambtelijke top is vaak ook de initiator van ideetjes/suggesties. Daar zou je mogen verwachten dat er voldoende kennis en kunde zit. Helaas merk ik dat velen op die posities niet eens beseffen waar ze het over hebben. Daarmee een compleet ambtenarenapparaat aan het werk zetten, zonder enig idee van de gevolgen. Als veelvuldig genoemd, de sturing is vaak zwak en de verantwoordelijkheid nemen voor de gevolgen is er vaak helemaal niet.

    De stelling die ik hier maak is dat vraagarticulatie, wat daar begint echt elk project mee, vaak de oorzaak is van alle faaltrajecten. En dat heeft bij niets met IT-projecten te maken, maar met alle projecten (dus ook grote infrastructurele tot en met hele grote administratieve gedrochten). Als er geen directe aanleiding is om iets veranderen, waarom gaan we met zijn allen (dus de initiators, ambtenaren en leveranciers) als makke schapen achter het idee aan hollen. Ik noem een aantal redenen: angst (bang voor positie), skills (vakinhoudelijk zwak en vaardigheden missend), ego (meelopen met de initiatiefnemer om goede zier te maken).

    Als bovenstaande redenen de daadwerkelijke oorzaak zijn voor de problemen, moeten we het wellicht helemaal niet zoeken in technologie en projectmethodieken en wat al niet meer, maar eerder in een “veilige omgeving” die ook nog eens zwaar toetst op haalbaarheid en realiteitszin vooraf. Wat in ieder geval een oplossing zou kunnen zijn (maar dat is voor de troepen vooruit lopen) is een ieder te laten (h)erkennen dat een initiatief vormgeven een vak is, dat meer dan gemiddelde vakinhoudelijke discipline, vaardigheden en een sterke persoonlijkheid vereist. Dat de aandragers van de ideetjes/suggesties die niet of nauwelijks (uitzonderingen daargelaten) bezitten. En er dus anderen moeten zijn die die schone taak op zich nemen. Veel kennis en kunde van op tactisch/operationeel niveau (met voldoende aanhaking bij de strategie) zit op lagere echelons in veel organisaties, ook bij overheden. Zij kennen de ins en outs van de staande organisatie en zijn de gesprekspartner. Geef de mensen die “veilige omgeving” en voor deze mensen is het zaak om vaardigheden te ontwikkelen om je als professioneel gesprekspartner met directie of politiek van gedachten te wisselen.

    – Mocht uit de vraagarticulatie een daadwerkelijk initiatief komen dat “hout snijdt”, komt een verandertraject al gauw in zicht. Is de verandering van dermate grote omvang of complexiteit, dan praten we al gauw over een project. Voor mij bestaan er geen IT-projecten, maar ook geen business-projecten (overigens leuk om te weten, maar de term business is door IT-ers “verzonnen”). Even kort een training hoe los ik een probleem in de “business” op: pak het organisatie proces en kijk welke stap ik om kan draaien, eruit kan trekken, of welke skills ik in het proces moet opwaarderen of juist moet toevoegen om het proces lekkerder laten lopen. Mijn stelling: 80% van alle “projecten” hebben als oplossing een proceswijziging en minimale IT-wijzigingen. Oorzaak: slechte vraagarticulatie!
    – Trek de stekker uit de veranderopdracht (project) als de oorspronkelijke vraag er al helemaal niet toe doet. Vaak duren opdrachten zo lang, dat het “probleem” als sneeuw voor de zon is verdwenen. Veranderende omstandigheden zijn ook vaak oorzaak voor het stoppen van een project. Gewoon doen. En ja, een project stoppen lijkt op falen, maar is voor mij de grootste vakbekwaamheid die er bestaat. Hoe eerder je ziet dat het nergens toe laat, hoe beter dat is. Hier komen natuurlijk ego en macht kijken vanuit het opdrachtgeverschap. Misschien moeten we gewoon eens een aantal klip en klare situaties voorleggen dat het helemaal niet vreemd is om verandering te starten, maar hem vroegtijdig te stoppen, omdat het probleem reeds is opgelost. Desnoods integraal uitzenden op TV, zodat een ieder begrijpt dat dit geen schande is of fout, maar voortschrijdend inzicht. De boodschap is dan, kijk we zagen een concreet probleem, we hebben er tijdig op geacteerd, maar het probleem is uiteindelijk niet meer aanwezig en we stoppen alle activiteiten die dat probleem aan het beteugelen was. Ik zou echt niet weten welke burger, politici en/of vakgenoot daar tegen zou kunnen zijn. Wat je in feite doet is de drempelvrees weghalen om projecten te stoppen. Het liefst stop ik 8 van de 10 projecten (in verschillende stadia met diverse reeds opgeleverde (tussen)resultaten en maak er 2 juist heel goed af, dan dat ik er 10 laat doorgaan en vermoedelijk alle 10 tot niets leiden!
    – Binnen de projecten die daadwerkelijk afgemaakt moeten worden is wat mij betreft vakinhoudelijke kennis, vaardigheden en houding en gedrag een keiharde randvoorwaarde om ze te laten slagen. Alle stakeholders moeten daar aan voldoen. De overheid heeft (in tegenstelling tot het bedrijfsleven) een nogal instrumentele kijk op het toetsen en beoordelen van deze randvoorwaarden. Het idee dat een projectmanager die een training PrinceII heeft gevolgd beter is dan een projectmanager die dat niet heeft is voor mij niet relevant. Ik zou meer vertrouwen hebben in een projectmanager een aantal projecten met goed succes heeft afgerond en er een aantal niet goed heeft afgerond en mij kan vertellen wat hij geleerd heeft van die mislukte projecten.
    Mijn stelling is als je een club mensen hebt die er voor wil gaan en intrinsieke motivatie heeft om er wat van te maken, aanwezige of potentiele skills heeft om het aan te kunnen, al de reeds eerder genoemde (door andere reageerders) instrumenten om een compleet organisatie-landschap in te richten met alle tools en methodieken om een veranderorganisatie in te richten, de juiste gekozen worden. Waarbij bij de ene organisatie en watervalmethodiek prima is, kan bij de ander Agile misschien handiger zijn. Ik geloof in ieder geval niet in one-size-fits-all oplossingen, daar is een gemiddelde organisatie qua mensen en middelen gewoonweg de complex voor.

    Tot zover mijn bijdrage

  33. In de NOS app ‘Waarom kosten ICT-projecten vaak meer dan gedacht?’ van 14 juni, meent de heer Boonstra (hoogleraar informatiemanagement aan de Rijksuniversiteit Groningen) ook nog een duit in het zakje te moeten doen (met name over de overheid) met wat obligate uitspraken: http://nos.nl/l/2236444.

    Zijn observaties:
    (1) Pas nadat een project is gestart, bedenkt een organisatie dat er extra wensen zijn;
    (2) Men wil alles tegelijk.
    Volgens Boonstra is het beter om IT-systemen stapsgewijs te vernieuwen. Dan maak je steeds kleine stapjes en is het makkelijker om een realistisch offertebedrag op te stellen.

    Ad 1: Pas als een project is gestart, beginnen de gebruikers zich een beeld te vormen van hetgeen zal zijn gewenst. Logisch toch, het leven is toch al zo overvol.
    Oplossing: een architect is de regisseur van het beeldvormingsproces. En een volwassen architect is vaak niet aanwezig bij de ideevorming of krijgt onvoldoende tijd/ruimte zijn werk goed te doen.

    Ad 2: Bij sommige zaken moet alles tegelijk. Een nieuwe wet kan vaak niet salami-gewijze worden ingevoerd.
    Trouwens in een ideale wereld hebben we weinig grote projecten, want een groot project betekent vaak dat een groot aantal zaken moeten worden aangepakt. Oftewel de organisatie heeft een tijdje zitten slapen, en denkt ineens we moeten eens wat gaan doen. Zie bijna alle digitaliseringinitiatieven.
    Oplossing: een architect zorgt voor versiegewijze oplevering (ook vriendelijker voor de toekomstige gebruikers) en modularisatie (maakt projectmanagement overzichtelijker).

    Eindopmerking: Zorg dat de universiteit Groningen meer goede digitale architecten gaat afleveren.

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here