process-excellence

プロセスの卓越性

業務上の問題の原因を特定し、プロセス全体に効果のある改善策を設計します。質問と証拠に応じて、リーン、シックスシグマ、またはより簡易な診断方法を使います。分析範囲が限定的であれば、DMAICの成果物をすべて作成する必要はありません。

範囲、顧客要件、意思決定、利用可能なデータ、ユーザーが求める成果物を明確にします。提供されたベースラインと定義に基づいて作業します。データが不完全な場合は、限界を明示したうえで暫定的な診断または測定計画を提示します。ベースラインを捏造したり、ドラフトの作成前に実務上の承認を必須としたりしてはいけません。ただし、運用上のリスクに応じて、実行時の承認プロセスや段階的な導入は引き続き重要です。

実際の業務を測定する

開始イベントと終了イベント、作業単位、対象ケース、期間、および所要時間に待ち時間、営業時間外、手戻り、未完了ケースを含めるかどうかを定義します。実作業時間と経過時間を分けます。平均値を信用する前に、イベントの欠落や重複、タイムゾーン、選択バイアス、未完了ケースを確認します。

証拠に基づいて、フロー、意思決定、キュー、引き継ぎ、例外をマッピングします。SIPOCで範囲を明確にし、バリューストリームマッピングで待ち時間や在庫を明らかにできます。意思決定に役立つ深さでマッピングしてください。並列処理の能力、バッチサイズ、需要が異なる場合、平均所要時間が最も長い工程だけを根拠にボトルネックを推定してはいけません。

イベントログ、工程能力、管理図、フロー指標には、測定および統計手法を使用します。統計ツールは、その前提とデータが適切な場合にのみ適用してください。パフォーマンスが不明だからといって、シグマレベルが低いと判断してはいけません。

原因を検証し、改善策を設計する

観察、プロセスデータ、インタビュー、パレート分析、フィッシュボーン図、繰り返し「なぜ」を問う手法を使って、検証可能な仮説を立てます。疑われる原因と、検証済みの原因を区別します。「ヒューマンエラー」の背後に設計や管理上の問題が隠れている可能性があります。チームが制御できないという理由だけで、外部要因を除外してはいけません。

待ち時間、手戻り、不要な移動、過剰な作業、在庫、重複処理、未活用の能力を、状況に応じて評価します。目的や義務を理解しないまま、管理策や一見付加価値のない工程を取り除いてはいけません。一つの工程を最適化する前に、下流への影響と制約を確認します。

実行可能な変更を、影響、コスト、サービスリスク、定着性、可逆性で比較します。重要な変更では、パイロット、ベースラインとの比較、成功基準、中止またはロールバックのトリガーを定義します。リスクの低い改善では、形式的な承認プロセスではなく、リスクに見合った検証を行います。

二重計上せずに定量化する

数量、時間、単価、品質、実際のコスト変化に基づいて、財務効果を算出します。創出された労働力の余力と、支出の削減を分けます。スループットの増加が収益につながるのは、需要と下流の処理能力がそれを許容する場合に限ります。適切な場合は、増分利益貢献とキャッシュを使います。サービス品質、リスク、非財務的な成果が変更の目的である場合は、それらも明示します。

ROIと投資回収期間について、対象期間と含めるコストを明記します。その期間の純ROIを(benefits-costs)/costsで計算し、導入コスト、継続コスト、効果が現れるまでの期間を示します。同じ改善を労務費の削減と再配置可能な余力の両方として計上してはいけません。

定着させ、成果を届ける

運用上の責任者、改訂された標準作業、モニタリング、パフォーマンスが悪化した場合の対応を定義します。管理限界は観測されたプロセスの変動を示し、規格限界は要件を示します。両者を混同してはいけません。

求められた分析、改善計画、マップ、または管理設計を提供します。証拠、残る不確実性、推奨する変更、期待される効果、診断を否定する根拠となる事柄を説明します。実際に導入する場合は、既存の運用プロセスを通じて、トレーニング、責任者、サポート、関連する承認を確認します。計画を作成しただけの場合に、パイロットや改善が完了したと報告してはいけません。