
Halo semuanya, nama saya Igor Tyukachev, dan saya konsultan kelangsungan bisnis. Dalam posting hari ini,
kita akan membahas kebenaran bersama secara panjang lebar dan membosankan. Saya ingin berbagi pengalaman dan berbicara tentang kesalahan utama yang dibuat perusahaan ketika mengembangkan rencana untuk memastikan kelangsungan kegiatan mereka.
1. RTO dan RPO secara acak
Kesalahan paling penting yang saya temui adalah waktu pemulihan (RTO) diambil dari langit-langit. Nah, seperti dari langit-langit - misalnya, ada beberapa angka dua tahun lalu dari SLA, yang seseorang bawa dari tempat kerja sebelumnya. Mengapa mereka melakukan ini? Setelah semua, sesuai dengan semua teknik, Anda pertama-tama perlu menganalisis konsekuensi untuk proses bisnis, dan berdasarkan analisis ini, menghitung waktu pemulihan target dan kehilangan data yang diijinkan. Tetapi untuk melakukan analisis seperti itu kadang-kadang panjang, kadang-kadang mahal, kadang tidak terlalu jelas bagaimana menekankan yang diperlukan. Dan hal pertama yang terlintas di benak banyak orang:
“Kita semua adalah orang dewasa dan kita memahami cara kerja bisnis. Kami tidak akan membuang waktu dan uang! Mari kita mengambil plus atau minus, sebagaimana mestinya. Dari kepala, menggunakan kecerdikan proletar! Biarkan RTO sama dengan dua jam. "Apa yang menyebabkan ini? Ketika Anda datang ke manajemen untuk mendapatkan uang untuk kegiatan guna memastikan RTO / RPO yang diperlukan dengan angka-angka tertentu, itu selalu membutuhkan pembenaran. Jika tidak ada pembenaran, muncul pertanyaan: dari mana Anda mendapatkannya? Dan tidak ada jawaban. Akibatnya, kepercayaan pada pekerjaan Anda hilang.
Selain itu, terkadang pemulihan dua jam ini bernilai satu juta dolar. Dan alasan untuk durasi RTO adalah masalah uang, dan sangat besar.
Dan akhirnya, ketika Anda datang dengan rencana BCP dan / atau DR Anda kepada para pemain (yang akan langsung berlari dan melambaikan tangan mereka pada saat kecelakaan), mereka akan mengajukan pertanyaan serupa: dari mana datangnya dua jam ini? Dan jika Anda tidak dapat menjelaskan ini dengan jelas, maka mereka tidak akan memiliki kepercayaan pada Anda atau pada dokumen Anda.
Ternyata selembar kertas demi selembar kertas, berhenti berlangganan. Ngomong-ngomong, beberapa melakukannya dengan sengaja untuk sekadar memenuhi persyaratan regulator.
Anda mengerti?2. Obat untuk semuanya
Beberapa percaya bahwa rencana BCP dirancang untuk melindungi semua proses bisnis dari ancaman apa pun. Baru-baru ini, pertanyaan "Apa yang ingin kita bela diri?" Saya mendengar jawabannya: "Dari segalanya dan banyak lagi."

Tetapi kenyataannya adalah bahwa rencana tersebut dirancang hanya untuk melindungi proses bisnis utama perusahaan dari ancaman
tertentu . Oleh karena itu, sebelum mengembangkan rencana, perlu untuk menilai terjadinya risiko dan menganalisis konsekuensinya bagi bisnis. Penilaian risiko diperlukan untuk memahami ancaman seperti apa yang ditakuti perusahaan. Dalam hal membangun kehancuran, akan ada satu rencana untuk memastikan kesinambungan, dalam kasus tekanan sanksi - yang lain, jika terjadi banjir - yang ketiga. Bahkan di dua situs identik di kota yang berbeda, rencana dapat sangat bervariasi.
Anda tidak dapat melindungi seluruh perusahaan dengan satu BCP, terutama yang besar. Misalnya, Grup Ritel X5 yang besar mulai menyediakan kontinuitas dengan dua proses bisnis utama (kami menulis tentang ini di
sini ). Dan untuk melampirkan seluruh perusahaan dengan satu rencana sama sekali tidak realistis, ini berasal dari kategori "tanggung jawab kolektif", ketika semua orang bertanggung jawab dan tidak ada yang bertanggung jawab.
Dalam standar ISO 22301 ada konsep kebijakan yang dengannya, sebenarnya, proses kontinuitas dalam perusahaan dimulai. Itu menggambarkan apa yang akan kita lindungi dan dari apa. Jika orang-orang berlari dan meminta untuk menambahkan ini, misalnya:
- Dan mari kita tambahkan ke BCP risiko kita diretas?Atau
- Di sini kita baru-baru ini membanjiri lantai terakhir dalam hujan - mari kita tambahkan skrip, apa yang harus dilakukan jika terjadi banjir?Kemudian segera kirim mereka ke kebijakan ini dan katakan bahwa kita melindungi aset perusahaan tertentu dan hanya dari ancaman khusus yang telah disepakati sebelumnya, karena mereka sekarang dalam prioritas.
Dan bahkan jika proposal untuk perubahan benar-benar tepat, maka tawarkan untuk memperhitungkannya dalam versi kebijakan selanjutnya. Karena melindungi perusahaan adalah banyak uang. Jadi semua perubahan pada rencana BCP harus melalui komite anggaran dan perencanaan. Kami merekomendasikan untuk meninjau kebijakan kelangsungan bisnis perusahaan setahun sekali atau segera setelah perubahan signifikan dalam struktur perusahaan atau lingkungan eksternal (pembaca memaafkan saya atas kata-kata seperti itu).
3. Fantasi dan kenyataan
Sering terjadi bahwa ketika menyusun rencana BCP, penulis menggambarkan beberapa gambaran ideal dunia. Misalnya, "kami tidak memiliki pusat data kedua, tetapi kami akan menulis rencana seolah-olah kami memilikinya." Atau bisnis belum memiliki bagian dari infrastruktur, tetapi karyawan masih akan membawanya ke dalam rencana dengan harapan akan muncul di masa depan. Dan kemudian perusahaan akan menarik kenyataan ke dalam rencana: membangun pusat data kedua, menggambarkan perubahan lain.
Di sebelah kiri adalah infrastruktur yang sesuai BCP, di sebelah kanan adalah infrastruktur nyata
Semua ini adalah kesalahan. Menulis rencana BCP berarti menghabiskan uang. Jika Anda menulis rencana yang tidak akan berfungsi saat ini, maka Anda akan membayar kertas yang sangat mahal. Tidak mungkin untuk pulih dari itu, tidak mungkin untuk mengujinya. Ternyata bekerja demi pekerjaan.
Anda dapat menulis sebuah rencana dengan cukup cepat, dan membangun infrastruktur cadangan, mengeluarkan uang untuk semua solusi perlindungan adalah proses yang panjang dan mahal. Ini bisa memakan waktu lebih dari satu tahun. Dan mungkin ternyata Anda sudah punya rencana, dan infrastruktur untuk itu akan muncul dalam dua tahun. Mengapa kita membutuhkan rencana seperti itu? Apa yang akan dia lindungi darimu?
Dari kategori fantasi, ketika tim pengembangan BCP mulai memikirkan untuk para ahli apa yang harus mereka lakukan dan untuk berapa lama. Ternyata dari kategori: “ketika Anda melihat beruang di taiga, Anda perlu berbalik ke arah yang berlawanan dari beruang dan berlari dengan kecepatan melebihi kecepatan beruang. Di bulan-bulan musim dingin, penting untuk menutupi jejak. ”
4. Atasan dan akar
Kesalahan paling penting keempat adalah bahwa rencana itu dibuat terlalu dangkal atau terlalu rinci. Butuh jalan tengah. Rencananya tidak boleh terlalu rinci
untuk orang idiot , tetapi tidak boleh terlalu umum sehingga hal seperti ini tidak terjadi:
Mudah5. Ke Caesar - Kaisarean, tukang kunci - Tukang Kunci
Kesalahan berikut berasal dari yang sebelumnya: semua tindakan untuk semua tingkat manajemen tidak dapat diintegrasikan ke dalam satu rencana. Rencana BCP biasanya dikembangkan untuk perusahaan besar dengan aliran keuangan yang besar (omong-omong, menurut
penelitian kami, rata-rata, 48% dari perusahaan besar Rusia menghadapi kemungkinan yang menyebabkan kerugian finansial yang signifikan) dan sistem manajemen multi-level. Untuk perusahaan seperti itu, Anda tidak boleh mencoba memasukkan semuanya ke dalam satu dokumen. Jika perusahaan besar dan terstruktur, maka rencana tersebut harus memiliki tiga tingkatan terpisah:
- tingkat strategis - untuk manajemen senior;
- tingkat taktis - untuk manajer menengah;
- dan tingkat operasional - untuk pemain langsung di lapangan.
Misalnya, jika ini adalah masalah memulihkan infrastruktur yang jatuh, maka keputusan dibuat di tingkat strategis untuk mengaktifkan rencana restorasi, prosedur proses dapat dijelaskan di tingkat taktis, dan instruksi tentang cara menugaskan item peralatan tertentu di tingkat operasional.
BCP tanpa anggaranSetiap orang melihat bidang tanggung jawab dan komunikasi mereka dengan karyawan lain. Pada saat kecelakaan, semua orang membuka rencana, dengan cepat menemukan bagiannya dan mengikutinya. Idealnya, Anda perlu mengingat dengan hati-hati halaman mana yang akan dibuka, karena kebetulan hitungannya berlangsung beberapa menit.
6. Bermain peran
Kesalahan lain dalam persiapan rencana BCP: Anda tidak perlu menentukan nama, alamat email, dan informasi kontak lainnya dalam rencana tersebut. Dalam teks dokumen itu sendiri, hanya peran yang direpersonalisasikan yang harus diindikasikan, dan peran orang-orang yang bertanggung jawab untuk tugas-tugas tertentu harus ditugaskan ke peran-peran ini dan kontak mereka harus tercantum dalam lampiran rencana.
Mengapa
Saat ini, kebanyakan orang berganti pekerjaan setiap dua atau tiga tahun. Dan jika Anda menuliskan semua orang yang bertanggung jawab dan kontak mereka dalam teks rencana, maka itu harus terus-menerus diubah. Dan di perusahaan besar, dan terlebih lagi yang menyatakan, setiap perubahan pada dokumen apa pun membutuhkan banyak persetujuan.
Belum lagi jika terjadi keadaan darurat, dan Anda harus dengan panik membuka rencana dan mencari kontak yang diinginkan, maka waktu yang berharga akan hilang.
Retas seumur hidup: ketika Anda mengubah aplikasi, Anda bahkan sering tidak perlu menyetujuinya. Satu petunjuk lagi: Anda dapat menggunakan sistem otomasi untuk memperbarui paket.
7. Kurang versi
Biasanya mereka membuat paket versi 1.0, dan kemudian membuat semua perubahan tanpa mengedit, dan tanpa mengubah nama file. Namun, seringkali tidak jelas apa yang telah berubah dibandingkan dengan versi sebelumnya. Dengan tidak adanya versi, rencana hidup sendiri, yang tidak dilacak dengan cara apa pun. Halaman kedua dari rencana BCP harus mencakup versi, pembuat perubahan, dan daftar perubahan itu sendiri.
Tidak ada yang bisa mengetahuinya
8. Siapa yang bertanya?
Seringkali perusahaan tidak memiliki BCP yang bertanggung jawab dan tidak ada unit kesinambungan bisnis yang terpisah. Tanggung jawab kehormatan ini terletak pada CIO, wakilnya, atau pada prinsip bahwa "Anda terlibat dalam keamanan informasi, di sini Anda memiliki BCP sebagai tambahan." Sebagai hasilnya, rencana tersebut dikembangkan, disetujui dan disetujui oleh semua orang, dari atas ke bawah.
Dan siapa yang bertanggung jawab untuk menyimpan rencana, memperbarui, dan meninjau informasi di dalamnya? Ini mungkin tidak ditentukan. Untuk mengambil seorang karyawan untuk hal ini adalah pemborosan, dan untuk membebani salah satu yang ada dengan tugas tambahan adalah mungkin, tentu saja, karena semua orang sekarang berusaha untuk efisiensi: "Mari menggantungkan senter di atasnya sehingga dapat memotong di malam hari," tetapi apakah itu perlu?
Kami mencari mereka yang bertanggung jawab atas BCP dua tahun setelah pembentukannyaKarena itu, sering terjadi seperti ini: sebuah rencana dikembangkan dan dimasukkan ke dalam kotak panjang yang tertutup debu. Tidak ada yang mengujinya, tidak mendukung relevansinya. Ungkapan paling umum yang saya dengar ketika saya datang ke pelanggan adalah: "Ada rencana, tetapi sudah dikembangkan sejak lama; tidak diketahui apakah sudah diuji, diduga tidak berfungsi."
9. Terlalu banyak air
Ada rencana di mana pengenalan lima halaman, termasuk deskripsi tempat dan terima kasih kepada semua peserta dalam proyek, dengan informasi tentang apa yang dilakukan perusahaan. Saat Anda membalik halaman ke kesepuluh, di mana informasi berguna, Anda telah membanjiri pusat data.
Ketika Anda mencoba membaca sampai ke titik apa yang harus dilakukan ketika pusat data banjir
Keluarkan semua "air" perusahaan dalam dokumen terpisah. Rencana itu sendiri harus sangat spesifik: orang yang bertanggung jawab atas tugas ini melakukan ini, dan seterusnya.
10. Atas biaya siapa perjamuan itu?
Seringkali, pembuat rencana tidak mendapat dukungan dari manajemen puncak perusahaan. Tetapi ada dukungan dari manajemen menengah yang tidak mengelola atau tidak memiliki anggaran dan sumber daya yang diperlukan untuk mengatur kelangsungan bisnis. Misalnya, departemen TI membuat rencana BCP sesuai anggarannya, tetapi CIO tidak melihat keseluruhan gambaran di perusahaan. Contoh favorit saya adalah konferensi video. Ketika konferensi video umum tidak berhasil, siapa yang akan ia nyali? CIO yang "tidak menyediakan." Oleh karena itu, dari sudut pandang CIO, apa hal terpenting dalam perusahaan? Apa yang selalu “dicintai” olehnya: konferensi video, yang segera berubah menjadi sistem bisnis yang kritis. Dan dari sudut pandang bisnis - well, tidak ada VKS, pikirkan, kami akan berbicara di telepon, seperti di Brezhnev ...
Selain itu, departemen TI biasanya berpikir bahwa tugas utamanya jika terjadi bencana adalah memulihkan fungsi sistem TI perusahaan. Tetapi terkadang ini tidak perlu! Jika ada proses bisnis dalam bentuk kertas cetak pada printer yang sangat mahal, maka Anda tidak harus membeli printer kedua sebagai cadangan dan meletakkannya di sebelahnya jika terjadi kerusakan. Mungkin cukup untuk sementara mewarnai kertas secara manual.
Jika kami membangun perlindungan berkelanjutan di dalam TI, kami berkewajiban untuk meminta dukungan manajemen senior dan perwakilan bisnis. Kalau tidak, setelah mengintip ke dalam departemen TI, Anda dapat memecahkan sejumlah masalah tertentu, tetapi tidak semua yang diperlukan.
Ini adalah situasi ketika hanya departemen TI yang memiliki rencana DR11. Tanpa pengujian
Jika Anda memiliki rencana, Anda perlu mengujinya. Bagi mereka yang tidak terbiasa dengan standar, ini sama sekali tidak jelas. Misalnya, di mana pun Anda memiliki tanda "pintu darurat". Tapi katakan padaku, di mana ember api, kait, sekop Anda? Di mana letak hidran? Di mana berdiri pemadam api berdiri? Tapi semua orang harus tahu ini. Tampaknya tidak masuk akal bagi kami di pintu masuk kantor untuk menemukan mata pemadam api.
Mungkin kebutuhan untuk menguji rencana harus disebutkan dalam dirinya, tetapi ini adalah keputusan yang kontroversial. Dalam kasus apa pun, sebuah rencana hanya dapat dianggap sebagai pekerja ketika telah diuji setidaknya satu kali. Seperti yang disebutkan di atas, saya sering mendengar: “Ada rencana, semua infrastruktur telah disiapkan, tetapi bukan fakta bahwa semuanya akan berfungsi seperti yang tertulis dalam rencana. Karena mereka belum diuji. Tidak pernah. "
Kesimpulannya
Beberapa perusahaan dapat menganalisis sejarah mereka untuk memahami masalah apa dan dengan probabilitas apa yang dapat terjadi. Penelitian dan pengalaman menunjukkan bahwa kita tidak dapat mempertahankan diri dari segala hal. Sial, cepat atau lambat, terjadi pada perusahaan mana pun. Hal lain adalah seberapa banyak Anda akan dipersiapkan untuk situasi ini atau yang serupa dan apakah Anda dapat memulihkan bisnis Anda tepat waktu.
Beberapa orang berpikir bahwa kontinuitas adalah tentang cara menghilangkan semua jenis risiko sehingga tidak terwujud. Tidak, ini tentang fakta bahwa risikonya direalisasikan, dan kami akan siap untuk ini. Tentara berlatih agar tidak berpikir, tetapi bertindak dalam pertempuran. Hal yang sama berlaku untuk rencana BCP: itu akan memungkinkan Anda untuk membangun kembali bisnis Anda secepat
mungkin .
Satu-satunya peralatan yang tidak membutuhkan BCPIgor Tyukachev,
Konsultan Kesinambungan Bisnis
Pusat Desain Kompleks Komputer
Jet Infosystems