プロセスマイニングとは?業務の実態を明らかにする方法
プロセスマイニングとは何か、仕組みや3つの種類、主な用途、始め方をわかりやすく解説します。
プロセスマイニングとは?
**プロセスマイニングとは、ITシステムのイベントデータをもとに、業務プロセスの実際の流れを可視化し、分析・改善する手法です。**アクティビティを案件やタイムスタンプと結び付けることで、業務の経路や各工程にかかる時間、想定との違いが明らかになります。
イベントログには、アクティビティ、タイムスタンプ、案件を識別するIDが記録されます。プロセスマイニングでは、イベントを案件ごとにまとめ、プロセスの流れを再構成します。その結果を使って、ボトルネックや手戻り、参照プロセスとの適合性を調べられます。分析結果は判断の根拠となりますが、どう対応するかはチームが決めます。
プロセスマイニングソフトウェアについて詳しく知りたい方は、プロセスマイニングツールのガイドをご覧ください。
プロセスマイニングの先駆者であるWil van der Aalstは、これを企業のMRIにたとえています。表面の下で何が起きているかを明らかにできるという考え方です。こうした可視化は、プロセス改善やデジタルトランスフォーメーションに役立ちます。データに基づくプロセス改善の戦略ガイドもご覧ください。
顧客の注文が、受付と承認を経て出荷される場面を考えてみましょう。各ステップはデジタル記録として残る場合があります。プロセスマイニングでは、これらの記録をつなぎ合わせ、寄り道や例外も含めて、注文ごとにたどった経路を示します。インタビューや推測だけに頼らず、データに記録された経路を確認できます。
分析結果は、イベントデータの品質と、その背景にあるコンテキストに左右されます。プロセスマップは想定された経路を示し、プロセスマイニングは記録から実際に何が起きたかを明らかにします。
プロセスマイニングの仕組み
プロセスマイニングは、ITシステムのイベントデータを使って分析します。通常、各イベントには次の3つの項目が必要です。
- **ケースID:**注文やサポートチケットなど、プロセスの実行単位を識別するIDです。
- **アクティビティ:**実行されたステップです。
- **タイムスタンプ:**そのステップが実行された日時です。
ソフトウェアはケースIDごとにイベントをまとめ、タイムスタンプ順に並べます。次に、各案件がたどった経路を再構成し、プロセスモデルとして提示します。経路を比較し、所要時間を確認して、ステップの繰り返しや長い待ち時間などのパターンを調べられます。
結果の品質はデータに左右されます。タイムスタンプの欠落、アクティビティ名の不統一、誤ったケースIDは、分析結果を歪める可能性があります。プロセスデータの入手先と、対応しているデータ形式をご確認ください。
プロセスマイニングの3つの種類
プロセスマイニングの3つの種類は、それぞれ異なる問いに答えます。
-
プロセスディスカバリーでは、イベントログのデータからプロセスモデルを作成します。文書化されていないバリアントも含め、案件が実際にたどる経路を確認できます。
-
適合性チェックでは、実際のプロセスの動きと参照モデルを比較します。案件が想定されたステップに従っている箇所、ステップを省略している箇所、逸脱している箇所を見つけられます。
-
プロセスエンハンスメントでは、イベントログの情報を既存のプロセスモデルに追加します。たとえば、待ち時間やアクティビティの所要時間などのパフォーマンス指標を加え、プロセスの状況を把握できます。
プロジェクトでは、まずプロセスディスカバリーを行い、次に適合性チェックで参照プロセスとの違いを調べることがよくあります。プロセスエンハンスメントでは、モデルにパフォーマンスの情報を加えられます。答えたい問いに合った手法を選びます。
誰でも始められるプロセスマイニング
プロセスデータの分析を始めるのに、データサイエンティストである必要はありません。アナリスト、プロセス責任者、オペレーションチーム、ITチームが協力し、問いを決め、イベントログを準備して、分析結果を確認できます。
まずは次の手順から始めます。
- 対象のプロセスと具体的な問いを決めます。
- アクティビティを記録しているシステムデータを特定します。
- ケースID、アクティビティ名、タイムスタンプを含むイベントログを準備します。
- 明らかになったフローを確認し、重要な経路を詳しく調べます。
- 業務を理解している人に分析結果を確認してもらいます。
プロセスマイニングの5つのステップ
データを収集する
受注から入金までの各ステップの記録など、システムからイベントデータを集めます。最初はExcelファイルだけでも始められます。
プロセスを把握する
プロセスマイニングソフトウェアで、ケースIDと時刻をもとにイベントをつなぎ、データに表れたプロセスフローを確認します。
適合性をチェックする
把握したプロセスをBPMNモデルなどの参照モデルと比較し、違いを調べます。
結果を分析する
プロセスダッシュボードで、ボトルネックや手戻り、非効率な箇所を調べ、さらに調査または変更する対象を決めます。
変更をモニタリングする
変更後にプロセスを再確認し、パフォーマンスや経路がどう変わったかを把握します。
はじめ方の手順を確認し、最初の分析に向けて準備しましょう。
プロセスマイニングとプロセスマッピングの違い
プロセスマイニングとプロセスマッピングは、関連しながらも異なる問いに答えます。プロセスマイニングではイベントデータから、プロセスが実際にどう進んだかを確認します。プロセスマッピングでは、関係者の知識やプロセス設計の手法を使い、業務のあるべき姿を文書化したり計画したりします。
| プロセスマイニング | プロセスマッピング | |
|---|---|---|
| データソース | ITシステムのイベントログデータ | インタビュー、ワークショップ、文書 |
| 出力 | 記録されたイベントに基づくプロセスの動き | 文書化または設計されたプロセス |
| 作業量 | データへのアクセスと準備によって異なる | 対象範囲と関係者からの情報提供によって異なる |
| 対象範囲 | イベントログに記録された経路を確認できる | 関係者が文書化した内容によって異なる |
| 適した用途 | プロセスの実際の動きを把握する | プロセスを設計または文書化する |
この2つの手法は、組み合わせて使うと効果的です。プロセスマイニングでデータが示すプロセスを調べ、プロセスマッピングやBPMNモデリングで変更を文書化または設計します。ProcessMindでは、プロセスマイニングとプロセスマッピングを1つのプラットフォームで利用できます。両者を組み合わせるメリットについては、プロセスモデリングとプロセスマイニングを組み合わせる価値をご覧ください。
プロセスマイニングのアルゴリズムの仕組み
プロセスマイニングのアルゴリズムは、イベントデータからプロセスモデルを作成します。公開されている研究では、いくつかの種類が紹介されています。alpha algorithmはアクティビティ間の関係を導き出す古典的な手法です。heuristic minerはノイズや不完全なログを許容し、fuzzy minerは構造化されていない動きを扱います。inductive minerは、健全性が保証されたプロセスツリーを作成します。それぞれ対象とするログが定義されており、その定義に基づくモデルを出力します。
ProcessMindには、独自のマイナーが3種類あります。モデルをマイニングダイアログでいずれかを選択します。描画結果の厳密さを決めるゲートウェイポリシーも同じ画面で設定できます。詳しくはマイニングのドキュメントをご覧ください。
| マイナー | 出力される内容 | 適した用途 |
|---|---|---|
| Directly-Followed-By miner | 各アクティビティを、その直後に続くアクティビティにつなぐフラットなモデル。サブプロセスの入れ子はありません | ログの内容を加工せずに確認したい場合や、データに何が含まれているかを調べたい場合 |
| Simple Miner | グラフの密集した部分を再帰的に分解し、入れ子状のセグメントにしたモデル | 1画面に収まる簡潔なモデルが必要な場合 |
| AI Miner | エンリッチメントデータに基づいてAIが分解し、並行する領域を検出して描画するモデル | ログが不完全または複雑な場合や、フラットなモデルでは表現できない並行作業がある場合 |
AI MinerはProcessMind独自のもので、公開済みのアルゴリズムを再実装したものではありません。イベントログとともにエンリッチメントデータを読み込み、並行する領域を検出してグラフを階層的に分解します。そのため、ログが示す構造を平坦化せずにモデルに反映できます。この点がAI Minerの特長です。公開されているアルゴリズムの定義では、整然とした完全なログが前提となっていますが、多くの組織が扱うエクスポートデータは、その条件を満たしません。AI Minerは、定義上求められるデータではなく、実際に手元にあるデータで役立つように開発しました。3種類のうち、エンリッチメントデータが必要なのはAI Minerだけです。そのため、新しいログを使う場合は、まずDirectly-Followed-By minerで分析し、結果を比較するのが適切です。
マイナーが構造を作成した後、レイアウトアルゴリズムがフローを読みやすく配置します。この処理はProcessMindのClarity Engineが担います。
プロセスマイニングが役立つ理由
プロセスマイニングを使うと、プロセスの説明や少数の事例だけに頼らず、記録された案件全体から業務の流れを確認できます。次のような点に役立ちます。
- **プロセスのバリアントを把握する:**案件ごとの経路を比較し、よくある経路や珍しい経路を特定します。
- **遅延を調べる:**案件がどこで待っているか、どのアクティビティに時間がかかっているかを確認します。
- **手戻りを見つける:**エラーや要件の不明確さを示す可能性がある、アクティビティの繰り返しやループを探します。
- **適合性を確認する:**実際の動きと参照プロセスを比較します。
- **パフォーマンスを追跡する:**ダッシュボードと重要業績評価指標(KPI)で、時間の経過に伴うプロセス指標を確認します。
分析結果は、より適切な問いを立てるのに役立ちます。ただし、遅延や逸脱が起きた理由を証明するものではありません。変更を決める前に、関係者に話を聞き、関連するコンテキストを確認してください。
プロセスダッシュボードと重要業績評価指標(KPI)を使ったパフォーマンスの確認方法をご覧ください。
プロセスマイニングの長所と課題
長所
プロセスマイニングを使うと、誰かの記憶を頼りに再構成しなくても、業務の客観的な姿を確認できます。
- ログに含まれるすべての案件の動きを示すため、誰かが覚えている少数の事例だけに頼りません。
- フローや遅延、手戻りが図で示されるため、原因を調べる時間を短縮できます。
- ITシステムに構造化されたイベントデータが残るプロセスであれば、分析できます。
- プロセスダッシュボードを使えば、アナリストだけでなく業務チームも分析結果を確認できます。
課題
分析結果の精度はログの品質に左右され、ログの準備には作業が必要です。
- データの品質が低いと、もっともらしくても誤った答えが導かれます。分析の信頼性はイベントログの品質に左右されます。
- プロジェクトでは、データの準備と確認が最も手間のかかる作業になることがよくあります。
- プロセスマイニングでプロセスが改善されるわけではありません。調査すべき点は明らかになりますが、判断して変更するのは人です。
- 複雑なモデルは読み解くのが困難です。まずは明確な問いを1つ立て、その問いに関係する経路に絞りましょう。
見過ごせない点
証拠を不適切に扱うと、かえって問題を招きます。
- プロセスデータを個人の責任追及に使うと、恐れや反発を招きます。個人ではなく、プロセスの条件に目を向けましょう。
- データを誤って読むと、誤った結論につながります。業務をよく知る人と一緒に、分析結果を確かめてください。
- ツールによっては、多くのIT支援と投資が必要です。導入を決める前に、設定にかかる費用と必要なスキルを確認しましょう。
- 明確な問いを立てずに始めると、インサイトよりデータばかりが増え、それをもとに判断することもできません。
プロセスマイニングは魔法のように感じられることもありますが、そうではありません。これまで見えなかったインサイトが得られても、最も難しい部分は残ります。インサイトを変化につなげることです。分析は、誰かが変化を定着させて初めて意味を持ちます。
プロセスマイニングの避けるべき使い方
プロセスマイニングは、明確な問いと信頼できるデータがあり、結果を解釈できる人がいるときに最も役立ちます。ここでは、プロジェクトの信頼性を損なう失敗を紹介します。
明確な目標なしに始めない
目的を定めずに調べ始めると、判断につながらない分析になりがちです。「請求書の承認に10日以上かかるのはなぜか」「顧客はオンボーディングのどこで遅れを感じているのか」といった問いから始めましょう。具体的な問いがあれば、どのプロセス、データ、指標を調べるべきかが明確になります。
実行可能な目標には、プロセス、対象期間、分析で支援する判断の3つが含まれます。データを読み込む前に目標を書き出し、プロセスの責任者と合意しましょう。こうした合意があれば、対象を広げすぎて何も答えられなくなる事態を防げます。
どこから始めればよいか迷う場合は、プロセス改善ガイドをプロジェクトの範囲決めに利用できます。対象のプロセスやシステム、エクスポートする項目、記録するアクティビティが示されているため、最初の問いに答えるためのデータをそろえられます。
ツールがプロセスを直してくれると期待しない
プロセスマイニングはプロセスの動きを調べるもので、自動的に問題を解決するものではありません。承認に時間がかかっていることは分かっても、その理由を特定し、変更を決めるのは人です。結果を確認し、関係者と話し合い、変更後にもう一度プロセスを測定してください。
関係者を交えずに進めない
データを理解するには、業務の背景が必要です。プロセスを単独で分析して報告書を送るだけでは、なぜ迂回経路があるのか、業務上の正当な理由があるのかを見落とすことがあります。プロセスを管理する人と協力し、データへのアクセスや検証に支援が必要な場合はIT部門も交えましょう。業務を知る人の知見があれば、イベントログから分かることと分からないことを判断できます。
レビューの段階ではなく、最初から関係者に参加してもらい、分析の目的を伝えましょう。事前に問いを共有しておけば、迂回経路や一時的な回避策、実務上だけで行われている手順について説明を得られます。
業務を担当する人は、システムに記録が残らない手順も把握しています。こうした記録の抜けがあると、発見されたプロセスが不完全に見えることがあります。ProcessMindでは、データフロースルーとしてマークすることで、記録されていないイベントを作り出さずに、モデル上でその手順を確認できます。
一度きりのプロジェクトとして扱わない
改善したプロセスも、時間とともに変化します。変更後に再度確認し、時間の経過に伴う結果を比較して、業務の動きが変わったかを確かめましょう。継続的なモニタリングによって、発見を成果につなげられます。
分析結果を人の責任追及に使わない
プロセスマイニングで分かるのは業務の進み方であり、誰が間違えたかではありません。分析の目的を共有し、プロセスの責任者や担当者に最初から参加してもらいましょう。あるグループの処理に時間がかかっていると分かったら、業務量、システム上の制約、手順の明確さなど、差が生じる条件を確認してください。原因は多くの場合、プロセスの構造にあります。答えを知っているのは、実際に業務を行う人であることがほとんどです。
品質の低いデータを使わない
分析の信頼性はイベントログに左右されます。タイムスタンプの欠落、アクティビティ名の不統一、誤ったケースIDがあると、実際とは異なるプロセスに見えてしまいます。各項目の意味を確認し、イベントが正しいケースに紐づいているかを確かめてから、データ全体を分析する前にサンプルを確認しましょう。プロセスデータの入手方法では、必要な項目を説明しています。
始め方
対象を絞ったパイロットなら、すべてを一度に分析しようとせずに、プロセスマイニングで何が分かるかを確認できます。
プロセスマイニングで何が分かるのかを共有し、明らかにしたいことについて合意します。プロセス、データ、業務の背景を理解している少人数のメンバーを集めます。
チームにとって意味のある問いから始めましょう。たとえば、遅延がどこで発生するのか、ケースが前のステップに戻るのはなぜか、といった問いです。
対象範囲が明確で、データにアクセスできるプロセスを選びます。遅延や繰り返し作業が知られているプロセスは、取り組みの出発点として適しています。
試行の対象は、事業部門、製品ラインなど、範囲を明確に定めた領域に絞ります。対象を絞ることで、分析結果を検証しやすくなります。
試行に必要なデータを集めます。最初はスプレッドシートやCSVのエクスポートで十分な場合があります。データへのアクセスや統合に支援が必要な場合は、IT部門に相談してください。
各イベントにケースID、アクティビティ名、タイムスタンプが含まれていることを確認します。各項目の形式が統一され、調査対象のプロセスを正しく表していることも確かめてください。
イベントログを読み込み、プロセスモデルを確認します。ケース数と期間が妥当かを確かめてください。妥当でない場合は、データの準備を見直します。
主な経路やバリアント、アクティビティの所要時間を確認します。フィルターで問いに関係するケースに絞り込み、さらに調査が必要な傾向を記録します。
アナリスト、プロセスオーナー、実務をよく知る担当者と結果を確認します。見つかった傾向が現場の実感と合っているか、何が原因として考えられるかを話し合います。
どの問題を調査または解決するかを決め、変更の効果を測る方法を定めます。
チームで変更を行った後、プロセスを再度分析します。開始時点の結果と比較し、何が変わったかを確認します。
得られた知見をもとに次の問いを見直すか、別のプロセスにも分析を広げます。
ProcessMindの役割
プロセスマイニングの活用例
アクティビティがデジタル記録として残り、ケースに紐づけられるプロセスは、プロセスマイニングで分析できます。よくある例を紹介します。
- **受注から入金まで(O2C):**顧客の注文から入金までの受注ライフサイクルを調べ、履行、請求、回収における遅延を確認します。
- **調達から支払いまで(P2P):**購買依頼から仕入先への支払いまでの調達を確認し、承認の遅れや手戻りを調べます。
- ITサービス管理(ITSM):サービスデスクのチケットを分析し、解決に時間がかかる経路、エスカレーション、SLA違反を特定します。
- **顧客のオンボーディング:**新規顧客のオンボーディングの進み方を確認し、遅延や途中離脱が起きる場所を調べます。受注管理では、履行側から同じ課題を確認できます。
- 保険金請求の処理:保険や医療の請求が、審査や処理の各段階をどう進むかを調べます。
- 製造・サプライチェーン:生産やサプライチェーンのプロセスを確認し、遅延、品質上の問題、リソースの制約を調べます。
イベントデータは、SAP、Oracle、Microsoft DynamicsなどのERPシステム、SalesforceやHubSpotなどのCRMプラットフォーム、ServiceNowやZendeskなどのヘルプデスクツール、または独自のアプリケーションから取得できます。システムのデータが適しているかどうかは、ケース、アクティビティ、タイムスタンプを特定できるかによって決まります。
業界、部門、変革の役割からライブラリを探すか、対象のプロセスとシステムに合ったプロセス改善ガイドをご覧ください。各ガイドには、エクスポートする項目、記録するアクティビティ、ソースシステムから入力するデータテンプレートが記載されています。
さまざまなチームや業界におけるプロセスマイニングの活用例をご覧ください。
プロセスマイニングとデータマイニング、機械学習の違い
プロセスマイニング、データマイニング、機械学習は、それぞれ異なる方法でデータを分析します。プロセスマイニングは、ケースが時間の経過とともにアクティビティをどう進むかに注目します。データマイニングは、データセット内のパターンを探します。機械学習は、データを使って予測や分類を行います。
| プロセスマイニング | データマイニング | 機械学習 | |
|---|---|---|---|
| 答える問い | このプロセスはどのように進むか | このデータセットにはどのようなパターンがあるか | 次に何が起きるか、またはこのケースは何か |
| 分析単位 | 時間の経過とともにアクティビティを進むケース | レコード、行、特徴量 | 予測結果に対応づけられた入力 |
| 入力 | ケースID、アクティビティ、タイムスタンプを含むイベントログ | 準備済みのデータセット | ラベル付きまたはラベルなしの学習データ |
| 出力 | プロセスモデル、バリアント、適合性チェック、ボトルネック | パターン、セグメント、クラスター | 予測、スコア、分類 |
| 一般的な用途 | 注文がどこで滞留し、どのように進むかを特定する | 顧客レコードに見られるパターンを特定する | 納品が遅れる可能性を予測する |
重要な違いは、それぞれの手法が答える問いです。プロセスマイニングでは、アクティビティの順序を追いながら分析できます。ケースが引き継ぎで滞留したり、同じアクティビティを繰り返したりしたことが分かります。データマイニングではレコード間のパターンを特定でき、機械学習では結果が起きる可能性を推定できます。
これらの手法は組み合わせて使えます。プロセスマイニングで業務の流れを把握し、変動を特定したうえで、ほかの分析手法を使ってパターンを調べたり結果を予測したりできます。予測だけでプロセスの理由が分かったり、プロセスが変わったりするわけではありません。
プロセス分析で使われる用語については、ProcessMind用語集をご覧ください。
次に読む記事
プロセスマイニングを理解するには、見覚えのあるイベントログで何が分かるかを見るのが最も早い方法です。エクスポートデータを読み込むか、サンプルプロセスから始めれば、定義が抽象的なままではなくなります。