Ini bukan momen terbaik dalam seminggu, ketika perubahan gagal setelah berjam-jam persiapan dan pekerjaan ekstensif selama jendela eksekusi. Selain itu, ia juga memecah hal-hal lain. Kadang-kadang jelas setelah penerapan, tetapi kadang Anda menemukannya berjam-jam atau berhari-hari kemudian. Jika beruntung, Anda dapat menerapkan perubahan darurat untuk memperbaiki akar masalah yang sangat jelas, seperti kehilangan item pada daftar periksa penerapan Anda. Namun, dalam banyak kasus hal ini tidak dapat dilakukan dan Anda perlu membatalkan perubahan tersebut.
Kunci sukses berhenti adalah memiliki rencana. Ya, rencana untuk mundur, sesuatu yang sering terlewatkan. Bagaimanapun, Anda ingin ulasan Anda menjadi penyerahan yang terhormat, bukan pelarian dari kepanikan. Untuk membatasi kerusakan pada bisnis dan reputasi Anda, Anda harus tetap mengendalikan situasi. Untuk melakukan ini, tim teknik perlu mengetahui apa yang harus dilakukan dan biro layanan perlu terus mengetahui pekerjaan tersebut.
Rencana backout bertujuan untuk membuat Anda tetap memegang kendali. Ini polis asuransi Anda terhadap Hukum Murphy. Jujurlah dengan diri kita sendiri: kita tidak percaya pada segalanya. Bukan rencana dukungan formal untuk setiap perubahan. Pastikan saja tim tersebut dapat menjelaskan secara lisan bagaimana untuk kembali jika keadaan menjadi berantakan.
Namun, Anda memang membutuhkan rencana yang lebih formal untuk membuat perubahan yang lebih kompleks. Membuat rencana seperti itu adalah salah satu aktivitas yang paling tidak disukai oleh banyak ahli teknologi. Itulah sebabnya manajer perubahan harus bertanggung jawab untuk melakukan ini. Ini harus dilampirkan ke dokumen perubahan lainnya, sehingga siap digunakan jika perlu.
Rencana dukungan yang baik harus mencakup:
- Instruksi teknis tingkat rendah,
- Instruksi kontak khusus, dengan nama kontak.
Daftar instruksi teknis dibuat dengan membalik urutan kegiatan dari rencana implementasi Anda dan menjelaskan cara membatalkan setiap langkah yang dilakukan. Ini akan relatif sederhana jika sebagian besar pekerjaan dapat diselesaikan dengan memulihkan cadangan terbaru. Pertimbangkan contoh rencana backit untuk skenario seperti itu:
- Beri tahu meja layanan tentang permulaan rencana PACT. (Hubungi mereka, kirim email, atau ajukan tiket – sebutkan secara spesifik.)
- Nonaktifkan akses pengguna ke sistem. (Bagaimana caranya? Buatlah daftar tindakan.)
- Pulihkan cadangan yang diambil sebelum perubahan diterapkan. (Buat daftar tindakan yang diperlukan).
- Pemeriksaan kesehatan sistem (letakkan semuanya)
- Aktifkan akses pengguna.
- Beri tahu biro layanan tentang akuisisi yang berhasil.
Rencananya seringkali lebih rumit dari yang terlihat. Mungkin ada banyak langkah pemulihan, termasuk berbagai database, sistem file, dan area infrastruktur TI lainnya. Template dasar masih berlaku. Ini harus dirinci dan rinci untuk setiap organisasi dan setiap perubahan. Tak perlu dikatakan, setiap tindakan harus ada pemiliknya, jadi pastikan jelas siapa yang melakukan apa.
Komunikasi dengan meja layanan sangat penting. Komunikasi umumnya harus menjadi bagian dari rencana untuk mempertahankan kendali atas situasi. Selain itu, bisnis perlu mengetahui bahwa TI memegang kendali. Biro layanan harus tertarik untuk memproyeksikan citra kontrol terhadap pekerjaan. Mereka dapat melakukannya dengan melakukan komunikasi rutin jika dampak bisnisnya cukup parah. Mereka juga akan menerima panggilan dari pengguna yang tidak senang dan memberi tahu mereka tentang status solusi.
Rencana backout adalah polis asuransi Anda. Terserah Anda untuk mendapatkannya atau tidak. Disarankan untuk memilikinya untuk setiap perubahan yang kompleks, karena kelangsungan bisnis dan keandalan TI dipertaruhkan. Mulailah dengan menyiapkan rencana seperti itu untuk perubahan paling kompleks yang akan dibawa ke saluran Anda. Kemudian kembangkan itu dan seiring waktu Anda akan siap untuk semua perubahan berisiko tinggi.
Source by Piotr Chec
