Kaizen, the Japanese philosophy of continuous improvement, sounds mysterious, but it need not be. Over time, Kaizen’s small, frequent, permanent actions improve the quality of a system and its products—beyond anything achievable without it.
At Geometrica we live Kaizen. We use a couple of commonly available software tools: a wiki and issue-tracking software. The wiki is a repository for the company's knowledge. The issue-tracking software holds records of our problems and our improvement actions.
Who is to Blame for Problems?
Nonconformities, glitches, waste, defects. They are all problems. Problems are caused by errors that someone committed, right? As humans, we err even if hardly anyone wants to. We can select and train personnel, but somehow that never eliminates all errors. Who is to blame?
That is the wrong question. Workers have good intentions. They want to do good work. The organization must help them do so. It is counterproductive to assign blame for a problem, because then folks hide problems! Instead, we can continuously improve our systems so that human errors do not derail our production or our service. In truth, problems arise only because the system creates them. The worker is not to blame for a flawed system.
To solve a problem, we must identify its root cause and eliminate it. Once we do that, no one doing the job will trigger the problem again. Finding the root cause of a problem requires gathering information. When we identify the root cause and eliminate it, the information we’ve gathered becomes knowledge: organizational knowledge.
When you think of it that way, it’s easy to see that problems are the first step in learning, which makes them valuable. Before they can be solved, they must be captured. And then they should be studied.
Capturing Value
Here is where issue-tracking software helps. We use Bugzilla, but there are many options. The software should be accessible from any computer or mobile device in the organization. When someone encounters a problem, she generates a "problem report" on Bugzilla. The generation of this report is like pulling the "Andon-chord" in the famous Toyota Production System. It immediately alerts a supervisor, manager or process owner. That person, in turn, can direct a correction, stop production and/or raise a corrective action request.
Both steps—capturing the problem in a system and immediately alerting the relevant team—can save reworks and headaches. The sooner the issue is detected, the sooner bad production is prevented and the sooner the system can be improved.
Corrections vs Corrective Actions
A correction repairs or replaces a nonconforming product so it conforms. But a correction does not change the system that produced the nonconforming product. In contrast, that is precisely what a corrective action does: It changes the system so that a nonconforming product cannot be produced again. Corrective action is sometimes called a "countermeasure" or "process improvement."
For example, if a guest in a hotel complains about a noisy air conditioner, the correction is sending a maintenance person to his room to fix the unit—or giving the guest another room. Corrective action is different. It requires digging much deeper. It means investigating why the unit is or became noisy, as well as how other units may become noisy. Perhaps this unit is old, or maybe it wasn't included in the last maintenance cycle. If so, why? Can this happen to other units? Keep digging: Why wasn’t the unit replaced or maintained earlier? Ask “why” to that answer. Until you reach the root cause.
Effective elimination of the root cause, in this example, will result in never again having a guest encounter a noisy air conditioner. Depending on the root cause, the corrective action could involve cleaning the units daily, adjusting the inspection program, improving preventive maintenance or replacing units periodically. The key to these changes is transforming the information into knowledge. System documents must be amended, and the new knowledge must be shared with all involved—through effective communication and training.
Corrective actions are one type of improvement actions. However, not all improvement actions are corrective. For example, improvement actions may arise from sources other than problems: Analysis of results, new technology, new knowledge or "Kaizen events" on a process can produce requests for improvement actions and subsequent implementation. Whatever their source, all improvement actions modify a process or processes. And, for permanence, the knowledge captured in the improvement must be written down.
Improvement actions are Kaizen.
| Kaizen makes these domes possible |
 |
Repository of Knowledge
Geometrica captures and records its knowledge in a wiki. A wiki is a website that anyone in the organization can edit. It keeps a record of all changes, noting the author and time, as well as every older version of each wiki page.
A wiki is an ideal place to keep a company's aggregate knowledge. Standards, procedures, work instructions, forms and records all can be kept safely and accessibly. Most important, these documents are accessible not only for consultation, but also for improvement. We have written previously about how we implemented our QMS on a wiki. This has been running for 10 years very successfully.
The wiki enables Geometrica to store, update and use all the knowledge that we have learned through the years. It is the heart of our management system. And, almost as a bonus, it complies with ISO 9001-2015, as well as other quality and safety standards.
Kaizen - Three Improvement Cycles
Agile improvement
Keeping information in a wiki enables quick implementation of very small changes. We call this "agile improvement." It can occur without a request for improvement action. Every Geometrica employee is empowered to update any wiki document so long as she considers herself qualified to make the change. The update, made directly on the wiki, takes effect immediately.
People who are not familiar with wikis are wary of changing others’ work because they worry they’ll destroy previous information. If this were true, a potential editor would have to be absolutely certain that his version was better than the previous, since a change could risk damaging the document—and the editor's reputation. But a wiki keeps every version of a document in a "document history." Once users gain some familiarity with document histories, they lose their reluctance to contribute.
Furthermore, in Geometrica's wiki, the “owner” of any process affected by agile improvement is notified of any changes immediately, through automatic email. Both the improver and the process owner can decide if other corrective actions should be requested, including communication and training. If so, they may open a Corrective Action Request (CAR). The process owner also reviews, re-approves and re-evaluates any applicable risk from the agile change. But all of this is done extemporaneously—because the organization assumes, as did the improver, that the change is good. This is empowerment, and everyone loves it.
Improvement actions
Formal improvement actions are triggered whenever a problem requires root cause analysis and elimination. This occurs at another level of the issue-tracking software. The process owner leads the investigation, which includes an analysis of the root cause, using 5-whys, Ishikawa, or other means. Interested co-workers can contribute, and, eventually, they identify a root cause, take corrective action and record it.
Issue-tracking software makes it possible to conduct concurrent work on hundreds of improvement actions. Asynchronous collaboration is the norm. Process owners can delegate investigations or actions to team members, and every interested party can contribute.
Improvement projects
If an improvement action requires substantial resources to implement, we open an improvement project. These projects get a budget and a project manager, who coordinates their implementation on the wiki.
Geometrica's Continuous Improvement Procedure
Here is a very condensed version of our continuous improvement procedure.
- Handle non-conformities (NC) and new knowledge. Everyone in the organization is empowered to do this:
- Upon detection of an NC or an opportunity for improvement, log it into the system. The manager is notified automatically.
- Correct and contain all nonconformities immediately.
- In consultation with the manager, evaluate NC for their effect and decide whether to 1) correct and contain only, 2) conduct agile improvement (AI) or 3) initiate a corrective/improvement action request (CAR).
- In case of AI or CAR, the process owner is notified automatically.
- Handle CAR. Upon receiving a CAR, the process owner or a delegate:
- Analyzes root cause using 5-whys or another appropriate method.
- Through on-line discussion, decides on improvement actions.
- Modifies the system documents in the wiki to reflect all changes derived from the improvements, including risk analysis, communication and training.
- Verify effectiveness. The CQO or a delegate verifies the effectiveness of the improvement action.
Conclusion
With the right tools, Kaizen is as practical as it is powerful. A wiki is a great repository of knowledge. Issue-tracking software enables structured problem capture and solution. Methodical use of these two tools makes Kaizen practical and can produce world-class quality in any organization.
More on the use of wikis for quality management
Geometrica pioneered the use of a wiki for quality management and has written the following articles on the subject.
- Using a Wiki to implement a QMS - revisited
- Using a Wiki for Document Control
- Sample QMS Wiki Organization
- What is the Point of a Wiki?
- Practical Kaizen
About the authors:
Francisco (Pancho) Castaño, PE, is CEO of Geometrica, Inc.
Gerardo (Gerry) Mendez, is CFO and CQO of Geometrica, Inc.