Consistency is a problem. Not just in engineering, but universally – finding ways to do something the same way every time is tricky. Trying to get a group to accomplish this feat is even trickier. It takes weeks of practice to get a marching band to look – and sound – as polished as they do, and if a gap in practice happens the whole performance shows it. When you are considering getting a team in production to maintain something or perform something the same way, every time, be aware that you are in for a challenge.
By its nature, enforcement means additional effort to identify and punish folks who do not comply with the improvement.
The book “The 5S’s – Five keys to a Total Quality Environment” by Takashi Osada, written in 1989, is the first and most thorough treatise on 5S. The section on the last S (I call this “Sustain”, Mr. Takashi called this “Discipline” – the Japanese word is “Shitsuke”) he also struggles with how this works well. He points out that habits can be formed, but take conscious effort – whereas falling back on already established habits is automatic and unconscious.
In 5S the practice is intended to improve performance by decreasing waste, improving or maintaining an organized workspace, and using visual tools to get consistent and ever improving results. The first four steps are all about getting to this point – the last step (and its a doozy!) is to find a way to make the improvement “stick”. We are discussing this last step first to look for ways to increase adhesion without increasing burden.
The burden often associated with Sustain is the enforcement. By its nature, enforcement means additional effort to identify and punish folks who do not comply with the improvement. If something needs to be enforced, it is probably because the people who are expected to violate the sustaining of the improvement were not the ones who spoke up and said “This needs to be fixed, and here’s how it should be done.” If the improvement was being made by these people, the ones who know about the problem and know what they want implemented to fix it (the experts) then the policing of this improvement would come automatically and naturally. The experts would have made the improvement and it is in their best interest to keep the improvement in place. If enforcement is needed then the improvement (or it might just be a change, not an improvement) probably came from some outside source (like a manager) with little or no involvement form the crew (the experts).
There are some very common and consistent methods used to implement “Sustain”. Here is a short and incomplete list, but this will give you the general idea:
- Checklists
- Audits
- QA/QC sign off
- Log book
- Video surveillance
- Cross-checking
- Lead inspect
The consistent thing in all these approaches is to add work to verify the improvement is being sustained. This in itself should indicate that sustaining needs to be more a part of the improvement than an ‘add-on’ at the end. This is also the indicator that an improvement expert, such as yourself, can look at a process and consider Sustain as a place where improvement can be made. If the Sustain effort is extraneous to the process it represents opportunity for improvement. And it all starts with how you introduce the improvement.
Let’s talk about the three common ways improvement from 5S is introduced.
1 – Go clean your room.
The lead or the manager sees an opportunity to make the line or the team or the department look and work the way the manager would like. It really doesn’t matter what the change is, it is a perceived observation that the outside individual wishes to change. The manager then leads the team through a structured improvement collecting data and mapping improvements, and in the end the manager gets what they want. The last step is to determine who has the responsibility of making sure the change remains in place, that records are kept or folks sign an affidavit or someone audits the process. Frequently this leads to additional work (aka Muda) to make sure the change is in place. A checklist might be implemented, then someone is assigned to walkthrough the checklist (Muda) and then the checklist is filed (Muda) and occasionally a report on the checklist is called forth (Muda).
Notice how this unfolds. The impetus for the improvement comes not from the team but from an outside entity asking for a change not necessarily related to the work going on. The improvement is driven by an individual who is pushing the responsibility for change and maintenance onto an unwilling group of people. Going in, everyone knows that this improvement will be hard to keep in place because the value was not identified by the team. Once this change is in place it is a fair expectation that the enforcement of the change will be difficult, and employees are warned, written up, reassigned, retrained.
Improvements like this are fodder for auditors. When a procedure (procedure is a document describing a process) says a thing WILL be done or SHALL be recorded, a common tool for controlling implementation by enforcement, the auditor will ask for evidence of how this requirement is being met. Go get the copies of the checklists. pull the reports. Show how the requirement is being met, and what improvement is being implemented to reduce the times the requirement is not met. You can see how this can become a spiral.
Managers that inherit processes with enforced improvements like this have an opportunity to change how the team operates by finding the improvements that hold no intrinsic value to the team (Muda) and working with the team to make improvements with value.
2 – Better than nothing
Improvements that lacked luster, in other words improvements of debatable value, tend to include punitive responses or monitoring requirements. These often do come from the team, but the team was not in concert when the improvement was made. Sometimes this is a result of a team that is too small in number or cross section of responsibility to really represent the whole. The improvement team made changes that were not vetted with the rest of the team, or the attitude was “it’s better than nothing” which translates to “we really aren’t solving the problem.” When leading an improvement Kaizen and walking through the 5S’s if you, as an improvement lead, discover the team is hurtling toward a non-solution that will be dubious in effectiveness and difficult to enforce – stop. Open this up with the improvement team. Discuss your options and change course. Working hard to implement a questionable result is not ideal.
(Author’s note: BTN solutions are frequently the result of a root cause gone wrong. Unless the team has effectively found the root cause, and all agree this is the cause, the solution can easily become a BTN.)
The friction with “BTN” solutions comes from quality. If an improvement was driven by a corrective action (Risk and Opportunity) and the improvement is determined necessary for quality, and the outcome of the improvement was “BTN” and additional work was introduced just to keep track of the use of the change then removing this after the fact is not impossible but damn difficult. Now you are required to demonstrate that a new change is better than the previous improvement. It is now much more than consulting the team to find a better way, now outside agencies (ISO at a minimum, AS, AIAG, or FDA) are interested as well. This can be a case where the improvement introduces more problems instead of reducing them.
3 – Holistic and comprehensive
The third and most effective way to introduce Sustaining in an improvement is to make it part of the effort from the beginning. This requires a few keys:
- The improvement must be addressing an issue of which the team is aware and agree needs to be corrected.
- The team needs to find the solution within the limits of their control (not asking for outside auditing).
- The team needs to be empowered – the change comes from them. They are responsible for its success or failure.
- Prototyping is important. Prototype before release.
Five S has four steps ahead of Sustaining, and each of these steps contributes to the success of the last. Before considering Sort, think about Sustain. If you want to see a bunch of tools put away or not scattered about the line, is this because there are too many tools, or is it because the tools have no home? If you are considering the order of a process, consider who does this process and do they perform the process exactly the same way? If not, is this something that needs to be addressed first?
Take on each tool in the 5S chest in the same way. Consider what change can be made in such a way as to be automagic in nature. A tool that needs to be available might be best attached to the bench with a cable. A shadowboard of tools might be best mounted right on the machine instead of in the closet. A maintenance function might call for the machine to be drained while other operations are happening instead of waiting for the process to end. A checklist might need to accompany each part through a process to be checked by the next operator in the line, rather than a dedicated QC person at the end of the line.
Remember, when introducing an improvement the change needs to be part of the process. Incorporated, woven into the functionality of the thing. Knowing this from the beginning will make the ending much simpler.
sigmakatadojo.com 