Het kan echt met minder!
Nog altijd komen ze voor: software aanbestedingen met honderden eisen. Voorbeelden met 150 tot 200 eisen zijn er genoeg te vinden. En meer is zeker geen uitzondering. In dit artikel een betoog om hiermee te stoppen. En de stelling dat er een optimaal aantal eisen bestaat dat veel lager ligt dan je zou denken.
Photo by Kelly Lacy from Pexels
Bij het aanschaffen van standaard (off-the-shelf) software is het logisch dat er eisen worden gesteld, zowel aan de leverancier als aan de oplossing zelf. Voordat overheden verplicht werden om Europees aan te besteden kon je op basis van ervaringen met leveranciers en oplossingen zelf een inschatting maken van de geschiktheid van een softwarepakket. Natuurlijk kon het een uitdaging zijn om goed in te schatten welke oplossing het beste zou passen, maar als je in een offerte van een leverancier iets zag staan wat je niet beviel, dan vroeg je gewoon nog ergens anders een offerte op.
Die werkwijze was in veel opzichten prettig, maar had ook nadelen. Overheden konden ook om redenen die haaks stonden op het publieke belang kiezen voor een bepaalde voorkeursleverancier. En dat kwam ook gewoon voor, meestal met de beste bedoelingen. Maar misbruik kwam helaas ook voor. In de huidige situatie is het daarom verplicht voor overheden om een aantal uitgangspunten te hanteren bij het inkopen van onder andere softwarepakketten. Die uitgangspunten moeten ervoor zorgen dat het gunnen van opdrachten op een eerlijke en transparante wijze plaatsvindt.
Waarom stellen we eigenlijk eisen?
Maar dat betekent dat je niet meer direct invloed hebt op de uiteindelijke keuze. En dat geeft dan meteen de noodzaak weer om vooraf goed na te denken over wat je wilt. Of anders gesteld, je zult vooraf na moeten denken over de eisen waar een softwarepakket en de leverancier aan moeten voldoen. En daar ontstond meteen een uitdaging, want veel gebruikers konden eigenlijk niet zo goed formuleren wat de eisen moesten zijn (“Ik heb een softwarepakket nodig om teksten te typen en in op te maken”). En zij ontdekten vaak pas na gunning dat ze eisen vergeten waren (“Met Powerpoint kan ik inderdaad teksten typen en opmaken, maar dat is niet wat ik bedoelde!”). En dan nog maar gezwegen over leveranciers die hier dan weer bewust - of in ieder geval opportunistisch - misbruik van maken. Dit creëerde in het verleden een opwaartse spiraal in het aantal eisen. Wellicht vanuit een gevoel gevangen te zitten in een keurslijf van strakke Europese aanbestedingsregels greep men in het verleden iedere negatieve ervaring aan om weer extra eisen toe te voegen om zo herhaling van die ervaring te voorkomen.
Het heeft meer nadelen dan voordelen om (te) veel eisen te stellen
En zo werden de programma’s van eisen steeds omvangrijker. Zo omvangrijk dat veel overheden ook helemaal niet meer begonnen met de vraag welke eisen gesteld moesten worden, maar een kopie maakten van een eerdere aanbesteding. En met die kopie als startpunt vooral keken naar wat er nog aan eisen mistte. Men probeerde en probeert met een omvangrijk programma van eisen het risico weg te nemen dat een uiteindelijk gekozen oplossing niet goed aansluit bij de werkelijke behoeften (van de organisatie, van de gebruikers, et cetera). Echter, de praktijk van steeds maar eisen blijven toevoegen heeft een groot aantal nadelen:
Het kost de aanbestedende dienst en de leveranciers veel tijd en moeite om al die eisen op te stellen, te lezen, om er vragen over te stellen, die vragen weer te beantwoorden, en ga zo maar door. Iedere eis die aan het begin wordt toegevoegd creëert werk in alle stappen in het aanbestedingsproces die nog volgen.
Bij een (te) groot aantal eisen wordt de ‘waarde’ van iedere eis minder groot. Dat is gevoelsmatig zo, maar de praktijk laat ook zien dat omvangrijke programma’s van eisen vol staan met details. En vaak ook details waarvan je - met een beetje onderzoek - zou kunnen weten dat er helemaal geen oplossingen bestaan die daaraan voldoen.
Het vorige punt draagt bij aan ‘adverse selection’. Dit houdt in dat leveranciers die risicomijdend zijn eerder besluiten af te haken dan risicozoekende leveranciers. Of anders gezegd, de eerlijke leverancier zal eerder ‘nee’ zeggen tegen eisen (en daardoor afvallen), terwijl de opportunistische leverancier eerder over ‘ja’ op zegt en het risico neemt op discussies achteraf.
Het grote aantal eisen, met daarin vaak details, draagt er ook aan bij dat aanbestedende diensten eigenlijk te veel zelf bedenken hoe software moet werken (“Er moet een tooltip zijn”) en daarmee nieuwe innovatieve oplossingen uitsluiten waarmee dezelfde behoefte wordt ingevuld.
Door te veel eisen te stellen verklein je vooraf het aantal potentieel geschikte oplossingen en leveranciers.
Wat is dan wel een goed aantal eisen?
Moet je dan weinig of geen eisen stellen? Het antwoord op die vraag is nee. Je hebt eisen nodig. In ieder geval om duidelijk ongeschikte oplossingen en leveranciers buiten de deur te houden. Maar ook om de juiste omvang van de te leveren scope goed af te bakenen. Het gaat dan nadrukkelijk niet om eisen die aansluiten bij een vooringenomen voorkeur of afkeur, maar om goed te onderbouwen aspecten die bepalen of een oplossing geschikt is.
In een perfecte wereld kan een aanbestedende dienst alle eisen opsommen die noodzakelijk zijn om 100% zekerheid te creëren dat de best passende oplossing wordt gekozen. En in die perfecte wereld mogen dat er ook veel zijn. Alle betrokkenen hebben het cognitieve vermogen om het grote aantal details te doorgronden en te beoordelen. Alle leveranciers zijn eerlijk en zij begrijpen perfect wat de aanbestedende dienst nodig heeft. En op haar beurt begrijpt de aanbestedende dienst precies wat iedere leverancier aanbiedt.
De Wet van de Toe- en Afnemende Zekerheid
Maar we leven niet in een perfecte wereld. In de realiteit is de wereld nogal imperfect. Mensen zijn niet perfect cognitief en analytisch. Leveranciers zijn niet allemaal even eerlijk. Het vertalen van de behoeften naar eisen is niet vrij van ambiguïteit. En dus zal een leverancier (deels) moeten interpreteren wat de behoeften zijn. En de informatie is niet gelijk verdeeld, dus een leverancier weet veel meer van haar eigen oplossing dan de aanbestedende dienst ooit uit een offerte kan afleiden.
In die wereld - de werkelijke wereld - bestaat voor iedere aanbesteding van een softwarepakket een optimaal aantal eisen dat minder dan 100% zekerheid biedt.
Dat is de stelling in dit artikel. De logica voor het bestaan van dit optimum komt voort uit twee argumenten:
Je hebt eisen nodig om duidelijk te maken waar een oplossing aan moet voldoen om aan te sluiten bij je behoeften. Met iedere individuele eis maak je het een stukje duidelijker en verhoog je de zekerheid dat de best passende oplossing gekozen zal worden.
Maar omdat de wereld niet perfect is neemt de netto meerwaarde van iedere extra eis steeds verder af (en wordt negatief) omdat de nadelen van de totale set eisen steeds verder toenemen. Er komt een punt waarop een extra eis minder meerwaarde biedt dan de extra nadelen van een steeds maar groeiend aantal eisen (spreekwoordelijk zie je door de bomen het bos niet meer).
In de grafiek is voor het optimum vrij arbitrair gesteld dat dit 70% zekerheid biedt, maar het is per situatie verschillend waar dit punt lig, zowel qua aantal eisen als qua zekerheidsniveau dat bereikbaar is. En sterker nog, in de realiteit weten we niet wat het aantal is dat bij 100% zou horen. Het is dus zeker geen exacte wetenschap, maar een kunst om voor iedere aanbesteding opnieuw tot dit optimale aantal te komen.
De weg naar het optimale punt is eigenlijk vrij eenvoudig
Er is geen aanpak die kan garanderen dat een aanbestedende dienst aantoonbaar het optimale aantal eisen stelt. Maar het goede nieuws is dat de kunst waar in de vorige alinea over gesproken werd, eigen meer een ‘kunstje’ is. En dat kunstje bestaat uit een 10 ingrediënten:
Begin bij de eigen behoeften. Dat was namelijk de oorspronkelijke reden om überhaupt met eisen aan de slag te gaan. De bron van de behoeften kan verschillen. Soms is er sprake van een eenvoudige vervangingsvraag, in een andere situatie is het de bedoeling dat een softwarepakket bij gaat dragen aan het bereiken van bepaalde doelstellingen. Het is belangrijk om die behoeften te kennen, maar ook te weten waar ze vandaan komen. Streep nu alle behoeften weg die veroorzaakt worden door persoonlijke voorkeur of waarvoor je geen objectieve argumentatie kon vinden. Als je niet kunt onderbouwen waarom je een behoefte hebt, dan wil dat niet zeggen dat die behoefte er niet is, maar wel dat je er in een aanbesteding niks mee mag doen.
En ga nu niet opnieuw meteen eisen formuleren waarmee je probeert te borgen dat een oplossing in jouw behoeften kan voorzien! Dan is er namelijk geen enkele manier om te bepalen wanneer je moet stoppen met het toevoegen van details. Gebruik die behoeften (en de bronnen van die behoeften) om de markt te verkennen. Bekijk welke oplossingen er zijn. Let goed op overeenkomsten tussen oplossingen, maar ook op verschillen. Dit zijn interessante kenmerken van de verschillende oplossingen die je later kunt gebruiken om eisen te formuleren.
Beantwoord voor jezelf welke oplossingen het beste in staat lijken te zijn om te voorzien in je behoeften. Je hoeft het niet 100% zeker te weten. Je hoeft ook nog niet te begrijpen waarom dat zo is. Blijft dit lastig, dan is het bezoeken van referenties zeker aan te raden. Ga eens bij klanten van oplossingen kijken en stel daar de vraag waarom die oplossing daar goed past? Of juist niet.
En probeer dan de vraag te beantwoorden: waarom zouden deze oplossingen beter passen voor jouw organisatie? En probeer de antwoorden op deze vragen te formuleren in relatie tot de eerder geformuleerde behoeften én in relatie tot de overeenkomsten en met name de verschillen die je bij de oplossingen hebt ontdekt.
Doe 3 en 4 nogmaals, maar dan met de vraag welke oplossingen absoluut ongeschikt zijn.
Je hebt nu kenmerken van oplossingen waarvan je kunt onderbouwen waarom die ervoor zorgen dat een oplossing goed zou passen en kenmerken die ervoor zorgen dat een oplossing juist ongeschikt is.
Formuleer nu een zo klein mogelijk aantal eisen die er voor zorgen dat ongeschikte oplossingen onmogelijk aan de eisen kunnen voldoen. Gebruik hiervoor met name de verschillen in kenmerken. En zorg er voor dat je kenmerken gebruikt die objectief verifieerbaar zijn. Dus de eis “de aangeboden applicatie is gebruiksvriendelijk” is totaal onbruikbaar. Maar de eis “de aangeboden applicatie heeft bewezen werkende koppeling met applicatie X” kan heel goed bruikbaar zijn.
Voeg nu die eisen toe die bijdragen aan het zeker stellen dat leveranciers de juiste scope (in termen van bijvoorbeeld modules, aantallen licenties) aanbieden. Hier komt die marktverkenning dus ook weer goed van pas!
En voeg ook eisen toe die ervoor zorgen dat de leveranciers goed begrijpen welke diensten zij aan moeten bieden. Dus vraag je alleen de licenties voor het softwarepakket? Of wil je dat de leverancier het pakket komt installeren? En ga je het zelf inrichten? Et cetera.
Als je eisen hebt waarmee je (vrij) zeker weet dat alleen geschikte oplossingen een kans maken én eisen waarmee de scope duidelijk is én eisen waarmee duidelijk wordt welke diensten je nodig hebt, dan heb je het optimale aantal eisen. Echt bewijs hiervoor is nooit te geven en 100% zekerheid bestaat niet.
Als je deze ingrediënten toepast in je aanpak om te komen tot een programma van eisen, dan zul je ervaren dat je eerder stopt met het toevoegen van details. Dat komt omdat je niet bezig bent met de vraag “beschrijven de eisen nu echt goed mijn behoeften”. Deze vraag is ongelooflijk moeilijk te beantwoorden. Door deze ingrediënten toe te passen beperk je het werk eigenlijk tot drie vragen:
Zorgen deze eisen ervoor dat ongeschikte oplossingen geen kans maken?
Zorgen deze eisen ervoor dat de leverancier snapt welke modules aangeboden moeten worden? (En voor hoeveel mensen, cases, inwoners, et cetera)
Zorgen deze eisen ervoor dat de leverancier snapt welke diensten aangeboden moeten worden?
Deze vragen zijn vaak al met grote zekerheid positief te beantwoorden bij slechts een klein aantal eisen.
Maar zit je dan op het optimale aantal eisen? Zoals gezegd, dat is nooit te bewijzen. Maar ga eens terug naar de grafiek. Als je te weinig eisen hebt, dan heb je een minder dan optimale hoeveelheid zekerheid, je zit dan links van het optimum op de curve! Met de beschreven ingrediënten kom je niet zo snel aan de rechterkant van het optimum uit. Met de aanpak die veel aanbestedende diensten nu volgen wel. Je zou kunnen zeggen, dat is dan ook minder dan optimaal. Dat klopt, maar wel na veel meer werk!
Noot: Let op dat ‘ingrediënten’ niet gezien moeten worden als een stappenplan. Afhankelijk van de inkoopprocedure zullen er verschillen zijn. Zo heb je bij een niet-openbare procedure de mogelijkheid om door middel van eisen aan de leverancier het aantal inschrijvers voor de inschrijvingsfase al te beperken. Hierdoor hoef je wellicht nog minder eisen aan de oplossing zelf te stellen. En bij een meervoudig onderhandse procedure gebruik je de verschillende kenmerken vooral om zelf te bepalen welke leveranciers je uitnodigt en zul je wellicht hierdoor ook minder eisen nodig hebben.
En wensen dan?
Even aangenomen dat er niet gegund wordt op basis van laagste inschrijving (goedkoopste) dan zijn wensen ook nodig. Met de eisen bereik je alleen dat ongeschikte oplossingen buiten de deur gehouden kunnen worden en dat de scope van de oplossing en de bijbehorende dienstverlening duidelijk zijn. Maar nu moet je nog kiezen tussen de resterende oplossingen. Daar zijn de wensen voor. En ook voor wensen geldt een soort wet van toe- en afnemende meerwaarde. De aanpak voor het opstellen van de wensen vertoont overeenkomsten, maar ook verschillen met de eisen. Het voert voor dit artikel te ver om dit uitvoerig toe te lichten. In dit artikel wordt slechts opgemerkt dat er wensen nodig zijn in relatie tot de scope (bijvoorbeeld modules die niet verplicht aangeboden hoeven te worden), de dienstverlening (bijvoorbeeld hogere servicelevels dan de minimale eisen) en niet te vergeten wensen om uiteindelijk te kunnen komen tot een keuze. Het moge duidelijk zijn dat die laatste vooral gebaseerd moeten worden op de verschillen tussen de oplossingen.
Tot slot
Dit artikel is geschreven vanuit 15 jaar ervaring in het begeleiden organisaties in het opstellen van programma’s van eisen voor (Europese) aanbestedingen van standaard (off-the-shelf) bedrijfssoftware. En vanuit de overtuiging dat gebruikers(organisaties) zich vooral moeten bezighouden met het formuleren van behoeften en dat het aantal eisen zo klein mogelijk moet zijn.
