Özel Yazılım mı Hazır Paket mi? Toplam Sahip Olma Maliyetiyle Karar Vermek

Karar masaya genellikle iki teklifle gelir. Birincisi aylık bir abonelik rakamı, ikincisi tek seferlik bir geliştirme bedeli. İlk bakışta karşılaştırma kolay görünür: biri küçük bir sayı, diğeri büyük bir sayı. Sözleşme de çoğu zaman bu iki sayıya bakılarak imzalanır.

Oysa yazılım, alındığı gün değil kullanıldığı yıllar boyunca ödenir. Abonelik kullanıcı sayısıyla büyür, uyarlama talepleri ayrı fiyatlanır, entegrasyon her iki tarafta da iş çıkarır, ekip değiştikçe eğitim tekrarlanır ve bir gün sistemden çıkmak istediğinizde verinizi almanın da bir bedeli olduğunu görürsünüz.

Bu yazıda özel yazılım mı hazır paket mi sorusunu, ilk faturaya değil beş yıllık toplam sahip olma maliyetine bakarak ele alıyoruz. Kalem kalem bir karşılaştırma tablosu, bir karar tablosu ve sahadan iki gerçek durum var.

Neden ilk fatura yanıltır?

Hazır paketin ilk faturası küçüktür çünkü geliştirme maliyeti çok sayıda müşteriye bölünmüştür. Özel yazılımın ilk faturası büyüktür çünkü o maliyeti tek başınıza karşılarsınız. Buraya kadar her şey açık.

Yanılgı, ikinci yıldan sonra başlar. Hazır pakette maliyet kullanımla birlikte büyür: kullanıcı eklenir, modül açılır, yıllık zam gelir, standart dışı her ihtiyaç ayrıca fiyatlanır. Özel yazılımda ise ilk yıldan sonraki maliyet büyük ölçüde bakım ve yeni geliştirme kalemine iner; kullanıcı eklemek ek lisans doğurmaz.

Bu iki eğri bir yerde kesişir. Kesişme noktasının nerede olduğunu belirleyen şey ürünün fiyatı değil, sizin süreçlerinizin sektör standardından ne kadar saptığıdır. Sapma büyüdükçe hazır paketin uyarlama maliyeti büyür ve kesişme öne gelir.

Beş yıllık toplam sahip olma maliyeti: kalem kalem

Aşağıdaki tabloda rakam yok, çünkü her firmanın ölçüsü farklıdır ve uydurma bir sayı kararı iyileştirmez. Onun yerine her kalemin nasıl davrandığını yazdık. Kendi tekliflerinizi bu satırların üzerine oturtun; eksik kalan satır, sözleşmeden sonra karşınıza çıkacak olan satırdır.

Tabloyu doldururken en çok atlanan iki satır çıkış maliyeti ve kullanıcı artışıdır. Çıkış maliyeti sözleşme aşamasında sorulmadığı için görünmez; verinizi hangi biçimde, hangi kapsamda ve ne kadar sürede alabileceğinizi yazılı olarak isteyin. Kullanıcı artışı ise büyüyen firmalarda beş yılda toplam maliyetin en hızlı büyüyen bileşeni hâline gelir.

Hangi durumda hangisi? Karar tablosu

Aşağıdaki altı soruyu sırayla yanıtlayın. Bir soruda "özel yazılım" tarafına düştüyseniz, alt sorular kararı yalnız güçlendirir; ilk üç soruda hazır paket tarafında kaldıysanız, aramanız gereken şey bir sektörel çözümdür.

Üçüncü soru, tablodaki en belirleyici satırdır. Fiyatlama veya üretim mantığınız rakiplerinizle aynıysa, onu geliştirmek için para harcamanın anlamı yoktur. Ama o mantık sizi rakiplerinizden ayıran şeyse, onu bir başkasının ayar ekranına sığdırmaya çalışmak, avantajınızı standarda düşürmek demektir.

Sahadan örnek: sektörel bir çözüm nasıl doğdu?

LazerCRM, tam olarak bu ikilemin ortasından çıktı. Fason lazer kesim, büküm ve kaynaklı imalat yapan atölyelerde teklif hazırlamak 20-45 dakika sürüyordu: parça listesi elle Excel'e giriliyor, fiyat hafızadan veriliyor, teklif ayrı bir belgede yazılıyordu.

Genel amaçlı bir CRM bu işi yapamıyordu, çünkü orada fiyat tek bir alandır. Burada ise fiyat; malzeme cinsine, kalınlığa, işlem türüne ve tezgâhın dakika maliyetine bağlı bir hesaptır. Yani sorun modül eksikliği değil, fiyatın veri modelindeki yeriydi.

Yapılan iş karmaşık değildi: kesim fiyat matrisi ve tezgâh maliyetleri bir kez tanımlandı; atölyenin hâlihazırda ürettiği parça listesi raporu dosyadan toplu olarak sisteme alınabilir hâle geldi. Aynı teklif artık 5-10 dakikada hazırlanıyor ve onaylandığında iş emrine tek adımda dönüşüyor.

Buradaki asıl ders şudur: aynı işi yapan çok sayıda atölye olduğu için bu ihtiyaç sektörel bir çözüme dönüşebildi. Bir ihtiyaç yeterince çok firmada tekrarlanıyorsa, o ihtiyacın hazır bir karşılığı er ya da geç doğar. Sizin sorunuz da bu: benim derdim yalnız bana mı özgü, yoksa sektörün ortak derdi mi?

Sahadan örnek: özel yazılım gerektiren bir kur mantığı

Lunasan tarafında durum tersiydi. İşletmenin sermayesi farklı tarihlerde ve farklı kurlardan konulmuştu; üretim fason atölyelere yaptırılıyor, satışın önemli bölümü vadeli ve çekle dönüyordu. Kârı yalnız TL üzerinden okumak yanıltıcıydı: kur artışı büyüme gibi görünüyordu.

Çözümün çekirdeğine tek bir kural konuldu: her kayıt hem ₺ hem de işlem günündeki kurdan $ karşılığıyla saklanır; tutar ile kur birlikte tutulur. Kur sonradan güncellendiğinde geçmiş kayıtlar yeniden yazılmaz, her hareket kendi gününün kurunu taşır.

Bu bir rapor tercihi değil, veri modelinin kendisidir ve hazır bir pakete ayar ekranından eklenemez. Kur alanı sonradan iliştirildiğinde geçmiş dönem raporları her kur hareketinde yeniden yazılır; ortaklı bir yapıda bu, pay dağılımının geriye dönük kayması anlamına gelir. Karar tablosundaki üçüncü sorunun karşılığı burada somutlaşıyor.

Melez yol: ikisini birden kullanmak

Üçüncü bir seçenek daha var ve pratikte en sık işe yarayan yol çoğu zaman budur: standart işi hazır bir çözümle yürütmek, işin ayırt edici parçasını özel geliştirmek ve ikisini birbirine bağlamak.

Standart tarafta kalanlar

Resmî muhasebe kaydı, bordro, genel ofis araçları — bunları geliştirmenin size kazandıracağı bir şey yok.

Özelleşmesi gerekenler

Fiyatlama, maliyet, üretim akışı, kur mantığı — sizi ayıran her şey.

Aradaki köprü

İki tarafın hangi veriyi ürettiği ve kimin doğruluk kaynağı olduğu baştan yazılmalı. Bu tarafı API ve sistem entegrasyonları başlığında ele alıyoruz.

Sıralama

Önce en çok kaybettiren adım. İkinci faz, ekip birinciyi gerçekten kullanmaya başladıktan sonra.

Sıkça sorulan sorular

Özel yazılım her zaman daha mı pahalı?

İlk yıl genellikle evet. Beş yıllık toplamda ise cevap, kullanıcı sayınıza ve uyarlama ihtiyacınıza bağlıdır. Ekip büyüyorsa ve standart dışı kuralınız çoksa, hazır paketin toplamı çoğu zaman öne geçer.

Hazır paketle başlayıp sonra özel yazılıma geçebilir miyiz?

Evet, yaygın bir yoldur. Tek şart, verinizi eksiksiz dışa aktarabilmenizdir. Bunu sözleşme aşamasında yazdırın; sonradan sormak pazarlık gücünüzü sıfırlar.

Özel yazılımda kod gerçekten bizim mi olur?

Sözleşmede yazıyorsa olur. Kaynak kodun teslimi, barındırmanın nerede olacağı ve bakım anlaşmasının kapsamı üç ayrı maddedir; üçünü de ayrı ayrı netleştirin.

Küçük bir firma için özel yazılım aşırı kaçar mı?

Ölçü firma büyüklüğü değil, sürecin standarttan sapma miktarıdır. Küçük ama çok özel çalışan bir atölyede özel yazılım, büyük ama standart çalışan bir firmadan daha erken kendini amorti edebilir.

Bakım maliyetini nasıl öngörebiliriz?

Yıllık bakımı bir yüzde olarak değil, kapsam olarak tanımlayın: kaç adam-gün, hangi yanıt süresi, hangi işler dahil. Yüzde üzerinden yapılan anlaşmalar ikinci yılda tartışmaya dönüşür.

Sonraki adım

Karar vermeden önce iki tabloyu doldurun: elinizdeki tekliflerin beş yıllık kalem dökümünü ve altı soruluk karar tablosunu. Bu iki sayfa, üç saatlik demo toplantısından daha çok şey söyler.

Doldururken tıkanırsanız ücretsiz ön analiz talebi oluşturabilirsiniz: süreçlerinizi inceleyip kapsam, süre ve bütçe içeren bir öneriyle 1 iş günü içinde dönüyoruz. Konuyu bir yazılım seçimi olarak değil, süreç kararı olarak ele almak isterseniz iş süreci otomasyonu ve özel PHP/Laravel yazılımı sayfaları başlangıç noktası olabilir. Daha önce teslim ettiğimiz işleri müşteri projeleri sayfasında görebilirsiniz.