Özel Yazılım Teklifi Nasıl Karşılaştırılır? Adana Yazılım Şirketleri Seçim Rehberi

Önce Teklifleri Aynı Kapsama Getirin

Teklif karşılaştırmasının ilk adımı, tüm firmalara aynı ihtiyaç dokümanını göndermektir. Kullanıcı rolleri, ana ekranlar, iş kuralları, entegrasyonlar, veri taşıma, raporlar ve başarı ölçütleri yazılı değilse her ekip farklı bir ürün varsayar.

• Projenin çözmesi gereken iş problemi ve hedef kullanıcılar.
• Yönetici, çalışan, müşteri, bayi veya tedarikçi rolleri.
• Zorunlu modüller ile sonraki faza bırakılabilecek özellikler.
• Mevcut veri kaynakları, API’ler ve dış sistemler.
• Web, mobil, masaüstü veya cihaz gereksinimleri.
• Raporlama, yetki, kayıt ve denetim ihtiyaçları.

Bu doküman teklif talebinin eki olmalı ve her firmanın hariç tuttuğu işleri açıkça işaretlemesi istenmelidir.

Özel Yazılım Teklifi Karşılaştırma Matrisi

Fonksiyonel ve Fonksiyonel Olmayan Gereksinimleri Ayırın

Fonksiyonel gereksinim sistemin ne yapacağını söyler: teklif oluşturma, stok sorgulama, randevu planlama veya rapor indirme gibi. Fonksiyonel olmayan gereksinim ise nasıl çalışması gerektiğini tanımlar: hız, erişilebilirlik, güvenlik, günlük kullanıcı sayısı, yedekleme, tarayıcı ve cihaz desteği gibi.

İki teklif aynı ekranları sunsa bile biri yüksek işlem hacmini, rol bazlı yetkiyi ve denetim kaydını hesaba katmış; diğeri almamış olabilir. Özellikle CRM ve ERP yazılımı gibi iş kritik sistemlerde bu fark proje başladıktan sonra pahalı değişikliklere dönüşür.

Kaynak Kodu, Veri, Domain ve Hesap Sahipliği

Teklifte yalnız yazılımın kullanım hakkı değil; kaynak koduna erişim, veritabanı dışa aktarımı, bulut hesabı, domain, e-posta, uygulama mağazası, analitik ve üçüncü taraf servis hesaplarının kimin adına açılacağı yazılmalıdır. İşletmenin kendi hesapları üzerinde ajansa yetki vermesi, sağlayıcı değişiminde devamlılığı kolaylaştırır.

• Git deposu ve kaynak kodu erişim düzeyi.
• Veritabanı yedeğinin okunabilir formatta teslimi.
• Domain, DNS, sunucu ve bulut hesabı sahipliği.
• Apple, Google, ödeme, SMS, e-posta ve harita servis hesapları.
• Tasarım kaynakları, dokümantasyon ve dağıtım anahtarları.
• Hizmet bittiğinde erişim devri ve güvenli kapatma adımları.

Sözleşme kontrolü: Fikrî haklar ve lisans koşulları proje türüne göre değişir. Teslim ve kullanım haklarını hukuk danışmanınızla açıklaştırın.

API, Entegrasyon ve Veri Taşıma Kapsamı

Muhasebe, ödeme, kargo, ERP, CRM, e-posta, SMS, harita veya üretim sistemi entegrasyonu teklif içinde yalnız isim olarak geçmemelidir. Hangi API uçlarının kullanılacağı, erişimi kimin sağlayacağı, test ortamı, kota, hata yönetimi ve üçüncü taraf ücretleri belirtilmelidir.

Eski sistemden veri taşınacaksa kaynak format, temizleme, eşleştirme, deneme aktarımı ve nihai geçiş planlanır. ‘Veriler taşınacak’ cümlesi; kaç tablo, kaç kayıt, hangi alan, hangi tarih ve hangi doğrulama yöntemi sorularını cevaplamaz.

Güvenlik ve Test Maddeleri Nasıl Değerlendirilir?

Güvenlik son hafta eklenen bir eklenti değildir. Kimlik doğrulama, yetkilendirme, parola politikası, veri şifreleme, kayıt yönetimi, yedekleme, bağımlılık güncellemeleri ve güvenli geliştirme gereksinimleri proje başında tanımlanmalıdır. OWASP ASVS, web uygulaması güvenlik kontrolleri için ölçülebilir bir gereksinim kaynağı sunar.

Kabul Kriterleri ve Tamamlandı Tanımı

Bir özelliğin ‘tamamlandı’ sayılması için yalnız ekranın açılması yetmez. Yetki kontrolleri, hata mesajları, mobil davranış, test, dokümantasyon ve kabul senaryosu da tamamlanmalıdır. Her kilometre taşı için müşteri tarafından doğrulanabilir kabul kriteri bulunmalıdır.

Örneğin ‘teklif PDF’i oluşturulur’ maddesi; doğru müşteri bilgisi, kalem hesapları, para birimi, yetkili kullanıcı, arşivleme, e-posta gönderimi ve hata durumunu kapsayabilir. Bu ayrıntılar teklif öncesinde konuşulursa değişiklik tartışmaları azalır.

Takvim, Kilometre Taşı ve Değişiklik Yönetimi

Sağlıklı takvim analiz, tasarım, geliştirme, entegrasyon, test, eğitim ve canlıya geçiş fazlarını gösterir. Müşteri onayı, içerik teslimi ve üçüncü taraf erişimi gibi bağımlılıklar da yazılır. Belirsiz kapsam için tek tarih vermek yerine faz bazlı plan kullanılır.

Proje sırasında yeni istek çıkması normaldir. Değişiklik talebinin kapsam, süre, maliyet ve diğer maddelere etkisi yazılı değerlendirilmelidir. Küçük görünen bir alanın veri modeli, rapor ve entegrasyonu etkileyebileceği unutulmamalıdır.

Garanti, Bakım ve Destek Aynı Şey Değildir

Hata düzeltme garantisi, yazılım bakımı, yeni geliştirme ve kullanıcı desteği ayrı başlıklardır. Teklif; hangi hataların hangi dönemde düzeltileceğini, altyapı ve bağımlılık güncellemelerini, destek saatlerini, yanıt hedeflerini ve kapsam dışı işleri açıklamalıdır.

‘Sınırsız destek’ yerine talep kanalı, öncelik sınıfı, yanıt ve müdahale hedefi, aylık kapsam ve değişiklik ücretlendirme yöntemi ölçülebilir biçimde yazılmalıdır.

Yalnız İlk Fiyata Değil Toplam Sahip Olma Maliyetine Bakın

İlk geliştirme bedeline ek olarak barındırma, alan adı, e-posta/SMS, ödeme sağlayıcısı, harita veya yapay zekâ API’si, lisanslar, bakım, yedekleme, izleme ve yeni sürümler maliyet oluşturabilir. Teklifler bu kalemlerle üç yıllık bakışta karşılaştırılabilir.

• Bir defalık analiz, tasarım, geliştirme ve veri taşıma bedelleri.
• Aylık/yıllık altyapı, lisans ve üçüncü taraf kullanım bedelleri.
• Bakım, destek ve güvenlik güncelleme maliyeti.
• Yeni özellik veya kapsam değişikliği fiyatlandırma yöntemi.
• Çıkış, veri dışa aktarma ve sağlayıcı değişimi maliyeti.

Yazılım Şirketi Seçiminde Kırmızı Bayraklar

• İhtiyaç analizi yapmadan kesin süre ve kesin fiyat verilmesi.
• Kaynak kodu, veri ve hesap sahipliğinin konuşulmaması.
• Güvenliğin yalnız SSL sertifikasıyla açıklanması.
• Test ve kabul sürecinin teklifte bulunmaması.
• Üçüncü taraf lisansların ve kullanım ücretlerinin gizli kalması.
• Referansların doğrulanamaması veya her sektöre aynı demo gösterilmesi.
• Dokümantasyon, eğitim ve canlıya geçiş planının olmaması.
• Sınırsız, süresiz veya garantili sonuç gibi ölçülemez vaatler.

Temsili Senaryo: Ucuz Teklif Neden Pahalıya Dönebilir?

Bir üretici bayi sipariş sistemi için iki teklif alsın. İlk teklif yalnız ürün ve sipariş ekranlarını, ikinci teklif ise ERP entegrasyonu, rol bazlı yetki, test ortamı, veri taşıma, kullanıcı eğitimi ve bakım planını içeriyor olsun. İlk fiyat düşük görünse de eksik kalemler sonradan ayrı iş olarak eklendiğinde toplam maliyet ve gecikme artabilir.

Bu senaryo gerçek müşteri sonucu değildir. Amaç fiyatı değil, kapsam eşitliğini karşılaştırmanın neden önemli olduğunu göstermektir.

100 Puanlık Teklif Değerlendirme Örneği

Daha geniş kurumsal ihtiyaçlar için kurumsal çözümler ve entegrasyon kapsamı birlikte planlanabilir.

Kaynaklar ve Yöntem

Standartlar her projede aynı kontrol seviyesinin zorunlu olduğu anlamına gelmez. Risk, veri türü ve iş kritikliği doğrultusunda hangi maddelerin kapsama alınacağı teklif aşamasında belirlenmelidir.

• OWASP Application Security Verification Standard
• OWASP DevSecOps Verification Standard
• NIST Secure Software Development Framework

Sıkça Sorulan Sorular