Bilgi için Poka-Yoke: FMEA'nız neden boş kalıyor

Yıllar önce bir mühendis bildiklerini FMEA’ya yazmayı reddetti.

Nedenini toplantıda açıkça söyledi. Bunu yazıya dökmek, şirketteki kendi değerini düşürecekti.

Cevabı, elimde tuttuğum formdan daha dürüsttü.

Kimsenin tasarlamadığı teşvik

Neredeyse her tesiste, belirli bir makine durduğunda aranan bir kişi vardır. Onun bilgisi hiçbir belgede yer almaz. Bunu herkes bilir ve kimse düzeltmez.

Şirket onu, başkalarının bilmediğini bildiği için ödüllendirir. Sonra ondan bunu yazmasını ister. Yani aranmasının sebebini azaltmasını istemektedir.

Eliyahu Goldratt bu mekanizmayı tek cümleyle anlattı: bana beni nasıl ölçtüğünü söyle, sana nasıl davranacağımı söyleyeyim. O mühendis, yalnızca onun çözebildikleriyle ölçülüyor. Tam da ölçüldüğü gibi davranıyor.

Olağan cevap bir hatırlatma, bir şablon ya da bir eğitimdir. Üçü de problemin dikkat olduğunu varsayar. Değildir.

Shingo gerçekte ne dedi

Shigeo Shingo, çoğu kalite departmanının hâlâ bulanıklaştırdığı bir çizgi çekti. Hatayı kusurdan ayırdı. İnsanlar hata yapar. Hata, ancak arada onu hiçbir şey durdurmazsa kusura dönüşür.

Vardığı sonuç, insanlardan daha dikkatli olmalarını istemek değildi. Dikkatli olmak bir kontrol değildir. Adımı, yanlış hareket tamamlanamayacak şekilde tasarladı: parçayı yalnızca tek bir yönde kabul eden bir fikstür, eksik bir pul varken kapanmayan bir aparat.

Poka-yoke’nin amacı, insan dikkatine bağımlılığı tam da dikkatin dağılma ihtimalinin en yüksek olduğu anda ortadan kaldırmaktır.

Aynı fikri kendi FMEA’nıza uygulayın. Belge ancak biri hatırladığında, cömert hissettiğinde ve bir saati olduğunda doluyorsa, sistem dikkate bağlıdır. Ortada bir kontrol yoktur.

Excel’deki FMEA neden iki kez ölür

Bir tablodaki FMEA iki ayrı yerde başarısız olur ve ikincisi, bu dosyaların çoğunun dolu görünüp yine de kimseye yardım etmemesinin sebebidir.

Kayıtta başarısız olur. Ona yazmak, asıl iş bittikten sonra yapılan ayrı bir iştir. Bir sonraki şikâyetle yarışır. Kimsenin takip ettiği bir son tarihi yoktur. Bu yüzden düzensiz dolar, çoğunlukla da kaybedecek en az şeyi olanlar tarafından.

Erişimde başarısız olur. Yazılmış satırlara bile sonradan ulaşmak zordur. Altı ay sonra onlara ihtiyaç duyan mühendis dosyanın var olduğunu bilmez, SharePoint’teki on iki sürümünde arama yapamaz ve hangisinin güncel olduğunu bilmez. Bilgi teknik olarak yazılmıştır, pratikte ise kaybolmuştur.

Aynı tesiste hem “zaten her şeyi belgeliyoruz” hem de “aynı problemi yılda iki kez çözüyoruz” cümlelerinin doğru olmasının sebebi bu ikinci başarısızlıktır.

Bilgi için bir güvencenin yapması gerekenler

Kontrol dikkat değilse, dört özelliğin sağlanması gerekir. Hiçbiri yazılımla ilgili değildir.

Kayıt, işin bir yan ürünü olmalıdır. Bilgi, vaka kapatıldığı için kaydedilir; birisi sonradan istediği için değil. Ayrı bir adım varsa istisnalar olur ve istisnalar kurala dönüşür.

Kayıt kaynağını taşımalıdır. Arkasında belge, parti ya da ölçüm olmayan bir neden, biçimlendirilmiş bir görüştür. Bir sonraki mühendis ona güvenmek zorunda kalmamalı, onu kontrol edebilmelidir.

Erişim ihtiyaç anında gerçekleşmelidir. Talep üzerine değil, bir aramadan sonra değil. Benzer bir problem tanımlandığında, daha önce öğrenilenler onunla birlikte gelmelidir.

Yazan kişi, yazdığı için bedel ödememelidir. Diğer üçünün hiç çalışıp çalışmayacağına bu karar verir. Bilgi paylaşmak statü kaybına mal oluyorsa, sistem ne kadar iyi olursa olsun etrafından dolaşılır.

Bunun sonucu

Galileon’da inşa ettiğimiz şey bu. Belgelerin saklandığı bir yer değil, yeni bir form da değil. Kapatılan her vakanın bir sonrakini beslediği bir sistem.

Bunun mühendise kazandırdıklarını, Ocak-Mart 2026 arasında Slovenyalı üreticilerdeki 10 müşteri şikâyetinden oluşan kendi pilot örneklemimizde ölçtük:

• Düzeltici faaliyet adımı üç günlük toplantılardan ilk öneri için yaklaşık otuz saniyeye iner, çünkü öneriler doğrulanmış nedenlerde zaten işe yaramış faaliyetlerden gelir.
• Problem tanımı adımı boş bir şablona göre kabaca üç kat daha fazla kullanılabilir öneri üretir, çünkü boş bir sayfadan değil, benzer vakalardan başlar.
• Müşteri şikâyetinden önleyici faaliyete kadar tam izlenebilirlik sağlanır; böylece denetimdeki “buraya nasıl geldiğinizi gösterin” sorusunun zaten var olan bir cevabı olur.

Mühendisin yapmadığı şey: bir bilgi bankasını doldurmak. Kayıt, vaka kapatıldığı için yazılır.

Mühendiste kalan

Yapay zekâ ajanları veriyi bugün insanların topladığı gibi toplayacak ve şimdikinden çok daha fazla veri olacak. Son adım yine de bir insana ait.

Yerinden oynamayan muhakeme, analitik ve eleştirel düşünmedir ve dört kararda kendini gösterir:

• bu probleme neyin ait olmadığı
• neyin gürültü, neyin sinyal olduğu
• yorumun nerede yanlış olduğu
• hangi verinin daha büyük bir örneklemde yeniden toplanması gerektiği

Veri arttıkça, bunlardan hangisinin gerçekten problem hakkında bir şey söylediğine karar vermenin değeri de artar.

Çizilmeye değer çizgi

Bunun her şirketin kendi aracını geliştirdiği bir versiyonu da var. Kod artık ucuz; bu yüzden reddedilmesi gereken şeyler de geliştiriliyor ve sonuç, pek çok işlevi olan ama hiçbirine gönül verilmemiş bir ürün oluyor.

Bu başlamadan önce sorulmaya değer soru şu: hangi kısım gerçekten sizin alanınız ve hangi kısmı her gün bu işle uğraşan, çok daha fazla veriye sahip olan ve şirket içi bir MVP’den daha iyisini ortaya koyacak insanlara bırakmak daha doğru?

Cevabı siz vereceksiniz. Bunu akışına bırakarak değil, bilinçli olarak vermeye değer.

galileon.si’de daha fazlası

• Tek bir hatayı tanımlamak için iki yıl: Toyota’nın geri çağırması problem tanımı hakkında ne öğretiyor - bunun öncesinde olanlar: problem, analizin geçerli olabileceği kadar iyi hiç tanımlanmadığında.
• SolveR nasıl çalışır
• Veri güvenliği

Kaynaklar

• Shigeo Shingo, Zero Quality Control: Source Inspection and the Poka-Yoke System, Productivity Press, 1986. Yayıncının sayfası
• Eliyahu M. Goldratt, ölçüm ve davranış üzerine. Goldratt Consulting