An integration between enterprise planning and the shop floor is not a data transfer. It is a set of decisions about what the plant’s reality is called in the system of record.
An order should not change meaning as it travels from ERP to production, inventory, quality and shipment. A released order is only useful once MES has the right version, material availability is understood, and completion and consumption return without manual reconstruction.
This table is the real scoping conversation. Each row is a business decision rather than a technical one, and each one has a finance consequence, which is why an integration team cannot make them alone.
An interface built before these are answered will encode somebody’s guess, and the guess becomes the plant’s accounting for as long as the interface runs.
Disconnected ERP and manufacturing applications
Each system is internally correct and the pair is inconsistent. Nobody discovers it until a physical stock count or a month end, and by then the divergence has been accumulating for weeks.
Inconsistent master data across enterprise systems
The same material has three identifiers, two units of measure and a different description in each system. This is unglamorous, it is the precondition for everything else, and it is routinely descoped.
Manual order, inventory and production data transfers
A spreadsheet emailed between planning and the plant, re-keyed at both ends. It works, it has an error rate nobody measures, and it stops entirely when one person is away.
Delayed synchronisation between planning and execution
The plant works to yesterday’s plan and planning sees yesterday’s output. Both are therefore making decisions on information the other has already superseded.
Complex legacy ERP integrations
Older ERP instances with interfaces built over a decade by people who have left, often undocumented, frequently with business logic embedded in the interface rather than in either system.
Multiple ERP environments across manufacturing plants
Usually acquired with the plants. Harmonising the instances is a multi-year programme. Harmonising the small set of records that must cross plant boundaries is achievable this year.
Limited end-to-end transaction visibility
When an order is late, nobody can say whether it was never dispatched, dispatched and not received, received and not scheduled, or made and not confirmed. Each has a different owner and a different fix.
Integration failures affecting manufacturing operations
These interfaces are production dependencies. A failure overnight is a plant without work in the morning, which is why the fallback path in section 7 is a design item rather than an operational detail.
ERP modernisation and migration complexity
During a migration both ERP instances exist and the plant has to keep running against both. Coexistence is the hardest integration work in this category and it is covered in section 5.
The sequence below front-loads the decisions. It looks slower for the first three weeks and it is the only order that avoids rebuilding interfaces after the first month end exposes what they assumed.
Step 1
Enterprise application and manufacturing systems assessment
Which systems hold which record, which interfaces already exist, and which of those are documented. The undocumented ones are the project risk.
Which systems hold which record, which interfaces already exist, and which of those are documented. The undocumented ones are the project risk.
Step 2
Business process and integration dependency mapping
The order to cash and plan to produce flows as they actually run, including the manual steps, because the manual steps are usually where the business rule lives.
The order to cash and plan to produce flows as they actually run, including the manual steps, because the manual steps are usually where the business rule lives.
Step 3
ERP and manufacturing data flow discovery
What moves today, by what mechanism, at what frequency and with what failure behaviour. File drops and scheduled jobs count and are frequently missed.
What moves today, by what mechanism, at what frequency and with what failure behaviour. File drops and scheduled jobs count and are frequently missed.
Step 4
Master data and transaction mapping
Material, plant, work centre, unit of measure, BOM and routing reconciled across systems, with a single owner named for each. This is the stage that is cut when timelines compress and the one that causes the rework.
Material, plant, work centre, unit of measure, BOM and routing reconciled across systems, with a single owner named for each. This is the stage that is cut when timelines compress and the one that causes the rework.
Step 5
Integration architecture and technology selection
Chosen against your existing platform commitments and against what your team can operate, not against a market category.
Chosen against your existing platform commitments and against what your team can operate, not against a market category.
Step 6
API, event-driven and batch integration design
Each flow assigned the pattern that fits its volume, latency and consistency requirement. Mixing the three deliberately is correct; defaulting all three to one is where the cost appears.
Each flow assigned the pattern that fits its volume, latency and consistency requirement. Mixing the three deliberately is correct; defaulting all three to one is where the cost appears.
Step 7
ERP to manufacturing workflow implementation
Built with the six decisions from section 2 answered and recorded, so the behaviour is traceable to a business decision rather than to an implementation choice.
Built with the six decisions from section 2 answered and recorded, so the behaviour is traceable to a business decision rather than to an implementation choice.
Step 8
Integration testing and transaction reconciliation
Tested on volume and on the exception cases, with a reconciliation that compares both systems transaction by transaction rather than in totals. Totals agree while details disagree, routinely.
Tested on volume and on the exception cases, with a reconciliation that compares both systems transaction by transaction rather than in totals. Totals agree while details disagree, routinely.
Step 9
Phased deployment and operational transition
By flow and by plant, with the fallback path proven before each flow goes live and support handover completed rather than assumed.
By flow and by plant, with the fallback path proven before each flow goes live and support handover completed rather than assumed.
Step 10
Continuous integration monitoring and optimisation
Reconciliation running continuously rather than at month end, with exception ageing visible and owned.
Reconciliation running continuously rather than at month end, with exception ageing visible and owned.
For every interface below, one system owns the record and the other holds a copy. Stating which, in writing, before build, is what prevents the slow divergence that nobody notices until a stock count.
ERP to MES integration
Orders and master data down, confirmations and consumption up. ERP owns the plan, the plant owns the actual. The execution side of this interface is covered on the MES & Shop Floor Integration page.
ERP to PLM integration
Engineering releases flowing into manufacturing BOMs and routings, with the revision carried so the plant can tell which version it is building.
ERP to WMS integration
Material issue, staging, returns and finished goods receipt, with the handoff point between warehouse and production defined physically as well as in the system.
ERP to CMMS and EAM integration
Maintenance work orders, costs and asset records, plus planned downtime visible to production scheduling before it happens.
ERP to quality management system integration
Inspection results, holds, dispositions and nonconformance, with a hold in quality actually blocking movement in ERP rather than being advisory.
Production order and work order synchronisation
Dispatch, status, changes and close, including the awkward cases: a cancelled order partly made, a split order and a quantity change after start.
Inventory and material movement integration
Issues, consumption, transfers and adjustments, with backflush behaviour decided explicitly because backflush is where inventory accuracy is usually lost.
Bill of materials and routing synchronisation
Engineering to manufacturing BOM, with effectivity dates handled so that a change mid-run does not retrospectively alter what was built.
Procurement and supplier data integration
Purchase orders, confirmations, receipts and supplier master, including the EDI flows where they exist.
Manufacturing master data integration
Material, plant, work centre, unit of measure and the conversion rules between units, which is the single most common source of quantity errors.
Multi-ERP integration and harmonisation
A defined cross-plant record set rather than a full harmonisation programme, so group reporting and inter-plant supply work without waiting for a single instance.
Each flow is easy in the normal case. The exception named for each is what the interface actually has to be designed around, because the exception is what happens on a Tuesday.
Production order synchronisation
Orders released in ERP and dispatched to the plant, with status returning.
Inventory availability and material consumption updates
Stock position and consumption moving between ERP and the plant.
Bill of materials and routing updates
Engineering changes reaching manufacturing.
Manufacturing work order status synchronisation
Progress visible to planning during the run rather than at close.
Quality inspection and nonconformance data integration
Results and holds connected to the order and the material.
Warehouse and production material movement
Staging, issue, return and finished goods receipt.
Procurement and supplier transaction integration
Purchase orders, confirmations and receipts, including EDI where it is in use.
Finished goods and shipment updates
Completion, putaway and despatch.
Multi-plant ERP consolidation
A defined set of records made consistent across plants running different instances.
ERP migration and coexistence integration
Both ERP instances live while plants move across in waves.
The common mistake is picking one integration style and applying it everywhere. A thousand-line BOM extract does not belong on a synchronous API, and an order dispatch does not belong in an overnight batch. The style follows the flow.
Enterprise integration reference architecture
A layered model with the system of record named per domain, and every interface documented as a contract rather than as a field map.
SAP, Oracle, Microsoft Dynamics 365 and other ERP connectivity
We work with the interfaces each platform provides. Which ERP you run changes the mechanism and not the six decisions in section 2, which are the same everywhere.
REST, SOAP, OData and enterprise APIs
Used where the volume and latency suit them. Modern interface styles do not remove the need to decide what a transaction means.
IDoc, BAPI, RFC and ERP-specific interfaces where applicable
Still the right answer for many high-volume ERP flows. Replacing a working ERP-native interface with an API because it is newer is a cost with no benefit.
Event-driven integration and message brokers
Production and inventory events published once and consumed by whatever needs them, with delivery guarantees stated per topic.
EDI and B2B transaction integration
Customer and supplier transaction exchange, including the mapping and the acknowledgement handling that EDI partners require.
ETL and ELT and scheduled data synchronisation
Appropriate for master data and for reporting extracts. Explicitly not appropriate for anything the plant acts on within a shift.
Canonical data models and transformation
Built per domain from the flows that exist, extended when a new flow needs it. The enterprise-wide version of this is discussed on the Data & Application Integration page and is not attempted here.
Middleware and integration platform connectivity
Working with the platform you already run where it is fit for purpose. Where it is not, that is the subject of the Integration Platform Modernization page.
Hybrid cloud and on-premises integration
Cloud ERP with on-premises plant systems is the normal case. The link between them is a production dependency and is designed as one.
Governance defines who may change an interface, how exceptions get resolved, and how production continuity is protected. Everything below serves one of those three.
These interfaces are production dependencies. The controls below are ordinary enterprise integration controls plus one that is specific to manufacturing: a documented, rehearsed fallback for each flow, agreed with operations before go-live.
ERP integration security and access management
Service accounts with least privilege, per-interface credentials, and no shared account across interfaces. An interface account with broad ERP authority is a finding waiting to be written.
Master data governance and ownership
One named owner per master data domain, with a change process. Integration propagates master data, so an ungoverned domain becomes an ungoverned domain everywhere.
Transaction integrity and reconciliation
Reconciliation per interface, transaction by transaction rather than on totals, running continuously with exception ageing visible. Totals agreeing while details diverge is the characteristic failure here.
Error handling and exception management
Every interface has a defined behaviour for a rejected record: retried, queued, or routed to a named person. An exception queue with no owner is a data loss mechanism with a dashboard.
Audit trails and integration traceability
What was sent, when, by which version, what came back and what the resulting posting was, retained so a financial figure can be traced to the plant event behind it.
Change management and version control
Interface changes follow the same release process as the systems they connect, with the counterparty retesting. An interface changed on one side only is the most common cause of an outage in this category.
Business continuity and recovery
Recovery point and recovery time agreed per interface with operations, and a replay capability for the window that was missed. Recovery that loses a shift of transactions is not recovery.
Sensitive manufacturing and supplier data protection
Pricing, supplier terms, formulations and process parameters restricted at the interface rather than only at the application. An integration layer with everything in it is a single place to lose all of it.
Integration ownership and operational accountability
A named owner per interface, an on-call route, and a documented escalation that reaches somebody who can authorise a manual workaround during a shift.
The one is reconciliation at transaction level. Availability can be high, latency low and error rates near zero while the two systems quietly disagree, and only a transaction-level comparison finds it.
Integration availability and reliability
Per interface, measured against the window in which the plant needs it rather than as a monthly average. An interface that is down from four to six every morning has excellent monthly availability and is useless.
Transaction processing latency
End to end, from the event to the posting, including any queue wait. Measured at the percentile that matters rather than the mean.
Data synchronisation accuracy
Field-level agreement between systems on a sampled basis, which catches the slow divergence that record counts do not.
Failed transaction and retry rates
With the failure reason classified, because a validation rejection and a timeout need different responses and are usually reported together.
Order and inventory reconciliation
The primary measure. Transaction by transaction, continuously, with any difference ageing visibly until somebody closes it.
Integration exception resolution time
From exception raised to closed, with the backlog age distribution rather than the count. A stable count can hide a growing tail of items nobody will ever resolve.
ERP interface performance
Load placed on the ERP instance by integration, which is a capacity planning input and frequently the reason a month end runs slowly.
Integration throughput and scalability
Against peak rather than average, with peak defined by the actual business cycle: a month end, a campaign, a seasonal peak.
Operational support and maintenance efficiency
Effort spent keeping existing interfaces running, which is the number that tells you whether the estate is sustainable or accumulating.
Continuous integration improvement
Interfaces retired, consolidated or simplified, tracked deliberately. Without it an integration estate only grows.
Connected enterprise and manufacturing operations, where a late order can be traced to the step that delayed it rather than debated between functions
Improved transaction accuracy, most of it from the six decisions in section 2 being made explicitly rather than from the interface itself
Reduced manual data transfers, with the remaining manual steps documented as the fallback path rather than left as undeclared dependencies
Better production and inventory synchronisation, which depends on master data being reconciled first and will not arrive before that
Improved end-to-end operational visibility, available once the confirmation point supports the resolution the question needs
Scalable ERP modernisation, with coexistence integration built to be operated rather than built to be thrown away
If your ERP and your plant disagree and nobody can say why, the cause is usually one of the six decisions in section 2 having been made implicitly, by an interface, years ago. Start there.
CaliberFocus integrates ERP with the plant by answering the business questions first: the six plant events ERP has no word for, the confirmation point, and the system of record for every interface. We reconcile transaction by transaction rather than on totals, and deliver every interface with a rehearsed fallback so the plant can run the shift without it.
- The six plant event decisions answered in writing with finance and operations
- A deliberate confirmation point, chosen once
- Continuous transaction-level reconciliation
- A documented, rehearsed fallback path for every interface
Security & Compliance
