Hazır bir yazılım, işletmenin ihtiyacını yeterince karşılıyorsa sıfırdan yazılım geliştirmek çoğu zaman gereksizdir. Ancak iş süreçleri hazır ürünün sınırlarına takılıyor, sürekli manuel müdahale gerekiyor veya kullanılan sistemler birbiriyle sağlıklı biçimde çalışmıyorsa özel yazılım daha doğru bir yatırım hâline gelebilir.
Karar verirken yalnızca “özel yazılım mı, hazır yazılım mı?” sorusuna bakmak yetmez. Asıl mesele, yazılımın işletmenin mevcut süreçlerine ne kadar uyduğu, büyüdükçe nasıl davranacağı ve birkaç yıllık kullanım boyunca ne kadar maliyet çıkaracağıdır.
Hazır yazılım ile özel yazılım arasındaki temel fark
Hazır yazılım belirli bir kullanıcı kitlesinin ortak ihtiyaçları düşünülerek geliştirilir. CRM, muhasebe, proje yönetimi, e-ticaret veya insan kaynakları uygulamalarının büyük bölümü bu modelle çalışır. İşletme ürünü satın alır ya da abonelik başlatır ve sunulan özellikleri kullanmaya başlar.
Bu yaklaşımın en güçlü tarafı hızdır. Ürün zaten hazırdır; kurulum, veri aktarımı ve temel yapılandırmanın ardından kullanılabilir. Başlangıç maliyeti de özel geliştirmeye kıyasla çoğu durumda daha öngörülebilir olur.
Fakat işletmenin çalışma biçimi ürünün öngördüğü yapıya uymadığında tablo değişir. Kullanıcılar yazılıma uyum sağlamak için süreçlerini değiştirmeye, Excel dosyalarıyla açık kapatmaya veya aynı veriyi farklı sistemlere tekrar tekrar girmeye başlayabilir.
Özel yazılımda hareket noktası ürün değil, iş sürecidir. Siparişin nasıl alındığı, hangi aşamalardan geçtiği, kimlerin onay verdiği, hangi verilerin tutulduğu, hangi sistemlerden bilgi geldiği ve hangi raporların gerektiği incelenir. Yazılım bu yapıya göre tasarlanır.
Bu esneklik değerli olsa da bedelsiz değildir. Analiz, tasarım, geliştirme, test, devreye alma ve bakım için kaynak gerekir. Bu nedenle özel geliştirme, sırf daha fazla özellik isteyen işletmeler için değil; standart ürünlerin karşılayamadığı anlamlı bir iş ihtiyacı bulunan projeler için mantıklıdır.
Özel yazılım geliştirme ihtiyaç analiziyle başlar
Kod yazmak sürecin ilk adımı değildir. İlk iş, gerçekten neyin çözülmesi gerektiğini belirlemektir.
Örneğin bir işletme “özel CRM istiyoruz” diyebilir. Yapılan analiz sonunda asıl problemin CRM eksikliği değil; tekliflerin farklı dosyalarda hazırlanması, satış ekibiyle operasyon ekibi arasında veri kopukluğu yaşanması veya kullanılan ERP sisteminden güncel müşteri bilgilerinin alınamaması olduğu görülebilir.
Böyle bir durumda yeni bir CRM geliştirmek yerine mevcut sistemleri entegre etmek daha doğru olabilir.
İhtiyaç analizi sırasında genellikle şu soruların cevabı aranır:
-
Mevcut süreç nasıl çalışıyor?
-
Kullanıcılar hangi işlemleri manuel yapıyor?
-
En fazla zaman veya hata hangi aşamada oluşuyor?
-
Hangi kullanıcıların hangi yetkilere ihtiyacı var?
-
Mevcut ERP, CRM, muhasebe veya diğer sistemlerle entegrasyon gerekiyor mu?
-
Hangi veriler tutulacak ve hangi raporlar üretilecek?
-
Kullanıcı veya işlem hacmi ileride ne kadar büyüyebilir?
-
İlk sürümde gerçekten hangi özelliklere ihtiyaç var?
Bu çalışma proje kapsamını belirler. Kapsam net değilse geliştirme sırasında sürekli yeni talepler ortaya çıkar; süre ve bütçe de doğal olarak değişir.
Piasoft da proje yaklaşımında süreci ihtiyaç analiziyle başlatıyor, ardından kapsam, teknik yapı ve takvimi planlıyor.
Her ihtiyaç ilk sürüme girmek zorunda değil
Özel yazılım projelerinde sık yapılan hatalardan biri, akla gelen bütün özellikleri ilk sürüme yerleştirmeye çalışmaktır.
Bir işletmenin müşteri yönetimi, teklif hazırlama, sipariş takibi, stok entegrasyonu, gelişmiş raporlama, mobil uygulama, bildirim sistemi ve onlarca farklı yetkilendirme talebi olabilir. Bunların tamamını tek seferde geliştirmek projenin değerini otomatik olarak artırmaz.
Daha sağlıklı yöntem, işin çalışması için gerekli çekirdek fonksiyonları ayırmaktır.
İlk sürüm kullanıma açıldığında gerçek kullanıcı davranışları görülür. Hangi fonksiyonların gerçekten kullanıldığı, hangi ekranların sorun çıkardığı ve hangi yeni ihtiyaçların ortaya çıktığı daha somut biçimde anlaşılır. Sonraki geliştirmeler tahminlere değil, gerçek kullanıma dayanabilir.
Teknik planlama yalnızca hangi programlama dilinin kullanılacağı değildir
İhtiyaçlar belirlendikten sonra yazılımın nasıl kurulacağı planlanır.
Veri yapısı, kullanıcı yetkileri, entegrasyonlar, güvenlik gereksinimleri, yedekleme yaklaşımı, sunucu altyapısı ve ileride eklenmesi muhtemel fonksiyonlar bu aşamada değerlendirilir.
Buradaki kararların etkisi çoğu zaman yıllar sonra ortaya çıkar. İlk kullanıcı sayısı düşük olduğu için sorunsuz çalışan bir sistem, işlem hacmi büyüdüğünde yavaşlayabilir. Başlangıçta düşünülmeyen bir entegrasyon daha sonra yapılmak istendiğinde mevcut yapı buna izin vermeyebilir.
“Şimdilik çalışıyor” bu yüzden iyi bir teknik hedef değildir.
Öte yandan her projeyi gelecekte milyonlarca kullanıcı gelecekmiş gibi tasarlamak da maliyeti gereksiz yere yükseltir. Mimari, gerçekçi büyüme beklentisine göre kurulmalıdır.
Tasarım ile geliştirme birbirinden kopuk ilerlememeli
Kurumsal yazılımlarda tasarım yalnızca ekranların nasıl göründüğüyle ilgili değildir.
Bir depo çalışanının sipariş ekranında görmek istediği bilgiyle yöneticinin görmek istediği bilgi aynı olmayabilir. Muhasebe ekibinin her gün onlarca kez yaptığı bir işlem üç ekrana dağıtılmışsa görsel olarak temiz bir arayüz bile kötü bir kullanıcı deneyimi yaratabilir.
Bu nedenle ekranlar iş akışına göre tasarlanır. Kullanıcının hangi sırayla işlem yaptığı, hangi bilgiyi hangi aşamada gördüğü, hangi işlemlerin sık tekrarlandığı ve hata yapıldığında sistemin nasıl davranacağı geliştirme sürecini doğrudan etkiler.
Ardından yazılım fonksiyonları oluşturulur, veri tabanı bağlantıları kurulur ve gerekiyorsa diğer sistemlerle entegrasyonlar geliştirilir.
Test, “sayfa açılıyor mu?” kontrolünden daha fazlasıdır
Bir fonksiyonun geliştirici bilgisayarında çalışması, üretim ortamında sorunsuz çalışacağı anlamına gelmez.
Yetkisiz bir kullanıcının erişmemesi gereken veriyi görüp göremediği, aynı işlemin art arda yapılması durumunda ne olduğu, hatalı veri girildiğinde sistemin nasıl tepki verdiği, entegrasyon servislerinden biri cevap vermediğinde sürecin nasıl devam ettiği gibi durumların da denenmesi gerekir.
Gerçek kullanıcı testleri ayrıca değerlidir. Geliştirme ekibine açık görünen bir işlem, sistemi ilk kez kullanan çalışan için kafa karıştırıcı olabilir.
Kritik sorunlar giderildikten sonra sistem kontrollü biçimde yayına alınır. Eski bir sistemden geçiş yapılıyorsa veri aktarımı, kullanıcı hesapları ve operasyonun kesintiye uğramaması ayrıca planlanır.
Yazılım yayına çıktığında proje tamamen bitmez
İşletmenin süreçleri değişir. Yeni çalışanlar gelir, mevzuat veya operasyon ihtiyaçları değişebilir, başka sistemlerle entegrasyon gerekebilir. Kullanılan teknolojiler de güncellenir.
Bu nedenle bakım maliyetini ilk yatırım maliyetinden ayrı düşünmek yanıltıcıdır.
Bakım kapsamında hataların giderilmesi, güvenlik ve altyapı güncellemeleri, performans kontrolleri, yedekleme süreçleri ve ihtiyaç hâlinde yeni geliştirmeler bulunabilir. Hizmetin kapsamı projeye ve yapılan anlaşmaya göre değişir.
Piasoft, geliştirdiği projelerde yayın sonrasını da bakım ve teknik destek sürecinin parçası olarak ele alıyor. Şirketin [bakım ve destek hizmetleri]bakım ve destek hizmetleri sayfasında bu süreçle ilgili ayrıntılar yer alıyor.
Maliyet karşılaştırmasını satın alma fiyatıyla sınırlamayın
Hazır yazılım ilk bakışta daha ucuz görünebilir. Kullanıcı başına aylık veya yıllık ücret ödenir ve geliştirme yatırımı yapılmaz.
Fakat kullanıcı sayısı arttıkça lisans giderleri büyüyebilir. Ek modüller, entegrasyonlar veya yüksek kullanım paketleri ayrıca ücretlendirilebilir. İşletmenin yazılıma uymayan süreçlerini manuel yürütmesi de doğrudan faturada görünmeyen bir maliyet yaratır.
Özel yazılımda ise başlangıç yatırımı genellikle daha yüksektir. Buna karşılık lisans modeline bağlı olmayan, süreçlere göre şekillenmiş bir sistem kurulabilir. Yine de sunucu, bakım, destek ve yeni geliştirme giderleri devam eder.
Bu nedenle karşılaştırılması gereken rakam yalnızca ilk teklif değildir. Toplam sahip olma maliyetine bakmak gerekir.
Örneğin üç veya beş yıllık bir değerlendirmede şu kalemler birlikte ele alınabilir:
-
lisans ve abonelik ücretleri,
-
ilk geliştirme veya kurulum maliyeti,
-
entegrasyon giderleri,
-
veri aktarımı,
-
bakım ve teknik destek,
-
yeni özellik geliştirmeleri,
-
altyapı ve barındırma giderleri,
-
yazılımın karşılayamadığı işler nedeniyle oluşan manuel operasyon yükü.
Bazen hazır ürün açık biçimde daha ekonomik çıkar. Bazen birkaç yıl boyunca ödenen lisanslar, ek modüller ve operasyonel kayıplar özel geliştirmeyi daha anlamlı hâle getirir. Tek bir cevap yoktur.
Hazır yazılım ne zaman daha mantıklı?
İşletmenin ihtiyacı piyasadaki olgun ürünlerle büyük ölçüde karşılanıyorsa hazır çözüm ciddi bir adaydır.
Özellikle standartlaşmış süreçlerde sıfırdan geliştirme için güçlü bir neden bulunmayabilir. Kullanıcıların ihtiyacı belli, özelleştirme beklentisi sınırlı ve hızlı devreye alma önemliyse hazır ürün daha düşük riskle kullanılmaya başlanabilir.
Burada kritik soru şudur: İşletme yazılıma mı uyum sağlayacak, yoksa yazılım işletmeye mi?
Süreçleri değiştirmek sorun yaratmıyorsa hazır ürünün sınırları kabul edilebilir. Fakat işletmenin rekabet gücü tam olarak kendine özgü operasyon biçiminden geliyorsa süreçleri standart bir yazılıma uydurmak pahalı bir taviz olabilir.
Özel yazılım ne zaman anlamlı hâle gelir?
Özel geliştirme ihtiyacı genellikle birkaç belirgin durumda ortaya çıkar.
İşletmenin operasyonu piyasadaki ürünlerin karşılamadığı özgün iş akışlarına sahipse, çalışanlar farklı sistemler arasında sürekli veri taşıyorsa, mevcut uygulamalar yoğun manuel işlem gerektiriyorsa veya şirket için kritik sistemlerin doğrudan birbiriyle konuşması gerekiyorsa özel çözüm değerlendirmeye değer.
Ölçek de kararı değiştirebilir. Bugün birkaç kişinin yönettiği süreç, işletme büyüdüğünde yüzlerce kullanıcıya veya çok daha yüksek işlem hacmine ulaşacaksa geçici çözümler pahalılaşabilir.
Burada özel yazılımın otomatik olarak daha iyi olduğu düşünülmemeli. İyi analiz edilmemiş özel bir yazılım, olgun bir hazır üründen çok daha pahalı ve sorunlu olabilir.
Hibrit çözüm de bir seçenek
Karar her zaman iki uçtan birini seçmek zorunda değildir.
İşletme standart ihtiyaçları için hazır bir ERP veya CRM kullanıp kendine özgü operasyonlarını yöneten özel bir uygulama geliştirebilir. Özel yazılım, hazır sistemlerle API veya farklı entegrasyon yöntemleri üzerinden veri alışverişi yapabilir.
Çoğu projede en ekonomik yaklaşım da budur: Piyasada zaten iyi çözülen problemi yeniden geliştirmemek, işletmeye özgü ve gerçek değer üreten bölümlere geliştirme bütçesi ayırmak.
Piasoft’un [web yazılım çözümleri]web yazılım çözümleri kapsamında kuruma özel paneller, süreç otomasyonları, veri yönetimi ve ERP/CRM entegrasyonları geliştirdiği belirtiliyor.
Bir işletmenin doğru teknoloji kararı, hazır veya özel çözüm etiketinden önce ihtiyacın doğru tanımlanmasına bağlıdır. Süreç basitse hazır ürün fazlasıyla yeterli olabilir. Standart çözümler operasyonu zorlaştırmaya başladıysa özel geliştirme veya hibrit bir yapı daha uygun olabilir.
Piasoft, mevcut iş süreçlerini ve teknik altyapıyı analiz ederek hazır bir çözümün yeterli olup olmadığını, entegrasyonla sorunun çözülüp çözülemeyeceğini veya özel yazılım geliştirilmesi gerekip gerekmediğini değerlendirebilir. Amaç mümkün olan en fazla yazılımı geliştirmek değil, işletmenin bugün kullanabileceği ve büyüdüğünde değiştirmek zorunda kalmayacağı doğru yapıyı kurmaktır.