S/4HANA移行の検討に入ると、必ずこの問いにぶつかる。「RISE with SAPにすべきか、それとも自社でクラウド運用するか、オンプレを続けるか」。ベンダーからはRISEを、既存のインフラ部門からはオンプレ継続を勧められ、判断軸のないまま声の大きいほうに流れていく。だが選択の本質は、どれが新しいかでも、どれが安いように見えるかでもない。この3つは、自社が何を握り、何を手放すかが根本的に違う。本稿は、コスト構造・統制責任・カスタマイズ自由度の3軸で、自社の制約から選ぶための判断軸を書く。

POINT
2027年の保守期限は「いつ移行するか」を迫るものであって、「RISEにするか」を決めるものではない。RISE with SAP(SAP管理のマネージドクラウド)・自社クラウド運用(ハイパースケーラでの自社管理)・オンプレは、①コスト構造(CapEx対OpEx)②統制責任(どこまで自社が握るか)③カスタマイズ自由度(クリーンコア制約)で性質が分かれる。期限に急かされて選ぶと、統制と自由度を手放したことに運用が始まってから気づく。

まず「時間軸」と「方式」を分ける

議論が混乱する最大の原因は、「いつやるか(時間軸)」と「どの方式か(RISE/自社/オンプレ)」を混ぜてしまうことだ。この二つは別の問いである。

時間軸のほうは、外部要因でほぼ決まっている。SAPは従来型のBusiness Suite 7(ECC等)のメインストリーム保守を2027年末で終了し、有償の延長保守でも2030年末までとしている(SAP)。つまり遅くとも2027年までにはS/4HANAへ移る意思決定が要る。これは動かせない締切だ。

だが「2027年までに移る」ことと「RISEを選ぶ」ことは、まったく別の判断である。保守期限に追われた会社ほど、時間軸の切迫を方式選定の理由にすり替え、「時間がないからとりあえずRISE」を選ぶ。移行の緊急性は、方式を吟味しない言い訳にはならない。移行アプローチ(現行踏襲か再構築か)の論点は別稿に譲る(S/4HANA移行のアプローチ)。ここでは方式の選び方に絞る。

統制責任――「委ねる」か「握る」か

3方式の最も深い違いは、運用の責任と統制をどこまで自社が握るかにある。RISEはSAPが管理するマネージドサービスで、インフラ運用やアップデートの多くをSAPに委ねる。自社クラウド運用やオンプレは、その多くを自社(と協力会社)が握る。

RISEと自社運用は『責任分界点』が根本的に違う
RISE with SAP委ねる(マネージド)
運用負担の軽さ
統制の自社裁量
人材要件
インフラ・OS・DBの運用やアップデートをSAPに委ねる。自社の運用要員は最小で済む。反面、アップデートの時期や環境の細部はSAPの管理下に入り、監査対応や統制の証跡もその枠組みに合わせる必要がある。「運用できる人がいない」会社には現実的な選択。
自社クラウド/オンプレ握る(セルフマネージド)
運用負担の軽さ
統制の自社裁量
人材要件
ハイパースケーラ上やオンプレで自社が運用する。アップデートのタイミング、統制の設計、監査対応を自社の都合で握れる。反面、SAPを運用できる人材と体制が必須。ここが欠けたまま握ると、保守も統制も回らなくなる。
RISEは運用負担を委ねる代わりに、統制の細部とタイミングをSAPの土俵に預ける。自社運用は握るぶん重いが、統制・監査対応・変更タイミングを自社の都合で設計できる。どちらが良いかは、自社にSAPを運用できる人材とガバナンスがあるかで決まる。

内部統制の観点では、どちらを選んでも証跡・承認・モニタリングの設計責任は自社に残る点は変わらない(S/4HANAで内部統制を効かせる)。違うのは、その統制をSAPの枠組みの中で組むか、自社の裁量で組むかである。

コスト構造とカスタマイズ自由度

残る2軸も、方式選定を左右する。

コスト構造(CapEx対OpEx)。 RISEはサブスクリプション型で、初期投資(CapEx)を抑えて費用を運用コスト(OpEx)に平準化する。オンプレはハードウェアやライセンスの初期投資が重い。ここで注意すべきは、「OpExだから安い」わけではないことだ。サブスクは長期で累積するため、5年・7年の総所有コスト(TCO)で比べないと判断を誤る。安く見えるOpExが、期間を通せばオンプレを上回ることは珍しくない。財務としては、キャッシュフローの平準化に価値があるか、総額で有利かを分けて評価する。

カスタマイズ自由度(クリーンコア)。 S/4HANAではSAPが「クリーンコア」――標準のコアを改変せず、拡張はコアの外(SAP BTPなどの外部レイヤー)に出す――という方針を推している。RISEはこの思想と強く結びついており、コアへのアドオン(独自改造)に制約がかかる。長年アドオンを積み上げてきた会社ほど、この制約は移行の難所になる。どこまで自社の独自要件を諦め、標準に寄せられるかが、RISEの適合可能性を決める。アドオンをどこまで作るか・標準に合わせるかの判断は、移行スコープの中核論点だ(S/4HANA移行のスコープ設計)。

自社の制約から選ぶ――最終確認

方式は「一般にどれが優れているか」で決まらない。自社の制約――人材・統制要件・既存アドオン・キャッシュ――から選ぶ。意思決定の前に、CFOと情シスで次を確認する。

RISE/自社運用/オンプレを選ぶ前の最終確認
  • SAPを自社で運用できる人材と体制があるか(無ければRISE寄り、あれば自社運用も選べる)
  • 統制・監査対応で、アップデート時期や環境を自社の都合で握る必要がどれだけあるか
  • 既存アドオンのうち、標準(クリーンコア)に寄せて捨てられるものと、どうしても残すものを仕分けたか
  • OpEx平準化の価値か、5〜7年TCOの総額有利か――どちらの物差しで選ぶかを先に決めたか
  • 2027年の保守期限までの移行スケジュールと、方式選定の吟味時間を分けて確保したか

「新しいから」「ベンダーが勧めるから」でRISEを選ぶのが最悪だ。RISEは運用負担を大きく下げる有力な選択肢だが、その代わりに統制の細部とカスタマイズの自由度を手放す。それが自社にとって痛くないなら合理的だし、痛いなら自社運用を選ぶ理由になる。この痛みの大小は、自社にしか判断できない。

まとめ
2027年の保守期限は「いつ移行するか」を迫るもので、「RISEにするか」を決めるものではない。RISE(委ねる/マネージド)・自社クラウド/オンプレ(握る/セルフマネージド)は、①統制責任(アップデート時期と統制を自社で握るか、SAPに委ねるか)②コスト構造(OpEx平準化か、TCO総額か。OpExは安いとは限らない)③カスタマイズ自由度(クリーンコアでアドオンをどこまで諦められるか)で分かれる。選ぶ物差しは「どれが新しいか」でなく「自社の人材・統制要件・既存アドオン・キャッシュという制約」。運用人材が無ければRISE、統制と自由度を握る必要が強く体制があれば自社運用。期限の切迫を方式選定の言い訳にした瞬間、統制と自由度を手放したことに後で気づく。