the Be Cause and other inhibitors to good problem solving

Practical Problem Solving (PPS) is the methodology that Toyota teaches to everyone on how to approach and solve problems.  It follows the PDCA cycle and is very similar to the 6 Sigma Green Belt Training which follows the DMAIC cycle.  I know, I’ve taught both. 

The process is pretty simple and straight forward.  This leads to the question, then why do organizations have so many problems and what’s keeping them from effectively solving their problems?

There are a lot of reasons for this, many of which are the be causes.  First, because there are people involved and people don’t like change.  Especially when a problem is involved with the change, people feel threatened that what they’re doing is wrong and feel a need to defend their position.  Which leads to the next reason.

The history cause, because we’ve always done it that way.  This is where opponents will often try to use lean tools like standard work against you.  They’ll explain that they’re just following the standard for consistency and it’s always been done this way and worked just fine in the past.

Then there’s the Lemming cause, because everyone else is doing it!  There’s safety in numbers!  Yes Mom, we all jumped off the collective bridge and ended up here and you can’t possibly take us all on.

And the whipper snapper cause, because you’re new and don’t know all the reasons we have to do it this way.  Really?  Please explain.  The history lesson is often useful to understand the politics and will also help you understand what temporary detours and work arounds were put in place that became part of the embedded infrastructure.

The charity cause, because we don’t have the money.  It’s easy to throw lots of money at a problem and hope for a solution.  But often, the best solutions are the ones that involve a cross functional team and fosters innovation.

The hearing cause, because no one listens to me.  This is legitimate and a great opportunity to gain an ally by including them as part of the team to study and make changes.

There are lots of causes that inhibit good problem solving.  However, within the PPS model there are only three.  You need to cut through all the other causes to understand the Point of Cause, the Direct Cause and the Root Cause.

The Point of Cause is where you first know you have a problem.  This might be a physical location or a certain screen within a program.  This is the starting point for your problem solving.

As you track back through your issue, you will come to the direct cause.  The direct cause is the thing that is actually causing the problem, like having two programs open at once causes your system to crash.  There is a huge red flag to watch for here, which is the fake solution or workaround.  You will frequently hear at this point, ‘oh yeah, that happens all the time, here’s how you “fix” that’.  You can look for phrases like this and use them to help you identify your direct cause.

Now, you’re finally on your way to finding, the root cause!  Yes the real issue at hand that will address your issue.

So as you go through your problem solving activities, you will have to be courageous and fight through the becauses, be diligent and keep pushing.  You will be rewarded by finally discovering the true causes, Point of Cause, Direct Cause and Root Cause.

Institutionalized Continuous Improvement

One of the hardest things to do as you transform to a lean enterprise is to find the time and resources to do kaizen or continuous improvement activities.  Kaizen events yield great results and are a great learning and transformation tool.  However, getting people to commit to three to five days is difficult.  I often hear the argument that people can’t even take a week’s vacation from their regular responsibilities and now we want them to take five days “off” to fix a problem. 

This is certainly a difficult position for lean enterprises.  So what’s the answer?  One answer is to institutionalize the continuous improvement.  Make the effort part of the process by inserting a Reflection or Lessons Learned activity at key points in the process.  Now I’m not saying to insert this in the middle of a process that has a 55 second cycle time, that would be ridiculous.  However, as part of a development process, monthly planning cycle or hoshin planning it works very well.

Making the reflections activity part of the process is vital for a couple reasons.  First, by making it part of the process, you will capture the resources required for the activity so you can now account for and budget for it.  If you don’t, you will always be fighting to make the time.  Second, you can ensure that it is completed by making part of the gate criteria before moving on to the next project.

The timing associated with the reflection is also critical.  I’ve seen in a lot of organizations that they wait until the end of a project or program to do their reflection exercises.  This might be convenient, buy is ineffective and turns into a check the box exercise.  The issues at the beginning of the project are often forgotten or details aren’t clear anymore.  Organizations do much better if they increase the frequency of the reflections for a couple reasons.  First, all the issues are fresh on their mind, so the quality of information is greatly improved.  Second, by doing the reflections more often, they don’t take as long.  Third, and maybe most importantly, other projects that are month or quarter behind will benefit from the output where it would have been missed had it been delayed till the end of the project.

In order to help institutionalize continuous improvement in your organization:

1.       Institute a reflections or lessons learned activity

2.       Establish a standard format for the activity to enable cross departmental activities

3.       Make it part of the process

4.       Perform reflections on short cycles not waiting till the end of a project or program.

5.       Get the enterprise to perform their own reflections, don’t keep it as a fixed duty of the Lean Org.

Yokoten vs Best Practice

From my previous post, you now have an idea on my position with Lean and Six Sigma.  They fit together well so long as the Six Sigma problem solving rigor is subjugated to the Lean Methodology and Principles.  One place that I’ve seen the two methodologies butt head’s is between Yokoten and Best Practice.

Six Sigma follows the DMAIC (Define, Measure, Analyze, Improve, Control) cycle for problem solving.  During the Analyze phase, teams often look out to the industry to see who is “Best in Class” or has the “Best Practice” for the process the team is improving.  This best practice is then adopted as the “To Be” state.  The improvement phase then focuses on closing the gap between the As Is and To Be.  This approach might work well if you work at the company where the best in class solution is implemented.  If not, the approach usually fails.

It looks at the end result and it ignores the 5 Why’s that led to the solution.  This approach ignores the question: what problem were they trying to fix?  Many companies know they have a broken process.  So instead of figuring out why, they spend time and money on consultants to bring them the best in class solution.  Unfortunately, this solution was designed to fix problems that they might not have. 

“But the best practice was implemented perfectly”, they say.

“The process is world class, so it’s not the process, it must be the incompetent people!”

And so the long line of throwing good people at a bad process begins.  Insanity prevails.

Yokoten offers a bit of sanity to the mix.  Yokoten means, horizontal dissemination of information.  It’s about knowledge sharing, not just solution sharing.  Yokoten in a culture is about spreading wisdom to other areas of a business that might do similar processes and letting them know what problems you had and what you did about it.  It can manifest itself as a Lessons Learned activity which then updates the standard work for the next go around or highlights improvements for other teams not to that point yet.

This is not to say that yokoten zealots ignore best practices.  On the contrary, they use them to speed the problem solving process.  I experienced a good example of yokoten recently while working with a couple Toyota plants.  Toyota brings me in occasionally to work on certain problems.  I always enjoy going back to the mother ship for a little re-indoctrination.  I did some work at the Indiana plant which they were pleased with.  Then a few months later I got a call from the Lexus plant in Canada.  They wanted to bring me in for a few days to discuss an issue they had.

When I arrived they said that the solution we came up with for the Indiana plant was highlighted as a “best practice” within the network of Toyota plants.  So that was the reason for bringing me in.  However, their first question was: ‘what were the problems they were trying to solve?’  They listed these on a board.  They then pulled out their notes and said: ‘here are our problems and what we’re trying to solve.’  They then listed them next to the other list.  We matched up the common problems and then highlighted the gaps.  We then went on to come up with a solution that addressed all their issues.

They did two things here.  First, they specifically understood their problem.  They didn’t jump straight to the best practice solution.  They took the time to understand all the variables impacting them.  Second, they didn’t adopt the best in class, best practice blindly.  They understand that the best practice is the best practice given a set of circumstances and doesn’t mean in every circumstance.  As a result, they ended up with a best practice for them.

When you approach problem solving, you should absolutely consider best practices and leverage them.  Look at what others have done but also look at why they did it.  What problem were they trying to solve?  Make sure you understand the problem you’re trying to solve and don’t short cut the process.  Utilize best practices as a starting point, not a goal!  If you’re always trying to implement the best in class process, you never will be.

 

Lean vs Six Sigma

Over the past 10 – 15 years there’s been sort of a VHS vs Beta battle going on between Lean and Six Sigma.  I’ve been in the fortunate position to evaluate the battle from both sides.  I learned lean from working at Toyota’s premier plant in Georgetown, KY producing Camry’s, Avalon’s and Sienna’s at the time.  Then later, I earned my Six Sigma black belt while working at Ford’s iconic heavy truck plant (KTP) in Louisville, KY producing the F-250 to 550 and the Excursion.

I’ve always viewed the two methodologies as compatible in that structured problem solving as part of kaizen, is a key component within a lean enterprise.  Some proponents of Six Sigma will argue that lean is too feel good, loosey goosey and lacks discipline.  On the contrary, Toyota might not wave the wave the scientific method flag but the majority of statistical methods taught during my Six Sigma training were used daily in the trenches at Toyota.

At one point, I was asked to teach a Green Belt class.  I received the training material and started to evaluate them.  Much to my surprise, the material was a close match to the PPS (Practical Problem Solving) course that I used to teach at Toyota.  The biggest difference was that Toyota removed a lot of the math jargon which they knew might intimidate people and focused on the process of using the tool, the data and what the output meant.  So if you are trying to impress someone with your high math skills, use a Cause and Effect Diagram or if you want to understand the potential relationships between your problem and its variables use a Fishbone Diagram.

The simplification of terminology alone lowers the water level and enables so many more on the team to be involved.  With more involved in taking ownership of their problems and solving them, you get better solutions, more buy-in and long term sustainability.  If you want an elitist class structure of experts, then by all means, keep talking about regression analysis and R-squared values.  Or you can get everyone involved and talk about what has the greatest impact on the problem and what should be fixed first.

Currently, movements have resulted in a convergence of Lean and Six Sigma.  Typically, these movements have Lean as the over arching cultural methodology with the discipline of Six Sigma as the backbone of the problem solving system.  I think this is a good approach so long as the roll out doesn’t result in a class system.

 

the Porridge Principle

The goal of a Lean enterprise is to reduce lead times through the elimination of waste. Or to put it slightly different, a Lean enterprise focuses on efficiently delivering value to the customer. Both of these statements are short and simple and focus on the need to eliminate waste from any and all systems and processes.

Waste is anything that the customer does not value. And in this case, we are specifically referring to the external paying customer, as they are the ones who keep us in business. There are eight generally agreed upon categories of waste:

1. Overproduction

2. Defects

3. Transportation

4. Waiting

5. Inventory

6. Motion

7. Over Processing

8. Untapped Involvement

These eight categories of waste help us to systematically evaluate the value stream and to look for opportunities to improve processes. They also relate back to the customer because it is the customer who defines what is valuable. Once they have defined the value, everything else is considered waste and must be reduced and ultimately eliminated.

Value to the customer is an interesting topic on which many volumes have been written. Value is defined as what the customer is willing to pay for. However, what they are willing to pay for has some constraints around it, commonly known as the 5R’s. The customer wants the:

1. Right part (or service)

2. At the Right Quality

3. In the Right Quantity

4. At the Right Time

5. At the Right Price

If all of these conditions are met, the customer will find value in what the enterprise has provided. In some cases, the enterprise can exceed the customer’s expectations around one of the 5R’s and the customer is ecstatic. This is often referred to as the WOW factor. It is also great when the enterprise can do this without incurring additional cost.

Processing is the act of converting raw materials or data into something the customer values. Therefore, by definition, processing contains the actions that customers are willing to pay for. Everyone is familiar with the childhood story of Goldie Locks and the Three Bears. Goldie Locks was wandering through the woods when she came upon the empty home of the Three Bears. Goldie Locks proceeded to go inside and to make herself comfortable by sitting in their chairs, tasting their food and sleeping in their beds. With everything of the Bears’ that she tried, she discovered that one was too much, one was not enough and one was just right. This same idea applies to the wastes associated with processing. In addition to over processing, you can also have under processing which is potentially worse than its more common counterpart.

Over processing is when the enterprise exceeds the customer’s requirement around one of the 5R’s and the customer doesn’t notice or care. One example would be heated cup holders in the back seat of a sports coupe – the only reason the vehicle has a back seat is basically for insurance purposes. Another example is software that has additional unadvertised features, like hot keys, that the customer doesn’t even know about.

Over processing a product or service costs money to develop, design, source, build, document and maintain the unnecessary feature, and the enterprise doesn’t get anything back for its investment. The time and money that was wasted in over processing could have been used towards other value added efforts.

Under processing, on the other hand, is when the enterprise has failed to hit the 5R’s. Under processing is easy to say but hard to identify and quantify. It is not always obvious that a company is not meeting their customers’ expectations; the customer just doesn’t come back.

Over processing has direct costs that are easily associated with it, like material and labor costs. Additionally, it’s easier to ask “Are we doing too much rather than not enough?” when an enterprise is being directed to reduce cost. Furthermore, under processing can actually appear to be a cost savings due to avoided direct costs. If the process is delivering quickly and running smoothly it must be okay? Right?

In a recent discussion with an executive from a manufacturing company who supplies components for precision applications within the defense and high tech industries -- the executive brought up issues they had with a recent outsourcing project. Many of the issues boiled down to a lack of due diligence prior to making decisions. In other words, the data was under processed. They made decisions quickly and the project moved along efficiently, until the product showed up and it did not meet the company’s expectations and required significant rework. In this case, the under processing had an obvious impact in time and money. In other cases, the customer might just keep you as a tier two supplier and never throw any new business your way. For this enterprise, they are now working to define and standardize on more robust outsourcing process.

While analyzing processes, facilitators and participants are trained to ask themselves where are we doing too much and what should we stop doing that the customer does not care about? In reality, they are only asking half the question. They should also be asking if we are doing enough and what are the gaps we have in maximizing our value to our customers? This highlights the need to communicate with the customer and truly understand what value the enterprise provides to them.

Hitting the 5R’s on the mark will maximize the enterprise’s value to the customer. In trying to address over processing you must be careful to not swing the pendulum to the other extreme and create a situation of under processing. The enterprise must understand what value they provide to their customer and identify the gaps of excess or inadequacy. There is a sweet spot to processing and hitting the balance of the 5R’s. As you look for opportunities to eliminate waste, remember Processing and the Porridge Principle. Not too much, not too little, Just Right!

Chaku Chaku doesn't apply here

It’s probably because of my tool and die background, but Chaku Chaku and SMED are a couple of my favorite lean concepts. In the manufacturing environment they often involve making some tool or fixture and any excuse to fire up the welder and make chips on the mill is a good thing.

Chaku chaku means load load and it is often applied when creating cellular arrangements of work centers. Typically, the orientation of a part is critical during the setup for an operation. The part needs to face a certain way, be rotated against a stop and be fully seated and clamped. Whatever those things are, there are usually several steps and they require some degree of dexterity and thought (more on this and SMED in a later post). However, the removal of the part does not require any huge cognitive power or dexterity. Therefore, identify the simple tasks, like unloading a machine, that can be quickly, cheaply and reliably automated. Then leave the higher level thinking to the workers and set up the system so that more of their time is spent actually thinking.

Once the easy stuff, unloading, is automated, the team member can load several machines instead of just loading and unloading one machine. Now they are providing more value to the company, doing more interesting work, able to spend more time inspecting and they get a better understanding of the value stream since they are involved in multiple steps within the process. I always picture it like this:

Load = Duck and Unload = Goose. When chaku chaku is applied, you get Duck, Duck, Duck, Duck, but no Goose (which is usually a good thing!)

‘Yeah, but I don’t make widgets and chaku chaku just sounds funny so I know it doesn’t apply here.’

Okay, so let’s think about what chaku chaku is trying to do. First, it’s separating tasks into the categories of high skill and low skill. Then it is removing the burden of the low skill tasks from the team member.

“Do you do any simple, mind numbing, repetitive tasks?” So eliminate them! There should have been a huge red flag going up as you asked yourself, ‘so you think we should automate all those tasks? Isn’t that just automating waste, which hides it?’ Yes it is, and I’m glad you’ve been paying attention and no that’s not what I was getting at.

Optimize your process by eliminating waste. Then when you’re left with value added and necessary non value added tasks, figure out which one’s truly require your intelligence to perform. This is often the decisions and the analysis. Identify and isolate these items. Look at the other items and see if there are easy ways to standardize and automate them.

The automation can be a simple macro that pulls data from multiple spreadsheets giving you more time to analyze the data. This can be applied to when you log onto your companies online HR vacation system or IT help desk ticket system. Chances are, you’re already logged into the system, so why do you have to fill out who you are, your id number, cost center and mother’s maiden name? Why can’t this information be auto filled and give employees more time to explain what they want? I’ve seen programmers apply chaku chaku by automating their tests, giving them more time for crazy stuff like coding and use case development.

Chaku chaku enables the knowledge worker to focus on, well knowledge. Yea, it’s a funny name but the concept is powerful and can greatly improve the productivity, engagement and satisfaction of your team.

Andons don't apply here

Anyone who's part of a lean transformation in manufacturing will be familiar with andon systems. Andon systems are visual control systems that enable team members to signal for help or assistance without leaving their station. This keeps the value stream intact and brings support staff to them. Andon systems are usually made up of lights, sounds, displays and other technology to highlight an issue at the line. Let me now shamelessly plug Industrial Andons, www.IndustrialAndons.com, the largest manufacturer of wireless andon systems in the world!

Often times, off the factory floor I hear remarks like, 'andons don't apply to us, I guess you think we should have stack lights on our cubicles'. As much as I might like to sell light stacks to cube farms, no that's not what I'm saying.

The important point is not to focus on the tool but to understand the question that the tool was created to answer. The question andons answers is: How can we enable our team members to get assistance without disrupting their work? In other words, what is our escalation plan?

When I first worked with my Japaneese sensei, he would drive me nuts by saying things like, 'I see no andon here' while standing in the middle of the procurement department. It took me a while to realize what he was really saying. He was referring to the simple tool as a way to get me to think about the question that needed answered. It's sort of like Yoda speak from Star Wars, 'hmmm, only once you have andon will your problem of escalation be no more'.

So, the philosophy of an andon system, or escalation process is universally important. The manifestation of the solution will depend on the application. As you walk through any part of an organization, just ask yourself, is there is a standardized process for someone to signal that they have a problem and how it is addressed?

And then try to work in Yoda quote just for good measure.

Doesn't apply here

I don't know how many companies or departments within companies that I work with where their first reaction to lean is, "that doesn't apply here".

I guess that's a natural response to anything new or unknown. Additionally, most lean activities start in manufacturing areas and the activities that occur there appear very different than the activities performed by knowledge workers.

I have found that there is a need to translate the language and conversation to an area of common understanding. This helps them to feel less threatened and more open to the ideas.

I will first go through and compare traditional lean manufacturing activities and map them to the world of the knowledge worker.

After that I will hopefully have some more research done on another realm of lean off the factory floor that I can share.