Problem Solving Methodology Help - Shainin/Red X

[ByronD]

I have a two-part question. First, I would like some opinions regarding the relative ease of implementing the Shainin System (SS) in an organization where formal problem solving is relatively new – this in the context of A3 and Six Sigma. Also, does SS deal with the bigger picture of managing/prioritization of projects as does Six Sigma, or is it simply a method applied to a problem.

FYI - We have people within the company trained in Six Sigma Methodology, but are without experience, formality (dashboards), dedicated BB resources, or infrastructure for directing/managing/ formal Six Sigma projects – we do use some of the tools however. On the other end of the complexity scale, we have begun using A3 problem solving, using a team approach. I am happy with the results so far for “mid-level” complexity problems. However some our more involved problems we are now asked to work on have to do with improving the RTY on key value streams – these consist of 20+ process steps. Such a project likely has many facets and consequently seems too unwieldy for an A3. If you feel strongly otherwise, please discuss.

The second part of my question actually hinges on the first, but is a request for recommendations for a book to learn about SS. Has anyone reviewed both “World Class Quality” by Bhote and Statistical Engineering by Steiner and Mackay, or have other recommendations?

Thank you.

 

[Miner]

The Shainin System is a good approach for problem solving. It is very difficult to find information about it without actually taking their classes, but the book Statistical Engineering: An Algorithm for Reducing Variation by Stefan H. Steiner is an excellent resource. While different enough to avoid copyright issues, it covers essentially the same approach.

SS and SE will handle a wide range of problems of equal to greater complexity than A3, but not quite as complex as Six Sigma. It does have a process, but does not have the superstructure that Six Sigma has. It is more suited to special cause problems, or recurring problems, while Six Sigma is more suited for Common Cause problems.

I have found Bhote to be a little dogmatic about Taguchi Methods. While good, they are not quite the panacea that Bhote makes out.

 

[ByronD]

SS and SE will handle a wide range of problems of equal to greater complexity than A3, but not quite as complex as Six Sigma. It does have a process, but does not have the superstructure that Six Sigma has. It is more suited to special cause problems, or recurring problems, while Six Sigma is more suited for Common Cause problems.

I have found Bhote to be a little dogmatic about Taguchi Methods. While good, they are not quite the panacea that Bhote makes out.

Thank you Miner. Your comments are very helpful.

 

[Bev D]

I agree that Statistical engineering is a much better book if you can only afford one.

I strongly disagree with Miner (repsectfully) that statitistical engineering is not for common cause problems - in my experience it is excellent for solving complex common cause problems...I do it all of the time. (for what it's worth my view is that special cause and common case are operational definitions that only have meaning in the context statistical process control. All results have a physical cause and it can be determined)

I view the Shainin System as a special subset of tools and strategy that falls under the classification of effect to cause (starting at the Problem side and working back to find the causal mechanism; Kepner-Tregoe, SE and Why-Why are also in this category) where most common approaches (fishbone diagramming and brainstorming) are in the classification of cause to effect.

 

[ByronD]

I agree that Statistical engineering is a much better book if you can only afford one..

Hi Bev,

I was hoping you would chime in. I did see your post in 2007?? recommending both of these books; you had "World Class Quality" in the "Also, if you can afford.." section of your post so I thought your recommendation would be the SE book.

BTW (if anyone is interested – and I hope this is OK to say) the SE book is on sale at ASQ for $30. I could not pass on this price.

I strongly disagree with Miner (repsectfully) that statitistical engineering is not for common cause problems - in my experience it is excellent for solving complex common cause problems...I do it all of the time. (for what it's worth my view is that special cause and common case are operational definitions that only have meaning in the context statistical process control. All results have a physical cause and it can be determined)

Good point. Don't want to be a catalyst for a debate, but that makes perfect sense to me. Variation detection - whether special or common - should be measured (detected) and reduced preferentially by magnitude. It may be factual - not sure - that special cause may be easier (cheaper/quicker) to eradicate, but focus should be directed to the larger contributors and I think Shainin’s method would not discriminate.

I view the Shainin System as a special subset of tools and strategy that falls under the classification of effect to cause (starting at the Problem side and working back to find the causal mechanism; Kepner-Tregoe, SE and Why-Why are also in this category) where most common approaches (fishbone diagramming and brainstorming) are in the classification of cause to effect.

I don’t wish to get off topic, but can you differentiate between effect to cause vs. cause to effect? I fear I may be missing something important here… a fishbone has a single effect and the thought process to determine what “factors” may be a causal subset leading to this effect? While effect to cause is the opposite??? There may be one or several effects (defects for instance) for which a common cause is sought?

 

[Bev D]

It may be factual - not sure - that special cause may be easier (cheaper/quicker) to eradicate

Actually I've found this to be a myth...The real drivers of how easy or difficult it is to determine the causal mechanism lies in 3 factors:

• how deeply the cause is buried in the system
• the occurence rate (to an extent the if the problem characteristic can be measured with continuous data can be faster than when we can only count the nubmer of good/bad events
• the ability to actually measure or see the Problem characteristic and it's system of inputs.

I've expereinced enough assignable causes that took months to determine and enough common cause chronic long term problems that fell apart within hours when I looked at it properly. Of course teh opposite is also true so I've found that there is no 'ease' realted to the type of 'cause' as defined by it's temporal behavior:

For Assignable causes to be 'easy' to find we must ask the question "what changed". A quick solution to this might be to look at records, but this would require that we knew about the causal factor, measured it and recorded it all along. We're not always that lucky. Another method might be to compare parts before and after the change, a post hoc test if you will. But (for both of these approaches) we are stuck with the first factor above. Often we find the immediate factor (first level "Why") but the actionable cause lies much deeper in the system - even into our supply chain.

...can you differentiate between effect to cause vs. cause to effect? I fear I may be missing something important here… a fishbone has a single effect and the thought process to determine what “factors” may be a causal subset leading to this effect? While effect to cause is the opposite??? There may be one or several effects (defects for instance) for which a common cause is sought

more on this later...

 

[Bev D]

...can you differentiate between effect to cause vs. cause to effect? I fear I may be missing something important here… a fishbone has a single effect and the thought process to determine what “factors” may be a causal subset leading to this effect? While effect to cause is the opposite??? There may be one or several effects (defects for instance) for which a common cause is sought?[/FONT][/COLOR]

The phrases “effect to cause” and “cause to effect” refer to two different strategies for determining the causal mechanism.

Cause to effect is the more commonly known and utilized approach. It starts with theories, guessing or ‘voting’ about which ‘casual factor’ is creating the effect (or Problem). This approach is the one that is associated with the fishbone diagram, use of FMEA, etc. Trying various ‘solutions’ to see if they ‘fix’ the Problem is also a form of this method.

Effect to cause is the less commonly known approach and begins wit the effect and works ‘backwards’ to determine the cause. (The Shainin tools and methods fall under this approach as do the 5-Why and Kepner Tregoe approaches. Statistical Engineering is another example)

A brief comparison
Cause to Effect:

• Conjecture, potential causes are listed based on: Brainstorming → fishbone diagrams → multi-voting
• Proves a cause creates an effect
• Swing for the fence
• Divergent – random searches
• One factor testing or fractional factorials
• Requires us to be able to 'know' what the input factors are
• Focus is on how the system works

Effect to Cause:

• potential causes are evidenced based
• Disproves potential causes
• Considers all potential causes and tests all of them simultaneously
• Iterative approach
• Convergent
• Quick tight experiments
• Requires us to understand the function of the system
• Focus is on how the system fails

I have found the Effect to cause approach to be faster and much more effective in determining the true causal mechanism than the Cause to Effect approach.

Some references:
Steiner, Stefan H., MacKay, R. Jock, “Strategies for Variability Reduction”, Quality Engineering, Volume 10, Issue 1, September 1997 , pp 125-136
Kavuri, Surya N., Rengaswamy, Raghunathan, Venkatasubramanian, Venkat, “A Review of Process Fault Detection and Diagnosis Part II: Qualitative Models and Search Strategies”, Computers and Chemical Engineering, 27 (2003), pp. 313-326
Dale, H. C. A., “Fault Finding in Electronic Equipment”, Ergonomics, pp. 356-383, 1957
Allen, John R., “Three Good Questions (and One Not So Good), The New Science of Fixing Things, 2006, www.tnsft.com
Kida, Thomas, Don’t Believe Everything You Think: The 6 Basic Mistakes We Make in Thinking, Promethius Books, 2006
Seder, Leonard, “The Technique of Experimenting in the Factory”, Industrial Quality Control, March 1948
Gano, Dean, Apollo Root Cause Analysis - A New Way Of Thinking, Apollonian Publications, Distributed by BookMasters, Inc., 1999
Allen, John R., Hartshorne, David J., “The Art and Science of Fixing Things”, 2006, www.tnsft.com

 

[ByronD]

Thanks for the information Bev.

I have read most of the Statistical Engineering book and now have a much clearer idea of this approach to problem identification and problem solving.

Thank you for the explanation and references. I am interested in pursuing training for myself and other engineering personnel. If you have any recommendations I would appreciate hearing them.

Thanks so much!

 

[Bev D]

...I am interested in pursuing training for myself and other engineering personnel. If you have any recommendations I would appreciate hearing them

Well, I mostly trained myself. I did take an 'open to the public' course from Shainin in the early 90s, but I mostly took away a knowledge of some of the experimental designs they taught. They were all variations of design structures taught by others and I ended up researching them at their source.

The critical element of the cause to effect approach is the strategy one uses for each split level. The articles from John Allen & David Hartshorne do a decent job of explaining this. However I've found the following to be extremely helpful when teaching the techniques to others:

the 3 possible splits are

• Temporal - Within piece, piece to piece, lot to lot, vendor lot to lot, month to month, season to season etc.
  - Product use: during use, use to use
  - Operator to operator
  - Within a process; step to step or operation to operation.
  
  
• Structural
  - Location (Within piece, cavity to cavity, station to station, line to line, plant to plant, region to region)
  - Components (Sub-assemblies, Component parts, Raw materials, Process step (assembly or process methods))
  - Specific features, dimensions and/or properties
  
• Functional

- Failure modes
- Use cases, (User, Product, Consumables, supplies, Environment, Use conditions
- Specific functions or energy transfer paths

Each level will usually have a different split approach.

 

[bobdoering]

Actually I've found this to be a myth...The real drivers of how easy or difficult it is to determine the causal mechanism lies in 3 factors:

• how deeply the cause is buried in the system
• the occurrence rate (to an extent the if the problem characteristic can be measured with continuous data can be faster than when we can only count the number of good/bad events
• the ability to actually measure or see the Problem characteristic and it's system of inputs.

I agree! You may be able to identify common causes easier, because they are common, and therefore there all of the time. Special causes may be more difficult to detect, as they may be very intermittent. But, eliminating either can be anywhere on the continuum of easy to impossible.

For example, in machining, tool wear is a common cause - it affects every part (how much more common can you be than that?), and eliminating tool wear has some serious physical limitations...ignoring it is bad enough.

Startup and warm-up are special causes, and you may be able to identify their effect, but, again, eliminating startup/warm-up is also pretty darn difficult. In fact, in short run applications, the whole run may fall into the effect of the special cause startup/warm-up and never reach steady state.

Another tough example of a special cause is tool breakage. You can minimize it with correct SPC methods (as in not x-bar/R), but the tool and material variation is such that eliminating it is also pretty darn tough.