システム導入効果を伝えるシナリオ PLMシステム導入で仕事はどう変わる？：PLM導入プロジェクト、検討前に読むコラム（5） （3/3 ページ）

[久次昌彦／プログレス・パートナーズ，＠IT MONOist]

コンテキストをつなげて擦り合わせ型モノづくりをサポート

　では実際に製品開発業務でプロセスアプローチを実現し、業務に必要なコンテキストをどのようにPLMシステムに実装していくのかを見ていきたいと思います。

　部門を超えた情報共有シナリオとして、ここでは不具合の発見と設計変更の流れを用いて、PLMシステムが担うインプットとアウトプットおよびプロセスとしての処理を紹介したいと思います。

　システムの利用シナリオは次のとおりです。

システム利用シナリオ

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

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

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

　どうでしょうか？

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

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

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

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