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

Orta ölçekli bir işletmede satınalma dosyaları ortak klasör, e-posta ve kişisel takip tablolarına dağılmıştı. Talep formunun son sürümü, hangi teklifin onaylandığı ve sözleşmenin nerede olduğu ancak süreci bilen kişilerden öğrenilebiliyordu. M-Files gündeme geldiğinde ilk beklenti bütün belgeleri tek klasöre taşımaktı. Oysa eski klasör mantığını yeni araca kopyalamak, dağınıklığı yalnızca daha modern bir ekrana taşır.

DMS projesinde odak dosyanın konumu değil, belgenin ne olduğu ve hangi iş kararına bağlı olduğudur. Talep, teklif, değerlendirme, sipariş ve sözleşme ayrı nesneler olsa da ortak süreç kimliğiyle ilişkilendirilmelidir. Teknoloji ancak karar hakları, veri sahipliği ve ERP sınırı tanımlandığında fayda üretir. Bu nedenle kuruluma ekranlardan değil, gerçek satınalma akışından başladık.

Sorunun ortaya çıkışı

Farklı birimler kendi talep şablonlarını kullanıyor, teklifler e-postada kalıyor ve onaylar bazen yalnızca mesajla veriliyordu. Dosya adındaki “son”, “final” ve tarih ekleri versiyon kontrolü sanılıyordu. Denetimde bir satınalma kararının talep, karşılaştırma ve yetkili onay zincirini göstermek zaman alıyordu. Aynı tedarikçiye ait belgeler farklı klasörlerde tekrar tutuluyor, saklama süreleri uygulanamıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk varsayım taranmış PDF yüklemenin dijitalleşme olduğuydu. Aranabilirlik artsa da zorunlu metadata ve süreç durumu olmadan kontrol gelişmez. Diğer varsayım bütün alanları ilk günden zorunlu yapmaktı; bu kullanıcıyı sistem dışı kanallara iter. ERP’nin ya tamamen devre dışı kalacağı ya da her şeyi yöneteceği düşüncesi de yanlıştı. İşlem sistemi ile belge ve onay sistemi arasında açık sınır gerekiyordu.

Teknik analiz

Talep numarası, şirket, lokasyon, maliyet merkezi, kategori, tutar aralığı, süreç sahibi ve saklama sınıfını temel metadata olarak belirledik. Nesne ilişkileri sayesinde teklifleri talebe, siparişi onay kararına bağladık. Yetki modeli belge türünden çok süreç rolü ve organizasyon bağlamına dayandı. ERP’de oluşan tedarikçi ve sipariş anahtarlarının DMS’ye nasıl aktarılacağı, hata ve yinelenen kayıt senaryolarıyla birlikte analiz edildi.

Uygulanan çözüm veya önerilen mimari

Önce tek bir satınalma kategorisinde pilot workflow kurduk: taslak, birim onayı, bütçe kontrolü, satınalma değerlendirmesi, karar ve arşiv. Her durumda düzenleme ve görüntüleme hakları ayrı tanımlandı. M-Files versiyon geçmişini resmi kayıt olarak tuttu; onay yorumu ve zaman damgası korundu. ERP entegrasyonunda yalnızca gerekli ana veriler ve onaylanmış sonuç taşındı. Kullanıcılara ekran eğitimi yerine örnek iş senaryoları verildi.

Alternatifler ve karar gerekçesi

ERP’nin yerleşik satınalma modülü işlem bütünlüğünde güçlü olabilir; DMS ise belge yoğun süreç, arama ve kayıt yönetiminde avantaj sağlar. SharePoint veya başka içerik platformları da doğru bilgi mimarisiyle aynı ihtiyacın bir bölümünü karşılayabilir. Ürün seçimini mevcut lisans, entegrasyon yetkinliği ve kayıt yönetimi ihtiyacına göre yaptık. M-Files’ı ERP yerine değil, kontrollü belge ve karar katmanı olarak konumlandırdık.

Güvenlik ve operasyonel riskler

Teklifler, sözleşmeler ve ticari koşullar geniş erişime açılmamalıdır. Kalıtımlı yetkiler, dış paylaşım, indirme ve çevrimdışı kopya senaryoları test edildi. Entegrasyon hesabına yalnızca gerekli nesne ve işlemler için yetki verildi; kişisel hesap kullanılmadı. Workflow arızasında satınalmanın durmaması için kontrollü manuel prosedür ve sonradan sisteme işleme kuralı tanımlandı. Saklama ve silme hukuki gereksinimlerle uyumlu tutuldu.

Çı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