ERP導入とデータドリブン経営のギャップをどう埋めるか

ERP・SCP・BIなどの基幹システム投資は年々拡大しています。しかしその一方で、「データドリブン経営が実現できた」と明確に言える企業はまだ多くありません。

多くのプロジェクトではシステムは予定通り稼働するものの、意思決定や業務のやり方が変わらず、結果として投資対効果が限定的になるケースが見られます。 本記事では、このギャップがどこで生まれ、なぜ解消されないのか、そしてどのように埋めるべきかをプロジェクトマネジメントの観点から整理します。

---

データドリブン経営とは何か

データドリブン経営とは、単にデータを可視化することでも、BIダッシュボードを整備することでもありません。

本質は、意思決定の根拠がデータに置き換わり、組織の行動がそれに連動して変化している状態です。

つまり、「データを見る経営」ではなく「データで決める経営」です。

データドリブン経営が実現している状態

データドリブン経営が実現している企業では、以下のような状態が日常的に成立しています。

特に重要なのは、会議が単なる状況共有ではなく、意思決定やアクションがデータによってなされる場になっている点です。これにより、計画・実行・検証のサイクルが高速に回るようになります。

データドリブン経営ができていない状態

一方で多くの企業では、システムは整備されていても意思決定は従来型のままです。

典型的には以下のような状態です。

• ERPは導入されているが、判断は経験と勘に依存している
• BIは存在するが、既存帳票の置き換えにとどまる
• SCPは自動発注や処理効率化のツールとしてのみ利用される
• 部門ごとに異なる数字を前提に議論している
• 会議は実績報告が中心で、意思決定が弱い
• 数字はそのまま出せず、どのようにまとめるかでトーンが大きく変わる

この状態では、データは「存在しているが使われていない資産」となり、投資効果は限定的になります。

---

データドリブン経営が実現できない理由

このギャップの本質は技術の問題ではなく、プロジェクト設計と組織構造にあります。

プロセス設計が優先されデータ活用設計が後回しになる

ERP導入プロジェクトでは、業務プロセス標準化や高度化が優先されがちです。その結果、「データをどう使って意思決定を変えるか」という視点が後回しになります。

本来は業務効率化ではなく意思決定変革がゴールであるべきですが、設計段階でそこが十分に掘り下げられないと、結果として“業務は整ったが意思決定は変わらない”状態になります。

KPI・意思決定プロセスが定義されていない

KPIは設定されていても、それがどの意思決定に使われるのかが明確でないケースが多く見られます。

• 誰が判断するのか
• どのタイミングで判断するのか
• 何をトリガーに意思決定を変えるのか

これが曖昧なままでは、KPIは「見るための数字」にとどまり、「行動を変える指標」にはなりません。

しかし、多くのプロジェクトでは、業務プロセス設計をなんとか終わらせるのに力のほとんどを費やしてしまい、BIやそれによって実現されるデータドリブン経営については、ほとんど議論されないまま、後続タスクが進行するケースが多いのではないでしょうか。

BIやSCPが業務ツール止まりになる現象

また、プロジェクト開始時には、データドリブン経営を支える基盤として採用されたシステム群も、本来の目的は達成できておらず、単なる業務処理ツールになってしまっているケースが多いように見受けます。

ツール	本来の役割	実態
BI	意思決定支援	帳票置換・レポートツール
SCP	需給最適化・判断支援	自動化ツール
ERP	経営基盤・意思決定基盤	業務処理システム

このギャップにより、「データはあるが意思決定は変わらない」という状態が固定化されます。

---

データドリブン経営が進まない組織構造の問題

そして、この問題はシステムの問題ではなく、プロジェクトの構造そのものに起因すると考えています。

IT部門主導による“システム導入最適化”

多くのERPプロジェクトではIT部門が主導し、業務部門は要件提示やレビューに回る構造になっています。

その結果、プロジェクトのゴールが「システムを正しく導入すること」に収束し、「意思決定をどう変えるか」という本質が後回しになります。

H3 業務部門の“お客様化”問題

本来、システム導入は、業務を改善・改革するためのものです。そのため、構想・要件定義の中心は業務部門であるべきです。

しかし、実際には、業務部門が受け身になり、要件定義フェーズでも、現行業務を説明するに留まり、現行業務の延長線上で要件が整理されるケースが多く見られます。

その結果として：

• 変革ではなく改善にとどまる
• 現状踏襲型の要件になる
• 意思決定構造が変わらない

という状態が生まれます。

チェンジマネジメントの役割が矮小化される問題

チェンジマネジメントチームは多くのプロジェクトで設置されますが、実態は以下にとどまることが多いです。多くの場合、トレーニングチームとの差がほとんどない、もしくは同一の位置付けになっているのではないでしょうか。

• システム導入に留まる業務変更点の説明
• 新システム導入に伴う初期混乱への心の準備支援
• マニュアル展開・トレーニング実施

しかし本来は、以下を担うべきです。

• 意思決定の変化設計
• 行動変容の設計と定着
• KPIの使われ方そのものの変革

つまり、単なる教育機能ではなく、業務変革の実行主体であるべきです。だから、チェンジ「マネジメント」なのです。

---

カットオーバー後に起きるギャップの本質

カットオーバー後の典型的な問題は、非常にシンプルです。

新システムは動いているが、意思決定は変わっていない

システムは稼働するが意思決定は変わらない

システムを導入しても、意思決定のあり方を変更していなければ、ERPやSCPは予定通り稼働していても、意思決定は従来と同じ構造のままです。

• 判断は経験と勘に依存
• データは補助情報として扱われる
• 意思決定速度は変わらない

良いシステムを導入したら、勝手に企業の意思決定プロセスが変わるということは、ありません。

データは存在するが活用方法が定着しない

データ自体は整備されているものの、「どう使うか」が現場に定着していません。

その結果：

• 活用が属人化する
• 部門ごとに使い方が異なる
• 再現性が生まれない

プロジェクト終了と同時に改善活動が止まる

プロジェクト終了とともに推進組織が消失し、改善活動が継続されなくなるケースは非常に多く見られます。

物事を改革するのは、大変な労力と気力が必要です。そのため、関係各所から優秀なメンバを招へいし、推進力のあるリーダを据えて、プロジェクトを行います。結果、プロジェクトが終了すると、その推進力も無くなってしまうことは避けられません。

---

本来プロジェクト期間中に行うべきこと

本来のERPプロジェクトはシステム導入ではなく、業務プロセスと意思決定の設計プロジェクトです。

KPI・意思決定設計（シミュレーション起点）

KPI設計において重要なのは網羅性ではありません。むしろ網羅的に作り込むことで、実務で使われない巨大な構造物になるリスクがあります。

重要なのは以下です：

• 誰の目にも理解できるよう、シンプルに作る
• 経営指標が、現場の行動指標につながるように設計する
• クイックウィン領域を設定して「そのKPIで意思決定がどう変わるか」を検証。実運用に近い形でシミュレーションする

KPIツリーは、作ること自体が目的ではなく、新しい意思決定プロセスを検証するための仮説モデルとして扱うべきです。

経営の判断基準は、時間の経過とともに変化していきます。現在の見通しで細かく作り込むよりも、シンプルなものに留めて柔軟性を維持しつつ、実際に意思決定にどう活かせるかに力を割くべきです。

会議体・運用設計（クイックウィンでの実運用トライアル）

会議体は設計書ではなく、実際の運用で磨き込むものです。しかし、データを元にした業務運営が社内に定着していない時期に、あるべき姿を全社的に定義するのは困難です。

そのため、クイックイン領域を決めて、トライアルを行うことが有効です。

クイックウィンの例：

• ERP＋SCPツールのデータを利用した、需給調整・在庫最適化
• ERPのデータを利用した、購買価格・発注の最適化
• ERPのデータを利用した、原価低減活動

これらは、ERP導入によって蓄積したデータで運営することが可能なため、比較的効果が得やすい領域になります。

これらを実際に回しながら、

• データを見ることで意思決定はどう変わるか
• 判断スピードは変わるか
• 行動が変化するか

を検証します。

システムテスト・UATは「意思決定リハーサル」

通常のテストは機能確認にとどまりがちですが、システム導入が、業務改革のためのものだと考えると、それだけでは足りません。

本当はテストすべきもの

• データを使って意思決定できるか
• 判断の質は向上するか
• 現場で行動に落ちるか

テスト工程自体を、意思決定のリハーサルとして活用することが重要です。

逆に、このようなリハーサルを行わないと、実際の運用に入ったときの問題を先んじて見つけ出し、つぶしこんでおくことができません。実運用が始まってしまうと、ビジネス影響も出てきてしまいますので、試行錯誤はできなくなります。そして、緊急避難策として従来の運用に戻して、そのままになってしまう事例も多いです。

ERP・SCP・BIを意思決定前提で設計する

設計の中心は画面や機能ではなく、意思決定です。

• 何を見るかではなく「何を決めるか」
• どの頻度で意思決定するか
• どの粒度の情報が必要か

この観点で設計することで、初めてシステムが意思決定基盤になります。

しかし、新しいシステムの操作に終始した議論しかなされていないプロジェクトは少なくありません。

Fit to Standardという考え方が浸透し、追加開発を抑える思想が広まったことは大変良いことなのですが、一方で、新システムを利用して、どのように業務を改革していくのかという観点は疎かになっているように見受けられます。

---

クイックウィンと定着化（カットオーバー後）

カットオーバー後は段階的に「意思決定変革」を広げていきます。

1～2年：クイックウィン

まずは意思決定が明確に変わる領域から着手します。例えば、前述した、以下のような活動です。

• ERP＋SCPツールのデータを利用した、需給調整・在庫最適化
• ERPのデータを利用した、購買価格・発注の最適化
• ERPのデータを利用した、原価低減活動

目的は、効果の刈り取りだけではなく、

意思決定が変わる成功体験

を作ることです。それが、社内に「データドリブン経営は可能だ」という機運を作りだします。

3年目以降：定着化と文化変革

そして、クイックウィンの短期成功を基盤に、組織全体へ展開します。

• CoE設置
• データ人材育成
• 人事評価へ反映
• データのない稟議の廃止

カットオーバー前に計画を立てておくことの重要性

そして、この計画を、カットオーバー前に立てておくことが重要です。

システム導入プロジェクトは、本当にタフな仕事です。そのため、カットオーバーしてしまうと、そこで力尽きてしまうことも珍しくはありません。

そこで、その前に、きちんと計画を立てつけておくことが欠かせません。本来的には、構想フェーズでドラフトをし、UAT期間中に最終化することが望ましいと考えます。

---

ERP導入の本質はシステム構築ではなく、意思決定構造の変革です。つまり、ERPの導入完了は、スタートであり、ゴールではありません。しかし、ERP導入プロジェクトの難易度の高さから、手段が目的化し、ERPを入れ切ることだけで終わってしまっているプロジェクトが、かなり多くあります。

そういったプロジェクトの改善に役立てばと思い、本記事を書かせて頂きました。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

---