Programma van eisen voor HR-software: maak eisen die je kunt testen
Vertaal werkproblemen naar duidelijke, geprioriteerde eisen. Zo vergelijk je leveranciers op bewijs in plaats van op een lange lijst functies.
Wat is een programma van eisen voor HR-software?
Een programma van eisen, vaak afgekort tot PvE, beschrijft waaraan een nieuwe oplossing moet voldoen. Voor HR-software gaat het niet alleen om functies. Het document moet ook duidelijk maken welke processen worden ondersteund, wie welke rechten nodig heeft, welke gegevens worden gebruikt, welke koppelingen belangrijk zijn en hoe invoering en beheer worden geregeld.
Het verschil met een wensenlijst zit in de toetsbaarheid. De wens ‘het systeem moet gebruiksvriendelijk zijn’ zegt weinig. De eis ‘een leidinggevende moet een verlofaanvraag kunnen beoordelen en de nieuwe status moet voor de medewerker en planner zichtbaar zijn’ kun je wel demonstreren en controleren.
Gebruik het PvE als gezamenlijke meetlat. Niet iedere leverancier hoeft exact dezelfde schermen of stappen te hebben. Wel moet duidelijk worden of het gewenste resultaat haalbaar is en welke inrichting, koppeling of handmatige stap daarvoor nodig blijft.
Van werkprobleem naar een toetsbare eis
Beschrijf eerst wat nu misgaat. Formuleer daarna het gewenste resultaat en vraag hoe een leverancier dat bewijst.
| Werkprobleem | Voorbeeld van een toetsbare eis |
|---|---|
| Een goedgekeurde verlofaanvraag bereikt de planner te laat. | Na goedkeuring moet de actuele afwezigheid in de planning herkenbaar zijn. Laat in de demo zien wie dit ziet en wat er bij een correctie gebeurt. |
| Nieuwe medewerkers worden in meerdere systemen opnieuw ingevoerd. | Leg vast welke bron leidend is, welke gegevens worden overgenomen en wie een mislukte overdracht herstelt. Test een gewijzigde startdatum. |
| De status van ingediende uren is onduidelijk. | Een medewerker en leidinggevende moeten kunnen zien of uren zijn ingediend, afgekeurd of goedgekeurd en welke actie nog openstaat. |
| Na een functiewijziging blijven oude rechten bestaan. | Een bevoegde eigenaar moet rechten kunnen wijzigen volgens een vast proces. Controleer ook hoe wijzigingen worden vastgelegd en teruggekeken. |
| Een verlopen kwalificatie wordt pas bij het roosteren ontdekt. | De planner moet vóór een definitieve inzet relevante kwalificatie-informatie kunnen controleren. De organisatie blijft verantwoordelijk voor de inhoudelijke beoordeling. |
Begin bij processen, niet bij een lijst modules
Een modulelijst nodigt uit tot ja-of-nee-antwoorden. Daardoor lijkt een pakket al snel compleet, terwijl onduidelijk blijft hoe collega’s ermee werken. Start liever met gebeurtenissen die meerdere rollen raken. Denk aan iemand die in dienst komt, een verlofaanvraag, een roosterwijziging, een ziekmelding of het goedkeuren van uren.
Loop ieder proces van begin tot eind door. Noteer waar informatie ontstaat, wie een besluit neemt, wie daarna verder moet en waar nu wordt gewacht of opnieuw ingevoerd. Neem ook een uitzondering mee. Juist een gecorrigeerde startdatum, afgekeurde urenregel of last-minute roosterwijziging laat zien of de toekomstige werkwijze beheersbaar is.
Kies alleen eisen die helpen bij een echt besluit. Een eigenschap die niemand gebruikt of controleert, maakt het document langer maar de selectie niet beter.
- Benoem de gebeurtenis waarmee het proces start.
- Leg vast welke rollen handelen, controleren en besluiten.
- Beschrijf het gewenste eindresultaat in gewone taal.
- Neem minimaal één belangrijke uitzondering of correctie mee.
- Bepaal welk bewijs je tijdens demo, proef of contractbespreking wilt zien.
Welke onderdelen horen in het programma van eisen?
Gebruik deze onderdelen als kapstok. Werk alleen uit wat nodig is voor jullie selectie en leg bij iedere belangrijke eis eigenaar, prioriteit en bewijs vast.
- Doel en afbakening: welk probleem los je op en welke processen vallen nu buiten de selectie?
- Proces en resultaat: welke stappen, uitzonderingen en goedkeuringen moeten worden ondersteund?
- Gebruikers en rollen: wie mag bekijken, invoeren, wijzigen, goedkeuren en beheren?
- Gegevens en koppelingen: welke bron is leidend, wat wordt uitgewisseld en hoe zie je fouten?
- Privacy en beveiliging: welke gegevens zijn nodig, hoe zijn rechten ingericht en welke afspraken moeten aantoonbaar zijn?
- Invoering en beheer: wie ruimt data op, richt processen in, test, traint en beheert na de livegang?
- Kosten en uitgang: welke licenties, inrichting, koppelingen en gebruikskosten gelden en hoe krijg je gegevens terug bij een latere overstap?
Zo schrijf je een eis die je echt kunt testen
Een toetsbare eis bevat vijf onderdelen: de rol, de aanleiding, de handeling, het zichtbare resultaat en het bewijs. Bijvoorbeeld: ‘Wanneer een medewerker uren indient, moet de aangewezen leidinggevende die uren kunnen beoordelen. Na het besluit zien beiden de status en is duidelijk welke regels nog aandacht vragen. Dit wordt getest met een normale week en een afgekeurde regel.’
Vermijd woorden als snel, eenvoudig, flexibel, modern of volledig zonder uit te leggen wat ze in jullie werk betekenen. ‘Snel’ kan bijvoorbeeld betekenen dat een planner zonder export ziet welke diensten nog openstaan. ‘Eenvoudig’ kan betekenen dat een medewerker een aanvraag zelfstandig kan afronden op een telefoon. Pas wanneer het gedrag en resultaat duidelijk zijn, kun je beoordelen of de oplossing past.
Schrijf ook op wat niet in de eis staat. Als salarisberekening in een apart salarispakket blijft, hoeft HR-software die berekening niet zelf uit te voeren. De eis kan dan gaan over goedgekeurde brongegevens, overdracht, foutmelding en controle.
Vijf velden voor iedere belangrijke eis
Met deze vaste velden blijft de eisenlijst kort, vergelijkbaar en bruikbaar tijdens de demo.
| Veld | Wat leg je vast? |
|---|---|
| Eis | Het gewenste gedrag of resultaat, met rol en aanleiding. |
| Eigenaar | De persoon die bepaalt of het resultaat in de praktijk voldoende is. |
| Prioriteit | Moet nu, belangrijk bij de keuze of later te verbeteren. |
| Bewijs | Een demoscenario, proef, document of afspraak waarmee je de eis controleert. |
| Open vraag | Een afhankelijkheid, uitzondering, koppeling of kostenpost die nog niet duidelijk is. |
Geef prioriteit zonder alles onmisbaar te noemen
Als iedere eis verplicht is, helpt de prioriteit niet meer bij een besluit. Gebruik daarom drie eenvoudige niveaus. ‘Moet nu’ is alleen voor voorwaarden waarbij de oplossing anders niet bruikbaar of verantwoord is. ‘Belangrijk bij de keuze’ onderscheidt oplossingen, maar kent mogelijk een tijdelijke werkwijze. ‘Later te verbeteren’ gaat over waarde die niet nodig is voor de eerste invoering.
Laat de eigenaar van het proces de prioriteit uitleggen. HR kan bijvoorbeeld eigenaar zijn van dossiergegevens, terwijl de planner beoordeelt of een roosterwijziging tijdig en duidelijk zichtbaar wordt. IT, privacy en security beoordelen eisen binnen hun vakgebied. Directie of stuurgroep weegt de uiteindelijke samenhang, kosten en risico’s.
Herzie de prioriteiten nadat je de processen en kosten beter begrijpt. Een koppeling kan minder belangrijk blijken wanneer een duidelijke periodieke overdracht volstaat. Andersom kan een ogenschijnlijk kleine correctieroute doorslaggevend zijn als die dagelijks wordt gebruikt.
Praktijkvoorbeeld: van beschikbaarheid naar goedgekeurde uren
Stel dat planners beschikbaarheid verzamelen, diensten maken en na afloop gewerkte uren laten goedkeuren. Nu staan contracturen in het HR-systeem, beschikbaarheid in berichten, het rooster in een los hulpmiddel en correcties in een spreadsheet. De wens ‘we willen personeelsplanning’ is dan te breed.
Beschrijf in plaats daarvan de keten. Welke medewerker geeft beschikbaarheid door? Wanneer ziet de planner een conflict met verlof of afwezigheid? Wie mag een dienst wijzigen? Hoe wordt een verschil tussen geplande en geregistreerde uren beoordeeld? En welke goedgekeurde gegevens gaan naar de salarisvoorbereiding?
De leverancier hoeft niet te beweren dat alles automatisch gaat. Laat per stap zien wat het systeem ondersteunt, welke inrichting nodig is en waar een mens controleert of beslist. Zo ontstaat een realistisch beeld van de toekomstige werkwijze.
Voorbeeld van een compacte eisenmatrix
De organisatie vult zelf prioriteit, eigenaar en acceptatie in. Dit voorbeeld is geen juridische of functionele garantie.
| Onderwerp | Eis en gewenst bewijs |
|---|---|
| Beschikbaarheid | De medewerker kan beschikbaarheid voor een afgesproken periode doorgeven. Bewijs: voer dit uit op mobiel en toon wat de planner ziet. |
| Roosterconflict | De planner kan relevante afwezigheid of inzetbeperking herkennen vóór publicatie. Bewijs: test een conflict met fictieve gegevens. |
| Wijziging | Na een dienstwijziging zien betrokken rollen de actuele status. Bewijs: wijzig een gepubliceerde dienst en controleer opvolging. |
| Urencontrole | Een aangewezen leidinggevende kan een afwijking beoordelen. Bewijs: keur één regel goed en wijs één regel af met toelichting. |
| Overdracht | Alleen goedgekeurde brongegevens worden klaargezet voor de afgesproken salarisroute. Bewijs: toon selectie, controle en foutafhandeling. |
Neem privacy en toegangsbeheer als concrete eisen op
HR-software verwerkt persoonsgegevens. Vraag daarom niet alleen of een leverancier ‘AVG-proof’ is. Zo’n algemene uitspraak vervangt geen eigen inrichting of beoordeling. Leg vast welke gegevens voor een proces nodig zijn, wie ze mag zien, wie rechten wijzigt, hoe wijzigingen worden vastgelegd en wat er bij in-, door- en uitstroom gebeurt.
De Autoriteit Persoonsgegevens beschrijft privacy by design als het meenemen van gegevensbescherming bij ontwerp en inrichting. Privacy by default betekent dat standaard alleen persoonsgegevens worden verwerkt die nodig zijn voor het doel. Het NCSC adviseert daarnaast om verantwoordelijkheden, gebruikersbeheer, autorisaties en een rollen- of rechtenmatrix vast te leggen.
Vertaal dit naar bewijs. Vraag bijvoorbeeld om een demonstratie met verschillende rollen, een beschrijving van de verwerkersketen, afspraken over gegevensverwijdering en export, en uitleg over logging en beheer. Laat privacy-, security- of IT-specialisten risicovolle eisen beoordelen.
Gebruik hetzelfde PvE tijdens de demonstratie
Stuur niet alleen het document op en wacht op een ingevulde ja-of-nee-lijst. Selecteer de eisen die het besluit bepalen en maak daar scenario’s van. Laat iedere leverancier dezelfde beginsituatie, normale route en belangrijke uitzondering gebruiken. Noteer wat direct werkt, welke inrichting nodig is, wat een koppeling vraagt en welke stap handmatig blijft.
Een positief antwoord is nog geen bewijs. Leg vast of je het gedrag zelf hebt gezien, alleen een toelichting hebt gehoord of een afspraak later in een voorstel moet terugkomen. Koppel open punten aan een eigenaar en datum. Zo voorkom je dat aannames na de demo als zekerheden in het besluit terechtkomen.
Gebruik de eisenmatrix ook bij een proef en bij acceptatie. Daarmee blijft de lijn van werkprobleem naar selectie, inrichting en controle herkenbaar.
Hoe WorkVine langs dezelfde meetlat kan worden beoordeeld
WorkVine is vooral relevant wanneer HR-processen en de dagelijkse operatie elkaar raken. Denk aan de samenhang tussen medewerkergegevens, beschikbaarheid, planning, verlof, verzuim, uren en opvolging. De precieze waarde hangt af van jullie processen, inrichting en de rollen die ermee werken.
Gebruik daarom ook bij WorkVine dezelfde toetsbare eisen. Laat een eigen keten zien, inclusief een correctie of uitzondering. Vraag welke onderdelen binnen het platform vallen, welke koppelingen of afspraken nodig zijn en waar een leidinggevende of specialist verantwoordelijk blijft voor de beslissing.
Een ander pakket kan beter passen wanneer de belangrijkste vraag op zichzelf staat, een zeer specialistische functie vraagt of al goed wordt ondersteund door bestaande systemen. Het doel van een PvE is niet om vooraf één leverancier gelijk te geven, maar om zichtbaar te maken welke oplossing het beste aansluit op het werk dat echt moet gebeuren.
Vermijd deze fouten in je eisenlijst
Controleer de conceptlijst samen met de proceseigenaren. Deze fouten maken een vergelijking langer, maar niet duidelijker.
- Honderden functies opnemen zonder te beschrijven welk werkprobleem ze oplossen.
- ‘Gebruiksvriendelijk’, ‘flexibel’ of ‘veilig’ eisen zonder zichtbaar gedrag en bewijs.
- Alle wensen de hoogste prioriteit geven.
- Alleen de normale route testen en correcties of uitzonderingen overslaan.
- Een koppeling als afgerond beschouwen zonder bron, eigenaar, controle en foutafhandeling te benoemen.
- Kosten voor inrichting, beheer, gebruik en een latere gegevensoverdracht vergeten.
- Een leveranciersantwoord verwarren met een getoonde werking of vastgelegde afspraak.
Hoe uitgebreid moet een programma van eisen zijn?
Er is geen ideaal aantal eisen. Neem genoeg eisen op om de beslissende processen, rollen, gegevens, risico’s en invoering te beoordelen. Schrap herhaling en onderdelen die geen invloed hebben op het besluit. Een korte lijst met eigenaarschap en bewijs is vaak bruikbaarder dan een groot document met algemene vinkjes.
Wat is het verschil tussen een eis en een wens?
Een eis beschrijft een noodzakelijk of belangrijk resultaat dat je kunt toetsen. Een wens beschrijft extra waarde, maar is niet doorslaggevend voor de eerste keuze of invoering. Geef beide een prioriteit en eigenaar, zodat een wens niet ongemerkt als harde voorwaarde wordt behandeld.
Moet iedere eis een softwarefunctie noemen?
Nee. Beschrijf liever het gewenste werkresultaat. Een leverancier kan dat resultaat mogelijk op een andere manier bereiken dan je vooraf verwacht. Leg wel grenzen vast wanneer een handmatige stap, aparte koppeling of aanvullende dienst niet acceptabel is.
Wie moet het programma van eisen goedkeuren?
Laat proceseigenaren hun eisen en prioriteiten bevestigen. Betrek dagelijkse gebruikers bij de werkwijze, IT bij techniek en beheer, en privacy of security bij relevante risico’s. Leg vast wie het uiteindelijke besluit neemt en wie na invoering eigenaar blijft van ieder belangrijk proces.
Bronnen en controledatum
Bronnen gecontroleerd op 16 september 2026. De selectieaanpak in dit artikel is praktische redactionele uitleg van WorkVine. Organisaties blijven zelf verantwoordelijk voor hun eisen, privacybeoordeling, beveiligingskeuzes, contracten en uiteindelijke acceptatie.