Steps in the Analyze phase
– Have you ever wondered why problems that were “supposedly solved” a few months ago resurface? Why are we having this problem again? Didn’t Mike and his team do this project a few months back? All too often, problems that were “solved” were not really solved because the true root causes were not properly diagnosed and addressed. That’s why analysis has to be done correctly. So, let’s discuss the Analyze Phase and the steps involved. The Analyze Phase is the third phase of a Six Sigma project. It is the A in DMAIC. The purpose of this phase is to answer the W word, Why. Why is there a problem? We have to determine which Xs are the key factors that impact the problem Y in the equation Y = f(x). There are five steps in the Analyze Phase. Generate a list of potential Xs that impact Y. Organize the potential Xs. Shortlist and select the likely key Xs. Develop a data collection plan for the analysis. And, prove the key Xs in Y = f(X). Let’s take a look at the first step, generating a list of potential Xs that impact Y. This is done using brainstorming to generate a list of potential suspects. In our example of the pizza chain with complaints on pizza crust, what impacts crust? Possible Xs include the flour, the chefs, procedures, tossing technique, oven temperature, baking time, delivery time, and the list goes on. List as many potential Xs as possible. Next, we need to organize the potential Xs. To do this, organize the brainstorm list using a tool such as a cause-effect diagram or fishbone diagram. After the diagram has been completed, shortlist and select the most likely key Xs that are impactful. Use the knowledge, experience, and expertise of those familiar with the problem to identify which potential Xs are the most likely culprits or key X factors. Then develop a data collection plan for the analysis. We need a data collection plan before collecting any data. Why? So that the correct and sufficient amount of data are collected to test the selected Xs. In our pizza crust example, this means that if you suspect oven temperature is a culprit, you may need to run a regression. If you’re not sure what regression is, here’s a quick example. Having good grades in high school is a predictor of success in college. And in the same way, oven temperature can predict a perfect crust versus a burnt one. Therefore, you should plan to collect sufficient data on oven temperature and how well done the crust is. The final step is to prove the key Xs. Inferential statistics and hypothesis testing are used. Conduct the necessary test such as the regression we mentioned to validate the key X factors. At the end of the Analyze Phase, we have a list of proven Xs that were validated by data-driven analysis. In our example, let’s say there are three key X factors. Tossing technique, oven temperature, and baking time were proven to cause variation and problems with our pizza crust. In summary, the focus of the Analyze Phase is on the question Why. Using data-driven analysis, we prove the key Xs that belong in Y = f(X). The power and data-driven rigor of Six Sigma has been put to work. Correctly understanding the Analyze Phase, its purpose, and the steps involved will help you render a correct diagnosis to get to the true root causes or key X factors that impact the problem.
How to use the cause-effect diagram
– People are late for work. Why are they late for work? Well, maybe they missed the bus. Or maybe they were on time for the bus, but there was a huge traffic jam. Or it was because of bad weather. Or they simply woke up late. These are just some possible reasons for being late. And for each of these, there will be possible causes. For example, for the first reason, one could ask, why did you miss the bus? And the list of possible causes goes on and on. Wouldn’t it be nice to have a tool to organize all the possible causes? Well, in this movie, we’ll discuss the tool used to the facilitate brainstorming and organize potential causes or x’s in a six sigma project. This tool is called the Cause-Effect diagram. So, what is a Cause-Effect diagram? A Cause-Effect diagram is simply a diagram to organize the list of potential causes on a particular effect. In the above example, late for work is the effect. The diagram is arranged based on logical relationships. For example, I missed the bus, therefore I am late for work. Why did I miss the bus? A number of possible or potential causes for missing the bus comes to mind. Take our pizza crust problem. What can possibly cause the pizza crust problem? It can be caused by x’s that are related to the oven. Technique, delivery, raw materials, or the pizza chefs. As for the oven, potential x’s, or causes, are temperature and baking time. And for each of them there are many contributing causes. Here is the completed Cause-Effect or CE diagram. This CE diagram takes the form of a tree diagram. I used Excel to create this. This is easy to revise, update and maintain when you’re getting inputs from project team members, any additional subject matter experts, and process personnel in the brainstorming session. The original CE diagram takes the form of a fish. With the fish head, where the effect of pizza crust is. And the tree diagram is replaced by a skeleton of the fish. Showing its primary, secondary, and tertiary bones arranged using a Cause-Effect launcher, like this. It is also known as a Ishikawa Fish Bone diagram, name after it’s inventor Kaoru Ishikawa, of Kawasaki Works in Japan in the late 50’s. He used the fish diagram since Japanese workers can relate to it easily because they are a maritime country. The birthplace of sushi. If this tool was invented in US, it would have been a cow diagram with beef ribs. Anyway, all the branches of bones contain potential causes of theories. Until they are proven with facts and data, they remain just that. The CE diagram should capture all possible causes or x’s. To do that, you want the fish to be a big fish. Not a small fish. The next time of Analyze Phase is to select from the CE diagram the most likely theory’s or x’s to test and validate with data. This selection will be done using the knowledge and experience of the project team and subject matter experts. Developing the Cause-Effect diagram will help you brainstorm and organize potential x’s that impact the y. This is the key step in diagnosing the x’s that belong in y equals f of x.
Introduction to hypothesis testing
– If you’ve ever watched a crime or detective show, you know that there’s usually a crime committed first thing at the start of the show, and what usually follows is that detectives pursue leads to test various theories, and maybe one theory is that the butler committed the crime, another theory is that business partner is a guilty one, and so on. Based on their experience and expertise, the detectives will select the likely theories to pursue. They work on each selected theory by gathering any evidence, facts and data. If there is insufficient evidence to support a theory, they stop pursuing that theory. However, if there is sufficient evidence to support a theory, they will make an arrest. Theories are also called hypotheses. This is an example of theory testing or hypothesis testing. So, what is hypothesis testing? Hypothesis testing is sometimes called the Scientific Method. A theory or hypothesis is proposed, then data or evidence is collected to see if the theory is refuted or supported. If the theory or hypothesis is not supported, then it is considered disproven. If the data supports it, then the theory is validated. In crime mysteries or detective shows, if the evidence showed that the butler was out of town at the time of the crime, then there is no means and no opportunity, then the theory that the butler did it is disproven. In terms of a Six Sigma project, the theories of potential axis are all listed on the cause-effect diagram during the analyze phase. Using the knowledge and experience of the project team and subject matter experts, the likely theories or X’s are selected to be tested with data. Here’s a CE diagram for pizza crust. Let’s just say a number of theories was selected, and one of them is oven temperature. The theory is inconsistent oven temperature causes variation in the quality of pizza crust. To use the justice system or court of law analogy, a person is innocent until proven guilty, and the verdict is either guilty or not guilty, never innocent. Do we have enough evidence to convict oven temperature of causing our pizza crust problem? If there is insufficient evidence, then we have to dismiss the hypothesis, verdict not guilty. However, if we find that there is a lot of variation in oven temperatures among the various (mumbles), and if we can establish a correlation and causation with the variability in pizza crust quality, then we have overwhelming evidence. Since there is overwhelming evidence that we cannot dismiss the hypothesis, verdict guilty. Oven temperature is a proven cause, or key X in our pizza crust problem.
Data collection in the Analyze phase
– If you ever watched or read a tale of Sherlock Holmes, you know that he does not just stumble upon evidence. He has a rigorous plan for gathering information and evidence. He considers how he will collect it, who he will talk to, and where he should go. He has a plan for data collection. So, let’s imagine ourselves as Sherlock Holmes and let’s discuss how to plan for data collection to test hypotheses during the analyze phase of a Six Sigma project. Planning for data collection in the analyze phase starts with the following questions. What is the theory or hypothesis to be tested? For example, you suspect that oven temperatures used are not consistent from store to store, or from chef to chef, even within a same store. What type of hypothesis test should be used? For example, if we want to test for differences among groups, in this case, differences in average oven temperatures between pizza stores or between the chefs in each store, what data is needed? In our example, it would be oven temperature by store, by chef, during peak hours, and off-peak slow hours, and so on. How much data is needed to run the test and draw a valid conclusion? Do we need one data point or 100 data points? From whom, when, and where? From which persons should data be collected? From when to when? Last month, last year? For how long? A day, a week, or a month? From where? Which location? Which database? I recommend that a data collection plan be laid out in a table with columns. The column headings are the questions I listed. Each selected X will be a row entry in that table. The benefit in spending the time and effort to plan for data collection cannot be emphasized enough. Planning for data collection during the analyze phase is important so that the project team knows exactly which hypothesis are to be tested, which data needs to be collected, how much data to collect, from whom, from when to when, and from where, in order to validate the key X’s that belong in Y = F of X. In other words, you validate potential causes or key X’s with facts and data.
How to analyze graphs and charts
– Customers are complaining about pizza crust. The pizza chain is losing revenue. A Six Sigma project team is now in the Analyze phase. Potential X’s were generated and a few X’s were selected to be tested and validated. One potential X is that one or two locations is causing all the crust problems. Another potential X is that the crust problem is caused by variation in oven temperatures. We can use graphs and charts to help validate key X’s during the Analyze phase. For example, let’s address the first potential X mentioned in this analysis. Since the number of crust complaints is Discrete, or Count Data, a bar chart or Pareto chart, is appropriate. But if I want to prioritize the locations based on a number of crust complaints, then the Pareto chart is the most suitable graph. Here is the Pareto chart of pizza crust complaints across locations. Looking at the Pareto chart, we can conclude that, yes, the crust problem is indeed isolated to just one location. We have proven one X. Next, let’s address a second potential X, that the crust problem is caused by variation in oven temperatures. Since we now know that the crust problem is caused by one location, the Six Sigma project team can focus there. To test and validate this potential X, the project team would need to plot the temperatures used for each pizza, by each chef working in this location. Which graph or chart can be used? Since temperature is continuous data, it is appropriate to use histograms, dot plots, or box plots. These graphs display the pattern of variation, showing how spread out the temperatures are, in addition to showing where they are centered. Here is a graph of box plots showing oven temperatures used by each chef at this location. Looking at the graph, it is obvious as to what’s happening. The variation in oven temperatures is caused by two chefs, Chefs B and C. Their oven temperatures are the most inconsistent. We have proven another X. We should follow up with Chefs B and C. This is how you can use graphs and charts to analyze and help prove potential causes and validate key X’s.
How to analyze process maps
– A process map is a graphical representation showing the steps, activities, and decisions involved in a process. This process map was created earlier during the measure phase, so how do you analyze it? Well, let’s talk about it. I have some recommendations and questions you can ask when you analyze a process map. My first recommendation is to identify any bottlenecks. Ask, where are the delays? Where are the holdups? Highlight those steps. Then ask, why are there bottlenecks? Is it because there’s too much work required at those bottleneck steps? Could it be the workload is not balanced among the steps? Perhaps there is not enough people or resources assigned to carry out those steps. Identify any workarounds. Perhaps the official procedure is too unwieldy. People bypass bureaucracy and take shortcuts. Question why are there so many steps. Ideally, the perfect process has only one step. Snap, and it’s done. Mission accomplished. Examine each step and ask, why is it needed? What value does it add? Identify the steps that really add value to the final outcome or end result. These are called Value-Added steps or VA for short. If they don’t add value, highlight them as Non-Value Added steps, or NVA for short. If there are steps that are necessary to get to the Value-Added steps, for example, booting up the computer and logging into the system, classify them as Value-Enabling steps, or VE for short. They do not add value, but at the same time, they are necessary to enable you to get to the Value-Added steps. Zero in on the decision diamonds. These diamonds may be inspections, checks, or evaluation decisions. How often does it fail to meet the decision criteria? If significant, ask why. Look at the rework loops where work has to be sent back to be redone because it failed an inspection. Ask how long are the rework loops? I’ve seen long rework loops in many processes, and the following scenario is a pet peeve of mine. You may have seen this in your own processes. Say we have a 100-step process, and there is an inspection step that takes place in step 99, and if it fails that inspection, the product has to go all the way back to step two to be redone. That’s a rework loop that is 98 steps long. Shorten the rework loop. Why can’t the inspection take place right after step two or better yet, implement self-checking, or even better yet, mistake-proof what happens in step two. So there you have it. Some tips and questions for analyzing process maps.