Satınalma yazılımı demolarında birçok ürün benzer görünebilir: talep ekranı, tedarikçi listesi, karşılaştırma tablosu. Seçimi belirleyen ayrıntı, sizin işinizdeki istisnalar ortaya çıktığında sistemin nasıl davrandığıdır. Bu nedenle değerlendirmeyi özellik sayısından çok, gerçek bir alım senaryosu üzerine kurmak daha yararlıdır.
İhtiyaçları üç gruba ayırın
İlk gruba bugün çalışması gereken zorunlu işleri yazın. İkinci gruba sonraki aşamada değer katacak özellikleri, üçüncü gruba ise yalnızca ilginç bulduğunuz seçenekleri koyun. Böylece güçlü bir görsel sunum, temel bir ihtiyacın eksikliğini perdelemez. Her zorunlu ihtiyacın karşısında onu kullanacak kişinin adı bulunsun.
Örneğin “onay sistemi” geniş bir tanımdır. Talep hangi kullanıcının birimine göre ilerleyecek, onaydan sonra kalemler nasıl ihaleye aktarılacak? Bu iki soru daha sınanabilir bir ihtiyaç üretir. Aynı şekilde “raporlama” yerine hangi verinin hangi biçimde dışa alınacağını tarif edin.
Demoya kendi senaryonuzla katılın
On kalemlik örnek bir dosya, üç tedarikçi ve birkaç ticari sorudan oluşan bir test hazırlayın. Kalemlerden birinde birim eksik, birinde alternatif ürün açıklaması olsun. Yazılımı sunan kişiden yalnızca başarılı akışı değil, bu eksiklerin nasıl fark edildiğini de göstermesini isteyin.
Tedarikçi tarafını ayrıca görün. Davet edilen firma teklifini nereden verir, soruları nasıl cevaplar, son teklifini nasıl kontrol eder? Satınalmacı için kolay olan bir ekran, tedarikçi için anlaşılır olmayabilir. Katılımın sürdürülebilmesi için iki tarafın deneyimi birlikte değerlendirilmelidir.
Entegrasyonun kapsamını yazılı netleştirin
“API var” cevabı tek başına yeterli değildir. Hangi kayıtlar okunabilir veya oluşturulabilir? Dokümantasyon nasıl paylaşılır? Bağlantıyı kim geliştirir ve hatalı aktarımı kim inceler? Kurum içindeki teknik ekibin bu görüşmeye erken katılması, sonradan ortaya çıkan beklenti farklarını azaltır.
OpenAPI gibi açıklama standartları API yeteneklerinin anlaşılmasına yardımcı olur. Bununla birlikte, belirli bir standardın desteği veya hazır entegrasyon modülü bulunması ayrıca doğrulanmalıdır. Satınalma platformunun ERP’deki bütün süreçleri devralacağını varsaymayın.
Toplam kullanım maliyetini değerlendirin
Lisansın yanında başlangıç çalışması, veri hazırlığı, eğitim, entegrasyon geliştirmesi ve kurum içi bakım emeğini değerlendirin. Kullanıcı veya işlem kapsamı büyüdüğünde ücretlendirmenin nasıl değiştiğini sorun. Ayrılma durumunda hangi verileri hangi biçimde alabileceğinizi de baştan öğrenin. Bu bir güvensizlik göstergesi değil, sağlıklı yazılım seçimidir.
OECD’nin KOBİ dijitalleşmesi araştırması beceri ve benimseme konularını da ele alır. Bu nedenle bütçeyi yalnızca teknolojiye ayırmayın; ekibin yeni işleyişi öğrenmesi için zaman planlayın. Projenin sorumlusu belirlenmeden alınan iyi bir yazılım bile beklenen şekilde kullanılmayabilir.
Kararı kanıtlarla verin
Değerlendirme tablonuzda her gereksinim için “gösterildi”, “ek geliştirme gerekiyor” veya “kapsam dışında” gibi açık durumlar kullanın. Puan verdiyseniz gerekçesini yazın. Bir ürünün gelecek planındaki özellik ile bugün kullanılan işlevi aynı sütunda değerlendirmeyin.
Tenflex’i incelerken talep aktarımı, ihale soruları, rekabet gösterimi, teklif seçimi ve API kapsamını kendi örneklerinizle deneyin. Son karardan önce bir alımın başından raporuna kadar ilerleyin. İyi bir seçim, sunum sonunda en çok özellik hatırladığınız ürün değil; işinizi hangi koşullarda yürüteceğini açıkça gördüğünüz çözümdür.
