Windchill 変更管理
動画で学ぶ「Windchill」シリーズ
動画で学ぶ「Windchill」シリーズ : Windchill 変更管理
Windchill 変更管理
Windchillでは標準の変更管理として様々な国際基準に対応できるフローが採用されており、ワークフローによる一貫した変更管理プロセスを管理することができます。
変更プロセスは個々の業務フローに合わせてカスタマイズすることも可能です。
また、変更に関連する情報と、変更される製品情報を紐づけて管理できるため、変更についての原因や、変更を加えた後の対策などが容易に確認できます。
上の図はWindchillで用意されている変更管理の標準のプロセスフローで、問題レポート～変更リクエスト～変更通知 という各種通知を用いた管理のフローを表現しています。問題レポートは、製品に関連する不具合やクレーム、改善要望を記載し、変更リクエストは仕様変更情報として、仕様変更の理由・対応案などを管理、変更通知は、変更タスクによる作業指示や、変更対象のアセンブリや部品、CADなどのステータスなどを管理します。
問題レポート
問題レポートは、問題を記録するため、または製品の機能拡張を依頼するために作成されます。
Windchill ユーザーによって作成される場合と、Windchill ユーザーが顧客やサプライヤといった システム外の人の代理として作成する場合があります。
問題レポートを起票する人は、製品について発覚した問題やクレーム、改善要望を「問題レポート」に記載します。
問題レポートの作成
問題レポートは、紐づけ情報なしで新規作成することが可能ですが、問題のある個所が明確である場合は、問題部品を右クリックして新規作成することにより、関連部品を自動的に入力して起票することもできます。
問題の名前、リクエスト発行者名、また問題のカテゴリや優先度などの情報とともに、問題について内容を詳細に記載します。
代理で入力する場合もあるため、リクエスト発行者名はWindchillユーザー以外の名前も記載できるよう、ユーザー名の選択式ではなく、任意の名前を記入することができます。
また、起票時に情報入力、資料添付、影響データと製品をリンクするために、
変更適用最終品目や、変更対象が特定されている場合は変更適用オブジェクトの記載、問題の内容を補足する文書を添付したり、過去の類似の問題などがあった場合に関連プロセスオブジェクト、関連参照オブジェクトなどを紐づけて登録することができます。
問題レポートが起票されると、製品の関連メンバーで「承認者」として登録されている 設計変更リーダー に、問題レポートが作成されたことが通知されます。
設計変更リーダーがWindchillにログインすると、ログイン直後の画面の「Myタスク」の欄に、自分が確認すべき問題レポートが表示されています。
「Myタスク」への表示だけでなく、問題レポート作成時にメールで問題レポートの確認依頼を通知できるようにも設定できます。
設計変更リーダーは問題レポートの内容を確認し、
・検討必要な技術計算書は何か
・影響の出るCADデータはどれか
・影響が出る製品はどれだけあるか
といった観点で検討し、変更をかけていくべきであると判断した場合は承諾、変更をするには適切でないと判断した場合は却下を選択し、問題レポートの確認を終えます。問題レポートの確認後は、まだフォルダの中の変更対象の部品に変化はありません。
変更リクエスト
次に、問題レポートの内容について対応が必要と判断された場合に作成する、変更リクエストについて説明していきます。
変更リクエストは、そのリクエストに対する変更処理を行うかどうかのビジネス上の判断を行います。
通常、変更リクエストは１つ以上の問題レポートと関連付けて処理をしますが、問題レポートを作成せずに変更リクエストを作成することもできます。
変更リクエスト作成
では、変更リクエストを作成していきます。
問題レポートから「新規作成」で変更リクエストを作成します。
変更リクエストはこちらの「情報を適用」にチェックを入れることにより、問題レポートから内容を引き継いで作成することができます。
先ほどの問題レポートを起票したときと同様に、
・ 原因、変更方法、変更影響、実施計画を記録
・ 情報入力、資料添付、影響データと製品をリンク
・ 関連変更をリンク（問題レポート等、複数可）
を検討し、入力していきます。
関連プロセスオブジェクト欄に、元となる問題レポートがあらかじめ登録されているところが問題レポート作成時と異なる点です。
変更リクエスト確認
起票された変更リクエストを確認していきます。
変更リクエストの場合も、先ほどの問題レポートの確認時と同様に、製品の関連メンバーで承認者として登録されている 設計変更リーダー に、問題レポートが作成されたことが通知されます。
設計変更リーダーは起票された変更リクエストの内容を分析し、対応を決定していきます。
対応として、
・承認者を変更
・ 起票者に再確認
・ レビュー担当に詳細確認を依頼したりも選ぶことができ、また確認を完了する際に変更内容の難易度によって承認者判断で承認する：ファストトラック
・ 変更レビュー委員会を開催して対応方針を判断する：フルトラック
を選択することができます。
変更通知・変更タスク
次は、変更通知・変更タスクについて説明します。
変更通知は、承認された変更リクエストによって発生した変更作業のプロセスを管理します。変更通知は、１つ以上の変更リクエストを参照して作成します。
変更通知は、
・ 実現計画の作成＆実行
・ 変更管理会議
・ 変更のリリース
・ 結果の監査
を行うプロセスです。
変更タスクは、変更を実際に行うにあたり必要な個々の作業を明確にし、作業担当者とその作業の承認者を指名し、変更作業を管理します。
変更タスクは
・ 変更の実装
・ 変更対応後の変更対象の改訂
を行います。
変更通知と変更タスクの作成
変更通知も変更リクエストから内容を引き継いで作成することができます。
こちらにチェックを入れることにより、変更リクエストの内容が引き継がれます。
変更通知作成時には、一つ以上の変更タスクを作成する必要があります。
変更タスクを作成していきます。
タスクの名前、タスク実施者、レビュー者を登録し、期日、タスクの詳細情報を記載します。
変更適用オブジェクト欄に、実際に影響のある部品を選択して登録します。
前のプロセスで部品が決定されている場合は、あらかじめその部品が引き継がれて表示されています。
その部品を「改定」をクリックすることにより、部品の改定が行われ、結果オブジェクトの欄にBのバージョンに改定されて表示されます。
この部品を変更タスク対応時に修正していくことになります。
必要なタスク数分の変更タスクを登録できたら、変更通知作成を引き続き行います。
添付資料や問題レポート等の関連付けを登録し、変更通知と変更タスクの作成を完了します。
変更の実装
ここで、変更タスクを割り当てられたタスク実施者は、変更を実装していきます。
変更の実装・関連文書等の変更が完了すると、変更タスクを完了させます。
タスクが完了すると、タスクレビュー者が確認し、タスク完了のプロセスを終了させます
タスクの実施
タスク実施者は、変更対象をチェックアウトし、変更を加えます。
（ここで場面変換のエフェクトを入れる）
変更が完了すると、タスク実施者は対象をチェックインします。
この時点でリビジョンは上がりますが、状態はまだ作業中となっています。
変更のチェックインが終わると、変更タスクで変更が完了したことを記載していきます。
「マイタスク」または「タスク」のところから、自分に割り当てられた変更タスクに変更が完了した旨を記入していきます。
変更実施詳細を記録し、変更タスクを完了させると、タスクレビュー者に変更タスクのレビュー依頼が通知されます。
変更タスクのレビューを割り当てられたユーザーは、「変更タスク」の実施内容をレビューしていきます。
変更タスクに記載されている対応内容を確認し、適切に変更の実装が行われたことを確認できたら、承認を選択して承認します。
変更の実装が適切に行われていない場合は、差し戻しを行います。
以上で変更タスクの実施からレビューまでをご紹介しました。
変更通知の監査
すべての変更タスクが完了すると、変更通知の監査を行います。
「変更通知」の実施内容を監査し、監査の結果適切に対応されている場合は 解決とし、変更結果データを承認します。
承認が完了すると、変更対象の新しい版の部品がリリース済みとなります。
監査NGの場合は変更通知作成者に再作業を指示します。
最後に変更リクエストを承認し、リクエストされた変更がすべて完了したことを通知します。
この作業により、すべての変更管理プロセスが完了します。
以上でWindchillで標準で準備されている変更管理の一連の動きをご説明しました。
今回ご紹介したフローはあくまでも基本の変更管理プロセスですので、実際の業務フローに合わせてフローや入力情報のテンプレートを柔軟にカスタマイズしていくことが可能です。
変更管理モニターレポート
これらの機能を使い、プロセスの見直しや分析、継続的な改善、またナレッジとして過去の変更管理情報を利用することでき、新たな製品作成時に役立てることができます。