Saha Notu: Yönetici Desteği Olmayan Projelerde Gördüklerim

Bu bir saha notu. Yıllardır kurumsal yapay zeka projelerini devreye alırken gördüklerimi, süslemeden ve tek bir kalıba indirerek anlatmak istiyorum: bir projenin kaderini belirleyen en güçlü değişken, çoğu zaman modelin ne kadar iyi olduğu değil, arkasında gerçek bir sponsor desteği olup olmadığıdır. Teknik olarak kusursuz projelerin sönerken, teknik olarak ortalama projelerin ayakta kalmasını izledim; aradaki farkı en sık açıklayan şey buydu.

Bu yazı "vaka analizi" niyetiyle yazıldı ama hayali şirket adı, uydurma sayı veya süslenmiş başarı hikâyesi içermiyor. Anlatacağım şey, farklı sektörlerde, farklı büyüklükteki kurumlarda tekrar tekrar karşılaştığım bir örüntü. Sponsor desteğinin ne olduğunu, gerçek destekle sözde desteği neyin ayırdığını, destek zayıfladığında hangi sinyallerin belirdiğini ve bir uygulayıcı olarak bu desteği nasıl kazanıp koruduğumu — hepsini saha gözlemi diliyle aktaracağım.

Neden bu konuya bütün bir yazı ayırıyorum? Çünkü sahada gördüğüm en pahalı israf, teknik olarak doğru kurulmuş ama arkasında gerçek bir sahiplik olmayan projelerin boşa harcanan emeğiydi. İyi bir ekip aylarca çalışır, sağlam bir sistem kurar; sonra proje, kimse açıkça öldürmediği hâlde sessizce durur. Bu israfı bir kez değil, defalarca izledim; ve her seferinde aynı kök nedene, yani zayıf veya sözde sponsor desteğine geri döndüm. Bu saha notu, o örüntüyü bir daha yaşamamanız için yazıldı.

Tanım

Sponsor Desteği (Yönetici Sahipliği)

Bir kurumsal yapay zeka projesine yetkili bir yöneticinin sağladığı sürekli ve aktif sahiplenme; yalnızca başlangıç onayını değil, projeye bütçe, öncelik, karar hızı ve kurum içi meşruiyet sağlamayı; engelleri bizzat kaldırmayı ve projeyi kendi iş hedeflerine bağlamayı kapsar. Sponsor desteği zayıf olduğunda proje teknik olarak sağlam olsa bile öncelik erimesi, kaynak çekilmesi ve karar yavaşlaması yoluyla sessizce söner.

Ayrıca: yönetici sahipliği, yönetici desteği, sponsorluk, executive sponsorship, proje sahipliği

Sponsor desteği, bir projeye başlamak için imza atan bir yöneticinin ötesinde bir şeydir. Benim tanımımla sponsor desteği, projeye bütçe, öncelik, karar hızı ve kurum içi meşruiyet sağlamaya devam eden aktif bir sahiplenmedir. "Devam eden" kelimesinin altını çiziyorum, çünkü desteğin en yaygın çöküş biçimi başlangıçta yokluğu değil, zamanla erimesidir. Bir yönetici açılış toplantısında coşkulu olabilir; asıl soru, üç ay sonra ilk zorlukla karşılaşıldığında hâlâ orada olup olmayacağıdır.

Kurumsal bir yapay zeka projesi neden bu desteğe bu kadar bağımlıdır? Çünkü bu projeler teknik olduğu kadar örgütseldir. Bir modeli çalıştırmak bir mühendislik problemidir; ama o modeli bir iş sürecine yerleştirmek, veriye erişim izni almak, başka bir departmanın iş yapış şeklini değiştirmek, bütçeyi savunmak ve önceliği korumak tamamen örgütsel problemlerdir. Bu problemlerin hiçbiri kodla çözülmez; ancak yetkili bir yöneticinin ağırlığıyla çözülür. Yönetici sahipliği, projenin bu örgütsel engelleri aşmasını sağlayan güçtür.

Bir benzetme kullanayım. Teknik ekip, projenin motorudur; sponsor desteği ise projenin yakıtı ve yol iznidir. En güçlü motor bile yakıtsız gitmez ve yol kapalıysa hızlanamaz. Sahada gördüğüm en trajik durum, mükemmel bir motoru olan ama yakıtı biten ve yolu kapalı kalan projelerdi — ekip harika iş çıkarır, ama proje bir yere varamaz. Bu yazının çıkış noktası tam olarak bu gözlem: neden iyi işlerin çoğu teknik nedenlerle değil, destek nedenleriyle ölüyor?

Bu konunun stratejik çerçevesini kurumsal AI stratejisi yazısında, projelerin neden başarısız olduğunun genel resmini yapay zeka yatırımlarında başarısızlık nedenleri yazısında ele alıyorum. Bu saha notu ise o resmin tek bir parçasına, belki de en belirleyici parçasına odaklanıyor.

Sahadaki en yaygın gözlemim şudur: destek nadiren açıkça reddedilir; çoğu zaman sözde kalır. Yani kâğıt üstünde bir sponsor vardır, sunum slaytında adı geçer, açılış toplantısına katılır, "bu bizim için stratejik" der — ama gerçek sahiplenmenin gerektirdiği hiçbir şeyi yapmaz. Bu sözde destek, gerçek desteğin yokluğundan daha tehlikelidir, çünkü herkesi yanıltır: ekip desteklendiğini sanır, projeye güvenir, planlar yapar; oysa altındaki zemin boştur.

Sözde desteği hangi davranışlardan tanıdığımı anlatayım. Yönetici projeye ilgi gösterir ama zaman ayırmaz; takvim istendiğinde hep "bu hafta yoğunum" der. Kararları sürekli erteler; "bir düşüneyim", "önümüzdeki toplantıda konuşuruz", "üst yönetime bir danışayım" cümleleri kararların mezarlığıdır. Projeyi kendi hedeflerine bağlamaz; onun için proje bir "iyi olur" işidir, "olmazsa olmaz" değil. Ve en kritik test: ilk bütçe veya öncelik sıkışmasında projeyi savunmak yerine sessizce geri çeker.

Bu sözde destek neden bu kadar yaygın? Birkaç nedenini gördüm. Bazı yöneticiler yapay zekaya "geri kalmamak için" evet der, ama içten içe ne olduğunu ya da neden önemli olduğunu anlamamıştır; sahiplenemez çünkü inanmaz. Bazıları samimi ister ama önceliklerini gerçekten değiştirmeye hazır değildir; yapay zeka, uzun listedeki onlarca işten biridir. Bazıları ise politik bir hesapla adını projeye koyar ama riski üstlenmek istemez; iş yürürse kredisini alır, batarsa mesafesini korur. Nedeni ne olursa olsun sonuç aynıdır: sponsor desteği ismen vardır, fiilen yoktur.

Peki gerçek sponsor desteğini nasıl anlarım? Yıllar içinde birkaç güvenilir göstergeye güvenmeyi öğrendim ve hepsinin ortak noktası şu: sözler değil, davranışlar. Bir yöneticinin ne söylediği değil, ne yaptığı destek olup olmadığını söyler. Aşağıdaki karşılaştırma tablosu, saha gözlemi olarak biriktirdiğim güçlü ve zayıf sinyalleri bir araya getiriyor.

Yönetici desteği göstergeleri: güçlü sinyal ve zayıf sinyal

Destek göstergesi	Güçlü sinyal (gerçek destek)	Zayıf sinyal (sözde destek)
Zaman ayırma	Takviminde düzenli, korunmuş zaman	Sürekli ertelenen, iptal edilen toplantı
Karar hızı	Kararı günler içinde verir	Kararı haftalarca erteler
Engel kaldırma	Engeli bizzat, hızla kaldırır	'İlgili birime yazın' der, unutur
Bütçe	Bütçeyi sıkışmada savunur	İlk kesintide projeyi çıkarır
Hedefe bağlama	Projeyi kendi performans hedefine koyar	Proje onun için 'iyi olur' işi
Kötü haber	Kötü haberi birlikte göğüsler	Sorun çıkınca mesafe koyar
Görünürlük	Projeyi üst yönetime kendi savunur	Yalnızca açılışta görünür

Bu tablodaki en belirleyici satır, benim için "hedefe bağlama"dır. Bir yönetici projeyi kendi performans hedefine, kendi yıllık taahhüdüne, kendi patronuna verdiği söze bağladıysa, o proje artık onun için "iyi olur" değil, "başarmam gereken" bir iştir. İşte gerçek sponsor desteği buradan doğar. Bir yönetici projeyi kaybederse kendisi de bir şey kaybediyorsa, o proje güçlü bir sahiplik altındadır. Kaybederse hiçbir şey kaybetmiyorsa, sahiplik gerçek değildir.

İkinci en güvenilir gösterge "engel kaldırma"dır. Her kurumsal projede, ancak yöneticinin ağırlığıyla açılabilecek kapılar vardır: bir departmanın direnci, bir veri erişim izni, bir hukuk onayı, bir bütçe kalemi. Gerçek destek sahibi yönetici bu engelleri bizzat ve hızla kaldırır; bunu bir angarya değil, kendi işinin parçası olarak görür. Sözde destek sahibi ise "ilgili birimle konuşun" der ve konuyu ekibin sırtına yıkar — oysa ekibin o kapıyı açacak yetkisi yoktur. Yönetici sahipliğinin en somut kanıtı, kapıların kimin tarafından açıldığıdır.

Üçüncü gösterge ise kötü haber anıdır. Her proje bir noktada kötü haber üretir: gecikme, beklenenden düşük sonuç, öngörülmemiş maliyet. Bu an, desteğin turnusol testidir. Gerçek sponsor kötü haberi ekiple birlikte göğüsler, "ne öğrendik, nasıl düzeltiriz" diye sorar. Sözde sponsor ise sorun çıkınca mesafe koyar, "ben zaten emin değildim" tonuna geçer ve ekibi yalnız bırakır. Bir yöneticinin desteğini ilk zaferde değil, ilk kötü haberde ölçün.

Bir yöneticinin desteğinin gerçek olup olmadığını sınamanın en pratik yolu, kaynak ve zaman taahhüdüne bakmaktır. Konuşma ucuzdur; kaynak ve zaman pahalıdır. Bir yönetici projeye kendi zamanını ve kendi bütçesini ne kadar bağlıyorsa, desteği o kadar gerçektir. Bu yüzden sahada bir projeye girerken erken sorduğum sorulardan biri şudur: "Bu proje için hangi kaynaklar, kim tarafından, ne kadar süreyle taahhüt edildi?"

Zaman taahhüdü, paradan bile güçlü bir sinyaldir. Çünkü bir yöneticinin en kıt kaynağı takvimidir. Bana düzenli, korunmuş bir zaman ayıran — haftalık on beş dakikayı bile olsa iptal etmeyen — bir yönetici, desteğini fiilen kanıtlıyor demektir. Buna karşılık her toplantıyı erteleyen, "bu hafta çok yoğunum" diyen bir yönetici, ne derse desin, projeyi öncelik listesinin altına koymuştur. Takvim yalan söylemez; bir yöneticinin gerçek öncelikleri, söylediklerinde değil, zamanını nasıl harcadığında görünür.

Kaynak taahhüdü de benzer biçimde okunur, ama bir inceliği vardır: taahhüdün somutluğu. "Sana kaynak ayıracağız" belirsiz bir sözdür; "Ayşe'yi haftanın üç günü bu projeye veriyorum, önümüzdeki iki çeyrek boyunca" somut bir taahhüttür. Sahada gördüğüm en sağlıklı projeler, kaynağı isim, oran ve süreyle netleştirenlerdi. En kırılgan projeler ise kaynağın "boşta kalınca" verildiği, yani hiçbir zaman gerçekten verilmediği projelerdi. Kaynak çekilmesi çoğu zaman burada, taahhüdün baştan muğlak bırakılmasında başlar.

Bu taahhüt testini bir bütçe konuşmasına dönüştürmek gerektiğinde, kurumsal AI bütçesi planlama yazısındaki çerçeve işe yarar. Ayrıca projenin değerini yöneticinin diliyle savunmak için üst yönetime yapay zeka projesi sunumu ve AI yatırımı kurul sunumu yazıları, taahhüdü nasıl isteyeceğiniz konusunda pratik yol gösterir.

Sponsor desteğinin belki de en ölçülebilir çıktısı karar hızıdır. Sahada bunu defalarca gördüm: destekli bir projede kararlar günler içinde çıkar; desteksiz bir projede aynı kararlar haftalarca, bazen aylarca bekler. Ve bu gecikme, bir projeyi yavaşça öldüren en sinsi güçtür. Çünkü kurumsal yapay zeka projeleri hız üzerine kuruludur; öğrenme döngüsü ne kadar hızlıysa, proje o kadar değer üretir. Kararlar yavaşladığında, döngü kırılır.

Somutlaştırayım. Bir projede sürekli kararlar birikir: hangi veri kaynağını kullanacağız, hangi departmanla pilot yapacağız, bu bütçe kalemini onaylıyor muyuz, bu riski kabul ediyor muyuz? Destekli bir projede bu kararlar, yetkili yönetici hızlı davrandığı için akışkandır; ekip beklemeden ilerler. Desteksiz bir projede ise her karar bir onay kuyruğuna girer, kuyruk uzar, ekip bekler. Beklerken motivasyon düşer, en iyi insanlar başka projelere göz kırpar ve momentum kaybolur. Kararların yavaşlaması, teknik bir sorun gibi görünmez ama projeyi teknik sorunlardan daha hızlı çökertir.

Karar hızının bir başka boyutu, kararın kalitesidir. Yavaş çıkan kararlar çoğu zaman kötü kararlardır, çünkü aciliyet biriktikçe ekip "en azından bir karar çıksın" diye baskı yapar ve yönetici acele, yeterince düşünülmemiş bir karar verir. Oysa güçlü bir sponsor desteği, kararların hem hızlı hem düşünülmüş olmasını sağlar; çünkü yönetici konuya zaten hâkimdir, aniden karar vermek zorunda kalmaz. Bu yüzden karar hızı ile karar kalitesi, sponsor desteği güçlüyken birlikte yükselir, zayıfken birlikte düşer.

Bu bağlantı, projelerin neden pilotta takılıp üretime geçemediğini de açıklar. PoC'den üretime yapay zeka projeleri ve agentic AI pilot-üretim uçurumu yazılarında ele aldığım "pilottan üretime geçememe" sorununun altında sıklıkla karar hızı yatar; ve karar hızının altında sponsor desteği vardır. Pilotta kalan projelere dair daha geniş bir saha gözlemini pilotta kalan projeler saha notu yazısında paylaştım.

Bir projenin sponsor desteği açısından nerede durduğunu okumak için, gözlemlediğim belirtileri kök nedenlerine ve önlemlerine bağlayan bir teşhis çerçevesi geliştirdim. Aşağıdaki tablo, sahada tekrar tekrar gördüğüm belirtileri, altlarındaki gerçek nedeni ve işe yaradığını gördüğüm önlemi bir araya getiriyor. Bunu bir tanı kılavuzu gibi kullanabilirsiniz.

Yönetici desteği sorunları: belirti, kök neden ve önlem

Görünen belirti	Kök neden	İşe yarayan önlem
Toplantılar sürekli iptal ediliyor	Proje yöneticinin öncelik listesinin altında	Projeyi yöneticinin bir hedefine açıkça bağla
Kararlar haftalarca bekliyor	Karar yetkisi net değil veya yönetici konuya hâkim değil	Karar hakkını ve kapsamını baştan netleştir; kararı basitleştir
Bütçe 'sonraki çeyreğe' öteleniyor	Proje değeri yöneticinin dilinde kanıtlanmamış	Erken, küçük ve ölçülü bir kazanım göster
Ekip üyeleri başka işlere çekiliyor	Kaynak taahhüdü baştan muğlak bırakılmış	İsim, oran, süre ile somut taahhüt al
Yönetici hep 'ilgili birime yazın' diyor	Sahiplik delege edilmiş, gerçek sahip yok	Tek ve yetkili bir sponsor tanımla
Sorun çıkınca yönetici mesafe koyuyor	Yönetici riski üstlenmemiş, politik durmuş	Kötü haberi erken paylaş, riski birlikte sahiplen
Sorular teknikten maliyete kayıyor	Sabır tükeniyor, değer henüz görülmedi	Değeri iş metriğiyle görünür kıl, beklentiyi yönet
Sponsor değişti, yenisi ilgisiz	Destek tek kişiye bağlıydı, devri planlanmadı	Desteği yönlendirme grubuna yay; yeni sponsoru yeniden kazan

Bu tablonun en önemli mesajı şudur: belirtiler nadiren kendi başlarına ele alınmalıdır. Toplantı iptalleri, karar gecikmeleri ve bütçe ötelemeleri, çoğu zaman aynı kök nedenin — zayıf veya sözde sponsor desteğinin — farklı yüzleridir. Belirtiyi tek tek kovalamak yorucu ve sonuçsuzdur; asıl çözüm kök nedene, yani destek ilişkisine inmektir. Bir belirtiyi bastırdığınızda, kök neden yerinde durduğu sürece başka bir belirti olarak geri döner.

İkinci mesaj, önlemlerin çoğunun teknik değil ilişkisel olmasıdır. "Erken kazanım göster", "kötü haberi erken paylaş", "değeri iş metriğiyle görünür kıl" — bunların hiçbiri koddan geçmez; hepsi yöneticiyle kurulan ilişkinin niteliğinden geçer. Sahada öğrendiğim en zor ders buydu: en iyi teknik ekip bile, bu ilişkisel önlemleri ihmal ettiğinde desteğini kaybediyordu. Bu konuya, teknik olmayan rollerin projeye kattığı değer açısından teknik olmayan roller ve AI şampiyonu yazısında ayrıca değindim.

Sponsor desteğinin en tehlikeli özelliği, aniden değil yavaşça kaybolmasıdır. Bir gün "bu projeyi kapatıyoruz" denmez; onun yerine destek santim santim çekilir ve bir bakarsınız proje fiilen durmuştur. Bu yüzden destek zayıflamasının erken sinyallerini okumayı öğrenmek, bir uygulayıcının en değerli becerilerinden biridir. Erken fark edersen müdahale edebilirsin; geç fark edersen yalnızca cenazeye katılırsın.

İlk sinyal, zamanın çekilmesidir. Yönetici, daha önce düzenli katıldığı toplantıları iptal etmeye başlar veya yerine birini gönderir. Delege etme, çoğu zaman ilginin azaldığının kibar bir işaretidir; yönetici hâlâ "önemsiyorum" der ama artık kendisi orada değildir. İkinci sinyal, soruların değişmesidir. Başlangıçta "bunu nasıl daha iyi yaparız" diye soran yönetici, giderek "bu ne kadar tutuyor", "ne zaman bitecek", "buna gerçekten ihtiyacımız var mı" sorularına kayar. Soruların tekno-heyecandan maliyet-kaygısına kayması, sabrın tükendiğinin en net işaretidir.

Üçüncü sinyal, bütçe ve kaynak dilindeki incelmedir. "Bu projeye yatırım yapıyoruz" cümlesi, önce "şimdilik idare edelim"e, sonra "sonraki çeyrekte tekrar bakarız"a dönüşür. Kaynak çekilmesi genellikle böyle nazik bir erteleme kılığında gelir; kimse "kaynağı kesiyorum" demez, yalnızca "şu an müsait değil" der. Ekipten birinin "geçici olarak" başka bir işe kaydırılması ve bir daha geri dönmemesi, kaynak çekilmesinin klasik biçimidir. Dördüncü sinyal, görünürlüğün kaybıdır: proje artık yöneticinin üst yönetime yaptığı sunumlarda geçmez, kurumsal iletişimde adı anılmaz, "vitrin"den çekilir.

Bu sinyaller bir araya geldiğinde proje sönmesi başlamış demektir. Proje sönmesi, ani bir ölüm değil; öncelik erimesi, kaynak çekilmesi ve karar yavaşlamasının birleşerek projeyi yavaşça durdurmasıdır. En sinsi yanı, hiç kimsenin sorumluluğu üstlenmemesidir: proje "iptal edilmez", sadece "askıya alınır", "beklemeye alınır", "yeniden değerlendirilir" — ve bir daha geri dönmez. Bu sessiz sönme kalıbını, benimseme tarafındaki yansımasıyla birlikte kullanıcı benimsemesi saha notu yazısında da ele aldım.

Desteği korumaktan önce, doğru sponsoru bulmak gelir. Sahada gördüğüm bir hata, "en üsttekini sponsor yap" refleksidir. En yüksek unvanlı yönetici her zaman en iyi sponsor değildir; çünkü en üsttekinin gündemi en kalabalıktır ve projeye ayıracak gerçek zamanı en azdır. İyi bir sponsorun tek kriteri unvan değil; yetki, ilgi ve erişilebilirliğin kesişimidir.

Doğru sponsoru ararken üç şeye bakarım. Birincisi yetki: bu yöneticinin, projenin ihtiyaç duyacağı kararları (bütçe, kaynak, öncelik, süreç değişikliği) gerçekten verebilecek yetkisi var mı? İkincisi ilgi: bu proje, bu yöneticinin kendi hedeflerine dokunuyor mu? Kendi sorununu çözen bir yönetici, "kurum için iyi olur" diye düşünen bir yöneticiden çok daha güçlü bir sponsordur. Üçüncüsü erişilebilirlik: bu yöneticiye düzenli ulaşabilecek miyim, yoksa her toplantı için haftalarca mı bekleyeceğim? Yetkisi olan ama hiç ulaşılamayan bir sponsor, kâğıt üstünde iyi görünür ama pratikte işe yaramaz.

Bu üç kriterin kesişiminde çoğu zaman en üstteki değil, "bir kademe aşağıdaki güçlü yönetici" çıkar: kararları verebilecek yetkisi olan, projeyle kendi hedefi kesişen ve size düzenli zaman ayırabilecek kadar erişilebilir olan kişi. Sahada en sağlam projelerin sponsoru genellikle böyle bir profildi. Bir üst düzey yöneticiyi (C-level) tepe destekçi olarak arkada tutmak değerlidir; ama günlük yürütmeyi taşıyan gerçek sponsor, çoğu zaman bir kademe aşağıda olur.

Bir başka kritik nokta: sponsoru tek kişiye indirmemek. Tek bir sponsora bağlı proje, o kişi ayrıldığında veya önceliği değiştiğinde savunmasız kalır. Bu yüzden ideal kurgu, bir ana sponsor artı onu destekleyen bir yönlendirme grubudur. Bu grup, hem kararları meşrulaştırır hem de tek kişilik bağımlılığın riskini dağıtır. Doğru rol ve sahiplik yapısını kurmak için AI organizasyon tasarımı ve Chief AI Officer rol tanımı yazıları, kurumsal ölçekte bu yapıyı nasıl kuracağınıza dair çerçeve sunar.

Doğru sponsoru bulduktan sonra, işin asıl zor kısmı gelir: desteği kazanmak ve zamanla korumak. Bunun sihirli bir formülü yok; ama sahada tekrar tekrar işe yaradığını gördüğüm birkaç taktik var. Hepsinin ortak paydası, desteği bir kerelik bir onay değil, sürekli beslenen bir ilişki olarak görmektir.

Birinci taktik: teknoloji değil, iş sonucu konuşmak. Yöneticiye modelin mimarisini, embedding'i veya token maliyetini anlatmak neredeyse hiçbir zaman desteği güçlendirmez; çünkü yönetici bu dili konuşmaz ve bu onun problemi değildir. Onun problemi maliyet, hız, müşteri memnuniyeti, risk ve büyümedir. Projeyi bu dile çevirmeyi öğrendiğimde — "bu, destek ekibinin çözüm süresini kısaltır", "bu, uyum riskini azaltır" — desteğin nasıl güçlendiğini gördüm. Yönetici, teknolojiye değil, kendi hedefine yatırım yapar.

İkinci taktik: erken ve küçük kazanım üretmek. Aylar sonra gelecek büyük bir sonuç vaadi, sabrı test eder ve destek erimesine davetiye çıkarır. Bunun yerine, birkaç hafta içinde görülebilir, somut, mütevazı bir iyileşme göstermek, yöneticinin desteğini yeniler ve size ilerlemek için zaman kazandırır. Sahada öğrendiğim şuydu: küçük ama gerçek bir kazanım, büyük ama uzak bir vaatten her zaman daha ikna edicidir. Erken kazanım, desteği besleyen yakıttır; onsuz en iyi projeler bile açlıktan söner.

Üçüncü taktik: yöneticiyi ortak yapmak, seyirci değil. Kararları onunla birlikte almak, ilerlemeyi düzenli ve dürüst raporlamak, ve — bu kritik — kötü haberi de erken vermek. Kötü haberi saklayan ekipler, sorun patladığında yöneticinin güvenini toptan kaybeder; kötü haberi erken ve çözüm önerisiyle getiren ekipler ise güven biriktirir. Bir yönetici, kendisini süreçte gerçek bir ortak hisseder ve dürüst bilgilendirildiğini bilirse, zor anlarda projenin yanında durur. Destek, dürüstlükle büyür.

Bu taktikleri sistematik bir sunum ve ikna diline dönüştürmek için üst yönetime yapay zeka projesi sunumu yazısı; projenin değerini rakamla savunmak için yapay zeka ROI nasıl hesaplanır yazısı; ve kurumun genel yapay zeka olgunluğunu değerlendirmek için kurumsal yapay zeka stratejisi nasıl oluşturulur yazısı bu saha notunu tamamlar.

Her zaman ideal koşullarda başlamayız. Bazen kendinizi, sponsor desteği baştan zayıf olan bir projenin içinde bulursunuz. Bu durumda ne yapmalı? Sahada birkaç gerçekçi seçenek gördüm ve hiçbiri "kahramanlıkla desteksiz yürümek" değil. Desteksiz kahramanlık, sahada en çok tükenmeye yol açan stratejiydi.

Birinci seçenek: kapsamı küçültüp desteği inşa etmek. Eğer büyük bir dönüşüm için destek yoksa, küçük ve düşük riskli bir kazanımla başlayıp o kazanımı desteğe çevirebilirsiniz. Yöneticiye somut bir sonuç göstermeden büyük bir taahhüt beklemek gerçekçi değildir; ama küçük bir başarı, büyük desteğin kapısını açabilir. Bu, "önce güven kazan, sonra ölçek iste" stratejisidir ve sabır gerektirir ama işe yarar. Kapsamı doğru daraltmak için AI use-case önceliklendirme matrisi yararlı bir araçtır.

İkinci seçenek: sponsoru değiştirmek veya yükseltmek. Mevcut sponsor gerçekten ilgisizse ve değişmeyecekse, projeyi onun hedefine daha yakın veya konuya daha meraklı başka bir yöneticiye taşımak bazen tek çözümdür. Bu politik olarak hassastır ama sahada gördüm ki yanlış sponsorla yürümeye çalışmaktan çok daha az yıpratıcıdır. Doğru sponsor, projenin motorunu değiştirmeden yakıtını değiştirir.

Üçüncü seçenek — ve söylemesi zor olanı — projeyi bilinçli olarak duraklatmak veya kapatmak. Eğer ne destek inşa edilebiliyor ne de doğru sponsor bulunabiliyorsa, teknik olarak ne kadar iyi olursa olsun o projeyi zorlamak, ekibin enerjisini ve kurumun güvenini boşa harcar. Sahada öğrendiğim olgunluk buydu: bazen en doğru karar, desteksiz bir projeyi onurlu biçimde durdurup enerjiyi destekli bir işe yöneltmektir. Bir projeyi zamanında durdurmak başarısızlık değil, kaynak disiplinidir. İç ekiple mi yürümek yoksa dışarıdan destek mi almak gerektiği kararında AI danışmanlığı mı iç ekip mi yazısı yardımcı olur.

Yıllar içinde biriken saha gözlemi, bir dizi tekrar eden hataya işaret ediyor. Bunları tek tek saymak, kendi projenizde erken uyarı işareti aramanıza yardım edebilir. Hepsi, sponsor desteğini yanlış anlamaktan veya ihmal etmekten doğuyor.

En sık gördüğüm hata, başlangıçtaki heyecanı destek sanmaktır. Açılış toplantısındaki coşku gerçektir ama geçicidir; asıl destek, üçüncü ayda ilk zorlukla karşılaşıldığında ölçülür. Ekipler sık sık başlangıç coşkusuna güvenip zeminin sağlam olduğunu varsayar; sonra ilk sarsıntıda zeminin boş olduğunu görür. İkinci hata, desteği kâğıt üstünde aramaktır: organizasyon şemasında sponsor kutusu doludur, ama o kutudaki kişi fiilen hiçbir şey yapmaz. Şema desteği göstermez; davranış gösterir.

Üçüncü hata, kötü haberi saklamaktır. Ekipler yöneticiyi hayal kırıklığına uğratmamak için sorunları erteler, "biz hallederiz" der; sorun büyüyüp patlayınca da yönetici hem kötü sonuçla hem de saklanmışlıkla karşılaşır ve güveni ikiye katlanarak kaybolur. Dördüncü hata, tek sponsora aşırı bağımlılıktır: proje bir kişinin omzunda durur, o kişi ayrılınca veya önceliği değişince proje çöker. Destek devri planlanmadığında, sponsor değişikliği çoğu zaman projenin sonu olur.

Beşinci hata, yöneticinin dilini konuşmayı reddetmektir. Teknik ekip, çözümün zarafetine âşık olur ve yöneticiye onu anlatmak ister; oysa yönetici zarafetle değil, sonuçla ilgilenir. Teknolojiyi iş sonucuna çevirmeyi reddeden ekipler, en iyi işi yapsalar bile desteği kaybeder.

Altıncı hata, yanlış yöneticiyi sponsor seçmektir: en yüksek unvanlıyı otomatik olarak sponsor yapmak ama o kişinin ne zamanı ne de gerçek ilgisi olduğunu görmemek. Yetkisi olan ama ulaşılamayan bir sponsor, kâğıt üstünde iyi görünse de projeyi karar kuyruğunda bekletir; bu da yavaş yavaş bir proje sönmesine yol açar. Yedinci ve belki en sinsi hata, destek zayıflama sinyallerini görmezden gelmektir: iptal edilen toplantıları "yoğunluk", ertelenen bütçeyi "geçici" sanıp erken uyarıları okumayı reddetmek. Bu sinyalleri erken okumayan ekipler, kaynak çekilmesini ancak geri dönüşü olmayan noktada fark eder.

Bu hataların hepsi, aslında tek bir kök yanılgının farklı yüzleridir: desteği bir kere alınıp bir kenara konulan bir şey sanmak. Oysa sponsor desteği, sürekli beslenmezse kuruyan canlı bir ilişkidir. Bir saha gözlemi olarak söyleyeyim: bu hataları yapan ekipler kötü ekipler değildi; çoğu teknik olarak çok iyiydi. Sadece kurumsal yapay zekanın bir teknoloji değil, bir sahiplik ve ilişki işi olduğunu geç fark ettiler. Bu örüntülerin dönüşüm projelerindeki daha geniş yansımasını dönüşüm kalıpları saha notu yazısında topladım.

Bir projenin sponsor desteği açısından kaderi, çoğu zaman ilk doksan günde belli olur. Bu ilk üç ay, başlangıç coşkusunun yavaş yavaş gerçek bir sahiplenmeye dönüştüğü — ya da dönüşemeyip söndüğü — kritik penceredir. Sahada gördüğüm kadarıyla, bir yöneticinin desteğinin gerçek mi sözde mi olduğunu anlamak için doksan gün yeterlidir; çünkü bu süre içinde ilk zorluk, ilk kötü haber ve ilk kaynak çatışması mutlaka yaşanır ve destek bu üç ateşte sınanır.

İlk otuz günde çoğu yönetici destekleyici görünür; bu evrede henüz zorluk çıkmamış, kimseden fedakârlık istenmemiştir. Asıl sınav ikinci ayda başlar: proje ilk teknik veya örgütsel engelle karşılaşır ve yöneticinin bu engeli bizzat kaldırıp kaldırmadığı görülür. Üçüncü ayda ise ilk kötü haber gelir — bir gecikme, beklenenden düşük bir sonuç veya öngörülmemiş bir maliyet — ve yönetici ya ekiple birlikte göğüsler ya da mesafe koyar. Bu üç anın nasıl geçtiği, projenin geri kalanının haritasını çizer.

Bu yüzden bir uygulayıcı olarak ilk doksan günü bilinçli yönetmeyi öğrendim. İlk aydan itibaren küçük ama gerçek bir kazanım hedefliyorum; çünkü yöneticinin desteğini besleyen en güçlü yakıt, erken görünen somut sonuçtur. Aynı zamanda ilk engeli ve ilk kötü haberi, kaçınılacak felaketler olarak değil, desteği test edecek ve güçlendirecek fırsatlar olarak görüyorum. Bir engeli yöneticiye taşıyıp onun bizzat kaldırmasını sağlamak, o yöneticiyi projenin gerçek sahibi hâline getirmenin en etkili yollarından biridir. Yönetici sahipliği, soyut bir taahhütle değil, somut engellerin birlikte aşılmasıyla pekişir.

İlk doksan günün sonunda net bir teşhis koymaya çalışırım: bu proje gerçek bir sponsor desteğine mi sahip, yoksa sözde mi? Bu teşhis erken konursa, hâlâ yön değiştirmek için zaman vardır — desteği güçlendirmek, sponsoru değiştirmek veya kapsamı küçültmek. Geç konursa, proje çoktan proje sönmesi yoluna girmiş olabilir. Bu ilk-doksan-gün disiplinini, pilottan üretime geçişin genel dinamiğiyle birlikte PoC'den üretime yapay zeka projeleri yazısında ele aldığım çerçeveyle birlikte okumanızı öneririm.

Sponsor desteğinin zayıflamasının en somut ve en yaygın biçimlerinden biri bütçe erozyonudur. Ama sahada gördüğüm şu: bütçe nadiren tek bir kararla kesilir. Onun yerine santim santim erir; her adım küçük ve makul görünür, ama toplamı projeyi açlığa mahkûm eder. Bu sessiz kaynak çekilmesinin anatomisini anlamak, onu erken fark edip müdahale edebilmenin ön koşuludur.

Erozyon genellikle şöyle ilerler. Önce "esneklik" adı altında bütçenin bir kısmı dondurulur: "Şimdilik şu kalemi bekletelim, çeyrek sonunda tekrar bakarız." Sonra ekipten biri "geçici olarak" başka bir yangına kaydırılır ve bir daha geri dönmez; bu, parasal olmayan ama belki en ağır kaynak çekilmesi biçimidir, çünkü projenin bilgi birikimini de götürür. Ardından yeni harcama talepleri giderek daha fazla gerekçe ister; onay süreci uzar, her kalem için "gerçekten gerekli mi" sorusu belirir. Son aşamada bütçe resmen kesilmez ama fiilen kullanılamaz hâle gelir — para kâğıt üstünde vardır, ama her kullanım girişimi bir dirençle karşılaşır.

Bu erozyonun altındaki kök neden neredeyse her zaman aynıdır: projenin değeri yöneticinin dilinde henüz kanıtlanmamıştır. Bir yönetici, projenin somut bir iş sonucu ürettiğini gördüğünde bütçeyi savunur; göremediğinde ise bütçe, kesilecek ilk kalem olur. Bu yüzden bütçe erozyonuna karşı en güçlü savunma, muhasebe tartışması değil, erken ve ölçülebilir bir değer göstergesidir. Değeri iş metriğine bağlamayı beceren ekipler, bütçelerini korudu; teknolojinin zarafetine güvenen ekipler ise erozyona teslim oldu.

Bütçeyi bir yönetici diliyle kurmak ve savunmak için kurumsal AI bütçesi planlama ve değeri rakamla göstermek için yapay zeka ROI ölçümü yazıları, bu saha notundaki gözlemleri uygulanabilir bir çerçeveye oturtur.

Bir sponsorun desteği hiçbir zaman boşlukta yaşamaz; her zaman bir kurumsal zeminin, çıkarların ve politikanın içinde durur. Sahada öğrendiğim önemli bir gerçek şu: en güçlü yöneticinin desteği bile, karşısında görünmeyen bir direnç varsa yeterli olmayabilir. Bu direnç açık bir "hayır" biçiminde nadiren gelir; çoğu zaman pasif bir yavaşlatma, bir "ama önce şunu halledelim" veya bir "biz de bir bakalım" kılığında sinsi biçimde işler.

Bu direncin kaynakları çeşitlidir. Bazı departmanlar, projenin kendi iş yapış biçimini değiştirmesinden veya kendi öneminin azalmasından korkar; bu korku açıkça dile getirilmez ama iş birliğini yavaşlatır. Bazı yöneticiler, kendi projelerinin gölgede kalmasından rahatsız olur ve kaynak rekabetinde sizin projenizi arka plana iter. Bazıları ise geçmiş başarısız girişimlerin yarattığı yorgunlukla "bu da geçer" tavrı takınır. Bu politik zemin okunmadan, en güçlü sponsor desteği bile beklenmedik bir yerde takılabilir.

Bu yüzden desteği yalnızca ana sponsorla kurmak yetmez; direnç noktalarını erken tespit edip onları da hesaba katmak gerekir. Sahada işe yaradığını gördüğüm yaklaşım, itirazları saklamak yerine erken davet etmekti: "Bu projeyle ilgili endişeniz nedir?" sorusunu erken sormak, gizli direnci açığa çıkarır ve çoğu zaman çözülebilir bir hâle getirir. Duyulmayan itiraz, altı ay sonra bir kaynak çekilmesi olarak geri döner; duyulan itiraz ise bir tasarım kararına dönüşebilir. Bu, bir saha gözlemi olarak defalarca doğrulandı.

Politik zeminin bir başka boyutu, projenin görünürlüğünü yönetmektir. Çok erken ve çok yüksek sesle duyurulan bir proje, henüz değer üretmeden büyük beklentiler ve büyük rakipler yaratır; çok sessiz kalan bir proje ise meşruiyet ve destek biriktiremez. Doğru denge, değeri kanıtlanana kadar mütevazı kalmak, sonra kanıtla birlikte görünürlüğü artırmaktır. Bu dengeyi kurumsal ölçekte yönetmek için kurumsal AI stratejisi ve doğru rol yapısını tasarlamak için AI organizasyon tasarımı yazıları çerçeve sunar.

Somutlaştırmak için, sahada gözlemlediğim tekrarlayan bir örüntüyü — hayali isim ve sayı kullanmadan, iki temsili durum üzerinden — anlatmak istiyorum. İki proje düşünün: teknik olarak neredeyse aynı, benzer kapsamda, benzer ekiplerle yürüyen iki kurumsal yapay zeka girişimi. Biri üretime geçti ve değer üretti; diğeri sessizce söndü. Aradaki farkın teknoloji olmadığını, sponsor desteği olduğunu görmek, bu saha notunun özünü özetliyor.

Birinci projede sponsor, projeyi kendi yıllık hedefine açıkça bağlamıştı. Haftalık kısa bir görüşmeyi hiç iptal etmiyor, çıkan her engeli bizzat ve hızla kaldırıyor, ilk kötü haberi "ne öğrendik" tavrıyla karşılıyordu. Ekip, karar beklemeden ilerliyordu; çünkü kararlar günler içinde çıkıyordu. Bir sıkışma olduğunda sponsor bütçeyi savundu, projeyi üst yönetime kendi ağzıyla anlattı. Bu proje mükemmel değildi, hatalar yaptı; ama arkasındaki gerçek yönetici sahipliği, onu her sarsıntıda ayakta tuttu.

İkinci projede ise sponsor, açılışta coşkuluydu ama sonrasında görünmez oldu. Toplantılar bir bir ertelendi, yerine birileri gönderildi; kararlar haftalarca onay kuyruğunda bekledi. İlk kötü haber geldiğinde sponsor "ben zaten emin değildim" tonuna geçti ve ekip yalnız kaldı. Kaynak çekilmesi başladı: ekipten biri başka bir işe kaydırıldı, bütçe "sonraki çeyreğe" ötelendi. Kimse projeyi resmen iptal etmedi; ama altı ay sonra proje kimsenin gündeminde değildi. Klasik bir proje sönmesi.

Bu iki temsili durumun dersi nettir ve sahada defalarca aynı biçimde tekrarlandı: teknoloji, iki projeyi ayırt eden değişken değildi. Ayırt eden, arkalarındaki sponsor desteğinin gerçek mi sözde mi olduğuydu. Aynı motor, farklı yakıt; aynı kod, farklı kader. Bu yüzden bir projeye başlarken sorduğum ilk soru artık "hangi modeli kullanacağız" değil, "bu işi kim sahipleniyor ve ne kadar gerçek" oluyor. Bu örüntünün benimseme tarafındaki yansımasını kullanıcı benimsemesi saha notu ile birlikte okumak, resmi tamamlar.

Sponsor desteğini korumanın somut bir yolu, yöneticiye ne raporladığınızı bilinçli seçmektir. Sahada gördüğüm bir hata, yöneticiye teknik metrikler yağdırmaktı: model doğruluğu, gecikme, token sayısı. Bu metrikler ekip için değerlidir ama yönetici için anlamsızdır; onun desteğini ne besler ne de korur. Yöneticiye raporlanan şey, onun dilinde bir değer ve ilerleme anlatısı olmalıdır. Doğru raporlama, desteği besleyen sessiz bir kaldıraçtır.

Bir yöneticiye raporlarken üç soruya cevap vermeye çalışırım. Birincisi: "Bu proje senin hedefine ne kattı?" — yani somut bir iş sonucu (kısalan süre, azalan hata, artan kapasite). İkincisi: "Ne öğrendik ve sıradaki adım ne?" — ilerlemenin ve yönün netliği. Üçüncüsü: "Hangi engel var ve senden ne gerekiyor?" — yöneticinin bizzat kaldırabileceği somut bir talep. Bu üç soru, yöneticiyi seyirci değil ortak yapar; her raporlama, onun desteğini yeniden kazanma fırsatına dönüşür.

Raporlamada dürüstlük, cazibeden daha değerlidir. Kötü haberi yumuşatmak veya saklamak kısa vadede rahatlatır ama uzun vadede güveni yok eder. Sahada desteğini en iyi koruyan ekipler, kötü haberi ilk duyuran taraf olmayı alışkanlık hâline getirenlerdi; çünkü sürprizden nefret eden yöneticiler, erken ve dürüst uyarıya minnet duyar. Bir raporun amacı yöneticiyi etkilemek değil, onu doğru bilgilendirip doğru kararı hızlı vermesini sağlamaktır. Bu ayrım, karar hızını doğrudan etkiler.

Bu raporlama disiplinini bir sunum ve ikna sistemine dönüştürmek için üst yönetime yapay zeka projesi sunumu ve kurul düzeyinde bir anlatı kurmak için AI yatırımı kurul sunumu yazıları, bu saha gözlemini uygulanabilir bir şablona bağlar.

Sponsor desteğinin dinamiği, kurumun büyüklüğüne ve sektörüne göre değişir; bunu da bir saha gözlemi olarak paylaşmak isterim. Küçük ve orta ölçekli kurumlarda destek çoğu zaman tek bir güçlü kişide toplanır: karar veren de, kaynak ayıran da, engeli kaldıran da aynı yöneticidir. Bu, hız avantajı sağlar ama kırılganlık yaratır; o kişi giderse proje savunmasız kalır. Büyük kurumlarda ise destek dağıtıktır: karar birkaç komiteden geçer, kaynak birden fazla bütçeden gelir ve tek bir sponsorun ağırlığı yetmeyebilir.

Büyük kurumlarda gördüğüm en önemli fark, desteğin tek kişilik değil, koalisyon işi olmasıdır. Tek bir güçlü sponsor bile, karşısında ikna olmamış birkaç paydaş varsa projeyi tek başına taşıyamaz. Bu yüzden büyük kurumlarda destek, bir kişiyi ikna etmekten çok, bir koalisyon kurmaktır: farklı departmanların çıkarlarını hizalamak, itirazları erken duymak ve projeyi birden fazla yöneticinin ortak hedefi hâline getirmek. Bu daha yavaş ama daha dayanıklıdır.

Regüle sektörlerde (bankacılık, sigorta, sağlık) ise ek bir katman devreye girer: desteğin yalnızca iş tarafından değil, uyum ve risk tarafından da gelmesi gerekir. Bu sektörlerde bir yöneticinin coşkusu tek başına yetmez; hukuk, uyum ve risk birimlerinin de projeyi sahiplenmesi veya en azından engel olmaması gerekir. Sahada gördüm ki regüle sektörlerde en hızlı ölen projeler, iş sponsoru güçlü ama uyum tarafı ikna olmamış projelerdi. Regüle sektörlerdeki onay dinamiğine dair daha ayrıntılı gözlemi regüle sektör onay saha notu yazısında paylaştım.

Bu farklar, tek bir evrensel reçete olmadığını gösterir. Küçük kurumda güçlü bir kişiyi kazanmak, büyük kurumda bir koalisyon kurmak, regüle sektörde uyumu erken hizalamak gerekir. Ama üçünde de değişmeyen çekirdek aynıdır: proje, arkasında onu umursayan ve kaynak ayıran gerçek bir sahiplik olmadan yürümez. Kurumsal ölçekte bu sahipliği nasıl kurumsallaştıracağınıza dair çerçeveyi yapay zeka mükemmeliyet merkezi kurulumu yazısında ele aldım.

Sahada fark ettiğim ve başta beklemediğim bir bağlantı, sponsor desteği ile kullanıcı benimsemesi arasındadır. İlk bakışta bunlar ayrı konular gibi görünür: destek üst yönetimle, benimseme ise son kullanıcıyla ilgilidir. Ama gözlemlerim ikisinin sıkı sıkıya bağlı olduğunu gösterdi. Bir yöneticinin görünür ve sürekli sahiplenmesi, kullanıcıların da projeyi ciddiye almasını sağlar; desteğin zayıflaması ise sahada bir "bu da geçer" tavrına dönüşür ve benimseme çöker.

Neden böyle olur? Çünkü kurumsal davranış, üstten gelen sinyalleri okur. Bir yönetici bir projeyi kendi hedefine bağladığında, kendi zamanını ayırdığında ve düzenli olarak "nasıl gidiyor" diye sorduğunda, alt kademeler bu ilgiyi hisseder ve projeye enerji verir. Buna karşılık yönetici görünmez olduğunda, kullanıcılar sessiz bir mesaj alır: "Bu iş öncelikli değil, eski yöntemle devam edebilirsiniz." Böylece teknik olarak mükemmel bir araç, kimse kullanmadığı için değersizleşir. Benimsemeyi öldüren şey çoğu zaman aracın kalitesi değil, arkasındaki desteğin görünürlüğüdür.

Bu bağ, bir uygulayıcı için önemli bir kaldıraç sunar. Kullanıcı benimsemesini artırmanın en etkili yollarından biri, yöneticinin görünür sahiplenmesini bir benimseme aracı olarak kullanmaktır: sponsorun projeyi kendi ağzıyla ekiplere anlatması, ilk kullananları takdir etmesi ve kullanımı kendi gündeminde tutması, herhangi bir eğitim kampanyasından daha güçlü bir benimseme sinyalidir. Sahada gördüm ki en hızlı benimsenen projeler, en iyi arayüze sahip olanlar değil, yöneticinin en görünür biçimde arkasında durduğu projelerdi. Bu saha gözlemini, benimseme tarafının ayrıntısıyla birlikte kullanıcı benimsemesi saha notu yazısında derinleştirdim.

Tersi de doğrudur: güçlü bir benimseme, sponsor desteğini besler. Kullanıcılar araci sahiplenip somut fayda gördüğünde, bu fayda yöneticiye geri döner ve onun desteğini pekiştirir. Böylece bir olumlu döngü kurulur: destek benimsemeyi, benimseme değeri, değer de yeniden desteği besler. Bu döngüyü başlatmak için erken ve görünür bir kazanım şarttır; işte bu yüzden erken kazanım, yalnızca yöneticiyi değil, tüm kullanıcı tabanını da harekete geçiren bir kıvılcımdır. Bu döngüyü kurumsal ölçekte sürdürmek için gereken beceri altyapısını kurumsal AI akademisi yazısında ele aldım.

Bir uygulayıcı olarak öğrendiğim en incelikli beceri, sponsoru yönetmek değil — bu kulağa manipülatif gelir — ama sponsorun beklentisini dürüstçe yönlendirmektir. Sahada gördüğüm en sık destek kaybı nedenlerinden biri, yanlış yönetilmiş beklentiydi. Yönetici, yapay zekadan gerçekçi olmayan bir hız veya sonuç bekliyorsa, proje teknik olarak iyi gitse bile onun gözünde "yeterince hızlı değil" veya "vaat edileni vermedi" olur ve destek erir. Beklenti yönetimi, sponsor desteğini korumanın görünmeyen ama belirleyici bir parçasıdır.

Beklenti yönetimi en baştan başlar. Projeyi satarken abartılı vaatlerde bulunmak, kısa vadede desteği kolaylaştırır ama uzun vadede bir tuzaktır; çünkü karşılanamayan her abartı, desteğin altını oyar. Sahada öğrendiğim disiplin, baştan mütevazı ve dürüst olmaktı: neyin mümkün, neyin belirsiz, neyin zaman alacağını açıkça söylemek. Bir yönetici, gerçekçi bir söz verildiğinde ve o söz tutulduğunda güven biriktirir; abartılı bir söz verilip tutulmadığında ise güven, karşılanmayan beklentinin ağırlığıyla çöker.

Beklenti yönetiminin bir diğer boyutu, yapay zekanın sınırlarını yöneticiye dürüstçe anlatmaktır. Birçok yönetici, medyadaki abartılı anlatılardan etkilenerek yapay zekayı sihirli bir çözüm sanır; oysa gerçek projeler kademeli, deneysel ve zaman zaman geri adımlıdır. Yöneticiye bu gerçekliği erken ve dürüstçe aktarmak, sonraki hayal kırıklıklarını baştan önler. Sahada en dayanıklı sponsor desteği, yapay zekanın hem gücünü hem sınırını anlamış yöneticilerden geliyordu; en kırılgan destek ise yapay zekayı bir sihir sanan yöneticilerden. Bu gerçekliği yöneticiye anlatırken, kurumsal beklentileri çerçeveleyen yapay zeka yol haritası nedir yazısı yardımcı bir dil sunar.

Son olarak, beklenti yönetimi kötü haber anında en çok işe yarar. Beklentiyi baştan dürüst kurmuş bir uygulayıcı, kötü haber geldiğinde "bunu birlikte öngörmüştük, planımızda vardı" diyebilir; beklentiyi abartıyla kurmuş bir uygulayıcı ise kötü haberi bir ihanet gibi sunmak zorunda kalır. Dürüst beklenti, kötü haberi bir kriz olmaktan çıkarıp bir öğrenme adımına dönüştürür. Bu, sponsor desteğini zor anlarda ayakta tutan en güçlü tamponlardan biridir ve bir saha gözlemi olarak defalarca doğrulandı.

Bu saha notunun belki en önemli ileri düzey dersi şudur: sponsor desteği tek bir kişinin iyi niyetine bağlı kaldığı sürece kırılgandır; gerçek dayanıklılık, desteği kişiden sisteme taşımakla gelir. Sahada gördüğüm en olgun kurumlar, yapay zeka projelerinin desteğini tek bir yöneticinin heyecanına değil, kurumsal bir yapıya bağlamıştı. Böylece bir yönetici ayrıldığında veya önceliği değiştiğinde proje çökmüyordu.

Desteği kurumsallaştırmanın ilk adımı, tek sponsor yerine bir yönlendirme yapısı kurmaktır. Bir ana sponsor artı birkaç paydaştan oluşan bir yönlendirme grubu, hem kararları meşrulaştırır hem de tek kişilik riski dağıtır. Bu grup düzenli toplandığında, projeye dair kararlar bir kişinin takvimine değil, kurumsal bir ritme bağlanır. Sahada gördüğüm en dayanıklı projeler, desteği bu şekilde çeşitlendirenlerdi; en kırılgan projeler ise tüm ağırlığı tek bir yöneticinin omzuna yüklemiş olanlardı. Kaynak çekilmesi riskini azaltmanın en güçlü yolu, kaynağı tek bir karar vericiye bağımlı olmaktan çıkarmaktır.

İkinci adım, desteği bir sürece bağlamaktır. Yapay zeka projelerinin bir portföy olarak yönetildiği, düzenli gözden geçirildiği ve kurumsal hedeflere bağlandığı bir yapı kurulduğunda, tek tek projelerin desteği kişisel ilişkilerin ötesine geçer. Bir proje, kurumun yapay zeka stratejisinin parçası olarak görülüyorsa, o projeyi savunan yalnızca bir kişi değil, kurumsal bir öncelik sistemi olur. Bu yapıyı kurmanın çerçevesini yapay zeka mükemmeliyet merkezi kurulumu ve genel strateji zeminini kurumsal yapay zeka stratejisi nasıl oluşturulur yazılarında ele aldım.

Üçüncü adım, sahiplik ve rolleri netleştirmektir. Kurumsallaşmış destek, "bu projeyi kim sahipleniyor, kim karar veriyor, kim kaynak ayırıyor" sorularına kalıcı ve yazılı cevaplar verir. Bu netlik, sponsor değiştiğinde bile devamlılığı sağlar; çünkü sahiplik bir kişiye değil, bir role bağlıdır. Sahada gördüğüm gerçek şu: kişiye bağlı destek hızlı ama kırılgandır, sisteme bağlı destek yavaş ama dayanıklıdır. Olgun kurumlar, ikisini dengeler — bir yandan güçlü bir kişisel sponsor, öte yandan onu taşıyan kurumsal bir yapı. Rol ve sahiplik yapısını doğru kurmak için AI organizasyon tasarımı ve düzenli saha gözlemlerinin bir arada durduğu dönüşüm kalıpları saha notu ile pilotta kalan projeler saha notu yazıları, bu kurumsallaşmayı somutlaştırır.

Bir yöneticinin sponsor desteğinin gerçek olup olmadığını en net gösteren an, ilk zafer değil, ilk kötü haberdir. Bu yüzden kötü haber anını iyi yönetmek, bir uygulayıcının en kritik becerilerinden biri; çünkü bu an, desteği ya sağlamlaştırır ya da çökertir. Sahada aynı kötü haberin, iyi yönetildiğinde desteği güçlendirdiğini, kötü yönetildiğinde ise projeyi bitirdiğini defalarca gördüm. Fark, haberin kendisinde değil, nasıl taşındığındaydı.

İlk ilke, kötü haberi erken vermektir. Ekipler çoğu zaman kötü haberi "belki düzeltiriz" umuduyla erteler; sorun büyüyüp patladığında ise yönetici hem kötü sonuçla hem de saklanmışlıkla karşılaşır ve güvenini ikiye katlayarak kaybeder. Oysa erken verilen kötü haber, henüz küçükken müdahale şansı sunar ve yöneticiye "bana güveniliyor" mesajı verir. Sahada desteğini en iyi koruyan ekipler, kötü haberi ilk duyuran taraf olmayı bir disipline dönüştürmüştü; sürprizden nefret eden yöneticiler, erken uyarıya minnet duyar. Bu, karar hızını da doğrudan besler: erken duyulan sorun, erken çözülür.

İkinci ilke, kötü haberi bir çözüm önerisiyle birlikte taşımaktır. "Şu sorun çıktı" cümlesi yöneticiyi çaresiz bırakır; "Şu sorun çıktı, iki seçeneğimiz var, ben şunu öneriyorum ve senden şu kararı bekliyorum" cümlesi ise yöneticiyi güçlendirir. Kötü haberi bir problem yığını olarak değil, bir karar noktası olarak sunmak, yöneticiyi paniğe değil eyleme yönlendirir. Sahada gördüğüm en olgun uygulayıcılar, kötü haberi hiçbir zaman çıplak taşımazdı; her zaman bir teşhis, bir seçenek ve bir öneriyle birlikte getirirlerdi. Bu, yöneticiyi projenin ortağı yapmanın en güçlü anıydı.

Üçüncü ilke, kötü haberi bir öğrenme çerçevesine oturtmaktır. Kurumsal yapay zeka projeleri deneysel ve kademelidir; her başarısızlık bir bilgi üretir. Bir kötü haberi "başarısız olduk" yerine "şunu öğrendik ve yönümüzü şöyle düzeltiyoruz" diye çerçevelemek, yöneticinin de bu deneysel doğayı içselleştirmesini sağlar. Beklentiyi baştan dürüst kurmuş bir uygulayıcı, bu çerçeveyi rahatça kullanabilir; çünkü yönetici zaten yolun düz olmayacağını biliyordur. Bu yüzden beklenti yönetimi ile kötü haber yönetimi birbirini besler; biri olmadan diğeri eksik kalır.

Kötü haber anını yönetmek, aynı zamanda desteğin dürüstlük üzerine kurulması gerektiğinin en somut kanıtıdır. Cazip ama abartılı bir anlatı, ilk kötü haberde çöker; dürüst ve mütevazı bir anlatı ise kötü haberi taşıyabilir. Bu yüzden bir uygulayıcı olarak, sponsor desteğini kısa vadeli etkileyici sunumlarla değil, uzun vadeli dürüst bir ilişkiyle kurmayı seçtim. Bu ilişki, projelerin en sık öldüğü an olan ilk kötü haberde, projeyi ayakta tutan zemin oldu. Bu deneyim örüntüsünü, dokümantasyon hazırlığı gibi görünüşte teknik ama aslında sahiplik gerektiren konularla birlikte doküman hazırlığı saha notu ve şirket içi gerçeklerle on-premise gerçekler saha notu yazılarında da paylaştım.

Bütün bu gözlemleri birkaç derse indirmem gerekirse, işte yıllar içinde damıttıklarım. Bunları bir kontrol listesi gibi değil, bir deneyim özeti gibi okuyun; her biri, birden fazla projede aynı sonucu verdiği için bu listeye girdi.

Birinci ders: destek bir imza değil, bir ilişkidir. Başlangıçtaki onay, yolculuğun başıdır, sonu değil. Sponsor desteği sürekli beslenmezse kurur; en iyi başlayan projeler bile, ilişki ihmal edildiğinde söner. İkinci ders: davranışa bak, söze değil. Bir yöneticinin desteğini ölçmek için ne söylediğine değil, zamanını, kaynağını ve riskini nasıl kullandığına bak. Takvim, bütçe ve kötü haber anı, sözlerden çok daha dürüsttür.

Üçüncü ders: karar hızı, desteğin nabzıdır. Kararlar hızlanıyorsa destek güçlüdür; kararlar yavaşlıyorsa destek eriyor demektir. Karar hızını izlemek, desteği izlemenin en pratik yoludur. Dördüncü ders: sinyalleri erken oku. Proje sönmesi ani değil, yavaştır; toplantı iptalleri, delege etme, değişen sorular ve ötelenen bütçe erken uyarılardır. Erken fark edersen kurtarabilirsin.

Beşinci ders: desteği çeşitlendir. Tek bir sponsora bağlı proje kırılgandır; desteği bir yönlendirme grubuna yaymak, hem kararı meşrulaştırır hem de tek kişilik riski dağıtır. Altıncı ders — ve belki en zoru: bazen doğru karar, durmaktır. Desteksiz bir projeyi zorlamak, ekibin enerjisini ve kurumun güvenini tüketir; onurlu bir duraklama, çoğu zaman inatçı bir sürüklemeden daha değerlidir.

Yedinci ders, dürüstlüğün desteğin temeli olduğudur. Kısa vadeli etkileyici sunumlar desteği hızlı kazandırır ama ilk kötü haberde çöker; uzun vadeli dürüst bir ilişki ise zoru göğüsleyebilir. Kötü haberi erken ve çözüm önerisiyle taşımak, beklentiyi baştan gerçekçi kurmak ve değeri abartmadan göstermek — bunlar bir uygulayıcının en kalıcı destek yatırımlarıdır. Sekizinci ve son ders ise şudur: destek, kazanılan değil, sürekli yeniden kazanılan bir şeydir. Her yönetici görüşmesi, her erken kazanım, her dürüst kötü haber, desteği yenileme fırsatıdır. Bu ritmi kaybeden ekipler desteğini de kaybetti; bu ritmi koruyanlar, en zor koşullarda bile projelerini ayakta tuttu.

Son olarak, hepsinin üstünde duran ders şu: kurumsal yapay zeka bir teknoloji projesi değil, bir değişim projesidir; ve değişim, ancak arkasında gerçek bir sahiplik varsa mümkündür. Sponsor desteği, bu sahipliğin adıdır. Kod yazılır, model eğitilir, sistem kurulur — ama bunların hiçbiri, projeyi umursayan ve onu ayakta tutmak için kendi ağırlığını koyan bir yönetici olmadan üretime dönüşmez. Sahada tekrar tekrar gördüğüm gerçek buydu ve bu saha notunun özü de budur.

Bu saha notunu, saha gözlemlerimi bir araya getiren saha notları ana sayfasıyla, ve komşu deneyim yazılarım olan veri yönetişimi eksikliği saha notu ile entegrasyon gecikmeleri saha notu ile birlikte okumanızı öneririm; hepsi aynı gerçeğin farklı yüzlerini anlatıyor. Kurumsal AI yatırımlarının neden değere dönüşemediğine dair daha geniş çerçeveyi kurumsal AI ROI neden başarısız yazısında bulabilirsiniz.

Bir projede yönetici desteği gerçekten var mı, nasıl anlaşılır?

En güvenilir işaret sözler değil, kaynak ve zaman taahhüdüdür. Gerçek sponsor desteği olan bir yönetici projeye kendi takviminden düzenli zaman ayırır, kendi ekibinin önceliklerini bu projeye göre değiştirir, engelleri bizzat kaldırır ve projeyi kendi performans hedeflerine bağlar. Sözde destekte ise yönetici yalnızca açılış toplantısında görünür, kararları sürekli erteler ve ilk bütçe sıkışmasında projeyi gözden çıkarır. Bir yöneticinin desteğini ölçmek için üç şeye bakarım: son bir ayda projeye kaç saat ayırdı, kaç engeli bizzat kaldırdı ve projeyi üst yönetime kendi ağzıyla kaç kez savundu. Bu üçü boşsa, kâğıt üstündeki destek gerçek değildir.

Sponsor desteği zayıflarsa projede ne olur?

Çoğu zaman ani bir iptal olmaz; sessiz bir proje sönmesi başlar. Önce öncelik erir; proje "önemli ama acil değil" rafına kayar. Sonra kaynak çekilmesi gelir; ekipteki kişiler başka işlere kaydırılır, bütçe "sonraki çeyreğe" ötelenir. Ardından karar kuyruğu uzar; onay bekleyen konular birikir, karar hızı düşer, motivasyon kırılır. Bu üçü birbirini besler ve proje resmen kapatılmadan fiilen durur. En tehlikeli yanı, sürecin yavaş olması ve kimsenin "projeyi öldürdük" dememesidir. Bu yüzden destek zayıflamasının erken sinyallerini okumak, projeyi kurtarmanın tek yoludur.

Yönetici desteği nasıl güçlendirilir?

Üç şey işe yarıyor. Birincisi, teknoloji değil iş sonucu konuşmak: yöneticiye model veya mimari anlatmak yerine, onun kendi hedeflerine (maliyet, hız, müşteri memnuniyeti, risk) projenin nasıl dokunduğunu göstermek. İkincisi, erken ve küçük kazanım üretmek: aylar sonra gelecek büyük bir sonuç yerine, birkaç hafta içinde görülebilir somut bir iyileşme, yöneticinin desteğini yeniler. Üçüncüsü, yöneticiyi ortak yapmak: kararları onunla birlikte almak, ilerlemeyi dürüst raporlamak ve kötü haberi de erken vermek. Desteğini en iyi koruyan ekipler, en iyi kod yazanlar değil, yöneticiyle en dürüst ve en sık konuşanlardı.

Yönetici desteği olmadan bir AI projesine başlamalı mı?

Küçük bir keşif veya kavram kanıtı için sınırlı biçimde başlanabilir; ama üretime geçmeyi hedefleyen bir proje, sağlam bir sponsor desteği olmadan başlatılmamalıdır. Nedeni basit: kurumsal yapay zeka projeleri teknik olduğu kadar örgütseldir; süreç değişikliği, bütçe, ekipler arası koordinasyon ve öncelik çatışması ancak yetkili bir yöneticinin sahiplenmesiyle çözülür. Desteksiz başlayan bir proje, teknik olarak ne kadar iyi olursa olsun ilk örgütsel engelde takılır. Başlamadan önce "bu işi kim sahipleniyor ve neden umursuyor" sorusuna net bir cevap almak gerekir; cevap muğlaksa, önce desteği inşa etmek doğrudur.

Sponsor kaybolursa veya değişirse ne yapılır?

Yönetici değişikliği kurumsal hayatın gerçeğidir ve iyi bir projenin tek bir kişiye bağımlı kalmaması gerekir. İlk önlem, desteği en baştan tek bir sponsora değil, bir yönlendirme grubuna yaymaktır; böylece bir kişi ayrılınca proje çökmez. Sponsor değiştiğinde yapılması gereken, yeni yöneticiye projeyi sıfırdan ve onun diliyle yeniden anlatmak, hızlı bir kazanım göstererek güven kazanmak ve projenin onun hedeflerine nasıl hizmet ettiğini net biçimde bağlamaktır. Eski sponsorun desteğinin otomatik devredileceğini varsaymak en pahalı hatalardan biridir; yeni sponsorun desteği yeniden kazanılır, miras alınmaz.

Kısaca söylersem: sponsor desteği, bir kurumsal yapay zeka projesine yetkili bir yöneticinin sağladığı sürekli ve aktif sahiplenmedir; ve teknik olarak sağlam projelerin çoğu koddan değil, bu desteğin sözde kalmasından ölür. Gerçek desteği sözde destekten ayıran şey kaynak ve zaman taahhüdüdür; desteğin nabzı karar hızıdır; ve desteğin çöküşü ani değil, öncelik erimesi, kaynak çekilmesi ve karar yavaşlamasıyla gelen sessiz bir proje sönmesidir.

Bu saha notunun en önemli mesajı şudur: kurumsal yapay zeka bir teknoloji değil, bir değişim işidir; ve değişim ancak arkasında gerçek bir yönetici sahipliği varsa yürür. Desteği kazanmak teknoloji anlatmakla değil, iş sonucu konuşmak, erken kazanım üretmek, yöneticiyi ortak yapmak ve destek zayıflama sinyallerini erken okumakla olur. Bunu bir teori olarak değil, defalarca aynı sonucu veren bir saha gözlemi olarak paylaşıyorum. Kurumunuzda bir yapay zeka projesini doğru sahiplikle kurmak, doğru sponsoru bulmak ve desteği sürdürülebilir kılmak için danışmanlık görüşmesi üzerinden başlayabilir, ekiplerinizin bu dili konuşabilmesi için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezi'nde derinleştirebilirsiniz.