複数ケース属性の比較

概要

Compare Multiple Case Attributes エンリッチメントは、基本的な比較機能を拡張し、複数のケース属性がすべて同一の値を持つことを検証します。この強力なデータ品質オペレーターは、選択されたすべての属性がケース内で一致しているかどうかを示すブール値の結果を生成し、複数のデータポイント間の整合性が重要な包括的な検証シナリオを可能にします。単純な2属性間の比較とは異なり、このエンリッチメントは3つ以上の属性間での完全な一致をチェックし、複雑なデータ検証、多システムの照合、総合的な品質保証に不可欠な機能を提供します。

このエンリッチメントは、複数のソースシステムからのデータ、冗長なデータ入力ポイント、または複雑な検証要件を含むプロセスマイニングのシナリオで特に有用です。例えば、調達で一般的な三方一致のシナリオでは、発注書、受領書、および請求書の数量値が一致しているかを検証できます。医療現場では、入院、治療、退院記録の間で患者識別子が一貫していることを確認できます。製造業では、設計、生産計画、および品質管理システム間の製品仕様が一致していることを保証します。このエンリッチメントは、指定されたすべての属性が完全に同じ値を保持する場合にのみ True を返すため、複数の関連データポイント間の不整合を検出するのに最適です。

比較アルゴリズムは属性を順次処理し、各後続属性と最初の属性を比較します。いずれかの属性の値が最初の属性と異なる場合、結果は False となります。いずれかの属性に null 値が含まれる場合は結果が null（計算不能）となり、不完全なデータが誤解を招く検証結果を生じないようにします。このアプローチは、複雑なマルチシステム環境でのデータ品質監視およびプロセス適合性チェックの堅牢な基盤を提供します。

よくある用途

  • 調達プロセスにおける三方一致の検証：発注書、受領書、請求書の数量がすべて一致していることを確認
  • 医療現場における患者識別子の一貫性検証：入院、治療、請求、退院システム間で識別子が一貫していることを確認
  • 製造業における製品仕様の整合性確保：設計文書、生産指示書、品質検査記録間の仕様を一致させる
  • CRM、注文管理、請求システム間の顧客情報同期の検証
  • 購買要求、承認ワークフロー、支払い許可システム間の承認金額の整合性チェック
  • 倉庫管理、輸送、通関書類間の出荷数量の一致を検証
  • 複数のログ記録システム間での監査証跡タイムスタンプの一致検証によるコンプライアンス確保

設定

新規属性名: 比較結果を格納するブール属性の名前を指定します。多属性検証の内容が明確にわかる説明的な名前を選択してください。例えば、発注書、受領書、請求書の数量比較時は「Three_Way_Match_Quantity」、複数システム間の患者識別子検証時は「Patient_ID_Consistent」などです。すべての比較値が一致する場合に True、いずれかの値が異なる場合に False、いずれかの属性が null 値を含む場合に null を格納します。

ケース列名: 等価性を比較するケース属性を選択します。このマルチセレクトフィールドでは、データセット内のすべての利用可能なケース属性から3つ以上の属性を選択できます。元の属性および他のエンリッチメントで生成された属性の両方が含まれます。属性のデータ型はテキスト、数値、日付、ブール値など何でも構いません。エンリッチメントは選択されたすべての属性がケースごとに同一の値を持つことを検証します。2つ以上の属性を選択する必要がありますが、3つ以上の属性を対象にしたシナリオ向けに設計されています。比較は厳密な等価性をチェックし、データ型やフォーマットも正確に同一でなければなりません。リスト内に null 値が含まれる場合は結果が True ではなく null となり、不完全なデータを適切に検知します。

例

例1：調達における三方一致

シナリオ: 調達から支払いプロセスにおいて、支払い承認前に発注書、受領書、請求書の数量値が一致していることを検証する必要があります。この三方一致は財務の正確性と不正防止の基本的な管理手法です。

設定:

  • 新規属性名: Three_Way_Match_Quantity
  • ケース列名: PO_Quantity, GR_Quantity, Invoice_Quantity

出力: ブール属性 "Three_Way_Match_Quantity" を作成し、値は以下の通り：

  • True：3つの数量が完全に一致する場合（例：PO=100, GR=100, Invoice=100）
  • False：いずれかの数量が異なる場合（例：PO=100, GR=100, Invoice=105）
  • null：いずれかの数量フィールドが欠損またはnullの場合

異なるシナリオを示すサンプルデータ：

Case_ID PO_Quantity GR_Quantity Invoice_Quantity Three_Way_Match_Quantity
PO-001 100 100 100 True
PO-002 50 50 52 False
PO-003 200 195 200 False
PO-004 75 null 75 null
PO-005 25 25 25 True

洞察: この比較により、完全に三方一致する請求書の自動承認が可能となり、不一致は手動レビューのためにフラグ付けされます。組織は三方一致率をKPIとしてプロセス効率を測定し、頻繁に不一致が生じるサプライヤーの特定や不一致に伴う財務影響の評価が可能です。Falseとなったケースは調査が必要であり、null結果はデータ品質向上が必要な不完全データを示します。

例2：医療における患者識別子検証

シナリオ: 病院情報システムにおいて、入院システム（ADT）、電子カルテ（EMR）、検査システム（LIS）、請求システムで患者識別子が一貫していることが必要です。識別子の不一致は医療ミス、請求問題、コンプライアンス違反を引き起こす恐れがあります。

設定:

  • 新規属性名: Patient_ID_Consistent
  • ケース列名: ADT_Patient_ID, EMR_Patient_ID, LIS_Patient_ID, Billing_Patient_ID

出力: ブール属性 "Patient_ID_Consistent" を作成し、以下を示します：

  • True：4システムすべての識別子が一致（例："PT-789456"）
  • False：いずれかのシステムで異なる識別子が存在し、データ同期の問題を示す
  • null：いずれかのシステムで識別子情報が欠損している

サンプルデータ：

Case_ID ADT_Patient_ID EMR_Patient_ID LIS_Patient_ID Billing_Patient_ID Patient_ID_Consistent
ADM-101 PT-789456 PT-789456 PT-789456 PT-789456 True
ADM-102 PT-445821 PT-445821 PT-445821 PT-445281 False
ADM-103 PT-223344 PT-223344 null PT-223344 null
ADM-104 PT-998877 PT-998877 PT-998877 PT-998877 True

洞察: この検証により、マスターデータ管理上の問題を特定し、医療ミスの防止に役立ちます。医療機関は一貫した識別子の割合をトラッキングし、システム統合の優先順位をつけ、規制遵守を確保します。Falseはデータ照合ワークフローをトリガーし、nullは不完全な登録プロセスを示します。

例3：製造における製品仕様の一貫性

シナリオ: 製造環境では、製品仕様が設計文書、生産計画システム、品質管理データベース間で一致していることが要求されます。不一致は不適合製品の製造や生産遅延の原因となります。

設定:

  • 新規属性名: Spec_Consistent_All_Systems
  • ケース列名: Design_Material_Grade, Planning_Material_Grade, QC_Required_Grade

出力: ブール属性 "Spec_Consistent_All_Systems" を作成し、以下を示します：

  • True：3システム全てが同一の材料グレードを指定（例："Grade_A_Premium"）
  • False：いずれかのシステムが異なる仕様（例：設計は"Grade_A_Premium"だが計画は"Grade_A_Standard"）
  • null：仕様データがいずれかのシステムで欠損

サンプルデータ：

Production_Order Design_Material_Grade Planning_Material_Grade QC_Required_Grade Spec_Consistent_All_Systems
WO-5001 Grade_A_Premium Grade_A_Premium Grade_A_Premium True
WO-5002 Grade_B_Standard Grade_B_Standard Grade_A_Premium False
WO-5003 Grade_C_Economic null Grade_C_Economic null
WO-5004 Grade_A_Premium Grade_A_Premium Grade_A_Premium True

洞察: この比較により、生産開始前に仕様不一致を早期に検出し、品質問題や材料の無駄を防止できます。製造組織は各システム間の仕様一致率を測定し、頻繁に不一致が起こる製品・製品群を特定し、エンジニアリング変更管理を改善できます。False結果は仕様レビューのワークフローをトリガーし、生産前の不整合を解決します。

例4：システム間での顧客データ同期

シナリオ: 複数の顧客向けシステムがある企業において、顧客のメールアドレスがCRM、ECプラットフォーム、メールマーケティングシステム、カスタマーサポートポータルで同期されていることが求められます。一貫しない連絡先情報は、重要な通知の未達や重複送信を引き起こします。

設定:

  • 新規属性名: Customer_Email_Synchronized
  • ケース列名: CRM_Email, Ecommerce_Email, Marketing_Email, Support_Email

出力: ブール属性 "Customer_Email_Synchronized" を作成し、以下を示します：

  • True：すべてのシステムで同一のメールアドレスを保持（例："customer@example.com"）
  • False：各システムでメールアドレスが異なる場合、同期に問題あり
  • null：メールアドレスがいずれかのシステムで欠損

サンプルデータ：

Customer_ID CRM_Email Ecommerce_Email Marketing_Email Support_Email Customer_Email_Synchronized
CUST-1001 john@example.com john@example.com john@example.com john@example.com True
CUST-1002 mary@company.com mary@company.com mary@oldmail.com mary@company.com False
CUST-1003 bob@business.net bob@business.net null bob@business.net null
CUST-1004 lisa@enterprise.io lisa@enterprise.io lisa@enterprise.io lisa@enterprise.io True

洞察: この検証により、連絡先情報が不一致の顧客を特定し、重要通信の未達や重複送信を防ぎます。組織はシステム間のデータ同期率を算出し、マスターデータ管理の改善優先順位を設定し、古い情報による顧客サービス問題を削減できます。Falseはデータ同期ワークフローをトリガー、nullは不完全な顧客プロフィールを示します。

例5：財務承認金額の整合性

シナリオ: 購買要求および承認プロセスにおいて、要求金額が複数の承認レベルやシステム間で一貫していることが必要で、不正な金額変更を防止し財務管理の健全性を確保します。

設定:

  • 新規属性名: Approval_Amounts_Aligned
  • ケース列名: Requisition_Amount, L1_Approval_Amount, L2_Approval_Amount, PO_Final_Amount

出力: ブール属性 "Approval_Amounts_Aligned" を作成し、以下を示します：

  • True：すべての承認段階で同一の金額（例：すべて 15,000.00）
  • False：承認段階間で金額が異なり、不正変更を示唆
  • null：いずれかの段階で金額データが欠落

サンプルデータ：

Requisition_ID Requisition_Amount L1_Approval_Amount L2_Approval_Amount PO_Final_Amount Approval_Amounts_Aligned
REQ-2001 15000.00 15000.00 15000.00 15000.00 True
REQ-2002 8500.00 8500.00 8750.00 8750.00 False
REQ-2003 22000.00 22000.00 null 22000.00 null
REQ-2004 5000.00 5000.00 5000.00 5200.00 False

洞察: この比較により、承認ワークフロー中の不正な金額変更を検出し、財務管理の整合性を守ります。組織は適正承認の逸脱事例を特定し、承認プロセス遵守状況の調査や財務管理強化を進められます。False結果は不正や違反の可能性があるため即時調査が求められ、True率が高ければ管理体制が適切に機能していることを示します。

出力

Compare Multiple Case Attributes エンリッチメントは、設定で指定した名前の単一の新規ブール型ケース属性を作成します。この属性は、比較したすべての属性が同一の値を持つ場合に True、いずれかの属性が異なる場合に False、いずれかの属性が null 値を含む場合に null を格納します。比較はケースごとに独立して行われます。

エンリッチメントは逐次比較アルゴリズムを使用し、最初の属性を各後続属性と比較します。すべての値はデータ型や形式も含めて完全に一致する必要があります。結果は以下の通りです：

  • True: 選択されたすべての属性が同一の非null値を持つ
  • False: 少なくとも1つの属性が異なる値を持つ（ただしすべて非null）
  • null: 1つ以上の属性にnull値が含まれ、不完全なデータを示す

ブール属性は視覚化の好みに応じて、True/False、Yes/No、1/0、カスタムラベルなど様々な形式で表示可能です。この属性は mindzieStudio の他機能とシームレスに統合されます：

  • フィルタリング: 完全一致(True)のみ、いずれかの不一致(False)、不完全データ(null)のケースでフィルタリング可能
  • 適合性分析: 完全整合ケースの割合と不整合ケースの割合を算出
  • プロセスフロー: すべて一致するか否かで異なるプロセス経路を作成
  • 計算式: 複雑な検証ルールにおいて "(Three_Way_Match_Quantity = True) AND (Amount < 10000)" のような論理式で利用可能
  • ダッシュボード: 一致率やデータ品質のトレンド分析、頻繁に不一致が起きるシステムの特定用KPI作成
  • データ品質監視: null結果をトラッキングし、調査が必要なデータ欠損を把握

他の比較エンリッチメントと組み合わせて総合的な検証階層を構築する際に特に効果的です。例えば、まず Compare Multiple Case Attributes で3つの数量フィールドが一致するか確認し、続いて別の比較でその一致数量が閾値を満たすか検証するような構成が考えられます。

関連事項

  • Compare Case Attributes: 2つの値のみを検証するシンプルな2属性比較用
  • Logical AND: 複数の比較結果を組み合わせて複雑な検証ルールを作成する際に使用
  • Logical OR: 少なくとも1つの比較がTrueであればよい柔軟な検証ルール作成用
  • Categorize Attribute Values: 複数属性比較結果に基づくケースのグルーピング分析用
  • Filter Cases: 複数属性検証結果に基づくケース除外用

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