A KaiNexus webinar with Ed Pound, hosted by Mark Graban
Listen to the recording via our podcast:
View the Slides:
Most improvement programs ask people to believe something. Believe in Lean. Believe in Six Sigma. Believe in the new digital initiative. The veterans in the room have seen enough programs come and go that the request for belief lands as fatigue. Here comes another one.
Ed Pound's argument in this session is that the belief problem is a symptom of a deeper one. Operations across every industry suffer from a knowledge gap. On one side of the gap sit solutions that are too complex or technical to hand to the people doing the work -- multivariate optimization of multi-echelon inventory networks, the heavier reaches of Six Sigma statistics. On the other side sit best-practice solutions that get adopted because they worked somewhere else -- Lean, Agile, digital tools deployed because being digitally connected seems like the right thing to do. Between the two sits a missing middle: a shared scientific understanding of how operations actually behave.
Operations science fills that gap. It isn't a program to believe in. It's a body of math and science describing how variability, utilization, flow, and cycle time relate to each other, the same way physics describes what happens when you let go of a ball. The power of it, Ed argues, isn't just that some people have the wrong mental model. It's that people across the same organization hold wildly different mental models of the same basic relationships, and that disagreement alone produces chaos even when everyone is working hard with good intentions.
Ed Pound is Managing Director of the Operations Science Institute and a recognized expert in applying scientific principles to real-world operations. He is the lead author of Factory Physics for Managers and co-author of the forthcoming Applied Operations Science. He spent 16 years at Factory Physics Inc. doing consulting and software work before founding the Operations Science Institute about two years before this session. He has more than 35 years of experience managing, coaching, and training in operations across many industries, countries, and businesses large and small. He holds a bachelor's and a master's of science in mechanical engineering from the University of Alabama and an MBA and an MS in Engineering Management from Northwestern University.
This session was hosted by Mark Graban, then Senior Advisor at KaiNexus.
The name change has a practical origin. For 16 years, Ed worked at Factory Physics Inc., going into operations of all kinds. Every time the work moved outside an actual factory -- a hospital emergency department, an aviation maintenance and overhaul shop -- the same objection came up. We're not a factory. That objection is fair. And "physics" carried its own friction: physics sounds rigorous, which is good, but it also sounds hard, which made some people decide they didn't want to get into it.
Operations science solves both problems. Everyone has operations. A hospital ED, an automobile dealership, a traditional factory -- all of them transform resources to create and distribute goods and services. And people trust science as an objective basis for decisions rather than as one more opinion. The reframe isn't cosmetic. It's the difference between a concept people dismiss and a concept people will engage with.
Ed's working definition: operations science is the study of the transformation of resources to create and distribute goods and services. It focuses on the interaction between demand and transformation -- between demand and supply -- and the variability in either or both. The central question is how to manage variability, because everyone has variability and no one can eliminate it. The solution to the knowledge gap is to train everyone in the organization on operations science. Some people need more detail than others. But once everyone is aligned on how the system behaves, the people who do the work can turn that knowledge and their experience loose on their own processes.
An operation, in this framework, has a few standard components. Work in process (WIP) and queues. Transformation, which is resources that consume time. Demand. Stocks, which are completed entities waiting for demand.
One distinction matters more than it first appears: work in process can be physical or virtual. It could be code waiting to be written for a program. It could be a pipe spool waiting to be installed at a refinery. The framework doesn't care whether the work is tangible. It cares about how the work flows.
Two more definitions anchor the rest of the session. Transformation is measured as a rate. Demand is measured as a rate. Transformation synchronizes to meet demand. That synchronization, under conditions of variability, is the entire game.
Ed walks through the same structure across industries to make the universality concrete. In an emergency department, patients are the work in process; registration, triage, treatment, diagnosis, and discharge are transformation; the waiting rooms and the waits for results are queues; syringes and bandages are stocks waiting for patient demand. In aviation maintenance, repair, and overhaul, an engine comes in with unknown condition, gets disassembled, and reveals its actual work scope -- a light repair can turn into a heavy repair the moment corrosion shows up on a turbine blade, which is variability in its purest form. In construction, you design, make, transport, and build; a refinery project might involve 2,000 pipe spools, which is a repeatable process whether or not anyone wants to call it a factory. In engineering configure-to-order, the work between quote and release to manufacturing is entirely virtual, but it's still work in process. And in traditional manufacturing -- the place people assume the concepts are confined to -- a casting gets turned, milled, inspected, and hand-finished before it reaches finished goods.
Good science applies everywhere. That's the point of the tour.
The centerpiece of the session is a test Ed has run with thousands of people. It depends on two definitions stated carefully.
Process time is the time to do work at one process center. Two hours here, an hour there. Cycle time is the time to get through an entire routing -- process center one to two to three to four. Cycle time is usually far greater than the sum of the process times, which is why the value-added time in most processes looks so small against the total. Ed is candid that he isn't a fan of the value-added/non-value-added discussion, because it tends to get subjective. The more useful framing is the gap between the sum of process times and the actual cycle time, and that gap is mostly wait time.
Utilization is the time used over the time available. If demand is three parts a day, each takes two hours of work at a process center, and the shift is eight hours, that's six hours of work in an eight-hour window -- 75% utilization. Straightforward. Something people work with day in and day out, at work and at home.
So the test should be easy. Take 15 seconds and draw the relationship between utilization and cycle time. Everyone in the room works with both concepts constantly. It should be as intuitive as sketching the path of a ball that rolls off a table.
It isn't. When Ed collects the responses from a room of people with hundreds of combined years of operations experience and overlays them, the result is a spaghetti diagram. Some people draw cycle time decreasing as utilization rises. Some draw it increasing. Some draw a straight line. Some draw an exponential curve. Some draw an S-curve. The variation isn't only in the direction of the relationship; it's in the shape too.
This is the fundamental problem. It's not merely that some people hold the wrong model. It's that an organization full of capable, well-intentioned people holds incompatible models of a basic relationship they all depend on. Ed's crew-boat analogy lands the point: even if six of ten rowers pull in the right direction, the other four rowing wherever they like wreck the boat. The cost of disagreement is nearly as high as the cost of error.
He shares an anecdote that captures the payoff of fixing it. After training a mixed group -- veterans alongside new hires, managers alongside engineers and line workers -- one participant told him that they used to think they had 30 problems and 30 potential solutions, because they had 30 people. After the training gave them a shared framework, they realized they had four problems, and they got dead set on those four. Shared understanding doesn't just improve answers. It collapses the noise.
There is a mathematical answer to the test question. It's the Kingman equation -- Ed calls it the VUT equation, the NBA version of the name. Three components drive cycle time: a variability factor (the squared coefficients of variation for arrivals and for effective process time), a utilization factor (the same time-used-over-time-available figure), and a time factor (the process time for a batch, not for a single piece).
Plotted, the relationship produces two curves: one for low variability, one for high. Both show cycle time rising as utilization rises, but the shape carries the real insight.
As Mark walks through for listeners following only the audio: on the low-variability curve, cycle time increases slowly, almost linearly, until roughly 95% utilization, where it skyrockets. That sharp upturn is what Factory Physics calls the cycle time explosion. On the high-variability curve, cycle time climbs more steeply from the start and hits its explosion much earlier, around 75% utilization. The lesson writes itself: the more variability you carry, the more brutally cycle time punishes you for pushing utilization high.
Ed grounds the abstraction in a real company. KX Technologies, run by his friend and board advisor Bill Furley, is an engineer-to-order, configure-to-order shop making compression seal fittings, temperature sensors, and cable and wiring harnesses in small lots. Their plasma welders have stubbornly high variability -- machines they've spent years trying to dial in without success. Knowing the curve, they plan those welders at about 50 to 52% utilization. An accountant might have a heart attack at the sight of equipment planned for half-idle. But if you want predictability from a high-variability process, that's simply how the process works. You could spend $5 million on a more dependable machine if one exists; understanding the curve lets you make that trade-off with eyes open. Their dependable Okuma mill, by contrast, gets planned at 92% utilization. Same factory, two utilization plans, one three-week lead time held reliably -- because they plan for the variability they actually have rather than the variability they wish they had.
For most managers, the worst thing to see is people standing around. Ed reframes that instinct. Idle capacity is a capacity buffer, and a capacity buffer is one of the legitimate ways to absorb variability.
He recounts a conversation from the day before the webinar. A manager wanted to cut labor cost by automating everything, then started to wonder whether he'd still need the people anyway -- because they're flexible, able to flex from one line or machine to another to absorb variability in a way fixed automation can't. People not working at 100% of the time aren't necessarily waste. They may be the most adaptable buffer the operation has. (Ed is careful to add that this doesn't mean people sit around playing tiddlywinks -- there's always improvement work to do in the slack, a point he and Mark return to at the end.)
The construction industry shows the inverse pathology. Construction hates idle workers, so it tends to keep material waiting on work rather than workers waiting on material -- a preference that drives its own set of problems.
You don't need a designed experiment to dissect cycle time. The components are known and quantifiable: process time, setup time, downtime, queue time, batch time, wait-to-match time, move time, shift differential time, and plan time buffer (the last especially relevant to construction). The Operations Science Institute publishes a downloadable glossary covering these terms.
This decomposition clarifies what the popular methods actually address. Six Sigma focuses on process time, downtime, and queue time. Lean works on setup times, queue times, and move times. Agile, when it sets a sprint length, is really setting the batch size of work for a software production process. None of these is bad. Ed is emphatic on this -- don't quote him saying Lean sucks, because that isn't what he's saying. The tools are useful but incomplete, particularly because most of them evolved as best practices: someone was doing something great somewhere else, and the practice got transplanted without the underlying science. The knowledge gap is what turns transplanted practices into the program-of-the-month cycle that exhausts the veterans.
Ed offers a simple structure for putting operations science to work: design, implement, control. Start with a process map -- if you don't have one, make one, because you can't model what you can't see. Turn the map into a model with data and the operations science concepts. Use the model to optimize a new process before approving the capital expenditure, or to find improvement opportunities in the current one.
The trap is that everyone runs straight to implement. Implement is the fun part -- move things around, run a kaizen, do something. But how do you know last week's kaizen isn't working against this week's? And a perfect design with perfect implementation can still be wasted without the right controls -- controls that match the behavior of the operation as the science describes it. All three components have to be present. Design and implementation without control is a one-time win that erodes.
This session is about the science of how operations behave, not about software. But the connection between operations science and improvement infrastructure runs through two of Ed's central points.
The first is shared understanding. Ed's whole case is that disagreement about how the system behaves -- the spaghetti diagram -- produces chaos independent of anyone's competence. A platform that makes improvement work, metrics, and process performance visible across an organization gives people a common reference point. When everyone can see the same data on cycle time, throughput, and where work is queuing, the conversation can move from competing intuitions to a shared picture. The visibility doesn't substitute for the science, but it supports the alignment the science depends on.
The second is the slack question. Ed and Mark close on the idea that capacity buffers shouldn't be filled with busywork or eliminated in the name of utilization -- they should be partly used for improvement work. Reducing setup times, attacking the sources of variability, improving flow. That's exactly the kind of work an improvement management system is built to capture, route, and track. The non-productive time that operations science says you need for buffering becomes the time in which continuous improvement actually happens, and the platform is where that improvement work lives so it doesn't evaporate.
There's also a direct line to the cycle time explosion. Organizations that chase 100% utilization because idle resources look wasteful are, in operations science terms, driving themselves up the steep end of the curve. The same instinct shows up in improvement work as overproduction -- one of the classic seven wastes of the Toyota Production System. The methodologies and the science agree here: the goal isn't busy machines, it's flow. Infrastructure that lets leaders see lead times, queue buildup, and the impact of improvements helps keep the focus on flow rather than on the false comfort of full utilization.
What is operations science?
The study of how resources are transformed to create and distribute goods and services, while managing variability in demand and in processes. It focuses on the interaction between demand and transformation and the variability in either or both. Its practical value is providing a shared, scientific understanding of how systems behave -- a common language for leaders and frontline teams -- rather than another improvement program people are asked to believe in. The concepts apply across industries because, as Ed puts it, it wouldn't be good science if it didn't apply universally.
How is operations science different from Factory Physics?
The science is the same; the name is broader. "Factory Physics" triggered a "we're not a factory" objection everywhere outside traditional manufacturing -- hospitals, aviation overhaul shops, construction. "Physics" also struck some people as too hard to approach. "Operations science" sidesteps both: everyone has operations, and people trust science as an objective basis for decisions. Ed founded the Operations Science Institute to carry the concepts forward under that framing.
What is the relationship between utilization and cycle time?
Cycle time rises as utilization rises, and it rises along a curve, not a straight line. At low variability, cycle time increases slowly until roughly 95% utilization, where it explodes upward. At high variability, it climbs more steeply from the start and explodes around 75% utilization. The practical implication is that the more variability a process carries, the lower you have to keep utilization to maintain predictable lead times. This is the relationship that thousands of experienced operations people draw incorrectly -- or draw in wildly inconsistent ways -- when tested.
What is the cycle time explosion?
The point on the utilization curve where cycle time shoots up dramatically as utilization approaches its ceiling. On a low-variability process that's near 95%; on a high-variability process it can happen around 75%. Pushing utilization into the explosion zone is what turns a well-meaning drive for efficiency into long lead times and firefighting. It's why striving for 100% utilization is self-defeating for anything but a true bottleneck running to meet demand.
Why is striving for 100% utilization a problem?
Because of the cycle time explosion. Running resources at or near 100% drives cycle time up steeply, which lengthens lead times and creates the work-in-process buildup that operations science predicts. In healthcare, the desire to keep rooms, equipment, and people fully utilized -- because idle capacity looks wasteful -- produces exactly the flow problems and delays leaders are trying to avoid. The exception is a genuine bottleneck that has to run at high utilization to meet demand; the error is trying to run everything that way.
What causes variability?
Two broad sources. Demand variability -- the variation in arrival times between units of demand -- is typically the largest source, and for an internal operation it often can't be controlled. Transformation variability comes from the resources themselves: differing process times even when nothing goes wrong, machine breakdowns, defects, scrap, and rework. The key decision is how much variability to plan for, because planning for more variability requires more buffering, and reducing variability lets you carry less.
What are buffers, and what types are there?
Buffers absorb the mismatch between demand and transformation that variability creates. There are three: inventory buffers, capacity buffers, and time buffers. More planned variability requires more buffering; less variability allows less. Idle capacity, often seen as waste, is a legitimate capacity buffer -- flexible people who can flex across lines or machines absorb variability in ways fixed automation can't. The art is selecting the buffer mix that meets your cycle time and service-level targets at acceptable cost.
Does operations science apply to a job shop?
Yes. Job shops -- including aviation maintenance, repair, and overhaul operations, which are classic job shops -- were among the early skeptics who insisted they weren't factories. Chapter 7 of Factory Physics for Managers details how the concepts apply at Arc Industries, a medical products job shop. The central concern in a job shop is using expensive capital equipment as effectively as possible against high variability, which is precisely what the science helps you plan.
How does operations science relate to operations strategy?
Organizational or business strategy sets the goals -- which customers, which products, which channels, how much to spend. That choice defines a performance envelope. Operations strategy is the design, implementation, and control of buffers and variability to meet that envelope. Offering more products and chasing more customers adds variability; operations strategy decides how to deploy capacity and inventory buffers to deliver against the envelope the business strategy set. The two are connected -- Dell's demand-shaping through pricing and configuration discounts is an example of operations and sales strategy working together, though doing demand shaping well still requires understanding how your resources behave.
Can you really manage variability predictably?
You can't predict the future -- you can't say what will happen next Friday at 3 p.m. But you can select a range of variability in supply and transformation, then set your resources and buffers (capacity, inventory, time) to deliver a given cycle time and service level at a given cost. Within that planned range, performance becomes predictable. When reality exceeds the range, you make a deliberate decision: accept lower service or higher cost, or let a one-time event pass. The firefighting and heroics drop sharply once the organization shares this understanding.
How does operations science relate to Lean and the Toyota Production System?
Ed sees high alignment and warns against misreading either. He wouldn't tell anyone to abandon Lean -- you've built the language and the system around it. The risk is driving decisions without the underlying science and producing unintended consequences. A misread of "waste" that treats machine downtime as something to eliminate by running everything to 100% violates what the science predicts and lengthens lead times -- the opposite of Lean's intent. This echoes Taiichi Ohno's own teaching that idle people or idle machines aren't the problem; idle flow of product through the system is. Operations science is agnostic to your chosen methodology and provides the scientific foundation underneath whatever you use. As Ed frames it, the science shows you what will happen if you push utilization to 100% -- it doesn't forbid it, it predicts the consequence.
What does "optimal" actually mean in operations science?
Ed's working definition after decades in the field: maximum throughput to meet demand, at minimum cost (fixed and variable, in people, plant, and equipment), at whatever service level you choose. Sales will always want 100% on-time delivery, but that may be prohibitively expensive. Optimal is maximum throughput, minimum cycle time, and minimum cost together -- and what that combination looks like differs from business to business. Operations science helps you find the specific answer for yours.
.svg)
Copyright © 2026
Privacy Policy