活動回数比較

概要

Compare Activity Counts エンリッチメントは、各ケース内で選択した2つの活動が同じ頻度で発生しているかを分析し、均衡した実行パターンか不均衡な実行パターンかを示すブール属性を作成します。このエンリッチメントは、プロセスの対称性を検証し、ペアとなる操作が適切に対応しているかを確認し、期待される活動パターンの逸脱を検出するために不可欠です。個別の活動発生回数を追跡する単純なカウントエンリッチメントとは異なり、このオペレーターは2つの活動の実行回数を比較して、均衡しているケースと一方の活動が頻繁に発生するケースを識別します。

このエンリッチメントは、特定の活動がペアで発生すべき、または一致する頻度で発生すべきプロセスに特に有用です。たとえば、調達プロセスでは、「発注作成」活動ごとに対応する「受領」活動があることが期待されます。製造業では、品質検査が生産実行と一致している必要があります。財務プロセスでは、借方と貸方がバランスする必要があります。このエンリッチメントは、これらの期待されるパターンが破られているケースを特定し、プロセスの逸脱、不完全な実行、またはシステムエラーによる不均衡な活動パターンを対象とした調査を可能にします。

主な用途

  • ペアとなる活動が同じ頻度で発生していることを検証(注文作成 vs. 注文履行)
  • 財務プロセスでのバランスの取れた操作を保証(支払い開始 vs. 支払い完了)
  • 製造プロセスの対称性をチェック(組立開始 vs. 組立完了活動)
  • 品質管理の完了を検証(生産品目 vs. 検査済み品目)
  • 承認ワークフローの一貫性を監視(承認依頼 vs. 承認決定)
  • 期待される対応活動が欠落している不完全なプロセス実行を検出
  • 活動回数の不一致を引き起こすシステム連携問題を特定

設定

フィルター(任意): 活動回数比較対象とするケースを限定するためのフィルターを適用できます。フィルターが適用された場合、フィルター条件を満たすケースのみが比較され、その結果が保存されます。これは特定の優先度の高いケース、製品カテゴリー、あるいは特定の期間のみを対象に活動バランスをチェックしたい場合に有用です。フィルター条件に合致しないケースは新しい属性の値が null になります。

新属性名: 比較結果を保存する新しいブール属性の名前を指定します。比較対象が明確にわかる説明的な名前を選択してください。たとえば、注文と配送活動を比較する場合は "Orders_Balanced"、生産と検査活動を比較する場合は "QC_Complete" などです。この属性値は、カウントが一致する場合は「Yes」(真)、異なる場合は「No」(偽)、双方の活動がケース内に存在しない場合は null となります。

活動1: 分析データセット内のすべての活動から比較対象の第1活動をドロップダウンリストで選択します。これはバランスをチェックしたいペア活動のうちの1つであるべきです。エンリッチメントはこの活動の各ケース内発生回数をカウントします。選択リストにはイベントログ内に実際に存在するユニークな活動がすべて表示されます。

活動2: 比較対象の第2活動をドロップダウンリストから選択します。これは活動1と同じ頻度で発生すべき活動です。エンリッチメントはこの活動の発生回数もカウントして活動1と比較します。特殊な検証シナリオで必要な場合を除いて通常は、活動1とは別の活動を選択し、論理的にペアをなす活動を指定します。

例1:発注と受領の検証

シナリオ: 調達プロセスにおいて、作成されたすべての発注に対応する受領記録があることを確認し、注文した品目がすべて納品されてプロセスが完了していることを検証します。

設定:

  • フィルター: 無し(すべての発注を対象)
  • 新属性名: Order_Receipt_Balanced
  • 活動1: Create Purchase Order
  • 活動2: Record Goods Receipt

出力:
新しいブールケース属性 "Order_Receipt_Balanced" が生成され、以下の値を取ります:

  • "Yes" - 発注数と受領数が等しいケース(例:3件の発注、3件の受領)
  • "No" - 数が異なるケース(例:3件発注作成だが受領は2件)
  • Null - どちらの活動も含まないケース(混合データセットの非調達ケース)

洞察:
"No" のケースは、遅延納品、記録漏れ、注文受領システム間の同期不良など、不完全な調達プロセスを示し調査が必要です。

例2:製造における品質検査完了

シナリオ: 製造プロセスでは、すべての生産実行に対応する品質検査が実施されていることを確認し、製品規格適合とコンプライアンス要件を満たしていることを保証します。

設定:

  • フィルター: Product_Category = "Electronics"
  • 新属性名: QC_Inspection_Complete
  • 活動1: Complete Production Run
  • 活動2: Perform Quality Inspection

出力:
電子製品に対し "QC_Inspection_Complete" 属性を作成:

  • "Yes" - 生産実行数と検査数が均衡(例:5実行、5検査)
  • "No" - 数の不一致(検査不足や重複生産記録の可能性)
  • Null - 生産活動がないケース(フィルターで除外された非電子製品)

洞察:
品質管理を通過しなかった生産バッチを特定し、是正措置や報告に活用可能。ミスマッチのパターンから特定ラインやシフトの系統的なQC問題を発見できる。

例3:財務取引の照合

シナリオ: 買掛金プロセスで、すべての支払い承認に対応する支払い実行があることを確認し、支払いプロセスの停滞や失敗を検出します。

設定:

  • フィルター: Amount > 10000(高額取引に絞る)
  • 新属性名: Payment_Reconciled
  • 活動1: Approve Payment
  • 活動2: Execute Payment

出力:
高額取引に関し "Payment_Reconciled" 属性を作成:

  • "Yes" - 承認数と実行数が等しい(適切に完了した支払い)
  • "No" - 不均衡(承認されたが未実行の支払いや実行エラーを示唆)
  • Null - 支払い活動が存在しないケース

洞察:
"No" のケースは未実行の承認済み支払いを表し、ベンダー関係やコンプライアンス違反のリスクがあるため即時対応が必要。

例4:カスタマーサービスチケット解決

シナリオ: カスタマーサービスプロセスで、専門担当者へのエスカレーションがあったすべてのチケットに対し専門担当者からの応答があることを検証し、エスカレーションされた問題の放置を防止します。

設定:

  • フィルター: Priority = "High" OR Priority = "Critical"
  • 新属性名: Escalation_Handled
  • 活動1: Escalate to Specialist
  • 活動2: Specialist Response

出力:
高優先度チケットに「Escalation_Handled」属性を生成:

  • "Yes" - すべてのエスカレーションに応答あり(バランスの取れたサポート)
  • "No" - 一部エスカレーションに応答なし(顧客問題未解決の可能性)
  • Null - エスカレーションなしで解決された高優先度チケット

洞察:
エスカレーションされた問題が適切な対応を受けていないサービスレベル違反を特定し、プロセス改善やスタッフ教育の機会を提供。

例5:医療予約管理

シナリオ: 患者予約システムで、スケジュールされたすべての予約に対応する完了またはキャンセル記録があることを確認し、利用率の正確な報告を行います。

設定:

  • フィルター: Department = "Radiology"
  • 新属性名: Appointment_Closure_Complete
  • 活動1: Schedule Appointment
  • 活動2: Complete Appointment

出力:
放射線科の予約案件に対して「Appointment_Closure_Complete」属性を作成:

  • "Yes" - スケジュール済みと完了が均衡
  • "No" - 不一致(無断欠席、不完全な記録、スケジューリングエラー)
  • Null - 予約に関連しない放射線科のケース

洞察:
"No" のケースは無断欠席の傾向を示し、患者への連絡改善や放射線科の資源計画の最適化を支援。

出力

Compare Activity Counts エンリッチメントは、比較結果を格納する単一のケースレベルのブール属性を作成します。属性はブール型で、「Yes/No」表示形式を採用してフィルター、ピボットテーブル、可視化での解釈を容易にします。

値のロジック:

  • Yes (True): 両活動がケース内で完全に同じ頻度で発生(両方とも0発生の場合も含む)
  • No (False): 活動発生回数が異なる(片方が多い)
  • Null: 両活動ともケースに存在しない場合。値は空欄のままとし、Yesに設定しない

この新属性は、直ちに後続のエンリッチメント、フィルター、計算で利用可能です。典型的な利用例は、不均衡ケース抽出のためのフィルタリング、均衡プロセスの割合計算、コンフォーマンスチェックでのプロセス逸脱検出です。ブール型出力の性質により、KPI算出、ダッシュボード指標、自動警告システムでのプロセス不均衡検出に最適です。


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