ERP Selection in Mid-Sized Companies: Why the Requirements Document Is the Most Expensive Mistake

The most thorough company I accompanied through an ERP selection chose the worst vendor. 200 pages of requirements. 6 months to write. 14 vendors contacted, 8 invited, 4 shortlisted. A process that any project management professor would have applauded.

The result: A system that perfectly fits the old processes — not the future ones. An implementation partner who impressed in the demo but was overwhelmed in execution. And a go-live that came 14 months later than planned.

The mistake wasn’t a lack of thoroughness. The mistake was the wrong kind of thoroughness. This pattern is a core focus of my ERP consulting for SMEs — and one of the most common reasons I get called in.

ERP Requirements Document in SMEs: What It Really Is and What It Cannot Do

A classic ERP requirements document lists demands. Hundreds of them. “The system must support multiple entities.” “The system must manage bills of materials with up to 5 levels.” “The system must provide a DATEV interface.” Each requirement gets a priority: Must, Should, Could.

The problem isn’t what’s in it. The problem is what’s missing.

The Requirements Document Describes the Current State

When departments formulate requirements, they describe their current workflows. “We need a field for manual quantity adjustment” — because that’s how procurement works today, not because it’s the optimal process. The requirements document cements old processes instead of enabling new ones.

Vendors Optimize for Checkboxes

A requirements document with 300 items becomes a tick-box game. Every vendor claims: “Yes, we can do that.” The differences between “the system does this natively,” “possible with customization,” and “theoretically possible if you invest 80 consulting days” disappear behind a green checkmark.

The result: all vendors look the same. The decision ultimately comes down to price — which in ERP projects is the worst decision factor of all, because the real costs lie in implementation, not in licensing.

6 Months of Writing Is 6 Months Without Progress

While the requirements document is being written, nothing operational happens. No process optimization, no test installations, no learning. The document becomes an alibi for standstill. “We’re in the requirements phase” — a sentence that keeps projects alive for months without creating value.

ERP Selection Without Requirements Document: What Works Instead

Process Workshops Instead of Feature Lists

Germany’s Bitkom association also recommends in its ERP guides shifting focus from feature lists to processes. Instead of listing 300 features, define your 10–15 core processes. How does the process run from customer order to delivery? From goods receipt to payment? From production order to finished product?

Map these processes — not as they run today, but as they should run. This forces departments to think about improvements instead of describing the status quo. And it gives ERP vendors the opportunity to show their strengths in a process context, instead of ticking checkboxes.

Reference Visits Instead of Demo Appointments

A three-hour demo where the sales consultant presents the system with test data is nearly worthless. He shows the ideal case with his test data. Your reality looks different.

What works: Visit 2–3 existing customers of the vendor. Not the reference customers they recommend — but companies in your industry and size range. Ask: How did the implementation really go? What would you do differently? How is support after go-live?

The answers to these questions tell you more about vendor quality than any demo or requirements document.

Implementation Partner as the Main Criterion

The software is interchangeable in most cases. The top 5 ERP systems for mid-sized companies can all do the same things — with minimal differences in niche functions. This is confirmed by the regular ERP satisfaction studies from Trovarit: functional differences are marginal, but implementation quality varies enormously. What makes the difference is the implementation partner.

Don’t ask “What can the system do?” but instead:

• How many projects in my industry and size has the partner completed?
• Who exactly will work on my project? (Not the sales consultant, but the consultants who’ll be on-site)
• What does escalation management look like? (What happens when things go wrong — and at some point they will)
• What does an average consulting day cost after go-live? (This shows how much post-go-live effort the partner calculates)

The 3 Questions That Replace Any Requirements Document

If you want to reduce ERP selection to the essentials, answer three questions — and ask them of every vendor:

1. “Show us what our order process looks like in your system — with our data, not your test data.”

Anyone who can’t or won’t do this is out. This question separates vendors who understand your business from those who deliver standard presentations.

2. “What are the 3 most common problems your customers in our industry have after go-live?”

An honest vendor answers this openly. A bad one says “There are no problems.” If someone doesn’t know any problems, they either lack experience or they’re lying.

3. “Who specifically will work on our project, and what happens if that person leaves?”

Personnel continuity is the most important success factor in ERP implementations. Projects fail when the consultant who knows the system is pulled out after three months and a junior takes over.

Documentation for ERP Selection: What You Really Need

No requirements document doesn’t mean no documentation. It means: the right documentation.

• Process maps for your 10–15 core processes (2–3 pages per process, not 20)
• Integration list: Which systems need to be connected? (DATEV, web shop, CRM, warehouse, etc.)
• Framework conditions: Number of users, locations, entities, languages, currencies
• 3–5 key scenarios: Concrete business cases the vendor must demonstrate live in a workshop

That’s 15–20 pages instead of 200. And these 15 pages tell a good vendor more about your company than any requirements document — because they provide context instead of checkboxes.

Conclusion

The requirements document is the comfort zone of ERP selection. It gives a feeling of control and thoroughness. In reality, it leads to wrong decisions because it compares features instead of partners, describes the status quo instead of the future, and allows all vendors to look the same.

Those who are bold enough replace the requirements document with process workshops, reference visits, and the right questions. That takes weeks instead of months — and delivers a decision basis that deserves the name.

Next Step

Facing an ERP selection and want to do it differently? I guide the selection process — vendor-independent, process-oriented, and without a 200-page requirements document.

→ Book a free consultation

→ Or read more first: DATEV Integration Audit