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

プロセスマイニングのイベントログ作成は、ケースIDごとにまとめた、タイムスタンプ付きアクティビティのテーブルから始まります。このガイドでは、架空のレストランの注文プロセスを例に、システムのデータからテーブルを作る方法を説明します。Excelで数行をまとめる方法と、UNION ALLを使ってアクティビティを1つにまとめるSQLクエリの両方を紹介します。作成しながら、完成版のサンプルログと見比べてみてください。

プロセスマイニングのイベントログ：必要な3つの列

イベントログは、プロセスで何が起きたかを記録した構造化データです。各行は、注文の受付や支払いの受領など、1つのイベントを表します。ケースIDで関連するイベントを結び付け、タイムスタンプで発生時刻を示します。この2つを使って、ツールはケースがプロセスをどのように進んだかを再構成します。

**アクティビティは種類、イベントは個々の発生を指します。**アクティビティは「注文を出荷」のような行動の種類です。イベントはその行動が実際に起きた1回の記録で、たとえば注文12345が1月15日午後2時30分に出荷されたことを表します。ログに記録するのはイベントで、各イベントにはアクティビティ名が付いています。この2つの言葉は同じ意味で使われることもありますが、データを準備する際には違いが重要です。アクティビティは何が起きたかを示し、イベントはそのケースでいつ起きたかを示します。

基本的なプロセスマイニングのイベントログには、次の3つの列が必要です。

次に進む前に、以下の3つのフィールドを確認してください。

この3つのフィールドが基礎となります。いずれかが欠けていたり、一貫していなかったりすると、プロセスの表示で作業の順序を正しく把握できません。それ以外の項目は任意です。プロセスマイニングツールで読み込めるイベントログは、ケースとイベントをまとめた1つのテーブルであり、業務プロセスの分析に使えるイベントログに必要な3つの列は変わりません。対応形式や準備手順については、プロセスマイニングのデータ文書をご覧ください。

作成例：Pizza Palaceの注文システム

手順を具体的に説明するため、Pizza Palaceという架空のレストランを例にします。顧客がオンラインで注文し、スタッフが料理を準備し、配達員が届けます。この例に顧客データは含まれていません。

システムに次のようなテーブルが保存されているとします。

• orders：注文ID、顧客、注文時刻
• order_items：各注文のピザ、サイドメニュー、飲み物
• kitchen_queue：注文が厨房に入った時刻と出た時刻
• delivery_assignments：配達員の割り当てと配達状況
• payments：支払い処理の記録

注文を受け付けてから配達するまでを追跡できるイベントログを1つ作成します。注文IDをケースIDとして使い、関連する各時刻とアクションを1行ずつ記録します。プロセスマイニング用のサンプルイベントログとして、Pizza Palaceのサンプルログをダウンロードし、列を手元の抽出データと比べてください。

**データを抽出する前に、含めるアクティビティを決めます。**Pizza Palaceの注文プロセスには、次の6つのステップがあります。

1. 注文受付：顧客が注文を送信します。
2. 支払い受領：支払いが正常に処理されます。
3. 厨房へ送信：注文が調理待ちのキューに入ります。
4. 調理完了：厨房が注文の完了を記録します。
5. 配達員を割り当て：配達員が割り当てられます。
6. 配達完了：注文が配達されます。

各アクティビティについて、データソースのテーブル、タイムスタンプのフィールド、ケースIDのフィールドを特定します。ケースIDによってイベントが正しい注文に結び付いていることを確認してください。

**直接記録されたイベントと推定したイベントを分けます。**直接記録されたイベントには、データソースのシステムに明示的な記録とタイムスタンプがあります。注文受付はorders行のタイムスタンプ、支払い受領はpayments、配達完了はdelivery_assignmentsから取得します。分析したいイベントをタイムスタンプが表していることを確認できれば、通常は簡単に抽出できます。

推定したイベントには独自の記録がないため、別のフィールドから発生時刻を導き出します。配達員の割り当ては配達割り当ての作成時刻しかなく、調理完了は厨房のキューのステータスが「completed」に変わった時刻しかない場合があります。推定したイベントも分析に役立ちますが、どのように時刻を導いたかを文書化してください。ステータスの変更やレコードの作成時刻が、アクティビティ名から想定される内容と一致するとは限りません。イベントのタイムスタンプとして扱う前に、データソースのシステムに詳しい人にフィールドの意味を確認してください。

このマッピングは計画であり、すべてのフィールドが適切であることを保証するものではありません。タイムスタンプに値が入っているか、各テーブルを注文IDで結合しても行が重複しないかを確認してください。

ケース属性とイベント属性

属性を加えると、分析にコンテキストを持たせられます。ケースID、タイムスタンプ、アクティビティ以外の列が該当します。意味が明確で、正しいケースまたはイベントに結び付けられる場合に追加してください。

ケース属性はケース全体を表し、通常はそのケースのイベント間で変わりません。顧客名、注文の合計金額、配達先住所、注文された商品の数などが該当します。フラットなイベントログでは、同じケースの各行に値を繰り返し記録します。これにより、後からケース単位の情報を使ってイベントを絞り込んだり、比較したりできます。

イベント属性は個々のイベントを表します。配達イベントの配達員、支払いイベントの支払い方法、厨房イベントの調理ステーションなどが該当します。このような列はすべての行に当てはまるわけではありません。当てはまらない行は空欄にし、すべての行の構造をそろえるために列自体は残してください。

完成したイベントログは、1行に1つのイベントを記録したフラットなテーブルにします。Pizza Palaceのログは次のとおりです。

同じケース内では、顧客と注文金額が各イベントに繰り返し記録されています。これは意図的なものです。プロセスマイニングツールで読み込める、シンプルなテーブル形式を保てます。

方法1：Excelで作成する

Excelは、少量のデータを抽出する場合や、最初に試す場合に適しています。イベントの種類ごとにデータをエクスポートし、列を統一してから、行を1つのシートにまとめます。以下の5つの手順は、Pizza Palaceのデータなら約1時間で完了します。

**ステップ1：イベントの種類ごとに別のシートへエクスポートします。**アクティビティの種類ごとにワークシートを作成します。例：

シート1：注文受付

シート2：支払い受領

同じ方法で、厨房と配達のイベント用のシートも作成します。

**ステップ2：列を統一します。**すべてのシートで列名と順序をそろえ、属性が当てはまらない場合は空欄の列を追加します。たとえば、注文受付シートにも、すべての列を含めることができます。

値の形式に互換性があることを確認してください。特に、タイムスタンプが見た目だけの文字列ではなく、日付と時刻として保存されていることを確かめます。

ステップ3：シートをまとめます。****イベントログという新しいシートを作成し、各アクティビティのシートからイベントの行をコピーします。見出し行は1行にまとめ、1行につき1つのイベントを記録してください。

**ステップ4：ケースIDとタイムスタンプで並べ替えます。**まとめたデータを、ケースIDの昇順、次にタイムスタンプの昇順で並べ替えます。これにより、各ケースの順序を確認しやすくなります。並べ替えても不正確なタイムスタンプは修正されません。順序を判断する前に、同じ時刻のイベントや予想外の時刻を確認してください。

**ステップ5：CSVにエクスポートします。**まとめたシートを、ツールで読み込めるプロセスマイニング用のイベントログCSVとして保存します。エクスポートしたファイルを一度開き、見出し、区切り文字、日付形式、空欄の値が想定どおりか確認してください。

Excelを使う際のヒント：

• VLOOKUPまたはXLOOKUPを使い、注文シートから顧客名などのケース属性を追加します。
• YYYY-MM-DD HH:MM:SSなど、日付と時刻の形式を統一します。
• エクスポートの前に、重複行がないか確認します。
• 修正内容を追跡できるよう、元の抽出データは変更せずに保存しておきます。

方法2：SQLで作成する

データがデータベースにある場合、抽出量が多い場合、または翌月以降も同じ抽出を実行する場合は、SQLが適しています。通常は、アクティビティごとに1つのSELECTを作成し、UNION ALLで積み重ねます。

**UNION ALLの仕組み。**複数のSELECT文で取得した行を積み重ねます。各文が返す列の数と順序をそろえ、データ型に互換性を持たせる必要があります。また、最終的な列名が明確になるよう、エイリアスも統一してください。

**クエリ。**以下の例では、架空の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;

このクエリでは、注文IDをケースIDとして使い、各アクティビティについて同じ7つの列を返します。属性が当てはまらない場合はNULLを使い、列の構造を統一します。日付のフィルターと支払い成功の条件は例です。分析したいプロセスと期間に合う条件を選んでください。

**クエリの拡張。**別のアクティビティを追加するには、次の手順に従います。

1. SELECTブロックをコピーして、ひな形にします。
2. イベントを記録しているデータソースのテーブルを使います。
3. タイムスタンプを表すフィールドを選びます。
4. ほかの行と一貫性のあるアクティビティ名を設定します。
5. ケースIDと関連する属性を含めます。
6. 分析に合ったフィルターを追加します。

たとえば、システムに関連するテーブルとフィールドがあれば、次のように配達の試行を追加できます。

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'

ログを分析する前の確認事項

ログを分析する前に、次の項目を確認してください。重複、タイムスタンプの欠落、不安定なケースID、アクティビティと誤認されたステータスフィールドなど、プロセスマイニングの結果を誤って解釈する原因となるイベントログの不備を確認できます。

1. **必須の列から始めます。**イベントや属性を追加する前に、ケースID、タイムスタンプ、アクティビティを含む小さなログを作成します。
2. **変わらないケースIDを使います。**同じケースのすべてのイベントには、同じ識別子を設定します。プロセスの途中で変わる値は使わないでください。
3. アクティビティ名を統一します。「注文受付」など1つの名称を選び、「注文作成」や「新規注文」と混在させないでください。
4. **タイムスタンプを確認します。**イベントの発生時刻を表していること、タイムゾーンが統一されていること、日付と時刻として並べ替えられることを確認します。
5. **重複と欠損値を確認します。**イベントの重複や、ケースID、タイムスタンプ、アクティビティが欠けている行を調べます。
6. **抽出内容を文書化します。**データソースのテーブル、フィールド、フィルター、抽出日、前提条件を記録します。ログの更新や問題の調査がしやすくなります。
7. **属性は慎重に追加します。**疑問への回答に役立つフィールドを含め、結合によってイベントの行数が増えないことを確認します。

重複イベントやケースIDの欠落など、よくある7つのデータの問題については、このページ末尾のFAQで説明しています。定期的なデータ抽出については、プロセスマイニング向けETLをご覧ください。

データが手元にない場合の進め方

イベントログを準備するために、事前に作成されたコネクターは必要ありません。まず、システムからどのようなデータをエクスポートできるか、必須の3つのフィールドが含まれているかを確認してください。

1. 対象のプロセスと追跡するケースIDを特定します。
2. システムからイベント履歴、監査記録、タイムスタンプ付きのステータス変更をエクスポートできるか確認します。
3. データテンプレートを使い、利用可能なフィールドをケースID、タイムスタンプ、アクティビティに対応付けます。
4. イベントごとに1行のテーブルをそのままエクスポートできない場合は、データチームにデータベースの抽出またはイベントごとに1行のレポートを依頼します。

システムからのエクスポートには複数のテーブルが含まれていたり、同じフィールドに異なる名前が使われていたりすることがあります。各フィールドの意味を保ち、データソースまで追跡できるのであれば、ExcelやSQLでデータを結合したり、名前を変更したりできます。プロセスマイニング用データの入手先では、利用できるデータが見つかるほかの場所を紹介しています。また、プロセス改善ガイドでは、お使いのシステムについてステップ1から3までをすでに整理し、プロセスごとのデータテンプレートも用意しています。

形式を比べるために別のプロセスマイニング用イベントログの例をお探しの場合は、サンプルログファイルとテンプレートに用意されたスプレッドシートをご覧ください。イベントログのテンプレートページでは、必須列と任意列を確認できます。最初のデータセットを読み込む手順については、最初のデータセットを読み込むをご覧ください。

作成したログを読み込む

ログの準備ができたら、ファイルを読み込み、必須の3列をマッピングします。ProcessMindでは、Excel、CSV、データベースから抽出したデータを直接読み込めます。

1. ファイルをアップロードするか、データベースから抽出したデータを選択します。
2. ケースID、タイムスタンプ、アクティビティの列をマッピングします。
3. 追加の属性を確認します。
4. プロセスを表示し、ケースとイベントの順序に問題がないか確認します。

ProcessMindで、データセットの列をアクティビティ、ケース、属性の各役割に割り当てた状態を表示

プロセスの表示を使うと、欠けているアクティビティ、予想外の順序、詳しく調べるべき箇所を見つけられます。ただし、元のデータを修正したり、作業の進め方を変えたりするものではありません。最初の結果でデータの問題が見つかった場合は、抽出データを更新して再度読み込んでください。最初のデータセットを読み込むでは、アップロードとマッピングの手順を詳しく説明しています。

作成したログを読み込む