Kritik bildirimleri görünür, onaylı ve raporlanabilir hale getirin.

Problem

Kurumlarda en kritik bilgiler çoğu zaman en zayıf kanallardan akar. Bir acil bakım duyurusu e-postayla gönderilir ama gelen kutusunun dibinde kaybolur; bir güvenlik talimatı WhatsApp grubuna düşer ama yüzlerce mesajın arasında görülmez; sözlü iletilen bir uyarı ise vardiya değişiminde yarıda kalır. Sonuçta bilgi "gönderilmiş" sayılır, ama gerçekten ulaşıp ulaşmadığı belirsizdir.

Asıl risk burada başlar. Kritik bir bildirim, normal bir duyurudan farklı olarak sonuç doğurur: bir kişi haberdar olmadığında üretim durur, müşteri etkilenir, güvenlik açığı oluşur ya da uyum gerekliliği ihlal edilir. Buna rağmen birçok kurum, "bu kişiye ulaştık mı, ne zaman gördü, onayladı mı?" sorusuna kanıtlanabilir bir cevap veremez. Bilgi dağınık kanallara yayıldığında sorumluluğun kimde olduğu da bulanıklaşır.

Klasik yöntemler neden yetersiz kalır?

Kullanılan kanalların hiçbiri kritik iletişim için tasarlanmamıştır:

• E-posta, görünürlüğü garanti etmez. Açılma takibi piksel tabanlıdır, kurumsal filtrelerle güvenilmez sonuç verir; üstelik açılma okumayı, okuma da onayı garanti etmez.
• Mesajlaşma uygulamaları bireysel iletişim için pratiktir ama okundu bilgisi kullanıcı kontrolündedir, kapatılabilir ve kurumsal bir denetim kaydına dönüştürülemez. Kritik mesaj, akışın içinde sıradan bir bildirim gibi kaybolur.
• Pano duyuruları ve sözlü aktarım ise hiçbir iz bırakmaz; kimin ne zaman bilgilendirildiği sonradan çıkarılamaz.

Ortak eksik şudur: bu yöntemler gönderim, ulaşma, okuma, onay ve aksiyon adımlarını tek bir tutarlı zincirde birleştirmez. Bir bildirim okunmadığında otomatik olarak kimseyi uyaramaz, süre aşıldığında üst kademeye taşınmaz ve sonradan raporlanabilir bir kayıt üretmez. Kritik iletişimin denetlenebilirliği tamamen insanların hafızasına ve iyi niyetine kalır.

Notivex yaklaşımı

Notivex'in kritik bildirim modülü, bir duyuruyu "gönderildi" durumundan "görüldü ve aksiyona dönüştü" durumuna taşıyan bir operasyonel kontrol katmanı olarak konumlanır. Süreç şu yapı taşlarıyla kurulur:

• Zorunlu görünürlük — Kritik bildirim, alıcının ekranında öne çıkar ve başka bir akışın içinde kaybolmaz. Önemli bilginin gerçekten görülmesi, sürecin geri kalanının anlamlı olması için temel koşuldur.
• Okudum/onayladım (acknowledge) kaydı — Alıcı yalnızca bildirimi görmekle kalmaz, gördüğünü ve gerektiğinde içeriği kabul ettiğini açık bir aksiyonla teyit eder. Her yanıt, kim ve ne zaman bilgisiyle kayda geçer.
• SLA takibi — Her kritik bildirime bir yanıt süresi tanımlanabilir. Sistem, hangi alıcıların süre içinde onayladığını, kimlerin geciktiğini gerçek zamanlı izler; bu, kritik bilginin "ne zamana kadar" ele alınması gerektiğini somut bir ölçüye bağlar.
• Eskalasyon — Tanımlı süre içinde yanıt vermeyen alıcılar için bildirim otomatik olarak üst kademeye veya yedek sorumluya taşınır. Böylece tek bir kişinin gözden kaçırması, kritik bir bilginin tamamen kaybolmasına dönüşmez.
• Audit trail — Gönderim, ulaşma, okuma, onay ve eskalasyon olayları zaman damgalı, geriye dönük müdahaleye karşı korunacak biçimde kaydedilir. Bu, denetlenebilir bir operasyon kaydı oluşturur.
• Raporlama — Tüm bu veriler tekil mesajlar yerine operasyonun bütününe ait bir tabloya dönüşür: hangi duyuruyu kimin ne zaman okuduğu, kimin onaylamadığı ve eskalasyonun ne zaman devreye girdiği tek yerden görülebilir ve dışa aktarılabilir.

Amaç, kritik iletişimi insan hafızasına bağlı kalmaktan çıkarıp, takip edilebilir ve raporlanabilir bir sürece dönüştürmektir. KVKK gereksinimlerine göre yapılandırılabilir kurulum ve on-premise seçeneği, kayıtların kurumun kendi altyapısında tutulmasına imkân tanır.

Örnek senaryo

Bir üretim tesisinde bilgi işlem müdürü, ERP sisteminde planlanmamış bir kesintinin başladığını fark eder ve etkilenen tüm vardiya sorumlularına acil bir kritik bildirim gönderir:

> "ACİL: ERP sistemi 14:20 itibarıyla erişime kapalıdır. Lütfen sipariş girişlerini geçici formla yürütün ve bu bildirimi okuduğunuzu onaylayın. Tahmini çözüm süresi 90 dakikadır."

Bildirim, zorunlu görünürlükle 18 vardiya sorumlusunun ekranında öne çıkar ve 15 dakikalık bir SLA ile gönderilir. İlk 15 dakikada 15 sorumlu bildirimi okuyup onaylar; süre içinde yanıt vermeyen 3 sorumlu için sistem otomatik eskalasyon tetikler ve onların üst amirlerine bilgi düşer. Üst amir, bu 3 kişiye doğrudan ulaşarak geçici sürece geçmelerini sağlar.

Olay kapandığında bilgi işlem müdürü raporu açar: bildirimin kime, ne zaman ulaştığı, kimin kaç dakikada onayladığı ve eskalasyonun hangi noktada devreye girdiği zaman damgalarıyla görülür. Böylece "duyduk/duymadık" tartışması yerine, kayıtlı verilere dayanan bir değerlendirme ve süreç iyileştirme imkânı doğar.

Kullanılabilecek modüller

• Kritik Bildirim — Acil ve öncelikli duyuruları, normal bildirimlerden ayrışacak biçimde, takip edilebilir bir akışla iletir.
• Zorunlu Görünürlük — Kritik bildirimin alıcının önüne çıkmasını sağlayarak başka akışların içinde kaybolmasını engeller.
• SLA — Her bildirime yanıt süresi tanımlar ve onay durumunu gerçek zamanlı izleyerek geciken alıcıları görünür kılar.
• Eskalasyon — Süre içinde yanıtlanmayan bildirimleri otomatik olarak üst kademeye veya yedek sorumluya taşır.
• Audit Trail — Gönderim, okuma, onay ve eskalasyon olaylarını zaman damgalı ve denetlenebilir biçimde kaydeder.