DMAICは、Define、Measure、Analyze、Improve、Controlの5段階で既存のプロセスを改善する手法です。
問題を定義し、現在の状態を測り、原因を分析し、改善策を試し、その効果が続くように管理します。
シックスシグマで使われる代表的な進め方です。

この順序には理由があります。
問題の大きさも原因も確認しないまま対策を決めると、改善したように見えても、偶然の変動や測り方の違いかもしれません。
DMAICでは、問題、原因、対策、結果をデータで結び付けます。

改善対象を測れる形にする

仮に、注文受付から出荷までの時間が長いという問題があるとします。
Defineでは、対象とする注文、時間の起点と終点、顧客が必要とする納期、改善する範囲を決めます。
「物流を効率化する」だけでは、どこまで進めば成功なのか判断できません。

Measureでは、実際の所要時間を記録します。
平均だけでなく、遅い注文の割合や、商品、曜日、注文方法による違いも調べます。
入力時刻と受注確定時刻が混在していれば、分析する前に定義をそろえる必要があります。

Analyzeでは、時間を工程に分解し、遅れがどこで生じるかを確認します。
たとえば在庫不足の注文ほど遅くても、それだけで原因と断定はできません。
注文量や商品の違いなど、別の説明も調べ、現場の観察とデータを照合します。

対策を試し、戻りを防ぐ

Improveでは、原因に対応する対策を小さな範囲で試します。
確認作業の重複が原因なら手順の変更を、情報の欠落が原因なら入力や連携の改善を検討します。
出荷時間が短くなっても誤出荷が増えていないかなど、副作用も評価します。

Controlでは、新しい手順の担当者、確認する指標、異常時の対応を決めます。
改善直後の一度の測定で終えず、注文量が増えた時期にも効果が続くかを追います。
管理の目的は、報告資料を増やすことではなく、悪化を早く見つけて対応できる状態を保つことです。

向く問題と向かない問題

DMAICは、繰り返し発生し、結果を測定できる問題に向いています。
原因が明白な軽微な不具合まで、すべて5段階の大きなプロジェクトにする必要はありません。

また、新製品のように既存の工程がなく、顧客要求から設計し直す場合には、シックスシグマ設計の進め方が候補になります。
既存工程の修正で要求を満たせるのか、設計の前提から変える必要があるのかを先に判断します。

参考資料