活動順序違反

概要

Wrong Activity Order エンリッチメントは、特定の2つの活動が誤った順序で発生しているケースを検出し、プロセスのコンフォーマンス違反としてマークします。この強力なコンフォーマンスチェックツールにより、重要なプロセスステップが規定された順序に従っていることを保証し、特定の順序で実行されるべき活動が順序を誤って実行される場合を検知できます。コンフォーマンス属性を作成し影響を受けたケースにマークすることで、プロセス遵守度の定量化、教育のニーズの特定、誤った活動順序を招くシステム的な問題の発見を可能にします。

このエンリッチメントは単なるシーケンスチェックを超え、柔軟な重症度レベルやルールのグループ化機能を提供します。これにより、ビジネスの影響に基づいて異なる種類の順序違反を分類できます。規制遵守、品質基準の維持、プロセス効率の最適化など、期待される活動フローが守られていないケースを識別・定量化するのに役立ちます。個々のルール属性とグループレベル属性の両方を作成するため、異なる詳細度でのコンフォーマンス分析が容易です。

主な用途

調達プロセスで承認活動が実行活動の後に行われた場合の検知
製造業で製品出荷後に品質検査が行われたケースの特定
検証手順がスキップされたり順序がずれて実施された場合のコンプライアンス違反の監視
Eコマースで支払いが注文確認前に処理された事例の追跡
医療で必要な診断検査前に医療処置が実施されたケースの特定
書類提出後に必要なレビューが行われた規制違反の検知
必須モジュールの完了前に認証が行われた研修遵守の監視

設定

Activity 1: 正しい順序で最初に発生するべき活動を、データセット内のすべての活動からなるドロップダウンリストから選択します。例えば購買発注プロセスでは、「PO Approval」（承認）が「PO Released」（発注書発行）より前に行われるべき活動です。ドロップダウンにはイベントログに記録されたすべてのユニークな活動が表示されます。

Activity 2: Activity 1の後に続くべき2番目の活動をデータセット内の活動から選択します。この活動が発生しても、Activity 1が全く発生しなかったり、Activity 2の後に発生する場合は違反としてフラグされます。例として、「PO Approval」がActivity 1、「PO Released」がActivity 2の場合、「PO Released」が「PO Approval」より前に起こるケースは違反と判定されます。

Rule Name: この特定のコンフォーマンスルールに対して一意の名前を指定します。この名前の論理属性が新たにケース属性として作成され、そのルール違反ケースでtrueにセットされます。例えば「Approval After Release」や「QC After Shipment」など、検出される違反を明示する説明的な名前を使います。空欄の場合はRule Group Name属性のみが作成されます。各ルール名は個別に追跡する特定の順序違反を表します。

Rule Group Name: 関連する複数のコンフォーマンスルールをまとめるためのカテゴリー名です。この名前の別の論理属性が作成され、グループ内のいずれかのルール違反があったケースでtrueになります。デフォルトは「Activity Order Issue」です。例えば「Approval Violations」や「Quality Process Violations」といったグループ名をつけて、詳細なルールとまとめ両方の分析を可能にします。

Severity: 違反の重要度レベルをドロップダウンから選択:

Low: 軽微な逸脱、業務影響は最小限
Medium: 注意を要する中程度の違反
High: 重大な業務またはコンプライアンス影響を伴う違反（デフォルト）
Critical: 即時是正を必要とする深刻な違反

重症度はプロセスマップやコンフォーマンスダッシュボードでの表示に影響し、対応優先度の判断に役立ちます。

例

例1: 購買発注承認遵守

シナリオ: 調達部門は、ベンダーへの発注リリース前に購買発注が必ず承認されているか確認する必要があります。承認なしのリリースは会社方針違反で、不正支出につながります。

設定:

Activity 1: PO Approved
Activity 2: PO Released to Vendor
Rule Name: Unapproved PO Release
Rule Group Name: Procurement Compliance
Severity: High

出力: 以下の論理ケース属性を作成:

"Unapproved PO Release": 承認前に発注書がリリースされたケースでtrue
"Procurement Compliance": 調達関連の違反があるケースでtrue

サンプルデータ例:

ケースPO-2024-001: どちらもfalse（遵守：承認後リリース）
ケースPO-2024-002: どちらもtrue（違反：承認なしリリース）
ケースPO-2024-003: どちらもtrue（違反：承認前リリース）

インサイト: 分析により発注の8%が適切な承認なしにリリースされており、特に月末の繁忙時に集中していることが判明。自動承認リマインダーの導入や未承認発注のリリース制限を検討。

例2: 製造業の品質管理

シナリオ: 製造施設では製品が包装される前に品質検査が完了している必要があります。検査未実施のまま包装されると顧客クレームやリコールに繋がります。

設定:

Activity 1: Quality Inspection Completed
Activity 2: Product Packaged
Rule Name: Package Before Inspection
Rule Group Name: Quality Process Violations
Severity: Critical

出力: 違反を示す属性を作成:

"Package Before Inspection": 品質検査順序違反を特定
"Quality Process Violations": 品質関連の違反を集約

生産バッチ結果:

バッチA-500: 遵守（09:00検査完了、10:30包装）
バッチA-501: 違反（08:45包装、11:00検査）
バッチA-502: 違反（検査なし包装）

インサイト: バッチの3%が検査より前に包装されており、シフト交代時に多い。包装システムに検査確認ロックを実装する改善策を検討。

例3: 医療治療プロトコル

シナリオ: 病院では手術開始前にインフォームドコンセントの取得が必須。同意なし手術は倫理・法令違反になります。

設定:

Activity 1: Informed Consent Signed
Activity 2: Surgery Started
Rule Name: Surgery Without Consent
Rule Group Name: Medical Protocol Violations
Severity: Critical

出力: コンフォーマンス追跡属性を生成:

"Surgery Without Consent": 同意順序違反を検出
"Medical Protocol Violations": 医療プロトコル違反を追跡

患者ケース例:

患者1001: 遵守（07:30同意、09:00手術開始）
患者1002: 違反（14:00緊急手術、16:00同意取得）
患者1003: 遵守（前回の来院時に同意済み、予定通り手術）

インサイト: 緊急手術では標準的な同意手続きが省略される例があり、緊急同意の特別手順と文書化要件の導入を検討。

例4: 金融サービスのローン処理

シナリオ: 銀行はローン承認前に必ず信用調査が完了していることを確保する必要があります。信用調査なしの承認は不良債権リスク増加および規制違反となります。

設定:

Activity 1: Credit Check Completed
Activity 2: Loan Approved
Rule Name: Approval Without Credit Check
Rule Group Name: Lending Compliance
Severity: High

出力: コンプライアンス追跡属性を作成:

"Approval Without Credit Check": 信用調査未実施の承認を特定
"Lending Compliance": 融資関連の違反を集約

ローン申請結果:

ローン2024-0101: 遵守（信用調査後承認）
ローン2024-0102: 違反（承認が信用調査前）
ローン2024-0103: 違反（信用調査活動なし承認）

インサイト: 既存顧客の信用状況を信用調査不要とみなして無調査承認が約2%存在。この発見により、顧客履歴に関係なくすべてのローンで信用調査義務化の方針を更新。

例5: IT変更管理

シナリオ: IT部門は本番システムへの変更はCAB（変更承認委員会）承認後であることを保証する必要があります。無承認変更はシステム障害やセキュリティ問題を引き起こします。

設定:

Activity 1: Change Approved by CAB
Activity 2: Deployed to Production
Rule Name: Unauthorized Deployment
Rule Group Name: Change Management Violations
Severity: Medium

出力: 変更管理コンフォーマンス属性を作成:

"Unauthorized Deployment": CAB承認なしの展開をフラグ
"Change Management Violations": すべての変更プロセス違反をグループ化

変更チケット分析:

CHG-0001: 遵守（月曜承認、水曜展開）
CHG-0002: 違反（土曜緊急展開、月曜承認）
CHG-0003: 違反（CAB承認なし展開）

インサイト: 週末の緊急対応で5%の変更が承認を経ずに展開されている。緊急変更承認の迅速CABレビュー手続きを導入。

出力

Wrong Activity Order エンリッチメントは、コンフォーマンス違反を示す新しい論理型ケース属性を作成します。

個別ルール属性: Rule Nameが指定されると、その名前の論理型ケース属性が新規作成され、指定された活動順序違反（Activity 2がActivity 1の前または未発生で起こる）をしたケースでtrueに設定されます。この属性はYes/No表示形式で、ダッシュボードやレポートでの読み取りが容易です。

ルールグループ属性: Rule Group Nameにより、複数の関連ルール違反をまとめる論理型ケース属性が作成されます。そのグループ内のいずれかのルール違反があればtrueとなり、詳細・集約両方のコンフォーマンス分析を可能にします。

コンフォーマンス問題の登録: 指定された重症度レベルで違反をシステムのコンフォーマンス問題リストに登録します。これにより、違反はコンフォーマンスダッシュボード、違反箇所が強調されたプロセスマップ、およびコンフォーマンスレポートに反映されます。

エッジ情報の更新: 2つの活動間のエッジ情報を更新し、指定された重症度レベルで非準拠としてマークします。プロセスマップでのフロー描画に影響し、違反エッジは通常赤色や警告アイコンで表示されます。

これらの属性は後続フィルターで非準拠ケースの絞り込みに使ったり、計算式でコンフォーマンス率や傾向の分析に利用できます。論理型属性のため、違反ケースの割合計算やコンフォーマンス改善のトラッキングなどKPIs作成にも最適です。