2つのアクティビティ間の属性変更

概要

2つのアクティビティ間の属性変更エンリッチメントは、各ケース内の特定の2つのアクティビティ間で発生するイベント属性の変化を検出するために分析します。この強力なエンリッチメントは、指定したアクティビティ間で選択されたイベント属性の値が変更されたかどうかを示すブール属性を作成します。これは、データの変換、引き継ぎの品質、プロセスの一貫性を理解し、ビジネスプロセス内で情報の変更がどこで起こっているかを特定するために不可欠です。このエンリッチメントは複数のイベント属性を同時に分析でき、変更が発生した箇所を示す新しいアクティビティを作成することもでき、プロセス全体のデータの進化を包括的に可視化します。

単なる変更検出を超えて、このエンリッチメントは組織がプロセスの非効率性、データ品質の問題、コンプライアンスリスクを特定するのに役立ちます。主要なプロセスマイルストーン間で属性の変更を追跡することで、データ訂正が行われる場所を特定し、必要な変換が行われていることを検証し、部門間の引き継ぎで情報の一貫性を確保できます。変更点にアクティビティを生成する機能は、プロセスマップに重要なデータの遷移を視覚的に示すマーカーを作成する上で特に価値があります。

主な用途

請求書処理: 送信段階と承認段階での請求金額、支払条件、承認コードの変更を検出
注文管理: 注文入力から履行までの注文数量、納期、顧客要求の変更を追跡
変更要求処理: 初期要求から実施までのステータス変更、優先度調整、担当チームの変更を監視
品質管理: 検査段階間での製品仕様、試験結果、品質スコアの変化を特定
カスタマーサービス: チケット作成からクローズまでの優先度変更、カテゴリ再割り当て、解決コードの変更を検出
医療経路: 患者の診断コード、治療計画、保険状況の変更を診察間で追跡
融資処理: 申請から承認までの信用スコア更新、担保評価、利率調整を監視

設定

Event Columns: 2つのアクティビティ間で変更を分析する対象のイベント属性を選択します。選択した各列に対して、値が変更されたかどうかを示す個別のブール属性を作成します。複数の列を選択して、プロセスのさまざまな側面でのデータ変更を包括的に追跡できます。空欄の場合は、すべての非システムイベント属性を自動的に分析します。

Activity 1: 比較の開始点となる最初のアクティビティを選択します。このアクティビティで最初の属性値が取得されます。プロセス内の意味のあるチェックポイントで、データが特定の状態にあることを示すアクティビティを選んでください。

Activity 1 Selection Type: ケース内でActivity 1の最初の出現か最後の出現かを指定します：

First: アクティビティが複数回出現する場合は最も早い出現を使用
Last: Activity 2の前の最新の出現を使用
デフォルトはFirst

Activity 2: 比較の終了点となる2番目のアクティビティを選択します。このアクティビティの属性値とActivity 1の値とを比較します。データの変更や一貫性を検証したい別の主要なマイルストーンを選んでください。

Activity 2 Selection Type: ケース内でActivity 2の最初の出現か最後の出現かを指定します：

First: Activity 1の後で最も早い出現を使用
Last: ケース内で最後の出現を使用
デフォルトはLast

Create Activities: 属性の変更が検出された箇所に新しいアクティビティをイベントログに自動的に挿入するオプションです。有効にすると、変更された属性名にちなんだ名称（例：「Invoice Amount-Change」）の新イベントを作成します。プロセスマップに視覚的マーカーを提供し、変更パターンのさらなる分析を可能にします。デフォルトは無効。

例

例1: 請求金額の検証

シナリオ: 財務チームは請求金額が初期送信から最終承認までに変更されたかを追跡する必要があります。変更がある場合は会社ポリシーに基づき追加のレビューが必要です。

設定:

Event Columns: [Invoice_Amount, Tax_Amount, Total_Due]
Activity 1: Submit Invoice
Activity 1 Selection Type: First
Activity 2: Approve Invoice
Activity 2 Selection Type: Last
Create Activities: False

出力: 3つの新しいブール型ケース属性を生成します：

Invoice_Amount-Change: 請求金額が変更されたケースにTrue
Tax_Amount-Change: 税額計算が変更されたケースにTrue
Total_Due-Change: 支払総額が変更されたケースにTrue

分析結果サンプル： | Case ID | Invoice_Amount-Change | Tax_Amount-Change | Total_Due-Change | |---------|----------------------|-------------------|------------------| | INV-001 | False | False | False | | INV-002 | True | True | True | | INV-003 | False | True | True | | INV-004 | True | False | True |

インサイト: 財務チームは送信と承認間で23％の請求書に金額変更があることを発見し、初期検証の強化が必要と判断。送信段階での追加トレーニングとシステムチェックを実施して手戻りを減少させました。

例2: 注文履行の品質管理

シナリオ: 物流会社が注文受付から出荷準備までの間に配送詳細が変更される注文を特定したい。これらの変更は配送遅延や顧客苦情の原因となります。

設定:

Event Columns: [Delivery_Address, Delivery_Date, Shipping_Method, Order_Priority]
Activity 1: Place Order
Activity 1 Selection Type: First
Activity 2: Prepare Shipment
Activity 2 Selection Type: First
Create Activities: True

出力: 4つのブール属性を生成し、検出された変更に対して新しいアクティビティを追加します：

Delivery_Address-Change: 住所変更の有無
Delivery_Date-Change: 配送日の変更
Shipping_Method-Change: 配送方法の変更
Order_Priority-Change: 優先度の変更

変更検出時のログ例： | Case ID | Activity | Timestamp | |---------|----------|-----------| | ORD-123 | Place Order | 2024-01-10 09:00 | | ORD-123 | Delivery_Date-Change | 2024-01-10 14:30 | | ORD-123 | Shipping_Method-Change | 2024-01-10 14:30 | | ORD-123 | Prepare Shipment | 2024-01-10 14:30 |

インサイト: 配送日変更の35％は繁忙期に発生。日付変更時の顧客通知システムを実装し、設備計画を調整して変更の削減を図りました。

例3: 医療治療経路の監視

シナリオ: 病院が救急外来での初回評価から専門部門への入院までの患者の診断コードや治療計画の変更を追跡し、適切な情報引き継ぎを保証したい。

設定:

Event Columns: [Diagnosis_Code, Treatment_Priority, Assigned_Department, Insurance_Status]
Activity 1: ER Assessment
Activity 1 Selection Type: First
Activity 2: Department Admission
Activity 2 Selection Type: First
Create Activities: False

出力: 医療データ変更を追跡する4つのブール属性を生成：

Diagnosis_Code-Change: 診断が変更または詳細化された場合にTrue
Treatment_Priority-Change: 優先度の変更を示す
Assigned_Department-Change: 部門の再割り当てを示す
Insurance_Status-Change: 保険確認の更新を追跡

フィルタリング・分析用データ： | Case ID | Diagnosis_Code-Change | Treatment_Priority-Change | Assigned_Department-Change | |---------|----------------------|--------------------------|----------------------------| | PT-001 | True | False | False | | PT-002 | True | True | True | | PT-003 | False | False | False | | PT-004 | True | False | True |

インサイト: 患者の42％がERから入院までに診断コードが変更され、初期評価の改善が必要。ERでの追加診断ツールを導入し精度向上を図りました。

例4: IT変更要求管理

シナリオ: ITサービスデスクが初回申請から実施開始までの変更要求属性の変化を監視し、成功した展開と相関するパターンを特定したい。

設定:

Event Columns: [Risk_Level, Implementation_Type, Affected_Systems, Approval_Status]
Activity 1: Submit Change Request
Activity 1 Selection Type: First
Activity 2: Start Implementation
Activity 2 Selection Type: First
Create Activities: True

出力: 変更指標とアクティビティマーカーを生成：

Risk_Level-Change: リスク評価の変更を示す
Implementation_Type-Change: 実施方式の変更を示す
Affected_Systems-Change: 対象システムの変更を追跡
Approval_Status-Change: 承認ステータス変化を監視

エンリッチメントは重要な変更箇所に新規アクティビティを注入し、変更管理ワークフローのプロセスマイニング可視化を可能にします。

インサイト: リスクレベル変更がある変更要求は失敗率が3倍高いことを発見し、リスク変更時の必須レビュー会議を実施して計画調整を確実にしました。

例5: 製造品質管理

シナリオ: 製造業者が異なる検査ステーション間で製品仕様や品質測定が変わるかを検出し、不良の発生・修正箇所を特定したい。

設定:

Event Columns: [Product_Weight, Color_Code, Quality_Score, Defect_Count]
Activity 1: Initial Inspection
Activity 1 Selection Type: Last
Activity 2: Final Inspection
Activity 2 Selection Type: Last
Create Activities: False

出力: 品質変化追跡属性を生成：

Product_Weight-Change: 重量の変動を検出
Color_Code-Change: 色仕様の変化を識別
Quality_Score-Change: 品質評価の変更を追跡
Defect_Count-Change: 欠陥数の変化を示す

各生産ライン別分析結果： | Production Line | % Weight Changes | % Quality Score Changes | % Defect Changes | |----------------|------------------|------------------------|------------------| | Line A | 2.3% | 15.2% | 18.5% | | Line B | 5.1% | 22.7% | 31.2% | | Line C | 1.8% | 8.9% | 11.3% |

インサイト: 生産ラインBでは特に高い変更率を示し、設備の較正問題が示唆された。即時メンテナンスを計画し、そのラインの品質チェック頻度を増やしました。

出力

エンリッチメントは選択された各イベント列に対して [ColumnName]-Change という命名パターンの新しいブール型ケース属性を作成します。これらの属性は以下を含みます：

True: Activity 1 と Activity 2 間でイベント属性の値が異なる場合
False: イベント属性の値が同じ場合、またはいずれかのアクティビティがケースに存在しない場合
Empty/Null: 属性の評価ができない場合（アクティビティや属性値の欠落）

作成された各属性は：

フィルターや計算器、その他エンリッチメントで直ちに利用可能
強化されたデータセットとともにエクスポート可能
分析や可視化用のケース属性リストに表示
変更アクティビティが作成された場合はプロセスマイニングの可視化をサポート

「Create Activities」が有効な場合、エンリッチメントは：

Activity 2 のタイムスタンプで新しいイベントをログに挿入
新イベント名は [ColumnName]-Change というパターンで命名
その他のイベント属性は Activity 2 からコピーしコンテキストを保持
プロセスマップで新アクティビティを表示するにはデータセットのリフレッシュが必要

エンリッチメントは以下をスマートに処理します：

片方または両方のアクティビティが存在しない場合（変更なしと記録）
アクティビティが複数出現する場合（選択タイプ設定で制御）
Nullや空の属性値（比較時に異なる値として扱う）
混在するデータ型（文字列表現で比較）

これらの出力を活用して：

具体的な変更タイプのケースをフィルタリングし詳細分析
プロセス全体の変更率やパターンを計算
予期しない変更に対するアラート作成
許容・禁止される変更に関するコンフォーマンスルール構築
アクティビティ作成時にはプロセスマップ上に変更パターンを可視化

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