ERP and system integration is a design and operations discipline that makes data flow correctly, securely and traceably between the enterprise resource planning (ERP) system and manufacturing execution (MES), quality, maintenance, warehouse and shop floor control systems. This guide is for IT, integration and project teams that want to plan an integration project step by step, from inventory to post go-live support.
In integration projects the problem is usually not the technology but missing decisions: who owns which data, which system tells the truth, what happens if a message is lost? This guide covers those decisions first, then the technical patterns.
System inventory
Integration design starts by mapping the current systems. The inventory is not just a list of software names; it shows what data each system holds, which interfaces it offers, who manages it and what constraints it has.
Manual transfers are the most valuable findings. A user who takes a list from one system every morning and keys it into another is both an automation opportunity and a data inconsistency risk that exists today.
Don't build the inventory once and leave it. Every new system, version upgrade or interface change should be recorded in it. In practice the easiest way to ensure this is to keep the inventory in the same place as the interface specifications and add an “is the inventory updated?” step to the change request process. That way the post go-live support team can see from one place which systems and flows are affected when investigating an error, and a new project starts from a current map instead of discovery from scratch.
ISA-95 levels: ERP, MES and control
ISA-95 (IEC 62264) is an international standard that defines integration between business systems and manufacturing control systems. Its level model makes clear which decision is made at which layer and on what time scale, which makes it easier to decide where each piece of data should live.
- Level 4: Business planningERP: orders, stock, cost
- Level 3: Operations mgmtMES: work orders, traceability, OEE
- Level 2: Supervisory controlSCADA, HMI
- Level 1: Sensing and controlPLC, sensors, drives
- Level 0: Physical processMachines and process equipment
- Level 4 (business planning and logistics): ERP; planning, purchasing, inventory and cost on a scale of days, weeks and months.
- Level 3 (manufacturing operations management): MES and similar systems; work orders, traceability, quality and performance on a scale of shifts, hours and minutes.
- Levels 2, 1 and 0 (control): SCADA, PLCs, sensors and the physical process; control on a scale of seconds and milliseconds.
General rule: the ERP should not talk directly to PLCs. Shop floor data is collected and interpreted at level 3 and passed to the ERP in summary form (production receipts, consumption, scrap). This separation protects both performance and security.
Source of truth decisions
The source of truth is the single system where a data object is created, changed and held accountable for accuracy. Other systems can use a copy of that data but don't change it. If this decision isn't written down for every data object, the same record starts living in two systems with different values.
| Data object | Typical source of truth | Consuming systems |
|---|---|---|
| Item master | ERP | MES, quality, warehouse |
| Business partner (customer, supplier) | ERP | CRM, quality |
| BOM and routing | ERP or PLM / MRP | MES, costing |
| Sales order | ERP | Planning, CRM |
| Work order status | MES / MRP | ERP, reporting |
| Production receipt and consumption | MES / MRP | ERP (stock, cost) |
| Equipment and maintenance history | Maintenance system | MES, OEE reports |
| Quality results and non-conformity | Quality system | MES, ERP (blocking) |
| Controlled document | Document system | MES, quality |
The assignments in the table are a typical starting point; yours may differ. What matters is that each row has one answer and that the answer is approved by the business owners. If there are field-level exceptions (e.g. item master in the ERP, but shelf life in the quality system), write those down separately too.
Integration patterns
The right integration pattern is chosen based on how current the data must be, its volume, what the source system offers and the tolerance for errors. Using more than one pattern in a single project is normal.
| Pattern | Strength | Weakness |
|---|---|---|
| File transfer (CSV, XML) | Simple, available everywhere | Delayed, hard to track errors |
| Direct database | Quick to set up | Tight coupling, version risk |
| REST API | Standard, can be authorised | Depends on the source system's API |
| Message queue | Loosely coupled, durable | Needs infrastructure and ops skills |
| ETL / bulk load | High volume, good for reporting | Not real time |
| CDC (change data capture) | Low load on source, current data | Complex setup and monitoring |
Avoid writing directly into another system's database. It looks fast, but it bypasses business rules, breaks with software updates and often puts vendor support at risk. Even for reads, prefer the views or API the system provides wherever possible.
Interface specification template
Prepare an interface specification for every integration flow. It gives the developer, the test team and the post go-live support team the same reference. The fields below are a good starting template.
| Field | Content |
|---|---|
| Interface code and name | Unique ID, e.g. INT-ERP-MES-01 |
| Source and target | Sending and receiving system |
| Business purpose | Which business need this flow serves |
| Trigger and frequency | Event, scheduled job, real time |
| Pattern and protocol | REST, queue, file, CDC |
| Field mapping | Source field, target field, transformation |
| Validation rules | Mandatory fields, formats, code lists |
| Unique key | Business key for duplicate checks |
| Error behaviour | Retry, parking, notification |
| Volume and performance | Expected record count, time target |
| Security | Account, permissions, encryption, personal data |
| Owners | Business owner, technical owner, support team |
Error handling, retries and idempotency
Every integration fails sooner or later: the network drops, the target system is under maintenance, a code list is missing. Good design focuses not on preventing errors but on making them visible, safe and recoverable.
- 01ReceiveStore the message with its unique ID
- 02ValidateCheck mandatory fields and codes
- 03TransformApply the field mapping
- 04WriteApply to the target idempotently
- 05AcknowledgeReport the result to source and log
- Separate transient from permanent errors: a network timeout is retried; a missing item code won't be fixed by retrying and must be reported to a person.
- Retry with increasing intervals (exponential backoff) and set a limit; when the limit is reached, the message moves to a dead letter queue.
- Idempotency: if the same message arrives twice, the result must not change. For this, every message carries a unique business key (e.g. source system + document number + line) and the target checks whether it has already processed that key.
- Ordering: if the order of messages for the same record matters (e.g. open a work order, then close it), take this into account in pattern choice and key design.
- Manual intervention: define who has permission to view, correct and resend messages in the dead letter queue.
Logging and monitoring
Logging is there so you can answer “why didn't this order reach the ERP?” within minutes. Monitoring lets you ask that question before a user does.
- For every message, log the timestamp, interface code, business key, result and error message.
- Logs are collected in one place and searchable by business key.
- Fields with personal data are not written to logs in plain text; mask them where needed.
- Monitoring indicators: messages processed, error count, messages in the dead letter queue, latency.
- When a threshold is crossed (e.g. messages waiting in the queue, or time since the last successful transfer), an alert is raised and sent to the owner.
- Log retention is set according to audit and legal needs.
OREL DM can be used to monitor when and why data pipelines stop and to show where each piece of data came from with lineage. That way integration monitoring happens in one place instead of being spread across separate tools.
Security and data protection
Integration accounts are often the most privileged and least monitored accounts in your systems. That is why security must be addressed from the first day of design.
From a KVKK perspective, an integration is itself a data transfer. Document which personal data is transferred, for what purpose, to which system and (if cloud is used) to which country. The final decision on this assessment should be made with your legal or compliance expert.
Test strategy
Integration testing is built on the assumption that two systems working correctly on their own doesn't mean they will work correctly together. The test layers complement each other; none is enough on its own.
- ReconciliationDo both systems show the same result?
- End-to-end testReal business scenario, all systems
- Contract testConformance to the interface spec
- Unit testTransformation and validation rules
- 01Unit tests
Field transformations, unit conversions, code mappings and validation rules are tested one by one.
- 02Contract tests
Check that sender and receiver conform to the interface spec (fields, types, mandatory rules), even when each side changes independently.
- 03End-to-end tests
Real business scenarios, from sales order to production and from production to stock and cost, are run with all systems in the test environment, including failure scenarios (outage, duplicate message, missing code).
- 04Reconciliation tests
Record counts, quantities and amounts in both systems are compared for a given period; every difference is explained.
- 05Performance test
The expected peak volume (month end, season) is tried in the test environment; duration and resource use are measured.
Testing only the “happy path” is the most common gap. Integrations that go live without testing network outages, target system maintenance, duplicate messages and missing master data can silently lose data on their first real failure.
Cutover and ownership
Integration cutover should be planned together with the migration of master data and open balances. Write down in advance which flows open in which order, when old transfers are switched off and how long parallel running lasts.
| Role | Responsibility |
|---|---|
| Business owner | Meaning and accuracy of data, change approval |
| Technical owner | Interface operation, change development |
| Support team | Monitoring, first response, resending |
| Security / compliance | Account and permission audit, KVKK assessment |
An integration with unclear ownership turns, a few months after go-live, into a black box nobody dares to touch. Updating the interface specification with every change request and having owners regularly review error and reconciliation reports reduces this risk.
In the first weeks after cutover, reviewing integration errors daily is recommended. Most errors in this period come from master data gaps, differences in code lists or volume effects not seen in the test environment. Record the root cause of each error and define a permanent fix (a validation rule, a master data process or an interface change) so the same type of error doesn't recur. Once the error rate drops and settles, the review can move to a weekly or monthly cadence.
Conclusion
A good ERP integration starts with the right decisions before the right tools: inventory, source of truth, interface specification and ownership. Then come a design that makes errors visible and recoverable, security that runs on least privilege and tests that go beyond the happy path. By reusing the checklists in this guide for every new interface, you can manage your integrations as a consistent architecture rather than one by one.