2026年のERP導入チーム：必要な人材と、それぞれの役割

ERP導入チームには、権限を持つスポンサー、ERPを理解しているプロジェクトマネージャー、影響を受ける全部門のビジネスプロセスオーナー、機能コンサルタントとテクニカルコンサルタント、そして連携、データ移行、テスト、チェンジ、カットオーバーそれぞれの専任リードが必要です。クラウドのSAPプログラムでは、これにクリーンコアアーキテクトとSAPの指名窓口が加わります。チームの規模は会社の従業員数ではなく複雑さで決め、すべてのコンサルタントに、本稼働後にその領域を担う社内の担当者を組ませてください。

この記事は、ERPプログラムの体制を組むスポンサー、CIO、プログラムディレクターに向けたものです。ロール、各ロールの成否を分けるもの、チーム規模、クラウドERPとAIで何が変わるか、そして導入パートナーとの作業の分け方を扱います。

私が関わったある企業では、2つのERP導入が同時に進んでいました。1つはSAP、もう1つはOracleです。Oracleのプロジェクトには4,500人が関わり、SAPのプロジェクトは38人でした。一方はスムーズに本稼働し、もう一方は終わりのない惨事になりました。違いはチームでした。

SAP導入に25年携わってきましたが、このパターンは変わりません。チームを間違えるか、適切な人材を間違った体制に置くと、プロジェクトは長引き、コストは膨らみ、本稼働の頃にはユーザーはすでにそのシステムを嫌うと決めています。

1. プロジェクトスポンサー障害を取り除き、予算を確保し、部門間の判断を下す
   SAPサービス窓口RISEプログラムで、プラットフォームのエスカレーションとサービスレビューを担当
2. プロジェクトマネージャースケジュール、スコープ、リスク、パートナー調整

• ビジネスプロセスオーナー設計を検証し、実際のワークフローをテストする
• 機能コンサルタントとテクニカルコンサルタント設定し、拡張し、異論を唱える
• データ移行リードクレンジング、ロード、カットオーバー用データ
• 連携リードミドルウェア設計とデータフロー
• チェンジ・トレーニングリードコミュニケーション、チャンピオン、定着
• クリーンコアアーキテクトクラウドエディションで、すべての拡張をどこに置くか

ロール	実際に担う仕事	関与する時期
プロジェクトスポンサー	障害を取り除き、予算を確保し、部門をまたぐ判断を下す	全フェーズ
プロジェクトマネージャー	スケジュール、スコープ、リスク、パートナー調整を運営する	全フェーズ
ビジネスプロセスオーナー	設計を検証し、シナリオをテストし、実際のワークフローを代弁する	ExploreからDeploy
機能コンサルタント	要件を収集し、モジュールを設定し、テストを支援する	ExploreからDeploy
テクニカルコンサルタント	拡張、インターフェース、システム設定	RealizeからDeploy
連携リード	ミドルウェア設計と、システム間のデータフロー	ExploreからDeploy
データ移行リード	データ戦略、クレンジング、ロード、カットオーバー用データ	PrepareからDeploy
チェンジ・トレーニングリード	トレーニング、コミュニケーション、定着施策	ExploreからRun
テストリード	テストスクリプト、SIT、UAT、不具合管理	RealizeからDeploy
カットオーバーマネージャー	本番切り替え、ダウンタイム、ロールバック計画	Deploy
クリーンコアアーキテクト（クラウドエディション）	すべての拡張をどこに、どのクリーンコアレベルで置くかを決める	ExploreからRun
SAPサービス窓口（RISE）	プラットフォームのエスカレーション、サービスレビュー、SAPロードマップとの整合	PrepareからRun

ロールごとの詳細は、私の記事SAP導入チームのロールで解説しています。

プロジェクトスポンサー

スポンサーの仕事は、憲章に署名して姿を消すことではありません。部門間で意見が割れたとき、プロジェクトマネージャーより上に決定する権限を持つ人がいなければ、プロジェクトは何か月も止まります。スポンサーにはすぐ連絡がつき、厳しい判断を下す意思があり、キックオフだけでなく安定化の期間まで関与し続けることが求められます。

うまくいかないのは、すべてをIT部門に任せてしまうスポンサーです。ERPは事業の動かし方を変えます。経営陣が主導しなければ、失敗します。スポンサーのための会議体をどう組むかは、ステアリングコミッティのガイドで扱っています。

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

ERPのプロジェクトマネージャーには、一般的なITプロジェクト管理だけでなく、SAPやOracleのプログラムが実際にどう動くかを知っていることが必要です。リスクも、依存関係も、カットオーバー時のプレッシャーも違うからです。

うまくいかないのは、スコープの判断をコンサルタントに委ねてしまうプロジェクトマネージャーや、テストの期限をビジネス側に守らせられないプロジェクトマネージャーです。

ビジネスプロセスオーナー

ITが事業を動かしているわけではありません。動かしているのは、オペレーション、財務、調達、人事です。プロセスオーナーは、システムが書面上だけでなく実際のプロセスで機能することを確かめます。彼らを外すと、ワークショップでは筋が通っていたのに、稼働初週で破綻する設定ができあがります。

最初から巻き込んでください。自分が関わっていない決定を承認させるためだけに、UATで呼んでも意味がありません。

ERPコンサルタント

優れたコンサルタントは異論を唱えます。あなたのコンサルタントが何にでも賛成し、要件に一度も異議を唱えないなら、専門性を提供しているのではなく、時間を請求しているだけです。最も優れたコンサルタントは、何か月分ものコストになる前にミスを止めます。

弱いコンサルタントの兆候の1つは、過剰にカスタマイズすることです。業務プロセスを変えるべき理由を説明するより、そのほうが楽だからです。カスタムプログラムはすべて、保守し、アップグレード時にテストし、次のチームに説明しなければなりません。SAPのクリーンコアレベルによって、その負債は今では目に見えます。従来のやり方で作った拡張はレベルCまたはDに分類され、最初のメジャーアップグレードで表面化します。

データ移行リード

旧システムの悪いデータは、新システムでも悪いデータになります。移行の前にデータ品質について話し合う責任者がいなければ、稼働初日の財務レポートは現実と一致しません。

データ移行は、ビジネス側が責任を持つべき業務プロセスです。ITはデータを移せます。それが正しいことを確認するのは、ビジネス側です。

チェンジマネジメントとトレーニングのリード

チェンジマネジメントはトレーニングではありません。コミュニケーション、早期の巻き込み、そして本稼働前に事業部門の中でチャンピオンを見つけることです。トレーニングで十分だと考えていると、新システムを信頼しないユーザーはスプレッドシートに戻ってしまい、本稼働後にそれを直すにはコストがかかります。

このリードは、本稼働の2週間前にPDFを配るのではなく、コンテンツを作り、パイロットを実施し、準備状況を測定すべきです。SAPのプログラムでは、現在はデジタルアダプションのツールも担当します。SAPはSAP Enable Nowを、2024年に買収したWalkMeに統合しつつあるため、新しいコンテンツはWalkMeで計画すべきです。

クリーンコアアーキテクト（クラウドエディション）

SAPは現在、すべての拡張をAからDまでの4つのクリーンコアレベルで評価します。ギャップごとに、標準設定で解決するのか、SAP BTP上またはABAP Cloudを使ったシステム内のレベルA拡張で解決するのか、あるいは解決しないのかを、誰かが決めなければなりません。大規模プログラムでは専任のロールになります。ミッドマーケットのプログラムでは、通常ソリューションアーキテクトが兼ねます。

SAP BTPとABAP Cloudの経験がないパートナーには、このロールは務まりません。これらのルールのもとで何件の拡張を納めてきたかを尋ね、実物を見せてもらってください。

SAPサービス窓口（RISEプログラム）

RISE with SAPでは、SAPがシステムのインフラと運用を担うため、SAPもデリバリーの一部です。CIOには、プラットフォームのエスカレーション、サービスレビュー、ロードマップの整合のために、指名されたSAPの窓口が必要です。その人物は、ステアリングコミッティの招待者リストだけでなく、Prepareの段階からチームの名簿に載せてください。

チームの規模は、人数ではなく複雑さに合わせます。

企業タイプ	一般的なチーム規模	複雑さを左右する要因
小規模（単一法人、従業員500人未満）	10〜25	ほぼ標準機能で、連携は少ない
ミッドマーケット（複数拠点、従業員500〜5,000人）	30〜75	連携の増加、地域ごとのプロセスの違い、大規模なチェンジ
エンタープライズ（グローバル、従業員5,000人以上）	100〜500以上	複数の法人と連携、複数の法域にまたがるコンプライアンス

複雑な受注生産型の製造を行う従業員50人の工場は、標準的な小売プロセスで動く従業員500人の会社より、大きく専門性の高いチームを必要とすることがあります。やるべきことに合わせて規模を決めてください。計画の立て方は、私のガイドSAPプロジェクトのリソース配分計画で示しています。

Jouleは現在、SAPの導入ツール（SAP Cloud ALMとSAP Activate Roadmap Viewer）に組み込まれています。SAP Build Codeは、Jouleを使って開発者がSAP BTP上で拡張を構築するのを支援します。Microsoft Copilotは、ステータスレポート、ステアリングコミッティ向けの資料、チェンジに関する連絡文を下書きします。

一貫して使えば、これらのツールはワークフロー中心のロールを加速します。同じスコープを数年前に実施する場合と比べて、プログラムはいくらかスリムになりますが、劇的に小さくなるわけではありません。

ツールをロール定義に書き込んでください。機能コンサルタントは、要件とフィット・ギャップ文書の初稿にAIを使います。プロジェクトマネージャーはステータス報告に使います。開発者は役に立つ場面で使います。AIが変えないのは説明責任です。下書きは速くなりましたが、その内容に責任を持つのは今も人です。

ほとんどの企業は、事業を知る社内のコアチームと、技術と方法論の深さを持ち込むパートナーを組み合わせます。

社内チームは、ステータス会議に出席するだけでなく、本当に関与しなければなりません。そうでなければ、パートナーだけが理解していて、社内の誰も運用できないシステムができあがります。

パートナーに期待できるのは、体制、速い意思決定、そしてあなたと同じ種類の失敗を経験してきた知見です。任せてはいけないのは、スコープの判断、プロセス設計の承認、ユーザーの準備状況です。これらには社内のオーナーが必要です。

一貫してうまくいくモデルは、シャドーペアリングです。各コンサルタントに、本稼働後にその領域を担う社内のカウンターパートを置きます。コンサルタントが成果を出し、社内の担当者が学び、コンサルタントが去った後も知識が残ります。

パートナーを見極めるときは、ベンダーの看板顧客ではなく、自社と同じ規模・同じ業種の企業からの参照先を求めてください。クリーンコアの経験を具体例つきで尋ね、RISEプログラムでSAPとどう協働しているかも聞いてください。曖昧な答えは、誰が最新の知識を持っていて、誰が3年前のSAPを売っているのかを教えてくれます。

ERP導入チームは何人で構成しますか？

会社の規模よりも、複雑さによって決まります。プロセスが単純な小規模企業では通常10〜25人、複数拠点のミッドマーケット企業では30〜75人、グローバル企業では100〜500人以上です。個別受注設計型のプロセスを持つメーカーは、標準的な小売機能で動くより大きな会社よりも、多くの体制を必要とします。

クラウドのSAPプログラムでは、どんな新しいチームロールが必要ですか？

2つです。1つは、すべての拡張をどこに、どのクリーンコアレベルで置くかを決めるクリーンコアアーキテクトまたは拡張リードです。小規模なプログラムでは、ソリューションアーキテクトが兼ねます。もう1つは、RISE with SAPの場合に、エスカレーションとサービスレビューを担う指名されたSAPサービス窓口です。SAPがシステムのインフラと運用を担うためです。

ERP導入におけるプロジェクトスポンサーの役割は何ですか？

スポンサーは予算を確保し、障害を取り除き、部門間で意見が割れたときに決定を下します。プロジェクトを運営するのではなく、運営できる状態にするのが役割です。スポンサーが果たす最も重要なことは、安定化の期間まで関与し続けることです。カットオーバー後に経営層の関心が離れたプロジェクトでは、何年も残る回避策が生まれます。

ERP導入にビジネスプロセスオーナーが必要なのはなぜですか？

財務、オペレーション、人事、調達の担当者は、仕事が実際にどう進むかを知っているからです。彼らがいなければ、チームは書面上では筋が通っても現場では機能しないシステムを設計してしまいます。最初からワークショップや設計判断に巻き込んでください。UATの段階では、誤りを直すにはもう費用がかかりすぎます。

ERPコンサルタントには何を求めるべきですか？

異論を唱える姿勢です。何にでも賛成するコンサルタントは、あなたではなく自分の仕事を楽にしています。優れたコンサルタントは、悪い要件に異議を唱え、スコープクリープを指摘し、カスタムよりも標準のほうが多くの場合あなたの役に立つ理由を説明します。そのうえで、具体例つきのクリーンコア経験、連絡して確認できる同規模の参照先、そして彼らがあなたの課題を解決しようとしているのか、すでに納品方法を知っている案件を売ろうとしているのかを確かめてください。

ERP導入でデータ移行はどう扱いますか？

戦略、クレンジングルール、ロード、本稼働時の検証に責任を持つ専任のリードを置きます。データ品質に責任を持つのはビジネス側です。ITはベンダーレコードを移せますが、それが正しいかどうかを知っているのはビジネス側だけです。

ERPプロジェクトにおけるチェンジマネジメントとは何で、なぜ重要ですか？

仕事の進め方が大きく変わることに対して、本稼働の前、最中、後で人々の準備を整えることです。コミュニケーション（何がなぜ変わるのかを早めに伝える）、巻き込み（キーユーザーを設計とテストに参加させる）、サポート（同僚の適応を助けるチャンピオン）の3つを含みます。トレーニングの予定表として扱ったプロジェクトは、毎回同じ結果になります。回避策、スプレッドシート、そして誰も信頼しないシステムです。