Decide which work belongs in ERP, MES, LIMS and QMS

System overlap is often an ownership problem

A manufacturer wants to replace its pharma ERP because quality status is inconsistent across the warehouse and laboratory. The investigation finds that three systems can update the same status, each using a different definition of “complete”.

Replacing a platform may be justified, but the architecture decision should begin with the work and its authority. A new application can reproduce the same ambiguity if the organisation has not agreed who owns the record, what a status means and how other systems learn about changes.

For applicable computerised systems, lifecycle, data and interface controls need assessment within the relevant regulatory scope. EU GMP Annex 11 provides one such framework; it does not prescribe a universal arrangement of ERP, MES, LIMS and QMS products. EU GMP Annex 11.

Start with decisions people make

List the operating decisions that matter: what purchasing may buy, which material may be used, whether equipment is ready, which procedure applies, whether testing is complete, who makes disposition decisions and how finance records the result.

For each decision, identify the authorised role, evidence required, current system and downstream users. This reveals whether the problem concerns missing functionality, poor data, unclear responsibility or unreliable integration.

Avoid beginning with a feature inventory. Several products may offer approvals, attachments and dashboards, but those similarities do not establish where a regulated record or business decision should live. The intended use and operating process provide the basis.

Use system roles as a starting hypothesis

Enterprise resource planning (ERP) commonly coordinates commercial, planning, inventory and financial transactions. Manufacturing execution systems (MES) support production execution and related records. Laboratory information management systems (LIMS) support sample, test and result workflows. Quality management systems (QMS) support processes such as deviations, changes and corrective actions. Actual product capabilities and implementations vary.

Treat those descriptions as an initial allocation to test, not a rigid rule. A company may use an integrated suite or several specialised applications. The architecture is sound when ownership and behaviour are clear, not when it matches a fashionable diagram.

The answer may involve linked records, but one system's summary should not silently replace the evidence held elsewhere.

Worked example: follow one batch across the landscape

Consider an illustrative batch B410. ERP records the purchase and receipt of a material lot, its inventory movements and the production order. The approved quality process determines the material's disposition, and the warehouse uses that authoritative status when planning use.

MES records the manufacturing execution associated with B410, including relevant material relationships and actual activity. LIMS receives the batch's samples, manages tests and retains reviewed laboratory results. QMS holds a linked deviation that requires assessment before the authorised batch decision.

The architecture should let a reviewer follow these relationships without copying every attachment into every application. A common batch reference and controlled mappings connect the records, while each system preserves the evidence it owns.

Suppose all laboratory tests are reviewed but the deviation remains unresolved. “Laboratory review complete” must not become “batch released” through an overly simple interface mapping. The authorised disposition process evaluates the required evidence and issues its own decision.

Finance later receives the relevant production quantities and cost transactions. Its costing calculation should not change quality status, and a closed production order should not erase an open quality issue.

This example illustrates ownership and handovers. It does not prescribe a release authority or a specific vendor architecture for every site.

Define identities and relationships explicitly

List the identifiers used for product, material, supplier site, batch, sample, equipment, procedure and quality event. Decide where each identity is created and how other systems reference it. Similar display names are insufficient for dependable integration.

Keep local identifiers where necessary, with controlled mappings to shared references. Forcing every legacy system to use one new code immediately may create avoidable migration risk. The important requirement is that the relationships remain unambiguous and reviewable.

Define units and version references alongside identities. A result value without a unit or a procedure link without its version can be technically transmitted while losing its meaning. Interface testing should assess that meaning, not only field presence.

Assign an owner to each mapping and record how changes reach dependent systems. A correct initial mapping can become unreliable when one application introduces a new product presentation or local code without updating the agreed relationship.

Give status changes one authoritative route

Create a status model for each important object. Material availability, laboratory review, manufacturing completion and product disposition are different concepts. If several systems use the same label, document whether they actually mean the same thing.

Identify who may create or change the authoritative state and how consumers receive it. Other systems can display or enforce the state within their intended use, but should not independently infer a conflicting decision from partial evidence.

Include effective time, version and source reference in the event contract where needed. A delayed older message should not overwrite a later restriction. When the receiving system cannot establish a reliable state, the approved process should define how uncertainty is handled.

Design interfaces as business handovers

For each interface, specify the triggering event, payload, identity, expected acknowledgement, update rule and reconciliation owner. A transport success response does not necessarily establish that the receiving system completed the intended business action.

Distinguish safe replay from a new event. If an invoice or result message is retried, the receiver should recognise the relevant identity and version. Blindly creating another record can produce duplicates that later require substantial manual correction.

Make unresolved events visible to operating owners. Technical logs support diagnosis, but a laboratory or warehouse user needs to know which sample, batch or movement is affected and what action is required. The integration team and business owner should share a clear incident boundary.

Preserve evidence without creating uncontrolled copies

Decide when to retain a reference, a controlled snapshot or the underlying record. The answer depends on intended use, availability, retention and the need to reconstruct a decision. Copying everything everywhere can create conflicting versions and unclear retention obligations.

Test whether an authorised reviewer can retrieve the evidence used at the time of a decision. A link that always opens the newest document may not support historical reconstruction. A link that depends on a discontinued service may fail entirely after a system transition.

FDA's drug CGMP data-integrity guidance discusses records and associated context within its scope. Use that context to assess the evidence users rely on, without assuming that a summary dashboard replaces the underlying record. FDA data-integrity guidance.

Compare integration, improvement and replacement

Once the ownership model is clear, identify the actual capability gaps. Some problems may be resolved through configuration, better master data or a controlled interface. Others may require a new application because the current system cannot support the intended records or controls.

Compare options against the same operating scenarios and lifecycle costs. Include migration, assurance, training, administration, support and supplier changes. A replacement programme can carry benefits, but its cost and transition risk should be assessed alongside the narrower alternatives.

Use the warehouse software guide and QMS evaluation guide for deeper functional assessments. The architecture decision should connect those evaluations rather than repeat them as disconnected product selections.

Establish assurance responsibilities early

Define intended use and assess system and interface consequences with quality and operating owners. Supplier evidence can contribute, but the organisation needs an appropriate approach for its configured processes and actual reliance on the system.

The computer-system validation guide explains the lifecycle approach. Architecture work should identify the dependencies that validation planning must cover, including interfaces, shared infrastructure and record retention.

Avoid treating each application as an isolated validated island. A correct source record and a correct receiving screen can still be connected by a faulty unit conversion or status mapping. End-to-end verification needs to test the business meaning across the handover.

Deliver a complete small flow first

Choose a bounded path with clear value and manageable dependencies, such as material status communication to one warehouse process. Include normal operation, a hold, a delayed message and recovery. A complete small flow provides better evidence than several unfinished modules.

Define acceptance conditions before implementation. The operating team should be able to perform the work, identify uncertainty, resolve exceptions and retrieve the evidence. Technical deployment alone is not the completion criterion.

Plan how the flow coexists with legacy processes during transition. State which system is authoritative at each stage and prevent users from maintaining competing live records without a controlled reconciliation approach.

Plan migration, continuity and retirement together

Inventory records and relationships that must move or remain accessible. Define mapping, verification, cut-over and recovery criteria. Include open transactions and quality events rather than focusing only on closed historical records.

Assess how work continues if a connected service is unavailable. The approved continuity process should preserve the evidence needed for later reconciliation. Recovery must account for events created during the outage and avoid overwriting newer decisions.

For retirement, confirm that retained records remain readable and retrievable for the applicable purpose. Remove unnecessary access and interfaces while preserving the historical context required by authorised reviewers.

Assign ownership after the project ends

Name business, system, data and integration owners with defined responsibilities. Agree who reviews supplier releases, maintains mappings, investigates discrepancies and approves changes. An architecture that depends on one implementation consultant's memory will be difficult to operate.

Measure unresolved cross-system differences, time to reconstruct a batch history and incidents caused by conflicting status. These measures reveal whether the architecture improves operating reliability. API volume and dashboard count are secondary indicators.

NextEdge Labs can support a focused ownership and integration assessment using one real business flow. The result should be a reviewable record map, interface decisions and phased delivery scope that the site's responsible teams can maintain.

Summary and next actions

ERP, MES, LIMS and QMS work together when their records, decisions and handovers have clear ownership. Platform selection should follow that operating model and its evidence requirements.

• Trace one batch and identify the authoritative record and decision owner at each stage.
• Resolve ambiguous identifiers, units, statuses and cross-system responsibilities.
• Compare integration and replacement options against the same end-to-end failure scenarios.
• Deliver one complete flow with assurance, continuity, migration and ongoing ownership agreed.