SAP ECCのメインストリームメンテナンス終了に向けたジョブ準備計画2027

バッチスケジュールがSAP ECCで実行される場合、その下のプラットフォームは重要なメンテナンスの期限に近づいています。2027年の締切に関するほとんどのガイダンスは、ERPの移行を全体として扱います - データモデル、カスタムコード、機能範囲。このガイドはより狭く、より実用的です：それはジョブを所有するチームのための計画です。計画は、文書化されていないECC依存関係から、あなたと共に移動するマッピングされた、合理化された、ポータブルなワークロードにスケジューリングエステートを持ち込むための5つのステップを通じて進行します。

2027年の締切が変更するもの

SAPはSAP ERP 6.0、SAP Business Suite 7のコアのメインストリームメンテナンスの終了のための確定日を設定しました。今日ほとんどの顧客が稼働している拡張パッケージ（EHP 6から8）のメインストリームメンテナンスは2027年12月31日に終了し、その後2030年末までオプションの延長メンテナンスが行われますが、メンテナンスベースにプレミアムがかかります。より古いEHP 0-5バージョンは、すでに2025年12月31日にメインストリームメンテナンスの終了を迎えたため、これらのシステムは顧客特有のメンテナンスに移行しており、その範囲は法的および規制の更新を含まなくなっています。特に複雑なプログラムをクラウドインフラストラクチャに移行する資格のある大企業は、選択された顧客のためにECCの操作を延長するRISEを介したプライベートエディションへの移行のもう1つのオプションがあります。どの道を選んでも、スケジューリングエステートには明示的な計画が必要です：サポートされているターゲットに移行、新しいインターフェースに再設計するか、廃止するか。この作業は機能プロジェクトと並行して進行します - それには独自のクリティカルパスがあり、以下の5つのステップがそのパスです。

ステップ1 - インベントリ：移動する前にすべてのジョブをマッピング

マッピングされていないものを移行することはできず、多くのECCエステートは要求に応じて完全なマップを生成できません。SM36でユーザーによって直接スケジュールされたジョブはSAPで表示されますが、中央カタログの外に位置しているため、移行の真の範囲は文書化されたものよりも常に大きくなります。最初のステップは、すべての未管理のジョブを中央ガバナンスの下に持ち込むことです。ジョブの抽出とミラーリングにより、ユーザーがスケジュールしたSAPジョブを単一の管理されたカタログに取り込み、計画する範囲が仮定ではなく現実のものとなります。これは、隠れた依存関係を浮き彫りにするための基盤です。

ステップ2 - 合理化：持ち運ぶ前にエステートを縮小

小さなシステムはより早く移行します。何年にもわたる蓄積されたハウスキーピングジョブ、ワンオフレポート、廃止されたプロセスがスケジューリングの複雑さを増加させます。不必要なアプリケーションデータもアーカイブ、システムコピー、バックアップ、および移行活動中に処理されるボリュームを増加させ、すべての技術的なステップを長引かせることでS/4HANAのロードマップを遅延させます。不必要なデータと廃止されたスケジューリングロジックを減らすことで、移行範囲を簡素化し、努力を減らすことができます。エステートをスリム化するための2つのアクション：

• SARAでアーカイブします。データアーカイブは、書き込み、削除、およびアーカイブオブジェクト全体での保存を実行し、移行が処理しなければならない基盤となるテーブルを縮小します。
• 習慣として実行されているハウスキーピングジョブを廃止します。ステップ1の中央カタログにより、エステート全体の繰り返しの技術的および管理的な作業負荷の完全なセットを確認できます。その可視性により、レガシースケジュール、重複プロセス、廃止されたレポート、監視タスク、およびもはやビジネス価値を提供しないメンテナンスジョブを特定しやすくなります。各作業負荷を慎重に見直し、ターゲット環境に持ち運ぶ前に必要のないものを廃止してください。企業規模でのバックグラウンドジョブスケジューリングに関するガイドは、通常蓄積されるハウスキーピング作業負荷と、それらをガバナンスの下に持ち込む方法について説明しています。

ステップ3 - ターゲットトポロジーを選択

"ECCから移行する"は1つの目的地ではありません。スケジューリングの影響は4つの一般的なランディングゾーンで異なり、ジョブが実行されるインターフェースもそれぞれ異なります。変換する前にターゲットを決定してください - それがすべての下流のことを決定します。これらのターゲットのほとんどは、バックグラウンド処理のためのSAPの認定外部インターフェースであるXBPを公開しています；一つだけは公開していません。

通過線：同じSAPジョブタイプはSAP R/3とS/4HANAにまたがっているため、S/4HANAへの移行には新しいプラグインは必要ありませんし、RISEへの移動はマイナーな設定変更です。唯一の重要な変化はGROWパブリッククラウドで、スケジューリングの表面が異なります。RISE、クリーンコア、GROWのガイドは、エージェントの配置、暗号化、およびそれぞれの高可用性モデルを含む4つのトポロジーを完全に比較しています。

ステップ4 - 再構築するのではなく変換する

プラットフォームの変更に対する本能は、新しい環境で手動でスケジュールを再構築することです。任意のサイズのエステートでは、それは遅く、エラーが発生しやすく、何年もかけて正しく取得した依存関係のロジックを捨ててしまいます - それは必要ありません。変換ツールは、既存のジョブ定義を直接インポートし - ジョブとカレンダーを一緒に - 定義されたシーケンスに従って何を見つけたかを列挙する評価レポートを生成します：プロジェクトを選択し、データを評価し、変換を実行し、結果を検証し、ターゲットに読み込む。再構築するのではなく変換することで、クロスシステムのロジックを保持します - SAPジョブをファイル転送、銀行、またはそれを待っているデータプラットフォームに結びつける依存関係を保持します - 人にそれを記憶から再構築させる代わりに。私たちのSAPバッチジョブとECCからS/4HANAへの移行ガイドは、変換メカニクスを完全にカバーしています。

ステップ5 - シミュレーションし、カットオーバーを保護する

最後のリスクはカットオーバーの週末そのもので、2つの失敗モードがあります：新しいプラットフォームで異なる動作をするバッチ実行と、基盤作業が進行中の間にSAPに書き込むジョブです。

• 実行をシミュレーションします。ゴーライブの前に新しい環境に対してバッチスケジュールを予測し、What-Ifドライランを実行して、実データを運ぶ前に実行の形状とどこで壊れるかを確認します。
• ウィンドウを保護します。エステート全体にわたるグローバル停止、保留、再起動は、アップグレード、サポートパック、および変換週末に関与する強化作業の間にSAPに何も投稿しないことを確保し、そのウィンドウが閉じた後にエステートをクリーンにリリースします。アップグレードとサポートパックプロジェクトは、システムがそれらに対して準備が整っていないため、ジョブがシステムに飛び込むため、ビジネスプロセスの混乱のよく知られた原因です。グローバルな保留は、それが発生するリスクを大幅に減少させます。

タイムラインを構築します

締切は固定されているので、それから計画します。S/4HANAプログラムの期間は、範囲、ランドスケープの複雑さ、データ戦略、カスタムコード、デプロイメントモデル、展開アプローチによって大きく異なるため、締切から逆算して、組織の検証されたプログラム計画を立てます。算術は見た目よりも厳密です。2026年8月現在、主流メンテナンスがEHP 6-8システムのために終了するまで、約17か月が残っています。多くのS/4HANAプログラムは範囲によって12〜24か月の間で実行されますが、それはその範囲の短い側がまだウィンドウ内に収まることを意味し、長い側はもはやそうではありません。まだスコーピングを開始していないプログラムは、実際には2027年の日付自体ではなく、ブリッジとして延長メンテナンスの周りで計画を立てている - そのブリッジはメンテナンスベースのプレミアムを伴います。スケジューリングチームにとって、ターゲットに関係なく、シーケンスは同じです：

• インベントリ - すべてのジョブをマッピングし、中央集権化します
• 合理化 - アーカイブし、廃止します
• トポロジーを選択 - オンプレ、RISEプライベート、RISE + BTP、またはGROW
• 変換し、パラレル実行 - インポートし、検証し、古いものと新しいものを並行して実行
• カットオーバー - シミュレーションし、ウィンドウを保護し、リリースします

ステップ1と2は即座に価値を提供します - マッピングされた、スリムなエステートは今日の運用が容易であり、締切に関係なく - それが今すぐにそれらを開始する理由です。

よくある質問

ECCサポートが2027年に終了する際、私のSAPバッチジョブはどうなりますか？メンテナンスのマイルストーンは、SAPシステムやそのバッチジョブを自動的に停止するものではありません - システムが稼働している限り、それらは動き続けます。終了するのは、2027年12月31日にEHP 6-8システムの下にあるプラットフォームのSAPのメインストリームメンテナンスです；古いEHP 0-5の締切は2025年末に過ぎました。実際の作業はジョブではなくエステートにあります：スケジュールされたすべてのジョブをインベントリし、SM36でユーザーがローカルに作成したものを含む；もはやその場所に値しないものをアーカイブし、廃止する；それから選択したS/4HANAターゲットに定義を変換し、手動で再構築するのではなく、クロスシステムの依存関係が移行を生き残るようにします。この作業は、機能S/4HANAプロジェクトと並行して進行し、締切のかなり前に開始するのが最良です。 S/4HANAに移動する際、すべてのSAPジョブを再定義する必要がありますか？いいえ - 1つの例外を除いて。サンプルのSAPジョブタイプはSAP R/3とS/4HANAにまたがっているため、S/4HANAへの移動には新しいプラグインが必要なく、SAPとのRISEへの移動はマイナーな設定変更です。変換ツールは既存のジョブ定義とカレンダーをインポートし、見つけたものを報告します。これにより、実際のサイズのエステートに対する手動再構築が置き換えられます。例外は、スケジューリング表面が異なるGROW with SAP、パブリッククラウドです。次のステップ変換されたエステートがSAPおよび非SAPシステムでどのように実行されるかを実際に見るには、Control-M for SAPを探ってください。

これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも代表するものではありません。