SAP導入チームに欠かせない役割と責任

SAP導入には、名前の挙がった専任の責任者を置いた、8つの役割が必要です。エグゼクティブスポンサー、プロジェクトマネージャー、ファンクショナルリード、ITリード、データ移行リード、チェンジマネジメントリード、導入パートナー、そして独立したプログラムアドバイザーです。RISE with SAPでは、これにSAP自身の提供担当者が加わり、クリーンコアの責任の所在も明確にする必要があります。このガイドは、チームを組む、あるいは立て直すスポンサーとプログラムディレクターに向けたものです。各役割が何を担うか、欠けると何が壊れるか、企業規模別のチーム人数、そして本稼働前にセンター・オブ・エクセレンス（CoE）を築く方法を扱います。まず、8つの役割のうち、本業を別に持つ人が兼ねているものがどれかを確認してください。それが最大のリスクです。

長年のあいだに、私は数十のSAPチームと仕事をしてきました。潤沢な予算と経験豊富なベンダーがありながら、重要な役割が欠けていたり、ほかの仕事を持つ人たちに分散していたりして、失敗するプロジェクトを見てきました。逆に、予算が乏しくても、適切な人が全力でその場に集まり、責任の所在が明確だったために、成功したプロジェクトも見てきました。

私が関わったあるグローバル小売企業には、予算があり、経営層の支援があり、選んだERPはSAPでした。ところが、導入チームは惨憺たるものでした。重要な役割が欠けていました。重要な意思決定を担う人がいませんでした。コミュニケーションはあらゆる方向に飛び交うだけで、どこにも着地しませんでした。期限は遅れ、コストは膨らみ、信頼は崩れました。

どのSAP導入でも、これらの役割を埋める必要があります。肩書きより、責任の所在のほうが重要です。

1. エグゼクティブスポンサー意思決定、予算、エスカレーション
   ERPプログラムアドバイザー独立した監督、リスク、経営層との整合
2. プロジェクトマネージャースケジュール、予算、調整

• ファンクショナルリードとSMEプロセス設計、モジュールの設定
• ITリードとチーム連携、開発、セキュリティ
• データ移行リードデータ品質、ロードの順序、カットオーバー
• チェンジマネジメントリードトレーニング、定着、コミュニケーション
• 導入パートナーアーキテクチャ、連携設計、デリバリー

役割	主な責任	欠けると何が壊れるか
エグゼクティブスポンサー	戦略上の意思決定、予算、エスカレーションの権限	迷走、スコープをめぐる争い、決着をつける人がいない
プロジェクトマネージャー	スケジュール、予算、チーム間の調整	遅延、解決されない障害、コストの超過
ファンクショナルリードとSME	業務プロセスの設計、モジュールの設定	誤った設定、本稼働後の回避策
ITリードとチーム	連携、開発、セキュリティ、パフォーマンス	技術的負債、壊れたインターフェース、不安定さ
データ移行リード	データ品質、ロードの順序、カットオーバーの正確さ	使えないデータ、本稼働の失敗、数か月に及ぶクレンジング
チェンジマネジメントリード	トレーニング、定着、コミュニケーション	ユーザーの抵抗、並行して使われるスプレッドシート
導入パートナー	アーキテクチャ、連携設計、デリバリー	作り込みすぎ、連携の失敗
ERPプログラムアドバイザー	独立した監督、リスク、経営層との整合	孤立した意思決定、避けられたはずの失敗

エグゼクティブスポンサー

スポンサーは、ステアリング資料に載っているだけの名前ではありません。ほかの誰にもできない判断を下す人です。予算、スコープの変更、部門をまたぐリソースの確約です。この役割が形だけになると、プロジェクトは迷走します。

この役割を飛ばした企業と、仕事をしたことがあります。プロジェクトは迷走しました。判断はなく、進捗もなく、お金は水の泡でした。

効果的なスポンサーは、ハイパーケアまで関わり続けます。本稼働後も月次のステアリングの場に出席し、何週間も止まっていたものを動かす小さな判断を下します。その場の組み立て方は、私のSAPステアリングコミッティの設置のガイドで扱っています。

プロジェクトマネージャー

PMは、日々の運営を担います。スケジュール、リスクログ、調整、報告です。大規模なSAPプログラムでは、経験のある人が専任で務める役割です。

ある顧客が、導入の途中でリード開発者を失うのを見たことがあります。代わりの人を探して奔走するあいだ、プロジェクト全体が数週間止まりました。

逆の問題も、同じくらい害になります。チームに30人を超える人員がいた企業と、仕事をしたことがあります。誰が意思決定を担うのか、誰も分かっていませんでした。簡単な変更に、5回の会議が必要でした。スケジュールは、コミュニケーションの負荷だけで、12か月から18か月に延びました。

ファンクショナルリードと分野の専門家（SME）

この人たちは、業務をSAPの設定に置き換えます。悪いプロセスに異を唱えられるだけ業務を理解し、何が可能かが分かるだけSAPを理解している必要があります。

ある製造業のクライアントでは、ファンクショナルリードがプロセスを設計する前に、工場の現場で時間を過ごしたため、チームが抜きんでた成果を出しました。

SMEが中途半端な関わり方をすると、必ず穴が空きます。プロジェクトが彼らの注意を得るのか、それとも承認欄に彼らの名前が載るだけなのか。この2つは同じではありません。

ITリードとチーム

ITチームは、技術的な土台を担います。開発、Basis、セキュリティ、連携、パフォーマンスです。S/4HANAでは、カスタムコードをコアに入れないというクリーンコアの規律も担います。

連携は、ほとんどのチームが過小評価するものです。外部システムとの接続は、すべて、設計し、構築し、テストし、責任者を決める必要があります。データフローを誰もマッピングしていなければ、インターフェースはUATで壊れます。ITは、決定の後ではなく、ブループリントのセッションに参加させてください。

データ移行リード

この役割は、任命が遅く、リソースも不足しがちです。データの問題が表面化するころには、プログラムはすでにスケジュールの圧力にさらされています。

あるクライアントは、データクレンジングを省けると考えました。大きな間違いでした。システムは、数か月間使い物になりませんでした。稼働中のシステムの上でデータを整えるほうが、最初にきちんとクレンジングするよりも、費用がかかります。

専任の移行リードは、ロードのたびに突合を行います。構造的な問題が本稼働の前に見つかるのは、そのおかげです。ほかに3つのワークストリームを抱える人がこの役割を兼ねていると、そうはなりません。その進め方は、私のSAPデータ移行が失敗する理由の記事で扱っています。

チェンジマネジメントリード

最も一貫してリソースが不足している役割です。誰も働き方を変えたがらず、100万ドル規模のシステムが使われないまま放置されるのを、見てきました。

技術的には完璧だった導入が、ユーザーに嫌われて失敗するのを見たことがあります。設定は正しく、プロセス設計も健全でした。しかし、毎日それを使う人たちが、設計に関わっていませんでした。なぜ変わったのかを理解できず、古いExcelファイルを使い続けたのです。

ある小売のクライアントは、新システムに対するレジ担当者の懸念に耳を傾け、進め方を調整したことで、成功しました。

エンタープライズ規模のプログラムでは、最低でも専任のチェンジマネジメント担当が2人は必要です。1人では、トレーニング設計、コミュニケーション、抵抗への対応、定着の追跡を同時にカバーできません。

ERPプログラムアドバイザー

独立したアドバイザーは、導入パートナーではありません。仕事は、監督と軌道修正です。方向性がいまも筋が通っているかを確かめ、デリバリーチームが近すぎて見えないリスクを見つけ、経営層が起きていると考えていることと実際に起きていることとの差を埋めます。

私は、デリバリーチームは強いものの、独立した声を持たないクライアントのために、この役割を務めてきました。ある製造業のクライアントは、成長戦略とSAPのロードマップを誰も結びつけていなかったため、もう少しで誤ったモジュールを導入するところでした。

問題を早期に見つけるのは、もう半分の仕事です。あるとき、クライアントのデータチームに重大なスキルギャップがあることを、それが本稼働を遅らせることになる3か月前に見つけました。危機になる前に、解消できました。

8つの役割のモデルは、いまも通用します。2026年には、そこに組み込むべきことが3つあります。

RISEにおけるSAP自身の提供担当者

RISE with SAPのプライベートクラウドでは、SAPがインフラと技術運用を担います。SAPの役割と責任に関する文書では、顧客は、SAP Cloud Architect Advisor、Client Delivery Manager、またはSAPのプライベートクラウドのカスタマーセンターチームとサービスを取り決めることになっています。SAPが割り当てた担当者を、パートナーチームの隣の体制表に載せ、自社側でその関係を担う人を指名してください。オンプレミスでは、SAPはソフトウェアベンダーであり、これは当てはまりません。

クリーンコアと拡張の責任

S/4HANA Cloud Public Editionでは、クリーンコアは設計によって強制されます。拡張は、リリース済みAPI、キーユーザー向けツール、またはSAP BTPを通じて行います。プライベートクラウドとオンプレミスでは、修正はまだ可能ですが、ひとつ加えるたびにアップグレードが難しくなります。その線引きを担う人が必要です。

大規模なプログラムでは、ソリューションアーキテクトに報告する、専任のクリーンコアアーキテクトまたはBTP拡張リードがこれを担います。中堅規模のプログラムでは、通常はソリューションアーキテクトが兼ねますが、責任の所在は文書に書き出す必要があります。パートナーを評価するときは、BTPの拡張をいくつ納品してきたかを尋ね、事例を見せてもらってください。

AIが変えるのは生産性であり、責任ではない

SAP Joule for Consultants（2025年から一般提供）は、SAP自身のナレッジベースから設定に関する質問に答え、ABAPコードを説明します。SAP Build Codeは、SAP BTP上でJavaやJavaScriptの拡張コードを生成します。Microsoft Copilotは、ステアリングコミッティ向けの資料やステータスレポートの下書きを作ります。

効果が出るのは、要件分析、ステータスレポート、カスタム開発など、ワークフローの多い役割で、しかも、人がそのツールを一貫して使った場合に限られます。提示された生産性の数字は、自分のプログラムで検証すべき主張として扱ってください。

同じスコープに必要だったチームの規模は、これらのツールが登場する前よりやや小さくなりますが、劇的にではありません。ツールは、片手間の活動として扱うのではなく、役割の定義に書き込んでください。AIは下書きを速く作ります。下書きの内容に責任を持つのは、いまも人間です。

表には、企業規模ごとの、各役割の一般的な人数を示しています。出発点として扱い、スコープと地域に合わせて調整してください。SAP以外で同じ問いを考えるには、私のERP導入チームのガイドをご覧ください。

役割	小規模企業	中堅企業	大企業
エグゼクティブスポンサー	上級ディレクター	CIOまたはCFO	ステアリングコミッティを伴う経営幹部（C-suite）
プロジェクトマネージャー	専任1人	専任1〜2人	プログラムマネージャーとワークストリームPM
ファンクショナルリード	モジュールごとに1〜2人	モジュールごとに専任	モジュールごとに複数
ITチーム	2〜3人（兼務）	4〜6人（専任）	8人以上の専門家
データ移行	リード1人	リード1人とアナリスト	専任のワークストリーム
チェンジマネジメント	最低1人	最低2人	専任3〜5人
クリーンコアまたはBTP拡張リード	ソリューションアーキテクト	ソリューションアーキテクト	専任の役割
SAPの窓口（RISE）	担当者を指名	担当者を指名	担当者を指名し、四半期ごとにレビュー
導入パートナー	コンサルタント5〜10人	コンサルタント15〜25人	30人以上、プログラムディレクターを置く

技術のスキルが、システムを作り上げます。人がそれを使うかどうかを決めるのは、感情的知性です。

ある製造業の企業では、倉庫の責任者が会議では笑顔を見せながら、水面下でプロジェクトを妨害していました。察しのよいチェンジマネージャーが早い段階で兆候に気づき、彼を支持者に変えました。本稼働の時点で気づいていたら、はるかに直しにくかったはずです。

あるクライアントのプロジェクトマネージャーは、技術的には非常に優秀でしたが、伝え方を相手に合わせられませんでした。CFOに必要なコミュニケーションは、倉庫のスタッフに必要なものとは違います。その結果、組織全体で賛同が得られず、本稼働は苦いものになりました。

「従業員か、コンサルタントか」という問いへの答えは、ほぼ必ず、その両方です。

従業員は、業務を知っています。プロセス、社内の力学、そして誰も文書化していない回避策です。ある製造業の企業では、外部のコンサルタントがまったく見落としていた導入上の問題を、従業員が見つけました。その気づきが、倉庫の設定が惨憺たるものになるのを防ぎました。

従業員には、導入の経験が乏しいことがよくあります。ある小売のクライアントは、全員を社内の人間で固めたチームにこだわりました。6か月後、SAPを学びながら導入していたため、挽回しようのないほど遅れていました。

コンサルタントが持ち込むのは、パターンを見抜く力です。あるクライアントのためにコンサルタントを入れたところ、本稼働を台無しにしたはずのデータ移行のやり方を、すぐに見抜きました。

コンサルタントのリスクは、ナレッジ移転です。社内の誰もシステムを学ばなければ、コンサルティング費用は、稼働後も長く続きます。

うまくいくモデルは、シャドーペアです。ある医薬品のクライアントは、各コンサルタントに、本稼働後にその領域を引き継ぐ社内のカウンターパートを付けました。コンサルタントがデリバリーを行い、カウンターパートが学び、ナレッジが残ります。このモデルの周りで、差を生む実践が6つあります。

1. ソフトウェアを選ぶ前に、チームを作ってください。あるクライアントは、チームが保守できないモジュールを買い、6か月の混乱が続きました。
2. 人を専任にしてください。兼務は、プレッシャーがかかると本業が勝つということです。重要な設定が、担当者が忙しすぎるために数週間待たされるのを見てきました。
3. 可能なら同じ場所に集めてください。ある製造業のクライアントは、週に3日、チームを同じ部屋に置くことで、行ったり来たりのやり取りにかかる数週間分を省きました。
4. エスカレーション経路を早めに定義してください。ある小売のクライアントは、意思決定がどう上に上がるかを正確に示した、1枚の文書を持っていました。数えきれないほどの遅延を防ぎました。
5. 決定は、その根拠とともに書き残してください。決めたことと、その理由を記録していた企業と、仕事をしたことがあります。プロジェクトの途中で新しい経営陣が加わったとき、果てしない蒸し返しを防げました。
6. 途中のマイルストーンを祝ってください。ある製造業のクライアントは、月ごとに表彰のイベントを開いていました。小さなことですが、過酷な18か月の導入を通じて、士気を保ちました。

本稼働後に企業が犯す間違いは、導入チームを解散してしまうことです。まさにそのときこそ、CoEが、機能強化、アップグレード、ガバナンス、新規ユーザーのトレーニング、そして設定を事業の実際の動きに合わせ続けることを、引き継ぐ必要があります。

導入の最中に、計画してください。この助言を無視した製造業のクライアントがありました。本稼働の3か月後、主要な設定の専門家が去りました。構築したものをどう保守するかを誰も知らず、システムはすぐに劣化し始めました。

導入の最初の数か月から計画すべき、CoEの役割は次のとおりです。

CoEの役割	主な責任
CoEディレクター	SAP戦略、事業目標との整合、CoEの運営
ソリューションアーキテクト	アーキテクチャ、連携設計、クリーンコアのガバナンス
クリーンコアまたはBTP拡張リード	拡張のカタログ、アップグレードの影響分析
ファンクショナルコンサルタント	モジュールの最適化、プロセスの改善
テクニカルコンサルタント	開発、Basis、パフォーマンス、セキュリティ
チェンジおよびトレーニングリード	定着、トレーニング、能力の底上げ
データガバナンスリード	マスタデータの品質と標準
連携リード	ミドルウェア、API、システム間のデータフロー
サポートリード	問題解決、継続的な改善
SAPとの窓口担当（RISE）	SAPへのエスカレーション、サービスレビュー、ロードマップとの整合

ある医薬品企業は、自分の領域に影響しうる変更をすべて承認しなければならない、モジュールオーナーを任命しました。そのガバナンスが、2、3年後にシステムを使いにくくするのが常である、調整のない変更を防ぎました。

あるクライアントは、CoE予算の10%を継続的な学習に投資しました。3年後、同社は、競合他社が手を出せない新機能を導入していました。機能しているCoEとは、そういうものです。

計画が堅実に見えるのに、SAP導入チームが失敗するのはなぜですか？

たいていは、計画が技術を扱うだけで、人を無視しているからです。よくあるパターンは、重要な役割を、ほかの仕事を持つ人が担っていること、分野の専門家がプロジェクトの途中で現場の業務に引き戻されること、そしてチェンジマネジメントがトレーニングの機能として扱われることです。誰も意思決定を担わず、エスカレーション経路もなければ、障害は何週間も放置され、プロジェクトは、技術ではなく調整の失敗で頓挫します。

どのSAP導入でも欠かせない役割は何ですか？

専任で、責任を負う担当者が必要な役割が、6つあります。エグゼクティブスポンサー、プロジェクトマネージャー、主要モジュールごとに少なくとも1人のファンクショナルリード、ITリード、データ移行リード、チェンジマネジメントリードです。どれか1つが欠けても、その穴は本稼働前の最後の数週間に表面化します。最もリソースが不足しているのは、チェンジマネジメントです。RISEでは、拡張の責任者と、SAPの提供担当者との関係の責任者を、明確に置いてください。

RISE with SAPでは、チーム設計で何が変わりますか？

SAPがインフラと技術運用を担うため、Client Delivery ManagerやCloud Architect Advisorなど、SAPが割り当てた担当者と仕事をすることになります。その人たちを体制表に載せ、自社側の関係の責任者を指名してください。クリーンコアの責任も明確にする必要があります。大規模なプログラムでは専任のアーキテクト、中堅規模ではソリューションアーキテクトが担います。

SAPプロジェクトのチームは、従業員とコンサルタントのどちらで構成すべきですか？

両方です。従業員は、コンサルタントがすぐには再現できない業務の文脈を持っています。コンサルタントは、従業員に多くの場合欠けている、導入のパターンを見抜く力を持っています。各コンサルタントに、本稼働後にその領域を引き継ぐ社内のカウンターパートを組ませ、コンサルタントが去ってもナレッジが残るようにしてください。これを省く企業は、本来は社内で対応できたはずのサポートに、何年も費用を払うことがよくあります。

SAPのCoEは、いつから築き始めるべきですか？

導入の最中、できれば最初の数か月からです。最良のCoEメンバーは、たいてい導入で最も貢献した人たちで、本稼働まで待つと、見つけ出す前に彼らは次へ移ってしまいます。待った製造業のクライアントの1社は、本稼働の3か月後に主要な設定の専門家を失い、構築したものをどう保守するかを誰も知りませんでした。

2026年に、AIはSAPのチーム設計をどう変えますか？

SAP Joule for Consultants、SAP Build Code、Microsoft Copilotなどのツールは、人が一貫して使えば、ワークフローの多い役割の生産性を高めます。同じスコープに必要なチームは、これらのツールが登場する前より、やや小さくなりますが、劇的にではありません。ツールを役割の定義に組み込み、責任は人に残してください。AIは下書きを速く作りますが、その内容に責任を持つのは、いまも人間です。