Constraints Push Innovation

This Ted Talk by Amos Winter is about a fantastic project to develop an inexpensive, rugged, rough-terrain wheelchair for people in countries with much less infrastructure than we take for granted in the U.S. and Europe.

Though they didn’t follow the traditional “3P” approach, their project did reveal a few key elements. More below the video.

What Winter talks about as constraints:

  • Cost < $200
  • Parts readily available
  • Repairable by local trades (bicycle shops)

we could also talk about as a “target condition.”

Winter describes an iterative design process where the first two attempts failed once they got them into the hands of actual users. A valuable lesson – the only true “voice of the customer” is the customer!

The “Marshmallow Challenge” (in the link back above) describes the power of an iterative process within a constrained design space as well – though the most rapid learning occurs in a group that may surprise you.

A company I worked for got a challenge from Mr. Nakao of Shingijutsu: “Make your next year of aggressive growth with:

  • No more people.
  • No more space.
  • No more money (capital).

In other words, squeeze it out of the waste that is all around you. That was a year of intense learning for all of us, but even today that company has one of the highest value-add per unit of area I have seen in any plant, with operations reaching inventory turns in mid-to-high double digits.

The experience of “constraints driving innovation” also plays out in a client project I have been involved with. They set out a challenge for themselves that was very aggressive – an order of magnitude difference from their current baseline. Then they set out to meet that challenge.

Past history (they tell me) has been to routinely break the “constraints” in these projects, but this time around they are sticking to their own rules.

What has emerged a large wall covered with major sub-goals, each with its criteria (the target condition), the current level of performance, the gap, the next trial they expect to run, the expected result.

They have been working hard to try to reduce the cycle time of those experiments: What can we do with what we have; What can we do for free or cheap rather than waiting until everything is here?

The key point here is that a well focused challenge can align people’s efforts and keep them focused on the objective.

The best challenges are the ones that come from within.

What are you striving for?

One-By-One; On Demand; As Requested

Once again we see another data point on the trend.

Why is “batching more efficient?”

Simple – you haven’t solved the problems yet.

Here is an ice cream shop that has no ice cream… until you order it.

Does this shop surface the next layer of issues to solve? Certainly. But by thinking it is possible and they trying it, she is learning fast.

Finding Patterns

“What is your target condition?”

“One-by-one flow, meeting an 11 minute planned cycle time, with two people.”

“What is your current condition now?”

“We are making rate, but our lowest repeatable times add up to 28 minutes, and with that and the 32% variation we are seeing, we need 3 people on the line to do it consistently.”

“Where is all of that variation coming from? What are people struggling with?”

“All of the assemblies are different!”

And this was kind of true. We had five different larger assemblies firing in a repeating cycle:

A, B, C, A, D, E, A, B, C, A, D, E

And to make the discussion more interesting, each of these items has four sub-assemblies, of different types, that go into it. This line was building those sub-assemblies in a sequence that matched the need. So it is easy to see why all of that variation seemed overwhelming.

But there was commonality, a lot of it. The operations were very similar, with the differences being things like:

  • A left-hand or right-hand difference.
  • An operation is included, or excluded from a particular sub-assembly.
  • Differences in geometry that had little or no bearing on the actual operations being conducted.

My goal was to lead them to doing more detailed observations, seeing the blind assembly operations, chaotic layout on the bench, the occasional hunt for information, and at this point, the learning curve the assemblers are still coming down as we identify key points.

We are hard-wired to see differences in things – that blade of grass is bent, is there a tiger there? Sometimes it is more challenging to seek out and become aware of the underlying patterns. In other words, what these items have in common.

Rather than looking at obstacles to build the parts, we want to look at the obstacles to smoothly carrying out the operations. It is a subtle difference, but an important one. Sometimes you have to search through the noise to find the signal.

As of this writing, the bench is getting better organized, tools are getting homes, and some assembly aids and tools are being developed to avoid having large fingers trying to get things done in small places.

The work is starting to stabilize enough that the patterns are becoming more visible, which allows capturing the work breakdown in a rational way that can be taught – first the base industrial skills, then the common operations, then the sequence of those operations for specific parts.

We’ll get there.

TSA Kata

Robert Heinlein observed (through the HOLMES IV computer character in The Moon is a Harsh Mistress) that “humor” often centers around the misfortune of others. I’ll make this little story topical by hypothetically applying the “coaching kata”…

This wasn’t me, just something I witnessed. If only people would apply PDCA to real life… If I were coaching this guy, it might go something like this:

“What is your target condition?”

“To get to the gate for my flight.”

“What is your current condition now?

“In the TSA security checkpoint.”

“What obstacle are you addressing?

“The TSA wants to do a secondary screen on me, delaying my passage through the checkpoint.”

“What was your last experiment?”

“I raised my voice and became indignant, accusing them of not knowing what they were doing.”

“What result did you expect?”

“That they would understand they were wrong, and let me pass.”

“What actually happened?”

“A lot more TSA agents showed up, along with a police officer.”

“What did you learn?”

I think the trajectory is pretty clear from this point…

What is the ROI for That Log?

I still see companies struggle to apply a financial return on every improvement proposed.

PC has made an excellent analogy in a post on the forum. Rather than repeat it here, I’ll give you the link, maybe we can get a conversation started.

http://forums.theleanthinker.com/viewtopic.php?f=9&p=903#p903

(Sidebar: I am pretty aggressive about deleting accounts that look like spammers. If I got yours by mistake, write to me at “Contact Mark” on the right sidebar, and I’ll fix it.)

Obstacles vs. Lists of Tools

I have been noticing a significant linguistic difference between those who still embrace the “implement the tools” paradigm, and a much smaller (but growing) group are are adopting the PDCA thinking structure as a framework for everything else.

It comes down to how a problem is stated.

We were looking at an operation with a lot of variation from one team member to another, both in terms of performance, and actually, what precisely was being done.

When asked what the obstacle was, the immediate reply was “Lack of standard work.”

While this may have been true, it is not a statement of the problem. Rather, it is defining the problem as “lack of a specific solution.”

This may seem to be an semantic discussion, but consider what the responsible supervisor hears, and interprets, from these two statements:

“There isn’t any standard work.”

or

“There is a lot of variation from one operator to another.”

In the first case, we are telling the supervisor what she isn’t doing, hasn’t done, needs to do. It isn’t even teaching.

In the second case, we are pointing out something that we can both agree on. I haven’t even said it is a problem, and honestly, in some cases it might not be (yet). It is a simple observation.

If, then, we agree that this variation is leading to some undesirable effect, then we can talk about countermeasures. That might include trying to capture a baseline, teach it to a few of the team members, and see if that helps. We can name it later.

Which of those approaches is more likely to enlist the support of the supervisor, which is more likely to put her on the defensive?

Lean thinking is not a checklist of which tools are in place. It is a step-by-step convergence on smoother flow, dealing with observed obstacles and problems.

This isn’t to say that the coach doesn’t have intimate knowledge and experience with flow, with standard work, and everything else. But the approach must be respectful of the people who are struggling with the real world issues every day. Saying “You need to implement standard work” isn’t helpful no matter how much logical justification is wrapped around it.

Teaching someone to observe the impact of variation on the process might seem slower, but it will get them there much faster because it engages their curiosity.

Appearances vs. Reality

I’m looking at a form labeled as an X-Bar / R-Bar SPC chart. It is filled out pretty consistently by the operators.

But the “control limits” are actually specification limits, and the “standard deviation” looks like it is calculated as 1/3 x the spec limits to force the lines to where they want them from the mean… er ah… nominal.

When I asked about it, at least one company leader was under no illusion that this was a statistical process control, it is simply a means to develop a run chart of actual parameters vs. a nominal value and the specification limits.

I’ve seen far worse, like the time an engineer didn’t understand the difference between “in control” and “in specification.”

But what do they say in their everyday conversations? Do they talk about this process being “within specification” or “in control?” I expect the later.

Some PDCA Cycles

We had five sequential operations. Although the lowest repeatable times for each were well within the planned / target cycle time, there was a lot of variation.

Though Operation 3 was working pretty continuously, Operations 4 and 5 (downstream) were getting starved on occasion, and the empty “bubble” was working its way to the output. The exit cycles, therefore, were irregular enough that they weren’t making rate.

The team set their target to stabilize Operation 3, with the expectation that doing so would smooth out the overall exit cycles.

To that end, they went back and started to study Operation 3 in a little more detail to better understand the obstacles that were impacting the Team Member’s ability to complete the work smoothly.

Then a wrinkle – a different team member was now doing the work, and his cycles were faster.

This actually was an opportunity. Why is one Team Member faster than another?

Their hypothesis was that the faster Team Member had some knack or technique, that enabled him to perform more consistently. And indeed, he did have a few tricks.

So the first experiment was to capture this work cycle in a Job Breakdown, then see if using Job Instruction and teaching it to the first Team Member they could duplicate the results of the second.

Then another wrinkle. The first team member was back on the job. Armed with the knowledge gained by breaking down the steps, key points and reasons for Team Member #2, they took more baseline data from Team Member #1 to set up their experiment.

…only to discover that Team Member #1 was also doing things that #2 didn’t do.

One of those things was unbending a part that was sometimes being bent by an upstream operation.

It seems that #2 was just passing those along as he got them. With that background, the conversation went something like this:

“What obstacle are you addressing?”

“The manual rework in Operation 3 is adding variation and extending his cycles.”

“What experiment are you running next?”

“We think the jig being used in Operation 1 is a bit undersize, allowing the part to deform. We are going to adjust the jig to the proper size.”

“What do you expect from that?”

“We expect to eliminate bent and deflected parts, and see more consistency in Operation #3’s cycles.”

Then they tried it. Skipping ahead a bit:

“What actually happened?”

“The parts are now more consistent, and there Operation #3 has a lot less variation, and is running closer to the planned cycle time… except that now he is waiting on parts from the upstream operation.”

“Huh. What is happening there? What did you just learn?”

“Well, it looks like Operation #3’s variation was masking inconsistent delivery from Operation #2. That team member is operating in small batches, then turning and delivering 3-5 parts at a time. When there was a lot of variation in Op #3, those parts were kind of buffering everything. Now he is working more consistently and faster, and ends up waiting on parts.”

“Because of the layout, the Operation #2 Team Member has to turn to his left and pass the parts behind him. He said he batches so he doesn’t have to turn so often. So what we are thinking is we want to…”

“Hang on, I want to stick to the structure so you guys can practice hearing and responding to it… So – what is your next step?”

“We talked to the team members, and they all agree that if we straighten out that bend in the layout, this will be a lot easier on them, so we are going to do that during the lunch break.”

“And what do you expect from that?”

“Operation #3 will get his parts one-by-one, as they are ready, and won’t have to wait on them.

“Great, so when can we see what you have learned?”

“Give us about 30 minutes after lunch break is over.”

You can probably surmise that things smoothed out a bit.

Then they went back to capturing a hybrid of the best practices of both operators in a job breakdown. At this point, the Team Members were genuinely interested in how they were doing, and both were quite open to learning the “tricks” of the other, so “Get the worker interested in learning the job” had pretty much been done.

A lot was learned over a few hours.

Reflection:

The “real world” is often quite a bit messier than the real world. There was actually a lot more dialog than I reconstructed here to keep the “learners” on track and focused on their stated target vs. resorting to an action of “improvements.”

In addition, merely beginning to work on one obstacle revealed enough information that they were dealing with a different underlying problem.

At another point in the week, they also believed they saw a need for more consistent part presentation. I happened to agree with them, but…

when pressed for what result they expected, the initial response was “The parts will be consistently presented.”… but what does that have to do with your target?

That was tough because, at the time, they were looking at the cycles of the 2nd operator that were, actually, pretty consistent, and lost sight of the fact that they were working on reducing the overall variation of output from that position.

They had a very hard time articulating why consistent part presentation would address the issue, even though they knew it should.

I think this is the result of years of conditioning that the “tools” – such as consistent part presentation – are good for their own sake, without really examining the underlying problems and causes that are being addressed.

If we lean practitioners are scratching our heads wondering why people don’t see this stuff helps, it would be a lot easier to deal with if we could point to the issue being addressed at the moment.

More tomorrow.

One-by-one, As Requested, When Requested

The world continues to move toward meeting customer’s true demand of one of something, when they want it, where they want it.

3D printing is one area where we can see the beginnings of a disruptive technology curve.

Laser printing has been around even longer.

Books are an area where the traditional mass-printing model is under assault from a number of directions.

Now On Demand Books is offering their Espresso Book Machine, fully automated production technology for a copy of a traditional paperback book. Check out the video.

Yes, the costs are higher for now, but in a niche market (which is where disruptive technology matures), that is less of an issue.

The trend is inevitable – it isn’t how fast you can go, it is how slow can you go while preserving the economy of scale. That is the challenge.