属性が変わらないケース

概要

「属性が変わらないケース」フィルターは、指定した属性がケース全体を通じて同じ値を保持しているケースを選択します。このケースレベルのフィルターは、各ケース内のすべてのイベントを調べ、選択した属性の値がすべてのイベントで同一であるケースのみを返します。このフィルターは、特定のプロパティが一定のままであるプロセスの特定、データ品質の問題の検出、または変動のない標準化されたパターンに従うケースの発見に特に有効です。

主な用途

  • データ品質の検証: ステータスや場所など、変化すべき属性がプロセス全体で変化しないケースを特定し、データ記録の問題を示唆する場合があります。
  • プロセスの標準化: 部門間の引き継ぎや転送なしに単一の部門、リソース、システムで処理されたケースを抽出します。
  • 一貫性分析: 優先度、顧客タイプ、製品カテゴリなどの重要な属性が開始から終了まで変わらなかったケースを検出します。
  • 単一拠点処理: サイト間の転送なしで1つの場所や施設で完全に処理されたケースを特定します。
  • 専任リソース分析: プロセス全体を通じて単一のリソースまたはチームメンバーが担当したケースを見つけます。
  • 静的設定の検出: 設定値やシステム設定が一定で安定した処理条件を示すケースを発見します。

設定

イベント属性名: 一貫性をチェックしたいイベント属性を選択します。このフィルターは、その属性の値がすべてのイベントで同じであるケースのみを返します。属性はイベントテーブルに存在し、サポートされるデータ型(String, Integer, DateTime, TimeSpan, Decimal, Boolean)でなければなりません。

補足: フィルターでは完全一致で比較します。数値や日付属性は値が完全に同一である必要があります。文字列属性は大文字小文字を区別して比較します。Null値も有効とみなされ、属性がすべてNullの場合、そのケースは結果に含まれます。

例1: 単一部門のケース検索

シナリオ: 購買注文が部門間の引き継ぎなしに、単一の部門で処理されたケースを特定したい場合。

設定:

  • イベント属性名: "Department"

結果: すべてのイベントの部門値が同じケース(例: 全て「Finance」または全て「Procurement」)だけが返されます。

示唆: これらのケースは部門間の転送がない効率的なプロセスを表します。以下を識別する手がかりになります:

  • エンドツーエンドで部門が所有するプロセス
  • 協調コストがかからなかったケース
  • プロセス効率向上のためのベストプラクティス候補
  • 複数部門連携不要の単純なケース

例2: 変わらない優先度の検出

シナリオ: 優先度が開始から終了まで変化しなかったケースを探す。これは単純な処理か、緊急課題のエスカレーション失敗を示す場合がある。

設定:

  • イベント属性名: "Priority"

結果: すべてのイベントで同じ優先度(「Low」「Medium」「High」いずれか)のケースを選択します。

示唆: 次の点が明らかになります:

  • 初期の優先度分類を維持したケース
  • 緊急ケースのエスカレーションが行われなかった可能性
  • 優先度レベルごとの標準的な処理パターン
  • 動的な優先度調整の導入機会

例3: 静的ステータスの特定

シナリオ: ステータス属性が変化していないケースを見つける。これはデータ品質問題やプロセスの不完全な実行を示す場合がある。

設定:

  • イベント属性名: "Status"

結果: すべてのイベントでステータス値が同じケースが返されます。

示唆: これらのケースは以下を示すかもしれません:

  • ステータス更新が記録されなかったデータ記録エラー
  • 途中でキャンセルまたは放棄されたケース
  • ステータス更新ができなかったシステム統合問題
  • データ品質改善が必要なケース

例4: 単一拠点処理

シナリオ: 複数の製造施設への転送なしに、1か所の生産施設で完了した製造注文を特定。

設定:

  • イベント属性名: "Location"

結果: すべてのイベントが同じロケーションで実行されたケースを選択します。

示唆: これにより以下がわかります:

  • 一つの施設で開始から完了まで製造された製品
  • 物流の複雑さを回避したケース
  • 場所固有の能力や専門性
  • 中央集権的処理モデルの可能性

例5: 一貫したリソース割り当て

シナリオ: 全イベントを同じリソースが担当し、専任体制が示されているケースを探す。

設定:

  • イベント属性名: "Resource"

結果: すべてのイベントを同一リソースまたは人物が実行したケースが返されます。

示唆: これらは以下を示します:

  • 個別リソースによるエンドツーエンドのケース所有
  • 引き継ぎ回避による効率化可能性
  • リソースの専門化パターン
  • 専任ケース処理のための教育機会

例6: 一様な顧客タイプ処理

シナリオ: 顧客タイプ分類が処理全体で一定のケースを特定。

設定:

  • イベント属性名: "CustomerType"

結果: すべてのイベントで同じ顧客タイプ(例:「Premium」「Standard」「Enterprise」)のケースを選択。

示唆: これにより理解できます:

  • 分類が安定している顧客セグメント
  • 特定顧客タイプ向けに調整されたプロセス
  • 顧客分類の一貫性
  • 顧客タイプごとの処理パターン

出力

このフィルターは、指定した属性の値がすべてのイベントで同一であるケースのみを含む新しいデータセットを返します。返されたケースは、元のすべてのイベントと属性を保持します。選択した属性の値に差異があるイベントを含むケースは結果から除外されます。

条件に合致するケースがない場合(すべてのケースにおいて少なくとも1つのイベントで異なる値がある場合)、フィルターは空の結果セットを返します。

技術的注意事項

  • フィルター種別: ケースレベルフィルター(個々のイベントではなくケース全体を除外)
  • 比較ロジック: 最初のイベントの値を基準にし、それ以降のイベントを比較
  • Null処理: Null値を有効かつ一貫した値とみなし、すべてのイベントがNull値の場合はケースを含む
  • 対応データ型: String, Int32, Int64, DateTime, TimeSpan, Single, Double, Boolean
  • パフォーマンス: LINQで効率的に実装し、不一致が見つかり次第早期終了

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