
目次
SAP導入とは、企業の財務、購買、サプライチェーン、販売、人事を1つのSAPシステムに移すプログラムです。現在、移行先はたいていSAP S/4HANAです。SAP Activateの6つのフェーズ(Discover、Prepare、Explore、Realize、Deploy、Run)に沿って進み、成否は、誰かが何かを設定し始める前に、プロセス、データ、人の作業をどこまでやったかで決まります。
端的に言えば、SAP導入プロジェクトは、ばらばらのレガシーシステムを1つのシステムと1つのデータモデルに置き換えるものです。プロセスは6つのステップです。ビジネスケースを確認する、チームを立ち上げる、SAPの標準に合わせて設計する、構築してテストする、本稼働する、そして安定化させて引き継ぐ。私の経験では、GROW with SAPで6〜9か月、RISE with SAPで9〜18か月かかります。フェーズごとの内訳はSAP導入スケジュールのガイドで説明しています。
私が率いた、立て直した、あるいは脱線していくのを見てきた21のSAPプログラムを通じて、パターンは同じです。SAPをソフトウェアのインストールとして扱う企業は苦戦します。まずプロセスを再設計し、設定をその後に回す企業は、取締役会に約束したものを実現します。
このガイドは、これからSAP導入を始める経営幹部とプログラムリーダーのためのものです。1つのセクションだけ読むなら、「設定を始める前の計画」を読んでください。
S/4HANAはSAPの現行ERPで、SAP HANAのインメモリデータベース上で動きます。今も旧来のSAP ECCを使う企業は多いですが、ECCのメインストリームメンテナンスは2027年12月31日に終了します。割高な料金で2030年末まで延長メンテナンスを選ぶこともできます。
多くの導入で最初に手を付けるコアモジュールは次のとおりです。
| モジュール | 管理する領域 |
|---|---|
| FI(財務会計) | 総勘定元帳、買掛金、売掛金、固定資産会計 |
| CO(管理会計) | 原価センタ、利益センタ、内部指図、管理会計レポート |
| MM(購買在庫管理) | 調達、在庫、入出庫、仕入先管理 |
| SD(販売管理) | 受注から入金まで、価格設定、出荷、請求 |
| PP(生産計画) | 製造指図、能力計画、MRP |
| HCM(人事管理) | 人事マスタデータ、給与計算、勤怠管理 |
多くの企業はFI/COと1つか2つの業務モジュールから始めます。残りは後のリリースで構築していきます。
導入と移行は同じではありません。すでにSAP ECCを使っているなら、SAPシステムの変換か再構築になります。グリーンフィールド、ブラウンフィールド、選択的移行の各パスは、私のECCからS/4HANAへの移行ガイドで扱っています。

SAP ActivateはSAPの導入方法論です。旧来のASAP方法論に代わるもので、6つのフェーズがあり、それぞれ次に進む前にクリアすべきゲートがあります。
SAP Activateの六つのフェーズ
Discover
ビジネスケースを確認し、優先プロセスをトライアル環境やデモシステムで検証します。
Prepare
立ち上げ:チーム、ガバナンス、スコープ文書、計画、システムアクセス。
Explore
プロセスオーナーとFit-to-Standardワークショップを行います。設定、インターフェース、拡張のバックログを作ります。
Realize
設定、拡張、データ移行、テスト。最も長いフェーズです。終了にはクリーンな回帰テストの結果が必要です。
Deploy
実際のプロセスでユーザーを教育し、カットオーバーをリハーサルし、ウォールームを用意して本稼働します。
Run
ハイパーケア、最適化、Centre of Excellenceへの引き継ぎ。
この表は、私がプログラムオフィスの壁に貼っているものです。各フェーズで何を作るべきか、誰が責任を持つか、次のフェーズを始める前に何が満たされていなければならないかを示しています。
| フェーズ | 成果物 | 責任者 | 次に進むためのゲート |
|---|---|---|---|
| Discover | ビジネスケース、目標スコープ、展開方式の選択 | スポンサーとCFO | 予算承認 |
| Prepare | スコープ文書、計画、ガバナンス、チーム体制 | プログラムディレクター | スポンサーがスコープに署名 |
| Explore | Fit-to-Standardの結果、バックログ、拡張の判断 | ソリューションアーキテクトとプロセスオーナー | 未解決のギャップがない |
| Realize | 設定とテストを終えたシステム、移行済みのテストデータ | 機能リードと技術リード | クリーンな回帰テスト、データの照合一致 |
| Deploy | 教育済みのユーザー、リハーサル済みのカットオーバー、Go/No-Go資料 | カットオーバーマネージャー | 3日間の決算リハーサルに合格 |
| Run | ハイパーケアのログ、CoEへの引き継ぎ、フェーズ2のバックログ | サービスデリバリーリード | 未解決のP1/P2がない、CoEが受け入れ |
各フェーズの裏にあるテンプレートは、私のSAP Activateテンプレートのガイドにあります。
5段階か、6段階か
「SAP導入の5段階」を検索する人がいるのは、SAPの旧来のASAP方法論が5つのフェーズだったからです。プロジェクト準備、ビジネスブループリント、実現、最終準備、本稼働とサポートの5つです。
SAP Activateは同じ考え方を引き継ぎ、先頭にDiscover、最後にRunを加えています。PrepareからDeployまでが、通常は中核のデリバリーフェーズとして扱われます。今も「ブループリント」と言うチームは、たいていExploreのことを指しています。
3日間の決算リハーサルというゲート
RealizeとDeployの間のゲートは、スケジュールに追われたチームが最も飛ばしやすいゲートです。私はどのプログラムでも、3日間の決算リハーサルを準備完了の判定ゲートにしています。新システムで財務が帳簿を締められないなら、ITが何と言おうと、データ移行は準備ができていません。
このゲートを飛ばすと、それによって避けたはずの遅れよりも高くつきます。
順番が大事です。設定の判断を1つでも下す前に、済ませておくべきことが4つあります。
- 現行プロセスを可視化する回避策も含めて、実際の動き方のとおりに
- 標準か拡張かを決めるほぼ常に標準のほうが速い
- データ品質を監査するデータ移行を始める前に
- チームを揃えてからスコープを決める誰がいるかで、何を届けられるかが決まる
ここで初めて設定を始める
私が見る最大の失敗は、最初にきちんと計画しないことです。予算はExploreで超過します。ワークフロー、レポート、インターフェース、データ変換、機能拡張、帳票(WRICEF)の一覧が膨らみ、スコープを握っているのがクライアントではなくベンダーになるときです。それが予算に何をもたらすかは、私のSAP導入コストの内訳で示しています。
現行プロセスを実際の動き方のとおりに可視化する
プロセスがこうあるべきという姿ではありません。回避策も含めた、実際の姿です。
2023年の欧州の金融サービスのプログラムで、私はブループリントのセッションに同席しました。そこでは財務部門が会社間取引をスプレッドシートで照合していました。誰も書き残していない要件は、こうした回避策の中に隠れています。
プロセスごとに標準か拡張かを決める
SAPの標準機能でカバーできるプロセスと、拡張が必要なプロセスを見極めます。標準のほうがほぼ常に速いです。拡張を1つ足すたびに、テストサイクル、アップグレードのリスク、保守が増えるからです。
SAPのClean Coreのガイダンスのもとでは、拡張ごとに置き場所も意図して決めなければなりません。そのぶん判断の重みは増します。軽くはなりません。
データ移行を始める前にデータ品質を監査する
データは最も過小評価されるワークストリームです。私の経験では、データ移行は導入工数の30〜40%を占めます。
あるクライアントでは、顧客データの重複が18,000件を超えていました。それを本稼働後に直したことで、請求業務が何週間も混乱しました。データは早い段階でプロファイリングし、ソースシステムの中でクレンジングしてください。その方法は、私のSAPのデータ移行が失敗する理由のガイドで扱っています。
先にチームを揃え、それからスコープを確定する
届けられるスコープは、各ワークストリームで設定し、テストし、責任を持てる人が誰かで決まります。先にスコープを決めて後から人を集めるチームは、背負い込みすぎたものを作り直すのに何か月も費やします。
SAP導入プロジェクトには、次の役割にそれぞれ名前のある担当者が必要です。そのほとんどはパートナー側ではなく、自社側の人です。
- エグゼクティブスポンサー。 ビジネスケースに責任を持ち、意見が割れたときに決着をつけます。通常はCFOかCOOです。
- プログラムディレクター。 計画、予算、ステアリングコミッティを運営します。自社の社員か、パートナーから独立した人を充てます。
- プロセスオーナー。 領域(財務、購買、販売、生産)ごとに1人です。設計を承認し、本稼働後の結果に責任を持ちます。
- ソリューションアーキテクト。 全体の設計を握り、すべての拡張をどこに置くかを決めます。
- 機能リードと技術リード。 設定、構築、テストを行います。通常はパートナーのチームです。
- データ移行リード。 RealizeではなくPrepareで任命します。
- チェンジマネジメントと教育のリード。 Exploreの段階からエンドユーザーと話し始めます。
- カットオーバーマネージャー。 本稼働のランブックとGo/No-Go資料に責任を持ちます。
このリストよりも大事なルールが1つあります。実際の作業を請け負うパートナーに、ビジネスケースを書かせてはいけません。
彼らのインセンティブは始めることです。あなたのインセンティブは終わらせることです。
SAPは壊れたプロセスを直してはくれません。露呈させるだけです。SAPから最も多くを得ている企業は、まずプロセスを再設計し、システムの設定はその後に行っています。
ほぼすべてのプログラムで目にする課題と、それぞれの対策です。
| 課題 | どう現れるか | どう対処するか |
|---|---|---|
| スコープクリープ | 「ついでにこれも追加して…」という要望が積み上がる | 初日から正式な変更管理を行い、すべての要望に影響評価を付ける |
| データ品質 | 移行の段階で、誰も知らなかった不整合が見つかる | 早期にデータをプロファイリングし、ソースシステムでクレンジングする |
| ユーザーの抵抗 | 本稼働から2週間以内にユーザーがExcelに戻っていく | Exploreからエンドユーザーを設計に参加させる |
| 連携の不具合 | UATでサードパーティとの接続が壊れる | Exploreでインターフェースを洗い出し、早期に現実的なデータ量でテストする |
| テストサイクルの削減 | 期日に間に合わせるために回帰テストを短縮する | テストフェーズを守る。構築の遅れでテストを圧縮しない |
| チームの疲弊 | 終盤に士気が下がり、不具合率が上がる | 簡単な週次のセンチメント指標で追跡する |
チームの疲弊については、私は簡単な週次のセンチメント指標を追っています。チームの25%を超える人が「手一杯だ」と答えると、テストの不具合率が跳ね上がります。
2024年のGCCの製造業のプログラムでは、チームがスケジュールの3週間を取り戻すために回帰テストを飛ばしました。その後、財務は主要なレポートの照合ができなくなり、何か月もの後始末が続きました。システムの欠陥ではありません。避けられた判断でした。
本稼働の前、最中、後
本稼働の前には、決算リハーサルを行い、移行したデータを照合レポートで検証し、デモのシナリオではなく実際のプロセスで教育します。ロールバック計画もテストします。ステアリングコミッティにGo/No-Goの基準を一つひとつ説明し、暗黙のうなずきではなく明示的な承認を得てください。
本稼働の最中は、監視を強化し、最初の72時間はカットオーバーチームが24時間対応できる体制にします。この数時間の判断で、ハイパーケアが自信を持って始まるか、課題の行列とともに始まるかが決まります。
本稼働の後は、少なくとも4週間ハイパーケアを行い、サポートチケットをカテゴリ別に追跡します。どこで教育が足りなかったのか、どこで設定の調整が必要なのかが見えてきます。
2024年の欧州の製造業のプログラムでは、クライアントが原材料の欠品を繰り返していました。購買部門は計画担当者のせいにし、計画担当者は誰も信用していないスプレッドシートのせいにしていました。私たちはその仕組みをS/4HANAに置き換え、MRPをきちんと設定したSAP PPを全面的に活用しました。
在庫水準は勘から実時間のデータに変わり、購買発注は必要に応じて起票されるようになりました。最初の6か月で、原材料の欠品は50%以上減りました。この成果は、設定に先立つプロセスの再設計から生まれたものです。プロセスの作業がなければ、PPは間違った答えを速く出すだけだったでしょう。
2024年の英国のプロフェッショナルサービスのプログラムでは、問題は財務でした。月次決算に2週間以上かかり、レポートは手作業で作り直されていました。私たちは、現場に深く関わるステアリングコミッティのもとで、SAP Financeを段階的に展開しました。
月次決算は1週間強まで短縮されました。CFOは私に、数字が「信じられるものに感じられた」と言いました。
2022年向けに書かれたガイドは、2026年の買い手には通用しません。キックオフの時点から設計に織り込むべき変化が3つあります。
クラウドエディションが標準になった
SAPは現在、2つのクラウドERPエディションを販売しています。SAP Cloud ERP(パブリックエディション、旧S/4HANA Cloud Public Edition)とSAP Cloud ERP Private(プライベートエディション)です。RISE with SAPは、プライベートエディションに、SAPによる運用と、SAP Signavio、SAP LeanIX、SAP Cloud ALMを含むツール群をまとめたパッケージです。GROW with SAPは、パブリックエディションを使う中堅企業向けのパッケージです。
いまではエディションの判断が、従来の展開方式の議論よりも上位にあります。ビッグバンか段階導入か、グリーンフィールドかブラウンフィールドか選択的移行かは、エディションの中で選ぶものであって、エディションの代わりに選ぶものではありません。
Clean Coreは二択ではなく段階評価になった
2025年8月、SAPはAからDの4つのClean Coreレベルを導入しました。レベルAは、リリース済みで安定したAPIだけを使います。SAP BTP上のサイドバイサイド拡張か、ABAP Cloudによるシステム内の拡張です。レベルBはクリーンとみなされるクラシックAPIを認め、レベルCには特別な対策が必要で、レベルDはクリーンではありません。
パブリックエディションではレベルAの拡張しか認められません。プライベートエディションとオンプレミスではクラシックな拡張も可能なので、規律はプラットフォームによる制限ではなく、ガバナンスから生まれます。Exploreの段階ですべての拡張のレベルと置き場所を決め、「ノー」と言える担当者を指名してください。
デリバリーチームの中のAI
JouleはいまやSAP Activate Roadmap ViewerとSAP Cloud ALMに組み込まれ、タスクに関する質問に答え、方法論に基づいてコンテンツの下書きを作ります。2024年から一般提供されているSAP Build Codeは、Jouleを使って、SAP BTP上のJavaとJavaScriptの拡張向けにアプリケーションロジック、データモデル、テストを生成します。SAPはABAP開発者向けにも同様の生成AI支援を追加しています。
私の見方はこうです。SAPプログラムにおけるAIは本物ですが、価値を決めるのはデータ品質です。きれいなプロセス文書ときれいなマスタデータからは役に立つアウトプットが生まれ、汚れたデータからは自信満々のノイズが生まれます。どれも、一つひとつの判断に責任を持つ人の必要性をなくすものではありません。
フェーズは今も有効で、作業の順番も今も重要です。エディションの判断、拡張の規律、新しいツールをキックオフの時点で取り込んだプログラムは、それらを設計上の制約として扱います。無視したプログラムは、最初の3か月を何が変わったのかを知ることに費やします。たいていは、パートナーからの変更要求を通じて知ることになります。
このガイドは、ビジネスケースから本番稼働までのすべてのテーマをまとめたSAP導入ガイドの一部です。
SAP導入とは、簡単に言うと何ですか?
財務、購買、販売、人事など、企業の中核プロセスを1つのシステムと1つのデータモデルで動かすために、SAPソフトウェアを構築するプロジェクトです。プロセス設計、設定、データ移行、テスト、教育、本稼働までを含み、通常はSAPのActivate方法論に沿って進めます。
SAP導入の5段階とは何ですか?
5段階は、SAPの旧来のASAP方法論に由来します。プロジェクト準備、ビジネスブループリント、実現、最終準備、本稼働とサポートです。SAP ActivateはASAPに代わるもので、先頭にDiscover、最後にRunを加えた6つのフェーズを使います。
SAP Activateの6つのフェーズとは何ですか?
Discover(ビジネスケースと適合性)、Prepare(チーム、ガバナンス、計画)、Explore(Fit-to-Standardワークショップとバックログ)、Realize(設定、拡張、移行、テスト)、Deploy(教育、カットオーバーのリハーサル、本稼働)、Run(ハイパーケアとCentre of Excellenceへの引き継ぎ)です。
SAP導入とSAP移行の違いは何ですか?
導入はSAPを新たに入れることで、通常はSAP以外のシステムやレガシーシステムを置き換えます。移行は、既存のSAP ECCシステムをS/4HANAに移すことで、システム変換(ブラウンフィールド)、新規構築(グリーンフィールド)、選択的データ移行のいずれかで行います。どちらもSAP Activateのフェーズに沿って進めます。
SAP導入チームには誰を入れるべきですか?
エグゼクティブスポンサー、プログラムディレクター、各領域のプロセスオーナー、ソリューションアーキテクト、機能リードと技術リード、データ移行リード、チェンジマネジメントと教育のリード、カットオーバーマネージャーです。スポンサー、プロセスオーナー、データリードは、パートナー側ではなく自社側から出すべきです。
SAP導入が失敗する最も多い理由は何ですか?
問題を抱えたプログラムのほぼすべてに、3つの根本原因があります。プロセスの作業が省かれる、データ品質がカットオーバーまで放置される、チェンジマネジメントが単なる教育として扱われる、の3つです。
新しい原因もあります。Clean Coreの計画なしに拡張を作るパートナーです。それが負債として残り、最初の大型アップグレードで表面化します。
適切なSAP導入パートナーはどう選べばよいですか?
自社と同じ規模での業界経験があり、実際に電話で話を聞ける導入実績先を持つパートナーを探してください。提案の場に出てきた人が、プログラムを率いるべきです。SAP BTPとABAP Cloudの拡張をいくつ作ったかを尋ね、実物を見せてもらってください。
RISE with SAPとは何ですか?自社に合っていますか?
RISE with SAPは、SAP Cloud ERP Private向けのSAPのサブスクリプションパッケージです。ソフトウェア、SAPが管理するインフラと運用、そしてプロセス分析、アーキテクチャ、ライフサイクル管理のためのツール群が含まれます。導入作業そのものは、引き続きパートナーが担います。
ECCから移行する大規模な組織で、プラットフォームと運用をSAPとの1つの契約にまとめたい場合に向いています。標準に近い形で運用できる中堅企業は、パブリックエディションのGROW with SAPを検討すべきです。
次のステップ
いまERPプログラムを進めていますか?
この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。




