İş sürekliliği konuşmaları çoğu zaman "yedek alıyor muyuz?" sorusuyla başlar ve orada biter. Oysa bir kesinti yaşandığında acenteyi asıl ilgilendiren iki soru vardır: Sistem ne kadar sürede yeniden kullanılabilir olacak ve geri döndüğünde ne kadarlık bir iş kaybolmuş olacak? Bu iki sorunun ölçülebilir karşılıkları RTO ve RPO olarak adlandırılır.
Bu yazıda bu iki kavramı teknik jargona boğmadan, bir sigorta acentesinin günlük işleri üzerinden ele alıyor ve acenteniz için gerçekçi hedeflerin nasıl belirlenebileceğini adım adım anlatıyoruz.
RTO: Ne kadar süre beklemeyi göze alabilirsiniz?
RTO (Recovery Time Objective), bir kesintinin başlamasından hizmetin yeniden kullanılabilir hale gelmesine kadar geçmesine izin verilen en uzun süredir. Bir hedef olduğu için "olsa iyi olur" düzeyinde bir dilek değil, planlamanın üzerine kurulduğu bir sınırdır.
Acente açısından RTO şu soruyla somutlaşır: Müşteri kayıtlarına, yenileme listesine ve teklif ekranlarına erişim olmadan ekip kaç saat çalışabilir? Bazı işler birkaç saat ertelenebilir; bazıları ise aynı gün içinde tamamlanmazsa müşteri kaybına ya da teminatsız kalan bir araca dönüşebilir.
RPO: Ne kadarlık veriyi yeniden girmeyi göze alabilirsiniz?
RPO (Recovery Point Objective), bir kesinti sonrasında geri dönülecek en son veri noktasının ne kadar eski olabileceğini tanımlar. Sistemler son yedekten geri yüklendiğinde, o yedekten sonra girilen kayıtlar yeniden oluşturulmak zorundadır.
Örneğin RPO bir saat olarak belirlenmişse, en kötü durumda son bir saat içinde girilen notlar, tahsilat kayıtları ve teklif sonuçları yeniden işlenmelidir. RPO ne kadar kısa olursa yedekleme ya da veri kopyalama o kadar sık yapılmalıdır.
İki kavram arasındaki fark neden önemli?
RTO zamana, RPO veriye odaklanır. Bir sistem çok hızlı ayağa kalkabilir ama dünden kalma bir veriyle açılabilir; bu durumda RTO iyi, RPO kötüdür. Tersi de mümkündür: Hiç veri kaybolmaz ama erişim bütün gün kesik kalır. Acente için her iki tablo da farklı sonuçlar doğurur:
- Uzun RTO: Telefonla arayan müşteriye anında yanıt verilemez, sahadaki temsilci teklif hazırlayamaz.
- Uzun RPO: Gün içinde yapılan görüşmeler ve tahsilat girişleri kaybolur, mükerrer arama ve hatalı hatırlatma riski doğar.
Acente süreçlerini kritiklik seviyesine göre ayırmak
Tek bir RTO ve RPO değeri bütün süreçler için doğru değildir. Daha sağlıklı yaklaşım, işleri gruplara ayırmak ve her grup için ayrı hedef belirlemektir.
Aynı gün tamamlanması gereken işler
Bitiş tarihi yaklaşan poliçelerin yenilenmesi, müşterinin beklediği trafik, kasko veya DASK teklifleri ve hasar sonrası acil bilgi talepleri bu gruptadır. Bu süreçlerde RTO saatlerle ifade edilir ve RPO mümkün olduğunca kısa tutulur.
Birkaç gün ertelenebilecek işler
Haftalık performans raporları, kampanya hazırlıkları ve segment analizleri birkaç gün gecikse bile müşteri doğrudan etkilenmez. Bu grupta daha uzun hedefler kabul edilebilir.
Kayıt bütünlüğü kritik olan işler
Tahsilat kayıtları ve komisyon hesapları beklemeye dayanabilir ama kaybolmaya dayanamaz. Burada RTO esnek, RPO ise sıkı olmalıdır.
Hedefleri belirlemek için pratik bir yöntem
Hedefleri masa başında tahmin etmek yerine şu adımlarla belirlemek daha gerçekçi sonuç verir:
- Ekipteki her rol için gün içinde yapılan beş temel işi listeleyin.
- Her işin yazılım olmadan ne kadar süre yürütülebileceğini ekip üyeleriyle birlikte tartışın.
- Bir saatlik veri kaybının o iş için ne anlama geldiğini somut örnekle ifade edin; örneğin "sabah girilen on iki tahsilat kaydını yeniden bulmak".
- Ortaya çıkan süreleri üç kritiklik grubuna yerleştirin.
- Hedefleri yazılı hale getirip yazılım sağlayıcınızın taahhütleriyle karşılaştırın.
Bu çalışmanın en değerli çıktısı çoğu zaman sayıların kendisi değil, ekibin hangi işin gerçekten ertelenemez olduğu konusunda ortak bir anlayışa varmasıdır.
Sağlayıcı taahhütleriyle hedeflerinizi eşleştirmek
Web tabanlı bir sigorta acentesi yazılımı kullanan bir acente, altyapı tarafındaki RTO ve RPO değerlerini doğrudan kendisi belirlemez; bunlar sağlayıcının mimarisine ve yedekleme düzenine bağlıdır. Acentenin görevi, kendi iş hedefleriyle sağlayıcının sunduğu değerler arasında bir boşluk olup olmadığını görmektir.
Değerlendirme sırasında şu konuları netleştirmek faydalıdır:
- Veri kopyalama ya da yedekleme hangi aralıklarla yapılıyor ve bu aralık RPO hedefinizi karşılıyor mu?
- Büyük bir altyapı sorununda hizmetin yeniden açılması için öngörülen süre nedir?
- Hedeflerle gerçekleşen kurtarma süreleri arasında fark çıktığında acente nasıl bilgilendiriliyor?
Sağlayıcının değerleri hedeflerinizden uzunsa iki seçenek vardır: ya hedefleri gözden geçirirsiniz ya da aradaki boşluğu acente içi geçici çalışma yöntemleriyle kapatırsınız.
Boşluğu kapatan acente içi önlemler
Altyapı hedefleri ne olursa olsun, acentenin kendi tarafında alabileceği önlemler RTO ve RPO etkisini hafifletir:
- Kritik listelerin dönemsel dökümü: Önümüzdeki günlerde yenilenecek poliçelerin güncel bir listesini yetkili kişilerin erişebileceği güvenli bir ortamda tutmak.
- Alternatif erişim kanalı: Web paneline erişim sorunu ofis kaynaklıysa, aynı veri üzerinde çalışan mobil sigorta uygulaması üzerinden işe devam edebilmek.
- Kesinti günlüğü: Erişim olmadığı sürede yapılan görüşme ve tahsilatları kısa notlarla kaydedip sistem geri geldiğinde toplu olarak işlemek.
InsureHub bakış açısı
InsureHub, sigorta acentelerine yazılım sağlayan bir teknoloji şirketi olarak kurtarma hedeflerini yalnızca altyapı ekibinin değil, acenteyle birlikte konuşulması gereken bir konu olarak görür. Müşteri ve acente CRM kayıtları, poliçe ve yenileme takibi ile tahsilat bilgileri tek bir web acente panelinde tutulduğu için hangi verinin hangi süreçte kritik olduğu da daha net görünür. Kendi kritik süreçleriniz için hedeflerinizi belirledikten sonra bunları demo görüşmesinde ekibimizle birlikte değerlendirebilirsiniz.
Sonuç
RTO ve RPO, iş sürekliliğini soyut bir güvence olmaktan çıkarıp ölçülebilir bir plana dönüştürür. Acente için doğru başlangıç noktası teknik terimler değil, "hangi iş ne kadar bekleyebilir ve ne kadar kayba dayanabilir?" sorusudur. Bu soruya rol bazında verilen dürüst cevaplar, hem sağlayıcı seçimini hem de kriz anındaki davranışı belirler.