Connect981 – Content Dev

RSC Topic: Manufacturing Execution Systems (MES)

How production work is routed, tracked, and controlled on the shop floor.

  • NPI

    NPI stands for New Product Introduction. In industrial and regulated manufacturing environments, it commonly refers to the structured, cross-functional process used to industrialize, validate, and launch a new or significantly changed product into production.

    NPI typically covers the activities required to move from an approved design concept to stable, repeatable manufacturing. This can include manufacturing process design, process FMEA, control plans, work instructions, equipment selection and validation, pilot builds, capability studies, and definition of inspection and test strategies.

    Scope and typical activities

    Within manufacturing operations, NPI often includes:

    • Translating product requirements into manufacturing and quality requirements
    • Defining and validating the production process, tooling, and fixtures
    • Creating and approving routings, BOMs, and production recipes in MES/ERP
    • Developing control plans, inspection plans, and test methods
    • Applying core quality tools such as APQP, PPAP, FMEA, MSA, and SPC where required
    • Executing pilot runs and collecting data to confirm capability and capacity
    • Releasing manufacturing documentation, digital work instructions, and training

    NPI is usually managed as a formal project, with defined phases, gates, and evidence requirements, especially in automotive, aerospace, medical device, and other regulated industries.

    How NPI shows up in systems

    Operationally, NPI activities interact with multiple systems:

    • PLM / design systems for product definitions, drawings, and changes
    • MES for process definitions, routing, work instructions, and genealogy rules
    • ERP for item masters, BOMs, costing, and planning parameters
    • QMS for risk assessments, validation records, deviations, and approvals

    In many organizations, a product is not considered fully released to volume production until NPI milestones and required approvals are completed and documented across these systems.

    Common confusion

    NPI vs. product development: Product development focuses on defining what the product is (requirements, design, verification). NPI focuses on how the product will be built reliably at scale and integrated into operations.

    NPI vs. APQP: In automotive contexts, NPI is closely related to Advanced Product Quality Planning (APQP). APQP provides a structured quality planning framework and tools, while NPI is the broader industrialization and launch process that may include APQP as one component.

    Relation to the core quality tools

    In sectors aligned with IATF 16949 and similar standards, NPI commonly uses the five core tools: APQP, PPAP, FMEA, MSA, and SPC. For example, process FMEAs and control plans are developed and iterated during NPI, and PPAP submissions are often tied to NPI gateways for new or changed products.

  • Traveler / Router

    Operational meaning

    In manufacturing, a **traveler** (also called a **router**) is a structured production document that accompanies a work order, lot, or batch as it moves through the plant. It defines the required processing path and provides a place to record execution data for each step.

    A traveler/router commonly includes:

    – Identification: work order, part or product ID, revision, lot or batch number
    – Routing definition: ordered list of operations, work centers, or machines
    – Process details: standard operation descriptions, reference to methods, drawings, or recipes
    – Parameters to record: quantities, times, measurements, test results, and defect codes
    – Accountability: operator sign-offs, approvals, and sometimes electronic signatures
    – Status fields: operation completion flags, hold or rework indicators, and scrap recording

    Travelers/routers may be implemented as:

    – **Paper forms** that physically follow the material through each work center
    – **Electronic travelers/routers** inside an MES or ERP that logically track the work order as it is processed

    Use in manufacturing workflows

    In day-to-day operations, a traveler/router is used to:

    – Communicate which operations must be performed, and in what sequence
    – Indicate required resources such as work centers, tools, or fixtures
    – Capture production data at each operation (e.g., start/finish times, yields, test values)
    – Document inspections, quality checks, and holds
    – Provide traceability from finished product back to the operations and conditions under which it was produced

    On the shop floor, operators consult the traveler/router to know what to do next and record what was actually done. Supervisors and planners use the traveler/router to monitor progress and verify that required steps were completed.

    Boundaries and distinctions

    – A traveler/router **defines and records** the process path and execution data for a given work order or batch; it is not the same as:
    – A **work instruction** or **SOP**, which provides detailed step-by-step how-to content
    – A **process route master**, which is the template or master data from which individual travelers/routers are generated
    – A **shipping document**, which covers logistics after manufacturing is complete
    – In many systems, the word **router** emphasizes the planned sequence of operations (routing), while **traveler** emphasizes the physical or logical document that accompanies the work. In practice, the two terms are often used interchangeably.

    Electronic travelers/routers in regulated environments

    In regulated or highly controlled manufacturing (e.g., pharmaceuticals, medical devices, aerospace), travelers/routers are frequently managed in electronic systems such as MES or integrated ERP/MES platforms. In these contexts they commonly:

    – Enforce predefined routings and processing rules
    – Capture electronic records of execution, including operator IDs and timestamps
    – Reference controlled documents, recipes, and specifications
    – Support traceability, deviation recording, and quality review processes

    The core concept remains the same as with paper travelers/routers: a defined routing plus a structured record of how each unit, lot, or batch moved through that routing.

    Common confusion

    – **Routing vs. traveler/router**: “Routing” usually refers to the reusable master definition of the process path for a product. A traveler/router is the instance of that routing (plus record fields) for a specific work order or batch.
    – **Batch record vs. traveler/router**: In some industries, the terms overlap. A batch record often includes additional formulation, processing, and quality data beyond the routing steps. A traveler/router may be one component of, or equivalent to, a batch record depending on the plant’s documentation model.

    Site context application

    On this site, *traveler/router* commonly refers to the production documentation and routing mechanism that links shop-floor operations, MES/ERP master data, and quality records. It is a key object used for execution tracking, traceability, and integration between OT and IT systems in manufacturing environments.

  • process parameters

    What process parameters are

    Process parameters are the defined, measurable settings and conditions under which a manufacturing process is executed. They describe **how** a process is run for a given product, lot, or batch.

    They commonly include:

    – Equipment settings (e.g., temperature setpoints, pressures, speeds, flow rates)
    – Timing values (e.g., dwell times, mixing durations, curing times)
    – Recipe or program values (e.g., additive amounts, agitation profiles, machine offsets)
    – Environmental conditions when controlled as part of the process (e.g., humidity, chamber temperature)
    – Control limits and targets associated with those settings

    In regulated or highly controlled environments, process parameters are usually defined in procedures, master recipes, or control plans and then implemented in control systems (e.g., PLCs, DCS, or MES).

    Use in industrial and manufacturing workflows

    In day-to-day operations, process parameters are:

    – **Configured** in recipes, batch records, or machine programs before production
    – **Loaded and enforced** by control systems (e.g., a PLC using setpoints from an MES order)
    – **Monitored and recorded** during execution as part of electronic batch records, device history records, or production reports
    – **Reviewed and trended** by engineering and quality teams to assess process capability and stability

    Parameters may be treated differently depending on their impact:

    – **Critical process parameters (CPPs)**: Parameters that have a direct, significant impact on product quality or safety.
    – **Non-critical or supporting parameters**: Parameters that influence efficiency or robustness but are not directly linked to a critical quality attribute.

    Boundaries and exclusions

    Process parameters:

    – **Include** the numeric or coded configuration values and conditions that govern a process (e.g., oven temperature set to 180 °C, belt speed 12 m/min, agitation mode “intermittent”).
    – **Include** the actual achieved or measured values when these are captured to verify execution against the intended settings.
    – **Do not include** high-level product or business data such as customer orders, pricing, or inventory levels.
    – **Do not include** unstructured instructions (e.g., free-text work instructions) unless they are converted into specific, parameterized settings.

    They are related to, but distinct from:

    – **Process steps or operations**: The sequence of activities in a routing or recipe.
    – **Material attributes**: Properties of raw materials or intermediates (e.g., viscosity, purity) rather than the machine settings used to process them.

    Common confusion and related terms

    – **Setpoints vs. process parameters**: Setpoints are a subset of process parameters, typically the target values provided to control loops (e.g., temperature setpoint). Process parameters can also include limits, modes, and timing values.
    – **Process conditions vs. process parameters**: Conditions often refer to the actual measured state (e.g., the oven is currently at 177 °C), while parameters include both intended and recorded values that define and document how the process is run.
    – **Specifications vs. process parameters**: Specifications define acceptable ranges for product or process outcomes; process parameters are the controllable inputs adjusted to meet those specifications.

    Site context: process parameters in MES and investigations

    Within manufacturing execution systems (MES) and other shop-floor systems, process parameters commonly refer to the equipment and recipe settings that are:

    – Linked to specific units, lots, or batches
    – Captured with timestamps and equipment/operator context
    – Used in root cause investigations when a deviation or nonconformance occurs

    For example, when investigating an out-of-spec lot, teams may review the recorded process parameters (temperatures, times, speeds) against the defined recipe values and limits to identify process drift, configuration errors, or execution anomalies.

  • routing

    Operational meaning

    In manufacturing and industrial operations, **routing** commonly refers to the defined sequence of steps that a product, batch, or work order follows as it moves through production. A routing specifies:

    – The ordered list of operations (e.g., cut, drill, heat treat, inspect)
    – The work centers, machines, or lines where those operations occur
    – Required resources such as tools, fixtures, or programs
    – Relevant parameters or references (e.g., process instructions, NC programs, recipes)

    Routings are usually managed in ERP, MES, or planning systems and are used to plan capacity, schedule work, and ensure that production follows an approved process path.

    Use in manufacturing systems

    In integrated ERP–MES environments, routings are often:

    – **Master data** that define the standard process path for a part number or product family
    – **Linked to work orders** to generate shop floor job steps and traveler information
    – **Referenced by MES** to drive operator instructions, sequence enforcement, and data collection
    – **Used for traceability**, by associating actual production records with the routing steps executed

    In regulated or high‑risk industries, routings are typically versioned, controlled documents aligned with approved process plans and quality records.

    Boundaries and exclusions

    Within this site context, routing:

    – **Includes**: the logical and sometimes physical path of a product through defined manufacturing operations, including operation sequence and associated resources.
    – **Excludes**: general network routing (IP routing, packet routing) or logistics routing (shipping routes, transport optimization), except where briefly mentioned for contrast.

    When IT or OT network design is discussed, “routing” in that context usually means IP traffic routing, which is distinct from manufacturing process routing.

    Common confusion and related terms

    Routing is often discussed alongside:

    – **Bill of material (BOM)** – defines *what* materials go into a product; routing defines *how* and *where* it is processed.
    – **Process plan / process route** – in many plants, used interchangeably with routing; sometimes process plan includes more detailed parameters and controls.
    – **Workflow** – a broader term that may include approvals, documentation steps, and electronic signatures; routing is usually focused on physical production steps.

    Care is needed to distinguish manufacturing routing (process sequence) from **network routing**, which concerns directing data packets between devices and networks.

    Application in MES alerts and scrap prevention (site context)

    In MES, routing information is frequently used to:

    – Enforce **operation sequencing**, preventing operators from skipping or reordering critical steps
    – Drive **contextual alerts** when work deviates from the approved routing (e.g., attempting inspection before required heat treat)
    – Tie **specification limits and controls** to specific routing steps (e.g., torque checks at a defined operation)
    – Support **configuration and revision control**, ensuring the correct routing version is applied to the correct part and work order

    In aerospace and other regulated industries, misrouting or executing the wrong routing revision is a common precursor to scrap, rework, or nonconformance. MES alerts that reference the active routing and its required sequence are therefore used to highlight deviations before irreversible operations are performed.

  • Implementation plan

    An implementation plan is a structured description of how a specific project, system, or process change will be executed, tracked, and controlled. It translates agreed objectives and requirements into concrete tasks, timelines, responsibilities, and resources.

    Typical contents of an implementation plan

    In industrial and regulated manufacturing environments, an implementation plan commonly includes:

    • Scope and objectives: What is being implemented (for example, a new MES module, quality workflow, or work-instruction system) and what outcomes are expected.
    • Work breakdown and tasks: Discrete activities such as configuration, integration, validation, data migration, training, and cutover.
    • Roles and responsibilities: Named owners for each task, including operations, quality, IT/OT, engineering, and suppliers where applicable.
    • Schedule and milestones: Start and end dates, dependencies, and key checkpoints such as pilot, go-live, and stabilization.
    • Resources and budget: People, systems, external partners, and any required tools or infrastructure.
    • Risk and issue handling: Identified risks, mitigations, and escalation paths, especially for production and compliance impacts.
    • Change management: Communication, training, and support activities for operators, supervisors, and other users.
    • Validation and acceptance steps: Testing, documentation, and signoffs needed for quality and regulatory requirements.
    • Measurement and follow-up: How success will be monitored (for example, impact on OEE, NCR rates, or lead time) and how adjustments will be managed.

    Use in manufacturing and regulated environments

    Implementation plans are commonly used for:

    • Deploying or upgrading MES, ERP, QMS, PLM, or data-integration solutions.
    • Rolling out new standard work, digital work instructions, or inspection workflows.
    • Introducing new quality or compliance processes such as electronic DHR or traceability enhancements.
    • Process-improvement initiatives such as Lean or continuous-improvement projects that affect production methods.

    In regulated sectors, the implementation plan often aligns with internal procedures and quality-system requirements and may be referenced as objective evidence during internal or external audits.

    What an implementation plan is not

    • It is not the business case. The business case explains why a change is pursued; the implementation plan explains how it will be executed.
    • It is not the solution design. Functional and technical designs describe what will be built or configured; the implementation plan describes the steps to deploy that design.
    • It is not ongoing operations procedures. Standard operating procedures govern steady-state work; the implementation plan governs the transition to that new steady state.

    Common confusion

    • Project plan vs. implementation plan: In many organizations the terms are used interchangeably. Where they are distinguished, the project plan covers the full lifecycle (including strategy and post-go-live optimization), while the implementation plan focuses more narrowly on execution and cutover activities.
    • Roadmap vs. implementation plan: A roadmap is typically high level and long term (multiple initiatives and releases). An implementation plan is detailed and near term, specific to one release, site, or project.

  • System of Execution

    A system of execution is software used to direct, control, and record operational work while that work is being performed. In manufacturing, it commonly refers to systems that manage shop-floor execution, guide operators, capture production events, and maintain the current state of work in process.

    A system of execution often sits between planning or record systems, such as ERP and PLM, and equipment or OT systems on the production floor. It may dispatch jobs, enforce routings, present work instructions, collect inspection results, record material consumption, capture timestamps, and route exceptions or approvals. A manufacturing execution system, digital traveler platform, electronic batch record system, or electronic DHR workflow can function as a system of execution depending on the environment.

    The term should not be confused with a system of record. A system of record is the authoritative source for a defined set of data, while a system of execution is focused on controlling and documenting the work process as it occurs. A system of execution may create or update records, but its primary role is operational execution rather than long-term master data ownership or reporting alone.

  • Machine Connectivity

    Machine connectivity is the ability of industrial equipment to exchange usable data with other systems, such as PLCs, SCADA, MES, quality systems, historians, or ERP platforms. In manufacturing, it commonly refers to the hardware, network, protocol, and data-model arrangements that let machines send and receive production, status, process, and quality data.

    Machine connectivity may include direct connections to controllers, adapters or gateways for legacy equipment, industrial protocols such as OPC UA or MTConnect, and message-based approaches such as MQTT. The goal is not only to connect a machine to a network, but to make its data available in a reliable and interpretable form for operations, traceability, monitoring, and integration workflows.

    The term should not be confused with machine monitoring alone. Monitoring is one use of machine connectivity. Connectivity can also support work-order execution, parameter download, inspection data capture, alarm handling, maintenance signals, and production reporting. It also does not imply that a machine is fully automated or that all connected data is automatically valid for regulated records without appropriate controls.

  • Is MES the same as SAP?

    No. MES and SAP are not the same, and they solve different layers of the manufacturing problem. In regulated, long-lifecycle environments, they usually coexist and integrate rather than replace each other.

    What SAP typically does

    When people say “SAP” in manufacturing, they almost always mean SAP ERP (or SAP S/4HANA). At a high level, SAP usually covers:

    • Enterprise resource planning: finance, controlling, procurement, inventory, and logistics.
    • High-level production planning and scheduling (MRP, capacity planning, order creation).
    • Order management: sales orders, purchase orders, delivery notes, invoicing.
    • Master data: materials, BOMs, routings (sometimes shared with PLM or other systems).
    • Some quality and maintenance functions, depending on which SAP modules are implemented.

    SAP is strong at transactional integrity, financial traceability, and enterprise-wide planning. It is not designed as a near-real-time shop-floor control system.

    What MES typically does

    Manufacturing Execution Systems (MES) focus on detailed execution and tracking on the shop floor, for example:

    • Dispatching work to specific lines, cells, or machines based on the production schedule.
    • Enforcing workflows, operation sequences, and electronic work instructions.
    • Collecting production data and events in near-real time (start/stop, scrap, rework, machine states).
    • Capturing genealogy and traceability (which material, which lot, which serial numbers, who did what, when, and on which resource).
    • Managing in-process quality checks, electronic signatures, and deviations.
    • Supporting regulatory records (e.g., batch records, device history records) subject to validation and proper configuration.

    MES is closest to the physical process. It sits between planning systems (like SAP ERP) and the automation layer (machines, PLCs, SCADA, DCS).

    How MES and SAP usually work together

    In most brownfield plants, SAP and MES are integrated but distinct:

    • SAP creates and manages production orders, planned orders, and material requirements.
    • MES receives those orders, sequences them locally, and executes them on the shop floor.
    • MES sends back confirmations: quantities produced, scrap, downtime, and sometimes quality results.
    • SAP updates inventory, costs, and order status based on feedback from MES.

    The exact division of responsibilities depends heavily on how each site has configured SAP, MES, PLM, and automation systems. In some plants, MES does more (deep traceability, e-signatures, electronic batch records). In others, SAP takes on more of the routing, quality, or maintenance functions.

    What about SAP MES or SAP MII?

    SAP also offers MES-like products (e.g., SAP Digital Manufacturing, legacy SAP ME/MII). These are still not “SAP ERP” themselves. Instead, they are SAP’s MES layer that integrates tightly with SAP ERP/S/4HANA. Functionally, they compete with other MES vendors, but the architectural principle is similar:

    • SAP ERP/S/4HANA: enterprise planning and transactions.
    • SAP MES (ME/MII/SAP Digital Manufacturing): shop-floor execution and data collection.

    Using SAP’s own MES does not eliminate the need to design and validate integrations or to clarify which layer is the system of record for which type of data.

    Why MES and SAP are not interchangeable

    In regulated, long-lifecycle operations, trying to use SAP ERP alone as an MES, or vice versa, usually runs into hard limits:

    • Granularity of control: SAP ERP is not optimized for second-by-second or unit-by-unit execution logic and machine interactions.
    • Operator usability: ERP transaction screens are typically not designed for fast, high-volume operator interactions in a noisy, time-critical environment.
    • Regulatory records: MES is often where detailed as-built/as-manufactured records, operator signatures, and in-process checks live. Forcing this into ERP can create validation and usability problems.
    • Integration with automation: MES and SCADA/PLC layers are usually closer to real-time control and data acquisition than ERP.

    Where companies have tried to collapse MES into SAP ERP, they frequently encounter high customization, brittle integrations, and validation burdens that make changes slow and risky. The reverse (attempting to replace ERP with MES) usually fails outright in finance, procurement, and supply chain domains.

    Brownfield realities and replacement risks

    In most established plants:

    • Legacy MES, custom shop-floor apps, and SAP have grown together over many years.
    • There are numerous point-to-point integrations, manual workarounds, and plant-specific configurations.
    • Equipment lifecycles are long, and many machines were qualified or validated with specific MES/ERP behaviors in place.

    Attempting a full replacement (for example, “we will remove MES and run everything in SAP” or “we will rip out SAP and run everything in a new MES”) carries significant risks:

    • Requalification and revalidation of processes, especially where electronic records and signatures are involved.
    • Extended downtime risks during cutover, which many aerospace and medical sites cannot tolerate.
    • Complex data migration and reconciliation for genealogy, quality records, and cost history.
    • Loss of traceability or audit trails if not managed carefully, with strict change control.

    Most high-consequence environments move toward clearer boundaries and better integration between SAP and MES rather than wholesale replacement.

    Key questions to clarify at your site

    To understand how MES and SAP relate in your environment, it is useful to ask:

    • Which system is the system of record for production orders, routings, and BOMs?
    • Where is as-built/as-manufactured data and genealogy stored and queried from?
    • Which layer operators primarily use during execution (and why)?
    • How are electronic signatures, deviations, and quality holds handled across MES and SAP?
    • What has already been validated, and what would need revalidation if roles shift between systems?

    The answers are site-specific and driven by existing configurations, validations, and integration maturity. There is no single “correct” split, but conflating MES with SAP typically leads to misunderstandings about scope, cost, and risk.