Yazılım teklifi nasıl değerlendirilir? Satır satır okuma rehberi

Bir yazılım teklifini değerlendirirken önce fiyata değil, fiyatın neyi kapsadığına bakın: kapsam, kabul kriterleri, ödeme adımları, kaynak kod sahipliği ve yayından sonraki destek yazılı değilse, iki teklifin rakamını karşılaştırmak anlamsızdır. Yazılım teklifi nasıl değerlendirilir sorusunun kısa cevabı şu: teklifi bir fiyat belgesi gibi değil, iki tarafın ne teslim edeceğini ve neyi kabul edeceğini anlatan bir iş tanımı gibi okuyun.

Masanızda üç teklif olduğunu düşünün. Biri iki sayfa, biri on beş sayfa, biri tek satırlık bir e-posta. Rakamlar birbirinden çok farklı; ama çoğu zaman aradaki fark fiyattan değil, her firmanın kafasındaki projenin farklı olmasından gelir. Bu yazı, o farkı görünür kılmak için teklifte hangi başlıklara bakmanız gerektiğini anlatıyor.

Henüz özel yazılım mı yoksa hazır bir program mı gerektiğine karar vermediyseniz, önce özel yazılım mı hazır yazılım mı karşılaştırmasına göz atmanızı öneririz. Bu yazı, özel geliştirme kararını vermiş ve teklif toplayan işletmeler için.

Yazılım teklifi nasıl değerlendirilir: önce kapsam

Kapsam, teklifin geri kalan her şeyinin dayandığı zemindir. "Stok takip modülü" yazan bir teklifle "depo bazında stok kartı, seri/lot takibi, sayım farkı düzeltme ve kritik stok uyarısı" yazan bir teklif aynı şeyi anlatmıyor olabilir.

İyi bir kapsam bölümünde şunları görmeyi bekleyin:

• Neyin dahil olduğu: ekranlar, raporlar, kullanıcı rolleri, entegrasyonlar (muhasebe programı, e-Fatura entegratörü, kargo firması gibi).
• Neyin dahil olmadığı: "Mobil uygulama bu teklifin kapsamında değildir" gibi açık cümleler. Kapsam dışı listesi, kapsam listesi kadar değerlidir.
• Varsayımlar: "Mevcut verilerin Excel'de ve tek formatta teslim edileceği varsayılmıştır" gibi. Varsayım tutmazsa ne olacağı da yazmalı.
• Veri taşıma: eski sistemden ya da tablolardan veri aktarımı kapsamda mı, temizliği kim yapacak?

Teklif çok genel yazılmışsa bu, firmanın kötü niyetli olduğu anlamına gelmez; çoğu zaman ihtiyacı henüz yeterince dinlemediğini gösterir. Bu durumda bir analiz görüşmesi isteyin ve teklifi o görüşmeden sonra yenilemelerini bekleyin.

Kabul kriterleri: "bitti" ne demek?

Projelerde en çok tartışma çıkan an, teslimde yaşanır. Firma "istediğiniz ekran hazır" der, siz "ama böyle çalışmıyordu bizim işimiz" dersiniz. Kabul kriterleri bu anlaşmazlığı önceden çözer.

Kabul kriteri, bir özelliğin tamamlanmış sayılması için neyin çalışması gerektiğini somut olarak tarif eder. Örneğin: "Bayi portaldan sipariş verdiğinde sipariş, kimse elle girmeden ERP'de açık sipariş olarak görünür ve bayinin cari hesabına yansır." Bu cümle test edilebilir; "sipariş modülü yapılacaktır" edilemez.

Teklifte kabul kriteri yoksa, en azından kabul sürecinin nasıl işleyeceğini sorun: test ortamında kim deneyecek, kaç gün içinde geri bildirim verilecek, bulunan hatalar nasıl sınıflandırılacak?

Ödeme adımları teslimata bağlı mı?

Ödeme planı, riskin kimde kaldığını gösterir. Sağlıklı bir planda ödemeler takvim tarihlerine değil, teslim edilen ve kabul edilen işe bağlanır.

Ödeme yapısı	Ne anlama gelir
Aşama sonunda ödeme (her aşama kabul edildiğinde)	Risk iki tarafa dengeli dağılır; ilerlemeyi somut olarak görürsünüz
Makul bir başlangıç ödemesi + aşamalar	Yaygın ve anlaşılır bir model; başlangıç ödemesinin neyi karşıladığını sorun
Tamamı peşin	Risk tamamen sizde kalır; proje yarıda kalırsa elinizde pazarlık payı olmaz
Aylık sabit ücret, teslim tanımı yok	Uzun işlerde olabilir, ama her ay ne teslim edileceği yazılı olmalı

Aşamalar teklifte adlandırılmış olmalı: "1. aşama: stok ve cari modülü, test ortamında kullanıma hazır" gibi. Her aşamanın sonunda size çalışan bir şey gösterilmesi, projenin gerçekte nerede olduğunu anlamanın en güvenilir yoludur.

Kaynak kod ve veri kimin?

Bu başlık teklifte çoğu zaman hiç geçmez, ama yıllar sonra en çok önem kazanan başlıktır. Firmayla yollarınız ayrılırsa, sistemi başka bir ekibe devredebilmeniz gerekir.

Sorulacak sorular:

• Kaynak kod size teslim edilecek mi, yoksa yalnızca kullanım hakkı mı veriliyor?
• Kod hangi depoda tutuluyor ve size erişim verilecek mi?
• Firmanın başka projelerde de kullandığı hazır bileşenler var mı? Bunların lisans koşulları ne?
• Verileriniz istediğiniz an, okunabilir bir formatta dışa aktarılabilir mi?

Yazılımın fikri haklarının kime ait olduğu, sözleşmede açıkça yazılmadıkça sizin varsaydığınız gibi olmayabilir. Bu maddeyi sözleşme aşamasında bir hukukçuyla birlikte okumanızı öneririz. Kişisel veri işlenen sistemlerde KVKK kapsamındaki sorumlulukların nasıl paylaşıldığı da sözleşmede yer almalı; güncel mevzuatı kontrol edin.

Sunucu ve altyapı kimin sorumluluğunda?

Sistem nerede çalışacak: sizin sunucunuzda mı, firmanın yönettiği bir bulutta mı, yoksa sizin adınıza açılmış bir bulut hesabında mı? Her biri farklı sorumluluk demek.

Teklifte şu soruların cevabı olmalı: sunucu maliyetini kim ödüyor, yedekleme kimde ve ne sıklıkla alınıyor, sistem çökerse kim müdahale ediyor, alan adı ve SSL sertifikası kimin adına kayıtlı? Altyapı hesabının sizin adınıza açılması, ileride firma değiştirdiğinizde işleri çok kolaylaştırır.

Bakım, destek ve müdahale süreleri

Yazılım yayına alındığında iş bitmez; asıl kullanım o zaman başlar. İlk haftalarda küçük hatalar, eksik raporlar ve kullanıcı soruları gelir. Teklif, bu dönemi nasıl karşıladığını yazmalı.

Bakım ve destek bölümünde şunlara bakın:

• Yayından sonra ücretsiz hata düzeltme süresi var mı, ne kadar?
• Sonrasında bakım ücretli mi, neyi kapsıyor (hata düzeltme, güncelleme, güvenlik yamaları)?
• Destek hangi saatlerde veriliyor ve hangi kanaldan (e-posta, telefon, talep sistemi)?
• Kritik bir hata için ilk müdahale süresi ne? "Sistem açılmıyor" ile "raporda yazım hatası var" aynı sürede ele alınmamalı.

Destek kısmı belirsizse, projeyi geliştiren ekibin yayından sonra da işin başında olup olmayacağını doğrudan sorun.

Değişiklik talebi süreci

Proje ilerledikçe fikirleriniz netleşir ve yeni istekler çıkar. Bu doğaldır. Sorun, bu isteklerin nasıl ele alınacağının belli olmamasıdır.

Teklif ya da sözleşmede bir değişiklik talebi süreci olmalı: yeni istek yazılı olarak iletilir, firma etkisini (süre ve maliyet) yazılı olarak bildirir, siz onaylamadan iş yapılmaz. Bu süreç hem sizi sürpriz faturalardan hem de firmayı bitmeyen bir kapsamdan korur.

Ekipte kim var, muhatabınız kim?

Teklifi hazırlayan kişiyle projeyi geliştirecek kişiler aynı olmayabilir. İşin bir kısmının başka bir firmaya ya da serbest çalışana devredilip devredilmeyeceğini sorun.

Projede tek bir muhatabınız olması, soruların kaybolmasını önler. Kimin analizi yapacağını, kimin geliştireceğini ve sorunlarınızı kime ileteceğinizi teklif aşamasında öğrenin.

Yayından sonraki maliyetler

İlk fiyat, toplam maliyetin yalnızca bir parçasıdır. Teklifi okurken yayından sonraki yılları da hesaba katın:

• Sunucu ve bulut hizmeti ücretleri
• Bakım ve destek ücreti
• Üçüncü taraf lisanslar ve servisler (harita, SMS, e-Fatura entegratörü gibi)
• Yeni kullanıcı ya da yeni modül eklendiğinde fiyatlandırma

Bu kalemler teklifte yoksa ayrıca yazılı olarak isteyin. Yazılım firması seçimi yaparken ilk yılın değil, birkaç yılın toplamını karşılaştırmak daha adil bir tablo verir.

Kırmızı bayraklar

Aşağıdakilerden biri tek başına teklifi reddetmek için yeterli olmayabilir; ama birkaçı birlikte görülüyorsa dikkatli olun:

• Kapsamı olmayan fiyat. Tek satırda "ERP sistemi: X TL" yazıyorsa, neyin satın alındığı belli değildir.
• Tamamı peşin ödeme. Teslimata bağlı hiçbir aşama yoksa pazarlık gücünüz ilk günden biter.
• "Her şey dahil". Neyin dahil olduğu sayılmıyorsa, neyin dahil olmadığı teslimde ortaya çıkar.
• Demo ya da ara teslim takvimi yok. İlk kez çalışan bir şeyi projenin sonunda görecekseniz, yön değiştirmek için çok geç kalmış olursunuz.
• Kaynak kod ve veri konusunda sessizlik. Bu başlık sorulduğunda net cevap alamıyorsanız, cevap büyük ihtimalle sizin lehinize değildir.
• İhtiyacınız dinlenmeden verilen teklif. İlk görüşmede soru sormayan firma, sizin işinizi değil kendi hazır çözümünü teklif ediyor olabilir.

Teklifte sorulacak sorular: kontrol listesi

Aşağıdaki tabloyu masanızdaki her teklif için ayrı ayrı doldurabilirsiniz. Cevabı teklifte yazmayan soruları firmaya yazılı olarak iletin.

Teklifte sorulacak soru	Neden önemli
Kapsamda ve kapsam dışında neler var?	İki teklifi ancak aynı işi anlatıyorlarsa karşılaştırabilirsiniz
Her özellik için kabul kriteri yazılı mı?	Teslimde "bitti mi, bitmedi mi" tartışmasını önler
Ödemeler hangi teslimlere bağlı?	Riskin kimde kaldığını gösterir
Kaynak kod ve veriler kime ait, nasıl teslim edilecek?	Firma değiştirmeniz gerekirse sistemi kaybetmezsiniz
Sunucu, yedekleme ve alan adı kimin sorumluluğunda?	Kesinti ya da ayrılık anında kimin ne yapacağı bellidir
Destek saatleri ve kritik hata müdahale süresi ne?	Yayından sonraki ilk haftalar en yoğun dönemdir
Değişiklik talepleri nasıl fiyatlanıp onaylanıyor?	Sürpriz fatura ve bitmeyen kapsamı önler
Projede kimler çalışacak, tek muhatabım kim?	Soruların ve kararların kaybolmasını önler
Ara teslim ve demo takvimi var mı?	Projenin gerçekte nerede olduğunu görmenizi sağlar
Yayından sonraki yıllık maliyetler neler?	İlk fiyatın ötesindeki toplam maliyeti gösterir

Nereden başlamalı?

Teklif toplamadan önce kendi tarafınızda kısa bir hazırlık yapmak, gelen teklifleri de netleştirir. Bugün hangi işi Excel'de, WhatsApp'ta ya da elle yürüttüğünüzü, sistemin hangi programlarla konuşması gerektiğini ve ilk aşamada neyin mutlaka çalışması gerektiğini bir sayfaya yazın. Stok ve sipariş takibini tablolardan kurtarmayı düşünüyorsanız Excel'den ERP'ye geçiş yazısı bu hazırlıkta işinize yarayabilir.

Bu sayfayı her firmaya aynı şekilde verin. Böylece gelen teklifler aynı soruya cevap verir ve karşılaştırma gerçekten anlamlı olur. Özel ERP yazılımı ya da CRM yazılımı için teklif alıyorsanız, bizim nasıl çalıştığımızı da aynı soru listesiyle sorgulayabilirsiniz.

Elinizdeki teklifi bu soru listesiyle birlikte okumak isterseniz, sizinle aynı masaya oturmaktan memnuniyet duyarız.