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
Reacties
"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.
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.
Binnen de bestaande wetgeving is al meer mogelijk dan waar de meeste aanbestedingen nu mee werken. Zo beginnen een aantal opdrachtgevers de principes van Best Value Procurement te hanteren.
- De eerste selectie vindt plaats op een aantal korte plannen (enkele A4'tjes per plan.
- Vervolgens vinden er interviews plaats.
- De partijen die dan nog in de race zijn gaan dan pas de concurrentie aan op prijs.
Ik heb daar in december een heel artikel over geschreven dat je terug kunt vinden op mijn blog: http://watkostit.blogspot.com/2011/12/aanbestedingen-waarde-niet-gewaardeerd.html
Het aanbestedingsdrama is geen uitbestedingsdrama. Het is het klassieke verhaal dat de brug niet word gemaakt tussen IT vs Non-IT, met dit artikel als resultaat. Daar kun je natuurlijk allerlei klassieke meningen op loslaten, maar daar los je dat probleem ook niet mee op.
Je hebt hier drie gemene delers die hieraan debet zijn.
1. IT vs Non-IT
De overheid is een apparaat vol met egootjes, maar dat zijn IT-ers pur sang ook. Het zijn twee werelden waarbij telkens de brug maar niet kan worden geslagen.
Wanneer het eerste resultaat wordt opgeleverd en iets anders blijkt dan be/gedacht, dan begaat men de klassieke fout voort te borduren op iets wat al niet deugt met alle gevolgen van dien. Voorbeelden: EPD, C2000, software debacles bij KLPD en Diginotar.
2. Commercie
De commercie weet hoe het verhaaltje te brengen en het grote spel te spelen. Zij moeten zich eens achter de oren krabben of zij menen wel zo goed bezig te zijn. Immers, je ben mede debet aan verslechterende aanzien van de IT als leverancier wanneer uitgeklede diensten of producten verkoopt wetende dat er later met nacalculatie en hele dure uren, het grot geld wordt verdiend. Immers, in de regel zal men niet al te vaak een project afschieten wanneer men een aanzienlijk eind is gevorderd nietwaar?
Persoonlijk heb ik daar mijn gedachten over en ik kan u vertellen dat die niet mals zijn. Als je namelijk, en ik chargeer niets, 'te stom' voor woorden bent te willen begrijpen dat IT als materie heel goed voorspelbaar is mits je daar open voor wil staan, goed kunt voorspellen wat zal werken en wat niet, en dan toch zaken op deze wijze inhoud geeft, dan bewijs je de IT als naam en faam gewoon een zeer negatief aanzien.
Uiteraard op dit punt plots heel veel kritiekjes dat ik het niet zou begrijpen, leg ik graag even naast mij neer. Ik spreek graag uit eigen waarneming en ervaring.
3. Fragmentatie
Het grootste gevaar is fragmentatie van een dienst of een product. IT is relatief eenvoudig in containervorm te visualiseren. Domweg omdat IT een lineaire materie is. Wanneer je zaken eenvoudig houd, kom je vaak tot de sterkste oplossingen.
De fragmentatie zit hem in het gegeven dat men, en dat geld voor beide partijen wanneer het overheid betreft, dat twee partijen, weinig tot geen affiniteit met IT hebben maar de 'zaken regelen', voila, zie de inhoud en teneur van het artikel.
Aanbesteden
Helaas, zo is de realiteit, hebben wij een aantal 'domme dienders' gehad in het verleden die de zakelijk soevereiniteit hebben overgeheveld naar Brussel. We hebben zo nog wel een paar van die 'fantastische' bewindvoerders gehad die kweelden dat Brussel zaken zou structureren en problemen zou oplossen.
Realiteit is volkomen anders gebleken. Wij werden vanuit Brussel opgezadeld met iets genaamd Capex en de verplichting grotere projecten Europees aan te besteden. Dat heeft een enorme fragmentatie met zich meegebracht.
Naar berekening betekend dit dat bij de overheid meer dan 80% van de middelgrote en grote IT projecten volkomen uit de klauwen loopt met alle financiële en organisatorische consequenties van dien.
Wilt u een antwoord in dit opzicht? Dan moet u Verhage 'klip en klaar' duidelijk maken dat vele miljarden aan schade t.l. van de belastingbetaler, klaarblijkelijk hem de ogen niet heeft geopend dat deze gang van zaken het aanzien van IT en het oogmerk van IT, namelijk besparingen bewerkstelligen, op deze manier onmogelijk maakt.
Ik beloof u in elk geval dat deze gang van zaken, in de nabije toekomst gewoon doorgang zal vinden. Business as usual. Dan weet u in ieder geval de reden waarom ik weiger voor een overheid te acteren. En dat heeft te maken met het begrip dat we hier werken met geld van de belastingbetaler en als die zo flagrant een 'oor wordt aangenaaid' dan haak ik af.
Als je geen idee hebt van IT, de wetmatigheden en de werking, blijf er dan met je handen vanaf. Het resultaat is in het artikel weergegeven. Next!
De meeste aanbestedingen die fout gaan kenmerken. zich door:.
niet goed weten wat er moet gebeuren
het niet goed, precies omschrijven wat er gedaan moet worden
het 'indirect' definieren van een product ipv een oplossing
zaken bevragen die nooit afgenomen worden
geen objectief vergelijkingsmechanisme inbouwen, maar een subjectief vergelijk
onvoldoende tijd, kennis en energie stoppen in het aanbestedingsproces,de inhoud dus
eEen goed aanbesteding zou moeten leiden tot het beoogde eindresultaat, weinig of geen meerwerk, em opties en op maat realiseren.
Helaas is het zo dat de aanbestedingen waar iets fout gaat meer en veel in de aandacht staan dan de aanbestedingen waar het wel goed gaat. In dat kader is een aanbesteding dan al gauw een drama,
@Frank: Goed artikel. Zoals ik ook al - kort - aangeef is er ook ruimte om binnen de Europese aanbestedingen beter te werk te gaan, jouw artikel is een goed voorbeeld van zo'n aanpak. En het zal ook wel moeten - die aanbestedingsplicht is er natuurlijk nog wel even.
Goed artikel, niet volledig en "put the blame on the EU". Kommentaren zijn van mijn standpunt goed maar toch enkele opmerkingen.
1. Overheid : prospectie kost te veel en het systeem moest al lang geleverd worden;
2. Industrie : alles kan .... tot wanneer, na de gunning, het project (overheidsopdracht) komt voor de eerste keer bij de techneuten en PM.
3. Firmas die in team werken, hebben de grootste pijn, om niet schrik, schriftlelijke vragen over vereisten, aan de overheid te stellen ... en terug de vraag stellen wanneer het antwoord niet past. Niet uit de oog te verliezen is dat normaal de overheid moet het antwoord anoniemiseren en publiceren (zie 1)
4.Prijs ... indien geen deftige antwoord ... risiko (in andere bijdragen hierboven beschreven) wordt hoger aldus de prijs ook; en, de kans om gunning wordt kleiner
Mijn besluit is : vragen stellen en in-team werken. Pas op bij de overheid heerst de "gelijkheid van de mogelijke aannemers, aldus zwijgen" traditie. In EU wordt dat de "Public Administration Zero Mistaken Syndrom" genoemd. Raadgeving, zie de DISA website.
Grondig mee eens Marc.
Wij zijn in de gelukkige omstandigheid die jij beschrijft in je soll situatie van samenwerking met de klant:
"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."
De vraagt om dappere mensen die dit als eis willen stellen in tot nu toe onvermijdelijke aanbestedingen.
Goed geschreven,
Ruud