The 12 Manufacturing KPIs That Matter for a 10–20 Machine Factory
A 10-20 machine factory can lose 20-30% of throughput to downtime, speed losses, scrap, and plan-vs-actual gaps without manufacturing KPI dashboards. The hard part is knowing which loss is happening while there is still time to act.
Excel plans may show the order, target, and staffing plan. The shop floor shows machine states, downtime reasons, production targets, and scrap reasons, often too late if data is collected after the shift. This guide focuses on 12 manufacturing KPIs that help production managers connect daily work with actual output. The goal is a practical KPI set, not a long metric dump.
To see live machine status and plan-vs-actual tracking in action, try the free demo with no financial commitment.
Which Manufacturing KPIs Actually Matter?
The useful KPIs are the ones that explain four problems: lost time, lost speed, lost quality, and delivery risk. If a KPI does not help a team find or reduce one of those losses, it probably belongs outside the first dashboard. Use this lens to group the 12 KPIs:
Effectiveness KPIs: OEE, TEEP, Availability, Performance, and First Pass Yield or Quality show how much productive capacity is actually being used.
Reliability KPIs: MTBF and MTTR show how often machines fail and how long recovery takes.
Downtime KPIs: Planned and Unplanned Downtime Hours and Top Stop Reasons show where production time disappears during a shift.
Output and delivery KPIs: Throughput, On-Time Delivery, and Scrap Rate connect shop floor performance to orders, customer promises, and margin.
Start with the KPI group that matches the current production constraint. A factory missing order dates needs delivery and throughput visibility, while a line with repeated stops needs downtime and reliability data first.
What Is a Manufacturing Dashboard?
A manufacturing dashboard is a live view of production performance. It brings machine signals, operator input, targets, stops, and quality data into one place so teams can see what is happening now. A useful OEE dashboard should show:
Live machine status: running, stopped, idle, changeover, or another state agreed by the team.
Target progress: actual output compared with the shift target, order target, or planned run rate.
Active stops: which machine is stopped now, how long the stop has lasted, and whether help is needed.
Downtime reasons: operator-selected reasons such as material shortage, tool change, breakdown, or waiting for approval.
Scrap and reject reasons: the quality losses that reduce saleable output.
Role views: operators, supervisors, maintenance, planners, and managers see the information they need for their work.
For a production manager, the dashboard routine is simple: check live machine status, compare output with the shift target, then act on active stops before the shift ends. The formulas along with downtime analysis come later. First, the dashboard needs trusted source data from machines and operators, because clean KPI charts depend on accurate shop floor events.
Effectiveness KPIs
Effectiveness KPIs show how much useful production a factory gets from the time, machines, and materials already available.
Use these KPIs together. OEE shows the main effectiveness score, while TEEP, Availability, Performance, and First Pass Yield explain where the losses sit.
1. OEE
Overall Equipment Effectiveness, or OEE, is the main score for how effectively a machine turns planned production time into good output.
For example, a machine with 87.5% Availability, 85% Performance, and 90% Quality has an OEE of about 66.9%.
Read the single OEE percentage as a starting point, not the full answer. A factory can have the same OEE score for very different reasons:
Low Availability: The machine loses time through failures, changeovers, waiting, or missing materials.
Low Performance: The machine runs, but slower than its ideal cycle time or with frequent micro-stops.
Low Quality: The machine produces scrap or rework, so output cannot be counted as good production.
GlobalReader is useful here because machine signals capture running state and output, while operator input explains downtime reasons. That combination helps teams separate the score from the causes behind the score.
2. TEEP
Total Effective Equipment Performance, or TEEP, shows how much of a machine's total available calendar time becomes good production.
OEE looks inside scheduled production time. TEEP adds the question of whether the factory is using the machine enough in the first place.
That makes TEEP useful for a 10-20 machine factory comparing planned capacity with actual use.
A line may have acceptable OEE during scheduled shifts but still leave capacity unused during evenings, weekends, or idle machine time.
Example:
Total calendar time: 1,440 minutes in a day
Planned production time: 480 minutes for one shift
Utilization: 480 / 1,440 = 33.3%
OEE during the shift: 70%
TEEP: 33.3% × 70% = 23.3%
TEEP helps leaders discuss hidden capacity without immediately buying more machines. The answer might be better scheduling, fewer changeovers, extra shifts, or moving work to an underused asset.
3. Availability
Availability is the ratio of actual operating time to planned production time, expressed as a percentage.
Operating Time is planned production time minus downtime inside the scheduled window. Planned Production Time excludes pre-planned breaks that the machine was never expected to run through.
Example for one 8-hour shift:
Planned Production Time: 480 minutes
Downtime recorded: 60 minutes
Downtime split: 45 minutes unplanned failure, 15 minutes changeover
Operating Time: 420 minutes
Availability: 420 / 480 × 100 = 87.5%
Benchmarks only help when teams calculate them consistently. Treat high OEE and high Availability targets as goals to compare against your own baseline, not as context-free pass or fail numbers.
Low Availability usually points to recurring failures, long changeovers, waiting time, or late response to stops. Fixing Availability starts with clean downtime reasons, not just a lower target on a report.
4. Performance
Performance measures actual production speed against the theoretical maximum speed during available running time. Maximum Possible Output should come from the machine's ideal cycle time or engineering specification. Historical averages can hide losses because past slow running gets treated as normal.
Actual Output counts units produced during available time, including output made at reduced speed.
Performance losses usually come from three places:
Micro-stoppages: Short pauses that interrupt rhythm but may not trigger a formal downtime log.
Slow cycles: The machine runs below ideal speed because of worn tooling, cautious settings, material issues, or operator adjustments.
Start-up and restart losses: The machine runs inconsistently after a stop, product change, or adjustment.
Micro-stops and slow cycles can create a hidden productivity drain. These losses are easy to miss because the machine still looks like it is running.
Worked example:
Theoretical maximum output: 1,000 units per shift
Actual output: 850 units
Performance: 850 / 1,000 × 100 = 85%
An 85% Performance score means the machine produced 150 fewer units than its ideal running speed allowed during available time.
5. First Pass Yield / Quality
First Pass Yield, or FPY, is the percentage of units produced to specification on the first pass, without rework or scrap. FPY is closely related to the Quality component in OEE. Quality asks how much output is good output, while FPY adds pressure by excluding units that needed rework.
Two loss types reduce FPY:
Scrap units: Parts that cannot be recovered and must be discarded.
Reworked units: Parts that need extra processing before meeting specification.
A low FPY usually signals process instability, not just bad parts. Equipment running outside spec, inconsistent setup, material variation, or unclear operator instructions can all show up as lower first-pass quality.
Track FPY beside scrap rate and OEE Quality. Together, they show whether output is increasing because the process improved or because teams are spending more time correcting defects.
Reliability KPIs
Reliability KPIs show whether machines can keep running between failures and how quickly maintenance can restore production after a breakdown.
For a 10-20 machine factory, start with MTBF and MTTR. They connect maintenance work directly to availability, OEE, and daily output.
6. MTBF and 7. MTTR
MTBF means Mean Time Between Failures. It measures average operating time between breakdowns. MTTR means Mean Time To Repair. It measures average repair time from failure start to production-ready status.
MTBF is mainly affected by preventive maintenance, lubrication schedules, component age, and whether machines are running past service intervals.
MTTR is mainly affected by spare parts availability, fault diagnosis speed, technician skill, and how quickly the right person sees the stop.
Track averages per machine, line, or asset group. Blending old machines, new machines, and different duty cycles into one number hides the equipment that needs attention.
Rising MTBF usually means failures are becoming less frequent, often because maintenance routines are catching issues earlier.
Falling MTBF can show worn components, poor lubrication, harsh running conditions, or skipped inspections.
High MTTR means recovery is too slow, even if failures are rare.
Low MTTR with falling MTBF means maintenance is reacting quickly, but the root cause is still repeating.
A machine that fails once a month but takes 8 hours to repair can hurt delivery more than a machine with short, frequent resets. Practical downtime tracking needs clean timestamps, not memory. Record when the failure starts, when maintenance is notified, when repair work starts, and when the machine is ready to run again.
Set the rules before the dashboard goes live:
Define a failure. Separate breakdowns from planned stops, changeovers, cleaning, and waiting for material.
Use consistent machine states. Running, stopped, planned stop, fault, setup, and idle should mean the same thing across shifts.
Connect stop reasons to repairs. A fault code without a reason tells you that time was lost, but not what to fix.
Review repeat failures weekly. MTBF only improves when recurring faults become maintenance actions, parts changes, or process changes.
The goal is simple: make reliability visible early enough that maintenance can prevent the next stop, not just explain the last one.
Downtime KPIs
Downtime KPIs show how many planned production hours were lost and which stop reasons caused the loss. OEE availability gives the percentage. Downtime hours and stop reasons show the actual minutes, machines, and causes that production and maintenance can act on.
8. Unplanned Downtime Hours and 9. Top Stop Reasons
Unplanned downtime hours is the total time lost to unexpected stops during planned production.
Top stop reasons is the ranked list of causes behind those stops, such as breakdowns, material waiting, setup overrun, operator callouts, quality checks, or tool issues.
Use a simple formula:
Unplanned downtime hours = total duration of unplanned stops during planned production time.
Downtime cost = lost output value + idle labour + recovery costs.
Top stop reasons = stop duration grouped by reason, then ranked from largest loss to smallest loss.
Balti Spoon showed why this matters. On one major production line, a stopped machine costs about €1,000 per hour.
Manual logs also understated stops. A stop that felt like 5 minutes could become 15 minutes once digital monitoring captured the actual duration.
Digital monitoring exposed 5-8 hours per week of invisible working-hour differences between similar lines. The dashboard turned a vague productivity gap into a measurable loss.
Set up the dashboard in this order:
Machine states. Define running, stopped, idle, setup, planned stop, and fault so the system can measure time correctly.
Downtime reasons. Give operators a short, clear reason list so every stop has context.
Targets. Set machine and product-specific targets so a slow product mix is not confused with a slow machine.
Scrap reasons. Track quality loss next to downtime, because rejected output can hide inside apparently good running time.
Top stop reasons turn downtime from a total number into an action list. A weekly Pareto chart usually shows which few causes deserve the first improvement meeting.
Use the ranking to split work between teams:
Maintenance owns repeat mechanical or electrical failures. These should feed inspections, spare-parts planning, and repair standards.
Production owns setup overruns and operator process issues. These should feed training, standard work, and shift handover checks.
Planning owns waiting time. Material shortages, missing instructions, and unrealistic schedules should show up as visible stop categories.
Quality owns scrap-linked stops. A machine can be technically available while producing rejects that still cost output.
Balti Spoon’s dashboard also separated product speed from machine speed. Product-by-product targets showed whether a slower result came from the order mix or from a real machine problem.
Review downtime hours daily and stop reasons weekly. Daily review catches urgent losses, while weekly review gives enough data to choose root-cause work instead of chasing every stop.
Output and Delivery KPIs
Where effectiveness KPIs measure how well machines run, output and delivery KPIs measure what actually leaves the factory floor. Throughput, on-time delivery, and scrap rate connect daily production to customer demand.
10. Throughput, 11. On-Time Delivery, and 12. Scrap Rate
Throughput measures production volume, on-time delivery measures schedule performance, and scrap rate measures waste. Together, they show whether the factory is producing enough good parts at the promised time.
Use these KPIs as a set, not as three separate numbers:
Output plus downtime: Shows whether low throughput came from machine stops, slow cycles, or missing labour.
Plan vs actual plus cycle time: Shows whether the plan was realistic for the product, order, machine, and shift.
Scrap plus product or order: Shows whether waste is tied to a specific job, material, setup, or process condition.
Throughput is the number of units produced in a set period. Many factories track it as parts per hour, units per shift, or completed orders per day.
Formula:
Throughput = Total units produced / Time available
Throughput is useful because it keeps the conversation concrete. If Line 3 made 420 parts in 7 hours, the team can compare that output against the plan, expected cycle time, and downtime record.
A throughput number by itself can mislead. A shift may hit the total output target while running too much overtime, producing too much scrap, or delaying another customer order.
Action example: If throughput drops, check downtime reasons and cycle time before adding people or machines. The issue may be micro-stops, changeover delay, or a product that runs slower than the standard.
On-time delivery measures the share of customer orders or production runs completed by the scheduled due date. It connects shop floor performance to customer promises.
Formula:
On-time delivery = (Orders delivered on time / Total orders) x 100
Plan vs actual makes on-time delivery easier to manage. If a job is planned for 6 hours but the live cycle time points to 8 hours, supervisors can adjust staffing, sequence, or customer communication earlier.
GlobalReader Planner is a natural fit here because it compares planned production with real machine progress. Analytics can show whether downtime, speed loss, or quality loss caused the gap.
Scrap rate is the percentage of total output that fails quality standards and cannot be reused or reworked. It is one of the clearest ways to see material and margin loss.
Formula:
Scrap rate = (Total scrap units / Total units produced) x 100
Scrap becomes more useful when the dashboard connects scrap to the product, order, machine, and shift. A factory does not just need to know that scrap increased.
The team needs to know where to look first:
Product: One SKU may have a tighter tolerance or harder setup.
Order: One batch may have bad material or a rushed changeover.
Machine: One asset may drift after warm-up or maintenance.
Shift: One team may need clearer instructions or operator training.
With GlobalReader, Analytics can track OEE quality, Operator can capture scrap reasons, and Smart Factory can help connect production data to wider business systems. The cost of quality might be quite hurtful.
Key takeaway: Total output tells you what happened. Output with downtime, plan vs actual, cycle time, and scrap context tells you what to fix next.
From KPI List to KPI Dashboard
A KPI dashboard starts with definitions, not screens. Confirm the KPI formula, map each data source, normalize machine feeds, test one production cell for 30-60 days, then publish views by role.
| Step | Action | Output |
|---|---|---|
| 1.Confirm formulas and sources | Define each KPI calculation and connect it to a machine, ERP, or operator input source | Data source map per KPI |
| 2.Normalize feeds | Standardize PLC output, sensor signals, ERP records, and manual entries into one collection layer | Clean, uniform data stream |
| 3.Pilot one cell | Test the dashboard for 30–60 days on a cell with known visibility gaps | Validated dashboard accuracy |
| 4.Publish role views | Build separate views for operators and production managers | Role-appropriate live dashboards |
Use the table as a rollout sequence. Each step should create something the next step can use, so the dashboard grows from confirmed data instead of assumptions.
1. Confirm formulas and sources
Start with a simple data source map for your 10-20 machines. For each KPI, write the exact formula, the machine or ERP field behind it, and who owns the definition.
A practical map should answer:
Machine state: Which signal shows running, stopped, idle, or changeover status?
Production target: Which ERP or planning record holds the order, product, and shift target?
Operator input: Which screen captures downtime reason, scrap reason, or setup completion?
Temporary gaps: Which KPI needs manual entry until a machine feed is connected?
Use one KPI definition across every machine. If OEE is availability x performance x quality on Line 1, the same formula must be used on Line 2.
2. Normalize feeds before building charts
Machines from different eras rarely speak the same data language. Normalize PLC outputs, sensor signals, ERP records, and operator entries into one collection layer before building dashboard widgets.
For older equipment, retrofit hardware can capture machine states and counts when direct controller data is limited. In GlobalReader, Analytics combines machine signals and operator input into OEE, interruption data, production statistics, and shift details.
3. Run a 30-60 day pilot on one cell
Choose a cell with recurring stops, missed shift targets, or disputed downtime reasons. The pilot should prove whether the dashboard matches what operators and managers see on the floor.
During the pilot, follow the production manager's daily workflow:
Check live machine status.
Compare output with the shift target.
Review active stops and downtime reasons.
Decide whether to call maintenance, adjust the plan, or move people to the bottleneck.
Use the pilot to clean up data rules. If operators choose different stop reasons for the same issue, simplify the reason list and train the team again.
Tools like Operator help capture stop reasons and prompts at the machine, while Planner helps compare planned work with actual progress.
4. Publish role-specific views
Avoid giving every user the same dashboard. Operators need a live working screen; production managers need a decision screen.
| Role | Dashboard should show | Main decision |
|---|---|---|
| Operators | Live target, machine status, current order, stop reason prompts, and scrap prompts | What should I run now, and what reason should I log if the machine stops? |
| Production managers | Shift performance, bottlenecks, plan vs actual, OEE losses, and active stops | Where is output slipping, and what action should I take before shift ends? |
If the dashboard is shown on shop floor screens, keep the live view narrow. Machine status, target progress, and active stops matter more than a full management report.
Keep the first version practical. A dashboard that makes downtime, targets, and active stops clear for operators and production managers is more useful than a broad screen no one trusts.
KPI Standards in Plain Language: What ISO 22400 Defines
ISO 22400 gives factories a shared language for manufacturing KPIs. The standard defines terms and formulas for OEE, availability, performance, quality, cycle time, and production rate.
That matters when you compare one machine, shift, line, or site against another. A 78% OEE score only means something if each team calculates availability, speed loss, and scrap the same way.
Without standard definitions, KPI meetings turn into debates about the numbers. With ISO 22400, teams can spend more time asking why losses happened and less time arguing about the calculation.
| KPI | Plain-language meaning | Why the standard helps |
|---|---|---|
| OEE | How much good output a machine makes during planned production time. | Keeps availability, performance, and quality tied together instead of treated as separate opinions. |
| Availability | How much planned time the machine was actually running. | Makes downtime and changeover losses comparable across shifts and machines. |
| Performance | How close actual running speed is to the expected cycle time. | Separates slow cycles and micro-stops from full downtime. |
| Quality | How much output is good without scrap or rework. | Keeps defect tracking linked to actual production, product, and order data. |
| Cycle time | How long one unit, batch, or operation takes in reality. | Helps planners compare planned rates against actual shop floor speed. |
| Production rate | How much output is produced in a defined time period. | Gives managers a common output measure across equipment types. |
The goal is consistency. Once KPI definitions are stable, a production manager can compare Line 2 on Monday with Line 4 on Friday without changing the rules halfway through.
Don’t Track Everything: The Start-With-Three Rule for SMEs
A small-to-mid factory does not need a 20-metric dashboard on day one. A 10-20 machine plant needs the first dashboard to show where output is being lost and why.
Start with 3 KPI groups:
OEE with downtime reasons: OEE is useful, but the percentage alone does not tell the team what to fix after a stop, slow cycle, or quality loss.
Plan vs actual with cycle time: Compare the target schedule with actual run time, completion time, and cycle time so planners can see where estimates break.
Scrap tied to product or order: Track scrap against the product, batch, or order so quality losses show up where costing and delivery decisions happen.
The first dashboard setup should capture 4 basics:
Machine states: running, stopped, idle, changeover, or planned maintenance.
Downtime reasons: breakdown, missing material, setup, waiting for operator, quality check, or another agreed reason code.
Production targets: planned quantity, expected cycle time, shift target, and order target.
Scrap reasons: defect type, rework reason, product, order, and shift.
Keep the first setup practical. If operators cannot record a stop reason in the moment, the dashboard becomes another reporting screen instead of a tool for daily decisions.
GlobalReader fits this start-small approach because hardware and Analytics can begin collecting real machine data first. From there, factories can add Operator for downtime reasons, Planner for plan vs actual, Maintenance for service work, or Smart Factory for integrations.
The pricing model is modular and subscription-based, so teams can add features as the dashboard becomes more useful. Try the free demo and see how a simple first dashboard can turn machine signals into better production decisions.
Manufacturing KPI dashboard FAQ
-
Start with 3 KPI groups: machine status and downtime, output against shift target, and quality or scrap. These give production managers enough data to see what is happening and decide what action to take.
Once data quality is stable, expand toward the full 12 manufacturing KPIs. Adding every KPI too early usually creates reporting work before the team trusts the numbers.
-
OEE is useful because it combines availability, performance, and quality into one score. But OEE alone can hide what the team should fix first.
At the start, pair OEE with downtime reasons. A line at 62% OEE matters more when you can see whether the loss came from setup, micro-stops, slow cycles, or scrap.
-
Check live KPIs during the shift so supervisors can react to active stops, slow output, and missed shift targets. Live checks are for action now.
Review daily and weekly KPI trends separately. Daily reviews catch repeated losses from yesterday, while weekly reviews help managers choose larger improvement work.
-
Yes. A no-code manufacturing dashboard means production teams can configure views and KPI templates without writing software code.
Setup still requires production knowledge. Someone must decide which KPIs matter, how stops are categorized, and which machines or work centers appear in each view.
Typical no-code setup includes:
KPI templates: Start with OEE, availability, performance, quality, downtime, output, and scrap.
Dashboard views: Build separate screens for operators, supervisors, planners, and management.
Reason codes: Standardize downtime, scrap, rework, and delayed-start categories before reporting begins.
Collection hardware: Connect machines through sensors, counters, PLC signals, or retrofit devices where needed.
User access: Give operators simple input screens and managers summary views.
No-code does not mean no setup. Deeper ERP integration, custom data mapping, and advanced reporting can still need IT or implementation support.
-
Excel is useful for designing the first KPI framework. Use it to define formulas, targets, owners, and review routines before choosing dashboard software. Excel starts to fail when the dashboard needs to be live.
No machine connection: Excel does not capture counters, stops, speed losses, or cycle signals directly from production equipment.
Manual delay: Operators or supervisors often enter numbers after the shift, when downtime reasons are easier to guess wrong.
Version conflicts: Separate files across departments create different answers for the same production day.
Weak alerts: Excel will not notify maintenance when a stop happens or warn planning when an order falls behind.
Poor scale: Tracking one or two KPIs manually is manageable; tracking several machines across shifts becomes admin work.
A spreadsheet can help you prepare. A live dashboard is needed when teams must react before the shift is over.
-
Start with one machine cell before rolling out the dashboard across the factory. A 30 to 60 day pilot gives you time to catch bad assumptions.
During the pilot, reconcile automated counts against manual shift logs. Check whether cycle times, stop events, scrap counts, and order IDs match what operators see.
Use the pilot to standardize the data rules:
Part IDs: Match part names and numbers between ERP, machines, and dashboard reports.
Reason codes: Use the same downtime and scrap categories across every machine.
Timestamps: Keep machines, dashboards, and reports aligned to the same timezone and shift structure.
Cycle times: Compare planned cycle time with actual run rates before trusting performance scores.
Operator input: Train teams on when to select a reason code, add a note, or call for help.
After go-live, data quality becomes a daily habit. Set alerts for missing signals, unusual counts, undefined interruptions, and outlier cycle times.
Review the first few weeks closely. Small naming errors, duplicated reason codes, and missing timestamps can distort OEE, scrap, and plan-vs-actual reporting.
GlobalReader helps factories move from paper and Excel to live machine data, operator reasons, and plan-vs-actual dashboards. Start the free demo when you want to see it yourself.
