製品定義の重要性とPLM動向


製品定義(Product Definition)の重要性とPLM(Product Lifecycle Management)動向

 ここ1~2年の間にPLM(製品ライフサイクルマネージメント:Product Lifecycle Management)と言う言葉を製品設計の現場でも耳にしていることと思う。PLMとは全く新しい概念なのだろうか?それとも新しいツールなのか?何をしてくれるのだろうか?

 ビジネスの環境の変化やIT実装の進歩により、ビジネスソリューションは過去のポイントソリューションから企業全体、いや企業間含めてのソリューションへと進んでいる。様々な期待、また疑問があろう。ここではPLMについて動向、それを企業の現場で実践するための基本的事項で避けては通れない製品定義(Product Definition)や課題&推奨事項について述べる。

 企業をドライブする製品のライフサイクル?

 企業の多くは原材料を仕入れ、それを加工することで、製品を生産、在庫、流通することでビジネスを行って来た。一般に言われるサプライチェーン活動である。また、製品の生産にはその製品の企画、設計&詳細設計、試作、生産準備など社内外との設計のコラボレーションを行っている。所謂、デザイン・サプライチェーン活動である。

 過去の大量生産(Mass Production)のビジネスモデルから、多品種少量(Mass Customization)のビジネスモデルに変化し、更にビジネスのスピードの高速化や顧客含めてサプライチェーンがグローバル化していることは承知の事実である。最近のこの環境に於いて、上工程としての設計と下工程の生産&製造と言う関係が、過去の様にモノを中心とした生産重視のシケンシャルな関係ではもはや市場の競争力を得ることを出来ない。上述のサプライチェーンを含む、企画からフィールドサポート以降までを含む、製品のライフサイクルに於ける様々な活動を社内外共に密に結合することは必須であり、トレンドである。

 米国CIMdata社では企業のビジネスをドライブする重要なライフサイクルを3つのカテゴリーに大類している(図1:参照)。それぞれのライフサイクルは、以下の様な固有なオペーションにフォーカスする:

  • 製品の定義 - 製品の定義に関する生成とメンテナンス、“知的”資産
  • 製品の生産 - 実際の製品に関する生産とメンテナンス、“物理的”資産
  • 運用の支援 - 人、設備、資金など運用環境
Fig.1

図1:企業のドライブする3つのライフサイクル(Courtesy of CIMdata)

 それぞれのライフサイクルは製品の全ライフサイクルに関係し、製品のアイデアの段階から始まり、製品が完全に終焉を迎える迄、カスタマサポートの必要がなくなるまで、またそれらに関わる情報が不必要になるまで続く(所謂、揺りかごから墓場迄)。

 製品の定義ライフサイクルは企業の製品定義を表現する知的財産の作成、コミュニケーション、コントールに責任をもつ活動にフォーカスする。このライフサイクルの中で取り扱うものは要件、仕様書、デザイン、技術計算書、解析情報、変更に関する情報、その他の製品定義データとなる。

 製品の生産ライフサイクルは、企業の生産活動の遂行に必要な資源、技術、スケジュールを中心にしたデータを基に生産のライフサイクルを通してマネージされる。三番目のライフサイクルはビジネスの運用面であり、要員、資産、会計など情報が運用ライフサイクルを通して取り扱われる。

 3つの分離したライフサイクルだが、実体はそれらが互いに緊密に統合されてなければならない。それらライフサイクルの間の調和、コミュニケーション、そしてコラボレーションの必要性、そしてシリアルでなくパラレルであることは言うまでもない。このコンセプトは業界の中で良く理解されていることであり、また異なった表現でも語られている。しかし、製品の定義にポイントを当てると、新製品を創る基であり、品質やコストを左右する企業の利益を生み出す知的資産でありながら、中々企業の中で理解されてない部分でもある。製品の定義には機構系CADだけではなく、電気系、ソフトウエア、そして様々な文書が必要であり、重要なことは明確な形での製品への要件があっての製品の定義である。

企業は何で商いをしているか、知的資産:製品定義とは?

 企業の日々の生業(ビジネス)を考えてみよう。材料を仕入れ、加工し、組み立てて、物流に流す、そして保守と、所謂、サプライチェーンであり、材料を仕入れるインバウンド・サプライチェーン、製品を流通させるアウトバウンド・サイプライチェーンとなる。これらは、上述の“製品の生産”であり、企業に於ける“物理的”資産である。

 企業の多くはこれらのサプライチェーンに対する最適化、すなわち在庫の圧縮、流通の効率化を高めることを図って来た。これは過去のモノ不足時代の大量生産のビジネスモデルでは企業の利益に貢献をした。しかし、時代が変化し、消費者の多様なニーズ、更にグローバル化など環境変化に俊敏に答えるために設計をも巻込んだサプライチェーン、すなわち切れ目のない、またはコンカレント(またはサイマル)な、製品定義情報の“一気通貫”システムや仕組が必要となって来た。

 そこで、“物理的”資産である製品の生産に際して、どのように要件を満たすのか、どのように造らなけれならないのか、どのように品質を高めたらよいのか、そして保守はどうするなどの原点はどこにあるのだろうか?それは明確な要件定義、それに基づく構想設計、詳細設計、製造プロセス、検査基準などである(多くは形骸化され社内標準などで定められていることだろう)。もしくは設計&製造現場の担当者の中に刻み込まれたりしている場合もあろう。

 これらが“知的”資産であり、製品の定義と言ってよい。この定義が曖昧であれば、製品の生産に於いて、曖昧なモノが産まれるだろう、または生産現場で手直しということになる(実はこの生産現場での手直しもある意味では品質を設計側にシフト出来る要素であると筆者は考える)。この“知的”資産のマネージメント&プロセスを確実に行うことにより、設計と生産の距離を限り無く近付け、材料&資材の無駄の無い手配、そして再利用を促し、また変更管理も各組織、更にパートナーを含んで利益を得る仕組を作り上げることが出来る。企業の財産はここにある訳で、“知的”資産と言われる所以であり、企業のモノづくりの原点でもある。

 それでは製品の定義とは具体的にどんなものなのか?一例として、米国 ICM(Institute of Configuration Management)が提唱し、実装が進んでいるCMII手法を参照する。この手法自体は古典的なConfiguration Managementに溯る。主にDoD(U.S. Department of Defense)に代表される軍関係や航空宇宙などの分野での利用により、その目的のために管理体系が作られていた。所謂、管理のための管理であり、また紙ベースでもあった。しかし、この手法は製品定義のライフサイクルのマネージメント手法と言う点で定着しており、広く米国(並びに欧州)で現場の技術となっており、産学でもカリキュラムが作られている。昨今のモノづくりの現場で、Product Configurator、Production Process ConfiguratorとかSalese Configuratorなどが存在するバックボーンでもある。

 ICMでは古典的なConfiguration Managementを独自に発展させ、昨今の環境の変化に対応すべく企業のビジネスプロセスの改善(利益を創出する)への手法=CMIIプロセスを開発し、彼自身のコンサルティングビジネスに使用し、またモノづくり現場での実装の手法の訓練のワークショップを通じて実装技術者の認定制度(全世界で約3,000人を超える。筆者もその1人)を進めている。

 CMIIプロセスには多くの基本的な手法があり、その一つとして図2の製品定義(物理アイテムの階層)を参照いただきたい。非常に単純ではあるが製品定義の基礎の全てを含んでいる。最上位は要件の明確化であり、当該製品への要件は何か、例えば、性能、仕向け地の規格(法的なものなど)、製造要件、諸々のものがあるが、当該製品&企業のビジョンによって決まるものである。これが製品の全てを決定する。

Fig2a

図2:製品の定義:例、物理アイテムの階層(Courtesy of ICM)

 この要件をベースをしたデリバリーアイテム、すなわち最終製品についての定義である。それには実装機能等どのような働きをするか、どのように造るかなどを明確にする。これらはブツとしのモノづくりではなく、所謂、論理的なブツを造ることを意味する。そして実際の構成展開となるが、ここでは大きく、「Make」と「Buy」に大別して展開を図る。前者は内製品であり、後者は標準品とか購入品であり、それらに附随する固有の各種ドキュメント(要件、機能仕様、検査仕様、品質、製造プロセス、図面など諸々)が結び付けられる。そして、これらの製品定義を基にライフサイクルマージメント(変更管理)を進めようと言うものである。

 この製品定義が、古典的な例として、フロッピーディスクを考えてみよう。要件から構成展開までが、教則本のように同じものが出来るかと言うと、それは各企業によって異なる。理由は企業のビジネスのビジョンである。ある企業は樹脂の材料までの展開を、ある企業はラベルだけで他は購入品であるかも知れない。ビジネスのビジョンあっての製品定義であり、構成展開である。

 モノづくりの現場からはそんなものをやっても品質だか実際の手順は、ブツを目の前にしてやると言う声が聞こえそうが気がするが、実はそれらも現場のノウハウであり、形骸化して行かなければ伝承も出来ないし、パートナーとのコミュニケーションも今の時代では期待出来ない。

 ICMのこのCMIIプロセスは製品の定義の手法だけでは実現するものでない。要件定義、構成展開、品番体系、変更管理の手法、クローズドループ・プロセス、QCD改善策、ライフサイクル&トレーサビリティ、計画管理、PDM/ERP他を含むシステム実装課題、更に組織的な改善(BPRそのものではない)を含めてのトータルな手法であることを明記しておく。

 尚、ICMでは独自に彼らのCMIIプロセスを満足するアプリケーションを認定しており、ベンダーの対応も充実してきた。これについては表1:CMII 認定アプリケーション(巻末)を参照されたい。

PDM、そしてPLMへと

 企業のライフサイクル、また一つの要素である製品定義について、ビジョンや手法面から簡単に説明したが、本来でこれらを実践するための一つの製品データ/定義マネージメント(PDM)が長き渡りに語られ、利用され、存在し、PLMと言う言葉が定着して来た。業界では、同様にその中で製品ライフサイクルマネージメントについて、既に語られて来ていたことは承知の事実であろう。それでは最近表面に出て来たPLMとの関係はどうなっているのだろうか、また、違いはあるのだろうか?

 PLMと言う言葉が定着したのが1995年くらいであろう。それ以前はPIMやEDMなど多くの事が存在した。最近では、業界(ユーザー&ベンダー両方)で製品データ、いや製品定義情報を昨今のインターネット&グローバルなビジネス環境に対応させるため、更に如何に効率的に且つ正確に製品を創り&マネージメントをライフサイクルを通して統合的に行うために以下の様な多くの言葉が業界の中で発信されるようになった:

  • 製品ライフサイクル(Product Lifecycle)
  • 製品定義(Product Definition)
  • コラボレーティブプロダクトコマース(CPC)
  • 製品ナレッジマネージメント(PKM)
  • 製品データ/定義マネージメント
  • CAE/CAM/CAE、MCAD、EDA、CASE
  • コラボレーション
  • コラボレーティブマニファクチャリングエンタープライズ(CME)
  • コラボレーティブ製品定義マネージメント(cPDm)
  • 製品ライフサイクルマネージメント(PLM)
  • 他、諸々

 これらは過去のPDMの黎明期にもあった様に、ユーザー側含めての業界が目指すビジョンに対して多くの切り口で語られ、更にベンダーにとっては市場でのポジション争いに於いての様々なセールストークにもなっていた。

 米国CIMdata社は過去10年以上に渡りPDMについての定義や市場形態を適宜発信してきた(ここで適宜としたのは固定したものではなく発展的に変化/正常進化を続けたことを意味する)。社では2002年新たに、ベンダー向けに製品ライフサイクルマネージメント(PLM:Product Lifecycle Management)の定義を紹介すると共にPLM市場規模&動向を発表し、引き続いてCIMdata 2002(平成14年4月開催)ではユーザーコミュニティへの同様な紹介を進めて来た。

Fg3a

図3:PLMの定義(Courtesy of CIMdata)

 CIMdataではPDMの定義、その正常進化の一つとしてcPDm(collaborative Product Definition management)の紹介しており、これらに加え、最近での業界の進展を盛込み、上の図3のようにPLMを定義、その領域を以下の様に述べている:

  • 製品定義に関する全ライフサイクルのマネージング:初期のコンセプトからフィールドサポート、そしてライフサイクルの最後迄
  • 企業間を含む:サプライヤー、パートナー、下請け、顧客
  • 製品定義に関する生成ツール(オーサリングツール)を含む:MCAD、ECAD、CASE、ドキュメントなど
  • 製品定義に関する全てもコンポーネント&プロセスをマネージング:機構系、電子、ソフトウエアやドキュメンテーション、製造プロセス(プロセスプランなど)、マネージメントプロセス(ポートフォリオマネージメント、チャンジマネージメント)
  • 企業の中の3つのライフサイクル(前述)をインテグレーションする製品情報のバックボーン

 そして、一般的な製造業に於けるPLMについての役割、またそのERPやCRMとの関係を図4に示す。尚、この関係については明確な境界区分があるかと言えば、それはオーバーラップする部分もあることを付け加えておく。

Fg4a

図4:製品ライフサイクルに於けるPLMの役割(Courtesy of CIMdata)

 PLMを実装するためのソリューションは図5にあるようなモデルを想定する。それらには:

  • 核と成る機能群(Core Functions):プログラムマネージメント、クラシフィケーション、データのオーサリング(所謂CASEを含むCax,、解析&シミュレーションなど)、製品構成、ワークフロー、ボールト
  • 基本的な技術群(Fundamental Technologies):カーネル、標準、セキュリティ、アドミニ、エンタープライズアプリケーションインテグレーション、コミュニケーション&通知、ビジュアライゼーション&デジタルモックアップ、コラボレーション
  • アプリケーション群:コンフィグレーションマネージメントなどのような固有な機能を実現するアプリケーション
  • ビジネスソリューション群:企業の固有なビジネスプロセスを支援するソリューション
fig5a

図5:CIMdataのPLMビジネスソリューションモデル(Courtesy of CIMdata)

 そして、次のような特徴を持つ:

  • 必要とするベストプラクティスとテクノロジーを組合せ
  • 今日手に出来る、また明日のテクノロジーとメソッドを利用する
  • 企業(間)の製品定義のサプライチェーンを実現
  • 企業(間)の至るところでの効果的なコラボレーションを推進
  • “競争優位”から“競争上の必要性”の変化への対応

 CIMdata社のPLMの定義や上記のビジネスソリューションを得るための要素からも分かるようにポイントソリューションではない。企業にとって製品を企画、設計、生産、販売、保守と言った一連の中でのソリューションであることは言う迄もない。

 PLM市場のプレーヤーには従来からのPDM、CAD、ERPベンダーからのPLMソリューション、またコラボレーションやビジュアライゼーションのベンダー、そしてシステムインテグレータやサービスプロバイダー等が数多く存在する。彼らのソリューションへの詳細なメッセージについては、表2:PLM関連情報のベンダーホームページに纏めたので参照されたい。また、PLMの効果については表3:製品チーム、表4:組織を参照されたい。

実装課題

 さて、ユーザーにとっての問題は実装である。多くの組織で過去、何年もPDM実装にエネルギーを割いた、もしくは今、割こうとしている。これらの実装状況についての弊社(メタリンク)の調査は以下の様である:

【成功事例と現場に実装しているグループの意見】

  • PDMを推進する側は現場を理解している
  • PDM開発側とエンドユーザーのチームワーク
  • 設計のデータは後工程でも有効利用
  • 今までの手作業をきっぱりと止める勇気
  • 現場の人のため、そのためには泥臭さはまぬがれない
  • 全社を巻き込む、トップダウンで推進
  • PDMはあくまでツール
  • 自分達の必要なことが出来るツールの選択
  • カスタマイズの少ないシステム
  • 作り込みはしない。パッケージの実現可能な機能や不可能機能の認識
  • パッケージの位置付け・効果を明確に定める
  • パッケージに合わせる
  • 業務改革を定着させるための段取りや教育を徹底

【動かないPDMシステムとなったグループの意見】

  • 開発したものの現場が使わない。現場に余計な作業が増える。
  • プロト作成に終わってしまう。本番に移行しないのは何故必要か解らない(特に効果)
  • 本番使用でなかなか立ち上がらない。原因はPDMソフトウエアのバグの問題、パフォーマンスが悪いなど
  • 開発に金がかかりすぎる。カスタマイズが思った以上に多い。
  • PDMそのものに価値を見い出せない。今のレガシー(メインフレームベース)でも仕事は出きる
  • 実装したいPDM機能は自社でも開発可能。

 一時期あった、目的ももたずに“PDMしましょう”などど言うベンダーのセールストークの時代ではないし、そのような過ちとでも言う行為は今後ありえないと思う。PLMに於いても同様なことは推測され、これらの事例はそのまま、ケーススタディをし、活かすことが可能と筆者は考える。そしてPLMの場合には更に範囲が広まっている。しかし、“一元管理”だとか、“情報の共有化”などの甘い言葉に誘われてはいけない。情報は必要な時に必要な情報は必要な場所にあることが重要である。“Push”では、“Pull”であるべきであき、カンバンと同様な要素である。PLM実装には留意しておくべきである。

 PKMに於いては既に記述の様に製品データのオーサリング、すなわち、作成を含む、その全ライフサイクルをカバーしようと言うコンセプトである。製品のライフサイクル全体でどう製品データがビジネス活動に関わっているか、当該企業にとってのクリティカルポイントは何かについてのアセスメントが必要である。

 また、3D CAD実装でよく語られた“一気通貫”は何なのか?おそらくデータだけではなく、ビジネスプロセスを含む、一気通貫を支えるバックボーンを見い出さなければ新たのレガシー(部分最適)を陥ることになる。

 PLMのビジネスアプローチを実装する際、以下のようの課題を議論しなければならないだろう:

  • 社内標準(技術、品質、設変、他)は?今のままで昨今のビジネス環境に耐えられるのか?もし、現場で機能して無いならば、即刻改善すべきであるし、環境の変化に応じ変えるべきである。
  • 設計部品表は?単なる3D CADからの部品表で良いだろうか局所的にはよいだろう。製品は複数の要素、機構、電気、ソフトウエア、他から出来ている。マスターデータモデルの定義が必要である。
  • データのオーナーシップ?例えば、PDM/ERPの統合がよく言われるかそれにはどんな問題が潜んでいるか?E-BOM、M-BOM、そして工程設計情報など物理的な統合は現実的では無い、しかし論理的には可能。そこで製品情報について、各エレメントについて同期&整合性を保つプロセス、マスターはどこにあるのかを定義しておかねばならない。
  • 変更管理とは?よく技術変更管理(ECO)は言うが正しいだろうか?実態は各企業のビジネス上のクリティカルポイント(コストとか品質とか)がベースになっている。また、サプライヤー含めて行われている。ECOのEはエンジニアリングではなく実はエンタープライズのEである。
  • 製品定義情報&プロダクオーナー?誰が構成展開をしているか?設計者の論理だけでは不十分。要件定義を含め確実に行わなければ、製品は出来ない。ライフサイクル全体を見て、製品定義を行わなければ効果はない。そのために組織的な構造も必須である。
  • その他、プロセスモデル、データモデル、そしてアドミニストレーションモデルなど諸々。

 最後に

 企業に於いて、現場の設計者は日夜、問題解決に日常業務に追い捲られている。PLMのような新しいトレンドに対し、その評価は身近のポイントソリューション、例えば、QCD項目だけに目を向け易い。また、PDMも効果を身にしみて効果を体感出来ないことも何故なのかと言う疑問もあるかと思う。しかし、ビジネス環境など外部要因を含めて考えてこそ、企業全体のパフォーマンスや競争力の評価や対策が出来るものである(図6:成功へのデシジョンツリー参照)。

Fig6a

図6:成功へのデシジョンツリー(Courtesy of MetaLinc)

 情報技術はメインフレームからWEBベースに、データモデルは紙から電子、2次元から3次元、オブジェクトからモデルへと、そして最も変化したのはグローバル化に代表されるビジネスモデルであり、25年前、いや数年前と比較しても激変している。これらの要因も受け止めてPLMへの進展である。CIMdataの定義にあるようにPLMそのものはビジネスアプローチであり、企業が競争力をもって生き残りをするためのものであり、それを支援するベストプラクティスや各種ツールである。時代のトレンド、そしてビジネス現場に於ける課題を山の頂上に立って正確な道筋を見ることをぜひとも薦める。

参照資料:

  • collaborative Product Definition management _ Overview (An Overview of a Collaborative Approach to Managing the Product Definition Lifecycle))(CIMdata社偏)
  • 米国CIMdata社PLM Vendor Forum Workshop テキスト
  • 米国CIMdata社PLM Configuration Management Workshop テキスト

参照企業:

表1:CMII 認定アプリケーション

  • SDRC, PKM - MetaChange 3.2 /Metaphase (5. June 200)
  • UGS, iMan V7 (25, July 2001)
  • Auto-trol, CENTRA 2000 (13, September 2001)
  • MatrixOne, Engineering Central (18, September 2001)
  • MERANT, PVCS DIMENSIONS(26, September 2001)
  • Spescom Software, eB CM (23, October 2001)
  • Einger (21, January 2002)
  • PTC, PDMLink/ Windchill (8, April 2002)
  • Agile Software, Agile Product Collaboration suite (15, May 2002)

(註)上記の日付はプレスリリースであり、認定取得日ではない。また、詳細は各社のHPを訪問することを薦める。

表2:PLM関連情報のベンダー(順不問)

  • 日本パラメトリック・テクノロジー株式会社
  • 日本電気株式会社
  • ダッソー・システムズ株式会社
  • 日本アイ・ビー・エム株式会社
  • バーンジャパン株式会社
  • 株式会社日立製作所
  • SAPジャパン株式会社
  • メトリクス ワン株式会社
  • 株式会社クラステクノロジー
  • 株式会社ケイ・ジー・ティー
  • PwCコンサルティング株式会社
  • コクリエイト・ソフトウエア株式会社
  • 富士通株式会社
  • アクセンチュア株式会社
  • 三菱電機インフォメーションシステムズ株式会社
  • 新日鉄ソリューションズ株式会社
  • 株式会社 東芝 e-ソリューション社

(註)本リストには各ベンダーの協力をいただいたが全てではない。また内容についてはPLMのソリューションの一部とである従来からのPDMなども含まれる。

表3:PLM効果:製品チーム

  • 企業を横断するコラボレーティブなプロジェクトマネージメント
  • 矛盾の無く精度の高い製品データへの迅速&容易なアクセス
  • 完全な製品データのアクセスとマネージメント
  • リアルタイムなプロジェクト・トラッキングと状況報告
  • デシジョンサポートを行う情報提供
  • 製造工程(プロセス)の評価を早期に行う
  • 付加価値の無い活動を低減させることで創世的(Innovation)な活動を増やす

表4:PLM効果:組織

  • 企業間のコラボレーティブなビジネスプロセスを実現するイネーブラ
  • 組織を横断する共通プロセスや標準化の推進
  • 情報、プロセス、人への強化
  • 企業間を横断する分散、グローバルコミュニケーションのイネーブラ
  • 組織の知的資産の整合性とセキュリティを確実にする
  • 組織の変化を支援
  • 情報の島の橋渡し

(江澤 智、2013.6.26 改、Original 2002.6)


本件についてのご意見はこちらからお送り下さい。

Your local time is  where you live.

© 1995-2017 MetaLinc K.K.