SAP導入テンプレート：フェーズ別ガイド

SAP Activateには、S/4HANAプログラムのほぼすべての成果物にテンプレートが用意されています。SAP Activate Roadmap Viewerで、クラウドプログラムではSAP Cloud ALMの中で、見つけられます。見つけるのは簡単です。難しいのは、どれを真剣に扱うべきかを知ることです。

このガイドは、導入のセットアップを担うプログラムマネージャー、PMOのリード、スポンサーに向けたものです。各フェーズで私が必ず使うよう求めるテンプレートを取り上げ、それぞれの実用的なレイアウトを示し、チームが手を抜きがちな箇所を指摘します。キックオフまで1週間しかないなら、まずスコーピング文書とステークホルダーマトリクスを作ってください。その後の作業はすべて、この2つに寄りかかります。

製造、小売、金融サービスで私が関わったECCとS/4HANAのプログラムでは、パターンは一貫しています。テンプレートに従うチームは、問題を早く見つけます。テンプレートを任意の事務作業として扱うチームは、プロジェクトの途中で、書き留めなかった判断のすべてがスコープをめぐる争いになっていたことに気づきます。

次が、承認済みであることを私が確認したいテンプレートの一式です。各テンプレートの責任者と、通過すべき時点も示します。

フェーズ	テンプレート	責任者	承認が必要な時点
Prepare	プロジェクトスコーピング文書	プログラムマネージャー（スポンサーが承認）	Exploreの開始前
Prepare	ビジネスケース	CFOまたは業務オーナー	予算が執行される前
Prepare	ステークホルダーマトリクス	プログラムマネージャー	Exploreのワークショップを予約する前
Explore	要件とフィットギャップのシート	ソリューションアーキテクトとプロセスオーナー	Realizeの開始前
Realize	設定ログ	ファンクショナルリード	各トランスポートがQAに移る前
Realize	カスタム開発台帳	開発リード	いずれかのオブジェクトの構築開始前
Realize	テスト戦略	テストマネージャー	システム統合テストの開始前
Realize	データ移行計画	データ移行リード	最初のモックロードの前
Deploy	カットオーバー計画	カットオーバーマネージャー	最終リハーサルの前
Deploy	本稼働準備アセスメント	プログラムディレクター（スポンサーが署名）	Go/No-Go会議の前
Run	ハイパーケアのサポートモデル	サービスデリバリーリード	本稼働の前
Run	パフォーマンス監視シート	Basisリード	本稼働の前

Activateは、Discover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズからなります。SAP Best Practicesのコンテンツ、ガイド付き設定、アジャイルなデリバリー手法を組み合わせたものです。多くのお客様では、Discoverは契約締結前に行われるため、以下のテンプレートはPrepareから始めます。

1. 01Discover通常は契約締結前に行う
2. 02Prepareスコーピング文書、ビジネスケース、ステークホルダーマトリクス
3. 03Explore要件とフィットギャップのシート
4. 04Realize設定ログ、開発台帳、テスト戦略、移行計画
5. 05Deployカットオーバー計画、本稼働準備
6. 06Runハイパーケアモデル、パフォーマンス監視

すべてのテンプレートが、それぞれのゲートの前に承認されている

フェーズの順序は、省略できません。あるリテーラーが一部を飛ばそうとして、3か月分の作業をやり直すことになったことがあります。クオリティゲートは、どれも理由があって存在します。

テンプレートを自社向けに調整するときは、標準の構造の約80%を残してください。変更するのは、自社の事情を反映する部分だけにします。業界の要件、規制上のコントロール、地域固有の事情です。すべてを書き換えるのでは、意味がありません。

2026年に変わったツール群

Activateの構造は、以前と同じです。その周りのツールが動きました。

1. クラウドプログラムでは、SAP Cloud ALMがテンプレートを保持します。 SAP Cloud ALMはSolution Managerの後継で、SAP Enterprise Supportと、RISE with SAPなどのクラウドサブスクリプションに含まれています。スコーピング、要件、テスト計画、カットオーバータスクをそこに置き、それぞれの間のトレーサビリティを保てます。Solution Manager 7.2は2027年末でメインストリームメンテナンスが終了し、一部の機能については延長メンテナンスが2030年まで続くため、既存のオンプレミス環境に残された期間は、10年ではなく数年です。
2. Jouleが、方法論のツールの中に入りました。 SAPは2025年に、Activate Roadmap ViewerとSAP Cloud ALMでJouleを利用できるようにしたため、チームはロードマップをもとに、タスクのガイダンスを求めたり、コンテンツのドラフトを作らせたりできます。最初のドラフトは速くなります。フィットギャップに署名する人の代わりにはなりません。
3. クリーンコアは、レベル付きの設計ルールになりました。 2025年8月、SAPは3層の拡張性モデルを、AからDの4つのクリーンコアレベルに置き換えました。レベルAは、SAP BTP上、またはABAP Cloudを使ったシステム内で、リリース済みのAPIだけを使います。レベルDは、クリーンではまったくありません。フィットギャップのテンプレートには、各ギャップがどこに着地するのかを示す列が必要です。
4. Public Editionは、フィットギャップの幅を狭めます。 SAPは現在、S/4HANA Cloud Public EditionをSAP Cloud ERPとして展開しており、中堅企業向けにはSAP GROWとして販売されています。同じ6つのフェーズが、より軽い成果物で適用され、拡張はリリース済みAPIによるものだけが認められるので、「ギャップ」の列に入りうる答えは少なくなります。

この下準備を飛ばしたプロジェクトは、ExploreとRealizeでその代償を払います。

プロジェクトスコーピングのテンプレート

プロジェクトに含まれるものと含まれないものを定義します。3か月経ってから誰かがスコープを追加しようとしたとき（必ず出てきます）、この文書が拠り所になります。SAPプロジェクト憲章はこの上位にあり、ガバナンスの詳細を担います。

セクション	内容
タイトル、スポンサー、PM	SAP S/4HANA Financeの導入、CFO、指名されたシニアPM
背景	現状と、変革の動機
目的	決算サイクルを14日から5日に短縮する。手作業の照合をなくす
スコープに含むもの	FI/CO、MM/SD連携、データ移行、UAT、本稼働
スコープ外	HRモジュール、レガシーレポートの移行、ERPを超えるサードパーティ連携
前提条件	エグゼクティブスポンサーが月次のステアリングコミッティに出席できる。テストデータが第6週までに合意される
制約	本稼働日は固定。設定は社内リソースのみで行う
成果物	設定済みのシステム、テスト計画、カットオーバー計画、トレーニング資料
スケジュール	Prepare：第1〜4週、Explore：第5〜10週、Realize：第11〜26週
承認	Exploreの開始前に、プロジェクトスポンサーとPMOの承認が必要

ビジネスケースのテンプレート

財務チームが読める形式で、費用対効果の分析を順に示します。この構成を使って、初回の提出でプログラム承認を得たクライアントもいます。数字が明確で、前提が書き出されているからです。

私が守っているルールが1つあります。作業を担当するシステムインテグレーターに、この文書を書かせてはいけません。向こうの動機は、始めることです。御社の動機は、終わらせることです。SAPビジネスケースのテンプレートでは、ベネフィットのモデルをさらに掘り下げています。

セクション	内容
オーナーと概要	CFOまたはプログラムディレクター。なぜ今なのか、何が変わり、何が変わらないのか
課題の定義	具体的な業務上の問題（決算サイクルの長さ、手作業による回避策、システムの古さ）
提案するアプローチ	グリーンフィールド／ブラウンフィールド／セレクティブ、スコープの要約つき
ベネフィット	定量化したもの：決算サイクルの短縮日数、FTEの削減、エラー率の低減、監査リスクの低減
コストと資金	導入、ライセンスまたはサブスクリプション、社内リソースの工数、予備費、予算の出所
リスク	上位3件、発生確率と影響度つき
推奨	進める／条件付きで進める／延期する、根拠つき

ステークホルダー特定マトリクス

導入の影響を受けるすべての人と、それぞれの影響力のレベルを整理します。誰に毎週の報告が必要で、誰には本稼働前に一言伝えておけばよいのかが、ひと目でわかります。

ステークホルダー	役割	関心事	影響力	エンゲージメント
グループCFO	エグゼクティブスポンサー	プログラムのROI、決算の改善	高	月次のステアリングコミッティ、週次の書面報告
ITディレクター	技術面のオーナー	システムの安定性、連携、セキュリティ	高	週次のプログラムボード、Realize中は毎日
財務ディレクター	主要なプロセスオーナー	FI/COの設計、決算プロセス	高	Exploreでのワークショップ、UATの承認
工場長	影響を受けるユーザー	MM/PPのプロセス変更	中	月次の変更周知、UATへの参加
エンドユーザー（AP/AR）	オペレーター	トランザクション単位の変更	低	トレーニング、ハイパーケアのサポート
内部監査	ガバナンス	トレーサビリティ、統制、コンプライアンス	中	クオリティゲートでの成果物レビュー

同じマトリクスを使って、部門ごとにハイレベルの要件を集めるPrepareのワークショップを計画してください。それらの要件には、Exploreで使う形式（REQ-001など）で番号を振っておくと、後で番号が振り直されることがなく、最初の依頼までさかのぼる追跡も残ります。

Exploreは、導入の形が決まる段階です。次のテンプレートは、SAPが標準で行えることと、ビジネスが必要とすることとの間のギャップを明らかにします。

要件マッピングとフィットギャップのテンプレート

要件マッピングは、部門ごとにビジネスニーズを記録し、それぞれをシステムのコンポーネントとテストケースにまでたどれるようにします。これを省いた結果、誰も使わないシステムになった会社を見たことがあります。構築が、ビジネスが言ったことではなく、コンサルタントが思い込んだことに基づいていたからです。

フィットギャップ分析は、標準のSAPがどの要件を満たし、どれを満たさないかを示します。多くのクライアントにとって、これは大きな気づきになります。高額なカスタムコードの代わりに標準機能を使えると、チームが気づく瞬間を見るのが私は好きです。

私は両方を1枚のシートにまとめ、解決方法の列を設けています。S/4HANAでは、すべてのギャップに明確な答えが要ります。標準設定、キーユーザー拡張、システム内でのデベロッパー拡張、あるいはSAP BTP上のサイドバイサイド拡張です。SAPコードへの従来型の改修は、最も高くつく答えで、承認者の名前を必須にすべきです。

Req ID	要件	SAPコンポーネント	Fit / Gap	解決方法	テスト参照
REQ-001	月次決算の仕訳の自動化	FI-GL、期末処理	Fit	定期仕訳のテンプレートを設定する	TC-001
REQ-002	Fioriによる購買発注の承認	MM購買、Fiori承認アプリ	Gap（ECCにはない）	標準のS/4HANAアプリとワークフローを設定する	TC-003
REQ-003	会社間請求の自動化	SD請求、FI連携	Gap	会社間請求の設定	TC-010
REQ-004	バッチジョブの監視	Application Jobsアプリ	Fit	標準アプリ	TC-015
REQ-005	サプライヤーのセルフサービスポータル	SAP Aribaまたはサプライヤーポータル	Gap	Aribaとの連携	TC-020
REQ-006	GDPRに準拠したデータアーカイブ	ILM、データアーカイブ	Gap	ILMポリシーの設定	TC-025
REQ-007	原価センタのリアルタイムレポート	CO、エンベデッドアナリティクスまたはSAC	Gap	エンベデッドアナリティクスまたはSACのライブ接続	TC-030
REQ-008	同時ユーザー500人のサポート	HANAのサイジング	Gap（300人でテスト済み）	サイジングの見直しとインフラの増強	TC-035

ここは構築のフェーズです。次のテンプレートは、すべての設定判断、すべての開発、すべてのテスト結果の監査証跡になります。

設定管理のテンプレート

システムへの変更をすべて記録します。誰が、なぜ行い、どのトランスポートに入ったのかを残します。あとで何かが壊れたとき、原因を数日ではなく数分でたどれます。

1. 設定IDとモジュール：[例：MM-CONF-001、MM]
2. IMGパスと設定オブジェクト：[例：テーブルT161、発注伝票タイプ]
3. 目的と、影響を受ける業務プロセス
4. 設定者と日付
5. トランスポートリクエスト番号：[例：DEVK900123]
6. 主要な値：変更前と変更後
7. 関連するテストケース
8. 検証と承認のステータス

カスタム開発台帳

カスタムオブジェクトは、誰かがコードを書く前に、1件ごとに1行を登録します。私のクライアントの1社は、標準のSAPで十分に対応できる箇所が台帳で見えたおかげで、カスタムコードを30%減らしました。

Dev ID	オブジェクト	説明	開発者	工数（時間）	ステータス	拡張タイプ
CD-001	Fioriタイル：原価センタの概要	財務向けのリアルタイムCOレポートのタイル	Fiori開発者	12	完了	デベロッパー拡張
CD-002	会社間請求レポート	会社間照合用のレポート	ABAP開発者	20	進行中	デベロッパー拡張
CD-004	仕入先支払ステータスアプリ	AP支払照会用のFioriアプリ	BTP開発者	10	QA待ち	BTP上のサイドバイサイド
CD-005	入庫通知	入庫転記時のメール送信トリガー	連携開発者	24	計画済み	イベントベース、BTP上

テスト戦略のテンプレート

すべてのテスト計画を一か所にまとめます。誰が、何を、いつ、どの環境で、どの基準でテストするのかを記載します。

セクション	内容
スコープ	対象モジュール全体にわたる、機能、連携、リグレッション、パフォーマンス、UAT（ペネトレーションテストは情報セキュリティ部門が担当）
環境	DEV、QA、UAT（本番前環境）、最終検証用のステージング
ツール	SAP Cloud ALMまたはJira/Xrayでのテスト管理。Tricentis Toscaなどによる自動化。JMeterまたはLoadRunnerによるパフォーマンステスト
不具合のライフサイクル	新規、対応中、解決済み、検証済み、クローズ。重大度と優先度はトリアージ時に設定
終了基準	重大な不具合がすべてクローズされている。UATの承認を受領している。リグレッションの合格率が95%以上。パフォーマンスのベンチマークを満たしている

データ移行計画のテンプレート

データ移行は、最も痛い目に遭いやすいワークストリームです。このテンプレートは、それをいくつかのステップに分け、データ品質の問題をカットオーバーの最中ではなく、その前に見えるようにします。データ移行が失敗するパターンの記事では、これを省いたときに何が起きるかを扱っています。

セクション	内容
スコープ	得意先マスタ、仕入先マスタ、未決済明細、品目マスタ、在庫残高、原価センタ階層
移行元システム	ECC 6.0 EHP 7（主）。レガシーHRシステム（従業員の原価センタ割り当て）
移行先システム	S/4HANA（現行リリース）
マッピングとルール	得意先と仕入先はビジネスパートナーへ。原価センタは新しい階層へ。無効な銀行情報は削除。重複はマージ
移行ツール	SAP S/4HANA Migration Cockpit（主）。カスタムオブジェクト用のMigration Object Modeler。事前処理用のスクリプト
ロード戦略	QAでのモックロード、差分移行と照合、本番カットオーバー
検証方法	移行元と移行先のレコード件数の照合、10%のランダムサンプリング、残高照合レポート
ロールバック計画	カットオーバー前のバックアップ。レガシーシステムは48時間スタンバイ

Deployフェーズは、本稼働させる段階です。次のテンプレートが、混乱しがちな週末を、管理されたイベントに変えます。

カットオーバー計画のテンプレート

ブラックアウト期間を、1時間単位で書き出します。すべてのタスク、すべての担当者、すべての開始時刻です。午前2時に、チームが次に何をすればいいのかわからないまま立ち尽くす、ということがあってはなりません。

タスクの一覧を書く前に、4つのことに合意してください。期間（たとえば、金曜の22:00から土曜の06:00まで）、ロールバックの判断基準、レガシーシステムをどれだけ速く再稼働できるか、そして新システムが動くことを確かめるスモークテストです。そのうえで、タスクの順序です。

ステップ	内容	担当	開始時刻	ステータス
1	ECCシステムを凍結する（転記なし）	Basis	22:00	未着手
2	最終のデータ抽出と照合	データ移行リード	22:30	未着手
3	本番の移行ロードを実行する	DBA	23:00	未着手
4	残りのトランスポートを本番にインポートする	Basis	00:30	未着手
5	DNSとロードバランサーをS/4HANAに切り替える	ネットワーク	01:30	未着手
6	スモークテスト：FI転記、入庫、受注	QAリード	02:00	未着手
7	ビジネス側の確認とGo/No-Goの判断	プログラムディレクター	03:00	未着手
8	ビジネスユーザーにシステムを開放する	Basis	06:00	未着手

本稼働準備アセスメント

本当に切り替える準備ができているかを判断します。このアセスメントをもとに本稼働を延期したクライアントもいて、彼らは後から感謝してくれました。

領域	チェック項目（それぞれ、根拠を添えて「はい」か「いいえ」で回答）
機能	主要プロセスのテストが完了している。モジュールをまたぐシナリオが完了している。未解決のP1/P2不具合が一覧化されている。キーユーザーが準備完了を確認している
データ	マスタデータのロードが完了している。トランザクションデータが検証されている。照合レポートが承認されている。レガシーの凍結が確認されている
技術	カットオーバー計画が承認されている。トランスポートが本番にある。バッチジョブがスケジュールされている。監視が設定されている
人	トレーニングの受講率（%）。アクセスロールが検証されている。ハイパーケアチームが配置されている。サポート計画が周知されている
判断	重大なリスクと対策が一覧化されている。Go／No-Go／条件付き。氏名、役割、日付つきで承認されている

本稼働の後は、仕事の形が変わります。次のテンプレートは、システムとチームをハイパーケアから定常運用へと導きます。

導入後サポートのテンプレート

ローンチ後の問題への対処方法を整理します。これがなければ、あらゆる問題がP1になります。

セクション	内容
ハイパーケア期間	本稼働後の第1〜4週：24時間体制の対応
サポートチャネル	ServiceNowのインシデントキュー（主）。専用のチャットチャネル。P1の問題用の電話ブリッジ
サポート階層	1：サービスデスク（パスワード、画面操作、既知の問題）。2：ファンクショナルコンサルタント（プロセスの問い合わせ、軽微な設定）。3：Basisと開発（システムエラー、パフォーマンス、インターフェース）
SLA（応答／解決）	緊急：15分／2時間。高：30分／4時間。中：4時間／1日。低：1日／3日
監視	SAP Cloud ALMまたはSolution Manager。エラーログの日次レビュー
終了基準	未解決のP1/P2の問題がない。すべてのインシデントが文書化されている。最終的な引き継ぎの承認がある

パフォーマンス監視のテンプレート

システムの健全性を日々見守り、ユーザーから苦情が出る前に速度低下を見つけられます。最近、ある会社でこの方法によって、月次決算の最中にシステムを落としかねなかったデータベースの問題を見つける手伝いをしました。

指標	目標	ツール	アラートのしきい値	責任者
ダイアログの応答時間（95パーセンタイル）	1秒未満	ST03 / SAP Cloud ALM	2秒	Basisチーム
バックグラウンドジョブの完了	スケジュールどおり100%	SM37 / Application Jobs	失敗したジョブがあった場合	運用リード
データベースのクエリ時間	200ミリ秒未満	SAP HANA cockpit	500ミリ秒	DBA
システムの可用性	99.5%超	SAP Cloud ALM	99%未満	インフラ
インターフェースのエラー率	1%未満	SAP Integration Suiteの監視	2%	ミドルウェアリード
ログイン成功率	98%超	セキュリティ監査ログ	95%未満	セキュリティリード
月次決算ジョブの実行時間	合意した時間枠内	ジョブスケジューラー	ベースラインを30%超えた場合	財務オペレーション

クオリティゲートは、あるフェーズの問題が、次のフェーズで高くつく手戻りになるのを防ぎます。設定方法は、私のSAPクオリティゲートのガイドで扱っています。ここでは、それがなぜ重要なのかを書きます。

本稼働前の経営層の承認は、形だけの承認であってはなりません。私が関わったあるプロジェクトでは、本稼働レビューのときにCEOが大きな問題に気づき、それが財務チームの業務を混乱させるところでした。

各ゲートに、合否の基準を設けてください。「リグレッションテストの95%が合格すること」「FI連携のシナリオがすべてグリーンであること」。こうした基準があれば、品質に関係なくビジネスが決まった日に本稼働したがるときも、一線を守るための根拠を持てます。

私のプロジェクトの1つでは、連携テストの合格が75%にとどまった時点で、クオリティゲートが私たちを止めました。先を急がずに、まず問題を直しました。そのおかげで、クライアントは本稼働後の緊急対応に約10万ユーロを使わずに済みました。

スポンサーが電話1本で覆せるゲートは、ゲートではありません。必要になる前に、誰が免除できるのかを書き留めておいてください。

SAP Activate方法論とは何ですか？

SAP Activateは、S/4HANAとSAPのその他のクラウド製品のための、SAPの導入方法論です。6つのフェーズ（Discover、Prepare、Explore、Realize、Deploy、Run）で進み、SAP Best Practicesのコンテンツ、ガイド付き設定、アジャイルなデリバリーを組み合わせています。

各導入シナリオのタスクリストと成果物のテンプレートは、SAP Activate Roadmap Viewerで公開されています。

SAP Activateのどのフェーズに、最も重要なテンプレートがありますか？

Prepareです。スコーピング文書、ビジネスケース、ステークホルダーマトリクスは、その後のあらゆる判断の土台になります。そして、設定に早く取りかかるために、チームが省略してしまうのもこの3つです。この近道が、Realizeでスコープをめぐる争いが起きる最も多い原因です。

次がExploreです。フィットギャップと要件マッピングの文書に穴があると、数か月後にUATの不具合として表面化します。そのときの修正費用は、Exploreの第3週に直していた場合よりも、はるかに高くつきます。

SAP Activateのテンプレートをカスタマイズできますか？

できます。標準の構造の約80%を残し、自社の事情に固有の部分だけを変更してください。たとえば、医薬品のバリデーション、公共部門の調達ルール、SOXのコントロールです。これらは、Deployではなく、Prepareの最初に加えてください。

クオリティゲートの構造、フェーズの順序、必須の成果物（スコーピング文書、ビジネスケース、本稼働準備アセスメント）は、カスタマイズしないでください。

SAP Activateのテンプレートは、グリーンフィールドとブラウンフィールドの両方で使えますか？

はい。主な違いはExploreにあります。ブラウンフィールドのコンバージョンでは、既存の設定を引き継ぐため、フィットギャップは、何を変更する必要があるか、標準のS/4HANAがどのカスタムコードを置き換えられるようになったか、コンバージョンの前にどのようなデータクレンジングが必要かに焦点を当てます。グリーンフィールドのプログラムは、SAP Best Practicesから出発し、どの標準プロセスが合うかを確認します。

カットオーバー計画も異なります。ブラウンフィールドのシステムコンバージョンは、全データを移行するグリーンフィールドの本稼働とは、異なる手順になります。

カットオーバー計画は、どれくらい詳細にすべきですか？

最低でも1時間単位で、ブラックアウト期間についてはそれより細かくします。すべてのタスクに、開始時刻、担当者、依存関係が必要です。

ロールバックの基準は、カットオーバーが始まる前に合意してください。どの条件でレガシーシステムに戻すのか、誰がその判断をするのか、何時までに判断するのかです。事前に合意した基準なしに午前4時に下すロールバックの判断が、本稼働後の大惨事の始まりです。