Özel Yazılım Nedir?
Kısa tanım
Özel yazılım, belirli bir kurumun süreçleri, kullanıcıları ve entegrasyon ihtiyaçları için sıfırdan veya mevcut bileşenler üzerine tasarlanıp geliştirilen yazılımdır. Herkese aynı şekilde satılan hazır paketlerin ve abonelikli SaaS ürünlerinin aksine, yazılım şirketin iş akışına göre şekillenir. Kaynak kodu ve yol haritası genellikle kurumun kontrolündedir; karşılığında geliştirme, barındırma ve sürekli bakım sorumluluğu da kuruma ya da seçtiği ekibe aittir.
Diğer adları: custom software, özel yazılım geliştirme, ısmarlama yazılım, bespoke software, firmaya özel yazılım
Süreç yazılıma değil, yazılım sürece uyar
Hazır bir ürün satın alındığında şirket, ürünün tasarlandığı iş akışına kendini uydurur. Çoğu standart iş için bu doğru bir tercihtir. Özel yazılımda ise yön tersine döner: ekranlar, yetki kuralları, raporlar ve entegrasyonlar şirketin gerçekte nasıl çalıştığına göre tasarlanır. Örneğin bir bayi ağının sipariş, stok ve prim hesaplarını tek yerde birleştiren bir portal, bir laboratuvarın numune kabulünden rapor teslimine kadar uzanan iş akışı ya da bir sahadaki ekiplerin çevrim dışı da çalışabilen mobil uygulaması tipik özel yazılım projeleridir.
İkinci büyük fark sahipliktir. Kaynak kodu, veri modeli ve yol haritası kurumun kontrolündedir; hangi özelliğin ne zaman geleceğine bir sağlayıcının ürün planı değil, kurumun öncelikleri karar verir.
Hazır paket, SaaS ve özel geliştirme arasında karar
Maliyet, bakım ve verinin yeri gibi başlıklarda üç seçeneğin satır satır karşılaştırması SaaS maddesinde yer alıyor. Burada kararı netleştiren sorulara odaklanmak daha faydalı:
- Bu süreç bizi rakiplerimizden ayırıyor mu? Ayırmıyorsa özel geliştirme çoğunlukla gereksiz bir masraftır.
- Hazır ürünü ne kadar zorlamamız gerekiyor? Eklentiler, elle yapılan aktarmalar ve Excel'de sürdürülen ara adımlar çoğaldıysa ürün süreci taşımıyor demektir.
- Hangi sistemlerle konuşmalı? Muhasebe, ERP, CRM, e-ticaret ve kargo sistemleriyle yoğun veri alışverişi gerekiyorsa entegrasyon katmanı başlı başına bir proje olabilir.
- Beş yıl sonra kim bakacak? İç ekip mi, dış bir ajans mı? Bu soru cevapsızsa proje daha başlamadan risk taşır.
Ara yollar da vardır: bir SaaS ürününü API'si üzerinden yalnızca eksik kalan kısımlarla genişletmek ya da iç kullanım için basit araçları low-code platformlarla kurmak.
Bir özel yazılım projesi nasıl ilerler?
Sağlıklı projeler, ilk satır kod yazılmadan önce bir keşif aşamasıyla başlar: kullanıcılarla görüşülür, mevcut süreç ve veri akışı çıkarılır, kapsam önceliklendirilir. Ardından en kritik işi uçtan uca çözen bir MVP hedeflenir; gerçek kullanımdan gelen geri bildirimle kapsam genişletilir. Bütçeleme yapılırken yalnızca geliştirme maliyeti değil, barındırma, izleme, güvenlik güncellemeleri ve küçük geliştirmeler için her yıl tekrarlayan bir bakım bütçesi de hesaba katılmalıdır.
Sözleşmede yazılı olması gerekenler
- Kaynak kodunun ve fikrî hakların kime ait olduğu, kodun hangi depoda ve kimin erişiminde tutulacağı.
- Sunucu, alan adı ve üçüncü taraf hesaplarının kurum adına açılması.
- Teslim edilecek dokümantasyon: kurulum, mimari ve kullanıcı kılavuzu.
- Canlıya çıktıktan sonraki destek süresi, müdahale süreleri ve ücretlendirme.
Bu maddeler belirsiz kalırsa kurum, bir yazılım sağlayıcısına bağımlı kalmaktan kaçarken bu kez geliştirici ajansa bağımlı hâle gelebilir.
Tipik riskler
Kapsamın sürekli büyümesi, tek bir geliştiricinin bütün bilgiyi taşıması ve zaman baskısıyla biriken teknik borç en sık görülen sorunlardır. Bunlara karşı en etkili önlemler net önceliklendirme, kod incelemesi, otomatik testler ve sık, küçük teslimlerdir. Projeyi teslim alan tarafın da en az bir kişinin kodu ve altyapıyı okuyabilecek düzeyde süreçte yer alması, ileride ekip değiştiğinde yaşanacak kesintiyi büyük ölçüde azaltır.