プロセスマイニング – Process Mining

Introduction to Process Mining (12)Process Enhancement

今回は、「プロセス強化」について詳しく解説します。

プロセス強化　- Process Enhancement

プロセス強化は、プロセス発見や適合性検査などで特定できた様々な問題（非効率、ボトルネック、逸脱など）に対して、根本原因分析を行って原因をつきとめ、改善施策を展開、より望ましいプロセスへと変革していく取り組みのことです。

プロセスマイニングの効用（下図）から、プロセス強化に関係する改善施策（右端）を見てみましょう。

まず、イベントログから可視化された現状プロセスの複数のバリエーションから、理想プロセスが発見できたら、これの標準化を図り、BPMシステムに実装・展開することで、標準プロセスが確実に実行できるようにします。併せて、マニュアルの開発も有益でしょう。なお、ここで「理想プロセス」とは、効率が高く、ボトルネック発生が少ない、また逸脱のないto「to beプロセス」であり、多くの場合、スループット最短、処理コスト最少となります。

また、プロセスの一部の工程がムダであるなら、ばっさりとその工程をカットしたり、適切な順番に手順を入れ替えたり、直列処理から並行処理に切り替えるなどの「プロセス変革」を行うことが有効である場合も多いでしょう。

こうしたプロセスの改善においては、モデリングツールに現状プロセスを投入して、BPMN形式のフローチャート上でプロセス改善のための再設計を行う必要があります。モデリングツールは、プロセスマイニングツールによっては既に組み込まれているものがあります。モデリング機能がないプロセスマイニングツールの場合は、現状プロセスをBPMN形式でダウンロードし、別途モデリングツールにアップロードして編集を行うことになります。

単純な繰り返し作業や定型手順となっているプロセスについては、RPAによる自動化の有力な候補です。RPA化に当たっては、タスクレベルの詳細な手順を把握する必要があります。このためには、現場担当者へのヒアリングを行うことになりますが、タスクマイニングによってPC操作ログを収集し分析すればファクトベースでのタスクフローの可視化が可能になるだけでなく、そのままRPAのプログラムに展開できる場合もあります。

なお、プロセス変革、RPA化に当たっては、プロセス改善による具体的な成果（リードタイム短縮、コスト削減、ミス低減など）がどの程度期待できるかを事前に検証したいものです。プロセスマイニングツールの中にはシミュレーション機能実装されているものもあり、そうしたツールを活用すれば、プロセス強化の成果を定量的に検証できます。

もちろん、モデリングツールにもシミュレーション機能が備わっていますので、モデリングツール上でのシミュレーションで効果検証を行うことも可能です。

Introduction to Process Mining (11)Conformance Checking

今回は、「適合性検査」のアプローチについて詳しく解説します。

適合性検査　- Conformance Checking

適合性検査は、ひとことで言えば標準プロセスからの逸脱があるかどうかを確認する分析手法です。

ここで、「標準プロセス」とは、あらかじめマニュアルなどに示されている規範となる「正しい手順」、あるいは例外処理がなく、円滑に業務が遂行された場合の一般的な手順のことです。

標準的なプロセスは基本的に無理・無駄がなく、スループットも最短、コストも最小であることから、すべての案件が標準的なプロセスに沿って行われるのが理想です。しかし、現実には、マニュアル通りに業務が行われるとも限りません。また例外処理もやむを得ず発生することでしょう。

そこで、プロセスマイニングでは、標準となるプロセス（to beプロセス）と、イベントログから再現した現状プロセス（as isプロセス）の比較分析を行い、標準プロセスを正とした場合に、現状プロセスがどの程度適合しているかを詳細に検証します。だから「適合性検査」なのです。

以下のイメージ図では、左側にto beプロセス、右側にas isプロセスのフローチャートが表示されています。これは、購買プロセス（PtoP）における適合性検査となります。

さて、to beプロセスは購買申請から納品までなんの問題もなく円滑に業務が行われた場合の手順です。これを基準にas isプロセスを見ると２つの逸脱が存在していることがわかります。

ひとつは、購買承認のアクティビティから、その前の購買申請のアクティビティへと戻る流れが発生しています。購買申請内容になんらか不備があり、購買申請者に戻された（再申請要求）ものと考えられます。

もうひとつの逸脱は、見積もり依頼のアクティビティで繰り返しが発生していることです。サプライヤ（商社）に対してなんどか繰り返し見積依頼が行われたことがうかがわれます。

上記２つの逸脱はもちろん、現実には起こりうる想定内の逸脱ではあります。大事なのは、逸脱をゼロにすることは不可能としても、逸脱をできるだけ減らすことにより、明確に工数が削減でき、スループット短縮、処理コストの低減が目指せることです。

たとえば、購買申請内容に不備があることで購買部からの戻しがあり、購買の再申請を行うケースが多い場合、申請前に内容不備を減らすような工程を増やしたり、システム上のチェック機能を追加するなどの改善施策が考えられます。こうした改善施策によって再申請回数を減らすことが重要なのです。

逸脱の２つのパターン

標準プロセスに対する現状プロセスの逸脱（適合していないこと）には、大きくは2パターンあります。

１　標準プロセスには含まれていない手順・アクテイビティが発生している

やってはいけないこと、やらないほうが望ましいことを実施している、という逸脱です。前項の解説でしめした「戻り」や「繰り返し」は、やらないほうが望ましいけれど実施しているケースがあるというもの。

また、購買プロセスではしばしば、購買承認を得る前に発注が行われるケースがあります。急を要するので購買承認が下りる前に発注せざるを得ない、ということは現実には起こります。この「購買承認前発注」は、英語では「マーベリックバイング」と呼ばれる逸脱です。コンプライアンス上、厳密に言えば「行ってはならないプロセス」でしょうし、行うことがやむを得ないのであればできるだけ減らすべきプロセスでもあります。

２　標準プロセスに含まれている手順・アクティビティを実施していない

やるべきことをやっていない、端折っている、という逸脱です。

これは、製品の検査プロセスにおいては大問題となりかねない逸脱だと言えるでしょう。本来実施すべき検査工程が、なんらかの理由で端折られてしまうといいう状況は様々な現場でしばしば観察されることです。しかし、その結果として、製品が世の中に出たとき、損害賠償につながるような大事故を起こしたり、リコールによる製品回収となった場合の損害は多大なものとなります。

したがって、検査工程がある程度ITシステムで管理されており、イベントログを通じて検査プロセスの見える化が可能であれば、ぜひこのやるべきことをやっていない逸脱の検査を行うべきでしょう。

to beプロセスの設定

適合性検査を行いたいが、そもそもto beプロセス、すなわち標準プロセスを規定していない、マニュアルなども存在しないというケースがあります。むしろ、事前に標準プロセスが確立されているケースよりも、標準プロセスは明文化されていないケースのほうが多いと言えます。

プロセスマイニングツールを用いて適合性検査を行う場合、as isプロセスの元となるイベントログのアップロードとは別に、to beプロセスのデータをアップロードする必要があります。ここでto beプロセスを作成する方法には２つあります。

１　to beプロセスをモデリングツールで作成

対象プロセスを実行しているITシステムのドキュメントやマニュアルに標準的な手順が示されていた場合、これをベースにモデリングツールを用いてBPMN形式でプロセスフローチャートを作成します。この作成したto beプロセスをプロセスマイニングツールにアップロードします。

２　as isプロセスから、to beプロセスを抽出

イベントログから再現したas isプロセスには多くのバリエーションが存在します。プロセス発見の「バリアント分析」によって、どのようなプロセスパターンがあるかを検証、その中で理想的なプロセスがあれば、それをto beプロセスとして抽出、必要に応じて整形を行った後、プロセスマイニングツールに再投入すれば、他のプロセスパターンとの適合性検査が可能となります。

Introduction to Process Mining (10)Process Discovery

今回は、「プロセス発見」のアプローチについて詳しく解説します。

プロセス発見　- Process Discovery

プロセス発見は、プロセスマイニングの土台となる手法です。プロセス発見をベースに適合性検査、プロセス強化、運用サポートが行われます。

プロセス発見とは端的に言えば、イベントログに基づいて「プロセスモデル」、すなわち対象プロセスのアクティビティの流れを表した「フローチャート」を自動的に作成することです。事前に、どのような手順で行われているか、といった情報を与える必要はありません。イベントログの情報（必須情報はケースID、アクティビティ、タイムスタンプ）だけを用いて、固有のアルゴリズムによってフローチャートを自動的に再現します。

従来、プロセスの流れはモデリングツールを用いて、手作業でフローチャートを作成していました。元となるのは、システム関連のドキュメント類、現場担当者へのヒアリングやワークショップによって得られた情報です。

一方、プロセスマイニングでは、ITシステムから業務に関わる操作履歴をイベントログとして抽出し、ツールにアップロードすれば自動的にフローチャートを作成してくれます。このことから、プロセスマイニングは初期のころ、「ABPD（Automated Business Process Discovery）」、すなわち、自動化された業務システム発見」とも呼ばれていたのです。

さて、プロセス発見のアプローチでは、様々な視点での分析が行えますが、基本となるのは「頻度分析（Frequency Analysis）」と「パフォーマンス分析（Performance分析）」です。

頻度分析　- Frequency Analysis

頻度分析では、各アクティビティの処理件数、および複数のアクティビティの間を移動した移行件数に着目します。下図のサンプルフロー図で解説します。

開始アクティビティの処理件数は7542件です。その次のアクティビティXへの移行件数も同じく7542件です。開始アクティビティで処理された案件（ケース）はすべてアクティビティXに移行したことがわかります。

アクティビティXの処理件数は7820件となっています。移行件数7542件よりも多いのは、アクティビティXは同じ案件について繰り返し業務が発生していることが考えられます。なんらかのミスをした場合など、操作をやり直したために繰り返し業務（リワーク）として記録されたということです。

アクティビティXからアクティビティYに移行しているのは7102件と大きく減少しています。これは、アクティビティXの後、手戻りが発生して前工程に戻ったり、全く別のアクティビティへ移行していたり、分析時点ではアクティビティXが最後のアクティビティとして記録されていたりしたためです。（簡略化したサンプルのため他のアクティビティへの移行は示されていません）

頻度分析の場合、処理件数や移行件数が相対的に多くなっているところを中心に分析を深掘りします。件数が多いということは作業負荷が高いということですから、次項のパフォーマンス分析と併せて、生産性の低下やボトルネック発生がないかを確認し、改善すべき問題を特定していきます。

パフォーマンス分析　- Performance Analysis

パフォーマンス分析は「時間」に基づく分析です。下図のサンプルフロー図で解説します。

開始アクティビティから終了アクティビティまでの総所要時間＝スループットは、対象プロセスのパフォーマンス分析において最も重要なKPI（Key Performance Indicator）と言えるでしょう。

プロセス改善の第一の目的は多くの場合、このスループットの短縮にあります。案件処理を開始してから終了までのスループットが短ければ短いほど、生産性は向上し、処理コストも低下するからです。

スループットは、「サイクルタイム」とも呼ばれます。ある定型的な業務、たとえば特定製品の製造工程において次々と新たな製品を生み出すサイクルにおる１件あたり平均処理時間のことです。

一般にまず、全案件の平均スループットを算出します。その上で、平均スループットよりも著しく長くなっている問題プロセス、逆に、平均スループットよりも短いプロセスを把握します。前者に関しては、なぜスループットが長くなってしまっているのかの原因を探ります（例えばミスが多く発生して繰り返しが多い、手戻りが発生しているなど）一方、スループットが平均より短いプロセスは、それが正しい手順で行われているとするなら効率の良いやり方とみなすことも可能です。（こうしたプロセスのバリエーションと併せて分析することは、後述する「バリアント分析」と呼ばれます）

サンプルフロー図に戻りましょう。アクテビティごとの時間は処理時間、また複数のアクティビティの間は待ち時間です。

サンプルフローでは、開始アクティビティの処理時間は5分11秒です。開始アクティビティからアクティビティXをつなぐ線上の時間は54分。これは待ち時間です。開始アクティビティは完了した時間から、アクティビティXの処理が開始される時間までの間の時間だからです。

さて、アクティビティごとの処理時間が、KPIの目標値よりも長い場合、効率性が低いという判断になります。例えばアクティビティYの処理時間は3時間45分17秒です。もし、当アクティビティのKPI目標値が「3時間」とするなら、約45分余計に時間がかかっているわけですから効率が良くない。なんとか処理時間を短縮すべき問題箇所となります。

また、その前のアクティビティXからアクティビティYの間の待ち時間は20時間を超えています。これも、KPI目標値よりも長ければ、業務が滞留している＝ボトルネックの発生ということになり、是正対象ポイントとして原因追求を図る必要があります

バリアント分析　 – Variant Analysis

プロセスマイニングの分析対象とするイベントログデータの件数は一般に数百件から、数百万件になります。ここでの件数は対象プロセスで処理される案件数です。例えば、経理部における請求書の処理プロセスの場合、処理された請求書の件数のことです。これは経理システムで付番した請求書IDの数と一致するでしょう。

さて、開始アクティビティと終了アクティビティが同じ「定型業務プロセス」であったとしても中間処理のプロセスには様々なバリエーションがありえます。請求書処理プロセスであれば、金額などに応じて上長承認が必要なもの、必要でないもので手順が異なります。内容不備の場合の差戻し、再受領というイレギュラーな手順もあるでしょう。

バリアント分析は、こうしたバリエーションが何パターンあり、それぞれのバリエーションで処理された案件数を算出します。もちろん、それぞれのバリエーションについてのプロセスモデル、すなわちフローチャートを作成し、頻度分析やパフォーマンス分析を行うことができます。

下図のバリアント分析のイメージ図では、３つのバリエーションが存在していることを示しています。合計処理案件数433件（260件＋125件＋48件）のうち、バリアントXが最も多く処理されているパターンであることがわかります。バリアントは開始から終了までシンプルな流れであり、余計な分岐や手戻り的なものがありません。こうした処理件数が多いバリアントはしばしば「ハッピープロセス」と呼ばれることがあります。多くの場合、ハッピープロセスは効率的でボトルネックがなく、スループットが最も短いからです。（必ずしもそうでない場合もあります）

一方、バリアントZは、バリアントXと比べて手順が多くなっています。パフォーマンス分析で比較すれば、おそらくバリアントZのスループットはバリアントXよりも長いでしょう。バリアントZが上長の承認が必要であるなど、不可欠な手順を踏んでいるのであれば問題はありません。しかし、担当者の裁量でやらなくてもよいことをやっている、あるいはなんらかのミスによって手順が増えてしまっているとしたら是正すべき問題箇所ということになります。

以上、プロセス発見の基本的な分析視点を解説しました。多くのプロセスマイニングツールでは、リソース（担当者）のデータを付加することにより、担当者間の関係性を可視化する「ソーシャルネットワーク分析」を行うことができます。

また、費用に関わるデータを追加することにより、コスト視点での様々な分析が可能です。

Introduction to Process Mining (8)Four Basic Approaches

今回は、プロセスマイニングをプロセス改善に活用するための４つの基本アプローチについて概要をお伝えします。次回以降で、各アプローチを個別に取り上げて詳しく解説します。

１　プロセス発見　- Process Discovery

プロセス発見は、プロセスマイニングの土台となる手法です。プロセス発見をベースに適合性検査、プロセス強化、運用サポートが行われます。

プロセス発見とは、ITシステムから抽出したイベントログに基づいて、一定のアルゴリズムによって、対象プロセスをプロセスモデル、すなわち業務の流れを表すフローチャートを再現します。このプロセスモデルは、実際のシステム操作履歴を反映したものですので、「現行プロセスモデル（as is プロセスモデル）」と呼ばれます。

再現されたプロセスモデルは、大きくは２つの切り口、すなわち「頻度（処理件数）」、「時間（処理時間）」での分析を行います。

頻度分析を通じて、例えば、対象プロセスのどの箇所で処理件数が多いか＝作業負荷が大きいかを把握することができます。作業負荷が大きい箇所はしばしば処理が追い付かず、ミス多発による繰り返しや業務の滞留＝ボトルネックが生じやすいところです。

また、時間分析では、実際に対象プロセスの個々の工程でどの程度の処理時間を要しているかを把握します。KPI目標値に照らして想定以上の時間が掛かっている場合、それは生産性が低いことになります。また、前の工程から次の工程に移る間の時間は「待ち時間」であり、この待ち時間が想定よりも長い場合、業務が滞留する「ボトルネック」であるということが明確です。

２　適合性検査　- Conformance Checking

適合性検査という呼び方はちょっと固い表現ですが、文字通り、手本となるプロセスと現状のプロセスを比較して、現状がどの程度お手本に適合しているかを分析するアプローチです。

ここで手本となるプロセスは「参照プロセスモデル」や「規範プロセスモデル」とも呼ばれます。要するに、あるべき「理想プロセスモデル（to beプロセスモデル）」です。一方、イベントログに基づくプロセスは「現状プロセスモデル（as isプロセスモデル）」です。

適合性検査は、理想プロセスを「正」として、現状プロセスがどのように乖離、逸脱しているかを明らかにします。具体的には、理想プロセスには含まれていない手順を現状プロセスでは行っている場合（やってはいけない手順実行）や、逆に、理想プロセスに含まれている手順が、現状プロセスでは実行されていない場合（やるべき手順の不実行）などです。

３　プロセス強化　- Process Enhancement

プロセス強化は、前項の「プロセス発見」や、「適合性検査」の分析結果を踏まえて、非効率なプロセス、ボトルネックを特定し、有効な改善施策を検討し、より優れたプロセスを設計・開発するアプローチです。

プロセスマイニングツールでは、不要と思われる手順をカットしたり、業務手順を組み替えたり、ボトルネックを解消するために要因配置を変更したり、またRPAによる自動化を行った場合にどの程度の改善が期待できるかをシミュレーションできる機能が備わっているものがあります。

シミュレーションを行うことにより、プロセス強化のための優れた改善施策はどのようなものになるかを事前に検証したうえで展開できます。

４　運用サポート　- Operational Support

従来、プロセスマイニングの分析対象は、過去の完了したイベントログでした。運用サポートでは、現在仕掛中のプロセス、すなわち未完了の案件に係るイベントログをほぼリアルタイムでプロセスマイニングツールに流し込み分析を行います。

そして、今まさに運用中の処理プロセスにおいて非効率、ボトルネックの箇所や逸脱を発見、あるいは予測し、担当者にメールやチャットなどでアラートを出すことで、問題の芽を早めに摘み取ったり、問題発生を未然に防ぎます。

運用サポートでは、予測分析などの高度な分析が行われるためAI（人工知能）も組み込まれており、現在最も最先端のアプローチと言えるでしょう。

Introduction to Process Mining (8) Process Mining Algorithm Basics

今回は、プロセスマイニングによるプロセスモデル（フローチャート）再現の基本原理であるアルゴリズムについて、わかりやすさを優先し、簡易的に説明します。

詳細な技術的解説は、プロセスマイニングのバイブルである『プロセスマイニング Data Science in Action』（Wil van der Aalst著、インプレス）をお読みください。

プロセス発見 – Process Discovery

プロセスマイニングは当初、「Automated Business Process Discovery」（自動的に業務プロセスを発見する）と説明されていました。ITシステムから抽出したイベントログデータから、対象プロセスの流れ（業務手順）を自動的に再現することが最も基本的な機能だからです。

現在は、単にプロセスを発見するだけでなく、参照プロセス（to beプロセス）との比較分析を行う「適合性検査」や、未完了の案件について予測を行ったり、逸脱発生時にアラートを流すなど、高度な機能が次々と実装されています。

したがって、プロセスマイニング＝プロセス発見とは言えなくなってきたものの、プロセス発見という機能がプロセスマイニングの核となる機能であり、また分析の出発点であることは依然変わりません。

さて、イベントログは下図あるようなフラットなデータです。イベントログからプロセスモデル（フローチャート）を再現するためには、案件ID、アクティビティ、タイムスタンプの3項目があればいいのですが、初めてプロセスマイニングを知った方は、どうやってフローチャートを描くのか不思議に思われるようです。もちろん、裏には、一定の処理ロジック、すなわち「アルゴリズム」が存在します。

このアルゴリズムはプロセスマイニング固有であり、一般的なデータマイニングツールには備わっていません。したがって、プロセスマイニング分析を行い、プロセスを可視化したい場合には、プロセスマイニングツールを利用する必要があります。

プロセスモデル（フローチャート）の再現

では、イベントログからフローチャートをどのように作成するかを簡易的なサンプルデータでご説明しましょう。

下図のデータは、案件ID（1～３）とアクティビティ（A～E）のみ。タイムスタンプは略してありますが、上から下に時間が経過している、つまり上の行にあるアクティビティほど古い時間に行われているということになります。

まず案件１についてアクティビティを拾ってみましょう。色分けしてあるので簡単です。緑色のアクティビティ、すなわちA→B→C→D→Eです。同様に、案件２（オレンジ）、案件３（青）についてそれぞれのアクティビティのフロー図が下図の中央にあります。

言うまでもないことですが、Aを起点として終点のEに至る道筋＝トレースは、案件毎に異なっています。アクティビティの順番が入違ったり、同じアクティビティが繰り返されていたりしていますね。どんなプロセスであれ、その辿る道筋＝トレースは複数のバリエーションがあるのが一般的です。

プロセスマイニングでは、案件ごとの個別の道筋を分析することもありますが、まずはこうした複数のバリエーション全体をうまく説明できる「プロセスモデル」を作成します。（下図右端の濃紺のフローチャート）たとえとしては正確ではありませんが、バリエーションの「最大公約数」を見つけるようなものです。

こうして、イベントログに含まれる複数の業務手順のバリエーションから、全体に当てはまりのよいプロセスモデルを作成するのがプロセスマイニングのアルゴリズムです。なお、プロセスマイニングツールに触れたことのある方はお分かりかと思いますが、このプロセスモデルの抽象度は自由に変更することが可能です。すなわち、全体の流れをざっくり把握できる抽象度の高いモデルから、すべてのバリエーションを再現した、最も抽象度の低い詳細なモデルまで、ツールの機能として「粒度」を変更できる可変スライダーが実装されています。

プロセスモデル作成の流れ（イメージ）

さらに、もう少し詳しくアルゴリズムの原理を説明しましょう。

前項同様、わかりやすいように、タイムスタンプを省いて以下のような4つの案件が含まれたイベントログからのフローチャート作成を考えてみましょう。ここで、アルファベットは各アクテイビティであり、（A,B,C）のログは、Ａ→Ｂ→Ｃという時間的順番で行われたことを意味します。

わかりやすいように、タイムスタンプを省いて、以下のような4つの案件が含まれたイベントログからのフローチャート作成を考えてみましょう。

CASE_1　(A,B,C)
CASE_2　(A,B,D)
CASE_3　(A,E,C)
CASE_4　(A,B,C,B,C)

ここで、アルファベットは各アクテイビティであり、（A,B,C）のログは、Ａ→Ｂ→Ｃという時間的順番で行われたことを意味します。

まず、CASE_1のログからフローチャートを描きます。

シンプルですね。

次に、CASE_1に加えてCASE_２も考慮します。

Ａ→Ｂ→Ｃだけでなく、Ａ→Ｂ→Ｄというパタンも存在したことがわかったので、ＢからＣとＤに分岐するフローチャートが描かれました。

さらに、CASE_1、CASE_2、CASE_3の３つの案件を考慮したフローチャートです。

Aに続くのはＢだけでなく、Ｅが続く手順もあるのでこのようなフローになります。

最後に、CASE_1からCASE_4までのすべてを考慮したプロセスモデルは以下の通りです。

Ｂ→Ｃだけでなく、Ｃ→Ｂと戻る手順も存在していることがわかります。手戻り発生です。

以上の例では４案件だけでしたが、実際の業務プロセス分析では数万件、数十万件の案件のイベントログに基づいて、上記のようなフローチャートを再構成していくわけです。

アルゴリズムの種類

イベントログからプロセスモデル（フローチャート）を再現するアルゴリズムも日々進化しています。

プロセスマイニングは1999年、オランダでの学術研究からスタートしていますが、当初は「アルファアルゴリズム（アルファマイナー）」が用いられました。ただ、アルファアルゴリズムには、現実のプロセスを十分に再現できないというロジック上の制約があるため、研究が進むにつれ、以下のような様々なアルゴリズムが開発されています。（それぞれに、優れている点と劣っている点があり、どれが最も優れたアルゴリズムか、ということは一概に言えません）

・ヒューリスティックマイナー

・インダクティブマイナー

・スプリットマイナー

現在入手可能なプロセスマイニングツールは世界に30ほど存在しますが、それぞれなんらかのアルゴリズムをベースに、精度を高めるためのカスタマイズを施していると思われます。

ユーザーとして留意しておきたいことは、同じイベントログだったとしても、様々なツールによって再現されたプロセスモデル（フローチャート）を比べてみたら、若干の違いがあるだろうということです。（まったく違うということはないにしても）なぜなら、それぞれ異なるアルゴリズムを実装しているからです。

Introduction to Process Mining (７) What is Event Log？

今回は、プロセスマイニングの分析対象となる「イベントログ」がどのようなものかについて解説します。

典型的なイベントログのデータフォーマット

プロセスマイニングツールにアップロード可能なイベントログの典型的なデータフォーマットは下表のようなものです。

ちなみに、ツールにアップロードするためのファイル形式は「CSV」が最も一般的です。CSVだけでなく「エクセル形式」、およびXMLに基づくプロセス定義のための交換フォーマット、「XPDL形式」でのアップロードが可能なツールもあります。

また、IEEEが標準として決めたタグ形式のイベントログは「XES（eXtensible Event Stream)」と呼ばれており、プロセスマイニングツールの中にはXES形式のデータのアップロードもできるものがあります。（業務システムから抽出した生データを前処理する際、最終的にはCSV形式にするのが一般的であり、XESデータを扱うことはほとんどありません）

さて、プロセスマイニング分析のためのイベントログのデータ項目は、大きくは「必須3項目」と、残りの「属性項目」で構成されます。

【必須項目】

必須項目は以下の３つです。

・案件ID（CaseID)

　上表の例は、顧客からの航空券の払い戻しプロセスです。予約していた便がなんらかの理由で利用できなくなったため、代金の返金を求める顧客からの申請を受け付け、審査を行い、返金することを決定したら、返金手続きを行い、顧客の銀行口座に代金を振り込むという流れになっています。

このプロセスにおいて案件IDとは、個別の顧客からの特定の予約についての申請について附番されたIDになります。おそらく、顧客からWebや電話などで申請を受け付け、システムに登録（返金申請受付）された時点で自動的に付番される仕組みになっているでしょう。

この案件IDがあることで、あるひとつの案件について、起点となるアクティビティ（システム操作）から、途中の節目となるアクティビティを経由して完了アクティビティまでを縦串にして、所要時間などを分析することが可能になります。

また、資材などの購買プロセスの場合、各部門の調達担当者が作成する「購買要求」が、システムに記録された時点で付番される「購買番号」を案件IDとして扱うことになります。

・活動（アクティビティ）

活動（アクティビティ）とは、業務システム上でなんらかの業務プロセスを実行する際、節目節目で記録される操作のことです。航空券の払い戻しプロセスの場合、「返金申請受付」、「審査」、「返金決定」、「返金手続き」、「口座振り込み」といったものがアクティビティです。

システム上の操作としては、なんらかの情報入力を行い、「完了」や「保存」などのボタンを押下したタイミングで記録されることが多いでしょう。システムによっては、あるアクティビティの開始と完了の両方が記録される場合もあります。例えば、「返金申請受付開始」、「返金申請受付完了」といったようにです。これは、システム上の操作のイメージとしては、返金申請の情報入力画面を立ち上げたタイミングで「返金申請受付開始」が、また、同入力画面を完了ボタンを押下して終了したタイミングで「返金申請受付完了」が記録されると考えてください。

操作のどのタイミングでアクティビティとして記録されるかはシステムの仕様次第であり様々です。おおむね、開始アクテイビティ、または終了アクティビティのどちらか一方しか記録されないシステムが多くなっています。

なお、一つ一つのアクティビティはシステムにおいては「イベント」として次に述べるタイムスタンプととともに記録されます。すなわち、「イベントログ」とは、システム上の操作イベントをひとまとまりのデータとして集約したもの、と言えます。

・時刻（Timestamp)

時刻（タイムスタンプ）とは、前項の活動（アクテイビティ）が業務システムで行われた時間を記録したものです。どの程度詳細な時刻が記録されているかはシステムの仕様次第です。できれば「年・月・日・時・分・秒」で記録されているのが望ましいのですが、「年・月・日・時・分」だったり、「年・月・日」だけで、時分が含まれていない場合もあります。

タイムスタンプは、案件IDに基づいて縦串した複数のアクテイビティの時間的順序、つまり、どのアクティビティが先に（後に）行われたかを判断するアルゴリズムに用います。したがって、「年・月・日」だけ、つまり時分秒が含まれていない場合、同日に行われた複数のアクテビティの時間的順序の判別が困難となり、プロセスフローチャートの精度が低下することになります。

【属性項目】

属性項目は、分析を深めるために追加する各種データ項目です。

航空券払い戻しプロセスの例では、「リソース」、「処理費用」、「顧客（名）」の３つが属性項目です。リソースは、当該システムを操作する担当者のことであり、しばしば、その担当者の所属部署や役職＝ロールの属性も分析対象とします。

また、購買プロセスの場合には、「サプライヤー名」や「製品名」なども追加されます。

属性項目は、業務プロセス上の問題（非効率性やボトルネックなど）を特定した際、それは、特定のリソースや顧客において起こりやすいかどうか、といった深堀りを行う「根本原因分析」において活用するものです。また、「活動基準原価計算（ABC: Activity Based Costing)」などに基づいて、処理費用の算出が可能であれば、属性項目として処理費用を追加することで、プロセスに係るコスト視点での分析が可能となります。

イベントログデータ作成フロー

プロセスマイニングの対象とする業務プロセスを決定したら、その業務プロセスを遂行しているITシステムから、必要なデータを抽出するわけですが、抽出されたデータ（生データ：トランザクションデータ）をそのままプロセスマイニングツールにアップロードすることはできません。

というのも、プロセスマイニングツールにアップロードするファイルは、ノイズなどが除去され、所定のデータ項目が揃ったクリーンなファイルに一本化する必要があるからです。

一般に、ITシステム内のDBから抽出されたデータは年度単位でファイルが分かれていたり、トランザクションファイルとマスターファイルが分かれていたり、データの抜け漏れ（ブランク）や文字化けがあったりと、要するに汚れたデータ、ダーティデータです。

このような複数（しばしば数十本）のダーティデータをクリーンにし1つのデータファイル＝クリーンなイベントログに加工する作業が「データ前処理」です。例えば、ブランクが存在するデータについては一括削除したり、なんらかの補正値を入力したりします。こうした前処理作業を数十万～数百万件の生データに対して行うため、基本的にはデータ前処理のためのツール「ETL」を用います。

ETLはExtract, Tranform, Loadの頭文字を取ったものです。文字通りデータ抽出からデータ変換（加工）、他のツールへのアップロード、さらには分析機能も持つ多機能なツールですが、プロセスマイニングにおいてはもっぱらデータ変換（加工）に活用します。

私がお勧めしているETLは、「KNIME（ナイム）」というオープンソースのツールです。日本語ローカライズはされていませんが、なんせ無料ですし、直感的な操作を行うことができる非常に優れたツールです。

KNIMEであれば、様々なデータ加工をノンプログラミングで行うことができるため、エンジニアでなくともデータ前処理を実行可能です。もちろん、エンジニアの方がデータ前処理を行うのであれば、SQL、Python、Rなど得意なスクリプトでデータ加工処理を行えば、KNIMEより高速に処理ができるでしょう。

なお、データ前処理の手順をワークフローとして作成すれば、同じプロセスについては差分データの前処理も同じワークフローで可能です。したがって、APIを通じて業務システムから分析対象の生データを抽出して前処理を行いプロセスマイニングにアップロードするまでを自動化することができます。

プロセスマイニングツールによっては、一般的なSaaS型の業務システムについて、APIで直接データを吸い上げる「コネクター」を提供しており、データの前処理作業も行えるものもあります。

Introduction to Process Mining (6) Process Mining and Related Solution

今回は、プロセスマイニングの隣接分野、関連ソリューションとの関係性について解説します。

ビジネスインテリジェンス（BI）の視点から

プロセスマイニングは分析手法のひとつです。ビジネスへの適用を前提とすると下図の通り、一番大きな枠として「ビジネスインテリジェンス」があり、その内側に「プロセスインテリジェンス」、さらにその内側に「プロセスマイニング」があるという入れ子構造になっていると考えることが可能です。

まずビジネスインテリジェンスですが、文字通り、ビジネスに関わるあらゆるデータ・情報を分析対象として収集し、分析するものです。いわゆるBIツールを用いて分析することが多いですが、典型的には、売上や利益などの財務データをベースに、年度別、月別、週別などの推移を見たり、エリア別や製品別にドリルダウンして、売上や利益に貢献しているエリアや製品カテゴリ、逆に足を引っ張っている要因がどこかを掘り下げて分析する。これがビジネスインテリジェンスです。

ビジネスインテリジェンスのうち、特に業務プロセスに関わるデータ・情報に絞って各種分析を行うのが「プロセスインテリジェンス」です。さらに、プロセスインテリジェンスの中で、業務の流れ、すなわち「コントロールフロー」を核とする分析手法が「プロセスマイニング」です。

このようにみると、プロセスマイニングは大きくはビジネスインテリジェンスに含まれるため、ビジネスインテリジェンスで代替できるのではないか、とおっしゃる方もいます。

しかし、プロセスマイニングの基本機能である「（自動的な）プロセス発見」には、特殊なアルゴリズムが必要であり、BIツールには、このアルゴリズムは通常、実装されていません。また、BI機能に基づいて、プロセスマイニング用のアルゴリズムをゼロベースで組むのは現実的には不可能です。（初歩的なものは組めたとしても、それによって、再現されたプロセスモデルの信頼性は低いものでしょう）

したがって、プロセスマイニングを実行したければ、専用のプロセスマイニングツールの採用が必要になり、BIで代替することはできません。

では、プロセスインテリジェンスがカバーする領域はどこになるのでしょうか？

プロセスマイニングツールでは、特殊なアルゴリズムを用いて行うプロセス発見以外に、様々な統計数値を算出し、様々な表・グラフで表現する機能が備わっています。

例えば、分析対象としたプロセスに含まれる案件数、プロセスの開始から終了までのスループット（サイクルタイム）や、各アクティビティごとの処理数、処理時間、あるアクティビティから別のアクティビティまでの移行時間、すなわち待ち時間などです。そして、これらの数値に関して平均、最大・最小、中央値、標準偏差などを併せて確認することが可能です。

こうした統計数値の算出は、シンプルな四則演算ベースで可能であり、特殊なアルゴリズムは言うまでもなく必要ありません。BIでも簡単に実行できますが、これこそ「プロセスインテリジェンス」がカバーしている領域です。

プロセスマイニングによる分析においては、アルゴリズムを通じて発見された「プロセスモデル」（as isプロセスモデル）を起点に、様々なバリエーションを検証する「バリアント分析」や、理想プロセス（to beプロセス）との比較分析、すなわち適合性検査などを行います。

さらに、処理時間がKPIを超えている問題アクティビティや、待ち時間が長くなっているボトルネックを特定していきますが、ここで重要になってくるのが処理件数や処理時間、待ち時間などの基本統計数値です。

すなわち、プロセスマイニングでは、プロセスモデルと併せてプロセスインテリジェンスの数値を様々な視点で掘り下げることを行うわけです。

主要なプロセスマイニングツールでは、プロセスモデルを作成するアルゴリズムは当然として、プロセスインテリジェンス機能、特に、様々な数値をビジュアルに表現するダッシュボード機能が標準で装備されています。この意味では、現在のプロセスマイニングツールは、「プロセスインテリジェンスツール」と言い換えても全く支障がないと言えます。

BPM、データマイニング・AIとの関係

プロセスマイニングと密接な関係がある隣接分野があります。ひとつはデータマイニング・AI、もうひとつはBPM（Business Process Management）です。

まずは「データマイニング・AI」とは何かから説明します。データマイニングは、基本的にビッグデータを対象とした分析手法であり、その主な目的はものごとの因果関係や典型的なパターンのような「法則性」を発見して、様々な意思決定に役立てることです。

例えば、各地の気温、湿度などの天候情報を大量に収集し、データマイニングでそのデータを分析することで、どのような状況において晴天になりやすいのか、それとも雨天になりやすいのかの予測式がつくられ、天気予報に活用されています。

データマイニングでは、数十年前から活用されてきた「多変量解析」の手法、例えば、回帰分析や、クラスター分析、決定木分析に加え、近年は主にニューラルネットワークによるディープラーニングが飛躍的な進歩を遂げ、ものごとを判別したり、予測する精度が大きく向上しています。一般に、これらの分析手法のことは「AI（Artificial Intelligence:人工知能）」と呼ばれますが、AIはデータマイニングにおいて頻繁に利用される手法なので、当記事では「データマイニング・AI」と一括りにしています。

さて、データマイニングはあらゆる分野のあらゆるビッグデータを分析対象としますが、基本的に「プロセス」を対象とはしてきませんでした。ある瞬間、すなわちスナップショット的な静的なデータを抽出して、要約したり、分類したり、因果関係を見出してきたりしたのです。

一方、プロセスマイニングは、文字通り、時系列のひとつながりになった動的なデータから、プロセスの流れを描き出すこと、すなわち「プロセスモデル」を作成することが基本にあります。もちろん、プロセス処理件数や処理時間など、プロセスに関わる静的な各種統計量も併せて算出する点は、データマイニングと共通しています。

こう考えると、データマイニングとプロセスマイニングは、分析手法としては兄弟分のようなものです。（どちらにも「マイニング」という言葉が含まれていますし）

ただ、プロセスマイニングを主体に考えると、プロセスに関わる様々な分析を深めていくうえで、データマイニング、AIの手法が応用されています。例えば、現在処理中の案件（ランニングケース）の終了までのリードタイムを推測するためには、データマイニングにおける「予測分析」が採用されています。

それ以外にも、必要に応じて、クラスター分析や決定木分析などが活用可能であり、今後も、プロセスマイニングツールとしての分析の幅や精度を高めるためにデータマイニングの手法がプロセスマイニングに取り入れられていくと考えられます。

では次に、BPM（BPM）について考えてみましょう。BPMはシンプルにいえば、プロセスを改善することを目的として、プロセスの現状を分析し、問題点を解消するto beプロセスを設計し、現場に展開・監視を行う一連の活動です。

このBPMの活動のうち、とりわけ「現状分析」において、プロセスマイニングの基本アプローチのひとつ、「プロセス発見」は役立ちますし、その後の設計、展開、監視においても、プロセスマイニングが提供できる「適合性検査」、「プロセス強化」のアプローチはBPMにとって強力な武器となりえます。

このように、プロセスマイニングとデータマイニング・AI、BPMはお互いに補完しあえる関係にあると言えます。プロセスマイニングのゴッドファーザー、Wil van der Aalst教授は、「プロセスマイニングは、データマイニングとBPMをつなぐ橋である」と述べられていますが、まさに、BPMの取り組みにおいて、プロセスに特化したデータマイニングとしての「プロセスマイニング」は大きな役割を果たしていくと思われます。

プロセスマイニングの前工程と後工程

業務プロセス改善の取り組みにおいて、プロセスマイニング活用を中心に置くと、プロセスマイニング分析を行う前工程としての「データ前処理」に関わるソリューションと、プロセスマイニング分析後の実際の改善施策としての様々なソリューションが存在します。

データ前処理は、ERPなどの業務システムから分析対象となるデータを抽出し、プロセスマイニングツール（およびタスクマイニング）で分析できるデータ形式へと整形する作業です。

業務システムから抽出した生のデータをそのままプロセスマイニングツールにアップロードできることは基本的にありません。抽出されたデータは複数のファイルで構成され、実際の取引履歴であるトランザクションデータ以外に、参照するためのマスターファイルが含まれています。また、データには抜け漏れ、文字化けなど、そのままでは分析できない箇所が存在するため、適宜削除、補正するなどの作業が必要です。これを「データ前処理」と呼びます。

データ前処理は、SQLやPythonなどで処理プログラムを記述することで高速に行えますが、こうした言語を知らなくても、データ前処理を簡単に行えるETLツールの利用を私はお勧めしています。ETLツールもいろいろとありますが、オープンソースで操作も簡単な「KNIME（ナイム）」が一押しです。

さて、プロセスマイニング分析後に発見した問題を解決するための施策としてのソリューションには、まずRPA(Robotic Process Automation）によるタスク自動化が挙げられます。また、プロセス単位で一定の業務手順を自動化するためにはビジネスプロセスマネジメントシステム（BPMS）の採用が有効でしょう。また、業務を遂行するためのリソース最適化のために、アウトソーシングサービス（BPO)の活用も検討に値するでしょう。

なお、プロセスマイニングを軸とする継続的プロセス改善のためには、分析対象となる各種データを長期に亘って蓄積し、柔軟に抽出できる仕組みが有効です。したがって、データウェアハウス（DWH）やデータレイクと呼ばれる分析系システムを構築して、実運用によって不断に生み出されるデータを収集・蓄積しておくことが望ましいです。

Introduction to Process Mining (5) Application areas of Process Mining

今回は、プロセスマイニングによる分析が可能な適用対象について、いくつかの視点で解説します。

システム・テクノロジー視点

まず、システムやテクノロジーの視点でプロセスマイニングの分析が可能なものについて概説します。

プロセスマイニングは1999年に研究がスタートしました。もともと、ビジネスプロセスマネジメント、ワークフローといった業務プロセスの可視化を目的として始まった分析手法ですので、分析対象となったのは企業の基幹システムである「ERP」です。こうしたシステムは取引履歴がDBに詳細に記録・保持されています（「大福帳型DB」とも言います）。

取引履歴、すなわちトランザクションデータには、業務システムの操作の節目となるアクティビティ、タイムスタンプ、そして案件IDが基本的に含まれており、プロセスマイニング分析が容易に行えるデータだと言えます。

また、ERPと並んで、CRM（SFA含む）システムから抽出される業務システム操作ログは営業管理、顧客管理に関わるデータであり、プロセスマイニングの分析対象として有効です。

もちろん、個々の企業が独自開発したレガシーシステムについても、それがどんなコンピュータ言語で開発されていようとも、「業務システム操作ログ」が記録・保持されていればプロセスマイニングでの分析が可能となります。（多くの場合、レガシーシステムでも業務システム操作ログ、あるいはトランザクションデータはなんらかの形で記録されています。）

また、コールセンターでの顧客からの問い合わせの対応履歴を管理するCTI(Computer Telephony Integration)や、ITヘルプデスクのためのシステムからは、問い合わせ対応や、チケット対応履歴データが抽出できます。この、いわゆる「コミュニケーションログ」も、プロセスマイニングではしばしば分析されます。迅速な解決のための対応プロセスの改善により、顧客満足の向上を目指すことが主な目的です。

Webサイトの訪問履歴、すなわち「Webアクセスログ」も、訪問者のセッションID（Cookieも可）、訪問したページ（＝アクティビティ）、タイムスタンプの3つの必須データ項目が含まれており、Web上での顧客の振る舞いを分析するためにプロセスマイニングが採用されます。顧客の行動をプロセスマイニング分析することは「カスタマージャーニーマイニング」と呼ばれています。

さて、意外な分析対象なのが、「機器操作ログ」です。「マシンログ」とも言いますが、これまでしばしば分析されているのが医療機器、具体的にはCTやMRIといったものです。分析目的は、稼働率の向上や適切に利用されているか、といったものです。

また、近年、IOT（Internet Of Things)が注目され、あらゆる場所にセンサーが設置されることで、センサーが捕捉したログが大量に発生しています。センサー捕捉ログはデータ量が大きく、ノイズが大量に存在しますが、適切にデータ前処理を行うことでプロセスマイニングを実行できます。

最後は、エクセルやブラウザーの詳細な操作履歴を収集したPC操作ログです。PC操作ログは、業務システム内に保存されているイベントログと異なり、分析対象PCに操作内容を収集するエージェントをインストールして能動的に蓄積する必要があります。PC操作ログは、タスクレベルの業務内容の見える化が可能であることから、「タスクマイニング」と呼ばれます。このPC操作ログはIOT同様、データ量が膨大でノイズが多く含まれますが、データ前処理を行うことでプロセスマイニングツールでの分析が可能です。

バリューチェーン視点

下図は、企業活動を価値を生み出し、顧客に提供する仕組みとして構造化してもので「バリューチェーン」と呼ばれています。ここでは、バリューチェーンの視点でプロセスマイニングの分析対象を考えてみましょう。

様々な企業活動において、収益を得て事業を継続する「価値創出プロセス」は、

購買物流→製造→出荷物流→販売・マーケティング→アフターサービス

の流れです。この価値創出プロセスの多くは現在、ERPや、CRM(SFA)などの業務システム、またSaaS型の各種アプリケーションで遂行されるようになってきており、どの段階においても、プロセスマイニング分析による継続的改善が行われるようになってきました。

また、この価値創出を支えるさまざまな機能、すなわち調達活動、技術開発、人事労務管理、全般管理についても、システム化が進行している管理についてはプロセスマイニングが採用されるケースが増えてきています。

例えば、人事労務管理の領域になりますが、新規採用人材の受け入れプロセスである「オンボーディング」を効果的、効率的に行うための改善を目的としてプロセスマイニングが採用されています。

分析対象となることの多い業務プロセス

最後に、これまでプロセスマイニングの分析対象となることの多かった業務プロセスをご紹介します。

まず、「受注（O2C)プロセス」、「購買（P2P)プロセス」は非常に多く分析されています。バリューチェーンの枠組みでは、まさに価値創出プロセスの根幹にある最も重要な業務だからでしょう。欧米では特に、ERP上で実行されることの多い業務プロセスであり、データの抽出、前処理の手順がある程度標準化できることも、分析対象とされることの多い理由です。

また、受注プロセスに含まれますが、倉庫などで、顧客からの発注を受けて在庫を割り当て、出荷を行うまでのプロセスが分析されることも多くなっています。

さらに、バリューチェーンの価値創出プロセスでは最下流にあたる「問い合わせ対応」やヘルプデスクも、手順がある程度定型化され、イベントログとしてシステムから抽出が容易なためプロセスマイニングが行われています。

経理部門に限定されるプロセスとして、「買掛金管理」、「売掛金管理」も、ERP上でほぼ完結し、分析が容易であることから、しばしば分析対象となります。

Introduction to Process Mining (４) What Process Mining can deliver

今回は、プロセスマイニングの活用がもたらす主な効用（ベネフィット）について解説します。

経営的インパクト

まずは、経営的な視点で考えてみましょう。すなわち、プロセスマイニングの活用が、経営上のゴールともいえる売上や利益の向上にどのように貢献できるか、ということについてです。

第一に、「コスト削減」の成果が期待できます。プロセスマイニングによって業務プロセスが可視化されることにより、ムダな業務を洗い出すことが可能です。ムダな業務とは、たとえば、そもそもやらなくても支障のない業務や、ミス多発により手戻りが発生しやすい業務などです。こうしたムダな業務を除去したり、ミスを減らせるような手立てを講ずることで、業務プロセスの遂行コストの削減が可能となります。

第二に、「顧客満足度向上」が期待できます。例えば、受注から納品までの「受注プロセス」の場合、プロセスマイニングによる問題点の把握と改善を行うことによって、納期の短縮が図れます。顧客にとって、注文したものが以前よりも早く届くようになれば満足度は高まります。また、業務プロセスが最適化されれば、納期短縮だけでなく、発注したものとは違うものが届くといったミスも減ることも期待できます。すなわち、プロセスのスピード、および質の向上によって顧客満足度の向上が可能となり、結果的に受注金額の増大やリピート率改善につながることになります。

第三に、「従業員満足度の向上」も期待できます。プロセスマイニングによってあぶりだされたムダな作業や業務の滞留、すなわちボトルネックが解消されれば、業務プロセス完了に費やされる労働時間が減り、不必要な残業がなくなって総労働時間の短縮が可能となります。徒労に感じられるような業務に時間を取られることなく、効率的に業務を遂行できるようになり士気も高まることでしょう。

プロセス改善の手がかり

前項では、最終的な売上・利益にどのようにプロセスマイニングが貢献できるかを解説しました。ここでは、プロセスマイニング分析の結果から、どのようなプロセス改善につなげることができるかを説明します。

プロセスマイニングツールにイベントログをアップロードし分析を行うことでまず「現状プロセス」が可視化されます。ここから様々な現状分析を行っていきます。可視化された現状のプロセス（as is プロセス）からは以下のような問題点が発見できるでしょう。

・非効率なプロセス（想定よりも処理時間が長い箇所）

・ボトルネック（仕事が滞留している箇所）

・スタッフスキルのばらつき（個々人の生産性の違い）

・手戻り（繰り返し）プロセス

これらの問題が発見できたら、「なぜこのような問題が発生してしまうのか」を掘り下げます。「根本原因分析」です。結果、原因が特定できたら、その原因を解消するための改善施策を検討し展開します。改善施策としては以下のような打ち手が考えられます。

・プロセス変革（ムダ業務の除去、手順の見直しなど）

・要員配置の最適化（シフトの見直し等）

・スキルアップトレーニング（生産性の差を均すため）

・RPA化（定型業務を中心とした自動化）

・BPO化（要因配置計画をより柔軟に行うため）

また、可視化された現状プロセスのバリエーションの中に、優れた手順を発見することができたら、それを「理想プロセス（ハッピープロセスとも言います）」とみなし、標準化を図ります。そして、マニュアルを作成したりBPMシステムのワークフローとして組み込むことで全社に展開することが有効な打ち手でしょう。

一方、すでに標準プロセスが存在していた場合、それをto beプロセスとしてプロセスマイニングツールにアップロードすれば、現状プロセスとの比較分析（「適合性検査」と呼びます）を行うことで、標準から逸脱しているプロセスをあぶりだすことができます。

この逸脱についても根本原因分析を行い、即時是正を行ったり、法令遵守、すなわちコンプライアンス上の問題に発展する可能性がある場合には、対象部署に対するコンプライアンス研修などを行い、逸脱発生を未然に防ぐ施策を打ちます。

このように、プロセス改善、プロセスの標準化に向けての適切な改善施策を検討する前段となる、プロセス上の様々な問題を簡単に発見できることが、プロセスマイニングの直接的な効用だと言えます。

なお、プロセスマイニングツールと業務プロセスを接続可能とし、リアルタイムにイベントログデータをツールに流し込むことで、完了した案件だけでなく、未完了案件のリアルタイム監視も可能です。

リアルタイム監視の場合、現在仕掛り案件についてボトルネックや逸脱の発生を探知できることから、ただちに改善措置を行うことが可能となります。ツールによっては問題の発生を事前に予測することもでき、未然に問題発生を阻止することさえ行えます。こうした機能は「運用サポート」と呼ばれ、近年ユーザーの評価がますます高まっている、プロセスマイニングのベネフィットだと言えます。

業務分析手法としての効用

プロセスマイニングは、業務プロセス改善やシステム改修を主な目的とする現状把握のための業務分析のひとつです。従来の業務分析は現場ヒアリングなどアナログな手法であったのに対し、業務システムから抽出されたイベントログデータを分析するデジタルな手法です。

これまで述べてきた便益に加えて、業務分析手法としてのプロセスマイニングは従来のアナログな手法と比較してのメリットもあります。

従来手法は前述したように、分析対象となる業務プロセスに関わっている関係者に個別ヒアリングを行ったり、一堂に会して議論するワークショップ、またストップウオッチを手にしての観察調査（動作調査）などアナログな方法です。

ヒアリングやワークショップの場合、関係者の発言がベースになることから、ありのままの現実というよりは主観的なものになります。また、記憶に頼ったものになるため、得られる情報は断片的です。

なにより、長大・複雑なプロセスの場合関係者も多数存在し、ヒアリングやワークショップにかかる時間とコストは膨大なものになります。観察調査は主観性はある程度排除できるもののの実施の負荷は大きく、また業務遂行の邪魔になる可能性もあります。

一方、プロセスマイニング分析は、業務システムから抽出したイベントログデータにもとづく定量分析です。システム上の操作履歴を基本的に丸ごと、全数で分析するため、客観的かつ、漏れのないエンド・ツー・エンドのプロセスを再現することが可能です。

プロセスマイニング分析自体は、現場担当者に大きな負担をかけることはありませんし、データクリーニングなどの前処理の手間を含めても、従来手法よりも大幅な期間圧縮、コストダウンが可能です。

ただし、注意点があります。プロセスマイニング分析の分析対象は業務システムで行われた業務のみであり、エクセルなどで行われた中間ファイル作成業務などは捕捉できません。プロセスマイニングは、エンド・ツー・エンドのプロセスを見える化できるとは言え、その粒度は現実の業務よりは粗いものになります。

したがって、プロセスマイニング分析から得られた現状プロセスをベースに、漏れているタスクレベルの業務はやはり現場担当者へのヒアリングやワークショップを補完的に行う必要があります。もちろん、従来手法のようにゼロベースでのヒアリングよりは、はるかに的確で効率的な情報収集が可能となりますので、業務分析にプロセスマイニングを採用することのメリットは総合的には非常に大きいと言えるでしょう。