State-based and quantity-based KPIs describe two different ways of measuring performance. In most regulated, brownfield environments you will need both, but they answer different questions and depend on different data and modeling choices.
What are state-based KPIs?
State-based KPIs are built from “time in state.” They measure how long an asset, line, or process step spends in predefined states such as:
- Running / in-cycle / producing
- Setup / changeover
- Planned stop (maintenance, breaks, meetings)
- Unplanned stop (faults, breakdowns, material shortages)
- Starved, blocked, idle, waiting for quality, etc.
Example state-based KPIs include:
- Percent of time running vs. stopped during a shift
- Mean time between failures (MTBF) and mean time to repair (MTTR)
- Share of downtime attributed to specific loss categories
- Changeover time as a percent of available time
These KPIs require reasonably accurate state models and event data, usually from PLCs, SCADA, MES, or an event historian. They are sensitive to how states are defined, how well sensors and logic distinguish those states, and how cleanly events are timestamped and sequenced.
What are quantity-based KPIs?
Quantity-based KPIs are built from “how much” and “how many.” They measure counts, volumes, and rates such as:
- Good units produced per hour or per shift
- Scrap quantity and rework quantity
- Yield, first pass yield, and defect rates
- Backlog, on-time delivery, and throughput
Example quantity-based KPIs include:
- First pass yield (%) for a process step
- Scrap rate by part number or work center
- Throughput (units completed per shift or per day)
- Cost of poor quality (COPQ) summarized by area
These KPIs rely on accurate counting, proper attribution of good vs. bad output, and consistent links to orders, lots, and revisions. Data typically comes from counters in automation, MES production records, QMS nonconformances, and ERP booking data.
How are they different in practice?
In practice, the differences come down to what question each type answers:
- State-based: “What was the equipment or process doing over time, and why?”
- Quantity-based: “What did we produce or lose, and where?”
Key practical differences:
- Data foundation: State-based KPIs depend on state transitions and timestamps; quantity-based KPIs depend on counts and classifications (good, scrap, rework).
- Resolution: State-based metrics often reveal short stops and micro-losses that never show up as quantity changes; quantity-based metrics capture yield and volume impacts even when equipment appears to be running normally.
- Root cause accessibility: State-based KPIs are usually better for identifying causes of downtime and delays. Quantity-based KPIs are better for quantifying quality and output impacts.
- Modeling effort: State-based KPIs require a clear and maintained state model and consistent event logic in PLC/SCADA/MES. Quantity-based KPIs require robust definitions of what counts as produced, accepted, rejected, and reworked, with traceability to orders, lots, and revisions.
When is each type more useful?
State-based KPIs are most useful when you are:
- Looking for hidden capacity by reducing downtime, changeovers, or micro-stops
- Trying to understand interaction between upstream and downstream equipment (starved vs. blocked states)
- Managing maintenance effectiveness and reliability over long asset lifecycles
Quantity-based KPIs are most useful when you are:
- Managing quality performance, scrap, and rework by product or process
- Balancing capacity against customer demand and delivery commitments
- Estimating cost of poor quality or cost of nonproductive time at a financial level
How do state-based and quantity-based KPIs work together?
In regulated, long-lifecycle environments, neither type is sufficient alone. You typically need quantity-based KPIs to size the problem and state-based KPIs to locate the causes. For example:
- Quantity-based KPIs may show a high scrap rate on a product family; state-based KPIs can show that inspection queues and rework are causing extended “waiting for quality” time.
- Quantity-based throughput data may show missed schedule; state-based downtime data can reveal that the losses are dominated by changeover time, not mechanical failures.
Many composite metrics, like OEE, inherently combine both approaches: availability is mostly state-based, while performance and quality use quantity-based data. In brownfield plants, reconciling these inputs across legacy MES, SCADA, and ERP systems often exposes inconsistencies that must be resolved through data governance and validation.
Dependencies and common pitfalls in brownfield environments
Several constraints affect how reliable each KPI type will be:
- Instrumentation limits: Some legacy equipment has minimal or unreliable state signals. For these assets, state-based KPIs may require new sensors, logic changes, or manual event logging, all subject to change control.
- Inconsistent state models: Different lines and vendors often use different names and triggers for similar states (for example, “idle” vs. “starved”). Without harmonization, plant-wide state-based KPIs can be misleading.
- Partial counting: Where counting is manual or only at certain process steps, quantity-based KPIs may not align with state-based utilization data. This is common when ERP booking does not match physical flow.
- Data integration quality: Aligning states and quantities into a single view depends on integrations across MES, SCADA, historians, ERP, and QMS. Gaps or timing mismatches can skew both KPI types and need explicit validation.
- Change control and validation: Changes to state definitions, PLC logic, or counting rules must go through formal change control. Otherwise, historic and current KPIs become non-comparable, which is problematic in regulated environments.
Because of these constraints, a full replacement of existing MES or SCADA solely to “standardize KPIs” is rarely justified in highly regulated plants. The qualification burden, downtime risk, and integration complexity usually outweigh the benefit. A more realistic approach is to:
- Standardize KPI definitions and state models on paper first.
- Map those definitions to current systems and signals, identifying gaps.
- Close gaps incrementally with targeted instrumentation and integration changes, under proper validation and change control.
How to choose and design KPIs in your context
When deciding how to use state-based vs. quantity-based KPIs, consider:
- What decision you need to support (scheduling, maintenance, quality, capital planning).
- What data you already trust from existing systems and what would require non-trivial changes.
- How changes to KPI definitions will be documented, approved, and communicated.
- How you will ensure traceability of KPI inputs over long equipment and product lifecycles.
In most cases, a minimal, stable set of well-defined KPIs using both state-based and quantity-based inputs is more effective than a large dashboard of metrics that are weakly defined or inconsistently implemented across your brownfield environment.