Satınalma Bekleyen IT Talepleri Neden Ayrı İzlenmeli?

Bir kullanıcının dizüstü bilgisayar talebi teknik ekip tarafından aynı gün incelenmiş, standart onay alınmış ve ürün özellikleri hazırlanmıştı. Kayıt daha sonra haftalarca açık kaldı. Aylık raporda bu süre BT çözüm süresine yazılıyor, kullanıcı ise kaydın neden ilerlemediğini göremiyordu. Satınalma tarafı da kaç IT talebinin bütçe veya tedarikçi yanıtı beklediğini toplu olarak izleyemiyordu.

Buradaki amaç gecikmeyi başka bir ekibin üzerine bırakmak değildir. Uçtan uca hizmet süresi kullanıcı için önemini korur; bunun yanında her aşamanın kontrol edilebilir süresi ayrı ölçülmelidir. Doğru bekleme durumu, sorumluluğu görünür yapar, SLA durdurma kurallarını denetlenebilir hale getirir ve toplantıyı suçlama yerine engel kaldırma mekanizmasına dönüştürür.

Sorunun ortaya çıkışı

Donanım, abonelik ve dış hizmet talepleri aynı aktif kuyrukta tutuluyordu. Teknik çalışma tamamlandıktan sonra teklif, bütçe kodu, yönetici onayı veya teslimat bekleniyordu. Ancak owner hâlâ BT uzmanıydı ve sonraki adım kaydın notlarında kalıyordu. Bu yapı hem kapasite raporunu bozuyor hem de yaklaşan lisans yenilemelerinin zamanında eskale edilmesini zorlaştırıyordu.

İlk belirtiler ve yanlış varsayımlar

En belirgin işaret, yaşlı kayıtların büyük bölümünde son teknik aksiyon bulunmamasıydı. İlk öneri bunları kapatıp satınalma tamamlanınca yeni kayıt açmaktı; bu uçtan uca izi ve kullanıcı bağlamını koparır. Her beklemede SLA’yı otomatik durdurmak da doğru değildir. Kurumun söz verdiği hizmet hedefi ve iç performans ölçümü ayrı tutulmalı, durdurma yalnızca tanımlı nedenlerde uygulanmalıdır.

Teknik analiz

Bekleme nedenlerini teklif, bütçe, onay, sipariş ve teslimat olarak sınıflandırdık. Her geçişte bekleyen taraf, başlangıç tarihi, beklenen yanıt tarihi ve sonraki aksiyon zorunlu oldu. Toplam çevrim süresi korunurken BT çalışma süresi ve procurement aging ayrı hesaplandı. Tedarik tamamlandığında kaydın otomatik olarak doğru teknik gruba dönmesi, unutulmuş kayıt riskini azalttı. Yenileme işleri için geriye doğru planlama uygulandı.

Uygulanan çözüm veya önerilen mimari

ITSM akışına “Satınalma Bekliyor” üst durumu ve kontrollü alt nedenler eklendi. Owner rolü hizmet sorumluluğunu korurken current action owner alanı satınalma veya onay sahibini gösterdi. Eşik aşımında ilgili yöneticiye özet eskalasyon üretildi. Kullanıcıya teknik değerlendirmenin tamamlandığı, mevcut aşama ve tahmini sonraki güncelleme açıklandı. Haftalık dashboardda adet kadar toplam parasal tahmin ve kritik tarih de gösterildi.

Alternatifler ve karar gerekçesi

Satınalma sisteminde ayrı talep açmak mali kontrol için gereklidir, ancak ITSM kaydıyla bağlantı kurulmazsa iki gerçek oluşur. Tam entegrasyon yüksek hacimde değerlidir; düşük olgunlukta önce ortak referans numarası ve durum mutabakatı yeterli olabilir. E-posta ile takip hızlı başlar fakat ölçülemez. Biz aşamalı yaklaşımı seçtik: standart durum ve sahiplik, bağlantılı satınalma kaydı, ardından API entegrasyonu.

Güvenlik ve operasyonel riskler

Dashboardda teklif ayrıntısı, tedarikçi iletişimi ve bütçe bilgisi gereksiz geniş kitleye açılmamalıdır. Görev ayrılığı gereği talep eden, onaylayan ve satınalma yapan roller uygun eşiklerde ayrıldı. SLA durdurma yetkisinin performansı yapay iyileştirmek için kullanılmaması amacıyla değişiklikler loglandı ve örneklendi. Acil güvenlik lisansı gibi talepler için standart akışı atlayan değil, kayıtlı hızlandırılmış yol tanımlandı.

Çıkarılan Dersler

Kontrol Listesi