'Gebrekkige software kost overheid miljarden'

De overheid betaalt jaarlijks vier tot vijf miljard euro aan automatiseringssystemen die gebreken vertonen of nooit in gebruik worden genomen. Deze conclusie trekt Trouw na een analyse van de uitgaven aan it-projecten en een rondgang langs deskundigen.

Het dagblad berekende dat deze jaarlijkse kosten net zoveel zijn als dat de aanleg van de Betuwelijn in zijn geheel heeft gekost. Volgens enkele ondervraagde deskundigen wordt het de hoogste tijd voor een inventarisatie van het probleem, zodat aan oplossingen gewerkt kan worden. In de ogen van Jan Friso Groote, hoogleraar computertechnologie in Eindhoven, is het probleem van falende it-systemen ook buiten de overheid structureel. Uit Amerikaanse cijfers zou blijken dat van alle automatiseringsprojecten 30 procent nooit van de grond komt, 50 procent bij de invoering veel problemen geeft en slechts 20 procent als geslaagd is te bestempelen. Berekend op de Nederlandse overheidsuitgaven zou zeker drie miljard euro gestoken worden in totaal mislukte projecten. De Amsterdamse Informaticahoogleraar Chris Verhoef verklaart tegenover Trouw dat het cijfer nog weleens hoger zouden kunnen liggen: 'Vijf jaar geleden is voor het ministerie van Vrom onderzoek gedaan naar automatisering bij de overheid. Volgens dat onderzoek kwam maar liefst de helft van alle projecten nooit tot voltooiing.'

Een belangrijke veroorzaker van de mislukte overheidsinvesteringen in informatietechnologie zouden de politici in Den Haag zijn. Door steeds nieuwe eisen te stellen aan nog niet afgeronde projecten, ontstaan grote problemen. Zo moest de Belastingdienst vorig jaar een systeem voor het toekennen van huurtoeslag en zorgtoeslag ter waarde van vijftig miljoen euro in de ban doen. Dit werd veroorzaakt door het grote aantal regels en uitzonderingen, waardoor de software nodeloos ingewikkeld was geworden en daarom vol fouten zat. De fiscus besloot uiteindelijk om zijn automatiseringssysteem te vervangen voor een geheel nieuwe, waarbij de software voor het berekenen van toeslagen compleet zal worden vervangen. Behalve de burger heeft ook het bedrijfsleven last van mislukte it-projecten bij de overheid; zo zijn de Nederlandse Spoorwegen regelmatig de dupe van vastgelopen computersystemen van spoorbeheerder ProRail, waardoor vertraagde treinreizigers compensatie opeisen bij de vervoerder.

Reacties (80)

[Verwijderd]

Het meest opvallende is dat bij grote automatiseringstrajecten telkens dezelfde fouten worden gemaakt:

1. geen communicatie en dus geen draagvlak binnen het bedrijf
2. de software blijkt na implementatie niet gebruiksvriendelijk, het personeel heeft moeite om ermee te werken, er wordt te weinig tijd in opleidingen gestoken
3. de kosten blijven niet binnen het budget; er wordt vooral naar de baten gekeken, niet naar de extra kosten
4. oplevering is te laat
5. de top trekt direct de handen ervan af als het mis gaat ("Het is toch een automatiseringsprobleem? Laat hun het maar oplossen.")
6. onvoldoende energie wordt gestoken in conversie van bestaande gegevens
7. voor het testen wordt te weinig tijd uitgetrokken
8. projecten breiden zich als een olievlek uit, waardoor het niet meer hanteerbaar is (onvoldoende nadenken over de consequenties)
9. de tijd dat automatisering snelheidswinst opleverde ligt achter ons (je hebt steeds meer personeel nodig).
10. niet alleen software verandert, maar ook de onderliggende processen veranderen; dit wordt vaak onvoldoende onderkend.

[elmuerte]

#2 is geen automatiserings fout, het is denk fout. Je hebt een verschrikkelijk ingewikkeld systeem dat veel werk kost om handmatig uit te voeren geautomatiseerd waardoor het makkelijker te gebruik is. Makkelijker betekend niet makkelijk. Men is gewoon te laks.

#4 dat is geen fout, dat is een resultaat van een aantal factoren. Je kan best wel eerder opleveren, maar dan is het gewoon niet af.

#9 ook een resultaat en geen fout.

Bijna alle fouten zijn terug te brengen naar:
- slechte specificaties, de klant weet bijna nooit wat die wil waardoor specs tijdens het ontwikkel process veranderen.
- te weinig aandacht voor QA, want er is al zo weinig tijd en "het moet gewoon in 1 keer goed zijn". Testen doe je niet achteraf, dat doe je tijdens het hele ontwikkel process. Testen word ook een voor groot deel door de ontwikkelaars gedaan.
- slechte documentatie, en daarmee bedoel ik dus documentatie van de implementatie van het system zoals aanmanens source code commentaar. Als de code of ontwerp niet direct duidelijk is hoort er commentaar bij.

Verder worden er vaak ontwerp fouten gemaakt, te veel systemen worden monolitisch gebouwed in plaats van modulair/component based.

[E.T.O.]

Ook 'moet' de overheid kiezen tussen een standaard aantal aanbieders en van de aangeboden offertes degene met het laagste bedrag onder de streep kiezen. Alle kosten welke niet door de offerte gedekt worden komen daar nog eens bovenop waardoor de "goedkoop" is "duurkoop" regel van toepassing wordt.

[denkster]

Prima opsomming!
Je vergeet nog een paar enorme standaardfouten:
5a. Projectleiders accepteren (prestige, carrière) projecten met onhaalbare deadlines, gegeven de te leveren functionaliteit, te stellen kwaliteitseisen, het beschikbare budget, verander-snelheid van de omgeving, de heersende risico's en beslissingstrajecten
2a, 8b De kwaliteit van de analyse (gegevensmodellering, procesmodellering) is onvoldoende. Analisten hebben doorgaans geen benul van de business.
3a, 8a. Bij het begin van het project zijn de scope en de randvoorwaarden (te stellen kwaliteitseisen, het beschikbare budget, verander-snelheid van de omgeving, de heersende risico's en beslissingstrajecten) onvoldoende ingecalculeerd
6a Ontwerpers concentreren zich op het systeem, terwijl het om de inhoud van de informatie moet gaan. Ze vergeten de bestaande gegevens en bouwen 'lege dozen'.
7a. De activiteiten voor het testen beginnen te laat. Bij het allereerste ontwerp moet al vast staan wat men hoe gaat testen. Het testontwerp moet gelijk-op lopen met het systeemontwerp.

[styno]

De fiscus besloot uiteindelijk om zijn automatiseringssysteem te vervangen voor een geheel nieuwe, waarbij de software voor het berekenen van toeslagen compleet zal worden vervangen.

Daar gaan we weer: "weet je wat, we beginnen wel weer opnieuw". Nou dat gaat de belastingbetaler gegarandeerd weer de nodige miljoenen kosten. En het resultaat? Jaren uitloop in de ontwikkeling, tientallen procenten duurder dan beraamd en waarschijnlijk niks beter dan de oude systemen....

Edit: Ja, mod de kritiek maar weg, maar wat betreft de uitloop en kosten heb/krijg ik gewoon gelijk...

[Freee!!]

En het resultaat? Waarschijnlijk niks beter dan de oude systemen....

Als beroepsprogrammeur kan ik je vertellen dat het geregeld een heel stuk sneller en eenvoudiger is om een stuk code opnieuw te schrijven dan door te blijven modderen met aanpassing op aanpassing, dus daarmee is het tevens een stuk goedkoper.

Ik ben het met je eens dat het direct goed zou moeten, maar dan moeten die politici eens een keer op tijd hun bek houden (en ze menen zelf dat ze daarvoor niet gekozen zijn).

[styno]

Dag collega! Wanneer we het hebben over complexe system en als die bij de belastingdienst draaien, is het even opnieuw schrijven van de code heel wat meer werk dan nieuwe/gewijzigde wetten verwerken in bestaande code. Dat het uiteindelijk beter zal werken waardoor er minder handelingen uitgevoerd moeten worden en aanpassingen eenvoudiger gaan wil niet zeggen dat een nieuw systeem ontwikkelen niet zelden onderschat wordt en veel duurder dan verwacht.

[catfish]

klopt wel, maar waarschijnlijk doelt Freee!! op het feit dat programma's met aanpassing op aanpassing op aanpassing meestal niet zo bugvrij zijn... en begin dan maar eens te zoeken... nog een aanpassing

onderschatte systemen zijn meestal de fout van slechte analyse, als je een echt goed model opzet, dan zou de programmatie geen/weinig problemen mogen geven

[g4wx3]

Waarom je nooit moet opnieuw beginnen.

[Verwijderd]

Interesant artikel... maar verschrikkelijk kortzichtig.

Natuurlijk, er zijn tal van redenen waarom je niet zomaar oude code moet weggooien. En hij geeft er een paar heel belangrijke aan. Ook geeft hij een paar hele duidelijke drogredenaties aan, waarom je niet moet herschrijven.
Maarre... Niettemin zijn er ook tal van redenen waarom je dat soms wel moet doen. O.a. wanneer de fundamentele architectuur van het systeem verandert.

Vooral het Netscape 6 voorbeeld is verschrikkelijk slecht. Dat is namelijk ons aller zo geliefde firefox. En de reden dat die momenteel zo perfect met CSS e.d. omgaat, is juist omdat het compleet opnieuw geschreven is. Waarom? Omdat het fundament van de rendering engine opnieuw geschreven moest worden, omdat het oude totaal ongeschikt was om met de CSS structuur om te gaan. Iedereen die geprobeerd heeft CSS floats toe te passen in Netscape 4.x weet hoe verschrikkelijk dat systeem was.

[Verwijderd]

Wát een ontzettend slecht stuk, zeg. De auteur generaliseert vreselijk, en stelt bijvoorbeeld:

The idea that new code is better than old is patently absurd.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

Nou, daar ben ik het dus niet mee eens. Hij gaat namelijk volstrekt voorbij aan de volgende feiten:

1) Een project waar in de loop van de tijd van alles aan vastgeprutst wordt (zoals bij veel grote projecten gebeurt), wordt in toenemende mate onbeheersbaar. Bij zo'n project wordt het steeds tijdrovender om bij wijzigingen in het ontwerp en/of de code of bij het maken van uitbreidingen, uit te zoeken waar een wijziging of toevoeging allemaal invloed op heeft. Bedenk daarbij dat documentatie vaak achterloopt, en dan dus onvolledig en/of (op punten) incorrect is. Waardoor het spitten in de code uitsluitsel moet geven. Wat dus door het toenemen van het aantal regels steeds moeilijker wordt. En vroeger of later het overslagpunt bereikt wordt waarbij geheel of gedeeltelijk herontwikkelen goedkoper wordt.

2) Er bestaat zoiets als voortschrijdend inzicht in het probleem... Waardoor een nieuw (heel- of deel-)ontwerp vaak veel kleiner, transparanter en robuuster is dan het oorspronkelijke. En de implementatie dus veel minder code bevat - met in het algemeen minder fouten.

3) Een bij zijn vakgebied betrokken ontwikkelaar doet steeds meer ervaring op. Daarom zal de kwaliteit van zijn (m/v) ontwerpen en implementaties door de bank genomen een stijgende lijn vertonen. En de kwaliteit van een herontwerp / implementatie dus hoger liggen.

4) In de loop der tijden ontstaan nieuwe methoden (bv OO vrs. procedureel) en technieken (bv C++ vrs. C), waarmee een probleem beter aangepakt kan worden dan met de methoden en technieken waarmee het probleem oorspronkelijk opgelost is.

Ruimschoots voldoende redenen dus om een herontwerp van scratch niet per definitie als onzinnig af te wijzen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:55]

[djack]

Dit heeft volgens mij weinig te maken met de overheid maar is een algemeen probleem.
Projecten moeten een duidelijke scope hebben en daar mag alleen per uitzondering van afgeweken worden.
Eens een project een duidelijke scope en leiding heeft dan is de slaagkans voor het project in 1 trek een pak groter, pas op het is nog geen recept voor succes....

Het probleem bij de overheid stelt hem volgens mij bij de verkiezingen. Nieuwe regering nieuwe wensen en dus aanpassingen aan scopes van lopende projecten... en tja zoals hier boven gezegd ... aanpassingen in scopes is een blok aan elk project.

Het belastings systeem tja dat is initieel volgens mij verkeerd uitgedacht. Als je aan zo een project begint weet je vanaf moment 1 al dat het een zeeeeeeeeeer flexiebel systeem moet zijn op vlak van bereken enzo ... dus die stukken zouden modulair moeten zijn zodat niet elke aanpassing een nieuwe infra nodig heeft.
Maar flexiebel en deftige software is meestal tegenspraak...

[n4m3l355]

Het is wel zo dat overheden bekend staan om het verspillen van tijd en geld aangezien het voor een hen vaak er niet aan toe doet. Iets wat in het bedrijfsleven misschien ook voorkomt maar toch wel in mindere mate. Maar juist omdat bij de overheid maar zelde koppen rollen is men ook minder geneigd voorzichtig om te gaan.
Om er eens nummertjes tegenaan te gooien, jaarlijks wordt er dus pp 187 euro omgezet in een nutteloos product. Beetje om van te imo. En ik vraag me af van de successen in heoverre dit wel successen zijn. Zelde kom ik een website vd overheid tegen die logisch is.

[jasperwillem]

De website van de IB groep ben ik zeer over te spreken.

Alleen toen DigID om de hoek kwam kijken en accounts gemerged moesten worden werd het slechter.

[Verwijderd]

De Belgische overheid heeft net hetzelfde probleem en bij ons moeten de verkiezingen nog komen.

Het grootste probleem is de uitzonderingen. Het is toch veel sneller en goedkoper om de uitzonderingen te bannen.

I simplicity

[Verwijderd]

@Kinushi:

Hij bedoelt dat het probleem is dat er iedere 4 jaar verkiezingen zijn, dit zorgt er eigenlijk automatisch al voor dat een project met een looptijd langer dan 4 jaar bijna geen kans van slagen heeft.

[L3TUC3]

Och, ik neem aan dat ambtenaren uit verantwoordelijke ministeries het grootste deel van de uitbesteding controleren en niet perse de minister zelf.

Als er eens een project geschrapt wordt komt de redenering denk ik voornamelijk uit het budgettaire vlak en niet direct uit de besluitvormende.

Wie regelen dit soort IT zaken eigenlijk bij de overheid? Misschien tijd voor een nieuwe ministerspost?

[bouwfraude]

De ibgroep bestaat inmiddels al wat langer, maar toen de stufi net werd ingevoerd was het daar ook een groot drama.
Stelletje prutsers van volmac.

(oops verkeerde thread)

[Verwijderd]

wacht even.... lees ik nou goed dat een systeem om huursubsidie toe te wijzen VIJFTIG miljoen euro kost? Er zijn +/- 1.000.000 mensen met huursubsidie. Dit betekent dat er per persoon 50 euro aan software geschreven wordt.

En let wel: we hebben het hier niet over software waar jarenlang research voor nodig is. In principe zou iedere VMBO stagair met visual basic en een kopietje van het orginele formulier dit in een weekeindje in elkaar moeten kunnen flansen. VIJFTIG miljoen voor wat kleuterklas niveau software. Ik weet nu iig wel waar al die dikke leasebakken van betaald worden.

Kunnen ze mij niet even bellen volgende keer, want ik doe het wel voor de helft en zorg dan ook nog dat het echt goed werkt

[Cameleon73]

Laat ze mij maar bellen -- ik doe 't voor een kwart

[EdwinG]

Met
- Eisen die van te voren niet duidelijk zijn gemaakt?
- Steeds veranderende eisen?
- Eventueel koppeling met andere applicaties?
- Support?

Ik geef het je te doen

Niet te vergeten dat van het bedrag
- BTW
- Inkomstenbelasting
- Loonbelasting
- Zorgtoeslag
- etc
af worden gehaald voordat de werknemers er uiteindelijk iets van zien.

[darkphoenix]

Maar er word wel werk door gecreëerd!
Je moet positief blijven.

Edit: Mensen ik was heel sarcastisch,Natuurlijk is dit een zeer ernstig probleem. Maar jammer genoeg zal dit toch wel altijd zo blijven omdat onze neuzen nou eenmaal niet dezelfde kant opwijzen en het liefst op ons zelf gericht zijn.

[Superstoned]

Da's een dom argument. Als het geld niet zo verspilt werd, zou het uitgegeven kunnen worden aan NUTTIGE dingen (en net zo goed banen opleveren).

(miste ik hier de irony?)

Anyway, een goede stap voor veel gemeenten zou meer samenwerking zijn. En de overheid moet voor meer concurentie en markwerking zorgen, de meeste software word door een paar bedrijven aangelevert. Tegen top-prijzen... Wat mij betreft zou de overheid alleen nog GPL software mogen gebruiken, dan krijg je in elk geval concurentie, samenwerking, lagere prijzen en betere service. Dat de huidige situatie beroerd is lijkt me onderhand wel voldoende aangetoond (ik loop ook regelmatig bij gemeentelijke IT afdelingen rond - doffe ellende. Oude bestanden die ze niet meer kunnen openen, proprietary databases en applicaties waar ze aan vast zitten... En bij bedrijven is het niet eens veel minder erg).

[Rhapsody]

Dan zal je salaris ook wel een duikvlucht nemen.

[Verwijderd]

Wat is belangrijker werk houden en kwaliteit leveren of je salaris kunstmatig hoog houden?

Als het salaris de enigste drijfveer zal je baan waarschijnlijk uiteindelijk geoutsouced worden. IMO ook helemaal terecht.

[ijdod]

ik zie de link tussen salaris als drijfveer en outsourcing eerlijk gezegd niet helemaal.

[Verwijderd]

Wat mij betreft zou de overheid alleen nog GPL software mogen gebruiken, dan krijg je in elk geval concurentie, samenwerking, lagere prijzen en betere service.

Dit zal de beloning stimuleren, men levert een produkt die niet afhankelijk is van de leverancier die allerlei nukken in hun formaat of protocol kunnen stoppen, waardoor de klant meerdere mogelijkheden heeft om het te kunnen gebruiken.

De klant behoeft geen extra tooling te gaan gebruiken om de nukken te benaderen/bewerken en zal hierdoor enthousiaster worden, wat meer werk zal opleveren en hiervoor belonen.

Denk dat men meer zal genereren dan wanneer men door zal gaan op de weg die nu ingeslagen wordt.

[sariel]

Ik wil niet al te lullig klinken...maar mijn salaris wil ik wel op dit niveau houden, of graag hoger. anders kan ik zeker fluiten naar een eigen huisje.

[Olaf van der Spek]

Je moet positief blijven.

Daar is toch niks positiefs aan? Werk is geen doel op zich!

[RobzQ]

Voor de Nederlandse overheid is het creeeren van werkgelegenheid toch echt een vrij serieuze zaak.

[Verwijderd]

'k vind 't wel een goeie opmerking, alleen die andere kant is ook van belang.

[GENETX]

Helaas is een uitkering voor de overheid goedkoper als ICT-ers aan het werk zetten

[P5ycho]

Zodra een plan uitgewerkt is moet de boel gewoon afgemaakt worden zoals gepland met minimale veranderingen. eerst een werkend systeem op tafel, en dan mogen de politici weer een lijst met aanpassingen aandragen. Als je halverwege een ontwikkelingsproces ineens flink gaat hakken in het eisenpakket dan kun je er dodner op zeggen dat de hele ellende uiteindelijk als een kaartenhuis in mekaar dondert. Alles staat of valt met een goed gedefinieerd eisenpakket en plan van aanpak.

[Ook al Bezet]

Sinds wanneer trekken politicie zich ook maar iets aan van de praktijk bij het beleid maken? Kijk naar het onerwijs. De ene hervorming is nog nauwelijks ingevoerd of hòp daar komt de volgende alweer.

[PHiXioN]

Er zijn hiervoor denk ik verschillende oorzaken:

1. Altijd willen bezuinigen en uitgaan van de meest optimistische budgetramingen, dus of gebrekkige rotzooi krijgen of duurder uit zijn. (ook een probleem in het bedrijfsleven)

2. Men spreekt van 1 overheid, maar in de werkelijkheid zijn het verschillende organisaties die allemaal iets anders willen en ook allemaal inspraak hebben.

3. Besluitvormers hebben geen verstand van de requirements.

4. Besluitvormers hebben geen verstand van IT.

[Verwijderd]

5. Bouwers zijn te optimisch qua offerte en leveren het altijd te laat op en onderhoud blijkt altijd duurder te zijn dan geraamd. (Want ze hebben de klus al voor een te laag bedrag aangenomen maar moeten toch op een of andere manier aan hun winst komen.)

6. Bouwers zijn altijd te laat met het doorgeven dat het project toch uit gaat lopen en dan mag het voetvolk maar weer overuren draaien om toch die deadline te halen. En vooral het skippen van goed en afdoende testen.

[PHiXioN]

Punt 5. is volgens mij een gevolgt van oorzaak 1., bij een realistische raming van het budget is er altijd wel een concurrent met een optimistischer kostenplaatje, die dan de klus krijgt.

[denkster]

Ambtenaren weten dat ze het langst een baan hebben en het hoogst komen als ze geen besluiten nemen.
Want als een ambtenaar een besluit neemt kan hij daarop kritiek krijgen.
En dat is einde carrière, in Nederland.
Dus ambtenaren stellen elk besluit eindeloos uit.
En dat geeft eindeloze vertraging.
Terwijl de kosten van de detacheerder doorlopen.
Geeft niet of het miljoenen kost, de ambtenaar treft geen blaam, want hij doet niets.
Ik heb dat meegemaakt bij Min. v. Sociale zaken en Min. v. Justitie.
Walgelijk.

[merethan]

Aan wat ik allemaal bij bedrijven heb gezien en mee krijg op school zie ik ook dat mensen dingen graag veel te ingewikkeld maken.

[tERRiON]

Mmmm... Het wordt als "grappig" gemodereerd terwijl het feitelijk diep triest is. Hoe vaak zie je niet van die totaal nutteloze "extraatjes" in een programma die niets toevoegt wel gezellig meedraait en met een beetje pech je systeem nog instabiel maakt ook.

Zo snap ik bijvoorbeeld niet waarom Adobe Reader (voorheen de Acrobat Reader) zo'n enorm gedrocht heeft moeten worden. Als je een PDF wilt openen zakt het licht in de straat bijna weg omdat Adobe Reader wordt gestart. En zo zijn er nog véél meer voorbeelden...

Ik ken ook software waar ze zo'n enorm rigide "beveiliging" op hebben gezet dat het gewoon niet meer te onderhouden is. Harddisk stuk? Huur maar iemand in voor 2 a 3 dagen om het opnieuw te installeren. Netwerkkaart stuk? Idem. Mobo stuk? Wederom... Huur maar iemand anders in. De updates kunnen alleen worden gedownload als je in een bepaalde (vooraf doorgegeven) IP-reeks valt. Val je in een andere IP-reeks, bel de leverancier maar... Het pakket (als ik me niet vergis van een aantal duizenden euro's) was al gekocht voordat de IT-club er naar kon kijken, anders was het waarschijnlijk niet eens aangeschaft.

Het kan wel heel stoer zijn om alles toe te passen wat je weet, maar persoonlijk vind ik het veel stoerder wanneer je alleen dat toepast wat relevant is voor de applicatie.

[Ahrnuld]

inderdaad, ik sta ook steeds minder positief tegenover mijn 'collega-programmeurs' die geavanceerde code belangrijker vinden dan of iets nu werkelijk het probleem oplost. (en de commerciële kant ervan)

Maar dat heb je, als je het vak reserveert voor mensen die exacte vakken kiezen op school. (softwareontwikkeling is wiskunde? ja daag).

[IntToStr]

Ik krijg nog wel eens wat mee over hoe de "geweldige" comunnicatie op dit gebied tussen managers en de mensen die "er iets van zouden moeten weten". Daardoor sta ik hier ook helemaal niet van te kijken helaas.

Zou dit bericht ook enigszins samenhangen met berichten over het tekort aan hoogopgeleide informatici?

Die professor van de TU/e heet overigens Jan Friso Groote. * IntToStr mompelt iets over: het maakt niet uit of je posititief of negatief in het nieuws bent, als je naam maar goed geschreven staat...

[Verwijderd]

Ik verwonder me telkens weer dat er absurde budgetten vrij gemaakt worden voor software en computers. Terwijl bijvoorbeeld voor de meeste andere bedrijfsmiddelen ieder "dubbeltje" tig keer opgedraaid wordt.

De Betuwelijn is een schandaal "terecht IMO" maar de software uitgaven niet, wat het IMO ook zou moeten zijn.