メインコンテンツへスキップ
見出し画像

S/4HANAのバージョンアップ（リリースアップグレード）の案件｜アップグレードでコンサルに求められる経験

    アサインコネクト｜SAP案件・キャリア

    S/4HANAへの移行が終わっても、SAPの仕事はそこで終わりません。S/4HANAにはリリース（版）があり、それぞれに保守の期間があるため、使い続けるには数年ごとに新しいリリースへ上げる作業が要ります。現場では「バージョンアップ」「リリースアップグレード」と呼ばれる仕事です。

    この記事は、すでにS/4HANAを使っている会社のプロジェクトに関わるSAPコンサルタントの目線で、リリースと保守の期間の決まり、アップグレードの進め方、業務のコンサルが関わるところを、SAPの公式資料で整理します。後半では、この領域の仕事で問われやすい経験を考えます。


    このnoteは、SAP人材に特化した案件紹介サービス「アサインコネクト」が書いています。

    当社には、SAPの導入・移行・運用保守など、さまざまな領域の案件が継続的に届いています。

    S/4HANAの運用保守や追加の導入で、リリースのアップグレードやテストに関わってきた方には、これまでのご経験と、稼働率・リモートの可否などの希望条件をうかがったうえで、合う案件を個別にご案内しています。

    下の画像か、その下のリンクを押すと、アサインコネクトのページが開きます。案件の例やご利用の流れを確認でき、LINEから希望条件を登録できます。

    画像

    アサインコネクトをチェックする

    この記事でわかること

    • 「アップグレード」と「アップデート」、ECCからの「移行（システム変換）」の違い

    • S/4HANAのリリースの出方と、保守の期間の決まり

    • アップグレードの準備と実行の流れ、使うSAPの道具

    • 業務のコンサルが関わる、差分の確かめ方・テスト・権限の見直し

    • アップグレードを計画するときに決めることと、この領域の仕事で問われやすい経験

    1. 「アップグレード」と「移行」は別の仕事

    SAP Learningでは、S/4HANAに関わる作業の言葉を、次のように分けて説明しています。

    • システム変換（System Conversion）：今のSAP ERPのシステムを、手順に沿って1対1でS/4HANAに変換すること。例はECCからS/4HANAへの変換

    • アップグレード（Upgrade）：システムを新しいソフトウェアのベースリリースに上げること。例はS/4HANAの2022から2023へ

    • アップデート（Update）：Feature Pack Stack（FPS）やSupport Pack Stack（SPS）といった、新しいソフトウェアの更新を当てること

    SAPのアップグレードガイド（Upgrade Guide for SAP S/4HANA 2025）でも、SAP ERPからS/4HANA 2025へ移る場合は、アップグレードではなくシステム変換になると書かれています。この記事が扱うのは、すでにS/4HANAを使っている会社が、新しいリリースへ上げるアップグレードです。ECCからの移行は、別記事「S/4HANA移行と2027年の保守期限｜移行案件でSAPコンサルに求められる経験」で、移行の方式は、別記事「S/4HANA移行のグリーンフィールドとブラウンフィールドの違い｜移行方式の選び方と、コンサルに求められる経験」で整理しています。

    2. S/4HANAのリリースと保守の期間

    2年に1回のリリースと、7年の保守

    SAP News Center（2022年9月15日）では、S/4HANAの2023のリリースから、次のように変えると発表されています。

    • リリースは2年に1回になる（2023のリリースから）

    • 各リリースの通常の保守（メインストリーム保守）は7年になる（それまでは5年）

    • 新しい機能は、使い始めやすいFeature Packで届ける。リリースのはじめの2年間は、半年ごとに出す予定

    SAP Learning（Navigating Release Upgrades）では、この流れが次のように説明されています。

    • ベースリリースは2年に1回出て、出てから7年で通常の保守が終わる

    • 新しいベースリリースが出たあと、次のベースリリースが出るまで、半年ごとにFPS（新しい機能を含む更新）が出る

    • 次のベースリリースが出たあとの前のリリースには、通常の保守が終わるまで、半年ごとにSPS（修正だけで新しい機能は無い）が出る

    また、SAPのサポートのページでは、2040年までは、常に少なくとも1つのS/4HANAのリリースが保守の対象にあると説明されています。

    オンプレミスとPrivate Editionで違うこと

    SAP Learningでは、オンプレミスのS/4HANAでは、アップグレードのすべてを利用する会社が担う、と説明されています。一方、S/4HANA Cloud Private Editionでは、通常の保守の範囲にとどまるために7年に1回は少なくともアップグレードを当てることが求められ、RISE with SAPのサービスとして年に1回のアップグレードをSAPに頼めます。このとき技術的なアップグレードはSAPが行い、計画・準備・テストなどの技術以外の作業は、利用する会社か導入のパートナーが担うとされています。

    つまり、Private Editionでも、業務の側の準備とテストは会社とコンサルの仕事として残ります。RISE with SAPの仕組みは、別記事「RISE with SAPとは｜クラウド移行で変わるSAPの案件とコンサルの役割」で整理しています。

    3. アップグレードの進め方

    SAPのアップグレードガイド（S/4HANA 2025）では、アップグレードを「準備（Prepare）」と「実行（Realize）」の2つの段階に分けています。ガイドでは、S/4HANAの1709から2023までのリリースから、2025へ上げられると書かれています。

    準備の段階

    • 計画：SAP Readiness Check for SAP S/4HANA upgrades で、今のシステムを分析し、関係する変更点（Simplification Item）・独自開発のコードの影響・アドオンが対応しているかなどを洗い出す。必須ではないが、強く勧められている。リリースのアップグレードで使うもので、同じリリースの中のFPS・SPSの更新では対象外とされている

    • Maintenance Planner：最初の手順として必ず使う。アドオン・有効にしている業務機能（ビジネスファンクション）・業種のソリューションが新しいリリースに対応しているかを確かめ、対応していないものがあればアップグレードを止める。そのうえで、実行に使うファイルを作る

    • Simplification Item-Check（SI-Check）：システムを技術的に上げられるか、上げたあとすぐに業務を動かせるかを確かめる。必須の手順

    • 独自開発のコードの確認：独自開発のコードを、新しいリリースの変更点に照らして確かめる。必須ではないが強く勧められており、使っていないコードを整理する作業と一緒に行うのがよいとされている

    • 業務ごとの準備：チェックの結果から見つかった、業務ごとの手作業の準備

    実行の段階

    • Software Update Manager（SUM）：実際にソフトウェアを上げる道具。SI-Checkは、SUMの始めと、システムを止める直前にも流れ、重大な問題が残っていると先へ進めない

    • 業務ごとの後続の作業：チェックの結果から見つかった、上げたあとの手作業

    ガイドでは、アップグレードに伴うデータの変換は、ふつうはシステムを止めているあいだに行うが、Silent Data Migrationという仕組みで、上げたあとの業務の時間中に流せるものもあると説明されています。

    4. 業務のコンサルが関わるところ

    アップグレードの道具を動かすのは、主にBasisや開発の担当です。ここからは、ガイドの内容から整理した、業務のコンサルが関わりやすいところの見方です。システムの基盤の仕事は、別記事「SAP Basisの仕事｜Basisの案件で求められる経験」で整理しています。

    変更点（Simplification Item）を業務の言葉に直す

    ガイドでは、Simplification Item Catalog（変更点の一覧）には、そのアップグレードに関係しない項目も多く含まれるため、自社に関係するものを見つけ、それぞれのSAP Noteを読んで影響を確かめる必要がある、と説明されています。SI-Checkの黄色のメッセージについても、「技術的には上げられるが、データや機能の変化、上げたあとの作業の知らせを含むことがある」として、軽く見ないよう注意されています。例として、独自に追加したテーブルの項目は、何もしなければアップグレードで引き継がれずデータが失われる、と書かれています。

    どの変更点が、どの業務・どの帳票・どの画面に効くのかを、業務の担当と一緒に読み解くのは、業務のコンサルの仕事になりやすいところです。

    上げる前と後で、業務のデータを比べる

    ガイドでは、Data Transition Validation（DTV）という道具が紹介されています。業務の帳票や取引を使って、アップグレードの前と後で業務のデータを比べるもので、準備の段階で、どの帳票で確かめるかを、業務の部門や社内外の監査人と決めておく、と説明されています。上げる前にデータを取り出し、上げたあとに新しいリリースで正しさを確かめる流れです。

    「何をもって正しく上がったとするか」を業務の側と決めることは、テストの計画そのものです。テストの進め方は、別記事「SAPのテスト・UATの案件｜テストリーダー・テストマネジメントで求められる経験」で整理しています。

    権限と画面の見直し

    ガイドでは、アップグレードのあとに、SAPが届ける権限の初期値が変わっている可能性があるため、その比較と取り込み、ロールの見直しをするよう書かれています。SAP Fioriの画面（アプリ）についても、上げたあとの作業が並んでいます。新しいリリースで画面や権限が変わると、利用者の操作の手順書や教育にも影響が出ます。

    5. アップグレードを計画するときに決めること

    ここからは、SAPの公式資料から整理した一つの見方です。会社の使い方や、オンプレミスかPrivate Editionかによって答えは変わるため、実際の判断は、情報システムの部門や運用の担当と決めることになります。

    • どのリリースへ、いつ上げるか：今のリリースの通常の保守がいつ終わるかと、新しいリリースの機能を使いたい時期から決める

    • 新しい機能を使うか：上げるだけにするのか、新しいリリースの機能を合わせて使い始めるのか。使うなら、業務の変更と教育も範囲に入る

    • 独自開発をどこまで直すか：チェックで見つかった独自開発のうち、直すもの・使っていないので外すもの・標準の機能に置き換えるものを分ける

    • テストの範囲：どの業務のシナリオを、どの深さで確かめるか。上げる前と後で比べる帳票を、業務の部門や監査人と決める

    • 止める時間と切り替えの日：システムを止められる時間と、決算などの業務の山を避けた日程

    • 周辺のシステム：連携しているシステムやアドオンが、新しいリリースでも動くか

    ご自身の運用保守やテストの経験が、この中のどこに近いか気になった方へ。希望条件をLINEで登録いただくと、近いSAP案件が出たときに個別にご案内します。

    SAP案件の受け取り方を見る

    6. この領域の仕事で問われやすい経験

    当社に届いた2026年7月〜11月の案件には、すでに使っているS/4HANAのリリースを上げる作業（バージョンアップ・リリースアップグレード）を条件に入れたSAP案件はありませんでした。「コンバージョン」の語が入った案件はありましたが、どちらもECCからの移行の方式やSAC（計画の道具）の話で、アップグレードの経験を条件にしたものではないため、この記事では扱っていません。以下は、SAPの公式資料から考えた、この領域の仕事で問われやすい経験の見方です。

    1. 変更点の影響を調べた経験

    変更点の一覧やSAP Noteを読み、自社の業務・帳票・独自開発にどう効くかを洗い出した経験です。ECCからの移行で変更点を調べた経験も、ここに近い経験です。

    2. 回帰テスト（変わっていないことの確認）を計画した経験

    アップグレードでは、新しい機能より「今の業務がそのまま動くか」を確かめるテストが中心になります。業務のシナリオを選び、テストの範囲と合否の決め方を業務の部門と決めた経験です。

    3. 独自開発の整理に関わった経験

    チェックで見つかった独自開発を、直す・外す・標準に置き換えるに分け、開発の担当と進めた経験です。

    4. 権限やFioriの見直しに関わった経験

    上げたあとのロールや画面の変化を確かめ、利用者への案内や手順書の更新をした経験です。

    5. 止める時間と切り替えの計画をした経験

    システムを止められる時間の中で作業を組み、業務の部門と切り替えの日を決めた経験です。本番切替の計画は、別記事「SAPの本番切替（カットオーバー）の案件｜切替計画・リハーサルで求められる経験」で整理しています。

    運用保守の中でアップグレードを担うことも多いため、運用保守の案件で求められることは、別記事「SAP運用保守の案件｜導入との違いと、運用保守で求められる経験」もあわせてご覧ください。

    7. この領域の経験を経歴書で伝えるときのポイント

    「S/4HANAのバージョンアップを担当」とだけ書くと、案件の担当者は、どのリリースから、何を担当したのかを判断できません。次の点が読み取れるようにしておくのがおすすめです。

    • リリース：どのリリースからどのリリースへ上げたか（例：2021から2023）。オンプレミスかPrivate Editionか

    • 範囲：変更点の影響調査・テスト・独自開発の整理・権限・切り替えのどこを担当したか

    • 業務の領域：会計・販売・購買など、どの業務の確認を受け持ったか

    • 規模：テストのシナリオの数、関わった独自開発の数、チームの人数

    • 役割：計画を立てたのか、テストを実行したのか、業務の部門との調整をしたのか

    経歴書の全体の書き方は、別記事「SAPコンサルの職務経歴書｜案件の担当者に伝わる書き方」で整理しています。

    8. よくある質問

    FPSやSPSを当てるのも、アップグレードですか？

    SAP Learningでは、新しいベースリリースへ上げることを「アップグレード」、FPSやSPSを当てることを「アップデート」と分けて説明しています。アップグレードガイドでも、SAP Readiness Checkはリリースのアップグレードで使うもので、同じリリースの中のFPS・SPSの更新では対象外とされています。

    1つずつ順にリリースを上げる必要がありますか？

    SAPのアップグレードガイド（S/4HANA 2025）では、1709から2023までのリリースから、2025へ上げられると書かれています。どの版の組み合わせで上げられるかの細かな条件は、ガイドが示すSAP Noteで確かめる必要があります。

    Private Editionなら、アップグレードはSAPに任せられますか？

    SAP Learningでは、Private EditionではRISE with SAPのサービスとして年に1回のアップグレードをSAPに頼め、技術的なアップグレードはSAPが行う一方、計画・準備・テストなどの技術以外の作業は、利用する会社か導入のパートナーが担うと説明されています。

    まとめ

    • アップグレードは、すでに使っているS/4HANAを新しいベースリリースへ上げること。ECCからの移行（システム変換）や、FPS・SPSを当てるアップデートとは別の作業

    • 2023のリリースから、リリースは2年に1回、各リリースの通常の保守は7年になった

    • アップグレードは準備と実行の段階に分かれ、Maintenance Planner・SI-Check・独自開発の確認・SUMなどの道具を使う

    • 業務のコンサルは、変更点を業務の言葉に直すこと、上げる前と後のデータの比べ方とテスト、権限や画面の見直しに関わりやすい

    • 計画では、上げる時期・新しい機能を使うか・独自開発の扱い・テストの範囲・止める時間を決める

    SAPのモジュール全体の中で、各領域がどうつながっているかは、別記事「【2026年版】SAPモジュール一覧と業務のつながり」で整理しています。

    アサインコネクトは、SAP人材に特化した案件紹介サービスです。

    希望条件をLINEで登録すると、条件に合うSAP案件を個別に受け取れます。

    SAP案件を受け取る方法を見る

    参考資料

     
     

    アサインコネクト｜SAP案件・キャリア

     
     
    SAPフリーランスの案件・独立・キャリア情報を整理して発信。自分の経験をどう活かせるか、案件選びで何を見るかをわかりやすく届けます。案件・キャリアのご相談もお気軽にどうぞ。

    あなたへのおすすめ