ITSM ticket yönetir; Notivex kritik iletişimi görünür ve aksiyonlu hale getirir.

Problem: Ticket açıldı, ama doğru kişi haberdar oldu mu?

Olgun bir BT organizasyonunda bir sorun yaşandığında akış genellikle nettir: kullanıcı veya izleme sistemi bir ticket açar, talep kategorize edilir, bir ekibe atanır ve çözüm sürecinde durum güncellenir. Bu, ITSM araçlarının çok iyi yaptığı iştir. Ancak ticket akışının iyi çalışması ile doğru insanların doğru anda gerçekten haberdar olması her zaman aynı şey değildir.

Kritik bir olay düşünün: bir ödeme sistemi kesintiye girdi. ITSM tarafında bir "major incident" ticketı açıldı, önceliği yükseltildi, atandı. Buraya kadar her şey kayıt altında. Ama o anda asıl sorular şunlardır: Olaydan etkilenen iş birimi yöneticisi bu durumdan haberdar mı? Çağrı merkezi müşterilere ne diyeceğini biliyor mu? Kriz iletişim sorumlusu bildirimi gördü ve "okudum, devralıyorum" dedi mi? Yedek ekip lideri belirlenen sürede yanıt vermezse bir üst kademeye otomatik olarak çıkıyor mu?

ITSM, ticketın yaşam döngüsünü yönetmek için tasarlanmıştır; etkilenen tüm paydaşların bildirimi görüp onayladığını güvence altına almak için değil. Ticket "in progress" görünürken, etkilenen iş birimlerinin yarısı durumdan habersiz olabilir. İşte bu görünürlük ve onay boşluğu, klasik ITSM kurulumlarında çoğu zaman e-posta zincirleri, telefon turları ve grup mesajlarıyla doldurulmaya çalışılır.

Klasik yöntemler neden yetersiz kalır?

ITSM ile kritik iletişimi tek başına yürütmeye çalışan kurumların başvurduğu pratiklerin her birinin görünürlük, onay ve denetlenebilirlik tarafında bir açığı vardır:

• Ticket bildirim e-postaları: ITSM, atama ve durum değişikliklerinde otomatik e-posta gönderir. Ama bu e-postalar gelen kutusunda diğer yüzlerce bildirimin arasında kaybolur; açıldığı, okunduğu ve kabul edildiği ölçülmez. Kritik bir olay e-postası ile rutin bir SLA hatırlatması aynı görsel ağırlıkta görünür.
• Manuel telefon turu: Major incident'ta nöbetçi mühendis ilgili kişileri tek tek aramaya başlar. Bu süreç yavaştır, kim arandı kim aranmadı kaydı tutulmaz ve gece yarısı kimin ulaşılabilir olduğu şansa kalır.
• ITSM'in dahili bildirim özelliği: Çoğu araçta bir izleyici (watcher) ekleme veya bildirim atama vardır; fakat bu bildirim genellikle yalnızca BT kullanıcı havuzunu kapsar. Etkilenen üretim müdürü, hukuk ekibi veya saha personeli çoğu zaman ITSM lisansına sahip değildir, dolayısıyla bu döngünün tamamen dışında kalır.
• Ayrı kriz iletişim grupları: BT, olay anında ad-hoc bir grup kurar. Ancak bu grupta kimin "gördüm ve aksiyon aldım" dediği, kimin sessiz kaldığı ve bir üst kademeye ne zaman çıkılması gerektiği yapılandırılmış biçimde takip edilmez.

Sonuç olarak ITSM'in kapsadığı "servis sürecini yönetme" işi ile kapsamadığı "kurum geneli kritik bildirimin görülüp onaylandığını ve süresinde aksiyona döndüğünü kanıtlama" işi arasında bir boşluk kalır. Bu boşluk genellikle ancak bir olay büyüdüğünde, "neden bizi kimse haberdar etmedi?" sorusuyla fark edilir.

Notivex yaklaşımı

Notivex, ITSM aracının yerine geçmek yerine onun bıraktığı kurum geneli kritik iletişim boşluğunu kapatan bir bildirim ve operasyonel karar destek katmanı olarak konumlanır. Yapı taşları şöyle çalışır:

• Kritik bildirim ve zorunlu görünürlük: Bir major incident veya kritik durumda bildirim, gelen kutusunda kaybolan bir e-posta olmaz; ilgili kişilerin akışında atlanamayacak biçimde önüne çıkar. Bildirim BT havuzuyla sınırlı kalmaz; iş birimi yöneticisi, çağrı merkezi, hukuk veya saha gibi BT dışı paydaşları da kapsayacak şekilde kurgulanabilir.
• Acknowledge (gördüm/devraldım beyanı): Bildirimi alan kişi yalnızca görmekle kalmaz, "gördüm ve devralıyorum" beyanını verir. Böylece bildirimin gönderilmesi ile gerçekten alınması birbirinden ayrılır; ikisi de ayrı ayrı ölçülür.
• SLA içinde aksiyon takibi: Kritik bildirime belirli bir yanıt veya aksiyon süresi tanımlanır. Bu, ITSM'in çözüm SLA'sından farklı olarak bildirimin görülme ve sahiplenilme süresini izler. Süresinde yanıt gelmeyen bildirimler görünür kalır.
• Eskalasyon: Belirlenen sürede yanıt vermeyen bildirim, önceden tanımlı bir zincirde otomatik olarak bir üst kademeye çıkarılır. "Nöbetçi yanıt vermedi, kimse devralmadı" senaryosu sessizce kaybolmaz; eskalasyon kuralı devreye girer.
• Audit trail (denetlenebilir operasyon kaydı): Hangi bildirimin kime, ne zaman ulaştığı, kimin ne zaman onayladığı ve eskalasyonun nasıl ilerlediği zaman damgalı olarak tutulur. Bu kayıt yapısı, denetim ve uyum gereksinimlerine göre yapılandırılabilir biçimde tasarlanır.
• Entegrasyonlar: Notivex, mevcut ITSM aracınızla yan yana çalışacak şekilde konumlanır. Major incident sürecinizi ITSM'de açmaya devam eder, kurum geneli kritik iletişim katmanını Notivex üzerinden yürütürsünüz.

Bu yaklaşımın özü şudur: Notivex bir ITSM aracı değildir, ticket yönetmez ve servis kataloğunu işletmez. BT servis süreçlerini mevcut ITSM'iniz yönetmeye devam eder; Notivex yalnızca o olay etrafındaki kritik iletişimin görüldüğünü, onaylandığını ve süresinde aksiyona döndüğünü kanıtlanabilir kılar.

Örnek senaryo

Bir lojistik şirketinin servis masası yöneticisi, gece 02:00'de ana depo otomasyon sistemini yöneten sunucuda kritik bir kesinti yaşandığını öğrenir. ITSM tarafında otomatik olarak bir major incident ticketı açılmış, BT operasyon ekibine atanmıştır. Buraya kadar süreç doğru işler. Ancak bu kesinti yalnızca BT'yi ilgilendirmez: depo vardiya amiri, müşteri hizmetleri ekibi ve operasyon müdürü de durumdan anında haberdar olmalı, çünkü sabahki sevkiyatlar etkilenecektir.

Klasik yöntemde nöbetçi mühendis tek tek aramaya başlar; kimine ulaşır, kimine ulaşamaz, kim haberdar oldu kaydı tutulmaz. Aynı süreç Notivex üzerinde şöyle ilerler: ITSM'de açılan incident, kritik bildirimi tetikler ve ilgili tüm paydaşlara zorunlu görünürlükle iletilir. Depo vardiya amirinin ekranına şu bildirim düşer:

> "Kritik kesinti: Ana depo otomasyon sistemi devre dışı. Sabah sevkiyatlarını manuel plana göre hazırlayın. Lütfen 15 dakika içinde gördüğünüzü onaylayın. Onaylamazsanız bildirim bölge müdürüne eskale edilecektir."

Vardiya amiri "gördüm ve devralıyorum" beyanını verir; bu onay zaman damgasıyla kaydedilir. Belirlenen sürede yanıt vermeyen paydaşlar için bildirim otomatik olarak bir üst kademeye eskale olur. Olay kapandığında servis masası yöneticisi tek bir ekrandan kimin ne zaman haberdar olduğunu, kimin onayladığını ve eskalasyonun nasıl ilerlediğini denetlenebilir bir kayıt olarak görür. ITSM ticketı süreci yönetmeye devam ederken, kurum geneli iletişimin kanıtı Notivex'te kalır.

Kullanılabilecek modüller

• Kritik Bildirim — BT olaylarına bağlı kritik mesajları, BT dışı paydaşları da kapsayacak şekilde zorunlu görünürlükle ilgili kişilere ulaştırır.
• SLA — Bildirimin görülme ve sahiplenilme süresini tanımlar; süresinde yanıtlanmayanları görünür kılar.
• Eskalasyon — Belirlenen sürede yanıt gelmeyen bildirimleri önceden tanımlı zincirde bir üst kademeye otomatik taşır.
• Audit Trail — Hangi bildirimin kime ulaştığını, kimin ne zaman onayladığını ve eskalasyonun seyrini denetlenebilir operasyon kaydı olarak saklar.