A manufacturing data foundation across ERP, MES, SCADA, historians and PLM, built around the keys that make plant data joinable rather than around the platform that stores it.
Ingesting plant data is largely a solved problem. The difficulty is that a machine signal, a production order, a quality result and a maintenance record describe the same event and share almost no common key.
Every question anybody asks of manufacturing data requires at least two of these joins. The platform work is making them possible, and the effort column is the honest estimate.
| The join | Why it is not already possible | What resolving it needs |
|---|---|---|
| Signal to asset | Tag names are plant-local and cryptic | A maintained tag dictionary |
| Product to revision | The spec changed and the data did not say | Effective dating from PLM |
| Order to job to batch | Each system numbers it differently | A stored cross-reference, not a rule |
| Everything to time | Three clocks and a shift calendar | A time model, per section 3 |
| Tag to meaning | Nobody wrote down what it measures | The dictionary again. The real work |
| Plant to plant | Same concept, different conventions | An equivalence map, agreed |
Fragmented ERP, MES, SCADA, PLM and shop-floor data
Each system is right about its own part and silent on the rest.
Silos across plants and across departments
Production, quality and finance each holding part of the answer.
Plants that cannot be compared
Because the conventions differ, not the performance.
Definitions that vary by department
Production, quality and finance count differently.
Legacy systems with no interface
Where the only route out is a file or a screen.
Records with gaps nobody logged
A sensor offline, a shift not entered, a manual override.
Real-time that means four things
To four people, in the same meeting.
A platform per plant
Each built once, each maintained by whoever is left.
No owner for any of the data
So every disagreement goes to the data team.
Pick ten historian tags at random and ask what each one measures and on which asset. If the answers require a conversation with a specific engineer, the plant has signals rather than data, and every analytics project will pay that cost again. The dictionary is a few weeks of work, it is reusable forever, and it is the cheapest thing on this page.
Platform programmes usually begin with ingestion, because it demonstrates progress. Data arrives, nobody can join it, and the project spends its second year on the work that should have been its first phase.
We resolve the keys first, on the subset of assets and products that answer the first real questions, and expand from there.
Step 1
Assess the data landscape per plant, not as a group
Step 2
Discover and map every data source, including files and screens
Step 3
Build the tag dictionary for the assets in scope
Step 4
Resolve asset identity against the asset register
Step 5
Establish the time model: event, ingestion, shift, period
Step 6
Define the order to job to batch cross-reference
Step 7
Agree the plant-to-plant equivalence map
Step 8
Design the architecture for the latency people actually need
Step 9
Build ingestion, transformation and standardisation
Step 10
Implement quality controls and ownership at the boundary
Step 11
Publish data products rather than tables
Step 12
Scale by template and optimise cost continuously
Ask two plants for last month’s production figure and the shift it belongs to. The totals will usually match. The shift attribution, the production day boundary and the treatment of the night shift frequently will not, and that difference is why group reporting never quite reconciles. It is a morning of work to find and it is a definitional decision rather than a data problem.
Grouped by what each part does. The resolution group is the one that makes the rest useful, and the data products group is what stops the platform becoming a lake nobody can drink from.
Platform and ingestion
Enterprise manufacturing data platforms on your chosen architecture, technology-agnostic by design
Manufacturing data lakes and lakehouses, with the layering decided by how the data will be consumed rather than by convention
Industrial data ingestion pipelines from historians, SCADA, PLC tags and gateways
ERP, MES, SCADA and PLM data integration through supported interfaces
Real-time and batch processing, matched to the three latency requirements rather than to one
File and legacy ingestion, including the manual extracts that are currently load-bearing
Resolution and standardisation
The tag dictionary, built and owned, which is the artifact this page argues for
Asset identity resolution against the asset register and the maintenance system
Product and revision resolution with effective dating from PLM
Order, job, batch and lot cross-referencing, stored rather than derived
The time model from section 3, implemented once and used everywhere
Master data management for materials, assets, products and plants
Transformation and standardisation into a model the business recognises
Data products
Manufacturing data products with a contract, an owner and a published freshness, rather than tables somebody discovered
APIs and query interfaces for the consumers that need them
Curated models for the analytics consumers, per our Operational & Production Analytics page
Feature-ready data for predictive work, per our Predictive Analytics & Forecasting page
Semantic model foundations where Microsoft platforms are in use, per our Microsoft Fabric & Power BI page
Multi-plant and operations
Multi-plant consolidation with an agreed equivalence map rather than a forced schema
A deployment template per source type, parameterised per plant, so the second plant is weeks
Orchestration, observability and alerting on the pipelines, per section 8
Cost management, since industrial data volumes make this a design concern rather than an afterthought
These are the questions a manufacturing data platform exists to answer. The join each one depends on is named, because that determines the sequence of the work.
Unified production data across plants
One view of output, rate and performance across sites that record things differently.
Manufacturing performance consolidation
Bringing production, downtime and quality into one place so performance can be explained rather than reported.
Equipment and maintenance data integration
Joining machine signals to the maintenance record so condition and intervention sit together.
Supply chain and inventory unification
Material positions, consumption and movement across plants and warehouses.
Quality and inspection data integration
Inspection results, nonconformances and certificates joined to the product and the process that made it.
Production traceability and genealogy
Following a unit or batch backwards through its inputs, processes and conditions.
Enterprise manufacturing reporting
Reporting that reconciles with finance and does not require a week of investigation each month.
Foundations for AI and predictive analytics
Making data usable for forecasting, condition monitoring and quality prediction.
Pick one finished unit from last quarter and trace it back to its input lots and process conditions. Time how long it takes and how many people it involves. That number is the honest measure of your current data foundation, it is the number that will be asked for during a recall or a customer audit, and it is also the acceptance test to hold any platform programme to.
We work within your existing platform decisions and hosting policy. This page stays technology-agnostic by design: the Microsoft-specific implementation of the same foundation is covered on our Microsoft Fabric & Power BI page.
Edge and collection
Gateways and collectors at the plant, buffering when the link drops.
Ingestion
Streaming, batch and file, by source type rather than one mechanism.
Landing and raw retention
The data as received, retained, because reprocessing needs it.
Resolution and standardisation
The six joins, applied once rather than per consumer.
Curated models
Shaped for how the business asks questions.
Data products
With a contract, an owner and a published freshness.
Orchestration and observability
Per section 8, with freshness surfaced to consumers.
Hosting
Cloud, hybrid or on premises, with the plant link treated as a component.
Microsoft Fabric, Azure, Databricks or your existing platform of record, selected against your estate rather than recommended here, since this page is deliberately technology-agnostic and the Microsoft implementation has its own page in this group
OPC UA, which is the preferred route where the equipment and the historian support it
MQTT for gateway and sensor data where a publish and subscribe model fits
Historian interfaces, which are usually the highest-value source and the one with the most tags
PLC and SCADA tag access, read-only, through the route your controls engineers support
Modbus and legacy protocols where that is what the equipment speaks, usually via a gateway
ERP, MES, PLM, CMMS and WMS interfaces, through supported APIs or extracts
And secure file transfer, because some sources will remain files for years and that is acceptable if they are observable
Manufacturing data governance fails in a specific way: a platform team is made accountable for data they do not own and cannot correct, and every disagreement about a number arrives at their desk.
Ownership and stewardship
Per data element, named, in the business rather than in IT.
Quality and validation
At the boundary, with rejects visible rather than dropped.
Master data consistency
Materials, assets, products and plants, with one owner each.
Access control
By role and by plant, since a plant manager’s scope is a real boundary.
IT and OT separation and cyber security
One-way flow, read-only sources, segmentation reviewed with OT security, per section 3.
Lineage and traceability
From a figure back to the records behind it.
Retention and lifecycle
Raw, curated and archive, each with a stated period.
Industrial and regulatory requirements
Named by your functions, built to by us.
Turn manufacturing data into actionable insights that improve production visibility, optimize performance, and support informed decision-making. From industrial IoT and sensor analytics to production intelligence, predictive forecasting, and business intelligence, help manufacturers identify inefficiencies, anticipate operational challenges, and drive continuous improvement.
Platform monitoring is usually built for the team running the pipelines. The people depending on the data need something different and rarely have it.
How fresh this data is right now, as a published figure rather than a schedule that may or may not have run
Whether the last load was complete, including which periods or assets have gaps, per section 6
Whether there is a known problem affecting it, so nobody makes a decision on data that is being corrected
Pipeline reliability per source and per plant, with an alarm on the run that did not start as well as the one that failed
Freshness and latency against the stated bound for each data product, which is what makes the bound meaningful
Data quality and completeness: rejects, gaps, out-of-range values and late-arriving records, by source
Platform availability and the headroom to add plants, since scaling is the stated objective
Processing performance and the trend, because a job that is slowing is a capacity warning
Cloud and infrastructure cost by workload and by plant, which requires the tagging discipline our Cloud Modernization work describes
Collector and gateway health at every site, per section 6
And reprocessing events, with the reason, which is the improvement backlog
Ask a production manager how fresh they believe the plant data is, then ask the platform team. The answers differ in most organisations, and the gap is where decisions are being made on assumptions. Publishing freshness per data product is a small engineering change and it ends that entire category of dispute, including the one that happens during an incident when nobody can agree what the data was showing.
Outcomes depend on how many plants and systems are in scope and the state of your master data. These are the changes the work is aimed at.
A signal can be traced to an asset, a product revision and a point in time, which is what makes everything else possible
The tag dictionary exists and is owned, and every later project uses it rather than rebuilding it
Plants can be compared, because the equivalence map and the time model are agreed rather than assumed
Reporting reconciles with finance, because the production day and period are defined
Genealogy questions are answered in minutes rather than in a week
Data is more reliable and more accessible: consumers can see freshness and completeness without asking, gaps are visible rather than silent, and the people who need a figure can reach it themselves
Data arrives as products with contracts and owners rather than as tables somebody found
The second plant takes weeks because the first produced a template
Nothing the platform does writes back into the plant
And the raw data is retained, so a corrected join can be applied to history
Bring us two plants and the questions you cannot currently answer, and we will map the landscape, build the tag dictionary for the assets in scope, state which of the six joins are possible today, and set the genealogy trace as the acceptance test.
CaliberFocus builds manufacturing data foundations around the six joins that make plant data usable: signal to asset, product to revision, order to batch, time, tag meaning and plant-to-plant equivalence. We build the tag dictionary first, settle the time model, retain raw data so corrected joins can be applied to history, and read from the plant without writing back.
- A maintained tag dictionary, reusable by every later project
- A time model covering event, ingestion, posting, shift and period
- Data products with contracts, owners and published freshness
- Genealogy answered in minutes as the platform’s acceptance test
Security & Compliance
