Monday, June 27, 2005
On a flight today from Colorado Springs to Houston on a small regional jet, I asked the flight attendant for a can of Diet Coke. She prepared to hand me an unopened can and at the moment of handoff, we hit a bit of choppy air. The can missed my hand, hit the edge of the cart, did a triple somersault in the pike position, hit the aisle of the plane and rolled three rows back, where a laughing fellow passenger retrieved it and handed it back up towards me.
Amidst the jovial comments on what that can of soda would do, the flight attendant kindly offered to swap it out for one that had not had such a rough ride. And, in a rare moment of clarity, I declined. "Why would we want to give this to someone else who is unaware of its state?" I posed to her. She looked at me a bit funny and I laughed with her, muttering something about PV=nRT, the only equation I remember from college chemistry. Yet I meant it and she accepted my odd reasoning and I kept the can. And, with a cautious, gentle lifting of the tab and two inelegant though effective slurps off the top of the can, I had my soda. No one else got sprayed. The flight attendant didn't have to explain anything away.
I got thinking about this brief incident. What happens when we pass along a piece of work we know is defective? Especially if it isn't obvious from the outside? Like a shaken-up can of soda? Yeah...we simply create grief down the line. Someone else has to clean up the mess. What happens, alternatively, when we don't pass along work we know is defective? Very often, as in this case, the operator can correct the error. And it cuts off the chain of error downstream.
There are defects in this analogy. But the principle of refusing to pass along a known problem holds in any lean system. I hope you will think twice today about passing along your Fizzy Coke.
Saturday, June 18, 2005
My colleague Misty took a couple of well-deserved vacation days last week and, due to other scheduling issues, the only person in the place to cover her role in order entry was yours truly. Misty went over detailed instructions with me on Tuesday, in desperate hopes that I wouldn't completely crash the system, and then left, quietly fearful over what she would find when she returned.
As she predicted, we got a large, complex order from a major customer on Friday morning. I pulled out her excellent instructions and got the orders placed, seemingly correct from indications of our error-proofing methods (though I put them in much more slowly than Misty). But several other useful observations flowed from this small exercise.
The value of cross training. It is necessary to have some back up, particularly in a small company. It is well worth the time.
Appreciating people. The hour or so I spent with the orders gave me a fuller appreciation of Misty's skills.
Seeing new things. I had not interacted with the details of our customer's ordering patterns. Though I reviewed them from an aggregate point of view, I had not "rolled around in the dust" with them. And that was useful.
Ways to improve. Misty is such a pro at what she does, she knows how to make some of the cumbersome elements of our system be more nimble. As I bumbled through them, I got several ideas on how we might eliminate some of the steps altogether.
All of these are expected when one goes to gemba, to the work place, and interacts with it directly. Fresh eyes see new things. Fresh eyes learn better.
I hope you can soon go to a part of your workplace you seldom frequent. Look for a way to cover for someone on vacation this summer. Write down what you learn. Propose local improvements. Eliminate some waste.
I hope this is helpful.
Wednesday, June 15, 2005
Settling for "good enough"
Relentless improvement is not a natural phenomenon. Seth Godin writes today on Seth's Blog: The seduction of "good enough" and it is very useful. One of the best summaries of the topic I've seen.
Go better, lighter, faster, cheaper, helpfuler. Somehow.
And, it's a good reason to keep reading and learning. Someone else is always thinking better and you and I had best know about it.
I hope this is helpful.
Monday, June 13, 2005
Sometimes watching Lean Systems can be downright hilarious. At least to me...
A fundamental concept in Lean is the use of Signals. The word "kanban" simply means "signal." And in a Lean System we use signals to trigger action, just in time. Signals are binary and mean one thing, clearly. Andon boards, painted lines, kanban, kaizen plans, standard work charts. All signals.
But I didn't anticipate a signal when my wife and I went to lunch recently. We got into the popular local restaurant ahead of the usual lunch crowd and the place filled up while we ate. We were engaged in a substantive and useful conversation, however, and were oblivious of a) the time and b) the fact that Darrin, our waiter, really really wanted us to move on so he could get another group into our booth and get another tip. Those of you who know me realize I can consume large quantities of iced tea in such a setting and Darrin had been doing a good job of keeping my glass filled.
Then Darrin had an idea for a signal. He stopped by the table, asked if I'd like some more tea and, as he expected, I said yes. Rather than just refill my glass from the pitcher, however, he went back to the kitchen, poured iced tea into a Styrofoam cup that said "To Go" on the outside and plunked it on the table.
A signal. One that said "You are done eating, dude. Take your tea and go. Let me get a tip from someone else." I laughed, admitted defeat and off we went.
Nicely done, Darrin.
Understand your signals.
I hope this is helpful.