SAPとServiceNowによるERPモダナイゼーション

SAPとServiceNowによるERPモダナイゼーションとは、各プラットフォームに得意な仕事を任せ、両者をきちんとつなぐことです。SAP S/4HANAは、財務、調達、在庫、給与といった構造化されたトランザクションを担います。ServiceNowは、その周辺のワークフロー、つまり受付、承認、例外処理、サービスリクエストを担います。2つをつなぐのは、SAP Integration SuiteとServiceNow IntegrationHubです。このガイドは、SAP ECCまたは初期のS/4HANAシステムからのモダナイゼーションを計画するCIO、CFO、エンタープライズアーキテクトに向けたものです。どの業務をどちらに置くかを機能別に示し、AIの位置づけ、段階的なロードマップ、落とし穴を扱います。まず機能別の表を見てから、ロードマップに進んでください。

ERPモダナイゼーションは、私が手がけるほぼすべてのプログラムで取り上げられます。いまだにSAP ECCを使い続け、何年も前に退役させるべきだった環境で財務や業務を回している企業と仕事をしてきました。ある物流クライアントは、小さなプロセス変更を承認するために、手作業による引き継ぎを4回も経なければなりませんでした。私たちはSAPとServiceNowをつなぎ、処理時間と可視性の違いはすぐに表れました。

よく見かける間違いは、ERPモダナイゼーションを最新のSAPバージョンへのアップグレードだと思い込むことです。システム同士が連携していなければ、問題が新しいインターフェースに移っただけです。データはサイロに閉じ込められ、チームはツールを信頼しなくなり、人々は問題を解決する代わりに追いかけ回すことになります。

多くのチームは、モダナイゼーションを済ませたと思っています。実際には、アップグレードしただけです。その違いは、日々の業務に表れます。

モダナイゼーションとは、10年前の設計思想ではなく、今日の事業をシステムがどう支えるかを考え直すことです。アーキテクチャ、プロセス、データ、連携、ユーザー体験に及びます。

CIOからよく聞かれます。「つまり、クラウドへの移行の話ですか、それともERPの入れ替えですか」と。両方のこともありますが、一度にすべてというのはまれです。本当のモダナイゼーションは、たいていERPが事業の成長についていけなくなり、摩擦が目に見えるようになったときに始まります。

中東のある消費財クライアントは、まだSAP ECCを使っていました。財務は不良データのクレンジングに追われ、レポーティングは現場の動きに遅れていました。私たちは、導入そのものの見直しから始めました。技術だけでなく、プロセスが今の事業のやり方に合っているかどうかも見直しました。次にマスタデータ。そして自動化です。SAPが内部で対応できること、ServiceNowが穴を埋められること、特に承認、エスカレーション、プロセスの追跡を整理しました。この順序によって、経営陣は計画、タイムライン、そして追いかけられる成果を手にしました。

モダナイゼーションは、すべてを取り払うことを意味するのはまれです。多くの場合、企業はすでに機能しているものを残し、その周辺をモダナイズします。そこで、SAPとServiceNowが並んで力を発揮します。

SAP S/4HANAは、構造化された中核、つまり統制と一貫性のために作られたトランザクション、財務、調達、在庫を担います。ServiceNowは、SAPが直接担うようには設計されていない領域、つまり受付、承認、部門横断のワークフロー、例外処理を担います。クリーンコアがこの役割分担を後押しします。SAPの中核に属さないワークフローのロジックはどこかに置かなければならず、現実的な置き場所は、SAP BTP上のサイドバイサイド拡張かServiceNowです。拡張の選択肢は、私のクリーンコアガイドで説明しています。

両者の接続は、BTP上のSAP Integration Suite、ServiceNow IntegrationHub、オープンAPIを通じて行うため、後付けではなく、最初からそうだったかのように流れます。私の知るあるグローバル企業は、調達にSAPを使い、購買依頼の管理にServiceNowを使うことで、独自ポータルの開発を不要にしました。のちに同じ構造をベンダーのオンボーディングにも使いました。SAP Process Orchestration（PI/PO）をまだ使っているなら、移行を計画してください。PI/POが動作するSAP NetWeaver 7.5は、2027年末でメインストリームメンテナンスが終了し、オプションの延長メンテナンスは2030年まで利用できます。移行先のプラットフォームについては、私のSAP Cloud Integrationガイドで扱っています。

1. 04ServiceNowチームをまたぐ受付、承認、例外、サービスリクエスト
2. 03連携BTP上のSAP Integration SuiteとServiceNow IntegrationHub、オープンAPI経由
3. 02拡張中核に属さないロジックのための、SAP BTP上のサイドバイサイド拡張
4. 01SAP S/4HANA中核財務、調達、在庫、給与を、標準に近い形で保つ

機能別のユースケース

**人事：**SAP（またはSuccessFactors）が、従業員マスタデータ、ロール、給与、福利厚生を保持します。ServiceNowは、オンボーディングのタスク、アクセス権の付与、昇進の承認、オフボーディングを、IT、人事、財務、セキュリティの各部門にまたがって調整します。

**財務：**SAPは請求書を処理し、元帳を管理し、決算を実行し、法定レポートを作成します。ServiceNowはワークフロー層を担います。

財務プロセス	SAPの役割	ServiceNowの役割
買掛金管理	請求書を処理し、発注書と照合し、支払を管理する	請求書の受付、例外のルーティング、SLAの追跡
売掛金管理	顧客への請求書と回収を追跡する	請求に関する紛争と与信保留の依頼をルーティングする
決算	期末締め、会社間消去、レポーティング	決算チェックリスト、タスクの割り当て、未処理項目のアラート
経費管理	入力を取り込み、ポリシーを適用し、精算を起動する	レポートを承認にルーティングし、例外にフラグを立てる
調達から支払まで	購買依頼、発注書、入庫、ベンダー決済	受付フォーム、承認のルーティング、例外処理

**調達：**SAPは、ベンダーのマスタデータ、発注書、入庫、3点照合を管理します。ServiceNowは、受付、ベンダーのオンボーディング確認、入庫に関する問題、調達ヘルプデスクを扱います。

**施設とオペレーション：**SAPは、固定資産、保守コスト、スペースを追跡します。ServiceNowは、職場に関する依頼、保守作業指示、技術者の割り当て、アクセス権の依頼、インシデントのルーティングを扱います。

モダナイゼーションの議論でAIが取り上げられる場面は増えており、期待が成果を追い越すこともあります。実際には、AIはエッジケースを処理し、繰り返し作業を自動化し、人が見落とすものを浮かび上がらせます。SAP側では、SAPのAIアシスタントであるJouleが、S/4HANA、SuccessFactors、Ariba、SAP Buildにまたがって動作します。ServiceNow側では、Now Assistが、IT、人事、カスタマーサービスの各ワークフローに生成AIを取り込みます。

仕事の分かれ方は、おおむね次のとおりです。

AIのユースケース	SAPの役割	ServiceNowの役割
請求書照合	発注書、入庫、請求書を照合し、異常にフラグを立てる	例外をルーティングし、リスクの高い不一致を優先付けする
予知保全	設備データから、使用状況と故障パターンを分析する	保守チケットを起票し、技術者のスケジュールを組む
キャッシュフローのアラート	過去実績から資金ポジションを予測する	流動性のしきい値を下回ったときに、アラートとワークフローを起動する
バーチャルエージェント	Jouleが、SAPアプリケーション全体にわたる自然言語の質問に答える	バーチャルエージェントとNow Assistが依頼を処理し、SAPのバックエンドを呼び出す
異常検知	SAP BTP上のモデルや組み込みアナリティクスが、トランザクションの外れ値にフラグを立てる	ワークフローと承認の異常に、監査レビュー用のフラグを立てる
依頼の分類	調達フローでカテゴリーを提案する	Predictive Intelligenceがケースを分類し、適切なグループにルーティングする

私たちが関わったあるIT部門では、パスワードのリセットやSAPデータの取得ができるバーチャルエージェントを導入して、四半期のうちに低価値のサポートチケットが30%減りました。SAP側でも同じパターンが当てはまります。AIが最も効果を発揮するのは、プロセスが安定し、履歴がクリーンで、課題が絞られているときです。そのような場合でも、AIはチームを支えるものであって、置き換えるものではありません。

モダナイゼーションは、最初の一歩が大きすぎるように感じられて止まることがよくあります。緊急性が足りないからではなく、「どこから始めるのか」に誰も答えられないために、何年も先送りしたクライアントがいます。次の順序がうまくいく傾向があります。

1. **評価と整理。**プラットフォームを移す前に、土台を整えます。SAP Readiness Checkを実行して、カスタムコードの量と互換性を把握します。マスタデータは、移行の後ではなく前にクレンジングします。どのシステム、レポート、プロセスを残すかを決めます。デプロイメントの方式（RISE with SAP、GROW with SAP、オンプレミス）を決め、ライフサイクルツールとしてSAP Cloud ALMを計画します。SAP Solution Managerは2027年末でメインストリームメンテナンスが終了するためです。何が何につながっているかを洗い出す短い技術ディスカバリースプリントを行えば、本当のリスクがどこに潜んでいるかが見えてくることがほとんどです。
2. **ServiceNowから始める。**受付、承認、ワークフローを先に構築します。これらはERPの周辺にあり、最も不満が出る部分です。あるクライアントは、S/4HANA移行の6か月前にServiceNowで変更管理を行い、障害を40%減らしました。SAPの中核に手を付ける前に、規律が身に付きます。
3. **クリーンコアでSAPの中核を移す。**カスタムコードをできるだけ減らして、トランザクションをS/4HANAに移します。標準に近い状態を保てば、アップグレードが簡単になり、保守コストも下がります。カスタムロジックは、中核ではなく、サイドバイサイド拡張かServiceNowに置きます。そして、単に移行するのではなく、今後5年間にERPが何を可能にすべきかを問いかけてください。
4. **最適化と拡張。**SAP BTP上にアナリティクスと拡張を追加し、適した場面でJouleを使い、ServiceNow側ではNow Assist、バーチャルエージェント、ローコードのワークフローを加えます。

各フェーズは重なってかまいません。ServiceNowの安定化を、SAPの準備作業と並行して進めれば、手を抜かずにスケジュールを短縮できます。S/4HANAの部分については、私のECCからS/4HANAへの移行ガイドで、移行パスとスケジュールを扱っています。

財務部門は早い段階でコストを尋ねます。そして、発端がIT部門であっても、判断は通常CFOのもとに落ち着きます。

直接コストが最初に発生します。インフラ、ホスティング、ストレージ、連携ツールです。ライセンスとサポートは、誰かが整理しない限り横ばいのままで、使われていないライセンスや重複しているライセンスを探さないチームも多くあります。RISE with SAPでは、Full User Equivalent（FUE）の料金体系のもとで、ユーザーの増加を契約期間全体にわたってモデル化してください。3年目のサブスクリプションが、1年目の見積もりどおりになることはまれだからです。

間接コストは見えにくいものです。承認の遅れ、SLAの未達、ITへの信頼を損なう連携の失敗などです。1つの予算科目には現れませんが、運用パフォーマンスには表れます。

投資対効果を示すには、何かを変える前に測定します。請求書承認、オンボーディング、購買依頼のサイクルタイム、エラー率、連携のレイテンシーです。不完全なベースラインでも、投資対効果を物語ではなく数字にできます。

これらの落とし穴は、両方のプラットフォームに現れます。

落とし穴	SAPでのつまずき	ServiceNowでのつまずき
プロセスの評価を省く	プロセスのギャップを見直さずに、レガシーの問題をそのまま移行する	本当のボトルネックを理解せずに、依頼フォームを展開する
ツールを特効薬と見なす	誰も再設計していないプロセスを、S/4HANAが直してくれると思い込む	非効率な依頼設計を、自動化が直してくれると思い込む
マスタデータを軽視する	重複した、または不整合なデータを移行する	信頼できないデータをもとに承認を起動する
早すぎるカスタマイズ	中核プロセスが安定する前に拡張を作り込む	ユーザーの行動を理解する前に複雑なフローを作り込む
ガバナンスの欠如	ビジネス側のオーナーなしに、判断をIT部門やベンダーに任せる	ルールとSLAのオーナーを決めないままワークフローを展開する
チェンジマネジメントの軽視	新しいSAPプロセスのトレーニングへの投資が足りない	新しい依頼タイプをいつ、どう使うかをユーザーに教えない

ある製造業のクライアントは、問題はERPだと考えていました。本当の障害は、5つのチームにまたがる手作業の承認経路でした。ServiceNowの層を導入してSAPにつなぎ戻すと、ボトルネックは消えました。

モダナイゼーションは、一度にすべてを行う必要はありません。残すシステムもあれば、変えるシステムもあります。価値は、より多くの環境がつながり、回避策に頼る部分が減るにつれて積み上がります。

一度にすべてをモダナイズする必要がありますか？

いいえ。モダナイゼーションは段階的に進めるのが最善です。多くの組織は、SAPの中核に手を付ける前に、ServiceNowのワークフローから始めて運用を安定させ、そのあとは摩擦の大きい順に残りを進めます。

あるクライアントは、S/4HANAの導入前にServiceNowの受付ワークフローを稼働させていました。従業員が少しずつ慣れていったため、定着が進み、抵抗も減りました。

S/4HANA移行で、レガシーのカスタマイズはどうなりますか？

ビジネス上の価値によります。SAP Readiness Checkを使えば、カスタムコードの量と互換性の問題を早い段階で把握できます。ほとんどのシステムは、誰も気づいていないほど多くのカスタムコードを抱えており、その多くはもう使われていません。

クリーンコアでは、システムを標準のままに保ち、拡張はSAP BTP上に、ワークフローはServiceNowに置くことを重視します。S/4HANA Cloud Public Editionでは中核をまったく変更できません。Private Editionとオンプレミスでは変更できますが、変更のたびにアップグレードの作業が増えます。実際のビジネス目的に役立っているものは残し、それ以外は廃止してください。

ERPモダナイゼーションにはどのくらいの期間がかかりますか？

ServiceNowで受付ワークフローから始める場合、通常は2〜3か月かかります。S/4HANAへの移行は、複雑さに応じて9〜18か月かかることが多く、カスタマイズが多い大規模なマルチエンティティの企業ではさらに長くなります。

各フェーズを順番に進める必要はありません。ServiceNowの安定化をSAPの準備作業と並行して進めれば、全体のスケジュールを短縮できます。

SAPとServiceNowのモダナイゼーションで、現実的なROIのタイムラインはどのくらいですか？

ほとんどの組織では、3〜6か月でソフトな効果が見られます。サイクルタイムの短縮、手作業による引き継ぎの削減、可視性の向上です。コスト削減や効率向上といった目に見える効果は、特に両方のプラットフォームが貢献するようになれば、12〜18か月以内に表れる傾向があります。

開始前に、サイクルタイム、エラー率、SLA遵守率を記録しておいてください。ベースラインがなければ、投資対効果は数字ではなく物語になります。

ERPモダナイゼーションが遅れていることは、どうすればわかりますか？

よくあるサインは次のとおりです。サポートチケットが増えて解決に時間がかかる、アップグレードやパッチが繰り返し先送りされる、同じデータについて複数の信頼できる情報源が存在する、ERPが担うはずだった穴をシャドーITが埋めている。

SAP ECCを使っていたヘルスケアのクライアントは、1四半期のうちにSLAを何度も未達にしました。問題は努力不足ではなく、技術的負債でした。長年にわたる小さな修正が積み重なり、インシデントが、誰も振り分けきれない速さで記録されていたのです。

SAPとServiceNowは、他のサードパーティシステムとも連携できますか？

はい。SAPは、外部システムとのAPIベースの接続にSAP BTP上のSAP Integration Suiteを使います。ServiceNowのIntegrationHubには、Workday、Salesforce、Coupaを含む、ほとんどのエンタープライズプラットフォーム向けの構築済みコネクタがあります。

連携は、最初からワークストリームとして扱ってください。インターフェースのスコープを遅く決めると、本稼働後に最も大きな摩擦を生みます。ブループリントの段階で連携設計を始めましょう。