2つのアクティビティのイベント属性を比較する

概要

「2つのアクティビティのイベント属性を比較する」エンリッチメントは、高度なクロスアクティビティ属性のマッチングを行い、各ケース内の異なる2つのアクティビティ間で特定のイベント属性が同じ値を持つかどうかを判定します。この強力な比較エンリッチメントは、選択された属性が一致するかどうかを示すブール型のケース属性を作成します。複数回出現する場合はすべてのアクティビティの発生を考慮します。これは、データの一貫性を検証し、プロセス段階間の適切な引き継ぎを保証し、不正な変更を検出し、重要な情報がビジネスプロセスを通じて正しく流れることを確認するために不可欠です。

単純な属性変更検出とは異なり、このエンリッチメントはケース内でアクティビティが複数回実行されるすべてのインスタンスを考慮します。デフォルトでは、両方のアクティビティからのすべての値をソートされた順に比較します。あるいは、重複を無視して各アクティビティに存在する固有のデータに焦点を当てるために、重複を除いた一意の値のみを比較することも可能です。この柔軟性により、正確なマッチングだけでなく、複雑なプロセスバリエーション間のより微妙な一貫性チェックにも対応できます。

このエンリッチメントは、特定の属性が主要なプロセスマイルストーン間で一貫した値を維持する必要があるコンプライアンス検証、データ整合性検証、品質保証シナリオに特に有効です。明確なブール指標を作成することで、一致しないケースを迅速にフィルタリング・分析でき、データ品質の問題、プロセス逸脱、潜在的なコンプライアンス違反の対象調査を可能にします。

主な用途

購買から支払までの照合: 発注と請求書の間で注文番号、ベンダーID、商品説明が正確に一致するかを検証
三者間照合: 注文書、納品確認、請求書間の価格、数量、商品コードの一貫性を保証
引き継ぎ検証: 部門間転送で顧客ID、口座番号、参照コードが一貫していることを確認
監査証跡検証: 提出と処理の間で承認コード、認証番号、コンプライアンスフラグが変更されていないことを検出
品質保証: 生産段階間で製品仕様、ロット番号、品質評価が変更されていないことを検証
契約遵守: 契約署名とサービス提供間で契約条件、価格合意、サービスレベルコードが一致することを保証
医療継続性: ケアの移行段階で患者識別子、投薬コード、治療プロトコルが一貫していることを確認
財務調整: 承認と決済の間で取引金額、口座番号、支払方法が一致していることをチェック

設定

Filter（フィルター）: 任意のケースレベルフィルターを適用し、特定のデータサブセットに対してのみエンリッチメントを実行します。フィルター条件に一致するケースのみ比較が行われ、除外されたケースは出力属性がnullになります。特定のプロセスバリアント、期間、組織単位に絞って分析を行う際に便利です。

New Attribute Name（新規属性名）: 比較結果を格納するブール型のケース属性名を指定します。例えば「PO_Vendor_Match」や「Invoice_Price_Consistency」のように、比較対象が明確に分かる名前を選択してください。この属性はケーステーブルに作成され、すぐにフィルタリングや分析に利用可能です。

Activity 1（アクティビティ1）: 比較するイベント属性を含む最初のアクティビティを選択します。このアクティビティは属性値が取得される初期のチェックポイントを示します。ケース内のすべての該当アクティビティ発生が比較に含まれます。プロセス内の権威あるまたは元のデータ入力ポイントを選択してください。

Attribute 1（属性1）: アクティビティ1のイベント属性のうち、比較に含めるものを選択します。ベンダーID、金額、商品コード、ステータスなど任意のイベントレベル属性が使用できます。エンリッチメントはケース内のアクティビティ1のすべての発生からこの属性の値を収集して比較します。

Activity 2（アクティビティ2）: 比較対象となるイベント属性を含む2番目のアクティビティを選択します。このアクティビティは属性値が一致すべき2次チェックポイントを示します。ケース内のすべてのアクティビティ発生が対象です。整合性が求められる従属または下流のプロセスステップを選びます。

Attribute 2（属性2）: 属性1と比較するアクティビティ2のイベント属性を選択します。属性名は属性1と同じでも異なっていてもよく、システムごとに異なる名前の同等属性同士を比較できます。ケース内アクティビティ2のすべての発生から値を収集して比較します。

Use Distinct Values（重複除外の使用）: このオプションを有効にすると、各アクティビティの重複しない一意の値のみを比較します。重複を無視したセットを作成して比較するため、繰り返し数の違いを無視してユニークな値の一致を検証したい場合に有効です。デフォルトは無効で、すべての値（重複含む）をソート順に比較します。例えば、同じ商品コードの集合が両アクティビティに存在するかを確認したいときに使用します。

例

例1: 発注書と請求書のベンダーID照合

シナリオ: 調達部門は請求書のベンダーIDが対応する発注書のベンダーIDと一致することを確認したい。この三者間照合は支払い詐欺防止と請求書の正当性確保に不可欠。

設定:

Filter: なし
New Attribute Name: Vendor_ID_Match
Activity 1: Create Purchase Order
Attribute 1: Vendor_ID
Activity 2: Receive Invoice
Attribute 2: Vendor_ID
Use Distinct Values: False

出力: ブール型ケース属性 Vendor_ID_Match を作成：

True: 発注書のすべてのベンダーIDが請求書のすべてのベンダーIDと完全に一致（同じ値、同数）
False: 発注書と請求書のベンダーIDが異なる

照合結果例： | Case ID | Purchase Orders | Invoices | Vendor_ID_Match | Analysis | |---------|----------------|----------|-----------------|----------| | PO-1001 | VND-523 | VND-523 | True | 完全一致 | | PO-1002 | VND-523, VND-523 | VND-523, VND-523 | True | 複数PO、完全一致 | | PO-1003 | VND-523 | VND-724 | False | ベンダー異なる | | PO-1004 | VND-523, VND-724 | VND-523, VND-724 | True | 複数ベンダー一致 | | PO-1005 | VND-523 | VND-523, VND-724 | False | 追加請求ベンダー |

洞察: 調達チームは8%のケースでベンダーID不一致を確認し、重複請求や詐欺の可能性を示唆。非一致ケース全てに必須検証ワークフローを導入し、34万ドルの重複支払い回収に成功。

例2: 商品コード一貫性チェック

シナリオ: 製造会社は受注時に割り当てられた商品コードが品質検査時に記録されたコードと一致することを確認し、誤商品出荷を防止したい。

設定:

Filter: [Order_Status] Equals "Completed"
New Attribute Name: Product_Code_Consistent
Activity 1: Enter Order
Attribute 1: Product_Code
Activity 2: Quality Inspection
Attribute 2: Inspected_Product_Code
Use Distinct Values: True

出力: Product_Code_Consistent ブール属性を作成。重複除外有効で数量差を無視し、両アクティビティに同一の固有商品コードがあるかに着目。

商品コード一致分析： | Case ID | Ordered Products | Inspected Products | Product_Code_Consistent | |---------|-----------------|-------------------|------------------------| | ORD-501 | PRD-A, PRD-B | PRD-A, PRD-B | True | | ORD-502 | PRD-A, PRD-A, PRD-B | PRD-A, PRD-B | True（重複除外で一致） | | ORD-503 | PRD-A | PRD-C | False | | ORD-504 | PRD-A, PRD-B | PRD-A, PRD-B, PRD-C | False（不要な製品） |

洞察: 重複除外比較により、完了した注文の12%に商品コード不一致を特定。多くは倉庫のピッキングミスが原因と判明し、バーコード検証導入でミスを85%削減。

例3: 医療用薬剤照合

シナリオ: 病院は入院時に処方された薬剤と患者ケア中に投与された薬剤が一致するか検証し、安全確保と投薬エラー検出を行いたい。

設定:

Filter: [Department] Equals "Cardiology"
New Attribute Name: Medication_Match
Activity 1: Admission Prescribe
Attribute 1: Medication_Code
Activity 2: Administer Medication
Attribute 2: Medication_Code
Use Distinct Values: True

出力: Medication_Match ブールで、処方と投与の薬剤セット一致を示す。重複除外で投与頻度に関係なく不正投薬を検出。

薬剤照合結果： | Patient ID | Prescribed | Administered | Medication_Match | Review Required | |-----------|-----------|--------------|------------------|-----------------| | PT-8001 | MED-101, MED-205 | MED-101, MED-205 | True | なし | | PT-8002 | MED-101 | MED-101, MED-303 | False | 要確認 - 追加薬剤 | | PT-8003 | MED-101, MED-205 | MED-101 | False | 要確認 - 薬剤不足 | | PT-8004 | MED-101 | MED-205 | False | 要確認 - 薬剤誤投与 |

洞察: 循環器科で6.5%の患者に薬剤不一致を検出。3%は不正な追加投与があった。投与時点の電子検証導入で患者安全スコアを40%改善。

例4: 財務取引承認検証

シナリオ: 決済処理会社は承認時の取引額が最終決済額と完全に一致することを確認し、不正やシステムエラーを検知したい。

設定:

Filter: [Transaction_Type] Equals "Credit Card"
New Attribute Name: Amount_Authorization_Match
Activity 1: Authorize Transaction
Attribute 1: Authorized_Amount
Activity 2: Settle Transaction
Attribute 2: Settlement_Amount
Use Distinct Values: False

出力: Amount_Authorization_Match ブール値生成。重複除外無効のため、各承認金額に必ず対応する決済額が必要。複数承認または決済がある場合も考慮。

取引承認検証分析： | Transaction ID | Authorized Amounts | Settled Amounts | Amount_Authorization_Match | |---------------|-------------------|-----------------|---------------------------| | TXN-4001 | 125.00 | 125.00 | True | | TXN-4002 | 125.00, 25.00 | 125.00, 25.00 | True | | TXN-4003 | 125.00 | 150.00 | False | | TXN-4004 | 125.00, 125.00 | 125.00 | False（決済不足） |

洞察: 0.3%の取引で金額不一致を発見し、210万ドルの差異を記録。調査で通貨換算時の小数点丸めバグを特定、修正により損失防止と顧客信頼向上。

例5: 品質管理のバッチ追跡

シナリオ: 製薬メーカーは原材料受け入れ時のバッチ番号と生産完了時のバッチ番号が一致することを確認し、規制コンプライアンスの完全なトレーサビリティを維持したい。

設定:

Filter: [Product_Category] Equals "Injectable"
New Attribute Name: Batch_Traceability_Valid
Activity 1: Receive Raw Material
Attribute 1: Material_Batch_Number
Activity 2: Production Complete
Attribute 2: Used_Batch_Number
Use Distinct Values: True

出力: Batch_Traceability_Valid ブール属性を作成。重複除外で使用頻度に関係なく受入バッチ全てが生産に反映されていることをチェック。

バッチトレーサビリティ検証： | Production Run | Received Batches | Used Batches | Batch_Traceability_Valid | Compliance Status | |---------------|-----------------|--------------|-------------------------|-------------------| | RUN-2401 | B-8801, B-8802 | B-8801, B-8802 | True | 適合 | | RUN-2402 | B-8803 | B-8803, B-8803 | True | 適合（重複可） | | RUN-2403 | B-8804 | B-8805 | False | 適合違反 | | RUN-2404 | B-8806, B-8807 | B-8806 | False | バッチ不足 |

洞察: 2.8%の生産ロットでトレーサビリティ不備が判明。リアルタイムバッチ検証を生産開始時に導入し、トレーサビリティ適合率99.9%を達成。

出力

エンリッチメントは「New Attribute Name」で指定した名前の単一のブール型ケース属性を作成します。この属性には以下が含まれます：

True：Activity 1/Attribute 1の収集値がActivity 2/Attribute 2の収集値と完全に一致する場合
False：値が何らかの形で異なる場合（値の不一致、数の違い、欠損値）
空/Null：一方または両方のアクティビティがケース内に存在しないため比較不可能な場合

マッチングロジック:

以下の高度な比較アルゴリズムを使用：

値収集：ケース内の各アクティビティのすべての発生から指定属性のすべての値を集める
重複除去処理（有効時）：それぞれの活動から重複する値を取り除き、一意の値のみ抽出
ソート：すべての値を昇順に並べる
文字列連結：ソート済みの値をパイプ区切り文字列として結合（例："|value1|value2|value3"）
完全一致判定：連結した文字列同士を完全一致で比較

重要な比較特性:

順序非依存：先にソートしているため順序は意味を持たない
Null対応：null値は個別の値として比較に含む
型依存：値は文字列表現として比較
出現数敏感（重複除去無効時）：出現回数が完全一致する必要あり
出現数非敏感（重複除去有効時）：一意の値のみで比較し回数は無視

複数回発生するアクティビティの処理:

アクティビティが複数回出現する場合は：

すべての発生が属性値に寄与
重複除去無効時はすべての出現の値を含む（二重も含む）
重複除去有効時は一意の値だけが1回だけ含まれる

アクティビティ不在ケースの対応:

Activity 1またはActivity 2が存在しない場合：出力はnull（比較不可）
両方存在しない場合：出力はnull
指定属性の値が存在しない場合は空文字列として処理

出力の活用:

作成されたブール属性は即座に以下に利用可能：

フィルタリング：一致・不一致ケースだけを抽出
パフォーマンス分析：一致率計算やパターン識別
アラート設定：重要属性の不一致時に通知
原因分析：不一致ケースを絞り込み共通点を調査
コンプライアンスレポート：検証合否率の報告作成
プロセスマイニング可視化：プロセスマップで一致状況の色分け表示
統計分析：マッチングと他の指標の相関分析
下流エンリッチメント：他の計算や機能の入力に活用

フィルター例の使用法:

不一致ケースに絞る場合:
[Vendor_ID_Match] Equals False

有効な一致ケースのみ抽出:
[Amount_Authorization_Match] Equals True

比較可能だったケース抽出:
[Product_Code_Consistent] Is Not Empty

このエンリッチメントはケースレベルで動作し、最適化されたソート・比較アルゴリズムを使用するため、大規模イベントログも効率的に処理可能です。結果はデータセットにキャッシュされ、設定変更またはリフレッシュまで利用可能です。

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