ECCやSAP ERP 6.0を利用している企業では、保守条件への対応と、業務・データ・周辺システムを含めた基幹システム刷新を切り離して考えることはできません。一方で、S/4HANAへの移行は単なるデータベース更改ではなく、既存資産をどこまで引き継ぎ、どの業務を標準化するかを決める経営・業務・ITの横断プロジェクトです。
この記事では、S/4HANA・ECC・SAP HANAの違い、保守条件の確認方法、移行方式、費用構造、工程、リスク、調達の考え方を順に解説します。保守確認から方式の一次選定、予算化と構想・調達の開始判断までを整理できます。
S/4HANA移行は、製品と基盤の整理から始め、保守・契約、方式、費用、工程、調達をつなげて検討します。
01SectionSAP S/4HANA・ECC・SAP HANAを混同しない
移行の検討では、製品、データベース基盤、導入形態、移行方式を分けて整理することが重要です。これらを混同すると、「HANA化したからS/4HANA移行は不要」「クラウド化すれば移行方式は決まる」といった誤解につながります。
S/4HANAはERP、SAP HANAはデータベース基盤
SAP S/4HANAは、会計、販売、購買、生産などの基幹業務を扱うERPです。SAP S/4HANA Help Portalでも、SAP HANAデータベースに基づくERPソリューションとして案内されています。
これに対しSAP HANAは、データを保存・処理するデータベース／データ処理基盤です。したがって、ECCのデータベースをSAP HANAへ移すことと、ERPアプリケーションをS/4HANAへ移すことは同じ作業ではありません。S/4HANA移行では、データモデル、業務プロセス、拡張、連携、操作設計なども確認対象になります。
ECCは、SAP ERP 6.0を含む従来のSAP ERP環境を指す実務上の呼称として使われます。本記事では、ECCからS/4HANAへの移行を検討する企業を主な対象とします。
移行検討で使う重要用語
モジュールと会社コード
モジュールは会計・販売・購買・生産など業務領域ごとの機能群です。会社コードは、SAPで会計上の独立単位として扱う組織設定を指します。
アドオンとカスタムコード
アドオンは標準機能を補う個別開発です。カスタムコードは、企業固有の要件に対応するために作成・変更したプログラムコードを指します。
インターフェースとバッチ処理
インターフェースは周辺システムとデータを送受信する連携の仕組みです。バッチ処理は夜間や月次などに自動実行する定期処理です。
Fit to Standard
標準機能を基準に業務を確認し、標準に合わせる範囲と例外要件を決める進め方です。
カットオーバーとハイパーケア
カットオーバーは旧システムから新システムへ本番運用を切り替える一連の作業です。ハイパーケアは稼働直後に問い合わせや障害へ集中的に対応する安定化期間です。
ECCとの違いが移行判断に影響する領域
S/4HANAへの移行で確認すべきなのは、機能差だけではありません。現行のアドオン、帳票、インターフェース、バッチ、権限、データ品質が、標準機能や新たな業務設計とどのように整合するかを検証する必要があります。
また、移行による業務標準化やデータ活用の効果は、製品を入れ替えるだけで自動的に得られるものではありません。例外業務の扱い、データ定義、利用者教育、運用責任を設計して初めて、効果を評価できる状態になります。
導入形態と移行方式は別の判断軸
Public Cloud、Private Cloud、オンプレミスなどの導入形態は、運用責任、拡張、更新、選択可能な移行経路に影響します。一方、グリーンフィールド、ブラウンフィールド、選択的移行は、「何を再利用し、何を再設計・移行するか」の方針です。
つまり、クラウド化とブラウンフィールド移行は同義ではありません。導入形態を前提に利用可能な移行経路を確認しつつ、資産・業務・データの状況から移行方式を検討します。製品仕様や利用可能な経路は更新され得るため、重要な判断前に公式情報で対象条件を確認してください。
02Sectionまず保守・契約上の節目と移行緊急度を確認する
移行の開始時期は、SAPが公開する保守方針だけで決めるべきではありません。まず公開方針を判断材料として把握し、そのうえで自社の契約、製品構成、事業上の節目を確認します。保守方針、製品仕様、移行経路は変更され得るため、各リンク先の閲覧時点を記録し、重要な判断前に再確認してください。
公開保守方針と個社契約は分けて確認する
SAP Business Suite 7の保守方針では、SAP Business Suite 7コアアプリケーションの最新3つのEHPを対象に、主流保守を2027年12月31日まで、任意の延長保守を2028年1月1日から2030年12月31日までと案内しています。対象にはSAP ERP 6.0、SAP CRM 7.0、SAP SCM 7.0、SAP SRM 7.0、SAP Business Suite powered by SAP HANAの各コアアプリケーションが含まれます。重要な判断前には、公式ページで最新の対象条件を確認してください（本記事の確認基準日: 2026年8月）。
同方針では、延長保守について対象範囲の保守ベースに2パーセントポイントのプレミアムが示されています。ただし、これは公開方針上の説明です。古いEHP、対象外コンポーネント、自社契約への適用可否、延長保守の選択可否、実際の費用を一律に判断する根拠にはなりません。
公開方針の一般日付だけで、自社の移行期限を決めない
自社に適用される保守終了日や延長保守の可否は、契約条件と利用製品によって異なります。利用製品、EHP、SAP_APPLリリース、対象外コンポーネントを確認し、契約書、SAP for Me、SAP窓口で対象範囲・適用日・費用を確認してから逆算計画の起点を置いてください。
保守方針と、移行以外も含めた対応の選択肢を確認したい場合は、SAP 2027年問題と企業が検討すべき選択肢も参照してください。
移行緊急度は期限だけで決めない
ECC維持、S/4HANA移行、他ERPへの刷新を比較する際は、保守条件に加えて、組織再編、拠点統合、周辺システム更改、データ活用、現行資産の属人化といった事実を並べます。保守の節目が先でも、業務変更や周辺更改が迫っているなら、構想・影響分析を先行させる合理性があります。
移行判断で先にそろえる5つの事実
利用製品・EHP・契約上の保守条件
製品名、EHP、SAP_APPLリリース、契約上の保守終了日、延長保守の可否・費用、対象外コンポーネントを確認します。
移行目的と対象範囲
期限対応、業務標準化、組織統合、データ活用などの優先順位と、対象となる会社コード、拠点、モジュール、利用者、段階展開の要否を仮置きします。
履歴データと監査・参照方針
マスタ、残高、未決済取引、履歴、アーカイブ、旧システム参照の扱いを分けて検討します。
停止制約と事業上の節目
月次・年次締め、繁忙期、法定対応、許容停止時間、復旧目標を確認します。
発注者の意思決定・テスト・教育体制
業務責任者、データ所有者、テスト責任者、スポンサー、参加工数と代替要員を確保できるか確認します。
03Section移行方式は「何を残し、何を変えるか」で一次選定する
移行方式は、技術的な経路だけでなく、業務変革の度合い、既存資産の扱い、データ方針、停止制約で選びます。SAPのPrivate Edition向け資料では、新規導入、システム変換、選択的移行を異なる移行経路として説明しています。SAPの移行経路に関する解説は、方式の定義を確認する際の参考になります。
3方式を共通軸で比較する
移行方式は名称で選ぶのではなく、業務変革、既存資産、データ方針、統合・再編の必要性を同じ軸で比較します。
以下は、SAPのPrivate Edition向け資料で整理されている新規導入、システム変換、選択的移行を、一次選定向けに比較したものです。導入形態や対象製品によって利用できる経路・条件は異なるため、SAPの移行経路に関する解説で対象条件を確認してください。
| 比較軸 | グリーンフィールド（新規導入） | ブラウンフィールド（システム変換） | 選択的移行（Selective Data Transition） |
|---|---|---|---|
| 変革度 | 高い。標準機能を基準に業務を再設計する。 | 低〜中。既存プロセスを活用しやすい。 | 中〜高。領域ごとに再利用と再設計を組み合わせる。 |
| 既存資産の再利用 | 設定・開発資産を選別し、再設計する。 | データ、プロセス、カスタムコードを活用しやすい。 | 設定、開発、マスタ、取引データを選択して扱う。 |
| 業務変更 | 標準化原則と例外業務の承認が必要。 | 変更を抑えやすい一方、簡素化項目への対応が必要。 | 対象領域ごとに異なり、統合後の業務設計が必要。 |
| データ方針 | 移すマスタ・残高・未決済取引を設計し、履歴は別参照も検討する。 | 既存データを継承しやすい。 | 会社・拠点・期間・データ種別を選択して設計する。 |
| 適する条件 | 業務標準化、統合、抜本再設計を優先する。 | 現行業務が安定し、資産再利用や期限対応を優先する。 | 複数ERP統合、事業再編、段階移行、データ選別が重要である。 |
| 慎重にすべき条件 | 例外業務が多い、業務側が設計に参加できない、履歴参照方針が未定。 | 未把握のアドオン・連携・権限が多い、現行の課題を持ち込みやすい。 | 対象範囲、データ方針、移行後運用、責任分界が曖昧。 |
| 主なリスク | 例外要件の増加、業務受入不足、旧システム参照の設計漏れ。 | カスタムコード・連携・データ品質の影響漏れ、テスト不足。 | データ整合性、切替順序、ツール起因の障害切り分け。 |
| 初期判断事項 | 標準化原則、例外承認者、移行データ、展開方針。 | 変換対象、改修優先順位、履歴継承、後続変革の範囲。 | 移す会社・拠点・データ、統合順序、並行運用、責任分界。 |
この表は方式を確定するためではなく、詳細調査に進む一次候補を絞るためのものです。導入形態によって選択可能な経路や制約が変わり得るため、対象製品・導入形態の条件も別途確認します。
判断フローで一次候補を絞る
方式の一次候補を絞る5つの順序
- Step01
標準化・再設計の優先度を確認する
組織統合や業務標準化、抜本的な再設計が最優先なら、グリーンフィールドを一次候補に置きます。
- Step02
既存資産と履歴データの継承範囲を確認する
現行業務、組織、履歴データを広く継承し、資産再利用を優先するなら、ブラウンフィールドを比較候補にします。
- Step03
統合・再編・段階移行の必要性を確認する
複数ERPの統合、会社・拠点単位の段階移行、事業再編、データ選別が主題なら、選択的移行を比較候補にします。
- Step04
導入形態との整合を確認する
Public Cloud、Private Cloud、オンプレミスの前提を置き、利用可能な移行経路、拡張・運用の制約を確認します。
- Step05
未確認の資産・データ・停止制約を確認する
資産一覧、データ方針、停止可能時間のいずれかが未確認なら、方式を確定せず、構想・影響分析を先行します。
方式確定前に行う影響分析
ブラウンフィールドでも、カスタムコード、連携、権限、データ、テストへの影響確認は省略できません。グリーンフィールドでも、履歴参照や例外業務の扱いを後回しにすると、受入や切替の段階で課題が顕在化します。
選択的移行は、設定、開発資産、マスタ、取引データなどを選択して移行・変換する考え方です。複数ERP統合や事業再編に適合する場合がありますが、対象選別と照合方法を先に定める必要があります。
選択的移行は、ツールと責任分界を確認してから比較する
SAPのPrivate Edition向け資料では、選択的移行で用いる第三者の製品・サービスはSAPが認証せず、非SAPツールに起因する不整合はSAP Support Agreementsの対象外と説明されています。採用手法、対象データ、照合方法、障害の一次切り分け、是正作業、費用負担、成果物は、RFI／RFPと契約で確認してください。
04Section費用は総額相場ではなく、総額定義と見積条件で判断する
S/4HANA移行の費用は、対象会社・業務・拠点、方式、導入形態、アドオン・連携、データ、支援範囲で大きく変わります。公開情報だけでは同じ条件での総額比較が難しいため、根拠がそろわない総額相場ではなく、何を総額に含めるかを先に定義します。
目安の幅として、海外の民間調査・公開事例（2026年8月時点の公開情報）では、対象範囲を限定した中堅規模の移行で数千万円規模から、複数法人・グローバル展開を伴う大企業の全面刷新では数十億円規模まで変動するとされています。主な変動要因は、対象会社・業務の範囲、移行方式（新規導入・システム変換・選択的移行のいずれか）、アドオン・カスタムコードの数と改修方針、連携・データ移行の量、支援範囲です。この幅は個別案件の予算根拠にはならないため、必ず以下の総額定義と見積条件をそろえて確認してください。
初期費用・継続費用・発注者工数・予備費を分ける
見積もりは合計額だけで比較せず、費用区分と前提・除外条件をそろえることが重要です。
| 費用層 | 代表費目 | 見積比較で固定する条件 | 計上区分 |
|---|---|---|---|
| 構想・影響分析 | 資産棚卸し、方式評価、ロードマップ、RFP支援 | 対象会社・業務・資産調査の範囲、成果物、委託範囲 | 初期費用 |
| ソフトウェア契約 | ライセンス、サブスクリプション、保守、契約変更 | 製品構成、利用者・利用量、既存契約との差分、契約期間 | 初年度継続費用。導入時の契約変更作業は初期費用として分離 |
| 基盤 | 環境構築、ネットワーク、監視、バックアップ、DR | 導入形態、性能・可用性、復旧要件、運用責任分界、契約期間 | 環境構築は初期費用、利用料・運用は初年度継続費用として分離 |
| 導入・設定 | 要件定義、設計、設定、開発、PMO | 対象モジュール、会社・拠点、成果物、委託範囲 | 初期費用 |
| アドオン・連携 | カスタムコード、帳票、API・ファイル連携、周辺改修 | 難度、仕様書・所有者の有無、利用実績、テスト範囲 | 初期費用 |
| データ | 調査、クレンジング、変換、移行、照合、アーカイブ | 対象データ、保存年限、品質、リハーサル回数、旧システム参照方針 | 初期費用 |
| テスト・教育 | テスト環境、シナリオ、性能・復旧試験、教育、マニュアル | 対象業務、利用者、教育形態、受入基準 | 初期費用 |
| 安定化 | カットオーバー、ハイパーケア、障害対応、運用引継ぎ | 支援期間、対応時間、完了基準、通常運用への移管条件 | カットオーバー・初期支援は初期費用、継続運用支援は初年度継続費用として分離 |
| 発注者工数 | 業務設計、データ承認、テスト、教育、PMO、代替要員 | 部門別の参加人数・時期・社内単価または原価の扱い | 発注者工数 |
| 予備費 | 未確定要件、データ品質、追加テスト、変更要求への備え | 発動条件、承認者、上限、未使用時の扱い | 予備費 |
総額は、初期費用・初年度継続費用・発注者工数・予備費を分けて比較します。比較時には、除外費目、契約期間、税、旅費、為替、変更要求の扱いも別欄でそろえます。
SAP S/4HANAの製品情報はSAP公式製品ページで確認できますが、個別の契約価格は製品構成や利用条件により変わります。公式窓口または個別見積もりで確認してください。
見積比較で固定すべき前提
見積依頼でそろえる条件
- ✓
対象会社・拠点・業務・モジュール・利用者を明記する
対象外の会社や業務も併記し、範囲差を見分けられるようにします。
- ✓
移行方式と導入形態の前提、未確定事項を分けて示す
方式を確定していない場合は、比較してほしい候補と追加調査事項を明記します。
- ✓
アドオン、帳票、連携、バッチ、データの現状を共有する
数量だけでなく、所有者、仕様書の有無、利用頻度、履歴年数も示します。
- ✓
停止制約、繁忙期、品質基準、委託範囲をそろえる
テスト、教育、カットオーバー、安定化のどこまでを依頼するか明確にします。
- ✓
費目別金額、継続費用、前提・除外、変更管理を同じ様式で求める
合計額だけでなく、追加費用が発生する条件と再委託の範囲も確認します。
投資効果は削減額だけで評価しない
投資判断では、保守・運用のリスク、業務標準化、データ活用、現行資産の属人化、将来の組織再編や周辺更改への対応力も評価対象になります。効果を過大に見積もらないためには、「どの業務で、誰の作業が、どの条件で変わるか」を業務部門と確認し、初期費用とは別に継続的な運用負荷も評価します。
05Section工程はゲートを置き、保守・事業上の節目から逆算する
移行計画では、本番稼働日だけを置くのでは不十分です。構想、方式決定、要件合意、移行リハーサル、受入、Go／No-Go、安定化までに完了すべき条件をゲートとして設定します。一律の期間ではなく、依存関係と完了基準から開始時期を決めます。
構想から安定化までの工程ゲート
| 工程 | 主要成果物 | 発注者の決裁事項 | 完了基準の例 | 主な参加部門 |
|---|---|---|---|---|
| 構想・現状分析 | 資産棚卸し、課題一覧、対象範囲案、保守確認結果 | 調査範囲、スポンサー | 未確認領域、所有者、調査計画が明確 | 経営、業務、情シス、購買 |
| 方式・投資方針 | 方式比較、導入形態の方向性、データ方針、総額定義 | 一次候補、予算枠、調達方針 | 比較前提、除外項目、重大論点を合意 | 経営、業務、情シス、財務 |
| Fit to Standard・要件合意 | 標準化対象、例外要件、拡張・連携方針、受入基準 | 例外業務、要件凍結方針 | 変更管理とテスト方針を合意 | 業務、情シス、内部統制 |
| 実装・移行準備 | 設定・開発物、移行設計、権限、テスト・教育計画 | 変更要求、データ対象、権限方針 | 重要設計、移行、テスト準備が完了 | 情シス、業務、データ所有者 |
| テスト・教育・リハーサル | テスト結果、照合結果、教育実績、切替・復旧計画 | 受入判定、本番準備可否 | 重要業務の受入、照合、復旧確認を承認 | 業務、情シス、運用、監査 |
| 本番Go／No-Go | 判定資料、未解決課題、切替体制 | 本番移行可否 | 切戻し準備、要員、連絡体制を確認 | スポンサー、業務、情シス |
| 安定化・引継ぎ | 障害・問い合わせ状況、運用手順、残課題計画 | 通常運用への移管 | 品質指標、残課題責任者、対応期限を合意 | 運用、業務、情シス |
データ移行では、移行対象、マッピング、シミュレーション、進捗管理の設計が必要になります。SAP S/4HANA Migration Cockpitの文書を参照し、対象導入シナリオと製品バージョンにおける適用可否を確認してください。
本番稼働日だけでなく安定化まで逆算する
移行計画は本番稼働日だけで終わらせず、受入、リハーサル、Go／No-Go、安定化の完了条件から逆算します。
保守・事業上の節目から逆算する7段階
- Step01
最終節目を固定する
目標本番稼働日、または契約上確認した保守・事業上の節目を起点にします。
- Step02
安定化の完了条件を置く
問い合わせ、障害、運用引継ぎ、残課題の対応体制が通常運用へ移る条件を決めます。
- Step03
Go／No-Go日を設定する
本番直前ではなく、重大課題の是正、切戻し判断、経営判断に必要な余地を確保した日程にします。
- Step04
リハーサル・受入・教育を逆置きする
総合テスト、業務受入、性能・復旧試験、カットオーバーリハーサル、教育完了をGo／No-Goの開始条件にします。
- Step05
データ整備と改修の完了日を置く
テスト開始前に、移行マッピング、クレンジング、アドオン・連携の改修対象、テスト環境を確定します。
- Step06
方式決定とFit to Standardを逆置きする
実装前に、標準化範囲、例外業務、データ範囲、受入基準、方式・導入形態の方向性を決裁します。
- Step07
構想・調達の開始時期を定める
保守確認、現状調査、RFI／RFP、支援先選定、契約締結に必要な手順を前倒しで配置します。
遅延につながりやすいのは、データ方針、アドオン・連携の影響分析、業務例外の承認、テスト環境・テストデータの準備、業務部門の参加確保です。これらは後工程で短縮しにくいため、構想段階から所有者と承認期限を置いて管理します。
06Section準備度とリスクは、品質基準と責任者まで決める
移行リスクは、技術的な課題だけではありません。データ、業務受入、統制、教育、事業継続の未確認事項を可視化し、作業担当、内容承認者、最終判断者を分けることが重要です。
構想開始前の準備度を確認する
構想・影響分析の開始判定に使う5項目
- ✓
保守・契約条件を確認できている
製品、EHP、契約上の終了日、延長保守の可否・費用、確認窓口と確認日を記録します。
- ✓
対象範囲と現行資産を仮置きできている
対象会社・拠点・モジュールと、アドオン、帳票、連携、バッチの所有者を把握します。
- ✓
データ・統制の論点を把握している
データ所有者、保存年限、履歴参照、監査証跡、権限・職務分掌の確認事項を置きます。
- ✓
停止制約と業務参加の条件を把握している
繁忙期、締め処理、許容停止時間、復旧目標、テスト・教育への参加工数を確認します。
- ✓
意思決定体制を置けている
スポンサー、業務責任者、データ所有者、PM、テスト責任者、Go／No-Goの最終判断者を定めます。
5項目のうち、保守・契約、現行資産、データ・統制のいずれかが未確認なら、実装開始日を決めるより先に構想・影響分析を始めるべき状態です。
主要リスクを品質指標で管理する
カスタムコードは、使用実績と移行適合性を踏まえて対象を分析し、改修・廃止・代替を検討します。カスタムコード移行の公式文書を確認し、利用できる機能や前提条件を自社構成に照らして確認してください。
主要リスクと責任分界の置き方
データ
残高・件数の照合差異、移行エラー、未確定対象を管理します。データ移行チームが作業し、業務データ所有者が内容を承認し、業務責任者とPMが本番可否を判断します。未達時は原因分類、修正、再移行・再照合を行います。
アドオン・連携
所有者不明、仕様不足、改修・連携試験の未完了を管理します。情シス・開発チームが作業し、システム所有者が承認します。未達時は廃止・代替・改修を再判断し、変更管理へ反映します。
業務受入
例外業務の未承認、重要業務シナリオの不合格、テスト不参加を管理します。業務部門が作業と承認を担い、業務責任者・スポンサーが受入と本番可否を判断します。
権限・統制
職務分掌、監査要件、権限承認、統制テストの未完了を管理します。情シス・セキュリティ部門が作業し、内部統制・監査責任者が内容を承認します。未解消なら本番Goの対象外とします。
性能・復旧
応答時間、バッチ時間、復旧試験の結果を管理します。基盤・運用チームが作業し、IT運用責任者が承認します。未達時は容量・設計を見直し、再試験します。
教育
対象者の受講状況、理解度、問い合わせ傾向を管理します。教育担当と業務部門が作業し、業務責任者が定着状況を確認します。未達時は追加教育や教材改訂を行います。
カットオーバー
手順の完成度、リハーサル所要時間、切戻し準備、連絡体制を管理します。切替責任者が作業し、PM・業務責任者が承認し、スポンサーを含む会議体が最終判断します。未達時は手順修正と再リハーサル、必要に応じた移行日見直しを行います。
照合許容値、テスト合格率、復旧目標、停止可能時間は、業務・規制・契約条件によって異なります。外部支援者が作業を担う場合でも、業務データの内容承認や本番移行可否は発注者が担います。
07Section支援先比較は、役割分担とRFI／RFP条件をそろえる
外部支援を活用する場合でも、発注者が保持すべき判断まで委託すると、要件や受入基準が曖昧になりやすくなります。発注者の判断責任と、外部へ委託する専門作業を先に分けてから、RFI／RFPを設計します。
発注者に残す判断と外部へ委託する作業
発注者に残すべき主な判断は、移行目的、対象範囲、業務優先順位、例外業務、データ内容、受入基準、本番Go／No-Goです。経営スポンサー、業務責任者、データ所有者、情報システム、PMO／PM、テスト責任者の役割を明確にします。
外部支援者には、現状分析、方式評価、設計、設定・開発、データ移行、テスト、教育、安定化支援を依頼できます。ただし、業務の優先順位、例外の承認、データの内容承認、受入可否は、発注者の責任として残します。
構想・実装を一括か分離かで比較する観点
構想・影響分析から実装・安定化までを一括で依頼するか、構想と実装を分離するかに一律の正解はありません。期限が厳しく、対象範囲や意思決定者、要求の見通しが一定程度ある場合は、一括での連続性を比較します。
一方、方式、対象範囲、データ方針、例外業務が未確定で、構想成果物を基に実装提案を比較したい場合は、分離発注を比較候補にできます。いずれの場合も、成果物の利用権、引継ぎ、変更管理、責任分界、安定化支援、再委託の扱いをRFPと契約で確認します。
RFI／RFPと提案比較でそろえる条件
RFIは現状・目的・制約・選択肢を把握するため、RFPは調達対象、提案依頼事項、提出物をそろえるために使います。IPAの要求策定ガイドは、重要情報を扱うシステムを対象に、発注者がリスクと要求水準を整理して要求仕様を策定する考え方を示しています。自社の要件整理に応用する際は、対象業務とリスクに合わせて具体化してください。
RFI／RFPに記載する条件
移行目的と優先順位
期限対応、標準化、統合、データ活用などの目的と、優先順位・意思決定の前提を示します。
対象範囲と現行資産
対象会社・拠点・業務・モジュール・利用者、アドオン、帳票、連携、バッチ、データの状況と未確認事項を記載します。
制約とデータ方針
停止可能時間、繁忙期、監査・セキュリティ要件、履歴参照、保存年限、復旧目標を示します。
依頼範囲と成果物
構想、方式評価、実装、テスト、教育、カットオーバー、安定化の依頼範囲と、成果物・引継ぎ条件を定めます。
費用・品質・変更管理の提出条件
費目別金額、初年度継続費用、前提・除外、体制、品質基準、変更管理、再委託を同じ様式で求めます。
支援先の提案を比較する5つの観点
- ✓
前提・対象外・未確認事項が明記されている
金額や工程だけでなく、どの条件で提案が成立するかを比較します。
- ✓
方式の判断根拠と追加調査が示されている
特定方式を前提にせず、資産・データ・停止制約との関係を確認します。
- ✓
業務・データ・テスト・移行の役割と体制が明確である
再委託の範囲、責任者、発注者側に必要な工数も確認します。
- ✓
受入基準、照合、性能・復旧、Go／No-Goが具体化されている
基準未達時の再試験、再移行、延期判断の扱いを確認します。
- ✓
変更管理、引継ぎ、安定化支援の条件が示されている
変更時の影響評価、費用・納期への反映、運用移管の完了条件を比較します。
候補を探す段階では、SAP導入・S/4HANA移行支援サービスの一覧を利用し、対象業務、移行方式、体制、品質管理、引継ぎ条件を同じ観点で確認すると比較しやすくなります。
08SectionSAP S/4HANA移行の一次判断を、構想・調達開始へつなげる
最初に決めるべきなのは、方式名や支援先ではありません。保守・契約、対象範囲、現行資産、データ、停止制約、意思決定体制の事実をそろえ、それから方式・予算・工程・調達を設計します。
構想開始前に確認する優先事項
- 契約書、SAP for Me、SAP窓口で、保守の適用日、延長保守の可否、対象範囲を確認する。
- 対象会社・拠点・業務と、アドオン、帳票、連携、バッチ、データの一覧・所有者を仮置きする。
- 履歴データ、監査・参照要件、停止可能時間、繁忙期、復旧目標を確認する。
- グリーンフィールド、ブラウンフィールド、選択的移行の一次候補、または構想・影響分析を先行する必要性を判断する。
- 初期費用、初年度継続費用、発注者工数、予備費を分けた予算枠と、RFI／RFPの比較条件を準備する。
保守・契約、現行資産、データ・統制のどれかが未確認であれば、構想・影響分析の開始優先度は高いといえます。個別価格はSAP公式窓口や個別見積もりで、選択的移行の手法・責任分界はRFI／RFPと契約で確認します。
よくある質問
SAP S/4HANA移行でよくある質問
SAP HANAへ移行していれば、S/4HANAへの移行は不要ですか？+
いいえ。SAP HANAはデータベース／データ処理基盤であり、S/4HANAはERPです。データベース移行だけで、ERPアプリケーション、業務プロセス、データモデル、拡張・連携の移行が完了するわけではありません。
ブラウンフィールドなら短期間・低リスクで終わりますか？+
一律にはいえません。既存資産を活用しやすい一方、カスタムコード、連携、権限、データ品質、簡素化項目、テスト、停止制約の影響分析は必要です。現行資産が未把握なら、方式確定より先に影響分析を行います。
保守方針の一般日付を、自社の移行期限として扱えますか？+
そのまま扱うべきではありません。公開方針には対象製品・EHPの範囲があります。自社への適用日、延長保守の可否・費用、対象外コンポーネントは、契約書、SAP for Me、SAP窓口で確認してください。
最初に支援先へ伝えるべき情報は何ですか？+
移行目的、対象会社・拠点・業務、現行製品・保守確認状況、アドオン・連携・データの概況、停止制約、依頼範囲、発注者側の体制と希望時期です。未確認事項も明示すると、追加調査を含む提案を比較しやすくなります。
SAP S/4HANA移行の支援先を比較する
構想・影響分析、移行方式の検討、要件整理、実装・テスト・切替支援まで、依頼したい範囲と比較条件に合わせて支援先を確認できます。
SAP導入・S/4HANA移行197社掲載
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
