SAPステークホルダー管理：対立が起きる前に防ぐ

SAPのステークホルダー管理は、プログラムが予定どおりに終わるか、最後の四半期を議論に費やすかを分けます。要点は四つの習慣です。誰が重要で、各グループが何を気にしているかを整理する。誰が何を決める権限を持つかを書き出す。SAP Activateのフェーズに合ったコミュニケーションのリズムを回す。重要な意思決定は、代替案とともにすべて記録する。本ガイドは、S/4HANAプログラムに携わるプログラムディレクター、PMO、エグゼクティブスポンサーに向けたものです。最初のワークショップの前に、以下の役割の表とフェーズ別のリズムを使って、エンゲージメント計画を組み立ててください。

以前、ITは厳格なシステム統制を求め、財務はより柔軟性を必要としていたSAP導入に関わったことがあります。私たちが入った時点で、両チームは口をきかなくなっていました。財務は苛立ち、ITは守りに入り、経営陣は、なぜ誰もコミュニケーションを取っていないのかを知りたがっていました。

私たちは役割マップを作り、定期的な調整会議を開き、意思決定の唯一の情報源を整えました。その土台を最初から築いていれば、何か月もの言い争いを避けられたはずです。

このパターンは、そのプログラムに限りません。技術が単独で失敗することはまれです。意思決定がなされず、期待が設定されなかったときに、プログラムは失敗します。コミュニケーションがリズムではなく個人的な関係に頼っているとき、そして現場レベルで扱うべき対立が数週間遅れて経営陣に届くときにも、失敗します。

SAPプログラムの全員が、同じ関心事や同じ影響力を持っているわけではありません。全員を一つの聞き手として扱うと、無関係な報告を送ることになり、本当のリスクを見逃します。

役割	関心事	関わり方
エグゼクティブスポンサー（CEO、COO、グループCFO）	リターン、事業リスク、プログラムの信頼性	直接、定期的に、短く
ステアリングコミッティ（CIO、CFO、事業部門長）	スケジュール、予算、スコープ	意思決定を伴う、構造化されたステアリングレビュー
財務リーダー（CFO、コントローラー）	収益認識、報告の完全性、統制	設計への早期の関与。FI/COのスコープを承認
業務部門・オペレーションのリーダー	業務の継続性、研修、使いやすさ	設計ワークショップ。ユーザー受入テスト（UAT）のオーナーシップ
IT部門のリーダー（CIO、アーキテクチャ責任者）	アーキテクチャ、セキュリティ、連携、サポート	技術設計の承認
業務プロセスオーナー	プロセスの正確さ、例外、エッジケース	設計ワークショップを主導。コンフィグレーションを承認
エンドユーザー	習得の負担、日々の業務、仕事の変化	研修とチェンジマネジメント
システムインテグレーター（SI）	導入スコープ、変更要求、人員配置	正式なガバナンスとスコープ文書
HRとチェンジマネジメント	人への影響、役割の変更、コミュニケーション	導入と並行するワークストリーム

パワー・関心度マトリクスは、どこに労力をかけるべきかを教えてくれます。CIO、CFO、スポンサーは、どちらの軸でも高い位置にいます。変更を承認し、本稼働を延期させ、人員を割り当てる立場にあり、彼らが関与しなくなれば、プログラムは後ろ盾を失います。プロセスオーナー、コントローラー、アーキテクトは、関心が高く、公式な権限は小さいものの、事業が実際にどう動いているかについての知識があるため、設計に欠かせません。取締役やプログラム外の経営幹部には、毎週の報告ではなく、マイルストーンごとの説明が必要です。エンドユーザーは影響力が小さく、影響の度合いが最も大きい存在です。本稼働時に彼らが納得しているかどうかが、システムが現場で機能するかを決めます。

成果への影響力高中低

• 取締役会、プログラム外の経営幹部

• スポンサー、CFO、CIO

• プロセスオーナー
• コントローラー、アーキテクト

• エンドユーザー

低中高プログラムから受ける影響の大きさ

最も効果的な関与は、誰かが不満を口にする前に行うものです。キックオフで三つを固めます。

意思決定権限

スコープ変更を承認できるのは誰か。UATを承認するのは誰か。本稼働の遅れをステアリングコミッティに上げられるのは誰か。それを書き出し、署名をもらい、プロジェクト憲章に入れます。プロジェクトの途中で意思決定が争われたとき、指し示すのはその文書です。

それがなければ、争いのある意思決定は、声が最も大きい人か、スポンサーの耳に入る人のところへ流れます。どちらもガバナンスではなく、どちらも不満を生みます。意思決定権限のセクションに何を入れるべきかについては、SAPプロジェクト憲章の書き方のガイドで扱っています。

コミュニケーションのリズム

プログラムがどのくらいの頻度で、どのチャネルで、どんな内容を伝えるかを、キックオフの時点で決めます。ステアリングは2週間ごと。ワークストリームのリーダーとは毎週。エンドユーザーにはマイルストーンごとに、研修の案内を添えて。プログラムからの連絡が何か問題があるときだけだと、人々は常にトラブルの中にあると思い込みます。

スコープのベースライン

何がスコープ内で、何が明示的にスコープ外かを書き出します。除外事項は、含める事項と同じくらい重要です。定義されていない境界はすべて、将来の対立になるからです。経費管理がスコープに入っていると思い込んでいた財務リーダーが、Realizeの段階で入っていないと知る場合を考えてみてください。その人は、プログラムの残りの期間、扱いにくい存在になります。本人が生来扱いにくいからではなく、プログラムが暗黙の約束を破ったからです。

プログラムがSAP Activateのフェーズを進むにつれて、関与の必要性は変わります。Exploreで効果のあるやり方は、Deployでは通用しません。これをエンゲージメント計画の骨格として使ってください。

フェーズ	関与の焦点	リズム	主導する人
Discover and Prepare	役割マップ、ガバナンス体制、スポンサーへの説明、財務・オペレーション・ITとの最初の調整セッション	開始時にスポンサーへの説明。ステアリングを立ち上げる	プログラムディレクター
Explore	業務リーダーとプロセスオーナーとのFit-to-Standardワークショップ。承認前にフィットギャップの意思決定をレビュー	毎週の作業セッション。フェーズ終了時にステアリング	ソリューションアーキテクトとプロセスオーナー
Realize	UATの準備。テストのために業務リーダーの時間を確保する。不具合とデータ移行の状況	ステアリングは隔週。ワークストリームのリーダーとは毎週	プログラムマネージャー
Deploy	カットオーバーの準備状況。カットオーバー開始前に合意するGo/No-Go基準	毎日のカットオーバー・スタンドアップ。経営層向けのGo/No-Goブリーフ	業務オペレーション責任者（ITとSIが支援）
Run	ハイパーケアのコミュニケーション、問題の連絡チャネル、安定化レビュー	2週間は毎日、その後は毎週。30日、60日、90日の時点でレビュー	サポートリードとプロセスオーナー

トラブルの大半を生むのは二つのフェーズです。Exploreでは、場にいるべき人が間違っていると、コンフィグレーションが始まった後のRealizeで意思決定が蒸し返されます。Realizeでは、UATのオーナーが不在、あるいは準備不足という状況がよくあります。テスト開始の2週間前ではなく、Exploreの間に計画で手当てしてください。

従来のモデルは、クライアント、SI、スポンサーの3者でした。RISE with SAPでは、SAPが納品の関係者として加わります。インフラと技術運用を担い、カスタマーサクセスチームが定着と価値の実現を追跡します。これに伴い、ガバナンスは三つ変わります。

1. 拡張レビューフォーラム。 すべてのギャップに決定が必要です。コンフィグレーションで対応するか、公開済みのAPIで拡張するか（ABAP Cloudによるオンスタック、またはSAP BTP上のサイドバイサイド）、却下するかです。S/4HANA Cloud Public Editionでは、コアの改修はできません。Private Editionでは可能ですが、改修のたびにアップグレード作業が増えます。ステアリングの下に、決定権限を持つアーキテクトを一人置いた小さなフォーラムを設けると、あらゆるカスタマイズの議論がステアリングに持ち込まれるのを防げます。これを省くと、最初のメジャーアップグレードで技術的負債が表面化します。
2. SAPとのカスタマーサクセスのリズム。 SAPのチームは、定着、BTPの利用、ロードマップについて関与します。導入のガバナンスと並行して進み、本稼働後も続きます。別立てで運営するのではなく、自社のガバナンスに組み込みます。
3. SAPへのエスカレーション経路。 プラットフォームのレベルで何かが失敗したとき、CIOはパートナーだけでなく、SAPの誰に連絡すればよいかを知っている必要があります。署名する前に、連絡先とサービスレベルを確認します。

Public EditionでのGROW with SAPプログラムにも、同じ三つが必要ですが、軽めで足ります。拡張の余地が小さいので拡張の意思決定は少なく、サクセスのリズムはより標準化され、エスカレーションは通常まずパートナーを通ります。オンプレミスのプログラムは従来のモデルのままで、SAPは関係者ではなくベンダーです。

AIツールが役に立つのは、関与に伴う事務作業であって、人間関係ではありません。

会議の要約が、最も分かりやすい成果です。 Microsoft Copilotは、録画されたステアリング会議を議事録の下書きにしてくれるので、長い文書作成の代わりに短い確認で済みます。捉える意思決定は、たいてい正確です。記憶ではなく文字起こしから作るからです。

意思決定ログが次です。 ConfluenceのAI機能は、現在はAtlassianのRovoブランドの下にあり、テンプレートを作っておけば、会議メモを構造化された意思決定ログのエントリに変換できます。

要件の起案は、Exploreで役に立ちます。 SAP Cloud ALMは、Fit-to-Standardワークショップの文字起こしから要件を起案できます。それでも、すべての行を人が検証する必要があります。

センチメント分析は、ほとんどが見せかけです。 100人に満たないプログラムでは、シグナルが弱く、誤検知も多く、センチメントを監視していると見られること自体に、政治的に無視できないコストがあります。非常に大規模なプログラムでは、関与が薄れているグループを早期に見つけられるかもしれません。大半のプログラムでは、AIの予算はほかに使うべきです。

SAPへの抵抗には、ほとんどの場合、合理的な理由があります。反対している人は、たいてい何かを守ろうとしています。旧システムのギャップを埋めている回避策、標準プロセスでは見えない手作業のチェック、あるいは変化を吸収できるチームの余力への心配です。反応する前に、その理由を見つけます。根本の懸念に対処すれば、対立しなくても抵抗は収まるのが普通です。

「このカスタマイズが必要だ」

たいていは、現在うまく動いているプロセスを守ろうとしており、標準のSAPがそれを扱えると信頼していない場合です。標準プロセスを一緒に確認し、どこで具体的に破綻するのかを尋ねます。懸念がコンフィグレーションで対応できるエッジケースだったということもよくあります。正当なものであることもあります。それは、対話してみなければ分かりません。クリーンコアの方針の下では、答えによって拡張を構築して保守するかどうかが決まるため、賭け金はいっそう高くなります。

「本稼働の準備ができていない」

これは真剣に受け止めます。業務リーダーが準備できていないと言うとき、たいていは理由があります。データ品質、不十分な研修、テストされていないプロセスなどです。具体的な懸念を探ります。それが妥当なら、本稼働を延期すべきです。証拠ではなく不安によるものなら、新しい日程ではなく、焦点を絞った準備で応えます。

最もよくあるのは、UATで見つかった問題が修正されていないケースです。そのまま進めれば、問題はUATから本番環境へ移るだけです。2週間の延期のほうが、本稼働前から分かっていた問題に費やすハイパーケア期間よりも、たいていはるかに安く済みます。

「この変更について誰も聞いていない」

これはコミュニケーションの失敗です。その人は配布リストには入っていても、設計セッションには入っていなかった、あるいは変更が、その人が読むことのなかった文書の中にありました。誰が何を伝えたかを議論してはいけません。謝罪し、変更を一緒に確認し、その人の担当領域の今後の設計レビューに加え、エンゲージメント計画の穴をふさぎます。

対立が現場レベルを超えて大きくなったときに重要なことが三つあります。

ガバナンスの内側で扱う。 システムのアクセス権をめぐる財務とITの争いは、粘り強いほうが非公式に決着をつけるのではなく、ステアリングで扱うべきものです。構造的な対立を非公式に解決すると、不満が残り、意思決定が蒸し返されます。

ビジネスの言葉で捉え直す。 財務とITがアクセス制御をめぐって言い合うのは、政治です。財務とITが、セキュリティリスクと運用コストを並べて示すなら、それは経営判断であり、ステアリングが決められます。一方を他方に翻訳するのは、プログラムマネージャーの、契約によってはSIのリーダーの仕事です。

重要な意思決定はすべて記録する。 何が決まったか、誰が決めたか、いつか、どんな代替案が検討されたか。半年後には、誰かが「そんなことには合意していない」と言い出します。ステアリングがなぜそのコンフィグレーションを選んだのかを尋ねたとき、あるいは新しく加わった人が過去の判断に疑問を呈したときに、必要なのは記憶からの再構成ではなく、記録です。毎週更新し、ステアリングでレビューする共有の意思決定ログは、ほとんどコストがかからず、多くを救ってくれます。

プログラムマネージャーの受信箱が緊急のエスカレーションで埋まっているなら、計画は機能していません。健全なプログラムは、毎日の火消しではなく、構造化された意思決定で動きます。

健全なサイン： ステアリング会議が先送りではなく意思決定を生む。業務リーダーが、追いかけなくてもワークショップとUATに出席する。スコープ変更が変更プロセスを通じて届く。本稼働後の問題が、定められたチャネルから上がってくる。意思決定ログが最新で、ステアリングで参照されている。

警戒サイン： ガバナンス体制の外から、プログラムマネージャーに直接連絡が来る。業務リーダーが成果物を読まずに承認し、後から異議を唱える。ステアリングの合間にスポンサーが姿を消す。設計を欠席した人が、変更凍結に異議を唱える。同じ対立が、3回連続のステアリング会議に現れる。

警戒サインが出たときは、既存の計画をさらに強く押し通そうとしないでください。どの要素が機能していないのか（リズム、権限、コミュニケーション、文書化）を見極め、その一つを直します。メールと会議を増やすと、かえって悪化します。ステアリングコミッティそのものについては、効果的なSAPステアリングコミッティの作り方のガイドを、本稼働に伴う人の側面については、SAPチェンジマネジメントに関する私のメモをご覧ください。

SAP導入におけるステークホルダー管理とは何ですか？

プログラムに影響力や関心を持つのは誰かを特定し、その懸念を理解し、コミュニケーションと意思決定の仕組みを整え、キックオフからハイパーケアまで関与を保ち続ける、体系的な取り組みです。

SAPは、財務、HR、調達、オペレーション、ITに同時に及び、それぞれ優先順位も影響力も異なります。全員を一つの聞き手として扱うと、画一的な報告になり、抵抗の原因となる懸念を見落とします。SAP Activateは、これを各フェーズに組み込んでいます。Exploreのワークショップ、RealizeのUATのオーナーシップ、Deployの準備状況レビューはいずれも、準備のできた業務側の参加者に依存しています。

SAPプロジェクトの役割マップはどう作りますか？

個人またはグループを、成果への影響力と、プログラムから受ける影響の大きさという二つの軸にプロットします。スポンサー、CFO、CIOはどちらも高く、直接かつ定期的な接触が必要です。コントローラー、プロセスオーナー、アーキテクトは関心が高く、設計に加わる必要があります。プログラム外の経営幹部には、マイルストーンごとの説明が必要です。エンドユーザーには、自分たちに何が変わるのか、研修はいつか、どこでサポートを受けられるかについて、的を絞った連絡が必要です。

マップは最新に保ちます。人は役割を変え、プログラムが目に見えるようになるにつれて影響力は移り、スコープが広がると新しい参加者が加わります。

SAPのエンゲージメント計画には何を含めるべきですか？

役割台帳（名前、機能、影響力、関心、主な懸念）、コミュニケーション計画（グループごとのチャネル、頻度、内容）、スコープ変更・設計判断・本稼働の準備状況に関する意思決定権限、Activateの各フェーズの活動、争いのある意思決定のエスカレーション経路、そして懸念を正式に提起する手段です。

フェーズのゲートごとに更新します。プログラムマネージャーがすべてのやり取りを自ら処理しなくてもチームが運営できるよう、十分に文書化します。名前の挙がった参加者が30人を超えると、それではスケールしないからです。

業務リーダーのSAPへの抵抗にどう対処しますか？

まず原因を見つけます。よくあるのは、新しいプロセスが重要なエッジケースを取りこぼすのではないかという心配、生産性が下がることへの不安、意思決定から外されたという感覚です。プロセスの懸念は設計セッションで扱います。生産性への不安には、現実的な研修と、明確なハイパーケアの支援が必要です。疎外感はコミュニケーションの失敗であり、言い争うのではなく、直すものです。

合理的な根拠のない抵抗は、もっと厄介です。動かす手段になるのは、たいていスポンサーで、プログラムに経営陣のコミットメントがあることを明確にしてもらう必要があります。抵抗に対処せずに押し切るのは、最悪の選択です。懸念は、UATで再び現れます。

SAPプログラムでの財務とITの対立にどう対処しますか？

多くは三つの緊張関係のいずれかに行き着きます。アクセス権と職務分掌、レポートの柔軟性とデータガバナンス、連携のペースとセキュリティレビューです。

緊張関係を正確に言葉にします。「財務は、レポート用にコントローラーが製造オーダーへの参照アクセスを持つことを望み、ITはそれが職務分掌を損なうと考えている」なら解決できますが、「財務は柔軟性を望んでいる」では解決できません。選択肢とそのリスクを持って、ステアリングに上げます。そのうえで、意思決定と代替案を記録します。人が入れ替わると、この種の争いは再燃するからです。ステアリングで解決できなければ、スポンサーに上がります。それは、ガバナンスが設計どおりに機能している姿です。

RISE with SAPはステークホルダー管理をどう変えますか？

SAPは単なるベンダーではなく、関係者になります。クリーンコアの方針の下で各ギャップをどう扱うかを決める拡張レビューフォーラム、SAPのカスタマーサクセスのリズムを組み込むガバナンス上の場所、そしてパートナーに頼らない、プラットフォームの問題に関するSAPへの文書化されたエスカレーション経路が必要になります。署名する前に、エスカレーションの連絡先とサービスレベルを確認してください。