DMAIC - For Improvement

DMAIC is a FANTASTIC process improvement methodology. While DMAIC had its origins in “Lean”, it was an integral part of GE's Six Sigma program during the late '90s. GE saved $12 billion over five years and added $1 to its earnings per share ¹⁾

ASQ defines DMAIC as:

DMAIC: A data driven quality strategy for improving processes and an integral part of a Six Sigma quality initiative. DMAIC is an acronym for define, measure, analyze, improve and control.

While I generally agree with the above definition, I'd change the phrasing of “…quality strategy…” to more correctly describe DMAIC as a “methodology”, and expand its application to read:

DMAIC: A data-driven methodology for improving processes and an integral part of the Lean, Six Sigma and Lean Six Sigma (LSS) quality initiatives. DMAIC is an acronym for define, measure, analyze, improve and control.

Far too often, I see flawed or overly restrictive explanations of “what” DMAIC is. Below is a more accurate description:

The first stage of the DMAIC improvement process is to “define” the “problem”.

A “problem” is the “gap” between where you are and where you want/need to be. When defining the problem, be aware that the DMAIC methodology can be used in response to either an existing quality-related nonconformity or simply a business-related improvement (e.g., to improve efficiency). Be sure to define the scope (e.g., specific products impacted) and boundaries (e.g., specific production area(s) where the problem exists).

For example:

The “Measure” stage typically involves creating a ”Data Collection Plan“. This includes identifying those measurements that are pertinent to the scope of the problem. Common examples include:

• FPT (First Pass Yield) - to determine the number of defects being produced by the process
• Throughput Time - including the time spent (1) waiting, (2) processing, (3) inspection/testing, (4) movement, etc. from the point of entry to the point in which the product is released to the next step in the value stream.

This high-level data will help the team develop more focused/meaningful measurements that can be used to identify the contributing factors to the problem. For example, if there FPY is low, then this may be due to (1) inexperienced (new) workers receiving inadequate training, (2) inadequate Work Instructions, (3) worker fatigue, (4) defective components received from one or more suppliers, etc.

In addition, capturing data for a Pareto Chart of the most common nonconformities may offer greater insight into the problem. If the problem can be isolated to a specific part, this could indicate (1) a supplier issue, (2) a design issue, (3) a workmanship issue involving the placement of the part, (4) the lack of a sufficiently detailed Work Instructions, etc.

<note important>While a Pareto Chart can be useful, it will not differentiate between defects due to ”Common Cause“ vs ”Assignable Cause“ variations in a process.</note>

If the Throughput Time is lower than planned, this may be due to (1) Supplier delivery delays, (2) production “bottlenecks”, (3) process inefficiencies, (4) repetitive machinery breakdowns, etc.

While many of these examples point to areas outside of the initial scope area, once identified, we can expand the scope to include those areas contributing to the problem. The source of the problem may actually be an “input” to the process being analyzed.

Upon obtaining measurement data, the next task is to analyze the data to determine the various causes leading to, or contributing to the problem. Students of ”causal analysis“ techniques typically learn the simplest techniques first, then only learn more complex/sophisticated techniques if needed (assuming that this learning is guided by a mentor or an instructor):

1. 5 Whys
2. 5 Whys with Tree Diagram (for addressing multiple causes)
3. Fishbone (Ishikawa) Diagram (for addressing multiple causes from multiple sources)
4. Events & Causal Factors Charting (for addressing multiple causes associated with their conditions)
5. Fault Tree Analysis (for including AND, OR & AND/OR conditions with multiple sources)
6. Apollo Root Cause Analysis (Using a “Reality Chart” approach)

Unfortunately, almost all of the above techniques assume that the solution(s) will become obvious through the causal analysis process. It should come as no surprise that the simpler techniques are the most popular… because they can be effective in solving simple problems with few causes and obvious solutions. The true “root cause” for most of these simple problems is poor planning. As the complexity of the problems increases, more sophisticated causal analysis techniques are required. And the solution becomes more evasive.

With so much focus on “causal analysis”, it is unfortunate that the vast majority of Quality Professionals remain oblivious to any sort of structured problem-solving!

We must acknowledge that in order to improve, we must be innovative (inventive).

If you're like most Quality Professionals, you've never heard of TRIZ… or perhaps you considered it something only useful for Engineers. In reality, TRIZ is a structured approach applicable to solving virtually any problem.

TRIZ is the Russian acronym for “Theoria Resheneyva Isobretatelskehuh Zadach”; which translates into English as the “Theory of Inventive Problem Solving”. TRIZ was developed between 1946 and 1985, by Engineer and Scientist Genrich S. Altshuller and his colleagues. The premise of TRIZ is that there are universal principles for innovation. TRIZ identifies and codifies these principles so that they can be used to add structure and standardize the process for innovation.

One of the first things that TRIZ practitioners learn is that “solutions” include contradictions (whether as “trade-offs” or “inherent”). The TRIZ methodology promotes improvement of the system/process towards “ideality” by overcoming the contradictions.