SAP_2027問題完全ガイド

SAP 2027年問題　完全ガイド

S/4HANA移行の意思決定と落とし穴

― 保守期限の全体像・移行方式比較・失敗パターン・2026年の最適行動 ―

2026年6月

第一章：SAP 2027年問題とは何か

1.1　問題の本質

「SAP 2027年問題」とは、SAP社が提供する基幹ERPシステム「SAP ERP Central Component（ECC）6.0」の標準保守サポートが2027年12月31日に終了することを起点に、日本国内およびグローバルで約10,000社以上のSAP ECCユーザー企業が、後継製品であるSAP S/4HANAへの移行またはサポート延長対応を迫られる問題です。

問題の本質は単なる「ソフトウェアのバージョンアップ」ではありません。SAP ECCからS/4HANAへの移行は、データベース構造の根本的な変更（インメモリデータベース「SAP HANA」への置換）・業務プロセスの再設計・長年にわたって蓄積されたアドオン（独自開発機能）の全面改修を伴うため、企業によっては数年・数十億円規模のプロジェクトとなります。

1.2　SAP保守期限の変遷と現在地

保守期限は過去に複数回延長されており、混乱の一因となっています。以下に時系列を整理します。

1.3　なぜ多くの企業が動けないのか

2026年6月時点で、約4割の日本企業がまだ移行先を決定していないと推計されています（複数調査の平均）。その背景には以下の構造的要因があります。

要因①：「延長があるから大丈夫」という楽観バイアス

保守期限が2025年→2027年→2030年→2033年と繰り返し延長されてきたため、「またSAPが延ばしてくれる」という楽観論が現場に根付いています。経営層への説明責任上も「延長があるから急がなくていい」という判断が取りやすく、意思決定が先送りされやすい構造があります。

要因②：アドオンの重さが移行の見積もりを困難にする

SAP ECCは20〜30年以上にわたって運用されているケースも多く、その間に蓄積されたアドオン（独自開発機能）が数百〜数千に上ることがあります。アドオンの全量を棚卸しし、S/4HANA対応状況を調査するだけで数ヶ月〜1年かかるため、プロジェクトの初動自体が遅れます。

要因③：コンサルタント市場の枯渇

S/4HANA移行を担えるSAPコンサルタントの需要が供給を大幅に上回っています。2024年以降、コンサルタント単価は前年比約1.5倍に上昇し、稼働率は90%超。予算があっても「15社に提案を断られた」という事例が2026年に実際に報告されています（ITmedia Enterprise, 2026年4月）。移行着手の最終列車は2026年末が実質的なリミットに近づいています。

要因④：プロジェクト規模・コストへの経営判断の遅れ

S/4HANA移行の費用は企業規模・アドオン数・対象拠点数によって大きく異なりますが、中堅企業で数億円〜、大企業では数十億〜数百億円規模になることがあります。この規模の投資判断は経営会議・取締役会での承認が必要なため、IT部門が必要性を認識していても「経営が決断しない」という状況が頻発します。

第二章：2027年以降に何が起きるか――保守終了のリアルな影響

2.1　標準保守終了でなくなるもの

SAP ECC標準保守終了後に停止される提供物と、その影響を具体的に把握しておく必要があります。

2.2　コンプライアンス・監査上のリスク

ECC継続企業がもっとも見落としやすいのが「コンプライアンスリスク」です。日本では以下のような法制度対応がERPに求められており、保守終了後はSAPからの公式対応プログラムが提供されなくなります。

• 電子帳簿保存法：2024年完全施行。電子取引データの保存要件はSAPモジュール（FI/MM）に直接影響

• インボイス制度（適格請求書等保存方式）：2023年10月施行済み。今後の制度変更への対応が必要

• 国際財務報告基準（IFRS）対応：グローバル上場・子会社連結でIFRS17等の対応要件が変化

• サイバーセキュリティ対策基準：経済産業省のサイバーセキュリティ経営ガイドラインで「既知脆弱性への対応」が明示

監査法人・内部監査において「保守終了後のセキュリティ対応状況」を確認する動きが2025年以降顕在化しています。取締役会でのリスク管理として、ECC継続リスクの開示が求められるケースも増えています。

第三章：移行の選択肢――5つのアプローチ

3.1　選択肢の全体地図

SAP 2027年問題への対応策は大きく5つの方向性があります。それぞれが異なるリスク・コスト・期間・変革度合いを持ちます。自社の状況に合った選択肢を正確に理解した上で意思決定することが重要です。

3.2　RISE with SAP vs. GROW with SAP の使い分け

第四章：意思決定フレームワーク――自社に最適な方式を選ぶ

4.1　移行方式選択のための5つの問い

グリーン・ブラウン・ブルーフィールドのいずれを選ぶかは、以下の5つの問いに答えることで絞り込むことができます。

問い①：現在稼働中のアドオンは何件か？

アドオン数が「100件以下」の場合はブラウンフィールドが現実的選択肢となります。「300件以上」の場合、アドオン改修コストがグリーンフィールドの再設計コストを超える可能性があり、ゼロリセットを選ぶ合理性が高まります。「100〜300件」がグレーゾーンであり、アドオンの重要度分析（必須/準標準/廃止候補）を先に実施する必要があります。

問い②：業務プロセスを変える意思が経営にあるか？

グリーンフィールドは「Fit to Standard（標準機能に業務を合わせる）」という考え方が前提です。経営層が「業務プロセスを変えたくない・現場の反発を抑えたい」という姿勢であれば、グリーンフィールドは機能しません。逆に言えば、グリーンフィールドを成功させるには、経営のトップコミットメントが不可欠です。

問い③：移行に使える期間は何年か？

2027年末の標準保守終了から逆算すると、「今すぐ着手」しないと、グリーンフィールド（18〜36ヶ月）は実質的に2027年末に間に合いません。2026年後半の時点でグリーンフィールドを選択する場合、保守延長（2030年）を前提としたスケジュール設計が必要です。ブラウンフィールド（6〜18ヶ月）であれば2027年末ぎりぎり間に合う可能性があります。

問い④：SAPの新機能（AI・組込分析・Fiori）を本移行で活用するか？

「今回の移行はS/4HANAに乗り換えることが目的であり、新機能活用は次フェーズ」と割り切れる場合はブラウンフィールドが合理的です。「今回の移行でDXを実現したい・リアルタイム分析やAI予測を使いたい」という場合は、グリーンまたはブルーフィールドを選ぶべきです。

問い⑤：グローバル多拠点展開があるか？

グローバル多拠点（10拠点以上）を持つ企業はブルーフィールドの選択肢が現実的になります。拠点ごとに業務プロセスの成熟度・アドオン数が異なる場合、一律にグリーンまたはブラウンを適用するより、拠点単位で判断を分けるブルーフィールドが効率的です。

4.2　意思決定マトリクス

第五章：S/4HANA移行の落とし穴――失敗の構造を解剖する

ISG（2026年調査）によると、S/4HANA移行プロジェクトの約60%が予算超過または工期延長を経験しています。その背景にある構造的な失敗パターンを詳解します。

5.1　落とし穴①：アドオンの「氷山」問題

アドオン問題はS/4HANA移行最大の難関です。「氷山」に喩えられるのは、見えている部分（件数）よりも、水面下（相互依存・未文書化・開発者不在）が問題だからです。

なぜアドオン改修は想定より膨れ上がるか

• アドオンの相互依存（A→B→Cとチェーンしている機能が存在し、Aを修正するとB・Cも連鎖修正が必要）

• 開発者の不在（10〜20年前に作られたアドオンの仕様書がなく、開発者もすでに退職している）

• SAP標準テーブルの構造変更（S/4HANAではFI/COのテーブル構造がUniversal Journalに統合されており、ECCのABAP内のテーブル参照が根本から変わる）

• Simplification Item Checkで検出できない間接依存（SAP提供のチェックツールで表面的な非互換は判明するが、動的SQL・カスタムフレームワーク由来の問題は実行時にしか判明しない）

対処法

• 移行判断前に「アドオン棚卸しアセスメント」を必ず実施。件数だけでなく「廃止可能・標準機能に置き換え可能・改修必要」の3分類を行う

• 廃止候補アドオンを事前に削除・無効化してからコンバージョンすることで改修対象を最小化

• アドオン改修コストの見積もりには30〜40%のコンティンジェンシー（予備費）を必ず積む

5.2　落とし穴②：「Fit to Standard」の名のもとに積み上がるアドオン

グリーンフィールドを選択してもなお、業務部門からの「ECC時代と同じ動きにしてほしい」という要求が押し寄せ、結果として新たなアドオンが大量に作られるケースが多く報告されています。

これを防ぐには、Fit/Gap判断を「業務部門の裁量」ではなく「経営主導のガバナンス委員会」が承認する仕組みが必要です。業務部門ではなく経営がアドオンの可否を最終判断する体制を構築してください。

5.3　落とし穴③：コンサルタント不足という構造問題

2026年現在、S/4HANA移行に必要なSAPコンサルタントの需給ギャップは臨界点に達しています。

• S/4HANAコンサルタントの単価は2024年比で約1.5倍に上昇

• 優秀なコンサルタントの稼働率は90%超で、事実上フルブッキング状態

• 「予算はある・意思決定も済んだ・でもベンダーが受けてくれない」という企業が続出

• 2026年に実際に報告：1社から移行プロジェクトのRFPを発行したところ、15社のSIベンダーが連続で提案辞退（ITmedia Enterprise, 2026年4月）

2026年後半に意思決定するとしても、プロジェクト開始は2027年以降になり得ます。その場合、標準保守終了後に移行中というリスクを受け入れた上でスケジュールを設計することが必要です。

5.4　落とし穴④：クラウド上の「塩漬けSAP」

RISE with SAPでクラウドに移行したにもかかわらず、膨大なアドオンをそのままクラウドに持ち込んでしまい、クラウドの利点が活かせない「クラウド内レガシー」が生まれるケースがあります。ITmedia（2026年6月）の調査では、「10億円かけてクラウドに移行したが、業務部門が変わらず従来通りの操作を要求し、S/4HANAの新機能を一切使っていない」という状態を「塩漬けSAP」と呼んでいます。

• 問題：RISE with SAPはインフラコストの削減が主目的だが、アドオンが残存する限り、インフラ利用料（アドオンによる処理負荷増）が高止まりする

• 問題：SAPのSaaS新機能（Joule AI・Business AI等）はクリーンな標準環境を前提としており、アドオン過多の環境では動作保証が得られないケースがある

• 対処法：RISE移行と同時に「アドオン整理プロジェクト」を並行実施。インフラ移行とプロセス変革を同一プロジェクトに組み込む

5.5　落とし穴⑤：スコープ・クリープとプロジェクト長期化

移行プロジェクトの工期延長・予算超過の最大要因は「スコープ・クリープ（当初想定外の要件の追加）」です。

第六章：業種別移行事例――成功と失敗から学ぶ

6.1　事例分析の前提

本章で紹介する事例は、公開情報（日経BP・ITmedia・各社プレスリリース・SAP Community）をもとに業種・課題・学びを整理したものです。企業名は公開情報に基づき記載します。セキュリティポリシー上、社内での検討資料として使用する際は社名部分を業種記述に置き換えてください。

6.2　事例①：アドオン1,000件超からの脱却（食品・飲料業）

• 学び①：「アドオン削減」を移行目的の一つに明示することで、現場の変革受容度が高まった

• 学び②：「選択と集中」として、競争優位に直結しない業務（経理・購買）はSAP標準に合わせ、営業・物流など差別化領域に開発リソースを集中

• 学び③：グリーンフィールドは「移行を成功させること」ではなく「移行後の姿を先に設計すること」から始めた

6.3　事例②：工期2年・コスト1.6倍の代償（食品製造業）

• 失敗要因①：アドオン棚卸しのアセスメントを移行プロジェクト開始と同時に着手したため、移行途中で改修対象が拡大し続けた

• 失敗要因②：業務部門がプロセス変更に強く抵抗し、Fit to Standard方針が形骸化。アドオンが新環境で再生産された

• 失敗要因③：プロジェクト初期の工数見積もりにコンティンジェンシーが含まれておらず、追加コストが経営会議の都度承認を取り直す形になり意思決定が遅延

6.4　事例③：ブラウンフィールドで短期移行を実現（化学・素材業）

• 学び①：「2027年に間に合わせること」を最優先と明確に定義することで、スコープが締まりプロジェクトが収束した

• 学び②：アドオンの「廃止可能なもの」を移行前に徹底的に整理した。件数は多くとも「使われていないアドオン」を先に削除することで改修対象を20%削減できた

• 学び③：移行後の「第2フェーズ（残アドオン最適化・AI機能活用）」を移行プロジェクト開始時に計画に組み込み、経営承認を得ていた

6.5　事例④：コンサル不足で3度のRFP流会（製造業・匿名）

• 教訓：コンサルタント市場は「予算があれば動ける」時代ではなくなっている

• 教訓：RFPを出す前に「パートナーとの非公式な接触（事前市場調査）」で要員確保の目処をつけることが先

• 教訓：RFP発行から契約まで平均6〜12ヶ月かかることを念頭に、意思決定から逆算してアクションを開始する

第七章：2026年現在の最適アクション

7.1　移行着手のタイムライン

2027年末の標準保守終了を起点に、移行プロジェクトを逆算すると以下のようになります。

7.2　今すぐやるべき3つのこと

アクション①：SAP Readiness Checkの実施（無償・SAP提供）

SAP社が無償で提供する「Readiness Check for SAP S/4HANA」ツールを実行することで、現在のECC環境のS/4HANA適合状況（シンプリフィケーション項目・アドオン互換性・データ品質）を自動診断できます。このレポートがアセスメントの出発点となります。実行には数時間〜1日で結果が得られます。まずここから始めてください。

アクション②：アドオン棚卸しの開始（3ヶ月以内）

Readiness Checkの結果を基に、社内またはパートナーとともにアドオンを「①廃止・②標準機能に置き換え・③改修必須」の3カテゴリに分類します。この棚卸しの結果が移行方式・コスト・期間の見積もりを大きく左右します。アドオン数が多い場合でも、実際に「使われているアドオン」は3〜4割という事例が多く、廃止候補の洗い出しが最もコスト削減効果の高い施策です。

アクション③：パートナーとの非公式接触（RFP前の市場調査）

正式なRFPを出す前に、有力SIパートナー3〜5社と「非公式の事前相談」を実施してください。「2026年Q3に着手したいが要員確保は可能か？」を確認します。要員確保の目処が立たない場合は、2030年延長を前提としたプランBを同時並行で設計します。パートナー選定は「S/4HANA移行実績数・業種特化知識・アドオン削減の取り組み実績」を必ず評価軸に入れてください。

7.3　経営へのエスカレーション：IT部門が伝えるべき4つのメッセージ

7.4　移行を成功させる組織体制

• エグゼクティブスポンサー（C-Level）：CIO/CFO/COOのいずれかが「アドオン追加承認権限」を持つ最終決裁者として関与。現場の「変えたくない」という圧力をトップが押さえる役割

第八章：機能領域別移行難易度マップ

S/4HANA移行の難易度は「モジュールごとに大きく異なる」という事実は、移行計画の精度を上げる上で非常に重要です。全モジュールを同じ工数で見積もると、実際のプロジェクトで大幅な誤差が生じます。以下の難易度評価は「データ構造変更の大きさ・アドオン影響度・業務変革の必要度」の3軸を総合したものです。

8.1　最難関モジュール：CO（管理会計）の詳解

CO領域はS/4HANA移行で最も設計変更が大きく、かつビジネスインパクトが大きいモジュールです。特に「原価ベースCO-PAの廃止」は、多くの企業で管理会計レポートの全面再設計を迫ります。

Universal Journalとは何か：なぜCOが最難関か

ECC時代、FIの仕訳はFI台帳（BKPF/BSEG）、COの原価は別台帳（COEP/COSS/COSP/COPA等）に分かれて記録されていました。S/4HANAでは「Universal Journal（ACDOCA）」という単一の仕訳テーブルに全ての財務・管理会計データが一元統合されます。

• 変更前（ECC）：FI台帳とCO台帳が別々。月次の台帳照合・FI-CO差異調整が必要だった

• 変更後（S/4HANA）：FI・CO・特殊台帳・資産・原価センター・利益センター・CO-PAがすべてAUCOCAに一本化。「瞬時に原価センター別P&L」「リアルタイムの収益性分析」が可能

これは会計の「概念変換」であり、既存の管理会計レポート・原価計算ロジック・アドオンが前提としているデータ構造が根本から変わります。

原価ベースCO-PAから勘定ベースCO-PAへの移行

ECCのCO-PA（採算性分析）には「勘定ベース（Account-based）」と「原価ベース（Costing-based）」の2種類がありました。S/4HANAでは「勘定ベース」がデフォルトとなり、「原価ベース」の廃止が推奨されています。

• 影響：原価ベースCO-PAのみで構築されていた収益性レポートは、勘定ベースで再設計が必要

• 影響：原価ベース特有の「評価（Valuation）」「条件ベース配賦」のロジックを勘定ベースで再現する必要がある

• 影響：BI/BW・社内レポーティングシステムがCO-PAデータを参照している場合、全て再設計

この移行の設計・テストだけで6〜12ヶ月を要するケースがあります。CO領域を社内で設計できる要員がいない場合、外部の管理会計専門コンサルタントが必須です。

8.2　WM→eWM移行の実態

倉庫管理の移行は、機能の「廃止と置換」という性格が最も強いモジュールです。WM（在来倉庫管理）はS/4HANAで廃止となり、eWM（Extended Warehouse Management）が全ての後継機能を担います。

• WMとeWMは「管理の概念」が異なる：WMの「転送指示（Transfer Order）」→eWMの「倉庫タスク（Warehouse Task）」。物の動きの捉え方自体が変わります

• 設定の移行不可：WMの倉庫番号・保管タイプ・棚番・コントロールパラメータはeWMへの自動変換ができず、基本的に再設定が必要

• インターフェースの全面再設計：WMとPP・MM・SDを繋ぐインターフェース（搬送依頼の流れ）がeWMで変わるため、WM周辺のアドオン・外部システム連携を全て見直す必要がある

• WMユーザーへの推奨：ブラウンフィールドであっても、eWMはグリーンフィールド的な設計作業が発生すると心得ること

8.3　HR/HCMの特殊性：S/4HANA移行とは別のプロジェクト

HR/HCMはS/4HANA移行の文脈で最も誤解されやすいモジュールです。SAP社の方針は「HR機能はSuccessFactors（クラウドHCM）に移行する」というものであり、S/4HANAにはHR機能が統合されていません。

HR移行はS/4HANA移行チームとは別の「HRトランスフォーメーションチーム」を組成し、並行して推進することを強く推奨します。一つのプロジェクトに統合すると、スコープが過大になり収拾がつかなくなります。

第九章：「バージョンアップ」か「次のビジネス」か――S/4HANA移行の戦略的価値

S/4HANA移行を「SAP保守終了への対応コスト」として捉えるか、「デジタル経営への変革投資」として捉えるかで、プロジェクトの性格・スコープ・得られる価値が根本から変わります。同じ移行費用をかけても、移行後に「前のSAPと何も変わらない」企業と「競争優位を獲得する」企業に分かれます。その差は何かを本章で解説します。

9.1　2つの移行マインドセット

9.2　S/4HANAが解放する新たな技術能力

S/4HANAはECCの「後継バージョン」ではなく、アーキテクチャが根本から異なるプラットフォームです。その新能力を正しく理解することが、移行投資を「コスト」から「資産」に変える第一歩です。

① リアルタイム統合経営（Universal Journal）

ECCでは「FIの月次締め後にCOに転記→月次レポート作成」という時間差がありました。Universal Journalでは全ての財務・管理会計データが発生と同時に単一台帳に記録されます。

• 実現できること：「今日の時点で原価センター別・製品別・地域別の収益性がリアルタイムで見える」という経営の意思決定スピードの根本的変革

• 実現できること：月次決算の早期化（最大で月末日中に仮決算、翌営業日に正式決算が可能になる）

• 実現できること：「なぜこの原価が発生したか」をFIとCOを行き来せずに一画面で追跡可能

② 組込分析（Embedded Analytics）

ECCでは分析用のデータをBWに抽出・蓄積してからレポートするという「データウェアハウス型」アーキテクチャが主流でした。S/4HANAでは「Embedded Analytics」として、ERPのデータをリアルタイムに分析する機能が内蔵されています。

• SAC（SAP Analytics Cloud）との統合：S/4HANAのリアルタイムデータを直接SACのダッシュボード・予測分析に活用

• Smart Business Cockpit：Fioriベースのリアルタイム経営ダッシュボードが標準で提供

• BW/4HANA統合：過去履歴データが必要な場合はBW/4HANAとの連携でリアルタイム＋履歴の統合分析

③ SAP Joule / Business AI

SAP社は「Business AI」をS/4HANAの中核戦略と位置づけ、2024〜2026年にかけて大量のAI機能を標準搭載しています。これらのAI機能はクリーンなS/4HANA（アドオン過多でない環境）でのみ動作保証されます。

④ SAP BTP（Business Technology Platform）による次のビジネスへの拡張

SAP BTPはS/4HANAをコアとした「DXプラットフォーム」であり、単なるS/4HANAの周辺ツールではありません。BTPを活用することで、S/4HANAのデータと外部システム・AI・IoTを統合した新しいビジネスアプリケーションを構築できます。

• SAP Build（ローコード開発）：プログラミングなしにS/4HANAデータを活用したアプリ・ワークフローを現場部門が作成可能

• 統合Suite：SAP SuccessFactors・Ariba・IBP・DMとS/4HANAをAPIで統合し、「One SAP」としての一気通貫業務フローを実現

• 外部システムとの統合：SalesforceやWorkday等の非SAPシステムとBTPを介してリアルタイムにデータ連携

9.3　「次のビジネス」を獲得した具体的な価値事例

以下の事例は、S/4HANA移行を「保守対応コスト」ではなく「ビジネス変革の起爆剤」として活用した企業の実像です。特に「現状が問題とすら認識されていない慢性的な非効率」に切り込んだ事例に注目してください。

価値事例①：「Excelが経営報告の正とされている」状態から脱却した企業

この事例の本質は「ExcelではなくSAPが正」という文化の転換にあります。技術的な移行以上に、「役員がSACを直接見る」という行動の変化が組織全体を動かしました。

価値事例②：AI時代に耐えられる「データ基盤の再構築」を主目的とした移行

価値事例③：「月末の残業地獄」が消えた決算早期化（小売・流通業）

価値事例④：「ベテラン担当者の引退問題」をAI自動仕訳で解決（中堅製造業）

価値事例⑤：工場の「原価がブラックボックス」問題の解消（自動車部品メーカー）

価値事例⑥：「AIを使える会社」になるための移行（デジタル変革の前提条件として）

2025〜2026年にかけて、「AI活用を本格推進しようとしたら、SAPのデータが使えない状態と判明した」という経緯でS/4HANA移行を決断する企業が増えています。以下は、移行を「AI活用の前提条件」として経営承認を得た事例の論理構造です。

これらのAI活用は「S/4HANAへの移行なしには実現できない」ものではありません。しかし現実には「ECC時代の汚染データ・分散データ・アドオン由来の不透明性」が、AIプロジェクトの最大の障壁になっています。S/4HANA移行をAI活用投資の前払いとして捉えると、移行コストの「意味付け」が経営に通じやすくなります。

9.4　ROI（投資対効果）の2層構造

S/4HANA移行のROIを「コスト削減だけで評価」することは片手落ちです。真のROI評価には、コスト削減（第1層）と収益機会の創出（第2層）の両方を盛り込む必要があります。

9.5　「義務的移行」で終わらないための判断基準

移行プロジェクトが「単なるバージョンアップ（義務的移行）」に終わるサインと、それを避けるための処方箋を示します。

9.6　S/4HANA移行を「経営変革の起爆剤」にするための3原則

原則①：「ITプロジェクト」ではなく「ビジネストランスフォーメーション」として定義する

プロジェクトの位置づけを「SAPのバージョンを上げる」ではなく「経営の意思決定をリアルタイム化し、競争優位を構築するためのビジネス変革」として経営会議で定義・合意します。この言語の違いが、経営の関与度・予算承認のスピード・現場の変革受容度に大きく影響します。

原則②：移行後の「1枚ビジョン」を先に描く

「S/4HANA移行後の3年後の姿（To-Be）」を1枚の図で表現し、全ステークホルダーで合意することが先決です。「月次決算を3営業日以内に完了し、毎週経営会議でリアルタイムP&Lを確認する」「AI仕訳自動化率70%を達成し経理部員を分析業務にシフト」など、具体的な数値を伴ったビジョンが変革のコンパスになります。

原則③：アドオン削減を「コスト削減策」ではなく「新機能活用のための前提条件」として位置づける

アドオンが多いと、S/4HANAのAI機能・Embedded Analytics・Business AIが正常動作しないケースが生じます。アドオン削減を「コストを下げるための苦労」ではなく「AI・分析機能を使うための環境整備」として捉え直すことで、現場の変革受容度が高まります。「アドオンをなくすことで、こんな新しい機能が使える」という訴求が有効です。

第十章：なぜバカみたく高くなるのか――コスト爆発の構造と業務改革なき移行の末路

S/4HANA移行プロジェクトには「最初の見積もりが1.5〜3倍に膨らんだ」という事例が非常に多く報告されています。またROI（投資対効果）を経営に説明することの難しさから、稟議が通っても「何のためにやったのか分からない」という結果に終わるケースも後を絶ちません。本章では、コスト爆発のメカニズム・ROI説明の落とし穴・そして「業務改革を伴う移行と伴わない移行がどれほど違う結果をもたらすか」を具体的な事例とともに解説します。

10.1　コスト爆発の解剖――なぜ見積もりの2〜3倍になるか

S/4HANA移行プロジェクトのコストが大幅に膨らむ構造は、ほぼ決まった複数の要因の組み合わせで説明できます。「うちは大丈夫」という先入観が、最も危険です。

10.2　ROI説明の難しさ――「いくら儲かる？」に答えられない構造

S/4HANA移行の経営稟議における最大の難所は「効果の説明」です。コストは明確に算出できますが、効果（ベネフィット）の大部分が「定量化しにくい」という本質的な問題があります。

なぜROIが説明しにくいか

ROI説明の失敗パターン（実例）

ROI説明を成立させる3つの工夫

工夫①：「対しない場合のコスト（Status Quo Cost）」を試算する

移行しない場合のコストを積み上げて「移行コストと比較」する方法が最も経営に届きます。有償延長保守費・コンサル費高騰リスク・セキュリティインシデントの期待損失・法制度対応の手作業コスト・競争劣位による機会損失を合算すると、移行コストを上回るケースが多くあります。

工夫②：「最初の1勝（Quick Win）」を定義して先行実証する

「移行全体のROI」を証明しようとすると議論が発散します。代わりに「移行後に最初に実現できる1つの具体的な効果」を定義し、PoC（概念実証）や先行パイロットで数字を出します。「A事業部の仕訳自動化率を3ヶ月で60%にする」「購買部門の支払いサイクルを3日短縮する」など、小さくても実証できる成果が経営の信頼を獲得します。

工夫③：KPIを「移行前に」設定・測定し「移行後に」比較する

移行後に「何が変わったか」を測れるよう、移行前に現状値（As-Is KPI）を記録しておくことが必要です。月次決算日数・在庫回転日数・仕訳件数と処理工数・購買リードタイム・不良発生率など、移行後に改善効果を計れる指標を「移行プロジェクト開始時に」合意します。これがないと、移行後に「何が変わったのか誰にもわからない」状態になります。

10.3　業務改革なき移行の末路――「クラウドの塩漬けSAP」

「業務改革を伴わない移行」がどのような結果をもたらすか。複数の事例を合成した典型的なパターンを示します。

なぜ「業務改革なき移行」が繰り返されるか

• SIベンダーの収益構造：アドオンの設計・開発・維持はSIベンダーにとって収益源。「標準に合わせましょう」と言いながら、業務部門の要求を断らずにアドオン開発を受注する構造が存在する

• 業務部門の抵抗：「今のやり方を変えたくない」という現場の圧力は、チェンジマネジメントが不十分なプロジェクトでは必ず勝つ。「なぜ変えるのか」を経営が説明しないと現場は変わらない

• IT部門の優先順位：「本番稼働させること」が最大の成功基準になると、業務変革は二の次になる。稼働直前は「とにかく動かす」ために変革を先送りする意思決定が横行する

• 経営の「任せっきり」：移行プロジェクトをITの仕事と見なし、業務側が参加しない形になると、業務プロセスの根本的な見直しは誰もやらない

10.4　業務改革を伴う移行の成功事例――仕事の仕方を抜本的に変える

成功した移行プロジェクトに共通するのは「SAPのデータを活用して仕事の仕方を根本から変える」という視点です。「SAPに合わせる」のではなく「SAPのデータで何ができるかから業務を再設計する」という順序が重要です。

成功事例①：週次Excelレポートの廃止と意思決定の革命（製造業）

成功事例②：購買業務の「発注判断の自動化」（化学メーカー）

成功事例③：アドオン削減で「将来コスト」を断ち切る（産業機器メーカー）

10.5　「SAPデータを活用した仕事の見直し」の実践フレームワーク

業務改革を伴う移行を成功させるには、「現行業務フローをS/4HANAに乗せ換える」発想から「S/4HANAで何ができるかを先に理解し、業務フローをゼロから設計する」発想への転換が必要です。以下に実践的なフレームワークを示します。

Step 1：「誰が・何のために・どんな判断をしているか」を棚卸しする

現行業務の中で「人が時間をかけている作業」を「判断系」と「作業系」に分類します。「判断系」（何を発注するか・どの原価センターに配賦するか・品質合否をどう判定するか）はSAPデータで支援・自動化できる可能性があります。「作業系」（データを手で入力する・PDFをExcelに転記する・メールで承認を回す）はS/4HANAの自動化・ワークフローで置き換えられます。

Step 2：「SAPが自動でやること」と「人が価値を出すこと」を分離する

移行の目的は「人をシステムに置き換えること」ではなく「システムが定型処理を担い、人が判断・創造・関係構築に集中できる構造を作ること」です。

• SAPに任せる：データ入力・転記・集計・定型レポート・発注推奨・ルーティングワークフロー・自動仕訳・在庫計算

• 人が担う：例外の判断・サプライヤーとの関係交渉・顧客への提案・新しい施策の立案・SAPデータを使ったビジネス分析・チームメンバーの育成

この「役割の分離設計」を移行前に業務部門と合意することが、業務改革を成功させる最大のポイントです。「SAPを入れても誰の仕事も変わらない」という結果を防ぐ唯一の方法は、「移行後に誰が何をしているか」のTo-Beイメージを業務部門が自分で描くことです。

Step 3：チェンジマネジメントを「研修」ではなく「参加」として設計する

「S/4HANA研修を受けて操作を覚えよう」という受動的なアプローチでは業務改革は起きません。業務部門が「自分たちの仕事の設計者」として移行プロジェクトに関与することが鍵です。

• 業務部門代表（Key User）が自ら業務プロセスを設計する：IT担当者やSIコンサルタントが「こう変えましょう」と提案するのではなく、現場のKey Userが「自分たちの新しい仕事の仕方」を描く

• 「なくなる作業」ではなく「生まれる価値」を語る：「この作業がなくなる」という表現を避け、「この時間を○○に使える」という表現で変革を訴求する

• 早期成功体験（Quick Win）を演出する：本番稼働前のサンドボックス環境で業務部門が「これ便利だ」と体感する場を設ける。自発的な変革推進者（チャンピオン）が現場から生まれる

以上