ERPの選び方：比較の観点と失敗しない選定プロセス

ERP選定では、機能の多さや初期見積の金額だけで候補を決めると、連携・移行・運用や契約条件の差を見落としやすくなります。比較の前に「何をERPの対象にするか」を決め、同じ業務シナリオと前提条件で候補を評価することが重要です。

この記事では、ERP本体だけでなく導入パートナー、総保有コスト（TCO）、契約・運用リスクを分けて比べる方法を解説します。自社の比較表と選定計画を作り、契約先決定に必要な判断材料をそろえられるようになります。

ERP選定は、対象範囲を先に定めたうえで、製品だけでなく導入体制・総コスト・責任分界を同じ前提で比較します。

01SectionERPとは何か：選定対象を先に定義する

ERPは、会計、販売、購買、在庫、生産、人事などの基幹業務データを、統合または連携して扱う仕組みです。すべての業務を一つの製品に集約することだけを意味するものではなく、既存の周辺システムを残して連携する構成も選択肢になります。

製品比較に入る前に、対象範囲を定めておかないと、要件・見積・責任分界を候補ごとに同じ条件で比較できません。

比較開始前に決める対象範囲

対象範囲が曖昧なまま候補を比較すると、ある候補では連携費用、別の候補では移行作業が見積対象外になるといった差が起きます。まずは対象範囲を選定チームで合意し、変更時には評価条件も更新する運用にします。

02Section選定前に決める目的・範囲・体制

ERP導入の目的は「効率化」だけでは比較基準になりません。どの業務を、どの状態に変えたいのかまで具体化すると、必要な機能・運用・支援範囲を判断しやすくなります。

目的を業務成果に変換する

目的は、たとえば締め処理に必要な照合を減らす、在庫や原価を必要な粒度で把握する、承認や権限の統制を強める、といった業務成果に置き換えます。成果ごとに、対象業務、確認するデータ、責任者、導入後に測る指標を対応付けます。

現行踏襲と標準化を分けて考える

現行業務をすべて再現することが最適とは限りません。法令、内部統制、顧客との契約などにより維持すべき処理と、標準化・廃止・手順変更を検討できる処理を分けます。個別対応が必要な理由を明確にすることで、追加開発の範囲を必要以上に広げにくくなります。

意思決定者を選定開始時に置く

選定チームには、少なくともスポンサー、プロジェクト責任者、業務責任者、情報システム、経理・購買・法務などの管理部門を含めます。データ移行や現場定着の影響が大きい場合は、データ担当者と現場代表も参加させます。

特に、対象範囲の縮小、業務標準化、残リスクの受容、予算と契約条件は、誰が最終判断するかを先に決める必要があります。

03SectionERP比較の8軸と足切り・重み付け評価

必須要件の未充足は候補除外の判断材料です。加点評価の総点に加え、4領域の確認を経て採用可否を判断します。

情報システム調達では、構想、要件定義、要件の文書化、供給者選定、契約合意を関連付けて進める考え方が整理されています。IPAの調達管理ガイドも、評価条件をそろえた調達プロセスを考える際の参考になります。

要件を3区分に分ける

機能要件だけでなく、可用性、性能・拡張性、運用・保守性、移行性、セキュリティも確認対象に含めます。IPAの非機能要求グレードは、こうした非機能要件を整理する際の枠組みとして参照できます。

共通の業務シナリオでデモを行う

候補ごとに異なるデモを受けると、印象で比較しやすくなります。通常処理に加え、次の観点を共通シナリオとして提示します。

• 返品、訂正、差戻し、承認者不在などの例外処理
• 月次締め、棚卸、締め後修正などの締め処理
• 権限変更、履歴、監査ログなどの統制
• 連携エラーの検知、再送、訂正時の整合性
• 問合せ、利用者追加、異動時の運用

業界固有の業務要件は、この共通シナリオに追加する前提で扱います。

足切りと重み付けの最小ルール

必須要件は「充足・未充足・条件付き」で判定し、未充足の候補は除外します。条件付きの場合は、回避策、追加費用、契約条件、未解決リスクを最終比較へ持ち越します。

重要要件は、定義した評価点に重みを掛けて比較します。計算式は 加重点＝重み×評価点 です。製品適合、導入パートナー、TCO、契約・運用リスクは別々に集計します。総点が高くても、必須条件や責任分界に問題が残る候補を自動採用しないことが重要です。

04Section失敗しにくいERP選定プロセス

工程ごとに判断ゲートを置くことで、候補比較の条件や未解決事項を次工程へ持ち越さずに管理しやすくなります。

ここでいう選定期間は、構想整理の開始から契約先決定までです。契約後のキックオフ、詳細要件定義、設定・開発、移行、本稼働は導入プロジェクトとして別に管理します。

RFI・RFP・デモの使い分け

RFI（情報提供依頼書）は、候補が多い段階で、対象業務への対応範囲、提供形態、支援可能範囲などを広く確認するために使います。RFP（提案依頼書）は、候補を絞った後に、要件、導入体制、見積前提、契約条件をそろえて提案を受けるための文書です。

デモは共通シナリオに沿って実現方式と運用可能性を確認し、性能、重要連携、データ移行など、デモだけでは不確実性を解消できない事項に限って検証を追加します。IPAの情報セキュリティマネジメント試験シラバスでは、RFI、RFP、RFQを調達で用いる依頼文書として扱っています。呼称や運用、必須記載事項は自社の購買・契約規程に従ってください。

判断ゲートで手戻りを防ぐ

要件や見積前提を途中で変更する場合は、全候補に同じ変更内容と回答期限を伝え、評価表の版を更新します。候補ごとに異なる条件で比較しないことが、公平な選定の前提です。

05Section規模・成長段階に応じた選び方

ERPの適合性を、中小企業か大企業かといった従業員数だけで判断すると、過剰な構成や将来の機能不足につながることがあります。見るべきなのは、現在の業務複雑性と、変化を受け止める運用体制です。

業務複雑性で現在の必須要件を定める

現在の必須要件は、法人・拠点の数、取引・データ量、部門間連携、権限・監査の水準、既存システムとの依存関係、IT運用力から整理します。

中小企業など小規模または初回導入では、標準機能へ業務を寄せられる範囲、教育負荷、日常運用のしやすさを重視しやすくなります。一方、複数法人・拠点や複雑な連携がある場合は、データ正本、権限、連携障害時の運用、段階移行での二重管理を重点的に評価します。

成長計画は将来要件として記録する

利用者、拠点、事業、取引量の増加見込みは、確度・発生時期を分けて整理します。確度が低い将来像をすべて先行実装するのではなく、「どの条件が発生したら、何を、どの費用・制約で変更できるか」を将来要件として確認します。

特に専任のIT人員が限られる中小企業では、内製できない高度な個別開発を前提にしないことも重要です。変更後に誰が設定、連携、権限、問い合わせを担うのかまで含めて、運用可能な構成を選びます。

06Section提供形態と標準・設定・開発の判断

クラウド、オンプレミス、ハイブリッドは提供形態の違いです。一方、標準機能、設定、追加開発・外部連携、個別開発は、要件をどう実現するかという実現方式の違いです。両者を一つの比較項目にまとめず、別軸で確認します。

提供形態では運用責任を確認する

クラウド型では、インフラ運用負荷や更新方針を受け入れられるかを確認します。オンプレミス型では、自社または委託先が基盤、更新、監視、バックアップを継続運用できるかが論点です。ハイブリッド型では、既存資産を残す必要性と、システム境界ごとの障害切り分け、二重運用を評価します。

クラウドの基本概念はNIST SP 800-145の共通語彙も参考になりますが、個別サービスのデータ所在、保持期間、復旧目標、SLA、責任分界は確認できません。これらは公式仕様、契約条件、自社の運用設計で確認してください。提供形態ごとの論点は、パッケージ・提供形態の選び方とクラウドERPの選び方でも確認できます。

実現方式は標準から検討する

実現方式は、標準機能、設定、追加開発・外部連携、個別開発の順に検討します。標準機能や設定で目的・統制を満たせるなら、変更範囲と保守負担を抑えやすくなります。

追加開発や個別開発を採用する場合は、初期構築の可否だけで判断しません。ERPや周辺システムの更新時に必要な追随・再試験、障害時の切り分け、保守主体、変更費用、受入基準を要件・TCO・契約条件に反映します。

周辺システムを残す場合は連携を要件化する

既存システムを残す場合は、データの正本、同期頻度、エラー検知・再送、訂正時の整合性、二重管理を終える条件を定めます。調達時のセキュリティ要件は、機能面だけでなく利用・運用面を含めて整理する必要があります。IPAのセキュリティ要件リスト活用ガイドブックも確認の補助になります。

07Section費用構造・TCO・KPI

TCOは見積合計ではなく、比較期間と対象範囲をそろえたうえで、導入・運用・変更に関わる費用を合算して確認します。

ERPの費用は、対象業務、利用規模、連携、移行、追加開発、教育、支援範囲、契約条件によって変わります。公開情報だけでは同じ条件での費用比較が難しいため、合計額や一般的な金額レンジだけで候補を並べるのではなく、費用構造と比較前提を固定します。

費用を4層に分ける

TCO比較前に固定する条件

比較期間TCO ＝ 初期費用 ＋ 比較期間中の継続費用 ＋ 変更・追加費用 ＋ 旧環境並行費用 ＋ 発注側直接費

比較条件がそろわない見積は、TCO比較を保留します。

見積では、次の5点を確認します。

• 含む作業と含まない作業
• 発注側が担うデータ整備、テスト、教育などの作業
• 利用者数、容量、取引量、対象範囲の増加による増額条件
• 変更管理の手続き、固定価格か時間精算か、単価の扱い
• 受入基準、検収条件、再試験が必要になる条件

TCOと投資効果は、取引・契約や投資判断の論点として扱われます。経済産業省の研究会資料も、総コストと投資価値を対話する際の参考になります。

稟議と導入後評価につながるKPI

KPIは、業務改善、統制、運用定着の3方向から選びます。業務改善では月次締めにかかる日数や手入力・照合件数、統制では承認滞留や権限外処理、運用定着では教育完了率や問合せ・エラー件数などが候補です。

指標ごとに、現状値、目標値、測定時点、データ取得元、責任者を定めます。作業時間が減っても、その時間が別業務に再配分される場合があるため、削減時間をそのまま人件費削減と同一視しないようにします。

08Section導入パートナーと発注側体制・最終決裁

導入パートナーは、製品の機能評価とは分けて評価します。業務理解、要件定義の方針、推進体制、移行、テスト・受入、教育、保守、追加費用条件の実行可能性を確認します。

パートナーへの確認事項

発注側が保持すべき判断

外部支援を活用しても、発注側の判断責任はなくなりません。スポンサーは目的・優先順位・リスク許容度を、プロジェクト責任者は判断ゲートと課題管理を担います。業務責任者は業務ルールと受入可否を、情報システムは連携・権限・運用の受入可否を判断します。データ担当者と現場代表は、データ品質と利用定着の条件を確認します。

利用者側が要求を検討・策定し、調達・構築・運用を通じて共有する重要性は、重要情報を扱うシステム向けの資料ですが、IPAの要求策定ガイドでも示されています。内製と外部支援の分担は、内製と外部支援の考え方も参照してください。

最終決裁は4つの領域を分けて行う

最終決裁では、加重点が最も高い候補をそのまま採用するのではなく、次の4領域を分けて確認します。

• 製品適合：必須業務、統制、必須連携を満たしているか
• 導入パートナー：体制、移行、テスト、教育、保守の実行条件が明確か
• TCO：比較期間、対象範囲、支援範囲、増額条件がそろっているか
• 契約・運用リスク：受入・検収・変更・障害時の責任分界と主要リスクを受容できるか

条件付きで採用する項目がある場合は、責任者、解消期限、確認証跡、契約または導入計画へ反映する条件を決めます。これらが未確定なら、契約先決定を急がず、交渉や追加確認を行う判断が必要です。

ERP選定で重要なのは、候補の機能数を競わせることではありません。対象業務とデータの境界を定め、必須条件で候補を絞り、同じ業務シナリオ・TCO前提・契約条件で比較することが、導入後の手戻りを減らす土台になります。

ERP導入を支援できる会社を探す

要件整理、RFP作成、製品・導入パートナーの比較、導入支援まで、必要な支援範囲に応じて相談先を比較できます。

ERP導入564社掲載

ERP導入の支援会社を見る