Problem: What Does Maintenance Cost?

Another interesting “homework problem” showed up in the searches today:

an assembly line turns out parts at the rate of 250 per hour. on the average, the line must be shut down for maintenance for 20 hours during a month. how much production is lost each month?

Answer: None.

Wait a minute!! What about the 20 hours * 250 units / hour = 5000 units? Isn’t that lost production? Maybe. What problem are you trying to solve?

I’m making a couple of assumptions here. First is around the word “maintenance” vs. the word “repair.” If the line requires 20 hours of maintenance to run reliably and avoid repairs, then this time must be planned into the expected monthly production. Thus, no planned production is lost.

If no production above the planned level is required, then I can’t say any is lost. This is why one-dimensional questions like this are so dangerous. Whenever we are confronted with questions like this, we must always ask another:

Compared to what?

What should be happening? What is normal? What is needed? Simply saying that the line (when it is running) can produce 250 units per hour is data, but it gives us nothing to act on.

Here is the rule I have been pushing lately:

Whenever you measure something, there are always two values.

  1. What you measured.
  2. What is required or expected if the process or thing you are measuring is problem free or otherwise doing what it should or what you expect.

This is equally true for an observation.

  1. What you saw.
  2. What you should have seen if things were as expected or problem-free.

Then you can start the process of meaningful inquiry.

If my line produces 250 units / hour when running problem-free, and requires 20 hours of maintenance a month to be able to do that, we have a single piece of information: How much production I should expect during the month.

Is that enough? Then no problem, turn your attention to something more pressing.

Is that not enough? OK – now we have to get serious.

A lot of management teams confronted with this problem are going to reflex to just allocating fewer hours to maintenance in order to get more hours for production.

Don’t do it.

Just cutting maintenance time is going to make things worse. Maybe not this month or even next, but sooner or later you will be losing a lot more than 5000 units of production / month. What will make this frustrating is you won’t lose them all at once. You will experience slowdowns, short stoppages, jams, and all of these things will seem like a normal day – only you won’t be making 250 units per hour anymore.

This is where a lot of management team struggle. They only look at “maintenance hours” and issue a directive to cut those hours.

But “maintenance hours” is a metric that you cannot action directly. This is a classic example of what I wrote about a couple of years ago in “Performance is the Shadow of Process.”

Worse, this is a step away from what you are trying to accomplish… which is what?

Key Question: What Problem Are You Actually Trying to Solve?

“I need to reduce the time we spend on maintenance.” is not a problem. It might be a desire, or a possible solution, but if you start here, you are already restricting your thinking.

If you did reduce the time you spent on maintenance, what would you be able to do that you can’t do today? Why is this important to work on?

(Sometimes I get “We wouldn’t spend so much time on maintenance.” I always have to laugh when I hear something like this. Aren’t circular arguments fun? “OK, why is it important to spend less time on maintenance?”)

After some discussion, we might arrive at something like a need to produce another 1000 units / month to meet increased sales demand.

That becomes our challenge. Then the fact that we spend 20 hours / month doing maintenance is part of (and only part of) the current condition. But I can ask other question now such as:

How fast must we produce (units / hour) to get another 1000 units / month? You would be surprised how often the math tells us a number that is slower than “250 units per hour.” Huh. So maybe that’s the rate when things are running smoothly… where is the time going?

The point is that it is critically important to understand why you are asking how much time is being “lost” to maintenance to avoid jumping to a solution.

 

Poster - What Problem are you Actually Trying to Solve?

Overproduction vs. Fast Improvement Cycles

A couple of weeks ago ago I posted the question “Are you overproducing improvements?” and compared a typical improvement “blitz” with a large monument machine that produces in large batches.

I’d like to dive a little deeper into some of the paradoxes and implications of 1:1 flow of anything, improvements included.

What is “overproduction” – really?

In the classic “7 wastes” context, overproduction is making something faster than your customer needs it. In practical terms, this means that the cycle time of the producing process is faster than the cycle time of the consuming process, and the producing process keeps making output after a queue has built up above a predetermined “stop point.”

If the cycle times are matched, then as an item is completed by the upstream process, it is consumed by the downstream process.

If the upstream process is cycling faster, then there must be an accumulation of WIP in the middle, and that accumulation must be dealt with. Further, those accumulated items are not yet verified as fit-for-use by the downstream process that uses them.

The way this applies to my “Big Improvement Machine” metaphor is that we are generating “improvement ideas” faster than we can test and incorporate them into the process.

“Small Changes” Doesn’t Mean “Slow Changes”

No matter how good your solution or idea, it is just an academic exercise until it is anchored as the an organizational norm. The rate limit on improvement is established by how quickly people can absorb changes to their daily, habitual routine.

Implementing and testing small changes one-by-one is generally faster than trying to make One Big Change all at once. When we do One Big Change, it is usually actually a lot of small changes.

I hear “we don’t have time to experiment,” but when I ask what really happens if a big change is made, what I hear almost every time is they had to spend considerable time getting things working. Why? Because no matter how well the Big Change was thought through, once you are actually trying it, the REAL problems will come up.

Key Point #1: Don’t waste time trying to develop paper solutions to every problem you can imagine. Instead, “go real” with enough of the new process to start revealing the real issues as quickly as possible.

In other words, the sooner you start actively learning vs. trying to design perfection, the quicker you’ll get something working.

Slow is Smooth, Smooth is Fast

Your other objective here is to develop the skill within the organization to test and anchor changes quickly, as a matter of routine. This will take time.

When we see a high-performance organization making rapid big changes, what we are typically seeing is making small changes even more rapidly. They have learned, through practice over time, how to do this. It isn’t reasonable to expect any organization to immediately know how to do this.

Key Point #2: If managers, or professional change agents (internal or external consultants, for example) are telling people exactly what to do, this learning is not taking place.

It is critical for the organization to develop this learning skill, and they are only going to do it if they can practice. Learning something new always involves doing it slowly, and poorly at first. If your internal or external consultants are serving you, their primary focus is on developing this basic competence. Their secondary focus is on getting the changes into place. This is the only approach that actually strengthens the organization’s capability.

The same is true for an operational manager who “gets” lean, but tries to just direct people to implement the perfect flow. It will work pretty well for a while. But think about how you (the operational manager) learned this stuff: Likely you learned it by making mistakes and figuring things out. If you don’t give your people a chance learn for themselves, you limit the organization in two ways:

  1. They will never be any better than you.
  2. They will wait to do what they are told, because that is what you are teaching them to do.

Think about what you want your people to be capable of doing without your help, and make sure you are giving them direction that requires them to practice doing those things. It will likely be different than telling them what they layout should look like.

Improve your Cycle Time for Change

Coming back to the original metaphor, if you want fast changes to last, you have to work speeding up the organization’s cycle time for testing improvement ideas. Part of this is going to involve making that activity an inherent and deliberate part of the daily work, not a special exception to daily work.

Part of that is going to be paying attention to how people are working on testing their ideas. The Improvement Kata and Coaching Kata are one way to learn how to deliberately structure this work so that learning takes place. Like any exponential curve, progress seems painfully slow at first. Don’t let that fool you. Be patient, do this right, and the organization will slingshot itself past where you would be with a liner approach.

Small changes, applied smoothly and continuously become big changes very quickly.

Are You Overproducing Improvements?

Imagine a factory with a large monument machine. It takes several days to set up. When it does run, it runs very fast, much faster than you can actually use its output. Therefore, you take the excess output and store it to use later. Actually, you don’t know how many items you need to make, so you make as many as you can while the machine is available to you.

image

Some of that excess output may prove to be less useful than you thought, but there is pressure to use it all anyway since it was so expensive to produce.

After a run making items for one process, you change it over to make items for a different process, and build up a queue of output there.

When all of the output is used, it all may or may not work the way you expected it to.

Most of us would see this as a classic case of “overproduction” – overwhelming the system with excess output that hasn’t been checked for quality, that isn’t needed right now, and might or might not be useful in the future. But it seemed like good efficiency to make it while we could.

Our lean thinking tells us we want to do a few things here. Ultimately, we want to work hard to break up the batches, and make the value flow more evenly to each of the customer processes, and ultimately to the end customers. The work we must do to keep things moving smoothly and evenly will pay off in both tangible and intangible ways.

One of the primary reasons we push hard for 1:1 flow in the lean world is to enable one-by-one confirmation.

We want to test each item of output to confirm that it actually performs as expected rather than making lots of them without knowing if they are any good.

How Do You Produce Improvements?

Now, imagine doing improvements this way. What would it look like?

A process would be scheduled to receive the rapid output of the Improvement Machine.

The Improvement Machine would be set up over a period of several days to produce improvements for the target process.

Once it was running, we would run the Improvement Machine very fast for a week or so. It would produce improvements faster than the target process can really absorb them.

At the end of the run, we might test the improvements as a batch. We might not test them at all, but rather report that they have been implemented with the assumption that they will work. We would also have excess improvements stored on a to-do list for future use.

Those excess improvements might, or might not, prove to be useful, but we would have huge pressure to implement them because they are on the list.

Once the machine was done producing improvements for one process, it would be set up to produce improvements the same way for another.

We would measure how many times we were able to run the improvement machine in a year, not so much the actual sustained impact we were making.

Improvements that were made without the machine might not be measured or credited at all. Or worse, these rogue improvements might actually be discouraged since they are made by people who aren’t certified to run the machine.

Now… substitute “kaizen event” for “improvement machine” and see if it makes any sense.

Why Are Big Batches Necessary?

The reason the Large Monument Machine has to cycle batches of output to different customers is because those customer processes don’t have the internal capability to do what it does. We need an outside resource to do it.

The countermeasure we strive to apply in these cases is to identify the capability that the customer process does need. We then work hard to develop it on a scale they can incorporate into their daily work. This is typically smaller, more specialized, and scoped to their needs.

My purpose here, though, is to apply a metaphor, not to discuss the economics of large capital equipment.

When we “batch improvements” it is often for the same reason: The area that is being improved can’t do it themselves, so we have to dedicate a scarce outside resource – an improvement expert – to lead them through it. Since that improvement leader can’t be there 100% of the time, he has to work as hard and fast as he can when he IS there.

Making Improvements vs. Teaching How to Make Improvements

The countermeasure in both scenarios is the same: Develop the capability within the process. In the case of making improvements, this means asking ourselves “Why can’t they do it?”

All of these are harder than just doing it for them. But if we want improvement to flow, this is the work that must be done.

There Are No Silver Bullets

There are no quick, simple solutions

Occasionally I get an email from someone who asks a question like “How can I improve cycle time in the [fill in the blank here] industry?” Generally my reply is along the lines of “I don’t know, but I can help you figure it out.” I’ll give them some homework, often pointing them at Mike Rother’s Toyota Kata Practice Guide online, and asking them to do the Process Analysis step and get back to me with what they have seen and learned.

Lone Ranger with Silver Bullet
Who was that masked man?

This is usually followed by silence (cue the crickets here). Perhaps they think there is an easy answer and a single email can just tell them what to do to get that 20% performance improvement.

Unfortunately it doesn’t work like that. Process improvement involves work. There aren’t easy fixes (that last). There isn’t any solution anyone can give you that can just be implemented, nor can anyone learn it for you.

The real work is adjusting your culture

Digging a little deeper, if you want that productivity improvement to reach even a fraction of your full potential or sustain for any length of time, you have to go beyond technical solutions. When I said process improvement involves work, the technical mechanics are the easy part. The real work is understanding what social and cultural norms in your organization are holding you back and dealing with those.

Fortunately we have learned a lot more about the influence of the organization’s culture and how to influence the culture. But influencing the culture doesn’t happen by accident. And you can’t outsource your own thinking, reflection and learning.

 

A Machine Productivity Search Question

Here is another test or quiz question that showed up in my search logs:

a machine tool is producing 90 pcs per day .using improved cutting tools,the output is raised to 120 pcs per day. what is the increase in productivity of the machine?

I guess the answer seems pretty obvious…

90 x 1.33, rounded a bit, is 120, which gives us a 33% productivity improvement, right?

Not so fast…

(pun intended)

How fast does the machine need to run?

Is there demand for the additional 30 pieces per day, or are they just being put into inventory with the hope they will sell at some point in the future?

This is actually pretty common where cost accounting systems allocate overhead against production output rather than actual sales.

But what if you are only selling 90 pieces per day?

After three days you will have a day’s worth in inventory. You are running the machine more than you have to, adding wear and tear. You are consuming material to make parts you aren’t selling. At some point you are going to have to shut down the machine – idle it. What is your productivity then?

What Problem Are You Trying to Solve?

It always comes down to this question. Is there a real-world, customer-impacting reason you need the additional output? If so, then yes, this is a valid countermeasure, similar to one I have overseen myself. If the machine is too slow, what do we have to do to run it faster (while maintaining quality and not breaking anything)?

But if the machine is fast enough, then why are you trying to make it run faster?

And what will happen if we do? Use real numbers. You don’t have revenue until a customer with real money (not transfer pricing) actually pays for your product. Pretending otherwise looks great on the balance sheet for a while, but the paper profits aren’t tangible, you can’t use that “money” to buy anything else, or distribute to share holders. In fact, it is just money you have spent not money you have earned.

Machine Utilization at Home

At least here in the USA, a typical home washing machine will run a cycle in about 25 minutes. The dryer takes about 40 minutes to complete a cycle. If you wanted “maximum efficiency” from the washing machine, all you will get is a big pile of wet laundry. There is no point in running the washer any more often than once every 40 minutes. The dryer is pacing the system.

If I could modify the washing machine to run in 15 minutes instead of 25, how much more productivity do I have? The question is nonsense.

This example makes perfect sense to people. Then I often get arguments about how the factory floor is somehow different?

It’s The System, not the Machine

Key Point: You can’t look at one machine in isolation and calculate how “efficient” or “productive” it is unless it is pacing your system. In this case, we don’t have enough information.

Now, I know this example was just a made up case. But I have seen well-meaning production people fall into this trap all of the time. You have to look at the system, not individual machines.

Push Improvement vs. Pull Improvement

I’m writing up a proposal for a benchmarking and study week, and just typed the term “push improvement” as a contrast to a true “continuous improvement culture.” I wanted to explore that a bit here, with you, and perhaps I’ll fill in the idea in my own mind.

Push Improvement

A few years ago I was working with a few sites of a multi-national corporation. In one of their divisions, their corporate lean office was pushing various programs into place. Each site was required to implement, and was graded on:

  • 5S
  • Jidoka
  • Heijunka
  • Toyota Kata

plus a few other things. Those are the ones I really remember. Each of these programs was separate and distinct, they had been deployed on some kind of phased time-table over a few years. They also had requirements to maintain some number of Six-Sigma Black Belts and Green Belts in their facilities, with the requirement to report on a number of projects.

They brought me in to teach the Toyota Kata stuff.

In reality, while people taking the class generally thought it was worthwhile, the leadership teams were also a little resentful that all of this stuff was being, in the words of one plant manager, “pushed down our throats.”

Even the Toyota Kata “implementation” had a specific sequence of steps that the site was expected to check off and report their progress on. In addition, there were requirements for how the improvement boards would look, including the position of the corporate logo and the colors used – all in the name of “standardization.”

At the same time, of course, the plants were also measured on their performance – financial, delivery, quality, etc. These metrics were separate and distinct from their audit scores on all of the lean stuff.

On the shop floor, they had the artifacts in place – the boards, the charts, the lines on the floor, but were struggling with making it all work. There was no integration into the management system. Each of these was a program.

I should also point out that, ironically, the plant that was getting the most traction with continuous improvement at the time was the one that was pushing back the hardest against this rote, “standard” approach.

A few years before that, I had been working (as an employee) in another multi-national company. There was a big push from the executives at the very top to develop a set of metrics they could use to determine if a site was “doing lean correctly.” They wanted a set of measurements they could monitor from corporate headquarters that would ensure that any business performance improvement was the result of “doing lean” rather than something else.

Both of these organizations were looking at this as an issue with compliance rather than developing their leaders.

Implementations like these typically involve things like:

  • Developing some kind of “curriculum” and rolling it out.
  • Requiring sites to have a “value stream map” and a “lean plan.”
  • Audits and “lean assessments” against some kind of checklist.
  • Monitoring the level of activity, such as how many kaizen events sites are running.

I have also seen cases of an underlying assumption that “if only we can explain it well enough, then managers will understand and do it.” This assumption drives building models and diagrams that try to explain how everything works, or the relationships between the tools. I’ve seen “pillar models,” puzzles, gears, notional value stream maps, and lots of other diagrams.

In summary, “push improvement” is present when implementing an improvement program is the goal. Symptoms are things such as a project plan with milestones for specific “lean tools” to be in place.

The underlying thinking is that you are doing improvement because you can, not because you must.

This is, I believe, what Jeff Liker and Karyn Ross refer to as mechanistic lean in their book The Toyota Way to Service Excellence.

Relationship to the Status Quo

One of the obstacles that organizations face with this approach is the traditional relationship to the status quo. Most business leaders are trained to evaluate any change against a financial return based on the cost. In other words, we look at the current level of performance as a baseline; evaluate the likely improvement; look at what it would cost to get to that new level and ask “Is it worth doing this?”

If the answer comes up short of some threshold of return, then the answer is “no,” and the status-quo remains as a rational optimum.

Implication: The status-quo is OK unless there is a compelling reason to change it.

For the lean practitioner, this presents a problem. We have to convince management that there is a short-term return on what we are proposing to do in order to justify the effort, time and expense. Six Sigma black belt projects are intently focused on demonstrating very high cost benefit, for example. And, honestly, if you are spending the money to bring in a consultant from Japan and an interpreter, I can see wanting some assurance there is a payback.1

If the discussions are around “What improvements can we make?” and then working up the benefit, you are in this trap. Those benefits, by the way, rarely find their way to the actual P&L unless there is already a business plan to take advantage of them.

The root cause of this thinking may well be disconnection of continuous improvement from whatever challenges the organization is facing; coupled with assumptions that a “continuous improvement program” can be implemented as a project plan on a predictable timeline.

Pull Improvement

Solving Problems

The purpose of any improvement activity is to solve problems. Real problems. In my classes, I often ask for a show of hands from people who have a shortage of problems on a daily basis. I never get any takers. Since there are usually lots of problems – too many to deal with all of them – we need to be careful to work on the right ones. The ROI approach I talked about above is a common way to sort through which ones are worth it. We can also get locked into “Pareto Paralysis”

So which ones should we work on?

Inverting this question, when someone wants to make a change, put in a “lean tool,” etc., my question is “What problem are you trying to solve?” And “we don’t have standard work” is not a problem, it is lack of a proposed solution. In these cases I might ask “…. and therefore?” to try to understand the consequence of this “lack of…” The problem might be buried in there somewhere. But if the issue at hand is trying to raise an audit score for its own sake, we are pack to “Push Improvement.”

A meeting gets derailed pretty fast when people are debating which solution should be applied without first agreeing on the problem they are solving. The Coaching Kata question “Which one [obstacle] are you addressing now?” is intended to get help the learner stay clear and focused on this.

But long before we are talking about problems, we need to know where we are trying to end up. This is why the idea of a clear and compelling challenge is critical.

Challenge First

Organizations that are driven by continuous improvement have a different relationship with the status-quo. Those organizations always have a concrete challenge in front of them. In other words, the status-quo is unacceptable. “Today is the worst we will ever be.”

Cost enters into the discussion when looking at possible ways to reach that destination. But it does not drive the decision about whether or not to try. That decision has already been made. The debate is on how to do it.

The Challenge with Challenges

“Wait a minute… we have objectives to reach too!” Yes, lots of organizations set out objectives for the year or longer. Here are some of the scenarios I have seen, and why I think they are different.

The goal setting is bottom-up. The question “What can we improve?” cascades down the organization, and individual managers set their goals for the year and roll them back up. There may be a little back-and-forth, and discussion of “stretch goals,” but the commitment comes from below. In most of the cases I have seen these goals are carefully worded, the measurements delicately negotiated, with bonuses riding on the level of attainment of these objectives. I have used the word “goal” here because these are rarely challenges or even challenging.

The goal is based strictly on hitting metrics. I have discussed the dangers of “management by measurement” a few times in the past.

A pass is given if there is a strong enough justification made for missing the goal. Thus the incentive to carefully define the metrics, and include caveats and loopholes.

There are measurements but not objectives. Any improvement is OK.

Any true challenge is labeled as a “stretch goal” meaning “I don’t really expect you to be able to reach it.”

And, sometimes the end of the year is an exercise in re-negotiating the definition of “success” to meet whatever has been achieved.

None of this is going to drive continuous improvement, nor align the effort toward achieving something remarkable or “insanely great.”

But here is the biggest difference: FEAR.

Fear of failure. Fear of committing to something I don’t already know how to achieve. Fear of admitting “I don’t know.”

And fear breeds excuses and other victim language that makes sure success or failure was beyond my control.

Fearless Challenges

So maybe that’s it. The key difference is fearless challenge. So what would that look like?

Here I defer to Jeff Liker and Gary Convis’s great book The Toyota Way to Lean Leadership. But I have seen this in action elsewhere as well.

Some key differences here:

  • The challenge comes from above. It isn’t a bottom-up “what can we improve?” It is a top-down “This is what we need to be able to do.”
  • It is an operational need, not a process specification. In other words, it isn’t the “lean plan.” The process specification is what is created to meet the challenge.
  • The challenge is an integral part of developing people’s capability. Perhaps this is the key difference.
  • There is no fear because the challenge comes with active support to meet it. That support, if done well, is both technical and emotional. We’re in this together – because we are.

Improvement = Meeting the Challenge

Given that there is a business or operational imperative established, we are no longer trying to push improvement for its own sake. We have an answer to “Why are we doing this?” beyond “to get a higher 5S score.”

Now there is a pull.

In my Toyota Kata class, I give the teams a challenge that, in the moment, is seemingly impossible. That is intentional. I hear air getting sucked in through teeth. “No way!” is usually the reply when I ask how it feels.

Then, for the next few hours, the teams are methodically guided through:

  • Grasping the current condition – understanding their process as a much deeper level.
  • Breaking down the problem into pieces, taking on one at a time. First a target condition, then specific obstacles.

Depending on how much time they have, 1/4 to 1/3 of the teams crack the problem, a few excel and go beyond, and those that don’t usually acknowledge they are close.

The teams that get there fastest are the ones who get into a quick cadence of documented experiments and learning. They see the problems they must solve much quicker, and figure out what they need to do. I tell them at the start, as I hold up my blank Experiment Records, “The teams that get it are the ones who burn through these the quickest.”

In the process of tackling the challenge, they learn what continuous improvement is really about. I don’t specify their solution. Any hints I give are about what to pay attention to, not what the solution looks like. I don’t deploy tools or give them a template for the solution. At the same time, most teams converge on something similar, which isn’t surprising.

Taking this to the real world – I see similar things. Teams taking on similar challenges on similar processes often arrive at similar looking solutions. But each got there themselves, for their own reasons, often following quite different paths.

While it seems more efficient to just tell them the answers, it is far more effective to teach them how to solve the problem. That is something they can take beyond the immediate issue and into other domains.

Pull Improvement = Meeting a Need

In my post Learning to See in 2013, I posed the question nobody asks: Why are you doing this at all? I point out that, in many cases, value-stream mapping is used as a “what could we improve?” tool, which is backwards from the original intent.

If there is a clear answer to “Why are we doing this?” or, put another way, “What do we need to be able to do that, today, we can’t?” or even “What experience do we aspire to deliver to our customers that, today, we cannot?” then everything else follows. Continuous Improvement becomes a daily discussion about what steps are we taking to get there, how are we doing, what are we learning, what do we need to do next (based on what we learned)?

This is pull. The people responsible for getting a higher level of performance are pulling the effort to get things to flow more smoothly. The mantra here is “not good enough,” but that must be the form of a challenge that inspires people to step up, not punitive.

Then it’s easy because “they” want to do it.

image

Epilogue: For the Practitioner

If you are reading this, you are likely a practitioner – someone on staff who is responsible for “continuous improvement” in some form, but not directly responsible for day-to-day operations. I say that because I know, in general, who my subscribers are.

This concept presents a dilemma because while you are challenged with influencing how the organization goes about improving things, the challenge of what improvements must be made (if it exists at all) is disconnected from your efforts.

That leaves you with trying to “drive improvement into the organization” and “be a change agent” and all of those other buzzwords that are probably in your job description.

Here are some things to at least think about that might help.

Let go of dogma. If you think continuous improvement is only valid if a specific set of tools or jargon are used, then you are already creating resistance for your efforts.

Focus on learning rather than doing. You don’t have all of the answers. And even if you did, you aren’t helping anyone else by just telling them what to do. No matter how much sense it makes to you, logical arguments are rarely persuasive, and generally create a false “yes.”

Seek first to understand. Listen. Paraphrase back. Try to get the words “Yeah, that’s right.” to come out of that resistant manager you are dealing with. Remember your purpose here is to help line leadership meet their challenges. Often those challenges are vague, are negative – as in trying to avoid some consequence – or even expressed as implied threats. You don’t have to agree, but you do need to “get it.”

That’s the first step to rapport, which in turn, is necessary to any kind of agreement or real cooperation. As a friend of mine said a long time ago: “You can always get someone’s attention by punching them in the nose, but they likely aren’t going to listen to what you have to say.” Making someone wrong is rarely going to increase their cooperation.

All of this, by the way, is harder than it sounds. I’m still learning these lessons, sometimes multiple times. I’ve been on my own journey of explicit / deliberate learning here for a couple of years.

We have a couple of generations now of improvement practitioners who have been trained with the idea that “lean is good” (or Six Sigma is good, or Theory of Constraints is good, or…). Therefore, it follows, that these things need to be put into place for their own sake – because all of the best companies do them.

This approach, though, reflects (to me) a shallow understanding of what continuous improvement is all about. It skips the “Why?” and goes straight to “How” and “What.” My experience has also been that relatively few of the practitioners steeped in this can actually articulate how the mechanics of these systems actually drive improvement on a daily basis after all of the mechanics are in place beyond a superficial statement like “people would see and remove waste.”

It seems that implementing the mechanics is equated with improvement, when in reality, those mechanics are simply an engine for starting improvement.

Yes, the mechanics are important, but the mechanics are not the reason. We are leaving out the people when we have these discussions. What are they doing every day (other than “following their standard work”)? How do these mechanics actually help them move, as a team, toward a goal they cannot otherwise attain?

————–

1In its worst manifestation, this thinking can be a cancer on the integrity of the company, for example, GM has had a couple of scandals where it has been revealed that they calculated the ROI of fixing a safety defect vs. the cost of paying off wrongful dealt lawsuits. Don’t even go there!

Looking at some old notes…

I am cleaning out some old notepads. One page has the notes I took during a 4pm production status meeting during my first “get to know you” visit to this company.

In a box on my notes page it says:

image

“More information is not going to help until you begin to define how you expect things to run.”

What I had observed is their focus on the previous 24 hours metrics, with lots of speculation about “what happened” to account for the lost production. They were focused on incidents and, honestly, assigning those incidents as causes. Where they came up short, they were seeking more information about lost production incidents.

But everything I have written is just to give you a little context for the scribbled box on my notes a few years ago.

Today? They fixed it. This was one of the most dramatic culture shifts – from “find who to blame” to “let’s solve the problem” I have ever witnessed.

Reflection:

What are your daily meetings like? Are they focused on the stuff that went wrong yesterday? Or are they focused on where you are trying to go in the near future?

The Lure of Rapid Lean Transformation

image

Lean In A Box

I can see where the promise of a rapid “lean transformation” is appealing. We shop around, listen to presentations, read proposals, and find someone with a good “solution.”

For the next few weeks, maybe a couple of months, things move in a flurry. Lines are connected, visual inventory controls are established, your team is taught about the lean tools with simulations demonstrating the power of flow. Thus convinced, the team is expected to buy into the changes being made.

At the end, with much hoopla and pizza, we are done, and the new system is running.

The Grass is Greener – For a While

Now let me tell another story. It isn’t my story, I heard it during a presentation by Jim Sorensen in Seattle. I’m sure he tells it much better than I will. Jim talks about his neighbor who has a fantastic, immaculate lawn. Jim recounts that, one day as he was chatting with his neighbor, shared a little envy – “I wish my lawn looked as good as yours.” The neighbor’s response was “Jim, if you had a lawn like mine, in three months it would look like your lawn does now.” His neighbor works on his lawn. The immaculate appearance was important to him. For Jim? He chose to spend his time doing different things, which is fine. But at the same time, he, we, shouldn’t expect an immaculate lawn to stay that way unless we are willing to do the work.

Likewise with these rapid implementations. To continue to metaphor, we rip out your old grass, put down beautiful fresh sod, take the photos, and move on to the next house. But if you don’t fundamentally change the way you maintain that new lawn, by the end of the year, it will look like your old one.

You Are Transforming Your Culture

Continuous improvement as “the way we do things” is a fundamental shift in the way people think, and the way they spend their time. There is no “set it and forget it.” Your processes are either improving or eroding. You must exert continuous active control by the people who are closest to the work just to keep up with the entropy. Their “buy in” is not even close to being enough to make it work. They need different leadership.

Many years ago I was interviewing at a Big Household Name Company that looking to accelerate their “lean deployment.” They already had a guy with incredible qualifications working very hard to teach the things they needed to understand.

Every person that talked to me asked “How can we go faster?” My reply was “Listen to what [your lean director] says and do it. He knows what he is talking about.” Unfortunately, he was telling them that there were no easy shortcuts, and that they had to begin thinking about production in a fundamentally different way. My feeling was they were looking for someone to tell them there was an easier way to do it.

I run into that a lot. An organization wants the results, they want the immaculate lawn, but they want someone else to do the work to make it that way, then they want the outcome.

The problem is you can’t outsource your own thinking.

More Cycle Time Questions from Search Results

A couple of more exam questions showed up in search results.

4. what can happen if the cycle time is much shorter than the takt time

The searcher didn’t even bother typing this one – just cut and paste the entire thing, including the question number.

Fortunately the answer is really easy:

Raiders of the Lost Ark warehouse

If you keep this up, you’ll need another building.

OK, here’s one that is a little more subtle:

185 units in 14 hours is what cycle time

Hmmm. My first thought is to go back to Who is Grading the Questions?

think whoever wrote this question is looking for something like 14 hours  (840 minutes) / 185 units = 272 seconds / unit (more or less). But that’s an average, it isn’t a cycle time.

The Average Rate of Output is not “Cycle Time.”

The average doesn’t give you any more information than the original question. This is simply a rate of output: 185 units in 14 hours. Cycle time is the measured time to complete one cycle.

There might be a single cycle that produces a batch of 185 units. Let’s say, for example, in a cure oven process that takes 14 hours to load, run and unload. Then the cycle time is 14 hours.

If the pieces are moving in a sequence of operations, but in a lot (which is different from a batch), where Operations 1 is completed on all 185, then Operation 2 is completed on all 185, etc. and maybe that all takes 14 hours? I have no idea what the cycle time(s) for the operations are. Most of the time the units are waiting in queue for the other 184 items to be done at each operation.

If we have true one-by-one flow then I have at least 185 cycle times. Hopefully they are all about the same, but likely that isn’t the case.

Are we measuring exit cycles (the cadence of output at the end of the process), or operator or machine cycle times?

By taking the average we are obscuring all of this information. Calling the average the “cycle time” just makes it worse because it gives people the impression that they are the same.

Cycle time is not calculated. It is measured. You cannot determine cycle time by applying mathematical operations on numbers. You have to go observe with a stopwatch.

And finally:

within each four hours worked, workers can take a total of 48 minutes in allowance (so allowance factor is based on workday). if the observed time is 6 minutes, and performance rating is 95%, what is the standard time (in minutes; give three significant digits after the decimal point)?

Even if I could understand the question, down to thousandths of a minute? Seriously?

</rant> <!– Until next time –!>

 

 

Who is Grading the Questions?

Once again the search terms have revealed an interesting test question. Let’s parse it and see what we can learn.

2. the cycle time to complete a final step on an assembly line is normally distributed, with a mean of 4 minutes and a standard deviation of 1 minute.1) at the end of an 8-hour shift, how many units will have been assembled on average?

The question is about exit cycles – the cadence at the output of a production process of some kind, in this case an assembly line.

Measuring and plotting the variation of exit cycles at the customer end of your production process is a great way to get a handle on how much variation there is.

This question, however, reveals a level of simplistic understanding in the mind of the person who wrote the question of how these things work.

Answering the Question

First, we have to assume that this assembly line (which implies manual work) takes no breaks during their 8 hour shift. We have no information that suggests otherwise.

That means we have 8 hours x 60 minutes = 480 minutes of working time.

Intuitively, if the exit cycles are normally distributed (which implies the distribution is symmetric), with a mean of 4 minutes, then we should be able to simply divide to get the average number of units built during each shift.

480 / 4 = 120 units

Which in the long-haul is close, though it will take a lot of iterations to converge on that. Running about 65 iterations of a random number set with a mean of 4 and standard deviation of 1, I got an average daily production of 120.1, a high of 127 units, and a low of 115.

But Exit Cycle Times Aren’t Normally Distributed

This is a problem with a lot of the “statistics” I see being kicked around today.

This is a histogram of 36 actual exit cycle times from a real production line.

image

The “Cycle Time” bucket numbers on the horizontal axis represent the top of the range. So the high bar says there were 10 cycle times between 25 and 30 seconds.

The mean of the data set is 42, which is actually one of the less frequent values.

The first thing that jumps out is that this data set might have two peaks (be bimodal). I would want a lot more data before I drew this conclusion, however let’s assume it is for the discussion because this is quite common.

A bimodal distribution implies there are two different processes running. If we looked at a run chart of individual cycles, we would probably see one of two things:

  • Clusters of longer times spaced between clusters of shorter times. This would be the case if the line is running lots or batches, then switching over.
  • A repeating cadence like “short-short-short-long, short-short-short-long” which would indicate really good production leveling.

But all of that is a sidebar. The real issue I have with this “homework question” simple: Cycle times are (almost) never normally distributed.

There is a minimum time that can elapse between the completion of one unit and the completion of the next, but there is no theoretical limit on the length of delay. These distributions (almost) always have a tail to the right.

So once again, be very careful about blindly using averages (arithmetic means) unless you understand the whole story.

The Test Question Misleads the Students

And this is my problem with questions like this on exams and homework, especially in classes that purport to be teaching how factories run. Even when using a distribution, the problems almost always default to a symmetric distribution when real world factory-related data sets are rarely symmetrically distributed.

You are teaching your students a simple solution that won’t work in the real world without explaining why.