Featured Product
This Week in Quality Digest Live
Operations Features
Constance Noonan Hadley
The time has come to check whether the benefits of teamwork still outweigh the costs
Jeremy L. Boerger
To keep your business running, you need visibility into your IT assets
Naresh Pandit
Enter the custom recovery plan
Anton Ovchinnikov
In competitive environments, operational innovation could well be the answer to inventory risk
Kari Miller
An effective strategy requires recruiting qualified personnel familiar with the process and technology

More Features

Operations News
Major ERP projects take six months longer than companies were told
The Ring Dex 2 filling and capping system is designed to simplify production.
Recent research finds organizations unprepared to manage more complex workforce
Designed for high-volume production environments
Combined company gives manufacturers greater control over output, quality, and sustainability
Enables system-level modeling with 2D and 3D visualization, reducing engineering effort, risk, and cost
For high-volume, parts-cleaning applications
Product placement lends depth to sustainability
Innovative in-line, continuous color-management systems

More News

Mark Rosenthal


Ask, ‘What Do We Need to Learn?’ Not, ‘What Should We Do?’

Stop trying stuff and hoping it works without understanding why

Published: Thursday, December 15, 2016 - 19:11

One of my readers, Darren, commented with some great questions about the “Takt Time-Cycle Time” post on my blog. He wondered which system is more efficient, a fixed, rigid takt-based production line or a flexible one-piece flow?

In terms of designing a manual-based production line to meet a theoretical forecasted “takt time,” (10 fixed workstations need 10 operators), how do you fluctuate in a seasonal business (±25% per month) to ensure you don’t end up overstocking your internal customer? Would one-piece flow be more efficient on the whole value chain in this instance due to its flexibility?

Through the evolution of answering his questions, this article had four titles, and I don’t think there is a single sentence of the original draft that survived the rewrites. I started the post with a confident analysis of the problem and the likely solution. Then I realized something: I don’t know.

My brain, just like every other brain on the planet, is an incredibly efficient pattern-matching machine. I got a little bit of information and immediately filled in a picture of Darren’s factory, then proceeded to work out a course of actions to take, as well as alternatives based on other sets of assumptions.

NO, no, no!

Our reflex: jumping to solution

This graphic is copied from Mike Rother’s presentation material. It is awesome.


It is likely that at this point you know that it doesn’t say “JUMPING TO CONCLUSIONS” under the little blue square, and of course you are right.


But in spite of the fact that you know the truth, it is likely you still read “JUMPING TO CONCLUSIONS” when you look at the first graphic. I know I do, and I present this all the time.

Our brains are all wired to do this; it’s basic survival and it happens very fast. Think about a time when you have been startled by something you thought you saw, then a few seconds later you realized it was nothing.

That pattern recognition triggered the startle. Within seconds your logical brain took over and analyzed what was really going on. This is good. We don’t have time to figure out if that movement in the grass was really a leopard or not. We’ll sort that out after we get away.

Our modern brains work the same way with learned patterns, imagebut we are usually very poor at distinguishing between “what we really know” and “what we have filled in with assumptions.”

This is the trap that we “lean experts” (whatever that means) fall into all the time. We take limited information, extrapolate it into a false full understanding, and deliver a diagnosis and treatment.

Boom. Done. Next?

What’s even worse is we often don’t hang around to see if the solution worked exactly the way we expected, or if anomalies came up.

In other words, everything comes down to takt, flow, and pull, right? Kinda, but kinda not.

Some technical background

All of the above notwithstanding, it really helps to understand how the mechanics of lean tie together to create the physical part of an organic/technical process.

What I mean by “really helps” is that this understanding gives you a broad sense of how the mechanics help people learn. Someone who only understands the mechanics as a set of tools is committing the gravest sin: Leaving out the people.

One-piece flow

One-piece flow is not inherently efficient. It’s easy to have lots of excess capacity, which translates to either overproduction or waiting, and still have one-piece flow.

This is the people part: One-piece flow makes those imbalances very obvious to the people doing the work so you can do something about them, if you choose to. Many people think the goal is one-piece flow. What the goal really is is making sure the people doing the work can see if the flow is going smoothly or not and give them an opportunity to fix the things that make flow less than smooth.

A pull system is designed to throw overproduction (or underproduction) right into your face by stopping your line rather than allowing excess stuff to just pile up. Again, it is a tool to give the people doing the work immediate visibility of something unexpected rather than the delayed reporting of inventory levels in a computer somewhere.


Any given level of capacity has a sweet spot for efficiency. Even “inefficient” systems are most efficient when their capacity (usually defined by a bottleneck somewhere) is at 100-percent utilization (which rarely happens).

If other process steps are capable of running faster (which is the very definition of a bottleneck), they must either be underutilized or build up work-in-process. This is part of the problem Darren is asking about—flooding his downstream operation with excess WIP to keep his line running efficiently.

If your system is designed to max out at 100 units/day, and you make less than that, then your efficiency is reduced. If the next operation can’t run at 100 units/day and absorb your output, then it’s the bottleneck. 

Let’s break down your costs of capacity. In the broadest sense, your costs come down to two things:
Capital equipment. This includes the costs of the facility.
Labor. This involves paying the people.

The capital equipment cost is largely fixed. At any rate of production less than what the equipment is capable of holding, you are using it less efficiently than you could. Because machines usually operate at different rates, you aren’t going fully utilize anything but the slowest one. It doesn’t make sense to even try.

The people issue is more complicated. In the short term, your labor costs are fixed as well. You are paying the people to be there whether they are productive or not.

When the people are operating machines, your flexibility depends on how well the automation is designed. The technical application of “lean tools” to build flow cells pushes hard against this constraint. We strive to decouple people from individual machines, so the rate can flex up and down by varying the work cycles rather than just having people wait around or overproduce.

At the other end of the labor spectrum is pure manual work, like assembly. We are striving for that same flexibility by moving typically separated operations together so people can divide the labor into zones that match the desired rate of production.

All of these approaches strive for a system that allows incrementally adjusting the capacity by adding people as needed. This adds costs as well, though, often hidden ones. A couple of questions you need to confront: Where do these people come from, and frankly, what are they doing when they aren’t working for you? The people are not parts of the machine. The system is there to help the people, not the other way around. This is people using tools to build something, not tools being run by people.

Handling seasonal production efficiently

“Our demand is seasonal” is something I hear quite a bit. It’s usually stated as though it’s a unique condition (to them) that precludes level production. In my nearly 30 years in industry, I haven’t encountered a product (with the possible exception of OEM aircraft production and major suppliers) that didn’t have a seasonal shift of some kind.

Depending on the fluctuations and predictability of future demand, using a combination of managing backlog and building up finished goods is a pretty common way to at least partly level things out for planning purposes.

That being said, I know of at least one company whose product is, first, custom-ordered for every single unit and, two, highly seasonal. They don’t have as many options.

Solving the problem

With all of that, we get to Darren’s specific question. The short answer is: “I don’t know, but we can figure it out.” There isn’t a fixed answer, but there is a problem to solve, a challenge to overcome.


I am interpreting the challenge here as: “We need to have the ability to flex production ±25 percent a month without sacrificing efficiency.”

Just to ensure understanding of the challenge, I would ask to translate the production capacity targets into takt times. What is the fastest takt time you would need to hit? What is the slowest?

In other words, the ±25 percent makes me do some math, even if I know the baseline, before I really know what you need to be able to do. Let’s get some hard numbers on it so we will all agree when we see it, or don’t.

Remember, takt time is simply a normalization of your demand over your production time. It is a technique for short-term smoothing of your demand. It doesn’t mean you are operating that way.

Current condition

We need to learn more, so the next questions have to do with the current condition. Although this article by necessity is too short to get down to the details, there are answers to some additional questions I need to understand.

Known: There are 10 fixed workstations with 10 operators.

Assumed to be known: the high and low target takt times (from the challenge)

How are the workstations laid out?

What are the cycle times of each operation?

What is actually happening at each of the workstations?

What are they currently capable of producing in relation to the takt times we want to cover in our ±25-percent range?

A good way to start would be to get exit cycles from each of the positions, and from the whole line. What is the current cadence of the operation? What are the lowest repeatable cycle times? How consistently is it able to run? What is driving variation?

Because we are looking for rate flexibility, I am particularly concerned with understanding points of inflexibility.

I would be looking at individual steps, at distance between the workstations, and how easy it is to shift work from one to another. Remember, to be as efficient as possible, each work cycle needs to be as close as possible to the takt time we are striving to achieve this season. Because that varies, we are going to need to create a work space that gives us the smoothest transitions possible.

What is the next target condition?

I don’t know.

Until we have a good grasp of the current condition, we really can’t move beyond that point. Although I am sure Darren knows much more, am at my threshold of knowledge: 10 workstations, 10 operators. That’s all I know.

However, I do know that it is unlikely I would try to get to the full challenge capability all at once. Even if I did have a good grasp of the current condition, I probably can’t see the full answer, just a step that would do two key things:
•  Move in the direction I am trying to go.
•  Give me more information that, today, is hidden by the nature of the work.

For an operation this size, I would probably set that target condition for myself at no more than a week or two. This also depends on how much time I can focus on this operation and how easy it is to experiment. The more experiments I can run, the faster I will learn, and the quicker I can get to a target.

Now, I will re-state the target condition to answer this question:

“We can’t… [whatever the target condition is]… “because ________.” as many times as I can. That is one way to flush out obstacles.

Another way is just to tell the skeptics we are going to start operating like this right away, then write down all of the reasons they think it won’t work. 

Then the question is: “OK, which of these obstacles are we going to address first?”

Iterate experiments/PDCA to learn.

Once I know which obstacle I am choosing to address first, I need to know more about it. What do I want to learn, or what effect do I want to have on the process? Those things are my expected result.

Now, what do I need to do to cause that to happen? That is my next experiment.

At that point, we are off to the races. As each learning cycle is completed, your current condition, your current level of understanding, changes. As you learn more, you better understand the obstacles and problems.

When you reach a target condition (or realize you are at the deadline and haven’t reached it), then go back to the top, review the challenge, make sure you understand the current condition, and establish a new target. Lather, rinse, repeat.

This isn’t about “the answers”

imageA long time ago, when I first started my blog, I wrote a post called “The Chalk Circle.” I told the story of one of my more insightful learning experiences in the shadow of one of the original true masters, the late Yoshiki Iwata. My “aha” moment finally came several years later, and a year after his death. He wasn’t interested in the answers, he was teaching me the questions.

We don’t know the answers to a problem like, “How do I get maximum efficiency through seasonal demand changes?” The answer for one process might give you something to think about, but copying it to another is unlikely to work well. What would work for Darren’s operation is unlikely to work in Hal’s. Even small differences mean there is more learning required.

When confronted with a problem, the first question should never be “What should we do?” Rather, we need to ask “What do we need to learn?”  What do we know? What do we not understand? What do we need to learn, then what step should we take to learn it? Taking actions without a learning objective is just trying stuff and hoping it works without understanding why.

What works is learning and applying the thinking behind sound problem solving, and being relentlessly curious about what is keeping you from moving to the next level.

I have come a long way since my time with Mr. Iwata, I continue to learn (lots), sometimes by making mistakes, sometimes with unlikely teachers, at times and in ways I least expect it. Sometimes it isn’t fun in the moment. Sometimes I have to confront something I have hidden from myself.

One thing I have learned is that the people who have all of the answers have stopped learning.

First published Nov. 12, 2016, on The Lean Thinker blog.


About The Author

Mark Rosenthal’s picture

Mark Rosenthal

Mark Rosenthal is an experienced lean manufacturing/quality director and manager with more than 20 years of experience implementing continuous improvement in diverse organizations. He brings deep understanding of the Toyota Production System and has proven ability to see any organization’s potential. Rosenthal is a change agent who facilitates the process of discovery to quickly make an impact on the way people think, enabling them to cut to the core issues and get things moving by engaging the entire team to develop solutions that affect the bottom line.


Well said

We should never be afraid to admit we don't know - it's the first step towards solving the problem! A favourite quote of mine is - "Education is a progressive discovery of our own ignorance"