SAP S/4HANA Migration
SAP S/4HANA移行プロジェクトのフェーズ概要と進め方
SAP S/4HANA移行プロジェクトを、計画、準備、分析、実現、テスト、移行、稼働後安定化のフェーズに分けて整理します。各フェーズの成果物、判断ポイント、期間の見積もり方を実務向けに解説します。
SAP S/4HANAへの移行は、システム変換の技術作業だけで完結しません。業務プロセス、アドオン、データ、権限、連携、テスト、利用部門の受け入れを一つの計画で管理する必要があります。特に既存のSAP ERPを移行する場合は、最初に方式と対象範囲を決め、その後に分析結果を設計と作業計画へ反映します。
本記事では、SAP S/4HANA移行プロジェクトを実務で扱いやすいフェーズに分け、各段階の目的、主な成果物、完了条件、期間の考え方を整理します。SAP Activateのフェーズ名と完全に一対一で対応するというより、移行プロジェクトで必要になる作業単位として整理したものです。
全体像を先に決める
最初に、移行対象のシステム、会社コード、プラント、販売組織、購買組織、データ期間、連携先、対象ユーザーを一覧化します。プロジェクトの範囲が曖昧なまま詳細設計へ進むと、後から対象追加が発生し、テストとカットオーバー計画が連鎖的に遅れます。
移行方式は、既存システムを活用して変換する方式、新規に業務設計を行う方式、段階的に組み合わせる方式から検討します。方式を選ぶ際は、既存業務をどこまで維持するか、データをどの期間・粒度で引き継ぐか、業務標準化をどこまで進めるかを判断材料にします。方式の比較は移行方式の違いを整理したSAP S/4HANA移行アプローチ解説も参照できます。
この段階で作成する基本成果物は、プロジェクト憲章、対象範囲一覧、関係システム一覧、概算スケジュール、体制図、リスク登録簿です。経営層には投資、停止可能時間、業務変更の範囲を提示し、業務責任者には意思決定の期限を提示します。
フェーズ1：構想と準備
構想・準備フェーズでは、移行の目的を業務上の成果へ変換します。単にサポート期限への対応とするのではなく、決算早期化、在庫可視化、マスタ統合、購買統制、分析基盤との連携など、移行後に測定できる目標を設定します。
主な作業
- 現行SAP ERPの利用範囲と周辺システムを棚卸しする
- 移行方式、対象リリース、インフラ方針、運用体制を決定する
- プロジェクト責任者、業務リード、技術リード、データ担当、テスト担当を任命する
- 業務停止可能時間とカットオーバー候補日を確認する
- 開発、検証、リハーサル、本番の環境計画を作成する
- 予算、調達、外部パートナー、意思決定会議を確定する
準備段階では、SAP S/4HANA移行の全体計画と論点を確認するガイドを使い、技術課題だけでなく組織と業務の前提も確認します。
完了条件
対象範囲と移行方式が承認され、主要な責任者が決まり、初期リスクに対応方針が付いている状態を完了条件にします。特に、移行対象外のシステムとデータを明示しておくことが重要です。対象外を定義しない計画は、後工程で追加要件として戻ってきます。
フェーズ2：現状分析と適合性評価
現状分析では、業務プロセス、利用機能、データ、カスタムコード、アドオン、連携、帳票、ジョブ、権限を調査します。インタビューだけでなく、実際の利用状況、トランザクション、バッチ、インターフェースの実績も確認します。
SAP S/4HANAで利用方式が変わる業務やデータ構造は、早い段階で影響を記録します。業務部門には、現在の処理を継続するか、標準プロセスへ合わせるか、拡張で補うかを選択してもらいます。
分析対象のチェックリスト
| 分析領域 | 確認する内容 | 主な成果物 |
|---|---|---|
| 業務プロセス | 現行手順、例外処理、承認、月次・年次処理 | 業務プロセス一覧、課題一覧 |
| マスタ | 顧客、仕入先、品目、勘定、組織、分類 | マスタ移行方針 |
| トランザクションデータ | 残高、未決済、受注、発注、在庫、固定資産 | データ対象一覧 |
| カスタムコード | Zプログラム、拡張、帳票、ジョブ | 改修・廃止・継続判定 |
| 連携 | RFC、API、ファイル、EDI、外部サービス | インターフェース台帳 |
| 権限 | ロール、職務分掌、緊急ユーザー | 権限設計方針 |
| 運用 | 監視、バックアップ、障害対応、ジョブ運用 | 運用設計課題 |
このフェーズでは、Simplification Itemの確認手順と対応管理を活用し、該当する業務変更と対応期限を管理します。SUMを利用する変換では、SUMを使ったSAP S/4HANA移行の準備ポイントも技術計画に組み込みます。
完了条件
分析対象が一覧化され、各項目に「継続」「変更」「廃止」「追加調査」の判定が付いている状態を目標にします。未判定項目を残す場合は、担当者、期限、判定に必要な情報を明確にします。
フェーズ3：設計とバックログ化
分析結果を、実装可能な作業へ分解します。業務プロセス、組織、データ、開発、連携、権限、運用、テスト、教育を別々のワークストリームとして管理すると、担当範囲と依存関係を追跡しやすくなります。
設計で決めること
- 標準機能へ合わせる業務と拡張する業務
- 組織構造とマスタコードの対応
- データの保持期間、変換規則、除外条件
- カスタムコードの改修、再設計、廃止方針
- 外部システムとの接続方式とエラー処理
- ロール、承認、職務分掌、監査要件
- テストデータ、テスト環境、欠陥管理方法
- 切替順序、凍結期間、戻し判断の条件
作業項目には、担当者だけでなく完了条件と証跡を設定します。例えば「インターフェースを確認する」ではなく、「送受信項目、接続先、エラー時の再送方法、疎通結果を台帳へ記録する」と定義します。
設計レビューでは、業務リードと技術リードが同じ成果物を確認します。業務上成立していても、運用監視や障害復旧が成立しない設計は、後の総合テストで問題になります。
フェーズ4：実現と反復テスト
実現フェーズでは、設定、開発、データ変換、連携構築、権限設定、帳票、運用手順を反復的に作り込みます。初回から本番同等の完成度を目指すより、優先度の高い業務シナリオを小さく通し、早期に設計上の問題を発見します。
推奨する反復単位
- 対象プロセスと受け入れ条件を確定する
- 設定・開発・データ準備を行う
- 開発環境で単体確認する
- 代表データで業務シナリオを実行する
- 欠陥、設計変更、未決事項を記録する
- 修正後に再テストし、業務責任者が判定する
開発作業とデータ作業を別々に進めると、移行後の業務シナリオで初めて不整合が発覚することがあります。設定変更、変換プログラム、データ抽出、ロード、照合を一つのテストシナリオに結び付けます。
フェーズ5：総合テストと受入
総合テストでは、単一機能ではなく、受注から出荷・請求、購買から支払、計画から製造、入庫から棚卸、会計から決算までの業務連鎖を確認します。外部システム、帳票、ジョブ、権限、承認、監視も同じシナリオに含めます。
テストの段階
- 単体テスト：設定、開発、変換処理を担当者が確認する
- 結合テスト：複数機能と連携を組み合わせて確認する
- 業務シナリオテスト：部門横断の業務を通して確認する
- 回帰テスト：既存業務と修正済み機能を再確認する
- 性能テスト：大量データ、同時実行、月次処理を確認する
- 移行リハーサル：本番と同じ手順、時間、役割で実行する
- ユーザー受入：業務責任者が利用可否を判定する
テストでは、欠陥件数だけでなく、重要業務の通過率、未解決の重大度、データ照合結果、性能目標、権限エラーの有無を判定材料にします。テスト計画の作成方法はSAP S/4HANA移行におけるテスト戦略の整理で補足しています。
受入判定の例
- 重要な業務シナリオが計画どおり完了している
- 財務残高、在庫、未決済、マスタ件数を照合できている
- 必須インターフェースと帳票が稼働条件を満たしている
- 重大な未解決欠陥に対する回避策と期限が承認されている
- 操作手順、監視手順、障害時の連絡経路が完成している
フェーズ6：カットオーバーと本番移行
カットオーバーでは、停止開始から本番利用開始までの作業を分単位で計画します。作業項目、開始条件、担当者、所要時間、確認方法、判断者、失敗時の対応をカットオーバー台帳へ記載します。
カットオーバー計画に含める項目
- 旧システムの業務停止と利用者通知
- 最終データ抽出と変換
- 最終バックアップと復旧確認
- オープン項目、残高、在庫、マスタのロード
- カスタムコード、ジョブ、連携、権限の有効化
- 技術確認と業務確認
- 外部システムとの接続確認
- 利用者への開始通知
- 監視強化と初動対応体制
移行リハーサルでは、作業時間だけでなく、照合に要する時間と判断待ち時間も測定します。リハーサルの所要時間が業務停止可能時間を超える場合は、データ範囲、並行作業、手順、担当者の配置を見直します。
戻し判断は、カットオーバー開始後に初めて考えるのではなく、事前に条件化します。例えば、重要な残高照合が完了しない場合、主要連携が復旧しない場合、業務開始時刻までに必須確認が終わらない場合など、判断可能な基準にします。
フェーズ7：稼働後安定化
本番稼働直後は、通常運用へすぐに戻すのではなく、安定化期間として管理します。問い合わせ窓口、障害の優先度、対応時間、業務影響、エスカレーション先を明確にし、日次で状況を確認します。
稼働後に確認する指標
- 重要業務の処理状況と未処理件数
- ジョブ、連携、帳票、承認のエラー
- データ照合差異と修正件数
- 性能、バッチ時間、画面応答
- 権限不足や過剰権限の申告
- 利用者からの問い合わせ分類
- 既知課題の解消状況
安定化期間の終了条件は、日付だけでなく、重大障害が一定期間発生していないこと、主要業務が定常運用へ移管されていること、運用チームが手順と監視を引き継いでいることに基づいて定めます。終了後は、残課題を通常の変更管理へ移します。
移行プロジェクトの期間を見積もる
期間は、対象範囲、移行方式、会社・拠点数、データ量、アドオン、連携数、テストの深さ、業務部門の稼働可能時間で大きく変わります。単一の標準期間を当てはめるのではなく、作業量と制約から見積もります。
見積もりの進め方
- 対象業務、会社、拠点、データ、連携を数える
- 分析、設計、構築、テスト、移行、安定化へ分類する
- 各作業に担当チームと前提条件を付ける
- 依存関係を洗い出し、クリティカルパスを特定する
- テストとリハーサルを複数回入れる
- 意思決定、調達、休暇、決算、繁忙期の制約を反映する
- 不確実性の高い作業に予備期間を割り当てる
期間短縮では、テストを削るより、対象範囲の優先順位付け、標準化の早期判断、データ品質改善、意思決定の迅速化、反復作業の自動化を優先します。特にデータ品質とカスタムコードの判定を後回しにすると、終盤の手戻りが増えます。
フェーズ間のゲートを管理する
各フェーズの終了時には、次へ進むためのゲートを設けます。ゲートは報告会ではなく、未完了項目を次工程へ持ち越すか、計画を変更するかを判断する場です。
| ゲート | 判断する内容 |
|---|---|
| 構想完了 | 範囲、方式、体制、予算、主要日程が承認されているか |
| 分析完了 | 影響、データ、アドオン、連携、業務変更が判定されているか |
| 設計完了 | 要件、受け入れ条件、移行規則、運用方針が確定しているか |
| 実現完了 | 主要シナリオが動作し、テストへ渡せる状態か |
| 受入完了 | 重大な未解決事項と業務リスクが許容されているか |
| 本番開始 | カットオーバー準備、復旧、連絡体制が整っているか |
| 安定化完了 | 運用引継ぎと残課題管理が成立しているか |
ゲートでは、未完了項目をゼロにすることだけを目指しません。未完了項目の影響、回避策、責任者、期限、承認者を明確にし、リスクを可視化したうえで判断します。
実務で起きやすい遅延要因
1. 対象範囲が増え続ける
追加要求は、業務効果、法令、運用リスク、依存関係を評価してから計画へ入れます。承認済み範囲との交換条件を示し、日程・予算・品質への影響を記録します。
2. データ品質の確認が遅い
重複マスタ、未完了伝票、不整合な組織値、古いコードは、分析フェーズで抽出します。データクレンジングの担当と業務上の承認者を分け、修正結果を照合します。
3. カスタムコードを一覧だけで判断する
利用頻度、業務重要度、依存関係、性能、権限、出力結果を確認し、継続・改修・廃止を決めます。コード検査の結果を業務シナリオと結び付けることで、不要な開発を減らせます。
4. 業務部門の判定が後ろへずれる
各シナリオに業務責任者を割り当て、レビュー日と受入日を予定へ固定します。技術チームだけで完了判定を行わず、業務結果、残高、帳票、承認を業務側が確認します。
5. 移行リハーサルが一度だけになる
初回リハーサルでは手順の欠陥を洗い出し、次回で時間と品質を改善します。少なくとも、データ移行、照合、外部連携、業務開始確認を本番に近い条件で再現します。
プロジェクト開始時の実務チェックリスト
- 移行方式と対象範囲が承認されている
- 現行システム、周辺システム、連携先が一覧化されている
- 業務、技術、データ、テスト、運用の責任者が決まっている
- Simplification Itemと影響業務が管理されている
- カスタムコードとアドオンの判定計画がある
- データ抽出、変換、ロード、照合の担当が決まっている
- テスト環境と代表データの準備日が決まっている
- カットオーバー候補日と業務停止可能時間が確認されている
- 戻し判断の条件と承認者が定義されている
- 稼働後の問い合わせ、監視、障害対応の体制がある
このチェックリストをプロジェクト計画へ組み込み、各項目に担当者、期限、証跡を付けます。フェーズ名を並べるだけでなく、成果物とゲートを管理することが、移行期間と品質を安定させる基本です。