DMAIC is the Six Sigma acronym for:
A DMAIC project has the goal of improving an existing system. (A DMADV project creates a new system or a new product).
Define three concepts: the problem; the process; and the goal(s) of this project.
The problem must be clearly articulated using quantitative terms. One cannot simply say, "The quality is poor". The problem should be stated as, "The defect rate is 7%". The term "defect rate" should also be defined – the number of sold units returned by customers? The number of completed units scrapped before shipment? The difference between the number of units begun minus the number which passed final inspection?
Some prefer to speak of "opportunities for improvement" rather than "problems".
Define the process under study, at a high level. Important aspects of the process are:
The goal(s) must be clearly articulated to solve the problem. For example, "To improve the defect rate to be less than 4% within 3 months".
The "Define" phase, consists of five key activities:
Define the roles for the team members. Typical full-scale Six Sigma projects require a Black Belt, several Green Belts and some employees from the department(s) that will benefit from the project.
Choose the best people to fill these roles. It may seem obvious to select a particular Green Belt who has experience in the department or with the class of problem being addressed. However, it may be important to bring someone else on board to gain experience for future projects.
Selecting people from the department may pose the same conundrum: to use someone with experience in special projects, or to help people develop in their careers?
Will it be necessary to bring in outside consultants, whether for their Six Sigma knowledge or because of their technical expertise? Remember that the project will be costly in terms of internal salaries; pinching pennies to avoid hiring consultants may waste the whole project.
The "customer" is an entity that receives services or products from the department involved in the project. The customer may be internal or external. There may be multiple customers. There may be different products or services. Different processes may be used by one customer, perhaps depending on the type, cost, or other characteristics of the transaction.
This activity includes documenting the requirements of each customer: these define what will "satisfy" the customer.
This documentation is vital in later stages of a Six Sigma project.
The Project Charter is a document which identifies the project, summarizes the need and justification for the project, and outlines the scope and objectives.
A typical project charter has sections covering the project identity (as a name or number), the business case, the scope, the budget, the objectives, milestones, any special requirements or assumptions, and the project team (by name, role and responsibilities).
Many times the time frame for each phase is added to the project charter. This helps maintain the senses of urgency associated with these projects.
"SIPOC" stands for "Supplier, Input, Process, Output, Customer". The SIPOC map is a graph tracing the inputs received from suppliers, through the department's processes that create the outputs going to the customers.
A SIPOC map identifies the current system at a high level. It will be used later in the project to show the processes being changed. Without an accurate and complete SIPOC map, source of defects may easily be overlooked.
By producing the deliverables in the "Define" phase, the Six Sigma team will have documented vital information about the project. Who are the customers? What do they need and want? What issues might cause resistance to change? What are the constraints on the project, in terms of budget, personnel and deadlines?
Resist the temptation to rush the Define stage. Selecting the wrong people, especially because someone is temporarily unavailable, can lead to serious problems in later stages. Both the customer's business process, and the SIPOC map, will require investigation and analysis. If surprises arise later in the project, then costs and timelines will be compromised.
The project charter is another key to success, since it contains the objectives and the business case. Hasty research or poor estimates will lead to a failure to achieve the stated goals, particularly the budget or cost benefits, even if the project successfully solves a problem.
This phase should start with a process map, whether by observation or by interviewing the participants. Sometimes there are useful surprises when interviewing or observing different participants – does the midnight shift work at a slower pace, or with fewer interruptions?
Measure key aspects of the situation. Gather relevant data – look for the factors which may affect the outcome of the process under study.The four major activities in a Six Sigma "Measure" phase are:
Many practitioners group the first two activities: "to plan and collect the data".
The overall goal of this phase is to measure the performance of the core business process scrutinized by the Six Sigma project.
The goal in collecting data is to identify what needs to be improved in the business process.
Planning is required because of the huge amount of data that could be collected. Plan to obtain data from three main areas: the source of the inputs to the business process; the process itself; and the outputs from the business process.
Quality assurance techniques can determine whether source input defects are causing problems for the "target" department.
The process data is usually concerned with efficiency measurements. How long does the process take? What does it cost? How much value is produced? What is the defect rate? How much labour is involved?
The output data tends to measure the efficiency of the process. How much output was obtained from the inputs? What was its value? Would the customer accept the output, or reject it despite passing the business process controls?
Plan to avoid sampling bias. For example, make observations at different times, not just during a weekday shift.
This activity executes the data collection plan. It may seem time-consuming and menial, but there are opportunities to learn about the process. For example, asking about the frequency of machine breakdowns might yield useful information, even if no repairs were needed during this activity.
Any output, whether product or service, that falls outside the customer's specifications is considered a "defect" within a Six Sigma project. Each chance that a defect might occur is an "opportunity".
For example, the project may observe a machine making one hundred metal washers. The washer's minimum and maximum weight, thickness, outer circumference, the diameter of the hole, and "flatness" are specified. Multiply five (specifications) times 100 (outputs: the washers) to determine that there are 500 opportunities for defects.
DPMO (Defects per Million Opportunities) is calculated by multiplying 1,000,000 times the number of defects and dividing by the number of opportunities.
To continue the example: say that three washers were defective due to the size of the hole, four due to the thickness, and one mangled washer was rejected because it was under-weight, too small and not flat. That is a total of ten defects for eight rejected washers. DPMO = 1,000,000 X 10 / 500 = 20,000 defects per million opportunities.
The standard statistical table relates the Sigma value to the DPMO. 20,000 defects indicates that Sigma is between 3.5 and 3.6. There is considerable room for improvement to the Six Sigma standard of 3.4 DPMO.
This activity is called "FMEA": Failure Mode and Effects Analysis. The goal is to prevent defects. The three usual dimensions for analyzing each defect are:
Usually each dimension is scored from 1 to 10, with 10 the most likely, detectable or severe. Whether one adds or multiplies the dimensions together, the result will be that different failure modes will have a rating. The defects with the highest scores will be the first targets for improvements.
In the above example, the single mangled washer was the least likely failure. However, it was the easiest to detect and, let us say, the most dangerous in that it could damage the machine, so it may have scored 1 + 10 + 10 = 21 and warrants the most attention. The four thin washers had the highest frequency but might not score highly for the other criteria.
Analyze the data for statistical relationships.
For example: it was observed that the midnight shift works differently. Data should then have been gathered on productivity and quality on a per-shift basis. The analysis may, or may not, show that one shift contributes more to the problem than another.
One roadblock may be that the anomalies might be explained by "random chance". If the statistics do not support a cause/effect relationship, then Six Sigma's DMAIC does not offer a solution.
The Six Sigma "Analyze" phase determines the causes of defects and measures their severity. Usually this phase is broken into five analysis activities, followed by a completion activity:
This phase seeks to identify the "root cause" of the problem.
This activity seeks the source, or root cause, of each type of defect. A convenient approach is to use "three steps" to determine the root cause: opening, narrowing and closing steps.
The "opening" step is essentially a brainstorming session. List all possible causes.
In the "narrowing" step, eliminate the causes which do not fully explain how the defects occurred.
"Close" the root cause analysis by performing further tests to validate the suspected causes of the defects. Several causes may be implicated by these tests.
Each process is, in a sense, "competing" with others for efficiency and effectiveness. Do some business competitors excel in a process comparable to the one under study? What is the theoretic limit on the process, and how far is it falling short?
Create a detailed process map to determine where defects may be introduced, or where efficiencies may be found.
This activity differs from the root cause analysis because its focus is on "movement": where do requests or materials go? The root cause analysis is more likely to find problems in the inputs or the equipment.
Data analysis often begins by using a standard statistical analysis tool, such as Minitab.
Question even the validity of the data that has been collected. Was there a bias in the sampling?
For example…and this should have been addressed in the Data Planning activity…all the project data may have been collected during a weekday shift. Night or weekend shifts may have completely different employees, and their defect patterns may be quite different. Was data collected just before or just after a routine maintenance task?
This is also the time to check whether there are surprising statistical patterns in the data. While even random numbers will show some patterns when subjected to enough analysis, it should be clear from this phase whether further data collection is required.
This usually addresses problems in efficiency and timeliness. If inputs are not available on time, then production will lag. Are there too few forklifts? Is the supplier late with deliveries; if so, why?
Some production and process defects will be caused by inadequate human resourcing or training. Fatigue may be a factor to be considered, and may be considered a human resourcing issue.
Perhaps there is a problem in communications. It is impossible to correctly fulfil a purchase order if the part number or quantity figures are copied incorrectly.
A classic example comes with a discrepancy between a verbal offer from the salesperson and inflexible back-room processes at head office. "You offered me a discount on my annual purchases". "Our system can only provide discounts on individual bulk orders".
Whether the customer is external or another internal department, poor communication leads to many defects.
Document the results from all the analysis activities. It may be tempting to plan to use the same methodology or format for each. However, some practitioners find that each type of analysis is best presented in one format over another.
At this time, the severity of each defect should be addressed. For example, one late receipt of a required input might cost an hour of production if the material is readily available from a nearby warehouse. If, however, there is a chronic and frequent delay, caused by a systemic flaw, those "one hour" delays may amount to a serious problem…and hint at a department-wide problem.
Improve the process to avoid similar mistakes.
The emphasis is on correcting the root cause(s) of the problem.
An important factor is continuing to work with the people involved in the process under study. They may have valuable insights into the problems and potential solutions. They definitely must implement the improvements.
It is possible that various solutions will compete for your attention. It may be necessary to try different pilot changes, and measure their outcomes.The "Improve" phase of a Six Sigma project identifies and implements the improvements to the process. This requires several activities:
This three-step activity is similar to the Root Cause Analysis activity. Open with a brainstorming session to list all possible solutions. Narrow the list by eliminating the solutions which do not fully address the problem. Close this activity by documenting and planning the candidate solution(s).
There is always the possibility that the solution is blindingly obvious: something simple but overlooked. In that case, this activity is quick and painless.
On the other hand, it may become apparent that a combination of expensive or difficult steps is required to solve the problem.
Sometimes the lowliest team members, the department members or the "Yellow Belts", can offer the clearest insights into the solutions.
A formal decision-making process would involve voting on a weighted set of criteria for each solution. Costs, time-lines, and effectiveness would be three criteria to consider. The "How to Choose a Six Sigma Project" article discussed this type of process in some detail. A Pugh matrix uses score values of +1, zero and -1 to indicate "better", "equivalent", or "worse" in each category; then that value is multiplied by the category's weight; and the sum of weighted votes indicates the "best" solution(s).
One class of solution that is sometimes overlooked, but is very effective, is the poka yoke, or "error avoidance", approach. This involves designing equipment or processes that prevent defects, or catch them before they go downstream. A familiar example is the USB connection: it cannot be inserted upside-down, so it prevents an operator from making an error. In manufacturing, a part might be placed into a jig immediately after an operation, to ensure it is the right size and shape; this catches defective work-in-process before it reaches the next process.
This activity starts with planning the required changes. Time-lines, budgets, procurement and training may be involved to greater or lesser degrees. Certainly the Six Sigma team must communicate the type and scope of the changes being envisioned. Plan for the measurements required for the next stage.
The department's leadership must be involved and committed to the solution(s). If they have experience in building up the department, they could make the implementation go relatively smoothly. If they have been caretakers rather than innovators, then the Six Sigma project team would have to carry more of the load.
Even the implementation process should be monitored. Delays or problems during implementation would have a negative effect on the cost/benefit and timeline of the overall project.
Take measurements, much as were taken during the "Measure" phase.
Re-calculate the process sigma, particularly if this project's goal was to reduce the defect rate.
The general rule, of course, is to compare the "before" and "after" pictures of the process. Has it improved? Has it improved to the expected degree?
Control the future state: implement data collection and control systems.
A significant early question is: does the improved process yield the desired goal as stated in the "Define" stage?
Another important question: do the improvements remain?
The Control phase must include processes to request corrective action if problems recur later.
The Six Sigma "Control" phase accomplishes several goals. In this phase, the project team:
Some call this activity "Document the Improvements", but that can be misinterpreted as noting how much better the outputs have become thanks to the project. This activity is more about "project documentation".
The first point is to revise the process map to reflect the implemented changes. Created in the "Improve" phase to illustrate the initial processes, it should now include the actual changes.
Further documentation may be required. These may include new instructions for operating the equipment; revised maintenance schedules; or updated procedures for ordering supplies or receiving customer requests.
Training is usually included to fully implement the revised processes. The ongoing monitoring efforts will also require staff training.
This is the most obvious and visible aspect of "Control". The first step is to specify:
The measurements will probably be a subset of those established in the Measure phase. Why a "subset"? It is likely that this project has determined which metrics are most relevant to the problem under scrutiny; other metrics may not matter much, and be too costly or time-consuming to gather on an ongoing basis. The measurements should, however, be sufficient to determine whether the output is defective.
The discipline of Statistical Process Control is a useful tool for these measurements. By monitoring and analyzing the production process, assignable-cause variations can be noted and corrected.
This monitoring process should begin before the project is closed. The Six Sigma team should mentor the front-line workers to transfer the knowledge of how to perform the monitoring function.
A final task is to document "how to make changes" in the future, such as keeping the process map, procedures documents and monitoring processes in alignment when a process change is made. This is a candidate for the poka yoke, or "error avoidance", approach. Try to design the change process so it is difficult to avoid touching each facet. An example would be an implementation checklist with a sign-off requirement. The checklist would include each type of documentation, and serves as a reminder that they are inter-related.
The major task is to return control fully to the department manager or process owner.
In addition, the project team may have further suggestions based on their observations but outside the scope of the original project charter. These may range from "quick fix" ideas through new Six Sigma projects.
The final reports should include an analysis of the project itself:
By Oskar Olofsson
Making lean work for you
World-Class / Lean Manufacturing
5S Implementation
SMED Quick Change-over
TPM and Plant Maintenance
Succeeding With Standardized Work
Succeeding With 5S