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

最良のSAP導入戦略とは、自社の事業に合い、チームが最後までやり抜ける戦略です。決めるべきことは3つあります。デプロイモデルはどれか。S/4HANA Cloud Public Edition(通常はGROW with SAP経由)、Private Edition(通常はRISE with SAP経由)、オンプレミスのいずれかです。移行パスはどれか。グリーンフィールド、ブラウンフィールド、ブルーフィールドのいずれかです。そして展開方式はどれか。ビッグバン、段階的、ハイブリッドのいずれかです。本ガイドは、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から始まります。

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

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

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

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

1. 経営陣の関与が消える。 ある銀行のS/4HANA導入では、CEOが主要な会議すべてに出席し、的確な質問をし、チームを後押ししました。プロジェクトは予定どおりに終わり、費用も計画を下回りました。ある店舗チェーンでは、経営陣がキックオフ後にすべてを丸投げしました。誰も意思決定できず、プロジェクトは何か月も停滞しました。
2. データ移行をITの作業として扱う。 あるクライアントは、製品のマスタデータは「十分にきれい」だと主張しました。初日、倉庫には3年前に販売終了した製品の注文が届きました。クリーンアップに数週間を要し、大口顧客を1社失いました。データ移行には業務側のオーナーシップが必要です。
3. 研修を省く、または急ぐ。 SAP稼働の2週間後、ある事務所を訪れました。経理チームのモニターには基本操作のメモを書いた付箋が一面に貼られていました。研修は1日だけだったのです。マネージャーは私に「なんとか乗り切ろうとしているだけです」と言いました。この会社は初年度、サポートに20万ドルを余分に費やしました。
4. システムを迂回して仕事をする。 研修さえすれば十分だと考えていた工場と仕事をしたことがあります。作業者は新しいシステムを信頼せず、スプレッドシートに戻りました。本稼働後にそれを正すのは高くつきました。チェンジマネジメントとは、コミュニケーション、巻き込み、そして事業内部の推進役であり、研修はその一部にすぎません。

2つの主要な展開方式

ビッグバン

1. 01一度の切り替えですべてを稼働
2. 02標準化されたプロセスへの最短ルート
3. 03初期費用は低いが、初日のリスクは高い
4. 04入念なリハーサルとクリーンなデータが必要

段階的

1. 01モジュール、地域、機能ごとに順次稼働
2. 02フェーズの合間に軌道修正する余地が大きい
3. 03サポート費用が長引き、維持すべき連携が増える
4. 04持続的な規律とガバナンスが必要

ビッグバン

ある製造企業の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オンプレミス。 インフラは自社またはハイパースケーラーが運用します。拡張性と管理の自由度は最大で、アップグレードのサイクルは最も遅くなります。Clean Coreは推奨されますが、強制ではありません。厳格なデータ所在地要件がある組織や、社内に強力な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か月未満で本稼働できました。可動部分が少なく、やり取りも減り、将来のアップグレードに向けてシステムがすっきりしました。

目安： カスタマイズするのは、規制が求める場合か、そのプロセスが真の競争優位をもたらす場合に限ります。「昔からそうしてきたから」という理由では決して行いません。

実務におけるClean Core

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

コードが避けられない場合

ある程度の独自開発は必要です。SAP Build CodeやJoule for developersのようなAIツールは、コードを書くコストを下げます。保守するコストは下げません。

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

以下は、2026年に私が目にしているS/4HANAのプログラム総費用のレンジです。金額を左右するのは、戦略よりもはるかに企業規模とスコープです。見積もりではなく予算計画の目安として使い、詳しい内訳は私の2026年版SAP導入費用レンジをご覧ください。

企業規模	一般的なプログラム総費用
小規模(従業員200人未満)	8万ドル〜50万ドル
中堅(従業員200〜1,000人)	50万ドル〜200万ドル
大企業(従業員1,000〜10,000人)	200万ドル〜1,000万ドル超
グローバルグループ(従業員10,000人超)	1,000万ドル〜5,000万ドル超

戦略で動くのはレンジの中での位置であり、レンジをまたぐことはありません。グリーンフィールドはブラウンフィールドより初期費用が高く、ビッグバンは初期費用の低さと引き換えに初日のリスクが高くなります。これに加えて10〜20パーセントの予備費を確保し、導入サービスが総額の35〜50パーセントを占めると見込んでください。

最も過小評価されやすいコスト変数はデプロイモデルです。RISEとGROWのサブスクリプションは、複数年の契約を合算すると、オンプレミスのライセンスより安いわけではありません。その価値は、インフラ責任の移転、価値実現までの速さ、予測可能なサブスクリプション費用にあります。RISEやGROWを選ぶ理由が総コストであることはまれです。理由は運用モデルです。

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

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つの契約にまとめています。私が目にするプログラム総額は、導入作業を含めて大企業で200万ドルから1,000万ドル超、グローバルグループで1,000万ドルから5,000万ドル超、期間は9〜18か月が一般的です。

GROW with SAPは中堅企業向けで、SAPの標準プロセスを備えたS/4HANA Cloud Public Edition上で稼働します。中堅企業の場合、導入作業を含めて50万ドルから200万ドル、期間は約6〜9か月が一般的です。

どちらを選ぶかは、企業規模と、自社のプロセスがSAP標準からどこまで外れる必要があるかで決まります。

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

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

今より重要になっているのはClean Coreのためです。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の作業として扱われるデータ移行、研修マニュアルにとどまるチェンジマネジメント、そしてClean Coreの経験がないパートナーが生み出し、最初のアップグレードで表面化する技術的負債です。

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