Do we really need a requirements spec for the ERP selection, or just a longer wish list?

A requirements spec helps, but only as the result of clean process capture, not as a collected feature wish list from every department. The value arises in the pre-project: first understand how you really work and where your complexity sits, then derive the requirements from that. A requirements spec without this foundation leads to the wrong choice.

If you want to gather requirements in a structured way: the ERP requirements generator

Which two kinds of requirements documents exist?

One is a collection of feature wishes, often hundreds of lines, every department contributes. The other is the condensed description of how your core processes run and what a system has to support of them. Only the second helps in the selection.

The feature wish list feigns thoroughness. It rewards the system with the most ticks, not the one with the best fit for your real work. Vendors predictably tick off almost everything, that separates no one.

The difference shows in the length: a process description of your five or six value-creating flows fits on a few pages. A feature list grows into three-digit line counts and is still never complete, because every department adds whatever comes to mind. Its length is therefore not a mark of quality but rather a warning sign: it shows that nobody has condensed, weighted and prioritised.

Why does process mapping come first?

Before even a single requirement is written down, the following belongs on the table:

• Which processes make you special and where your complexity arises.
• Which workflows are only historically grown.
• What truly sets you apart from the competition, and what the standard can do anyway.

These three questions sound simple and are not. Answering them means agreeing on a shared reading inside your own house, and that agreement is missing in most selection projects. The effort for it is manageable, but it can neither be delegated nor handed over to a vendor.

This separation of the differentiating from the standard is worth more than any feature list. Only out of that clarity comes a specification that asks the right question, namely whether a system really carries your value-creating flows, and not whether it ticks three hundred boxes.

Why is the requirements document a means, not an end?

The specification is meant to sharpen the selection and later to steer the implementation. If it becomes an end in itself, it costs months and commits nobody. For a complex selection the rule is: better to think a few well-understood processes through deeply than to survey a hundred functions superficially. In a complex selection, depth beats completeness, clearly and demonstrably.

The useful test once it is finished reads: can a vendor derive from it where our project will get difficult? If not, the document describes wishes rather than reality, and then it will not carry the later decisions either.

If you are facing an ERP selection and do not want to land in the wish-list trap, in the pre-project we capture your core processes and derive from them what a system really has to support. Control stays on your side, with Business Central as our home ground.