属性が変更されたケース
概要
「属性が変更されたケース」フィルターは、ケース内のイベント間で特定のイベント属性の値が異なるケースを選択します。このケースレベルのフィルターは、各ケースのすべてのイベントを調べ、指定された属性がイベントごとに異なる場合にのみそのケースを保持します。このフィルターは、ステータスの遷移、場所の変更、リソースの引き継ぎなど、ケースの実行中に属性値が変化する動的なプロセスを特定するのに特に役立ちます。
フィルターは非NULLの値にフォーカスしており、まずNULL値を除外し、残った値がすべて同一かどうかをチェックします。すべてのイベントが同じ値（またはすべてNULL）のケースは結果から除外されます。
一般的な用途
- ステータス進行の分析：処理中にステータス値が変化したケースを特定し、異なる段階の進行を示す。
- リソースの引き継ぎ検出：異なるリソースや部署が異なるイベントを担当したケースを見つけ、協力パターンを明らかにする。
- 場所の変更追跡：場所属性が変化したケースを特定し、物理的な移動や拠点間の移動を示す。
- 優先度のエスカレーション：実行中に優先度が変更されたケースを検出し、昇格や降格のパターンを確認する。
- プロセス逸脱の特定：属性値が予期せず変化したケースを特定し、例外や非標準処理の可能性を示す。
- 多段階プロセスの分析：段階関連属性の変化を検出して、複数段階を経たケースを特定する。
設定
イベント列名：変動を評価するイベント属性を選択します。この属性がイベント間で異なる値を持つケースをフィルターが返します。変動チェックでは非NULL値のみが考慮されます。
注意：属性はイベントテーブルに存在し、サポートされているデータ型（String、Int32、Int64、DateTime、TimeSpan、Single、Double、Boolean）である必要があります。列名を誤って入力した場合は、フィルターの検証システムが類似の列名を提案します。
事例
事例1：ステータス変更があるケースを見つける
シナリオ: 注文処理のステータスが処理の過程で変わったケースを特定したい。これは注文が異なる段階を経たことを示す。
設定:
- イベント列名: "Order Status"
結果: イベントごとに異なる「Order Status」値（例: "New" -> "Processing" -> "Shipped"）を持つケースを返します。全イベントが同一ステータスのケースは除外されます。
洞察: 次のことの把握に役立ちます：
- ワークフローを正常に進行したケース
- ステータス遷移の通常の処理パターン
- 複数のステータス変更を経験したケース
- 異なる履行段階を経た注文
事例2：リソースの引き継ぎを検出する
シナリオ: 異なるリソースや担当者が異なる活動を行ったケースを探し、協力や引き継ぎの状況を把握する。
設定:
- イベント列名: "Resource"
結果: 「Resource」属性がイベント間で異なるケースを選択し、複数の人物やシステムが異なる活動を処理したことを示します。
洞察: これらのケースは以下を明らかにします：
- 複数の人による協働作業パターン
- 部署やチーム間の引き継ぎ
- 異なるリソースにより専門的な対応が必要なケース
- リソース変更が発生したボトルネックの可能性
事例3：場所の変更を特定する
シナリオ: 処理中に異なる場所に移動した出荷品やアイテムを追跡したい。
設定:
- イベント列名: "Location"
結果: イベントが異なる場所で発生したケースを返し、物理的な移動や拠点間の移転を示します。
洞察: 次のようなことを示します：
- 複数の倉庫や配送センターを経由したアイテム
- 複数拠点での処理パターン
- ケースの地理的なルーティング
- 複数ロケーションの調整が必要なケース
事例4：優先度のエスカレーションを見つける
シナリオ: サポートチケットやリクエストの優先度が処理中に変わったケースを特定し、エスカレーションや降格の兆候を捉える。
設定:
- イベント列名: "Priority"
結果: イベント間で「Priority」値が変化したケースを選択します（例: "Low" から "High" へ）。
洞察: これらのケースは以下を示す可能性があります：
- 注目が必要となったエスカレーション事案
- 初期評価後に優先度が下がったケース
- 顧客フィードバックに基づく動的優先度調整
- 管理者の介入が必要となったケース
事例5：部署間の移管を検出する
シナリオ: 処理中に部署間で移管されたケースを見つけ、複雑なケースでの部門間支援の必要性を示す。
設定:
- イベント列名: "Department"
結果: 異なる部署が異なるイベントを担当したケースを返します。
洞察: 次の点を明らかにします：
- 複数部署の専門知識が必要なケース
- 部門間の協働パターン
- 部署間での引き継ぎ遅延の可能性
- プロセス最適化が望まれる複雑なケース
事例6：承認レベルの変化を追跡する
シナリオ: 承認レベルが変わったケース、例えば高い管理層へのエスカレーションが必要となったリクエストを特定したい。
設定:
- イベント列名: "Approval Level"
結果: イベント間で「Approval Level」属性に変化があるケースを選択します。
洞察: これらのケースは以下を示すことがあります：
- 複数の承認レベルを必要としたリクエスト
- 高価値または複雑なリクエストのエスカレーションパターン
- 標準の承認基準を超えたケース
- 多段階承認のワークフロー
出力
指定されたイベント属性がイベント間で異なる値を持つケースのみを含む新しいデータセットを返します。返された各ケースは元のすべてのイベントと属性を保持し、選択した属性値の変動が確認できます。
すべての非NULL値が同一のケースや、NULL値のみ、または単一ユニーク値のケースは除外されます。
条件に一致するケースがない場合は、空の結果セットが返されます。
技術的な注意点
- フィルタータイプ：ケースレベルフィルター（個々のイベントではなくケース全体を除外）
- NULL処理：変動チェックの際にNULL値は無視し、非NULLのみを対象
- 変動検出：最初の非NULL値とその他の非NULL値を比較
- サポートされるデータ型：String、Int32、Int64、DateTime、TimeSpan、Single、Double、Boolean
- 検証：指定した列が見つからない場合、自動的に類似の列名を提案
このドキュメントはmindzieStudioプロセスマイニングプラットフォームの一部です。