Ini bukan momen terbaik dalam seminggu, ketika setelah berjam-jam persiapan dan kerja keras selama jendela implementasi, perubahan Anda gagal. Selain itu, merusak hal-hal lain juga. Terkadang, ini terbukti tepat setelah penerapan, tetapi terkadang Anda mengetahuinya beberapa jam atau hari kemudian. Jika Anda beruntung, Anda dapat menerapkan perubahan darurat untuk memperbaiki akar penyebab yang cukup jelas, misalnya kehilangan salah satu item pada daftar periksa implementasi. Namun, dalam banyak kasus, hal itu tidak dapat dilakukan dan Anda harus membatalkan perubahan tersebut.

Kunci sukses backout adalah memiliki rencana. Ya, backout plan, hal yang sering terabaikan. Bagaimanapun, Anda ingin backout Anda menjadi penyerahan yang terhormat, bukan melarikan diri karena panik. Untuk membatasi kerusakan pada bisnis, dan reputasi Anda, Anda harus tetap mengendalikan situasi. Untuk melakukan itu, tim teknisi perlu mengetahui apa yang harus dilakukan dan Meja Layanan perlu terus menginformasikan bisnis.

Rencana backout dimaksudkan agar Anda tetap memegang kendali. Ini adalah polis asuransi Anda terhadap Hukum Murphy. Jujurlah dengan diri kita sendiri: kita tidak mengasuransikan segalanya. Jangan menyiapkan rencana backout formal untuk setiap perubahan. Pastikan saja tim dapat menjelaskan secara lisan cara kembali jika ada yang berantakan.

Anda memang membutuhkan rencana yang lebih formal untuk perubahan yang lebih kompleks. Membuat rencana seperti itu adalah salah satu aktivitas yang paling tidak disukai oleh banyak orang teknis. Itulah mengapa Manajer Perubahan harus bertanggung jawab untuk menyelesaikannya. Ini harus disertakan dengan dokumentasi perubahan lainnya, siap digunakan jika perlu.

Rencana backout yang baik harus mencakup:

  • tingkat rendah, instruksi teknis,
  • instruksi komunikasi khusus, dengan nama kontak.

Daftar instruksi teknis dibuat dengan membalik urutan kegiatan dari rencana implementasi Anda dan menjelaskan cara mundur dari setiap langkah yang dijalankan. Mungkin relatif mudah jika sebagian besar pekerjaan dapat diselesaikan dengan memulihkan cadangan terbaru. Pertimbangkan contoh rencana backout untuk skenario seperti itu:

  • Beri tahu Meja Layanan tentang permulaan rencana backout. (Hubungi mereka, kirim email atau ajukan tiket – sebutkan secara spesifik.)
  • Nonaktifkan akses pengguna ke sistem. (Bagaimana? Buat daftar tindakannya.)
  • Pulihkan cadangan yang diambil sebelum implementasi perubahan. (Buat daftar tindakan yang diperlukan.)
  • Lakukan pemeriksaan kesehatan sistem. (Buat daftar semuanya.)
  • Aktifkan akses pengguna.
  • Beri tahu Meja Layanan tentang pencadangan yang berhasil.

Seringkali rencananya akan lebih kompleks dari yang terlihat. Mungkin ada lebih banyak langkah pemulihan, yang melibatkan berbagai database, sistem file, dan area infrastruktur TI lainnya. Template dasar masih berlaku. Ini perlu dirinci dan disesuaikan dengan setiap organisasi dan setiap perubahan. Tak perlu dikatakan, setiap tindakan harus ada pemiliknya, jadi pastikan jelas siapa melakukan apa.

Berkomunikasi dengan Service Desk sangatlah penting. Komunikasi secara umum perlu menjadi bagian dari rencana untuk mempertahankan kendali atas situasi. Selain itu, bisnis perlu mengetahui bahwa TI memegang kendali. Meja Layanan harus berhati-hati dalam memproyeksikan citra kendali terhadap bisnis. Mereka dapat melakukannya dengan melakukan komunikasi secara berkala jika dampak bisnis cukup parah. Mereka juga akan menerima panggilan dari pengguna yang tidak puas dan memberi tahu mereka tentang status resolusi.

Rencana backout adalah polis asuransi Anda. Terserah Anda untuk memilikinya atau tidak. Disarankan untuk memilikinya untuk setiap perubahan yang kompleks, karena kelangsungan bisnis dan kredibilitas TI dipertaruhkan. Mulailah dengan mempersiapkan rencana seperti itu untuk perubahan paling kompleks yang akan Anda hadapi dalam proses pipeline Anda. Kemudian kembangkan itu dan seiring waktu Anda akan menyiapkannya untuk semua perubahan berisiko tinggi.



Source by Piotr Chec