Hoofdcategorieën

'Politiek te ingewikkeld voor computers Belastingdienst'

Door Mick de Neeve, zondag 2 maart 2008 17:42, views: 26.445

De Belastingdienst wil dat het kabinet terughoudend is met nieuw beleid dat de fiscus moet uitvoeren. Naar verluidt zijn ingewikkelde politieke wensen een van de redenen voor recente problemen met de computersystemen van de dienst.

Volgens staatssecretaris Jan Kees de Jager van Financiën heeft de fiscus hem met name laten weten dat de plannen voor de AOW-heffing voor vermogende 65-plussers en de bonus voor ouderen die blijven werken - wat in 2011 moet worden ingevoerd - te ingewikkeld zijn om door de dienst te worden uitgevoerd. Ook met het innen van de kilometerheffing wil De Jager de Belastingdienst niet opzadelen, zo heeft de bewindsman in De Telegraaf gezegd.

belastingbabe De Jager benadrukt dat hij niet wil zeggen dat de fiscus helemaal geen nieuw beleid meer moet gaan uitvoeren, maar hij wil zich ervan verzekeren dat dit niet leidt tot "ingewikkelde regels." De Belastingdienst wil hooguit een adviserende rol op zich nemen over hoe de kilometerheffing het beste kan worden geïnd. De dienst past er echter voor om zonder meer de politieke wensen uit Den Haag uit te gaan voeren, zo is de staatssecretaris te kennen gegeven.

De uitlatingen van De Jager volgen op kritiek die medio vorig jaar werd geuit op automatiseringsprojecten van de overheid. Steeds veranderende wensen vanuit politiek Den Haag zouden ertoe leiden dat - soms nog in ontwikkeling zijnde - computersystemen bij de overheid gebreken gingen vertonen, niet in gebruik werden genomen of aan de kant moesten worden gezet. Dat laatste gebeurde met een vijftig miljoen euro kostend systeem van de fiscus voor het toekennen van huur- en zorgtoeslag. De desbetreffende software was door het grote aantal regels en uitzonderingen nodeloos ingewikkeld geworden en zat daarom vol fouten. Voor de Algemene Rekenkamer was dit een van de redenen om de ict-aanbestedingen van de overheid te gaan onderzoeken.

Belastingdienst blauwe envelop Afgelopen week werd bekend dat door een computerfout bij de Belastingdienst circa 730.000 digitale aangiftes over 2007 onbruikbaar waren geworden. Staatssecretaris De Jager kan nieuwe incidenten niet uitsluiten, en zegt dat het nog zeker vijf tot tien jaar zal duren voor alle gewenste verbeteringen in de it-infrastructuur van de fiscus zijn doorgevoerd. In 2009 zal er een nieuw en sneller computersysteem bij de Belastingdienst operationeel zijn voor het uitbetalen van toeslagen, zo belooft de bewindsman.

Volgende 19:25
Vorige 16:00

Reacties

«  1  2  3  4  »

In 2009 zal er een nieuw en sneller computersysteem bij de Belastingdienst operationeel zijn voor het uitbetalen van toeslagen, zo belooft de bewindsman.
We hebben als landgenoten zijnde natuurlijk weinig tot geen inzicht in wat er zich allemaal afspeelt binnen de Belastingdienst qua techniek en software en qua problematiek. Dus wat de Belastingdienst ook zegt, ze kunnen ons natuurlijk alles wijs maken. Zou best wel eens willen weten wat er nou allemaal aan de hand is en hoe ingewikkeld de problemen zijn.

Ik heb nooit aan belastingsystemen gewerkt, maar wel aan systemen in de sfeer van sociale verzekeringen, en daar is net zoiets aan de hand. Een enorm oerwoud aan regels en uitzonderingen, en vooral wijzigingen die op veel te korte termijn moeten worden doorgevoerd. Dat soort systemen is zo ingewikkeld, en het aantal mogelijke situaties die je moet testen zo groot, dat je voor de testfase vaak al maanden uit moet trekken. Als dan een wetswijziging dan in oktober wordt vastgesteld met als ingang 1 januari ben je bij voorbaat kansloos.

Dat er een fout sluipt in de software is tot daar aan toe, maar als je zo enorm stom bent om de binnenkomende gegevens direct te verwerken en niet eerst as-is op te slaan zodat je ze, als een fout wordt ontdekt, gewoon opnieuw kunt verwerken met verbeterde software zonder dat de burger daarvoor op hoeft te draaien, snap je gewoon weinig van software engineering.

Dat het proces niet goed is ingericht is duidelijk, maar veel interessanter is het hoe die afweging uiteindelijk gemaakt is om zonder goed proces live te gaan. Vermoedelijk heeft het gemiddelde kamerlid nog nooit gesproken met de it-ers die uiteindelijk hun product moeten maken; daar zitten ongetwijfeld meerdere lagen tussen. De vraag is dan hoe de opdrachtgever duidelijk kan worden gemaakt dat een fraaie feature ten kost gaat van het proces, of dat het product klaar is maar het proces niet, en wat de risico's daarvan zullen zijn. Met dergelijke zwaar gepoliticeerde mega-projecten is daar doorgaans weinig toe. En als dan de opdrachtgever weinig van dergelijke projectdynamiek begrijpt, dan wordt het een lastig verhaal.

Maar gelukkig zijn er nog altijd die IT-ers, waarvan de algemene veronderstelling is dat ze overbetaald zijn, die je de schuld kunt geven. Het is goed te zien dat De Jager lijkt te snappen dat het probleem subtieler is dan slechts een domme fout.

Dat komt allemaal door de politiek die binnen de tweede kamer afspreekt dat er binnnen bijvoorbeeld drie maanden een wet moet zijn en uitvoerbaar moet zijn voor een bepaald 'probleem'. De belastingdienst moet dat dan maar weer als de donder verwerken in hun systemen, zonder dat er dus tijd is om goed te testen of om het goed binnen het geheel te laten passen. Zo is er al tientallen jaren hapsnap werk verricht en gaat het dus steeds meer op een spaggetti lijken.

Je zou ook denken het als volgt verwerkt wordt:

gebruiker -> verstuurd gegevens -> gegevens worden opgeslagen (database).
Gegevens inlezen -> verwerken -> controle op gegevens -> opslaan van gegevens.

Op zich heb je dan nog geen as-is opslag nodig maar zou het bij controle op gegevens de fout al voorkomen kunnen worden als het daar fout gaat blijven de gegevens gewoon in originele staat.

Maar laten we eerlijk zijn het is een complex verhaal en door die haastige wijzigingen dan krijg je vaak ad-hoc situaties waarbij een testfase vaak te weinig tijd heeft voor alle situaties en dus aan komt op brakkig software.

Het probleem zit hier bij de overheid die de regels te haastig wijzigen met een onrealistische implementatie periode en daardoor een goed proces in de weg staat.
Aan de andere kant zou de ICT gewoon steviger op de overheid moeten benadrukken en aangeven dat het op die manier onhaalbaar is om de wijzigingen door te voeren en goed uitleg geven van hoe en waarom.

"geen as-is"? Zelf zeg je: "gegevens worden opgeslagen (database)."
Daar is je "as-is"!

"Aan de andere kant zou de ICT gewoon steviger op de overheid moeten benadrukken en aangeven dat het op die manier onhaalbaar is om de wijzigingen door te voeren en goed uitleg geven van hoe en waarom."
In de praktijk wordt een bedrijf ingehuurd om de nieuwe software te maken. Dit bedrijf zegt geen 'nee' want ze zullen er aan gaan verdienen - het is hun brood. Daarbij komt dat die bedrijven achteraf zelden of nooit verantwoordelijkheid hoeven af te leggen. Vaak juist in tegenstelling: 't bedrijf krijgt ook de volgende opdracht.
Zo lang de ICT-bedrijven er maar geld aan verdienen zonder verantwoordelijkheid te hoeven afleggen, is er echt geen ICT-bedrijf die gaat piepen dat 't onhaalbaar is. Ze zullen alleen zeggen dat 't veel méér gaat kosten als er nieuwe eisen komen.

In mijn ogen niet. De gebruiker stuurt een blok data door en als je dat in een database inleest ga je de data al interpreteren. Als er dan iets fout gaat kun je niet terug naar je originele rauwe data, die moet je dus eerst opslaan en eventueel backuppen.

Hoe zo? Je kunt in een database ook raw data in binaire vorm kwijt! Pas op een later tijdstip ga je de ruwe data omzetten naar bruikbare gegevens.
En zoals 'kimborntobewild' al zei: de binnenkomende data in een database opslaan is wél 'as-is' !

Dus niet. Als jij een tekstveld "02032008" binnenkrijgt en je stopt dat gegeven in een databaseveld wat van het type datum is dan heb je al een conversie toegepast en is je data niet meer "as is".

Ze moeten gewoon beter gaan werken. Bij de belastingdienst zitten een hoop IT'ers die gewoon niet creatief denken of onder de maat presteren. Die verzieken het niet alleen voor al die IT'ers die wel goed werk leveren, maar ook voor de rest van de bevolking.

Het is nog niet zo heel lang geleden dat men in Amersfoort niet kon zien of een betaling in Apeldoorn verwerkt was. Want er was geen communicatie tussen belastingdienst A'foort en Belastingdienst A'doorn. Alle communicatie ging via fysieke dragers.

@intGod: Nou gooi je wel erg veel mensen op één hoop. Ik ken toevallig een aantal mensen die bij de ict van de belastingdienst werken, en ik kan je verzekeren dat men daar zijn stinkende best doet om alles zo goed mogelijk te laten verlopen.

Naast de vele en snelle wijzigingen hebben ze daar ook te maken met de 'wet van de grote getallen'. Als er ook maar 1 promille verkeert gaat, dan raakt dat onmiddellijk duizenden burgers.

Bovendien staat de belastingdienst bij problemen altijd per definitie op de voorpagina's, terwijl, laten we zeggen b.v. een verzekeraar, gewoon even een excuus briefje rond stuurt, waarmee de kous af is.

Is het dan ZO moeilijk om je software zodanig dynamisch te ontwerpen, dat je een interface bouwt voor de gegarandeerde wetswijzigingen? In plaats van een lading if-statements erdoor te stampen?

sinds wanneer is iets, laat staan een wetswijziging, gegarandeerd in de politiek?

dat is het niet, dus los van een AI, kun je er vrijwel niet op voor-programmeren. je hobbelt altijd achter de feiten aan.

kort en bondig: JA!

omdat je van een huidige situatie moet vertrekken en een project van deze omvang al snel enkele jaren loopt voordat die huidige situatie geïmplementeerd raakt, terwijl die al zo radicaal kan zijn gewijzigd dat je weer even lang aan het patchen bent als dat je hebt ontwikkeld.

Daarom ook dat er voor heel wat diensten in onze ogen verouderde technologie gebruikt wordt, simpelweg omdat je dan enkel maar een systeem moet patchen dat je al door en door kent.

Het is toch allang mogelijk om een stel rules aan te voeren bij een programma, configuratie bestandjes... laten dit nu voor de politiek heel erg ingewikkelde configuratie bestandjes zijn. Maar het principe is mogelijk.

Als je het programma zo abstract maakt dat er gewoon rauwe data aan te voeren is, dan zal het programma door een beheerder makkelijk aan te passen zijn aan de huidige situatie.

Klinkt erg simpel, is het principe ook, uitvoering is wat ingewikkelder, op z'n minst gezegd :)

Jouw aanpak is precies het probleem. De ingewikkelde configuratie (of dat nou in de code is met if statements, of met script bestandjes) zorgt voor bugs.
Je hebt een veel flexibeler systeem nodig dat goed data door regels kan pipen.

Dit soort dingen zijn allang verkend in de software engineering dus het is belachelijk dat dit bij de belastingdienst fout gaat.

Dit soort dingen zijn allang verkend in de software engineering dus het is belachelijk dat dit bij de belastingdienst fout gaat.
je hebt het wel over situaties waarbij iedere individueele invoer (een belastingaangifte) compleet anders is dan een andere, en er spelen duizenden regels die in sommige combinaties wel en sommige niet opgaan.

zo goed als we tegenwoordig kunnen programeren, dit is toch wel heel extreem, alles is variabel, iedere stap weer.

Het mooie van die regels is dat specificaties openbaar zijn: namelijk de wetboeken. Ja het is veel, ja het is moeilijk, maar in tegenstelling tot een gemiddeld bedrijfsproject zijn de specificaties vele malen beter.

Als je in een bedrijf specs vindt die mekaar tegenspreken kun je tenminste nog overleggen hoe je ze kan aanpassen zodat de tegenstrijdigheid opgeheven wordt. Wat in wetboeken staat verander je niet zomaar, laat staan dat je wetten op je eigen manier kan gaan interpreteren.

Maar niet altijd kompleet. Als er een extra wet word aangenomen worden niet alle oude wetten gecontroleerd op compleetheid en mag je als belastingdienst zelf gaan besluiten of die -10% voor of na een andere regel geld.

Ware het niet dat de belastingdienst een systeem aan de gang houd die niet alleen is bedoeld voor particulieren (16 mln mensen) maar ook voor de Omzetbelasting, Loonbelasting, Vennootschapsbelasting,
dat die allemaal met elkaar moeten kunnen communiceren, cq
als een werkgever opgeeft dat je bij hem hebt gewerkt, dan moet dat overeenkomen met jouw aangifte,
daarnaast is de belastingdienst langzaam een sociale zekerheidsinstelling geworden die allerlei premies int en toeslagen uitbetaald omdat de overheid er van uitgaat dat daar alle informatie bekend is maar ook dat het makkelijk is om er een extra functies aan toe te voegen. Een ander groot knelpunt is dat de belastingdienst ook nog eens makkelijk moet kunnen communiceren met andere sociale instellingen als het CWI en de gemeentelijke basisadministratie.

Hierdoor ontstaat er een wirwar van oude en nieuwe machines die niet altijd even goed met elkaar kunnen communiceren ( je kunt oudere machines qua software niet altijd upgraden waardoor je met lapmiddelen gaat werken zoals het omzetten van bestanden), en om de zoveel jaar het hele park veranderen is ook onverantwoord, brengt teveel kosten met zich mee.

Het bedrag dat Jager heeft toegekend is dan ook maar een druppel op een gloeiende plaat,
eigenlijk zouden van scratch moeten beginnen en dan hebben we over 10 jaar deze discussie weer.

"Wij" werken bij de Belastingdient m.b.t. IT en dit is met afstand oorzaak no. 1.
Er wordt wel degelijk gepresteerd bij de Belastingdienst, om binnen zo min mogelijk tijd nieuwe regelgeving in te voeren in het systeem, maar noodgedwongen (tijd!) moeten er een aantal stappen extreem verkort of zelfs overgeslagen worden in het gehele proces. En met IT (in het algemeen ;) )....er is nog nooit een testcyclus geweest die niet een aantal rewrites heeft opgeleverd of botsende business processen.

De politiek denkt dat een nieuwe wet even wat code inkloppen is, regeltje vervangen met Tipex en gaan met die banaan. Ach, ze moesten eens weten...

Maar hoe kan je nu software implementeren zonder een testcyclus? het hoort er bij en is zo belangrijk in het vak. Een typefoutje in de code kan al cruciaal zijn zoals nu wel weer gebleken is.

Kerel... "druk"...
Ik weet niet of je ooit in een echt development project hebt gezeten, maar het is meestal zo dat de ene dag de klant vraagt en het de volgende week wil hebben. Ongeacht of de testfase wel of niet in die tijd past.

Het hele principe van "it's done when it's done" gaat niet echt op voor de belastingdienst. De regelgeving gaat in op een bepaalde datum, en de belastingdienst moet er dan maar voor zorgen dat het werkt. En als er in het proces dan ergens wat spaak loopt dan moeten er op het einde wat bochten afgesneden worden.

Ik erger me ook enigszins aan de reacties die stellen "hoe moeilijk kan het zijn?". Ik heb ook kort aan administratieve software gewerkt, maar wat dit soort software ingewikkelder maakt dan andere software zijn de vele uitzonderingen op de regeltjes. Dit resulteert vaak in spaghetti code, en probeer dat dan maar eens te wijzigen.

En voor die spaghetti code is er..... de rule-engine. Veel te veel ITers hobbyen maar aan met IF-statements en moeilijke code terwijl er generieke oplossingen voor generieke problemen bestaan (workflow is er nog zo eentje).

Ik kan me voorstellen dar een programma moeilijker wordt door alle regels en dergelijke, maar Als er dingen ontrafeld kunnen worden als eiwitstructuren en dergelijke moet een belastingaangifte toch ook wel lukken? Zeker voor iets wat 50 miljoen kost. Wat misschien wel een oorzaak kan zijn is dat de regels al weer anders zijn tegen de tijd dat de software klaar is. Ik snap trouwens niet dat ze alles kwijt kunnen raken, als je dat op je eigen thuis servertje overkomt ok, maar 730000 aangiftes backup je toch wel even? en dan controleren of de backup wel goed uitgevoerd is en nog maar twee keer backuppen voor de zekerheid. Niet iets wat je bijvoorbeeld even de stagaire laat doen iig :+ .

edit: misschien moeten ze een paar ps3's neerzetten, of beter nog, een soort folding@home verplicht stellen voor nedrlandse ps3 bezitters in plaats van snellere computers kopen ;)

[Reactie gewijzigd door jdm8]


Als er dingen ontrafeld kunnen worden als eiwitstructuren en dergelijke moet een belastingaangifte toch ook wel lukken? Zeker voor iets wat 50 miljoen kost. Wat misschien wel een oorzaak kan zijn is dat de regels al weer anders zijn tegen de tijd dat de software klaar is.
Die eiwit structuren blijven netjes hetzelfde en veranderen (meestal) niet iedere keer als je wat doet. Ze zijn op vrijdag hetzelfde als op maandag. Dat is bij de belasting wel wat anders. Bovendien merk jij het niet als dat eiwit programma 22 keer opnieuw moest worden geschreven

De ellende bij de belasting is dat de regering dingen blijft aanpassen tot en met 31 december. En dan gaat het niet om het aanpassen van een percentage, want dat los je simpelweg op door een veldje aan te passen. Maar soms zijn er dingen fundamenteel anders. Wel of niet een aftrekpost op voorwaarde dat er minimaal twee kinderen beneden de 14 gedurende maximaal 4 maanden buiten Europa zijn geweest. Maar dan alleen wel als pa een freelancer is en ma een Alfahulp. Ze kunnen dus niet echt testen. Losse stukjes wel...maar het geheel niet. Dat kan dan ook pas na 1 januari. En dat loopt dan wel eens mis. Eigenlijk ben ik verbaast dat het niet veel vaker mis gaat.

Dat ze geen backup hadden is eigenlijk de enige echte blunder.

[Reactie gewijzigd door Ortep]


Waarschijnlijk hadden ze wel backups maar is er gewoon iets verkeerd gegaan waardoor de informatie uberhaupt al verkeerd binnenkwam (in de vorm van: een of andere debug waarde vergeten om te schakelen of iets dergelijks). Want inderdaad zoals je zei: de belastingdienst krijgt zo ongeveer geen tijd om het geheel te testen. Alle kleine blokjes van het programma zullen dan wel werken, maar als uiteindelijk ergens een globale switch vergeten wordt om om te zetten (wat normaal gesproken natuurlijk bij een simpele testsessie snel achterhaald had kunnen worden), dan heeft het natuurlijk weinig zin.

Eigenlijk is dit de zoveelste typische overheidsblunder: de mensen die de regeltjes opstellen hebben geen weet van de praktijk en stellen dus alles vanuit een of ander theoretisch oogpunt op: m.a.w.: in theorie als alle bouwblokjes er liggen, en alles wordt op 31 december in elkaar gezet, dan werkt het gewoon op 1 januari. Helaas is vaak de praktijk iets weerbarstiger dan simpelweg wat blokjes in elkaar duwen, daar houdt de overheid totaal geen rekening mee lijkt het. Misschien moet de belastingdienst ook maar eens een featurefreeze voorstellen bij de overheid.

Dat ze geen backup hadden is eigenlijk de enige echte blunder.
en daarmee doe je zelf het verhaal over moeilijk te implementeren regels teniet.
het is ook niet de eerste keer dat bdienst gegevens kwijt is geraakt

De belastingdienst is echt niet achterlijk hoor. Die backup is er echt wel. De boel is gewoon niet goed binnen gekomen. Dan kan je daar wel backups van hebben maar daar heb je helemaal niks aan.

Dat is een heel interessante stelling. Is er in de tussentijd een update van het aangifteprogramma geweest?

Geen idee. Maar je denkt zelf toch niet dat een organisatie zoals de BD helemaal geen backups maakt :P

zelfs bij de grotere organisaties gaat wat fout. Heb het meegemaakt dat braaf de tapes gewisseld werden, maar nooit gecontroleerd. Gevolg: 3 maanden data kwijt.

Geheel juist,

de recente problemen zijn ontstaan door geen backups of een niet voldoende geteste backup-procedure, kortom amateurisme van het meest bedroevende niveau.
Persoonlijk ben ik jarenlang als adviseur, en projectmanager in de IT-branche werkzaam geweest, dat in het bedrijfsleven het meeste goed gaat en dat bij overheidsinstellingen, met name bij de belastingsdienst, grove fouten worden gemaakt, is een logisch gevolg van het totale gebrek aan duskundige leiding en begeleiding aldaar. Het was mede een van de redenen dat ik persoonlijk, en vele professionele automatiseerders met mij, niet meer voor de Nederlandse oveheid wilde werken.

Stel de server die alles ontvangt en naar de database toesluist heeft een foutje in de datum notatie en neemt de tijd over als datum. Dan kan je backuppen wat je wilt maar de datastroom is kapot. Natuurlijk hadden ze de ruwe data moeten backuppen maar dan kan je weer geen foutmeldingen naar de gebruiker sturen als er ongeldige waardes ingevuld worden.

Naast het feit dat ik zo'n kleine fout (en dan 730.000 keer) gemaakt word en ben ik het je eens dat het een teken van amateurisme of erger nog arrogantie is.

Inderdaad, arrogantie is ook op z'n plaats. Niet geteste backup-procedures is iets wat totaal niet in de professionele IT-sector past.
Stel dat iemand een even stomme fout maakt in zijn belastingaangifte dan kan die persoon dat bekopen met vervolging en minimaal 200 % boete ( er is in zo'n geval immers sprake van grove nalatigheid ).
De minimale consequentie zou moeten zijn: alle verantwoordelijken, inclusief minister, ontslaan en nu maar eens zonder de gebruikelijke gouden handdruk.

Probleem is dat veel natuurlijke dingen erg logies in elkaar zitten waardoor deze een stuk makkelijker zijn te automatiseren! In de meeste gevallen is het gewoon wiskundig te onderbouwen!

De overheid en veel dingen uit hun stal als wetgeving, boekhoud regels en dergelijken hebben geen wiskundige fundering maar een politieke fundering vol met uitzonderingen en andere ellende. En daar kan je flink op kapot lopen....

Overheden zijn ook politiek gefundeerd en nooit wiskundig :P
Maar een beetje fuzzy logic zou hier geen kwaad kunnen dat weet ik wel.
fuzzy is het wel, logic nog niet :P

PS3's zijn een lachertje vergeleken met een mainframe. Het gaat hiet ook niet om zozeer om rekenkracht die het belangrijkste is maar om het verwerken van enorme hoeveelheden gegevens.

Het valt me op dat veel mensen hier redeneren vanuit een thuis/kleinbedrijf situatie. In een echt groot bedrijf als een Bank/Verzekeraar of in dit geval de Belastingdienst spelen zaken die vele malen grootschaliger en complexer zijn dan veel mensen zich kunnen voorstellen.

[Reactie gewijzigd door erikdenv]


Feit blijft dat een goed lopende organisatie binnen een paar jaar verworden is tot een van de meest lachwekkende overheidsinstellingen. Vooral als de leiding de problemen in allerlei interviews blijft ontkennen of probeert te verhullen in vage management speak, is het tijd dat de complete leiding een bijdrage levert aan het halen van de doelstelling van dit kabinet om de grootte van het ambtenaren apparaat drastisch te verkleinen.

Dus jij wil graag dat jouw belastinggegevens bij jouw buren worden verwerkt?
Of wacht even: ze worden verwerkt bij net diegene waar je niet mee op kan schieten. En laat die nou net even de gegevens in de cache terug kunnen vinden omdat hij op tijd was!
Al je gegevens op straat.
Leuker kunnen we het niet maken, wel openbaarder!

Bedrijven hebben natuurlijk geen last van de regelzucht in Den Haag... 8)7

Ik vermoed dat dit weggemod gaat worden, maar je raakt hier dus wel een gevoelige snaar. De belastingdienst kan blijkbaar simpelweg zeggen dat het systeem het niet aankan, terwijl bedrijven zich maar moeten aanpassen.

Ik heb zelf een klein bedrijf, dus het valt te overzien, maar ook ik word gek van de regels die telkens veranderen. Ondernemend NL wordt net zo gek van Den Haag als de belastingdienst. Wat dat betreft wel goed dat ze ook een keer op hun 'bek' gaan.

In mindere mate. Wij hebben er bij BCICT (belastingdienst) last van dat een complex systeem ontwikkeld moet worden maar dat de specs continu gewijzigd worden. Op die manier werk je fouten in de hand.
Voorbeeld is de kindertoeslag. Wat de politiek wilde was niet haalbaar per 2008, dan maar per 2009 maar men wil wel een tijdelijke oplossing per 2008. Zo doe je dubbel werk ter wijl je je (mijns inziens) beter kunt concentreren op 1 goed syteem dat misschien iets langer duurt.

ja heel mooi maar daar trek je geen stemmen mee en met de korte levensduur van de kabinetten balkenende moet je als politike party wel heel snel een score maken anders gaat het mis bij de volgende ronde

Aan de reactie van erikdenv wil ik nog toevoegen dat wij gewone burgers niet moeten denken dat alle regels die IT programmeurs aan het verwerken zijn op de voorkant van het dagblad staan. Er werken alleen al bij het Ministerie van Financien tientallen adviseurs en ambtenaren die voor allerlei bijzondere en speciale uitzonderingen regels bedenken (die ook zeker nodig zijn) en die vervolgens weer moeten worden uitgelegd aan de programmeurs die er vervolgens weer mee aan de slag gaan.

Daarbij stelt 4play ook heel goed dat het gewone stemvolk wel wat wil zien veranderen (hoe het ook al zijn, tevreden al de meerderheid nooit zijn, was nooit zo, is niet zo en word nooit zo). Maar die ene zin die bijvoorbeeld de mp brult op tv houd op zichzelf niet alleen tientallen waarden in, maar zorgt er ook voor dat er groot gedeelte van het hele scala aan regels op nieuw doorgelicht moet worden, om te kijken of die nog wel juist aansluiten of van toepassing zijn.

Nu kun je aan zo een complex systeem alleen voor de controle van de waarden natuurlijk veel IT'ers inzetten die elk een eigen gebied krijgen toegewezen. Maar hoe complexer hoe meer overlopend de waarden zijn, hoe langer het allemaal duurt.

Het hele bureaucratie systeem gaat ons ook zeker op dit gebied opbreken maar afschaffen (in een korte tijd) is niet mogelijk. Er zullen teveel mazen in het net ontstaan en nog veel meer fouten voorkomen.

Interresant punt. Een vergelijking met een grote verzekeraar of een bank. Ik heb het idee dat die hun zaken doorgaans beter op orde hebben. De complexiteit van hun administratie lijkt me ongeveer vergelijkbaar (ik ben echter geen expert), maar toch lukt het hun om die op een juiste en effectieve manier bij te houden.
Het echte probleem, en daar is iedereen het volgens mij wel over eens, is denk ik combinatie van 1) de verwachting van de overheid dat de belastingdienst alles op korte termijn door kan voeren en 2) gebrek aan tijd (of geld) bij de belastingdienst om continue wijzigingen door te voeren.

Anderzijds, de politiek is ook begrijpelijk, zij willen graag hun beleid uitvoeren. Het proces zou daarin geen belemmerende rol mogen spelen. De belastingdienst zou er in dat opzicht misschien goed aan doen om abstracter systeem te ontwikkelen waarin je regels gemakkelijker door kan voeren vergeleken met het huidige systeem. Dan hoef je alleen nog aan de politiek te communiceren dat de invoeringshorizon voordat het systeem af is op 2 jaar ligt.

Ik ben overigens een van 730.000 die het opnieuw mag doen :) helden zijn het :)

De complexiteit van hun administratie lijkt me ongeveer vergelijkbaar (ik ben echter geen expert), maar toch lukt het hun om die op een juiste en effectieve manier bij te houden.

Omdat als ze het niet doen, al hun klanten weglopen, werknemers hun baan verliezen en investeerders hun geld. Da's een vrij effectieve prikkel om je best te doen. Er is geen concurrent voor de belastingdienst (is natuurlijk ook onmogelijk). Niemand verliest zijn baan (overheids CAO, etc). Financiele gevolgen zijn voor alle belastingbetalers. Het enige wat er bij falen gedaan kan worden kan doen is de bestaande organisatie verbeteren - er is nou eenmaal geen alternatief.

[Reactie gewijzigd door Dreamvoid]


Ik ben overigens een van 730.000 die het opnieuw mag doen :)
Het grappige is dat je wettelijk gezien het helemaal niet opnieuw aangifte hoeft te doen.

Je hebt aan je wettelijke plicht voldaan door aangifte te doen. Dat de belastingdienst vervolgens de aangifte kwijt is, is niet jouw zorg.

Zodra dit bekend wordt bij het grotere publiek kan dit gegeven interessant worden. Ik las in de krant dat de eerste advocaten al hun messen aan het slijpen zijn.

Denk dat dat messen slijpen wel mee valt. Uiteindelijk volgt uit de wet ook dat de inspecteur de aanslag vast stelt en als hij de gegevens niet heeft, dan gaat hij dus zelf een aanslag "verzinnen". Dat doen hij dan wel op een dusdanige manier dat er een leuke aanslag uitkomt. Dan kan die advocaat bezwaar maken en zal hij als motivatie toch weer met de gegevens van de aangifte moeten komen. Inspecteur herziet dan de aanslag en in het beste geval krijgt de belanghebbende een kostenvergoeding van ¤ 161 voor het inroepen van de professionele bijstand van de advocaat. Meeste advocaten worden niet bepaald warm van ¤ 161 dus kans is dat factuur naar de klant veel hoger is dan de vergoeding. Dan is het toch goedkoper om hem even opnieuw op te sturen.

En als je denkt dan maak ik zelf het bezwaar en verdien ik die ¤ 161. Nee dat krijg je alleen als je professionele bijstand gebruikt. Anders krijg je niks. Kost het je dus velletje papier en wat printerinkt en postzegel voor je bezwaarschrift.

De complexiteit bij een bank lijkt me toch minstens een graadje lager, zij hoeven immers geen rekening te houden met al die uitzonderingen en speciale regeltjes. Ook zijn ze niet onderhevig aan de grillen van de politieke wil. Vaak zijn het vaststaande waardes en regels, die zijn een stuk makkelijker te integreren in de software.

Gebruiken ze daar nog MS Works ofzo?

Nee even serieus, gaat leuk worden als de belastingdienst gaat bepalen welke regelgeving de overheid mag doorvoeren.

Is er in het licht van transparantie niet meer bekend over welke systemen in gebruik zijn en welke systemen ze willen gaan gebruiken bij de belastingdienst?

Nee even serieus, gaat leuk worden als de belastingdienst gaat bepalen welke regelgeving de overheid mag doorvoeren.
Dat wordt nergens gezegt, waar het meer op neerkomt is dat de belastingdienst van de politiek verlangt dat ze hun wensen goed en duidelijk kenbaar maken, en niet met miljoenen uitzonderingen en complexe berekeningen. De complexiteit van de belastingwet maakt de uitvoering onmogelijjk en daardoor oncontrolleerbaar.
Is er in het licht van transparantie niet meer bekend over welke systemen in gebruik zijn en welke systemen ze willen gaan gebruiken bij de belastingdienst?
vast wel, ik denk alleen dat je daar niet veel wijzer van wordt, de meeste van die systemen zijn speciaal voor de belastingdienst ontwikkeld, en zullen niemand behalve insiders iets zeggen. Het enige wat je dan nog aan bruikbare informatie krijgt is het type hardware, de specs en het OS.

Ja hoor, geef de "klant" maar de schuld. Wat ik inmiddels geleerd heb is dat je altijd goed moet communiceren met de klant zodat je er achter komt wat de klant precies wil (requirements analysis) en dat het beste is om niet meteen alles uit te werken, omdat de klant mogelijkerwijs behoorlijk van gedachten kan veranderen. Het is veel beter om gewoon net zolang te gaan prototypen totdat je iets hebt wat de klant wil en dat uit te breiden met nieuwe features. Je laat steeds een demo zien van de laatste versie. Als je iets tegenkomt wat niet goed te implementeren valt, dan overleg je met de klant of de bijhorende requirements gedropt mogen worden of veranderd kunnen worden, zodat de zaak makkelijker te implementeren valt. Als dat niet kan, dan geef je aan dat je misschien meer tijd nodig hebt (omdat je bijvoorbeeld aan iets "experimenteels" moet werken) Natuurlijk geef je de moeilijkheden op tijd aan en ga je niet a la waterval te werk zodat je mogelijk pas helemaal op het eind van het proces er achter komt dat er toch zeer grote problemen zijn met de huidige implementatie.
Het kan natuurlijk heel goed zijn dat het helemaal niet anders kon. Tja, dan hadden ze maar niet zo'n scherpe deadline moet stellen of ze hadden betere SE's moeten aannemen.

helemaal mee eens. Probleem in dit specifieke geval is het woord tijd. Blijkbaar kan de regering tot 31 december aanpassingen maken in de regels maar tegelijkertijd moet de belasingaangifte wel voor 1 april binnen zijn. En moet de software dus al in januari klaar zijn! Men zou kunnen afspreken om vanaf 1 oktober bijvoorbeeld geen aanpassingen toe te staan. Of de 1 april verschuiven naar 1 juni, maar dan gaat iedereen weer zeuren dat het zo lang duurt dat ie z'n geld terug krijgt.

de politiek wil "1" nu, en morgen willen ze "2" nog steeds nu. Alleen is het verschil tussen 1 en 2 zo'n beetje het verschil tussen kernfysica en vuur maken met een vuursteen.

dat maakt een normaal ontwikkeltraject zoals jij omschrijft compleet onmogelijk. De belastingdienst heeft hier heus wel ervaring mee hoor.

[Reactie gewijzigd door arjankoole]


Ik denk dat dat (zoals hierboven ook al gezegd werd) niet te vergelijken is. Sowieso is de situatie bij de belastingdienst anders, het zijn enorme trajecten waar volgens mij heel erg veel mensen aan zitten te werken.
Ook in het bedrijfsleven gaan dit soort dingen mis: trajecten waarbij gedurende de ontwikkeling constant de (fundamentele) requirements veranderen, hebben een veel grotere kans op falen. Ik heb zelf al genoeg bedrijven meegemaakt waar projecten van meerdere miljoenen het raam uitgingen vanwege dit soort zaken.

Probleem is echter: aangezien de belastingdienst de wensen van de politiek moet opvolgen, kunnen ze niet echt anders. Helemaal de cyclus van 4 jaar in de politiek lijkt me funest: plannen die worden teruggedraaid enzo. Ik zou persoonlijk nooit bij de belastingdienst willen werken. Het zijn vast erg interessante vraagstukken en omgevingen (qua ICT), maar echt goed werk leveren is vrijwel niet mogelijk volgens mij.

De situatie die jij beschrijft is inderdaad hoe het zou moeten ja. Echter, dat gaat alleen op voor compleet nieuwe software.

De belastingdienst heeft al een enorm complex systeem, waar de klant dus elk jaar tientallen dingen (groot en klein) aan veranderd wil hebben. Als de klant dan ook nog eens aan het begin van het jaar volmondig A zegt, maar het aan het eind van het jaar sowieso B moet worden? Tja, daar kun je niet tegenop prototypen.

Zelfs al analyseer je op zo'n moment alles perfect, omschrijf je alles nog zo goed, krijg je nog zoveel handtekeningen op papierwerk waarop staat "Ja zo moet het".. Als de overheid dan plotseling een wetswijziging intrekt of geheel wijzigt, is dat al dat papier en die tijd voor niets geweest.

Je zegt wel, dan hadden ze maar niet zo'n scherpe deadline moeten stellen, maar denk je nu werkelijk dat die deadline redelijk was? Den Haag wil alles altijd per de volgende 1 januari geïmplementeerd hebben. Of de beslissing nu op 15 maart of op 30 september genomen wordt.

Ik wil hiermee niet zeggen dat de Belastingdienst hun softwareontwikkeling perfect onder de knie heeft, maar volgens mij ligt de schuld toch ook vooral bij de klant hoor. :)

edit: ik moet sneller typen, ik zie net dat hierboven al het gras voor mijn voeten is weggemaaid ;)

[Reactie gewijzigd door Cloud]


Dat het inderdaad niet vaker fout gaat verbaast mij ook...

Je praat hier nog over cobol systemen met 100.000'den regels aan code
die je niet zomaar ff omschrijft en constant moet aanpassen aan weer een of andere
politicus die weer iets leuks verzint daar in den haag....

Aan de ene kant wil je natuurlijk niet dat de software je beperkt in je ontwikkelingen maar met de snelheid waarop het nu iedere keer moet worden aangepast is het gewoon vragen om problemen...

Bron: artikel, Tweakers juli 2007

Staatssecretaris De Jager wil de situatie voor de Belastingdienst nu dus gladtrekken door de ict-taken van de fiscus naar India over te hevelen. Daar zal software worden aangekocht en callcenterpersoneel worden ingehuurd om de ambtenaren in Nederland van support te voorzien. De Jager is zelf voormalig ict-ondernemer en zegt na uitgebreid onderzoek te zijn geschrokken van de verouderde systemen die hij bij de fiscus aantrof. Overigens kan de bewindsman nog niets zeggen over de gevolgen van het uitbesteden voor het ict-personeel van de Belastingdienst.
Zou dit er iets mee te maken hebben???

Je ziet dit vaker bij grote overheidsinstellingen... DTO is ook zo'n voorbeeld...
Gebruiken ze volgens mij ook nog steeds cobol enzo.
Belangrijkste reden hiervoor is dat het uitontwikkeld en stabiel is.

Dat soort oude systemen (Cobol) zijn vaak ondanks de belabberde programmeertaal en antieke omgeving softwareontwerptechnisch goed en hebben al lang bewezen dat ze foutloos hun werk doen. Functioneerden ze slecht, dan waren ze al lang vervangen.

Vaak wordt geprobeerd ze met modern spul te vervangen. Dat moet dan al naar gelang de mode van de dag in Visual Basic, Java of .NET. De programmeurs die deze talen aantrekken zijn lang niet altijd sterinformatici en zo wordt er dan een brak systeem afgeleverd. De invoering van het systeem mislukt en het oude, goed werkende systeem draait vrolijk door.

Indien men een dergelijk oud systeem met succes wil vervangen dient men daar (A) kundige informatici bij te betrekken om een degelijk nieuw systeem op te zetten en ( B ) mensen met kennis van het oude systeem bij betrekken om te voorkomen dat het nieuwe team in valkuilen loopt waar het oude team al jaren geleden mee te maken had.

In het algemeen wil je je bij het doorlichten van een automatisering het minst op de oude systemen richten. Die zijn vaak niet de reden dat de automatisering de mist in gaat.

[Reactie gewijzigd door dmantione]


Cobol is voor vele toepassingen geen belabberde programmeertaal, het is wel oud maar niet slecht. Om grote hoeveelheden data te verstouwen en voor verslaglegging werkt het prima. Java of .net zijn hier totaal niet geschikt voor. Mainframe(z/OS), Cobol en DB2 zijn voor veel grote bedrijven de pijler van hun ICT.

Een webapplicatie kun je er natuurlijk niet in bouwen maar dat spreekt voor zich.

Nou, ik kan en zal Cobol geen goede programmeertaal noemen. Als Pascal-evangelist kan ik niet anders dan vaststellen dat er in Cobol gewoon hele slechte dingen zitten.

Maar taal en toolkit zijn verschillende dingen. De Cobol-toolkit maakt het inderdaad uitstekend voor administratieve toepassingen. Liever een goed Cobol-systeem dan een slecht .NET-systeem.

Dus ondanks mijn afkeer van Cobol ben ik het helemaal met je eens. :)

Ja, dingen overhevelen naar India zal alles oplossen 8)7

Mijn God zeg, bij veel bedrijven gaan de ogen wat dat betreft eindelijk open: personeel mag er dan een factor X goedkoper zijn, maar per saldo ben je duurder uit omdat veel werk hier gewoon opnieuw gedaan kan gaan worden omdat ze er daar niks van bakken. En dit is geen geblaat van een studentje dat ook eens een boekje heeft gelezen: het is de praktijk bij grote (high-tech) bedrijven die met outsourcing te maken hebben. De managers kijken alleen naar de korte-termijn besparingen zodat zij hun bonusje weer verdiend hebben en de architechten en engineers op de werkvloer mogen de shit opdweilen als er weer eens een mislukt project terugkomt uit India.

Laat de overheid dit soort dingen alsjeblieft niet gaan outsourcen :/

Het gaat hier alleen om de support richting de medewerkers van de Belastingdienst. De belastingbetaler krijgt hier dus helemaal niets mee te maken en de persoonlijke informatie blijft gewoon veilig binnen de Nederlandse grenzen.

B/CICT moet zich op zijn kerncompetenties richten. Als het leveren van support aan de medewerkers daar niet bij hoort, dan moet overwogen worden om het geheel te outsourcen.

Hierin geef ik de belastingdienst gelijk. We zitten nu al een x-aantal jaren met een wispelturige en door onbetrouwbare politiek/overheid. Ook zitten we al jaren opgescheept met een visieloze overheid en daardoor wordt er continue verandering op verandering doorgevoerd. Ingewikkelde administratieve belastingregels en de enorme hoeveelheid hiervan kan ik mij voorstellen dat dit geen doen is voor de belastingdienst.

In mijn ogen is een onbetrouwbare overheid een gevaar voor een land. Italie zit al jaren in dit proces en dat is niet een situatie waar wij in verzeild moeten raken. Wanneer burgers en bedrijven elke keer maar weer moeten afwachten wat het omgooien van belastingregels gaat betekenen aan het einde van het jaar, zal de portemonee op de knip gaan en verlamming treedt op...

Ook zitten we al jaren opgescheept met een visieloze overheid

Opgescheept? Zo kiezen we nou eenmaal. Elke 2, 3, 4 jaar zwaait de pendel weer door, van links naar rechts, van populistisch tot technocratisch, van gematigd tot radicaal, elke keer weer een nieuwe regering met nieuwe 'opdracht' van de kiezers. De politiek/overheid voert nou eenmaal uit wat de kiezer op dat moment denkt te willen. Waar je in UK/Duitsland/Frankrijk/VS/Spanje rustig regeringen hebt die acht jaar zitten (na herverkiezing) krijg je hier net als in Italie elke keer nieuwe coalities. Het is nou eenmaal de consequentie van het kiesstelsel (proportioneel vs first-past-the-post) dat we hebben. Het heeft zijn voordelen, het is directer democratisch en de kiezer heeft veel vaker de mogelijkheid om de politiek terug te fluiten, maar het is wel veel wispelturiger, en dat maakt lange-termijn projecten moeilijker.

'Politiek Computers te ingewikkeld voor computers politiek Belastingdienst'

Lijkt mij bij dit soort dingen dat het probleem is dat de opdrachtgever geen enkel idee heeft van de mogelijkheden en beperkingen aan de kant van degene die het moet uitvoeren. Politici zijn over het algemeen IT-technisch niet erg onderlegd, maar zij verzinnen de regels wel. Nu is bij een normale opdracht ook vaak het probleem dat de opdrachtgever geen idee heeft waar hij het over heeft (en vaak ook niet wat hij nou eigenlijk wil) maar daar heb je nog de mogelijkheid om feedback te geven en te zeggen dat dingen misschien handiger op een andere manier zouden gaan om te voorkomen dat je onmogelijke dingen moet gaan uitvoeren. Dat is door het drietrapssysteem hier onmogelijk: de politiek (de eigenlijke opdrachtgever) neemt besluiten en geeft die door aan de belastingdienst. Dat wordt dan dus eigenlijk de uitvoerende opdrachtgever die dus weer geen invloed heeft op wat nou uiteindelijk moet gebeuren, alleen een beetje op de vorm. Die moet vervolgens weer de daadwerkelijke uitvoerder(s) gaan aansturen zonder dat er veel/enige flexibiliteit mogelijk is in de oplossing van problemen. Tel daar ook nog eens bij op dat de politiek z'n wensen iedere drie seconden verandert en de boel is eigenlijk gewoon niet goed uit te voeren.

Door de aard van politiek, dat beslissingen gemaakt worden en daarna hoe dan ook maar uitgevoerd moeten worden omdat er besloten is is natuurlijk een beetje de kern van het probleem. Ik ben bang dat dat niet zomaar op te lossen valt.

Edit: kromme zinscontructies beetje recht gemaakt.

[Reactie gewijzigd door Camacha]

«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 19:25
Vorige 16:00
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: