Mislukte invoering juridisch ict-systeem kost overheid 100 miljoen euro - update

De invoering van een nieuw automatiseringssysteem bij het Ministerie van Justitie is deels mislukt en in 2011 stilletjes stopgezet, nadat er tien jaar aan was gewerkt. Er is intussen honderd miljoen euro uitgegeven aan het project.

Het Geïntegreerd Processysteem Strafrecht moest een einde maken aan de papieren strafdossiers, maar het project is slechts deels ingevoerd en blijkt nu dus in 2011 al stopgezet te zijn. Naast de mislukte invoering heeft het project ruim twee keer zo veel gekost als oorspronkelijk gepland was. Dat meldt Het Financieele Dagblad, dat beschikt over vertrouwelijke stukken waarin het project wordt geëvalueerd. De Tweede Kamer is in 2009 voor het laatst ingelicht over de voortgang van het project.

Een van de problemen tijdens de invoering was dat de eisen aan het project gedurende de ontwikkeling veranderden. Dat gebeurde diverse malen en halverwege is het project zelfs volledig herzien. Daarnaast was het gedeelde opdrachtgeverschap tussen het OM en de rechterlijke macht problematisch. Uit pilots van het project bleek bovendien dat de stabiliteit en performance van het systeem ondermaats waren, waardoor het systeem aangepast moest worden en de ontwikkeltijd almaar opliep.

In eerste instantie zou het project al begin 2004 klaar zijn. Uiteindelijk duurde het tot 2008 voordat het systeem landelijk werd uitgerold, maar dat was alleen bij het Openbaar Ministerie. De rechterlijke macht volgde een halfjaar later. Het systeem beschikte echter nog steeds niet over alle functionaliteit die met het project was beoogd. Daardoor gebruikt de rechterlijke macht het systeem lang niet voor alle zaken en blijven papieren dossiers nodig. Een koppeling met de politie, eveneens onderdeel van het oorspronkelijke projectplan, is ook nog niet gerealiseerd.

De kosten voor het project waren in eerste instantie begroot op ruim 40 miljoen euro. Door de hernieuwde aanpak halverwege het project is echter de eerste 24 miljoen euro grotendeels voor niets uitgegeven, zo wordt geconcludeerd in het evaluatierapport. In totaal heeft het project ruim 99 miljoen euro gekost. Het onderzoek werd overigens bemoeilijkt doordat het oorspronkelijke projectdossier ontbreekt en de auditdienst het moest doen met documenten uit dat dossier die via medewerkers van het OM 'uit eigen voorraad' werden verstrekt.

Update, 15:53: Het ministerie zegt in een reactie tegenover NOS dat het GPS-project is beëindigd, omdat het is ingevoerd. Het OM verwerkt alle overtredingen en 75 procent van de misdrijven met het systeem, aldus het ministerie. Ook in de rechtspraak zou er wel mee worden gewerkt.

Door Christophe van Bokhoven

26-06-2013 • 12:49

137

Reacties (137)

137
133
94
19
2
10
Wijzig sortering
Een heel mooie reactie van Equator. En zo is het natuurlijk ook.

Maar, en zou zelfs willen zeggen MAAR.

Waar ik mij vooral boos over maak is het stukje:
"Het onderzoek werd overigens bemoeilijkt doordat het oorspronkelijke projectdossier ontbreekt en de auditdienst het moest doen met documenten uit dat dossier die via medewerkers van het OM 'uit eigen voorraad' werden verstrekt"

We praten hier over 100 miljoen, niet over iets van 10 euro. Ik moet eens wagen om dit te zeggen bij een controle door de belastingdienst, als je daar bij wijze van spreken 1 btw bon niet hebt laten ze je alle hoeken van de kamer zien.

De overheid krijgt zijn inkomsten voor een groot deel uit belastingen opgebracht door het volk. Nu is het zonder kunstgrepen (heeft iemand nog wat in de la liggen of thuis) niet te controleren wat er fout is gegaan en waarom. Al was het alleen maar als leerproces en handvat voor een eventueel vervolgproject, want als ik zie dat er nu verdachten moeten worden vrijgelaten omdat het papieren dossier zoek is, is dat ook niet ideaal.

[Reactie gewijzigd door fitznl op 23 juli 2024 13:34]

Fantastisch weer de reacties van de meerderheid hier. Zonder enige kennis van zaken worden er aannames gedaan die nergens op slaan. Er wordt maar vanuit gegaan dat al het geld weer weg is.

Let wel: Natuurlijk zijn er fouten gemaakt, maar die gebeuren ook in het dagelijkse commerciele leven. Misschien niet in de grootte van 100 Miljoen, maar de meeste commerciele bedrijven hebben dan ook geen klanten van 20.000 en meer gebruikers.

Het GPS systeem was bedoeld als vervanger van de sterk verouderde voorganger. (waarvan ik tot mijn spijt moet bekennen dat ik de naam vergeten ben) Daarvoor was er al een eerder project gestrand wat circa 40 miljoen gulden heeft gekost. (de naam van dat project weet ik echt niet meer)

Helaas was het onduidelijk wat er aan processing kracht nodig was om het nieuwe GPS systeem werkend te krijgen. Er is initieel begroot dat er circa 1,5 Miljoen Euro nodig was aan hardware per arrondissement. Uiteindelijk bleek dit niet het geval. Alle hardware die er is aangeschaft zit natuurlijk in deze 100 Miljoen waar over gesproken wordt. Het feit dat deze hardware verder ingezet is voor andere systemen wordt voor het gemak even achterwege gelaten.

Het feit dat de zittende magistratuur er nog neit echt mee werkte heeft wmb vooral te maken met de afspliting van de Rechterlijke Organisatie (Waar het OM overbleef).

De koppeling met de Politie is wel degelijk gerealiseerd. Sterker nog er waren vergaande projecten waarbij de processen verbaal digitaal ondertekend via de politie/justitie service bus getransporteerd kunnen worden. De adoptie hiervan is een traag proces (want ambtenaren zijn niet gewend aan vernieuwing en andere manieren van werken) maar zou uiteindelijk een hoop operationele kosten schelen.

Helaas, het is weer geklapt. Er zijn weer fouten gemaakt, dat betreur ik, maar laten we eerlijk zijn. Alle opmerkingen van gebruikers hier dat zij het wel even regelen (de standaard reactie bij geklapte ICT projecten bij de overheid) tonen aan dat men geen idee heeft van de omvang van dergelijke systemen.
Een projectje draaien voor een bepaalde software/hardware oplossing bij de overheid is echt niet moeilijk, dat lukt de meeste bedrijven wel. Het probleem is echter dat de samenleving steeds meer verwacht van de overheid, wat koppelingen vereist tussen alle losse systemen. Deze koppelingen zijn slechts deels realiseerbaar wat er op neer komt dat men gaat vragen naar een integraal system voor alle gebruikers die met elkaar moeten samenwerken. Dan ga je in het ergste geval ministerieoverschrijdend werken en dan gaat het gewoonweg niet zoals de meeste projectleiders denken dat het zou moeten gaan. De simpelweg enorme omvang, het aantal verschillende typen gebruikers en bedrijfsprocessen die je dan moet afstemmen is niet iets wat je zomaar 'even' doet.

/ergernis.
Alle opmerkingen van gebruikers hier dat zij het wel even regelen (de standaard reactie bij geklapte ICT projecten bij de overheid) tonen aan dat men geen idee heeft van de omvang van dergelijke systemen.
Misschien moet eens de les getrokken worden om geen systemen meer te bouwen met zo'n collosale omvang dat niemand het kan begrijpen en overzien. De menselijke maat is volkomen afwezig waardoor het project een olietanker wordt met niemand aan het roer. Er zullen genoeg capabele mensen geweest zijn in het project, dat neem ik zonder meer aan, maar welk individue is in staat enige invloed uit te oefenen op zo'n monstreus project.

Echt, dit soort projecten gaat alleen lukken als het opgedeeld kan worden in stukken die voor mensen behapbaar en te begrijpen zijn. Een megalomaan project houd niemand in de hand. Dus begin bij en stukje en bouw dat langzaam uit. En refactor de boel om de zoveel tijd zodat het geen lappedeken wordt. Zelfs als je dan een project halverwege stopt heb je in elk geval de al gerealiseerde delen en is niet alles weg.

Projecten met enorme omvang waarbij ook nog eens iedereen en allemaal wat te zeggen heeft en geen mens de grandioosheid kan bevatten zijn gewoon een recept voor mislukking. Maar toch zijn er telkens weer mensen of organisaties die denken dat dit alleen voor projecten uit het verleden geld maar niet voor het eigen project.

Het is alsof iemand Windows of Linux in een project van 2 jaar zou willen bouwen. Beide zijn echter klein begonnen en pas langzaam gegroeid naar de enorm complexe producten die het nu zijn. En dat geldt voor alle succesvolle software.
Het GPS systeem was bedoeld als vervanger van de sterk verouderde voorganger. (waarvan ik tot mijn spijt moet bekennen dat ik de naam vergeten ben)
Je Bedoelt COMPAS geschreven in cobol.
Yes, die bedoel ik :)
Ik weet ook niet alle details, en projecten en zaken zijn altijd ingewikkelder dan men op het eerste gezicht zou zeggen.

Een tijdje in de ICT bij de overheid gezeten, daar heb ik o.a. gewerkt aan het project DIVOS: http://rechtennieuws.nl/3...ssiers-met-divos-2_0.html

Of dit nu hetgeen betreft wat beschreven wordt in het artikel weet ik niet.

Mijn ervaring met dit soort projecten is dat het vaak, hoe gemotiveerd mensen ook zijn, uitdraait op een puinbak, mede oorzaken hiervoor zijn al genoemd, maar er spelen zoveel factoren mee. Ik zal verder niet in details treden.
Nee, DIVOS is niet hetzelfde. DIVOS is voornamelijk het rechtspraak-proces ondersteunen, GPS voornamelijk het OM proces.
Rechtspraak heeft wel toegang tot GPS, OM niet tot DIVOS.
DIVOS haalt wel documenten via GPS binnen.
Bagetelliseer jij nou een (zoveelste) 100 miljoen faal ?
Nee, ik baggetaliseer niets. Ik weet dat er in elk (overheid) ICT project fouten wordne gemaakt. Ik wil alleen duidelijk maken dat het niet zo simpel is als menigeen denkt.
Volgens mij bagatelliseert hij niets. In vele woorden is uitgelegd wat de oorzaken kunnen zijn.

Mijn ervaring is dat dit soort projecten mislukken omdat ze te groot zijn en men vaak in een bigbang implementeert. Daarnaast hebben deze projecten last van scope creep. Stakeholders worden onvoldoende geanalyseerd en willen van alles erbij. Scope puilt uit en project loopt uit. Met alle gevolgen van dien.
Grappig :+ ik heb nog meegewerkt met dit project :)

in 2004. Documenten moesten ingescaned worden naar een DMS systeem (hummingbird als ik me niet vergis). Allen de rechters die de documenten wilde inzien konden niet overweg met het systeem. En liet het Wetenschappelijk bureau weer alles afdrukken :+

halve 2005 is toen beslissing gevallen dat voorlopig het systeem niet gebruikt zou worden. Wel zouden alle dossiers in het systeem gebracht worden, maar de papieren dossier waren leading.
Communicatie met Justitie was ook moeizaam.. te veel poortjes waar je door moest om informatie te halen.

Uiteindelijk is 1 onderdeel wel geslaagd in het project en dat is alle FAT clients vervangen voor Thin Clients en werken via Citrix.. Maar het DMS systeem was in 2004-2005 al redelijk afgeschrven. Gewoon weg omdat men niet wist hoe hiermee te werken.. Meta data die niet goed ingevuld kon worden. Features die gemaakt moesten worden konden niet of werden gestopt enz..

BTW Hummingbird DMS systeem werd door Capgemini Ordina neergezet, waarbij zij bepaalde featuresets en Meta Data systemen moesten ontwikkelen. Ook het Anomiseren van de documenten zou door het systeem gedaan moeten worden maar ook dat werkte niet.

Ik was BTW verantwoordelijk voor Biometrie en de Thin Clients, en liep ook vaak zat tegen problemen op van het DMS systeem zoals traagheid van de Remote Desktops e.d. Mail wat niet meer werkte na migratie naar DMS..

[Reactie gewijzigd door To_Tall op 23 juli 2024 13:34]

Het blijft voor overheden en grote instanties moeilijk om eindgebruikers op tijd te betrekken, al in de concept/requirementsfase. Je hebt zo al een hoop van dit soort problemen gesignaleerd ver voordat ze überhaupt optreden.
Ik zou ook wel eens een nieuwsitem willen zien over een succesvol door de overheid uitgerold ICT-project. Ik vermoed enige telegraaf-bias: nl dat alleen de sappige mislukkings-stories de voorpagina's halen en wij dus een ongenuanceerd beeld krijgen van de overheid. Dit soort items krikt de toch al overheersende 'overheid sucks'-mentaliteit naar nog grotere hoogten, en ik vraag me serieus af of dit wel helemaal terecht en gewenst is.
Telegraaf is ook een flutkrant, en met teveel macht (de leugen regeert). Echter denk ik niet dat ze dit verhaal over het mislukte IT project verdraaid hebben.

Politiek is in het geheel niet daadkrachtig, en ze besteden van alles en nog wat uit aan projectbureaus die elkaar tegenwerken door contracten en -breuken.

De grotere bedrijven lopen over ze heen met hun lobby-geld, ach als de politici maar hun baan behouden he, zeker die in de 2e kamer met hun 7k salaris?
Zoveel kost gebakken lucht en carrousels (draait op niets uit).
Nu vraag ik me af welke andere overheid-IT projecten faalden. Er zijn er ongetwijfeld nog veel meer dan dat er gepubliceerd werden, maar volgens mij worden ze een beetje actief 'verstopt' zodat we het niet te weten komen wanneer het nog relevant is.

Daarnaast snap ik niet dat de eisen/specificatie halverwege of uberhuaupt tussendoor verandert. Dat kan je als overheid toch helemaal niet meer maken? Met een trackrecord wat betreft IT projecten zou je op z'n minst verwachten dat ze er wat van leren!
Ik citeer: "Een van de problemen tijdens de invoering was dat de eisen aan het project gedurende de ontwikkeling veranderden."

Tja, bij een project met zo'n omvang moet je gewoon eerst alle specs helemaal duidelijk hebben voordat je de eerste regel code schrijft. Gewoon beginnen en zien waar het schip strandt is een garantie voor failure.

Dit is namelijk ook wat Cap Gemini de overheid (in dit geval de politie) verweet bij dat geldverslindende project, dat ze constant de specs veranderden.

Hoe meer je vooraf in kaart brengt, hoe minder verrassingen later in het traject. En het is ondoenlijk om halverwege het project van technieken te wisselen.
Cap is nou niet echt een objectieve partij hier. Het is een veel gebruikte strategie bij grote projecten om de specs zo gunstig mogelijk te interpreteren (waterdichte specs zijn zijn een sprookje) en op basis daarvan zo laag mogelijk in te schrijven. Bij iedere wijziging of verschil van interpretatie van de specs kom je vervolgens met een vet change request zodat je je marge weer op peil kan brengen. Lijkt me meer een gevalletje straatje schoonvegen.

Wijzigingen tijdens de bouw en vooral tijdens testen komen overal voor, overheid is zeker geen uitzondering. Het komt wel wat meer voor bij de overheid, de aansturing is tenslotte politiek, en dat levert niet altijd de meest rationele besluiten op.
Precies, als je als bijvoorbeeld aan een project begint waarvan de specs niet duidelijk zijn moet of er niet aan beginnen of goede afspraken maken met de klant over wijzigingen.
Dat is natuurlijk ook utopie. Aan de ene kant kan je eenvoudigweg bij zo'n monsterproject met zoveel betrokken partijen niet goed overzien wie precies welke eisen heeft. Aan de andere kant draait de wereld ook tijdens je concept en bouwfase gewoon door. De omgeving verandert dus, en daarmee de eisen aan je systeem, zeker bij de (semi-) overheid. Daar heb je te maken met veranderende wetgeving bijvoorbeeld.

Het enige wat je volgens mij kan doen, is niet de wereld in één keer willen veranderen. Hou het grove einddoel - dat de hele keten aangesloten moet gaan worden en het bruikbaar moet gaan worden voor alle type zaken - in je achterhoofd bij het werk, maar probeer dat niet in één keer te realiseren. Knip het op in kleinere deelprojecten met elk hun eigen deliverables en een relatief korte doorlooptijd. Meer agile dus, in plaats van waterfall.

Dus juist niet:
(...) bij een project met zo'n omvang moet je gewoon eerst alle specs helemaal duidelijk hebben voordat je de eerste regel code schrijft.
In plaats daarvan moet je zorgen dat je project überhaupt nooit zo'n omvang kijgt.

[Reactie gewijzigd door ATS op 23 juli 2024 13:34]

"Dus juist niet:

(...) bij een project met zo'n omvang moet je gewoon eerst alle specs helemaal duidelijk hebben voordat je de eerste regel code schrijft.

In plaats daarvan moet je zorgen dat je project überhaupt nooit zo'n omvang kijgt. "

Om te weten hoe je het project in deelprojecten kan opdelen moet je toch wel eerst snappen hoe het geheel er uit moet komen te zien. Je zult op zn minst moeten vastleggen hoe de diverse componenten gaan communiceren. Welke informatie mag/moet door welke componenten worden gehanteerd etc.
Er zijn enorm veel verbanden en afhankelijkheden die puur door de omgeving worden geschapen. Het is dan zaak om met je modules zo min mogelijk nieuwe afhankelijkheden te creeren. En dat kan alleen als je het geheel beschouwt.
De projecten waar ze dat doen, leveren nooit ook maar één regel code op, voordat ze gecanceled worden, een paar jaar na de oorspronkelijke geplande opleverdatum. De enige potentieel duidelijke specs zijn code, en dat suggereert dat je zo snel mogelijk moet beginnen met code schrijven en opleveren. Welke code? Die code die risico's verkleint en die code die waarde oplevert. Om fatsoenlijk te kunnen zien of voldaan wordt aan de specs moeten die zoveel mogelijk executeerbaar zijn (acceptance tests en unit tests). Gebruik TDD om alleen geteste code te kunnen opleveren en continue deployment om de stakeholders feedback te geven over de voortgang.
Anoniem: 69322 @SJCE26 juni 2013 17:16
De projecten waar ze dat doen, leveren nooit ook maar één regel code op, voordat ze gecanceled worden, een paar jaar na de oorspronkelijke geplande opleverdatum. De enige potentieel duidelijke specs zijn code, ...
Dit is een modieuze reactie van onervaren mensen met een te grote mond en nog beperktere kennis. Als het je zo geleerd is, geld terugvragen...meteen!

Als er ook maar iets te leren valt van een kwart eeuw in de IT is het wel dat het niet zozeer over code gaat, maar vooral over organisaties, veel data en nog meer manipulatie van die data. Code kan meestal na 10 jaar, en vaak al veel sneller de prullenbak in. De data daarentegen heeft een veel langere levensduur, net als de organisaties die er gebruik van maken. Sterker nog, de data leeft vaak nog langer dan de organisatie die de data oorspronkelijk genereerde!

Het extreme code centrisch denken dat de nieuwe ontwikkelaars van nu zo kenmerkt baart mij daarom zorgen. Veel zullen lang op een onnodig beperkt niveau blijven opereren, en misschien wel altijd door gebrek aan kennis van data en data gerelateerde standaarden. Dit is deels met agile methoden en meer mankracht te verbergen, maar niet eeuwig! Er komt een moment dat de data zonder nog meer code, buiten het originele programma om her-gebruikt moet gaan worden.

En dan komen de problemen dus bovenwater. Er zijn bedrijven die noodgedwongen met zeer langzame, onwerkbare processen werken omdat hun applicatie van 15-20 jaar terug, geschreven voor DOS allerlei beperkingen kent en onmogelijk is te vervangen. De oplossing van toen is dan te code centrisch opgezet, met een eigen niet open storage systeem en/of met gebruik van een product dat al al lang niet meer bestaat, maar destijds hip was, maar niemand nu kent.

Tja, dat was toen ook in, lekker coden...en hippe libs gebruiken. Sommige zaken veranderen blijkbaar echt niet.

Nu zegt dit alles niet per-se iets over TDD, maar wel veel over hoe wel en/of niet te ontwikkelen en met wat voor soort tools en technieken. In mijn omgeving blijkt tot nu toe iedereen die ik tegenkom vanuit een scrum hoek werkelijks niets te weten van SQLen relationele databases. Toch is dat best wel essentieel voor een goede ontwikkelaar, maar in tegenstelling tot leren gaat met zich er van afschermen met bv. het gebruik van LINQ2SQL en talloze ORMs waarvan er over 5 jaar gegarandeerd maar enkele overblijven en de rest vergeten wordt en niet sexy meer is. Standaarden en zich zorgen maken over de data....daar doen ze dus niet aan. Eenzelfde fenomeen zie je aan de web kant met javascript libraries, waar ook maar enkele zullen overleven.

[Reactie gewijzigd door Anoniem: 69322 op 23 juli 2024 13:34]

Het is me niet zo geleerd nee. Dat was meer waterval, en Z. Maar het is het resultaat van 20 jaar systemen bouwen, en aardig wat data-migraties.

De les die we dertig jaar geleden geleerd hebben, is dat je data en gedrag samen moet modelleren om een goede modularisatie te krijgen. Data kwaliteit en relationele databases blijkt in de praktijk helaas niet erg goed samen te gaan. Normaliseren doen we maar niet aan want die arme database-engine kan niet fatsoenlijk joinen. Zodra je te maken krijgt met tijd-afhankelijke waarden breekt alle tooling. Door het gebrekkige type systeem en het niet valideren van records staat er allerlei inconsistente troep in de database. Niet echt beter dan de eerdere Cobol ISAM systemen.
Anoniem: 69322 @SJCE27 juni 2013 15:11
Data en gedrag moet je inderdaad gelijktijdig modelleren, en dat kan prima met relationele databases, ik doe het dagelijks.

Het probleem is dat de kennis van relationele databases bij de meeste ontwikkelaars echt miserabel is, waardoor vergelijkbare kwaliteit in performance en data integriteit wordt behaald. Dit is echter niet de fout van die producten, maar van de ontwikkelaars!

Het gaat dan niet eens over normaliseren, maar over o.a.:

* indexes met included columns
* filtered indexes
* schemas + manipulatie
* geavanceerdere SQL, zoals window functions, cross/outer apply, inline table valued functions, enz.

Wat betreft integriteit, de meeste data-integriteit issues kun je declaratief afhandelen in een relationele database. Dit is een groot voordeel is t.o.v. een met code uitgewerkte oplossing die bovendien te gebonden is met een specifieke applicatie met een kortere levensduur dan de data.

Er zijn ook altijd wel speciale condities die met code afgehandeld zullen moeten worden. Maar dat is geen reden om niet een goede basis te leggen die meer applicatie onafhankelijk is en altijd gegarandeerd wordt afgedwongen.

Wat betreft tijd-afhankelijke waarden, daar kan ik verschillende dingen onder verstaan. Een deel ervan is in iedere geval op te lossen met goed modelleren en weer...meer kennis van zaken.

Wat betreft niet valideren van records....daar sla je in de ronde. Heb je van check constraints gehoord, of van foreign keys? Gevaarlijker is het om de data kwaliteit uitsluitend afhankelijk laten zijn van code (met bugs, gegarandeerd) die de consistentie van je database permanent en ongezien aantast. Je kunt dan ook nooit betrouwbaar buiten de specifieke applicatie code om data aanvullen omdat je anders mogelijk regels omzeilt. Een code only oplossing neigt altijd naar meer code en meer bugs na gelang de tijd.

En serieus, de type systemen in C/C++/C# zijn ook niet zaligmakend.
Ik zou juist willen stellen dat je NIET alle specs helemaal duidelijk moet hebben maar moet beginnen met het inventariseren van de epics en user stories en het hele project middels Scrum of Kanban sturen. Dat is er om juist met veranderingen aan specs om te kunnen gaan. Big Designs Up Front werken al jaren niet meer in de software development tak van sport. Eerste selectie maken van de features voor een versie 1, die gedetaileerder uitwerken en dan implementeren en opleveren, feedback van de ontwikkelcyclus meenemen in de volgende feature release of sprint.
Het is een combinatie van beiden. Als je een gebouw maakt heb je ook eerst een bestektekening/ of -lijst, toch blijkt dan bij aanvang van de bouw dat 20-30% nog niet volledig is uitgedacht en voor potentiele problemen kan zorgen. Men kijkt dan in het werk naar oplossingen, dit leidt onherroepelijk tot faalkosten, soms ook tot 20-30% van de bouwsom. Goeie architecten houden hier dan weer rekening mee in het ontwerp van het systeem.
Wat er mis gaat in al die ICT projecten van de overheid is min of meer resultaat van hetzelfde probleem, alleen komt hier dan ook nog een groot stuk incompetentie bij kijken van de zogenaamde 'regenten'. Oude grijze mannetjes die bij het OM de dienst uit maken weten geen klap van ICT noch van de mogelijkheden, voor hun is de kaartenbak de laatste referentie naar iets van een administratief systeem. De rest komt uit boekjes of via het journaal.
Dergelijke systemen worden daarnaast ook niet of slecht ontworpen, kan je direct afleiden aan die faalkosten. De beveiliging van OV chipkaart is ook een goede referentie hiervoor.

Ik denk dat scrum grote voordelen heeft, maar dat een meer technocratische aanpak van systeemarchitecten die verschillende partijen vertegenwoordigen ook wel belangrijk is. Wat ik ook sterk vermoed is dat de opdrachtgever die dit eisenpakket in eerste instantie op tafel legt, geen idee heeft waar hij eigenlijk mee bezig is. In dit geval gaat het om een juridisch systeem, maar die juristen weten zelf niet waar ze het voor nodig hebben. Dit zag je ook bij de politie. Ook belangenverstrengeling en BIAS van de architecten naar bepaalde systemen zou een rol kunnen spelen.
Tja, bij een project met zo'n omvang moet je gewoon eerst alle specs helemaal duidelijk hebben voordat je de eerste regel code schrijft. Gewoon beginnen en zien waar het schip strandt is een garantie voor failure.
Dit is onmogelijk.
Je zult veel meer moeten gaan werken ala scrum of iets dergelijks, kleine deelprojecten opleveren die steeds wat toevoegen.
Zo creëer je een modulair programma waar je sneller kan ingrijpen mochten er dingen dreigen te ontsporen. Ook kan je dan eenvoudiger inspringen op gewijzigde regelgeving en de snel veranderende ICT-wereld.
Tja, bij een project met zo'n omvang moet je gewoon eerst alle specs helemaal duidelijk hebben voordat je de eerste regel code schrijft. Gewoon beginnen en zien waar het schip strandt is een garantie voor failure.
Zo werkt dat niet. Zeker bij een groot project is dat onmogelijk. Je kunt in hoofdlijnen iets bedenken maar het detailleren moet in stukjes gedaan worden. Als je alles gaat uitdenken ben je 4 jaar bezig, daarna kun je weer opnieuw beginnen met uitdenken omdat de wereld (politiek en ICT) ongelooflijk snel veranderen. Wat jij beschrijft is een waterval-methode en die werkt echt niet meer anno 2013 (anno 2003 ook al niet meer trouwens)

Als ik aan deel a begin dan maak ik specs van deel a, code deel a en test je deel a. Vervolgens ga je naar deel b.

Kleine behapbare brokjes per keer.

Beste is je kernproces als eerste te specen en bouwen en daarna de basis modulair uitbreiden.
Waarom komt dit nu pas naar buiten als dit al in 2011 is stilgezet? En wordt er nu gewerkt aan een alternatief?
Anoniem: 175233 @tweaker201026 juni 2013 14:25
Waarom komt dit nu pas naar buiten als dit al in 2011 is stilgezet? En wordt er nu gewerkt aan een alternatief?
Volgens het ministerie van justitie is het helemaal niet 'stilletjes stilgezet', maar is het project beeindigt omdat het ingevoerd is. En is er dus ook geen alternatief nodig.
In een reactie zegt het ministerie dat het GPS-project is beëindigd, omdat het is ingevoerd. Het OM verwerkt alle overtredingen en 75 procent van de misdrijven met het systeem, aldus het ministerie. Ook in de rechtspraak zou er wel mee worden gewerkt
(bron:www.nos.nl)

Als het systeem alle overtredingen en 75% van de misdrijven afhandeld, dan kan je niet spreken van een project dat stilletjes is stopgezet. En ook niet van een mislukte invoering.

Ik geloof best dat het project niet optimaal verlopen is, maar lijkt er sterk op dat het FD op zijn minst een nogal gekleurd artikel heeft geschreven... sensatie journalistiek?

[Reactie gewijzigd door Anoniem: 175233 op 23 juli 2024 13:34]

Nogal raar, want iedereen die betrokken is bij dit project weet dat de rechtspraak hun eigen systeem hebben opgezet, los van GPS. Sterker nog, het is een soort prestige strijd tussen het OM enerzijds en de Rechtspraak anderzijds.
"Als het systeem alle overtredingen en 75% van de misdrijven afhandeld, dan kan je niet spreken van een project dat stilletjes is stopgezet. En ook niet van een mislukte invoering. "

LOL, dat hangt toch wel af van hoe je 'het systeem' definieert.
Het project kostte ruim twee keer meer dan beraamt en voldoet nog lang niet aan de specs.
Dat kan je niet anders noemen dan een mislukte invoering.
Er is wel iets ingevoerd, maar het is vast niet 'het systeem' zoals oorspronkelijk bedoelt.
Zo is de Fyra ook 'ingevoerd'... :|
stilletjes stopgezet
Dus het komt pas nu via via naar buiten.
Ja dat begrijp ik, maar dat geld moest toch ergens vandaan komen? Wie is er verantwoordelijk voor etc? Ik neem aan dat de betrokken partijen allang wisten dat het niet goed functioneerde.

@johnkeates: ik bedoelde dat er waarschijnlijk een minister is die een gat van 100 miljoen in zijn/haar begroting heeft, dat is in deze tijden best een flink bedrag hoor. ;)

[Reactie gewijzigd door tweaker2010 op 23 juli 2024 13:34]

Ja, maar het is niet zo alsof er 1 persoon is die alles weet en 1 persoon is die ziet waar geld naartoe gaat... en 100 miljoen is voor jou veel geld, maar voor een overheid slechts een heel klein percentage.

Dus zo heel gek is het niet dat het niet meteen opvalt als er een paar hondeld miljoen 'verdwijnt'.
We kunnen overheidsbestedingen inderdaad niet één op één vergelijken met eigen uitgaven. Dat er veel geld over de spreekwoordelijke balk wordt gegooid is alom bekend, maar het totaalplaatje is nog veel groter:

"Volgens een onderzoek van de Algemene Rekenkamer is de overheid jaarlijks 4 tot 5 miljard kwijt aan problemen met ict-projecten."
Bron: NRC.

Volgens mij moesten we nog ergens 6 miljard zien te bezuinigen volgend jaar.. :)
Stilstand is achteruitgang maar 'investeren' in ICT door de overheid lijkt verspilde moeite.
Het is geen verspilde moeite,
het probleem is dat de overheid zich wijs laat maken dat er "oplossingen op maat" moet komen.

Een voorbeeld hoe het wel kan is Limux,
http://en.wikipedia.org/wiki/LiMux

De Duitse stad München die hun systeem heeft omgezet naar Linux. En misschien kost het wel wat meer, maar het geld blijft dan wel in Nederland, je betaalt je niet scheel aan licenties die naar het buitenland vloeien.

En gezien de mogelijkheden die Linux bied moet het mogelijk zijn om een bestaand systeem aan te passen en toe te passen binnen justitie. Het zal niet zijn dat er +100 beschaafde landen zijn, en dat er niet enkele tussen zit waar het wel werkt. We moeten hier niet het wiel opnieuw uitvinden.
het probleem is dat de overheid zich wijs laat maken dat er "oplossingen op maat" moet komen.
Oplossingen op maat die natuurlijk alleen maar door grote consultancy firma's gemaakt kunnen worden, die voor aanvang van het project eerst allemaal tegen elkaar op mogen bieden wie het het goedkoopste kan doen, er nadat ze de opdracht binnen hebben gehaald dus veel voordeel bij hebben als het project langer, groter en duurder wordt, en er daarom geen problemen mee hebben om hun goedkoopste/minst capabele werknemers te sturen. De echt goede zijn namelijk nodig voor bedrijfskritische private projecten, waar ze wel afgerekend worden op resultaat.

Achteraf blijkt elke keer maar weer dat het waarschijnlijk stukken goedkoper was geweest om zelf een vaste ICT en ontwikkel afdeling aan te houden voor dit soort projecten, maarja die zijn overal wegebezuinigd, want aanbesteden is altijd beter en goedkoper toch? :X
Ha, herkenbaar dit verhaal. Die consultancy firma's moeten nodig eens op prestaties afgerekend worden en als dit soort praktijken gedetecteerd worden, mogen ze op een zwarte lijst. Het is puur misbruik van onze belastingcenten dat ze er zo mee omspringen.

Maar dit gebeurt volgens mij ook buiten de ICT. Kijk hoe defensie als kleine kinderen hun beslissing al meteen genomen hadden: de JSF moest er komen en was op alle fronten de beste investering. Kritische geluiden werden niet geduld en nu lijken ze hun zin te krijgen, ondanks dat dat ding vertraag en fors duurder is. Je kunt natuurlijk niet met een Zweeds of Frans product aankomen, ben je mal. Als je bij defensie eenmaal binnen bent, kun je gouden bergen verdienen lijkt het wel :X
Helemaal eens. Die consultancy firmas zal het ook een worst wezen of het project lukt of niet. Als zij maar maximaal geld er uit kunnen halen en het inderdaad zo lang mogelijk kunnen rekken.

Aanbesteden is ook een hel, maar we kunnen ook niet zonder, want dan gaan we weer ambtenaren krijgen die worden omgekocht om zo het project naar bedrijf X te krijgen.

Daarnaast is 100 miljoen wel een bizar bedrag. Hier moeten echt een paar mensen goed rijk van zijn geworden.
Oplossingen op maat die natuurlijk alleen maar door grote consultancy firma's gemaakt kunnen worden, die voor aanvang van het project eerst allemaal tegen elkaar op mogen bieden wie het het goedkoopste kan doen

Als je voor een dubbeltje op de eerste rang zit krijg je bijna altijd de deksel op je neus. Er wordt gestuurd op geld en niet op kwaliteit. En dan gaat het mis, goh.

geen problemen mee hebben om hun goedkoopste/minst capabele werknemers te sturen.

Tja, men wilde een product wat eigenlijk het dubbele waard is aan consultancy en ontwikkeluren. En natuurlijk heeft een IT bedrijf maar 1 klant.

Achteraf blijkt elke keer maar weer dat het waarschijnlijk stukken goedkoper was geweest om zelf een vaste ICT en ontwikkel afdeling aan te houden voor dit soort projecten

Wellicht, voor 100 miljoen kun je wel wat mensen aan het werk zetten maar aan het einde van de rit is het niet efficient om binnen alle overheidstakken ontwikkelaars te hebben.

want aanbesteden is altijd beter en goedkoper toch?
Aanbestedingen in Nederland zijn een slechte grap die wat mij betreft direct afgeschaft mogen worden.

[Reactie gewijzigd door oef! op 23 juli 2024 13:34]

Anoniem: 135756 @-Tom26 juni 2013 14:25
Oh ik geloof dat meteen.
Werk 10+ jaar in de ICT infra en bij overheden is het altijd een puinbak.
De uitzonderingen zijn bijvoorbeeld kleinere overheden zoals gemeenten maar de grotere "overheids lichamen" ..... ga er niet heen. begin er niet aan.
Ja, maar het is niet zo alsof er 1 persoon is die alles weet en 1 persoon is die ziet waar geld naartoe gaat... en 100 miljoen is voor jou veel geld, maar voor een overheid slechts een heel klein percentage.

Dus zo heel gek is het niet dat het niet meteen opvalt als er een paar hondeld miljoen 'verdwijnt'.
Honder miljoen is ongeveer een 0.4 promille van de totale begroting, dat klinkt heel weinig, maar je gaat me niet vertellen dat er Ministers zijn die zo slecht kunnen rekenen dat ze van elke duizend euro er vier kwijt raken...
Ik denk dat je twee zaken over het hoofd ziet:
- Die 100 miljoen is over 10 jaar, dat is dus 10 miljoen per jaar als gat in de begroting, geen 100.
- In die 10 jaar tijd zijn er volgens mij iets van 4 of 5 kabinetten geklapt. Ik heb niet bijgehouden of de minister van justitie elke keer vervangen is door een nieuwe, maar het komt de continuïteit vast niet ten goede. Het zou mij niets verbazen als de laatste minister(s) niet van het bestaan van dit project op de hoogte waren...
Het wordt tijd voor een kabinet dat de periode weer eens uitzit, voor de verandering :P
" Wie is er verantwoordelijk voor etc?"

HAHAHAHA.
LOL.
Je denkt toch niet dat er ook maar een beetje iemand verantwoordelijk voor is?
Hoe hoger de bestuursfunctie hoe minder werkelijke verandwoordelijkheid er kan worden genomen. Die functies zijn vaak zo abstract dat er vanuit die positie geen invloed is op het probleem. Dat, terwijl de verantwoordelijkheid wel komt te liggen bij die hogere functies.
Het resultaat is dat de mensen die de verantwoordelijkheid op zich nemen nooit de gereedschappen hebben om daar werkelijk uitdrukking aan te geven. Ze stappen dan meestal maar op. Dit is de overtreffende trap van je verantwoordelijkheid niet nemen.
En het element dat de problemen in eerste instantie veroorzaakte blijft gewoon in het systeem aanwezig.

Wie is er verantwoordelijk voor?
Wij, want wij nemen blind aan dat hoge functionarisen hun verantwoordelijkheid nemen en we lijken niet te merken dat ze gewoon weglopen voor hun verantwoordelijkheid, vaak met een dikke bonus op zak.
Hopelijk niet. Voor 100 miljoen kun je beter 300 mensen 10 jaar lang inhuren om met pen en papier de zaken vast te leggen.
Voor 33.000 euro per jaar krijg jij maar weinig mensen aan het werk hoor. Dan kun je die persoon ongeveer 16.500 euro jaar salaris bieden. Dat is net genoeg om te voldoen aan het minimum inkomen van een 22 jarige. Het minimum voor 23 jaar en ouder ligt al op 19000 euro per jaar.
Was het maar zo'n feest. Ongeveer 17.500 euro.
Is dat ook zo als de werkgever de overheid zelf is? En als ze toch belasting moeten betalen over het loon van de werknemer, dan komt dat geld dus direct weer terug waardoor het onder de streep bruto bijna netto is voor de overheid.
Nee, het OM krijgt een budget van de overheid. Belastinggeld gaat weer terug naar de overheid en komt dan dus niet direct terug bij het OM
Er wordt volgens mij wel degelijk aan een nieuw systeem gewerkt.
Waarom komt dit nu pas naar buiten als dit al in 2011 is stilgezet? En wordt er nu gewerkt aan een alternatief?
Zodat de verantwoordelijke hun ambtstermijn uit kunnen zitten: there's no way dat je ze nu nog aansprakelijk an stellen voor falen met belastinggeld. Nu weten we wel waaorm we die broekriem moeten aantrekken...
Interessant dat dit nu pas echt naar buiten komt, terwijl dit natuurlijk al vele jaren bekend was.
Ook gewoon bij alle betrokkenen en medewerkers.
Groot probleem is dat iedereen denkt mee te moeten beslissen, eisen/wensen niet helder zijn en een groot, traag ICT-bedrijf (Ordina, zonder enige druk iets goeds op te leveren, maar wel factureren) de boel heeft moeten bouwen.
Na invoering zeer regelmatig enorme performance problemen gehad en zoals gezegd, het systeem is alleen geschikt voor de simpelste zaken (vanuit rechtspraak-oogpunt).

Als je screenshots zou zien van het programma, denk je dat je weer begin jaren 90 leeft.
Er staat nog net niet zo'n "under construction" mannetje met houweel die bezig is.

Overigens zijn de OM en rechtspraak juist "ontvlecht" afgelopen jaren en zal onderlinge uitwisseling nu/in de toekomst alleen gaan via servicebus/berichtenverkeer etc.
Eén groot lomp programma om beide (totaal verschillende) processen te ondersteunen is gelukkig (in de toekomst) niet meer nodig.

[Reactie gewijzigd door geenstijl op 23 juli 2024 13:34]

ik weet niet waar jij hebt gezetten maar ik zat bij de HR. Rechters wisten totaal niet hoe het systeem werkte en opleiden was niet mogelijk.
Daarnaast zijn die rechters voornamelijk vrij oudere mensen met veel ervaring.. Die wilde hellemaal niets met PC's te maken hebben.. Die zaten liever in hun kamer op de bank met een mooi muziekje aan hun documenten te lezen en te bestuderen..

Ordina was het ja.. ik dacht CAP :+
Maar die gasten die het DMS systeem opzetten zaten daar druk te programmeren in hun ontwikkel systeem. Maar ik heb ze nooit bij de vergaderingen gezien behalve dan hun managers.
Ik zat ook (gedeeltelijk) bij de ontwikkelclub. Wij werden bewust afgeschermd voor de business. Alles verliep via 5 of 6 verschillende managementlagen. Specs waren onduidelijk of verkeerd; men had die specs / beslissingen genomen om zichzelf in te dekken, niet om een use case te maken of uberhaupt mee te werken aan het project.

Verder een hoop (al dan niet moedwillige) sabotage door het continu veranderen van managers die vaker rouleren dan de wissels in een voetbalelftal. Verantwoordelijkheden en taken werden ook niet duidelijk gemaakt, iedereen had zijn eigen bv'tje. Dan kan je programmeren tot je een ons weegt, het gaat nooit voldoen.
ziedaar het probleem "via 5 of 6 verschillende managementlagen".
Klopt, denk maar aan het spelletje, ik ga op vakantie en neem mee...
Na drie, vier personen is het oorpronkelijk lijstje al verwaterd.
Eens. Ik heb uit eerste hand mogen meemaken wat een draak van een systeem GPS eigenlijk is. Verschrikkelijk. Er zijn geen woorden voor.
Klinkt als het prototype project dat schreeuwt om een Agile aanpak.
En waarschijnlijk is de kreet Agile net zo onbekend daar als de rest van het project. Door teveel met dat soort onbekende termen en vakjargon te werken snapt uiteindelijk meer dan dehelft niet waar het overgaat. Miscommnicatie is denk ik eenvan de grootste redenen waarom dingen zo fout kunnen gaan...
Mmm, ben ik an-sich niet helemaal met je eens. Agile methodieken onderscheiden zich juist van veel andere methodieken door juist met de klant in conclaaf te gaan. Er komt verder weinig qua specifieke terminologie voor de klant bij kijken, maar des te meer een focus van de ontwikkelaars om met de klant te gaan inventariseren wat ze nu eigenlijk *wel* willen. Communicatie staat juist voorop!

Ter volledigheid het Agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
En waarom wordt er pas na 100 MILJOEN euro geconstateerd dat het mislukt is? Als je al ettelijke duizenden euro's uitgegeven hebt aan de conceptfase, kun je al zien aankomen of iets succesvol wordt of niet. Zeer zeer slecht werk om er eerst vier keer teveel aan uit te geven.

Het ergste is nog: het is niet verrassend.
Ettelijke duizenden? Al je tijdens een elaboratiefase een aantal mensen (zeg 10) poc's en uitzoekwerk laat doen (2 maanden) ben je zo 100.000 Euro verder.
Verder is wetgeving vaak lastig te implementeren in software, de regels zijn vaak stukje bij beetje uitgebreid met veel mitsen en maren.

Er moet ook vaak informatie uitgewisseld worden met andere partijen, het onderzoeken of dat mogelijk is, is secuur werk.

Ook is het de vraag wie welke gegevens moet/mag beheren, een goed begin is al gemaat door het project Stroomlijning Basisgegevens: https://zoek.officielebek...20&sorttype=1&sortorder=4
Meerdere incompatibele systemen moeten over meerdere incompatibele servicebussen nieuw in te richten processen uitvoeren en de requirements en de beschikbare informatie is onduidelijk bij de verschillende partijen.
Zoveel tijd kost dat dus wel. Die shit is Sparta.
Ik weet niet in welke wereld jij leeft, maar in de echte wereld is een groot ICT project iets wat veel tijd kost en zoals met alle software alleen goed gaat als er heel precies te werk gegaan wordt.

Stel dat je bijvoorbeeld een leuk programma'tje in elkaar wil zetten dat het mogelijk maakt een lijstje producten bij te houden, het mogelijk maakt klanten dingen te laten kopen uit die lijst, en dat multiuser wil, dan kost dat minimaal 6 mensen minimaal 4 maanden om dat compleets met documentatie op te leveren. En dan is dat zelfs nog een project waar er dus geen wazige onbekende onderdelen in zitten.

Als je het dan voor de overheid moet doen heb je opeens ook nog eens met wetgeving te maken, en in plaats van zo'n simpel dingetje mag je opeens een factor 1000 rekenen aan benodigde kennis en uren om *iets* te maken.

Het is niet zo dat je even wat phpcrap in elkaar flanst en in 5 minuten een of andere analfabeet moet overtuigen dat het wel goed is, echte software wordt met documentatie voor de code en de unittests gemaakt, documentatie voor eindgebruikers, documentatie voor beheerders, controles op performance en wetten, en dan gezien het formaat ook genoeg uurtjes voor HR en management personeel.
Volgens mij weet je niet hoe het werkt.. Je mag er van uit gaan dat het al minimaal een ton kost om uberhaupt administratief zo'n project in te richten en op te zetten, voor dat er nog maar een seconde over een regel code nagedacht is.
En dat is ook een deel van het probleem. Zijn we er in de afgelopen jaren niet juist achter gekomen dat "AGILE" de magic word is. De waterval methode waarbij er éérst heeeeeeel veel wordt nagedacht en dan een batterij developers wordt ingeschakeld om 4 jaar achter elkaar te programmeren functioneert niet. En de overheidsprojecten zijn er doorgaans erg goed in om dat te bewijzen.

Ik ben in mijn jaren als ICT'er nog maar weinig projecten tegen gekomen waarbij men in 1 keer 10 miljoen regels code foutloos kon programmeren met een techniek die nog 10 jaar relevant / onderhoudbaar etc bleef. De meest succesvolle projecten die ik gezien heb ontstonden rond een goede projectmanager en een klein team van slimme engineers die weten hoe ze software evolueerbaar kunnen maken. Flexibel genoeg om over de loop van jaren uitgebreid te worden zonder aan kwaliteit in te boeten en waarbij zelfs een verandering van core technologie geen onoverkoombaar obstakel bleek.
Ook een Agile of Scrum methode gaat je niet helpen, die bak met geld gaat ook nog voor dat er een SDM of SDLC gekozen wordt. Net als dat iets als RUP of AUP je ook niet perse die bak geld een stuk lichter laat maken.

Wat ik met mijn post bedoelde, was dat je niet even voor 'een paar duizend' zo'n project kan starten. Voor de allereerste handelingen die nog voor de interviews, definities en projectopzet plaatsvinden heb je dat geld al moeten uitgeven. Bijvoorbeeld aan een vooronderzoek van de partij die de met de aanbesteding wil meedoen of de onkosten voor het kunnen maken van een aanbieding om uberhaupt iets op papier te hebben.
En natuurlijk personeel. Stel dat je er 4 of 5 mensen op moet zetten om te kijken of je uberhaupt al wat gaat doen voor een overheidsproject, dan zullen die ook wel een weekje de boel moeten bestuderen en dat kost ook gewoon geld. In elk geval meer dan 2k of 3k ;)
De overheid en ICT gaan nog steeds niet goed samen. Het wordt tijd dat de overheid een ICT-team opricht dat ondersteuning kan bieden aan meerdere ministeries en instanties, want nu laat de overheid zich te vaak afschepen met waardeloze producten, doordat ze bij uitbesteding kiezen voor de "goedkoopste" offerte. Helaas valt het altijd duurder uit doordat het geleverde product niet goed werkt en moet worden aangepast en gefinetuned. Tel hier wat externe adviseurs bij op die moeten helpen bij de aanbesteding en het project zelf en je hebt weer een financiële strop.

Laat het in het vervolg gewoon over aan experts in eigen dienst die je kan vertrouwen. Dan heb je misschien een doorlopende salarispost erbij, maar dat geld "verdien" je terug door onnodige kosten te voorkomen.

p.s. zoek wel naar nieuwe en echte experts, want er lopen nu bij verschillende overheidsdiensten zogenaamde experts rond die net zoveel of minder weten dan de gemiddelde ambtenaar met een beetje computerkennis.
Probleem is juist dat er 1001 verschillende producten zijn.. Je kan dus niet zomaar een team van 50 man oprichten die voor alle ministirie's en andere overheden al het ICT gaan doen.. Daarnaast zullen deze mensen ook niet van alles wat weten.

Zelfs een multinational met 500 man IT in dienst zal externe moeten inhuren omdat bepaalde kennis niet in huis is..

Hoe kan je een gloednieuw product introduceren als je beste technischie er nog nooit van gehoord heeft.. Nee dan laat je een aantal consultans komen.. Je legt je wensen uit. Zij verkennen de markt, en zullen een applicatie aandragen.. Die consultant kunnen interne mensen zijn natuurlijk..

Maar de implemitatie zal toch echt door derde gedaan moeten worden.. Je kan niet verwachten dat alle kennis voor ontwikkeling, implemitatie en ondersteuning. al bij je werknemers in kennis is voor nieuwe producten.
p.s. zoek wel naar nieuwe en echte experts, want er lopen nu bij verschillende overheidsdiensten zogenaamde experts rond die net zoveel of minder weten dan de gemiddelde ambtenaar met een beetje computerkennis.
Uitspraak gebaseerd op ...

Ik heb ruim 8 jaar voor of bij de overheid in een ICT functie gewerkt, en ik kan je vertellen dat de meesten hun shit echt wel op orde hebben. Er lopen genoeg echte experts rond.
p.s. zoek wel naar nieuwe en echte experts, want er lopen nu bij verschillende overheidsdiensten zogenaamde experts rond die net zoveel of minder weten dan de gemiddelde ambtenaar met een beetje computerkennis.
Maarja, dat is ook zo bij de ICT bedrijven die ingehuurd worden..... en maar lekker uren schrijven... Het zijn toch echt de zogenaamde expert bedrijven als pink roccade (om er maar eens 1 te noemen) die de troep aflevert (nouja, de bedoeling is dat ze het afleveren)..
Maar waar zie je dat niet? Overall kan je met grootschalige projecten vaak zeggen dat goedkoop = duurkoop. Niet alleen vanwege gebreken aan het te maken onderwerp, ook vanwege meerwerk en onverwachte zaken die gemakkelijk mee konden worden genomen als er vooraf een fatsoenlijk inventarisatie of onderzoek had plaatsgevonden.

Dat soort grappen zie je ook met alle andere miljoenen of zelfs miljarden projecten, Betuwelijn iemand?, Noord-zuidlijn, ICT (data, digitalisering, archiefbeheer?). De regelgeving is traag, waardoor stappen worden overgeslagen. Teveel mensen die zich met onvoldoende verstand er zogenaamd denken mee te moeten bemoeien. Tja en dan loop je tijdens of na uitvoering tegen gezeik aan omdat in het vooronderzoek onvoldoende tijd, kennis en geld is gestoken om alles maar zo "snel" en "goedkoop" mogelijk te kunnen uitvoeren. En dat is niet nieuw, dat is nog het meest trieste eraan vind ik.

Geld mag best rollen, maar doe het dan tenminste op een effectieve manier. Ik kan mn geld maar 1 keer uitgeven, jij ook, maar blijkbaar de staat kan het 3x keer uitgeven. Ongelofelijk. :X :X

Op dit item kan niet meer gereageerd worden.