BT projeleri: rekabet avantajı yerine maliyet faktörü
BT projelerinin rekabet avantajı vaat ettiği uzun zamandır söylenmektedir. Ancak gerçekte, bir BT projesi, elektrik veya kiradan farklı olmayan bir maliyet faktörü olarak ele alınır. Ama farklı olabilir.
Muhtemelen BT’deki herkes etkili BT’nin rekabet avantajı yarattığını düşünüyor. Verilerin yeni petrol olduğu biliniyor. Dijitalleşme her şeyi yazılıma dönüştürüyor ve yazılımı kontrol eden, pazarı da kontrol ediyor. Bu faydaları fiilen gerçekleştirmek için BT projelerine açıkça ihtiyaç vardır.
Tipik bir BT projesine bakalım. Maliyetler neredeyse her zaman bilinir. Devam eden personel maliyetleri nispeten kolay belirlenebilir, projenin süresi de bilinir ve donanım maliyetleri gibi faktörler genellikle çok doğru belirlenir. Süreler ve son tarihler tahmin edilir, bütçeler belirlenir ve aşılırsa bu elbette yönetilir. Ve önemli ihlallerin ciddi sonuçları vardır.
kurumsal hedefler?
BT projeleri rekabet avantajı sağlayacaksa, yeni pazarlar açmak veya bilinen süreçleri optimize etmek için iş hedefleri de yönetilmelidir. Hedeflerin gerçekten odak noktası olması gerekir. Tabii ki, projeler genellikle, örneğin bir sunumda kaydedilen ve bir projeyi gerekçelendirmek ve başlatmak için kullanılan bir iş gerekçesine dayanır. Ancak bu, devam eden projelerde gerçekte ne olacağını hedeflerin belirlediği anlamına gelmez.
Danışman olarak gördüğünüz çeşitli projelerde, projelerin iş hedefleri ekipler için her zaman net değildir. Örneğin, bazı projelerde, nihai müşteriler için faydalar gibi hedefler vardır, ancak bunlar ekibe iletilmez veya günlük işleri belirlemez. Diğer projelerde hedefler belirsizliğini koruyor.
Öte yandan, kalan eforu ve nihayetinde kalan zamanı ve bütçeyi gösteren ve bunu herkese açık bir şekilde ileten yanma çizelgeleri gibi araçlar yaygındır. Dediğim gibi: maliyetler ve bütçeler her zaman yönetilir. İlginç bir şekilde, aslında iş hedeflerine daha iyi ulaşmayı vaat eden çevik projelerde bir tükenmişlik çizelgesi yaygındır.
İş hedeflerinin ihmal edilmesine bir örnek, yeni bir teknolojiye geçiş planları olabilir. İşlevsellik açısından değişen bir şey yok. Bu, daha düşük işletme maliyetleri veya istikrarlı uzun vadeli işletme gibi bir iş hedefine izin verir, ancak bu tür tasarımlar genellikle mantığı değiştirerek diğer iş hedeflerini oldukça kolay bir şekilde uygulayabilir. Sonuçta, sistem yine de tamamen dönüştürülecek. Bu fırsatı, sistemi iyileştirmek ve böylece daha fazla kurumsal değer yaratmak için kullanabilirsiniz. Ancak bu aynı zamanda projeyi çok karmaşık ve riskli hale getirebilir. Bununla birlikte, ek iş değeri ile risk arasında böyle bir değiş tokuş genellikle yapılmaz: Öte yandan, bu projelerde maliyetler de izlenir.
iş değeri?
BT’yi bir rekabet avantajı olarak deneyimlemek istiyorsanız, yalnızca iş hedeflerini bilmeniz değil, aynı zamanda iş gerekçesini parasal bir miktar olarak tahmin etmeniz gerekir. Örneğin, bir projeden daha fazla satış veya kar bekliyorsanız, bunun ne kadar değerli olduğunu hesaplayabilirsiniz. Bir şirketin değeri aynı zamanda finansal parametrelerle belirlenir, peki aynısını neden bir proje için yapmıyorsunuz?
Artık bir projenin ticari değerini belirlemenin harcanan ve kalan bütçeden çok daha zor olduğu söylenebilir. Ancak bir yazılım projesi için harcanan çabayı tahmin etmek de zordur. Aslında bu imkansızdır, çünkü yazılım projeleri o kadar karmaşıktır ki detaylı bir şekilde planlanamaz. Bu nedenle, küçük boyutlarından dolayı tahmin edilmesi daha kolay olan tek küçük artışlar için ilerleyen yinelemeli artımlı yöntemler kullanılır. Bu nedenle yazılım geliştirme ekipleri, olumsuz koşullara rağmen giderleri ve bütçeleri tahmin etmede kendilerini zorlamak zorundadır. Projelerin ticari değerini tahmin etmek aslında daha mı zor? En azından deneyebilirsin, ama böyle bir girişim bile genellikle yapılmaz. Bu değerleri belirlemeye yönelik yapılandırılmış yaklaşımlar vardır – bunları uygulamanız yeterlidir.
Artı, özellikle ticari değer söz konusu olduğunda büyük sürprizler yaşayabilirsiniz: müşteri bulmayan bir ürünün değeri yoktur. Bu nedenle, iş değerini belirlemek ve bütçelemeye kıyasla onu takip etmek aslında daha da önemlidir. Çünkü işe yaramaz bir şeye para harcarsanız, hiçbir anlamı kalmaz. Öte yandan, müşteriler tarafından çok değer verilen ve dolayısıyla değerli olan projeleri daha iyi destekleme fırsatını kaçırırsanız, bu da bir o kadar kötüdür.
Bir projenin değeri önemli olabilir. Müşterinin yeni yazılımı beklerken diğer finansal işlemleri sonuçlandırabilmesi ve dolayısıyla proje bütçesini oluşturabilmesi nedeniyle daha başlamadan kendi masrafını çıkaran bir proje hatırlıyorum. Ve yazılım giderek daha önemli hale geldikçe, iyi yazılımın değeri de artıyor.
Böyle bir mali değerlendirmeniz olsa projelerdeki şartlar değişirdi. Çabadan nerede tasarruf edebileceğinizi sormak yerine, birdenbire en fazla değeri nerede yaratabileceğiniz sorusu aynı derecede önemli hale gelir. Bu sadece bütçe aşımlarıyla ilgili değil, aynı zamanda değer yaratmayla da ilgili. İş değeri için böyle bir mali ölçüt olmadan, her zaman bilinen tek mali ölçütler bunlar olduğundan, projeleri maliyete dayalı olarak değerlendirmek ve optimize etmek mantıklıdır.
teslimat süresi?
Bir projenin iş değerine ek olarak, BT için önemli olduğu söylenen başka bir ölçü daha vardır: bir özelliğin fiilen üretime girmesine kadar geçen süre. Ancak burada da bu boyutun gerçekten aktif olarak yönetilip yönetilmediği sorusu ortaya çıkıyor. Projeler, üretimde bir değişikliği ne kadar çabuk gerçekleştirebileceklerini kesinlikle bilirler. Bu sayıyı bildirip bildirmedikleri ve bununla ölçülüp ölçülmediği tamamen başka bir konudur. Ayrıca, burada da aynısı geçerlidir: bir değer, parasal bir miktar olarak ifade edilebilmelidir. Bunun için kullanılabilecek bir boyut var mı: Bir özellik ertelenirse ne kadar maliyet doğar? Buna “gecikme maliyeti” denir.
“State of DevOps 2018” raporunda Maersk’ten ilginç bir grafik var (sayfa 46). Bu, muhtemelen müşterilerin atlaması veya süreçlerin zamanında optimize edilememesi nedeniyle bir hafta geciktirmenin 7 milyon dolara mal olacağı üç özellik olduğunu gösteriyor. Bu tür çizelgeler veya listeler projelerde nadirdir. Diğer bir deyişle, teslimat süresi o kadar önemsizdir ki, olası faydayı finansal olarak değerlendirmeye bile gerek yoktur.
Çözüm
Bu nedenle, bir projenin maliyetini finansal olarak değerlendirmek ve izlemek yaygındır. Kurumsal hedefler genellikle yanlış iletilir. Ve aslında bir projenin ticari değerini parasal terimlerle ifade etmek çok sıra dışı. Böylece odak, değer yaratmaktan, gerçekten bilinen tek miktar olan maliyet optimizasyonuna kayar. Bu nedenle BT, kasıtsız ve plansız bir şekilde rekabetçi bir faktör olmaktan çok bir maliyet haline gelir. Elbette böyle olmak zorunda değil: Ancak bunu yapmak için kurumsal hedefler, kurumsal değer, iş gerekçesi ve dolayısıyla üretilen değerlerin finansal parametreler olarak bilinmesi ve ideal olarak oluşturulması gerekir.
tl; doktor
BT proje maliyetleri genellikle yönetilir, ancak yaratılan potansiyel değer parasal olarak hesaplanmaz bile. Bu şekilde, BT saf bir maliyet faktörü haline gelir.
Makalenin önceki bir versiyonuna yaptıkları yorumlar için meslektaşlarım Gerrit Beine, Matthias Déjà, Anja Kammer ve Stefan Tilkov’a çok teşekkürler.
()
ana sayfaya