SAP S/4HANA移行前のSimplification Item Check実践ガイド

SAP ERPからSAP S/4HANAへシステムコンバージョンを進める場合、既存業務やデータ構造が移行先の前提に適合するかを、技術変換の前に確認します。その中心となるのがSimplification Item Checkです。これは単なるエラー一覧の取得ではなく、対象リリースで変更された機能、データモデル、業務前提を洗い出し、プロジェクトの対応作業へつなげるためのチェックです。

この記事では、SAP S/4HANA移行プロジェクトでの実行準備、結果の読み方、担当割り当て、対応後の再実行までを、実システムで扱いやすい順序にまとめます。全体計画との関係はSAP S/4HANA移行の全体像で確認できます。

01Simplification Item Checkの役割

Simplification Item Checkは、移行元システムの利用状況や設定を、対象のSAP S/4HANAリリースで定義されたSimplification Itemの観点から検証します。Simplification Itemは、従来機能の変更、後継機能への移行、データ変換、設定変更、利用停止などを整理した単位です。

結果には、対応が必要な項目だけでなく、追加確認が必要な項目や、対象システムでは影響が限定的な項目も含まれます。したがって、件数をそのままプロジェクト工数とみなさず、業務影響と技術対応の有無を一件ずつ判断します。

主な確認対象は次のとおりです。

• 変更されたデータモデルやテーブル構造
• 旧機能から後継機能への移行が必要な業務領域
• 既存設定、マスタ、トランザクションデータの事前処理
• カスタムコードやインターフェースへの影響
• 移行前または移行後に実施する変換プログラム
• 対象リリース固有の前提条件や制約

Simplification Item Checkは、SAP S/4HANA移行プロジェクトのフェーズでは、準備から実現に入る前の技術・業務ギャップ整理に置くと扱いやすくなります。

02実行前にそろえる情報

最初に、対象リリースと移行方式を固定します。同じSAP S/4HANAでもターゲットリリースが異なれば、確認対象や対応手順が変わるためです。対象システムの製品バージョン、サポートパッケージ、アドオン、業務利用範囲、移行予定日をプロジェクト台帳に記録します。

次に、使用中の業務領域を整理します。FI、CO、MM、SD、PP、EWM、TM、PS、HCMなどの利用有無に加え、独自トランザクション、帳票、バッチ、外部連携を一覧化します。利用していない機能に関する結果は、除外理由を残したうえで管理すると、後続のレビューで再調査する手間を減らせます。

アドオンと拡張の確認も実行前に行います。アドオンの対応状況、拡張オブジェクト、修正済み標準オブジェクト、RFCやファイル連携を台帳へ登録します。カスタムコードの調査はSAP S/4HANAカスタムコード移行の進め方と並行させると、Simplification Itemの指摘と独自開発の影響を結び付けやすくなります。

実行環境は、本番データを直接変更しない検証系システムから始めます。システムコピーやリフレッシュを使う場合は、データ鮮度、接続先、外部送信の停止状態を確認します。チェック結果を保存する場所、実行者、実行日時、対象リリースも記録してください。

03チェックの実行手順

実行方式は、対象リリースの移行手順とシステム構成に合わせて決めます。プロジェクトでは、Maintenance PlannerやSAP Readiness Checkなどの周辺情報と、システム内で実行するSimplification Item Checkを役割分担させます。外部の計画情報だけでシステム内の適合性確認を完了扱いにせず、実環境の結果を基準にします。

システム内でチェックを開始する場合は、次の流れで作業します。

1. 作業対象クライアント、システム、対象リリースを確認する。
2. 移行作業用の変更凍結やバックアップ方針を確認する。
3. 対象リリースで要求されるチェック用コンポーネントと前提条件を確認する。
4. /SDF/RC_START_CHECK を指定された実行方法で起動する。
5. 実行ログ、検出結果、実行日時、対象システムを保存する。
6. 結果を業務領域、技術領域、データ変換、カスタムコードに分類する。

実行時に権限エラー、未導入コンポーネント、前提条件不足が出た場合は、エラーを解消してから再実行します。エラーを結果一覧から手作業で除外して進めるのではなく、実行ログと環境情報をセットで残します。

チェックに長時間かかる場合は、ダイアログ処理だけで完了させようとせず、実行方式とバックグラウンド処理の運用を担当チームで決めます。並列実行を行うときは、同じシステム上の他の重い処理やバックアップへの影響も確認します。

04結果を読むときの分類

結果を受け取ったら、まずステータスとメッセージを確認します。次に、各項目を「対応必須」「影響確認中」「対象外の根拠あり」「再チェック待ち」に分けます。ステータスの文字だけで判断せず、メッセージ、参照文書、該当オブジェクト、業務利用状況を一緒に確認します。

対応必須の項目には、業務担当、アプリケーション担当、SAP Basis担当、データ移行担当などの責任者を割り当てます。項目ごとに、次の情報を課題管理表へ記録します。

対象外と判断した項目にも、判断理由を残します。たとえば該当機能を利用していない、対象組織が存在しない、既に後継機能へ移行済み、といった根拠を記録します。対象外の判断を曖昧にすると、カットオーバー直前に同じ項目が再び課題として戻ります。

05業務対応と技術対応を分ける

Simplification Itemの対応は、技術処理だけで完了しないことがあります。業務プロセスの変更、権限設計、マスタ整備、未決済データの処理、履歴データの扱いなど、業務側の意思決定が先に必要な項目があります。

FIやCOでは会計データと管理会計データの整合性、MMでは在庫と購買伝票、SDでは販売伝票と請求、PPでは製造関連データを確認します。EWMやTMを使う場合は、周辺システムとの連携や移行順序も課題に含めます。業務担当が結果を確認し、技術担当が変換や設定を実施するという分担を明確にしてください。

カスタムコードの影響は、単純な構文エラーだけでなく、変更されたテーブル、削除された項目、旧トランザクションへの依存、権限や連携方式の変更として現れます。Simplification Itemの結果をコード調査の優先順位に利用し、影響のあるプログラムをテスト対象へ加えます。

アドオンは、製品提供元の対応状況、対象リリース、導入バージョン、適用ノートや修正手順を確認します。アドオンの更新が必要な場合は、更新後のシステムでチェックを再実行し、旧バージョンの結果を完了証跡に使わないようにします。SUMを使った技術変換との関係はSAP S/4HANA移行でのSUMの位置付けで整理できます。

06対応後の再チェック

課題を修正したら、同じ条件でSimplification Item Checkを再実行します。実行前に、修正対象、適用日時、変更依頼、関連テストを記録し、結果ファイルに実行番号や日時を付けます。初回結果を上書きせず、初回、対応後、移行リハーサル後の結果を比較できる状態にします。

再チェックでは、次の観点を確認します。

• 対応必須の項目が解消または承認済みになっているか
• 新しい警告や前提条件不足が発生していないか
• アドオン更新や修正輸送が結果へ反映されているか
• 業務テストとデータ検証が完了しているか
• 対象外とした項目の判断根拠が現在も有効か
• 移行リハーサルで同じ手順を再現できるか

結果が改善していても、移行本番の直前に設定やコードを変更した場合は、影響範囲を確認して再実行します。完了判定は、チェック結果だけでなく、課題管理表、テスト証跡、業務承認、移行リハーサルの結果をまとめて行います。

07失敗しやすい運用パターン

最初の結果をそのまま移行判定に使う運用は避けます。ターゲットリリースの確定前に実行すると、後から項目や前提条件が変わり、結果の比較が難しくなります。対象リリース、実行環境、コンポーネント状態を結果ファイルに残してください。

件数削減だけを目標にすると、対象外判断の品質が落ちます。課題数ではなく、対応必須項目の解消、業務テストの完了、再チェックでの確認を完了条件にします。

Basis担当だけで結果を閉じる運用も問題になります。データや業務プロセスの影響は、FI、CO、MM、SD、PPなどの担当者が確認する必要があります。プロジェクトの週次会議では、未解決項目を領域別に確認し、判断待ちと技術作業待ちを分けて報告します。

移行リハーサル後にチェックを一度も行わない運用では、実際のデータ量やアドオン状態を反映できません。リハーサルの各サイクルで再実行し、本番前の変更を結果へ反映します。

08移行判定に使える完了基準

プロジェクトで完了基準を定める際は、単に「チェック実行済み」としません。次のような条件を組み合わせると、判断が明確になります。

• 対象リリースと実行環境が承認されている
• 実行ログと結果ファイルが保存されている
• 対応必須項目に担当者と期限が設定されている
• 業務影響のある項目に業務責任者の判断がある
• カスタムコード、アドオン、インターフェースの影響調査が完了している
• 対応後の再チェック結果が保存されている
• 未解決項目にリスク受容者と切り戻し条件がある

この基準を移行ゲートに組み込み、SUM実行、データ移行、結合テスト、カットオーバー計画と連動させます。移行方式の比較やデータ移行の整理が必要な場合は、SAP S/4HANAデータ移行方式の整理も参照してください。

09まとめ

Simplification Item Checkは、SAP S/4HANAコンバージョン前に、既存システムと移行先の差分を具体的な作業へ変換するための確認工程です。実行するだけでは十分ではなく、対象リリースの固定、業務利用状況の確認、担当割り当て、対応、再チェック、証跡保存までを一つの流れとして管理します。

特に重要なのは、結果の件数ではなく、各項目について「誰が」「何を」「いつまでに」「どの証跡で」完了と判断するかを明確にすることです。移行リハーサルを含む複数回のチェックを計画し、業務と技術の両方から承認できる状態を作ることで、カットオーバー直前の想定外作業を減らせます。