A long, long time ago – in the days when computer programs were coded as holes in punch cards – I was in ROTC* in college. Twice a year we had a “PT” (Physical Training, I think) test that consisted of measured performance on five “events.” One of those events was a 2 mile run. To get a maximum score of 100 points, the participant had to complete the 2 mile run in 14 minutes and 9 seconds. Why? I have no idea. But that was the way it was.
My buddy John and I enjoyed running, and would often work out together. Our school was in Potsdam, New York, a place known for rather brutal winters, so we ran on a 1/10 mile indoor track.
We practiced the PT test. John would track our total time for 2 miles (20 laps around the 1/10 mile track). I would measure lap times. Since 14 minutes is 840 seconds, we knew that if we could consistently make 42 second laps, we would complete two miles in 14 minutes, and get the maximum score with 9 seconds to spare.
The track had hash marks at each quarter point, so we knew we had to hit quarter 1 between 10 and 11 seconds, half way at 21, the 3/4 mark between 31 and 32, and the lap at 42. We would check and adjust our pace accordingly, striving to hit exact 42 second laps every time.
To be clear, we could hold that pace many times further than 2 miles. It wasn’t a matter of conditioning. We weren’t going all out. We were going fast enough. And that was the point.
When we took the test, other cadets were going all out, passing us, and turning in much faster times. Others would try to “pace themselves” and then sprint as fast as they could for that last lap. As a general rule, although the instructors were calling out elapsed times as people went by, these cadets weren’t all that aware of the speed they had to hold. They were just going as fast as they could.
Meanwhile, John and I, running together, and tracking our cycle times (lap times) vs the takt time (42 seconds / lap) would come in at pretty much exactly 14 minutes and get the same score as everyone who had finished ahead of us: 100 points.
After our timed run was done, we would keep running, offering encouragement and pacing for those cadets who were struggling a bit. Everyone finishes, nobody left behind.
A couple of the instructors were curious why we didn’t go for a faster time. And many times we did when we were just working out. We were capable of breaking 12 minutes – not competitive times in a track meet, but respectable. The simple fact was that going faster wasn’t necessary to accomplish the goal.
Takt Time and Cycle Time
This is the whole point of having a takt time. It answers the question, “How fast must we go?” It doesn’t answer “How fast can we go?” nor does it answer “How fast should we go?” I fact, John and I could have run those laps almost (but not quite) half a second slower than we did – which would have eaten into the 9 second buffer we established. Aside from making the math easier, that buffer also gave us a small margin for even something as bad as taking a stumble and standing back up. Also, of course, we could make up 5-10 seconds a lap if we really had to. But we never did. Time: 14:00. We were very consistent.
Rate vs. Output
I encounter a lot of production managers who are so conditioned to focus on the daily output that they don’t even think about the critical factor: How fast are you running vs. how fast do you need to run? In other words what is your rate of output vs. your takt time?
Instead they tend to, at best, count units of output without really paying attention to the time interval between one and the next. In the worst case many units are started at once, and people swarm from one operation to the next during the day – the equivalent of that mad sprint trying to make up as much time as possible. They don’t really know if they will succeed or not until the end of the day (or month!).
It Isn’t a Race
The “just” in “just-in-time” is “just enough resources” to “just make the output you need” in any given time interval. As the operation is streamlined, the same effort is able to accomplish more. Where to put that additional capacity (which costs nothing additional since it has been there all along) to create more value should be the challenge the organization is trying to meet.
My experience has been that managers and leaders often struggle to adopt this “rate” mindset and let go of chasing an inventory number. In the words of the late great philosopher Kenny Rogers – “There’ll be plenty of time for counting when the dealings done.”
*ROTC (Reserve Officers Training Corps) is a U.S. program where college students can earn a commission in the U.S. Armed Forces while earning their degree.
MONDAY: 2 PERS 1 MACHINE. TODAY: 1 PERSON 2 MACHINES
On a Thursday afternoon in the summer of 1997 I sent that pager message (remember pagers?) to Rick from the factory where I had spent a week working with Mr. Shimura of Shingijutsu and Reiko, his interpreter.
I knew that Rick would be wrapping up a class teaching the basics of kaizen events to a group of suppliers and if I were lucky, he would see the pager message and use it as a reinforcement to the participants. Rick and I usually alternated teaching that class, sometimes we taught it together. We were good work partners, finishing each others’ sentences and the mutual respect was very high.
I was on-site at another supplier. We were there to help them take some first steps toward “lean production.” Our goal, at least the idea, was that we would work through the process of making significant improvements with the thought that they would learn enough to try it themselves.
This was not my first visit – the episode with Mr. Iwata that I relate in my third post to this blog had happened there a couple of months earlier, and that visit had resulted in my company offering up Mr. Shimura’s time on our dime.
This may well have been “an offer they couldn’t refuse” and I’m not sure everyone there saw it as help. We were from their 800 pound gorilla customer, they had trouble making on-time deliveries, and sometimes that isn’t the kind of help that you want. From their perspective their biggest customer had people who knew their way around a factory spending days on their shop floor and, most certainly, ascertaining how much more productivity was possible if only, well, the buyers squeezed them hard enough. It didn’t really work that way, but it had worked that way in the past, so who could blame the suppliers for thinking this was a more sophisticated way to audit them?
Anyway, we had worked through the week to carefully look at the tasks involved to unload, load, and machine a single part on a large linear milling machine. Mr. Shimura was there asking questions, not so much from curiosity but to direct my eyes. I’m sure he already knew the answers. As we dug into the timing, it became clear that there was enough operator waiting time as the part was being milled that a single operator could, theoretically, unload and load an adjacent machine – operating two of them at once.
So we carefully worked out the chorography required to make it work, and on Thursday mid-day it all came together. The work was flowing, the parts were flowing. It was really a thing of beauty.
Friday morning we would report out the week to management, and Friday afternoon I would head to the airport to go home to Seattle.
But I had some worries as well. Although the company President, and the VP of Operations were supportive, their support was along the lines of welcoming everyone into the plant, making it clear they were happy to see us, attending the final report-out and endorsing our efforts.
I was still pretty knew at this. I was making the transition from teaching classes and running simulations to making real change in real factories (that weren’t mine!). I was really fortunate to have a lot of 1:1 time with Mr. Shimura and Reiko. I asked questions, he patiently taught me how to use the standard work combination sheet, and other nuances of kaizen and flow production. I got a lot more out of that week than the supplier did simply because I was there spending time with Mr. Shimura and taking advantage of every second I could. I had 1:1 time because none of the supplier’s managers were seeking him out to learn from his vast experience.
Some quotes I will never forget: “If I see something is hand written, then I know at least one person has read it.”
“If parts that are in tolerance don’t fit, it is a problem with the tolerances.”
(Walking through the shop) “Does this company lose a lot of money?” Reply: “No, they are very profitable.” “Then their prices are too high.”
In the end, though, I am equally certain that come Monday morning the work sequence we had so carefully worked out – at great expense to my company for my time, my travel, Mr. Shimura, his interpreter, and others – was never repeated again.
Well, we can all blame “management commitment” because that is really easy to do. But I put equal weight on our paradigm of improvement at the time. The idea that, in 4 working days we could institute a change that flew straight against the operational and cultural norms of the company and expect it to last any longer than until we were out the door was, well, ludicrous.
Why should we expect anything different?
It is ludicrous in any company, whether this work is being brought in from outside or internally generated.
The people who have to manage the daily work, whether they were involved in this exercise or not, have no paradigm for dealing with the myriad of issues that are bound to be surfaced after we pulled all of the buffers out of the material and the time. Yes, it can work, IF we understand the conditions required for success, and IF we pick up right away when those conditions aren’t there and IF we respond to fix it very fast. Then, yes, it can work.
It will be more time and trouble than it was before, though, unless the next things are also done.
For at least some of those issues – maybe not all of them, but always working against a couple of them – seeking out why those issues happened and dealing with the causes.
Just to keep this tiny two-machine “work cell” operating in this large factory would have eventually engaged every support system they had.
That’s the whole point, actually, of a model line. It isn’t building the model line. It is what you have to fix in your systems to keep it going.
Many years later I spent a week on another company’s shop floor with their internal kaizen team and getting an andon / escalation process up and running was the only thing we were working on that week. That process is just as important, if not more, than the baseline work of flow. Because without it, your flow will fall apart.
This is the part of the process that engages people. Putting in the baseline process is the easy part. Fielding the problems that flow surfaces – that takes changing the day-to-day routine in the workplace, and is a lot harder. That is where the culture change comes into play. Actually it is more than engaging people. It engages specific people: This is the part that must engage the leaders. They must lead, guide and coach process of working through all of the issues so stability can be reestablished. Then challenge the team to get to the next level.
But all of that is what I know now. I had the knowledge back then, but not the deep understanding.
So – I am thankful for that week because my understanding of what I had been teaching for months easily doubled… twice in those few days.
I was back there a few more times, they even gave me a badge (which I still have somewhere) so I could let myself in. One time I spent two straight weeks there. They were good people.
But we were applying work to the technical systems, and never really dealing with their default responses to problems, their culture, the way they went managing their daily work.
I know so much more today it is actually humbling to write this. And I still have a lot to learn. We all do.
The company I was working in? They were sold, and sold again. I think they are still in business, but I wouldn’t know anyone there.
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.
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.
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:
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:
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.)
“Are you ahead or behind?” seems an innocent enough question.
But when asked by a Toyota advisor, the simple process of becoming able to answer it launched Liz McCartney and Jack Rosenburg on a journey of finding consistency in things that were “never the same” and stability in things that “always changed.”
Getting Homeis, first and foremost, a story. And, with the “business novel” being an almost worn-out genre, seeing a non-fiction story was refreshing. So when Chet Marchwinski from the LEI offered a review copy to me, I accepted.
For the story background, I’ll leave it to you to read the blurb on Amazon.* Better yet – read the book – and it is worth reading. I’ll say that right up front.
Yet with stories like this it is all too easy to dismiss them because they have different circumstances from “my” specific case and say “Yeah, it worked there, but won’t work here.”
I would contend, however, that in this case “it worked” in situations that are far more difficult than anything we are likely to encounter in most organizations.
What I want to do here is help pull their specific achievements into more general application – what lessons are here that anyone can take away and apply directly.
What They Achieved
I can’t think of a lot (any?) business circumstances that would have more built-in variability and sources of chaos than the process of rebuilding communities after a disaster such as a hurricane or flood.
Every client has different circumstances. The make, mix and skill levels of the volunteer workforce changes continuously. Every community has different bureaucratic processes – not to mention the various U.S. government agencies which can be, well, unpredictable in how and when they respond.
Yet they have to mobilize quickly, and build houses. This means securing funding, getting permits, mobilizing unskilled and skilled labor, and orchestrating everything to meet the specific needs of specific clients on a massive scale… fast.
How They Achieved It
When they first connected with their Toyota advisor, the simple question, “Are you ahead or behind?” prompted the response that drives all improvement, all scientific advancement, all innovation:
“We don’t actually know.”
Actually they did, kind of, but it was in very general, high-level terms.
And that is what I encounter everywhere. People have a sense of ahead or behind (usually behind), but they don’t have a firm grasp on the cause and effect relationship – what specific event triggered the first delay?
This little book drives home the cascading effect of ever deepening understanding that emerges from that vital shift from accepting things as they are to a mindset of incessant curiosity.
Being able to answer “Are you ahead or behind?” means you have to have a point of reference – what is supposed to happen, in what order, with what timing, with what result. If you don’t know those things, you can only get a general sense of “on track” or not.
They had to develop standards for training – what to train, how to train – volunteers! – , which meant challenging assumptions about what could, and could not, be “standardized.” (A lot more than you think.)
A standard, in turn, provides a point of reference – are we following it, or are we being pushed off it. That point of reference comes back to being able to know “Are we ahead or behind?”
It Isn’t About the Specific Tools
Yet it is. While it isn’t that important about whether this-or-that specific tool or approach is put into place, it is critical to understand what the tools you use are there to achieve.
As you read the book, look for some common underlying themes:
Information as a Social Lever
The project started revolving around the ahead/behind board.
In the “lean” world, we talk about “visual controls” a lot, and are generally fans of status boards on the wall. We see the same thing in agile project management (when it is done well).
These information radiators work to create conversations between people. If they aren’t creating those conversations, then they aren’t working. In Getting Home it was those conversations that resulted in challenging their assumptions.
Beyond Rote Implementation
Each tool surfaced more detail, which in turn, challenged the next level. This goes far beyond a checklist of tools to implement. Each technical change you make – each tool you try to put into place – is going to surface something that invites you to be curious.
It is the “Huh… what is happening here?” – the curiosity response – that actually makes continuous improvement happen. It isn’t the tools, it is the process of responding to what they reveal that is important.
Like the tools it describes, Getting Home is an invitation, and that is all, to think a little deeper than the surface telling of the story.
My challenge to you: If you choose to read this book (and I hope you do), go deeper. Parse it. Ask “What did they learn?” ask “What did this tool or question reveal to them, about them?” And then ask “What signals did they see that am I missing in my own organization?”
*This is an affiliate link that give me a very small kickback if you happen to purchase the book – no cost to you.
The factory is running complex automated equipment. At the morning meeting today we heard “machine x was down for broken bolts.” Actually “again.”
Background – the bolts in question resist pressure in molding equipment. The details of how the equipment works aren’t relevant here. This isn’t the first time I have heard of “broken bolts” being the source of downtime.
After the meeting, I saw the production manager on the shop floor. “So, tell me about the broken bolts.” We know each other, he is happy to.
We went to the machine in question. “How do bolts break?” (These days I ask “how?” rather than “why?” because I am interested in the mechanism of failure rather than whatever mistake is being made.
I am asking that question for a simple reason: Grade 8 bolts don’t “just break” in equipment that is properly engineered and assembled as designed. Something, somewhere, is stressing things beyond their limits.
By accepting that “bolts break” and “shafts get stripped” and “hoses fail” we move into the realm of “normalized deviance” where we accept as OK something that actually is a sign of a serious problem.
This is no different than accepting that “o-rings burn through sometimes but it hasn’t caused a problem so it must be OK.”
How do Bolts Break?
A few possibilities came up.
The bolts might be just a bit too long allowing movement.
The might be loose.
“Why is a ‘too long’ bolt even needed in the plant?” – that is still an open question.
“What is the torque spec?”
“… I don’t know.”
Now we are getting somewhere.
Once we hit the threshold of knowledge, we know the next step.
This search question landed someone on my site yesterday, and I thought it would be a good one to try to answer specifically:
why is lean manufacturing preferred to implement target condition as compared to target?
In other words, what is the difference between a “target” and a “target condition?”
Where this gets sticky is that there isn’t any canonical definition of either term. There are people who use “target” to describe what I mean when I say “target condition.” So I think it is probably best to focus on that term: “Target Condition.”
“Target Condition” = “Target Process”
A team I am working with is bringing up a new (to them) product line. Their short-term target is to complete 8 units / day. But just saying that doesn’t describe the way they want the process itself to operate.
The Target Condition for the line is unit-by-unit flow in critical parts; with order-by-order flow in others (where we can’t overcome batching at the moment). To that end, we have created some guidelines for the layout and movement of work; limits on work-in-progress inventory, etc.
We know that this can’t be achieved right away, but aren’t sure what problems will surface as we try. Thus, the effort is focused on trying to operate to the target process in order to surface those obstacles so they can be systematically addressed.
So – to answer the question “Why [does] lean manufacturing prefer to implement a target condition as compared to a target?” – Unless we know how we want the process to operate, we have no point of comparison for how it is actually operating.
Without the ability to compare “What should be?” with “What actually is?” we cannot identify the gaps we need to close, the problems we need to work on to get there.
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?
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.
What you measured.
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.
What you saw.
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.
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:
They will never be any better than you.
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.
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.
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?”
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.
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.