Endüstriyel otomasyon ve kurumsal bilişim altyapısında değer, fiziksel donanımdan operasyonu yöneten kontrol düzlemine ve platform katmanına kayıyor. Donanım ölmedi; ancak tek başına bir varış noktası olmaktan çıkıp yazılım, telemetri, veri ve yapay zekâ servislerini müşterinin tesisine sokan stratejik bir Truva Atı’na dönüştü. Siemens’in fabrikayı Xcelerator ile bir yaşam döngüsü işletim sistemine çevirmesinden, HPE’nin VMware krizini Morpheus VM Essentials ve GreenLake ile veri merkezinde pazar fırsatına dönüştürmesine kadar; kazananlar donanım veya saf yazılım değil, müşteriyi kendi ekosistemine bağlayan platformlar inşa ediyor.

Tez: Donanımdan Platforma Değer Göçü

1990’larda rekabet “en iyi donanımı kim üretiyor?” sorusuydu. 2000’lerde sektör “yazılım dünyayı yiyip bitirecek” manifestosuyla yazılıma koştu. Ama bu koşu tek başına yeterli olmadı. Yazılımı donanımdan bağımsız, kendi başına bir ürün olarak satmaya çalışanlar tökezledi. Kazananlar ise sessizce farklı bir mimari kuruyordu: donanımı, yazılımı, veriyi, yapay zekâyı, servisleri ve ekosistemi tek çatıda birleştiren platformlar.

Bugün soru tamamen değişti: müşterinin bütün operasyonunu kim yönetiyor? Siemens, HPE, Schneider Electric, ABB, Cisco, Dell Technologies, Emerson ve Rockwell Automation artık donanım satmıyor. Yazılım da satmıyor. Platform satıyorlar. Ve bu yapıyı bir kez kuran şirket, müşterinin çalışma biçimini doğrudan belirliyor.

Bu makale; bu dönüşümün neden kaçınılmaz olduğunu, “yazılıma geçiş” söyleminin neden yetersiz kaldığını, platformu kuranlarla yazılımda takılıp kalanlar arasındaki farkı ve finansal kanıtları analiz ediyor.

Donanım Ölmedi, Rolü Değişti

Şunu en başta netleştirelim: donanım öldü diye bir tablo yok. NVIDIA, ASML ve TSMC bugün dünyanın en değerli teknoloji şirketleri arasında. Yarı iletken kıtlığı bütün küresel tedarik zincirini kilitleyebiliyor. Yapay zekâ devriminin tam kalbinde GPU kümeleri duruyor.

Değişen şey donanımın kendisi değil, iş modelindeki konumu. Eskiden donanım son üründü. Satıyordun, müşteri alıyordu, işlem tamamlanıyordu. Sözleşme süresi dolduğunda veya cihaz eskidiğinde müşteri rahatlıkla rakip bir donanımı yerine koyabiliyordu: tek seferlik gelir, döngüsel nakit akışı ve sürekli aşınan marjlar.

Bugün donanım son ürün değil, platformun fiziksel taşıyıcısıdır. Sensör, sunucu, PLC veya switch; bunların hepsi asıl değeri taşıyan yazılım ve hizmet katmanını müşterinin tesisine sokmak için kullanılan birer giriş kapısıdır.

Bir kez içeri girdiğinde, artık o cihazın üzerine kurulu platform müşterinin günlük operasyonlarını yönetir hale gelir. Tasarım, üretim planlaması, felaket kurtarma, öngörücü bakım, otonom karar alma; bunların hepsi platform katmanında yürütülür. Müşteri bu donanımı söküp atmak istediğinde, aslında kendi operasyonel omurgasını sökmek zorunda kalır.

“Yazılımcı Olalım” Dalgası ve General Electric Dersi

Bu dönüşüm düz bir çizgide gerçekleşmedi. Sektörün büyük çoğunluğu önce “yazılıma geçiyoruz” dedi. Marc Andreessen’in 2011’deki ünlü manifestosu bu dalganın meşrulaştırıcı metni oldu. Donanım şirketleri art arda yazılım firmaları satın almaya, kendilerini “dijital endüstriyel şirket” olarak yeniden konumlandırmaya başladı.

Ve bu dalganın en çarpıcı başarısızlık örneği GE Predix oldu. General Electric 2015’te büyük bir iddia ortaya koydu: dünyanın en büyük dijital endüstriyel şirketi olacaktı. Milyarlarca dolar yatırım yaptı ve Predix adını verdiği endüstriyel IoT platformunu kurdu. Ama kritik bir hata yaptı: yazılımı donanımdan bağımsız, kendi başına satılabilecek genel bir ürün olarak konumlandırdı. Predix, GE’nin kendi türbin ve lokomotif ekipmanlarıyla sıkı sıkıya entegre olmak yerine, herkesin kullanabileceği genel amaçlı bir bulut platformu olmaya çalıştı.

Sonuç: sahada operasyonel karşılığı olmayan, müşterinin iş akışıyla bütünleşmeyen bir yazılım kütüphanesi. GE Digital 2018 sonunda yeniden yapılandırılarak küçültüldü ve milyarlarca dolarlık değer düşüklüğü (write-down) kaydedildi.

GE’nin hatası yazılıma yatırım yapmak değildi. Hatası, yazılımı tek başına son ürün zannetmekti. Aynı dönemde Siemens’in izlediği yol ise tam tersi bir stratejik olgunluk sergiledi. Siemens 2007’den itibaren UGS, Mentor Graphics, Mendix ve Altair’i satın aldı; ama bunları birbirinden bağımsız yazılım ürünleri olarak satmadı. Her satın alma, Xcelerator denen bütünün bir tuğlasıydı. Tasarım, simülasyon, düşük kodlu geliştirme ve hesaplamalı zekâ; bunların hepsini donanımın üzerine oturan ve müşterinin operasyonuna gömülen tek bir platform mimarisinde birleştirdi.

Sektörün söylemi iki aşamalıydı: önce yazılıma geç, sonra platformu keşfet. Oysa kazananların pratiği başından beri platform yönündeydi. Kaybedenleri ayıran temel faktör de buydu: yazılımı varış noktası sandılar, oysa yazılım yolun sadece yarısıydı.

Truva Atı Stratejisi: Donanım Kapıyı Nasıl Açıyor?

B2B pazarındaki yazılım doygunluğu bu stratejiyi zorunlu kılıyor. Yapay zekâ ve büyük dil modellerinin yükselişiyle standart SaaS ürünleri haftalar içinde kopyalanabilir hale geldi. Eğer bir yazılım ürünü hızla yeniden inşa edilebiliyorsa, o ürünün pazarda kalıcı bir savunma hattı kurması son derece zordur.

Donanım ise tamamen farklı bir dinamikle çalışır. Geliştirmek maliyetlidir, üretim süreçleri karmaşıktır ve sahada kusursuz çalışması şarttır. Ancak bir kez müşterinin veri merkezine, fabrika zeminine veya enerji şebekesine girmeyi başardığında, rakip yazılımların kolay kolay nüfuz edemeyeceği korunaklı bir alan açar.

Dışarıdan bakıldığında sıradan bir endüstriyel sensör, ağ yönlendiricisi veya sunucu görünür. İçeride ise telemetri yetenekleri, gömülü yazılımlar ve platform bağlantıları yer alır. Cihaz müşterinin sistemine entegre olduktan sonra bu yetenekler devreye girer.

Bu strateji özellikle muhafazakâr pazarlarda çalışır. Savunma, sağlık, enerji ve ağır sanayi gibi sektörler; bürokrasi ve kökleşmiş risk refleksleri nedeniyle saf yazılım satışına direnç gösterir. Ancak fiziksel bir problemi somut olarak çözen tanıdık bir donanımı satın almaya çok daha açıktırlar. Donanım bir kez sahaya girdikten sonra, gömülü platform doğal olarak operasyonun içine yerleşir. Fiziksel varlık yalnızca bir dağıtım kanalı değildir; aynı zamanda telemetri verilerinin, güvenlik sertifikasyonlarının ve kestirimci bakım gibi katma değerli hizmetlerin operasyonel tekelini üreticiye verir.

Siemens: Fabrikayı İşletim Sistemine Dönüştürmek

Siemens’in bu dönüşümü tesadüf değildir ve yeni de başlamamıştır. PLC ve SCADA üreticisi olarak bilinen şirket, fiziksel bileşenlerin metalaşacağını yirmi yıl önceden öngörerek agresif bir satın alma ve entegrasyon stratejisi yürüttü: 2007’de UGS satın almasıyla PLM, CAD ve CAM alanına girdi; 2017’de Mentor Graphics ile elektronik tasarım ve entegre simülasyonu, 2018’de Mendix ile düşük kodlu (low-code) platform katmanını portföyüne kattı ve 2024’te duyurulan 10.6 milyar dolarlık Altair Engineering satın alma anlaşmasıyla bu dönüşümü zirveye taşıdı.

Altair Hamlesi ve Xcelerator Portföyü

Altair hamlesi stratejiyi en üst seviyeye taşıdı. Altair’in hesaplamalı zekâ, yüksek performanslı bilgi işlem (HPC) ve simülasyon yetenekleri Siemens Xcelerator platformuna entegre edildiğinde, ortaya çıkan yapı geleneksel bir endüstriyel yazılımın çok ötesine geçti.

Müşteriler artık bir ürünün sadece mekanik tasarımını yapmakla kalmıyor; yapay zekâ algoritmalarıyla malzeme yorulmalarını, termal dinamikleri ve elektromanyetik etkileşimleri sanal ortamda eksiksiz test edebiliyor. Siemens’in kurduğu denklem şudur: fabrikadaki PLC fiziksel donanım olarak çalışır. Üstüne, ürünün tasarım aşamasından simülasyonuna, üretim hattındaki optimizasyondan satış sonrası bakımına kadar uzanan bir yaşam döngüsü platformu inşa edilir. Makineyi satın alan fabrika, o makinenin beyni ve sinir sistemi haline gelen Xcelerator platformundan bir daha ayrılamaz.

Siemens’in Büyüme ve Kârlılık Göstergeleri

Siemens 2025 mali yılını 78.9 milyar Euro gelir ve 10.4 milyar Euro net kâr ile tamamladı. Q2 2026 finansallarında siparişler yüzde 18 artarak 24.1 milyar Euro’ya çıktı. Toplam sipariş birikimi 124 milyar Euro ile tarihi rekor seviyeye ulaştı.

Dijital Endüstriler yazılım birimi ilgili çeyrekte yıllık bazda yüzde 14 büyüyerek 1.6 milyar Euro gelir elde etti. Müşterilerin abonelik ve buluta geçişini temsil eden organik yıllık tekrar eden gelir (ARR) yüzde 11 artışla 5.5 milyar Euro’ya yükseldi.

Donanım ticareti gümrük tarifelerine, demiryolu altyapı gecikmelerine ve döviz kuru dalgalanmalarına son derece açıktır. Buna rağmen Siemens endüstriyel işletme kâr marjını yüzde 15.4 seviyesinde tutmayı başardı. Sebebi açıktır: yazılım ve platform katmanının kâr marjı, donanımın marj erozyonunu telafi edecek kadar güçlüdür.

HPE: Veri Merkezinin İşletim Sistemini Yazmak

Siemens fabrikayı nasıl platformlaştırıyorsa, Hewlett Packard Enterprise (HPE) de veri merkezini aynı yaklaşımla bütünleştiriyor. Sunucu, depolama ve ağ donanımları satan HPE, saf donanım marjlarının genel bulut sağlayıcıları tarafından nasıl eritildiğini erkenden fark eden üreticilerden biridir.

HPE’nin stratejik kararı net bir kabule dayanır: bulut bir yer değil, bir işletme modelidir. Donanımı müşterinin veri merkezine yerleştir, ancak yönetim ve orkestrasyonunu GreenLake platformu üzerinden hizmet olarak sun. Şirket bu mimariyi kurmak için Zerto ile felaket kurtarma, OpsRamp ile AIOps, Morpheus Data ile hibrit bulut orkestrasyonu ve Juniper Networks ile ağ katmanını bünyesine kattı.

VMware Lisans Krizi ve Morpheus VM Essentials Fırsatı

HPE’nin platform stratejisinin en somut sınavı 2026’da yaşandı. Broadcom’un VMware’i satın almasının ardından lisanslama modelini çekirdek bazlı aboneliklere çevirmesi ve fiyatları katlaması, kurumsal IT dünyasında ciddi bir maliyet şoku yarattı. Müşteriler eski lisans ile yeni altyapıyı aynı anda finanse etmek zorunda kaldıkları çifte maliyet problemiyle karşılaştı.

HPE bu krizi doğrudan bir pazar penetrasyonu fırsatına çevirdi:

• Agresif Fiyatlandırma ve HVM Mimarisi: Morpheus VM Essentials ile KVM tabanlı kurumsal HPE HVM hipervizör katmanı sundu; VMware ESXi kümeleriyle tek konsoldan çalışabilme yeteneği sağladı. Soket başına yaklaşık 600 dolarlık maliyetle VMware’e kıyasla yüzde 90’a varan tasarruf sundu.
• Donanım ve Depolama Kenetlenmesi: HPE Alletra MP kurumsal depolama altyapısını ve gelişmiş sanal anahtar (Virtual Switch) ağ mimarisini doğrudan kontrol düzlemine entegre etti. AMD işlemcili sunucu alan müşterilere bir yıl ücretsiz lisans tanımladı; Zerto veri taşıma lisansını sembolik 1 dolara çekti ve 600 yetkili iş ortağına üç yıl ücretsiz dağıtım hakkı verdi.

HPE CEO’su Antonio Neri’nin vurguladığı gibi: müşteri hibrit kontrol düzlemini bir kez benimsediğinde, alttaki sanallaştırma katmanı ne olursa olsun tüm altyapı GreenLake çatısı altında toplanır. Bu, sunucu satmanın çok ötesinde kurumsal BT mimarisine yerleşme hamlesidir.

HPE’nin Finansal Sıçraması ve Sipariş Göstergeleri

HPE GreenLake ARR’si 2023’te 1.3 milyar dolar seviyesindeyken, Q4 2025’te yüzde 63 organik büyümeyle 3.2 milyar dolara ulaştı. Q2 2026’da toplam çeyrek geliri yüzde 40 artışla 10.7 milyar dolara çıkarak rekor kırdı.

Bulut ve AI segmenti yüzde 32.7 büyümeyle 5.5 milyar dolar, Ağ segmenti Juniper entegrasyonuyla yüzde 148 büyümeyle 2.7 milyar dolar ciro üretti. Yapay zekâ sipariş birikimi 6.3 milyar doları aştı. Non-GAAP hisse başına kazanç 0.79 dolar ile analist beklentilerini geride bıraktı.

Sadece İki Şirketin Hikayesi Değil: Sektör Çapında Platformlaşma

Bu dönüşüm münferit bir taktik değildir. Farklı dikey pazarların liderleri aynı deseni takip etmektedir:

• Schneider Electric: Klasik elektrik panosu ve şalter satışından EcoStruxure platformuna geçti. Şirketin “Dijital Volan” gelirleri 2025’te yüzde 15 organik büyümeyle 25 milyar Euro’ya ulaştı ve toplam cironun yüzde 62’sini oluşturdu. Düzeltilmiş EBITA marjı yüzde 18.7 seviyesine oturdu.
• ABB: Geleneksel güç şebekeleri birimini 2020’de elden çıkararak odağını yazılım, robotik ve elektrifikasyona çevirdi. Sevensense gibi yapay görme girişimlerini bünyesine katarak donanımı otonom mobil robotlara dönüştürdü. 2025 siparişleri 36.8 milyar dolara, operasyonel EBITA marjı yüzde 19’a ulaştı.
• Rockwell Automation: 2.2 milyar dolara satın aldığı Plex Systems ile bulut tabanlı ERP ve MES katmanını donanımının üzerine kurdu; toplam ARR büyümesini yüzde 8’e taşıdı.
• Emerson: AspenTech’in kalan yüzde 45’lik hissesini 7.2 milyar dolara alarak endüstriyel sensörlerden süreç optimizasyonu yazılımına geçişini tamamladı. Emerson bu satın alma için 2025 Düzeltilmiş FAVÖK’ünün 29 katını ödedi. Bir donanım üreticisinin yazılım varlığına ödediği bu çarpan, şirketin artık SaaS çarpanlarıyla değerlendiğini gösteriyor.
• Cisco: Splunk satın almasıyla ağ trafiği verilerini kurumsal güvenlik ve gözlemlenebilirlik platformuna dönüştürdü. Gelirlerinin yüzde 54’ü abonelik kaynaklı hale geldi ve toplam ARR 30 milyar dolara yaklaştı.
• Dell Technologies: 2025’te 100 milyar doları aşan gelirleriyle sadece sunucu satmıyor; Palantir ortaklığıyla kurum içi yapay zekâ işletim sistemi sunuyor. AI sunucu sipariş birikimi 43 milyar dolar düzeyindedir.

Kontrol Düzlemi: Yeni Nesil İşletim Sistemi

Bu şirketlerin inşa ettiği yapılar sıradan bulut panelleri veya masaüstü araçları değildir; teknik mimaride bu yapılara kontrol düzlemi adı verilir. Geleneksel işletim sistemleri deterministik süreçler etrafında tasarlanmıştı: doğrudan insan komutuna bağımlı ve basit sistem çağrılarıyla çalışan mekanizmalardı. Modern veri merkezleri ve akıllı fabrikalar ise statik kurallarla yönetilemeyecek kadar karmaşık bir hal almıştır.

Bu karmaşıklığı yönetmek için otonom ajan mimarileri devreye giriyor: sistemin uç parçaları (sunucular, CNC tezgâhları, ağ yönlendiricileri) kendi başlarına telemetri topluyor, durum değerlendirmesi yapıyor ve amaca yönelik yapay zekâ ajanları birbirleriyle haberleşerek aksiyon alıyor.

Somut bir senaryo: Siemens Xcelerator altındaki dijital ikiz altyapısı, üretim hattındaki PLC’nin anlık verisini okur, Altair algoritmalarıyla stres simülasyonunu yapar ve mekanik yorulma riski tespit ederse üretim planlama ajanına otomatik olarak parça değişimi iş emri gönderir. Bu statik bir kural otomasyonu değil; donanıma entegre edilmiş olasılıksal bir karar alma döngüsüdür.

AWS, Microsoft ve Google gibi saf bulut sağlayıcılarına karşı donanım üreticilerinin asimetrik avantajı tam olarak buradan gelir: uç noktanın fiziksel sahibi olmaları. Saf bulut şirketleri fabrikadaki sensörün kalibresini veya sunucu bileşeninin termal eşiğini doğrudan kontrol edemez. Donanım üreticileri ise verinin doğduğu ve kararın fiziksel harekete dönüştüğü altyapının sahibi olarak bu ajanları en düşük gecikmeyle çalıştırabilir.

Finans Piyasaları Neden Bu Dönüşümü Ödüllendiriyor?

Dönüşümün arkasındaki finansal mantık üç temel sütun üzerinde durur:

1. Tekrar Eden Gelirler (ARR): Donanım satışının tek seferlik nakit girişinin yerini, müşteri platformu kullandığı sürece her çeyrek tahsil edilen ARR alır. HPE’nin 3.2 milyar dolara çıkan ARR’si veya Cisco’nun 30 milyar dolarlık abonelik havuzu, makro kriz dönemlerinde nakit akışını güvenceye alır.
2. Gelecek Gelirlerin Teminat Altına Alınması: Sipariş birikimi ve kalan performans yükümlülükleri sayesinde şirketler gelecek yılların bilançolarını bugünden korumaya alır. Siemens’in 124 milyar Euro’luk, Dell’in 43 milyar dolarlık sipariş birikimi yatırımcılara geleceğin nakit akışının garanti altında olduğu mesajını verir.
3. Değerleme Çarpanlarının Ayrışması: Piyasalar saf donanım üreticilerini düşük fiyat/kazanç (P/E) çarpanlarıyla (10-15x) fiyatlarken, yazılım ve platform şirketlerine çok daha yüksek çarpanlar tanır. Gelirlerinin yarısından fazlasını aboneliklerden sağlayan şirketler (Schneider’ın yüzde 62’si, Cisco’nun yüzde 54’ü) donanım sınıfından çıkıp SaaS kategorisinde değerlenir.

Üretici Bağımlılığı: Değer Üreten Sadakat mi, Zorunluluk mu?

Bu platform stratejileri doğası gereği yüksek değiştirme maliyetleri yaratır. Ancak üretici bağımlılığı (vendor lock-in) tek başına olumsuz bir durum olarak değerlendirilemez. Apple kurumsal ve bireysel ekosisteminde bağımlılık yaratır. SAP kurumsal süreçlerde, Cisco ise ağ omurgasında benzer bir kilitlenme sağlar.

Buradaki kritik ayrım şudur: müşterinin elde ettiği değer, bu bağımlılığı rasyonel kılıyor mu? Xcelerator üzerinden tüm ürün yaşam döngüsünü yöneten bir sanayi tesisi bu altyapıdan gerçek bir operasyonel verim ve hız kazanıyorsa, değiştirme maliyeti bir engel değil, bilinçli bir operasyonel tercihtir. Buna karşın Broadcom’un VMware tarafında yaptığı gibi, mevcut kurulu tabanı fahiş fiyat artışlarıyla sıkıştırmak müşterinin mecburiyetini suistimal etmektir. Piyasa bu ayrıma hızla cevap verir: HPE’nin Morpheus VM Essentials hamlesi, tam olarak bu suistimale karşı doğan pazar tepkisinin ürünüdür.

Sonuç: Platform Satıyorlar

Donanım kapıyı açar, ancak geleceği platform dikte eder. Fiziksel bir cihaz sattığınızda, müşteriye dar bir kapasite teslim etmiş olursunuz. Cihazın ömrü bittiğinde yerine bir başka üreticinin donanımı konabilir. Ancak bu donanımın üzerine Xcelerator, GreenLake veya EcoStruxure gibi bir platform inşa ettiğinizde; tasarımı, yönetimi, orkestrasyonu, felaket kurtarmayı ve otonom kararları bu platform üzerinden yürüttüğünüzde müşterinin kurumsal iş yapış kültürüne kalıcı olarak yerleşmiş olursunuz.

Geleceğin kazananları yalnızca bulutta yaşayan saf yazılım firmaları olmayacaktır. Düşük kâr marjlı üretim bantlarına sıkışmış geleneksel donanım üreticileri de olmayacaktır. Kazananlar; fiziksel dünyanın donanım bariyerlerini kullanarak müşterinin operasyon merkezine sızan, ardından yapay zekâ destekli kontrol düzlemiyle müşteriyi kendi ekosistemine bağlayan platform şirketleri olacaktır.

Kaynaklar

Siemens Q2 FY 2026 Finansal Raporu ve Earnings Call Transkripti
Siemens ve Altair Satın Alma Bildirimi (SEC Kaydı, Kasım 2024)
HPE Q2 FY 2026 Finansal Sonuçları ve Basın Bülteni
HPE Morpheus VM Essentials Ürün Dokümantasyonu ve QuickSpecs
CRN: HPE CEO Antonio Neri, Morpheus VM Essentials Röportajı (Haziran 2026)
Schneider Electric FY 2025 Yıllık Sonuç Sunumu
ABB Q4 2025 ve Entegre Faaliyet Raporu 2025
Rockwell Automation FY 2025 Finansal Raporu
Emerson ve AspenTech Satın Alma Bildirimi ve SEC Kayıtları
Cisco FY 2025 Yıllık Raporu
Dell Technologies FY 2025/2026 Yatırımcı Sunumları
Venture Atlanta: “Top Startup Industries to Watch in 2026” (Donanım Destekli Yazılım Modelleri)

İlgili Bağlantılar

Siemens Xcelerator Endüstriyel Platform Portföyü
HPE GreenLake Uçtan Buluta Hibrit Kontrol Düzlemi
Broadcom VMware Lisans Değişiklikleri ve Sektörel Analiz

Son güncelleme: Ekim 2026 | Versiyon: 1.0

ContextRail, AI agent’ların bir yazılım projesinde uzun süreli, tutarlı ve denetlenebilir biçimde çalışabilmesi için tasarlanmış açık kaynak bir harness çerçevesidir. Agent yeni bir session başlattığında projenin neresinde kaldığını, aktif görevi, alınan kararları ve geçmiş denemeleri proje durumunu ve mimari kararları izlenebilir kılmak üzere 5 Markdown katmanı ve platform doğrulayıcılarıyla koordine eder.

Proje Künyesi

Çıkış Noktası ve İhtiyaç

Agentic coding araçları (Codex, Claude Code, Gemini, Cursor vb.) hızla güçleniyor. Fakat hepsinin ortak bir zayıf noktası var: proje hafızası.

Agent tek bir session içinde iyi çalışabilir. Ama session bittiğinde:

• Aktif görev kaybolur.
• Alınan kararlar unutulur.
• Sonraki session aynı keşfi yeniden yapar.
• Aynı hata tekrar yapılabilir.
• İnsanın her seferinde yeniden bağlam kurması gerekir.

Piyasada bunu çözmeye çalışan yaygın yaklaşım: devasa AGENTS.md dosyaları, yüzlerce küçük Markdown dosyası veya karmaşık planlama sistemleri. Bunların hepsinde aynı problem var: ya context’i şişiriyorlar ya da agent’ın neyi nerede bulacağını bilemediği bir karmaşıklık yaratıyorlar.

ContextRail’in hedefi farklı: Mümkün olan en az dosyayla, agent’ın nerede durduğunu, ne yapacağını ve neyi neden yaptığını bilmesini sağlamak.

Mimari Akış ve Yaşam Döngüsü

ContextRail bunu yaşam döngülerine göre ayrılmış 5 Markdown katmanıyla çözer:

• AGENTS.md: Agent nasıl çalışmalı?
• SYSTEM.md: Proje tanımı, sınırları ve mimari değişmezleri
• BOARD.md: Şu anda ne yapılacak?
• NOTES.md: Neden böyle yapılacak?
• HISTORY.md: Daha önce ne yapıldı, nasıl doğrulandı?

Bu 5 katmanın üstüne üç platformda çalışan native validator script’leri (Bash, PowerShell, GitHub Actions) eklenir. Framework, SDK veya kütüphane bağımlılığı yoktur; herhangi bir repoya doğrudan kopyalanabilir.

Kapsam ve Sınırlar

ContextRail şunları yapar:

• Agent’a session başlangıcında net bir giriş noktası verir.
• Aktif iş, karar gerekçesi ve geçmiş uygulamayı farklı lifecycle katmanlarına ayırır.
• Agent’ı broad scan yerine hedefli bilgi erişimine yönlendirir.
• Benzersiz ID’lerle karar ve görevleri adreslenebilir hale getirir.
• Dış kaynaklardan gelen spesifikasyon, değerlendirme ve planları yapılandırılmış handoff süreci ile alır.
• Kodda görev bağlantılı kod izleme yorumları ile karar-kod ilişkisini sürdürür.
• Metadata sözleşmesini üç işletim sisteminde mekanik olarak doğrular.
• Projenin mevcut test/build/lint zincirine entegre olarak tek bir ana doğrulama komutu oluşturur.
• Farklı agent platformlarıyla uyumlu çalışır (Codex, Claude Code, Gemini, Cursor, Copilot).

ContextRail şunları yapmaz:

• Yeni bir programlama dili veya framework dayatmaz.
• SDK veya kütüphane yüklemez.
• Kendi test framework’ünü kurmaz; mevcut proje altyapısına bağlanır.
• Semantic search, embedding veya graph database gerektirmez.
• Proje yönetimi aracı, planlama derleyicisi veya multi-agent orchestration platformu değildir.
• Agent’ın kendi planner’ını devre dışı bırakmaz.

Çözüm Mimarisi

Lifecycle Ayrımı

Bilgi dosya sayısına göre değil, yaşam döngüsüne göre ayrılır:

• AGENTS.md → Çalışma kuralları ve navigation haritası
• SYSTEM.md → Proje tanımı, bileşenler, sınırlar ve mimari değişmezler
• BOARD.md → Aktif görevler ve mevcut durum
• NOTES.md → Karar gerekçeleri, teknik kısıtlamalar, kalıcı ürün hafızası
• HISTORY.md → Tamamlanmış görevler ve doğrulama kanıtları

Agent, BOARD.md dosyasından aktif görevi bulur. Görevdeki karar kimliğiyle NOTES.md dosyasında yalnızca ilgili bölümü açar. HISTORY.md dosyasına ancak geçmiş bir uygulamayı doğrulaması gerekirse gider.

External Handoff Mekanizması

Dış kaynaklardan gelen ham spesifikasyonlar, değerlendirmeler ve planlar handoffs/incoming/ dizinine bırakılır. Agent, handoffs/HANDOFF.md dosyasındaki süreci izler: önce mevcut ID’lerde arama yapar, kalıcı anlamı Notes’a aktarır, bağımsız olarak doğrulanabilir Board görevleri türetir, çakışmaları raporlar, sonucu doğrular ve ancak o zaman kaynak paketi taşır veya kaldırır.

Görev Bağlantılı Kod İzlemesi

Kalıcı davranış sınırları kodda kısa bir native yorum ile işaretlenir:

ContextRail: TASK-0042
Invariant: Persistent mutation requires explicit authorization.

Görev, gerekçe ve ilişkilerin tamamını taşır. Kod yorumu yalnızca mevcut davranışı en iyi açıklayan görevi tanımlar; tüm tarihsel düzenlemeleri listelemez. Aynı işaret, görev test edilebilir çalışma zamanı davranışı oluşturuyorsa ilgili regresyon testine de eklenir.

Agent Uyumluluk Katmanı

Farklı platformların kendi konfigürasyon dosyaları desteklenir:

• CLAUDE.md → Claude Code
• GEMINI.md → Gemini
• .github/copilot-instructions.md → GitHub Copilot
• .cursor/rules/00-agents.mdc → Cursor

Hepsi aynı şeyi söyler: “Önce kökteki AGENTS.md dosyasını oku ve uygula.” Kural kopyalamaz, yönlendirir.

Cross-Platform Validator’lar

scripts/
  validate-linux.sh
  validate-macos.sh
  validate-windows.ps1

Validator’lar projenin dilinden bağımsız çalışır. Python, Node.js, Go veya herhangi bir proje runtime’ı gerektirmez. Yalnızca Markdown metadata sözleşmesini kontrol eder:

• Zorunlu dosya ve SYSTEM.md bölümleri mevcut mu?
• System dosyasına yanlışlıkla lifecycle kaydı yazılmış mı?
• Aynı ID iki defa kullanılmış mı?
• Aynı normalize edilmiş kayıt başlığı farklı kimliklerle tekrar edilmiş mi?
• Aynı stabil kimliğin başlığı tutarsız mı?
• Board’da geçersiz status var mı?
• Board, Notes ve History kayıtlarında zorunlu alanlar eksik mi?
• Tamamlanan veya iptal edilen görevde tarih eksik mi?
• Tamamlanan görevde evidence veya outcome eksik mi?
• Board ve History’de aynı görev aynı anda var mı?
• Orphan görev detayı var mı?
• Related, Supersedes ve Replacement referansları kırık mı?
• Kabul edilmiş kararlar mevcut sistem doğrusuna yansıtılmış mı?
• Koddaki task-linked yorumlar mevcut olmayan lifecycle veya Notes kaydına mı işaret ediyor?
• Task-linked yorumların yanında boş olmayan invariant açıklaması var mı?
• System haritası sınırlı boyutu aşmış mı?

Agent “işi tamamladım” dediğinde validator bunu mekanik olarak doğrular.

İki Repo, İki Dağıtım Kanalı, Tek Bakım Noktası

• minimum-governed-harness geliştirme, dokümantasyon ve release deposudur.
• contextrail-template kullanıcıya yönelik temiz template repository’dir.

Yeni projeler doğrudan template repository’den, mevcut projeler ise GitHub Release sayfasından versiyonlanmış ZIP ile kurulabilir. Her release’de ZIP checksum ve manifest dosyaları da yayımlanır.

Geliştirme Süreci ve Governance Kuralları

ContextRail yalnızca dosya yapısı değil, agent’ın çalışma disiplinini de tanımlar:

• External Handoff Adoption: Dış kaynaklardan gelen paketler yapılandırılmış süreçle alınır; duplikasyon kontrolü yapılır, çakışmalar raporlanır.
• Task-Linked Code Trace: Kalıcı davranış sınırları kodda ve ilgili regresyon testinde görev kimliğiyle işaretlenir.
• Root Cause Before Patch: Agent, ihlal edilen invariant veya durum geçişini tespit etmeden yama eklemez. Testler bir davranış sınıfını kanıtlar.
• Independent Review: Agent kendi diff’ini bağımsız reviewer gibi inceler. Tamamlama iddiaları nesnel çıktıya dayandırılır.
• Controlled Incidental Findings: Görev sırasında görülen ilgisiz hatalar kanıtla raporlanır, sessizce düzeltilmez.
• Ana Doğrulama Entegrasyonu: Agent, ilk önemli kullanımda projenin mevcut test, build ve lint zincirini keşfeder ve validator’ı bu zincire entegre eder.
• Governed Delegation: Agent, sınırlı ve düşük riskli işleri alt agent’lara devredebilir; mimari kararlar ve hafıza güncellemeleri ana agent’ta kalır.
• Version Awareness & User-Owned Instructions: .contextrail-version ve kullanıcıya ait talimat bloğu güncellemelerde korunur.
• Reuse-First Engineering: Özel altyapı varsayılan başlangıç değildir; ekosistemdeki mevcut çözümler değerlendirilir.

Mevcut Durum ve Açık Kaynak Dağıtımı

Proje açık kaynak ve stabil sözleşme altındadır:

• Ana Repo: github.com/muisik/minimum-governed-harness — Açık kaynak, MIT lisanslı
• Template Repo: github.com/muisik/contextrail-template — GitHub Template Repository
• Sürümler: GitHub Releases üzerinden checksum ve manifest ile indirilebilir ZIP paketleri
• Platform Uyumluluğu: Codex, Claude Code, Gemini, Cursor, GitHub Copilot

İlgili Bağlantılar

Teknik Analiz: Agent’a Her Şeyi Anlatma, Nereye Bakacağını Öğret
Ana Repo: github.com/muisik/minimum-governed-harness
Template Repo: github.com/muisik/contextrail-template

Kod yazmak ucuzluyor. Bir fonksiyonun ilk taslağını çıkarmak, API endpoint açmak, test iskeleti üretmek artık eskisine göre çok daha az insan emeği istiyor. Fakat maliyet ortadan kalkmıyor; başka yere taşınıyor. Agent neyi değiştirmeliydi? Hangi karar hâlâ geçerli? Bu görev neden açılmıştı? Eski uygulama kasıtlı mı, tesadüf mü? Yeni kod başka bir modülü sessizce bozdu mu? Bir sonraki session aynı işi yeniden mi keşfedecek? Kod üretim maliyeti düşerken context kurma, doğrulama ve review maliyeti büyüyor. Harness’in değeri ne kadar büyük olduğuyla değil, agent’ın doğru bilgiye ne kadar az sürtünmeyle ulaşabildiğiyle ölçülür. Birçok projede bunun için devasa ve karmaşık bilgi altyapıları kurmak yerine; yaşam döngüsüne göre doğru tanımlanmış odaklı Markdown katmanları asgari etkili çekirdeği (minimum viable harness) sağlamak için yeterlidir.

Harness Nedir, Ne Değildir?

Harness engineering’i yalnızca bir AGENTS.md veya CLAUDE.md yazmak olarak görmek eksik kalır.

Harness, agent’ın içinde çalıştığı mühendislik düzenidir: hangi bilgilerle başlayacağı, hangi görev sınırını aşamayacağı, sonuçlarını nasıl doğrulayacağı ve ne zaman insana döneceği.

İyi harness, modelin daha zeki olmasını beklemez. Modelin hataya gidebileceği yolları daraltır ve doğru davranışı mekanik olarak kolaylaştırır.

OpenAI kendi harness engineering deneyiminde de aynı sonuca varmış. Ekip, başta tek bir büyük AGENTS.md dosyası kullanmış. Context’i doldurması, kuralları eşit derecede “önemli” hale getirmesi ve hızla eskimesi nedeniyle bu yaklaşımdan vazgeçmiş. Sonuçta kısa bir AGENTS.md dosyasını ansiklopedi değil, içindekiler tablosu gibi kullanmışlar; ayrıntıları indekslenmiş dokümanlarla ihtiyaç halinde açmışlar.

Önemli ayrım burası:

Harness daha fazla talimat yazmak değildir. Doğru davranışa giden yolları tasarlamaktır.

“Ne Kadar Modüler, O Kadar İyi” Yanılgısı

Monolitik dokümanın sorunları gerçek. Yüzlerce kararın tek dosyada bulunması session başlangıcını pahalı hale getirir, güncel ve eski bilgiyi karıştırır, agent’ın kritik talimatları atlamasına neden olabilir.

Fakat buradan “her konu ayrı dosya olmalı” sonucuna atlamak da doğru değil.

Her küçük karar için ayrı dosya oluşturulduğunda başka bir maliyet çıkar:

• Agent önce doğru dosyanın adını bulmalıdır.
• Aynı bilgi birden fazla dosyada tekrar edebilir.
• Linkler ve indeksler güncel tutulmalıdır.
• Hangisinin ana kaynak olduğu belirsizleşebilir.
• Eski veya unutulmuş kayıtlar sahipsiz (orphan) hale gelebilir.

Yazılım mühendisliği saha pratikleri, bu tür dağınık ve yaşam döngüsünden kopuk dokümantasyonların birkaç ay içinde hızla güncelliğini yitirip atıl kaldığını gösteriyor. Dosya sayısını artırmak, erişim mimarisi kurmak değildir.

Dosya modülerliği ile bilgi modülerliği aynı şey değildir.

Bir kaydın ayrı dosyada bulunması şart değildir. Kayıt mantıksal olarak sınırlandırılmış, benzersiz kimlikle adreslenmiş, küçük bir aralık halinde okunabilir ve başka kayıtlardan açıkça ayrılmışsa tek başına erişilebilir bir bilgi birimidir — hangi dosyada olursa olsun.

Grep vs LSP Tartışmasının Aslı

Piyasada sıkça yapılan hata: LSP ile grep’i rakip olarak konumlandırmak.

LSP kaynak kodda sembol ve referans arar. Fonksiyonun nerede çağrıldığını, sınıfın nerede tanımlandığını, bir arayüzün implementation’larını bulur. Bunun için tasarlanmıştır.

Fakat Markdown içindeki karar gerekçeleri, ürün sınırları, config açıklamaları ve DEC-ARCH-021 gibi serbest metin kimlikleri kaynak kodun symbol graph’ının parçası değildir. Bunlar için grep veya rg kullanılır. Mesele birini seçmek değil; ikisini doğru yerde kullanmak. Mesele aracı veya jargonu değil, amacı anlamak.

Birkaç Markdown dosyasında benzersiz bir ID ile hedefli arama yaptırmanın pratik maliyeti ihmal edilebilir düzeydedir. rg -F "DEC-ARCH-021" docs/ komutu milisaniyeler içinde sonuç verir ve modele yalnızca eşleşen satırları aktarır. Bütün dosya context’e girmez.

Gerçek maliyeti belirleyen üç farklı kavramı ayırmak lazım:

Navigation maliyeti asıl risktir. Agent genel bir kelimeyle arama yaparsa onlarca sonuç döner. DEC-ARCH-021 gibi benzersiz bir kimlikle ararsa çoğu durumda doğrudan tek kayda ulaşır.

Benzersiz kimliklerin asıl faydası disk hızında değil, navigation belirsizliğini azaltmasındadır.

Lifecycle Ayrımı: Ne, Neden, Ne Zaman?

Peki bilgi nasıl organize edilmeli?

Kendi projelerimde doğal olarak ortaya çıkan bir desen var. Harness’i dev bir talimat dosyası olarak değil, birkaç dosyanın yaşam döngüsüne göre ayrılmış hali olarak kurdum:

SYSTEM.md  → Sistem ne yapar, mimari sınırları nelerdir?
AGENTS.md  → Nasıl çalışmalıyım?
BOARD.md   → Şu anda ne yapmalıyım?
NOTES.md   → Neden böyle yapmalıyım?
HISTORY.md → Daha önce ne yapıldı, nasıl doğrulandı?

Bunları birbirine bağlayan şey de basit:

Aktif görev → İlgili karar kimliği → Hedefli arama → Küçük bölüm okuma → Uygulama → Test → Kayıt güncellemesi

Agent yeni bir session başlattığında bütün repoyu taramıyor. Board’dan aktif görevi buluyor. Görevdeki karar kimliğiyle Notes’ta yalnızca ilgili bölümü açıyor. History’ye ancak eski bir uygulamayı doğrulaması gerekirse gidiyor.

Bu “birkaç büyük dosya” yaklaşımı mı? Hayır. Dosya sayısı görünen yüz. Asıl mimari şunlardan oluşuyor:

1. Lifecycle partitioning: Aktif iş, karar gerekçesi, tamamlanmış kanıt ve çalışma kuralları ayrılıyor.
2. Authority routing: Hangi konuda hangi dosyanın otorite olduğu tanımlı.
3. Addressable records: Benzersiz kimlikler kullanılıyor.
4. Progressive disclosure: Bütün dokümanlar başlangıçta context’e yüklenmiyor.
5. Targeted retrieval: ID araması ve küçük satır aralıkları okunuyor.
6. Scope gating: Agent tek aktif işin sınırları dışına çıkmıyor.

Aynı desen üç ana dosyada da, konu bazlı on dosyada da, yüzlerce ADR dosyasında da uygulanabilir. Kritik olan dosya sayısı değil, adresleme ve yönlendirme modelidir.

Piyasa Aynı Yöne Gidiyor

Bu yaklaşım teorik bir öneri değil. Piyasanın gittiği yön aynı:

• OpenAI, kısa AGENTS.md + indekslenmiş dokümanlar + execution plan kullanıyor. Büyük talimat dosyasından vazgeçmiş durumdalar.
• Anthropic, CLAUDE.md dosyalarının kısa ve spesifik olmasını, skill ve referansların yalnızca gerektiğinde yüklenmesini öneriyor.
• Codex, dizin hiyerarşisinde birden fazla AGENTS.md kullanarak path-scoped yönlendirme kuruyor.

Ortak nokta açık:

Agent’a daha fazla bilgi yüklemiyorlar. Bilgiyi hangi aşamada, hangi araçla göreceğini tasarlıyorlar.

2026’da yayımlanan bir araştırma bu resmi daha da netleştiriyor. 138 gerçek görev üzerinde yapılan çalışmada, repo context dosyaları genel olarak görev başarı oranını anlamlı biçimde artırmamış; maliyeti ise ortalama yüzde 20’den fazla yükseltmiş. Araştırmacılar, context dosyalarının yalnızca agent’ın başka türlü bilemeyeceği minimal ve gerekli kuralları içermesini öneriyor.

Bu çalışma benim sistemimi doğrudan test etmiyor. Fakat neden şişkin harness kurmamak gerektiğini güçlü biçimde doğruluyor.

Dosya Ne Zaman Bölünmeli?

Basit bir karar ağacı:

• Bilgi farklı bir hızda mı değişiyor? Aktif görev listesi her gün değişir, mimari kararlar yılda bir. Evet → böl.
• Bilgi farklı bir ekibin yetkisinde mi? Evet → böl.
• Bilgi nadiren mi okunuyor ve çok mu uzun? Evet → ayrı dosyaya al, ID ile haritalandır.
• İki bölüm neredeyse her görevde birlikte mi okunuyor? Evet → ayırma.
• Bölmek yeni bir source of truth doğuracak mı? Evet → ayırma. Bir dosya ana kaynak, diğeri yalnızca link olmalı.

Fayda belirgin biçimde maliyeti geçmiyorsa aynı dosyada, ayrı ID’li bölüm olarak bırak.

Ne Yapmalı?

Bu yaklaşımı deneyimlemek isteyenler için minimum etkili çekirdek şundan ibaret:

1. Her dosyanın tek ve açık bir rolü olsun.
2. Board’dan karar kaydına çift yönlü ID bağlantısı kurulsun.
3. Session başlangıcında genel bir tarama yerine aktif görev araması yapılsın.
4. Notes ve History yalnızca hedefli aramayla açılsın.
5. Her turda tek görevlik küçük uygulama dilimi yapılsın.
6. Test ve doğrulamadan sonra lifecycle kaydı güncellensin.

Bu yaklaşımı açık kaynak bir çerçeve olarak uyguladım: ContextRail. Birkaç Markdown dosyası, üç platform validator’ı ve sade bir lifecycle sözleşmesinden ibaret. Şişkin değil, doğrudan kullanılabilir.

Sonuç

Agent’a daha fazla doküman vermek ile agent’ın doğru dokümana ulaşmasını sağlamak aynı şey değildir.

Bir repoyu yüzlerce Markdown dosyasına bölmek erişim mimarisi kurmak değildir. Tek bir büyük talimat dosyasını modele vermek de kurumsal hafıza oluşturmak değildir.

İyi harness, agent’ın her şeyi bilmesini istemez.

Agent’ın bilmediği şey her zaman bilgi değildir. Bazen nereye bakacağını bilmiyordur.

Harness’i şişirmek agent’ı güçlendirmeyebilir. Bazen yalnızca daha fazla şey okumasına neden olur.

Basit harness ile ilkel harness aynı şey değildir.

Kaynaklar

1. OpenAI, “Harness Engineering: Leveraging Codex in an Agent-First World,” 2026. openai.com
2. Gloaguen vd., “Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?”, arXiv:2602.11988, 2026. arxiv.org (Ayrıca bkz. Lulla, Baltes vd., arXiv:2601.20404)
3. Anthropic, “How Claude remembers your project,” Claude Code Docs. docs.anthropic.com
4. OpenAI Developers, “Custom instructions with AGENTS.md,” Codex Docs. developers.openai.com
5. Michael Nygard, “Documenting Architecture Decisions,” Cognitect, 2011. cognitect.com
6. Liu vd., “Lost in the Middle: How Language Models Use Long Contexts,” arXiv:2307.03172, 2023. arxiv.org

İlgili Bağlantılar

Proje Kartı: ContextRail: Agentic Coding İçin Minimum Etkili Proje Hafızası
Agentic Mikroyönetim Hakkındaki Önceki Yazı: LLM’lerle Dans Etmenin Kuralı: Agentic Mikroyönetim

Son güncelleme: Ekim 2026 | Versiyon: 1.0

Video to Slide, YouTube ders videolarından, oynatma listelerinden veya bilgisayardaki video dosyalarından slaytları otomatik olarak yakalayan, eğitmenin tahta kalemi izlerini filtreleyerek ilk temiz kareleri PNG, PDF ve slayt sıralı PowerPoint (.pptx) sunumlarına dönüştüren açık kaynaklı bir masaüstü uygulamasıdır. Videoyu durdurup tek tek ekran görüntüsü alma zahmetini ortadan kaldırarak ders çalışanlar ve araştırmacılar için düzenli dijital dokümanlar üretir.

Proje Künyesi

Çıkış Noktası ve İhtiyaç

İnternet üzerindeki veya arşivdeki video derslerden not çıkarırken karşılaşılan en yaygın zorluk, slaytların tek tek elle kaydedilmesidir. Video sürekli durdurulur, ekran alıntısı yapılır ve bir dokümana yapıştırılır.

Bu zahmetin ötesinde daha büyük bir pratik sorun vardır: Eğitmen slayt açılır açılmaz üzerine dijital kalemle veya tahta kalemiyle notlar almaya başlar. Standart sahne değişimi yakalayıcıları videonun o sahnedeki son halini yakaladığı için elde edilen görseller çiziklerle ve okunaksız karalamalarla dolar.

Video to Slide bu ihtiyacı doğrudan çözmek üzere geliştirildi:

• Video bağlantısını veya yerel dosyasını verip süreci tek tuşla başlatmak,
• Eğitmenin yazı yazmaya başlamasından önceki ilk temiz slayt karesini otomatik yakalamak,
• Karşılaştırmada tahta kalemi darbelerini filtreleyip slayt geçişini doğru tespit etmek,
• Çıktıyı doğrudan PDF ve slayt görsellerinin yerleştiği PowerPoint (.pptx) sunumu olarak teslim etmek.

Çözüm Yaklaşımı ve Algoritmik Mantık

Araç, videoyu kare kare tararken iki kritik görüntü işleme mantığı işletir:

İlk Temiz Karenin Tespiti

Bir sunumda slayt değiştiğinde ekran bir anlığına sabitlenir; hemen ardından eğitmenin el veya kalem hareketi başlar. Algoritma slayt değişimini yakaladıktan sonra, hareket eşiğinin henüz aşılmadığı ilk kararlı kareyi hafızaya alır. Böylece eğitmenin sonradan eklediği el yazıları sunum görselini bozmaz.

Tahta Kalemi İzlerinin Filtrelenmesi

Eğitmenin renkli tahta kalemleriyle çizdiği çizgiler hareket analizini yanıltabilir. Karşılaştırma döngüsünde bu renkli çizgiler filtrelenerek slayt geçişi ile yerel çizimler birbirinden ayrılır; orijinal karenin kalitesine dokunulmadan doğru slayt sınırları belirlenir.

Temel Yetenekler ve Çıktı Biçimleri

• Çoklu Kaynak Desteği: Tekil YouTube bağlantıları, tam oynatma listeleri, yerel .mp4, .mkv, .mov, .webm dosyaları veya bir klasördeki tüm videolar topluca işlenebilir.
• Seçilebilir Çıktı Biçimleri:
• Yüksek çözünürlüklü tekil PNG slayt görselleri,
• Tek dosyada birleştirilmiş PDF ders notu,
• Slayt karelerinin tam sayfa yerleştiği PowerPoint (.pptx) sunumu (metinler görsel katman olarak aktarılır).
• Çift Dilli Arayüz: Tek tıkla Türkçe ve İngilizce dil seçimi arasında geçiş yapılabilir.
• Önizleme ve Ayar Denetimi: Eşik değerleri, kırpma payları ve kalite ayarları arayüzden kolayca özelleştirilebilir.

Çapraz Platform ve Dağıtım

Video to Slide, karmaşık bağımlılıklar veya Python kurulumu gerektirmeden çalışabilecek şekilde paketlenmiştir:

• Windows, Linux ve macOS üzerinde doğrudan çalıştırılabilir taşınabilir sürümler sunar.
• Arayüz masaüstü odaklı, sade ve hızlı tepki verecek şekilde kurgulanmıştır.
• Harici bir bulut servisine veya API anahtarına ihtiyaç duymadan tüm işlemi yerel işlemci üzerinde tamamlar.

Mevcut Durum ve Açık Kaynak

Video to Slide açık kaynaklı olarak geliştirilmekte ve MIT lisansı altında dağıtılmaktadır. Kod tabanı, ekran görüntüleri ve derlenmiş hazır sürümler GitHub deposunda yer almaktadır.

İlgili Bağlantılar

LinkedIn Paylaşımı: Video to Slide: Açık Kaynak Otomatik Slayt Çıkarma Aracı
GitHub Deposu: github.com/muisik/video-to-slide
İlgili Proje: Tender Tracker: Yerel Kamu İhale Takip ve Sınıflandırma Aracı
İlgili Proje: ContextRail: Minimum Etkili Proje Hafızası

Bir ürünün üzerinde IP65 yazması, o donanımın sahada karşılaşılabilecek her türlü çevresel etkene dayanacağı anlamına gelmez. Standart testler su ve toza odaklanırken; endüstriyel yağlar, kesme sıvıları ve hareketli miller sızdırmazlık dinamiğini tamamen değiştirir. Sahada sızdırmazlık hatasıyla karşılaşıldığında koruma sınıfını suçlamadan önce, maruziyetin kimyasal ve mekanik gerçeklerini doğru okumak gerekir.

Standart Test Şartları ve Kapsam Dışı Riskler

Standart bir IP65 sertifikası, donanımın sahada karşılaşabileceği her kimyasal veya mekanik etkiye karşı korunduğunu garanti etmez. Örneğin bir gövdenin su sıçramasına direnmesi, endüstriyel yağ sızıntılarına karşı sızdırmaz olduğu anlamına gelmez.

IP koruma sınıfı bize ürünün toz ve suya karşı hangi test koşullarında koruma sağladığını söyler. Ancak bu değer tek başına ürünün:

• Sürekli yağ içinde çalışabileceğini,
• Kesme sıvısına ve soğutma kimyasallarına dayanacağını,
• Basınçlı yıkamadan etkilenmeyeceğini,
• Hareketli bir mil veya çubuk üzerinden kılcal sıvı yürümeyeceğini,
• Kullanılan kimyasalla conta malzemesinin uyumlu olduğunu elbette söylemez.

Statik Gövde ile Dinamik Mekanik Yüzeylerin Farkı

Özellikle hareketli mekanik yüzeylerde iş daha da karmaşıklaşır. Sabit bir gövdeden su geçirmemek başka bir şeydir; sürekli ileri geri hareket eden bir mil üzerinde yağ filminin taşınmasını engellemek bambaşka bir şeydir.

Sahada Sıvı Girişi Olduğunda Doğru Soruları Sormak

Bu yüzden sahada “ürün IP65 ama içine sıvı girmiş” dediğimizde “IP65 neden çalışmadı?” diye sormadan önce şu sorulara bakmak gerekir:

• Ürün sahada gerçekten hangi sıvıya maruz kaldı?
• Maruziyet sürekli mi, aralıklı mı?
• Sistemde bölgesel basınç artışı veya yıkama basıncı var mı?
• Ürünün montaj yönü ve drenaj kanalları nasıl konumlandırıldı?
• Sıvı doğrudan hareketli yüzeye veya mil keçesine ulaşıyor mu?
• Conta ve gövde malzemesi proses kimyasalına uygun mu?

Çünkü koruma sınıfı yalnızca tanımlı laboratuvar parametrelerini gösterir. Suya ve toza karşı test edilmiş bir cihazın endüstriyel yağlara, agresif solventlere veya dinamik şaft sürtünmesine aynı direnci göstermesi beklenemez.

Datasheet ürünün sınırını söylüyor ama mühendislik gerçek çalışma koşulunu anlamakla başlıyor.

Kaynaklar

Flitney, R. (2014). Seals and Sealing Handbook (6th ed.). Butterworth-Heinemann.
International Electrotechnical Commission. (2013). Degrees of protection provided by enclosures (IP Code) (IEC Standard No. 60529:1989+AMD1:1999+AMD2:2013 CSV). IEC.

İlgili Bağlantılar

Ölçüm ve Test Kararlılığı: Ürün mü Hatalı, Ölçüm Sistemi mi?
Donanım ve Servis Mimarisi: IT/OT Bariyerini Aşmanın Donanım Mimarisi: Makine İmalatçıları İçin Güvenli Uzaktan Servis
Operasyon ve Diagnostik: Tüketici Elektroniği ve Giyilebilir Ekosistem İçin Servis ve Diagnostik Operasyon Mimarisi

Bir şirkette en büyük risk hata yapanlar değil, bariz bir hatayı gördüğü halde konfor uğruna susanlardır. İtiraz edebilme ve yanlış kararları sorgulayabilme refleksi hoş bir kurumsal kültür detayı değil, organizasyonun duvara çarpmasını engelleyen hayati bir kontrol mekanizmasıdır. Yönetimin yanılma payını dengeleyecek açık bir iletişim zemini kurulmadığında, ortak akıl yerini kolektif bir körlüğe bırakır.

Ortak Akıl ile Yanılma Payı Arasındaki Fark

Bir organizasyonda en kritik operasyonel risk, hata yapılması değil; bariz bir hatanın fark edildiği halde kurumsal çekincelerle dile getirilmemesidir.

Bir yönetici yanlış bir karar alabilir. Bu son derece normaldir. Yöneticilik, her şeyi bilmek veya her zaman haklı olmak değildir. Asıl tehlike, odadaki herkes yanlış olduğunu düşündüğü bir karara yalnızca yönetici söyledi diye başını salladığında başlar.

Çünkü o noktadan sonra şirket artık insanların ortak aklıyla değil, organizasyon şemasındaki en yüksek makamın yanılma payıyla yönetilmeye başlanır.

Hata Yapma Hakkı ve Sorun Bildirme Sorumluluğu

Benimle tartışıp beni hatadan döndüren bir çalışma arkadaşını, söylediğim her şeye “evet” deyip yanlış kararımı uygulayan birine her zaman tercih ederim.

Hatta bana göre çalışanların yalnızca konuşma hakkı değil, gördükleri ciddi bir problemi dile getirme sorumluluğu da vardır.

Bir hata yaptıysanız neden olduğunu inceler, sistemi düzeltir ve devam edersiniz. Ancak bir problem öngörüldüğü halde psikolojik güvenlik eksikliği veya kurumsal sürtünme endişesiyle sessiz kalınıyorsa, organizasyonun erken uyarı mekanizmaları devre dışı kalır. Bu durum bireysel hatanın ötesinde, sistemik bir kurumsal körleşme riski yaratır.

Uyumsuzluk ile Kontrol Mekanizması Arasındaki İllüzyon

Ne yazık ki birçok şirket tam tersini ödüllendiriyor. İtiraz eden “zor insan” oluyor. Sorgulayan “uyumsuz” oluyor. Sessiz kalan ise “sorunsuz çalışan” olarak görülüyor.

Sonra yanlış kararlar aylarca uygulanıyor ve herkes sonucu gördükten sonra “Ben zaten böyle olacağını düşünmüştüm” demek için sıraya giriyor. Araba devrilince yol gösteren çok olur demişler. O zaman neden söylemedin?

Bir organizasyonda insanların yanlış gördükleri şeyleri rahatça söyleyebilmeleri güzel bir kültür özelliği değildir. Bir kontrol mekanizmasıdır. Çünkü iyi yönetim, yöneticinin hiç hata yapmamasını sağlamaz. Hata yaptığında organizasyonun onu durdurabilmesini sağlar.

Kaynaklar

Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350–383.
Morrison, E. W., & Milliken, F. J. (2000). Organizational Silence: A Barrier to Change and Development in a Pluralistic World. Academy of Management Review, 25(4), 706–725.
Reason, J. (2000). Human Error: Models and Management. BMJ, 320(7237), 768–770.

İlgili Bağlantılar

LinkedIn Paylaşımı: Organizasyonlarda Sessizlik Kültürü ve Kontrol Mekanizmaları
Ölçüm ve Test Kararlılığı: Ürün mü Hatalı, Ölçüm Sistemi mi?
Donanım ve Servis Mimarisi: IT/OT Bariyerini Aşacak Donanım Mimarisi: Makine İmalatçıları İçin Güvenli Uzaktan Servis
Operasyon ve Bilgi Mimarisi: Satış Sonrası Hizmetlerde Teknik Bilgi Yönetimi ve L1/L2 Destek Mimarisi

Bir yapay zeka modelinin gerçek maliyetini yalnızca token başına ödenen fiyata bakarak değerlendirmek yanıltıcıdır. Doğru sonuca ulaşmak için gereken deneme sayısı, hata düzeltme süreçleri ve insan denetimi hesaba katıldığında, nominal olarak ucuz görünen bir model pahalı bir alternatife kıyasla kat kat yüksek bir toplam operasyonel maliyet yaratabilir.

Nominal Token Fiyatı ve Başarılı İşlem Başına Maliyet

Bir AI modelinin ucuz olup olmadığını yalnızca token fiyatına bakarak anlayamayız.

Model A bir işi 1 dolara yapıyor ama doğru sonucu almak için üç kere çalıştırmanız, promptu düzeltmeniz, çıktıyı kontrol etmeniz ve sonunda başka bir modele doğrulatmanız gerekiyorsa, bu gerçekten 1 dolarlık bir model midir? Model B aynı işi 2 dolara tek seferde bitiriyorsa hangisi daha ucuzdur?

Not: Aşağıdaki karşılaştırma kavramsal ve temsili bir senaryodur; asıl kıyas ölçütü salt token tarifesi değil, doğrulama, gecikme ve yeniden işlem adımlarını kapsayan uçtan uca operasyonel maliyettir.

Ölçülecek asıl metrik “başarılı işlem başına maliyet” olmalıdır. Kurumsal kullanımda ise bunun da ötesine geçmek gerekir. Yanlış çıktının fark edilmemesi, insan kontrol süresi, yeniden çalışma, model değiştirme, API çağrıları, gecikme ve operasyonel karmaşıklık da toplam maliyetin doğrudan bir parçasıdır. Bu yüzden, ucuz model her zaman ucuz çözüm anlamına gelmez.

Agent Zincirlerinde Güvenilirlik Farkı

Özellikle agent ve otomasyon sistemlerinde küçük bir güvenilirlik farkı, zincirin her adımında tekrarlandığında toplam maliyeti ciddi şekilde değiştirebilir.

Birbirine bağlı çok adımlı bir iş akışında ilk adımda yaşanan bir sapma, sonraki tüm adımlarda katlanarak büyüyen bir hata maliyetine dönüşür. Tek bir hatalı çıkarım, sistemi yeniden başlatmaya veya ek düzeltme katmanları kurmaya zorlayarak başlangıçtaki fiyat avantajını tamamen yok eder.

Model Kalitesi ile Veri Kalitesi Ayrımı

AI modellerini değerlendirirken “1 milyon token kaç dolar?” sorusunun yanına “Bu model bana işi kaç denemede tamamlatıyor?” sorusunu koymak gerekir. Ancak bu değerlendirmeyi yaparken model kalitesiyle veri kalitesini birbirine karıştırmamak da kritik bir eşiktir.

Kötü veriyle iyi bir modeli, iyi veriyle kötü bir modeli kıyasladığınız anda maliyet hesabının terazisi bozulur. Doğru birim maliyet hesabı, ancak tutarlı ve temiz bir veri tabanı üzerinde, modelin tek seferde doğru sonuca ulaşma başarısı ölçüldüğünde elde edilir.

Kaynaklar

Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. de O., Kaplan, J., … & Zaremba, W. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374.
Madaan, A., Tandon, N., Gupta, P., Hallinan, S., Gao, L., Wiegreffe, S., … & Clark, P. (2023). Self-refine: Iterative refinement with self-feedback. Advances in Neural Information Processing Systems, 36, 46534-46594.

İlgili Bağlantılar

LinkedIn Paylaşımı: Ucuz LLM İllüzyonu: Başarılı İşlem Başına Maliyet
Yapay Zeka Mimarisi: Agent’a Her Şeyi Anlatma, Nereye Bakacağını Öğret
Proje Hafızası: ContextRail: Agentic Coding İçin Minimum Etkili Proje Hafızası
LLM Dinamikleri: LLM Modellerinde Kısa Devre: AI Neden Bize “Yalan” Söylüyor?

Fiziksel sensörler bağımsız bir sinyali ölçerken, yapay zeka metin dedektörlerinin elinde insan metinlerinden türetilmiş aynı olasılık uzayından başka bir veri yoktur. İnsana benzemek üzere optimize edilmiş bir modelin çıktısını istatistiksel benzerlik üzerinden yargılamak, ölçülebilir bir fiziksel gerçeği değil, metodolojik bir çıkmazı temsil eder.

Bağımsız Fiziksel Sinyal ve Duman Dedektörü Analojisi

Duman dedektörüne inanırım. Havayı koklar, partikül yoğunluğunu ölçer, optik bir eşik aşıldığında da anında alarmı basar. Arkasında ölçülebilir, bağımsız bir fiziksel sinyal vardır.

Ama yapay zeka dedektörüne inanmam. Çünkü ortada çok temel bir problem var: Yapay zeka, insanların yazdığı milyarlarca metinden öğreniyor. Sonra başka bir yazılım geliyor ve o metinlerden öğrenmiş bir sistemin ürettiği yazıya bakıp, “Bunu insan mı yazdı, yapay zeka mı?” diye karar vermeye çalışıyor.

Neye bakarak? Kelime seçimine mi? Cümle uzunluğuna mı? Metnin fazla düzgün olmasına mı? Tahmin edilebilir kelimelerin peş peşe gelmesine mi?

Bunların hiçbiri yapay zekaya özgü şeyler değildir. Bir insan da son derece düzenli, sade ve tahmin edilebilir yazabilir. Bir yapay zeka da dağınık, kişisel, hatalı veya sıra dışı yazabilir. Burada zaten modelin tek amacı insan metinlerinin dağılımını öğrenip ona benzemektir.

Aynı Metin Uzayında İki Yazar: İnsan ve Makine

Duman dedektöründe duman ile dedektör arasında bağımsız bir fiziksel sinyal bulunur. Yapay zeka dedektöründe böyle bir sinyal yoktur.

Dedektörün elinde yalnızca metin vardır ve aynı metin uzayında hem insan hem makine yazar. Bu araçlar doğrudan üretim sürecini veya nedensel bir fiziksel izi ölçmez; insan metin dağılımı üzerinden türetilmiş olasılıksal bir benzerlik sınıflandırması sunar. Dil modelleri zaten insan üslubunu taklit etmek üzere eğitildiğinden, bu skorlar yüksek yanlış pozitif riski taşır ve kesin bir kanıt değeri üretmez.

Kendi Dağılımına Benzeme Çıkmazı

Burada aslında bir dağılımın kendisine ne kadar benzediği sorulmaktadır. Bu yüzden mesele “bu araçlar kesin hüküm değil, yalnızca benzerlik skoru veriyor” meselesi değildir.

Mesele, o benzerliğin ölçülebilir ve ayırt edici bir parametre olup olmadığıdır. Doğrulukla ölçemiyorsanız, elinizdeki sayısal skor süsten ibarettir.

Buna rağmen öğrenciyi suçlamak, çalışanı sorgulamak veya makaleyi reddetmek gibi biçimlerle bir insanın emeğini ölçülemeyen bir benzerlik yüzünden değersizleştirmek affedilmez bir hatadır.

Duman dedektörü öterse önce mutfağa bakarım. Ama yapay zeka dedektörü öterse önce dedektörden şüphelenirim.

Kaynaklar

Sadasivan, V. S., Kumar, A., Balasubramanian, S., Wang, W., & Feizi, S. (2023). Can AI-generated text be reliably detected? arXiv preprint arXiv:2303.11156.
Weber-Wulff, D., Anohina-Naumeca, A., Bjelobaba, S., Foltýnek, T., Guerrero-Dib, J., Popoola, O., Šigut, P., & Waddington, L. (2023). Testing of detection tools for AI-generated text. International Journal for Educational Integrity, 19(1), 26.

İlgili Bağlantılar

LinkedIn Paylaşımı: Duman Dedektörüne Güvenirim, Yapay Zeka Dedektörüne Güvenmem
LLM Dinamikleri: LLM Modellerinde Kısa Devre: AI Neden Bize “Yalan” Söylüyor?
Ekonomi ve Güvenilirlik: Ucuz LLM İllüzyonu: Başarılı İşlem Başına Maliyet Neden Token Fiyatından Önemlidir?
Yapay Zeka Mimarisi: Agent’a Her Şeyi Anlatma, Nereye Bakacağını Öğret

Bir ürün testte başarısız olduğunda ilk refleks ürünü suçlamaktır. Ancak mekanik hizalama, fikstür esnemesi ve referans ekipman kararsızlığı gibi ölçüm sistemi parametreleri sağlam bir ürünü hatalı, hatalı bir ürünü ise sağlam gösterebilir. Kalite kontrolde güvenilirlik, yalnızca ürünü değil, ölçüm yönteminin kendisini doğrulamakla başlar.

Test Sonucunu Belirleyen Gizli Değişkenler

Bir ürün testte başarısız oldu. Peki gerçekten ürün mü başarısız oldu?

Ölçüm sistemlerinde çok kolay unutulan bir gerçek var: Test sonucu sadece test edilen ürüne bağlı değildir. Bir ölçüm sürecinde sonuca doğrudan etki eden temel parametreler şunlardır:

• Fikstür tasarımı ve rijitliği
• Mekanik hizalama ve eksenel paralellik
• Destek noktaları ve gövde salınımı
• Referans ekipmanın metrolojik hassasiyeti
• Numunenin bağlanma ve tork şekli
• Yazılım parametreleri ve filtreleme frekansı
• Operatörün uyguladığı yöntem ve el alışkanlığı

Bu değişkenlerin her biri, test edilen parça kusursuz olsa dahi ölçüm sonucunu doğrudan saptırabilir.

Aynı Ürün, Farklı Kurulum ve Değişen Sonuçlar

Yakın zamanda aynı ürünü farklı test koşullarında ölçerken sonuçların ne kadar ciddi biçimde değişebildiğini somut bir deney düzeneğinde inceledim.

İlk bakışta ürünün ölçüm değeri kabul edilemez derecede kötü görünüyordu. Ancak ürün tasarımına dokunmadan; yalnızca test düzeneğini, mekanik desteği ve ölçüm yöntemini değiştirdiğimizde sonuç bambaşka bir seviyeye geldi:

Kalite Kontrolde Ölçüm Yöntemini Doğrulamak

Dolayısıyla ölçüm sonucu kötü diye ürünü hemen suçlamayın. Karar vermeden önce şu soruyu sormak gerekir: “Bu ölçüm sisteminin kendisine ne kadar güveniyorum?”

Kötü ve kararsız bir test sistemi, sağlam bir ürünü hatalı gösterebilir. Bundan çok daha tehlikeli ve maliyetli olanı ise; zayıf bir ölçüm sisteminin hatalı bir ürünü sağlam olarak onaylayıp müşteriye sevk etmesidir.

Kalite güvencede ve kök neden analizinde asıl mühendislik refleksi, yalnızca test edilen parçayı değil; fikstürü, hizalamayı, operatör metodolojisini ve ölçüm zincirini de eşzamanlı doğrulamaktır.

Kaynaklar

AIAG. (2010). Measurement Systems Analysis (MSA Reference Manual) (4th ed.). Automotive Industry Action Group.
JCGM. (2008). Evaluation of measurement data — Guide to the expression of uncertainty in measurement (GUM). JCGM 100:2008.
Montgomery, D. C. (2019). Introduction to Statistical Quality Control (8th ed.). John Wiley & Sons.

İlgili Bağlantılar

Saha ve Servis Mimarisi: IoT ve Giyilebilir Cihaz Ekosistemi İçin Uçtan Uca Servis ve Diagnostik Operasyon Mimarisi
Kriz ve Kalite Yönetimi: Mobil Ekosistemde Müşterinin Sesi Analitiği ve Kritik Kalite Kriz Yönetimi
Yönetim ve Metodoloji: Satış Sonrası Hizmetlerde Teknik Bilgi Yönetimi ve L1/L2 Destek Mimarisi

Bir şirkette satış birimine yalnızca ciro hedefi verilip servis ve saha maliyetleri hesaba katılmadığında, her departman kendi hedefini tuttururken şirket hızla zarar edebilir. Mesele çalışanların duyarsızlığı veya bir performans sorunu değil; KPI’ların araç olmaktan çıkıp amaca dönüştüğü sistemsel bir tasarım hatasıdır. Çapraz departmanlar arası maliyet dengesi gözetilmeden kurgulanan teşvikler, organizasyonel körlüğü kaçınılmaz kılar.

300 Dolarlık Kurulumun Görünmeyen Bilançosu

Herkes hedefini tutturuyor, ama şirket zarar ediyor.

KPI’ları yanlış belirlemenin ve onu bir araç olmaktan çıkarıp amaç haline getirmenin nasıl sonuçlar doğurduğuna somut bir saha örneğiyle bakalım.

Büyük bir firmada satış biriminin temel hedefi ciro olarak belirlenmiş. Müşteriyi memnun etmek ve ana ürünü daha rahat satmak için kurulumlara, arızalara ve saha hizmetlerine mümkün olduğunca düşük fiyatlar veriliyor.

Geçtiğimiz günlerde karşılaştığım örnek şuydu: Samsun’a gidilecek. İki mühendis üç gün konaklayacak ve sahada kurulum yapacak. Müşteriye verilen toplam servis fiyatı: 300 dolar. Oysa iki mühendisin yalnızca bir günlük otel konaklama masrafı bile 300 doların üzerinde.

Şirketin İnsanlara Yanlış Oyunu Oynatması

Şimdi burada satışçıya kızabilir misiniz?

Satış temsilcisine hedef olarak “ciro yap” demişsiniz; karlılığı önüne bir hedef veya sınır olarak koymamışsınız. Saha mühendisinin maliyeti ise onun KPI’ında görünmüyor bile. O da kendisinden isteneni yapıyor: Asıl ürünü daha rahat satmak için servis hizmetini bilerek ucuza veriyor, 300 dolar fatura kesip satış tablosuna +300 dolar ciro yazıyor.

Peki şirketin tablosunda gerçekte ne oluyor?

Üç günlük uzman mühendislik zamanı, ulaşım, konaklama, harcırah ve o mühendisin üç gün boyunca katma değerli başka bir projede kullanılamamasının fırsat maliyeti şirketin üzerinde kalıyor.

Daha kötüsü, bu maliyet çoğu zaman satışın üzerinde de görünmüyor. Teknik servisin, saha mühendisinin veya kurulum ekibinin üzerine yazılıyor. Sonra yıl sonunda raporları açıyoruz:

• Satış ekibi başarılı ilan edilir; hedefini tutturmuş, ciroyu basmıştır.
• Teknik servis ise “pahalı” ve “maliyetli” olarak yaftalanır.
• Kurulum ekibinin yeterince gelir üretmediği iddia edilir.

Kağıt üzerinde hepsi doğru görünür; gerçekte ise şirket kendi kendini kandırmaktadır. Çünkü burada mesele satışçının yanlış fiyat vermesi değil, şirketin insanlara yanlış oyunu oynatmasıdır.

Performans Değil, Tasarım Sorunu

Sonra herkes kendi hedefinde başarılı olurken şirketin neden para kazanamadığı tartışılır.

Sonuçlar beklendiği gibi gitmediğinde herkes geriye dönük haklılık aramaya başlar. Oysa Goodhart Yasası bu durumu açıkça tanımlar: Bir ölçüt hedef haline geldiğinde, iyi bir ölçüt olma özelliğini kaybeder.

KPI amaç değildir. KPI, şirketin gerçek amacına doğru gidip gitmediğini ölçmek için kullandığınız bir araçtır.

Mesele bir personel performans sorunu değil, teşvik ve mimari tasarım sorunudur. KPI’yı doğru tasarlamadan çalışanlara “daha sorumlu davranın” demek hiçbir işe yaramaz.

Kaynaklar

Goodhart, C. A. E. (1975). Problems of Monetary Management: The U.K. Experience. Reserve Bank of Australia.
Kerr, S. (1975). On the folly of rewarding A, while hoping for B. Academy of Management Journal.
Goldratt, E. M., & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press.

İlgili Bağlantılar

LinkedIn Paylaşımı: Hatalı KPI Tasarımı ve Şirket İçi Görünmeyen Maliyetler
Liderlik ve Kültür: Sessizlik Kültürü ve Kontrol Mekanizmaları: Şirkette En Tehlikeli Çalışan Kimdir?
Destek ve Servis Mimarisi: Satış Sonrası Hizmetlerde Teknik Bilgi Yönetimi ve L1/L2 Destek Mimarisi
Maliyet ve Süreç: Ucuz LLM İllüzyonu: Başarılı İşlem Başına Maliyet Neden Token Fiyatından Önemlidir?