ビジネスの世界では、紛らわしい流行語や業界用語が使用されることで知られています。 これは、標準変更と通常変更の区別に関しても同様です。
多くの人が “通常変更と標準変更の違いは何ですか?” と自問するのは当然のことでしょう。
変更というウサギの穴に入る前に、そもそも「変更」と言ったときに何を意味しているのか、同じページにいることを確認しましょう。
今すぐダウンロード。 ITIL 4 Best Practice e-Books
2020年に向けて一新されたITIL e-booksは、ITIL 4のベストプラクティスの重要な要素を強調しています。
変更とは
ITビジネスの世界、特にITILマネジメントの世界では、変更とは組織のソフトウェアアプリケーションを変更することであり、それが内部アプリケーションであっても顧客向け製品であっても同じことです。
この変更管理のプロセスは、変更マネージャと変更諮問委員会 (CAB) によって処理されます。
- 標準的な変更
- 通常の変更
これらの特定の定義および指定は、ニーズによって組織ごとに変わるかもしれませんが、それらが動作する傾向があるいくつかの一般的なルールが存在します。
(後で説明する緊急の変更とは、より緊急で機密性の高い変更であり、通常は CAB のサブセットである緊急変更諮問委員会が取り扱います。)
標準の変更とは
標準の変更は、ルーチン変更とも呼ばれますが、事前に承認された変更で、それに伴うリスクがほとんどないものと見なされる傾向にあります。 これらは、特定のガイドラインと手順に従った、かなり一般的に行われる変更です。 標準的な変更は、多くの場合、繰り返しの手順で実施され、めったに修正は必要ありません。
標準的な変更は、多くの場合、プロセスのスピードアップと効率アップのために自動化が可能な領域です。 これらの変更は、確実に成功につながる、きちんと順序付けられた体系的なアプローチに洗練されています。
ITIL変更管理では、標準的な変更を次のように定義しています:
「リスクが低く、比較的よくある、手順または作業指示に従う事前承認の変更」
標準を、ITがエンド ユーザーに提供するサービスと考えてみてください。
- ハードウェアのライフサイクル交換
- ソフトウェアのパッチ適用と更新
- ファイアウォールの変更
- 新しい DNS エントリ
これらはすべて、変更要求または要件が発生したらすぐに実行できる承認済みのタスクの例です。 このような変更の承認後、変更要求の実行に必要なのは最小限の計画だけです。
標準的な変更には、プリンター、ワークステーション、およびネットワーク デバイスの更新サイクルなど、特定のスケジュールに従った運用上の変更も含まれる場合があります。 標準的な変更を承認する前に、徹底的なリスク評価手順が実行されます。
承認と事前承認は組織またはサービスプロバイダーの裁量に任されているため、標準的な変更として記述されています。 変更の実施に関わる手順は十分に文書化されています。 関連するリスクは事前に十分に計算され、説明されている。 必要なリスク軽減措置は、変更実施手順の一部として実施される。
ITサービス要求を標準的な変更とすることは、ITサービスマネジメント (ITSM) の観点からも利点があります。 特に、情報や部門のサイロが変更の実装に不必要な遅延や制限を引き起こす可能性がある場合、変更プロセスは最小限の摩擦で流れます。 事前承認、文書化された実施手順、および広範なリスク評価をすでに持っていることにより、IT は要求されたサービスを効率的かつ効果的に提供することができ、それはまさに変更管理に関連する ITIL フレームワークの目標です。 一般に、標準的な変更は、予定されたメンテナンス ウィンドウの間に滞りなく行われ、実際のサービスにはほとんど影響を与えません (たとえあったとしても)。 これは、直接の監視と慎重な検討を必要とする緊急の変更とは正反対です。
緊急の変更とは
緊急の変更は、基本的に標準の変更と正反対です。 ITILでは緊急の変更を次のように定義しています：
「できるだけ早く導入されなければならない変更」です。
緊急の変更の例としては、
- ゼロデイ攻撃に対するセキュリティパッチの実装
- 大規模なDDoS攻撃からのネットワークの隔離
これらの変更は、通常、危機または過度のリスクなしに対処しなければならない機会を表します。 したがって、許容可能なレベルのリスクが期待され、リスク軽減戦略として特定の手順に従います。
これは、CAB メンバー間の長時間の会議を意味するのではなく、変更管理プロセスに対するハイレベルな監視を意味します。 このプロセスは、変更管理プロセスの各段階において、すべての利害関係者の迅速な行動を踏襲しなければなりません。
組織の俊敏性は、緊急の変更をどの程度うまく管理できるかを決定します。 これは、通常の変更と同様の変更管理プロセスフローに従いますが、ITILガイドラインに従って加速されたタイムスケールで行われます。 緊急の変更にうまく対処できるかどうかで、エンドユーザーに提供するITサービスの安定性が決まります。
また、緊急変更の管理プロトコルに、修復またはバックアウトプロセスを含める必要があります。 これは、変更の実施により追加のリスクや問題が発生した場合に、元の状態に戻すことができるようにするためです。
緊急の変更は、予想された時期に行われるものではなく、ありふれたものでもありません。 緊急の変更は、セキュリティの欠陥や悪用など、予期せぬ障害への対応としてもたらされます。 緊急の変更は、チェンジ マネージャーの注意を即座に引き、その後、さらなる分析のために ECAB に送られます。 提案された緊急の変更のリスクを評価し、根本的な問題が組織とそのサービスにもたらす危険を計量するのは、ECAB の義務です。
ECABは、新たに発見された問題に対する迅速かつ効果的な救済策を見つけようとし、ほとんどの変更操作に関わる典型的なお役所仕事をする余地がないほど、厳しい期限で作業します。 情報を迅速に収集、分析し、目の前の問題を改善するための最善の行動を決定する必要があります。 緊急の変更は、迅速にテストされ、必要なときに直ちに実行されます。 緊急変更の目的は、稼働中のサービスにできるだけ影響を与えず、できるだけ早く出血を止めることです。
緊急の変更と標準の変更の中間に位置するのが通常の変更です。
通常の変更とは何ですか
ほとんどの組織は、通常の変更を緊急の変更でも標準の変更でもないすべての変更と定義します。 通常の変更は、標準の変更のように事前に承認されたものではありませんが、緊急の変更のように厳しいタイムラインや、お役所仕事や窮屈なガイドラインからの解放を必要とするようなワイルド ウェスト的な性質のものでもありません。
これにより、変更を監視し、標準の変更に変換できる再現可能なガイドラインを与えられるほど、この標準の変更が頻繁に発生するかどうかを評価する機会が、CAB に提供されます。
通常の変更はかなり一般的ですが、一般に、ステップバイステップのガイドまたはいくつかの基本的なアウトラインの使用によって達成できる標準の変更とは異なり、多少ユニークまたは斬新なアプローチを必要とします。 通常の変更は、自己レビューを行い、チームが割り当てられた範囲内で変更を分析し、その実行可能性を評価してから、CAB に渡します。
ITILは通常の変更を次のように定義しています:
「緊急の変更でも標準の変更でもない変更です。
これらの変更は、標準化されたプロセスに従って評価され、承認され、次にスケジュールされる必要があります。 これらの変更は事前に予期され、計画され、それに応じて適切な標準化された変更管理コントロールが考案されるかもしれません。 しかし、通常の変更は、正式な承認と認可を受けた後にのみ実施されます。 低リスクの変更であれば、ローカルのITチームからの承認が必要かもしれないが、高リスクの変更であれば、CABまたはビジネスとITの上級幹部からの承認が必要かもしれない。
例としては、重要な情報リソース、アプリケーション、およびワークロードをオンプレミス サーバーからクラウド データセンターに移行することなどがあります。
変更を通常と定義することにより、組織および IT サービス プロバイダーのリスクが低減します。 しかし、通常の変更の実装は、長くて時間のかかるプロセスでもあります。 承認と認可のプロセスに加え、サービス プロバイダーは、変更プロセス、対象システム、および関連する依存関係に対する強力な可視性と制御を必要とします。
したがって、通常変更の管理と実装には、変更プロセスとシステムを慎重に分析、テスト、管理、および実行するための高度な ITSM テクノロジーが必要です。 通常変更が実施されると、IT 部門は実施の成功と同様の変更に関する将来の要件を評価します。 理想的には、IT部門は変更管理プロセス、ツール、および能力を成熟させ、通常変更を標準変更に変換します。 これにより、IT 部門とサービス プロバイダーが変更を管理する負担が軽減され、同時に、標準変更で達成されたように、変更管理プロセスの制御が可能になります。
この変更管理プロセスは、リスクを減らしダウンタイムを最小限に抑えながら実装の成功率を高めるのに役立ちます。 さまざまな種類の変更とその分類は、変更プロセス全体の円滑な運用を助けます。 標準的な変更は、ほとんど監視することなく行われますが、緊急の変更には慎重な管理と詳細な分析が必要です。
標準変更、標準変更、および緊急変更の区別は、命名規則の違いを超えて、概念的な観点から観察する必要があります。 標準と標準という用語は同義語のように見えますが、根本的な違いは、変更管理の手順とコントロールの有効性を表しています。 したがって、変更要件につながる変更要求とインシデントを慎重に評価することによって、3 つの変更の種類を識別する強力な変更可能化プラクティスを持つことが重要です。
これらの 3 種類の変更は、組織が、現代の DevOps 組織に求められる一定のペースを維持しながら、問題が発生するとそれに対処するのに役立ちます。
関連記事
- BMC Service Management Blog
- Types & Levels of Change Management
- Change Management in the Cloud
- Organizational Change Management (OCM): A Template for Reorganizing IT
- Facilitating Change through Effective Communication