はじめに
IBM Process Mining(IPM)の特徴の一つであるマルチレベル・プロセス・マイニング機能についてご紹介します。
通常、プロセス・マイニングで業務分析を実施する場合、最低限以下の3つの要素が必要です。
- 注文番号やチケット番号などのID(IPMではプロセスID)
- そのIDに関連するアクティビティ
- アクティビティが完了した時間などのアクティビティに関する時間情報
IPMでは、マルチレベル・プロセス・マイニング機能によりプロセスIDを一度に5つまで指定して分析することが可能です。これにより、プロセスが複数のサブ・プロセスに含む場合でもプロセス全体を分析することができます。なぜなら、サブ・プロセスを含む場合とは、例えば注文番号から受注番号、商品番号、請求番号とプロセスで固有なIDが変化していく場合になりますが、それらを一度に指定して分析できるからです。
一般的なプロセス・マイニング・ツールが抱える課題
プロセスIDが一つしか指定できない場合に、複数のサブ・プロセスを含むプロセスを分析する場合どうすればいいでしょうか。対処方法として、それぞれのサブ・プロセス単位で分析したり、イベントログやIDをコピーしてフラットデータにして対応したりしますが、以下のような問題が発生します。
- Deficiency (欠陥)
プロセスIDとして設定した項目に対応する値がないために、イベントログが意図せずに消失してしまう(表示されない)こと
- Convergence (収束)
複製によって誤解を招くような診断をしてしまうこと
- Divergence (発散)
関連性のあるアクティビティが断絶してしまい、複雑なプロセス・モデルになってしまうこと
サブ・プロセスを含む例
サブ・プロセスを含む例として、インターネット・ショッピングで考えてみます。
- 2商品を注文
- 注文した商品のうち1つは在庫が無いためにキャンセル
- 在庫のあった1商品を発送
上記の結果、下表のようなイベントログが得られたとします。ここで、例えば注文番号だけで分析すると、ログとしては存在するNo.3-8が対象にならず漏れてしまいます。ここでは、イベントログの数が少ないので意図せずと言うことでは無いですが、Deficiencyにあたります。
No. |
注文番号 |
商品番号 |
発送番号 |
アクティビティ |
タイムスタンプ (hh:mm) |
1 |
100 |
I_101, I_102 |
|
注文受付 |
10:00 |
2 |
100 |
I_101, I_102 |
|
確認メール送付 |
10:30 |
3 |
|
I_101 |
|
在庫引当 |
11:00 |
4 |
|
I_102 |
|
在庫引当 |
11:00 |
5 |
|
I_101 |
|
キャンセル:在庫不足 |
12:00 |
6 |
|
I_102 |
|
ピッキング |
15:00 |
7 |
|
I_101 |
S_002 |
梱包 |
17:00 |
8 |
|
I_101 |
S_002 |
発送 |
20:00 |
一つのプロセスIDをコピーして全体を分析する場合
商品番号、発送番号を無視し、注文番号のみで全体を分析対象とする場合、注文番号を他のイベントログにコピーし、データをフラット化して分析することがあります。注文番号を他のイベントログにコピーした結果が下表です。
No. |
注文番号 |
商品番号 |
発送番号 |
アクティビティ |
タイムスタンプ (hh:mm) |
1 |
100 |
I_101, I_102 |
|
注文受付 |
10:00 |
2 |
100 |
I_101, I_102 |
|
確認メール送付 |
10:30 |
3 |
100 |
I_101 |
|
在庫引当 |
11:00 |
4 |
100 |
I_102 |
|
在庫引当 |
11:00 |
5 |
100 |
I_101 |
|
キャンセル:在庫不足 |
12:00 |
6 |
100 |
I_102 |
|
ピッキング |
15:00 |
7 |
100 |
I_101 |
S_002 |
梱包 |
17:00 |
8 |
100 |
I_101 |
S_002 |
発送 |
20:00 |
これをもとに注文番号をプロセスIDとして分析して得られた全体のプロセスが下図になります。
実際には別々の商品番号に対して「在庫引当」が2回行われています。しかし、ここでは「在庫引当」が繰り返し行われたかのように見えます。 そのことを理解して分析していればいいですが、誤解を招いてしまいます。 ( Convergence )
本来は「在庫引当」の次は「キャンセル:在庫不足」と「ピッキング」がありますが、 「在庫引当」と「ピッキング」の関係が消えてしまっています。また、実際には「キャンセル:在庫不足」でプロセスは終了しますが、後続アクティビティとして「ピッキング」があるように見えます。( Divergence )
さらに、データをフラット化する方法ではタイムスタンプが一つ変わるだけで全く異なる結果を得ることがあります。例えばNo.4のイベントログのタイムスタンプを下表のように変更してみます。
No. |
注文番号 |
商品番号 |
発送番号 |
アクティビティ |
タイムスタンプ (hh:mm) |
1 |
100 |
I_101, I_102 |
|
注文受付 |
10:00 |
2 |
100 |
I_101, I_102 |
|
確認メール送付 |
10:30 |
3 |
100 |
I_101 |
|
在庫引当 |
11:00 |
4 |
100 |
I_102 |
|
在庫引当 |
11:00 13:00 |
5 |
100 |
I_101 |
|
キャンセル:在庫不足 |
12:00 |
6 |
100 |
I_102 |
|
ピッキング |
15:00 |
7 |
100 |
I_101 |
S_002 |
梱包 |
17:00 |
8 |
100 |
I_101 |
S_002 |
発送 |
20:00 |
すると、全体のプロセスは下図のように先ほどとは全く異なってしまうことがわかります。
IPMのマルチレベル・プロセス・マイニングで分析した場合
IPMでは、最大5つまで複数のプロセスIDを設定できるマルチレベル・プロセス・マイニングの機能があります。これによりデータをフラット化することなく、注文番号、商品番号、発送番号を使った一度の分析で本来のプロセスを導き出すことができます。下図が実際にIPMで分析した結果になります。
まとめ
プロセスが複数のサブ・プロセスを含む(分析対象となるIDが複数使用されている)場合においても、他のプロセス・マイニング・ツールにはない独自のマルチレベル・プロセス・マイニング機能により、サブ・プロセスをまとめて分析し、実態に即したプロセスを可視化することができます。これによりプロセス・マイニングの分析品質を高く維持することができるのです。
#IPM
#ProcessMining