Üretim Tesisleri İçin OEE (Toplam Ekipman Etkinliği) ve Duruş Takip Web Dashboard Mimarisi

Üretim tesislerinde verimliliği artırmak için yalnızca toplam üretim miktarını izlemek yeterli değildir. Bir makinenin ne kadar süre çalıştığı, hedef çevrim hızına ne ölçüde ulaştığı ve ürettiği parçaların kaçının kalite kriterlerini karşıladığı birlikte değerlendirilmelidir. OEE (Toplam Ekipman Etkinliği) bu üç boyutu ortak bir göstergede birleştirir. Ancak güvenilir bir OEE sonucu, ekranda gösterilen yüzdeden önce doğru veri modeli, açık hesaplama kuralları ve denetlenebilir duruş kayıtları gerektirir.

Bu nedenle OEE ve duruş takip web dashboardu, standart grafiklerden oluşan hazır bir rapor ekranı olarak ele alınmamalıdır. Tesisin üretim yapısına, vardiya düzenine, veri kaynaklarına, kalite sürecine ve ERP/MES kullanımına göre tasarlanmış kuruma özel bir yönetim sistemi olmalıdır. Amaç; ham sinyalleri ve kullanıcı kayıtlarını, üretim müdürlerinden bakım ekiplerine kadar herkesin anlayabileceği ve aksiyona dönüştürebileceği ortak bilgiye çevirmektir.

OEE nedir ve hangi bileşenlerden oluşur?

OEE; kullanılabilirlik, performans ve kalite oranlarının çarpılmasıyla hesaplanır: OEE=Kullanılabilirlik × Performans × Kalite. IBM’in OEE açıklaması da göstergenin üretim süresi, çalışma hızı ve hatasız çıktı boyutlarını birlikte değerlendirdiğini belirtir. Tek bir bileşendeki kayıp toplam sonucu aşağı çektiği için dashboard, yalnızca nihai OEE yüzdesini değil üç bileşeni ve bunların dayandığı kayıtları ayrı ayrı göstermelidir.

Kullanılabilirlik

Kullanılabilirlik, gerçek çalışma süresinin planlanan üretim süresine oranıdır. Planlanan üretim süresinden arıza, ayar, malzeme bekleme veya benzeri duruşlar çıkarılarak çalışma süresi bulunur. Bununla birlikte mola, resmi tatil ve planlı bakım gibi zamanların paydaya girip girmeyeceği işletme kuralıdır. Sistem bu ayrımı kodla gizlemek yerine sürümlü ve yetkili kişilerce yönetilebilen bir hesap politikası olarak saklamalıdır.

Performans

Performans, ekipmanın çalıştığı süre içinde ideal çevrim hızına ne ölçüde yaklaştığını gösterir. Yaygın yaklaşım ideal çevrim süresi ile toplam üretim adedinin çarpımını gerçek çalışma süresine bölmektir. Ürüne, reçeteye, kalıba veya hatta göre ideal çevrim değişiyorsa tek bir makine hızı kullanmak yanıltıcı olur. Geçerli standart hızın ürün ve tarih bağlamıyla tutulması, geçmiş raporların sonradan bozulmasını önler.

Kalite

Kalite oranı, sağlam ürün miktarının toplam üretime oranıdır. Hurda, ret, yeniden işleme ve koşullu kabulün nasıl değerlendirileceği açıkça tanımlanmalıdır. Kalite sonucu laboratuvar veya ERP sisteminde daha sonra kesinleşiyorsa dashboard ön değer ile onaylanmış değeri ayırmalı; geriye dönük değişiklikleri kullanıcı, zaman ve gerekçe bilgisiyle kaydetmelidir.

Dashboard projesi veri kaynaklarının analiziyle başlamalıdır

İlk adım, hangi verinin hangi sistemde üretildiğini ve asıl kayıt sahibinin kim olduğunu belirlemektir. PLC, SCADA veya IoT geçidi çalışma-duruş sinyallerini sağlayabilir; MES iş emri, operasyon ve üretim adetlerini tutabilir. ERP ürün, rota, vardiya, sipariş ve kalite sonuçlarının ana kaynağı olabilir. Bakım yönetim sistemi ise arıza bildirimi, iş emri ve müdahale zamanlarını barındırabilir. Manuel formlar ve elektronik tablolar da mevcut sürecin göz ardı edilmemesi gereken parçalarıdır.

Her kaynak için kimlik alanları, veri sıklığı, zaman damgası, saat dilimi, bağlantı yöntemi, gecikme toleransı ve hata senaryosu kayda alınmalıdır. ISA-95, üretim operasyonları ile kurumsal sistemler arasındaki sınırları ve bilgi alışverişini tanımlamak için yararlı bir referans sunar. ISA-95 standardı, özellikle MES gibi seviye 3 sistemleriyle ERP gibi seviye 4 uygulamaları arasındaki entegrasyonun modellenmesine yardımcı olur.

Ortak üretim veri modeli nasıl kurulmalıdır?

Dashboardun omurgası, farklı sistemlerdeki kodları ortak bağlama taşıyan üretim veri modelidir. Tesis, bölüm, hat, iş merkezi, makine, vardiya, ekip, ürün, iş emri, operasyon ve parti ilişkileri tanımlanmalıdır. Aynı makinenin PLC’deki etiketiyle ERP’deki iş merkezi kodu farklıysa kalıcı bir eşleme tablosu kullanılmalıdır. Kodları yalnızca ekranda dönüştüren geçici çözümler, veri kaynağı değiştiğinde raporların kopmasına neden olur.

Temel olay kaydı; başlangıç ve bitiş zamanı, ekipman, olay durumu, kaynak sistem, iş emri, ürün, vardiya ve veri kalitesi bilgisini içermelidir. Üretim sayacı sıfırlanabilir veya ağ bağlantısı kesilebilir. Bu nedenle ham olaylar korunmalı, türetilmiş süre ve OEE sonuçları yeniden hesaplanabilmelidir. Kaynağı, dönüşüm kuralı ve hesap sürümü görülemeyen bir KPI denetlenebilir değildir.

Duruş neden ağacı ve kayıt yaşam döngüsü

Duruş takibinin değeri, “makine durdu” bilgisinden değil, duruşun nedenini tutarlı biçimde açıklayabilmekten doğar. Neden ağacı; planlı/plansız ayrımından başlayarak arıza, kalıp değişimi, temizlik, kalite kontrolü, malzeme bekleme, personel eksikliği veya üst-alt hat beklemesi gibi kategorilere ayrılabilir. Alt nedenler tesis ve makine grubuna göre yönetilmeli; serbest metin yalnızca açıklama amacıyla kullanılmalıdır.

Sinyal geldiğinde sistem otomatik bir duruş olayı açabilir. Operatör belirli süre içindeki olaya neden seçer, gerekiyorsa açıklama veya fotoğraf ekler. Uzun ya da kritik duruş bakım ekibine bildirilir; vardiya amiri sınıflandırmayı doğrular. Sonradan yapılan değişiklikler eski değer, yeni değer, kullanıcı ve zaman bilgisiyle denetim izinde tutulur. Böylece dashboard yalnızca rapor değil, kayıt kalitesini yöneten bir iş akışına dönüşür.

Operatör ekranı birkaç dokunuşla kullanılabilmeli; aktif makineyi, başlayan duruşu ve uygun nedenleri bağlama göre göstermelidir. Tablet, terminal veya mobil cihaz kullanımında büyük dokunma alanları, kısa listeler ve çevrimdışı kuyruk önemlidir. Benzer eşitleme ve güvenli tekrar ilkeleri, depo mobil uygulaması planlamasında olduğu gibi üretim sahasındaki kesintili bağlantılar için de düşünülmelidir.

Gerçek zamanlı görünürlük nasıl tasarlanmalıdır?

“Gerçek zamanlı” her veri için aynı anlama gelmez. Makine durumu saniyeler içinde güncellenirken ERP iş emri veya kalite sonucu birkaç dakikalık aralıklarla gelebilir. Mimari; olay tabanlı aktarım, zamanlanmış entegrasyon ve kullanıcı girişini birlikte desteklemelidir. Her kartta son güncelleme zamanı ve veri durumu gösterilmeli; geciken kaynak güncelmiş gibi sunulmamalıdır.

Akış genellikle saha sistemlerinden veri alma, doğrulama ve eşleme, olayları ortak modelde saklama, OEE hesaplama servisi ve web arayüzü katmanlarından oluşur. Mesaj kuyruğu veya benzeri tampon mekanizması geçici kesintilerde veri kaybını azaltabilir. Tekrarlanan mesajlar benzersiz olay kimliğiyle ayıklanmalı; eksik zaman aralıkları veri kalite kuyruğuna düşmelidir. Böylece entegrasyon geri geldiğinde kayıtlar güvenli biçimde tamamlanabilir.

Yönetim ekranlarında hangi görünümler bulunmalıdır?

Ana ekran, tesisin o anki durumunu hızlı karar vermeye uygun bir hiyerarşiyle sunmalıdır. Üst seviyede OEE ve üç bileşeni; altında hat ve makine kırılımları, aktif duruşlar, hedef-gerçekleşen üretim ve veri kalitesi uyarıları yer alabilir. Renk tek başına anlam taşımamalı; durum etiketi, süre ve eşik bilgisiyle desteklenmelidir.

• Tesis, hat, makine, vardiya, ürün ve tarih filtreleri
• OEE, kullanılabilirlik, performans ve kalite eğilimleri
• Aktif duruşlar ve müdahale bekleyen olaylar
• Pareto görünümünde en yüksek süre veya sıklığa sahip nedenler
• Planlı ve plansız duruş karşılaştırması
• Hedef-gerçekleşen adet, hurda ve yeniden işleme bilgileri
• Eksik sınıflandırma, geciken kaynak ve eşleme hatası uyarıları
• Ham kayda ve hesap ayrıntısına inen açıklama görünümü

Bir KPI kartına tıklandığında sonucun hangi vardiya, olay, sayaç ve hesap kuralından üretildiği görülebilmelidir. Bu detaylandırma özelliği, toplantılarda “rakam neden farklı?” tartışmasının yerine veriye dayalı kök neden analizini koyar. Karşılaştırmalarda yalnızca yüzde değil, kayıp dakika ve üretim etkisi de gösterilerek önceliklendirme kolaylaştırılabilir.

Rol, yetki ve denetim izi

Operatörün duruş nedeni seçmesi, bakım ekibinin teknik neden ve iş emri eklemesi, kalite ekibinin sağlam-ret sonucunu onaylaması, yöneticinin hedefleri izlemesi beklenir. Sistem yöneticisi ise eşlemeleri ve hesap politikalarını yönetir. Yetkiler tesis, hat ve işlem seviyesinde sınırlandırılmalı; görüntüleme, düzenleme, onay ve dışa aktarma ayrı izinler olarak ele alınmalıdır.

Hesap kuralı, ideal çevrim süresi veya duruş sınıfı değiştirildiğinde yürürlük tarihi kaydedilmelidir. Geçmiş dönemlerin yeni kuralla yeniden hesaplanıp hesaplanmayacağı kontrollü bir karar olmalıdır. Kişisel hesaplar, güçlü kimlik doğrulama, oturum kayıtları, veri aktarımında şifreleme, yedekleme ve saklama politikaları projenin başlangıcında planlanmalıdır. Bu yaklaşım müşteri gizliliğini ve üretim verisinin bütünlüğünü destekler.

ERP ve MES entegrasyonunda kritik kararlar

ERP’den alınacak ürün, rota, iş merkezi ve iş emri verileriyle dashboarddaki kodların sahipliği netleştirilmelidir. Üretim gerçekleşmeleri ERP’ye geri gönderilecekse kabul, ret ve tekrar deneme yanıtları izlenmelidir. Formdan başka bir kurumsal sisteme kayıt aktarımında kullanılan alan eşleme, mükerrer kayıt kontrolü ve hata kuyruğu yaklaşımı, web sitesi–CRM entegrasyonu planlamasında açıklanan ilkelerle benzer biçimde burada da uygulanabilir.

Entegrasyon yalnızca teknik bağlantı değildir. Hangi sistemin ürün adı, vardiya takvimi, kaliteli adet veya iş emri durumu için ana kaynak olduğu kararlaştırılmalıdır. ISA-95’in seviye 3 ile seviye 4 arasındaki bilgi alışverişine ilişkin yaklaşımı bu sorumlulukları tartışmak için ortak dil sağlar. NIST’in OEE üzerine değerlendirmesi de farklı tanım ve hesap yorumlarının bulunabildiğine dikkat çekerek hesap politikasının açık biçimde belgelenmesinin önemini destekler. NIST raporu, basit OEE oranıyla kullanılabilirlik, performans ve kalite temelli hesap yaklaşımını ayırır.

Proje kapsamı nasıl aşamalandırılmalıdır?

Sağlıklı başlangıç, tek bir kritik hat veya temsil gücü yüksek pilot alanla yapılabilir. Önce veri kaynakları ve mevcut kayıt alışkanlıkları incelenir; ardından KPI sözlüğü, neden ağacı, kullanıcı rolleri ve ekran taslakları hazırlanır. Pilot dönemde otomatik sinyaller ile sahadaki gerçek olaylar karşılaştırılır. Veri kalitesi kabul seviyesine ulaştığında kapsam diğer hatlara açılır.

Başarı ölçütleri yalnızca dashboardun yayına alınması olmamalıdır. Sınıflandırılmış duruş oranı, eksik olay sayısı, entegrasyon gecikmesi, kullanıcı müdahalesi gerektiren kayıtlar ve aksiyona dönüşen kayıp nedenleri izlenmelidir. Sistem yeni makineler, ürünler ve vardiya modelleri eklenebilecek biçimde ölçeklenmeli; hesap motoru ile arayüz birbirinden ayrılarak sürdürülebilir bakım kolaylaştırılmalıdır.

Kumsal Ajans ile kuruma özel OEE dashboardu

Kumsal Ajans, İstanbul merkezli bir dijital ajans olarak iş süreçleri, kullanıcı rolleri, veri yapıları ve entegrasyon gereksinimlerine göre özel web yazılımları geliştirir. OEE ve duruş takibi yaklaşımı hazır bir ürün iddiasına değil; tesisin gerçek üretim akışına uyarlanan güçlü yazılım altyapısına, kullanıcı odaklı arayüze, ortak veri yönetimine, güvenliğe ve sürdürülebilir işletime dayanır.

Kurumsal Kaynak Planlaması uzmanlığı sayesinde üretim dashboardu yalnızca saha sinyallerini gösteren bağımsız bir ekran olarak değil; ERP, MES, bakım ve kalite süreçleriyle bağlantılı bir yönetim katmanı olarak ele alınabilir. Üretim tesisinizdeki veri kaynaklarını, OEE hesaplama kurallarını, duruş kayıt sürecini ve ERP entegrasyonu ihtiyaçlarını birlikte analiz ederek kuruma özel web dashboard kapsamını planlamak için Kumsal Ajans ile iletişime geçin.