プロセスを分析してボトルネックを特定する方法

このガイドは、ProcessMindでプロセスを分析する方に向けて作成しました。紹介する手法は他のツールでも使えます。各ステップでは、作業に使うワークスペース内の画面を具体的に示しているため、抽象的なチェックリストを読み替えずに、手元のデータで分析を進められます。データを見るだけでは、どの結果が重要なのか判断できません。6つのステップで、既存のダッシュボードから、根拠を示して説明できるプロセスのボトルネックまでたどります。

このガイドは、2つの読者を想定しています。プロセスの読み解き方をすでに知っていて、各作業をProcessMindでどう行うか（どの表示、指標、フィルターを使うか）を知りたい方もいます。一方、業務プロセスの分析が初めてで、ツール上の操作を説明できるよう、まず考え方を知りたい方もいます。どちらの方にも、同じ順序で説明します。

始めるために、データエンジニアリングのプロジェクトは必要ありません。すでにあるエクスポートデータで十分です。1イベントにつき1行で、ケース識別子、アクティビティ名、タイムスタンプが含まれていれば始められます。以下の手順はすべてProcessMindのデータセット上で行うため、最初に稼働中のシステムへ接続する必要はありません。

最初は、使いやすいツールさえあれば誰でも十分だと思っていました。しかし、プロセスを自然に読み解ける人もいれば、数値を理解する前に手順が必要な人もいると分かりました。そこで、どちらの方にも役立つガイドを作りました。プロセス分析に慣れている方には、実際に取り組むことと、ProcessMindでの進め方を紹介します。初めての方には、分析を始めるための手順を説明します。どちらの場合も、次の問いを意識してください。何が見えるのか、何を意味するのか、プロセスの改善にどう役立てられるのか。

このガイドでは、その問いに沿って説明を進めます。「何が見えるか」は、ダッシュボードとプロセスグラフで確認します。「何を意味するか」は、時間、バリアント、それらに関わるケースから読み解きます。「どう改善するか」は、その後の判断と、改善の効果を確かめる方法です。

始める前に必要なもの

分析は、最初のグラフを見る前から始まっています。ProcessMindが答えられるのは、データから分かることに限られます。まずは入力データを2分ほど確認してください。

データセットがまだワークスペースにない場合は、イベントログをアップロードし、データセットを設定して、ケース識別子、アクティビティ名、タイムスタンプをProcessMindが正しく読み取れるようにします。コスト、リソース、手戻りの有無などの属性は任意ですが、含めない列に関する問いには後から答えられません。開始前にデータセットの属性を確認してください。必要な項目がエクスポートデータにない場合は、計算属性を使って、既存の列から値を導き出せます。

ダッシュボードから根拠のある分析結果へ

ProcessMindはイベントデータからプロセスを再構成し、指標を計算します。最も待ち時間が長いアクティビティ、ケースの3分の1を占めるバリアント、5件に1件で発生する手戻りなどを表示できます。しかし、どの結果が重要かを判断したり、パターンの理由を説明したり、何を変更すべきかを示したりはしません。このガイドでは、その分析方法を説明します。

多くのチームはすでにダッシュボードを使っています。難しいのは、そこから実際の業務の進み方を説明することです。文書化されたプロセスは意図された経路を示しますが、イベントデータはケースが実際にたどった経路を示します。ProcessMindでは、作成または自動作成したモデルと、そのモデルに対応するデータセットの両方を確認できます。両者を比較することが、プロセスのボトルネックの特定につながります。

データと予想の違いは、結論ではなく問いとして捉えてください。業務は変化し、例外は積み重なり、すべてを記録するシステムはありません。比較によって、どこにボトルネックの可能性があり、調査する価値があるかが分かります。場合によっては、プロセスに対する認識が古くなっていたことにも気付けます。

ProcessMindで分析する6つのステップ

各ステップで1つの問いに答え、次のステップではさらに絞り込んだ問いを扱います。画面名はワークスペースに表示される名称です。6つのステップを順に進めることで、次のデータセットにも使えるプロセスのボトルネック分析の枠組みになります。

1. ダッシュボードを読み解く

   各チャートの指標を確認し、同じ期間とフィルターを設定したプロセスグラフを開きます。

2. プロセスを調べる

   プロセスアニメーションで流れを確認し、一度に1つずつ条件を絞り、プロセスバリアントを比較します。

3. 分析の焦点を絞る

   確認した内容を、データで答えられる3〜5個の問いにまとめます。

4. 適切な画面で詳細を調べる

   各問いをプロセスグラフ、プロセスバリアント、ケースエクスプローラーで検証し、根拠をブックマークします。

5. 分析結果をまとめる

   すべての分析結果を表示、フィルター、数値に結び付け、観察した事実と解釈を分けて記録します。

6. 次の対応を決める

   次の対応の担当者を決め、変更をシミュレーションし、モニタリングの方法を設定します。

ステップ1：ダッシュボードを読み解く

パターンを調べる前に、各チャートが何を測定しているかを確認してください。分かりやすく見えるダッシュボードでも、対象期間、対象データ、計算方法が明示されていないことがあります。プロセスグラフを開くと、同じフィルターが引き継がれます。

各チャートの指標を確認する

ProcessMindでは、時間と件数、手戻り、適合性チェック、プロセスヘルスなど、答える問いごとにチャートをまとめています。まず、知りたいことに合ったダッシュボードを開き、レポートと同じように各チャートを確認します。

• **何を測定していますか？**スループット時間、処理時間、待ち時間、ケース数、その他の指標ですか？
• **数値は何を表していますか？**時間、日数、割合、件数のどれですか？
• **どのケースが対象ですか？**フィルターと、チャートの元になっているデータセットを確認します。
• **どの期間を対象にしていますか？**1か月、1四半期、それともデータセット全体ですか？
• **数値はどのように集計されていますか？**平均値では、極端に速いケースや遅いケースが見えなくなることがあります。

記憶に頼らず、チャートの設定を確認してください。平均値の場合は、その元となる分布も比較します。極端に時間のかかったケースが1件あるだけで平均値が上がり、実際には問題のないプロセスが遅く見えることがあります。

使用する指標の定義を確認する

ProcessMindでは、3つの時間指標を分けて表示します。スループット時間、処理時間、待ち時間は、ケース単位でもアクティビティ単位でも、それぞれ異なる時間を数えるためです。同じ意味だと考えてしまうと、定義の違いから実際には存在しないボトルネックが見つかることがあります。比較する前に、各時間指標の対象を確認してください。

プロセス全体を最初に確認するには、プロセスヘルスダッシュボードを開きます。プロセスをCURESの5つの観点（適合性、均一性、手戻り、効率性、スムーズさ）で評価し、最も低い観点を最初に示します。これにより、「どこから始めるか」という問いを、優先順位の付いた課題に変えられます。

把握しているプロセスに照らして数値を読む

結果を、業務について把握している内容で説明できるか考えてみましょう。ダッシュボードに受注処理の平均処理時間が5日と表示されている場合、実際の業務の進め方と合っていますか。プロセスグラフで想定外の経路をたどるケースが多く見つかった場合、その原因に心当たりはありますか。

食い違いがあれば、そこから調査を始められます。実際のプロセスに問題があるのか、チームごとに業務の進め方が異なるのか、イベントログが不完全なのか、指標の読み違いなのかもしれません。把握していることと、確認が必要なことを書き出しましょう。

数値の背景にあるケースを確認する

グラフを見て疑問が生じたら、ケースエクスプローラーを開き、個々のケースを確認します。傾向がよく表れているケースを選び、イベントを開始から終了まで追ってみましょう。

次の点を確認します。

• 各ケースで記録されたアクティビティ
• アクティビティが発生した順序
• イベント間の長い空白
• アクティビティの繰り返しや想定外の経路
• ダッシュボード上では似ているケース間の違い

記録された順序を、プロセスについての理解と照らし合わせます。システムに記録されていないステップがあるのかもしれません。また、アクティビティ名が実際の業務では別の意味で使われている可能性もあります。個々のケースから傾向の背景が見えてきますが、結論を出す前に複数のケースを確認してください。

把握していることを書き留める

次の内容を簡潔に記録しておきます。

• 各ダッシュボードやグラフで測定している内容
• 適用中のフィルターと対象期間
• 既知のデータ上の制約
• 主要な指標についての解釈
• 追加確認が必要な点

この記録を次回の分析と比較すれば、同僚も内容を確認し、判断の根拠を確かめられます。

ステップ2：プロセスを調べる

ダッシュボードで何が測定されているかを把握したら、特定の説明を証明しようとせずにプロセスを調べます。詳しく確認する価値のある傾向を探し、フィルターとプロセスバリアントを使って、異なるケース群でも同じ傾向が見られるか確かめましょう。

まずはプロセスアニメーションから

プロセスアニメーションでは、ケースが時間の経過とともにプロセスグラフ上を進みます。最初に対象期間とフィルターを設定し、流れを確認しましょう。ケースがアクティビティ間を移動し、待ち時間が発生している箇所に滞留する様子が分かります。

次の点を確認します。

• ケースが滞留するアクティビティ
• ケースが前のアクティビティに戻るループ
• 多くのケースがたどる経路と、少数のケースだけがたどる経路
• ケース群ごとの流れの違い

アニメーションで分かるのは傾向であり、その原因ではありません。次に調べる対象を絞り込むために使い、見つけた傾向を指標やケースで確認しましょう。

一度に1つずつ絞り込む

フィルターを使ってデータを絞り込み、たとえば次のようなグループを比較します。

• 今月と前四半期
• 顧客やケースの種類ごとの比較
• 正常に終了したケースと遅延したケース
• 標準経路をたどったケースと、そこから外れたケース

可能であれば、フィルターは一度に1つずつ変更してください。変更した条件だけを違いの要因として捉えやすくなり、数値の算出方法を尋ねられたときにも、同じ比較を再現できます。

属性ごとにプロセスを分けて見る

ProcessMindでは、データセットの属性ごとにプロセスを分けて確認できます。

• 部門、チーム、担当者
• 地域、拠点
• 製品、サービスのカテゴリ
• 顧客セグメント

全体では一貫して見えるプロセスも、チームやケースの種類によって異なる動きをすることがあります。グループ間の違いは調査の手がかりであり、特定のチームの成績が悪いことを示す証拠ではありません。各グループが比較可能な業務を扱っているか、アクティビティが同じ方法でデータに記録されているかを確認してください。

平均ではなくバリアントを比較する

プロセスバリアントでは、ケースがたどる経路の種類と、それぞれの発生頻度を確認できます。次の点を考えてみましょう。

• 最も多くのケースがたどる経路はどれですか。
• 例外的ではなく、頻繁に発生する逸脱はどれですか。
• 経路ごとに処理時間などの指標はどう異なりますか。
• まれな経路は本当の例外ですか。それとも、繰り返し使われている回避策ですか。

通常、少数のバリアントに大半のケースが集中し、発生頻度の低い例外が長い裾野を形成します。まずは影響するケースが多い経路から確認しましょう。ただし、発生頻度だけで優先順位が決まるわけではありません。まれな経路でも、ケースのコストが高い、または処理に時間がかかる場合は確認が必要です。

説明を仮説として書き出す

調査しながら、考えられる説明を自然な言葉で書き出します。

• 「この地域のケースは、追加の承認が必要なため、処理に時間がかかります。」
• 「この属性を持つケースは、次のアクティビティに進む前に待機します。」
• 「このステップが繰り返されると、ケースの完了までに時間がかかります。」

それぞれの文が仮説です。裏付けとなる証拠と、反証となる情報は何かを考え、フィルター、プロセスバリアント、ケースエクスプローラーで検証しましょう。データで裏付けられるまでは、もっともらしい説明にすぎません。

ステップ3：分析の焦点を絞る

調査を進めると、1回の分析では答えきれないほど多くの疑問が出てきます。プロセスオーナーにとって重要で、データセットで実際に答えられる問いを選びましょう。

繰り返し現れる傾向を見つける

最初の2つのステップで記録した内容を読み返します。

• 複数回現れた傾向はどれですか。
• 意外だったことは何ですか。
• まだ説明が必要な結果はどれですか。
• プロセスの担当者にとって重要な問いはどれですか。
• プロセスの専門家がすでに問題や改善の機会に気づいているのはどこですか。

データが示す内容と、業務を知る人の見解を組み合わせましょう。どちらか一方だけでは全体を把握できません。データからは発生頻度や所要時間が分かり、プロセスオーナーからは、イベントログに記録されない方針や例外、変更について説明を得られます。

分析に適した問いとは

手元のデータセットで答えられる質問を書き出し、漠然とした目標を測定可能なパターンに置き換えます。

• ? Why is throughput time higher for some case types?
• ? Which activities or handoffs account for the most waiting time?
• ? Why do some cases leave the most common variant?
• ? What separates the fastest cases from the slowest?
• ? Where do cases repeat an activity, and how much time sits in those cases?

「プロセスを改善するにはどうすればよいですか」という問いには、データだけでは答えられません。傾向、対象となるケース群、説明したい結果を具体的にすれば、データで検証できる問いになります。

問いを3～5個に絞る

まず調べる問いを3～5個選び、それぞれについて次の点を確認します。

1. **具体的で、次の行動につながる問いですか。**プロセスの領域、ケース群、または測定対象を明確にします。
2. **このデータセットで答えられますか。**必要なフィールドとビューを挙げます。
3. **答えには意味がありますか。**影響を受けるケース数と、結果によって何が変わるかを考えます。
4. **解釈を検証できますか。**確認を依頼できるプロセスオーナーや専門家を挙げます。

焦点を絞った分析は、完了しやすく、説明もしやすくなります。ほかの問いは次回の分析に回しましょう。

期待値をすり合わせる

分析は繰り返し進めるものです。関係者が「その傾向はすでに知っていた」と話す場合もありますが、それも意思決定の根拠になります。一方で、原因を尋ねられることもあります。まだ答えられない場合は、結果を誇張せず、次に調べる問いを示しましょう。

優先する問いに集中し、興味深い発見は追加調査のリストに記録して、調査の焦点がそれないようにします。後から次の分析サイクルに取り組めます。重要な問いから答えることで、関係者が判断するための材料を提示できます。

ステップ4：目的に合ったビューで詳しく調べる

優先する問いごとに、適したビューを選びます。まずプロセス全体を確認し、必要なケースにデータを絞り込み、指定したグループを比較します。傾向の説明が必要な場合は、個々のケースを開いて確認しましょう。

問いに合ったビューを選ぶ

問い	ProcessMindのビュー
どこで時間がかかっていますか。	プロセスグラフで時間の指標を選択
ケースはどこで待機していますか。	プロセスアニメーションと待ち時間のグラフ
ケースはどの経路をたどりますか。	プロセスバリアントと経路フィルター
このケースの動きが異なるのはなぜですか。	ケースエクスプローラー
チームや担当者によって業務はどう異なりますか。	組織の選択項目と担当者のグラフ
この変更によってプロセスはどう変わりますか。	モデルのシミュレーション

証拠を順に確認する

問いごとに、次の手順で進めます。

1. プロセス全体から確認する

   絞り込む前に、すべてのケースで傾向を確認します。

2. フィルターを適用する

   対象期間、ケースの種類、または確認したい結果を絞り込みます。

3. グループを比較する

   問いで指定したケース間の違いを探します。

4. ケースの例を確認する

   ケースエクスプローラーで、傾向の背景にあるケースを開きます。

5. 一貫性を確認する

   結論の根拠となるだけのケースで傾向が確認できるか検証します。

分析中も、最初に設定した問いを意識してください。グラフから興味深い傾向が見つかっても、調査対象の問いに答えるものではない場合は、追加調査のリストに記録します。

分析しながら結果を記録する

有用な結果が見つかったら、次の内容を書き留めます。

• 調査した問い
• 使用したビューと指標
• 適用したフィルターと対象期間
• データが示す内容
• その意味についての解釈
• 今後検証が必要な点

プロセスブックマークを使って、ビュー自体を保存できます。ブックマークを開くと同じフィルターと設定が復元されるため、分析をやり直さずにレビュー中の追加質問に答えられます。

分析を妨げるデータの問題を解消または切り分ける

データの問題によって優先する問いに答えられない場合は、修正できるか、問いの範囲を絞るべきか判断します。タイムスタンプが欠けていると時間の比較は信頼できず、分析を重ねても解決しません。ProcessMindでは、根本的な問題をデータ品質ダッシュボードで確認できます。

その問題が問いに影響しない場合は、記録して分析を続けましょう。すべての分析を終える前にデータ上の制約をすべて解消しようとすると、今必要な答えの精度は上がらないまま、結果が出るのが遅れてしまいます。

プロセスのボトルネックを見つける6つの方法

プロセスのボトルネックとは、プロセス内で業務が進む速度を制限する要因です。ボトルネック分析では、ケースがどこで待機しているか、遅延にどのような傾向が伴うか、何をさらに検証する必要があるかを確認します。多くの場合、6つの方法で主要な点を調べられます。それぞれの問いに対応するProcessMindの画面があります。

アクティビティの処理時間が長いだけでは、それが制約要因だとは言い切れません。ボトルネックと判断する前に、その手前の待ち行列、前後の流れ、影響を受けるケースを確認しましょう。プロセスグラフは、数値と経路を1つの画面で示せるため、プロセスオーナーへの説明にも使えます。

サイクルタイム：どこで時間がかかっているか

**問い：**ケースの処理にどれくらいかかり、その時間はどこで発生していますか。

**ProcessMindで確認する場所：**時間の指標を選択したプロセスグラフと、その内訳を示す分布。

1. ダッシュボードと同じ対象期間、フィルターを設定し、プロセスグラフで平均処理時間または平均作業時間を選択します。
2. アクティビティと接続部分の数値を確認します。作業時間はアクティビティに、待ち時間は2つのアクティビティ間の接続部分に表示されます。
3. 最も長い接続部分と全体の処理時間を比較します。通常、合計時間の大半は少数の接続部分に集中します。
4. 平均値と分布を切り替えて確認します。処理に時間がかかるケースが少数あるだけでも、平均値が大きく変わることがあります。
5. 最も長い接続部分の背景にあるケースを、ケースエクスプローラーで開きます。

次の点を確認します。

• 想定より待ち時間が長い接続部分
• アクティビティ間の長い空白
• ケースの種類、地域、その他の属性による処理時間の違い
• 平均値と分布の大きな差

**注意点：**処理時間が長くても、作業自体が遅いとは限りません。ケースが次のステップを待って数日間滞留している可能性もあります。アクティビティを制約要因と判断する前に、どこで時間がかかっているかを確認してください。

手戻り：ケースが同じステップを繰り返す箇所

**問い：**ケースがアクティビティを繰り返す箇所と、その発生頻度はどの程度ですか。

**ProcessMindで確認する場所：**プロセスグラフ、手戻りダッシュボード、プロセスアニメーション、プロセスバリアント。

1. プロセスグラフで逆向きの接続部分を探します。これが繰り返しのループです。
2. 手戻りのグラフで、再度実行される頻度が高いアクティビティと、繰り返しが発生するケースの割合を確認します。
3. プロセスアニメーションで流れを再生し、ケースが前のアクティビティに戻る様子を確認します。
4. アクティビティを繰り返すケースに絞り込み、そうでないケースと処理時間を比較します。

次の点を確認します。

• ケースが複数回実行するアクティビティ
• 「レビュー、修正、レビュー」のように繰り返される一連の作業
• 手戻りが発生するケースの割合
• 繰り返しの有無による処理時間の違い

**注意点：**繰り返しの中には、適切な確認手順もあります。頻繁な手戻りは、要件の不明確さ、品質上の問題、引き継ぎの問題を示している可能性があります。ただし、イベントデータから分かるのは傾向であり、原因ではありません。実際に業務を行う人に確認してください。

適合性：モデルから外れる経路

**問い：**実際の流れがモデル化されたプロセスと異なる頻度はどの程度ですか。

**ProcessMindで確認する場所：**適合性ダッシュボード、プロセスグラフ、適合性フィルター。

1. モデルを照合の基準として使うため、必要なアクティビティと想定される経路について、プロセスオーナーと合意します。
2. 適合性ダッシュボードを開き、報告された逸脱を確認します。
3. 適合性フィルターを適用し、省略、追加、繰り返しのあるアクティビティを確認します。
4. プロセスバリアントで逸脱した経路を比較し、それぞれの発生頻度を確認します。
5. 各逸脱が許容された例外なのか、記録されていない回避策なのかを確かめます。

次の点を確認します。

• 実行されるはずなのに記録されていないアクティビティ
• 想定外に現れるアクティビティ
• モデルと異なる経路
• 想定された終了イベントの前に終了するケース

**注意点：**逸脱が必ずしも問題とは限りません。承認済みの例外である場合もあれば、文書化する価値のある実務上の回避策である場合もあります。逸脱を不適合と判断する前に、プロセスオーナーに本来のプロセスを確認してください。

担当者：チーム間の業務配分

**問い：**担当者、チーム、部門の間で業務はどのように分配されていますか。

**ProcessMindで確認する場所：**組織の選択項目、担当者のグラフ、フィルター。

1. データセットの組織属性を使い、担当者、チーム、部門ごとにプロセスを分けて確認します。
2. グループごとのケース数と処理時間を比較します。
3. グループ間の引き継ぎを確認します。引き継ぎが発生するたびに、プロセスに待ち時間が加わる可能性があります。
4. 各グループが同程度のケースを扱っているか、業務が同じ方法でデータに記録されているかを確かめます。

次の点を確認します。

• チームや担当者間での業務量の偏り
• チームによる処理時間の違い
• 部門間で繰り返される引き継ぎ
• 少数の担当者に依存するアクティビティ

**注意点：**担当者間の違いだけでは、特定の人やチームの成績が優れているとは言えません。業務の複雑さ、研修、ツール、記録方法が異なる可能性があります。比較結果は、プロセスオーナーへの問いを深めるために使い、個人の評価には使わないでください。

件数と傾向：プロセスはいつ変化するか

**問い：**ケース数は時間とともにどう変化し、それに伴ってパフォーマンスも変化しますか。

**ProcessMindで確認する場所：**期間フィルターと傾向グラフ。

1. 同じフィルターと指標を使い、定義した期間同士を比較します。
2. データセット全体でケース数が増加、減少、横ばいのどれに当たるかを確認します。
3. データが十分にさかのぼれる場合は、前年の同じ期間と比較します。
4. ケース数の変化が処理時間やほかの重要業績評価指標（KPI）の変化と一致するかを確認します。

次の点を確認します。

• ケース数の季節的な傾向
• 既知の業務上の出来事と時期が重なる傾向
• ケース数の変化に伴う処理時間の変化
• 比較可能だと想定していた期間同士の違い

**注意点：**ケース数の変化とパフォーマンスの変化が同時に起きても、ケース数が原因だとは限りません。ほかの変化も調べ、実際に業務を担当した人に時期を確認してください。

経路とバリアント：業務はどの経路をたどるか

**問い：**ケースはどの経路をたどり、それぞれの経路にはどのような違いがありますか。

**ProcessMindで確認する場所：**プロセスグラフ、プロセスバリアント、経路フィルター。

1. プロセスグラフで判断箇所と、そこから分岐する経路を確認します。
2. プロセスバリアントで、各経路をたどるケース数を確認します。
3. 1つのバリアントに絞り込み、ほかのバリアントと処理時間や結果を比較します。
4. プロセスオーナーが想定している経路と、想定していない経路を確認します。

次の点を確認します。

• 一般的な経路と、その周辺にある例外
• バリアントごとの処理時間の違い
• 追加ステップや繰り返しを含む経路
• プロセスオーナーが見直しを希望する経路

**注意点：**まずケース数の多いバリアントを確認し、まれな経路についてはケースにかかるコストも考慮します。発生頻度だけで優先順位は決まりません。経路がもたらす影響も判断材料になります。

ステップ5：分析結果をまとめる

プロセスの担当者が分析結果を理解し、次の対応を判断できるとき、分析は役立ちます。問い、証拠、結論の制約の順に提示しましょう。

分析結果を一定の形式でまとめる

優先する問いごとに、次の5項目を同じ形式で記録します。

1. **問い：**何を調べましたか。
2. **検索対象：**データは何を示していますか。
3. **証拠：**どのビュー、指標、フィルター、ケースが根拠になりますか。
4. **示唆：**プロセスにどのような影響が考えられますか。
5. **次のステップ：**プロセスオーナーは何を検証し、何を判断する必要がありますか。

データが示す事実と、その解釈を分けてください。「このグループのケースは平均処理時間が長い」は観察結果です。「承認ステップが遅延の原因である」は因果関係の主張であり、さらに証拠が必要です。通常は、シミュレーションや変更による検証も必要になります。

関係者が理解しやすい形で提示する

分析の根拠が伝わるよう、レビューを次のように構成します。

1. **要約：**主な分析結果と、必要な判断
2. **方法：**使用したデータセット、対象期間、分析方法
3. **分析結果：**優先する問いごとに1つのセクションを作成
4. **示唆：**分析結果がプロセスに与える可能性のある影響
5. **次のステップ：**検証する内容、検討事項、担当者
6. **補足資料：**グラフ、フィルター、ケースの例

可能であればProcessMindの画面を使って提示しましょう。数値と一緒にフィルターも確認でき、その場で別の切り口を求められた場合にも対応できます。グラフをスライドに書き出す場合は、キャプションに対象期間とフィルターを記載してください。これらがないと、グラフの内容を検証できません。プロセスグラフでは書き出し方法を、カスタムダッシュボードでは会議の目的に合わせたビューの作成方法を確認できます。

影響を慎重に見積もる

データで裏付けられる範囲で、分析結果を業務上の表現に置き換えます。たとえば、処理時間が長いケース群、手戻りが発生するケースの割合、全体の3分の1を占めるバリアントなどです。

測定した内容を正確に伝えましょう。改善の可能性を確実な結果として示してはいけません。変更の効果を見積もる場合は、前提条件を明記し、あくまで推定値であると示します。シミュレーションでは、1つのグラフから推測するのではなく、プロセス上で変更をモデル化し、どのような影響が考えられるかを示せます。

提示前に意見を聞く

次の人たちと分析結果を確認します。

• データを理解している同僚
• 業務の進め方を知るプロセスの専門家
• 解釈が実際の業務に合っているか確認できる関係者

前提に異論がないか、足りないコンテキストがないかを尋ねましょう。レビューによってデータの問題を見つけられます。また、相関関係を因果関係として提示してしまうのを防ぐうえでも、早い段階で確認することが有効です。

ステップ6：次に進む

分析結果を共有したら、次の対応について合意します。プロセスの変更につながる結果もあれば、追加調査やデータセットの改善が必要な場合もあります。決定事項とフォローアップの担当者を記録しましょう。

対応事項を管理する

レビューでは、追加分析の依頼、改善案に関する判断、プロセスオーナーへの依頼事項などが生まれます。それぞれの項目に担当者と次のステップを設定しないと、日々の業務に埋もれてしまいます。

決定する前に変更をシミュレーションする

分析は意思決定を支援しますが、変更を実行するものではありません。ProcessMindでは、次のステップとしてモデル上で変更を試すことができます。What-if分析では、同じデータを使って現状と変更後のシナリオを比較し、プロセスを作り直す前に処理時間への影響を確認できます。エンジンの機能については、シミュレーション機能のページをご覧ください。発見から業務改善までの全体的な進め方については、プロセス最適化の実施方法をご覧ください。

変更の効果を確認する

プロセスを変更したら、変更前後の期間を同じ定義とフィルターで比較します。意図した指標が変化したか、ほかの指標にも変化があったかを確認しましょう。プロセスヘルスは、この比較に適しています。プロセスを継続的に監視する方法では、その進め方を説明しています。

分析内容を文書化する

次の内容を記録しておきます。

• 調査した問い
• 使用したデータセットと対象期間
• 分析に影響したデータ上の制約
• 分析結果とその根拠
• 決定事項、担当者、フォローアップ

記録があれば、次回の分析をより早く進められ、ほかの人も判断の根拠を確認できます。

分析サイクルを繰り返す

プロセス分析は一度きりではありません。新しいデータ、業務の変化、新たな問いがあれば、次の分析サイクルが始まります。そのたびに、分析結果を業務改善やビジネス最適化につなげる機会が生まれます。問いを絞り、分析結果と根拠を一緒に記録しておけば、回を重ねるごとに効率よく進められます。

ProcessMindを始める

すでにお持ちのエクスポートデータで、この方法を試せます。ProcessMindにデータを読み込むと、データセットが作成され、プロセスが可視化されます。また、上記の手順で使うダッシュボード、プロセスグラフ、ケースエクスプローラーも利用できます。ブックマークで表示内容を保存し、プロセスの担当者と共有することもできます。

初回の設定は、はじめにをご覧ください。ここで説明する手順にコネクターは必要ありません。

プロセスの流れを理解するには、イベントデータからプロセスがどのように可視化されるかを説明したプロセスマイニングとはをご覧ください。この分析を組み込む、より広範な取り組みについてはデータドリブンなプロセス改善の戦略ガイドで、関連する手法の比較についてはプロセス改善手法：完全ガイドで解説しています。

Where to Go From Here

分析の進め方と、確認したい質問が整理できました。次は実際のデータで分析し、何を変更するか、効果をどう確認するかを検討しましょう。

• Reproduce the analysis on your own export
• Set the analysis up so it survives a review

Start your free trial with ProcessMind