ピボットテーブル
概要
ピボットテーブル計算機は、複数の次元で同時にプロセスデータを整理し要約するクロス集計ビューを作成します。この強力な分析ツールでは、ケースまたはイベント属性を列としてピボットし、件数、合計、平均、その他の統計的指標を集約できます。1つか2つのカテゴリ分解を表示する「Breakdown by Categories」計算機と異なり、ピボットテーブルは行と列からなる従来のスプレッドシートスタイルのピボットテーブルを作成します。
この計算機は、生のプロセスデータを整理された要約表に変換し、異なるカテゴリ次元間の関係を分析し、さまざまな指標がそれらの次元にどのように分布しているかを理解できます。
主な用途
- 部門別および期間別のコストや収益を示す財務概要レポートの作成
- 異なる活動や組織単位にわたるリソース作業負荷分布の分析
- 複数のカテゴリ次元にわたるパフォーマンス指標の比較
- カテゴリおよびサブカテゴリごとのコンプライアンスレポートの生成
- 多次元のプロセスメトリクスを表示する経営者向けダッシュボードの構築
- 複数のプロセス属性にわたるパターン特定のためのクロス集計分析の実施
設定
行属性: ピボットテーブルの行を形成するケースまたはイベント属性を選択します。この属性の各一意の値が出力テーブルの行になります。
列属性（任意）: ピボットテーブルの列を形成する2番目の属性を選択します。各一意の値が別々の列を作成します。指定しない場合、ピボットテーブルは単一列の要約を表示します。
集約関数: 各行-列交差点でどのようにデータを集約するか選択します：
| 関数 | 説明 | 使う場面 |
|---|---|---|
| Count | ケースまたはイベントの数を数える | 各カテゴリに該当するアイテム数を知りたい場合 |
| Sum | 選択した属性の値を合計する | 合計値（例：総コスト、総収益）が必要な場合 |
| Average | 選択した属性の平均値を計算する | 典型的な値（例：平均処理時間）が欲しい場合 |
| Minimum | 最小値を見つける | 各カテゴリの最小値を特定したい場合 |
| Maximum | 最大値を見つける | 各カテゴリの最大値を特定したい場合 |
| Median | 中央値を計算する | 外れ値の影響を減らした典型値が欲しい場合 |
値属性: Count以外の集約関数（SumやAverageなど）を選択した場合、集約したい数値属性を指定します。Countの場合は不要です。
並べ替え順序: 行を並べ替えるかどうかを選択します：
- 昇順: アルファベット順または数値の小さい順に並べる
- 降順: 大きい順に並べる（トップカテゴリの特定に便利）
最大行数: 表示する最大行数を指定します。多くの一意値がある場合に上位Nカテゴリのみ見たいときに便利です。空欄にするとすべての行を表示します。
例
例1: リソース別活動概要
シナリオ: 各リソースがプロセス内でどの活動を何回実行したかを示す要約表を作成したい。これにより作業負荷の分布やリソースの専門化パターンを把握できます。
設定:
- 行属性: Resource
- 列属性: Activity Name
- 集約関数: Count
- 最大行数: 20
出力:
リソースを行に、活動を列にしたピボットテーブルが作成されます。各セルはそのリソースがその活動を実行した回数を示します。
| Resource | Create Order | Approve Order | Process Payment | Ship Items | Close Order | Total |
|---|---|---|---|---|---|---|
| Alice Johnson | 245 | 189 | 0 | 0 | 234 | 668 |
| Bob Smith | 0 | 0 | 456 | 0 | 0 | 456 |
| Carol White | 123 | 145 | 234 | 0 | 198 | 700 |
| David Brown | 0 | 0 | 0 | 567 | 0 | 567 |
| Emma Davis | 189 | 234 | 123 | 0 | 212 | 758 |
洞察: このピボットテーブルは明確な活動専門化のパターンを示しています。Bob Smithは決済処理のみ担当（456件）、David Brownは出荷業務専門（567件）です。Alice、Carol、Emmaは複数の活動を担当しており、ジェネラリストの傾向があります。Emmaが最も多くの活動数（758）を持ち、最も活発なリソースです。ピボット形式は作業負荷の不均衡も明白にします—例えば、注文承認は3人のリソース（Alice、Carol、Emma）のみで処理されており、ボトルネックになりうることがわかります。任意のセルをクリックすると、そのリソースが特定の活動を行ったケースを詳細に掘り下げられます。
例2: 部門別・月別コスト分析
シナリオ: 各部門の月別総コストを示す財務レポートを作成し、支出傾向を追跡し異常なコスト変動を特定したい。
設定:
- 行属性: Department
- 列属性: Case Start Month
- 集約関数: Sum
- 値属性: Total Cost
- 並べ替え順序: 降順
出力:
部門を行、月を列にしたピボットテーブルが作成され、各組み合わせの総コストを示します。
| Department | January | February | March | April | May | Row Total |
|---|---|---|---|---|---|---|
| Operations | $456,789 | $478,234 | $502,456 | $489,123 | $495,678 | $2,422,280 |
| Sales | $234,567 | $245,678 | $256,789 | $267,890 | $278,901 | $1,283,825 |
| IT | $189,234 | $195,678 | $198,234 | $201,456 | $205,678 | $990,280 |
| HR | $89,234 | $92,345 | $87,234 | $91,456 | $93,678 | $453,947 |
| Finance | $67,890 | $71,234 | $69,345 | $72,456 | $74,567 | $355,492 |
洞察: このピボットテーブルは明確な財務概要を提供します。Operations部門は5か月で合計$2.4Mと最も高く、最大の部門として想定通りです。Operationsは1月の$456Kから5月の$495Kまで緩やかな増加傾向があり、活動増加またはケースあたりコスト上昇が推測されます。Salesも月々増加傾向で、事業拡大を示唆します。ITは月あたり$195-205Kと比較的安定。HRは3月にやや減少（$87K）が見られ調査が必要かもしれません。このピボット形式は部門ごとの総支出（行合計）と月別全体傾向（列合計）を簡単に把握できます。
例3: バリアントおよび部門別適合率分析
シナリオ: どのプロセスバリアントが適合問題を抱え、部門間でどのように異なるか理解したい。これにより改善対象を特定できます。
設定:
- 行属性: Process Variant
- 列属性: Department
- 集約関数: Count
- 最大行数: 10
出力:
| Variant | Sales | Operations | Customer Service | Total |
|---|---|---|---|---|
| Standard Path | 1,234 | 2,456 | 1,789 | 5,479 |
| Skip Approval | 234 | 67 | 456 | 757 |
| Rework Loop | 123 | 345 | 234 | 702 |
| Express Processing | 456 | 189 | 234 | 879 |
| Manual Override | 89 | 234 | 123 | 446 |
洞察: Standard Pathが全部門で最も多く（合計5479件）、望ましい状態です。一方、「Skip Approval」バリアントは757件発生し、Customer Serviceで最も多い（456件）ため、承認手順の省略圧力がある可能性があります。「Rework Loop」は702件でOperationsの345件が最多、品質問題の懸念があります。Salesは「Express Processing」（456件）を多用しており、正当な迅速処理かショートカットの可能性があります。セルクリックで個別ケースを確認し、非標準バリアント発生の原因調査が可能です。
例4: 活動組み合わせ別平均ケース期間
シナリオ: 最初と最後の活動の組み合わせで平均ケース期間が最も長いものを特定し、遅延の原因となるプロセス経路を理解したい。
設定:
- 行属性: First Activity
- 列属性: Last Activity
- 集約関数: Average
- 値属性: Case Duration (Days)
- 並べ替え順序: 降順
出力:
| First Activity | Standard Close | Manual Close | Cancelled | Exception Close | Average |
|---|---|---|---|---|---|
| Manual Entry | 12.5 days | 18.7 days | 8.3 days | 23.4 days | 15.7 days |
| Auto Import | 6.2 days | 14.3 days | 5.1 days | 19.8 days | 11.4 days |
| Web Submission | 5.8 days | 13.9 days | 4.8 days | 18.2 days | 10.7 days |
| Email Receipt | 8.9 days | 16.5 days | 6.7 days | 21.3 days | 13.4 days |
洞察: Manual Entryで開始したケースは平均15.7日と最長で、この入力方法が複雑さや誤りを生む可能性があります。「Exception Close」経路は開始方法に関わらず最も遅く（18.2～23.4日）、例外処理が特別な対応を要することを示しています。Manual EntryからException Closeの組み合わせは最悪で23.4日の平均期間です。Auto ImportやWeb Submissionは最速で（11.4日、10.7日）デジタルチャネルの品質の良さが示唆されます。ピボット形式は全組み合わせの比較と改善余地の特定に適しており、Manual Entryの削減やException Closeの効率化に注力すべきです。
例5: リソースパフォーマンススコアカード
シナリオ: ケースの複雑さ別に各リソースの平均ケース期間を示すパフォーマンススコアカードを作成したい。
設定:
- 行属性: Resource
- 列属性: Case Complexity
- 集約関数: Average
- 値属性: Case Duration (Hours)
- 並べ替え順序: 昇順
- 最大行数: 15
出力:
| Resource | Simple | Medium | Complex | Very Complex | Overall Average |
|---|---|---|---|---|---|
| Alice Chen | 2.3 hrs | 5.7 hrs | 12.4 hrs | 28.5 hrs | 12.2 hrs |
| Bob Martinez | 2.8 hrs | 6.2 hrs | 13.1 hrs | 31.2 hrs | 13.3 hrs |
| Carol Taylor | 2.1 hrs | 5.4 hrs | 11.8 hrs | 26.7 hrs | 11.5 hrs |
| David Wilson | 3.1 hrs | 6.8 hrs | 14.5 hrs | 34.2 hrs | 14.7 hrs |
| Emma Johnson | 2.2 hrs | 5.6 hrs | 12.1 hrs | 27.8 hrs | 11.9 hrs |
洞察: Carol Taylorが全複雑さレベルで最良のパフォーマンス（平均11.5時間）を示し、David Wilsonは最長（14.7時間）です。Carolの安定したスキルは、難易度に関わらず強みを示しています。すべてのリソースはSimpleからVery Complexまで時間が比例して増えており、複雑さの分類が有効であることがわかります。DavidのVery Complexタスク（34.2時間）はCarolの26.7時間を大きく上回り、追加トレーニングや支援の余地を示唆します。このピボットテーブルはトップパフォーマー（Carol、Emma、Alice）と支援が必要な者（David）を特定しやすく、チームの適切な時間配分も示します。
例6: 品質指標ダッシュボード
シナリオ: 製品ラインおよび顧客セグメント別に品質問題のあるケースの割合を示す品質ダッシュボードを作成したい。
設定:
- 行属性: Product Line
- 列属性: Customer Segment
- 集約関数: Average
- 値属性: Quality Score (0-100)
出力:
| Product Line | Enterprise | Mid-Market | Small Business | Consumer | Average |
|---|---|---|---|---|---|
| Premium | 94.5 | 92.3 | 89.7 | 87.2 | 90.9 |
| Standard | 89.2 | 87.6 | 84.3 | 82.1 | 85.8 |
| Economy | 85.7 | 83.4 | 79.8 | 77.5 | 81.6 |
| Custom | 96.2 | 94.8 | 91.2 | 88.9 | 92.8 |
洞察: Custom製品は全顧客セグメントで最高の品質スコア（平均92.8）を示し、個別対応と品質管理が寄与していると考えられます。Premium製品も良好（平均90.9）。Enterprise顧客は高品質（Premiumで94.5）で、Consumer顧客は低め（Premiumで87.2）という明確な品質差があり、サービスレベルの違いを示唆します。Economy製品は最も低いスコア（平均81.6）で特にConsumerセグメント（77.5）が懸念されます。Custom/Enterprise（96.2）とEconomy/Consumer（77.5）の17.5ポイントの差は大きなプロセス差異を示します。このピボットテーブルは改善優先度を視覚的に示し、Economy製品のConsumerおよびSmall Businessセグメントへの注力が望まれます。
出力
ピボットテーブル計算機は、行属性の一意値を行に、列属性の一意値を列に持つスプレッドシート形式の表を表示します（列属性指定時）。各セルはその行-列の組み合わせに対する集約値を含みます。
行合計: 列属性が指定されている場合、通常計算機は各行の全列合計を示す行合計列を含みます。
列合計: 表の下端に列の全行合計を示す合計行が表示されます。
インタラクティブ機能: 任意のセルの値をクリックすると、そのセルの値に寄与する具体的なケースを掘り下げて表示可能です。これにより任意のカテゴリ組み合わせの詳細調査ができます。
エクスポートオプション: ピボットテーブルをExcelやCSV形式でエクスポートし、更なる分析、レポート作成、関係者との共有に利用可能です。
可視化: データによっては、ピボットテーブルをヒートマップとして色分けし、高・低値を視覚的に把握しやすくできます。
大規模テーブル: 多数の行・列がある場合は、横・縦スクロールで全体を閲覧可能です。Max Rows設定で上位カテゴリに絞ることも検討してください。
このドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。