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
Als tot nu toe via aanbestedingstrajecten de verkeerde partner werd gekozen, en projecten op een financieel fiasco uitliepen, hoe kun je dan stellen dat je voor succes moet samenwerken met een team waarmee al eerder succesvol is samengewerkt? Daar zit iets tegengestelds in. Vooral ook omdat op een of andere wijze toch meerdere aanbieders een kans moeten krijgen om de opdracht binnen te slepen. Op welke gronden je dan moet vaststellen dat een van die partijen, ondanks de fiasco’s, toch tot een succesvolle samenwerking in staat was is een lastige. Bovendien wordt impliciet de rest van het veld voor de toekomst uitgesloten van deelname.
En dat brengt mij op de gedachte dat de enige manier om van die fiasco’s af te komen en verzekerd te zijn van een goede samenwerking tussen teams in grote lijnen de volgende is:
•Organiseer je business,
•Beschrijf op eenduidige wijze je processen, leg deze vast en identificeer de generieke elementen;
•Zorg voor coördinatie van en regie op (het vaststellen van) eisen en wensen en bepaal welke van toepassing zijn op de generieke elementen en welke niet;
•Zorg voor een duidelijke businesscase;
•Organiseer de ICT;
•Haal vervolgens de ICT weer in eigen huis, al dan niet via een (overheids)poolconstructie, waardoor kennis wordt opgebouwd van – en behouden blijft voor de betrokken organisaties;
•Bouw eerst de generieke elementen en zorg dat ze werken;
•Bouw vervolgens uit met de specifieke elementen.
Op die manier moeten we toch tot een professionele, goed geautomatiseerde overheid kunnen komen, lijkt mij. Van dat negatieve beeld van ambtenaren moeten we maar eens af.
@edekkinga: Die rechtszaken lopen overigens ook vaak in gevallen waar wel degelijk wordt aanbesteed, de ‘bescherming’ die aanbesteding biedt is dus maar zeer beperkt. Zoals je terecht opmerkt worden bijvoorbeeld veel aanbestedingen op maat van de beoogde winnaar geschreven.
Dat een bedrijf dat reeds binnen is (en dus de business al kent) in het voordeel zou zijn (tenminste bij goed resultaat) is zeker waar, maar dat is juist wenselijk. Ieder bedrijf dat ik ken dat niet hoeft aan te besteden werkt bij voorkeur met bekende partners, waarmee succesvolle samenwerking bewezen is in het verleden. Dat is goed entrepreneurschap. Natuurlijk moet een grote partij als de overheid af en toe verder kijken, en ook nieuwe partijen toelaten. Volgens mij is echter verplicht alles (boven bepaald bedrag) laten aanbesteden een verkeerd instrument.
@Harold: Ik ben helemaal voor software metrics, gebruik zelf ook vaak functiepunten om orde van grootte van kosten te bepalen. Mijn ervaring is dat indicatieve FP vaak voldoende is, en detailuitwerking hetzelfde cijfer geeft. Gebruik dat zelf echter alleen maar als één van de instrumenten. M.n. bij inzet nieuwe technologie zegt het minder.
Insteek wel Agile, kosten+doorlooptijd fixed, functionaliteit niet, is interessant. Heb dat in de praktijk nog niet voorbij zien komen bij aanbesteding (hoogstens voor delen ervan).
Zie je slides daarover graag.
Allereerst mijn complimenten voor het stuk. Lekker vlot geschreven en zeer herkenbaar. Het correct en zonder enig financieel risico beantwoorden van aanbestedingen begint steeds vaker onmogelijk te worden.
Aanbestedingen waar om minimaal 5 a 10 referenties gevraagd worden komen steeds vaker voor. En dan komen er ook vaak extra regeltjes zoals omvang, toegepaste technologie en aanschaf/implementatie datum bij kijken.
Hier mee wordt bijna iedereen gedwongen om te gaan samenwerken om aan de eisen te kunnen voldoen. En steeds vaker kom ik partijen tegen die zelf weinig tot geen technische kennis hebben maar wel over een groot netwerk van IT partijen beschikken waar mee zij kunnen samen werken.
Een partij met weinig tot geen kennis kan dus als hoofdaannemer optreden en zeer creatief alle onderaannemers tegen elkaar uit spelen.
Je ziet dus steeds meer een verandering optreden dat er steeds vaker inkoopbureau’s grote aanbestedingen winnen. En dit komt de kwaliteit en verantwoordelijkheid niet altijd ten goede.
De inschrijver heeft altijd een uitdaging met het binnenhalen van dit soort opdrachten. Als hij deze ook binnen gehaald heeft dan begint pas het feest. Dat komt o.a. door:
– The Day After: De huidige omgeving wordt geprobeerd op papier en door RFP en daarna NVI (v1, V1.1, V1.2. V1.3 etc) beschreven te worden.De vraag is hoe kun je als opdrachtgever zo`n complexe omgeving zoals bij overheid(instellingen) op papier beschrijven! En hoe groot is de kans dat je als aannemer deze omgeving in het echt dezelfde gaat meemaken zoals deze op papier stond! Laten we hopen wanneer je de opdracht gewonnen hebt, beperkt aantal lijken uit de kast zien komen.
Steeds meer voorgekookte oplossingen worden in de aanbestedingen opgenomen. Dit i.p.v. de benodigde functionaliteit. De opdracht gever moet weten wat klantorganisatie nodig heeft. Zij moeten tevreden zijn en niet de ICT afdeling. Dit zorgt voor allerlei wijzigingen die later plaats zullen vinden (Exceptions)
Wanneer de situatie duidelijk in RFP weergegeven wordt dan zal transitie van RFP naar oplossing makkelijker en met hoge kwaliteit verlopen. Dit kan veel wijzigingen en tegenslagen voorkomen.
– De prijs: de prijs heeft meestal een hoog scorepercentage. Op de hardware zit een kleine marge en soms niks! De opdrachtgever probeert deze ook op diensten krijgen. Maar hoe reeel is dit?
– De magere winst die overblijft (als het overblijft) wordt ook afgesnoept door eisen zoals “ Social Return”. Opdrachtnemer wordt verplicht om hier iets aan te doen anders krijgt hij of een laag score of een boete later als hij de opdracht wint en dit niet kan waarmaken.Maar er zat al weinig winst in deze opdracht, hoe moet ik deze boete betalen?
– Referenties, omzet en winst, hoge schadebedragen en nog wat andere eisen zorgen ervoor dat de kleine partijen uitgesloten worden van deelname. Hoe eerlijk is dit beleid?
Een opdracht die door aanbesteding gewonnen is lijkt op een waterbed! Als je hierop drukt dan zet het daar op! En dit gaat in dit traject ten koste van kwaliteit en dus het eind resultaat.
Een uitstekend en duidelijk verhaal. Eindelijk is een artikel wat helder weergeeft wat de belangrijkste oorzaken zijn van het mislukken van (ICT-) projecten. Ik ben het geheel eens met de inhoud van dit artikel. Ik hoop dat onze Tweede Kamerleden hier ook eens nota van nemen als ze parlementaire onderzoeken gaan uitvoeren. Als ICT-er is mijn ervaring dat je maximaal negentig procent van de wensen en eisen kunt vastleggen, maar als opdrachtgever en opdrachtnemer elkaar voor de overige tien procent niet kunnen vinden, op basis van een win-win situatie, dan is ieder ICT-project gedoemd om te mislukken.
@marc
Politiek willen we misschien een kleinere overheid maar als belastingbetaler heb ik liever een efficiënte. De verschillende publieke opdrachtgevers zien ICT vaak nog niet als strategisch of ‘business enabler’, dit ondanks schrijven van WRR over de iOverheid. Natuurlijk zal een partner, die bekend is met de interne gang van zaken en op de hoogte van de details een heleboel problemen vooraf en achteraf kunnen voorkomen. Maar overheid kan deze rol ook zelf nemen door op tactisch en strategisch niveau de regie te behouden en eigen vakmensen te hebben.
Onbekend maakt onbemind en dat speelt zeker als je aanbesteding los laat want dan komt meestal de wet van de remmende voorsprong ervoor in de plaats. Een monopolist zal veel minder innovatief zijn maar kan door zijn positie entrepeneurs de toegang tot de markt belemmeren. Je ziet dit bij de digitale dienstverlening aan burgers maar ook weer met introductie van ‘papierloos werken’ waarbij opmerkelijk vaak voor iPads gekozen wordt. Met laatste kun je misschien nog roepen dat applicaties ruimte bieden maar uiteindelijk moet alles wel aansluiten op bijvoorbeeld het RIS.
Allen dank voor de positieve feedback.
@Gerrit: werken onder architectuur en incrementeel ontwikkelen sluiten elkaar helemaal niet uit. In de architectuur worden te ontwikkelen applicaties geïdentificeerd, die per stuk aanbesteed en incrementeel ontwikkeld kunnen worden. Het enige wat je m.i. niet moet willen is een architectuur die tot één mega systeem leidt wat in één keer aanbesteed wordt. Maar juist met architectuur kun je makkelijk tot los te ontwikkelen componenten komen.
@PeterAmbagtsheer citaat: ‘Ook moet het makkelijker worden om prutsers die er niets van bakken, uit te sluiten.’
Ik denk dat eenieder het hier wel mee eens zal zijn.
Hoe denk je dit in de praktijk te kunnen realiseren ?
Hoe defineer je ‘prutser’ ?
Wil je alle bedrijven van naam die in het verleden als prutser aanmerken ?
Wie gaat dit beoordelen ? als in hoe weet ik dat dit geen prutser is ?
Ik zou het een goede zaak vinden als het op deze manier geregeld kan worden maar dat zal wel heel wat mensen hun baan kosten (wat mij betreft terecht) maar ik vrees dat het erg lastig gaat worden mijn bovenstaande vragen op een politiek correcte manier te beantwoorden.
Eens met het artikel. Oplossingen voor problemen/wensen worden beter door te overleggen. En juist in europese aanbestedingen is de mogelijkheid van overleg tussen leverancier en opdrachtgever vanaf zeker moment bijna niet mogelijk. Dus wordt het benodigde net niet optimaal beschreven, als dat uberhaupt al kan.
Daarnaast maakt het fenomeen Europese aanbesteding een en ander eerder duurder dan goedkoper. De aanbiedende partijen moeten tenslotte de kosten van de niet gegunde aanbestedingen ook op een of andere manier terug verdienen.
Tenslotte is mijn eigen ervaring dat leveranciers die reeds in huis zijn, meer moeite hebben om een aanbesteding te winnen dan nieuwe aanbieders. Reeds aanwezige leveranciers lijken vaak net iets te makkelijk te denken dat ze toch wel winnen onder blijkbaar de gedachte “je weet toch wat we kunnen”. En zo werkt het dus niet.