SAP導入プロジェクト憲章の作り方

SAP導入のプロジェクト憲章とは、プログラムを正式に承認する短い文書です。プログラムが何を納品し、何を納品しないのか、誰が決定するのか、成功をどう測り、いつまでに達成するのかを、文書で確定させます。ベンダーとの作業範囲記述書（SOW）に署名する前に作成し、クライアント側のスポンサーが責任を持ち、議論に決着をつけられるだけの具体性を持たせてください。項目ごとの構成例は後述します。

チームは自信を持ってSAPのキックオフ会議に臨みます。ところがその後、役割の定義が曖昧で、スコープの境界についても合意がなく、成功がどういう状態なのか誰も説明できないことに気づきます。それを防ぐのが憲章の役目です。しかし、多くの憲章はそうなっていません。作業の拠り所にするためではなく、ガバナンス上の要件を満たすために書かれているからです。

見た目はきれいなのに、実際の計画とつながっていないプロジェクト憲章を見たことがあります。機能する憲章とは、作成中に関係者が意見をぶつけ合うものです。そうなっていれば、その憲章は正直だと言えます。

大規模なSAPプログラムでは、必ずこの3つの文書が混同されます。役割はそれぞれ異なります。

文書	目的	作成者	時期
プロジェクト提案書	プロジェクトを実施すべき理由を示す	事業部門のスポンサー	承認前
プロジェクト憲章	プロジェクトを承認し、スコープ、目的、担当者の氏名、ガバナンスを確定する	スポンサーとプログラムマネージャー	立ち上げ時
プロジェクト計画書	作業の進め方を定める。タスク、リソース、依存関係	プログラムマネージャー	憲章の承認後

憲章はガバナンスの文書です。線を引くものです。S/4HANAプログラムが複数のモジュール、国、ベンダーにまたがるなら、各自が勝手な前提を置き始める前に、何を含めるのかを決める場が憲章です。

事業成果に結びついた目的

「システムの近代化」ではいけません。目的にはそれぞれ数字が必要です。確かめる方法があります。ビジョンを、スライドなしで30秒のうちに取締役に説明できるでしょうか。

私が関わったSAPプログラムの中には、本稼働の時点では全員が祝杯を挙げたものの、2か月後には約束した価値が実現したのかどうか誰も説明できなかったものがあります。ある製造業のクライアントは400万ドル以上を投じながら、リターンを何も示せませんでした。CFOが指標を求めても、誰も持っていません。その結果、次回の資金調達が遅れました。

対照的なのが、私が支援した小売業のクライアントです。憲章には、初日からKPIが定義されていました。受注処理コストが32%下がったことを示し、フェーズ2はすぐに承認されました。

除外事項を明記したスコープ

最も見落とされやすい項目です。チームはスコープ内の項目を詳細に書き、除外事項を書き落とします。ところが、議論が起きるのはまさにその部分です。

私が一緒に仕事をしたヘルスケア企業は、この方法でSAP展開の焦点を保ちました。ユーザー受入テスト（UAT）の最中に、マーケティング責任者がキャンペーン追跡用の分析機能を追加したいと言い出しました。憲章にその余地はなく、ステアリングコミッティはすぐに指摘しました。この判断一つで85万ドルを節約し、6週間の遅延を回避できました。

部署ではなく、個人の名前を書く

「財務チーム：レポートに関する意見を提供する」では、誰も責任を負いません。「財務リード、[氏名]：レポート要件を定義し、FI/COの設定を承認し、データ移行の準備状況を承認する」なら、責任が明確になります。

コミットメントとしてのマイルストーン

ある小売業のクライアントは、本稼働が4か月遅れました。きっかけは、要件定義で生じた3週間の遅れでした。誰もそれをスケジュールに反映しませんでした。後工程で取り戻せると考えたのです。結果は逆で、180万ドルの超過費用が発生しました。

逆の例もあります。ある製造業の案件では、チームが公表した計画を守りました。データ移行チームが遅れを報告すると、ステアリングコミッティは直ちに要員の増強を承認しました。憲章によってマイルストーンが見える状態になっていたからです。この判断で、時間と60万ドルの両方を節約できました。

予算、リスク、依存関係

概算の予算、プログラムを頓挫させかねない3つか4つのリスク、そして同じ人材と予算を奪い合う他のプログラムを記載します。ある小売業のクライアントは、本稼働に至らなかった導入に320万ドルを費やしました。財務再設計とSAPプロジェクトが、同じリソースと同じ予算枠で並行して走っていたのに、どちらの憲章も相手に触れていませんでした。経営陣が気づいたときには手遅れでした。

私ならこの構成から始めます。各項目は1ページ以内に収めてください。

1. 目的と背景：なぜ今なのか、何が壊れているのか、何もしなければどうなるか。
2. 目的と成功指標：各目的に、ベースライン、目標値、期日を付けます。
3. スコープ：対象となるモジュール、プロセス、法人、国、拠点、連携、データ。
4. スコープ外：スコープと同じ丁寧さで書き、除外した各項目を先送りするフェーズも記します。
5. 導入形態と拡張ルール：S/4HANA Cloud Public Edition、RISEのPrivate Edition、またはオンプレミス。そして、カスタム開発をどう承認するか。
6. ガバナンス：スポンサー、ステアリングコミッティ、デザインオーソリティ、変更管理、エスカレーション経路。いずれも個人の名前で記します。
7. 役割と責任：プロセス領域、データ、テスト、チェンジ、カットオーバーのそれぞれについて、担当者の個人名を記します。
8. マイルストーン：日付付きのフェーズゲートと、通過の基準。私のクオリティゲートのガイドに例があります。
9. 予算とコンティンジェンシー：予算枠、コンティンジェンシー、そして誰がそれを解放できるか。
10. リスク、前提、依存関係：並行プログラムや規制上の期限も含みます。
11. コンプライアンス要件：たとえば、米国ヘルスケアのHIPAA、製薬のGxP、米国上場企業のSOX。
12. 承認：スポンサーと事業部門のリーダー。バージョン番号と日付を付けます。

1. 01現場を知る人に聞くスポンサー、事業部門のリーダー、エンドユーザー
2. 02必須と希望を仕分ける本稼働に必要、フェーズ2、またはこのプロジェクトの対象外
3. 03テンプレートから始めるそのうえで、連携、データ、コンプライアンスを加える
4. 04議論に決着をつけられるだけ具体的にする各目的が達成されたと証明できるか
5. 05本当の承認を得る項目ごとに読み、問いただし、受け入れる

三か月目にスコープをめぐって揉めたときに、立ち返れる憲章

1. 現場を知る人に聞く

何かを書き始める前に、スポンサー、事業部門のリーダー、エンドユーザーと膝を突き合わせてください。何が壊れているのか、これまでに何を試したのかを聞きます。以前、ある製造業のクライアントの案件に関わりました。現場が何を必要としているかをわかったつもりでSAP導入を進め、180万ドルを無駄にしました。6か月が経って、本当の業務フローの問題には手が付けられていないことが判明したのです。

私が関わった財務変革では、ITが効率の問題を解決するためにSAPを展開しようとしていました。財務部門と話してみると、本当の問題はデータ品質の低さだとわかりました。聞いていなければ、数百万ドルをかけて、間違った問題を直していたはずです。

2. スコープを書く前に、必須と希望を仕分ける

あらゆるインプットを、本稼働に必要なもの、フェーズ2に回すもの、このプロジェクトの対象外のものに分類します。私のクライアントであるプロフェッショナルサービス企業は、要件が3か所に分散し、プロジェクトが始まって何か月もたってから「再発見」され続けたせいで、予算を40%超過しました。私のスコープテンプレートのガイドが、この作業の助けになります。

3. テンプレートから始め、SAP固有の事項を加える

汎用のテンプレートは、SAPプログラムのコストを押し上げる要素を取りこぼします。連携ポイント、データ移行とクレンジングの責任者、モジュールごとの前提、コンプライアンス要件、そしてカスタム開発のルールです。データクレンジングに一度も触れない汎用の憲章でスタートしたSAPプロジェクトの話を聞いたことがあります。6か月後、レガシーデータがひどい状態だと判明し、75万ドルと3か月が上乗せされました。

4. 議論に決着をつけられるだけ具体的にする

シンガポールの小売業のクライアントで、導入を取り仕切ったことがあります。そのクライアントの憲章には「在庫管理の近代化」と書かれていました。チームの半分は処理の高速化だと受け取りました。残りの半分は需要予測に力を入れました。結果として180万ドルを費やしても、成功がどういう状態なのか合意できませんでした。すべての目的について、自問してください。これが完了したと証明できるか、と。

5. 本当の承認を得る

憲章が完成するのは、署名する人たちが読み、問いただし、その約束事を受け入れたときです。スポンサーと事業部門のリーダーに、項目ごとに説明して回ってください。小売業のクライアントが、憲章の合意形成にまる3日をかけたのを見たことがあります。それで、後になって何か月も続いたはずの議論とスコープ変更を避けられました。

間違い	引き起こすこと	代わりにすべきこと
曖昧な目的（「効率を改善する」）	チームがばらばらの方向に進む	すべての目的に数字を付ける
除外事項がない	スコープが静かに膨らむ	スコープ外のリストを、スコープと同じ丁寧さで書く
担当者を肩書きや部署でしか指定しない	意思決定が先送りされる	個人の名前を書く
成功指標がない	本稼働は祝われるが、価値は示されない	キックオフの前にKPIを定義する
並行プログラムを整理していない	リソースと予算の衝突	両方の憲章に依存関係を記録する
導入パートナーが憲章を書く	スコープが、パートナーの納品したいものを反映する	クライアントが所有し、パートナーは詳細を補う

最後の点については、私は譲りません。導入パートナーに憲章を書かせてはいけません。パートナーの動機は、プロジェクトを始めることです。御社の動機は、スコープを定めることです。

RISE with SAP（Private Edition）の場合、ガバナンスの項目に2つを加えます。1つ目は、クリーンコアの承認フォーラムです。SAPは現在、拡張をレベルA（リリース済みAPIのみ）からレベルD（修正）までに分類しています（SAP News、2025年8月）。Private Editionでは今もコアを修正できるため、技術的負債が積み上がるのを止めるのがこのフォーラムです。2つ目は、SAPへのエスカレーション経路です。RISEでは、SAPがインフラと技術運用を担います。プラットフォームレベルで障害が起きたとき、パートナーだけでなくSAPの誰に連絡すればよいかを、CIOは把握しておく必要があります。

GROW with SAP（Public Edition）の場合、憲章は小さくなります。拡張はリリース済みのインターフェースに限られるため、クリーンコアはプラットフォームが代わりに強制してくれますし、連携の選択肢も狭くなります。ビジョン、成功指標、担当者の氏名、除外事項は、どちらの場合も同じように重要です。

AIツールを使えば、インタビューのメモを初稿にまとめる作業は速くなります。しかし、憲章の政治的な仕事、つまり、スポンサーに自分が何を担うのかを合意させる仕事は、AIにはできません。

SAP導入におけるプロジェクト憲章とは何ですか？

SAPプログラムを正式に承認する文書です。スコープと除外事項を定め、スポンサーと責任者を指名し、成功指標を定義し、マイルストーンとガバナンスを設定し、主要なリスクを一覧にします。役に立つ憲章は、スコープやオーナーシップをめぐる意見の相違に決着をつけられるだけの具体性を備えています。

SAPプロジェクト憲章には何を含めるべきですか？

目的と測定可能な目標値、スコープ、明示的な除外事項、導入形態と拡張ルール、個人の名前入りのガバナンス、役割、ゲート基準付きのマイルストーン、予算とコンティンジェンシー、リスクと依存関係、コンプライアンス要件、承認です。各項目は上の構成例で示しています。

プロジェクト憲章とプロジェクト計画書の違いは何ですか？

憲章は承認し、定義します。スコープ、スポンサー、ガバナンス、大まかなマイルストーンです。計画書は実行します。タスク、依存関係、リソース、順序です。憲章のない計画書は、スコープに合意がないため漂流します。計画書のすべての約束は、憲章にたどれるようにしてください。

SAPプロジェクト憲章は誰が書くべきですか？

クライアント側のスポンサーが所有し、プログラムマネージャーが起案します。詳細は、財務、IT、業務の各リードが提供します。導入パートナーに書かせることはお勧めしません。パートナーの動機はプロジェクトを始めることであって、御社を不要なスコープから守ることではないからです。

RISE with SAPでプロジェクト憲章はどう変わりますか？

どの拡張を、どのレベルまで認めるかを決める、クリーンコアの承認フォーラムを加えます。プラットフォームの問題に備えて、SAPへのエスカレーション経路も加えます。RISEではSAPがインフラを運用するからです。GROW with SAPでは、Public Editionが技術的にクリーンコアを強制するため、憲章は軽くなります。

導入の途中でプロジェクト憲章を変更できますか？

できます。変更管理を通じて行います。憲章はベースラインとして扱ってください。スコープ、スポンサー、予算、主要なマイルストーンが変わったら、バージョン番号、何がなぜ変わったかの記録、新たな承認を付けて更新します。プロジェクトが逸脱するたびに、憲章をこっそり改訂してはいけません。