You may have heard about Pavlo and his dogs. But who is this Andon character, you may ask?
Well, at least the Andon I will discuss is not a person. In this case I’m talking about the Andon system, a principal part of the Toyota Production System. The Andon system is a system to notify leaders, maintenance, and co-workers of a quality or process problems. The notification is usually be activated manually using a pull-cord or button, or may be activated automatically. Andon is a key part of the “Stop the Line” principle of stopping when you discover a problem that need to be fixed.
The idea of the “Stop the Line” principle is to stop and fix a quality or process problem. The great benefit of “Stopping the Line” is that information about the context and situation of when the problem occurred is not lost. You don’t have to spend as much time recording the information and you don’t remember what happened at a later stage. Another great benefit is that defects are not propagated to the following steps that could then potentially cause even more need for rework.
I have used different kinds of Andon systems with software development teams. The most common I have used is the Continuous Integration (CI) Server. The simplest form has been a server that monitors the code repository for check-ins. When code is checked-in it compiles the code. If there is any problems the CI-server will pull the Andon cord and notify the team that there is a problem. When the team gets the notification of a problem the team should focus on fixing the problem as soon as possible.
The behavior pattern when want to create with the team is:
- Notification of problem
- Stop the Line
- Initiate Problem Solving for the immediate problem
- Agree on how to fix the immediate problem
- Fix the immediate problem
- Initiate Problem Solving for eliminating root cause of the systemic problem
- Implement countermeasure for the systemic problem
- Closely observe if systemic problem is solved and no unwanted side effects has been introduced
Step 6-8 is often done later to reduce unwanted variation in the normal flow of work.
In Lean we look at problem in a slightly different way than many others:
“NO PROBLEM” = A PROBLEM
Here is an interesting excerpt from Mike Rothers book Toyota Kata : Managing People for Improvement, Adaptiveness and Superior Results that illustrate that point.
According to my source, what actually happened when the number of andon pulls dropped from 1,000 to 700 per shift is that the Toyota plant’s president called an all-employee meeting and said, “The drop in andon pulls can only mean two things. One is that we are having problems but you are not calling for help. I want to remind you of your responsibility to pull the andon cord for every problem. The other possibility is that we are actually experiencing fewer problems. But there is still waste in our system and we are staffed to handle 1,000 pulls per shift. So I am asking group leaders to monitor the situation and reduce inventory buffers where necessary so we can get back to 1,000 andon pulls per shift.”
Just like Pavlo’s dogs that start salivating for food when the bell rings we want people to jump into Problem Solving when the Andon notifies us of a problem.
This is my Lean/Agile Advent Calendar. I will publish a short post on a Lean/Agile topic every day up until Christmas. I will based each days topic on what is behind the door in the LEGO® City Advent Calendar. So be sure to check back every day!
DISCLAIMER: LEGO® is a trademark of the LEGO Group, which does not sponsor, authorize or endorse this post and blog in any way.