SAP導入のスケジュール計画：フェーズ別の期間と避けるべき5つの失敗

私の経験では、SAP導入にはGROW with SAPで6〜9か月、RISE with SAPで9〜18か月かかります。SAP ECCからの移行は、ブラウンフィールドでのシステム変換か選択的データ移行で12〜18か月、グリーンフィールドでの導入で18〜24か月です。

端的に言えば、期日はキックオフではなくExploreの終わりに確定し、ベンダーの見積もりに15〜20%のバッファを上乗せしてください。データの作業はDiscoverで始めます。データ移行が導入工数の30〜40%を占めるからです。遅延が1か月延びるごとに、コンサルティング費用だけで少なくとも6桁にのぼる費用がかかります。

このガイドは、計画を立てている、あるいは計画を立て直しているプログラムディレクターとスポンサーのためのものです。扱うのは「どれくらいかかるか」であり、「どう進めるか」ではありません。各フェーズで何をし、誰がそれを担うかは、私のSAP導入のステップごとのガイドをお読みください。

2024年の欧州の製造業のプログラムで、私はSAPプロジェクトが予定より6か月遅れているプロジェクトマネージャーに出会いました。SAP Activateのフェーズに厳密に沿って計画を立て直した結果、残りの作業を4か月で終えました。

彼の言葉です。「明確なフェーズと具体的な成果物があったことで、すべてが変わりました。次に何をすべきか、いつもはっきりわかっていました。」

SAP導入のスケジュールを最も大きく左右するのは、展開モデルの選択です。私が計画の出発点にしている期間は次のとおりです。

出発点と移行先	標準的な期間	ペースを決める要因
GROW with SAP（SAP Cloud ERP、パブリックエディション）	6〜9か月	標準プロセスのみ。拡張はリリース済みAPI上
RISE with SAP（SAP Cloud ERP Private）	9〜18か月	スコープ、拡張の数、データ量
ECCからのブラウンフィールド変換	12〜18か月	カスタムコード、簡素化項目、テスト
ECCからのグリーンフィールド導入	18〜24か月	プロセスの再設計、ユーザーにかかる変化の負荷
選択的データ移行	12〜18か月	データのスコープ定義と専門ツール

比較として、パブリックエディションのプロジェクトを何百件もレビューしてきたSAPのプロダクトエキスパートは、標準的な本稼働までの期間を5〜7か月としています。2026年初めに始まったSAPのGROW Fastは、固定スコープで2〜4か月を目標にしています。それでも私がGROWのプログラムを6〜9か月で計画するのは、ソフトウェアがかけない時間を、データ、意思決定、教育が必要とするからです。

RISEでは、SAPがインフラを運用するので、Prepareの作業の一部がなくなります。データ、テスト、チェンジマネジメントの作業はなくなりません。ブラウンフィールド、グリーンフィールド、選択的移行のどれを選ぶかは、ECCからS/4HANAへの移行ガイドで説明しています。

出張・経費管理の製品であるSAP Concurは、独自のプロジェクトを持つ別のクラウド製品です。S/4HANAのフェーズ計画の中に入れるのではなく、S/4HANAの財務との連携を含めて、独立したワークストリームとして計画してください。

予算と期日が崩れる場所

私が見る最大の失敗は、最初にきちんと計画しないことです。期日と予算はExploreで超過します。ワークフロー、レポート、インターフェース、データ変換、機能拡張、帳票（WRICEF）の一覧が膨らみ、スコープを握っているのがクライアントではなくベンダーになるときです。

それが50%の超過にまでつながりうることは、私のSAP導入コストの内訳で示しています。守られるスケジュールには3つの共通点があります。現実的なバッファ、確定前に検証された前提、そして絶対的な停止点として扱われる品質ゲートです。

超過の大半は、5つの失敗で説明できます。どれも予測可能で、どれにも対策があります。

失敗1：スコープを理解する前に期限を決める

2023年のGCCの小売業のプログラムでは、クライアントがバッファなしで9か月での導入を取締役会に約束していました。データ移行が想定より長引き、期限を3か月過ぎ、経営陣はチームへの信頼を失いました。私ははっきりと伝えました。あのスケジュールは無理がありすぎた、と。

対策：スケジュールはキックオフではなくExploreの後に確定し、そのことを最初に取締役会に伝えます。ベンダーの見積もりに15〜20%のバッファを上乗せします。

失敗2：データ移行を遅れて始まるワークストリームとして扱う

多くのチームは、データ移行リードの任命が遅く、作業に十分な人を割きません。最初のデータ評価はほぼ必ず問題を過小評価し、稼働中のシステムのプレッシャーのもとで3か月のクレンジングが続きます。

対策：データのプロファイリングはRealizeではなくDiscoverで始めます。結合テストを始める前に、Realizeで完全な移行リハーサルを行います。リハーサルのサイクルについては、私のSAPのデータ移行が失敗する理由の記事で詳しく扱っています。

失敗3：スケジュールに追われて品質ゲートを飛ばす

RealizeとDeployの間のゲートは、チームが最も飛ばしやすいゲートです。「とにかく本稼働させろ」というプレッシャーがそこで最も高まるからです。「スケジュールを守る」ために品質ゲートを飛ばすと、後でもっと大きな遅れが生まれます。

対策：測定可能な終了基準をプロジェクト憲章に書き込み、ステアリングコミッティにそれを徹底させます。私はどのプログラムでも、3日間の決算リハーサルを準備完了の判定ゲートにしています。ゲート設計の詳細は、私のSAPの品質ゲートのガイドをご覧ください。

失敗4：本稼働の2か月前にユーザー教育をする

2024年のGCCの小売業のプログラムでは、クライアントが本稼働の2か月前に全ユーザーの教育を行いました。稼働当日には、ほとんどの人がシステムの使い方を忘れていました。私たちはすべての作業場所に業務マニュアルを置き、現場サポートを倍にしました。

対策：教育は本稼働の2〜3週間前に行い、パワーユーザーを講師にします。人は信頼する同僚から学ぶからです。全体のアプローチは、私のSAPのユーザー教育戦略の記事にまとめています。

失敗5：繁忙期に本稼働を予定する

Hersheyは1999年7月、SAP R/3、Siebel、Manugisticsによるシステムで本稼働しました。予定より3か月遅れ、そのままハロウィーンの受注シーズンに突入しました。同社のCEOはアナリストに対し、この問題によってHersheyは1億ドル相当のハロウィーン向け受注を出荷できないと説明しました。

対策：影響を受けるすべての事業部門について、月末決算や四半期末決算を含む繁忙期を洗い出します。6週間ずらすことになっても、取引量の少ない時期に本稼働してください。ずらした分は取り戻せますが、繁忙期の本稼働の失敗は取り戻せません。

SAP Activateには6つのフェーズがあり、クラウドでもオンプレミスでも、あらゆるS/4HANAの計画の骨格になります。以下の期間は、単一プログラムの計画の出発点であり、約束ではありません。

1. 1Discover2〜4週間。終了条件：スコープと成功基準への署名
2. 2Prepare3〜6週間。終了条件：憲章の承認、要員の書面での確約
3. 3Explore4〜8週間。終了条件：ギャップの判断に責任者がいる、スケジュールの確定
4. 4Realize8〜16週間。終了条件：移行リハーサルの合格、結合テストの完了
5. 5Deploy2〜4週間。終了条件：UATの承認、決算リハーサル、Go/No-Go
6. 6Run4〜8週間のハイパーケア。終了条件：不具合がしきい値未満、サポート移管への署名

私がすべての計画の出発点にしているフェーズ表です。

フェーズ	標準的な期間	何が行われるか	次に進む前の終了ゲート
Discover	2〜4週間	ビジネスケース、スコープ、展開方式の選択（パブリッククラウド、プライベートクラウド、オンプレミス）	スコープと測定可能な成功基準への署名
Prepare	3〜6週間	チームの立ち上げ、ガバナンス、システムランドスケープ、ベースライン計画、リスク登録簿	憲章の承認、モジュールごとの意思決定者の指名、要員の書面での確約
Explore	4〜8週間	Fit-to-Standardワークショップ、ギャップログ、WRICEFの一覧	ギャップの判断を責任者とともに記録、スケジュールの確定
Realize	8〜16週間	設定、開発、単体テストと結合テスト、移行リハーサル	移行リハーサルの合格、結合テストの完了
Deploy	2〜4週間	ユーザー受け入れテスト、カットオーバーのリハーサル、エンドユーザー教育、最終データロード	UATの承認、決算リハーサルの合格、Go/No-Go
Run	4〜8週間のハイパーケア	現場サポート、日次のトリアージ、サポートへの引き継ぎ	未解決の不具合が合意したしきい値未満、サポート移管への署名

時間が実際にどこに消えるか

Discoverは急がされがちです。チームはスコープを理解する前に期限を決め、「月次決算を3日短縮する」といった測定可能な成功基準を省いてしまいます。

オンプレミスでは、技術的な遅れはPrepareで始まります。クライアントとパートナーがインフラを構築するからです。要員の確約は書面で取ってください。口頭の「対応できます」は消えてなくなります。

Exploreでは記録が重要です。判断とその責任者が書き残されていなければ、6か月後には、なぜ返品がその方法で処理されるのか誰も覚えていません。

Realizeは最も長いフェーズで、超過の大半がここで起きます。たいていはExploreで楽観的なギャップ一覧が作られたことが原因です。最初の移行リハーサルは失敗します。本番ではなくテストで失敗させる必要があるのです。

Deployには、正確な手順、時刻、責任者を書いたカットオーバー計画が必要です。「データを移行する」は手順ではありません。

2023年の米国のヘルスケアのプログラムでは、クライアントがスケジュールより3か月遅れ、200万ドルの予算超過に直面していました。私たちはSAP ActivateのFit-to-Standardワークショップを使って計画を立て直しました。チームは、カスタマイズなしで運用できるプロセスを28個見つけました。

そのプロジェクトマネージャーの言葉です。「SAPにすでにあるものを設計するのに、何か月も無駄にしていました。」6週間以内に、スケジュールどおりの状態に戻りました。

2024年の欧州の小売業のプログラムでは、クライアントは自社のニーズの70%がSAPの標準プロセスで満たされることに気づきました。実際にシステムが動くのを見るまで、大規模なカスタマイズを計画していたのです。

Clean Coreはこの効果を強めます。パブリックエディションでは標準プロセスしか選択肢がなく、拡張はSAP BTPかリリース済みAPIの上に置かれます。プライベートエディションとオンプレミスでは今も修正ができますが、すべてのギャップにコストを伴う拡張の判断が必要になれば、カスタマイズの議論はより正直なものになります。

業界ごとに特有の負荷が加わります。以下の期間は複数拠点にわたるS/4HANAの全社プログラム全体を対象にしたものなので、9〜18か月という単一のRISE導入よりも長くなります。

業界	計画期間	期間を延ばす要因
製造業	14〜20か月	部品表と作業手順の品質、MRPの調整、QMの要件
小売・消費財	12〜18か月	POS連携、マスタデータの量、繁忙期の時間枠
医薬品	16〜22か月	GxPバリデーション、バッチのトレーサビリティ、シリアル化
公益事業	15〜20か月	機器管理、料金体系、GISとSCADAとの連携
公共部門	18〜24か月	基金会計、調達規制、承認の負担、データ所在地の要件
自動車	16〜22か月	ジャストインタイムのサプライチェーン、技術変更管理
航空宇宙・防衛	20〜26か月	政府への報告、プログラム会計、セキュアなサプライチェーン
石油・ガス	18〜24か月	共同事業会計、資産集約型の操業
金融サービス	14〜20か月	職務分掌に基づくロール設計、規制対応のバリデーション

AIツールが変えること、変えないこと

SAP Joule for Consultantsは2025年に一般提供になりました。SAP Notesを含むSAP独自のナレッジベースから設定に関する質問に答え、ABAPコードを説明します。2024年3月から一般提供されているSAP Build Codeは、Jouleを使ってSAP BTP上のJavaとJavaScriptの拡張コードを生成します。

どちらも個々のコンサルタントや開発者の助けにはなります。どちらも、ワークショップ、意思決定、データクレンジング、ユーザー受け入れにかかる期間は変えません。これらを使う前提で計画するのは構いませんが、自社のチームで効果を測るまでは、計画から何週間も削らないでください。

私が毎週のプログラム会議の議題に載せているリスクです。どれも、月次のステアリングコミッティまで放置すると期日が動きます。

1. 遅いスコープ変更。 スコープはExploreの終わりに確定します。それ以降は、変更管理委員会が、スケジュールと予算への影響を添えたうえで、すべての変更を承認します。
2. データ品質。 多くの企業は計画段階でデータ評価を省きます。質の悪いデータは、移行リハーサルが失敗する最も一貫した原因です。
3. 要員のボトルネック。 部門長から、名前のある担当者と日程について書面での確約を取ってください。重要な役割にはすべて代わりの人を育てます。
4. 意思決定の遅れ。 スコープをめぐる意見の対立は48時間以内にエスカレーションします。判断を月次のレビューまで溜め込まないでください。
5. 遅れたチェンジマネジメント。 エンドユーザーとの対話は、本稼働の2週間前ではなく、Prepareで始めます。

ツールについて言えば、SAP Cloud ALMは導入管理のためのSAPのプラットフォームです。SAP Solution Manager 7.2のメインストリームメンテナンスは2027年末に終了し、一部の機能については2030年まで延長メンテナンスがあります。SAP Best Practices Explorerは2023年に提供を終了し、そのプロセスコンテンツは現在SAP Signavio Process Navigatorにあります。

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

SAP S/4HANAの導入にはどれくらいかかりますか？

私の経験では、GROW with SAP（パブリックエディション）で6〜9か月、RISE with SAP（プライベートエディション）で9〜18か月です。ECCからの場合、ブラウンフィールド変換や選択的データ移行は12〜18か月、グリーンフィールド導入は18〜24か月かかります。

SAP Activateの各フェーズにはどれくらいかかりますか？

計画の出発点としては、Discoverが2〜4週間、Prepareが3〜6週間、Exploreが4〜8週間、Realizeが8〜16週間、Deployが2〜4週間、Runが4〜8週間のハイパーケアです。大規模なプログラムで最も延びるのはRealizeです。

RISE with SAPはスケジュールにどう影響しますか？

RISEではインフラの責任がSAPに移るので、Prepareフェーズの作業の一部がなくなります。データ移行、テスト、教育、意思決定は短くなりません。時間の大半が消えるのはそこです。Clean Coreの規律がカスタム開発を始まる前に止められれば、Realizeを短くできます。

SAP導入のスケジュールにはどれくらいのバッファを入れるべきですか？

ベンダーの見積もりに15〜20%のバッファを上乗せしてください。期日は、スコープとギャップが見えるExploreの終わりに確定し、そのことをキックオフの前に取締役会に伝えます。

SAP導入のスケジュールを短縮するにはどうすればよいですか？

Fit-to-Standardを徹底してください。避けたカスタマイズの1つひとつが何週間もの節約になります。データクレンジングはDiscoverで始め、業務部門の要員は兼務で借りるのではなく専任で充てます。カットオーバー計画は、Realizeの後ではなく、Realizeの間に準備します。

SAPの展開はビッグバンと段階導入のどちらを選ぶべきですか？

ビッグバンは、すべてを一度に本稼働させます。全体としては速いもののリスクが高く、スコープが小さい場合や、チェンジマネジメントが強い組織に向いています。段階導入は、モジュール、拠点、事業部門ごとに進めます。リスクは低く期間は長くなり、複数の事業体を抱える大規模なグループに向いています。

SAPプロジェクトが遅れる最も多い原因は何ですか？

管理されていない変更要求、データ品質の想定外の問題、遅れたチェンジマネジメント、サードパーティとの連携の不具合、プロジェクト途中での主要メンバーの離脱、ステアリングコミッティの遅い意思決定です。多くのチームが驚くのはデータ品質です。誰もがレガシーデータはきれいだと思い込んでいますが、まずきれいではありません。

SAPの本稼働後のハイパーケアはどれくらいの期間ですか？

4〜8週間のハイパーケアを計画してください。現場サポート、日次の課題トリアージ、パフォーマンス監視を行います。その後、システムはアプリケーションサポートチームか社内のCentre of Excellenceに移管されます。