Overheid en ict, het is niet altijd een gelukkig huwelijk. In mei is de aftrap van weer een parlementaire commissie die ditmaal het ict-falen bij de overheid onder de loep moet nemen.
Het globale plaatje: de overheid wil iets automatiseren, en dat wat begint als een zoektocht naar een leuk functioneel gezinsautootje groeit uit tot vraag naar een limousine met ongekende hoeveelheden toeters en bellen, de wagen moet plots ter land, ter zee en in de lucht kunnen functioneren, en het pakket met eisen en wensen wordt ter aanbesteding aan de markt aangeboden. Likkebaardend denkend aan de vele miljoenen die er te verdienen vallen, duikelen de consultancybureaus over elkaar heen om de klus in de wacht te slepen.
Daarbij moet uiteraard gezorgd worden voor een zo laag mogelijke prijs, want bij aanbesteden is de prijs altijd een van de onderscheidende criteria. Die zo laag mogelijke prijs is toch nog even flink slikken voor de overheidsdienaren, die uiteraard door een wat al te roze bril naar de mogelijkheden gekeken hebben. Maar goed, het moet dan maar. Met al die toeters en bellen kunnen we tenslotte álles, maar dan ook álles, doen wat we de komende vijfentwintig jaar denken te moeten doen. Vervolgens gaat de winnaar aan de slag.
De ellende
En dan begint de ellende. Uiteraard is het om te beginnen onmogelijk het systeem wat beschreven wordt in het pakket eisen en wensen tegen de afgesproken prijs te bouwen. Maar spoedig wordt het erger: bij opleveren van de eerste delen van het systeem blijkt dat het helemaal niet mogelijk is het werk ermee te doen wat gedaan moet worden.
Dan begint het gevecht. ‘Dit doet niet wat wij willen', roepen de overheidsdienaren, ‘het moet niet dít, maar juist dát doen.' ‘Maar dát staat niet in de eisen en wensen', roepen de bouwers. De exegese van de eisen en wensen begint, ieder lettertje en iedere komma wordt gewogen. De belangen van opdrachtgever en opdrachtnemer, die idealiter parallel zouden moeten lopen, staan recht tegenover elkaar.
De opdrachtnemer zit al met een systeem wat tegen een veel te lage prijs gebouwd moet worden. Daar mag geen millimeter extra bovenop komen. En de opdrachtgever heeft het contract voor het prijzige systeem al getekend, dus dat moet wel werken. Wanneer niet 100 procent glashelder in de kleine lettertjes van het contract staat dat het zo moet als de opdrachtgever wenst, trekt die aan het kortste eind.
Er zal iets bijgebouwd moeten worden. Aanvullingen op de eisen en wensen. En dat kost geld. Want nu wil de aannemer, die toch al nauwelijks winst kan maken op het staande contract, wel geld verdienen. En dus wordt het systeem duurder en duurder, en complexer en complexer. Waardoor een fiasco nooit een goedkoop fiasco wordt, maar altijd een duur fiasco.
Overschatting
Wat gaat er nu mis in dit proces? Een paar dingen. Ten eerste gaat het hele proces van aanbesteden uit van de schromelijke overschatting dat mensen in staat zijn van tevoren op papier op te schrijven wat een groot en complex systeem zou moeten kunnen doen. Dat kunnen mensen niet, zelfs de besten niet. Systemen bouwen, zeker nieuwe systemen die dingen moeten doen die niet eerder gedaan zijn, gaat met vallen en opstaan. Gaandeweg leren, aanpassen, verfijnen, dat is de enige manier.
Zelfs met dingen die we vaak doen, zoals kantoren en huizen bouwen, is het al moeilijk genoeg voor ervaren architecten en aannemers om op prijs en afspraak te werken. Dingen die niet eerder gebouwd zijn (de Noord-Zuid lijn, de Chunnel, de Betuwelijn) lukken zelden of nooit tegen een vaste prijs op een vaste tijd. En ict-systemen zijn nagenoeg altijd nieuwe systemen, die nooit eerder gebouwd zijn, en die dingen moeten kunnen die niet eerder gedaan zijn.
De maandelijkse totaallijst maken, dat kunnen we wel tegen een vaste prijs. Eerlijk gezegd: wat vroeger de automatiseerder deed, doet de gebruiker nu zelf wel in Excel. Maar een nieuw systeem moet tegenwoordig kunnen werken met social media, of geolocatie, of big data: nooit eerder gedaan. Ict is (bijna) altijd nieuw.
Ten tweede gaat aanbesteden ervan uit dat er objectieve keuzecriteria vast te stellen zijn om de beste aannemer te selecteren. Dat is maar deels zo. Systemen bouwen is mensenwerk, en de beste systemen worden gebouwd wanneer de communicatie tussen bouwers en gebruikers goed is. Wanneer bouwers meedenken met de gebruikers, en wanneer gebruikers meedenken met de automatiseerders. En juist menselijke communicatie is nauwelijks meetbaar, anders dan door te communiceren.
Samenwerken
Het beste recept voor een succesvol systeem: werk samen met een team waar eerder succesvol mee samengewerkt is. En dat kan bij aanbesteden niet, omdat de beste partner op papieren criteria wordt gekozen, met papieren antwoorden, en een technocratische rekensom waar ‘de beste' uit rolt.
Wat werkt het best in de ict: werk iteratief, met kleine releases, wijzig de specs wanneer nodig, kies een team dat goed samenwerkt, communiceer goed. Aanbesteden op basis van vaststaande specificaties staat daar haaks op.
Wat de parlementaire onderzoekscommissie niet na moet laten, is eens kritisch te kijken naar de veelal volslagen idiote aanbestedingsregels die via Europa en Den Haag aan de ict worden opgelegd. Gelukkig dringt ook in Europa het besef door dat er dingen moeten veranderen, en is de wetgeving rond aanbesteden in verandering. En wellicht biedt de huidige wetgeving ook wel wat ruimte om er intelligenter mee om te gaan dan nu gedaan wordt. Openbaar aanbesteden staat haaks op alle zinnige ict-praktijken. Als de politiek een ding moet doen, is het een einde maken aan het aanbestedingsdrama.
Marc de Graauw, freelance consultant
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” – John Gall.
Nou Marc, ik ben het geheel met je eens. Ook nog eens leuk geschreven!
Overigens zie ik wat je beschrijft ook bij andere takken dan overheid, het is een fundamentele fout die je vaak ziet bij het uitbesteden van werk per “bieding”.
Zoals ik eerder heb voorgesteld dient er een app store te komen voor overheid. Iedere aanbieder die aan de eisen voldoet mag zijn app aanbieden in de store. En per gemeente/overheidsorgaan/afdeling kunnen de juiste apps ingezet worden.
Waarom worden miljarden verbrand met eigen wielen uitvinden?
Dus nogmaals, leuk artikel, bedankt.
Dit artikel gaat m.i. niet zozeer over aanbesteden, maar over de onmogelijkheid van overheid en leverancier om goed samen te werken bij ICT-projecten. Daar zijn aanbestedingsregels deels schuldig aan.
Ik ben het overigens geheel eens met de strekking van het artikel, inclusief de aanbevelingen als: “werk iteratief, met kleine releases…”etc.
Het lijkt voor de overheid vaak ook problematisch om intern op een lijn te komen. Dienst A wil een systeem, dienst B moet er ook gebruik van maken, evenals dienst C. Geen van de diensten wil zijn eigen werkwijze aanpassen (dat doen die prutsers van de andere diensten maar). Gevolg een cumulatief pakket eisen dat het te bouwen systeem onnodig gecompliceerd en duur maakt.
Toch even terug naar aanbestedingen: dat is idd vaak een drama. Bijv. wat referenties betreft. Dienst X, gemeente Y of overheidsinstantie Z moeten aanbesteden. De waarde van de opdracht is 1500K. Bijv. een inhuurmantel voor de komende 2 jaar. Voorwaar een heel bedrag voor dienst X. De overeiverige ambtenaar stelt een pakket eisen op waar leveranciers aan moeten voldoen. Eis: 20, 30 soms zelfs 50(!) referenties, vaak met handtekening van de referent.
De overheid wil graag iets aan lastenverlichting doen, maar vaak niet als het gaat om het aanbesteden van een eigen opdracht. Het leukste zijn die overheidsinstellingen die zelf ooit tig referenties hebben gevraagd in hun eigen procedure, maar zelf “uit principe” nooit als referent willen optreden.
En aan dat drama zie ook ik graag een einde komen.
De strekking van het artikel gaat nog wel verder dan alleen ICT projecten. Bij veel meer aanbestedingen gaat het mis. De ‘drama’s’, die Peter Verkade aandraagt, zijn evenmin voorbehouden aan ICT aanbestedingen.
Veel ervan worden ronduit amateuristisch uitgeschreven en veel aanbieders, uit angst voor willekeur in krappe tijden, durven er niet tegen te protesteren. Tot het te laat is (voor de rechter).
Ik ben het met Henri Koppen eens, dat de oplossing niet in een toename van het aantal regeltjes ligt. Het moet eenvoudiger.
Ook moet het makkelijker worden om prutsers die er niets van bakken, uit te sluiten.
Zeer goed artikel van Marc en volledig mee eens!
Let op dat hij expliciet zegt: communiceer goed…komt toch weer die communicatie om de hoek kijken!
Inderdaad een goed verhaal wat door de schrijfstijl en stellingen lekker is om te lezen. Ik geloof echter in een andere oplossing die zeker aansluit op het feit dat het onmogelijk is om op te schrijven wat gebouwd moet worden.
Ik geloof erg in de kracht van simulaties. Dat betekent op schermniveau de functionaliteit uitwerken zonder code te maken. Betrokken team is multidisciplinair dus er is gelijk een technische toets. Je kan dan snel en met veel draagvlak bepalen wat het systeem moet gaan doen. Daarna kan je de realisatie starten. Dus gewoon aanbesteden op parameters zoals kennis, kwaliteit en prijs.
Uiteraard kan je in sommige omgevingen ook direct bouwen, zijn er redenen genoeg die je wilt verzinnen om de oude manier te hanteren en kan je meer focussen op hergebruik voor andere overheidsonderdelen.
Maar vanuit ervaring weet ik dat succes dichterbij ligt als je een applicatie eerst kan voelen voordat je gaat bouwen. Eigenlijk zou de overheid een ontwerpdepartement moeten hebben die snel via simulaties de voorbereiding doet voor de aanbestedingen. Scheelt een hoop ellende!
Het simuleren op schermniveau is voorbehouden aan applicaties die data-invoer door gebruikers gericht zijn of opvraag gericht zijn zoals internetbankieren of orderverwerking. Veel applicaties zijn dat juist niet. Ipv simuleren zou dan eigenlijk gewoon direct bouwen beter uitpakken door na het snel bouwen van een niet volledig systeem dit te evalueren om vervolgens de code weg te gooien en opnieuw te beginnen. Nu weet men veel beter wat men wil en wat consequenties kunnen zijn. Dit staat haaks op de aanbestedingsprocedure. Voor IT systemen (en welke zijn niet complex tegenwoordig) werkt aanbesteding eenvoudigweg niet. Ook is aanbesteden per definitie duurder omdat vooral bij overheden vrijwel altijd een rechter er aan te pas moet komen en die kosten komen er gewoon bovenop. Ten slotte wordt een hele grote factor vergeten in vrijwel alle beoordelingen van verkeerd uitgepakte IT systemen en dat is het vakmanschap. Vrijwel 95% van de werkzame IT’ers (incl management) heeft niet de juiste papieren. Daardoor heeft vrijwel niemand dezelfde achtergrond en vakbekwaamheid. Dit is destijds versterkt door het weggeautomatiseerde personeel en de geflopte studenten massaal in te zetten bij de grote vraag naar IT personeel. Helaas is mijn enige advies “leer een vak” dan kan je later altijd nog de IT in, en meedoen in de waanzin van de IT wereld, mocht je dat willen.
In mijn ogen is het beschrijven van de functionaliteit van het gewenste systeem wel degelijk een goed startpunt van een aanbesteding. Na het meten van de omvang van de functionaliteit (b.v. in functiepunten) en het toepassen van historische data (bv. die van de ISBSG) kan in ieder geval een indicatie worden gekregen van de te verwachten kosten en doorlooptijd en kan dus de haalbaarheid van de business case worden vastgesteld. Met deze informatie kan ook een ‘realistische range’ worden vastgesteld,met een ondergrens voor wat betreft het mogelijk aantal uren (of prijs) dat een leverancier kan besteden.
Bij de aanbesteding zouden leveranciers die menen onder die ondergrens aan te moeten bieden moeten afvallen, tenzij men een goed verhaal heeft. Vraag daarom de productiviteit uit (b.v. aantal uur per functiepunt) en laat de leverancier die onderbouwen met objectief verifieerbare data. Voor een leverancier die op CMMI level 3 acteert zou dit geen probleem moeten zijn.
Keuze van een leverancier puur op prijs leidt tot de debacles, zoals in het artikel genoemd. Het gaat om het realiteitsgehalte van de aanbieding, niet de prijs!
De uitvoering van het project kan vervolgens wel prima op een agile manier gebeuren, maar dan moet het wel duidelijk zijn dat als de doorlooptijd, de kwaliteit en de kosten vast zijn, de enige variabele de hoeveelheid functionaliteit is. Bij agile projecten wordt weliswaar eerst de belangrijkste functionaliteit gerealiseerd, maar het is uiteindelijk maar afwachten wat er wordt opgeleverd als het geld op is en de einddatum is bereikt.
Toevallig geef ik a.s. woensdag een webinar over dit onderwerp. Mocht iemand de slides willen, laat het me dan even weten.
@Marcel: Je hebt helemaal gelijk met simulaties. Werk zelf ook graag met quick & dirty prototypes. Eerst de functionaliteit goed krijgen, en dat gaat alleen via ervaring, niet met louter stapels papier.
@Henri, Peter, Peter, Robert: dank. Klopt overigens ook dat veel (de meeste?) aanbestedingen slecht uitgewerkt zijn, met eisen en criteria die de kern niet raken. En vaak erg veel verlangen van de biedende partij. Soms geven aanbesteders tegenwoordig een vergoeding aan bieders die het niet worden. In de bouw is een ’tekenvergoeding’ voor aanneemrs die het niet worden gebruikelijk. Zou het in de IT ook moeten zijn.
Marc,
Een prima en erg goed leesbaar artikel die voor wat betreft aanbestedingen de spijker op de kop slaat. Echter een aanbesteding is een reflectie van de invulling van bepaalde wensen. Als deze reflectie niet goed tot stand komt kun je trekken wat je wilt aan de uitvoerig hiervan, maar kom je niet tot een goed resultaat. Trouwens, nog zo’n retorische vraag, wat is een goed resultaat: dat wat de ‘hoog over’ organisatie wil, dat wat de operationele of uitvoerende organisatie wil of de uiteindelijke gebruikers? Over welke stakeholders praten we dan? Veel veranderingen op dit moment leiden tot reorganisaties en dus niet altijd tot ‘happy users’.
De veranderingen die op dit moment spelen bij de Rijksoverheid zijn dusdanig ingrijpend dat het (bijna) onmogelijk is om alle partijen tevreden te stellen. Aan de bovenkant worden er mega veranderingen voorbereidt waar men aan de onderkant in veel gevallen niet goed van op de hoogte is (communicatie). Veranderingen die aan de ‘onderkant’ worden aangepakt kunnen haaks staan op de plannen aan de ‘bovenkant’. Maar we moeten ons natuurlijk ook realiseren dat het een enorme uitdaging is om de duizenden miljoenen aan euro’s die worden uitgegeven aan ICT projecten goed te stroomlijnen. Dit lukt je niet met incrementeel kleine stapjes uitvoeren of met schermen voor gebruikers uit te werken. Deze mega verandering is mijn inziens alleen mogelijk met een goede blauwdruk, wat Daan Rijsenbrij al tien jaar probeert aan de man te brengen. Deze mega veranderingen kunnen alleen plaats vinden onder architectuur, je kunt ook de Randstad niet herinrichten zonder plan. Op het gebied van Rijksoverheid ICT architectuur valt er nog wel een en ander te verbeteren, deze is in veel gevallen te technisch en operationeel ingestoken.
Een ander belangrijk aspect om de reflectie van verandering goed te kunnen doen en ook uit te voeren is de governance en mandatering rondom verandering. Hierbij speelt mee dat teveel partijen veranderingen kunnen beïnvloeden zodat de uiteindelijke doelstellingen niet gehaald (kunnen) worden. Dit geldt zowel voor de financiële als project-/programma mandateringen c.q. governance. Er is een eenduidige sturing op verandering nodig die dan ook alle mandaat heeft om dit tot uitvoer te brengen.
We zullen nog wel een vijf tot tien jaar moeten wachten tot de compacte Rijksoverheid zijn beslag vindt en de noodzakelijke vernieuwingen en reorganisaties van de ICT huishouding uitgevoerd zijn, met de gewenste honderden miljoenen aan lagere totaal kosten.
Aanbesteden is/was bedoeld om het speelveld te levelen zodat iedereen mee kan doen, daar een einde aan maken lijkt me geen goed idee. Dat werkt vriendjespolitiek in de hand waar, gezien de rechtszaken die regelmatig de krant halen, nu al sprake van lijkt te zijn. En een bedrijf dat reeds binnen is en meedingt heeft, afhankelijk natuurlijk hoe de verstandhouding is meestal een voordeel. Niet zelden zijn aanbestedingen dan ook ‘geheel toevallig’ naar een bepaalde leverancier geschreven.
Zeggen dat ICT en overheid een slecht huwelijk is lijkt me ook een open deur omdat de overheid juist de ICT vaak uitbesteed heeft. Soms zijn er wel een dozijn partijen die ieder verantwoordelijk zijn voor een kavel en zelfs het aanbestedingsproces is vaak uitbesteed. Maar hoe zou het beter kunnen, minder kosten en wel het resultaat opleveren dat gewenst is? Het recept samenwerking klinkt inderdaad goed, zolang opdrachtgever maar wel de regie blijft behouden.
Dat betekent in praktijk dat de kennis die eerder verdwenen is door uitbesteding weer terug verkregen moet worden. Want om het speelveld te levelen is het handig als ook de spelers gelijk zijn. Nu is het vaak een wedstrijd tussen amateurs, gemengd met semi-profs tegen beroepspelers die alle trucjes kennen. Aanbesteding moet dus niet een spel zijn tussen (externe) juristen en beleidsmedewerkers zonder affiniteit met IT maar tussen vakmensen die knollen van citroenen kunnen onderscheiden.