Een leverancier laat een overtuigende demo zien, de software heeft tientallen functies en op papier lijkt bijna alles mogelijk. Toch zegt dat nog weinig over de vraag of het systeem ook past bij de manier waarop jouw organisatie werkt. Zonder duidelijke eisen wordt een softwareselectie al snel een vergelijking van functies die misschien helemaal niet belangrijk zijn.
Een requirementslijst helpt om dat te voorkomen. Hierin leg je vooraf vast wat de nieuwe software moet ondersteunen, welke eisen noodzakelijk zijn en waar ruimte zit voor alternatieven. Zo vergelijk je leveranciers niet op gevoel, maar op dezelfde uitgangspunten.
In het kort
Een requirementslijst vertaalt de behoeften van je organisatie naar concrete eisen voor nieuwe software. Een goede lijst:
- begint bij processen en knelpunten, niet bij functies;
- maakt onderscheid tussen eisen en wensen;
- beschrijft wat de software moet kunnen;
- bevat ook voorwaarden rond integraties, gebruiksgemak en beheer;
- geeft iedere requirement een prioriteit;
- wordt gebruikt om leveranciers op dezelfde punten te beoordelen.
De lijst hoeft niet honderden regels lang te zijn. Een compacte set goed geformuleerde software requirements is vaak bruikbaarder dan een uitgebreid document waarin vrijwel iedere denkbare functie is opgenomen.
Wat is een requirementslijst voor software?
Een requirementslijst is een overzicht van voorwaarden waaraan nieuwe software moet voldoen. Zo’n document wordt ook wel een programma van eisen voor software genoemd. De requirements kunnen betrekking hebben op functionaliteit, techniek, gebruikers, integraties, beveiliging en dienstverlening.
Het belangrijkste is dat een requirement duidelijk maakt wat een gebruiker of organisatie nodig heeft. “Goede rapportages” is bijvoorbeeld nog erg breed. Beter is om vast te leggen welke informatie een manager daadwerkelijk moet kunnen zien, zoals omzet, openstaande kansen of voorraad per locatie.
Door requirements concreet te formuleren, ontstaat tijdens de selectie minder discussie over wat een leverancier precies wel of niet ondersteunt.
Begin niet bij de software, maar bij het probleem
Requirements opstellen begint niet met het openen van leverancierswebsites. Kijk eerst naar de huidige situatie. Waar verliezen medewerkers tijd? Welke gegevens worden dubbel ingevoerd? Waar ontstaan fouten? Welke informatie ontbreekt? En welke processen lopen buiten het bestaande systeem om?
Dat sluit aan op de 7 vragen die je moet stellen vóór je software kiest. Een softwareselectie wordt een stuk gerichter wanneer vooraf duidelijk is welk probleem het nieuwe systeem moet oplossen.
Betrek daarbij ook medewerkers die dagelijks met de processen werken. Een manager kijkt misschien vooral naar rapportages, terwijl een medewerker merkt dat dezelfde klantgegevens op drie verschillende plekken worden bijgehouden. Beide perspectieven leveren waardevolle requirements op.
Welke requirements neem je op?
Bij bedrijfssoftware selecteren wordt vaak als eerste aan functies gedacht. Die zijn belangrijk, maar vormen slechts een deel van de eisen en wensen voor software.
Een requirementslijst kan bijvoorbeeld voorwaarden bevatten rond:
- Functionaliteit: welke werkzaamheden moet het systeem ondersteunen?
- Integraties: met welke bestaande systemen moet gegevensuitwisseling mogelijk zijn?
- Data: welke gegevens moeten worden opgeslagen, geïmporteerd of geëxporteerd?
- Gebruikers: wie werkt met de software en welke rechten zijn nodig?
- Gebruiksgemak: moet het systeem bijvoorbeeld mobiel beschikbaar zijn?
- Techniek: cloud, API-mogelijkheden en andere technische voorwaarden.
- Beveiliging: toegangsbeheer, logging en gegevensopslag.
- Rapportage: welke informatie moet beschikbaar zijn en voor wie?
- Dienstverlening: eisen rond implementatie, training en ondersteuning.
- Schaalbaarheid: moet de software kunnen meegroeien met gebruikers, locaties of processen?
Juist de niet-functionele software requirements worden makkelijk vergeten. Een pakket kan alle gewenste functies hebben en alsnog ongeschikt zijn omdat een belangrijke koppeling ontbreekt of het dagelijkse beheer te ingewikkeld is.
Probeer iedere requirement bovendien zo te formuleren dat je hem later kunt controleren. In plaats van alleen “gebruiksvriendelijk” op te schrijven, kun je bijvoorbeeld vastleggen dat een verkoopmedewerker zonder hulp van IT zelfstandig een nieuwe klant en verkoopkans moet kunnen registreren.
Requirements prioriteren met de MoSCoW-methode
Niet iedere wens is even belangrijk. Wanneer alles op de requirementslijst een harde eis wordt, blijven uiteindelijk weinig leveranciers over. Bovendien kan een relatief onbelangrijke functie dan even zwaar wegen als een proces dat iedere dag wordt gebruikt.
Een bekende manier om requirements te prioriteren is de MoSCoW-methode:
- Must have: zonder deze requirement valt de software af.
- Should have: belangrijk, maar een alternatief is mogelijk.
- Could have: waardevol, maar niet doorslaggevend.
- Won’t have: bewust buiten de huidige selectie gehouden.
Stel dat een organisatie een nieuw CRM-systeem zoekt. Een koppeling met de bestaande e-mailomgeving kan een Must have zijn, terwijl automatische AI-samenvattingen van gesprekken misschien een Could have zijn.
Door vooraf prioriteiten toe te kennen, voorkom je dat een opvallende extra functie tijdens een demo belangrijker wordt dan de software requirements die voor het dagelijkse werk echt nodig zijn.
Hoe ziet een praktische requirementslijst eruit?
Een requirementslijst hoeft geen ingewikkeld document te worden. Voor veel organisaties is een spreadsheet voldoende.
Je kunt bijvoorbeeld per requirement vastleggen:
- wat het systeem moet ondersteunen;
- welke afdeling de requirement heeft aangeleverd;
- waarom deze belangrijk is;
- welke MoSCoW-prioriteit erbij hoort;
- of een leverancier hier standaard aan voldoet;
- of configuratie, een koppeling of maatwerk nodig is.
Een regel kan dan bijvoorbeeld zijn:
Klantgegevens centraal beheren — Must have — Sales — voorkomt losse bestanden en dubbele invoer.
Of:
Dashboard met verkoopresultaten per medewerker — Should have — Salesmanagement — meer inzicht in prestaties.
Zo ontstaat een lijst die tijdens de selectie eenvoudig is uit te breiden met de antwoorden van verschillende leveranciers.
Een requirementslijst voor CRM is anders dan voor ERP
Welke requirements je opstelt, hangt sterk af van het type bedrijfssoftware dat je zoekt.
Bij CRM (Customer Relationship Management) ligt de nadruk bijvoorbeeld op klantgegevens, verkoopkansen, marketing, contactmomenten en klantenservice. Bij een ERP-systeem kunnen juist financiën, inkoop, voorraad, productie en andere bedrijfsprocessen centraal staan.
Twijfel je nog welk type systeem nodig is, dan is het verstandig dat eerst duidelijk te krijgen. In CRM vs. ERP: wat is het verschil? leggen we uit waar beide soorten software elkaar overlappen en waar de verschillen zitten.
Een generieke requirementslijst van internet volledig overnemen werkt daarom zelden goed. Die lijst weet immers niets over je eigen processen, knelpunten of bestaande softwareomgeving.
Gebruik requirements om software eerlijk te vergelijken
Wanneer de eisen zijn opgesteld, begint de daadwerkelijke softwareselectie. De requirementslijst zorgt ervoor dat iedere leverancier vanuit dezelfde basis wordt beoordeeld.
Per requirement kun je bijvoorbeeld onderscheid maken tussen:
- standaard aanwezig;
- mogelijk na configuratie;
- externe koppeling nodig;
- alleen mogelijk met maatwerk;
- niet beschikbaar.
Dat verschil is belangrijk. Twee leveranciers kunnen allebei aangeven dat een bepaalde functie mogelijk is, terwijl de ene oplossing dit standaard ondersteunt en de andere eerst maatwerk nodig heeft.
Een goede requirementslijst maakt daardoor ook de kosten beter zichtbaar. Niet alleen licenties tellen mee, maar ook implementatie, datamigratie, koppelingen, training en maatwerk. In Wat kost bedrijfssoftware echt? lees je welke kosten bij een selectie makkelijk over het hoofd worden gezien.
Laat de softwaredemo aansluiten op je requirements
Een standaarddemo laat meestal zien waar een leverancier goed in is. Dat hoeft niet hetzelfde te zijn als waar jouw organisatie behoefte aan heeft.
Kies daarom een paar belangrijke processen uit de requirementslijst en laat leveranciers deze tijdens de demo uitvoeren. Zoek je CRM-software, laat dan bijvoorbeeld zien hoe een lead binnenkomt, wordt opgevolgd en uiteindelijk wordt omgezet naar een verkoopkans.
Bij een ERP-systeem kan een scenario beginnen bij een klantorder en vervolgens doorlopen naar voorraad, inkoop en financiële verwerking. Zo verandert een demo van een verkooppresentatie in een praktische test. Je ziet niet alleen óf een functie aanwezig is, maar ook hoe medewerkers ermee moeten werken.
Veelgemaakte fouten bij requirements opstellen
Een requirementslijst moet de softwarekeuze eenvoudiger maken. Toch kan hij juist voor extra complexiteit zorgen wanneer de lijst verkeerd wordt opgebouwd.
Veelvoorkomende fouten zijn:
- iedere wens als harde eis behandelen;
- bestaande processen één op één in nieuwe software willen kopiëren;
- alleen managers laten bepalen wat nodig is;
- requirements rechtstreeks van een leverancier overnemen;
- te gedetailleerd voorschrijven hoe iets technisch moet worden opgelost;
- integraties en beheer vergeten;
- honderden eisen opnemen zonder prioriteiten;
- tijdens de selectie voortdurend nieuwe eisen toevoegen.
Vooral een te lange lijst kan contraproductief worden. Wanneer honderden kleine requirements allemaal moeten worden afgevinkt, raakt het oorspronkelijke doel van de softwareselectie uit beeld.
Bepaal daarom eerst welke processen echt belangrijk zijn en welke requirements aantoonbaar verschil maken voor de organisatie.
Een goede softwareselectie begint vóór het vergelijken
De grootste fout bij software selectie is misschien wel te snel naar leveranciers kijken. Een bekende naam, moderne interface of lange lijst functies zegt weinig wanneer niet duidelijk is wat je organisatie werkelijk nodig heeft.
Een requirements lijst dwingt je om die vraag eerst te beantwoorden. Welke processen moeten beter? Welke functies zijn noodzakelijk? Waar kunnen compromissen worden gemaakt? En welke voorwaarden zijn belangrijk voor gebruikers, IT en management?
Daarna wordt software vergelijken een stuk concreter. Leveranciers worden langs dezelfde software selectiecriteria gelegd en een demo kan worden gebruikt om de belangrijkste processen daadwerkelijk te testen.
De requirements blijven bovendien bruikbaar nadat een pakket is gekozen. Tijdens de implementatie en acceptatietest kun je opnieuw controleren of de belangrijkste Must-have-eisen daadwerkelijk zijn ingericht.
Zo wordt een requirementslijst niet alleen een hulpmiddel om software te kiezen, maar ook een basis voor een betere implementatie. Je zoekt uiteindelijk niet naar het pakket dat op papier het meeste kan, maar naar software die aansluit op de eisen, wensen en dagelijkse praktijk van je organisatie.