Programma van eisen ERP: waarom uw selectie al is gestuurd voordat de eerste demo begint

Op de MT-agenda staat een dik document met één besluit eronder: vaststellen. De directeur die het opent herkent een deel van de eisen meteen; die komen uit gesprekken van afgelopen kwartaal. Dan stuit zij op een eis voor grafische capaciteitsplanning. Niemand aan tafel kan zeggen wie die eis heeft ingebracht of welk probleem eronder ligt. Het document gaat binnenkort naar leveranciers.

Dat is het moment waarop een selectie in stilte al is beslist. Het sturende werk gebeurt hier, weken voordat de eerste demo wordt ingepland. Wij zien dat terug bij trajecten die wij later moeten rechttrekken, en het is de reden dat wij altijd eerst het document lezen voordat wij naar de kandidaten kijken.

Wat uw programma van eisen in werkelijkheid vastlegt

Een programma van eisen is het document waarmee u de markt bevraagt: het legt vast wat u van het nieuwe systeem en van de leverancier verwacht. Zo’n document werkt als een filter. Elke leverancier antwoordt op wat er staat en op niets anders.

Daar zit de stuurkracht. Schrijft u een oplossing op, dan sluit u iedere leverancier uit die het probleem langs een andere weg heeft opgelost. Een formulering uit een template beschrijft bovendien de werkwijze van een ander bedrijf, en die wijkt op de punten die ertoe doen af van de uwe. Het lastigst zijn de eisen waarvan niemand de herkomst kent: die kan ook niemand verdedigen zodra ze geld gaan kosten.

Onze positie daarin is eenvoudig. De uitkomst van een ERP-selectie volgt uit de kwaliteit van de vraag die u stelt. Wie die vraag mocht formuleren, bepaalt dus mede welk systeem u overhoudt. Zolang die herkomst ongetoetst blijft, vergelijkt u antwoorden op verschillende vragen. Bias in het traject zelf, in de shortlist en de demo’s, werkten wij eerder uit bij onafhankelijke ERP-selectie. Dit artikel gaat over het document dat aan al die stappen voorafgaat.

De herkomst-audit: lees uw eisenlijst in drie kolommen

Gebruik het instrument hieronder als een leesmanier op uw eigen concept. Neem dat concept erbij en zet er drie kolommen naast: wat er letterlijk staat, wat die formulering in werkelijkheid vastlegt, en welke vraag daaronder had moeten staan. Reken erop dat de tweede kolom u verrast.

Wat er in het programma van eisen staat	Wat het in werkelijkheid vastlegt	Welke vraag daaronder hoort
“Het systeem beschikt over een module voor grafische capaciteitsplanning”	Een productkeuze; bij leveranciers die het probleem anders hebben opgelost zien wij hier meestal maatwerk uit voortkomen	Welk planningsprobleem lost u op, met welke doorlooptijd en welke wijzigingsfrequentie?
“Het systeem is gebruiksvriendelijk”	Niets toetsbaars; iedere leverancier kan hier met goed fatsoen ja op antwoorden	Welke taak moet welke rol binnen hoeveel handelingen kunnen afronden?
“Koppeling met ons WMS via API”	Een technische route, gekozen voordat de kosten en het beheer ervan zijn afgewogen	Welke gegevens moeten wanneer en met welke betrouwbaarheid heen en weer?
“Rapportage conform het huidige maandrapport”	De inrichting van het oude systeem, doorgetrokken naar het nieuwe	Welk besluit neemt u met dit rapport, en welke gegevens heeft dat besluit nodig?
“Ondersteuning van onze productiestraat zoals nu ingericht”	Een bevriezing van het bestaande proces, waarmee de verbetering uit de business case verdwijnt	Wat wilt u behouden omdat het onderscheidend is, en wat houdt u alleen uit gewoonte?
“Leverancier heeft aantoonbare ervaring in onze branche”	Een referentiedrempel die de shortlist verkleint voordat u weet wat u nodig heeft	Welke ervaring is voor u dekkend, en wie beoordeelt of een referentie vergelijkbaar is?

Wat wij bij deze oefening telkens zien, is een lijst die technisch scherp is en bestuurlijk vaag. Op het moment dat de offertes binnenkomen, heeft u het omgekeerde nodig.

Rode vlaggen die om een gesprek vragen voordat het document de deur uit gaat

Deze signalen wegen bij ons zwaarder dan de rest.

• Een deel van de eisen is aantoonbaar overgenomen uit een document van een leverancier of een branchevereniging, zonder hervertaling naar uw eigen processen.
• Er zit geen prioritering in, waardoor de leverancier zelf bepaalt wat zwaar telt. Een prioritering in must have, should have, could have en won’t have lost dat op, mits het MT de must-haves ook echt vaststelt.
• De eisen komen van afdelingshoofden en de mensen die het proces dagelijks draaien hebben het document nooit gezien.
• Er staat een eis in waar niemand een naam bij kan noemen.

Die laatste is de belangrijkste. Een eis zonder eigenaar is een eis die u tijdens de onderhandeling niet kunt laten vallen, want u weet niet wat u opgeeft.

De afspraak die wij onszelf opleggen voordat wij een eisenlijst aanraken

Er loopt bij ons geen resellermarge mee en er bestaat geen partnercontract met een softwareleverancier. Geen enkele leverancier betaalt ons voor de uitkomst van uw selectie, en onze vergoeding voor dit werk verandert niet met het pakket dat u kiest. Dat is de reden dat wij dit werk mogen doen, en het is ook de reden dat wij onszelf een afspraak opleggen: wij houden de pen bij u. Onze rol is helpen om elke eis terug te brengen tot de vraag die eronder ligt, en die vraag blijft van u.

Het klinkt bescheidener dan het is. In zo’n document staat het werk van mensen beschreven door anderen. Een medewerker die het systeem straks urenlang bedient, leest daar zijn eigen dag terug in woorden van iemand die dat werk nooit heeft gedaan. Onze rol is die collega aan tafel krijgen en zijn taal terugleggen in het document, zodat het MT tekent voor iets wat klopt. Zo houdt u regie over een besluit dat u de komende tien jaar draagt.

Wat wij zien als de vraag per leverancier verschilt

In onze ervaring komt het scheve in de vergelijking pas boven water als de offertes op tafel liggen. De prijzen liggen dan dicht bij elkaar en dekken elk een andere hoeveelheid werk. De ene leverancier heeft de planningseis als standaardfunctionaliteit gelezen, de tweede als maatwerk begroot, de derde heeft hem stilzwijgend uit de scope gelaten met een voetnoot over een latere fase. Alle drie hebben ze correct geantwoord op wat er stond.

Op dat moment vergelijkt uw MT drie antwoorden op drie verschillende vragen, en het verschil wordt zichtbaar als een prijsverschil. Wat wij dan doen is de vraag terugleggen: welke van de drie interpretaties beschrijft uw werkelijke behoefte? Zodra die vraag is beantwoord, is de vergelijking weer eerlijk en verschuift het gesprek van prijs naar geschiktheid.

Onder onze 265+ collega’s zitten mensen die zo’n regel eerder in een echte implementatie hebben zien landen, op uiteenlopende ERP-platformen. Zij weten waar een zin uit een eisenlijst twee jaar later terechtkomt, en dat is precies de kennis die uw vraag scherp maakt. Hoe zo’n traject er in de praktijk uitziet, leest u in de casus van Velopa, dat met onze begeleiding koos.

De volgorde die uw eisenlijst toetsbaar maakt

Een programma van eisen wordt bruikbaar zodra u er een volgorde in aanbrengt. Loop de ijkpunten hieronder op volgorde na en stop bij het eerste dat blijft haken; verder werken heeft dan geen zin.

1. Het probleem staat voor de oplossing. Elke must-have is te herschrijven tot een zin die begint bij het probleem en eindigt bij een meetbare uitkomst. Lukt dat bij een eis niet, dan heeft u een voorkeur te pakken, en voorkeuren horen thuis in de could-haves. Dit ijkpunt kunt u zelf uitvoeren, zonder hulp van buiten.
2. Elke must-have heeft een naam en een consequentie. Achter elke must-have staan twee dingen: wie hem heeft ingebracht en wat er misgaat wanneer het systeem die eis mist. Ontbreekt de consequentie, dan weegt de eis te licht voor de must-lijst. Zonder naam kan niemand de eis tijdens de onderhandeling verdedigen of laten vallen.
3. De vraag is voor iedere leverancier gelijk. Zorg dat de eisen zo geformuleerd zijn dat drie verschillende partijen ze op dezelfde manier kunnen lezen. Vraag naar de uitkomst en laat de route aan hen. Dat maakt de antwoorden vergelijkbaar en het legt bloot welke leverancier uw proces werkelijk heeft begrepen.

Struikelt uw document op ijkpunt 2 of 3, dan is een toets door iemand zonder belang bij de uitkomst het snelste herstel; dat is wat onze dienst ERP pakket- en partnerselectie doet.

Wanneer moet u actie ondernemen?

Toets uw programma van eisen zolang het document nog van u is. Concreet betekent dat: voordat het naar de markt gaat, voordat u een leverancier laat meeschrijven aan de specificatie en voordat het MT het formeel vaststelt. Na verzending kunt u eisen nog wel wijzigen. In onze ervaring kost zo’n wijziging u onderhandelingsruimte, omdat het aanbod al op de oude tekst is gebouwd.

De toets is dringender wanneer één partij heeft geholpen bij het opstellen en ook meedoet aan de aanbesteding. Datzelfde geldt bij een eisenlijst die grotendeels de inrichting van uw huidige systeem beschrijft, want dan koopt u uw eigen verleden opnieuw in. En een traject waarin de must-haves in aantal blijven groeien, lezen wij als een teken dat het gesprek over prioriteit nog moet komen.

Wanneer is dit juist niet nodig?

Een volledige herkomst-audit is overbodig wanneer uw vraag klein en helder is. Vervangt u één afgebakende applicatie waarvan het proces onveranderd blijft, dan volstaat een korte functionele lijst met een prioritering. Hetzelfde geldt wanneer u binnen uw huidige platform een module bijzet en de leverancier al vastligt in een lopend contract: de selectievraag speelt dan gewoon niet.

Ook bij een organisatie die net een grondige procesanalyse heeft afgerond en die analyse letterlijk als basis voor de eisen heeft gebruikt, is de winst beperkt. De herkomst is dan al vastgelegd. Wat wij in zo’n geval nog aanraden is een korte tegenlezing op formulering, zodat oplossingen die per ongeluk in de eisen zijn beland er alsnog uit gaan.

Zullen wij eens meelezen voordat u verstuurt?

De rest van dit traject volgt uit één beweging: uw eisenlijst terugbrengen tot uw eigen vragen voordat iemand anders ze beantwoordt. Dat is de laatste plek waarop u het document nog kunt bijsturen voordat anderen ervan afhankelijk worden.

Wij lezen zulke documenten graag, ook als ze nog rommelig zijn. Het interessantste deel van dit werk zit in de vraag eronder, en die pluizen wij met u uit zonder dat er iets uit hoeft te komen. Een concept opsturen of even bellen is genoeg om te beginnen.

De concrete stap daarna is een onafhankelijke herkomsttoets: wij lezen het document regel voor regel en benoemen welke eisen een oplossing voorschrijven, welke geen eigenaar hebben en welke voor drie leveranciers verschillend leesbaar zijn. U krijgt uw eigen lijst terug, met de vragen erbij die er nog niet in stonden. Daarna is het uw traject: u gaat de markt op met een vraag die van u is, en de gesprekken met leveranciers voert u zelf.

Veelgestelde vragen over een programma van eisen voor ERP

Wat is een programma van eisen voor ERP?

Een programma van eisen voor ERP is het document waarmee u de markt bevraagt en waarin u vastlegt wat het nieuwe systeem en de leverancier moeten leveren. Het bepaalt welke antwoorden u terugkrijgt, want leveranciers reageren uitsluitend op wat erin staat.

Een goed document beschrijft problemen en gewenste uitkomsten, zodat leveranciers hun eigen route mogen voorstellen.

Wie stelt het programma van eisen op?

De organisatie zelf stelt het programma van eisen op, met de mensen die de processen dagelijks uitvoeren als bron en het MT als eigenaar van de prioritering. Een partij die meedoet aan de selectie hoort niet mee te schrijven aan het document.

Wel kan een onafhankelijke begeleider helpen bij structuur en formulering, mits die partij geen belang heeft bij de uitkomst.

Hoeveel eisen horen er in een programma van eisen?

Beperk de must-haves tot de eisen waarbij u kunt benoemen wat er misgaat als het systeem ze mist, en zet al het overige lager in de prioritering. De verhouding tussen de prioriteitsklassen telt zwaarder dan het totaalaantal.

Een lijst met honderden must-haves maakt vergelijken lastig, omdat de leverancier dan zelf bepaalt welke eisen zwaar wegen.

Moet u het programma van eisen delen met leveranciers?

Ja, deel het volledige document met alle leveranciers tegelijk en in dezelfde versie. Alleen dan zijn de antwoorden onderling vergelijkbaar en ziet u welke partij uw proces werkelijk heeft begrepen.

Deel het pas nadat de prioritering vaststaat. Wijzigingen daarna kosten in onze ervaring onderhandelingsruimte, omdat het aanbod al op de oude tekst is gebouwd.

---