ERP Requirements Gathering Template
Most failed ERP projects trace back to requirements that were vague, unprioritized or owned by nobody. This template runs one process workshop at a time: it captures the as-is flow, pain points, volumes, interfaces and a register of testable, prioritized requirements. Export a record per area and sign it off with the process owner.
Fill in
ERP Requirements Gathering Template
Requirements Workshop Record
Project: ERP Replacement Program Process area: Production and shop floor Process owner: Maria Gonzalez, Plant Manager Facilitator: Sam Patel, ERP project lead Date: 2026-11-10
Attendees: Production supervisors (2), planner, quality engineer, maintenance lead, IT analyst.
Current process (as-is)
Work orders are released from the ERP but progress is tracked on paper travelers and keyed in at end of shift. Scrap and rework are logged in a spreadsheet.
Pain points and root causes
Labor and WIP are 12 to 24 hours behind. Cannot see real routing status. Rework is not tied to the work order. Frequent reconciliation at month end.
Volumes and scale
Approximately 450 open work orders, 6 work centers per routing, 3 shifts, 85 shop-floor users.
Capture peak volumes as well as averages. Systems are sized and priced on peaks, month end and seasonal surges.
Interfaces and data
CNC machine monitoring, barcode scanners, PLM for BOM release, quality system for inspections.
Desired future state (to-be)
Real-time operation reporting at the work center, automatic labor and material backflush, scrap with reason codes tied to the order, live WIP visibility.
Requirement register
| ID | Requirement statement (the system shall...) | Priority (Must, Should, Could, Won't) | Source / owner | Acceptance test |
|---|---|---|---|---|
| REQ-001 | Report operation completion and quantity at the work center in real time | Must | Maria Gonzalez, Plant Manager | Operator completes a step and WIP updates within a minute |
| REQ-002 | Record scrap and rework with reason code against the work order | Must | Quality engineer | Scrap by reason is reportable per order |
| REQ-003 | Backflush material consumption on operation completion | Should | Production supervisor | Inventory reduces without manual issue |
| REQ-004 | ||||
| REQ-005 | ||||
| REQ-006 |
Open questions and assumptions
| # | Question or assumption | Owner | Due |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 |
Sign-off
Run one workshop per process area and export one document each. Write requirements as testable statements (a measurable outcome, not a feature name) so they can be used later as demo scripts and acceptance tests.
Want requirements pulled from your current ERP usage?
We can discuss how read-only analysis of your existing ERP data can show which processes and reports are really used. Optional.
Optional. The tool and every export work without this. No spam.
How to run the workshop
Pick one process area, invite the people who actually do the work and not only the managers, and fill in the fields live. Start with the as-is process and the pain points, because they ground the conversation in real problems. Then describe the to-be vision before writing requirement statements. Finish by reading the register back to the group and agreeing priorities. Keep each session to two hours and finish with an owner and a due date for every open question.
- One process area per session
- Include operators and supervisors, not only managers
- Capture peak volumes, not just averages
- Agree priorities in the room
Writing a good requirement
A requirement should be a single testable statement: the system shall do something, for someone, with a measurable outcome. Compare the weak requirement of good inventory visibility with the usable requirement that a planner can see on-hand, allocated and in-transit quantity by location and lot in one screen. Tag each with MoSCoW priority: Must have for processes that stop the business if missing, Should have for high value, Could have for nice-to-have, and Won't have this time to record explicit exclusions.
From requirements to selection
The register feeds three downstream artifacts. The Must and Should lines become the requirements workbook attached to your RFP. The acceptance tests become the scripted scenarios for vendor demos. After selection, the same list becomes the fit-gap baseline and later the user acceptance test plan. Keeping one numbered register through all four stages avoids translating requirements again and again, which is where meaning is lost.
Common mistakes
Do not document the current system's screens as the requirement. Ask what outcome is needed rather than how the old system did it. Avoid making everything a Must: if more than about 60 percent of lines are Must have, priorities have not been decided and vendors will not be able to differentiate. Also avoid leaving finance, quality and IT out of operational workshops, because most integration surprises come from the edges between functions.
Frequently Asked Questions
How many ERP requirements should a manufacturer have?
Mid-size manufacturers usually end up with 200 to 600 requirements across all areas, with the highest-priority 20 to 30 percent driving most of the decision. More than that is often duplicated or too detailed; fewer than 100 suggests the scope is too vague to evaluate.
Who should own each requirement?
Each requirement needs a business owner who can say yes or no to a trade-off, not an IT contact. The owner confirms the priority, clarifies intent during demos and signs acceptance at the end. Requirements without owners tend to be dropped at the first scope pressure.
Should requirements describe features or outcomes?
Describe outcomes with a test. A feature name like lot tracking is ambiguous. A statement that any received lot can be traced forward to customer shipments in under a minute can be demonstrated and scored. Outcomes also leave room for vendors to propose better approaches.
Can this replace a business requirements document?
For most ERP selections, a set of signed workshop records with a single requirement register is enough and more useful than a long narrative. If your governance demands a formal document, combine the exported records into one with a short introduction and scope statement.
If your requirements live in scattered documents, spreadsheets and old project files, we can show how a private AI setup can consolidate them into a structured register on your own systems.
Related Tools
ERP RFP Template
Generate a complete ERP request for proposal: instructions, scope, technical and security questions, pricing format and evaluation criteria.
ERP Migration & SelectionERP Demo Script Template
A scripted demonstration plan: ground rules, agenda, business scenarios with your data, and a score sheet for evaluators.
ERP Migration & SelectionERP Vendor Scoring Matrix Worksheet
A weighted evaluation matrix for three ERP vendors. Edit criteria and weights, score each vendor and read the totals.
ERP Migration & SelectionERP Selection Readiness Assessment
Nine questions that test whether your organization is ready to run an ERP selection, with a score and next actions.
ERP Migration & SelectionERP RFP Completeness Checklist
Verify your ERP request for proposal covers everything vendors need to quote accurately, so responses are comparable and post-award scope disputes are avoided.
More ERP Migration & Selection tools
See all- ERP TCO Comparison Calculator (5-Year)
- ERP Migration Risk Assessment
- Data Migration Effort Calculator
- ERP Selection Scorecard for Manufacturers
- ERP Go-Live Readiness Checklist
- ERP Change Management Readiness Assessment
- ERP Integration Complexity Calculator
- Cloud vs On-Premise ERP Cost Calculator
- ERP Upgrade vs Replace Assessment