MES'i ertelemek, ERP'de geliştirme olarak geri döner
MES sadece OEE'nin hesaplandığı bir katman değil. Bir alüminyum yaşlandırma fırını üzerinden, sahanın operasyonel karmaşasını ERP'ye taşımak yerine MES'te yönetip ERP'ye özet göndermenin neden standardı koruduğunu anlatıyorum.
MES’e gerek var mı? Benim cevabım evet. ERP’nin yalın kalması ve sahadan gereken bilginin doğru toplanması için bile MES gerekli. MES sadece OEE’nin hesaplandığı bir katman değil. Önümüzdeki haftalarda birkaç yazıda bunu farklı örneklerle açmaya çalışacağım. Bu ilki.
Clean Core ile başlayan proje
SAP Public Cloud üzerinde bir proje geliştirdiğimizi düşünelim. Süreç Clean Core yaklaşımıyla başlar: çekirdeğe dokunulmayacak, standart süreçler kullanılacak, ihtiyaç duyulan geliştirmeler izin verilen genişletme noktalarında ya da yan uygulama olarak yapılacak.
Kağıt üzerinde çok doğru bir karar. Ama üretim sahasının detayına indikçe tablo değişir. Hemen hemen her üretim süreci, doğası gereği kendine özgü bir operasyonel karmaşa barındırır. Standart üretim teyidi bu karmaşayı taşımaz, taşıması için de tasarlanmamıştır. Maliyet gerekçesiyle “sonraki faz” diye ertelenen MES, bir süre sonra ERP içinde geliştirme maliyeti olarak geri döner.
Bunu bir senaryo üzerinden anlatayım.
Bir yaşlandırma fırını
Alüminyum parçalar yapay yaşlandırma için bir fırına yerleştiriliyor. Aynı reçeteye sahip birden fazla ürün aynı şarjda, 175 °C civarında saatlerce fırında tutuluyor, sonra çıkarılıp sertlik kontrolüne gidiyor. Yaşlandırma parçanın son mukavemetini belirler; sıcaklık ya da süre eksik kalırsa parça yeterince sertleşmez.
Bu kadarı ERP için basit görünür: bir iş emri, bir operasyon, bir teyit. Ama sahada önemli olan çoğu şey bu tek satırın içine sığmaz:
- Hangi ürün fırının hangi bölgesine yerleştirildi?
- Hangi sırayla girdiler, ne kadar kaldılar?
- O sürede her bölgenin sıcaklığı nasıl seyretti?
- Bu şarj ne kadar enerji harcadı ve bu enerji ürünlere nasıl dağıtılmalı?
Bunlar merak konusu değil. Bir kalite problemi, fırın içindeki homojen olmayan ısı dağılımından ya da ürünün bulunduğu bölgeden kaynaklanabilir. Bölgeyi bilmiyorsanız problemi de bilemezsiniz.
Bu karmaşa nerede yönetilmeli?
ERP içinde yapmaya kalktığınızda neler gerektiğine bakalım. Fırının bölgelerini bir şekilde modellemeniz, her ürünü bir bölgeye ve bir giriş zamanına bağlamanız, bölgesel sıcaklık verisini bir yerde saklayıp grafiklemeniz, operatörün fırın başında barkod okutacağı bir ekran tasarlamanız gerekir. Bunların hiçbiri standart değil. Her biri bir geliştirme, her geliştirme de bir sonraki sürüm yükseltmesinde test edilmesi gereken bir parça. Clean Core’dan ödün vermeden yapmaya çalıştıkça proje yan uygulamalarla büyür. Fark etmeden ERP’nin yanında bir MES yazmaya başlamış olursunuz, sadece adı MES değildir.
Daha doğru yaklaşım, bu operasyonel karmaşıklığı MES’te yönetmek ve ERP’ye üretim, tüketim, kalite ve maliyet açısından anlamlı sonuçları göndermek.
MES’te kalan, ERP’ye giden
ERP’nin ihtiyaç duyduğu veri genellikle maliyetle ilişkili özet bilgidir. MES bu bilgiyi bir hap gibi paketleyip ERP’ye gönderdiğinde, standardın korunmasına destek olur. Aynı fırın için iki tarafın gördüğü şey kabaca şöyle:
| MES’te kalan detay | ERP’ye giden özet |
|---|---|
| Şarj numarası, fırına giren her ürünün barkodu | Üretim teyidi: iş emri, tamamlanan miktar |
| Her ürünün bölgesi ve fırın içindeki pozisyonu | — |
| Giriş sırası, giriş ve çıkış zamanları | Operasyon süresi |
| Bölge bazında saniyelik sıcaklık eğrileri | — |
| Sertlik ölçümleri, ölçümün yapıldığı ürün ve bölge | Kalite sonucu: kabul ve ret miktarı, ret nedeni |
| Şarj boyunca harcanan enerji (kWh) | Birim başına enerji maliyeti |
| Kullanılan malzeme partileri | Parti bazında tüketim |
Sağ sütun ERP’nin standart süreçleriyle alınabilecek şeyler. Sol sütun ise ERP’nin hiç görmesine gerek olmayan, ama sahayı yönetmek için vazgeçilmez olan detay.
Bir kalite problemi
Farkı en iyi bir problem anında görürsünüz. Diyelim ki bir şarjdan çıkan on iki parçanın dördü sertlik kontrolünden kaldı.
ERP’de gördüğünüz şu olur: iş emri 4711, 12 adet üretildi, 4 adet ret, neden kodu “sertlik düşük”. Doğru ve yeterli bir kayıt. Maliyet hesaplanır, ret miktarı stoktan düşer, gerekiyorsa yeniden işleme emri açılır.
MES’te gördüğünüz ise şu: kalan dört parçanın dördü de üçüncü bölgede. O bölgenin sıcaklığı şarjın ortasında yaklaşık iki saat boyunca hedefin 15 °C altında seyretmiş, o bölgedeki parçalar eksik yaşlanmış. Diğer bölgeler hedefte. Sorun reçetede ya da malzemede değil, fırının bir bölgesinde. Bakım ekibi rezistansa bakar, sonraki şarjlarda o bölge izlenir.
Bu analizi ERP’de yapabilmek için yukarıdaki bütün detayı ERP’ye taşımış olmanız gerekirdi. Oysa ERP’nin bu analizden ihtiyaç duyduğu tek şey sonucu: kaç adet, hangi nedenle, ne maliyetle.
“ERP’nin içinde de yaparız”
Bu itiraz her projede gelir ve teknik olarak çoğu zaman doğrudur. Yapılabilir. Ama sorulması gereken soru yapılıp yapılamayacağı değil, kimin ne kadar süre bunun bedelini ödeyeceği.
Her sahaya özgü geliştirme, ERP’yi sahanın hızına bağlar. Fırına yeni bir bölge sensörü eklendiğinde, yeni bir hat kurulduğunda, operatör ekranında bir alan değiştiğinde ERP projesi yeniden açılır. Sürüm yükseltmelerinde test yükü artar. Saha kullanıcısı da ERP ekranlarıyla, fırın başında eldivenle çalışmaya uygun olmayan bir arayüzle baş başa kalır.
MES ise tam bu değişkenlik için var. Sahadaki her değişiklik orada karşılanır, ERP’ye giden özetin biçimi değişmez. Çekirdek temiz kalır, çünkü çekirdeğe gelen veri zaten temizdir.
Sonuç
Clean Core bir ERP kararı gibi görünür ama aslında bir mimari karardır. Çekirdeği temiz tutmak istiyorsanız, sahanın karmaşasının gidebileceği bir yer olması gerekir. O yer MES.
Benzer bir durumu stok tarafında MRP ve stok doğruluğu yazısında anlatmıştım: ERP’ye doğru tüketimin gitmesi de sahada doğru kaydın tutulmasına bağlı. Sonraki yazılarda başka üretim senaryolarıyla devam edeceğim.