値のカウント
概要
Count Values エンリッチメントは強力な統計解析ツールであり、プロセスデータセット内の各ケースに対して選択したイベント属性の異なる(ユニークな)値の数をカウントします。このエンリッチメントは、プロセスインスタンス全体にわたるデータ値の多様性や種類を理解する上で不可欠です。ユニークな値の数を含む新しいケースレベルの属性を作成し、データの複雑さ、変動パターン、および潜在的なデータ品質の問題に関する洞察を提供します。
このエンリッチメントは、カテゴリカルデータの変動を分析し、属性値の異常な多様性を持つケースを特定し、プロセスの複雑さの指標を理解するのに特に有用です。総発生数ではなく異なる値の数をカウントすることで、同一属性に対して複数の異なる値が現れるケース(例:異なる注文された製品タイプ、関与する複数の部門、ケース実行中に発生した複数のステータスなど)を識別するのに役立ちます。
このエンリッチメントはケースレベルで動作し、各ケース内のすべてのイベントを調べて、指定された属性のユニークな値がいくつ存在するかを判断します。したがって、個々のプロセスインスタンス内の多様性、複雑さ、またはデータの豊かさを測定する必要があるシナリオに最適です。
主な用途
- 単一の購入注文で異なる製品またはSKUの数をカウントする
- ケース処理に関与した異なる部門やチームの数を特定する
- ケース実行中に出現したエラーコードや例外タイプの多様性を測定する
- 調達ケースで関与したユニークなベンダーやサプライヤーの数を決定する
- 単一取引でサービスされた異なる顧客セグメントやカテゴリをカウントする
- 承認ワークフローにおける承認レベルや認可ステータスの多様性を分析する
- ケース処理中にアクセスされた異なるシステムやアプリケーションの数を追跡する
設定
新しい属性名: ユニークな値の数を保存する新しいケース属性の名前です。カウントされる内容が明確に分かる説明的な名前にしてください。例えば、ユニークな製品タイプをカウントする場合は「Unique_Product_Count」や「Product_Variety_Count」などが考えられます。この属性は整数型として作成され、数値形式で表示されます。
属性名: ユニークな値をカウントするイベント属性です。このドロップダウンにはデータセット内のすべての利用可能なイベント属性がリストアップされます。ユニーク性を分析したい値を含む属性を選択してください。このエンリッチメントは各ケース内のすべてのイベントにわたってこの属性を調べて異なる値をカウントします。
Nullを許可: Null(空)値をユニーク値のカウントに含めるかどうかを決定するチェックボックスオプションです。チェックすると(true)、ケース内にNull値が存在する場合、それを1つの異なる値としてカウントします。チェックしない場合(false)はNull値は無視されカウントされません。データに欠損値が含まれる可能性がある場合、この設定は正確なカウントに重要です。
フィルター: ユニーク値をカウントする際に考慮するイベントを制限するための任意のフィルターです。これにより、特定のアクティビティ、期間、またはケース内の他のフィルタリングされたイベントサブセットからのみ異なる値をカウントできます。フィルターが指定されていない場合は、ケース内のすべてのイベントが調べられます。
例
例 1:購入注文における製品の多様性のカウント
シナリオ: 小売会社が、購入注文で通常どのくらい異なるSKUが一緒に注文されるかを理解し、倉庫のピッキングプロセスの最適化やバンドル商品の機会を特定したいと考えています。
設定:
- 新しい属性名: Unique_SKU_Count
- 属性名: Product_SKU
- Nullを許可: いいえ(未チェック)
- フィルター: アクティビティが "Add Item to Order" と等しい
出力: エンリッチメントは各注文に含まれる異なる製品SKUの数を格納する新しいケース属性「Unique_SKU_Count」を作成します:
- ケース PO-2024-001: Unique_SKU_Count = 5(顧客が5種類の製品を注文)
- ケース PO-2024-002: Unique_SKU_Count = 1(単一製品の注文)
- ケース PO-2024-003: Unique_SKU_Count = 12(多くの製品を含む複雑な注文)
洞察: 高いユニークSKUカウントを持つ注文は、倉庫でのピッキングがより複雑です。同社はこの指標を使って注文を効率的にルーティングし、よく一緒に注文される商品のバンドル機会を特定できます。
例 2:ITチケットでの部門関与の分析
シナリオ: ITサービスデスクが、各チケットの解決に関与した異なる部門の数をカウントして、クロスファンクショナルな協力を必要とするチケットを特定したいと考えています。
設定:
- 新しい属性名: Departments_Involved_Count
- 属性名: Assigned_Department
- Nullを許可: いいえ(未チェック)
- フィルター: なし(すべてのイベントを分析)
出力: 各ITチケットケースに「Departments_Involved_Count」属性が付与されます:
- ケース TICKET-5001: Departments_Involved_Count = 1(完全にヘルプデスクが担当)
- ケース TICKET-5002: Departments_Involved_Count = 3(ヘルプデスク、ネットワークチーム、セキュリティを経由してエスカレーション)
- ケース TICKET-5003: Departments_Involved_Count = 5(複数のチームが必要な複雑な問題)
洞察: 複数部門が関与するチケットは解決時間が長くコストも高いです。組織はこの指標を活用してルーティングを改善し、より良い協力プロトコルの確立やトレーニングニーズの特定に役立てています。
例 3:調達プロセスにおけるサプライヤー多様性
シナリオ: 製造会社がサプライヤー多様化ポリシーの遵守を確保し、単一ソース依存を特定するために調達プロセスでのサプライヤー多様性を追跡したいと考えています。
設定:
- 新しい属性名: Unique_Supplier_Count
- 属性名: Supplier_ID
- Nullを許可: はい(チェック済み)
- フィルター: アクティビティが「Quote」または「Purchase」を含む
出力: エンリッチメントは各調達ケースに「Unique_Supplier_Count」を追加します:
- ケース PROC-2024-101: Unique_Supplier_Count = 4(4社の異なるサプライヤーから見積もり取得)
- ケース PROC-2024-102: Unique_Supplier_Count = 1(単一ソース調達)
- ケース PROC-2024-103: Unique_Supplier_Count = 7(多くのサプライヤーによる競争入札)
洞察: サプライヤーが1社のみのケースは供給リスクとなります。同社は特定の金額以上の購入には最低サプライヤー数を要求するポリシーを実施し、この指標で遵守を監視しています。
例 4:製造におけるエラータイプ分析
シナリオ: 製造工場が生産ロットにおける品質問題の多様性を理解し、品質改善イニシアティブの優先順位付けや問題のある生産ラインの特定を行いたいと考えています。
設定:
- 新しい属性名: Distinct_Error_Types
- 属性名: Quality_Error_Code
- Nullを許可: いいえ(未チェック)
- フィルター: アクティビティが「Quality Check Failed」と等しい
出力: 各生産バッチケースに「Distinct_Error_Types」カウントが付与されます:
- ケース BATCH-2024-A001: Distinct_Error_Types = 0(品質問題なし)
- ケース BATCH-2024-A002: Distinct_Error_Types = 2(2種類の欠陥を検出)
- ケース BATCH-2024-A003: Distinct_Error_Types = 5(システム的問題を示す複数の品質問題)
洞察: 高い異なるエラー数を持つバッチはシステム的な品質問題が示唆され、直ちに対応が必要です。工場はこの指標を使って品質レビューや予防保全をトリガーします。
例 5:顧客インタラクションチャネル分析
シナリオ: カスタマーサービスセンターが、顧客がサービス利用時に使用する異なるコミュニケーションチャネルの数を把握し、オムニチャネルサポート戦略を最適化したいと考えています。
設定:
- 新しい属性名: Communication_Channels_Used
- 属性名: Interaction_Channel
- Nullを許可: いいえ(未チェック)
- フィルター: なし(すべての顧客インタラクションをカウント)
出力: エンリッチメントは各顧客ケースにチャネル多様性の指標を作成します:
- ケース CUST-2024-1001: Communication_Channels_Used = 1(電話のみ)
- ケース CUST-2024-1002: Communication_Channels_Used = 3(電話、メール、チャット)
- ケース CUST-2024-1003: Communication_Channels_Used = 4(電話、メール、チャット、ソーシャルメディア)
洞察: 複数チャネルを使用する顧客は、複雑な問題や単一チャネルでの解決に対する不満を示すことが多いです。同社はチャネル統合を改善し、すべての接点で一貫した情報提供を実現して顧客体験を向上させています。
出力
Count Values エンリッチメントは以下の特性を持つ単一の新しいケースレベル属性を生成します:
属性タイプ: 整数(Int32)- カウントは常にユニークな値の数を表す整数です。
属性名: 「新しい属性名」設定で指定された名前を使用します。カウント対象が明確な説明的な名前を選択してください。
表示形式: 属性はデータセットビューで自動的に数値形式で表示され、並べ替えやフィルタリング、分析が容易です。
値の範囲: カウントは0(該当値が見つからないか「Nullを許可」が未チェックで全てNull値の場合)から、ケース内のイベント数の最大値(各イベントが異なる値を持つ場合)までの範囲です。
統合: 新しい属性は以下にすぐに使用可能です:
- 特定のユニーク値数を持つケースを識別するフィルター
- 統計解析や集計のための計算機
- 数値ケース属性を必要とする他のエンリッチメント
- プロセスマイニングの視覚化やダッシュボード
- 外部分析のためのエクスポート操作
参照
- Event Count - 各ケースのイベント総数をカウント
- Summarize Values - 数値属性の合計、平均、その他統計の計算
- Max Value - 各ケースの数値属性の最大値を取得
- Count Boolean Attributes with Value - 特定の値を持つブール属性の数をカウント
- Compare Activity Counts - 2つのアクティビティの実行回数を比較
このドキュメントは mindzieStudio のプロセスマイニングプラットフォームの一部です.