ERPシステム選定：中堅製造業の事例

このケーススタディは、中堅の製造業が12週間でERPを選定し、120万ドルの不要な支出を回避した経緯を示します。選定を始めようとしている、あるいは行き詰まっているCFO、COO、CIOに向けた内容です。違いを生んだのは5つのことでした。デモより先にプロセスマップを作りました。すべてのベンダーが、クライアント自身のデータで、同じ台本のシナリオを実演しました。5年間の総所有コスト（TCO）モデルが、価格表が隠していたコストを明らかにしました。経営幹部が別々に採点して、偏りを浮かび上がらせました。そして取締役会には、1枚の意思決定資料を示しました。削減は、ベンダーの値引きではなく、事業が必要としていないスコープを削ったことから生まれました。これから始めるなら、まず中核プロセスをマップにしてください。

ERPアドバイザリーに25年携わり、たいていのことは見てきたつもりでした。そんなとき、ポーランドの中堅製造業が、誤ったシステムにほぼ承認を出しかけていました。120万ドルの失敗になりかねない状況です。経営陣は、ベンダーの営業手法、社内の政治、そして願望リストに膨らんだ要件リストに圧倒されていました。

そこで私が呼ばれました。選定プロセスを単純にし、体系的な評価基準を導入し、経営陣に本当の課題は何かを尋ねました。また、ERP選定は機能の品評会ではなく、ガバナンスとリスクの判断であることも、あらためて伝えました。

結果は次のとおりです。12週間での自信を持った選択、120万ドルの不要な支出の回避、そして、ためらいではなく明確な見通しを持って導入に入った取締役会です。

1. 01ベンダーが触れない要件連携、ロックイン、準備状況、拠点間の違い
2. 02台本つきのデモ日同じワークフロー、クライアント自身のデータ
3. 03五年間のコストモデル三年目以降に50万ドルの増加が判明
4. 04別々の採点CIO、CFO、COOが別々に採点
5. 05一枚の取締役会資料取締役会は45分で合意

十二週間でERPを選定し、不要な支出120万ドルを回避

この会社の売上高は4億ドル弱でした。財務、倉庫、生産はそれぞれ別のプラットフォームで動いており、連携はほとんどありませんでした。レポートは遅く、信頼性に欠け、各部門は業務を回すために手作業の回避策を作り込んでいました。取締役会の立場は明確でした。もう1年は待てない、というものです。

経営陣と時間を過ごすうちに浮かび上がった圧力は、次のとおりです。

1. CIO：クラウド機能と長期的な拡張性を推進
2. CFO：コスト管理を強く求め、再びの予算超過を懸念
3. COO：運用の安定を最優先とし、生産への支障を懸念
4. ベンダー：四半期末の値引きや「期間限定」のオファーで決断を迫る

どの優先事項も、単独では筋が通っていました。ところが合わさると、膠着状態を生みました。確かな数字を持つ人はおらず、判断を動かしていたのは、裏づけとなるコストモデルのないベンダーのスライド資料でした。

現場は疲れ切っていました。評価の枠組みがないまま、週に3、4回のデモが入る週もありました。ある管理職は、どの製品にどの機能があったのか、もう覚えていないと、静かに打ち明けました。判断疲れが広がり、とにかくどれかに決めてしまいたいという誘惑は、現実のものでした。

次の表は、選定でよくある問題と、それぞれの対処法です。

よくある問題	影響	対処法
いきなりベンダーのデモに入る	チームが機能に気を取られ、プロセスへの適合が無視される	まず業務フローを文書化し、自社のデータでデモを行う
経営陣の要件が不明確	優先事項の衝突で判断が止まり、スコープが広がる	必須要件と推奨要件のリストを、経営陣の承認つきで確定する
5年間のコストモデルがない	隠れたコストが稼働後に表面化する	ライセンス、年次の値上げ条項、連携、サポートを含むTCOの全体像を作る
連携の盲点	後から見つかったインターフェースが遅延と超過を招く	すべてのシステムを早期にマップし、リスクの高いインターフェースはPoCで検証する
政治と偏り	判断が事実ではなく意見に基づく	重み付けしたスコアカードと、役割別の基準を使う

フェーズ1：ベンダーが決して尋ねない要件

多くの選定は、モジュールと機能に集中します。私は、連携が最も重要になる箇所を見ました。レガシーシステムは、一夜で消えてはくれないからです。ベンダーロックインも取り上げました。どの営業チームも最初のスライドには載せない、違約金や将来の移行コストです。さらに、組織の準備状況も確認しました。

ワークショップで、生産拠点ごとに在庫管理のやり方が違うことが分かりました。原材料をスプレッドシートで管理している拠点もあれば、ローカルのデータベースを使っている拠点もありました。この差だけでも、カットオーバーの危機になりかねません。早い段階で指摘したことで、経営陣は、システム選定がプロセスの統一と一体で進められなければならないことを理解しました。これは、私がどこでも適用している原則と同じです。まずプロセス、次にシステムです。

フェーズ2：実データを使った台本つきのデモ日

ベンダーは、得意なところを見せたがり、それが弱点を隠します。私は、台本つきのデモ日を設計しました。すべてのベンダーが、受注から入金まで（order-to-cash）と生産計画という同じ中核ワークフローを、クライアント自身のデータで、同じ順序で実演します。都合のよいシナリオの選り好みは認めませんでした。

ベンダーの中には、こうしたやり方は珍しいと反発するところもありました。私は譲りませんでした。クライアントは並べて比較することで、パンフレットが隠していた違いを目にしました。

フェーズ3：隠れたコストを表に出す

価格表は人を惑わせます。私は5年間のTCOモデルを作りました。そこには、料金を静かに押し上げる年次の値上げ条項や、本来の業務から外れた要員の穴埋めにかかるコストも含めました。ハイパーケアのサポートも対象にしました。これは、ベンダーが最初に見積もった額の2〜3倍かかることが多いものです。

ある「中位」の選択肢は、3年目以降に、隠れた50万ドルの増加を示しました。このモデルがなければ、クライアントは表向きの価格でそれを選んでいたでしょう。この作業1つだけで、私の起用は元が取れました。

フェーズ4：社内の偏りを中和する

データがあっても、偏りは入り込みます。CIOはクラウドファーストのベンダーに、CFOは初期価格が最も低いところに、COOは安定性に傾いていました。私は、それぞれと別々に、構造化した採点セッションを行い、その結果を比べて、個人の好みが事実を上回っていた箇所を示しました。構造化した採点があれば、根拠なしに「こちらのほうがしっくりくる」と言うことは難しくなります。

フェーズ5：取締役会の合意形成

すべてを、1枚のエグゼクティブダッシュボードにまとめました。スコアカード、コストのレンジ、リスクのヒートマップです。専門用語も、長い報告書もありません。取締役会での議論は1時間もかからず、経営陣は45分で意見が揃いました。彼らが自信を持って会議を後にしたのは、データが増えたからではなく、データが構造化され、透明だったからです。

次の表は、選定の手順を順番に並べ、それぞれが何を生んだかを示します。

ステップ	目的	成果
事業目標を定める	ERPが解決すべきこと（コスト管理、コンプライアンス、拡張性）で合意する	経営陣と現場が目標で一致する
現行プロセスをマップする	ワークフロー、課題、依存関係を文書化する	適合度を判断する基準線ができる
ベンダーを絞り込む	現実的な選択肢に絞る	関連性のある候補に評価を集中できる
フィットギャップ分析を行う	各選択肢を事業ニーズと比較する	カスタマイズ、リスク、連携のギャップが明確になる
総所有コストをモデル化する	ライセンス、導入、トレーニング、5年間のサポート	予算編成と取締役会の承認に向けた財務上の明確さ
リファレンスを確認する	同じERPを使う同業他社の担当者と話す	ベンダーの実績を直接知ることができる

1. ERPを12週間で選定しました
2. 業務上の価値がないモジュールを外し、割高なプレミアムバンドルを断ることで、120万ドルの不要な支出を回避しました。値引きを追いかけたからではありません
3. 判断疲れが解消し、経営陣は足並みを揃えて、合意した期待値を持ってキックオフに入りました
4. ベンダーの四半期末の期限は意味を失い、クライアントは自社の条件で購入しました

「Noelは、ERPを選ぶ手伝いをしてくれただけではありません。政治を切り抜け、隠れたコストを見抜き、取締役会レベルの決定を明確な根拠をもって下すための方法を与えてくれました。12週間で100万ドル以上を節約し、10年続く過ちを避けることができました」（ポーランドの製造グループのCFO）

このコストモデルは、この案件で最も価値のある成果物でした。次に、モデルがカバーした項目と、特に見落とされやすい点を示します。

コスト項目	含めるもの	見落とされやすい点
ソフトウェア	現在と将来のユーザー数、拠点数に対応するライセンスまたはサブスクリプション	ユーザー数の増加と、1年目以降の値上げ
導入	パートナー費用、社内プロジェクトチーム、予備費	本来の業務から外れた要員の穴埋め費用
連携	残すシステムとのインターフェース、ミドルウェア、テスト	プロジェクトの後半で見つかるインターフェース
データ移行	クレンジング、模擬ロード、照合	レガシーデータの品質改善作業
トレーニングと変更管理	トレーニングの設計、実施、現場サポート	ハイパーケア中の再研修
ハイパーケアとサポート	本稼働後のサポートと運用体制	ベンダーの最初の見積もりを超えるハイパーケアの範囲
終了と更新	更新条件、データのエクスポート、移行コスト	更新時に条件が変わった場合のロックインのコスト

同じ話の契約面については、私のCFO向けERP契約交渉ガイドをご覧ください。

2026年に選定する中堅製造業にとって、変わる点が3つあります。

SAP GROWが候補に入ります。 SAP GROWは、SAPのパブリッククラウドERPを基盤とし、SAPを初めて導入する企業にとって、NetSuite、Dynamics 365 Business Central、Inforと同じ土俵で語られるようになりました。固定スコープのGROW Fastは、数か月での本稼働を目指しており、クリーンコアは設計上担保されます。TCOモデルでは、永久ライセンスと保守ではなく、5年間のサブスクリプションの伸びを比べる必要があります。

AIが速くするのは書類仕事であり、判断ではありません。 AIアシスタントは今や、要件のサマリー、採点の枠組み、最初のフィットギャップ分析のたたき台を作成できます。どのベンダーが事業に本当に合うかは、今も経験豊富な人間が下す判断です。

クラウドが標準です。 かつては、中堅製造業の一部がクラウドとオンプレミスを天秤にかけていました。2026年の現実的な標準はクラウドであり、データ所在地や主権に関する規則がそうでないと定めている場合を除きます。ベンダーごとにオンプレミスのシナリオを作るのではなく、TCOの中でクラウドの選択肢どうしを正面から比べてください。

台本つきのデモ日、隠れたコストを洗い出すTCO、別々の採点、1枚の取締役会資料は、候補に何が入っていても、今もそのまま当てはまります。ベンダーについては、製造業向けのおすすめERPのガイドで、より詳しく取り上げています。

判断を急がないでください。急いで決めると、隠れたコストや連携のリスクを見逃します。スライド資料ではなく、5〜7年先まで見通せる確かな数字を手に入れてください。経営陣内の優先事項は、立場が固まる前の早い段階で、構造化したセッションで調整します。基準を標準化し、参加者を交代させて、現場をデモ疲れから守ってください。そして、取締役会には短い節目の報告を続け、終盤になって驚くことがないようにします。候補にSAPとOracleが入っているなら、私のSAPとOracleの比較で、トレードオフを整理しています。

中堅製造業は、デモに振り回されずにERP選定を始めるには、どうすればよいですか？

ベンダーのデモからは始めません。まず、中核となるプロセスをマップします。受注から入金まで、生産スケジューリング、在庫管理、サプライヤーへの支払いです。それらが文書化されて合意されたら、各システムがどう支えるかを評価します。洗練されたデモに何週間も費やし、見たものの半分は自社の業務と無関係だったと気づくチームを、私は見てきました。プロセスのマッピングを先にすると、たいてい評価は短くなり、政治色も薄れます。

ERPの5年間の総所有コスト（TCO）モデルには、何を含めるべきですか？

ユーザー増加を見込んだライセンスまたはサブスクリプション、保守と値上げ条項、導入、連携、データ移行、テスト、ハイパーケア、そして本来の業務から外れた社内要員の穴埋めです。ある事例では、チームがライセンス料だけでシステムを承認し、2年目には予算が倍になっていたことに気づきました。このモデルがあれば、値上げや更新の話を、約束してしまう前に持ち出さざるを得なくなります。

ベンダーのデモを、本当に比較できるものにするには？

同一のシナリオを、自社のデータで台本にします。すべてのベンダーが、受注から入金まで、生産計画、返品といった同じワークフローを、同じ順序と同じ時間で実演します。採点は、プレゼンの出来ではなく、自社の優先事項で重み付けします。ある製造業のチームは、ベンダーに、クレジットの発行を伴う複雑な返品を処理させました。そのテスト1つで、洗練されたデモが隠していた違いが露わになりました。

ERPの決定を承認する前に、取締役会は、どのようなリスクを見るべきですか？

データ移行の失敗、残すシステムとの連携のギャップ、拠点間でのプロセス定着のばらつき、そしてアップグレードや更新の時期に響いてくるベンダーロックインです。発生確率と影響度を示した1枚のリスクヒートマップがあると、たいてい議論が変わります。それがなければ、経営陣はERPをライセンスとスケジュールだけの話だと思い込むからです。軽減できるリスクもあれば、承知のうえで受け入れるべきリスクもあります。

ERP選定中のスコープクリープは、どう防げますか？

必須要件とオプションの要件を分け、すべての機能を測定可能な事業成果に結びつけます。正式な変更プロセスも設けます。新しい要件は、リスクの低減か財務上のリターンを示さなければなりません。タイムラインが倍になるまで、すべての要望を承認し続けたチームを、私は見てきました。機能が1つ増えるたびに、本稼働の準備状況と競合します。経営陣は、そのことを一貫して言い続けなければなりません。

ベンダーからの圧力や、四半期末の値引きには、どう対処しますか？

期限の短い値引きは、節約ではなく、圧力の手法として扱います。本当の節約は、不要なモジュールを外し、過剰なライセンスに異議を唱えることから生まれます。機能の半分が使われないなら、10%の値引きは魅力が薄れます。このケースでは、決定を遅らせても、利用できる条件は変わりませんでした。ベンダーは、購入を決めた買い手を手放すことは、まずないからです。120万ドルの削減は、値引きではなく、スコープから生まれました。