Connect981 – Content Dev

Glossary Tag: signal detection

  • data lakehouse

    Core meaning

    A **data lakehouse** is a data architecture that combines characteristics of both a data lake and a data warehouse in a single platform. It typically:

    – Stores large volumes of raw and semi-structured data at scale (like a data lake).
    – Provides structured schemas, governance, and query performance comparable to a data warehouse.
    – Supports batch, interactive, and often streaming analytics on the same underlying data.

    In practice, a data lakehouse usually consists of low-cost, scalable storage (object storage or distributed file systems) with an added layer that manages tables, schemas, transactions, and access control to make the data reliable for BI and analytics workloads.

    Use in industrial and manufacturing environments

    In industrial and regulated manufacturing settings, a data lakehouse commonly refers to a central analytics layer that:

    – Consolidates OT, MES, ERP, LIMS, maintenance, and supplier data into a single logical store.
    – Retains raw time-series and event data (e.g., historian tags, machine logs) alongside curated, structured tables.
    – Enables cross-plant or cross-supplier reporting, operations intelligence, and advanced analytics without duplicating data into multiple warehouses.
    – Supports data scientists and engineers who need access to both granular shop-floor data and standardized business views.

    A lakehouse often acts as the intermediate data layer between plant-level systems (MES, historian, SCADA) and enterprise analytics or dashboard tools.

    Relationship to data lakes and data warehouses

    A data lakehouse is intended to bridge the gap between:

    – **Data lake**: Focused on storing raw, diverse data with minimal upfront modeling, but often lacking robust governance and performance for BI.
    – **Data warehouse**: Focused on highly modeled, structured data with strong governance and high-performance queries, but less flexible for raw or semi-structured data.

    The lakehouse adds data management features on top of data-lake-like storage, such as:

    – Table formats with schema definitions and evolution.
    – Transactional guarantees (e.g., ACID semantics) for reliable updates.
    – Metadata catalogs and governance functions.

    Site-context application: cross-site MES and supplier data

    In the context of combining MES dashboards across plants and suppliers, a **data lakehouse** is often used as the shared data foundation that:

    – Ingests and stores data from multiple MES instances, historians, ERP systems, and supplier feeds.
    – Applies normalization and harmonized data models to align equipment IDs, product codes, quality attributes, and time bases.
    – Exposes standardized tables and views that analytics tools and dashboards can query for cross-site or cross-supplier comparisons.

    The lakehouse itself does not guarantee alignment; it provides a technical platform where common data models, governance rules, and validation logic can be implemented.

    Boundaries and exclusions

    – A data lakehouse **is not** a specific product or vendor implementation, although some vendors market platforms under this term.
    – It **is not** the same as a traditional on-premises data warehouse, even if it can serve similar reporting use cases.
    – It **is not** a replacement for MES, historian, or ERP; instead, it aggregates and structures data produced by those systems for analytics and reporting.

    Common confusion and related terms

    – **Data lake vs. data lakehouse**: A lakehouse includes management and governance features (e.g., table formats, transactions, catalogs) that a basic data lake may not provide.
    – **Data warehouse vs. data lakehouse**: A data warehouse usually stores only modeled, structured data. A lakehouse supports both structured and raw or semi-structured data on the same storage.
    – **Data fabric / data mesh vs. data lakehouse**: Data fabric and data mesh are broader architectural or organizational concepts for how data is managed and owned. A lakehouse is more specifically an architectural pattern for storage and analytics.

  • workflow

    Operational meaning

    In industrial and regulated manufacturing environments, **workflow** commonly refers to a defined sequence of tasks, decisions, and data exchanges that together execute a repeatable business or operational process.

    A workflow typically specifies:

    – **Steps**: ordered activities performed by people, machines, or software systems.
    – **Roles**: who is allowed or expected to perform each step (operators, quality, planners, maintenance, etc.).
    – **Inputs and outputs**: data, documents, materials, or approvals consumed and produced at each step.
    – **Rules and decision points**: conditions that determine what happens next (e.g., pass/fail, reroute, escalation).
    – **Systems involved**: applications that support or record the steps (MES, ERP, LIMS, QMS, CMMS, PLM, etc.).

    Workflows can be manual (paper forms and verbal handoffs), partially digital (email, spreadsheets, point solutions), or orchestrated in a structured system (workflow engines, BPM tools, MES, or QMS).

    Use in manufacturing and regulated operations

    In this domain, workflows are used to structure and coordinate activities such as:

    – **Production execution**: issuing work orders, performing operations, capturing results, recording nonconformances.
    – **Quality processes**: deviations, nonconformances, investigations, approvals, CAPA, change control.
    – **Maintenance and asset management**: work requests, work orders, inspections, and sign-offs.
    – **Material and inventory handling**: receiving, inspection, release, movement, kitting, and returns.
    – **Engineering and documentation**: document change requests, approvals, and release of controlled instructions or specifications.

    The emphasis in regulated environments is typically on **traceability**, **role clarity**, and **consistent, documented execution** of these workflows across sites, lines, and products.

    Boundaries and what workflow is not

    To prevent confusion, it can be useful to distinguish workflow from related concepts:

    – A **workflow is not just a single task**. It is the structured sequence that connects multiple tasks, decisions, and handoffs into a coherent process.
    – A **workflow is not inherently a software tool**. Software may implement or automate a workflow, but the workflow itself is the process logic and sequence, independent of any given application.
    – A **workflow is not the same as a work instruction**. Work instructions describe *how* to perform an activity; workflows describe *when and in what order* activities occur, and how they connect across roles and systems.
    – A **workflow is not simply a value stream map or process map**, though these artifacts can be used to document workflows at different levels of detail.

    Common confusion and variants of usage

    The term “workflow” is sometimes used loosely and can overlap with other process terminology:

    – **Workflow vs. business process**: In many organizations these terms are used interchangeably. Some teams use “business process” for higher-level, end-to-end flows, and “workflow” for more detailed, step-level sequences embedded within that process.
    – **Workflow vs. SOP (standard operating procedure)**: An SOP may *describe* a workflow, but it also includes policy, safety, and compliance language. A workflow focuses on the operational flow and decision logic that can be executed or automated.
    – **Workflow vs. automation**: A workflow may be manual, partially automated, or fully automated. Automation is a characteristic of implementation, not of the workflow concept itself.

    In IT and OT systems, a **workflow engine** or **workflow orchestration** capability usually means a software component that executes, tracks, and enforces defined workflows (for example, routing approvals or triggering integrations between MES and ERP).

    Site-context application: workflows across systems

    In environments with **point-solution sprawl** (many disconnected tools), a workflow often:

    – **Spans multiple systems** (e.g., an issue opened on the shop floor in an MES, investigated in a quality system, and resulting in a change recorded in PLM and ERP).
    – Requires **standardization** so that the same type of event (such as a deviation, change request, or work order) follows a consistent set of steps and approvals regardless of which tools are used.
    – Becomes the **primary unit of integration design**, where interfaces and data mappings are defined around a specific workflow (for example, a nonconformance workflow or an engineering change workflow) rather than around each individual system.

    In this context, when teams “pick a workflow” to focus on, they are selecting a single, cross-functional process (such as batch release or supplier nonconformance management) and explicitly modeling the steps, roles, and data exchanges so that it can be executed more consistently and supported by light, targeted integrations.

  • equipment historian

    Core meaning

    An **equipment historian** is a time-series data system that continuously collects, stores, and serves equipment-related data from industrial assets such as production machines, utilities, and process lines.

    It typically records:
    – Process values (e.g., temperatures, pressures, speeds, flows)
    – Equipment states and modes (e.g., running, idle, faulted, setup)
    – Setpoints and recipe parameters downloaded to equipment
    – Alarms, events, and operator interventions
    – Selected calculated or aggregated values (e.g., averages, maxima, counts)

    Data is usually stored with high time resolution, compressed for volume, and indexed by timestamp, tag name, and sometimes asset hierarchy.

    How it is used in manufacturing environments

    In regulated and industrial operations, an equipment historian commonly:
    – Acts as the primary repository for high-frequency equipment and process data
    – Feeds MES, quality systems, and reporting tools with historical values
    – Supports root cause and deviation investigations by reconstructing equipment behavior
    – Provides evidence of equipment conditions during specific lots, batches, or work orders
    – Enables long-term trending, process capability analysis, and maintenance analytics

    Access is typically through:
    – Tag- or asset-based queries (e.g., all values of a temperature tag over a time range)
    – Time-window queries aligned to production events (e.g., batch start/stop times)
    – Visualization tools such as trending clients, dashboards, and OSIsoft PI–style tools

    Boundaries and what it is not

    An equipment historian:
    – **Is** a specialized database for time-series and event data from equipment
    – **Is not** a full Manufacturing Execution System (MES) or ERP system
    – **Is not** a document repository for procedures, certificates, or specifications
    – **Does not usually** manage workflows, work instructions, or electronic batch records

    Key distinctions:
    – **Equipment historian vs. MES**: MES coordinates production operations and records contextual production data (orders, materials, operators, electronic records). The historian focuses on continuous equipment and process values.
    – **Equipment historian vs. SCADA/HMI**: SCADA/HMI provides real-time control and visualization; the historian stores historical data that SCADA/HMI often uses for trends and analysis.
    – **Equipment historian vs. general-purpose database**: A historian is optimized for high-volume, time-stamped data with compression and fast time-series queries, rather than general relational workloads.

    Typical data model and integration

    An equipment historian commonly organizes data as:
    – **Tags (points)**: Named signals mapped to sensors, PLC registers, or equipment parameters
    – **Time-stamped samples**: Value plus quality/status flags at specific timestamps
    – **Events**: Discrete state changes, alarms, or mode transitions
    – **Asset hierarchy**: Optional structure that groups tags by machine, line, or area

    It is usually integrated with:
    – PLCs, DCS, and embedded controllers via industrial protocols
    – SCADA or DCS systems as a data source and consumer
    – MES, quality, and analytics platforms, often through APIs or connectors

    Site context: relation to MES and special process evidence

    On this site, an equipment historian is often referenced in the context of:
    – Providing high-frequency parameter traces (e.g., temperatures, pressures, spindle speeds) that complement MES records
    – Acting as one of multiple systems that together support evidence for special process qualification or certification
    – Storing parameters that may not be fully modeled or retained in MES (for example, sub-second values or auxiliary machine conditions)

    MES may log key parameters and production context, while the equipment historian retains the full time-series record. During audits or investigations, evidence may be drawn from both systems.

    Common confusion and misuse

    The term **equipment historian** is sometimes used interchangeably with:
    – **Process historian** or **plant historian**: These often cover a broader scope, including utilities and environmental data, not just production equipment.

    In many plants, the same historian platform serves both roles; the distinction is mainly in scope and configuration. When precision is important, “equipment historian” should refer specifically to the subset of historian data tied to production or test equipment.

  • product lifecycle management (PLM)

    Product lifecycle management (PLM) commonly refers to the coordinated governance of product-related data, processes, and decisions across the entire life of a product, from initial concept and design through manufacturing, service, and end-of-life.

    What PLM includes

    In industrial and regulated manufacturing environments, PLM typically covers:

    • Product definition data, such as CAD models, drawings, bills of material (BOM), specifications, recipes, and design history.
    • Change and configuration management, including engineering change requests (ECR), engineering change orders (ECO), revisions, variants, and configuration baselines.
    • Process and manufacturing definition, such as manufacturing BOMs, routings, work instructions, and tooling definitions, often handed off to MES and ERP.
    • Collaboration workflows across engineering, quality, supply chain, and manufacturing, including controlled approvals and reviews.
    • Traceable records that show how the product definition evolved, which versions were released, and what was authorized for production.

    PLM is often supported by a PLM software platform that integrates with CAD, MES, ERP, QMS, and document control systems. In regulated industries, it may be used as part of the controlled environment for design history files, device master records, or similar regulated artifacts, but it does not replace quality or regulatory systems.

    How PLM is used operationally

    Operationally, PLM acts as the source of truth for the product definition before and during production:

    • Engineering authors and maintains product structures and specifications in the PLM system.
    • Approved revisions and change orders are released from PLM to downstream systems such as MES and ERP.
    • Manufacturing uses PLM outputs (e.g., released BOMs, routings, 3D models, approved work instructions) as inputs for planning, scheduling, and execution.
    • Quality and regulatory teams reference PLM records to understand design intent, approved configurations, and change history when investigating nonconformances, performing impact assessments, or preparing for audits.

    Common confusion

    • PLM vs. PDM: Product data management (PDM) usually focuses on controlling engineering files (CAD, drawings) and revisions. PLM is broader, managing end-to-end product structures, processes, and cross-functional workflows, not just file vaulting.
    • PLM vs. MES: PLM manages the definition of the product and related changes. A manufacturing execution system (MES) manages the execution of production on the shop floor, including orders, routing execution, data collection, and traceability.
    • PLM vs. ERP: ERP focuses on planning, finance, inventory, and order management. PLM focuses on product definition and change control. The two typically synchronize BOMs, material masters, and sometimes routing data.
    • PLM vs. QMS: A quality management system (QMS) manages quality processes such as CAPA, nonconformances, audits, and complaints. PLM may integrate with QMS, and may store design-related quality records, but it is not the same as a QMS.

    Relation to standards and security

    PLM itself is a product and process governance concept. It is not a security or quality standard. In regulated manufacturing it often coexists with:

    • Information security standards (for example, an ISMS based on ISO 27001) that govern how PLM data and systems are protected.
    • Industrial cybersecurity frameworks (such as IEC 62443) that may apply when PLM connects to OT and plant systems.
    • Manufacturing and quality standards (for example, those defining design controls, documentation, and traceability) that rely on PLM-managed records as part of evidence.

    When PLM systems are integrated with MES, ERP, and other OT/IT components, organizations typically define clear scopes and interfaces to ensure that product data, change records, and access controls remain consistent across the lifecycle.

  • smart factory

    A smart factory is a manufacturing facility where equipment, systems, materials, and people are connected through digital technologies so that production can be monitored, controlled, and improved using data. It commonly refers to an Industry 4.0 style environment where machines, sensors, and software systems share information in near real time across the shop floor and into enterprise systems.

    In a smart factory, operational technology (OT) such as machines, PLCs, and automation is integrated with information technology (IT) such as MES, quality systems, data platforms, and ERP. The goal is not a specific level of automation, but the use of data and connectivity to support more consistent, traceable, and coordinated operations.

    Key characteristics

    Smart factories typically include several of the following characteristics, although implementations vary:

    • Connected assets: Machines, utilities, test equipment, and material handling systems instrumented with sensors and interfaces (for example OPC UA, industrial Ethernet) for data exchange.
    • Integrated systems: Links between shop floor control (SCADA, PLCs, DCS), MES, quality management, laboratory systems, and ERP for shared master data and production records.
    • Centralized and contextualized data: Collection of time-series, event, and transactional data into historians or data platforms where it is organized by product, batch, order, or equipment.
    • Analytics and visibility: Dashboards and reports for OEE, downtime, scrap, deviations, and other key indicators, often with role-based views for operators, engineers, and management.
    • Digital workflows: Use of digital work instructions, electronic logbooks, and electronic batch records rather than isolated paper processes.
    • Closed-loop control: In some cases, automatic adjustment of process parameters based on inline measurements or analytics, subject to applicable change control and validation requirements.
    • Cybersecurity and governance: Defined network segmentation, access controls, and change management practices to protect connected OT and IT systems.

    Use in regulated and industrial environments

    In regulated manufacturing, a smart factory still relies on defined procedures, documented evidence, and change control. Digital systems are typically subject to validation or qualification appropriate to the industry, and electronic records must support traceability, audit trails, and data integrity expectations.

    Smart factory initiatives in these environments often focus on:

    • Improving traceability of materials, equipment, and personnel activities across batches and lots.
    • Providing real-time visibility into process conditions, alarms, and deviations.
    • Linking quality events and CAPA processes to process data and production history.
    • Supporting audit readiness by centralizing and organizing production and quality records.

    What a smart factory is not

    • It is not a specific product, vendor solution, or certification. Different organizations and suppliers use the term with varying scope.
    • It is not limited to fully automated, lights-out production. Manual and semi-automated operations can be part of a smart factory if they are digitally connected and recorded.
    • It is not a substitute for regulatory compliance, validation, or safety practices. Those requirements still apply, regardless of the level of digitalization.

    Common confusion

    Smart factory vs. Industry 4.0: Industry 4.0 is a broader concept describing the current phase of industrial digitalization, including technologies such as IoT, cloud computing, and advanced analytics. A smart factory is a concrete implementation of these ideas in a specific plant or network of plants.

    Smart factory vs. digital twin: A digital twin is a virtual representation of a product, process, or asset that is kept in sync with its physical counterpart. A smart factory may use digital twins, but the terms are not interchangeable.

    Smart factory vs. MES: A manufacturing execution system is one core component of many smart factories, but a plant can have an MES without being highly connected or data driven across all operations. The smart factory concept encompasses the broader connected ecosystem.

    Relation to certification programs

    Some organizations and national programs offer maturity models, assessments, or badges that label a site as a smart factory or as compliant with an Industry 4.0 framework. These programs vary in scope and are not standardized globally. In regulated industries they do not replace required validation activities, inspections, or audits, and they do not by themselves guarantee interoperability across suppliers or legacy sites.

  • functional level

    In industrial and manufacturing contexts, functional level commonly refers to a logical grouping or layer of related activities, capabilities, or responsibilities within a broader system or organizational model.

    Core meaning

    A functional level is a way of organizing what a system or organization does into coherent blocks of functionality. Each level typically has:

    • Well defined responsibilities or objectives
    • Characteristic information inputs and outputs
    • Typical systems or roles that operate at that level

    Functional levels are often used in layered reference models to clarify who does what, what data flows where, and where interfaces need to be managed.

    Use in ISA-95 and similar models

    In the ISA-95 / IEC 62264 family of models, functional levels describe groups of activities across business and manufacturing operations, for example:

    • Business planning and logistics level (often associated with ERP and higher level planning)
    • Manufacturing operations management level (often associated with MES and related systems)
    • Batch, continuous, or discrete control levels (often associated with SCADA, DCS, or PLCs)

    These functional levels are distinct from physical hierarchy (such as enterprise, site, area, line, equipment). The same physical asset can participate in multiple functional levels through different software, interfaces, and workflows.

    Operational implications

    In day to day manufacturing operations, referring to a functional level usually involves:

    • Clarifying which systems are responsible for a given activity (for example, order scheduling vs. batch execution)
    • Defining integration points between levels (for example, how production schedules from ERP are handed to MES)
    • Assigning ownership for procedures, data, and controls aligned to that level

    This helps separate concerns such as planning vs. execution, or production control vs. basic equipment control, even when they share the same underlying infrastructure.

    Common confusion

    • Not the same as physical level: A functional level describes what is done (capabilities and processes), not necessarily where it physically happens.
    • Not a job grade or management tier: In some business contexts, “functional level” can refer to organizational hierarchy. In manufacturing systems discussion, it usually refers to system or activity layers, not employee seniority.

  • data warehouse

    Core meaning

    A **data warehouse** is a centralized database designed and structured specifically for querying, reporting, and analytics rather than day‑to‑day transaction processing. It typically stores large volumes of historical, integrated data from multiple source systems in a consistent, well‑defined schema.

    In industrial and manufacturing environments, a data warehouse commonly aggregates information from MES, ERP, LIMS, QMS, maintenance, and other OT/IT systems to support cross‑site and long‑term analysis.

    Key characteristics

    Common characteristics of a data warehouse include:

    – **Subject oriented**: Organized around key business domains (e.g., production, quality, maintenance, inventory), not around individual applications.
    – **Integrated**: Data from different source systems is reconciled, standardized (units, codes, identifiers), and stored in a common model.
    – **Time variant**: Maintains historical snapshots (e.g., daily, batch, or event‑based loads) to enable trend and performance analysis.
    – **Non‑volatile**: Once loaded, data is rarely updated or deleted; changes are usually captured as new records to preserve history.
    – **Optimized for analytics**: Uses structures such as star or snowflake schemas, facts and dimensions, and indexing strategies that support complex queries and aggregations.

    Use in manufacturing and regulated operations

    In regulated and multi‑site manufacturing, a data warehouse commonly:

    – Consolidates production, quality, supply chain, and maintenance data from multiple plants or suppliers.
    – Provides a stable source for **operations intelligence**, KPI dashboards, and management reporting.
    – Supports traceability and investigation workflows by combining batch, lot, equipment, and material data from different systems.
    – Enables cross‑system analysis (e.g., comparing OEE, yield, or deviation patterns across lines, plants, or contract manufacturers).

    The warehouse often sits between operational systems (MES, ERP, historians) and reporting/analytics tools, acting as an intermediate data layer with controlled data models and governance.

    Boundaries and what it is not

    – **Not an operational database**: It does not typically run production transactions (e.g., MES work execution, ERP order posting). Latency is usually minutes to hours, not real time.
    – **Not a data lake**: A data warehouse stores structured, modeled data. A data lake can store raw, semi‑structured, or unstructured data with less predefined structure.
    – **Not a single tool or vendor product**: The term describes an architectural role. It may be implemented using different database platforms, cloud services, or appliances.

    Common architectures and components

    A data warehouse implementation typically includes:

    – **Source systems**: MES, ERP, historians, LIMS, QMS, CMMS, supplier portals, and other OT/IT systems.
    – **Data integration/ETL or ELT**: Processes that extract data from sources, transform and standardize it (e.g., units of measure, identifiers), and load it into the warehouse.
    – **Core warehouse schema**: Fact tables (e.g., production, quality results, maintenance events) and dimension tables (e.g., product, equipment, site, supplier, time).
    – **Semantic layer or data marts**: Curated subsets of the warehouse for specific domains such as production performance, quality, or supply chain.
    – **Access layer**: BI tools, dashboards, reporting systems, and analytics platforms that query the warehouse.

    Relation to MES dashboards and cross‑site views (site context)

    When MES dashboards combine data from multiple plants or suppliers, an intermediate data warehouse (or similar analytical store) is often used to:

    – Normalize data models across different MES/ERP instances and plants.
    – Provide a single, governed source for enterprise‑wide KPIs and cross‑site comparisons.
    – Manage versioning and history of production and quality data for long‑term analysis.

    In brownfield environments with heterogeneous systems, the data warehouse commonly acts as the consolidation layer where data alignment, validation, and historical structuring are performed before dashboards access it.

    Common confusions

    – **Data warehouse vs. data mart**: A data mart is usually a smaller, subject‑specific subset or view of the warehouse (e.g., a quality data mart). The warehouse is the broader, enterprise‑level store.
    – **Data warehouse vs. data lakehouse / analytics platform**: Some modern platforms combine warehousing and data lake capabilities. The term “data warehouse” still refers to the structured, analytical store component within such platforms.
    – **Data warehouse vs. historian**: A process historian stores high‑frequency time‑series data from equipment and sensors. A data warehouse may ingest summarized or selected historian data but is not optimized as a raw time‑series store.

  • data flow mapping

    Core meaning

    Data flow mapping is the activity of systematically documenting how data moves between systems, people, and locations across a process or organization. It describes the sources, destinations, formats, and transfer mechanisms for data, rather than the business logic applied to that data.

    In industrial and manufacturing environments, data flow mapping typically focuses on how production, quality, maintenance, and business data travel across OT and IT systems and into external parties such as suppliers or customers.

    What data flow mapping includes

    Data flow mapping commonly captures:

    – **Data sources**: where data originates (e.g., PLCs, SCADA, MES, LIMS, ERP, supplier portals, spreadsheets).
    – **Data destinations**: where data is consumed or stored (e.g., historians, MES, ERP, QMS, file shares, cloud services).
    – **Transfer paths**: how data moves (e.g., APIs, message queues, OPC, file transfers, email, USB, paper forms later keyed in).
    – **Data types and classifications**: what the data represents and its sensitivity (e.g., production recipes, NC/CAPA records, Controlled Unclassified Information, personally identifiable information).
    – **Process and workflow context**: which business or manufacturing steps the data supports (e.g., work order release, batch record review, supplier qualification).
    – **Actors**: which roles or systems send, modify, or receive the data (e.g., operators, quality engineers, maintenance planners, external labs).

    The result may be represented as diagrams, tabular inventories, or both.

    Use in manufacturing and regulated environments

    In manufacturing, data flow mapping is commonly used to:

    – Describe how shop-floor data moves from equipment and sensors into MES, historians, and ERP.
    – Show how quality data flows between QMS, LIMS, production systems, and customer or regulatory reporting channels.
    – Document how engineering data (e.g., specifications, BOMs, recipes) is distributed to production lines and suppliers.
    – Trace how supplier and customer data is exchanged through portals, EDI, APIs, or manual processes.

    In regulated or audited settings, such mappings help organizations:

    – Identify where controlled or sensitive data is stored or transmitted.
    – Understand system boundaries and trust zones between OT and IT networks.
    – Support risk assessments, change impact analysis, and validation or verification activities.

    Boundaries and what it is not

    Data flow mapping:

    – **Is about movement and location of data**, not about detailed business rules or algorithms.
    – **Is system- and process-focused**, not limited to network-layer packets or code-level interactions.
    – **May include high-level technical details** (e.g., protocol, interface type) but usually does not replace full network diagrams or application design specifications.

    It is not the same as:

    – **Process mapping**: which focuses on business or manufacturing steps, roles, and decisions; data flows may be one component, but are not the only focus.
    – **Value stream mapping**: which concentrates on material and information flow for performance and waste analysis, rather than documenting specific data interfaces and storage locations.
    – **Data modeling**: which describes data structure and relationships (schemas, entities, attributes), not how data moves between systems.

    Common confusion and misuse

    Data flow mapping is sometimes confused with general “system architecture” or “network” diagrams. While these may overlap, data flow mapping is specifically concerned with:

    – What data items move.
    – Between which endpoints.
    – By what mechanisms.
    – Under which process context and controls.

    Another common misuse is to focus only on formal, IT-managed integrations and ignore:

    – Ad-hoc spreadsheets and local databases.
    – Manual exports, email attachments, removable media.
    – Shadow tools and unofficial workflows on the shop floor.

    These informal flows often handle sensitive production, quality, or customer data and are important to capture.

    Site context: security and compliance readiness

    In the context of security and frameworks such as CMMC or similar requirements, data flow mapping is used to:

    – Identify where controlled or regulated data enters manufacturing operations (e.g., controlled drawings, specifications, contract data).
    – Trace how that data moves through OT systems, shop-floor workflows, supplier interactions, and back-office systems.
    – Highlight undocumented or ungoverned paths (e.g., printing drawings, copying to USB, sharing via personal email) that can become compliance and security gaps.

    For assessments and audits, documented data flow maps provide evidence that an organization understands and manages how sensitive information is handled across production, IT, and supplier ecosystems.