İş Etki Analizi (BIA) Nasıl Yapılır? Anket, Görüşme ve Çıktılar

Felaket kurtarma planı yazılmış ama hangi sistemin önce açılacağı belli olmayan bir şirkette, kesinti anında ilk saat sırayı tartışmakla geçer. Bunun kaynağı neredeyse her zaman eksik ya da hiç yapılmamış bir iş etki analizidir (BIA). BIA, bir kesintinin hangi süreci ne kadar sürede, hangi şiddette vurduğunu ölçer; kurtarma sırası, RTO’lar ve yedekleme yatırımları bu veriden çıkar. Aşağıda kapsamı çizmekten yönetim onayına kadar BIA’yı sahadaki çalışma sırasıyla anlatıyoruz.

BIA’nın amacı ve risk analizinden farkı

Risk analizi “ne olabilir, olasılığı ne?” diye sorar. BIA olasılığı masadan kaldırır ve tek bir soruya bakar: “Bu süreç durursa, saat ilerledikçe ne kaybederiz?” ISO 22301:2019’un 8.2.2 maddesi BIA’dan şunları bekler: etki türlerinin ve kriterlerinin tanımlanması, ürün ve hizmetleri destekleyen faaliyetlerin belirlenmesi, faaliyet yürütülmediğinde etkinin kabul edilemez hale geleceği zaman diliminin (MTPD olarak da anılır) saptanması, öncelikli faaliyetler için devreye alma sürelerinin (RTO) belirlenmesi, gereken kaynakların ve bağımlılıkların çıkarılması.

İki çalışma birbirini besler, birbirinin yerine geçmez. BGYS kapsamındaki bilgi güvenliği risk analizi varlık ve tehdit ekseninde yürür; yöntem ve kayıt örnekleri için BGYS risk analizi rehberine bakabilirsiniz. BIA ise süreç ve zaman ekseninde yürür. Sahada en sık gördüğümüz hata, BIA formuna bir “olasılık” sütunu eklenmesidir. O sütun girdiği anda bina kaybı ya da ERP veritabanının tamamen bozulması gibi düşük olasılıklı ama yıkıcı kesintiler puan tablosunun dibine iner. Plan da onları atlar.

Kapsam ve süreç listesi

BIA, iş sürekliliği yönetim sisteminin kapsamıyla aynı sınırlarda yapılır. Kapsam dar tutulacak olsa bile ilk turda kuruluşun dışarıya sunduğu ürün ve hizmetlerin listesiyle başlayın; önceliklendirme hizmetten geriye doğru yapılır. Sıra şöyledir:

1. Ürün ve hizmetler: Müşteriye, yasal mercilere veya grup şirketlerine sunulan çıktılar (örneğin sipariş karşılama, sevkiyat, bordro, teknik destek).
2. Süreçler: Her hizmeti baştan sona üreten süreçler. Organizasyon şemasındaki departman adı süreç değildir; “Muhasebe” yerine “tedarikçi ödemeleri”, “e-fatura düzenleme” yazılır.
3. Faaliyetler: Süreç içindeki, ayrı kaynak ve zaman ihtiyacı olan adımlar. BIA çoğu kuruluşta bu seviyede yapılır; görev seviyesine inmek veri toplamayı yönetilemez hale getirir.

Süreç listesini BIA başlamadan önce süreç sahipleriyle doğrulayın. Her satıra bir sahip, bir yedek kişi ve sürecin yürütüldüğü lokasyonlar yazılır. Lokasyon bilgisi boş bırakılırsa ileride tesis kaybı senaryosunda ve alternatif çalışma yeri kararında aynı soruyu yeniden sormak zorunda kalırsınız.

Veri toplama yöntemleri

Üç yöntem var ve çoğu çalışmada birlikte kullanılıyor. Seçimi kuruluşun büyüklüğü, süreç sahiplerinin süreklilik kavramlarına aşinalığı ve ayrılabilen zaman belirler.

Yöntem	Güçlü yanı	Sınırlaması	Uygun olduğu durum
Anket (form)	Çok sayıda süreçte hızlı ve tutarlı veri	Kavramlar yanlış anlaşılır, cevaplar iyimser olur	Çok lokasyonlu, olgun kuruluşlar; ön veri
Birebir görüşme	Derinlik, gizli bağımlılıkların ortaya çıkması	Zaman alır, görüşmeciye bağımlıdır	Kritik süreçler, ilk BIA turu
Atölye	Süreçler arası bağımlılıkta uzlaşı	Baskın katılımcı etkisi, planlama zorluğu	Birbirine bağlı süreç zincirleri

Sahada işleyen sıra şu: önce süreç sahiplerine kısa bir ön form gidiyor (süreç tanımı, kullanılan sistemler, kişi sayısı, dönemsel yoğunluklar). Ardından 60–90 dakikalık görüşmede form birlikte tamamlanıyor ve etki değerlendirmesi yapılıyor. Son olarak birbirine bağlı süreçlerin sahipleri bir atölyede yan yana oturtuluyor. Satış “siparişler dört saat içinde işlenmeli” derken depo aynı siparişi ancak ertesi gün sevk edebiliyorsa, bu çelişki ancak o masada ortaya çıkar.

Sonucu soruların biçimi belirler. “Bu süreç ne kadar kritik?” sorusunun cevabı her zaman “çok kritik” olur. Bunun yerine zamana bağlı, somut sorular sorun: “Sistem sabah 09.00’da durdu; öğlene kadar ne olur? Ertesi sabaha kadar? Üç gün sonra?” “Bu işi bir hafta elle yürütebilir misiniz, kaç kişiyle?” “Ay sonunda mı, ortasında mı durması daha kötü?” Cevapta somut bir kayıp geçmiyorsa soruyu tekrar sorun.

Zaman bazlı etki ölçeği

Etki ölçeğini BIA başlamadan önce yönetime onaylatın; aksi halde her süreç sahibi “yüksek etki”yi kendine göre yorumlar ve sonuçlar karşılaştırılamaz. Ölçek iki eksenden oluşur: etki kategorileri (finansal, müşteri ve sözleşme, yasal ve düzenleyici, itibar, sağlık ve güvenlik, operasyonel) ve şiddet seviyeleri. Her seviye kuruluşa özgü, ölçülebilir eşiklerle tanımlanır. Aşağıdaki tablo bir örnek şablondur; tutarlar ve eşikler kuruluşun ölçeğine göre belirlenir.

Seviye	Finansal (örnek eşik)	Müşteri / sözleşme	Yasal / düzenleyici
1 – Önemsiz	Aylık cironun çok küçük bir kısmı	Müşteri fark etmez	Yükümlülük yok
2 – Sınırlı	Bütçe içinde karşılanabilir	Tek müşteride gecikme	İç kayıt gerekir
3 – Ciddi	Çeyrek hedefini etkiler	Sözleşme cezası, şikâyet	Bildirim yükümlülüğü doğabilir
4 – Kritik	Yıllık hedefi etkiler	Kilit müşteri kaybı riski	İdari yaptırım riski
5 – Yıkıcı	Şirketin devamlılığını tehdit eder	Müşteri tabanında kalıcı kayıp	Faaliyet izni riski

Sonra her faaliyet için zaman dilimleri boyunca etki seviyesi işaretlenir. Zaman dilimleri işin doğasına göre seçilir; tipik set 4 saat, 1 gün, 3 gün, 1 hafta, 2 hafta ve 1 aydır. Her hücreye o dilimdeki en yüksek kategori seviyesi yazılır. Etkinin “kabul edilemez” sınırını (örneğin seviye 4) ilk aştığı zaman dilimi, o faaliyetin MTPD’sini verir. RTO bu sürenin altında, kurtarma ve doğrulama için pay bırakılarak belirlenir. Hedeflerin iş ve BT arasında nasıl uzlaştırıldığı ayrı bir konudur ve MTPD, RTO ve RPO hedeflerinin belirlenmesi ve onayı rehberinde ele alınır.

Bağımlılıkların çıkarılması: kişi, sistem, tedarikçi, tesis

BIA’nın asıl değeri çoğu zaman etki puanında değil, bağımlılık listesindedir. Kurtarma sırasında sizi durduran şey genellikle unutulmuş bir bağımlılıktır: lisans sunucusu, tek bir kişinin bildiği banka ekranı, yalnızca bir makinede tanımlı yazıcı. Her öncelikli faaliyet için dört kaynak türünü ayrı ayrı sorgulayın:

• Kişiler ve yetkinlikler: Faaliyeti asgari düzeyde yürütmek için kaç kişi, hangi yetkinlik ve yetkiyle gerekir? Tek kişiye bağlı bilgi (yalnızca bir kişinin bildiği banka ekranı, tek kişinin yetkili olduğu imza) ayrıca işaretlenir.
• Bilgi sistemleri ve veri: ERP, e-posta, dosya sunucusu, banka entegrasyonu gibi uygulamalar ve kabul edilebilir veri kaybı. Süreç sahibine “en son ne zamanki veriyle çalışabilirsiniz?” diye sorun; bu cevap RPO talebinin kaynağıdır.
• Tedarikçiler ve dış hizmetler: Bulut hizmetleri, lojistik firması, internet servis sağlayıcısı, bakım firması. Kritik tedarikçilerin süreklilik kapasitesinin nasıl sorgulanacağı kritik tedarikçilerde iş sürekliliği rehberinde ayrıca anlatılır.
• Tesis ve ekipman: Bina, üretim hattı, depo, özel yazıcı, kasa, imza cihazı gibi taşınamayan veya yerine konması zor kaynaklar.

Bağımlılıkları tabloya dökerken yön bilgisini kaybetmeyin: “A süreci B’ye girdi verir” ile “A süreci B’den girdi alır” aynı şey değildir. Yön doğru kaydedilince tutarsızlıklar kendini gösterir; yukarı akıştaki bir sürecin RTO’su aşağı akıştakinden uzunsa aşağıdaki hedef kâğıt üzerinde kalır. BIA doğrulamasında ilk bakılacak yer burasıdır. Üretim tesislerinde OT sistemleri de bu listeye girer; PLC programlarının yedeği ve mühendislik istasyonları sık atlanır. Bu özel durum için üretimde IT/OT iş sürekliliği yazısına bakabilirsiniz.

BIA formu örnek alanları

Form, görüşmede birlikte doldurulacak kadar sade olmalı. Kırk alanlı bir Excel dosyası süreç sahibine gönderildiğinde ya boş döner ya da kopyala-yapıştır cevaplarla döner. Aşağıdaki alanlar çoğu kuruluş için yeterli bir başlangıçtır:

Bölüm	Alanlar
Tanım	Süreç/faaliyet adı, sahibi, yedek sahibi, lokasyon, bağlı olduğu ürün/hizmet
Çalışma düzeni	Çalışma saatleri, dönemsel yoğunluklar, normal personel sayısı
Etki	Her zaman dilimi için kategori bazında seviye, gerekçe notu
Hedef talebi	Önerilen MTPD, RTO, kabul edilebilir veri kaybı, asgari hizmet seviyesi
Kaynaklar	Asgari personel, uygulamalar, veri, ekipman, tesis, tedarikçiler
Geçici çözümler	Elle çalışma imkânı, süresi, birikmiş işi eritme süresi
Bağımlılıklar	Girdi aldığı ve çıktı verdiği süreçler
Onay	Süreç sahibi onayı, tarih, sonraki gözden geçirme tarihi

“Geçici çözümler” alanı en sık atlanan, ama strateji seçiminde belirleyici olan alandır. Bir süreç üç gün elle yürütülebiliyorsa o sürecin sistem RTO’su daha uzun tutulabilir. Öte yandan elle çalışmanın biriktirdiği iş de kaydedilmelidir: sistem geri geldiğinde girilecek kâğıt yığını, kurtarma süresini fiilen uzatır. Bunu hesaba katmayan RTO yanıltır.

Sonuçların doğrulanması ve onayı

Toplanan veri ham haliyle yönetime gitmez. Önce tutarlılık kontrolü yapılır:

• Birbirine girdi veren süreçlerin RTO’ları mantıksal sırada mı?
• Aynı uygulamaya bağlı süreçler için talep edilen kabul edilebilir veri kaybı birbirinden çok farklı mı? (Uygulama tek bir RPO ile korunacağından en sıkı talep belirleyici olur.)
• Tüm süreçler “4 saat” mi demiş? Bu genellikle ölçeğin yanlış anlaşıldığını gösterir.
• Tek kişiye bağımlılık, tek tedarikçi ve tek lokasyon bağımlılıkları işaretlendi mi?

Ardından sonuçlar yönetime tek sayfalık bir özet halinde gider: öncelikli faaliyetler ve önerilen MTPD/RTO değerleri, her faaliyetin kritik bağımlılıkları, mevcut teknik kapasiteyle ilk göze çarpan boşluklar, onay bekleyen kararlar. Yönetimin onayı kayda geçer; bu kayıt hem strateji seçiminin dayanağı hem de denetimde BIA sürecinin kanıtıdır. ISO 22301, BIA’nın planlı aralıklarla ve önemli değişikliklerde gözden geçirilmesini bekler. Pratikte bu, yılda bir tam tur ile yeni ürün, sistem veya organizasyon değişikliklerinde ara güncelleme demektir. Güncellenmeyen BIA, eski bir ağ şeması kadar yanıltıcıdır.

BIA’yı ilk kez yürüten ekiplerde dış bir kolaylaştırıcı, görüşme tekniği ve ölçek tasarımında zaman kazandırabilir; BIA ve iş sürekliliği planı hizmeti bu çalışmanın kapsamını açıklar. BIA’nın yönetim sistemi içindeki yeri için ISO 22301 danışmanlığı sayfasına bakabilirsiniz. Standardın kendisi için ISO 22301:2019 sayfası başvuru kaynağıdır; BIA’ya özel rehberlik ise ISO/TS 22317 teknik şartnamesinde yer alır.

Sık sorulan sorular

BIA’yı kim yapmalı: BT mi, iş birimleri mi?

BIA’nın sahibi iş sürekliliği sorumlusudur, verinin kaynağı ise süreç sahipleridir. BT, sistem bağımlılıklarını doğrulamak ve mevcut kurtarma kapasitesini göstermek için masadadır. BT’nin tek başına yaptığı BIA iş etkisini değil sistem kritikliğini ölçer ve öncelikleri yanlış sıralar.

BIA ne sıklıkla güncellenmeli?

Yılda bir tam gözden geçirme genel uygulamadır. Yeni ürün veya hizmet, büyük sistem değişikliği, birleşme, lokasyon değişikliği ya da önemli bir kesinti yaşandığında ilgili süreçlerin BIA kayıtları ara dönemde güncellenir.

BIA’da finansal etkiyi kesin tutarla hesaplamak gerekir mi?

Gerekmez. Amaç doğru sıralamadır, muhasebe kesinliği değil. Yönetimle önceden onaylanmış eşik aralıkları süreçleri karşılaştırmaya yeter. Kesin tutar hesabı yalnızca yatırım kararı gerektiren boşluklarda ayrıca yapılır.

Küçük bir şirkette BIA nasıl sadeleştirilir?

Süreç sayısı azsa form tek bir atölyede tüm süreç sahipleriyle doldurulabilir. Zaman dilimleri azaltılabilir, etki kategorileri üç dörde indirilebilir. Atlanmaması gerekenler şunlardır: onaylı bir ölçek, öncelikli faaliyet listesi ve kayda geçmiş bağımlılıklar.