Özel yazılım, satın alınabilecek bir ürün değil, sizinle birlikte kurulan bir süreçtir. Bu sayfa o sürecin bizdeki karşılığını anlatıyor: hangi ihtiyaç gerçekten özel geliştirme gerektirir, kapsamda ne var ne yok, entegrasyon katmanı neden işin en zor kısmıdır, kaynak kod kimin olur, bakım anlaşması neyi kapsar ve fiyatı hangi kalemler belirler. Karar aşamasındaysanız ve önce hazır ürünle karşılaştırmak istiyorsanız kişiye özel yazılım rehberi karar tablosunu veriyor; burası hizmetin kendisi.
Hazır ürün ne zaman yetmez
Keşif görüşmelerimizin bir kısmı "bu iş için özel yazılım gerekmiyor" cümlesiyle bitiyor ve bunu bir kayıp saymıyoruz. Yanlış kurulmuş bir proje, kimsenin kullanmadığı bir panelle ve iki taraf için de kötü bir deneyimle sonuçlanıyor. Ayrımı şu dört sinyal üzerinden yapıyoruz:
- Sürecinizin kendisi rekabet avantajınızsa. İşi rakiplerinizden farklı yapıyor ve bu farkı hazır ürünün kalıbına sığdıramıyorsanız, yazılımı kalıba uydurmak yerine kalıbı yazdırmak mantıklıdır.
- İki sistem arasında insan eliyle veri taşınıyorsa. Excel indirip başka bir panele yüklemek, bir yerden kopyalayıp diğerine yapıştırmak yalnızca zaman kaybı değil, hata kaynağıdır.
- Hazır ürünün lisans maliyeti kullanıcı sayısıyla katlanıyorsa. Kullanıcı başına ücretlendirilen bir üründe ekip büyüdükçe maliyet, geliştirme maliyetini geçebilir. Bu hesabı birlikte yapıyoruz.
- İhtiyaç ürünün yol haritasında yoksa. Kritik bir eksik için sağlayıcının bir gün ekleyeceği özelliği beklemek, çoğu şirketin göze alamayacağı bir belirsizlik.
Bunların hiçbiri geçerli değilse, hazır bir ürünle başlamanızı öneriyoruz. En sık kurduğumuz yapı zaten melez oluyor: standart işler hazır ürünlerde kalıyor, aradaki boşluk özel geliştirilen bir katmanla kapanıyor.
Kişiye özel yazılım hizmeti kapsamında ne teslim ediyoruz
| Kalem | Standart kapsamda | Not |
|---|---|---|
| Keşif ve süreç analizi | Evet | Mevcut işleyişin yazıya dökülmesi ve istisnaların çıkarılması |
| Kapsam belgesi | Evet | Ekranlar, roller, kurallar ve kapsam dışı maddeler |
| Veri modeli ve mimari kararlar | Evet | Ana veri kaynağı, yetki yapısı, kayıt ve yedekleme politikası |
| Arayüz tasarımı | Evet | Günlük kullanılan ekranlarda akış önceliklidir |
| Geliştirme ve haftalık sürüm | Evet | Her hafta çalışan bir sürüm görürsünüz |
| Entegrasyonlar | Evet | Kapsamda sayılan sistemler; her biri ayrı test yükü getirir |
| Test ortamı | Evet | Canlıdan ayrı; veri geçişi ve senaryolar burada denenir |
| Veri geçişi | Evet | Mevcut kayıtların aktarımı ve doğrulaması |
| Kaynak kod ve dokümantasyon | Evet | Kurulum notları ve veritabanı şeması dahil size teslim edilir |
| Kullanıcı eğitimi | Evet | Rol bazlı; yönetici ve saha kullanıcısına ayrı ayrı |
| Garanti dönemi | Evet | Kapsam içi hatalar tanımlı süre boyunca ücretsiz düzeltilir |
| Sunucu ve barındırma | Opsiyon | Kendi sunucunuzda veya bizim önerdiğimiz kurulumda |
| Bakım ve izleme | Opsiyon | Aylık anlaşma; zorunlu değil, tavsiye edilir |
| Üçüncü taraf lisans bedelleri | Hayır | Gerekiyorsa teklifte ayrıca gösterilir |
İş süreç yazılımı: en sık karşılaştığımız dört kalıp
Talepler farklı sektörlerden gelse de yazılıma dönüşen ihtiyaçlar birkaç kalıpta toplanıyor. Bu kalıpları bilmek, kendi ihtiyacınızı tarif etmenizi kolaylaştırır.
1. Onay ve teklif akışları
Bir talebin oluşturulup sırayla farklı kişilerin onayından geçtiği süreçler. Yazılıma alındığında kazanç yalnızca hız değil, izlenebilirliktir: talebin hangi adımda beklediği ve kimde durduğu görünür hâle gelir. Kritik nokta, onay kurallarının koda gömülmeden yönetici tarafından değiştirilebilir olmasıdır.
2. Saha ve servis kayıtları
Dışarıda çalışan ekiplerin kayıt girdiği, fotoğraf yüklediği ve iş emri kapattığı yapılar. Burada belirleyici olan bağlantısız çalışma ihtiyacıdır: kapsama alanı dışında girilen kaydın kaybolmaması gerekir. Bu gereksinim mimariyi baştan değiştirir, sonradan eklenmesi zordur.
3. Sistemler arası ara katman
E-ticaret, pazaryeri, muhasebe ve depo yazılımı arasında ürün, stok, fiyat ve sipariş verisinin akması. En sık talep edilen iş budur ve teknik olarak da en çok hata potansiyeli taşıyanıdır. Ayrıntısını aşağıdaki entegrasyon bölümünde ele alıyoruz.
4. Raporlama ve konsolidasyon
Farklı sistemlerdeki verinin tek ekranda birleştirilmesi. Burada asıl iş rapor çizmek değil, sayıların hangi tanıma göre hesaplandığını sabitlemektir. İki departmanın aynı metriği farklı hesapladığı bir şirkette rapor yazılımı, tanım netleşmeden yapılırsa tartışmayı bitirmez, büyütür.
Entegrasyon katmanı: işin gerçekten zor kısmı
Özel yazılım projelerinde sürprizler ekranlardan değil, dış sistemlerden çıkar. Karşı sistemin belgesi eksiktir, alanlar beklenen biçimde gelmez, servis kimi zaman yanıt vermez, aynı kayıt iki kez düşer. Bu yüzden entegrasyonlarda standart olarak şu önlemleri kuruyoruz:
- Yeniden deneme ve kuyruk. Anlık başarısız olan istek kaybolmaz, artan aralıklarla tekrar denenir.
- Tekrar koruması. Aynı işlem iki kez geldiğinde ikinci kayıt oluşmaz; bu, sipariş ve fatura akışlarında en kritik korumadır.
- Hata kuyruğu. Otomatik çözülemeyen kayıtlar sessizce düşmez, ayrı bir listede birikir ve sorumlusuna görünür.
- İz kaydı. Hangi isteğin ne zaman gittiği ve ne yanıt aldığı saklanır; aksi hâlde "bizden gitti" tartışması hiç bitmez.
- Tek yön kararı. Her veri için hangi sistemin ana kaynak olduğu baştan belirlenir. İki sistemin aynı alanı karşılıklı güncellemesi, çözülmesi en pahalı hatalardan biridir.
Bir başka pratik nokta, platformların kendilerine özgü davranışlarıdır. Bazı e-ticaret ve pazaryeri arayüzlerinde alanların sırası, isteğin biçimi veya sayfalama davranışı belgelenenden farklı çalışır; bu tuzaklar yalnızca o platformla gerçekten çalışmış ekiplerce bilinir. Yalnızca sistemler arası veri akışı arıyorsanız ve yeni bir panele ihtiyacınız yoksa, bu iş özel çözümler ve entegrasyonlar kapsamında ayrı bir hizmet olarak da veriliyor.
Ismarlama yazılım projelerinde kapsam nasıl sabitlenir
Projelerin gerçek riski teknik zorluk değil, kapsamın sessizce büyümesidir. Her istek tek başına küçük görünür; toplamı takvimi ikiye katlar. Bunu üç kuralla yönetiyoruz.
Birincisi, kapsam belgesinde kapsam dışı başlığı bulunur ve orada yazan her madde açıkça listelenir. İkincisi, geliştirme sırasında çıkan yeni istek reddedilmez ama araya da sıkıştırılmaz: değerlendirilir, süresi ve bedeli çıkarılır, sıraya girer. Üçüncüsü, haftalık demolar bu kararların alındığı yerdir; hiçbir kapsam değişikliği yazılı hâle gelmeden uygulanmaz.
Bu disiplin ilk bakışta katı görünür, ama koruduğu şey teslim tarihidir. Yazılım projelerinde alıcı tarafın hangi noktalarda direnç göstermesi gerektiğini yazılım projesi yaptırmak yazısında ayrıntılı anlattık; oradaki kontrol listesini bizim tekliflerimize karşı da kullanabilirsiniz.
Kaynak kod mülkiyeti ve devir
Proje tamamlandığında kaynak kod, veritabanı şeması, kurulum notları ve teknik dokümantasyon size teslim edilir. Kodu başka bir ekibe devretmek için bizden izin almanız gerekmez ve kod bizim sunucumuzda rehin kalmaz. Bunu bir jest olarak değil, sağlıklı çalışmanın şartı olarak görüyoruz: ilişkinin sürmesi bağımlılıktan değil, işin iyi yürümesinden kaynaklanmalı.
İki noktanın altını çiziyoruz. Projede kullanılan açık kaynak kütüphaneler kendi lisanslarıyla gelir; bunlar sizin mülkiyetinize geçmez, kullanım hakkı lisansları çerçevesinde devam eder. İkincisi, ücretli bir üçüncü taraf bileşene ihtiyaç varsa bunu teklifte ayrı kalem olarak gösteriyoruz ki maliyet sonradan sürpriz olmasın.
Bakım anlaşması neyi kapsıyor
| Konu | Bakım kapsamında | Ayrı planlanır |
|---|---|---|
| Kapsam içindeki hataların düzeltilmesi | Evet | — |
| Sunucu, kütüphane ve güvenlik güncellemeleri | Evet | — |
| Yedeklerin kontrolü ve geri dönüş provası | Evet | — |
| İzleme ve hata bildirimlerinin takibi | Evet | — |
| Küçük düzenlemeler ve aylık geliştirme kapasitesi | Evet | Kapasiteyi aşan işler |
| Dış sistem arayüz değişikliğine uyum | Küçükse evet | Yeniden yazım gerektiriyorsa |
| Yeni modül veya yeni entegrasyon | Hayır | Ayrı proje olarak |
Bakım zorunlu değildir. Ancak canlıda çalışan bir iş süreç yazılımının izlenmeden bırakılması, sessizce biriken hataların ancak bir gün kritik bir işlem durduğunda fark edilmesi anlamına gelir. En azından izleme ve yedek kontrolünü içeren asgari bir paket öneriyoruz.
Benimseme: yazılım iyi olsa da kullanılmıyorsa
Özel yazılım projelerinin görünmeyen riski teknik değil, insan tarafındadır. Ekranlar doğru çalışsa bile ekip eski yöntemine devam ediyorsa proje başarısızdır. Bu yüzden geliştirme sırasında sahadaki kullanıcıyı sürecin içinde tutuyoruz: prototipi onlarla yürüyor, haftalık demolarda yalnızca yöneticiyi değil işi fiilen yapan kişiyi de masada istiyoruz.
Devreye almada tercih ettiğimiz yol paralel kullanımdır. Eski yöntem bir süre daha açık kalır, yeni sistem yanında çalışır ve ekip karşılaştırma imkânı bulur. Bu dönem uzatılmamalıdır; iki sistemin aylarca birlikte yaşaması, verinin ikiye bölünmesiyle sonuçlanır. Eğitimi de rol bazlı veriyoruz, çünkü yöneticinin ihtiyaç duyduğu ekranla saha kullanıcısının günde elli kez açtığı ekran farklıdır ve ikisine aynı sunumu yapmak ikisini de bilgisiz bırakır.
Sık yapılan beş hata
- Mevcut süreci yazmadan yazılıma başlamak. Kimsenin tarif etmediği istisnalar, kod yazıldıktan sonra ortaya çıkarsa yeniden yazım gerektirir.
- İlk sürüme her şeyi koymak. Kapsamı büyük tutmak, ilk faydayı aylarca erteler ve projenin şirket içindeki desteğini tüketir.
- Kuralları koda gömmek. Onay eşiği, komisyon oranı veya vade gibi değerler panelden yönetilemiyorsa her değişiklik geliştirici işi hâline gelir.
- Entegrasyonu son haftaya bırakmak. Dış sistemlerde çıkacak sürprizler yalnızca gerçek veriyle görülür; entegrasyonu erken açıp uzun süre test etmek gerekir.
- Tek bir kişinin bilgisine bağlı kalmak. Süreci yalnızca bir kişi biliyorsa, o kişinin izne çıkması projeyi durdurur. Kapsam belgesi bu riski de azaltır.
Özel yazılım fiyatını belirleyen kalemler
Ekran sayısı üzerinden fiyat vermiyoruz, çünkü aynı sayıda ekrana sahip iki proje arasında kat kat fark olabiliyor. Teklifte şu kalemler ayrı ayrı görünür:
- Kural sayısı ve karmaşıklığı. Bir ekranın arkasındaki istisna ve doğrulama kuralları, ekranın kendisinden daha çok emek ister.
- Entegrasyon sayısı ve karşı sistemin kalitesi. Belgelenmiş ve düzgün çalışan bir arayüz ile eski, belgesiz bir sistem aynı iş değildir.
- Rol ve yetki derinliği. Üç rol ile onlarca yetki kırılımı arasında ciddi fark vardır.
- Veri geçişi. Mevcut verinin miktarı, dağınıklığı ve temizlik ihtiyacı.
- Çalışma ortamı gereksinimleri. Bağlantısız çalışma, mobil kullanım veya yüksek erişilebilirlik beklentisi mimariyi büyütür.
- Raporlama derinliği. Liste ekranı ile çok boyutlu analiz ekranı arasındaki fark bütçeye doğrudan yansır.
- Kullanıcı sayısı ve yük beklentisi. Aynı anda çalışacak kullanıcı sayısı, altyapı kararlarını değiştirir.
- Uyum gereksinimleri. Kişisel veri işleme, saklama süreleri ve denetim izleri ek çalışma gerektirir.
- Takvim. Sıkıştırılmış teslim tarihi, paralel çalışan ekip demektir.
Bütçeyi küçültmek gerektiğinde önerdiğimiz yol, kaliteyi düşürmek değil kapsamı bölmektir: en çok zaman kaybettiren tek süreçle başlayıp, kazanç görüldükten sonra genişletmek. Bu yaklaşım hem riski hem de ilk faturayı düşürür.
Nereye bağlanıyor
Özel yazılım nadiren tek başına durur. Sürecin bir ucu satış tarafındaysa kurumsal web sitesi ile aynı veriyi paylaşacak şekilde kurgulanabilir; ekibin sahada kullanacağı bir arayüz gerekiyorsa mobil uygulama tarafı devreye girer. E-ticaret operasyonunuz varsa çoğu ihtiyacın kendi altyapımız RapiSoft üzerinde zaten karşılandığını görebiliriz; bu durumda sıfırdan geliştirme yerine yalnızca eksik parçayı yazmak daha hızlı ve ucuz olur.
Kurumsal yazılım kavramının kapsamını ve şirket içi sistemlerin sınıflandırmasını merak ediyorsanız kurumsal yazılım nedir yazısı çerçeveyi çiziyor. Kendi sürecinizi konuşmak isterseniz destek@stools.digital adresine yazabilir veya 0547 007 54 24 numarasından ulaşabilirsiniz; ilk görüşmede ne istediğinizi net bilmeniz gerekmiyor, süreci birlikte çıkarıyoruz.