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で直接データを吸い上げる「コネクター」を提供しており、データの前処理作業も行えるものもあります。
