Haftalık IT Toplantısı İçin Talep Verisinden Dashboard Hazırlamak
Haftalık BT toplantısında yüzlerce satırlık Excel dosyasını ekrana yansıtmak raporlama değildir. Bir ekipte bunu yaptığımız ilk toplantı iki saat sürdü; kayıtlar tek tek konuşuldu, fakat toplantı sonunda hangi üç işin eskale edileceği netleşmedi. Bazı tarihler metin, bazı sahipler boş, kapalı kayıtlar hâlâ aktif listede ve satınalma bekleyen işler teknik gecikme gibi görünüyordu.
Dashboardun amacı güzel grafik üretmek değil, karar süresini kısaltmaktır. Yönetici toplam hacmi, ekip lideri darboğazı, kayıt sahibi ise bu hafta yapacağı aksiyonu görmelidir. Bu nedenle önce veri sözlüğünü ve toplantının sorularını tanımladık. Görselleri ancak aynı kavramların herkes için aynı anlama geldiğinden emin olduktan sonra hazırladık.
Sorunun ortaya çıkışı
ITSM aracından alınan dışa aktarımda kayıt numarası, durum, öncelik, sahip, oluşturma ve hedef tarih vardı. Fakat durum adları zaman içinde değişmiş, ekip adları birleşmiş ve bazı talepler yeniden açılmıştı. “Aktif kayıt sayısı kaç?” sorusuna iki kişi farklı yanıt veriyordu. Toplantı ayrıntıya boğuluyor, kritik yaşlı kayıtlar yüksek hacimli yeni talepler arasında kayboluyordu.
İlk belirtiler ve yanlış varsayımlar
İlk yanlış varsayım, export dosyasının rapora hazır olduğuydu. İkincisi bütün geciken kayıtların aynı önemde kabul edilmesiydi. Hedef tarihi geçen düşük etkili talep ile hizmet kesintisi aynı kırmızı renkte gösterilince renk anlamını yitirdi. Kapanan iş sayısını tek başarı ölçütü yapmak da kolay talepleri teşvik eder. Hacim, yaş, etki ve bağımlılık birlikte okunmalıydı.
Teknik analiz
Önce durumları Active, Waiting, Resolved ve Closed gruplarına eşledik. Aging değerini oluşturma tarihinden, overdue değerini hedef tarih ile rapor anı arasından hesapladık. Bekleme nedeni ve son güncelleme tarihi ayrı alan oldu. Boş owner, geçersiz tarih, yinelenen kayıt ve kapanmış fakat açık görünen satırlar kalite istisnasına alındı. Ortalama yerine medyan ve yaş dilimleri kullanmak uç değerlerin etkisini azalttı.
# Excel tablo formülü örneği; veri değiştirmez.
=MAX(0,INT(ReportDate-[@CreatedAt]))
=IF(AND([@StatusGroup]<>"Closed",[@DueDate]<ReportDate),"Overdue","On track")
Uygulanan çözüm veya önerilen mimari
Tek sayfalık yönetim görünümüne aktif hacim, geciken kritik işler, yaş dilimleri ve ekip dağılımını koyduk. Altında yalnızca karar gerektiren kayıtların aksiyon tablosu yer aldı: owner, sonraki adım, son tarih ve engel. Satınalma bekleyenler ayrı gösterildi. Veri hazırlığını Power Query benzeri tekrarlanabilir adımlarla yaptık; haftalık elle kopyalama ve formül sürükleme riskini azalttık. Her metrikten kaynak satıra inilebildi.
Alternatifler ve karar gerekçesi
ITSM ürününün yerleşik dashboardu gerçek zamanlılık ve yetki açısından avantajlıdır; fakat özel veri temizliği sınırlı olabilir. BI platformu ölçeklenebilir, ancak küçük ekipte model ve lisans yükü yaratabilir. Excel hızlı bir başlangıçtır fakat kişisel dosyaya dönüşmemelidir. Mevcut hacimde kontrollü veri modeli olan Excel’i seçtik, büyüme ve otomatik yenileme ihtiyacı için BI geçiş eşiği belirledik.
Güvenlik ve operasyonel riskler
Ticket açıklamaları kişisel veri ve teknik ayrıntı içerebilir; yönetim dashboarduna yalnızca gerekli alanları aldık. Dosya erişimi rol bazlı sınırlandı, e-posta eki olarak dolaştırılmadı ve saklama süresi tanımlandı. Formül hatası veya eski veri yanlış eskalasyona yol açabileceğinden rapor zamanı görünür yazıldı. Metriklerin çalışan sıralamasına dönüşmesini önlemek için ekip kapasitesi ve iş karmaşıklığı bağlamı korundu.
Çıkarılan Dersler
- Dashboard karar sorusuyla başlamalıdır.
- Export verisi rapora hazır kabul edilmemelidir.
- Ortalama tek başına aging dağılımını gizler.
- Her gösterge kaynak kayda izlenebilmelidir.
- Dış bağımlılıklar ekip gecikmesinden ayrılmalıdır.
Kontrol Listesi
- Durum eşleme tablosu güncel mi?
- Rapor zamanı belirtiliyor mu?
- Boş owner ve hatalı tarihler kontrol edildi mi?
- Aksiyonların sahibi ve tarihi var mı?
- Hassas açıklamalar dışarıda mı?