Aanbesteding, pilot, PoC etc

Ik mocht recent een rol spelen bij een aantal aanbestedingen. Ik noteer hieronder wat ik daaruit ondermeer (ook voor mezelf) wil bewaren.

Veel publieke organisaties moeten een aanbesteding doen als de waarde van iets boven de aanbestedingsdrempel komt. Theoretisch is de gedachte achter die verplichting en procedures helemaal goed. Zo moeten voldoende aanbieders een kans krijgen en moet 'publiek geld' goed worden besteed.

In de praktijk zijn er allerlei redenen waarom aanbestedingen 'lastig' zijn. Bijvoorbeeld:

• Vaak begin je op kleine schaal iets te gebruiken ... als het dan succesvol is en op grotere schaal gebruikt gaat worden, kun je ineens boven de aanbestedingsgrens uit komen. Maar een aanbesteding mag je niet toeschrijven naar een oplossing. Aan de andere kant wil je wel blijven gebruiken wat je in gebruik hebt, omdat dat bijvoorbeeld zo fijn werkt. En omdat, als je over moet stappen naar een concurrent/andere oplossing, je wellicht hoge kosten moet maken.
• Het overstappen van sommige dingen, bijvoorbeeld SAP, een groot ELO/LMS (bijvoorbeeld Blackboard) etc, brengt veel kosten met zich mee. Dat kan bij grotere organisaties oplopen tot miljoenen, in verband met migratie, opleidingen/cursussen, lagere productiviteit in het begin, nieuw moeten bouwen van allerlei koppelingen met andere systemen etc.

Theoretisch zijn er dan allerlei 'tegenwerpingen':

• Dan moet je maar vooraf bedenken als je iets in gebruik neemt, of het wellicht breed gebruikt gaat worden
• Dan moet je maar zorgen dat je makkelijk over kunt stappen, bijvoorbeeld door oplossingen te kiezen die voldoen aan open standaarden
• Etc

Maar in de praktijk gaat dat vaak niet zo mooi als in de theorie. Ik las ergens "In theorie is de theorie gelijk aan de praktijk. In de praktijk niet".

Een vraag die in 1 van de aanbestedingsprocedures speelde: “kunnen we pakketten eerst testen/uitproberen etc”.  Daarop dichtte ik het volgende:

• Op zich kun je software op kleine schaal uiteraard naar behoefte testen. De ene leverancier zal daar geld voor vragen, in andere gevallen zijn test-accounts wellicht gratis. 
• Zolang de kosten voor de pilot maar onder de aanbestedingsgrens blijven, is er niets aan de hand. 
• Testen van software kun je doen om een gevoel te krijgen van wat je zoekt/nodig hebt, waar je op moet letten bij de selectie. Het helpt je je Programma van Eisen scherper maken.
• Een mogelijk gevaar van testen, is dat een bepaald pakket je heel erg bevalt, en dat je dat dan in de hele instelling wil gaan/blijven gebruiken. Als de kosten boven de aanbestedingsgrens komen, moet je aanbesteden, en mag je uiteraard niet naar een bepaalde oplossing toeschrijven. Als je het nodige getest hebt, kun je natuurlijk wel beter je vraag omschrijven. Maar of er dan ‘het’ pakket uit komt wat bij het testen zo goed beviel, weet je pas aan het eind van de aanbesteding. Dat moet voor iedereen die bij dergelijke ‘test’ betrokken is, klip en klaar duidelijk zijn en blijven.
• Ik zou het logisch vinden dat elke leverancier zelf zorgt voor een proefomgeving (zeker bij cloudsoftware).
• Als de vraag is “we willen experimenteren, met hetgeen het meest bevalt willen we het experiment groter maken, en als iedereen blij is, willen we het op grote schaal in gebruik nemen …. Hoe kan dat in relatie tot de aanbestedings wet- en regelgeving” is het antwoord simpel: dat kan niet.
• We hoorden van iemand dat ze ervaring hebben met een usability lab. Ik begreep dat je als gunningscriterium bv de uitkomst van een test in zo’n usability-lab kunt meenemen. Je weegt dan mee of je gebruikers het pakket prettig vinden werken.

In dat kader vond ik nog een aantal leuke links:

• Een artikel over meenemen van gebruiksvriendelijkheid en ‘zachtere’ eisen  
• Een mogelijk interessant (maar betaald, ik heb het niet ingekeken) artikel over usability irt tenders 
• Een artikel over testen icm aanbesteding (zelf vind ik het niet heel sterk)

Voor zover ik weet kun je dus experimenteren zoveel je wil, zolang je met je experiment maar niet boven de aanbestedingsgrens uit komt.

In een aanbesteding zag ik de volgende passage:

“1.4.3 Proof of Concept
Na de gunningsprocedure zal een proof of concept (PoC) worden gehouden. Deze start en loopt tot . Dat betekent dat de PoC met de winnende inschrijver wordt uitgevoerd. Gedurende de PoC worden keuzes gemaakt ter zake van de inrichting van het systeem. De PoC is om die reden minder een proefopstelling maar meer een afgekaderd deel van de implementatie. De PoC wordt afgerond met een goedkeuringsprocedure. Bij het mislukken van de PoC volgt ontbinding van de (reeds gesloten) overeenkomst. Er wordt derhalve gegund onder ‘de ontbindende voorwaarde’ dat de PoC met goed gevolg wordt doorlopen.”

Dat is niet 1-op-1 een kwestie van “we kijken vooraf naar systeem A, zijn enthousiast, en dan willen we het ook”, maar wel een goede manier om te de kans te vergroten dat je een systeem krijgt dat ook voldoet/je nog een ontsnapping hebt NA gunning. Overigens ben ik wel benieuwd op welke gronden dan zo’n PoC mag worden ‘afgekeurd’.