De eis die uw beste kandidaat uitschakelt

Er is een moment in vrijwel elk selectietraject dat iemand naar de shortlist kijkt en zegt: waar is die ene leverancier gebleven? Het pakket waar iedereen aan dacht, dat de collega's bij een vergelijkbare organisatie draaien, dat op elke branchevergelijking bovenaan staat. Weg. En als u dan gaat graven, blijkt het niet te liggen aan de weging, niet aan de prijs en niet aan de beoordelaar. Het ligt aan één zin in uw eisenlijst.

Dat is een oncomfortabele constatering, want die zin heeft u zelf geschreven. Meestal met de beste bedoelingen, vaak zelfs zorgvuldiger dan de eisen eromheen. Juist de zorgvuldigheid is het probleem: hoe meer nuance u in één eis probeert te vangen, hoe onbruikbaarder die eis wordt zodra er een oordeel over geveld moet worden.

Dit artikel gaat over hoe u dat voorkomt. Niet met een sjabloon dat u invult, maar met zes regels die u op uw eigen lijst kunt loslaten voordat die de deur uit gaat.

Regel 1: één eis, één controleerbare bewering

Kijk eens naar deze eis, letterlijk overgenomen uit een echte selectie:

De mobiele app beschikt over voice-to-tekst functionaliteit, of deze functionaliteit staat aangekondigd op de roadmap voor het komende half jaar.

Op het oog redelijk. De organisatie wil de functie, maar is bereid te wachten als een leverancier hem al heeft aangekondigd. Precies de soepelheid die je van een verstandige opdrachtgever verwacht.

Alleen: er staan twee beweringen in, en ze zijn van een totaal verschillende soort. De eerste gaat over wat een product vandaag doet en is te controleren in documentatie. De tweede gaat over wat een leverancier heeft beloofd en is te controleren in releasenotes, roadmappagina's en productaankondigingen. Twee vragen, twee bronnen, twee soorten bewijs. En één vakje om aan te vinken.

Wie deze eis beoordeelt, moet twee keer zoeken en één keer oordelen. In de praktijk verdwijnt de tweede helft. Er wordt gezocht op de functie, die wordt niet gevonden, en het pakket krijgt een nee. De ontsnappingsroute die u er bewust in had gebouwd, is nooit gebruikt.

De eis die u eigenlijk bedoelde zijn er twee:

Het pakket biedt spraakinvoer voor het vastleggen van notities in de mobiele app.

Als het pakket dat vandaag niet biedt, heeft de leverancier deze functie publiek aangekondigd voor levering binnen zes maanden.

Nu kan iemand op beide een apart antwoord geven, met apart bewijs. En nu ziet u ook wat er gebeurt als het tweede antwoord onvindbaar is, in plaats van dat het geruisloos in het eerste verdwijnt.

Deze regel is niet nieuw. De internationale norm voor requirements engineering, ISO/IEC/IEEE 29148, noemt hem singular: een eis beschrijft precies één capaciteit. Hij staat er al sinds 2011 in en in de herziening van 2018 nog steeds. Hij wordt alleen bijna nooit toegepast, omdat samengestelde eisen ontstaan op het moment dat u probeert redelijk te zijn.

Regel 2: gebruik een vaste zinsbouw

De snelste manier om samengestelde eisen te herkennen is een vaste zinsvorm. Wie iets doet, met welke informatie, onder welke voorwaarde, volgens welke regel.

Er bestaat een beproefd patroon voor, EARS genaamd, in 2009 ontwikkeld bij Rolls-Royce voor de eisen aan straalmotorbesturing en inmiddels in gebruik bij onder meer Airbus, NASA, Siemens en Bosch. Het kent maar een handvol vormen, en in gewoon Nederlands zien ze er zo uit:

• Altijd: het systeem legt bij elke klantinteractie het kanaal vast.
• Bij een gebeurtenis: wanneer een order wordt geannuleerd, registreert het systeem de annuleringsreden uit een vaste keuzelijst.
• In een toestand: zolang een klant een openstaande klacht heeft, toont het systeem dat bij elk contactmoment.
• Bij een optie: als de module servicebeheer is aangeschaft, koppelt het systeem serviceverzoeken aan de klantkaart.
• Bij een uitzondering: als een adres niet valideert, blokkeert het systeem de order en toont het de reden.

U hoeft deze vormen niet dogmatisch te volgen. Waar het om gaat is de test die ze mogelijk maken. Staan er twee werkwoorden in uw zin? Dan zijn het twee eisen. Staat er een "of" tussen twee dingen die het systeem zou kunnen doen? Twee eisen. Staat er een "en" tussen twee functies die los van elkaar kunnen bestaan? Twee eisen. Ontbreekt de voorwaarde, dus wanneer de eis geldt? Dan is hij niet ambigu geformuleerd maar ambigu bedoeld, en dat is een gesprek dat u intern moet voeren en niet aan een leverancier moet uitbesteden.

Aardig detail: deze zinsbouw beleeft op dit moment een tweede jeugd, omdat AI-hulpmiddelen eisen moeten kunnen lezen zonder ze te interpreteren. Wat goed is voor een machine, blijkt ook goed voor de leverancier die uw lijst om vier uur 's middags voor de zeventiende keer doorneemt.

Regel 3: alleen knock-outs hoeven atomair

Als u regel 1 en 2 consequent toepast op een complete eisenlijst, houdt u er zo vierhonderd over. Onwerkbaar, en niemand leest ze.

Dat hoeft ook niet. De mate waarin u een eis uit elkaar trekt, hoort af te hangen van wat er gebeurt als hij niet gehaald wordt. Voor een eis die meeweegt in een score is een samenvattende formulering prima: "het systeem ondersteunt het opstellen en versturen van offertes" is genoeg detail om een verschil tussen pakketten zichtbaar te maken.

Maar voor een eis die afvallers maakt, moet elk onderdeel apart te controleren zijn. Anders valt een leverancier af op iets waarvan u achteraf niet kunt reconstrueren wat het was. De vuistregel: als het antwoord "nee" betekent dat u dit pakket niet koopt, dan moet die eis uit precies één controleerbare bewering bestaan.

Dat maakt de klus ook overzichtelijk. Van een lijst van tachtig eisen zijn er meestal vijftien tot twintig echte knock-outs. Alleen die hoeven door de fijne zeef.

Regel 4: een knock-out zonder handhaving is een wens

Hoe weet u welke eisen echte knock-outs zijn? Er is een verrassend effectieve vraag voor, en die gaat niet over de eis maar over uw eigen organisatie: wat gebeurt er nu als iemand deze regel overtreedt?

"Wij eisen ISO 27001" is een wens als er in de kast drie leveranciers zitten die het niet hebben. Het is een knock-out als inkoop er ooit een aanbieding op heeft afgewezen. Datzelfde geldt voor bewaartermijnen, autorisatiemodellen, hostinglocatie en koppelverplichtingen.

Deze vraag doet twee dingen tegelijk. Ze haalt de nep-knock-outs eruit, en ze geeft u meteen de onderbouwing die u toch nodig had zodra iemand in de stuurgroep vraagt waarom een aantrekkelijk pakket is afgevallen.

Regel 5: prioriteer tegen uw doelen, niet op gevoel

Er is een verhaal uit de praktijk van een Canadees adviesbureau dat iedereen herkent die dit ooit heeft gedaan. Een adviseur vroeg zijn klant om vijfhonderd eisen te scoren op een schaal van 1 tot 5. Resultaat: 465 vijven, 25 vieren, geen enkele één. Volstrekt bruikbaar als gevoelsmeting, volstrekt onbruikbaar om leveranciers mee te vergelijken.

De oorzaak is dat "hoe belangrijk is dit" een vraag is zonder ankerpunt. Het alternatief kost een halve dagdeel: zet uw twee of drie belangrijkste doelen voor dit traject bovenaan een tabel, zet de groepen eisen ernaast, en scoor per groep hoeveel die groep bijdraagt aan dat doel. Een eis die aan geen enkel doel bijdraagt, is per definitie geen must have. Soms hoort hij zelfs helemaal niet in de lijst.

Bijkomend voordeel: als straks leverancier A op 80 procent van uw eisen scoort en leverancier B op 70 procent, weet u of die 70 procent toevallig wel de hele bovenste laag bevat.

Regel 6: zeg waar de functie mag zitten

Dit is de regel die het vaakst wordt vergeten en die de meeste schade aanricht, zeker nu vrijwel elk pakket een ecosysteem van koppelingen heeft.

Neem een eis over urenregistratie. Bedoelt u dat het pakket het zelf moet kunnen? Of is een standaardkoppeling met het urenpakket dat u al gebruikt ook goed? Of accepteert u dat de leverancier het als hoofdaannemer levert via een koppelcomponent, zolang u maar niet zelf tussen twee partijen in komt te zitten?

Dat zijn drie verschillende eisen met drie verschillende uitkomsten. Laat u het open, dan wordt de eis in de praktijk beantwoord door wie het antwoord zoekt, en die vindt op internet altijd wel ergens een integratiepartner die iets soortgelijks doet. U krijgt dan een groen vinkje voor een functie die in de demo nergens te bekennen is.

Formuleer daarom de leveringsgrens expliciet, bijvoorbeeld zo: "in het pakket zelf; een koppeling met een extern systeem geldt hier niet als invulling". Of juist het omgekeerde, als u soepel wilt zijn. Beide zijn goed. Alleen niets zeggen is fout.

De check voor u uw lijst verstuurt

Loop uw eisen langs deze zes vragen. Het kost een dagdeel en het verschil is groter dan welke weegformule ook.

1. Staat er meer dan één bewering in deze zin?
2. Is duidelijk wie wat doet, met welke informatie, onder welke voorwaarde?
3. Is dit een knock-out, en zo ja: bestaat hij uit precies één controleerbare bewering?
4. Wat gebeurt er nu in onze organisatie als deze regel wordt overtreden?
5. Aan welk van onze doelen draagt deze eis bij?
6. Mag deze functie ook buiten het pakket zitten, en zo ja hoe?

Hoe wij hiermee omgaan

Dit is niet toevallig ons stokpaardje. Smart Selector beoordeelt pakketten niet op wat leveranciers zelf invullen, maar op bewijs dat per eis wordt opgezocht en bij het oordeel wordt bewaard. Daardoor wordt de scherpte van uw eisen meteen zichtbaar. Per eis worden de score en het bewijsniveau vastgelegd. Bij een eis die twee vragen stelt, blijft echter onduidelijk op welk deel het ene oordeel precies rust.

Twee dingen zitten daarom vast in onze beoordeling. Brede eisen worden bij de beoordeling uiteengelegd in de onderliggende functies in plaats van als één blok gescoord. En de leveringsgrens uit regel 6 hoort tot de vaste beoordelingsregels: er wordt onderscheiden of de functie in het pakket of een inbegrepen bundelapplicatie zit, via configuratie of een eigen uitbreiding beschikbaar komt, via een bewezen standaardconnector of commerciële middleware wordt ontsloten terwijl de werkstroom in het pakket blijft, dan wel alleen buiten het pakket of via een workaround realiseerbaar is. Uniek maatwerk geldt daarbij niet als volwaardige invulling van de eis.

Wat geen enkele methode en geen enkel hulpmiddel voor u kan repareren, is een knock-outeis die twee beweringen bevat. Welke van de twee doorslaggevend is, weet u alleen zelf, en dat moet vaststaan voordat er een pakket op afvalt. Vandaar zes regels en geen knop.

Wilt u uw eigen eisenlijst hier eens tegenaan houden? Dat is waar we mee beginnen.