プロセスマイニングに必要なデータとは？始める前に知っておきたいこと

プロセスマイニングに必要なデータは、3つの項目に集約されます。イベントを結び付けるケースID、何が起きたかを示すアクティビティ、発生時刻を示すタイムスタンプです。多くのチームは、すでにあるデータのエクスポートからこれらを見つけます。あとは、知りたいことに答える記録を見極めます。

まず確認：プロセスマイニングに必要なデータ

まずは必要最小限のイベントログを用意します。1つのイベントにつき1行とし、ケースID、アクティビティ、タイムスタンプを含めます。具体的な問いに答えるために必要な場合は属性を追加し、完璧なデータセットができるまで待たずに、業務の実態を把握できるか確認しましょう。

以下では、これら3つのフィールドの信頼性を高める方法を説明します。用語になじみがない場合は、データを抽出する前に、プロセスマイニングとは何か、イベントログから何が分かるのかをご確認ください。

必須項目はプロセスマイニングのデータスキーマの基本となり、任意の項目を加えると、後からばらつきの理由を説明しやすくなります。まず、出力データに必須の3項目が含まれているか、各行が1つのイベントを表しているかを確認しましょう。データの構成例はイベントログの作成方法を、項目の設定方法はデータマッピングの文書をご覧ください。

どのようなデータが必要ですか。

レモネードの屋台を営み、お客様の待ち時間の理由を知りたいとします。お客様一人ひとりの詳細をすべて集める必要はありません。注文ごとの工程がわかれば十分です。

イベントごとに、次の項目を記録します。

• **ケースID：**注文番号を使って、同じ注文に属するイベントを関連付けます。
• **アクティビティ：**何が起きたかを示す名前です。「注文を受ける」「レモネードを作る」「お客様に渡す」などがあります。
• **タイムスタンプ：**イベントの発生時刻です。これを使ってイベントの順序を決めます。

Figure 1 — すべてのケースの細部ではなく、工程に注目します。

データの構成を示すには、次のような小さな例で十分です。

これらの項目から、注文ごとの工程と各工程にかかる時間がわかります。注文の種類や販売チャネルなどの項目を加えると、時間がかかる注文がある理由を説明できます。具体的な問いへの答えに役立つ項目を追加しましょう。

レモネードの屋台以外でも、考え方は同じです。受注プロセスでは、ケースIDに注文番号を使い、アクティビティにはステータスの変化を記録します。タイムスタンプはレポートの出力ではなく、イベント履歴から取得する場合があります。ProcessMindは項目を対応付けた後、既存のデータ出力を読み込みます。ソースシステムを変更せずに、プロセスマイニングプラットフォームで業務の流れを確認できます。

レモネードの記録が見つからないとき

レモネードの屋台は忙しく、列は伸びる一方です。お客様が注文を待っているのか、準備を待っているのか、それとも何か問題が起きているのかを知りたいところです。根拠となる情報は、レシートや注文記録、メモに分散しています。

Figure 2 — 1件の注文を裏付けるデータが、きれいに整理された1つの表にまとまっているとは限りません。

実際のプロジェクトでも、これはよくあることです。データはあっても、すぐに使えるイベントログの形ではありません。異なるテーブルやシステムの記録を組み合わせ、どの項目をケース、アクティビティ、タイムスタンプとするかを決めます。

まず答えたい問いを書き出し、その答えを得るために必要な記録を探しましょう。

• 注文のリードタイムを測るには、注文の識別子と、関連するステータス変更のタイムスタンプを探します。
• チャネルを比較するには、追加の属性としてチャネルを含めます。
• 苦情の状況を把握するには、一貫して記録されている場合、苦情に関連するアクティビティや結果を含めます。

こうすることで、最初のデータ抽出の対象を絞れます。すべてのシステムからあらゆる項目を集める必要はありません。プロセスを再現し、問いを調べるのに必要なデータだけで十分です。

すでにExcelやCSV形式でデータを出力できる場合は、データチームに新しい抽出を依頼する前に、そのデータを確認しましょう。既存の項目で何がわかるか、より適切なデータ抽出で何を補えるかを把握できます。

データを探す

プロセスマイニングのデータソースには、業務の記録に使われているシステムがよく利用されます。ERP、CRM、ITSMプラットフォーム、チケット管理ツール、その他の業務アプリケーションなどです。必要な記録は、データベースやレポート、出力ファイルにある場合があります。

プロセス責任者とシステム責任者に主要なイベントの記録場所を確認し、実際のケースをいくつか選んで最初から最後まで追ってみましょう。各工程について、ケースの識別子、イベント名、タイムスタンプを確認できるかを調べます。

1. プロセスを1つ選び、問いを1つ決める

   注文が滞留する場所や、最も時間がかかる引き継ぎ箇所。

2. システムとその責任者を確認する

   業務を記録するアプリケーションと、その運用を担うチーム。

3. イベント履歴を探す

   現在の状態を示すスナップショットではなく、ステータスの変化を記録したレポートやテーブル。

4. ケースIDを確認する

   関連付けたいすべてのイベントに、同じ識別子が含まれている必要があります。

5. まず少量のデータを出力する

   より大規模なデータ抽出を依頼する前に、まず確認します。

入手できるからといって、すべてのテーブルを取り込む必要はありません。対象を絞ったデータは、レビューや整備、説明がしやすくなります。複数のシステムにまたがるプロセスでは、たとえばどの注文番号でCRMの記録とERPの記録を関連付けるのか、記録のつなぎ方を書き留めておきましょう。

一般的なデータソースについては、データの入手先に関する文書をご覧ください。複数のシステムのデータを結合または変換する必要がある場合は、プロセスマイニングのETLガイドで手順を確認できます。

データの問題を確認する

出力データには、イベントの重複、タイムスタンプの欠落、ステータス名の不統一、テスト注文、分析対象のプロセスに属さない記録などが含まれる場合があります。だからといって、データが使えないわけではありません。ただし、結果を解釈する前に、各行が何を表しているかを把握する必要があります。

データを段階的に確認しましょう。

• **重複：**同じ行が繰り返されている場合、実際にイベントが繰り返されたのか、誤って複製されたのかを確認します。
• **タイムスタンプ：**値の欠落、形式の混在、想定外のタイムゾーン、順序が前後しているイベントがないかを確認します。
• **アクティビティとステータス：**同じ意味を持つラベルは統一し、異なる工程を表すステータスは区別します。
• **テストまたはキャンセル済みの記録：**分析対象に含めるかを決め、除外する場合は理由を記録します。
• **ケースID：**空欄や途中で変わる識別子がないか確認します。こうした識別子は、1つのケースを複数に分けたり、無関係なケースをまとめたりする原因になります。

見慣れないケースだからといって、データから取り除かないでください。まず、有効な例外なのかデータの誤りなのかを判断します。準備したデータセットを元データと照らして説明できるよう、変更内容をすべて記録しておきましょう。

プロセスマイニングのデータ品質は、良いか悪いかだけで判断できるものではありません。重要なのは、分析したい問いに関わる項目が一貫しているかどうかです。そのため、約束を聞くより、実際のデータを確認することが大切です。ProcessMindでは、データセットに品質バッジとパーセンテージを表示し、欠損値、不整合な値、タイムスタンプの問題など、スコアに影響する要因をパネルで説明します。結果に基づいて判断する前に、どの程度信頼できるかを確認でき、修正に応じたスコアの変化も把握できます。詳しくはデータ品質に関する文書をご覧ください。

データのレビューは反復して進めます。まず一部のデータを確認し、項目を対応付けて、プロセスを表示し、問題がありそうな箇所を調べます。一般的な手順や確認事項については、データのクリーニングと準備のガイドをご覧ください。

データを分析用に整える

記録を見つけて確認したら、ソースの列をプロセス分析に必要な項目に対応付けます。ソースシステムで異なる名前が使われていても、それぞれの意味が明確である必要があります。

アクティビティには、曖昧なコメントではなく、プロセス内で発生したイベントを記録します。「顧客満足」のような表現は意見やメモとも受け取れますが、「注文を納品済み」は、システムにそのステータスが記録されていれば、より明確なイベントです。タイムスタンプには、レポートを出力した時刻ではなく、イベントが発生した時刻を示すものを選びます。

列をすべて手作業で割り当てる必要もありません。データセットをマッピングすると、ProcessMindが対応する項目を提案します。AIデータに関する提案では、一致する可能性の高いマッピングが信頼度スコアとともに示され、分析をより明確にする属性、アクティビティ、データソースも提案されます。フィールドの一覧から探し回るのではなく、内容を確認して確定できます。これにより、マッピングにかかる時間を大幅に短縮できます。詳しくはAIデータに関する提案をご覧ください。

適切なマッピングを行うと、業務をよく知る人にとってプロセスが理解しやすくなります。プロセスオーナーとアクティビティ名を確認し、ケースIDとタイムスタンプが想定どおりに機能することを確かめます。データマッピングの文書ではデータセットの設定方法を、アクティビティのマッピングのガイドではアクティビティの定義方法を説明しています。

必要なデータ量

どのプロセスにも当てはまる、ケース数や履歴期間の基準はありません。適切なデータ量は、プロセスの実行頻度、想定されるばらつき、比較したい内容によって異なります。

まず確認するには、通常の業務と確認したい例外の両方を含むケース数を用意します。関連するプロセスサイクルや、時間の経過に伴う重要な変化を把握できるだけの履歴も含めてください。期間が短い場合やサンプル数が少ない場合でも、スキーマやマッピングの検証はできます。ただし、結果を代表的なものとして扱う際は注意が必要です。

データを増やすと、頻度の低い経路が見つかることがあります。一方で、準備や分析にかかる時間も長くなります。まず対象期間を絞って始め、初期結果から疑問が生じたら範囲を広げてください。大規模なイベントログを扱う場合は、読み込む履歴の量を決める前に、プロセスマイニングのパフォーマンスとスケーラビリティに関するガイダンスをご確認ください。

ファイル形式とアップロード方法

最初のプロジェクトでは、チームで作成・確認できる形式でデータを出力してください。ProcessMindは、CSVやExcelなど一般的な表計算ファイルや区切り形式のファイルに対応しています。大規模なログにはParquetやORCも利用できます。ファイルのアップロードは数分で完了します。ファイルを追加し、検出された列を確認すると、コネクターを検討する前にプロセスを確認できます。手順についてはデータセットのアップロード方法をご覧ください。

データセット全体を作り直さずに新しいレコードを追加したい場合は、データを段階的に読み込むこともできます。適切な方法は、データソースの作成方法や変更頻度によって異なります。詳しくは、対応データ形式とデータの段階的な読み込みに関する文書をご覧ください。

データの読み込みを繰り返し行う場合は、APIが適していることがあります。利用できる方法については、データAPIの文書をご確認ください。データの抽出、変換、読み込みの方法を検討する場合は、ETLガイドからご覧ください。

アップロードを避けるべきデータ

プロセスに関する問いに答えるために必要なデータだけを含めてください。想定していないフィールド、特に自由記述のメモ、コメント、説明欄に個人情報が含まれていることがあります。アップロードする前にデータを確認し、分析に不要なフィールドは削除するか、マスキングしてください。

プライバシー、セキュリティ、データガバナンスの担当チームと連携し、組織で許可されている範囲を確認してください。氏名などの直接識別子が本当に必要かどうかも検討します。多くの分析では、目的やポリシーに適していれば、チーム名、ロール、または仮名化した識別子で十分です。

プロセス分析を、個人データをさらに収集する理由にしないでください。プロセスの把握に必要なフィールドだけにデータセットを絞り、アクセス、保存期間、取り扱いに関する組織のルールに従ってください。ProcessMindではテナントを分離し、ロールに応じてアクセスを制御します。また、監査ログに誰が何を閲覧できたかが記録されるため、後から確認できます。詳しくは、ユーザー、ロール、権限、監査ログ、プライバシーポリシーをご覧ください。

データチームへの依頼

依頼内容を明確にすると、データチームは作業量を見積もりやすくなり、不要なデータ抽出も避けられます。次の情報を1ページにまとめて送ってください。

• **プロセス：**対象のプロセスと開始点・終了点を明記します。
• **確認したいこと：**注文のどこで待ち時間が発生しているかなど、明らかにしたい内容を記します。
• **対象範囲：**対象システム、期間、含めるケースの種類を指定します。
• **必須フィールド：**各イベントのケースID、アクティビティ、タイムスタンプを依頼します。
• **必要なフィールド：**問いに答えるために必要な属性だけを挙げます。
• **例：**必要に応じて機密情報を削除したうえで、代表的なケースをいくつか添えます。
• **確認項目：**IDやタイムスタンプの欠落、イベントの重複、不明確なステータス値がないか確認を依頼します。
• **プライバシー：**共有可能なフィールドと、削除またはマスキングが必要なフィールドを確認します。

必要なデータ構造を具体的に伝えるために、イベントログガイドを共有できます。特定のシステムからデータを抽出する必要がある場合は、該当するプロセス改善ガイドも案内してください。データを出力したら、はじめにガイドに沿って読み込み、プロセスを確認します。

次のステップ：データのアップロードとマッピング

最初の分析にデータを使えるか確認するために、完璧なデータ抽出は必要ありません。既存のデータ出力から始め、必須の3つのフィールドを確認して、より大規模なデータプロジェクトに着手する前に対応が必要な点を把握しましょう。

最初のプロセスマップを作成した後にも、得られる価値があります。データセットを読み込むと、ProcessMindのプロセスヘルスがプロセスを自動でスコア化します。CURESフレームワークの5つの評価軸、適合性、均一性、手戻り、効率性、スムーズさに基づいて、プロセスごとに再現可能なスコアを算出します。スコアから着手点が分かり、同じダッシュボードで改善箇所も確認できるため、最初のデータセットから、状況を示すだけでなく実行可能な作業リストを作成できます。プロセスヘルスとそのスコアは、プロセスインテリジェンスのシートに含まれています。