SAP S/4HANA移行・コンバージョンの全体像｜方式選定から本稼働までの進め方

SAP ERPからSAP S/4HANAへ移行するプロジェクトでは、ソフトウェアの更新だけでなく、業務プロセス、データ構造、拡張、連携、権限、運用を一体で見直します。特に既存資産をどこまで残すかによって、計画、停止時間、テスト量、業務部門の負荷が大きく変わります。

この記事では、移行方式の選定から事前チェック、構築、データ移行、テスト、本稼働、安定化までを、実際のプロジェクトで使える単位に分けて整理します。個別の製品バージョンやアドオンの適合性は、対象システムの構成と利用中の文書を確認しながら判断してください。

01SAP S/4HANA移行の全体像

SAP S/4HANA移行は、次の流れで管理すると論点を漏らしにくくなります。

1. 現行環境と移行目的を整理する
2. 移行方式と対象範囲を決める
3. 事前チェックと互換性確認を実施する
4. 業務・データ・拡張・連携の設計を固める
5. 開発環境と検証環境で変換を反復する
6. 統合テストと業務受入テストを行う
7. 本稼働リハーサルとカットオーバーを実施する
8. 本稼働後の監視と課題収束を進める

全体計画では、技術作業だけでなく、業務停止時間、データ凍結、ユーザー教育、外部システムの切替、問い合わせ対応まで工程に含めます。プロジェクトの基準日、責任者、完了条件を早い段階で合意しておくと、後工程での判断が安定します。

フェーズごとの成果物、依存関係、承認ポイントを先に一覧化する場合は、SAP S/4HANA移行プロジェクトのフェーズも参照してください。

02移行方式を選ぶ

代表的な方式は、既存システムを基盤として変換するBrownfield、新しい環境を構築して業務やデータを再設計するGreenfield、既存資産を選択的に引き継ぐ中間的なアプローチです。

Brownfield

Brownfieldは、既存の組織構造、業務データ、設定、拡張を活用しながら、SAP S/4HANAの要件に合わせて変換する方式です。業務変更を抑えやすい一方、古い拡張や利用実態のない設定も引き継ぎやすく、事前分析と修正の品質が重要になります。

Greenfield

Greenfieldは、新しいシステムを構築し、標準業務を中心にプロセス、組織、権限、データ移行範囲を設計する方式です。業務を整理しやすい反面、要件定義、データクレンジング、ユーザー移行、連携再構築に多くの作業が発生します。

判断の軸

判断時は、次の観点を点数化すると議論を整理できます。

• 既存業務を維持する必要性
• 不要なカスタマイズの量
• データを継続利用する範囲
• 利用中アドオンと連携の適合性
• 業務停止に許容される時間
• 変革を実施する組織の準備度
• 将来の標準化と運用簡素化の目標

方式ごとの特徴を比較する際は、SAP S/4HANAのBrownfieldとGreenfieldの違いで、引き継ぐ対象と再設計する対象を分けて確認できます。

03事前分析と変換準備

移行方式を決めたら、現行システムの棚卸しを実施します。対象には、リリース情報、データ量、会社コードやプラントなどの組織構造、使用中の業務機能、カスタムコード、アドオン、インターフェース、ジョブ、帳票、権限、運用手順を含めます。

事前分析では、単に一覧を作るだけでなく、各項目に「継続」「修正」「廃止」「再設計」の判断を付けます。利用実績のないトランザクションやインターフェースを移行対象から外せると、テストと運用保守の負荷を減らせます。

Simplification Itemの確認

SAP S/4HANAでは、従来のデータモデルや業務機能から変更される項目があります。対象となる業務領域ごとに、前提条件、影響、必要な対応、完了証跡を管理します。未解決の項目を残したまま変換工程へ進めると、後続のエラー調査が複雑になります。

事前チェックの実行結果は、単なる警告一覧ではなく、担当チーム、期限、対応方針、再確認方法を持つ課題台帳に落とし込みます。詳細な確認観点は、SAP S/4HANA Simplification Itemチェックの進め方にまとめています。

アドオンとカスタムコード

アドオンは、利用目的、提供元、対象リリース、修正版の有無、業務上の代替策を確認します。カスタムコードは、使用頻度と業務重要度を基準に優先順位を付け、静的チェックと実行テストを組み合わせて評価します。

本稼働直前に初めて互換性問題が判明すると、修正だけでなく回帰テストの期間も必要になります。したがって、アドオンとカスタムコードの分析は、設計やテスト計画より前に開始するのが安全です。

04主要な機能・データ領域を整理する

移行計画は、システム単位だけでなく業務領域単位でも作成します。たとえば、FIでは会計伝票、残高、固定資産、税設定、締め処理を確認します。MMでは購買、在庫、評価、発注残を確認し、SDでは受注、出荷、請求、未処理伝票を確認します。

生産を利用する場合は、PPの品目、BOM、作業手順、計画、製造指図を対象にします。倉庫や輸送を利用する場合は、EWMやTMとの連携と業務責任の境界を明確にします。品質管理、保全、人事、プロジェクト管理なども、利用実態に応じて個別の移行条件を定義します。

業務領域ごとに、次の項目を表形式で管理すると、担当間の認識をそろえやすくなります。

05Business Partner変換とデータ移行

顧客・仕入先をBusiness Partnerへ整理する作業は、移行プロジェクトの重要な準備項目です。対象の重複、番号体系、一般データ、会社コードデータ、購買組織データ、ロール、住所、税情報を確認し、変換後の一意性を確保します。

データ移行では、全履歴を持ち込むか、残高と未処理明細を中心に移すかを決めます。判断には、法令・監査要件、業務検索の必要性、参照システムの有無、保管コスト、照合方法を含めます。

移行対象データは、抽出、変換、ロード、照合、業務承認の各段階で管理します。件数一致だけでなく、金額、残高、キー項目、組織別集計、代表明細を照合し、差異があれば原因と再処理方法を記録します。

Business Partner変換の設計や確認項目は、SAP S/4HANA Business Partner変換の実務を参照してください。

06テストと本稼働リハーサル

テストは、技術確認、単体確認、業務プロセス確認、統合テスト、業務受入テスト、性能確認、権限確認、切替リハーサルに分けて計画します。各テストには、前提データ、実行者、期待結果、証跡、欠陥の優先度、再テスト条件を定義します。

業務プロセスは、正常系だけでなく、返品、取消、差戻し、部分納品、請求差異、期間締め、インターフェース再送などの例外系を含めます。移行後のデータを使い、業務ユーザーが実際の判断を行えるシナリオを準備することが重要です。

テスト終了の判断は、欠陥件数だけでなく、重要業務の完了、データ照合、権限確認、連携確認、運用手順の承認を組み合わせます。テスト設計の詳細は、SAP S/4HANA移行のテスト戦略で確認できます。

07カットオーバーを設計する

カットオーバー計画には、作業順序、開始条件、担当者、所要時間、依存関係、判定ポイント、エスカレーション先、切り戻し条件を記載します。事前にリハーサルを複数回行い、実測時間を計画へ反映します。

典型的な作業には、旧システムの取引停止、最終データ抽出、未処理伝票の確認、バックアップ、変換処理、データロード、照合、連携切替、権限反映、ジョブ有効化、ユーザー接続確認が含まれます。

切り戻しを検討する場合は、どの時点まで戻せるか、業務データをどう扱うか、外部システムへ通知するかを明文化します。判断を現場の担当者だけに委ねず、プロジェクト責任者と業務責任者が承認できる体制を整えます。

08本稼働後の安定化

本稼働直後は、システム監視と業務監視を並行して行います。ログオン、バッチ、キュー、RFC、印刷、インターフェース、データベース、ジョブ、権限エラーを監視し、業務領域ごとの未処理件数や締め処理の進行も確認します。

問い合わせは、障害、操作、データ、権限、仕様、改善要望に分類します。重大度、影響範囲、暫定対応、恒久対応、担当、期限を記録し、毎日の運営会議で未解決項目を確認します。

安定化期間の終了条件には、重要業務の連続稼働、未処理障害の収束、運用チームへの引き継ぎ、監視ルールの承認、バックアップと復旧手順の確認を含めます。移行プロジェクトの終了後も、改善項目と通常運用の課題を分けて管理すると、責任範囲が明確になります。

09実務で使えるチェックリスト

企画・方式選定

• 移行目的と成功条件を定義した
• Brownfield、Greenfieldの判断理由を記録した
• 対象会社、拠点、業務、期間を確定した
• 停止時間と切り戻し条件を合意した

事前分析

• システム、アドオン、拡張、連携を棚卸しした
• Simplification Itemを担当者付きで管理した
• カスタムコードの修正・廃止方針を決めた
• データ品質と移行対象を評価した

構築・テスト

• 開発、検証、本番の移送経路を確認した
• 業務領域別のテストケースを準備した
• データ照合の基準値を定義した
• 権限、ジョブ、連携、帳票を確認した
• 本稼働リハーサルの実測時間を記録した

カットオーバー・安定化

• 作業順序と判定ポイントを確定した
• 問い合わせと障害の受付方法を決めた
• 監視項目と担当者を割り当てた
• 運用引き継ぎと終了条件を承認した

10まとめ

SAP S/4HANA移行の成否は、変換ツールの実行だけでなく、移行方式、事前分析、データ品質、業務テスト、カットオーバー、安定化を一つの計画として管理できるかで決まります。

特に重要なのは、既存資産を残す判断と廃止する判断を明確にすること、Simplification Itemやアドオンの課題を早期に解消すること、業務部門がデータとテスト結果を承認できる状態を作ることです。工程ごとの完了条件を設定し、未解決事項を次工程へ持ち越す場合は、影響と期限を明示して進めてください。

よくある質問

SAP S/4HANA移行では、最初に何を決めますか？

移行目的、対象範囲、業務停止の許容時間、既存資産の継続利用方針、移行方式を決めます。技術方式だけでなく、業務変革の範囲とデータ移行方針を同時に定義することが重要です。

BrownfieldとGreenfieldはどちらを選ぶべきですか？

既存業務やデータを広く継続利用し、変更を抑える必要がある場合はBrownfieldが適しています。業務を標準化し、不要な設定や拡張を整理したい場合はGreenfieldが適しています。アドオン、データ品質、組織の変革準備度も含めて判断します。

Business Partner変換はいつ実施しますか？

事前分析と並行して対象データを整理し、設計段階で番号、ロール、重複、必須項目を確定します。その後、開発・検証環境で変換と照合を反復し、本稼働リハーサルで所要時間と結果を確認します。

移行テストでは何を確認しますか？

業務プロセス、データ件数と金額、権限、バッチ、外部連携、帳票、性能、例外処理、切り戻し条件を確認します。正常系だけでなく、取消、差戻し、再送、締め処理などの実業務に近いケースを含めます。

本稼働後の安定化期間は何を管理しますか？

重大度、影響範囲、暫定対応、恒久対応、担当、期限を管理します。システム障害だけでなく、データ差異、操作上の問い合わせ、権限不足、連携遅延、未処理業務も同じ運営ルールで追跡します。