NRC: Capgemini moet 21 miljoen euro boete betalen voor mislukt ict-project SVB

Ict-bedrijf Capgemini moet aan de Sociale Verzekeringsbank een boete van 21 miljoen euro betalen wegens contractbreuk. De multinational zou een betalingssysteem ontwikkelen voor het overheidsorgaan, maar leverde een systeem dat 'achterhaald was en niet goed bleek te werken'.

De boete is in arbitrage vastgesteld. De NRC maakt er melding van op basis van 'goed ingevoerde bronnen'. De boete komt neer op ongeveer de helft van de 43,7 miljoen euro die het project de SVB heeft gekost. In 2006 werd Capgemini in de arm genomen om voor de SVB, dat de betaling van uitkeringen als de AOW en de kinderbijslag regelt, een 'multiregelingensysteem' te bouwen. Het systeem werd met vier jaar vertraging opgeleverd.

Volgens Jetta Klijnsma, staatssecretaris van het ministerie van Sociale Zaken en Werkgelegenheid, bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar.' Dat stelde ze in 2014 toen het project stilgelegd werd.

De NRC noemt de uitspraak uniek. 'Voor zover bekend is het de eerste keer dat het Rijk met succes bij een van de grootste ict-leveranciers compensatie voor de geleden schade heeft geclaimd.' Het is namelijk niet de eerste keer dat een groot ict-project op de klippen loopt. Dit overkwam ook de Belastingdienst, het UWV, Defensie en Justitie en die mislukkingen kostten bij elkaar vele honderden miljoenen euro's. Volgens ander onderzoek van de NRC zou Capgemini bij een groot aantal van die financieel uit de hand gelopen ict-projecten van de overheid betrokken zijn.

Reacties (303)

[Martinspire]

Even de advocaat van de duivel spelen: Schuif niet de hele schuld naar Capgemini. Vergeet niet hoe slecht sommige departementen binnen de overheid gerund worden (laatste faal in het nieuws was bv Defensie) en hoe lastig het is om al een beeld te krijgen waar het allemaal op aan moet sluiten. Managementbeslissingen door mensen die vervolgens nergens verstand van hebben zorgt voor nog meer vertraging. Als ik zie wat voor puinhoop het bij de Belastingdienst is, dan kan ik me niet voorstellen dat het bij de SVB zo soepel loopt.

Ik kan me niet voorstellen dat de keuze van een oud betaalsysteem komt door Capgemini zelf, dat moet zijn voorgelegd aan SVB waar de keuze wordt gemaakt.

En ja, tuurlijk kan Capgemini uren blijven schrijven, maar dit soort negatieve press doet uiteindelijk meer kwaad dan goed en kan zelfs leiden tot boetes als deze. Het is geen liefdadigheidsinstelling, maar niemand gaat aan een opdracht werken om vervolgens deze te saboteren.

Als ik zaken lees als "bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar." dan kan ik niet anders concluderen dan dat er ook blaam bij SVB ligt. Dit klinkt namelijk als iets waar requirements en eisen constant veranderen, waardoor veel tijd en werk verloren gaat, plus het er allemaal niet beter op wordt. En hoewel de boete vast terecht is, is het jammer dat men Capgemini vervolgens als enige schuldige op het hakblok legt. Maar goed, met de huidige overheid weten we al dat verantwoording afleggen erg moeilijk blijkt te zijn en het bijna een sport is om het in de schoenen van anderen te schuiven.

[Reactie gewijzigd door Martinspire op 22 juli 2024 13:22]

[Sandor_Clegane]

Daarvoor hebben ze toch die "volwassen" projectleiders die u van A to Z ontzorgen zodat u bezig kan zijn met de dingen waar u echt verstand heeft, namelijk uw core-business?

En daarom nemen we niet zomaar een software bedrijf in de hand, maar CAP de gerenommeerde partij die volgens Gartner in de leiders kwart zit en daardoor verstand van zaken heeft en met volwassen technologieën, niet conservatief let wel, een product neer zetten waar u van achterover slaat.

Ik kan voor een deel met je mee, maar de bedragen die ermee gemoeid zijn, het falen van outsourcing en dergelijke en de arrogantie van dit bedrijf doen me nu niet echt sympathie voelen voor dit bedrijf.
Check die docu van Zembla, je staat echt met je oren te klapperen. Aan beide kanten zijn er bokken geschoten waar je niet vrolijk van wordt.

Is dit dat project dat de toezichthouder, die toezicht moet houden op CAP, ook een werknemer is van CAP? Dat is deze toch? Wij van WC eend........

Ik vraag me af waar het met software ontwikkeling zo mis is gegaan.

[gold_dust]

Het gaat 'altijd' fout met dit soort detacheerders. Het hele verdienmodel is gebaseerd op zo goedkoop mogelijk personeel in dienst te nemen, dus de top ontwikkelaars werken daar echt niet, vervolgens zo goedkoop mogelijk in te schrijven op projecten, om vervolgens de beloften niet waar te kunnen maken in de hoop op vervolgopdrachten om het recht te kunnen breien. En de schuld ligt natuurlijk altijd bij de klant, die 'weet niet wat hij wil', 'heeft geen duidelijke specificaties', etc.

Het is zeker niet alleen Capgemini, er is genoeg terug te vinden over grote projecten van andere detacheerders die net zo goed mislukt zijn. De overheid is zelf ook te incompetent om dit soort projecten in goede banen te leiden maar een dienstverlener zou inderdaad een stukje 'ontzorging' moeten kunnen bieden. Wat ze dus duidelijk niet kunnen.

[Reactie gewijzigd door gold_dust op 22 juli 2024 13:22]

[mikesmit]

De schuld ligt bij de overheid zelf, die bij wet verplicht zijn om de goedkoopste aannemer te nemen. Daarom lopen bijna alle projecten van de overheid uit in tijd en kosten.

[Zarhrezz]

Het gaat nog wat verder...er moet Europees aanbesteed worden. De laagste bieder wint. Om dit soort opdrachten uit te zetten, moeten er requirements zijn. Dit terwijl het volkomen onmogelijk is 'goede requirements', vooraf, compleet, niet-veranderlijk, etc. neer te leggen voor die Europese aanbestedingen.

Van de kant van de detacheerders moet er tijd / geld besteed worden aan de analyse van de requirements om tot een bod te komen. Hier zit het eerste probleem: in deze fase wordt al gezien dat de requirements incompleet / niet eenduidig / etc. zijn. Hier een rapport over schrijven en dit met de aanbesteder opnemen kost echter geld en er wordt geen vergoeding tegenover gezet. "Oh bedankt, je hebt gelijk, bedankt voor de moeite en je kunt straks weer meedingen naar de aangepaste opdracht die we straks communiceren". Je doet dus onbetaald werk om te kunnen bieden op een aanbesteding die je wellicht niet gaat binnenhalen want als je de gemaakte kosten doorrekent in je bod, verlies je op prijs. Het is dus volkomen logisch dat dit niet gebeurt.

Het is dus aan alle kanten bekend dat de opdracht niet klopt en niet compleet is, de prijzen zijn zodanig laag dat de uitvoerende partij geen ruimte heeft om extra werk te doen om problemen voor te zijn / op te vangen en zoals altijd is de uitkomst dus een project wat op z'n best alleen maar over het budget heengaat omdat er meerwerk afgenomen moet worden en in het slechtste geval tot een gefaald project leidt met flinke kosten voor de belastingbetaler.

Los van het acteren van de detacheerders die inschrijven is het hele systeem zodanig dat falen de enige logische uitkomst is. Zolang dit niet veranderd, houden we krantenkoppen en rapporages als deze.

[tweaker2010]

Tegenwoordig wint lang niet altijd de laagste bieder meer. Overigens zou ik Capgemini niet neerzetten als de eerste beste ICT detacheerder. Het is een enorm groot concern waar vele specialisten met kennis rondlopen. De overheid en grote bedrijven komen tenslotte niet voor niets zo vaak bij dit soort bedrijven uit. Als Capgemini keer op keer rommel oplevert kunnen ze de deuren wel gaan sluiten. Dit soort boetes is blijkbaar ingecalculeerd en gewoon peanuts voor zo'n bedrijf.

Zonder requirements kan men inderdaad geen goede inschatting doen. Kritiekpunt blijft elke keer dat de business zijn eisen blijkbaar zelf niet helder heeft en gedurende het proces steeds (extra) aanpassingen wil laten doorvoeren. Ja, dat kost veel geld en dat levert vertraging op. Aan de andere kant heeft de leverancier ook een adviserende rol in deze. Het is niet alleen een opdracht binnenhalen, maar ook de opdracht (goed) uit kunnen voeren. Dat blijft altijd lastig, zeker als het om grote prestigieuze projecten gaat.

[Zarhrezz]

Requirements op papier zijn gewoon geen goede basis voor grote software development trajecten. Tientallen jaren software development gestoeld op 'goede requirements' hebben dat wel aangetood.

Wat de input van een software traject gaat zijn, zijn dus eigenlijk altijd requirements die op z'n best een redelijke basis zijn. Meer niet. Het moge duidelijk zijn dat contracten gebaseerd op 'afvinken van de requirements' gedoemd zijn te falen.

Dat de business zijn eisen niet helder heeft en gedurende het proces steeds aanpast zouden we niet als oorzaak van falende IT trajecten meer mogen noemen. Het is namelijk een gegeven en zeker als een traject langer dan een maandje duurt is het waarschijnlijk noodzakelijk vanuit business oogpunt omdat anders het geleverde al achterhaald is voordat het live is. Als IT / ontwikkelaar kun je klagen dat de opdracht steeds verandert, maar wellicht wordt het eens tijd dat je als ontwikkelaar dat als vaststaand onderdeel van je werk gaat beschouwen.

Het probleem is dat de huidige manier van aanbesteden dat niet toelaat. Pas als er afgestapt wordt van aanbestedingen en er naar partnerships bewogen wordt, gaat je dit kunnen veranderen. Feit is dat in het huidige IT-klimaat het waanzin is om software te gaan maken gebaseerd op vaststaande requirements als die software meer dan 1-2 maanden na opstellen van de requirements pas klaar is. De wereld veranderd daar tegenwoordig veel te snel voor.

[Anoniem: 69322]

Mijn ervaring is dat aan de kant van de overheid de expertise ontbreekt om een aanbesteding uit te zetten.

Er is geen kennis in huis om specificaties boven water te krijgen, het wordt altijd een opsomming van wat er al is en dan er iets bij optellen. Geheel inrichtloos werk dus en daarmee is vrijwel de hele meerwaarde van wat nieuwe software kan bieden bij voorbaat verdampt.

Er moet veel ruimte zijn om te willen veranderen/verbeteren en ook om kritische vragen te stellen. In een politieke omgeving zoals je zie bij grote organisaties hebt, zeker bij de overheid...kan dat niet.

Dus als het al een keer goed lukt is dat puur een toevalstreffer.

[Anoniem: 408411]

Dan de vraag, waarom is die expertise er niet?

Een mogelijk antwoord is dat de gebruikelijke aanpak een expertise bij de opdrachtgever vereist die zeer dicht op het technische ligt, en dus niet aanwezig is want die moest worden ingekocht, en tegelijkertijd zeer ver van de organisatie zelf afligt.

Dit constateren haakt mooi in bij managementschrijver wijlen Peter Drucker, die zegt dat we niet in het digitale tijdperk zitten, maar in het tijdperk van het management. Tweakers weten vast allemaal dat je je
geweldig kan verliezen in al dat digitale moois. Maar tweaken is niet hetzelfde als productie draaien. Dan is het hele digitale feest een enabler, meer niet. Dus niet, "zoveel mogelijk digitaal doen", maar wel, "de juiste informatie op de juiste plek zien te krijgen", al dan niet met digitale hulp.

Dit is radicaal anders dan wat we nu doen. Het betekent onder andere dat de eerste inslag moet zijn, "wat wil de organisatie?", waaruit dan weer volgt "wat heeft ze daarvoor nodig aan informatie en kennis?", en pas daarna, "hoe doen we dat?" Meestal begint zo'n trajectje achterstevoren, met "we willen digitaal". Dat is helemaal je core business niet, "digitaal zijn".

Zeker niet voor een overheid. Dat wel pretenderen kost een hoop geld, en geeft ICT-faals. Maar het maakt de overheid niet efficienter of toegankelijker, juist niet.

Dat betekent dan dat met "requirements" beginnen eigenlijk geen zin heeft. Je begint met een doel en het pad erheen is een organisatietransformatie. Daarin kan je dan de techniek integreren, maar dat hoort geen verplichting te zijn, want niet het kerndoel.

Je kan zeggen dat "agile" met z'n incrementele stapjes dichter bij dat transformatie-idee ligt, maar het is nog steeds digitaal gedreven, niet organisatiedoelgestuurd. Hetzelfde met het partnerschapsidee. Het is een stapje weg van wat niet werkt, maar op zichzelf niet genoeg om het goed te doen.

En overheden hebben nog een eigen probleem, namelijk dat ze helemaal van starre regeltjes aanelkaar hangen tot op het punt dat zelfs de medewerkers versteend raken. Aan zulke organisaties valt nauwlijks te transformeren. Ook niet, zoals vaak wel geprobeerd wordt, door een externe kracht te laten
breekijzeren, zoals managementconsultants of via een ICT-project. Dan kon het wel eens efficienter zijn om een parallele organisatie van de grond af aan op een nieuwe leest te schoeien. Maarja, dan hou je dus een groot blik zielige ambtenaren over, en dat kan echt niet natuurlijk.

En het werkt ook nog eens niet altijd. TLS is zo'n nieuwe leest, maar al bij de beginfase zijn ze de reiziger uit het oog verloren. Zie daar achteraf dan maar weer het contact en het vertrouwen mee te herstellen.

[Sandor_Clegane]

Dit is wel een leuke opmerking, hetzelfde fenomeen doet zich ook voor bij ideeën uitwerken en is ook een van de redenen dat we van het Waterfall model van software ontwikkeling afstappen. Het is een illusie dat je van tevoren alles op papier kunt zetten en tot in de details kunt uitwerken. Juist door het probleem/idee uit te werken kom je tot nieuwe inzichten en krijg je een beter begrip van het probleem domein. Hoe beter je begrip van het probleem des te beter je het probleem kunt tackelen.

Maar dit is niet algemeen geaccepteerd.

[Ras]

Heb je helemaal gelijk aan. Eisen veranderen en dit hoort bij IT-projecten. De kunst is dan dus om de code zodanig neer te zetten dat die veranderingen ook soepel doorgevoerd kunnen worden. Het is dagelijkse praktijk dat programmeurs code te star / concreet bouwen in plaats van een abstract stuk waar vervolgens weer goed op verder gebouwd kan worden.

De aanwezigheid van abstractie wordt slecht gecontroleerd, wordt dikwijls niet vereist en wordt een programmeur dan al helemaal geen paar uurtjes extra voor gegund om het goed uit te denken en te schrijven. Als de programmeur zelf uberhaubt al in staat is om abstract te denken.

[goarilla]

De aanwezigheid van abstractie wordt slecht gecontroleerd, wordt dikwijls niet vereist en wordt een programmeur dan al helemaal geen paar uurtjes extra voor gegund om het goed uit te denken en te schrijven. Als de programmeur zelf uberhaubt al in staat is om abstract te denken.

Genoeg anti-patronen te vinden waarbij de programmeur 'te generisch' ontwikkelde. Het is dus een balans zoeken.

[cdwave]

.. Het is een enorm groot concern waar vele specialisten met kennis rondlopen...

Yep, dat zijn de lokeenden zeg maar.

Standaard is om eerst een senior specialist in te zetten die de opdracht binnen sleept. Na korte tijd worden er juniors aan het project toegevoegd en de seniors worden weggekaapt bij het project om weer nieuwe projecten op te starten, waardoor het eerste project langzaamaan ontspoort door gebrek aan kennis en visie omdat alleen de juniors zijn overgebleven en min of meer aan hun lot overgelaten.

[beerendlauwers]

Ik durf te wedden dat het met de senior profielen het ook in de soep zou hebben gedraaid. Misschien iets later, maar sowieso wel.

Softwareontwikkeling op de watervalmethode zal altijd resulteren in over budget, over tijd en onder kwaliteit.

Je moet in Time & Means denken en met Scrum aan de slag gaan. Optimaliseren op het niveau van het individu kan je een boost geven van 2-3x productiviteit (output van junior vs senior). Optimaliseren op het niveau van het team geeft periodieke boosts van 4-10x productiviteit.

[Mellow Jack]

Hoeft niet perse zo te zijn. Ik heb in meerdere type projecten meegedraaid en het is vooral goed project management wat succes oplevert, Agile /Scrum is een goede methode maar het is niet zo dat waterfall niet kan omgaan met veranderingen (mits je hier maar rekening mee houdt in de planning). Een project doe je toch vaak obv een architectuur, veel uitdagingen kan je zien aankomen mits je als projectleider uit je bubbel kan stappen

[altasia]

Nog een aantekening bij de term "senior", dit ben je altijd binnen 1 a 2 jaar in dienst bij Cap of zodra je op een project langer dan 6 maanden succesvol hebt meegelopen.

[Anoniem: 1322]

Wat je beschrijft is ieder IT bedrijf met meer dan 50 man personeel

[Rutix]

Niet met je eens. Ik ken zeker ook bedrijven die 50+ man zijn maar het wel snappen en het wel goed doen. Zij winnen echter vaak dit soort aanbestedingen niet omdat ze kwaliteit leveren en kwaliteit kost nu eenmaal geld.

[zwiep]

Dit punt is tot op heden heel moeilijk over te brengen op het management van een potentiële aanbesteder. De setup van een goed project + om er daarna goede onderhoudbare code op te schrijven heeft ook een kost. Een kost die weliswaar niet direct business value oplevert en dus vaak als extra kost gezien wordt.
Ze kijken vaak niet verder dan de (veel te kort opgelijste) requirements en beslissen dan maar op basis van het prijskaartje.

[Martijn033]

Zij winnen dit soort aanbestedingen vaak niet omdat ze überhaupt dit soort aanbestedingen niet doen. Meedoen in een Europese aanbesteding is een vak apart waar bedrijven zoals CAP haast een aparte afdeling voor hebben. Het vraagt zoveel specialistische kennis om correct op zo'n aanbesteding in te schrijven...

[Croga]

Kritiekpunt blijft elke keer dat de business zijn eisen blijkbaar zelf niet helder heeft en gedurende het proces steeds (extra) aanpassingen wil laten doorvoeren.

Dat klopt. Dat is niet raar. Dat is de werkelijkheid die de meeste mensen nogsteeds niet onder ogen durven te zien: Het is onmogelijk om requirements van te voren helder te krijgen. En dat is precies wat Zarhrezz zegt: "Aanbesteding" vereist heldere requirements van te voren. Realiteit zegt dat dat onmogelijk is. Resultaat is een enorme chaos waar niemand beter van wordt.

Ik ben in ieder geval om die reden volledig gestopt met voor de overheid te werken. Aanbestedingen zorgen er voor dat het onmogelijk is om een succesvol IT project bij de overheid te doen.

[OddesE]

Aanbestedingen zorgen er voor dat het onmogelijk is om een succesvol IT project bij de overheid te doen.

Dit geloof ik ook. De overheid gedraagt zich als een klant die een product koopt en daar garantie op wil. En vervolgens naar de rechter stapt als zaken niet goed werken. Het enige dat deze boete tot gevolg zal hebben is dat IT dienstverleners nog angstiger worden om dit soort opdrachten aan te nemen. Want wat valt er nu eigenlijk te winnen hier?

De overheid moet verantwoordelijkheid nemen voor haar eigen processen. Waarom lezen we dit soort artikelen nooit over grote bedrijven die toch ook een hele IT infrastructuur neer moeten zetten. Wanneer was het laatste grote mislukt IT project bij.. zeg.. Shell?

De overheid zal eens in moeten zien dat een IT project gaan doen met zoveel maatwerk, nieuw ontwikkelwerk een inherent groot risico is. En dat er offers gebracht moeten worden. Dat het niet is wij zeggen, Cap Gemini (of wie dan ook) draait wel. Het is een gezamelijk project. De software moet zoveel mogelijk aansluiten bij de organisatie, maar het omgekeerde geldt ook. De overheid moet niet bang zijn de boel om te draaien en de organisatie eens aan te laten sluiten bij de software.

De meeste bedrijven accepteren dat er gewoon bepaalde mogelijkheden en onmogelijkheden zijn als het op software aan komt. Je gebruikt standaard pakketten met standaard workflows en standaard aansluitmogelijkheden en je verandert jezelf zodat je organisatie daarmee kan werken. De overheid wil altijd de software aanpassen / laten bouwen want deze moet naadloos aansluiten bij de processen / software die men 30 jaar geleden bedacht heeft. Waanzin.

Neem nou DigID... Moet de NL overheid nou echt zijn eigen identity service verzinnen en alle gemeentes gaan dwingen ermee te werken? Waarom niet OpenID Connect / OAuth2 pakken en de gemeentes een client laten zijn van een dergelijk systeem? Ik durf te wedden dat als een echte expert de macht zou krijgen om zijn zin erdoor te drukken hij het hele authenticatie systeem bij de NL overheid binnen een jaar op orde zou hebben.

Weinig medelijden verder met Cap want dit is imho ook echt geen fijn bedrijf verder. Maar deze boete bewijst echt niet dat de overheid 'onschuldig' is. Dit nieuws zullen we blijven krijgen omdat de overheid gewoon veel te afwachtend deze projecten in gaat. Neem controle!

[kidde]

De IT-sector als geheel zou zich kunnen verbeteren, als de IT'ers uit de markt en IT'ers / aanbesteders bij de overheid niet continu naar elkaar zouden wijzen, maar als ze samen in de spiegel keken en zouden leren van de 'buurman'. Al die reacties die heen en terug wijzen tussen IT en overheid komt nogal potsierlijk over op de niet-IT'er, alsof overheid / usual-suspect IT-bedrijven (Capgemini, Atos, Logic, Sogeti, Centric - zijn dat ze zo ongeveer?) een incapabele draaideur-pot nat is die er niets van bakken en keer op keer falen, terwijl ik zeker weet dat er aan beide zijden capabele mensen zitten die keihard hun best doen. Expertise en goede wil is volgens mij niet het probleem, dat kan en wil ik niet geloven.

Kortom, meer 'volwassenheid' tonen en toegeven dat de toch enigszins conservatieve IT net een paar jaartjes achterlopen op sommige andere sectoren, en dat de IT van die andere sectoren kan leren: Toon leergierigheid door verder dan de eigen sector te kijken, en voer eens een keer niet het gebruikelijke naar-elkaar-wijs toneelstukje dat de belastingbetaler inmiddels zo verwacht.

Neem RWS en de bouw, die hebben de laatste tijd zeer veel faal-projecten gehad. Verzakte panden aan de Vijzelgracht met de Noord-Zuidlijn. In het geval van Ansaldo-Breda werden de goedkoopste Fyra-prullen gekocht die mogelijk waren (een bewuste keus van de NS overigens met als bedoeling de politiek een lesje te leren en de aanbesteding te laten mislukken); hieraan ging Ansaldo-Breda bijna failliet en zoals u zegt ging de overheid naar de rechter. Ook voor infra werden er boete-clausules opgenomen, maar veel heftigere dan dit schijntje voor CapGemini, zoveel zelfs dat Ballast Nedam haast failliet ging na een simpele maar domme blunder. Ook de Roertunnel was een drama, oa ook door software.

Een logische reactie is dan de uwe

De meeste bedrijven accepteren dat er gewoon bepaalde mogelijkheden en onmogelijkheden zijn als het op software aan komt. Je gebruikt standaard pakketten met standaard workflows en standaard aansluitmogelijkheden en je verandert jezelf zodat je organisatie daarmee kan werken. De overheid wil altijd de software aanpassen / laten bouwen want deze moet naadloos aansluiten bij de processen / software die men 30 jaar geleden bedacht heeft. Waanzin.

Met andere woorden, we laten het kopje hangen, accepteren dat we het niet beter kunnen en geven het op om nieuwe technologie te ontwikkelen, vooruitstrevend te zijn en op nieuwe manieren met elkaar samen te werken! We pakken alleen nog bewezen technologieën. Maar werkt dat? Juist bij de Noord-Zuidlijn was het de bewezen technologie met damwanden (damwanden zijn de OpenID Connect / OAuth2 uit de bouwwereld) die voor de verzakte panden zorgden; juist het nog nooit vertoonde overcomplexe huzarenstukje "tafel onder het drijfzand van het monumentale Amsterdam CS bouwen" ging goed, terwijl het station openbleef.

Toen er een snelweg-tunnel onder Maastricht moest komen, was het dus een logische reactie voor de overheid om 'standaard pakketten met standaard workflows' te pakken, gezien al het falen. Hier iets compleet nieuws met niet-bewezen technologie bouwen, onder / naast een van de drukste wegen van Nederland met huizen ernaast zou waanzin zijn. Maar zie, het voor onmogelijk gehouden gebeurde: RWS leerde van haar fouten! Van het falende boete-model bij de A15, van de tunnel ellende in Roermond, de goedkoopste aanbesteding bij de Fyra. En ze kozen voor iets moeilijks: De eerste dubbeldeks-tunnel in Nederland met daarbovenop dan ook nog eens een stads-laan (eigenlijk drie lagen dus), midden in een stad waar het leven door moest gaan en de bestaande A2 moest openblijven. Totale waanzin. Het moest wel technisch falen, de veiligheids-software is te complex dus moest wel niet werken, dit moest wel jaren langer duren dan gepland en veel meer gaan kosten. Had ik ook gedacht, eerlijk waar.

Resultaat: De drielaags Koning Willem Alexander tunnel, op tijd af en binnen budget. Overheid blij, leverancier blij, automobilist blij, belastingbetaler blij, zellufs de (meeste?) Mestreechenaren blij.

Loopt u hier nou te insinueren dat de private IT-sector / aanbesteders bij de overheid niet tot zo'n RWS/bouw-achtige verbeterslag in staat zijn, of lees ik dat verkeerd? Hoewel ik graag geloof dat IT iets heel anders is dan infra (hoewel infra dus veel software gebruikt), en dat de situaties moeilijk te vergelijken zijn, hoop ik toch vanuit de grond van mijn hart dat het verbeterpotentieel er wel degelijk zit.

[Cybertek]

Het is toch welbekend dat NL IT-bedrijven de overheid vele miljoenen hebben afgetroggeld en te weinig hebben neergezet?

Dat is volop in het nieuws! Der wordt met miljoenen gesmeten door de overheid en ze functioneren voor geen ruk. En die IT-ers maar lachen. In dit geval treft het zelfs ouderen en kinderen (kinderbijslag). Dat de SVB niet naar behoren functioneerd dat hebben we gezien de afgelopen jaren met de PGB en dhr. Van Rijn. Dus, ik denk dat CAP hier niet alleen verantwoordelijk moet worden gehouden en dat het wel meevalt wat hier uiteindelijk uitkomt.

Uitbesteden aan een ander Europees land (lees:bedrijf) is een no-go. De Nederlandse staat geeft geen inzage in inwonende Nederlanders aan het buitenland tenzij dat gerechtelijk bepaald/opgedragen wordt.

Wat de staat moet doen is als de sodemieter gaan investeren in een eigen computergarde die het heft in eigen handen neemt zoniet inzage heeft in zowel interfaces als code.

[d-snp]

Uit de documentaire van Zembla blijkt dat Capgemini juist wel keer op keer rommel levert en nooit de deuren hoeft te sluiten. Blijkbaar zijn er verschillende aanbestedingen gewonnen door Capgemini die op niets uitliepen. Op zijn best heeft Capgemini een slechte interne evaluatie voor de kwaliteit van hun managers, en op zijn slechtst is het simpelweg het businessmodel van Capgemini om kwaliteit geen prioriteit te geven.

[Atlantis1995]

Er zijn bedrijven die zich specialiseren op dergelijke bids. lees je een punt verkeerd, 0 punten vooor die requirement.

[boolean]

De tijd dat CAP uitsluitend kundig/gekwalificeerd personeel in dienst had, hebben ze al ver achter zich gelaten. Wij hebben in drie jaar tijd al ruim acht "cappers" de deur gewezen omdat ze ondermaats presteerden.

[MicGlou]

Waar staat dat de overheid bij wet verplicht is om de goedkoopste partij te nemen? Maakt eigenlijk niet uit, want het is sowieso onzin dat ze die verplichting hebben. Het enige uitgangspunt van een 'europese aanbesteding' is om een zo eerlijk mogelijk aanbestedingstraject te doorlopen, dit wordt gedaan door een pakket aan eisen en voorwaarden voor te leggen waarop verschillende partijen mogen bieden als ze geïnteresseerd zijn. Als hierbij blijkt dat een partij betere voorwaarden of producten biedt dan een andere partij voor een hogere prijs dan is de kans heel groot dat er meer betaald wordt voor die betere voorwaarden.

Een voorbeeld hierin is bijvoorbeeld een schoonmaakbedrijf dat zich ieder half jaar laat toetsen door een onafhankelijke partij en als de werkzaamheden niet naar voldoening zijn hoeft de rekening niet te worden betaald... het contract met dit schoonmaakbedrijf mocht dan wel duurder zijn dan overige partijen maar deze voorwaarde zet wel extra druk op het bedrijf om de werkzaamheden altijd naar een bepaalde standaard uit te voeren.

Of een nieuwe aanbesteding voor telecom waarin een hele harde voorwaarde is gesteld over de kwaliteit van het netwerk, zeker als het om bepaalde gebieden gaat. Daarbij werd dan ook voor een partij gekozen die weliswaar een hoger bedrag per aansluiting vraagt, maar zwart-op-wit heeft dat wanneer de kwaliteit van het netwerk niet goed blijkt te zijn op plekken in het werkgebied dat ze een verplichting hebben dit op te lossen.

[Croga]

Waar staat dat de overheid bij wet verplicht is om de goedkoopste partij te nemen? Maakt eigenlijk niet uit, want het is sowieso onzin dat ze die verplichting hebben. Het enige uitgangspunt van een 'europese aanbesteding' is om een zo eerlijk mogelijk aanbestedingstraject te doorlopen, dit wordt gedaan door een pakket aan eisen en voorwaarden voor te leggen waarop verschillende partijen mogen bieden als ze geïnteresseerd zijn. Als hierbij blijkt dat een partij betere voorwaarden of producten biedt dan een andere partij voor een hogere prijs dan is de kans heel groot dat er meer betaald wordt voor die betere voorwaarden.

Het probleem met een dergelijk pakket aan eisen en voorwaarden is dat het zo in de IT niet werkt.....

Ten eerste weet men helemaal niet wat de eisen en voorwaarden zijn en dus schrijven ze maar wat op. 60 jaar ervaring met IT projecten heeft ons allen geleerd dat het onmogelijk is om de eisen en voorwaarden juist op te schrijven.

Ten tweede is er niets zo in beweging als IT, zeker bij de overheid. Dat betekend dus dat alles wat wél opgeschreven is, al achterhaald is voordat de offertes binnen zijn.

De overheid is bij wet verplicht de partij te nemen die het beste fabeltje schrijft naar aanleiding van het sprookje wat de overheid zelf geschreven heeft. Ofwel: De overheid is verplicht degene te nemen die de juiste onzin weet te antwoorden op de onzin die de overheid zelf geschreven heeft. Hoe kunnen daar ooit winnaars zijn?! Want neem van mij aan, de juristen van de gekozen partij zijn gegarandeert beter dan die van de overheid; tenslotte heeft de overheid vooral gevraagd aan de beste jurist om zich in te schrijven, niet aan de beste ITer.

[GateKeaper]

En als je niet seperaat opmerkingen aanleveren, maar een offerte schrijft voor de juiste implementatie, en aangeeft waarom je dingen anders aanpakt dan gevraagd, verlies je de aanbesteding omdat je niet voldoet aan de vraag.

Meermaals meegemaakt inderdaad. Opdrachten van de overheid win je op prijs. Niet op kwaliteit van je aanbieding.

[maomanna]

Het is dus aan alle kanten bekend dat de opdracht niet klopt en niet compleet is, de prijzen zijn zodanig laag dat de uitvoerende partij geen ruimte heeft om extra werk te doen om problemen voor te zijn / op te vangen en zoals altijd is de uitkomst dus een project wat op z'n best alleen maar over het budget heengaat omdat er meerwerk afgenomen moet worden en in het slechtste geval tot een gefaald project leidt met flinke kosten voor de belastingbetaler.

is het niet zo dat dat altijd is bij een vrijblijvende offerte?!
de aanbesteding is echt een giller. gaat veel te vaak fout omdat er verwachtingen van beide partijen scheef zijn.

[Grrrrrene]

Het gaat nog wat verder...er moet Europees aanbesteed worden. De laagste bieder wint. Om dit soort opdrachten uit te zetten, moeten er requirements zijn. Dit terwijl het volkomen onmogelijk is 'goede requirements', vooraf, compleet, niet-veranderlijk, etc. neer te leggen voor die Europese aanbestedingen.

Zo gaat het overal, niet alleen in de ICT. Herinner je je dat kraanongeluk in Alphen a/d Rijn nog? Op werk huren we geregeld een kraanbedrijf in, een van de grotere en gerenommeerdere in Nederland (zal geen namen noemen) en die gaven aan ook aangeboden te hebben op die klus. Uiteindelijk is die hijsklus gedaan voor een bedrag waar zij van zeiden "dat kan nooit voor dat geld". En jawel, het gaat fout. Geen enkel bedrijf kiest de aanbieder puur op prijs, waarom doet de overheid dat dan wel met zulke belangrijke projecten? Gebrek aan kennis en dus geen idee of ze appels met appels vergelijken?

M'n vriendin werkte voor een overheidsorganisatie en daar kwamen dit soort grote clubs ook. Daar had je dus echt he-le-maal niks aan. De mensen die gedetacheerd werden hadden geen kennis van zaken (logisch, anders had je wel een goedbetaalde baan elders genomen) en de organisatie bood geen meerwaarde. Combineer dat met een totaal gebrek aan kennis vanuit de hogere lagen bij de overheid en daardoor totaal geen eisen in de contracten en je hebt een recipe for disaster.

[Reactie gewijzigd door Grrrrrene op 22 juli 2024 13:22]

[TheekAzzaBreek]

Het gaat nog wat verder...er moet Europees aanbesteed worden. De laagste bieder wint. Om dit soort opdrachten uit te zetten, moeten er requirements zijn. Dit terwijl het volkomen onmogelijk is 'goede requirements', vooraf, compleet, niet-veranderlijk, etc. neer te leggen voor die Europese aanbestedingen.

Een veel voorkomend misverstand. De aanbestedingsregels zeggen vooral dat er op duidelijke, vooraf vastgestelde criteria geselecteerd wordt. Je kan er voor kiezen vooral op prijs te selecteren, maar dat hoeft helemaal niet. Dat kan net zo goed prijs, kwaliteit of snelheid zijn, of hoe roze het eindproduct wordt.

[klonic]

Dit terwijl het volkomen onmogelijk is 'goede requirements', vooraf, compleet, niet-veranderlijk, etc. neer te leggen voor die Europese aanbestedingen.

Waarom?

"Oh bedankt, je hebt gelijk, bedankt voor de moeite en je kunt straks weer meedingen naar de aangepaste opdracht die we straks communiceren".

Ze kunnen ook gewoon niet meedingen... Ik vind het goed dat je steeds vaker ziet dat aannemers (of dat nou Capgemini of het consortium achter de verbreding van de A15 (in het artikel staat dat rijkswaterstaat betaald aan het consortium, maar het consotrium heeft nog altijd forse verliezen gemaakt op deze projecten). Bedrijven moeten zich voor een goede prijs inschrijven, doen ze dat niet, dan moeten ze ook de risicos van die inschrijving accepteren, dat kennelijk hoe het nu werkt en wat mij betreft is dat heel goed.

[Zwollebuds]

Dit lijkt me toch iets te kort door de bocht. Aanbesteden geschiet tegenwoordig verplicht op basis van beste prijs/kwaliteit verhouding. Dit betekent dat je prijs voor een x aantal % laat meetellen, en kwaliteit voor de rest. Bijvoorbeeld door 20% laagste prijs, 40% plan van aanpak, 20% innovatie, 20% duurzaamheid oid. Laagste prijs kan enkel indien het gaat om eenheidsworst, zoals benzine of zand.

Het probleem zit erin dat de overheid kennis ontbreekt om deze criteria slim op te stellen. En omdat de verkeerde criteria worden opgesteld, wordt de verkeerde ondernemer uiteindelijk gekozen.

Het aanbestedingssysteem op de schop gooien is helaas niet zo makkelijk, dit is vooral Europees geregeld.

[djiwie]

Dat klopt niet helemaal. Je kunt ook kiezen voor "Economisch Meest Voordelige Inschrijving" (EMVI) (heet tegenwoordig anders, maar zelfde principe). Komt er op neer dat je iedere aanbieding op een aantal criteria beoordeelt, waarvan prijs maar een gedeelte is. Je kunt zo bewerkstelligen dat aanbieding met hogere kwaliteitsscore beter beoordeeld wordt dan een goedkopere bieding die kwalitatief inferieur is.

Probleem is echter dat het vrij lastig is om kwaliteit objectief en eerlijk mee te wegen. Je kunt vrijwel niet leunen op historie (want dan sluit je nieuwe partijen uit), en een groot deel van zo'n aanbieding is in feite een beschrijving hoe de leverancier van plan is om het project te doen.

Meer informatie: https://www.pianoo.nl/met...prijs-kwaliteitverhouding

[CEx]

Meest voorkomende probleem is dat er vervolgens op punten nauwelijks onderscheidende criteria zijn en de prijs die eigenlijk slechts 5 tot 10% van de punten was alsnog de onderscheidende factor gaat zijn.

[Wasrek]

Dat is Europese aanbestedingswetgeving ja. Daar heeft de de Sociale Verzekeringsbank weinig invloed op. De overheid als geheel theoretisch misschien wel, maar ja in die denklijn hebben zijn jij en ik ook "schuldig" .

[MicGlou]

Daar heeft de Sociale Verzekeringsbank alle invloed op als ze een duidelijk pakket van eisen en voorwaarden opstellen... en zoals ik hierboven al in een reactie heb beschreven is het nonsense dat er verplicht voor de goedkoopste partij gekozen moet worden, er wordt gekozen voor de partij die het beste aansluit aan de eisen en voorwaarden.

[supersnathan94]

En dat is dus het stomme van die aanbestedingsregels. Goedkoop is vrijwel altijd duurkoop. Helemaal bij ICT projecten waar kwaliteit vaak gewoon echt serieus geld kost. Ik snap daarom dan ook niet dat er blind op een paar brieven wordt gestaard. Een aanbesteding in het bedrijfsleven doe je toch ook niet zonder een gesprek met die partij? Dan ga je toch ook eerst om de tafel zitten om te kijken of het wel slim is en of beide partijen bij elkaar passen?

Aanbestedingsregels m’n neus. Laat bedrijven maar lekker solliciteren op een project. En dan niet alleen met de salesmensen, maar ook daadwerkelijk de mensen die de kar gaan trekken. Als een developer daadwerkelijk met jou en je gebruiker(s) om tafel gaat zitten is de kans vrij groot dat het binnen no-time wel goed gaat.

[MicGlou]

Aanbestedingsregels m’n neus. Laat bedrijven maar lekker solliciteren op een project.

En wat denk je wat een dergelijk aanbestedingstraject is? Precies wat jij zegt, bij een europese aanbesteding solliciteren partijen op een project en dan gaat het niet om de goedkoopste, het gaat om de beste partij. Het is echt nonsens dat er verplicht voor de goedkoopste gekozen moet worden. De overheid is echt niet totaal op het achterhoofd gevallen en snapt ook wel dat als je voor een dubbeltje op de eerste rij wil zitten dat de kans heel groot is dat het resultaat vies tegen zou kunnen vallen.

En dit geval is 1 van de redenen waarom die regels zijn opgesteld, nu kunnen partijen die niet (goed) opleveren dus ook daadwerkelijk hard worden aangepakt ipv dat het een bodemloze put van geld lozingen wordt.

[supersnathan94]

Nou ik ben dus bang dat het heel erg tegenvalt om eerlijk te zijn. Zullen we voor de gein Tenderned eens even doornemen voor een recente opdracht? Ik zag dat de gemeente deventer nieuwe “complexe” hardware ergens voor nodig had. Ik ben dus even gaan kijken op de pagina van PIANOo. Het expertise centrum van het ministerie van EZ. Als ik dan ga kijken wat de aanbesteding precies inhoud krijg ik een mooi document van 34 pagina’s met daarin de aanbesteding voor mijn neus: https://www.tenderned.nl/...19806451311da19/cid/39919

Ik ben dus even gaan kijken wat hier nou precies in dit document staat. Ik moest eigenlijk wel een beetje lachen om eerlijk te zijn:

Geef een beschrijving van de merkbreedheid van uw assortiment en specificeer dit naar naar (i) thin clients, (ii) desktops, (iii) laptops/notebooks, (iv) beeldschermen/touch screens, (v) toetsenborden, (vi) muizen, (vii) mobiele telefoontoestellen/smartphones, (viii) tablets en hand helds, (ix) specifieke printers als desktopprinters en labelprinters en (x) docking stations.
Er dienen standaard minimaal twee A-merken van iedere apparatuursoort te worden gevoerd (knock-out, zie paragraaf 7.1). Voor het beantwoorden van deze vraag komen alleen merken in aanmerking die in Nederland worden ondersteund door de fabrikant (knock-out).
Beoordelingskader (na toetsing op knock-out): van alle apparatuursoorten drie A-merken: 12 punten; daarnaast van beeldschermen/touch screens meer dan drie A-merken: 6 punten extra; daarnaast van telefoontoestellen/ smartphones meer dan drie A-merken: 6 punten extra. Met de zinsnede ‘daarnaast’ wordt bedoeld: indien genoemde 12 punten zijn behaald. Met beantwoording van deze vraag kunnen derhalve maximaal 24 punten worden behaald.

Sorry maar wat is dit? Ga je nu serieus vragen naar WAT iemand kan leveren?
En ga je nou bonuspunten geven voor het feit dat iemand 3 “A-merken” in het assortiment heeft? Dit is toch geen manier om aan te besteden? “Ja wij leveren computers van merk A, B en C met muizen en tobos van merk X en Y.”

Geen wonder dat het zo vaak fout loopt. Je past op deze manier je eisen aan aan wat er leverbaar is. Je moet uiteindelijk kiezen voor wat je nodig hebt en daar eisen aan stellen. Niet vragen naar wat iemand kan leveren en daar dan vervolgens uit kiezen. Dit is even een simpel voorbeeld overigens. Hier gaat het om een berg “complexe” hardware (wat gewoon standaard spul is) en daar kun je best eisen aan stellen toch? Wat heeft het voor nut om aan ieder mogelijk bedrijf in europa te vragen welke computer ze kunnen leveren? Dat is letterlijk ieder apparaat tussen de 10 en 12.000 euro. Beetje vaag vind je niet? Wat heb je nu daadwerkelijk nodig dan? Waarvoor ga je de hardware gebruiken en met welke software? Afhankelijk van het gebruik kan het namelijk beter zijn om twee kleinere monitoren neer te zetten in plaats van 1 hele grote. Afhankelijk van wie het gaat gebruiken is het misschien slimmer om een hufterproof toetsenbord te leveren of juist mechanisch. Misschien is een hexacore i7 overkill?

Nergens lees ik een harde eis aan de daadwerkelijke hardware en overal lees ik “hoe ga je om met...?” “wat kunnen jullie leveren...?” “Geef een beschrijving van de wijze waarop...”

Schiet mij maar lek, maar met zulke vragen ga je natuurlijk vragen om problemen. Want tot hoe ver kun je gaan? Welke merken zijn bijvoorbeeld geen A-merk? HP, Canon en Xerox maken alledrie prima printers, maar afhnakelijk van het gebruik ga ik voor professioneel zakelijk gebruik met honderden tot duizenden prints per week liever voor een ricoh.

En dat is dus precies het probleem wat ik bedoel. Nergens wordt er daadwerkelijk gekeken naar wat heb ik nodig alleen naar wat er te bieden is. Voor een salespersoon is dit dus prima zo te bouwen dat hij hier goede antwoorden op kan geven. Terwijl de daadwerkelijke ontwikkelaars uiteindelijk denken: ja maar ho ff. Dat kan helemaal niet als ze dat op dezemanier echt willen. Ondertussen zijn we dan al weer een jaar verder en dat alleen maar omdat er geen eisen worden gesteld aan het product, functionaliteit en de kwaliteit daarvan, maar alleen aan zoveel mogelijk kunnen leveren, duurzaam bezig zijn en dat je een fatsoenlijk verhaal hebt over de term “social return”. Het stomme daarvan is dan weer dat het gewenste antwoord letterlijk binnen dezelfde website is te vinden:
https://www.pianoo.nl/the...mvi-thema-s/social-return

Hier trouwens nog een link naar de confomiteitenlijst bij deze aanbesteding. Deze moet je verplicht met ja kunnen invullen anders wordt je inschrijving niet eens in behandeling genomen.
https://www.tenderned.nl/...19806451311da19/cid/39919

[MicGlou]

Om jouw lange verhaal kort te maken... het heeft inderdaad weinig zin als de mensen die zijn aangewezen om het aanbestedingstraject te leiden totaal niet snappen wat belangrijk is om te vragen/eisen. Maar dat is niet het probleem van de europese aanbestedingen zelf, dat is een (flinke) tekortkoming in hoe en door wie dit wordt ingevuld... en dat geldt uiteraard voor iedere 'sollicitatie' op een project, als je de verkeerde vragen stelt, of beter gezegd je vragen flink abstract houdt dan vraag je om ellende.

PS... voor een aanbesteding van printers hoef jij dus ook niet mee te worden genomen in het traject,
daar ga jij zelf ook fout door aannames over bepaalde merken. Waarom zou je een Ricoh boven een Canon willen verkiezen? Op welke basis doe je dat? Want dat lijkt er sterk op dat je bijvoorbeeld niet weet wat een bedrijf als Canon kan leveren, ze zijn toch echt de grootste leverancier met het breedste assortiment ter wereld sinds ze Océ hebben ingelijfd.

[supersnathan94]

Op basis van die honderd tot duizende printjes per week. In nederland is Ricoh dan bijvoorbeeld een goed leverbaar merk met prima ondersteuning. De canon thuis noemden we altijd Bob Marley. Because he kept jammin’.

Maar goed ik hoef op die aanbesteding niet in te schrijven want daar ging het niet om en ik heb al een prima job. Het punt was meer dat er nu helemaal niks aan eisen worden gesteld en bovenstaande is dan dus ook gebasseerd op mogelijke redeneringen binnen het vak.

[Splorky]

Volgens mij is het idee dat er dan 'vriendjes' met inside informatie heel gericht een goede offerte kunnen maken.

Zie Nova zembla over hoe dat te werk gaat, gaat ook over Capgemini, hoog tijd dat ze boetes kregen.

[Nap]

nvm

[Reactie gewijzigd door Nap op 22 juli 2024 13:22]

[PizzaMan79]

Beetje off topic, dit is een heel andere aanbesteding. De vraag is hoe de aanbesteding bij de svb is gegaan.

[Sandor_Clegane]

Deze regels zijn meer het kaf van het koren scheiden gok ik, als je een eenmanszaak bent of een kleine ICT doezenschuiver, voer je niet drie "A-Merken". Ergo, deze schrijven zich dan ook niet in voor deze tender. Of dit nu de manier is, ik denk het niet.

Maar ik snap je punt.

[supersnathan94]

Zelfs als eenmanszaak kun je dit dus eigenlijk gewoon prima doen. Waarschijnlijk heb je hierna voldoende werk om door te kunnen groeien het volgende contractsjaar in. Er zijn namelijk twee verleningen van 12 maanden mogelijk die je moet accepteren. Doe je het goed dan heb je die verlenging dus automatsich. Als eenmanszaak dus juist een prachtige kans.

En dan zit ik meer met het probleem: wat zijn A-merken? Als het gaat om toetsenborden en muizen dan is logitech of microsoft al voldoende want die leveren voor zakelijk gebruik prima rand apparatuur. Echter zie je ook vaak zat HP en Dell toetsenborden. Ook een a-merk maar op het gebied van toetsenborden vind ik ze totaal niet ergonomisch in gebruik. Veel te zompig.

[Sandor_Clegane]

Ik denk niet dat ze op het gebied van toetsenborden zo nauw kijken......

[supersnathan94]

Hoezo niet? Het weegt net zo zwaar mee volgens de documenten. Daar anders mee ongaan kan betekenen dat andere partijen hier een zaak over kunnen beginnen omdat het dan niet meer non-discriminatory is.

[Yucon]

Hier staat gewoon dat een fabrikant met een geweldige productaanbod maar die wel alleen maar microsoft muisjes levert bij voorbaat in kan pakken

[Anoniem: 798783]

De DROW zocht een logistiek dienstverlener met betrekking tot ICT Hard- en software voor de komende 2 tot 4 jaar. Dan wil je een bedrijf dat een ruim assortiment voert en die eis verwerk je in de uitvraag. Daar is niets vreemds aan. Je wilt voorkomen dat je bijvoorbeeld over een jaar een paar tablets wilt aanschaffen en je goedkope meuk in je maag gesplitst krijgt, die je niet kunt weigeren, omdat je bij de aanbesteding bent vergeten keuzevrijheid in te bouwen.
Waarom heb je het eerst over het onderdeel complexe hardware en plak je dan een vraag in die bij het onderdeel devices hoort? De uitvraag niet goed gelezen of om de procedure belachelijk te maken?

Overigens zie ik niet wat een aanbesteding voor een logistiek dienstverlener nu duidelijk maakt aan het gedoe rond Capgemini. Appels en peren.

[supersnathan94]

Ah klopt. Foutje van mijn kant. Complexe hardware is perceel 2. Je verwacht toch hopelijk niet dat ik mijn vrije zaterdag avond een heel document als dit door ga zitten nemen om het helemaal Kompleet af te dekken? Je snapt wat ik bedoel en dat het raar is dat er geen specifieke eisen worden gesteld ook niet bij perceel 2 en 3.

Overigens is het assortiment ondergeschikt aan de eisen die je hebt mbt tot kwaliteit van de producten. Zo is HP een A-merk, maar zijn hun toetsenborden en muizen bijvoorbeeld bijzonder slecht om de hele dag mee te werken. Zeker in deze branch is een merk leuk, maar is het erg afhankelijk van het type device.

[Reactie gewijzigd door supersnathan94 op 22 juli 2024 13:22]

[Zwollebuds]

T.a.v. die conformiteitenlijst, het doel hiervan is om onbetrouwbare en incapabele ondernemers buiten de deur te houden.

Wil je als overheid die 1000 laptops nodig heeft een bedrijf dat er slechts 200 kan leveren? Nee toch?
Of een bedrijf dat 100 gestolen laptops heeft overgenomen en ze met dikke winst doorverkoopt?

Die lijst ziet op dit soort zaken. Dus ik snap echt totaal niet waarom je negatief daarover doet. Idealiter voorkomt het dat Capgemini weer in aanmerking komt voor een aanbesteding. Uitsluitingsgronden zien namelijk ook op aanzienlijke fouten in de uitvoering van een overheidsopdracht.

[Anoniem: 855731]

De regels zijn niet verkeerd maar ee inkopers zijn niet competent genoeg. Als je geen verstand vand e materie hebt kan je alleen maar op prijs selecteren. Als je ziet hoe groot overheidsprojecten zijn in vergelijking met gemiddelde projecten buiten de overheid dan zou de overheid de beste inkopers, contract managers en projectleiders die er te vinden zijn in dienst moeten nemen. Maar die krijg je niet als het salaris onder de balkenende norm moet blijven. Geef de beste mensen op hun vakgebied wat ze willen hebben en je verdient het vanzelf terug.

[supersnathan94]

En dus zijn de regels verkeerd. Als het incompetentie ondersteund zijn de “regels” of richtlijnen niet duidelijk genoeg opgesteld. Zelfs al zouden ze erbij hebben gezet “we hebben dit pakket qua software en we willen deze responsetijden kunnen garanderen, wat raad u aan qua hardware specificaties?” Dan hadden ze een logische advies vraag gehad waar een vendor wat mee kan.

[CEx]

Er zijn legio mogelijkheden om toe te passen in een aanbesteding, van het vooraf aangeven en interviewen van het geachte implementatieteam tot het uitvoeren van proof of concepts onder de ogen van een reviewgroep. In het bedrijfsleven is vertrouwen in een huidige of via via partner vaak de doorslaggevende factor echter wordt hier wel degelijk ook aanbesteed met dezelfde modellen.

[Anoniem: 69322]

Aanbesteden kan prima werken, als er bij de klant maar iemand in dienst is genomen die echt kan leiden en de backing heeft van het management. Een onkundige klant kan het nooit intern eens worden en de juiste afwegingen maken (als de wil er al is). En met een onkundige klant kan ook een goede partij er hooghuid tegen extra kosten en moeite er iets van maken.

Daarom zijn zo veel projecten gewoon een exercitie van iets nabouwen of gewoon chaos automatiseren en dan orde verwachten.

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

[bouwfraude]

Voor de aanbestedingswet gingen dit soort projecten ook mis. Wie herinnert zich het debacle rond de Studiefinanciering nog. Of alle bedrijven die met SAP in zee zijn gegaan. Wil dat uiteindelijk een beetje werken dan is er al heel veel geld tegenaan gegooid.

[Bart ®]

Welnee. Zoek eens op de term 'EMVI'. Daarnaast mag er niet in zee worden gegaan met bedrijven die onder de kostprijs inschrijven ('het contract kopen' is niet toegestaan). Lekker makkelijk om de overheid volledig de schuld te geven als je niet weet waar je over praat.

[Bardman01]

Als ict'er die bij diverse overheids-instanties heeft gewerkt kan ik Mikesmit voor een groot deel gelijk geven.
Meerdere projecten meegemaakt die mislukten i.v.m. vriendjes politiek, onkunde, arrogantie enz. En dat kan omdat het andermans geld is. Projecten van miljoenen en dan in één vergadering, oh ging het niet goed?, doe het dan maar opnieuw, letterlijk. Dat was dan ook tegen een interne, bij een externe kijken ze eerst of ze die de schuld kunnen geven. Ideale omgeving om projectmanagement te leren.
Zeer dure apparatuur aanschaffen en dan degene met kennis ontslaan, want hij is niet aardig genoeg, dat word in een vergadering gezegd maar niet op papier. En de apparatuur .. ? Een paar rack-kasten vol met bv HD raid opstellingen. met bijbehorende tapelibary's, Fluke apparatuur (erg leuk, had ik nog nooit gezien van Fluke). TV servers want er moet wel voetbal gekeken worden, maar niemand wist hoe dat werkte. Telefoon centrales enz enz. Als het maar verantwoord op papier staat, of een slachtoffer om te ontslaan. Triest wereldje die overheids ICT, maar wel van onze centen.
Tuurlijk gaat het het een enkele keer goed, als zo'n projectmanager geleerd heeft, en de interne contacten heeft gaat hij nooit meer weg, iets met kip en gouden eieren.

BTW Capgemini, wordt onder ICT 'ers vaak CRAPgemini genoemd ...geen idee wat daar mee bedoeld wordt

[Anoniem: 69322]

Precies, in elke omgeving met veel politiek zie je dit soort problemen. Zeker als er met het geld van anderen gespeeld kan worden en er strikte hiërarchische macht is. Heb het zelf ook waargenomen, afdelingshoofd haantjes die elkaar uit proberen te spelen. Het personeel en de ingehuurde mensen zijn de voetsoldaten die de promotie voor de leider binnen moeten slepen. Niet zozeer door de beste te zijn, maar door de ander te tackelen en met problemen op te zadelen.

Hele nare omgeving bij de overheid, daar zal ieder mens een onmens worden of vertrekken...er heerst pure corruptie.

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

[Bardman01]

Kan het helaas alleen maar met je eens zijn +++

[mustisen]

Die bij wet verplicht zijn om de goedkoopste aannemer te nemen.

Sorry, maar een dergelijk grote onzin heb ik nog nooit in mijn leven gehoord. Dus als ik als leverancier mee doe met een aanbesteding en een bedrag van €0,01 (één eurocent) opnoem (wat een ridicuul laag bedrag is en waarschijnlijk geen enkel ander leverancier onder zit, maar in principe mag), móeten ze bij wet mijn oplossing kiezen?

Projecten bij de overheid lopen uit in tijd en kosten omdat het gros nog steeds volgens de waterval methode uitgevoerd wordt. Vooral bij meerjarige projecten is dit toch echt het domste dat je kunt doen. Een te groot deel van de requirements die aan het begin van het traject zijn opgesteld hebben al lang geen nut meer in de situatie een jaar verder. Maar ze worden wel meegenomen, want:

- niet meenemen betekent dat de leverancier zich niet aan de afspraak houdt.
- wel meenemen, maar tijd is op betekent in de praktijk dat het project wordt verlengd en daardoor meer inkomsten voor de leverancier.

[scsirob]

En toch klopt het dat sommige aanbieders ridicuul lage prijzen aanbieden. Sommige resellers bieden spullen met nul procent of zelfs negatieve marge aan, en gokken er op dat gaande het project de eisen veranderen waardoor ze geld verdienen aan andere goederen/diensten. Ook hebben fabrikanten er een handje van om 'marketing funds' toe te kennen aan resellers die dergelijke opdrachten scoren, waarmee ze weer boven nul komen. Het zou daarom geen slecht idee zijn om standaard de één-na laagste inschrijving te kiezen.

Overigens zijn veel aanbestedingen zo erbarmelijk slecht opgezet dat mijn werkgever er regelmatig voor kiest om niet aan te bieden. Waarna aanbestedende diensten dan soms boos aan de telefoon hangen want ze hebben minimaal drie offertes nodig. Helaas weigeren we om excuus-Truus te spelen.

[Zwollebuds]

Sorry, maar dat sluit nergens op. Er wordt niet op prijs gegund bij complexe aanbestedingen! En ja, soms wordt er strategisch of manipulatief ingeschreven. Maar de wet biedt hier mogelijkheden voor: de abnormaal lage inschrijving regelgeving. Bij twijfel kan een aanbestedende dienst die ondernemer uitsluiten.

Dat dat faalt in de praktijk komt door een gebrek aan kennis en kunde bij inkopers. Sowieso is er in de inkoopwereld een groot gebrek aan mensen en middelen trouwens, maar dat is een andere discussie.

[fantafriday]

Dan is denk ik eerder de definitie van kosten die ze bij de overheid hebben verkeerd.

[jwywy17276]

Kan je hier meer informatie over geven?
(Source/link voor meer informatie)

[oef!]

Dit is niet waar. Ik ben zelf betrokken bij aanbestedingen maar het is niet zo dat de goedkoopste altijd wint.

[Wasrek]

Mwah, er kan fictieve korting op de inschrijving gegeven worden voor bijvoorbeeld het voldoen aan criteria (bijvoorbeeld duurzaamheid). Uiteindelijk is echter toch nog steeds de prijs (na aftrek fictieve kortingen) het enige criterium? Of vergeet ik iets?

[TD-er]

Bij een aanbesteding beschrijf je zelf als klant de eisen waaraan moet worden voldaan en wat de wegingsfactoren zijn.
Helaas moet dat wel heel neutraal opgeschreven worden, dus eisen als "bedrijfsnaam moet met een C beginnen" mag weer niet. Maar je kunt wel opdrachten toeschrijven naar bepaalde uitvoerders door bijvoorbeeld "ervaring met product bladiebla" een hoge score te geven.

Dus als je "betrouwbaarheid" of "Onderhoudbaarheid" opneemt met een redelijk hoge score, kom je zeer waarschijnlijk niet op de laagste prijs uit.

[scsirob]

Neutraal opschrijven klinkt leuk, maar in de praktijk kan men zaken vaak prima sturen. "Er wordt gebruik gemaakt van beheersoftware X. Aangeboden oplossing dient geheel ondersteund te worden door bestaande beheersoftware".

Er is altijd wel een uniek gegeven van een oplossing te vinden wat de mogelijkheden fors inkadert. We komen met regelmaat aanbestedingen tegen waar we als vraag insturen "Staat u open voor oplossing gebaseerd op andere merken dan XYZ", omdat de aanbesteding daar 100% op geschreven is.

[mikesmit]

Zie de reactie van zarhrezz

[knijnsel]

Je hebt de feiten niet op orde. Het is voor een opdrachtgever toegestaan om de weging voor kwaliteit in de ‘meest voordelige aanbieding’ mee te nemen. De inkoop procedure staat in principe los van de kwaliteit van inkoop en product.

[robinhheddes]

Klopt niet helemaal wat je zegt, in een aflevering van zembla werd deze zaak behandeld. Uiteindelijk is het software geschreven door een ander bedrijf wat ca. 10 keer goedkoper was.

https://zembla.bnnvara.nl/nieuws/de-spaghetticode

[Hendrik53]

Nee, NIET laagste prijs. EMVI, de meest voordelige inschrijving is wettelijk verplicht. Als je dat wilt kun je de prijs slechts voor 1% meenemen in de beoordeling van de verhouding tussen prijs en 'kwaliteit'!

Slechts in uitzonderlijke gevallen mag je alleen op prijs toetsen. Daar gelden zeer strenge regels voor en je moet uitgebreid motiveren waarom je niet aan kwalitatieve criteria gaat toetsen.

[xTmPizzaMan]

Dat is kant en klare onzin wat je hier uit spreekt. Top ontwikkelaars zitten ook bij grote detachering partijen. Ik ken er persoonlijk genoeg waarmee ik graag samen zal werken. Die partijen nemen ontwikkelaars aan van elk niveau. Wel zijn die partijen beter in teams te versterken dan projecten uit te voeren.

Ik vind je reactie nogal gefocust op enkel het negatieve. En het voelt alsof je een wrok hebt tegen detacheerders of een van die partijen je iets aan heeft gedaan.

Maar ik ben benieuwd hoe zal jij het dan regelen? Weetjij of jou werkgever alle projecten wel in goede banen leiden?

[Anoniem: 481578]

Ik heb meerdere keren Cap aan het werk gehad en altijd lopen projecten gigantisch uit en veel te duur. Ik ben blij voor de overheid dat ze de zaak gewonnen hebben. Als we in het verleden niet zulke incapabele managers hadden dan hadden wij dat ook moeten doen. Ik vind het een ronduit slechte partij en zal deze nooit en te nimmer aanbevelen.

[Nap]

Als projecten uitlopen is dat niet alleen nadelig voor de partij waar het werk zit, dat is voor het bedrijf zelf ook enorm nadelig. Maar het ligt er aan hoe je een project afspreekt hoe nadelig het is. Er zit aan beide kanten onkunde, de vragende partij weet niet hoe ze moeten aanbesteden (oa requirements), de leverende partij probeert aan optimalisatie te doen, dat betekent ook jonge (meer onervaren) mensen op het project zetten om ze op te leiden, omdat je niet kritische resources altijd op een project hebt omdat er te weinig IT'ers heb in NL

[deadlock2k]

Het is in dit geval geen detachering.

Onze organisatie heeft met een andere grote automatiseerder een soortgelijk iets meegemaakt maar dan aan de consultancykant. De directies wordt een mooie vette kluif voorgehouden en ondertussen gaat de meter lopen. 6 miljoen euro verder.... Nou is dat slechts 2% van de bekostiging en we hebben we degelijk een ontzettende kostenbesparing van een dik half miljoen per jaar gerealiseerd plus een veel hogere betrouwbaarheid van de netwerken van sommige scholen, maar het had ook voor een miljoen met alleen de interne mensen gekund en dan was de besparing na een jaar of twee gaan lopen in plaats van nu zo'n beetje nooit. En met elke willekeurige andere grote consultancytent zou het exact zo gegaan zijn. Er is een structureel probleem op het koppelvlak (semi-)overheid en dit soort bedrijven. Geen idee of dat in de vrije markt onderling ook zo gaat trouwens.

[IplugNplay]

Ze schrijven zich niet goedkoop in, ze zorgen dat ze indirect contact hebben met de opdrachtgever. Ze weten precies de gevraagde eisen en langs welke meetlat elke bieder gelegd wordt.
Dan maken ze een voorstel precies zo dat alle eisen gehaald worden, en dan hoeven ze niet de goedkoopste te zijn maar komen ze wel als meest geschikt uit de bus voor het project te realiseren.

Dat het vervolgens grandioos fout gaat komt natuurlijk doordat de eisen nooit allesomvattend kunnen zijn en dus vereisen dat een bedrijf eigen inzet toont en het welzijn van de klant ook in het oog houdt. De overheid zal niet omvallen en je maakt gewoon kans op de volgende bid bij ze ondanks dat je de vorige opdracht compleet verkloot. Ze moeten je wel inhuren.

[brinkdinges]

Linkje naar die uitzending van Zembla over SVB en Capgemini, een aanrader:

https://zembla.bnnvara.nl/nieuws/de-spaghetticode

[NSG]

(Ex)medewekers van de SVB spreken in deze uitzending over een creatieve boekhouding en dat er in werkelijkheid meer dan 100miljoen is betaald aan Capgemini. Iemand een idee of hier nog iets officieels over bekend is? Want als dat echt zo is, dan is het terug moeten betalen van 21 miljoen, natuurlijk helemaal niks.

[TheekAzzaBreek]

Nee, dat zeggen ze niet: de totale kosten voor SVB waren waarschijnlijk wel zo hoog, maar dat ging niet allemaal naar CAP: er werd ook geld uitgegeven aan software, hardware, facilities en eigen personeel.

[Cybertek]

En tientallen miljoenen euro's verdwenen van de belasting.

Iemand zit hard te lachen, denk ik.

[Crazio]

Daarvoor hebben ze toch die "volwassen" projectleiders die u van A to Z ontzorgen zodat u bezig kan zijn met de dingen waar u echt verstand heeft, namelijk uw core-business?

Bij het bedrijf waar ik werk hebben we SAP geïmplementeerd en tijdens het project konden de "volwassen" projectleiders nog zo hun best doen om ons van A to Z te ontzorgen, de business neemt uiteindelijk beslissingen en nemen heus niet altijd, lees in sommige gevallen vaker niet dan wel, de adviezen aan van dergelijke projectleiders.

Capgemini zal bij SVB ongetwijfeld fouten hebben gemaakt, maar ik ben het met Martinspire eens dat daar nooit 100% de blaam neer te leggen is.

[Sandor_Clegane]

Tja, dan nog. Dan kun je zeggen: "We snappen wat jullie willen en dat heeft deze gevolgen etc. etc.".
Het opleveren van een niet werkend systeem is nog wel wat stappen verwijderd hiervan lijkt me.

Op een gegeven moment moet je dan ook "kerel zijn" en zeggen van, als jullie deze adviezen niet opvolgen kunnen wij het project niet opleveren. Of, dat kan wel maar dat kost zoveel extra.

Nogmaals, een systeem opleveren met ontbrekende functies waarvan beweert wordt dat ze er wel in zitten, een systeem opleveren dat bij de eerste de beste productie dag op zijn gat ligt is mijlenver verwijderd van een aantal dingen niet juist doen.

[Anoniem: 84766]

Ik vraag me af waar het met software ontwikkeling zo mis is gegaan.

Bij Cap. Willekeurige HBO opleiding en twee handen? Snelle cursus code kloppen en hup naar een overheidsproject voor €120/uur. Geef de slacker een lelijke laptop, telefoon en een Seat leasebak en iedereen is blij. Behalve dan de belastingbetaler uiteindelijk.

[joelharkes]

Eerlijk gezegd zo voelde het wel toen ik net afgestudeerd was en meerdere sollicitaties heb gedaan.

Blij dat ik daar uiteindelijk niet voor gekozen heb.

[supersnathan94]

Same here. Ik zoek een bedrijf met hart voor het werk en geen CV schuivers.

[Atlantis1995]

De overheid komt niet verder dan 75 per uur. Geef er de naam architect aan en het wordt wat hoger. Maar in de praktijk wordt er dan iets gedaan/gepoogd met outsourcing.

[Bardman01]

Kan ik helaas beamen, maar zo gaat bij veel bedrijven want dat is goedkoper, Price Waterhouse Cooper laat zijn PID vaak door startende HBO'r doen een senior zegt dankjewel gaat met de eer strijken. Uiteraard gecontroleerd door hem want hij moet de HBO'er natuurlijk wel evalueren:-)
En je dan maar afvragen waarom ze altijd zoveel mensen vragen. Niet mee doen? geen job.

[IplugNplay]

Helaas, overheidsprojecten worden zo veel mogelijk richting de India tak geschoven.

[CurtPoindexter]

Overdrijven is ook een vak zeg. Moet de eerste overheidspartij nog tegenkomen die 120,- over heeft voor een hbo starter.

[andydewit]

Heb zojuist even die docu van Zembla gekeken en ik sta met een mond vol tanden. Is op z'n minst belachelijk te noemen.

[Sandor_Clegane]

Ja is echt een stukje. Ook mooi die man die zijn idee door CAP zou laten implementeren op aanraden van FC Barcelona. Op het eind is alles weg.

[hassanjassan]

Ik ben al sinds 1997 afgestudeerd als informaticus en nog altijd, voor zelfs de kleinste klusjes, volg ik de punten, die ik toen geleerd had. Eentje ervan is, dat de klant deskundige en inhoudelijke medewerking moet leveren aan het ontwikkelen van het systeem. Het kan nl. niet zo zijn dat een klant je inhuurt en dan wegloopt en zegt, zorg maar dat het afkomt. Nou schaal dat eens op naar het formaat ministerie en dan zie je wel dat het mis kan gaan lopen. Geen medewerking, geen inhoudelijke kennis, geen tijd, geen haast, geen interesse, etc....en ja Cap is ook geen dommerd, dat is een urenfabriek, dus die leeft van uurtje-factuurtje en die schrijft wel. Cap krijgt daarom ook niet de hele som voor z'n kiezen, maar Minsiterie moet ook hand in eigen boezem steken. Het is gewoon triest dat men nog steeds niet begrijpen dat een groot ICT project nogal een complex ding is, niet veel simpeler dan een nieuwe metrolijn in amsterdam ofde nieuwe rotterdamsebaan bij Den haag.

[Belenar]

Je hebt gelijk over de attitude van CAP. Ook in hun aanwervingsprocedure komt de arrogantie naar boven naar nieuwe werknemers toe. Ze doen uitspraken waaruit zou moeten blijken dat enkel CAP consultants goed kunnen zijn, dat zij 'de grote jongens' zijn, dat als je iets wilt betekenen je voor hun moet werken, enz.

Ik kreeg er de kriebels van. Ik vroeg me ook af wat voor soort mensen er geprikkeld wordt door dat soort uitspraken. Volgens mij enkel mensen met een veel te hoge dunk van zichzelf, of mensen die onzeker zijn.

No offense voor CAP medewerkers die wel een goeie job doen, want die zijn er ongetwijfeld ook, maar op basis van mijn ervaringen heb ik er een heel arrogant beeld van.

[Sandor_Clegane]

Daar zit jammer genoeg ook wel een kern van waarheid in. Ze hebben nu eenmaal de naam mee, zelfde als een KPMG en die anderen van de grote vijf(?) als ik me niet vergis.

Staat ook wel goed op je CV, dus ja het is een beetje wat je zelf wilt lijkt me. Ik weet niet of ik daar zou kunnen werken.

[Martinspire]

Welke uitzending van Zembla bedoel je? Is ie nog online?

[Berlinetta]

Ik gok deze:
https://www.npo.nl/zembla/02-09-2015/VARA_101375763

[Hellboy!]

Al deze bedrijven willen de aanbesteding winnen en deze dan zoveel mogelijk uitmelken, extra functionaliteit bedenken tegen hoge uurtarieven en meer inhuur. Probleem is aanbesteding gaat om de laagste prijs niet op kwaliteit.

[Anoniem: 58485]

Inderdaad. Dit is echt niet het eerste 'incidentje'. De overheid laat zich gewoon op dat vlak niet voldoende adviseren en put uit iedere keer dezelfde groep van software-leveranciers.

En hoe komt het toch dat dingen veel duurder worden dan dat ze zijn begroot? Hoe komt het dat bijv Translink weet dat het systeem niet optimaal werkt, fraudeloos is maar zoiets toch wordt doorgezet? Waarom wordt er geen goede audit van te voren gedaan VOORDAT men zo'n product tot live werking zet?

Omdat het de overheid is en aan de overheid kan voldoende verdiend worden.

[Anoniem: 636203]

Ik hoor die klacht vaak, maar ik ben er niet van overtuigt dat als je een blanco cheque schrijft dat het dan (veel) beter gaat worden. Ik denk dat het dan ietsje beter is, maar zal zeker niet tot een perfect werkend systeem leiden. Je kan heel moeilijk hard maken dat als men twee of drie keer zoveel betaald dat er dan ook een beter software systeem uit komt. Misschien steekt CapGemini dan gewoon nog meer winst in z'n zak en wordt deze winst in Frankrijk lekker gebruikt om de mensen daar met 62 met pensioen te laten gaan terwijl wij hier tot onze 67e mogen doorploeteren.

Als overheid ben je verplicht om efficiënt met belastinggeld om te gaan en dus moet het aan de goedkoopste aanbieder gegund worden. De overheid moet de aanbesteding wel zo dichttimmeren dat de opdrachtnemer niet later meer kan vragen omdat iedereen dan voor een belachelijk laag bedrag inschrijft omdat ze toch wel weten dat ze het later weer terughalen met extra werk.

[BadRespawn]

Check die docu van Zembla, je staat echt met je oren te klapperen.

M'n oren klapperen zowel over CAP als SVB.

[Sandor_Clegane]

Yep, en dan moet je nagaan dat jij zit te wachten op 800 Euro in de maand van de SVB voor je uitkering en dat komt dan te laat omdat er dit speelt. Komt nog eens bij dat ze voor die 800 Euro jouw hele doopceel lichten om er maar zeker van te zijn dat je toch echt niet teveel krijgt.

BTW even iets heel anders: Wil je eens zien waar dit soort instanties en regeltjes toe leiden moet je "I Daniel Blake" eens kijken.

Linkje: https://www.youtube.com/watch?v=2Dt-VYlVchc

[Reactie gewijzigd door Sandor_Clegane op 22 juli 2024 13:22]

[Earthfinder]

Ik vraag me af waar het met software ontwikkeling zo mis is gegaan.

Omdat er maar heel weinig mensen zijn die applicatieontwikkeling echt doorgronden.
De meeste Projectleiders, Informatie Analisten, Funtioneel Ontwerpers en programmeurs hebben zelf nood administratief werk verricht. Ze zijn nooit onder aan de ladder begonnen als gebruiker van een applicatie. Hierdoor is het bijna onmogelijk om te beseffen hoe applicaties gebruikt worden, wat handig is en wat niet, wat frustreert bij het gebruik van een applicatie.

ICT moet ondersteunend zijn aan de business. Als je de werkelijke business dan niet goed kent, dan kun je in theorie fantastische functionaliteit ontwikkelen, maar dan blijkt de praktijk er niet zo heel gebaat bij te zijn.

Binnen organisaties is een enorme "verzuiling" de één is "gebruiker", de ander "programmeur" weer een ander is "systeembeheerder", etc. maar een aantal mensen met een zeer gedetailleerd generiek inzicht en kennis van de totale business zijn extreem zeldzaam. Of wellicht zijn ze er wel maar laten ze zich wat minder makkelijk horen omdat ze tijd nodig hebben om over zaken na te denken.

[Uruk-Hai]

https://zembla.bnnvara.nl/nieuws/de-spaghetticode
Vanaf 34:45 tot 35:05: "Het niet werkende computersysteem kost uiteindelijk minstens 270 miljoen euro. Vervolgens bouwt het ICT bedrijfje van Veldwijk voor nog geen 4 miljoen euro een systeem dat het wel doet." - "Dat heeft ons 5 maanden tijd gekost met 8 mensen."

Dat lijkt mij wel genoeg zeggen over de schuldvraag.

[Tjeerd]

Ik wil hier toch op inhaken, ik werk zelf ook bij een relatief klein bedrijfje (~25 man/vrouw) met een afdeling van vier backend-ontwikkelaars en momenteel 'maar' twee frontend-ontwikkelaars. Om ons heen een paar mensen die van de markt afweten/business analisten en helpdesk e.d. Als ik ziet wat we met zo'n klein team weten op te zetten en koppelingen we weten te leggen met verschillende (overheids)instanties met ons eigen back-/frontofficeplatform dan vraag ik me af hoe het zo uit te klauwen kan lopen bij grote bedrijven. We zijn zelf de 'softwarearchitect' en doen als softwareontwikkelaars het uitrollen, databaseonderhoud/tuning, backups, serverproblemen zelf oplossen enzovoorts. Allemaal onderdelen die bij de grote bedrijven door allemaal specialisten en aparte afdelingen worden gedaan. Wat op zich trouwens niet verkeerd is, want je kunt niet alle ballen tegelijk in de lucht houden. Maar dat maakt het uiteindelijk ook allemaal duurder en vaak stroperiger met veel langere doorlooptijden. En mensen gaan meer op elkaar zitten wachten tot de een weer iets heeft opgeleverd, zodat de ander weer verder kan.

Ten opzichte van grote partijen die in dezelfde markt als wij zitten zien we vaak dat ons bedrijf als eerste de koppelingen (webservices bijv.) klaar heeft (getest, goedgekeurd en goed werkend). Andere concurrerende partijen volgen meestal (veel) later. Simpelweg omdat grotere organisaties een soort mammoettankers zijn en wij een soort speedboot.

De bedragen die wij telkens horen bij overheidsprojecten zijn voor ons astronomisch en wij hebben in verhouding echt maar een klein budget. Soms zijn we wel eens nieuwsgierig wát er dan voor zoveel geld is neergezet en of wij zoiets voor hooguit 1% van de prijs ook zouden kunnen bouwen.

[Sandor_Clegane]

Dit heeft er mee te maken dat het zelf doen van dingen, in Nederland lijkt het, zo langzamerhand een vies woord aan het worden is.

[bouwfraude]

Dat is al een paar decennia aan de gang.

[Anoniem: 343906]

Kleinere bedrijven met goede teams zijn inderdaad heel productief. Maar ook kwetsbaar. Goed personeel vinden is nog verduveld lastig. En één iemand vervangen vanwege ziekte is nog wel te doen maar wanneer het meer dan één betreft kan het zo maar nijpend worden.

[SPT]

Ik heb wel een vermoeden. Het valt me telkens op bij personeelsadvertenties van bedrijven als Capgemini dat technische kennis of programmeerkennis geen vereiste is, want 'die doe je vanzelf wel op', en dat men steevast allerlei zij-instromers aantrekt. Ik denk dat die bedrijven vol zitten met mensen die bar weinig capaciteiten hebben, behalve de capaciteit om de hele dag te vergaderen.

[Anoniem: 55401]

Ik ben zelf software engineer. Ik vraag we af hoe groot de omvang van het project is als het in 5 maanden definitief af is.

Een maand heeft +/- 22 werkdagen dat zijn: 176 uren
8 * 176 * 5 = 7040 uren voor 5 maanden met 8 personen.

dus: 4.000.000 / 7040 = 568,- p/u

Als het 2jr was geweest dan geloof ik het wel.
8 * 176 * 24 = 33.792 (en dan heb ik vrije dagen, feestdagen, ziektedagen enz niet eens eraf gehaald)

dus: 4.000.000 / 33.792 = 118,- p/u dit is nog steeds te duur, maar goed.

Dat het veel en veel goedkoper kan is zeker, maar 5 maanden is zo voorbij. Een beetje oude code analyseren en huidige situatie schetsen, medewerkers interviewen en nieuwe situatie schetsen, plannen enz ben je al gauw 2 maanden kwijt. Ontwikkelen, testen, evalueren, aanpassen enz ga je echt niet in 3 maanden redden.

[Reactie gewijzigd door Anoniem: 55401 op 22 juli 2024 13:22]

[Ahrnuld]

Het idee dat een ervaren software developer een factor 30 efficiënter kan zijn dan een combi van sales, management & een beginnende programmeur uit India lijkt me eigenlijk niet eens zo heel gek. Ik ben het met je eens dat 5 maanden wel erg kort is, maar als je met een team van goede ervaren mensen zit kan je enorm veel werk verzetten.

Maar het sommetje van 5 maanden, 8 man en 4 miljoen kwam op mij ook wel vreemd over

[kaas-schaaf]

Daarbij komen ook servicekosten (bij kleine partijen vaak in de beginprijs voor een bepaalde tijd), doorberekening van ondersteunend personeel, leuke winstmarge (zal in dit geval best prima zijn) en kosten voor apperatuur en onderhoud daarvan.

De prijs/tijd vind ik niet heel raar.

[killer_mac]

Dat vind ik wel heel knap, want uit mijn ervaring, duurt het vaak meer dan 3 maanden (waarin meer dan 10 sessies)
om enigzins een antwoord te krijgen op de de vragen,

Waarom
Wat is het doel
Wat zijn de belangrijkste functies voor het systeem
Welke functies zijn nog meer nodig.
Met welke systemen dienen er interfaces te zijn.

Laat staan dat de systemen waar een interface mee moet komen mensen beschikbaar hebben om hier over in gesprek te gaan en alles uitgewerkt en wel op tafel hebben liggen binnen 6 maanden..

maar goed, ik zou zeggen ik laat me graag verrassen..

[Taint_NLD]

Is dat wel zo?

Dus je wilt zeggen dat een bedrijf wat begint nadat een product is opgeleverd, alle gebreken boven tafel zijn gekomen en alle eisen duidelijk zijn gemaakt, hetzelfde traject doorloopt als een bedrijf wat begint met:

• Onduidelijke/ontbrekende requirements
• de bekende tegenwerkendheid van de overheid
• 0 historie en documentatie

Ik zeg niet dat er geen fouten worden gemaakt, maar ik heb wel in mijn eigen carriere gemerkt dat klanten er soms rare beslissen op nahouden die door detacheerders maar geslikt dienen te worden. En dat de basis principes van een goed project vaak te pas en te onpas uit het raam gegooid worden om maar maar de detacheerder te wijzen en te zeggen jullie probleem.

[White Feather]

Ga nu niet ineens of ander algemeen verhaal opdissen als een arbitragecommissie gewoon een uitspraak heeft gedaan:

Een arbitragecommissie heeft vrijdag bepaald dat het bedrijf contractbreuk heeft gepleegd en een wanprestatie heeft geleverd, melden goed ingevoerde bronnen aan NRC.

Het is algemeen bekend dat er moet worden ingeschreven op dit soort grote projecten.
De klant zegt wat hij wil en je weet als aannemer dan al dat de klant nooit een werkend systeem gaat krijgen omdat het technisch niet klopt. Je schrijft goedkoop in en daarna draai je de klant een poot uit met meerwerk.
Uit het NRC-stuk:

Een van de belangrijkste oorzaken is dat overheidsinstellingen vaak slechte opdrachtgevers zijn, en leveranciers daar gebruik van maken.

Hoe het nu in de praktijk werkt is echt belachelijk. Er zijn genoeg ICT-bedrijven waar je problemen die je als medewerker ziet niet aan de klant mag tippen (waarmee veel werk en kosten bespaard kunnen worden), maar alleen aan je werkgever. Die kan dat dan weer gebruiken voor een stuk meerwerk.

Of een order neerleggen om een huis te bouwen en van binnen volledig wit schilderen. Uiteindelijk is het huis gebouwd en wordt de opdracht gewijzigd naar: alleen de keuken, maar dan in het geel. 1e waar de uitvoerder aan denkt: meerwerk!

Aan de andere kant zijn de uitbestedingsregels soms echt belachelijk. Hoe goed een bedrijf eerder zijn projecten heeft afgeleverd kan nauwelijks meegenomen worden in de nieuwe aanbesteding.

Ik mag hopen dat dit nu een voorbeeldzaak wordt van een claim die je voor je kiezen kan krijgen als je de boel bewust aan het flessen bent.

[Zarhrezz]

Zoals ik hierboven in een post al aangeeft zit er één nuance in het meerwerk-dat-je-van-tevoren-al-aan-ziet-komen verhaal; als je dit netjes meldt tijdens de aanbesteding staat hier geen enkele vergoeding tegenover. Het is een 'bedankt voor de informatie, die gaan we gebruiken om de opdracht aan te passen' waarna je als detacheerder eigenlijk een hoger bod moet doen om de kosten (van het documenteren van de gaten in de requirements en het delen daarvan met de opdrachtgever) ook te dekken, maar dan verlies je de aanbesteding op prijs. Stank voor dank dus.

Ja, het gebeurt, maar dat is volkomen logisch gezien het systeem dat gehanteerd moet worden wegens de aanbestedingsregels.

Dit compleet brakke systeem moet al jaren en jaren gebruikt worden voor overheidsaanbestedingen. Dit soort berichten zien we dus al jaren en jaren. Totdat die regels overboord gaan, gaat dit niet verbeteren. Dat er nu een keertje een claim voor ongeveer de helft van het bedrag dat compleet weggegooid belastinggeld is komt, maakt het wat minder weggegooid geld, maar nog steeds 21M belastinggeld het putje in.

[Aftansert]

Als je zo graag 'advocaat van de duivel' wil gaan zitten spelen, kan je dan eerst even wat meer huiswerk doen voordat je zonder enige kennis van zaken een theorietje de comments in plempt, waar iedereen dan weer z'n plasje overheen kan doen?

Zembla (die overigens niet altijd te vertrouwen is) heeft uitputtende onderzoeksjournalistiek bedreven en de direct betrokkenen uitgebreid geinterviewd. Daaruit blijkt dat Capgemini willens en wetens het project heeft gedoemd tot mislukken, uit puur winstbejag. Het gebrek aan voorgang en de hoeveelheid fouten in de software heeft ze vervolgens verborgen voor de SVB. In dit geval van een enorm gebrek aan professionele ethiek is het simpelweg niet meer relevant of de SVB wel of niet een competente organisatie is. Capgemini is hier in ieder geval de schuldige.

Bekijk bijvoorbeeld vanaf 10:57. Capgemini heeft de 'India-route' die hier genoemd wordt pas ingezet nádat de aanbesteding binnen was.

[Reactie gewijzigd door Aftansert op 22 juli 2024 13:22]

[CMD-Snake]

Even de advocaat van de duivel spelen: Schuif niet de hele schuld naar Capgemini. Vergeet niet hoe slecht sommige departementen binnen de overheid gerund worden (laatste faal in het nieuws was bv Defensie) en hoe lastig het is om al een beeld te krijgen waar het allemaal op aan moet sluiten. Managementbeslissingen door mensen die vervolgens nergens verstand van hebben zorgt voor nog meer vertraging. Als ik zie wat voor puinhoop het bij de Belastingdienst is, dan kan ik me niet voorstellen dat het bij de SVB zo soepel loopt.

[...]

Als ik zaken lees als "bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar." dan kan ik niet anders concluderen dan dat er ook blaam bij SVB ligt. Dit klinkt namelijk als iets waar requirements en eisen constant veranderen, waardoor veel tijd en werk verloren gaat, plus het er allemaal niet beter op wordt. En hoewel de boete vast terecht is, is het jammer dat men Capgemini vervolgens als enige schuldige op het hakblok legt. Maar goed, met de huidige overheid weten we al dat verantwoording afleggen erg moeilijk blijkt te zijn en het bijna een sport is om het in de schoenen van anderen te schuiven.

Grote ICT reuzen als Capgemini hebben al meerdere mislukkingen op hun geweten. Vooral bij de overheid horen we ervan omdat daar openheid over gegeven (moet) worden. Een bedrijf kan ervoor kiezen om zo'n miskleun te verbergen. Er was rond de tijd dat speelde, samen met de Equihold zaak, een interessant opinieartikel waar beschreven werd hoe het lucratiever was voor bedrijven als Cap om een project uit te rekken en te laten mislukken dan om te leveren wat er gevraagd werd.

In het geval van de SVB zat er duidelijk een luchtje aan de zaak. Twee hoge leidinggevende (een intern, een ingehuurd) aan de kant van SVB om dit project te leiden hadden samen een BV via welk een van de twee ingehuurd werd door Capgemini. Die persoon had ook nog een clausule in zijn contract dat als betalingen snel gedaan werden door het SVB hij een bonus kreeg. Samen drukten deze heren ook alle kritiek binnen de SVB de kop in. Dat klinkt mij als een ernstig integriteitsprobleem en belangenverstrengeling.

Het is een goede zaak dat de ICT reuzen die normaal zonder kleerscheuren wegkomen hier nu eens bestraft worden.

[Taint_NLD]

In het geval van de SVB zat er duidelijk een luchtje aan de zaak. Twee hoge leidinggevende (een intern, een ingehuurd) aan de kant van SVB om dit project te leiden hadden samen een BV via welk een van de twee ingehuurd werd door Capgemini. Die persoon had ook nog een clausule in zijn contract dat als betalingen snel gedaan werden door het SVB hij een bonus kreeg. Samen drukten deze heren ook alle kritiek binnen de SVB de kop in. Dat klinkt mij als een ernstig integriteitsprobleem en belangenverstrengeling.

Hier vergeet je te vermelden dat de verplichting om deze 2 heren aan te nemen vanuit de SVB kwam als ik me niet vergis.

[CMD-Snake]

Hier vergeet je te vermelden dat de verplichting om deze 2 heren aan te nemen vanuit de SVB kwam als ik me niet vergis.

Een van de twee was al in dienst bij de SVB als hoge ambtenaar. De programmadirecteur die voor de SVB het toezicht moest houden op Capgemini werd ingehuurd via Capgemini. De programmadirecteur had echter een bedrijfje samen met eerder genoemde hoge ambtenaar. Cap betaalde uit aan dat bedrijfje. De programmadirecteur had ook een clausule in zijn contract dat als hij de facturen van Cap binnen een bepaalde periode betaalde hij een bonus ontving.

Dat de programmadirecteur via Cap ingehuurd wordt, klinkt als een slager die zijn eigen vlees keurt. De bonus bij snelle betaling zal er nog meer voor zorgen dat er weinig behoefte is om facturen nader te bekijken. Tel daar nog bij op dat de hoge ambtenaar die toezicht moest houden op de programmadirecteur samen met hem een bedrijf heeft dat dus verdiend aan Cap en je hebt wel een heel dubieuze situatie.

[andreetje]

"Als ik zaken lees als "bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar." dan kan ik niet anders concluderen dan dat er ook blaam bij SVB ligt."

Vreemde conclusie van jou. Immers, deze zaken zijn typisch verantwoordelijkheid van een ontwikkelaar. Die hoort op zijn minst een transparant, stabiel en goed onderhoudbaar systeem op te leveren. Dat is professioneel ontwikkelen. En dat staat nog los van het bouwen van de gewenste functionaliteit.

"Dit klinkt namelijk als iets waar requirements en eisen constant veranderen, waardoor veel tijd en werk verloren gaat, plus het er allemaal niet beter op wordt. "

Welkom in 2017! De tijd ligt voorgoed achter ons dat in jaar 1 de architectuur wordt vastgesteld, in jaar 2 en 3 het ontwerp, en dat CapGemini het gewenste product in jaar 4 en 5 mag bouwen.

Anno 2017 wordt met scrum ontwikkeld, en zijn veranderende requirements geen uitzondering maar regel.

[Martinspire]

De vraag is hoe je onbetrouwbare code krijgt. Dat is lang niet alleen onervaren programmeurs. Zeker niet bij een project als deze. Er is heus wel een controle vanuit Cap op het opgeleverde werk. Het wordt juist slechter naarmate de zaken veranderen gedurende het project. Ik heb zelf ook eens zaken opgeleverd waarvan achteraf te zeggen was dat het beter had gegaan als ik op voorhand een aantal zaken beter inzichtelijk had gehad.

En ik heb het niet over het veranderen van slechts een paar requirements. Het lijkt er hierop alsof meer dan de helft op den duur is verschoven en dat is ook gewoon niet normaal. Of dat aan gebrekkig voorwerk ligt, weet ik niet, maar je kunt niet alles op voorhand zien.

En ja, je doet bij dergelijke grote overheidsprojecten wel degelijk die zaken in meerdere jaren omdat de materie simpelweg complex is.

Scrum/Agile is prima, maar is geen zekerheid dat zaken goed worden uitgelegd. Als je basislaag al 10 keer veranderd, dan krijg je dat op den duur gewoon niet meer goed. En dat lijkt hier toch wel zeker het geval te zijn. Volgens mij onderschat jij enorm hoe anders zaken werken als je met de overheid te maken hebt en hoe veel bepaalde zaken kunnen veranderen. Ja Agile zorgt dat je met veranderingen om kunt gaan, maar ook diens bereik is maar beperkt. Bovendien heeft dat alleen zin als je met iets werkt waar je ook kleine iteraties op kunt leveren en dat lijkt met dit niet het geval. Het moest het huidige systeem in 1 keer vervangen. Dat is imo al een foute situatie geweest.

[andreetje]

Eerlijkheidshalve moet ik zeggen dat ik ook wel eens getwijfeld hebt of je halverwege nog grote veranderingen kunt doorvoeren.

Inmiddels weet ik dat scrum werkt. Gebruikers zien wat ze krijgen en kunnen bijsturen. Het bereik van bijsturen is groot, veel groter dan ik verwachtte.

En ja, ik heb ook met grote projecten bij de overheid te maken.

Wanneer kun je volgens jou geen kleine iteraties opleveren?

[Martinspire]

Wanneer je een redelijk eenzijdig product aanbiedt.

Ik heb zelf gewerkt aan een systeem voor het aanvragen van je pensioenaanvraag. Uiteindelijk niet live gegaan vanwege backend problemen, maar wij waren dus de front-end aan het maken. Hierbij had je enerzijds een weergave van de keuzes die je moest maken, met een visuele weergave daarnaast. Nou kun je wel dingen in delen opsplitsen, maar uiteindelijk moet het geheel als 1 product live. Je kunt niet zeggen dat je het online zet met alleen de visualisatie (want die gaat over de berekening). En je kunt de front-end niet live zetten zonder de berekening op echte bedragen te zetten. Groot probleem was dan ook om 50+ verschillende fondsen onder 1 site te krijgen (waarvan een aantal dus over waren genomen, maar mensen hadden er wel geld mee gespaard). Ook daar kun je een paar fondsen online gooien, maar je berekening moet wel rekening houden met het feit dat er meer fondsen bij komen en flexibeler zijn.

Uiteindelijk heeft het volgens mij een jaar of 4 geduurd aan ontwikkeling, met een jaar aan front-end. En een maand voordat de oplevering afgerond moest worden, was de stekker eruit getrokken.

Ik verwacht dat een systeem als deze met soortgelijke situaties te maken heeft en je eigenlijk niet live kunt zonder de hele keten te doen. Tuurlijk kun je de front-end makkelijk opleveren met scrum, maar daar ligt het probleem niet. Dat zijn de systemen erachter. Bedenk dat iedereen op een ander moment zonder salaris komt te zitten en om andere redenen. Dat alleen al zorgt voor een vrij complexe berekening achter hetgeen jij te zien krijgt als gebruiker.

De iteraties die je dan met scrum oplevert zijn leuk voor de bühne, maar zeggen uiteindelijk vrij weinig. En als er dan ook nog eens een hoop commentaar komt en veel zaken overhoop worden gegooid, wordt het er allemaal niet beter op.

[Origin64]

De SVB zelf is ook schuldig, daarom betaalt cap maar de helft van de projectkosten ipv alles.

[FreezeXJ]

SVB heeft 0 verstand van requirements, of van complexiteit bij dit soort dingen. Dat pleit ze niet vrij (verre van), maar als aannemer van dit soort klussen weet je dat. Je zult zelf probleempunten moeten opsporen, zelf met oplossingen moeten komen, en zelf moeten bedenken hoeveel impact dat heeft. De overheid tekent keurig bij het kruisje en verder weten ze van niks.

Waarom snapt de overheid niks? Omdat a. iedereen met wat capaciteiten inmiddels het politieke geneuzel spuugzat is en weg is, en b. omdat anders die personen wel wegbezuinigd zijn. Vergeet niet dat mensen vast aannemen levensgevaarlijk is, en dat je ze dan misschien wel heel lang heel veel geld moet betalen.

[oltk]

Dit is een te simpele voorstelling van zaken. Ik ben zelf gedelegeerd opdrachtgever namens een (rijks)overheid. En ik merk hoe moeilijk het is om te specificeren wat je wil. Je wil "moderne" software, het moet toekomstbestendig zijn (en dus niet nu al achterhaald), gebruikersvriendelijk. Voldoen aan allerlei eisen die intern worden gesteld omdat bepaalde werkprocessen dat nou eenmaal vereisen. En hoe groter de complexiteit bij een overheid is, hoe moeilijker het is om dit te specificeren.

Dan zeg je als overheid: die kennis hebben we niet. Niet de kennis om het precies te specificeren en al helemaal niet om het geheel te ontwerpen. De taak van de overheidsorganisatie is dan om alle processen intern goed te organiseren en iemand in te huren. Het liefst een bedrijf dat specialisten in dienst heeft op deelgebieden. En je zorgt er dan voor dat de opdrachtnemer alle informatie krijgt die nodig is. Tegelijk heeft de opdrachtnemer de plicht (en daar huur je 'm ook voor in) om de architectuur zo uit te werken dat het allemaal klopt en aan de bel te trekken als er tegenwerking is of verwarring.

En juist op de laatste punt moet je scherp zijn. Want soms gaat het mis omdat elke regionale club zo zijn eigen ideeën heeft en daar helemaal niet flexibel in is (zie de politie, wat gillend mis ging). Maar ook dan zou een opdrachtnemer zijn rug recht moeten houden en zeggen: luister, jullie willen teveel, te complex, en te warrig. Wij gaan pas factureren en bouwen als we zeker weten dat we het eens zijn over wat we bouwen.

Of het klopt dat een CAP willens en wetens doet alsof ze gek zijn en alles neerleggen bij de klant weet ik niet. Maar vanuit mijn verhaal redenerend is dit een prima uitspraak. De opdrachtnemer heeft nu maar mee te denken met een klant. Tegelijk mag (m.i.) geld niet het enige criterium zijn voor opdrachtverlening. Je moet ook naar de kwaliteit kijken. Hier kan nog wel iets worden verbeterd.

[walteij]

En hoe voorkom je als overheid nu dat die externe medewerker die je inhuurt (vaak van een bedrijf als CAP afkomstig) om de specificatie en de processen op papier te zetten deze niet precies zo aanpast/definieert zodat zijn werkgever het beste aan deze specs en processen kan voldoen?

Het probleem bij CAP en overheid is onder meer dat de programmeurs en coders in India zitten en niets begrijpen van NL wetgeving. Er zit dus een flinke vertaalslag tussen de NL wet en de specificities en processen, de vertaling naar het Engels, gevolgd door de Indische interpretative hiervan.

En het verschrikkelijke is dus ook dat CAP dit weet en hier zelf ook dankbaar gebruik van maakt. De specificities worden in het Engels worden opgeschreven (want grote projecten vallen onder een Europese aanbesteding), maar dan wel zodat ze op meerdere manieren te interpreteren zijn.
De NL CAP Consultant gaat dan in gesprek, interpreteert het op zijn manier en zet de Indiers aan het werk.
Resultaat: iets dat niet volgens de NL wensen werkt, maar wel volgens de Engelse specificities klopt. Alle aanpassingen zijn dus nu meerwerk en dus uurtje factuurtje.
Als dit bij CAP slechts af en toe voorkomt, zou je dit nog als toevallig kunnen bestempelen, maar bij veel overheidsprojecten is dit gebeurd en ik heb het ook al in het gewone zakenleven meegemaakt dat er werd gekozen voor CAP, want de opleveringskosten waren zo laag. Uiteindelijk zijn dan de werkelijke kosten een factor 4 hoger dan de opleveringskosten in de eerste paar jaar.

[Martinspire]

Maar als iemand op een hoge positie denkt te weten hoe het moet en eisen stelt waar niet aan kan worden voldaan, dan kun je zelf plannen wat je wilt. Bovendien moet je op een gegeven moment ook dingen gaan schatten en heb je niet eindeloos de tijd om te analyseren. Het lijkt me duidelijk dat ze zaken onderschat hebben, maar SVB waarschijnlijk ook.

[burne]

Het lijkt me duidelijk dat ze zaken onderschat hebben, maar SVB waarschijnlijk ook.

Was dat niet het hele punt van clubs als Capgemini? Bedrijven en Overheden missen bepaalde kennis en huren die extern in bij bedrijven die die kennis wel hebben. Als vervolgens blijkt dat die kennis iets is wat je toch zelf in huis moet halen om er voor te zorgen dat je je externe inhuur op z'n incompetentie te betrappen en de schade van die incompetentie vergoed kunt krijgen...

[Martinspire]

Als de incompetentie intern zit, kun je nog zoveel externen inhuren...

[Mangofruit]

Ook daar kan expertise voor worden ingehuurd en dat gebeurt ook.

[VulcanSnow]

De (een) klant heeft terdege verstand van requirements, maar de opdrachtnemer heeft deze (bewust?) onvoldoende bewaakt.

[Blokker_1999]

Stel een bouwonderneming wil een nieuw ERP systeem invoeren. Hoeveel verstand hebben zij van de requirements denk je? Of van de complexiteit? Waarom moeten we altijd maar denken dat dit soort problemen alleen bij de overheid bestaat en niet in de private bedrijfswereld? De overheid is echt niet zo verschillend hoor.

Aan de top van een overheidsdienst zitten inderdaad politiek benoemde mensen. Maar de mensen die aan dit soort projecten meewerken zijn vaak niet politiek benoemd maar hebben zich opgewerkt of zijn extern aangetrokken vanwege hun expertise.

Overheidsdiensten zijn echt niet meer wat ze 50 jaar geleden waren.

[NLKornolio]

Waarom snapt de overheid niks,... Omdat de personen over de aanbesteding uitzetten gaan er niks van snappen, dat betekent niet dat ze niet gewoon mensen indienst hebben die de kennis wel hebben. Als ze alle IT zouden centraliseren dan durf ik te wedden dat ze dit soort zaken zelfs inhouse zouden kunnen bouwen. Helaas mag dat weer niet.

[incaz]

Deze visie komt echt iedere keer weer aan bod. Maar ik vind het een buitengewoon gemakkelijke visie, die doet alsof CapGemini niet een expert is, niet slechts op het gebied van de code daadwerkelijk schrijven maar ook de 'consultancy' maar alleen maar een soort onderaannemers. Dat is natuurlijk niet waar ze 43 miljoen voor hebben gekregen.
Als zij onduidelijke specs hebben, horen ze dat te herkennen. Als zij schuivende requirements zien, dienen ze dat te overleggen met de opdrachtgever. De indruk die ik echter heb (niet alleen gebaseerd op dit project) is dat het niet gebeurt en dat men hoopt ermee weg te komen om gewoon niet echt goed werk te leveren.

Ik vind het buitengewoon gemakkelijk om iedere keer die zogenaamd 'controversiele' advocaat-van-de-duivel visie te herhalen, die doet alsof gigantische softwarebedrijven daarin machteloos zijn. Mij lijkt dat echt een verkeerde voorstelling van zaken. Een die wel heel gerieflijk alle blaam van zich af schuift.

[Martinspire]

Ik zeg ook niet dat ze geen blaam treft, maar vind het makkelijk dat álles op Capgemini lijkt te worden afgeschoven.

Als je kijkt hoeveel opdrachten elk jaar wel goed gaan, dan is het duidelijk dat er een ander probleem zit. Bovendien zul je bij hun een mooi overzicht kunnen maken van welke branches de opdrachten op tijd kunnen worden afgeleverd en bij welke niet. Of hoe het zit met de kwaliteit. Je zult zien dat overheid het slechtst scoort en dat is jammer, maar zeker ook wel een probleem. Daar kun je op den duur ook maar beperkt rekening mee houden en ze zullen vast geklaagd hebben, maar de opdracht is betaald en men verwacht dat er dan wat geleverd wordt. Dat is in sommige situaties erg lastig, zeker als je te maken hebt met een opdrachtgever die ontkent dat er problemen zijn en alles afschuift.

Ik stel ook niet dat onbekwaamheid onder de Capgemini medewerkers niet heeft meegespeeld. Er zullen vast nieuwe mensen aan gewerkt hebben, maar dat is altijd wel een risico. Je kunt alleen niet verwachten dat er altijd ervaren mensen aan werken, want je moet toch wel een keer nieuwe mensen aan het werk zetten.

[djiwie]

De schuld wordt op Cap afgeschoven omdat Cap gewoon keihard geblunderd heeft. En dat doen ze vaker, meestal komen ze er zelfs mee weg (omdat de opdrachtgever ook blundert), maar hier heeft de arbitragecommissie een duidelijk oordeel gegeven en Cap veroordeeld tot een boete.

Ik stel ook niet dat onbekwaamheid onder de Capgemini medewerkers niet heeft meegespeeld. Er zullen vast nieuwe mensen aan gewerkt hebben, maar dat is altijd wel een risico. Je kunt alleen niet verwachten dat er altijd ervaren mensen aan werken, want je moet toch wel een keer nieuwe mensen aan het werk zetten.

Je gooit niet 100% juniors op een project, zeker niet met een omvang als deze. Bovendien is slechte code schrijven één ding, een bedrijf dat zich als expert profileert (en dat doet Cap) zou ook een proces moeten hebben waar alle code gereviewd wordt voordat het naar de klant verscheept wordt. Als je de Zembla documentaire hebt gezien is dat duidelijk niet gebeurd.

Nog los daarvan blijkt uit alles dat Capgemini met man en macht heeft weten te voorkomen dat medewerkers van de SVB inzicht kregen in de problemen tijdens het project of in de kwaliteit van de opgeleverde software.

Ik snap niet zo goed waarom je in je verschillende reacties op dit artikel steeds het aandeel van Capgemini loopt te downplayen, terwijl daar overduidelijk heel veel fouten gemaakt zijn.

[Martinspire]

Nogmaals, ik zeg nergens dat Capgemini geen blaam treft, maar ik vind dat de overheid ook een deel van de schuld op zich moet nemen. Ja ze hebben gefaald en nee dat had nooit mogen gebeuren. Maar het is nu gebeurd en waar 2 eraan werken, hebben 2 schuld.

[R4gnax]

waar 2 eraan werken, hebben 2 schuld.

Het is nog altijd zo dat er één de opdracht heeft gegeven en de ander daaraan gewerkt heeft.
Van die tweede mag je verwachten dat er afdoende expertise zit.

Als ik een loodgieter laat komen en vraag om een lek te herstellen, dan hoef ik ook niet pijp voor pijp mee te gaan staan kijken; aan te gaan lopen wijzen; en bij te instrueren, of wel?

Ja; software is complex. Zeker meer complex dan een lek herstellen. Maar het is primair aan de expert die er mee aan het werk is om alle details helder te krijgen en met problemen naar buiten te treden. Niet aan de klant. Die zal enkel op de rem trappen als duidelijk wordt dat er broddelwerk geleverd wordt.

Juist dat heeft Capgemini in bovenstaande verhaal met man en macht gepoogd om buiten zicht van de SVB te houden. Helaas succesvol. (Dat zal wss. voor de arbitrage ook wel een vrij zwaar wegend punt geweest zijn.)

[Reactie gewijzigd door R4gnax op 22 juli 2024 13:22]

[Sandor_Clegane]

Uhm nee, je kan wel verwachten dat er ervaren mensen aan meewerken, daarom neem je CAP en niet ZZP Software Inc om de hoek. Hoe zij hun mensen trainen is voor jou, als een klant, helemaal niet interessant en je betaald de hoofdprijs aan hun om dat ook niet te hoeven weten.

Zij horen te signaleren wanneer dingen niet duidelijk zijn in de requirements, zij horen op de rem te trappen als de features de spuigaten uit lopen.

De overheid treft ook blaam, maar niet als het komt op het bouwen van de software. Daarvoor neem je een bedrijf als CAP in de hand zodat jij dat niet hoeft te weten.

Is dit nu het resultaat van jaren: "je moet geen eigen mensen in dienst hebben die dat kunnen, dat wil je toch helemaal niet. Je moet blijven bij je core-business en de expertise inhuren".

[incaz]

Heb je cijfers over hoeveel opdrachten er elk jaar wel goed gaan? Hoe weet je eigenlijk dat het bij commerciele bedrijven wel goed gaat? Op grond van wat er zoal aan datalekken en administratieproblemen voorkomen (sommige mensen die een wijziging proberen door te geven aan een telecombedrijf ofzo kunnen je verhalen vertellen) zou ik zeggen dat dit maar de vraag is - alleen weten we veel van die problemen niet omdat die bedrijven niet op dezelfde manier onder de loep genomen worden als overheidsinstanties. Dat betekent niet dat het daar beter gaat...

Zoals ik het een makkelijke frame vind dat techbedrijven het zo moeilijk hebben omdat de specs steeds veranderen of de opdracht onduidelijk is (dan zorg je dat het goed geregeld is?) vind ik het ook een ontzettend makkelijke frame om te doen alsof het altijd de overheid is waar het faalt.)

[Martinspire]

Ik heb geen cijfers, maar werk bij 1 van de zusterbedrijven van Cap die ook veel opdrachten doet en detacheerders wegzet. Niet elk project gaat goed, maar ik zie vaak dat een groot deel van het probleem bij de opdrachtgever zit omdat die niet alles goed heeft ingeschat, niet alles eerlijk heeft verteld en gedurende het project constant dingen veranderd.

Het is onmogelijk om het spelletje te spelen, als je de hele tijd de regels veranderd en anders toepast. Volgens mij wordt onderschat hoeveel incompetente mensen er bij de overheid werken die denken dat ze competent zijn.

[latka]

Ik heb ook gewerkt bij zo'n club maar ben weggegaan omdat ik in zo'n situatie het project stil wilde laten leggen om eerst het verhaal goed te krijgen. Dat werd niet gewaardeerd door het management (van de klant en het bedrijf waar ik voor werkte). Project is uiteraard niet gelukt maar ik ben wel met opgeheven hoofd het pand uitgelopen.

[Crazy D]

Ik heb geen cijfers, maar werk bij 1 van de zusterbedrijven van Cap die ook veel opdrachten doet en detacheerders wegzet. Niet elk project gaat goed, maar ik zie vaak dat een groot deel van het probleem bij de opdrachtgever zit omdat die niet alles goed heeft ingeschat, niet alles eerlijk heeft verteld en gedurende het project constant dingen veranderd.

In een veranderende wereld kunnen de specificaties niet ongewijzigd blijven. Daarmee loop je per definitie achter met je oplossing t.o.v. de werkelijkheid. De kunst is hier goed mee om te gaan.

Als specs dusdanig wijzigen dat dat fundamenteel anders moet worden opgelost, moet de projectleider dat escaleren bij de opdrachtgever.

Het probleem bij projecten van deze omvang is dat het heel moeilijk is om die flexibiliteit te bieden, omdat er zoveel parameters en afhankelijkheden zijn. Ik denk dat een deel van het probleem is, dat projectleiders zichzelf ook wel iets overschatten.

[incaz]

Ah, dan snap ik je visie beter.

Maar toch, als expertbedrijf dien je met die dingen om te kunnen gaan en daar rekening mee te houden. Fool me once etc.
Mijn eigen ervaring bij de overheid (maar dat waren lagere overheden, gemeentes vooral) was dat het geen onwil was, maar vooral dat er binnen die overheid niemand over voldoende kennis beschikt om de juiste specs te *kunnen* formuleren omdat er een grote kloof loopt tussen het werk van alledag en de vertaling daarvan naar de IT. Dat is niet erg en ook niet onoplosbaar: zorg dat je veel contact krijgt met de mensen die ermee werken en analyseer wat ze doen, en dan kom je er vaak wel uit.

(Voor mij is dit precies de reden dat IT van landelijke overheidsdiensten eigenlijk niet bij aparte bedrijven hoort maar gewoon een goede eigen IT-afdeling hebben: de IT en de uitvoeringspraktijk liggen zo dicht bij elkaar dat ze samen zouden horen.)

Maar goed, ik vind dus dat als dit nu jaren en jaren al gebleken is dat de opdrachtgevers niet vooraf helder kunnen maken wat ze exact nodig hebben, je als consultancy-expertisebedrijf je daar rekening mee moet houden en moet zorgen dat je daar ruimte voor inbouwt. Da's namelijk ook een deel van de kennis en ervaring die je hebt opgedaan en waar je voor betaald wordt.

[Blokker_1999]

Nieuwe mensen plaats je onder supervisie van ervaren mensen en hun werk controleer je ook net iets vaker. Er is geen enkel excuus te vinden van waarom Cap hier slecht werk heeft geleverd behalve dan dat ze er de hoeken serieus hebben afgelopen.

Ik vind het ook vreemd dat men altijd maar afgeeft op de overheid en dat het daar misloopt. Dan vraag ik me af hoeveel ervaring je zelf hebt met private ondernemingen. Want daar heb ik ondertussen ook al voldoende van gezien en gehoord. Het gaat daar echt niet beter hoor.

Het enige verschil tussen een overheidsopdracht en een opdracht met een private onderneming is dat die overheid moet rapporteren en openbaren wat er allemaal gebeurd met zo een investering. Een private ondernemer moet dat niet en zal dat liefst zo snel mogelijk uit zijn geschiedenisboeken laten verdwijnen.

[Vizzie]

Nog een verschilletje is dat de overheid faalt met ons geld, een private onderneming met het eigen geld...mag wel wat meer transparantie tegenover staan toch?

[Mangofruit]

Blijkbaar heb je het stuk niet goed gelezen, Cap Gemini is veroordeeld tot een bedrag van ongeveer de helft. De belasting betaler o.a. jij en ik dus, mogen de andere helft betalen.

[Nogne]

Ik heb weinig verstand van een aanbestedingsprocedure, maar als SVB aangeeft wat ze willen. En Capgemini zegt dat ze dat kunnen leveren voor €43miljoen euro en ze leveren dat dan niet, dan is het toch logisch dat je je geld terug wil. Misschien denk ik te makkelijk hier over, maar ik vind je argumenten beetje raar over komen als leek.

[Deveon]

Dat is de theorie van een aanbesteding, maar in de praktijk bied de leverancier onder of tegen kost prijs zijn diensten aan en zodra er meerwerk komt betaald de klant zich scheel.

[Nogne]

Meerwerk is toch extra werk wat niet bij de originele aanbesteding zat? Ik snap dat als de klant iets bovenop de originele aanbesteding wil dat je daar extra voor betaald. Maar het gaat hier om het feit dat Capgemini zegt dat ze het voor €43 miljoen kunnen leveren, en wat ze achteraf helemaal niet hebben kunnen leveren.

[Wasrek]

Ik denk dat Deveon probeert de schetsen hoe aanbestedingen in de praktijk kunnen werken: bedrijven schrijven zich zo goedkoop mogelijk in om als goedkoopste inschrijver uit de bus te komen en de opdracht binnen te halen. Hier wordt waarschijnlijk niet of nauwelijks geld verdiend. Het cashen begint pas na gunning aan de goedkoopste inschrijver, als later naar boven komt dat de klant fouten in het dossier heeft zitten (al dan niet bij de inschrijvers bekend op het moment dat ze een bod doen) en dus aanpassingen wil. De goedkoopste inschrijver kan dan vaak de hoofdprijs vragen.

Ik ken de details in dit geval niet, maar afgaand op het nieuwsbericht heeft Capgemini zelfs niet aan de orginele afspraak voldaan en moet het de helft van het reeds verdiende geld terugbetalen. De gemaakte kosten voor de SVB (daar werkt ook personeel dat zich bezig hield met deze opdracht + het systeem zal flink vertraagd zijn) liggen vermoedelijk veel hoger.

[TerraGuy]

Al is dat deels ook vanwege dat een 'kleine wijziging' van de klant heel veel werk kan betekenen voor de leverancier. Omdat het afwijkt van de stramienen waarmee een leverancier werkt, of omdat een kleine functionele wijziging soms betekent dat het hele ontwerp op de schop moet en weer opnieuw getest. Dit is mijn ervaring als webdesigner tenminste, zal bij programma's niet anders zijn. Lastig om uit te leggen aan een klant vaak.

[Reactie gewijzigd door TerraGuy op 22 juli 2024 13:22]

[Luno]

Als je voor de overheid iets maakt moet rekening houden met veranderingen. Elk nieuw kabinet maakt nieuwe wetten en verandert regelingen.
Als je als leverancier niet kunt omgaan met deze dynamische werkelijkheid maar slechts een product aflevert dat maar voor één situatie goed werkt ben je fout bezig.
En die dynamische werkelijkheid komt door ons, door telkens andere eisen te hebben waaraan de regering wil voldoen met her aanpassen van regels.

[killer_mac]

Ik hoop dat je snapt dat je nooit met alles rekening kan houden.
soms worden er zelfs in een kabinetsperiode 180 graden gedraaid.
Geen enkele voorspelling of systeem kan hiermee over weg..

enkel een paar kamervragen die met ja beantwoord worden kan de hele werking van je systeem op zijn kop leggen..

Stel jij krijgt een opdracht om een interface te bouwen met SQL server.
tijdens oplevering wordt er bij de tegenpartij een nieuw systeem geïntroduceerd namelijk Oracle,
Beide systemen dienen nu ondersteund te worden.

Oracle heeft volledig andere eisen.. (dat is toch meerwerk of niet??)

[Luno]

Sinds wanneer begrijpt Oracle geen SQL?
Ik geloof best dat dit soort dingen voorgekomen zijn. Maar als jij dus iets bouwt dat alleen met SQL server kan omgaan ben je al fout bezig. De presentatielaag is één ding, de logica laag is een 2de, en de onderliggende database server een derde.
De pijn zit hem in de logica laag, want de logica van de overheid is dynamisch. De onderliggende database laag is irrelevant (of het nou Access is, MySQL of Oracle).
En de interface mag helemaal niet gebaseerd zijn op de server. Dan hang je bij elke versie van de server op redesign. Nb. ik neem aan dat je met interface de interactie van de gebruiker met het systeem bedoelt.

Als je de opdracht krijgt om een interface te bouwen met SQL server, moet je de opdracht terugverwijzen.

[killer_mac]

Eeh Oracle maakt toch echt gebruik van andere interfaces als SQL server,
derhalve maakt het wel degelijk uit welke database ten grondslag ligt

Zelfs de SQL code verschilt, omdat ieder zijn eigen sausje er over heen gooit.
Daarnaast ook de functionaliteit, SQL server triggers zijn toch echt anders als die van Oracle, Hebben beiden hun eigen optimalisaties nodig enz...

Als ik de opdracht krijgt om een met SQL server connectie te maken waarom zou ik de opdracht dan terug moeten verwijzen?? zeker als de klant alleen SQL servers beschikbaar heeft..
Moet ik dan maar vertellen met mij bent u vele malen duurder uit omdat u bij aanvang al u hele serverpark dient te vervangen??

Zoals ik al eerder zei, theorie is de ene kant, Praktijk is altijd weerbarstiger,
oh btw, ik heb een achtergrond in Software ontwikkeling, Database beheer, Netwerken en security en al jaren projectmanager van projecten op allerlei gebied..needless to say, ik ken de valkuilen maar al te goed..

[Reactie gewijzigd door killer_mac op 22 juli 2024 13:22]

[latka]

De kosten die jij noemt zijn nihil (Oracle VS sql server). De echte kosten zitten in schuiven op functioneel gebied. Goed voorbeeld zijn de aangepaste BTW regels voor digitale diensten. Voorheen (voor 2015) deed je aangifte in eigen land. Dat is omgezet naar BTW in land van de klant. Dat betekent dat je in de hele keten van gegevens verwerking deze informatie mee moet nemen en een BTW berekening per land moet gaan doen. Dan moet je je datamodel aanpassen, de logica aanpassen en de ui laag (nieuwe beheerscripts op zijn minst). Je moet alles testen (gestart 20* zo groot maken). Zo'n kleine vraag ("BTW in land van klant ipv. land van leverancier") kan zo een paar weken werk zijn en alles raken.

[Mangofruit]

Dat ben ik helemaal met je eens, ze belazeren de klant op deze manier. Het is goed dat er eens tegenspel komt tegen dit soort half criminele organisaties die het zo op gemeenschapsgeld voorzien hebben.

[Tweaker42a]

Cap had de opdracht natuurlijk niet hoeven aannemen, ze wisten waaraan ze begonnen. Ze waren zelf bij de requirement analyse ze hadden toen moeten ingrijpen, maar die grote zak geld aan het eind is natuurlijk verleidelijk voor cap. Neemt niet weg dat de overheid zelf betere experts moet aannemen en niet alleen management functies vervult.

[Martinspire]

Volgens mij onderschat je hoe weinig je te horen krijgt bij een dergelijke opdracht. Je moet veel zaken zelf invullen en er zit qua kostenindicatie veel nattevingerwerk bij. Het is niet alsof je alles te zien en te horen krijgt en of de SVB eerlijk is in hoe goed hun huidige systeem werkt.

[Tweaker42a]

Dan moet je de opdracht niet aannemen, als je hem aanneemt zeg je impliciet: ik snap het, gaan we doen.
Ik werk zelf in deze sector en ik denk dat er ruimte moet zijn voor fouten, het gaat hier echter gewoon om erg grove fouten.

Beide partijen zouden niet aan mammoet projecten moeten willen beginnen, dit advies zou een professional je ook moeten geven, deel het project op, laat dit doen door de juiste mensen (dit is natuurlijk makkelijker gezegd dan gedaan) .

[Reactie gewijzigd door Tweaker42a op 22 juli 2024 13:22]

[jpsch]

Zat in die docu over CG niet dat CG ook werd ingehuurd voor het schrijven van de opdracht?

Edit: de twee programma managers werden ingehuurd door CG en hadden een gezamenlijk bedrijf
.docu is overigens van Zembla, heet 'Spaghetticode' en is nog online te kijken.

[Reactie gewijzigd door jpsch op 22 juli 2024 13:22]

[Tweaker42a]

Dat zou kunnen, altijd makkelijk om alles uit handen te geven, als je alles door iemand anders laat doen wordt het waarschijnlijk wel wat (veel) duurder. Neemt niet weg dat die partij wel iets werkend moet opleveren.
De vraag is nu meer of men er iets van geleerd heeft, in veel van dit soort gevallen zijn het erg ambitieuze mensen die niet overleggen met de juiste mensen.

[Reactie gewijzigd door Tweaker42a op 22 juli 2024 13:22]

[Megajr]

Maar heeft Capgemini niet een batterij aan consultants die in elke fase van het project vast leggen wat er geleverd gaat worden? Als daar aan voldoen was dan zou er in mijn beleving geen boete zijn nu. Niet dat ik een gedeelte van je statement niet herken, elke overheidsinstantie heeft hier wel mee te maken maar dat geeft je geen vrijbrief om dan niet goed werk te leveren.

[Martinspire]

Het hangt maar net af aan hoe dat dit is afgesproken. En het zal niet de eerste keer zijn dat iets toch anders blijkt te werken dan vooraf gedacht/geschat. Bovendien kunnen eisen veranderen of zaken worden toegevoegd. Ja men wil graag opleveren wat is afgesproken, maar dat gaat niet altijd door. Zeker met die overheidssystemen kan ik me voorstellen dat je er niet zomaar achter komt hoe bestaande systemen werken en hoe de integratie daarmee moet gaan verlopen. Als je dan al tijd kwijt bent aan het schrijven van tussenlagen (omdat het allemaal niet aansluit), dan kost dat extra tijd en moeite.

Het is niet alsof er na de onderzoeken en ontwerpen niks meer veranderd.

[ALRD]

Net met verbazing naar de Zembla documentaire gekeken. Om zo'n systeem te kunnen bouwen moet je tot in detail weten hoe het Nederlandse sociale zekerheidsstelsel in elkaar zit. Dat is zeer complex en bronnen zijn enkel in het Nederlands beschikbaar. En daarbij is het een constant wijzigende omgeving door beleidswijzigingen door opvolgende kabinetten en gerechtelijke uitspraken. De foutmarge is daarnaast minimaal (elke burger die een verkeerde uitkering/toeslag krijgt klaagt/maakt bezwaar). Er is geen enkele marge om betalingen ook maar één dag uit te stellen. De schaal van het systeem is enorm.

En om dan te denken dat je een stel Indiërs code kan laten kloppen. Hoe verzin je het? Dan ben je als Capgemini sowieso schuldig.

[Cybertek]

_{En om dan te denken dat je een stel Indiërs code kan laten kloppen.}

Denk je dat dat alles is?

En wat dacht je van de ABN/Amro, Rabobank, ING? Die hebben allemaal Indiërs in India zitten die aan het programmeren zijn hoor hun en op en neer vliegen. Jullie financiële veiligheid is ondergebracht daar in dat oh zo corrupte landje, ongeacht bij welke bank je ook zit. En dat is in Duitsland niet anders en België.

[Anoniem: 890159]

Blijkbaar is er door Cap nog slechtere code opgeleverd dan gebruikelijk. Dat was natuurlijk te verwachten omdat Cap het uitvoerende werk heeft geoffshored naar India, en dat is vragen om problemen. Cap India staat uiterst slecht bekend, ook bij andere opdrachtgevers

Ik ken Indiers persoonlijk, en sommigen zijn erg goede programmeurs, maar dat zijn dan wel de mensen die al jaren in het westen leven en (grotendeels) de werkcultuur overgenomen hebben.

[Martinspire]

Mja mijn ervaringen met offshore zijn ook niet goed. En het maakt weinig uit of je dat laat doen in India of bv in oost Europa. Maar vaak kom je daar alleen met dit soort opdrachten achter en is het lastig om kwaliteit te kunnen garanderen. Ze denken in India veel te makkelijk, zijn niet flexibel en spreken (ondanks dat Engels gewoon een officiële taal is) maar belabberd Engels.

[Anoniem: 343906]

Die ICT-ers die vanuit India naar hier komen hebben een output waar je 'U' tegen zegt. Idem geldt overigens voor ICT-ers uit de V.S. en Israël. Die hebben een werkdiscipline die ik bij menige Nederlandse collega niet zie.

[vbmot]

Natuurlijk, de goede engineers uit India vertrekken allemaal naar Silicon Valley (met evt tussenstop in Europa). De minder goede blijven achter in Bangalore.

[hiostu]

Dat niet alleen, de druk ligt bij dit soort aanbestedingen vaak enorm op de prijs. Alle bedrijven proberen daarom zo goedkoop mogelijk aan te bieden. Daarnaast wil de overheid vaak ook maatwerk in plaats van de processen aan te passen aan hoe sommige pakketten werken (en soms kan dat ook simpelweg niet door wetgeving). In Nederland heest een beetje het idee dat tegenwoordig programmeurs zo goedkoop mogelijk moeten zijn. En goede programmeurs zijn nou eenmaal moeilijk te vinden en duur. Veel mensen kunnen programmeren, maar er zijn er veel minder die dit ook goed kunnen. Het is best een kunst om een groot en complex systeem onderhoudbaar neer te zetten. Ik denk dat >50% van de programmeurs dit simpelweg niet kan.

Tegenwoordig zie je dat ook weer pijnlijk duidelijk worden bij de "app" ontwikkelaars. Het gaat goed zolang het een relatief simpele app is, maar zodra de omvang groeit en er steeds meer functionaliteit bij komt en meer integratie, dan zakt het als een kaartenhuis in elkaar.

Maar ja, dat kun je vaak nergens kwijt in een doorsnee aanbesteding. De overheid wil functionaliteit X tegen een zo laag mogelijke prijs.

[Tribits]

Als ik de verklaringen van de klokkenluiders lees dan heeft de SVB zelf soms onprofessioneel of nalatig gehandeld, bijvoorbeeld door geen rekening te houden met licentiekosten, onvoldoende af te bakenen wat wel en geen meerwerk was, en niet te bedingen dat het programmeerwerk in Nederland plaats zou vinden.

Het belangrijkste punt is echter dat CAP structureel voorkomen heeft dat de SVB voldoende toezicht kon houden, niet of nauwelijks reageerde op de bevindingen van de SVB en er bewust op aanstuurde om software met fouten en ontbrekende kwaliteit in productie te nemen. Daar zit duidelijk een deel kwade opzet, en dat is toch wel een stuk ernstiger dan een klant die een contract niet volledig dicht heeft getimmerd.

[Reactie gewijzigd door Tribits op 22 juli 2024 13:22]

[memphis]

Het is bekend dat veel door de overheid ingehuurde bedrijven er alles aan doen om veel onkosten te maken en het werk langer te laten duren dan het moet zijn gezien veel overheden er toch niet tegenin gaan. Blijkbaar heegt Capemini verkeerd gegokt en is in zee gegaan met een overheidsinstelling die wel actie durft te ondernemen.

[GeoBeo]

Even de advocaat van de duivel spelen: Schuif niet de hele schuld naar Capgemini. Vergeet niet hoe slecht sommige departementen binnen de overheid gerund worden (laatste faal in het nieuws was bv Defensie) en hoe lastig het is om al een beeld te krijgen waar het allemaal op aan moet sluiten. Managementbeslissingen door mensen die vervolgens nergens verstand van hebben zorgt voor nog meer vertraging. Als ik zie wat voor puinhoop het bij de Belastingdienst is, dan kan ik me niet voorstellen dat het bij de SVB zo soepel loopt.

Wat een onzin. Capgemini heeft beloofd iets te kunnen leveren en heeft niet geleverd wat het beloofde. Punt uit.

"Ja maar het was zo moeilijk te achterhalen wat ze dan moesten leveren aan de klant." is een onzin argument. Je kunt immers als leverancier gewoon besluiten niet door te gaan met levering als de inkoopvoorwaarden van de klant te vaag zijn of het project te vaag is. Je kunt dat zelfs opnemen in het contract. Tenminste, als je reputatie je wat waard is.

Dit is gewoon met pure opzet zo veel mogelijk geld uit "de domme overheid" persen als mogelijk. Die reputatie heeft Capgemini al en ze zijn actief bezig die reputatie hoog te houden. Als Capgemini (o.a.) ook maar een greintje schade zou leiden door dit soort ondermaatse leveringen en contractbreuk dan hadden ze er wel mee opgehouden jaren geleden. En ja, de overheid is ook een pijnhoop, maar dat is geen excuus voor een leverancier om met voorbedachte rade dan toch maar opdrachten aan te nemen. Opdrachten waarbij vanaf het aller eerste begin duidelijk is dat er niets duidelijk is en ook niet zal worden.

Nog even los van het feit dat als je naar de details van de deals kijkt en onderzoek doet naar de mensen erachter je waarschijnlijk tot de conclusie moet komen dat dit soort software aanbestedingen pure corruptie zijn.

[Ciel48]

Ik denk dat CapGemini er nog genadig vanaf komt. De boete bedraagt minder dan de helft van het totale bedrag waarvoor SVB nu 't schip in gaat en wij als belastingbetaler voor gaan opdraaien...

[karma4]

Ik mis de leiding van de ICT door onder andere IBM. Het is niet een enkel factor het gaat om de hele keten.
https://www.computable.nl...-voor-it-vernieuwing.html

[Ganymedus]

Je hebt zeker een punt, er is een groot schemergebied wat nu niet belicht is. In Nederland in het algemeen zijn wij niet sterk in het accuraat bepalen wat we willen. (Als iemand twijfelt, vraag dan even je vrouw/vriendin wat zij van jou skills op dit vlak vind.... ) Dit is een denkwijze die voorbij gaat aan samenwerken maar een sterk en afgebakende visie vereist. Zeker binnen de (met name semi) overheid, geeft dit een probleem op het snijvlak van outsourcing van werk. Er is een verkeerde verwachting dat wanneer je het ontwikkel traject over de schutting gooit dat de organisatie opeens een gestroomlijnde software delivery straat heeft.

Persoonlijk denk ik dat de overheid aanzienlijk meer baat heeft bij agile oplossingen in house.

Dit neemt niet weg dat Capgemini mogelijk meer had kunnen doen om ervoor te zorgen dat er een degelijk product komt te staan. Het is de consultant zijn taak om voorbij de belangen van zijn werkgever te kijken en juist ook de belangen van de klant te behartigen.

[Reactie gewijzigd door Ganymedus op 22 juli 2024 13:22]

[SSH]

Cap is de professionele partij en moet regie voeren om binnen budget te blijven. Al mijn ervaringen met Cap zijn dat hun managers alleen maar beloond worden op meerwerk en marge. Deze partij moet je gewoon weg van blijven...

[SunnieNL]

4 jaar programmeren levert sowieso elk jaar andere regels vanuit de overheid zelf. Echter, dat weet je als je hier aan begint en je moet dan ook een systeem bedenken waarin zulke regels flexibel kunnen worden veranderd.

Maargoed, bij dit soort projecten hebben altijd meerdere schuld. Waarschijnlijk aanbesteding met eisen niet goed afgegeven.
Zie het zo vaak. 30 pagina`s tekst en dan 1 pagina met eisen. Alleen met dat laatste moet je officieel rekening houden. Ze hebben dan zelf vergeten de tekst om te zetten naar eisen.

[Anoniem: 426269]

Tsss, er ontrbeekt nog altijd bijna 24 miljoen. Die is dus geleverd voor een niet-af, ondeugdelijk product. Dat zouden ze mijn inziens ook moeten terugkrijgen. Nu zal een overheid best tussentijds steeds veranderingen willen en extra werk opgeven, maar als de basis niet goed is, dan houdt het wel een beetje op en kan het natuurlijk nooit iets worden.

Daarom betaal ik zelf nooit voor half werk, maar alleen bij oplevering van een goed werkend product. Maar die projectjes zijn ook iets kleiner. Dat zal hier wel niet te doen zijn. Maar het is altijd hetzelfde liedje, het loopt altijd uit en het wordt altijd tig keer duurder.

[Dark_man]

Ik werk zelf bij een groot bedrijf die software heeft laten ontwikkelen dat draait op Windows en door een bug in Windows werkt de software niet goed.

Terwijl dat soort dingen oplosbaar zouden moeten zijn maar zijn na vele jaren nog steeds niet opgelost.

Het is gewoon bizar hoe slecht en amateuristisch grote bedrijven software ontwikkelen, je zou toch gewoon altijd je geld moeten kunnen terug vragen? Anders beloon je dit soort software bedrijven om slechte producten af te leveren.

[Zer0]

Als ik zaken lees als "bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar." dan kan ik niet anders concluderen dan dat er ook blaam bij SVB ligt.

Ik snap niet hoe de SVB verantwoordelijk kan zijn voor simpelweg slechte code. Dat het project langer duurt door tussentijdse wijzigingen door SVB, of omdat de vraagstelling gewoon erg complex is zou ik snappen.
Als tussentijdse wijzigingen je niet genoeg tijd laten om een goed product af te leveren dan heb je een slechte deal gesloten en jezelf niet genoeg afgedekt in de contracten.

[HooksForFeet]

Als Capgemini dacht dat een oud systeem niet zou werken, dan hadden ze het niet als optie aan moeten bieden. In dat geval zouden ze dus bewust iets verkocht hebben waarvan ze wisten dat het zinloos was, en zou de boete meer dan terecht zijn.

[Fornoo]

De schuld ligt bij beiden. Waarom het steeds zo fout gaat en ook zal gaan is omdat veel managers in meer of mindere mate narcistisch zijn. Dit verhult incompetentie. Zo simpel is het.

[Bezulba]

Ik ben van mening dat het wel degelijk voor een groot deel de schuld is van Cap. Dit soort projecten worden aanbesteed en dan schrijven er een hoop bedrijven zich in en een aantal daarvan (zoals Cap) gaan lekker laag zitten. Want dan krijgen ze het sneller.
Vervolgens hebben ze slechte projectleiders, geen overzicht en al helemaal geen overwicht (want ze doen alles wat de klant wil aangezien uurtje=factuurtje) en komt er dus iets uit waarvan Cap durft te beweren: "niet onze schuld, de klant wou het constant anders!11" en nu is er dus een uitspraak waar bij men zegt dat het wel degelijk de helft hun fout is. Dat slecht projectmanagement niet compleet in de schoenen van de klant geschoven kan worden. De klant zegt namelijk "Wij hebben hier de kennis niet voor" en dan mag de leverancier vervolgens broddelwerk leveren en als tegenargument aanbrengen "De klant had de kennis niet en daarom ging het slecht!"..

[fverhoef]

Ja, de overheid is soms berucht als het gaat om slechte opdrachten uit te schrijven. Echter de grote ICT bedrijven maken daar vaak goed gebruik van om daarop in te schrijven voor een achterlijk laag bedrag, om daarvoor een incompleet product op te leveren.
Daarna is het 't meerwerk waar zo'n ICT bedrijf dan opeens veel geld mee verdient.

Het is dus ook aan een ICT bedrijf om aan te geven wanneer een opdracht niet compleet of eenduidig is, om dat dan ook aan te geven.

Ik vind het dus wel goed dat zo'n ICT bedrijf nu eindelijk eens wordt aangepakt voor het handig veel extra geld af te troggelen over de ruggen van de belastingbetalers

[1nsane]

Maar dat is dan ook precies het probleem van een waterval methodiek, in de huidige wereld veranderen eisen en wensen aan software regelmatig. Niet voor niets stappen veel bedrijven over op een Agile methodiek juist om ook effectief bij te kunnen sturen op veranderende scope.

[Martinspire]

Je kunt best Agile werken aan een project als deze en het zal me verbazen als Cap dat al niet had gedaan.

[Golodh]

Dacht ook een tijdje dat de ICT bij de overheid relatief slecht gamanaged werd.

Heb echter mijn beeldvorming een klein beetje bijgesteld op basis van een gesprek in laatste paar maanden met een collega die overgestapt is van de Belastingdienst naar een bedrijf in de financiele sector. Bleek de puinhoop erger te wezen, aleen dan met simpeler systemen.

Bijvoorbeeld het database ontwerp van een bepaald productiesysteem (!) van zijn nieuwe opdrachtgever "was er niet". Moest je zelf maar uitvogelen op basis van de fysieke tabellen die hij aantrof. Leuk heh? Oplevering van dat soort docs was niet bij de prijs inbegrepen en de oorspronkelijke bouwers waren al lang weer weg.

Het zal vast niet allemaal goed zitten bij de overheid, maar het bedrijfsleven kan er ook wat van. Klein verschil tussen bedrijfsleven en overheid: als een groep klanten bij het bedrijfsleven voor disproportioneel grote kosten zorgt (ook op ICT gebied) dan maak je een kosten-baten afweging. Desnoods knikker je die groep lastige klanten eruit.

De overheid kan dat niet. Die moet echt iedereen bedienen en doet zelden aan kosten-baten afwegingn. En dat leidt dan inderdaad wel eens tot grotere complexiteit je systemen dan verstandig is.

[laptopleon]

Schuif niet de hele schuld naar Capgemini. […] Als ik zaken lees als "bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar." dan kan ik niet anders concluderen dan dat er ook blaam bij SVB ligt. […] En hoewel de boete vast terecht is, is het jammer dat men Capgemini vervolgens als enige schuldige op het hakblok legt.

Dat staat er toch ook niet? "De boete komt neer op ongeveer de helft van de 43,7 miljoen euro die het project de SVB heeft gekost.". Feitelijk is de hele som weggegooid geld maar Capgemini hoeft maar de helft terug te geven, dus dan ze komen nog goed weg.

Juist met zulke projecten voor zulke bedragen mag je verwachten dat een specialistisch bedrijf grenzen stelt en het project in goede banen leidt. Hopelijk leren beide partijen hier iets van, vooral de overheid.

[Punkbuster]

Dit soort gebrekkige bende heb ik vaker gezien van CAP.. krijg je ook al je trainees weg zet als senior consultants..

[Wim-Bart]

Ik heb zo veel projecten van Cap langs zien komen, waarvan er niet 1 bracht wat er beloofd was. Maar ook onduidelijke specificaties waar CAP op in speelt waren hier debet aan naast slecht testen door de klanten zelf. Zelf vind ik de werkwijze van CAP onethisch, maar ze gebruiken gewoon de regels in hun voordeel. Daarnaast speelt ook de politiek een rol. Wetten die ingaan op datum x en dan nog twee weken van te voren een aanpassing maken door de politiek, dat is vragen om moeilijkheden. Overigens speelt dat ook de Belastingdienst parten. Pro actief inspelen op wet en regelgeving is niet mogelijk. En bedrijven als CAP lachen want die bouwen gedrochten en iedere aanpassing is weer een flinke factuur.

CAP is eigenlijk een grote organisatie bestaande uit sales, consultants, financiële medewerkers en dan een zwik beroerde programmeurs in India die niet eens weten wat ze bouwen.

Maar ben blij dat er eindelijk eens een halt wordt toegeroepen al is dit natuurlijk een druppel op een gloeiende plaat.

Maar 1 tip als je met CAP in zee gaat. Ondubbelzinnige specificaties opstellen, goed testen, en geen scope wijzigen tijdens het project en duidelijke afspraken over afhandeling van code fouten.

[Iblies]

Apart dat je India noemt.

Een grote partij heeft onlangs een hele zwik contracten vervangen met Tata Consultancy Services.

Een groot deel van de uitbestedingen kwamen via via uiteindelijk in India terecht, alleen zaten er (kostbare) lagen tussen.

Nu heb heb je een aanspreekpunt die ook beter thuis is in die regio.

[FreezeXJ]

"Maar 1 tip als je met CAP in zee gaat. Ondubbelzinnige specificaties opstellen, goed testen, en geen scope wijzigen tijdens het project en duidelijke afspraken over afhandeling van code fouten. "
Als programmeur kan ik dit alleen maar toejuichen, ongeacht het project. Als er halverwege of vlak voor het einde nog even een nieuwe set requirements langs komt, die ook nog maar half uitgewerkt is (want deadline!) krijg je hele nare situaties.

Idem met specificaties, ik heb laatst bij het uitwerken van een issue letterlijk te horen gekregen "doe maar wat". Dit was een ingehuurde expert, die een half boekwerk over het probleem had geschreven, en bij navragen van een interne tegenspraak verwacht ik dan niet zoiets.

[johnkeates]

Komt natuurlijk bij al die grote 'laat ons het maar doen' bedrijven voor, en altijd om dezelfde redenen: scope/requirements verkeerd afgebakend en bewegende doelen gesteld. Het is ook oud nieuws, ik krijg meteen een flashback naar een commentaar van ~4 jaar geleden waar precies hetzelfde aan de hand was (ergens rond de tijd dat de Politie van oude IBM mainframes naar een Windows applicatie over ging?). Het blijft natuurlijk mis gaan door dat de realiteit toch zal blijven botsen met de politiek.

Waar je buiten de IT met smoesjes en halve waarheden nog wel weg komt heb je in de IT, maar ook andere meer wetenschappelijke systemen geen marge. Iets werkt wel, of werkt niet. Software die 1 fout heeft compileert niet, software met 100 fouten ook niet, er is daar geen grijs gebied in (ja, dat is dan puur op syntax maar het is ter illustratie van de afwezigheid van het grijze gebied in niet-functionele zaken). Hetzelfde geldt natuurlijk in metaal waarbij een cylinder met een diameter van 1cm niet vrij door een gat van minder dan 1cm gaat bewegen. En zwaartekracht is ook niet onderhevig aan de mening van een persoon.

Op het moment dat de harde waarheid en de mening- en interpretatiefabriek botsen krijg je falende overheid-IT-projecten.

[warhamstr]

Juist buiten de IT kom je niet weg met smoesjes.

Iets tastbaars dat niet aan de vraag voldoet word simpelweg niet afgenomen.

[Golodh]

Juist buiten de IT kom je niet weg met smoesjes.

Iets tastbaars dat niet aan de vraag voldoet word simpelweg niet afgenomen.

Sorry, maar daar gaat het meestal niet om. Een opdrachtgever betaalt (tenzij een turnkey systeem gevraagd wordt) voor bouwen op specificatie. En die wordt mestal door de opdrachtgever zelf beheerd, want die heeft de proceskennis. Als iets volgens de (door de opdrachtgever geaccordeerde) specs werkt dan moet de opdrachtgever betalen. Okk al issie niet tevreden

Mocht de opdrachtgever het maken van die specs ook bij de softwareleverancier hebben ondergebracht, dan is het nog maar de vraag of hij daarmee verder komt.

Heb bijvoorbeeld meegewerkt aan specs voor een systeem dat op basis van een BPM analyse van des klant's business proces was opgesteld. Die specs waren op zich correct, en garandeerden een systeem dat precies volgens de BPM analyse werkte. Helaas voor de opdrachtgever werkte zijn proces in de praktijk echt anders. Mocht niet "volgens de regels", maar gebeurde gewoon wel, wat in de definitie-fase van het project door het management van de klant gewoon werd ontkend.

Heb in opdracht van de projectleider tenslotte samen met hem mijn bedenkingen over het verschil tussen het gespecificeerde en het werkelijke procesmodel schriftelijk gemeld bij ons directe aanspreekpunt van opdrachtgever, en verder mijn mond dichtgehouden.

Gevolg: de software was correct, werkte aantoonbaar volgens de specs, en was in de praktijk onwerkbaar. Klant moest toch echt betalen. Hoorde later dat ze er een flinke reorganisatie tegenaan hebben moeten gooien om de software in productie te kunnen nemen. Misschien was dat ook wel de bedoeling van hun management. Weet ik veel.

Moraal: de opdrachtgever heeft een fikse verantwoordelijkheid en kan zich daar echt niet zo simpel onderuit draaien..

[STING]

Hoogstwaarschijnlijk zijn ze doorgeschoten met offshoring.

[Martinspire]

Maar dan krijg je ook een senior consultant en geen senior developer

[Mainstay]

Inderdaad. Maar ook de gevestigde orde kan naar de behoefte binnen het project zo plots een compleet andere rol hebben alsof ze kunnen toveren.

"Henk, vandaag ben je IT management liason en morgen hebben we je even nodig als senior consultant. (Henk) komen daar geen vragen van dan? Nee, ze snappen er toch niks van!"

Een grote zwendel als je het mij vraagt en allemaal ontstaan uit onwetendheid waar lekker misbruik van gemaakt word.

[jpsch]

Zolang Henk maar het juiste visitekaartje bij zich heeft.

[SuperDre]

Dat is niet alleen bij CAP, dat is bik bijna alle van dat soort ict bedrijven.

[Blommie01]

Was dit niet die “spaghetti code” ?

[STING]

Klopt! Hier te zien voor de geinteresserden, wel een interessante rapportage: https://zembla.bnnvara.nl/nieuws/de-spaghetticode

[batjes]

Ik vind de manier waarop spaghetticode geformuleerd wordt niet echt correct

Maar Capgemini levert de SVB software die helemaal niet blijkt te werken. Deskundigen noemen dergelijke mislukkingen 'spaghetticode', oftewel onleesbare software

Spaghetticode is niet afhankelijk van het wel of niet functioneren van het programma.

[Coebergh]

Spaghetti code kan prima werken. Alleen is vaak de herbruikbaarheid en modulariteit waardeloos. Als er geen tijd is genomen om spaghetti code om te zetten naar libraries, Dan KAN dat resulteren in een programma wat slecht werkt.

Al mag je natuurlijk van een dergelijk groot project wat je bij een dergelijk groot bedrijf toevertrouwd er redelijkerwijs van uit gaan dat ze fatsoenlijke code afleveren.

[Wim-Bart]

CAP is helemaal geen bedrijf wat fatsoenlijke code wil opleveren. CAP is ook geen software bedrijf.

CAP is een geld machine, die onder het motto van software ontwikkeling knijpt op de kosten. En hoe doen ze dat... Slechte amateur programmeurs in lage lonen landen die maar wat doen en voor de rest alleen maar factuur na factuur sturen.

[Tribits]

Als ik de verklaringen van de klokkenluiders lees dan denk ik dat de structuur van het systeem er wel aan bijgedragen zal hebben dat de kreet spaghetticode gebruikt wordt. Misschien niet geheel correct, maar als ik lees dat het systeem uit dertig verschillende Oracle applicaties opgebouwd was die nog nooit op een dergelijke manier aan elkaar gekoppeld waren dan begrijp ik de vergelijking met spaghetticode wel.

Los daarvan kan spaghetticode prima werken, maar als er iets fout is zal het haast onmogelijk zijn de fout te vinden en op te lossen zonder andere zaken te breken. Daar zat voor zover ik begrijp ook wel een grote makke van dit systeem. Het was niet duidelijk wat er wel en niet inzat of waarom bepaalde zaken niet werken.

[Uruk-Hai]

Dat filmpje geeft eigenlijk wel het volledige antwoord op de vraag waarom zo'n duur project zo grandioos kan mislukken.

Angst-cultuur bij SVB, buitenlandse programmeurs die niet (goed) begrepen waarvoor ze moesten programmeren, glashard liegen over functionaliteiten van het systeem die er volgens insiders niet eens in zaten, allerlei misstanden die rieken naar corruptie enz.

Kortom, de perfecte ingrediënten voor een mooie speelfilm

[SuperDre]

Juist ordina is exact hetzelfde al CAP, een grote concurrent. Enuh mijn ervaring is dat eigenlijk wel de meeste projecten 'spagetticode' is als men het over onleesbare code heeft, want wat voor de een perfect leesbaar en begrijpbaar is, kan voor anderen compleet onduidelijk zijn, vooral voor mensen zonder domeinkennis. Tuurlijk wordt er ook werkelijk een hoop 'slechte' code geschreven, maar goede en slechte code is vaak all in the eye of the beholder.

[Ahrnuld]

Vaak, maar niet altijd. Ik heb zelf ook code uit India mogen bekijken, en dat was wel degelijk objectief slecht te noemen. Gebrek aan kennis van OOP principes zorgde voor een hoeveelheid code die met gemak tot een fractie (1%) gereduceerd kon worden. Het was alsof de software was gebouwd door beginners die alleen een cursus hadden gevolgd waar je op de 'visual basic' manier van de jaren '90 leert programmeren. Een beetje klikken en slepen en dan alle code onder je controls hangen.

Misschien is in dat geval het ook niet handig om het over code te hebben, want dat wordt misschien geassocieerd met de inhoud van classes en functies, terwijl het juist misgaat bij het (niet) opzetten van de projectstructuur, gebrek aan vakkennis en het daarom nemen van verkeerde ontwerpbeslissingen.

[Reactie gewijzigd door Ahrnuld op 22 juli 2024 13:22]

[vbmot]

Dat ben ik niet met je eens. Onder goede code verstaan we goed onderhoudbare en makkelijk te testen code. Die twee gaan vaak samen als begrippen uit SOLID als single responsibility, encapsulation betekenis hebben voor een programmeur.

Goede code betekent niet dat je abstractie op abstractie stapelt, maar dat je functionaliteit logisch scheidt zonder dat afzonderlijke onderdelen allerlei side-effects op elkaar hebben. In de praktijk betekent dit dat de programmeur die een wijziging aan jouw code wil maken niet door duizenden regels code met allerlei geneste loops hoeft te lezen om de juiste plek te vinden.

[Y451N]

But it compiles!

[_Thanatos_]

Ach, als het ongekookte spaghetti is...

[SSDtje]

"Volgens Jetta Klijnsma, staatssecretaris van het ministerie van Sociale Zaken en Werkgelegenheid, bevat de geleverde software 'onvolkomenheden, en op sommige onderdelen is het complex, instabiel en moeilijk onderhoudbaar."

Heeft ze het bedrijf in het begin ook aangegeven dat ze het graag zo had willen zien uiteindelijk.

- De onvolkomenheden (welke dat dan moge zijn volgens haar)
- Zo simpel mogelijk wou hebben
- Zo stabiel mogelijk wou hebben
- En makkelijk om te onderhouden

Zo niet, dan is dit even lekker cashen zo...
Er vanuit gaan dat het bedrijf het allemaal zelf al wel zou weten dat ze het graag zo had gewild.
Nou zijn de genoemde punten natuurlijk vaak vanzelfsprekend, maar toch, er standaard maar vanuit gaan dat het bedrijf het wel zal weten is wel erg makkelijk.

Ik vond net nog een paar stukken van het Ministerie van Sociale Zaken en Werkgelegenheid weer die hier betrekking tot hebben:
- ICT bij de Sociale Verzekeringsbank
- Advies Implementatie MRS bij de SVB
- Afwikkeling overeenkomst voor ontwikkeling van het MRS bij de SVB
- Onderzoeken naar inhuur externen en cultuur bij SVB

Edit: nog twee stukken kennen vinden die hier betrekking tot hebben inmiddels, en deze nog even toegevoegd

[Reactie gewijzigd door SSDtje op 22 juli 2024 13:22]

[rilly]

Als ze de punten inderdaad vooraf wist, dan kon ze het systeem toch beter zelf bouwen als het onderhoudbaar en simpel moest zijn? Stabiel wordt wel weer een lastiger puntje, maar waarom zou je een extern bedrijf dat überhaupt dan laten doen?

[migchiell]

Omdat de SVB geen software-ontwikkelaar is.

[cdwave]

Misschien moeten ze daar dan nog eens over nadenken. Voor 40 miljoen kun je best een goed IT team permanent in dienst hebben.

[migchiell]

Maar als het systeem eenmaal staat dan heb je die ontwikkelafdeling de eerste jaren niet meer nodig, hooguit voor onderhoud maar niet meer op volle sterkte.

[incaz]

Want dat zijn dingen die je apart moet aangeven? Dit lijken me gewoon de basisfundamenten van elke opdracht. En het is dan aan de opdrachtgever om in te schatten wat daarvoor nodig is. Alsof je in een contract met een architect zou moeten zetten dat je huis ook daadwerkelijk moet blijven staan, en het dak waterdicht moet zijn. Ja, dat moet. Nee, dat hoeft niet vooraf gespecificeerd te worden.

[Wim-Bart]

Zelfs al zijn het de basis onderdelen. Ik heb zelf meegemaakt dat ik een specificatie op stelde voor een leverancier, de leverancier gejokt had over een aantal harde eisen met betrekking tot security en bij pentesten de boel op deze punten werd afgekeurd. Rapport komt bij management, management beslist, gewoon doorgaan met product. Daar sta je dan en dan nog op je donder krijgen dat je te streng bent geweest. Gelukkig mezelf van project kunnen halen en straks komen ze weer zoals altijd op hun knieën bij me om het te fixen.

Soms vraag ik me af wat voor zin het heeft om adviezen uit te brengen wanneer managers binnen organisaties het negeren. En zolang managers niet persoonlijk gestraft worden blijft dit zo.

[Anoniem: 636203]

Managers moeten verboden worden. Alle managers dienen ontslagen te worden, ze creëren alleen maar problemen in plaats van deze op te lossen.

[Wim-Bart]

Dat zeg ik niet, maar ik heb beslissingen gezien op rvc niveau van bedrijven waar je je van kan afvragen waar ze mee bezig zijn. Soms heb ik echt het gevoel dat ze op de golfclub zitten en dat hun vriendje die een computerwinkeltje op de hoek heeft en al met moeite Windows kan installeren als adviseur in de arm nemen.

[Blokker_1999]

Wil je nu echt zeggend at als je niet specifieert dat je stabiele software wenst dat men gewoon een product mag afleveren dat elke 5 minuten vastloopt? Dat als je niet specifieert dat onderhoud eenvoudig moet zijn men een product mag afleveren dat je een downtime van een week geeft telkens je die upgrade wil uitvoeren omdat je 500 paginas met instructies moet doorworstelen op 35 verschillende servers? Dat als je het niet specifieert de mogelijkheid om af te sluiten ergens in het helpmenu mag verstopt worden?

Want dat is wat je hier aangeeft. Een beetje common sense is toch wel op zijn plaats mag ik hopen.

[SSDtje]

"Want dat is wat je hier aangeeft. Een beetje common sense is toch wel op zijn plaats mag ik hopen."

Zeker, ikzelf steek er dan ook netzo in.
Maar blijkbaar moet dit, anders was het niet zo gelopen als het nu is lijkt me, hoe krom het ook mag klinken.

[gjmi]

Kom op zeg. Er is ook iets als vakmanschap.
Als jij je huis laat schilderen, wil je toch ook dat het er overal even strak en mooi uit ziet? Of moet je de schilder van te voren vertellen dat ie niet op de ramen mag knoeien en dat je geen zakkers wilt zien?

Het stomme van de overheid is dat ze steeds weer bij dezelfde groep aan klopt en steeds weer projecten fout gaan.

[Nogne]

En nu nog het geld terug van alle andere gefaalde ICT projecten. Ik vind dat het rijk dit vaker moet doen, want wij betalen al genoeg belasting. Als jij een bedrijf inschakelt en dat bedrijf levert niet wat is afgesproken, dan ga je ook je geld terugvragen.

[Kalief]

Dat 'wat is afgesproken' moet dan ook wel duidelijk zijn afgesproken oftewel gespecificeerd en dat gebeurt niet want daar heeft de opdrachtgever de benodigde kennis niet voor, die moet ook weer van een externe consultant komen. En dan moet de opdrachtgever ook nog eens niets meer wijzigen tijdens het project want dan kan de uitvoerder zijn wanprestatie daar weer op afschuiven.

En er moet een soort van boetebeding in het contract zijn opgenomen. En dat is wat mij hier nog het meest verbaast: hoe hebben ze CAP in 2006 zover weten te krijgen akkoord te gaan met een boetebeding? Het was nog geen crisis, ze zaten nog niet om werk verlegen.

[Nogne]

Dat het duidelijk moet zijn afgesproken ben ik geheel met je eens. Het lijkt mij wel lastig als bedrijf indien je geen tot weinig ICT kennis hebt, maar duidelijke afspraken is voor beide kanten wenselijk.

En ik heb geen kennis van deze materie dus ik zie dit echt als een leek, maar hoezo moet je een clausule hebben over boetedoening? Als partij A zegt dat ze dit kunnen leveren voor een X bedrag en ze leveren het niet. Dan heb je toch recht om je geld terug te vragen, of werkt dat met aanbestedingsprocedure’s anders?

[adje123]

Oooooh man. Hoevaak ik dit soort dingen tegen kom bij klanten. Ik zou er een nieuwssite voor kunnen oprichten. Vaak nemen bedrijven een opdracht aan en leveren dan stukjes op(Scrummothode). Echter houden ze vaak geen rekening met dat de gebruikte technieken snel achterhaald of kwetsbaar zijn. Gevolg, na oplevering herstelwerkzaamheden uitvoeren.

[SuperDre]

Tja, maar ik denk dat jouw concullega's dat ook wel zullen zeggen over de projecten die jij aflevert als zij na jou het project moeten overnemen. Ik kom het ook regelmatig tegen, probleem is ook gewoon vaak dat developers allemaal hun eigen visie hebben van wat goede en slechte code is, it's all in the eye of the beholder. Ook ikzelf ben daar niet van uitgesloten. Maargoed, als ik tegen een met specificaties vastgelegde webservice moet werken en ik krijg verkeerde dingen terug waarna ik dan de opmerking krijg van de bouwer, 'wat verwacht je dan terug te krijgen', dan heb ik het wel gehad met zo'n developer, zeker als je dan hebt uitgelegd wat de specs aangeven wat er terug moet komen, men zegt 'probeer het nu opnieuw', en dan klopt er nig niets van, dan vraag ik me toch af waar men mee bezig is.

[veltnet]

Daarom is het ook belangrijk dat we als developers kritisch naar elkaars werk blijven kijken en dat je het aan je collega's meldt (opbouwende kritiek) als code niet deugt of niet helemaal 100% is.

Bij bedrijven waar mijn collega's kritisch naar mijn code kijken wordt de kwaliteit van mijn code vele malen beter dan bij bedrijven waar niemand naar mijn code kijkt. Veel developers kunnen hele mooie en goede dingen bouwen als hun omgeving ook stimuleert om dat te doen.

[SuperDre]

Daar ben ik het helemaal mee eens, maar de visie van developers kan ook heel erg afwijken van wat goede/leesbare code is en wat niet. Een goed voorbeeld is bv het gebruik van lambda expressies, een college vond dat veel duidelijker en maakte daar constant gebruik van, terwijl ik dat juist helemaal niet leesbaar vond (op de manier zoals hij het gebruikte), ja ze zijn handig maar in feite zijn ze niets meer dan naamloze functies (en dan kom je dus soms eigenlijk meer uit op vergelijkbare code als 1 lange functie met een hoop loops).

[SSDtje]

Compleet Off-Topic

"Vaak nemen bedrijven een opdracht aan en leveren dan stukjes op(Scrummothode)."

Maar moest hierdoor spontaan denken aan EA-games

[henk1994]

Maar wat dan? In 1 keer het hele programma opleveren? En dan erachter komen dat het niet is wat je wilt?

[killer_mac]

Allereerst is dat geen echte SCRUM methode.

Want als SCRUM daadwerkelijk wordt toegepast is er een definition of DONE waar de architecturele aspecten in opgenomen zijn.. Elke SCRUM team dient hier aan te voldoen, anders mag de sprint niet worden opgeleverd.

Vaak genoeg wordt SCRUM gebruikt als cover voor Trail on Error, en daar is het zeker nooit voor bedoeld..
Ook in SCRUM moet de opdrachtgever (Productowner) weten welke functionaliteit gewenst is en waar het aan dient te voldoen.
Te samen met het Development team..

[wm1234]

Het beeld zou toch wel genuanceerd moeten worden. Als buitenstander verbaasde ik mij ook elke keer over deze berichten. Als insider begrijp ik nu heel goed, hoe projecten zoals deze mislukken. Bij de overheid willen ze bij een aanbesteding vaak meerdere partijen hebben voor de ICT (Infra en ontwikkeling gescheiden). Dit zorgt vaak al voor niet werkende VDI's, beperkte data omgevingen (lees: niet werkend of slecht in elkaar gezet). Slechte planning rondom hoofd en deelprojecten. De klant die niet op tijd aanlevert, lang doet over beslissingen. Politieke belangen en budgetten per jaar, macht onderling in de departementen en soms zelfs corruptie en zelf verrijking, vriendjespolitiek. Requirements die continue worden aangevuld (niet zoals afgesproken). De kennis ontbreekt vaak bij de overheid, personeelstekort. Noem maar op. Grote ICT bedrijven hebben geen bewuste insteek om hun zakken te vullen. De meeste mensen die ik tegenkom, werken voor een normaal salaris en willen graag hun werk goed doen (net zoals de rest van Nederland). Alleen als je in zo'n situatie komt, ga je ook niet de boel lopen opstoken om dingen goed aan te leveren vanuit de klant (de klant bepaald ten slotte).

[VulcanSnow]

De klant bepaalt inderdaad, maar de opdrachtnemer moet wel meedenken en de klant op de gevolgen attenderen. Vaak gebeurt dit niet om zo meerwerk te kunnen rechtvaardigen ... Onethisch. Een groot IT bedrijf heeft als doel: winsten maximaliseren om de aandeelhouders tevreden te stellen.

[Jonathan-458]

Blijf het toch apart vinden dat bijv Capgemini niet instaat is om een goede basis te ontwikkelen zodat er op langer termijn gewoon goed door ontwikkeld kan worden, software is infeite ook nooit klaar.

Het is echter wel een stap in de goede rochting dat Ontwikkelaars aansprakenlijk kunnen worden gesteld.

Overheid en ICT gaat overal nogsteeds te vaak fout, niet altijd de ontwikkelaars schuld echter zou de ontwikelaar stricter en realistischer moeten opstellen tegenover de overheid om dit te voorkomen.

[Anoniem: 890159]

Blijf het toch apart vinden dat bijv Capgemini niet instaat is om een goede basis te ontwikkelen zodat er op langer termijn gewoon goed door ontwikkeld kan worden

Cap wil dat soort werk tegenwoordig perse uitbesteden in India, en Cap India heeft al vaker bewezen slecht werk af te leveren.

[Zarhrezz]

Fun fact: alle aanbesteders doen aan off-shoring. Als je dat niet doet, komt je bod namelijk altijd zodanig hoog uit, dat je overheid jou bod nooit zal accepteren. Je kunt best Europese ontwikkelaars willen in die trajecten, maar dan moet de overheid wel accepteren dat de kosten van de aanbestedingen een factor 2-3 hoger uit gaan pakken. En dat willen wij als belastingbetalers dan weer niet ophoesten.

[Anoniem: 162126]

Ik vraag me af wat de dozenschuivers met deze uitspraak gaan doen. Gaan ze iets aan de kwaliteit doen of gaan ze zich juridisch beter indekken? Of gaan ze door op de oude voet en nemen ze deze kosten voortaan voor lief. Of gewoon als risico opnemen in de offertes/facturen die ze versturen.

[Technomania]

Is het niet zo dat bij complexe systemen het eigenlijk al achterhaald is voor men klaar is met de ontwikkeling daarvan? (vrij kort door de bocht)

[FreezeXJ]

Als je het even in elkaar knutselt wel ja, want dan is het zo hard-coded dat het maar 1 ding kan doen. Capabele programmeurs doen dat al sinds de maanlandingen niet meer, maar als het vlugvlugvlug moet en er een manager boven zit krijg je dat wel eens... en ja, dan kost aanpassen meer dan het opnieuw schrijven.

[Technomania]

maar als het vlugvlugvlug

En dat zal wel moeten. Als je ziet hoe het betalingssysteem is veranderd sinds de maanlanding.

[gjmi]

Nee (vrij kort door de bocht)
Als je van te voren weet dat je een complex systeem bouwd, kun je er rekening mee houden dat bepaalde zaken achterhaald raken en die bijvoorbeeld als laatste doen. En iets van flexibiliteit inbouwen. Een groot software bedrijf zoals deze moet dat in kunnen schatten.