Zestig regels in een spreadsheet, na één week. Zo ziet het begin van veel ERP-trajecten eruit: iedereen levert zijn wensen aan, en de lijst groeit. Het voelt als een goede basis. Toch is requirements opstellen voor je ERP iets anders dan wensen verzamelen. Wie elke wens uitdaagt met de vraag waarom en hem een plek geeft in het proces, ziet een deel van het maatwerk vanzelf wegvallen.
Dat het misgaat bij het verzamelen, zei Odoo op Odoo Experience 2026 zelf. Een business analist van Odoo hield er een sessie over met een duidelijke titel: stop met requirements verzamelen, begin ze uit te dagen. De strekking: projecten lopen zelden vast op wensen die ontbreken, wel op wensen die zonder tegenvraag worden aangenomen. Een tweede sessie van Odoo ging over wat een slechte analyse in echte projecten kost. Ik zou die titel boven elke analyse hangen. Wij beginnen een traject er in elk geval mee.
Waarom verzamelen niet werkt
Een wensenlijst voelt grondig. Iedereen is gehoord, alles staat erop. Toch loopt het daar vaak mis:
- Elke regel is al een oplossing. "Een extra knop", "een eigen rapport", "een koppeling met de planning". De vraag eronder staat er niet bij.
- Alles lijkt even belangrijk. Zonder waarom kun je niet kiezen, dus wint wie het hardst roept.
- Je kunt niet testen. Nergens staat wanneer het probleem is opgelost.
- Tegenstrijdigheden blijven onzichtbaar. Tot de bouwers erop stuiten, en dan kost het meerwerk.
Wie zo'n lijst één op één laat bouwen, krijgt maatwerk dat het oude werk nabootst. En maatwerk moet bij elke upgrade mee.
Requirements opstellen voor je ERP begint bij waarom
Een requirement beschrijft de behoefte, niet de oplossing. Daar kom je met één vraag: waarom? Op onze pagina over behoeftes en functionaliteit staan de vijf vragen die we per behoefte stellen:
- Welk probleem speelt er?
- Waardoor ontstaat het?
- Wat is de impact?
- Welke workaround houdt het nu overeind?
- Waar ontbreekt de regie?
Beantwoord je die vijf, dan heb je geen wens meer, maar een requirement dat je kunt bouwen en testen.
Van wens naar requirement: een voorbeeld
De wens: "Ik wil een knop op de offerte die de pdf naar de planning mailt." Waarom? De planning hoort te laat dat een order rond is. Waardoor? Verkoop meldt het nu per mail, en dat vergeet iemand weleens. En de impact is dat monteurs stilstaan of voor niets rijden.
De behoefte is dus niet een knop. Het is: "De planner ziet een bevestigde order snel in zijn planning", met als norm: snel is binnen een uur. Eén zin, één behoefte, en het vage woord is meetbaar gemaakt. Dat is meteen het verschil tussen een wens en een requirement: de wens beschrijft een oplossing, de requirement de behoefte erachter, in een zin die je kunt toetsen.
Nu pas kies je de oplossing. Vaak dekt de standaard het al, met een status of een automatische taak. Soms is een kleine automatisering nodig. Een eigen knop met een mailtje is zelden het antwoord.
Uitdagen is niet wegpraten
Er zit een grens aan het doorvragen. Soms klinkt iets als een oplossing, maar is het een beperking die gewoon vaststaat: een systeem dat blijft, een datum, een budget, de capaciteit van je team. In de methode waarmee we requirements schrijven, is een beperking op techniek, tijd, geld of capaciteit een volwaardige requirement. Die noteer je als beperking. Wegpraten helpt dan niemand, want hij komt bij het bouwen toch terug.
Elke wens krijgt een plek in je proces
Een requirement zweeft niet los. Hij hoort bij een stap in je proces, zodat je ziet wat hij raakt en wie er iets van merkt. Hang elke behoefte aan een processtap, van aanvraag tot factuur, met wie wat doet. Geef hem een belang en een urgentie: essentieel en urgent gaat in deze fase, gewenst en niet urgent wacht. En werk het proces dat de doorstroom bepaalt, het knelpunt, als eerste uit. De rest komt in een volgend kwartaal.
Zo wordt de lijst van zestig regels een geordend overzicht. Een deel blijkt dubbel, een deel blijkt een workaround voor een probleem dat elders zit, en wat de standaard al dekt, valt af. Dat is ook hoe je onnodig maatwerk in Odoo voorkomt. Wat overblijft, bouw je bewust, met een reden die je later nog terugvindt.
Zo werken we bij Newway
In de analyse schrijven we de behoeftes uit, hangen ze aan het proces en kiezen we het knelpunt. Pas daarna komt de vraag hoe Odoo het invult: zo standaard als kan, zo maatwerk als nodig. Meer over die eerste stap lees je bij procesoptimalisatie.
Het maatwerk dat overblijft, is bewust gekozen. Dat scheelt bij elke volgende versie, want maatwerk moet mee bij de upgrade en wordt onderdeel van het kwartaalritme van ons beheer. Ook met alles wat Odoo 20 nieuw meebrengt begint een goede inrichting bij deze analyse, niet bij de nieuwe functies.
Twee vragen vooraf
Wie stelt de requirements op bij een ERP-implementatie? De mensen die het werk doen, leveren de inhoud. Een analist vraagt door, schrijft de behoeftes uit en hangt ze aan het proces. Een besluiter aan klantkant bepaalt of de lijst klopt en wat voorrang krijgt. Ontbreekt een van die rollen, dan wordt het een lijst van wie het hardst riep.
Hoe herken ik een wens die eigenlijk een oplossing is? Er staat een middel in, zoals een knop of een rapport. "Een knop die de offerte mailt" is een wens. "De planner ziet een bevestigde order binnen een uur" is een requirement. Pas dan kies je de oplossing.
Welke wens op jouw lijst zou de vraag "waarom?" niet overleven? Vraag een impactscan aan
Luc Castermans was op Odoo Experience 2026 en schrijft in Hoe Odoo?! over Odoo inzetten zoals het bedoeld is.
