SAP Basisは「守りのコスト」だけではなくなった

SAP Basisは、これまで長く「システムを止めないための領域」と見られてきました。
監視、ジョブ運用、移送、ユーザ管理、パッチ適用、障害対応…。いずれもSAPシステムの安定稼働に欠かせない業務です。

一方で、SAPシステムが正常に稼働している限り、その価値は見えにくいという側面があります。
そのため、経営層からは「できるだけコストを抑えたい領域」と捉えられることも少なくありませんでした。
しかし、RISE with SAPをはじめとするクラウド化が進み、SAP Business Technology Platform（SAP BTP）による拡張、外部サービスとの連携、データ活用、AI活用が経営アジェンダに置かれる中で、SAP Basisの役割は変わりつつあります。

実際、2026年5月のSAP Sapphireでは、SAP BTP、SAP Business Data Cloud、SAP Business AIを単一のガバナンス環境へ統合する「SAP Business AI Platform」が発表されました。拡張、データ、AIを個別に扱うのではなく、一体として捉える方向性は、SAP社自身の戦略にも表れています。変わったのは、安定運用の重要性ではありません。
SAP Basis領域における設計判断が、企業の将来の選択肢を左右するようになったことです。

RISE with SAPを通じて利用するクラウドERP環境では、SAPシステムを稼働させるインフラの提供に加え、契約内容やサービス範囲に応じて、従来ユーザ企業や保守ベンダーが担っていた技術基盤の運用の一部が、SAP社側へ移ります。
しかし、どのサービスと接続するのか、構成変更に伴う業務影響をどのように評価するのかまで、SAP社が決めてくれるわけではありません。
実作業を行う主体が変わっても、企業側に残すべき判断があります。新しい技術をPoC（概念実証）で終わらせず、本番業務へ組み込むためには、データ、連携、権限、監視、性能といった技術的な前提条件を整える必要があります。

「攻めのSAP Basis」が担う5つの設計領域

「攻めのSAP Basis」が横断的に関与すべき設計領域は、大きく5つに整理できます。
もちろん、これら5つの領域をSAP Basisだけで設計するわけではありません。業務、アプリケーション、データ、セキュリティ、インフラの各担当者と連携しながら、それぞれの設計をSAPシステム全体として整合させる必要があります。
攻めのSAP Basisに求められるのは、複数領域にまたがる技術的な論点をつなぐことです。

これらはいずれも、手順書に従って処理する作業ではありません。
複数の選択肢を比較し、実現性、コスト、リスク、将来性を天秤にかける、判断そのものです。

例えば、製造業では、生産計画や製造実績のデータをAIエージェントへ高頻度で連携する構成を採用した結果、想定を超えるデータ取得やインターフェース処理が発生し、基幹システム側の処理に遅延が生じる可能性があります。

SAP S/4HANAやSAP BTPとAIサービスを接続するための製品や選択肢は、以前より増えています。
しかし、本番業務で継続的に利用するためには、データの取得方式、連携頻度、処理量、ピーク時の負荷を事前に見積もる必要があります。
基幹システムから直接取得するのか、SAP BTPやデータ基盤を介するのか。リアルタイム性を優先するのか、一定の遅延を許容して負荷を抑えるのか。

接続できることと、本番業務として継続的に利用できることは別です。
こうした選択肢を比較し、SAPシステム全体への影響を見極めることが、攻めのSAP Basisに求められる設計判断です。

SAP Basis運用は「守り」と「攻め」に分けて考える

非定型の設計判断と、日々の定常運用では、求められる能力も運営方法も異なります。
そこで、これからのSAP Basis運用は、「守り」と「攻め」に分けて考える必要があります。

守りのSAP Basisは、監視、ジョブ運用、移送、ユーザ管理、定期作業、障害の一次対応といった定常運用を指します。
これらは引き続き欠かせない業務ですが、目指すべき方向は明確です。
手順を標準化し、監視や作業を可能な限り自動化し、リモート保守やチーム運営によって、属人性を抑えることです。
実際、SAPシステム運用を長年特定の担当者に依存し、その担当者の定年退職をきっかけに、運用体制の見直しを迫られる企業があります。
守りのSAP Basisで求められるのは、特定の個人が長年の経験によってシステムを支え続けることではありません。担当者が変わっても一定の品質を維持できる、再現可能な運用をつくることです。
NHSが提供する運用維持支援（AMOサービス）でも、窓口となるフィールドマネージャーを固定しながら、実際の障害対応や定常作業は、複数の技術者がチームで支える体制を取っています。
特定の担当者への依存を減らし、品質を維持しながら運用コストを最適化するためです。

一方、攻めのSAP Basisは性質が異なります。SAP BTP、外部クラウドサービス、データ基盤、AIなどの新しい技術を、企業システムとして安全かつ継続的に利用できる構造へ落とし込む役割です。
ここで求められるのは、作業の速さや手順の正確さだけではありません。
経営や業務部門の構想を技術要件へ翻訳し、SAP社や各ベンダーの提案を評価し、システム全体への影響を見極める能力です。
言い換えれば、攻めのSAP Basisは「作業者」ではなく、企業の意思決定を技術面から支える「技術参謀」なのです。
NHSのSAPテクニカルアドバイザリでは、システム設定の変更や障害復旧といった実作業ではなく、SAP社の回答や他ベンダーの提案に対するレビュー、構成変更時の影響評価、セカンドオピニオンを提供します。
SAPシステムとインフラを横断する専門家が、企業側の意思決定に必要な材料を補い、「技術参謀」としてその判断を支援します。

重要なのは、守りと攻めを同じ運営原則で扱わないことです。
守りでは、標準化、再現性、コスト、サービスレベル合意（SLA）が評価軸になります。
攻めでは、実現可能性、リスク、将来性、事業への貢献が評価軸になります。
同じ担当者が両方に関与する場合であっても、求められる役割と評価基準は明確に分ける必要があります。

おわりに

経営の観点から見れば、IT投資には、システムを安定して稼働させるだけでなく、データ活用やAI活用を継続的に実現できる環境を整えることが求められています。
定常運用は標準化し、特定の個人への依存とコストを減らす。
一方で、SAP BTP、データ、AIなど、新しい技術を本番業務へ組み込むための設計には外部の専門知見を活用しながらも、判断を主導できる能力は企業側に残すことが重要です。

RISE with SAPによって、従来のインフラ運用や定型的な作業は、次第にサービス化されていきます。
しかし、それは企業から技術力が不要になることを意味するわけではありません。
むしろ、クラウドサービスやAIが継続的に進化する時代だからこそ、変化に対応するための設計・判断能力は、組織の中に持ち続ける必要があります。

Clean coreが、将来の変化に対応しやすいシステム構造を維持するための考え方だとすれば、Fit to Standardは、標準に合わせる領域と、企業の差別化を残す領域を見極める考え方です。
SAP Basisには、その方針を技術構成へ落とし込み、SAP BTP、データ基盤、外部サービスを適切に組み合わせながら、データ活用やAI活用を継続的に支えられるシステム構造を設計する役割が求められます。

これから問われるのは、SAP Basis要員を何人抱えるかではありません。
どの領域を標準化し、どの判断能力を組織内に残すのか。その設計こそが、これからのSAP Basis戦略になります。
作業を担うSAP Basisから、企業の判断を支えるSAP Basisへ。
これからSAP Basisに求められるのは、企業の新しい選択肢を技術面から成立させる「技術参謀」としての役割です。