BT için iş etki analizi (BIA): görüşmeden kurtarma hedeflerine

BT için iş etki analizi neyi cevaplar?

İş etki analizi (BIA), bir iş sürecinin ya da hizmetin kesintiye uğraması halinde kurumun ne kadar zarar göreceğini ve bu zararın zamanla nasıl büyüdüğünü ölçen çalışmadır. BT tarafında asıl sorusu şudur: hangi iş süreçleri hangi BT hizmetlerine dayanıyor ve bu hizmetler ne kadar süre çalışmazsa iş ayakta kalamaz?

Çıktısı bir rapordan çok karar girdisidir. BIA sonucunda her kritik süreç için tolerans gösterilebilecek azami kesinti süresi, hizmetin kurtarma süresi hedefi (RTO), kabul edilebilir veri kaybı sınırı (RPO) ve bağımlı olduğu BT bileşenleri belli olur. Bu bilgi, hangi hizmete yedek ortam yatırımı yapılacağını, hangisinin yedekten geri yüklemeyle yetineceğini söyler. BIA yapılmadan seçilen kurtarma çözümü ya gereğinden pahalı ya da iş için yetersiz kalır.

BIA risk değerlendirmesi değildir. Risk değerlendirmesi hangi tehdidin ne olasılıkla gerçekleşeceğine bakar; BIA ise tehdit ne olursa olsun kesintinin işe etkisini ölçer. Bu çalışmalar birlikte süreklilik planının temelini oluşturur.

Adım adım: BT odaklı BIA nasıl yapılır?

Çalışmayı şu akışla yürütün.

Kapsamı ve sponsoru netleştirin. Hangi iş birimleri, hangi süreçler ve hangi lokasyonlar analize girecek? Üst yönetimden onay almış bir sponsor, iş birimlerinin görüşmelere zaman ayırmasını sağlar.

Süreç envanterini çıkarın. İş birimleriyle çalışarak müşteriye, gelire, yasal yükümlülüğe ya da operasyona dokunan süreçleri listeleyin. Her sürecin sahibini yazın. Bu aşamada yöntem, mevcut süreç dokümanları ve organizasyon şemasından başlayıp sahibiyle doğrulamaktır.

Etki ölçeğini tasarlayın. Kesintinin neleri etkileyebileceğini kategorilere bölün: finansal kayıp, müşteri deneyimi, yasal ve düzenleyici uyum, itibar, operasyonel aksama, çalışan güvenliği. Her kategori için etki derecelerini sözlü olarak tanımlayın, örneğin ihmal edilebilir, sınırlı, ciddi, çok ciddi, kabul edilemez gibi. Dereceleri örnekle somutlaştırın; "ciddi" kelimesi herkes için aynı şey ifade etmez.

Görüşmeleri yapın ve veriyi toplayın. Süreç sahibine kesintinin zaman içindeki etkisini, alternatif çalışma yollarını ve gerekli BT hizmetlerini sorun.

Verileri BT hizmetleriyle eşleştirin, kurtarma hedeflerini önerin ve sonuçları süreç sahiplerine doğrulatın. Son adımda raporlayın ve sonuçları süreklilik planlarına aktarın.

Görüşmede hangi sorular sorulur?

BIA'nın başarısı görüşmenin kalitesine bağlıdır. Süreç sahibi sık sık BT bağımlılığını bilmez ya da kesintinin etkisini abartır. Soruları somut kurun.

• Bu süreç ne iş sonucu üretiyor, kimin için çalışıyor?
• Süreç durursa ilk hangi saatte ne olur, bir gün sonra ne olur, bir hafta sonra ne olur? Etki hangi noktada kabul edilemez hale gelir?
• Yılın hangi dönemlerinde süreç özellikle kritiktir (ay sonu kapanışı, kampanya dönemi, bordro günü)?
• Süreç hangi uygulama, veri ve altyapıya dayanıyor? Kullandığınız dış tedarikçiler kimler?
• Bu hizmet olmadan manuel olarak sürdürebilir misiniz, ne kadar süre ve hangi kapasiteyle?
• Hangi veriyi en fazla ne kadar geriye giderek yeniden üretebilirsiniz?
• Hangi diğer süreçler sizin çıktınıza bağlı?

Cevapları tek bir formda tutun. Her sürece ait alanlar şunlardır: süreç adı ve sahibi, açıklama, BT bağımlılıkları, her etki kategorisi için zamana göre etki derecesi, tolerans gösterilebilecek azami kesinti süresi, önerilen RTO ve RPO, alternatif çalışma yöntemi, kritik dönemler. Standart form, farklı birimlerin cevaplarını kıyaslanabilir kılar.

Örnek: bir finans kurumunda ödeme sürecinin analizi

Örneğin bir finans kuruluşunda müşteri ödeme işlemleri süreci analiz ediliyor. Süreç sahibi, süreç durduğunda ilk saatlerde müşteri şikâyeti ve itibar etkisinin sınırlı kaldığını, ama günün sonunda takas yükümlülüklerinin karşılanamamasıyla düzenleyici ve finansal etkinin ciddi şekilde büyüdüğünü söyler. Ay sonunda etki daha da yüksektir.

BT bağımlılıkları çıkarıldığında sürecin ödeme uygulamasına, bu uygulamanın veritabanına, bir dış ağ bağlantısına ve kimlik doğrulama hizmetine dayandığı görülür. Veri tarafında sürecin işlem kayıtlarını kaybetmeyi kaldıramadığı, yani RPO'nun çok düşük olması gerektiği anlaşılır. Buna karşılık kurtarma süresi için birkaç saatlik bir tolerans vardır, çünkü iş bu sürede manuel bir kuyrukla yönetilebilir.

Bu bilgi doğrudan çözüme dönüşür: ödeme veritabanı için sürekli çoğaltma, kimlik doğrulama için yedek örnek, uygulama için yedek ortama geçiş planı. Aynı kurumda raporlama sürecinin tolerans süresi uzunsa onun için yedekten geri yükleme yeterli olabilir. BIA, bu farkı kanıta dayalı olarak görünür kılar.

Verileri analiz etmek ve hizmetleri önceliklendirmek

Toplanan formlardan hizmet bazlı bir tablo çıkarın. Her BT hizmeti için ona bağlı süreçlerin en kısa tolerans süresini alın; çünkü hizmet, kendisine bağımlı en hassas sürecin hızında kurtarılmak zorundadır. Bir hizmet birden çok sürece hizmet ediyorsa en katı süreç belirleyici olur.

Ardından bağımlılıkları zincir olarak okuyun. Bir uygulama düşük kritiklikte görünse bile kritik bir hizmetin bağımlılığıysa onun kademesi yükselir. Ortak altyapı bileşenleri (kimlik, ağ, DNS, depolama) bu yüzden genellikle en üst kademelere çıkar.

Sonuçları kademelere ayırın ve her kademeye varsayılan bir kurtarma yaklaşımı eşleyin. Sapma gösterenleri açıklayın. Son olarak çıkan sonuçları süreç sahiplerine geri götürün; kendi sürecinin sonucunu görmeyen biri bunu sahiplenmez, plan için kaynak ayırmaz.

BIA'da sık yapılan hatalar

En sık düşülen tuzaklar şunlardır.

• Sadece BT ekibinin çalışması. BT iş etkisini bilmez; iş birimi katılmadan yapılan analiz varsayımdır.
• Herkesin her şeyi kritik demesi. Önceliklendirme yapılamıyorsa etki ölçeğinin dereceleri net örneklerle tanımlanmamıştır.
• Yalnız uygulamaları listelemek, bağımlılıkları görmemek.
• Kritik dönemleri atlamak. Ay sonu, sezon ve kampanya zirveleri etkiyi katlar.
• Tek seferlik yapıp bırakmak. Süreçler ve sistemler değiştikçe BIA eskir; büyük bir değişiklik sonrasında ya da belirli aralıklarla tekrarlanmalıdır.
• Sonucu rapora gömmek ve plana aktarmamak. Hedefler kurtarma çözümlerinin tasarımına ve test kriterlerine girmelidir.

Bu beceriyi geliştirmek ve Mindset bağlamı

Küçük bir süreçle başlayın: tek bir iş birimindeki birkaç kritik süreç için yukarıdaki formu doldurun ve BT bağımlılıklarını çıkarın. Ardından etki ölçeğini ve önceliklendirmeyi kurumsal düzeye taşıyın.

Mindset kataloğundaki İş Etki Analizi (BIA) ve Kritik BT Hizmetlerinin Önceliklendirilmesi eğitimi süreç envanteri ve hizmet eşleştirmesi, etki ölçeğinin tasarımı ve puanlama, süreç sahibi görüşmeleri ve kurtarma hedeflerinin belirlenmesi modüllerini kapsar. BT risk, süreklilik ve operasyon ekiplerinin iş birimleriyle ortak bir analiz dili kurması gerektiğinde uygundur. BCP / DR Planlama eğitiminin iş etki analizi ve RTO/RPO tanımlama modülü ise sonuçların plana nasıl aktarıldığını tamamlar.