ERP Requirements Gathering: A 7-Step Process for Success

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

Send a short discovery questionnaire to participants a week before each session so they arrive with volumes, pain points, and report gaps already written down. The section below covers what to ask, and our ERP requirements template ships the same structure as a spreadsheet you can circulate.

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

---

ERP Requirements Gathering Questionnaire: What to Ask

A requirements gathering questionnaire is an internal discovery instrument. You send it to your own department heads and end users ahead of the Step 4 workshops — not to vendors. That distinction matters: the vendor-facing document that asks suppliers what their software can do is your ERP RFP, and it is written after this questionnaire, using its output. The questionnaire's job is to surface raw pain points, volumes, and workarounds so the workshops start from evidence rather than a blank page.

How long should it be? 40–60 questions in total is realistic — roughly 8–12 per in-scope department, answerable in 30–45 minutes. Past about 80 questions, completion rates fall and answers get thinner. A short questionnaire followed by a live workshop beats a long one nobody finishes.

Structure it by department, with a shared core. Ask every respondent the same five baseline questions, then add 5–8 department-specific prompts.

Core questions (every department)

1. Which three tasks in your week take the most time, and why?
2. What do you do outside the current system — spreadsheets, email, paper, shadow databases?
3. What report or number do you need that you cannot get today?
4. What breaks most often, and what is the workaround?
5. How many transactions, orders, or invoices does your team process in a typical month?

Department-specific prompts

• Finance — Close cycle length, number of legal entities to consolidate, revenue recognition rules, statutory and tax reporting obligations
• Operations and manufacturing — Planning horizon, lot or serial traceability, shop-floor data capture, scrap and yield tracking
• Sales and service — Pricing complexity (tiers, contracts, rebates), quote-to-cash handoffs, CRM integration points
• Supply chain — Multi-warehouse rules, EDI trading partners, carrier selection and landed-cost handling
• HR and payroll — Headcount by country, payroll providers, time capture methods, union or collective agreement rules
• IT — Systems to retire, integrations to keep, data volumes to migrate, security and access standards

Close every version with two scoring questions: "If this were a must-have, what could you not do without it?" and "What would you trade away to get it?" Those force the prioritisation you need in Step 6, and they let you tier requirements without another round of meetings.

---

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) and 8–16 weeks for enterprises. Budget roughly one week per in-scope module: two workshop sessions, write-up, and process-owner sign-off. Multi-country or multi-entity scope adds 2–4 weeks for local statutory and tax rules. Our Requirements Wizard compresses the initial framework to under 30 minutes, but workshops and validation still need calendar time.

Who should lead ERP requirements gathering?

A business analyst or project manager who understands both business process and technology — not the IT director alone, and never a vendor. Expect the lead to spend 50–70% of their time on the project for its duration. Mid-market teams without an internal analyst commonly engage an independent ERP consultant for 4–8 weeks to facilitate workshops and keep the document vendor-neutral. The executive sponsor approves the output; they do not run the process.

How many requirements should we gather?

200–400 for a typical mid-market project; 400–800+ for enterprises. Roughly 25–40 per in-scope module is the working benchmark. Fewer than 150 usually means whole departments were skipped; more than 1,000 means feature wish-lists have crept in, and vendors will struggle to respond meaningfully. Our framework covers 500+ requirements across 13 modules — select only those in scope.

Is a requirements questionnaire the same as an RFP?

No. The questionnaire is internal: it asks your own staff what they do today and what hurts. The RFP is external: it asks vendors how their software meets the requirements the questionnaire helped you write. Run the questionnaire first, in weeks 1–2 of gathering; the RFP follows prioritisation and sign-off, typically 4–8 weeks later.

What if stakeholders disagree on a requirement?

Escalate, don't average. Log the conflicting positions verbatim, name the process owner behind each, and put the item on the steering committee agenda with a decision deadline. In practice 5–10% of requirements need this. Disagreements that get quietly downgraded to "nice-to-have" instead of resolved are a common source of post-go-live change requests.

---

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