デザイナーのためのフォーラムに参加しよう
あなたの専門知識はコミュニティにとって不可欠です。私たちに参加して、あなたの知識を提供してください。
今すぐフォーラムに参加する業界最高のプロフェッショナルと分かち合い、学び、成長する.
エンジニアリング変更管理は、製品の変更と実装を管理するビジネスプロセスです。製品ライフサイクル管理（PLM）ソフトウェア内のエンジニアリング変更管理プロセスは、PLMカスタム・トレーニングの中核をなすものであり、私のお気に入りのトピックの1つです。このブログでは、使用するPLMソフトウェアに依存しない一般的なワークフローをご紹介します。
下の画像は、エンジニアリング・チェンジ・マネジメントのプロセス全体です。エンジニアリング・チェンジ・マネジメントにおけるあなたの役割によっては、プロセスの特定の部分のみに参加することもできます。タスクには、製品データのレビュー、オーサリング、または承認が含まれる場合があります。
1. 問題報告
これは、顧客やサプライヤに代わって記録された問題や機能拡張による製品変更の要求です。しかし、このステップは任意です。問題レポートの作成では、優先度、影響を受けるオブジェクト、提案された解決策、期待される利益などの詳細を入力します。その後、変更管理者または問題報告レビュアーが問題を調査し、該当する場合は影響分析を実施します。問題レポートが承認されると、新しい変更要求の作成に進むことができます。
2. 変更要求
正式な変更は、影響を受けるオブジェクトに対して新しい変更依頼を作成することによって提案されます。問題報告からの情報は変更依頼に引き継がれ、分析のために提出される前に必要に応じて更新されます。変更要求は、要求の検証、技術的分析の調整、推奨される解決策の生成を含む、分析されます。関連する分析情報も変更リクエストに含まれます。この時点で、Change Requestはそれ以上検討することなく却下されるか、プロセスを進めるかのどちらかになります。PLMシステム構成によっては、変更審査委員会による審査をスキップするファストトラックオプションがあります。プロブレムレポートが承認されると、プロセスは新しい変更通知（チェンジオーダーとも呼ばれる）の作成に進みます。
3. 変更通知（変更注文とも呼ばれます）
変更要求が承認されると、適切な変更通知が作成され、承認された変更要求を実施するための計画が策定されます。実施計画は、作業に必要な変更アクティビティ/アクションタスクで構成されます。その後、担当者（PLMシステムによっては、担当エンジニアと呼ばれることもあります）は、仕様書、CADモデル、EBOMの編集や作成など、割り当てられた変更アクティビティ/アクションを完了します。タスクが完了としてマークされる前に、レビュアーは担当者の作業をチェックし、検証する必要があります。変更通知に関連するすべてのタスクが完了すると、変更内容が監査され、文書が明確で簡潔かつ有効であることが確認されます。変更通知は、承認または却下されます。承認された場合、結果のオブジェクトはリリースされ、対応する変更要求は解決されクローズされます。結果としてオブジェクトがリリースされれば、エンジニアリング変更管理プロセスは完了です。
PLMカスタムトレーニングイニシアチブをお客様と一緒に行うことは、やりがいのあることです。この一般的なワークフローは、カスタム属性、カスタム・ユーザー・インターフェース、カスタム・ロール、ERPシステム統合など、製品やプロセスのカスタマイズを組み込んだ各ステップのトレーニング・コンテンツを作成する前のアウトラインを提供します。
デザイナーのためのフォーラムに参加しよう
あなたの専門知識はコミュニティにとって不可欠です。私たちに参加して、あなたの知識を提供してください。
今すぐフォーラムに参加する業界最高のプロフェッショナルと分かち合い、学び、成長する.