Gartnerの予測によると、2027年までに最近実装されたERP施策の70%以上が、当初のビジネス目標を完全には達成できない見込みです。Panorama Consultingの2026年ERPレポートでは、25%以上の組織が予算を超過したことが判明しました。Godlanによる2026年の分析(Inforのパートナーであるため、参考値として扱ってください)では、製造業のERP失敗率は73%、平均超過率は215%とされています。
港湾、ヤード、鉱山、あるいは現場主導のオペレーションを運営している方なら、これらの数字はむしろ控えめに感じるはずです。この失敗率はプロジェクト管理の問題ではありません。構造的な問題です。事後に現場へ足を運ぶと、毎回同じ5つの問題が、同じ順序で発生しています。
要点
- Gartner:2027年までに、最近のERPプロジェクトの70%以上が当初のビジネス目標を達成できない。
- Panorama:ERP導入の25%以上が、追加の技術ニーズにより予算を超過。
- Godlan:個別受注生産型製造業のERPプロジェクトの73%が目標未達、コスト超過率は215%。
- 産業系プロジェクトで繰り返される5つの失敗パターン:テンプレートの不一致、OT統合の負債、導入の壁、パイロットから本番への移行不全、サンクコストによるロックイン。
- Hershey(1億ドル分の未処理注文)、Lidl(5億ユーロの償却)、Revlon(第1四半期6,400万ドルの未達)が、このパターンが大規模に現れた例です。
- オペレーション実態の約60%はシステム外に存在し、無線、WhatsApp、シフト引き継ぎメモなど、ERPが決して把握できない場所にあります。
ERP導入失敗に関する統計スナップショット
以下のセクションに記載するすべての数字には出典があります。この表は、すぐに参照できるよう主要な根拠を一箇所にまとめたものです。
| 出典 | 主な調査結果 |
|---|---|
| Gartner | 2027年までに、最近実装されたERP施策の70%以上が当初のビジネス目標を達成できない |
| Panorama Consulting 2026 | ERPプロジェクトの25%以上が、追加の技術ニーズにより予算を超過 |
| Godlan 2026 | 製造業のERPプロジェクトの73%が目標未達、平均コスト超過率215% |
| CIOによるHersheyの事例 | SAP導入を急いだ結果、1999年のハロウィン向け注文の約1億ドル分が未処理となった |
| HandelsblattによるLidlの事例 | 7年にわたるSAP導入が失敗に終わり、約5億ユーロが償却されたと報じられている |
| DolfingによるRevlonの事例 | SAP移行後、2018年第1四半期に6,400万ドル分の注文が処理不能に |
| Revlon 2018年10-K | 年次報告書にて、2018年通期の純損失2億9,420万ドルを開示 |
上記で参照した一次情報源:
ERPプロジェクトが産業系オペレーションで失敗する5つの理由
繰り返し現れるパターンは5つあります。オペレーションやベンダーによって、さまざまな組み合わせで現れます。私がこれまでレビューしてきた失敗事例は、いずれも少なくとも3つのパターンに当てはまります。以下、それぞれのパターンを個別のセクションで解説します。
1. 汎用テンプレートによるスコープクリープ
主要なERPはいずれも、プロセステンプレートの上に構築されています。発注書をモデル化する標準的な方法があり、標準的な作業指示があります。標準的な在庫レコードもあります。これらのテンプレートは、できるだけ広範な顧客層に対応できるよう設計されています。
そのフィット感は、フリーサイズの服が実際の人間の体型に合う程度でしかありません。
導入チームは、顧客のプロセスをテンプレートに当てはめます。適合しない箇所では、システムをカスタマイズするか、プロセスを変更するかの選択を迫られます。カスタマイズは高コストであり、恒久的な技術的負債を生みます。プロセスの変更は、オペレーターに今までとは違うやり方を求めることになります。
実際には、両方が同時に起こります。カスタマイズをカバーするためにスコープが拡大します。それでもオペレーターには適応するよう求められます。稼働開始前の段階で、構築コストは大きく膨らみます。結果として出来上がるのは、きれいなテンプレートでもなければ、ワークフローを忠実に再現したものでもありません。
オーダーメイド・ソフトウェアは、ベンダーのテンプレートではなく、あなたのワークフローを起点にします。オペレーションの実際の動き方とシステムが想定する動き方との間に、翻訳レイヤーは存在しません。
2. OT統合の負債
オペレーショナルテクノロジーとは、SCADA、PLC、MES、テレマティクス、センサーネットワークを指します。これらは物理的なオペレーションを動かしていますが、ERPの言葉を話しません。
ERPシステムは、取引、記録、承認といったビジネスデータ向けに構築されています。OTはリアルタイムの信号を、ほとんどのERPデータモデルが元々処理するようには設計されていない量で生成します。
一般的な解決策はコネクタです。ミドルウェアがOT信号をERPフレンドリーなレコードに変換し、コネクタはデモでは機能します。しかし本番環境では、それ自体が数年がかりのメンテナンスプロジェクトと化してしまいます。
あるPLCのファームウェア向けに構築されたコネクタは、そのPLCが更新されると壊れます。毎秒100イベント向けにチューニングされたものは、10,000イベントには耐えられません。6か月の予定だった統合の積み残しは、2年経ってもまだ片付いていません。オペレーションチームは、接続されたシステムが接続状態にあるのは全体の約60%に過ぎないため、スプレッドシートによる並行プロセスを運用しています。
私はこのパターンを、港湾やヤードの現場で目にしてきました。コネクタが悪いソフトウェアというわけではありません。その問題に対しては、そもそもアーキテクチャが間違っているのです。
オーダーメイド・ソフトウェアは、OTを後付けのミドルウェアとしてではなく、初日から第一級の要件として扱います。統合レイヤーがSCADA、PLC、テレマティクスをネイティブなデータストリームとして扱えば、蓄積していくコネクタの負債は存在しません。
3. 導入の壁
導入の壁が立ちはだかるのは、システムを日常的に使う人たち、ターミナルオペレーター、シフト監督者、ディスパッチャー、保守クルーが、それを学ぶよりも無視した方が生産性が高いと判断したときです。
これは非合理的な反応ではありません。一度もシフトを回したことのないプロジェクトチームが会議室で設計したシステムに対する、合理的な反応なのです。
この壁は、稼働開始から90日以内に現れます。プロジェクトチームはすでにいません。オペレーションチームは、重要な意思決定についてはWhatsApp、無線、スプレッドシートに戻ります。ERPは、財務部門が求めるレポートのためだけに使われるようになります。
システムオブレコードが、コンプライアンスのためのシステムになってしまう。
導入は研修の問題ではない。悪いワークフローに研修を重ねても、悪いワークフローに研修を重ねているに過ぎない。導入は設計の問題だ。そのシステムを実際に使うことになる人たちは、ワークフローが設計される場にいなかった。
オーダーメイド・ソフトウェアは、現場を学ぶことで作られる。シフトを回している人たちと共に座り、実際の例外やエッジケースをマッピングし、彼らがすでに知っているやり方を軸にワークフローを組み立てる。
その結果、現場の仕事に合ったシステムができ、オペレーターは実際にそれを使うようになる。ライブオペレーションビューが現場そのものに見えるのは、それが現場から作られたからだ。
4. パイロットから本番への脱落
ERPのパイロットは成功する。概念実証は、クリーンで精査されたデータと、少人数のコーチングを受けたユーザーグループで動く。実装チームが対処方法を熟知している、限定された業務範囲だ。
経営スポンサーはデモを見る。プロジェクトはゴーサインを得て、全面展開が始まる。
本番環境はまったく別物だ。移行前に完全にはクリーニングされなかった、雑然としたレガシーデータがある。パイロットでは一度も触れられなかったエッジケースがある。標準外のBOL形式を使うキャリア。対象外のシステムにメンテナンス履歴がある機材。昔からずっとそうだからという理由で、無線とWhatsAppで行われるシフト引き継ぎ。
クリーンなパイロット環境とライブの本番環境は、同じ場所ではない。
この脱落は、単独のデータ問題ではない。現実を単純化したバージョンでパイロットを行い、システムを調整しないまま完全版に展開したときに起こることだ。
オーダーメイド・ソフトウェアは、オフシステムのデータも含め、現場が実際にどう動くかに照らして検証される。ステータスキャプチャレイヤーは、構造化された連携経由で届くものだけでなく、無線、WhatsApp、メール経由で入ってくるものも処理する。本番環境こそが設計環境なのだ。
5. サンクコストによるロックイン
産業組織がERPのライセンス、コンサルティング、カスタマイズにいったん200万から500万ドルを費やすと、撤退は政治的に不可能になる。
CFOはその金額を承認した。取締役会はプレゼンテーションを見た。早期に懸念を示したオペレーターたちは却下された。システムが成果を出さないことが明らかになる頃には、組織はすでに18ヶ月を費やしている。
誰も、その投資を評価損として処理するメモに署名する人間にはなりたくない。
そこで組織はさらに踏み込み、カスタマイズを重ねる。コンサルティングを重ね、チェンジマネジメントを重ねる。総コストは膨らみ、稼働開始は遅れる。最終的にリリースされるシステムは、誰も置き換える権限を持たない妥協の産物だ。
私は、オペレーションチームが何年もパラレルシステムを運用しているのを見てきた。コンプライアンスのためのERP。重要なことのためのWhatsAppとスプレッドシート。
オーダーメイド・ソフトウェアは、このリスクモデルを逆転させる。システムが機能するかどうかを知る前に200万ドルを費やす必要はない。あなたのデータの上で、あなたが選んだ課題に対する、実際に動く本物のソリューションを見て、それが自らの居場所を勝ち取ったときにだけ支払う。最初のリスクはこちらが負う。
ERPの失敗が大規模に展開するとどうなるか
次の3つのケースは、記録に残る失敗であり、実数だ。実名の組織。それぞれが上記のパターンの1つ以上に当てはまる。
ハーシー、1999年。ハーシーは1999年夏、SAP、Manugistics、Siebelの同時稼働開始を行った。計画はハロウィンに間に合わせるため約6ヶ月圧縮された。ハロウィンの注文が殺到する中でシステムは稼働開始した。約1億ドル相当のキスチョコとジョリーランチャーを期日通りに出荷できなかった。ハーシー株は1日で約8%下落した。原因は、1億ドル規模でのパイロットから本番への脱落だった。
リドル、2018年。約7年間、推定5億ユーロの支出の末、リドルはSAP導入を断念した。Handelsblattの報道によれば、根本的な問題はデータモデルの不一致だった。SAPの標準的な小売在庫モデルは小売価格をベースに動く。リドルの業務は仕入価格をベースに動く。リドルはプロセスを変えることを拒み、代わりにSAPがカスタマイズされた。そのカスタマイズは何年も続いたが価値を生まなかった。報じられた数字について、リドルもSAPも公式には確認していない。5億ユーロ規模での、汎用テンプレートからのスコープクリープだ。
レブロン、2018年。レブロンのノースカロライナ州オックスフォード工場でのSAP移行は、第1四半期の出荷を混乱させた。同社は第1四半期だけで推定6,400万ドル相当の注文を履行できなかった。この数字は、業績開示から作成された投資家集団訴訟の申し立てで浮上したものだ。レブロンは年次10-Kで2018年通年の純損失2億9,420万ドルを報告した。この6,400万ドルという数字は、LinkedIn上でしばしば、その後のレブロンの破産につながった30億ドルの債務負担と混同されている。これらは別の出来事だ。2018年のERP失敗は、OT連携と本番準備態勢の失敗だった。
共通するのは、これらがいずれも技術の問題ではなかったという点だ。それらはアーキテクチャと検証の問題だった。どの組織も、管理された環境では機能したが、実際のオペレーションの下では破綻するシステムを展開した。
第三の道
上記の失敗リストに対する明白な対応は2つある。
1つ目は自社で構築し、エンジニアリングチームを雇うことだ。要件をゼロから明確化する。現場に正確に合ったソフトウェアを構築し、それはときには機能する。ただし、複数年に及ぶエンジニアリングの取り組み、ほとんどのオペレーターが持っていない技術的リーダーシップ、そして構築したものを維持するための継続的な投資が必要になる。
あなたの本業が港やヤード、鉱山を運営することであるなら、社内でソフトウェアを構築するのは本業からの逸脱だ。
2つ目は、より優れたERPやより専門特化した垂直型SaaSを購入し、導入プロジェクトをより注意深く管理することだ。これは、より優れたプロジェクトガバナンスをもって同じ賭けをもう一度行っているに過ぎない。プロジェクトマネージャーの経験が豊富だからといって、構造的な問題が消えるわけではない。
第三の道は、程度の違いではなく種類の違いだ。オーダーメイド・ソフトウェア。あなたの具体的な目標のために構築され、あなたの具体的なシステムとデータに接続され、あなたの現場が実際にどう動くかに照らして検証される。そのライフサイクル全体を通じて稼働と改善が続けられる。
これは以前に取り上げた第三の道だ。失敗パターンの根本に対処するものであり、症状ではない。
Opsimaのモデルは、これを具体的な形にする。私たちは、エッジケースも含めて、現場が実際にどう動いているかを学ぶ。そのワークフローを軸に設計されたソフトウェアを構築する。それは、あなたがすでに運用しているERP、EAM、TMS、TOS、あるいはWMSと連携するのであって、それを置き換えるのではない。私たちは、システムオブレコードに決して届かないデータ、無線通話、WhatsAppのスレッド、手書きのシフトメモを扱う。それは、私が歩いてきたほとんどの現場において、業務の現実の約60%に相当する。
その後、私たちは稼働を開始し、実際の本番の挙動に照らして検証し、現場の変化に合わせてシステムを稼働させ、改善し続ける。
Opsimaは産業オペレーション向けAIネイティブ・ソフトウェア・ファクトリーです。あなたのオペレーションが実際に稼働するCMMS、TMS、TOS、EAM、ERP、設備モニタリング、文書処理ソフトウェアを、あなたのオペレーションの動き方に合わせてオーダーメイドで構築します。
2つのサービスモードがあります。（1）既存スタック（SAP、Maximo、MainPac、Navis、Priority、JDE、AS400）の上にオーダーメイドで重ね合わせ、リプレースはゼロ。または（2）レガシーシステムが限界を超えた場合は、ゼロから代替システムを構築します。数週間で出荷。価値を確認してから初めて対価を支払います。
この商業モデルは、リスクの逆転を反映している。システムが機能するのを見る前に、数百万ドル規模のライセンス契約にコミットする必要はない。私たちは、あなたが選んだ課題に対して、あなたのデータの上で、あなたのインフラの上で、実際に動く本物のソリューションを構築する。あなたはそれが動くのを見る。あなたの現場に照らして評価し、それから決断する。
詳細は価格ページに記載されている。要点だけ言えば、最初のリスクは私たちが負う。
ケーススタディは、これが実際にはどう機能するかを示している。その1つがPNCTだ。
うまくいった場合はどう見えるか
Port Newark Container Terminalは、100台を超えるストラドルキャリアの車両群で、年間約165万TEUを取り扱う。この車両群は24時間365日稼働する。ストラドルキャリアの稼働率が制約条件だ。1台のキャリアが停止すると、スループットが低下する。計画外のダウンタイムの1時間ごとに、実際のコストが発生する。
PNCTがOpsimaに持ち込んだ課題は、特殊なものではなかった。機材データ、メンテナンス履歴、オペレーションログが、互いに連携しないシステムに散在していた。技術者は不完全な情報のままメンテナンスの判断を下していた。故障は事前に予測されるものではなく、事後対応だった。
OpsimaはPNCTがすでに運用しているシステムに接続されたソリューションを構築した。テレメトリー、メンテナンス記録、オペレーションデータが、メンテナンスチームが実際に使えるライブオペレーションレイヤーに集約された。
結果は、ストラドルキャリア車両群の稼働率が+5%、計画外故障が約15%減少というものだった。
100台の車両群において、稼働率5%は、シフトごとにおよそ5台の追加稼働ユニットに相当する。その5台は、新規機材の購入を必要としない。新たな設備投資を必要としない。新規スタッフを必要としない。それらは、より良い情報によって既存の車両群から取り戻されたスループット能力だ。
PNCTのチームは率直にこう言った。「あなた方は単なる大手ソフトウェアベンダーではありませんでした。すでにコンセプトを持ち、やればできるという姿勢で来てくれました。」
それが、1,000社の顧客向けに構築されたシステムと、あなたのために構築されたシステムとの違いだ。
1つのスコープを絞った課題、そして1つの稼働したシステム。数年ではなく、数週間で。
ERP適合度診断、10の質問
ERP導入にコミットする前に、あるいは現行のシステムが利用可能な最善の選択肢だと受け入れる前に、次の10の質問に正直に答えてほしい。それぞれが、上記の5つの失敗パターンのいずれかに対応している。
テンプレート適合性について:
- あなたのオペレーションチームは、ERPがカスタマイズや回避策なしに設計通り処理するワークフローを説明できますか。
- 現場でプロセスが変わったとき、その変更をシステムに反映するまでにどれくらいかかりますか。数時間ですか、数週間ですか、それとも数ヶ月ですか。
OT統合について:
- SCADAとPLCのフィードは、ファーストクラスのデータとして扱われていますか。それとも主要アーキテクチャの外側でコネクタ経由で取り込まれていますか。
- 統合プロジェクトが「ほぼ完了」の状態のまま6ヶ月以上経過していませんか。
導入について:
- シフトを回している人たちは、ワークフロー設計に意味のある意見を反映できましたか。それとも設計が固まった後のUATで初めて呼ばれましたか。
- 実際にシステム内で行われているオペレーション上の意思決定は何パーセントで、無線通話やWhatsApp、スプレッドシートなど、システムの外で行われている意思決定は何パーセントですか。
パイロットから本番移行について:
- あなたのパイロットは、整理・精選されたデータセットで実施されましたか。それとも実運用データの雑然としたライブスナップショットで実施されましたか。
- 標準的なケースと同様に、例外的なケースもシステムは処理できますか。非標準のキャリア、断片的なメンテナンス履歴、無線での引き継ぎなどです。
商業的リスクについて:
- 費用を確定させる前に、自社データ上で機能するソリューションを確認しましたか。それともベンダーのデータで動くベンダーのデモを見ただけで契約を確定させましたか。
- 価格体系は、システムが自社のオペレーションに機能するかどうかに連動していますか。それともベンダーは結果にかかわらず報酬を得られますか。
3つ以上「いいえ」と答えたなら、それはERPの適合性の問題ではありません。オーダーメイド・ソフトウェアを必要としていることを示しているのです。
結論
ERP導入が産業オペレーションで失敗するのには構造的な理由があり、その理由は繰り返し現れます。
汎用テンプレートはオペレーション側に無理を強い、OT統合の負債が積み上がっていきます。オペレーションを回している人たちがワークフロー設計の場にいなければ、導入は定着しません。パイロットはきれいなデータでは成功し、本番の現実では失敗します。埋没費用のせいで、方向転換は政治的に不可能になります。
代わりとなるのは、あなたのオペレーションを中心に構築されたソフトウェアです。あなたのワークフロー、あなたのシステム、あなたのデータ。引き渡されて放置されるのではなく、そのライフサイクルを通じて稼働し続け、改善され続けます。
あなたのワークフローのために構築され、価値を実感してから初めて対価を支払うオーダーメイド・ソフトウェア。それこそ、ERPが本来目指すべきものでした。
直すことを諦めてしまったプロセスを教えてください。私たちは、あなたが選んだ課題について、あなたのデータ上で実際に機能するソリューションを構築します。それが価値を証明した場合にのみ、対価をお支払いいただきます。あなたのオペレーションを中心に構築されたオーダーメイド・ソフトウェアで次の導入のリスクを減らすには、Opsimaとのワーキングセッションを予約してください。
