Connect981 – Content Dev

RSC Cluster: Data Mapping and System Interoperability

The Data Mapping and System Interoperability Cluster ties execution, planning, quality, and supplier systems together without rip-and-replace projects. It explains how governed data mapping enables interoperability across ERP, MES, QMS, PLM, and external partners. The content positions execution as the truth layer that systems align around. This cluster is the connective tissue of the entire ecosystem.

  • procedural model

    A procedural model is a structured representation of how a process is executed over time, capturing the ordered sequence of operations, phases, and steps required to carry out a task or batch. In industrial and manufacturing environments, it commonly refers to the modeled logic that defines what to do, in what order, and under which conditions.

    In the context of batch and process manufacturing

    Within standards such as ISA-88 (S88), the procedural model describes the hierarchy and flow of activities needed to run a batch or other process. It is distinct from the physical equipment model and focuses on what actions are performed rather than what hardware executes them.

    An S88-style procedural model typically includes:

    • Procedures: High-level descriptions of how to make a product or execute a major process.
    • Unit procedures: Segments of the process tied to a specific processing unit.
    • Operations: Logical groupings of tasks within a unit procedure, such as charging, heating, or mixing.
    • Phases: The smallest control-level actions, often directly implemented in a DCS, PLC, or batch engine.

    These elements are organized to express the process logic, including start and end conditions, interlocks, transitions, and exception handling. In practice, the procedural model is implemented in control systems, batch management systems, or MES as recipes, workflows, or automated sequences.

    Operational meaning

    Operationally, a procedural model:

    • Defines the execution flow for manufacturing a product, cleaning a system, or performing a changeover.
    • Provides a common structure that can be mapped to different units or equipment via recipes and equipment models.
    • Supports integration with MES, batch engines, and DCS/PLC logic by providing a clear hierarchy of steps.
    • Can be used as a reference when creating electronic batch records, digital work instructions, or automated workflows.

    In regulated environments, a well-defined procedural model helps maintain consistency of process execution, supports impact assessment when changes are made, and facilitates traceability of what was executed and when.

    Common confusion

    • Procedural model vs. equipment model: The equipment model describes the physical assets (units, modules, connections). The procedural model describes the process logic and sequence of actions. In S88, these are complementary but separate views.
    • Procedural model vs. recipe: A recipe often uses the procedural model structure but also includes parameters, formulas, and other product-specific data. The procedural model is the generic framework for how actions are organized and executed.
    • Procedural model vs. workflow diagram: Many tools show the procedural model as a workflow or flowchart, but the term usually implies a formally structured hierarchy (procedure, unit procedure, operation, phase) rather than an informal diagram.

    Connection to the S88 standard

    In the context of S88, the procedural model is one of the core models used to describe batch manufacturing. It provides a standardized way to break down and represent process logic so that recipes, control strategies, and MES/DCS/ERP integrations can be designed and discussed using a common language. S88 does not mandate specific software or hardware; instead, its procedural model is a conceptual framework that systems and plants may choose to implement.

  • phase

    In manufacturing and industrial automation, a phase commonly refers to the smallest reusable unit of equipment-level control logic that carries out a specific, well-defined action. The term is widely used in batch control models such as those based on ISA‑88.

    Core meaning in manufacturing and automation

    In the context of batch and equipment control, a phase typically:

    • Runs on or close to the equipment (for example on a PLC or DCS)
    • Performs one specific action, such as start agitator, heat to setpoint, or transfer material
    • Has a defined interface for commands (start, stop, hold, abort) and status (running, complete, aborted, failed)
    • Is reusable across multiple operations, unit procedures, or recipes

    A phase is usually part of an equipment module or unit. Higher-level recipe structures (such as operations and unit procedures) call phases to execute physical actions on the plant floor.

    Operational use

    In day-to-day operations, phases appear in control systems, batch execution systems, and MES as addressable objects that:

    • Expose parameters (for example setpoints, speeds, target quantities)
    • Produce events and status changes that can be logged for traceability
    • Are orchestrated by recipes or workflows to implement product-specific processes

    For example, a vessel unit might contain several phases such as Charge Material A, Heat and Hold, and Cool to Transfer. Different recipes sequence and parameterize these phases to produce different products while using the same equipment.

    Relation to ISA‑88

    ISA‑88 provides a reference model and terminology for batch control. In this model, phases are an element of the equipment control layer and are distinct from product recipes. Recipes define what to do in terms of procedures and operations, while phases define how specific equipment actions are executed. This separation supports modular design and clearer integration between automation, MES, and quality systems.

    Other common technical meaning

    Outside of batch and control logic, phase can also refer to the state of alternating current (AC) power (for example single-phase or three-phase power). In that context it describes the spatial and temporal relationship between voltage waveforms, not a control function or recipe element.

    Common confusion

    • Phase vs. operation: An operation is a higher-level recipe step and may call several phases. A phase is an equipment-level action with a standardized interface.
    • Phase vs. step: Some systems use step informally for any action. In ISA‑88 style models, phase has a specific meaning tied to equipment control, while step may be used more loosely within procedures or workflows.
    • Phase (control) vs. phase (power): In discussions that involve both automation and electrical engineering, it is important to clarify whether phase refers to control logic units or AC power characteristics.

  • IEC 61512

    IEC 61512 is an international standard that specifies models and terminology for batch control in manufacturing. It is the International Electrotechnical Commission (IEC) counterpart to the ISA‑88 standard and is often referenced jointly as ISA‑88 / IEC 61512.

    What IEC 61512 covers

    IEC 61512 commonly refers to a family of standards that describe:

    • Equipment models for batch plants, including how physical assets are structured into process cells, units, equipment modules, and control modules.
    • Procedural control models, defining how batch procedures are organized into processes, operations, and phases.
    • Recipe models, including concepts such as general, site, master, and control recipes, and how they relate to equipment and execution.
    • Consistent terminology so that engineering, operations, quality, and IT/OT teams describe batch activities in a common way.

    The standard is technology neutral. It does not prescribe specific hardware, software products, or architectures. Instead, it provides a reference model that vendors and manufacturers can use when designing and implementing batch control, DCS, PLC, MES, and related systems.

    Use in manufacturing and regulated environments

    In industrial operations, IEC 61512 is commonly applied when:

    • Designing or upgrading batch processes in industries such as pharmaceuticals, specialty chemicals, food and beverage, or biotech.
    • Structuring batch recipes and procedures in batch management or MES systems so they map cleanly to plant equipment.
    • Integrating control systems (for example DCS or PLC) with MES/ERP using ISA‑95-style models, while maintaining a consistent batch vocabulary from IEC 61512 / ISA‑88.
    • Documenting batch processes, recipes, and equipment in a way that supports change control and traceability.

    IEC 61512 itself does not guarantee product quality, regulatory compliance, or system performance. Those outcomes depend on how the standard is interpreted, implemented, validated, and maintained within a given plant or organization.

    Common confusion

    • IEC 61512 vs ISA‑88: In practice these terms are often used interchangeably. ISA‑88 is the original standard from the International Society of Automation; IEC 61512 is the aligned international standard. Concepts, models, and terminology are closely matched.
    • IEC 61512 vs ISA‑95: IEC 61512 / ISA‑88 focuses on batch control, recipes, and equipment models at the process and control level. ISA‑95 focuses on the interface and information models between enterprise systems (such as ERP) and manufacturing operations (such as MES and control systems). They are complementary but address different layers.
    • IEC 61512 vs safety standards: IEC 61512 is about batch control models and terminology, not functional safety. It is different from standards such as IEC 61508 or IEC 61511, which address safety-related systems.

    Relation to the S88 standard

    IEC 61512 is directly derived from and aligned with the S88 (ISA‑88) standard. References to S88 in batch system design, equipment modeling, or recipe structuring generally apply to IEC 61512 as well. Many vendors and practitioners simply say “S88” while their formal documentation cites IEC 61512 as the international reference.

  • data backbone

    A data backbone is the core data and integration structure that connects systems, moves information between them, and keeps shared operational data available across an organization. In manufacturing, it commonly refers to the combination of interfaces, data models, message flows, and governance used to connect systems such as MES, ERP, PLM, QMS, historians, and shop-floor equipment.

    The term usually describes an enterprise or plant-wide foundation rather than a single application. A data backbone may support work orders, material status, specifications, quality records, traceability, equipment data, and production events as they move across OT and IT boundaries. It can be built with middleware, APIs, event streams, service buses, data hubs, or similar integration patterns.

    It should not be confused with a database, a network backbone, or a full digital thread. A database stores data, and a network backbone carries traffic at the infrastructure level. A digital thread is a broader concept about connected lifecycle information and context. A data backbone is the practical data exchange layer that helps make those connections possible.

    In regulated or quality-sensitive environments, the term often implies consistent identifiers, controlled data handoffs, and reliable links between source systems, but it does not by itself indicate compliance or validation status.

  • Operations Platform

    An operations platform is a unified software environment used to coordinate and support day-to-day operations across manufacturing, supply chain, quality, and maintenance processes. It typically connects data, workflows, and user interfaces from multiple systems so that operational teams can plan, execute, monitor, and improve industrial activities from a common foundation.

    Key characteristics

    In regulated and industrial environments, an operations platform commonly:

    • Integrates OT and IT systems such as MES, ERP, PLM, QMS, maintenance, and logistics tools
    • Provides role-based interfaces for operators, supervisors, engineers, quality, and management
    • Centralizes operational data for visibility into work orders, materials, equipment status, quality results, and nonconformances
    • Supports governed workflows, approvals, and audit trails for changes and deviations
    • Enables analytics, KPIs, and alerts related to throughput, scrap, downtime, and compliance

    An operations platform may be delivered as a single product, a tightly integrated suite, or a collection of services that work together. The emphasis is on providing a cohesive operational environment rather than standalone point solutions.

    How it shows up in manufacturing workflows

    In manufacturing, an operations platform often sits between enterprise planning and the shop floor, coordinating:

    • Release of work orders, routings, and digital travelers to production
    • Execution of work instructions, data collection, inspections, and test results
    • Material status, kitting, shortages, and traceability across lots or serials
    • Nonconformance handling, MRB decisions, and CAPA workflows with full history
    • Performance visibility such as OEE, NPT, and yield across lines, cells, or sites

    In regulated sectors such as aerospace and defense, an operations platform commonly incorporates or connects to capabilities for document control, revision management, electronic records, and evidence needed to demonstrate process control and traceability.

    What it is not

    An operations platform is not the same as:

    • A single point solution, such as a standalone scheduling tool, SPC system, or digital work instruction tool, that does not provide broader integration or orchestration
    • A pure ERP system focused primarily on finance, high-level planning, and inventory accounting without deep execution control
    • A generic IT platform (for example, a low-code environment) that lacks manufacturing-specific data models and workflows unless explicitly configured for operations

    Common confusion

    The term “operations platform” is sometimes used interchangeably with:

    • MES (Manufacturing Execution System): MES focuses on execution control on the shop floor. An operations platform may include MES-like capabilities but usually also addresses broader integration and cross-functional workflows.
    • Operations intelligence or analytics platforms: These focus on dashboards and analytics. An operations platform typically covers both visibility and the underlying transactional workflows.

    In practice, vendors and organizations may label MES, MOM (Manufacturing Operations Management), or integrated suites as an “operations platform” when they serve as the primary system of record and coordination layer for operational work.

  • hybrid architecture

    Hybrid architecture commonly refers to a system design that combines two or more computing environments within one overall solution. In manufacturing, this usually means some applications, data, or control functions remain on-premises or close to the shop floor, while other functions run in the cloud or in enterprise IT platforms.

    This model is common where plants need low-latency execution, equipment connectivity, or local resiliency, but also want centralized analytics, planning, reporting, or multi-site coordination. For example, an MES or edge layer may manage real-time production events locally, while ERP, data warehousing, or advanced analytics operate in a cloud environment.

    Hybrid architecture should not be confused with a single system that is merely accessible remotely. The term describes how the solution is deployed and integrated across environments, not just where users log in. It also differs from a pure cloud or pure on-premises architecture, where most components run in only one environment.

    In industrial systems, the term often matters in discussions about integration, security boundaries, data flows, validation scope, and system ownership between OT and IT teams. The exact split varies by use case, but the core idea is a deliberate mix of local and centralized platforms working together.

  • industrial internet of things

    The Industrial Internet of Things refers to the use of network-connected industrial assets, sensors, controllers, machines, and software systems to collect, exchange, and use operational data in manufacturing and other industrial environments. In practice, it commonly links shop-floor equipment and OT data with higher-level applications such as MES, ERP, quality, maintenance, or analytics platforms.

    IIoT is commonly used for machine monitoring, condition monitoring, production visibility, traceability support, energy monitoring, and event or alarm reporting. A typical IIoT setup may include sensors, PLCs, gateways, edge devices, communication protocols, and cloud or on-premise applications that turn raw equipment data into usable operational information.

    In manufacturing, IIoT is broader than a single device or software product. It refers to the connected architecture and data flow across assets and systems. It is also distinct from consumer IoT, which usually focuses on household or personal devices rather than industrial reliability, integration, and control requirements. Depending on context, IIoT may support monitoring only, or it may also feed supervisory control, workflow triggers, quality records, or maintenance processes.

    The term is sometimes used alongside concepts such as Industry 4.0, smart manufacturing, and connected operations. Those terms overlap, but IIoT usually refers more specifically to the connected device and data layer that enables those broader initiatives.

  • What data do we need to start building predictive quality models from NCRs?

    At minimum, you need structured NCR data tied to operational context and eventual outcomes. NCR records by themselves are usually not enough, especially if they are mostly free text, inconsistently coded, or disconnected from MES, ERP, PLM, QMS, inspection, or supplier data.

    A practical starting point is not “all plant data.” It is a smaller, traceable dataset where each NCR can be linked to what was built, how it was built, who supplied the material, where in the process it occurred, and what happened next.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Minimum data to start

    • NCR core record: NCR ID, date and time opened, site, line or cell, product or program, part number, revision, serial or lot if applicable, defect category, defect description, severity or priority if used, disposition, and closure status.

    • Process context: operation or routing step, work center, machine or asset ID where relevant, inspection point, shift, operator or team if governance allows, and whether the issue was found in incoming, in-process, final inspection, or field/MRO context.

    • Material and supplier context: supplier ID, purchase order or receipt linkage, batch or lot, material cert reference where applicable, outside processing step, and whether the issue was internal or supplier-originated.

    • Product definition context: part family, assembly relationship, drawing or spec revision, manufacturing plan version, approved work instruction version, and any relevant engineering change state.

    • Inspection and measurement data: characteristic or feature inspected, pass/fail result, measured values where available, gage or method used, sampling context, and whether measurement system variation is understood well enough to trust the signal.

    • Outcome data: scrap, rework, use-as-is, return to supplier, concession or deviation if applicable, time to disposition, time to closure, recurrence, cost estimate if tracked, and downstream effects such as schedule delay or repeated escapes.

    • Corrective action context: containment actions, root cause coding if it exists, CAPA linkage, effectiveness check result, and whether a similar issue had been seen before.

    What makes the data usable for modeling

    The most important requirement is consistent keys and timestamps. If you cannot reliably join NCRs to work orders, travelers, lots, serials, suppliers, revisions, inspections, and dispositions, you will spend more effort resolving data lineage than building a useful model.

    You also need stable definitions. If one site uses defect codes by symptom, another by cause, and a third by disposition, the model may learn coding habits instead of process risk. That is common in brownfield environments.

    For most teams, usable data quality means:

    • Repeatable coding for defect type, location, source, and disposition

    • Enough record volume over time to capture recurrence patterns

    • Known data ownership and change control

    • Traceable joins across QMS, MES, ERP, PLM, and inspection systems

    • Event timestamps accurate enough to reconstruct sequence

    • Validation that missing data is understood, not random guesswork

    What usually matters more than model choice

    In practice, feature quality matters more than whether you start with a complex algorithm. Many programs get better early results from simple, explainable models built on clean operational signals than from advanced machine learning applied to weak NCR data.

    Common predictive features include prior defect frequency by part-operation pair, supplier-specific issue history, process step recurrence, inspection failure rates, rework loops, revision changes, shift or handoff patterns, queue time, and material lot clustering. Whether those features are available depends on your integration quality and traceability maturity.

    What not to rely on alone

    Free-text NCR narratives alone are usually not sufficient. Text can help, especially for triage or clustering, but it often contains inconsistent terminology, abbreviations, copy-forward habits, and missing context. If text is the only source, your first project is often data standardization, not prediction.

    Also be careful with cost fields, root cause fields, and operator identifiers. These are often incomplete, entered late, or influenced by local behavior rather than true process conditions.

    How much history do you need?

    There is no universal threshold. It depends on product mix, event rates, process stability, and how granular the prediction target is. A high-mix, low-volume plant may have years of NCRs and still not have enough repeatability at the individual part-number level. In that case, you may need to model at the part family, process family, supplier, or defect category level instead.

    If the process, routing, coding scheme, or product definition changed materially over time, older data may be only partially useful. More history is not automatically better if the underlying process is no longer comparable.

    Brownfield reality

    Most plants do not have all of this in one system. NCR data may sit in QMS, execution context in MES, product structure in PLM, receipts and suppliers in ERP, and measurements in separate SPC or inspection tools. That is normal.

    You do not need a full platform replacement to begin, and in regulated, long-lifecycle environments that strategy often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability and controlled change. A narrower approach is usually more realistic: define a specific prediction target, map the required records across existing systems, validate the joins, and prove data reliability before scaling.

    Recommended first use case

    Start with one constrained question such as:

    • Which incoming lots are most likely to generate an NCR?

    • Which part-operation combinations are most likely to recur as rework?

    • Which open NCRs are most likely to become high-cost scrap or schedule delay?

    Those use cases usually need less data than a broad “predict all quality issues” initiative and are easier to validate operationally.

    Bottom line

    To start building predictive quality models from NCRs, you need structured NCR records plus traceable links to process, product, supplier, inspection, and outcome data. If those links are weak, the limiting factor is data readiness, not analytics. Start with one prediction target, one governed dataset, and one integration path you can validate under change control.

  • Is SAP an ERP or MES?

    SAP is primarily known as an ERP vendor, but it also provides MES-class products. Whether SAP functions as your ERP, MES, or both depends on which SAP products you run, how they are configured, and how they are integrated into your plant stack.

    What SAP is by default

    The core SAP products used across industry, such as SAP ERP (ECC) and SAP S/4HANA, are Enterprise Resource Planning (ERP) systems. They are designed for:

    In practice, this connects to MES execution control when teams need to turn the answer into repeatable execution habits.

    • Financials, controlling, and cost accounting
    • Procurement and inventory management
    • Sales, distribution, and logistics
    • High-level production planning (MRP, capacity planning)
    • Basic shop floor integration hooks (production orders, confirmations, backflushing)

    In most regulated manufacturing environments, these ERP capabilities are not sufficient to fully replace a dedicated MES for detailed execution, traceability, and operator guidance on the line.

    When SAP is used as an MES

    SAP offers products specifically targeting manufacturing execution:

    • SAP Digital Manufacturing (formerly SAP Digital Manufacturing Cloud), a modern MES-class solution focused on shop floor execution, integration, and analytics.
    • SAP ME (Manufacturing Execution), a traditional MES used in some discrete and high-tech environments.
    • SAP MII (Manufacturing Integration and Intelligence), historically used as a bridge between SAP ERP and shop floor systems and to provide limited MES-type functionality.

    With these products, SAP can act as a MES provider. However, actual MES coverage depends heavily on:

    • How comprehensively the solution is deployed (all lines vs a subset)
    • The depth of integration to PLCs, SCADA, historians, and tooling
    • Configuration of routing, work instructions, data collection, and nonconformance flows
    • Validation status and documented intended use in regulated environments

    Some plants run SAP ERP plus SAP Digital Manufacturing as their primary MES. Others use SAP mainly for order and inventory orchestration, with a different vendor's MES handling line-level execution.

    How SAP ERP and MES typically coexist

    In brownfield, regulated manufacturing, the common pattern is coexistence rather than full replacement:

    • SAP ERP manages planning, production orders, inventory, and financial integration.
    • MES (SAP or non-SAP) manages detailed work execution, operator guidance, electronic batch records, genealogy, and quality data collection at the operation level.

    Reasons many plants do not use SAP ERP alone as an MES include:

    • Execution granularity: ERP is typically too coarse to model all operations, test steps, rework paths, and exceptions encountered at the line.
    • Real-time needs: ERP transaction models and performance are not ideal for very high-frequency, low-latency machine and sensor events.
    • Traceability: Serialized component-level genealogy, test results, and detailed process parameters are usually better handled in MES or historian-type systems.
    • Regulatory expectations: Electronic records, signatures, audit trails, and validated workflows are often easier to implement and maintain in systems meant for line-level execution.

    Regulated and long-lifecycle environment considerations

    In aerospace, defense, medical devices, and similar regulated domains, treating SAP as "the MES" by configuration alone is risky if you do not address:

    • Validation and intended use: You must show that the configured system supports the defined MES functions (e.g., eDHR, eBR, traceability, deviations) with appropriate testing and documentation.
    • Change control and lifecycle: SAP upgrades, notes, and customizations can affect execution logic; every change must go through impact assessment and formal change control.
    • Integration complexity: SAP-based MES still requires robust, validated interfaces to equipment, SCADA, historians, and test systems. Integration debt often limits what is realistic in practice.
    • Downtime risk: Moving more MES functionality into SAP concentrates risk. ERP outages can now stall the shop floor, not just planning and shipping.

    Because of these factors, sweeping programs to "make SAP the single manufacturing system" often under-deliver in regulated, long-lifecycle plants. The qualification burden, downtime constraints, and need to keep legacy equipment and processes running make a phased coexistence model more viable.

    How to answer this question inside your organization

    The correct answer in your environment is not "SAP is ERP" or "SAP is MES," but rather:

    • Which SAP products are deployed? (ECC, S/4HANA, SAP Digital Manufacturing, SAP ME/MII, others)
    • For which MES functions are they actually used? (detailed routing, data collection, genealogy, electronic records, NC/CAPA initiation, etc.)
    • What other systems are involved? (third-party MES, LIMS, QMS, historian, SCADA, test stands)
    • What is validated as the system of record for which data? (orders, batch/lot release, device history, calibration, test results)

    Only by mapping these explicitly can you say, with any precision, whether SAP is acting as ERP, MES, or both in your current stack.