SAP導入プロジェクトを正しく始めるには

SAP導入を正しく始めるには、誰かがトランザクションを設定する前に、5つのことを決めておく必要があります。デプロイメントモデルを選びます。スコープと意思決定権限を定めたプロジェクト憲章に署名します。設計ワークショップに出席する業務オーナーを指名します。データとカットオーバーの作業を早期に始めます。現実的なコンティンジェンシーを含むスケジュールを組みます。最初の1か月でこれらを押さえれば、高くつく失敗の大半は起こりません。

SAP導入は、システムさえ正しく設定されていれば問題なく進むものだと、私は長い間考えていました。ブループリント、構築、テスト、本稼働。何年もの間、これが私の頭の中のモデルでした。

私は中東、東南アジア、ヨーロッパで、SAPを含むERPの導入に25年携わってきました。チームがSAP Activateを一歩ずつ忠実に踏んでいても、プロジェクトはつまずきました。原因はほとんど技術的なものではありません。弱いオーナーシップ。誰も確認していなかった前提。遅すぎたカットオーバー計画。こうしたひびは、最初のうちは無害に見えます。ひとたび広がってしまうと、終盤にどれだけ力を注いでも、早い段階で見えていれば防げたはずの問題は直せません。

SAP導入は、ソフトウェアの要素を含んだ業務変革プログラムです。ワークストリームは、プロセス設計、コンフィグレーション、データ移行、連携、テスト、トレーニング、チェンジマネジメントです。それぞれに独自のスケジュール、リスク、オーナーがあります。

これをコンフィグレーション作業として扱うチームは、コンフィグレーション以外のすべてに十分な予算を割きません。私が見てきた難航した本稼働の原因として、これが最も一貫しています。

今まさに始まるプログラムでは、先に決めるべきワークストリームがもうひとつあります。デプロイメントモデルです。S/4HANA Cloud Public Edition（GROW with SAP）、Private Edition（RISE with SAP）、またはオンプレミス。この選択が、ほかのすべてのワークストリームの進み方を左右します。

SAP ActivateはSAPの導入メソッドです。6つのフェーズがあり、それぞれの終わりに品質ゲートがあります。各フェーズの目的と、私が決して疎かにしないことを示します。

フェーズ	行うこと	私が確実にしておくこと
Discover	ビジネスケース、大枠のスコープ、デプロイメントモデル	楽観的な見積りではなく、現実的なコストとスケジュール
Prepare	ガバナンス、プロジェクト憲章、チーム、リスク登録簿、環境	実質的な権限を持つ、名前の挙がった意思決定者
Explore	Fit-to-Standardワークショップ、ギャップの判断、設計承認	ITだけでなく、業務オーナーが同席していること
Realize	コンフィグレーション、開発、連携、システムテスト	カットオーバー計画がすでに進んでいること
Deploy	ユーザー受入テスト、データロード、トレーニング、カットオーバー	本番を想定した通しリハーサルを少なくとも1回
Run	本稼働、ハイパーケア、サポートへの引き継ぎ	最初の月次決算までハイパーケアの体制を維持

スケジュール遅延で最も多いのは、Exploreの遅れです。それがRealizeを圧縮し、Deployを圧縮します。ユーザー受入テスト（UAT）は短縮され、データのリハーサルは省かれ、日付がすでに公表されているという理由で、本稼働は予定どおり行われます。その代償は、本稼働後の最初の90日で支払うことになります。

1. 01Exploreが遅れるFit-to-Standardと設計承認が遅れる
2. 02Realizeが圧縮される構築とテストの時間が減る
3. 03Deployが圧縮されるUAT、データロード、トレーニングの時間が減る
4. 04テストが削られるUATが短縮され、データのリハーサルが省かれる
5. 05公表した日付で本稼働日付がすでに公表されているため

そのコストは、本稼働後90日間のハイパーケアにのしかかります

1. 業務部門不在の設計承認

Exploreの成果物は設計です。その質は、承認したプロセスオーナーが、自分が何に署名しているのかを理解していたかどうかで決まります。ワークショップにITとコンサルタントしか出席していないと、設計は技術的に正しくても、実際に使う人にとっては見覚えのないものになりかねません。そうなるとUATは、検証ではなく、新たな発見の場になってしまいます。

簡単な確かめ方があります。承認から3か月後に、プロセスオーナーに、本稼働後に購買発注がどう流れるかを説明してもらってください。答えられなければ、その承認は実質を伴っていなかったということです。

2. 書類の上にしかないガバナンス

ガバナンスが徹底されていないと、スコープは非公式に膨らみ、意思決定は先送りされます。優れたガバナンスとは、名前の挙がったエグゼクティブスポンサー、意思決定権限が明確なステアリングコミッティ、フェーズゲートを守れるプロジェクトマネージャー、承認者が決まっている変更管理プロセスを指します。

私が関わったプロジェクトの大半では、CFOがプロジェクトチャンピオンの役割を担いました。部門間でプロセスが合意できないとき、最終判断を下したのはそのCFOです。おかげで、課題が未解決のまま放置されて何週間も遅れる事態を防げました。この体制の作り方は、SAPステアリングコミッティのガイドで解説しています。

3. 遅すぎるカットオーバー計画

カットオーバーは、プログラムの中で運用面が最も複雑な部分です。本稼働の数週間前に作り始めた計画は、リハーサルされず、依存関係を見落とし、実際に戻れる地点（ロールバックポイント）も持てません。

カットオーバー計画はRealizeで始めてください。手順を文書化し、通しリハーサルを少なくとも1回実施し、ロールバックの基準を事前に合意します。事前に合意した基準もないまま、20時間起きっぱなしの人たちがプレッシャーの中で下すカットオーバーの判断。本稼働後の大きなトラブルは、そこから始まります。

4. 削られる結合テスト

正直に言うと、以前の私はテストを、チェックリストの1項目だと思っていました。システムを設定し、テストケースをいくつか実行し、次へ進む。ところがあるプロジェクトで、購買承認が財務会計への転記にどう影響するかを誰も確認しなかっただけで、プロジェクトが崩壊するのを目にしました。その出来事が、SAPのテストに対する私の見方を変えました。

単体テストが証明するのは、トランザクションが単独で動くことだけです。本稼働後に痛手となる障害は、プロセス全体がモジュールをまたいで流れたときに現れます。購買発注のステータスによってブロックされた入庫。勘定決定が未設定のために止まった請求処理。受注から入金まで（Order to Cash）、調達から支払まで（Procure to Pay）の一連の流れ全体をテストし、UAT直前の数週間まで後回しにしないでください。

5. 過小評価されるデータ移行

移行元のデータは、最初の評価が示すより、ほぼ確実に状態が悪いものです。単純に見えたフィールドマッピングがロード時に失敗します。レコード件数には、使われていないデータが含まれています。クレンジングのルールには業務上の判断が必要で、それには時間がかかります。

ある製造業の企業では、移行中に数千件の顧客レコードの重複が見つかり、その修正のために本稼働を3週間延期せざるを得ませんでした。ロードのサイクルは、最初から余分に見込んでおいてください。SAPデータ移行が失敗する理由の記事で詳しく説明しています。

6. 任意扱いにされるチェンジマネジメント

システムは完璧に動いているのに、利用者が古いやり方に固執しているプロジェクトを見てきました。彼らが扱いにくいからではなく、変化への移行を誰も丁寧に案内しなかったからです。チェンジマネジメントが削られると、最初の週に回避策が生まれ、それが恒久化し、サポートへの問い合わせは何か月も高止まりします。

大規模なカスタマイズも、同じカテゴリーに入ります。以前、システムの60%以上をカスタマイズしたクライアントと仕事をしたことがあります。そのクライアントは後のアップグレードに苦労し、ベンダーサポートも失いました。

上記の基本は変わっていません。ただ、今日のプログラムでは、開始時に決めておくべきことが3つあります。

デプロイメントモデルが最初です。 Public Editionはカスタマイズの選択肢が最も狭く、システムの運用はSAPが担います。RISEのPrivate Editionでは、より余地が広がり、インフラの運用はSAPが担います。オンプレミスは最も自由度が高く、その分、責任も最も重くなります。Discoverで決めてください。決定を先送りしたプログラムは、Exploreの間ずっとその議論に時間を費やします。

クリーンコアは、プロジェクト憲章に明記します。 Public Editionは、リリース済みのインターフェース経由でしか拡張を認めないため、クリーンコアを技術的に強制します。Private Editionとオンプレミスにはその強制力がないので、ガバナンス上の判断になります。SAPは現在、拡張をレベルA（リリース済みAPIのみ）からレベルD（モディフィケーション）までに分類しています。2025年8月のクリーンコアに関するアップデートで示されたとおりです。目標とするレベルと承認の場を、プロジェクト憲章に書き込んでください。そうしないと、パートナーは初期設定のままモディフィケーションに流れます。

AIツールは、初日からメソッドに組み込みます。 JouleはSAP Activate Roadmap Viewerの中で利用できます。Joule for consultantsはコンフィグレーションに関する質問に答え、Joule for developersはABAP Cloudのコードを生成します。これらは、ドラフト作成や構築のタスクを速められます。ただし、業務上の判断、データ作業、チェンジの労力がなくなるわけではありません。パートナーに、どこで使っているのか、それが計画にどう表れるのかを尋ねてください。

アプローチは、リスク許容度、複雑さ、変化への対応力に応じて選ぶべきです。よくある選択肢は次のとおりです。

アプローチ	内容	向いているケース
ビッグバン	すべてのモジュールと組織単位を同時に本稼働させる	標準的なスコープの小規模な組織。本稼働時のリスクが高くなることを受け入れる場合
モジュール別の段階導入	最初に財務、次にサプライチェーン、その後にHR	モジュール間の依存が少ない場合。フェーズの合間にチームが学べる
国・組織単位別の段階導入	1つの組織単位でテンプレートを本稼働させ、その後に展開する	グローバルテンプレートを持つグループ
ブラウンフィールドコンバージョン	既存のECCをS/4HANAへコンバージョンする	プロセスが安定した、成熟したECC
グリーンフィールド	S/4HANAを新規に導入する	非SAPのレガシー、または技術的負債の重いECC
選択的データ移行	選んだ組織単位やデータを、再設計したシステムへ移す	合併、カーブアウト、部分的な再利用

半年足らずで本稼働した小規模な展開を見たことがあります。一方で、意思決定が間に合わなかったために2年も長引いたプロジェクトも見てきました。初めての導入とテンプレートの展開のどちらにするか迷っているなら、導入とロールアウトの違いを比べたガイドをご覧ください。

最初の1か月、コンフィグレーションを始める前にこれを使ってください。各項目には、顧客側のオーナーがいます。

1. エグゼクティブスポンサー: デプロイメントモデルを決定し、その理由とともに記録していること。
2. プログラムディレクター: スコープ、明示的な除外事項、成功基準、意思決定権限、変更管理を網羅したプロジェクト憲章に署名済みであること。口頭でのスコープ合意は消えてしまいます。私のプロジェクト憲章のガイドにテンプレートがあります。
3. 業務リーダー: 領域ごとに指名されたプロセスオーナーがいて、ワークショップに出席するための時間が実際に確保されていること。
4. ソリューションアーキテクト: クリーンコアの目標と、拡張の承認の場が合意されていること。
5. データリード: データプロファイリングを、設計承認の後ではなく、Prepareで開始していること。
6. カットオーバーリード: Realizeで指名され、計画にはすでにリハーサルの日程が入っていること。
7. テストマネージャー: 承認から財務会計への転記までを含む、プロセス全体を通したテストシナリオが列挙されていること。
8. CFO: スケジュールを類似のプログラムと照らして確認し、Exploreの遅れとデータサイクルの追加に備えたコンティンジェンシーを持たせていること。すべてがうまくいく前提の計画は、計画とは言えません。

SAP導入プロジェクトとは何ですか？

企業の業務を動かすためにSAPソフトウェアを導入するプログラムです。プロセス設計、コンフィグレーション、データ移行、連携、テスト、トレーニング、チェンジマネジメントを含み、通常はSAP Activateで進めます。必要な労力は、組織単位、国、モジュールの数や、既存データの状態によって大きく変わります。

SAP導入にはどのようなフェーズがありますか？

SAP Activateには、Discover、Prepare、Explore、Realize、Deploy、Runの6つのフェーズがあります。Discoverではビジネスケースとスコープを定めます。Prepareではガバナンスとチームを整えます。ExploreではFit-to-Standardワークショップを行い、設計を確定します。Realizeでは構築とテストを行います。DeployではUAT、データロード、トレーニング、カットオーバーを扱います。Runは本稼働とハイパーケアです。各フェーズは品質ゲートで終わります。

SAP導入にはどのくらいかかりますか？

スコープと、意思決定の速さによります。半年足らずで本稼働した小規模な展開も、意思決定が間に合わず2年も長引いたプロジェクトも見てきました。超過の原因として最も多いのは、Exploreフェーズの遅れが、その後のすべてを圧縮することです。

SAP導入が失敗する最も多い理由は何ですか？

業務部門が実質的に関与しないまま承認された設計、徹底されないガバナンス、遅いカットオーバー計画、圧縮された結合テスト、過小評価されたデータ移行、削られたチェンジマネジメントです。6つとも、たいていは早い段階で見えており、その時点なら低コストで直せます。

SAPプロジェクト憲章には何を盛り込むべきですか？

測定可能な成果に結びついた目的、モジュール、組織単位、国、連携ごとのスコープ、明示的な除外事項、担当者の名前を挙げた意思決定権限、ガバナンスとエスカレーション、成功基準、変更管理、主要なマイルストーン、重要な前提条件です。クラウドのプログラムでは、デプロイメントモデルとクリーンコアの方針を加えてください。コンフィグレーションが始まる前に、スポンサーと業務リーダーに署名してもらいます。

SAP本稼働後のハイパーケアとは何ですか？

ハイパーケアとは、本稼働後に行う集中的なサポート期間で、通常は30〜90日です。プロジェクトチームと業務部門が並んで、問題を解決し、業務を安定させます。少なくとも1つの業務サイクル全体、つまり最初の月次決算までは体制を維持してください。多くの問題が最初に表れるのが、その時期だからです。