Özel Yazılım Nedir? Hazır Ürün Ne Zaman Yeter, Ne Zaman Yetmez

Bize gelen taleplerin büyük kısmı aslında tek bir soruya iniyor: bu işi hazır bir programla çözebilir miyim, yoksa gerçekten bize özel bir yazılım mı yazdırmam gerekiyor? Soruyu soran kişi genelde teknik biri değil; işletme sahibi, operasyon müdürü ya da şirketin bilgi işlemden sorumlu tek kişisi oluyor. Elinde iki teklif var, biri aylık abonelikli hazır bir ürün, diğeri altı haneli bir geliştirme projesi. İkisi de aynı problemi çözeceğini söylüyor.

Bu yazı o kararı vermek için gereken kriterleri anlatıyor. Hangi durumda hazır ürünün yeteceğini, hangi durumda yetmediğini, özel yazılım sürecinin gerçekte nasıl ilerlediğini ve teslimden sonra ne olduğunu yazıyoruz. Amacımız "özel yazılım daha iyidir" demek değil; çünkü çoğu zaman değil. Amacımız kararı sezgiyle değil kriterle vermenizi sağlamak.

Özel yazılım nedir, hazır üründen nerede ayrılır

Özel yazılım, tek bir kurumun kendi iş akışına göre sıfırdan tasarlanıp geliştirilen ve o kurumun kullanımına özgü kalan yazılımdır. Ismarlama yazılım, kişiye özel yazılım ya da kurum içi yazılım gibi adlarla da anılır. Hazır üründen ayrıldığı yer ekran sayısı ya da özellik listesi değil; kimin kime uyduğu.

Hazır bir üründe süreciniz ürüne uyar. Ürün "önce teklif, sonra sipariş, sonra sevkiyat" diyorsa, sizde sevkiyat teklifin önüne geçemez. Bu bir kusur değil, hazır ürünün varlık sebebidir: binlerce şirketin ortak paydası üzerine kurulmuştur ve o ortak payda sayesinde ucuzdur, hızlı kurulur, dokümantasyonu ve topluluğu vardır. Özel yazılımda ise ürün size uyar. Karşılığında analiz süresi, geliştirme maliyeti ve teslim sonrası bakım sorumluluğu sizin tarafınıza geçer.

Kararın özü budur: süreciniz sizi rakiplerinizden ayıran bir şey mi, yoksa herkesin yaptığı işin sizdeki hâli mi? Muhasebe kaydı tutmak sizi rakibinizden ayırmaz. Ürünlerinizi hangi kriterlere göre fiyatlandırdığınız, hangi bayiye hangi vade ile hangi kotayı verdiğiniz ya da üretim hattınızdaki fire hesabı ayırabilir.

Kişiye özel yazılım, ısmarlama yazılım, kurum içi yazılım: farkları var mı?

Piyasada aynı işi anlatan birkaç ad dolaşıyor ve teklif alırken bu adların farklı şeyleri kastediyor olması kafa karıştırıyor. Pratikte kullanım şöyle ayrışıyor:

• Kişiye özel yazılım en geniş ve en yaygın kullanılan ad. Tek bir kurum için, o kurumun akışına göre yazılan her yazılımı kapsar; ekranların ve iş kurallarının size özel çizildiğini vurgular.
• Ismarlama yazılım aynı şeyin daha eski adı ve daha çok ticari ilişkiyi vurgular: siz sipariş verirsiniz, geliştirici o siparişe göre üretir. Terim olarak "paket yazılım"ın karşıtı olarak kullanılır.
• Kurum içi yazılım ise kullanım yerini anlatır: dışarıya değil yalnızca çalışanlara açık, iç operasyonu yürüten sistemler. Kurum içi bir yazılım hazır ürün de olabilir, özel geliştirilmiş de.

Yani ilk ikisi arasında teknik bir fark yok; üçüncüsü farklı bir eksende duruyor. Teklif metinlerinde bu adların hangisi geçerse geçsin bakmanız gereken şey ad değil, kapsamın ve fikri mülkiyetin nasıl tanımlandığıdır.

Ürün mü satın alıyorsunuz, yazılım hizmeti mi?

Bu ayrım, karardan sonra yaşayacağınız her şeyi belirliyor. Hazır ürün aldığınızda bir ürün satın alırsınız: fiyatı bellidir, ne yaptığı bellidir, yol haritasını başkası çizer ve siz o yol haritasının yolcususunuz. Özel geliştirmede ise bir yazılım hizmeti satın alırsınız: satın aldığınız şey bitmiş bir kutu değil, sizin adınıza çalışacak bir ekip ve süreçtir.

Bunun pratik sonucu şu: üründe kalite en baştan bellidir, hizmette kalite süreç boyunca yönetilir. Yazılım hizmeti alırken sorulacak sorular fiyat listesi soruları değil, ekip, iletişim ritmi, kapsam yönetimi ve teslim sonrası sorumluluk sorularıdır.

Hazır ürün ne zaman yeter

Aşağıdaki maddelerin çoğu sizin için doğruysa özel yazılım yaptırmayın; para ve zaman kaybedersiniz.

• Süreç standart. Ön muhasebe, bordro, e-fatura, CRM'in temel kartotek işlevi, yardım masası biletleme. Bunların hepsi olgun pazarlarda çözülmüş problemler.
• Mevzuat sürekli değişiyor. e-Fatura, e-Arşiv, e-Defter gibi alanlarda mevzuat her yıl değişir. Hazır üründe bu değişikliği sağlayıcı takip eder; özel yazılımda her değişiklik sizin bakım faturanıza yazılır.
• Kullanıcı sayınız az ve süreç seyrek işliyor. Ayda otuz kez yapılan bir işlem için yazılım geliştirmenin geri dönüşü genelde çıkmaz.
• Hemen başlamanız gerekiyor. Hazır ürün gün içinde kurulur, özel yazılımın en hızlı hâli bile haftalarla ölçülür.
• Ekipte yazılımı sahiplenecek kimse yok. Özel yazılımın bir iç sahibi olmak zorundadır; kimse sahiplenmezse teslimden altı ay sonra kimse kullanmaz.

E-ticaret tarafında da aynı mantık geçerli. Mağaza altyapısı seçerken sıfırdan bir e-ticaret motoru yazdırmak neredeyse hiçbir zaman doğru karar değildir; bu kararın nasıl verildiğini ikas mı Shopify mı karşılaştırmasında ayrıntılı yazdık. Doğru soru "altyapıyı mı yazdırayım" değil, "hazır altyapının üstüne bana özel ne eklenmeli" sorusudur.

Özel yazılım gerçekten ne zaman gerekir

Aşağıdaki işaretlerden üç veya daha fazlası varsa hazır ürün arayışını durdurup özel geliştirmeyi konuşmanız mantıklı.

1. Excel bir arayüz hâline gelmişse

Şirketlerin çoğunda kritik bir süreç, içinde makrolar olan ve tek bir kişinin tam olarak anladığı bir Excel dosyasında yaşar. Dosya e-postayla dolaşır, aynı anda iki kişi açtığında sürüm çakışır, formülü kuran kişi ayrıldığında kimse dokunamaz. Bu, sürecin standart olmadığının en net kanıtıdır: standart olsaydı hazır bir ürün onu zaten kapsıyor olurdu.

2. Hazır ürünü özelleştirmenin maliyeti ürünün kendisini geçmişse

Bir hazır ürünü aldınız, üstüne beş ayrı eklenti, iki danışman ve bir sürü manuel ara adım eklediniz. Bu noktada "hazır ürün kullanıyoruz" demek artık doğru değil; kırılgan ve kimsenin tümünü bilmediği bir melez sistem kullanıyorsunuz. Bu melezin bakım maliyeti genellikle özel yazılımın maliyetini sessizce geçer.

3. Sistemler arasında veriyi insan taşıyorsa

Bir kişi her sabah bir panelden rapor indirip başka bir panele elle giriyorsa, ortada yazılımla çözülmesi gereken bir entegrasyon problemi var demektir. Bu genellikle tam bir özel yazılım değil, sadece bir entegrasyon ve otomasyon katmanı gerektirir; maliyeti de tam bir sistemin çok altındadır.

4. İşin mantığı sizde farklıysa

Fiyatlandırmanız müşteri segmentine, sipariş hacmine ve döviz kuruna göre kademeli hesaplanıyorsa; ya da servis planlamanız teknisyen sertifikasyonu, bölge ve stok durumunu birlikte değerlendiriyorsa, bu mantığı hazır bir ürünün ayar ekranına sığdıramazsınız. Sığdırmaya çalışanlar genelde sonunda o mantığı Excel'e geri taşır.

5. Veri sahipliği ya da yer kısıtınız varsa

Kamu işi yapıyorsanız, sağlık verisi işliyorsanız veya sözleşmeleriniz verinin belirli bir ülkede ya da kendi sunucunuzda kalmasını şart koşuyorsa, hazır SaaS ürünlerinin çoğu bu şartı karşılayamaz. Bu tek başına özel geliştirme için yeterli bir gerekçedir.

Hazır yazılım mı özel yazılım mı: karar tablosu

Çoğu şirket için doğru cevap: melez kurgu

Uygulamada en sık kurduğumuz yapı, ikisinin arasındaki bir yerde duruyor. Standart olan ne varsa hazır üründe kalır: muhasebe, e-fatura, bordro, mağaza altyapısı. Sizi ayıran ne varsa özel yazılıma taşınır. İkisi arasına da bir entegrasyon katmanı konur; bu katman veriyi taşır, çakışmaları çözer ve hata olduğunda haber verir.

Bu kurgunun avantajı riskin küçülmesidir. Şirketin tamamını tek seferde yeni bir sisteme taşımak yerine, en çok acıtan tek süreci özel yazılıma alırsınız. İşe yararsa bir sonrakini alırsınız. İşe yaramazsa kaybınız tek bir modülle sınırlı kalır. E-ticaret tarafında biz de aynı yaklaşımı izliyoruz: mağaza altyapısı yerinde kalır, üzerine modüller ve gerektiğinde özel geliştirme eklenir.

Özel yazılım geliştirme süreci adım adım

Süreci beş aşamada anlatıyoruz. Her aşamanın çıktısı somuttur; çıktı ortaya çıkmadan bir sonrakine geçilmez.

Analiz: neyin yazılacağından önce neyin yazılmayacağı

Analiz, ekranların çizildiği aşama değildir. Bu aşamada işi kimin yaptığı, hangi kararı neye bakarak verdiği ve hangi istisnaların gerçekten yaşandığı çıkarılır. En kritik çıktı kapsam dışı listesidir: bu sürümde yapılmayacak işlerin yazılı listesi. Bu liste yoksa proje boyunca her yeni fikir kapsama sızar ve teslim tarihi sürekli ötelenir.

Analizde bir tuzak var: süreci anlatan kişi genellikle süreci ideal hâliyle anlatır, gerçek hâliyle değil. Bu yüzden anlatılanla yetinmeyip mevcut kayıtlara bakmak gerekir. Sistemde "iptal" statüsünün ne sıklıkta ve hangi gerekçelerle kullanıldığını görmek, o statüyü kimin nasıl kullandığını anlatan yarım saatlik toplantıdan daha çok şey söyler.

Tasarım ve mimari: kararların pahalıya mal olduğu yer

Bu aşamada veri modeli, yetkilendirme yapısı, entegrasyon noktaları ve ekran akışları belirlenir. Veri modeli özellikle kritiktir çünkü sonradan değiştirmesi en pahalı şey odur. Bir alanı sonradan eklemek kolaydır; bir kaydın hangi kayda bağlı olduğunu sonradan değiştirmek, üzerine yazılmış tüm ekranları ve raporları etkiler.

Rol ve yetki yapısı da bu aşamada konuşulmalıdır. "Sonra ekleriz" denilen yetkilendirme, sonradan eklenirken her ekrana tek tek dokunmayı gerektirir. Kimin neyi görebileceği ve neyi değiştirebileceği baştan modellenirse bu iş bir kez yapılır.

Geliştirme: haftalık çalışan sürüm

Geliştirme aşamasında tek bir ilke önemlidir: her hafta çalışan bir şey görün. Aylarca "geliştiriyoruz" denip sonunda tek seferde teslim edilen projelerde, teslim anına kadar hiçbir yanlış anlaşılma ortaya çıkmaz; hepsi teslim gününde aynı anda ortaya çıkar. Haftalık demo, yanlış anlaşılmayı bir haftalık işle sınırlar.

Bu aşamada sizden beklenen şey de var: geri bildirimin zamanında gelmesi. Bir hafta gecikmiş geri bildirim, o hafta üzerine inşa edilmiş işin de değişmesi anlamına gelir. Projelerin gecikme sebeplerinin önemli bir kısmı geliştirme hızı değil, karar bekleme süresidir.

Teslim: yazılımın değil sürecin devreye alınması

Teslim, kodun sunucuya çıkması değildir. Devreye alma üç işi birlikte kapsar: veri göçü, paralel çalışma ve eğitim. Veri göçünde eski sistemdeki kayıtlar temizlenerek aktarılır; burada beklenmedik iş çıkar, çünkü eski veride her zaman tarih formatı bozuk, mükerrer ya da boş kayıtlar bulunur. Paralel çalışma, yeni sistem devreye girdikten sonra eskisinin bir süre daha açık kalmasıdır; geri dönüş ihtimalini korur. Eğitim ise ekranların gösterilmesi değil, ekibin kendi günlük işini yeni sistemde bir kez baştan sona yapmasıdır.

Bakım: proje bitmez, biçim değiştirir

Teslimden sonra üç tür iş gelir ve bunlar birbirine karıştırılmamalıdır. Birincisi hata düzeltme: yazılım sözleşmede tanımlandığı gibi çalışmıyordur, bu geliştiricinin sorumluluğundadır. İkincisi uyum bakımı: kütüphane sürümleri, işletim sistemi güncellemeleri, entegre olunan servisin API değişikliği, mevzuat değişikliği. Bunlar hiç yeni özellik istemeseniz bile gelir ve bakım anlaşmasının asıl gerekçesidir. Üçüncüsü yeni özellik talebi: bu ayrı bir iştir ve ayrı fiyatlandırılır.

Bakım anlaşması yapılmadan teslim alınan projelerin ortak kaderi şudur: bir yıl boyunca hiçbir şeye dokunulmaz, sonra bir gün sunucu bir güncelleme sebebiyle çalışmaz hâle gelir ve o noktada projeyi yazan ekiple iletişim de kopmuştur. Teklif alırken bakım kalemini ayrıca konuşmak gerekir; bu konuyu yazılım projesi yaptırma rehberinde sözleşme maddeleri düzeyinde ele aldık.

Kapsam kayması: projelerin gerçek katili

Yazılım projelerinin çoğu teknik sebeplerle değil kapsam sebebiyle başarısız olur. Kapsam kayması, kimsenin kötü niyeti olmadan gerçekleşir: analizde konuşulmamış bir istisna ortaya çıkar, biri "bu arada şunu da ekleyelim" der, bir başkası "zaten oradayken şu raporu da alalım" der. Her biri tek başına küçüktür, toplamı projeyi ikiye katlar.

Bunu önlemenin yolu talepleri reddetmek değil, hepsini yazılı bir listeye almak ve her birine "bu sürüm mü, sonraki sürüm mü" kararı verdirmektir. Karar sizin olur, ama sonucu görürsünüz: her eklenen madde teslim tarihini ve bütçeyi görünür biçimde değiştirir. Sözlü kalan talepler ise fatura zamanı tartışma çıkarır.

Özel yazılım fiyatları neye göre belirlenir

"Özel yazılım kaça mal olur" sorusuna listeden okunacak bir cevap yok; olduğunu söyleyen teklif de zaten kapsamı görmeden verilmiş demektir. Ama fiyatı neyin belirlediği tamamen sayılabilir bir liste ve teklif almadan önce bunları kendi işiniz için işaretlerseniz, gelen rakamların neden farklı olduğunu da anlarsınız.

Özel yazılım fiyatlarını sırayla şu kalemler belirler:

Bu tablodaki hangi satırın sizde ağır bastığını bir analiz görüşmesinde birkaç saatte çıkarmak mümkün; gerçekçi bir bant o zaman verilebilir. Ayrıca fiyatın tamamı geliştirme değildir: sunucu, alan adı, sertifika, e-posta veya mesaj gönderim servisi, harita ve doğrulama servisleri gibi aylık işleyen kalemler yazılımın kendisinden bağımsız devam eder ve teklifte kimin ödeyeceği yazılı olmalıdır.

Sık yapılan beş hata

1. Her şeyi ilk sürüme koymak. İlk sürüm en çok acıtan süreci çözsün. Kalanı ikinci sürümde, gerçek kullanım verisiyle karar verilerek eklensin.
2. Kullanıcıyı analizden dışlamak. Sistemi gün boyu kullanacak kişi analizde yoksa, teslimde "biz böyle çalışmıyoruz" cevabı gelir.
3. Raporu sona bırakmak. Yönetimin bakacağı raporlar en sona bırakılırsa, veri modelinin o raporu üretemeyeceği en sonda anlaşılır.
4. Tek kişiye bağımlı kalmak. Projeyi bilen tek bir geliştirici varsa, o kişi projeden ayrıldığında proje de durur. Dokümantasyon ve kod teslimi bu yüzden sözleşmede yer almalıdır.
5. Test ortamı olmadan yayına almak. Canlı sistemde deneme yapmak, hatayı müşterinizin bulmasına yol açar.

Biz nasıl çalışıyoruz

STools Digital olarak özel yazılım tarafında iki farklı işi ayırıyoruz. Birincisi tam kapsamlı iş süreç yazılımları: kendi panelinizde çalışan, rol bazlı, mevcut sistemlerinizle konuşan uygulamalar. İkincisi mevcut altyapınızın üstüne oturan daha küçük çözümler: iki sistem arasındaki veri akışını kuran entegrasyonlar, tek bir süreci otomatikleştiren araçlar ve e-ticaret tarafında mağazanıza eklenen modüller.

E-ticaret altyapısı arayan şirketler için kendi geliştirdiğimiz RapiSoft altyapısını kullanıyoruz; bu, kiraladığımız bir panel değil kendi ürünümüz olduğu için ihtiyaç duyulan yerde derinlemesine özelleştirilebiliyor. Kurumsal tarafta ise kurumsal web sitesi ve mobil uygulama işleri çoğu zaman aynı özel yazılım projesinin parçası olarak ilerliyor.

Bu iki başlığın kapsamını, çalışma biçimini ve fiyatı belirleyen kalemleri özel yazılım hizmet sayfamızda ayrıntılı yazdık.

Nereden başlayacağınızdan emin değilseniz ilk adım analiz görüşmesidir. Bu görüşmede çoğu zaman "buna özel yazılım gerekmiyor, şu hazır ürünle çözülür" dediğimiz de oluyor; çünkü gerekmeyen bir projeyi satmak iki taraf için de kötü sonuçlanıyor. destek@stools.digital adresinden ya da iletişim sayfasından yazabilirsiniz.