ODTÜ’de Başlayan, Toyota Production System ile Derinleşen ve Dijital Dönüşüme Uzanan Bir Hikâye
Bugün sanayi dünyasında çok sık duyduğumuz bazı kavramlar var: Endüstri 4.0, Yapay Zekâ, Dijital İkiz, Akıllı Fabrikalar, PHM, kestirimci bakım, veri analitiği ve dijital dönüşüm.
Bu kavramlar çoğu zaman sanki birdenbire ortaya çıkmış yeni teknolojiler gibi anlatılıyor. Sunumlarda parlak görseller, sensörler, yapay zekâ modelleri, üç boyutlu fabrika çizimleri ve dijital panolar ön plana çıkarılıyor. Fakat yıllar içinde şunu daha net gördüm: Bu kavramların arkasında, çoğu zaman gözden kaçırılan çok daha eski ve çok daha sağlam bir mühendislik düşüncesi var.
Benim için bu düşüncenin başlangıç noktası ODTÜ Makine Mühendisliği Bölümü’nde aldığım Reliability Engineering dersiydi.
O dersi Prof. Dr. Alp Esin’den almıştım. O zamanlar bunun hayatım boyunca zihnimde kalacak bir ders olduğunu tam olarak fark etmiyordum. Birçok öğrenci gibi ben de Reliability Engineering’i ilk bakışta istatistiksel hesaplar, Weibull dağılımları, MTBF analizleri, arıza olasılıkları ve benzeri teknik başlıklar üzerinden görüyordum.
Ama Alp Esin hocamızın anlattığı şey sadece bu değildi.
Asıl mesele bir sistemin ne zaman bozulacağını hesaplamak değildi. Asıl mesele, sistemlerin neden başarısız olduğunu anlamaktı.
Bugünden geriye baktığımda, okul hayatımda aldığım bazı derslerin yalnızca sınavı geçmek için öğrenildiğini; bazı derslerin ise insanın düşünme biçimini kalıcı olarak değiştirdiğini görüyorum. Reliability Engineering benim için ikinci gruptaydı.
O ders bana şunu öğretti:
Bir arıza tesadüf değildir.
Bir duruş yalnızca bir sonuçtur.
Bir problemin arkasında mutlaka anlaşılması gereken bir neden vardır.
Bu bakış açısı yıllar sonra iş hayatımda, özellikle Japon otomotiv tedarik sanayisinde çalışırken çok daha anlamlı hale geldi.
Toyota Production System uygulamalarını öğrenmeye başladığımda, aslında ODTÜ’de aldığım Reliability Engineering eğitiminin beni bu düşünce sistemine hazırlamış olduğunu fark ettim. TOTOTETSU’de birlikte çalıştığım değerli mentorlarımdan Takahiro Takaki-san bana sık sık şu soruyu sorardı:
“Toyota sistemini bu kadar kısa sürede nasıl kavrayabiliyorsun?”
O zaman bu soruya net bir cevap veremiyordum. Sadece bazı şeyler bana tanıdık geliyordu. Toyota’nın problem çözme biçimi, kök nedene inme yaklaşımı, sistemleri bütün olarak ele alma disiplini, bana yabancı değildi.
Bugün bunun nedenini daha iyi anlıyorum.
Çünkü Toyota Production System’in derinlerinde de aynı düşünce vardı: problemi yüzeyde değil, kökte aramak.
Bu düşünce daha sonra yazdığım “Çift Geçişle Dönüşüm” kitabının da temel omurgasını oluşturdu. Zaman içinde kafamda şu zincir netleşti:
Reliability → Maintainability → Safety → Risk → PHM → Digital Twin
Bugün dijital dönüşümü anlamak isteyen herkesin, aslında bu zinciri anlaması gerektiğine inanıyorum.
Her Şey Reliability ile Başladı
Reliability Engineering’in klasik tanımı bellidir:
Bir sistemin, belirli koşullar altında, belirli bir süre boyunca görevini yerine getirme olasılığı.
Bu tanım doğrudur ama bana göre tek başına yeterli değildir. Çünkü Reliability Engineering yalnızca bir olasılık hesabı değildir. Daha derinde çok daha temel bir soru vardır:
Sistemler neden başarısız olur?
Bir rulman neden bozulur?
Bir motor neden durur?
Bir üretim hattı neden performans kaybeder?
Bir uçak sistemi neden arızalanır?
Bir proses neden beklenen kaliteyi sürekli üretemez?
Bu soruların cevabı sadece istatistikle verilemez. İşin içinde fizik vardır, malzeme bilimi vardır, triboloji vardır, yorulma teorisi vardır, termodinamik vardır, insan faktörleri vardır, bakım alışkanlıkları vardır, tasarım tercihleri vardır ve en önemlisi sistem düşüncesi vardır.
Benim Reliability Engineering’den öğrendiğim en önemli şey buydu.
Arıza dediğimiz şey, çoğu zaman sistemin bize gönderdiği bir mesajdır. O mesajı doğru okuyabilirsek, yalnızca bozulan parçayı değil, sistemin davranışını da anlamaya başlarız.
Bu yüzden Reliability benim için hiçbir zaman yalnızca bir mühendislik dersi olmadı. Zamanla bir düşünme biçimine dönüştü.
Toyota Production System’i Neden Hızlı Anladım?
Toyota Production System’e dışarıdan bakıldığında, bazı araçlar bütünü gibi görünür.
Kanban, Andon, Jidoka, Kaizen, Heijunka, Standard Work…
Bunlar elbette çok önemli kavramlardır. Ancak Toyota’yı Toyota yapan şey yalnızca bu araçlar değildir. Bu araçların arkasında çok güçlü bir düşünce sistemi vardır.
Toyota’nın temel sorusu şudur:
Problem neden oluştu?
Bu soru, Reliability Engineering’in sorduğu soruyla neredeyse aynıdır.
Toyota’daki “5 Why” yaklaşımı da aslında aynı mantığın üretim sahasındaki karşılığıdır. Bir makine durduğunda, Toyota düşüncesi hemen parçayı değiştirmeye odaklanmaz. Önce sorar:
Makine neden durdu?
Sensör arızalandığı için.
Sensör neden arızalandı?
Kirlenmişti.
Neden kirlenmişti?
Koruma kapağı eksikti.
Koruma kapağı neden yoktu?
Bakım prosedürü bunu yeterince tanımlamamıştı.
Bakım prosedürü neden yetersizdi?
Çünkü sistem tasarlanırken bakım erişilebilirliği yeterince düşünülmemişti.
İşte burada çok önemli bir fark ortaya çıkar.
Yüzeydeki problem sensör gibi görünür. Ama gerçek problem sensör değildir. Gerçek problem sistem tasarımında, bakım düşüncesinde veya standartların yetersizliğindedir.
Reliability Engineering ile Toyota Production System benim zihnimde tam olarak bu noktada birleşti.
İkisi de semptomlarla uğraşmaz. İkisi de kök nedeni arar.
Reliability’den Maintainability’ye: Arıza Olduğunda Ne Kadar Hızlı Toparlanıyoruz?
İş hayatında zamanla şunu görüyorsunuz: En iyi tasarlanmış sistemler bile sonsuza kadar sorunsuz çalışmaz. Her sistem bir gün arızalanır, durur, performans kaybeder veya müdahale gerektirir.
Bu noktada Reliability tek başına yeterli değildir.
Yeni soru şudur:
Sistem arızalandığında onu ne kadar hızlı ve ne kadar sağlıklı bir şekilde tekrar devreye alabiliyoruz?
İşte bu soru bizi Maintainability kavramına götürür.
Maintainability, bir sistemin belirli koşullar altında belirli bir süre içinde tekrar çalışır hale getirilebilme kabiliyetidir.
Başka bir ifadeyle, sadece arıza olasılığını azaltmak yetmez. Arıza gerçekleştiğinde toparlanma kapasitesini de tasarlamak gerekir.
Toyota’nın gücü burada da kendini gösterir. Toyota yalnızca arızaları azaltmaya çalışmaz. Aynı zamanda sistemin arızadan sonra hızlı toparlanmasını sağlayacak standartlar, yöntemler ve iş disiplinleri kurar.
SMED, yani kalıp değişim sürelerini radikal biçimde azaltma yaklaşımı, bunun en iyi örneklerinden biridir. İlk bakışta yalnızca üretim verimliliğiyle ilgili gibi görünür. Ama daha derinden bakıldığında, SMED aslında sistemin toparlanma kabiliyetini artıran bir Maintainability yaklaşımıdır.
Benim için bu kavramlar yıllar içinde birbirinden ayrı başlıklar olmaktan çıktı. Reliability, Maintainability ve yalın üretim aynı büyük resmin parçaları haline geldi.
Maintainability’den Safety’ye: Her Arıza Aynı Değildir
Bakım ve güvenilirlik konularıyla daha fazla ilgilendikçe başka bir gerçek daha net ortaya çıkar:
Her arıza aynı öneme sahip değildir.
Bazı arızalar üretim kaybına neden olur.
Bazı arızalar kalite problemine yol açar.
Bazı arızalar maliyeti artırır.
Bazı arızalar ise insan hayatını tehlikeye sokar.
İşte bu noktada Safety Engineering devreye girer.
Bir otomotiv fabrikasında bir kaynak robotunun durması üretim kaybı yaratabilir. Bu önemli bir problemdir. Ancak aynı robotun güvenlik sisteminin çalışmaması, çok daha kritik bir sonuç doğurabilir. Çünkü bu kez konu yalnızca üretim değildir; insan hayatıdır.
Bu nedenle soru değişir:
Arıza olursa ne olur?
Reliability bize arızanın olasılığını düşündürür.
Maintainability bize toparlanma süresini düşündürür.
Safety ise arızanın sonucunu düşündürür.
Bu üç kavramın birlikte ele alınmadığı hiçbir sistem bana göre tam anlamıyla olgun bir mühendislik sistemi değildir.
Safety’den Risk Yönetimine
Sanayi tarihine baktığımızda, büyük endüstriyel kazaların mühendislik disiplinlerini derinden etkilediğini görürüz. Three Mile Island, Bhopal, Challenger, Chernobyl gibi olaylar yalnızca teknik arızalar olarak açıklanamaz. Bu olaylar aynı zamanda sistemsel düşünme eksikliklerini, organizasyonel zafiyetleri ve risk yönetimi problemlerini de ortaya koymuştur.
Bu noktada Risk Management daha merkezi bir disiplin haline gelir.
Riskin temel formülü basittir:
Risk = Olasılık × Sonuç
Ama bu basit formülün arkasında çok güçlü bir düşünce vardır.
Formüldeki olasılık kısmı Reliability Engineering’den gelir.
Sonuç kısmı ise Safety Engineering’den gelir.
Yani Risk Management, aslında Reliability ve Safety disiplinlerinin birleştiği bir alandır.
Bu bakış açısı benim için iş hayatımda çok değerli oldu. Çünkü sahada karşılaştığımız birçok problem, yalnızca teknik bir arıza ya da yalnızca operasyonel bir aksaklık değildir. Bunlar çoğu zaman olasılık, sonuç, bakım kabiliyeti, insan davranışı, organizasyonel refleksler ve karar mekanizmalarının birleşiminden oluşur.
Bir problemi gerçekten anlamak için yalnızca “ne oldu?” diye sormak yetmez.
Şunları da sormak gerekir:
Bu olayın olma ihtimali neydi?
Sonucu ne kadar kritikti?
Daha önce hangi sinyalleri vermişti?
Sistem bunu neden önleyemedi?
İnsanlar, prosedürler ve teknoloji bu olayın neresindeydi?
Bu sorular beni zamanla PHM ve Digital Twin gibi daha yeni kavramlara götürdü.
Risk Yönetiminden PHM’e: Arızayı Önceden Görebilir miyiz?
Sensör teknolojileri, veri toplama sistemleri ve analiz yöntemleri geliştikçe mühendislik dünyası yeni bir soruya odaklandı:
Arızaları meydana gelmeden önce görebilir miyiz?
Bu soru, Prognostics and Health Management, yani PHM disiplininin temelini oluşturur.
PHM’in içinde condition monitoring, diagnostics, prognostics, remaining useful life ve decision support gibi başlıklar vardır. Türkçeye daha sade çevirirsek; sistemi izlemek, problemi teşhis etmek, gelecekteki arızayı tahmin etmek, kalan ömrü hesaplamak ve karar süreçlerini desteklemekten söz ediyoruz.
Ben PHM’i Reliability Engineering’in dijitalleşmiş hâli olarak görüyorum.
Çünkü değişen şey aslında temel soru değildir. Biz hâlâ sistemin nasıl davrandığını, neden bozulduğunu ve ne zaman bozulabileceğini anlamaya çalışıyoruz. Sadece artık elimizde daha fazla veri, daha fazla sensör ve daha güçlü algoritmalar var.
Eskiden arıza davranışını geçmiş verilerden, testlerden ve istatistiksel modellerden anlamaya çalışıyorduk. Bugün gerçek zamanlı veriler, yapay zekâ modelleri ve dijital platformlar üzerinden aynı sorulara daha hızlı ve daha kapsamlı cevaplar arıyoruz.
Ama temel değişmedi:
Sistemi anlamadan veriyi anlamak mümkün değildir.
Bu nedenle PHM projelerinde yalnızca veri bilimi yeterli olmaz. Mutlaka mühendislik sezgisi, saha bilgisi, bakım deneyimi ve sistem davranışı anlayışı gerekir.
PHM’den Digital Twin’e: Dijital İkiz Aslında Neyin İkizi?
Son yıllarda Digital Twin çok popüler bir kavram haline geldi. Fakat sahada sıkça gördüğüm bir yanılgı var: Dijital ikiz çoğu zaman yalnızca üç boyutlu bir model veya ekranda görünen dijital bir kopya gibi algılanıyor.
Bence bu eksik bir yaklaşım.
Gerçek bir Digital Twin yalnızca fiziksel varlığın görsel temsili değildir. Gerçek bir dijital ikiz fiziksel sistemin davranışını, performansını, risklerini, bakım ihtiyaçlarını ve gelecekteki olası durumlarını temsil edebilmelidir.
Bu nedenle gerçek bir Digital Twin’in içinde şu katmanlar olmalıdır:
Fiziksel sistem bilgisi,
Reliability model,
Maintainability model,
Risk modeli,
Operasyonel model,
Veri katmanı,
Yapay zekâ ve karar destek katmanı.
Bu açıdan baktığımda, Digital Twin bana yeni bir disiplin gibi gelmiyor. Daha çok, yıllardır gelişen mühendislik disiplinlerinin dijital ortamda birleşmiş hali gibi geliyor.
Yani Digital Twin’in kökleri yalnızca yazılımda ya da yapay zekâda değildir. Kökleri Reliability Engineering’dedir, bakım mühendisliğindedir, emniyet mühendisliğindedir, risk yönetimindedir ve sistem düşüncesindedir.
Bu kökleri anlamadan kurulan dijital ikizler, çoğu zaman parlak ama yüzeysel uygulamalar olarak kalır.
Çift Geçişle Dönüşüm: Önce Fiziksel Sistem, Sonra Dijital Sistem
“Çift Geçişle Dönüşüm” kitabımda ortaya koymaya çalıştığım model de aslında bu hayat ve iş deneyiminin bir sonucuydu.
Zaman içinde şunu gördüm: Birçok kurum dijital dönüşüme doğrudan ikinci aşamadan başlamak istiyor. Yapay zekâ kurmak, sensör eklemek, dashboard oluşturmak, veri toplamak ve dijital ikiz geliştirmek istiyorlar.
Bunların hepsi önemli. Ancak birinci geçiş tamamlanmadan ikinci geçişin başarılı olması çok zor.
Benim “birinci geçiş” dediğim şey, fiziksel sistemlerin olgunlaştırılmasıdır.
Yani süreçlerin anlaşılması, standartların kurulması, Reliability yaklaşımının yerleşmesi, Maintainability kabiliyetinin artırılması, Safety ve Risk Management disiplinlerinin oturtulmasıdır.
“İkinci geçiş” ise dijital sistemlerin kurulmasıdır.
Yani PHM, Digital Twin, yapay zekâ, veri analitiği ve karar destek sistemlerinin devreye alınmasıdır.
Buradaki kritik nokta şudur:
Kötü tasarlanmış bir fiziksel süreci dijitalleştirmek, o süreci iyileştirmez. Sadece hataların daha hızlı görünmesini veya daha hızlı yayılmasını sağlar.
Toyota’nın başarısı bana bu konuda çok şey öğretti. Toyota önce süreci anlar, sadeleştirir, standartlaştırır ve mükemmelleştirmeye çalışır. Sonra teknolojiyi bu sağlam zeminin üzerine yerleştirir.
Bu yüzden dijital dönüşüm yalnızca teknoloji yatırımı değildir. Dijital dönüşüm, önce düşünme biçiminin dönüşümüdür.
Bugünden Geriye Bakınca
Bugün geriye dönüp baktığımda, ODTÜ’de aldığım Reliability Engineering dersinin iş hayatımda ne kadar derin bir iz bıraktığını daha iyi anlıyorum.
O ders bana sadece arıza hesaplamayı öğretmedi. Sistemlere nasıl bakmam gerektiğini öğretti.
Toyota Production System’i öğrenirken bu bakış açısı bana yol gösterdi. Risk Management çalışmalarında aynı düşünceyi kullandım. PHM projelerinde aynı temel sorulara geri döndüm. Digital Twin kavramını değerlendirirken yine aynı mühendislik zincirine baktım.
Bugün geldiğim noktada şuna inanıyorum:
Digital Twin, PHM ve yapay zekâ sistemleri mühendislik dünyasına dışarıdan gelmiş kopuk teknolojiler değildir. Bunlar Reliability Engineering ile başlayan uzun bir evrimin bugünkü halkalarıdır.
Bu nedenle dijital dönüşüm konuşurken yalnızca teknolojiye odaklanmak bana eksik kalıyor. Sensörlerden, algoritmalardan ve yazılımlardan önce şu soruları sormamız gerekiyor:
Sistemi gerçekten anlıyor muyuz?
Arızaların neden oluştuğunu biliyor muyuz?
Bakım kabiliyetimizi ölçüyor muyuz?
Emniyet ile risk arasındaki ilişkiyi doğru kuruyor muyuz?
Veriyi hangi fiziksel gerçekliğin ürettiğini biliyor muyuz?
Dijital modeli hangi mühendislik temelleri üzerine inşa ediyoruz?
Bu sorulara güçlü cevaplar vermeden yapılan dijital dönüşüm yatırımları çoğu zaman beklenen değeri yaratmıyor.
Son Söz
Benim için Reliability yalnızca bir mühendislik dersi olmadı.
Reliability, sistemleri anlama biçimim oldu.
ODTÜ’de başlayan bu düşünce, Japon otomotiv tedarik sanayisinde Toyota Production System ile derinleşti. Daha sonra bakım, risk yönetimi, PHM ve Digital Twin çalışmalarında farklı biçimlerde karşıma çıktı. En sonunda da “Çift Geçişle Dönüşüm” yaklaşımının temelini oluşturdu.
Bugün sanayide dijital dönüşümden söz ederken, aslında bu yolculuğun en başına dönmek gerektiğine inanıyorum.
Çünkü gerçek dönüşüm, ekrana yeni bir yazılım koymakla başlamıyor.
Gerçek dönüşüm, sistemi gerçekten anlamakla başlıyor.
Ve benim hayatımda bu anlayışın ilk tohumu, Prof. Dr. Alp Esin’in Reliability Engineering dersinde atıldı.
Bu yazıyı da tamamen Alp Esin hocama saygı ve sevgimi sunmak için yazdım.
okandinc 
Yorum bırakın