Problem Solving Methodology Help - Shainin/Red X

B

ByronD

#1
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.
 
Elsmar Forum Sponsor

Miner

Forum Moderator
Staff member
Admin
#2
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.
 
B

ByronD

#3
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

Heretical Statistician
Staff member
Super Moderator
#4
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.
 
B

ByronD

#5
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

Heretical Statistician
Staff member
Super Moderator
#6
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...
 
Last edited:

Bev D

Heretical Statistician
Staff member
Super Moderator
#7
...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
 
B

ByronD

#8
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!:thanx:
 

Bev D

Heretical Statistician
Staff member
Super Moderator
#9
...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

Stop X-bar/R Madness!!
Trusted Information Resource
#10
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.
:topic:
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.
 
Thread starter Similar threads Forum Replies Date
I TRIZ (Theory of Inventive Problem Solving) Methodology - Is there training available? Misc. Quality Assurance and Business Systems Related Topics 6
F How Can I Identify any Drawbacks of 8D Problem Solving Methodology Quality Tools, Improvement and Analysis 5
D Experience with Toyota's A3 Problem Solving methodology Lean in Manufacturing and Service Industries 4
M Switching to new problem solving methodology Quality Tools, Improvement and Analysis 7
B 8D Root Cause Problem Solving Methodology in TS16949 Problem Solving, Root Cause Fault and Failure Analysis 10
M Problem Solving in Fiat Automobiles Problem Solving, Root Cause Fault and Failure Analysis 0
R Problem solving activity - Three hours to fix the issue Manufacturing and Related Processes 15
NDesouza Go See, Think, Do (GSTD) Problem Solving Activity Food Safety - ISO 22000, HACCP (21 CFR 120) 8
K Does anyone have a copy of a GM 5 Phase Problem solving form Problem Solving, Root Cause Fault and Failure Analysis 1
D Training for AS13000 - Problem Solving Requirements for Suppliers Training - Internal, External, Online and Distance Learning 17
G When preventative action is prohibited by cost in 8D problem solving Problem Solving, Root Cause Fault and Failure Analysis 1
G When preventative action is prohibited by cost in 8D problem solving Problem Solving, Root Cause Fault and Failure Analysis 8
M Training in 8D Problem Solving as a Preventive Action? Problem Solving, Root Cause Fault and Failure Analysis 9
A 5Why vs. 8D - Problem Solving Problem Solving, Root Cause Fault and Failure Analysis 19
K Documented problem solving and documented error-proofing - IATF 16949 10.2.3 & 10.2.4 Internal Auditing 7
W Documented Problem-Solving for Automotive IATF 16949 - Automotive Quality Systems Standard 4
Q Problem Solving Techniques - 5 why or Fishbone diagram ? Problem Solving, Root Cause Fault and Failure Analysis 8
S Problem Solving Database for Each Machine Manufacturing and Related Processes 5
automoto International Problem Solving Guide Problem Solving, Root Cause Fault and Failure Analysis 2
M Problem Solving: JDI (just do it) vs. A3 vs PDCA Projects Lean in Manufacturing and Service Industries 1
P Global 8D Problem Solving Training Material Problem Solving, Root Cause Fault and Failure Analysis 1
P Global 8D Problem Solving Example Problem Solving, Root Cause Fault and Failure Analysis 5
N Corrective and Preventive Action in 8D Problem Solving Nonconformance and Corrective Action 21
B Problem to be used for Problem Solving class for different Manufacturing Backgrounds Problem Solving, Root Cause Fault and Failure Analysis 1
T What Problem Solving Tools do you use the most? Problem Solving, Root Cause Fault and Failure Analysis 4
E Problem Solving using PDCA/A3 - Tips & Exercise Lean in Manufacturing and Service Industries 3
C A3 Problem Solving Template Document Control Systems, Procedures, Forms and Templates 0
C 5 Why's Problem Solving Template Document Control Systems, Procedures, Forms and Templates 0
O Practical 8-D or similar Problem Solving worksheet or form Excel .xls Spreadsheet Templates and Tools 5
Q Green Wall or Green Room Problem Solving Problem Solving, Root Cause Fault and Failure Analysis 2
K 7 or 8D (Problem Solving) CAPA template Nonconformance and Corrective Action 4
C What is problem solving? Imported Legacy Blogs 5
T Practical Problem Solving - Does anyone have a practical problem solving template? Document Control Systems, Procedures, Forms and Templates 6
W Does anyone have a Training Exercise for 5 Whys Problem Solving? Problem Solving, Root Cause Fault and Failure Analysis 11
Q List of Problem Solving Methods (not tools) Problem Solving, Root Cause Fault and Failure Analysis 23
R 5S Problem Solving Presentation needed Lean in Manufacturing and Service Industries 4
F Toyota A3 Practical Problem Solving (PPS) Document Needed Nonconformance and Corrective Action 1
Casana 8D (Eight Disciplines) Problem Solving - When Actions are not Effective Nonconformance and Corrective Action 5
P I need a good QC story format for my use in problem solving technique Document Control Systems, Procedures, Forms and Templates 1
U Problem Solving Flowchart Problem Solving, Root Cause Fault and Failure Analysis 9
M Lesson Learned Cards for Problem Solving and Prevention after 8D Problem Solving, Root Cause Fault and Failure Analysis 1
F Problem Solving Workshops - DMAIC Example? Six Sigma 11
L When to use 8D Problem Solving Misc. Quality Assurance and Business Systems Related Topics 3
A How many steps in an 8D? What is an 8-D? Problem Solving Problem Solving, Root Cause Fault and Failure Analysis 4
J IS - IS NOT Problem Solving Analysis Method Nonconformance and Corrective Action 10
Chennaiite What is meant by 'Lesson Learned' in the context of Problem Solving Quality Tools, Improvement and Analysis 6
C Planning & Implementing Solution (book chapter 5 on problem solving) The Reading Room 8
C Identifying Causes (book chapter 4 on problem solving) The Reading Room 26
D Problem Solving Techniques Training Materials Training - Internal, External, Online and Distance Learning 4
M So long Problem Solving Program? Quality Tools, Improvement and Analysis 1

Similar threads

Top Bottom