「経営判断に使えるレポートを出してほしい」と現場に依頼したのに、上がってきたExcelの集計表は先月とフォーマットが違い、数字の定義も曖昧。結果として意思決定には使えず、また別の資料を作り直す――。
この問題の本質は、システムの性能不足ではありません。「何を測るべきか」が組織内で定まっていないことにあります。ERP導入を検討する企業の多くが、この設計を後回しにしたまま製品選定を進め、「システムは入ったが、経営に活かせない」という事態に陥っています。
本記事では、管理会計が機能しない構造的な原因を整理した上で、ERP導入前に整えるべきKPIとデータ設計の考え方を、RICE CLOUDの支援実績をもとに解説します。
結論サマリー
管理会計が現場で使われない理由は、以下の3点に集約されます。
・測るべき指標（KPI）が経営と現場で一致しない
・データの粒度・定義・更新頻度が設計されていない
・ERP導入後に「データを出せる状態」にすることを目的化してしまい、意思決定への接続が欠けている
ERP導入を成功させるには、製品選定よりも先に「誰が・何を・どう判断するために・どんなデータが必要か」を言語化し、全社で合意しておくことが不可欠です。
1. 管理会計が現場で使われない3つの構造的理由
管理会計が機能していない企業には、共通する構造的な問題があります。RICE CLOUDがこれまで手がけてきたプロジェクトリカバリー案件から見えてきた、3つの本質的な原因を解説します。
管理会計とは、経営判断や事業運営のために社内向けに作成される会計情報です。財務会計とは異なり法的な制約を受けないため、設計の自由度が高い反面、「誰のために・何のために測るのか」が曖昧なまま運用され、誰も見ないレポートが量産されるケースが後を絶ちません。
1-1. 測るべき指標（KPI）が経営と現場で一致していない
経営層は「事業別の営業利益率」を知りたいと考えているのに、現場では「受注件数」や「商談数」といった活動指標しか集計していない——このような指標のズレは、多くの企業で見過ごされています。
ある製造業の事例では、経営会議で求められていたのは「製品ラインごとの限界利益」でした。しかし現場の基幹システムでは「部門別の売上」しか集計できず、毎月手作業でExcelを使った按分計算が発生していました。精度も信頼性も低い状態が続いた結果、経営判断のスピードが大幅に低下していたのです。
KPIの不一致は、単なる認識のズレではありません。「何をもって事業の成否を判断するか」という経営哲学の欠如を示しています。ERP導入前に、経営層・事業部門・管理部門が同じテーブルで「測るべきもの」を定義するプロセスを省略してはなりません。
1-2. データの粒度・定義・更新頻度が設計されていない
「売上」という言葉ひとつをとっても、受注ベースなのか入金ベースなのか、返品やキャンセルをどう扱うのかは企業によって異なります。この定義があいまいなまま基幹システムに入力が進むと、後から「正しいデータ」を取り出すことは極めて困難になります。
RICE CLOUDが支援したあるケースでは、システム刷新後に「月次の売上推移」をレポート化しようとした際、過去データに複数の売上計上ルールが混在していることが判明しました。データクレンジングに3か月を要し、プロジェクト全体の遅延を招く結果となりました。
データ設計とは、単に項目名を決めることではありません。「誰が・いつ・どのタイミングで・どの粒度で入力するか」「更新頻度はリアルタイムか日次か月次か」「マスタの管理責任者は誰か」——運用ルールまで含めて設計することが求められます。
1-3. ERP導入後に「データを出せる状態」を目的化してしまう
「とにかくERPを入れれば、データは自動で整理されるはず」という期待は、現場で必ず裏切られます。ERPはあくまでデータを格納・処理する箱であり、何をどう測るかは人間が設計しなければなりません。
ある建設業では、ERP導入後に「工事別の原価管理」を実現しようとしましたが、工事コードの体系が現場の実態と合っておらず、入力が形骸化しました。結果として従来通りExcelでの管理が続き、ERPは「請求書を出すためだけのシステム」になってしまったのです。
“意思決定を支援できる状態を作ること”——これがERP導入プロジェクトの真のゴールです。RICE CLOUDでは、アジャイル手法を活用し、導入初期段階で「現場が本当に使うKPI」を特定します。それに必要最小限のデータ設計を優先することで、無駄な機能実装や入力負荷を回避しています。
2. ERP導入前に整えるべきKPIとデータ設計の5ステップ
管理会計を機能させるためには、ERP製品を選ぶ前に「測る仕組み」を設計する必要があります。以下の5ステップは、RICE CLOUDが実際のプロジェクトで実践している設計プロセスです。
2-1. 経営判断のシーンを具体的に洗い出す
まず行うべきは、「誰が・どんな場面で・何を判断するか」を具体的に列挙することです。たとえば、以下のような問いを経営層・事業責任者に投げかけます。
・新規事業への投資判断をする際、どんな数字があれば意思決定できるか
・月次の事業会議で、どの数字が改善していれば「順調」と判断できるか
・四半期ごとの見通しを立てる際、どの指標をもとに予測を修正するか
これらの問いに対する回答が曖昧であれば、そもそも管理会計の要件が定まっていない証拠です。RICE CLOUDでは、導入支援の初期段階でこの「判断シーンの可視化」をワークショップ形式で行い、全社で合意形成を図ります。
よく見るのは、経営層が「データドリブンな経営」を掲げながら、具体的な判断シーンを言語化できていないケースです。このギャップを埋めない限り、どれだけ高機能なERPを導入しても管理会計は機能しません。
2-2. KPIツリーを作成し、測定可能な指標に分解する
経営目標（例：営業利益率15%）を達成するために、どの要素を改善すべきかを階層的に整理します。これを「KPIツリー」と呼びます。
営業利益率を向上させるには、売上を増やすかコストを下げるか。売上を増やすには、客単価を上げるか受注件数を増やすか。受注件数を増やすには、商談数を増やすか成約率を上げるか——このように分解していくことで、現場が日々測定・改善できる指標に落とし込まれます。
ある流通業の事例では、経営層が求めていた「店舗別の収益性」をKPIツリーで分解した結果、「来店客数」「客単価」「商品別粗利率」「人件費率」の4指標を日次で可視化する設計に至りました。ERP導入後、これらの指標がリアルタイムでダッシュボードに表示されるようになり、店長が自律的に改善アクションを取れる環境が整いました。
2-3. データの粒度と更新頻度を決める
KPIが定まったら、次に「どの粒度でデータを持つべきか」を設計します。売上データを「月次・事業部単位」で集計するのか、「日次・商品単位」で持つのかによって、システムの設計も入力負荷も大きく変わります。
RICE CLOUDが支援したあるケースでは、経営層が求めていたのは「週次での事業進捗」でしたが、現場では月次でしかデータを締められない運用になっていました。ERP導入を機に、売上データの入力を「受注確定時点」にルール変更し、週次での集計を可能にしました。
重要なのは、「理想のデータ粒度」ではなく「現実的に運用可能な粒度」を選ぶことです。過度に細かいデータ設計は入力負荷を増やし、結果として運用が破綻します。
2-4. マスタ設計とコード体系を統一する
管理会計が機能するかどうかは、マスタデータの設計で決まると言っても過言ではありません。顧客マスタ、商品マスタ、部門マスタ、プロジェクトマスタなど、各マスタのコード体系が統一されていなければ、集計も分析もできません。
ある製造業では、工場ごとに異なる製品コードが使われており、全社での原価集計が不可能でした。ERP導入を機に製品マスタを全社統一し、旧コードとの紐付けテーブルを設計することで、過去データとの連続性を保ちながら新体系への移行を実現しました。
マスタ設計は地味な作業ですが、ここで妥協すると後から取り返しがつきません。RICE CLOUDでは、マスタ設計フェーズに十分な時間を確保し、現場へのヒアリングを重ねることで、運用に即したコード体系を構築しています。
2-5. プロトタイプでレポートを先に作る
KPIとデータ設計が固まったら、ERP本格導入前に「レポートのプロトタイプ」を作成します。これにより、「このデータがあれば本当に意思決定できるか」を関係者が事前に確認できます。
RICE CLOUDのアジャイル導入手法では、初期フェーズで簡易的なダッシュボードを構築し、経営層・現場責任者に実際に触ってもらいます。その反応をもとにKPIの見直しやデータ粒度の調整を行い、本番環境に反映します。
このプロセスを経ることで、「導入後に使われないレポート」を作るリスクを大幅に削減できます。現場でよく聞くのは「稼働後に初めてレポートを見て、こんなはずじゃなかったと気づく」というケースです。プロトタイプによる事前検証は、こうした失敗を防ぐ最も有効な手段といえます。
3. 基幹システム刷新で管理会計を機能させるために必要な視点
基幹システム刷新は、単なるITプロジェクトではありません。「会社の意思決定の仕組みを再設計するプロジェクト」として捉えるべきです。
3-1. 経営層のコミットメントを最初に確保する
管理会計の設計には、経営層の意思決定が不可欠です。「何を測るか」は経営戦略そのものであり、現場任せにしてはなりません。
RICE CLOUDが支援したあるケースでは、プロジェクト開始時に経営層向けのキックオフ会議を設け、「このプロジェクトで実現したい経営判断」を明文化しました。その結果、途中で仕様変更が発生した際も、経営層の合意があるため現場の抵抗を最小限に抑えられました。
経営層がプロジェクトにコミットしているかどうかは、プロジェクトの初期段階で明確にすべきです。予算承認だけで終わらせず、要件定義の場に経営層自身が参加することが理想的です。
3-2. 現場の入力負荷を最小化する設計思想を持つ
データ設計が理想的でも、現場が入力できなければ意味がありません。入力項目はできる限り絞り込み、既存の業務フローに自然に組み込める形にすることが重要です。
RICE CLOUDでは、入力画面の設計段階で現場担当者に実際に操作してもらい、「この項目は本当に必要か」「この入力タイミングは現実的か」をフィードバックしてもらいます。その結果、当初計画の3割の項目を削減できたケースもあります。
現場から「入力が面倒」という声が上がった時点で、管理会計は形骸化します。設計段階から現場の声を反映させることが、運用継続の鍵となります。
3-3. 段階的な導入で「小さな成功」を積み重ねる
ERP導入を一度に全社展開すると、トラブル発生時のリカバリーが困難になります。RICE CLOUDが推奨するのは、特定の部門や事業所で先行導入し、そこで得た学びを全社展開に活かすアプローチです。
ある企業では、本社部門で先行して管理会計レポートを稼働させ、経営層が「使える」と実感した後に全国の拠点に展開しました。この段階的なアプローチにより、現場の納得感と導入スピードの両立が実現しました。
大規模な変革ほど、小さな成功体験の積み重ねが重要です。段階的導入は時間がかかるように見えますが、結果的にプロジェクト全体のリスクを下げ、成功確率を高めます。
RICE CLOUDならではの視点：プロジェクトリカバリーから見えた失敗パターン
RICE CLOUDは、他社で失敗したERP導入プロジェクトの立て直し（プロジェクトリカバリー）を数多く手がけてきました。その経験から見えてきたのは、「管理会計の設計を後回しにしたプロジェクトは、ほぼ確実に失敗する」という事実です。
あるプロジェクトでは、ERP製品の選定とカスタマイズに大半の予算と時間を費やし、「どんなレポートを出すか」は導入直前まで決まっていませんでした。結果としてシステムは稼働したものの、経営層が求めるデータは一切出力できず、追加開発に多額のコストが発生しました。
こうした失敗を防ぐため、RICE CLOUDではプロジェクトの最初の1か月を「KPI設計とデータ要件定義」に充てます。この期間で関係者の認識を揃え、ゴールを明確にすることで、後続フェーズの手戻りを最小化しています。
また、Microsoft AI Cloud Partner Programに参加する企業として、Dynamics 365やPower BIを活用した柔軟なレポート設計にも対応しています。既存のExcel文化を無理に否定せず、Power BIで「Excel感覚で使えるダッシュボード」を構築することで、現場の抵抗感を和らげる工夫も行っています。
実際にあったケースでは、現場が長年使い慣れたExcelのピボットテーブル形式をPower BIで再現しました。操作感を維持しながらリアルタイム性と精度を向上させたことで、現場からの受け入れがスムーズに進みました。
ERP導入・業務改善のご相談はお気軽に
まとめ
管理会計が現場で使われない理由は、「測るべきもの」が定まっていないこと、そしてERP導入を「システムを入れること」として捉えてしまうことにあります。基幹システム刷新を成功させるには、製品選定よりも先にKPIとデータ設計を整え、全社で合意しておくことが不可欠です。
ERP導入前に実行すべき5ステップを再掲します。
・経営判断のシーンを具体的に洗い出す
・KPIツリーを作成し、測定可能な指標に分解する
・データの粒度と更新頻度を決める
・マスタ設計とコード体系を統一する
・プロトタイプでレポートを先に作る
RICE CLOUDは、SaaS（ERP）導入のプロフェッショナル集団として、アジャイル手法による低コスト・短納期の導入支援を行っています。管理会計の設計からERP選定、導入後の運用改善まで、一気通貫でサポートいたします。ERP導入・業務改善についてお悩みがあれば、お気軽にご相談ください。
