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.

  • ICT

    ICT stands for Information and Communication Technology. It commonly refers to the combined set of technologies, systems, and services used to create, process, store, secure, transmit, and display information. ICT includes both information technology (IT) components, such as servers and applications, and communication technologies, such as networks and telecommunications.

    Scope in industrial and regulated environments

    In manufacturing and other regulated operations, ICT typically includes:

    • Enterprise IT systems such as ERP, MES, LIMS, QMS, PLM, and document management platforms
    • Network infrastructure, including wired and wireless LANs, WAN links, VPNs, and internet connectivity
    • Communication systems used for voice, video, and collaboration, such as VoIP, conferencing tools, and messaging platforms
    • Data centers and cloud services that host business and manufacturing applications
    • End-user devices such as workstations, laptops, mobile devices, and thin clients used on shop floors and in offices

    In this context, ICT is often discussed alongside operational technology (OT). ICT systems support business processes, planning, quality management, and regulatory reporting, while OT systems directly monitor and control physical processes and equipment on the manufacturing line. The two domains increasingly interconnect, which raises additional cybersecurity, safety, and compliance considerations.

    ICT and supply chain risk

    Standards and frameworks that address supply chain risk, such as NIST SP 800-53, commonly use the term ICT supply chain to describe the full lifecycle of information and communication technology products and services. This includes hardware, software, firmware, cloud services, and supporting components sourced from external suppliers and integrated into enterprise and manufacturing environments.

    In this sense, ICT supply chain risk management covers:

    • Selection, evaluation, and monitoring of ICT vendors and service providers
    • Risks from third-party software, firmware, and hardware components used in IT and networked systems
    • Dependency on external cloud platforms, managed service providers, and connectivity partners
    • Potential impacts of compromised or unreliable ICT components on business and manufacturing operations

    Common confusion

    ICT vs. IT: Information technology (IT) usually refers to computing systems and data processing. ICT is a broader term that explicitly includes communication and networking technologies, though in many organizations the two terms are used interchangeably.

    ICT vs. OT: ICT primarily covers digital and communication systems that support information processing and business functions. Operational technology (OT) covers systems that directly monitor or control physical equipment and processes, such as PLCs, SCADA systems, and DCS. In modern plants, ICT and OT overlap where production equipment is networked and integrated with business systems.

    Operational use

    In operational and compliance documentation, ICT may appear in:

    • Policies and procedures for cybersecurity, access control, and incident response
    • Risk assessments that distinguish between ICT and OT assets and networks
    • Supplier and procurement requirements for ICT products and services
    • Architecture diagrams that show how enterprise, plant, and cloud systems communicate

    Using the term ICT helps emphasize that both computing and communication capabilities are in scope when analyzing risks, dependencies, and controls across manufacturing and regulated operations.

  • database schema

    A database schema is the formal description of how data is structured inside a database. It defines the tables or collections, the fields within them, the data types, primary and foreign keys, indexes, and the rules that govern relationships and constraints between data elements.

    In industrial and manufacturing environments, a database schema typically underlies systems such as MES, ERP, LIMS, historians, and quality management tools. It determines how production orders, batches, equipment states, parameters, alarms, quality results, and other operational data are stored and related so that applications and reports can retrieve and interpret the data consistently.

    Key characteristics

    • Logical structure: Describes entities such as orders, materials, equipment, and events, and how they relate (for example one order to many batches).
    • Data definitions: Specifies field names, types (such as integer, date, varchar), allowed values, and default rules.
    • Constraints and relationships: Includes primary keys, foreign keys, uniqueness, and referential integrity rules that keep data consistent.
    • Physical considerations: May include indexing and partitioning choices that affect performance and storage but not the business meaning of the data.

    Use in regulated and integrated environments

    In regulated manufacturing, the database schema is a critical part of how systems implement data integrity, traceability, and alignment with reference models or standards. For example, a team might design a schema so that production events and KPIs follow concepts defined in standards such as ISA-95 or ISO 22400, while still fitting the plant architecture and legacy MES/ERP/QMS systems.

    Standards that define terms, models, and KPIs generally do not prescribe a specific database schema or physical data model. Implementers must translate those conceptual models into a concrete schema that fits their technology stack, validation approach, and integration requirements.

    Common confusion

    • Database schema vs. data model: A data model is the higher-level conceptual design of data and relationships. A database schema is the concrete implementation of that model in a specific database technology.
    • Database schema vs. database instance: The schema defines the structure. The instance is the actual data stored according to that structure.

    Operational context

    Operational teams encounter the database schema during activities such as integrating MES and ERP, designing reports and dashboards, mapping OT data to IT systems, or validating changes to production or quality systems. Changes to the schema, such as adding a column for a new quality attribute or introducing a new relationship between equipment and recipes, typically require impact assessment, testing, and controlled deployment in regulated settings.

  • Data model alignment

    Data model alignment is the process of making the structure, meaning and relationships of data consistent across multiple systems or datasets so that information can be exchanged, compared and traced reliably.

    In industrial and manufacturing environments, data model alignment typically focuses on how core objects such as parts, bills of material, routings, work orders, tools, inspection results and genealogy records are represented in systems like ERP, MES, PLM, QMS and data historians. The goal is that the same business concept (for example a part number or operation step) is modeled in a compatible way across all systems.

    What data model alignment includes

    Data model alignment commonly involves:

    • Agreeing on shared definitions and attributes for key entities (such as part, lot, batch, work order, nonconformance, inspection characteristic)
    • Mapping fields and data types between systems (for example ERP item master to MES material definition)
    • Harmonizing identifiers and keys so the same physical object can be referenced consistently across systems
    • Standardizing relationships, such as how routings link to operations, resources and quality checks
    • Resolving overlaps or conflicts between system-specific data models so information is not duplicated or interpreted differently

    Aligned data models are a foundation for system interoperability, traceability, reporting and analytics, because they reduce ambiguity about what each data element represents.

    Operational context in manufacturing

    In day-to-day operations, data model alignment shows up in activities such as:

    • Designing integrations so MES can consume ERP work orders and BOMs without manual rework
    • Ensuring quality records (for example inspection results, NCRs or CAPAs) can be linked back to the correct part, lot and work order across QMS and MES
    • Supporting traceability and genealogy by using consistent identifiers for materials, serial numbers and process steps
    • Building dashboards and KPIs that pull from multiple systems using a shared understanding of entities like line, cell, operation or shift

    Common confusion

    • Data model alignment vs. data mapping: Data mapping is the technical activity of linking one field to another between systems. Data model alignment is the broader conceptual work of agreeing what entities exist, how they relate, and what each attribute means, which then guides the mappings.
    • Data model alignment vs. master data management (MDM): MDM focuses on managing authoritative values for key data (such as which system is the source of truth for part masters). Data model alignment focuses on the structure and semantics of data across systems. In practice, they are often addressed together.

    Relation to standards and integration

    Manufacturing reference models and standards (such as those used for MES, ERP and shop-floor interoperability) often provide conceptual models for products, operations and resources. Data model alignment efforts commonly use these models as a guide to design consistent representations across OT and IT systems, particularly when implementing MES/ERP integrations, electronic travelers or traceability solutions.

  • organizational interoperability

    Organizational interoperability commonly refers to the ability of different organizations, business units, or functions to work together effectively toward shared objectives. It focuses on aligning processes, responsibilities, decision rights, and governance so that information and capabilities provided by technical systems can actually be used in a coordinated way.

    What organizational interoperability includes

    In industrial and manufacturing environments, organizational interoperability typically involves:

    • Aligned roles and responsibilities so that operations, quality, maintenance, IT, and OT teams know who does what when data crosses boundaries.
    • Compatible processes and workflows across departments or sites, so that handoffs (for example, between MES, ERP, and QMS users) are clear and consistent.
    • Governance and decision-making structures that define how changes to systems, data, or procedures are requested, evaluated, approved, and communicated.
    • Common objectives and KPIs that ensure different organizations or functions are optimized toward the same performance, quality, and compliance outcomes.
    • Agreements and policies such as service-level expectations, escalation paths, and data ownership rules between internal functions or external partners.

    Organizational interoperability is often described as the highest of four interoperability layers: technical, syntactic, semantic, and organizational. It builds on the lower layers by ensuring that people, teams, and institutions are structured to take advantage of interoperable data and systems.

    Operational meaning in manufacturing

    In regulated manufacturing, organizational interoperability shows up in practical ways such as:

    • Cross-functional change control boards that include IT, OT, quality, and production for system or process changes.
    • Standardized work instructions that align how operators, quality inspectors, and maintenance technicians use MES and related tools.
    • Coordinated responses to deviations or nonconformances, where responsibilities span multiple systems and departments.
    • Shared governance for master data that impacts multiple plants or business units.

    Without organizational interoperability, technical integrations between systems (for example, between ERP and MES) may exist, but handoffs between teams, ownership of tasks, and decision processes remain fragmented.

    Common confusion

    • Versus technical interoperability: Technical interoperability focuses on systems being able to connect and exchange data. Organizational interoperability focuses on people, structures, and governance using that connectivity in a coordinated way.
    • Versus semantic interoperability: Semantic interoperability ensures common meaning of data elements. Organizational interoperability ensures that, even with common meaning, the right teams know how to act on the information.

    Relation to the four interoperability layers

    Organizational interoperability depends on and extends the other interoperability types. Technical, syntactic, and semantic interoperability enable accurate data exchange, while organizational interoperability ensures that this exchange fits into clear processes, responsibilities, and governance across departments, sites, or external partners.

  • data catalog

    A data catalog is a curated, searchable inventory of data assets that describes where data lives, what it contains, how it is defined, and how it should be used. In industrial and manufacturing environments, a data catalog typically covers data from OT systems (such as PLCs, historians, MES) and IT systems (such as ERP, LIMS, QMS, and BI tools).

    Key characteristics

    In this context, a data catalog commonly includes:

    • Registered data sources: Connections to databases, historians, data lakes, message buses, files, and application APIs used in operations.
    • Data asset listings: Tables, views, tags, KPIs, reports, and datasets with basic technical metadata (names, types, locations).
    • Business and semantic definitions: Plain-language descriptions, data owners, related processes, and links to standards or models such as ISA-95 or ISO 22400.
    • Lineage and relationships: How data is transformed, aggregated, and combined across systems, including how KPIs are calculated and from which sources.
    • Quality and usage information: Optional indicators such as update frequency, typical consumers, and known data quality constraints.

    Role in industrial and regulated environments

    In regulated manufacturing, a data catalog supports consistent understanding and use of operational and quality data across sites and systems. It can help:

    • Document definitions and formulas for KPIs, including those that are not directly defined in a standard such as ISO 22400.
    • Clarify which system is the source of record for specific measurements (for example, batch genealogy, equipment state, or test results).
    • Support audits and reviews by making data origins, transformations, and meanings more transparent.
    • Align MES, ERP, QMS, and analytics tools by providing a shared reference for data element names and meanings.

    Operational usage

    Operators and engineers may use a data catalog indirectly through analytics tools that query cataloged datasets. Data stewards, system owners, and BI teams typically use the catalog directly to:

    • Register new data sources from production lines, labs, and supply chain systems.
    • Document or revise metric definitions and link them to underlying data elements.
    • Search for existing data suitable for new reports, dashboards, or models.
    • Review lineage when troubleshooting discrepancies between systems, such as differences between MES and ERP production quantities.

    Common confusion

    • Data catalog vs data dictionary: A data dictionary usually describes the structure and fields of a specific database or application. A data catalog spans many systems and focuses on discoverability, governance, and cross-system definitions.
    • Data catalog vs data lake or data warehouse: A data lake or warehouse stores data. A data catalog describes data, including data that may reside in multiple lakes, warehouses, or source systems.
    • Data catalog vs master data management (MDM): MDM manages core reference data (such as material, equipment, or supplier records). A data catalog documents where all kinds of data reside and what they mean; it may reference MDM systems but does not replace them.

    Link to KPI and standards context

    When plants use KPIs that do not map directly to standards such as ISO 22400, a data catalog can record the KPI name, intent, formula, and data sources, and explicitly note how it relates to or diverges from standard definitions. This helps avoid ambiguity in cross-site comparisons, long-term system integration, and audits.

  • data model

    A data model is a defined structure that describes how data is organized, named, related, and constrained within and across systems. It specifies the entities (such as orders, lots, serial numbers, equipment, and test results), the attributes of those entities, and the relationships between them.

    In manufacturing and regulated operations

    In industrial and regulated environments, a data model commonly refers to the way production, quality, maintenance, and business data are structured across systems such as MES, ERP, QMS, LIMS, and data historians. It typically includes:

    • Core entities, for example work orders, batches/lots, serialized units, materials, equipment, and operators
    • Key identifiers, such as order numbers, lot IDs, serial numbers, and equipment IDs
    • Relationships and genealogy, such as which components went into which finished unit, or which tests were run on which batch
    • Rules and constraints, for example one serial number per physical unit or required links between a test record and a lot
    • Logical groupings used for reporting and KPIs, such as how shift, line, and product family are associated to events and measurements

    A data model may be documented as diagrams, database schemas, or configuration in integration tools. It can exist at different levels of abstraction, such as:

    • Conceptual data model: High-level view of the main entities and relationships, often used with business and quality stakeholders.
    • Logical data model: More detailed description of attributes and relationships, independent of specific database technology.
    • Physical data model: The actual implementation in databases, message schemas, or APIs used by systems.

    Operational relevance

    In daily operations, a clear data model supports:

    • Traceability and genealogy, by defining how order, lot, and serial keys connect production events and quality records
    • System integration, by aligning identifiers and relationships across MES, ERP, QMS, historians, and analytics platforms
    • Reporting and KPIs, by specifying which data sources and joins underlie each calculation and how results map back to units, equipment, or time periods
    • Change control, by allowing controlled updates to structures and relationships when processes or systems change

    Common confusion

    • Data model vs. database: A database is the implemented storage system; the data model is the design that describes what is stored and how it is related.
    • Data model vs. data schema: A schema is often the concrete, technical representation (for example tables and columns). The data model includes the schema but also the conceptual definitions, rules, and intended use of the data.
    • Data model vs. process model: A process model describes workflow steps and sequences of activities. A data model describes the information related to those activities and how that information is linked.

    Audit and compliance context

    In audits and investigations, a well-defined data model helps show how high-level metrics and reports can be traced back to underlying records. For example, it can demonstrate how KPI values are linked to specific orders, lots, serial numbers, test results, and system-of-record transactions, and how those links are preserved through integrations and data transformations.

  • Reporting bucket

    A reporting bucket is a defined category, range, or grouping used to sort data for reporting and analysis. In manufacturing and industrial operations, it commonly refers to the way events, records, transactions, or measurements are grouped so they can be summarized consistently in dashboards, KPIs, scorecards, or management reports.

    A reporting bucket is not the raw data itself. It is the classification structure applied to data so that similar items are counted together. Buckets may be based on time, status, cause, product family, work center, shift, severity, or another reporting dimension.

    How it is used in operations

    Reporting buckets appear in MES, ERP, quality systems, maintenance systems, and analytics tools when organizations need a stable way to compare activity across periods or processes. Examples include:

    • downtime buckets such as planned, unplanned, and changeover
    • quality buckets such as scrap, rework, use-as-is, or pending review
    • time buckets such as hourly, daily, weekly, or monthly reporting periods
    • order or inventory buckets such as released, in process, completed, or on hold

    The exact bucket definitions matter because the same operational event can be reported differently depending on how categories are designed and maintained.

    What it includes and excludes

    A reporting bucket usually includes the label, the business rule for what belongs in that label, and the mapping logic from source data into that group.

    It usually does not mean a storage container, database bucket, or cloud object storage bucket unless the discussion is specifically about IT infrastructure. In operations reporting, the term most often refers to a reporting classification rather than a technical storage object.

    Common confusion

    Reporting bucket vs. KPI: a bucket groups data, while a KPI measures performance using data that may be grouped into buckets.

    Reporting bucket vs. data field: a data field is a raw attribute such as reason code or timestamp. A reporting bucket may be derived from one or more fields.

    Reporting bucket vs. chart bin: a chart bin is a visual grouping used in analysis tools. A reporting bucket may be similar, but it is often a defined business category used repeatedly across reports.

    Manufacturing example

    If multiple machine stop codes roll up into broader categories such as material issue, operator waiting, maintenance, or setup, those broader categories are reporting buckets. The bucket allows management to view trends without reviewing every individual stop code.