現場で不具合が発生したので不具合報告書をPLMシステムに起票します（アウトプット）
不具合報告書はワークフローを使って、部門を超えて情報が伝達されていきます（アウトプットからインプット）
不具合報告書が回覧された品質管理担当部署では、不具合の影響度の分析をします。ここでECO（設計変更票）を起票し対象品目を入力すると、システムが影響する品目を提案します（プロセス）
影響度の分析を実施し対応要と判断されると、ワークフローを用いて設計部の変更実施担当者に回覧されていきます（アウトプットからインプット）
設計担当者は設計変更に必要な設計作業を実施します。
　このときシステムが、対象品目の設計作業に必要な図面や仕様書をそろえて提示します（プロセス）
設計変更作業が完了すると、変更する設計担当者は新品目情報をシステムに入力します（アウトプットからインプット）
ECOの内容が承認されると、対象品目はリビジョンアップして新しい部品表をシステムが自動的に構築して管理します（プロセス）
後工程部門は、システムから表示される新しい部品表の変更内容を、差分分析などで把握して、作業に活用します（アウトプットからインプット）

　このシナリオを念頭に、下図（画像部分をクリックすると、別ウィンドウでFlash形式の動画を再生します）を確認してみてください。

PLMプロセス生成のイメージ（画像をクリックすると別ウィンドウでFlash形式のデモムービーを表示します）

　どうでしょうか？

　PLMシステムを使って各作業の成果物を、ワークフローやデータ間の関連付け（リレーション）を通してアウトプットやインプットとするとともに、不具合の影響範囲やリビジョンアップによる新部品表の作成など、システムが持っているデータをコンテキスト（業務のシナリオ）に合わせてシステムが利用者に提案するというPLMシステムの利用イメージや効果を、ご理解いただけましたでしょうか？

　これは単なる一例にすぎませんし、ここで出てきたプロセスアプローチやコンテキストの流れは決して特別なものではありません。

　プロセスアプローチの流れやコンテキストの部分は、製造業の現場で日々行われていることをそのままシステムに反映させればいいのです。

　難しいのは、PLMシステムがどこまで自社に合ったプロセスアプローチとコンテキストを実現できるのかという点で、PLMシステム選択の大きなポイントとなるところです。

PTCがアプリケーションライフサイクル管理ソフトウェア開発企業を買収
PTCは、アプリケーションライフサイクル管理ソフトウェア「Codebeamer」の開発、販売を手掛けるIntland Softwareを買収した。単体またはPLMソフトウェア「Windchill」や「Arena PLM」と組み合わせて提供する予定だ。
製造業DXに必要なPLMの3段階デジタル化
本連載では製造業DXの成否において重要な鍵を握るPLM／BOMを中心に、DXと従来型IT導入における違いや、DX時代のPLM／BOM導入はいかにあるべきかを考察していく。第2回はDXを実現するまでに必要な「3段階のデジタル化」を解説する。
PLM的な情報管理なんて実現しない？
製品ライフサイクル全体を管理するためにはPLMを基軸としたシステム作りが急務。PLM導入・改善プロジェクトを担当する際に事前に知っておくべき話題を、毎回さまざまな切り口から紹介していきます。
PLMはTime to MarketからTime to Profit
日本にPLMを紹介する先駆けとなった書籍「CRM、SCMに続く新経営手法　PLM入門」（2003年刊）を執筆したアビームコンサルティングの執筆チームが、その後のPLMを取り巻く環境変化と今後のあるべき姿について、最新事例に基づいた解説を行う。
PLM雌伏の10年、これからは飛躍の10年となるか
2000年代前半から製造ITツール業界で話題になり始めた「PLM」。しかし、MONOistが2007年に開設してからこの10年間、PLMの実際の運用状況はPDMの延長線にすぎなかったかもしれない。しかし、IoTの登場により、PLMは真の価値を生み出す段階に入りつつある。