プロセスマイニングのイベントログの作り方

方法2: SQL で イベントログ を作る

大規模データや定期的な抽出には、SQL のほうが効率的で再現性も高いです。ポイントは、UNION ALL を使って複数のクエリ結果を1つの結果セットに結合することです。

UNION ALLを理解する

UNION ALLは、複数のSELECT文の結果を縦に積み重ねて1つの結果セットにします。すべてのSELECTで列数をそろえ、互換性のあるデータ型にしておく必要があります。

完全な SQL サンプル

Pizza Palace のイベントログを作成するための SQL クエリ例です：

-- イベントログ Extraction for Pizza Palace
-- This query combines multiple event types into a single イベントログ
-- Each SELECT block represents one activity type

-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT 
    o.id AS case_id,                          -- The order ID is our case identifier
    o.created_at AS タイムスタンプ,                -- When the order was placed
    'Order Placed' AS activity,               -- The activity name (hardcoded)
    o.customer_name AS customer,              -- Case attribute: who ordered
    o.total_amount AS order_value,            -- Case attribute: order value
    NULL AS driver,                           -- Not applicable for this event
    NULL AS payment_method                    -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01'            -- Filter to your desired date range

UNION ALL

-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT 
    p.order_id AS case_id,
    p.payment_time AS タイムスタンプ,
    'Payment Received' AS activity,
    o.customer_name AS customer,              -- Join to get case attributes
    o.total_amount AS order_value,
    NULL AS driver,
    p.payment_method AS payment_method        -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id            -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
  AND p.status = 'successful'                 -- Only include successful payments

UNION ALL

-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
SELECT 
    k.order_id AS case_id,
    k.queue_entry_time AS タイムスタンプ,
    'Order Sent to Kitchen' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'

UNION ALL

-- Event 4: Order Ready
-- Source: kitchen_queue table (different タイムスタンプ field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT 
    k.order_id AS case_id,
    k.completed_time AS タイムスタンプ,            -- Different タイムスタンプ than entry
    'Order Ready' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
  AND k.completed_time IS NOT NULL            -- Only include completed orders

UNION ALL

-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
SELECT 
    d.order_id AS case_id,
    d.assigned_at AS タイムスタンプ,
    'Assigned to Driver' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,                  -- Event-specific attribute
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'

UNION ALL

-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different タイムスタンプ field)
-- This captures when the order was delivered to the customer
SELECT 
    d.order_id AS case_id,
    d.delivered_at AS タイムスタンプ,
    'Delivery Completed' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
  AND d.delivered_at IS NOT NULL              -- Only include completed deliveries

-- Final ordering: by case, then by time
-- This makes the イベントログ easy to read and follow
ORDER BY case_id, タイムスタンプ;

このクエリを拡張するには

イベントを追加する手順：

1. 既存の SELECT ブロックをコピーして雛形にする
2. テーブル名を変更して参照元を差し替える
3. タイムスタンプの列を正しいカラムに更新する
4. アクティビティ名をイベント内容に合わせて変更する
5. 属性列を必要に応じて調整する
6. WHERE 条件を加えてデータを適切に絞り込む

例えば「Delivery Attempted」イベントを追加する場合：

UNION ALL

-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT 
    d.order_id AS case_id,
    d.attempt_time AS タイムスタンプ,
    'Delivery Attempted' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01'

次のステップ：イベントログをプロセスマイニングツールに読み込む

CSVファイルやデータベースからのエクスポートとしてイベントログを作成できたら、次はそれをプロセスマイニングツールに読み込みます。ほとんどのツールでは、以下の手順で進めます：

1. ファイルをアップロードするか、抽出データにツールを接続する
2. 列（Case ID、Timestamp、Activity）のマッピングを行う
3. 追加の属性を設定する
4. プロセスマップを生成する

ProcessMind のような最新のプロセスマイニングツールを使えば、このプロセスは非常にシンプルです。イベントログをアップロードするだけで、ツールが自動的にプロセスを可視化。bottleneckやイレギュラーな処理、改善の機会を特定し、コスト削減や業務の最適化を支援します。

まとめ

プロセスマイニング用のイベントログ作成には、特別なツールや高度な技術知識は必要ありません。本質的には、プロセスマイニングのデータを「Case ID」「Timestamp」「Activity」という3つの必須項目を含むテーブル形式に整理するだけです。

小規模なデータセットならExcel、大規模で複雑な抽出ならSQLといった具合に手法は異なりますが、基本原則は共通しています：

1. 追跡したいイベントを特定する
2. 各イベントが発生した日時（Timestamp）を確認する
3. すべてのデータを1つのテーブルに統合する
4. 分析を深めるためのAttributesを追加する

最も難しいのは技術的な抽出作業ではなく、どのイベントが重要かを判断できるほどにビジネスプロセスを深く理解することです。まずは「注文受付」や「出荷完了」といった分かりやすいイベントから始め、ツールが提示するインサイトに合わせて、徐々に詳細なデータを追加していきましょう。

さらに詳しく知りたい方は、弊社の 継続的プロセス改善ページ  をご覧ください。ここでは、購買管理（P2P） 、受注管理（O2C） 、買掛金管理 といった代表的なプロセスのデータ要件やアクティビティについて詳しく解説しています。SAP、Oracle、Microsoft Dynamicsといった主要システム向けのデータテンプレートも用意しているため、イベントログ作成をスムーズに開始できます。