Özel Yazılım mı, Hazır Paket mi? Kararı Neye Göre Vermeli

Özel yazılım ile hazır paket arasındaki tercih, kalite değil uyum meselesidir. Hazır bir paket, binlerce işletmenin ortak ihtiyacına göre şekillenmiştir; bu onu kötü yapmaz, sizin işinize özgü olan kısmı görmemiş yapar. Özel yazılım tam tersidir: yalnız sizin işinizi bilir, ama binlerce işletmenin kenar durumlarını görmemiştir. İki yaklaşımın da kör noktası var ve doğru karar, hangi kör noktanın sizin için daha ucuz olduğuna bağlı.

Biz bu yazıyı taraf tutmadan yazabiliyoruz, çünkü ikisini de üretiyoruz. Bir yanda belirli sektörler için geliştirdiğimiz hazır ürünler var — kafeler, klinikler, emlak ofisleri gibi. Diğer yanda kuruma özgü, sıfırdan yazılan sistemler. Aynı ekibin iki farklı işi olduğu için, bir müşteriye 'sizin işiniz için hazır ürünümüz uygun değil' demek bizim için ticari bir kayıp değil, yalnız doğru odaya yönlendirmek.

Her işletme kendini özel görür ve çoğu zaman haklıdır — ama özellik yazılıma her zaman yansımaz. Bir kafenin kahve harmanı özeldir, sipariş akışı değildir; bir kliniğin hasta ilişkisi özeldir, randevu takvimi değildir. Karar vermeden önce yapılacak en yararlı egzersiz, işin adımlarını yazıp her adımın yanına 'bu bizde nasıl farklı' sorusunu koymaktır. Cevabı boş kalan her satır, hazır paketin alanıdır.

Fark gerçekten varsa, genellikle bir yerde yoğunlaşır: fiyatlandırma mantığında, onay zincirinde, üretim planlamasında ya da mevzuatın dayattığı bir kuralda. Bu durumda üçüncü bir yol açılır — çekirdek için hazır bir temel, farkın olduğu yerde özel geliştirme. Bizim ürün ailemizde bu kalıp sık tekrar ediyor: aynı çekirdek üstünde sektöre özgü modüller.

Bir uyarı: farkın gerçek olup olmadığını yazılım ekibi tek başına anlayamaz. 'Biz böyle yapıyoruz' cümlesinin arkasında bazen sağlam bir iş nedeni, bazen de yalnız alışkanlık vardır. Alışkanlığı yazılıma gömmek, en pahalı özelleştirme türüdür — çünkü yıllarca bakımı yapılır ve kimse neden orada olduğunu hatırlamaz.

Hazır paket ilk gün ucuzdur, özel yazılım ilk gün pahalıdır; bu yüzden birinci yılın karşılaştırması hep aynı sonucu verir. Anlamlı karşılaştırma üç yıllık toplam sahip olma maliyetidir ve hesaba dört kalem girer: lisans ya da abonelik, kurulum ve göç, süregelen bakım, bir de en çok unutulanı — sistemin karşılamadığı işleri insanların elle yapmasının maliyeti.

Dördüncü kalem genellikle en büyüğüdür ve hiçbir teklifte yazmaz. Hazır bir sistemin karşılamadığı akış, elektronik tabloya, e-postaya ya da bir kişinin hafızasına taşınır. Bunun aylık bedeli görünmez ama vardır: iki kişinin haftada beş saati, üç yılda ciddi bir rakama ulaşır ve bu rakam çoğu zaman özel geliştirmenin farkını kapatır.

Tersi de doğrudur: özel yazılımın gizli kalemi bakımdır. Yazdırdığınız sistem, sizin için çalışan bir ekip olmadan yaşamaz — güvenlik güncellemeleri, çatı yükseltmeleri, değişen mevzuat. Bu yükü hesaba katmayan bir özel yazılım kararı, üçüncü yılda 'kimse dokunamıyor' noktasına gelir. Hesaba her iki tarafın da görünmeyen kalemini koyun.

Zaman kısıtı, kararı çoğu maliyet hesabından daha güçlü belirler. Üç hafta içinde çalışan bir sisteme ihtiyacınız varsa özel yazılım seçenek değildir; hazır bir ürünle başlar, farkı sonra ele alırsınız. Altı ay varsa tablo değişir. Bu yüzden ilk soru bütçe değil takvim olmalı: bu sistem ne zaman çalışmak zorunda ve o tarih neden o tarih?

Takvim baskısı altında sık yapılan hata, özel yazılımı hızlandırmaya çalışmaktır. Kapsamı sabit tutup süreyi kısaltmak kaliteyi düşürür; doğru hamle kapsamı küçültmektir. Hazır ürünle başlayıp özel parçayı ikinci fazda yazmak, aynı bütçeyle daha az riskli bir yoldur — ve ilk fazda öğrendikleriniz ikinci fazın tasarımını iyileştirir.

Hangi yolu seçerseniz seçin, sorulacak tek ortak soru şudur: verimi istediğim gün, eksiksiz ve makine okunur biçimde alabilir miyim? Bu soruya net cevap veremeyen bir çözüm, ne kadar iyi olursa olsun bir riski beraberinde getirir. Hazır ürünlerde bu genellikle bir dışa aktarım özelliğidir; özel yazılımda veritabanının kendisi zaten sizindir.

İkinci kilitlenme türü daha sinsidir: bilgi kilidi. Sistemi yalnız bir kişi ya da bir tedarikçi anlıyorsa, kod sizde olsa bile bağımlısınızdır. Bunun panzehiri belgelemedir — mimari kararların, ortam yapılandırmasının ve dağıtım adımlarının yazılı olması. Özel yazılım aldığınızda kodun yanında bu belgeyi de isteyin; kod kadar değerlidir.

Pratikte en sık işe yarayan yol ikisinin ortasıdır: standart olan her şeyi hazır bir temelden almak, gerçekten farklı olan kısmı özel yazmak. Bu, teknik olarak sınırların net çizilmesini gerektirir — özel parça, çekirdeğin içine dağılmış yamalar hâlinde değil, ayrı bir modül olarak yaşamalıdır. Aksi hâlde çekirdek her güncellendiğinde özelleştirmeler kırılır ve üründen kopmuş bir çatal ortaya çıkar.

Biz bu ilkeyi kendi ürünlerimizde de uyguluyoruz: dış sistemlerle konuşma ihtiyacı çıktığında her biri bağımsız bir adaptör olarak yazılır, çekirdeğe dokunulmaz. Yeni bir sistem eklemek, yeni bir adaptör ve bir kayıt satırı demektir. Bu disiplin sayesinde bir müşteriye özel yazılan entegrasyon, diğer müşterilerin ürününü riske atmaz.

Melez yolun ticari faydası da var: özel parçanın maliyeti tüm sistemin değil yalnız farkın maliyetidir. Müşteri, hazır çekirdeğin olgunluğundan yararlanırken kendi işine özgü akışı da kaybetmez. Karşılığında bir kısıt kabul eder — çekirdek nasıl çalışıyorsa öyle çalışır; onu değiştirmek istemek, melez yolu terk edip özel yazılıma dönmek demektir.

Özel yazılım kararı verildiğinde ikinci soru hemen gelir: kim yazacak? İç ekip kurmak, bilginin kurumda kalmasını sağlar ve uzun vadede en ucuz yoldur — ama işe alım, yönetim ve süreklilik gerektirir. Tek bir geliştiriciyle kurulan iç ekip, o kişi ayrıldığında sıfırlanır; üç kişiden azına 'ekip' demek genellikle iyimserliktir.

Dış tedarikçi hızlı başlar ve riski dışarı taşır, ama bilgi de dışarıda birikir. Bunu dengelemenin yolu sözleşmeye üç madde koymaktır: kaynak kodun mülkiyeti, teknik belgelerin teslimi ve devir sürecinin tanımı. Bu üçü yoksa proje bittiğinde elinizde çalışan bir sistem olur ama ona dokunabilecek kimse olmaz.

Pratikte en çok işe yarayan üçüncü yol karma modeldir: sistemi dış ekip yazar, kurumdan bir teknik kişi projenin içinde durur. O kişi kod yazmasa bile mimariyi bilir, kararlara katılır ve devir günü boş bir sayfayla karşılaşmaz. Bu rolün maliyeti, projenin toplamında küçük; karşılığı ise bağımsızlıktır.

Birincisi, mevcut süreci olduğu gibi yazılıma çevirmek. Kurumda yıllardır işleyen bir süreç, çoğu zaman eski araçların kısıtlarına göre şekillenmiştir; onu birebir kodlamak, o kısıtları da kalıcı hâle getirir. Yazılıma geçmeden önce sorulacak soru, 'bu adım neden var' olmalıdır — cevabı 'hep böyle yapıyorduk' olan adımların yarısı yazılımda gereksizdir.

İkincisi, her isteği ilk sürüme sığdırmaya çalışmak. Özel yazılımın en büyük avantajı istediğinizi yaptırabilmenizdir ve bu avantaj, kapsamı kontrolsüz büyütmenin de en büyük sebebidir. İlk sürümü dar tutup gerçek kullanımdan öğrenmek, altı ay sürecek bir listeyi baştan yazmaktan hem ucuz hem doğru sonuç verir.

Üçüncüsü, bakımı planlamamak. Yazdırılan sistem teslim edildiğinde proje bitmez; güvenlik güncellemeleri, çatı yükseltmeleri ve değişen mevzuat devam eder. Bakım için bir bütçe ve bir sorumlu tanımlanmadığında sistem üç yıl içinde 'dokunulamaz' hâle gelir ve kurum, yeni bir proje başlatmak zorunda kalır.

Hazır bir ürünü seçtikten sonra çoğu kurum onu kendine benzetmek ister ve bir noktaya kadar bu mümkündür: ayarlar, alan tanımları, iş akışı yapılandırması, rapor tasarımı. Sınır, ürünün çekirdek davranışını değiştirmeye başladığınız yerdir. O çizgiyi geçtiğinizde artık hazır ürün kullanmıyorsunuzdur; bakımı size ait bir çatal kullanıyorsunuzdur.

Bu çizginin pratik testi güncellemedir: ürün yeni sürüme geçtiğinde yaptığınız özelleştirmeler ayakta kalıyor mu? Kalıyorsa doğru katmanda çalışıyorsunuz demektir. Her sürümde elden geçirmeniz gerekiyorsa, o özelleştirme yanlış yerde duruyordur ve zamanla ürünü güncelleyemez hâle gelirsiniz.

Sınırı aştığınızı fark ettiğinizde iki dürüst seçenek var: özelleştirmeyi geri alıp ürünün yolundan gitmek ya da o parçayı ayrı bir modül olarak ürünün dışına taşımak. Üçüncü seçenek — çekirdeği değiştirmeye devam etmek — kısa vadede işe yarar, uzun vadede hem ürünün hem sizin yolunuzu tıkar.

Bir: işin hangi adımı gerçekten farklı — ve bu fark bir iş nedenine mi yoksa alışkanlığa mı dayanıyor? İki: sistem ne zaman çalışmak zorunda? Üç: üç yıllık toplam maliyeti, elle yapılan işlerin bedeli dahil hesapladınız mı?

Dört: veriyi istediğiniz gün eksiksiz alabiliyor musunuz? Beş: sistemi kim bakacak ve o kişi ayrılırsa ne olacak? Altı: farkın olduğu yeri ayrı bir modül olarak tutabiliyor musunuz? Son soruya evet diyebiliyorsanız, melez yol genellikle en dengeli seçenektir.

Özel yazılım ile hazır paket arasındaki seçim bir inanç meselesi değil, birkaç somut sorunun cevabıdır: farkınız nerede, takviminiz ne, üç yıllık maliyetiniz ne, veriniz kimde ve bakımı kim yapacak. Cevaplar çoğu zaman ortada bir yeri işaret eder — hazır bir çekirdek üstünde, yalnız gerçekten farklı olan yerde özel geliştirme.

Biz ikisini de yaptığımız için tavsiyemizin yönü müşteriye göre değişiyor; bazen 'hazır ürünümüz size uymaz' diyoruz, bazen 'buna özel yazılım gerekmez' diyoruz. Elinizdeki işi anlatırsanız, hangi yolun sizin için daha ucuz olduğunu birlikte hesaplayabiliriz.