製品の変更の管理
製品の品質向上、市場の需要の変化、および既存の製品への革新的なアイデアの組み込みにより、製品は時間とともに進化していきます。非公式の変更は、製品がリリースされる前に、製品ライフサイクルの早い段階で簡単に採用できます。ただし、製品の設計が完成して生産にリリースされている場合は、変更計画がより複雑となり、コストも上昇するため、より正式なプロセスを使用する必要があります。
変更プロセス
Windchill を利用すると、非公式な変更プロセスと正式な変更プロセスのどちらも容易になります。正式な変更プロセスは企業ごとに異なりますが、すべての企業で共有されている最良事例は数多くあります。Windchill には、一般的な最良事例を利用した正式な変更プロセスが用意されています。
標準的な Windchill のプロセスは、次の図に示す 5 つの基本ステップで構成されます。各ステップは、自動化されたワークフローによって実行されます。フローチャートのボックスをクリックすると、基本プロセスの各ステップについての説明が表示されます。
Go to explanation for step 1, Identify IssueGo to explanation for step 2, Request ChangeGo to explanation for step 3, Plan ChangeGo to explanation for step 4, Change ImplementationGo to explanation for step 5, Physical Implementation
ステップ 1 「問題の特定」 - 問題とは、製品設計に対してレポートされた問題や提案された改善を表し、一般的には問題レポートで識別されます。次のステップに進む前に、問題は解析、ディスカッション、および検証されます。問題レポートを使用するかどうかは任意です。変更リクエストおよび変更通知によって、問題が文書化される場合もあります。
詳細については、問題レポートについてを参照してください。
ステップ 2 「変更の要求」 - 検証された 1 つ以上の問題は、変更リクエストによって処理されます。変更リクエストにより変更プロセスが開始され、関連するすべてのデータと解析が取得されます。これには、変更を実行する技術的な理由やビジネス上の理由が含まれます。
変更の複雑さにより、単純な変更プロセスと信頼性の高い変更プロセスのどちらを使用するかを決定します。実行される変更が順序、生産、または使用中のユニットの改良に影響しない場合、変更リクエストは簡略化されたワークフロー (ファーストトラックプロセス) を通して受け渡しできます。変更が複雑な場合、コストがかかる場合、または変更が広範囲にわたる場合は、より信頼性の高いプロセス (フルトラック) が使用されます。使用するトラックを決定するガイドラインは、企業ごとに異なります。
詳細については、変更リクエストについてを参照してください。
ステップ 3 「変更の計画」 - 変更の実装が承認されると、変更を文書化および実装する作業を計画する必要があります。変更通知には実装計画が記録されます。計画には、変更される製品データに関連する個々のタスクが含まれます。スケジュールが提案され、既存の製品在庫の処理に関する推奨事項が設定されます。計画が承認されると、ワークフローにより実装がトリガされます。
詳細については、変更通知についてを参照してください。
ステップ 4 「変更実装」 - 製品ドキュメントの更新と新しい製品コンフィギュレーションの確認を担当するメンバーに、変更タスクが配布されます。新しい製品コンフィギュレーションは、物理的な実装が開始されるときに製造にリリースされます。
詳細については、変更タスクについてを参照してください。
ステップ 5 「物理的実装」 - 変更が生産に組み込まれます。新しい部品および修正された部品は、設計の要件に準拠していることを検査されます。製品仕様に対する一時許可は、偏差または免除プロセスを使用して管理されます。
詳細については、一時許可についてを参照してください。
Windchill 変更管理オブジェクトネットワーク
上で説明した 4 つの基本的な変更管理オブジェクトは 1 つにリンクされ、変更プロセスの完全な履歴が提供されます。変更管理オブジェクトのネットワークとそれぞれの関係を、次の図に示します。変更管理オブジェクトネットワークは、左上の問題レポートを起点として作成され、右下の変更タスクに向かって進みます。変更管理オブジェクトネットワークの解決は、変更タスクの完了から始まり、左上の問題レポートに向かって作成と逆の順に進みます。
変更リクエストは、部品またはドキュメントの情報ページから、または既存の問題レポートから作成できます。変更リクエストを問題レポートから作成する場合は、自動的に 2 つの変更管理オブジェクトが相互に関連付けられます。影響を受けるデータは、問題レポートから変更リクエストにコピーできます。1 つの変更リクエストで複数の問題レポートを処理できます。
変更レビュー会議で変更リクエストの実装が承認されると、ユーザーは変更リクエストから変更通知を作成します。2 つのオブジェクトは自動的に関連付けられます。変更通知は実装計画で必要な 1 つ以上のタスクで構成され、変更管理オブジェクトネットワークに追加されます。各変更管理オブジェクトは、完了するための既成のワークフローを備えます。各ワークフローはリンクされ、ワークフロー内でタスクが完了すると、次のワークフローでタスクの開始がトリガされます。変更が完了すると、ワークフローは変更管理オブジェクトの状態を変更し、関係者に通知を送信して、プロセスのループを終了します。
* 
上の図では、問題レポートを起点として、すべての変更管理オブジェクトを使用する完全な変更プロセスを示しています。変更リクエストまたは変更通知から開始することで、プロセスを短縮することができます。
これは役に立ちましたか?