Summary
SAP/MES/shop floor interfaces are not a subject of secondary technical integration. In an industrial environment, they often constitute the nervous system of the digital factory: they carry orders, operating status, consumption, quality results, machine parameters, OPC UA events, labels, batches, confirmations and sometimes the data necessary for product release.
The difficulty is that these flows cross rarely aligned organizational boundaries: ERP, MES, automation, infrastructure, cybersecurity, methods, quality, production and support. An interface can be technically available while being functionally unusable if the source of truth is unclear, if the recovery rules are not defined, or if operations team does not know how to diagnose the incident.
A robust interface is therefore conceived as a critical industrial process. The protocol — RFC, IDoc, API, OPC UA, file, SQL base, SAP MII, SAP PCo or middleware — comes after clarification of the trigger, data owner, granularity, recovery scenario, and monitoring criteria.
Put business ownership back at the centre of interface design
The first trap is to delegate the interface to the technical teams alone. However, most of the incidents visible in production come from a business ambiguity: who decides the status of an order? Who is responsible for a corrected quantity? Can MES create a batch or should it only consume an SAP batch? Can a machine measurement be retired? Should a partial declaration close the transaction?
These issues are not within the scope of the protocol. They are the responsibility of the governance process. Without an explicit decision, each system interprets the flow according to its own logic, and then the support teams discover the gap after go-live.
Fenlynks recommends producing an interface sheet that begins with the covered process, business decisions and exceptional cases, before detailing the technical format.
Define the source of truth for each data element
In SAP/MES architectures, the term “source of truth” is often used too widely. It is not enough to say that SAP is master of the data. SAP can be master of the order, MES master of the execution, the master equipment of the machine event and the master laboratory of the control result. The granularity must be finer.
For each critical data, it is necessary to define the author system, the consumer system, the rules of modification, the acceptable deviation thresholds, the method of correction and the business owner. Otherwise, the differences accumulate: order present in SAP but absent from MES, batch existing in MES but not reconciled in SAP, quantity produced different from the confirmed quantity, incoherent quality status between inventory and shop floor.
Treat OPC UA as an information model, not merely a data pipe
OPC UA is often approached as machine connectivity. The real question is the information model exposed: which nodes are readable, which values are stored historically, what frequency is useful, which tags are reliable, which machine states have business meaning, and how state changes are interpreted.
A tag that exposes a temperature value, a counter, or a line state does not create a value in itself. It is necessary to define whether this data is used to release a batch, calculate a performance indicator, trigger an alert, feed an eBR, generate a non-compliance or simply contextualize an event.
On the shop floor, issues often arise from an insufficiently governed mapping table: non-standardised tag names, inconsistent units, null values not interpreted, PLC changes not reflected, or absence of versioning of the model.
De-risk SAP MII/PCo through operations, not just by development
SAP MII and SAP PCo can play a useful role in the collection, processing and orchestration of industrial flows. Their main risk is not their technical capacity, but their maintainability: undocumented transactions, critical jobs known to a single expert, unsupervised destinations, logs difficult to operate, lack of non-regression tests.
An IBI/PCo environment should be treated as a critical asset. It requires a flow catalog, a dependency mapping, a transport policy, recovery scenarios, a media-readable monitoring and a clear distinction between technical and business incident.
In a rigorous logic, the question is not “should we replace MII? " The question is “what flows still carry a value, which flows expose the plant, what flows should be modernized, and in what order? »
Test recovery scenarios before standard flows
A nominal stream will often work in testing. The real risks appear on timeouts, double sending, message rejected, incomplete value, equipment unavailable, SAP locked, change of status late, time difference or operator correction.
Each critical interface must have a replay scenario. It is necessary to know if the replay is automatic, manual, prohibited, conditioned or controlled by a workflow. It is also necessary to define whether the system should be idempotent: receiving twice the same event must not double a consumption or create two confirmations.
Cases of recovery must be written in the testing book. If they are not tested before go-live, they will be discovered in production, usually at the worst time: team change, end of post, batch closure, urgent shipment or quality audit.
Establish an actionable OT/IT support model
Support for an SAP/MES/shop floor interface fails when no one has end-to-end vision. The automation engineer sees the available tag, MES team sees a rejected message, SAP sees an application error, and business teams see a blocked line. Diagnosis time increases dramatically.
An effective support model defines diagnostic levels: equipment availability, PCo availability, MII transaction, middleware, SAP message, functional data, business decision. It also defines escalation thresholds, on-call arrangements, minimum documentation and recurrence indicators.
The run must be designed before the go-live, not rebuilt after several weeks of incidents.
Decision matrix
The following matrix makes it possible to differentiate the interfaces that must be industrialized as a priority from those that may remain simpler.
| Criterion | Question to Ask | Risk signal |
|---|---|---|
| Industrial criticality | Can the flow stop a line, block a batch or prevent a shipment? | Absence of workaround plan tested |
| Source of Truth | Is the business owner of the data explicit? | Data corrected in several systems |
| Takeover | Is the replay documented, secure and tested? | Manual correction not traced |
| Supervision | Does the support know how to diagnose in less than 15 minutes? | Dispersed or incomprehensible logs |
| Maintainability | Are the mappings and rules versioned? | Dependence on a single expert |
Anonymised case study
In a batch production context, a confirmation interface traced the actual consumption of MES to SAP. The nominal flow was working, but an operator correction after partial closure generated a difference between the quantity consumed in MES and SAP inventory movement. The incident was not technical: the late correction business scenario had not been resolved.
The resolution did not consist of “correcting the interface”, but defining a management rule: permitted correction window, validation role, order status, SAP movement type, audit trace, replay scenario and error message understandable to users. The main gain was the reduction of diagnostic time and the removal of ungoverned manual corrections.
Executive questions
- Do we have a comprehensive map of SAP/MES/OT flows that are truly critical for production?
- For each stream, do we know who owns the data, who can correct it, and how it is reconciled?
- Have fault scenarios, dual shipping, timeouts, SAP rejection and manual recovery been tested?
- Does the support have an end-to-end diagnostic procedure, understandable outside the project team?
- Is the MII/PCo trajectory driven by business criticality or technological opportunism?
Operational checklist
- Map the flows by industrial process, not just by system.
- Define a source of truth, trigger, frequency, format, rejection rule, and recovery rule.
- Test timeouts, dual execution, network cut-off, SAP rejection and business correction.
- Set up a support-oriented monitoring, with explicit OT/IT responsibilities.
- Rank MII/PCo flows to maintain, secure, simplify or modernize.
Conclusion
The robustness of an SAP/MES interface does not depend primarily on the protocol chosen. It depends on the quality of business decisions, the clarity of responsibilities, the ability to test exception scenarios and the maturity of operations. In a digital factory, the interface is not a technical line in a schedule: it is a critical operational asset.
Fenlynks provides scoping, rapid audits, business project support (AMOA), testing assurance, project governance and post-go-live stabilisation.