変更管理

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

品質管理システム(QMS)および情報技術(IT)システム内では、変更管理は、製品またはシステムへの変更が管理され調整された方法で導入されることを保証するために使用されるプロセス(公式または非公式[1])です。これにより、不必要な変更が予期せずにシステムに導入されたり、システムに障害が発生したり、ソフトウェアの他のユーザーによって行われた変更が取り消されたりする可能性が低くなります。変更管理手順の目標には、通常、サービスの中断を最小限に抑え、バックアウトアクティビティを削減し、変更の実装に関連するリソースを費用効果の高い方法で利用することが含まれます。

変更管理は、IT、[2]ソフトウェア開発、[1]製薬業界、[3]医療機器業界、[4]およびその他のエンジニアリング/製造業界を含むさまざまな業界で使用されています。[5] ITおよびソフトウェア業界にとって、変更管理は、変更管理の幅広い分野の主要な側面ですコンピュータおよびネットワーク環境からの典型的な例は、ソフトウェア製品へのパッチ、新しいオペレーティングシステムのインストール、ネットワークルーティングテーブルへのアップグレード、またはそれらをサポートする電力システムへの変更です。インフラストラクチャ[1] [2]

ITILの特定の部分は、変更管理をカバーしています。[6]

プロセス

変更管理構成管理、および変更管理の間には、かなりの重複と混乱があります以下の定義は、他の定義とまだ統合されていません。

変更管理は、6つのステップのセットとして説明できます。

  1. 計画/範囲
  2. 評価/分析
  3. レビュー/承認
  4. ビルド/テスト
  5. 埋め込む
  6. 近い

計画/範囲

提案された変更の主要な補助的な詳細を検討してください。これには、変更の特定、その所有者、変更の伝達と実行の方法、成功の検証方法、変更の重要性の見積もり、付加価値、ビジネスおよび業界標準への準拠、完了の目標日。[2] [7] [8]

評価/分析

影響とリスクの評価は、次の重要なステップです。実行されたとき、提案された計画は何かがうまくいかない原因になりますか?関連するシステムは、提案された変更の影響を受けますか?このフェーズでは、細部を考慮する必要があります。その後、リスクカテゴリを提案された変更に割り当てるのが理想的です:高リスク、中リスク、または低リスク。高リスクの変更には、管理者の承認や利害関係者への通知など、多くの追加手順が必要ですが、低リスクの変更には、プロジェクトマネージャーの承認と最小限のドキュメントのみが必要な場合があります。[2] [7] [8]計画/範囲で対処されていない場合、特に重大な最悪のシナリオを持つリスクの高い変更については、バックアウト計画の要望を表明する必要があります。[2]

レビュー/承認

変更管理者、変更管理委員会、運営委員会、またはプロジェクトマネージャーのいずれであっても、通常、レビューと承認のプロセスが必要です。計画/範囲および影響/リスクの評価は、ビジネスの目標、要件、およびリソースのコンテキストで考慮されます。たとえば、変更要求が、修正するためにかなりのリソースを必要とする、重大度が低く影響が少ない問題に対処していると見なされる場合、要求は優先度が低くなるか、完全に棚上げされる可能性があります。影響力の大きい変更が要求されたが、強力な計画がない場合、レビュー/承認エンティティは、さらなる分析のために完全なビジネスケースを要求することができます。[1] [2] [7] [8]

ビルド/テスト

変更管理要求の進行が承認された場合、デリバリーチームは、テスト環境または開発環境での小規模な開発プロセスを通じてソリューションを実行します。これにより、配信チームは、ユニットテストや回帰テストを使用して、段階的な変更を設計および作成する機会が得られます。[1] [2] [7]リスクの低い変更については、テストと検証の方法がほとんど発生しない可能性がありますが、大きな変更には、実装前に重要なテストが必要になります。[7]次に、承認を求め、実装フェーズを実行する日時を要求します。ソリューションをテストできないまれなケースでは、変更/実装ウィンドウに対して特別な考慮を払う必要があります。[2]

実装

ほとんどの場合、変更を迅速に進めるための技術的専門知識を備えた特別な実装チームが、変更を実装するために使用されます。チームは、承認された計画だけでなく、組織の標準、業界の標準、および品質管理の標準に従っても変更を実装する必要があります。[7]実装プロセスでは、トラブルシューティングの支援を求められる可能性のある利害関係者を含む、実装チーム外の追加のスタッフ責任も必要になる場合があります。[2]実装後、チームは実装後のレビューを実行することもできます。これは、別の利害関係者会議またはプロジェクトの終了手順中に行われます。[1] [7]

を閉じる

クロージングプロセスは、変更管理のより困難で重要なフェーズの1つになる可能性があります。[9]この最終段階での3つの主要なタスクには、プロジェクトが実際に完了したかどうかの判断、「プロジェクト完了のコンテキストでのプロジェクト計画」の評価、およびプロジェクトの成功の具体的な証拠の提供が含まれます。[9]最善の努力にもかかわらず、変更管理プロセス中に問題が発生した場合は、将来の変更に学んだ教訓を適用する目的で、何が起こったかについて事後分析を実行する必要があります。[2]

規制環境

適正製造基準で規制されている業界では、このトピックはユーザーが頻繁に遭遇します。人々がこの概念を理解するために、さまざまな産業ガイダンスと解説が利用可能です。[10] [11] [12] 一般的な慣行として、活動は通常1つ以上のSOPによって指示されます。[13]臨床試験情報技術の観点から、それは別の米国食品医薬品局の文書によって導かれています。[14]

も参照してください

参照

  1. ^ a b c d e f Hall、PAV; ラミル、JCF(2007)。ソフトウェアエンタープライズの管理:コンテキスト内のソフトウェアエンジニアリングと情報システムセンゲージラーニング。pp。318–325。ISBN 97818448035452018年5月20日取得
  2. ^ a b c d e f g h i j Matteson、S.(2017年7月7日)。「変更管理管理の10の重要な要素」TechRepublicCBS Interactive、Inc 2018年5月20日取得
  3. ^ ターナー、SG(2003年12月15日)。製薬工学の変更管理テイラーアンドフランシス。pp。200  _ ISBN 9780849320613
  4. ^ Teixeira、MB(2013)。医療機器産業向けの設計管理(第2版)。CRCプレス。p。205. ISBN 9781466503557
  5. ^ Monahanm E.(1995)。エンジニアリングドキュメント管理の実践と手順CRCプレス。p。280. ISBN 9780824795740
  6. ^ Herzig、TW; Walsh、T .; ギャラガー、LA(2013)。ヘルスケアにおける情報セキュリティの実装:セキュリティプログラムの構築医療情報管理システム協会。pp。204–205。ISBN 97819389043562018年5月20日取得
  7. ^ a b c d e f g Taylor、J.(2008)。プロジェクトのスケジューリングとコスト管理:ベースラインの計画、監視、および管理J.ロス出版。pp。192–203。ISBN 97819321591102018年5月20日取得
  8. ^ abc オペレーショナル エクセレンス プログラムオフィス。「変更管理プロセス」(PDF)カリフォルニア大学バークレー校2018年5月20日取得
  9. ^ a b Taylor、J.(2008)。「第11章:プロジェクトを正常に終了する」プロジェクトのスケジューリングとコスト管理:ベースラインの計画、監視、および管理J.ロス出版。pp。215–225。ISBN 97819321591102018年5月20日取得
  10. ^ 「業界向けガイダンス:医薬品CGMP規制への品質システムアプローチ」(PDF)米国食品医薬品局2006年9月2009年7月12日取得
  11. ^ 注入。「規制対象業界における変更管理の課題」(PDF)2009年4月28日取得 [永久デッドリンク]
  12. ^ ICH「Q7:医薬品有効成分の適正製造基準ガイド」(PDF)2011年4月20日取得
  13. ^ GMPオンラインコンサルティング。「変更管理システム:標準操作手順」2009年4月28日取得
  14. ^ 「業界向けガイダンス-臨床試験で使用されるコンピューター化されたシステム」米国食品医薬品局1999年4月2021年5月13日取得