Category: The Basics

Posted on

There Are (almost) No Big Problems

In a “management by metrics” world, problems are detected when performance indicators are off track. Perhaps inventory is too high, first pass quality is a problem. Maybe operational availability is tanking.

Once the problems are abstracted into numbers, the numbers become the problem. The solution, then, is usually a directive to reverse the trend, to improve this measurement or that measurement, to get things back on track.

Here is the rub: The numbers aren’t the problem. They don’t even tell you what the problem is without a whole lot of investigation, digging, and stratification. And why was this investigation and stratification necessary in the first place? Because now you are trying to sort out a batch of problems that weren’t dealt with, one-by-one, at the moment they occurred.

The further you go up in the organization, the more things are aggregated and summarized. And the more they are aggregated and summarized, the more things look like big problems, even though they are composed of many (hundreds, sometimes) of little problems.

Let me cite an example. I was in a factory where the site manager was proudly showing off his real time display of Overall Equipment Effectiveness (OEE). Each time the equipment slowed, for any reason, the display would immediately change. He could see, at an instant, how the day’s OEE compared with his target, and, he said, “take action.”

But exactly what action is he going to take?
Even the real-time display lags the actual problem.
Two weeks ago a lubrication point was missed. Today something is overheating, and we need to slow or stop the machine to deal with it.

A bracket securing a roller is loose, today the machine is stopping all the time as they clear jams.

A hole in a screen let chips and debris clog a filter, and the coolant pumps are overheating.

This list can go on. The point is that the things that actually slow down or stop the machinery are second, third, fourth levels in chains of events. The actual problem had no immediate effect on the machinery.

In this system, the very best they will ever do is fix it fast and hold the number at some level. They will never be able to actually improve it, because they aren’t dealing with the underlying systemic issue: They aren’t finding and dealing with the actual root causes.

When you get to financial measures, things are even more abstract.

Inventory levels (or inversely, inventory turns) is a great example. “We have too much inventory!” “Our inventory levels are above the industry norm!”

In the boardroom, or in the Chief of Operations’ office, this is all they can see. Because most leaders in that position really like direct action, they.. um.. “direct” that some “action” be taken.

So the organization goes to war against inventory.

Two levels down, “We have too much inventory” is still characterized as the problem because that is what they have to report every month.

Two more levels down it is often still attacking the symptom – too much inventory.

But inventory isn’t the problem.

The problem is an engineering change that missed one part on the bill of material update, delaying production for a day while all of the other parts continued to roll in.

The problem is a paint system that is unreliable, so the factory obsesses on maintaining four hours of buffer on either side of it.

The problem is pressure to keep the line moving, so people work ahead, and push incomplete or problem units into the “hospital” for later repair.

The problem is that the upstream processes have to be ready to respond to massive fluctuations in assembly’s demand.

The problem is a broken jig, local initiative to make something else instead, resulting in too much of what nobody needs and none of what they do – because they don’t want to waste time doing nothing.

An additional problem is that the typical organizational response to these problems is to add more inventory because each local unit needs to protect itself from the dysfunction problems of their suppliers and customers.

Worse, just “taking out inventory” is going to tank everything else because the underlying problems are still there.

Inventory isn’t the problem.

The problem is that each of these small problems is too small to bother addressing as a systematic breakdown that leads to “too much inventory.” While the high-level leaders are looking for a big problem, they are missing their real responsibility.

It isn’t to “do something about inventory.”
It is to ensure that the small problems that occur every day, the ones which cause all of that inventory to accumulate in the first place, actually get addressed. Actually no. Their responsibility is to ensure there are systems in place which catch those problems and address them. They do this by teaching, setting example, then checking.

Leaders – if you want to “do something about inventory” you have to do it by setting an expectation that:

  • Processes are well defined.
  • Those processes are followed.
  • When there is a problem following the process, it is raised immediately.
  • When a problem is raised, it is swarmed, fixed, understood and prevented.

You handle big problems by making sure the small ones are dealt with, every day, all day.

Then your OEE will go up quickly. OEE is an indicator of how well you respond to problems, not how well your machines run.

One more thing – for my Health Care readers.
You can substitute “medication errors” for any of this. But until there is a system in place that alerts anytime someone spots the possibility of confusion, medication errors will occur at pretty much the same rate they always have.

Posted on

The Paper Shuffle

This post is in response to Ethan’s post on “The White Board.” He asked about the paper shuffle – admin processes.

This seems to be a hot topic today. First, because these techniques are increasingly being applied to operations that don’t do manufacturing. They are service delivery, information processing, and creative processes instead. And second, I think, because manufacturing companies are realizing that these paper (or information) processes are often the ones that cause havoc on the shop floor.

Many consultants (and others) like to differentiate between “manufacturing processes” and “non-manufacturing” or “administrative” (or “office”) processes and say that there is a fundamental difference in how these types of processes need to be approached.

They go so far as to produce separate products and methods for “administrative kaizen.” Part of this, I suppose, is sales and marketing. But part of it is, I think, a sincere belief.

Ironically, these same people are (usually) cheerfully adamant that there is no fundamental difference in approach for kaizen between custom circuit boards and airliners. They are right about this. But I question whether 747’s and circuit boards are less different than lawnmowers and insurance claims.

I do believe that, in most cases, there has not been a lot of thought applied to what administrative processes are actually trying to accomplish, nor exactly what tasks are required to do it. But this isn’t something that makes administrative kaizen unique, it just requires a bit more work up front.

The First Questions

These questions should really be asked for any kaizen activity. For this process:

  1. What is the intended outcome?
  2. How is the actual outcome checked?

To paraphrase, what, exactly, does the customer expect? How does the customer expect it? When does the customer expect it? Where?

and.. how do you verify that what you delivered, how you delivered it, when you delivered it, where you delivered it, and exactly match what the customer expects?

Answering these questions gives you the definition and confirmation criteria of a “defect-free outcome.” If you don’t have answers to these questions STOP, because you will have no way to know if your process works or not.

The Second Questions

  1. What tasks need to be performed, in what sequence, to assure the defect-free outcome (defined above) is produced?
  2. As you perform each task, how can you check that it was done as expected, in the sequence expected, in the time expected?
  3. As you perform each task, what is the expected result of that step and how do you check that you got it?

In other words, just what is required to just meet the customer’s exact requirement? This is the “just” of “just in time.” (At least part of it.)

The Third Question

What conditions are required for the process to succeed?

What information, tools, materials, environment, skills, software, hardware must be present?
If a manufacturing process, what is air pressure required for your tools to run to the proper torque?
What information must be present for the approval process to evaluate?
What parts are required?
What forms must be signed? By whom?

In a larger sense, this question defines what your process needs from its suppliers. Again, “just” what is needed? “Just” when is it needed?

Between these three sets of questions you have (hopefully) defined an ideal. Your actual process might not come anywhere close to the ideal, but until you think through what is necessary, there is really nothing compare to. You could look at your current process and say “this is pretty bad” (or “pretty good,” for that matter) but I ask “Compared to what?” and that comparison is vs. the ideal.

It is certainly true that (usually) manufacturing processes are further along with these answers, but that doesn’t mean they are fundamentally different.

What about one-time processes?

There is no such thing.
“What? Is he crazy? We have to customize every time!”
Yes you do customize. But if what you did was totally unique and had to be created from scratch each time, then you are claiming you have no experience in your field. Even something as uniquely complex as a building construction project or a tailored treatment plan for a cancer patient, still has answers to the above questions. There is some outcome you are trying to achieve, and you really ought to know what it looks like. And you construct a specific sequence of tasks which you believe will get that done. And those sub-tasks are all things you already know how to do, or have a good idea what to expect when you try them. You still have (or should have) a verifiable outcome, and your best estimate of what is required for success. You may answer these questions every time, but you still answer them.

What Kind of Process?

Your improvement approach depends a little on the nature of the process. This has less to do with “manufacturing” or “non-manufacturing” than it has to do with the nature of the variation drivers.

Is largely repetitive?
A surprising number of administrative processes fit into this category. Almost all accounting transaction processing does. So do order entry, insurance claims, medical records updating, routine approvals (contracts, loans, etc), and preparing routine reports. Those are just the ones that come to mind right now.

What makes them seem different from “manufacturing” processes is that no one has ever really thought of them as repetitive. But once people grok that these tasks are mostly doing the same thing over and over, then just about every trick in the manufacturing kaizen book directly applies.

Here are a few things to keep in mind:

A lot of repetitive process are buried in noise. People do not have what they need, so they have to go on safari. In manufacturing it is possible to see this happening because the Team Members usually have to stop working and go looking. But administrative people do their hunting and gathering from their desks, so they (and their leaders) are often unaware that they have “stopped working” – but they have. They just look like they are working. The process feels irregular because the hunting and gathering gets mixed in with the “doing.”

In manufacturing we say “do not launch the job until the parts are available.” The solution is the same in admin – a front-end process of triage.

Triage is a term from the medical community. In a largely repetitive administrative process, the idea is to ensure the people have what they need before they start. A quick assessment of the documents can quickly divide incoming requests into three categories:

  1. Everything needed is here, it is routine. Drop into the work queue.
  2. It is routine, but incomplete. Finish the information gathering first. Do not send it to the work queue until it is complete and routine.
  3. This is a true exception. Process it off-line, not as part of the routine work.

Consider the alternative. Most of the packets can be processed in an hour. But if one is incomplete, there is another hour or two of research, interruptions, information gathering to do. While that one is being worked on, there are two more routine ones that are not getting done. Every time the process is interrupted, more work falls behind.

A true exception that takes two days, meanwhile, stalls 16 routine ones.

By separating the routine from the non-routine, you allow at least part of the process to stabilize. With stability comes standardization, and with standardization comes kaizen opportunities.

Is is truly non-repetitive?
If you apply the thinking described above, surprisingly few processes drop into this category. But there are true exceptions. Preparing complex bids and proposals, true research and design, some trials and tests, and true creative work come to mind as some possible examples.

Nevertheless, “the questions” that I posed at the beginning still apply, and the better you ask them, the more clear you are.

In the end, you want to have a plan. This consists of:

  • A defined, verifiable outcome. A definition of “success.”
  • A defined series of verifiable tasks, listed in a specific sequence, with expected timing.

To put the same thing in the terms used in “Decoding the DNA of the Toyota Production System” – your activities are “Highly specified in terms of content, sequence, timing and outcome.” Further, you have checks on execution (content, sequence, timing) and checks on the outcome.

What’s the point? Kaizen is a process of applying structured learning.

In both of the above cases you have defined what you are going to do, and defined what you expect as a result. You are checking to see if what you actually do differs from what you planned to do; and you are checking to see if your actual result differs from the expected result.

When you see a difference STOP. Does this mean literally stop in place? Sometimes, but usually no. But it does mean to stop pretending you are still following the plan as intended, because you aren’t. You are now processing an exception to the plan. This simple consciousness is the first step in learning.

Why did the Team Member have to depart from the plan? Maybe there was something you didn’t think of. Maybe you designed a process that is actually impossible. Maybe there is a vital tool, fixture, part missing. Maybe information is missing or wrong. Whatever it is, see it, fix it, understand why it happened and then fix that.

What Makes Administrative Kaizen Hard?

The “Big Picture” is often invisible.
Many administrative processes involve a lot of complex interconnections. Nobody ever designed them, they just morphed into what they are as local people tried to deal with the effects of system problems. Since there is no real architecture, it is probable that nobody actually knows how the whole things works, or understands the unintended consequences of local countermeasures that cause problems elsewhere. (A disturbing percentage of corporate information systems follow the same general architecture.)

Countermeasure
There are two broad approaches. The first is to decide that whatever is the current process, it is too complex and too broken to fix. Start over. Honestly, I think this isn’t done often enough. Go through the questions listed above and systematically engineer how things are supposed to go.

The other (and more common) approach is to try to fix it. That means:

  • Thoroughly understanding how it works today.
  • Looking for:
    • Ambiguity – places where people are unsure what is expected.
    • Breakdown – places where there is a difference between what you expect (should happen) and what really happens.
    • Rework – places where people have to fix something that should have been done differenty.
    • Overprocessing – places where people are doing, again, something that has already been done. (Data entry is notorious for this… re-entering information that is already in the computer.)
  • Systematically addressing these issues starting at the customer end and working your way back.

Most “kaizen events” stop at this point, and they fail to anchor the improvements. Again, this is not unique to administrative processes, but it is much easier to omit this step, and much harder to see the consequences.

The vital step is, as you define what should be happening, to also put in those “checks.” Any departure from your specified outcome, or your specified process to produce that outcome, is a “problem” and problems must be identified and corrected immediately; then they must be understood. The learning gained must be applied to make the process itself more robust.

At the end, administrative kaizen is exactly the same as manufacturing kaizen, but most of us do both badly, and manufacturing kaizen is more tolerant of a poor approach. This, I believe, is why many people think the two are fundamentally different.

Posted on

Jim Collins: “Good to Great” Website

Jim Collins book “Good to Great” has been a best selling business book for several years. But I am not so sure everyone knows about Jim Collins web site. It as on-line mini-lectures, and much more material that reinforces the concepts outlined in the book.

As for how the concepts in the book relate to “lean thinking” – I believe they are 100% congruent. Examining Toyota in the context of the model outlined in the book shows everything Collins calls out as the crucial factors that separate sustainable improvement from the flash-in-the-pan unsustainable variety.

The only difference I can see between Toyota and the companies that were profiled is that Toyota has had these ingredients pretty much from the beginning, and Collins’ research was looking at companies that acquired them well into their existence.

Posted on

Waste

I guess four months into this, it kind of makes sense to talk about waste. But rather than repeat what everyone else says, maybe I can contribute to the dialog and toss out some things to think about.

Identifying / Seeing Waste.

Taiichi Ohno had 7 wastes, a few publications say 7+1. I have always disliked trying to put “types of waste” into buckets. I have seen long discussions, some of them fairly heated, about which list of wastes is “correct” and whether this waste or that waste should be included, or whether it is included in another one. None of this passes the “So What?” test. (A related military acronym is DILLIGAS, but I’ll leave it as an exercise for the reader to work out what it means.)

The problem, as I see it, with lists of categories isn’t the categories themselves. It is that we teach people using the categories. We make people memorize the categories. We create clever mnemonics like TIMWOOD and CLOSEDMITT. We send them on waste safari with cameras to collect “examples” of various types of waste. Well.. you can’t take a photo of overproduction because it is a verb. You can only photograph the result – excess inventory. So which is it? People end up in theological discussions that serve no purpose.

Like I mentioned in an earlier post, teach it by inverting the problem. The thing people need to understand is this: Anything that is not adding value is waste. If you understand what value is, then waste is easy to see. It is anything else. What category of waste is that? Who cares. That only matters when you are working on a countermeasure.

What about “necessary waste?” Even Ohno concedes there is some of that. OK – ask “does this work directly enable a task that does add value?” Then it is probably necessary – for now.

Let’s take a real-world example from my little corner of the world – welding. Welding is pretty easy. If there is an arc, it is very likely value is being added. Not always, but it is a good place to start. Now – watch a welder. What does he do when he is not “burning wire?” (the phrase “and producing a quality weld” has to be tacked onto the end of this because I can burn wire, but it doesn’t mean I am welding.)

What stops the welder from welding? When, and why, does he have to put down the gun and do something else? For that matter, what makes him let go of the trigger and stop the arc? Is he loading parts into the jig? Does he have to jiggle those parts into place? Does he have to adjust the jig?

Special Types of Waste

In spite of what I said above, there are two types of waste that merit special attention. Most everyone who can spell “J-I-T” knows that overproduction is one of them. I won’t go into it here – anyone who is reading this probably already gets that at some level. If I am wrong about that, leave a comment and I’ll expand.

The other is the “waste of waiting.” Of all of the categories, overproduction is clearly the worst, but the waste of waiting is the best. Why?

It is the only type of waste that can be translated directly into productivity. It is the waste you are creating as you are using kaizen to remove the others. That is because all of your kaizen is focused on saving time and time savings, in the short term, turn busy people into idle people.

Let me cite some examples:

  • The Team Member is overproducing. You put in a control mechanism to stop it. Now the team member must wait for the signal or work cycle to start again before resuming work.
  • You remove excess conveyance by moving operations closer together. The person doing the conveyance now has less to do. He is idle part of the time where he was busy.
  • Defects and rework – eliminate those and there is less to do. More idle people.
  • Overprocessing – eliminate that, less to do.
  • Materials – somebody has to bring those excess materials. Somebody has to count them, transport them, weigh them. Somebody has to dispose of the scrap.
  • Inconsistent work or disruptions: Eliminate those and people are done early more often than they were. More idle time.

If you look at a load chart, these are all things which push the cycle times down. You have converted the other wastes to the waste of waiting.

Now your challenge is how to convert that wait time to productivity. What you do depends on your circumstance. You can drop the takt time and increase output with the same people. Or you can to a major re-balance and free up people – do the same with fewer, and divert those resources to something productive elsewhere.

Does something stop you from doing that? Do you have two half-high bars that you can’t combine onto one person? Start asking “Why?” and you have your next kaizen project. Maybe you have to move those processes closer together, or untie a worker from a machine.

Summary:

  • Don’t worry too much about teaching categories of waste. Teach people to see what is truly value-adding, and to realize everything else is waste – something to streamline or eliminate.
  • In most cases your kaizen activity will result in more waste of waiting. This is good because wait-time is the only waste that converts directly to increased productivity.
Posted on

Who Took My Grease Pencil?

I was in a popular “Gold Rush” themed restaurant the other night, and they were struggling with a new table assignment system.

In the past the system was very simple. When you arrived, you told them your name, the number in your party. They wrote your name on a list, and gave you a pager. They had a laminated chart of the table layout, and marked tables as occupied, uncleared and available with a grease pencil. As tables became available, they moved down the list, triggered the pager, and took guests to the table. As tables were cleared and bussed, they were reported as available.

No more. Now there is a computer screen with the layout on it. They hand you the pager, and I suppose it gets logged in to “the system” as a party of 2, or whatever. And the computer pages you when an appropriate table is available. Sounds great, doesn’t it?

Of course the system is new, and the team was struggling a bit. That is expected, it is unfamiliar. But as we handed in our pager, I commented “I thought the grease pencil worked just fine.” The response was “Tell me about it.”

Now I suppose the technology enables them to track all kinds of great metrics like table turnover, etc. But if it is like most similar software implementations, those benefits are solutions in search of a problem. They are justifications for the expenditure.

I am always very wary when someone proposes to replace a functioning manual process with a computerized one. The main reason is this: The people who do the process no longer can improve it.

With a chart and a grease pencil, the team owns the process and readily understands the (non-) technology behind it. If they find a better way, it is easy for them to make an improvement.

Bury the process in a computer and you take that away. All the team can do is blindly execute whatever the programmer thinks should be happening. Programmers are smart people, but they generally do not have to execute their process hundreds of times a day. Maybe a few times – or even a few days – for testing, but not day after day. They do not, and can not, see the small issues that accumulate to become aggravation.

Before you introduce a “high tech” solution into your work area, think long and hard.

EXACTLY what is the current situation? EXACTLY what standard of performance is not being met by the current process? EXACTLY what are you trying to achieve? Remember that “automating the process” is a countermeasure, and that a “manual process” is not a problem. Let me say that again: If your problem statement says “Process is manual” then you do not yet understand the problem, and there may not BE a problem. What, exactly, about this manual process does not meet your expectations?

If the problem is that the process is labor-intensive or cumbersome, then you are getting closer. But jumping to automation still is not appropriate here. Have you carefully studied the process to see why it is labor-intensive or cumbersome? Have you looked at every step, every motion, and evaluated:

  • Why is it necessary?
  • What is the purpose?

Don’t know? Then that step is a candidate for elimination as pure waste.

  • Where should it be done?
  • When should it be done?
  • Who should perform this step?

These questions give you insights that let you combine operations. Administrative processes, especially, are full of redundant work – people looking up or entering the same information at different times in different places, or copying information from one place to another. Your goal is to take the remaining operations, the ones which passed the “Who / What” test and rearrange the steps into the best logical sequence, with the right people doing them.

  • How should this task be done?

Take the remaining steps and simplify. Make the job easier and quicker. Jigs, fixtures. In administrative processes – forms, templates. Find sources of error and mistake-proof them. Work out the method.

When you are done with all of this, then take a look at what is left. NOW, if there is a problem that has not, or cannot, be solved within the existing context you might consider an automated solution as one possible countermeasure… but don’t reflex there, unless you want to turn your kaizen over to programmers.

Last Thought – what about those great metrics the automated system can collect? Question: Do they pass the “Who Cares?” test? What is your plan to use those measurements to know where you are, and are not, performing to your standard? What is your plan to use that information to target improvement activity? Keep in mind that you cannot get performance simply by measuring it, any more than calculating your fuel mileage makes your car drive further. The purpose of measurement is to compare What Should Be Happening vs. What Is Actually Happening so you can compare your results against your predictions to see if the process is working the way you expect it to.

Posted on

Takt Time and Leveling – What’s The Point?

A few days ago I wrote about asking “What is your takt time?” and the likely responses to that question. But in my list of common responses, I left one out – “What’s the point? We get everything out by the time the truck leaves.”

Here’s a real-life example: In a high-volume consumer goods factory we had a daily transportation cycle. Shipments left once a day. Parts and materials arrived once a day. Although the operation was not without its glitches, the process itself incorporated a lot of automation (another story entirely), and the time through the machinery was pretty quick.

We were trying to implement the production leveling (heijunka) into the enterprise flow between the factory and the distribution system. While the mechanics were very straight forward, leveling the model mix during the course of the day encountered a logical question: What’s the point?

And what is the point? With or without model-mix leveling the same stuff ended up on the truck at the end of the day, and the total amount of inventory in the factory was not going to dramatically change. So why go through the trouble, especially of working changeovers on the packaging equipment, when there was apparent no net effect?

The question is a logical one until we understand that takt time (or pitch in this case) is not a production quota. It is part of a standard.

What’s so important about standards?
Without a standard, you can’t detect a problem.

Daily management is about rapidly detecting, correcting and solving problems. This is much easier to do when dealing with small problems before they grow into big ones.

The “What’s the point?” question even gets asked in the course of many lean manufacturing implementations. The operation reaches a level of performance that is “good enough” – for example, everything makes it onto the truck by the end of the day – and they are satisfied with that level of performance. This is when continuous improvement stops.

Have all of the problems been solved? Has all of the waste been removed? Of course not. But the next level of problems, and therefore the next level of performance, is under the radar.

In the factory I described above they had more demand than they could handle. They were already working 24/7, and were working to add capacity. They wanted to speed up the automation, and possibly even add additional lines. Yet, during the course of a day:

  • They lost many units to defects.
  • The lost production to machine stoppages and slow-downs.
  • They had part shortages and frequently substituted one product for another in the shipments, and made it up tomorrow.
  • Because they were “behind” they relentlessly kept the lines running, only to find defective product in final inspection.

The list goes on. They are all familiar things.

So what is the point of applying leveling product mix and establishing the discipline of a takt time or pitch?

Honestly, there isn’t any point unless they also implement a leadership process to immediately call out and respond to any slippage or deviation from the intended pace and sequence of production.

So – what started out as a question about a common tool or technique in the TPS has come around to what the core issue really is when that “What’s the point?” question is asked: Lean manufacturing is not about the tools and techniques. It is a system to assist a proactive leadership culture that is almost obsessed with finding and fixing the problems that keep them from achieving perfect safety, perfect quality, perfect flow, with zero waste.

A “problem” is any deviation from the standard. (And if you don’t have a standard, that is a problem.)

Two key questions:

Are we meeting the standard? If the answer is “yes” then:

Are we looking at perfection?

One or the other of those questions is going to drive you to address the next level of problems.

Posted on

Computer Kaizen

We were at a business meeting and my coworker was waiting impatiently for his laptop computer to finish booting up. He and I were sitting next to each other, had identical machines, but I was already working. He made some comment about my machine booting faster for some reason.

But that wasn’t the case.

Here is his laptop startup sequence:

  1. Unzip bag, remove computer from bag, set on table: 7 seconds.
  2. Remove power cord from bag, unwind: 8 seconds.
  3. Crawl under table to plug in power cord: 14 seconds.
  4. Re-emerge, connect power cord, connect network cord: 11 seconds.
  5. Open lid, press start: 3 seconds.
  6. Wait: 61 seconds.

This seems reasonable, doesn’t it? Why was my setup faster?

  1. Unzip bag, remove computer from bag, set on table: 7 seconds.
  2. Open lid, press start: 3 seconds.
  3. Remove power cord from bag, unwind: 8 seconds.
  4. Crawl under table to plug in power cord: 14 seconds.
  5. Re-emerge, connect power cord, connect network cord: 11 seconds.
  6. Wait: 61 – 33 = 28 seconds.

The core question is “Why can’t I turn on the computer sooner?”

It is a laptop. It will start up just fine on the batteries while I fidget with the power cord. And the networking doesn’t come on line until well into the boot cycle, so no time is lost if the network cable isn’t connected right away.

Net result is my wait time was half of my co-workers even though we both did the same thing. We just did them in a different sequence.

In the terms of a changeover, this is identifying internal tasks that could be external and moving them there.

This is the kind of improvement opportunity your Team Leaders should leaders should learn to spot. In most cases, though, they should not implement a change. Instead they should use the opportunity to teach the Team Member who does the work how to see this opportunity, and teach the Team Member how to make the improvements.

What kind of performance would you have if everyone in your operation thought this way for a year?