A multinational manufacturing group operating in three countries (name withheld under NDA)
OmniERP Manufacturing Suite — an internal delivery codename, not a commercial product name.
The problem
The group had begun a full custom ERP build covering finance, HR, inventory and production. Finance and HR are governed by external rules the group does not control and gain them nothing by being different — building there was reproducing licensable functionality at considerable expense.
Meanwhile the one genuinely differentiating capability, yield-optimising production scheduling, was being squeezed into a generic work-order model that could not express it.
Constraints we had to design within
- Three countries with different statutory reporting requirements.
- Production could not stop for migration.
- An in-flight custom build with sunk cost and organisational commitment behind it.
Approach
Recommending they build less
Our first recommendation was to stop building finance and HR and license them instead, keeping the package close to vanilla so statutory changes across three jurisdictions remain the vendor's problem rather than the group's. This reduced the scope of work available to us and was the right advice.
Custom where the advantage lives
Production scheduling was built as a custom service modelled on how the group actually optimises yield, rather than on a generic work-order abstraction. This is the capability a competitor would gain something by copying, which is precisely the test for whether to build.
A deliberate integration layer
The packaged and custom systems are connected through an explicit API layer rather than direct database access. That layer is what preserves the option to replace either side later, and it is the piece most often cut under delivery pressure — cutting it is how organisations end up unable to replace anything.
Engineering notes
Deciding the system of record before anything else
The integration problems we are most often asked to remediate reduce to two systems both believing they own the same entity. Once that exists there is no principled way to resolve a conflict, and reconciliation becomes permanent operational work.
Ownership was therefore settled per entity — item master, inventory position, order, customer — before any interface was designed. Copies are explicitly copies, with a defined direction of authority.
Migration of non-conforming history as a business decision
Historical manufacturing data almost never conforms to the model a new system expects: missing mandatory fields, identifiers that were free text, duplicate entities never merged, units recorded inconsistently.
What to do with that history is a business decision with regulatory and financial implications, not a technical one. It needs a named owner early, because the alternative is engineers silently deciding what a record means — which is how a migration produces a clean-looking dataset nobody trusts.
Shop-floor interfaces designed for the actual environment
Interfaces intended for a production floor are used with gloves, in poor light, by people who cannot stop what they are doing to read a dialogue. Touch targets, contrast and error recovery were designed against that reality rather than against an office desktop.
Where an action is destructive or hard to reverse, the interface is deliberately slower. Speed is the wrong objective at exactly the points where a mistake is expensive.
Outcome
Statutory reporting across three jurisdictions is maintained by the package vendor. Engineering effort concentrated on the scheduling capability that differentiates the business.
Either side of the architecture can be replaced independently, which was not true of the original plan.
Figures above are drawn from delivery records held under NDA and are pending independent confirmation. Where a figure cannot be evidenced it will be removed rather than qualified.