Savunma Ar-Ge'sinin Önümüzdeki Beş Yılı: Program Yönetimi Neyi Değiştirmek Zorunda?

Bu yazıda kamuya açık kaynaklardan ve sektörün genel yöneliminden okunabilen dört eğilimi ve bunların program yönetimi tarafında zorunlu kıldığı değişiklikleri ele alacağım.

Kestirim yapmıyorum; hiçbir programın içeriğine dair bir şey söylemiyorum. Konuştuğum şey, yönetim pratiğinin nasıl uyum sağlaması gerektiği.

Dört eğilim

1. Otonomi seviyesinin yükselmesi. Uzaktan kumandalı sistemlerden, görev seviyesinde karar verebilen sistemlere doğru bir kayma var. Bu, teknolojik olduğu kadar doktrinel bir değişim ve haberleşmenin kısıtlandığı ortamlarda çalışabilme ihtiyacından besleniyor.

2. Sürü ve iş birlikli kabiliyetler. Tek bir yüksek maliyetli platform yerine, birbiriyle koordine olan çok sayıda düşük maliyetli platform. Bu yaklaşımın maliyet-etkinlik mantığı güçlü ve küresel ölçekte yaygınlaşıyor.

3. Düşük maliyetli, sarf edilebilir sistemler. Kaybedilmesi göze alınabilen sistemler, tasarım felsefesini kökten değiştiriyor. Uzun ömür, ağır kalifikasyon ve yüksek güvenilirlik yerine; düşük birim maliyet, hızlı üretim ve yeterli güvenilirlik.

4. Yazılım tanımlı platformlar. Donanımın sabit, kabiliyetin yazılımla tanımlandığı mimariler. Aynı platformun yazılım güncellemesiyle yeni bir görev yapabilmesi.

Bu dördü birbirini besliyor: sürü, otonomi olmadan yönetilemez; sarf edilebilirlik, düşük maliyet olmadan anlamsızdır; hızlı kabiliyet ekleme, yazılım tanımlı mimari olmadan mümkün değildir.

Program yönetimi tarafında ne değişmek zorunda?

1. Kalifikasyon felsefesi ölçeklenmek zorunda

Mevcut kalifikasyon yaklaşımı, uzun ömürlü ve pahalı platformlar için tasarlandı. Her bileşenin ayrıntılı nitelendirilmesi, kapsamlı çevre testleri, uzun doğrulama kampanyaları.

Birim maliyeti düşük ve sayıca çok olan bir sistemde bu yaklaşım ekonomik olarak çalışmaz. Kalifikasyon maliyeti, ürün maliyetinin katlarına çıkabilir.

Gereken şey risk temelli, kademeli kalifikasyon: kayıp maliyeti düşük sistemlerde daha hafif, kritik alt sistemlerde tam kapsamlı. Bunu yapabilmek için önce şu sorunun kurumsal olarak cevaplanması gerekiyor: "Bu sistemin başarısızlık maliyeti nedir ve buna orantılı doğrulama seviyesi hangisidir?"

Bu, teknik bir soru değil, kurumsal risk iştahı sorusudur. Ve program yöneticisinin tek başına cevaplayabileceği bir soru değildir, ama sorulmasını sağlaması gereken kişidir.

2. Doğrulama, sistemden sürüye taşınmak zorunda

Tek bir aracın doğrulanması bilinen bir iştir. Yüz aracın birlikte davranışının doğrulanması bambaşka bir problemdir.

Çoklu sistemlerde ortaya çıkan davranışlar, tek tek bileşenlerin davranışından türetilemez. Her araç doğru çalışırken, sürünün tamamı istenmeyen bir davranış sergileyebilir.

Bunun tek pratik doğrulama yolu büyük ölçekli simülasyon. Yüz aracı sahada tekrar tekrar uçurmak ne ekonomik ne pratiktir; simülasyonda binlerce senaryo koşturmak mümkündür.

Yani simülasyon altyapısı, artık bir geliştirme kolaylığı değil kalifikasyon kanıtının kendisi haline geliyor. Bu, simülasyon ortamının kendisinin de doğrulanmasını gerektiriyor ve bu, çoğu kurumun henüz kurmadığı bir disiplin.

3. Yazılım, konfigürasyon yönetiminin merkezine geçmek zorunda

Yazılım tanımlı platformlarda kabiliyet, yazılım versiyonuyla tanımlanır. Bu, konfigürasyon yönetiminin ağırlık merkezini donanımdan yazılıma kaydırıyor.

Zor kısmı şu: sahadaki her platformun hangi yazılım versiyonunu çalıştırdığının bilinmesi, güncelleme mekanizmasının güvenli olması ve her versiyonun ayrı ayrı doğrulanmış olması gerekiyor.

Buna bir de öğrenme tabanlı bileşenler eklendiğinde konfigürasyon öğesi sayısı artıyor: kod versiyonu, model versiyonu, model eğitiminde kullanılan veri kümesinin versiyonu. Aynı girdilerle aynı çıktıyı yeniden üretebilmek, yani tekrarlanabilirlik, burada zorlaşıyor.

Bu, klasik konfigürasyon yönetimi araçlarının doğrudan karşılamadığı bir ihtiyaç.

4. Tedarik zinciri, tasarım kriteri haline gelmek zorunda

Sayıca çok üretilen sistemlerde tedarik zinciri, bir destek fonksiyonu değil birincil tasarım kısıtıdır.

Bir bileşenin teknik olarak en iyi olması yetmez; yeterli hacimde, öngörülebilir sürede ve sürdürülebilir maliyetle temin edilebilir olması gerekir. Bu, tasarım kararlarının verildiği masaya tedarik bilgisinin taşınmasını gerektiriyor (ki bu, çoğu kurumda yapısal olarak ayrı iki dünya).

Millileştirme yönelimi de bu başlığın altında: stratejik olarak doğru, ama daha önce yazdığım gibi kendisi de bir Ar-Ge programı ve o şekilde bütçelenmesi gerekiyor.

5. Geliştirme döngüsü kısalmak zorunda, ama disiplin kaybedilmeden

En zor madde bu.

Kabiliyet ihtiyacının değişim hızı, klasik geliştirme takvimlerinden yüksek. Buna verilen yaygın cevap "daha çevik olalım" oluyor ve bu cevap, savunma bağlamında dikkatli kurulmazsa tehlikeli.

Çünkü çeviklik, doğrulama disiplininden ödün vermek anlamına gelirse, sonuç hızlı üretilmiş güvenilmez sistemlerdir. Emniyet-kritik bir alanda bu kabul edilemez.

Gerçekten işe yarayan yaklaşım, hızı doğrulamadan kısarak değil, doğrulamayı otomatikleştirerek elde etmek: sürekli entegrasyon, otomatik regresyon testleri, simülasyon tabanlı kabul senaryoları, donanım-döngüde test tezgâhları.

Yani hız, süreçten kısarak değil altyapıya yatırım yaparak geliyor. Ve bu yatırım önden yapılıyor, getirisi sonra geliyor; bu yüzden de bütçelenmesi en zor kalem.

Bu, yetkinlik profilini de değiştiriyor

Yukarıdaki beş maddenin ortak sonucu şu: teknik ile yönetsel arasındaki mesafe kapanıyor.

Simülasyonun kalifikasyon kanıtı haline geldiği, konfigürasyonun model versiyonlarını kapsadığı, tedarik kararının tasarım kararı olduğu bir ortamda; sadece takvim ve bütçe konuşan bir program yöneticisi doğru soruları soramaz.

Bu, teknik yöneticinin üstün olduğu anlamına gelmiyor. Şu anlama geliyor: bu iki alan arasında tercüme yapabilen insana olan ihtiyaç artıyor. Ne saf teknik uzman ne saf yönetici: arada duran.

Ve bu profil, yetiştirilmesi en uzun süren profil olduğu için, sektörün önümüzdeki dönemdeki dar boğazlarından biri olacağını düşünüyorum.

Kapanış

Bu yazıdaki hiçbir madde teknolojik bir öngörü değil. Hepsi, hâlihazırda görünen yönelimlerin yönetim pratiğine ne yaptığıyla ilgili.

Ve ortak temaları şu: eski araçlar yanlış değil, ölçekleri yanlış. Kalifikasyon, konfigürasyon yönetimi, doğrulama, tedarik disiplini; hepsi hâlâ gerekli. Ama her birinin, farklı maliyet ve farklı sayıda üretilen sistemler için yeniden ayarlanması gerekiyor.

Bunu yapmayan kurumlar iki hatadan birine düşecek: ya yeni sistemlere eski ağırlıkta süreç uygulayıp ekonomik olarak rekabet edemeyecekler, ya da süreci tamamen bırakıp güvenilmez sistemler üretecekler.

Doğru cevap ikisinin arasında ve orada durmak, iki uçta durmaktan zordur.

---

Bu yazıdaki değerlendirmeler kamuya açık kaynaklara ve genel sektörel yönelimlere dayanmaktadır. Görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.