Teknoloji tarihinde bazı dönemler vardır. Herkes büyük bir değişimin geldiğini hisseder, şirketler yatırım yapar, yöneticiler sunumlarında bu yeni teknolojiden bahseder, danışmanlar yeni kavramlar üretir, tedarikçiler hızlıca yeni ürünler çıkarır. Fakat bütün bu hareketliliğe rağmen verimlilik göstergeleri beklenen hızda değişmez. İnsanlar doğal olarak şu soruyu sormaya başlar: “Bu kadar büyük teknoloji yatırımı yapıyoruz ama gerçek verimlilik nerede?”

AI Neden Beklenen Sıçramayı Hemen Üretmiyor?
Bugün yapay zeka, özellikle de büyük dil modelleri, ajan tabanlı sistemler ve üretken AI için konuştuğumuz şey tam olarak budur. Şirketler ChatGPT benzeri asistanlar kullanıyor, yazılımcılar kod tamamlama araçlarından destek alıyor, müşteri hizmetleri chatbot denemeleri yapıyor, raporlama ve doküman üretimi için LLM tabanlı çözümler devreye giriyor. Ancak birçok kurumda AI hala mevcut işlerin üzerine eklenmiş bir yardımcı katman gibi duruyor. Bir çalışanın yaptığı işi biraz hızlandırıyor, bir raporun ilk taslağını çıkarıyor, bir e-postayı daha düzgün yazıyor, bir kod bloğunu daha hızlı oluşturuyor. Bunlar faydalı işlerdir, ama tarih bize şunu söylüyor: Gerçek verimlilik sıçraması, yeni teknoloji eski iş yapış biçiminin üzerine yapıştırıldığında değil, işin kendisi yeni teknolojiye göre baştan tasarlandığında ortaya çıkar.
Bu noktada Paul A. David’in 1990 yılında yayımlanan “The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox” başlıklı makalesi bugün AI dönüşümünü anlamak için çok değerli bir referans sunuyor. David, bilgisayar devriminin neden kısa vadede beklenen üretkenlik artışını hemen üretmediğini anlamak için elektrik dinamosunun tarihine bakar. Makaledeki temel fikir basittir ama çok güçlüdür: Genel amaçlı teknolojiler, yani birçok sektöre ve sürece uygulanabilen temel teknolojiler, tek başlarına verimlilik yaratmazlar. Verimlilik etkisi, bu teknolojilerin çevresinde yeni tamamlayıcı sistemler, yeni süreçler, yeni organizasyon yapıları, yeni beceriler ve yeni tasarım ilkeleri oluştuğunda ortaya çıkar.
Kısa cevap: AI’yi eski iş akışlarının içine yerleştirmek yetmez. İşi, AI’nin doğal kabiliyetlerine göre yeniden tasarlamak gerekir.
Elektrik bunun en klasik örneklerinden biridir. Fabrikalara elektrik motoru koymak, otomatik olarak modern üretim yaratmadı. İlk dönemlerde birçok fabrika eski buhar gücü mantığıyla tasarlanmıştı. Güç merkezi bir noktadan sağlanıyor, kayışlar ve miller aracılığıyla makinelere dağıtılıyordu. Elektrik geldiğinde ilk refleks, bu eski yapıyı tamamen değiştirmek değil, mevcut yapının içine elektrik motorunu eklemek oldu. Yani elektrik, eski sistemin üzerine monte edildi. Bu yaklaşım kısmi fayda sağladı ama esas verimlilik sıçramasını yaratmadı.
Asıl kırılma, elektrik motorunun sadece yeni bir güç kaynağı olarak değil, fabrika tasarımını değiştiren bir unsur olarak görülmesiyle geldi. Elektrik sayesinde her makinenin kendi motoruna sahip olduğu daha esnek düzenler mümkün oldu. Fabrika binaları daha hafif, tek katlı, lineer ve malzeme akışına göre optimize edilmiş şekilde tasarlanabildi. Üretim hatları daha kolay değiştirilebilir hale geldi. Bakım, yerleşim değişikliği ve kapasite artırımı daha esnek yönetilebildi. Yani verimlilik artışı, elektrik motorunun alınmasıyla değil, elektrikli üretim mantığına uygun yeni fabrika tasarımının ortaya çıkmasıyla geldi.
AI Eklentisi ile AI-Native Süreç Aynı Şey Değil
Bugün AI için de benzer bir dönemin içindeyiz. AI’yi mevcut işlere ekliyoruz. Ama henüz birçok yerde AI’ye göre tasarlanmış iş süreçleri kurmuyoruz. Bu nedenle beklenti ile gerçek etki arasında bir boşluk oluşuyor.
Bir satın alma ve tedarikçi onay süreci düşünelim. Bugün birçok şirkette bir ekip yeni bir yazılım, hizmet veya ekipman almak istediğinde önce bir talep formu doldurur, sonra bütçe kontrolü yapılır, ardından güvenlik, uyumluluk, hukuk ve finans onayı beklenir. Tedarikçi bilgileri ayrı bir formda toplanır, sözleşme taslağı incelenir, vergi ve ödeme bilgileri doğrulanır, bazı durumlarda bilgi güvenliği anketi veya risk değerlendirmesi istenir, sonrasında satın alma siparişi açılır. AI bu sürece eklendiğinde genellikle şöyle kullanılır: Talep metni özetlenir, sözleşmede riskli maddeler aranır, tedarikçi evrakları okunur, önceki onay kayıtları bulunur, eksik alanlar işaretlenir. Bu faydalıdır. Süreci hızlandırır, tekrar eden işi azaltır, hata riskini düşürür. Ama süreç çoğu zaman yine aynı kalır: belge toplayan, onay bekleyen, kuyrukta ilerleyen, birimler arası aktarılan klasik bir iş akışı sürer. AI burada eski sistemin üzerine takılmış elektrik motoru gibidir.
Oysa gerçekten AI-native bir satın alma akışı farklı tasarlanmalıdır. Talep geldiği anda sistem yalnızca metni okumamalı, şirket politikalarını, bütçe limitlerini, satın alma kategorisini, geçmiş tedarikçi performansını, güvenlik ve uyumluluk şartlarını, sözleşme şablonlarını ve ödeme koşullarını birlikte değerlendirmelidir. Basit ve düşük riskli talepler belirli kurallar içinde otomatik ilerleyebilir; yüksek riskli ya da istisna içeren talepler ise doğru insanlara yönlendirilir. Sistem eksik alanları toplar, riskli maddeleri işaretler, alternatif tedarikçi önerir, benzer geçmiş kararları getirir, standart sözleşme eklerini hazırlar ve onay sürecini mümkün olduğunca akıllı bir şekilde orkestre eder. İnsan bu yapıda belge taşıyan kişi değil, istisna yöneticisi ve karar verici olur. Sürecin tasarımı “AI insana yardım etsin” mantığından “AI süreci uçtan uca yönetsin, insan kritik eşiklerde devreye girsin” mantığına dönüşür. İşte verimlilik sıçraması burada başlar.
Yazılım geliştirme için de benzer bir durum geçerlidir. Bugün birçok ekip AI kod asistanları kullanıyor. Geliştirici kod yazarken öneri alıyor, test taslağı oluşturuyor, hata mesajını açıklatıyor, dokümantasyon üretiyor. Bunlar önemlidir ama yazılım geliştirme sürecinin tamamını değiştirmez. Jira aynı Jira’dır, analiz dokümanı aynı dokümandır, code review aynı review sürecidir, test aynı test döngüsüdür, deploy aynı CI/CD zinciridir. AI sadece bazı adımları hızlandıran bir yardımcıdır.
Otonom yazılım geliştirme zinciri ise çok daha farklı bir tasarım gerektirir. Gereksinim geldiğinde AI önce bunu yapılandırılmış bir ürün gereksinimine dönüştürür. Etki analizi yapar, mevcut kod tabanındaki ilgili modülleri bulur, mimari kısıtları çıkarır, veri modeli değişikliklerini önerir, test senaryolarını üretir, riskleri sınıflandırır. Daha sonra ajanlar arasında görev dağılımı yapılır. Bir ajan backend değişikliğini hazırlar, bir ajan migration üretir, bir ajan frontend etkisini çıkarır, bir ajan API sözleşmesini kontrol eder, bir ajan güvenlik ve yetki kurallarını doğrular, bir ajan testleri çalıştırır, bir ajan release notunu hazırlar. İnsan geliştirici bu zincirde her satırı manuel yazan kişi olmaktan çıkar, sistem tasarımını, karar noktalarını, kalite standartlarını ve istisnaları yöneten kişiye dönüşür.
Bu dönüşüm, sadece Copilot veya benzeri bir aracın lisansını almakla olmaz. Bunun için geliştirme sürecinin baştan tasarlanması gerekir. Gereksinim formatları, kod standartları, test stratejileri, branch yapısı, review kriterleri, mimari karar kayıtları, dokümantasyon yapısı ve deployment süreçleri AI ile çalışabilecek hale getirilmelidir. Aksi halde AI mevcut karmaşanın içine girer ve sadece karmaşayı daha hızlı üretir.
Verimlilik Nerede Kayboluyor?
Bu noktada “AI ile verimlilik” tartışmasında en çok yapılan hatalardan biri, verimliliği sadece bireysel hızlanma olarak görmektir. Bir yazılımcı yüzde 20 daha hızlı kod yazarsa, bir destek uzmanı yüzde 30 daha hızlı cevap verirse, bir analist raporu bir saat yerine on dakikada hazırlarsa bunun toplam şirket verimliliğine doğrudan yansıyacağı varsayılır. Ancak iş süreçleri çoğu zaman tek kişinin hızından ibaret değildir. Darboğazlar onay süreçlerinde, veri erişiminde, sistem entegrasyonunda, karar mekanizmalarında, departmanlar arası koordinasyonda, kalite kontrol noktalarında ve eski alışkanlıklarda oluşur. Bir adımı hızlandırmak, eğer sonraki adım aynı şekilde yavaş kalıyorsa toplam akışı sınırlı etkiler.
Bu nedenle AI dönüşümünde asıl soru şu olmalıdır:
“Bu işi AI ile biraz daha hızlı nasıl yaparız?” değil, “AI’nin doğal kabiliyetleri olsaydı bu işi en baştan nasıl tasarlardık?”
Bu soru çok farklı bir düşünme biçimi gerektirir.
Süreçleri Yeniden Tasarlamak
Örneğin raporlama sürecini ele alalım. Klasik yapıda bir yönetici rapor ister. Bir analist ilgili sistemlerden veri çeker, Excel’de düzenler, grafik oluşturur, yorum yazar, sunum hazırlar. AI bu sürece eklendiğinde analist rapor metnini AI’ye yazdırabilir veya grafik yorumlarını hızlandırabilir. Fakat süreç hala talep bazlıdır, manuel veri çekmeye dayanır, statik çıktılar üretir.
AI’ye göre yeniden tasarlanmış raporlama sürecinde ise sistem sürekli veri kaynaklarını izler, iş metriklerini takip eder, sapmaları tespit eder, neden analizi yapar, farklı kırılımlarda karşılaştırma üretir, yöneticinin doğal dilde sorduğu sorulara göre veri üzerinde ilerler, gerekirse aksiyon önerir. Rapor artık belirli periyotlarda hazırlanan statik bir doküman olmaktan çıkar, sürekli çalışan analitik bir karar destek sistemine dönüşür. Burada AI sadece rapor yazmaz, karar sürecinin mimarisini değiştirir.
Üretim operasyonlarında da benzer bir dönüşüm mümkündür. Bir fabrikada AI sadece arıza kayıtlarını özetleyen veya operatöre prosedür öneren bir araç olarak kalabilir. Bu faydalıdır ama sınırlıdır. Daha ileri tasarımda AI, makine verilerini, kalite sonuçlarını, bakım geçmişini, vardiya performansını, enerji tüketimini ve üretim planını birlikte analiz eder. Anomaliyi erken yakalar, olası kök nedeni tahmin eder, bakım aksiyonunu önerir, üretim planı etkisini hesaplar, stok ve teslimat riskini gösterir. İnsan ekipler bu önerileri değerlendirir, kritik kararları verir ve sistemin öğrenme döngüsünü besler. Böyle bir yapıda AI tek bir ekranın içine eklenen özellik değil, operasyonel yönetim modelinin parçasıdır.
Bu ayrımı net yapmak gerekiyor: AI eklentisi ile AI-native süreç aynı şey değildir.
AI eklentisi, mevcut sürecin üzerine konur. AI-native süreç, mevcut süreci sorgular.
AI eklentisi, insanın yaptığı işi hızlandırmaya çalışır. AI-native süreç, işin hangi kısmının insan tarafından yapılması gerektiğini yeniden tanımlar.
AI eklentisi, eski veri yapıları ve eski organizasyon sınırları içinde çalışır. AI-native süreç, veri akışlarını, karar noktalarını ve sorumlulukları yeniden düzenler.
AI eklentisi, kısa vadeli verimlilik sağlar. AI-native süreç, uzun vadeli verimlilik sıçraması yaratır.
AI Dönüşümünün İlkeleri
Paul A. David’in elektrik ve bilgisayar karşılaştırmasından çıkarılacak en önemli derslerden biri budur. Genel amaçlı teknolojiler, olgunlaştıkça ve yaygınlaştıkça etkilerini artırır. Fakat bu etki gecikmelidir. Çünkü teknoloji tek başına yeterli değildir. Onu tamamlayan yeni sermaye yatırımları, yeni beceriler, yeni standartlar, yeni organizasyon modelleri ve yeni tasarım pratikleri gerekir. Elektrikte bu, fabrikanın fiziksel tasarımını değiştirmekti. Bilgisayarda bu, bilgi süreçlerinin dijitalleşmesi, ağların kurulması, yazılım sistemlerinin yaygınlaşması ve veri tabanlı yönetimin gelişmesiydi. AI’de ise bu, bilgi işi süreçlerinin, karar süreçlerinin ve operasyonel akışların yeniden tasarlanması olacaktır.
Bugün birçok şirket AI yatırımlarına başlıyor ama eski organizasyon yapısını koruyor. Departmanlar aynı, onay mekanizmaları aynı, veri sahipliği aynı, entegrasyon yaklaşımı aynı, süreç KPI’ları aynı. Sonra AI’den radikal verimlilik bekleniyor. Bu beklenti gerçekçi değildir. Çünkü AI’nin değeri çoğu zaman departman sınırlarını aşan akışlarda ortaya çıkar. Müşteri talebini anlamak için CRM gerekir, işlem yapmak için ERP gerekir, teknik veri için ürün sistemi gerekir, geçmiş destek kayıtları için ticket sistemi gerekir, sözleşme bilgisi için doküman yönetimi gerekir. AI’nin bu süreçte gerçek değer üretmesi için sadece model değil, kurumsal bağlam, veri erişimi, yetki modeli, işlem kabiliyeti ve denetim mekanizması gerekir.
Burada ajan mimarileri önemli hale geliyor. LLM tek başına metin üreten bir motor olarak kullanıldığında etkisi sınırlıdır. Ancak araç kullanabilen, veri kaynaklarına erişebilen, iş kurallarını bilen, görevleri parçalara ayırabilen, başka ajanlarla koordinasyon kurabilen ve sonuçları denetleyebilen sistemlere dönüştüğünde daha büyük bir potansiyel ortaya çıkar. Yine de ajan kullanmak da tek başına çözüm değildir. Ajanlara ne yaptıracağımızı, hangi sınırlar içinde çalışacaklarını, hangi kararları otomatik alabileceklerini, hangi durumlarda insana döneceklerini, nasıl izleneceklerini ve nasıl ölçüleceklerini tasarlamak gerekir.
Yani yeni soru sadece “Hangi modeli kullanalım?” değildir. Yeni soru şudur: “Bu süreci AI ve ajanlar çalışacak şekilde nasıl yeniden kurmalıyız?”
Bu sorunun cevabı her şirket için farklıdır ama bazı ortak ilkelerden bahsedebiliriz.
Birinci ilke, süreci görev listesi olarak değil, karar ve bilgi akışı olarak modellemektir. AI özellikle bilgi toplama, bağlam kurma, sınıflandırma, özetleme, karşılaştırma, öneri üretme ve alternatifleri değerlendirme gibi alanlarda güçlüdür. Bu nedenle süreç analizinde sadece “kim ne yapıyor?” sorusu yetmez. “Hangi bilgi nereden geliyor?”, “Hangi karar hangi bağlama dayanıyor?”, “Hangi adımda belirsizlik var?”, “Hangi istisnalar insan uzmanlığı gerektiriyor?”, “Hangi kararlar kurallarla güvenli şekilde otomatikleşebilir?” soruları da sorulmalıdır.
İkinci ilke, veriyi AI’nin kullanabileceği hale getirmektir. Kurumsal verinin dağınık, eksik, bağlamsız ve erişilemez olduğu bir ortamda AI’den sağlıklı karar desteği beklemek doğru değildir. AI dönüşümü, veri mimarisi dönüşümünden ayrı düşünülemez. Dokümanlar, veri tabanları, API’ler, loglar, müşteri kayıtları, ürün katalogları, prosedürler ve geçmiş kararlar AI tarafından anlamlandırılabilir hale getirilmelidir. Burada sadece vektör veri tabanı kurmak yeterli değildir. Metadata, yetki, versiyon, kaynak güvenilirliği, güncellik, sahiplik ve izlenebilirlik de tasarımın parçası olmalıdır.
Üçüncü ilke, insan rolünü doğru yeniden tanımlamaktır. AI dönüşümünün başarısı insanı tamamen süreç dışına atmakla değil, insanın en yüksek değer ürettiği noktaları netleştirmekle ilgilidir. İnsanlar bağlamı yorumlar, stratejik öncelik belirler, etik ve hukuki değerlendirme yapar, istisnaları yönetir, müşteri ilişkisini sahiplenir, kalite standardını tanımlar, sistemin yanlışlarını düzeltir. AI’nin işi ise tekrar eden bilgi işlerini hızlandırmak, seçenekleri çoğaltmak, veriden sinyal çıkarmak, karar hazırlığını yapmak ve operasyonel akışı otomatikleştirmektir.
Dördüncü ilke, ölçüm sistemini yenilemektir. Elektrik döneminde birçok faydanın verimlilik istatistiklerine hemen yansımamasının nedenlerinden biri kalite artışı, esneklik, güvenlik, hız ve yeni hizmet türlerinin ölçülmesindeki zorluktu. AI için de aynı sorun geçerlidir. Bir AI sistemi sadece kişi başı işlem sayısını artırmayabilir. Hata oranını azaltabilir, yanıt kalitesini artırabilir, müşteri bekleme süresini düşürebilir, daha iyi karar alınmasını sağlayabilir, çalışan eğitim süresini kısaltabilir, bilgi kaybını azaltabilir, regülasyon uyumunu güçlendirebilir. Bunlar ölçülmezse AI’nin etkisi eksik görünür.
Beşinci ilke, pilotları doğru seçmektir. AI pilotları genellikle kolay görünen ama stratejik etkisi sınırlı konularda yapılır. Bir doküman özetleme aracı, bir chatbot, bir içerik üretim yardımcısı hızlıca gösterilebilir. Ancak gerçek dönüşüm, uçtan uca süreçlerde denenmelidir. Örneğin destek talebinden aksiyona kadar giden süreç, gereksinimden çalışan koda kadar giden yazılım geliştirme zinciri, üretim anomalisinden bakım kararına kadar giden operasyon akışı, satış fırsatından teklif ve sözleşmeye kadar giden ticari süreç gibi alanlar daha değerlidir. Çünkü AI’nin asıl etkisi tekil görevde değil, akışın tamamında ortaya çıkar.
Altıncı ilke, entegrasyonu ürünün merkezine koymaktır. AI sistemleri kurumsal dünyada izole çalışamaz. Ticket açamayan, ERP kaydı okuyamayan, CRM güncelleyemeyen, üretim verisine erişemeyen, doküman versiyonlarını ayırt edemeyen, yetki kontrolü yapamayan bir AI sistemi çoğu zaman sadece iyi konuşan bir arayüz olarak kalır. Verimlilik için AI’nin konuşması yetmez, işlem yapabilmesi gerekir. Ama işlem yapabilmesi için de güvenlik, yetki, audit log, rollback, onay, açıklanabilirlik ve sorumluluk tasarımı gerekir.
Yedinci ilke, organizasyonel öğrenmeyi hızlandırmaktır. Elektrikli fabrika tasarımında olduğu gibi, AI-native süreç tasarımı da bir anda ortaya çıkmaz. Deneme, hata, öğrenme ve standartlaşma gerekir. Şirketlerin AI deneyimlerini sadece PoC çıktısı olarak değil, tekrar kullanılabilir süreç desenleri olarak biriktirmesi gerekir. Hangi görevler ajana verilebilir? Hangi veri kaynakları daha güvenilir? Hangi prompt desenleri daha iyi çalışıyor? Hangi kontrol noktaları gerekli? Hangi metrikler anlamlı? Hangi insan müdahalesi gerçekten değer katıyor? Bu bilgi kurumsal hafızaya dönüşmediği sürece her AI projesi sıfırdan başlar.
Yönetim Sorusu
Burada yöneticilere düşen görev de değişiyor. AI stratejisi sadece araç seçimi, lisans bütçesi veya model karşılaştırması değildir. AI stratejisi, iş süreçlerinin yeniden tasarım stratejisidir. Hangi süreçler AI-native hale getirilecek? Hangi süreçlerde insan merkezli yapı korunacak? Hangi kararlar otomatikleşecek? Hangi yetkiler AI sistemlerine verilecek? Hangi veri altyapısı kurulacak? Hangi roller yeniden tanımlanacak? Hangi metriklerle başarı ölçülecek? Hangi regülasyon ve güvenlik sınırları konulacak? Bu sorulara cevap vermeden yapılan AI yatırımları, elektrik motorunu eski mil ve kayış sistemine bağlamak gibi olacaktır.
Bu nedenle bugünkü AI dönüşümünü sadece “daha akıllı araçlar” dönemi olarak görmemek gerekir. Daha doğru ifade şudur: AI, bilgi işinin elektrikleşmesidir. Ama tıpkı elektrikleşmede olduğu gibi, ilk aşamada eski düzenin üzerine yeni motorlar takıyoruz. Eski ekranlara AI butonları ekliyoruz. Eski formların yanına öneri kutuları koyuyoruz. Eski raporların özetini alıyoruz. Eski müşteri hizmetleri akışına chatbot ekliyoruz. Eski yazılım geliştirme zincirine kod asistanı bağlıyoruz. Bunlar geçiş dönemi için normaldir. Fakat burada kalırsak beklenen sıçrama gelmez.
Asıl mesele, araç eklemek değil, işin mantığını yeniden kurmak.
Bu yazıyı beğendiyseniz Twitter’da takipçilerinizle paylaşabilir veya beni Twitter’da takip edebilirsiniz.