データ管理機能 > 変更の管理 > 変更管理について
  
変更管理について
変更管理システムは、標準の変更プロセスに基づきます。このトピックでは、変更管理システムで使用される用語を説明し、プロセス内の個々の手順についても簡単に説明します。
変更プロセスで使用される用語を以下の表にいくつか示します。
変更管理の用語
用語
説明
影響を受ける最終品目
影響を受ける最終品目は、特定の変更管理オブジェクトに関連付けられている最終品目です。通常、最終品目とは、対処が必要な問題等があるオブジェクトです。問題レポートまたは変更リクエストを作成または更新中に、変更の影響を受ける最終品目を追加できます。問題レポートに対応して変更リクエストが作成されている場合でも、問題レポートから自動的に関連付けが適用されることはありません。
変更適用オブジェクト
変更適用オブジェクトとは、変更によって影響を受ける部品、ドキュメント、プロセスプランや、その他のリビジョン制御されているオブジェクトです。これらのアイテムは、変更通知の実装計画に組み込まれているタスクに追加されます。通常、割り当てられたタスクをユーザーが完了すると、これらの部品またはドキュメントが変更されます。
変更管理者
変更管理者という役職に関連付けられた重要なプロセス上の役割が 3 つあります。
最初の変更管理者 (変更管理者 I) が変更リクエストをレビューして影響に関する情報を収集し、変更プロセスのファーストトラック部門またはフルトラック部門に変更を拒否するか実行するかの決定を通知します。また、変更管理者 I は、未解決の問題レポートから変更リクエストを作成します。
2 番目の変更管理者 (変更管理者 II) は、変更通知に盛り込む実装計画を作成します。また、変更管理者 II は、実装計画を続行するかどうかについて変更管理会議の決定を記録します。
3 番目の変更管理者 (変更管理者 III) は、変更に関連したすべての資料を監査し、作成された全ドキュメンテーションが明確、正確、有効で、プロセスのすべての手順が正しく実行されていることを確認します。
変更管理会議 (CIB)
変更管理会議は、変更通知に組み込まれている実装計画をレビューし、承認または拒否の判断を下します。
変更通知
変更通知は、新しい設計の文書化およびリリースや、既存の設計の強化、問題の修正を行うための作業認可です。
変更通知は、1 つまたは複数の変更リクエストを参照して作成できます。変更を行うために完了しておく必要のあるタスクが詳述されています。また、変更通知を使用してタスクを個々のユーザーに割り当てることもできます。
変更リクエスト
変更リクエストは、1 つ以上の問題レポートに対応する形で作成できますが、問題レポートを参照しなくても作成できます。問題の修正および機能の強化に必要な変更が詳述されているので、担当者は変更リクエストに基づいて、提案されている変更内容を進めるかキャンセルするかというビジネス上の判断を出すことができます。
変更レビュー会議 (CRB)
変更レビュー会議は、変更リクエストをレビューして、承認または拒否の判断を下します。通常、設計エンジニアリング、製造エンジニアリング、品質保証といった、企業の各部門の代表者で構成されます。
変更タスク
変更タスクは、変更通知に基づいて完了する必要がある作業指示を表します。複雑な変更通知には変更タスクが多数ありますが、簡単な変更通知には変更タスクが 1 つだけの場合もあります。
ファーストトラック変更リクエスト
ファーストトラック変更リクエストの影響とコストは低いので、変更プロセスを通じて迅速に処理できます。ファーストトラックの変更で処理可能な変更のコストしきい値は通常、企業方針によって定められます。
フルトラック変更リクエスト
フルトラック変更リクエストは影響が大きくコストが高く、綿密な分析とレビューを必要とします。フルトラックの変更は、変更レビュー会議を通過してから実装する必要があります。
実装計画
変更通知に含まれる変更タスクの集合体です。
変更予定
保留中の変更とは、未解決の変更リクエスト、またはオブジェクトに影響を与える不完全な変更通知のことです。オブジェクトに保留中の変更がある場合、オブジェクトの情報ページのタイトルバーに変更予定アイコン が表示されます。
問題レポート
問題レポートは、問題を書面に記録するため、または製品の機能拡張を依頼するために作成されます。問題レポートは、正規登録ユーザーが自身のために作成する場合と、カスタマーやサプライヤーといったシステム外の人のために作成する場合があります。
結果オブジェクト
結果オブジェクトとは、変更の結果として生じる部品、ドキュメント、プロセスプランや、リビジョン制御されているその他のオブジェクトです。これらのアイテムは、変更通知の実装計画に組み込まれているタスクに追加されます。通常、これらのオブジェクトは、割り当てられたタスクが完成すると作成 (または修正) されます。
タイプ
タイプとは、オブジェクト間で区別されるオブジェクトの特性です。
一時許可
一時許可は、設計どおりの構成から特定の単位数または特定の期間にわたって逸脱することを許可する認証です。一時許可の共通タイプには、偏差および免除の 2 つがあります。
変更プロセス
変更プロセスのシナリオ例を以下に示します。
1. 最終品目の情報ページから問題レポートを作成します。
2. ワークフローによって割り当てられている変更管理者 I が問題レポートをレビューし、承認または拒否の判断を下します。
3. 変更管理者 I は、問題レポートを確認後、変更リクエストを作成し、影響分析を実行します。そして、フルトラックかファーストトラックかの判断を記録します。
変更リクエストがファーストトラックモードに従う場合、実装に向けて変更管理者 II に速やかに送信されます。
変更リクエストがフルトラックオンラインモードに従う場合、変更レビュー会議がレビューを実施します。割り当てられているすべてのユーザーがレビュータスクを完了しなければなりません。
変更リクエストがフルトラックオフラインモードに従う場合、変更管理者 I が変更レビュー会議を招集します。
4. 変更管理者 I は、変更レビュー会議による変更リクエストの実装を行うかどうかの決定を記録します。フルトラックオンラインモードでは、すべてのユーザーが変更リクエストを承認した場合にのみ、変更リクエストが実装にルーティングされます。
承認された場合は、実装計画を記録した変更通知を作成するという業務が適切な変更管理者 II に割り当てられます。
5. フルトラック変更通知は、実際の作業に取り掛かる前に、変更管理会議の承認を必要とします。承認が出ると、変更を適用する作業が開始されます。
6. データ作成者は、変更通知のタスクで指示されているとおりに、製品データを編集します。次にデータ使用者 (レビュー担当者) は、作成者が行った作業の確認と承認を行ってから、タスクを完了する必要があります。
7. 変更通知に関連付けられているすべてのタスクが完了すると、生成されたドキュメンテーションを変更管理者 III が監査し、明確、正確、有効であることを確認して、変更通知の承認または拒否の判断を出します。
関連トピック