Waarom een must-have geen knock-out is

In vrijwel elk softwareselectietraject gebeurt hetzelfde. Het projectteam stelt de eisenlijst op, geeft de belangrijkste functionaliteiten het stempel must-have, en besluit dat een leverancier afvalt als hij daar niet aan voldoet. Dat lijkt logisch. Als een eis onmisbaar is, waarom zou je dan verder praten met een pakket dat het niet kan?

Toch is dit een van de duurste fouten in een selectie. Het gelijkstellen van een must-have aan een knock-out zorgt er in de praktijk voor dat de beste kandidaten al in de eerste ronde verdwijnen, meestal zonder dat iemand het merkt.

Twee vragen die door elkaar lopen

Een selectie stelt twee heel verschillende vragen.

De eerste is: hoe belangrijk is deze eis voor ons? Dat is prioritering. Het antwoord bepaalt hoe zwaar een eis meeweegt in de vergelijking tussen pakketten.

De tweede is: welke oplossingen komen überhaupt in aanmerking? Dat is toelaatbaarheid. Het antwoord bepaalt de grenzen van het speelveld: waar de data mag staan, welk budget er is, aan welke wetgeving voldaan moet worden, in welke taal het systeem moet werken.

Het verschil zit in de oplossingsruimte. Een must-have beschrijft wat de organisatie nodig heeft, maar zegt niets over hoe dat wordt opgelost. Een randvoorwaarde beschrijft een grens waar geen alternatief voor bestaat.

Wie die twee vragen in één veld propt, krijgt onvermijdelijk het antwoord op geen van beide.

Wat de BABOK Guide hierover zegt

Het onderscheid is geen eigen bedenksel. Het staat in de BABOK Guide, de body of knowledge voor business analyse van het IIBA.

In het hoofdstuk over het prioriteren van eisen worden acht factoren genoemd die de prioriteit bepalen: het voordeel, de consequentie van niet implementeren, de kosten, het risico, de afhankelijkheden, de tijdgevoeligheid, de stabiliteit, en de naleving van wet- en regelgeving. Die laatste staat er als eigen factor naast de andere, niet als een zwaardere variant van een functionele eis.

Veelzeggender is waar de uitkomst van dat prioriteren naartoe gaat. In het procesmodel stroomt het resultaat door naar de risicoanalyse. Niet naar een eliminatiestap. Een hoog geprioriteerde eis die niet volledig wordt ingevuld, leidt tot een risico dat je beoordeelt en afweegt, niet tot een pakket dat van tafel gaat.

Bij het definiëren van ontwerpopties wordt het expliciet. De BABOK stelt daar dat de hoogst geprioriteerde eisen "might deserve more weight in choosing solution components" vergeleken met eisen van lagere prioriteit. Meer gewicht bij het kiezen. Geen filter.

En dan de kern. In datzelfde hoofdstuk is er precies één plek waar wel iets wordt uitgesloten: de scope van de oplossing bepaalt de grenzen bij het selecteren van haalbare ontwerpopties. Niet de prioriteit van een eis, maar de afbakening van het speelveld.

Dat is de regel in één zin: een knock-out hoort bij de oplossingsruimte, niet bij een eis.

Wat er misgaat als je dat niet scheidt

Je sluit slimmere oplossingen uit voordat je ze ziet. Een pakket kan op een specifieke eis geen standaardfunctie hebben, en het probleem toch goed oplossen via een module die je bijschakelt, een no-code configuratie of een koppeling die de functie in het pakket brengt. Heb je die eis als knock-out ingericht, dan is de leverancier al weg voordat iemand die route heeft bekeken.

De lijst wordt leeg of willekeurig. Definieer je veertig must-haves en gebruik je ze allemaal als eliminatiecriterium, dan blijft er niemand over. In de praktijk zie je vervolgens iets ergers: de knock-outs worden zo ruim toegepast dat ze niemand meer tegenhouden. Een poort waar bijna alle eisen doorheen moeten, discrimineert niet. Je denkt dat je streng bent, en je filtert in werkelijkheid niets.

Je verliest zicht op wat er verdwijnt. Dit is het onderschatte deel. Een pakket dat afvalt op een knock-out zie je nog. Een pakket dat door dezelfde ruime knock-outs simpelweg lager in de rangschikking eindigt, zie je niet. Het staat niet op de shortlist en het staat ook niet op de afvallerslijst. Het is er gewoon niet.

Hoe wij het inrichten

CRM Selector werkt anders dan een klassiek tendertraject. Wij sturen geen vragenlijst naar leveranciers en wachten niet op hun eigen antwoorden. We beoordelen pakketten op publieke bronnen: productdocumentatie, kennisbanken, onafhankelijke reviews en prijsinformatie. Dat maakt het proces sneller en onafhankelijker, en het legt de bewijslast bij ons in plaats van bij de leverancier.

Juist daarom is de scheiding tussen prioriteit en toelaatbaarheid bij ons extra belangrijk. In een tender kan een leverancier bezwaar maken als hij ten onrechte afvalt. Bij een geautomatiseerde marktscan gebeurt dat niet: een pakket dat onterecht wegvalt, verdwijnt stil. De klant ziet nooit dat het er was.

Vier vuistregels die daaruit volgen:

Randvoorwaarden horen in het selectieprofiel, niet in de eisenlijst. Hostinglocatie, compliance, taal van de interface, budgetplafond, verplichte koppelvlakken. Dat zijn uitspraken over het speelveld en niet over een functie.

Houd het aantal randvoorwaarden klein. In de meeste trajecten zijn het er een handvol. Loopt het op tot enkele tientallen, dan zitten er functionele eisen tussen die daar niet horen.

Een randvoorwaarde moet binair zijn. Als je niet kunt opschrijven wat een pakket precies niet moet hebben om af te vallen, is het geen randvoorwaarde maar een weging. "Ondersteunt mobiel werken" is niet binair. "Data wordt in de EU opgeslagen" wel.

Scoor de rest op mate van geschiktheid. Niet ja of nee, maar hoe: standaard aanwezig, via configuratie, via een bijschakelbare module, via een koppeling, of niet beschikbaar. Die nuance is precies wat een binaire poort weggooit.

Eén nuance over koppelingen

Een must-have die via een koppeling wordt ingevuld, telt in de meeste methodieken gewoon mee als aanwezig. Wij maken daar een onderscheid dat past bij wat we beloven.

Brengt de koppeling de functie ín het pakket, en blijft de werkstroom bij de gebruiker in dat ene systeem, dan telt het als aanwezig. Stuurt de koppeling alleen data naar een ander systeem waar het hele functiedomein woont, dan niet. Dan is het integratie met een ander product, en geen invulling van de eis.

De reden is onze belofte. Een klant die een CRM-oplossing zoekt, krijgt van ons een top drie binnen die categorie. Geen op maat samengestelde combinatie van losse oplossingen. Dat is een bewuste inperking, en het is goed om te weten dat we die maken.

Tot slot

Het doel van een selectie is het pakket vinden dat het beste aansluit op wat de organisatie wil bereiken. Door randvoorwaarden te reserveren voor echte grenzen, en must-haves te gebruiken voor het wegen van de functionele geschiktheid, houd je de markt in beeld en voorkom je dat de beste kandidaat afvalt op een detail.