ストーリー
田
田中VPoE
「NetShop社の請求書処理プロセスについて、経理チームに聞き取りをしたところ、『受領→入力→承認→支払い』という単純なフローだと言っていた。しかし実際のシステムログを見ると、まったく違う実態が浮かび上がった。」
あなた
「現場の認識と実態にギャップがあるんですね。」
あ
田
田中VPoE
「そうだ。人間の記憶は『理想的なフロー』を語りがちだ。プロセスマイニングはシステムログという客観的なデータからプロセスの実態を浮き彫りにする。これがAs-Is分析の核になる。」
プロセスマイニングとは
プロセスマイニングは、情報システムに記録されたイベントログを分析し、業務プロセスの実態を可視化・分析する手法だ。
プロセスマイニングの3つの手法
| 手法 | 目的 | 入力 | 出力 |
|---|
| プロセス発見 | ログからプロセスモデルを自動生成 | イベントログ | プロセスモデル(BPMN等) |
| 適合性チェック | 理想プロセスと実態の差異を検出 | イベントログ + 理想モデル | 逸脱レポート |
| プロセス拡張 | 既存モデルをログデータで強化 | イベントログ + 既存モデル | 強化モデル(時間・コスト情報付き) |
イベントログの構造
プロセスマイニングの基盤はイベントログだ。NetShop社の請求書処理を例に見てみよう。
イベントログの基本構造
| 必須項目 | 説明 | 例 |
|---|
| ケースID | 個別プロセスの識別子 | INV-2025-0001 |
| アクティビティ | 実行されたタスク名 | 請求書受領 |
| タイムスタンプ | イベント発生日時 | 2025-01-15 09:23 |
| 推奨項目 | 説明 | 例 |
|---|
| リソース | 実行者 | 山田太郎 |
| コスト | 処理コスト | 500円 |
| 属性 | 追加情報 | 請求金額: 150,000円 |
NetShop社の請求書処理ログ例
ケースID | アクティビティ | タイムスタンプ | リソース | 属性
INV-2025-0001 | 請求書受領(メール)| 2025-01-15 09:23:45 | 自動取込 | 金額:150,000
INV-2025-0001 | PDF→データ変換 | 2025-01-15 09:30:12 | 田中経理 | 手入力
INV-2025-0001 | 発注書との照合 | 2025-01-15 10:15:33 | 田中経理 | 照合OK
INV-2025-0001 | 上長承認依頼 | 2025-01-15 10:20:01 | 田中経理 | 承認者:鈴木課長
INV-2025-0001 | 上長承認 | 2025-01-16 14:30:22 | 鈴木課長 | 承認
INV-2025-0001 | 支払い処理 | 2025-01-20 10:00:00 | 経理システム| バッチ処理
INV-2025-0002 | 請求書受領(郵送) | 2025-01-15 11:00:00 | 佐藤経理 | 金額:80,000
INV-2025-0002 | スキャン・PDF化 | 2025-01-15 14:22:10 | 佐藤経理 | 手動スキャン
INV-2025-0002 | PDF→データ変換 | 2025-01-15 15:10:45 | 佐藤経理 | 手入力
INV-2025-0002 | 発注書との照合 | 2025-01-15 16:05:33 | 佐藤経理 | 不一致
INV-2025-0002 | 差異確認 | 2025-01-16 09:30:00 | 佐藤経理 | 発注部門に問合せ
INV-2025-0002 | 発注書との照合 | 2025-01-17 11:20:15 | 佐藤経理 | 照合OK(修正後)
INV-2025-0002 | 上長承認依頼 | 2025-01-17 11:25:00 | 佐藤経理 | 承認者:鈴木課長
INV-2025-0002 | 上長承認 | 2025-01-17 16:45:30 | 鈴木課長 | 承認
INV-2025-0002 | 支払い処理 | 2025-01-20 10:00:00 | 経理システム| バッチ処理
プロセス発見
イベントログから実際のプロセスフローを自動的に再構成する。
請求書処理の発見されたプロセス
請求書受領(メール)──→ PDF→データ変換 ──→ 発注書との照合 ──→ 上長承認依頼 ──→ 上長承認 ──→ 支払い処理
│
請求書受領(郵送)──→ スキャン・PDF化 ──┘ │
↓(不一致の場合)
差異確認 ──→ 発注書との照合(再)
発見された主要なバリアント(経路パターン)
| バリアント | 頻度 | 平均所要時間 | 特徴 |
|---|
| メール受領 → 正常フロー | 45% | 3.2日 | 最も効率的な経路 |
| 郵送受領 → 正常フロー | 25% | 4.5日 | スキャン工程が追加 |
| メール受領 → 差異確認あり | 15% | 6.8日 | 照合不一致による遅延 |
| 郵送受領 → 差異確認あり | 10% | 8.2日 | 最も時間がかかる経路 |
| その他(差し戻し等) | 5% | 10日以上 | 複数回の差し戻しあり |
適合性チェック
理想プロセス(マニュアル通りのフロー)と実際のプロセスを比較し、逸脱を検出する。
主な逸脱パターン
| 逸脱タイプ | 内容 | 頻度 | 影響 |
|---|
| アクティビティのスキップ | 発注書との照合を飛ばして承認依頼 | 8% | 支払いミスのリスク |
| 順序の逆転 | 承認前に支払い処理が実行される | 2% | 内部統制違反 |
| 未定義アクティビティ | マニュアルにない「メールでの確認」が挿入 | 20% | 非効率だが実務上必要 |
| 繰り返し | 差し戻しによる照合の複数回実行 | 15% | 大幅な遅延の原因 |
適合度の測定
適合度 = 正常フローに従ったケース数 / 全ケース数
NetShop社の請求書処理:
適合度 = 70% / 100% = 0.70(やや低い)
業界ベンチマーク: 0.85以上が望ましい
プロセスマイニングツール
| ツール | 特徴 | 費用感 | 適用場面 |
|---|
| Celonis | 業界最大手、豊富な機能 | 高額(エンタープライズ) | 大規模プロセス分析 |
| Minit | 直感的なUI、導入しやすい | 中程度 | 中規模企業向け |
| PM4Py | Pythonライブラリ、無料 | 無料 | データサイエンス向け |
| Disco | 高速な可視化 | 中程度 | 初期分析・PoC |
| Microsoft Process Advisor | Power Platform連携 | Microsoft365に含む | Microsoft環境 |
まとめ
| 項目 | ポイント |
|---|
| プロセスマイニング | イベントログから業務プロセスの実態を可視化する手法 |
| 3つの手法 | プロセス発見、適合性チェック、プロセス拡張 |
| イベントログ | ケースID、アクティビティ、タイムスタンプが必須 |
| バリアント分析 | プロセスの経路パターンを分類し、頻度と所要時間を比較 |
| 適合性チェック | 理想と実態のギャップを定量的に測定 |
チェックリスト
次のステップへ
次は「ボトルネック分析」として、待ち時間やリワークの検出方法を学ぼう。
推定読了時間: 30分