ERP導入プロジェクトの体制と役割分担｜誰が何を決めるのか
KXSfourthERP導入では、担当者の人数より、誰が何を決め、誰が作業し、誰が結果を確認するかが重要です。責任が曖昧だと、課題が会議を回り続け、要件やデータの確認が遅れます。本記事では、経営層、業務部門、情シス、導入パートナーの役割と、判断を止めない体制の作り方を説明します。
この記事の要点
- 業務・技術・プロジェクト管理の責任を分けて定義する
- 役割表は部門名だけでなく、作業・判断・承認の単位で作る
- 通常業務と並行できるよう、参加時間と代理の判断方法を確保する
Agenda（この記事の内容）
体制は名簿ではなく意思決定の仕組み
体制図に経営層や部門長の名前があっても、何を判断するかが決まっていなければ機能しません。予算、対象範囲、部門間の業務変更、個別の設定など、決定の種類ごとに責任者を定めます。
導入プロジェクトでは、日常業務と異なる横断的な判断が増えます。営業の便利さが経理の照合負担を増やす場合など、部門内では決められない課題があります。全体の目的に照らして調整する場と権限が必要です。
体制を考える出発点は、工程で必要な作業と成果物です。要件、データ、テスト、教育、切替、運用を並べ、各々の担当と承認者を割り当てます。人数を先に決めるより、仕事から役割を考えると抜けを見つけやすくなります。
経営層と業務責任者の役割
経営層やスポンサーは、目的と優先順位を示し、予算や範囲、部門間の調整を判断します。日々の設定まで決める必要はありませんが、現場で解決できない課題を放置しない役割があります。
業務責任者は、新しい業務ルール、標準化の可否、例外処理、受入条件を決めます。実務担当者は、現在の処理と例外を説明し、試験や教育へ参加します。業務を知ることと、変更を承認できることは異なるため、両者を揃えます。
例えば請求方法を統一する場合、担当者だけでは取引先との条件を変えられないかもしれません。影響のある営業や経理の責任者が判断する必要があります。誰に相談すべきかが早くわかる体制が重要です。
| 役割 | 主に判断・実行すること |
|---|---|
| スポンサー | 目的・優先順位・予算・部門間調整 |
| 業務責任者 | 業務ルール・変更・受入 |
| 実務担当者 | 実態の説明・検証・教育 |
| 情シス | 構成・連携・権限・運用 |
| パートナー | 製品の実現方法・合意した導入作業 |
情シスと導入パートナーの役割
情シスは、システム構成、連携、認証、運用条件、技術上の制約を整理します。プロジェクトの調整を担うこともありますが、すべての業務判断を代行する役割ではありません。業務部門が決める事項を明確にします。
導入パートナーは、製品の実現方法を説明し、合意した範囲の設定・開発・移行などを支援します。業務変更の選択肢を提案できますが、自社の取引ルールやデータの正しさを最終承認するのは自社側です。
複数の会社が関わる場合は、ERP、連携先、ネットワークなどの境界を明確にします。問題が起きたとき、誰が最初に受け、どう切り分け、どこへ引き継ぐかを決めます。契約上の区分と実務の連絡経路を合わせておきます。
役割表で作業と承認を具体化する
役割表には、作業、実行担当、最終責任者、相談先、共有先を記載します。RACIのような形式は便利ですが、記号を埋めることが目的ではありません。「データ移行」では大きすぎるなら、抽出、修正、取込、照合へ分けます。
最終責任者が複数いて判断が止まる場合には、判断範囲を分けるか、最終決定者を明らかにします。実行担当が複数のときも、取りまとめる人を決めます。担当がない作業と、同じ役割を互いに相手が担うと思っている作業を探します。
役割表は、対象範囲と契約の作業一覧に対応させます。たとえばテスト支援の範囲がケース作成までなのか、実行や証拠の記録まで含むのかを確認します。大きな言葉の合意を、具体的な作業へ落とすことが大切です。
判断の期限と参加時間を確保する
会議体は、課題の検討、日程管理、重要な判断など目的で分けます。すべてを大人数の定例会で扱うと、細かい論点に時間を使い、重要な判断が後ろへ回ることがあります。議題ごとに必要な人を揃えます。
判断待ちの課題には、期限と、遅れた場合の影響を付けます。期限内に決められない場合の相談先も定めます。欠席時の代理や承認方法があると、会議を繰り返すだけの状態を減らせます。
また、担当者の通常業務を調整し、プロジェクトへ参加する時間を確保します。テストや移行の直前だけでは足りません。必要な役割を外部で補う場合も、自社が保持すべき業務判断と承認は残します。体制は進捗に応じて見直し、稼働後の担当者へ引き継ぎましょう。
一つの課題で役割表を試す
請求書の締め条件を統一する課題を例にします。パートナーは設定方式を説明できても、取引先との約束や社内の営業方針を決定できません。営業と経理の実務担当者が現状を整理し、各部門の責任者が変更の影響を確認し、必要ならスポンサーが部門間の優先順位を判断します。情シスは設定や連携への影響を確認します。
この課題を体制図へ当てはめ、誰が情報を集め、誰が選択肢を作り、誰が決定し、誰へ共有するかを確認します。決定者が会議へ参加できないなら、代理や別の承認方法を置きます。具体例で試すと、記号だけを埋めた役割表の不足を発見できます。
また、担当者が同時期に移行データの整理とテストも担うなら、役割としては成立していても時間が足りないかもしれません。工程別に必要な時間を見積もり、通常業務との調整を行います。責任を割り当てることと、その責任を果たせる条件を用意することを一組にしましょう。
主要な役割には代理と引継ぎ先も置きます。休暇や異動があっても、重要な判断の期限と根拠が失われないようにします。
よくある質問
プロジェクト責任者は情シスでよいですか？
配置は会社によりますが、部門横断の業務変更や予算の判断につながる権限が必要です。情シスが管理を担う場合も、経営層と業務責任者の判断経路を置きます。
少人数でも役割表は必要ですか？
一人が複数の役割を担っても構いません。重要なのは、抜けている作業や判断を見えるようにし、負担が集中していないか確認することです。
次に確認すること
移行・テスト・業務変更の三つについて、作業する人と最終承認する人を別々に書き出してください。
- ERP導入・運用の全体像｜契約後から稼働・定着までの進め方
- ERPの要件定義とは？選定時の要件を具体化する進め方
- ERPのデータ移行とマスタ整備｜対象・品質・照合をどう決めるか
- ERPのテストと受入判定｜業務シナリオ・合否基準・残る問題の扱い
- ERP導入パートナーの選び方｜製品とは別に確認したい体制と支援範囲
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
参考情報の確認日：2026年10月28日。運営方針・プロフィール
