Bir kesinti ya da ciddi bir operasyon hatası sona erdiğinde, ekiplerin çoğu rahat bir nefes alır ve günlük işe geri döner. Oysa olayın en değerli kısmı tam bu noktada başlar: Ne olduğunu, neden olduğunu ve bir daha olmaması için neyin değişmesi gerektiğini anlamak. Bu çalışma yapılmadığında aynı sorunlar farklı biçimlerde tekrar eder.
Bu yazıda olay sonrası değerlendirmenin, yani İngilizcede "postmortem" olarak bilinen çalışmanın, hem yazılım sağlayıcısı hem de acente tarafında nasıl yürütülebileceğini ve suçlamasız yaklaşımın neden belirleyici olduğunu ele alıyoruz.
Hangi olaylar değerlendirilmeli?
Her küçük aksaklık için uzun bir toplantı gerekmez. Değerlendirme için önceden belirlenmiş ölçütler kullanmak, sürecin hem tutarlı hem de sürdürülebilir olmasını sağlar. Tipik ölçütler şunlardır:
- Kullanıcıları belirli bir sürenin üzerinde etkileyen kesintiler.
- Veri kaybı ya da veri tutarsızlığı yaşanan olaylar.
- Müşteriye yanlış bilgi gönderilmesi gibi dışarıya yansıyan hatalar.
- Güvenlik olayları ve şüpheli erişim girişimleri.
- Çözülmüş olsa bile "kıl payı" atlatılmış ciddi riskler.
Son madde çoğu zaman göz ardı edilir; oysa zararla sonuçlanmamış bir olay, öğrenmek için düşük maliyetli bir fırsattır.
Suçlamasız yaklaşım neden önemli?
Olay sonrası değerlendirmelerde en sık düşülen hata, sorunu bir kişinin hatasına indirgemektir. "Çalışan yanlış dosyayı sildi" ya da "mühendis yanlış komutu çalıştırdı" gibi tespitler doğru olabilir, ancak bir şey öğretmez. Asıl soru, sistemin o hatanın yapılmasına neden izin verdiği ve hatanın neden daha erken fark edilmediğidir.
Suçlamasız yaklaşımın pratik faydaları şunlardır:
- İnsanlar ne yaptıklarını açıkça anlatır; bilgi saklanmaz.
- Kök nedenler kişilerden süreçlere ve araçlara kayar.
- Ekip, hatalarını bildirmekten çekinmez; sorunlar daha erken ortaya çıkar.
Bu, sorumluluğun ortadan kalktığı anlamına gelmez. Sorumluluk, aynı hatanın tekrarlanmaması için gereken değişiklikleri hayata geçirme biçiminde ortaya çıkar.
Değerlendirme belgesinin bölümleri
Özet
Olayın ne olduğu, ne kadar sürdüğü ve kimleri etkilediği birkaç cümleyle anlatılır. Belgeyi yalnızca bu bölümü okuyan biri de olay hakkında doğru bir fikir edinebilmelidir.
Zaman çizelgesi
İlk belirtiden çözüme kadar yaşanan olaylar saat sırasıyla listelenir: sorunun başladığı an, fark edildiği an, ilk müdahale, alınan kararlar ve hizmetin normale döndüğü an. Bu çizelge, tespit ve müdahale süreleri arasındaki boşlukları görünür kılar.
Etki
Etkilenen kullanıcı sayısı ya da işlevler, gecikmeye uğrayan işler ve varsa veri etkisi açıklanır. Acente tarafında bu bölüm, örneğin kaç yenileme görüşmesinin ertelendiği gibi somut bilgilerle doldurulabilir.
Kök neden ve katkıda bulunan etkenler
Tek bir kök neden aramak yerine olayı mümkün kılan etkenlerin tamamı listelenir. "Neden?" sorusunu art arda sormak bu aşamada işe yarayan basit bir yöntemdir.
Ne iyi gitti?
Olay sırasında işe yarayan adımlar da kaydedilmelidir. İzleme sisteminin sorunu erken yakalaması ya da ekibin alternatif çalışma yöntemine hızla geçmesi gibi olumlu noktalar, korunması gereken uygulamalardır.
Aksiyonlar
Her aksiyonun bir sahibi ve bir hedef tarihi olmalıdır. "Daha dikkatli olunacak" gibi ölçülemeyen maddeler yerine "toplu silme işlemlerine onay adımı eklenecek" gibi somut değişiklikler yazılmalıdır.
Acente tarafında küçük ölçekli değerlendirme
Olay sonrası değerlendirme yalnızca yazılım ekiplerine özgü değildir. Acentede yaşanan operasyon hataları da aynı yöntemle ele alınabilir. Örneğin bir yenileme hatırlatmasının yanlış müşteriye gönderildiği bir durumu düşünelim. Kısa bir değerlendirme şu sorularla yürütülebilir:
- Hatırlatma hangi kayıttan, hangi adımla gönderildi?
- Müşteri kaydında iletişim bilgisi neden hatalıydı; kayıt nasıl ve kim tarafından oluşturuldu?
- Benzer hatalı kayıtların bulunup bulunmadığı nasıl kontrol edilebilir?
- Kayıt oluşturma sırasında hangi doğrulama adımı bu hatayı önlerdi?
Bu tür bir çalışma, mükerrer ya da hatalı kayıtların temizlenmesi için bir başlangıç noktası olabilir. Denetim izi ve işlem kayıtları sunan bir acente CRM yapısı, bu soruların cevabını bulmayı kolaylaştırır.
Sağlayıcıdan beklenebilecek olay raporu
Yazılım sağlayıcısının yaşadığı ciddi bir kesinti sonrasında acentelerle paylaştığı kısa bir olay raporu, güven ilişkisinin önemli bir parçasıdır. Bu raporda teknik ayrıntılara girilmesi gerekmez; ancak şu bilgilerin bulunması beklenebilir:
- Olayın başlangıç ve bitiş zamanı.
- Etkilenen işlevler ve etkilenmeyenler.
- Nedenin anlaşılır bir özeti.
- Tekrarını önlemek için alınan ya da planlanan önlemler.
Aksiyonların takibi
Değerlendirmelerin en zayıf halkası, aksiyonların yazıldıktan sonra unutulmasıdır. Bunu önlemek için aksiyonların günlük iş takip sistemine görev olarak eklenmesi, belirli aralıklarla açık aksiyonların gözden geçirilmesi ve tamamlanan aksiyonların değerlendirme belgesine işlenmesi önerilir. Aynı kök nedenin farklı olaylarda tekrar görünmesi, aksiyonların yeterli olmadığının işaretidir.
Değerlendirme toplantısını yürütmek
Toplantının olaydan kısa süre sonra, ayrıntılar henüz tazeyken yapılması önerilir. Olaya doğrudan müdahale eden kişilerin yanında, etkilenen iş biriminden de birinin bulunması faydalıdır; çünkü teknik ekibin göremediği etkileri en iyi onlar anlatır. Toplantıyı yöneten kişinin görevi, konuşmayı kişilerden olaylara yönlendirmek ve "kim yaptı?" yerine "ne oldu ve neden mümkündü?" sorularını öne çıkarmaktır. Toplantı sonunda belge taslağı katılımcılarla paylaşılmalı ve eksik kalan noktalar tamamlanmalıdır.
InsureHub bakış açısı
InsureHub, sigorta acentelerine yazılım sağlayan bir teknoloji şirketi olarak ürünü sürekli geliştirmeyi ve yaşanan sorunlardan öğrenmeyi bir arada görür. Web acente panelindeki işlem kayıtları, görevler ve raporlama özellikleri, acentenin kendi operasyonel değerlendirmelerinde de veri kaynağı olarak kullanılabilir. Panelin yapısını sigorta acentesi yazılımı sayfasından inceleyebilir, sorularınızı demo talebi sonrasında ekibimizle paylaşabilirsiniz.
Sonuç
Olay sonrası değerlendirme, kesintiyi bir kayıptan öğrenme fırsatına dönüştürür. Suçlamasız bir yaklaşım, net bir belge yapısı ve takip edilen aksiyonlar, aynı sorunun ikinci kez yaşanma olasılığını azaltır ve ekibin hatalarını açıkça konuşabildiği bir kültür oluşturur.