Özel Yazılım İçin İş Gerekçesi Nasıl Hazırlanır?

Özel yazılım iş gerekçesi dört sayıya ihtiyaç duyar: mevcut durumun bugün size maliyeti, yazılımın değiştirmesi beklenen şey, üç yıllık geliştirme ve işletme maliyeti ve hazır çözümün dürüst karşılığı. Hiçbir şey yapmama maliyetini içermeyen bir gerekçe, gerekçe değil savunmadır.

Reddedilen tekliflerin çoğu birincide değil üçüncü ve dördüncüde başarısız olur. Bu rehber, kararın onu yazmayan birinin incelemesinden geçebilmesi için her parçanın nasıl kurulacağını anlatır.

Önemli noktalar

• Önce mevcut durumu fiyatlandırın: Sorunu olduğu gibi bırakmak bedava ise gerekçe yoktur; bedava değilse en güçlü argümanınız o sayıdır.
• Geliştirme bedelini değil üç yılı kullanın: Süregelen maliyet yıllık olarak geliştirmenin %15–25'i kadardır ve en sık atlanan kalemdir.
• Hazır çözümle dürüstçe karşılaştırın: Gerçek neden maliyetlendirilmiş bir kısıt değil de tercihse, standart araç genellikle daha doğru ticari karardır.
• Neyin bu kararı yanlış çıkaracağını yazın: En zayıf varsayımını kendi söyleyen bir gerekçe, kusursuz görünenden daha kolay onaylanır.

Hiçbir şey yapmamanın maliyetiyle başlayın

Mevcut durumu, finans ekibinizin zaten kullandığı birimlerle sayısallaştırın. Vaka başına harcanan saat çarpı yüklü maliyet. Hata oranı çarpı bir hatanın bedeli. Rakipler bir günde yaparken dört gün süren bir süreç yüzünden kaybedilen gelir. Araçların açıkça ayrılma gerekçesi olduğu bir rolde personel devri.

Burada kesinlik değil, savunulabilir bir büyüklük mertebesi ve açıklanmış bir yöntem gerekir. İki hafta boyunca yirmi gerçek vakayı uçtan uca ölçmek, kendinden emin bir tahminden çok daha inandırıcı bir başlangıç değeri üretir ve neredeyse hiçbir maliyeti yoktur.

Gerekçenin geri kalanı bu sayıya göre ölçülür. O olmadan iddia ettiğiniz her fayda sınanamaz hale gelir ve inceleyenler sınanamayan faydaları sıfır sayar.

Dört parçalı karşılaştırmayı kurun

Mevcut maliyet, yukarıdaki başlangıç değeridir; yıllık rakam olarak ifade edilir.

Beklenen değer, neyin değişeceğidir ve aynı birimlerle yazılır. Muhafazakâr ve açık olun: "çevrim süresi dört günden bire iner, bu da yılda yaklaşık 900 saatlik takip işini ortadan kaldırır" incelenebilir bir ifadedir. "Verimlilik artışı" değildir.

Teslimat riski, geliştirmenin planlanandan pahalıya gelme veya daha azını sunma olasılığı ve buna karşı ne yapacağınızdır. Bunu yazmak gerekçeyi zayıflatmaz, güçlendirir; deneyimli her inceleyen riskin var olduğunu bilir ve onu görmezden gelen bir gerekçe kendinden emin değil toy görünür.

Sahiplik, lansmandan sonra sonucu kimin işleteceğidir: işletmek için gereken iç zaman, değiştirmek için bütçe ve sonuçtan sorumlu kişi. Bunu atlayan gerekçeler çalışan ve sonra çürüyen yazılımlar üretir.

Üç yıllık toplam maliyeti hesaplayın

Geliştirme bedeli, onayladığınız şeyin en küçük parçasıdır. Eksiksiz bir rakam şunları içerir:

• Yönetim arayüzü ve her entegrasyon dahil geliştirme
• Barındırma, üçüncü taraf servisler ve lisanslar
• Bakım, güvenlik güncellemeleri ve platform değişiklikleri
• İç veya sözleşmeli destek
• İşletmek ve yönetmek için harcanan iç zaman
• İkinci ve üçüncü yıldaki değişiklik maliyeti — ki bu hiçbir zaman sıfır değildir

Süregelen maliyet genellikle yıllık olarak geliştirmenin %15 ile %25'i arasındadır. 80.000 avroluk bir geliştirme, gerçekte 140.000–160.000 avroluk üç yıllık bir taahhüttür. Yalnızca geliştirme rakamını sunmak, bir iş gerekçesinin onaylanıp sonra sessizce pişmanlık duyulmasının en yaygın nedenidir.

Hazır çözümle kendinizi kandırmadan karşılaştırın

Bu ihtiyacı karşılayabilecek standart ürünleri ve her birinin yapamadığı belirli şeyi adlandırın. Sonra o boşluğu yıllık olarak fiyatlandırın.

Boşluk gerçek bir kısıtsa — hiçbir ürünün desteklemediği fiyatlandırma kuralları, standart araçlarda karşılığı olmayan bir onay hiyerarşisi, düzenleyici bir gereklilik — geliştirmek için gerçek bir gerekçeniz var demektir. Dürüst yanıt standart aracın çalışabilir ama sevilmediği ise, ticari karar onu satın alıp aradaki farkı başka yere harcamaktır.

Hazır çözümün yapılandırma ve entegrasyon maliyetini de dahil edin. Tam bir özel geliştirmeyi, hiçbir uygulama maliyeti eklenmemiş bir lisans bedeliyle karşılaştırmak, kimse kasıtlı yapmasa da bu karşılaştırmanın en sık çarpıtılma biçimidir.

Bu kararın içinde yer aldığı daha geniş programı görmek için dijital dönüşüm yol haritası rehberine bakın.

Ölçütü ve gözden geçirme noktasını yazın

Her gerekçe, işe yarayıp yaramadığını gösterecek ölçütü, kontrol edileceği tarihi ve kimin kontrol edeceğini adlandırmalıdır. Çevrim süresi ve hata oranı gibi operasyonel ölçütler yayına girdikten sonraki çeyrek içinde hareket etmelidir. İki çeyrek sonra hareket etmediyse sorun benimseme veya kapsamdır ve daha fazla teslimat bunu çözmez.

Bunu önceden taahhüt etmek kararın kalitesini değiştirir. Aynı zamanda sizi korur: önceden üzerinde anlaşılmış bir sayıya göre değerlendirilen bir proje, sonradan hikâyeyi en iyi anlatan kişiye göre değil kanıta göre yargılanır.

Bu kararı yanlış çıkaracak şeyi yazın

Gerekçeyi, en çok bağlı olduğu iki üç varsayımla ve yanlış olsalardı ne göreceğinizle bitirin. Gerçekleşmeyen hacim. Geliştirme bitmeden değişen bir süreç. Desteklenmediği ortaya çıkan bir entegrasyon.

Bu bölüm, iş gerekçesini sunumdan ayıran şeydir. İnceleyenler, yanılma ihtimalini düşünmüş kişilerin tekliflerini onaylar; çünkü bir şey yapabilecek kadar erken fark edecek olanlar onlardır.

İlgili rehberler

İlgili içerikler:

• Otomasyon Keşif Aşaması Hangi Çıktıları Sağlamalı?
• Dijital Dönüşüm İş Ortağı Nasıl Seçilir?
• Pratik Bir Dijital Dönüşüm Yol Haritası Nasıl Hazırlanır?

Özel Yazılım İçin İş Gerekçesi Nasıl Hazırlanır? rehberinden doğan çalışma; ürün stratejisi, tasarım, geliştirme veya entegrasyon desteği gerektiren somut bir girişime dönüşürse Dijital Yol Haritanızı Konuşalım.