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

方法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'

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

イベントログをCSVファイルやデータベースのエクスポートとして作成できたら、プロセスマイニングツールに読み込む準備は整いました。多くのツールで手順は似ています：

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

ProcessMind のような最新のプロセスマイニングツールなら、この流れはとても簡単です。イベントログをアップロードするだけで、プロセスが自動的に可視化され、ボトルネック、ばらつき、改善のチャンスが明らかになります。

まとめ

プロセスマイニングのイベントログ作成に特別なツールや高度な技術は必要ありません。本質はシンプルです。Case ID（ケースID）、Timestamp（タイムスタンプ）、Activity（アクティビティ）の3列にデータを整理するだけです。

小規模ならExcel、大規模・複雑ならSQLで抽出しても、考え方は同じです：

1. 追跡したいイベントを決めます
2. 各イベントのTimestampを特定します
3. すべてを1つのテーブルに統合します
4. 分析を深める属性を追加します

最も難しいのは技術的な抽出ではなく、どのイベントが重要かを判断できるほど自社のプロセスを理解することです。まずは明らかなイベント（例：受注登録、受注完了）から始め、プロセスマイニングツールが示してくれる気づきを踏まえて、徐々に詳細を追加しましょう。

もっと深掘りしたい方は、継続的なプロセス改善のページ をご覧ください。調達から支払い（Purchase to Pay） 、受注から回収（Order to Cash） 、買掛金・債務管理（Accounts Payable） など、主要プロセスのアクティビティや必要データを詳しく解説しています。SAP、Oracle、Microsoft Dynamicsなどで使えるデータテンプレートも用意しています。イベントログの作成をすぐに始められます。