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

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