When rebuilding factory ERP, system boundaries usually matter more than feature wish lists

One common factory problem is that the same business fact is maintained in several places at once. ERP shows one order status, the workshop board shows another, warehouse spreadsheets show a third, and finance adjusts things again at month end. If a rebuild starts without naming which system is authoritative for which data, every new feature risks creating another layer of contradiction.

That is why I prefer a simple responsibility map before a feature matrix. Who owns order master data? Who confirms stock movement? Who maintains production scheduling? Who makes the final financial determination? If primary, secondary, and read-only roles are unclear, the project may look complete in review meetings while staying confusing in daily use.

Projects often produce long lists of urgent requests: more automation, more alerts, more approvals, more export formats. On the surface, these look like capability gaps. In reality, many of them are attempts to patch over unclear ownership. If inventory rules are inconsistent, every team asks for another reconciliation report. If scheduling rules keep shifting, people want heavy manual override logic. If warehouse and purchasing responsibilities overlap, the workflow fills with duplicate confirmation steps.

These features are not always wrong, but they are dangerous when used as substitutes for real decisions. Before adding them, it helps to ask whether the request solves a high-frequency business need or only helps people survive a process that was never properly defined. A lot of ERP budget disappears into patches that feel necessary only because the underlying boundary problem was left untouched.

Factory ERP rebuilds are especially vulnerable to oversized phase-one scope. Orders, scheduling, purchasing, inventory, quality, equipment, finance, and dashboards all sound important, and they are. But each area carries old habits, hidden exceptions, and different definitions. If boundaries are still unsettled, launching everything together usually digitizes the confusion instead of solving it.

A more reliable phase one starts with one operational chain that already has relatively clear ownership, such as order-to-scheduling or purchasing-to-receiving. Once status definitions, user actions, exception handling, and data rules are stable there, the next chain can be added on stronger foundations. It may look less ambitious at first, but it creates a system people can actually keep extending.