Reading the Signs

"Do not throw away. We refill the empty bottles."

These are the labels I see on the toiletry bottles at my gym. Pretty unremarkable, unless you really think about them. Another label/sign I always remember is a sign I saw on a hotel room desk that said, "Turn on switch below to provide power to desk lights."

Why do signs like these exist? The obvious answer would be "to address a problem," right. But, think carefully, how do we know a sign is the best countermeasure?

In the first example, the gym is waiting to refill bottles only after they are empty. Instead of thinking about a process solution for members throwing away the empty bottles, the gym just made a label. How else could they have solved this problem? Well, if the toiletries were topped off each evening there would be no need for a label. That's just one idea, but I'm sure there are other solutions.

In the second example, the desk was designed so that the power switch for the lights is hidden below a darkened shelve. (Did I mention that the switch itself was dark brown? Almost a catch-22. You need a light to see the switch to activate the light!). If the desk were designed so the switch is located in a more obvious location, no sign would be needed. Starting to get the idea?

Ok, ok, what does any of this have to do with Lean?

How often does your organization settle for an inferior process design or process fix, bandaged together with labels and signs? This approach merely shifts the burden of the process inadequacies to the user. I remember once I observed a workstation at a plant that had nine different quality alerts posted in front of the operator. Nine! This meant nine problems were left unsolved and the burden was shifted to the operator. 

So before you are tempted to add a sign to any process, or just employ an add-on or work around to any process, remember a quote from my sensei Yamada-san, “Signs are an excuse that we could not make a good system.”

Look, signs are great and will never completely go away, but they should be the exception and not the rule. Look for real process solutions to your problems. Of course this requires really slowing down and getting your hands dirty in PDCA problem solving. But it’s worth it.