変更管理基準
ソフトウェアやその他の業界で広く受け入れられている変更管理標準はありますか？私は、ターゲットドメインがまったく異なるいくつかの企業（投資銀行と電気通信）で働いていました。企業は、非常によく似たグローバル変更管理（GCM）の組織とプロセスを持っていました。すなわち：
- GCM部門会社全体のファイアウォールの変更、データベースの割り当て/サポート、バージョン管理システムのサポートなど、IT関連のすべての変更を担当していました。
- 変更がフリーズするのような概念がありました。変更の実装日が変更の凍結日と同じである場合、変更を実装することができませんでした。
- 全員が変更の必要性と重要性について話し合ったとき、GCM会議（電話会議）がありました。毎週同時にGCM部門の代表者が主催しました（火曜日、グリニッジ標準時17:00など）。
- 変更は変更承認者によって承認されている必要があります。必須の承認者グループの独自のリストを持つさまざまな種類のリクエストがありました。グループには、異なるタイムゾーンで作業する複数のメンバーがいました。グループ全体で変更を承認するには、少なくとも1人のそのようなメンバーがGCMを承認している必要があります。予定された実施時期が来る前に、すべての必須の承認者グループの承認が収集されている必要がありました。それ以外の場合は、実装されないことが100％保証されていました。
- 官僚主義 GCMプロセスの注目に値する。それは純粋でした官僚的な地獄。ツールはひどく、人々は遅くて頑固でした。小さな変更でも実装することはほぼ不可能でした。実装時間の前に最後の承認を取得できなかったり、突然、変更のフリーズ時に実装時間がスケジュールされていることが判明したりしました。
GCMプロセスと、それらがさまざまな企業でどのように機能するかについて一般的に理解できるように、それを見てみたいと思います。どこでもそうひどいなのか、それとも特定の会社でのGCMプロセスの実装が不十分だったのかを知りたいのですが。
チェックアウト [〜＃〜] itil [〜＃〜] 。これは、ITインフラストラクチャを管理するためのプラクティスとガイドラインのコレクションです。設備、電源、機器、オペレーティングシステムソフトウェア、フレームワーク、データベース、およびアプリケーションを管理するプロセスを設定できます。
理想的には、変更の「障壁」は既存の資産を保護することを目的としており、リスクの少ない付加価値のある変更をブロックし、リスクの少ない付加価値のある変更を克服できるように十分に強力である必要があります。