Rekenkamer hekelt sterke veroudering it-systemen Belastingdienst

De Rekenkamer heeft grote veroudering en achterstallig onderhoud van de it-systemen van de Belastingdienst geconstateerd. Bovendien zijn de systemen onderling sterk afhankelijk. De Rekenkamer vreest 'ernstige verstoring van de massale processen'.

De Rekenkamer heeft in zijn Verantwoordingsonderzoek 2014 voor het ministerie van Financiën sterke kritiek op de it-infrastructuur van de Belastingdienst. Het gaat om een groot aantal systemen die in veel gevallen sterk verouderd zijn, maar tegelijk essentieel voor het functioneren van de Belastingdienst. De oudste van die applicaties is 37 jaar oud, bevestigt de Rekenkamer aan Tweakers.

"Deze ouderdom van systemen zorgt voor problemen in het it-landschap, omdat er geen overzicht van systemen, platforms, versies en programmeertalen is", schrijft de organisatie. De Rekenkamer sluit niet uit dat er ernstige verstoringen in de massale processen van de Belastingdienst komen als de werkzaamheden veranderen als gevolg van het doorvoeren van toekomstige wetswijzigingen.

De organisatie noemt het verder 'bewonderenswaardig' dat het de Belastingdienst tot nu toe gelukt is om problemen snel op te lossen en de gevolgen voor burgers en bedrijven beperkt te houden. Er zou sprake zijn van een 'cultuur van brandjes blussen op de werkvloer'. "Er ligt een heel grote opgave voor de Belastingdienst om snel te moderniseren", stelt Kees Vendrik van het college van de Algemene Rekenkamer.

De Belastingdienst kondigde dinsdag een grote reorganisatie aan waarbij duizenden banen verdwijnen als gevolg van verregaande automatisering.

Reacties (192)

[jwal]

We zijn weer lekker aan het meedenken met onze overheid zie ik in de reacties , maar ze zijn ook niet helemaal gek.
Voor de mensen die gemakkelijk even de conclusies willen lezen, heb ik ze even gekopieerd uit de publicatie.

De bevindingen van de Algemene Rekenkamer:
De Belastingdienst heeft een groot aantal IT-systemen in gebruik die veelal sterk verouderd zijn en die essentieel zijn voor het functioneren van de Belastingdienst. Deze ouderdom van systemen zorgt voor problemen in het IT-landschap, omdat:

• er geen overzicht van systemen, platforms, versies en programmeertalen is;
• deze systemen sinds de introductie zijn aangepast aan wetswijzigingen, zonder dat deze wijzigingen systematisch zijn bijgehouden. Hierdoor ontbreekt overzicht hierop;
• veel systemen onderling van elkaar afhankelijk zijn. Het overzicht van de systemen en de onderlinge afhankelijkheden zijn slecht gedocumenteerd. Daarnaast is de kennis hierover slechts aanwezig bij medewerkers die dicht tegen hun pensioendatum aanzitten;
• de legacy problematiek groter is dan bij het opstellen van de Brede Agenda is ingeschat.

De aanbevelingen van de Algemene Rekenkamer:
Wij bevelen de staatssecretaris van Financiën aan om de legacy problematiek in kaart te brengen inclusief een afbouwplan voor de uitfasering van te vervangen IT-systemen. Zorg voor voldoende tijd en ruimte bij de introductie van nieuwe belastingmaatregelen en probeer deze maatregelen zo vorm te geven dat zij het stelsel vereenvoudigen; dit zal ook leiden tot een complexiteitsreductie van de IT-systemen van de Belastingdienst op lange termijn.

Als de Belastingdienst aan het eind 2015 ons inzicht kan geven in dat integrale plan en de eerste stappen tot uitvoering daadwerkelijk zijn gezet, is dat voor ons een signaal om het predicaat ‘ernstige’ te kunnen laten vervallen. Vervolgens is het integraal uitvoeren van het plan en het invulling geven aan alle verbeteringen het signaal om de ‘onvolkomenheid’ te laten vervallen. De sleutel ligt dus bij het daadwerkelijk uitvoeren van het plan.

De reactie van het Ministerie van Financien
De minister van Financiën stelt, dat de legacy-problematiek binnen de Belastingdienst volop aandacht heeft. In de Brede agenda is de aanpak op hoofdlijnen geschetst. Vervolgens is hieraan in de ICT Ontwikkelagenda de eerste uitwerking gegeven. Naast het verminderen van complexiteit van de regelgeving wordt binnen de Brede Agenda en de ontwikkelaanpak op twee manieren de legacy aangepakt:

• Het programma robuuste processen. De inzet is om tot de ‘slankere’ transactiesystemen te komen waardoor uiteindelijk minder legacy ontstaat.
• Het programma Rationalisatie. Het achterstallig onderhoud op de ICT-systemen is de reden geweest om het programma rationalisatie op te starten. Dit programma heeft tot doel om de beheer- en onderhoudslast de komende drie jaar terug te brengen.

Voor de aanpak van de legacy-problematiek geldt dat een benadering die de suggestie wekt dat op korte termijn legacy vervangen gaat worden, niet werkt en niet nodig is, aldus de minister. Niet werkt omdat een dergelijke aanpak te groot is en niet overzien kan worden. Niet nodig omdat een deel van de legacy (immers bestaande systemen) ofwel goed functioneert ofwel door de potentie van nieuwe datagestuurde benaderingen niet meer op de klassieke wijze vervangen gaat worden.
(Volledige reactie:)
http://verantwoordingsond...0van%20Financien%20IX.pdf

ICT Ontwikkelagenda 2014 (wordt aan gerefereerd in de reactie van het ministerie)
http://www.rijksoverheid....a/ict-ontwikkelagenda.pdf

Nawoord Algemene Rekenkamer
Wij vinden het een goede zaak, dat de legacy-problematiek volop de aandacht heeft van de Belastingdienst. Wij vinden het van groot belang dat bij het oplossen van de problemen de balans bewaakt wordt tussen modernisering enerzijds en beheer en onderhoud van bestaande systemen anderzijds.

De minister van Financiën refereert in zijn reactie aan de potentie van “nieuwe datagestuurde benaderingen”. Hierdoor is het volgens de minister niet nodig om een deel van de legacy te vervangen. De minister geeft in zijn reactie echter ook aan, dat het proces van uitvoering van de maatregelen uit de Brede Agenda meer jaren in beslag zal nemen. Tot het moment dat deze veranderingen gerealiseerd zijn, zal de druk van de legacy op de processen en resultaten van de Belastingdienst verder toenemen. Het handelingsperspectief van de Staten-Generaal wordt als gevolg daarvan beperkt: het (tijdig) doorvoeren van beleidswijzigingen wordt in toenemende mate bemoeilijkt door de IT-legacy van de Belastingdienst. De Belastingdienst zal daarom nu al passende maatregelen moeten nemen. Een afbouwplan is daarbij in onze ogen onontbeerlijk.

Wij zullen de verhouding tussen de nieuwe datagestuurde-benaderingen en de aanpak van de ‘legacy’ problematiek in ons onderzoek over 2015 nauwgezet volgen, net als de andere toezeggingen van de minister. In het najaar 2015 zullen wij nagaan of de minister onze aanbevelingen heeft opgevolgd om vast te stellen of wij deze onvolkomenheid niet langer het predicaat ‘ernstig’ geven. Wij zullen daarbij beoordelen of er sprake is van een integraal plan en daadwerkelijk voldoende eerste stappen van de uitvoering daarvan zijn gezet.

De Staten-Generaal moeten op hun beurt daarnaast én het terugdringen van de kwetsbaarheid van de Belastingdienst controleren en met de situatie rekening houden bij het dimensioneren van het nieuwe belastingplan.

[Hedva]

Daarnaast is de kennis hierover slechts aanwezig bij medewerkers die dicht tegen hun pensioendatum aanzitten;

Ik zie een stel ouwe kerels om een tafel voor me, die zichzelf belangrijk houden.

Maare, zelf denk ik dat ze misschien nog even kunnen wachten tot die nieuwe belastingwetten erdoor zijn. Anders kan je straks weer alles aanpassen. Over 3 jaar ofzo, dan kunnen ze vieren dat het ene systeem 40 jaar oud is

[Dual Infinity]

Ik zie een stel ouwe kerels om een tafel voor me, die zichzelf belangrijk houden.

Nee.

Dit is een klassiek probleem dat in de managementlaag onstaat. Een van de fasen in de ontwikkeling van software die niets lijkt op te leveren is die van het (laten) documenteren van de software en dan met name de eigenaardigheidjes ervan. Voor dingen die geen geld lijken op te leveren wordt simpelweg geen tijd vrijgemaakt omdat de mensen die die beslissingen nemen vaak kortzichtig opereren en het belang (en de toekomstige kostenbesparing) van dergelijke zaken niet voldoende inzien.

Er zijn zo veel bedrijven waarbij enorm veel kennis opgesloten zit in de hoofden van slechts een paar developers. Developers die die kennis graag zouden willen delen en gestructureerd opschrijven, al was het maar om een goed overzicht te krijgen en te hebben van de zwaktes en grote verbeterpunten van de codebase. Als die developers pleitos gaan om de een of andere reden, en HR nieuwe devs vindt, dan worden die vervolgens in het diepe van de slecht gedocumenteerde codebase gegooid met een tekst als: 'ja, er zijn een paar kleine bugjes die we graag opgelost willen hebben'. Genoemde devs besteden ieders volgens weken (meer dan het documenteren origineel gekost zou hebben) aan beurtelings 'WTF, hoezo?' en 'Wat een onbegrijpelijke bende.' te roepen, terwijl ze door de codebase spitten.

Actuele, goede documentatie en specificatie is belangrijk voor de kwaliteit van een systeem (overzicht) en kostenbesparend op de langere termijn (Write Once, Read Many).

[kwaazaar]

"(Write Once, Read Many)" - Deze heb ik nog nooit gehoord in deze context.

Het argument dat de documentatie niet op orde is, hoor ik heel vaak. In veel gevallen echter als excuus van ontwikkelaars, omdat ze de code niet begrijpen, terwijl collega ontwikkelaars er geen moeite mee hebben.

Daarnaast kan documentatie tegen je werken:
- Incomplete documentatie kan de indruk wekken dat de lezer het systeem volledig overziet, terwijl hij feitelijk nog delen mist, misschien zelfs de delen die er echt toe doen.
- Foute/achterhaalde documentatie kan je op het verkeerde been zetten, waardoor het averechts werkt: het helpt je niet, maar veroorzaakt verwarring, foutief ontwerp van aanpassingen en uiteindelijk veel tijdverlies. Vaak kun je dan beter de gebruikershandleiding lezen, die geeft vaak nog het beste beeld van het systeem én is redelijk up to date.

Tegelijkertijd is het ook te makkelijk om te stellen dat je het wel zonder documentatie kunt; tuurlijk, de code als documentatie klopt ALTIJD met de werkelijkheid, maar die is niet altijd even goed te doorgronden. Code-commentaar is daarbij ESSENTIEEL en in soms nog belangrijker dan systeemdocumentatie. Ook zijn er geautomatiseerde (unit) tests die functionele testcases uitvoeren. Ook die vormen een soort documentatie.

Ik wil niet zeggen dat documentatie onnodig is, maar klassieke systeemdocumentatie/ontwerpen zijn zeker niet heilig.

[Reactie gewijzigd door kwaazaar op 23 juli 2024 06:17]

[Dual Infinity]

"(Write Once, Read Many)" - Deze heb ik nog nooit gehoord in deze context.

Bij deze ;-)
Ik vind em wel lekker beknopt de lange-termijn tijdsbesparing vatten.
Het geldt ook in discussies over de verbosity van code en dingen zoals lange versus korte variabelenamen. De tijd die het kost om je code leesbaar en begrijpelijk te maken verdien je dubbel en dwars terug door de tijd die het je (en alle andere toekomstige lezers) bespaart tijdens het lezen van de code.

In veel gevallen echter als excuus van ontwikkelaars, omdat ze de code niet begrijpen, terwijl collega ontwikkelaars er geen moeite mee hebben.

Tja, dat is niet meer dan een stukje positieve compensatie van genoemde collega-ontwikkelaars. Natuurlijk zijn sommige mensen veel beter in snel een mentaal model opbouwen van een matig gedocumenteerd systeem, maar het lijkt me onjuist om op basis daarvan te impliceren dat er niets mis is met een matig gedocumenteerd systeem.

Volgens dezelfde logica zou je bijvoorbeeld kunnen zeggen dat het prima is om uberhaupt geen lunchpauze te doen omdat sommige mensen prima door kunnen werken zonder een lunchpauze in de dag te hebben.

Terzijde, als general tip voor bekend raken met een codebase: een van de eerste stappen moet imho zijn om alle TODOtjes en FIXMEs van de codebase door te lezen. Dat geeft (gegeven dat ze bestaan) vaak heel veel info over eerdergenoemde eigenaardigheidjes en zwaktes, en over het niveau van haast/genomen shortcuts tijdens de eerdere ontwikkeling.

Incomplete documentatie ...

Mee eens. Ik zei niet voor niets: "Actuele, goede documentatie en specificatie is belangrijk ...". Het gebeurt meer dan eens dat er initiëel wel tijd gestopt wordt in het schrijven van documentatie tijdens het ontwerpproces, maar dat deze nooit meer wordt aangepast aan de veranderde requirements. Maar dat is (imho) precies waar je wel tijd en geld voor moet vrijmaken om je systeem in brede zin solide te maken.

Vaak kun je dan beter de gebruikershandleiding lezen, die geeft vaak nog het beste beeld van het systeem én is redelijk up to date

En waarom is de gebruikershandleiding wel up to date? Het antwoord is dat iedereen inziet dat een half kloppende gebruikershandleiding waardeloos is en je business schaadt (toegegeven: deels ook omdat er minder technische kennis voor nodig is om de gebruikershandleiding actueel en kloppend te maken). Maar in zekere zin is de gebruikershandleiding documentatie. Het zijn in principe de use cases van het systeem (zij het met een laag detailniveau van de acties van het systeem).

Code-commentaar is daarbij ESSENTIEEL en in soms nog belangrijker dan systeemdocumentatie.

Ook absoluut mee eens. Hier kan een developer in zekere zin wel de documentatietijd 'opeisen', door die code comments als integraal onderdeel van het schrijven van de code te zien (en zich niet te laten verleiden om e.e.a. z.s.m. de deur uit te willen knallen). Tegelijkertijd valt er nog steeds veel voor te zeggen om tijd in te plannen om de bestaande code door te nemen en daar waar de code comments tekortschieten deze aan te vullen. Waar gehakt wordt vallen spaanders.

Ik wil niet zeggen dat documentatie onnodig is, maar klassieke systeemdocumentatie/ontwerpen zijn zeker niet heilig.

Een van de functies die dergelijke documenten ook hebben is dat ze de hele technische in-depth wereld die de code zelf is in een vorm vatten waarmee ook minder technisch onderlegden het overzicht kunnen krijgen en houden en daardoor betere (tijdsbesparende!) conclusies kunnen trekken en beslissingen kunnen maken over het systeem. Eigenlijk zou het bijvoorbeeld nooit voor moeten komen dat iemand in een support-rol of iemand die nieuwe features of aanpassingen moet voorstellen aan de developers moet vragen/zeggen: "Hoe werkt dit nu eigenlijk?" of "Volgens mij klopt het niet hoe het nu werkt."

Als je nergens anders dan in de code zelf hebt vastgelegd hoe het inderdaad zou moeten werken, dan kun je eigenlijk ook niet vaststellen of de geïmplementeerde werking ook de juiste is (is het by design, of is de implementatie onjuist?). In die zin is het ook een soort vorm van redundancy (zij het dat de specificatie en documentatie in principe altijd leidend zouden moeten zijn).

[Blazing-Studios]

Niet eens zozeer dat (gemiddelde leeftijd was zo rond de 40/50).

Van uit mijn interactie met deze (soms nog Windows 95/NT1) systemen weet ik dat van heel veel software de ontwikkelende partijen al meer dan 10 jaar niet meer bestaan en er ook geen support op geleverd wordt.

In 1 geval was de ontwikkelaar naar een hutje op een berg in India geëmigreerd waarna ze er iemand naartoe hebben gestuurd om hem over te halen om wat dingen op te lossen (waarna het alleen maar erger werd).

Veelal moest je met een pleister naar deze systemen rennen om een slagaderlijke bloeding proberen te stoppen.

Ik vond de verspilling zo walgelijk decadent dat ik al snel gestopt ben.

[RielN]

Of ze verhogen de pensioenleeftijd...

[fevenhuis]

Ik vermoed dat de oplossing voor deze problemen uiteindelijk zal neerkomen op het verdwijnen van een nationale rekenkamer en een bijdrage aan een Europese rekenkamer.

De voornaamste reden dat ik dat denk is omdat de ICT problemen systemisch zijn en niet incidenteel.

[Reactie gewijzigd door fevenhuis op 23 juli 2024 06:17]

[LauPro]

De rekenkamer gaat wel even voorbij aan de kern van de zaak:

De enorm complexe wetgeving waardoor het heffen van Belasting en het toekennen van toeslagen ook een kriem is geworden.

Wat dat betreft kan ik mij wel vinden om eens echt een goed team op te zetten en een geheel nieuw systeem te ontwikkelen dat alle relevante aangiftes op de juiste wijze verwerkt. En dan geen stoffige IBM consultants die miljoenen kosten maar gewoon kleine teams die veel ervaring hebben met het bouwen van webplatformen. Waar gebruiksvriendelijkheid, snelheid en veiligheid zeer belangrijke factoren zijn (de applicatie kan daarna natuurlijk gewoon intern draaien eventueel).

Echter tegelijkertijd moet er ook politieke draagvlak zijn om bepaalde belastingconstructies eenvoudiger te maken anders blijf je met een complex systeem dat ook veel support kost om uit te leggen.

Het is een beetje jammer om alleen maar met modder te gooien richting de Belastingdienst. Ze hebben beperkt budget en kunnen niet zomaar alles even omgooien.

[FreezeXJ]

Het punt is dat het gegarandeerd goed moet zijn, en dat betekent garantie via certificaten, en die hebben kleine bedrijfjes zelden. IBM mag een logge kolos zijn, voor dit soort projecten (en voor de overheid) is het een geschikte partner. Dingen blijven werken, het kost een paar miljoen (geen probleem, belastinggeld), en je weet zeker dat er niks nieuws geintroduceerd wordt zoals Python, C# of Java ofzo.

Het probleem van de overheid is niet de complexiteit van de wetgeving (dat staat keihard vastgelegd in diezelfde wet, en is goed naar de digitale wereld om te zetten) maar die verwevenheid van programmas. Als je 1 functie omzet naar iets moderns, dondert de hele toren om die erbovenop gebouwd is. Nou kun je dan weer output in 8+3-format gaan genereren, of je kunt de stapel proberen in 1x om te bouwen, maar beide methoden zijn traag, en kosten vooral heel veel kennis en geld.

Daarnaast is er het budget-probleem. De laatste projecten kostten miljoenen (300 miljoen voor een paar projecten... ) en zijn geschrapt. Het volgende plan mag dus initieel niet teveel kosten, want dat roept vragen op. Dat het later over budget gaat is nu nog geen probleem. Klein beginnen dus, ergens bovenaan de stapel. Iets als de web-apps wellicht? Laat die oude meuk dan nog maar even draaien, totdat de overheid in staat is ICT te beheren.

[LauPro]

Maar dat is dus het hele punt. Zodra je met een IBM gaat zitten dan ben je per definitie al een miljoenenproject aan het starten.

Volgens mij kan het voor de overheid veel aantrekkelijker zijn om een deel in house / open source te laten ontwikkelen zodat alles veel transparanter is. Prima als daar wat externe consultants naast staan die de zaak in de gaten houden.

Eerlijk gezegd zou ik mij kapot schamen als ik als leverancier 200 miljoen factureer voor een project dat volledig geïntegreerd is bij de klant. Ik begrijp niet hoe die bedrijven daarmee wegkomen. Als je alleen maar zoveel mogelijk uren wil schrijven dan begrijp ik het...

[mustisen]

Eerlijk gezegd zou ik mij kapot schamen als ik als leverancier 200 miljoen factureer voor een project dat volledig geïntegreerd is bij de klant. Ik begrijp niet hoe die bedrijven daarmee wegkomen. Als je alleen maar zoveel mogelijk uren wil schrijven dan begrijp ik het...

Vorig jaar rond deze tijd zijn er verschillende uitzendingen geweest van hoorzittingen waar bovenstaand probleem in uitgezet wordt. Ook is dit ter sprake gekomen in een uitzending van Zembla. De hoorzittingen gingen ook over verspilling van geld bij grote ICT projecten. De aflevering(en) van Zembla ging over hoe een bepaald IT bedrijf aan deze projecten kwam.

In het kort ligt de schuld bij beiden kanten: de overheid heeft de kennis niet om hetgeen de leverancier haar voorschrijft te toetsen. De leverancier heeft daar weer baat bij want projecten lopen uit en hoe langer het daar zit, hoe hoger haar inkomsten. Dus nee, de leverancier schaamt zich niet kapot en zal zich dat ook nooit doen want zij komt daar telkens weer mee weg.

[freaq]

liever 1x 200 miljoen en gegarandeerd goed (laten we wel zijn dit zijn NIET de echt falende kosten uit de klauwen lopende projecten)

dan een project door iemand die het denkt in 30 miljoen te kunnen doen, er consistent naast zit en uiteindelijk 2x zoveel kost en alles houtje touwtje in elkaar flasnt.

nee betaal dan maar en heb een solide en betrouwbaar (en maintainable) systeem.

[mustisen]

Ik denk serieus dat je eens goed het nieuws moet volgen. Dan zul je zien dat het juist niet gegarandeerd goed gaat als je als overheid met één leverancier in zee gaat voor één project van 200 miljoen. De cijfers liegen er niet om: slechts 7% van de projecten met een budget groter dan 7 miljoen slaagt. Dus 93% slaagt niet! Per jaar wordt op die manier 4 tot 5 miljard belastinggeld weggegooid (lees: vloeit weg naar die grote leveranciers waar jij het over hebt terwijl er geen of nauwelijks prestatie tegenover staat).

Dus nee, zo lang die paar grote leveranciers er nog steeds baat bij hebben dat een project zo uit de hand loopt zal er nog steeds vele miljarden aan belastinggeld verkwispeld worden. Zonde.

[freaq]

ik heb nog niet echt een IBM project gehoord wat echt gefaald is ICM de overheid anders, wel veel over mensen die denken het goedkoper te kunnen en er dan een bende van maken,

maar als je een voorbeeld kan vinden zou ik het appricieren.

[mustisen]

Waarom zit je de hele tijd alleen maar naar IBM te kijken terwijl ik het heb over de projecten bij de overheid in het algemeen?

Maar hier zijn twee voorbeelden:

IBM-project in Australië gaat voor een miljard de mist in.

Dan is dat voorbeeld niet een uit Nederland, maar het is hetzelfde principe: IBM dat voor een overheid een groot project aan het uitvoeren is.

En voor Nederland heb ik er ook één: Hoe het UWV ingepakt werd door IBM en Logica.

[freaq]

ok I stand corrected
de reden dat ik IBM pak is omdat IBM dit soort werk met grote Databases al extreem lang erg succesvol doet. en mijn aanname was dat het zovaak fout gaan omdat we niet met de big blue in zee gaan maar met een bedrijf wat dit gewoon niet aankan (maar zegt het te kunnen doen voor 20% goedkoper maar dus duurder blijkt te zijn).

IBM is natuurlijk ook niet perfect, en falen is niet altijd de schuld van het bedrijf, veranderende omstandigheden, verkeerd voorgestelde systemen, kunnen we toch nog even dat ene extra dingetje krijgen etc.

maargoed ik ben kritisch richting de verheid om altijd voor de goedkoopste offerte te gaan. goedkoopste betekent waarschijnlijk gewoon verkeerd gebudgetteerd. en turn key werkt niet want het bedrijf gaat dan gewoon failliet.

imho moet de overheid gaan voor het emest extensieve voorstel in acht nemende de kosten, maar dat voorstel is in elk geval feature compete.

[mustisen]

imho moet de overheid gaan voor het emest extensieve voorstel in acht nemende de kosten, maar dat voorstel is in elk geval feature compete.

Mee eens! En daar schort het aan: de overheid heeft de mensen niet meer die het voorstel van grote (maar zeker ook kleine) bedrijven kunnen beoordelen op haalbaarheid. De IT afdelingen bij de overheid zijn de afgelopen jaren érg geslonken. En daarom moeten deze mensen ingehuurd worden. Wat weer nóg meer geld kost, buiten het belangaspect wat deze mensen nu hebben: langer zitten in plaats van goed werk leveren.

Ben blij dat we het nu eens zijn over dit punt

[freaq]

ik denk dat we het nooit oneens waren
slechts een ander uitgangspunt

[Falcon]

Maar op dit moment gebeurt vaak juiste beide. Flink bom duiten + garantie, maar toch bleek het niet te kunnen en komt er nog 100 miljoen bij.

[mustisen]

En er lijkt in sommige gevallen een wel érg hoog plafond te zijn getuige die project van laatst waar uiteindelijk toch de stekker uit is getrokken.

[jqv]

De overheid is niet al te slim in al haar projecten
Wat is er mis om vooraf een prijs af te spreken? En niet ergens beginnen en wel zien waar de geldstroom naartoe gaat.
Dat is in vele zaken de normale gang van zaken. Voor een bepaald bedrag wordt een project aangenomen. Duurt het langer, dan zijn de kosten voor het bedrijf, zijn ze eerder klaar dan hebben ze extra winst
En jezelf niet meer werk op laten dringen.

Een bedrijf ziet dit als een risico factor dus zal de prijs hoger uitvallen. Maar niet zo hoog als de meeste overheidsprojecten die soms tot tweemaal zo duur worden vanwege onvoorziene problemen

[ronaldmathies]

Omdat geen enkel bedrijf met de overheid in zee gaat als de prijs vooraf afgesproken moet zijn, niet omdat het anders niet genoeg oplevert maar omdat het anders een grote kostenpost voor het bedrijf wordt. Probleem bij de overheid is de belang verstrengeling en de scope creep.

Het is niet zo dat ze vooraf weten wat ze willen, ze weten het grofweg maar als je het eindsysteem bekijkt t.o.v. van wat ze aan het begin wilde dan zie je dat het enorm is gaan afwijken, niet alleen functioneel maar ook architectueel. Deels omdat ze het mischien niet wisten wat ze wilde maar ook deels omdat er vaak twintig capiteins op één schip zitten die allemaal wat anders willen.

Je ziet zelden dat bij dit soort projecten het probleem bij de ontwikkelaars liggen, die kunnen niet veel meer doen dan bouwen wat er gevraagt wordt, het is eerder dat als je iets gebouwd hebt dat je al weet dat je de komende jaar het continue aan het omgooien bent omdat ze het toch weer anders willen hebben. Een ander probleem is bijvoorbeeld dat bij de belastingdienst de software vaak nauw verweven is met de wetgeving, het product is nog niet af of de wetgeving is al tien keer aangepast, wat als gevolg heeft dat je continue het product weer moet aanpassen op plekken wat eigenlijk al opgeleverd was.

De ontwikkeling van een product is namelijk niet start bouw -> testen -> opleveren. het is meer:

Fase 1: start bouw -> testen -> opleveren -> onderhoud -> opleveren -> etc..
Fase 2: start bouw -> testen -> opleveren -> onderhoud -> opleveren -> etc..
Fase 3: start bouw -> testen -> opleveren -> etc..

Waarbij je in Fase 2 al weer wijzigingen in Fase 1 aan het doen bent plus nieuwe functionaliteit en hetzelfde heb je met Fase 3.

Overheid heeft een enorme ineficiente manier van werken, meestal pakken ze het meteen te groot aan ipv het in kleine delen te behandelen. Meestal zie je dat er een mentaliteit is van, gooi er maar genoeg ontwikkelaars tegenaan en het gaat vanzelf sneller (terwijl iedereen elkaar alleen maar in de weg loopt). Vaak zie je dat ze nogal graag met software van partijen als IBM (neem IBM als voorbeeld maar er zijn veel meer van dit soort partijen) werken terwijl die producten enorm duur zijn en weinig toegevoegde waarde hebben. Meestal slepen ze als het even kan dan ook nog een reeks aan consultants naar binnen van die partijen die een fortuin kosten en alleen maar een enorme vendor lock-in veroorzaken want die slepen vrolijk nogmeer IBM spul naar binnen..

Als laatste wat vaak opvalt is dat degene die aan het roer staan totaal onwetent zijn over hoe software ontwikkeling in zijn werk gaan. Ze hebben een totaal verkeerd beeld, ik heb geregeld nog wel eens de uitspraken gehoord dat software ontwikkeling niet veel meer is dan een soort van fabrieks werk waar men kijkt of de glazen flessen geen krasjes / barstjes hebben. Dit leid tot verkeerde verwachtingen, en leid tot verkeerde beslissingen.

En dan denk men dat veel van de problemen op te lossen zijn met het toepassen van Scrum om meer incrementeel op te kunnnen leveren maar hier is weer het probleem dat alleen de onderkant Scrum gebruikt en de rest erboven niet. Er gebeurt dus feitelijk geen Scrum, ja men doet een plansessie, retrospective etc.. maar de functionaliteit staat al vast, de scope voor de oplevering ook en de oplever datum ook.

Dit is mijn ervaring tot nu toe bij de verschillende overheids diensten.

@Toevoeging

Een interesant detail, de overheid werkt met zoveel externe omdat ze moeite hebben om interne ICT mensen te krijgen, een bezetting van 40 tot 60% aan externe mensen is niet ongewoon, voor zover ik begrijp wordt dit mede veroorzaakt door de CAO, deze is zoveel nadeliger (lees, de loon schalen liggen zoveel lager) t.o.v. van het bedrijfsleven dat praktisch niemand bij de overheid in dienst wilt. Dus moet de overheid veel externe aantrekken die veelal twee keer zo duur zijn. De bedrijven maken hier gebruik van door expres hogere tariefen te rekenen voor bijvoorbeeld ontwikkelaars / consultants (+85 Euro ex btw is normaal). Terwijl een interne je per uur gemiddeld 45 Euro per uur kost (incl. belastingen), bij een fatsoenlijke schalen systeem. En wat je dan als interne mensen toch binnen krijgt is (niet rot bedoeld), meestal niet het meest bijzondere.

[Reactie gewijzigd door ronaldmathies op 23 juli 2024 06:17]

[melgers]

Geen java bij IBM? Weet je dat zeker?

[Verwijderd]

ik weet wel zeker dat er heeeel veel java bij IBM is..sterker, bijna al het custom applicatie ontwikkelwerk is in java.
C# niet echt (is van de concurrent). Python wordt vast ook wel gebruikt, maar ik ben er al een tijdje weg..

[Verwijderd]

Het punt is dat het gegarandeerd goed moet zijn

Ik zou er van willen maken... goed moet worden. Want mijn echtgenote en ik zijn al diverse malen het slachtoffer geworden van het amateuristische gerommel van de Belastingdienst. In een geval zelfs besloot de Belastingdienst van het ene moment op het andere dat we niet waren getrouwd en niet op hetzelfde adres woonden.

Echt, vanuit het niets.

Ook heeft het gerommel daar ons letterlijk geld gekost, geld dat wij niet verschuldigd waren maar waar de Belastingdienst wel heilig van overtuigd was en bleef en toentertijd hadden we echt het fut niet om de strijd aan te gaan en hebben we dus maar betaald.

Het punt -- het wordt eens tijd dat er zeer aandachtig wordt gekeken naar de Belastingdienst want de automatisering is niet het enige dat er aan schort daar. En ik neem het de Belastingdienst zelf ook nog niet eens kwalijk ofzo, het is de Nederlandse politiek die alles nodeloos ingewikkeld heeft gemaakt waardoor er door de bomen heen het bos niet meer te zien is, voor wie dan ook.

Er is echt veel meer aan de hand dan de automatisering, veel meer.

[CMD-Snake]

Wat dat betreft kan ik mij wel vinden om eens echt een goed team op te zetten en een geheel nieuw systeem te ontwikkelen dat alle relevante aangiftes op de juiste wijze verwerkt. En dan geen stoffige IBM consultants die miljoenen kosten maar gewoon kleine teams die veel ervaring hebben met het bouwen van webplatformen. Waar gebruiksvriendelijkheid, snelheid en veiligheid zeer belangrijke factoren zijn (de applicatie kan daarna natuurlijk gewoon intern draaien eventueel).

Leuk, web based en gebruikersvriendelijk! Het gaat alleen voorbij aan de kern van de zaak. De wetgeving rondom belastingen is erg complex. Het probleem ligt niet zozeer aan de voorkant, maar in de back office. De software moet alle regels bevatten en deze regels veranderen ook regelmatig. De klacht hier gaat over de manier van verwerken. Nog los van uitzoeken hoe de oude applicaties werken is het denk ik al een gigantische taak om het huidige belastingstelsel opnieuw te vatten in een systeem.

Of schermen met ouderdom zo goed is weet ik ook niet. Een club als de Belastingdienst heeft ook vast nog een mainframe voor bepaalde taken. Die kunnen best oud worden en ondanks dat kan een mainframe een degelijk apparaat blijven. Dat een applicatie daarop net zo oud is hoeft ook nou niet meteen te zeggen dat die per definitie slecht is. Wie weet is die applicatie nog perfect geschikt voor zijn taak.

[LauPro]

Ik geef toch aan dat de essentie is dat er politieke draagvlak moet zijn om systemen eenvoudiger te maken?

Applicaties die niet met de tijd mee gaan kunnen moeilijk worden beheerd of worden veranderd. Er gaat dus veel tijd verloren in het in stand houden van applicaties.

[CMD-Snake]

Ik geef toch aan dat de essentie is dat er politieke draagvlak moet zijn om systemen eenvoudiger te maken?

Applicaties die niet met de tijd mee gaan kunnen moeilijk worden beheerd of worden veranderd. Er gaat dus veel tijd verloren in het in stand houden van applicaties.

De systemen zijn denk ik alleen al complex omdat de regelgeving complex is. Elk jaar veranderd er ook wel iets aan de belastingregels, maar de oude regels moeten ook blijven voor als iemand aangifte over eerdere jaren.

[oef!]

Zoals Snake al aangeeft is het allemaal midoffice en backoffice, websitejes hebben hier niets mee te maken. De systemen zijn niet zozeer complex vanwege 'de regeltjes' maar vooral omdat ze enorm veel verschillende dingen moeten kunnen en met allerhande andere systemen moeten communiceren.

Met het versimpelen van de regels win je praktisch niets, je maakt het alleen maar complexer omdat er dan in een keer een oude situatie en een nieuwe situatie ontstaat, hierdoor wordt alles ineens veel complexer dan het al was (los van het feit dat de hele oude bende bij wijze van spreken gereversed engineered moet worden om er achter te komen wat het überhaupt doet)

Als de belastingdienst met een schone lei begint qua verwerkingssoftware dan kunnen ze net zo goed direct stoppen met bestaan aangezien dit een veeljarig project gaat worden dat geen precedent kent en er van tevoren niet ingeschat kan worden wat de hoeveelheid werk en de kosten zullen zijn. Revolutie is simpelweg niet aan de orde dus blijft alleen evolutie over.

[PolarBear]

Ik geef toch aan dat de essentie is dat er politieke draagvlak moet zijn om systemen eenvoudiger te maken?

Afgezien van de wetgeving en regelingen die complex kunnen zijn (zijn ze niet allemaal) heb je ook met enorm veel uitzonderingen te maken. Je maakt systemen die alle Nederlanders moet kunnen registeren. Dan is een veldje voornaam, achternaam of adres opeens al een complexiteit.

[a fly]

@PolarBear
Alle gegevens die jij noemt zijn al gekoppeld aan een getal van 9 cijfers: Het Burgerservice nummer. Ook mensen die tijdelijk in Nederland wonen/werken krijgen dit. Een kopie van deze database spiegelen naar de belastingdienst stelt dan ook niet meer zoveel voor.
Hetzelfde gaat trouwens op voor bedrijven met hun btw nummer.

@Topic
De overheid heeft sowieso een raar beleid qua kosteninschatting. Enkele jaren geleden was het nog te duur om een kosteninschatting te maken om een server wel/niet redundant te laten draaien. Wat mij betreft was simpel in te schatten door 75% van de gemiddelde actieve gebruikers te pakken, een uurloon rekenen van €20, en de server lag er (veel) meer dan 15uur per jaar uit.
Er zijn niet veel gebruikers nodig om met dit sommetje op het punt uit te komen waarna een 2e server virtueel ophangen goedkoper was.

[keesdewit]

Je hebt groot gelijk. Een compleet nieuw systeem, wat gemaakt is door een aantal teams, waar mensen in zitten die hun werk met passie en gedrevenheid uitvoeren. Dat zijn de mensen die op dit moment voor het bedrijfsleven geld opleveren door succesvolle software op te leveren binnen commercieel haalbare tijd spannen. Waarom zou dat voor de Belastingdienst niet mogelijk zijn?

[S1GNZ]

Tijdens mijn afstudeeropdracht heb ik meegelopen binnen de unit Centrum voor Infrastructuur en Exploitatie en het Centrum voor Applicatiebeheer en Onderhoud.

Wat ik mee heb gekregen is dat er heel erg veel 'oude' legacy applicaties zijn die onderling met elkaar zijn verbonden, waarvan enkele al stammen uit de jaren 80. Die applicaties bereiken een tijd waarop er geen ontwikkelaars meer binnen het bedrijf zijn (kennis loopt de deur of gaat de pijp uit) en waardoor het dus extreem lastig wordt om het te vervangen.

Ook is het vrij lastig om zulke complexe software - zomaar even - te vervangen. Ik heb ooit de procesplaat gezien voor de VIA (Vooraf ingevulde Aangifte), daar wordt je benauwd van als je dat moet ontwikkelen.

[Electromonkey]

Tijdens mijn stage bij de gemeente Rotterdam precies hetzelfde verhaal maar dan op kleinere schaal. Een erg handige Excel sheet in 1998 was in 2014 een "applicatie" waar een hele afdeling mee werkte. Niemand had enig idee hoe het precies in elkaar zat, alleen wat waar ingevuld moest worden.
Uiteindelijk anderhalf mee bezig geweest om het hele ding uit pluizen en begrijpelijk te maken voor een buitenstaander/de medewerkers zelf.

[Jeoh]

Anderhalf wat?

[RielN]

Mensenleven zou indruk maken

[Electromonkey]

Oeps! Anderhalf uur natuurlijk!

[AMS76]

Oh. Dan was het ook geen echt ingewikkelde spreadsheet... Als je 'm in anderhalf uurt kunt uitpluizen.
Ben wel eens spreadsheets tegengekomen waar inmiddels >2GB aan data in stond. Pluis dat maar eens uit Gelukkig was de ontwikkelaar nog aanwezig...

[Electromonkey]

Dat is een clowntje he?!

Anderhalf jaar is er aan gewerkt. Dat is wel inclusief het uitpluizen en verwerken in een functioneel ontwerp voor de ontwikkelaars.

[CyBeRSPiN]

Geen geheimhoudingsverklaring getekend?

[Rub3s]

Hij verteld niets nieuws

[ToFast]

Inderdaad, bij andere 'soortgelijke' (overheids)organisaties zoals het UWV is precies hetzelfde aan de hand.

[flippy]

laat maar eens de overheidstoko zien waar het niet gebeurt...

[CivLord]

Laat maar eens een groot bedrijf zien dat 30 á 40 jaar geleden voorop liep met digitalisering waar niet hetzelfde aan de hand is.

[flippy]

Overheid is geen bedrijf.

[CivLord]

Dat is ook mijn punt.
Grote ICT projecten en vervanging van grote legacy systemen zijn niet alleen problematisch bij de overheid, maar ook voor het bedrijfsleven. Alleen bedrijven slagen er beter in om mislukkingen buiten de publiciteit te houden, waardoor het lijkt dat de overheid het monopolie op ICT problemen heeft.

[Rub3s]

Ik heb een vermoeden dat bij heel veel grote bedrijven met complexe software dit probleem er is, zoals ook bij banken en verzekeraars.

[S1GNZ]

Daar heb je deels gelijk in. Ik ben tijdens mijn onderzoek ook op bezoek geweest bij andere bedrijven, waaronder een zorgverzekeraar. De knelpunten kwamen aardig overeen.

[TimMer]

Ten eerste: hier is niets geheim aan. Geheim is bedrijfsgevoelige informatie, dat is dit niet.

Ten tweede: dat tranendal wordt betaald van ons belastinggeld; wij hebben er dus recht op te weten wat ze met dat geld doen, ook al vindt dat enge zooitje in Den Haag vaak van niet.

[donderdraak]

@B.Gerrits Je zit hier op tweakers.net en geen wikileaks

edit: naam toegevoegd

[Reactie gewijzigd door donderdraak op 23 juli 2024 06:17]

[S1GNZ]

Ik ben niets aan het lekken. Ik heb een geheimhoudingsverklaring getekend voor mijn onderzoek en zet daar ook geen specifieke resultaten van online.

[SirJMO]

Aangezien overheids ICT projecten vaak miljoenen kosten en een snelle oplossing er niet aan zit te komen is mijn idee:
Pak een miljoen, reserveer dit voor loon voor 20 jonge ICT-ers (50.000 p.p. p. jaar).
Laat ze er een jaar aan werken, met 40 weken 40 uur zouden ze het riante salaris hebben van 31,25 bruto per uur.

Geef ieder de opdracht om het bestaande systeem (of een paar delen) te vervangen, met wat dummy data van de input en hoe de input en output nu precies eruit moeten zien.
En dan na een jaar kijken welk van de 20 ICT-ers een goed product heeft afgeleverd .

Indien ze allemaal floppen, niet echt iets verloren omdat:

• er (tijdelijke)banen zijn gecreëerd
• een hoop ervaring is opgebouwd bij deze ICT-ers
• een miljoen die weer circuleert onder echte mensen die niet al miljoenen op de bank hebben.

Behalve dat het probleem nog bestaat, maar ja...
De kans dat er grote stukken kunnen worden vervangen lijkt mij veel groter.(zeker als je een paar miljoen gebruikt ipv 1 miljoen en dan meer ICT-ers)

Slechts een idee wat een miljoen kost en vrijwel meteen ook weer in circulatie brengt. (zij moeten ook eten en leven)

[S1GNZ]

Dat is inderdaad wel een goede werving voor ICT-personeel, maar ik denk ten eerste dat de applicaties te complex zijn voor pas-afstudeerders.

Ten tweede moet je rekening houden dat een gering van de applicaties wellicht zijn geschreven met een programmeertaal die nauwelijks wordt gebruikt en waarvoor ook de nodige kennis is vereist.

Ten derde zet je mensen in om te gaan 'code-diggen' in andermans code. Je weet niet de precieze gedachtegang van de programmeur(s) die de applicatie(s) ontworpen heeft/hebben. Dit maakt de uitvoering van het bovenstaande knap lastig.

Van wat ik weet bij de Belastingdienst wordt er gewerkt met een pool van programmeurs. Zo heb je een pool java programmeurs, C programmeurs etc. Wanneer er een wijziging komt, danwel vanuit de overheid of klantenperspectief dan wordt er een project opgezet. Op dit project wordt een projectleider aangesteld en worden er uit de verschillende 'pools' de programmeurs verzameld.

Deze werkwijze is wel effectief aangezien je niet voor iedere applicatie ondersteunend personeel nodig hebt, maar in jouw bovengenoemde situatie maakt dit het natuurlijk ook erg lastig om een bepaalde applicatie aan te passen, omdat iedereen elke keer aan iets anders werkt.

[SirJMO]

Ik zeg jonge ICT-ers, niet zozeer net afgestudeerd. Je zit ook met verdwijnen van kennis bij pensioen, vandaar jong.

Door die oudere talen te vervangen door nieuwere algemene talen, word het in de toekomst makkelijker. Ook al moet er wat tijd in het begrijpen van de oude code gestoken worden.

Ze zouden het ook vanaf nul beginnen met ontwikkelen als ze weten wat er moet gebeuren in het programma.

[Verwijderd]

Als die ontwikkelaars slechts kleine delen vervangen dan blijft het toch een breiwerk van onsamenhangende applicaties? Dat is volgens mij nou juist een van de problemen. Ik zie het ook niet gebeuren dat zo'n ontwikkelaar in zijn eentje een dermate complex systeem gaat ontwikkelen zoals je die bij de overheid ziet.

[SirJMO]

Als stukken uit dat breiwerk verdwijnen door meerdere kleine delen tot 1 te brengen en het complexe simpeler gemaakt word met ook nog goede documentatie.
Dan kan uiteindelijk dat hele breiwerk terug worden gebracht tot enkele programma's.
Uiteindelijk misschien zelfs 1 programma dat dan weer complex word, maar uit simpele dingen is opgebouwd die goed gedocumenteerd zijn en dus makkelijk aan te passen.

Moet toch ergens beginnen met het versimpelen en opschonen.

[Verwijderd]

Probleem van overheden (en ook banken) is dat ze het ene systeem op het andere stapelen. Waardoor uiteindelijk ook een nieuw stukje software afhankelijk wordt van de oude software.

De eerste minister staatssecretaris die het lef heeft om echt een keer een systeem vanaf de grond af op te bouwen (duurder op de korte termijn, beter op de lange) heeft mijn stem voor de volgende verkiezingen.

[emnich]

En die verliest mijn stem. Dit is een onmogelijke taak die nooit volbracht zal worden.

De enige reële optie is om per onderdeel te vernieuwen. Daarbij zal je stukken zo moeten herbouwen dat oude systemen er nog steeds afhankelijk van kunnen zijn op hun vertrouwde manier en de nieuwe systemen op een andere manier.

Zo houdt je een werkend systeem, zijn. alle deelprojecten behapbaar en kom je gegarandeerd onder de totale kosten (inclusief de talloze bugs die je gaat tegenkomen) van het compleet opnieuw bouwen uit.

[AMS76]

Eerst alle koppelingen tussen applicaties inventariseren, en hier een nieuwe standaard (datawarehouse?) voor inrichten.
Dan een voor een de applicaties aanpassen.

Anders zie je nog door de bomen het bos niet meer...

[C.Cluch]

Ik pleit al jaren voor een minister ICT binnen het kabinet. Iemand die ook echt verstand heeft van ICT zaken en niet een of andere praatjes maker die alles afschuift naar een externe ICT bedrijf.

lijkt me toch niet zo lastig?

[Reactie gewijzigd door C.Cluch op 23 juli 2024 06:17]

[kidde]

Is wel lastig, iedereen wil minder ambtenaren, PVV wilde geloof ik nog eens 30% ontslaan. Iedereen vind ambtenaren traag en inefficiënt tijdens de borrelpraat.

Rijkswaterstaat geeft daar gehoor aan, alle ambtenaren met kennis zijn weg met als gevolg oa Fyra en faillisement ballast Nedam en A15 en A2 debacle. En nu weer iedereen boos dat ze geen kennis van zaken hebben, ja, hoe is het, wat willen we als kiezer nou eigenlijk? Wij kiezers zijn hierbij zelf debet aan.

[scsirob]

Is wel lastig, iedereen wil minder ambtenaren, PVV wilde geloof ik nog eens 30% ontslaan. Iedereen vind ambtenaren traag en inefficiënt tijdens de borrelpraat.

Rijkswaterstaat geeft daar gehoor aan, alle ambtenaren met kennis zijn weg met als gevolg oa Fyra en faillisement ballast Nedam en A15 en A2 debacle.

Dat heeft niets met het aantal ambtenaren te maken, maar wel met gebrek aan kennis en de manier van aanbesteden. Je haalt toevallig twee voorbeelden aan die verschillend aanbesteed zijn.

Fyra is een debacle geworden omdat er (zoals bijna altijd) gekozen werd voor de laagste aanbieder, zonder dat er kennis van zake was om te beoordelen of de aanbieding ook kwalitatief in orde was. Soortgelijke aanbestedingen waren altijd de regel, te laag inschrijven en vervolgens het handje ophouden want men kon toch niet meer terug. Slachtoffer: De belastingbetaler.

Ballast Nedam heeft zich vergalloppeerd aan de nieuwe manier van aanbesteden. Heel simpel: We hebben budget <x> (zeg 150 Miljoen), wat kan je daarvoor leveren. De ene biedt een weg, de andere een weg met fietspad, de volgende een weg met fietspad en park. De bieder van het meeste value wint. Ballast Nedam dacht op reguliere wijze het handje op te kunnen houden als de 150 Miljoen op was. Rijkswaterstaat zegt terecht: Jammer dan, budget is budget. Slachtoffer: Ballast Nedam.

Doe mij dat laatste maar.

[Reactie gewijzigd door scsirob op 23 juli 2024 06:17]

[kidde]

Eens, echter, behalve verschillen zijn er overeenkomsten:
-Beide projecten waren simpelweg te groot en te complex (ik denk dat dit ook voor SPEER geldt),
-In beide gevallen hebben (semi-) overheden hun eisen veranderd,
-Resultaat is dat Finmecannica (Ansaldo Breda) noodlijdend werd en werd overgenomen, ik voorzie voor Ballast Nedam hetzelfde,
-Ballast Nedam gaat zeker proberen om geleden schade te verhalen op RWS.

[bouwfraude]

Dat kennis weg loopt is omdat ze verkeerd bezuinigen. Op de werkvloer wordt beknibbeld, de niets wetende management laag blijft.

[SvMp]

Ze moeten wel de juiste ambtenaren wegsturen: boa's, cultuur, ontwikkelingshulp, onzinnige subsidieregelingen. Hele afdelingen en delen van departementen kunnen zonder problemen verdwijnen.

[field33P]

Gezien het feit dat we momenteel al mensen die niets over het onderwerp weten als minister neerzetten (zie defensie, VWS), denk ik dat dat ook op een ministerie van ICT fout zal gaan.

[Navi]

Sterker nog, alleen een minister van ICT is te weinig, omdat ICT alles raakt.

Overal moeten dus gewoon 2 ministers komen:
Minister van Financien
(vice?)Minister van Financien ICT

Minister van Defensie
(vice?)Minister van Defensie ICT

etc..

[SvMp]

ICT moet je niet aan de overheid overlaten, zelfs niet met een minister.
Regels schrappen (zoals de cookiewet en een groot deel van het auteursrecht) en de markt zijn werk laten doen.

[AMS76]

Ja, laten we nog meer nietswetende managers (want wat is een minister anders dan een manager) aanstellen. Dat zal vast helpen...

[the_shadow]

De eerste minister staatssecretaris die het lef heeft om echt een keer een systeem vanaf de grond af op te bouwen (duurder op de korte termijn, beter op de lange) heeft mijn stem voor de volgende verkiezingen.

Dat is een miljardenoperatie die gegarandeerd a) over tijd, b) over budget en c) foutief gaat werken. Ik ben het met je eens, zodra onderhoudbaarheid van systemen (vanwege het ontbreken van ontwikkelaars met de juiste know-how) in het geding komt, moet er iets veranderen. Echter, met een Big Bang een volledige infrastructuur onderuit trekken en een volledig nieuw alternatief neerzetten is denk ik ook niet de gewenste aanpak. Aangezien het gaat om enkele honderden systemen moet dit langzaam, stap voor stap aangepakt worden. Ja, kostbaar, maar in mijn ogen de enige manier waarop je een dergelijke migratie kan aanpakken zonder al te veel stront aan de knikker te krijgen.

[Verwijderd]

[...]
Dat is een miljardenoperatie die gegarandeerd a) over tijd, b) over budget en c) foutief gaat werken. Ik ben het met je eens, zodra onderhoudbaarheid van systemen (vanwege het ontbreken van ontwikkelaars met de juiste know-how) in het geding komt, moet er iets veranderen.

Conclusie is dat de overheid efficienter moet worden. Door de efficientie te verhogen worden ook 80% van de problemen in de pensioensector, zorg, het onderwijs etc opgelost.

[KoffieAnanas]

Die kans is erg klein gezien de eerdere missers bij IT projecten van de overheid. Kans op succes is klein, de reputatieschade groot.

[PolarBear]

De eerste minister staatssecretaris die het lef heeft om echt een keer een systeem vanaf de grond af op te bouwen (duurder op de korte termijn, beter op de lange) heeft mijn stem voor de volgende verkiezingem

http://www.ben-morris.com...better-than-rewriting-it/

En een minister of staatssecretaris wordt niet gekozen.

[Lethalis]

Tsja, anderzijds heb ik nog nooit een groot succesvol project gezien dat een complete rebuild was.

Ik ben bang dat het dus alleen maar veel geld kost.

[CivLord]

Zolang de grote ICT bedrijven er nog steeds mee wegkomen om veel te beloven en een paar honderd miljoen later niets werkbaars te leveren blijft er helaas niets anders over dan blijven stapelen op de oude meuk die je al hebt.

[r3agluurder]

Tja als ze nou eens een paar goede it architecten aannamen en die aan het werk zetten en in fases wat uitrollen ipv miljoenen aanbestedingen bij bedrijven uitzetten, zou het een stuk behapbaarder worden. Ze zijn veels te log om in 1 keer alles om te zetten.

Edit:

Ik krijg ondertussen de indruk dat er targets gehaald moesten worden op het ministerie. Netto 3500 man eruit door automatisering en aan de andere kant hoor je dat het wederom (lees: nog steeds) een drama is bij de belastingdienst

[Reactie gewijzigd door r3agluurder op 23 juli 2024 06:17]

[blade181]

Het probleem is dat de werkelijkheid vaak de IT projecten inhaalt. Men verandert namelijk om de haverklap wet en regelgeving, hierdoor is het gemaakte ontwerp niet meer de werkelijkheid. Hetgeen wat dan opgeleverd wordt is niet meer bruikbaar.

[ZeroTwo]

Bureaucratie lijkt mij het probleem. Het bedrijfsleven kan het ook dus waarom de overheid niet.

[emnich]

Omdat het bedrijfsleven vóór het nemen van een beslissing ook kijkt of het technisch haalbaar is. Een gemiddelde politicus heeft daar geen boodschap aan.

Hiermee wil ik niet zeggen dat je een politieke keuze niet zou moeten maken omdat de BD zegt dat het niet zou kunnen..

[tmnvanderberg]

"Het bedrijfsleven" kan dat helemaal niet. Sommige bedrijven kunnen het. Vaak is de ICT bij bedrijven een enorme bende.

[MrAngry]

Het lijkt me een slechte zaak als je ontwerp afhankelijk is van wetgeving. Veranderende wetgeving moet je juist meenemen in je ontwerp, dat wil zeggen dat je systeem draait op templates die te wijzigen zijn (of iets dergelijks).

[CivLord]

Klopt. Maar hoe lastiger het is om achteraf wijzigingen in software door te voeren des te meer kan de bouwer van de software er aan blijven verdienen.
Waarom iets onderbrengen in een .ini bestandje dat een systeembeheerder aan kan passen wanneer je het ook kunt hard-coden en je voor elke wijziging opnieuw facturen kunt versturen.

[MrAngry]

Omdat dat in de URS staat? Zijn er echt bedrijven die zich zo laten naaien? Ik bedoel, misschien een keertje, maar daarna zou je er toch van moeten leren als organisatie.

[CivLord]

Omdat de softwarebouwer zegt het programma veel goedkoper te kunnen maken wanneer alles hard-coded is en niet alles uit .ini bestanden te halen. En aangezien de aanschafkosten het probleem van de huidige manager zijn en de onderhoudskosten het probleem van zijn opvolger, is de keuze eenvoudig.

[r3agluurder]

Dat ben ik met je eens, maar zou je de architectuur niet dusdanig kunnen voorbereiden op zulke veranderingen? Waardoor je meer adhoc gaat werken?
En na de 'quickfix' weer het liedje deels opnieuw begint? Soort van modulaire opzet?

Een tweede factor dat meespeelt bij zulke IT projecten is de graaiachtige cultuur van grote IT bedrijven. Ik denk als die cultuuromslag plaatsvindt dat het ook financieel beter wordt. En zijn er vast nog genoeg factoren die meespelen.

Meer kennis in eigen huis en de belangrijkste systemen zelf beheren/ontwikkelen en minder kritieke processen uitbesteden bij IT bedrijven.

[AMS76]

Daarom, modulair opbouwen. Verandert er een wetje? Hoef je alleen module X aan te passen, ipv je hele applicatie te herschrijven...

[the_shadow]

Tja als ze nou eens een paar goede it architecten aannamen en die aan het werk zetten en in fases wat uitrollen ipv miljoenen aanbestedingen bij bedrijven uitzetten, zou het een stuk behapbaarder worden. Ze zijn veels te log om in 1 keer alles om te zetten.

Absoluut mee eens. Ik zie ook niet waarom keer op keer de grote IT detacheerders voor dergelijke projecten in de arm genomen worden, terwijl ze inmiddels een redelijke track-record hebben opgebouwd van behoorlijk hard falen. Ik vrees alleen dat (omdat het gaat om posities binnen de overheid) ze niet (CAO technisch) gelijke salarissen kunnen bieden voor dit soort experts, als dat gedaan wordt door Capgemini en consorten. Geen mensen, geen project.

[Tenocticatl]

Gebruiken grote banken niet nog steeds COBOL? Het is natuurlijk stompzinnig om een dataverwerkingsstructuur zo op te zetten dat je 'm niet (makkelijk) kunt upgraden, maar ik heb het idee dat dat in grote organisaties eerder regel dan uitzondering is.

[blurgh]

idd, veel banken(maar niet ALLEEN banken) gebruiken nog COBOL. probleem: geen hond kent nog COBOL. iedereen met ervaring gaat met pensioen, degene die het wel hebben kosten een godsvermogen, en bijna niemand die het meer leert.

met andere woorden: als je het geen probleem vind een vrij slechte programmeertaal t eleren en antieke systemen in leven proberen te houden, leer COBOL. als je voor de rest al wat ervaring hebt loop je zo binnen.

[dataworm]

Dat zou je wel denken, maar alle COBOL ontwikkelaars die ik ken zijn of overgestapt naar modernere talen of zitten werkloos thuis inmiddels.

[Luno]

Zo moeilijk is COBOL niet. Het is juist een taal waardoor niet alleen de programmeur, maar ook de meelezende medewerker duidelijk is wat er berekend wordt. Ik zeg niet dat het onmogelijk is om een onleesbaar COBOL programma te maken, maar met juist gekozen namen van variabelen is het meestal duidelijk wat het programma doet.
Welke logische beslissingen er genomen moeten worden is een (belasting)proces is belangrijk en of je dat in C, PL1, Algol Fortran of COBOL programmeert is irrelevant. Maar in COBOL sluit het programma beter aan bij het jargon van een administratie. Dec opdrachtgeven kan ook beter nagaan of zijn bedoelingen begrepen zijn door de codeur.

Ga geen COBOL gebruiken voor een spraakherkenningsprogramma, daarvoor is het niet gemaakt,

[jpsch]

Opzetten valt wel mee. Probleem ontstaat bij aanpassingen, waarbij vaak quick-and-dirty gewerkt wordt, omdat er weinig tijd en budget is. Paar van dit soort rondjes en je systeem begint aardig op een black box te lijken. En aangezien bij de belastingdienst elk jaar de wetgeving wel weer wat verandert.

[Tenocticatl]

... en na een aantal jaar krijg je natuurlijk met verloop van werknemers te maken, mensen hebben hun code niet goed gedocumenteerd want alles moest snel... snap 'm.

[CAPSLOCK2000]

De belastingdienst zit ook in een lastig parket omdat er al jarenlang op wordt bezuinigd. Tegelijk zitten ze wel met harde deadlines terwijl de gemiddelde Nederland pas op het allerlaatste moment aangifte doet. Ik kan begrijpen dat het heel moeilijk is om iets te veranderen en al helemaal om een oud systeem uit te zetten.

Gezien het nieuws van gisteren proberen ze nu toch drastisch in te grijpen
nieuws: Belastingdienst reorganiseert maar neemt 1500 mensen aan voor data-analyse .

[jpsch]

Dat 2e is toch een voordeel? Veel werkload in een korte overzienbare tijd, kun je in de overige maanden juist veranderingen in gang zetten en goed testen.

[CAPSLOCK2000]

Er moet inderdaad ook heel veel getest worden want zodra het in prodcutie gaat moet het foutloos werken en krijg je direct de grote massa over je heen.

Goed testen wordt echter flink moeilijk gemaakt omdat de wet voortdurend verandert. De Belastingdienst moet maar zorgen dat ze bij blijven. Soms moet er op het laatste moment nog een grote verandering wordne doorgevoerd. Het is dus belangrijk dat de basis zo stabiel en betrouwbaar mogelijk is.

[bouwfraude]

Maar het werkt niet foutloos. De webapp zit vol fouten en de Windows applicatie die het wel doet zit tegenwoordig goed verstopt op de site.

[Luno]

Je onderschat het probleem. Niet alleen de wet veranderd, maar je moet ook nog de aangifte van 2013 kunnen verwerken bij een correctie, of die van 2014, en ook middenin een jaar veranderen er zaken (bv btw na 1 juli van 6% naar 21%).
Een programma dat uitstekend is volgens de laatste wetten is foutief voor aangiftes voor de laatste wet.(ten).
M.a.w. na elke belasting wijziging, of jurisprudentie van uitleg van wetten, is er een nieuwe programma nodig, bij jurisprudentie kan het ook zijn dat programma's van vorige jaren aangepast moeten worden.

[CivLord]

Er zijn meer belastingmiddelen dan alleen de inkomstenbelasting. Het klopt dat wanneer er in 2013 wijzigingen voor de inkomstenbelasting 2014 worden doorgevoerd het aangiftesysteem pas in 2015 klaar hoeft te zijn.
Voor de BTW en de loonbelasting moet er elke vier weken, maand of drie maanden aangifte gedaan worden. De politiek beslist vaak vrolijk in oktober of november nog dat er per 1 januari iets gaat veranderen. Dan moeten de systemen uiterlijk eind januari gereed zijn om miljoenen aangiftes te verwerken.
Het is niet vreemd dat er af en toe iets mis gaat. Het is juist een godswonder dat het zo vaak goed gaat.

[woekele]

Oud opzich is inderdaad geen probleem. Wij draaien een VB-applicatie van minimaal 10 jaar oud. Maar het draait soepel en snel en zit logisch in elkaar. In tegenstelling tot bijvoorbeeld nieuwe, maar trage, buggy, web-based cloud-crap die java-plugin in je browser vereist en alleen in IE draait.

Maar andere aspecten kunnen inderdaad wel belangrijk zijn, zoals schaalbaarheid en koppeling met andere systemen.

[Montaner]

Je gaat ook ineens snel van vb (stiekem even de link naar .net) en een heel ander soort applicatie. Waarschijnlijk als je dezelfde applicatie is (vb).Net 4 maakt dat het wel gewoon doet wat je wil, en sneller en beter is.

Maar het probleem bij de belastingdienst, en wat dat betreft heel veel grote data verwerkende bedrijven, is dat niemand zich eraan durft te branden zolang het nog enigszins goed werkt. En er ondertussen niemand meer is die weet hoe het aan elkaar geknoopt is, enkel nog eilandjes kennis van bepaalde onderdelen.

Een nieuwe leverancier vinden die dit toekomstvast kan vervangen is al moeilijk, en dan ben je ook nog eens overheid. En veel bedrijven begin bij vooral dat laatste te stuiteren van geluk bij een mogelijke opdracht. Valse beloftes, daardoor uitloop en onbeperkt cashen. Totdat een minister er tussen komt en dan wordt je ontslagen, velen miljoenen rijker. En dan zit je weer met een nieuwsbericht over falende ICT projecten bij de overheid.

[Verwijderd]

Wat is er mis met web-based spul? Web-based apps hebben zóveel meer voordelen dan lokale apps.

Er komt een tijd dat alles web-based is.

[Douweegbertje]

Heel veel.. afhankelijk van je doel. Je kunt niet zware backend's 'webbased' houden. Ik noem maar even het verwerken van heel veel data.. dat wil je niet simpel webbased hebben.

[Herko_ter_Horst]

Inderdaad, het verwerken van heel veel data, zoals bijv. Google en Facebook doen, kun je niet webbased hebben...

Wat denk je dat web-based applicaties zijn? Dat zijn in elk geval NIET de Flash en Java-plugin-gebaseerde dingen van eind jaren '90.

[RagingPenguin]

De backend van Facebook en Google zijn ook niet web-based... Front-end is heel wat anders

[Douweegbertje]

Ik weet niet of je serieus bent met je smileys. Facebook gebruikt in de backend o.a. C++, Python, Perl, Erlang, Java en inderdaad ook een stuk PHP. In elk geval totaal niet 'webbased' of 'web talen'.

[Herko_ter_Horst]

Wat ik bedoel, is dat met een web-based applicatie in het algemeen juist dat soort applicaties met een "website" als front-end en een server (in welke taal dan ook) als back-end bedoeld worden.

[Verwijderd]

Onzin.

Het proces wat jouw vele data verwerkt is gewoon een achtergrond proces, wat je aanstuurt via je webapp. Daar heb je echt geen lokale app voor nodig.

[Douweegbertje]

We hebben het hier heel de tijd over de IT systemen van de BD. Dan kom je aan met een webbased oplosing. Nogal krom. Grote kans dat de huidige systemen al applicaties hebben die webbased zijn, maar verder in de proces stroom nog alles verwerken met COBOL op een gare bak. Daar gaat het uiteindelijk ook over.
9 van de 10x maak je data met wat nieuwere meuk, die niet zo afhankelijk zijn van andere zaken. Dieper liggende processen gebeuren meestal nog op die oudere zooi.

Simpel zeggen 'wat is er mis met web-based spul' is dan iets met appels en peren.

[djneo-nl]

" nieuwe, maar trage, buggy, web-based cloud-crap die java-plugin in je browser vereist en alleen in IE draait." dat klinkt niet echt nieuw

[bArAbAtsbB]

is toch al lang bekend dat de hele overheid zo aan elkaar geknoopt is qua ICT....allemaal houtje touwtje aan elkaar....en maar zeuren dat nieuwe systemen niet werken...men zou gewoon een een alomvattend overheidssysteem moeten maken...maarja kost te veel denk ik!

[the_shadow]

Overheden, banken, luchtvaartmaatschappijen, productieindustrie. Alles waar je te maken hebt met bedrijfscritische systemen die in de begintijd van de automatisering zijn geintroduceerd, loop je tegen dit soort constructies aan. Vervanging is vaak dusdanig kostbaar dat andere, nieuwe systemen er tegenaan bouwen de enige kosteneffectieve mogelijkheid is.

[Reactie gewijzigd door the_shadow op 23 juli 2024 06:17]

[jpsch]

Soort SPEER, omgedoopt tot ERP en gestopt door Hennes?

[wnb_pro]

Het is mooi dat dit openbaar gemaakt wordt omdat heel veel organisaties dit niet op orde hebben. Een instelling als de Belastingdienst behoort dit toch echt wel up to date te houden. Als het een keer fout gaat kan het ook echt de foute kant op gaan, zeker zonder die 5000 werknemers.