Incident ve Service Request Ayrımı Neden Önemlidir?

Bir operasyon toplantısında kapanan kayıt sayısı iyi görünmesine rağmen iş birimleri hizmet kesintilerinin geç çözüldüğünü söylüyordu. Ham veriye indiğimizde parola talebi, yeni ekipman isteği, uygulama hatası ve erişim kesintisinin aynı kayıt türünde tutulduğunu gördük. Ekip çok sayıda standart işi kapatıyor, fakat gerçek arızaların tepki süresi bu toplamın içinde görünmez oluyordu.

Incident ve service request ayrımı akademik bir ITIL tartışması değildir. Birincisi normal hizmeti mümkün olan en kısa sürede geri getirmeyi, ikincisi önceden tanımlı bir hizmeti kontrollü biçimde sunmayı hedefler. Ayrım doğru kurulmadığında SLA hedefi, öncelik modeli, onay akışı ve otomasyon yanlış çalışır. Kullanıcıdan terminoloji ezberlemesini beklemek yerine anlaşılır bir giriş deneyimi tasarlamak gerekir.

Sorunun ortaya çıkışı

Kurumun portalında tek bir “BT destek” formu vardı. Kullanıcı açıklama yazıyor, servis masası kaydı elle yönlendiriyordu. Standart erişim talepleri onaysız ilerleyebiliyor; kritik kesintiler ise satınalma veya bilgi bekleyen kayıtlarla aynı kuyrukta kalıyordu. Aylık raporda ortalama çözüm süresi hesaplanıyor fakat birbirinden tamamen farklı iş türleri toplandığı için sayı yönetim kararı üretmiyordu.

İlk belirtiler ve yanlış varsayımlar

İlk belirti, ekip performansı ile kullanıcı algısının çelişmesiydi. Çözüm olarak daha fazla kategori eklemek önerildi; oysa uzun kategori listesi kullanıcı hatasını artırır. “Kullanıcı doğru seçsin” varsayımı da gerçekçi değildi. İnsanlar hizmet kesildiğinde incident kelimesini düşünmez. Ön yüzde “Bir şey çalışmıyor” ve “Yeni bir şey istiyorum” gibi açık seçenekler, arka planda doğru kayıt türüne çevrilmeliydi.

Teknik analiz

Örnek kayıtları hizmet, etki, aciliyet, onay ihtiyacı ve tekrar edilebilirlik bakımından sınıflandırdık. Incident mevcut hizmette plansız bozulma veya kalite düşüşüydü. Service request parola sıfırlama, standart yazılım veya ekipman gibi tanımlı sunumdu. Tekrarlayan incident kümeleri problem yönetimine, kontrollü üretim değişiklikleri change sürecine bağlandı. Yeniden açılma, ilk yanıt ve çözüm süreleri kayıt türü bazında ayrı hesaplandı.

Uygulanan çözüm veya önerilen mimari

Portal girişini iki sade niyetle yeniden düzenledik ve popüler talepleri hizmet kataloğuna taşıdık. Incident formunda etkilenen hizmet, kapsam ve başlangıç zamanı; request formunda istenen öğe, gerekçe ve onay bilgisi öne çıktı. Servis masasına kısa karar ağacı ve düzeltme yetkisi verildi. Yanlış tür değiştirildiğinde ilk kayıt zamanı korunarak raporun yapay biçimde iyileşmesi önlendi.

Alternatifler ve karar gerekçesi

Tek form düşük hacimli küçük ekiplerde sürdürülebilir olabilir; ancak raporlama öncesi disiplinli triage gerekir. Yapay zekâ ile otomatik sınıflandırma yardımcı olabilir fakat dil, veri kalitesi ve yanlış öncelik riskinden dolayı insan kontrolünü kaldırmamalıdır. Çok ayrıntılı katalog ise bakım yükü ve kullanıcı kararsızlığı yaratır. Biz az sayıda anlaşılır giriş, güçlü arka plan yönlendirmesi ve düzenli katalog gözden geçirmesini seçtik.

Güvenlik ve operasyonel riskler

Yanlışlıkla request seçilen güvenlik olayı normal SLA’da bekleyebilir. Bu nedenle şüpheli e-posta, hesap ele geçirilmesi ve veri kaybı belirtileri için ayrı, görünür kanal tanımlandı. Formlarda parola veya hassas veri istenmedi. Kayıt türü değişiklikleri denetim izine alındı; KPI baskısıyla incident kayıtlarının request olarak yeniden sınıflandırılması yönetici onayı ve örneklem kontrolüyle engellendi.

Çıkarılan Dersler

Kontrol Listesi