ERP導入体制の作り方｜責任者・業務リーダー・IT担当の役割

ERP導入体制の作り方について、申込や依頼の前に確認しておきたい項目を整理しました。条件を一つずつ照合して、納得できる選択につなげましょう。

図の項目を使い、候補ごとの回答を同じ条件で記録してください。不明点を残したまま進めず、追加費用・契約条件・利用後のサポートまで確認してから最終判断します。

担当者名より先に意思決定の仕組みを決める

ERP導入では、経営判断、業務判断、システム判断が混在します。導入目的や対象範囲を決めるスポンサー、日々の進行を管理するプロジェクト責任者、業務ルールを決める部門責任者を区別します。

担当者名だけを並べず、どの論点を誰が決め、どの会議へ上げるかを明示します。現場要望を集める人と、要望を採否判断する人を同じ役割にすると、優先順位が決まらず課題が積み上がりやすくなります。

部門の業務代表には必要な時間を確保する

経理、販売、購買、在庫、生産など、対象となる業務ごとに代表者を置きます。日常処理だけでなく、月末、返品、取消、担当者不在、権限変更などの例外を説明できる人を選びます。

代表者が通常業務の合間に参加するだけでは、要件確認やテストが後回しになります。週あたりの稼働時間、繁忙期の代替担当、上長が優先順位を調整する手順を先に合意しておきます。

データとシステムの責任を分けて明記する

情報システム担当は環境、権限、連携、障害対応の整理を担いますが、顧客や商品マスタの正しさまで一人で保証できるとは限りません。データの意味と内容を決める業務オーナー、登録・変更を行う担当、技術的に移行する担当を分けます。

ベンダーについても、提案時の営業担当ではなく、実際のプロジェクトマネージャー、業務コンサルタント、開発・移行担当を確認します。協力会社が入る場合は、成果物の責任者と問い合わせ先を一本化できるか確認します。

役割表と会議体を小さく運用する

役割表は、成果物ごとに実行担当、承認者、相談先、共有先を一人または一組ずつ書きます。複数人が最終承認者になっている箇所は、誰が意見をまとめるか別に決めます。

週次では課題・作業・決定待ちを確認し、月次では予算・範囲・主要リスクをスポンサーが判断する構成が基本です。会議の議事録には決定内容、理由、責任者、期限を残し、未決事項を次回へ持ち越すだけにならないようにします。

• スポンサー：目的、予算、範囲変更の最終判断
• プロジェクト責任者：日程、課題、ベンダー調整
• 業務オーナー：業務ルール、例外、受入れ
• データ責任者：定義、品質、移行可否
• 情報システム：権限、連携、運用・障害対応

担当変更と引き継ぎも計画に含める

長い導入期間では、担当者の異動や休職が起こり得ます。決定記録、要件一覧、テスト証跡、未解決課題を共有保管場所に残し、引き継ぎ先が背景まで追える形にします。

ベンダー側の交代条件や引き継ぎ時間も契約・体制確認の段階で質問します。人に依存した知識を減らし、複数の担当者が重要な判断を説明できる状態を作ることが、稼働直前のリスク低減につながります。

小規模企業でも決めておきたい役割

専任メンバーを多く置けない会社では、役割を兼務しても構いません。ただし、最終決定者、現場の業務代表、データ責任者、システム管理者、ベンダー窓口の機能は誰が担うか明記します。ひとりが複数役を持つ場合も、承認と作業を同じ人が行ってよい範囲、代行者、通常業務との優先順位を決めておくと、担当者の不在で判断が止まりにくくなります。

部門代表は役職だけで選ばず、実際の例外処理や繁忙期の流れを説明できる人を含めます。営業、購買、在庫、経理などの代表に、週あたりの参加時間、会議前に確認する資料、持ち帰り事項の期限を合意してもらいます。現場代表を会議に呼んでも決定権や時間がなければ意見は出にくいため、上司と参加条件を先にすり合わせておくことが大切です。

判断待ちを短くする会議と記録

定例会議は進捗報告だけで終えず、未決事項、期限、決定者、必要な選択肢を一覧にして扱います。議題ごとに「情報共有」「相談」「決定」のどれかを明示すると、会議中に決められることと上位判断が必要なことを区別できます。決定記録には採用案だけでなく、理由、影響する業務、保留条件、再検討日も残し、あとから議論が蒸し返されるのを防ぎます。

ベンダーへの依頼は、担当者個人のメールや口頭だけに置かず、課題番号と回答期限を付けて共有台帳で管理します。重要な判断をベンダーに委ねず、自社側の責任者が業務上の許容範囲を決め、技術案の妥当性を確認します。回答が遅れた場合に誰へエスカレーションするか、費用・日程に影響する変更を誰が承認するかも契約前に決めておくと、責任の空白を減らせます。

体制が機能しているかを月次で点検

毎月、決定待ちの件数と滞留日数、会議欠席、未割当の課題、特定の担当者に集中する作業を点検します。件数が増えたら、メンバーを増やす前に、決裁経路が長すぎないか、議題の資料が不足していないか、業務代表に判断権限があるかを確認します。体制表は最初に作って終わりではなく、要件定義からテストへ移るタイミングで必要な役割を見直します。

交代や休職に備えて、主要な判断の根拠、進行中の論点、次の期限、関連資料の保管場所を引き継げる状態にします。個人の経験だけに依存しないよう、例外処理の決め方や問い合わせの窓口も記録します。プロジェクト責任者は進捗率だけでなく、現場が通常業務を続けられる負荷か、繁忙期との重なりがないかも確認し、必要なら範囲や日程を早めに調整します。

体制表を実際の連絡に使う

体制表には役職だけでなく、判断可能な範囲、代行者、会議への連絡手段、回答期限を書きます。業務停止につながる課題は通常の定例会を待たずに上げる経路を設け、費用や日程に影響する判断は決裁者へ同じ書式で提出します。月次で担当者の負荷と滞留を見直し、異動時には未決事項と根拠を後任へ引き継いで、個人の記憶だけに判断が残らないようにします。