Yazılım tekliflerini doğru karşılaştırmak

Bir yazılım projesi için birkaç firmadan teklif aldığınızda genellikle elinizde birbirine hiç benzemeyen belgeler olur. Biri tek sayfalık bir fiyat yazısıdır, biri onlarca sayfalık bir teknik doküman, bir diğeri ise ürün broşürüne eklenmiş bir ödeme planı. Bu belgeleri yan yana koyup karşılaştırmak, farklı dillerde yazılmış üç sözleşmeyi karşılaştırmaya benzer.

Sonuçta karar çoğu zaman en anlaşılır rakama, yani fiyata göre verilir. Oysa yazılım projelerinde asıl farklar fiyatta değil, teklifin neyi kapsayıp neyi kapsamadığında saklıdır. Bu yazıda teklifleri gerçekten karşılaştırılabilir hâle getirmenin ve okurken nelere bakmanın yollarını anlatıyoruz.

Karşılaştırma tekliften önce başlar

Teklifler birbirine benzemiyorsa, bunun en sık nedeni firmalara aynı şeyin sorulmamasıdır. Bir firmaya telefonda kısaca anlatılan ihtiyaç, diğerine toplantıda farklı ayrıntılarla anlatılır; her firma da boşlukları kendi tecrübesiyle ya da kendi ürününe göre doldurur. Sonunda aynı projeye değil, üç farklı projeye teklif alırsınız.

Çözüm, teklif istemeden önce kısa bir ihtiyaç belgesi hazırlamaktır. Bu belge teknik bir şartname olmak zorunda değildir; işinizin diliyle yazılması yeterlidir. İçinde şunlar bulunmalıdır:

• Çözülmesi istenen iş sorunu ve bugün nasıl yürüdüğü,
• Sistemi kimlerin, hangi işler için kullanacağı,
• Bağlanması gereken mevcut sistemler (muhasebe, e-ticaret, kargo vb.),
• Olmazsa olmaz özellikler ile “olsa iyi olur” denenler ayrı ayrı,
• Taşınması gereken eski veriler,
• Yayına alma için bilinen bir takvim kısıtı varsa o.

Aynı belge bütün firmalara gönderilir ve sorular geldiğinde verilen cevaplar herkesle paylaşılır. Böylece teklifler ortak bir zemine oturur.

Belgede neyi yazmamalı?

İhtiyaç belgesinin amacı sorunu anlatmaktır, çözümü dikte etmek değil. “Şu programlama dili kullanılsın”, “ekranlar şöyle görünsün” gibi ayrıntılar, gerçek bir kısıt değilse belgeye yazılmamalıdır. Firmalara çözüm önerme alanı bırakmak, onların tecrübesinden yararlanmanızı sağlar; tekliflerdeki farklı yaklaşımlar da karşılaştırmanın önemli bir parçasıdır. Belgede ayrıca bütçe aralığınızı paylaşıp paylaşmayacağınıza karar verin: Paylaşmak, firmaların kapsamı gerçekçi kurmasına yardım eder; paylaşmamak ise çok farklı ölçeklerde öneriler görmenize yol açabilir.

Kapsamı kalem kalem okumak

Teklifin en önemli bölümü, neyin yapılacağını anlatan kısımdır. “Stok yönetimi modülü” gibi genel bir başlık, iki firmada çok farklı şeyler anlamına gelebilir. Birinde yalnız stok miktarının görüntülenmesidir, diğerinde depo içi konumlar, sayım ve transferlerin tamamıdır.

Bu yüzden ihtiyaç belgesindeki her maddenin teklifte nasıl karşılandığını tek tek eşleştirin. Karşılığı bulunmayan maddeleri ayrı bir listeye yazın ve firmaya sorun. Belirsiz kalan her ifade, proje başladıktan sonra “bu kapsamda yoktu” tartışmasına dönüşebilir.

Kapsam dışı bırakılanlar asıl farkı gösterir

İyi hazırlanmış bir teklif, neyi yapmayacağını da açıkça yazar. Kapsam dışı bölümü olmayan ya da bu bölümü çok kısa tutan teklifler, ilk bakışta daha kapsamlı görünür; ama belirsizlik genellikle ek faturaya dönüşür. Sık rastlanan kapsam dışı kalemler şunlardır:

• Eski sistemden veri taşıma ve verinin temizlenmesi,
• Diğer sistemlerle entegrasyonlar,
• Sunucu, barındırma ve lisans giderleri,
• Kullanıcı eğitimi ve kullanım belgeleri,
• Yayın sonrası değişiklik talepleri,
• Mobil uyum ya da ek dil desteği.

Bu kalemlerin her birinin hangi teklifte dahil, hangisinde hariç olduğunu yan yana yazmak, fiyat farklarının nereden geldiğini çoğu zaman tek başına açıklar.

Karşılaştırma tablosu kurmak

Teklifleri tek bir tabloda toplamak, kararı kişisel izlenimden çıkarır. Satırlar karşılaştırma ölçütleri, sütunlar firmalardır. Örnek bir iskelet:

Tablo doldurulurken boş kalan hücreler de bilgi verir: Bir firma belirli bir konuda bilgi vermiyorsa, o konuyu sormak gerekir.

Teslim aşamaları ve ödeme düzeni

Projenin tek bir büyük teslimle mi, yoksa her biri kendi başına denenebilen aşamalarla mı ilerleyeceği önemli bir farktır. Aşamalı teslimde her adımın sonunda çalışan bir şey görürsünüz; yanlış anlaşılan bir ihtiyaç erken fark edilir. Tek büyük teslimde ise sorunlar çoğu zaman en sonda ortaya çıkar.

Ödemelerin bu aşamalara bağlı olması iki taraf için de sağlıklıdır. Her aşamanın sonunda neyin teslim edileceği ve nasıl kabul edileceği teklifte yazmalıdır. “Proje tamamlandığında” gibi ucu açık ifadeler yerine gözlemlenebilir teslimler aranmalıdır.

Değişiklik talepleri nasıl yönetilecek?

Hiçbir yazılım projesi ilk gün yazıldığı gibi bitmez. Ekip sistemi kullanmaya başladıkça yeni ihtiyaçlar doğar; bu doğaldır. Önemli olan, bu taleplerin nasıl değerlendirileceğinin baştan belli olmasıdır. Teklifte değişiklik taleplerinin nasıl yazılı hâle getirileceği, nasıl fiyatlanacağı ve takvime etkisinin nasıl bildirileceği anlatılmalıdır. Bu bölümü olmayan teklifler, proje boyunca her küçük değişikliğin pazarlık konusu olmasına yol açabilir.

Tersi de bir risktir: Değişikliklerin sınırsız kabul edildiği izlenimini veren teklifler, proje uzadıkça ya kaliteden ya da takvimden ödün verilmesine neden olabilir. Sağlıklı olan, küçük düzeltmelerle kapsamı değiştiren yeni ihtiyaçların ayrı ele alındığı, her talebin etkisinin önce yazılı olarak paylaşıldığı ve sizin onayınızla uygulandığı bir düzendir.

Bakım, destek ve sürekliliği sormak

Yazılımın asıl ömrü yayına alındıktan sonra başlar. Bu dönemde hata düzeltmelerinin nasıl yapılacağı, güvenlik güncellemeleri, kullandığı altyapının güncel tutulması ve yeni talepler gündeme gelir. Tekliflerde destek talebinin hangi kanaldan açılacağı, müdahale şeklinin nasıl olduğu ve bakımın neleri kapsadığı karşılaştırılmalıdır.

Bir de sürekliliği düşünün: Yazılımı geliştiren ekip bir gün işinize devam edemezse ne olur? Yazılımın belgelenmesi ve başka bir ekibe devredilebilir olması, uzun vadede fiyattan daha önemli hâle gelebilir.

Kaynak kod, lisans ve devir

Size özel geliştirilen bir yazılımda kaynak koda erişiminizin olup olmadığı, hazır bir üründe ise lisansın hangi koşullarda sürdüğü yazılı olmalıdır. Verinin her durumda size ait olduğu ve sözleşme bittiğinde hangi biçimde teslim edileceği de teklifte ya da sözleşmede açıkça geçmelidir.

Toplam maliyeti hesaplamak

Teklifteki rakam, yazılımın size maliyetinin yalnız bir kısmıdır. Karşılaştırma yapılırken şu kalemler de eklenmelidir: yıllık lisans ya da abonelik, barındırma ve sunucu, bakım ve destek, entegrasyonlar, veri taşıma, eğitim ve ekibin projeye ayıracağı zaman. Bunlar eklendiğinde ilk bakışta pahalı görünen teklifin daha ekonomik olduğu, ucuz görünenin ise ek kalemlerle öne geçtiği sıkça görülür.

Ekibinizin zamanı da bu hesabın görünmeyen ama gerçek bir kalemidir. Bir sistem kullanımı zor olduğu için her işlemde fazladan adım istiyorsa ya da diğer programlarla konuşmadığı için elle aktarım gerektiriyorsa, bu yük her gün tekrar eder. Teklifleri değerlendirirken “bu sistemle günlük iş nasıl yürüyecek?” sorusunu sormak, kâğıttaki rakamın göstermediği maliyeti görünür kılar. Mümkünse ekipten sistemi en çok kullanacak birkaç kişinin tanıtımlara katılması, bu değerlendirmeyi çok daha gerçekçi yapar.

Teklif dışında neye bakılmalı?

Belge ne kadar iyi olursa olsun, firmayla çalışmanın nasıl olacağını gösteren işaretler de vardır. Teklif sürecinde sorularınıza nasıl cevap verdikleri, ihtiyacınızı anlamak için soru sorup sormadıkları ve olmayacak bir şeyi açıkça söyleyip söylemedikleri önemli ipuçlarıdır. Her talebe “olur” diyen bir firma, kapsamı yeterince düşünmemiş olabilir. Mümkünse önceki işlerinden birini çalışır hâlde görmek ve o işin sahibiyle konuşmak da faydalıdır.

Tanıtım toplantılarında hazır bir sunum izlemek yerine, ihtiyaç belgenizdeki gerçek bir iş akışını göstermelerini isteyin. Hazır ürünlerde bu, ürünün işinize ne kadar uyduğunu; özel geliştirmede ise firmanın ihtiyacınızı ne kadar anladığını gösterir. Projede kimlerin çalışacağını, sizin tarafta kiminle muhatap olacağınızı ve proje boyunca ilerlemenin nasıl paylaşılacağını sormak da çalışma düzenini önceden görmenizi sağlar.

Bunny Soft teklif karşılaştırmasına nasıl yardımcı oluyor?

Bilişim danışmanlığı kapsamında, yatırımdan önce mevcut sistemlerinizi inceliyor ve günlük işi yürüten ekiplerinizle konuşarak ihtiyaçları işinizin diliyle tanımlıyoruz. Bu tanım, firmalardan teklif isteyeceğiniz ortak belgenin temelini oluşturur. Hazır ürünleri, işinize özel geliştirmeyi ve mevcut sistemin iyileştirilmesini aynı ölçütlerle karşılaştırıyor, gerekçeleriyle raporluyoruz; işinize hazır bir ürün uyuyorsa bunu açıkça yazıyoruz.

Seçim ve kurulum sürecinde de yanınızda oluyoruz. Uygulamayı başka bir ekiple yürütmeyi seçerseniz planı, gerekçeleri ve teknik ayrıntılarıyla onlara eksiksiz aktarıyoruz. Amacımız size bir ürün satmak değil, kararınızı tedarikçi önerisine değil kendi ihtiyacınıza dayandırmanızı sağlamak.

Teklif istemeden önce ihtiyacı netleştirmek ve seçenekleri tarafsız karşılaştırmak için bilişim danışmanlığı sayfamıza göz atabilirsiniz.