Six Sigma Quality

Six Sigma Quality came from Motorola in the late 1980s. It is a quality management methodology which is based on reducing defects to 3.4 per 1 million opportunities. This is the statistical definition of Six Sigma (6 σ). For practical purposes, Six Sigma can be split into two - the number crunching or statistical elements and the Six Sigma tools and management approach. For those of us not involved in operations with a large number transactions or production units, there is little need to delve into the statistical elements.

Our focus is therefore mainly on using the Six Sigma approach and its analytical tools. In particular, we encourage our clients to base their analysis and decisions on facts and not guess-work and, from there, to use the DMAIC methodology in solving problems.

No Guessing - stick to facts
Many of us have seen "process maps" which are really schematics of what the designer thinks the process should be. These clear, tidy and neat diagrams rarely show convoluted process flows and they do not always reflect the reality of the workplace with people improvising or developing workarounds. Whilst they make good wall decorations, they do not help anyone trying to sort out process problems or exploring improvements. When we asked our clients to walk the process so that they can map it accurately, the initial response is often:
     "... goodness, this is tedious..."

But when the process is accurately mapped, the comments quickly change to:
     "... THIS is our process?..." and "... I never knew this is what we are working to..."

With accurate data, it becomes significantly easier to solve a process problem or to improve a specific part of a process.


The importance of analysis and decision making based on accurate data part of good management practice and this is also part of the Six Sigma problem solving method DMAIC.

DMAIC - the Six Sigma standard problem solving method
DMAIC is an acronym for Define - Measure - Analyse - Improve - Control. It is a 5-step process that can be applied in virtually any circumstance where there is a problem to be resolved. The sequence of activities are described below.

Define: an accurate definition of the problem and its impacts (based on facts) such that everyone on the team understands and there is no ambiguity.

Measure: this is to make sure we know the extent of the problem - the impacts are "defined" but "measure" allows us to gauge the severity of the impact and also allows us to compare one problem against another. This has to be based on actual data to be of any use.

Analyse: the problem is analysed and a technical solution is produced. This solution is often the logical one which makes sense to everyone taking part in the problem analysis.

Improve: this is about the implementing the solution - the implementation takes the solution from purely a technical response to the real world, with awkward people, cramped working area and limited budgets. It is also a solution that is wrapped in communications, training and motivation. The packaging is necessary to enable the technical solution to be acceptable and practicable in the reality of the workplace.

Control: this is the phase that is occasionally ignored. This is about making sure the problem stay solved and the gains from the improvement are not eroded. It is not necessarily easy or a lot of fun, but unless you enjoy carrying out the same improvement year after year, this is a critical step to pursue with diligence.

top