Many factory-customized software projects don’t fail during coding, but rather because of “unclear requirements, constantly changing scope, and no one acknowledging the system after launch.” Sales wants to track process progress, the workshop demands reassignment capabilities, finance insists on aligning with work order costs, and IT claims the interface list hasn’t been finalized yet. Three months later, the system goes live, yet现场 still relies on WeChat for photo sharing and Excel for time reporting. What’s truly lacking isn’t a feature list—it’s an actionable roadmap that spans from scope freeze, solution design, development implementation, to acceptance testing—forming a closed-loop process.
Business issue: Why is it that even after “completion,” the system remains unusable?
A common pain point in discrete manufacturing is this: work orders are issued, but process progress remains invisible; team leaders make verbal reassignments, yet the system stays stuck at the previous step; quality inspection results are documented only on paper, leading to discrepancies in cost accounting. The boss buys software hoping to see real WIP (work-in-progress), but if the vendor quotes based on a “module checklist,” they’ll bundle dashboards, time reporting, inventory, and cost management into a single phase, causing the scope to balloon beyond what can be accepted.
Another type of failure occurs when interview notes are mistaken for requirement specifications.The notes state, “We need to track progress,” but fail to clarify which work order serves as the basis for progress updates, how rework should be recorded, or who has authority over cross-team reassignments. Development builds a list page literally according to these vague instructions, and the system immediately runs into issues once deployed. Software can address these problems by turning such rules into executable state machines and access controls; if it cannot, it means no one in the organization is willing to lock down those rules.
There’s also an invisible cost: prolonged parallel operation of old and new systems. While the old Excel spreadsheets keep running, the new system remains incomplete, leaving现场 to choose the easier path. As a result, system data becomes increasingly messy, ultimately leading to the conclusion that “the system isn’t usable.” Parallel operation is acceptable, but only if you clearly specify the date when the old forms will be discontinued and the reconciliation procedures—otherwise, going live merely adds another display layer.
- Unclear scope: Phase one’s objectives get conflated into “full digitalization.”
- Data collection breakpoints: Progress is still tracked verbally, while the system serves only as a presentation layer.
- Misaligned acceptance criteria: Inspections are conducted based on menu items rather than actual business outcomes.
- Uncontrolled dual-track operations: Old forms persist, while new data lacks clear ownership.
How to break down the business: First, lock in verifiable results for phase one.
It’s recommended to anchor phase one to a measurable outcome—for example, “key process time reporting delays must not exceed 30 minutes, and planners should be able to match work orders with complete sets and identify bottlenecks.” Other tasks like deep inventory optimization, cost allocation, and BI dashboards can be deferred to phase two. Business decomposition can follow four key chains:
- Work order chain: Obtain work orders and process definitions from ERP/MES, clearly defining responsible parties for master data.
- Time reporting chain: Who scans or clicks to report completion, rework, or suspension, and when.
- Exception handling chain: How shortages, equipment downtime, or quality freezes impact downstream processes.
- Reconciliation chain: During daily clearing, how do we explain discrepancies between system progress and on-site inventory counts?
Each chain should clearly definetrigger events, responsible roles, and escalation protocols for timeouts.If something can’t be written down, it means the business isn’t ready for the system yet—first implement procedural warm-ups instead of rushing straight into development. The scope freeze meeting should produce a signed document: features listed go into phase one, while those not listed remain in the requirements pool; any changes require change orders and updated timelines.
How to design: Roles, workflows, and data boundaries.
During the design phase, three key deliverables should be produced—not just a pile of wireframes: a role matrix, a state machine, and interface contracts. Wireframes can be added later, but missing any of these three essentials will lead to constant rework of every interface.
Roles and permissions.
At minimum, distinguish between planners, team leaders, operators, quality inspectors, warehouse managers, and read-only executives. Reassignments and write-offs must leave a dual-trace record; operators report only their own station; planners monitor the bottleneck pool. Permissions should be tied to “position + production line” to prevent single accounts with universal access. Account details and employee departures must be synchronized with the operations maintenance roster; otherwise, permission debts could undermine data credibility.
Processes and states.
For process instance statuses, it’s recommended to streamline them: pending start, in progress, awaiting inspection, completed, reworked, frozen. State transitions should only allow legally permitted moves; illegal jumps must include detailed reasons. Dashboards should only display state machine results, prohibiting bypasses that directly alter status without proper reporting. For rework, clearly specify which process it returns to and whether a sub-work order is generated, avoiding situations where progress appears complete but actually loops back.
Data and interface boundaries.
Master data (materials, process routes, teams) is maintained by the source system; execution data (time reports, exceptions) is generated within the on-site system. Interfaces should be tailored to specific roles: operators complete time reporting with three clicks, planners monitor bottlenecks and completeness, while management reviews delay distributions. Don’t dump all ERP fields onto workshop tablets. Fewer fields mean more accurate data collection.
How to develop and implement: interfaces, data collection, acceptance testing.
Development sequence recommendation: synchronize master data → collect time reports → handle exception bottlenecks → query alignment with work orders → generate daily reconciliation reports. Prioritize idempotent interfaces: use version numbers for work order changes; employ unique business keys for time reporting to prevent duplicates. Data collection endpoints should adapt to weak networks: local queues, resubmission mechanisms, conflict alerts. Device scanning and manual selection can coexist, but each process instance should have only one “authoritative completion event.”
Joint debugging requires preparing a “dirty data script”: repeated scanning, network interruptions, mid-process work order changes, cross-team reassignments. These scenarios expose design flaws far more effectively than happy paths. In terms of performance, dashboard queries should be partitioned by production line to avoid scanning the entire plant in real-time.
Acceptance testing shouldn’t rely on simply checking off “functional points.” Instead, use scenario scripts: issue a real work order and walk through the full process of time reporting; artificially create material shortages to verify downstream freezing; after cross-team reassignments, ensure dashboard and work order consistency; randomly sample three days of time reporting and on-site inventory counts, keeping discrepancy rates below agreed thresholds. If standards aren’t met, refuse final acceptance and sign only conditional go-live approval.
Document delivery should include: scope freeze minutes, state machine explanations, interface lists, permission matrices, scenario-based acceptance records, operations duty schedules, and change management procedures. Without these, post-implementation operations will devolve into verbal archaeology.
Conclusion: Treat delivery as “operational rules.”
From requirements to go-live, the core isn’t stacking features—it’s codifying workshop default rules into executable logic and proving through data collection and acceptance testing that they’re functioning. Completing just one chain in phase one is far more valuable than ten half-finished menus. If your factory is struggling with process progress and work order misalignment, consider compressing the scope of phase one along the above path before restarting development.
Shandong XYN Information Technology Co., Ltd. (XYN Tech) has long specialized in custom software development across various industries, breaking down scope, design, development, and acceptance into manageable deliverables. To learn more, visit About Us.