İş Sürekliliği Planlaması için Uygulama Kritiklik Puanlaması

İş sürekliliği planlaması en sık kriz anında değil, krizden önceki değerlendirme aşamasında başarısız olur. Kuruluşlar İş Etki Analizleri yapar, Kurtarma Süresi Hedeflerini belgeler, kapsamlı kurtarma kılavuzları oluşturur ve ardından en kötü anda, görünüşte kritik olmayan eski bir kimlik doğrulama hizmetinin tüm e-ticaret platformları için tek bir hata noktası olduğunu, herkesin düşük öncelikli olduğunu varsaydığı COBOL toplu iş programının gerçek zamanlı ödeme doğrulama hizmetini beslediğini veya aynı kurtarma kademesine atanmış iki uygulamanın, sıralı kurtarmayı imkansız kılan belgelenmemiş bir bağımlılığa sahip olduğunu keşfederler. Puanlama yapıldı. Bağımlılıklar belirlenmedi.

Uygulama kritiklik puanlaması, bir kuruluşun portföyündeki her uygulamaya niceliksel veya kademeli bir önem derecesi atama sürecidir; bu derece, uygulamanın kurtarma önceliğini, yedekleme yatırım düzeyini, değişiklik kontrol gereksinimlerini ve felaket kurtarma sıralamasındaki konumunu belirler. Bu puanlama yalnızca iş etkisi anketlerine ve uygulama sahibi görüşmelerine dayanıyorsa, insanların uygulamaların ne yaptığını düşündüklerini yansıtır. Uygulamaların gerçekte ne yaptığına, kimin kimi aradığına, hangi verilerin hangi programlardan geçtiğine, hangi paylaşılan bileşenlerin birden fazla yüksek öncelikli sistemin kritik yolunda yer aldığına dair yapısal analizlere dayanıyorsa, operasyonel gerçekliği yansıtır.

İnanç ile gerçeklik arasındaki uçurum, iş sürekliliği planlarının başarısız olduğu noktadır.

Başvuru Kritiklik Puanlaması Gerçekte Neyi Ölçüyor?

Kritiklik tek bir boyut değildir. Kurumsal uygulama kritiklik puanını belirlemek için, stratejik iş ihtiyaçları üzerindeki en büyük etki, iş ortakları üzerindeki etkiler, müşteri etkileşimleri ve diğer kurumsal uygulamalar üzerindeki etkiler de dahil olmak üzere, kurumsal uygulamanın kritikliğini veya önemini değerlendirmek için kullanıcı girdileri dikkate alınabilir. Bu boyutların her biri, "kritik" kelimesinin farklı bir yönünü yakalar:

İşletme üzerindeki etki , kuruluşun kesinti süresinin her saati başına kaybettiği miktardır. Gelir kaybı en görünür boyuttur: saatte 10 milyon dolar işlem yapan bir ödeme işleme sisteminin, kesintinin her dakikası için ölçülebilir bir maliyeti vardır. Ancak işletme üzerindeki etki, gelir kaybının ötesine geçerek düzenleyici riskleri (kesinti hangi uyumluluk yükümlülüklerini tetikliyor?), itibar kaybını (müşteriler doğrudan etkileniyor mu?) ve sözleşme cezalarını (hizmet seviyesi anlaşmaları ceza maddelerini tetikliyor mu?) da kapsar.

Operasyonel bağımlılık , bu uygulamaya kaç başka sistem veya sürecin bağlı olduğunu ifade eder. Doğrudan iş etkisi düşük olan bir uygulama, doğrudan etkisi yüksek olan uygulamaların bağımlılık yolunda yer aldığı için yüksek kritiklik derecesine sahip olabilir. Müşteriyle doğrudan etkileşim kuran diğer tüm uygulamaları etkinleştiren kimlik doğrulama hizmeti, kendi işlevinden daha kritik bir öneme sahiptir.

Kurtarma karmaşıklığı , uygulamanın geri yüklenmesinin ne kadar zor ve zaman alıcı olduğunu ifade eder. Orta düzeyde iş etkisi olan ve 48 saatlik kurtarma süresi gerektiren bir uygulama, daha yüksek iş etkisi olan ve 2 saatlik kurtarma süresi gerektiren bir uygulamaya göre daha yüksek oranda yedeklilik yatırımı gerektirebilir, çünkü toplam kesinti riski daha büyüktür.

Yasal yükümlülük , hangi uygulamaların yasal süreklilik gerekliliklerine tabi olduğunu belirler. DORA'ya tabi finans kuruluşları, kritik veya önemli işlevlerinin belirtilen kesinti senaryolarına dayanabileceğini göstermelidir. HIPAA'ya tabi sağlık kuruluşları, korunan sağlık bilgilerini içeren sistemlerin kullanılabilirliğini korumalıdır. Yasal boyut, belirli uygulamalar için iş etkisi puanlamasının önüne geçebilir.

Kritiklik puanı, kuruluşun özel risk toleransı, düzenleyici ortamı ve iş modeliyle ağırlıklandırılmış, dört boyutun tamamının bir bileşimidir.

Standart Kritiklik Seviyeleri

Çoğu kurumsal uygulama portföyü dört kademeli bir kritiklik modeli kullanır. Uygulama kritiklik matrisindeki kritiklik kategorileri şunlardır: Görev Açısından Kritik, İşletme Açısından Kritik, İşletme Operasyonel ve Yönetimsel. Aşağıdaki tanımlar, ISO 22301 (İş Sürekliliği Yönetim Sistemleri) ve İş Sürekliliği Enstitüsü'nün İyi Uygulama Kılavuzları ile uyumlu mevcut sektör uygulamalarını yansıtmaktadır:

Birinci Seviye, kritik öneme sahip uygulamalar; arızaları temel iş operasyonlarını anında durdurur veya kabul edilemez bir düzenleyici veya güvenlik riski oluşturur. Kurtarma Süresi Hedefi (RTO): tipik olarak 0-4 saat. Kurtarma Noktası Hedefi (RPO): tipik olarak 0-1 saat. Örnekler: temel bankacılık işlem işleme, gerçek zamanlı ticaret sistemleri, acil durum sevk sistemleri, endüstriyel kontrol arayüzleri, ödeme yetkilendirme sistemleri. Bu uygulamalar en yüksek altyapı yatırımını haklı çıkarır: aktif-aktif yedeklilik, sıfır RPO replikasyonu, otomatik arıza durumunda devralma ve en titiz değişiklik kontrolü.

2. Seviye, İşletme Operasyonlarını Önemli Ölçüde Aksatan Ancak Hemen Durdurmayan Kritik İşletme Uygulamaları. Kurtarma Süresi Hedefi: Genellikle 4-24 saat. Kurtarma Noktası Hedefi: Genellikle 1-4 saat. Örnekler: CRM sistemleri, ERP modülleri, sipariş yönetimi, bordro dönemlerinde İK sistemleri, düzenleyici başvuru dönemlerinde raporlama sistemleri. Bu uygulamalar, yüksek kullanılabilirlik altyapısı, düzenli olarak test edilmiş arıza durumunda devreye girme ve öncelikli kurtarma sıralamasını gerektirir.

3. Seviye, İşletme Operasyonel Uygulamaları: İşletme operasyonlarını destekleyen ancak geçici olarak kullanılamamaları manuel çözümlerle yönetilebilen uygulamalar. Kurtarma Süresi Hedefi: Genellikle 24-72 saat. Kurtarma Noktası Hedefi: Genellikle 4-24 saat. Örnekler: Dahili iş birliği araçları, müşteriyle doğrudan etkileşim gerektirmeyen raporlama, yönetim portalları, eğitim platformları. Standart yedekleme ve kurtarma prosedürleri uygundur.

Seviye 4, Doğrudan operasyonel etkisi olmayan, yönetimsel işlevleri destekleyen Yönetimsel Uygulamalar. Kurtarma Süresi Hedefi: Genellikle 72+ saat. Kurtarma Noktası Hedefi: 24+ saat veya son yedekleme. Örnekler: Dahili dokümantasyon wikileri, temel olmayan geliştirme araçları, geçmişe dönük raporlama. Yedeklemeden geri yükleme, fırsatçı bir yaklaşımla yapılır.

Kademe ataması kalıcı değildir. Yılın büyük bölümünde 3. Kademede olan bir uygulama, ay sonu mali kapanışı, düzenleyici raporlama dönemleri veya yoğun işlem sezonlarında 2. Kademe haline gelebilir. Kademe atamasının operasyonel takvime göre değiştiği dinamik kritiklik, olgun iş sürekliliği planlama programlarına sahip kuruluşların temel kademe yapısını oluşturduktan sonra uyguladığı bir iyileştirmedir.

Puanlama Metodolojisi: Boyutları Sayılara Çevirmek

Yapılandırılmış bir puanlama metodolojisi, dört kritiklik boyutunu, kurumsal politikalardan ziyade objektif olarak kademe atamasını yönlendiren sayısal bir puana dönüştürür. Aşağıdaki yaklaşım, ağırlıklı kriterler kullanarak 0-100 arasında bir bileşik puan üretir:

Boyut 1: İşletme Etkisi (ağırlık: %35)

Kesinti Süresinin Saat Başına Gelir Etkisi	Puan
> Saatte 1 milyon dolardan fazla	35
Saatte 100 ila 1 milyon dolar	28
Saatte 10 - 100 dolar	21
Saatte 1 - 10 dolar	14
Saatte 1 dolardan az	7
Gelir üzerinde doğrudan bir etkisi yok.	0

Düzenleyici etkiler (DORA, HIPAA, PCI-DSS, SOX uyumluluk yükümlülükleri nedeniyle ortaya çıkan kesintiler) bu boyuta 10 puan daha ekler.

Boyut 2: Operasyonel Bağımlılık (ağırlık: %30)

Fan-In: Bu Uygulamaya Bağlı Uygulamalar	Puan
> 20 bağımlı uygulama	30
10-20 bağımlı uygulama	24
5-9 bağımlı uygulama	18
2-4 bağımlı uygulama	12
1 bağımlı uygulama	6
Bakmakla yükümlü olunan kimse yok (bağımsız)	0

Buradaki "giriş sayısı", yapısal bağımlılık sayısını, yani bu uygulamayı çağıran, çıktılarını okuyan veya verilerine bağımlı olan uygulama sayısını ifade eder; kullanıcı sayısını veya algılanan önemi değil. Bu boyut, anketlerde en sık yanlış hesaplanan boyuttur çünkü uygulama sahipleri tüm alt tüketicilerini bilmezler.

Boyut 3: Kurtarma Karmaşıklığı (ağırlık: %20)

Önceden Oluşturulmuş Felaket Kurtarma Olmadan Tahmini Kurtarma Süresi	Puan
> 72 saatleri	20
24-72 saat	16
8-24 saat	12
2-8 saat	8
<2 saat	4
Otomatik arıza durumunda devralma < 15 dakika	0

Boyut 4: Veri Hassasiyeti ve Mevzuat Yükümlülüğü (ağırlık: %15)

Veri Sınıflandırması ve Düzenleyici Gereklilik	Puan
Açık kurtarma süresi yükümlülüğü bulunan, düzenlemeye tabi kişisel veriler/sağlık bilgileri/sağlık bilgileri.	15
Belirli bir kurtarma süresi yükümlülüğü bulunmayan düzenlenmiş veriler	12
Hassas iç veriler (ticari sırlar, mali kayıtlar)	9
Dahili operasyonel veriler	6
Hassas olmayan dahili veriler	3
Depolanan veri yok	0

Bileşik Puanın Kademe Eşleştirilmesi:

Karma Not	Kademe Ataması
75-100	Kademe 1, Kritik Görev
50-74	2. Kademe, İşletme Açısından Kritik
25-49	3. Kademe, İşletme Operasyonları
0-24	4. Kademe, İdari

Bağımlılık Sorunu: Anket Tabanlı Puanlama Neden Yanlış Sonuç Veriyor?

Operasyonel bağımlılık boyutu, yanlış hesaplanma olasılığı en yüksek olan ve yanlış hesaplandığında en büyük sonuçlara yol açan boyuttur. Görünüşte kritik olmayan eski bir kimlik doğrulama hizmeti, tüm bir e-ticaret platformu için tek bir hata noktası olabilir ve arızası tüm gelir getiren işlemleri durdurabilir. Bu süreç, soyut tehditlerin ötesine geçerek hizmet seviyesi anlaşmaları üzerinde somut, ölçülebilir etkilere dönüşür.

Uygulama sahipleri, doğrudan yukarı yönlü bağımlılıklarını, yani çağırdıkları sistemleri bilirler. Ancak, aşağı yönlü bağımlılıklarının tamamını, yani onları çağıran sistemleri nadiren bilirler. Dahili bir kullanıcı kimlik doğrulama hizmeti, sahibi tarafından düşük kritiklikte (gelir getirici değil, basit, nadiren başarısız oluyor) olarak değerlendirilebilirken, tamamı 1. Seviye olan on iki müşteri odaklı uygulama tarafından bağımlı olarak kullanılmaktadır. Kimlik doğrulama hizmetinin gerçek kritikliği, kendi işlevi nedeniyle değil, daha üst seviye sistemlerin bağımlılık grafiğindeki konumu nedeniyle 1. Seviye'dedir.

Anket tabanlı kritiklik puanlaması bu hatayı sistematik olarak üretir. Uygulama sahibi anketinde şu soru sorulur: "Bu uygulama ne kadar kritik?" Kimlik doğrulama hizmeti sahibi, hizmetin kendi işlevine dayanarak "düşük ila orta" yanıtını verir. On iki bağımlı uygulama sahibi, kimlik doğrulama hizmetiyle ilgili bu anketi yanıtlamaz, kendi uygulamalarıyla ilgili yanıtlar verir. Bağımlılık ilişkisi hiçbir zaman kaydedilmez.

Sonuç, kurtarma sıralamasında ortaya çıkar: İş sürekliliği planı (BCP), anketten elde edilen kritiklik puanlarına göre kurtarma sırasını tanımlar ve kimlik doğrulama hizmeti 3. Kademe kurtarma için planlanır. Gerçek bir olay sırasında, ilk önce kurtarılması gereken 1. Kademe uygulamaları, bağlı oldukları kimlik doğrulama hizmeti geri yüklenmediği için kurtarılamaz. Kurtarma sırası, en kritik bağımlılık noktasında başarısız olur.

Anketlerin sürekli olarak gözden kaçırdığı üç bağımlılık türü:

Gizli paylaşılan bileşenler. Anketin hiçbirinin ortak bir bileşen olarak tanımlamadığı üç ayrı iş süreci için para birimi dönüştürmeyi yöneten dahili bir COBOL programı, üçünün de kurtarılmasını etkileyen gizli bir bağımlılıktır. Eğer para birimi dönüştürme programı 3. Seviyede ise ve üç iş sürecinden herhangi biri 1. Seviyede ise, para birimi dönüştürme programının etkin kritikliği 1. Seviyededir.

Veri işlem hattı bağımlılıkları. Diğer uygulamalardan toplu olarak işlenmiş verileri tüketen uygulamaların gerçek zamanlı değil, zamansal bir bağımlılığı vardır. Risk, eş zamanlı arıza değil, sıralı arızadır: alt uygulama kurtarılır, ancak veri kaynağı aynı kurtarma noktasına geri yüklenmez ve bu da eski veriler üzerinde doğru çalışma görünümü yaratır. Bu tür bağımlılıklar, veri akışının kendisi izlenmediği sürece ağ topolojisi haritalarında veya çağrı grafiği analizinde görünmez.

Paylaşılan yapılandırma ve şema bağımlılıkları. Veritabanı şemalarını, yapılandırma hizmetlerini veya kimlik sağlayıcılarını paylaşan uygulamalar, birbirlerini doğrudan çağırmasalar bile, örtük bir bağımlılığa sahiptir. Paylaşılan bir veritabanındaki şema değişikliği birden fazla uygulamayı etkileyebilir. Şema bozulmasından sonra tüm şemayı paylaşan uygulamaları kurtarmadan yalnızca bir uygulamayı kurtarmak, uygulama portföyünde tutarsız bir duruma yol açar.

İş Sürekliliği Planı Entegrasyonu: Kritiklik Puanları Kurtarma Kararlarını Nasıl Etkiliyor?

Kritiklik puanı, altı özel BCP tasarım kararının girdisidir:

1. Kurtarma sırası tanımı. Uygulamalar kritiklik sırasına göre, 1. Kademe'den önce, 2. Kademe'den önce ve 3. Kademe'den önce kurtarılır; ancak bir kademe içinde, bağımlılık grafiği sırayı belirler. Gelen bağımlılığı olmayan (başka hiçbir uygulamanın onlara bağlı olmadığı) uygulamalar, kendi kademeleri içinde herhangi bir sırada kurtarılabilir. Yüksek giriş sayısına sahip uygulamalar, kademe içindeki göreceli puanlarından bağımsız olarak, bağımlı oldukları uygulamalardan önce kurtarılmalıdır. Bu nedenle kurtarma sırası şöyledir: her kademe içindeki bağımlılık kısıtlamalı alt dizilere uygulanan kademe sıralaması.

2. RTO ve RPO hedef belirleme. Kritiklik puanı, RTO ve RPO hedeflerini kalibre eder. Her üretim uygulaması için Maksimum Tolere Edilebilir Kesinti Süresi (MTD) ve Kurtarma Noktası Hedefi (RPO), tüm süreklilik stratejisinin teknik temelini oluşturur. MTD, işletmenin bir uygulamanın kullanılamaz durumda olmasına tahammül edebileceği maksimum süredir. RTO, MTD'den daha az olmalıdır. RTO ve MTD arasındaki marj, güvenlik tamponudur. Saat başına yüksek iş etkisi olan Tier 1 uygulamaları, dar MTD/RTO marjlarına sahiptir ve hızlı otomatik kurtarma için tasarlanmış altyapı gerektirir.

3. Altyapı yatırım kalibrasyonu. Kritiklik puanları, felaket kurtarma altyapısı yatırım kararlarını doğrudan yönlendirir. 1. seviye uygulamalar, aktif-aktif çok bölgeli yedekliliği haklı çıkarır. 2. seviye uygulamalar, test edilmiş arıza durumunda devreye girme özelliğiyle aktif-pasif yapıyı haklı çıkarır. 3. seviye uygulamalar, belgelenmiş geri yükleme prosedürleriyle düzenli yedeklemeyi haklı çıkarır. 4. seviye uygulamalar, standart yedekleme politikalarına güvenebilir. Kritiklik puanları olmadan, altyapı yatırım kararları ya aşırı yatırıma (pahalı) ya da yetersiz yatırıma (riskli) yönelir.

4. Değişiklik kontrolü gereksinimleri. Kritiklik puanı daha yüksek olan uygulamalar daha titiz bir değişiklik kontrolü gerektirir: daha uzun değişiklik dondurma süreleri, daha fazla zorunlu onaylayıcı, daha kapsamlı değişiklik öncesi testler, daha muhafazakar geri alma prosedürleri. 4. seviye uygulamalara 1. seviye değişiklik kontrolü uygulamak mühendislik zamanını boşa harcar. 1. seviye uygulamalara 4. seviye değişiklik kontrolü uygulamak kabul edilemez riskler yaratır.

5. Test ve doğrulama sıklığı. İş sürekliliği planı (BCP), kurtarma prosedürlerinin periyodik olarak test edilmesini, masa başı tatbikatlarını, bileşen düzeyinde arıza durumunda devreye girme testlerini ve tam felaket kurtarma simülasyonlarını gerektirir. Kritiklik puanları test sıklığını belirler: 1. Seviye uygulamalar üç ayda bir felaket kurtarma testlerini; 4. Seviye uygulamalar ise yıllık testleri gerektirir. Her uygulamayı aynı sıklıkta test etmek ne pratik ne de gereklidir.

6. Tedarikçi SLA gereksinimleri. Üçüncü taraf hizmetlerine bağımlı uygulamalar için, kritiklik puanı, tedarikçi sözleşmelerinde bulunması gereken SLA gereksinimlerini belirler. 4 saatlik RTO'ya sahip bir Tier 1 uygulaması, bu RTO ile tutarlı kullanılabilirliği garanti eden bir üçüncü taraf SLA'sına ihtiyaç duyar. Tier 4 uygulaması için bu gerekli değildir.

Eski Sistem Komplikasyonu

Eski sistemler, modern uygulama portföy yönetimi çerçevelerinin yeterince ele almadığı şekillerde kritiklik puanlamasını karmaşıklaştırır. Standart kritiklik değerlendirmesi, uygulama sahiplerinin uygulamalarının ne yaptığını ve kimlerin bunlara bağımlı olduğunu bildiğini varsayar. Eski sistemler için, örneğin birden fazla geliştirici nesli tarafından sürdürülen COBOL programları, bağımlılıkları en son 2008'de belgelenmiş JCL iş akışları, kuruluşta şu anda çalışan hiç kimsenin yazmadığı süreçler tarafından tüketilen çıktı dosyaları üreten RPG programları için bu varsayım geçerli değildir.

Eski bir sistemin gerçek bağımlılık yapısı yalnızca kodun kendisinde görülebilir. On iki alt programın okuduğu bir veri kümesine yazan bir COBOL programının on iki alt bağımlılığı vardır, ancak bu gerçek, programın yalnızca işlevini (günlük işlemleri işlemek) gören, yapısal rolünü (on iki diğer süreci etkinleştiren veri kümesini üretmek) görmeyen COBOL programının sahibi tarafından bilinmeyebilir.

Eski sistemler için, kritiklik puanlamasının bağımlılık boyutu, sahip anketlerinden ziyade kod analizini gerektirir. Bir COBOL programının giriş sayısı, ortamdaki diğer tüm programları inceleyerek ve hangilerinin ilk programın çıktı veri kümelerine, çağrı kurallarına veya paylaşılan kopyalama kitaplarına referans verdiğini belirleyerek elde edilebilir. Bu analiz, yapısal kod analizi platformlarının sağladığı şeydir ve bu platformlar olmadan, eski bir programa atanan herhangi bir kritiklik puanının bağımlılık boyutu en iyi ihtimalle tahmini bir değerlendirmeden ibarettir.

Eski uygulamaların kritiklik düzeyinin yanlış değerlendirilmesinin sonuçları özellikle ağırdır çünkü eski sistemler hem son derece kritiktir (çoğu zaman on yıllar boyunca birikmiş temel iş mantığını içerirler) hem de düşük puan alırlar (sahipleri onlara neyin bağlı olduğunu açıklayamadıkları için muhafazakar puanlar atarlar). Sonuç olarak, aslında 1. seviye iş süreçlerinin kritik yolunda bulunan eski programlara 3. seviye atanır; bu da gerçek olaylar sırasında kurtarma dizisi hatalarında ortaya çıkan tam hata modudur.

Ne kadar SMART TS XL Kritiklik Puanlaması için Bağımlılık Kanıtı Sağlar

SMART TS XL Anket tabanlı yaklaşımların en az güvenilir olduğu uygulama sınıfları için, uygulama kritiklik puanlamasının bağımlılık boyutunu doğrudan ele almaktadır.

Uygulama bağımlılık eşleme özelliği, ortamdaki her dil için eksiksiz bir bağımlılık grafiği oluşturur: diğer her COBOL programını çağıran her program, alt programlar tarafından tüketilen verileri üreten her JCL iş adımı, birbirini doğrudan çağırmayan programlar arasında örtük bir bağımlılık oluşturan her paylaşılan copybook, üretici ve tüketici programlar arasında akan her veri kümesi. Bu grafik, kritiklik puanlamasının bağımlılık boyutu, giriş sayıları, paylaşılan bileşen tanımlamaları ve anketlerin güvenilir bir şekilde yakalayamadığı gizli veri işlem hattı bağımlılıkları için yapısal kanıt tabanıdır.

Etki analizi özelliği, BCP planlaması için bağımlılık grafiğini sorgulanabilir hale getirir: portföydeki herhangi bir uygulama için, doğrudan veya dolaylı olarak ona bağlı olan ve dolayısıyla kullanılabilirlik gereksinimini devralan diğer tüm uygulamaları listeler. Üç doğrudan bağımlısı ve yirmi dolaylı bağımlısı (doğrudan bağımlılara bağlı programlar) olan bir COBOL programının etkin kritikliği, yalnızca kendi işlevini değil, kritik yolunda bulunduğu yirmi üç programı da yansıtır.

Statik kod analizi özelliği, kurtarma karmaşıklığı boyutunu bilgilendiren yapısal karmaşıklık ölçütlerini ortaya çıkarır: döngüsel karmaşıklık, bağlantı ölçütleri, ölü kod yüzdesi ve her uygulamanın kurtarılmasının ne kadar süreceğini ve ne kadar riskli olacağını öngören teknik borç göstergeleri. Yüksek karmaşıklığa ve yoğun bağlantıya sahip bir uygulamanın geri yüklenmesi daha pahalıdır ve temiz mimariye sahip eşdeğer işlevli bir uygulamaya göre Boyut 3 kurtarma karmaşıklığı puanı daha yüksektir.

Kurumsal arama özelliği, BCP yaşam döngüsü boyunca tüm bağımlılık envanterinin sorgulanabilir olmasını sağlar: belirli bir veri kümesine erişen her programı (kullanılabilirliğine bağlı tüm programları belirleyerek), belirli bir copybook'u paylaşan her programı (kullanılabilirliğinden etkilenen tüm programları belirleyerek), belirli bir toplu işlem penceresinde çalışan her JCL işini (pencere başlamadan önce kurtarılması gereken tüm programları belirleyerek) bulabilirsiniz. Bu arama özelliği, uygulama portföyü geliştikçe puanları güncel tutan güncelleme süreci olan yıllık kritiklik puanı incelemesini destekler.

Faaliyet gösteren kuruluşlar için miras modernizasyonu BCP geliştirme ile birlikte programlar, SMART TS XLBu analiz aynı anda iki amaca da hizmet eder: kritiklik puanlamasını bilgilendiren bağımlılık haritası aynı zamanda geçiş sıralamasını da belirler ve kurtarma karmaşıklığı puanlamasını bilgilendiren karmaşıklık ölçütleri aynı zamanda modernizasyon çabası tahminini de belirler.

Güncel Puanları Takip Etmek: Yıllık Değerlendirme Döngüsü

İş sürekliliği olgunluk değerlendirmesi size üç konuda yardımcı olmalıdır: mevcut durumunuzu anlamak, en önemli eksiklikleri belirlemek ve iyileştirme için gerçekçi bir yol haritası oluşturmak. İşte bu, olgunluk puanlamasını daha iyi bir programa dönüştüren şeydir.

Organizasyonlar değiştikçe uygulama kritiklik puanları gerçeklikten uzaklaşır. Yeni uygulamalar eklenir. Eski uygulamalar kullanımdan kaldırılır ancak tamamen devre dışı bırakılmaz. Daha önce hiçbir bağımlılığı olmayan uygulamalar arasında entegrasyonlar oluşturulur. İş süreçleri değişir ve bunlarla birlikte dayandıkları uygulamalar da değişir. Düzenleyici gereksinimler gelişir ve yeni kurtarma yükümlülükleri getirir.

Kritiklik puanlarına ilişkin yıllık değerlendirme döngüsü şunları içermelidir:

Yapısal yeniden analiz. Son incelemeden bu yana ortaya çıkan yeni bağımlılıkları belirlemek için bağımlılık haritasını yeniden çalıştırın. Bağımsız olan uygulamaların artık kritikliklerini artıran bağımlılıkları olabilir. Yüksek oranda bağımlı olan uygulamaların tüketicileri daha yeni sistemlere geçmiş olabilir ve bu da kritikliklerini azaltabilir.

İş etkisi yeniden değerlendirmesi. Gelir ve operasyonel etki rakamları, işletme büyüdükçe ve uygulama portföyü geliştikçe değişir. Üç yıl önce saatte 1 dolarlık iş değeri sağlayan bir uygulama, işletme büyümesinin ardından bunun on katını sağlayabilir.

Kurtarma testi sonuçlarının entegrasyonu. DR testleri, varsayılan ve gerçek kurtarma karmaşıklığı arasındaki farkları ortaya koymaktadır. İlk değerlendirmede kurtarma karmaşıklığı açısından düşük puan alan bir uygulama, masa başı tatbikatında kötü performans göstermiş olabilir ve bu da puanın yukarı yönlü revize edilmesini gerektirir.

Mevzuat değişikliği incelemesi. Yeni düzenlemeler veya mevcut düzenlemelerdeki değişiklikler, belirli uygulamalar için yeni kurtarma süresi yükümlülükleri getirebilir. Örneğin, DORA düzenlemesinin AB finans kurumları için operasyonel dayanıklılık gereksinimleri, DORA öncesi kritiklik puanlarında yansıtılmamış olabilecek "kritik veya önemli işlevler" üzerinde belirli kurtarma süresi yükümlülükleri getirmiştir.

Olgun iş sürekliliği planlama programlarına sahip kuruluşlar, kritiklik puanlamasını tek seferlik bir işlem olarak değil, sürekli bir süreç olarak ele alırlar: Uygulama bağımlılıklarında, iş etkisinde veya düzenleyici yükümlülüklerde önemli değişiklikler meydana geldiğinde puanlar güncellenir ve yapılandırılmış bir inceleme yoluyla yıllık olarak doğrulanır.

Puanın değeri, dayandığı kanıtların sağlamlığıyla doğru orantılıdır.

Uygulama kritiklik puanlaması, bağımlılık boyutu anketlerden ziyade yapısal kanıtlara dayandırıldığında en büyük değeri sunar. İş etkisi ve düzenleyici yükümlülük boyutları, görüşmeler ve iş süreci analizi yoluyla güvenilir bir şekilde değerlendirilebilir. Operasyonel bağımlılık boyutu ise, her uygulamanın neye bağlı olduğunu bilmeyi gerektirdiğinden ve uygulama sahipleri alt kademe tüketicilerini sistematik olarak hafife aldığından, bu şekilde değerlendirilemez.

Hata modu tahmin edilebilir: Anketlerden elde edilen kritiklik puanlarına dayalı bir kurtarma dizisi, gizli bağımlılıklarda başarısız olur. Eski bir kimlik doğrulama hizmeti geç geri yüklenir. COBOL para birimi dönüştürme programı, ona bağımlı uygulamalar kurtarma girişiminde bulunurken çevrimdışıdır. Paylaşılan bir veritabanı şeması, ondan okuyan uygulamalardan farklı bir kurtarma noktasındadır. Bu hataların her biri, yapısal analizin sağladığı bağımlılık kanıtlarıyla önlenebilir ve her biri, masa başı tatbikatı sırasında değil de gerçek bir olay sırasında meydana geldiğinde maliyetlidir.

Puanlama metodolojisi belirlenmiştir. Çerçeveler mevcuttur. Çoğu kuruluşun yaşadığı eksiklik, puanlama çerçevesinde değil, en önemli boyutuna ilişkin kanıt tabanındadır. Bir sonraki olayda iş sürekliliği planının (BCP) çalışması gerekmeden önce, yapısal analizle bu eksikliği kapatın.