執筆者：堤 史明（Ascend株式会社 代表取締役）
基幹システムの老朽化や、SAP ERP 6.0の標準保守が2027年末に終了することを背景に、ERPの導入や基幹システムの刷新を行う企業が多いことは既に知られています。矢野経済研究所の調査では、国内のERPパッケージライセンス市場は2027年に約2,240億円まで拡大する見通しです。その一方で、新システムへの移行直後に出荷が止まる、投資額が当初計画の1.5倍以上に膨らむといったつまずきは、大手企業でも相次いでいます。
私はこれまで、外資系コンサルティングファームでの経験を含め、製薬会社のグローバルERP導入やガス会社のSAP刷新プロジェクトなどで、発注企業側に立ってプロジェクトを支援してきました。
その経験から言えるのは、ERP導入の失敗の多くは、システムそのものの問題ではなく、発注側の体制や判断の仕組みから生まれているということです。本記事では、失敗のパターンをプロジェクトの段階ごとに整理したうえで、その背景にある4つの構造と、発注側が今から取れる備えをお伝えします。
【ダウンロード資料】ERP刷新ガイド 2027 失敗の構造と成功への処方箋
ERP導入・基幹システム・業務システムの「失敗」とは何か
本題に入る前に、言葉の範囲を整理しておきます。ここでの基幹システムとは、販売・購買・在庫・生産・会計など、企業活動の中核となる業務を支えるシステムの総称を指しています。ERPは、それらの業務データを一つのデータベースで統合して管理するパッケージ製品を指し、業務システムは経費精算や勤怠管理のような周辺業務まで含めた、より広い呼び方として使われています
SCSKが年商500億円以上の企業を対象に行った調査では、ERPだけで基幹業務をまかなっている企業は54%にとどまり、残りは業務システムやスクラッチ開発のシステムと組み合わせて運用していました。実際のERP導入は周辺の業務システムとの連携まで含めた取り組みになるため、本記事ではこれらをまとめて扱います。
稼働しない失敗と、稼働しても効果が出ない失敗の違い
ひと口に「失敗」と言っても、その姿は一つではありません。私は大きく3つに分けて考えています。1つ目は、稼働延期を繰り返して予算を使い切り、プロジェクトが途中で凍結される失敗です。2つ目は、稼働はしたものの直後に出荷停止のような重大な障害が起き、事業に直接の影響が出る失敗です。そして3つ目が、稼働して大きなトラブルもないものの、想定以上の時間と費用がかかり、当初描いていた業務の姿にはたどり着けなかったという失敗です。
報道されるのは1つ目と2つ目ですが、多くの企業が抱えているのは3つ目のほうです。ガートナーの調査では、ERPパッケージの導入・刷新プロジェクトの70%以上が当初のビジネス目標を達成できていないとされています。
システムが動いている以上、社内では「プロジェクトは完了した」と扱われやすく、効果が出ていないことが問題として認識されにくい。この見えにくさが、3つ目の失敗を見過ごされやすいものにしています。
大規模案件は工期遅延48%・予算超過42%という調査結果
ERP導入が計画どおりに進みにくいことは、データにも表れています。日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2026」によると、500人月以上の大規模プロジェクトでは、工期が予定より遅れた割合が47.8%、予算が予定を超えた割合が42.2%にのぼります。10人月未満の小規模プロジェクトではいずれも10%未満であり、規模が大きくなるほど計画を守ることが難しくなる傾向がはっきりと出ています。
製造業に絞った調査でも、同じ傾向が見られます。京セラコミュニケーションシステムが、生産管理システム（ERPを含む）の選定・導入に関わった製造業の情報システム担当者355名に聞いた調査では、導入時に生じた問題として「当初の予算からのコスト増」が32.4%で最も多く、「システム要件・仕様の変更」（30.4%）、「導入スケジュールの遅延」（29.3%）、「データ移行における整合性や正確性の問題」（25.4%）が続きました。予算の超過や遅延は一部の企業だけに起きる例外ではなく、基幹システムの刷新に伴う典型的なリスクとして、あらかじめ備えておくべきものだと言えます。
公表事例に見る基幹システム刷新の失敗とその共通点
大手企業の公表事例を見ると、基幹システム刷新の失敗が事業にどれほど大きな影響を与えるかがよくわかります。江崎グリコは2024年4月、調達・生産・物流・会計を統合する基幹システムをSAP S/4HANAへ移行した直後に障害が発生し、主力のチルド食品のほぼ全品が出荷停止となりました。一度は出荷を再開したものの、在庫データの不整合やシステムエラーが続いて再び停止し、完全復旧は同年8月にずれ込んでいます。障害による売上の減少は約200億円、投資額も当初の215億円から342億円へと約1.6倍に膨らみました。
同じ2024年には、ユニ・チャームもゴールデンウィーク中にSAP S/4HANAへの基幹システム更新を行い、新システムと物流システムの間のデータ連携に不具合が生じました。連休明けに集中した注文の処理が追いつかず、紙おむつなどの出荷が全国的に遅れ、自治体向けの紙おむつ給付事業や直営のECサイトにも影響が及んでいます。
外から見える情報だけで原因を断定することはできませんが、2つの事例からは共通点が読み取れます。どちらも経営資源の豊富な大手企業が、世界で広く使われている製品へ移行した案件であり、問題が表面化したのはデータの整合性や周辺システムとの連携といった、移行と稼働の局面でした。
製品の選定や企業の規模だけでは失敗を防げず、どこまで検証してから本番に切り替えるのか、周辺システムを含めた全体を誰が見渡すのかという、プロジェクトの進め方と判断の仕組みが結果を左右したと私は考えています。
※各事例の詳しい経緯は、グリコの基幹システム障害の解説記事とユニ・チャームの基幹システム障害の解説記事でまとめています。生産現場に影響が出た事例として、安川電機の基幹システムトラブルの記事もあわせてご覧ください。
フェーズ別に見るERP導入の失敗パターンと早期の兆候
ERP導入の失敗は、稼働日に突然起きるわけではありません。多くの場合、その原因は構想や設計の段階で生まれ、プロジェクトの進行とともに少しずつ大きくなっていきます。ここでは失敗のパターンをプロジェクトの段階ごとに整理し、それぞれの段階で発注側が気づける兆候をあわせて紹介します。兆候に早く気づくほど、手戻りにかかる費用は小さく抑えられます。
構想・選定段階：目的が曖昧なまま製品比較から始める
構想段階で多いのは、「業務を効率化するためにERPを入れる」といった漠然とした目的のまま検討が始まり、経営層から業務改革の意思が示されないケースです。目的が定まらないまま製品の比較に進むと、機能の多さや価格で選ぶことになり、業界特有の取引慣行や取引先とのデータ連携に合わない製品を選んでしまうことがあります。また、SIベンダーの営業段階の見積もりをそのまま前提に予算を組み、最終的に費用が当初見積もりの3〜5倍に膨らむケースも見られます。
この段階の兆候は、比較的わかりやすいものです。導入目的を問われたときに「老朽化への対応」や「保守期限への対応」しか出てこない、成果の目標が数字で示されていない、製品デモを見ることが検討の中心になっている。こうした状態であれば、製品選びの前に「何を変えるためにERPを入れるのか」を経営層と詰め直す必要があります。
要件定義・設計段階：現行踏襲の要望でアドオンが膨らむ
設計段階の典型は、標準機能を前提に契約したにもかかわらず、現行の業務プロセスを再現するためのカスタマイズが次々に追加されるパターンです。いわゆるアドオンが増えるほど開発費と保守費が膨らみ、クラウドERPであれば年に数回行われるバージョンアップに追随できなくなるおそれもあります。もう一つ見落とされやすいのがデータの棚卸しです。旧システムに残る重複した取引先や、廃止済みの品目・勘定科目を整理しないまま新システムへ持ち込むと、稼働後にデータの不整合として表面化します。
兆候としては、要件定義の会議でアドオンの件数が回を追うごとに増えている、「今と同じようにできるか」という確認が議論の中心になっている、データクレンジングの担当者や期限が決まっていない、といった点に注意してください。アドオンの一覧と、それぞれを採用した理由を発注側が自分の言葉で説明できるかどうかが、一つの目安になります。
移行・稼働段階：検証不足のまま本番を迎え混乱が続く
移行と稼働の段階では、スケジュールを優先して並行稼働の期間を設けず、ある日を境に新システムへ一斉に切り替えた結果、初期トラブルで業務が止まるパターンが代表的です。業務部門がテストやレビューに十分に参加できず、情報システム部門とSIベンダーだけで仕上げたシステムが現場の実務とずれているという問題も、この段階で表に出てきます。
プロトスターの調査でも、ERP導入・運用で直面した課題の上位に「導入期間が長引いた」（25.7%）、「データ移行が大変だった」（20.0%）、「既存業務とのフィットが不十分だった」（17.1%）が挙がっています。
稼働後に注意したいのは、運用体制の空白です。改修要望の窓口や判断の責任者が決まっていないと業務部門の要望が滞り、ERPの外でExcel管理や二重入力が再び広がっていきます。移行リハーサルの回数が日程の都合で削られている、本番切り替えの判断基準が文書になっていない、稼働後の運用責任者が決まっていない。このどれかに当てはまる場合は、稼働日を守ることよりも、検証と体制を整えることを優先すべき局面です。
ERP導入の失敗を生む4つの構造的な原因を読み解く
前の章で挙げた失敗パターンは、担当者の注意不足や個別の判断ミスとして片付けられがちです。しかし複数の企業で同じパターンが繰り返されているのは、その背後に、どの会社でも起こりうる共通の構造があるからです。私は、発注側の企業に潜む構造を次の4つに整理しています。
ベンダーへの丸投げが生む発注側との情報の非対称性
ERPの導入や刷新を外部のSIベンダーに依頼すること自体は、専門性の高い領域である以上、合理的な選択です。問題は、要件の整理から設計、進行管理までを一括して委ね、契約を境に「あとは専門家に任せておけばよい」という意識に切り替わってしまうことにあります。DX推進や情報システムの担当者は他部署と兼任していることが多く、現行システムの仕様や業務フローの背景まで深く理解できていないため、本来は自社で行うべき現行システムの棚卸しまでベンダーに依頼する形になりがちです。
その結果、自社の業務を最も深く理解しているのが外部のベンダーである、という逆転が起きます。ベンダーはヒアリングを通じて業務を仕様書として整理・蓄積していく一方、発注側にはその情報が体系立てて残りません。この情報の非対称性があると、標準機能で対応できる要件にアドオン開発が提案されたり、スケジュールやコスト超過のリスクが十分に説明されなかったりする余地が生まれます。
これはベンダーの倫理の問題というより、提案の妥当性を確かめる機能が発注側に存在しないという構造の問題です。丸投げの結果として起きるのは、要件定義の終盤になって想定外に高額な見積もりが出てくる「高額化」、旧来の業務フローがそのまま新システムに引き継がれる「現行踏襲」、言われたとおりに作ったのに現場では使いづらい「期待外れ」の3つです。詳しくはERP導入・刷新が「丸投げ」で失敗する理由で解説しています。
標準化かカスタマイズか、社内に判断軸が育っていない
ERP導入の進め方には、自社の業務要件を起点に、標準機能で足りない部分をアドオンで補う「Fit & Gap」と、パッケージの標準機能を前提に業務のほうを合わせていく「Fit to Standard」があります。近年はコストと導入期間を抑えられる後者が主流になりつつありますが、ここで社内の立場の違いが表面化します。
情報システム部門や経営層は、開発費や導入期間を抑えられることから標準化を志向します。一方で現場は、長年慣れた業務の手順が変わることへの不安や、現場で積み上げてきたノウハウやローカルルールが失われることへの抵抗から、現行仕様の踏襲を求めやすくなります。
どちらの立場にも合理性があり、「標準化かカスタマイズか」の二者択一に正解はありません。必要なのは、業務ごとに判断する軸です。自社の競争力に直結するコア業務はこれまでのやり方を残し、他社でも共通して行われているノンコア業務は標準機能に寄せる。
このような切り分けの基準が社内で共有されていないと、要望ごとに個別の判断が積み重なり、声の大きい部署の要望ほど通りやすくなります。前の章で触れた「アドオンが回を追うごとに増える」という兆候は、多くの場合この判断軸の不在から生まれています。
経営層と現場で「ERP導入の目的」がそろっていない
現場が自らの業務課題を起点に検討を進め、その内容を経営に上げていく「ボトムアップ型」のERP導入は、現場の実態を反映でき、導入後の定着にもつながりやすい進め方です。ただし既存業務の踏襲に寄りやすく、部門ごとの要望が積み上がって全社最適の視点が後回しになりがちです。
その結果、アドオン開発が膨らみ、期間とコストの面で経営の合意が得られず、検討そのものが頓挫することがあります。反対に、経営が方針と判断軸を定めて現場に落とし込む「トップダウン型」は、全社最適の検討と迅速な意思決定に向いていますが、現場の納得感が得られにくいという弱点を持っています。
実際に多くの企業で見られるのは、そのどちらでもない状態です。経営層からは「DXを進めよ」という指示が出るものの、その起点は「競合が取り組んでいるから遅れるわけにはいかない」という発想にとどまり、標準化の判断軸や具体的な進め方までは示されません。
現場は判断軸を組み立てる材料を持たないまま指示を受け止めることになり、指示を出す側と受け取る側の間に大きな溝が生まれます。方針なき指示はトップダウンではなく、実質的には現場への丸投げです。現場発の検討を経営に通す方法については、ボトムアップ型ERP導入が頓挫する理由と経営への通し方をご覧ください。
兼任のDX推進担当者に意思決定と調整が集中している
DX推進部門の多くは、情報システム部門や経営企画部門から派生する形で生まれました。専任の体制が整わないまま、既存業務に「上乗せ」する形でDX推進やERP刷新を任されている担当者は少なくありません。
情報処理推進機構（IPA）の「DX動向2024」では、最も不足している人材類型として、企画から導入、効果検証までを一気通貫で推進する「ビジネスアーキテクト」を挙げた企業が41.9%にのぼりました。人材育成の課題としても「時間確保のための支援（現業のリソース調整など）」が43.5%と上位に挙がっており、担い手の不足と時間の不足が重なっていることがわかります。
ERP導入では、部門間の調整、ベンダーの成果物のレビュー、経営層への上申資料の作成といった業務が、こうした兼任の担当者に集中します。ベンダーの提案や見積もりを一つひとつ精査する時間が取れなければ、確認は形式的なものにとどまり、結果として一つ目の構造である丸投げに戻っていきます。4つの構造は独立しているわけではありません。
兼任で時間が足りないために精査が追いつかず、判断軸がないまま現行踏襲の要望が通り、アドオンが増えて経営の合意が得にくくなる。このように互いに連鎖しているからこそ、個別の対症療法ではなく、構造そのものに手を入れる必要があります。担当者が置かれた状況については、DX担当者が孤立する原因でも詳しく取り上げています。
失敗を防ぐために発注側が押さえておきたい3つの備え
ここまで見てきたように、ERP導入の失敗の多くは発注側の体制と判断の仕組みから生まれます。裏を返せば、発注側が備えを整えることで防げる失敗も少なくありません。ここでは、これから導入を始める企業にも、すでにプロジェクトが動いている企業にも共通する3つの備えを紹介します。
導入目的と「やらないこと」を経営層と先に合意する
最初の備えは、経営戦略と結びついた導入目的を定め、それを経営層の言葉として社内に発信してもらうことです。「ITコストの削減」や他社事例をなぞった目的では、現場の納得は得られません。たとえば「拠点ごとにばらばらな在庫管理をそろえ、全社の在庫を日次で把握できるようにする」のように、自社の課題に裏づけられた目的であることが大切です。
あわせて合意しておきたいのが、「やらないこと」です。どの業務を標準機能に合わせ、どの業務は自社のやり方を残すのか。ベンダーの見積もりが膨らんだときに備えた予算の余裕を、経営層が事前に承認しているか。業務部門に対して標準業務への適合を求めることに、経営として合意しているか。これらをプロジェクトの開始前に決めておけば、要件定義の場で一つひとつの要望を個別に判断する必要がなくなり、アドオンの増加にも歯止めがかかります。
発注側にPMO機能を置き、判断の主導権を自社で持つ
情報の非対称性を正し、ベンダーの提案や見積もりの妥当性を確かめる役割は、本来は発注企業自身が担うべきものです。しかし現実には2つの制約があります。一つは、仮に時間を確保できたとしても、「この見積もりは適正か」「この機能は本当に必要か」「このTo-Beは自社の実情に合っているか」を判断する視点は、ERP導入を複数経験しなければ身につきにくいこと。もう一つは、担当者の多くが兼任で、提案を一つひとつ精査する時間が取れないことです。
そのため、発注側の立場に立つPMO（プロジェクトマネジメントオフィス）を置き、必要に応じて外部の人材でその機能を補うことが現実的な選択肢になります。発注側に立つ外部人材は、同じ業界・同じ規模の他社がどこを標準化し、どこを作り込んだのかという知見を持ち込めるほか、特定部門の利害から離れた立場で、経営層と現場の間の調整役を担うこともできます。
ただし外部の支援を選ぶ際は、提案書に記載された体制と実際に参画するメンバーが一致しているかを確認しておく必要があります。社内体制と外部委託の切り分け方はERP導入担当者が知るべき、社内体制と外部委託の設計術、依頼先の見極め方はERP導入コンサルの選び方完全ガイドで詳しく解説しています。
進行中のプロジェクトでも間に合う立て直しの判断軸
すでにプロジェクトが進んでいる場合でも、打てる手はあります。大規模なERP導入では、グローバルなベンダーが元請けとして主導するケースが多く、ベンダーが作成したテスト仕様書や進捗報告を発注側がそのまま受け入れてしまいがちです。
そこで有効なのが、元請けベンダーと利害関係のない第三者が発注側に立って、プロジェクトの状態を点検する方法です。テストの業務シナリオが実態に即しているか、重要なケースが抜け落ちていないか、仕様が必要以上に複雑になっていないかを独立した視点で確かめ、ベンダーからの報告を経営層が判断できる形に整理します。
自社で現状を見極めるには、次の3点を確認してみてください。アドオンの一覧と、それぞれを採用した理由を自社の言葉で説明できるか。テストシナリオが月末の締めや繁忙期、例外的な取引といった実際の業務を網羅しているか。本番切り替えの判断基準が文書になっており、並行稼働の期間や延期した場合の影響まで含めて、経営層が判断できる状態になっているか。どれか一つでも答えに詰まるようであれば、稼働日の前に一度立ち止まって点検する価値があります。稼働前に見直す手間は、稼働後の障害対応や手戻りに比べればはるかに小さく済みます。
まとめ：失敗の構造を知ることがERP導入成功の第一歩
ERP導入や基幹システムの刷新がつまずく原因は、システムそのものよりも、ベンダーへの丸投げ、標準化の判断軸の不在、経営層と現場の目的のずれ、兼任担当者への負荷の集中という、発注側の構造にあることが多いものです。こうした構造は、構想・設計・移行の各段階で兆候として表れます。兆候に早く気づき、導入目的の合意、発注側のPMO機能、第三者の目による点検という備えを整えることで、失敗のリスクは大きく下げられます。
2027年末のSAP ERP 6.0の標準保守終了を控え、基幹システム刷新の検討はこれから本格化します。スケジュールに追われて判断を急ぐ前に、自社のプロジェクトにどの構造が潜んでいるかを一度点検してみてください。
【ダウンロード資料】ERP刷新ガイド 2027 失敗の構造と成功への処方箋
本記事で取り上げた4つの失敗構造を、市場データと各種調査結果をもとに全9章で詳しく解説した資料です。プロジェクトの点検に使える10項目のチェックリスト、ERP導入コンサルタントを見極める5つの視点、提案書と実際のアサイン体制のずれを防ぐ確認方法も収録しています。社内でERP刷新の必要性を説明する際の基礎資料としてもご活用ください。
ベンダーへの丸投げが起きる構造と、発注側に伴走パートナーが必要な理由に絞って知りたい方は、ERP導入・刷新の丸投げが、失敗を招く構造的な要因もあわせてご覧ください。