The War on Error – Vol. VII: The Shainin System

     Lesser known than Six Sigma, but no less valuable, the Shainin System is a structured program for problem solving, variation reduction, and quality improvement.  While there are similarities between these two systems, some key characteristics lie in stark contrast.
     This installment of “The War on Error” introduces the Shainin System, providing background information and a description of its structure.  Some common problem-solving tools will also be described.  Finally, a discussion of the relationship between the Shainin System and Six Sigma will be presented, allowing readers to evaluate the potential for implementation of each in their organizations.

Origins of the Shainin System
     Development of the Shainin System began in the 1940s while Dorian Shainin worked with aeronautics companies to resolve production issues.  In the intervening decades, the system has evolved, with additional tools developed, through Shainin’s experience with numerous operations and a vast range of quality and reliability problems.
     Use of the Shainin System to improve process performance is based upon the following tenets:

• A single root cause is the source of the greatest amount of variation (the “Red X”); it may be an independent variable or the interaction effects of multiple variables.  The “Pink X” and “Pale Pink X” are the second and third largest contributors to variation, respectively.
• Breakthrough improvements in process performance are achieved only by identifying and controlling the Red X.  The Pink X and Pale Pink X may also require improvement.  The Red X is critical because the output varies as a function of the squares of the input variations, according to the following relation:
  

• Random variation does not exist.  Several input factors (Xs) affect the variation in output (Y).  With sufficient resources, all Xs could be identified.

     The Shainin System is also known by a more descriptive moniker, “Red X Problem Solving,” owing to its focus on the single largest contributor to process variation.  It has been developed to be statistically rigorous, while keeping complex statistics in the background.  This expands the use of tools from highly-trained statisticians to operators and engineers of all skill levels.
     Red X Problem Solving is best suited for process development projects with the following characteristics:

• medium- to high-volume process,
• data are readily available,
• statistical methods are in common use, and
• process intervention is difficult.

 
The FACTUAL Framework
     Much like Six Sigma, the Shainin System uses an acronym to guide application of its methodology.  Fortunately, this one is easy to pronounce!  The FACTUAL framework is comprised of the steps Focus, Approach, Converge, Test, Understand, Apply, and Leverage.
     Each component of the FACTUAL framework is presented in a summary table below.  The top cell of each table contains a description of activities associated with that step.  The lower left cell contains the deliverables expected to result from those activities.  The lower right cell lists examples of tools commonly used to achieve the objectives of each step.  Those designated with a “*” are discussed in the next section.

     The FACTUAL framework exhibits a similar flow to DMAIC – problem definition → data collection → analysis → implementation → monitoring – but the Shainin System takes much greater advantage of graphical analysis than does Six Sigma.  Use of graphical tools facilitates implementation by non-mathematicians and expedites identification of the Red X.  The Shainin System toolbox is the topic to which we now turn.
 
Tools of the Shainin System
     More than 20 tools have been developed as part of the Shainin System, using a foundation of rigorous statistics.  The tools are designed to be intuitive and easy to use by practitioners without extensive statistical training.  Many are unique, while a few have been adapted or expanded for use within the Shainin System.  The descriptions below only preview the tools available.  Consult the references cited, or other sources, for additional information.  Links to additional information are provided to assist this effort.
 
 [Focus]
5W2H:  5W2H is an abbreviation for seven generic questions that can be used to define the scope of a problem.  The 5 Ws are Who? What? Where? When? and Why?  The 2 Hs are How? and How much?  As simple as this “tool” is, it must be used with caution.  If the answers to these questions are perceived as accusatory, the improvement effort may lose the support of critical team members, hindering identification of the Red X and implementation of a solution.
Links to additional information on tools used in the Focus step:
Eight Disciplines (8D)
 
 [Approach]
Isoplot:  An Isoplot is used to evaluate the reliability of a measurement system; it is an alternative method to variable gauge R&R.  To construct and interpret an Isoplot (see Exhibit 1):
1) Measure the characteristic of interest on each of 30 pieces.  Repeat the measurement on each piece.
2) Plot the pairs of measurements; the first measurement on the horizontal axis, the second on the vertical axis.
3) Draw a 45° line (slope = 1) through the scatter plot created in step 2.
4) Draw two lines, each parallel to the 45° line, that bound all data points.
5) Determine the perpendicular distance between the lines drawn in step 4.  This distance represents the measurement system variation, ΔM.
6) Determine the process variation, ΔP.  This is the range of measurements along the horizontal axis.
7) Calculate the Discrimination Ratio:  ΔP/ΔM.
8) If (ΔP/ΔM) ≥ 6, accept the measurement system; otherwise, seek improvements before using the measurement system in the search for the Red X.

 [Converge]
Component Search:  This technique can be called, simply, “part swapping.”  By exchanging components in an assembly and tracking which combinations perform acceptably and which do not, the source of the problem can be traced to a single component or combination of components.  To conduct a Component Search, select a set of the best-performing assemblies (BoB, “best of the best”), and an equal number of the worst-performing (WoW, “worst of the worst”).  As parts are swapped, poor performance will follow the “problem parts.”
Multivari Analysis:  A multivari chart is a type of run chart that displays multiple measurements within samples over time.  For example, a characteristic is measured in multiple locations on each part.  Samples consist of consecutively-produced parts, collected at regular intervals.  As can be seen in Exhibit 2, plotting these data allows rapid evaluation of positional (within-part), cyclical (part-to-part), and temporal (time-to-time) variations.

Links to additional information on tools used in the Converge step:
Concentration Diagram
Group Comparison
Solution Tree – example shown in project context
 
 [Test]
B vs. C:  Comparing the current process (C) with a proposed “better” process (B) develops confidence that the new process will truly perform better than the existing one.  Data collected while running the B process should indicate improved performance compared to C.  When C is again operated, performance should return to the previous, unsatisfactory level.  If process performance cannot be predictably controlled in this fashion, further investigation is required.  Several iterations may be required to sufficiently demonstrate that the new process, B, outperforms the existing process, C.
Variable Search:  Conducted in similar fashion to Component Search, Variable Search is employed with five or more suspect variables.  “High” and “low” values are chosen for each variable, analogous to “good” and “bad” parts.  Comparisons of performance are then made, varying one suspect variable at a time, to incriminate or eliminate each variable.  If a characteristic is “the same” in “good” and “bad” assemblies, it is unlikely to be a significant contributor to the issue experienced.
Links to additional information on tools used in the Test step:
ANOVA on Ranks
Full Factorial Experiments or Full Factorial Example
 
 [Understand]
Tolerance Parallelogram:  Realistic tolerances to be used for the Red X variable to achieve Green Y output can be determined using a Realistic Tolerance Parallelogram Plot.  To construct and interpret a Tolerance Parallelogram (see Exhibit 3):
1) Plot Red X vs. Green Y for 30 random parts.
2) Draw a median line, or regression line, through the data.
3) Draw two lines, parallel to the median line, that bound “all but one and a half” of the data points.  The vertical distance between these two lines represents 95% of the output variation caused by factors other than the variable plotted.  If this distance is large, the variable may not be as significant as suspected.  Perhaps it is a Pink X or Pale Pink X instead of the Red X.
4) Draw horizontal lines at the upper and lower limits of the customer requirement for the output (Y).
5) From the intersection of the lower customer requirement line and the lower parallelogram boundary, draw a vertical line to the horizontal axis.
6) From the intersection of the upper customer requirement line and the upper parallelogram boundary, draw a vertical line to the horizontal axis.
7) The intercepts of the lines drawn in steps 5 and 6 with the horizontal axis represent the realistic tolerance limits for input X to achieve Green Y output.

Links to additional information on tools used in the Understand step:
Tolerance Analysis
 
 [Apply]
Lot Plot:  A Lot Plot can be used to determine if a lot of parts should be accepted, sorted, or investigated further.  To construct and interpret a Lot Plot:
1) Measure 50 pieces, in 10 subgroups of 5 pieces each, from a single lot.
2) Create a histogram, with 7 – 16 divisions, of all 50 measurements.
3) From the histogram, determine the type of distribution (normal, bimodal, non-normal).
4) Calculate the average (Xbar) and range (R) of measurements in each subgroup.
5) Calculate the average of the subgroup averages (Xdbl-bar) and the average of the subgroup ranges (Rbar).
6) Calculate upper and lower lot limits (ULL, LLL):

7) Evaluate acceptability of lot.  For normally-distributed data, use the following guidelines:

• All sample data within specification limits → Accept.
• ULL and LLL are within specification limits → Accept.
• ULL or LLL is outside specification limits → Acceptance decision is made by Material Review Board.

For non-normally-distributed data, use the following guidelines:

• ULL and LLL are within specification limits → Investigate non-normality or repeat sampling.
• ULL and/or LLL is outside specification limits → Sort.

For bimodally-distributed data, investigate the cause of bimodality or repeat sampling.
Links to additional information on tools used in the Apply step:
Precontrol
 
 [Leverage]
To leverage what is learned from an improvement project, use of several tools may be repeated.  For example, similar processes may have a common Red X influencing their performance.  The tolerances required to maintain acceptable output from each, however, may be very different.  Each will require its own tolerance parallelogram.  In general, leveraging knowledge gained in one project does not preclude thorough analysis in another.
FMEA:  Though not a component of the Shainin System per se, a thoughtfully-constructed and well-maintained Failure Modes and Effects Analysis is a rich source of ideas for “leverage targets.”  For example, all products or processes that share a failure mode could potentially reap significant gains by replicating the improvements validated in a single project.
 
            The selection of tools at each stage of a project will depend on the specific situation.  A problem’s complexity (i.e. the number of variables involved) or the ability to disassemble and reassemble products without damage are examples of circumstances that will guide the use of tools.  Understanding the appropriate application of each is critical to project success.
 
The Shainin System and Six Sigma
            Vehement advocates of the Shainin System or Six Sigma often frame the relationship as an either/or proposition.  This adversarial stance is counterproductive.  Each framework provides a useful problem-solving structure and a powerful set of tools.  There is nothing to suggest that they are – or should be – mutually exclusive.
            Six Sigma is steeped in statistical analysis, while the Shainin System prefers to exploit empirical investigations.  Six Sigma traces a problem from input to output (X → Y), while the Shainin System employs a Y → X approach.  Six Sigma requires training specialists, while the Shainin System aims to put the tools to use on the shop floor.
            Despite their differences, these systems share common objectives, namely, process improvement and customer satisfaction.  In the shared objectives lies the potential for a cohesive, unified approach to problem-solving that capitalizes on the strengths of both frameworks.  One such unification proposes using Shainin tools within a DMAIC project structure (Exhibit 4).  Six Sigma tools could also be used to support a FACTUAL problem-solving effort.  Both frameworks are structured around diagnostic and remedial journeys, further supporting the view that they are complements rather than alternatives.

     The hierarchical structure of “Red X Problem Solvers” is another example of a similarity to Six Sigma that also highlights a contrast.  Students of the Shainin System begin as Red X Apprentices and advance to become Journeymen.  These titles have strong “blue-collar” connotations and are familiar to most “shop floor” personnel that are encouraged to learn and apply the tools.  Like Six Sigma, the Shainin System also has a designation for those with substantial experience that have been trained to coach others – the Red X Master.
 
 
     One need not have a sanctioned title to begin learning and applying useful tools.  Readers are encouraged to consult the references and links to learn more.  Also, JayWink Solutions is available for problem-solving assistance, training development and delivery, project selection assistance, and other operations-related needs.  Contact us for an assessment of our partnership potential.
 
For a directory of “The War on Error” volumes on “The Third Degree,” see “Vol. I:  Welcome to the Army.”
 
References
[Link] “Strategies for Technical Problem Solving.”  Richard D. Shainin; Quality Engineering, 1993.
[Link] “An Overview of the Shainin SystemTM for Quality Improvement.”  Stefan H. Steiner, R. Jock MacKay, and John S. Ramberg;  Quality Engineering, 2008.
[Link] “Introduction to the Shainin method.”  Wikilean.
[Link] “Shainin and Six Sigma.”  Shainin The Red X Company.
[Link] “Using Shainin DOE for Six Sigma: an Indian case study.”  Anupama Prashar; Production Planning & Control, 2016.
[Link] “Developing Effective Red X Problem Solvers.”  Richard D. Shainin; Shainin The Red X Company, April 18, 2018.
[Link] “Shainin Methodology:  An Alternative or an Effective Complement to Six Sigma?”  Jan Kosina; Quality Innovation Prosperity, 2015.
[Link] “The Role of Statistical Design of Experiments in Six Sigma:  Perspectives of a Practitioner.”  T. N. Goh; Quality Engineering, 2002.
[Link] World Class Quality.  Keki R. Bhote; American Management Association, 1991.
[Link] “Training for Shainin’s approach to experimental design using a catapult.”  Jiju Antony and Alfred Ho Yuen Cheng; Journal of European Industrial Training, 2003.
 
Jody W. Phelps, MSc, PMP®, MBA
Principal Consultant
JayWink Solutions, LLC
jody@jaywink.com