Panduan Analisis Dampak Bisnis

Tidak semua orang tahu di mana dan kapan harus mulai menerapkan rencana kesinambungan bisnis. Saya biasanya mengatakan ini: ketika kemungkinan kerugian lebih tinggi daripada biaya untuk menghadapi ancaman, sekarang saatnya untuk mengambil tindakan, biayanya akan memadai. Begitu juga sebaliknya. Jika biaya penimbangan lebih atau kurang jelas, maka memperkirakan kerugian adalah tugas yang tidak sepele. Saya mengundang Anda ke belakang panggung proyek untuk menilai dampak keadaan darurat pada bisnis (Analisis Dampak Bisnis - BIA) dan mengembangkan strategi untuk memastikan kesinambungan TI menggunakan contoh dari pengecer besar. Jadi ayo pergi.

Mulai

Kami berpartisipasi dalam proyek X5 Retail Group - pengecer terbesar di Rusia. Perusahaan ini mengelola jaringan Pyaterochka, Carousel dan Crossroads.

Dia sudah memiliki kebijakan manajemen risiko interupsi sendiri, yang meliputi:

1. asuransi risiko;
2. pembentukan manajemen krisis;
3. meminimalkan risiko terhadap kehidupan dan kesehatan orang;
4. kontrol risiko pengelolaan bisnis;
5. Persiapan rencana pemulihan darurat untuk sistem TI.

Sesuai dengan kebijakan ini, infrastruktur TI terpusat membutuhkan pengembangan kesinambungan layanan TI dan rencana pemulihan bencana. Solusi ideal adalah membangun pusat data cadangan, mengatur replikasi sinkron, mengatur otomatisasi transfer darurat, dan menonton "H" pada satu jam di layar bagaimana sistem TI pindah ke pusat data cadangan dan lampu hijau menyala, menandakan bahwa tidak ada bahaya bagi bisnis.

Tetapi dengan mempertimbangkan ekonomi dari proses tersebut, perusahaan menyarankan bahwa pemesanan hanya sistem IT yang paling kritis, tanpanya toko tidak akan dapat bekerja dan kerugian finansial yang signifikan, akan menjadi ukuran yang memadai jika terjadi keadaan darurat. Sebuah pertanyaan penting muncul - sistem mana dan berapa lama harus dipulihkan?
Departemen TI pelanggan menentukan klasifikasi sistem TI dan waktu pemulihan yang dapat diterima untuk setiap sistem. Namun, kemudian diputuskan untuk melakukan penilaian penuh terhadap dampak keadaan darurat pada bisnis perusahaan (BIA) sesuai dengan ISO 22301 dan praktik terbaik.

Volume dan batas

Teater dimulai dengan gantungan, dan BIA dimulai dengan definisi lingkup pekerjaan. Untuk melakukan ini, Anda perlu memeriksa proses bisnis perusahaan, layanannya, laporan keuangan, hubungan dengan mitra, pelanggan, dan kontraktor. Kemudian mengidentifikasi dan mengoordinasikan proses dan layanan bisnis utama yang akan berada dalam batas-batas proyek. Durasi dan biaya BIA tergantung pada volume. Selain itu, pengalaman kami menunjukkan bahwa Anda tidak boleh memperpanjang proyek selama lebih dari 9 bulan.

Dalam kasus kami, pelanggan telah menentukan batasan dengan memilih proses bisnis yang paling signifikan untuk kegiatan perdagangan.

Wawancara

Setelah batasan dan kerangka kerja BIA diperbaiki, daftar pemangku kepentingan dari bisnis dan departemen lain yang ingin Anda wawancarai ditentukan. Sangat penting untuk mengumpulkan informasi dari berbagai departemen untuk mendapatkan gambaran objektif tentang proses di perusahaan, untuk memahami cara kerjanya, untuk mendapatkan penilaian "apa yang akan terjadi jika ...". Pada tahap ini, kami memperoleh informasi tentang bagaimana sebenarnya proses bisnis bergantung pada TI dan membangun matriks dependensi ini. Juga, perwakilan bisnis dan pihak-pihak yang tertarik dalam proses bisnis mengevaluasi konsekuensi, kemungkinan kerusakan, kemungkinan skenario. Untuk ini, kami mengembangkan kuesioner khusus dan mewawancarai sekitar 50 responden (mempresentasikan 50 presentasi tentang proyek itu sendiri, melakukan, menerima, dan memproses semua kuesioner yang telah diisi).

Proses bisnis

Sejalan dengan wawancara, kami menggambarkan proses bisnis, dengan mempertimbangkan waktu yang dibutuhkan untuk menyelesaikan operasi individu dan kedalaman elaborasi, cukup untuk analisis lebih lanjut. Mempartisi proses menjadi komponen yang lebih kecil dan operasi khusus diperlukan untuk memahami bagaimana sistem TI mempengaruhi proses tertentu pada waktu yang berbeda dalam sehari dan waktu yang berbeda dalam setahun. Pada tahap ini, penting untuk dipahami bahwa kami tidak menggambarkan proses bisnis sesuai dengan GOST atau metodologi lainnya. Kami tidak mengoptimalkan proses bisnis dan umumnya tidak memberikan rekomendasi untuk meningkatkan proses bisnis, setidaknya dalam BIA. Kami menjabarkan proses bisnis secara terperinci yang memungkinkan kami untuk menjustifikasi metodologi untuk menghitung kerugian dan mengevaluasi kerugian berdasarkan beberapa kriteria. Untuk deskripsi grafis, notasi EPC, ARIS, dan MS Visio digunakan sebagai alat.

Ambang batas

Untuk menentukan waktu pemulihan target yang obyektif, perlu di pantai untuk menyepakati kriteria yang akan digunakan untuk menilai kerusakan, dan pada nilai ambangnya. Jika ambang ini terlampaui, kami akan mempertimbangkan kerusakan kritis, dan interval waktu di mana nilai ambang batas tercapai akan menjadi waktu pemulihan target. Dua opsi disarankan:

• menentukan RTO dengan satu kriteria - kerugian finansial;
• menentukan RTO dengan tiga kriteria - kerugian finansial, kehilangan reputasi, kehilangan kendali proses bisnis.

Opsi pertama dengan satu kriteria tampaknya lebih disukai, karena setiap kerugian dapat diubah secara kondisional menjadi uang - yang utama adalah menyetujui formula perhitungan ulang. Tetapi, seperti yang diperlihatkan oleh praktik, tidak ada yang secara khusus menghitung kerugian reputasi menjadi kerugian finansial, dan persetujuan formula seperti itu dapat memakan waktu tidak terbatas. Diputuskan untuk mempertimbangkan waktu pemulihan untuk kedua opsi, dan pada tahap penyajian hasil, pelanggan sendiri akan menentukan mana yang mencerminkan kenyataan secara lebih objektif.



Ke depan, saya akan mengatakan bahwa ketika menggunakan opsi pertama dengan satu kriteria, ternyata RTO dalam proses "penetapan harga", misalnya, bisa mencapai 10 hari. Saat menghitung opsi kedua, RTO tidak melebihi 24 jam. Dalam kasus apa pun, keputusan manajemen - yang hilang untuk dipertimbangkan dan yang tidak - tetap menjadi milik pelanggan.

Risikonya

Bersama dengan pelanggan, kami menentukan daftar risiko operasional. Yaitu, yang memengaruhi TI, dan pada gilirannya memengaruhi proses bisnis yang ... well, Anda mengerti. Tahap ini penting karena keadaan darurat tidak dianggap sebagai kuda bulat dalam ruang hampa, mereka mengatakan apa yang akan terjadi pada Tanah Air dan kepada kita jika kita kehilangan IT. Risiko dibagi menjadi global dan lokal. Untuk masing-masing dari mereka, skenario pengembangan dan dampak pada proses perusahaan ditentukan dengan mempertimbangkan hasil wawancara. Jelas, sistem TI yang sama jika terjadi kegagalan dapat memengaruhi beberapa proses bisnis, tetapi kami sangat khawatir hanya dua proses dalam proyek tersebut. Kemudian kami mengevaluasi klaim sesuai dengan parameter berikut:

• ancaman menyebar;
• kemampuan untuk mengingatkan;
• durasi paparan;
• probabilitas terjadinya;
• perkiraan kerusakan.

Sebagai hasilnya, mereka membuat peta panas di mana setiap aplikasi menerima penilaian seberapa panas bisnis dapat terbakar selama waktu henti. Sebagai contoh, selama 4 jam downtime modul SAP individu, perusahaan masih tidak menerima masalah serius, tetapi bahkan jam-jam pertama downtime perangkat lunak register kas pada peta panas ditandai dengan warna merah menyala.

Penting untuk mengklarifikasi bahwa penilaian risiko dan peringkat lebih lanjut dibentuk dengan bantuan sekelompok ahli dan diperlukan untuk menentukan situasi yang paling kritis bagi pelanggan.

Risiko dan skenario kontinjensi. Kebakaran di pusat data: ruang server benar-benar terbakar, modul SAP yang terlibat dalam proses "Pengisian" tidak tersedia. Ini berarti bahwa setiap hari, hingga modul SAP yang dibakar dikembalikan, kisaran produk dikurangi. Pertama-tama, ini menyangkut produk yang mudah rusak, kedua, produk yang sangat diminati (misalnya, sereal dan roti), dan ketiga, bahan kimia rumah tangga. Jelas, situasi ini akan menyebabkan penurunan pendapatan di toko-toko. Tetapi ini tidak sepenuhnya jelas: pembeli yang datang untuk minum bir dan rokok, tanpa adanya salah satu barang, kemungkinan besar tidak dapat membeli apa pun. Demikian pula untuk proses penetapan harga. Jika pembeli bersyarat yang mengetahui tentang diskon pada hari Rabu pukul 12:00 malam tiba di toko pada sore hari, dan proses "Penetapan Harga" tidak berfungsi (yaitu, harga tanpa diskon), maka ia:

A) tidak membeli apa pun (= kerugian finansial);
B) akan menuduh toko penipuan (= kehilangan reputasi)
B) mengeluh kepada regulator (= penalti untuk iklan yang tidak adil).

Teknik Estimasi Kerugian

Seperti yang mungkin Anda pahami dari hal di atas, untuk bahkan menghitung kerugian finansial, Anda perlu mengembangkan metodologi dan formula untuk menghitungnya, yang memperhitungkan diskon, promosi, waktu, musim tinggi (misalnya, kegembiraan di akhir Desember). Metodologi harus berisi bagian deskriptif (dari mana asalnya dan mengapa dikalikan dengan bobot), serta tabel dan grafik untuk kejelasan persepsi.

Teknik ini juga menjelaskan:

• Bagaimana waktu pemulihan ditentukan untuk proses bisnis
• Bagaimana waktu pemulihan untuk proses bisnis diterjemahkan menjadi RTO / RPO untuk sistem TI
• kelas kritikalitas dan kelas pemulihan - mengapa ini diperlukan.

Kita melangkah lebih jauh.

Perhitungan RTO

Setelah semua wawancara dilakukan, proses bisnis dijelaskan, risiko dinilai, metodologi didefinisikan dan disetujui, dan kerugian dihitung. Karena bisnis Pyaterochka, Carousel dan Crossroads berbeda setidaknya dalam skala - untuk setiap jaringan kami telah mengembangkan tabel kami sendiri, jadwal kami sendiri dan perhitungan kerugian.

Untuk proses bisnis secara keseluruhan, waktu pemulihan ditentukan (lihat metodologi), ketika kerugian melebihi nilai ambang (lihat ambang). Waktu pemulihan ini ditetapkan untuk sistem TI yang terlibat dalam proses bisnis (lihat wawancara dan matriks ketergantungan). Tampaknya parameter kesinambungan didefinisikan - proyek selesai (lihat batas dan kerangka kerja). Tapi itu tidak cukup untuk mengatakan "proses harus dipulihkan dalam 12 jam." Penting untuk menentukan cara kerjanya sekarang. Berapa jam sistem TI dapat dihidupkan kembali hari ini? Dan bagaimana jika waktu pemulihan saat ini lebih lama atau lebih lama dari target? Bagi mereka yang masih mempertahankan alasan dan konsentrasi, selamat datang di GAP!

Analisis GAP dan rencana aksi

Sebagai hasil dari langkah-langkah sebelumnya, kami menentukan keadaan untuk proses dan sistem TO TO, yaitu, sebagaimana seharusnya idealnya. Pada tahap saat ini, kami menentukan status "SEBAGAIMANA ADANYA". Pada saat yang sama, kami menyentuh proses bisnis pada tingkat yang lebih rendah, dan fokus pada komponen TI. Untuk pelanggan, kami mengevaluasi solusi saat ini dalam hal pemulihan dari keadaan darurat. Selain itu, dalam hal ini, tidak perlu melakukan pemulihan nyata dengan timer. Itu sudah cukup untuk masuk ke dalam rincian dan pengujian desktop yang cukup untuk memahami bahwa RTO target tidak dapat dicapai.

Setelah itu, kami mengembangkan sejumlah rekomendasi, baik yang bersifat umum (untuk memastikan kelangsungan TI), dan terkait langsung dengan sistem TI dan arsitekturnya. Ini adalah sketsa solusi teknis dan perkiraan kasar biaya implementasi mereka. Padahal, sekarang ada dasar untuk mengambil keputusan. Di satu sisi skala - kerugian, dan di sisi lain - biaya tindakan.
Jika beberapa sistem TI tidak menjalani analisis GAP, atau lebih tepatnya, waktu pemulihannya lebih lama dari target, kami membuat program proyek untuk mencapai keadaan target atau, jika Anda suka, peta jalan dengan justifikasi urutan proyek dan penilaian sementara untuk meningkatkan keberlanjutan organisasi.

Selain itu, untuk pelanggan kami telah mengembangkan bahan metodologis dan template untuk pembentukan rencana kesinambungan dan rencana pemulihan bencana.

Strategi

Tunggu, tunggu, aku hampir selesai.

Berdasarkan hasil BIA, kami mengembangkan strategi kontinuitas TI. Strategi kesinambungan menggambarkan dua poin utama.

1. Risiko IT mana yang memengaruhi aktivitas perusahaan diperhitungkan dan mana yang tidak (yaitu, apa yang kita takuti dan akan memutuskan dalam kerangka kesinambungan, dan apa yang tidak kita takuti, dan untuk ini kita memiliki manajemen insiden).
2. Solusi organisasi, arsitektur, infrastruktur, dan lainnya apa yang akan kami bela dari ancaman.

Secara strategi kami membunuh dua burung dengan satu batu. Pertama, semua orang di perusahaan memahami bagaimana dan apa yang akan kita lindungi dari diri kita. Kedua, untuk non-spesialis TI (misalnya, pemodal), proses penganggaran solusi pemulihan bencana TI terlihat lebih transparan. Dan betapapun menyedihkannya kedengarannya, strateginya membantu membuat keputusan manajerial yang tepat (selalu ada opsi untuk tidak menghabiskan uang untuk DR, dan sekarang kita tahu persis bagaimana ini akan memengaruhi perusahaan jika terjadi kecelakaan).

Apa selanjutnya Implementasi lebih lanjut dari strategi kontinuitas dan analisis dampak bisnis untuk proses bisnis lain dan sistem TI. Pengembangan rencana kesinambungan, pengujian berkala atas rencana-rencana ini, tetapi ini adalah cerita yang sama sekali berbeda.

Igor Tyukachev, Konsultan, Pusat Desain Jet Infosystems