日本企業に「業務モデル」は存在しない
多くの日本企業には「現行業務モデル」など存在していません。現場は慣習と担当者の経験則で動き、業務手順は曖昧なままです。金融機関ですら「法律違反でなければOK」という最低限の基準で動いており、業務が体系的に設計されていない例が殆どと言っても過言ではありません。
この状況でERPを導入すると、ERPベンダーが提供する「標準モデル」と自社業務の整合性を議論できず、結局「当社独自のやり方」を押し通す形でアドオンを乱発してしまいます。結果としてERPの持つ標準化効果は失われ、維持コストばかりが膨らむのです。
業務モデリングの目的
業務モデリングの本質は、「暗黙知のやり方」を「明示知の設計図」に変換することです。具体的には、以下の9つの観点を整理する作業を指します。
1. 目的と指標：なぜその業務が存在するのか。顧客価値、収益性、規制遵守など。
2. 語彙と定義：用語の意味を全社で揃える（例：顧客、案件、売上）。
3. 価値の流れ：入力（顧客の要請）から出力（納品・請求・サービス提供）までの一貫性。
4. 役割と責任：誰が実行し、誰が判断し、誰が承認するのかを明確にする。
5. データ構造：入力項目と更新責任、正本データ（Single Source of Truth）の決定。
6. 状態とイベント：業務の進行を「状態」で区切り、どんな出来事（イベント）で遷移させるかを定義する。
7. 業務ルール：判断基準、承認レベル、分掌、例外条件。
8. 統制と証跡：リスクをどこで制御し、どんな記録を残すか。
9. 例外処理：通常プロセスから外れる場合の扱い（拒否、吸収、別レーンで対応）。
これらを整理することで、業務は属人性から解放され、ERPの標準モデルと比較可能になります。
レイヤーで考える ― 意図から実装へ
業務モデルは、一つの図では完結しません。少なくとも以下の4つのレイヤーに分けて考える必要があります。
• 意図レイヤー：顧客価値やKPIなど「なぜその業務が必要なのか」。
• 価値レイヤー：顧客の要請をどう受け取り、どんな成果で応えるのかという流れ。
• 運用レイヤー：役割・責任・状態・ルール・統制を具体的に記述。
• 実装レイヤー：ここで初めて画面、帳票、インターフェースなどシステム仕様に落とし込む。
多くのERP失敗は、意図や価値の議論を飛ばしていきなり「実装レイヤー」から議論してしまうことにあります。
業務モデリングの進め方
現実的に、全社一気に業務モデルを作るのは不可能です。まずは一本の「価値の流れ」に絞り、小さく回すことが大切です。
例：受注 → 出荷 → 請求 → 入金
ステップ例
1. 語彙を揃える（顧客とは何か、受注の定義は何か）
2. イベントと状態を決める（受注登録、与信承認、出荷確定、売上計上）
3. 責任とルールを整理（誰が判断し、どの条件で例外が許されるか）
4. データと正本を確定（顧客コード、商品コードの体系を統一）
5. 例外とKPIを明示（差戻し率、リードタイム、一次通過率など）
このプロセスを短期間で回し、成果を確認しながら他の業務へ展開していくのが現実的です。
ERPとの接続
完成した業務モデルは、そのままERPの標準モデルと照合するための“物差し”になります。
• 標準モデルに業務を合わせられるか？
• どうしても独自性を残す必要があるのか？
• カスタマイズが不可欠な場合、それは顧客価値に直結するのか？
この判断を行う際、業務モデリングがなければ「なんとなくのこだわり」でアドオンを追加するしかなくなります。業務モデリングは、カスタマイズを合理的に制御する唯一の手段なのです。
成果の測り方
業務モデリングの効果は、「協調コストの削減」として現れます。会議時間の短縮、差戻し件数の減少、決算の早期化、例外処理率の低下――これらはすべて業務がモデルとして整備された証拠です。
ERPを経営基盤として活かすためには、こうした指標を使って「モデルの完成度」を測ることが欠かせません。
まとめ
業務モデリングとは、暗黙知を明示知に変え、経営と現場を同じ設計図で結びつける行為です。
これなくしてERPを導入するのは、設計図なしに巨大な建築物を建てるようなもの。失敗するのは当然です。
ERPを本当に経営基盤として活かしたいなら、まず「業務をモデルとして描き直す」ことから始めるべきなのです。
次回予告
第5回では、「ERPの本質を活かすDX」についてお話しします。ERPを導入するだけではDXにはなりません。ERPをどう活かして戦略と業務をつなぎ、新しい価値を生み出すかを議論します。
合同会社タッチコア 小西一有
第1回：ERPとは何か？ー単なるシステムではない経営基盤ERP
