TRL 4 ile TRL 6 Arasındaki Uçurum: Ar-Ge Projelerinin Gerçekten Öldüğü Yer

Ar-Ge projelerinin başarısızlığı konuşulurken hep aynı yerlere bakılır: fikir yeterince iyi değildi, pazar yoktu, ekip dağıldı, fon bitti.

Sahada gördüğüm tablo farklı. Projelerin büyük kısmı fikir aşamasında ölmüyor. Laboratuvarda çalışan bir şeyin, sahada çalışan bir şeye dönüşmesi gereken yerde ölüyor. Teknoloji Hazırlık Seviyesi ölçeğinde bunun karşılığı yaklaşık olarak TRL 4 ile TRL 6 arasıdır ve literatürde bu bölgeye uzun süredir "ölüm vadisi" deniyor.

Bu yazı, o vadinin neden bu kadar derin olduğu ve bir program yöneticisinin oradan geçmeyi nasıl planlaması gerektiği üzerine.

Önce ölçek: TRL neyi ölçer?

Teknoloji Hazırlık Seviyesi (Technology Readiness Level), bir teknolojinin olgunluğunu 1'den 9'a kadar tanımlayan, NASA kökenli ve bugün savunma sanayii dâhil pek çok alanda standart olan bir ölçektir. Kabaca:

• TRL 1–3. Anlamı: Temel prensipler, kavram, kavramın deneysel kanıtı
• TRL 4. Anlamı: Laboratuvar ortamında doğrulanmış bileşen/breadboard
• TRL 5. Anlamı: İlgili ortamda doğrulanmış bileşen
• TRL 6. Anlamı: İlgili ortamda gösterilmiş sistem/alt sistem prototipi
• TRL 7. Anlamı: Operasyonel ortamda gösterilmiş prototip
• TRL 8–9. Anlamı: Nitelendirilmiş, uçuşta kanıtlanmış sistem

Dikkat edilmesi gereken kelime "ilgili ortam" (relevant environment). TRL 4 ile TRL 6 arasındaki bütün mesele bu iki kelimede saklı.

Uçurumun birinci nedeni: "ilgili ortam" tahmin ettiğinizden pahalıdır

TRL 4'te ürününüz masada çalışır. Oda sıcaklığında, sabit gerilimde, titreşimsiz bir masada, laboratuvar güç kaynağıyla, yanınızda onu tasarlayan mühendisle.

TRL 6'da aynı şeyin, kullanılacağı ortama benzeyen bir ortamda çalışması beklenir. Bu ortamın getirdiği yükler genellikle şunlardır:

• Sıcaklık aralığı. Masada çalışan bir devrenin eksi kırk derecede de, artı yetmişte de çalışması bambaşka bir tasarım problemidir.
• Titreşim ve şok. Lehim noktalarından konektör seçimine kadar her şeyi yeniden düşündürür.
• Elektromanyetik uyumluluk (EMC/EMI). Laboratuvarda kimsenin umursamadığı bir kablo yerleşimi, sahada sistemi çalışmaz hale getirebilir.
• Güç bütçesi. Laboratuvar güç kaynağı sonsuzdur; batarya değildir.
• Kullanıcı. Sistemi tasarlayan mühendis değil, sahadaki operatör kullanır. Ve o operatör, sizin hiç düşünmediğiniz sırayla düğmelere basar.

Bu maddelerin hiçbiri "yeni bir şey icat etmek" değildir. Hepsi mühendislik işidir. Ama toplamı, TRL 4'e kadar harcanan emeğin birkaç katı olabilir. Ve hiçbiri sunumda güzel görünmez. TRL 3'ten 4'e giderken demo yaparsınız, herkes alkışlar. TRL 4'ten 6'ya giderken aynı demoyu sadece daha zor koşullarda tekrar yaparsınız ve kimse alkışlamaz.

İkinci nedeni: finansman yapısı tam oraya denk gelen bir boşluk bırakır

Bu, Türkiye'ye özgü değil ama bizde de fazlasıyla geçerli.

Araştırma fonları (akademik projeler, TÜBİTAK'ın Ar-Ge destekleri, üniversite-sanayi iş birlikleri) doğaları gereği TRL 3–4 civarına kadar rahat çalışır. Yenilik vardır, bilimsel katkı vardır, yayın çıkar.

Yatırım ve seri üretim tarafı ise genellikle TRL 7 ve üzerini bekler. Bir yatırımcı ya da bir ana yüklenici, "sahada çalıştığını gördüğüm" bir şeye para koyar.

Arada kalan TRL 4–6 bandı ise ne yeterince yenidir ne yeterince hazırdır. Bilimsel katkısı azalmıştır, ticari kanıtı henüz yoktur. Bu bandın finansmanı çoğu zaman şirketin kendi kaynağından çıkar ve tam da bu yüzden en kolay kesilen kalemdir.

Program yöneticisinin buradaki görevi teknik değil, siyasidir: bu geçişin ayrı bir bütçe kalemi olarak, ayrı bir iş paketi olarak, ayrı bir takvimle planlanmasını sağlamak. "Prototip bitince zaten ürünleşir" cümlesi, bir projeyi öldürmenin en kibar yoludur.

Üçüncü nedeni: TRL 4 ekibi ile TRL 6 ekibi aynı ekip değildir

Bu, en az konuşulan ve bence en belirleyici olanı.

TRL 3–4 aşamasını iyi götüren insan profili; meraklı, hızlı deneyen, standarda takılmayan, "çalıştı işte" diyebilen mühendistir. Bu profil olmadan hiçbir şey başlamaz.

TRL 5–6 aşaması ise tam tersi bir profil ister: tekrarlanabilirlik, ölçüm, dokümantasyon, konfigürasyon kontrolü, test prosedürü, izlenebilirlik. Aynı testi yüz kere aynı şekilde yapıp sonuçları kaydedebilen insan.

Bu iki profil aynı kişide nadiren bulunur ve (daha önemlisi) birbirlerinin işini küçümsemeye meyillidirler. Birincisi ikinciyi bürokrat, ikincisi birinciyi özensiz bulur. Geçişin yönetilememesinin en yaygın sebebi teknik zorluk değil, bu kültür çatışmasının yönetilmemesidir.

Program yöneticisi ne yapar? Beş somut madde

1. TRL'yi sistem bazında değil, bileşen bazında ölçün. "Projemiz TRL 5'te" cümlesi neredeyse her zaman yanlıştır. Sistemin TRL'si, en olgunlaşmamış kritik bileşeninin TRL'sidir. Bileşen bazlı bir TRL tablosu tutun; hangi kutunun geride kaldığı görünür hale gelsin. Vadiye düşen sistem değil, o tek bileşendir.

2. Kalifikasyon planını TRL 4'te yazın, TRL 6'da değil. Hangi testleri, hangi standarda göre, hangi tesiste yapacağınızı prototip daha masadayken bilmek zorundasınız. Çünkü bu bilgi tasarımı değiştirir. Kalifikasyon planını sonra yazarsanız, plan tasarıma değil, tasarım plana uydurulmak zorunda kalır ve o noktada tasarımı değiştirmek pahalıdır.

3. "İlgili ortam"ı sözleşmeye ve gereksinim dokümanına sayıyla yazdırın. "Zorlu koşullarda çalışacaktır" bir gereksinim değildir. Sıcaklık aralığı, titreşim profili, koruma sınıfı, çalışma süresi: hepsi sayı olmalı. Sayı yoksa kabul kriteri de yoktur; kabul kriteri yoksa proje bitmez, sadece bir gün durur.

4. Ölçüm altyapısına erken yatırım yapın. Neyi ölçemiyorsanız onu iyileştiremezsiniz. Test düzeneği, veri kaydı, telemetri, otomatik test. Bunlar TRL 6'da ihtiyacınız olacak ama TRL 4'te kurmanız gereken şeylerdir. Vadiden geçerken elinizdeki tek pusula ölçüm verisidir.

5. Geçişi ayrı bir faz olarak ilan edin, sunumda da öyle gösterin. Yönetime "prototipimiz çalışıyor, ürünleştirme başlıyor" demek yerine, "TRL 4'teyiz, TRL 6 hedefi için şu iş paketleri, şu bütçe, şu süre gerekiyor" demek. Birincisi iyimserlik, ikincisi yönetimdir. Kesilen bütçelerin çoğu, birinci cümleyi kuran projelerden kesilir.

Kapanış

Ar-Ge yönetiminde en yaygın hata, zorluğun bilinmeyende olduğunu sanmaktır. Oysa bilinmeyen heyecan vericidir, insanlar onun üzerinde çalışmayı sever ve genelde de çözerler.

Projeleri öldüren şey bilinmeyen değil, bilinen ama sıkıcı olandır. Titreşim testi, sıcaklık döngüsü, EMC ölçümü, doküman, izlenebilirlik. Vadinin dibinde yatan projelerin çoğu, bilimsel problemi çözmüş ama bu listeyi planlamamış projelerdir.

Program yönetiminin işi tam olarak burasıdır: kimsenin heyecan duymadığı işi zamanında, bütçeli ve görünür kılmak.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.