ERP刷新で「この業務は特殊だからカスタマイズが要る」という主張を崩せない。AIエージェントを適用したいが、どこに効くのか特定できない。ツールは入れたのに現場の負荷は減っていない——別々に見えるこれらの行き詰まりは、同じ一点に行き着きます。業務が実際にどう流れているのかを、誰も事実として掴んでいないという点です。

本記事では、システムのログから実際の業務の流れを再構成するプロセスマイニングを、ツール導入ではなく「意思決定の材料をつくる取り組み」としてどう始めるかを整理します。

課題 ― 議論の土台が「記憶と主張」になっている

業務改革やシステム刷新の検討では、現行業務を把握するために業務部門へのヒアリングとワークショップを重ねます。しかしそこで集まるのは、担当者が記憶している業務と、そうあるべきだと考えている業務です。手順書に書かれた流れと現場で実際に起きている流れは、多くの組織で一致しません。

この状態で標準化を議論すると、「例外的な処理が必要だ」という主張の当否を判断する材料がありません。その処理が実際に何件発生し、そもそも本当に使われているのか——誰も答えを持たないまま、声の大きさで結論が決まります。結果としてカスタマイズは残り、刷新後も同じ構造が再生産されます。

なぜ今、あらためて問われるのか

三つの流れが重なっています。

第一に、ERPの標準化圧力です。クラウドERPへの移行に伴い、標準機能に業務を合わせるFit to Standardの考え方が広がりました。調査会社からも、カスタマイズ比率が高いプロジェクトほど遅延と予算超過のリスクが高まるという指摘が出ています。ただしこの方針は、「どの業務を標準に寄せられるか」を事実で判断できて初めて実行できます。

第二に、AI適用の前提としての可視化です。AIエージェントに業務を任せる検討では、対象業務の入力・判断・例外分岐が定義されている必要があります。実態が曖昧なまま適用すると、例外処理だけが人に残り、全体の負荷は下がりません。

第三に、DXの成果停滞です。IPAの調査でも、DXへの着手は広がった一方で、AI活用が業務効率化の範囲にとどまる状況が示されています。打ち手を増やしても、直すべき場所を外していれば効果は出ません。

プロセスマイニングとは何を見る手法か

プロセスマイニングは、基幹システムやワークフローに蓄積されたログから、実際の処理の流れを機械的に再構成する手法です。必要なのは最低限「どの案件が」「いつ」「どの処理を通ったか」の三要素で、これが揃えば案件ごとの経路を時系列に並べ直し、業務の実像を描けます。用途は大きく三つに分かれます。

用途 何がわかるか 典型的な使いどころ
発見 実際に発生している経路の全体像と頻度 現行業務の棚卸し、刷新前の実態把握
適合性検査 想定した流れからの逸脱と、その発生箇所 標準化の徹底度合いの確認、内部統制
改善 待ち時間・手戻り・再処理の集中箇所 改善対象の優先順位づけ、AI適用箇所の特定

一方で、ログに残らない仕事は見えません。メールや表計算ソフト上のやり取り、システム外の調整はそのままでは捕捉できず、端末操作の記録から補うタスクマイニングを併用するか、対象範囲を割り切る判断が必要になります。ここを理解せずに導入すると、「全業務が見えるはずだったのに見えない」という失望に終わります。

進め方 ― 四つのステップ

ステップ1：問いを先に決める 「業務を可視化する」は目的になりません。「購買の承認リードタイムが長い原因はどこか」「受注処理の例外分岐は本当に必要か」といった、答えが出たら誰が何を決めるのかまで含めた問いを先に置きます。ここが曖昧なまま始めた取り組みは、精緻な図が出来上がった時点で止まります。

ステップ2：対象を一つの業務領域に絞る 全社一斉ではなく、購買や受注など、ログが残っていて改善余地も大きい領域を一つ選びます。刷新プロジェクトが動いているなら、その対象業務に合わせるのが最も投資対効果の高い選び方です。

ステップ3：イベントログを整える 実務上、最も工数がかかる工程です。案件を一意に識別できるキーが揃っているか、処理の記録に抜けがないか、システムをまたぐ場合に案件を突き合わせられるかを確認します。品質が低いまま分析すると、誤った実像を根拠に意思決定してしまいます。データの持ち方そのものに課題があるなら、データガバナンスの整備と並行して進めることになります。

ステップ4：事実を意思決定の場に載せる 分析レポートで終わらせず、標準化方針やアドオン可否を決める会議の議題に載せます。「この処理はごく少数しか発生していない」という事実が示されて初めて、例外を残すかどうかの議論が成立します。

体制 ― 事実を突きつけられるのは誰か

分析自体はIT部門やデータ分析チームで完結しますが、それだけでは組織は動きません。可視化された実態は、業務部門にとって「自分たちのやり方への異議申し立て」に見えるためです。

実効性を持たせている組織に共通するのは、業務領域ごとにプロセスの責任者を置き、その判断を上位者が支える構造です。標準化の範囲を業務側の責任者が定義し、個別要望の可否に経営層が関与する。この形をとらない限り、分析結果は参考資料の一つとして扱われ、従来どおりの結論に戻ります。

推進側から見れば、プロセスマイニングは業務プロセス層の可視化であり、エンタープライズアーキテクチャの一部を実データで埋める取り組みでもあります。

よくある失敗と回避策

失敗パターン 回避策
可視化そのものが目的化し、図の精緻化に工数を使う 着手前に「誰が何を決めるための材料か」を文書で合意する
全社・全業務を一度に対象にして頓挫する ログが揃い改善余地の大きい一領域から始め、型を作ってから広げる
ログ整備の工数を見積もらず、計画が破綻する 分析より前にログの実在と品質を確認する期間を明示的に取る
分析結果が業務部門への批判と受け取られ、協力を失う 個人や部門の評価に使わないことを明言し、対象は経路と時間に限定する
一度の分析で終わり、刷新後に元へ戻る 稼働後も同じ指標で継続測定し、逸脱の監視を定例に組み込む

まとめ

プロセスマイニングは業務改革を自動化する手段ではなく、議論の土台を「記憶と主張」から「事実」に置き換えるための道具です。

始め方はツール選定からではありません。答えを出したい問いを決め、対象を一領域に絞り、ログの品質を確認し、その結果を意思決定の場に載せる。この順序を守れば、限られた投資でも標準化やAI適用の判断は変わります。

FAQ

Q. 専用ツールを導入しないと始められませんか。 A. 本格的な分析には専用ツールが有利ですが、最初の一歩は既存のBIツールや表計算ソフトでも踏み出せます。特定の業務について案件ID・日時・処理名の三点を抽出し、経路のばらつきを数えるだけでも、議論の土台は大きく変わります。まず小さく事実を出し、投資判断はその後で構いません。

Q. 基幹システムが古く、ログがほとんど残っていません。 A. その場合は無理に全体を対象にせず、ワークフローシステムや承認履歴など、記録が残っている周辺業務から始めるのが現実的です。あわせて、刷新の要件として「後から業務の流れを追えるログを残す」ことを盛り込んでおくと、次の刷新サイクルで効いてきます。

Q. RPAやBPMツールとは何が違いますか。 A. RPAは決まった作業を代行する実行の手段、BPMはあるべき業務を定義し回す管理の手段です。プロセスマイニングはその手前で、現に何が起きているかを測る役割を担います。実態を測らずに自動化すると、非効率な手順をそのまま高速化してしまうため、順序として先に置く価値があります。

Q. 誰が主管すべきですか。 A. 分析の実務はIT部門やデータ部門が担うとしても、結果を意思決定に使う責任は業務側に置く必要があります。刷新プロジェクトが動いているならPMOが分析結果と意思決定会議をつなぐ役割を持つと、成果物が宙に浮きにくくなります。

参考資料