イベント順序アルゴリズム
概要
イベント順序アルゴリズムのエンリッチメントは、mindzieStudio がケース内のイベントを並べる方法を制御するシステムレベルの設定エンリッチメントです。これは、タイムスタンプの粒度が不十分であるか、複数のイベントが同じタイムスタンプを共有している場合に特に重要です。このエンリッチメントは、日付のみを記録するデータソースや、初期データ読み込み後にイベントがログに挿入される場合などに、正確なプロセスフロー分析と可視化を保証するために不可欠です。
プロセスマイニングにおいて、アクティビティの順序はプロセスの振る舞いの理解、所要時間の計算、ボトルネックの特定、および適合性の問題検出に不可欠です。しかし、多くのソースシステムはイベントの日付のみを記録し、正確な時刻は記録しません。また、複数のイベントが同一のタイムスタンプで記録される場合もあります。イベント順序アルゴリズムのエンリッチメントは、これらのイベントに対して一貫性と意味のある順序を確立するためのインテリジェントなソート戦略を提供し、実際の操作順序を反映したプロセス分析を可能にします。
このエンリッチメントはイベントログレベルで機能し、その後のすべての分析、可視化、および計算でイベントの順序解釈に影響を与えます。通常、エンリッチメントパイプラインの開始時に一度設定されますが、データに特定の順序要件がある場合や、異なるタイムスタンプ特性を持つ新しいデータソースを追加した場合には調整が必要になることがあります。
主な用途
- ソースシステムのタイムスタンプに時間情報がない（日付のみ）の場合に決定的なイベント順序を確立
- ログに現在時刻でイベントが挿入されるデータインポートを処理
- 異なるデータ抽出やログ再構築にわたる一貫したイベント順序を確保
- 解像度の低いタイムスタンプデータのプロセスフロー可視化精度の向上
- 期待されるモデルとの比較において予測可能なイベント順序を提供し適合性チェックをサポート
- イベント順序が既に正しい場合に不要なソート処理を省略してパフォーマンスを最適化
- 過去イベントが挿入タイムスタンプで読み込まれるレガシーデータ移行の処理
設定
Order Event Algorithm: ケース内のイベント順序を決定するアルゴリズムを指定します。この設定は、タイムスタンプだけでは明確な順序を確定できない場合に mindzieStudio がイベント順序を解決する方法を定義します。利用可能なオプションは以下の通りです：
Insert Date Events Before（デフォルト）：ほとんどのシナリオに推奨されるアルゴリズムです。各ケース内のイベントをタイムスタンプでソートし、特にタイムスタンプが日付のみの複数イベントがある場合は Expected Order 属性を使って順序を決定します。このアルゴリズムは日付のみのタイムスタンプイベントが事後にログに挿入されたと想定し、追加のメタデータを用いて順序を定めます。Expected Order 属性は通常、Expected Order エンリッチメントで設定し、プロセスにおける論理的なアクティビティの順序を定義します。このオプションは混在する粒度のタイムスタンプをスマートに処理しつつ、良好なパフォーマンスを維持します。
Insert Date Events Before (Old)：Insert Date Events Before のレガシーバージョンで、古いイベントログとの後方互換性のために維持されています。同じソートロジックを実装していますが、大規模データセットで異なるパフォーマンス特性を示す古いコードパスを使用します。過去の分析結果との整合性を保つ必要がある場合や新しいアルゴリズムで互換性問題が発生する場合のみ使用してください。新規分析の場合は標準の Insert Date Events Before が推奨されます。
No Sorting：自動的なイベントソートを完全に無効化し、ソースデータ内のイベントの元の順序を保持します。ソースデータが高精度なタイムスタンプ（ミリ秒単位を含む）を提供し、挿入順が時間順と一致していると確信できる場合に、不要なソート処理を避けてパフォーマンス最大化したい場合に使用します。ただし、このオプションはソースデータが正しい順序を保証しない場合、誤ったプロセスフローをもたらす恐れがあります。後に計算イベントを追加したり複数ソースデータを統合する場合は、能動的なソートアルゴリズムに切り替える必要があります。
例
例1: 日付のみタイムスタンプの購買注文処理
シナリオ: 調達システムで購買注文の承認を追跡しますが、レガシーERPシステムは承認日時ではなく承認日だけを記録します。同じ日に複数の承認ステップ（部門マネージャー、財務コントローラー、役員承認）が行われ、タイムスタンプはすべて「2024-03-15」となっています。適切な順序付けがなければ、プロセスマイニングはランダムなシーケンスを示し、正しい承認経路の特定や正確なハンドオーバー時間の計算が不可能になります。
設定:
- Order Event Algorithm: Insert Date Events Before
追加設定: このエンリッチメント適用前に Expected Order エンリッチメントで以下を定義します：
- 部門マネージャー承認が常に最初
- 財務コントローラー承認が次
- 役員承認が最後
出力: Insert Date Events Before を選択すると、「2024-03-15 00:00:00」タイムスタンプのイベントは正しく以下のように順序付けられます：
| ケースID | 活動 | 元のタイムスタンプ | ソート位置 | Expected Order |
|---|---|---|---|---|
| PO-1234 | 部門マネージャー承認 | 2024-03-15 | 1 | 10 |
| PO-1234 | 財務コントローラー承認 | 2024-03-15 | 2 | 20 |
| PO-1234 | 役員承認 | 2024-03-15 | 3 | 30 |
これにより、承認の階層構造が正しく可視化され、各ステップ間の所要時間計算が意味を持ち、適合性チェックで期待される承認順序の遵守を検証可能になります。
インサイト: この設定により日付のみのタイムスタンプイベントでも正確な承認階層が反映されます。エンリッチメントなしでは、承認イベントはケースごとにランダムに表示され、パターンの判別や順序違反の検出が困難になります。
例2: 高精度タイムスタンプでの高性能分析
シナリオ: 製造実行システム（MES）が、各作業ステーションで「材料投入」「溶接完了」「品質検査」「梱包完了」などの工程をミリ秒単位のタイムスタンプ付きで記録します。データ量は数百万イベントに及び、タイムスタンプが既に明確な順序を示しているため、エンリッチメントのパフォーマンス最適化を目指します。
設定:
- Order Event Algorithm: No Sorting
出力: イベンツは元の挿入順のまま処理されます：
| ケースID | 活動 | タイムスタンプ | 元の順序保持 |
|---|---|---|---|
| WO-5678 | 材料投入 | 2024-03-15 14:32:18.437 | ポジション1 |
| WO-5678 | 溶接完了 | 2024-03-15 14:35:42.891 | ポジション2 |
| WO-5678 | 品質検査 | 2024-03-15 14:38:15.234 | ポジション3 |
| WO-5678 | 梱包完了 | 2024-03-15 14:41:03.567 | ポジション4 |
能動的なソートアルゴリズム使用時と比較し、エンリッチメント処理は15-20％高速化されます。特に複数エンリッチメント適用後のケースビュー再生成時に顕著です。
インサイト: 高精度なタイムスタンプがある場合、ソート無効化は大規模データセットのパフォーマンスを劇的に向上させます。リアルタイムやほぼリアルタイムのプロセスマイニングで特に有用です。ただし、初期導入時はソースデータの順序が正しいことを慎重に確認してください。
例3: 混在タイムスタンプによる過去データ移行
シナリオ: 金融サービス会社が10年分のローン申請データをレガシーシステムから新プラットフォームへ移行します。2015～2020年の過去データは日付のみで、2021年以降は正確なタイムスタンプがあります。さらに一部の過去イベントは移行日付の挿入タイムスタンプで大量ロードされています。Expected Order エンリッチメントにより標準的なローン起票手順（申請受付、信用調査、収入検証、アンダーライティング審査、承認決定）が定義されています。
設定:
- Order Event Algorithm: Insert Date Events Before
出力: 2017年の過去ケース：
| ケースID | 活動 | 保存タイムスタンプ | イベント日付 | ソート位置 | Expected Order |
|---|---|---|---|---|---|
| LN-9012 | 申請受付 | 2017-06-12 | 2017-06-12 | 1 | 10 |
| LN-9012 | 信用調査 | 2017-06-12 | 2017-06-12 | 2 | 20 |
| LN-9012 | 収入検証 | 2017-06-13 | 2017-06-13 | 3 | 30 |
| LN-9012 | 審査 | 2017-06-13 | 2017-06-13 | 4 | 40 |
| LN-9012 | 承認決定 | 2017-06-14 10:30:00 | 2017-06-14 | 5 | 50 |
2024年の最近のケース：
| ケースID | 活動 | 保存タイムスタンプ | ソート位置 |
|---|---|---|---|
| LN-9876 | 申請受付 | 2024-03-15 09:15:23 | 1 |
| LN-9876 | 信用調査 | 2024-03-15 09:47:11 | 2 |
| LN-9876 | 収入検証 | 2024-03-15 14:22:35 | 3 |
| LN-9876 | 審査 | 2024-03-16 08:30:12 | 4 |
| LN-9876 | 承認決定 | 2024-03-16 16:45:08 | 5 |
インサイト: Insert Date Events Before は混在するデータ品質シナリオをシームレスに処理します。過去データの同日イベントは Expected Order で順序付けし、最近のデータは正確なタイムスタンプを利用します。これにより、タイムスタンプ粒度に依存せず一貫したプロセス分析が可能となり、過去と現在のプロセスパフォーマンス比較やトレンド分析が正確に行えます。アルゴリズムはタイムスタンプに時間情報がない場合を自動検知し、適切な順序ロジックを適用します。
例4: 複数システムのデータ統合
シナリオ: 医療機関が患者の来院データを3つのシステムから統合します。予約管理システム（秒精度タイムスタンプ）、電子医療記録（EMR）（多くの過去エントリは日付のみのタイムスタンプ）、請求システム（分単位タイムスタンプ）です。「予約確定」「患者来院」「バイタル記録」「医師診察」「検査依頼」「検査結果」「処方発行」「請求完了」が異なる精度のタイムスタンプで記録されます。Expected Order エンリッチメントで患者滞在の典型的順序を定義しています。
設定:
- Order Event Algorithm: Insert Date Events Before
出力: 2024年3月15日の患者訪問例：
| ケースID | 活動 | ソースシステム | 元のタイムスタンプ | ソート位置 | Expected Order 適用 |
|---|---|---|---|---|---|
| PT-4455 | 予約確定 | 予約管理 | 2024-03-10 14:30:00 | 1 | 適用なし（精密時間） |
| PT-4455 | 患者来院 | 予約管理 | 2024-03-15 09:00:00 | 2 | 適用なし（精密時間） |
| PT-4455 | バイタル記録 | EMR | 2024-03-15 | 3 | 適用あり（日時み、順序30） |
| PT-4455 | 医師診察 | EMR | 2024-03-15 | 4 | 適用あり（日時み、順序40） |
| PT-4455 | 検査依頼 | EMR | 2024-03-15 | 5 | 適用あり（日時み、順序50） |
| PT-4455 | 検査結果 | EMR | 2024-03-15 | 6 | 適用あり（日時み、順序60） |
| PT-4455 | 処方発行 | EMR | 2024-03-15 | 7 | 適用あり（日時み、順序70） |
| PT-4455 | 請求完了 | 請求 | 2024-03-15 17:00 | 8 | 適用なし（時間・分単位） |
インサイト: Insert Date Events Before は異なるタイムスタンプ精度の統合データに知的に対応します。精密タイムスタンプによる時系列を維持しつつ、粗い精度のイベントは Expected Order で順序付けして包括的なエンドツーエンドのプロセスマイニングを実現します。これにより、複数システムをまたがる患者のフロー把握、引き継ぎ、待ち時間、リソース活用を正確に分析できます。
例5: 過去分析との後方互換性維持
シナリオ: プロセスマイニングチームが3年間古い mindzieStudio バージョンで注文処理プロセスを分析し、多数のレポートやKPIを公開しています。プラットフォームの新バージョンにアップグレード後、同日活動に関わる一部プロセスメトリクスに微妙な違いが見られました。調査の結果、イベント順序アルゴリズムがパフォーマンス向上を伴う更新を受けていることが判明。過去の分析結果との整合性保持と年次比較の妥当性確保のため、レガシー順序アルゴリズムが必要になりました。
設定:
- Order Event Algorithm: Insert Date Events Before (Old)
出力: 過去の分析とプロセスメトリクス、フローダイアグラムが完全に一致：
現在の分析（旧アルゴリズム使用）
- 平均注文処理時間: 4.2日
- 納期遵守率: 87.3%
- プロセスバリアント分布は過去基準に合致
- 適合率: 91.2%
新アルゴリズムとの比較
- 平均注文処理時間: 4.2日（変化なし、精密タイムスタンプによる）
- 納期遵守率: 87.3%（変化なし）
- プロセスバリアント分布: 2つの新しい稀なバリアント検出（全ケースの0.1％）
- 適合率: 91.0％（順序細分化により若干低下）
インサイト: 旧アルゴリズムオプションは、過去の分析との一貫性を必要とする長期的なプロセスマイニングに対する継続性を提供します。新しいアルゴリズムは性能と精度の向上を提供しますが、既存のKPIやベンチマーク、トレンド分析の比較を円滑に行うために切替期間中は旧アルゴリズムを活用可能です。両アルゴリズムで差異を確認後、将来的な分析は新アルゴリズムに移行するとよいでしょう。これによりステークホルダーの信頼を損なわずにプラットフォームの近代化が図れます。
出力
イベント順序アルゴリズムのエンリッチメントは新しい属性を作成したり既存データを変更したりするものではありません。むしろ、mindzieStudio がケースビューを構築し分析や可視化を行う際のイベント並び順を内部的に制御するシステム設定を構成します。このエンリッチメントによる影響は以下の点で確認できます：
プロセスフロー可視化: プロセスマップ、バリアント分析、ダイレクトフォローグラフは選択されたアルゴリズムに基づくイベント順序を反映します。同一タイムスタンプイベントを含むケースでは、一貫性のある論理的なフローパターンが示され、ランダムな順序は回避されます。
所要時間計算: 「2つのアクティビティ間の所要時間」や「アクティビティとケース開始間の所要時間」などの計算を行うエンリッチメントは、正しい順序に基づくため意味のある結果となります。不適切な順序では、同一タイムスタンプイベント間の所要時間がゼロや負値になる可能性があります。
適合性チェック: 期待プロセスモデルに対してアクティビティ順序の検証を行う適合性エンリッチメントは、正しいイベント順序により逸脱を正確に特定します。これにより、適合性違反がデータ品質問題による誤検出でなく実際のプロセス問題を示します。
パフォーマンス分析: 所要時間の閾値や時間基準によるケースの分類を行うパフォーマンスカテゴリ化エンリッチメントは、適切に順序付けられたイベントに基づくため、正確なパフォーマンス評価が可能です。
下流エンリッチメント: アクティビティ位置、前後関係、ケース段階計算などイベント順序を前提とする後続のすべてのエンリッチメントは、このエンリッチメントによる順序を基に正しく動作します。
エンリッチメントはイベントログ読み込み後および適用時にケースビュー生成フェーズで動作します。パフォーマンスへの影響はアルゴリズムによって異なります：
- No Sorting はソート処理を完全に省略するため最高のパフォーマンスを提供
- Insert Date Events Before は精度とパフォーマンスのバランスがとれ、現代のデータセットに最適化
- Insert Date Events Before (Old) は後方互換性を維持しますが大規模データでは遅くなる可能性あり
適用時、mindzieStudio は選択されたアルゴリズムでケースビューを再生成し、内部のイベント順序を更新します。元のデータのタイムスタンプ値は変更されません。そのため、ソースデータを変更せずにアルゴリズムを切り替えて、プロセスの実態を最もよく表す順序付け手法を試すことができます。
関連項目
- Expected Order - 同一タイムスタンプイベントの順序付けに利用されるプロセス内の論理的なアクティビティ順序を定義
- Freeze Log Time - 履歴データ分析や再現可能な分析作成時に利用する時間基準の固定設定
- Shift Activity Time - タイムゾーン補正や異なるデータソースの時間調整に役立つタイムスタンプのオフセット調整
このドキュメントは mindzieStudio プロセスマイニングプラットフォームの一部です。