Hazır ürün ile özel yazılım arasındaki gerçek maliyet farkı
Rol ve yetki derinliğinin bütçeye etkisi
Entegrasyon ve veri taşımanın gizli yükü
Önce şu karar: hazır ürün yetiyor mu, gerçekten özel yazılım mı gerekiyor
Özel yazılımın en pahalı hâli, hazır bir ürünün zaten yaptığı işi yeniden yazmaktır.
Muhasebe, e-ticaret altyapısı, temel CRM veya proje takibi gibi standartlaşmış alanlarda olgun ürünler vardır. Bu alanlarda özel geliştirme, yalnızca iş akışınız gerçekten sektör dışı ise veya ürünün kapatamadığı bir darboğaz varsa gerekçelenir.
Özel yazılım şu durumlarda doğru karardır: süreç rekabet avantajınızın parçasıysa, birden çok sistemin arasında hiçbir ürünün karşılamadığı bir köprü gerekiyorsa, ya da hazır ürünün lisans maliyeti kullanıcı sayısıyla birlikte kontrolden çıkıyorsa.
Karma model çoğu zaman en ucuzudur: standart işler hazır üründe kalır, yalnızca ayrışan akış özel yazılıma taşınır ve ikisi API ile konuşur. Teklif isterken bu seçeneğin değerlendirilip değerlendirilmediğini sorun.
- Hazır ürün alternatifi incelendi mi
- Özel geliştirmenin gerekçesi yazılı mı
- Karma model değerlendirildi mi
- Lisans maliyeti 3 yıla yayıldı mı
Maliyeti ekran sayısı değil, rol ve yetki derinliği büyütür
Aynı ekran, üç farklı rol için üç farklı davranış gösteriyorsa üç kez tasarlanmış demektir.
Tek kullanıcılı bir panel ile yönetici, şube sorumlusu, saha personeli ve müşteri rollerinin bulunduğu bir sistem aynı iş değildir. Her rol; ne göreceğini, neyi değiştirebileceğini, hangi onaydan geçeceğini ve hangi kaydı hiç görmeyeceğini ayrı ayrı tanımlar.
Onay akışları özellikle dikkat ister. “Müdür onaylasın” cümlesi; onay bekleyen kayıt durumu, bildirim, vekâlet, reddetme gerekçesi ve geçmiş kaydı anlamına gelir. Bunlar tek bir düğme değil, bir alt sistemdir.
Teklifte rollerin ve her rolün yetkilerinin tablo hâlinde yazılmasını isteyin. Bu tablo hem fiyatı hem teslim süresini en çok açıklayan belgedir.
- Rol listesi ve yetki tablosu
- Onay akışı var mı
- Kayıt geçmişi ve denetim izi
- Rol bazlı raporlama ihtiyacı
Her entegrasyon kendi başına küçük bir proje gibi davranır
Bağlanılacak sistemin dokümante API'si yoksa, önce o API'nin yazılması gerekir.
ERP, muhasebe, e-fatura, ödeme, kargo, SMS ve pazaryeri bağlantılarının her biri ayrı yetkilendirme, ayrı hata durumu ve ayrı test ortamı ister. Bir entegrasyonun “çalışıyor” sayılması için mutlu senaryonun yanı sıra zaman aşımı, çift kayıt ve kısmi başarısızlık durumlarının da ele alınmış olması gerekir.
Karşı sistemin test ortamı sunup sunmadığı süreyi doğrudan etkiler. Test ortamı yoksa doğrulama canlı veriyle yapılır; bu hem yavaştır hem risklidir.
Teklifte entegrasyonların tek tek listelenmesini ve her biri için karşı tarafın hangi erişimi sağlayacağının yazılmasını isteyin. “ERP entegrasyonu dahildir” ifadesi tek başına ölçülebilir bir taahhüt değildir.
- Entegrasyon listesi tek tek yazılı mı
- Karşı sistemin API dokümanı var mı
- Test ortamı sağlanıyor mu
- Hata ve tekrar deneme senaryoları
Mevcut veriyi taşımak çoğu projede ayrı bir kalemdir
Geçmiş kayıtların ne kadarının taşınacağı, temizliğin kimde olduğu kadar önemlidir.
Excel dosyalarında, eski bir programda veya kâğıtta duran müşteri, ürün, stok ve cari kayıtları yeni sisteme kendiliğinden geçmez. Alan eşleştirme, tekrarlayan kayıtların birleştirilmesi, eksik zorunlu alanların tamamlanması ve doğrulama gerekir.
Verinin ne kadar geriye gideceğine baştan karar verin. Çoğu işletme için son iki yıl aktif kullanım, öncesi ise arşiv olarak yeterlidir; tümünü taşımak maliyeti orantısız büyütür.
Temizliğin kimde olduğu yazılı olmalıdır. Kirli veriyi geliştirici temizleyecekse bu ayrı bir iş kalemidir; işletme temizleyecekse takvimde ona da süre ayrılmalıdır.
- Taşınacak veri kaynakları
- Kaç yıl geriye gidilecek
- Temizlik sorumlusu kim
- Taşıma sonrası doğrulama yöntemi
Faz planı hem riski hem toplam maliyeti düşürür
Tek seferde teslim edilen büyük sistem, yanlış varsayımı en pahalı noktada ortaya çıkarır.
İlk faz, günlük operasyonun en çok acıyan tek adımını çözmelidir. O adım canlıda çalışmaya başladığında hem ekip sistemi öğrenir hem de sonraki fazın gerçek ihtiyacı görünür hâle gelir.
Her fazın sonunda çalışan bir sürüm ve o sürümün kabul ölçütü olmalıdır. Ödeme fazlara bağlandığında risk iki tarafa da dengeli dağılır.
Toplam sahip olma maliyetini değerlendirirken geliştirme bedelinin yanına sunucu, yedekleme, bakım ve gelecek yılın geliştirme bütçesini de koyun. Yalnızca teslim gününe bakan karşılaştırma yanıltıcıdır.
- İlk fazın çözdüğü tek problem
- Faz kabul ölçütleri
- Fazlara bağlı ödeme planı
- Yıllık işletim ve bakım bütçesi