属性-アクティビティ マトリックス
概要
属性-アクティビティ マトリックス計算機は、イベントログ内の属性とアクティビティの関係を示す包括的なクロス集計表を提供します。属性とアクティビティの各組み合わせについて、その属性に値があるケース数を表示し、管理者がデータの完全性パターンを理解し、データ品質の問題を特定するのに役立ちます。
重要: これは技術分析およびデータ品質評価用に設計された管理者専用の計算機です。 属性が異なるアクティビティでどのように入力されているかを示すマトリックスを生成し、データ抽出パターンの理解、欠落データの特定、イベントログ構造の検証に不可欠です。
この計算機は主に、プロセスのアクティビティ全体に渡る属性の入力パターンを理解し、トラブルシューティング、検証、またはデータセットの最適化を行うシステム管理者およびデータ品質専門家によって使用されます。
一般的な用途
- 特定の属性を入力するアクティビティを特定し、プロセスにおけるデータの流れを理解する
- データがあるはずの特定のアクティビティで欠落している属性値を検出する
- 重要な属性が期待されるプロセス段階で入力されているか検証する
- 属性の入力の体系的なギャップを特定してデータ抽出の問題を診断する
- ETL設計のために特定アクティビティに依存する属性を理解する
- 技術仕様のために、どのアクティビティがどの属性にデータを提供しているかを文書化する
設定
この計算機は特別な設定を必要としません。実行すると、すべての属性（ケースレベル属性とイベントレベル属性の両方）とすべてのアクティビティのマトリックスを自動的に生成し、セルの値はそのアクティビティにおいてその属性に値があるケースの数を示します。
注意: 属性やアクティビティが多数あるデータセットでは、このマトリックスは非常に大きくなる場合があります。計算機は完全なマトリックスを表示するため、すべての組み合わせを確認するにはスクロールする必要があります。
例
例1: 承認データの完全性検証
シナリオ: 新しい承認追跡システムを導入し、購買注文プロセスの各承認段階で承認関連属性が適切に入力されているか確認する必要があります。
設定:
- タイトル: 「承認属性入力分析」
- 説明: 「P2Pプロセスにおける承認データの捕捉を検証」
出力例:
計算機はアクティビティを列、属性を行としたマトリックスを表示します。承認関連属性に対しては次の通りです：
| 属性 | PO作成 | 承認申請 | L1承認 | L2承認 | 財務承認 | ベンダー送付 |
|---|---|---|---|---|---|---|
| ApproverName | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalLevel | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalTimestamp | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalComments | 0 | 0 | 1,523 | 398 | 189 | 0 |
| DelegatedBy | 0 | 0 | 234 | 67 | 23 | 0 |
洞察: このマトリックスは、承認属性が承認関連のアクティビティ（L1、L2、財務承認）でのみ正しく入力されており、それ以外のアクティビティではゼロであることを確認しています。L1承認までに到達する1,847ケースすべてにApproverName、ApprovalLevel、ApprovalTimestampが入力されており、データ捕捉が完全であることが分かります。ただし、ApprovalCommentsはL1で1,847ではなく1,523ケースに入力されており、324ケースがコメントを欠いています。コメントが任意の場合は許容されますが、調査が必要です。DelegatedBy属性は一部の承認ケースにだけ現れ、委任シナリオを正しく捕捉しています。
例2: データ抽出のギャップの特定
シナリオ: 複数のソースシステムを統合した後、オーダー・トゥ・キャッシュプロセスで期待されるアクティビティ全体で一部の属性が一貫して入力されていない疑いがあります。
設定:
- タイトル: 「マルチソースデータ完全性チェック」
- 説明: 「CRM、ERP、配送システムからの属性入力を検証」
出力例:
| 属性 | 受注作成 | クレジットチェック | 商品ピック | 梱包 | 発送 | 請求書作成 | 入金確認 |
|---|---|---|---|---|---|---|---|
| CustomerName | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| CreditScore | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| WarehouseLocation | 0 | 0 | 2,456 | 2,456 | 2,456 | 0 | 0 |
| CarrierName | 0 | 0 | 0 | 0 | 2,456 | 0 | 0 |
| TrackingNumber | 0 | 0 | 0 | 0 | 2,234 | 0 | 0 |
| InvoiceAmount | 0 | 0 | 0 | 0 | 0 | 2,456 | 2,456 |
| PaymentMethod | 0 | 0 | 0 | 0 | 0 | 0 | 1,987 |
洞察: マトリックスは複数のデータ品質問題を示しています。CustomerNameとCreditScoreはケースレベル属性で、すべてのケースで全アクティビティにわたって入力されているため期待通りです。WarehouseLocationは倉庫アクティビティ（ピック、梱包、発送）のみで正しく表示されています。しかし、TrackingNumberは発送時点で期待2,456件のうち2,234件しか入力されておらず、222件の出荷に追跡番号が欠けていることが判明しました。これは重大なギャップで調査が必要です。PaymentMethodも入金確認時に1,987件のみ入力されており、469件の支払いで支払い方法が欠落、支払いシステムとの連携問題が疑われます。
例3: 属性ライフサイクルの理解
シナリオ: 下流の分析・レポート設計を指示するために、特定の属性がプロセスのどの段階で利用可能になるかを文書化する必要があります。
設定:
- タイトル: 「属性ライフサイクル文書化」
- 説明: 「請求処理における各属性の入力タイミングをマッピング」
出力例:
| 属性 | 請求書受領 | 請求書検証 | POとの照合 | 支払承認 | 支払スケジュール | 支払実行 | ケース終了 |
|---|---|---|---|---|---|---|---|
| InvoiceNumber | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| VendorID | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| PONumber | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| MatchStatus | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| ApprovedAmount | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 |
| PaymentDate | 0 | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 |
| ActualPaymentDate | 0 | 0 | 0 | 0 | 0 | 3,456 | 3,456 |
| ClosureReason | 0 | 0 | 0 | 0 | 0 | 0 | 3,456 |
洞察: このマトリックスは属性のライフサイクルを明確に示しています。InvoiceNumber と VendorID は最初から設定される（請求書受取時のケースレベル属性）ことが分かります。PONumber と MatchStatus は POとの照合以降に利用可能で、それ以前の段階にはありません。ApprovedAmount は支払承認で登場し、その後のアクティビティを通じて維持されます。PaymentDate（予定日）は支払スケジュール段階で現れ、ActualPaymentDate（実日）は支払実行段階だけで入力され、計画と実際の区別を示しています。ClosureReason は最終アクティビティのみで入力されます。このライフサイクル理解は特定の属性に依存する分析設計に不可欠です。
例4: 体系的なデータ品質問題の検出
シナリオ: ユーザーから分析データの不整合が報告されており、特定のアクティビティが期待される属性の入力に体系的に失敗しているかどうかを特定する必要があります。
設定:
- タイトル: 「体系的データギャップ分析」
- 説明: 「欠落属性のあるアクティビティを特定」
出力例:
| 属性 | リクエスト検証 | リソース割当 | 作業開始 | 品質チェック | 作業完了 | 結果文書化 |
|---|---|---|---|---|---|---|
| RequestID | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| AssignedTo | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| WorkCategory | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| StartTime | 0 | 0 | 5,678 | 5,678 | 5,678 | 5,678 |
| QualityScore | 0 | 0 | 0 | 4,234 | 4,234 | 4,234 |
| CompletionNotes | 0 | 0 | 0 | 0 | 5,678 | 5,678 |
| DocumentationLink | 0 | 0 | 0 | 0 | 0 | 3,456 |
洞察: マトリックスは重大なデータ品質問題を示しています。QualityScore は品質チェック時にすべてのケース（5,678）で入力されるべきですが、実際には4,234ケースのみ入力されており、1,444ケース（25%）が欠損しています。これは品質検査システムまたはデータ抽出に問題がある体系的なギャップを示します。さらにDocumentationLinkは結果文書化時に2,222ケース（39%）で欠落しており、多くの作業で文書化が省略されている可能性があります。これらの体系的なギャップはデータ整合性の確保のため直ちに対処する必要があります。
例5: マルチシステム連携の検証
シナリオ: プロセスはCRM、ERP、物流の3つの異なるシステムからのデータを統合しており、各システムの属性が適切なアクティビティに正しく関連付けられているかを検証したい。
設定:
- タイトル: 「マルチシステム連携検証」
- 説明: 「CRM、ERP、物流システムからの属性入力の検証」
出力例:
| 属性 | 受注入力（CRM） | 在庫予約（ERP） | 在庫割当（ERP） | 発送（物流） | 配達（物流） | 受領確認（CRM） |
|---|---|---|---|---|---|---|
| CustomerID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SalesRepID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SKU (ERP) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| InventoryLocation (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| StockLevel (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| CarrierID (Logistics) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| DeliveryStatus (Logistics) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| ReceivedBy (CRM) | 0 | 0 | 0 | 0 | 0 | 7,234 |
洞察: マトリックスはほとんどのシステム連携が正しく機能していることを検証しています。CRM属性（CustomerID、SalesRepID）はプロセス全体で利用可能でケースレベル属性として期待通りです。ERP属性（InventoryLocation、StockLevel）は在庫予約以降のアクティビティで正しく表示されています。物流属性（CarrierID、DeliveryStatus）は発送以降で正しく表示されます。しかしReceivedBy属性には問題があり、受領確認時に8,945件中7,234件にしか入力がなく、1,711件（19%）が誰が受け取ったかの確認が欠けています。CRMの受領確認ワークフローの調査が必要です。
例6: 属性強化戦略の計画
シナリオ: どの属性が入力頻度が低く、参照データによる強化やデータ捕捉プロセスの改善によって恩恵を受ける可能性があるかを特定したい。
設定:
- タイトル: 「属性強化機会分析」
- 説明: 「強化が必要な低入力属性の特定」
出力例:
| 属性 | 請求申請 | 書類確認 | 損害評価 | 金額承認 | 支払発行 | クレーム終了 |
|---|---|---|---|---|---|---|
| ClaimNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| PolicyNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterID | 0 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterName | 0 | 0 | 0 | 0 | 0 | 0 |
| DamageCategory | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| EstimatedCost | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| ApprovalReason | 0 | 0 | 0 | 12,456 | 12,456 | 12,456 |
| PaymentMethodCode | 0 | 0 | 0 | 0 | 12,456 | 12,456 |
| PaymentMethodName | 0 | 0 | 0 | 0 | 0 | 0 |
洞察: マトリックスは優れた強化の機会を示しています。AdjusterIDは書類確認段階以降すべてのケースで入力されていますが、AdjusterNameは一度も入力されていません。社員照会テーブルから名前を補完することで分析がよりわかりやすくなります。同様に、PaymentMethodCodeはすべての支払いで入力されていますが、PaymentMethodNameは欠落しています。支払い方法コードに説明的な名前を付加すればレポートの理解度が大きく向上します。これらの強化は参照IDがすでに存在するため、少ない労力で大きな価値を追加できます。
出力
属性-アクティビティ マトリックス計算機は以下の構造を持つ包括的なマトリックス表を表示します。
行: イベントログの各属性（ケース全体に適用されるケースレベル属性と、アクティビティごとに異なる可能性があるイベントレベル属性）の一つずつ。
列: プロセス内の一意のアクティビティ。
セル値: それぞれのセルには、そのアクティビティでその属性に値があるケースの数が表示されます。0は、そのアクティビティでその属性が全く入力されていないことを示します。
セル値の理解
ケースレベル属性: CustomerIDやOrderNumberのようなケースレベル属性の場合、その行のすべてのアクティビティでセル値は同じで、その属性に値があるケースの総数を示します。
イベントレベル属性: ApproverNameやWarehouseLocationのようなイベントレベル属性の場合、セル値はアクティビティによって異なり、その属性がプロセスのどこで入力されているかを示します。
ゼロ値: セル値が0の場合、そのアクティビティでは属性が一度も入力されていないことを意味します。これは期待される動作か、プロセスによってはデータ品質の問題のいずれかです。
インタラクティブ機能
並べ替えとフィルター: 列見出しをクリックしてアクティビティごとにマトリックスを並べ替えできます。ブラウザの検索で特定の属性を素早く見つけられます。
結果のエクスポート: 完全なマトリックスをExcelやCSVにエクスポートしてオフラインで詳しく分析、文書化、技術チームとの共有が可能です。
大規模マトリックス: 多数のアクティビティと属性があるプロセスではマトリックスが非常に大きくなります。水平および垂直スクロールを使用して全体を閲覧してください。
属性入力パターンの解釈
一貫した入力: 特定の属性が全アクティビティで同じ非ゼロ値を示しているなら、プロセスの早い段階で入力されるケースレベル属性です。
段階的な入力: 初期のアクティビティで0、後のアクティビティで非ゼロ値を示す場合、その属性は特定のプロセス段階で入力されていることを示します。
部分的な入力: 属性値が総ケース数より少ない場合、いくつかのケースでその属性が欠落していることを意味し、データ品質問題や任意項目の可能性があります。
アクティビティ特有の入力: ある属性が特定アクティビティでのみ非ゼロ値を示す場合、イベントレベル属性でそのアクティビティに関連しています。
パフォーマンス考慮点
- 大規模データセット: 属性やアクティビティが数百ある場合、処理に時間がかかることがあります
- リソース使用: 属性-アクティビティの全組み合わせをスキャンするため計算負荷が高いです
- 推奨: 非ピーク時間にこの計算機を実行してください
管理者アクセス
この計算機は管理者ロールのユーザーに制限されています。データセットの概要を理解したい通常ユーザーは、詳細な属性-アクティビティの内訳なしにサマリ指標を提供するDataset Information計算機を使用してください。
このドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。