Being like water, Lean Six Sigma or Lean and Six Sigma?

In recent years, many companies have developed their own lean version of the TPS, to try to keep competitive and get advantages against competition. Some others have incorporated Six Sigma methodology to their Lean based system. The general idea is that combining two powerful methodologies, or systems into one is better to achieve results even faster than using just one.

I remember that during my years in Ford, Six Sigma was the main methodology used for problem solving, even though  the 8D´s were also used, along with some other statistical tools to help identify were the root cause of the problem was. At the same time Ford used some lean tools to try to build cars more efficiently, such as Andon buttons, kitting, visual management, one piece flow principles, etc. I remember that one of the managers was a big fan of the TPS and the Toyota philosophy. He actually worked for a couple of years in Japan for Mazda, during the period when Ford and Mazda were working closely and Ford had a major participation on Mazda stocks. 

I guess that in this environment Lean and Six Sigma were used successfully, but sometimes felt that Six Sigma was more important when solving a problem. 

Today there are a lot of organisations using Lean Six Sigma, and I have identify common mistakes when combining these two powerful methods or philosophies. 

DMAIC above all.

When solving a problem, I´ve always thought that one should use the tool that fits the problem better. Or solves the problem better should I say. This means that If one is able to get deep knowledge about an issue and therefore develop a simple great solution, should´t matter if a 5 whys was used, or if the answer was obtained through a regression.  Some organizations using Lean Six Sigma, seem really obsessed about using DMAIC methodology. DMAIC as some may know is the Six Sigma cycle to improve processes that already exist, and through the use of this cycle, it is expected that processes experience a dramatic improvement. But I have found this isn`t always practical. As there are  problems, where a well conducted 5 whys or even an 8D´s are better tools according to the nature of the problem. 

But LSS organizations, seem to be inflexible about it and some of them demand that the standard problem solving technique would be DMAIC even if this isn`t practical. Organizations obsessed with a single standard problem solving tool, or template create bureaucracy and excess motion. Wastes that Lean wants to eliminate. The obsession about using an specific tool, makes solving problems a slow process. If to this point you do not agree with me, try conducting a Value Stream Transformation and make it fit into the DMAIC cycle.

Six Sigma can be applied to everything.

Other pitfall i have witnessed is that organizations think that 6 sigma could be applied to everything. This isn't completely wrong, but there are certain environments where 6 sigma could be better applied than others. For example, industries or organisations where variation is high and processes seem to be really complicated. Where there seem to be multiple factors creating an specific issue, could be a good point where 6 sigma could work. But definitely there are other environments where may not work as good. These environments are where no SPC programs, or techniques exist, or where there isn't in place a good system to get reliable information from the process. The question I think, isn't if 6 Sigma can be applied to any situation. Instead we should ask ourselves if 6 sigma should be applied to every single situation. Is there another tool that could be applied in a simpler or more effective way for this specific situation? Flexibility when solving problems or improving processes is the key. It was Bruce Lee who said:

You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.

Every single improvement is a project. 

Some companies using LSS, believe that every single improvement should be a 6 Sigma project. Even when the solution is obvious. Personally I don´t like the word project, because a project requires someone to own it, and also brings the implicit thinking that the project has an owner and he/she should worry about it, not me. Also It implies that a project is something that has a beginning and ending. Lean as most of us know, is a journey that never ends. 

Finally, the last mistake I have seen about the use of 6 Sigma, or obsession with 6 Sigma should I say, is that as 6 Sigma is often used for issues where the answer is evident. 6 sigma works better where the solution is unknown. If you already know the answer, why wasting time justifying your decision using DMAIC, if the solution could be applied now, and not after 2 hours of statistical debate? Solving problems, improving processes is critical. Is the core for great companies. Using the right tool, is critical. Doing it fast, efficient and simple is the key to succeed in the long run. There fore, Become like water, my friends.

Thanks for reading, I´d love to read your thoughts, please leave a comment.

Review of the week: Understanding Variation, The key to managing chaos

As Black Belt, got to admit, that sometimes one tend to think that everything is statistics. That a statistical tool can reveal a relationship between a critical x and the output. That inertia of starting analyzing if a set of data is normal or not, if the cp or cpk is higher than 1.66 or if the gage R&R used to obtained that data is reliable.

Yes, of course, Green or Black Belts have a tendency of jumping right away and perform statistical analysis. This is exactly when this great book make sense. Understanding Variation, The key to managing chaos, isn`t a book about how to use tools to perform fancy analysis. Is about using the right tools to take decisions and to understand what`s going on on our processes. The book is more an eye opener about how to use the basic control charts to understand the variation that affects a process.

It is essential to understand that there are extraordinary events that happen and affect the performance of a process. It is important to note this, in order to decide whether or not to take action to maintain control over a process. This is a key rule to understand and remind when analysing data. The fact that a single point is out of control doesn't mean the process is completely out of control. When a point exhibits an unusual behaviour, we need to ask ourselves if there was an external agent that cause the process to behave this way. In this case, we need to examine this point alone, and not the whole process. The process may be well in control,  but this point may reflect external causes affecting the process. In this case tools to examine special cause variation may help; 8Ds. So, if one single point doesn´t always mean that we need to take action or doesn´t always mean that the process is performing bad, maybe a couple of points would do the trick right? Well, that`s another thing this book explains better. Sometimes, specially when we analyze results, most organizations tend to compare one single month vs the same month from last year, or if we want to analyze further we may add the previous month from this year in the equation. As it is displayed in the book, this isn´t enough either. Many companies today focus on the current month, if we´re lucky, in the current year. Sometimes 6 or 12 data points doesn´t offer the whole information. In other to correctly identify if a process has changed; improved or worsened. The book shows some examples on how, looking just a portion of data, might not provide enough information to take the right decisions; interpreting this data would lie to us. In some cases we need to go back 2 or even three years to clearly see why sometimes the process does achieve the targets and why some other cases do not. This is another key rule. If a process hasn´t been changed for better or worse it is impossible that alone would be able to always meet targets. In this sense, the book will give an specific observation: arbitrary targets are exactly that, arbitrary. And sometimes do not have something to do with the process itself. A great insight in this subject is given in the book.

When a process looks stable, without points behaving in weird ways, it is necessary to analyze the process as a whole. In this case, this is common cause variation. Under this scenario six sigma tools are useful. Either to reduce variation or to make a shift in the process. This is key, because, how many times a manager has requested explanations on a single point? how many times a manager has ignored the sings from a process requesting help? Understanding this two types of variation will help to any person who examines a process to distinguish when action is needed and when isn´t. This book is a great reminder of the basic statistical rules used in SPC to observe a process and how to correctly look at data to take the best decisions the process can tell. The book includes some study cases so the reader is able to understand and see clearly how the traditional method to analyze data reveals a reality completely different when using the right tool and applying the principles of variation.

So, no matter if you are related to SPC or 6 sigma methodologies, or if you just want to understand what`s going on on your process, this book will help you to understand what the process is telling you. In consequence will reveal the voice of the process and will help you to take the most appropriate decision.
Really a great, simple and powerful book for any manager to read.

Thank´s for reading. I`d love to read your thoughts. Please, don't be shy and leave a comment.

Western Obsession for recipes and The five why`s technique.

These days I have thought a lot about how western culture seems to be seeking recipes for success in all areas. In general we all look to follow a method, a scientific way to find solutions, to find success, to achieve what companies such as Toyota has in almost a century of making cars. I guess that`s why people in general is a fan of Checklists. Speaking of which, I will be reviewing The Checklist Manifesto by Dr. Atul Gawande in a future post. But anyway. I believe we like this tools because we believe it is a safe way to go into the wild. To reduce risks, and to maximize the chances of success.

This is no trivial because this obsession I believe, lead Motorola & GE to develop the well know 6 sigma methodology.

I have no evidence to support this last statement but I believe that`s why 6 Sigma was born on this side of the planet, well a little bit up North. But as the next article about Six Sigma in Asia sort of explains, difference between Western and Asian Cultures are noticeable.

Lean on the other hand, comes  (as we all know) from Japan, born within the walls of Toyota and to my eyes, Lean is first about people and principles, and when followed and applied, derive in efficient tools that can be apply to a wide range of situations. I believe that cultural difference were significant and were crucial when the first western learners took these information and export them into the US. Of course language was the greatest barrier to fully understand the principles and tools from Toyota. But I think that it was also the obsession to have a recipe for success, which lead to receive some sort of distorted tools and lack of understanding of principles. Fortunately there are leaders such as Mark Graban, Steven Spear, Karen Martin, John Shook, and many others that have helped to clarify and expand the knowledge across industries.

Why?

All this introduction is to support the following story. I was recently working with a crew making a root cause analysis. Claims have been high for the past weeks and we wanted to know why. It is a requirement that the root cause analysis would be conducted through a Fishbone diagram, a 5 whys technique or both. I prefer other techniques or tools since I believe this could be biased if these tools aren´t supported by evidence. I will explain later why. In this sense, I have always asked myself, how did the creator of the 5 whys defined that 5 were enough? Why asking why and not when, how, who, and others? And why corporations are so emphatic to specifically use 5 whys only? I believe this tool didn´t captured correctly the spirit of improvement, when first brought to America. The key point here is to dive into the issue and asking why,  accompanied by who, when, how, how many etc. Of course, also having facts, and/or data. Understand the problem is the main idea. During the session to capture ideas and define what was the root cause, I didn´t use the 5 whys as the company demands. Instead, requested evidence, data, facts and it was more like a dialogue. A discussion with the team members, to understand the underlying issue causing all of the symptoms. I guess we did a pretty good job, and more important is that people got involved. My personal conclusions are that sometimes you got to use the tool that fits better the problem you`re facing. Or as the Lean practitioners say, according to the problem that you`re trying to solve.

Why do I think these tools could be biased?

Because the way they have been thought. For example, I was taught that a 5 whys technique, you should start asking why is this problem happening? answering because..., and then ask why again on the response given, and answer again, and after asking 5 whys you´ll have the root cause. But if this is based on unverified assumptions our mind can trick us, and lead the solution where our subconscious wants. I´ll give an example:

On the same exercise, one of the team members pointed out the valid fact that we had new personnel and if training was´t complete and properly executed of course quality would decrease. We have an unusual high rotation, influenced by a number of different factors. So we dived on the lack of training of new personnel. Everybody agreed that it would be an issue. But is it an issue today? not sure. One of the supervisors said, "I think it does´t have anything to do. We know our training isn´t the best but is not the main issue right now".

Lets conduct a 5 whys before knowing how the story ends.

Lack of training on new personnel.

Why? Because there isn´t enough time to train. 

Why? Because our supervisors are in a hurry. 

Why? Because they need the job done. 

Why? Because they don´t like to give explanations. 

Why? Because they may be under evaluated. So the problem is originated by the trimestral evaluations right? But wait, what if we dive a little bit?

What if the issue isn´t due to the evaluations?

The issue must be due to the training program right?

Ok, will see what the 5 whys reveal.

Lack of training on new personnel.

Why? Because the training program isn´t properly designed. 

Why? Because it was designed by HR. 

Why? Because no operator or supervisor was involved. 

Why? Because they were busy. Why? because they didn´t have time. 

Why? Because needed to get the jobs done. Wow! this tool is really efficient right?. Both analysis lead to the semestral evaluation. So if we wanted to fix this issue, all we have to do is get rid of the semestral evaluations.

That would have been the answer if we didn´t have evidence. Note that I just conducted this analysis just with assumptions. The action on eliminating the semestral evaluations would have an effect on the organization. No doubt about it, but I`m not sure that would have an impact on claims.

I asked why to the supervisor, and he replied:

"Because the people with higher mistakes, are experienced people and relatively new people, look". And showed his graph were it was clear that something in the process apart from training, was causing the claims. But the  evidence suggested that training, even though, might be susceptible of improvement was´t the primary source of variation creating claims. Everybody agreed and we moved on to the next possible cause.

Thank`s for reading. If you liked this post, please share. If you do not agree with me, please share some knowledge. If you didn´t like it, please tell me why. That´s how we can improve.