活動の削除

概要

Remove Activities エンリッチメントは、イベントログから特定の活動を永久に削除し、それが発生するすべてのケースから実質的に除外することができます。この強力なデータクリーンアップツールは、選択した活動およびそれに関連するイベントレコードをデータセットから物理的に削除し、ログのサイズを削減し、ノイズやテストデータ、無関係なステップを排除することでプロセス分析を簡素化します。

データを一時的に非表示にするフィルターベースのアプローチとは異なり、このエンリッチメントは選択した活動をログから永久に削除し、残りのイベントに基づいてすべてのケース統計と指標を再計算します。コアプロセスステップに分析を集中させたい場合や、分析価値を持たないシステム生成活動を排除したい場合、テスト活動やデータ品質の問題を含むログをクリーンアップしたい場合に特に役立ちます。

活動が削除されると、それに対応するすべてのイベントが各ケースから削除されます。ケースが完全に削除対象の活動で構成されている場合でも、ケース自体はログ内に残りますが、イベントはゼロになります。エンリッチメントは削除後にケースビューを自動再生成し、すべての統計、パス、可視化がクリーンアップされたデータセットを反映するようにします。

一般的な用途

  • プロセスビューを煩雑にするシステム生成活動（ログ記録、監査、通知）を削除
  • 本番イベントログからテスト活動を排除
  • 不正確または欠損データを含む活動を削除してデータ品質の問題を解消
  • 価値の低い管理ステップを削除してプロセスモデルを簡素化
  • 技術的またはサポート活動を削除してコア業務活動に分析を集中
  • 自動システム活動を削除し、人間が実行したタスクのみを分析
  • 現行のプロセス分析に関連しなくなった廃止済み活動を削除
  • 調査範囲外の活動を削除して特定の分析向けにイベントログを準備

設定

削除する活動: イベントログから永久に削除したい活動を1つ以上選択します。ドロップダウンには現在のデータセットに存在するすべてのユニークな活動が表示され、1回の操作で複数の活動を選択して削除できます。適用すると、選択した活動名に対応するすべてのイベントがログから削除され、変更を反映するためにケースビューが再生成されます。

必要に応じて任意の数の活動を選択できます。よくあるシナリオとしては、すべてのテスト関連活動（「Test Order」「Test Payment」など）、すべてのシステム通知活動（「Email Sent」「Log Entry Created」など）、または分析目的に無関係と判断された特定の活動を選択することがあります。

重要: この操作はエンリッチメント内で元に戻すことはできません。削除された活動を復元するには、元のデータセットを再読み込みするか、このエンリッチメントをエンリッチメントチェーンから外す必要があります。最初は少数の活動でテストしてみるか、フィルターで影響をプレビューしてから永久に削除することを検討してください。

事例

事例1: 注文処理からのシステム通知の削除

シナリオ: Eコマース企業の注文処理ログには多数のシステム生成通知活動（メール通知、SMSアラート、ログ入力）が含まれており、プロセスモデルが過度に複雑で本質的な業務から気を散らしています。アナリストは実際の注文処理ステップのみに焦点を当てたいと考えています。

設定:

  • 削除する活動:
    • "Email Notification Sent"
    • "SMS Alert Sent"
    • "System Log Entry Created"
    • "Audit Record Generated"
    • "Status Change Notification"

出力: 5つの選択活動に対応するすべてのイベントがログから永久に削除されます。元々15イベント（10の業務活動＋5の通知活動）があったケースは10イベントとなります。プロセスモデルは簡素化され、通知の雑音がなくなった実際のビジネスプロセスフローのみが表示されます。

削除前:

  • 総イベント数: 125,450
  • ユニーク活動数: 28
  • ケースあたり平均イベント数: 15.2

削除後:

  • 総イベント数: 83,200
  • ユニーク活動数: 23
  • ケースあたり平均イベント数: 10.1

インサイト: 通知活動を削除することで、コアな注文処理フローが明確になり、実際の処理ボトルネックや非効率を特定しやすくなります。プロセス発見アルゴリズムは、価値を付加する活動に集中したよりクリーンで解釈しやすいモデルを生成します。

事例2: 本番ログからのテストデータのクリーンアップ

シナリオ: ソフトウェア開発チームの本番展開に誤って実行されたテストトランザクションが含まれています。正確なプロセス分析とレポートのためにこれらのテスト活動を削除する必要があります。

設定:

  • 削除する活動:
    • "TEST: Create Order"
    • "TEST: Process Payment"
    • "TEST: Generate Invoice"
    • "Test Data Entry"
    • "Quality Test Run"

出力: テスト関連活動はすべて削除されます。完全にテスト活動だけで構成されたケースはイベントゼロとなりますが、データセット内に残ります（後でフィルターで削除可能）。生産活動とテスト活動が混在するケースでは、生産イベントのみが残ります。

インサイト: クリーンアップ後のログは純粋に本番トランザクションを表し、パフォーマンス指標、コンプライアンスレポート、プロセス分析が実際の業務を反映したものになります。

事例3: ITサービス管理プロセスの簡素化

シナリオ: ITサービスデスクのインシデント管理には多くの自動システム活動（自動割り当て、自動カテゴリ分類、自動エスカレーション）が含まれています。チームは人間の意思決定や手動対応に分析を集中させるため、これらの自動活動を除去したいと考えています。

設定:

  • 削除する活動:
    • "Auto-Assign to Queue"
    • "Auto-Categorize Incident"
    • "Auto-Calculate Priority"
    • "Auto-Update Status"
    • "Auto-Send SLA Warning"
    • "System Auto-Escalation"

出力: すべての自動システム活動が削除され、「Analyst Review」「Assign to Technician」「Resolve Incident」「Close Ticket」といった人間が実行した活動のみが残ります。これによりノイズのない実際の人間のワークフローおよび意思決定ポイントが明らかになります。

インサイト: 人間活動に集中することで、手動作業の必要箇所を正確に把握し、さらなる自動化の機会を特定し、システム処理時間を含めずにアナリストの実際の対応時間を測定できます。

事例4: 医療患者ジャーニー分析

シナリオ: 病院の患者フロー分析には多くの管理・請求関連活動が含まれ、臨床ケアの流れを理解する上で無関係です。品質改善チームは臨床活動のみに分析を限定したいと考えています。

設定:

  • 削除する活動:
    • "Insurance Verification"
    • "Generate Bill"
    • "Update Billing System"
    • "Send Invoice"
    • "Schedule Follow-up Billing"
    • "Process Payment"
    • "Update Patient Portal"

出力: すべての財務・管理活動が削除され、「Register Patient」「Initial Assessment」「Diagnostic Tests」「Treatment」「Medication Administration」「Discharge Planning」といった臨床活動のみが残り、臨床ケアの流れに特化したプロセスモデルとなります。

インサイト: 臨床チームは複雑な管理プロセスを除外し、患者ケアの質、治療経路、臨床意思決定の明確な分析が可能になり、臨床上のボトルネックおよび改善機会を特定しやすくなります。

事例5: 製造プロセスのコアフロー分析

シナリオ: 製造工場の生産ログには多数の品質チェックログ記録活動およびステータス更新活動が自動生成されています。運用チームはコアの製造ステップのみ分析したいと考えています。

設定:

  • 削除する活動:
    • "Log Temperature Reading"
    • "Log Pressure Reading"
    • "Auto-Update WIP Status"
    • "Generate QC Report"
    • "Update MES System"
    • "Timestamp Production Event"
    • "Log Operator ID"

出力: すべてのログ記録および自動ステータス更新活動が削除され、「Load Raw Material」「Heat Treatment」「Machining」「Assembly」「Final Inspection」「Package Product」といった実際の製造操作のみが残ります。

インサイト: 簡素化されたログにより、実際の生産フロー把握が容易となり、価値を付加する活動の正確なサイクルタイムを計算し、生産ボトルネックの位置を特定しやすくなります。

出力

Remove Activities エンリッチメントは、選択した活動名に一致するすべてのイベントを永久に削除することでイベントログを変更します。データセットへの影響は以下の通りです。

削除されたイベント: 選択した活動名に合致するイベントは、それぞれのケースから削除され、データセットから完全に消えます。エンリッチメント適用後のプロセス可視化、統計、分析にはこれらのイベントは含まれません。

ケース構造の変更: 削除された活動を含むケースはイベント数が減少します。最初または最後の活動が削除された場合、ケースの開始時間・終了時間が変わり、残りのイベントに基づいてケース期間が再計算されます。

統計の更新: すべてのログレベルの統計が再計算されます。

  • 総イベント数が減少
  • ユニーク活動数が減少（削除活動が他に重複しない場合）
  • ケースあたり平均イベント数が変化
  • 活動頻度分布が更新
  • プロセスパスおよびバリアントが再計算

ケースビューの再生成: 削除後にケースビュー全体が自動再生成され、導出指標、プロセスフロー、分析計算がクリーンなデータセットを反映します。

空のケース: 削除対象の活動のみで構成されたケースはイベントゼロになりますが、ログ内に残ります。必要に応じて後続のフィルターエンリッチメントで削除可能です。

新しい属性は作成されない: 他のエンリッチメントとは異なり、新規属性は追加されず、ログの構造自体を変更してデータを削除します。

チェーン内では元に戻せない: 適用後、削除された活動はこのエンリッチメントを外すかオリジナルデータを再読み込みしない限り復元できません。削除は以降のすべてのエンリッチメントと分析に対して永久的です。

後続エンリッチメントへの影響: このエンリッチメント以降に適用されるエンリッチメントは、残存している活動だけを認識します。削除された活動を参照するエンリッチメントはデータセット内で見つけられません。

Remove Activities エンリッチメントはイベントログの構造を変換するツールであり、詳細なプロセス分析前のデータ準備とクリーンアップに不可欠です。分析連鎖の早い段階で特定活動を永久に除外したい際に活用してください。

関連項目

  • Filter Process Log - 条件に基づいてケースやイベントを一時的にフィルタリングする（非破壊的な代替手段）
  • Undesired Activity - 不要な活動を削除せずに特定・フラグ付けする
  • Hide Attribute - 基礎データを削除せずに属性を非表示にする
  • Allowed Case Start Activities - ケースが許可された活動で始まることを保証する
  • Allowed Case End Activities - ケースが許可された活動で終わることを保証する

このドキュメントは mindzie Studio プロセスマイニングプラットフォームの一部です。