Bir MES Ürününün İçine QMS Modülü Geliştirdim ve Canlıya Aldım

Dört aylık projenin son günü

Yaklaşık dört ay boyunca tek başıma geliştirdiğim kalite modülünü geçtiğimiz günlerde canlıya aldım.

İlk gerçek üretim verileri sisteme girildi. Laboratuvar sonuçları geldi. Sevkiyat bilgileri çekildi. Ardından ilk EN 10204 Type 3.1 sertifikası üretildi.

Daha önce bir sertifikanın hazırlanması dört ile beş saat arasında sürüyordu. Kalite ekibinin canlıya alma sonrası verdiği bilgiye göre aynı işlem artık yaklaşık 15 dakikada tamamlanıyor.

Bu yalnızca daha hızlı PDF üretmekle olmadı.

Hammadde girişinden laboratuvara, üretim içi ölçümlerden son kontrole, paketlemeden sevkiyata kadar bütün kalite verisini aynı zincirin parçaları olarak ele almak gerekti.

Çalıştığım şirket Konzek'in mevcut MES ürününe sıfırdan bir QMS modülü geliştirdim. Süreç analizinden mimariye, backend servislerinden React ekranlarına, veri göçünden saha eğitimine kadar projenin tek yazılım mühendisiydim.

Başlangıçta ortada tek bir sistem yoktu

Kalite verileri birkaç farklı yerde tutuluyordu.

Bir kısmı ERP'deydi. Bir kısmı ayrı bir kalite uygulamasındaydı. Ürün ve operasyon tanımları Excel dosyalarında, bazı üretim kontrolleri ise kâğıt formlardaydı.

Bir EN 10204 Type 3.1 sertifikası hazırlanırken şu bilgilerin bulunması gerekiyordu:

• müşteriye gönderilen gerçek sevkiyat,
• ürün ve hammadde lotları,
• kimyasal ve mekanik laboratuvar sonuçları,
• üretim rotası,
• proses sırasında girilen ölçümler,
• son boyutsal ve görsel kontroller,
• kaplama ve markalama bilgileri,
• uygulanacak standart ve mukavemet sınıfı.

Bu kayıtlar aynı anda oluşmuyordu. Aynı ekip tarafından da üretilmiyordu.

Bu yüzden problemi “sertifika formu yapalım” diye ele almadım. Sertifikayı, üretim boyunca oluşan kalite zincirinin son çıktısı olarak modelledim.

Önce canlı verinin gerçekte ne söylediğine baktım

Projenin başında bana iş emri kodlarının üretim sırasını verdiği söylendi.

Canlı veriyi incelediğimde bunun doğru olmadığını gördüm. Kodlar operasyon sırasını değil, planlamacının kayıtları sisteme eklediği sırayı taşıyordu.

Kalite planını bu varsayımla kursaydım operasyonlar yanlış sıralanacaktı.

Gerçek rota bilgisi başka bir sistemde zaten vardı. Planlanan sıra ile gerçekleşen sırayı ayrı kaynaklardan alıp karşılaştırdım. Böylece hem doğru rotayı buldum hem de müşteriden istenmesi düşünülen yeni bir API geliştirmesine gerek kalmadı.

Bu proje boyunca mümkün olduğunca aynı yöntemi kullandım:

Önce varsayımı belirledim. Sonra canlı veride ölçtüm. Sonuç tutmuyorsa veri modelini değiştirdim.

MES'te ürün kavramını yeniden kurmam gerekti

Canlı sistemde 36 binden fazla ürün kaydı görünüyordu.

Fakat bunların büyük kısmı gerçek birer ana ürün değildi. Aynı ürünün her operasyon adımı ayrı ürün kaydı olarak tutulmuştu.

Bu yapı üretim takibi için çalışıyordu ancak ürün seviyesinde kalite planı hazırlamaya uygun değildi. Kalite tarafında şu ilişkiye ihtiyacım vardı:

Bir ana ürün
  → bir veya daha fazla üretim rotası
  → revizyonlu kalite kontrol planı
  → ürüne ait PFMEA
  → ilgili standart ve sınıf sınırları

Operasyon kayıtlarının köklerinden 4.919 ana ürün oluşturdum.

Bunların üzerine 4.440 ürün kalite profili, 6.013 iş akışı ve 3.931 kalite kontrol planı kuruldu. Her ürünün PFMEA kaydı da diğer ürünlerden ayrıldı.

Bu geçiş çalışan canlı veri üzerinde yapıldı. Migration scriptlerini idempotent ve dry-run destekli hazırladım. Önce neyin değişeceğini ölçtüm, sonra uyguladım. Yarım kalan bir işlem tekrar çalıştırıldığında aynı kaydı ikinci kez üretmemesi gerekiyordu.

Sistemi durdurmadan ürün bazlı kalite modeline geçtik.

Sertifikanın hangi kayda ait olduğu önemliydi

Bir sertifikayı satış siparişine bağlamak ilk bakışta mantıklı görünüyor.

Ancak bir sipariş birkaç lotta üretilebilir. Parçalı sevk edilebilir. Aynı sevkiyatta farklı ürünler ve farklı hammadde lotları bulunabilir.

Müşterinin aldığı şey üretim emri değil, sevkiyattır.

Bu nedenle sertifikanın ana birimini sevk irsaliyesi ve irsaliyenin lot kalemleri olarak belirledim. Sertifika numarası da sistem tarafından uydurulmuyor. Kaynağını gerçek sevkiyat kaydından alıyor.

Bu karar sayesinde sistem şu durumları ayrı ayrı yönetebiliyor:

• aynı siparişin farklı tarihlerde sevk edilmesi,
• bir sevkiyatta birden fazla ürün bulunması,
• aynı ürünün farklı hammadde lotlarından gelmesi,
• birden fazla kalemin tek müşteri belgesinde gösterilmesi.

Belgedeki her satırın arkasında hangi sevkiyat, lot, laboratuvar ve üretim kaydından geldiği görülebiliyor.

QMS modülünün içinde neler var?

Ortaya yalnızca bir sertifika ekranı çıkmadı.

Modül şu süreçleri kapsıyor:

• hammadde ve ticari ürün girdi kontrolü,
• laboratuvar talepleri, sonuç girişi ve onay,
• ürün bazlı iş akışları ve kalite kontrol planları,
• PFMEA risk puanına bağlı numune planları,
• üretim istasyonlarında kiosk üzerinden ölçüm girişi,
• SPC takibi,
• son boyutsal ve görsel kontrol,
• paketleme ve sevkiyat,
• EN 10204 Type 3.1 sertifika hazırlama ve yayınlama,
• belge revizyonları ve müşteri doküman erişimi.

Bazı parçalar yeni bir kalite mikroservisinde çalışıyor. ERP ve diğer kalite kaynaklarıyla iletişim ayrı bir entegrasyon servisi üzerinden yapılıyor.

Arayüz tarafında sekiz ana ekran ve saha kiosku geliştirdim. Mevcut matbu kalite formları dijital çıktıya çevrildi. Sertifikalar aynı veri kümesinden farklı tasarımlarla ve altı dilde üretilebiliyor.

Eksik veriyi gizlememek önemliydi

Bir sertifika ekranında boş alan görmek kullanıcı için rahatsız edici.

En kolay çözüm o alanı elle doldurmaya izin vermek. Fakat bu, belgenin görünüşünü düzeltirken izlenebilirliği bozabiliyor.

Bir kimyasal analiz değeri eksikse sorun sertifika ekranında değildir. İlgili hammadde lotunun onaylanmış laboratuvar sonucu eksiktir.

Bu yüzden her verinin sahibini açık tuttum:

• müşteri ve miktar sevkiyattan,
• hammadde lotu üretim ve ERP kayıtlarından,
• kimyasal ve mekanik değerler onaylanmış laboratuvar sonucundan,
• boyutsal ve görsel kontroller üretim veya son kontrolden,
• sertifika numarası irsaliyeden geliyor.

Eksik bir değer olduğunda sistem kullanıcıya hangi kaynağın tamamlanması gerektiğini gösteriyor. Aynı bilginin başka bir ekranda tekrar girilmesini istemiyor.

Kalite yazılımında boş bir alan, kaynağı belli olmayan uydurma bir değerden daha güvenli.

Revizyon geçmişi sonradan eklenemez

QMS tarafındaki en önemli konulardan biri geçmişi korumaktı.

Bir ölçüm, laboratuvar onayı veya yayınlanmış sertifika düzeltildiğinde eski kayıt silinmiyor. Yeni bir revizyon oluşuyor.

Üretim planı oluşturulduğu anda hangi kalite dokümanı revizyonundan türetildiyse onunla bağlantısını koruyor. Master doküman daha sonra değişse bile geçmiş üretim kaydı geriye dönük olarak değişmiyor.

Yayınlanmış bir sertifika düzenlendiğinde sertifika numarası korunuyor ancak yeni bir belge revizyonu oluşuyor. Önceki sürüm denetim izi olarak sistemde kalıyor.

Sistem yalnızca “şu anki değer nedir?” sorusuna cevap vermiyor.

Şunları da gösterebiliyor:

• değer hangi kaynaktan geldi,
• kim tarafından girildi,
• kim onayladı,
• hangi doküman revizyonu kullanıldı,
• müşteriye o tarihte hangi sürüm gönderildi.

Bu yapı standart bir CRUD ekranından daha fazla iş çıkardı ama QMS tarafında başka türlü güvenilir bir sistem kurulamazdı.

Her sevkiyat aynı kalite zincirinden geçmiyor

Normal üretimde tam akış kullanılabiliyor:

Hammadde
→ Laboratuvar
→ Üretim planı
→ Operatör ölçümleri
→ Son kontrol
→ Paketleme
→ Sevkiyat
→ Sertifika

Fakat ticari ürünlerde, eski siparişlerde veya acil sevkiyatlarda tam proses kaydı bulunmayabiliyor.

Bu durumları tamamen engelleseydim kullanıcılar tekrar Excel'e dönecekti.

Bu nedenle üç farklı yol tasarladım:

• numune seviyesinde tam izlenebilirlik sunan zincirli yol,
• son kontrol kaydı üzerinden ilerleyen standart yol,
• üretim kaydı beklenmeyen durumlar için direkt sertifika yolu.

Arayüz her yolun hangi kayıtları içerdiğini açıkça gösteriyor.

Hızlı yol var ama sistem bunu tam izlenebilirlik gibi göstermiyor. Buradaki kararım, süreci zorla bloke etmek yerine kullanılan yolun sınırlarını dürüstçe kaydetmek oldu.

Kullanıcının önüne sistemin iç durumlarını koymamak

İlk sürümlerde bir sertifika hazırlamak için birkaç ayrı adım vardı.

Belgeyi hazırla, dili seç, şablonu seç, düzenle, yayınla ve indir.

Teknik olarak her adımın karşılığı vardı. Kullanıcı açısından ise aynı işi tamamlamak için fazla tıklama vardı.

Canlı testlerde kalite ekibinden gelen bir cümle durumu net anlattı:

“Solda görüyorum, neden indiremiyorum?”

Haklılardı.

Akışı tek pencereye indirdim. Kullanıcı sertifikayı açıyor, basılacak belgeyi görüyor, gerekirse yalnızca o belgeye ait alanları düzenliyor, dili ve tasarımı seçip PDF'i indiriyor.

Yayın durumu, revizyon ve kayıt izi arka planda yönetiliyor.

Aynı dönemde en ağır liste ve sertifika sorgularını da yeniden çalıştım. Yaklaşık 30 saniyede açılan ekranları 1,5 saniye seviyesine indirdim.

Sahada kullanılan bir ekranda 30 saniye teknik bir detay değil. İnsanların sistemi kullanıp kullanmama kararını etkiliyor.

Sole engineer olarak nelerden sorumluydum?

Bu projede yalnızca backend veya frontend geliştirmedim.

Tek başıma yürüttüğüm işler şunlardı:

• üretim ve kalite ekipleriyle süreç analizi,
• canlı veri yapısının incelenmesi,
• domain ve veri modeli tasarımı,
• kalite mikroservisinin geliştirilmesi,
• ERP ve kalite sistemi entegrasyonları,
• React tabanlı ofis ve kiosk ekranları,
• PDF ve Excel raporları,
• altı dilde sertifika üretimi,
• veri temizleme ve migration scriptleri,
• rol, yetki, onay ve revizyon kuralları,
• gerçek üretim senaryolarıyla test,
• canlı sunucu kurulumu ve deployment,
• sahadaki ilk kullanımın takibi,
• kullanıcı eğitimi ve kullanım kılavuzu.

Bir alanın veritabanındaki anlamıyla laboratuvardaki veya müşteri belgesindeki anlamı her zaman aynı değildi.

Projenin bütün katmanlarında çalışmak bu farkları daha erken görmemi sağladı.

Sonuçları neyle doğruluyorum?

Bu projedeki rakamlar tahmin değil. Canlı veri ölçümleri, migration raporları, Git geçmişi, devreye alma kayıtları ve gerçek kullanıcı geri bildirimlerinden geliyor.

Kayıtlardaki bazı sonuçlar:

• 36.634 operasyon seviyesinde ürün kaydı ve 34.165 iş emri analiz edildi.
• 4.919 ana ürün oluşturuldu.
• 4.440 ürün kalite profili, 6.013 iş akışı ve 3.931 kalite kontrol planı üretildi.
• 118 standart ve mukavemet sınıfı spesifikasyonu kaynak standartlardan doğrulandı.
• Sekiz ana ekran, bir saha kiosku ve altı dilde sertifika çıktısı geliştirildi.
• Proje Git geçmişinde yaklaşık 600 commit ve 100'den fazla merge request bulunuyor.
• Gerçek ekranlar ve akışlarla 43 sayfalık kullanıcı kılavuzu hazırlandı.
• İlk gerçek sertifika canlıya alma gününde üretildi.
• Kalite ekibinin bildirdiği hazırlama süresi 4–5 saatten yaklaşık 15 dakikaya indi.
• Yaklaşık 30 saniyede açılan liste ekranları 1,5 saniye seviyesine getirildi.

Bu projede öğrendiğim en önemli şeyler

Bu projede en zor kısım kod geliştirmek değildi.

Zor olan, farklı departmanların aynı veriye verdiği farklı anlamları tek modelde doğru şekilde tutmaktı.

Benim için öne çıkan dersler şunlar oldu:

1. Canlı veride test edilmemiş varsayımla veri modeli kurulmaz.
2. İzlenebilirlik sertifika ekranında değil, zincirin başında başlamalıdır.
3. Hızlı bir yol varsa hangi kayıtları içermediği açıkça gösterilmelidir.
4. Eksik veri başka bir ekranda elle kopyalanmamalı, kendi kaynağında düzeltilmelidir.
5. Migration yalnızca veri taşımak değildir. Tekrar çalıştırılabilir ve ölçülebilir olmalıdır.
6. Kullanıcı sistemin iç fazlarını öğrenmek zorunda kalmamalıdır.

Bu projede analizden canlıya kadar tek mühendistim.

Yanlış veri modeli kursaydım arkasına saklanabileceğim başka bir ekip yoktu. Entegrasyon çalışmasaydı, ekran yavaş olsaydı veya belge yanlış veri üretseydi problemi yine benim çözmem gerekecekti.

Dört ayın sonunda yalnızca yeni bir özellik teslim etmedim.

Mevcut bir MES ürününün içine, gerçek üretim verisiyle çalışan ve ilk müşterisinde canlıya alınmış bir QMS modülü ekledim.