TL;DR
Manufacturing data analytics connects production records with business records so plants can act on quality, throughput, maintenance and delivery problems. The hard part of manufacturing data analytics is the data. That is because ERP, MES, historians, quality systems and CRM each describe the same order in different terms. Solving it takes shared keys, matched time windows, kept history and agreed KPI definitions. A practical start is one decision that current reports answer badly. Microsoft Fabric and Power BI are the worked platform example here.
Key Takeaways Manufacturing data analytics turns production, quality, maintenance and order data into decisions a plant can act on. ERP, MES and SCADA, historians and sensors, quality systems, and supply chain and CRM are the five source families to connect. Most of the effort goes into shared keys, aligned time windows, kept history and agreed KPI definitions, before any dashboard work. A unified platform such as Microsoft Fabric holds ERP and plant data in one place, with Power BI reading shared measures. Start with one decision that current reports answer badly, reconcile it against the ERP, then scale to the next plant. Kanerika has unified three SAP systems on Fabric for one manufacturer and connected more than 200 QAD tables for another. Watch on YouTube
Microsoft Fabric Case Study: Order Lead Time Analytics for Manufacturing
Kanerika’s Microsoft Fabric case study on order lead time analytics for a manufacturer.
One Order, Four Different Answers Picture a Monday review at a mid-size plant. Operations says the line ran to schedule last week, while the ERP shows six customer orders overdue.
Quality also has two batches on hold, and finance cannot explain a cost variance on the same product family.
Each report is correct inside its own system. Still, none of them tells the plant manager which orders are at risk, why, and what to do today. That question needs records from four systems joined at the order and batch level, so no single report can answer it.
This is where manufacturing data analytics earns its keep. Done well, it gives the plant manager one answer that operations, quality and finance all accept.
What Is Manufacturing Data Analytics? Manufacturing data analytics is the practice of collecting, joining and analyzing data from production, quality, maintenance, supply chain and finance to improve plant decisions. It covers the full path from a machine signal or an ERP transaction to an action someone then takes on the floor or in planning.
Manufacturing analytics and data analytics in manufacturing usually mean the same thing. The difference from standard ERP reporting is scope.
An ERP report describes what the ERP recorded. In contrast, manufacturing analytics combines that record with what happened on the line, in the lab and at the customer. That wider view helps plants cut scrap and protect delivery dates.
You don’t need to be a data expert to use it. It’s really just about asking the right questions and letting your numbers give you the answers. It helps your team work smarter, not harder. And over time, those small insights can make a big difference. For manufacturers turning those insights into physical products, custom CNC machining with no minimum order can provide a flexible option for producing prototypes or smaller component runs.
The Four Types of Manufacturing Analytics Analysts generally group manufacturing analytics into four types. Each one answers a harder question and needs more connected data than the one before it.
A prediction is a signal that still needs checking. Diagnostic work has to confirm why a defect or failure happened before the plant changes a process.
Which Manufacturing Data Sources Need to Be Connected? Plants generate data at every level, from sensors on a machine to the general ledger. For example, the ISA-95 standard describes this as a hierarchy. MES and SCADA sit at level 3, and ERP and business systems sit at level 4, according to the International Society of Automation .
So analytics usually needs data from several levels at once.
ERP Data for Orders, Materials, Inventory and Costs The ERP holds the commercial and financial record. Sales orders, work orders, bills of materials, inventory, purchasing and costs live there, whether the system is SAP, QAD or another platform.
ERP data is reliable for what was ordered, issued, received and booked. However, it is weaker on what happened inside an operation, such as a micro-stop or a process drift during a batch. Kanerika’s article on AI in ERP also covers how ERP vendors are adding analytics of their own.
MES, Historians, Quality and Maintenance Records MES and SCADA record execution, including work order progress, good and rejected counts, downtime reasons and operator actions. Historians store time-series signals such as temperatures, pressures, speeds and machine states, often every second.
Quality systems and LIMS hold inspections, test results and nonconformances, while maintenance systems hold work orders, failures and spare parts. So each one answers a different part of the same production story.
Supply Chain and CRM Data for Demand, Shipments and Complaints Finally, supplier deliveries, shipments, customer orders and complaints connect the plant to the outside world. CRM opportunities are forecasts, while confirmed orders sit in the ERP, so keep the two apart in any delivery analysis.
Table 1: Manufacturing Data Sources and How They Connect
Source Main records Join keys Update pattern Usual owner ERP Orders, items, inventory, costs Order, item, site, lot Transactions through the day Finance and IT MES and SCADA Work order progress, counts, downtime Work order, line, asset, shift Events in near real time Operations Historian and IoT Process signals, machine states Asset tag and timestamp Streams, often every second Engineering and OT Quality and LIMS Inspections, test results, holds Lot, batch, sample, order Per sample, sometimes late Quality Maintenance Work orders, failures, parts Asset, failure code Per job Maintenance Supply chain and CRM Supplier deliveries, shipments, complaints Supplier, customer, order, lot Per transaction Supply chain and sales
Why Manufacturing Analytics Stalls Across Separate Systems The hardest step comes after connecting each source. Records from different systems then have to describe the same order, batch and asset in the same terms.
The ERP Records the Order, the MES Records Its Execution An order can be complete in the MES and still open in the ERP because a quality hold blocks shipment. Partial completions, scrap and rework also make the two systems disagree further.
Neither one is wrong, because they track different events on different clocks.
Historians Record Signals Without Business Context A temperature reading means little on its own. For example, to explain a defect, it needs the asset, the product, the batch and the production window it belongs to. But that context lives in the MES and the ERP.
Identifiers and Cutoffs Rarely Match For instance, the same machine can carry three names across maintenance, MES and historian systems. Item codes differ by site, shifts cross midnight, plants run in different time zones and the ERP posts some transactions late. Spreadsheet joins hide these mismatches until two reports disagree in a meeting.
Several ERP Instances Multiply the Problem Groups that grew through acquisitions may also run separate ERP instances by site or region. Order numbers can repeat across instances, and each one may have its own customizations. As a result, any shared model needs the site or instance in every key.
How to Integrate ERP and Plant Data Without Losing Context Integration choices decide whether the analytics layer can be trusted. Four design decisions matter more than the choice of tool.
Match the Ingestion Method to the Source and the Decision Machine-state data may need streaming, while month-end finance data can wait for a nightly load. So pick the method by how fresh the decision needs the data to be and how much load the source can take.
Table 2: Ingestion Methods for Manufacturing Data
Method Suits Strength Limit Check to run Scheduled extract ERP finance, master data Simple to run Misses deletes, data ages between runs Row counts and totals per load API Cloud MES, CRM, quality apps Supported by the vendor Rate limits, partial history Paging and missing history Change capture or mirroring ERP and MES databases Inserts, updates and deletes flow through Needs keys and source access Reconcile against source totals Event stream Sensors, machine states Seconds of latency Volume and storage cost Late and duplicate events
Create Shared Keys for Sites, Assets, Products, Orders and Batches Build cross-reference tables that map each system’s identifiers to one shared key. Then a site code, an asset ID and an item number mean the same thing in every model.
When order numbers repeat across sites or ERP instances, use compound keys that include the site. For example, site code plus order number keeps two plants’ matching order numbers apart. Kanerika’s guide to data modeling best practices covers the patterns.
Align Timestamps, Production Windows and Record Detail Separate when an event happened from when it was posted. Then map every timestamp to a shift calendar and a time zone. Join sensor readings to orders through production windows, because row-level joins can double the totals.
Also decide the grain of each fact table up front. Order lines, operations, batches and sensor minutes are different levels of detail, so they should not share a table.
Handle Corrections, Deletes and Late Records ERP and MES records change after the fact. For example, orders get cancelled, quantities get corrected and lab results arrive days later. So the pipeline has to carry updates and deletes and reopen calculations that depend on them.
Kanerika ran into this on live QAD systems for a global manufacturer. Standard data pulls missed records deleted in QAD and also slowed down on the largest tables. As a result, reports risked drifting away from QAD totals, according to the QAD Open Mirroring case study .
Kanerika’s fix was a QAD connection on Open Mirroring that sends new, changed and deleted records to Fabric. It also logs every run and alerts on errors. Testing on live systems also found seven QAD-specific issues, which Kanerika fixed before rollout.
Kanerika’s guide to data reconciliation covers the checks that catch drift early, before reports go out.
Checklist
Data Integration Checklist for Enterprise Teams
Kanerika’s enterprise data integration checklist covers connectivity, reliability, security, partner integrations and governance. Use it to check ERP and plant data feeds before the first model is built.
Get the Checklist → Tracing a Quality Hold to a Delivery Risk Take the Monday review again, when a lab result fails for one batch. To see the business impact, the model has to follow five links.
Quality to lot. The failed sample points to a batch and its supplier lot.Lot to order. The MES links the batch to the work orders that consumed it.Order to process window. Historian data for that window shows whether the process ran in range.Order to customer. The ERP links work orders to the customer orders and promised dates they serve.Customer to response. Planning sees which shipments are at risk and which other lots used the same material.With those links in place, the plant can answer the manager’s question in minutes, while without them someone rebuilds the trail in spreadsheets each time.
Where Microsoft Fabric and Power BI Fit in Manufacturing Analytics A unified platform should hold raw, cleaned and business-ready data, serve both history and timely views, and publish shared KPI definitions. For example, Microsoft Fabric is one way to get there, with Power BI as its reporting layer.
OneLake, Lakehouse, Warehouse and Mirroring Microsoft Fabric stores all workloads in OneLake, while Lakehouse and Warehouse items hold the cleaned and modeled layers and pipelines handle scheduled loads.
Fabric mirroring also keeps copies of operational databases current in OneLake. Microsoft’s mirroring overview lists sources such as SQL Server, Oracle and SAP through SAP Datasphere.
In addition, open mirroring lets any application write change data into a mirrored database. That is how ERPs without a native connector, such as QAD, can be brought in.
Kanerika’s guide on mirroring QAD ERP data into Microsoft Fabric covers that route. Its comparison of QAD ERP reporting options shows where native tools are still the better fit.
Real-Time Intelligence for Sensor and Event Data Fabric Real-Time Intelligence handles data in motion, where Eventstreams collect and route streaming data without code. Eventhouses store and query it, and Activator triggers actions when conditions are met, according to Microsoft’s Real-Time Intelligence overview .
This suits machine states and process signals, especially when plants want to watch them within seconds. Control loops still belong in the plant’s own control systems.
For setup steps, see Kanerika’s overview of Real-Time Intelligence in Microsoft Fabric .
Power BI Semantic Models for Consistent Reporting A shared semantic model holds the relationships, measures and access rules that every report uses. When OEE or on-time delivery is defined once, every plant and every report reads the same number.
Power BI can read mirrored and lakehouse tables in Direct Lake mode without a scheduled import, as Microsoft’s Open Mirroring FAQ confirms. Kanerika’s walkthrough of Direct Lake semantic models goes into more detail.
What Fabric Does and What the Team Still Owns Fabric provides the storage, compute and reporting layers. However, the work that makes manufacturing data trustworthy stays with the team or its partner.
Table 3: Fabric Components and the Work That Remains
Requirement Fabric component Work the team still does Keep ERP data current Mirroring, open mirroring, pipelines Source access, keys, a publisher for unsupported ERPs Capture sensor events Eventstream, Eventhouse Tag mapping, edge connectivity, retention rules Model and clean data Lakehouse, Warehouse, notebooks Cross-references, grain decisions, quality rules Shared KPIs and reports Power BI semantic models Agreed definitions, access rules, reconciliation Alerts and actions Activator Thresholds, owners and response steps
Fabric is not the only option. A company with a working warehouse and stable reporting should weigh skills, capacity costs and current investments before switching platforms. Kanerika’s Fabric and Databricks comparison covers one common choice.
Manufacturing Data Analytics Use Cases That Depend on Connected Data The use cases below each need at least three sources joined, which is what separates them from a single-system report.
Trace Scrap and Rework to Materials and Process Conditions Join quality outcomes to supplier lots, MES events and historian windows. Engineers can then test whether defects cluster by lot, line, shift or process setting before they change a recipe or a supplier.
Connect Delivery Risk to Demand, Inventory and Production Status Join customer commitments, open ERP orders, material availability, MES progress and quality holds. Planners then see at-risk orders early enough to reschedule or warn the customer. Kanerika’s article on predictive analytics in supply chain covers forecasting on top of this view.
Connect Downtime and Maintenance to Business Impact Unplanned downtime costs the world’s 500 biggest companies about $1.4 trillion a year, according to Siemens’ True Cost of Downtime 2024 report. That equals 11% of their revenues.
Linking machine events to maintenance history and the orders they delayed also shows which stops matter most. Kanerika’s guide to AI in predictive maintenance covers the next step.
Inventory, Demand and Energy Inventory analytics joins stock, consumption and demand to cut shortages as well as excess. Energy analytics joins meter data with output so plants compare energy per good unit, adjusted for product mix. Kanerika’s article on AI inventory management covers the inventory side.
Watch on YouTube
Power BI for Operations: Replacing Excel Reports (Real Case Study)
Kanerika’s case study on moving operations reporting from Excel to Power BI.
Table 4: Use Cases, Data and Owners
Use case Sources joined Main KPI Who acts Scrap and rework Quality, MES, historian, ERP lots Scrap rate, first pass yield Quality and process engineering Delivery risk ERP orders, inventory, MES, quality holds On-time delivery Planning and customer service Downtime MES states, historian, maintenance, ERP orders OEE availability, MTBF Maintenance and operations Inventory ERP stock, consumption, demand forecast Inventory turns, stockouts Supply chain Energy Meters, MES output, product mix Energy per good unit Operations and sustainability
How to Make Manufacturing KPIs Consistent Across Plants Connected data can still produce misleading comparisons when each plant calculates the same KPI differently. Fix the definitions before comparing sites.
Agree Calculation Rules and Boundaries OEE is Availability multiplied by Performance multiplied by Quality, as OEE.com explains. In its worked example, 88.81% availability, 86.11% performance and 97.80% quality give an OEE of 74.79%.
Plants still differ on what counts as planned downtime, which ideal cycle time to use and whether rework counts as good output. So write those choices down for each KPI.
First pass yield is good units on the first attempt divided by units started.Scrap rate is scrapped units or cost divided by total output, on one agreed basis.On-time delivery needs a choice of requested or promised date, line or order level, and a rule for partial shipments.Cost per good unit needs agreed cost pools and an agreed period.Reconcile Calculations to Source Records Check produced quantities against MES counts and financial totals against the ledger at an agreed cutoff. Then track missing mappings and duplicate joins as exceptions that someone owns.
Compare Plants With Production Context Product mix, equipment age, process type and planned maintenance all shift KPIs. So a universal OEE target across different processes misleads more than it helps. Instead, compare plants with similar processes, or show the context next to the number.
Data Quality, Governance and OT Security Checks Before Rollout Trust in the numbers and safety on the plant floor both need explicit owners.
Assign Owners for Data and Shared Metrics IT owns pipelines, while operations owns what production data means and finance owns cost validation. Kanerika’s data quality framework and its guide to data governance best practices cover how to set this up.
Protect Plant Operations Use approved read paths, read-only accounts and network separation between control systems and analytics. Analytics should never write back to a control system unless a separate, reviewed design allows it. Also limit query load on production databases.
Monitor Feed Health and Changes Watch for missing data, stale feeds, failed loads and schema changes, especially after upgrades. Each alert needs an owner and a recovery step, because an unowned alert gets ignored.
How to Start With One Decision, Then Scale The 90-day plan below assumes source access and a named business owner are in place. Without them, the first steps take longer.
Pick one decision. Choose a question with a measurable loss, such as late orders or scrap on one line, that today’s reports answer badly.Map the data. List the systems, keys, owners and refresh needs that the question depends on.Build and reconcile. Load the data, model it and check quantities and totals against the ERP before anyone uses it.Pilot with users. One plant and one team use it daily, so their feedback shapes the model.Scale. Add the next KPI or plant when shared definitions and governance are in place.Measure value with finance-approved baselines, and also count the full running cost, including integration, capacity, licenses and support. Kanerika’s article on business intelligence for manufacturing covers the reporting layer in more depth.
Manufacturing Data Analytics and AI AI models also need the same connected, reconciled data as dashboards. Otherwise, a forecasting or anomaly model trained on unmatched records repeats the same errors at scale.
Results come when the data is in order. For example, a US perishable food producer used Kanerika’s AI demand forecasting and production planning. Waste fell by 24% and revenue rose by 14%, according to the food production case study .
AI agents can also read ERP data directly. A UK building products manufacturer used Karl, Kanerika’s data insights agent, to cut inventory reconciliation time by 30%, as the Karl case study reports. Kanerika’s guide to AI in manufacturing covers more use cases.
Datasheet
Manufacturing AI Readiness: Critical Gaps and a Path Forward
Kanerika’s datasheet on the gaps that hold back manufacturing AI and practical ways to improve data, platforms, processes and workforce readiness.
View the Datasheet → How Kanerika Helps Manufacturers Build Analytics Kanerika is a Microsoft Solutions Partner for Data and AI with the Analytics specialization. It builds manufacturing analytics on Microsoft Fabric and Power BI , starting from the ERP and plant data a company already has.
Three SAP systems, one view. A global thermal management manufacturer linked 35+ SAP tables into 50+ KPIs on Fabric and cut reporting time by 60%.QAD across sites. Open Mirroring brought more than 200 QAD tables into Fabric for a global manufacturer. Each site has its own Fabric space.Thousands of metrics governed. A global packaging leader unified SAP, Azure and SQL Server data on Fabric, consolidated 10,000+ metrics and raised data accessibility by 60%.Reporting hours cut. A pharma manufacturer unified Model N, SQL Server and SAP on Fabric and reduced reporting man-hours by 95%.The three SAP systems result comes from the order lifecycle case study . Similarly, the packaging and pharma figures come from the packaging case study and the pharma reporting case study .
Case Study
60% Less Reporting Effort Across 3 SAP Systems on Fabric
A global thermal management manufacturer unified three SAP systems on Microsoft Fabric, linking 35+ tables into 50+ KPIs and cutting reporting time by 60%.
Read the Case Study → Manufacturers can start with an assessment of their sources, KPIs and current reports. Kanerika’s data analytics services and data integration services then cover the build from first pipeline to shared model.
Start With the Decision Your Reports Cannot Answer Manufacturing data analytics pays off when production and business records describe the same orders, batches and assets in the same terms. The platform matters less than the keys, time windows, history and definitions underneath it. Those reconciled records can then feed forecasting, maintenance planning and AI.
Pick one decision that today’s reports answer badly. Then map the records it needs, reconcile them against the ERP and put the result in front of the people who act on it. After that, repeat for the next plant.
Talk to Kanerika
Planning Manufacturing Analytics on ERP and Plant Data?
Kanerika reviews your ERP, MES and plant data sources, the KPIs teams argue about and your current reports, then maps a pilot around one decision.
Talk to Kanerika → Frequently Asked Questions
What is manufacturing data analytics? Manufacturing data analytics is the practice of collecting, joining and analyzing data from production, quality, maintenance, supply chain and finance to improve plant decisions. It combines ERP records with what happened on the line, in the lab and at the customer. Plants use it to reduce scrap and downtime, protect delivery dates and control costs.
What are the four types of manufacturing analytics? The four types are descriptive, diagnostic, predictive and prescriptive analytics. Descriptive shows what happened, such as yesterday’s OEE by line. Diagnostic explains why, such as scrap traced to one supplier lot. Predictive estimates what will happen next, and prescriptive recommends an action, such as moving maintenance into a planned stop.
Which systems supply data for manufacturing analytics? Manufacturing analytics usually draws on five source families. The ERP holds orders, inventory and costs. MES and SCADA record production and downtime. Historians and IoT sensors store process signals. Quality systems and LIMS hold inspections and test results, while supply chain and CRM systems track suppliers, shipments, customer orders and complaints.
How is manufacturing analytics different from business intelligence? Business intelligence usually reports on business systems such as the ERP and CRM. Manufacturing analytics adds plant data from MES, historians, quality and maintenance systems and joins it to those business records. That makes diagnosis and prediction possible, for example linking a defect to process conditions and to the customer orders it affects.
What is an example of manufacturing data analytics? A common example is tracing a failed quality test to its business impact. The analysis links the sample to a batch and supplier lot, and the batch to work orders. Those work orders then link to historian process data and to customer orders. Planners can then see which shipments are at risk.
How is OEE calculated? OEE, or overall equipment effectiveness, is Availability multiplied by Performance multiplied by Quality. Availability covers stops during planned production time. Performance covers running below ideal speed. Quality covers parts that miss standards. Plants should agree how planned downtime, ideal cycle times and rework are counted before comparing OEE across sites.
What makes manufacturing analytics projects stall? Projects stall when records from different systems cannot be matched. Item and order codes differ between ERP and MES, and shifts and ledger periods do not line up. Current-state tables also overwrite history, and plants define KPIs differently. Missing owners for data and actions also slow progress, even when the dashboards themselves work well.
How does predictive analytics work in manufacturing? Predictive analytics uses historical sensor, maintenance and production data to estimate future events such as equipment failure or quality drift. Models learn the patterns that came before past failures, then flag similar patterns early. The predictions need maintenance records and process context to be useful, and engineers should confirm causes before acting.
Can manufacturing analytics work without replacing existing systems? Yes. Manufacturing analytics reads data from existing ERP, MES, historian and quality systems through approved connections and builds a separate analytics layer for reporting and analysis. The source systems keep running as they are. The work goes into extraction, shared keys and models, with read-only access that protects production databases and control systems.
How long does a manufacturing analytics implementation take? The timeline depends on source access, the number of systems involved, data quality and how much history is needed. A first use case on one plant can move quickly once access and a business owner are in place. Multi-plant rollouts take longer because identifiers, calendars and KPI definitions need aligning across sites.
When does a plant need real-time manufacturing analytics? Real-time analytics fits decisions that must happen within minutes. Examples include reacting to a machine state change, a process drift or a quality alarm on the line. Cost, margin and delivery analysis usually work with hourly or daily data. Control actions should stay in the plant’s own control and automation systems.
What role does a data lakehouse play in manufacturing analytics? A data lakehouse stores raw and cleaned manufacturing data in one place and keeps history that source systems often overwrite. It holds both structured ERP tables and high-volume sensor data. Shared models built on the lakehouse let reporting, forecasting and AI use the same reconciled records from one common store.
How can QAD or SAP data be joined with MES and historian data? ERP data first lands in a shared platform through mirroring, change capture or scheduled loads. Cross-reference tables then map ERP items, orders and sites to MES work orders and historian asset tags. Production windows link sensor readings to orders, and reconciliation against ERP totals confirms that the joined data matches the source.
How do Microsoft Fabric and Power BI support manufacturing analytics? Microsoft Fabric stores ERP and plant data in OneLake, keeps databases current through mirroring and captures sensor streams with Real-Time Intelligence. Power BI semantic models then publish shared KPI definitions across plants. Teams still own the source access, shared keys, data quality rules and agreed metric definitions that make the numbers trustworthy.
