高くつく失敗を避ける、SAP導入のベスト戦略

最良のSAP導入戦略とは、自社の事業に合い、チームが維持できる戦略です。決めるべきことは3つに絞られます。1つ目は、どの導入形態にするか。S/4HANA Cloud Public Edition（通常はGROW with SAP経由）、Private Edition（通常はRISE with SAP経由）、またはオンプレミスです。2つ目は、どの移行パスにするか。グリーンフィールド、ブラウンフィールド、ブルーフィールドです。3つ目は、どの展開パターンにするか。ビッグバン、段階的、ハイブリッドです。このガイドは、S/4HANAの進め方を選ぶCIO、プログラムディレクター、スポンサーに向けたものです。以下の5つの質問に答え、先に導入形態を決め、そのうえで比較表とデシジョンツリーを使って残りの2つを決めてください。

私が関わった21のプログラムを通じて、パターンは一貫しています。戦略の選択は確かに重要ですが、判断の小さいほうの半分です。大きいほうの半分は、選択肢を並べたスプレッドシートがしまい込まれた後の14か月に及ぶ実行の間、チームが規律を保てるかどうかです。

目標は、最速または最安の選択肢ではありません。事業に合った進め方です。事業の構造、文化、ペース、規制上の特性、長期的な目標に合うものです。

最初に答えるべき5つの質問

1. 組織構造はどれほど複雑ですか。単一法人、複数法人、複数国のどれですか？
2. チームには適応する時間が必要ですか。それとも、今すぐ変化を受け入れる準備ができていますか？
3. 移行元は、複数のレガシーシステム、1つのERP、それとも白紙からですか？
4. 社内にSAPの専門知識はありますか。それともパートナーに頼ることになりますか？
5. 本稼働時の混乱を、どこまで許容できますか？

万能の答えはありません。戦略は、他社の成功事例ではなく、自社の現実を反映したものであるべきです。

2023年から2026年の間に何が変わったか

RISEとGROWが、クラウドでS/4HANAを購入する標準的な方法になりました。RISE with SAPは、ソフトウェア（通常はPrivate Edition）、SAPが運用するインフラと技術運用、BTPクレジットを、1つのサブスクリプションにまとめたものです。GROW with SAPは、標準的なプロセスで運用する中堅企業向けに、Public Editionをパッケージにしたものです。ライセンスを購入してから導入するという従来型の方法も、オンプレミスでは残っていますが、新規の相談の大半はRISEかGROWから始まります。

クリーンコアは、助言からアーキテクチャになりました。Public Editionでは、コアを修正できません。拡張はリリース済みのAPIを使い、ABAP Cloudによるオンスタック、またはSAP BTP上のサイドバイサイドで行います。Private Editionとオンプレミスでは今も修正できますが、修正はそのたびにアップグレードの作業を増やすため、SAPのガイダンスは修正を最後の手段と位置づけています。クリーンコアの経験がないパートナーは、初週から技術的負債を生み出します。

AIがデリバリーのツールに入ってきました。SAP Joule for Consultants（2025年5月から一般提供）は、SAP自身のコンテンツをもとに、設定に関する質問に答えます。SAP Cloud ALMは、Fit-to-Standardワークショップの書き起こしから要件のドラフトを作成できます。SAP Build Code（2024年3月から一般提供）は、Jouleを使ってJavaとJavaScriptの拡張を生成し、開発者向けのJouleには、2024年後半からABAPコードの生成と解説が加わりました。どれも、戦略上の選択を変えるものではありません。変わるのは、どの選択をしても、その中でかかるコストと時間です。

戦略が成功する場面、失敗する場面

選択よりも実行のほうが重要です。どの進め方を選んでも、4つの失敗パターンが現れます。

1. 経営陣の関与が消える。ある銀行のS/4HANA導入では、CEOが主要な会議にはすべて出席し、的確な質問をし、チームを支えました。導入は予定どおりに完了し、費用も計画を下回りました。一方、ある店舗チェーンでは、経営陣がキックオフの後はすべてを任せきりにしました。誰も意思決定ができず、プロジェクトは何か月も停滞しました。
2. データ移行をIT部門の作業として扱う。あるクライアントは、製品マスタデータは「十分にきれい」だと言い張りました。稼働初日、その倉庫には、3年前に廃止された製品の注文が届きました。クリーンアップには数週間かかり、主要な顧客を1社失いました。データ移行には、事業側のオーナーシップが必要です。
3. 研修を省く、または急ぐ。SAPの稼働から2週間後に、あるオフィスを訪ねました。経理チームは、モニターのあちこちに、基本的な作業のリマインダーを書いた付箋を貼っていました。研修は1日だけだったそうです。マネージャーは「なんとか生き延びようとしているだけです」と話していました。その会社は、最初の1年で、サポートに追加で20万ドルを費やしました。
4. システムを迂回する人たち。研修で十分だと考えていた工場と仕事をしたことがあります。作業員は新しいシステムを信用せず、スプレッドシートに戻りました。本稼働の後でそれを直すには、高い費用がかかりました。チェンジマネジメントとは、コミュニケーション、関与、そして事業部門内のチャンピオンのことであり、研修はその一部にすぎません。

主な二つの展開パターン

ビッグバン

• すべてを一回のカットオーバーで本稼働
• プロセス標準化への最短ルート
• 初期コストは低く、初日のリスクは高い
• 入念なリハーサルときれいなデータが必須

段階的

• モジュール、地域、機能ごとにウェーブで本稼働
• ウェーブの合間に軌道修正する余地が大きい
• サポートコストは長期化し、保守する連携も増える
• 持続的な規律とガバナンスが必須

ビッグバン

ある製造企業のSAP本稼働に参加したことがあります。1回の週末で、すべてが切り替わりました。財務、調達、営業、製造のすべてが、月曜の朝に本稼働しました。慌ただしさはありましたが、明快さには力がありました。全員が一緒に動き、どのシステム、どのデータを信頼すべきかで迷うことはありませんでした。

うまくいった理由は、チームがカットオーバーを何度もリハーサルし、数週間前からデータをクレンジングし、実際のテストケースでユーザーを訓練したことです。利点は、足並みが早くそろい、リターンも早く得られることです。欠点は、失敗の余地がないことです。初日に受注の価格設定で問題が起きたとき、その影響はすべての地域に及びました。

向いている条件：プロセスが標準化され、チームの準備が整っていて、経営陣がスコープを守り抜く場合です。

段階的

別のプロジェクトでは、小売チェーンの案件で段階的に進めました。まず財務、人事、調達、その後に物流とPOSです。1年以上かかりましたが、チームに息をつく余裕が生まれました。人事チームは最初の1か月をかけてワークフローを固め、その後でほかの全員を研修しました。ビッグバンでは、これはできなかったでしょう。

代償は、サポート期間が長くなることと、本稼働済みのシステムとまだ稼働していないシステムの間を流れるデータに、特別な注意が必要になることです。

向いている条件：組織が大きい、または分散している、地域ごとにプロセスが異なる、あるいは経営陣が軌道修正の余地を持ちたい場合です。

ハイブリッド

答えが、その両方になることもあります。

私が関わった英国の家電ディストリビューターは、財務と調達を早く本稼働させる必要がありました。倉庫は、依存関係が多すぎて準備ができていませんでした。そこで財務と調達が先に進み、物流と倉庫管理が後に続きました。ある領域ではビッグバン、別の領域では段階的です。

ハイブリッドは、調整作業を増やします。調達がSAPにあり、営業がまだ載っていなければ、両者の間のデータ同期を慎重に設計する必要があり、ガバナンスも最後まで緩めてはいけません。

向いている条件：事業部門ごとに進むペースが異なる、一部の部門がより速く動く必要がある、あるいは季節的な繁忙期のせいで特定の本稼働日が選べない場合です。

3つを比較すると、次のようになります。

基準	ビッグバン	段階的	ハイブリッド
スケジュール	最短：すべてを一度に	長い：ウェーブに分けて展開	中程度：一部は速く、ほかは遅め
事業への影響	本稼働に問題があれば大きい	小さい：変化が緩やか	最初のウェーブは大きく、その後は小さい
リスク	問題が事業全体に及ぶ	問題がフェーズ内にとどまる	ビッグバンの部分に集中する
コスト	初期は低いが、ミスは高くつく	総額は高いが、緊急対応は少ない	中間。調整が不確定要素
データ移行	1回の移行枠。完全でなければならない	ロードを分割し、フェーズごとの量は少ない	本稼働済みのシステムと稼働前のシステムの間のインターフェースが難所
ユーザーの定着	難しい：一夜で変わる	容易：徐々に触れていく	最初のウェーブが先駆者となり、後のウェーブはそこから学ぶ
最適な組織	小規模な組織、標準的なプロセス、高い準備度	プロセスが多様な、大規模で分散した企業	準備ができている部門とできていない部門が混在する、複数部門の組織

Decide

自社の状況に合う移行パスはどれですか？

レガシーが分断されていて、プロセスを再設計したい

→グリーンフィールド

プロセスは健全で、ECCは安定しており、履歴を残す必要がある

→ブラウンフィールド

複数法人で、一部を再利用し、データを選択して移したい

→ブルーフィールド

グリーンフィールド：ゼロから始める

この進め方は、買収で急成長し、システムが分断されていた小売企業のプロジェクトで見ました。私たちは白紙から始め、S/4HANA上で統一されたプロセスを設計しました。自分たちのやり方に慣れたチームは、最初は反発しました。結果として、地域間の一貫性が高まり、レポートがすっきりし、システム同士が連携するようになりました。

使うべき場面：レガシーシステムが分断されすぎている、またはカスタマイズされすぎていてきれいに移行できず、事業側も、古い習慣をデジタル化するのではなく、仕事の進め方を考え直したい場合です。

ブラウンフィールド：コンバージョンとアップグレード

私の初期のプロジェクトの1つ、製造企業の案件では、ブラウンフィールドが正しい判断でした。クライアントはECCを大幅にカスタマイズしており、やり直すのはリスクが高すぎると感じられたのです。私たちは、S/4HANAへの技術的なコンバージョンに集中しました。ユーザーは早く慣れ、本稼働も早くなりましたが、再設計すべきだった使いにくいワークフローを持ち越すことになりました。

使うべき場面：既存のプロセスが健全で文書化されており、監査やコンプライアンスのためにトランザクション履歴が重要で、予算や時間が厳しく、組織が再編の最中でない場合です。

ブルーフィールド：選択的な移行

ブルーフィールド（選択的データ移行）は、すべてではなく、特定の会社コード、事業部門、期間だけを移行します。合併やカーブアウトによって形づくられた企業や、誰も必要としない何年分ものデータを抱えたシステムに向いています。残すと決めた部分については、グリーンフィールドのようなプロセスの自由度と、ブラウンフィールドのような継続性の両方が得られます。3つの移行パスとそのスケジュールについては、私のECCからS/4HANAへの移行ガイドでさらに掘り下げています。

2018年には、展開パターンと移行パスが戦略のすべてでした。2026年には3つ目の決定があり、それが残る2つを制約します。どのエディションのS/4HANAを稼働させ、どのように購入するかです。

1. 03展開パターンビッグバン、段階的、ハイブリッド。吸収できる混乱の大きさで決まる
2. 02移行パスグリーンフィールド、ブラウンフィールド、ブルーフィールド。エディションが対応する範囲内で選ぶ
3. 01導入形態Public Edition、Private Edition、オンプレミス。これを最初に決める

S/4HANA Cloud Public Edition（通常はGROW with SAP経由で購入し、SAPはSAP Cloud ERPという名称で展開しています）。マルチテナントのSaaS、SAP標準のプロセス、6か月ごとのアップグレード、コアの修正は不可。グリーンフィールドのみです。価値の実現が最も速く、柔軟性は最も低くなります。SAP標準を受け入れる意思のある中堅企業に最適です。プロセスに大きな逸脱が必要なら、答えとして誤りです。

S/4HANA Cloud Private Edition（通常はRISE with SAP経由で購入）。シングルテナント、SAPが運用するインフラ、2年ごとの新リリースと7年間のメインストリームメンテナンス、そして設定と拡張の余地が大きい点が特徴です。ブラウンフィールド、グリーンフィールド、選択的な移行に対応します。大企業のプログラムの大半で、標準となる選択です。

S/4HANAオンプレミス。インフラは、自社またはハイパースケーラーが運用します。拡張性と制御は最大で、アップグレードの頻度は最も低くなります。クリーンコアは推奨されますが、強制はされません。厳格なデータレジデンシー要件がある場合や、社内に強力なBasisチームを持つ組織に向いています。SAPの新機能は、クラウドエディションに先に届くことが増えています。

展開パターンと移行パスは、選んだエディションの範囲内に収まります。Public Editionのプロジェクトは、定義上、グリーンフィールドです。大幅にカスタマイズされたECCを変換するPrivate Editionのプログラムは、通常はブラウンフィールドかブルーフィールドで、大規模なら通常は段階的です。RISEとGROWの商業面については、私のGROW with SAPとRISE with SAPのページをご覧ください。

木曜日の朝、デザインワークショップの途中でした。IT責任者が、SAP標準の受注から入金までのプロセスのデモを終えたところです。営業の誰かが言いました。「でも、うちのやり方はそうじゃない」。部屋が静まり返りました。この瞬間は、ほぼすべてのプロジェクトで訪れます。

Fit-to-Standard

SAP標準にとどまれば、導入期間と長期的な保守が減ります。存在しないカスタムロジックを、アップグレードが壊すことはありません。私が関わったある小売のプロジェクトでは、Fit-to-Standardのおかげで、クライアントは6か月未満で本稼働できました。可動部分が少なく、やり取りも少なく、将来のアップグレードに向けて、よりすっきりしたシステムになりました。

経験則：カスタマイズするのは、規制がそれを求める場合か、そのプロセスが真の競争優位をもたらす場合だけです。「昔からそうやってきたから」という理由では、決してしないでください。

実務でのクリーンコア

すべてのパートナーに、リリース済みのAPIまたはSAP BTP上で構築した拡張の実例を尋ねてください。答えが曖昧なら、危険信号として扱ってください。クラウドのプログラムにオンプレミスの習慣を持ち込むパートナーは、最初のスプリントから技術的負債を積み上げます。

コードが避けられないとき

カスタム開発が必要な場面は確かにあります。SAP Build Codeや開発者向けのJouleといったAIツールは、それを書くコストを下げます。保守するコストは下げません。

誰も文書化しなかったカスタムロジックは、誰も触りたがらないロジックになり、その後のあらゆる変更を遅らせます。どのAIツールも、これを解決しません。解決するのは、文書化の規律です。カスタマイズせざるを得ないなら、最初から文書化し、リリース済みのAPIかBTP上で構築し、コアから切り離しておいてください。クリーンなカスタマイズには、回収できる現実のコストがかかります。クリーンでないカスタマイズには、払い続けるコストがかかります。

これは、2026年に米国市場のS/4HANAで私が目にしているプログラム総費用のレンジです。スコープ、複雑さ、業界、パートナー、エディションによって変わります。予算計画の目安として使い、見積りとしては使わないでください。

戦略とスコープ	標準的なプログラム総費用
中堅企業、ブラウンフィールド、段階的	500万〜1,500万ドル
中堅企業、グリーンフィールド、ビッグバン	800万〜2,000万ドル
中堅企業のGROW with SAP（サブスクリプションとデリバリー）	200万〜600万ドル
大企業、ブラウンフィールド、段階的	2,500万〜8,000万ドル
大企業、グリーンフィールド、ビッグバン	3,500万〜1億2,000万ドル
大企業のRISE with SAP（サブスクリプションとデリバリー）	2,000万〜8,000万ドル
グローバル複数地域、いかなる組み合わせでも	1億〜3億ドル超

導入形態は、最も過小評価されがちなコスト変数です。RISEとGROWのサブスクリプションは、複数年のコミットメントを合算すれば、オンプレミスのライセンスより安くはありません。その価値は、インフラの責任の移転、価値実現の早さ、予測しやすいサブスクリプション費用にあります。RISEやGROWを選ぶ理由が総費用であることは、まれです。決め手は、運用モデルです。

SAP導入戦略とは何ですか？

企業がSAPを展開する際の進め方のことです。スコープ、方法論、導入形態、移行パス、展開パターン、スケジュールが含まれます。2026年時点での主な選択は、導入形態（Public Edition、Private Edition、オンプレミス）、移行パス（グリーンフィールド、ブラウンフィールド、ブルーフィールド）、展開パターン（ビッグバン、段階的、ハイブリッド）です。

重要なのは、その組み合わせが、組織の準備状況、プロセスの複雑さ、規制上の特性、混乱への許容度に合っているかどうかです。

ビッグバン導入がうまくいくのはどんなときですか？

プロセスがすでに標準化され、ユーザーが十分に訓練され、移行前にデータがクレンジングされ、経営陣がスコープを守り抜くときです。そのどれか1つでも欠ければ、特にきれいなデータとユーザーの準備が欠ければ、賭けになります。

本稼働時の問題は、すべてに一度に影響します。準備があれば、対処できる範囲です。準備がなければ、危機になります。

SAP導入のグリーンフィールドとブラウンフィールドの違いは何ですか？

グリーンフィールドは新しいシステムから始め、レガシーの設定を引き継ぎません。SAP標準を軸に、プロセスをゼロから設計します。ブラウンフィールドは既存のシステムを変換し、トランザクション履歴と設定を保持します。

グリーンフィールドは初期費用が高く、よりクリーンで将来に備えたシステムになります。ブラウンフィールドはより速く、混乱も少ないものの、回避策とカスタムコードを持ち越します。ブルーフィールドは中間の道で、選んだ法人とデータを選択して移行します。

RISE with SAPとGROW with SAPの違いは何ですか？

RISE with SAPは大企業向けのSAPのサブスクリプション提供形態で、通常はS/4HANA Cloud Private Editionを基盤とし、SAPが運用するインフラと技術運用を1つの契約に含みます。米国市場では、デリバリーを含むプログラム総額として、通常2,000万〜8,000万ドルを目にします。

GROW with SAPは中堅企業を対象とし、S/4HANA Cloud Public Edition上でSAP標準のプロセスで動きます。デリバリーを含めて、通常200万〜600万ドルを目にします。

企業の規模と、プロセスがSAP標準からどこまで異なる必要があるかで、どちらかが決まります。

SAPのFit-to-Standardとは何で、なぜ今、より重要なのですか？

Fit-to-Standardとは、現在の自社の仕事の進め方に合わせてSAPをカスタマイズするのではなく、自社のプロセスをSAPの標準機能に合わせることです。導入期間が短くなり、保守が減り、アップグレードもすっきりします。

クリーンコアがあるため、いっそう重要になっています。Public Editionでは、コアの修正はそもそも不可能です。Private Editionとオンプレミスでは、修正のたびにアップグレードの作業が増えます。問うべきは、標準のSAPでは対応できない真の事業上の理由があるかどうか、そしてある場合には、パートナーがリリース済みのAPIまたはSAP BTP上で拡張を構築できるかどうかです。

SAP Activate方法論のフェーズは何ですか？

SAP Activateには6つのフェーズがあります。Discover（SAPの提供内容とビジネスケースの探索）、続いて4つの中核となるデリバリーフェーズ。Prepare（計画、ガバナンス、チーム編成）、Explore（Fit-to-Standardワークショップとバックログ）、Realize（スプリントでの設定、拡張、テスト）、Deploy（カットオーバー、本稼働、ハイパーケア）です。Runは、本稼働後の運用を対象とします。

プロジェクトが最も時間を失うのはRealizeで、とりわけテストでデータ品質の問題が表面化したり、カスタマイズのスコープが膨らんだりするときです。Realizeの間じゅうスコープのベースラインを厳格に保てるかどうかが、予定どおりに本稼働するプロジェクトと、漂流するプロジェクトを分けます。

SAP導入はなぜ失敗するのですか？

失敗の大半は、4つの原因で説明がつきます。キックオフの後に経営陣の関与が消えること、データ移行がIT部門の作業として扱われること、チェンジマネジメントが研修マニュアルにとどまること、そしてクリーンコアの経験がないパートナーが、最初のアップグレードで表面化する技術的負債を生み出すことです。

技術が失敗することは、まれです。プログラムが失敗するのは、意思決定が行われないとき、汚れたデータが新システムに入り込むとき、ユーザーが回避策を見つけるとき、あるいはカスタマイズを作り直さなければならなくなるときです。戦略は重要です。実行の規律は、それ以上に重要です。