ERP Requirements Gathering: A 7-Step Process for Success

What Is ERP Requirements Gathering?

ERP requirements gathering is the structured process of identifying, documenting, and prioritising the functional and technical capabilities your organisation needs from an enterprise resource planning system. It's the foundation of a successful ERP selection — get it wrong, and you risk choosing software that doesn't fit your business.

A comprehensive requirements gathering process typically takes 4–8 weeks for mid-market companies and 8–16 weeks for enterprises. The result is a detailed requirements document that becomes the basis for your RFI/RFP, vendor demos, and ultimately your selection decision.

Accelerate your requirements gathering — Our ERP Requirements Wizard provides a pre-built framework of 500+ requirements across 13 modules. Customise it in under 30 minutes. Start the Wizard →

---

The 7-Step ERP Requirements Gathering Process

Step 1: Define Project Scope and Objectives

Before collecting any requirements, align your project team on what the ERP project is meant to achieve. Define:

• Business objectives — What problems are you solving? Cost reduction, process standardisation, growth enablement?
• Module scope — Which functional areas are in scope? (See our 13 core ERP requirement areas)
• Geographical scope — Single country or multi-country deployment?
• Timeline — When do you need the system live?
• Budget range — What is the realistic investment range?

Step 2: Identify and Engage Stakeholders

Map every department and role that will use or be affected by the ERP system:

• Executive sponsors — C-suite or VP-level champions who own the budget and business case
• Process owners — Department heads who understand current workflows and pain points
• End users — Day-to-day operators who will use the system most frequently
• IT team — Technical staff responsible for integrations, security, and infrastructure
• External stakeholders — Auditors, regulators, or key customers/suppliers affected by the change

Each stakeholder group brings different requirements. A common failure mode is gathering requirements only from IT or only from finance — comprehensive gathering requires cross-functional input.

Step 3: Document Current-State Processes

Before defining what you need, understand what you have. For each in-scope functional area:

1. Map current workflows — Document how work gets done today, including manual workarounds
2. Identify pain points — Where do processes break down, slow down, or create errors?
3. Quantify inefficiencies — How much time/money do current problems cost?
4. Note dependencies — Which processes depend on data from other systems or departments?
5. Capture volume metrics — Transaction volumes, user counts, data sizes

This current-state analysis reveals both the functional gaps your ERP must address and the process improvements you can achieve.

Step 4: Conduct Requirements Workshops

Run structured workshops with each stakeholder group to elicit requirements:

Workshop format (recommended):

• 2–3 hours per session, focused on one functional area
• 4–8 participants per session
• One facilitator, one scribe
• Use our module requirement checklists as discussion prompts

Key questions to ask:

• What does this process look like today?
• What's broken or frustrating about the current approach?
• If you could design the perfect system, what would it do?
• What reports or data do you need that you can't get today?
• What compliance or regulatory requirements must the system meet?
• How do you interact with other departments through this process?

Step 5: Classify Requirements — Functional vs Non-Functional

Organise gathered requirements into two categories:

Functional requirements define what the system must do:

• Module-specific features (e.g., "Support three-way matching for purchase invoices")
• Industry-specific capabilities (e.g., "Lot tracking with expiry dates for food manufacturing")
• Reporting and analytics needs
• Workflow and automation requirements

Non-functional requirements define how the system must perform:

• Performance — Response times, concurrent user capacity, batch processing speed
• Security — Role-based access, data encryption, SSO integration, audit trails
• Scalability — Ability to handle growth in users, transactions, and entities
• Availability — Uptime SLAs, disaster recovery, backup frequency
• Usability — Mobile access, user interface design, training requirements
• Compliance — Industry regulations (SOX, HIPAA, GDPR, etc.)
• Integration — APIs, middleware, data exchange formats
• Support — Vendor support hours, implementation methodology, upgrade process

Step 6: Prioritise and Score

Not all requirements are equal. Use a tiered prioritisation framework:

Score each requirement with input from the relevant process owner. Disagreements should be escalated to the steering committee for resolution.

Step 7: Validate and Finalise

Before distributing your requirements document to vendors:

1. Cross-reference — Ensure no critical process is missing requirements
2. Remove duplicates — Consolidate similar requirements that emerged from different workshops
3. Check feasibility — Flag any requirements that may be technically impossible or prohibitively expensive
4. Get sign-off — Have each process owner approve their section of requirements
5. Version control — Establish a baseline version and change management process

---

Common ERP Requirements Gathering Mistakes

1. Starting with vendor demos instead of requirements Seeing vendor demos before defining requirements leads to "shiny object syndrome" — you end up choosing based on presentations rather than fit.

2. Gathering requirements from IT only IT understands technical requirements but often misses business process nuances. Always include process owners and end users.

3. Copying another company's requirements list Every organisation is different. Use templates (like ours) as a starting point, but customise extensively.

4. Not prioritising requirements Treating everything as "must-have" makes vendor evaluation impossible. Force-rank requirements into tiers.

5. Ignoring non-functional requirements Security, scalability, and support requirements are as important as features. Don't overlook them.

6. Scope creep during gathering Set a firm deadline for requirements gathering and stick to it. Late additions should go through a formal change process.

---

Tools for ERP Requirements Gathering

---

Frequently Asked Questions

How long does ERP requirements gathering take?

4–8 weeks for mid-market companies (200–1,000 employees). 8–16 weeks for enterprises. Our Requirements Wizard can accelerate the initial framework to under 30 minutes, but stakeholder workshops and validation still require dedicated time.

Who should lead ERP requirements gathering?

Ideally, a cross-functional project manager or business analyst who understands both business processes and technology. Many organisations hire an independent ERP consultant to facilitate the process and avoid vendor bias.

How many requirements should we gather?

A typical mid-market ERP project has 200–400 requirements. Enterprise projects may have 400–800+. Our framework covers 500+ requirements across 13 modules — select the ones relevant to your scope.

---

Related Resources

• ERP Requirements: Complete Guide & Checklist — the pillar guide covering all 13 requirement areas
• ERP Selection Criteria — how to evaluate vendors against your requirements
• ERP RFP Requirements — structuring your RFP document
• Compare ERP Vendors — side-by-side vendor comparison