適合性問題
概要
適合性問題エンリッチメントは、mindzieStudioのフィルターエンジンの全機能を使用してカスタムの適合ルールを定義できる強力で柔軟なツールです。特定の条件(許可された開始アクティビティや必須アクティビティなど)をチェックする専門の適合エンリッチメントとは異なり、このエンリッチメントは、ケース属性、期間閾値、アクティビティパターン、またはその他のフィルター可能な基準に基づいて任意の適合問題を完全に制御して定義できます。
このエンリッチメントは、組織の特定のビジネスルールやプロセス要件に合わせて包括的な適合チェックフレームワークを構築するための基盤となります。ルールベースのチェックを作成して、定義した条件に一致するケースをフラグ付けし、プロセスの逸脱、ポリシー違反、コンプライアンス問題を特定できます。各適合問題は重要度で分類され、ルールグループに整理され、プロセス全体で追跡が可能です。
このエンリッチメントの柔軟性は、プロセスコンプライアンス監視、監査証跡、継続的なプロセス改善イニシアチブを実施する組織にとって不可欠です。複数のフィルター条件を組み合わせることにより、実際のプロセスガバナンスのニーズを反映した複雑なビジネスルールや規制要件をモデル化できます。
主な用途
- 重要なアクティビティ間の期間が定義された閾値を超える場合にSLA違反を検出
- 特定のユーザーロールが許可された範囲外でアクティビティを実行する無許可のプロセス変異を特定
- 属性値に基づき、必要な承認ステップをスキップした承認バイパスシナリオを監視
- 承認制限を超えた購入注文などの財務ポリシー違反を追跡
- 必須ケース属性が欠如または無効な値を含む場合のデータ品質問題をフラグ付け
- 同一ユーザーが矛盾するアクティビティを実行する職務分掌違反を検出
- プロセス非効率性を示す異常なリソース配分パターンのケースを特定
- 特定のビジネスルールに違反するケースをフラグ付けし、規制遵守を監視
- アクティビティの順序やタイミングに基づき標準作業手順からの逸脱を追跡
- 複数の条件を組み合わせた高リスクケースを識別し追加のレビューが必要なものを特定
設定
フィルター: このエンリッチメントの核心はフィルターの設定です。mindzieStudioの包括的なフィルターエンジンを用いて、適合問題を表すケースを正確に定義するために1つ以上のフィルターを追加できます。フィルターはケース属性、アクティビティ属性、期間計算、またはイベントログ内のその他のデータに基づけられます。複数のフィルターはAND/OR論理で組み合わせて高度なルール定義が可能です。少なくとも1つのフィルターを設定する必要があります。
ルール名: 特定の適合問題を追跡するために作成されるケース属性の名前です。ケースがフィルター条件に一致すると、この属性はTRUEに設定され、適合違反を示します。空のままにすると、ルールグループ名のみが使用されます。"遅延承認検出"や"マネージャ承認欠如"など、検出する適合問題の種類が明確にわかる説明的な名前を使用してください。この属性はケース表に表示され、その後のフィルターや計算、可視化で使用できます。
ルールグループ名: 関連する複数の適合ルールを1つにまとめるための上位カテゴリです。たとえば、異なるSLA違反の個別ルールを複数作成し、それら全てを"SLAコンプライアンス問題"にグループ化できます。条件に一致した場合、ルール名とルールグループ名の両方の属性がTRUEに設定されます。この階層構造により適合問題の整理が進み、異なる粒度レベルでの報告が容易になります。ルール名またはルールグループ名のいずれかは必須です。
重要度: この適合問題の重要度レベルで、Low(低)、Medium(中)、High(高)から設定可能です。デフォルトはHighです。この設定により、即時対応が必要な問題と情報提供レベルの問題を区別します。重要度は適合分析用ダッシュボードやレポートに表示され、チームは最も重大なプロセス逸脱に優先的に対応できます。高重要度の問題は即時アラートやエスカレーションを引き起こす場合があり、低重要度の問題は定期的にレビューされます。
制御フロー問題: このチェックボックスは、適合問題がケース属性値やその他のデータ関連の問題ではなく、アクティビティの順序や存在そのもの(制御フロー)に関連しているかどうかを示します。有効にすると、適合問題をプロセス実行上の問題として分類し、データ品質やビジネスルール違反との区別に役立ちます。この区別は根本原因分析やプロセス再設計、教育改善の必要性の判断に有用です。属性値、期間、あるいは活動シーケンス以外の基準に基づく適合問題にはチェックを入れずにおいてください。
例
例1: 購入注文のSLA違反
シナリオ: 調達組織は、10,000ドルを超える購入注文は提出から5営業日(120時間)以内に承認されることを要求するポリシーを持っています。この期間を超える注文はSLA違反となり、調達管理者によるレビューのためにフラグ付けされエスカレーションが必要です。
設定:
- フィルター:
- ケース属性: "Order Amount" > 10000 (AND)
- ケース属性: "Time from Submit PO to Approve PO" > 120 hours
- ルール名: "PO Approval SLA Violation"
- ルールグループ名: "SLA Compliance Issues"
- 重要度: High
- 制御フロー問題: チェックなし(時間関連問題であり、アクティビティの順序問題ではない)
出力:
エンリッチメントは2つの真偽値ケース属性を作成します:"PO Approval SLA Violation" と "SLA Compliance Issues"。両条件(注文額が10,000ドル超かつ承認時間が120時間超)を満たすケースで両属性はTRUEに設定されます。他のケースではFALSEです。
エンリッチメント後のサンプルデータ:
| Case ID | Order Amount | Time from Submit to Approve | PO Approval SLA Violation | SLA Compliance Issues |
|---|---|---|---|---|
| PO-1001 | $12,500 | 145 hours | TRUE | TRUE |
| PO-1002 | $8,000 | 150 hours | FALSE | FALSE |
| PO-1003 | $15,000 | 95 hours | FALSE | FALSE |
| PO-1004 | $25,000 | 168 hours | TRUE | TRUE |
洞察: この適合チェックにより、4件中2件の購入注文が承認SLAポリシー違反を検出しました。管理者はこれらのケースをフィルターし、遅延原因を分析して是正措置を講じることができます。高重要度指定によりこれらのケースはダッシュボードで優先的にレビューされます。
例2: 職務分掌違反
シナリオ: 金融システムでは、請求書を作成した者と支払を承認する者が同一人物であってはならないという内部統制があります。この職務分掌は不正防止と適切な監督を保証します。同一ユーザーが両方のアクティビティを行うケースは重大なコンプライアンス違反です。
設定:
- フィルター:
- ケース属性: "Create Invoice User" == "Approve Payment User"
- ルール名: "Same User Created and Approved"
- ルールグループ名: "Segregation of Duties Violations"
- 重要度: High
- 制御フロー問題: チェックなし(ユーザー属性に関するものでアクティビティの順序問題ではない)
出力:
2つの真偽値ケース属性が作成され、"Create Invoice User" と "Approve Payment User" が同じユーザーIDの場合、"Same User Created and Approved" と "Segregation of Duties Violations" の両方がTRUEになります。
サンプルデータ:
| Case ID | Create Invoice User | Approve Payment User | Same User Created and Approved | Segregation of Duties Violations |
|---|---|---|---|---|
| INV-501 | jsmith | jdoe | FALSE | FALSE |
| INV-502 | mbrown | mbrown | TRUE | TRUE |
| INV-503 | kwilson | jdoe | FALSE | FALSE |
| INV-504 | rjones | rjones | TRUE | TRUE |
洞察: この適合ルールにより、即時調査を要する重大な内部統制違反が特定されました。監査チームは故意の不正かシステム設定ミス、ユーザー教育の不足かを確認できます。この種のチェックは金融処理における規制遵守のために不可欠です。
例3: 必須文書の欠如
シナリオ: 医療提供者は、すべての患者退院ケースにフォローアップケア指示の文書が含まれていることを求めています。これが欠如したケースはコンプライアンス問題であると同時に患者安全の懸念要因です。退院患者についてはケース属性 "Follow-up Instructions Provided" が常に「Yes」である必要があります。
設定:
- フィルター:
- ケース属性: "Case Status" == "Discharged" (AND)
- ケース属性: "Follow-up Instructions Provided" != "Yes"
- ルール名: "Missing Follow-up Instructions"
- ルールグループ名: "Documentation Compliance"
- 重要度: High
- 制御フロー問題: チェックなし(データの完全性に関するものでアクティビティの流れではない)
出力:
エンリッチメントは、適切な文書が欠如する退院ケースをフラグ付けする2つの真偽値属性を作成します。TRUEのケースは即時対応が必要です。
サンプルデータ:
| Case ID | Case Status | Follow-up Instructions Provided | Missing Follow-up Instructions | Documentation Compliance |
|---|---|---|---|---|
| PT-2001 | Discharged | Yes | FALSE | FALSE |
| PT-2002 | Discharged | NULL | TRUE | TRUE |
| PT-2003 | Active | NULL | FALSE | FALSE |
| PT-2004 | Discharged | No | TRUE | TRUE |
洞察: このチェックにより、2名の退院患者がフォローアップ指示書を受け取っていないことが判明しました。品質改善チームはこれらの患者に即座に連絡し、欠落の理由を調査します。適合監視は患者安全および規制遵守にとって極めて重要です。
例4: 無許可割引の適用
シナリオ: 小売業の組織では、15%を超える割引はマネージャ承認が必要というポリシーがあります。販売担当者は最大15%の割引までは承認不要で適用できますが、それを超える割引は承認アクティビティを経なければなりません。15%超の割引が「Manager Approves Discount」アクティビティを含まない場合はポリシー違反となります。
設定:
- フィルター:
- ケース属性: "Discount Percentage" > 15 (AND)
- ケース属性: "Has Manager Approval Activity" == FALSE
- ルール名: "Unauthorized High Discount"
- ルールグループ名: "Authorization Policy Violations"
- 重要度: Medium
- 制御フロー問題: チェックあり(プロセスフロー内のアクティビティ欠如に関する問題)
出力:
2つの真偽値属性が、無許可の高割引を適用したケースを特定します。これらは割引の妥当性および販売員の承認ルール遵守教育の必要性の確認のためにレビューされます。
サンプルデータ:
| Case ID | Discount Percentage | Has Manager Approval Activity | Unauthorized High Discount | Authorization Policy Violations |
|---|---|---|---|---|
| ORD-701 | 12% | FALSE | FALSE | FALSE |
| ORD-702 | 20% | TRUE | FALSE | FALSE |
| ORD-703 | 25% | FALSE | TRUE | TRUE |
| ORD-704 | 18% | FALSE | TRUE | TRUE |
洞察: 2件の注文が15%の閾値を超える無許可割引を適用しました。管理者はこれらの取引を精査し、システム管理強化や教育が必要か判断できます。中程度の重要度はレビューが必要ですが、金融不正のような即時エスカレーションは要求しないことを示します。
例5: 複雑な多条件コンプライアルール
シナリオ: 製薬製造プロセスでは、48時間を超える生産期間かつ温度逸脱が記録され、かつ臨時オペレーターが処理したバッチは追加の品質レビューが必要という複雑なコンプライアンス要件があります。この多因子ルールは高リスクバッチを特定し、検査強化を促します。
設定:
- フィルター:
- ケース属性: "Production Duration Hours" > 48 (AND)
- ケース属性: "Temperature Deviation Recorded" == "Yes" (AND)
- ケース属性: "Primary Operator Type" == "Temporary"
- ルール名: "Enhanced Quality Review Required"
- ルールグループ名: "Manufacturing Compliance"
- 重要度: High
- 制御フロー問題: チェックなし(複数のリスク要因に基づくものでアクティビティ順序問題ではない)
出力:
3つの高リスク条件を満たすバッチをフラグ付けする真偽値属性が作成されます。これらバッチは自動的に強化品質レビューの手順に送られます。
サンプルデータ:
| Case ID | Production Duration | Temperature Deviation | Operator Type | Enhanced Quality Review Required | Manufacturing Compliance |
|---|---|---|---|---|---|
| BATCH-A | 52 hours | Yes | Temporary | TRUE | TRUE |
| BATCH-B | 45 hours | Yes | Temporary | FALSE | FALSE |
| BATCH-C | 55 hours | No | Temporary | FALSE | FALSE |
| BATCH-D | 60 hours | Yes | Permanent | FALSE | FALSE |
洞察: 3条件すべて満たすバッチのみがフラグ付けされました。これによりConformance Issueエンリッチメントが現実のリスク評価を反映した高度なコンプライアルールのモデル化に有効であることが示されます。高重要度指定により品質保証チームはこれらケースの優先的検査および文書レビューを行います。
出力
Conformance Issueエンリッチメント実行時、設定に応じて1つまたは2つの新しい真偽値ケース属性が作成されます:
ルール名属性(指定があれば): "Rule Name"設定で指定した名前の真偽値ケース属性。この属性は:
- TRUE: エンリッチメントのすべてのフィルター条件を満たすケース(適合違反検出)
- FALSE: それ以外のケース(適合問題なし)
ルールグループ名属性(指定があれば): "Rule Group Name"に指定した名前の真偽値ケース属性。同様にTRUE/FALSEロジックが適用され、複数の関連ルールを共通カテゴリでグループ化可能です。
カラムタイプ: 両属性とも"ConformanceIssue"というカラムタイプで作成され、mindzieStudioインターフェース上でコンプライアンス関連属性として扱われます。"YesNo"形式で表示され、判読しやすいです。
初期値: 属性作成時点ではすべてのケースの値はFALSEに初期化されます。エンリッチメントは各ケースのフィルター評価を行い、条件に一致するケースをTRUEに更新します。
適合問題の登録: ケース属性の作成に加え、適合問題はmindzieStudioの適合トラッキングシステムに登録されます。登録内容には以下が含まれます:
- 問題の発生元(ユーザー定義ルールであることを示す"Rule")
- 重要度レベル(Low, Medium, High)
- ルール名およびルールグループ名による分類
- 制御フラグ(アクティビティシーケンス問題かどうか)
- トラッキングおよび報告用の一意の適合問題識別子
他機能との連携: 作成された真偽値属性は即座に以下に利用可能です:
- フィルター: 特定の適合問題を持つケースのみ表示するビュー作成
- ダッシュボード: 問題の件数や傾向を示す適合監視ダッシュボード構築
- 計算: 数学的計算や条件ロジックに適合属性を利用
- 後続エンリッチメント: 適合問題の有無に基づく追加エンリッチメントの作成
- エクスポート: 外部分析用に適合フラグを含むデータセットの出力
- ケースステージ計算: 適合状態を利用したケースルーティングや優先度設定
適合分析: 登録された適合問題はmindzieStudioの適合分析ツールに表示され、以下が可能です:
- 各適合問題に影響を受けるケース数の表示
- 時間経過による問題の増減傾向の分析
- 異なるルールグループ間の重要度分布の比較
- 個別ケースの詳細調査による根本原因理解
- 管理者および監査担当向けのコンプライアンスレポート作成
関連項目
関連適合エンリッチメント:
- 許可されたケース開始アクティビティ - ケースの許可開始アクティビティ定義
- 許可されたケース終了アクティビティ - ケースの許可終了アクティビティ定義
- 繰り返しアクティビティ - 繰り返しアクティビティの検出
- 誤ったアクティビティ順序 - 不適切なアクティビティ順序の特定
- Mandatory Activity - 必須のアクティビティを実行させる
関連トピック:
- 適合チェック - mindzieStudioにおける適合分析の概要
- フィルターエンジン - 複雑なフィルター条件構築の理解
- ケース属性 - プロセスマイニングにおけるケースレベルのデータ操作
- 重要度レベル - プロセス分析における重要度を用いた優先順位付け
本ドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。