標準的なプロセスマイニング分析手順
プロセスマイニングツールを活用して、どのように対象プロセスの分析を行っていくのかについて、標準的な手順を解説します。
以下の点、あらかじめご留意ください。
・分析を行う流れは直線的なものではなく、基本的には、様々な分析の切り口を行ったり来たりする繰り返し作業を通じて深めていくものです。とりわけ、大量、かつ複雑なイベントデータからの分析から、新たな知見を引き出そうとするプロセスマイニング分では試行錯誤が不可欠です。「こうやれば新たな知見が発見できる」という分析の必勝パターンは存在しません。
活用する分析ツールによって機能には違いがあります。また、機能に対する名称も異なります。当記事では一般的な表現を用いています。利用されているツール独自の表現については、機能的に類似なものに読み替えてください。
さて、基本的なプロセスマイニングの分析手順は次の通りです。
1 分析対象プロセスに関する統計数値の確認
2 バリアント分析
3 頻度分析
4 パフォーマンス分析
5 リワーク分析
6 問題点検討会開催
7 根本原因分析
8 改善施策の立案
9 改善プロセスモデル作成/改善効果シミュレーション
1０ レポート作成
それでは、各手順の分析内容を概説していきます。
なお、 データ前処理済の「イベントログデータ」をプロセスマイニングツールにアップロードし、分析項目の紐づけ（マッピング）を行い、分析準備は完了しているものとします。
1 分析対象プロセスに関する統計数値の確認
プロセスマイニングツールの分析実行ボタンを押して分析スタートです。デフォルト画面はツールによって異なりますが、まずは分析対象プロセスに関して、以下のような基本的な統計数値が表示されている画面を確認します。データの概要を把握するためです。
- 分析対象案件数（ケースID数）
- 完了案件数・未完了案件数
- 分析対象アクティビティ数（延べアクティビティ数）
- 案件あたり平均/最多/最少アクティビティティ数
- アクティビティ別発生件数
- 分析対象期間(FROM: yyyy/mm/dd TO: yyyy/mm/dd)
- 平均/最長/最短/中央/最頻度スループット（時間表示）
- スループット分布（ヒストグラム）
- スループット標準偏差
上記の数値を確認する際の一番の留意点は、「完了案件のみを分析するかどうか」の判断です。完了案件とは、分析対象期間内において、「開始アクティビティ」と「終了アクティビティ」の両方が含まれているものを意味します。
問題が実際のイベントログでは、期間前に開始アクティビティが始まっていたり、また、分析期間内に「終了アクティビティ」に到達していない案件が含まれています。これらの「未完了案件」をそのままにしておくと、スループットの算出に問題が生じます。
基本的にはフィルター機能を活用して、分析期間内に「開始アクティビティ」と「終了アクティビティ」の両方が含まれているものだけを分析対象とする設定をこの時点で行いましょう。（もちろん、分析目的によっては未完了案件を分析対象とすることもあります）
また、スループットについては、平均、最多、最少、中央、最頻度の数値だけでなく、ヒストグラムによる分布状況を確認しましょう。プロセスデータの場合、正規分布しているケースはほとんどありません。
また、山が複数存在する「多峰型」のヒストグラムの場合、同じプロセスではあっても、すべてのプロセスを経由する案件と、なんらかの条件で途中のプロセスを省略した簡易プロセスの案件がごっちゃになっている可能性があります。（これは、次のバリアント分析で明確に識別すべきポイントです）
2 バリアント分析
分析対象プロセスの流れは、ビジネスルールによる分岐（たとえば、ローンの申請結果に基づいて、その後の流れは、承認と非承認の２つの流れに分かれるなど）や、前工程への差戻しや、繰り返し業務、逸脱などのアクティビティが存在することによって複数のパターンが発生します。
つまり、開始アクティビティから終了アクティビティまでの経路には様々なバリエーションがあるということです。バリアント分析では、このバリエーションそれぞれを確認することを通じて、典型的な流れや、逸脱が含まれるパターンの発見を行います。
バリアント分析でまず着目するのは、最も案件数の多いプロセスパターンです。このプロセスを「ハッピープロセス」、または「ハッピーパス（経路）」と呼ぶ場合もありますが、処理案件数が多いからといって必ずしもそれが最も理想的なプロセスとは限りません。
そこで、プロセスオーナーやドメインエキスパート（現場担当者）に確認して、そもそも問題のない理想的なプロセス＝ハッピープロセスが何かを確認します。
また、ビジネスルールなどによって、途中から流れが大きく分岐するプロセスパターンが複数存在する場合、それぞれのパターンごとにもハッピーパスが存在すると考えられます。
一方で、上記理想プロセスに照らして逸脱していると考えられるプロセスパターンを洗い出し、記録に残しておきます。これらは問題点として提起すべきものになります。
なお、逸脱プロセスの発見のためにさらに「コンフォーマンス分析」を行うことも有効ですが、これは標準ではなく応用分析と位置付けています。
3 頻度分析
プロセスモデル、すなわちプロセスの流れを示したフローチャートの表示画面において標準的に示されている数値が、プロセスに含まれる各アクティビティの処理件数や、あるアクティビティから別のアクティビティに流れた件数です。
これらの処理件数を細かく検証していくのが頻度分析です。着目ポイントとしては、もちろん処理件数の多い箇所です。処理件数が多いということはそれだけ、現場担当者の負荷が大きく、処理時間が長くなったり、案件が滞留するボトルネックが発生しやすい箇所になるからです。
4 パフォーマンス分析
パフォーマンス分析は、基本的に「時間」尺度の分析です。プロセスの開始アクティビティから終了アクティビティまでの総所要時間（トータルリードタイム）、すなわちスループット、および、各アクティビティの処理時間、あるアクティビティから別のアクティビティまでの移行時間＝待ち時間などをつぶさに見て、時間がかかりすぎている非効率な箇所、待ち時間が長い「ボトルネック」を発見します。
パフォーマンス分析において重要なのは、時間が長い・短いを判断するための基準値を明確にしておくことです。たとえば、スループットの場合、平均、または中央スループットを基準にして、それよりも長いプロセスにおいては、「全体的に時間がかかりすぎている」という問題があるとみなします。
また、各アクティビティごとの処理時間や待ち時間についても、平均値または中央値を基準値として設定するか、また、本来、この程度の時間であるべきというKPI（Key Performance Indicator）の目標値に照らして問題点を抽出することが有効です。
5 リワーク分析
リワーク、すなわち繰り返し業務は少ないほうが好ましく、リワークが発生している箇所には、非効率な手順や、リワークを誘発しやすい問題が潜んでいる可能性があります。
リワークには、大きくは、あるアクティビティが繰り返し行われている場合と、複数のアクティビティの流れが繰り返されている場合の２つがあります。前者は単純なエラーや反復業務が含まれている可能性、また後者は「手戻り」が発生しているということですから、ここにもなんらかの原因が存在しています。
リワーク分析で浮き彫りになった問題個所もまた、次の「問題点抽出」のひとつとして根本原因追求を行うことになります。
6 問題点検討会開催
バリアント分析、頻度分析、パフォーマンス分析、リワーク分析を通じて抽出した問題点を列挙して、関係者による検討会を行います。
プロセスオーナー、およびドメインエキスパート（現場担当者）に、分析結果を示しつつ、以下のような問題と想定される箇所についての確認を行います。
- 特定のアクテイビティやフローにおいて処理件数が多くなっている原因
- スループットが基準値よりも長い（あるいは短い）プロセスとなる原因
- 基準値よりも、アクティビティの処理時間や待ち時間が長い箇所が発生する原因
- 標準的な手順には含まれていない逸脱手順、あるいは省略されている手順が発生している理由
- リワークが発生している理由
プロセスオーナーやドメインエキスパートに確認した結果、逸脱手順と想定されたが現実には所定の手順であったとか、ある箇所において処理時間が長くなるのは現実に照らして問題がない、という判断になることもあるでしょう。
プロセスマイニング分析であぶりだされる問題は、あくまで現象としての問題ですから、それが本当に企業に悪影響を与える問題であるのか、また是正すべきなのか、また是正可能なのか、ということを判断するためには、現実のプロセスをよく理解している関係者へのヒアリングを通い、「解決すべき本当の問題」のみを残していくことが不可欠です。
7 根本原因分析
問題点の検討に続いて、根本原因を解明していくための深堀り分析を行います。プロセスマイニング分析においては、様々な属性によるクロス分析を通じて、問題の手がかりを探ります。
どのような属性による分析を行うべきかは対象プロセスによって異なりますが、一般的には以下のような属性分析が有効です。
- サプライヤ別
- 顧客（タイプ）別
- 製品別
- 資材別
- 調達部門別
- エリア別
- 調達金額別
- 受注金額別
たとえば、購買プロセスにおいては、どのサプライヤの場合に、あるいはどの資材調達の場合にリワークが発生しやすいのか、また、どのような条件においてビジネスルールが適用されるのか、そのビジネスルールは適切に運用されているのか、といった分析を行うことで根本原因に近づいていくことはできます。
ただ、最終的に現場担当者の手作業が非効率の原因となっているような場合、イベントログでは記録されていない業務であるため、データ分析だけでは真因に迫ることはできません。
したがって、根本原因分析においては、現場担当者のヒアリングやワークショップ、観察調査などを併用して、データ有無にこだわらず、根本原因を探るためのあらゆる手段を講じることが必要になるでしょう。
8 改善施策の立案
解決すべき本当の問題、およびその問題の根本原因が明らかにできたら、いよいよ改善施策を立案を行います。改善施策案の原案は、たとえばプロセスアナリストやビジネスコンサルタントが作成しますが、どの改善施策が有効であるのか、また最優先で取り組むべきなのかは、プロセスオーナーやドメインエキスパートを含む検討会で決定すべき事項です。
なお、どのようなプロセス改善を行うかは当然ながらケースバイケースですが、標準的なアプローチとしては以下のようなものがあります。
- 業務手順の組み直し
- 問題アクティビティの除去
- アクティビティの統合
- 複数アクティビティの並行処理化
- 人員配置の適正化
- 自動化
9 改善プロセスモデル作成・効果シミュレーション
取り組むべき改善施策が立案されたら、その改善施策が実施された場合の「改善プロセス」を作成し、可能な範囲でシミュレーションを行います。現行プロセス（as isプロセス）と改善プロセス（to beプロセス）でどの程度、処理件数が軽減できたり、所要時間やコストが削減できるかを検証するわけです。
なお、改善プロセスの作成は、モデリングツールを用いて「BPMN準拠」のフローを作成すべきでしょう。プロセスマイニングツールのなかには、BPMN準拠のモデリング機能が含まれているものがあります。含まれていない場合は、別途モデリングツールを準備することになります。
10 レポート作成
これまでの分析内容や、改善施策案に基づく改善プロセス、およびその効果検証シミュレーションの結果を取りまとめてレポートを作成します。レポートの一般的なタイトルは
「XXXプロセスのプロセスマイニング分析レポート – 問題点と解決策」
といったところです。
なお、分析プロジェクトの目的や状況によって、改善施策の立案の前の段階まで、すなわち問題点の抽出までのレポート作成になる場合もあるでしょう。