"Bir yazılım yaptırsak ne kadar tutar?" sorusunun tek cümlelik bir cevabı yok — ve bu cevabı hemen veren bir tedarikçi, muhtemelen sizin işinizi henüz anlamamış demektir. Özel yazılımda maliyet, ekran sayısından çok iş kurallarının ve entegrasyonların karmaşıklığına bağlıdır. Bu yazıda bütçeyi neyin belirlediğini, hangi kalemlerin teklifte mutlaka yer alması gerektiğini ve rakamları nasıl karşılaştıracağınızı anlatıyoruz.
1. Maliyeti belirleyen temel unsurlar
İş akışları ve kullanıcı rolleri
Bir kaydı yalnızca eklemek ile aynı kaydı çok aşamalı onaydan geçirmek, departman yetkisiyle sınırlamak ve değişiklik geçmişini tutmak aynı efor değildir. Örnek vermek gerekirse: "sipariş girişi" tek başına birkaç günlük bir iştir. Ama aynı siparişin satış temsilcisi tarafından girilip, kredi limiti kontrolünden geçip, depo tarafından onaylanıp, muhasebeye düşmesi gerekiyorsa bu artık bir ekran değil bir süreçtir. Her rol ve her istisna, test kapsamını da büyütür.
Pratik kural: kullanıcı rolü sayısı arttıkça maliyet doğrusal değil, basamaklı artar. İki rolden dört role çıkmak eforu iki katına çıkarmaz; ama roller arası etkileşim ve yetki kuralları nedeniyle beklediğinizden fazla büyütür.
Entegrasyonlar
ERP, muhasebe programı, e-ticaret altyapısı, ödeme sistemi veya üretim hattındaki makinelerle veri alışverişi gerekiyorsa, karşı sistemin API kalitesi süreyi doğrudan etkiler. Modern bir REST API sunan sistemle entegrasyon birkaç gün sürerken, yalnızca dosya aktarımı destekleyen eski bir muhasebe programıyla aynı iş haftalara yayılabilir.
Teklif alırken şu soruyu sorun: "Entegre olacağımız sistemin dokümantasyonunu incelediniz mi?" Cevap hayırsa, verilen süre tahmini bir tahminden ibarettir.
Mevcut verinin aktarılması
Excel dosyalarındaki ve eski sistemlerdeki verinin temizlenmesi, eşleştirilmesi ve doğrulanması ayrı bir iş paketidir — ve en sık küçümsenen kalemdir. Aynı müşterinin üç farklı yazımla kayıtlı olması, boş bırakılmış zorunlu alanlar, tutarsız birim kullanımı gibi sorunlar canlıya geçişte ortaya çıkarsa proje durur.
Öneri: Veri aktarımını proje sonuna bırakmayın. Keşif aşamasında gerçek verinizden bir örnek kümeyle test edin; böylece temizlik ihtiyacı ve süresi baştan görünür olur.
2. Teklifte hangi kalemler bulunmalı?
Aşağıdaki kalemlerin her biri teklifte ayrı satır olarak görünmelidir. Tek bir toplam rakam veren teklif, karşılaştırma yapmanızı imkânsız kılar.
| Kalem | Ne içerir | Tipik ağırlık |
|---|---|---|
| Keşif ve analiz | Süreç görüşmeleri, saha gözlemi, kapsam dokümanı | %10-15 |
| Arayüz ve geliştirme | Ekran tasarımı, iş kuralları, kodlama | %45-55 |
| Entegrasyon ve veri aktarımı | Diğer sistemlerle bağlantı, mevcut veri taşıma | %15-25 |
| Test, eğitim, canlıya geçiş | Kabul testleri, kullanıcı eğitimi, devreye alma | %10-15 |
| Barındırma, bakım, destek | Sunucu, güncelleme, hata giderme | Yıllık ayrı bütçe |
Yukarıdaki oranlar sektörde sık görülen dağılımlardır ve projeden projeye değişir; kesin oran olarak değil, teklifte eksik kalem olup olmadığını anlamak için bir kontrol listesi olarak kullanılmalıdır.
3. Bütçe aralıkları: gerçekçi bir çerçeve
Kesin fiyat kapsam netleşmeden verilemez, ancak planlama yapabilmeniz için piyasada sık karşılaşılan bandları paylaşalım:
| Proje tipi | Tipik kapsam | Süre |
|---|---|---|
| Tek amaçlı uygulama | Tek modül, 1-2 kullanıcı rolü, entegrasyon yok | 3-6 hafta |
| Departman çözümü | Birkaç modül, roller, tek entegrasyon | 2-4 ay |
| Kurumsal ERP / çok departmanlı | Çok modül, çok rol, birden fazla entegrasyon, veri aktarımı | Aşamalı, 6 ay+ |
Kurumsal web sitesi tarafında ise durum daha öngörülebilir: şeffaf paket fiyatlarımızda tanıtım siteleri 8.000 TL’den, özel tasarımlı kurumsal siteler 15.000 TL’den başlıyor ve 2-6 haftada teslim ediliyor. Özel yazılımda böyle sabit bir liste vermek doğru olmaz; çünkü iki işletmenin "stok takibi" ihtiyacı bile birbirinden çok farklı olabilir.
4. Bütçe nasıl kontrol altında tutulur?
Projeyi zorunlu, sonraki aşama ve isteğe bağlı teslimlere ayırın. Önce en pahalı problemi çözen çekirdek sürümü yayınlayın. Bu yaklaşımın iki somut faydası var:
- Varsayımlar erken doğrulanır. Ekibin gerçekten kullanacağı bir şey mi yaptık? Bunu altı ay sonra değil, altı hafta sonra öğrenmek çok daha ucuzdur.
- Fayda erken başlar. Çalışan bir parça devredeyken yatırımın geri dönüşü de başlar; tüm proje bitene kadar beklemek zorunda kalmazsınız.
Gıda ve tarım sektöründeki üreticilerle yaptığımız web ve yazılım çalışmalarında da bu aşamalı yaklaşımı izliyoruz: önce satışa doğrudan katkı veren kısım, sonra operasyonel derinleşme.
5. Bütçeyi şişiren tipik hatalar
Aşağıdakiler, danışmanlık görüşmelerinde en sık karşılaştığımız ve maliyeti sonradan büyüten durumlar:
- "Madem yapıyoruz, şunu da ekleyelim" birikmesi. Proje sırasında gelen her küçük istek tek başına masum görünür; toplamı ise kapsamı iki katına çıkarabilir. Çözüm, ek istekleri reddetmek değil — bunları "sonraki aşama" listesine alıp mevcut sürümü zamanında bitirmektir.
- Karar verecek kişinin süreçte olmaması. Ekranlar hazırlanıp gösterildikten sonra yönetimden gelen "biz bunu böyle istememiştik" geri dönüşü, yapılan işin bir kısmının tekrarlanması demektir. Keşif toplantısına kararı verecek kişinin katılması, sonradan çıkacak maliyetin en ucuz sigortasıdır.
- Süreci olduğu gibi yazılıma taşımak. Kâğıt üzerinde yıllardır yürüyen bir akış, çoğu zaman alışkanlıkla oluşmuştur. Onu aynen dijitalleştirmek, verimsizliği de dijitalleştirmek olur. İyi bir keşif, hangi adımın gerçekten gerekli olduğunu sorgular.
- Eğitim ve devreye alma kaleminin atlanması. Yazılım teslim edilse bile ekip kullanmıyorsa yatırım geri dönmez. Kullanıcı eğitimi ve ilk haftalardaki destek, teklifte görünmesi gereken gerçek bir kalemdir.
6. Yapmalı mı, satın almalı mı?
Her ihtiyaç özel yazılım gerektirmez ve bu kararı doğru vermek en büyük maliyet tasarrufudur. Kaba bir ayrım şöyle yapılabilir:
| Durum | Daha uygun seçenek |
|---|---|
| Süreçleriniz sektördeki standart akışa büyük ölçüde uyuyor | Hazır program — daha hızlı ve düşük ilk maliyet |
| Rekabet avantajınız kendine özgü çalışma biçiminizden geliyor | Özel yazılım — süreci kalıba sokmaz |
| Hazır ürünü kullanıyorsunuz ama %20’lik bir kısım eksik kalıyor | Karma — hazır ürün + entegre özel modül |
| İhtiyaç henüz net değil, süreç oturmamış | Önce hazır ürünle başlayın — ihtiyaç netleşince geliştirin |
Kullanıma hazır Workbench bulut ERP gibi ürünlerle başlayıp, ihtiyaç büyüdükçe size özel geliştirmeyle genişletmek çoğu işletme için en dengeli yol oluyor. Bu kararı keşif görüşmesinde birlikte veriyoruz; hazır bir program yeterliyse bunu açıkça söylemek de işimizin parçası.
7. Fiyat karşılaştırırken aynı kapsamı karşılaştırın
Ucuz görünen teklifte veri aktarımı, mobil uyum, güvenlik testi veya yayın sonrası destek bulunmayabilir. Bu kalemler sonradan ayrı fatura olarak döner ve toplamda daha pahalıya gelir.
Teklifleri karşılaştırırken şu üç soruyu her tedarikçiye sorun:
- Kaynak kodu ve veriler kime ait olacak? Cevap net değilse, ileride sistemi başka bir ekibe devretmeniz mümkün olmayabilir.
- Kabul kriterleri neler? "Bitti" demenin ölçüsü yazılı olmalı; aksi hâlde teslim tartışmaya açılır.
- Yayın sonrası ne oluyor? Bakım kapsamı, süresi ve bedeli baştan belli olmalı.
Cloidea’nın Bursa yazılım yaklaşımını inceleyebilir, kapsam çıkarmak ve net teklif almak için bizimle görüşebilirsiniz. İlk keşif görüşmesi ücretsizdir; sorunun yazılımla mı yoksa daha basit bir düzenlemeyle mi çözüleceğini açıkça söyleriz.