検索
連載

失敗企業5つの類型、成功企業7つの法則モノづくり最前線レポート(24)(1/2 ページ)

製造業向けERP導入プロジェクトを見守ってきた大澤氏が語る、プロジェクト失敗の症例集と成功のための7つのポイント。あなたの会社の症状は?

PC用表示 関連情報
Share
Tweet
LINE
Hatena

 富士通マーケティングが2010年11月11日、「クラウド時代を拓く エグゼクティブフォーラム」を東京で開催した。

 富士通マーケティングは、2010年10月に旧富士通ビジネスシステムを中核に、あらたに中堅民需市場をターゲットに設立された組織だ。中堅企業向けERPパッケージであるGLOVIA smartシリーズの提供、パートナー支援を中心とした活動を行う。同社がいま注力しているのは中堅企業向けのクラウド・SaaSサービスの展開だ(サービス内容は下記記事を参照)。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 イベント当日はクラウドを活用した経営効率化を主題に8セッションが設けられ、事例や専門家による講演が行われた。

 本稿読者の中にも利用者は多いと思われるGLOVIA smartについては、富士通マーケティング GLOVIAビジネス統括部 統括部長 大澤 尚氏が、自身の経験を基に、導入プロジェクトが失敗する理由を体系だてて紹介するセッションもあった。

 GLOVIA smart 製造 PRONESは富士通が提供するERPパッケージ「GLOVIA smart」の中でも特に製造業に特化した機能を取り入れた製品だ。販売管理、生産計画、製造計画、調達管理、原価管理、在庫管理などの機能を持つ。機能詳細は下記図版などを参照してほしい。GLOVIA smartシリーズには製造 PRONESのほか、FA機器などと連動して生産状況を可視化するGlOVIA smart MES(工程管理、在庫管理、スケジューラ機能を含む)や、生産計画機能を提供するGLOVIA SCP FK lightなどがある。

GLOVIA smart 製造 PRONESが提供する機能
GLOVIA smart 製造 PRONESが提供する機能
組み立て・加工業向けの標準テンプレートのほか、個別生産、自動車、化学、食品などの業界固有の商習慣を取り込んだ「業種テンプレート」が用意されている

症状別5つの失敗事例

 セッションはGLOVIA製品群の日本企業への展開を行う同社のいままでの経験からさまざまな業種・業態の企業の具体歴な例を示しながら紹介していくというもの。ここではその内容を中心に紹介しよう。

 「このような講演では成功事例の紹介が多いが、実はお客さまとお話をする際に最もリクエストが多いのが失敗事例」と切り出した大澤氏は、あえて失敗事例を示すことで成功のヒントとしたいとして講演を始めた。

 大澤氏は失敗事例を5つのケースに分類、それぞれに「症例名」を付けながら、その原因と背景を整理した。5つの症状のいずれかに当てはまる経験がある方も多いのではないだろうか。以降ではそれらについて見ていこう。

ケース1:導入の目的を見失う“道具依存症”

 ERPパッケージさえ導入すればMRPの理論をすぐに実践できる、と誤解し、現場のプロセスや会社の方向性を無視して導入した結果、現場の抵抗に遭い、導入したものの使われることのないシステムが完成したケース。

ケース2:目標達成前に情熱が冷めてしまう“燃え尽き症候群”

 例えば、プロジェクトの責任者が何らかの業務と兼務しており、一方の業務が繁忙期にさしかかったため、プロジェクトが中断、プロジェクト再開の頃には導入に向けた意欲が喪失してしまい、導入プロジェクト自体をキャンセルしてしまうケース。

ケース3:カスタマイズが肥大化してしまう“現状維持症候群”

 既存の業務フローをそのままにERPパッケージを導入しようとするあまり、標準的なワークフローから逸脱した要件が増えてしまうケース。カスタマイズしすぎてパッケージの原型がなくなってしまうばかりか、場合によってはデータの一貫性を保証できないほどの仕上がりになるうえ、開発期間が長引いてしまう。投資額は大きくなるものの、仕上がったシステムそのものが使えないレベルになってしまう。

ケース4:現場関係者が不在となる“当事者意識欠乏症”

 例えば本社情報システム部門の担当者だけがプロジェクトを担当する場合に多いケース。現場担当者が不在であるため、実際に導入した後に利用する側となる当事者=現場担当者らがプロジェクトに関心を示さず、最終的に仕上がったものが現場に受け入れられない。

ケース5:どんどんと要件が膨らんでしまう“企画倒れ症候群”

 ケース3に類似するが、そもそもプロジェクト担当者はパッケージ標準の業務プロセス導入を推奨し、その意気込みで要件定義を進めたにもかかわらず、現場からのカスタム要求をすべて受け入れてしまった結果、アドオン追加などがかさんでしまう。開発期間が長引いた結果、システムが仕上がることには陳腐化した要件が含まれることになってしまう。

 「こうした失敗はなぜ起こるかを突き詰めていくと、企業内の『部門の壁』が大きな要因となっていることが分かる。この壁に風穴を開けていくのがICTの本来あるべき役割り」と、大澤氏は訴える。では、「ICTの本来あるべき役割り」を実践するにはどうしたらよいのだろうか。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ
ページトップに戻る