SAP Readiness CheckとS/4HANA移行アセスメント

S/4HANA移行アセスメントは、ECCシステムの移行にどれだけのコストと期間がかかるのか、どのアプローチが合うのかを教えてくれます。SAP Readiness Checkはそのアセスメントの技術的な半分です。システムをS/4HANAと比較し、何が壊れるかを一覧にしますが、判断を代わりに下してはくれません。

結論から言えば、まず本番環境でReadiness Checkを実行し、カスタムコードの結果もアップロードしてください。そのうえで本当の労力は、チェックからは見えないことに注いでください。プロセス、データ、カスタムオブジェクト、インターフェースを、そもそも移すべきかどうかです。

移行の全体的な流れは、まず私のECCからS/4HANAへの移行ガイドからお読みください。

SAP Readiness Check for SAP S/4HANAは、SAPが提供するクラウドアプリケーションです。ECCシステムでデータコレクターを実行して結果をアップロードすると、S/4HANAがそのシステムにどう影響するかを示すインタラクティブなダッシュボードが得られます。

SAPのReadiness Checkの主要機能の概要（2026年9月）によれば、有効なSAP保守契約を持つすべての顧客がSAP for Meで利用できます。SAP Cloud ALMのテナントを持つ顧客はそこでも実行でき、結果をプロジェクトのタスクとしてCloud ALMに送れます。

別途購入するものではありません。実際のコストは、Basisチームと、結果を読み解く人たちの時間です。

SAPは、アップグレード、BW/4HANA、その他の製品向けに別のシナリオを用意しています。ECC移行に必要なのはSAP Readiness Check for SAP S/4HANAです。SAPのコンバージョン準備に関する学習コンテンツが説明するとおり、ターゲットはS/4HANAオンプレミスでも、RISE with SAPのターゲットであるSAP S/4HANA Cloud Private Editionでも構いません。

S/4HANAシナリオについてのSAPの現在の一覧には、17のチェックがあります。次の表は、移行の判断に最も重要なものをまとめ、それぞれから分かることと、私なら注意する点を示しています。

チェック	分かること	注意すべき点
簡素化項目	どのS/4HANAの変更が自社システムに該当するか。工数のランク付けと関連する作業付き	主にテーブルの内容と使用中のトランザクションに基づくため、示すのは該当性であって対処方法ではない
アドオンの互換性	SAPとサードパーティの各アドオンが、ターゲットリリースに対して互換、非互換、不明のどれか	非互換のアドオンはSUMでのコンバージョンを妨げる。「不明」はベンダーへの問い合わせが必要という意味
有効なビジネス機能	非互換でコンバージョンを妨げるビジネス機能	ここでブロッカーが出たら、早めにSAPサポートへのインシデントが必要
カスタムコード分析	ATCまたはCustom Code Migrationアプリの結果を、影響別にまとめ、クイックフィックスの件数と使用・未使用の範囲付きで表示	カスタムコードの結果を別途アップロードした場合にのみ表示される
SAP S/4HANAのサイジング	初期のHANAメモリとディスクのサイズ、上位のテーブル、アーカイブの余地	サイジングの出発点であり、最終的なハードウェアやRISEのサイジングではない
インターフェース	IDoc、RFCとBAPI、Webサービス、OData、BWエクストラクター、フラットファイル、SLTの一覧と、想定される影響	示すのはこのシステムの技術的なインターフェースだけで、相手側のシステムは対象外
得意先・仕入先の統合	ビジネスパートナー化済みの得意先と仕入先の数と、データ品質の問題	ビジネスパートナーへの変換は、ほかのどの前提条件よりも多くのチームをつまずかせる
財務データの品質	総勘定元帳、固定資産会計、品目元帳の不整合を、年度別、会社コード別に表示	カテゴリDの結果にはシステム固有の修正が必要で、時間がかかる
計画ダウンタイムの計算	1つのデータセンターでの標準的なSUMコンバージョンで想定される業務のダウンタイム	あくまで目安。実際の時間枠はカットオーバー計画が決める
アプリの可用性と推奨Fioriアプリ	非推奨または置き換えられたトランザクションと、利用状況に合ったFioriアプリ	推奨であって、UXの設計ではない
Business Process Discovery	プロセスの自動化率、期限切れの滞留、非標準の伝票タイプ	プロセス分析のプレビュー。詳しくは後述

中心となる手引きはSAP Note 2913617（SAP Readiness Check for SAP S/4HANA）です。SAPは前提となるノートを定期的に更新するので、始める前に最新版を読んでください。

Readiness Checkの実行

1. 01

   準備

   分析するシステム（通常は本番環境）に、SAP Note 2913617に記載されたノートを適用する。

2. 02

   収集

   データ収集レポートRC_COLLECT_ANALYSIS_DATAをバックグラウンドジョブとして実行し、ターゲットリリースを選んでZIPをダウンロードする。

3. 03

   カスタムコード

   ATCまたはCustom Code MigrationアプリでS/4HANAのカスタムコードチェックを実行し、結果をエクスポートする。

4. 04

   アップロード

   SAP for MeのSAP Readiness Checkのページで新しい分析を作成し、両方のファイルをアップロードする。

5. 05

   レビュー

   Basis、財務、プロセスオーナー、カスタムコードの責任者とともに、すべてのチェックを確認する。

手順の一覧には表れない点をいくつか挙げます。

1. 本番環境を使う。 SAPの手引きは本番環境を分析することです。計画に使うのはその結果だからです。いくつかのチェックは実際の使用履歴に依存しており、サンドボックスにはそれがありません。
2. カスタムコードの結果をアップロードする。 メインのデータ収集だけでは、カスタムコードは分析されません。ATCやCustom Code Migrationアプリの結果を誰も同じ分析にアップロードしなければ、カスタムコードのセクションは空のままで、レポートは実際のシステムよりきれいに見えてしまいます。
3. ターゲットリリースを確認する。 実際に移行するS/4HANAまたはPrivate Editionのリリースを選んでください。簡素化項目とアドオンの状況はリリースによって変わります。
4. ある程度の手戻りを見込む。 データコレクターは失敗し、ノートが不足し、大規模システムではジョブが長引きます。工数だけでなく、そのための経過時間を計画してください。

入り口のページはme.sap.com/readinesscheckです。

このチェックは1つの問いに答えるのが得意です。このシステムの何がS/4HANAと衝突するか、です。それがそもそも存在すべきかどうかに答えるようには作られていません。

カスタムオブジェクト

私の経験では、Readiness Checkの見落としで後に痛手になるのはカスタムオブジェクトです。チェックは、どのカスタムコードが簡素化項目に対して壊れるかを教えてくれます。どのZプログラム、テーブル、拡張、フォーム、レポートがいまも業務上の目的を果たしているのか、どれがS/4HANAの標準機能と重複しているのか、どれを何年も誰も実行していないのかは教えてくれません。

この差が重要なのは、私が見るプログラムで最も超過しやすいフェーズがカスタムコードだからです。予算で最も見落とされやすい隠れたコストでもあります。

検出結果の数とカスタムオブジェクトの数は、別の数字です。あるプログラムでは、smartShiftによる分析でカスタムオブジェクトを18,000から3,200まで減らしました。Readiness Checkだけでは、この削減はできなかったでしょう。チェックが測るのは影響であって、価値ではないからです。

ですから私は、カスタムコードのセクションを棚卸しの終わりではなく始まりとして扱います。Custom Code Migrationアプリは使用・未使用の範囲を、smartShiftは自動化された分析と修正を加えます。それでも、何を廃止するかには業務部門の誰かの合意が必要です。

分析対象のシステムの外にあるものすべて

チェックが見るのは1つのECCシステムです。次のものは見えません。

1. プロセス設計。 受注から入金まで、記帳から報告までのプロセスを再設計すべきかどうか。それがグリーンフィールド、ブラウンフィールド、選択的データ移行を決めます。
2. インターフェースの相手側。 ECC内のインターフェースは一覧になります。ミドルウェア、サードパーティのシステム、その担当者は対象外です。
3. まだロードしていないデータ。 SAP以外のシステムのデータや、財務とビジネスパートナー以外のデータ品質です。
4. 組織と変革。 誰が判断を担うのか、ユーザーの準備がどれだけ整っているか、プログラムの間に業務部門がどれだけ受け止められるか。
5. 商用面。 ライセンスの切り替え、RISEのスコープ、パートナーのコストは、どのSAPのダッシュボードにもありません。

Business Process Discoveryは、プロセスのパフォーマンスを最初に概観させてくれます。より踏み込んだSAPの分析はSAP Signavio Process Insights, discovery editionで、SAPのサポートの価値に関するページでは、6つの業務領域にわたるプロセス改善の推奨と説明されています。有用なインプットですが、それでも設計ではありません。

移行アセスメントは、Readiness Checkを1つのインプットとして取り込み、予算を付けられる判断に変えます。両者を比べると次のようになります。

問い	SAP Readiness Check	本格的な移行アセスメント
ECCの何がS/4HANAと衝突するか	対応。詳細に	チェックの結果を使う
どのカスタムオブジェクトを残し、廃止し、作り直すか	一部：影響と、Custom Code Migrationアプリを使えば使用状況	対応：オブジェクトの棚卸し、使用状況、業務上のオーナー、判断
グリーンフィールド、ブラウンフィールド、選択的データ移行のどれか	非対応	対応。プロセスとデータの調査結果に基づく
どのインターフェースと外部システムが変わるか	ECC側のみ	両側。担当者と修正方法付き
財務以外のデータはどれだけきれいか	一部	対応。クレンジング計画と担当者付き
どれだけの期間とコストがかかるか	ダウンタイムとサイジングの見積もりのみ	スケジュール、コストの幅、予備費
どの導入形態と商用モデルか	非対応	オンプレミス、Private Edition、Public Editionのどれか、そして何を交渉すべきか

私が使うツールは、SAP Readiness Check、カスタムコード向けのCustom Code MigrationアプリとsmartShift、そして選択的データ移行が選択肢にある場合のSNPやNatuvionです。どれも、プロセスオーナーとの設計レビューの代わりにはなりません。

あとは私のアプローチのルールが決めます。他のシステムから移る場合や新しいプロセスを定義する必要がある場合はグリーンフィールド、プロセスが定義され機能している場合はブラウンフィールド、一部の領域のプロセスを再定義する必要がある場合は選択的データ移行です。お金をかける前に最初の見通しを得たい場合は、私の無料のS/4HANA移行アセスメントツールで同じトレードオフを順にたどれます。

アセスメントの成果は、そのまま移行スケジュールとプロジェクト計画と移行コストの見積もりにつなげるべきです。パートナーに渡すのもこの成果です。パートナーが自社のアセスメントに具体的なハイレベル設計で応えられないなら、それ自体が一つの答えです。その段階は、私のS/4HANA移行パートナーの選び方のガイドで扱っています。

場合によります。要因が企業ごとにあまりに違うので、私は一つの数字は示しません。

期間を動かすのは次の要因です。

1. システムとクライアントの数。 ECCの本番システムが1つの場合と、BW、CRM、SRMが別にあって5つの場合とでは、別の仕事です。
2. カスタムコードの量。 数千のカスタムオブジェクトには使用状況の分析と業務上の判断が必要で、それはツールの時間ではなく人の時間です。
3. インターフェース。 外部システムごとに、自分の側で何が変わるかを言える担当者が必要です。
4. エンティティと国。 会社コードが多いほど、ローカライゼーション、税務、報告についての問いが増えます。
5. データ品質。 財務上の大きな不整合や乱れたビジネスパートナーのデータは、誰かが見積もる前に調査が必要です。
6. 業務部門の参加。 アセスメントに実際に時間を割けるプロセスオーナーは、どんなツールよりも期間を短くします。
7. アクセス。 ノートの承認や本番ジョブのスケジュールを待つ時間は、分析が進まないまま経過時間を増やします。

私がしないのは、構築を早く始めるためにアセスメントを切り詰めることです。私が主導または立て直した21のSAPプログラムを通じて、私が見る最大の誤りは、開始時にきちんと計画しないことです。アセスメントは、その計画が始まる場所です。

今月中に、Basisチームに本番環境へSAP Note 2913617を適用してもらい、カスタムコードの結果を含めてReadiness Checkを実行してください。そのうえで、財務の責任者、プロセスオーナー、カスタムコードの責任者と半日の時間を取り、一緒に結果を読んで、チェックが答えていない問いを書き出してください。

そのリストが、移行アセスメントのスコープです。パートナーに声をかける前に独立した視点が必要でしたら、ご連絡ください。

S/4HANA向けのSAP Readiness Checkとは何ですか？

SAP ERPシステムをSAP S/4HANAと照らし合わせて分析する、SAPのクラウドアプリケーションです。システムでデータコレクターを実行し、SAP for Meで結果をアップロードすると、簡素化項目、アドオン、ビジネス機能、カスタムコード、サイジング、インターフェース、ビジネスパートナー、財務データの品質、推奨Fioriアプリを網羅したダッシュボードが得られます。

SAP Readiness CheckはSAP顧客なら無料ですか？

SAPは、有効なSAP保守契約を持つすべての顧客にSAP for Meで、Cloud ALMのテナントを持つ顧客にはSAP Cloud ALMで提供しています。実際のコストは、システムを準備し結果を解釈するための社内とパートナーの時間です。

SAP Readiness Checkはどのように実行しますか？

SAP Note 2913617に記載されたノートを、通常は本番環境に適用します。データ収集レポートRC_COLLECT_ANALYSIS_DATAを実行してZIPをダウンロードし、ATCまたはCustom Code Migrationアプリでカスタムコード分析を別途実行します。SAP for MeのSAP Readiness Checkのページで、両方を1つの分析にアップロードします。

SAP Readiness Checkの対象外は何ですか？

カスタムオブジェクトがまだ必要か、プロセスを再設計すべきか、インターフェースの相手側で何が起きるか、プログラムにいくらかかるかは判断しません。分析するのは1つのシステムの技術的な互換性です。それ以外の問いは、本格的な移行アセスメントで扱うものです。

S/4HANA移行アセスメントにはどれくらいの期間がかかりますか？

システムの数、カスタムコードの量、インターフェースとエンティティの数、データの状態、そしてプロセスオーナーがどれだけ時間を割けるかによります。

グリーンフィールドかブラウンフィールドかを選ぶ前にReadiness Checkを実行すべきですか？

はい。システムのどれだけがS/4HANAと衝突するかが分かり、それはアプローチを決めるインプットの一つになります。判断そのものは、プロセスが定義され機能しているかどうかにかかっており、それはチェックでは測れません。