A factory can collect enormous amounts of data and still struggle to answer a basic operational question: what does this event actually affect?

ERP knows customer orders, materials, planned dates, and inventory. MES knows what is executing on the shop floor. PLCs and SCADA know machine states, alarms, and process values. Maintenance knows asset condition and service history. Quality knows inspection and release status. Engineering knows the product definition. The problem is not usually a lack of data. The problem is that these systems describe the same factory through different names, IDs, states, and rules.

An industrial data model creates shared meaning across those boundaries. It defines the factory objects that matter, gives them stable identity, and describes how products, processes, resources, orders, materials, people, tools, quality records, and machine events relate to each other. The goal is not to replace ERP, MES, maintenance, or other source systems. The goal is to make their information understandable as one connected production context.    

PLENTY OF SYSTEMS — NO SHARED MEANING
A modern plant already has specialized systems for almost every important job. ERP manages demand and commitments. MES manages execution. PLCs control equipment. SCADA presents machine conditions. Historians store process data. Maintenance systems manage assets and service work. Quality systems maintain inspection records, and Power BI can combine information for reporting.

Each system exists for a reason. The problem begins when the same real-world object appears differently in every one of them. A machine may be represented as a work center in ERP, an asset number in maintenance, a resource in MES, a group of OPC UA nodes in the control system, and a completely different friendly name on the shop floor.

An industrial model does not force all of those systems to use one identifier. Instead, it records how those references relate to the same physical or logical object. That gives the factory a stable identity layer without destroying the local structures each source system needs.

WHAT AN INDUSTRIAL DATA MODEL ACTUALLY IS
An industrial data model is a shared set of rules describing what matters in the factory and how those things connect.

It answers practical questions such as what counts as a production order, what a product revision represents, how a work center differs from a physical asset, when material is released, and what it actually means for a machine to be available.

The model can describe:
• Object types and identities
• Properties and states
• Relationships between factory objects
• Source-system references
• Effective dates and versions
• Conditions attached to relationships
• Ownership of definitions and rules

This lets several systems describe different aspects of the same production situation without collapsing them into one misleading status. An order can be released in ERP while its current MES operation remains blocked. A machine can be mechanically healthy while still unavailable because the required fixture is missing. Those facts can all be true at the same time.

THE MODEL IS NOT THE DATA PLATFORM
Microsoft Fabric, SQL databases, historians, data lakes, and other platforms are useful for storing, moving, governing, and analyzing information. But none of them can determine what a work center means in your factory simply because the records are stored together.

You can load ERP orders, MES execution records, maintenance events, quality results, and machine telemetry into one Lakehouse and still be unable to answer whether a particular order can move to another machine before the end of the shift.
That answer depends on relationships.

Which product revision is involved? Which operation must run next? Which resources are approved for that operation? Which tooling is required? Is the operator qualified? Does the current machine state allow the work? Is an inspection rule attached to the alternate route?
The platform can host and query those relationships, but the factory still has to define them.   

WHY TABLES ALONE OFTEN BECOME DIFFICULT
Relational tables are not the problem. ERP, MES, maintenance, and many manufacturing applications depend on relational models because they are excellent for transactions and structured records.

The difficulty appears when production questions cross many relationships that change over time.
A product revision may require several operations. An operation may be approved on multiple resources. One machine may support only certain product versions, tooling combinations, size ranges, or inspection requirements. Operator qualifications may expire. Engineering changes may invalidate a previously approved route.

All of this can be represented in tables, but the logic often becomes scattered across reports, SQL queries, spreadsheets, and local exception lists. Different reports then rebuild the same factory relationships differently.

The industrial model provides a shared relationship layer so the rules can be defined once, governed, and reused instead of rediscovered every time someone asks a difficult production question. 

PPR — PRODUCT, PROCESS, RESOURCE

A practical starting structure is PPR: Product, Process, Resource.
Product answers: what are we building?
Process answers: how does the work need to happen?
Resource answers: what can perform that work under real production conditions?

PPR provides a simple backbone for connecting isolated records into a production model. It avoids trying to model the entire enterprise immediately and instead focuses on the relationships that determine whether work can actually happen.

PRODUCT IS MORE THAN A PART NUMBER
A product definition may include the product family, specific variant, revision, bill of material, customer configuration, material requirements, inspection requirements, and quality rules.
This matters because two records with the same broad part number may not be interchangeable. A new revision may require a tighter tolerance, different process parameters, another inspection step, or equipment with higher capability.

Engineering systems such as PLM may own design intent. ERP may hold the material master and planning version. MES may hold a production definition. Quality may maintain an inspection plan.
The industrial model connects those references so production can answer a much more important question than “what part number is this?”

It can answer: are we building the correct revision under the rules that currently apply?

PROCESS DEFINES HOW WORK SHOULD HAPPEN
The process side describes the approved route through production. It includes more than a list of machines.

It can describe operation sequence, setup requirements, inspection points, wait times, rework paths, approvals, handoffs, and conditions that must be satisfied before work continues.
A planned process definition describes how work is supposed to happen. MES execution data records what actually happened for a specific order.
Both matter.

Without the planned process, you cannot determine whether execution followed the approved route. Without the execution history, you cannot learn what actually happened during production.

RESOURCE MEANS CAPABILITY — NOT JUST A MACHINE
A production resource can be a machine, line, workstation, tool, fixture, operator, test rig, transport system, or another capability needed to perform work.
This distinction is critical because a machine can be technically available while the operation remains impossible.

The required fixture may be in use elsewhere. A tool may be out of calibration. The only qualified operator may not be on the current shift. A machine may support the product family but not the current revision.

The model therefore separates design capability from current state.
Capability asks what a resource can perform under defined conditions.
Current state asks whether that capability can actually be used right now.
Production feasibility depends on both.

THE RELATIONSHIPS CARRY THE REAL MEANING
The value of PPR comes from the relationships between Product, Process, and Resource.
A product requires a process. A process contains operations. An operation can be performed by certain resources, but often only under specific conditions.

For example, a relationship may effectively state that a particular machine can perform Operation 20 for a defined product family and revision range when Fixture F12 is installed, the machine is within its approved operating condition, and a qualified operator is assigned.
That sounds detailed because production is detailed.

Those are the checks people already make manually when they move work after a machine breakdown. The industrial model simply makes the logic explicit and reusable.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.