One of the most predictable failure patterns in ERP selection is choosing a vendor before your team has a clear picture of what you actually need. When requirements are vague or undocumented, vendor demos become entertainment rather than evaluation. Your team ends up choosing the platform with the best salesperson rather than the one that fits your business.

Thorough requirements gathering is the foundation of a good ERP selection. This guide walks you through who to involve, what to capture, how to prioritize, and how to document your requirements in a way that actually drives better buying decisions.

Why Requirements Gathering Matters

Think of ERP requirements as the specification sheet your vendor must answer to. Without them, you are evaluating platforms based on marketing materials and demo scripts designed to showcase strengths while hiding gaps.

With a clear requirements document, you can:

• Issue a structured RFP that asks vendors to respond to your specific needs
• Design demo scenarios that test real workflows rather than generic ones
• Score vendors against objective criteria rather than gut feeling
• Identify gaps in vendor capabilities before you sign a contract
• Set expectations with your implementation partner about what needs to be built or configured

The investment you make in requirements gathering at the front end almost always pays for itself in avoided surprises during implementation.

Who to Involve in Requirements Gathering

This is where many organizations get it wrong. Requirements gathering is often delegated to IT or to a small project team that then tries to represent the entire business. The result is requirements that are technically detailed but operationally incomplete.

Effective requirements gathering involves a cross-functional group that includes at minimum:

Finance and Accounting

Finance has requirements around general ledger structure, accounts payable and receivable workflows, financial reporting, multi-entity or multi-currency needs, audit trails, and month-end close processes.

Operations and Supply Chain

Operations requirements typically cover inventory management, purchase order processing, goods receipt, warehouse management, production or job costing, and supplier management.

Sales and Customer Service

Customer-facing teams have requirements around order management, customer pricing, contract management, service ticketing, and CRM integration.

Human Resources

HR requirements cover employee records, benefits administration, payroll processing, time and attendance, and workforce planning.

IT

IT’s role is to document technical requirements: integration points with existing systems, data migration scope, security and access control, hosting preferences, and API or customization needs.

Executive Leadership

Senior leaders provide requirements around management reporting, KPI visibility, and strategic objectives that the system needs to support.

Do not try to gather requirements by sending out a survey and waiting for responses. You will get low-quality, incomplete input. Instead, run structured workshops where people can discuss, debate, and refine their requirements in a group setting.

Functional vs. Technical Requirements

ERP requirements fall into two broad categories: functional and technical.

Functional Requirements

Functional requirements describe what the system needs to do from a business process perspective. Examples include:

• “The system must support multi-currency invoicing in at least ten currencies.”
• “Purchase orders over a certain value must require a two-level approval workflow.”
• “The system must generate a weekly aged accounts receivable report by customer.”

Functional requirements come primarily from business users — finance, operations, sales, and HR.

Technical Requirements

Technical requirements describe the technical environment and constraints the system must work within. Examples include:

• “The system must integrate with our existing EDI platform.”
• “The system must support single sign-on through our Azure Active Directory.”
• “Data must be hosted in a specific geographic region for compliance reasons.”

Technical requirements come primarily from IT, though business users may surface compliance-driven technical needs.

Both types of requirements matter. Vendors often excel on one dimension and have gaps on the other. A beautiful, highly functional system that cannot integrate with your existing tech stack is a serious problem.

The Must-Have vs. Nice-to-Have Matrix

Not all requirements are equal. Some are non-negotiable: without them, the system cannot run your business. Others are preferences that would improve your experience but are not essential.

Categorizing requirements into tiers helps you focus your evaluation and avoid disqualifying otherwise strong vendors over minor gaps.

Priority Tier	Definition	Example
Must Have	Without this, the system cannot support a core process	Multi-company consolidation for a group with three legal entities
Should Have	Important to operations; a workaround exists but is painful	Automated bank reconciliation
Nice to Have	Would improve efficiency; easily handled outside the system	Embedded business intelligence dashboards
Future State	Not needed today but on the roadmap	E-commerce storefront integration

A good rule of thumb: if a vendor cannot meet all of your must-have requirements, they should not make your shortlist regardless of how well they score elsewhere. Should-have gaps are worth probing further. Nice-to-have gaps are acceptable.

When your team first drafts the requirements list, expect everything to land in the “must have” tier. Challenge your team on each requirement: what happens if the system cannot do this? Can the process be changed? Is there a manual workaround? This conversation is often more valuable than the initial list itself.

How to Facilitate an Effective Requirements Workshop

A well-run workshop surfaces better requirements faster than any other approach. Here is a proven facilitation structure.

Before the Workshop

• Send participants a list of the business processes in scope so they come prepared
• Provide a simple requirements template so people are not starting from a blank page
• Identify a facilitator who is neutral — ideally not the project manager, who has a stake in the outcome

During the Workshop

Start each workshop session by walking through the current-state process: how do you do this today, step by step? Then identify pain points: where does the current process break down? Then identify what an ideal future state looks like.

This current-state / pain-point / future-state structure produces far richer requirements than simply asking “what do you need from an ERP?”

Use a shared document or whiteboard so the group can see requirements being captured in real time. This allows people to react to each other’s input and often surfaces requirements that no one would have raised individually.

After the Workshop

Consolidate the raw notes from the workshop into a structured requirements document within a few days while the material is fresh. Send it back to participants for review and ask them to flag anything that was missed or misrepresented.

Documenting Your Requirements

Your requirements document should be structured so it can be used directly in an RFP. Each requirement should include:

• A unique identifier (for tracking)
• A clear, unambiguous description of the requirement
• The priority tier (must have, should have, nice to have, future state)
• The process or department it belongs to
• Any acceptance criteria — how would you know if the vendor meets this requirement?

Here is an example of a well-documented requirement versus a poorly documented one.

Version	Requirement
Poor	“The system needs good reporting.”
Better	“The system must allow finance users to generate a consolidated P&L across multiple legal entities, with the ability to filter by cost center, project, and period, without requiring IT involvement.”

Specificity is what makes requirements useful. Vague requirements produce vague vendor responses and make evaluation impossible.

Prioritizing Requirements Across Competing Stakeholders

In cross-functional requirements gathering, you will almost certainly encounter competing priorities. Finance needs feature A. Operations needs feature B. There is budget for one. How do you decide?

A few approaches that work well in practice:

Weighted scoring: Assign a weight to each business unit based on how central they are to the ERP project. Finance may carry more weight if the ERP is primarily a financial system. Use these weights when tallying must-have vs. nice-to-have priorities across teams.

Executive arbitration: When two departments have conflicting must-have requirements and the conflict cannot be resolved at the team level, escalate to your executive sponsor for a decision. This is one reason executive involvement is non-negotiable.

Process redesign: Sometimes competing requirements reflect two different ways of doing the same thing. If you standardize the process before selecting a system, the conflict dissolves.

Common Requirements-Gathering Mistakes to Avoid

Documenting Processes Instead of Requirements

There is a difference between “our current process is X” and “the system needs to do Y.” Requirements gathering is often derailed when teams document their current-state workflows in exhaustive detail without translating them into system requirements. You need to capture what the system must do, not a description of how you currently work.

Inviting Too Many People

Cross-functional involvement is essential, but workshops with twenty or thirty people become unmanageable. Keep working groups focused — ideally five to eight people — and ensure each group has the right expertise for the module area being discussed.

Treating Requirements as Final

Your requirements document will evolve. As you see vendor demos, you will discover capabilities you did not know existed and gaps you did not anticipate. Build in a process for updating your requirements document through the vendor evaluation phase rather than treating it as locked after the initial workshops.

Ignoring Integration Requirements

Integration requirements are often underestimated. Ask your IT team to map every system in your current tech stack and identify which ones the ERP will need to exchange data with, in what direction, and how frequently. Integration complexity is one of the biggest drivers of implementation cost and schedule overrun.

---

Frequently Asked Questions

How long should ERP requirements gathering take?

For a mid-market company, plan for four to eight weeks of structured requirements gathering. This includes workshop sessions with each major functional area, consolidation of outputs, and review cycles with stakeholders. Compressing this timeline usually means skipping departments or accepting incomplete input — both of which cause problems later.

Should you hire a consultant to help with requirements gathering?

If your team has no prior ERP experience, a consultant can help you ask the right questions and structure the process efficiently. Look for someone with experience in your industry and with the ERP platforms you are likely to evaluate. An independent consultant — one without a vendor affiliation — is generally the most objective choice.

How many requirements is too many?

There is no hard number, but requirements documents that run to several hundred items often contain a lot of redundancy, process documentation masquerading as requirements, and low-priority items that should have been placed in the nice-to-have tier. A focused requirements document of fifty to one hundred well-written requirements for a mid-market company is usually more useful than three hundred loosely defined ones.

What happens if vendors cannot meet all your requirements?

It is rare to find a vendor that meets every requirement perfectly. The key question is whether the gaps are in your must-have tier. Must-have gaps are disqualifying. For should-have gaps, understand what the workaround would be and how much it would cost to bridge the gap through configuration, customization, or an adjacent tool. For nice-to-have gaps, accept them and move on.