Learning to See in 2023

Pat’s comments on my last post reminded me of another post I had written a decade (!!!) ago titled Learning to See in 2013*. I think it is time for reflection and an update. That being said, I think the 2013 post has actually aged pretty well. I don’t see anything in it I would retract, just some things to further clarify or amplify.

Of course that implies that we (our community) is still largely stuck in the same groove we were a decade ago. *sigh*

Let’s ask some questions:

Who is “Learning to See?”

The first time I made a real value stream map was in 1999. A plant manager asked me to build a map of the flows in his factory. I spent three or four days talking to his area managers to get their understanding, observing flows on the shop floor, getting actual cycles, comparing what I observed with what those managers thought was going on.

With all of that information, I mapped out the factory’s flows. It took four 11×17 (A3 size) sheets taped together to depict what happened as raw steel came in one end of the building and was cut, bent, welded, painted, and assembled with purchased components into the final product.

I learned a lot, not only about mapping a process, but about the way this factory functioned, and had pretty compelling evidence that the bottleneck was not what the common knowledge said it was.

I dutifully presented my findings to the plant manager and his continuous improvement manager. And things pretty much ended there.

Years later, another plant manager asked me to come out to their site and map their value streams. This time I was pretty insistent that though I was happy to come out and facilitate the process, it really had to be the site leaders that were doing the observations and building the map. What they wanted, though, was for me to report my findings to them once I was done. I still scratch my head about that one as the General Manager was an ex-Toyota guy who knew better.

Which brings us to:

Who is mapping the process?

A production team reviews their understanding on a value stream map

Regardless of what structure you use to map your process (VSM, Swim Lanes, SIPOC, to name a few), the learning comes from the experience of building the map and then having to explain it to someone else.

That second bit is important: If you can’t explain it to someone else, you probably don’t understand it as well as you thought.

So, if you are a consultant or internal change agent, and you build the map and then try to explain it to management, guess who learned the most? (Hint: It wasn’t your audience.) The key point here is if your objective is for the line leaders to gain insight into what is actually happening, you are unlikely to accomplish that objective by explaining it to them. They will never gain as much insight as you did.

In the photo above, it is the operational leaders who are explaining what they are learning to me. I’m just asking questions until I understand. They ended up going back out to the shop floor more than a couple of times as the picture came into focus.

Why are you mapping the process in the first place?

I asked this question in the 2013 post: “Why are you doing this at all?” with a context of having some kind of strategic intent, a challenge, in mind.

If there isn’t a concrete challenge or objective in place, this quickly turns into a “What could we improve?” exercise followed by a calculation about whether it is even worth going through that effort or might be cheaper to just outsource the entire thing to a “low wage country.”

But there is another, more tactical, reason to ask this question.

If your step was “Make a value stream map,” then “What do you expect as a result of taking that step?”

I have heard responses such as “I expect the leaders to see what they need to fix.” That, actually, is a testable outcome if you do so with intent. But if you are frustrated that, time after time, a current state process gets mapped and then nothing else happens, then it might be time to ask “What am I learning?”

This kind of brings us back to the importance of that overall strategic intent, because that is what drives the necessity to then build a possible future state map that, if we can operate that way, will deliver the results we need. From that we can establish challenges for individual local leaders and work with them (coach them) toward reaching those challenges.

Again – this is all a lot of work. And it is hard. Thus it is equally important to understand that the higher level goal here is to build capability and competence within your organization. If you forget that part, then it is all to easy to just outsource the mapping (see the beginning of this post) or, worse, outsource your entire value-add chain.

*The title of that post, and this one, is based on a groundbreaking book by Mike Rother and John Shook, Learning to See. Published in 1999, it introduced the term “value stream map” into the vernacular. And it was the first significant publication of the then newly-formed Lean Enterprise Institute. I think Learning to See actually had the impact of establishing a genre – practical application workbooks that sent beyond just discussing benchmark examples and general principles.

October 13, 2020October 13, 2020

A Lean Leadership Pocket Card

I was going through some old files and came across a pocket card we handed out back in 2003 or so. It was used in conjunction with our “how to walk the gemba” coaching sessions that we did with the lean staff, and then taught them to do with leaders.

There is a pretty long backstory, some of it is summarized in Earl’s recollection on this old post: Genchi Genbutsu in a Warehouse as well as here: The Chalk Circle – Continued.

A lot has happened, a lot has been learned since then. Toyota Kata has been published, and that alone has focused my technique considerably (to say the least).

Nevertheless, I think the elements on these little cards are valuable things to keep in mind.

With that being said, a caveat: Lists like this run the risk of becoming dogma. They aren’t. There are lots of lists like this out there, and the vast majority are very good. The key here is something that a leader or team member can refer to as a reminder that may bias a decision in the right direction. It is the direction that matters, not the reminders.

Fundamentals

The fundamentals are based on the “Rules-in-Use” from Decoding the DNA of the Toyota Production System, a landmark HBR article by Steve Spear and H. Kent Bowen. The article, in turn, summarizes (and slightly updates) Spear’s findings from his PhD work studying Toyota.

A. All work highly specified as to content, sequence, timing, and outcome.

B. Every customer-supplier connection is simple and direct.

C. The path for every product is simple and direct.

D. All improvements are made using PDCA process.

What we left off, though, is that in each of those rules there is a second one: That all of these systems are set up to be “self diagnostic” – meaning there are clear indications that immediately alert the front line people if:

The work deviates from what was specified.
The connection between a customer and supplying process is anything other than specified.
The path a product follows deviates from the route specified.
Improvements are made outside of a rigorous PDCA (experimental) process.

In other words, the purpose of the rules is to be able to see when we break them, or cannot follow them, so we trigger action.

To put this into Toyota Kata-speak – every process is set up as a target condition that is being run as an experiment – even the process of improvement itself!

Every time there is a disruption – something that keeps the process from running the way it is supposed to – we have discovered an obstacle. That obstacle must first be contained to protect the team members and community (safety) and to protect the customer (quality). Then goes into the obstacle parking lot, and addressed in turn.

If you think about it, the Improvement Kata simply gives us much more rigor to (D).

This ties to the next sections.

Key Leadership Behaviors

Note that this is behaviors. These are things we want leaders to actually strive to do themselves, not just “support.” It was the job of the continuous improvement people to nudge, coach, assist the leaders to move in these directions. It was our job to teach our continuous improvement people how to do that coaching and assisting – beyond just running kaizen events that implement tools.

A. PDCA Thinking

Today we would use Toyota Kata to teach this. But the same structure drove our questioning back then.

B. Four Rules:

1. Safety First

Even though this should be obvious, it is much more common that people are tacitly, or even directly, asked to overlook safety issues for the sake of production. I remember walking through a facility with a group of managers on the way to the area we were going to see. Paul stopped dead in his tracks in front of a puddle on the floor. He was demonstrating just how easy it was for the leadership to walk right past things that should be attended to. And in doing so, they were sending the message – loud and clear in their silence – that having a puddle on the floor was OK.

2. Make a Rule, Keep a Rule

This is a more general instance of Rule #1. But the it is more subtle than it may seem on the surface. Most people immediately interpret this as enforcing organizational discipline, but in reality it is about managerial discipline.

Nearly every organization has a gap between “the rules” and how things really are day-to-day. Sometimes that gap is small. Sometimes it is huge.

Often “rules” are enforced arbitrarily, such as only cases where a violation led to a bigger problem of some kind. Here’s an example: Say your plant has a set of rules about how fork trucks are to be operated – speed limits, staying out of marked pedestrian lanes, etc. But in general the operators hurry, cut a corner now and then. And these violations are typically overlooked… until there is some kind of incident. Then the operator gets written up for “breaking the rules” that everyone breaks every day – and management tacitly encourages people to break every day by focusing on results rather than process.

When we say “make a rule / keep a rule” what we mean is if you aren’t willing to insist on a rule being followed consistently, then take the rule off the books. And if you are uncomfortable taking the rule off the books, then your only option is to develop something that you can stand behind. It might be simple mistake proofing, like physical barriers between forklift aisles and pedestrian aisles. But if you are going to make the rule, then find a way to keep the rule.

Do you have “standard work” documents that are rarely followed? Stop pretending you have standards or rules about how the work is done. Throw them away if you aren’t willing to train to them, mistake proof to them and reinforce following them.

3. Simple is Best

Simply, bias heavily toward the simplest solution that works. The fewest, simplest procedures. The simplest process flow. Complexity hides problems. “Telling people” by the way, is usually less simple than a physical change to the work environment that guides behavior. See above.

4. Small Steps

Again, Toyota Kata’s teaching covers this pretty well today. The key is that by taking small steps, verifying that they work, and anchoring them into practice before taking the next ensures that each step we take has a stable foundation under it.

The alternative would be to make many changes at once in the name of going faster.

We emphasized here that “small steps” does not equal “slow steps.” It is possible to take small steps quickly, and we found that in general doing so was faster than making big leaps. Getting big changes dialed in often required backing out and implementing one thing at a time anyway – just to troubleshoot! See “Gall’s Law” which states:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
John Gall, author of Systematics

and sums this up nicely.

C. Ask “Why, what, where, when, who, and how” in that order.

Here we borrowed the sequence from TWI Job Methods. The first two questions challenge whether a process step is even necessary: Why is it necessary? What is its purpose? To paraphrase Elon Musk, the greatest waste of time is improving something that shouldn’t even exist.

Then: Where is the best place? and When is the best time? These questions might nudge thinking about combining steps and further simplifying the process.

And finally we can ask Who is the best person? and “How” is the best method? The key point here is until we have the minimum possible steps in the simplest possible sequence, and understand the cycle times, it doesn’t make sense balance the work cycle or work on improving things.

Come to think about it – perhaps we should ask “How?” before we ask “Who” since improving the method will change the cycle times and may well inform out decisions about the work balance. Hmmm… I’ll have to think about that. Any thoughts from the TWI gurus?

D. Ask Why 5 Times

Honestly, this was a legacy of the times. Unfortunately it suggests that you can arrive at a root cause simply by repeatedly asking “Why?” and writing down the ~~excuses~~ answers that are generated. In reality problem solving involves multiple possible causes at each level, and each must be investigated. I talked about this in a post way back in 2008: Not Just Asking Why – Five Investigations.

E. Go and see.

Go and see for yourself. Taking this into today’s practice, I think it is something that the Toyota Kata community might emphasize a little more. We tend to ask the question “When can we go and see what we have learned…?” but all too often the answer to “What have you learned?” is a discussion at the board rather than actually going and observing. Hopefully the board is close to where the improvement work is being done. Key point for coaches: If the learner can’t show you and explain until you understand, it is likely the learner’s understanding could be deeper.

As You Walk The Workplace:

Check:

perhaps we should have said “Ask…” rather than “Check” but asking and observing are ways to “check.” All of the below are things that the leader walking the workplace must verify by testing the knowledge of the people doing the work.

A. How should the work be done? Content, Sequence, Timing, Outcome

This is another nod to the research of Steven Spear. The key point here is that before you can ask any of the following questions, you have to have a crisp and precise of what “good” looks like. In this paradigm, all processes are target conditions. And as the work is being done, we are actively searching for obstacles so we can work to make the work smoother and more consistent.

In other words, “What should be happening?” and “How do you know?”

Do the people doing the work understand the standard process as it should be done?

A few months ago I went into some depth on this here: Troubleshooting by Defining Standards. That probably isn’t the best title in retrospect, but there are too many links out there that I don’t want to break by changing it.

B. How do you know it is being done correctly?

Today I ask this question differently. I ask some version of “What is actually happening?” followed by “How can you tell?” We want to know if the people doing the work have a way to compare what they are actually doing against the standard.

C. How do you know the outcome is free of defects?

So, question B asks about consistency of the process, and question C asks about the outcome. Does the team member have a way to positively verify that the outcome is defect-free?

D. What do you do if you have a problem?

Again, we are checking if there is a defined process for escalating a problem. And we define “problem” as any deviation from the standard, or any ambiguity in what should be (or is) happening. We want someone to know, and act, on this, and the only way that is going to happen is to escalate the problem.

We want this process to be as rigorous and structured as the value-adding work.

And we want as much care put into designing production process as was put into designing the product itself. All too often great care and a lot of engineering time goes into product design, and only a casual pass is made at designing and testing the process.

Even better if these are done simultaneously where one informs the other.

For Abnormal Conditions:

ACT:

These are actions that the leader must take if she finds something that isn’t “as it should be” in the course of the CHECK questions above. Key Point: These are leadership actions. That doesn’t mean that the leaders personally carry them out, but the leaders are personally responsible for ensuring that these things are done – and checking again.

That is the only way I know of to prevent the process from continuing to erode.

A. Immediately follow up to restore the standard.

If it isn’t possible to get the intended standard into back place, then get a temporary countermeasure into place that ensures safety and quality.

B. Determine the cause of erosion.

We are talking about process erosion here, with the assumption that something knocked the process off its designed standard. Some obstacle has been discovered, we have to better understand what it is – at least enough to get it documented.

C. Develop and apply countermeasure.

Here we may have to run experiments against this newly discovered obstacle and figure out how to make the process more robust.

That is the end of the little card. But I want to point out that we didn’t just hand these out. You got one of these cards after time paired with a coach on the shop floor practicing answering and asking these questions. Only after you demonstrated the skill did you get the card – just as a reminder, not as a detailed reference. This exercise was inspired by a few of us who had experiences “in the chalk circle” especially with Japanese senseis who had been direct reports to Taiichi Ohno.

We piloted and developed this process on a very patient and willing senior executive – but that is another story for another day. (Thank you once again, Charlie. I learned more from you than you will probably ever realize.)

November 12, 2016January 9, 2019

It’s “What must we learn?” not “What should we do?”

Darren left a great question in the Takt Time-Cycle Time post:

Question… 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 needs 10 operators), how do you fluctuate in a seasonal business (+/-25%/month) to ensure you don’t end up over stocking your internal customer?

Would One Piece Flow be more efficient on the whole value chain in this instance due to its flexibility?

That was a few weeks ago. Through its evolution, this post has had four titles, and I don’t think there is a single sentence of the original draft that survived the rewrites.

I started this 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 (human and others) is an incredibly efficient pattern matching machine. I got a little bit of information, and immediately filled in a picture of Darren’s factory and 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 of the time.

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

That pattern recognition triggered the startle. It was seconds later that 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 but 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 of 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 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 is 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. The goal 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 under-production) 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.

Flexibility

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% utilization (which rarely happens).

If other process steps are capable of running faster (which is the very definition of a bottleneck), they will, 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 your efficiency is reduced. If the next operation can’t run at 100 units / day and absorb your output, then it is the bottleneck. See above.

Now, let’s break down your costs of capacity. In the broadest sense, your costs come down to two things:

Capital equipment. (And let’s include the costs of the facility here.)
Labor – 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. Since machines usually operate at different rates, it is you aren’t going fully utilize anything but the slowest one. It doesn’t make sense to even try.

People 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 over produce.

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. However this adds costs as well, often hidden ones. Where do these people come from, and frankly, “what are they doing when they aren’t working for you?” are a couple of questions you need to confront. 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 is usually stated as though it is 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 (1) custom ordered for every single unit and (2) highly seasonal (in fact, they are in their peak season as I write this). 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, there is a problem to solve, a challenge to overcome.

Challenge

I am interpreting the challenge here as “Have the ability to flex production +/- 25% / 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% makes me do 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.

While this post is too short to get down to the details, there are some additional questions I would really need to understand here.

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% 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?

Since 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 easily 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. Since 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. While I am sure Darren knows much more, I 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, (if I were the learner / person doing the improvement here) 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. Smile

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.

And 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.”

A long time ago, when I first started this 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 “ah ha” 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, by 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.

Darren – if you want to discuss your specific situation, click on “Contact Mark” and drop me an email.

April 30, 2015January 9, 2019

Interesting Question about Cycle Time

An interesting search landed someone on the site recently. Here it is:

a machine is producing 55 parts in one hour. what is the cycle time for each part.

Likely this is someone Googling his homework question, but I’d like to take apart the question and discuss it. If this is a homework question, I would contend that the likely “correct” answer is wrong.

Take a pause and think about it for a second. How would you reflexively answer this question?

Someone encountering this question is likely to simply divide the 55 parts of output into the 60 minutes of elapsed time. Doing that, we get something just over 65 seconds per part.

Which is interesting, but it isn’t the cycle time per part. It is the average rate of production, but it isn’t the cycle time.

I contend you don’t have enough information to answer the question. To really do that, you need to get your safety glasses and hearing protection, go down to the machine with a stopwatch (I’d suggest one with a lap function) and click off the elapsed time interval between each and every part as it come off the machine.

Why?

Well… let’s say that the machine is actually running at a cycle of 55 seconds / part when it is actually operating, but there are frequent jam-ups that the operator has to clear.

Isn’t that a completely different story than running smoothly with one part coming off every 65.45 seconds?

Think about it.

March 17, 2013January 9, 2019

The Simplest “Lean Audit”

I’m sorting through some old files, and just tossed a 20 or so page “lean audit” from some consultancy into the recycle bin. Like most of them, it tries to gauge the maturity of the organization by the depth and breadth of their implementation of a packet of “lean best practices” – the tools.

What I am interested in, though, is gauging maturity of the thinking and interactions, the culture.

If I ask a typical supervisor what he or she is working on right now for process improvement, what kind of answer will I get?

Does that supervisor’s boss give me the same answer? Are they coordinating and talking?

Ultimately, it comes down to the shop floor’s perception and answers to questions like:

“What are you trying to achieve?”

“Where are you right now?”

(If these look like the generic coaching questions that Mike Rother talks about in the video clip a couple of posts down, you’re right.)

The context of the answers to those questions tells me a great deal. Is it daily survival / firefighting? Or is there something they are striving for to make things better?

Even if the supervisor is engaged in daily firefighting, there is still some kind of target (usually making the production numbers); some kind of current condition (which may be clear, or may be just a judgment).

So I am curious now about what he sees as the problems and obstacles in his way of success.

“What kind of issues are keeping you from hitting your target?”

Then just listen. Whatever he says is the right answer, because I am interested in his overall perception.

Is the response from someone who is positive and feels supported, or besieged and left on his own?

Then, based on those responses, I might or might not get curious about his improvement activities. If he isn’t engaged in any, I’m not going to try to make anyone wrong, I am just trying to understand what is.

On the other hand, if there are improvement activities, then I am curious to know what he last tried, and learned, and what he plans to do next.

What kind of collaboration do I hear about?

What is the sophistication of the targets, the challenges, the experiments?

THOSE are the things that tell me how “lean” a company is… not whether or not they have uniform label colors on everything.