MTBF MTTR veri modeli, bakım performansını sayısal olarak izlemek isteyen işletmeler için ortak bir ölçüm dili kurar. Ancak MTBF ve MTTR, tek başına birer formülden ibaret değildir; bu metriklerin güvenilirliği, arıza olayının nasıl tanımlandığına, sürelerin hangi kurallarla hesaplandığına ve raporların hangi bağlamda sunulduğuna bağlıdır. Üretim yönetimi prensipleri çerçevesinde doğru yaklaşım, önce olay-süre modelini netleştirmek, ardından sınıflandırma ve raporlama katmanlarını aynı sözlükle bağlamaktır. Bu yazı, MTBF MTTR veri modeli tasarımında temel varlıkları, zaman damgası mantığını, planlı/plan dışı ayrımını ve raporlama yapısında dikkat edilmesi gereken teknik noktaları ele alır.
MTBF ve MTTR: Ölçüm tanımı, kapsam ve hesap kuralları
Teknik literatürde belirtildiği üzere MTBF (Mean Time Between Failures), arızalar arasındaki ortalama çalışma süresini; MTTR (Mean Time To Repair), arızadan yeniden kullanılabilir duruma dönüşe kadar geçen ortalama onarım süresini ifade eder. MTBF MTTR veri modeli kurulurken ilk adım, “arıza” ve “onarım” sınırlarının net tarif edilmesidir. Aksi halde aynı veri kümesiyle farklı ekiplerin farklı sonuçlar üretmesi mümkündür.
Yaygın kabul gören yaklaşıma göre hesaplama, iki temel zaman eksenini ayırır: çalışma zamanı ve duruş zamanı. MTBF çoğunlukla çalışma zamanı üzerinden, MTTR ise arıza kaynaklı duruş penceresi üzerinden değerlendirilir. Burada önemli nokta, planlı duruşların ve üretim dışı beklemelerin MTBF/MTTR kapsamına girip girmeyeceğinin açık bir kural setiyle belirlenmesidir. MTBF MTTR veri modeli bu kural setini veri sözlüğü olarak taşımalıdır.
MTBF/MTTR için asgari tanımlar
- Arıza olayı: Ekipmanın hedef fonksiyonunu yerine getirememesiyle başlayan, kayıt altına alınabilir bir olay.
- Arıza başlangıcı: Duruşun arıza nedeni ile başladığı zaman damgası.
- Arıza bitişi: Ekipmanın yeniden üretime hazır hale geldiği zaman damgası.
- Onarım süresi: Arıza başlangıcı ile arıza bitişi arasındaki süre; kural setine göre bekleme ve lojistik süreleri dahil/haric olabilir.
MTBF/MTTR veri modeli: Varlık hiyerarşisi, olay kayıtları ve süre türetimi
MTBF MTTR veri modeli, üç ana katmanda ele alınır: varlık (asset) modeli, olay (event) modeli ve türetilmiş süre/ölçüm (metrics) modeli. ISA-95 seviyeleriyle uyumlu düşünmek, üretim operasyonu ile bakım operasyonu arasında ortak veri sınırlarını tanımlamayı kolaylaştırır; yine de veri modelinin çekirdeği, her sistemde tutarlı olan varlık ve zaman damgası mantığıdır.
Varlık modeli (asset master)
Raporların anlamlı olabilmesi için ekipman kimliği, ekipman hiyerarşisi ve versiyonlanan master veriler net olmalıdır. MTBF MTTR veri modeli içinde ekipman; hat, istasyon, makine, alt komponent gibi seviyelere ayrılabilir. Önemli olan, olayın hangi seviyede toplandığı ve raporun hangi seviyede sunulduğunun aynı hiyerarşi üzerinden izlenebilmesidir.
Olay modeli (event log)
MTBF/MTTR hesapları doğrudan olay kayıtlarından türetilir. Bu nedenle olay kaydı, “ne oldu, ne zaman oldu, hangi varlıkta oldu, hangi sınıfta oldu” sorularını eksiksiz karşılamalıdır. Aşağıdaki alanlar, MTBF MTTR veri modeli için temel bir çekirdek olarak değerlendirilebilir.
| Alan | Açıklama |
|---|---|
| event_id | Tekil olay anahtarı |
| asset_id | Olayın ilişkilendiği ekipman kimliği |
| event_type | Arıza, planlı duruş, ayar, kalite beklemesi gibi sınıf |
| start_ts | Olay başlangıç zaman damgası |
| end_ts | Olay bitiş zaman damgası |
| duration_s | Hesaplanan süre (tercihen türetilmiş) |
| reason_code | Neden kodu (standart sözlükten) |
| planned_flag | Planlı/plan dışı ayrımı |
| source_system | Veri kaynağı (MES, CMMS, PLC, HMI vb.) |
| operator_id | İsteğe bağlı: giriş yapan/atanan kişi |
| work_order_id | İsteğe bağlı: bakım iş emri bağlantısı |
Süre alanını (duration) ham veri olarak saklamak yerine, start/end zaman damgalarından türetmek, yeniden hesaplamaya ve denetime imkan verir. MTBF MTTR veri modeli bu tercihi, veri ambarı veya raporlama katmanında standardize etmelidir.
Duruş ve arıza sınıflandırması: Planlılık, kapsam ve neden kodları
MTBF MTTR veri modeli yalnızca zaman damgası toplamakla tamamlanmaz; olayın sınıflandırılması raporun yorumunu doğrudan etkiler. Sektörde yaygın kabul gören yaklaşıma göre sınıflandırma iki eksende ele alınır: (1) planlı/plan dışı ayrımı, (2) fonksiyonel neden sözlüğü.
Planlı ve plan dışı ayrımı
Planlı duruşlar (bakım planı, kalibrasyon, periyodik kontrol gibi) ile plan dışı arızalar aynı olay günlüğünde yer alabilir; fakat MTTR ve arıza sayımı çoğunlukla plan dışı olaylardan türetilir. Bu nedenle planned_flag alanı yalnızca bir etiket değil, raporlama filtresinin temel girdisidir. MTBF MTTR veri modeli içinde bu ayrım, tanım dokümanıyla birlikte yönetilmelidir.
Neden kodu sözlüğü ve seviyeleme
Neden kodları, kısa vadeli raporlama ile kök neden analizini aynı çerçevede destekleyecek şekilde tasarlanır. Uygulamada hiyerarşik sözlük yaklaşımı kullanılır: üst seviye kategori (mekanik, elektrik, yazılım, proses, malzeme gibi) ve alt seviye detay kod. Bu yapı, raporlama yapısında hem yönetici özeti hem de mühendislik analizi için tutarlı kırılımlar sağlar. MTBF MTTR veri modeli, reason_code alanının serbest metin yerine kontrollü sözlükten gelmesini hedeflemelidir.
Arıza sayımı ve birleşik olaylar
Bir arıza kaydının “tek arıza” sayılıp sayılmayacağı, kısa aralıklı tekrarlar, aynı kök nedene bağlı kesintiler ve alt komponent arızaları gibi durumlarda kural gerektirir. Bu kural, olay birleştirme (merge) ve olay bölme (split) prensipleriyle tanımlanır. MTBF MTTR veri modeli, bu işlemleri sonradan izlenebilir kılmak için olay ilişkilerini (parent_event_id gibi) destekleyebilir.
Raporlama yapısı: Boyutlar, metrikler, filtre mantığı ve zaman pencereleri
MTBF ve MTTR raporları, tek bir sayıdan ziyade bağlamla birlikte anlam kazanır. Bu nedenle raporlama yapısının, veri modelindeki boyutları (asset, zaman, vardiya, ürün, iş emri, neden kodu) açıkça sunması beklenir. MTBF MTTR veri modeli ile raporlama katmanı arasında en çok hata, filtre mantığının belirsiz kaldığı durumlarda oluşur.
Boyutsal model yaklaşımı
Raporlama için yaygın yaklaşım, olayları bir “fakt” tablosunda toplamak ve çevresine boyut tabloları bağlamaktır. Aşağıdaki boyutlar MTBF/MTTR raporlarında sık kullanılır.
| Boyut | Raporlarda kullanım |
|---|---|
| Zaman | Gün/hafta/ay, vardiya, takvim dönemi |
| Ekipman | Hat-makine-alt komponent kırılımı |
| Olay sınıfı | Arıza, planlı duruş, ayar gibi ayrımlar |
| Neden kodu | Kategori ve alt neden analizi |
| İş emri | CMMS kayıtlarıyla izlenebilirlik |
| Üretim bağlamı | Ürün, operasyon, reçete versiyonu |
Metrik tanımı ve sürümleme
MTTR’nin hangi süreleri içerdiği (müdahale, bekleme, parça temini gibi) kuruluş içi kararlara bağlıdır. Bu nedenle raporlar, metrik tanımının sürümünü taşımaya uygun olmalıdır. MTBF MTTR veri modeli içinde metrik sözlüğü (metric_definition) tutmak, geçmiş raporların yeni kurallarla yanlış yorumlanmasını azaltır.
Zaman pencereleri: Takvim mi, üretim zamanı mı?
Raporlama dönemleri seçilirken takvim penceresi (ay bazlı) ile üretim penceresi (vardiya, plan) aynı şey değildir. MTBF MTTR veri modeli, olayları farklı pencerelere doğru şekilde dağıtmayı desteklemelidir. Ayrıca devam eden olaylar (end_ts olmayan kayıtlar) için raporlama kuralı belirlenir: hariç tutma, rapor anına kadar dahil etme veya ayrı bir “açık olay” metrik seti.
Veri kalitesi ve yönetişim: Zaman senkronu, tutarlılık kontrolleri ve denetlenebilirlik
MTBF MTTR veri modeli, veri kalitesi güvence altına alınmadan işletilebilir hale gelmez. Üretimden veri toplama katmanında saat senkronizasyonu, aynı olayın farklı kaynaklardan çift kaydı, eksik bitiş zaman damgaları ve serbest metin nedenler en sık karşılaşılan kalite problemleri arasındadır. Üretim yönetimi prensipleri çerçevesinde çözüm, veri girişini standardize etmek ve otomatik tutarlılık kontrolleri uygulamaktır.
Temel kalite kontrolleri
- start_ts ve end_ts sıralaması ve boş değer kuralları
- Aynı asset_id için çakışan olay pencerelerinin tespiti
- reason_code sözlüğü dışı değerlerin engellenmesi
- planned_flag ve event_type uyumsuzluk kontrolleri
- Kaynak sistemler arası olay eşleştirme anahtarları
Denetlenebilirlik ve değişiklik kaydı
Olay kayıtlarında sonradan yapılan düzeltmeler (zaman damgası düzeltimi, neden kodu güncellemesi) rapor sonuçlarını değiştirir. Bu nedenle MTBF MTTR veri modeli, değişiklik kaydı (kim, ne zaman, neyi değiştirdi) tutacak alanları veya ayrı bir audit günlüğünü desteklemelidir. Bu yaklaşım, raporlarda izah edilebilirlik sağlar.
MES odaklı entegrasyon prensipleri: CMMS ve otomasyon verisiyle uyum
MTBF MTTR veri modeli çoğu zaman birden fazla sistemin kesişiminde yer alır: otomasyon katmanından durum sinyalleri, HMI üzerinden operatör bildirimleri, CMMS üzerinden iş emri ve bakım faaliyetleri gibi. Burada amaç, aynı olayı farklı isimlerle çoğaltmak değil; tek bir olay kimliği etrafında bağlamsal bilgiyi zenginleştirmektir. Entegrasyon tasarımında olayın “kaynağı” ve “sahipliği” netleştirilir; zaman damgası otoritesi, neden kodu otoritesi ve iş emri otoritesi ayrı ayrı tanımlanır.
Üretimden veri toplama perspektifinde, ekipman durumları (çalışıyor, duruyor, arıza, bekleme) ile bakım olayları arasındaki dönüşüm kuralları yazılı hale getirilmelidir. MTBF MTTR veri modeli bu dönüşüm kurallarını hem raporlama hem de denetim için izlenebilir kılar; böylece MTBF ve MTTR değerleri, farklı raporlarda aynı mantıkla üretilebilir.
MTBF MTTR veri modeli ve raporlama yapısı, bakım performansı göstergelerini anlamlı ve tutarlı hale getirmek için olay tanımı, sınıflandırma, zaman penceresi ve veri kalitesini birlikte ele almayı gerektirir. Siz de MTBF/MTTR metriklerini kendi üretim yapınıza uygun bir veri sözlüğüyle standardize etmek, raporlarda aynı hesabı tekrar üretmek ve denetlenebilir bir yapı kurmak istiyorsanız MESPlus ile iletişime geçebilirsiniz.
