Nederlands OM erkent ict-problematiek na brandbrief over slechte omstandigheden

Het Nederlandse Openbaar Ministerie start een onderzoek naar de staat van zijn ict-systemen, nadat duizenden werknemers onlangs een brandbrief schreven over de problematiek bij de ict-infrastructuur van het overheidsorgaan. Er zijn nog geen concrete beloften gedaan.

In een openbaar statement schrijft het OM dat de zorgen van medewerkers over de staat van de ict-infrastructuur 'uitgebreid besproken' zijn met de hoofdofficieren. Zij gaan samen met het College van procureurs-generaal, ofwel het bestuur van het OM, onderzoeken of er iets aan de 'ict-problematiek' gedaan kan worden.

Volgens het OM willen medewerkers in de eerste plaats erkenning van het probleem. Het College gaat daarom alle OM-onderdelen langs 'om op de zorgen en vragen van medewerkers in te gaan'. In het statement erkent het OM de huidige ict-problematiek.

De overheidsdienst wijt dit aan eerdere bestuurlijke keuzes, waarmee de problematiek niet had kunnen worden voorkomen. Werknemers van het overheidsorgaan hadden het in de brandbrief ook over de nadelige gevolgen van 'jarenlange onvoldoende bestendige en consequente investeringen en eerdere bezuinigingen'. Het OM schrijft in het statement dat de financiële huishouding een bekend probleem is dat al langer speelt. Er wordt via verschillende routes naar meer financiering gevraagd, onder meer bij het kabinet en zelfs tijdens het huidige formatieproces.

Het OM reageert op de recente brandbrief die door grofweg de helft van zijn medewerkers werd ondertekend. Hierin staat dat medewerkers vrezen dat 'de staat van de rechtsstaat in het geding' zou kunnen komen, omdat er door een gebrekkige ict-infrastructuur mogelijk fouten gemaakt kunnen worden. Het is niet bekend wat er precies mis is met de systemen van het OM.

Door Yannick Spinner

Redacteur

04-12-2025 • 20:03

83

Reacties (83)

Sorteer op:

Weergave:

Beste Tweakers,

Is het niet eens tijd voor wat diepgravend onderzoek? Ik ben wel benieuwd hoe dit IT uit ziet.

Er zullen echt wel OM medewerkers hier zijn die je kan praten, wellicht zelfs een samenwerking met een NPO programma dat connecties heeft maar niks van IT snapt.

Dit moet echt monsterlijk slechte IT zijn als je door de regels leest.
Het OM heeft heel laat ingezet op digitalisering van dossiers, vanwege veiligheid. Advocaten liepen, nog niet zo lang geleden, daardoor met een kar met ordners de rechtszaal binnen. Onder die druk is men gaan digitaliseren. Het ontbrak destijds ook aan kennis. Men had beter defensie kunnen vragen hoe die het doen.
@peter123 het OM is al 20 jaar geleden begonnen met digitalisering. GPS, Geïntegreerd Proces Systeem, is destijds begonnen op het nog in brede kring operationele VMS, later OpenVMS van Digital in combinatie met Oracle. Iedere rechtbank kreeg al snel een eigen configuratie met een dikke VMS server en een groot storagearray van Digital (prijs/stuk Fl. 1.000.000).

Door de steeds wisselende eisen van het OM aan dit systeem kon de toenmalige beheer/ontwikkelorganisatie ICTRO (en haar voorgangers en opvolgers met andere namen, ook deel van Justitie) niet altijd aan die eisen voldoen. Functionaliteit bleef beperkt tot slechts één module: Wet Mulder, ipv alle modulen die de hele wetgeving zouden moeten dekken (want geïntegreerd).

Met de overname van Digital door Compaq werd dit OS door Compaq niet serieus genomen waarna Gartner dit OS als ‘legacy’ bestempelde, dus geen toekomstperspectief want aan een leverancier gebonden. Wat is overigens het verschil tussen een ‘legacy’ OS en een legacy DBMS als Oracle? Dus exit OpenVMS en entree HP-Unix. Sic!

Dus voorwaarts met HP-Unix en Oracle, exit de servers en storagearrays van Digital. Bakken met geld uitgegeven aan nieuwe hardware van HP, functionaliteit bleef beperkt tot Wet Mulder want men kreeg het systeem gewoon niet goed aan de praat omdat het bestond uit ca. 20 modulen van evenzovele leveranciers om aan alle eisen van het OM te voldoen want nieuwbouw voor deze functionaliteit zou teveel kosten en telang duren dus koop maar in met als resultaat een systeem van 20 modulen, versies etc. met bijbehorende interfaces om deze 20 modulen met elkaar te kunnen laten communiceren. Patchen bleek een nachtmerrie want iedere nieuwe versie betekende testen van het hele systeem. Ondertussen bleven de eisen van het OM op gebied van functionaliteit en performance zich opstapelen. Gevolgen: steeds maar bouwen en testen en nooit eens in productie en de opbouw van een hoeveelheid hardware waarvoor een middelgrote bank zich niet zou schamen.

De beheer/ontwikkelclub kreeg de schuld van uitblijvende resultaten terwijl deze steeds onder het bewind van altijd externe door het OM ingehuurde projectleiders naar de pijpen van het OM heeft gedanst. Gevolg was dat het OM een beheerclub wilde ‘die wel luisterde en meegaand was’, exit ICTRO, entree ATOS.

Een half jaar durend proces van kennisoverdracht volgde, ATOS medewerkers over de vloer bij ICTRO, na een half jaar de handtekening eronder dus alles overgedragen en akkoord, en nog eens een half jaar later kwamen er nog vragen van ATOS.

Maar de voornaamste domper voor het OM was dat ICTRO, als mede-Justitie-onderdeel, steeds meeboog met OM, alle best-practices van goed beheer, documenteren, ontwikkelen-testen-accepteren-productie enz. ten spijt, en ATOS boog niet flexibel mee want zij hadden wel afspraken over x patches per tijdsperiode, onderhoudswindows etc. en daarvan werd alleen afgeweken na veel praten + een dikke factuur. De gevolgen voor het OM waren een beheerorganisatie die minder meebewoog met de grillen van het OM (dat zou alleen maar goed kunnen zijn) en veel duurder was, dus de cultuur van opdrachtgever en beheerder sloten totaal niet meer op elkaar aan en veel verder dan die ene module Wet Mulder is men niet gekomen toen OM afscheid nam van ICTRO.

Ik besef dat mijn verhaal enigszins is afgedwaald van de opmerking van het OM te laat is begonnen met digitalisering maar het illustreert wel dat deze late digitalisering zeker niet waar is. Het OM heeft de ICT problemen geheel en al aan zichzelf te wijten wegens een groot gebrek aan visie op de ontwikkeling van ICT, telkens wisselende eisen aan functionaliteit en hard- en software, een steeds wisselend en altijd extern projectleiderschap en tenslotte de uitbesteding aan een externe beheer en ontwikkelorganisatie die qua cultuur niet paste bij het OM.

edit:Typo

[Reactie gewijzigd door schrikbeeld op 5 december 2025 20:37]

Wat een heerlijke gebruikersnaam erbij!

Kijk dit is precies wat ik bedoelde te zeggen dit soort info. Dank je!
Het was dus te laat omdat er telkens gewisseld is van systeem. Dat klinkt bekend en is een probleem overheidsbreed. Vaak worden door verkopers van zulke systemen dingen beloofd aan een directie die ze vervolgens niet kunnen waarmaken. Of heel veel meer geld kosten. De overheid wil de partij te vriend houden, omdat ze afhankelijk zijn geworden van hen.
Zover ik weet is het een combinatie van een IT partner die verouderde systemen gebruikt, gebrek aan interne IT kennis en hele oude applicaties die noodzakelijk zijn voor de rechtspraak
Is er ergens iets te vinden wat de problemen in de praktijk zijn? IT-problemen is een erg breed begrip. Gaat het om veroudere PC's, software die niet werkt, slechte netwerkinfrastructuur?
Dat staat in het verbetersplan, o wacht?! Welk plan (en erkenning)?
Zijn er ook takken binnen de overheid waar ICT geen puinhoop is? Voor mijn gevoel is het overal hopeloos verouderd, nodeloos ingewikkeld en is communicatie tussen de diverse systemen ook drama.
Niet echt de overheid maar de NS heeft zich getransformeerd tot een echte data en event driven IT organisatie (volgens mij, werk er niet maar ken er redelijk wat mensen.)

De app van de NS ligt er jaren voor op wat andere overheden überhaupt kunnen aanbieden.

De NS toont me het preciese aantal OV fietsen live in Groningen en update mijn app op de seconde bij vertraging.
En een treinkaartje is niet meer te betalen en de kwaliteit van het OV is verschrikkelijk. Lang leve de app.
Zijn er ook takken binnen de overheid waar ICT geen puinhoop is? Voor mijn gevoel is het overal hopeloos verouderd, nodeloos ingewikkeld en is communicatie tussen de diverse systemen ook drama.
Dat klopt want dat is wat wij met z'n allen graag wilden. De overheid moest kleiner worden. Nou dat is gelukt.
Werknemers van het overheidsorgaan hadden het in de brandbrief ook over de nadelige gevolgen van 'jarenlange onvoldoende bestendige en consequente investeringen en eerdere bezuinigingen'.
Jarenlang hebben we de overheid gedwongen om te bezuinigingen. Jarenlang hebben we de overheid gedwongen om te krimpen. Nu is de overheid een incompetent orgaan geworden die voor elke poep en scheet een consultant inhuurt om een adviesrapport uit te brengen. Vervolgens worden bedrijven ingehuurd om iets met dat rapport te doen. Totaal inefficiënt want nu moeten wij als belastingbetaler de winstmarges van die consultants en bedrijven betalen.

Mensen die roepen dat de overheid te groot is en moet krimpen, dit is het resultaat. Is dit beter dan een overheid die de Deltawerken, Flevoland en de Afsluitdijk voortbracht?
De overheid is de afgelopen 6 jaar met 22% ambtenaren gegroeid.

De overheidsuitgaven als percentage van ons BBP zijn licht gestegen, in ieder geval niet gedaald.

Laten we het een beetje bij de feiten houden.
Dat er groei is betekent niet dat die groei proportioneel is, Nederland(s bestuur) wordt steeds drukker en ingewikkelder, dus zal er relatief meer moeten worden uitgegeven. Gezien de neoliberalen het al een decennium+ aan de macht zijn en de enorme puinhopen die te vinden zijn in o.a. de jeugdzorg, Ter Apel, politie (capaciteitsproblemen), de gerechtelijke macht (ook capaciteitsproblemen) en de de overheids-ICT denk ik niet dat dit is gebeurd. Er is functioneel bezuinigd.
Als aanvulling: Consultants zijn geen ambtenaren, want niet in (loon)tdiens van de overheid. Die 22% is dus alleen het eigen personeel, niet de extern ingehuurde profesioneels.
Lokale overheden hebben het op zich aardig voor elkaar.
Kan niet voor allemaal spreken natuurlijk, alleen voor mezelf :)
Ik werk veel bij lokale overheden als software ontwikkelaar. Naar mijn mening is dat tussen de 80-90% helemaal goed gaat en bijgehouden wordt. Dat vind uiteraard niemand interessant, want er valt niets over te klagen.
Die 20-10% is wel een ander verhaal en zijn vaak de complexe zaken waar maar weinig mensen aan zich willen branden. Wetgeving verandert en er staan te veel managers aan het roer.

Budget is er amper... Want iedereen weet dat de burger het moet ophoesten. Dat is, naar mijn ervaring, heel anders dan aandeelhouders met diepe zakken.

[Reactie gewijzigd door Standeman op 4 december 2025 23:01]

Dat zullen de instanties zijn waar je niets van hoort.
Zolang alle takken van de overheid stelselmatig kapotbezuinigd en -gereorganiseerd worden zal het nergens state-of-the-art zijn of worden.

Wanneer je echter beseft hoeveel van de samenleving en dus ook de overheid drijft op ICT en hoe groot en veelzijdig de overheid is, zie je dat het aantal ICT problemen waar je wat van hoort relatief klein is.
Voor de gepamperde ICT-er, die met zijn leasebak uurtje-factuurtje voor komt rijden om die gasten van de overheid even te laten zien hoe het moet is het welllicht een puinhoop. (En voor de gebruikers lijkt het daar soms ook op.) Maar ondertussen zijn er intern gedreven deskundigen dag in dag uit bezig om het maximale te persen uit een te klein budget en vaak verouderde apparatuur en software om met één klein wonder tegelijk de organisatie draaiende te houden.
Er moet toch een overheidsinstantie zijn die het wel op orde heeft en kan helpen met informatie hoe die het hebben gedaan en hoe je dat zo snel mogelijk door de ambtelijke molen krijgt zonder eindeloze vergaderingen, legers interim personeel en miljoenen kostende mislukte projecten. (dit is mijn huidige beeld van de overheid en ict).
Je hoeft toch niet steeds het wiel opnieuw uit te vinden, en iedereen er iets van te laten vinden?
Helaas.

Elke ministerie heeft "unieke eisen en wensen" waardoor hergebruik niet voorkomt. Plus, een ministerie wil niet zijn budget inzetten en dat een andere daar ook kosteloos van profiteert. Snel en goed kan wel, maar vaak alleen voor kleine projecten. Zodra het groter wordt, gaat het de Europese aanbestedings-route in. En dan start die molen.

En is die applicatie eenmaal opgeleverd, dan komt het volgende probleem. Want het ontwikkelbudget is op, maar het systeem moet nu met een (flink) kleiner budget draaien en onderhouden worden. Lifecycle management wordt namelijk ook onvoldoende rekening mee gehouden. Alle kennishouders gaan naar het volgende project en de opvolgers zijn ook na een paar jaar weer weg. Degene die de boel draaiende houden moeten het dus met beperkte mogelijkheden doen. Dus het is logisch dat hun systemen niet op hun best zijn.
Zolang IT gezien wordt als kostenpost en geen goede planning voor investeringen wordt er meer en meer technische schuld opgebouwd.
Ik vraag mij vooral af of dit niet beter centraal voor iedereen geregeld kan worden. Alle IT budgetten afpakken, op een hoop gooien en aan centrale systemen werken die aan alle eisen voldoen. (volgens mij kan dit momenteel niet, want alle ministeries moeten gescheiden blijven oid)

Niet dat er één perfecte oplossing bestaat.
Het probleem daarmee is dat veel applicaties zijn gekoppeld aan het uitvoeren van wettenlijke taken. Hoe bepaal je dat (een applicatie voor) zo'n taak genoeg budget krijgt? Dat kun je niet vanuit IT regelen, daar moet echt het ministerie een keus in maken.

Wel kun je veel IT zaken centraal uitvoeren. En dat wordt ook gedaan (bv DICTU). Maar dat betekent niet men daardoor ook grip heeft op hun IT.
Het is ook lastig een meerjaren planning te maken als het kabinet elk jaar valt.
Daarom zou de Rijksoverheid dit ook gewoon op zich moeten nemen.

Dat Ministeries unieke eisen voor applicaties en zakelijke logica hebben (business logic, lol) daar kan ik nog wel inkomen. Al denk ik stiekem dat die veel minder uniek zijn dan ze graag willen doen voorkomen.

Maar dat is iets anders dan die apps draaien op een infrastructuur uit 2001.

De Rijksoverheid zou die infra moeten leveren, net als nu AWS. De Rijksoverheid zou een RijksDigiStaat moeten hebben waar alle andere overheden hun ontwikkelde apps kunnen aanmelden in de nationale Git repo.

Publiek geld = publieke code.

Dan kunnen andere overheden niet hele apps kopieren maar stukken code forken, zelf patchen of uitbreiden.

Maar goed dit zou moeten beginnen met één ambtenaar in de top 350 van de hele Rijksoverheid die überhaupt weet wat Git is en waarom je het zou willen.

We moeten van heel erg ver komen.

In ander nieuws: zelfs Duitsland heeft inmiddels een Ministerie van Digitale Zaken.
Ik zou denken dat je dan misschien de software niet over kan nemen, maar wel het proces, de partners waarmee gewerkt is, enkele bouwstenen en principes, de hoofdlijnen van de architectuur enzovoorts.

Maar waarschijnlijk is het bij de managementlaag een totaal gebrek aan kennis 🥲
Beetje een open deur maar daarom zou een ministerie van digitale zaken wel goed zijn. Die werken met een heel andere insteek en kunnen zaken auditen, i.p.v. dat er jaren later lijken uit de kast vallen.
Ik zou niet echt weten welke inmiddels. Ik denk ook niet dat het toeval is dat men alles naar MS 365 tjoept, omdat het intern zo "slecht" werkt allemaal dat alternatieven bedenken al helemaal teveel gedoe is.
Of drijft het onderzoek ze naar een IT dienstverlener die het wel goed snel en relatief goed kan oplossen om dan later in handen komt van een ander land? Zie ook de Logius casus
Bron? Ik ken de casus niet.
nieuws: Nederlandse cloudfirma Solvinity komt in handen van Amerikaans ict-bedrijf

Solvinity host vziw praktisch alles voor Logius/DigiD; en veel maatwerk.
Solvinity is ook de belangrijkste IT-leverancier van het ministerie van Justitie en Veiligheid en dus ook van het OM.
Yes en vast nog van een boel meer overheid.

Straks valt al die data onder de CLOUD Act
Bij Rijkswaterstaat is de software ook dramatisch verouderd. Diep triest hoe vaak de applicaties crashen in een 24/7 operationele omgeving.

En als er eindelijk eens wat nieuwers komt dan is het volledig ontworpen door de ontwikkelaar zonder ook maar enig advies of luisterend oor bij de eindgebruiker, resulterend in een uitermate slecht en frustrerend werkend systeem.
Ik vind leeftijd van software geen zinnig argument: Goedgeschreven software van 25 jaar oud kan nog steeds van nut zijn. Het gaat om de kwaliteit en flexibiliteit van software, want de omgeving waarin software gebruikt wordt verandert wel, maar te veel meebewegen met stand van de wind zorgt er juist voor dat je voortdurend aan het rennen bent en nooit de tijd hebt om zaken even grondig op te lossen. Je moet softwarekeuzes maken die de nodig jaren meekunnen. Dan zit je inderdaad lange tijd aan die software vast, maar als je goed gekozen hebt, is dat geen enkel probleem, en kun je die software perfectioneren.
Sorry maar dit is echt niet meer van deze tijd.

25 jaar oude software is sowieso EOL, draait op een EOL OS, heeft een sleur aan dependencies die ook niet geupdate worden en nu moet de overheid 2 menen inhuren voor €300 per uur om de app draaiende te houden, updaten kan al 10 jaar niet meer.

Bij bedrijven als Google wordt alle software herschreven binnen 5 tot 7 jaar. Ook al komt er 0 functionaliteit bij je herschrijft het in een moderne taal, met moderne standaarden, met geupdate dependencies en op een nieuw LTS OS.

Jouw mindset, met alle respect, is precies hoe we in deze situatie terecht zijn gekomen.
Wat een onzin, de overheid is geen Netflix of Google, wat al die "silicon valley guru consultants" je ook doen denken. Dus nee, alsjeblieft geen microservice container-based Kubernetes event-driven autoscaling architectuur naar binnen fietsen door consultant X en implementatiepartner Y, als het geen daadwerkelijk probleem oplost.

Oude software hoeft helemaal geen probleem te zijn, zoals hierboven al terecht aangekaart. Kijk bv maar eens op welke architectuur en software vliegtuigen en energie-centrales draaien.

Het echte probleem is dat de (door)ontwikkeling van de software is uitbesteed aan externe partijen, die dat weer verder uitbesteden aan clubs die puur op certificering draaien. Met andere woorden: er is geen interne kennis en expertise meer, en langzaam maar zeker worden de applicaties een grote houtje touwtje instabiele ball of mud. Plus dat het ook nog eens reteduur is om al die externe uurtarieven af te tikken.

De oplossing is dus om de boel weer naar binnen te halen, en met echte ervaren en getalenteerde architecten en engineers te gaan werken om de boel te stabiliseren en te verbeteren. Daarbij is het wel essentieel dat regel en wetgeving gaat versimpelen, omdat de logica en regels simpelweg niet te programmeren zijn, de complexiteit is echt doorgeslagen.

Klinkt simpel, is het niet, het is ook geen technisch probleem, iedereen kan code schrijven (of laten genereren door een LLM ahum) maar een goede code bij een goed ontwerp met de juiste Q&A processen, dat is andere koek. Gelukkig zijn die mensen er wel, maar dan moet je ze wel de juiste arbeidsvoorwaarden en uitdagingen aanbieden. En niet in een of ander politiek wespennest gooien, want daar zit niemand met een echte trackrecord op te wachten.
Ik werk bij een overheidsbedrijf (in loondienst ;) ) en wij zijn net bezig om bijna alle apps naar Kubernetes over te zetten. Grappig dat je die net noemt als een kut idee.

Automatisch healing, auto update, auto minor version patching, auto scaling, hardening, runtime security, infra as code, rolling updates.

We komen van een ouderwets landschap met honderden VMs die allemaal één app draaiden die alleen 's nachts down mag want anders valt de app ernaast om.

Vier weken terug hebben we het hele landschap van ons bedrijf verwijderd. Kubernetes bracht het automatisch in minuutje weer terug op. Alles.

Op het oude landschap zouden we net zo lang down zijn als het OM laatst als zo een incident plaats vond.

Maar je hebt gelijk hoor: we hadden ook gewoon de mensen in India kunnen vragen het nog 25 jaar draaiende te houden op Windows2012 Server met handmatige updates van het OS.

Dan stond er over 10 jaar een mooi artikel op Tweakers.net precies zoals dit.

[Reactie gewijzigd door ApexAlpha op 5 december 2025 09:22]

Ik zeg niet dat Kubernetes kut is, ik zeg dat het een probleem moet oplossen. Cargo culting "omdat het hip is" gaat je echt niet verder helpen. In jullie geval lijkt het een goede match te zijn, al zie ik wel in de praktijk een aantal organisaties weer wegbewegen van K8s na een aantal jaren, omdat de hogere complexiteit en abstractie geen toegevoegde waarde bracht, maar juist meer problemen (wie heeft er genoeg k8s expertise in-house om de gateway api, ingresses, helm charts, HPA etc te debuggen als het k8s cluster gek begint te doen?).

NB Je VM verhaal beschrijft een dependency-issue (de ene app valt om als de andere down gaat), dat is niet iets dat automagisch door k8s (of welk systeem dan ook) wordt opgelost.
De Gateway API / Ingress is gewoon de moderne variant van je firewall die je hebt.

Dus ik zou het ook kunnen omdraaien: wie heeft nog genoeg expertise in huis om een oude database app op Solaris te kunnen onderhouden dat al draait op een Oracle rek in de kelder sinds 1997?

En de bijbehorende firewall, Pearl en Bash scripts, IPsec tunnel, telnet verbindingen en handmatige sharding van tabellen?

[Reactie gewijzigd door ApexAlpha op 5 december 2025 10:01]

LOL dat is ook waar (een vriend van me heeft nog best lang goed geld verdiend met Cobol applicaties onderhouden en moderniseren). Grappig genoeg heeft de bedrijf waar ik voor werk (cloud-native CICD) ook nog support voor IBM System/390 mainframes.

Ik reageer misschien wat fel, omdat ik iets te vaak complete rewrites heb gezien naar honderden(!) microservices in containers op k8s, met allemaal ellende en budget/planning overruns, puur omdat iemand ergens een boek had gelezen of een training had gedaan. Als je dan vroeg "welk probleem lossen we hiermee precies op?" kwam er vaak geen of een onzinnig antwoord, en bleek het meer te zijn omdat iemand die nieuwe shiny tech heel interessant en spannend vond.

In heel veel gevallen kun je ook prima (delen van) je applicatie herschrijven als een (Go/Rust) monolith en op een VM draaien, gewoon lekker simpel. Als je weet welk probleem je oplost.

Anyway, mooi dat het goed voor jullie werkt!

[Reactie gewijzigd door olafmol op 5 december 2025 10:09]

Software uit de jaren 80 en 90 heeft vrijwel geen afhankelijkeden behalve een aantal externe services waarmee het systeem moet communiceren. Je had simpelweg gewoon minder libraries waar je gebruik van kon maken.

Vroeger schreef men software eenmalig en draaide het voor eeuwig. De scope van die projecten was veel kleiner en software werd al helemaal niet flexibel gemaakt.

Het is juist jouw mentaliteit welke vaak voor problemen zorgt. Een werkend oud systeem wordt vervangen door een nieuw half werkend systeem, want een manager had iets op het internet of tijdschrift gelezen.

30 jaar geleden bestond er helemaal niets iets als een supply chain attack vector. Juist die oude mentaliteit, kleine applicaties zijn weer helemaal hot, alleen hebben we ze een nieuwe neem geven: micro services. Geen 101 wensen applicaties meer, maar juist terug in de kern.

Je klaagt over inhuur van dure professionals, maar hebt geen problemen om een compleet team in te huren om een complete applicatie te herschrijven zonder business added value?
Is het probleem niet juist dat je bestaande oplossingen niet zomaar gewoon kan laten staan? Je kan wel een werkende oplossing hebben voor je huidige situatie maar de wereld staat niet stil, zeker niet binnen het overheidsapparaat waar de regels regelmatig veranderen. Of wat dacht je van wanneer er iets nieuws in een systeem gebouwd moet worden, ook daar blijkt vaak dat het "nieuwe" niet zo gemakkelijk te koppelen is met het "oude".

Dan heb je natuurlijk nog de technische kwetsbaarheden die je vaak hebt in verouderde systemen, er is vast een deel wat je volledig in-house kan doen maar juist de overheid zal ook veel partijen hebben waarmee data uitgewisseld zal worden. Ik weet het dus ook niet zo zeker of software van vroeger "eeuwig" draait, dit zie je ook niet echt terug in het bedrijfsleven want daar ook wordt oude software eruit gefaseerd.
Je klaagt over inhuur van dure professionals, maar hebt geen problemen om een compleet team in te huren om een complete applicatie te herschrijven zonder business added value?
Het up-to-date houden van je IT landschap IS business value.

Prachtig voorbeeld hoe jij het up-to-date houden van IT omschrijft als een veel te dure kostenpost die niks oplevert. Dat is inderdaad precies de foute mindset die ook bij de overheid leeft.

[Reactie gewijzigd door ApexAlpha op 5 december 2025 09:48]

Het is juist jouw mentaliteit welke vaak voor problemen zorgt. Een werkend oud systeem wordt vervangen door een nieuw half werkend systeem, want een manager had iets op het internet of tijdschrift gelezen.
Het grootste probleem is juist het níet vervangen van die oude systemen....

Alle systemen zijn interconnected. Toen ook al, nu nog meer. Maar als het aanpalende systeem verandert, verandert ook de interface. En in de meeste gevallen kan dat oude systeem dat niet aan dus bouwen we er iets tussenin wat er voor zorgt dat het nieuwe systeem qua interface omgevormd wordt tot het oude systeem. Uiteraard voegen we dat toe aan het oude systeem. En 3 jaar later gebeurt hetzelfde en bouwen we er nog een puistje op. En geen van allen zijn die perfect. Het oude systeem was dat al niet maar de ontwikkelaars van toen kende de uitzonderingen nog. De bouwers van die puistjes niet en dus faalt het vaker.

En nu zitten we met software uit de jaren 80/90 met een puistje van 2005 waar weer een puistje op gebouwd is in 2008 enzovoorts enzovoorts en niemand die nog maar het flauwste idee heeft hoe dat allemaal werkt of samenwerkt......
Als je dat schrijft heb je mijn boodschap niet begrepen. Als jij 25 jaar oude software op een oud besturingssysteem moet draaien, dan heb je bij het ontwerp of aanschaf van die software je werk niet goed gedaan. Software op duurzaamheid uitkiezen betekent niet dat je nooit iets verandert: De software hercompileren voor een nieuw besturingssysteem is bijvoorbeeld prima in te calculeren.

Maar juist als jij met het tempo van een Google mee moet rennen, en elke 5 tot 7 jaar totaal nieuwe software nodig hebt, dan ben je voortdurend aan het rennen en heb je geen tijd om je software op je bedrijfsprocessen te optimaliseren. Wat Rijkswaterstaat of het OM nu doet, is niet fundamenteel anders dan 25 jaar geleden. Als jij 25 jaar kunt doorbouwen, dan bereik je het punt van een geöliede machine, als jij in die periode 4 keer vanaf nul begonnen bent, heb je voortdurend niet-optimale software.
Maar we zitten nu toch in een situatie waar het OM 25 jaar heeft doorgebouwd op de oude infra en software, precies zoals jij zegt.

Het resultaat is de brandbrief van de medewerkers.

[Reactie gewijzigd door ApexAlpha op 5 december 2025 10:04]

De berichtgeving geeft niet de indruk dat ze 25 jaar hebben doorgebouwd, maar aan het rennen zijn en niet hard genoeg kunnen rennen. Zo is aanhoudende "Outlook-problematiek" een typisch probleem van Microsoft bij proberen te benen. E-mail is 50 jaar oud, ouder dan het internet, wie een goed e-mailsysteem heeft, hoeft dat niet iedere paar jaar te veranderen, daar bovenop gaat een goed geautomatiseerd systeem ook veel automatisering van e-mails: Al je e-mails met de hand tikken is inefficiënt.
Dat komt omdat ze een nieuw systeem bouwen die het oude systeem vervangt, daarom wordt er niets aan het oude systeem gedaan. Probleem is echter dat de release vorig jaar zou zijn. En ook een release volgend jaar is onzeker. En ondertussen wordt er niets gedaan aan het huidige productiesysteem.

In plaats van een continue ontwikkeling, is het budget nul, totdat er een probleem is. Dan moet er plotseling iemand met kennis gezocht worden die een aanpassing kan doen.
nee, het is bekend dat dit ook bij RWS zo is. Boven omschreven probleem is een overheids probleem wat verder gaat dan het OM. het is bij de belastingdienst, OM, RWS en vele andere overheidsorganisaties.
Het is een algemeen gegeven dat overheidsdiensten vaak niet uit de voeten kunnen met commerciële standaardpakketten vanwege allerlei ingewikkelde regelgeving. Het beste voorbeeld daarvan is wel de Belastingdienst maar zo zijn er nog wel meer. De gewone kantoorautomatisering met mail, tekstverwerker is meestal niet het probleem.
Die tekstverwerker moet dan wel weer kunnen werken met bepaalde (archiverings)standaarden, en documentmanagementsystemen. Dus zo simpel is dat nog niet. Laat staan, het moet ook nog werken in een Citrix omgeving.
Ook die standaardsoftware gaat niet zonder problemen. In een terminal omgeving - wat de overheid vaak heeft - is het vaak traag. Sharepoint is ook een "standaardpakket", maar dat ging bij de OM ook niet goed.
ik heb als senior applicatie manager gewerkt bij een overheidsorganisatie, probleem ligt vaak ergens anders en laatste jaren veel inhuur van onkundige. iemand die een IT rol heeft heeft vaak de achtergrond niet. verder budget, kennis en het aansluiten van diverse applicaties aan elkaar. desinteresse vond ik ook een ding. wet en regelgeving is vaak minder een probleem. maar we kennen het probleem win10, office en telemetry probleem nog wel.
Boven omschreven probleem is een overheids probleem wat verder gaat dan het OM.


wat is hier fout, moet dat zijn. Van iemand die academisch opgeleid is mag je een betere taalbeheersing verwachten.

Sayonara.
niet ieder persoon met een academische achtergrond spreekt nederlands of is autochtoon. beetje intolerant.

uit ervaring, niet iedere academische opgeleide IT manager heeft een IT achtergrond bij de overheid.
En vele tientallen miljioenen verder.
toch wel typisch, algehele personeel bestand zegt "onze systemen functioneren niet en zijn slecht beveiligd" en het management gaat een onderzoek uitvoeren....Wel makkelijk om de verantwoordelijk af te schuiven richting een bureau, ze geven volgens mij nog net niet het personeel te schuld.

[Reactie gewijzigd door Richo999 op 4 december 2025 21:42]

Dan heb ik toch de indruk dat de Belgische ambtenarij hun IT iets beter op punt heeft.

Op federaal niveau wordt veel vanuit de FOD BOSA / Beleid en Ondersteuning gestuurd / gecoördineerd, wat wellicht helpt.

Een tak als Justitie daarentegen doet er een jaar over om budget vrij te krijgen om een lamp te laten vervangen. Ik kan mij wel voorstellen dat de IT daar een serieuze achterstand kent.
Er zijn in België ook miskleunen te vinden, maar daar hangt erg veel af van de topambtenaar in functie. Wordt een departement geleid door een bestuurder met wat visie en ambitie, is er erg veel mogelijk en wordt er hervormd waar nodig, tegen het tandengeknars van de vakbonden in. Gaat het echter om een politieke benoeming aan de top, ongehinderd door expertise maar met een agenda vooral gericht op vriendjes maken, dan komt er direct veel zand in de machine en is het vaak wachten op diens pensioen voordat echte vooruitgang mogelijk is.

De Belgische justitie is alvast de traagste om te hervormen. Ze is ook veruit de slechtste betaler, zodat veel leveranciers vandaag simpel weigeren om opdrachten voor hen uit te voeren of om zelfs maar deel te nemen aan de aanbestedingen. Een en ander komt door enorme druk vanuit bepaalde kringen van de advocatuur, die geen baat hebben bij een snellere rechtsgang, want dan kunnen ze minder uren factureren, en dus voor elk project van stroomlijning of digitalisering de hakken in het zand zet.
Meer geld is niet per se de oplossing. Er moeten een paar management en sales lagen uit. Aanbestedingen moeten veel kritischer worden beoordeeld.
Het grootste probleem met aanbestedingsregels is, is dat je de uiteindelijke scope moet aanbesteden. Dat betekent dus dat je nu moet kunnen definieren wat je over 10 of 15 jaar nodig hebt. Het zou veel mooier zijn als je meer (vreselijk woord alert) agile manier van werken kunt aanbesteden, zonder dat je de precieze uitkomt van over 10 jaar weet. Maar dat is lastig met de regels en misscihen nog wel lastiger om een solide contract op te stellen.

Op dit item kan niet meer gereageerd worden.