# ERP Requirements Gathering Template > Source: https://netray.co/tools/erp-requirements-gathering-template > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A workshop form for one process area at a time: as-is flow, pain points, volumes, interfaces and prioritized requirement statements. ## Category erp-migration ## Audience - ERP project lead - Business analyst - Process owner ## Tool **Kind:** template **Output:** document **Fields:** #### Project name **Key:** project **Type:** text **Default:** ERP Replacement Program #### Process area **Key:** area **Type:** select **Options:** - Order to cash - Procure to pay - Planning and MRP - Production and shop floor - Inventory and warehouse - Quality management - Finance and reporting - Service and warranty - Engineering and BOM **Default:** Production and shop floor #### Process owner **Key:** owner **Type:** text **Default:** Maria Gonzalez, Plant Manager #### Workshop facilitator **Key:** facilitator **Type:** text **Default:** Sam Patel, ERP project lead #### Workshop date **Key:** date **Type:** date **Default:** 2026-11-10 #### Attendees **Key:** attendees **Type:** textarea **Default:** Production supervisors (2), planner, quality engineer, maintenance lead, IT analyst. #### As-is process summary **Key:** asis **Type:** textarea **Default:** 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 **Key:** pain **Type:** textarea **Default:** 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 **Key:** volumes **Type:** textarea **Default:** Approximately 450 open work orders, 6 work centers per routing, 3 shifts, 85 shop-floor users. #### Systems and interfaces touched **Key:** interfaces **Type:** textarea **Default:** CNC machine monitoring, barcode scanners, PLM for BOM release, quality system for inspections. #### To-be vision **Key:** tobe **Type:** textarea **Default:** Real-time operation reporting at the work center, automatic labor and material backflush, scrap with reason codes tied to the order, live WIP visibility. **Blocks:** #### Requirements Workshop Record **Body:** Project: {{project}} Process area: {{area}} Process owner: {{owner}} Facilitator: {{facilitator}} Date: {{date}} Attendees: {{attendees}} #### Current process (as-is) **Body:** {{asis}} #### Pain points and root causes **Body:** {{pain}} #### Volumes and scale **Body:** {{volumes}} Capture peak volumes as well as averages. Systems are sized and priced on peaks, month end and seasonal surges. #### Interfaces and data **Body:** {{interfaces}} #### Desired future state (to-be) **Body:** {{tobe}} #### Requirement register **Table:** **Columns:** - ID - Requirement statement (the system shall...) - Priority (Must, Should, Could, Won't) - Source / owner - Acceptance test **Rows:** **0:** REQ-001 **1:** Report operation completion and quantity at the work center in real time **2:** Must **3:** {{owner}} **4:** Operator completes a step and WIP updates within a minute **0:** REQ-002 **1:** Record scrap and rework with reason code against the work order **2:** Must **3:** Quality engineer **4:** Scrap by reason is reportable per order **0:** REQ-003 **1:** Backflush material consumption on operation completion **2:** Should **3:** Production supervisor **4:** Inventory reduces without manual issue **0:** REQ-004 **0:** REQ-005 **0:** REQ-006 #### Open questions and assumptions **Table:** **Columns:** - # - Question or assumption - Owner - Due **Rows:** **0:** 1 **0:** 2 **0:** 3 #### Sign-off **Signatures:** - Process owner - Facilitator - Project sponsor **Notes:** 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. ## Content **Intro:** 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. **Sections:** #### How to run the workshop **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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 **Body:** 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. **Cta:** 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. **Faq:** #### How many ERP requirements should a manufacturer have? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms erp requirements gathering template, erp business requirements document template, erp requirements template excel, erp requirements workshop template, erp functional requirements template, erp requirements checklist, moscow erp requirements --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json