The Founder and Experimentation — Jamie Flinchbaugh

For years I’ve heard people complain that process improvement is pie in the sky concepts that don’t work in the real world. First of all, that’s crap. Second of all, process improvement doesn’t work, until it does, and everybody’s looking to do the new-new thing.
Jamie Flinchbaugh’s blog post on “The Founder” is a great take and means that I’ll be watching this movie soon!

bh 2017-06-27

Experimentation Works!

Source: The Founder and Experimentation — Jamie Flinchbaugh

Learning what works and what doesn’t work is driven by experimentation, real-world trials that inform us about cause and effect. How do we improve the ability to experiment? By reducing the cost, the effort, the friction required to test what

Click here for the complete article.

Advertisements

Why 5 Whys?

I’m a big fan of Pete Abilla’s shumla blog.  Way back in the spring of 2007, the title of Pete’s post was “Ask ‘Why’ Five Times About Every Matter”. This is a quote from the visionary Taiichi Ohno. I’ve re-posted below and I hope you get as much out of this as I have.


“Ask ‘Why’ Five Times About Every Matter”

by Pete Abilla on April 16, 2007

Taiichi Ohno is known to have said that “having no problems is the biggest problem of all.”  He viewed problems not as a negative but as a “Kaizen opportunity in disguise.”  Whenever problems arose, he encouraged his staff to investigate the problem at the source and to as “ask ‘why’ five times about every matter (src).”

In a series of events, where people are involved, mistakes happen.  Functional areas such software engineering, industrial engineering or more general areas such as medicine, law, or sociology — these areas are composed by a series of events, involving people, process, machines, environment, and other items.  Undoubtedly, mistakes will happen. What typically happens in response to mistakes is that blame is thrown around, which builds resistance, then communication fails which could lead to project failure. The better approach is to identify the root causes of mistakes and attacking that, instead of what might be perceived as the cause: Perceived causes are most likely symptoms and not the root cause, in which case the problem was never really solved. This, more rigorous and long-lasting, approach to solving problems is called Root Cause Analysis.

Ohno was fond of using the following example to illustrate Root Cause Analysis:

1. “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
2. “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.

There are several tools that can aid in the process of Root Cause Analysis.  Basically, it is a simple approach of asking “why” several times until you arrive at an atomic but actionable item. To visually view the process of the “5-why’s”, a tool called an (Ishikawa Diagram) or a (Cause-and-Effect Diagram) or a (Fishbone Diagram) is often helpful — this tool is referred by either of these.

ishikawa diagram

Main Components of an Ishikawa Diagram

  1. At the head of the Fishbone is the defect or effect, stated in the form of a question.
  2. The major bones are the capstones, or main groupings of causes.
  3. The minor bones are detailed items under each capstone.
  4. There are common capstones, but they may or may not apply to your specific problem. The common ones are:
  • People
  • Equipment
  • Material
  • Information
  • Methods/Procedures
  • Measurement
  • Environment

After completing your Fishbone Diagram excercise as a group, it is helpful to test your logic by working the bones: top-down OR bottom-up like:

this happens because of g; g happens because of f; f happens because of e; e happens because of d; d happens because of c; c happens because of b; b happens because of a.

The excercise above is crucially important — you must test your logic so that it makes pragmatic sense and that the atomic root cause is actionable — that is, you can do something to correct it, reduce it, or eliminate the root cause.

Once you or your team arrive at a root cause for a specific capstone, then you typically “cloud” it to identify it as a root cause. A good rule is that there is typically *NOT* 1 root cause for a problem, but potentially several. Below is a diagram of one fishbone, decomposed:

ishikawa, fishbone, shmula.com

A Few Helpful Hints

  1. It is helpful to pull many people into the construction of these diagrams, as this ensures enough diversity of thought to make sure you get the righ potential root causes.
  2. Keep asking “why” until you arrive at something atomic and actionable.
  3. The purpose of this tool is to answer a question, then brainstorm about how to fix the identified root cause.
  4. Getting more people involved will give them a sense of ownership — and that sense of ownership is very important because now that they feel part of the process, resistance to change will likely be less of a problem.

Real-World Example of Root Cause Analysis

I once helped a large healthcare organization save several million dollars. This organization had the largest call center in California, handling over 8 million calls per year. These were mostly inbound calls, resulting from some internal mistake that caused people to call. My job was to identify the largest opportunity (call type), why are people calling, and eliminating or reducing the root causes.

After pulling log file data and running this enormous data set against my handy-dandy, home-grown regular expression engine (written in Python), we stratified the data into logical stratifications and identified that the largest number of calls into the call center were calls related to a specific product. This discovery naturally begs the question “why” — i.e., this question forms the head of our fishbone: “Why are x% of calls related to x product type?”

We got a cross-functional team together and proceeded with the Ishikawa excercise and identified several root causes. After running the root causes against a prioritization matrix, we went after the low hanging fruit, then the more difficult root causes after that. The result? We demonstrated a quantifiable reduction of inbound calls of this specific type — a reduction of ~8%, which amounted to over $2 Million Dollars in cost savings.

Facts Versus Data

Ohno seems to see a difference in the two.  In his words,

“The root cause of any problem is the key to a lasting solution,” Ohno used to say.  He constantly emphasized the importance of genchi genbutsu, or ‘going to the source,’ and clarifying the problem with one’s own eyes. ”‘Data’ is of course important in manufacturing,” he often remarked, “but I place greatest emphasis on ‘facts.’”

I believe what he means is that data, is a degree removed from the actual place where the phenomena is happening.  He placed a greater value on being where the work is done and where value is added.  Whereas data is often on a computer screen or on paper.  He preferred to be at the source of the phenomena.

More Fish To Go Around

Root Cause Analysis can be used anywhere. In software engineering, it can be used to identify the root causes of bugs in code; in industrial engineering, root cause analysis can be used to identify defects in design; in medicine, root cause analysis can be used to arrive at the reasons for mistakes or lack of patient satisfaction.

Root Cause Analysis is a helpful business tool with application to all areas of business and technology. Eliminating or reducing the root cause is much more effective than fixing a symptom. Involving people in the process will ensure buy-in and the elimination of resistance.

Creating an Improvement Culture

Ohno believed that by empowering each associate to have ownership and improve their work and the Gemba, that is how innovation is achieved and a culture of improvement is created — it is empowering your people to make the right changes using the tools that work — Root Cause Analysis is one of the tools that can help empower your employees and help to create a culture of improvement throughout your enterprise.  One item missed by most people is that Toyota doesn’t just build cars, but it also builds people.  Root Cause Analysis is an effective tool that helps associates feel empowered to make their everyday work better.


Check out Pete’s blog at http://www.shmula.com/

Questions About A3 Problem Solving

By Jon Miller | Post Date: February 25, 2010 12:22 PM on Gemba Panta Rei

These days if you stand next to a Toyota building and listen closely you may hear the sound of many sheets of A3 sized paper being slowly turned into problem solving documents. There are a few big, complex problems that will surely result in improvements, great new processes, and learning for Toyota.

Closer to home, the letter A and the number three can be heard in conversations almost daily in the context of problem solving. It’s a handy shorthand that seems to have stuck. What we hear from time to time in person, on the phone or by e-mail are detailed questions on how A3 problem solving. Here are a few such questions about A3 problems solving we’ve answered for people:

How important is having the right paper size, template or format?

Not very. There is now A4 problem solving at Toyota and each A3/A4 problem solving document should be hand drawn to present the information effectively. Don’t use a single template or it will constrain your thinking.

What is the expectation for taking immediate action on an A3 report to correct a problem or improve an process?

Usually there has been a temporary countermeasure in place long before the A3 in finished, which is due within 24 hours for a quality spill issue. But not all long term countermeasures are implemented automatically.

How are A3 problem solving documents used to build a file for future reference?

They have a “Lessons Learned” database for problem response, engineering and design knowledge and so forth. Having the knowledge base is just half of it, having processes and checks to make sure it is actively used is the important part.

How long does Toyota keep their A3 reports?

Until the next major model change that the problems could be of reference, so max 5 to 6 years.

Is there a time when an A3 should not be used?

Don’t use an A3 if your machine is on fire. If your customer or regulatory agency demands a different reporting format, conform to it. The A3 is the summary of problem solving activity, not the start of it. Go to the actual place, talk to people, see the situation, gather information then work through the PDCA process by writing a good problem statement. If the A3 keeps you from going to gemba, don’t use it.

Questions like these above are evidence that we are asking “What is our process for solving problems and managing through A3 thinking?” We enjoy these questions since they tell us that people are making deeper use of the A3 problem solving process. At the surface level the use of A3 allows people to ask “Have we taken root cause countermeasures?” and “What were the results of countermeasures?” When the Check is done properly, A3s help us ask “What was the process that got us those results?”

http://www.gembapantarei.com/2010/02/questions_about_applied_a3_thinking.html @ Gemba Panta Rei