ケースにおける属性変化

概要

ケースの属性変化エンリッチメントは、ケースのライフサイクル全体にわたるイベント属性の値の変化を検出し、定量化する強力な分析ツールです。このエンリッチメントはデータセット内のすべてのイベント属性を自動的に調査し、各プロセスインスタンス内の変化、安定性、変動のパターンを明らかにする新しいケースレベルのメトリックを作成します。イベントレベルの変動をケースレベルの洞察に変換することで、プロセスの不整合の特定、状態遷移の追跡、プロセスの安定性の大規模な測定が可能になります。

このエンリッチメントは、プロセスの動態や変動性を理解する上で特に価値があります。属性値がケース実行中にどのように変化するか、例えばステータスフィールドが頻繁に変わるか、リソース割り当てが一貫しているか、または単一のケース内で属性がどの程度の異なる値を取るかといった重要な問いに答えます。イベント属性ごとに最大3種類の異なるメトリックを作成し、プロセス全体にわたる属性変化を多様に分析・可視化する柔軟性を提供します。

主な活用方法

ステータス遷移分析 - 注文ステータスや承認ステータス、ケースステータスがプロセスのライフサイクルで何回変化するかを追跡
リソースの一貫性監視 - 所有権や責任が複数回移るケースを特定し、引き継ぎ問題の可能性を示唆
データ品質検証 - 一定であるべき属性に予期しない変動があるかを検出し、データ入力ミスやシステムの不整合を明らかに
プロセス複雑度の測定 - ケースが通過する異なる値や状態の数を計測してプロセスの複雑さを定量化
変化頻度分析 - 値の総変化回数をカウントし、頻繁に変動するケースを特定して調査の対象に
順守チェック - 特定の属性がビジネスルールに従った期待される値や変化パターンを維持しているか検証
パフォーマンス分類 - 変化パターンによってケースをグループ化し、単純な経路のケースと複雑な経路のケースを理解

設定

Ignore Null: 属性変化の分析時にnull（空）値を除外するかどうかを決定します。有効にすると、属性値がnullのイベントはスキップされ、実際の値の変化のみに注目します。null値が意味のある状態変化ではなく欠損データを表す場合に有効です。デフォルトはtrue（有効）。nullがデータギャップを表す場合に有効にし、nullが意味のある状態の場合は無効にしてください。

Create Change Count Attribute: イベント属性ごとの値の変化回数をカウントする属性を作成するかどうかを制御します。有効にすると、「-Changes」というサフィックスが付いた属性が作成され、値が前のイベントから変化した回数をカウントします。連続的な変化回数メトリックを提供します。デフォルトはtrue（有効）。変動性を測定し頻繁な状態変化があるケースを特定するときに使用します。

Create Group Count Attribute: ケース内でイベント属性が取る異なる値（グループ）の数をカウントする属性を作成するかどうかを決めます。有効にすると、「-Groups」というサフィックスが付いた属性が作成され、ユニークな値の数をカウントします。これは変化頻度ではなく多様性を測る指標です。デフォルトはtrue（有効）。値の多様性やプロセス複雑度を理解するために有効です。

Create Bool Change Attribute: それぞれのイベント属性に変化があったかどうかの真偽値属性を作成するか制御します。有効にすると、「-Change」というサフィックスが付き、属性に任意の異なる値があった場合はtrue、なければfalseを含む属性を作成します。デフォルトはtrue（有効）。変化の有無で簡単にケースを二分類するときに利用します。

例

例1：調達における注文ステータス監視

シナリオ: 調達チームは、過度なステータス変化がある購入注文を特定したい。これはプロセスの複雑化や遅延を示し、手動介入が必要となることが多いためです。

設定:

Ignore Null: true
Create Change Count Attribute: true
Create Group Count Attribute: true
Create Bool Change Attribute: false

出力: イベント属性「Order_Status」が「Created」→「Approved」→「In Review」→「Approved」→「Processed」と推移した場合、エンリッチメントは以下を作成します

Order_Status-Changes: 4（各遷移をカウント）
Order_Status-Groups: 4（異なる値：Created、Approved、In Review、Processed）

Order_Status-Changes が5を超えるケースは繰り返しステータスが往復しているためレビュー対象としてマークされます。

インサイト: 変化回数が多い注文はサイクルタイムが長くコストも高い傾向にあります。調達チームはステータス変化が3回を超える注文に対し自動アラートを導入し、例外管理に活用しています。

例2：医療における患者ケアチームの遷移追跡

シナリオ: 病院は患者滞在期間中に異なる医療チームや部署間で患者がどれだけ頻繁に移動するかを分析したい。

設定:

Ignore Null: true
Create Change Count Attribute: true
Create Group Count Attribute: true
Create Bool Change Attribute: true

出力: イベント属性「Assigned_Team」が「ER」→「ER」→「ICU」→「Surgery」→「ICU」→「Recovery」と遷移した場合、以下を作成します

Assigned_Team-Changes: 4（ERからICU、ICUからSurgery、SurgeryからICU、ICUからRecoveryの遷移数）
Assigned_Team-Groups: 4（ER、ICU、Surgery、Recovery）
Assigned_Team-Change: true（変化あり）

インサイト: チーム遷移が3回を超える患者は平均入院期間が40%長い傾向があります。病院は多くの遷移がある患者向けにケアコーディネーションのプロトコルを導入し、効率と成果の向上を図っています。

例3：製造業における品質管理追跡

シナリオ: 製造工場は生産プロセス中の品質検査結果を監視し、複数回の品質介入が必要な製品を特定したい。

設定:

Ignore Null: false
Create Change Count Attribute: true
Create Group Count Attribute: true
Create Bool Change Attribute: false

出力: イベント属性「Quality_Status」が null → "Pass" → "Fail" → "Rework" → "Pass" と変化した場合、以下の属性が作成されます

Quality_Status-Changes: 4（最初のnullからPassへの変化を含む）
Quality_Status-Groups: 5 (null、Pass、Fail、Rework、Passは重複値として含む)

Quality_Status-Groups が2を超える製品は品質問題の根本原因分析対象となります。

インサイト: 品質ステータスの変化が多い製品は特定の生産ラインやシフトに関連し、これに基づいて訓練や設備保守プログラムが実施されています。

例4：金融取引承認ワークフロー

シナリオ: 銀行はローン承認プロセスの複雑度を分析し、申請が通過する承認レベルと決定状態の多様さを追跡したい。

設定:

Ignore Null: true
Create Change Count Attribute: false
Create Group Count Attribute: true
Create Bool Change Attribute: true

出力: イベント属性「Approval_Level」が「Initial_Review」→「Credit_Check」→「Manager_Review」→「Credit_Check」→「Final_Approval」と遷移した場合

Approval_Level-Groups: 4（Initial_Review、Credit_Check、Manager_Review、Final_Approval）
Approval_Level-Change: true

Approval_Level-Groups が5を超える申請は複雑なケースでありプロセス最適化が必要です。

インサイト: 承認レベルのグループ数が少ない申請は処理時間が60%短いです。銀行は標準的な申請に対してプロセスを合理化し、複雑なケースに対しては厳格なレビューを維持しています。

例5：ITインシデント解決追跡

シナリオ: ITサービスデスクはインシデントの優先度や担当者の変更頻度を追跡し、担当が行ったり来たりする「ホットポテト」チケットを特定したい。

設定:

Ignore Null: true
Create Change Count Attribute: true
Create Group Count Attribute: true
Create Bool Change Attribute: true

出力: イベント属性「Priority」および「Assigned_Group」に対して以下の属性を作成

Priority-Changes: 優先度が上がったり下がったりした回数
Priority-Groups: 使用された異なる優先度レベルの数
Assigned_Group-Changes: チケットの再割り当て回数
Assigned_Group-Groups: チケットを扱った異なるチームの数
Assigned_Group-Change: true/false（再割り当てがあったかを示す）

Priority-Changes が2超えかつ Assigned_Group-Changes が3超えのチケットは「ホットポテト」チケットとして管理者の注意対象になります。

インサイト: 複数回の再割り当てがあるインシデントは解決時間が3倍長くなっています。サービスデスクは初動対応チームが他チームの専門知識が必要でも解決調整を行う「スティッキーアサインメント」方針を採用しています。

出力

ケースの属性変化エンリッチメントは、データセット内のすべての非システムイベント属性ごとに新しいケースレベルの属性を作成します。システム列（Activity, Timestamp, Start Time）や非表示・計算列を除いたすべてのイベント属性を自動的に処理します。

生成される属性:

[AttributeName]-Changes（整数型）: 属性の値が前のイベントから異なるたびにカウントされる変化数を保持します。値は0（変化なし）からn-1（nはケース内のイベント数）まで範囲を取ります。
[AttributeName]-Groups（整数型）: ケース内で属性が取る異なる値の数を保持します。変化頻度に関係なく値の多様性を示します。値が1の場合は属性がケースを通じて一定だったことを意味します。
[AttributeName]-Change（ブール型）: ケース内で属性に異なる値があった場合はtrue、一定または値なしの場合はfalseを保持します。変化有無の単純な二値指標です。

データ型と表示形式:

変化回数属性: 整数値で数値書式表示
グループ数属性: 整数値で数値書式表示
ブール変化属性: Yes/No 表示

他機能との統合:

これらの属性をフィルターで使い、特定の変化パターンを持つケースを特定
計算機能と組み合わせて変化率や割合を作成
ダッシュボードでプロセス安定性メトリックを可視化
順守チェックで期待される変化パターンの検証
機械学習モデルでプロセス複雑度の特徴量として利用可能

命名規則: 元の属性名を保持し、明確なサフィックス（-Changes, -Groups, -Change）を付与しています。属性の元データとメトリック種類が分かりやすく、mindzieStudioの分析機能でケース属性リストに表示され即座に利用可能です。

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