Xurrent’te Bir Talebi Bağımlı Görevlere Bölmek

Çok lokasyonlu bir kurumda “yeni sunucu kurulumu” kaydı açılmıştı. Merkezi sistem ekibi kuruluma hazır görünüyordu, fakat yerel ekip aktarılacak kullanıcı verisini henüz toplamamıştı. Ana kayıt tek kişiye atanmış olduğu için panelde iş başlamış, hatta SLA ilerliyor görünüyordu. Gerçekte iki ayrı teslimat ve bunlar arasında açık bir ön koşul vardı. Sorun teknik kapasiteden çok işin ITSM aracında yanlış modellenmesiydi.

Xurrent gibi platformlarda request, workflow ve task kavramlarını ayırmak yalnızca düzenli ekran elde etmek için yapılmaz. Doğru model, bir sonraki görevin ne zaman açılacağını, kimin beklediğini, hangi kanıtla tamamlanacağını ve talebin ne zaman kapanabileceğini belirler. Sahada en iyi sonuç, her ayrıntıyı yüzlerce göreve bölmekten değil, gerçek devir noktalarını görünür kılmaktan geldi.

Sorunun ortaya çıkışı

Talep kataloğunda sunucu kurulumu tek faaliyet olarak tanımlanmıştı. Oysa yerel BT veri listesini çıkaracak, iş sahibi kapsamı onaylayacak, merkezi ekip altyapıyı hazırlayacak ve son kabul yapılacaktı. İlk adım tamamlanmadan ikinci adımın başlaması veri kaybı ve yeniden çalışma riski yaratıyordu. E-posta ile koordinasyon yapıldığında bu bağımlılık yalnızca kişilerin hafızasında kalıyor, izin veya vardiya değişiminde süreç duruyordu.

İlk belirtiler ve yanlış varsayımlar

Yönetim raporunda merkezi ekip gecikiyor görünürken ekip, yerel hazırlığı beklediğini söylüyordu. İlk varsayım daha fazla hatırlatma göndermekti. Ancak bildirim sayısını artırmak sahipliği düzeltmez. Başka bir yanlış yaklaşım da her alt işi ayrı request yapmaktı; bu durumda ortak sonuç, ilişki ve kapanış koşulu parçalanacaktı. Tek kayıt altında yapılandırılmış görevler daha doğru bir hizmet görünümü sağladı.

Teknik analiz

Önce hizmetin aşamalarını ve giriş-çıkış kriterlerini yazdık. Yerel hazırlık görevinin çıktısı onaylı veri listesi, merkezi kurulum görevinin girdisi bu listeydi. Atama grupları lokasyona göre çözümlenmeli, görev bağımlılığı predecessor tamamlanmadan successor başlamayacak biçimde kurulmalıydı. Ana request tüm görevler tamamlanmadan kapanmamalı; iptal, ret ve eksik bilgi yolları da normal akış kadar açık olmalıydı.

Uygulanan çözüm veya önerilen mimari

Katalog öğesine iki temel görevli bir workflow bağladık. İlk görev ilgili lokasyonun destek grubuna atandı ve standart veri hazırlama kontrolünü içerdi. Tamamlanma kanıtı eklendiğinde merkezi kurulum görevi aktif oldu. Kurulumdan sonra talep sahibine kabul adımı gönderildi. Otomatik bildirimler yalnızca atama, gecikme eşiği ve devir anında üretildi; gereksiz e-posta gürültüsünden kaçınıldı. İstisnalar için hizmet yöneticisine kontrollü eskalasyon tanımlandı.

Alternatifler ve karar gerekçesi

Basit checklist daha az yapılandırma gerektirir, ancak görevlerin farklı ekiplere atanması ve ayrı sürelerinin ölçülmesi gerekiyorsa yetersiz kalır. Ayrı talepler bağımsız hizmetler için uygundur; aynı çıktının parçaları için ilişki yönetimini zorlaştırır. Tam otomasyon, yüksek hacimli ve kararlı süreçte değerlidir; düşük hacimde bakım maliyeti yaratabilir. Bu vakada iki bağımlı görev, görünürlük ile yönetim yükü arasında dengeli çözümdü.

Güvenlik ve operasyonel riskler

Görev açıklamasına kullanıcı parolası, gerçek sunucu adı veya hassas dosya yolu yazılmaması kuralını ekledik. Eklerin erişimi yalnızca ilgili gruplarla sınırlandı ve saklama politikası uygulandı. Yanlış lokasyona otomatik atama, işin gereksiz kişilere görünmesine yol açabileceğinden yönlendirme tablosu periyodik kontrol edildi. Acil taleplerin bağımlılığı yetkisizce atlamaması için bypass hakkı sınırlı ve kayıtlı tutuldu.

Çıkarılan Dersler

Kontrol Listesi

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

Kontrol Listesi