ERP導入失敗の轍を踏まないためには

PLMの専門家が語る「円滑なPLM導入の勘所」

PLM導入プロジェクトを成功させるためには、ITプロジェクトとしてPLM構想を推進するのではなく、戦略的な成果を目標とした全社的な業務改革の取り組みと位置付ける必要がある。

公開 2009年10月15日 08時01分

更新 2012年09月04日 17時45分

著者

Beth Stackpole

[TechTarget]

印刷する

　PLM（製品ライフサイクル管理）ソフトウェアの導入に当たっては、以前にERPを導入したときの教訓を生かさなければならない。ビッグバン方式の導入がプロジェクトの大幅な遅れと予算超過を招いたために、初期のERPプロジェクトの多くが頓挫したことを考えれば、PLMの導入成果を確実なものにするには、段階的な導入を行うべきだと専門家は口をそろえる。

　まず、各業務部門の代表者で構成される評価チームとIT部門は共同で、PLMプロジェクトを管理可能な要素に分割する必要がある。そしてこれらの要素を個別に導入・検証し、従業員の間で利用を促進することにより、経営陣に具体的な成果を示さねばならない。対照的に大規模導入ではプロジェクトが完了するのに非常に長い期間を要し、いつまでたっても具体的な成果を示すことができない。これは、プロジェクト推進力の減退、経営陣の関心の低下、予算配分の変化に伴う優先度の変更といった状況につながることが多い。

　「段階的に導入するということは、段階的に成果が得られるということでもある」と話すのは、米AMR ResearchでPLMを担当するマイク・バーケット副社長だ。「社内力学という視点から見れば、徐々に成果を示すことができれば、大きな成功を達成できる可能性が高い」

PLM導入指標とスケジュールの設定

　導入指標システムを構築することも、導入の各段階での目標達成を立証する上で非常に重要だ。PLMを専門とする市場調査会社CIMdataのピーター・ビレロ副社長は「試験運用段階が終了すれば、PLMの各要素を限定的なエリアに導入し、これらの要素が要求通りに機能するのを確認した上で、導入範囲を拡大するという方法が望ましい」とアドバイスする。

　「導入範囲の拡大あるいは縮小の判断を下す時期の目安となる期限と指標を設定すべきだ。その期限は検証対象の技術によって異なるが、経験的にいえば2カ月程度だ」とビレロ氏は語る。

PLMの成功には従業員のトレーニングが不可欠

　ユーザーをPLM環境に慣れさせるために、よく練られたトレーニングプログラムを作成することも、PLM導入に欠かせない重要な要素だ。ただしPLMのトレーニングというのは、ソフトウェアの具体的な特徴や機能を習得させるというよりは、むしろ働き方を変える文化的な訓練に近い。

　「人間は変化に抵抗するものだという事実を過小評価してはならない」と話すのは、PLMを専門とする米コンサルティング会社CPD AssociatesのPLMリサーチディレクター、ケン・バースプリル氏だ。「これは人間の問題であり、PLMではほかの企業向けアプリケーションよりもその傾向が強い」と同氏。技術者に対して新しいプロダクティビティツールのトレーニングを行う際には、この問題がより顕著になるという。

　「これは画家に対して、お気に入りの絵筆を使うのをやめ、ほかの筆を使うように求めるようなものだ」と同氏は付け加える。「ユーザーは技術開発や製造業務で特定のソフトウェアを使い慣れてしまうと、普段はそれに対して不満をこぼしていたとしても、変化を嫌がるものだ」

レガシーシステムからPLMにデータを移行する

　トレーニングと同様に重要で困難な作業として、データをレガシーシステムから新しいPLM基盤に移行することに加え、自社開発システムをPLMの各コンポーネントおよび製造プラットフォームやERPプラットフォームと連携させることがある。今日では多くのPLMベンダーが主要なERPプラットフォームとの連携が可能な製品を提供しており、特にエンジニアリング系の製品の多くは、製品データおよび各種CADシステムの3Dモデルと同期化するためのモジュールを備えている。

　こういった製品が登場しているものの、PLMをほかのエンタープライズプラットフォームと連携させるのは大変な作業であることに変わりはなく、全体的なPLMプロジェクトの一環として個別のカスタマイズ作業やコンサルティングサービスが必要となるケースも多い。これはPLMプロバイダーとの共同作業になる場合もあれば、当該分野を専門とするコンサルティング企業やシステムインテグレーターに委託するというケースもあるだろう。最初のRFP（提案依頼書）および最終的なコンサルティング契約には、必ずシステム連携に関する要件を盛り込み、自社のすべてのニーズがカバーされるようにすることが重要だ。

　PLM導入プロジェクトが頓挫するのは、戦略的な成果を目標とした全社的な業務改革の取り組みとしてではなく、ITプロジェクトとしてPLM構想を推進しようとすることが原因である場合が多い。

　「これは、IT部門が関与できないとか、関与すべきでないという意味ではないが、PLMプロジェクトがビジネス部門から要請を受けてスタートしたのではなく、単なるITプロジェクトとして進められている場合、ビジネス部門に与える効果を誰も判定することができないだろう」とバーケット氏は語る。逆に、ビジネス部門がPLMを要求してきた場合でも、IT部門は警戒する必要がある。「PLMは製品開発にかかわる問題を解決する触媒となる」といったたぐいの記事の受け売りにすぎないこともあるからだ。

　「ビジネス部門が問題を特定し、何を改革すべきかを把握するための作業をしていなければ、PLMがソリューションになるかどうかを判断するのが難しくなるだろう」（同氏）

本稿筆者のベス・スタックポール氏はフリーランスのライターであり、製造手法および製造関連のIT技術に関する記事を多数執筆している。

印刷する