——選定・評価・導入方式の決定まで——
2026年6月
ERP導入プロジェクトの成否は、驚くほど早い段階で決まる。設計書が一枚も書かれる前に、テストが一行も走る前に、しばしばプロジェクトの命運を左右する意思決定が下されている。それが「ERPパッケージの選定」である。
パッケージを選ぶとはすなわち、自社の業務プロセスをそのソフトウェアの設計思想に「委ねる」ことを意味する。SAPを選べばSAPのロジック、OracleならOracleの哲学に従って、自社の受注・調達・生産・会計の業務が再設計されることになる。その選択が誤っていれば、莫大なカスタマイズコストと無限のデバッグ地獄が待っている。
本ガイドは、構想策定フェーズにおけるERPパッケージ選定・評価・導入方式決定のプロセスを、実務の視点から解説するものである。「なぜそのパッケージを選ぶのか」という問いに、経営が納得できる根拠を持って答えられる状態を作ることが、我々コンサルタントの最初の使命に他ならない。
ERP（Enterprise Resource Planning）とは、企業の主要業務——受注、購買、製造、在庫、会計、人事——を単一のデータベース上で統合管理するためのソフトウェア基盤である。ERPが存在しない世界では、基幹業務の各部門が個別のシステムを持ち、それらをExcelや人手によって「橋渡し」する構造が生まれる。この「橋渡し」こそが、データの不整合、二重入力、意思決定の遅延という「諸悪の根源」となる。
ERPを導入することは、単にシステムを入れ替えることではない。それは企業が業務プロセスの「共通言語」を持つことを意味する。受注が入力された瞬間に在庫が引き当てられ、出荷が確定した瞬間に売上が計上され、月次決算が数日ではなく数時間で完了する。これがERPの本来の価値である。
市場には複数のERPパッケージが存在するが、それぞれに明確な「得意領域」と「設計思想」がある。選定の前に、主要パッケージの特性を正確に把握しておくことは不可欠である。
パッケージ | 主要ベンダー | 特徴 | 主な対象企業規模 |
SAP S/4HANA | SAP SE（独） | 製造業・グローバル展開に強い。業種別モジュール（IS）豊富。Fit to Standard思想。 | 大企業・中堅上位 |
Oracle ERP Cloud | Oracle（米） | 財務会計・グローバル連結に強い。クラウドネイティブ設計。 | 大企業・グローバル財務管理 |
Microsoft Dynamics 365 | Microsoft（米） | 中堅企業向け。Microsoft製品（Excel・Teams）との親和性高い。 | 中堅・中小企業 |
GRANDIT / ProActive | 国産 | 日本の商習慣（奉行帳票・支払サイト等）対応。SME向け。 | 中小〜中堅企業 |
Infor CloudSuite | Infor（米） | 製造業特化（食品・ファッション・航空）。業種テンプレート豊富。 | 製造業中堅〜大企業 |
注目すべきは、これらのパッケージが「どれが優れているか」ではなく「どの業種・規模・経営戦略に適合するか」で評価されなければならない点である。グローバルに50拠点を持つ製造業がMicrosoft Dynamics 365を選定することも、国内専業の中堅メーカーがSAP S/4HANAを選定することも、それ自体に正解も不正解もない。重要なのは「自社の5年後のあり姿とERPの設計思想が整合しているか」である。
現代のERP選定において最も重要なキーワードが「Fit to Standard（標準への適合）」である。かつてのERP導入は「自社業務に合わせてパッケージをカスタマイズする」のが常識であった。しかし現在、世界のベストプラクティスとして設計されたERPの標準機能に、自社業務を合わせることが強く推奨されている。
この思想的転換の背景には、カスタマイズによる「負債」の問題がある。バージョンアップのたびにカスタマイズ部分が動かなくなる、ベンダーが機能強化しても恩恵を受けられない、社内に「属人的な魔改造」が積み上がる——これが20年にわたって繰り返されてきた「日本企業のERP悲劇」の実態である。
| コンサルタントの視点 | 「Fit to Standard」を経営に説明する際、「自社の業務が非効率だから標準に合わせる」と説明してはならない。正確には「世界中の優良企業の業務プロセスが蒸留された標準機能を採用することで、自社は競争優位を持つコア業務の革新に資源を集中できる」という説明が必要である。 |
ERPパッケージ選定は、しばしば「デモを見て直感で決める」という非科学的なプロセスで行われる。しかしそれでは、後から「なぜこのパッケージを選んだのか」という経営からの問いに答えられなくなる。選定プロセスは客観的・再現可能な形で設計されなければならない。
フェーズ | 主要タスク | アウトプット | 期間目安 |
①要件整理 | 業務要件・技術要件・非機能要件の整理 | 要件定義書（RFP基礎資料） | 2〜3週 |
②RFP作成 | 要件を評価基準に変換・ベンダーへの質問票作成 | RFP（提案依頼書） | 1〜2週 |
③ベンダー選定 | 候補ベンダーを3〜4社に絞込み | ロングリスト→ショートリスト | 1週 |
④提案受領 | 各ベンダーからの提案書受領・初期スコアリング | 提案書・スコアシート | 2〜3週 |
⑤デモ評価 | 業務シナリオベースのデモを実施・スコアリング | デモ評価スコアシート | 2〜3週 |
⑥参照顧客訪問 | 同業他社の導入事例ヒアリング | 参照顧客報告書 | 1〜2週 |
⑦最終評価・経営決裁 | 総合スコア集計・TCO試算・意思決定 | 選定報告書・経営決裁 | 1〜2週 |
要件整理において最も犯しやすい過ちは、現行業務をそのまま要件として記述することである。「現在Excelで行っているXXXをシステム化したい」という要件は、Fit to Standardの観点から見ると誤りである。正しい要件定義は「この業務で達成したいアウトカム（成果）は何か」を起点に記述されなければならない。
要件は以下の3層に分類して整理することを推奨する。
要件レイヤー | 内容 | 記述例 |
業務要件 | 業務として達成すべきアウトカム | 月次決算を5営業日以内に完了する |
機能要件 | そのために必要なシステム機能 | 多通貨の自動換算・連結仕訳の自動生成 |
非機能要件 | パフォーマンス・セキュリティ・可用性 | オンラインバックアップ・SLA99.9%以上 |
評価基準は「重みづけスコアリング方式」で設計する。単に○×をつけるのではなく、各評価項目に重要度ウェイトを設定し、総合点で比較する方式である。重みづけは経営の優先課題と整合させることが重要であり、この作業に経営層を巻き込むことでBuy-in（経営の主体的関与）を獲得できる。
評価カテゴリ | 評価項目（例） | ウェイト目安 |
機能適合性 | 業務要件カバレッジ・標準機能充足率 | 30% |
技術・将来性 | クラウド対応・API連携・AI機能ロードマップ | 20% |
導入実績 | 同業種・同規模の導入事例数・参照顧客 | 20% |
TCO（総所有コスト） | ライセンス・導入・保守・運用の5年間総コスト | 20% |
ベンダー体制 | パートナーエコシステム・サポート品質 | 10% |
| 失敗事例 | 評価委員全員が全評価項目を個別に採点したところ、評価者間のバラつきが大きく「誰の点数が正しいか」という紛糾が起きた事例がある。評価者ごとに担当カテゴリを分担し、その専門家スコアを集計する方式のほうが再現性が高い。 |
RFP（Request for Proposal：提案依頼書）は、ベンダーに対して「我々は何者で、何を求めており、どのように評価するか」を伝える公式文書である。質の高いRFPはベンダーの質の高い提案を引き出し、質の低いRFPは「当社パッケージで全対応可能です」という画一的な提案を量産する。
RFP標準構成 |
①会社概要・プロジェクト背景（なぜERPを導入するのか） |
②プロジェクトスコープ（対象業務・対象組織・対象拠点） |
③業務要件・機能要件（業務別の詳細要件リスト） |
④非機能要件（性能・セキュリティ・可用性・保守性） |
⑤導入体制・スケジュール要件（We側・ベンダー側それぞれへの期待） |
⑥評価基準・選定スケジュール（RFP回答期限・デモ日程） |
⑦提案フォーマット（TCO内訳・体制図・参照顧客リストを必須化） |
機能要件の記述粒度が粗すぎると、ベンダーは「標準機能で対応可能」と回答し、実際のデモで「それは追加開発が必要です」という事態が多発する。逆に粒度が細かすぎると、ベンダーの標準的な強みが見えなくなる。
推奨するアプローチは「業務シナリオ型の要件記述」である。「製品ごとの価格設定が可能であること」ではなく「顧客ごと・数量段階ごとに価格が設定でき、受注時に自動適用されること（シナリオ：A社向け、1〜100個は1,000円/個、101個以上は900円/個）」のように、具体的な業務シナリオとともに記述する。これにより、ベンダーは「どの機能でどう対応するか」を具体的に示さざるを得なくなる。
RFPにはTCO（Total Cost of Ownership：総所有コスト）の内訳提示を義務づけることが不可欠である。ベンダーはライセンス費用を強調し、運用・保守コストを曖昧にする傾向がある。経営が「5年間でいくらかかるのか」を把握できない状態での意思決定は、後に「聞いていた金額と全然違う」という重大なトラブルの原因となる。
TCOコスト分類 | 内訳 | 注意点 |
ライセンス費用 | 初期ライセンス・年間サブスクリプション | ユーザー数・モジュール数で変動する |
導入費用 | コンサルティング・カスタマイズ・テスト・教育 | 固定ではなく変動要素を明確化させる |
インフラ費用 | クラウド利用料・ネットワーク・セキュリティ | データ量増加に伴うスケーリングコスト |
保守・運用費用 | バグ修正・バージョンアップ・ヘルプデスク | SLA別の費用差を明示させる |
隠れコスト | 追加ユーザーライセンス・外部I/F改修・帳票追加 | 契約外で発生しやすい要注意項目 |
ERPパッケージの評価プロセスにおいて、デモ評価は最も重要かつ最も「騙されやすい」フェーズである。ベンダーは自社パッケージが最も輝いて見えるシナリオを精巧に準備してくる。事前に用意したデータ、美しく設定されたダッシュボード、熟練したプレゼンターによる流暢な説明——これらは「このパッケージなら全て解決できる」という幻想を生み出す。
我々コンサルタントの役割は、この幻想を「こちらの業務シナリオ」で打ち破ることである。
デモ評価では「自社の業務課題を再現したシナリオ」を事前にベンダーに指定し、そのシナリオをライブで実演させることが原則である。ベンダーが事前準備したデモを「見せてもらう」のではなく、我々が指定したシナリオを「演じてもらう」のである。
デモシナリオの設計ポイント |
① 現行業務の「痛み」が最も大きいシナリオを選ぶ（例：月次締め作業・複数倉庫間の在庫移動） |
② ベンダーが苦手とすると聞いている機能を敢えて含める（競合情報を活用） |
③ 「標準機能でどこまで対応できるか」「追加開発が必要な部分はどこか」を明確に答えさせる |
④ データは自社の実データに近いサンプルを用意し、ベンダーのデモデータを使わせない |
⑤ 評価者（業務担当者）が自分でシステムを操作する「ハンズオン評価」の時間を設ける |
デモ評価の致命的な失敗パターンの一つが「IT部門だけで評価する」ことである。実際にシステムを日々使うのは現場の業務担当者であり、彼らが「使えるか・使えないか」を評価しなければ意味がない。理想的な評価チームは以下の構成が望ましい。
評価者 | 役割 | 期待する評価視点 |
業務部門リーダー（課長〜部長） | 総合評価の責任者 | 業務課題の解決度・現場のユーザビリティ |
業務担当者（スーパーユーザー候補） | 実務的な操作評価 | 日常操作の直感性・帳票・承認フロー |
IT部門（インフラ担当） | 技術評価 | 連携方式・セキュリティ・バックアップ体制 |
財務・経理担当 | 財務系機能評価 | 仕訳自動化・決算処理・連結対応 |
コンサルタント | 総合ファシリテーション | ベンダー回答の妥当性チェック・技術的正確性確認 |
ERPパッケージを選定したら、次に「どのように導入するか」という導入方式を決定しなければならない。これは単なる技術的決定ではなく、リスク・コスト・スピードのトレードオフに関わる経営的決定である。
導入方式 | 概要 | メリット | デメリット | 適合するケース |
ビッグバン導入 | 全業務・全拠点を同時にカットオーバー | シナジー最大・期間最短 | リスク集中・失敗時の影響大 | 業務が単純・小規模 |
フェーズ導入 | 業務領域・拠点を段階的に導入 | リスク分散・学習機会 | 期間長・移行コスト増 | 複雑業務・大規模企業 |
パイロット導入 | 特定拠点でまず導入し横展開 | テンプレート検証・リスク局所化 | 全社反映まで時間を要する | 多拠点グローバル企業 |
グローバルテンプレート | 本社でテンプレートを作り海外へ展開 | 統一性・ガバナンス確保 | 各国ローカライズの手間 | グローバル統一基準が目標 |
「クラウドにすべきかオンプレミスにすべきか」という問いは、2026年の現在においては多くのケースで答えが出ている。大手ERPベンダーはいずれも「クラウドファースト」を明確に打ち出しており、SAP S/4HANAにおいてはオンプレミス版（RISE with SAPのPCE含む）よりもSaaS版（Public Cloud）へのシフトが加速している。
しかし、以下のような事情を持つ企業は依然としてオンプレミス（またはプライベートクラウド）を選択する合理性がある。
機密情報の外部保存が法規制または業界規制で制限されている（防衛産業・医療・インフラ等）
既存ホストシステムとのリアルタイム連携が不可欠で、クラウド型の遅延が業務に支障をきたす
高度なカスタマイズがすでに行われており、標準クラウドへの移行コストが著しく高い
ERPパッケージを選んだからといって、それを導入する「実装力」が保証されるわけではない。導入パートナー（SIer・コンサルティングファーム）の選定は、パッケージ選定と同等以上に重要な意思決定である。
導入パートナー選定において、我々が必ず確認すべき点は以下の通りである。
導入パートナー評価の必須確認事項 |
① 同業種・同規模のSAP S/4HANA導入実績（件数・期間・スコープ） |
② 本プロジェクトにアサイン予定のメンバー（プロジェクトマネージャー・業務コンサルタント・技術コンサルタント）の個人経験値 |
③ プロジェクト途中での要員交代に関する契約上の制約 |
④ オフショアリングの比率と現地デリバリー品質の担保方法 |
⑤ 参照顧客（Reference Customer）への直接ヒアリング機会の提供 |
| 失敗事例 | 提案時の体制表には「Partner Level」のコンサルタントが並んでいたが、契約締結後に実際にアサインされたのは未経験に近いジュニアメンバーばかりだった——これは複数のクライアントで報告されている。提案時の体制表をそのまま信じてはならない。「誰がどのフェーズで何ヶ月稼働するか」を契約書に明記させることが不可欠である。 |
ERPパッケージ選定の最終的な意思決定者は経営陣である。彼らはテクノロジーの専門家ではないが、「投資の質」を判断する最高責任者である。経営に対してパッケージ選定結論を提示する際、コンサルタントは少なくとも以下の3つの問いに明確に答えられなければならない。
問い | 経営が知りたいこと | 回答に必要な根拠 |
なぜこのパッケージか | 他のパッケージではなくこれを選ぶ根拠 | 評価スコアシート・デモ評価結果・参照顧客報告 |
いくらかかるのか | 投資総額と回収見込み | TCO5年間試算・ROIシミュレーション |
うまくいくのか | リスクとその対処策 | リスク一覧・導入パートナー体制・過去実績 |
ROIを試算する際、効果の多くが「定性的」であることが問題となる。「意思決定スピードの向上」「属人業務の排除」は重要な価値だが、金額換算が難しい。そこでコンサルタントは、定量化できる効果——月次決算の短縮による残業削減時間、在庫削減による在庫金利の低減、発注業務自動化による人件費削減——を先に積算し、そこに定性効果を「プラスα」として添える構成を取るべきである。
「全て定量化しないとROIが証明できない」と考えるのは誤りである。経営は「こういった定性的価値もある」という説明で十分に判断できる。むしろ過度に精緻なROI試算を行うと「その数字の根拠は何か」という技術的議論に陥り、本質的な経営判断の場が失われる。
最後に、ERPパッケージの選定・導入は「システムが稼働すること」がゴールではない。ERPが真に機能を発揮するのは、現場がシステムを正しく使い、データの品質が担保され、経営がリアルタイムデータに基づいて判断できるようになったときである。
我々は構想策定フェーズにおいて、すでに「成功の定義（Definition of Done）」を経営と合意しておくべきである。「3年後、月次決算が3営業日で完了し、全社在庫の可視化が実現し、グループ連結をシステム自動化している状態」——このような具体的な将来像を描くことが、ERPパッケージ選定という「最初の賭け」を、単なる賭けではなく「戦略的投資」に昇華させることに他ならないのである。
以上