- 実際に参加する責任者と専門家に面談した
- 要員の稼働率と兼任状況を確認した
- 担当交代と引き継ぎ条件を書面で聞いた
ERP導入会社の体制を見極めるについて、申込や依頼の前に確認しておきたい項目を整理しました。条件を一つずつ照合して、納得できる選択につなげましょう。
図の項目を使い、候補ごとの回答を同じ条件で記録してください。不明点を残したまま進めず、追加費用・契約条件・利用後のサポートまで確認してから最終判断します。
商談担当とプロジェクト担当を分けて確認する
選定時の説明が良くても、契約後の実務メンバーが異なることがあります。契約前に、プロジェクト責任者、業務設計、移行、連携、教育の主要担当者と会い、質問への回答や意思疎通を確かめます。
肩書だけで評価せず、類似規模や対象業務の経験、稼働開始時期、同時に担当する案件数、週あたりの参加時間を聞きます。提案書で約束した人が初期計画に参加できるかも確認します。
協力会社と責任のつながりを明らかにする
複数会社が参加する場合は、契約相手、成果物の承認者、障害時の一次窓口、各社の作業範囲を一枚にまとめます。再委託がある場合は、会社名・作業内容・データ取扱い・交代時の連絡方法を確認します。
別会社へ依頼した作業の品質を誰が保証するかも重要です。課題が会社間で往復しないよう、全体の統合責任者がいるか、日程と仕様を一元管理できるか質問します。
提案と実務のギャップを質問で見つける
自社の難しい業務シナリオを提示し、導入会社がどの追加情報を確認するか観察します。すぐにできると断言するより、前提、未確認事項、調査方法、判断期限を説明できるかが実務能力の手がかりです。
過去の導入実績は社名や件数だけでなく、同じ制約に対して何を標準化し、どのリスクをどう管理したかを聞きます。事例情報を開示できない場合は、匿名化された成果物のサンプルや進行方法で確かめます。
交代・遅延・品質問題への対応を契約へ反映
担当者の交代、稼働不足、重要な成果物の遅延が起きた場合の通知期限、後任者の要件、引き継ぎ期間、追加費用の扱いを確認します。プロジェクト会議での報告だけでなく、契約上の責任と照合します。
議事録、設計書、移行手順、課題一覧を自社でも参照できる形式で保管するよう定めます。引き継ぎ時に一から説明し直さずに済むよう、成果物の更新責任と共有場所も合意します。
- 役割・氏名・専門分野・稼働時間
- 協力会社・再委託・データアクセス範囲
- 課題・品質・納期の報告とエスカレーション先
- 担当交代時の通知・後任要件・引き継ぎ期間
- 成果物の所有・保管・契約終了後の受渡し
価格だけでなく実行可能性を採点する
同じ価格でも、経験者が稼働できるか、業務部門と直接話せるか、変更要求に対応できるかで導入リスクは異なります。見積もり条件を揃えたうえで、体制、稼働、引き継ぎ、品質管理を比較項目にします。
不明点は契約前の確認事項として記録し、誰がいつ回答するかを決めます。重要な体制条件が解決しない場合は、導入開始後のリスクとして放置せず、評価や契約条件へ反映します。
提案チームの実働時間を確かめる
提案書に記載された責任者や専門家が、実際に何割の時間を担当するか、設計レビューや重要会議へ参加できるかを確認します。提案担当者と導入担当者が異なる場合は、移行前の引継ぎ会議に両者が出席し、要件や前提が変わっていないか自社が確認できるようにします。担当者交代の事前通知、後任の経験要件、引継ぎ期間も契約または議事録に残します。
要員表は氏名・役割だけでなく、工程ごとの稼働率、作業場所、レビュー責任、成果物の作成者と承認者を記載してもらいます。複数案件を兼務する専門家については、繁忙時に優先される顧客と代替要員の有無を聞きます。自社側の業務担当が週に何時間必要かも同じ表に置き、ベンダーだけでなく自社側の参加負荷が現実的かを見積もります。
成果物と受入条件を契約に含める
「導入支援一式」のような曖昧な表現を避け、要件一覧、設定書、データ移行結果、テスト記録、操作手順、運用引継ぎなど、各工程で受け取る成果物を定義します。成果物ごとに提出形式、期限、レビュー期間、差戻し回数、修正期限、受領判定者を決めます。対象範囲外の作業を明記することも重要で、後から追加費用になる条件と見積もり手順を契約前に確認します。
固定価格と準委任のどちらが適するかは、要件の確定度や変更頻度で変わります。固定価格でも前提条件が崩れれば変更協議が必要になり、準委任でも作業報告と承認がなければ費用を管理できません。追加変更の申請票に、理由、見積額、納期影響、代替案、承認者を含め、承認前に着手しないルールを双方で共有します。契約担当者だけでなく業務責任者も、見積もりの作業範囲を確認してください。
評価会議を公平な条件で行う
ベンダーへの質問は同じ文面で送り、回答期限と追加資料の条件をそろえます。デモでは、各社に同じ業務シナリオ、同じサンプルデータ、同じ制約を提示し、説明の印象ではなく操作手順、例外時の対応、標準機能と追加開発の境界を記録します。質問への回答が「できます」だけなら、具体的な設定例、必要な作業、費用、保守責任、実現条件を分けて確認します。
評価表は業務適合、プロジェクト体制、データ移行、連携、運用支援、契約条件、費用を分け、評価者が個別に点を付けた後で差を議論します。採点の差が大きい項目は、評価基準が曖昧か、提案内容の前提が異なる可能性があります。最終候補とは契約前にリスク一覧を共有し、未確定の仕様や価格条件を残したまま稟議へ進まないよう、解消期限と責任者を決めます。
契約前の確認事項を合意記録にする
候補会社と合意した成果物、担当者の稼働、見積前提、追加変更の承認、受入期間、障害時の支援を契約別紙または議事録へ残します。提案時の説明と契約条文に差があれば、誰がいつ修正するか決め、曖昧なまま発注しないようにします。自社側で用意するデータや業務担当の時間も作業分担表へ記載し、双方の依存作業が遅れた場合の連絡と調整方法を合意してください。
参考にした公式情報
制度・仕様は更新されるため、実施前に最新の公式情報を確認してください。
本記事は一般情報です。個別の法務・税務・労務・契約判断を代替しません。制度変更や自社への適用は、最新の公式情報と専門家にご確認ください。