COLUMN

SAP S/4HANAのバージョンアップ ─ 上げる周期を、導入したときに決めておく

SAP公開日 更新日 約9分で読めます

SAP S/4HANAのバージョンアップ ─ 上げる周期を、導入したときに決めておく

この記事の要点

  1. 01S/4HANAのバージョンアップは、リリースを上げるアップグレードと、同じリリースの中のアップデートに分かれる
  2. 02新しいリリースは2年ごと。2023年版からは、各リリースのメインストリーム保守は7年
  3. 03上げる周期を決めていないと、保守の期限が近づいてから準備が始まる。周期は導入したときに決めておく
目次7項目
  1. 01S/4HANAのバージョンアップは、アップグレードとアップデートに分かれる
  2. 02リリースは2年ごと、保守は7年。上げない選択にも期限がある
  3. 03バージョンアップの作業量は、作り込みと連携の量で動く
  4. 04上げる周期は、導入したときに決めておく
  5. 05クラウド版は更新をSAPが管理する。それでも発注側に仕事は残る
  6. 06S/4HANAのバージョンアップを外に頼むときは、準備の範囲を先に決める
  7. 07よくある質問

SAP S/4HANAを稼働させたあと、次に来る大きな仕事がバージョンアップです。導入のときほど話題になりませんが、稼働した日から、保守の期限に向かって時計は進んでいます。

筆者は、バージョンアップが重くなる会社には共通点があると見ています。上げる周期を決めていないことです。期限が近づいてから準備を始めると、作り込みの検証、テスト、利用者への教育が一度に重なります。上げる周期は、導入したときに決めておくものだと筆者は考えています。

この記事は、自社の環境で動かすSAP S/4HANA(オンプレミス版と、会社ごとの環境を持つクラウドの形)を主に扱います。SAPが更新を管理するクラウド版は、後半で触れます。

S/4HANAのバージョンアップは、アップグレードとアップデートに分かれる

日本語で「バージョンアップ」と呼んでいる作業は、SAPの言葉では2つに分かれます。SAPの公式資料は、次のように使い分けています。

  • アップグレード:低いリリースから高いリリースへ上げること。たとえば、SAP S/4HANA 2023から2025へ
  • アップデート:同じリリースの中で、より新しい修正の束(スタック)を当てること

同じリリースの中の更新にも、2種類あります。新しいリリースが出たあと、まず、機能の追加を含むことがあるフィーチャーパッケージスタック(FPS)が3回出ます。そのあとは、修正と法改正への対応が中心のサポートパッケージスタック(SPS)に切り替わります。

アップグレードとアップデートでは、テストと教育の量が違う

バージョンアップは、リリースを上げるアップグレードと、同じリリースの中で修正の束を当てるアップデートに分かれる。1つのリリースの中では、FPSが3回出たあとSPSに切り替わる。テストと利用者への教育の量は、リリース、FPS、SPSの順に軽くなる。
図1 バージョンアップの2つの種類と、1つのリリースの中で出る順番(出典1をもとに作成)。テストと教育の量の段階は、表1の比較を筆者が3段で示したもの。
種類 例 頻度 中身 テスト 利用者への教育
リリース(アップグレード) SAP S/4HANA 2025 2年に1回 大きな変更、機能の追加、機能の置き換え 入念なテストが必要 通常は必要
FPS(アップデート) 2023 FPS01 リリースごとに3回 小さな変更と機能の追加。法改正への対応と修正を含む 既存の業務の回帰テストと、新機能のテストが必要 一部で必要になることがある
SPS(アップデート) 2023 SPS04 SPS04以降、年に1〜2回 主に修正と法改正への対応 回帰テストを推奨 通常は不要

表1 リリース、FPS、SPSの違い(出典1の比較表をもとに作成)。

SAPは、安定のために、最新のSPSへ定期的に更新することを勧めています。SPSの更新は小さく、アップグレードは大きい。この違いを分けて予算と体制を組むことが、最初の一歩です。

ポイント

「バージョンアップ」をひとまとめにしないでください。リリースを上げるアップグレードと、同じリリースの中のアップデートでは、テストと教育の量が違います。

リリースは2年ごと、保守は7年。上げない選択にも期限がある

SAPは2022年9月、S/4HANAのリリースと保守の方針を変えると発表しました。発表の要点は3つです。

  • 2023年版から、新しいリリースは2年ごとに出る
  • 2023年版から、各リリースのメインストリーム保守は7年になる(それまでは5年)
  • 2040年までは、少なくとも1つのリリースを保守の対象に置く、という方針は変えない

7年あるなら、当分は上げなくてよいように見えます。けれども、7年は稼働した日から数える期間ではありません。リリースごとに決まる期間です。導入のプロジェクトに時間がかかれば、稼働した日には、残りの期間はすでに減っています。上げない選択をしても、期限は来ます。SAPの保守の段階と、期限を過ぎたときに何が止まるかは、SAPの運用保守の記事で扱っています。

リリースは2年ごとに出て、それぞれ7年の保守がある。上げる時期は自社で決める

2023年から2032年までの時間軸。2023年版と2025年版には、それぞれ7年のメインストリーム保守の帯がある。次のリリースは2年ごとの周期から描いた目安で2027年から。自社の予定の例では、2024年に2023年版で稼働し、2029年に上げたリリースへ移る。

稼働した日から、保守の残りは減っていく。どのリリースへ、いつ上げるかは、期限から逆算して決める。

図2 S/4HANAのリリースと保守の期間(出典1・2をもとに作成)。2023年版の提供開始は2023年10月で(出典2)、帯の左端はその年の途中から数える。帯は年単位の目安で、リリースごとの正確な日付はSAPの製品別の情報で確かめる。自社の予定は例示。

バージョンアップの作業量は、作り込みと連携の量で動く

アップグレードで発注側に生じる作業を、SAPの公式資料は次のように説明しています。新しいリリースには、多くの新機能と拡張に加えて、機能やオブジェクトの廃止や置き換えが含まれる。そのため、事前の準備が要る。例として挙がっているのは、自社で開発したプログラムの中で置き換えが必要なものを調べることと、利用者の権限を調整することです。アップグレードのあとには、入念なテストと、利用者への教育が続きます。

ここから、筆者は作業量を動かすものを3つに整理しています。

作業量を動かす3つは、どれも導入のときに手を打てる

追加開発の本数、周辺システムとの連携の本数、テストのやり方の3つについて、導入のときにできることと、上げるたびに起きる作業を左右に並べた図。追加開発は導入のときに標準に寄せて減らし、残したものは一覧にしておく。上げるたびに、置き換えが必要かを1本ずつ調べて直し、テストする。
図3 アップグレードの作業量を動かすもの。筆者の整理。準備とテストが要ることは出典1による。

追加開発が、リリースを上げるたびに検証の対象になることは、SAP移行の方式の記事でも扱いました。導入のときに減らしたアドオンは、その後のバージョンアップのたびに効いてきます。

注意

導入のプロジェクトが終わると、テストのシナリオと追加開発の一覧は、更新されなくなることがあります。次に上げるときに使えるよう、持ち主を決めて保っておいてください。

上げる周期は、導入したときに決めておく

SAPは、同じ発表の中で、利用企業に頻繁なアップグレードを勧めています。あわせて、2年ごとのリリースの合間に機能を届ける仕組みを増やし、アップグレードの回数を減らせるようにする、とも説明しています。毎回上げるか、間を空けるかは、利用企業が決めることです。

周期の決め方は、大きく2つあります。

周期の決め方は2つ。どちらでも、決めていない状態よりは軽くなる

リリースごとに上げるこまめな決め方と、リリースを飛ばして上げる間を空ける決め方を、1回の重さ、回数、向く会社、先に決めることで比べた図。どちらでも、上げる周期、準備を始める時期、予算を取る年度、判断する人の4つを、導入のプロジェクトを閉じる前に書いておく。

周期が決まっていれば、準備の始めどきと予算の年度が決まる。決めていないと、期限が近づいてから一度に重なる。

図4 上げる周期の2つの決め方。向く会社と重さの比べ方は筆者の整理。

どちらが正しいということはありません。筆者が勧めるのは、導入のプロジェクトを閉じる前に、次の4つを書いておくことです。

  • 上げる周期(リリースごとか、飛ばすか)
  • 準備を始める時期
  • 予算を取る年度
  • 上げるかどうかを判断する人

稼働後の運用の体制を決めるときに、あわせて決めておきます。すでに稼働している会社は、いまの時点で同じ4つを書き出します。

ポイント

上げる周期は、稼働してから考えるより、導入のプロジェクトを閉じる前に書いておきます。準備の始めどきと、予算の年度が決まります。

クラウド版は更新をSAPが管理する。それでも発注側に仕事は残る

SAP S/4HANA Cloud Public Editionでは、事情が違います。SAPの製品ページは、アップデートはSAPによって完全に管理される、と説明しています。

それでも、発注側の仕事がなくなるわけではないと筆者は考えています。更新のあとに自社の業務が同じように回るかを確かめること、変わった画面や機能を利用者に伝えること、周辺システムとの連携を確かめることは、利用する会社の側に残ります。更新の時期と、発注側が確かめる範囲は、契約と製品の案内で確かめてください。

クラウド版でも、更新のあとに確かめて伝える仕事は発注側に残る

更新のたびに要る4つの仕事を、自社の環境で動かす版とPublic Editionで比べた図。更新の作業は、自社の環境では発注側、Public EditionではSAPが管理する。業務が同じように回るかの確認、利用者への案内、周辺システムとの連携の確認は、どちらの版でも発注側に残る。
図5 更新のたびに要る仕事を、自社の環境で動かす版とPublic Editionで比べたもの。Public Editionの更新をSAPが管理することは出典3による。発注側に残る仕事は筆者の整理。

S/4HANAのバージョンアップを外に頼むときは、準備の範囲を先に決める

アップグレードの作業を外部の会社に頼む場合、見積もりが割れやすいのは、準備とテストの範囲だと筆者は見ています。

  • 追加開発の調査と修正を、どこまで含めるか
  • テストのシナリオを、誰が用意し、誰が実施するか
  • 周辺システム側の確認を、誰が取りまとめるか
  • 利用者への教育を、含めるかどうか

依頼の前に4つをそろえると、各社の見積もりを比べやすくなる

見積もりが割れやすい準備とテストの範囲として、追加開発の調査と修正をどこまで含めるか、テストのシナリオを誰が用意し誰が実施するか、周辺システム側の確認を誰が取りまとめるか、利用者への教育を含めるかの4つを並べ、そろえると各社の見積もりを比べやすくなることを示した図。
図6 S/4HANAのバージョンアップを外に頼む前に、そろえておく4つ。筆者の整理。

この4つを依頼の前にそろえておくと、各社の見積もりを比べやすくなります。前提のそろえ方は、導入のときと同じです。いまSAP ERP 6.0を使っていて、これからS/4HANAへ移る会社は、先にSAP 2027年問題の記事をご覧ください。

Never Redは、SAPの会計領域について、稼働後の定着と、標準機能の活用の見直しを支援しています。追加開発の棚卸しや、会計領域のテストの組み立てもご相談いただけます。支援の範囲はSAP導入支援をご覧ください。

まとめ

  • バージョンアップは、リリースを上げるアップグレードと、同じリリースの中のアップデートに分かれる
  • 新しいリリースは2年ごと。2023年版からは、各リリースのメインストリーム保守は7年
  • アップグレードには、事前の準備と、入念なテスト、利用者への教育が要る
  • 作業量は、追加開発の本数、連携の本数、テストのやり方で動く
  • 上げる周期、準備を始める時期、予算の年度、判断する人を、導入のときに決めておく

よくある質問

SAP S4HANAのバージョンアップは、何年ごとに必要ですか。
決まった年数はありません。新しいリリースは2年ごとに出て、2023年版からは各リリースのメインストリーム保守が7年です。メインストリーム保守の中で使い続けるには、使っているリリースの期限までに、より新しいリリースへ上げます。毎回上げるか、間を空けるかは、自社で決めます。
アップグレードとアップデートは、何が違いますか。
アップグレードは、低いリリースから高いリリースへ上げることです。アップデートは、同じリリースの中で、より新しいスタック(FPSやSPS)を当てることです。SAPの公式資料によると、アップグレードには入念なテストと利用者への教育が要り、SPSへのアップデートでは、テストと教育はわずかか不要とされています。ただし、回帰テストは勧められています。
バージョンアップの費用と期間は、どれくらいですか。
一律の目安は示せません。追加開発の本数、周辺システムとの連携の本数、テストの範囲で変わるからです。見積もりを頼む前に、準備とテストの範囲をそろえてください。
バージョンアップをしないと、どうなりますか。
使っているリリースのメインストリーム保守が終わると、その先の保守の内容が変わります。期限と、その後の保守の段階は、SAPが製品とリリースごとに公開しています。詳しくはSAPの運用保守の記事をご覧ください。

SAP S/4HANAのバージョンアップの計画や、稼働後の運用についてのご相談は、お問い合わせからお寄せください。

出典

  1. アップグレードとアップデートの定義、リリースが2年に1回であること、FPSが3回・SPSがその後であること、リリース・FPS・SPSの比較表(中身、テスト、利用者への教育)、アップグレードの事前の準備(自社開発のオブジェクトの置き換えの確認、権限の調整)とその後の作業(入念なテストと教育)、最新のSPSへの定期的な更新の推奨:SAP Help Portal「Getting Started With SAP S/4HANA 2025」(PDF)
  2. 2023年版からの2年ごとのリリース周期、各リリースのメインストリーム保守が7年(それまでは5年)、2040年まで少なくとも1つのリリースを保守の対象に置く方針、頻繁なアップグレードの推奨とアップグレードの回数を減らす取り組み:SAP News「New SAP S/4HANA Release and Maintenance Strategy to Deliver Greater Innovation and Flexibility」(2022年9月15日)
  3. SAP S/4HANA Cloud Public Editionのアップデートが、SAPによって管理されること:SAP Japan「SAP Cloud ERP」(SAP S/4HANA Cloud Public Editionの製品ページ)

CONSULTATION

SAP導入・S/4HANA移行のご相談

延長保守か移行か、移行ならどの方式か。会計の設計まで含めて、方針を決める段階からご一緒します。SAP FI(財務会計)の導入と経営管理の設計を、同じ担当者が受け持ちます。

相談する →SAP導入支援を見る →事業紹介を見る →

あわせて読みたい

← コラム一覧へ戻る