İçeriğe geçin

Hazır yazılım mı, özel geliştirme mi? Aynı işle sınayın

Mevcut modülü, yeni bir ürünü ve özel geliştirmeyi; tutarı değişen bir masraf talebi ve sistem kesintisi üzerinden karşılaştırın.

Daniel Hartmann2 dk okuma
Dişli modülü ve kod simgeli yapboz parçası gösteren monitör; yeşil kalem vurguları.

Önce elinizdeki yazılımın kritik iş akışını karşılayıp karşılamadığını kontrol edin. Yeni bir ürünle özel geliştirmeyi karşılaştırmak için aynı kuralları, verileri ve istisnaları ele almak gerekir. Ekranların genel olarak tanıtılması bu soruyu cevaplamaz.

Deneme işlemi: tutarı değişen masraf talebi

Varsayımsal bir işletmede R-17 numaralı talep 180 EUR tutarındadır. Yönetici onayı gerekir; 250 EUR ve üzerinde finans birimi de onaya katılır. Bu eşik yalnız örnekteki iç kuraldır, vergi mevzuatından alınmamıştır. İlk onaydan sonra tutar 320 EUR olur. Önceki onay yeni tutar için kendiliğinden geçerli sayılmamalıdır.

Talep, tutar, belge, talep eden kişi, onaylayan kişi ve işlem durumu gerekir. Kurgusal isimler ve deneme belgeleri kullanın. Normal işlemin yanında şu durumları da gösterin:

Durum

Beklenen sonuç

R-17, 180 EUR

Yetkili yönetici onay verebilir; karar sonradan görülebilir.

Yönetici yok

Açıkça yetkilendirilmiş vekil devralabilir. Diğer çalışanlar bu nedenle onay yetkisi kazanmaz.

Tutar 320 EUR olur

Önceki onay geçersizleşir; yeniden incelemeye finans birimi de katılır.

ERP'deki bütçe servisine ulaşılamaz

Talep inceleme bekler; ekran bütçe onayı verilmiş gibi göstermez.

Her çözümü aynı koşullarda değerlendirin

Mevcut ERP modülüyle başlayın. Ardından uygun bir hazır ürünü, gerekli ERP bağlantısıyla birlikte deneyin. Her ikisinde de neyin çalıştığını, neyin ayarlanması gerektiğini ve hangi kısmın ek geliştirme istediğini ayırın.

Özel geliştirme bu aşamada kapsamı belirlenmiş bir uygulama önerisidir. Henüz yapılmamış özelliklerin durumu açıktır. Bir taslağa, başarıyla çalıştırılmış bir denemeyle aynı kanıt değerini vermeyin.

Somut bir sonuç örneği

Tamamen kurgusal bir deneme kaydında, mevcut sistemdeki A seçeneği vekil ayarlandıktan sonra dört durumu da karşılasın. Ek bir ürün olan B seçeneği normal talebi işlesin; fakat 320 EUR için önceki onayı korusun. Bütçe servisi kapalıyken de başarı mesajı versin. Bunlar gerçek ürünlere ilişkin bulgular değildir.

Bu örnekte A seçeneği değerlendirmede kalır. B için iki sorunun ayarla mı, geliştirmeyle mi çözüleceği açıklığa kavuşmalıdır. Yeni deneme ve ek çalışma teklifin kapsamına girer. Daha rahat kullanılan bir ekran, açık kalan işlem kurallarını karşılamaz.

Aynı kapsamın maliyetini karşılaştırın

Kurulum, veri taşıma, ERP bağlantısı, kullanım ücretleri, işletim, bakım ve ileride başka çözüme geçişi aynı süre için, örneğin üç yıl üzerinden değerlendirin. Kullanıcı sayısı ve değişiklik ihtiyacı varsayımlarını da yazın. GOV.UK hizmet standardı da teknoloji seçimini toplam maliyet ve ileride seçenek değiştirebilme ile birlikte ele alır.

Mevcut modül gerekli kuralları karşılıyorsa çözüm orada tamamlanabilir. Önemli bir durum denenen bütün ürünlerde açık kalıyorsa, hedefli bir eklenti veya özel uygulama için o durumu tarif edin. Böylece geliştirme kararının sınanabilir bir gerekçesi olur.

Kaynaklar

Yazan

  • Daniel HartmannTeknoloji ve İş Dünyası EditörüDaniel Hartmann, ASES'te işletmelerdeki teknoloji kararları üzerine yazar. Yazılım yatırımlarını, uygun çözümlerin seçimini ve dijital projelerin planlanmasını ele alır.

ASES'i takip edin

Devamını okuyun

Tüm yazılar

ASES ile Yazılım geliştirme

Özel yazılım, web ve mobil uygulamalar