For a manufacturer operating across countries, the ERP architecture question starts with what the sites need to do together. Group financial reporting, purchasing and transfers between plants each require different kinds of coordination. They do not necessarily require identical local workflows.
The useful comparison is therefore not simply global ERP versus local ERP. It is how much operational responsibility to place in a common system, how much to leave with plants, and where to enforce shared rules.
In a SoftEngine webinar on ERP strategy, the speakers argue that strategic fit matters more than vendor origin. They discuss international rollout capabilities, regional knowledge and arrangements connecting local operational ERPs to an international system. That is a useful starting point: choose the division of responsibilities before treating vendor nationality as a proxy for suitability.
Separate the product, the instance and the process
A multi-country ERP architecture decision needs to answer distinct questions:
- Product choice: should sites use the same ERP software or different products?
- Instance design: should they share an application environment or operate separate environments?
- Process standardization: which business rules, definitions and workflows must be common, regardless of where they run?
Keep these questions separate in the architecture discussion. “The same ERP” should not stand in for an answer to all of them. A shared product with independently maintained local configurations is a different proposition from a shared product governed through a common template. Historical research published in Communications of the ACM explicitly distinguishes a standardized configuration across business units from several different configurations, with potentially different organizational impacts.
An ERP global template should express the rules the organization intends to reuse: shared data definitions, accounting structures, transaction responsibilities and the processes that connect sites. Decide separately whether to deploy that template in a shared environment or repeat it across separate environments. Otherwise, a deployment decision can quietly become an organizational policy nobody explicitly approved.
Also separate architecture from the investment decision. Keeping a local ERP does not establish that it is fit for purpose, and choosing common processes does not establish that every system needs replacing. Resolve that through an improve-or-replace assessment, rather than using the architecture label as the business case.
What a common global ERP approach asks of the business
A common approach is most coherent when plants need to coordinate closely and can accept shared definitions and decision rights. Its attraction is the opportunity to settle a rule centrally and reuse it, rather than repeatedly translate between local interpretations. The corresponding obligation is to make that shared rule suitable for the sites expected to follow it.
Start with master data. Decide which product identifiers, units of measure, customer and supplier identities, and financial classifications belong to the group. Then distinguish those from local attributes. A common material identity need not mean every plant uses identical planning parameters. Equally, allowing local planning parameters should not become permission to create incompatible identities for the same material.
Intercompany transactions require similar precision. For transfers between legal entities, agree the relationship between the sending and receiving records, the events that establish shipment and receipt, and who resolves disagreements. A common application environment should not be accepted as a substitute for those decisions. Ask how the selected design makes the agreed transaction visible and controllable.
The organizational burden becomes clearest when changes are requested. Who can alter a shared field? Which sites must approve a changed process? Who decides whether a local requirement belongs in the template? Central control is useful only if it comes with a workable route for resolving genuine differences.
Apply the same logic to upgrades. For a shared environment, establish how plants participate in release approval and how their operating calendars affect scheduling. For separate environments using a common template, decide which changes must move together and how deviations will be tracked. The architecture choice should include this continuing coordination, not just the initial rollout.
A corporate core with local ERPs moves the shared boundary
In a two-tier manufacturing arrangement, the corporate and plant systems have different responsibilities. Infor describes this division as plants focusing on operational business systems while headquarters focuses on financial management and other organization-wide systems. That division is a starting point for scope, not a complete integration design.
The shared boundary can be relatively narrow. The ACM research describes local operational autonomy combined with common financial consolidation, including an example of different operational ERP products connected to a common financial system. It also describes a broader model in which headquarters coordinates the supply chain through access to local purchasing requirements, inventories and production schedules. These are materially different architectures: financial reporting alone does not answer the information needs of cross-site production coordination.
Define the corporate core accordingly. If its purpose is consolidation, specify how local accounts map to group reporting, how submissions are reconciled and how adjustments are approved. If it also coordinates supply, specify the inventory and planning information it needs, its meaning and the point at which it becomes usable for decisions.
Integration does not remove the need to standardize. It changes where agreement must be enforced. For master data, name the authority for each shared field and define how local extensions relate to it. For intercompany transactions, agree the identifiers connecting records across systems and the responsibility for resolving mismatches. For consolidation, retain a traceable relationship between submitted group figures and local records.
Give that work continuing owners:
- Data owners approve shared definitions and mappings.
- Process owners resolve disagreements between corporate and local transaction rules.
- Application and integration owners manage interface changes, rejected exchanges and recovery responsibilities.
- Finance owners approve reconciliations and reporting adjustments.
Local release autonomy should have a clear boundary too. Require an impact review when a change affects a shared field, transaction or reporting output. Allow local scheduling where dependencies permit it, but make compatibility checks part of both corporate and local release approval. Otherwise, “local autonomy” leaves the responsibility for protecting shared processes undefined.
Distinguish genuine differences from inherited preferences
A local difference deserves examination on its substance, not automatic acceptance or rejection. In the SoftEngine discussion, the speakers distinguish regional market knowledge and regulatory particularities from global rollout considerations, while returning the decision to the company’s strategic priorities. Translate that into evidence about the requirement itself.
For a statutory difference, identify the applicable obligation, the records or outputs it changes, and the responsible local finance or legal owner. Then assess whether the common solution can meet it through supported localization or configuration. A legal requirement establishes what must be achieved; it does not, by itself, establish the need for a separate ERP.
Illustration: a plant making engineered-to-order equipment and a plant repeatedly producing standard components may need different planning workflows. Examine the actual differences in order definition, scheduling and costing before prescribing a common process. They could still share material identities, customer definitions and group reporting rules. The decision is where commonality remains useful, not whether the plants are identical.
By contrast, “we have always used this approval sequence” is not enough to justify a permanent exception. Ask what business obligation or operational constraint the sequence satisfies. If the common process meets that need, preserving the old sequence adds difference without a clear purpose. Once the requirement is understood, use a configuration and customization approval process to decide how to implement it.
Keep plant autonomy distinct from the shop-floor system boundary as well. Whether a production activity belongs in ERP or execution software is a separate question from whether the plant needs its own ERP. The division of responsibilities between ERP and MES should support the chosen architecture without being used as shorthand for local independence.
Choose the shared responsibilities before the system landscape
Favor a common global approach where shared operating rules and close cross-site coordination justify collective control over changes. Favor a corporate core with local ERPs where meaningful operating differences justify local responsibility, and where the organization is prepared to own the mappings, interfaces and reconciliations connecting them.
Neither choice removes governance. The common approach concentrates decisions about shared processes and releases. The hybrid approach places more responsibility at the boundaries between systems. The better design is the one whose continuing responsibilities the business can explain, assign and sustain.
If you are defining that division across countries and plants, Digiventi’s ERP services are a relevant next step for discussing process configuration and system integration together.