変更管理基準

ソフトウェアおよびその他の業界で広く受け入れられている変更管理標準はありますか？私はターゲットドメインがまったく異なる複数の企業で働いていました（投資銀行と通信）。企業は、非常によく似たグローバル変更管理（GCM）の組織とプロセスを持っていました。すなわち：

1. 全社的なファイアウォールの変更、データベースの割り当て/サポート、バージョン管理システムのサポートなど、IT関連のすべての変更を担当するGCM部門がありました。
2. 変更がフリーズするような考えがありました。変更の実装日が変更の凍結日と同じ場合、変更を実装することができませんでした。
3. ありましたGCM会議（カンファレンスコール）誰もが彼らの変更の必要性と重要性を議論したときには。GCM部門の担当者が毎週同時に開催しました（火曜日、グリニッジ標準時17:00など）。
4. 変更は変更承認者によって承認されている必要があります。必須の承認者グループの独自のリストを持つさまざまな種類の要求がありました。グループには、いくつかのメンバーが異なるタイムゾーンで働いていました。グループ全体が変更を承認するためには、少なくとも1人のメンバーがGCMを承認している必要があります。スケジュールされた実装時間になる前に、すべての必須の承認者グループの承認が収集されている必要がありました。それ以外の場合は、実装されないという100％の保証がありました。
5. GCMプロセスの官僚主義は注目に値しました。それは純粋な官僚の地獄でした。ツールはひどく、人々は遅くて頑固でした。小さな変更を実装することはほぼ不可能でした。実装時間の前に最後の承認が得られない場合や、変更の凍結時に実装時間がスケジュールされていることが突然判明した場合があります。

私はそれを見てみたいので、GCMプロセスとそれらがさまざまな会社でどのように機能するかについての一般的な理解を得たいと思います。それがどこでもひどいひどいものなのか、それとも特定の企業でのGCMプロセスの実装が不十分なだけなのか知りたい。

ITILをチェックしてください。これは、ITインフラストラクチャを管理するための実践とガイドラインの集まりです。設備、電力、機器、オペレーティングシステムソフトウェア、フレームワーク、データベース、アプリケーションを管理するプロセスを設定できます。

理想的には、変更の「障壁」は既存の資産を保護することを意図しており、大きなリスクでほとんど付加価値のない変更がブロックされ、リスクがほとんどない付加価値のある変更でそれらを克服できるように十分に強力である必要があります。