Making Andon Work: From Tool to Skill to System to Culture
Let’s take a deep dive into building effective help chains in organizations. While andon (or help chain) systems are often associated with manufacturing, I explain how any organization can use these principles to surface and solve problems faster.
Download the PDF “Making Andon Work: From Tool to Skill to System to Culture” White Papers Here: Making Andon Work or view the content below
Making Andon Work: From Tool to Skill to System to Culture
Adopted from an article published by the Lean Management Journal
One of the most commonly given topics for corporate training is problem-solving. There are many tools for problem-solving, and many people have been trained in all of them. There are simple models such as 5 Whys and A3s. There are more complex and deep methods, such as Six Sigma Black Belts. And there are proprietary models such as Kepner-Tregoe and Shainin, with catchy names such as The Red X. There are “old school” models such as Quality Circles. There are many, many more. You may not be surprised to learn that they all generally work.
The following story may feel familiar to you. An executive looks around and sees that the organization is not very effective or consistent with their problem-solving. They then look around and pick their favorite method, and launch training. Some good things happen, and then it starts to fade, usually about the time that the training schedule reaches its natural conclusion. Then a new executive shows and is disappointed in the problem-solving efforts, and the cycle repeats with a different chosen method. This only makes sense if
The method originally trained was simply the wrong choice, but this must be the extreme minority.
What is the root cause of the problem- solving issue? It is everything that surrounds the problem-solving tools. It is the system of problem-solving, and underneath that, it is the culture of problem-solving. A problem-solving tool only works once you decide to use it, and too often, the only systematic trigger for using the tool is the training in which it is delivered.
So having a tool is not nearly enough. Beyond that, you also need the skill with which to solve problems, and it is a skill acquired only through effective practice, not training. Beyond the skill, you need a system to manage your problem-solving efforts and connect them to real work. And finally, you need a culture that enables the right problem-solving behaviors. The bulk of this article will focus on the system, and especially a specific architecture of a system known as Andon.
What is andon?
Andon is lean jargon thrown around yet rarely described in books or training, especially in relation to its importance and impact. The concept is fundamental to managing a stable process. That is a universal objective to any environment, not just in manufacturing but in product development, healthcare, and government.
Andon is just a Japanese 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 and keeping your process stable. This purpose is useful in any process.
You can use whatever name you like. I generally prefer the term help chain over andon, because it is more descriptive, reminds people of the purpose, and, in general, unless you are Japanese, andon falls into the category of jargon which I generally eschew. 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. Many of these tools are implemented in succession until there are so many lists of problems, teams don’t know what to do. There are also many lean
methods to help you solve problems, as mentioned earlier in the article. Andon connects your library of problem surfacing methods to your library of problem-solving methods. It is, to repeat my favorite forged phrase, a chain that brings help or help chain.
How does andon work?
Ignoring the manufacturing artifacts such as cords and lights, how does andon really work? There are 5 core elements in the architecture of building 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 percent behind schedule is a problem, and you don’t believe it is a problem until we’re 20 percent behind, we will have conflict instead of collaboration.
This is where methods such as standard work become useful. Because there is a standard, it is easier to determine what is abnormal, as abnormal conditions force you to deviate from the standard.
I was coaching a team on a problem they were trying to solve. They felt good about their efforts from beginning to end, yet were having difficulty getting their site leader to accept their proposal. After much discussion, I asked two questions. First, does the site leader agree with your problem statement? Second, does the site leader agree that it is a problem that should be solved? The answers were yes, and no. If you can’t even agree that it is a problem, then you will never succeed in agreeing on the solution.
This issue is very important because it resolves a major distraction to problem-solving, and that is, “when do I tell my boss?” When a problem is big enough that you are considering raising it to your boss, or anyone, it is likely also big enough that it should demand 100 percent of your focus. If you are distracted by simultaneously trying to figure out when to sound the alarm, you
are far from 100 percent focused. If you can answer the questions of when to trigger an andon in advance of the problem occurring, you will remove that distraction.
2. Mechanism to detect the problem. This sounds obvious but it often isn’t 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.
Mechanisms 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. This is where methods such as standard work become useful. Because there is a standard, it is easier to determine what is abnormal, as it often forces you to deviate from the standard.
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 requester and responder. A sufficient mechanism could be a daily huddle where issues are raised, an online (or cloud-based) system where issues are logged, or even a code word used in conversation or emails that makes clear that you are triggering the andon. Many organizations simply start to say “I’m pulling the andon,” and that is a clear signal that we should then evoke certain roles and actions.
4. Who will respond? This particular design element of the architecture gets too little thought and attention. Most problems go through the chain of command, and we
surface them to our direct boss. But in some 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. If you manage a laboratory with 5 of the best minds in a diverse set of fields, how on earth can you solve all their technical problems?
The question is, who is in the best position to provide the necessary help or coaching? In one organization, when an area gets into a certain level of trouble, they invoke a help chain by declaring that they are in “task force” mode. Certain operating rules are triggered, and help is provided. An effective response is the involvement of a deeply skilled technical resource. They aren’t assigned to any team in particular on an ongoing basis but are available to coach teams through the problems they have surfaced.
5. High agreement of the response. What form should the response take from that resource, and just as important, when? The person triggering the andon must know how long they must wait. Before they should expect 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. On a Toyota assembly line, you must respond immediately, or at least within the cycle time of one unit. Team Leaders cannot spend time off the floor in meetings, or they would be unable to respond to their team’s needs, and that is one of the highest priorities.
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.
The answer to this may greatly depend on the maturity of your organization. If you have front-line resources with high turnover, little problem-solving skill, or organizational context, then it would be hard to expect them to get coached through solving the problem for themselves. This may result in transference of the problem to the supervisor or manager. You may also transfer ownership to someone because they can resolve the issue quickly with a decision within their rights. For example, you may be behind your milestones on a product development project, and it can be solved simply by approving some outside spending or overtime.
On the other hand, if you never respond with coaching, then you won’t develop the skill the organization needs in order to solve problems. The coaching that occurs as a result of an andon pull is one of the most effective sources of learning, whether it is from a behind-schedule decision or determining an innovative course of action on a technical product design.
Is it a problem or not?
Keep in mind that every problem surfaced from andon triggers does not need to result in a problem-solving effort. Problem-solving effort is an incremental investment in making your system stronger. But the important word is investment. If you are doing problem-solving well, you are likely going deep, and very unlikely able to respond to every single issue with that level of depth. If you treat every issue raised the same, you will likely go shallow on all of them.
So one decision, which is part of the response, is whether or not we should perform problem-solving, or instead, to make a clear distinction, simply apply a Band-Aid to the problem. If the gas gauge on your vehicle shows Empty, you do not need to start a formal problem-solving process with a map of the fuel system. You simply go to the fuel station and refill your tank.
Behaviors, not just system
While this is a topic for an entire article on its own, I’ve already made the point that problem-solving tools are insufficient; the development of an andon system is insufficient as well. You will still need the right behaviors, determined by an underlying culture, to be successful. If people don’t value the transparency of problems, they will resist triggering the help chain. If leaders don’t value people development, they will not coach when the opportunity arises. But how do you build a culture? By practicing. An effective andon system, or help chain, provide the right driver for good practice to build your lean culture.