DMAIC is an abbreviation of the five improvement steps it comprises: Define, Measure, Analyze, Improve and Control. All of the DMAIC process steps are required and always proceed in the given order.

The five steps of DMAIC

Define[edit]

The purpose of this step is to clearly articulate the business problem, goal, potential resources, project scope and high-level project timeline. This information is typically captured within project charter document. Write down what you currently know. Seek to clarify facts, set objectives and form the project team. Define the following:

A problem The customer(s) Voice of the customer (VOC) and Critical to Quality (CTQs) — what are the critical process outputs? The target process subject to DMAIC and other related business processes Project targets or goal Project boundaries or scope A project charter is often created and agreed upon during the Define step.

Measure[edit]

The purpose of this step is to objectively establish current baselines as the basis for improvement. This is a data collection step, the purpose of which is to establish process performance baselines. The performance metric baseline(s) from the Measure phase will be compared to the performance metric at the conclusion of the project to determine objectively whether significant improvement has been made. The team decides on what should be measured and how to measure it. It is usual for teams to invest a lot of effort into assessing the suitability of the proposed measurement systems. Good data is at the heart of the DMAIC process:

Identify the gap between current and required performance. Collect data to create a process performance capability baseline for the project metric, that is, the

process Y(s) (there may be more than one output). Assess the measurement system (for example, a gauge study) for adequate accuracy and precision. Establish a high level process flow baseline. Additional detail can be filled in later.

Analyze[edit]

The purpose of this step is to identify, validate and select root cause for elimination. A large number of potential root causes (process inputs, X) of the project problem are identified via root cause analysis (for example a fishbone diagram). The top 3-4 potential root causes are selected using multi-voting or other consensus tool for further validation. A data collection plan is created and data are collected to establish the relative contribution of each root causes to the project metric, Y. This process is repeated until "valid" root causes can be identified. Within Six Sigma, often complex analysis tools are used. However, it is acceptable to use basic tools if these are appropriate. Of the "validated" root causes, all or some can be

List and prioritize potential causes of the problem

Prioritize the root causes (key process inputs) to pursue in the Improve step Identify how the process inputs (Xs) affect the process outputs (Ys). Data is analyzed to understand the

magnitude of contribution of each root cause, X, to the project metric, Y. Statistical tests using p-values accompanied by Histograms, Pareto charts, and line plots are often used to do this.

Detailed process maps can be created to help pin-point where in the process the root causes reside, and what might be contributing to the occurrence.

Improve[edit]

The purpose of this step is to identify, test and implement a solution to the problem; in part or in whole. Identify creative solutions to eliminate the key root causes in order to fix and prevent process problems. Use brainstorming or techniques like Six Thinking Hats and Random Word. Some projects can utilize complex analysis tools like DOE (Design of Experiments), but try to focus on obvious solutions if these are apparent.

Create innovative solutions Focus on the simplest and easiest solutions Test solutions using Plan-Do-Check-Act (PDCA) cycle Based on PDCA results, attempt to anticipate any avoidable risks associated with the "improvement"

using FMEA Create a detailed implementation plan Deploy improvements

Control[edit]

The purpose of this step is to sustain the gains. Monitor the improvements to ensure continued and sustainable success. Create a control plan. Update documents, business process and training records as required.

A Control chart can be useful during the Control stage to assess the stability of the improvements over time by serving as 1. a guide to continue monitoring the process and 2. provide a response plan for each of the measures being monitored in case the process becomes unstable.

1) Define. L-3 CSW does not have a way to track configurations delivered. This affects consistent performance in the field, risk of legal action and allows SRA (Special Repair Activity) to better service the customer and reduce re-work in the factory diagnosing the product, which has higher priority than new product. Currently the process is for the product being returned is assigned to System Engineering and System Test Engineering to

do the current test procedure to determine what failed and what needs to be upgraded. The System Engineer then reviews the Engineering changes and suggests a BOP to address the problem. No record is kept in one place to determine what was applied to the returned equipment. This project is to combine the past history of all the hardware in the hardware as shipped from the factory initially and record changes when it is returned for repair or upgrade. This was not available. The chart above if a solid line was implemented for the project. Dotted indicates Phase 2 which was funded but never completed.

2) Measure :

This will solve a major hole in the whole configuration tracking of the life cycle of a part (IT manager CSW). One half the time on the floor is used to characterize the repaired item. Taking up production equipment and human assets as it is not recorded in one easily accessible data base. The hierarchy is not known due to assembly recording disconnects, available to a large factory staff. It also saves records that are easily reportable to the customer so they can place orders for the upgrades they did not get during early production units. This will reduce the turn around time from a 6-18 month period to the targeted 45 days.

3) AnalyzeThe root cause is the quantity demand on the production floor. As an example. Global Hawk, a DARPA project was pushed into service after 9-11 and put into service and production reducing the lead time needed to one third of the prototypes. What took 18 months to produce, now required only 6. The government

required repairs to be first priority over new build production. They also required that a record be kept of each system configuration. These records were kept in various places, but not linked to a family tree for each system. This caused a bottleneck as the repairs started coming back and a “trial and error” system was used to determine what had been shipped initially or after a repair. Pressure on the floor test and repair assets were stressed as this iterative diagnosis system was used. This was complicated by the fact that L-3 allowed their customers to pick and choose the Engineering Changes they wished to put into any given assembly part number. A dash revision gave you the last full compliment of Engineering changes when shipped, but partials were more common after it returned for repair and upgrade. A partial dash was common and not accessible. A full engineering change order implementation record was needed. To do this several data bases needed to be linked and easily available to decision makers.

4) Improve.

5 data input programs data bases needed to be combined. A cross functional team comprising of the owner of each data base and program needed to work together to produce an easily searchable master source. A training course was developed. The summary of the data base is shown below. The hierarchy can be shown by picking an anchor part number in the table, or placing it in the search function. Exploding above and below that part in the deliverable system and each part's configuration is a double click away. Program managers found easily fielded parts that needed upgrade and which aircraft they were installed in.

5) ControlTurnaround time was reduced to the required 45 days where implemented. If TAT drifted up, a review of the processes the part was going through would indicate if the repairs were based on the S/N Hierarchy record or if an iterative record was redundantly used. Using the database tool, a part that isn’t functioning as expected could potentially stay in the field and have a field upgrade sent to them.

SUMMARY PAGE:This is an IT spotlight page on the INTRANET shortly after the release of the tool. Unfortunately about a third of the target audience took the course and training was given word of mouth. The record is still used today even after Siemens’ SAP was implemented. It helped a number of people, mainly program managers give their customer a record of what was in their systems and what was needed. It saved them weeks of time. Those that used it couldn’t live without it.

Voice of the customer and stock holders.

With this tool, a summary of the Engineering changes this encoding feature requires can be quickly compiled and reported. Without it, and having nearly hundreds to upgrade, difficult to report comprehensibly.