E-satınalmaya geçişin ilk sorusu “Hangi yazılımı alalım?” olmak zorunda değil. Önce hangi işin düzelmesini istediğinizi tarif edin. Teklifler farklı dosyalarda mı kalıyor, talep kalemleri tekrar mı yazılıyor, yoksa onaylanan siparişin son hali bulunamıyor mu? İlk proje bu sorunlardan birini görünür biçimde çözebiliyorsa, sonraki adımlar için sağlam bir temel oluşur.
1. Bir alımı baştan sona izleyin
Yakın zamanda tamamlanmış bir alımı seçin. Talebin gelişini, teknik bilgilerin tamamlanmasını, davetleri, teklifleri ve sipariş kararını sırayla yazın. Her adımın yanına kullanılan dosyayı ve sorumlu kişiyi ekleyin. Aynı bilgi birden çok yerde tutuluyorsa hangisinin güncel kabul edildiğini sorun.
CIPS’in satınalma döngüsü, ihtiyacın tanımlanmasından sonraki aşamalara kadar ortak bir çerçeve sunar. Kendi akışınızı incelerken bu çerçeveyi bir kontrol listesi olarak kullanabilirsiniz; her adımın aynı yazılımda yürütülmesi gerektiği anlamına gelmez.
2. Pilotun başarı koşulunu yazın
“Daha dijital olmak” ölçülebilir bir hedef değildir. “Onaylı talep kalemlerini yeniden yazmadan teklif sürecine taşımak” çok daha açık bir hedeftir. Buna bir kullanıcı grubu, bir kategori ve gözden geçirme tarihi ekleyin. Pilot sonunda hangi kayıtların inceleneceği baştan belli olsun.
Başarıyı yalnızca fiyatla sınırlandırmayın. Kaç kullanılabilir teklif geldiği, davetten sonra kaç açıklama gerektiği ve karşılaştırma raporunun ne kadar sürede hazırlandığı da değerlidir. Bu ölçümleri önceki benzer alımla karşılaştırın; çok farklı bir kategoriyi referans almak yanıltabilir.
3. Veriyi ve sorumluları hazırlayın
Kalem açıklamalarını, ölçü birimlerini ve tedarikçi iletişimlerini kontrol edin. Tedarikçi listesinin büyüklüğünden önce güncelliğine bakın. Kayıt onayını kimin vereceğini, daveti kimin göndereceğini ve yanlış bilgi geldiğinde kimin düzelteceğini belirleyin. Bu küçük kararlar, canlı kullanım sırasında uzun e-posta zincirlerini önler.
Entegrasyonu ilk gün zorunlu hale getirmek gerekmeyebilir. Önce güvenilir bir dosya akışıyla süreci doğrulayın. API bağlantısı gerekiyorsa kapsamı, geliştirmeyi yapacak ekibi ve test verisini ayrı bir iş paketi olarak ele alın. Erişim yetkilerini de kullanıcıların gerçek görevleriyle sınırlandırın.
4. Alıcı ve tedarikçi tarafını birlikte deneyin
Test yalnızca satınalmacının ihale açmasıyla tamamlanmaz. Bir tedarikçinin daveti görmesi, şartları anlaması ve teklifini iletmesi de denenmelidir. Eksik cevap, yanlış birim ve kapanışa yakın teklif gibi durumları test senaryosuna ekleyin. Eğitimde bu örneklerden yararlanın; kullanıcılar kendi karşılaşacakları sorunları daha kolay hatırlar.
5. İlk alımdan sonra genişletin
Pilot bittiğinde sorunları “eğitim”, “veri” ve “süreç” olarak ayırın. Her aksiyona bir sorumlu ve tarih verin. Aynı sorunlar çözülmeden kullanıcı sayısını artırmak destek yükünü büyütebilir. İkinci kategoriye geçerken ilk pilotun kontrol listesini güncelleyerek kullanın.
Tenflex’te Excel ile kalem ekleme, kullanıcı birimine göre talep onayı ve talepten ihaleye aktarım üzerinden sınırlı bir başlangıç yapılabilir. Teklif toplama ve yeni tur gibi adımlar da ihtiyacınıza göre eklenebilir. Yazılımı değerlendireceğiniz demoya kendi örnek kalem listenizle gelmek, genel bir sunumdan daha anlamlı sorular sormanızı sağlar. Böylece satın aldığınız şeyin özellik sayısı değil, günlük işinize uygunluğu üzerinden karar verirsiniz.
