Hazır Yazılım mı Özel Yazılım mı? Kurumlar İçin Karar Çerçevesi

Kurumsal yazılım kararlarının büyük bölümü yanlış soruyla başlar: "Hangisi daha ucuz?" Bu soru, ilk faturayı karşılaştırır ama üç yıl sonraki tabloyu göstermez. Hazır bir ürünün lisans bedeli özel geliştirmenin yanında küçük görünür; buna karşılık o ürünün karşılamadığı her süreç, ya elle yürütülen bir işe ya da bir ara çözüme dönüşür ve maliyet görünmez biçimde geri gelir.

Doğru soru şudur: bu süreç bizi rakiplerimizden ayırıyor mu, yoksa herkesin aynı şekilde yaptığı bir iş mi? Bu ayrımı yapabilen kurumlar kararı kolay verir.

Ayırt edici süreç ile standart süreç

Her kurumun iş akışları iki gruba ayrılır. Birinci grup, sektörde standarttır: bordro, muhasebe fişi, e-fatura entegrasyonu, temel CRM. Bu süreçlerde farklı olmanın bir değeri yoktur; hatta standarttan sapmak mevzuat riski üretir. Bunlar için hazır ürün doğru tercihtir ve özel geliştirme kaynak israfıdır.

İkinci grup, kurumun kendi işini nasıl yaptığını tanımlar. Çok şubeli bir eğitim kurumunun şubeler arası öğrenci transfer kuralları, bir yayınevinin bayi bazlı fiyat ve teklif mantığı, bir üreticinin özel sipariş konfigürasyon akışı bu gruba girer. Bu süreçler yıllar içinde deneyimle şekillenmiştir ve rekabet avantajının kendisidir.

İkinci gruptaki bir süreci hazır bir ürüne sığdırmaya çalışmak, çoğu zaman süreci yazılıma uydurmak anlamına gelir. Bu da kurumu, kendisini farklı kılan şeyden vazgeçmeye zorlar.

Hazır ürünün gerçek maliyeti nerede birikir?

Hazır ürün kararının maliyeti lisans satırında görünmez; şu dört yerde birikir:

• Boşlukları kapatan elle işler. Ürünün karşılamadığı her adım, birinin her ay tekrar ettiği bir işe dönüşür. Ayda üç gün süren bir mutabakat işi, yılda otuz altı adam-günüdür ve hiçbir bütçe kaleminde görünmez.
• Ara çözümler. Excel dosyaları, paylaşılan tablolar, WhatsApp grupları. Bunlar başlangıçta pratiktir; iki yıl sonra kurumun gerçek iş mantığının nerede yaşadığı belirsizleşir ve kimse tam resmi göremez.
• Entegrasyon sınırları. Ürünün API'si sizin ihtiyacınızı karşılamıyorsa, veri iki sistem arasında elle taşınır. Elle taşınan veri er geç tutarsızlaşır.
• Sürüm bağımlılığı. Sağlayıcının yol haritası sizinkiyle örtüşmediğinde bekleyen taraf siz olursunuz. İhtiyacınız olan özellik başka müşterilerin önceliğine göre sıraya girer.

Özel yazılımın gerçek maliyeti nerede birikir?

Simetrik olarak, özel yazılım kararının da görünmeyen tarafları vardır ve bunları baştan kabul etmek gerekir:

• Süre. Hazır ürün haftalar içinde kullanılmaya başlanabilir; özel geliştirme aylar alır. Acil bir ihtiyacı özel yazılımla karşılamaya çalışmak genellikle iyi sonuç vermez.
• Bakım sorumluluğu. Yazılım teslim edildiğinde iş bitmez. Mevzuat değişir, entegre olunan sistemler sürüm atlar, kullanıcı ihtiyaçları evrilir. Bakım bütçesi olmayan özel yazılım, üç yıl içinde teknik borca dönüşür.
• Gereksinim netliği. Özel geliştirmenin en pahalı hatası, ne istendiğinin proje ortasında değişmesidir. Bu bir geliştirme sorunu değil, analiz sorunudur ve maliyeti kod yazmaktan yüksektir.
• Bilgi bağımlılığı. Yazılımı kimin geliştirdiği, dokümantasyonun ve kod kalitesinin durumu, ileride başka bir ekibin devralıp devralamayacağını belirler.

Karar için altı soru

Aşağıdaki sorulara verilen cevaplar, kararın hangi tarafa yaslanması gerektiğini büyük ölçüde gösterir:

1. Bu süreç sektörde standart mı? Standartsa hazır ürün; kuruma özgüyse özel geliştirme.
2. Süreç önümüzdeki üç yılda ne kadar değişecek? Sık değişen süreçler, üzerinde kontrol sahibi olduğunuz bir sistemde daha ucuza yönetilir.
3. Kaç kişi, günde kaç kez kullanacak? Yoğun kullanılan bir ekranda saniyeler önemlidir; az kullanılan bir ekranda "idare eder" yeterlidir.
4. Veriyi başka nerede kullanacağız? Verinin raporlamaya, muhasebeye ve diğer sistemlere akması gerekiyorsa, veriye erişiminizin ne kadar serbest olduğu belirleyicidir.
5. Sağlayıcıyı değiştirmemiz gerekirse ne olur? Veriyi dışa aktarabiliyor musunuz, yoksa sistemde kilitli mi kalıyor?
6. Bu işi yapan başka bir kurumu gözlemleyebiliyor muyuz? Sektörünüzde yaygın kullanılan bir ürün varsa, onun sınırlarını yaşayan kurumlarla konuşmak, demolardan daha bilgi vericidir.

Üçüncü yol: hibrit yaklaşım

Pratikte en verimli sonuç genellikle ikisinin arasındadır. Standart süreçler hazır ürünlerde bırakılır, kuruma özgü katman özel geliştirilir ve ikisi API üzerinden konuşur.

Örneğin muhasebe için yaygın bir ürün kullanılırken, satış ve özel sipariş akışı kuruma özel geliştirilebilir; fatura bilgisi entegrasyonla muhasebeye akar. Böylece hem standart tarafın bakım yükü sağlayıcıda kalır hem de ayırt edici süreç üzerinde tam kontrol korunur.

Bu yaklaşımın tek şartı, entegrasyon sınırlarının baştan netleştirilmesidir: hangi veri hangi sistemde doğar, hangisinde kopyası tutulur. Bu soru cevaplanmadan kurulan hibrit yapılar, iki sistemin de farklı doğruyu gösterdiği bir noktaya varır.

Üç yıllık toplam maliyeti hesaplamak

Karşılaştırmayı anlamlı kılmanın tek yolu, iki seçeneği de aynı zaman ufkunda ve aynı kalemlerle hesaplamaktır. Üç yıl, kurumsal yazılımda makul bir ufuktur: ilk yılın kurulum etkisi sönümlenmiş, ama teknolojinin tamamen değişmesine de yetecek kadar uzun değildir.

Hazır ürün tarafında hesaba katılması gerekenler:

• Yıllık lisans veya kullanıcı başına abonelik, üç yıl için ve öngörülen kullanıcı artışıyla birlikte.
• Kurulum, veri göçü ve eğitim bedeli.
• Kurumun ihtiyacı olup üründe bulunmayan özellikler için ödenen özelleştirme ücretleri.
• Ürünün karşılamadığı süreçler için harcanan adam-gün. Bunu tahmin etmenin pratik yolu, süreci bugün yürüten kişiye "bu ürün gelirse hangi işler sende kalır" diye sormaktır.
• Entegrasyon geliştirmeleri ve bunların bakımı.

Özel yazılım tarafında:

• Analiz ve geliştirme bedeli.
• Altyapı ve işletme maliyeti (sunucu, yedekleme, izleme).
• Yıllık bakım ve geliştirme bütçesi. Sağlıklı bir oran, ilk geliştirme bedelinin yıllık yüzde on beş ile yüzde yirmi beşi arasındadır; bunu ayırmayan kurumlar üçüncü yılda sistemin yaşlandığını fark eder.
• Mevzuat değişikliklerine uyum için ayrılan pay.

Bu iki listeyi yan yana koyduğunda çoğu kurum, ilk bakışta çok pahalı görünen özel geliştirmenin üç yıllık toplamda beklediğinden yakın çıktığını görür. Tersi de olur: ayırt edici olmayan bir süreç için özel geliştirme düşünen kurum, hazır ürünün ne kadar ucuz olduğunu somut olarak görür. Her iki durumda da karar, hisle değil tabloyla verilmiş olur.

Sözleşmede bakılması gereken dört madde

Hangi yolu seçerseniz seçin, sözleşmenin şu dört maddesi ileride ortaya çıkacak sorunların büyük bölümünü baştan belirler:

• Veri sahipliği ve dışa aktarım. Verinin size ait olduğu açıkça yazmalı ve talep hâlinde makul sürede, kullanılabilir bir formatta teslim edileceği taahhüt edilmelidir. "Ekran görüntüsü alabilirsiniz" bir dışa aktarım değildir.
• Ayrılma koşulları. Sözleşme sona erdiğinde verinin ne kadar süre saklanacağı, nasıl teslim edileceği ve ne zaman silineceği tanımlı olmalıdır.
• Hizmet seviyesi. Erişilebilirlik oranı, arıza durumunda müdahale süresi ve bunların ölçüm yöntemi. Ölçüm yöntemi yazmayan bir hizmet seviyesi taahhüdü uygulanabilir değildir.
• Kaynak kodu ve devredilebilirlik. Özel geliştirmede kodun kime ait olduğu ve dokümantasyonun teslim kapsamında olup olmadığı. Bu madde, ileride başka bir ekiple çalışma ihtimalinizin fiyatıdır.

Örnek bir karar

Çok şubeli bir eğitim kurumu düşünelim. Muhasebe, bordro ve e-fatura süreçleri sektörde standarttır; burada özel geliştirme yapmak, hem gereksiz maliyet hem de sürekli mevzuat takibi yükü demektir. Bu kalemler hazır ürünlere bırakılır.

Buna karşılık aynı kurumun şubeler arası öğrenci transferi, şubeye göre değişen fiyat ve indirim kuralları, özel sipariş akışı ve kuruma özgü raporlama ihtiyacı standart değildir. Bunlar yıllar içinde kurumun kendi deneyimiyle şekillenmiştir ve hazır bir üründe birebir karşılığı yoktur.

Doğru kurgu burada hibrittir: standart taraf hazır üründe kalır, kuruma özgü katman özel geliştirilir, fatura ve cari bilgisi entegrasyonla muhasebeye akar. Kurum hem bakım yükünün bir kısmını dışarıda tutar hem de kendisini farklı kılan süreçler üzerinde tam kontrol sahibi olur.

Sık yapılan dört hata

• Demoya bakarak karar vermek. Demo, ürünün en iyi göründüğü senaryodur. Doğru yöntem, kendi gerçek verinizle ve kendi en karmaşık senaryonuzla denemektir.
• Tüm süreçleri aynı anda değiştirmek. Büyük geçişler risk biriktirir. Tek bir süreçle başlayıp ölçmek, sonraki adımların isabetini artırır.
• Kullanıcıyı sürecin dışında bırakmak. Sistemi günlük kullanan kişiler karar sürecine katılmadığında, teknik olarak doğru ama kullanılmayan bir çözüm ortaya çıkar.
• Veri göçünü sona bırakmak. Mevcut verinin ne kadar temiz olduğu, projenin en büyük belirsizliğidir ve en başta ölçülmelidir.

Özetle

Hazır ürün ile özel yazılım arasındaki seçim bir bütçe kararı değil, bir strateji kararıdır. Sizi rakiplerinizden ayırmayan her süreci mümkün olduğunca hazır çözümlere devredin; sizi ayıran süreçlerde ise kontrolü elinizde tutun.

Bu ayrımı netleştirmiş bir kurum, hangi kalemde ne kadar harcayacağını da netleştirmiş olur. YES.Tools olarak kurumlarla çalışırken ilk adım genellikle kod yazmak değil, bu haritayı birlikte çıkarmaktır.

Sık sorulan sorular

Özel yazılım her zaman daha mı pahalıdır?

İlk faturada evet, üç yıllık toplamda her zaman değil. Hazır ürünün karşılamadığı süreçler için harcanan adam-gün, özelleştirme ücretleri ve entegrasyon bakımı hesaba katıldığında iki seçenek çoğu zaman birbirine yaklaşır. Karar, tek bir yılın değil üç yılın tablosuyla verilmelidir.

Küçük bir işletme özel yazılım yaptırmalı mı?

Ölçek tek başına belirleyici değildir; belirleyici olan sürecin ayırt edici olup olmadığıdır. Küçük ama iş modeli kendine özgü bir işletme, büyük ama tamamen standart süreçlerle çalışan bir işletmeden daha çok özel geliştirmeye ihtiyaç duyabilir.

Hazır üründen özel yazılıma geçiş ne kadar sürer?

Belirleyici faktör geliştirme değil veri göçüdür. Mevcut verinin ne kadar temiz ve dışa aktarılabilir olduğu, geçiş süresini geliştirme süresinden daha çok etkiler. Bu yüzden geçiş kararı verilmeden önce veri dışa aktarımının denenmesi önerilir.

Hibrit yapıda veri tutarlılığı nasıl sağlanır?

Her veri alanı için tek bir sistemin "doğduğu yer" olarak tanımlanması ve diğer sistemlerdeki halinin kopya kabul edilmesiyle. Kopya düzeltilmez, kaynak düzeltilir; bu kural tutarsızlıkların büyük bölümünü baştan engeller.