モノづくりシステムのROIがよくない5つの理由：戦略構築のためのライフサイクル管理論（2）（1/3 ページ）
自社の製品開発戦略をしっかり把握しているでしょうか？ 製品開発・生産技術の効率化を追求していたとしても、しっかりとした戦略とマネジメント意識がなければ意味がありません。本連載では、マネジメント技術としてのライフサイクル管理を考えていきます。
満足度50％、本来の1/5しか実現していない
今日、PLMシステムは多くの企業で導入され、3次元CADのモデルデータ管理や製品構成（BOM）管理を実現し、製品開発情報を統合管理する用途に使われています。
日本では1990年初期に導入が始まったこのシステムは、売上高が1兆円を超える製造業ではほぼ何らかの形で導入されています。
しかしこれらの導入企業でも十分満足のいく形でPLMシステムを導入している企業は50％前後にとどまっています。またPLMシステムの導入には満足している企業でも、計画どおりの機能をすべて実現できている企業は少なく、多くの企業では本来実現したい機能の1/5程度の導入にとどまり、不満がありながらも使い続けているのが現状です。
ひと言でPLMシステムといっても
PLMシステムには企業における製品開発を支援するためのさまざまな機能があります。CADデータやMicrosoft OfficeデータおよびPDFなどの電子データを管理するドキュメント管理機能、製品構成情報を管理する構成管理機能（E-BOM）や設計変更情報を一元管理したり、設計変更のレビューを自動化するためのワークフロー機能などです。
最近ではプロジェクト管理機能を持たせ、プロジェクトの進ちょくに応じPLMシステムで管理しているCADデータやドキュメント、パーツや部品表情報を設計成果物として関連付けて管理できるようになっています。
「PLM？ 使っているけど高い割に大したことできないよね、あれ」
私も仕事柄多くの設計部門に訪問するのですが、大手企業であればどの会社に行っても「PLMは使っているよ」という回答が返ってきます。しかしよくよく聞いていくと実は……。
PLMシステムはあるけど、BOMの管理ぐらいしかできていないんだよねぇ
とか
PLMシステムは導入しているけど、PDM的にCADデータを管理する程度しか使ってなく、設計変更やワークフローまで使い切れていないんだよねぇ
ということを異口同音に聞きます。これは一大事です。PLMシステムはそんなに安価なものではありません。
本来あるべき姿ならROIが上がるはずなのに
PLMは、億単位のプロジェクトが組まれることもよくあるERPやSCMシステムに匹敵する基幹システムです。そのようなシステムがなぜうまく活用されていないのでしょうか？
PLMシステムの活用度合いを「本来あるべき姿」まで持っていくことで、日本の製造業はもっと効率化が進むはずです。多くの企業を訪問し担当者と話をしていく中でPLMシステムがうまく活用されていない理由が明らかになってきました。
PLMシステムがうまく活用されていない理由は大きく下記の5つのポイントが挙げられます。このポイントを理解することでPLMシステム構築のリスクを大きく下げることができます。
- 部品表システムのダウンサイジングが成功事例として喧伝（けんでん）される
- PLMシステム製品の機能不足
- ライセンスの縛り
- 柔軟に開発できない
- ビジネスモデルとしてのプロダクト・ライフサイクル・マネジメントが認識されていない
以降では、ここに挙げたポイントをそれぞれ解説していきたいと思います。
理由1：BOMのダウンサイジングが成功事例って、ちょっと誤解がすぎます
PLMシステムにはすでに紹介したようにドキュメント管理や部品表管理および設計変更管理から、それらを承認回覧するための仕掛けとしてのワークフロー機能が備わっています。
そもそも汎用機の移行が目的ではお話が違う
しかし、これらの機能を十分に使いこなしている企業は多くはありません。というのも初期のPLMシステム導入ユーザーの要件は「既存の古いホストコンピュータで動いている部品表システムのサポートが切れるので、UNIXにダウンサイジングしたい」ということでした。
このような要件をベースにシステム構築がスタートしているため、既存のホストで動いていた部品表システムに関する要件は詳細に検討されましたが、それ以外の設計変更管理やワークフローなどは十分な検討が進まずに、結果としてドキュメントとパーツ情報を関連付けて管理する程度のシステムに落ち着きました。
初期導入事例は消化不良
このようなPLMシステムの初期導入ユーザーが構築したPLMシステムが、PLMベンダにとってはユーザー事例となってセールストークで使われたため、そのユーザー事例をベースとしたPLMシステムが多くの企業に導入されていきました。
しかし、このような形で構築・導入されたPLMシステムは、ドキュメントやパーツ、部品表を管理するだけのデータベースでしかないため、設計業務の流れとは切り離された設計コンテンツを管理するシステムとなってしまいました。このことが、設計業務の流れそのものである設計変更管理やワークフロー機能などを十分に使えるところまで導入が進めなかった大きな理由の1つといえます。
理由2：PLMシステム製品の機能不足
PLMシステムがソフトウェアとして日本に紹介された当時、日本企業のお客さまは自分たちの設計開発業務がシステム導入によって大きく改善できると非常に大きな期待を持っていました。
しかし、1990年代に登場したPLMシステムはお世辞にも完成度が高かったとはいえませんでした。
初期PLMの2つのパターン
当時のPLMシステムは大きく2種類のタイプに分けられます。1つは製品情報を管理するフレームワークとして提供されていたタイプ。もう1つは短期間での導入を実現するためにパッケージソフトとして仕様を固めて提供されていたタイプです。
管理フレームワーク型：定義に工数が掛かり過ぎて使えない！
前者の、フレームワークとして提供されていたタイプのPLMシステムはドキュメントやパーツ情報を「リビジョン」や「バージョン」を用いて世代管理できるとともに、ドキュメントとパーツをリレーションと呼ばれる関連付けを付けて必要な情報を探し出せる仕組みを持っていました。
しかし、リレーションの定義やドキュメントやパーツに持たせる属性（プロパティ）の定義などは標準で定義されているものではまったく業務では使えず、業務で使えるようにまでにはかなりの部分をプログラミングしてカスタマイズしなければなりませんでした。
また、多くのPLMシステムはCADベンダから提供されていますが、当時は自社で提供しているCADでさえPLMシステムと連携できず、結局CADとの連携機能などは同じソフトウェアベンダから提供されているものであっても個別に開発することが必要で、CADとPLMシステムを連携させるには非常に多くの工数を掛ける必要がありました。
パッケージソフト型：カスタマイズできなくて使えない！
一方、パッケージソフトとして開発部分を極力最小限にとどめたPLMシステム製品もありましたが、こちらの方は確かに一見システムをそのまま導入できそうな機能がそろっています。
しかし、設計開発業務は生産管理や会計業務とは違って非常に多くの例外処理が発生する業務です。
設計開発業務の例外処理をなくすことは日本企業にとって設計開発能力の柔軟性を制限することで、パッケージソフトの機能がある程度備わっていたとしても、必ず企業に応じたカスタマイズが発生します。
パッケージソフト型のPLMシステムでも多少のカスタマイズは可能ですが、カスタマイズを極力しないことを前提に開発されているシステムであるため、パッケージ型PLMシステムのカスタマイズはフレームワーク型PLMシステムと比べても、より多くの工数を費やすことになりました。
PLMベンダから提示されるあるべき姿とPLMシステムの機能不足とのギャップがPLMシステムを限定的な利用に押しとどめた大きな理由といえます。
Copyright © ITmedia, Inc. All Rights Reserved.