プロセスマイニングに必要なETLツールとは

プロセスマイニングにETLは必要ですか？

ETLツールは、ソースシステムからデータを抽出し、分析に使える形に整えて読み込みます。この記事では、プロセスマイニングに必要なETL作業と、省略できる場合を解説します。パイプラインの購入ガイドではありません。システムからレコードをエクスポートでき、ファイルにケースID、アクティビティ、タイムスタンプが含まれていれば、最初の分析ではパイプラインを使わず、エクスポートデータをそのまま読み込めることがよくあります。

必要な対応は、プロセス、その背後にあるシステム、分析データを更新する頻度によって異なります。まず、問いに答えられる最小限のデータを抽出しましょう。最初の分析で必要性が分かった段階で、データの準備や自動化を追加します。

次の3つのケースでは、ETL作業を検討する価値があります。

• **プロセスが複数のシステムにまたがる。**ケースを最初から最後まで追えるように、レコードを結合し、識別子をそろえる必要があります。
• **ソースデータをそのまま読み込めない。**分析に使う前に、アクティビティ名、タイムスタンプ、ケース識別子を標準化する必要があります。
• **データを繰り返し抽出する必要がある。**データが毎日更新され、分析にも反映させる必要がある場合、手作業でのエクスポートでは対応しにくくなります。

こうしたケースではデータの準備が必要ですが、最初の問いに答える前からパイプラインを構築する必要はありません。まず入手できるデータを読み込み、不足している項目を確認してから判断しましょう。

次のような場合も、別途パイプラインを用意せずに始められます。

• プロセスの大部分が1つのシステムに記録されている。
• 必要なレコードをエクスポートできる。
• エクスポートデータにケースID、アクティビティ、タイムスタンプが含まれている。
• ファイルが小さく、手作業で準備できる。
• データで問いに答えられるか、まだ検証中である。

スプレッドシートを使って、列名の変更、明らかな不整合の修正、不要な項目の削除を行えます。手作業での準備を続ける必要はありません。分析の有用性が確認でき、データを頻繁に更新する必要が生じたら、繰り返し行っている手順を自動化しましょう。

抽出データに必要な項目

プロセスマイニング用のイベントログには、3つの項目と、イベントごとに1行のデータが必要です。

コスト、ユーザー、チーム、顧客セグメント、CO2排出量などの属性は任意です。こうした属性があれば、プロセスの概要を分析に発展させられます。保持する属性はそれぞれ、後からフィルター、分類、測定項目として使えます。データセット属性のリファレンスでは、各項目の用途を確認できます。

ソースに項目が存在していても、使えるとは限りません。システム間でケースIDが変わると、イベントを関連付けられません。アクティビティ名に一貫性がなければ、実際には同じステップが3つに分かれてしまいます。タイムスタンプがテキスト形式だと、イベントの順序が正しくならないことがあります。マッピングする前にエクスポートデータを確認し、まず3つの必須項目を点検しましょう。ログに必要な項目の全体像については、プロセスマイニングに必要なデータをご覧ください。

最低限のイベントログを作成するクエリ

ソースにアクティビティごとに1行のデータがすでにあれば、必要なのはSELECTクエリだけです。以下の例では、ケース、アクティビティ、イベント時刻を含むprocess_eventsというテーブルを想定しています。

SELECT
  case_id        AS case_id,
  activity_name  AS activity,
  event_time     AS timestamp
FROM process_events
WHERE case_id IS NOT NULL
  AND activity_name IS NOT NULL
  AND event_time IS NOT NULL
ORDER BY case_id, event_time;

このクエリでは、3つの項目に名前を付け、利用できない行を除外し、ケースごとにイベントを並べ替えます。テーブル名と列名をソースに合わせて変更し、読み込む前にケースのサンプルを確認してください。各ケースに想定したイベントが含まれ、現場の人が認識できる順序になっていることを確かめましょう。

必要なデータ変換

データ変換では、分析結果を歪める要因を取り除きます。多くの場合、次の4つの手順で対応できます。

1. イベントを標準化する

   ソースでプロセスのステップが別々の列に保存されていても、アクティビティの発生ごとに1行を用意し、ケースIDとタイムスタンプを含めます。

2. タイムスタンプを使える状態にする

   値が実際の日付と時刻か、現地時刻かUTCかを確認します。複数のソースを組み合わせる場合は、タイムゾーンをそろえましょう。そろっていないと、イベントの順序が実態と異なります。

3. アクティビティ名を統一する

   実際のステップごとに1つのラベルを使い、言語と表記を統一します。リストを短くするために、似ているだけのステップをまとめないでください。

4. 必要な場合だけデータソースを結合する

   レコードを関連付けるキーを特定し、正しく一致するか確認します。結合によってイベントが重複したりケースが欠落したりすると、プロセスの見え方が変わります。結合の前後でレコード数を比較しましょう。

エクスポートデータに、3つの項目を含むイベントごとの行がすでにあれば、変換は不要です。それは通常の状態であり、手抜きではありません。プロセスマイニング用のイベントログの作成方法では、ExcelとSQLの例を使って同じ手順を説明しています。

イベントログはどこに読み込めばよいですか？

準備したデータを、分析に使うプラットフォームに読み込みます。まず内容を確認するだけなら、単一のファイルで十分です。データを準備して読み込み、プロセスの表示を確認し、データから分かることを把握してから抽出内容を調整します。プロセスマイニングのためだけに、新しいストレージ層を用意する必要はありません。すでにデータウェアハウスやデータレイクを運用している場合は、データをそこに保管し、その環境で出力したデータを読み込んでください。

対応データ形式のページで詳細をご確認いただけます。手動でのアップロードを避けたい場合は、同じ形式のデータをスケジュール済みジョブからデータAPI経由で送信することもできます。

読み込んだデータセットをモデルに関連付けます。パネルには対象となるケースが表示され、まだマッピングされていないアクティビティも確認できます。 Source: ProcessMind

どの方法を選ぶ場合も、データは分析を行う場所に読み込んでください。誰も確認しないフォルダーにファイルを置くだけでは、データ戦略とは言えません。データセットをマッピングし、内容を確認してこそ意味があります。

プロセスマイニングには、どのETLツールが適していますか？

どのプロジェクトにも当てはまるETLツールの一覧はありません。データの保管場所、チームがすでに運用しているツール、ログに必要な準備作業を基準に選びます。作業自体は一般的なデータエンジニアリングです。プロセスマイニング特有の要件は、出力データにケースID、アクティビティ、タイムスタンプが含まれていることです。

プロセスマイニングのプロジェクトでよく名前が挙がるツールには、データ抽出やSQL変換に使うCDataとdbt、データウェアハウス側のBigQuery、Snowflake、Databricks、システム間のデータ移動が課題となる場合のTalend、Apache NiFi、Airbyteなどがあります。オープンソースも選択肢の1つで、NiFiやAirbyteがよく使われます。また、EvidantやKonektiなど、一般的なシステム向けのテンプレートを備えたプロセスマイニング用ETLを提供するベンダーもあります。

これらはあくまで例であり、推奨や提携を意味するものではありません。プロジェクト終了後もチームで保守できるツールや形式を選び、可能であれば変換ロジックはプロセスマイニング製品の外に置いてください。慎重に検討したいのが、プラットフォーム内蔵のETLです。そのプラットフォームを使い続ける間は便利ですが、データ準備のロジックを別の場所に移しにくくなり、次の分析やAIプロジェクトで再利用しづらくなる可能性があります。

読み込み後のデータはどのように管理しますか？

データ抽出は作業の半分にすぎません。その後のデータセットの管理方法によって、四半期後も分析結果を信頼できるかどうかが決まります。

• データセットには内容が分かる名前を付けます。 Q1_2025_Sales_DataやCustomer_Support_Logsのような名前は、export_final_v3より適切です。
• **用途に合った形式を選びます。**手動でアップロードする小さなファイルなら、CSVやExcelで十分です。大規模なデータセットやパイプラインから出力するデータには、ParquetやORCが適しています。
• **マッピングの前にプレビューします。**構造、列のデータ型、数行分の内容を確認し、データセットの設定でケースID、アクティビティ、タイムスタンプが正しく指定されていることを確かめます。
• **アクティビティのマッピングを確認します。**まず自動マッピングを実行し、その後未マッピングのアクティビティを確認します。実際には発生していてもデータに記録されないステップは、データフロースルーとして設定できます。数値を変えずに、プロセス上で見える状態にできます。
• **作り直すのではなく、更新します。**定期的にエクスポートする場合は、分析に必要な頻度（日次または週次）で最新ファイルに置き換え、同じマッピングを維持します。
• **データに含まれない範囲を記録します。**対象外の期間、システム、ステップを分析メモに残してください。最終的に何を主張できるかを左右する情報です。
• **アクセスを管理し、不要になったデータはアーカイブします。**必要な人にデータセットへのアクセス権を付与し、プロジェクト終了後に使わなくなったデータセットはアーカイブします。

要点

ETLはプロセスマイニングの目的ではなく、そのための手段です。最初の分析を遅らせないように設定しましょう。

• 今週入手できるデータから始めます。
• 不要な項目を除いても、必須の3項目は残します。
• まずエクスポートデータを読み込み、分析で必要性が確認できてから読み込みを自動化します。
• チームがすでに保守しているツールと形式を使います。

パイプラインが単純すぎたことより、答えるべき問いが分かる前にパイプラインを構築したことが原因で、プロジェクトが失敗するケースのほうが多くあります。