Connect981 – Content Dev

Glossary Category: Operations and Quality Signals

  • PMI

    In industrial and manufacturing contexts, PMI most commonly refers to Product and Manufacturing Information embedded in a 3D CAD model. It captures the information needed to manufacture and inspect a part directly within the model instead of on a separate 2D drawing.

    What PMI includes

    PMI typically covers the information required to define, produce and verify a part, such as:

    • Geometric dimensions and tolerances (GD&T)
    • Datum features and feature control frames
    • Surface finish and surface texture requirements
    • Material specifications and treatments (e.g., heat treat, coating notes)
    • Assembly instructions and fit requirements
    • Weld symbols and other fabrication symbols
    • Inspection requirements and key characteristics
    • Process notes relevant to manufacturing and quality

    In a model-based definition (MBD) workflow, this information is attached directly to 3D geometry, allowing downstream systems to interpret and extract characteristics digitally.

    Operational role in manufacturing systems

    In regulated and high-precision manufacturing, PMI is used to:

    • Drive automatic or semi-automatic extraction of characteristics for inspection planning, including first article inspection (FAI) per standards such as AS9102
    • Link PLM models to MES, QMS and ERP so that specifications, tolerances and inspection points remain consistent across systems
    • Support digital work instructions and visualizations that reference the 3D model rather than static 2D drawings
    • Enable CMM programming, CAM toolpath generation and other automated or assisted NC programming directly from the annotated 3D model
    • Provide traceable, version-controlled product definition as part of a digital thread

    PMI content quality, structure and adherence to internal standards strongly affect whether downstream tools can consume the data reliably. Poorly structured or incomplete PMI often leads to manual rework, misinterpretation or mixed use of 2D drawings and 3D models.

    Common confusion

    • Product and Manufacturing Information vs. Project Management Institute: Outside of CAD and manufacturing, PMI may refer to the Project Management Institute, a professional association. In engineering, CAD, PLM and MES discussions, PMI almost always means Product and Manufacturing Information.
    • PMI vs. MBD: Model-based definition (MBD) is an approach where the 3D model is the authoritative product definition. PMI is a key enabler of MBD, but MBD also includes practices, standards, workflows and system integrations beyond the annotations themselves.
    • PMI vs. 2D drawing annotations: Traditional drawing notes and symbols serve a similar purpose, but PMI is natively associated with 3D geometry and intended for digital consumption by downstream systems.

    Relation to FAI and aerospace workflows

    In aerospace and other regulated industries, PMI is increasingly used to support digital FAI processes. Instead of manually ballooning 2D drawings and typing characteristics into FAI forms, software can read PMI from the 3D model, identify characteristics, and map them to inspection results and quality records. This can improve traceability and alignment between PLM, MES and QMS, while still operating within existing standards such as AS9102.

  • Model-Based Definition (MBD)

    Model-Based Definition (MBD) is a product definition approach in which a 3D CAD model, including embedded annotations and product manufacturing information (PMI), serves as the primary and often sole authority for describing a part or assembly. In an MBD approach, dimensions, tolerances, surface finishes, material specifications, and other requirements are attached directly to the 3D model rather than being maintained primarily on separate 2D drawings.

    Key characteristics

    • 3D model as the authority: The 3D CAD model, with its PMI, is treated as the master reference for design, manufacturing, and quality, often replacing traditional 2D drawings.
    • Embedded product manufacturing information (PMI): Geometric dimensions and tolerances (GD&T), notes, callouts, and other attributes are applied directly within the model environment.
    • Digital interoperability: The model is intended to be consumed downstream by CAM, CMM, MES, PLM, and other systems to support NC programming, inspection planning, and automated feature extraction.
    • Configuration and change control: MBD data typically lives under formal revision control in PDM/PLM systems, similar to drawings, and must align with document control and quality procedures.

    Use in industrial and regulated environments

    In manufacturing operations, especially in aerospace, defense, and other regulated sectors, MBD commonly appears as:

    • Design authority packages: Customers or engineering groups releasing 3D models with embedded PMI as the official definition delivered to suppliers or internal manufacturing.
    • Inputs to MES and digital work instructions: MBD models referenced in digital travelers, operation instructions, or visual work instruction tools to show model views and callouts at each operation.
    • Inputs to inspection and FAI: MBD used to drive ballooning, characteristic extraction, and CMM programs for First Article Inspection and ongoing inspection plans.
    • Source for manufacturing automation: CAM, toolpath generation, and coordinate measuring routines built directly from the model to reduce re-interpretation of requirements.

    What MBD includes and excludes

    • Includes the 3D geometry and all necessary product definition details (dimensions, tolerances, GD&T, notes, references to standards, and other PMI) required to manufacture and inspect the part.
    • May include links to related specifications, materials, and process requirements managed in PLM, QMS, or document control systems.
    • Does not automatically include full process plans, routings, or work instructions, although MBD is often referenced by these artifacts.
    • Does not replace quality records, FAI reports, DHRs, or other compliance documents, but can serve as a primary data source for generating them.

    Operational considerations

    When MBD is used on the shop floor and in quality systems, typical considerations include:

    • Access and visualization: Ensuring operators, inspectors, and suppliers can view and interrogate 3D models and PMI with appropriate tools and permissions.
    • Version governance: Aligning MBD revisions with ERP/MES routings, work orders, inspection plans, and FAI baselines under controlled change processes.
    • Integration with other systems: Mapping model features and characteristics into MES, PLM, QMS, and CMM software without manual re-entry where possible.
    • Training and interpretation: Ensuring personnel understand 3D PMI, GD&T usage, and how model-based requirements translate into measurement and process controls.

    Common confusion

    • Model-Based Definition (MBD) vs Model-Based Enterprise (MBE): MBD focuses on using the 3D model as the formal product definition. Model-Based Enterprise refers to a broader organizational approach where model-based data flows through design, manufacturing, quality, and support processes.
    • MBD vs 3D CAD models without PMI: A simple 3D model used only for visualization or rough geometry is not typically considered MBD. MBD implies that the model carries the authoritative dimensions, tolerances, and other PMI required to build and verify the part.
    • MBD vs digital drawings: PDF or electronic 2D drawings are digital but are still drawing-centric. MBD shifts the source of truth to the 3D model itself rather than to a 2D representation.

  • legacy systems

    Legacy systems commonly refers to older operational or IT systems that remain in use because they support critical business or manufacturing processes, even though they may be outdated, hard to maintain, or difficult to integrate with newer technologies.

    In industrial and regulated manufacturing environments, legacy systems can include:

    • Older MES, SCADA, DCS, LIMS, or historian platforms that are still the primary source of production or quality data
    • Obsolete ERP, MRP, or scheduling systems that have been heavily customized
    • Control systems and PLCs running on unsupported operating systems or proprietary protocols
    • Standalone applications used for batch records, equipment logs, or test data that were never designed for integration

    Key characteristics of legacy systems

    Legacy systems in manufacturing typically show some of the following traits:

    • Age and technology stack: Built on older platforms, programming languages, or databases that are no longer mainstream.
    • Limited vendor support: The original supplier no longer fully supports upgrades, patches, or security fixes.
    • Integration constraints: Interfaces are file-based, point-to-point, or proprietary, making real-time data sharing difficult.
    • Configuration lock-in: Customizations are poorly documented, making changes risky for validated or qualified processes.
    • Security exposure: Systems may not support modern authentication, encryption, or secure network architectures.

    Operational context in regulated environments

    Legacy systems often remain in place because they are deeply embedded in qualified or validated processes, or because replacing them would disrupt production. In practice, manufacturers may:

    • Place legacy systems in segmented network zones and apply compensating cybersecurity controls
    • Use adapters, gateways, or middleware to extract data for MES, ERP, or reporting
    • Rely on procedural controls, change control, and documentation to manage known limitations
    • Treat them as in-scope assets for audits, data integrity reviews, and supplier assessments

    From a supplier or partner perspective, legacy systems can affect how security requirements, data handling expectations, and integration approaches are interpreted and right-sized, especially for smaller organizations.

    Common confusion

    • Legacy system vs. obsolete system: A legacy system is still in use and often business-critical. An obsolete system is fully retired and no longer part of active operations.
    • Legacy system vs. technical debt: Technical debt is a broader concept about design trade-offs and deferred work. A legacy system is a specific instance of older technology, which may be one source of technical debt.

    The term does not automatically imply noncompliance or insecurity. It indicates age and constraints, not the absence of controls or governance.

  • Aggregation Level

    Aggregation level commonly refers to the degree of detail or summarization applied to data when it is collected, stored, analyzed, or reported. In industrial and manufacturing environments, it describes how information is grouped, such as per unit, batch, work order, shift, production line, plant, or enterprise.

    Core meaning

    An aggregation level is a defined layer of granularity at which data points are combined into a single record or metric. It determines:

    • What each record represents (for example, one sensor reading vs. one batch)
    • How many raw events are rolled up into that record
    • Which questions can be answered from the dataset or report

    Common aggregation levels in manufacturing and regulated operations include, for example:

    • Event or sample level: individual sensor readings, operator entries, or quality measurements
    • Unit or device level: all records tied to a specific serial number or equipment item
    • Batch or lot level: data grouped by batch ID, lot number, or work order
    • Shift or time period level: data grouped by shift, hour, day, week, or month
    • Line, area, or site level: data summarized by production line, cell, area, or plant
    • Enterprise level: consolidated data across multiple plants or business units

    How aggregation level is used in operations

    In OT, MES, ERP, and quality systems, aggregation level influences how information is:

    • Stored: time-series historians may keep fine-grained data (per second), while data warehouses store hourly or daily summaries.
    • Displayed: dashboards may present OEE per line per shift, while traceability tools retain unit- or batch-level records.
    • Integrated: interfaces between MES and ERP often define alignment by order, batch, or period-level aggregates.
    • Used for compliance: regulated environments may require specific aggregation levels (for example, batch-level records for release decisions) while still retaining underlying detailed data for investigations.

    Choosing an aggregation level is typically a trade-off between data volume, performance, and the need for detailed traceability or root-cause analysis.

    What aggregation level does not mean

    • It is not the calculation method itself (for example, average vs. maximum) but the grouping to which that method is applied.
    • It is not the data model or schema, although aggregation levels are usually embedded in those designs.
    • It is not limited to time; it can be based on product, batch, equipment, or organization hierarchy.

    Common confusion

    • Aggregation level vs. aggregation function: The level describes the grouping (per batch, per day). The function describes how values are combined within that group (sum, average, minimum, count).
    • Aggregation level vs. data resolution: Resolution usually refers to how frequently data is sampled (for example, every second). Aggregation level describes how those samples are grouped for storage or reporting (for example, one value per minute or per batch).

    Context in manufacturing systems

    Standards and reference models for manufacturing operations and integration often assume multiple aggregation levels across system layers, such as detailed event data at equipment level and aggregated production data at site or enterprise level. When designing KPIs, reports, or interfaces between OT, MES, and ERP, the required aggregation levels need to be explicitly defined to support traceability, quality investigations, and management reporting.

  • API Contract

    An API contract is a formal, versioned specification that defines how two or more software systems interact through an application programming interface (API). It describes the structure of requests and responses, supported operations, data types, error handling, and any rules or constraints that callers must follow.

    Key elements of an API contract

    In industrial and manufacturing environments, an API contract typically includes:

    • Endpoints and operations: The URLs or topics exposed, and what actions (such as create, read, update, delete) are available.
    • Data models: The fields, formats, units, and allowed values for request and response payloads, often including identifiers such as order IDs, batch IDs, or equipment IDs.
    • Protocols and formats: The transport and encoding used, such as HTTP/HTTPS with JSON, XML, or message-bus formats.
    • Authentication and authorization expectations: How clients identify themselves and what access rules apply.
    • Error handling: Error codes, message formats, and how exceptional conditions are reported.
    • Versioning rules: How changes are introduced and how backward compatibility is managed.

    Operational meaning in manufacturing

    In manufacturing, an API contract commonly refers to the defined interface between:

    • MES and ERP systems for exchanging production orders, material movements, and confirmations.
    • Quality systems and shop floor systems for sending results, nonconformances, and electronic records.
    • OT data platforms and analytics or reporting tools for process, performance, and traceability data.

    The contract provides a reference for engineering, validation, and support teams so that integrations are implemented and maintained in a consistent, testable way. In regulated environments, the documented contract often supports change control, impact assessment, and traceability between system requirements and implemented integrations.

    How API contracts are documented

    API contracts may be captured using:

    • Machine-readable specifications, such as OpenAPI/Swagger or similar schema definitions.
    • Human-readable interface control documents, sequence diagrams, or message dictionaries.
    • Configuration-controlled documents managed under document and version governance processes.

    Regardless of format, the contract is typically controlled under version management so that changes to fields, behavior, or security requirements are reviewed, approved, and communicated.

    Common confusion

    • API contract vs. API implementation: The contract describes what an API must do and how it behaves externally. The implementation is the underlying code and infrastructure that fulfill the contract.
    • API contract vs. service-level agreement (SLA): The API contract defines functional and technical behavior. An SLA describes performance and availability targets, which are related but not the same.

    Relation to integration and compliance

    For data integration and interoperability across MES, ERP, LIMS, and other systems, API contracts provide a clear boundary of responsibility between system owners. In regulated manufacturing, well-defined contracts also support repeatable testing of interfaces, impact analysis when changing connected systems, and consistent handling of production and quality data across the system landscape.

  • Middleware

    Middleware is software that sits between different applications, services, or devices and manages how they communicate with each other. In industrial and manufacturing environments, it commonly refers to the layer that connects shop-floor systems (such as PLCs, SCADA, and MES) with higher-level IT systems (such as ERP, LIMS, or quality systems).

    Core characteristics

    Middleware typically:

    • Enables data exchange between systems that were not originally designed to work together
    • Performs protocol conversion (for example, from fieldbus or OPC UA to HTTP/REST or message queues)
    • Transforms and maps data formats and structures between sending and receiving systems
    • Provides routing, queuing, and buffering of messages or transactions
    • May enforce basic security controls such as authentication, authorization, and encryption for system-to-system traffic

    Middleware is not a user-facing application and does not usually provide the primary business logic of production, planning, or quality processes. Instead, it supports those systems by handling integration and communication tasks.

    Common types of middleware in manufacturing

    • Message-oriented middleware (MOM): Uses queues, topics, or buses to send and receive messages between systems asynchronously. Examples include industrial message brokers that handle telemetry from machines to analytics platforms.
    • Integration / enterprise service bus (ESB): Provides a centralized integration layer with routing, orchestration, and transformation capabilities, often used between MES, ERP, WMS, and quality systems.
    • Database middleware: Manages access to one or more databases, connection pooling, and sometimes data virtualization, so applications do not connect directly to production databases.
    • API gateways and service middleware: Manage access to REST or SOAP APIs, including rate limiting, authentication, and request/response transformation.
    • OT/IT gateway middleware: Connects operational technology (for example, PLCs, DCS, historians) with IT applications, often using industrial protocols on one side and standard IT protocols on the other.

    Operational role in regulated environments

    In regulated manufacturing, middleware often plays a role in:

    • Collecting machine or process data for electronic batch records, genealogy, and traceability
    • Coordinating workflows between MES, laboratory systems, quality management systems, and ERP
    • Enforcing consistent data models and reference data across systems
    • Managing audit-relevant event streams, such as status changes, alarms, and electronic signatures, for downstream storage and review

    Middleware itself is typically part of the infrastructure layer, but its configuration and operation can affect data integrity, audit trails, and system interoperability.

    Common confusion

    • Middleware vs. MES/ERP: MES and ERP are end-user applications that implement business and production processes. Middleware connects these systems to each other or to equipment but does not usually define the process logic itself.
    • Middleware vs. gateway device: A physical gateway device may include middleware, but the term “middleware” refers to the software function, not the hardware.
    • Middleware vs. custom integration scripts: Point-to-point scripts can act like very simple middleware, but the term usually implies a more general, reusable integration or messaging layer.

  • Why do digital transformation projects fail in industrial SMEs?

    In industrial small and medium-sized enterprises (SMEs), digital transformation projects often fail not because of individual technologies, but because of organizational, process, and integration issues specific to manufacturing and regulated environments.

    Typical reasons for failure in industrial SMEs

    • Unclear business problem and success criteria
      Projects start from a desire to “go digital” or “implement Industry 4.0” without a tightly defined problem statement, target metrics (such as OEE, NPT, scrap, or lead time), or a clear link to quality, compliance, or capacity goals.
    • Lack of executive sponsorship and ownership
      No accountable owner with authority across production, quality, engineering, IT, and finance. Initiatives become “side projects” that stall when priorities shift or budgets tighten.
    • Over-scoping and under-resourcing
      Trying to replace or modernize everything at once (ERP, MES, quality, maintenance, analytics) with limited internal capacity, especially in SMEs that already operate with lean staffing.
    • Technology-first rather than process-first approach
      Selecting tools (MES, IIoT platform, analytics, cloud) before mapping current processes, constraints, and regulatory requirements. This leads to systems that do not match real shop-floor workflows.
    • Poor integration with existing OT/IT landscape
      Underestimating the difficulty of connecting legacy equipment, homegrown systems, paper processes, and core systems such as ERP, LIMS, or QMS. Data ends up siloed, duplicated, or unreliable.
    • Insufficient attention to data quality and governance
      Collecting more data without defining data ownership, version control, context (such as batch, product, or equipment), and rules for change control. This is especially critical in regulated environments where records must be complete and traceable.
    • Ignoring shop-floor and quality-user needs
      Systems are designed around management dashboards instead of operators, supervisors, and quality personnel. If new workflows slow people down, users revert to spreadsheets and paper, undermining adoption.
    • Underestimating change management and training
      Limited time allocated for training, coaching, and updating procedures or work instructions. New digital workflows conflict with existing standard work, audits, or approvals, creating confusion.
    • Misalignment with regulatory and quality requirements
      Digital tools are introduced without validating that they support required records, signatures, traceability, or auditability. This can lead to parallel paper systems or rework to satisfy inspections.
    • Vendor lock-in or misfit solutions
      Choosing tools that are too complex, too generic, or overly customized for the SME’s scale. High configuration and maintenance burdens cause projects to stall after pilots.
    • Lack of staged roadmap
      Absence of a phased plan that delivers early, measurable wins (for example, digital work instructions, basic OEE, or electronic logbooks) before expanding into more advanced analytics or automation.

    How this shows up in regulated manufacturing

    In regulated industrial SMEs, failures often appear as:

    • Digital systems that cannot reliably support batch records, device history records, or traceability, so paper backups continue indefinitely.
    • MES or data-collection pilots that never progress past a single line or work cell, often because validation, change control, or integration with ERP and QMS was not planned from the start.
    • Disconnected analytics projects that generate dashboards but are not trusted for decisions during audits or customer reviews.

    Successful SMEs usually start small, focus on a few high-value use cases (such as improved shop-floor visibility, reduced manual paperwork, or better nonconformance handling), and build a practical roadmap that aligns technology choices with process requirements, integration constraints, and quality/compliance needs.

  • Object of Measurement

    An object of measurement is the specific item, process, entity, or condition that a measurement activity is intended to quantify or qualify. It defines what is being measured so that data collection is specific, consistent, and repeatable.

    In industrial and manufacturing environments, the object of measurement can be physical (for example, a batch of material, a machined part, a vessel, or a production line) or conceptual (for example, a process parameter, a quality characteristic, a downtime event, or a workflow step). Identifying the object of measurement is a prerequisite for defining metrics, setting specifications, configuring instruments, and structuring data in IT/OT systems.

    Typical objects of measurement in manufacturing

    Examples include:

    • Products and materials: individual units, lots/batches, raw materials, intermediates, or finished goods measured for dimensions, weight, potency, or other properties.
    • Processes and operations: a mixing operation, an assembly step, a curing cycle, or a cleaning procedure measured for time, temperature, pressure, or sequence adherence.
    • Equipment and assets: machines, tools, lines, utilities, and sensors measured for status, availability, speed, energy use, or calibration state.
    • Quality characteristics: defect rates, surface finish, concentration, contamination level, or label accuracy measured against defined specifications or limits.
    • Performance measures: throughput, cycle time, changeover duration, scrap rate, or OEE components (availability, performance, quality).

    Operational use in systems and workflows

    In regulated and data-driven operations, the object of measurement is used to:

    • Define data structures in MES, LIMS, SCADA, historians, and ERP (for example, linking measurements to a specific batch, work order, or equipment asset).
    • Configure instruments and forms (for example, specifying that a gauge measures the diameter of a particular feature on a part, not the entire part).
    • Support traceability by clearly associating results with the correct product, process step, or time period.
    • Enable analysis such as SPC charts, capability studies, OEE dashboards, and deviation investigations, where data must be grouped by a well-defined object.

    Common confusion

    • Object of measurement vs. measurement unit: the object of measurement is what is being measured (for example, batch temperature). The measurement unit is how the result is expressed (for example, degrees Celsius).
    • Object of measurement vs. metric or KPI: the object of measurement is the underlying entity or characteristic (for example, line speed). A metric or KPI is the calculated indicator based on measurements (for example, average line speed per shift, or performance percentage in OEE).
    • Object of measurement vs. method of measurement: the object of measurement is the target of the measurement, while the method of measurement describes how the measurement is carried out (for example, instrument type, sampling plan, and procedure).

    Relation to standards and data models

    In structured data models and manufacturing standards, the object of measurement is often represented as the entity to which a measurement or result record is attached. For example, a standard may define measurements as linked to equipment, material lots, operations, or resources, all of which act as objects of measurement. Clear definition of the object of measurement supports consistent data integration and interoperability across OT and IT systems.

  • data sources

    Data sources are the systems, devices, repositories, or files from which data is obtained for use in applications, analytics, reporting, or integration workflows. In industrial and manufacturing environments, data sources commonly include shop floor equipment, control systems, business systems, and manually maintained records.

    What data sources typically include

    In regulated and industrial operations, data sources often refer to:

    • Operational technology (OT) systems such as PLCs, SCADA, DCS, historians, and machine controllers that generate process and equipment data.
    • Manufacturing IT systems such as MES, LIMS, QMS, WMS, CMMS, and production scheduling tools that generate and store transactional and event data.
    • Enterprise IT systems such as ERP, CRM, and financial systems that provide order, customer, material, and cost data.
    • Files and databases including CSV/Excel files, SQL/NoSQL databases, data warehouses, and data lakes used to persist and consolidate information.
    • Manual and semi-manual records such as electronic logbooks, digital forms, or structured spreadsheets maintained by operators, engineers, or quality staff.

    A data source is defined by both where the data resides or originates (for example, a specific MES instance) and how it is accessed (for example, REST API, OPC UA server, database connection, or file drop).

    How data sources are used operationally

    In integrated manufacturing environments, data sources are identified, cataloged, and connected so that information can be reused consistently across functions. Typical uses include:

    • Feeding KPIs and dashboards such as OEE, NPT, or ISO 22400 indicators from defined, traceable origins (for example, a specific historian tag set or MES production records).
    • Supporting regulatory and quality records by tying reports and batch documentation back to original source systems and timestamps.
    • Enabling MES/ERP integration by mapping master data and transactional data from clearly defined systems of record.
    • Driving operations intelligence and analytics, where models and reports are explicitly linked to named, version-controlled data sources.

    In validated or audited settings, it is common practice to maintain a data source catalog that documents each source, its owner, data structures, access method, and intended use so that metrics, reports, and decisions can be traced back to origin.

    Relation to KPIs and standards

    When defining KPIs, including those based on frameworks like ISO 22400 and locally defined indicators, each metric should reference its underlying data sources. For example, a performance KPI might specify that production quantity is taken from a particular MES table, while machine runtime is taken from a specific historian tag set. Clear linkage between KPIs and their data sources supports consistency, reproducibility, and review in regulated environments.

    What data sources are not

    It is useful to distinguish data sources from related concepts:

    • Data sources are not the same as data models. A data model describes how data is structured and related; a data source is where the data is actually obtained.
    • Data sources are not necessarily systems of record. A system of record is the authoritative place for a given data element, while a data source may be a copy, aggregation, or transformed view.
    • Data sources are not integration tools. Middleware, ETL tools, and message brokers move data between sources and targets but are not, by themselves, the originating sources of the data.

    Common confusion

    The term “data source” is sometimes used interchangeably with:

    • Data set, which usually refers to a specific collection of data extracted from one or more sources at a given time.
    • Connector or interface, which refers to the technical mechanism (for example, an OPC client, JDBC driver, or API client) used to access a data source, rather than the source itself.

    In manufacturing and compliance discussions, using “data source” to mean the actual originating system, repository, or device helps maintain clear traceability and accountability.

  • Functional Domain

    A functional domain is a clearly defined area of business or operational responsibility that groups together related processes, roles, data, and systems. In industrial and manufacturing environments, functional domains are often used to organize work, design system architecture, and structure governance.

    Common examples of functional domains in regulated manufacturing include:

    • Production / Operations: scheduling, execution, work-in-process tracking, and shop-floor data collection
    • Quality: nonconformance management, batch record review, CAPA, inspections, and laboratory information
    • Maintenance / Asset Management: preventive maintenance, work orders, equipment history, and calibration tracking
    • Supply Chain / Materials: procurement, inventory management, warehouse operations, and materials traceability
    • Engineering / Technical: process definition, recipes, routing, and change management for products and processes
    • Regulatory / Compliance: document control, training records, audit evidence, and regulatory submissions
    • Finance / Controlling: product costing, variances, and production-related financial reporting

    Use in systems and integrations

    In OT/IT and MES/ERP architectures, a functional domain commonly refers to the scope a system or module covers. For example, a computerized maintenance management system (CMMS) operates primarily in the maintenance functional domain, while an MES may span production, quality, and materials domains.

    Defining functional domains helps:

    • Clarify data ownership and stewardship across departments
    • Structure integrations between systems (for example, quality domain data flowing from MES to a QMS)
    • Assign responsibilities for procedures, controls, and records within each domain

    What it includes and excludes

    A functional domain includes:

    • The business objectives and responsibilities for that area
    • Standard processes and workflows
    • Roles and organizational units that perform the work
    • Data objects and records (for example, batch records, work orders, deviations)
    • Supporting applications and interfaces

    A functional domain does not necessarily equate to a single department or a single software application. A department may span several domains, and one domain can be supported by multiple systems.

    Common confusion

    Functional domain vs. business function: These terms are often used interchangeably. “Functional domain” is typically more explicit about including processes, data, and systems, not just organizational units.

    Functional domain vs. technical domain: A technical domain describes an area of technology (for example, network infrastructure or cybersecurity). A functional domain focuses on business or operational responsibilities (for example, quality management), even though it is often implemented using specific technologies.

    Operational context in manufacturing

    When designing workflows, digital work instructions, or integration projects, teams often map requirements by functional domain. For example, an MES deployment may be scoped by which functional domains it should cover (such as production and quality only), which influences data models, user roles, and validation expectations in regulated environments.