Continuous Erosion

“Sustaining the gains” is a frequent topic of discussion in the continuous improvement world. Often the discussion degenerates into a rant about “management commitment.”

But in the real world, people generally don’t sabotage improvements on purpose. (Though I have seen it happen, but only once.) The mechanism is far more subtle.

Before we get into what happens after improvements are made, let’s look at a common improvement process itself.

In many companies, the primary method for making improvements is through special events or projects. These are usually planned, organized and led by a staff specialist.

Although the exact methods and words vary, the general process usually looks something like this:

  • Identify an opportunity, select an area for improvement.
  • Analyze the current state.
  • Select an improvement team.
  • Teach the team members how to apply the improvement tools.
  • Facilitate the development of improvement ideas.
  • Work with the team members to implement them.
  • Wrap up with a report or presentation, including remaining action items for management.

A variation on this is where the team is chartered, and it is up to them to identify an opportunity. This approach was more common in the late 1980’s than it is today.

This process actually works. It is capable of making pretty dramatic changes over a short period of time, often only a few days.

So why do the results erode? Or put another way, what is the problem?

Take a look at the routine decisions that are made during normal work, especially the ones that result in some change to the process. Those decisions must be made, because people have to get something done. The question comes down to whether those decisions result in improving the new process, or eroding it somehow.

Once things are in operation, some kind of unforeseen event always happens. Guaranteed. It can be something that the improvement team didn’t think of. It can be a piece of malfunctioning equipment. Maybe there is a material shortage or a defective part is delivered. The same things happen in administrative processes, only the words are different. Incomplete information arrives.

It could even be a deliberate decision. A production rate change. A software upgrade. Making room for some other activity.

All of these things, no matter how small or inconsequential, force decisions to be made. “How do we deal with this this and get production going again?”

The person making that decision is either:

  1. Fully capable of applying kaizen principles, and applies them in a solution to the problem.
  2. Is not fully fully capable of applying kaizen principles, but knows that, and seeks assistance in finding a solution to the problem.
  3. Is not fully capable, may or may not know this, and does the best he can to get production back on track.

Both (1) and (2) result in making the system better, more robust and more responsive.

(3) usually results in a little bit of erosion. Variation is accommodated, things are made a bit more complex, the layout is now less than optimal, the old process does not work as designed anymore so the team member must improvise a bit. That, in turn, introduces more variation into the process, and usually drives a cascade of these little decisions.

If there is no mechanism for problem escalation (and if there was, we would likely be in (1) or (2) in the first place), then this becomes the new way, and things are steadily creeping closer to where they were before the event happened.

Given enough time (which can be amazingly brief), the process reverts back to where it was, or morphs into something else entirely – but equally wasteful.

Meanwhile the improvement specialists have moved on to the next project. Even if the local leader did ask for assistance, they might not be available, or worse, they tell him to figure it out.

Follow this with an “audit” that dings the local leader for “not supporting the changes” and wonder why he is less than enthusiastic about this kind of help.

Here is the question I want to leave hanging out there:

What was the intent of the kaizen event? (and was that intent accomplished?)

Notes From a Kaizen Event

I was cleaning out some old stuff and came across a folded piece of paper with notes on it. They were from my parting comments to a kaizen event team that had put in a great week with spectacular results. They had started out wanting to improve the delivery of WIP to and from the warehouse.

When we went to the shop floor to see the current situation, what I saw was much more opportunity. It took a little work, especially with the area manager, but by the end of the week they had gone from needing 5 work cells with 6 people each – plus more to meet the holiday seasonal production – to 4 production cells with 5 people each, that could comfortably meet the rush. Not bad for a week’s work.

That’s the background.

When I look at old notes like this, I am always comparing what I knew then with what I know now. Now and than I turn up something that gives a hint that I knew what I was doing.

These comments were as much for the rest of the audience as they were for the team members themselves. After all, they knew what they did, and were fully aware of what they had to do next. But the other teams, and their collective bosses, needed to hear it as well.

  • Wow – great team. You caught flow fever early in the week and ran with it. You make me look like I knew what I was doing – thank you.
  • You connected the operations into a smooth flow.
  • Now you can begin the process of kaizen. Stick with it, stay on the shop floor, and work to stabilize the work. Many problems will come up. Help the work teams learn how to see them and solve them.
  • If you can save, and stabilize, a quarter of a second every day, in three months you can get another 20% of productivity. Think about that – and do the math for yourself.

What made this work?

First and foremost, we had the operational manager there, fully participating. He was skeptical at first, but once I sat down with him and went through his production requirements, step by step, he began to see things in terms of takt times and production leveling rather than just quantities to push out the door. That was a big shift.

The other big thing was havingĀ  the team work off line for a few hours to construct a mock-up of a “typical” work cell. Then, without worrying a bit about the takt time, work to minimize the cycle time of one person going through the complete cycle. They learned for themselves that to save time you must study motion. We went through three or four cycles of granularity – every time they thought they had “the” solution, we introduced another tool to see the next level of extra motion. Through this exercise, they gained confidence that it was entirely possible to make a dramatic improvement in the “optimal layout” that they already had.

After that, it was a matter of getting to work. They watched the actual operators, and now could see the excess motions that were being driven by the way the work was arranged. They started making little adjustments – always being respectful of the workers. “We’d like to try something different here, just to see if it works better for you. May we just try something?”

That “May we try this?” attitude introduced something into the dynamic that doesn’t show up often enough – humility. Rather than these managers saying “We’ve got a better way, do it like this.” they were saying “We really don’t know if this will work or not,” and asking not only permission to try, but for input on whether it worked, or how it could work if it wasn’t quite there.

A lot of changes got implemented, but there was no arguing or friction because everything was just an experiment to see if it would work or not.

In the end, I saw something I had never seen before – the manager put in a budget request for a reduction, because he knew he couldĀ  get it done with less, or at least figuring out how was within his reach.

That scrap of paper reminded me of a pretty good week.

The Lean Manager: Part 3 – People, Purpose, Problems, Process vs. “Systems”

Click image for Amazon.com listing

This is Part 3 of a multi-part review. Part 1 is here.

Before I get into it, I will break the rules of blogging and acknowledge a time gap here. I did finish the book shortly after I wrote part 2, in fact, I didn’t want to put it down. So now I am going back through and bringing out some key points, intermixed with some other stuff that has caught my interest lately. Anyway – back to what you came for…

Steve Spear has described the TPS as a “socio-technical system.” Put in less formidable terms, it is a system that uses the structure of the work, the work environment and the support systems (the technical part) to create an organizational culture of problem solving.

Jenkinson, Andy’s boss in the book, describes it:

“You need to organize a clear flow of problem solving, explained Jenkinson one more time. “Operators need to have a complete understanding of normal conditions, so that whenever there is a gap, they know it’s a problem. Go and see is not just for the top management, It’s for everybody. This means operators as well, in particular how they learn to see parts and see the equipment they use. How can all operators recognize they have a problem? [emphasis added]

The simple statement, and following question posed by Jenkinson sums up a great deal that is left out of lean implementations. I see it everywhere, and will be commenting on it more shortly.

We talk about “go and see” (or “genchi genbutsu“) as something leaders do. I think this is because traditional leaders aren’t naturally out in the work areas, on the shop floor, in the hangars, etc. We don’t think about the workers because they are there all of the time.

Yes, they are. But what do they see? Do they see disruptions and issues as things they are expected to somehow work around and deal with? Or do they see these things as something to call out, and fully participate in solving?

And if they do see a problem, what is the process for engaging it?

Just saying “you are empowered to fix the problem” does not make it so. When are they supposed to do it? Do they have the skills they need? How do you know? Is there a time-based process to escalate to another level if they get stuck? (Or do they just have to give up?)

And indeed, as the story in the book develops, Andy turns out to be taking a brute-force approach. He is directing staff to implement the tools and to solve problems. But in spite of nearly continuous admonitions from his boss and other experts, he is not checking how they are doing it. He has put a “get-r-done” operations manager into place, and while the guy is getting “results,” in the long haul it doesn’t work very well. Yes, they end making some improvements, but at the expense of alienating the work force.

It is only late in the story (and I won’t get into the details to avoid playing the spoiler to a pretty good plot twist) that Andy finally learns the importance of having a process that is deliberately designed to engage people.

Commentary – it is amazing to me just how much we (in the “lean community”) talk about engaging people, but never really work through the deliberate processes to do it. There are explicit processes for everything involving production, administration, etc. but somehow we expect “engaging people” to happen spontaneously just because we believe it is a good thing.

The message in this book is loud and clear. This is about leadership. The tools are important, yes, but only (in my opinion) because they are proven techniques that allow people to become engaged with the process.

But the tools alone do not require people to get engaged.

Permission to make input is necessary, but not sufficient. If you want people to be engaged, you have to deliberately engage them. Otherwise you are just asking them to become nameless cogs in “the system.”

Reducing Inventory

Yesterday’s post on vendor managed inventory touched on a couple of things about “lean” and reducing inventory that I’d like to explore further.

All too often “inventory reduction” has been a way to “sell” a lean manufacturing implementation. The reduction of inventory becomes the objective. While this isn’t inherently a bad thing, it is all to easy to get caught up in the trap of “management by measurement” and do it the wrong way.

Reduced inventory is a result of good kaizen, but it isn’t the justification for doing it. The purpose of kaizen is to solve problems, specifically the problems that disrupt the smooth flow of work and creation of value. Solving those problems saves time – worker’s time, customer’s time, leader’s time because everything runs more smoothly and predictably.

The primary reason that inventory is there is because things aren’t smooth and predictable. Once they are, you can take some of it out.

The necessity to have inventory at any given point in the system is evidence of a problem that has not yet been solved. (Including, sometimes, simply having poor inventory management, which is another way of saying “overproduction.”)

By asking “What must we do to live without this piece of inventory?” you can uncover the next problem to solve, and then make a decision to solve it.

If it is solved, then inventory can be reduced. But it doesn’t happen automatically, you have to actually take it out of the system and keep it from coming back.

But in any case, this is a lot different than just shoving the ownership of the inventory onto someone else.

Without Standards There Can Be No Kaizen

The meaning of this famous quote, attributed to Taiichi Ohno, becomes much more clear in the context of “Chasing the Rabbit” and previous published research by Steven Spear.

Spear’s research goes beyond Toyota’s process and delves into a more general question about how any organization playing in an otherwise level field can continuously out perform similar organizations in similar circumstances. This makes Toyota is a subset or an instance of a very fundamental principle, rather than a special, complex, unique case.

I think that is important. Some critics say Spear is making a soft version of the TPS. I think quite the opposite. He is explaining why it works.

And why it works comes right back to Ohno’s quote.

To better understand Ohno’s quote, let’s compare Ohno’s context with Spear’s.

All of us have been taught Ohno’s three elements of standard work:

  1. Takt time
  2. Work sequence
  3. Standard inventory

In “Decoding the DNA of the Toyota Production System” (a summary of his PhD dissertation), Spear describes the first rule-in-use he observed:

All activities are highly specified in terms of content, sequence, timing and outcome.

Further, Spear’s research concluded that the process steps themselves include frequent, nearly continuous, built-in checks that are designed to call attention to any departure from the specification. It is those built in checks which, on an assembly line, trigger an andon call and start the escalation process.

It is the escalation process which, in turn, results in problem solving and improvement.

It is any departure from the standard which calls the standard itself into question and results in investigation to understand more about the process.

The elements of takt, sequence and standard inventory define not only standard work, but they define elements of the built-in checks.

Takt time is the standard. Cycle time is the actual.
Actual cycle time is compared to the takt every time the process is carried out. If it takes longer than expected – problem, andon, escalation, problem solving.

The defined work sequence is the standard. It is (or should be) checked against the actual work sequence every time it is carried out. If something knocks the worker off the standard sequence – problem, andon, escalation, problem solving.

The standard inventory is the minimum amount of inventory required for the process to be successful at takt. Just as the work cycle is timed against the takt time, actual inventory can be compared with the standard. Too little? The process gets halted. That is a problem. Andon, escalation, problem solving. How do you check for too much inventory? Inside a process, specified inventory locations (5S, folks!). Inventory out of place? That is a problem. Andon, escalation, problem solving.

In regular takt-based work, these things in combination are a very effective set of cross checks of actual vs. specified work. BUT these are only tools that set up the system for kaizen.

It is the problem solving – the seeking to understand why the exception occurred that is true kaizen. This should must happen rapidly and every day. Not just during special “events,” every day.

It is part of the work, just like putting on protective equipment, just like maintaining the machines, just like cleaning up. Only this part of the work actually improves the operation.

So – without first specifying what is supposed to happen, there is no way to determine if what actually happened is routine or cause for investigation, learning and improvement. Then the exceptions become the routine because there is no expectation of otherwise. Look up the term “normalizing of deviance” and get an idea what the ultimate consequences can be.

That is why the first step in improving a process is often to attack ambiguity itself. This is especially true in administrative processes, and it is critical at the points where one process step turns over work to another.

If a defect-free outcome has not been specified, people are left with the leadership cop-out of “do the best you can” and that results in continuous erosion of morale, quality, delivery, cost. It is anti-kaizen. It is what is very much like kaizan – faking it.

Why Doesn’t Daily Kaizen Happen?

More than one organization gets stuck in kaizen events. By "stuck" I mean that kaizen events are the only mechanism for improvement. A good indicator of this is "waiting for a kaizen event" to make an improvement that everyone agrees should be made.

At the same time, I see leaders who understand that these kinds of improvements should be made on a daily basis, but those leaders are frustrated because that doesn’t happen.

So why does this happen?

There are a few things that have to be in place, but even with a workforce that understands improvement and where this is going, even with shop floor leaders who understand how to do it, that doesn’t seem to be enough.

So here are some things to think about.

You block out time during the day for your start-up meeting, end-of-shift cleanup (a different topic). You block out time for preventative maintenance (you do, right?). You block out time and resources for the things you expect to get done.

Do the low-level work groups capture, in real time, the little issues that disrupt smooth work? Those are your daily kaizen opportunities.

Do you block out time for daily kaizen? If you don’t, then you are saying "Do kaizen when there is nothing else to do. Your daily kaizen time should not count as "available minutes" when calculating your takt time.

Do the Team Leaders and Supervisors expect the work teams to work on those problems during the kaizen time?

The bottom line: Don’t just wish it would happen. Look at what is necessary for success (skill, time, leadership, tools, expectations), make sure those things are available. If actual events are not what you planned, then study and understand why not and fix it. Daily kaizen is no different than production. You have to plan for it.

Bloodletting: Why Controlled Experiments are Important

Bloodletting: Why Controlled Experiments are Important

I want to start this post with the last paragraph of this article:

Next time someone tells you that they are sure their idea will work, consider running a prototype in a controlled experiment, and make a data driven decision!

Now – the article itself is in the context of Microsoft software development, but this is what "lean thinking" is all about.

In the Toyota Production System, processes and the organization are deliberately constructed so that a kaizen experiment in one area is unlikely to affect another – at least not before there is ample warning and opportunity to reverse the change.

Every production cycle itself is conducted as a controlled experiment testing the hypothesis that the process:

  • Can be conducted as specified.
  • Delivers the specified results.

Of course – and here is the key point – it is only an experiment if someone actually examines what really happens. And this is the fundamental difference that is captured in the quote at the top.

A truly lean process has built in checks that check, each and every time, whether the idea works. Any time an idea doesn’t work, there is an expectation that the process will be stopped and understood.

Continuing to blindly produce, without knowing if each and every process is working as planned, without knowing if the result is as planed each and every time is being sure it will work. It is bloodletting.

Don’t bleed your process, or your company, to death with things you "know will work."

Costs and Kaizen

How does kaizen actually show up on the bottom line?
This is a question that gets asked a lot, and honestly, we owe the asker a better answer than “it just does, trust us.” (Even though this is true.)

Here’s my thinking – it shows up two ways.
One is intangible. By that I mean it is incredibly difficult to quantify, even afterwards. But it is there.

IF the organization manages to get the continuous improvement engine running – meaning they understand that “pursue perfection” is not a “step in implementation” but rather the thing that gets it going in the first place – then, over time, everything starts running more smoothly.

It is hard to put a hard-monetary return on things like:

  • Everybody is working together, as a team, toward the organization’s overall goals.
  • Everybody understands who the customer is, and keeps their focus there.
  • Every instance of a problem causes the organization to improve and learn.
  • Everybody comes to work knowing what they must do to succeed; knowing they can do it; knowing that, if there is a problem, they will find out right away; knowing that they will get support in resolving it.

In short, the organiztion performs, and that performance is getting better and better.
What is that worth? Is it better to have a superbly performing organization, or one which requires continuous micro-management of every detail? (Hint: It isn’t about hiring better people, it is about creating working conditions and processes where regular, competent people can create superb performance.)

But it is possible to understand some direct, tangible returns as well. In fact it is possible to set solid targets, understand what must be done to reach them, and track progress on activities and results.

Any organization that is self-funding (including a non-profit) must offer some kind of value to its paying customers. If “value” is what the customer is willing to pay, then it is easy to determine the, ah, value of the value.

“Value add” defines the economic result of a transformation process. We buy some stuff at some cost (value), transform it into something that is worth more to the customer, and sell it. The difference between what we paid for the stuff we bought, and what the customer paid for the product or service we sold is the “value add.”

Note that this has absolutely nothing to do with what it cost to make that transformation. Nothing at all. It is possible to add value and lose money at the same time. It happens every day.

It does cost something to run the operation that adds the value. When those costs are less than the total value added (over some period), then the organization gets to keep some of the money as profit.

When those costs are more than the amount of value added, then someone has to fund the gap – the owners / shareholders, debt, the money has to come from somewhere.

When it comes to costs, I like to keep things really simple and easy to understand.

Costs are incurred two ways, and in the details, they intermix.

  1. In order to operate, we spend money every day on things like payroll, rent, utilities. This is cash burn.
  2. We have stuff needed to operate. This is cash tied up in the business, capital, inventory, etc. Just having that stuff costs money, and a lot of this stuff depreciates. That depreciation can, in turn, be counted the same as cash burn, but real life is more abstract than that because, while payroll must be paid, “depreciation” is something we can hold our breath about.

I have not included the cost for materials that are transformed into finished product here. That cost is captured in “value add.” The above two things add up to the cost to add that value, and those costs are largely fixed (in the classic sense of the word), whether we make anything or not.

Aside from the actual materials that are bought, transformed, and sold, there are very few truly “variable costs.”

“Continuous improvement” means to continuously increase value add, and continuously decrease what it costs to add that value.

There are fundamentally four ways in increase value-add.

  1. Improve the product offering so that customers will pay more. Ideally this is done without increasing any costs. This is really the only leverage point of purely service businesses.
  2. Pay less for the raw materials and parts – push your suppliers for lower prices.
  3. Change the engineering design to one that is less expensive to source.
  4. Examine your make / buy. Look for high-leverage items that your currently purchase. These are items which:
    1. We could make if we wanted to.
    2. Have a very high differential between the cost of the pieces and what we pay for them. (i.e. the supplier has a very high value-add to us.)

    Now, here’s the rub (and where this ties in to kaizen). If you have been doing a good job at kaizen, you have made some people available. If you know how to make these high leverage parts, can you put those people to work making them? A lot of this depends on the capital required, etc. but, as a general rule, the further up the supply chain you reach, the higher your value add. It comes down to capability and cost. And if you are using labor made available through kaizen, it does not matter what this labor costs. If you are adding more value today than you were yesterday, and incurring exactly the same costs to do so, your profit is higher. And the last time I checked, that was the name of the game.

Aside from increasing value-add, the other objective is to do so at the lowest possible cost, and there is a bit of a circular reference here.

Good kaizen can free up a lot of time. I suppose, if you wanted to do scorched-earth kaizen, you could immediately lay those people off. (Don’t expect much help with further improvements after that.) Aside from the ethical issues, these kinds of actions are really disruptive to the organization, in ways that are difficult to quantify.

If you are trying to simply increase production volume (the right kind of problem to have), then dealing with this issue is fairly simple, you just avoid hiring more people. You increase output without increasing payroll.

But also take a look at the in-sourcing option mentioned above. A lot of organizations overlook these kinds of opportunities today.

Like I said, this model is very simple. It is essentially the “throughput accounting” model offered by the Theory of Constraints folks. (Believe me, I don’t just make this stuff up.) Traditional cost accounting models can be mapped directly into this model. I just find it a lot easier to understand, and more importantly, to explain to the people who actually have to make all of these things happen.

The Value of People

How can some companies not only survive, but thrive when operating in “high cost labor” areas, while others are struggling even as they are busy chasing the lowest possible costs?

I would like to suggest that one key difference is the attitude toward people. On the one hand is the “people as cost” model. This model usually has a couple of built-in assumptions.

  • The number of people required to do a particular task is fixed, often against some kind of earned-hours standard.
  • The cost driver is wages, salaries and benefits.

On the other hand is the (seemingly) rare organization that truly believes that people are their strength, or the well worn out “our greatest asset.”

The assumptions which are required for this belief are:

  1. People’s net productivity can always be improved.
  2. The cost driver is the amount of time wasted coping with all of the small problems that keep things from going perfectly.

The above assumptions, of course, are anchored in a faith-based position that perfection is possible. (see “Chatter as Signal“)

So… what kinds of actions to each of these two models drive?

The first one – people are cost – says to find the cheapest possible labor and hire it. Since factory wages in China are (right now) running about 1/12 or less of those in the USA or Europe, that seems a logical choice. Here’s the rub.

You can outsource the entire job to another company – give the work to the lowest bidder. Now, if you truly believe that the amount of labor is fixed, and that only lower wages can change cost, then this is the obvious choice. You are relying on your superior supply chain management system to ensure you select a supplier that can maintain, and maybe even improve, the quality they deliver, plus hold the line against increases in materials, energy, and their own labor costs. In short, you are looking for a supplier who believes the opposite of what you do. Your ideal supplier knows they can bid aggressively, get your work, and then improve their profit position by applying continuous improvement.

Or you can export the production and set up your own operation in a “low wage area.” You are shifting your core beliefs about people to another culture, and another language. Communication (believe me!!) is a major issue, even if the managers work for you.

AND.. if “labor is cheap” then the solution to problems is to throw people at them. The cost differential you actually get almost NEVER reaches the advantage of a 1:1 substitution. Oh – and you just added 3-4 weeks to your lead / response times.

If, on the other hand, you take the attitude that the most precious resource in your operation is people’s time – no matter what you pay them, and take the attitude that to deliberately waste anyone’s time is to show great disrespect, then I would suggest that even in high-wage areas you can drive levels of improvement in productivity, quality and response to your customers that would be difficult to beat anywhere.

So – before you reflexively outsource or relocate to a “low wage area” please check your attitude about people. What are your expectations, and why is it that you don’t believe your own people are capable of delivering a 10x improvement?

Who are your competitors? What do they do?
What would you do if you had to compete with Toyota? or Komatsu? (to name two that come to mind) They are building product in your back yard, why can’t you?

Afterthought: Some companies end up outsourcing the skills they need to improve their own products and systems. They no longer understand the technology they sell, they no longer know how to make what they sell. I remember a time when I reminded an (arrogant) procurement executive that it was possible to outsource the entire procurement process just as easily. Another team had outsourced all of their direct labor management… they contracted the labor and the first level supervisors into their factory. Where did they really believe this was leading?

Shingijutsu Kaizen Seminar – Day 2

The day today ended about 10 pm. It is 11 pm now as I write this, which translates to 7 am Pacific Time. I will leave the remaining time zones as an exercise for my European readers. (Hello, Corrie!)

Once we hit the shop floor today we were in “understand the current situation” mode. It turned out to be more difficult than I expected due to a high level of variation, some real, but most self-inflicted, on the line. Yesterday I mentioned my great plan to put the less experienced people on the front line of the cycle time study. Well, I ended up doing that, along with everyone else, since the area we are working is fairly spread out and has 11 people working in it.

After getting our heads around things, we have these areas of focus tomorrow.

  1. Establish an even and visual pitch on the moving conveyor. We need to know when work cycles are supposed to start and end so we have some kind of baseline about where the cycle time issues are. This will help.
  2. Basic 5S and parts presentation in the first position. This guy is responsible for setting the takt for everyone else since he is the one who launches the unit down the conveyor after his stationary build. We might try to move most of his build to the conveyor too. I think it has been on the conveyor in the past because the unit moves through the first pitch without anyone touching it.
  3. Start recording line stops. When, why, how often. Basic understanding of where the problems are.
  4. Detailed work combination analysis of a semi-automated testing operation at mid-line. We know there are disruptions there, but those disruptions cause major distortions to the actual (vs. planned) work cycle, so we need to understand whether the operation even has the theoretical capability to meet takt.
  5. Work on a sub-assembly operation and at least try the concept of building unit-by-unit instead of batching to the weekly published schedule. Stuff is late to the line. It is probably not a capacity issue but rather that capacity being used making stuff other than what is needed right now. This will be a little complicated because they actually feed parts to more than one line position. Thus if they get truly synchronized with their customer, they will not build a unit set of parts because this is a mixed line, and different positions have different products at any given time. Instead they will have to shift their focus from “unit” to their individual main-line customers and build what they need next.

The real overall challenge is that this is a two-day event, and we spent the first day just getting our heads wrapped around all of this. So tomorrow will be busy. But people are learning, and that is the whole point. It is important not to lose sight of the reason we are here. If the host company gains, so much the better, but it is really about the participants learning something we can take back.

And yes, I have been deliberately vague so as not to compromise the host company. They have been at this a long time, and done some very impressive things. This particular area, however, needs work, which I suppose is why we are in it.