İçeriğe geç
Endüstri 4.0 & IIoT13 Temmuz 202612 dk okuma

Mersin Fabrikaları için OEE Ölçümü: Üretim Verimliliğini Artırma Rehberi

Mersin Fabrikaları için OEE Ölçümü: Üretim Verimliliğini Artırma Rehberi

OEE Nedir ve Neden Elle Tutma Yanıltıcı?

OEE'nin Üç Temel Bileşeni

OEE, üretim verimliliğini üç ayrı perspektiften ölçen bir çarpandır:

1. Kullanılabilirlik (Availability): Planlanan üretim süresinin ne kadarında makine gerçekten çalıştı?

Formül: (Planlanan Süre - Duruşlar) / Planlanan Süre

Örneğin, 8 saatlik vardiyada 1 saat kalıp değişimi, 30 dakika arıza durduğu için kullanılabilirlik = (480 - 90) / 480 = %81,25

2. Performans (Performance): Çalıştığında tasarım hızına göre ne kadar hızlı üretildi?

Formül: (Üretilen Adet × İdeal Çevrim Süresi) / Çalışma Süresi

Makineniz saatte 1000 parça üretmeli ama 800 üretiyorsa performans %80'dir.

3. Kalite (Quality): Üretilen parçaların ne kadarı ilk seferde hatasız?

Formül: (Toplam Adet - Hatalı Adet) / Toplam Adet

1000 parça üretip 50'si hurdaysa kalite %95'tir.

OEE = Kullanılabilirlik × Performans × Kalite

Yukarıdaki örnekte: 0,8125 × 0,80 × 0,95 = %61,75 OEE

Dünya standardında %85 üzeri "birinci sınıf" kabul edilir. Türkiye ortalaması %40-50 bandında — yani tipik bir fabrika kapasitenin yarısını kullanıyor.

Elle Veri Toplamanın Görünmeyen Maliyeti

Çoğu fabrika hâlâ şöyle çalışıyor: Vardiya lideri A4 kağıda duruş nedenlerini yazıyor. "Hammadde bekleme: 45 dk" — ama gerçekte ne zaman başladı, ne zaman bitti bilmiyor, tahmini yazıyor. Makine operatörü "yavaş gidiyor" diyor ama kimse kronometre tutmuyor.

Bir Mersin'deki metal işleme fabrikasında gördüğümüz durum: Elle tutulan kayıtlara göre ortalama kalıp değişim süresi "30 dakika" — ama PLC loglarına baktığımızda gerçek ortalama 52 dakikaydı. Neredeyse iki katı. Neden? Çünkü operatör "planlanan süreyi" yazıyordu, gerçeği değil.

Bir başka örnek: "Makineler %90 kullanılabilirlikte" raporlanıyor ama sensör koyduğumuzda görüyoruz ki kısa duruşlar (30 saniye-5 dakika arası) hiç kayda geçmiyor. Operatör "önemsiz" bulup yazmıyor, ama günde 40 kez olunca vardiyada 2 saat kayıp ediyor.

Otomatik veri toplama şart değil — ama manuel veriyle karar vermek kumar oynamak gibi.

Sensör ve PLC'den Otomatik Duruş Kaydı: Nasıl Başlanır?

Minimal Başlangıç: Tek Makineden Pilot

Hemen tüm fabrikayı donatmaya çalışmayın. Bir darboğaz makine seçin — siparişleri en çok geciktiren, en pahalı olan veya en sık arıza veren.

İhtiyacınız olan minimum altyapı:

  1. Dijital sinyal okuma: Makinenizin PLC'sinde zaten var olan sinyalleri okumak (çalışıyor/durdu, alarm aktif, parça sayacı). Yeni sensör takmaya bile gerek olmayabilir.

  2. Basit edge cihaz: PLC sinyallerini MQTT veya HTTP ile buluta gönderen küçük bir donanım (Raspberry Pi bile olabilir).

  3. Duruş sebebi girişi: Operatörün tablet/bilgisayardan "neden durdu?" seçebildiği basit bir arayüz.

Önemli: Otomatik tespit "ne zaman durdu", manuel giriş "neden durdu" — ikisi birlikte anlam kazanır.

Örneğin bir içecek dolum hattında: Sensör "hat durdu" dedi, 3 dakika sonra operatör "şişe sıkışması" seçti. Sistem otomatik "3 dakika şişe sıkışması kaybı" kaydetti. Elle yazılsa muhtemelen hiç yazılmayacak ("küçük duruş") ya da 10 dakika yazılacaktı (yuvarlanarak).

Mersin Özelinde Pratik Zorluklar ve Çözümler

Mersin'de özellikle gıda ve kimya sektöründe eski makinelerle çalışan fabrikalar var. "PLC'miz eski, protokolü kapalı" diye başlamadan önce şunu bilin: Çoğu durumda makinenin elektrik panosundaki rölelerin açma-kapama sinyallerini bile okuyarak temel veri toplayabilirsiniz.

Bir un fabrikasında gördüğümüz çözüm: 1980 model değirmen, hiç PLC yok. Motora akım sensörü (clamp-on, müdahalesiz takılan) taktık — akım varsa çalışıyor, yoksa durmuş. %100 doğrulukta kullanılabilirlik verisi elde ettik. Maliyet? Sensör + edge cihaz toplamda birkaç bin lira.

Veri toplamak için makineyi durdurmak zorunda değilsiniz. Non-invasive (müdahalesiz) yöntemler her zaman öncelik.

Duruş Sebep Analizi: Pareto ile Neye Odaklanacağınızı Bulun

%80'i Oluşturan %20'yi Bulmak

Bir ay veri topladınız. Şimdi ne yapacaksınız? Eğer "tüm duruşları azaltmaya çalışırsak" derseniz, sonsuza kadar uğraşırsınız.

Pareto prensibi üretimde de geçerli: Toplam kayıpların %80'i, genellikle %20'lik sebep kümesinden gelir.

Mersin'de bir ambalaj firmasında yaptığımız duruş analizi:

  • Toplam 127 duruş nedeni kaydedilmiş (1 ay)
  • En üstteki 6 neden toplam duruş süresinin %78'ini oluşturmuş:
    1. Etiket rulolarının geç gelmesi (%22)
    2. Folyo sarım kafası ayar bozukluğu (%18)
    3. Kalite kontrol onayı bekleme (%14)
    4. Vardiya değişiminde makine teslim süresi (%11)
    5. Bantların kayması, tekrar germe (%7)
    6. Hammadde nitelik sorunu (çözücü viskozitesi) (%6)

Geriye kalan 121 duruş nedeni toplamda %22. İlk 6 sorunu çözmeye odaklandılar.

Sonuç? 3 ayda kullanılabilirlik %62'den %79'a çıktı. Binlerce sorunu çözmeye gerek kalmadı.

Vardiya Toplantısında OEE Panosu Nasıl Kullanılır?

Veri toplamak ile veriyle hareket etmek farklı şeyler. Çoğu fabrika verileri toplar, raporlar arşivlenir, kimse bakmaz.

Etkili kullanım: Her vardiya öncesi 10 dakikalık duruş toplantısı, duvarda büyük ekranda canlı OEE panosu.

Pano şunları göstermeli:

  • Dünkü OEE: Hedefle karşılaştırmalı (örn. %68, hedef %75)
  • En büyük 3 kayıp: Süre ve yüzdesiyle ("Kalıp değişimi: 85 dk, %18")
  • Trend grafiği: Son 7 günün OEE'si (yukarı mı gidiyor, aşağı mı?)
  • Makine bazlı kıyaslama: Hangi makine hedefin altında?

Toplantı formatı:

  1. 2 dakika: Gece vardiyasından bayrak teslimi — "şu sorun vardı, çözemedik"
  2. 5 dakika: En büyük kayıp üzerine tartışma — "kalıp değişimi neden 85 dakika sürdü?"
  3. 3 dakika: Bugünkü hedef ve odak — "bugün kalıp değişimini 60 dakikaya düşürmeyi deneyeceğiz, yeni prosedürü uygulayacağız"

Bu toplantılar olmadan OEE sadece bir KPI'dır — aksiyona dönüşmez.

Performans ve Kalite Bileşenlerinin Ölçümü

Teorik Hız mı, Gerçekçi Hız mı?

Performans hesaplarken sık yapılan hata: Makine kataloğundaki "maksimum hız" değerini kullanmak.

Bir tekstil boyahanesi örneği: Makine kataloğuna göre saatte 500 metre kumaş boyamalı. Ama hiçbir zaman o hıza ulaşılamıyor çünkü kumaş kalitesi, boya türü, nem gibi faktörler hızı sınırlıyor. "Performans %60" diye rapor ediliyor, ama bunun %20'si hiçbir zaman ulaşılamayacak teorik bir sayı yüzünden.

Daha doğru yaklaşım: Son 3 aydaki "en iyi günün" hızını referans alın. O bile ulaşılamaz değil (çünkü bir gün başarmışsınız), ama sürdürülebilir bir hedef.

Ya da hammadde/ürün tipine göre farklı ideal hızlar tanımlayın. A tipi ürün için 500 m/saat, B tipi için 400 m/saat gibi.

Kalite Kaybını Nerede Ölçersiniz?

Bazı fabrikalar sadece son kontrol noktasındaki hurdayı sayar. Ama eğer 1. operasyonda hatalı parça üretildiyse, 2. ve 3. operasyonlarda o parça için harcanan zaman da kayıptır.

İdeal: Her operasyonda ayrı kalite kaydı. Hangisinde fire daha yüksek, orada temel sebep var demektir.

Mersin'de bir metal kaplama atölyesinde: Son kontrolde %8 fire görülüyordu. Operasyon bazlı ölçüm yapınca şunu gördük:

    1. operasyon (kesim): %2 fire
    1. operasyon (bükme): %1 fire
    1. operasyon (kaplama): %6 fire

Sorun kaplamaydı — kimyasal konsantrasyon kontrolü yetersizdi. Oraya odaklandılar, genel fire %8'den %3'e düştü.

Eğer sadece sona bakıyor olsalardı, "kesimde sorun var" diye yanlış yere yatırım yapabilirlerdi.

Küçük Adımlarla Başlama: 90 Günlük Yol Haritası

İlk günden "akıllı fabrika" olmaya çalışmayın. İşte gerçekçi bir başlangıç planı:

1. Ay: Pilot + Manuel Veri Rafine Etme

  • Hafta 1-2: Bir darboğaz makine seçin, mevcut PLC/sensör sinyallerini tespit edin. D'Cloud Software gibi bir yazılım ekibiyle keşif yapın (hangi veriler var, hangi entegrasyonlar mümkün).

  • Hafta 3: Basit bir edge cihaz + duruş sebebi giriş arayüzü kurun. Operatörleri eğitin — "makine her durduğunda telefondaki uygulamadan neden seçeceksiniz."

  • Hafta 4: Veri kalitesini kontrol edin. Sebebi seçilmeyen duruşlar var mı? Operatörler unutuyor mu? Hatırlatma mekanizması ekleyin.

2. Ay: Analiz + İlk İyileştirmeler

  • Hafta 5-6: Pareto analizi yapın. En büyük 5 kaybı belirleyin, kök sebep analizi başlatın (5 Neden, balık kılçığı diyagramı gibi yöntemlerle).

  • Hafta 7: Vardiya toplantılarında OEE panosunu kullanmaya başlayın. İlk tepkiler genelde "veri yanlış" olur — çünkü elle tutulanla farklı. Sabırlı olun, veriyi birlikte doğrulayın.

  • Hafta 8: En kolay çözülebilecek 1-2 soruna odaklanın. Hızlı kazanım motivasyon sağlar. Örneğin "vardiya teslim süresi" gibi prosedürle çözülebilecek bir kayıp.

3. Ay: Ölçeklendirme + Rutin Haline Getirme

  • Hafta 9-10: Pilot makinede OEE %5-10 arttıysa (ki genelde artar), ikinci bir makineye genişletin. Aynı altyapıyı kopyalayın.

  • Hafta 11: Aylık OEE hedefleri koyun. Bunu ücret/prim sistemine bağlamayın (henüz) — önce kültürü yerleştirin, sonra teşvik mekanizması gelebilir.

  • Hafta 12: 90 günlük retrospektif: Ne iyileşti? Hangi direnç noktaları vardı? Sonraki çeyreğin hedefleri ne olmalı?

Önemli Not: İlk 90 günde "mükemmel sistem" değil, "işleyen veri kültürü" hedefleyin. Operatörler veri girmeyi alışkanlık haline getirdi mi? Yöneticiler kararları veriye dayalı almaya başladı mı? Bunlar teknik altyapıdan daha kritik.

Sık Sorulan Sorular

OEE ölçümü için ne kadarlık bir yatırım gerekir?

Bu tamamen fabrika büyüklüğüne, mevcut altyapıya ve hedeflerinize bağlı — bu yüzden baştan fiyat vermek yanıltıcı olur. Basit bir senaryo: Tek bir makinede, mevcut PLC verilerini okuyup buluta gönderen edge cihaz + operatör giriş arayüzü birkaç bin TL mertebesinde olabilir. Ancak 20 makineli bir tesiste, her makine farklı marka/model PLC'ye sahipse ve özel entegrasyonlar gerekiyorsa, maliyet doğal olarak daha yüksek olur. Keşif görüşmesinde mevcut durumunuzu inceledikten sonra sabit fiyat teklifi veriyoruz — sözleşmede yazılı olduğu şekilde, sürpriz maliyet olmadan. Ayrıca yazılım tesliminden sonra 15 gün ücretsiz hata düzeltme garantimiz var.

Elle OEE ölçümü yapamaz mıyız, neden mutlaka otomasyon gerekiyor?

Yapabilirsiniz — ama sonuçlar genelde %15-20 sapmalı olur. İnsanlar tahmini yazar, küçük duruşları atlar, bazen "iyi görünmek için" gerçekten fazla rakam yazabilir. Otomasyonun avantajı objektif, sürekli ve tüm detayları yakalayan veri. Yine de eğer bütçe çok kısıtlıysa, "yarı manuel" bir yaklaşımla başlayabilirsiniz: Operatör duruş sebebi elle giriyor ama süre otomatik kaydediliyor. Bu bile büyük fark yaratır. Tümüyle elle yapmak yerine en azından süre takibini otomatize edin.

Operatörler veri girişine direnç gösterirse ne yapmalıyız?

Bu çok yaygın bir durum. Operatörler "bizi kontrol etmek için kullanacaklar" diye endişelenir. Çözüm şeffaflık ve güven: İlk vardiya toplantısında açıkça söyleyin, "bu veri sizi değerlendirmek için değil, sistemdeki sorunları bulmak için." Hatta operatörlerle birlikte Pareto analizine bakın — "sizin işinizi zorlaştıran neymiş?" diye sorun. Veri onların lehine kullanılınca (örneğin kalıp değişim süresini kısaltmak için yeni takım alındı), direniş hızla azalır. Bir de girişi mümkün olduğunca basit yapın — tek tık, 5 saniye içinde bitmeli.

OEE hedefi ne olmalı? %85 gerçekçi mi?

Dünya standardı %85 "world class" der ama bu genelde otomotiv, ilaç gibi yüksek otomasyonlu sektörler için. Gıda, tekstil, metal işleme gibi sektörlerde %70-75 bile çok iyi bir hedeftir. İlk hedefiniz kendi geçmişinizden %10 yukarısı olmalı. Şu an %50 OEE'niz varsa, ilk 6 ayda %55'i hedefleyin. Sonra kademeli artırın. Bir anda %85 diye hedef koyarsanız, herkes demoralize olur çünkü ulaşılamaz görünür.

Mersin'deki fabrikalar için özel zorluklar var mı?

Mersin'de özellikle OSB'lerde (Tarsus, Mersin Serbest Bölge) gıda, kimya ve lojistik ağırlıklı. Bu sektörlerde hijyen/temizlik duruşları uzun (CIP, sanitasyon) — bunları "kayıp" olarak görmemek lazım, planlı duruş olarak ayırmalısınız. Aksi halde kullanılabilirlik yanıltıcı düşük çıkar. Bir diğer husus: Mevsimlik üretim yapan gıda fabrikalarında "sezon yoğunluğu" dönemleri için ayrı OEE hedefi koyun — yılın her ayını aynı kefeye koymayın. D'Cloud olarak Mersin merkezli olduğumuz için bu tip sektörel nüansları biliyor, yazılımda esnek parametre tanımları sunuyoruz.

OEE yazılımını kendi ERP sistemimize entegre edebilir miyiz?

Evet, çoğu durumda REST API veya veritabanı senkronizasyonu ile entegrasyon mümkün. Örneğin, üretim emirlerini ERP'den çekip OEE sisteminde ilişkilendirme yapabilirsiniz — böylece "X siparişi için kullanılan gerçek makine zamanı" gibi bilgiler ERP'de de görünür. Ya da tersine, OEE verilerini ERP'ye göndererek maliyet muhasebesinde "gerçek üretim süresi" bazlı hesap yapabilirsiniz. Entegrasyon detayları keşif aşamasında netleşir, her ERP farklı olduğu için standart paket yoktur — özel geliştirme gerekebilir.

Sonuç: Veriyle Yönetmek, Tahminde Boğulmamak

Mersin'de bir fabrika sahibi olarak her gün onlarca karar veriyorsunuz: Hangi makineye bakım yapılsın? Fazla mesai mi, yeni yatırım mı? Bu müşteriyi kabul etsek kapasitemiz yeter mi?

Bu kararları "hissiyat" ya da "geçen ayın tahmini rakamları" üzerine kurarsanız, kumar oynamış olursunuz. OEE ölçümü, bu belirsizliği ortadan kaldırıp gerçek kapasiteyi görmenizi sağlar.

Elle tutma yanıltıcıdır — sensör tabanlı otomatik veri toplama şart. Ama "tüm fabrikayı bir anda dijitalleştirme" de gerçekçi değil. Küçük başlayın: Bir pilot makine, 30 gün veri, Pareto analizi, ilk iyileştirmeler. OEE %5-10 arttığında hem finansal hem de operasyonel farkı hissedersiniz.

Duruş sebep analizi ile kayıpların %80'ini oluşturan %20'lik dilimi bulun — oraya odaklanın. Vardiya toplantılarında canlı OEE panosu kullanın ki veri aksiyona dönüşsün. Ve en önemlisi, operatörleri "kontrol edilen" değil "güçlendirilen" taraf olarak konumlandırın.

D'Cloud Software olarak Mersin'de üretim sektörüne özel çözümler geliştiriyoruz. OEE ölçümünden duruş analizine, vardiya raporlama sistemlerinden ERP entegrasyonuna kadar, fabrikalar için özelleştirilmiş yazılımlar sunuyoruz. Sabit fiyat, sözleşmede yazılı — sürpriz maliyet yok. Teslimden sonra 15 gün ücretsiz hata düzeltme garantisi veriyoruz.

Ücretsiz online keşif görüşmesi için iletişime geçebilir, WhatsApp üzerinden mevcut durumunuzu paylaşabilirsiniz. Fabrika ziyareti yapıp mevcut altyapınızı inceleyerek, size özel bir yol haritası hazırlıyoruz. Küçük bir pilot ile başlayıp kademeli ölçeklendirme sizin elinizde — ama ilk adımı atmadan hiçbir şey değişmez.

Yazar: Doğuhan Bulut
D'Cloud Software – Endüstri 4.0 & IIoT Çözümleri

YAZAR

Doğuhan Bulut

Kurucu & CTO

Full-stack mimari ve ürün stratejisi. Next.js ve bulut altyapılarında 10+ yıl deneyim.

SIRADAKİ ADIM

ERP geçişinizi planlayalım

Logo, Netsis, Mikro, SAP veya custom: mevcut süreçleri haritalandırıp doğru sistemde karar verelim. 30 dk ücretsiz keşif.

Ücretsiz keşif al
BENZER İÇERİKLER İSTERSEN

Aylık dijital özet bültenimiz

Ayda 1 e-posta — yeni teknoloji, KOBİ + KVKK güncellemeleri, vaka çalışmaları. Spam yok, istediğiniz an çıkış.