SAP Readiness Checkの活用方法：S/4HANAコンバージョン前に確認する項目と進め方

SAP ERPからSAP S/4HANAへのシステムコンバージョンでは、技術的な作業に入る前に、既存システムの状態と移行による影響を整理します。SAP Readiness Checkは、そのための分析結果をまとめ、移行プロジェクトで確認すべき論点を可視化するために活用できます。

レポートは移行可否を自動的に決定するものではありません。分析結果を業務担当者、開発担当者、Basis担当者、移行責任者が確認し、対応方針・担当者・期限を決めるための材料として扱います。

01SAP Readiness Checkの役割

SAP Readiness Checkは、現在のSAP ERP環境をSAP S/4HANA移行の観点から分析する仕組みです。利用中の機能、データ量、アドオン、カスタムコード、簡素化項目などを横断して確認し、移行プロジェクトで調査が必要な領域をまとめます。

最初に確認するのは、レポートに表示された警告の数ではなく、業務影響の大きさと対応期限です。技術的な警告が多くても業務影響が限定的な場合があり、反対に少数の項目が移行計画全体を左右することもあります。

SAP S/4HANA移行全体の流れや用語を先に整理する場合は、SAP S/4HANA移行の全体像を参照してください。Readiness Checkは全体計画の一部として位置付けると、分析結果を次の作業へつなげやすくなります。

02レポートで確認する主な領域

Readiness Checkのレポートでは、複数の観点から現行システムを確認します。画面上の分類名や表示順をそのまま対応順にせず、各結果を移行作業、業務設計、開発、テストのどこで処理するかに置き換えて管理します。

簡素化項目

既存のトランザクションやデータ構造、業務機能がSAP S/4HANAで変更される場合、対応が必要な論点として整理されます。該当項目は、単なる利用有無の確認で終わらせず、対象プロセス、担当部門、代替機能、必要なデータ対応、テスト範囲まで確認します。

簡素化項目の技術的な確認方法を作業計画に落とし込む際は、S/4HANA Simplification Itemの確認方法と照合すると、課題の抜けを減らせます。

カスタムコード

自社開発プログラム、拡張、帳票、インターフェースなどは、S/4HANAのデータモデルや利用可能なAPIとの関係を調査します。検出された件数をそのまま改修件数とせず、実行頻度、利用部門、業務上の重要度、代替標準機能の有無で優先順位を付けます。

本番で使われていないプログラムを先に整理できれば、改修対象を絞り込めます。利用中のプログラムは、構文上の適合だけでなく、結果の意味、権限、バッチ実行、外部連携を含めてテスト対象にします。

アドオンと連携

導入済みアドオンは、対象リリースや移行方式との互換性、提供元の対応状況、更新時期、ライセンス条件を確認します。外部システムとの連携では、RFC、ファイル連携、IDoc、API、帳票配信などを一覧化し、接続先ごとに認証方式と切り替え手順を整理します。

アドオンの調査を独立した作業として管理する場合は、S/4HANAアドオン互換性の確認を参照してください。互換性の確認結果は、後続のテスト計画とカットオーバー計画にも反映します。

データ量とサイズ

データ量に関する結果は、移行対象データの範囲、保持期間、アーカイブ方針、移行後の運用要件を検討する材料になります。単純に全履歴を移す前提にせず、法令・監査・業務照会・レポート要件を確認して対象期間を決めます。

データ量の検討では、現在の使用量だけでなく、月次・年次の増加傾向、ピーク時の処理、バックアップ、テスト環境への複製も確認します。サイジングの前提は、移行対象と将来の業務量を分けて記録すると見直しやすくなります。

ビジネスプロセス

利用中の業務プロセスは、組織、会社コード、プラント、販売領域などの単位で整理します。レポート上の利用状況と、現場が重要と考える業務が一致しないことがあるため、業務部門へのヒアリングで補完します。

特に月次決算、購買、在庫、販売、製造、資産管理、請求、外部連携は、通常処理だけでなく例外処理と締め処理を確認します。業務一覧には、担当部門、関連マスタ、入力元、出力先、停止可能時間を記録します。

03レポートを読む手順

レポートを受け取ったら、まず分析対象システム、データ取得日時、対象クライアント、対象範囲を確認します。古い分析結果を現在の構成に適用すると、すでに変更されたアドオンやプログラムを誤って判断するため、基準日時を課題管理表に記録します。

次に、結果を以下の4つに分類します。

• 移行前に解決する項目
• 設計または開発で対応する項目
• テストで重点確認する項目
• 方針決定後に対象外とする項目

対象外とする場合も、理由、承認者、判断日を残します。未対応のまま放置した項目と、意図的に対象外とした項目を区別できることが重要です。

課題管理表には、レポート上の項目名だけでなく、対象オブジェクト、業務プロセス、影響、対応案、担当、期限、依存関係、完了条件を記録します。レポートのリンクや画面だけを保管するのではなく、プロジェクトの課題管理ツールで追跡可能にします。

04コンバージョン前の優先順位付け

優先順位は、移行を止める可能性、業務影響、調査に必要な時間、他作業への依存関係で決めます。次のような順序にすると、初期調査から設計へ移りやすくなります。

1. 移行方式や対象範囲を変える可能性がある項目を確定する
2. 簡素化項目と主要アドオンの対応方針を決める
3. 重要業務のカスタムコードと連携を特定する
4. データ保持・アーカイブ・移行対象を決める
5. 開発、統合テスト、リハーサルの工数を見積もる
6. 未解決リスクと意思決定期限を管理する

Readiness Checkの結果をそのまま作業順に並べるのではなく、依存関係を確認します。たとえば、アドオンの対応方針が決まらなければ、関連するカスタムコードや統合テストの範囲も確定できません。

05SUM実行前に準備する情報

Software Update Manager（SUM）を使う段階では、Readiness Checkの結果がプロジェクトの判断済み一覧になっていることが望まれます。未解決の項目が残る場合は、技術的な解決方法、暫定対応、業務承認、実施時期を明確にします。

SAP S/4HANAコンバージョンにおけるSUMの概要では、SUMを使う作業の位置付けを確認できます。SUMの実行手順だけを先に詳細化するのではなく、前提となるアドオン、カスタムコード、データ、連携、テストの判断をそろえます。

準備資料には、少なくとも次の情報を含めます。

• 現行システムと対象リリースの構成
• 移行方式と対象クライアント
• アドオンおよび拡張の対応状況
• 重要な簡素化項目の対応方針
• カスタムコードの改修・廃止・継続一覧
• 外部連携の切り替え方法
• 移行対象データと保持方針
• テスト、リハーサル、カットオーバーの判定基準
• 未解決リスクとエスカレーション先

06分析結果をチームで共有する方法

レポートの共有会では、画面を順番に説明するだけでなく、意思決定が必要な項目を中心に議論します。業務担当者にはプロセスと影響、開発担当者には対象オブジェクトと改修方針、Basis担当者には実行条件と停止時間を示します。

各項目について、誰がいつまでに何を確認すれば完了になるかを合意します。「調査中」だけでは進捗を判断できないため、たとえば対象プログラム一覧の確定、業務責任者の承認、テストケースの作成など、確認可能な完了条件を設定します。

定例会では、前回から変わった判定、期限を超えた課題、依存する課題、追加で判明した対象を確認します。分析結果を一度きりの報告書にせず、設計、開発、テスト、リハーサルの各工程で更新します。

07よくある運用上の注意点

警告件数を品質指標にしない

警告件数はシステム規模や利用機能に左右されます。件数の削減だけを目標にすると、重要な業務影響の調査が後回しになります。リスクの重大度、対応期限、残存リスクを指標にします。

未使用機能を無条件に移行しない

過去に設定された機能が、実際には使われていないことがあります。利用実績、業務部門への確認、ジョブや連携の実行状況を確認し、廃止できる対象を整理します。

カスタムコードを構文だけで判断しない

構文上の修正が完了しても、結果が業務要件を満たすとは限りません。権限、通貨、日付、数量、集計、エラー処理、外部送信を含む業務テストを実施します。

レポート取得後の変更を追跡しない

分析後に設定、アドオン、プログラム、マスタ、データ量が変わることがあります。大きな変更があった場合は、課題管理表に変更を記録し、再分析や追加確認の要否を判断します。

08実務で使える完了判定

Readiness Checkの確認を完了とする基準は、レポートを閲覧したことではありません。移行対象の各領域について、影響、対応方針、担当、期限、検証方法が定義され、未解決リスクが意思決定者に共有されている状態を完了とします。

最終的には、次の質問に回答できることを確認します。

• 移行を妨げる未解決項目は何か
• どの業務プロセスを重点的にテストするか
• どのアドオンと連携を継続・変更・廃止するか
• どのデータを移行し、どのデータを保持・アーカイブするか
• カスタムコードの改修完了を何で判定するか
• SUM実行前に誰が何を承認するか
• リハーサルで確認すべき時間、手順、復旧条件は何か

この状態まで整理できれば、Readiness Checkの結果を、単なる診断レポートから移行計画とテスト計画に接続できます。