SAP ECCからS/4HANAへの移行：中東小売企業の事例

これは、私のお気に入りの事例です。ファッションと消費財を手がける、中東の著名な小売企業が、SAP ECC 6.0からS/4HANAへ移行しました。従業員は約18,000人、7か国に1,200店舗以上を展開し、Eコマースのチャネルも成長していました。ECCを長年使い続けており、システムオブジェクトの44%がカスタマイズされていました。私たちは、選択的な再設計を伴うブラウンフィールドコンバージョンを選びました。月次決算は、週末にまで及んでいたものが、昼前に終わるようになり、カスタムコードは半分近く減りました。

大幅にカスタマイズしたECCを運用していて、どこまでを引き継ぐべきか迷っているなら、あるプログラムがその問いにどう答えたかを紹介します。

カスタマイズは、緊急の修正を一つずつ重ねるうちに、少しずつ積み上がっていました。私たちが始めた時点では、小さな更新にさえリスクが伴っていました。連携は壊れやすく、財務での小さな変更が、小売オペレーションの何かを壊しかねませんでした。ビジネス側は、柔軟性とスピードを求めていました。IT部門は、火消しに追われていました。双方が、お互いの目的がすれ違っていることを認めていました。

あるセッションで、サプライチェーンのチームが、自分たちの「重要」なレポートの数十本が、もうほとんど使われていないと認めて、少し笑ったのを覚えています。それらを切り捨てることは、実務的でもあり、不思議と気持ちが軽くなることでもありました。

きっかけは、ECCのメインストリームメンテナンスの終了でした。エンハンスメントパッケージ6〜8のSAP ERP 6.0は、2027年末でメインストリームメンテナンスが終了します（SAP News）。本当の動機は、もっと根深いものでした。財務は、毎月の決算のたびに手作業でデータを抽出していました。店舗は、夜間バッチでは得られない在庫の可視性を必要としていました。IT部門の労力の大半は、カスタムコードを生かし続けることに費やされていました。

SAP Readiness Checkは、私たちの予想を裏づけました。大幅にカスタマイズされたシステムで、この先に相当な是正作業が控えているということです。シンプリフィケーション項目リストは、ECCのカスタムコードがこれまで担ってきたことを、標準のS/4HANAがすでに実現している箇所を示しました。財務部門は、長年保守してきたカスタムレポートの一部が、もう不要になっていることを知りました。その会議での安堵の空気は、はっきりと感じられました。

単純な技術的コンバージョンでは、問題を先送りするだけでした。完全なグリーンフィールドでの作り直しでは、10年分の機能する設定を捨てることになります。選択的な再設計を伴うブラウンフィールドが、そのバランスでした。しっかりしたものは残し、整理が必要なものは整理し、壊れているものだけを作り直します。これらの道筋をどう比べるかは、私のECCからS/4HANAへの移行ガイドで解説しています。

単純なコンバージョン選択的な再設計を伴うブラウンフィールド完全なグリーンフィールドでの作り直し

維持される設定単純なコンバージョンすべて。問題も含めて選択的な再設計を伴うブラウンフィールドしっかりしていたもの完全なグリーンフィールドでの作り直しなし。十年分の作業を破棄

44%のカスタムオブジェクト単純なコンバージョンそのまま引き継ぐ選択的な再設計を伴うブラウンフィールド一つずつ、廃止、置き換え、改修のいずれかに分類完全なグリーンフィールドでの作り直し引き継がない

意味すること単純なコンバージョン問題がS/4HANAに移る選択的な再設計を伴うブラウンフィールド整理が必要なものを整理し、壊れているものだけを作り直す完全なグリーンフィールドでの作り直し機能している業務プロセスをすべて一から作り直す

課題	私たちの対応
44%のカスタマイズされたオブジェクト	ビジネスとITが一緒に、各オブジェクトに廃止、置き換え、改修のいずれかを割り当てた。フェーズごとの品質ゲート
壊れやすい連携	POS、WMS、財務、人事、仕入先ポータルを対象とするリグレッションテスト計画。ポイントツーポイントの連携は、SAP Integration Suiteのパターンへ移行
データ品質	機能ごとのデータスチュワードとSLA。不具合の日次追跡。クレンジングはQA開始前に完了
各国での定着	ロール別の業務ガイド、本稼働間近のフロアウォーク、実際の業務タスクに結びついたトレーニング

大規模なカスタムコード

レディネスチェックの結果は、フィルターとして機能しました。ビジネスとITが同じ場に座り、すべてのオブジェクトに分類を付けました。実行した記憶のある人もいないレポートのように、明らかに不要なものがありました。小売ならではの独自のプロセスを支えており、慎重な再設計が必要なものもありました。この作業は、チームに先送りではなく決断を迫りました。SAP Signavioは、新しいプロセスをベストプラクティスに照らして定義するのに役立ちました。smartShiftは、コードの自動スキャンと価値の低い修正を引き受け、そのおかげで、シニアの時間を再設計に充てられました。今、私がカスタムコードをどう分類しているかは、私のクリーンコアのガイドで解説しています。

連携

ECCは、POS（販売時点情報管理）システム、倉庫管理システム（WMS）、財務、人事、複数の仕入先ポータルとつながっていました。私たちは、そのすべてを対象にリグレッションテスト計画を作り、最後だけでなく、大きな設定変更のたびにテストしました。夜間バッチジョブは、S/4HANAでより速く終わらなければなりませんでした。そうでなければ、倉庫の朝のレポートが間に合わなかったからです。

データ品質

重複した仕入先レコードと古いマスタデータが、テストを長引かせました。対処は構造的なものでした。各機能にデータスチュワードを置き、解決にSLAを設けたのです。QAの開始時点でデータがきれいになっていなければ、スチュワードに差し戻しました。カットオーバーが近づくと、ロードをエンドツーエンドでリハーサルし、不具合を毎日追跡しました。この単純な習慣は、どんな凝ったダッシュボードよりもうまく機能し、それには今でも驚かされます。このパターンは、私の記事SAPのデータ移行が失敗する理由と対処法で扱っています。

定着

トレーニングは、26,000人の従業員に届きました。財務と小売オペレーションでは優先事項が異なり、それは初期のワークショップで表に出て、トレーニングの設計を変えました。本稼働が近づいてプレッシャーが高まると、ロール別の業務ガイドとフロアウォークを使いました。後に、ある店舗リーダーは、2ページのガイドのほうがどんなタウンホールミーティングよりも重要だったと言いました。私はその言葉を信じました。

SAP Activateによる段階的なデリバリー。 中核となる財務とサプライチェーンを先に移行し、人事と仕入先ポータルは後にしたので、サポートチームの負荷が限界を超えることはありませんでした。各環境には、それぞれ一つの役割がありました。サンドボックスは、移行の道筋を検証し、スコープを固めました。開発環境は、トランスポートを固めました。QAでは、実際の業務ボリュームで稼働させ、ジョブをチューニングしました。本番前環境は、本物のドレスリハーサルでした。デプロイの日程は、小売の繁忙期と閑散期に合わせました。

ビジネスとともに行うテスト。 財務とサプライチェーンのリーダーが、実際の期末処理とプロモーションのサイクルに合わせてテストしました。スクリプトは、システムのロジックではなく、ビジネスの現実に沿って書かれていました。夜間の実行で、タイミングの問題が浮かび上がりました。数週間の苛立ちの後、2回目の実行がスムーズに通ったとき、倉庫のリーダーが笑顔になったのを覚えています。

カットオーバーのリハーサル。 すべてのタスクに所要時間を計り、削るか、まとめるかしました。ドライランだけで、スプレッドシートでは決して見えなかった時間を短縮できました。リカバリー計画は1ページの配布資料にまとめ、その単純なリストは、どんなダッシュボードよりもストレスを減らしてくれたと言われました。店舗でのパイロットで、より広いロールアウトの前に、POSとWMSの安定性を証明しました。

ハイパーケア。 ITとビジネスが共有するウォールーム、明確なSLA、日次のアクションログを用意しました。週末のシフトは持ち回りにし、サポートの引き継ぎは分単位で台本化しました。人が覚えているのは、たいてい数字です。私が一番よく覚えているのは、最初の静かな夜です。

財務決算。 チームによると、月次決算は、かつては週末にまで及んでいたのに、今では昼前に終わります。CFOが最も喜んだのは、レポートがずっと早く手元に届くようになったことでした。ある財務リーダーは、システムがついに「コーヒーマシンより速く」動くようになったと冗談を言いました。そうした瞬間は、どんなスライド資料よりも信頼感を育てます。

カスタムコード。 半分近く減り、長期的なサポートの負担と、今後のアップグレードごとのリグレッションのリスクが下がりました。

レポーティングとユーザー体験。 店長たちは、古いトランザクション画面からSAP Fioriアプリへ移りました。アプリが人々の期待どおりに動くため、トレーニング時間は短くなりました。ある店長は、それを「新鮮だ」と表現しました。

連携。 POS、WMS、財務の連携が安定し、夜間ジョブはより早く終わるようになりました。

すべてが均等にうまくいったわけではありません。もっと良いレポートがあるのに、古いレポートを手放さないチームもありました。ワークショップが長すぎる、リハーサルが繰り返しばかりだと感じたチームもありました。今振り返ると、それらのステップこそがセーフティネットでした。

教訓	起きたこと	次回なら何をするか
早期にすり合わせる	あるワークショップで、店長たちが、レポートのニーズは財務とまったく違うと述べた。早い段階で表に出たので調整できたが、後になっていたら、カットオーバーで爆発していたはずだ	設計を始める前に、構造化されたすり合わせのセッションを設ける
コードレビューを初日から始める	本稼働間近になって、いくつかのオブジェクトがプレッシャーの中で作り直された	キックオフの時点から、廃止、置き換え、改修の判断を下す
データをビジネス側の仕事にする	重複した仕入先レコードがテストを遅らせた	最初の週に、機能ごとのデータスチュワードを指名し、SLAを設ける
必要だと感じる以上にリハーサルする	ドライランで、誰も予測していなかったPOSとWMSの間の順序の衝突が見つかった	リハーサルを追加で計画する。本稼働前の最後の1回は、退屈に感じるくらいがよい

同じプログラムを今始めるとしたら、変わる点が3つあります。この立場にあるほとんどの企業は、今ならオンプレミスにとどまるのではなく、RISE with SAPのS/4HANA Cloud Private Editionを検討するでしょう。廃止、置き換え、改修の判断は、SAPのクリーンコアのレベルA〜Dに照らして整理することになります。変更とデプロイメントの追跡は、SAP Cloud ALMで行います。Solution Manager 7.2のメインストリームメンテナンスが2027年末で終了するためです。データスチュワード、リハーサル、共同のウォールーム、2ページのガイドは、すべて今までとまったく同じままにします。人の側面については、私のSAPトレーニング戦略のガイドをご覧ください。

企業はなぜ、SAP ECCからS/4HANAへ移行するのですか？

きっかけは、2027年のECCのメインストリームメンテナンス終了です。より強い理由は、運用面にあります。リアルタイムのレポーティング、より速い決算、そしてカスタムコードや壊れやすい連携を生かし続けるための労力の削減です。このケースでは、ビジネス側が、リアルタイムの小売分析と、より短い月次決算を求めていました。

このケースで、SAP Readiness Checkは何を示しましたか？

オブジェクトの44%がカスタマイズされており、その多くが何年も使われていないことが確認されました。これが、カスタムコードの作業の組み立て方を変えました。まず廃止し、可能な限り標準に置き換え、本当に業務上の価値があるものだけを改修します。シンプリフィケーション項目リストは、標準のS/4HANAによって不要になったレポートも示しました。

なぜ、選択的な再設計を伴うブラウンフィールドを選んだのですか？

単純な技術的コンバージョンでは、あらゆる問題を引き継ぐことになり、完全なグリーンフィールドでの作り直しでは、10年分の機能する設定を捨てることになります。選択的な再設計では、しっかりしたものを残し、標準でカスタムロジックを置き換えられる箇所ではSAP Signavioで新しいプロセスを定義し、壊れているものだけを作り直しました。

データクレンジングを遅らせすぎると、どうなりますか？

テストが長引き、リハーサルが失敗し、本稼働が遅れます。このケースでは、重複した仕入先レコードと古いマスタデータが、テストで何週間も摩擦を生みました。対処は、各機能にSLA付きのデータスチュワードを置き、クレンジングをプログラムの健全性の指標として追跡することでした。

移行中、連携はどのように扱いましたか？

まず、すべての接続先を洗い出しました。POS、WMS、財務、人事、仕入先ポータルです。リグレッションテスト計画がそのすべてを対象とし、大きな設定変更のたびにテストを実施し、より広いロールアウトの前に、店舗でのパイロットでPOSとWMSの安定性を証明しました。それでも、ドライランで、POSとWMSの間の、誰も予測していなかった順序の衝突が見つかりました。

S/4HANAの本稼働後、優れたハイパーケアとはどのようなものですか？

ITとビジネスが共有するウォールームがあり、明確なSLAと日次のアクションログがあり、課題がバックログに塩漬けにならず、速やかにクローズされることです。ロール別のガイドとフロアウォークは、正式なトレーニングよりも速く、サポートへの問い合わせを減らします。週末のシフトを持ち回りにし、引き継ぎを台本化して、チームが燃え尽きないようにします。