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

方法2: SQL で event log を作る

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

UNION ALLを理解する

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

完全な SQL サンプル

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

-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- 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 timestamp,                -- 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 timestamp,
    '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 timestamp,
    '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 timestamp 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 timestamp,            -- Different timestamp 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 timestamp,
    '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 timestamp field)
-- This captures when the order was delivered to the customer
SELECT 
    d.order_id AS case_id,
    d.delivered_at AS timestamp,
    '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 event log easy to read and follow
ORDER BY case_id, timestamp;

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

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

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 timestamp,
    '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'

次の一歩: event log を Process Mining ツールに読み込む

CSV やデータベースのエクスポートとして event log を用意できたら、Process Mining ツールに読み込みましょう。一般的な手順はどこもほぼ同じです。

1. ファイルをアップロードする、または抽出データとツールを接続する
2. カラムのマッピング（Case ID / Timestamp / Activity）
3. 追加の属性を設定
4. プロセスマップを生成

ProcessMind のような最新ツールなら操作は簡単。event log をアップロードするだけでプロセスが自動で可視化され、ボトルネックやばらつき、改善の着眼点が浮かび上がります。

まとめ

Process Mining の event log を作るのに、特別なツールや高度な技術は不要です。本質はシンプルです。Case ID・Timestamp・Activity の3列にデータを整理するだけ。

小規模なら Excel、大規模や定期抽出なら SQL。どちらでも基本は同じです。

1. 追跡したい event を決める
2. 各 event の timestamp を見つける
3. すべてを1つのテーブルにまとめる
4. 属性を追加して分析を豊かにする

一番難しいのは抽出そのものではなく、「どの event が重要か」を理解すること。まずは明らかな event（例：注文受付、配達完了）から始め、ツールで得られる洞察に合わせて少しずつ詳細を足していきましょう。

もっと深掘りするなら、継続的な業務改善のページをご覧ください。購買から支払（Purchase to Pay）、受注から入金（Order to Cash）、買掛金管理（Accounts Payable）など、主要プロセスのアクティビティとデータ要件を詳しく解説しています。SAP、Oracle、Microsoft Dynamics などのテンプレートも用意しており、event log 作成にスムーズに着手できます。