本文へスキップ

S/4HANA移行のスケジュールとプロジェクト計画:アプローチ別

ECCからS/4HANAへの移行が各アプローチでどれだけかかるか、SAP Activateの各フェーズでプロジェクト計画に何を含めるか、そして移行スケジュールがどこで遅れるかを解説します。

付箋で描いた移行ロードマップが壁に貼られ、カレンダーのカットオーバー週末に丸印が付いた明るいプロジェクトルーム
目次
  1. アプローチ別のS/4HANA移行スケジュール
  2. フェーズ別のS/4HANA移行プロジェクト計画
  3. アプローチによって計画はどう変わるか
  4. ブラウンフィールド:テストコンバージョンを軸に計画する
  5. グリーンフィールド:設計とデータロードを軸に計画する
  6. 選択的データ移行:データ範囲を軸に計画する
  7. S/4HANA移行のスケジュールが遅れる箇所
  8. カットオーバーとダウンタイム:時間枠は早めに計画する
  9. 計画についてSAPとパートナーに尋ねるべき質問
  10. 私が次にすること
  11. よくある質問

私の経験では、SAP ECCからのS/4HANA移行のスケジュールは、ブラウンフィールドのシステムコンバージョンで12から18か月、グリーンフィールドの新規導入で18から24か月です。選択的データ移行は12から18か月かかります。プロジェクト計画はSAP Activateの6つのフェーズに沿い、最も超過しやすいフェーズはカスタムコードです。

結論から言えば、計画はSAP Readiness Checkから始め、工数の30から40%をデータに充ててください。ブラウンフィールドでは模擬コンバージョンを3回計画し、カットオーバーのダウンタイムは週末1回から1週間までを見込んでください。

この記事は、アプローチとECCの期限を扱った私のECCからS/4HANAへの移行ガイドを、スケジュールと計画の観点から掘り下げたものです。ECCからの移行ではなくSAPを新たに導入する場合は、フェーズごとの期間を含めて私のSAP導入スケジュールガイドで解説しています。

期間を決めるのはアプローチです。私のルールはこうです。他のシステムから移る場合や新しいプロセスを定義する必要がある場合はグリーンフィールド。プロセスが定義され機能している場合はブラウンフィールド、一部の領域のプロセスを再定義する必要がある場合は選択的データ移行です。

私が見てきたプログラムで各アプローチにかかった期間と、期間が延びる主な要因は次のとおりです。

アプローチ一般的な期間計画の軸期間が延びる主な要因
ブラウンフィールド(システムコンバージョン)12から18か月Software Update Managerで既存のECCシステムを変換し、テストコンバージョンを繰り返すカスタムコードの適応とビジネスパートナーへの変換
グリーンフィールド(新規導入)18から24か月Fit-to-Standardによる設計、構築、データロードサイクルの繰り返し長い要件リストに膨らむExploreワークショップと、データクレンジング
選択的データ移行12から18か月どの会社コード、組織単位、履歴を移すかの合意と、専門ツールデータ範囲の確定と、専門パートナーへの依存

アプローチと同じくらい重要なのがカレンダーです。エンハンスメントパッケージ6から8のECCでは、メインストリームメンテナンスが2027年12月31日に終了します(SAP News)。今月始めたブラウンフィールドは2027年10月から2028年4月の間に本稼働し、今始めるグリーンフィールドは2028年にずれ込みます。

つまり、今作られている計画の多くは、ある程度の延長メンテナンスを予算に含める必要があります。2年目に驚くのではなく、最初から組み込んでください。

RISE with SAPは商用パッケージであり、移行アプローチではありません。RISEのもとでのブラウンフィールドや選択的データ移行の移行先はSAP Cloud ERP Privateです。これは、多くの人がいまもS/4HANA Cloud Private Editionとして検索しているものを指すSAPの現在の名称です。私がGROW with SAPについて示す6から9か月、RISEについて示す9から18か月は新規導入の場合であり、ECCからの移行には当てはまりません。

SAP ActivateはS/4HANA向けのSAPの導入方法論です。Discover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズがあります(SAP Activate)。

移行でも同じフェーズを使います。変わるのは各フェーズの中身です。

移行プロジェクト計画

  1. Discover

    Readiness Check、アプローチの決定、ビジネスケース。

  2. Prepare

    計画、ガバナンス、チーム、最初のサンドボックス。

  3. Explore

    Fit-to-Standardまたは差分設計、WRICEFリストの合意。

  4. Realize

    構築、カスタムコード、データロード、テストコンバージョン。

  5. Deploy

    最終リハーサル、カットオーバー、本稼働。

  6. Run

    ハイパーケア、安定化、ECCの廃止。

移行の場合に各フェーズに含まれる作業と、アプローチによる違いは次のとおりです。

フェーズ移行で行うことアプローチによる違い
DiscoverSAP Readiness Check、アプローチの決定、ビジネスケース、カスタムコードとデータの初期把握選択的データ移行では、ここで最初のデータ範囲が必要
Prepare計画、ガバナンス、チーム、データオーナーシップ、サンドボックスブラウンフィールドは最初のサンドボックスコンバージョンを実施。グリーンフィールドはシステムとワークショップの日程を準備
ExploreFit-to-Standardワークショップまたは差分設計、WRICEFリストの合意、データマッピンググリーンフィールドが最も時間を使うフェーズ。ブラウンフィールドは該当する簡素化項目に対応
Realize構築、カスタムコードの適応、データロードサイクル、テストラウンドブラウンフィールドは模擬コンバージョンを実施。グリーンフィールドはロードサイクルを実施し、通常はMigration Cockpitを使用
Deploy最終リハーサル、カットオーバー、本稼働ダウンタイムの時間枠はアプローチ、データ量、手法によって決まる
Runハイパーケア、安定化ECCを廃止し、残すものをアーカイブ

WRICEFは、ワークフロー、レポート、インターフェース、コンバージョン、拡張機能、フォームの頭文字です。SAP標準を超えて構築するものすべてのリストであり、注視すべき数字です。

私が主導または立て直した21のSAPプログラムを通じて、最大の誤りは導入の開始時にきちんと計画しないことでした。Prepareでは、誰がデータクレンジングを担当するか、どのカスタムコードを廃止するか、各テストコンバージョンとリハーサルをいつ行うかを合意してください。それらの日付が計画の背骨になります。

ブラウンフィールド:テストコンバージョンを軸に計画する

ブラウンフィールドの計画は、コンバージョンのサイクルを軸に組み立てます。Software Update Managerがシステムを変換し、テストのたびに本番の変換にどれだけかかるか、何が壊れるかが分かります。

ブラウンフィールドでは、カットオーバー前に3回の模擬コンバージョンを計画します。時間の計測に意味を持たせるため、どの回も本番環境の最新コピーで実施すべきです。最後の回は本稼働と同じように進めてください。同じ手順、同じメンバー、同じチェックです。

ダウンタイム最適化アプローチについてのSAP自身の計画も同様です。サンドボックスでの実行、品質保証環境での実行、クローンでのロード検証、最終リハーサルを定めています(SAP Learning)。SAPは、技術的には回数を減らせるもののリスクが高まると述べています。

グリーンフィールド:設計とデータロードを軸に計画する

グリーンフィールドの時間はExploreに費やされます。Fit-to-StandardワークショップでSAP標準をどこまで採用するかを決め、ギャップはすべて、構築、テスト、保守が必要なWRICEFオブジェクトになります。

データはロードサイクルで移し、通常はSAP S/4HANA Migration Cockpitを使います。完全なロードサイクルを数回計画し、そのたびに業務部門が承認する照合を行ってください。ステージングテーブル、移行オブジェクト、ロード手順は、私のMigration Cockpitの手順ガイドで解説しています。

選択的データ移行:データ範囲を軸に計画する

選択的データ移行の計画は、データ範囲から始まります。どの会社コード、事業単位、何年分の履歴を移すのか、そしてどのプロセスを再設計するのかです。

その範囲が、ツール、専門パートナー、テストサイクルを決めます。後から変えれば、スケジュールも一緒に動きます。

私の経験では、最も超過しやすいフェーズはカスタムコードです。移行で最も見落とされやすい隠れたコストでもあり、これは私のS/4HANA移行コストガイドで扱っています。

私が注視する箇所を順に挙げます。

  1. カスタムコード。 チームはレポートを見て範囲を見積もり、修正を始めてから本当の規模に気づきます。あるプログラムでは、smartShiftによる分析でカスタムオブジェクトが18,000から3,200に減りました。まず廃止し、次に適応させます。
  2. アセスメントが見落としたカスタムオブジェクト。 私の経験では、SAP Readiness Checkが見落としたカスタムオブジェクトこそ、後で痛手になります。その結果をスコープとして扱う前に、私のSAP Readiness Checkガイドをお読みください。
  3. データ。 データ移行は工数の30から40%を占めます。クレンジングに担当者がいないと開始が遅れ、テストサイクルを圧迫します。詳しくは私の記事SAPのデータ移行が失敗する理由をご覧ください。
  4. Explore。 WRICEFリストが膨らむにつれ、予算はExploreで打撃を受けます。ベンダーがスコープを握っていると、ベンダー側にはその膨張を止める理由が誰にもありません。
  5. 時間節約のために削られたリハーサル。 日程を守るために省いたリハーサルは、節約した以上の時間を本稼働の週末に奪いがちです。

私の考えでは、本稼働日はWRICEFリストとカスタムコードの範囲が分かるExploreの終わりに確定すべきです。キックオフで決めた日付は、取締役会向けのプレゼン資料が付いた推測にすぎません。

私の経験では、最も超過しやすいフェーズはカスタムコードであり、最も見落とされやすい隠れたコストでもあります。

私が見てきたカットオーバーのダウンタイムは、週末1回から1週間までです。データ量、コンバージョンの手法、同時に本稼働するエンティティとインターフェースの数、業務部門が検証できる速さによって変わります。

ブラウンフィールドについては、SAPはSoftware Update Managerでダウンタイム最適化コンバージョンのアプローチを提供しています。本番環境を稼働させたまま、データの変換と移行の一部をアップタイム中に行うものです。

ただし、ただで手に入る時間ではありません。SAPは、追加のテスト実行、より複雑な計画、ダウンタイム前のカスタマイジングと開発の凍結、この手法の訓練を受けた専門家を挙げています。

ですから、技術的な手法を選ぶ前に、業務部門が許容できるダウンタイムを合意してください。そして本稼働の週末ではなく、模擬コンバージョンでそれを実証してください。カットオーバーは月次決算と繁忙期を避けて設定してください。

計画の質は、その前提の質で決まります。誰かが署名する前に、私なら次の質問をします。

  1. 計画はどのアプローチを前提にしているか。当社のReadiness Checkの結果のどこがそれを裏付けているか。
  2. 使用状況の分析後、範囲に入るカスタムオブジェクトはいくつか。そのうちいくつを廃止するか。
  3. データクレンジングの担当は誰か。どのフェーズで始めるか。
  4. 模擬コンバージョンまたはロードサイクルを何回計画しているか。どのデータで実施するか。
  5. 計画はどれだけのダウンタイムを前提にしているか。どのテスト実行でそれを実証するか。
  6. 日付はいつ確定するか。ExploreでWRICEFリストが膨らんだら日付はどうなるか。

パートナーには、自社と似たプログラムの事例と、ハイレベル設計を求めてください。回答が一般論ばかりで自社の業務に即していなければ、危険信号と受け止めてください。

今四半期中にSAP Readiness Checkを実行してください。誰かが本稼働日を約束する前に、カスタムコードとデータに関する結果をCFOとプログラムディレクターに提示してください。

そのうえで、許容できるカットオーバーの時間枠から逆算して計画を組み立ててください。ブラウンフィールドなら模擬コンバージョンを3回、ほかのアプローチならそれに必要なロードサイクルを入れます。まずアプローチそのものを検証したい場合は、私のグリーンフィールドとブラウンフィールドの移行アセスメントをお試しください。

私はこのような移行計画の作成と厳密な検証を支援しています。独立した視点が必要でしたら、ご連絡ください。

S/4HANA移行にはどれくらいの期間がかかりますか?

私の経験では、ECCからのブラウンフィールドのコンバージョンは12から18か月、グリーンフィールドの新規導入は18から24か月、選択的データ移行は12から18か月かかります。最も超過しやすいフェーズはカスタムコードで、データ移行は工数の30から40%を占めます。

S/4HANA移行のプロジェクト計画にはどのようなフェーズがありますか?

計画はSAP ActivateのDiscover、Prepare、Explore、Realize、Deploy、Runに沿います。移行の場合、DiscoverにはReadiness Checkとアプローチの決定、Realizeにはカスタムコード、データロード、テストコンバージョン、Deployには最終リハーサルとカットオーバーが含まれます。

S/4HANAのブラウンフィールド移行には模擬コンバージョンが何回必要ですか?

ブラウンフィールドでは、カットオーバー前に3回の模擬コンバージョンを計画します。SAPはダウンタイム最適化アプローチについて、サンドボックスでの実行、品質保証環境での実行、ロード検証、最終リハーサルを定めており、回数を減らすとリスクが高まると述べています。

S/4HANAのカットオーバーのダウンタイムはどれくらいですか?

私が見てきたカットオーバーのダウンタイムは、週末1回から1週間までです。データ量、コンバージョンの手法、同時に本稼働するエンティティとインターフェースの数によって決まります。SAPのダウンタイム最適化コンバージョンは作業の一部をアップタイム中に移しますが、より多くのテスト実行と計画が必要です。

2027年のECCサポート終了前にS/4HANA移行を終えられますか?

エンハンスメントパッケージ6から8のECCのメインストリームメンテナンスは、2027年12月31日に終了します。2026年10月に始めたブラウンフィールドは2027年10月から2028年4月の間に本稼働し、グリーンフィールドは2028年になります。今始めるプログラムの多くは、ある程度の延長メンテナンスを予算に含めるべきです。

S/4HANA移行プロジェクトを最も遅らせるものは何ですか?

私の経験では、最も多いのはカスタムコードの超過です。次いで、開始が遅れるデータクレンジングと、Exploreで膨らみ続けるWRICEFリストです。その多くの根本原因は、プログラムの開始時にきちんと計画しないことです。

Noel D'Costa

執筆者

Noel D'Costa

航空、政府、金融、小売、製造の各分野で、SAPとOracleのERPプログラムに25年携わってきました。財務出身です。経営陣とともに変革の範囲を誠実に定め、難航するプログラムを立て直し、本稼働後の最初の1年を乗り越えるシステムを構築します。

次のステップ

いまERPプログラムを進めていますか?

この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。