Author: Mark

Posted on

Clearing the Problem / Solving the Problem

As I work with clients to get a “problem solving culture” embedded, one common challenge is the distinction between the short term work-around to remove the obstacle, and the long-term countermeasure that actually improves the process.

I addressed this at a conceptual level in the “Morning Market” post a while ago.

Last week I was working with a client who has begun using the work-around as their key insight into the issue they have to solve.

When the work flow is disrupted, they are careful to capture what they had to do in order to clear the problem and get the item back into the normal production flow.

“We had to wait for parts.”

“We had to rework _____.”

“We had to get on someone else’s login for enough security to do the task.”

“We had to find the ____.”

“We had to replace ___”

This is really valuable information. By appending “Why did…” in front of the statement, they have a fairly well defined starting point for getting to the bottom of the actual issue.

By making the containment action the first “Why?” they get off the containment-as-solution mindset.

It might not work for everyone, but it is working very well for them.

“Please continue.”  Smile

Posted on

Smooth is Fast

When you are at the gemba, you are watching the work. We like to say you are “looking for waste” and list seven, or eight, or ten different categories of waste that you are supposed to look for.

I think it is simpler than that.

An ideal workflow is smooth.

The product moves smoothly, without starts and stops, without sudden changes in momentum.

The people move smoothly. Each of their motions engages the product and advances the work in some way.

Machines do not interfere with the smooth movement of product or people.

Information flows the same way. There is nothing in how it is stored, retrieved, or presented that causes people to break their smooth rhythm.

When you watch the work, try to visualize what smooth would look like. Smooth has no wasted motions, no excessive activities.

Anything that doesn’t look smooth is likely the result of an accommodation, an awkward operation, poor information presentation, poor computer screen layout and workflow.

Just another way of looking at it.

Posted on

Leadership and Challenges

This post rambles a bit, and wraps up a few concepts. It was, however, inspired by a recent interview of Mike Rother on Lean Nation. (See below)

One of the many good points that struck me was that you can’t rally around an ROI.

Yet companies try to do just that. They set something ROI or margin objectives, and wonder why everyone doesn’t pick them up and run with them.

Even companies that do issue a good challenge often come up wondering why the organization doesn’t align around it. Rother mentions one good reason: Nobody is there to coach them through meeting their part of the challenge.

A similar fallacy is trying to rally people around an abstract vision. I have experienced this a couple of times. A company tries to apply general education to people – lots of it – in the (vain) hope that once people “understand” then they will pick up the ball and run. But without consistent direction toward a limited objective that is easily articulated, people freeze up. “What do we work on?” There are too many choices.

Chip and Dan Heath discuss the importance of a rallying point in their book about culture change, Switch. They talk about “Pointing to the Destination” and “Scripting the Critical Moves.” When we talk about an aligning challenge, we are saying the same thing. Remember – in these initial stages you are trying to infuse a fundamental behavior and culture change. You can’t just tell people what it is and expect things to change tomorrow.

Classroom training may teach people the words, but it does little to accelerate the process of learning on the shop floor. That takes leadership.

More after the video:

One of the concepts that Rother discusses in Toyota Kata is the concept of “True North.” Spear also talks about it as striving toward the ideal process. Same thing, different words.

But at another level, when we are trying to shape a different management system, it is equally important for the leaders to have a “true north” for the ideal leadership process. I think this is different (or should be expressed differently) from the True North of the ideal value-adding process.

As I develop my own practice, I am honing in on those key elements of “leadership true north” and making it the cornerstone of my engagements. Mainly I try to describe specific behaviors and critical elements that need to be in place. This seems to play better than abstract concepts like “servant leadership” because it tells people what they need to do. (See “Script the Critical Moves.”)

Posted on

The Process of Caring

Vance left a really good comment on the recent Travel Tales post. He said, in part:

Having worked in the airline business, it’s really a matter of having employees that CARE (most due to their own pride, not by management) We many times had weather and mis-connected passengers to deal with. It only took a few minutes of extra time to send a message to the destination station and let them know what to expect or which passenger was going to be disappointed to not get their bag. Today’s situation is exacerbated by under-staffing, stressed employees, passengers with sometimes unrealistic expectations, checked bag fees, etc it’s ugly and very little relief in sight.

He brings up some really interesting points. In most of the airline industry, like most industry in general, “caring” is thought of as something the people have to do.

“The employees don’t care” or even “management doesn’t care” are pretty common statements.

Let’s turn it around.

How was the original process designed?

Continuing on the theme from the original post, I would speculate that most players in the airline industry see themselves as providing transportation to people and their stuff.

The process design is, logically, going to center on what things have to happen to get people and their stuff from their point of entry into the system through to their point of exit at baggage claim. (the fact that the trip doesn’t actually end at baggage claim is another topic – one which has been discussed by Jim Womack in Lean Thinking, among other places.)

In traditional thinking, improvements in that process will involve making those things happen cheaper, usually by doing less.

What if, though, we start with a different question:

“What experience do we want the customer to have?”

Describe, first and foremost, the things the customer has to do to get herself and her stuff from the point of departure to (sadly) baggage claim. (Bonus points if beyond, but let’s not stretch the fantasy too far.)

Even better, act it out. Simulate it. Try it on. Work out the kinks, from the customer’s perspective.

Next, design the interface between your customer and your process. What does the customer-touching part of your process have to look like to deliver that experience?

(I often wonder if airline executives ever see their own web reservation systems.)

Now, only when you know what the “on stage” part of your process looks like can you design the rest of it – the back stage parts that make it all happen.

Economics come into play at this last stage. This is where you have to get creative. If the solution is too expensive, work on the back-stage part to make it cleaner and more streamlined. The customer facing part of the process is the target condition. Your problem solving works to deliver that experience in continuously better ways.

What does this have to do with “caring?”

Remember, this is from the customer’s perspective. When we say “our employees care” do we not really mean “our customer’s feel cared-about?” Since we started with the customer’s experience, if that is what is desired, it was built into the process specification from the beginning.

Once there is a process that we predict will result in customer’s feeling that people care about them, then your market surveys make sense. You are not soliciting complaints about things to fix, you are validating (or refuting) your design assumptions. Every bit of customer feedback will be a learning experience.

Don’t forget Murphy.

In a complex business like airline travel, sometimes luggage doesn’t get to baggage claim at the same time as the customer. It happens. But this is the time to really apply the above process design. What do you want the customer to experience when things go wrong?

Ironically, in the customer satisfaction world, a spectacular and surprising recovery actually generates more loyalty than flawless delivery of service. This is the moment for your company to shine.

Whatever happens, though, make sure it is something you would do on purpose rather than relying on chance or a random team member’s disposition. Build “caring” into the process itself, and you will embed it into the culture.

Posted on

Travel Tales

One of the advantages of having a business performance blog is I have a ready place to rant complain share my customer experiences with the air travel industry.

It all started Monday. I had a flight from Seattle to Raleigh-Durham NC, connecting in Newark. It was only a two day trip, so I was traveling pretty light.

As we were boarding the 737 the bins filled up fast and everyone forward of about Row 15 was required to check their bags all the way to the destination. “We apologize for the inconvenience” (after pointing out how it was the customers’ fault because they had offered a chance for people to volunteer to check their bags, and not enough people did.)

OK, I checked my bag through to RDU. (Forshadowing)

Once on board, the pilot let us know that there were air traffic control delays enroute, but we were going to pull away from the gate anyway, and park on the tarmac until cleared. (This, by the way, lets them get credit for an on-time departure.)

That wasn’t too bad, only about 10 minutes. “We apologize for the delay.”

As we got to about the Great Lakes, the plane banks left. And banks. And banks. The shadow is gliding over the engine cowling, and returns to its previous position, the plane levels off. Yup, we just did what they call a “racetrack.”

Then we do another.

And another.

And some more.

We land at precisely the time my connecting flight is scheduled to depart. Not gonna make it. “There will be an agent waiting at the gate. We apologize for the inconvenience.”

Well – maybe everything is delayed, and I can still make the connecting flight. It wouldn’t be the first time I have lucked out that way.

Nope. Well, not quite. It hasn’t left because the plane never left RDU. Flight cancelled. “Head down to Customer Service at Gate 105.”

Wait in line, pretty surprised actually. Rebooked on a 7:32 flight, delayed to 9:51. Ugh. Got a few hours in the airport. “What about my luggage?” “It will be on the plane with you,” I was assured. More foreshadowing.

9:51 comes and goes. No plane. We’re told the inbound plane is enroute. OK.

I am having a nice chat with the pilot for our eventual flight to RDU. He is actually quite interested in the TPS. “Can you do this with airlines?” he asks, half seriously. He asks for a card. I know enough about aviation to have a very articulate conversation with a pilot about planes, flying, and the business, so that was nice. “No, I am not a pilot,” I answer his question,  “but working at Boeing Flight Test for five years, you learn a thing or two about how airplanes work. I know what all the noises are.” He smiles.

Woo hoo. A plane shows up. Bombardier –8 Q400. We board.

And wait.

And wait.

11:15pm The (other) pilot gets on the P.A. and explains that they are overweight and working on how to handle it. He goes on to explain that due to the fog earlier in RDU, they have extra fuel on board. Further, the alternate airport is back at Newark. (Which means they need enough fuel for a round trip PLUS the reserve.) We wait. 11:45. A passenger (two, actually) volunteer on their own to be “bumped” to a flight tomorrow. Apparently that “solves the problem.” But the pilot had mentioned that part of the excessive load was “excess baggage from an earlier flight.”

“We apologize for the delay.”

“We are just as frustrated as you are.”

I should mention at this point one of the games that gets played here. By declaring the departure airport as the alternate airport, the airline can either land the plane at RDU with enough fuel for the return trip, or return it all the way to Newark and avoid a deadhead ferry flight from an alternate landing if they can’t make it into RDU.

At midnight the propeller begins to turn.

It is about a 90 minute flight.

I glance out the window and notice the propeller spinner is now white at the tip. Leading edge of the wing also turning white. In my brain fogged state I start thinking about this airline’s last accident.

We land at RDU at 1:40 or so. The airport is pretty much buttoned up except for us.

Head down to baggage claim. A few bags come out, then the sign flashes from “unloading” to “completed.” There are twenty people still waiting.

I was one of them. It seems that a lot of the passengers on the plane were the ones whose baggage was left behind because it was just bags from an earlier flight.

Our little cluster heads over to the airline’s baggage office. There are two people there, and it clear from their body language (and verbal language for that matter) that this was not in their plans for the evening. We customers with no baggage have, apparently, really inconvenienced them.

It turns out that, of the two, only one of them “can operate the computer.” so they are processing one person at a time, with a cycle time of roughly 10 minutes per person.

The non-computer one comes out. People ask her when they can expect their luggage to get here. She, in an annoyed “I already-told-you-I-can’t-do-anything” tone carefully explains that only her computer-literate co-worker can find out, and only when they scan the ticket and search for things on the computer.

She asks if we would like the 800 number. Sure. She goes into the office and comes out with the number written on a scrap of paper and reads it off while people try to type it into their phones. (Tape it up on the window? Nah.)

I manage to get through, “All of our representatives are currently serving other customers.” (Yes, I can actually SEE them right now.) “The wait time is approximately TWENTY minutes.” I am reminded multiple times that all I need to do is go to www.(Houston based airline name).com, click here, click there, enter this, enter that, and I can do all of this myself. Not exactly helpful in an airport terminal at 2:15am.

A human answers. She asks for my case number. Huh? I have the baggage claim number. It seems she is actually there to handle follow-up rather than initial calls. Nevertheless, she is very helpful, takes my information, and offers to authorize me to spend $75 if I need to buy something for my client meeting in the morning. “Thank you,” I say sincerely, and laugh with her that there isn’t a lot I can buy at 2:30 in the morning.

Head for the rental car counter. I still have a 90 minute drive ahead of me.

The only thing in the “Emerald Aisle” is a big pickup truck. I don’t feel like taking it, so I go into the office. A very nice gentleman at the National counter is surprised about the number of people showing up all of a sudden, I explain a late arrival. He asks if I want an SUV, I said sure, he tells me where it is.

I get in, start it up, punch in my hotel address into my phone (I LOVE Android GPS), and start out. Once I clear the gate, there is a 20 mph speed limit, and one of those radar signs that says how fast you are going. I see the sign, and immediately slow down. My speedometer is dropping down under 40, as the radar sign is dropping down under 20. Huh? Take a good look through the foggy brain. Kilometers Per Hour. Yup. I have a Canadian vehicle. So driving through rural North Carolina having to run metric conversion in my head. No big deal, but the final irony.

I arrive at the hotel at 4:30. The night clerk is on the phone, “Just a minute sir, they are doing an night audit.” I mention that I have been on the road for 22 hours. She takes the hint and interrupts the auditor to check me in.

4:45, I get to the room, take a shower, and settle down for my 75 minute nap before meeting my client in the lobby at 7am for a great day on site.

Good news – the suitcase showed up the next day.

Of all of the places that I have “gotten ahead of my luggage” this was actually the least exotic. The last three were Berlin, Glasgow and Tunis. Danville, VA just doesn’t seem that exciting by comparison.

So this was 20 hours of hearing airline employees begin every other statement with “we apologize.” (Except the baggage claim people who were quite UNapologetic). I suppose this was catching up with the law of averages for a series of very smooth and uneventful travel adventures lately.

What if a key airline performance metric was how many times their employees use the words “we apologize” during a given day? If they actually meant it, the number should steadily decline.

 Smile

Hopefully the flight home will be less of an adventure.

All humor aside, this experience revealed a couple of obvious breakdown points.

First, I normally try to avoid any connection in the NYC area. The airspace is just too crowded for things to work under less than ideal conditions. But faced with the client’s requirement to use their travel booking, and unable to gerrymander arrival / departure times to force a decent fare-competitive alternative out of the system, I kinda had to take this one.

Let’s talk about the baggage thing. At the departure airport, we have the aircraft service process that loads fuel, calculates weights, generally gets the plane ready for a safe flight within regulatory guidelines (and consistent with airline economic objectives).

We have a separate process that takes luggage with “RDU” tags and loads them onto a plane headed for RDU.

And yet another process for getting the passengers manifested and loaded.

I surmise that there are three separate processes here because there were ample opportunities for cross-process communication that obviously did not happen.

The pilot was apparently surprised by the overweight condition. Yet the airline knew, hours before the plane even arrived at the airport:

  • How much fuel they planned to load.
  • How many passengers they planned to load.
  • How much luggage (and, if they really wanted to, the weight of that luggage) they planned to load.

What if they started to work the problem of overweight condition before just tossing the problem into laps of the newly arrived flight crew?

Based on the way the pilot spoke of the “excess baggage” it was not clear to him, or the gate agent, that the “excess baggage” belonged to the “excess customers” that were on the plane. I am not sure if that knowledge would have made any difference if they knew they were flying people without their bags, but at the minimum it would have set up a far more appropriate process at RDU.

As you recall, the baggage office at RDU was surprised (and apparently annoyed) that all of these passengers showed up, and now they were understaffed to deal with them.

Imagine, if you would, an alternate scenario.

The airline KNOWS which passengers are on board the plane. They KNOW which bags are on board the plane. (This is a true statement.)

What if their system cross-correlated bags with passengers.

What if, upon flagging the condition where they had a passenger in a seat, but no luggage in the hold, they notified the baggage office at the destination airport.

What if, upon receiving this information, the airline’s employees, using information they already have in their system, traced the bags and made plans.

What if, upon arrival at the destination airport, those passengers were greeted by name. What if “Mr Rosenthal, we are sorry, but your luggage didn’t make the flight. It is still in Newark. If you let us know where you are staying, we will get it here on the first available flight in the morning and have it delivered. Is there anything else you need?”

The net effect would have been the same, the airline would have done what they ended up doing anyway, except the customers would have received a little empathy. No extra cost, just a little more service. The baggage claim people could have gone home two hours earlier, and although inconvenienced, the customers might be left with the impression that somebody actually cared.

But, for those of you who remember the old Saturday Night Live Steve Martin Theodoric of York skits – First the soliloquy about how wonderful a situation could be then the punchline:  “Naaaaaaah.” as he returned to his medieval ways.

Oh – and I finished reading the Liker book I have been discussing, so look for a couple of more write-ups and then an actual review as I get some keyboard time.

Posted on

Year of the Dragon

forbidden-city-dragon-200-squareHappy New Year for the Year of the Dragon to all of my Chinese friends around the world.

January 23 is the New Year. This message is timed to appear at midnight, Beijing time, as the fireworks are reaching a crescendo.

I look at the time I spent in China as a period of great personal growth and learning.

As a bonus, I got to know the culture, aspirations, conflicts and the fabric of life there.

The relationships from that time still impact my life in very real ways every day.

Posted on

Steve Spear on Creative Experimentation

On Monday MIT hosted a webinar with Steven Spear on the topic of “Creative Experimentation.”

A key theme woven throughout Spear’s work is the world today is orders of magnitude more complex than it was even 10 or 15 years ago. Where, in the past, it was feasible for a single person or small group to oversee every aspect of a system, today that simply isn’t possible except in trivial cases. Where, in 1965 it was possible for one person to understand every detail of how an automobile worked, today it is not.

My interpretation goes something like this:

Systems are composed of nodes, each acting on inputs and triggering outputs. In the past, most systems were largely linear. The output of upstream nodes was the input of those immediately downstream. You can see this in the Ford Mustang example that Spear discusses in the webinar.

Today nodes are far more interconnected. Cause and effect is not clear. There are feed-back and feed-forward connections and loop-backs. Interactions between processes impact the results as much as the processes themselves.

Traditional management still tries to manage what is inside the nodes. Performance, and problems, come from the interconnections between nodes more than from within them.

The other key point is that traditional management seeks to first define, then develop a system with the goal of eventually reaching a steady state. Today, though, the steady state simply does not exist.

Product development cycles are quickening. Before one product is stable, the next one is launched. There is no plateau anymore in most industries.

From my notes – “The right answer is not the answer for very long. It changes continuously.”

Therefore, it is vital that organizations be able to handle rapid shifts quickly.

With that, here is the recorded webinar.

(Edit: The original flies have been deleted from the MIT server.)

A couple of things struck me as I participated in this.

Acknowledging that Spear has a bias here (as do I), the fact that Toyota’s inherent structure and management system is set up to deal with the world this way is probably one of the greatest advantages ever created by happenstance.

I say that because I don’t believe Toyota ever set out to design a system to manage complexity. It just emerged from necessity.

We have an advantage of being able to study it and try to grasp how it works, but we won’t be able to replicate it by decomposing its pieces and putting it back together.

Like all complex systems, this one works because of the connections, and those connections are ever changing and adapting. You can’t take a snapshot and say “this is it” any more than you can create a static neural net and say you have a brain.

Local Capability

One thing that emerges as critical is developing a local capability for this creative experimentation.

I think, what Spear calls “creative experimentation” is not that different from what Rother calls the “improvement kata.” Rother brings more structure to the process, but they are describing essentially the same thing.

Why is local capability critical? Processes today are too complex to have a single point of influence. One small team cannot see the entire picture. Neither can that small team go from node to node and fix everything. (This is the model that is used in operations that have dedicated staff improvement specialists, and this is why improvements plateau.)

The only way to respond as quickly as change is happening is to have the response system embedded throughout the network.

How do you develop local capability? That is the crux of the problem in most organizations. I was in an online coaching session on Tuesday discussing a similar problem. But, in reality, you develop the capability the way you develop any skill: practice. And this brings us back to the key point in Kata.

Practice goes no good unless you are striving against an ideal standard. It is, therefore, crucial to have a standardized problem solving approach that people are trying to master.

To be clear, after they have mastered it, they earn a license to push the boundaries a bit. But I am referring to true mastery here, not simple proficiency. My advice is  to focus on establishing the standard. That is difficult enough.

An Example: Decoding Mary – Find the Bright Spots

Spear’s story of “Decoding Mary” where the re-admission rate of patients to a hospital directly correlated with the particular nurse handled their transfer reminded me of Heath & Heath’s stories from Switch. One of the nine levers for change that they cite is “find the bright spots.”

In this case the creative experimentation was the process of trying to figure out exactly what Mary did differently so it could be codified and replicated for a more consistent result independent of who did it.

The key, in both of these cases, is to find success and study it, trying to capture what is different – and capture it in a way that can be easily replicated. That is exactly what happened here.

A lot of organizations do this backwards. They study what (or who) is not performing to determine what is wrong.

Sometimes it is far easier to try to extract the essence what works. Where are your bright spots for superb quality? Does one shift, or one crew, perform better than the others? Do you even know? It took some real digging to reveal that “Mary” was even the correlating factor here.

Continuous Improvement Means Continuous Change

Since “continuous improvement” really means “continuously improving the capability of your people,” now perhaps we have “to do what.” I have said (and still say) that the “what” is problem solving.

What you get for that, though, is a deep capability to deal with accelerating change at an accelerating rate without losing your orientation or balance.

It is the means to allow the pieces of the organization to continue to operate in harmony while everything is changing. That brings us back to another dilemma: What is the ROI on learning to become very, very good? You don’t know what the future is going to throw at you, only that you need the capability to deal with it at an ever quicker pace.

But none of this works unless you make a concerted effort to get good at it.

Here is the original link to the MIT page with the video, and a download link for PDFs of the slides:

http://sdm.mit.edu/news/news_articles/webinar_010912/webinar-spear-complex-operating-systems.html

Posted on

Flow Assembly of a 30 Story Building

Though I have some reservations (see below), this video shows a lot of good examples of flow for final assembly – only the assembly line is vertical, and the product is a 30 story hotel.

The video actually repeats twice, once with a music sound track, then a second time with no sound.

The Good

All in all, this is pretty impressive. Let’s look at the good examples that you can incorporate into your own thinking.

First, the product is designed for quick and easy assembly from the get-go. The engineers thought through how it would go together as a core part of their design process. There was no “throw it over the wall and figure it out” here.

The design itself is very modular. Detail work is done off-line in the “feeders.” This is how you want to set up an assembly line – the backbone (main line) is installation of “big chunks” that are assembled and tested in the feeders. This helps stabilize the work on the main line.

The assembly itself was flowing. Each floor progressed subsequently through the assembly stages as more stories were being added at the top. Contrast this with the more common approach of finishing the frame, then batching the various trades through.

What We Don’t Know

It is clear that this was done as a stunt. They did a good job. There are, however, legitimate questions about how, or if, the work was organized to surface and deal with quality issues. What was the line-stop process?

There are also legitimate questions in the building trade about the long-term stability of foundations and structure that does not have time to settle as it is going up. Building that go up fast can come down fast.

We truthfully don’t have enough information to make a judgment here, but I want to acknowledge those concerns as realistic whenever we see something like this.

Apparently those issues are unfounded. I admit I was repeating what I had read elsewhere. I am certainly not an expert. (See comment below)

Still, it is really cool so I wanted to share it as a good application of flow thinking.

Posted on

Lean Leadership: Kaizen is Management

Chapter 4 of The Toyota Way to Lean Leadership lays out the picture of a company where continuous improvement of operations is the primary focus of the management system.

Note here that I said “focus of the management system” rather than “focus of the managers.” I believe there is a crucial difference which I will explain in a bit.

Liker and Convis start out by explaining what “kaizen” isn’t. Sad that they have to do this, but the problem is summed up nicely:

Too often [kaizen] has come to mean assembling a special team for a project using lean of Six Sigma methods, or perhaps organizing a kaizen “event” for a week to make a burst of changes. We sometimes hear the phrase “doing a kaizen” as if it were a one-off activity. At Toyota, kaizen […] is how the company operates at the most fundamental level.

One of the persistent mysteries (to me) is why, after decades of knowing otherwise, so many businesses still consider “kaizen” or “improvement” to be a separate activity from “management.”

A few weeks ago I expanded on a great presentation by Bill Costantino that explained the relationship between challenges, targets, kaizen and the knowledge space of the company.

In that post, I created an animation of Bill’s graphic that illustrates progressive targets pushing the threshold of knowledge relentlessly toward the objective.

In this model, although we have a decent idea where we are, and what we want to end up with, the details of the path to get there are not known in advance.

Lean Leadership illustrates the same point quite well with the story of a factory kaizen team at TMMK (Toyota’s Georgetown, Kentucky facility). Of note is that this team is made up largely of production workers. It isn’t “the improvement team.” It isn’t an engineering department team. It is the people who have to live with the solution.

The team’s challenge was to improve a wasteful process for handling and moving sheet metal parts through the plant to the point of use on the assembly line.

They started by studying another company’s solution to the problem.

Did I mention that this team of factory workers from Kentucky spent two weeks in Japan studying this supplier’s system? Why make this kind of investment? Ponder that a bit, we’ll get back to this too.

Once back in Kentucky, the team had a clear sense of the challenge, and set out to progressively develop their own solution by experimentation, observation, and learning.

First they tried copying the benchmarked system on a small-scale test to deepen their understanding of what they had studied. Trying it on their parts surfaced differences that weren’t obvious at first, and they learned copying definitely wouldn’t work.

Key: The reason they tried to copy was to learn more about it. This was a small-scale concept test, not an attempt at wholesale implementation.

Even if it had worked, copying develops no skill other than reverse-engineering someone else’s solution that was developed for a different problem in different conditions. When people then say “See, it won’t work here” this is likely how they got to that conclusion. Too many companies “benchmark” and then try to do this. This team took a completely different approach.

“OK, cool, it didn’t work. Try something else.” And that is how learning happens.

They go back to grasping the original problem – damage from forklift handling. This is crucial. So many teams get bogged down on defining the “problem” as “making the fixed solution work” and end up expending a lot of effort in a tunnel with a dead-end. This is about exploring possible solutions to the actual problem.

They end up developing something quite different from what they benchmarked, that delivered the right parts, in the right orientation to the assembly operator. They knew this because they were their own customers – these were people who did this job.

Once they had it working on a sub-set of easier parts, they expanded the concept step by step (a few parts at a time) to handle the larger ones.

Key: Get the simple version working before trying to add complexity. Control your experiments. This is how learning happens vs. “just fiddling with it until it works.”

They proceed step by step – now sharing back and forth with the benchmark company who is seeing their solutions and building on them, until they have an AGV pulling a sequenced line of part carts that were loaded by robots, everything moving at takt.

Still, there was a lot of human interaction and they kept working to better synchronize everything.

Step by step, they worked their way back into parts that came from outside suppliers, dealing with one issue at a time.

Then a remarkable thing happened:

…at some point an hourly team member asked why the company was spending so much money to buy AGVs from external suppliers. Toyota manufactures vehicles, after all. Team members found they could buy the little robotic device that pulls the carts and custom-make the carts themselves.

But they didn’t stop there.

Later they discovered they could buy inexpensive, generic circuit boards of the type used in the AGV and program the boards themselves so that the AGVs would stop and wait at certain points along the line. Programming the AGVs themselves was a breakthrough, since it cut out licensing fees and added the flexibility to reprogram them. The original AGVs cost about $25,000 each; the ones built in-house cost under $4,000. With more than 100 AGVs in use, the team members kaizen initiative saved TMMK more than $2 million.

Let’s take a step back from this and look at what was really happening here.

What did these team members know at the end of this process that the didn’t know at the beginning?

What knowledge did they add to the company’s capability? Beyond the simple technical solution, what else did they learn? What confidence did they gain?

In other words, how did participating in this process improve the capability of the team members to improve other processes?

What would it be worth to your company to have team members who could think like this? (Hint – you already have them)

I promised to address a couple of points later. Here they are:

The role of managers vs. the management system.

The management system in any company is rightly focused on ensuring that operations are delivering the most customer value for the least cost. This is true of any value-creating operation, be it organized for profit or non-profit.

But the picture being painted by Liker and Convis is one where this management system works by ensuring the managers (that is, the individual people who are responsible for the operation) are focused on developing people’s capability.

To do this, Toyota has a specific process for developing leaders to embrace this responsibility.

This isn’t a new message. But it is emerging more clearly and more consistently in the popular literature in the last few years.

Which brings us to who made the improvements.

In this example, the improvements were made by production team members.

The company probably could have achieved similar (or at least similar looking) results with a project plan and a team of engineers. It might have even been faster.

But the production workers would have learned nothing other than to accept whatever the engineers gave them.

It is unlikely it would have occurred to anyone to build their own AGVs and save another couple of megabucks.

And the capacity of the company for improvements would have remained the same rather than increasing. At some point, the rate of improvement is constrained by the resources that can be dedicated to the task.

So, while an individual improvement task might take longer as people learn, in the end there is a multiplier effect as more and more people get better and better at making improvements. Sadly, it is really impossible to assign an ROI to that, so traditional management doesn’t allow for it.

This post is long enough. There is more in Chapter 4 to talk about, but I want to get this out there.

Posted on

Simple Solutions

Carlos Villela’s blog lixo.org has a great story about simple solutions. I really have no idea if it is true or not – indeed, a couple of the details don’t hang together. On the other hand, I have seen for myself the kind of thinking that is described in this story.

Link to full story: Networks are smart at the edges.

The factory is having a quality issue. The response is pretty typical:

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

And a great solution. It stops the line and forces someone to pay attention to the problem. While I would usually add that these instances need to be followed up by problem solving to eliminate the issue, even if I were doing so, I wouldn’t eliminate the final verification check. Even Toyota performs a thorough and rigorous final inspection. But that’s not the point here.

It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.

Like the Dilbert cartoon about 25 critical focus areas, this is more funny because the original reaction is totally typical, especially in companies who are comfortable with technology, controls, automation, etc.

Cudos to the CEO who realized, at least, that “No problem is a problem” and went to investigate at the actual gemba.

Once the team had a challenge (in this case small-Peanut-MMsprovided by the annoying bell) they dealt with what they saw as the issue.

Oh – and this graphic? It is an inside joke for some of my readers. Maybe we should have put some fans on the conveyer.

Thanks to Hal for sending the original link to this article.