'Nederlandse overheid trekt stekker uit duurste ict-project ooit' - update

Het Ministerie van Defensie zou willen stoppen met de ontwikkeling van ERP, een automatiseringssysteem voor het leger. Formeel is er 433 miljoen euro aan uitgegeven, maar waarschijnlijk gaat het om het dubbele. Het ministerie zelf ontkent dat ERP wordt stopgezet.

NRC stelt dat het documenten heeft ingezien van Defensie die met een beroep op de wet openbaarheid van bestuur zijn vrijgegeven. Tevens heeft de krant gesprekken gehad met bronnen bij Defensie. Daaruit komt dat de overheid, via minister Jeanine Hennis-Plasschaert, zou willen stoppen met ERP, een systeem dat ook bekend staat onder de naam Speer. Er wordt al sinds 2004 gewerkt aan het ict-systeem, maar er is nog steeds geen goed werkend geheel opgeleverd.

Wel is ERP al in de praktijk ingezet: bij de missie in Mali verliep de ondersteuning via het ict-systeem. Uit een brief die naar de Tweede Kamer is gestuurd blijkt dat ERP nog niet goed functioneert. Maar het beschikbare geld zal als het aan de minister ligt niet meer worden ingezet voor de ontwikkeling. In plaats daarvan worden de onderdelen van ERP die wel werken onderhouden en vervolgens ingezet in combinatie met andere systemen. Volgens bronnen die NRC Next heeft gesproken is ERP door de lange ontwikkeltijd inmiddels verouderd, maar kan het nog wel dienst doen als 'veredeld registratiesysteem'.

ERP is een ict-systeem voor het leger waarmee onder andere kan worden bijgehouden welk materieel er beschikbaar is en waar het precies staat. Ook moest het systeem informatie houden over het onderhoud en voorraden van reserveonderdelen registreren. Volgens officiële cijfers is er 433 miljoen euro aan uitgegeven, maar volgens een berekening van de Algemene Rekenkamer gaat het waarschijnlijk om het dubbele daarvan.

Ict-projecten bij de overheid liggen al langer onder vuur. Bij Defensie bleek vorig jaar al dat er sprake is van grote problemen. Daarnaast was er mogelijk sprake van fraude bij de aanbesteding van nieuwe projecten.

Update 13:19 uur: het Ministerie van Defensie zegt in een reactie tegenover de NOS dat ERP niet wordt stopgezet. Delen van het ict-systeem moeten volgend jaar klaar zijn, terwijl voor toepassingen waarbij het systeem niet functioneert 'naar andere mogelijkheden wordt gekeken'. ERP wordt echter niet bij voorbaat al uitgesloten, zo stelt het ministerie. Uit de reactie blijkt echter niet dat het ict-systeem ook daadwerkelijk wordt doorontwikkeld.

Reacties (358)

[ironx]

Minister Hennis-Plasschaert wil het programma nu 'bevriezen', maar wacht volgens ingewijden een goed moment af om dat besluit openbaar te maken. Ze is bang voor klachten van leveraniers, schrijft NRC.

Bron: RTL Nieuws

11 Jaar geleden opdracht voor gegeven. Had 6 jaar geleden al af moeten zijn (natuurlijk loopt er altijd vertraging op, maar 6 jaar and counting!?). De gedeeltes die wel af zijn werken ook nog eens niet eens goed, en dan bang zijn dat degene die het moet leveren gaat klagen omdat jij het zat bent!?

Overheid of niet, maar dit slaat als een tang op een varken. Jij bent de klant. Jij bent degene die eisen stelt. Jij bent degene die het moet betalen en dan bang zijn voor klachten als je er iets over wilt zeggen...

Nouja, ... maak van dat jij maar wij, want wij, de burger, hebben het allemaal weer op mogen hoesten.

[Reactie gewijzigd door ironx op 23 juli 2024 13:50]

[sirono]

tenzij je als klant het de leverancier bijna onmogelijk hebt gemaakt een goed product af te leveren, je wilt niet weten hoe vaak specs veranderen gedurende zo'n project.
dan begint het met:
we willen als eerste graag een systeem om alle voorraad van uniformen op die en die basis bijhouden.
2 maanden later als men daar druk mee bezig is:
ach als we toch bezig zijn met die uniformen, kunnen jullie het systeem niet ook gelijk helmen laten meenemen? dat lijkt toch heel veel op uniformen?
2 maanden later:
nu jullie toch al de voorraad bijhouden, kunnen we dan ook niet nog even automatsich laten bestellen als de voorraad onder een bepaalde threshold komt? dat moet wel instelbaar zijn, en helemaal automatisch.

en als de klant dan geen "nee" accepteerd maar er ineens een must have requirment van maakt zit je als leverancier in de klem. ga je meer geld vragen omdat je meer moet opleveren. maar meestal wordt er geen rekening gehouden met verschuiven van de opleverdatum waardoor de algehele kwaliteit hard achteruit gaat.
dit is nog los van het feit dat men vaak helemaal niet weet wat men wil.
"hoe loopt het proces om een nieuw uniform aan te vragen?" een mooie process beschrijven,
en een tijdje later blijkt ineens dat dit process totaal niet klopt. en veel complexer is dan het door de business analyst is beschreven.

zomaar een paar voorbeelden van hoe een ICT project uit de klauwen kan lopen. de schuld ligt dus niet alleen bij bij de leverancier, maar soms zeker ook bij de klant.

[vandeGerrit]

Het klopt dat software altijd veranderd en specificaties altijd veranderen terwijl je bezig bent. Dit maak ik zelf al software ontwikkelaar ook vaak mee. Erg is dit niet, als je hier maar goed mee omgaat. Denk aan agile achtige projecten.

Vaak wordt er ook gezegd dat de overheid een moeilijke klant is, vanwege alle veranderingen, maar ook wetten en regels die erin moeten verwerkt worden. Zelf ben ik van mening dat dit niet het probleem is, maar de grote IT bedrijven die niet de ballen tonen om goed advies te geven, echt zeggen waarop het staat. De overheid komt met een vraagstuk, vraagt om advies, je weet wat de randvoorwaarde zijn, en dat het project regelmatig wordt ingehaald door de werkelijkheid. En als het uitloopt, dan is het: ja de overheid.

Dat dingen worden ingehaald, is gewoon een feit wat wij als software ontwikkelaars moeten meenemen tijdens de bouw met alles wat we doen. Resultaat nu is: ERP door de lange ontwikkeltijd inmiddels verouderd. Ik weet niet hoe het opgebouwd is, maar de Linux Kernel is ook nog steeds niet verouderd, en lijkt mij een ingewikkelder stukje dan ERP.

[PhilipsFan]

De grote IT-bedrijven kunnen niet zeggen waar het op staat. Ze kunnen geen eerlijke offertes afgeven waar duidelijk op staat wat iets kost en hoe lang het duurt.

Als ze dat namelijk wel doen, dan is er altijd wel een concurrent die dat niet doet en dan zegt de ik-kijk-niet-verder-dan-mijn-domme-neus-lang-is-manager bij de overheid: hee, firma twee doet het veel goedkoper, dan gaan we daarmee in zee. Op 5-cijferige bedragen kunnen een paar kwartjes het verschil al maken.

Ik hoop al 10 jaar dat er bedrijfjes ontstaan die op basis van specialistische kennis offertes kunnen beoordelen op haalbaarheid. Maar helaas wordt er nog genoeg verdiend aan het doelloos inzetten van mannetjes. En het doelloos maken van allerlei rapporten. Echt ongelooflijk, hoe al dat managersvolk zichzelf aan het werk houdt en helemaal niks nuttigs oplevert...

[Reactie gewijzigd door PhilipsFan op 23 juli 2024 13:50]

[KopjeThee]

De grote IT-bedrijven kunnen niet zeggen waar het op staat. Ze kunnen geen eerlijke offertes afgeven waar duidelijk op staat wat iets kost en hoe lang het duurt.

Als ze dat namelijk wel doen, dan is er altijd wel een concurrent die dat niet doet en dan zegt de ik-kijk-niet-verder-dan-mijn-domme-neus-lang-is-manager bij de overheid: hee, firma twee doet het veel goedkoper, dan gaan we daarmee in zee.

Het probleem is volgens mij nog iets dieper. Die manager die de goedkoopste kiest, weet misschien eigenlijk ook wel beter. Maar hij moet zijn keuze ook verantwoorden naar zijn leidinggevende. En op voorhand kan je vaak niet hard maken dat de duurdere ook echt beter/realistischer etc. is: Kortom tot een beter eindproduct leidt. Dus je kiest gewoon langs het enige eenvoudig meetbare criterium: Prijs. Dan kan het mis gaan, maar niemand kan hardmaken dat het met die duurdere partij wel goed was gegaan.

[Reactie gewijzigd door KopjeThee op 23 juli 2024 13:50]

[gertm]

Niet (alleen) tegen zijn leidinggevende, maar tegenover de rechtbank. De overheid is namelijk (door EU-regels) VERPLICHT om het contract toe te wijzen aan de goedkoopste bieder die voldoet aan de eisen in het lastenboek. Dan moet je het lastenboek maar beter opmaken? Gemakkelijker gezegd dan gedaan, om een systeem zoals ERP in het lastenboek zo te beschrijven dat er geen onrealistische offertes ingediend kunnen worden. In feite, als je het lastenboek zo goed kunt opstellen, dan heb je waarschijnlijk alle nodige kennis in huis om het project zelf te doen.

[Anoniem: 470811]

Klopt, wat mij betreft voegt de overheid bij Europese aanbestedingen dit toe:

"PS. We betalen NIET voor meerwerk"

Dan worden offertes vanzelf weer realistisch.

[Reactie gewijzigd door Anoniem: 470811 op 23 juli 2024 13:50]

[Verwijderd]

Men weet niet wat men wil.... Dat is het echte probleem.... En ze zullen dit ook nooit weten want de overheid betaald niet de (hoge) lonen aan hun eigen werknemers die dit zouden moeten kunnen. Daarom krijg je dat externen worden ingehuurd die weer adviezen schrijven naar specifieke bedrijven....

Als je ondertussen kijkt binnen de gemeenten dan zie je dat er eigenlijk nog maar 2 software leveranciers zijn: Pink en Centric. Die cashen op grote schaal met software die echt bizar slecht werkt.

En het mooie is nog, geen politica die het interesseert. Die hoeft er niet mee te werken. Die doet over 4 jaar toch gewoon weer een stoelendans.

[Anoniem: 470811]

Dat men niet altijd (precies) weet wat men wilt is bekend. De klant moet je ook geven wat hij wilt, niet dat wat hij vraagt. De kunst, en de ethische plicht, van een leverancier is dat hij een klant helpt bij het formuleren van de vraag.

Bij een documentaire (Wie is de mol?, deel 2) van Zembla over Ordina zie je hoe Ordina systematisch de door jou benoemde issue bewust uitbuit.

http://zembla.vara.nl/seizoenen/2015/afleveringen/28-01-2015

Vandaar: Neem in je offerte op dat je niet betaald voor meerwerk. Dat helpt de leverancier het doen van een goede offerte en triggert het de leverancier om de werkelijke klantvraag (behoefte) boven tafel te krijgen.,

[Verwijderd]

Ik had al wel van de documentaire gehoord maar deze nog niet gezien. Bedankt voor de link! En erg verontrustend weer

[thegve]

Niet voor meerwerk? We betalen niet voor dingen die we wel willen maar die we gewoon niet opschrijven?
Dan blijft het aardig rustig qua inschrijvingen denk ik zo.
Maar ik weet wel wat je bedoeld. Bij verschillende bedrijven gewerkt waar het jagen is op punten die je in een systeem wel zou mogen verwachten, maar die niet zijn beschreven, en die je dan later inderdaad als meerwerk kan uitvoeren. En als software-ontwikkelaar ook als opdracht meegekregen goed te lezen wat er in de aanbesteding staat, en vooral niets te maken wat niet letterlijk staat beschreven, al kost het maar een minuut werk.
En bij beide bedrijven was dit echt geen onwil, maar gewoon een gevolg van de aanbestedingswet die netto gewoon neerkomt op prijs, gezien de grote jongens, waar 2 van mijn oud werk/opdracht-gevers toe behoorden, hun kwaliteit gewoon op orde hebben.
Overigens wel een van de redenen dat ik nu weer lekker bij een klein bedrijf werk. Gewoon ouderwets met een kopje koffie de plannen en soms dromen van opdrachtgevers bespreken, zonder drie-dubbele agenda's.

[ToolkiT]

Dan worden ze realistisch om like-for-like te vergelijken, maar krijgt een klant niet wat ze nodig hebben..
Meestal zijn de requirements very van compleet en correct met wat er echt nodig is.
Alternatief is om een agile project te doen en voor X dagen te betalen en dan flexibel de prioriteiten zetten en dus waarschijnlijk minder afkrijgen, maar wel goed werkend...
En over de kwaliteit van UAT zeg ik maar niks want daar gaat het heel vaak fout is mijn ervaring..

[Uruk-Hai]

Als dat echt waar is, dan zou je weleens een kernprobleem benoemd kunnen hebben waardoor dat dit ICT project op een fiasco uit is gelopen.

Ikzelf probeer altijd het beste van twee werelden te combineren, een zo laag mogelijke prijs koppelen aan een zo goed mogelijke kwaliteit. Dat is soms gelukt en soms mislukt door net iets te weinig kennis van zaken vooraf hebben.

Maar ja, je kunt ook niet alles vooraf weten. Leren is (groten)deels een kwestie van fouten maken en dan beslissen wat je met het geleerde gaat doen. Dat is precies wat minister Jeanine Hennis-Plasschaert nu doet.

Het was een dure les, maar zo werkt dat nu eenmaal in Nederland.

Als je ICT voor overheidsdoeleinden miljoenen euro's goedkoper wilt maken kun je volgens mij het ontwikkelen opensourcen en overdragen aan universiteiten. Daar zit het echt intelligente volk.

Maar dat laatste zie ik onze nog immer op closed software en gladde dure mannetjes met vlotte babbels gerichte overheid niet snel doen. Temeer omdat het bedrijfsleven hier in Nederland toch echt wel de baas is. Dat wordt niet alleen op ICT gebied keer op keer bewezen.

[JanJeen]

Deels waar, maar inmiddels zijn partijen als Rijkswaterstaat al iets verder en kijkt men naar Best Value.

[i-chat]

dit probleem is zo uit de wereld te helpen, stel een wettelijk verbod op meerkosten bij contractuele aanbestedingen, en laat zo'n aannemer maar aantonen dat de opdrachtgever nalatig is geweest oid... waardoor de rechter kan beslissen of die meerkosten bij wijze van uitzondering worden toegestaan...

[TheGhostInc]

Inderdaad. En dan blijkt het originele systeem ontworpen te zijn voor 1 uniform soort en komt er een tweede bij. Helaas werd dat 1 week na de aanbesteding besloten en 3 jaar later heeft elke afdeling een Excel sheet waarin de 2 uniformen uit elkaar worden gehouden.....

Als leverancier is het vaak ook maar een paar jaar leuk en daarna is het alleen maar gezeur. Zeker de medewerkers 'op de vloer' proberen er maar het beste van te maken, maar leuk is het ook niet als al je werk voor niks is geweest.

[Anoniem: 670995]

Zo'n kennis-afdeling ICT binnen de overheid is er geweest, maar kreeg zoveel macht dat het privaat gemaakt is. Terug bij af.

[robenroute]

Als ze dat namelijk wel doen, dan is er altijd wel een concurrent die dat niet doet en dan zegt de ik-kijk-niet-verder-dan-mijn-domme-neus-lang-is-manager bij de overheid: hee, firma twee doet het veel goedkoper, dan gaan we daarmee in zee. Op 5-cijferige bedragen kunnen een paar kwartjes het verschil al maken.

Inderdaad, daar ligt nu exact het probleem, en dat al sinds jaar en dag. Het is geen probleem, en soms wel erg verstandig, om bepaalde processen/projecten uit te besteden, maar zorg dan in ieder geval voor dat je als opdrachtgever over twee essentiële zaken beschikt (zelf in huis hebt dus!): verdomd goede kennis van zaken en een verdraaid goede regiseur/manager. En daar gaat het bij de overheid keer op keer mis; kennis van zaken wordt ingehuurd en de regie wordt uit handen gegeven (of in handen gegeven van mensen die niet vooraan stonden toen het gezonde boerenverstand werd uitgedeeld).

Als NL-belastingbetaler wordt ik toch wat boos om dit soort dingen...

[n4m3l355]

Het is tweeledig, ik heb een tal van projecten voor de overheid gedaan maar dan in de bouw/infra.

Enerzijds is het erg lastig om met vooral grote projecten te werken omdat er talloze partijen aan tafel zitten. Het is niet 1 klant, het is 1 klant met 10 gezichten die allemaal bang zijn om beslissingen te maken.

Omgekeerd was ik niet gebaat bij een eenduidig antwoord omdat ik uiteindelijk meerwerk kan facturen immers hetgeen wat ze nu willen wijkt af van het originele plan. Het boeit niet of het meer of minderwerk is, ik ken maar een antwoord, meerwerk.

Budget neutraal is ook een mooi term echter je kunt zoiets niet verkopen wanneer je talloze juridische trajecten moet doorlopen op hun wensen. Je kunt dit ook niet accepteren wanneer men constant met de kont draait.

De overheid is keer op keer dan ook zelf verantwoordelijk door een gebrek aan daadkracht maar ook een gebrek aan kennis. Ik zat soms met oud klasgenoten aan tafel die plots al projectleider waren echter op de uni waren ze verre van briljant. Ik kleedde ze dan ook keer op keer uit omdat ze gewoon onkundig zijn. Immers wie gaat voor de overheid werken wanneer je in de prive sector beduidend meer kunt verdienen.

[Zephyer]

En voor iedereen gaat het om het geld natuurlijk ...

[kikker81]

Haha nee, als software leverancier vind je het prettig om 11 jaar aan iets te werken en dat het dan nog niet goed is.
Bij de overheid komt je alleen terecht als IT specialist als je te onkundig bent om in de privé sector mee te kunnen (en dat is ERG onkundig)

[Zephyer]

Dat is nogal krap door de bocht ... Ben benieuwd waarop je dit baseerd.

Ken mensen die wel degelijk mee kunnen in de zgn commerciële sector maar wel als ambtenaar werken.

Vinger nogal denigrerend om eerlijk te zijn.

[kikker81]

Ja sorry, te kort door de bocht, het zijn zeker niet alleen onkundige mensen, maar je moet er wel een bepaalde werkinstelling hebben.

[GeoBeo]

Zelf ben ik van mening dat dit niet het probleem is, maar de grote IT bedrijven die niet de ballen tonen om goed advies te geven, echt zeggen waarop het staat. De overheid komt met een vraagstuk, vraagt om advies, je weet wat de randvoorwaarde zijn, en dat het project regelmatig wordt ingehaald door de werkelijkheid. En als het uitloopt, dan is het: ja de overheid.

Hier ben ik het heel erg mee eens. En dan is Capgemini (de winnaar van deze ERP aanbesteding) echt een goed voorbeeld van alles wat mis is met grote ICT bedrijven. Ze geven niet alleen door incompetentie onjuist en onwaar advies, ze geven dat onjuiste advies ook nog eens bewust met het doel meer geld (meerwerk) uit het project te trekken. Nog even los van het feit dat ICT'ers met daadwerkelijk talent en ambitie nooit bij zo'n bedrijf aan het werk gaan en dat dat bedrijf dus nooit echt goed personeel kan aantrekken. Dit geldt des te meer in de huidige arbeidsmarkt waar ICT'ers zeer schaars zijn.

Bovenstaande baseer ik op ervaring die ik heb met ex-Capgemini seniors in aanbestedingen: ze weten precies de juiste mensen te manipuleren (zowel bij eindklant als ook bij de financier) met verkeerd advies met het doel heel veel meerwerk uit het project te trekken. Technisch kunnen (of willen) ze absoluut niets, maar ze weten zichzelf er wel altijd weer tussen te dreigen/kopen/lullen.

Als techneut moet ik zeggen dat het echt pijn doet aan m'n hart om dat soort mensen zo aan het werk te zien. En dan houd ik het nog netjes.

[rijkvanwel]

+1! En daar komt nog bij dat deze bedrijven de ICT sector ('onze sector') een zeer slechte naam geven; als ICT in het nieuws komt is het 9/10 keer door een overheidsproject dat weer miljoenen over het budget is geknald. Nooit bijvoorbeeld over een supergoede oplossing die is ontwikkeld. Uiteindelijk worden mensen (terecht) wantrouwig naar ICT-'oplossingen' toe, wat alle ontwikkelaars schaadt, ook de goede.

Jammer dat de grootste amateurs in de sector beloond worden met de grootste opdrachten.

[Reactie gewijzigd door rijkvanwel op 23 juli 2024 13:50]

[codebeat]

Beide verhalen klinken zeer bekend, deze bedrijven hebben werkelijk geen idee wat voor schade ze de I(C)T-industrie toebrengen. Of het interesseert ze gewoon geen zier, want tja, als het alleen maar gaat om verkopen is er vast wel weer een andere markt die kan worden aangeboord wanneer dit op z'n gat gaat. Dat zou overigens niet de eerste keer zijn dat het op z'n gat gaat.

Kom ik weer uit bij SCRUM, ook zoiets, is bedacht om efficiënter te werken maar is nu commercieel toegepast. Kwaliteit in het eindresultaat is wel belangrijk maar op kort termijn want er worden desnoods dingen weggelaten zodat er sneller resultaat is. Dus wat het op langer termijn doet is niet bekend, is ook niet te vinden, alleen effect op kort termijn. Als het maar werkt, daar gaat het om, het gaat om: cashen.

Vandaar dat er nu vrijwel alleen maar functies worden aangeboden waarbij je het trucje moet kennen, niets meer, niets minder, het gaat om produceren. Lopende band programmeren is het eigenlijk geworden. Heb je een mooi CV, dat maakt voor het produceren niet uit, je moet het kunstje exact kunnen. Exact, want ze willen ook niet investeren, een zo'n hoog mogelijk rendement qua output.

Kan mij niet voorstellen dat dit op langer termijn geen schadelijk effect heeft. De mensen die echt goed zijn kunnen hun passie (ei) niet meer kwijt. Je hoeft geen briljante uitspattingen te verwachten want daar is geen ruimte meer voor.

De SCRUM is wellicht gunstig voor het ICT-bedrijf en haar inkomsten alleen voor de klant op langer termijn veel minder gunstig, het project is op productie gemaakt. Zoals ik eerder schreef, vaak dingen weggelaten (niet berekend op wijzigingen) dus komt er weer een nieuw project. Uiteindelijk is de klant die eventueel op ten duur meer wenst duurder uit maar dat vertellen ze er niet bij natuurlijk.

Het is een kwestie van tijd, zoals @rijkvanwel terecht schrijft, uiteindelijk worden mensen terecht wantrouwig richting ICT-projecten, wat alle ontwikkelaars schaadt, ook de goede.

Kwaliteit (in alle facetten) is onderschikt aan snelheid, dus kan zo'n big-boy het sneller dan een kleiner en misschien wat duurder bedrijfje, of heeft niet zo gelikte verkoper, dan vist het kwalitatief beter bedrijfje naast het net. Het is net als een goedkoop product uit China, als het werkt, werkt het. Gaat het echter stuk, dan moet je een nieuwe kopen. Programmeren is een massaproduct geworden en dat hoort niet bij maatwerkoplossingen.

[Reactie gewijzigd door codebeat op 23 juli 2024 13:50]

[rijkvanwel]

Het is daarom ook denk ik dat de term "ICT" zo'n nare bijsmaak heeft gekregen, en mensen in de sector hem (voor zover ik weet) liever mijden.

Ik ben gelukkig actief in de webapplicaties, die liggen er voor het gevoel sowieso al een stuk vanaf. En mijn klanten zijn meestal wel redelijk mee met de gang van zaken, dus ik ben nog niet tegen het probleem aangelopen. Maar het kan niet anders dan dat dit op termijn de sector gaat schaden. Mensen horen ICT en denken aan "weer miljoenen over de balk aan mislukt ICT project".

[codebeat]

Ik had er misschien nog aan toe moeten voegen dat zo'n groot bedrijf Enterprise prijzen hanteert maar goedkope China kwaliteit aflevert. Daardoor kan je jezelf aardig belazerd voelen op langer termijn en zou je kunnen gaan denken: "Daar heb je die ICT graaiers weer" wat natuurlijk niet zou moeten gelden voor bedrijven die wel goede kwaliteit willen leveren tegen een degelijk normaal tarief.

Ik maak zelf ook websites/webapps maar merk wel degelijk een verschil met jaren terug. Dat heeft naar mijn idee een aantal redenen:
- Bovengenoemde dus, het vertrouwen, waarde van dienst
- Gratis tools (met of zonder advertenties)
- Meerwaarde custom
- Economische situatie

Wordpress bijvoorbeeld, ik vind het een draak van een pakket (interne structuur bijvoorbeeld, bloated) alleen de klant denkt daar anders over. Je kunt als je wilt een template-tje gebruiken en in mum van tijd een website uit de grond stampen. De snelheid/prijs waarmee dat kan lijkt onderschikt aan de kwaliteit. Kwaliteit in de zin van uniek, bijzonder, op maat gemaakt. Zoals ik al eerder schreef, 'programmeren' is gelijk aan een massaproduct geworden. De klant denkt bij alles "Dat doe je toch effetjes".

Dus als je bijzonder werk wil leveren (niet een eenheidsworst) en je komt met een offerte is de eerste reactie "Wat duur". Je moet dan de prijs overdreven gaan rechtvaardigen wat voorheen niet nodig was omdat iemand zich wel kan indenken dat het echt werk is. De meerwaarde versus eenheidsworst moet sterker naar voren komen maar vaak maakt het de klant niet meer uit of het onderscheidend is, als het maar snel en goedkoop is en liefst nog alles kan. Veel voor weinig dus.

Net zoiets als de diensten van Google, vaak gratis (met advertenties) en kan alles wat een vertekend beeld geeft van de werkelijkheid. Mensen weten dus niet dat daar een heel team achter zit om de functionaliteit beschikbaar te maken. De werkelijke kosten zijn niet meer zichtbaar. Dat ze daar op een andere manier voor betalen lijken ze niet in te zien. Wat dat betreft heeft Google dat uitstekend begrepen hoe dat werkt.

Naar mijn idee wordt custom / maatwerk steeds minder interessant omdat het steeds minder loont, het dwingt je steeds meer mainstream te worden. Dan wordt het lopende band werk, wat mij absoluut niet aanspreekt. Of je moet een uitstekende salesmanager in dienst hebben zoals bij de big-boys die zelfs een drol als iets fantastisch kunnen verkopen. Niet om die drol te verkopen maar wel om de meerwaarde te kunnen verkopen. Het is steeds lastiger mensen te overtuigen van de meerwaarde wanneer je meerwaarde maakt.

Mensen denken al snel dat je hun een oor aannaait mede dankzij de "ICT-ers zijn graaiers" reputatie veroorzaakt door de big-boys én de gratis tools (vertekende marktwaarde) die beschikbaar zijn.

[Reactie gewijzigd door codebeat op 23 juli 2024 13:50]

[LinuxMan]

Resultaat nu is: ERP door de lange ontwikkeltijd inmiddels verouderd. Ik weet niet hoe het opgebouwd is, maar de Linux Kernel is ook nog steeds niet verouderd, en lijkt mij een ingewikkelder stukje dan ERP.

het gaat niet om de techniek die verouderd is (alhoewel SAP niet uitblinkt in moderne techniek), maar de bedrijfsprocessen die in de software zijn geconfigureerd zijn alweer veranderd voordat SAP het kan ondersteunen.

In een organisatie die de afgelopen twintig jaar elke drie jaar een enorme reorganisatie moest doen omdat er weer een enorme bezuiniging overheen ging zijn de bedrijsprocessen ook elke drie jaar volledig omgegooid. En SAP is blijkbaar zo'n star product dat ze dat tempo niet kunnen bijhouden.

Dus als je het met Linux wil vergelijken: als de Linux kernel elk jaar op een processor met andere instructieset moet werken.

[xxxneoxxx]

Star zou ik SAP niet noemen. Complex wel. Gebruik je standaard SAP methodiek, dan kan je e.e.a vrij snel inrichten en onderhouden. Knal je er voor elk bedrijfsproces maatwerk in, dan wordt het al lastiger. Onze overheid kennende, verandert de vraag om de 5 minuten naar gelang welke ambtenaar je de vraag stelt. Dus zal er geen standaard gebruikt worden, maar vooral custom ABAP. En maatwerk elke keer wijzigen, kost elke keer effort, geld en tijd. Tevens is het extra complex qua testen e.d na elke update.. Tel daarbij de standaard doorlooptijden van projecten bij de overheid en dan maakt het niet uit welke software oplossing je kiest - zonder duidelijk beleid en visie blijf je zulke issues hebben. Kan je SAP niet echt aanrekenen.

[Madrox]

SAP vind ik bovendien nogal gebruikersonvriendelijk; bij een printopdracht moet je voor onderdelen een rit invoeren, voer je niets in print die vrolijk alle ritten uit op kettingpapier in dit geval. Met geen mogelijkheid te annuleren, daar gaat een pak kettingpapier, naar de prullenbak.

Eenvoud, dat wel. Maar pas op dat je niet de verkeerde toets indrukt op de printpagina (enter). Niets waarschuwt wat er gaat gebeuren, in dat opzicht is het zeer gebruikersonvriendelijk.

Wellicht is dit vb op zichzelfstaand en alleen bij dat ene bedrijf van toepassing. in dat geval trek ik mijn woorden terug.

[xxxneoxxx]

Hangt er een beetje vanaf hoe het printproces ingericht is. En een spoolopdracht mag je als het goed is wel weggoien, maar dit hangt ook weer af van je autorisaties.

Zoals gezegd, e.e.a. is een stukje inrichting. Functioneel kan er ook voor kiezen om een paar velden vooraf ingevuld aan je te serveren, zodat er minder geprint wordt als je een keer vergeet een selectie te maken bijvoorbeeld. En de meeste transacties hebben een waarschuwing als er een te grote selectie plaatsvindt met de vraag of je zeker weet dat je iets wilt doen, omdat je selectie meer dan X duizend elementen bevat.

[Reactie gewijzigd door xxxneoxxx op 23 juli 2024 13:50]

[Verwijderd]

De overheids/afdelingen cultuur met ieder hun eigen lokale paus veroorzaakt een groot deel van de problemen. Personen die beslist hun zin moeten hebben en waarbij argumenten niet helpen zijn er veel teveel.

Bij de overheid als beslissingsbevoegde zijn is politiek bedrijven en alles moet geslachtofferd om de eigen ik op de agenda te houden als belangrijk persoon...zo kom je vooruit daar!

Dan krijg je spelletjes tussen personen bij de klant en tussen klant en leverancier. Dit vertaald zich in vreemde afspraken, ondeugdelijk specificaties en om oneigenlijke redenen daaraan lang vasthouden ook al is duidelijk dat iets niet kan werken.

Als leverancier ga je daar niets aan veranderen. Waar je op persoonlijk vlak nog iemand zou overtuigen, leg je het af tegen andere belangen. Deze cultuur heeft natuurlijk effect op leveranciers die grotendeels afhankelijk zijn van overheidsopdrachten. En aangezien de overheid geen "marktwerking heeft" en dus falen nauwelijks voelbaar is, of zelfs promotie kan betekenen, ettert dit probleem voort en infecteert ook de leveranciers.

Als kleine ontwikkelpartij kun je een meer assertieve houding aannemen, maar daar ga je geen grote leverancier mee worden!

[kdekker]

Qua aantal regels code denk ik dat een complex ERP pakket niet onderdoet voor de Linux kernel (aldus Wiki 15 miljoen regels code in 2014). Daarbij komt, wat hieronder of hierboven ook al gezegd wordt, is het inrichten van je bedrijfsprocessen is een complex en tijdrovend gebeuren. Zo complex, dat er niemand is die een offerte op dit gebied zonder weken of maanden studie op z'n merites kan beoordelen. En vermoedelijk zijn het aantal managers die zo'n project kunnen managen ook niet dik gezaaid...

Het inmiddels wel een klucht in het zoveelste bedrijf. Dat SAP de deal won is al (9 jaar geleden) omgeven met rechtszaken (o.a. met Baan).

[Intrepidity]

Ja, dus? Daarvoor heb je agile werkmethodes die kunnen omgaan met veranderende specs. Beslis welke core feature het meeste toegevoegde waarde bied, ontwikkel en release deze, en blijf dan iedere maand een nieuwe versie met extra funcionaliteiten releasen.
Het aantal keren dat een klant echt alle features in 1 keer nodig heeft en ook nog actief gebruikt is op één hand te tellen.
Zeker nog nooit van scrum gehoord bij de overheid.
Je kunt als ontwikkelaar onmogelijk de klant de schuld geven van veranderende requirements. Veranderende requirements zijn een onderdeel van het leven van een ontwikkelaar en als je je stug opstelt gaat het inderdaad mis. Leer omgaan met veranderingen en ze om te zetten naar een manier om je applicatie steeds een stukje beter te maken.

[T0mBa]

Het probleem is dat de overheid een openbare aanbesteding moet uitschrijven. Agile en scrum kunnen met zo'n systeem niet om aangezien het punt van een aanbesteding net is dat je op voorhand alles vastlegt wat je nodig hebt. Zo'n aanbestedingssysteem werkt prima bij zaken als wegenwerken of nieuwe gebouwen, maar bij IT-projecten is dat gewoon compleet nutteloos.
De overheid moet gewoon ZELF zijn IT in de hand hebben in plaats van dit uit te besteden aan veel te dure outsourcing bedrijven. Wanneer er met goedkopere interne mensen gewerkt wordt, die direct contact hebben met de toekomstige gebruikers kan je veel zinniger beslissen welke features prioritair zijn. En dan kan er agile, goedkoper en nuttig gewerkt worden. Zaken die onmogelijk zijn zolang men verplicht met aanbestedingen moet werken.
En als men het toch per se via aanbestedingen bij de privé wil doen (kwestie dat de politici hun spaarpot ook wat kunnen aandikken met de commissie die ze daarvoor krijgen), is het veel zinniger om een aanbesteding te doen voor uurlonen en competenties (bvb: wij willen gedurende 5 jaar 200 .NET profielen inhuren, waarvan zoveel developers, zoveel architecten, zoveel analisten, zoveel QA's,...)

[kikker81]

Ga jij de overheid dan helpen om die "goedkopere" interne mensen te vinden dan?

[T0mBa]

Waarom zou dat zo moeilijk zijn? Als je die mensen evenveel betaalt als de privé komt het nog altijd veel goedkoper uit aangezien er niet nog een tussenpersoon bij zit die een stevige marge neemt op de loonkost van de werknemer...

[kikker81]

Juist, alleen is het probleem dat je als ICT'er de banen voor het oprapen hebt en je belachelijke bedragen moet betalen om gemiddelde ICT'ers zo gek te krijgen voor de overheid te gaan werken.

[T0mBa]

Voor de overheid heeft ook nog wel een aantal andere voordelen zoals jobzekerheid, goed pensioen, minder stress...

[beerendlauwers]

Scrum voor dit zo'n projecten wordt ook al een monster, hoor. Scrum is voor teams van 8-10 max, Agile scalen geeft je dan dit soort situaties: https://scalingsoftwareag...-09-20-at-11-51-18-am.png

[Intrepidity]

Maar je kunt eenvoudig genoeg meerdere teams naast elkaar zetten met elk een eigen gedeelte van het project.

[Blokker_1999]

Vandaag richten development methodes zich inderdaad steeds meer op flexibiliteit in de opdracht, maar was dat ook al zo bij de opzet van dit systeem? En was het nadat het project eenmaal zijn (te trage) tempo had bereikt alsnog mogelijk om zoiets te gaan implementeren?

Bijkomend is het niet aan de overheid om een externe firma te gaan aansturen. Bij de overheid moet men niet van scrum gehoord hebben. De firma die de ontwikkeling doet moet dat wel natuurlijk.

[andreetje]

Als ontwikkelaar moet je inderdaad om kunnen gaan met wijzigingen in de requirements.

Daar heb je ook ervaren ontwikkelaars voor nodig. Als je bijvoorbeeld OO niet goed beheerst, bouw je oplossingen die niet flexibel zijn. Dan worden wijzigingen in de requirements enorme drama's (spaghetticode / puisten).

[KopjeThee]

Misschien is het fiasco inderdaad ook te wijten aan te complexe processen binnen de organisatie. Het doet me denken aan:
http://www.eur.nl/mandeville/lezingen/16/lezing/

Wat is ESSA? Het is de afkorting van Elimineren, Simplificeren, Standaardiseren en Automatiseren. Als in een groot bedrijf de leider niets doet , dan maakt de organisatie zichzelf telkens complexer. Als student herinner me ik het voorbeeld van een professor die vertelde over een groep managers van een bedrijf die waren opgesloten op een mooi kasteel met golfbaan zonder taakopdracht of doel. Na twee dagen hadden ze het zo druk met van alles dat ze hun golf moesten afgelasten.

Ook als u zegt “Stuur maar een kopietje”, dan voegt u al complexiteit aan het proces toe. Veel topleiders onderschatten hoeveel tijd aan - vaak terloops gestelde - vragen van de leiding wordt besteed. Mijn wijsheid is dat goede leiders leiden door telkens te elimineren. Het gaat om het hebben van focus op het eigen bedrijf en de klanten, er moet geen tijd worden verspild aan niet essentiële activiteiten.

Kortom: elimineer niet essentiële processen. Maak overige processen zo eenvoudig mogelijk. Standaardiseer processen: Proces van inkoop helm en uniform gelijk maken, om dat voorbeeld aan te houden. Ga daarna automatiseren.

[Reactie gewijzigd door KopjeThee op 23 juli 2024 13:50]

[Anoniem: 670995]

Je bedoelt vast "elimineer niet-essentiele processen"? ;-)

Ik denk inderdaad dat factor "organisatie" een groot onderdeel van de root cause is. Heel veel politiek en eilandjes met macht die eigen dingen ontwikkelen. Geen centrale sturing.

[FreezeXJ]

Da's de theorie... en dan denken sommigen: outsourcen! Want daarmee 'elimineer' je de processen toch? Fout. Je vervangt dan het oorspronkelijke proces door het aansturen van een extern team dat je proces moet uitvoeren. Zeker bij processen die nauw verweven zijn met andere processen ben je dan al snel duurder en trager uit. Je moet alsnog kunnen beoordelen of de externe goed werk aflevert, en dat kost tijd en geld...

Je ziet het aan heel veel dingen, dat in de poging om het makkelijker te maken, het leven alleen maar lastiger wordt. Met alle frameworks tegenwoordig ben je eerst maanden bezig om het framework te begrijpen, en moet je alsnog de onderliggende taal kennen, en alle valkuilen erbij, anders krijg je Heisenbugs, en andere narigheid, die je niet begrijpt zonder te weten wat er gebeurt.

[Verwijderd]

Als je ziet hoe de overheid IT heeft ingezet dan is dat duidelijk het ingewikkelder maken van de regels. Ze had ook de processen ingericht voor bestaande regels kunnen automatiseren en de zo ontstane overhead kunnen laten afvloeien. Die mensen zouden nu productief werk doen in plaats van onze welvaart verminderen.

[andreetje]

De IT van de overheid moet voldoen aan de wetgeving. De wetgeving wordt steeds complexer. Dat komt door politici die door het volk worden gekozen.

Wat moet je dan als overheidsdienst? Alles nog met de hand doen? Dan hebben we nog veel meer ambtenaren nodig.

Wat nodig is, is een radicale versimpeling van ons fiscale systeem.

[KopjeThee]

Bij de belastingdienst kan ik me dat voorstellen, maar dat zou bij defensie in veel mindere mate een rol moeten spelen, lijkt me.

Processen bij de overheid moeten inderdaad radicaal eenvoudiger om beheersbaar te blijven/worden. Ik vermoed dat we miljoenen, zo niet miljarden aan belastinggeld verspillen aan hopeloos ingewikkelde regels. Die regels ontstaan door een soort handjeklap van politici: Ik steun jouw regeltje x, maar dan wil ik uitzondering y. Dan houden we onze kiezers allebei tevreden.

Misschien moet er een politieke partij komen die niet per se links of rechts is, maar van de vereenvoudiging. Partij van de eenvoud. Ik steun jouw regel x, als je hem eenvoudiger maakt of beter laat aansluiten op bestaande regels/systemen etc. En verder heeft de partij natuurlijk als speerpunten allerlei regelgeving die met weinig gevolgen eenvoudiger kan.

[Reactie gewijzigd door KopjeThee op 23 juli 2024 13:50]

[andreetje]

Mee eens. Het gepolder heeft een belachelijk ingewikkelde wetgeving tot gevolg. Een corrupte wetgeving, want de burger begrijpt het niet meer.

Ik weet niet of de Nederlandse wetgever ook een defensiesysyeem ingewikkeld maakt. Het is wel zo dat bijvoorbeeld de zorgadministratie veel tijd kost door de eisen die de overheid / zorgverzekeraars stellen.

[kidde]

Uhuh, regels moeten simpeler.

1) Defensie gaat voortaan besparen op de papierkraam bij haar luchtvaart, procedures worden vereenvoudigd, luchtwaardigheidscertificaten en alle dubbelchecks afgeschaft. Boutjes mogen voortaan ook zonder papierkraam uit China van A|liexpress komen.

2) Transparantie van de kosten kost alleen maar geld, dus schaffen we ook af.
Een van de doelen van SPEER was vziw inzage in wat missies kosten. Dus als een vliegtuig voor 20 ton is onderhouden waarvan 5 ton in Nederland en 15 ton omdat er in Mali zand in kwam, gooien we dat weer ouderwets op een hoop en noemen het gewoon "onderhoud". Als iemand vraagt aan de minister wat de inzet in Mali kost, vinden we het voortaan weer prima dat ze dat niet weet. A|ls we willen weten wat JSF-onderhoud kost, vinden we het prima dat ze dat niet weet omdat het op een hoop wordt gesmeten met het onderhoud van schepen, "want dat scheelt een hoop bureaucratie".

Populistisch commentaar leveren is makkelijk, "willen we meer of minder bureaucratie?" --> "Minder, minder, minder..."

[KopjeThee]

Ik vraag me af hoeveel Wim Koks er nog rondlopen op belangrijke posities:
http://www.zideo.nl/playzideo/6d6f6d576f46303d
Mensen die grofweg weten dat er iets als IT bestaat en zich hebben laten vertellen dat je daar allerlei ingewikkelde problemen mee kunt oplossen o.i.d.

[Vexxon]

Het kan zijn dat specs veranderen maar ik mag toch aannemen dat er een offerte is opgesteld waarin overeengekomen is wat wordt opgeleverd en wat niet. Als de specs dus veranderen dan is dat meerwerk en zorg je als leverancier dat de basis eerst werkt en rekening houdt met de uitbreidbaarheid van het system, wat sowieso common practice is. De nieuwe specs kunnen dan daarna geïmplementeerd worden of direct als deze niet dramatisch zijn. Als leverancier ben je er zelf ook bij om zoveel mogelijk wensen boven tafel te krijgen dus de leverancier heeft hier ook een beetje zitten slapen of gehoopt op een langdurig project om de zakken te vullen. Ik hoop dat snel bekend wordt wie die leverancier is dat zijn toch ook wel een beetje prutsers of onbetrouwbaar.

Het is waarschijnlijk zoals emnich hieronder aangeeft. De projectleiders van defensie hebben zitten slapen en de leveranciers hebben daar misbruik van gemaakt. Als leverancier deug je dan gewoon niet. Als blijkt dat dat waar is dient de betreffende leverancier uitgesloten te worden van overheidsprojecten.

[Reactie gewijzigd door Vexxon op 23 juli 2024 13:50]

[ninjazx9r98]

Leuke theorie maar zo werkt een aanbesteding niet. De wensen/eisen staan van tevoren vast en kun/mag je niet over onderhandelen. Je maakt een offerte op basis van wensen/eisen en tijdens de aanbesteding mag er geen direct contact zijn met de klant. Er is een vragenronde maar vragen en antwoorden zijn/worden openbaar voor iedereen die mee doet.

[Pinkys Brain]

Dan moeten ze gewoon op laten leveren als open source oplossing waar er bij de aanbesteding over is onderhandelt en niets meer. Niet na de aanbesteding proberen opnieuw te onderhandelen want dan zit je in een slechte positie.

Er moet een duidelijk contract zijn en ze moeten maar leveren op straf van boetes ... anders krijg je moral hazard. Nu is er een miljard betaalt voor iets wat zo te horen een website boertje in een paar weken in elkaar draait en niemand word er op afgerekend.

[Reactie gewijzigd door Pinkys Brain op 23 juli 2024 13:50]

[ninjazx9r98]

Welke onderhandeling bij de aanbesteding? Dat is nu net wat ik zeg en waar je op gereageerd hebt, er is geen onderhandeling tijdens een aanbesteding. Er is een heel boekwerk waarin exact beschreven staat wat er geleverd moet worden en wat er verwacht wordt van de inschrijvende partijen. Tijdens het proces kun je vragen indienen als zaken niet duidelijk zijn maar zowel de vragen als de antwoorden worden vervolgens openbaar voor alle ingeschreven partijen.
Voor wat betreft dat website boertje, dat hele "zo te horen" is het hele probleem van dit soort discussies, de beste stuurlui staan zoals altijd aan wal en het is makkelijk roepen als je feitelijk niet weet wat er exact opgeleverd moet worden en tegen welke voorwaarden.

[CrimsonLance]

Er bestaat een aardige 'docu' over een vergelijkbaar process tijdens de ontwikkeling van de "Bradley" en het Pentagon.

[-Moondust-]

"dit is nog los van het feit dat men vaak helemaal niet weet wat men wil. "
Dat is idd een groot probleem dat je overal ziet. Voor requirements is vaak geen of weinig aandacht. Met alle gevolgen van dien. Op zich is het niet erg dat je niet precies weet wat je wil, maar kies dan een ontwikkelmethodiek die daarbij past, zoals een kortcyclisch methodiek als Agile.

[ninjazx9r98]

Requirements staan gewoon in het bestek en op basis daarvan wordt de offerte gemaakt en vindt er uiteindelijk een gunning plaats. Problemen ontstaan als men iets anders wil dan wat gevraagd en aangeboden is. Niet weten wat je wilt kan in principe niet bij een aanbesteding, dat staat juist van tevoren vast en is uitvoerig omschreven.

[thegve]

Kan in principe niet, maar zie je wel degelijk. Ik heb diverse aanbestedingen gelezen, en regelmatige met tranen in mijn ogen van het lachen gestaan wat je daar in tegen komt. Voorbeeldje, een beheerovereenkomst met een basisschool-cluster (ook Europese aanbesteding) waar in staat dat ieder probleem, wat de oorzaak ook is en wat de impact ook is (kort samengevat, die aanbestedingen zijn uiteraard lijvig), binnen 3 uur dient te zijn opgelost. Natuurlijk kan dat. Dat zou wel vereisen dat de opdrachtnemende partij een landelijk dekkend netwerk heeft, a la de brandweer, met overal een compleet IT inventaris en een compleet team dat dat binnen no-time kan installeren. Hier is overigens op ingeschreven waarbij die eis feitelijk werd genegeerd en er vanuit gegaan werd dat de soep niet zo heet werd gegeten als die werd opgediend.
En zo gaat dat maar door. En doorgaans "op basis van bestaande hardware", zonder dat je eerst een overzicht krijgt van wat ze daar dan hebben staan.

[ninjazx9r98]

Eisen negeren kun je uiteraard gewoon doen, moet je wel even het risico (willen) nemen dat je een hele berg werk verzet hebt en vervolgens wordt uitgesloten omdat je niet voldoet aan de selectiecriterie. Als eisen (voor jouw werkgever/bedrijf) niet haalbaar zijn moet je simpelweg niet inschrijven, komt ook wel eens voor dat helemaal niemand inschrijft.
Voor wat betreft dat "op basis van bestaande hardware" is het gewoon een kwestie van de vraag stellen wat die bestaande hardware dan precies is en dan krijg je samen met alle andere inschrijvers keurig netjes antwoord.

[Loft]

Zeker mee eens. Ik zit zelf soms in die situatie. Bijna altijd blijkt dat er een het begin geen duidelijk doel + PvA/PvE opgesteld is. Opdrachtgevers willen soms onderste uit de kan en kunnen vaak specs veranderen, maar dit is wel erg extreem.
Temeer de gevraagde functionaliteit (zoals geschetst bij t.net) standaard leverbaar is in standaard producten.

Dergelijke maatwerk systemen zijn steeds minder nodig, Alleen voor klanten die echt iets unieks doen en dat zijn er steeds minder. Gecombineerd met steeds beter wordende standaard applicaties zou dit minder voor moeten komen....

Helaas zijn er nog steeds bedrijven die dergelijke projecten leuk vinden en het niet boeit dat het uitloopt, want ze mogen mensen leveren.....

[polthemol]

het lijkt me dan toch dat je met runs gaat werken ? Nieuwe eisen worden in een volgende run meegepakt, eerst afmaken wat de hoofdeisen zijn. Precies om te voorkomen dat je continu aan alles moet blijven sleutelen.

[we_are_borg]

Het kan wel wezen dat de klant om meer werkzaamheden vraagt dan wat is afgesproken maar aan het einde van het verhaal dient de leverancier aan te geven of iets haalbaar is. Helaas zien dit soort bedrijven alleen het geld voor zich en nemen ze niet de verantwoordelijkheid om nee te verkopen.

Ik denk ook dat de wet aangepast dient te worden bouw en software makers genieten namelijk vergaande bescherming als hun over budgetten heen gaan.

[nlinzweden]

Wat is er zo wezenlijk anders aan een helm? Moet de "vorm" van de database anders, omdat een helm minder goed opvouwt, misschien? Heb je niet een wat realistischer voorbeeld die iets te maken heeft met veranderende data structuren?

[TIGER79]

Het is natuurlijk alleen een voorbeeld van veranderende requirements tijdens ontwikkeling, dat zorgt altijd voor vertraging of de ene functionaliteit inleveren voor een andere...
Ook doelt hij hiermee op het feit dat een klant vaak iets onderschat, ach als je al dit doet kan je ook dit erbij doen. Dat hoeft niet veel extra tijd te kosten afhankelijk van hoe ingrijpend het is onder water en niet vanuit het oogpunt van de klant die er geen verstand van heeft...
Een helm heeft natuurlijk andere soorten maten, andere materialen en dus ook bijbehorende modellen, en moet het een helm of moet het een relationele database worden waarbij deze valt onder hoofdwaar, want jah wat is dan een baret en de gewone pet...

[torp]

Je zou toch denken dat er inmiddels wel een systeem bestaat dat met dergelijke verschillen/functionaliteiten rekening houdt. Uit de losse pols: een overkoepelend systeem waarin per onderdeel een format kan worden bepaald. Dan hoef je bij een nieuwe kwestie niet helemaal van voren af aan te beginnen maar kun je een module toevoegen voor bijv. insignes (uniform) of palletwagens (werkplaats) met de bijbehorende keuzemogelijkheden (al dan niet complex).

[Het.Draakje]

Het is een ERP systeem. Dat soort systemen kan alles, maar (uiteraard) moet je dat alleen nog "afregelen". Ik heb hetzelfde systeem gebruikt zien worden voor tijdregistratie en facturatie, effectenadministratie en voorraadbeheer.

Het afregelen kost meestal een jaar of twee en normaal gesproken krijg je ook iedere 18 maanden een nieuwe release. Implementatietijd van zo'n release is al gauw 6 - 12 maanden. (Vaak worden dan ook releases overgeslagen).

Als ik een aantal uniformen moet administreren dan is het simpel. Maar op welke manier administreer je een tank? Als unit of als losse onderdelen (omdat die vervangen kunnen worden). En die laptop, daal je daar af tot het niveau van geheugenmodule (en registreert/registreerde de monteur alles nauwgezet?)
Wat doe je met diesel en benzine? En kogels. Zou de soldaat een bonnetje moeten inleveren iedere keer als hij de trekker overhaalt?

Verder werkt het systeem nu aardig (voorraad en onderhoudsplanning) Maar inkoop, begrotingen en plannen van (vredes)missie's gaat niet (uiteraard omdat dat soort processen nauwelijks beschreven zijn).

Ook de Amerikanen raken tijdens de missie's alles kwijt en laten na afloop ook veel staan. Omdat terugzending te duur is en juiste administratie ontbreekt. Dergelijke systemen bestaan dan ook niet voor defensie. Ik begrijp de beslissing voor a) toch zelfstandig een overkoepelend systeem te gaan gebruiken en b) voor een 'standaard' ERP pakket, dan ook niet echt.

[Blokker_1999]

Bij ons draait vandaag zowat alles op SAP (ik denk zowat het bekendste ERP systeem). Logistiek, productie, HR, tijdsregistratie, boekhouding, communicatie met de klant, CMS, ... . Ik denk dat we ondertussen zowat 10 jaar bezig zijn. De eerste systemen zijn op 01/01/2009 omgezet en nog altijd is men bezig met zaken toe te voegen.

En dan is het nog maar de vraag of de mensen die het systeem ontworpen hebben een gevoel hebben met de werkvloer. Wij doen op onze dienst herstellingen van wisselstukken maar werken in SAP met de productieplannings modules. Een verdomd slechte keuze waardoor er weer vele nieuwe problemen ontstaan. Maar we moeten spijtig genoeg roeien met de riemen die we hebben.

Ik zie trouwens niet in waarom defensie geen baat zou hebben bij een goed werkend standaard ERP pakket. Stock die je achterlaat is niet zoveel anders dan verbruiksgoederen die je ergens voor nodig hebt. Stock correcties moet je trouwens ook sowieso uitvoeren ongeacht of je nu een kleine zelfstandige bent of je nu Amazon bent. Iedereen verliest wel eens materiaal en moet regelmatig stockcorrecties doorvoeren.

[nlinzweden]

Uiteraard is het maar een voorbeeld.

Misschien is dit een mooie analoog: een fabrikant richt zich op telefoons met, zeg, Symbian. Prachtig, gerichte oplossing. Maar ja, klant wil iets anders, wil swypen. Gaan de bestaande klanten nu een tweede keer betalen? Ja, want ze kopen een nieuwe telefoon. Een verschilletje is wel dat de eerste telefoon het wel gewoon gedaan heeft.

Maar wat ik wil weten: welke ontwerpfouten zijn er gemaakt die het slecht aan te passen maakt. Ik wil wel eens weten wat er fout is gegaan. Was het de Cobol implementatie? Kan Oracle SQL niet met helmen omgaan? Kostte het maken van een nieuwe tabel in the RDMS 50 miljoen?

1 miljard euro is wel verschrikkelijk veel geld. Hoeveel JSFs is dat?

[StGermain]

Onderhoud inbegrepen (kerosine niet) had je met de 433 miljoen waarvan sprak in het artikel 2 (twee) JSF's up and running kunnen houden tenzij ze neerstorten tijdens gebruik.

bron: http://www.dewereldmorgen...ons-effectief-gaat-kosten

[Cilph]

Helmen moeten misschien hele andere stappen en protocollen doorlopen dan uniformen, terwijl de hele applicatie intussen toegespitst is op uniformen.

[nlinzweden]

... terwijl de hele applicatie intussen toegespitst is op ...

Ja, dat wil ik dus graag weten: heeft het bedrijf zich niet gewoon gericht op modulariteit en hergebruik, maar zich onnodig toegespitst op toeters en bellen? Misschien niet, maar dan wil ik dat zien en niet iets nietszeggend over helmen en broeken.

[onkl]

In mijn ervaring is dit inderdaad het cruciale probleem:
De interactie tussen een klant die voortdurend aan de scope zit te rommelen en een leverancier die de best practices in het platform negeert of, nog erger, helemaal niet blijkt te kennen.

Dan zie je het volgende patroon ontstaan:
1: Klant vraagt om een uiterst specifieke oplossing.
2: Leverancier gaat los met allerhande maatwerkontwikkeling en ontdoen het pakket zo van iedere modulariteit. Bovendien worden vaak krachtige concepten in de vanilla applicatie om zeep geholpen door onhandige afhankelijkheden te kweken.
3: Klant bleek geen idee te hebben van zijn eigenlijke functionele behoefte voegt at random wensen (da's een ander woord voor eisen) toe.
4: Leverancier gaat zijn eerdere maatwerk niet slopen, maar er met extra maatwerk weer omheen werken.
5: goto* 3

Door de bestaande aanbestedingslogica gebeurt het vaak dat de overheid zaken doet met leveranciers die zo groot zijn dat ze meer gefocust zijn op interne projectcontrole en klant/relatiebeheer dan op diepgaande kennis van de spelregels in het onderliggende platform. (Sogeti, Atos, etc.)
En dat is nou net het soort leverancier wat een grote, ambtelijke organisatie nodig heeft om bovenstaand contraproductieve spelletje goed te kunnen spelen.

*Hoi EWD.

[potterkop]

als ontwikkelaar / architect hou je rekening met veranderende specs . dus bouw je generiek.

[_eXistenZ_]

Daarom Scrum!

http://en.wikipedia.org/w...28software_development%29

[veltnet]

Een project heeft een startdatum een prognose einddatum en een budget. Als dat er niet (of als niemand zich er aan houdt) is dan kun je het geen project noemen. Het lijkt erop dat dat hier het geval is.

[Reactie gewijzigd door veltnet op 23 juli 2024 13:50]

[emnich]

Overheid of niet, maar dit slaat als een tang op een varken. Jij bent de klant. Jij bent degene die eisen stelt.

Meer dan eens is dát ook precies waarom dit soort projecten mislukken. De klant blijft nieuwe eisen stellen en de maker voert dat uiteraard graag uit.

Dat die nieuwe eisen niet verenigbaar zijn met eerdere eisen of met eisen van andere delen van de software lijkt dan niet van belang.

Ik vermoed dat er bij de (project)managers van defensie erg veel fouten zijn gemaakt en dat de leverancier(s) daar dankbaar misbruik van hebben gemaakt.

[dmantione]

Als informaticus moet je er (helaas) altijd van uitgaan dat de klant niet in staat is zijn specificaties goed op te stellen. Bouwen wat de klant vraagt is niet voldoende voor een succesvol automatiseringproject. Je moet door de specificaties heen zien wat de klant wil bereiken en soms zelfs keihard ingaan tegen wat hij direct vraagt. Dat vereist behalve vakmanschap op het gebied van programmeerwerk ook behoorlijke kundigheid in de sociale contacten met de klant.

Een implementatie kan je altijd aanpassen. Als het ontwerp echter verkeerd gekozen is, dan komt het in veel gevallen nooit meer goed met een systeem.

[enchion]

Tegen de klant ingaan hoeft niet perse, maar wel in ieder geval als de klant een "TopDown-AllIn" oplossing zoekt. (maw alles in 1 keer wil omgooien.)

Meestal zal er binnen de grote bedrijven/organisaties (waar de order vandaan komt) een grote groep mensen zijn die zeggen, "maar het oude systeem werkt toch goed", waar die mensen dan ook groot gelijk in hebben.

Het oude systeem is nl vaak door Evolutie tot stand gekomen, oftewel door over lange termijn steeds kleine problemen op te lossen. (Evolutie heeft zich nl ook bewezen te werken over 300miljoen jaar als je het leven als een complex programma ziet, "TopDown-AllIn" oftewel Revolutie heeft als bijwerking altijd een vorm van uitsterfte/extreme-aanpassings-periode)
Er is daardoor geen goede reden om dat soort proces niet te gebruiken bij de initiele aanbesteding.
Maw eerst alle problemen/gezochte-oplossingen/verbeteringen in kaart te brengen, en daar eerst te kijken of alleen de ergste opgelost kunnen worden om zo tijd te creeeren voor de volgende stap, doordat je door die verbetering ergens tijd/geld/capaciteit binnen je organisatie overhoudt.
Oftewel als je een Noord-Zuid lijn aanlegt ipv parallel dus serieel te gaan bouwen, en dan dus eerst 1 sectie te gaan bouwen, AdamCS naar bv het Damrak, en wanneer dat goed gaat (70% af is) de volgende sectie van Damrak-Munt.
Dan kan er al in ieder geval iets gebruikt worden of afgemaakt worden, en als de aanbesteding te duur wordt kan er ook altijd alleen die portie/sectie afgemaakt worden waar men als 1e mee begonnen is om vervolgens met het project te stoppen. (je hebt dan in ieder geval wat, ipv na 10 jaar nog niks)

Bijna alle grote software bouwers (OS bouwers, ontwikkelsoftwarebouwers, grote gamedevelopers) zijn inmiddels naar zo`n Evoluerend-Update systeem overgestapt (zelfs MS), gewoon omdat dat de enige manier is die echt werkt.

Ik hoop dus ten sterkste dat overheden dat ook zijn gaan inzien, en dus hun wensen pakket wat strategischer maw in kleinere porties gaan opdelen, om zo dus als een project lijkt te gaan mislukken makkelijk te kunnen overstappen naar een andere contracteur zonder de extreme kosten, en ook dus als die contracteur ja zegt op een "TopDown-AllIn" wens dat juist ziet als indicator om de aanbesteding af te blazen.
Daarbij is het ook interessant geworden voor de contracteur zelf om het opgesplitst te hebben, nl des te groter de kans dat elke stap positief wordt afgerond en dus des te vaker die in het nieuws kan komen met goed nieuws.
En als het misgaat, de informatie dat het misgaat aan het begin van het totale traject zit ipv aan het einde, waardoor die informatie nog in het leerproject gebruikt kan worden.

[Reactie gewijzigd door enchion op 23 juli 2024 13:50]

[andreetje]

Kort gezegd: als voor de bouw van een systeem meer dan twee jaar nodig is, moet je er gewoon niet aan beginnen.

Opknippen in afzonderlijke modules is een keiharde noodzaak.

[veltnet]

In Prince2 wordt dat de product breakdown genoemd.. Net zo lang opdelen van problemen tot het geen problemen meer zijn maar triviale acties.

[andreetje]

Inderdaad.

Ik hoorde eens van iemand die bij een automatiseringsproject van de politie werkte... Er werkten 80 man aan één project. Hij raakte aan de praat met zijn voor hem onbekende buurman. Het bleek dat ze precies dezelfde functionaliteit aan het bouwen waren, zonder dat ze dat van elkaar wisten.

Er was gewoon geen overzicht meer.

Managers denken dat twee keer zo veel IT'ers ook twee keer zo veel functionaliteit in dezelfde tijd oplevert.

[polthemol]

ik denk dat de meeste klanten een systeem willen wat "alles" kan en het liefst voor niets
Dit project lijkt in ieder geval in de leerboeken te kunnen gaan als een standaardvoorbeeld voor scope creep en waarom je met harde deadlines moet werken best, budgetcontrole handig is enz.

Eerlijk gezegd snap ik vooral niet hoe ze aan zoeen immense uitgaveposten komen. Als ik de omschrijving lees: dit is precies wat autoproducenten gebruiken: wat staat waar met welke voorraad, welke reserveonderdelen hebben we waar op voorraad. Nu kennen we de complete eisenlijst niet, maar heel erg spannend doet het me eerlijk gezegd niet aan.

[Bruin Poeper]

Als het ontwerp echter verkeerd gekozen is, dan komt het in veel gevallen nooit meer goed met een systeem.

Ik vrees, gezien de lange looptijd, dat men ging beginnen met een idee voor een ontwerp.
Zoiets kan je doen als R&D-onderzoeksproject, maar niet om afhankelijk van te zijn voor je bedrijfsprocessen.

Gelet op de gemiddelde levensduur van software wou ik voor bedrijfsomstandigheden toch wel graag binnen een paar maand, hooguit 1 jaar, een werkend principe-syteem willen hebben, en anders gaat het op een zijspoor of direct de vuilnisbak in.

Als je begint met ontwerp moet je de R&D al achter de rug hebben!

[Reactie gewijzigd door Bruin Poeper op 23 juli 2024 13:50]

[Floor]

Nee, leverciers zijn gebaat bij falen.
Pas wanneer ze gebaat zijn om een project te voltooien wordt het een succes. Ik heb al menig maal met ICT projecten te maken gehad. En door schade en schande geleerd dat je de afspraken zo moet maken dat de leverancier gebaat is bij succesvol opleveren. Dat is geweldig smeermiddel om een project tot een succes te maken

[cbravo2]

Nou dat werkt ook niet goed. Je hoeft dan alleen maar de definitie van succesvol opleveren te veranderen. Voila, job done. Maar of jij er vervolgens je doelen mee kan bereiken is nog steeds niet gezegd.

En dan komen we weer terug bij het originele plan: Goed definieren wat je wil (welk doel wil je ermee bereiken).

[catfish]

het probleem (uit eigen ervaring met software binnen grote bedrijven / overheid):
- de project manager kent helemaal niets van software ontwikkeling waardoor het bestek niet goed is
- de analist van de softwarebouwer maakt er een zootje van omdat deze de opdracht puur vanuit de software bekijkt en de praktische werking helemaal vergeet
- vervolgens wordt het code kloppen (als ik dat zo mag noemen) gedaan door mensen die het geheel niet zien en hele rare bugs veroorzaken (je zou soms bijna denken dat ze het expres doen)
- het programma wordt zonder veel testen in productie gegooid (want de baas wil resultaten zien)

gelukkig gaat het soms wel goed
bij de grotere projecten (zoals deze) gaat het echter ALTIJD mis
men moet werken aan aparte systemen, nooit 1 geheel
vroeg of laat komen er immers wijzigingen en het is veel gemakkelijker om een klein pakket te vervangen ipv een groot geheel aan te passen

[Bruin Poeper]

gelukkig gaat het soms wel goed
bij de grotere projecten (zoals deze) gaat het echter ALTIJD mis

"Gelukkig gaat het soms wel goed"

Als in een boek kan uitleggen waardoor dat komt zou je een Bestseller hebben.

[andreetje]

Kleine projecten, ervaren ontwikkelaars, veel tijd voor testen.

Ik zal het even in 350 bladzijden opschrijven!

[Stoney3K]

[...]

Meer dan eens is dát ook precies waarom dit soort projecten mislukken. De klant blijft nieuwe eisen stellen en de maker voert dat uiteraard graag uit.

De reden dat de klant nieuwe eisen blijft stellen is ook te verklaren: Dat heeft te maken met de Europese aanbestedingsregels.

Boven een bepaald bedrag moet een project EU-breed openbaar worden aanbesteed, maar als je onder een bepaalde kostprijs gaat zitten hoeft dat niet en ben je vrij om je leverancier te kiezen.

Wat er dus vaak gebeurt is dat de leverancier een opdracht krijgt voor een kleine prijs (bijvoorbeeld een miljoen) en er daarna de hele tijd nieuwe specificaties worden doorgegeven. Zo kan de overheid ervoor kiezen om een "vertrouwde" leverancier te kiezen en het hele project te boeken als "meerwerk".

Dat dat vaak in het honderd loopt omdat iedereen een andere mening heeft over dat meerwerk wordt bijna altijd over het hoofd gezien.

[Verwijderd]

Om je reeks jijen ff af te maken: "jij bent diegene die de specificaties hebt opgesteld"

Mijn ervaring is dat het hier het vaakst fout gaat. Daarna gaat gewoon alles fout.

[Anoniem: 670995]

Ik neem aan dat je opstellen en goedkeuren dan synoniem aan elkaar ziet. In dat geval: ja. Maar vaak is degene die goedkeurt niet diegene die opstelt en dan begint het gedonder.

[LopendeVogel]

Haha, is toch gewoon ''slim'' (vuil tegelijkertijd)?

Stel jij hebt oneindig geld wat niet van jou is maar wel mag uitgeven (belasting:) ), en stel jij bent een goede vriend van mij.
Jij huurt mij in, en betaald mij een vetpot, uiteraard krijg jij ook wat geld weer van mij. We stellen een contract op van 6 jaar, hebben we een flinke slag geslagen..

Stel de audi a6 word saai na die 6jaar, dan wil je een audi a8, wat doe je dan? Hoppa nog een 6 jaar erbij en jij en ik rijden allebei een audi a8. Heerlijk toch??

Uiteraard zou ik niet slapen, aangezien ik 100% van de tweakers hier aan het naaien ben, mijn buren, mijn familie en iedereen. Maar goed hun ''de overheid'' kunnen het blijkbaar wel.

Kan een alu hoedje zijn hoor, maar waarom kan de overheid niks, en elk ander bedrijf wel? Elk ander bedrijf doet het van hun hard verdiende geld, de overheid hoeft niks te doen voor dat geld, die krijgen het van ons. Krijgen ze niet genoeg? hoppa belasting tarief omhoog en klaar. Wij werken wel zodat hun het kunnen uitgeven. Bleh, nu ik er weer steeds meer over nadenk word ik weer misselijk.

Tijd voor een leuke film, aan de overheid denken op een zaterdag avond is het minst leuke wat ik kan doen!

[veltnet]

Heeft er mede mee te maken dat de overheid slecht tegen kritiek kan en dat het bij de overheid moeilijk is om (opbouwende) kritiek te geven. Dit wordt meestal niet gewaardeerd en vervolgens genegeerd.

[YangWenli]

Jezus dit is erger dan "the last guardian"

[djs909]

De ict "leveranciers" van de overheid lachen zich dood, ze kunnen eindeloos blijven factureren, de overheid betaalt het wel. Ja sorry, het loopt een beetje uit, dit konden we niet voorzien, bla bla bla. Gebeurt overigens niet alleen met ICT, kijk maar naar geweldige projecten zoals de Noord-Zuidlijn in Amsterdam. Is die al af?

[Gustaaf437]

Laten we de officiële cijfers even aanhouden.

Bijna 440 miljoen in 11 jaar.
Dus 40 miljoen/jaar.
Als je uitgaat van 100.000 per werknemer per jaar die betaald wordt, kom je op 400 fulltimers voor dit project.
Dan gaat het dus om 400 * 40 (uren/week) * 45 (volle werkweken) = 720.000 manuur per jaar.
In totaal zou er dan 720.000 * 11 = 7.920.000 manuur aan zijn gewerkt.

Nu lijkt het me onmogelijk om 400 man tegelijk aan een project te laten werken. 100 lijkt me al veel, maar dan zou er voor iedere werknemer per jaar 4 ton worden neergelegd, dat is totaal idioot.
De overheid heeft hier minimaal een nul teveel betaald, maar in het geval dat het bedrag richting de miljard gaat waarschijnlijk wel 2.

Het lijkt me goed om te kijken naar de rol van de leverancier hier, want dit is echt niet in de haak.

[sschalkwijk]

Natuurlijk is een mislukt project als dit van de zotten. En vermoedelijk zaten er een paar incompetente managers bij beide partijen die een prestige project wilden beginnen met de instelling "Hoe duurder hoe beter!" Maar veel mensen vergeten vaak waar de kosten in gaan zitten.

Je vergeet even dat een bedrijf nog andere kosten heeft buiten de werknemers. Hieronder vallen vaste lasten zoals kantoorpanden onder, belastingen, investeringen ect. Daarnaast heeft een bedrijf ook een winstoogmerk dus moet er winst gemaakt worden.

400 mensen fulltime zullen het nooit geweest zijn. Ga er even vanuit dat een werknemer tussen de 40.000 en 50.000 Bruto krijgt per jaar. Dan kost dat het bedrijf minimaal 100.000 per jaar.
Maar een bedrijf kan dan natuurlijk niet 100.000 per jaar factureren. Meestal moet een werknemer 3 tot 5 keer zijn kosten opbrengen. Dat betekend dat als een werknemer 100.000 per jaar kost. Deze werknemer tussen de 300.000 en 500.000 per jaar moet opleveren.

Dan zitten er nog geen "managers" en "projectleiders" tussen die vinden dat ze 100.000 per jaar moeten verdienen en het bedrijf dus 200.000 kosten. Als gevolg daarvan moeten deze minimaal 600.000 per jaar opleveren.

Dan wordt er wellicht nog ingekocht bij andere partijen die ook zulke bedragen rekenen. En daar moet natuurlijk ook weer een marge overheen voor de bemiddeling.

[HeldereM]

6 ton per jaar? Sorry hoor maar dat zou betekenen dat deze persoon 330,- per uur zou factureren. Mag hopen dat je dat zelfs bij de overheid niet voor elkaar krijgt.

[Darkstriker]

Het is onzin de gehele kosten van dit project op werknemers af te schuiven. Waarschijnlijk is makkelijk 50% of meer aan hardware besteed. En de aanname dat er maximaal 400 mensen aan hebben gewerkt is ook totaal uit de lucht gegrepen. Er kunnen veel meer mensen aan een project werken. En aangezien dit project voor het hele leger bedoelt was zal het aantal ook zeker wel groter zijn.
Aan de andere kant ik 200-300k voor hoogopgeleide technici (de meeste mensen die hieraan hebben gewerkt zullen geen eenvoudige icters zijn geweest) en managers helemaal niet gek. In de private sector krijgen ze meestal meer.

[Reactie gewijzigd door Darkstriker op 23 juli 2024 13:50]

[Garyu]

Nou nou, laten we het ook niet overdrijven. Een uurprijs van 150€ is al redelijk hoog voor het gros van de mensen die aan een dergelijk groot project werken. In die 150€ zitten dan wel alle kosten van een dienstverlener inbegrepen, dus ook zijn manager, de HR afdeling en de afschrijving op zijn computer.

Bij een gemiddeld aantal van 1680 uren per jaar kom je dan op 250k€ per persoon per jaar.

Natuurlijk moet je de hardware ook niet vergeten, maar dat is zeker geen honderden miljoenen aan hardware, misschien dat er 40M€ hardware-kosten bijzitten, dat lijkt me al een aardige som eerlijk gezegd. Dan blijven er dus nog 400M€ over. Bij 40M€ per jaar is dat dus werk voor 160 mensen full-time.

[bonus]

440 miljoen and nothing to show for....
Diep triest, als we het dan toch al hebben over geld weggooien ! Tuurlijk we hebben een aardige groep mensen aan het werk gehouden en er zal vast wel iets van alle inspanning overblijven maar toch. En dan idd, als 440 miljoen de lading dekt want er zijn bij alle projecten dingen die er niet direct ondervallen. En evt. boetes voor niet nakomen van afspraken of toch evet. dingen moeten afnemen. Ik denk dat de beerput nog niet dicht kan...

Overheid/Defensie en ICT is geloof ik nog nooit een gelukkige combinatie geweest, wel een dure

[mkools24]

Naja het is niet helemaal weggegooid geld natuurlijk want er zijn vooral mensen en bedrijven mee betaald dus het geld zit nog steeds in de economie.

[Verwijderd]

Het is verlies van welvaart.

Diezelfde mensen hadden ook iets anders kunnen maken wat wel bruikbaar is!

Nu is het niet meer dan een high-tech versie van putje scheppen en weer dichtgooien en daar geld voor ontvangen (dat bij anderen die het beter inzetten is weggehaald).

[Gamebuster]

Apparatuur? Groot kantoorpand? CEO's met grote auto's?

[THA_ErAsEr]

Laten we er vanuit gaan dat er inderdaad 400 man 11 jaar aan gewerkt heeft. Wat zijn ze dan aan het programeren? Wat ik af leid uit het artikel is dat het registratie en automatisatie doet voor defensie, that's it?

Windows 7 heeft mogelijk hetzelfde aantal manuren nodig gehad.

[tellavist]

Ik stik bijna in m'n koffie man!
866 Miljoen voor een systeem wat voornamelijk registreerd wat voor materieel waar staat?!
Dat hebben we op mijn werk ook voor zo'n 4,5miljoen modems.
Dat heet een CRM systeem...
Ik snap niet hoe een overheid ergens 866 Miljoen aan uit kan geven aan iets wat niet blijkt te werken?!
Hoeveelste keer is dit en hoeveel geld hebben we als land letterlijk door het putje gegoten zien worden via de ICT weg?!

Denk dat ik mn zwarte klusjes maar weer eens wat op pak. zonde om te zien dat mijn welverdiende belasting centen zo over de balk gesmeten worden...

[player-x]

Ja ik zat ook even met mijn mond open te lezen, bij mij op werk (Statoil), werk ik met SAP, en daar doen we letterlijk alles op werk mee, wat het leger met dit gefaalde project wilde doen.

Het SAP systeem houd bij waar welk onder deel is, inclusief (GPS) locatie van in gebruik zijnde onderdelen, ook wanneer er onderhoud gepleegd moet worden, welk special gereedschap men nodig heeft, welke onderdelen vervangen moeten worden bij welk type onderhoud, en ook waar de reserve onderdelen liggen, en ik welk magazijn, en geeft een waarschuwing voor de onderhoudsdatum voor het bestellen van onderdelen.

En bij nieuwbouw projecten wordt er door de aannemers ook gebruik gemaakt van het zelfde systeem, en kan men zien waar de bepaalde onderdelen zijn, en zelfs hoever ze in het aanbouwproces zijn, en wanneer en hoe ze ge transporteert moeten worden naar de site.

Als de overheid niet weet hoe ze dat moeten doen, waarom kijken ze het niet af van bv Shell, die werkt ook met SAP, en heeft veel complexer materiaal als ons legertje, en die kan ook net als Statoil prima bijhouden waar, hoe en in welke staat alles is.

[Jaaps2]

Ik weet een beetje van speer en redelijk veel van erp voor een zeer groot oliebedrijf. Processen zijn net zo complex. En erp voor dat oliebedrijf heeft zeker zoveel gekost als voor defensie met diverse herimplementaties.

[player-x]

Maar wel met een verschil, dat het systeem werkt, of niet?
Hier bij Statoil werkt het iig, zelfs na overname van Hydro door Statoil, en de samenvoeging van de ICT systemen.

[Jaaps2]

Klopt, het werkt tamelijk goed. Al zijn ook daar issues geweest. Het was om aan te geven dat Speer / Defensie toch een heftig project is. Bij het oliebedrijf was ik o.a. deelprojectleider van een herimplementatie voor een middelgroot land waarvoor een projectteam van bijna 100 mensen een klein jaar werd ingezet.

[Blokker_1999]

Leuk dat SAP, enig idee wat dat dat grapje gekost heeft? Vooral als je eenmaal met customizing begint (kan me niet inbeelden dat GPS tracking bijv. een standaard onderdeel is van SAP).

Wij gebruiken ook SAP, als ik de prijzen hoor die daarvoor betaald zijn, hoeveel er verspeeld is aan opleiding en consulting en als ik dat dan vergelijk met hoe goed (of moet ik zeggen slecht?) dat het eindproduct werkt dan weet ik niet of SAP altijd de juiste keuze is.

Ik heb door de jaren heen trouwens voldoende negatieve verhalen van SAP gehoord, zowel intern bij ons als uit andere bedrijven. Er zijn spijtig genoeg heel veel eindgebruikers die vloeken op het systeem, ten dele te wijten aan de incompetentie van de projectmanagers en het feit dat zulke systemen vaak worden opgezet zonder eens goed te kijken naar wat de eindgebruiker zou nodig hebben.

[player-x]

Leuk dat SAP, enig idee wat dat dat grapje gekost heeft? Vooral als je eenmaal met customizing begint (kan me niet inbeelden dat GPS tracking bijv. een standaard onderdeel is van SAP).

Het is geen GPS tracking, maar het schijnt dat die functie er ook is, maar het is GPS taging, de hele plant is gemodelleerd in CAD, en elk onderdeel heeft een XYZ locatie, die ik kan oversturen naar mijn tablet of smartphone om hem terug te vinden via GPS, kan echt heeeel veel zoektijd schelen vooral voor de onderhoudswerknemers.

Wij gebruiken ook SAP, als ik de prijzen hoor die daarvoor betaald zijn, hoeveel er verspeeld is aan opleiding en consulting en als ik dat dan vergelijk met hoe goed (of moet ik zeggen slecht?) dat het eindproduct werkt dan weet ik niet of SAP altijd de juiste keuze is.

Werkt alles helemaal vlekken loos, nee, heeft het een steile leercurve jazeker, zou het makkelijker kunnen, vast wel, maar het werkt wel degelijk redelijk goed, iets dat niet echt te zeggen is over het defensie systeem.

Ik heb door de jaren heen trouwens voldoende negatieve verhalen van SAP gehoord, zowel intern bij ons als uit andere bedrijven. Er zijn spijtig genoeg heel veel eindgebruikers die vloeken op het systeem, ten dele te wijten aan de incompetentie van de projectmanagers en het feit dat zulke systemen vaak worden opgezet zonder eens goed te kijken naar wat de eindgebruiker zou nodig hebben.

Dat is niet echt de schuld van SAP, en doet Oracle het beter?, daar hoor ik toch echt de zelfde verhalen over.

[Reactie gewijzigd door player-x op 23 juli 2024 13:50]

[tellavist]

Sterker nog, tot voor kort hielden we al die modems incl locatie gewoon in excel bij...
Oke toen waren het er 300.000. geen 4.5 miljoen.
Maargoed, just saying
Het zou theoretisch, wellicht iets omslachtig, gewoon in een office aplicatie kunnen.
Kost je alleen wat licenties

[player-x]

Het bij houden van waar modems zijn is toch wel wat minder complex dan het bij houden van mechanische machines, inclusief hun onderhoudsschema's.

Daar is CRM een stuk minder voor geschikt dan SAP, daar die software zich meer op klanten richt.

[koelpasta]

Ja ik zat ook even met mijn mond open te lezen, bij mij op werk (Statoil), werk ik met SAP, en daar doen we letterlijk alles op werk mee, wat het leger met dit gefaalde project wilde doen.

Alleen is SAP van een duits bedrijf.
Voor een leger is het niet zo handig als je je logistiek via het buitenland doet.
Wil ons leger hetzelfde kunnen als SAP dan zijn ze gedoemd het na te bouwen.

[player-x]

Onzin de Duitsers zijn onze dichtste bondgenoten, terwijl de Amerikanen zowel moreel als ideologisch veel veder van ons staan, en we kopen daar wel idioot dure F35's en andere wapensystemen van.

We hebben zelfs het Eerste Duits-Nederlandse Legerkorps, en je denkt dat we geen SAP software zouden kunnen gebruiken in het leger. omdat het Duits is.

[Reactie gewijzigd door player-x op 23 juli 2024 13:50]

[koelpasta]

terwijl de Amerikanen zowel moreel als ideologisch veel veder van ons staan, en we kopen daar wel idioot dure F35's en andere wapensystemen van.

Ja, ook dat is niet slim. Amerika kan dan, mochten ze dat willen, onze F35's uitschakelen.

We hebben zelfs het Eerste Duits-Nederlandse Legerkorps,

Ja, en op dat soort pan-europese verbanden kun je prima SAP loslaten. Maar om je hele leger daarop te draaien lijkt me niet erg slim.
Bedenk dus dat dit systeem een dusdanig kritieke functie moet vervullen dat als het ophoudt met werken ons leger per direct uitgeschakeld is.

[player-x]

Er is geen leger in de wereld die niet met wapen systemen werken uit andere landen, zo als laats in het nieuws, dat Frankrijk het stopt met bouwen van twee (plus twee opties) schepen voor de Russische marine.

Ik geloof dat de betrekkingen tussen NL en D een stuk beter zijn dan die tussen RUS en F, op de marine na gebruikt het Nederlandse leger bijna alleen buitenlandse wapen systemen, en volgens jouw zou SAP dan opeens een probleem zijn.

Daarnaast bij dergelijke contracten, vragen overheden volledige toegang tot de broncode, zou er in D opeens een vierde rijk opstaan, en we de betrekking met D verbreken, dan heeft het leger nog steeds toegang tot de broncode, net zo als het toegang heeft tot de broncode van Windows!

[Reactie gewijzigd door player-x op 23 juli 2024 13:50]

[koelpasta]

Een paar boten vind ik echt iets anders dan het hele logistieke systeem van je strijdmacht. Rusland is echt niet uitgeschakeld als die botn het niet meer doen. Buiten dan heeft rusland genoeg expertise en mankrachten om die boten helemaal te masteren en eventueel om te bouwen naar iets dat ze meer vertrouwen.
Maar als je kijkt naar de onkunde die nederland toont in het maken van hun eigen systemen denk ik dat we in het geval van sap gewoon aan de sap-infuus komen te hangen. Alleen al het feit dat er legertjes consultants in de binnenwerken van onze logistieke operatie komen te wroeten maakt het nogal een aanfluiting.

Daarnaast bij dergelijke contracten, vragen overheden volledige toegang tot de broncode,

Je hebt niks aan broncode als je niet de capaciteit hebt om het te doorgronden. Aangezien we zelf niet zo'n systeem hebben kunnen bedenken lijkt het me sterk dat we andermans werk op alle implicaties kunnen beoordelen.
Darnaast is SAP een gigantisch houtje-touwtje gebeuren waar SAP-mensn zelf lang niet altijd wijs uit worden.

zou er in D opeens een vierde rijk opstaan, en we de betrekking met D verbreken, dan heeft het leger nog steeds toegang tot de broncode, net zo als het toegang heeft tot de broncode van Windows!

Ja, maar daar heb je in kritieke tijden dus bitter weinig aan.

[Reactie gewijzigd door koelpasta op 23 juli 2024 13:50]

[Deem]

Dat heet ERP en niet CRM. CRM kan onderdeel zijn van een ERP systeem.

[Kevinp]

Maar 400 miljoen?

Overigens is het makkelijk te verklaren. Te veel mensen die zich ermee bemoeien.

Een goed werkend ERP systeem kost geen knoop. En dat zal ruim voldoende werken. Perfect nee, kosten, laten we zeggen 100.000 euro.

Maar nee, 20 verschillende bazen die allemaal iets willen wat eigenlijk niet samen gaat.

Goede eisen opstellen aan de voorkant en daar niet steeds van afwijken is de sleutel tot succes in een ICT systeem.

Daarnaast leven met wat je hebt ook als het nit ideaal is.

[tERRiON]

Een dergelijk omvangrijk ERP-systeem voor 100.000 euro?

Ik weet niet hoe die 433mln is opgebouwd, maar dat je geen idee hebt wat software kost en wat er zoal nog meer bij komt kijken, heb je bij dezen bewezen.

Ik werk bij een gemeente (klein tot middelgroot) en we zijn jaarlijks aan licenties voor Oracle al bijna een ton kwijt. Succes met je ERP-systeem van een ton!

[Kevinp]

Ik heb heel goed een idee. Het probleem zit hem niet in de schaal, maar in de incompetentie van managers vanuit twee kanten.

In plaats van goede afspraken maken vooraf worden afspraken halverwege aangepast. En dat kan best één keer, maar niet steeds opnieuw.

In plaats van eerst de basis goed maken en opleveren moest alles in één keer. Precies waar het mis ging.

Kijk naar de omschrijving wat het in basis moest doen, dat is echt een maandje hooguit werk. (bijhouden waar welk materieel zich bevind ).

Lever dat op, en ga dan verder, je hebt dan altijd een goed werkend systeem. In plaats van een systeem wat continue in ontwikkeling is.

Projecten kan je stapelen Met een uurloon van 60 euro per uur heb je 6666666 uur aan werk

166666 weken werk.

en met een minimum van 20 vrije dagen ( feestdagen niet mee geteld) 3472 manjaar aan werk. ( wat meer wordt wanneer je ook nog feestdagen en alles boven de 20 vrije dagen mee gaat tellen).

Goed voor de werkgelegenheid zekers, maar wanneer je aan een project met erg veel mensen werkt en dat niet gestructureerd doet dan gaat het mis. (overigens is deze berekening op basis van 400 miljoen ). Nu zullen de mensen mogleijk meer kosten. Met 100 euro per uur aan kosten zit je nog altijd op 1923 manjaar aan werk. Gezien de kosten mogelijk dubbel zo hoog uitvallen dus 4000 manjaar aan werk vergooit. (of mensen te veel betaald).

[tERRiON]

Het idee is leuk. En voor kleine projectjes ongetwijfeld ook prima zo uit te voeren.

Ik vraag me alleen af wat je zegt als je in grotere omgevingen komt. Een ERP-systeem van deze omvang, waar weet ik het hoeveel attributen (miljoenen?) in opgeslagen zijn met de meest uiteenlopende relaties, metadata en noem het allemaal maar op, is wel even wat anders dan ergens een Access-database 2000 records en een invulschermpje in elkaar friemelen.

Ik vraag me overigens af hoe jij aan die 6666666 uur komt. Denk je werkelijk dat die 433mln uitsluitend is besteed aan manuren? Waar denk je dat die berg data op terecht moet komen? Neem bijvoorbeeld alleen al de opslag van alle data: dat is heus geen NAS'je met een paar desktopschijfjes erin hoor. En dan hebben we de overige hardware nog nodig, dan moet er een smak aan licenties en onderhoudscontracten betaald worden, noem het allemaal maar op. En denk je werkelijk dat je voor 60 euro of zelfs 100 per uur ergens een stel systeemarchitecten kunt inhuren?

En dan vergeten we voor het gemak nog even dat Defensie onder politiek bestuur valt. Dat enkele gegeven brengt al erg veel complicaties met zich mee aangezien Politiek Den Haag zich meer laat leiden door de waan van de dag dan van inhoudelijke kennis of zelfs maar gewoon van gezond boeren verstand.

Begrijp me goed, ik praat dit project niet goed (al was het maar omdat ik geen idee heb hoe het bedrag van 433mln is opgebouwd) maar met de eenvoud zoals jij die voorstelt, is een dergelijk project eveneens gedoemd te mislukken.

[Kevinp]

tuurlijk is het iets ingewikkelder.

Maar wat je hier (duidelijk) ziet is dat mensen beginnen met vliegen terwijl ze nog niet kunnen lopen.

Elk klassiek plaatje over fouten in software development gaat hier op. En wanneer dit nu voor het eerst zou zijn ok, maar het gaat wel vaker mis.

[Pinkys Brain]

Overheden en slecht gerunde bedrijven ... daar drijft de IT industrie op.

[Bruin Poeper]

Maar 400 miljoen?

Overigens is het makkelijk te verklaren. Te veel mensen die zich ermee bemoeien.

Een goed werkend ERP systeem kost geen knoop. En dat zal ruim voldoende werken. Perfect nee, kosten, laten we zeggen 100.000 euro.

Maar nee, 20 verschillende bazen die allemaal iets willen wat eigenlijk niet samen gaat.

Goede eisen opstellen aan de voorkant en daar niet steeds van afwijken is de sleutel tot succes in een ICT systeem.

Daarnaast leven met wat je hebt ook als het nit ideaal is.

Ook Samas door ERP-syateem failliet.
Het erge is dat ze jaren daarvoor ook al een ERP-systeem met zwaar tegenvallende resultaten opgetuigd hadden.
Ze hebben dezelfde fout (minstens) 2x gemaakt.

[tellavist]

433 miljoen euro aan uitgegeven, maar waarschijnlijk gaat het om het dubbele.
Ik loop wat op de feiten vooruit. Maar we weten allebei wel dat het waarschijnlijk inderdaad om het dubbele gaat

[stresstak]

Ik loop wat op de feiten vooruit. Maar we weten allebei wel dat het waarschijnlijk inderdaad om het dubbele gaat

Al was het maar om dat de looptijd ook verdubbelt en we hebben nog niks. En arbeidskosten en meerwerk stijgen ook gewoon door.

Mijn troost is hooguit dat er mensen werk aan hebben gehad; een opdracht, een baan. Er gaan scheppen belastinggeld de deur uit waar we niks voor krijgen.
Dan valt zelfs 0,8 miljard in tien jaar nog mee. Afgerond.

[matty___]

Niet waar een vliegtuig staat maar elk schroefje, elke wijziging of onderhoud volledig kunnen herleiden.

Maar wat ik zo hoorde van consultants die op dat project zaten was er ook veel weer stand binnen de organisatie.

[Blokker_1999]

Elke verandering in een onderneming zal op weerstand stuiten. Om dat tegen te gaan is het belangrijk dat je goed uitlegt waarom iets wijzigt en alle mensen voor wie er iets zal veranderen moet je betrekken bij het project. De meerkost van die betrokkenheid verdien je terug door de lagere weerstand op de werkvloer.

[Dennism]

Ik zie niet direct de relatie tussen een Customer Relation Management system, en Asset Management over 4,5 miljoen modems. CRM systemen worden normaliter gebruikt voor het beheren van bedrijfs contacten met huidige en toekomstige klanten op het gebied van sales, marketing en klant support.

Wat jij bedoeld is is Asset Management, wat vaak een onderdeel is van een ERP applicatie, CRM functionaliteit zie je trouwens ook regelmatig als module binnen ERP pakketen bij zeer grote organisaties, maar is wel degelijk wat anders dan Asset Management.

[Anoniem: 256386]

Defensie is een complex organisatie. Ze hebben sap gekozen met module dfps
Dat is speciaal voor defensie. Ze kunnen dus ook moeilijk aan mensen met die kennis komen.
De grote is natuurlijk ook een factor.

[YangWenli]

Ja die Japanse automakers hebben al in de jaren 70 systemen bedacht om voorraden efficiënt te beheren.
Misschien hadden ze eens met amazon kunnen praten?

[himlims_]

trek hier dan ook leer uit; lever je ict diensten aan de overheid

[tellavist]

En dan dus het liefst zwart
Alhoewel het nog een hele klus is om die paar miljoen wit te wassen haha

[PupStar]

Ze zijn er al sinds 2004 mee bezig maar het werkt nog steeds niet? De incompetentie druipt er weer vanaf..

[Mr_gadget]

Overheid die niet precies weet wat hij wil en dure consultants die daar misbruik van maken.

Bewindspersonen zien ICT als de manier om allerlei plannen te verwerkelijken, maar tonen tegelijk geen enkele interesse in hoe het écht gaat bij automatiseringsprojecten. Daartegenover staat een Tweede Kamer die dit “ongebreidelde ICT-enthousiasme” nog versterkt, en zijn controlerende taak verwaarloost, ook omdat ze vaak gebrekkige en soms misleidende informatie van het kabinet krijgt. Ambtenaren op ministeries tonen zich zeer slechte projectmanagers, als ze het management al niet uitbesteden aan externe adviseurs, die vaak andere belangen hebben dan die van het ministerie. ICT-leveranciers maken gebruik van deze situatie door veel te vaak tegen te hoge kosten middelmatige of slechte producten af te leveren.

http://www.nrcq.nl/2014/1...miljard-bij-ict-projecten
Snap ook niet waarom ze niet een kant en klaar ERP systeem hadden kunnen laten aanpassen..

[Reactie gewijzigd door Mr_gadget op 23 juli 2024 13:50]

[CaptJackSparrow]

Ik ben altijd van mening geweest dat het waarschijnlijk het meest efficiënt is om zoveel mogelijk off-the-shelf software te gebruiken en die aan je wensen aan te passen. Hoever zou men al hebben kunnen komen met bijv. Access als database engine waar je in enkele maanden een geschikt front-end omheen timmert? Men wil ook altijd véél te grote en complexe systemen ineens bouwen. Begin met een beperkte deelfunctionaliteit en als dat goed werkt bouw je het verder uit. Dat is een véél veiligere en rationelere benadering imho.

Ik erger me ook al heel lang mateloos aan het hardnekkige geloof van de overheid dat je alles maar door 'de markt' moet laten doen. Die vreselijke neoliberale religie kost onze samenleving vele miljarden. De ICT behoefte van de overheid is zó groot dat die NATUURLIJK allang zijn eigen ICT departement zou moeten hebben die zelf o.a. in de softwarebehoefte van allerlei overheidstakken kan voorzien. Daarbij zou je een veel beter overzicht en controle kunnen hebben op de werkzaamheden dan wanneer je dat uitbesteedt aan allerlei vage externe partijen waarvan je niet weet wat die allemaal doen maar waarvan je wel weet dat die vooral op zoveel mogelijk geld uit zijn.

Ik ben dan ook allang van mening dat er een apart ministerie zou moeten zijn voor "Digitale Informatievoorzieningen" of zoiets. ICT speelt ZO een belangrijke rol in onze samenleving dat dit allang een eigen ministerie zou rechtvaardigen. Binnen dat departement kan dan een efficiënt gerund eigen 'softwarebedrijf' en een 'hardwarebedrijf' bestaan dat zich bezig houdt met de behoeften op dat gebied van alle landelijke, regionale en lokale overheden. Wat zou dat ons als samenleving (belastingbetalers) een enorme hoop geld besparen als dat goed en efficiënt gerund opgezet zou worden onder leiding van een capabele minister. Dát lijkt me nou een interessante en uitdagende baan. Het grootste probleem zou misschien kunnen zijn om die 'capabele minister' ook echt aan het hoofd te krijgen in plaats van iemand die na zoveel jaren trouwe partijdienst een mooi hoog baantje 'verdiend' heeft.

[Reactie gewijzigd door CaptJackSparrow op 23 juli 2024 13:50]

[Verwijderd]

Helemaal mee eens. De overheid is veel te lucratieve melk koe. En durft zelf niet bedrijven aan te pakken zodat ze gewoon failliet gaan. Want dan komen er weer mensen op straat. De overheid is echt een makkelijk doelwit voor dit geneuzel.

Belangen belangen belangen. Overheid richt uw eigen ICT afdeling op met eigen systemen.

[kimborntobewild]

Hoever zou men al hebben kunnen komen met bijv. Access als database engine

Access? Dan liever een database-programma van nederlandse of EU bodem. Waarom nog meer geld naar de USA pompen?

[kikker81]

Je beseft dat in elk intern ICT departement bij de overheid het personeel voor onbepaalde tijd tegen een freelance salaris werkt (incl pensioen e.d.)?
En dat er zelden iets af komt omdat er geen werkdruk is?

Wat er dan gebeurd is dat ze het gaan outsourcen, en 10 jaar later kom ze er dan achter dat dat net zo duur is, en dan moet alles weer in-house, tot weer 10 jaar verder, dan komt er iemand op het geniale idee om alles te outsourcen.

[hydex]

Helemaal mee eens. Bij de overheid zie je vaak slecht opdrachtgever schap. De business requirements zijn vaak niet helder. Tegelijkertijd zorgt het software bedrijf er wel voor dat alles wat niet direct is afgesproken meerwerk wordt. Ik zou graag zien hoe dit project is verlopen en wat de requirements zijn. Bovendien is het uitvragen van requirements ook een vak apart. Aan wie stel je de vragen? En als je dan eenmaal alles op papier hebt hoe zorg je er dan voor dat de projectleider(s) zich strikt houd aan de afspraken. In 2004 bestond scrum nog niet (volgens) mij. Hoe dan ook ik vermoed een watervall project waarbij gaandeweg het ontwikkelen steeds meer lijken uit de kast zijn gekomen en waarbij het enorm out of focus is geraakt.

Daarnaast is een andere belangrijke factor werknemers. Deze zijn gewend op een bepaalde manier te werken en zullen vanuit die focus feedback of weerstand geven op veranderingen. Wanneer je binnen essentiële processen werknemers met macht heb zitten en je hebt geen sterke stuurgroep dan loopt je ICT project enorm uit de hand.

Binnenkort gaan we dezelfde verhalen horen over het patiëntendossier heb al diverse verhalen gehoord dat het bij zorginstellingen ook fout gaat, mede om de redenen die ik hierboven schets.

[veltnet]

Agile development (waaronder scrum) bestaat al meer dan 30 jaar. De laatste jaren is het wat bekender geworden.

[Anoniem: 636203]

Een ERP systeem aanpassen kost vaak meer dan gewoon zelf iets bouwen.

[Bruin Poeper]

Een ERP systeem aanpassen kost vaak meer dan gewoon zelf iets bouwen.

Hahaha. Misschien is het systeem nog wel het simpelst. Maar vervolgens moeten de oude data er in. Ik heb meegemaakt dat men handmatig (oud systeem er naast en intypen in het nieuwe..) moest doen...

[Verwijderd]

Als het om spaghetti code gaat wel ja.

[mphilipp]

Ze hebben SAP proberen te implementeren. Ze hebben het niet zelf proberen te bouwen, dat zou inderdaad waanzin zijn geweest.

Typisch overheidsprobleem: te ambitieus, teveel dingen veranderen onderweg (scope), tegelijkertijd Defensie drastisch reorganiseren, incompetentie managers und soweiter...

[SuperDre]

En zoals ik altijd weer zeg, de projecten worden uitgevoerd door de grote ict jongens, dus dat zegt genoeg over de kwaliteit van deze bedrijven.......

[Ceejay]

Ik mag dan een beetje simpel zijn, maar kun je als overheid bij de aanbesteding van een ICT-project niet bedingen dat je pas betaalt als het af is? Een soort no cure no pay?

Waarom is de opdrachtgever de gesjochte als weer blijkt dat ICT bureaus gewoon niet kunnen leveren?

Mensen betalen mij ook pas als hun websites af en naar wens zijn. (Beetje andere schaal, geef ik toe)

[Reactie gewijzigd door Ceejay op 23 juli 2024 13:50]

[svennd]

Nee zo werkt geen enkel bedrijf, als je 4 jaar aan een project werkt zonder een cent te zien... de klant is nooit tevreden. Volgens mij is dit een gevolg van -zoals bij veel bedrijven- beleidsmakers die geen verstand hebben over IT/ICT toch alle beslissingen willen nemen. Samen met wat corruptie leuk voor de Nederlandse belasting betaler!

[Icekiller2k6]

Bwah in België is /was ook het probleem dat je moet bieden voor projecten. En de laagste prijs wint...
dan krijg je vanzelf absurde scenario's .

Ik zeg niet dat de overheid geen fouten maakt. Maar een meerjarenplan kan nu eenmaal dingen wjjzigen. Anders krijg he USSR praktijken dat ze in de zomer winterschoenen maken omdat ze productie problemen hadden en ze hun hoeveelheid nog niet gehaald hadden bv.

edit: Zullen we zeggen dat de in de winter/lente/zomer winterschoenen werden gemaakt... dat was het punt van het verhaal...

[Reactie gewijzigd door Icekiller2k6 op 23 juli 2024 13:50]

[Pyrone89]

Euhm, no offence maar in de zomer winterschoenen maken is juist de norm. In de winter maken ze juist weer zomerschoenen.

Dit in verband met een voorraad aanleggen en lead-times qua logistiek etc.

Als je pas in de zomer de zomerschoenen maakt ben je al te laat.

Zo worden op dit moment al de kerstpakketten gemaakt en zijn alle mode-winkels nu langzaam aan bezig met het voorbereiden van de gewenste herfstcollectie.

[Kevinp]

Precies daarom koop ik altijd kleren in de uitverkoop. Ik koop zomer kleren in de zomer, en winter kleren in de winter. tja dat de rest dat blijkbaar andersom doet is vreemd.

Echter dat heeft hier niet zoveel mee te maken.

Weten waar welk materiaal staat ( als dat echt de primaire taak is van het systeem ) kan ik voor ze in 1 uurtje in msaccess in elkaar knutselen.

ok dat is niet multi user, maar je maakt hetzelfde web based en je bent er. Je draait het geheel op intranet zodat je er alleen intern bij kan en het is ook nog redelijk beveiligd.

Overigens zijn er ook vele bedrijven die warehouse atomation doen iets wat er ook voor 99% op lijkt, alleen zijn dan de verblijftijden korter.

[hansg]

Er is feitelijk maar een extra regel nodig: bij meerkosten worden die automatisch bij de aanbestedingsprijs van het volgende project geteld.

Stel dat een bedrijf inschrijft voor bijna gratis, met als idee er dikke winst op te maken via extra kosten. Dat bedrijf wint automatisch de aanbesteding, want bijna gratis, maar vervolgens betaald de klant gigantisch veel meer. Geen punt, dat extra betaalde bedrag wordt in de volgende aanbesteding gewoon bij de prijs van de offerte geteld (want er is immers bewezen dat je kunt verwachten zoveel extra te betalen). Dat bedrijf komt dus automatisch achteraan in de lijst, en een realistischer bedrijf kan het nu wel winnen.

Is dit te doen? Wat mij betreft wel. Je hebt wat regeltjes nodig om te zorgen dat je projecten vergelijkt die in ongeveer dezelfde cathegorie zitten qua omvang, maar dan heb je daarna wel een level playing field en ben je gelijk af van die verschrikkelijke race naar beneden "om het project maar te winnen".

[SuperDre]

Tja, en toch is het zo dat je juist mensen inhuurt die er verstand van zouden moeten hebben en een goede ict-er houdt ook rekening met een beleidsmaker zonder ict kennis..... Het is niet alsof de ict-er niet weet dat degene die hem/haar inhuurt de ballen verstand ervan heeft............ Dus imho ligt het probleem bij de ict-bedrijven, niet bij degen die ze inhuren...

[svennd]

het probleem is dat beleidsmakers niet weten dat ze geen verstand hebben van IT...

[koelpasta]

Nee zo werkt geen enkel bedrijf, als je 4 jaar aan een project werkt zonder een cent te zien...

Waar HEB je het over?
Niet eens een week geleden is Ballast Nedam met 49 miljoen uit de nood gered omdat ze gigantische meerjarenprojecten voor de overheid doen en daar achteraf voor betaald gaan krijgen.
Niet betalen tot het product/de dienst geleverd is is een vrij gebruikelijke manier van zakendoen binnen onze overheid. Alles op de pof.

[veltnet]

Ballast Nedam had het project te goedkoop ingeschat waardoor ze niet uitkwamen met de kosten. Dat is de reden waarom ze in geldnood kwamen.

[MicGlou]

"Zo werkt geen enkel bedrijf"... hoe kom je daar bij? Ik werk voor (semi) overheid en wij hebben met diverse leveranciers contracten waarin staat dat als ze zich niet aan de afgesproken prestaties houden we de rekening niet hoeven betalen. Metingen daarin worden gedaan door een onafhankelijk bedrijf, dit moet eigenlijk wel vanwege die verrotte europese aanbestedingen. Afspraken moeten heel scherp worden gemaakt anders zit je voor langere tijd aan hele dure contracten vast waar een leverancier niet zou hoeven presteren... nu hebben we een flinke stok achter de deur waarmee we de afgelopen paar jaar een aantal leverancier al flink mee hebben kunnen meppen en dus ook de rekening niet hoefden te betalen.

Verder heb je wel deels gelijk, bij dergelijke projecten blijft er enorm veel aan de strontstok hangen en worden ook idd vaan gestuurd door onkundige beleidsmakers. Maar dan zou er nog een goed lopend project uit kunnen komen, een leverancier die troep oplevert heeft weinig respect voor de handel waarin ze zitten en zullen dan wss niet meer zo'n lang leven beschoren zijn. Maar dit is ook weer het gevolg van de europese aanbestedingen, dat zorgt gewoon simpelweg voor wurgcontracten met sub par leveranciers.

[Anoniem: 636203]

Je kan deelbetalingen doen voor deelopleveringen. Ook kan je bedingen dat de uiteindelijke betalingen nooit meer kunnen zijn dan het afgesproken bedrag tenzij de eisen inhoudelijk wijzigen. Laat de eindklant alleen globale eisen opstellen waar het product aan moet voldoen en geef hen niet de macht om tot op detailniveau te beslissen hoe het moet werken en hoe het er uit moet zien. Dat is voor de producent om te beslissen.

[Bruin Poeper]

Ik denk dat men daar wel naar toe moet. Aanbesteden zoals in de bouw.

De opdrachtgever wordt dan gedwongen om zijn eisen duidelijk te formuleren.
De opdrachtnemer weet wat hij moet leveren.

Wellicht moet je/(de overheid) dan bij software een (betere) vak-specialisatie in 'formulering+aanbesteding' hebben.

[nlinzweden]

Nee zo werkt geen enkel bedrijf"

Onzin. Zo werkt de farmaceutische industrie, en waarschijnlijk wel meer bedrijfstakken.

[svennd]

Een bedrijf die 100% output voor +10 jaar kan doen zonder 1 cent te zien... dat wil ik wel zien. De farma industrie investeerd in R/D zonder daar return voor te zien maar das anders dan een IT bedrijf die code begint te kloppen, per definitie zou dat moeten "werken".

[MicGlou]

Dat er nooit een cent wordt betaald wordt nergens beweerd, de rekeningen worden betaald zolang de prestatie op niveau is. Blijkt dat het project niet goed is opgeleverd of de verkeerde kant op gaat dan moet geld worden terugbetaald en in sommige scenario's zelfs al het geld.

[Anoniem: 167912]

Ik mag dan een beetje simpel zijn, maar kun je als overheid bij de aanbesteding van een ICT-project niet bedingen dat je pas betaalt als het af is? Een soort no cure no pay?

Geen enkel bedrijf kan het zich veroorloven om 10 jaar werk "voor te schieten".

Waarom is de opdrachtgever de gesjochte als weer blijkt dat ICT bureaus gewoon niet kunnen leveren?

Ik kan onmogelijk opmaken uit het artikel wie hier de schuldige is: het bedrijf dat niet levert wat er gevraagd werd of de overheid die zo vaak en zodanig van de oorspronkelijke beschrijving iis afgeweken dat alles nu met spuug en paktouw aan elkaar hangt.
De enige echte vraag is: waarom moet iets schijnbaar zo eenvoudig als wat hier beschreven wordt zo duur zijn? Met een excel op een beveiligde NAS zou het in principe ook moeten kunnen (jaja, ik weet dat dit vele te kort door de bocht is en dat het hier om nationale veiligheid gaat en zoverder, just making a point)

[MiloLemmy]

Dát!
Misschien dat Excel inderdaad wat kort door de bocht is, maar hoe precies is "een ict-systeem voor het leger waarmee onder andere kan worden bijgehouden welk materieel er beschikbaar is en waar het precies staat" wezenlijk anders dan een legergroen Warehouse Management Systeem?
Die heb je al jaren, ook open source...

[ph4ge]

Daarom hebben consortiums ook vaak een deelnemende bank. Als je vantevoren weet dat je zelf moet financieren hoeft dat geen probleem te zijn.

[vanaalten]

Ik denk dat bij een project dat - gepland - meerdere jaren duurt, je als aannemer dat niet gaat accepteren en minimaal jaarlijks betaald wil worden.

Daarnaast mist hier in het artikel een heel relevant stuk: waarom loopt dit zo uit? Het is zeker niet onmogelijk dat dat komt door foutieve, incomplete en/of wijzigende specificaties. Dat je er gaandeweg achter komt dat subsysteem 'X' niet goed met subsysteem 'Y' werkt of niet compatibel is met leverancier-systeem 'Z'. Dan ga je specificaties aanpassen, nieuwe fouten introduceren, nieuwe incompatibiliteiten creeeren en ontdekken...

Ik zou zonder die achtergrondinformatie niet zomaar durven stellen dat de leverancier/ontwikkelaar van de software de oorzaak van de vertraging is. Meest waarschijnlijke is dat er meerdere oorzaken aan diverse kanten zijn.

[ArcticWolf]

In de bouw krijg je betaald als je een werkpakket oplevert, dat kan in dit geval ook lijkt mij, bepaalde werkpakketten afspreken en dan moet de aannemer aantonen dat hij het zo heeft opgeleverd (meestal minimaal voor 95%) en dan krijgt hij betaald.

Maar om dit soort projecten in goede banen te laten verlopen moet je ook aan de opdrachtgevers kant een projectteam hebben zitten die de zaken aanstuurt/controleert anders krijg je idd dit soort achterlijke partijen.
En hopelijk hebben ze geleerd dat ze meer op kwaliteit moeten sturen dan op de goedkoopste prijs (ik ken een paar hele goede voorbeelden van hoe het niet moet uit de bouw ).

[Anoniem: 256386]

Dan moet je wel de kennis in huis hebben wat wel en niet kwaliteit is.
Dat is niet zo makkelijk. Daarom was een aanbeveling om 1 centraal punt te hebben die de kennis heeft en het traject begeleid.

[Anoniem: 636203]

Dat is iets wat de leverancier bij de aanbesteding zou moeten uitzoeken. Als men daar te laat achterkomt dan is het risico voor de leverancier.

[Stoney3K]

Dat is iets wat de leverancier bij de aanbesteding zou moeten uitzoeken. Als men daar te laat achterkomt dan is het risico voor de leverancier.

Helaas is de prijs tijdens zo'n aanbesteding de grootste doorslaggevende factor, en wordt er minder naar "kwaliteit" gekeken.

Vooral bij een overheidsproject wil je geen knal-voor-je-knaak aanbieden, maar een basisproduct voor een bodemprijs. De rest komt er dan gewoon bovenop als meerwerk of service achteraf.

[ninjazx9r98]

Borrelpraat en een veels te simplistische voorstelling van zaken, zou geen kwaad kunnen om je eens in te lezen in het proces van een aanbesteding. Voor wat betreft meerwerk, als daar niet in voorzien is in de oorspronkelijke overeenkomst kun je dat niet zomaar introduceren en heb je gewoon te maken met een nieuwe overeenkomst.

[veltnet]

In sommige gevallen heb je gelijk en is dit borrelpraat, maar in veel gevallen het is wel degelijk zo dat de overheid voor de goedkoopste/slechtste aanbieder gaat. Heb in het verleden meerdere keren advies moeten geven met welke aanbieder de overheid in zee zou moeten gaan. In 100% van de gevallen heeft de overheid dit advies naast zich neergelegd en is er gekozen voor de goedkoopste/incapabelste/slechtste partij. Goedkoop is dan duurkoop.

[Anoniem: 636203]

Dat men de laagste prijs neemt istoch altijd het geval? En als men dat niet doet dan wordt er weer geroepen dat het verkwisting van overheidsgeld is terwijl het ook (veel) goedkoper kan.

Het is aan de leverancier om er voor te zorgen dat zij de gewenste kwaliteit leveren voor de laagste prijs. Als een webshop A een product levert voor 15 euro minder ga ik het niet bij webshop B kopen. Ik kan niet inschatten of webshop A betere service verleent en het product is hetzelfde. Zo is het ook met ICT. Leverancier A kan niet zomaar hardmaken dat hij betere ontwikkelaars in dienst heeft die meer kosten. Zo'n project is ook te groot en complex om dat het aleen af zou hangen van de kwaliteit van de ontwikkelaars en functioneel analisten.

[Reactie gewijzigd door Anoniem: 636203 op 23 juli 2024 13:50]

[JanvdVeer]

Ik mag dan een beetje simpel zijn, maar kun je als overheid bij de aanbesteding van een ICT-project niet bedingen dat je pas betaalt als het af is? Een soort no cure no pay?

Zo is het dus met Ballast Nedam gegaan.

RWS bedong in het contract dat ze achteraf het afgesproken bedrag betaalt als de A15 af zou zijn en in gebruik kan worden genomen. Het idee is dat als een bouwer zelf jaren verantwoordelijk is voor onderhoud, het met een slim, zuinig en innovatief ontwerp zal komen. Eigenlijk neemt RWS een soort dienst af; beschikbaarheid van de A15. Maar omdat ze zich -uiteraard- veel te koop hebben ingeschreven is het nu huilen met de pet op (lees: op het randje van faillissement).

Het risico wordt op deze manier bij de uitvoerder gelegd. Zéker omdat het hier ook gaat om belastingcenten is dit een prima manier van aanbesteden imho.

[Reactie gewijzigd door JanvdVeer op 23 juli 2024 13:50]

[Bosmonster]

En dat geeft goed aan waarom dat systeem niet werkt. Je kunt het risico niet bij de ontwikkelaar neerleggen, omdat die meestal niet berekend is op eventuele problemen die ontstaan, alsmede dat zij natuurlijk niet verantwoordelijk kunnen zijn voor zaken waar ze geen invloed op hebben.

Het gevolg van deze verantwoordelijkheden bij de ontwikkelaar neerleggen is uiteindelijk dat de kosten voor nieuwe projecten juist de pan uit gaan rijzen, want zij moeten nu hun risico's gaan afdekken. Of dat gewoon niemand het project in z'n geheel meer wil afnemen voor een redelijke prijs.

Wat ze beter kunnen doen is simpelweg minder in 1x willen automatiseren, maar het opdelen in kleinere - en behapbaardere - deelprojecten. Dan zijn ook de risico's een stuk makkelijker te managen. Maar probeer dat een politicus zonder ICT-ervaring maar eens uit te leggen die als enige doelstelling heeft dat ie "binnen 5 jaar dit en dat bereikt moet hebben".

[Reactie gewijzigd door Bosmonster op 23 juli 2024 13:50]

[TheekAzzaBreek]

Als ze daar niet op berekend zijn, deugen ze niet voor hun vak. Je mag verwachten dat een wegenbouwer een beter zicht op de risico's van zo'n project heeft dan een ambtenaar. Politieke risico's daargelaten natuurlijk, kosten door allerlei onverwachte procedures, maatschappelijke onrust, van mening veranderende politiek etc vallen dan ook altijd buiten die aansprakelijkheid.

Ballast heeft bewust gegokt, en verloren. Daaruit concluderen dat het systeem niet werkt is wel een heel vlotte conclusie.

[Bacchus]

Als ze daar niet op berekend zijn, deugen ze niet voor hun vak. Je mag verwachten dat een wegenbouwer een beter zicht op de risico's van zo'n project heeft dan een ambtenaar.

In het geval van RWS t.o.v. Ballast-Nedam ben ik het hier niet helemaal mee eens. Mijn indruk is dat bij RWS nog wel wat ambtenaren zitten die serieus kennis van zaken hebben. Voor overheid en ICT geldt je verhaal veel sterker, beter nog: Ik denk dat grote delen van de grote ICT-bedrijven eigenlijk ook niet zo goed snappen hoe ICT werkt..

[stresstak]

En dat geeft goed aan waarom dat systeem niet werkt. Je kunt het risico niet bij de ontwikkelaar neerleggen, omdat die meestal niet berekend is op eventuele problemen die ontstaan,

De ontwikkelaar heeft het programma van eisen gelezen en ondertekend. En de ontwikkelaar, Ballast Nedam, is geen beginneling.

[veltnet]

Dus minder waterval en meer kortlopende iteraties (agile/scrum)

[Ceejay]

Ja, dat vind ik dus ook. Het is nu gewoon gratis geld, mij bekruipt het gevoel dat je als ICT-bedrijf "binnen" bent met een overheidsproject.
Waar is de motivatie om het daadwerkelijk af te maken? Je geld krijg je toch wel, rekken met die handel.

[TheekAzzaBreek]

In het bedrijfsleven zie ik anders ook zat van dergelijke melkkoe projecten, die eindeloos uitlopen en waar de dienstverlener goed op verdient. Ook daar slecht management, slechte kwaliteitsbewaking, veranderende eisen, de hele riedel. Misschien dat daar er wat eerder wordt ingegrepen, maar het dilemma blijft hetzelfde: we hebben er nu al x miljoen ingestoken. Als we overnieuw beginnen zijn we weer een paar jaar en weer x miljoen verder, en we hadden die functionaliteit echt hard nodig.
Overheid doet het helemaal niet zo veel slechter dan de particuliere sector, alleen staat het bij de overheid meteen in de krant, bij het bedrijfsleven meestal niet.

[Verwijderd]

Kan wel kloppen, maar het is toch wezenlijk anders:

1. Het bedrijf draait zelf op voor de kosten (ze heft geen belasting).
2. En als het echt structureel mis gaat kunnen ze niet concurreren en gaan ze failliet.

Concurrentie en kunnen falen werken zuiverend, als een soort van economische lever. De overheid heeft zo'n "economisch orgaan" niet en de druk voor verbetering is er niet werkelijk. Zij verhoogd gewoon haar inkomen door de gezonde delen van onze economie te belasten!

[Vexxon]

Dat kun je ook zien als oneerlijk, aangezien een kleinere aanbieder dat nooit kan.

[Bosmonster]

Beetje lastig als je planning meerjarig is en om honderden miljoenen draait. Waar ga je je personeel van betalen in de tussentijd?

[SuperDre]

Maarja, waar gaan al die honderden miljoenen aan op binnen die projecten?

[Dorus12]

"No cure No Pay"
Ik snap je gedachte gang wel maar dat is niet haalbaar.
Wat ik zelf niet begrijp is waarom er niet gewoon een bestaande ERP systeem aangekocht is, zo van de plank.
Als ik zo lees wat de vereisten zijn kan je dat met elk fatsoenlijk ERP systeem van een middel/groot bedrijf.

Waar ik me verder zorgen over maak is de beveiliging.
Als dit soort systemen aan internet geknoopt zitten dan is het wel heel interessant voor "vijanden" om die te hacken.

[matty___]

Zover ik weet was het gewoon SAP

[CAPSLOCK2000]

Dat kan, maar je moet er wel voor betalen. Als je alle risico's bij de leverancier legt dan zal de leverancier zichzelf moeten verzekeren. De prijzen zullen daardoor zo ver stijgen dat het helemaal onbetaalbaar wordt. Zoals bij alle verzekeringen is het verstandiger om je niet te vezekeren als je het risico zelf kan dragen. Nu is 400 (of 800) miljoen een hoop geld maar voor de staat is dat een heel overzichtelijk bedrag.

[Anoniem: 256386]

Hoe wil je dat met meerwerk doen.

[WokeBroke]

Als ik als consument een product koop dat het niet goed doet of niet goed functionerend, kan ik mijn geld terug krijgen. Maar als de overheid een ict project koopt van miljoenen en het werkt niet, hoeven ze hun geld niet terug te hebben? Kan iemand mij dit uitleggen?

[Ramon]

De overheid betaalt waarschijnlijk niet voor het product maar voor de dienstenlevering van de consultants die het inrichten. Dus de kosten zitten hem er in dat consultants vragen wat de overheid wil, de overheid die zijn shitload aan veel te veel eisen op tafel legt en de consultants die dan uit alle macht gaan proberen om alles erin te hangen, wat dan niet lukt.

[hydex]

De vraag is waar de fout zit? Heeft het software bedrijf niet geleverd wat is gevraagd of heeft de overheid de verkeerde dingen gevraagd.
Waarschijnlijk ligt de waarheid zoals altijd in het midden, want anders was defensie echt niet tien jaar geld blijven overmaken.

Het doet mij een beetje denken aan help mijn man is klusser. Er wordt van alles overhoop gehaald en vervolgens wordt er hier en daar geklust en vervolgens is het overzicht kwijt en weet niemand meer hoe alles zich tot elkaar verhoudt

[stresstak]

Als ik als consument een product koop dat het niet goed doet of niet goed functionerend, kan ik mijn geld terug krijgen.

Heb je het nu over tastbaar product of over een 'work in progress' ? Tastbaar kun je terugbrengen en als het software is kun je het misschien teruggeven maar dan is het wel een softwareproduct dat klaar is maar niet voldoet aan de verwachtingen.

Als je besluit dat je huis niet wit maar bij nader inzien groen geschilderd had moeten worden, want mooier, dan krijg je het geld van het witschilderen ook niet terug,

Het is een lopend project en in de beginfase zal men met de beste bedoelingen begonnen zijn aan de uitvoering. Ga je dan over op heel andere plannen en aanpassingen, dan zijn de eerder gemaakte uren natuurlijk verloren en wel uitgegeven. En zo voort.

[Blokker_1999]

Jij kan je geld terugkrijgen als consument op voorwaarde dat het om een standaard product gaat dat men weer kan doorverkopen aan een ander. Vanaf dat jij maatwerk laat maken heb je geen recht meer om je geld terug te vragen.

[The Reeferman]

866 miljoen euro voor een ICT project wat hun administratie digitaliseert. Lijkt mij erg veel geld, Het is een grote organisatie, maar dit is wel erg veel. Nou heb ik niet echt kennis van andere vergelijkbare projecten en de prijs daarvan. Dus als iemand me kan helpen daar iets beter inzicht in te krijgen lees ik het graag hieronder.

[supertheiz]

Het is niet zo simpel als jij het schets:
Er zouden met dit project een paar honderd applicaties moeten worden vervangen, die ook allemaal geld kosten aan licenties en onderhoud.
Administratie in het leger is wat lastiger als van een normale organisatie:
Je moet troepen bevoorraden die onderweg zijn, dus een bewegende afleverlocatie.
Je moet straaljagers onderhouden, en onderzeeboten.
Geheime missies moeten worden bevoorraad, maar wel een op manier dat het ook geheim blijft.
Openbare aanbestedingen, testtrajecten (wapens), opleidingen, etc.

Het leger is echt een heel erg complexe organisatie.
Maar: Er zijn oplossingen die dit ondersteunen, als compleet pakket. De vraag is dus vooral waarom het nederlandse leger zoveel afwijkt van bijvoorbeeld het Duitse leger, waar ze een standaard oploissing hebben die gewoon te koop is.

[Anoniem: 636203]

Een paar honderd applicaties?! Lijkt mij sterk.

[theobril]

Het zou mij niets verbazen hoor, een paar honderd. Een voorbeeld van een relatief eenvoudig bedrijf: school: Je zet een docent voor een klas, die geeft les, en na een poosje krijgt lesnemer al dan niet een diploma. Hoeveel verschillende applicaties denk je dat daar in gebruik zijn? Ik weet het niet exact, en dat is al een teken aan de wand.

[Anoniem: 636203]

Die kunnen nooit allemaal hetzelfde doen, dat geloof ik niet. Er werken maar 20.000 man bij defensie. Dat zou dus één applicatie per 100 man zijn. Die ook nog eens hetzelfde doen.

[DinX]

Onder "applicatie" wordt in deze gevallen vaak ook een uitgebreide Excel-sheet waar $onderdeel_van_dienst X een uurschema in bij houdt, een wat uitgebreider Access-bestand met een stocklijst van afdeling Y,... Neem daarbij nog software die binnengekomen is via andere oplossingen (bijvoorbeeld een toepassing om het wagenpark te beheren van $leasemaatschappij), een Sharepointsite voor het delen van wat bestanden en kalenders voor een bepaald project,...

Afhankelijk van wat je "applicatie" noemt zou je versteld staan hoe snel je aan 1 applicatie per 100 man zit.

[theobril]

Ik ben ook wel nieuwsgierig nu. In die zin jammer dat het om defensie gaat, zeker zij zullen niet direct openheid van zaken geven.

[Anoniem: 670995]

Is wel zo.

[supertheiz]

http://www.kvl.nl/files/u...20datamigratie%20ooit.pdf

Je hebt gelijk. 70.

[ssjaak]

lol.
heb er gewerkt (marine)en was er bij tot mijn pensioen. ik alleen beheerde voor mijn dienstvak 22 applicaties, en was 1 van de kleinste bureaus.(in mijn eentje)
er zijn alleen bij de Marine al 10 tallen dienstvakken die samen duizenden applicaties hebben.
en dat moest allemaal in Sap. Samen met de landmacht die nog groter is en de luchtmacht.
En ja, sommige bestanden stonden nog in acces/excel/dos. noem maar wat op.
ik beheerde 1 programma in dos wat al 22 jaar oud was.

over dat Defensie zijn eigen Ict moet hebben zoals hierboven geschreven? Wel dat was er, maar moet weg ivm bezuinigen. kijk mij thuis zitten...

oja ook leuk, Sap moest het altijd doen dmv. internet. euhhhh heb je niet in je pub tent op de Noordpool. oja heb/had je ook niet aan boord van schepen die te ver weg zijn.
of ergens in Irak in de woestijn konden we ook geen verbinding vinden. dan maar weer een schriftje met liniaal..

dus fantaseer maar door hoe het zou moeten en ga solliciteren bij defensie

[doeternietoe]

Het is niet zo simpel als jij het schets:
Er zouden met dit project een paar honderd applicaties moeten worden vervangen, die ook allemaal geld kosten aan licenties en onderhoud.
Administratie in het leger is wat lastiger als van een normale organisatie:
Je moet troepen bevoorraden die onderweg zijn, dus een bewegende afleverlocatie.
Je moet straaljagers onderhouden, en onderzeeboten.
Geheime missies moeten worden bevoorraad, maar wel een op manier dat het ook geheim blijft.
Openbare aanbestedingen, testtrajecten (wapens), opleidingen, etc.

Just curious, maar waarom zouden al deze zaken in één applicatie moeten komen, of zelfs in één project opgelost moeten worden?

[jobvr]

Het idee van kosten besparing. Alle defensie onderdelen hadden verschillende systemen. Dat is niet handig omdat er veel onderdelen dezelfde spullen gebruiken. Met de komst van de defensie materieels organisatie die al het materieel van de hele defensie regelde is het ook handig om een beheers systeem te hebben. Daarnaast zijn de onderhoud en instandhouding en licentie kosten een stuk minder als je een systeem hebt in plaats van 5. Ook het onderhoudt kan een probleem zijn . Bij defensie draait alles op een beveiligd netwerk waar je van buiten erg moeilijk bij kan. Als je dus verschillende systemen hebt, moeten er van al die systemen specialisten aanwezig zijn om in geval van storingen deze te kunne oplossen. Als je een systeem hebt is dat makkelijker.

Wat ik alleen denk dat er gebeurt is dat iemand van de logistiek bij zijn neef in het bedrijf een leuk systeempje zag waarbij je van alle producten kon zien waar ze waren. Hij heeft aan een generaal die niet gehinderd werd door enige vorm van kennis of kunde voorgesteld dat defensie dat ook moet hebben. daarbij natuurlijk de financiële voordelen wat rooskleuriger gemaakt en de risico's een beetje weg gelaten en 10 jaar later hebt je dit.

[dormamu]

Dat laatste kan natuurlijk niet. De defensie is ook gewoon aanbestedingsplichtig.

[link0007]

"Dat laatste kan natuurlijk niet. De defensie is ook gewoon aanbestedingsplichtig"

Je hebt vast de aflevering van Zembla over aanbestedingsfraude bij de overheid niet gezien?

[dormamu]

Jawel, dat ging over ingehuurde Ordina consultants die vertrouwelijke informatie van de klant doorspeelde aan de sales afdeling zodat Ordina een voorsprong had bij aanbestedingen van die zelfde klant.

Dat is dus iets anders dan dat jij zelf een miljoenen project onderhands kan gunnen aan een leverancier die je wel "leuk" lijkt.

[jobvr]

Natuurlijk is defensie voor onderdelen die niet daadwerkelijk met oorlog voeren te maken hebben aanbestedingen plichtig, maar dat is nu juist het probleem. De opzet van het project was veel kleiner toen ze begonnen en het project aanbestede. Gedurende het ontwikkel en implementatie traject zijn de eisen/wensen en schaalbaarheid van het pakket steeds aangepast. en deze aanpassingen vielen natuurlijk buiten de initiële aanbesteding. Hierdoor is het project zo uit de kluiten gegroeid.

[jobvr]

Helemaal mee eens. door de flexibiliteit en complexiteit van de organisatie moet dat systeem ook erg flexibel zijn. waarschijnlijk zijn daar bij de aanbesteding en de opzet van het project wat inschattings outen gemaakt. Zo'n missie in Mali waar in eens veel materiaal naar toe moet en delen van leger onderdelen worden samengevoegd is een drama voor zo'n systeem. ook schepen hebben geen draadje achter zich aan en die itten vaak op een trage SATCOM verbinding. Dit betekend dat je lokaal eigen netwerken moet draaien. En dan heb je het idd nog niet over kleinere schepen die geen satcom hebben of onderzeeboten die grote deel van de tijd gewoon geen verbinding hebben.

Als je je die complexiteit niet helemaal realiseert en bij aanvang niet goed aanloopt loopt een project heel snel uit de klauwen.

Nu is 800 miljoen wel echt bizar. Weet iemand wie de software ontwikkelaar was. want die heeft erg goede zaken gedaan...

[Anoniem: 256386]

SAP. Meerdere modules en dus ook de defensie module...DFPS.
Maar de consultants zijn cap en atos

[Iblies]

Onderliggend probleem is nog steeds aanwezig en geld in meer of mindere mate ook voor andere ministeries.

De minister weet niet waar het geld naar toe gaat anders dan dat aan het eind van het jaar het geld op is.

En dat klinkt misschien heel kinderachtig, maar het is altijd frappant hoeveel tijd altijd nodig is om bepaalde kosten in beeld te brengen voor bepaalde uitgaven, alsof er niemand is die deze facturen betaald... Dat probleem is echt niet uniek voor Defensie,
in de zorg is het het ook altijd gissen wie wat uitgeeft en of er een belang aanwezig is,
bij onderwijs zijn we in de veronderstelling dat het geld bedoeld is voor leraren en leerlingen terwijl er terdege andere prioriteiten zijn,
bij uitkeringen hebben we landelijke en lokale regelingen waarbij we ook niet weten wat voor effecten het onder de streep heeft.


Het als een uniek probleem projecteren op defensie is niet onrealistisch. De anderen hebben er net zo goed last van.

[JAVE]

Er zal naast de redenen die supertheiz opgeeft ook nog wel behoorlijk last zijn geweest van veranderende eisen, 'feature creep', volledig omgooien van specs en meer van dat soort onzin.

Helaas weet de overheid over het algemeen zelf niet wat ze precies willen, en als er wat opgeleverd wordt dat voldoet aan de oorspronkelijke specs, dan is het toch niet wat ze bedoelden, en kan je ongeveer opnieuw beginnen.

Daarnaast heb je natuurlijk een aantal grote automatiseerders die wel lekker makkelijk omgaan met overheidsprojecten, want uitloop en over budget gaan wordt behoorlijk makkelijk geaccepteerd...

[HollowGamer]

Dit is wat ik niet begrijp.. We hebben een EU, er wordt gehamerd op meer samenwerking tussen landen (van EU), we zien over de grens ICT-projecten die iets toevoegen en we zien ze ook mislukken.

Dat ene reisje naar Duitsland, vragen naar hun ervaring, technologie overnemen.. Nee joh, we hebben hier ontzettend veel mensen met 'kennis' zitten bij de overheid. Als klap op de vuurpeil een minister die niet wist wat een cookie was/deed, maar wel mooi een wet er doorheen drukte.

Nog een voorbeeld: Duitsland heeft veel Windows PC's vervangen door Linux. Goed, het project loopt nog niet zo lekker, maar er is wel verandering.

Hier betaald de overheid nog altijd miljoenen aan MS. Maar ik ben bang dat als onze overheid die stap zou zetten, er miljoenen verdwijnen in nutteloze projecten, managers die niks toevoegen, etc.

Het wordt tijd voor een IT minister. Die kunnen we ook op de kop tikken als een (miljaren) project misgaat. Maar dat willen de hoge heren/vrouwen in Den Haag natuurlijk niet.. Dan hebben ze minder vrijheid.

Kan er maar een conclusie aanbinden: corruptie

Excuses: Was reactie op supertheiz

[Reactie gewijzigd door HollowGamer op 23 juli 2024 13:50]

[mrPopo]

ERP is een ict-systeem voor het leger waarmee onder andere kan worden bijgehouden welk materieel er beschikbaar is en waar het precies staat. Ook moest het systeem informatie houden over de onderhoud en voorraden van reserveonderdelen registreren.

Serieus en dat voor 433 Miljoen Euro......
Welk bedrijf heeft zich hiermee verrijkt? Belachelijk hoe er zo met geld wordt gesmeten bij de overheid.
En we doen er gewoon niks aan...

[Swerfer]

Er staat onder andere. Eigenlijk was het de bedoeling dat de bestaande honderden losse systemen vervangen zou worden door 1 centraal systeem. Zo is SAP ook onderdeel van het systeem voor de logistiek en Peoplesoft voor p-zaken die ook samen gekoppeld zouden worden.

[Anoniem: 636203]

Er is een parlementaire enquete geweest maar de overheid doet vrijwel niks met de aanbevelingen. Het gaat om grote bedragen en grote belangen.

[WickedStealthy]

Dit is een typisch fenomeen waar grote private spelers zich maximaal verrijken aan overheidsprojecten. De kwaliteit is heel dikwijls bedroevend laag. En dan maar zeggen dat de overheid moet besparen en afslanken. Dit is schering en inslag. Er komt veel lobbywerk aan te pas. Dit is zeker geen alleenstaand feit en toepasselijk voor heel wat overheden. Dit zie je in België regelmatig. En zeker ook op Europees niveau.

[WillySis]

Het probleem is vaak dat men vooraf nog niet duidelijk weet wat men wil, maar wel een tender uitschrijft. Daarna komen er allerhande wensen en veranderingen bij. Dat kan men dan weer onder meerwerk verrekenen. Gebruikers blijven maar punten aandragen die niet goed werken, of waar ze niet mee overweg kunnen. Dat blijft maar in een cirkeltje ronddraaien. Uiteindelijk ontstaat een breiwerk waar overal stukken zijn uitgehaald en weer tussen zijn geplakt. Enige coördinatie vanuit de overheid is meestal ver te zoeken. Meestal ligt dat bij iemand die er de ballen verstand niet van heeft.
Het hele ICT proces bij de overheid is één grote ellende, waar de grote ICT bedrijven gemakkelijk gebruik van kunnen maken. Die moeten immers ook blijven groeien en vooral winst maken.

[FreezeXJ]

De overheid moet ook afslanken, maar is nu een anorexiapatient. Alles wat ook maar op vet lijkt is weggesneden, en nu hebben we overal de lappen huid erbij hangen, maar komt de patient amper nog overeind. Deze overheid kijkt alleen maar naar de calorieën op de verpakking, en vergeet dat je ook genoeg vitaminen moet binnenkrijgen om te overleven. Tja, dan krijg je dit soort projecten. Niemand is in staat ze te leiden, of uberhaupt te beoordelen of de specificaties goed zijn. Dan gaat er een grijpgraag bedrijf mee aan de haal, die je wel juniors voor 50 per uur belooft, maar ondertussen krijgen die juniors niks gedaan, en boeken ze lekker veel uren... die ze op scrum-training zitten

[Vaevictis_]

Het gaat om SPEER. Zie https://www.rijksictdashboard.nl/projecten/158769

Ze hebben het hier over 275 miljoen en rekenkamer over 866 miljoen? Dat is nogal een gat.

Sowieso al kansloos als je ziet dat het project vanaf 2002 loopt!? Hier moet meerdere malen een scope change in zitten. Wat mij het meeste verontrust is dat niemand in die tijd heeft kunnen ingrijpen. Dit laat je toch niet gebeuren!

[Reactie gewijzigd door Vaevictis_ op 23 juli 2024 13:50]

[Verwijderd]

Als er corruptie tussen zit met mensen die geld verdienen aan verkeerde belangen. Zou dit zeer goed kunnen. Heel gemakkelijk bij zulke hoge bedragen.

[SPee]

In punten 3 en 4 zitten ook organisatorische veranderingen in.
De ene neemt deze kosten wel mee en de ander niet.

Aangezien die organisatie niet wou aanpassen, was het project al gedoemd.

[Falcon]

Lol.. moet je kijken bij Projectplan -> https://www.rijksictdashb...cumentatie/projectplannen .. niet vereist