SAPプロジェクトが予算超過する理由と止める方法

SAPプロジェクトが予算を超過する主な理由は、企業が最初にコストを低く抑えようとし、その後、探索（Explore）フェーズでFit-to-Standardワークショップが実際のスコープを明らかにしたときに打撃を受けることです。私がレビューしたプログラムでは、40〜60%の予算超過は珍しくありません。

結論から言えば、SAPの予算が超過するのは、誰もスコープを把握していないうちに予算が決められたとき、そしてそのスコープをクライアントではなくベンダーが管理しているときです。探索フェーズ中のWRICEFの数を注視し、スコープを自社で持ち、10〜20%の予備費を自社の側で確保してください。

調査の平均値は、もっと穏やかに見えます。Panorama Consultingの2026年ERPレポートによると、ERP予算を超過した組織は4分の1を超え、最大の原因は追加の技術ニーズでした。調査の平均値と、最終的にアドバイザーのもとに持ち込まれるプログラムは別の母集団です。計画は後者を前提に立ててください。

40-60%

私がレビューするSAPプログラムでよく見られる予算超過の幅

出典: Noel D'Costa、公表済みの所見

この記事が扱うのは、出発点の金額ではなく予算超過です。企業規模別のコストレンジ、費用の行き先、日額単価、予算の計算式については、SAP導入コストはいくらかのガイドをお読みください。

私がリードまたは立て直しを担った21のSAPプログラム全体で、同じ原因が繰り返し現れます。その大半は、契約に署名する前から見えています。

1. 予算は低く設定され、探索フェーズで実際のスコープが現れる

これが、私が目にする最も多い理由です。企業は最初にコストを低く抑えようとします。取締役会が承認できる数字がビジネスケースに必要だからです。そして、探索フェーズがやってきます。

SAP Activateの探索フェーズでは、Fit-to-Standardワークショップで、SAPの標準プロセスを実際の業務の進め方と突き合わせます（SAP Learning）。そこで見つかったギャップは、すべてバックログ項目になります。レポート、インターフェース、コンバージョン、拡張、フォーム、ワークフローです。そのどれも、当初の価格には入っていませんでした。

予算が間違っていたのは、誰かが計算を誤ったからではありません。スコープが存在する前に設定されたからです。可能であれば、最終的な金額を承認する前に、短期間のFit-to-Standardアセスメントを実施してください。

2. ベンダーがスコープを管理している

署名前に私が目にする最大のコストの失敗は、ベンダーにスコープを管理させることです。システムインテグレーターがスコープを書くと、そのスコープには、業務に必要なものではなく、インテグレーターが納品する予定のものが書かれます。

そのギャップは後で変更要求として表面化し、変更要求はすべて同じベンダーが値付けします。スコープは自社で書くか、導入から独立した立場の人と一緒に書いてください。

3. コスト管理のないスコープ変更

ある小売チェーンは500万ドルの予算を組み、最終的に1,230万ドルで終わりました。要件定義が不十分だったため、スコープ変更が絶えませんでした。途中で在庫プロセスがSAPの標準機能に合わないことがわかり、大規模なカスタマイズが続きました。

レガシーシステムからのデータ移行も過小評価していました。設計段階でプロセスを標準に合わせていれば、はるかに安く済んだはずです。

4. 経営陣のプレッシャーで決まるスケジュール

あるグローバル製造業のプログラムは、予算を143%超過し（計画580万ドルに対して1,400万ドル）、稼働は11か月遅れました。原因は、経営陣からの非現実的なスケジュールのプレッシャー、人員不足の社内チーム、一度に多すぎるモジュール、そして業界の専門知識を持たない最安値のパートナーでした。

安ければ良いとは限りません。最も安い導入オプションを選んだあるクライアントは、より経験のあるチームなら避けられた問題の修正に、30%多く費用をかけることになりました。

5. 兼任の社内メンバー

専任のプロセスオーナーではなく兼任の担当者を割り当てたプログラムは、あらゆる意思決定で日数を失います。あのグローバル製造業のプログラムが11か月遅れた理由の一つも、人員不足の社内チームでした。

自社の優秀な人材は、何か月にもわたって半分以上の時間をプログラムに割くことになります。その時間も、本稼働前後の業務の停滞も、ベンダーの見積もりには現れません。

6. 遅れて見つかるデータの問題

本番前の段階で見つかるデータの問題は、最も高くつきます。データプロファイリングは、設定の後ではなく、要件定義と並行して進めるべきです。本稼働システムのプレッシャーの下での3か月のクレンジングは、予算超過したプログラムで一貫して最大の遅延コストになっています。

このテーマは、私のYouTubeチャンネルの動画（英語）でも解説しています。

最も明確な早期警告サインは、探索フェーズそのものです。WRICEF、つまりレポート、インターフェース、コンバージョン、拡張、フォーム、ワークフローの数を注視してください。ワークショップのたびにそのリストが増え続けるなら、予算はすでにスコープに追い越されています。

以下のサインは、それぞれ上記の原因のどれかを示しています。大半は、毎週のプログラムレビューで確認できます。

警告サイン	通常意味すること	取るべき対応
探索フェーズを通じてWRICEFの数が増えている	実際のスコープが、値付けされたスコープより大きい	探索フェーズの終わり、実現（Realize）フェーズの開始前に予算を再設定する
ギャップがデフォルトで「作る」で解消されている	標準プロセスに対する問いかけがなされていない	業務オーナーに、各ギャップを標準と比べて正当化してもらう
スコープ文書をシステムインテグレーターが起草している	何に値段が付くかをベンダーが管理している	スコープの主導権を握り、独立した立場の人と一緒にレビューする
変更要求のレビューが月次、または値付けされていない	小さな変更が見えないまま積み重なる	すべての変更要求に値段を付け、毎週レビューする
探索フェーズの終わりまでにデータプロファイリングが始まっていない	データの問題がテストやカットオーバーで表面化する	要件定義と並行して、いますぐプロファイリングを始める
キーユーザーがまだ兼任のまま	意思決定が遅れ、手戻りが増える	本来業務の代替要員を確保するか、スケジュールを動かす

以下はそれぞれ、上記の原因のどれかに対応しています。事例は、私が関わった、またはレビューしたプログラムのものです。

1. スコープを自社で持つ。 スコープはクライアント側で書き、探索フェーズの終わりに凍結し、その後の変更はすべて、ワークショップのメモではなく値段の付いた意思決定として扱います。
2. 標準プロセスを採用する。 カスタマイズには二度コストがかかります。作るときと、アップグレードのたびにです。ある製造業のクライアントは、カスタマイズせずに自社のプロセスをSAP標準に合わせることで、80万ドル以上を節約しました。一部の部門には苦しい変化でしたが、財務上の差は非常に大きなものでした。
3. 段階的に展開する。 ある小売業のクライアントは、すべてを一度に行うのではなく、18か月にわたる3つのフェーズに分けて展開し、120万ドルを節約しました。初期投資は40%減り、フェーズ1の教訓によって後のフェーズはより速く進みました。
4. 低い日額単価ではなく、専門性にお金を払う。 ある化学メーカーのクライアントは、汎用的なSAPパートナーから業界に特化したパートナーに切り替え、時間単価は高くなったにもかかわらず、全体で20%少ない費用で済みました。専門家のほうが仕事が速く、ミスも少なかったのです。
5. 予備費を自社の側で持つ。 予算の上に10〜20%を確保し、特定したリスクに対してのみ使います。パートナーの価格に含まれた予備費は、パートナーの優先事項に使われてしまいます。
6. 変更要求を毎週レビューする。 月末ではなく承認前に、一件ごとに予算とスケジュールへの影響を見積もります。
7. 回帰テストを自動化する。 Tricentis ToscaやSAP自身のテスト自動化といったツールは、テストサイクルが2回を超えるプログラムならどれでも元が取れます。そして本稼働後のアップグレードのたびに、新たなサイクルが発生します。

契約面については、私のSAPライセンス交渉チェックリストとCFOのための契約コストレビューで、署名前に何を押さえるべきかを取り上げています。

サブスクリプションモデルは、支出を資本的支出から営業費用へと移します。予算超過のリスクがなくなるわけではありませんが、リスクの所在は変わります。

GROW with SAPはS/4HANA Cloud Public Edition上で動き、拡張はリリース済みのインターフェースを通じてしか認められません。それによってWRICEFのリストが増える範囲は限られ、GROWのプログラムは6〜9か月程度で終わることが多くなります。その代償として、SAPを特殊なプロセスに合わせる自由度は下がります。

RISE with SAPはS/4HANA Cloud Private Edition上で動き、コアをまだ変更できます。そこではクリーンコアは技術的な制約ではなくガバナンス上の判断なので、探索フェーズのリスクはオンプレミスと同じです。RISEのプログラムは通常9〜18か月かかり、複数年のサブスクリプション期間をビジネスケースに明示する必要があります。

AIは新しい予算項目であって、当てにできる節約ではありません。一部のJouleの機能はSAPのクラウドサブスクリプションに含まれていますが、プレミアムなAI機能は別料金です。AIによる削減をうたうパートナーの単価表があれば、その裏にある生産性の前提を確認してください。

これは、大規模なプログラムが損益計算書にどう影響するかに関わります。IFRSでも米国会計基準でも、自社が支配する資産を構築するためのコストは資産計上できますが、運用、トレーニング、準備のためのコストはできません。クラウドでは、予算の大きな部分について答えが変わります。

コスト要素	オンプレミスのライセンス	クラウドのサブスクリプション（RISE / GROW）
ライセンス料またはサブスクリプション料	無形資産として資産計上	契約期間にわたって費用処理（サービス契約）
設定と構築のサービス	直接帰属できる場合は資産計上	IFRS：自社が支配する別個の資産を生まない限り、費用処理となることが多い。米国会計基準：導入コストを資産計上し、ホスティング期間にわたって償却
構築にかかる社内人件費	直接帰属できる場合は資産計上	上記と同じ区分
トレーニングとチェンジマネジメント	費用処理	費用処理
データクレンジング	費用処理	費用処理
継続して使うデータ変換ツール	再利用できる場合は資産計上	個別に判断
ハイパーケアとサポート	費用処理	費用処理

IFRSの立場は、IFRS解釈指針委員会によるクラウド・コンピューティング契約における設定とカスタマイズのコストに関する2021年のアジェンダ決定に基づいています。米国会計基準の立場は、ASU 2018-15に基づいています。特にIFRSの下では、オンプレミスと同じ資産計上を前提にしたRISEのビジネスケースは、初年度の利益を大幅に過大表示するおそれがあります。

どれだけ資産計上できるかは、文書化で決まります。ある製造業のクライアントは、適切に資産計上することで当期の費用を230万ドル削減しました。その方針を説明できるほど、コンサルタントの作業を綿密に記録していたからです。別のクライアントは、資産計上の判断を裏付けられず、苦しい修正再表示に直面しました。

監査人は、資産計上された大規模プロジェクトを厳しく見ます。方針は、期末ではなく、プログラムの開始前に監査人と合意してください。

予算超過したプログラムの大半は、計画に失敗したわけではありません。計画段階で正直さに失敗したのです。適切な予備費を含む現実的な計画を承認するCFOは、予備費のない楽観的な計画を承認するCFOより、少ない費用で済みます。

このガイドは、ビジネスケースから本番稼働までのすべてのテーマをまとめたSAP導入ガイドの一部です。

SAP導入はなぜ予算を超過するのですか？

最も多いのは、最初は予算を低く抑え、その後、探索フェーズで実際のスコープが明らかになるケースです。Fit-to-Standardワークショップによって、ギャップが値付けされていなかったレポート、インターフェース、コンバージョン、拡張、フォーム、ワークフローに変わります。ベンダーが管理するスコープ、兼任の社内チーム、遅れたデータ作業が、事態をさらに悪化させます。

SAPプロジェクトは通常どのくらい予算を超過しますか？

私がレビューしたプログラムでは、40〜60%の予算超過は珍しくありません。Panorama Consultingの2026年の調査では、ERP予算を超過した組織は4分の1を超えていました。アドバイザーのもとに持ち込まれるプログラムは、その母集団の中でも問題を抱えた一部である傾向があります。

SAPの予算超過の早期警告サインは何ですか？

最も明確なサインは、探索フェーズを通じて増え続けるWRICEFの数です。ほかには、ベンダーが起草したスコープ文書、毎週値付けされない変更要求、まだ始まっていないデータプロファイリング、兼任のままのキーユーザーがあります。リストが増えているなら、探索フェーズの終わりに予算を再設定してください。

SAPプロジェクトのスコープクリープはどう止めればよいですか？

システムインテグレーターに書かせるのではなく、スコープをクライアント側で持ってください。探索フェーズの終わりに凍結し、すべてのギャップをSAP標準と比べて問い直し、変更要求は承認する前に一件ずつ値段を付けます。変更要求のレビューは、月末ではなく毎週行ってください。

RISE with SAPは予算超過のリスクを下げますか？

それだけでは下がりません。RISEはPrivate Edition上で動き、コアをまだ変更できるため、探索フェーズのリスクはオンプレミスと同じです。Public Edition上のGROW with SAPは拡張をリリース済みのインターフェースに限定するため、スコープが増える範囲が狭まります。

RISE with SAPの導入コストは資産計上できますか？

一部は可能で、適用する会計基準によって異なります。サブスクリプション自体は通常、費用処理されます。IFRSでは、SaaS契約における設定とカスタマイズのサービスも、自社が支配する別個の資産を生まない限り費用処理となることが多く、米国会計基準（ASU 2018-15）では、導入コストを資産計上し、ホスティング期間にわたって償却します。