The misunderstanding of andon [Lessons from the Road]
I was recently having a lot of conversations about the use of andon, how and why it works, and how to tailor the concept to a specific application. They asked if I had an article or column on the topic, and was quite surprised that I had never taken the opportunity to write more on the subject. It is one of my favorite tools, because of the human connections that it supports. And so I took the opportunity with my IndustryWeek Lessons from the Road column to write more about andon.
Here is an excerpt, as I outline the elements of building your andon system:
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.
You can read the entire column here.