Hoe stel je een programma van eisen op voor ERP-selectie?

Een programma van eisen voor ERP-selectie stel je op door gestructureerd de functionele en niet-functionele behoeften van je organisatie in kaart te brengen, deze te prioriteren en te vertalen naar toetsbare criteria waarop je leveranciers kunt beoordelen. Voor woningcorporaties betekent dit concreet dat je de eisen afstemt op zowel de primaire verhuurprocessen als de specifieke wet- en regelgeving in de sociale huursector. De vragen hieronder loodsen je stap voor stap door het volledige proces.

Wat moet er minimaal in een programma van eisen staan?

Een programma van eisen voor ERP bevat minimaal een beschrijving van de organisatiecontext, een gestructureerde lijst van functionele eisen per bedrijfsproces, niet-functionele eisen op het gebied van techniek en beveiliging, integratie-eisen met bestaande systemen, en heldere prioriteiten per eis. Zonder deze bouwstenen kun je leveranciers niet objectief met elkaar vergelijken.

Voor woningcorporaties zijn de functionele eisen vaak gekoppeld aan de kernprocessen: verhuur en toewijzing, vastgoedbeheer, financiële administratie, onderhoud en huurderscommunicatie. Elk van deze domeinen verdient een eigen sectie in het document, zodat de beoordelaars tijdens de ERP-pakketselectie precies weten welke functionaliteit ze moeten toetsen.

Naast de inhoudelijke eisen hoort er ook een procesgedeelte in het document: wie heeft het document goedgekeurd, wat is de scope van de implementatie, en welke randvoorwaarden gelden voor de leverancier? Dit gedeelte is niet glamoureus, maar het voorkomt misverstanden zodra onderhandelingen beginnen.

Hoe verzamel je de juiste eisen van alle stakeholders?

Je verzamelt de juiste eisen door gestructureerde interviews en workshops te organiseren met vertegenwoordigers uit alle betrokken afdelingen, aangevuld met een analyse van bestaande procesbeschrijvingen en knelpuntenregistraties. Zorg dat zowel de eindgebruikers als het management aan tafel zitten, want zij kijken vanuit fundamenteel verschillende perspectieven naar hetzelfde systeem.

Begin met een stakeholderanalyse: breng in kaart wie dagelijks met het huidige systeem werkt, wie verantwoordelijk is voor de data en wie de strategische beslissingen neemt. Bij woningcorporaties zijn dat doorgaans medewerkers van verhuur, financiën, technische dienst, ICT en het managementteam. Elk van deze groepen heeft legitieme eisen die in het eindproduct terecht moeten komen.

Een beproefde aanpak is werken met thematische sessies per proces in plaats van één grote bijeenkomst. Zo krijg je diepgang per domein en voorkom je dat de luidste stem in de zaal het beeld bepaalt. Vat elke sessie schriftelijk samen en laat deelnemers de uitkomsten valideren voordat je verder gaat. Dit co-creatieve principe zorgt voor draagvlak en voorkomt dat eisen later worden betwist.

Wat is het verschil tussen functionele en niet-functionele eisen?

Functionele eisen beschrijven wat het systeem moet kunnen doen, zoals het registreren van huurcontracten of het genereren van een factuur. Niet-functionele eisen beschrijven hoe het systeem moet presteren, zoals beschikbaarheid, verwerkingssnelheid, beveiliging en schaalbaarheid. Beide categorieën zijn even belangrijk, maar worden vaak verward of door elkaar gebruikt.

Functionele eisen in de praktijk

Functionele eisen zijn procesgebonden. Ze beschrijven een concrete actie die een gebruiker of het systeem moet kunnen uitvoeren. Voorbeelden voor een woningcorporatie zijn: het systeem moet automatisch een huurverhoging kunnen doorvoeren op basis van de jaarlijkse indexering, of het systeem moet een wachtlijst kunnen beheren met meerdere toewijzingscriteria. Hoe specifieker deze eisen zijn, hoe beter leveranciers ze kunnen aantonen tijdens een demo.

Niet-functionele eisen in de praktijk

Niet-functionele eisen bepalen de kwaliteit van de oplossing. Denk aan: het systeem moet 99,9% beschikbaar zijn tijdens kantooruren, persoonsgegevens moeten versleuteld worden opgeslagen conform de AVG, en de responstijd bij een zoekopdracht mag niet meer dan twee seconden bedragen. Deze eisen zijn lastiger te demonstreren in een verkoopgesprek, maar zijn bij implementatie en beheer minstens zo bepalend voor het succes.

Hoe prioriteer je eisen zonder het overzicht te verliezen?

Je prioriteert eisen door elke eis in te delen in drie categorieën: must-have (onmisbaar voor de bedrijfsvoering), should-have (sterk gewenst maar overbrugbaar) en nice-to-have (wenselijk maar niet doorslaggevend). Deze MoSCoW-methode geeft structuur en maakt het voor alle betrokkenen direct helder welk gewicht een eis heeft.

De valkuil bij prioritering is dat stakeholders vrijwel alles als must-have bestempelen. Doorbreek dit patroon door bij elke eis de vraag te stellen: wat is de concrete impact als dit niet beschikbaar is op de eerste dag van productie? Als het antwoord is dat de organisatie gewoon verder kan draaien, is het geen must-have. Dit vraagt soms wat begeleiding, maar levert een eerlijk en bruikbaar document op.

Werk vervolgens met een gewogen scoremodel. Ken aan elke categorie een punt toe en gebruik dit model consistent bij de leveranciersbeoordeling. Zo voorkom je dat subjectieve voorkeur de selectie bepaalt en kun je de keuze achteraf verantwoorden aan bestuur en toezichthouders.

Wanneer is een programma van eisen goed genoeg om te starten?

Een programma van eisen is goed genoeg om te starten wanneer alle must-have-eisen zijn gevalideerd door de betrokken afdelingen, de prioritering is vastgesteld door het beslissingsbevoegde management en het document intern is goedgekeurd. Perfectie is geen vereiste; een werkbaar en gedragen document is waardevoller dan een uitputtende lijst die niemand heeft gelezen.

Een praktische toets is de zogenoemde leverancierstest: stuur het document intern langs iemand die de organisatie niet van binnen kent en vraag of zij begrijpen wat er gevraagd wordt. Als de eisen onduidelijk of tegenstrijdig zijn voor een buitenstaander, zijn ze dat ook voor leveranciers. Pas het document aan totdat de boodschap helder is.

Wees ook realistisch over de scope. Een programma van eisen voor een volledige ERP-vervanging bij een middelgrote corporatie bevat doorgaans enkele honderden eisen verdeeld over meerdere modules. Als je nog maar twintig eisen hebt geformuleerd, is het document waarschijnlijk niet volledig genoeg. Als je over duizend eisen hebt, is de kans groot dat je in details bent verdwaald die tijdens de selectie niet relevant zijn.

Hoe gebruik je het programma van eisen tijdens de leveranciersbeoordeling?

Tijdens de leveranciersbeoordeling gebruik je het programma van eisen als objectief toetsingskader: leveranciers beantwoorden elke eis schriftelijk en demonstreren de must-haves live in een demo. Door alle beoordelaars hetzelfde scoreformulier te laten invullen, vergelijk je aanbiedingen op een eerlijke en transparante manier.

Structureer de demo-sessies zo dat leveranciers jouw processen demonstreren in plaats van hun eigen verkoopverhaal. Geef ze vooraf een concreet scenario, gebaseerd op een herkenbare situatie uit jouw organisatie, en vraag ze dat scenario stap voor stap te doorlopen in het systeem. Zo zie je direct of de functionaliteit echt beschikbaar is of slechts op de roadmap staat.

Na de demo vul je per eis de score in op basis van de vooraf bepaalde criteria. Wij adviseren corporaties om de scores direct na de sessie in te vullen, terwijl de indrukken nog vers zijn. Het samenvoegen van de individuele scores geeft een geaggregeerd beeld dat de basis vormt voor de shortlist en uiteindelijk de leveranciersselectie.

Welke fouten maken corporaties het vaakst bij het opstellen van eisen?

De meest voorkomende fouten bij het opstellen van een programma van eisen voor ERP zijn: te laat beginnen, te weinig eindgebruikers betrekken, eisen formuleren als oplossingen in plaats van behoeften, en verzuimen om niet-functionele eisen op te nemen. Elk van deze fouten vergroot de kans op een mismatch tussen het gekozen systeem en de dagelijkse praktijk.

Te laat beginnen is misschien wel de meest kostbare fout. Een goed programma van eisen vraagt weken van voorbereiding en afstemming. Corporaties die dit pas opstarten nadat de directie al een voorkeursleverancier heeft gekozen, gebruiken het document als formaliteit in plaats van als sturend instrument.

Eisen formuleren als oplossingen is een subtiele maar veelgemaakte fout. Een eis als “het systeem moet werken met module X van leverancier Y” sluit andere leveranciers bij voorbaat uit en beperkt de mededinging. De juiste formulering beschrijft de behoefte: “het systeem moet huurbetalingen automatisch kunnen verwerken en koppelen aan de juiste huurovereenkomst.” Zo blijft de selectie open en objectief.

Tot slot onderschatten corporaties regelmatig het belang van integratie-eisen. Het nieuwe ERP-systeem staat nooit op zichzelf; het moet koppelen met woningzoekendenportalen, financiële rapportagetools en soms met systemen van externe partijen. Als deze koppelingseisen ontbreken in het programma van eisen, komen ze alsnog naar boven tijdens de implementatie, maar dan tegen aanzienlijk hogere kosten en tijdsdruk.

Wil je zeker weten dat jouw programma van eisen volledig en goed onderbouwd is voordat je de markt op gaat? Neem gerust contact met ons op; we denken graag met je mee.