2 Way Match

概要

2 Way Match エンリッチメントは、ケース内の2つの活動セットの数値を比較し、一致するかどうかを判断することで、文書照合やプロセス遵守分析の強力な検証機構を作成します。このエンリッチメントは、指定した活動および関連する数値属性から合計や平均、最初または最後の発生値などの集計値を計算し、これらの値を比較して一致や不一致を特定します。結果として、一致の真偽を示すブール属性と、2つの値の差分を示すオプションの差分属性を作成します。

このエンリッチメントは、複数の文書や活動を相互に照合する必要がある購買、財務、物流プロセスに不可欠です。例えば、調達から支払までのプロセスでは、発注数量が受領数量と一致するか、請求金額が発注金額と合致するかを検証できます。エンリッチメントはケース単位で動作し、多段階プロセスにおいて異なる活動が記録する関連情報の整合性を検証するのに最適です。合計、平均、最小、最大、最初、最後など複数の集計方法をサポートしており、単純な最終値比較から複数明細の複雑な合算まで様々なビジネスシナリオに対応します。

2 Way Match エンリッチメントは基本的な比較ロジックを提供し、そこから3 Way Matchや4 Way Matchといった高度な照合シナリオの基礎となります。不一致が判明した後は、フィルタリングや分析を用いて不一致のパターンを把握し、プロセス遵守率を測定し、不一致があるケースを手動レビューや承認に回すことが可能です。

主な用途

  • 調達プロセスで発注数量と受領数量の検証
  • 財務コンプライアンスや支払承認のために請求額と発注額を比較
  • 受注数量と出荷数量の照合
  • 製造における計画生産量と実生産量の検証
  • 支出管理での要求金額と承認予算の比較
  • プロフェッショナルサービスで契約時間数とサービス提供時間の検証
  • 実際の在庫数とシステム記録の照合
  • 倉庫業務で顧客注文数量とピッキング・梱包数量の検証

設定

Activity Names 1: 比較対象の最初の文書または取引タイプを表す1つ以上の活動を指定します。例として調達プロセスでは「CreatePurchaseOrderLine」や「UpdatePurchaseOrderLine」などがあり、発注数量を取得します。異なる活動名に同種の情報が含まれる場合は複数選択可能です。選択した活動から、後述の Event Selection 1 に従って数値を取り出します。

Event Selection 1: 同じケース内で Activity Names 1 のインスタンスが複数ある場合にどのように集計するかを指定します。選択肢は以下の通りです:

  • First: 最初の発生の値を使用
  • Last: 最後の発生の値を使用（デフォルト - 文書更新に最も一般的）
  • Sum: すべての発生の値を合計（明細合計に適する）
  • Average: 値の平均を計算
  • Min: 最小値を使用
  • Max: 最大値を使用

Activity Names 2: 比較対象の2番目の文書または取引タイプを表す1つ以上の活動を指定します。例として調達では「ProductReceipt」や「GoodsReceipt」などがあり、受領数量を取得します。これらの活動から集計した値が Activity Names 1 の値と比較されます。

Event Selection 2: Activity Names 2 の複数インスタンスに対する集計方法を指定します。Event Selection 1 と同様の選択肢があります。デフォルトは「Sum」であり、複数回に分けて出荷される受領に対して一般的です。例えば100個の発注が3回の出荷（40、35、25個）で満たされた場合、「Sum」により正しく100個として比較されます。

Column Name: 比較する値を含む数値のイベント属性を選択します。整数、少数、浮動小数点など数値型で、両方の活動セットのイベントに存在する必要があります。一般的な例は「Quantity」「Amount」「Value」「Hours」「Weight」などです。エンリッチメントは指定した活動からこの属性の値を抽出し、比較を行います。

New Attribute Name: 一致結果を格納するブール型ケース属性の名前を指定します。比較内容がわかりやすい名称を選んでください。例：「PO_Matches_GR_Quantity」や「Invoice_Amount_Matches_PO」などです。この属性は値が完全に一致すると True、異なる場合は False を持ちます。デフォルト例: 「Quantity for CreatePurchaseOrderLine = ProductReceipt」

New Attribute Difference Name: オプションで、差分を格納する数値型ケース属性の名前を指定します。この属性は Value1 から Value2 を差し引いた値を格納し、不一致の大きさや方向を分析できます。正の差分は最初の値が大きい（例：発注数が受領数より多い）、負の差分はその逆を示します。単に一致不一致を判別するだけなら空欄でもかまいません。デフォルト例: 「Quantity difference CreatePurchaseOrderLine - ProductReceipt」

Filter Cases (Advanced): オプションで、このエンリッチメントの対象ケースを制限するためにフィルタを適用できます。特定のステータスや日付範囲、属性値を持つケースのみに対して処理を限定する高度設定です。フィルタに該当しないケースは新属性が計算されません。

例

例1: 発注数量と受領数量のマッチング

シナリオ: 調達から支払いまでのプロセスで、受領合計数量が発注数量と一致することを検証します。発注は複数回更新される可能性があり、受領も複数回に分かれて行われます。不一致のあるケースを特定したいです。

設定:

  • Activity Names 1: CreatePurchaseOrderLine, UpdatePurchaseOrderLine
  • Event Selection 1: Last
  • Activity Names 2: GoodsReceipt, ProductReceipt
  • Event Selection 2: Sum
  • Column Name: Quantity
  • New Attribute Name: PO_Quantity_Matches_GR
  • New Attribute Difference Name: PO_GR_Quantity_Variance

出力: 2つの新しいケース属性を作成します。

  1. PO_Quantity_Matches_GR (Boolean):

    • True: 最終発注数量と受領合計数量が一致するケース（例：発注100、受領100）
    • False: 差異があるケース（例：発注100、受領95または105）

  2. PO_GR_Quantity_Variance (Numeric):

    • 0: 完全一致
    • +5: 発注が受領より5多い（数量不足）
    • -5: 受領が発注より5多い（過剰出荷）

サンプルデータ:

  • ケース12345: 発注100単位（最後のPO更新）、3回の出荷で受領計100（40、35、25）→ PO_Quantity_Matches_GR = True、Variance = 0
  • ケース12346: 発注50単位、受領48単位 → PO_Quantity_Matches_GR = False、Variance = +2
  • ケース12347: 発注75単位、受領80単位 → PO_Quantity_Matches_GR = False、Variance = -5

分析: 数量不一致ケースを抽出し、過不足の発生頻度や傾向を分析、問題の多いサプライヤーを特定、不一致のケースを承認や調査に回せます。「98%の発注で数量完全一致」「平均差分は+2.3単位で軽微な不足傾向」などの指標作成が可能です。

例2: 請求額と発注額の検証

シナリオ: 買掛金管理で、支払い前に請求額が元の発注額と一致しているか検証します。2 Way Match により正しい請求のみ支払いを許可し、価格差異や請求ミスを検出します。

設定:

  • Activity Names 1: CreatePurchaseOrder, ApprovePurchaseOrder
  • Event Selection 1: Last
  • Activity Names 2: ReceiveInvoice
  • Event Selection 2: Sum
  • Column Name: TotalAmount
  • New Attribute Name: Invoice_Matches_PO_Amount
  • New Attribute Difference Name: Invoice_PO_Amount_Difference

出力: 請求額と発注額の一致を示す2つのケース属性を作成。

  1. Invoice_Matches_PO_Amount (Boolean):

    • True: 請求額が発注額と正確に一致（例：両方5000.00ドル）
    • False: 金額が異なる（例：PO5000.00ドル、請求5250.00ドル）

  2. Invoice_PO_Amount_Difference (Numeric):

    • 0.00: 完全一致
    • +500.00: POが請求より500ドル多い（過少請求）
    • -250.00: 請求がPOより250ドル多い（過大請求、承認必要）

サンプルデータ:

  • ケースINV-001: PO $10,000、請求 $10,000 → 一致=True、差分=0
  • ケースINV-002: PO $7,500、請求 $7,750 → 一致=False、差分=-250
  • ケースINV-003: PO $3,200、請求 $3,200 → 一致=True、差分=0

分析: 一致する請求は自動承認ルールを適用し、一致しない請求は手動レビュー、特定ベンダーの価格問題を検出、スループロセス率を測定できます。「Invoice_Matches_PO_Amount が True の場合に自動承認」などのルールも作成可能です。

例3: 受注と出荷数量の照合

シナリオ: 注文履行プロセスで、出荷数量が顧客の注文数量と合っているか検証します。注文は変更されることがあり、出荷は複数回に分けて行われます。不足出荷を特定し顧客満足度を向上させます。

設定:

  • Activity Names 1: CreateSalesOrder, ModifySalesOrder
  • Event Selection 1: Last
  • Activity Names 2: ShipProduct, ConfirmShipment
  • Event Selection 2: Sum
  • Column Name: OrderedQuantity
  • New Attribute Name: Order_Shipment_Quantity_Match
  • New Attribute Difference Name: Unshipped_Quantity

出力: 受注履行精度を示す属性を作成。

  1. Order_Shipment_Quantity_Match (Boolean):

    • True: 完全履行（注文50、出荷50）
    • False: 一部または過剰履行（注文50、出荷48または52）

  2. Unshipped_Quantity (Numeric):

    • 0: 完全出荷
    • +2: 2ユニット不足（バックオーダー）
    • -2: 2ユニット超過出荷（在庫問題の可能性）

サンプルデータ:

  • 注文SO-5001: 200単位注文、4分割出荷（75、50、50、25 = 200）→ 一致=True、未出荷=0
  • 注文SO-5002: 150単位注文、145単位出荷 → 一致=False、未出荷=+5
  • 注文SO-5003: 100単位注文、100単位出荷 → 一致=True、未出荷=0

分析: 注文履行精度率を測定し、頻繁に不足出荷が発生する製品を特定、未出荷数量の傾向やバックオーダー量を分析、未完了出荷に対する顧客サービス通知トリガーも設定できます。「95%の完全充足率」「未充足数量の平均2.3単位」という KPI 作成も可能です。

例4: 製造計画と実生産数量の比較

シナリオ: 製造プロセスにおいて、計画生産数量と実際の生産数量を比較し、生産効率を測定、キャパシティーや品質問題を特定します。計画は更新され、生産はバッチ単位で記録されます。

設定:

  • Activity Names 1: CreateProductionOrder, UpdateProductionPlan
  • Event Selection 1: Last
  • Activity Names 2: RecordProduction, CompleteProductionBatch
  • Event Selection 2: Sum
  • Column Name: Quantity
  • New Attribute Name: Production_Met_Plan
  • New Attribute Difference Name: Production_Variance

出力: 生産実績を示す属性を作成。

  1. Production_Met_Plan (Boolean):

    • True: 実生産が計画通り（計画1000、実生産1000）
    • False: 過剰または不足生産（計画1000、実生産950または1050）

  2. Production_Variance (Numeric):

    • 0: 計画通り
    • +50: 50単位不足（キャパシティまたは品質問題）
    • -50: 50単位過剰（効率改善または予測誤差）

サンプルデータ:

  • 生産注文PR-8001: 計画5000単位、実績5000 → 一致=True、差分=0
  • 生産注文PR-8002: 計画3000単位、実績2850 → 一致=False、差分=+150
  • 生産注文PR-8003: 計画1500単位、実績1520 → 一致=False、差分=-20

分析: 生産効率率を計算し、一貫して低パフォーマンスの生産ラインを特定、製品種別やシフト別の差分パターン分析、キャパシティ制約に対する早期警告が可能です。「85%の生産注文が計画通り達成」「平均差分-2.5%（若干の過剰生産）」などの指標を測定できます。

例5: サービス時間 - 契約時間数と実提供時間の比較

シナリオ: プロフェッショナルサービスで、クライアントへの提供時間が契約時間数に合っているか検証します。契約は修正されることがあり、提供時間は複数の活動にまたがって記録されます。

設定:

  • Activity Names 1: CreateServiceContract, AmendServiceContract
  • Event Selection 1: Last
  • Activity Names 2: LogServiceHours, SubmitTimesheet
  • Event Selection 2: Sum
  • Column Name: Hours
  • New Attribute Name: Hours_Match_Contract
  • New Attribute Difference Name: Hours_Variance

出力: サービス提供検証の属性を作成。

  1. Hours_Match_Contract (Boolean):

    • True: 提供時間が契約時間に一致（契約80時間、提供80時間）
    • False: 過不足（契約80時間、提供75または85時間）

  2. Hours_Variance (Numeric):

    • 0: 完全一致
    • +5: 5時間不足（クライアント不満足の可能性）
    • -10: 10時間超過（請求不可の場合収益漏れ）

サンプルデータ:

  • プロジェクトSVC-2001: 契約160時間、提供160時間 → 一致=True、差分=0
  • プロジェクトSVC-2002: 契約120時間、提供115時間 → 一致=False、差分=+5
  • プロジェクトSVC-2003: 契約200時間、提供215時間 → 一致=False、差分=-15

分析: サービス提供の正確さを測定し、スコープクリープ（過剰提供）のあるプロジェクトを特定、不足提供を検出し是正措置に活用、請求精度を分析できます。「92%のプロジェクトが契約時間を提供」「平均過剰提供3.2時間」などの指標追跡が可能です。

出力

2 Way Match エンリッチメントは、設定に応じて1つまたは2つの新しいケース属性を作成します。

マッチ指標属性（常に作成）: 「New Attribute Name」で指定した名前のブール属性で以下の値を持ちます:

  • True: Activity Names 1 の集計値が Activity Names 2 の集計値に等しい場合
  • False: 値がいかなる差でも異なる場合
  • 無値（null）: いずれかの活動セットが存在しない場合、または指定列に値がない場合

差分属性（オプション）: 「New Attribute Difference Name」を指定した場合に作成され、数値属性として Value1 から Value2 を差し引いた値を格納します:

  • 正の値: 最初の値が大きい（例：発注数が受領より多い）
  • 負の値: 2番目の値が大きい（例：受領数が発注より多い）
  • ゼロ: 完全一致
  • 無値（null）: 比較不能の場合（活動や値が不足）

両属性は派生ケース属性として作成され、mindzieStudio の他機能とシームレスに連携します。

フィルタリング: 不一致ケースのみ表示（Match = False）、重大な差分があるケース（Difference > 閾値）、一方向の差分パターン（Difference > 0 で不足出荷）でフィルタを作成可能。

遵守分析: 全データセットや特定セグメントでマッチ率や差分統計を計算可能。「98%の発注が受領と一致」、「平均数量差分2.3単位」など。

プロセス可視化: マッチ結果に基づきプロセスフローを分割し、一致と不一致のケース別パスを可視化。不一致発生箇所や解消ポイントが判明。

計算式: ブールマッチ属性を論理式に利用し、複雑な検証ルール（他遵守チェックとの組み合わせ）を作成可能。

ダッシュボード・KPI: マッチ率の時間推移、差分分布、遵守トレンドを示す指標・グラフを作成。サプライヤー別、製品カテゴリ別、期間別などの差分パターンを表示。

自動化・ルーティング: マッチが True のケースを自動承認し、False は手動レビューキューに送るといったプロセス自動化を促進。

このエンリッチメントは、両方の活動セットが存在し、指定列に数値があるケースのみで比較処理を行います。活動や値が欠如するケースは null 値となり、不一致ケースとは別に不完全ケースを識別可能です。

関連項目

  • Compare Case Attributes - 活動を集計せずに2つのケース属性を直接比較する
  • Compare Event Attributes for Two Activities - 集計せずに2つの特定活動のイベント属性を比較する
  • Attribute Changes Between Two Activities - 2つの活動間の属性値変化を検知する
  • Subtract - 他のエンリッチメントで作成したケース属性間の差分を計算
  • Filter Process Log - マッチ結果や差分に基づきケースをフィルタ
  • Divide - マッチした値の比率計算に使用

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