
Teknoparktan Tedarikçi Koltuğuna: Aynı Ekosistemi İki Taraftan Görmek
Kariyerimin ilk uzun dönemini bir teknoloji geliştirme bölgesinde geçirdim; bilişim sistemleri ve ardından strateji ve iş geliştirme tarafında. Yani masanın bir tarafındaydım: bölgedeki şirketlere bakan, onların projelerini, teşviklerini, büyümelerini ve batışlarını dışarıdan gören taraf.
Sonra masanın diğer tarafına geçtim. Bir Ar-Ge şirketinde proje ve program yöneticisi olarak, daha önce dışarıdan izlediğim şeyin içinde çalışmaya başladım.
Bu geçiş, ekosistem hakkında sahip olduğum kanaatlerin bir kısmını doğruladı, bir kısmını tamamen çöpe attırdı. Bu yazı o envanterin kaydı.
Teknopark tarafından bakınca gördükleriniz
Bölge yönetiminde çalışırken aynı anda onlarca şirketi görürsünüz. Bu, tek bir şirketin içinden asla elde edemeyeceğiniz bir örneklem. Ve o örneklemde bazı örüntüler tekrar tekrar görünür.
Şirketler teknik nedenlerle batmıyor. Batmalarının en yaygın sebebi nakit akışıydı. İkinci sırada kurucu ortaklar arasındaki anlaşmazlık geliyordu. Teknoloji problemi çözemedikleri için kapanan şirket sayısı, ilk ikisinin yanında istatistiksel olarak önemsizdi.
Ar-Ge teşviki bir gelir modeli değildir. Sürekli tekrar eden bir kalıp: şirket bir destek programından fon alır, o fonla çalışır, proje biter, hemen bir sonraki başvuruyu yapar. Bir süre sonra şirketin asıl faaliyeti proje yazmak olur; ürün ise bir türlü müşteriye ulaşmaz. Teşvik, ürünleşme yolundaki bir köprü olmaktan çıkıp bir yaşam biçimine dönüşür.
Herkes aynı üç hatayı yapıyordu. Müşteriyle konuşmadan geliştirmek; ilk müşteriye özel iş yapıp bunu ürün sanmak; ve fikri mülkiyeti çok geç düşünmek.
Bu gözlemler doğruydu. Bugün de doğru olduklarını düşünüyorum. Ama eksiktiler.
Diğer tarafa geçince yanıldığınızı anladığınız yerler
Yanılgı 1: "Bu şirketler neden bu kadar yavaş?"
Dışarıdan bakınca bir Ar-Ge şirketinin altı ayda bitirmesi gereken işi iki yılda bitirmesi anlaşılmazdır. Ben de öyle düşünürdüm.
İçeriden bakınca görülen şey şu: o iki yılın büyük kısmı geliştirmede değil, beklemede geçiyor. Kritik bileşenin gelmesi, müşterinin gereksinimi netleştirmesi, test tesisinin müsaitliği, bir onayın çıkması, bir yetkinin verilmesi. Takvimi belirleyen şey ekibin hızı değil, ekibin kontrolü dışındaki bağımlılıklar.
Bunu bilmeden yapılan "hızlanın" baskısı, ekibi hızlandırmaz; sadece yorar.
Yanılgı 2: "Ana yüklenici bürokrasiyi seviyor."
Teknopark tarafındayken KOBİ'lerin ana yüklenici süreçlerinden şikâyetini sık duyardım ve haklı bulurdum: onlarca sayfa doküman, uzun onay zincirleri, ağır kalite şartları.
Tedarikçi tarafına geçtikten sonra öğrendiğim şey, bu şartların çoğunun keyfi olmadığı. Ana yüklenici kendi müşterisine karşı, sizin teslim ettiğiniz parçanın davranışından sorumlu. Sizden istediği izlenebilirlik kaydı, kendi izlenebilirlik zincirinin bir halkası. Sizden istediği kalifikasyon raporu, kendi kalifikasyon dosyasının eki.
Yine de itirazın haklı kaldığı bir yer var: bu şartlar ölçeklenmiyor. Bir KOBİ'den, on kat büyük bir şirketle aynı süreç olgunluğunu aynı takvimde beklemek gerçekçi değil. Sorun şartların varlığı değil, orantısızlığı.
Yanılgı 3: "İş geliştirme, teknik ekipten ayrı bir iştir."
Teknopark tarafında iş geliştirmeyi ağırlıklı olarak ilişki, tanıtım ve eşleştirme işi olarak görürdüm. Savunma tarafında bunun çalışmadığını gördüm.
Bu sektörde bir iş, ana yüklenicinin bir teknik problemi olduğunda ve sizin o problemi çözebileceğinize dair somut kanıtınız olduğunda gelir. Kanıt derken referans mektubu değil; çalışan bir prototip, geçilmiş bir test, kalifiye edilmiş bir süreç. İş geliştirmenin girdisi teknik olgunluktur. Teknik olgunluk yoksa yapılan iş geliştirme faaliyeti, olmayan bir şeyi satmaya çalışmaktır.
İki tarafın da birbiri hakkında bilmediği
Şirketlerin bölge yönetimi hakkında bilmediği: bölge yönetimindeki insanlar sizin başarınızı gerçekten istiyor, çünkü bölgenin performans göstergeleri doğrudan sizin çıktılarınıza bağlı. Bu yapısal bir çıkar birliği. Buna rağmen çoğu şirket, bölge yönetimini bir kira muhatabı ve bir denetim mercii olarak görüp sadece zorunlu olduğunda temas ediyor. Kullanılmayan bir kaynak.
Bölge yönetimlerinin şirketler hakkında bilmediği: teknik bir ekibin en kıt kaynağı zaman değil, dikkat. Bir mühendislik ekibi derin çalışma halindeyken, iyi niyetle düzenlenen bir etkinlik, bir anket, bir tanıtım toplantısı gerçek bir maliyettir. Ekosistem hizmetlerinin değerini "kaç etkinlik yapıldı" ile ölçmek, tam da bu maliyeti görmezden gelir.
Bu geçişin bana kazandırdığı yönetsel şey
En somut faydası şu: bir işin neden geciktiğini, gecikmeyi yaşayan tarafın diliyle anlatabilmek.
Bir ana yükleniciye "tedarik gecikmesi" demek yerine, onun kendi programında neyin kayacağını konuşabilmek. Bir mühendis ekibine "müşteri sabırsız" demek yerine, müşterinin hangi taahhüt altında olduğunu anlatabilmek. Bir kamu destek programına, projenin neden planlandığı gibi gitmediğini savunmacı olmayan bir dille yazabilmek.
Bu, teknik bir beceri değil ama teknik bilgi olmadan da yapılamıyor. Ve iki tarafta da bulunmadan öğrenilmesi zor.
Ekosisteme dair kanaatim
Türkiye'nin teknoloji geliştirme bölgeleri altyapı, vergi avantajı ve nitelikli insan yoğunlaşması sağlamakta başarılı. Zayıf oldukları yer, TRL 4–6 bandındaki geçişi destekleyecek mekanizmalar, yani şirketin prototipten ürüne geçerken en çok yalnız kaldığı an.
Bu bantta ihtiyaç duyulan şey daha fazla ofis alanı veya daha fazla etkinlik değil: paylaşımlı test ve kalifikasyon altyapısı, ürünleşme mentorluğu ve ana yüklenici ile yapılandırılmış eşleştirme. Bunlar pahalı ve kurulması zor mekanizmalar; tam da bu yüzden tek tek şirketlerin değil, ekosistemin sağlaması gereken şeyler.
Bir şirketin tek başına titreşim test tesisi kurmasını beklemek gerçekçi değil. Bir bölgenin kurmasını beklemek gerçekçi.
Bu yazıdaki görüşler şahsıma aittir, çalıştığım ve çalışmış olduğum kurumları bağlamaz.
İlgili İçerikler
YazıSavunma Ar-Ge'sinin Önümüzdeki Beş Yılı: Program Yönetimi Neyi Değiştirmek Zorunda?
Otonomi, sürü kabiliyeti, düşük maliyetli sarf edilebilir sistemler ve yazılım tanımlı platformlar. Bu dört yönelimin ortak özelliği, hepsinin mevcut program yönetimi pratiklerini zorlaması. Değişmesi gereken beş şey.
YazıPMP Almalı mıyım? Sertifikanın Gerçekten İşe Yaradığı ve Yaramadığı Yerler
PMP hakkında iki uç görüş var: kariyeri değiştirir ve tamamen kâğıttır. İkisi de yanlış. Sertifikanın ne verdiği, ne vermediği, kimin alması gerektiği ve almaya değmeyen durumlar.
Yazı"Buraya Yapay Zekâ Koyalım" Demeden Önce Sorulacak Altı Soru
Otonomi ve görüntü işleme, savunma ve endüstriyel projelerde en hızlı büyüyen talep başlığı. Ama pek çok projede yapay zekâ bir çözüm olarak değil, tanımlanmamış bir problem olarak ekleniyor. Karar öncesi sorulması gereken altı soru.