Özel Yazılım mı, Hazır Paket mi? Karar Rehberi

Bir işletme yazılım ihtiyacını konuşmaya başladığında soru genellikle "kaça mal olur" diye sorulur. Oysa bu kararın maliyet boyutu üç kalemden yalnızca biridir. Diğer ikisi, süreçlerinizin ne kadar özgün olduğu ve beş yıl sonra hangi konumda olmak istediğinizdir.

Hazır paket ne zaman yeterlidir?

Hazır paket, sizin gibi yüzlerce işletmenin ortak ihtiyacına göre yazılmış bir üründür. Muhasebe, bordro, e-fatura, temel stok takibi gibi alanlarda süreç zaten mevzuatla belirlenmiştir; burada özgünlük aramak anlamlı değildir.

Şu koşulların çoğu geçerliyse hazır paket doğru karardır:

• Süreciniz sektörün genel kabul görmüş işleyişinden farklı değil.
• Hızla başlamanız gerekiyor; haftalar değil günler ölçeğinde.
• Ekipte yazılım yönetecek teknik kaynak yok.
• İhtiyaç mevzuata bağlı ve mevzuat sık değişiyor; güncellemeyi üretici üstlensin istiyorsunuz.
• Kullanıcı sayınız az ve lisans maliyeti düşük kalıyor.

Bu durumda yapılacak iş, paketi seçmek ve süreci pakete uydurmaktır. Buradaki en yaygın hata, hazır paketi alıp onu kendi eski alışkanlıklarınıza benzetmeye çalışmaktır; bu, hem paketin avantajını yok eder hem de her güncellemede sorun çıkarır.

Özel yazılım hangi durumda gerekir?

Özel yazılım, süreç sizin rekabet avantajınızın parçasıysa gerekir. İşi rakiplerinizden farklı yapıyorsanız ve bu fark müşteriye yansıyorsa, o farkı hazır bir pakete sığdırmak avantajı silmek anlamına gelir.

Somut işaretler:

• Ekibiniz hazır paketin dışında ayrıca elektronik tablo tutuyor. Bu, paketin işi karşılamadığının en net göstergesidir.
• Aynı veriyi birden fazla sisteme elle giriyorsunuz.
• Fiyatlandırma, üretim planlama veya lojistik kurallarınız standart dışı.
• Birden fazla sistemi birbirine bağlamanız gerekiyor ve aradaki mantık size özgü.
• Kullanıcı sayısı büyüdükçe lisans maliyeti geliştirme maliyetine yaklaşıyor.
• Verinin tamamına sahip olmanız ve üzerinde analiz yapmanız gerekiyor.

Toplam sahip olma maliyeti nasıl hesaplanır?

İki seçeneği karşılaştırırken yalnızca ilk yılın rakamına bakmak yanıltıcıdır. Beş yıllık hesap yapılmalı ve iki tarafta da genellikle unutulan kalemler eklenmelidir.

Bu tabloda kritik satır "büyüme etkisi" satırıdır. Kullanıcı başına ücretlendirilen bir pakette, ekip iki katına çıktığında maliyet de iki katına çıkar. Özel yazılımda geliştirme maliyeti bir kere ödenir; büyüme yalnızca sunucu tarafında maliyet yaratır.

Tedarikçiye bağımlılık nasıl ölçülür?

Bağımlılık, sistemi değiştirmenin size kaça mal olacağıdır. Hem hazır pakette hem özel yazılımda vardır; farkı, kimin elinde olduğudur.

Sözleşme aşamasında sorulacak sorular:

1. Verilerimin tamamını, ilişkileriyle birlikte, standart bir biçimde dışa aktarabiliyor muyum?
2. Dışa aktarma için ek ücret ödeyecek miyim veya bir bekleme süresi var mı?
3. Sistemde ürettiğim veriler kime ait? Sözleşmede açık yazıyor mu?
4. Özel yazılımda kaynak kodu kime ait, kod deposu erişimi bende mi?
5. Kullanılan teknolojiler yaygın mı, başka bir ekip devralabilir mi?
6. Fiyat artışı hangi koşullarda ve hangi üst sınırla yapılabiliyor?
7. Hizmet sonlandığında bir geçiş dönemi ve veri devri taahhüdü var mı?

Özel yazılımda bağımlılığı azaltan tek şey teknoloji seçimidir. Yaygın diller, standart çatılar, belgelenmiş kod ve düzenli çalışan bir sürüm kontrol deposu; ekibi değiştirmeniz gerektiğinde bunu mümkün kılar. Kimsenin bilmediği bir teknolojiyle yazılmış özel yazılım, hazır paketten daha ağır bir bağımlılık üretir.

Entegrasyon ihtiyacı kararı nasıl değiştirir?

Çoğu işletmede tek bir sistem yoktur; muhasebe programı, e-ticaret altyapısı, kargo firmaları, banka ve pazaryerleri birlikte çalışır. Karar verirken sorulacak asıl soru şudur: bu sistemler arasındaki mantık ne kadar bize özgü?

Bağlantılar standartsa hazır paketin hazır entegrasyonları işi görür. Ancak "sipariş şu koşulda şu depodan çıksın, şu müşteri grubuna şu fiyat uygulansın, şu ürün grubunda şu kargo seçilsin" gibi kurallarınız varsa, bunlar hazır paketlerde ya hiç yoktur ya da her biri ayrı ücretli özelleştirme olur.

Sık kullandığımız bir ara model şudur: temel işleri hazır paketlerde bırakmak, aradaki özgün mantığı üstlenen küçük bir ara katman geliştirmek. Bu yaklaşım, her şeyi sıfırdan yazmadan süreç özgünlüğünü korur ve maliyeti belirgin biçimde düşürür.

Ara yollar neler?

• Hazır paket ve özel modül: Ana sistem hazır kalır, yalnızca farklı olan süreç için özel bir modül geliştirilir. Koşulu, paketin sağlam bir API sunmasıdır.
• Açık kaynak temel ve özel geliştirme: Olgun bir açık kaynak sistem temel alınır, üzerine kurum ihtiyaçları yazılır. Lisans maliyeti yoktur, uyarlama serbesttir; buna karşılık güncelleme sorumluluğu size geçer.
• Aşamalı geçiş: Önce hazır paketle başlanır, süreçler oturduktan sonra en kritik bölüm özel yazılıma taşınır. Gerçek ihtiyacı öğrenmenin en ucuz yoludur.
• Ara katman yaklaşımı: Sistemler yerinde kalır, aradaki veri akışını ve iş kurallarını yöneten bir katman yazılır.

Karar öncesi hangi hazırlık yapılmalı?

Yazılım kararı, süreç haritası çıkarılmadan verilmemelidir. Yapılacak hazırlık şudur:

1. Mevcut süreci adım adım yazın: hangi bilgi nereden geliyor, kim ne yapıyor, hangi belge üretiliyor.
2. Hangi adımların gerçekten size özgü olduğunu işaretleyin. Çoğu zaman "bizde farklı" denen adımların yarısı yalnızca alışkanlıktır.
3. Zorunlu ihtiyaçlarla iyi olur listesini ayırın. Bu ayrım yapılmadığında her seçenek yetersiz görünür.
4. Kullanıcı sayısını ve üç yıllık büyüme tahminini yazın; lisans hesabı buna dayanır.
5. Hangi sistemlerle konuşacağını ve hangi yöntemle konuşabileceğini araştırın.
6. Karar kriterlerini ağırlıklandırın: maliyet, hız, esneklik, bağımsızlık, destek.

Bu hazırlık birkaç gün sürer ve genellikle kararı kendiliğinden ortaya çıkarır. Hazırlık yapılmadan alınan tekliflerde ise karşılaştırma imkânsızdır; her tedarikçi farklı bir işi anlatır.

Özel yazılımda proje riski nasıl yönetilir?

Özel yazılımın gerçek riski maliyet değil, yanlış şeyi geliştirmektir. Altı ay boyunca kimseye gösterilmeden yazılan bir sistem, teslim edildiğinde ihtiyaca uymayabilir ve bu noktada harcanan emeğin geri dönüşü yoktur.

Riski düşüren çalışma biçimi şudur:

• Kısa döngüler: İki-üç haftalık aralıklarla çalışan bir sürüm gösterilir. Yön değişikliği erken yapılır, geç değil.
• Önce en kritik akış: Sistemin en çok kullanılacak ekranı ilk üretilir; yan özellikler sonraya bırakılır.
• Gerçek kullanıcıyla test: Ekranları kullanacak kişi geliştirme sürerken denemelidir. Yöneticinin onayı, sahadaki kullanıcının onayı yerine geçmez.
• Staging ortamı ve sürüm kontrolü: Her değişiklik izlenebilir ve geri alınabilir olmalıdır.
• Kabul ölçütleri: Her iş kaleminin ne zaman bitmiş sayılacağı önceden yazılır; aksi hâlde teslim tartışması sözlü hafızaya kalır.
• Belgeleme: Kurulum, yapılandırma ve veri modeli belgelenir. Ekip değiştiğinde maliyet tam olarak buradan doğar.

Bu yapı kurulduğunda özel yazılım, tek seferlik bir teslim projesi olmaktan çıkıp yönetilebilir bir ürün geliştirme sürecine dönüşür.

Pratik sonuç

Basit bir ölçüt: sürecinizi anlatırken "bizde şöyle olmaz, biz şöyle yaparız" cümlesini ne sıklıkla kuruyorsunuz? Nadiren kuruyorsanız hazır paket alın ve sürecinizi pakete uydurun. Sık kuruyorsanız ve o farklılık müşterinize değer üretiyorsa, o farkı koruyacak bir çözüm geliştirin.

Üçüncü bir ölçüt de zamanlamadır. İhtiyacı henüz tam tanımlayamıyorsanız, önce hazır bir çözümle çalışmak öğrenmenin en ucuz yoludur; süreçler oturduktan sonra geliştirilen özel yazılım çok daha isabetli olur. Buna karşılık hazır çözümün getirdiği kısıtlar günlük işi aksatmaya başladıysa, beklemek maliyeti artırır çünkü bu süre boyunca ekip elektronik tablolarla ve elle veri girişiyle açığı kapatmaya çalışır.

İkinci ölçüt maliyetin yönüdür: hazır pakette maliyet kullanıcı ve zamanla doğrusal artar, özel yazılımda başta yoğunlaşır sonra düşer. Kısa vadeli bir ihtiyaç için birinci eğri, uzun vadeli bir yatırım için ikinci eğri daha uygundur. Kararı bu iki soruyla verdiğinizde, tedarikçi sunumlarının etkisi belirgin biçimde azalır.