OEE for Knowledge Work: Measuring What Actually Matters

In manufacturing, there's a metric that cuts through the noise and tells you exactly how well your equipment is performing: Overall Equipment Effectiveness (OEE). It multiplies three factors, availability, performance, and quality, into a single number that reveals where time and capacity are actually being lost.

World-class manufacturers target 85% OEE. Most real-world factories operate between 40% and 60%. The gap between those numbers represents enormous hidden capacity that's being consumed by downtime, slow cycles, and defects.

But here's the interesting question: can this thinking be applied to knowledge work? Not the formula literally, you can't measure a software team's "cycle time per unit" the same way you measure a CNC machine. But the underlying framework, decomposing effectiveness into distinct loss categories and measuring each one, transfers surprisingly well.

How OEE Works in Manufacturing

The formula is simple:

OEE = Availability x Performance x Quality

Each component captures a different type of loss:

Availability measures the proportion of scheduled time that the equipment is actually running. Losses come from unplanned stops (breakdowns, material shortages) and planned stops (setup, changeovers, maintenance). If a machine is scheduled for 8 hours but only runs for 6, availability is 75%.

Performance measures how fast the equipment runs compared to its theoretical maximum. Losses come from small stops (jams, sensor trips, minor adjustments) and reduced speed (worn tooling, suboptimal settings). If the machine should produce 100 units per hour but averages 80, performance is 80%.

Quality measures the proportion of output that meets specification. Losses come from process defects (scrap, rework) and startup rejects (waste produced during warm-up or calibration). If 95 out of 100 units pass inspection, quality is 95%.

Multiply them: 75% x 80% x 95% = 57% OEE. That means 43% of the machine's potential capacity is being consumed by various losses.

Real-World Numbers

In a manufacturing department we analysed, the overall OEE was 47%, well below the 85% world-class benchmark. The breakdown was revealing:

  • Availability: 54% (the biggest problem, nearly half the scheduled time lost to stops)
  • Performance: 87% (reasonable, machines ran close to speed when running)
  • Quality: 99% (excellent, almost no defects)

Without the OEE decomposition, management might have focused on quality (which was already excellent) or speed (which was fine). The data showed that the real leverage was in availability: reducing downtime. Some machines ran at 10-14% OEE simply because they spent most of their scheduled time stopped.

This is the power of OEE: it prevents you from optimising the wrong thing.

Translating to Knowledge Work

Knowledge work doesn't have machines, cycle times, or unit counts in the same way. But it has analogous losses:

Availability losses in knowledge work:

  • Context switching between projects (the setup/changeover equivalent)
  • Waiting for decisions, approvals, or information from others
  • Meetings that could have been emails
  • Environment issues (tools not working, access not granted, blocked by dependencies)
  • Unplanned interruptions (urgent requests that derail planned work)

Performance losses in knowledge work:

  • Working on the wrong thing (effort that doesn't contribute to the goal)
  • Unclear requirements that slow progress
  • Technical debt that makes every change take longer than it should
  • Suboptimal tools or processes that add friction
  • Multitasking that reduces effective throughput on everything

Quality losses in knowledge work:

  • Rework due to misunderstood requirements
  • Bugs and defects that require fixing
  • Deliverables that don't meet the standard and need revision
  • Decisions that get reversed because the analysis was incomplete

What Would a Knowledge Work OEE Look Like?

You can't calculate a precise percentage the way you can for a machine. But you can ask the OEE questions:

Availability question: Of the time scheduled for productive work, how much is actually available for focused, uninterrupted work? If your team has 40 hours per week but spends 15 in meetings, 5 waiting for decisions, and 3 dealing with tool issues, availability is roughly 42%.

Performance question: Of the available focused time, how much is spent on work that directly contributes to the current priority? If half of the remaining time goes to context switching, email, and low-value tasks, performance is 50%.

Quality question: Of the work completed, how much is done right the first time? If 20% of deliverables require significant rework, quality is 80%.

Multiply them: 42% x 50% x 80% = 17%. That's a provocative number. It suggests that for every 40-hour week, less than 7 hours produce final-quality output on the right priorities.

The exact numbers are debatable. But the framework is valuable because it forces you to categorise losses rather than just feeling "busy but not productive."

The Six Big Losses, Adapted

Manufacturing's Six Big Losses map to knowledge work patterns:

Manufacturing Loss Knowledge Work Equivalent
Equipment failure System outages, broken tools, access issues
Setup and adjustments Context switching, onboarding to new project
Idling and minor stops Waiting for input, blocked by dependencies
Reduced speed Technical debt, unclear requirements, poor tooling
Process defects Rework, bugs, rejected deliverables
Startup rejects Learning curve waste on new projects, false starts

Making It Practical

You don't need to calculate a precise OEE number for your knowledge work team. But you can use the framework to:

Identify the dominant loss category. Is your team primarily losing time to availability (too many meetings, too much waiting), performance (working on wrong things, too much friction), or quality (too much rework)? The intervention is different for each.

Stop optimising the wrong thing. Just like the factory where quality was 99% but availability was 54%, your team might be investing in code review rigour (quality) when the real problem is context switching (availability).

Make invisible losses visible. Most knowledge work losses are invisible because no one tracks them. You don't get a red light when a developer spends 2 hours waiting for a design review. You don't hear an alarm when a consultant reworks a deliverable for the third time. Making these losses visible is the first step to reducing them.

Set realistic expectations. If your team's effective OEE is 20-30% (which is common), expecting 40 hours of output per 40-hour week is unrealistic. Understanding where the capacity goes helps set honest expectations and focus improvement efforts.

The goal isn't to reach 100%. Even world-class manufacturers don't achieve that. The goal is to understand where your capacity goes, focus improvement on the biggest losses, and gradually shift the balance from waste to value.

Our Experience With This

We have measured OEE on real machines, including the CNC department analysis described in this article. That experience of decomposing losses into availability, performance, and quality categories is now something we bring to software teams and knowledge work processes. At TaiGHT, we combine industrial measurement discipline with the ability to build the dashboards and tools that make these losses visible, using .NET and modern web frameworks.

If you suspect your team's effective throughput is far lower than the hours suggest, and you want to understand where the capacity actually goes, that is a conversation we are well-equipped for.


This article draws on the OEE framework and the following sources.

References

  • Nakajima, S. (1988). Introduction to TPM: Total Productive Maintenance. Productivity Press.
  • Hansen, R.C. (2001). Overall Equipment Effectiveness: A Powerful Production/Maintenance Tool for Increased Profits. Industrial Press.
  • DeMarco, T. & Lister, T. (2013). Peopleware: Productive Projects and Teams (3rd ed.). Addison-Wesley.