Sayfa yükleniyor
Bir ihtiyaç ortaya çıktığında ilk refleks genellikle piyasadaki hazır çözümlere bakmaktır. Bu doğru bir reflekstir: hazır bir paket varsa ve işi görüyorsa, sıfırdan yazılım yazdırmanın anlamı yok.
Ama “işi görüyor mu” sorusu demoda cevaplanmaz. Demolar hazırlanmış senaryoyla, en pürüzsüz akış üzerinden gösterilir. Karar, aşağıdaki beş sorunun cevabından çıkar. Cevaplar aynı yöne bakmıyorsa bu bir çelişki değildir; süreçler farklıysa kararlar da süreç bazında ayrışabilir.
Bordro, ön muhasebe, e-belge işlemleri, temel müşteri kaydı gibi süreçler her firmada aşağı yukarı aynı işler ve büyük ölçüde mevzuata bağlıdır. Bu alanlarda hazır paket çoğunlukla makul karardır; mevzuata bağlı güncellemeleri genellikle ürünü geliştiren taraf üstlenir. Kapsamını sözleşmede teyit edin.
Buna karşılık kalite kontrol akışınız, kalıp ömrü takibiniz veya müşteriye özel etiketleme kurallarınız firmadan firmaya değişir. Bir süreç işi yapış biçiminizin parçasıysa, o biçimi standart bir pakete uydurmak çoğu zaman kayıp yazar.
Hazır yazılımın görünen bedeli lisanstır, görünmeyen bedeli uyumdur. Paket sizin akışınızı desteklemiyorsa iki seçenek kalır: ya süreci pakete uydurursunuz ya da paketi özelleştirirsiniz.
Süreci uydurmak bazen iyidir; yıllardır alışkanlıkla taşınan gereksiz adımlar böyle temizlenir. Ama ürünün desteklemediği yerde insanlar sistemin yanında kendi tablosunu açar. Özelleştirme tarafında ise her sürüm yükseltmesinde aynı özelleştirmelerin yeniden test edilmesi gerekir; bu yük kalıcıdır.
Demoda satıcının hazırladığı senaryoyu değil, kendi en zor senaryonuzu deneyin. İstisnaları gösterin: kısmi sevkiyat, iptal, iade, sonradan değişen sipariş. Bir paket normal akışta değil, istisnada dökülür.
Tek başına çalışan yazılım azdır. Yeni sistem büyük ihtimalle ERP, muhasebe, barkod terminalleri, üretim hattındaki sayaçlar veya e-belge servisleriyle veri alışverişi yapacak. Bunu satın alma kararından sonra konuşmak pahalıya gelir.
Bu sorular cevapsız kalıyorsa bir ürün değil, entegrasyon borcu satın alıyorsunuz demektir.
Özel yazılımın en büyük avantajı sahipliktir. Ama sahiplik sözleşmede yazmıyorsa fiilen yoktur. Kaynak kodun nerede tutulduğu, sizin erişebileceğiniz bir depoda olup olmadığı ve kullanım hakkının kapsamı baştan yazılı olmalıdır.
Sahiplik yalnızca kod değildir. Veritabanı şeması, kurulum adımları, ortam ayarları, yedek alma ve geri dönme yordamı da devredilebilir olmalı. Hazır yazılım tarafında soru şuna dönüşür: sözleşme bittiğinde verinizi hangi biçimde ve ne kadar eksiksiz dışarı alabiliyorsunuz?
Sözleşmeyi imzalamadan önce “ayrılırken ne alıp götürüyorum” sorusunun cevabını yazılı olarak isteyin.
Yazılımın ömrü ilk teslimden sonra başlar. İşletim sistemi güncellenir, veritabanı sürümü yükselir, mevzuat değişir, personel değişir. Bu yükü kimin taşıyacağı en baştan belli olmalıdır.
Hazır yazılımda bakım üreticidedir; karşılığında yol haritasına da üretici karar verir ve sizin talebiniz sıraya girer. Özel yazılımda yön sizdedir; karşılığında sürekliliği güvence altına almak da size düşer. Tek kişiye bağlı ve belgelenmemiş bir özel yazılımda ise maliyeti ve sürekliliği öngörmek en zordur.
Kullanılan teknolojinin yaygınlığı da bu sorunun parçasıdır. Piyasada bilen geliştirici bulunan sıradan bir teknoloji, şık ama nadir bir seçime göre yıllar içinde geliştirici bulmayı ve bakımı kolaylaştırır.
Beş soruyu havada tartışmak yerine bir tablo kurun. Satırlara süreçleri yazın; sütunlara ayırt edicilik, uyum maliyeti, entegrasyon sayısı, sahiplik kritikliği ve bakım sorumlusu gelsin. Tablo dolduğunda karar çoğu zaman kendini gösterir.
Yaygın kurgulardan biri ikili yapıdır: standart alanlarda hazır paket, ayırt edici süreçlerde ona bağlanan özel modüller. Böyle bir kurguda asıl kritik olan, iki tarafın sınırının ve veri akış yönünün net çizilmesidir.
Ücretsiz bir değerlendirmeyle başlıyoruz. Mevcut durumunuzu çıkarıyor, riskleri ve eksikleri önceliklendirilmiş bir yol haritası halinde sunuyoruz.
Ücretsiz değerlendirme
