Halo semuanya, nama saya Igor Tyukachev dan saya seorang konsultan kelangsungan bisnis. Dalam postingan hari ini kita akan berdiskusi panjang lebar dan membosankan tentang kebenaran umum.Saya ingin berbagi pengalaman dan berbicara tentang kesalahan utama yang dilakukan perusahaan saat mengembangkan rencana kesinambungan bisnis.
1. RTO dan RPO secara acak
Kesalahan paling penting yang pernah saya lihat adalah waktu pemulihan (RTO) diambil begitu saja. Entah kenapa - misalnya, ada beberapa nomor dari SLA dua tahun lalu yang dibawa seseorang dari tempat kerjanya sebelumnya. Mengapa mereka melakukan ini? Lagi pula, menurut semua metode, Anda harus terlebih dahulu menganalisis konsekuensinya terhadap proses bisnis, dan berdasarkan analisis ini, menghitung target waktu pemulihan dan kehilangan data yang dapat diterima. Namun melakukan analisis seperti itu terkadang memakan waktu lama, terkadang mahal, terkadang tidak begitu jelas caranya—tekankan apa yang perlu dilakukan. Dan hal pertama yang terlintas dalam pikiran banyak orang adalah: “Kami semua sudah dewasa dan memahami cara kerja bisnis. Jangan buang waktu dan uang! Mari kita ambil plus minusnya sebagaimana mestinya. Keluar dari pikiran Anda, menggunakan kecerdikan proletar! Biarkan RTO menjadi dua jam.”
Hal ini menyebabkan apa? Ketika datang ke manajemen untuk mendapatkan uang untuk kegiatan memastikan RTO/RPO yang diperlukan dengan angka tertentu, selalu membutuhkan pembenaran. Jika tidak ada pembenaran, maka timbul pertanyaan: dari mana Anda mendapatkannya? Dan tidak ada yang perlu dijawab. Akibatnya, kepercayaan terhadap pekerjaan Anda hilang.
Selain itu, terkadang pemulihan selama dua jam itu menghabiskan biaya satu juta dolar. Dan membenarkan durasi RTO adalah masalah uang, dan itu adalah masalah yang sangat besar.
Dan terakhir, ketika Anda menyampaikan rencana BCP dan/atau DR Anda kepada para pemain (yang sebenarnya sedang berlari dan melambaikan tangan pada saat kecelakaan terjadi), mereka akan menanyakan pertanyaan serupa: dari mana datangnya dua jam ini? Dan jika Anda tidak dapat menjelaskan hal ini dengan jelas, mereka tidak akan percaya pada Anda atau dokumen Anda.
Ternyata selembar kertas demi selembar kertas, berhenti berlangganan. Omong-omong, beberapa melakukan ini dengan sengaja, hanya untuk memenuhi persyaratan regulator.
Nah, Anda mengerti
2. Obat untuk segalanya
Beberapa orang percaya bahwa rencana BCP dikembangkan untuk melindungi seluruh proses bisnis dari segala ancaman. Baru-baru ini, pertanyaan “Kita ingin melindungi diri kita dari apa?” Saya mendengar jawabannya: “Semuanya dan lebih banyak lagi.”
Namun faktanya rencana tersebut bertujuan untuk melindungi saja spesifik proses bisnis utama perusahaan dari spesifik ancaman. Oleh karena itu, sebelum mengembangkan rencana, perlu dilakukan penilaian terjadinya risiko dan analisis konsekuensinya terhadap bisnis. Penilaian risiko diperlukan untuk memahami ancaman apa yang ditakuti perusahaan. Jika terjadi kerusakan bangunan akan ada satu rencana kesinambungan, jika ada sanksi - yang lain, jika terjadi banjir - yang ketiga. Bahkan dua lokasi yang identik di kota yang berbeda mungkin mempunyai rencana yang sangat berbeda.
Tidak mungkin melindungi seluruh perusahaan dengan satu BCP, terutama perusahaan besar. Misalnya, Grup Ritel X5 yang besar mulai memastikan kesinambungan dengan dua proses bisnis utama (kami menulis tentang ini ). Dan sangatlah tidak realistis untuk menyatukan seluruh perusahaan dengan satu rencana, ini termasuk dalam kategori “tanggung jawab kolektif”, ketika setiap orang bertanggung jawab dan tidak ada seorang pun yang bertanggung jawab.
Standar ISO 22301 memuat konsep kebijakan yang dengannya proses kesinambungan dalam perusahaan dimulai. Ini menggambarkan apa yang akan kita lindungi dan dari apa. Jika ada orang yang datang berlari dan meminta untuk menambahkan ini dan itu, misalnya:
— Mari kita tambahkan ke BCP risiko kita akan diretas?
Atau
— Baru-baru ini, saat hujan, lantai atas kami terendam banjir - mari tambahkan skenario apa yang harus dilakukan jika terjadi banjir?
Kemudian segera rujuk mereka ke kebijakan ini dan katakan bahwa kami melindungi aset perusahaan tertentu dan hanya dari ancaman spesifik yang telah disepakati sebelumnya, karena aset tersebut adalah prioritas saat ini.
Dan bahkan jika usulan perubahan memang tepat, maka tawarkan untuk mempertimbangkannya dalam versi kebijakan berikutnya. Karena melindungi perusahaan membutuhkan banyak uang. Jadi segala perubahan rencana BCP harus melalui panitia anggaran dan perencanaan. Kami menyarankan untuk meninjau kembali kebijakan kelangsungan usaha perusahaan setahun sekali atau segera setelah terjadi perubahan signifikan pada struktur atau kondisi eksternal perusahaan (semoga pembaca memaafkan saya jika mengatakan demikian).
3. Fantasi dan kenyataan
Sering terjadi ketika menyusun rencana BCP, penulis menggambarkan gambaran ideal dunia. Misalnya, “kami tidak memiliki pusat data kedua, tetapi kami akan menulis rencana seolah-olah kami memilikinya.” Atau bisnis tersebut belum memiliki sebagian infrastrukturnya, namun karyawan tetap menambahkannya ke dalam rencana dengan harapan dapat muncul di kemudian hari. Dan kemudian perusahaan akan memperluas kenyataan ke dalam rencana: membangun pusat data kedua, menjelaskan perubahan lainnya.
Di sebelah kiri adalah infrastruktur yang sesuai dengan BCP, di sebelah kanan adalah infrastruktur sebenarnya
Ini semua adalah kesalahan. Menulis rencana BCP berarti mengeluarkan uang. Jika Anda menulis rencana yang tidak berhasil saat ini, Anda akan membayar kertas yang sangat mahal. Tidak mungkin untuk pulih, tidak mungkin untuk mengujinya. Ternyata itu pekerjaan demi pekerjaan.
Anda dapat menulis rencana dengan cukup cepat, namun membangun infrastruktur cadangan dan mengeluarkan uang untuk semua solusi perlindungan membutuhkan waktu yang lama dan mahal. Ini mungkin memakan waktu lebih dari satu tahun. Dan mungkin Anda sudah punya rencana, dan infrastrukturnya akan muncul dalam dua tahun. Mengapa rencana seperti itu diperlukan? Hal ini akan melindungi Anda dari apa?
Ini juga merupakan sebuah fantasi ketika tim pengembangan BCP mulai mencari tahu kepada para ahli apa yang harus mereka lakukan dan dalam jangka waktu berapa. Itu berasal dari kategori: “Saat Anda melihat beruang di taiga, Anda harus berbelok ke arah yang berlawanan dari beruang tersebut dan berlari dengan kecepatan melebihi kecepatan beruang. Selama bulan-bulan musim dingin, Anda perlu menutupi jejak Anda.”
4. Puncak dan akar
Kesalahan keempat yang paling penting adalah membuat rencana terlalu dangkal atau terlalu rinci. Kita membutuhkan jalan tengah. Rencananya tidak boleh terlalu rinci bagi orang bodoh, tetapi juga tidak boleh terlalu umum sehingga berakhir seperti ini:
Secara umum mudah
5. Bagi Caesar - apa itu milik Caesar, bagi mekanik - apa itu milik mekanik.
Kesalahan berikutnya berasal dari kesalahan sebelumnya: satu rencana tidak dapat mengakomodasi seluruh tindakan untuk semua tingkat manajemen. Rencana BCP biasanya dikembangkan untuk perusahaan besar dengan arus keuangan yang besar (menurut kami , rata-rata, 48% perusahaan besar Rusia menghadapi situasi darurat yang mengakibatkan kerugian finansial yang signifikan) dan sistem manajemen bertingkat. Bagi perusahaan seperti itu, tidak ada gunanya mencoba memasukkan semuanya ke dalam satu dokumen. Jika perusahaannya besar dan terstruktur, maka rencana tersebut harus memiliki tiga tingkatan terpisah:
- tingkat strategis - untuk manajemen senior;
- tingkat taktis - untuk manajer menengah;
- dan tingkat operasional – bagi mereka yang terlibat langsung di lapangan.
Misalnya, jika kita berbicara tentang pemulihan infrastruktur yang gagal, maka pada tingkat strategis keputusan dibuat untuk mengaktifkan rencana pemulihan, pada tingkat taktis prosedur proses dapat dijelaskan, dan pada tingkat operasional terdapat instruksi untuk commissioning khusus. potongan peralatan.
BCP tanpa anggaran
Setiap orang melihat wilayah tanggung jawabnya dan hubungannya dengan karyawan lain. Pada saat terjadi kecelakaan, semua orang membuka rencana, segera menemukan bagiannya dan mengikutinya. Idealnya, Anda perlu mengingat halaman mana yang harus dibuka, karena terkadang menitnya sangat berarti.
6. Bermain peran
Kesalahan lain saat menyusun rencana BCP: tidak perlu menyertakan nama spesifik, alamat email, dan informasi kontak lainnya dalam rencana tersebut. Dalam teks dokumen itu sendiri, hanya peran impersonal yang harus ditunjukkan, dan peran ini harus diberi nama orang yang bertanggung jawab untuk tugas tertentu dan kontak mereka harus dicantumkan dalam lampiran rencana.
Kenapa?
Saat ini, kebanyakan orang berganti pekerjaan setiap dua hingga tiga tahun. Dan jika Anda menuliskan semua orang yang bertanggung jawab dan kontak mereka dalam teks rencana, maka itu harus terus diubah. Dan di perusahaan besar, terutama perusahaan pemerintah, setiap perubahan pada dokumen memerlukan banyak persetujuan.
Belum lagi jika terjadi keadaan darurat dan Anda harus dengan panik membuka-buka rencana dan mencari kontak yang tepat, Anda akan kehilangan waktu yang berharga.
Peretasan hidup: ketika Anda mengubah suatu aplikasi, Anda bahkan sering kali tidak perlu menyetujuinya. Tip lainnya: Anda dapat menggunakan sistem otomasi pembaruan rencana.
7. Kurangnya versi
Biasanya mereka membuat rencana versi 1.0, lalu melakukan semua perubahan tanpa mode edit, dan tanpa mengubah nama file. Pada saat yang sama, seringkali tidak jelas apa yang berubah dibandingkan versi sebelumnya. Dengan tidak adanya pembuatan versi, rencana tersebut menjalani kehidupannya sendiri, yang tidak dilacak dengan cara apa pun. Halaman kedua dari setiap rencana BCP harus menunjukkan versi, pembuat perubahan, dan daftar perubahan itu sendiri.
Tidak ada yang bisa memahaminya lagi
8. Kepada siapa saya harus bertanya?
Seringkali perusahaan tidak memiliki orang yang bertanggung jawab atas rencana BCP dan tidak ada departemen terpisah yang bertanggung jawab atas kelangsungan bisnis. Tanggung jawab terhormat ini diberikan kepada CIO, wakilnya, atau sesuai dengan prinsip “Anda menangani keamanan informasi, jadi inilah BCP sebagai tambahannya.” Hasilnya, rencana tersebut dikembangkan, disepakati dan disetujui, dari atas ke bawah.
Siapa yang bertanggung jawab menyimpan rencana, memperbarui, dan merevisi informasi di dalamnya? Ini mungkin tidak ditentukan. Mempekerjakan karyawan terpisah untuk hal ini adalah pemborosan, tetapi tentu saja membebani salah satu karyawan yang sudah ada dengan tugas tambahan, karena semua orang sekarang mengupayakan efisiensi: “Mari kita gantungkan lentera padanya agar dia bisa memotong rumput di malam hari,” tapi apakah itu perlu?
Kami mencari mereka yang bertanggung jawab atas BCP dua tahun setelah pendiriannya
Oleh karena itu, sering terjadi seperti ini: sebuah rencana dibuat dan dimasukkan ke dalam kotak panjang hingga tertutup debu. Tidak ada yang menguji atau mempertahankan relevansinya. Ungkapan paling umum yang saya dengar ketika saya mendatangi pelanggan adalah: “Ada rencana, tapi sudah lama dikembangkan, diuji tidak diketahui, ada kecurigaan tidak berhasil.”
9. Terlalu banyak air
Ada rencana yang pendahuluannya sepanjang lima halaman, termasuk penjelasan tentang prasyarat dan terima kasih kepada semua peserta proyek, dengan informasi tentang apa yang dilakukan perusahaan. Pada saat Anda menggulir ke bawah ke halaman kesepuluh, di mana terdapat informasi berguna, pusat data Anda telah kebanjiran.
Saat Anda mencoba membaca terkini, apa yang harus Anda lakukan jika pusat data Anda kebanjiran?
Tempatkan semua “air” perusahaan dalam dokumen terpisah. Rencananya sendiri harus sangat spesifik: orang yang bertanggung jawab melakukan tugas ini, dan seterusnya.
10. Perjamuan itu dibiayai oleh siapa?
Seringkali pembuat rencana tidak mendapat dukungan dari manajemen puncak perusahaan. Namun terdapat dukungan dari manajemen menengah yang tidak mengelola atau tidak memiliki anggaran dan sumber daya yang diperlukan untuk mengelola kelangsungan bisnis. Misalnya, departemen TI membuat rencana BCP sesuai anggarannya, namun CIO tidak melihat gambaran perusahaan secara keseluruhan. Contoh favorit saya adalah konferensi video. Ketika konferensi video CEO tidak berfungsi, siapa yang akan dia keluarkan? CIO yang “tidak menyediakan.” Oleh karena itu, dari sudut pandang CIO, hal apa yang paling penting dalam perusahaan? Hal yang selalu “disukai” orang: konferensi video, yang segera berubah menjadi sistem yang penting bagi bisnis. Dan dari sudut pandang bisnis - tidak ada VKS, bayangkan saja, kita akan berbicara di telepon, seperti di bawah Brezhnev...
Selain itu, departemen TI biasanya menganggap bahwa tugas utamanya jika terjadi bencana adalah memulihkan pengoperasian sistem TI perusahaan. Namun terkadang Anda tidak perlu melakukan ini! Jika ada proses bisnis berupa pencetakan potongan kertas pada printer yang sangat mahal, maka sebaiknya jangan membeli printer second tersebut sebagai cadangan dan meletakkannya di sebelahnya jika terjadi kerusakan. Mungkin cukup dengan mewarnai sementara potongan kertas dengan tangan.
Jika kita membangun perlindungan berkelanjutan di bidang TI, kita harus mendapatkan dukungan dari manajemen senior dan perwakilan bisnis. Jika tidak, dengan menjadi kepompong di dalam departemen TI, Anda dapat memecahkan sejumlah masalah tertentu, tetapi tidak semua masalah yang diperlukan.
Ini adalah situasi ketika hanya departemen TI yang memiliki rencana DR
10. Tidak ada pengujian
Kalau ada rencana, perlu diuji. Bagi mereka yang tidak paham dengan standar, hal ini sama sekali tidak jelas. Misalnya, Anda memiliki tanda “pintu keluar darurat” yang tergantung di mana-mana. Tapi beritahu saya, di mana ember api, kail, dan sekop Anda? Dimana hidran kebakarannya? Di mana sebaiknya alat pemadam kebakaran ditempatkan? Namun semua orang harus mengetahui hal ini. Rasanya tidak logis sama sekali bagi kita untuk menemukan alat pemadam kebakaran saat memasuki sebuah kantor.
Mungkin kebutuhan untuk menguji rencana tersebut harus disebutkan dalam rencana itu sendiri, tetapi ini adalah keputusan yang kontroversial. Bagaimanapun, suatu rencana dapat dianggap berhasil hanya jika rencana tersebut telah diuji setidaknya sekali. Seperti disebutkan di atas, saya sering sekali mendengar: “Rencananya ada, semua infrastruktur sudah disiapkan, tapi belum tentu semuanya akan berjalan sesuai rencana. Karena mereka tidak mengujinya. Tidak pernah".
Sebagai kesimpulan
Beberapa perusahaan dapat menganalisis sejarah mereka untuk memahami jenis masalah apa yang mungkin terjadi dan seberapa besar kemungkinannya. Penelitian dan pengalaman menunjukkan bahwa kita tidak dapat melindungi diri kita sendiri dari segala hal. Sial, cepat atau lambat, akan terjadi pada perusahaan mana pun. Hal lainnya adalah seberapa siap Anda menghadapi situasi ini atau situasi serupa dan apakah Anda dapat memulihkan bisnis Anda tepat waktu.
Ada yang beranggapan bahwa kesinambungan adalah tentang bagaimana menghilangkan segala macam risiko agar tidak terwujud. Tidak, intinya risiko akan terwujud, dan kami siap menghadapinya. Prajurit dilatih untuk tidak berpikir dalam pertempuran, tapi untuk bertindak. Sama halnya dengan paket BCP: paket ini memungkinkan Anda memulihkan bisnis Anda secepat mungkin.
Satu-satunya peralatan yang tidak memerlukan BCP
Igor Tyukachev,
Konsultan Kontinuitas Bisnis
Pusat Desain Sistem Komputasi
"Sistem Info Jet"
Sumber: www.habr.com