Sigma is the 18th letter in the 24 letter Greek alphabet.  The term "Six Sigma" derives from a statistical measure of variation or variability.

In 1951, Armand V. Feigenbaum coined the term Total Quality Control (TQC). Others also had names and definitions for this technology, including Shewhart, Ishikawa, Deming, Juran, Crosby, Taguchi, and others. Two names were Quality Control and Statistical Process Control. Then in the late 1980’s Motorola, and later GE and other companies, began to use the term Six Sigma. Today, Six Sigma is one of the most popular names for the collection of techniques used to reduce process variation. 

But don’t let the statistical implications of the name scare you. To drive a car you don’t need to know how to build one, and to use a computer you don’t need to know how everything works. It is the same with Six Sigma. To use the techniques you don’t need to know how to prove the formulae (but is it nice to have access to a statistician, or auto mechanic, or computer geek, when the need arises). 

A process with a variation of six sigmas is said to equate to 3.4 defects per million opportunities. A process that produces good parts 99% of the time creates 1 defect out of 100; that is the same as 10 out of a 1000, or 10,000 out of 1,000,000 opportunities. Six Sigma equates to 99.99966%! Most organizations can attain four sigma with some quality disciplines. Five sigma requires more dedicated efforts. Six sigma requires problem prevention – correcting the conditions that cause defects before they occur.







Shewart, Deming and others used the “Plan, Do, Check, Act” circle as a guide to problem solving.( Some refer to it as the Plan, Do, Study, Act circle. Everything seems to have multiple names!).

 


Six Sigma advocates use the DMAIC process as their template.

The PDCA and DMAIC processes are similar and both follow the scientific method for problem solving. Bill Sandras will discuss both with you and use which every methodology you prefer. 

Problem Solving Storyboard

PCI includes its Problem Solving Storyboard as a part of the Six Sigma education. Storyboards have been in use in the film industry for decades. Writers use them to develop the script and directors use them to guide the course of events during the shoot. Storyboards are also useful for developing audiovisual presentations. The resulting storyboard is then available for the presenters as a guide.

PCI’s Problem Solving Storyboards help to guide teams through the PDCA or DMAIC problem solving process. The written part of the storyboard chronologically lists corrective actions taken. The numerical part of the storyboard graphically displays the results of the corrective actions. 

The Problem Solving Storyboard is a working document – it shows the problem statement, the goal, the analysis, the actions taken, and the results in a few concise pages. Only an updated working copy of the Storyboard is needed for management presentations, thus allowing the teams can focus on solving the problem rather than preparing for presentations. And, when the goals are reached, the Storyboard already contains the full story. In addition, if all teams are using a similar Storyboard format, it enables management to quickly focus on the critical issues, rather than take time to question the problem solving process itself. 

Learning and Applying Six Sigma in a Data RBE

The objective of a Data RBE is to resolve a quantifiable problem. Examples are: too many defects, too much variation in the time it takes to process a transaction, accounts receivables outstanding too long, customer service levels too low, etc.

Activity begins before the workshop. First, senior management writes a charter document explaining the problem. Affected managers assign names and commit the time for themselves and/or their people to work on the problem solving team. 

An example of a Data RBE is shown in the inset. 

We begin by discussing the Six Sigma philosophy and process, or if the client prefers, the Total Quality Management version. 

Next we conduct a simulation so that those in attendance can experience the same problem, and same frustration in solving it without Six Sigma tools.

They we go into the core Six Sigma tools themselves; those seven tools that Ishikawa says can be used to solve 95% of all problems within a company. We use many examples from life, newspapers, and other companies to help attendees understand the principles. They also practice with the seven tools on the some of the examples. We take the fear out of Six Sigma by showing that with some of the tools you only need to know how to point, some only require you add, subtract, multiply, and divide, others only require you to think and write, and of course some use statistics. But even those with statistics do not require courses in statistics, but some basic understanding and the ability to follow some documented procedures.

Next we conduct simulation again. This time the attendees are charged with using the appropriate tools to analyze the problems and make improvements. 

Then the Problem Solving Storyboard is explained. We use an example of the Storyboard from the simulation, plus examples from other problem solving teams.

Finally, near the end of the first day or the morning of the second, the teams begin to complete their own Problem Solving Storyboard. In the process of doing that, they will: 

  1. Define the problem and its limits

  2. Verify the necessary people are on the team

  3. Define the performance measures and the goal,

  4. Describe the priority of this problem and potential problems to success,

  5. Flowchart the process(s)

  6. Develop a cause & effect diagram

  7. Analyze the data they have and create a data collection procedure for what they need,

  8. Schedule follow-up meetings for the team, and with the PCI, 

  9. Schedule reviews with senior management, and

  10. Put a project plan together showing the known action items to be completed (e.g., train people on data collection, assign someone to enter the data on a daily basis, develop spreadsheets or programs to analyze the data; and when the root cause is known, additions to the action plan will show necessary changes to be made). 

After the two-day Data RBE, the team will continue to document the steps they take and the results they achieve on the Storyboard. Depending on the scope and complexity of the problem the team may meet periodically for several months. When the initial goals are reached, they will either tighten them and continue, or document how the new Standard process and dissolve this team so the members can work on other problem solving teams. 

For more information on the:

 

 

|  Home  |  About PCI  |  Our Services  |  Public Events  |  Publications & Other Information  |  Related Links  |  Contact Us  |

© Copyright 2000-2007 Productivity Centers International
The contents of this website, and the following terms, are 1985-2007 service marks or copyrights of William A. Sandras, Jr.:
Rapid Breakthrough Events, RBE, Alignment RBE, Value Stream RBE, Process RBE, Data RBE, and “one less at a time”.