SAPプロジェクトのステアリングコミッティを効果的に作る

SAPプロジェクトのステアリングコミッティとは、プロジェクトチームには下せない判断を下す、少人数の経営幹部のグループです。予算、スコープ変更、部門間の対立、そして最終的なGo/No-Goの判断が対象です。委員会が機能するのは、メンバーが実権を持ち、会議の場で決められるだけの頻度で集まり、カレンダーではなく証拠に基づいて準備状況を判断するときです。このガイドは、委員会を立ち上げるスポンサーとプログラムディレクター、あるいは状況報告の聴衆になってしまった委員会を立て直そうとする方に向けたものです。委員会が決めるべきこと、プロジェクト規模別の構成メンバー、意思決定の進め方、Go/No-Goチェックリスト、そしてRISE with SAPとAIツールによる変化を取り上げます。

私は、ステアリングコミッティが弱いままで成功したSAPプロジェクトを見たことがありません。難しい判断が下される場は、委員会です。その場でリアルタイムに下されるか、溜まりに溜まってカットオーバーで爆発するかのどちらかです。

あるSAPのロールアウトでは、委員会は月に1回しか開かれませんでした。プロジェクトチームは、承認ワークフローの不具合、未完了のテスト、不足しているトレーニングを指摘しました。経営陣は「確認します」と言いました。確認されることはありませんでした。プロジェクトは本稼働しましたが、財務部門は、その後6か月を後始末に費やしました。

別の会社では、委員会が毎週開かれ、実際に決断を下していました。テストで抜けが見つかると、リソースを再配分しました。プロセスがうまく機能していなければ、直しました。そのプロジェクトは、スムーズに本稼働しました。

一方の委員会は、率いていました。もう一方は、会議に座っていただけです。

委員会が状況報告を受け取るだけなら、すでに失敗しています。実務での違いを表にまとめました。

機能	良い状態	弱い状態
重要な判断	状況を確認し、その場で決める	「あとで個別に話しましょう」。課題は翌月に戻ってくる
障害の除去	人事部門がテストを遅らせていれば、議長が部門長に直接電話する	問題を認めて、記録するだけ
スコープ	すべての変更要求を、計画に照らして評価する	最も強く上がってきたものを、そのまま承認する
リスク	ベンダーが苦戦しているのを見て、遅れが出る前にバックアップを手配する	自然に解決するかどうか様子を見る
予算	混乱のほうがコストが大きいため、3か月延長するための追加200万ドルを承認する	翌月に先送りする
Go/No-Go	テストが完了していないため、本稼働を6週間遅らせ、その姿勢を貫く	日付がカレンダーに入っているからと、本稼働を承認する

最後の行が最も重要です。チームが突き進もうとしていても、委員会が本稼働を延期させたところを、私は見てきました。ある製薬業のクライアントでは、テストが完了していなかったため、委員会が本稼働を6週間延期しました。厳しい判断でしたが、大惨事を免れました。

メンバーが多すぎると、委員会は決められません。少なすぎると、重要な声が欠けます。

プロジェクト規模	予算とスコープ	メンバー数	同席すべき人
小規模	50万ドル未満、1部門、6か月未満	3〜5人	部門長、IT責任者、財務の代表
中堅企業	50万〜500万ドル、複数部門、6〜18か月	5〜8人	影響を受ける部門の事業責任者、ITのリーダー、財務
大企業	500万ドル超、全社規模、18か月以上	8〜12人	財務、人事、オペレーション、ITのCレベル。プログラムマネージャー。チェンジリード

私が適用するルールは、本当の決定権を持つ人を入れることです。上級の肩書きがあっても、誰かに確認しなければ何も承認できないために、委員会が失敗するのを見てきました。CFOが出席できない場合は、報告を持ち帰るためではなく、決めるための本物の権限を持つ人を送ってください。

議長は、プロジェクトスポンサーが務めるべきです。通常は、ほかの経営幹部に責任を問えるCレベルの役員です。中間管理職が議長を務めても、CFOの意見を覆すことはできません。スコープや予算の対立が表面化したとき、その権限が物を言います。

証拠に基づいて。 製造業のクライアントで、IT部門が、あるプロセス変更で3か月の追加がかかると言ったことがあります。事業部門は「簡単だ」と主張しました。委員会は、工数見積もり、依存関係の分析、キャパシティ計画を見るまで、決定を拒否しました。正しかったのはITでした。委員会が正しい判断を下せたのは、声の大きい側につくのではなく、証拠を求めたからです。

速く。 2週間ごとに開かれながら、毎回「これはあとで個別に話しましょう」で終わる委員会のクライアントがありました。課題は積み上がり、プロジェクトは6か月遅れました。別のクライアントの委員会は、その場で決断を下し、プロジェクトは予定より早く、予算内で終わりました。遅い委員会は、遅れるプロジェクトを生みます。

明確な権限をもって。 効果的な委員会は、部門長の決定を覆し、計画外の予算を承認し、進行中のスコープ追加を却下できます。これらの権限が文書化され、共有されていなければ、委員会は助言機関になります。そして、助言機関はSAPプロジェクトを完遂させません。

スコープについては、選択的に。 私のクライアントの一社で、ある部門が突然、20本のレポートの追加を求めてきました。委員会は、それぞれが今必要か、タイムラインを壊さないかを問いました。そして、重要な5本を承認し、残りは本稼働後に回しました。この決断が、本稼働の日程を救ったのだと思います。

会議は60〜90分に収めます。 上位のリスク、必要な個別の決定事項、担当者と期限を明記したアクション。事前に読めるはずの技術的な報告は入れません。同じ課題が3回連続の会議で解決されないまま現れるなら、問題は複雑さではなく、ガバナンスにあります。

資料ではなく、データを使います。 私が関わったあるエネルギー業界のクライアントは、テストの実行状況、不具合の解決、トレーニングの完了、予算の消化を示すダッシュボードを構築しました。会議は、現状を把握するためのものではなく、問題を解決するためのものに変わりました。

委員会にシステムを見せます。 ある製薬業のクライアントの委員会は、「ある一日」のシナリオを通しで確認しました。そこで、承認済みの設計では、よくあるプロセスのために担当者が5つもの別々の画面を使うことになると気づきました。委員会は、すぐに再設計を命じました。

政治を見込んで計画します。 最も多い失敗は、無能ではありません。部門が縄張りを守ること、そして年度末の業務を理由にチームがテストを遅らせることです。あるプロジェクトでは、人事部門が年度末の作業で忙しいと、給与のテストを遅らせ続けました。委員会は作業の優先順位を見直し、予備のテスト担当者を割り当てたため、プロジェクトは何か月も遅れることなく、予定どおりに進みました。

主要なゲートでは、独立した確認を使います。 ある製造業のクライアントは、本稼働を承認する前に、外部のレビュー担当者に準備状況を評価させました。レビューでは、プロジェクトチームが見落としていた、あるいは軽く見ていた深刻な問題がいくつも見つかりました。SAP品質ゲートのガイドで、そうしたチェックポイントの組み立て方を紹介しています。

カレンダーの圧力は、本稼働を承認する根拠として誤りです。採決の前に、委員会は次の各項目について証拠を確認すべきです。

1. 結合テストとユーザー受け入れテストが完了し、未解決のクリティカルな不具合がない
2. 最終のモックデータ移行が照合され、財務部門が署名している
3. カットオーバーのリハーサルが、計画した時間枠の中で完了している
4. キーユーザーのトレーニングが完了し、現場サポートとジョブエイドが整っている
5. 各プロセスオーナーが、事業の準備状況を書面で確認している
6. ロールバック計画がテストされ、合意されている
7. ハイパーケアのチーム、エスカレーション経路、初回決算のサポートが整っている

項目のどれか一つでも赤なら、強い委員会はノーと言います。6週間の遅れは取り戻せます。業務や財務決算を混乱させる本稼働の失敗は、安定化に何か月もかかりかねません。日付が動かせないように感じられたというだけで承認された本稼働の後始末を、私はあまりに多く手がけてきました。委員会のアジェンダは、ライブのリスクレジスタから作成すれば、これらの項目が早い段階で浮かび上がります。

RISEは、SAPをガバナンスモデルに組み込みます。 RISE with SAPでは、SAPがインフラと技術運用を担います。SAPのRISEの役割と責任に関する文書では、お客様はSAP Cloud Architect Advisor、Client Delivery Manager、またはSAPのプライベートクラウド・カスタマーセンターと連携することになっています。パフォーマンス、可用性、サービスレベルといったプラットフォームの問題については、委員会に、導入パートナーを経由しない、これらの担当者への経路が必要です。常任メンバーとしてではなく、該当するアジェンダ項目のときに招いてください。

Clean Coreのフォーラムは、委員会の下に置きます。 RISEのプログラムでは、Clean Coreの原則に照らしてカスタマイズ要求を承認または却下する、デザインオーソリティを設けてください。委員会にエスカレーションするのは、事業上クリティカルな要求がブロックされた場合だけです。この層がなければ、あらゆるカスタマイズが委員会での争いになります。オンプレミスでは、従来のモデルがそのまま当てはまり、SAPは参加者ではなくベンダーです。

1. ステアリングコミッティスポンサーが議長を務める。予算、スコープ、対立、Go/No-Go
   SAPのデリバリー担当者プラットフォームの案件で招く。パートナー経由にはしない

• プログラム管理オフィス（PMO）日々の実行、リスクログ、調整
• Clean Coreデザインオーソリティカスタマイズの可否を判断し、ブロックされたクリティカルな要求のみエスカレーション

AIは、事務作業の時間を節約します。 Microsoft 365 Copilotは、録画した会議から議事録のドラフトを作成します。作業はゼロから書くことではなく、ドラフトを確認することになり、決定事項は文字起こしから拾えます。AtlassianのRovoは、テンプレートを構築しておけば、会議メモを構造化された決定ログのエントリに変換できます。SAP Cloud ALMのJouleベースのアシスタントは、スコープ要求に対する最初の影響評価のドラフトを作成できるため、委員会は先送りせず、会議の場で決められます。

センチメント分析は、当面見送ります。 一部のベンダーは、プログラムのコミュニケーションに対するセンチメント分析を、委員会への入力として売り込みます。たいていのプログラムでは、それは見せかけです。シグナルは弱く、誤検知が多く、センチメントを監視していると見られること自体に、政治的なコストがあります。非常に大規模なプログラムでのみ、関与が薄れているグループを早期に見つけられる可能性があります。ほとんどの委員会にとって、AI予算を使うべき場所ではありません。

SAPプロジェクトにおけるステアリングコミッティの役割は何ですか？

プロジェクトチームには下せない判断を下すことです。予算の承認、スコープ変更、リソースのエスカレーション、そして最終的なGo/No-Goです。部門間の対立を解決し、部門長にテストとトレーニングの約束を守らせます。状況報告を受け取るだけなら、役目を果たしていません。価値は、出席した会議の数ではなく、下した決定にあります。

SAPのステアリングコミッティには、何人入れるべきですか？

単一部門の小規模プロジェクトなら3〜5人、中堅企業なら5〜8人、大企業のプログラムなら8〜12人です。よくある失敗は、人数が多すぎることです。20人の委員会は、プレゼンテーションの聴衆になります。メンバーは全員、何かについて本当の決定権を持っているべきです。RISEでは、SAPのデリバリー担当者は常任メンバーとしてではなく、プラットフォームの案件のときに招きます。

RISE with SAPは、ステアリングコミッティをどう変えますか？

SAPは、インフラと技術運用の担い手として、デリバリーの参加者になります。そのため委員会には、導入パートナーを経由しない、SAPの担当者への直接の経路が必要です。また、その下にカスタマイズ要求を扱うClean Coreのデザインオーソリティも必要で、事業上クリティカルな要求がブロックされた場合のみ、エスカレーションします。オンプレミスでは、SAPは引き続きベンダーです。

ステアリングコミッティとPMOの違いは何ですか？

プロジェクト管理オフィス（PMO）は、タスク、リスクログ、ワークストリーム間の調整といった、日々の実行を担います。ステアリングコミッティは、PMOには下せない判断を下します。予算の変更、スコープの変更、Go/No-Goです。大きな組織では、複数のプロジェクトの上にポートフォリオ・レベルの委員会があり、プロジェクト間でリソースを配分します。

ステアリングコミッティのアジェンダには何を載せるべきですか？

報告ではなく、決定事項です。まず上位3〜5件のリスク、次に承認が必要な個別の決定、次に解決すべき部門間の課題、最後に前回会議のアクションを担当者と期限つきで取り上げます。同じ項目が解決されないまま3回現れたら、もう一度議論するのではなく、その扱い方自体をエスカレーションします。

ステアリングコミッティは、いつ本稼働を延期すべきですか？

テストが完了していない、キーユーザーのトレーニングが済んでいない、データ移行が照合されていない、クリティカルな連携が不安定、ロールバック計画がテストされていない、といった場合です。延期のほうが、本稼働後の後始末よりほぼ必ず安く済みます。6週間の遅れは取り戻せますが、サプライチェーンや財務決算を混乱させる本稼働の失敗は、安定化に何か月もかかりかねません。