Siparişleri mevcut programda kaydediyor, fakat üretim onaylarını mesajlardan ve ayrı dosyalardan takip ediyorsanız özel yazılım ihtiyacı aklınıza gelebilir. Önce eksik olanı ayırmak gerekir: Programın kullanılmayan bir ayarı mı, iki sistem arasında bağlantı mı, yoksa işletmenize özgü bir iş kuralı mı? Verilecek cevap, hazır çözümü kullanmaya devam etmekle yeni uygulama geliştirmek arasındaki kararı değiştirir.
Özel Yazılım Ne Anlama Gelir?
Özel yazılım, belirli bir işletmenin veya kullanıcı grubunun ihtiyaçlarına göre hazırlanan uygulamadır. IBM’in yazılım geliştirme açıklaması, özel geliştirmeyi belirli gereksinimlere; hazır ticari ürünü ise daha geniş kullanıcı ihtiyaçlarına göre ayırır.
Örneğin standart dışı ölçülerde üretim yapan bir işletme, siparişin üretime geçmeden teknik ekip tarafından onaylanmasını isteyebilir. Kimin hangi siparişi göreceği, hangi koşulda onay vereceği ve değişikliklerin nasıl izleneceği uygulamanın iş kurallarını oluşturur. Özel yazılımın konusu, ekrana şirket logosunu koymanın ötesindeki çalışma biçimidir.
Her satırın sıfırdan yazılması gerekmez. Var olan bileşenler veya uygulama geliştirme platformları kullanılabilir. Örneğin Microsoft’un canvas uygulamaları, işletmeye göre ekran ve veri akışı düzenlemeye imkân verir. Böyle bir tercih, platformun teknik sınırlarını ve lisans koşullarını da değerlendirmeyi gerektirir.
Hazır Program, Uyarlama ve Özel Geliştirme
Hazır program, önceden geliştirilmiş işlevleri olan üründür. Desteklediği ayarlarla alan, rol veya rapor düzenlemek uyarlama olabilir. Eksik işlev için kod veya bağlantı geliştirmek ise mevcut ürünün yanında özel bir parçanın çalışmasını sağlayabilir.
Hazır ürünler hiç değiştirilemez, özel yazılımlar da sınırsız değiştirilebilir diye düşünmek yanıltır. Hangi değişikliğin desteklendiği, nasıl test edileceği ve sonraki güncellemelerde korunup korunmayacağı incelenmelidir. GOV.UK’nin kamu hizmetleri için hazırladığı hazır ürün değerlendirmesi de kullanıcı ihtiyacını ve uyarlamayı hesaba katar. İşletme açısından alınacak ders, ürünün özellik listesini günlük iş üzerinden sınamaktır.
Eksik bağlantı, bütün sistemi değiştirme gerekçesi olmayabilir. Sipariş programı işinizi görüyor fakat onaylanan kayıt muhasebeye elle taşınıyorsa önce mevcut ürünün aktarım seçenekleri incelenebilir. Özel geliştirme yalnız aradaki bağlantıyla sınırlı kalabilir.
Hazır ve Özel Yazılımı Karşılaştırmak için 4 Ölçüt
1. İş Akışına Uyum
Özellik adına bakmak yerine bir işi baştan sona deneyin. “Onay sistemi var” bilgisi, siparişin hangi durumda teknik sorumluya gideceğini anlatmaz. Örnek siparişi girip düzeltme, onay ve iptal durumlarını görmek, eksikliği daha açık gösterir.
Hazır ürün gerekli adımları destekliyorsa onu kullanmak yeterli olabilir. İşletmenin vazgeçemeyeceği kural ürünün sunduğu yapıya sığmıyorsa uyarlama veya özel geliştirme değerlendirilir. Önce mevcut işin neden öyle yapıldığını anlamak gerekir; yıllardır sürdürülen her alışkanlık yazılıma aynen taşınmak zorunda değildir.
2. Veri ve Entegrasyon
Entegrasyon, ayrı sistemlerin birlikte çalışacak şekilde bağlanmasıdır. Yazılımlar, API adı verilen arayüzlerle tanımlı kurallar üzerinden iletişim kurabilir. AWS’nin API açıklaması, farklı uygulamalar arasındaki iletişimi temel alır.
Bir ürünün “API var” demesi tek başına yeterli cevap değildir. Gerekli sipariş alanları okunabiliyor mu, durum güncellenebiliyor mu, erişim hangi koşullarda sağlanıyor? Microsoft’un özel bağlayıcı belgeleri, hazır bağlantı bulunmadığında mevcut API’ye özel bağlantı eklenebildiğini gösterir.
Örnekte siparişin iki sistemde farklı numarayla kaydedilmesi, doğru kaydın hangisi olduğuna karar vermeyi zorlaştırabilir. Verinin nerede tutulacağı ve hangi kaydın esas alınacağı, ekran tasarımından ayrı bir karardır. Dışa aktarma olanağı da ileride başka sisteme geçiş açısından değerlendirilmelidir.
3. Toplam Maliyet ve Kullanıma Geçiş
İlk teklif veya aylık abonelik, toplam maliyetin tamamını göstermez. Kurulum, veri aktarımı, eğitim, bağlantılar ve devam eden bakım aynı karşılaştırmaya girer. Microsoft’un maliyet modeli açıklaması, lisans ve altyapının yanında personel, bakım ve destek giderlerini de ele alır.
Hazır üründe ihtiyaç duyulan işlevler mevcutsa başlangıç daha kısa olabilir; veri temizliği veya uyarlama işi süreyi değiştirebilir. Özel geliştirmede ise iş kuralları, uygulama ve test için zaman ayrılır. Kullanıma geçiş tarihi, kaç ekran çizildiğinden çok hangi işlerin çalışır ve denenmiş olduğuna bağlıdır. Kapsamı görmeden kesin fiyat veya teslim süresi söylemek sağlıklı olmaz.
4. Bakım ve Geliştirme Sorumluluğu
İşletmenin onay kuralı değiştiğinde kim düzenleme yapacak? Dış servis güncellendiğinde bağlantıyı kim kontrol edecek? Kullanıcılar sorun yaşadığında kime ulaşacak? Hazır ve özel seçeneklerin ikisinde de sorumluların belli olması gerekir.
Microsoft’un uygulama yaşam döngüsü açıklaması, geliştirme kadar test, işletim ve bakımı da kapsar. Hazır üründe sağlayıcının desteğiyle işletmenin kendi görevleri ayrılır. Özel yazılımda geliştirme ekibinin devam eden desteği, teknik belgeler ve başka bir ekibin çalışmayı sürdürebilmesi planlanır. Kaynak koduna erişmek tek başına bakım işini tamamlamaz. Abonelikle sunulan uygulamalarda görevlerin nasıl ayrıldığını SaaS kullanan işletme ile ürünü sunan ekip karşılaştırmasında görebilirsiniz.
Karşılaştırdığınız her seçenek için aynı soruyu sorun: “İş kuralımız değiştiğinde kim, hangi kapsamda müdahale edecek?” Yanıt, ilk satın alma anında görünmeyen sorumlulukları ortaya çıkarır.
Bir Sipariş Sürecinde Seçenekler Nasıl Ayrılır?
Varsayımsal üretici örneğinde satış ekibi sipariş giriyor, teknik sorumlu ölçüyü onaylıyor ve uygun kayıt üretime açılıyor. Sorunun yerine göre çözüm değişebilir:
| Görülen durum | Değerlendirilecek yol | Önce doğrulanacak konu |
|---|---|---|
| Onay işlevi var, henüz ayarlanmamış. | Hazır ürünü yapılandırmak. | Gerekli rol ve koşullar destekleniyor mu? |
| Onay çalışıyor, kayıt başka sisteme elle taşınıyor. | Mevcut sistemleri bağlamak. | Gerekli veriye ve işlemlere erişim var mı? |
| Ürünün akışı zorunlu iş kuralını karşılamıyor. | Özel modül veya uygulama geliştirmek. | Kural, sınırları ve bakım sorumlusu net mi? |
Aynı işletmenin bütün araçlarını tek seferde değiştirmesi gerekmez. Kullanılan muhasebe programı korunurken özel sipariş ekranı geliştirilebilir. Mevcut ürünlerde gerçek sipariş akışını denemek, hangi yolun uygun olduğunu görmeye yardımcı olur.
Tarayıcıdan kullanılan bir uygulama, web sitesiyle aynı teknolojilerden yararlanabilir. Ziyaretçiye hizmet anlatmakla çalışanların sipariş kurallarını işletmesi farklı işlerdir. Görünüm ve kullanım için web tasarımın temel sorularına bakabilirsiniz. İş kuralları ise uygulamanın hangi işlemi, hangi koşulda yapacağını belirler.
Karara Nereden Başlanır?
Tek bir günlük işlemi seçip kimlerin katıldığını, hangi bilgilerin kullanıldığını ve nerede aksadığını anlatın. Mevcut üründe çözüm bulunup bulunmadığı, küçük bir uyarlamanın yeterliliği ve özel uygulama gereksinimi o örnek üzerinden konuşulabilir. GOV.UK’nin teknoloji seçimi yaklaşımı, mevcut sistemleri anlamayı ve varsayımları prototiplerle sınamayı önerir. İlk kararın bütün geleceği kilitlemesi gerekmez.
İşinizdeki özel kuralı anlatabiliyor ama nasıl bir uygulama gerektiğini kestiremiyorsanız, Metazen’in yazılım ekibiyle mevcut araçları ve veri akışını birlikte değerlendirebiliriz. Özel yazılım hizmetimizde ilk çalışan sürümün kapsamını belirliyor, veri geçişi ve bakım sorumluluklarını da proje planına dahil ediyoruz.
