Hazır paket mi, özel yazılım mı? Karar vermek için 6 soru
Hazır paket mi alınmalı, özel yazılım mı yaptırılmalı? Süreç, uyarlama, bakım ve gerçek maliyet üzerinden kararı netleştiren 6 soru.
Bir süreç Excel'e, e-postaya ya da elle girilen kayıtlara sıkıştığında iki yol görünür: piyasadaki hazır bir paketi almak ya da işe özel bir yazılım yaptırmak. Bu yazıda kararı kolaylaştıran altı soruyu ve iki yolun gözden kaçan maliyetlerini bulacaksınız.
Önce ayrım: destek işi mi, fark yaratan iş mi
Martin Fowler bu soruya iş fonksiyonları üzerinden bakmayı öneriyor. Muhasebe, bordro, izin takibi gibi her şirkette benzer yürüyen işler "fayda" (utility) türündendir. Sizi rakiplerinizden ayıran işler ise "stratejik"tir. Fowler'a göre ilk grupta hazır paketi alıp süreci yazılıma uydurmak, ağır uyarlamaya girmekten daha akıllıcadır. Stratejik işlerde ise rakiplerinizle aynı yazılımı kullanmak farklılaşmanızı zorlaştırır[1].
Fowler'ın uyarısı önemli: Stratejik işler azınlıktadır. Ona göre burada 80/20 kuralı 95/5'e daha yakın olabilir[1]. Yani "her şeyi özel yazdıralım" çoğu zaman doğru cevap değildir.
Karar vermek için 6 soru
- Bu süreç sizi rakiplerinizden ayırıyor mu? Müşteriniz sizi bu süreç sayesinde tercih ediyorsa, örneğin teklifi rakiplerden hızlı veriyor ya da siparişi daha esnek karşılıyorsanız, özel yazılım anlam kazanır. Ayırmıyorsa hazır paket genelde yeterlidir.
- Hazır paket ihtiyacın ne kadarını karşılıyor? Eksik kalan kısım için süreci pakete uydurmaya razıysanız paket ekonomik kalır. Eksikleri kapatmak için kapsamlı uyarlama gerekiyorsa hesap değişir. Gregor Hohpe, paket alan şirketin karmaşık bir ürünün uyarlama ve yapılandırmasına da para ödediğini, bunun için yüksek ücretli dış danışmanlara başvurulabildiğini hatırlatıyor[2].
- Süreç ne sık değişiyor? Gartner'ın katmanlı uygulama stratejisi, sistemlerin farklı hızlarda değiştiğini kabul eder. Thoughtworks ise değişim hızını yazılım katmanlarına göre değil iş yeteneklerine göre düşünmeyi öneriyor[3]. Kuralları her çeyrekte değişen bir fiyatlandırma ya da onay akışı, sizin hızınızda değişebilen bir yazılım ister. Yıllardır aynı kalan bir iş için bu esneklik gereksizdir.
- Hangi sistemlerle konuşması gerekiyor? Yeni yazılım ERP'nizle, e-ticaret sitenizle ya da bankanızla veri alışverişi yapacaksa, paketin bu bağlantıları hazır sunup sunmadığına bakın. Bağlantı yoksa veri yine elle taşınır ve kazanç azalır.
- Yazılıma kim bakacak? Özel yazılım teslim edildiği gün bitmez. Fowler, düşük iç kaliteli kodun geliştiricileri birkaç hafta içinde belirgin şekilde yavaşlattığını yazıyor[4]. Hohpe de şirket içinde yazılan sistemlerin, teknik borç biriktikçe ticari bir ürün kadar bağımlılık yaratabileceğini söylüyor[2]. Test, bakım ve sürüm planı baştan konuşulmalı.
- Gerçek maliyet ne? Paket tarafında lisans, uyarlama ve danışmanlık; özel yazılım tarafında geliştirme, bakım ve ekibin başka işlere ayıramadığı zaman. Hohpe'ye göre işiniz ve BT ekibiniz iyi çalışıyorsa, geliştiricileri başka bir işe ayırmanın fırsat maliyeti doğrudan maliyetin birkaç katı olmalıdır[2].
Çoğu zaman cevap ikisi birden
Karar genellikle "ya o ya bu" değildir. Muhasebe ve stok gibi ortak işler hazır ERP'de kalır. Sizi farklı kılan teklif, saha ya da onay süreci için küçük bir özel uygulama yazılır ve ERP'ye bağlanır. Örnek senaryo: Bir toptancı muhasebeyi mevcut ERP'sinde yürütür, bayilere özel fiyat ve iskonto kurallarını ise ERP'den müşteri ve stok verisini çeken ayrı bir web uygulamasında yönetir.
Şirketiniz için ne anlama geliyor?
- Süreçlerinizi "herkeste benzer" ve "bizi ayıran" diye iki listeye ayırın. İkinci liste kısa olmalı.
- Hazır paketi değerlendirirken eksik kalan kısmı yazın ve bu kısım için süreci değiştirmeye razı olup olmadığınızı netleştirin.
- Maliyeti yalnızca ilk yıl için değil, birkaç yıllık bakım ve güncellemeyi de katarak karşılaştırın.
- Özel yazılıma karar verirseniz tek bir süreçle ve sınırları belli bir ilk sürümle başlayın.
- Yeni yazılımın mevcut ERP'nizle nasıl veri alışverişi yapacağını kapsamın ilk maddesi yapın.
Hazır paketin yetmediği bir süreciniz varsa özel yazılım hizmetimize göz atın.
Kaynaklar
- Martin Fowler, "Utility Vs Strategic Dichotomy", 29 Temmuz 2010 (güncelleme: 7 Nisan 2016). martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
- Gregor Hohpe, "Revisiting Buy vs. Build: 3 Traps to Avoid", AWS Enterprise Strategy Blog, 29 Temmuz 2020. aws.amazon.com/blogs/enterprise-strategy
- Thoughtworks Technology Radar, "Pace-layered Application Strategy", Temmuz 2014 (son güncelleme: 10 Kasım 2015). thoughtworks.com/radar/techniques/pace-layered-application-strategy
- Martin Fowler, "Is High Quality Software Worth the Cost?", 29 Mayıs 2019. martinfowler.com/articles/is-quality-worth-cost.html