İki yazılım teklifinde de müşteri listesi, sipariş ekranı ve raporlar var. Fiyatlar ise birbirinden uzak. Farkın nedenini görmek için ekran adlarının arkasına bakın: siparişi kim değiştirecek, muhasebe bağlantısı kesilirse ne olacak, eski kayıtları kim temizleyecek? Özel yazılım maliyeti, görünen ekranlar kadar onların hangi koşullarda çalışacağından etkilenir.
Örneğin depo siparişlerini takip edecek bir uygulama düşünün. Tekliflerden biri kayıt ekleme ve listelemeyi kapsarken diğeri şubeye göre yetki, muhasebeyle eşitleme ve geçmiş verilerin aktarımını içeriyor olabilir. Aynı uygulama adını kullanmaları, aynı işi fiyatladıkları anlamına gelmez. Aşağıdaki beş belirsizlik, teklifleri karşılaştırırken farkın nerede oluştuğunu bulmanıza yardım eder.
Henüz geliştirme yaptırmakla hazır ürün kullanmak arasında karar vermediyseniz özel yazılımın hangi ihtiyaçlarda anlamlı olduğunu önce değerlendirin. İhtiyacınız işletme içi uygulama yerine hizmetlerinizi tanıtacak bir siteyse web sitesi tekliflerini karşılaştırma ölçütleri daha uygun başlangıçtır.
1. İş Kuralları ve Yetkiler Ne Kadar Açık?
“Sipariş düzenleme” küçük bir özellik gibi görünebilir. Satış temsilcisi yalnız kendi siparişini mi değiştirecek? Depoya iletilen sipariş düzenlenebilecek mi? Faturası kesilen kayıt için iptal veya düzeltme yolu gerekiyor mu? Her cevap, uygulamanın farklı durumlarda ne yapacağını belirler.
Teklifte yalnız “üç kullanıcı rolü” yazması da yeterli değildir. Roller arasındaki fark, görülen sayfalardan ibaret olmayabilir; kayıt bazında erişim, onay yetkisi ve rol değişikliği sonrası davranış da geliştirilecek işe girer. OWASP’ın yetkilendirme önerileri, kullanıcı, kaynak ve işlem izinlerinin tasarımda tanımlanmasını ve test edilmesini ele alır.
Firmanın hangi iş kurallarını fiyatına dahil ettiğini sorun. “Standart yetkilendirme var” cevabı yerine temsilci, depo sorumlusu ve yönetici için beklenen davranışları karşılaştırın. İşletmenizde gerekmeyen bir onay katmanına para ayırmak da zorunlu bir kontrolü kapsam dışı bırakmak da yanlış karara götürebilir.
2. Entegrasyon Hangi İşlemleri Kapsıyor?
API, uygulamaların belirli kurallarla veri alışverişi yapmasını sağlayan arayüzdür. Bir muhasebe programının API sunması, ihtiyacınız olan her kayda ve işleme erişebileceğiniz anlamına gelmez. Tekliften önce kullanılacak sürüm, erişim izni, desteklenen işlemler ve deneme ortamı kontrol edilmelidir.
Depo örneğinde, onaylanan siparişi muhasebeye göndermekle ödeme ve iptal durumlarını geri alıp iki sistemi güncel tutmak farklı işlerdir. İkinci kapsamda verinin hangi tarafta esas alınacağı, bağlantı hatalarının nasıl izleneceği ve çelişen değişikliklerin nasıl çözüleceği konuşulur.
Ödeme gibi sonuç doğuran işlemlerde tekrar deneme davranışı özellikle açık olmalıdır. Stripe’ın idempotent istek açıklaması, bağlantı sorunu sonrası aynı işlemin ikinci kez oluşturulmasını önlemeye yönelik bir örnektir. Her servis aynı imkânı sunmaz; teknik ekibin bağlantı davranışını doğrulaması gerekir.
“Entegrasyon dahil mi?” yerine şu soruyu sorun: Hangi kayıt, hangi yönde, ne sıklıkla aktarılacak; başarısız işlemden kim haberdar olacak? Veri akışını ve sorumluları belirleyen entegrasyon planıyla cevabı teklifin eki yapın.
3. Eski Veriler Aktarıma Hazır mı?
Müşteri listesinin Excel dosyasında olması, aktarım işinin belli olduğu anlamına gelmez. Aynı müşteri farklı adlarla kaydedilmiş, ürün kodları değişmiş veya zorunlu alanlar boş bırakılmış olabilir. Kayıt sayısından önce dosyanın içeriğini görmek gerekir. Dosyayı uygulamaya taşımaya henüz karar vermediyseniz önce Excel’deki aksaklığın yeni yazılım gerektirip gerektirmediğini değerlendirin.
IBM’in veri geçişi açıklaması, kaynak ve hedef yapıların yanı sıra veri kalitesi ile doğrulamayı da sürecin parçası olarak ele alır. Teklif karşılaştırmasında asıl soru, eski veriyi yeni uygulamanın beklediği hale kimin getireceğidir.
- Temizlenecek, dönüştürülecek ve yalnız arşivde tutulacak kayıtlar ayrılmış mı?
- Ürün ve müşteri kodlarının yeni alanlarla eşlemesini kim onaylayacak?
- Deneme aktarımı sonrasında doğruluğu hangi örnek işlemlerle kontrol edeceksiniz?
- Son geçiş sırasında eski sisteme girilen yeni kayıtlar nasıl ele alınacak?
Bir firma yalnız temiz dosyanın yüklenmesini, diğeri dosyanın incelenmesini ve sorunlu kayıtların ayıklanmasını fiyatlıyor olabilir. Aradaki farkı “veri aktarımı dahil” satırı tek başına göstermez. Örnek dosyayı paylaşırken kişisel ve ticari bilgileri gizleyin. Gerçek veriye geçileceği aşamada erişimin koşullarını kararlaştırın.
4. Hangi Koşullarda Çalıştığı Kanıtlanacak?
Az kayıtla yapılan kısa bir gösterim, yoğun iş gününü temsil etmeyebilir. Sipariş listesinin açılması kadar kullanıcılar aynı kaydı düzenlediğinde ne olacağı, dış servis yanıt vermediğinde işlemin nasıl devam edeceği ve yetkisiz erişimin engellenmesi de teslim beklentisine girebilir.
Kabul koşulları, uygulamayı tamamlanmış saymak için gözleyeceğiniz sonuçlardır. Depo yöneticisi kendi şubesinin açık siparişlerini görebilmeli, başka şubenin kaydını değiştirememeli ve başarısız aktarımı fark edebilmelidir. Hız veya eşzamanlı kullanım hedefi gerekiyorsa veri büyüklüğü ve kullanım koşullarıyla birlikte tanımlayın.
Teklifte test ortamı, örnek veri, kullanıcı kabul çalışması ve bulunan sorunların tekrar kontrolü için sorumlular belli olsun. Microsoft’un uygulama yaşam döngüsü açıklaması geliştirmeyi test, dağıtım ve bakım işleriyle birlikte ele alır. Kodun yazılması, bütün teslim işlerinin kendiliğinden tamamlandığını göstermez.
5. Yayın Sonrası Giderler Kimin Sorumluluğunda?
Geliştirme bedeliyle uygulamayı çalışır tutmanın giderlerini ayrı okuyun. Sunucu, lisans, dış servis kullanımı, yedekleme, izleme ve destek farklı kişiler veya firmalar tarafından sağlanabilir. Teklifte yer almayan bir kalem, hiç gerekmeyeceği anlamına gelmez.
Microsoft’un maliyet modeli yaklaşımı, başlangıç ve devam eden giderlerin kullanım koşullarıyla değerlendirilmesini önerir. Karşılaştırmanızda ilk teslim bedelinin yanına tekrar eden ödemeleri ve sizin ekibinizin üstleneceği işleri de yazın.
“Bakım dahil” ifadesini açın: kabul edilen kapsam içindeki hatalar mı düzeltilecek, dış hizmet değişince bağlantı mı uyarlanacak, yoksa yeni özellikler de mi geliştirilecek? Destek saatleri, sorunun nasıl bildirileceği ve çözüm sorumlusu netleşsin. Her yazılım için geçerli sabit bir bakım yüzdesi varsaymayın.
Proje müşterilere abonelikle sunulacak bir ürünse gider yalnız şirket içi kullanıma göre düşünülmez. Müşteri hesapları, hizmetin devamlılığı ve destek yükü de hesaba katılır. SaaS ürünü geliştirirken üstlenilen sorumluluklar, abonelik geliriyle birlikte planlanmalıdır.
Aynı Teklif Başlığının Altında Farklı İşler Olabilir
Aşağıdaki örnek gerçek bir fiyat teklifi değildir. Aynı sipariş uygulaması için kapsam ifadelerinin neden açılması gerektiğini gösterir. B sütunu her işletme için daha iyi veya zorunlu değildir; gereken işi sizin kullanımınız belirler.
| Kalem | Teklif A | Teklif B |
|---|---|---|
| Muhasebe bağlantısı | Onaylanan siparişin tek yönlü gönderilmesi | Sipariş ve ödeme durumlarının karşılıklı eşitlenmesi |
| Veri geçişi | İşletmenin temizlediği dosyanın yüklenmesi | Örnek inceleme, alan eşleme ve sorunlu kayıtların değerlendirilmesi |
| Teslim kontrolü | Kararlaştırılan temel işlemlerin gösterilmesi | Temel işlemlere ek olarak belirlenmiş yoğunluk ve hata koşullarının sınanması |
| Yayın sonrası | İşletme ekibinin operasyonu devralması | Sınırları yazılı izleme ve destek hizmeti |
Düşük bedeli hemen eksik iş, yüksek bedeli de otomatik olarak yüksek kalite saymayın. Önce kapsam farkını giderin. Ardından aynı işi üstlenen ekiplerin yaklaşımını, teslim sorumluluklarını ve teklif koşullarını değerlendirin.
Teklif Almadan Önce Belirsizliği Azaltın
Bir tahmin, dayandığı bilgi kadar işe yarar. GAO’nun maliyet tahmini rehberi kapsam, varsayımlar ve belirsizliklerin belgelenmesini maliyet değerlendirmesinin parçası olarak ele alır. İşletme tarafında işe, bilinenler ile henüz kararlaştırılmamış noktaları ayırarak başlayabilirsiniz.
Uygulamanın ilk sürümünde tamamlanması gereken işi belirleyin. Eski veriden örnek hazırlayın, dış sistem belgelerini bulun ve kritik bir bağlantı henüz doğrulanmamışsa teklifin hangi varsayıma dayandığını yazdırın. İş akışını henüz tarif edemiyorsanız teklif öncesi yazılım ihtiyaçlarını netleştirme adımları hazırlığı düzenlemenize yardımcı olur.
Çalışacağı henüz doğrulanmamış bir bağlantıyı kesin teslim sözü gibi değerlendirmeyin. Ön teknik incelemenin kapsamını ve olumsuz sonuç çıkarsa teklifin nasıl değişeceğini konuşun. Belirsizliği gizlemek, onu ortadan kaldırmaz.
Firmaya son bir soru yöneltin: “Hangi varsayım değişirse fiyatı yeniden konuşacağız?” Cevap bir özellik listesi kadar değerlidir. Yeni talebin kapsam, süre ve bedel etkisinin kim tarafından onaylanacağını da baştan kararlaştırın.
Yazılım Teklifinizin Kapsamını Birlikte Netleştirelim
Metazen’de yazılımı ekran listesiyle sınırlamadan kullanıcıların yapacağı işler, veri bağlantıları ve sürdürülebilir geliştirme üzerinden ele alıyoruz. Yazılım ekibimizin uzmanlıklarını inceleyebilir, elinizdeki süreci veya teklif beklentinizi bizimle paylaşabilirsiniz. İhtiyaçların değerlendirilmesinden uygulamanın geliştirilmesine uzanan çalışma kapsamını özel yazılım hizmetimizde bulabilirsiniz.
