Andon itself is just a word that means lantern. In manufacturing, the andon signal is often a light, hence the name. But both the name and the light do not capture the essence of the process, which is why it is undervalued. Most see it as just a manufacturing thing. A better description for what it really accomplishes is help chain, bringing help to problems to keep your process stable. This purpose is useful in any process.
Another view is andon’s place in the hierarchy of lean methods. Many lean methods such as 5S, visual management and standard work help make problems visible. There are also many lean methods to help you solve problems, from A3s to 5 whys. Andon connects your library of problem-surfacing methods to your library of problem-solving methods.
Ignoring the manufacturing artifacts such as cords and lights, how does andon really work? Use these five core elements to build your andon system, or help chain.
1. High agreement of what is a problem. To trigger your andon process, you must first have a problem or abnormal condition. Without high agreement on what is a problem, our andon system will fall apart. If I believe that 5% behind schedule is a problem, and you don’t believe it is a problem until we’re 20% behind, we will have conflict instead of collaboration.
2. Mechanism to detect the problem. This sounds obvious but it often isn’t so clear, particularly in knowledge work. If we agree that a problem is when someone is stuck, how do we detect that? If we rely on just feeling stuck, then andon becomes an emotional process rather than a reliable objective one.
The mechanism could include how long work sits in a queue, work-in-process limits that force you to stop working when there are delays or hurdles, or incremental time checks that allow you to evaluate progress. Your mechanism must be embedded in the work itself, and not outside reviews or monitoring.
Join the Conversation with JAMIE FLINCHBAUGH and Other IdeaXchangeTM XpertsTM
3. Mechanism to surface the problem. In manufacturing, this is often pulling the cord and the light turning on. Many get stuck on this physical mechanism and can’t see how it would work in knowledge environments. Good design depends on the urgency of the request and on the geography or location of both the requestor and responder.
A sufficient mechanism could be a daily huddle where issues are raised, a system where issues are logged, or even a code word used in conversation or emails that make clear that you are triggering the andon.
4. Who will respond. Most problems go through the chain of command and we surface them to our direct boss. But in many cases, the next level in the organization isn’t any better able to resolve the problem than the person who found it. This is particularly true for deeply technical resources. Who is in the best position to provide the necessary help or coaching?
5. High agreement of the response. What form should the response take from that resource, and just as importantly, when? The person triggering the andon must know how long they have to wait before they should see a response. This allows them to stay focused on the problem at hand instead of focusing their attention on if and when help will arrive.
The form of the response is vital. Is it coaching, or is it transferring ownership of the problem? If it could be either, how do we determine which form to take? The proper response must be consistent, because if the person triggering the andon does not know what response they will receive, they will resist using andon.
Whether you call it andon or not is irrelevant, but whether or not you have a system that accomplishes the above goals is vital to process stability and improvement.
