変更管理の10の黄金のルール
変更管理は複雑でリスクの高いプロセスである可能性があり、実装が不十分な場合、ビジネスに重大なリスクをもたらす可能性があります。堅牢な変更管理ポリシーを構築するための10のゴールデンルールを学びます。
“href =” https://www.techrepublic.com/a/hub/i/r/2021/08/30/ ad3adc0f-b638-4379-bb57-6c64fd9d3603/ resize /770x / 8faff41a1d66e14b396123cc858acabb / change-management.jpg “target =” _ blank “> 画像：Yunus Malik / Shutterstock
変更管理は必然的に複雑です複雑なプロセスは、信頼できる手段によって適切に開発および実行された場合、あらゆる組織とその継続的な進化と成長に真の恩恵をもたらす可能性があります。テクノロジーでの作業には、変化が避けられないという点である程度の皮肉が伴いますが、実装が不十分な場合、事業運営に重大なリスクをもたらす可能性があります。
見る： 電源チェックリスト：ハードドライブ障害のトラブルシューティング(TechRepublic Premium)
私のキャリアの中で、変更の実行は仕事の中で最もストレスの多い要素の1つであることがわかりました。だから、私はこれらを思いついた10最良の結果を得るためにプロセスを安全に合理化するのに役立つゴールデンルール。
1。ホスト/サービス/ユーザーのメンテナンスウィンドウを確立する
特定のホストを再起動するのに良い時間はないかもしれませんが、1日のある時間帯の方が良い場合があります他より。これはITプロフェッショナルに人気のある概念ではありませんが、午前4時に変更のために停止されたサーバーは、午後4時に停止されたサーバーよりも影響が少ないと考えられます。システムのメンテナンスウィンドウ、サービスを特定して、この作業が停止を引き起こすかどうかに関係なく、システムで作業を実行するための最も安全な時間を特定するのに役立てます。ユーザーがアクセスを必要とする可能性が最も低い時間枠を特定するためにも同じことを行います。
2。変更の概要を示すフォームで使用する変更のロールアウトに関連する標準の用語とタスクのリストを作成します
フォームには、これらの用語とタスクを次のように組み込む必要があります。ルール3から8に関連する詳細も同様です。
- 説明を変更します。あなたがやろうとしていること。これが「何」です。
- 正当化と優先順位を変更します;変更の背後にある理由と、それがビジネスにとってどれほど重要であるか。これが「理由」です。
- 影響を受けるホスト/サービス/ users;どのような要素や人々が関与するのか。これは「誰」と「どこ」です
- 変更が実行されるメンテナンスウィンドウ。これが「いつ」です。
- 実装計画、技術検証計画とビジネス検証計画。これが「方法」です。実装計画では、変更を段階的にレイアウトする必要があります。
- 技術検証計画は、変更が成功したことを確認しますテクノロジの観点(たとえば、オペレーティングシステムがアップグレードされて実行されているか、ネットワークカードが交換された)
- ビジネス検証計画は、ビジネス運用の観点から変更が成功したことを確認します(たとえば、クライアントはアップグレードされたサーバーに接続してトランザクションを処理できます)。
- また、「正常に実装されました。 「実装されているが問題がある」、「実装されているがロールバックされている」、「問題のため実装されていない」
3。変更の準備と計画のための流動的な考え方を構築する
小さな影響から大きな影響まで、すべての変更は異なるため、一連の質問をするのに役立ちます変更のリスク要因と潜在的な損害を最小限に抑える方法を最もよく特定するための質問。
- 停止は発生しますか？発生した場合、どのくらいの期間、誰が影響を受けますか？
- この変更について誰に通知または関与する必要がありますか？誰がそれを承認する必要がありますか？
- 変更は調査されましたか？適切に準備およびテストされていますか？
- どのように最善を尽くすことができますか包括的な変更後の検証？
- どのように変更を構築できますか失敗をなくすために可能な限り最善の方法で？
4。最悪の場合の影響について変更を評価する
リスク評価を実施して、変更が影響を引き起こす場合の最悪のシナリオとは何か、およびどのように可能な限り迅速かつ効率的に回復することができます。これを変更フォームに含めます。
5。可能な場合は即時バックアウトを実行する機能を合理化します
問題が発生した場合は、変更を即座に最小限に戻すための最善の方法を特定します衝撃または損傷の量。優れた戦略では、元のサーバーの電源をオフにしてから再度オンにして、変更に失敗した場合にサービスを復元することにより、あるサーバーを別のサーバーに置き換える必要があります。
参照：チェックリスト：バックアップの管理方法(TechRepublic Premium)
一部の変更により、本質的に取り消されてはいけません。重要なサーバーで故障したハードドライブを交換しようとしても、故障したドライブをサーバーに戻すことにはならないため、バックアウト計画に関して合理的な期待を設定してください。
6。バックアウト計画
を含む、変更に関連するすべてのタスクの時間枠を確立します。たとえば、4時間のメンテナンス期間の場合、スケジュールを立てることができます。実装計画に2時間、30技術検証計画の議事録、30ビジネス検証計画の場合は分、バックアウト計画の場合は1時間。これにより、メンテナンスウィンドウのしきい値を超えないようにすることができます(ただし、安全のために、超えた場合に何が起こるかを考慮してください)。
7。すべての利害関係者に情報を提供し、変更に参加します
変更に関与または影響を受けるすべての担当者が詳細と影響を認識していることを確認します。懸念や異議はありません(または、そうする場合は、これらは十分に対処されます)。
8。徹底した承認プロセスを実施する
承認には、管理職および経営幹部が関与し、続行する許可を発行する権限だけでなく、技術的ノウハウに基づく必要があります。変更手順が適切であることを確認します。承認では、リスク評価を考慮し、優先順位を変更する必要があります。
9。承認された変更フォームを使用して変更管理プロセスに従います
すべてのタスクを適切に閉じて、完了または失敗としてマークします。
08。該当する場合は、何がうまくいかなかったのか、その理由を確認して特定し、変更を取り消して失敗しました。
直接の過失がない限り、非難ゲームに参加することは避けてください。それに応じてそのような失敗に対処します。変更を正常にやり直すための戦略を作成します。
エグゼクティブブリーフィングニュースレター
プロジェクト管理、予算、および日常業務に関するこれらのヒントを使用して、ITリーダーシップの成功の秘訣を発見してください。 -日の課題。火曜日と木曜日に配信
今日サインアップする
