世界のERPプロジェクト、カスタマイズ、システム導入の失敗事例、原因は何?

ITで知っておくべき知識
スポンサーリンク

以前、ERPとは何か?世界の代表的なERPのソフトウェアを紹介しました。

ERPとは?わかりやすく ERP企業シェアと種類 (SAP、Oracle NetSuite、ワークスアプリケーションズ)
業務系のソフトウェアとしてよく聞くERPとは何なんでしょうか? ERPとは何か?あるいは、著名なERPソフト、パッケージ、ベンダーを見てみましょう。 わかりやすく説明してみましょう。 ERP (Enterprise Resource ...

 

ERPパッケージは、コストカット、業務効率化のために大企業を中心に1990年代から盛んに導入されてきました。

ところで、ERPパッケージの導入の失敗事例については、特に日本においてあまり大きくは報道されていませんね。

一方で世界的には有名なERPの導入失敗事例があります。

 

こちらの記事に世界で有名は15個のERPの失敗事例が書かれています。

Page not found | CIO

 

最後の方の記事はほとんどの日本人には無関係なのですが、いくつかをこの記事から引用して見てみましょう。

スポンサーリンク

世界の有名なERPの災害、混乱、失望

Twenty-one percent of companies who responded to a 2015 Panorama Consulting Solutions survey characterized their most recent ERP rollout as a failure.  So there are a lot of disasters out there.

 

2015年パノラマ・コンサルティング・ソリューションの調査に回答した企業の21%が、最新のERPのロールアウトを失敗として位置づけていました。だからそこにはたくさんの災害があります。

業務の効率化をめざして、ERPやCRMのようなシステムの導入は行われてきましたが、必ずしも、すべての導入が成功する訳ではないようです。

21%が失敗したという事実の真偽はさておき、いくつかの失敗事例を見てみましょう。

 

イギリスのボーダフォン

ボーダーフォンはイギリスの携帯電話事業会社。

一時期、日本にも参入していましたが、ソフトバンクに買収されました。

When British telecom provider Vodafone consolidated its CRM systems onto a Siebel platform, they ran into problems: not all the customer accounts migrated properly. The company didn't go out of its way to advertise this, of course, but people started to notice when their accounts weren't properly credited for payments made.

 

英国のテレコムプロバイダーである、ボーダフォンがCRMシステムをシーベルのプラットフォームに統合したとき、問題に遭遇しました。すべての顧客アカウントが適切に移行された訳ではありませんでした。同社はこれを広告宣伝する方法がありませんでた、しかし、顧客は支払いが行われ時にアカウントに適切に引き落とされていないと気付きました。

データ移行のミスか?

ボーダフォンはシステム統合の失敗の結果として、英国の通信規制当局から460万ポンドの罰金を支払いました。

 

ワシントンコミュニティカレッジのシステム

One cause of delay was internal: the 34 campuses in the system had widely varying business processes that needed to be standardized, which wasn't clear until well into the rollout.

Ciber, the third-party company hired to roll out the PeopleSoft system, went bankrupt in April of this year, only to have its assets scooped up by HTC, a Michigan company — and HTC then cancelled its contract with the school system and sued for $13 million, claiming the failed rollout was due to "internal dysfunction" on the colleges' part.

 

遅れの原因の1つは内在的でした。システム内の大学の34のキャンパスには、標準化が必要なビジネスプロセスが幅広くありました。

Ciberという、ピープルソフトのシステムを展開するために採択されたサードパーティー会社が今年4月に倒産し、その資産をミシガン州の会社であるHTCによってすくい出されました。HTCは契約をキャンセルし、ロールアウトの失敗が大学側の「内部機能不全」によるものであったと主張して1300万ドルで訴えた。

これは、分かりにくいケース。

Cyberというピープルソフトの委託業者が、ワシントンコミュニティカレッジのロールアウトを展開しようとしていた。

しかし、ワシントンコミュニティカレッジのシステムはロールアウトするに十分な標準化がなされておらず、プロジェクトは遅延した。

その後、Cyberが倒産して、HTCに資産が吸収された。

HTCは契約をキャンセルして、プロジェクトの遅れの原因がワシントンコミュニティカレッジにあるとして提訴したって事かな。

 

オーストラリアのウールワース

ウールワースはオーストラリア最大の小売業者、スーパーマーケットのチェーン店です。

アメリカでいうウォルマート、日本ではイオンみたいな存在かな。

The Australian outpost of the venerable department store chain, affectionately known as "Woolies," also ran into data-related problems as it transitioned from a system built 30 years ago in-house to SAP. One of the biggest crises that arose was that profit-and-loss reports tailored for individual stores, which managers were accustomed to receiving every week, couldn't be generated for nearly 18 months.

The problem lay in the change in data collection procedures, but the root cause was a failure of the business to fully understand its own processes. The day-to-day business procedures weren't properly documented, and as senior staff left the company over the too-long six-year transition process, all that institutional knowledge was lost

 

愛称の「Woolies」と呼ばれる由緒ある百貨店チェーンのオーストラリアの前哨基地も、30年前に社内に建設されたシステムからSAPに移行したときにデータ関連の問題に遭遇しました。最大の危機の1つは、マネージャーが毎週受け取ることに慣れていた個々の店舗に合わせた損益レポートを、約18ヶ月間生成することができなかったことです。

問題はデータ収集手順の変更にありますが、根本的な原因はビジネスが自らのプロセスを完全に理解できていないことでした。日々の業務手順は適切に文書化されておらず、シニアスタッフが長年にわたり6年間もの長すぎる移行プロセスを経て退社したため、その企業の知識はすべて失われました。

SAPの導入での失敗事例。

データ移行でよくある失敗。

現場の担当者、プロジェクトマネージャーともに、ビジネスプロセスを完全に理解できていないにも関わらず、移行が完了したと錯覚してしまった事例。

ビジネスプロセスを本当に知っている人を連れて行かず、ERPの展開に専念していると失敗するっていう事例です。

 

カナダのターゲット

ターゲットは、アメリカの第5位の小売業者です。

これは、ターゲットの子会社である、カナダ ターゲットの話です。

But upon launch, the company's supply chain collapsed, and investigators quickly tracked the fault down to this supposedly fresh data, which was riddled with errors— items were tagged with incorrect dimensions, prices, manufacturers, you name it. Turns out thousands of entries were put into the system by hand by entry-level employees with no experience to help them recognize when they had been given incorrect information from manufacturers, working on crushingly tight deadlines.

 

しかし、ローンチしてすぐに、サプライチェーンが崩壊した、そして、調査した人は、間違った次元、価格、製造業者などのタグを付けられたエラーでいっぱいだった、この新鮮なデータの障害を素早く追跡した。分かったことは、経験のないエントリーレベルの従業員が、ギリギリの厳しいスケジュールの中で、製造業者からの間違った情報を、なんとか理解しようとして手でエントリーを入力したことだった。

これは、データ移行とかSAPのカスタマイズ以前の問題。

ターゲット カナダは、新規にERPを導入しようとしたので、そもそも移行するデータはない。

そのためエントリーレベルの新人が新規にデータ入力を行ったけれど、そのデータがそもそも間違っていたって事かな。

 

PG&E パシフィック・ガス・アンド・エレクトリック・カンパニー

パシフィック・ガス・アンド・エレクトリック・カンパニーは、サンフランシスコ・ベイエリアを中心とするカリフォルニア州北部地域の天然ガス、電力供給を行う企業です。

In May of 2016, Chris Vickery, risk analyst at UpGuard, discovered a publicly exposed database that appeared to be Pacific Gas and Electric's asset management system, containing details for over 47,000 PG&E computers, virtual machines, servers, and other devices — completely open to viewing, without username or password required. While PG&E initially denied that this was production data, Vickery says that it was, and was exposed as a result of an ERP rollout: a third-party vendor was given live PG&E data in order to fill a "demo" database and test how it would react in real production practice. They then failed to supply any of the protection a real production database would need.

 

UpGuardのリスクアナリスト、Chris Vickery氏は、Pacific Gas and Electricの資産管理システムであると思われる、ユーザー名やパスワードなく公開された47,000台以上のPG&Eコンピュータ、仮想マシン、サーバー、その他のデバイスの詳細が含まれたデータベースを発見しました。最初にPG&Eは、これがリリース用のデータであることを否定していましたが、Vickeryによれば、ERPのロールアウトの結果として公開されたものでした:サードパーティのベンダーがデモデータを入れてリリース時にどうなるかをテストする際にPG&Eのライブデータが割り当てられました。そうです、PG&Eは、実際の本番データベースに必要な保護を行っていなかったのです。

このケースは、OracleのERPを使ったケースのようです。

 

これは原因がよく分からない事故。

テストデータにリアルデータを入れてテストを行う。

テストではそれがうまく行く。

そして本番用のデータを用意して、本番を迎えて本番もうまく行く。

 

そして、そのまま残ったテストデータが、そのまま第三者のベンダーに使われてしまったってことか?

きっと、セールスフォースのような、SaaSのプラットフォームベンダーを使っていてデータをそのまま本番データを残しちゃったって事かな???

 

ハーシー Hershey

ハーシー社はアメリカにおいて最も古いチョコレート菓子会社の一つです。

 

ハーシーのSAPのロールアウトの失敗は有名だけど、真の理由はイマイチよく書かれているサイトはないです。

今回は以下のサイトからの引用です。

A Case Study on Hershey’s ERP Implementation Failure: The Importance of Testing and Scheduling - Pemeco Consulting
Imagine waking up one day to find out that your company's supply chain has ground to a halt, making it impossible to fulfill 0 million worth of orders. For H...

Here are the relevant facts: In 1996, Hershey’s set out to upgrade its patchwork of legacy IT systems into an integrated ERP environment. It chose SAP’s R/3 ERP software, Manugistic’s supply chain management (SCM) software and Seibel’s customer relationship management (CRM) software. Despite a recommended implementation time of 48 months, Hershey’s demanded a 30-month turnaround so that it could roll out the systems before Y2K. Based on these scheduling demands, cutover was planned for July of 1999. This go-live scheduling coincided with Hershey’s busiest periods – the time during which it would receive the bulk of its Halloween and Christmas orders. To meet the aggressive scheduling demands, Hershey’s implementation team had to cut corners on critical systems testing phases. When the systems went live in July of 1999, unforeseen issues prevented orders from flowing through the systems. As a result, Hershey’s was incapable of processing $100 million worth of Kiss and Jolly Rancher orders, even though it had most of the inventory in stock.

 

関連する事実は次のとおりです。1996年にハーシーは、レガシーITシステムのパッチワークを統合されたERP環境にアップグレードすることに着手しました。 SAPのR/3 ERPソフトウェア、Manugisticのサプライチェーン管理(SCM)ソフトウェア、シーベルのCRM (顧客関係管理) ソフトウェアを選択しました。 ハーシーは、推奨される実装時間が48ヵ月であったにもかかわらず、2000年以前にシステムを展開できるように、30ヵ月の猶予時間を要求しました。これらのスケジューリングの要求に基づいて、1999年の7月にカットオーバが計画されました。このライブスケジュールは、ハーシーの最も忙しい時期 - ハロウィーンとクリスマスの注文の大部分を受け取る時期と一致しました。切羽詰まったスケジューリングの要求を満たすために、ハーシーの実装チームは、クリティカルなシステムテストフェーズで手を抜く必要がありました。 1999年の7月にシステムが稼働したとき、予期せぬ問題によってシステム内で注文を処理することができなくなりました。その結果、ハーシーは在庫のほとんどを在庫していたにもかかわらず、1億ドル分のキスチョコとジェリーランチャーソフトキャンディーの注文を処理できませんでした。

具体的な原因は書かれていないものの、スケジュールの圧縮が間接的な原因か。

その結果として、ちゃんとしたテストが出来なかった?ってことかな。

で、1999年のハローウィーンの繁忙期前、在庫はあったにも関わらず、オーダーをさばききれなかったとか。

1999年にゴーライブ(リリース、カットオーバー) したかったのは、いわゆる2000年問題があったので、それ以前にリリースしたかったんでしょう。

 

ナイキ NIKE

ナイキは日本人にも馴染みのあるシューズメーカーですね。

 

301 Moved Permanently

からの引用です。

They implemented a new demand-planning software solution without testing it, and everything went awry. Rather than helping Nike match their supply with demand, narrowing their sneaker manufacturing cycle, they ended up ordering low-selling sneakers in place of high demand ones, collapsing the supply chain.

 

ナイキ、テストせずに新しい需要計画ソフトウェアソリューションを実装し、すべてがうまくいかなかった。 ナイキの需給を需要に合わせるのではなく、スニーカーの製造サイクルを狭めることで、需要の高いスニーカーの代わりに低価格のスニーカーを注文し、サプライチェーンを崩壊させました。

よくわからないけれど、システム構築の目的がそもそもずれていたってことかな。

 

HP ヒューレットパッカード

HPは世界最大のパソコンメーカーですが、パソコン以外にSI事業にもシフトしています。

HPはSAPの認定パートナーでもあり、SAPのカスタマイズは得意なはずですが。。。

 

The project eventually cost HP $160 million in order backlogs and lost revenue—more than five times the project's estimated cost. Said Gilles Bouchard, then-CIO of HP's global operations: "We had a series of small problems, none of which individually would have been too much to handle. But together they created the perfect storm."

 

最終的な金額としてプロジェクトは1億6,000万ドルかかり、収益は失われました。当初の見積もりコストの5倍以上です。 HPのグローバル事業部門のCIOであるGilles Bouchard氏は次のように述べています。「一連の小さな問題がありましたが、そのどれについても処理するのは難しくなかったです。ただ、一緒になることでそれは、完全な嵐となってしまいました。」

HP自身が、SI事業のプロであるはずの自社内のERPプロジェクトに失敗した例。

詳細は不明ですが、細かな問題が積み重なって大きなコストがかかってしまったって事ですかね。

 

マサチューセッツ大学やスタンフォード大学

これはピープルソフトのロールアウトの失敗事例。

大学のWEBポータルが正しく機能せずに、多くの学生がクラスに出席できなかったとか。

 

ウェイスト・マネジメント Waste Management

ウェイスト・マネジメントは、米国ヒューストンにある、ごみ処理会社大手。

SAPは、2005年に18ヶ月以内に、ウェイストマネジメントのシステムを実装すると約束したとか。

それが約束通り実行されなかったのでしょうか。

ウェイストマネジメントは、SAPのインプリメンテーションの失敗からSAPと訴訟に発展しています。

 

Oracle Fusion Applications

オラクルのFusionが出荷されないという話。

これは、ほとんどの日本人には理解されない事例なので割愛。

 

Oracle、SAPとTomorrowNowという小さな会社

TomorrowNowは、2005年にSAPに買収された会社で、ピープルソフトというオラクルに買収された会社のコンペティター。

買収後は、買収元の製品に統合されることはよくあるけれど、TomorrowNowの場合、オラクルとの訴訟の関係で2008年に出荷を停止したとか。

 

まとめ

ERPの導入は難しい。。

 

 

コメント