For many years now Toyota has used one of the most effective practical problem solving approaches ever developed. There phenomenal development and use has created opportunities for many others to innovate and develop problem solving approaches specific to ones own need. Though many approaches vary in nature the simple concept of an organization using formal methods such as DMAIC, A3 thinking and many other approaches continues to provide stability and positive results for organizations around the world.
Solutions is a 9 step approach that can help individuals and teams completely transform business process.
The format of the Solutions methodology is as follows:
Borrowing from the PDCA cycle Solutions accomplishes its planning in steps 1 through 5 and then moves on to number 6 for the doing. Once doing is complete number 7, observe full-fills the "check" phase of PDCA before coming full circle in steps 8 and 9.
Step 1 - Simplify - Sticking with the common idea that a problem can be classified as either a deviation from a standard, a gap or an unfulfilled customer need or want stage 1 focuses on simplifying the issue through direct observation. While there are many ways to "observe" an issue experiencing it first hand can help make seemingly difficult issues much simpler.
Step 2 - Organize - When a problem is broken down or simplified for a team to solve it often times comes by way of making one "huge" issue into many contributing causes. As the problem you are dealing with becomes simpler there will be a need to analyze various elements of the issue and keep the issues organized.
Step 3 - Lock-In - Now that the initial problem has been simplified and the various causes have been organized and broken down to a manageable level we are ready to lock in our targets and objectives. Here we need to clarify the resources needed and estimated amount of time required to complete the project. After a target has gained consensus with the team and any committees involved it's time to go to "work."
Step 4 - Understand - Root cause is the important idea at this point of the project. Of course one of the best practices when seeking out a root cause is to go to the cause itself and see what is happening. At this point in the problem solving journey be aware that our one issue has most likely multiplied and each of those issues will need root cause analysis performed. There usually is not just one "root cause," but many break offs.
Step 5 - Transform - Having now discovered the root cause of your problems we are ready to transform our problems by creating solutions. It goes without saying but the biggest impact solutions should be top priority.
Step 6 - Implement - Here we begin implementation of the solutions. This is the "do" of our plan, do, check act. As you may understand already pdca is cyclical by nature and with every pass approaches the target. Given that you may not hit your locked in target on the first "go around" be sure that you are aware new problems may show up that were not discovered before. Implementation of solutions like most processes is much more effective and efficient if it is performed in a single piece fashion. Try one solution at a time this will give you a better opportunity to control your solutions and adjust as needed.
Step 7 - Observe - Often times as implementation of solutions takes place there will be some adjustments needed. Step 7 is all about monitoring the outcome of your solutions and making any necessary adjustments or improving on the solutions you have used.
Step 8 - Normalize - As with any other improvement, the standard now changes and the new level of performance must become the measure.
Step 9 - Share - There is a good possibility that your solutions can help others too. Be sure to share with others too.
The fishbone diagram, cause and effect, or ishikawa diagram is one of the most common quality tools used today. Best known by its resemblance to a fish's body the fishbone diagram is used to show the many possible causes for an effect. The tool is used to help coordinating brainstorming in an effort to discover root causes.
The ishikawa diagram was founded in 1968 by Kaoru Ishikawa. Dr. Ishikawa pioneered a major quality movement while working at Kawasaki. One of the fundamental tools he used on many of his projects was the ishikawa diagram. The tool is still used today by many different industries and has proved its worth on many different levels.
One of the most common mistakes made with the Ishikawa diagram is the belief that there are set categories for each of the branches. Although the 6M fishbone and the 8M fishbone are globally recognized as the standard for manufacturing, transactional processes often utilize a 7P fishbone diagram. Ultimately the categories are based on the team's agreement with possible categories that might be related to the problem that is being analyzed.
The fishbone diagram is commonly paired with the 5 why analysis in order to drill down to the root cause. Here is a general process that you can follow to conduct a root cause analysis.
Step 1 - Clearly define your effect or the problem you are trying to solve. Some examples of the effect maybe quality issues that aren't meeting a standard or a particular process that does not meet the required metrics. This can take a bit of practice as often times the initial problem problem may not be revealed right away.
Step 2 - Once you have clearly defined a problem and gained consensus from any team member who might be involved it is now time to start building the "bones" of our fish. These are the categories that we talked about earlier on. As a reminder the 6M or 8M fish bones are widely accepted in manufacturing, the 7P is commonly used in transnational or marketing situations and the final type of ishikawa diagram is the 5S diagram. Please remember though, no fishbone diagram is set in stone so your team should pick the most appropriate categories for the problem you are trying to solve.
Step 3 - The next step is to begin brainstorming with your team. The brainstorming will be focused on identifying possible causes that are associated with the effect. If a cause is identified and the team agrees on the cause, draw a line on the appropriate categories/bone and label the cause. After it has been placed under the appropriate category it will then be time to start "digging."
Step 4 - Though the 5 why's are not exactly a part of the cause and effect diagram, the two work together quite effectively. Once all the possible causes are in the appropriate category begin asking why. A good practice is to ask the individual that identified the problem why did that happen? Then wait for the answer (at the gemba if possible). Once you have received the answer ask why again until you have reached the "root cause."
There are many different ways of using the fishbone diagram but the 4 steps above should help you get started. Please feel free to send us a message if you run into any trouble using the fishbone diagram, we would love to help. Enjoy.
Lean and six sigma strategies use a belt system very similar to many forms of martial arts to designate the experience, skill and contribution to the organizations strategy for each individual. As you may know already there are 5 different belts that a practitioner can obtain.
White Belt - A white belt is generally trained in basic elements of lean and six sigma. They typically are capable of understanding language and activities that are going on around them and often times work with problem-solving teams. Although White belts are not often designated full time to a continuous improvement team they often times are able to assist others who may have little to no exposure in lean or six sigma.
Yellow Belt - A yellow belt is often times a subject matter expert in specific areas of an organization. Generally yellow belts will participate in projects as an assigned team member and are often capable of providing direct assistance with process improvements and data collection.
Green Belt - Green belts are very skilled in terms of improvement projects and analysis. The green belt is often of the same skill set as a black belt but lacks the experience needed to coach, guide, mentor and direct other individuals.
Black Belt - A black belt has mastered almost all aspects of their niche. Black belts often lead in initiatives, problem solving and help support coaching, training and facilitation of other individuals.
Master Black Belt - A master black belt is often referred to as sensei or coach. Often master black belts are full time coaches establishing programs to advance the organizations skill set and supporting as an "internal" consultant on large scaled projects.
One of the first quality tools that I learned how to use was the control chart. At the time my job function consisted mostly of receiving a blueprint and designing the process which would ultimately make what was on the blueprint, while at the same time working up an RFP or and RFQ. Being heavily involved in six sigma at the time I frequently went to the gemba and looked at reports from previous production runs and spoke with the employees who ran the machines. One day while speaking with an employee he mentioned that there was a lot of sanding that needed to be done, but that other times yielded no sanding at all. Upon further review I learned that this sanding had been built into the process in order to solve the over-sized parts. Knowing that this was a form of over-processing I decided to collect some data.
As we gathered the data a control chart was used to monitor the process stability as we produced our outputs or the Y's in our process. Eventually we discovered that this was in fact not a common cause variation but rather a special cause of variation. This of course told us that an adjustment needed to be made.
While the design of the mold is not the topic that we will discuss today, the application of the DMAIC method proved to be beneficial. I believe that the key turning point in the life cycle of the part was directly related to using that control chart.
If you have never used a control chart before the control charts general purpose is to monitor if a process stays within a standard over a defined period of time. The other important lesson that can be learned from a control chart is whether or not the process is in control or not, hens the name "control chart." The control chart shows us an upper limit and a lower limit and a mean or an average line. For example if you went bowling and wanted to monitor where the balls were hitting the average would show a cluster of where the ball hit most. As the name hints control charts show us when a process is no longer in control and an adjustment needs to be made. The key is to make the adjustment in relation to the "root cause" and not the issue that is first seen.
In my circumstance I wanted to see the readings and get started on a solution right away which is why the control chart worked so well for me. Most control charts need somewhere between 12 to 25 readings in order to estimate our limits. While every circumstance is different the control chart can often be used to analyze patterns of a process, control a process that is ongoing and to determine whether or not the process should focus on the problem or change the process entirely.
Here are a few basic steps to follow when using a control chart:
1. First define what it is you are trying to solve.
2. Select a control chart.
3. Measure or gather data that will be used for analyzing (If possible place data into control chart in real time).
4. Review data looking for patterns, "out of control points" and get to the root cause.
5. Correct the root cause.
6. Continue monitoring to ensure control.
To set up your own control chart is reasonably simple. Simply follow these steps or you can download a template by signing up below:
Step 1 - Collect data.
Step 2 - Insert data into template.
Step 3 - Calculate mean (center line)
Step 4 - Calculate the UCL or upper control limit.
Step 5 - Calculate the lower control limit.
Step 6 - Select data and insert chart.
In my circumstance of gathering data, the control chart proved to be a valuable tool and helped me to successfully eliminate some inefficiencies in that particular value stream. The control chart can do the same for you too if the situation is right. Don't forget to grab your free template below.
A young engineer stands at the shop floor. Tasked with finding one example of each of the 8 forms of waste he first stands for nearly an hour. When his supervisor returns and asks, "what did you discover?" He responds "just the normal activities." The supervisor nods his head and returns to his office where he can see the engineer on the floor and the area he is watching. About one hour later the supervisor returns and presents the same question. A bit baffled the engineer replies, "Well I saw that gentleman walking to get a tool he needed, someone from planning came out here to grab a paper they printed out and that gentleman right there finished all ten assemblies on time and placed them in the move area." Again the supervisor nodded his head and returned to his office.
Later that day while that engineer and his supervisor were conducting a hansei (reflection of the event) the two spoke about some various types of waste. As the hansei approached an end the supervisor posed the question "what can you do next time you are out at the Gemba to identify waste a little better?" The young engineer sat for almost 3 minutes appearing to have no response. Determined to let the spirit work its magic the supervisor was silent, never moving his eyes from the engineers face. A short while later the engineer responded, "I need to ASK." With years of experience in supervision the engineers supervisor dug a little deeper, "what do you mean you need to ASK?"
That was when the Supervisor/Sensei found his future leader.
"Well" the engineer started, "You told us in training that we should think in terms of processes. In this case I thought about it and ASKing seems like the best process for me to try." He went on to share his thoughts...
Acknowledge - The engineer shared that he knew what the 8 forms of Muda were and that he knew about there origins. However, he was not yet willing to acknowledge that the waste was right in front of him. After standing at the Gemba the entire day his thoughts moved from not seeing to asking, why am I not seeing? When he did this he realized that he was looking for types of waste but not yet identifying what was value and what was not value. At this point he asked why does that planner have to walk to pick up that paper, he prints those papers all day long? He then began to realize that walking to get paper that you print all day was waste. Next he admitted he thought outside the box and came up with a solution. What he ultimately realized was that often times we acknowledge the lower fruit on the tree but we don't really see the many other types of waste that we do everyday. He closed by sharing "I need to Acknowledge that waste is everywhere and those are opportunities to improve."
Study it out - Over the course of the hansei the engineer shared that acknowledging the waste was not enough. He learned that first we must acknowledge the waste and then study it out with ourselves and with the individuals working in the Gemba. Some methods of studying it out are asking why 5 times or conducting other forms of a root cause analysis.
Kaizen - As the engineer began to finish his story and his initial development of his ASK methodology he shared what the "K" in ask meant. To him the "K" was the most important. Kaizen, probably more appropriately described as the spirit of kaizen. As honest as our friends thoughts were he stated "maybe I don't really know what kaizen is." Of course the supervisor came to his aide and responded, "Kaizen is a journey, It is a spirit that individuals accept as a core belief and a philosophy from within themselves, however that is only part of Kaizen. A lot of the rest of that spirit comes in the doing. He then handed a book titled The Spirit of Kaizen to the engineer. I would like you to read this and summarize the 5 points that Dr. Maurer writes about in the book." Soon after our young friend received the book he said "This is part of Kaizen isn't it?"
In this story we read about a young engineer who in the beginning couldn't quite notice a fundamental aspect of Lean, identifying waste. But by the end of our engineers story he had developed a methodology of his own. While finding items that are non-value, mapping, assessing, analyzing and re-analyzing are contributing factors in a successful journey coaching and reflection land right up at the top with principles and tools. While many of us have years of experience, degrees and millions of belts on our wall, sometimes our greatest development comes to life if we just ask.