TR / EN

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

Ç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

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