Before a quality control dashboard in Power BI can solve anything, plant managers face a problem that the BI articles ranking on this topic tend to skip: the data coming in is already in conflict.
Here is what that looks like in practice. A shift supervisor pulls end-of-day scrap numbers from the Manufacturing Execution System (MES). The quality engineer has a different figure from the Quality Management System (QMS). The floor inspector logged a third set of numbers by hand. All three are measuring the same production run. None of them agree.
In plants running separate MES and QMS systems without a unifying data layer, this is the default state. MES systems capture scrap at the point of production, using machine-level codes that often differ from the defect taxonomy in the QMS. LIMS data, where it exists, adds a third layer of lot-level inspection results that does not reconcile cleanly with either. Manual inspection sheets get entered late, incompletely, or differently depending on who is on shift.
The result is a weekly quality meeting where the first 20 minutes go to arguing about which number is correct rather than deciding what to do about it. That pattern shows up consistently in client engagements before a unified reporting layer is in place.
A quality control dashboard in Power BI does not resolve this by itself. But when it is built correctly, with a data model that pulls from MES, QMS, and ERP into a single, consistently defined set of measures, it creates something a spreadsheet cannot: one number that all teams in the room agree to work from.
That is the transition this article covers.
The 5 KPIs Every Quality Control Dashboard in Power BI Needs and How to Calculate Each One
A quality control dashboard in Power BI should be built around five measurable KPIs. Here is each one defined, with its formula and a note on what it tells a plant manager that the other four do not.
1. Defect Rate
Formula: Defective Units / Total Units Produced
Defect rate is the broadest quality measure. It captures what share of output failed inspection at any stage. Where it earns its value is in the breakdown: defect rate by production line, by product family, or by shift reveals patterns that a plant-wide average hides. A line running 4% defect rate while the plant average sits at 1.8% is a specific, actionable problem. The average alone is not.
2. Scrap Rate
Formula: Scrap Quantity / Total Input Material
Scrap rate differs from defect rate in what it measures: material consumed, not units counted. A unit flagged as defective might be reworked and recovered. Scrap cannot. This makes scrap rate a direct input to raw material cost and margin calculation. In IATF 16949-governed environments, specifically automotive suppliers, scrap rate is a required tracked metric with defined reporting cadences.
3. Rework Percentage
Formula: Units Requiring Rework / Total Units Produced
Rework is frequently invisible in quality reporting because it does not show up as a failure. The product eventually passes. But rework consumes labor hours, delays throughput, and masks underlying process instability. A plant with a 1.5% scrap rate and an 8% rework rate is not performing well. It is performing expensively.
4. First-Pass Yield (FPY)
Formula: Units Passing Inspection Without Rework or Scrap / Total Units Started
FPY is the cleanest single measure of process stability. It captures defect, scrap, and rework in one number: what percentage of units made it through the full process correctly the first time. In ISO 9001 and IATF 16949 quality frameworks, high-performing precision manufacturing processes benchmark above 99% FPY. Plants that begin tracking it for the first time often discover they are running considerably lower, with no prior visibility into why.
5. Cost of Poor Quality (COPQ)
Formula: (Scrap Qty x Material Cost per Unit) + (Rework Hours x Labor Rate) + External Failure Costs
COPQ translates the four operational KPIs above into financial terms. This is the figure that gets a CFO’s attention. According to ASQ, poor quality costs manufacturers between 5% and 20% of annual revenue depending on industry and process maturity. The Power BI model makes it possible to see that cost broken down by product line, defect type, and shift, not as a single annual estimate, but as a live, filterable number.
One practical constraint: COPQ is only as accurate as the cost data feeding it. If ERP standard costs are outdated or labor rates are not mapped to work centers, the figure will understate actual loss. Verify both before publishing COPQ to a leadership dashboard.
How to Track Scrap Rate in Power BI: Data Model, Source Connections, and DAX
Scrap rate is the most commonly tracked quality KPI in Power BI manufacturing dashboards. It is also the most commonly miscalculated one, usually because the data feeding it comes from more than one system with more than one definition of what “scrap” means.
The Data Sources
Three or four systems hold quality-relevant data in a typical manufacturing plant:
- MES (Manufacturing Execution System): Production order output, scrap quantities, scrap codes, operator and shift identifiers, and work center assignments. This is the most granular source and usually the first one to pull.
- QMS (Quality Management System): Non-conformance records, inspection results, and disposition decisions (scrap vs. rework vs. accept). Under ISO 9001 and IATF 16949 requirements, non-conformance records must link to specific production lots and corrective actions, which makes them essential for traceability in the data model.
- ERP: Standard material costs, labor rates by work center, and finished goods cost structures. Required for COPQ calculation.
- LIMS (Laboratory Information Management System): In food, pharmaceutical, and chemical manufacturing, LIMS holds lot-level test results that feed directly into FPY calculations.
The standard integration pattern is to extract each source into a staging layer – Azure Data Factory, Power BI Dataflows, or flat-file imports depending on your infrastructure – and build the Power BI data model on top of that layer rather than querying source systems directly.
Data Model Structure
The core model for a quality dashboard follows a star schema:
- Fact table: Quality Events – one row per scrap transaction, non-conformance record, or inspection result, with quantities, codes, timestamps, and cost fields
- Dimension tables: Product (SKU, family, specification), Production Line, Work Center, Shift, Date, Defect Code, Operator (where tracked)
The scrap rate measure then runs across this model cleanly, filtered by any combination of those dimensions.
Key DAX Measures
Scrap Rate % =
DIVIDE(SUM(QualityEvents[ScrapQty]), SUM(QualityEvents[InputQty]), 0)
Defect Rate % =
DIVIDE(SUM(QualityEvents[DefectiveUnits]), SUM(QualityEvents[TotalUnits]), 0)
Rework % =
DIVIDE(SUM(QualityEvents[ReworkUnits]), SUM(QualityEvents[TotalUnits]), 0)
First Pass Yield % =
DIVIDE(
SUM(QualityEvents[TotalUnits])
- SUM(QualityEvents[DefectiveUnits])
- SUM(QualityEvents[ReworkUnits]),
SUM(QualityEvents[TotalUnits]),
0
)
COPQ ($) =
(SUM(QualityEvents[ScrapQty]) * AVERAGE(Products[MaterialCostPerUnit]))
+ (SUM(QualityEvents[ReworkHours]) * AVERAGE(WorkCenters[LaborRate]))Column names above are representative. Match them to your actual table schema before deploying.
One constraint worth naming before going live
If scrap codes are entered inconsistently across shifts – different codes for the same defect type, or entries logged the following morning – the Scrap Rate measure will be technically correct but operationally misleading. The fix is not a DAX workaround. It is a governance conversation about scrap code taxonomy and entry discipline before the dashboard is published.
Row-level security should also be configured from the start: shift supervisors see their own line data, quality managers see all lines, and plant directors see plant-wide aggregates. This is not optional if the dashboard will be used in performance conversations.
Dashboard Design for Quality Control: What Plant Managers Actually Need to See
A quality control dashboard in Power BI is built in a data model. It gets used in a meeting room or on a tablet. That gap is where dashboards tend to fail, and it is usually a design decision, not a data problem.
The following principles come from building quality reporting tools for plant managers rather than for analysts.
The five-second test
Open the dashboard. In five seconds, can you tell whether quality is on track or drifting? If not, the layout is wrong. The first thing visible should be headline KPI cards: scrap rate %, FPY %, COPQ this month. Each card should show the current value, the target, and a direction indicator. Green, amber, red. No decoding required.
Slice by what drives decisions
The filters that drive the clearest decisions on a quality dashboard are not date pickers. They are:
- By production line (where is the problem?)
- By product or SKU (what is the problem on?)
- By shift (who was running when the problem appeared?)
- By defect or scrap code (what type of failure?)
These four dimensions cover the first question a plant manager asks in a quality review. The dashboard should answer all four without a second click.
Pareto chart as a first-page visual
A Pareto chart of defect types, ranked by frequency or by cost, belongs on page one, not buried in a report tab. In practice, two or three scrap codes account for the bulk of quality loss in any given period. Making that visible immediately directs attention to where it belongs. The Pareto chart is one of the most searched quality visualization types in Power BI for manufacturing, and it earns its place every time.
Drill-through to batch or production order
The ability to right-click a data point and drill through to the underlying production orders or lot records is what separates a monitoring tool from an investigation tool. A plant manager who sees a scrap rate spike on Line 3 on Tuesday should be able to click through to the specific batches, the operator on shift, and the scrap codes logged, all without leaving Power BI. In our experience, this drill-through path is the feature plant managers reference first when describing what changed after a dashboard rollout.
Keep the layout calm
One page for the quality summary view. A second page for Pareto and defect-type analysis. A third for drill-through detail. Anything beyond that is a signal the dashboard is trying to serve too many roles at once.
Real-World Example: How Sub-Zero Reduced Scrap with Power BI Quality Reporting
The principles above are not theoretical. Simple BI applied them in a quality control reporting engagement with Sub-Zero, the premium appliance manufacturer known for tight production tolerances and multi-line complexity.
Before the engagement, Sub-Zero’s quality reporting relied on disconnected systems. Data from production and quality inspection processes lived in separate tools, and building a consolidated view required manual effort across multiple sources. The lag between data entry and usable reporting made it difficult to identify quality issues in time to intervene before they affected output or cost.
Simple BI built a Power BI quality reporting solution that unified Sub-Zero’s production and quality data into a single model. The dashboard gave quality managers and plant supervisors a consolidated view of quality performance across production, with the ability to filter by product, line, and time period, and to drill into specific events at the batch level.
The result was a measurable shift in how Sub-Zero’s teams used quality data: from reporting what had already happened to acting on what was happening. [Read the full case study: How Simple BI Helped Sub-Zero Transform Quality Control Reporting with Power BI.]
That outcome, moving from delayed and disputed quality reports to a dashboard the whole team works from, is the specific problem this type of engagement is built to solve. The scrap rate tracking and drill-through design described in the sections above reflect the same structure used in Sub-Zero’s build.
From “Arguing About Scrap Numbers” to a Single Trusted Source
When a plant manager can point to one number, a scrap rate or FPY figure that the quality, operations, and finance teams all accept as accurate, the quality meeting changes shape.
It does not guarantee a better process. But it removes a specific category of waste: the time and friction spent disputing which system’s figure is the real one before any conversation about root cause can begin.
Getting there requires two things, not one.
The first is the technical layer: a Power BI data model that pulls from MES, QMS, and ERP with consistent definitions, clean joins, and row-level security configured so each user sees the data relevant to their scope. The second is a process agreement on the plant floor. Who owns the scrap code taxonomy? What counts as scrap versus rework? What is the entry deadline for each shift? The data model enforces the definitions. Whether those definitions hold depends on the process discipline behind the data entry, and that is a conversation that has to happen before the dashboard goes live, not after it.
If your plant is at the stage where quality reporting still involves pulling numbers from three different places before a weekly meeting, the groundwork described in our manufacturing data integration post is a useful first step before building the quality dashboard layer on top.
FAQ: Quality Control Dashboards in Power BI
What KPIs should a quality control dashboard in Power BI include?
At minimum: scrap rate, defect rate, rework percentage, first-pass yield, and cost of poor quality (COPQ). Each targets a different dimension of quality performance. FPY and scrap rate tend to drive the clearest shift-level decisions because they are measurable within a single production run.
How do you calculate scrap rate in Power BI using DAX?
Scrap Rate % = DIVIDE(SUM(QualityEvents[ScrapQty]), SUM(QualityEvents[InputQty]), 0)The key is a fact table where scrap quantities and input quantities share the same production order reference. Without that join, the measure double-counts across source systems and becomes unreliable.
What is the difference between scrap rate and defect rate in manufacturing?
Scrap rate measures material loss as a share of total input material, specifically units or weight that cannot be recovered. Defect rate measures the share of units that failed inspection, regardless of whether they were scrapped or reworked. A plant can show a low scrap rate and a high defect rate simultaneously if rework is absorbing the failures.
How do you connect a MES to Power BI for quality reporting?
The standard approach is to extract MES data into a staging layer (Azure Data Factory or Power BI Dataflows), join it with QMS and ERP data there, and build the Power BI semantic model on top of that layer. Direct query from MES is possible but creates performance and governance problems in production environments.
What is Cost of Poor Quality (COPQ) and how is it tracked in Power BI?
COPQ converts scrap quantities and rework hours into a dollar figure using material costs and labor rates sourced from ERP. The formula is: (Scrap Qty x Material Cost) + (Rework Hours x Labor Rate) + any logged external failure costs. When mapped to a Power BI model with the correct dimension tables, COPQ becomes a filterable, live number rather than a quarterly estimate.
Next Step: Turn Your Quality Data Into a Dashboard That Works
If your plant has quality data sitting in a MES, QMS, or ERP system that no one fully trusts, the problem is rarely the data itself. It is the absence of a structure that ties the sources together with consistent definitions.
Simple BI builds quality control dashboards in Power BI for manufacturers, connecting your existing MES, QMS, and ERP data into a reporting model that gives quality managers, shift supervisors, and plant directors the same accurate numbers at the same time.
In a 30-minute discovery call, we review your current data sources and show you what a quality dashboard can realistically be built on, using your actual systems and your actual data.
