WRITING

中堅建設業のERP選定はなぜつまずくのか——「身の丈経営」の設計思想

「原価管理システムを入れたはずなのに、かえって現場が混乱している」。中堅ゼネコンや専門工事業の担当者と話していると、この種の声を耳にすることが少なくない。問題の本質は、多くの場合ツールの良し悪しではなく、選定と導入の設計そのものにある。

中堅建設業がSAPを断念するのは予算の問題ではない——設計思想の不一致が本当の理由だ

基幹システムの刷新を検討するとき、真っ先に名前が挙がるのはSAPのような大規模ERPだろう。しかし多くの中堅企業は、検討の初期段階でこの選択肢を外す。表向きの理由は「予算が合わない」だが、本質はそこではない。

汎用ERPは業種を問わない設計を前提にしている。建設業特有の「明細を一式でまとめて管理する慣習」や、実行予算を工種ごとに多階層で追いかける仕組みは、標準機能の外側にある。これを合わせ込むにはアドオン開発が必要になり、コストはさらに膨らむ。結果として、中堅・中小の受け皿になっているのが、建設業に特化した中価格帯のパッケージ製品群だ。

汎用ERPが中堅建設業に合わない構造
汎用設計ゆえに業界固有機能がない一式管理・工種別多階層予算が標準外
差を埋めるアドオン開発が必要カスタマイズ費用が本体費用を上回るケースも
投資対効果が成り立たなくなる
⚠ 選定の分かれ目

問題は予算の大小ではなく、標準機能と建設業務の設計思想の不一致にある。アドオンで埋めようとするほどコストと保守負担が増える。

見分け方 「御社の業務に合わせてカスタマイズします」という提案が複数回出てきたら、製品の標準機能と自社業務の乖離が大きいサインだ。

目安 アドオン費用が本体ライセンス費用の50%を超え始めたら、建設業特化パッケージへの切り替えを検討するタイミングだ。

「身の丈に合った製品」を選んでも、導入設計を後回しにすれば4つの失敗を踏む

ここで見落とされがちなのが、製品の選び方と導入の進め方は別問題だということだ。価格や機能一覧が自社の規模に合っていても、導入プロセスの設計が伴わなければ、現場は簡単に混乱する。

中堅建設業でERP導入がつまずく典型パターンは4つある。いずれも「製品の問題」ではなく「導入設計の問題」が起点だ。

失敗 1

現行業務をそのまま再現しようとする

要件定義が「今の業務をどう再現するか」に向き、標準機能をほとんど活かせないまま独自ルールが乱立する

失敗 2

旧運用ルールを全部持ち込む

現場ごとの独自入力ルールをパッケージに移植すると、データの整合性が保てなくなる

失敗 3

教育・定着支援を省略する

稼働開始と同時に現場任せになり、入力ミスや二重管理が常態化する

失敗 4

ベンダーに丸投げする

情シスが小規模な中堅企業ではやむを得ない面もあるが、社内のオーナーシップが育たず、稼働後の改善ができなくなる

分かれ目 要件定義の段階で「今の業務をどう変えるか」を問えているかどうかが分水嶺だ。「再現」から「改善」に問いを変えるだけで、導入後の混乱量が大きく変わる。

注意 情シスが1〜2名の企業では、稼働前から「誰がシステムの運用オーナーになるか」を決めておく必要がある。オーナーが不在のまま稼働すると、問い合わせがベンダー頼みになり続ける。

本当に問うべきは「機能の多さ」ではなく「自社業務との適合率」だ

ERP選定の場では、機能一覧や価格表を横に並べて比較する作業に時間がかかりがちだ。しかし本来問われるべきは、自社の工事管理フローとパッケージの標準機能がどこまで噛み合うかだ。合わない部分をカスタマイズで埋めるのか、それとも自社の業務フロー自体を見直すのか。この判断を導入前にどれだけ具体的に詰められるかが、稼働後の混乱の量を左右する。

ERP選定で本当に比較すべきこと

よくある比較軸

機能の多さ・価格

  • 機能一覧のチェックリスト数
  • 初期費用・月額コストの比較
  • 導入実績・シェアの大きさ

本来の比較軸

自社業務との適合率

  • 工事管理フローと標準機能の一致度
  • 標準機能でカバーできない業務の量
  • 稼働後サポート・教育プログラムの充実度

あわせて重視したいのが、導入後のサポート体制と教育プログラムの有無だ。パッケージを「入れて終わり」にする組織と、稼働後も定着支援を受けながら運用を磨き続ける組織とでは、同じ製品を使っていても数年後の活用度に大きな差が生まれる。

選び方 デモの際は「御社が最もよく使う機能を標準でどう動かすか見せてください」と頼むのが有効だ。カスタマイズの話が先に出てくる製品は、自社業務との乖離が大きい可能性がある。

よくある誤解 「導入実績が多い製品を選べば安全」とは限らない。建設業内でも専門工事業・ゼネコン・設備業では業務フローが大きく違う。自社の工事規模・工種・管理方式に近い事例があるかが重要だ。

今のデータ設計が5年後のAI活用を決める——ERPは業務効率化ではなくデータ資産の設計だ

選定段階で見落とされやすい視点がある。ERPに日々蓄積される見積・原価・工事管理のデータは、将来的にAI活用の土台になる資産だということだ。類推見積、原価予測、工程の異常検知といった応用は、いずれもこの基幹データの質に依存する。

ERPデータがAI活用の土台になるまでの4段階
1基幹データの蓄積見積・原価・工事管理が統一ルールで入力されている
2データの整合性確保工事コード・工種・版管理が揃っている⚠ ⚠ この段階が抜けると後からAIを載せても効果が出ない
3横断分析が可能な構造原価・工程・安全を共通キーで結合できる
4AI活用(類推見積・原価予測・異常検知)データ基盤が整って初めてAIが実務で機能する

入力ルールが曖昧なまま、あるいはデータ構造がバラバラなまま運用してきたシステムは、後からAIを載せようとしても効果が出にくい。ERPの選定・導入は、単なる業務効率化の話ではなく、5年後にどこまでデータを資産として活用できるかを決める意思決定でもある。

配分 「機能を早く動かすこと」より「データの入力ルールを最初から統一すること」に労力をかけるべきだ。後から整合性を取り直す作業は、最初に設計する労力の3〜5倍かかる。

目安 ERP稼働から2年後に「工事コード・工種・原価の3つが共通キーで検索できる状態か」を確認する。この状態が整っていれば、AIを載せる基盤として機能する。


中堅建設業の現場で起きている混乱は、「安いシステムを選んだから」ではない。自社の規模に見合った選択をしたうえで、導入プロセスの設計を後回しにしてしまったことが原因であるケースが多い。要件定義を丁寧に行うこと、業務フローを見直す覚悟を持つこと、そして将来のAI活用を見据えたデータ設計を最初から意識すること。この3点が、中堅建設業がDXで足をすくわれないための、地味だが確実な備えになる。

← 記事一覧に戻る