Özel Yazılım Geliştirmek mi Hazır ERP Almak mı: Karar Çerçevesi

Orta ölçekli bir tekstil ihracatçısının BT sorumlusu, konsinye stok takibini hiçbir hazır ERP'nin doğru modelleyemediğini fark ettiğinde beş yıl önce basit bir Excel makrosuyla başlamıştı. Makro zamanla bir web uygulamasına, sonra tam bir stok ve sipariş yönetim sistemine dönüştü; şirket içindeki bir geliştirici bu sistemi tek başına büyüttü ve firma yıllarca hazır bir ERP'ye ödeyeceği lisans bedelinden tasarruf ettiğini düşündü. Geliştirici işten ayrıldığında ortaya çıkan tablo farklıydı: belgelenmemiş bir kod tabanı, tek kişinin kafasında duran iş mantığı ve yeni bir geliştirici bulup sistemi öğretmenin aylar alacağı bir risk. Bu senaryo, özel yazılım geliştirmek ile hazır ERP satın almak arasındaki kararın neden yalnızca ilk maliyet karşılaştırmasından ibaret olmadığını gösteriyor.

Bu soru neden masaya geliyor

Özel yazılım geliştirme fikri genelde üç durumda gündeme geliyor. Birincisi, işletmenin süreci gerçekten benzersiz: konsinye satış, özel üretim reçeteleri veya sektöre özgü bir fiyatlandırma mantığı gibi hiçbir paket yazılımın standart modülüyle tam örtüşmeyen bir iş akışı var. İkincisi, firma daha önce bir ERP projesinde ağır özelleştirme yaptırmış ve her güncellemede bu özelleştirmelerin bozulmasından yorulmuş; "madem her seferinde yeniden yazdırıyoruz, baştan kendimiz yazalım" mantığı devreye giriyor. Üçüncüsü, şirket içinde zaten bir yazılım ekibi var ve bu ekibin kapasitesini değerlendirmek cazip görünüyor. Üç gerekçe de meşru bir başlangıç noktası, ama üçü de kararın yalnızca ilk aşaması; asıl fark beş-on yıllık ufukta ortaya çıkıyor.

Özel yazılımın maliyeti nerede saklanıyor

Özel yazılımın en görünür maliyeti geliştirme ekibinin maaş bordrosu, ama gerçek yük çoğunlukla başka bir yerde birikiyor. Bir geliştiricinin veya küçük bir ekibin sistemi tek başına anlaması, o kişi ayrıldığında kurumsal hafızanın da onunla gitmesi anlamına geliyor; hazır bir ERP'de bu bilgi vendor'un dokümantasyonuna ve destek ekibine dağılmış durumda kalırken, özel yazılımda çoğu zaman tek bir kafada toplanıyor. E-fatura ve e-defter gibi mevzuat entegrasyonlarının her değişiklikte yeniden kodlanması, güvenlik yamalarının kimse tarafından sistematik takip edilmemesi, yeni bir personel işe alındığında sistemi öğretecek hazır bir kaynağın bulunmaması gibi kalemler zamanla toplam maliyeti hazır bir çözümün üzerine taşıyabiliyor. ERP'nin gizli maliyet kalemleri rehberimizde hazır ERP tarafında da benzer gizli kalemlerin nasıl ortaya çıktığını ele aldık; özel yazılımda bu kalemlerin bir kısmı ortadan kalkıyor ama yerine personel bağımlılığı ve fırsat maliyeti giriyor.

Hazır ERP'nin esneklik sınırı

Hazır ERP tarafının da kendi riski var: standart modüller işin büyük kısmını karşılasa da geri kalan kısım için iki yol açık — süreci yazılıma uydurmak ya da yazılımı sürece uydurmak. İkinci yol, yani ağır özelleştirme, kısa vadede tatmin edici görünse de her sürüm güncellemesinde yeniden test edilmesi gereken bir teknik borç biriktiriyor; ERP özelleştirme riski yazımızda bu tuzağın nasıl işlediğini ayrıntılı ele aldık. Buradaki asıl ayrım özel yazılım ile hazır ERP arasında değil, hazır ERP'yi standart bırakıp süreci ona uydurmakla, onu sürece uydurup fiilen yarı özel bir yazılıma dönüştürmek arasında kuruluyor. İkinci seçenek genelde ilk yatırımı düşük gösterip toplam maliyeti gizliyor.

Ara yol: açık kaynak ve modüler mimari

İki uç arasında üçüncü bir seçenek büyüyor: açık kaynaklı veya modüler (composable) mimarili platformlar üzerine kurulu yarı özel çözümler. Odoo Enterprise gibi açık kaynak kökenli bir platform çekirdek modülleri hazır kullanırken, sektöre özgü kısmı özel bir modülle tamamlamaya izin veriyor; bu, sıfırdan yazmaktan daha az geliştirme yükü, saf hazır ERP'den daha fazla esneklik anlamına geliyor. Açık kaynak mı ticari lisanslı ERP mi karşılaştırmamızda bu iki dünyanın hangi kriterlerde ayrıştığını işledik; modüler mimari (composable ERP) yazımızda ise büyük yapıların bu ara yolu nasıl kullandığını ele aldık. Ara yolun bedeli de var: açık kaynak platformun kendi güncelleme döngüsünü takip etmek ve özel modülü her sürümde uyumlu tutmak yine bir mühendislik kapasitesi gerektiriyor — bedelsiz bir seçenek değil, sadece farklı dağılımlı bir bedel.

Sık yapılan yanılgı: "lisans ödememek" aslında tasarruf değil

Özel yazılımı savunan en yaygın argüman "vendor'a her yıl lisans bedeli ödemiyoruz" cümlesi. Bu cümle muhasebe açısından yanıltıcı, çünkü lisans bedelinin yerini geliştirici maaşları, sosyal haklar, donanım ve barındırma giderleri, bir de en görünmez kalem olan fırsat maliyeti alıyor. Şirket içi geliştirici ekibi ERP benzeri bir sistemi bakımda tutarken, aynı ekip firmanın asıl ürününü geliştirmiyor ya da müşteriye dönük bir projeye zaman ayırmıyor demektir. Bir yazılım firması için bu maliyet daha kolay görülebilir çünkü zaten mühendislik kapasitesini ölçüyorlar; ama üretim, dağıtım veya hizmet sektöründeki bir firma için bu fırsat maliyeti genelde hiç hesaba katılmıyor ve karar yalnızca "lisans bedeli var mı yok mu" sorusuna indirgeniyor. Doğru karşılaştırma, iki tarafın da beş yıllık nakit çıkışını ve ekip zamanının alternatif kullanım değerini aynı tabloya koymayı gerektiriyor.

Karar tablosu: üç yolun kriter bazında karşılaştırması

Hangi işletme profili hangi yolu seçmeli

Süreçlerinin gerçekten büyük bir kısmı sektöre özgü olan, uzun vadeli bir yazılım ekibini elinde tutabilecek ve beş yıldan uzun bir ufukta düşünen firmalar için özel yazılım savunulabilir bir seçim. Standart bir muhasebe, stok ve satış akışı olan, hızlı devreye alma isteyen çoğunluk firma için hazır ERP daha düşük riskli kalıyor. Yazılım sektöründeki firmalar kendi ürünlerini geliştirdikleri için iç yazılım kapasitesine zaten sahip olabiliyor, bu da özel yazılım seçeneğini görece ucuzlatıyor; buna karşılık üretim firmalarında MRP, üretim planlama ve saha verisi entegrasyonunun karmaşıklığı genelde hazır bir ERP'nin üzerine inşa edilmiş yıllarca test edilmiş mantığı gerektiriyor. Hazır ERP tarafında da ölçek ve mimariye göre çok farklı seçenekler var; örneğin Birasyo ve Qera gibi yerli çözümler ile SAP Business One gibi uluslararası bir platform aynı karar çerçevesinde farklı fiyat ve mimari segmentlerini temsil ediyor; hiçbiri diğerinden otomatik olarak daha doğru değil, karar firmanın profiline bağlı.

Karar sürecine nasıl başlanır

Karara netlik kazandırmanın ilk adımı, "benzersiz" denilen sürecin gerçekten ne kadarının benzersiz olduğunu ölçmek. Sık karşılaşılan durum, iş akışının yüzde 70-80'inin standart olduğu ama bir-iki özel adımın tüm süreci "hazır yazılıma uymuyor" gibi gösterdiği bir tablo. Bu oranı netleştirdikten sonra iki paralel teklif almak faydalı oluyor: en az iki hazır ERP vendor'ından uygulama süresi ve fiyat teklifi, aynı zamanda iç ekipten veya dış bir yazılım firmasından özel geliştirme için kabaca bir süre ve bütçe tahmini. Karşılaştırma ilk yıl maliyetiyle değil, beş yıllık toplam sahip olma maliyetiyle yapılmalı; lisanslama modelinin kendisi de bu tabloyu etkiliyor, bulut/SaaS ERP karşılaştırmamızda abonelik ile kalıcı lisans arasındaki farkın toplam maliyete nasıl yansıdığını ayrıca ele aldık.

Karar verildikten sonra da süreç bitmiyor; özel yazılımı seçen firmalar için belgeleme ve en az iki kişinin sistemi bakımda tutabilmesi bir zorunluluk haline gelmeli, aksi halde beş yıl önceki tekstil ihracatçısı örneğindeki tek-kişi bağımlılığı tekrar eder. Hazır ERP'yi seçen firmalar için ise özelleştirme taleplerinin hangi eşikte "ret" edileceğinin baştan netleşmesi, projeyi zamanla yarı özel bir yazılıma dönüştürme riskini sınırlıyor. Kendi sürecini bu çerçeveden geçirmek isteyen firmalar keşif görüşmesi talep edebilir; farklı ölçekteki hazır ERP adaylarını karşılaştırmak isteyenler uygun ERP bul aracını kullanabilir.