Üretim Sistemlerinde Değişiklik Yönetimi: MES, PLC ve Reçete

PLC programına eklenen tek satır, reçetede değiştirilen bir sıcaklık değeri ya da MES’te kapatılan bir zorunlu kontrol adımı, ofisteki bir sunucu güncellemesinden çok daha doğrudan ürün kalitesine dokunur. Buna rağmen çoğu tesiste bu değişiklikler ne BT değişiklik sürecine ne de kalitenin proses değişikliği sürecine tam olarak girer. Bakımcı gece müdahale eder, hat çalışır, kayıt açılmaz. Aşağıda MES, PLC, makine reçetesi ve test yazılımı değişikliklerini IATF 16949’un proses değişikliği ve ürün onayı gereklilikleriyle bağlayan, sahada işleyen bir süreci adım adım kuruyoruz.

Üretim sistemlerinde değişikliğin kapsamı

İlk iş, neyin “değişiklik” sayıldığını yazıya dökmektir. Yazılı tanım yoksa herkes kendi tanımını kullanır. Aşağıdaki nesnelerin her biri ürün karakteristiğini veya proses kontrolünü etkileyebilir:

• PLC ve robot programları: mantık, zamanlayıcı ve sayaç değerleri, emniyet ve kilitleme koşulları, robot yörüngeleri.
• Makine reçeteleri ve parametre setleri: sıcaklık, basınç, süre, tork, hız gibi proses parametreleri ve izin verilen aralıkları.
• HMI/SCADA yapılandırması: alarm sınırları, operatöre açık ayarlar, yetki seviyeleri.
• MES yapılandırması: iş akışı adımları, zorunlu kontroller, ürün-reçete eşlemesi, etiket şablonları, kalite kilit kuralları.
• Test ve muayene yazılımları: limit değerleri, test sırası, geçti/kaldı mantığı.
• Altyapı: HMI veya istasyon PC’sinin işletim sistemi yaması, ağ değişiklikleri, sunucu taşımaları.

Altyapı değişiklikleri ürün karakteristiğini nadiren doğrudan etkiler, ama hat duruşuna ya da veri kaybına yol açabilir. Hücre switch’indeki bir VLAN değişikliği PLC ile MES arasındaki bağlantıyı koparır, hat “MES yanıt vermiyor” alarmıyla durur. Bu yüzden altyapı kapsamda kalır. Yalnızca sınıfı farklıdır.

IATF proses değişikliği ile BT değişiklik süreci arasındaki bağ

IATF 16949’un 8.5.6.1 maddesi (değişikliklerin kontrolü – ek), ürün gerçekleştirmeyi etkileyen değişikliklerin kontrolü için dokümante bir süreç ister. Bu süreç değişikliğin etkisinin değerlendirilmesini, doğrulama ve geçerli kılma faaliyetlerinin tanımlanmasını, değişikliğin uygulamadan önce geçerli kılınmasını, risk analizinin kanıtlanmasını ve doğrulama/geçerli kılma kayıtlarının saklanmasını içerir. Müşteri gerektiriyorsa değişiklik müşteriye bildirilir ve onay alınır. 8.5.6.1.1 ise proses kontrollerinin geçici değişikliğini (örneğin bir hata önleme cihazının devre dışı kalıp alternatif kontrol yöntemine geçilmesi) ayrıca düzenler.

BT tarafında genellikle ITIL tabanlı bir değişiklik süreci vardır: talep, etki analizi, onay kurulu, uygulama, gözden geçirme. BT ve bilgi güvenliği uyumu açısından asıl sorun, iki sürecin birbirinden habersiz çalışmasıdır. Aynı değişiklik iki yerde açılır ya da hiçbir yerde açılmaz. Çözüm tek giriş noktasıdır:

• Üretim sistemlerine yönelik her değişiklik tek kayıtla açılır (BT değişiklik aracında veya kalite sisteminde, ama yalnız birinde).
• Kayıtta “ürün/proses etkisi var mı?” zorunlu alandır ve proses mühendisliği tarafından cevaplanır.
• Etki varsa kayıt kalitenin proses değişikliği akışına bağlanır; PFMEA ve kontrol planı güncelleme ihtiyacı değerlendirilir.
• Etki yoksa BT değişiklik süreci yeterlidir, ama bu karar ve gerekçesi kayıtta kalır.

BT değişikliklerinin denetimde nasıl kanıtlandığı ayrı bir konu; talep, onay ve test kaydının yapısı için değişiklik yönetimi denetim kanıtı yazısına bakın. Burada üretim sistemlerine özgü akışa odaklanıyoruz.

Değişiklik sınıflandırma karar ağacı

Her değişikliği aynı ağırlıkta ele alırsanız süreç tıkanır. Bakım ekibi ve operatörler bir hafta sonra süreci atlamaya başlar; haksız da sayılmazlar. Sınıflandırma, gereken onay ve doğrulama derinliğini belirler. Aşağıdaki karar ağacı bir başlangıç örneğidir:

1. Değişiklik bir ürün karakteristiğini, özel karakteristiği veya kontrol planındaki bir kontrolü etkiliyor mu? Evet ise Sınıf A: proses değişikliği, PFMEA/kontrol planı incelemesi, deneme üretimi ve müşteri bildirimi değerlendirmesi.
2. Hayır ise, proses parametresini onaylı aralığın dışına taşıyor mu ya da yeni bir parametre ekliyor mu? Evet ise Sınıf A’ya yükselir.
3. Hayır ise, onaylı aralık içinde bir ayar mı? Evet ise Sınıf B: yetkili kişi onayı ve kayıt yeterlidir; reçete değişiklik geçmişi bu kaydı oluşturur.
4. Hayır ise, ürün etkisi olmayan bir yazılım veya altyapı değişikliği mi? (Örneğin HMI ekran düzeni, işletim sistemi yaması.) Evet ise Sınıf C: BT değişiklik süreci, fonksiyon testi ve geri dönüş planı. Hiçbir soruya net “evet” verilemiyorsa değişiklik Sınıf A gibi ele alınır ve sınıflandırma kararını proses mühendisliği verir.

Acil değişiklik ayrı bir sınıf değildir; aynı ağacın farklı zamanlamayla işletilmesidir. Arıza müdahalesinde değişiklik önce uygulanır, en geç bir sonraki iş gününde kayıt açılır ve yukarıdaki sorularla geriye dönük sınıflandırılıp onaylanır. Sonuç Sınıf A çıkarsa müdahale süresince üretilen parçalar ayrıca değerlendirilir. Acil yolun kötüye kullanılıp kullanılmadığını görmek için aylık acil değişiklik sayısını ve geriye dönük onayı geciken kayıtları izleyin. Acil değişiklik sayısı her ay artıyorsa sorun süreçte değil, planlamadadır.

Sınıf B’nin dayanağı “onaylı aralık” kavramıdır. Kontrol planı ve proses parametre sayfası her parametre için alt ve üst sınırı tanımlamalı. Bu sınırlar MES veya HMI’da teknik olarak zorlanırsa operatör aralık dışına değişiklik sürecine girmeden çıkamaz. Sınır yalnız kâğıtta yazılıysa, sahada yoktur.

PLC program ve reçete sürüm arşivi

Değişiklik sürecinin en zayıf halkası çoğu zaman sürüm arşividir. “Makinedeki program” ile “sunucudaki son yedek” aynı mı, kimse bilmez. Arıza anında yanlış sürüm yüklenir, hat bir sonraki vardiyada eski hatayla tekrar durur. Aşağıdaki tablo farklı yaklaşımları karşılaştırır:

Yaklaşım	Avantaj	Sınırlama
Dosya sunucusunda klasör	Basit, ek maliyet yok	Sahadaki programla karşılaştırma yok; disiplin gerekir
Git vb. sürüm kontrol sistemi	Fark görme, geçmiş, imzalı kayıt	İkili PLC proje dosyalarında fark okunamaz
Endüstriyel sürüm yönetimi yazılımı	Cihazdan otomatik yedek ve karşılaştırma	Lisans maliyeti, cihaz uyumluluğu kontrolü
MES içinde reçete yönetimi	Ürüne bağlı reçete, onay akışı	Yalnız MES’in yönettiği parametreleri kapsar

Araç ne olursa olsun şu ilkeler değişmez: her makine ve kontrolör için tek bir “onaylı sürüm” tanımlıdır; onaylı sürüm değişiklik kaydı numarasıyla ilişkilendirilir; sahadaki program periyodik olarak cihazdan okunup onaylı sürümle karşılaştırılır. Siemens, Rockwell gibi üreticilerin mühendislik yazılımları proje karşılaştırma işlevi sunar. Birden fazla üreticinin cihazlarından oluşan bir hatta ise cihazdan otomatik yedek alıp fark raporu üreten üretici bağımsız araçlar tercih edilebilir.

Metin tabanlı reçete veya parametre dosyaları için Git iyi çalışır. Basit bir iş akışı örneği:

# Değişiklik kaydı numarasıyla bir dal aç
git switch -c CR-2025-0142-pres3-sicaklik

# Reçete dosyasını düzenle, farkı gözden geçir
git diff recete/PRES3/urun-4711.csv

# Değişiklik kaydı numarasını içeren açıklamayla kaydet
git commit -am "CR-2025-0142: PRES3 4711 kalıp sıcaklığı 185->190 C (onaylı aralık 180-195)"

# Onay sonrası ana dala al ve etiketle
git switch main
git merge --no-ff CR-2025-0142-pres3-sicaklik
git tag -a PRES3-4711-r12 -m "Devreye alma onayı: CR-2025-0142"

Commit mesajındaki değişiklik kaydı numarası, denetimde Git geçmişi ile değişiklik kaydını birbirine bağlayan tek iptir. Onu boş bırakmayın. Ağ cihazlarının konfigürasyon yedeği ve fark takibi için benzer yaklaşım Oxidized ile konfigürasyon yedekleme yazısında anlatılıyor; mantık üretim hücresindeki switch’ler için de geçerli.

Doğrulama ve devreye alma onayı

8.5.6.1, değişikliğin uygulamadan önce geçerli kılınmasını ister. Üretim sistemlerinde bu, sınıfa göre farklı derinlikte bir devreye alma kontrolüdür:

• Sınıf A: deneme üretimi, ilk parça onayı, ilgili karakteristiklerin ölçümü, gerekiyorsa proses yeterlilik çalışması; hata önleme cihazlarının doğrulanması.
• Sınıf B: ilk parça kontrolü ve reçete değerinin MES/HMI’da doğru yüklendiğinin teyidi.
• Sınıf C: fonksiyon testi; ölçüm veya test yazılımı etkileniyorsa yazılım doğrulaması.

Her sınıfta geri dönüş planı yazılır: önceki sürüm arşivde hangi etiketle duruyor, geri yüklemeyi kim yapıyor, ne kadar sürüyor? Bu sorulara cevap yoksa değişiklik başlamaz. Test ve ölçüm yazılımlarında yeniden doğrulama gerekliliğini ölçüm ve test yazılımlarının doğrulanması yazısı ayrıntılı ele alır.

Müşteri bildirimi gerektiren değişiklikler

Hangi değişikliğin müşteriye bildirileceğini son tahlilde müşterinin özel gereklilikleri (CSR) ve PPAP gereklilikleri belirler. AIAG tarafından yayımlanan PPAP el kitabı, bildirim gerektiren durumlara örnek olarak farklı malzeme veya yapı kullanımı, yeni veya değiştirilmiş takımlarla üretim, takımın başka bir tesise taşınması, alt tedarikçi değişikliği, uzun süre kullanılmayan takımla üretime yeniden başlama ve muayene/test yönteminde yeni teknik kullanımı gibi başlıklar sayar. Güncel ve eksiksiz liste için kendi müşterinizin uyguladığı PPAP baskısını ve CSR’ını esas alın.

BT ve otomasyon tarafında pratik sonuçlar şunlar:

• Test standı veya muayene yazılımında test yönteminin değişmesi, kabul kriterleri aynı kalsa bile bildirim gerektirebilir.
• Bir hattın PLC programının başka tesisteki aynı tip makineye taşınması, proses taşıma kapsamında değerlendirilebilir.
• Bir hata önleme kontrolünün yazılımla kaldırılması veya devre dışı bırakılması, geçici olsa bile 8.5.6.1.1 kapsamında yönetilir.

Son madde sahada en çok sorun çıkaranıdır. Sensör arızalanır, bakımcı PLC’de bit’i köprüler, hat çalışmaya devam eder. Köprü haftalarca kalır. CSR’ların BT süreçlerine etkisi daha geniş bir konu; müşteri özel gereklilikleri ve BT yazısı CSR’lardan BT aksiyonu çıkarma yöntemini anlatır.

Örnek değişiklik kaydı

Aşağıdaki alanlar bir reçete değişikliği için tutulan kaydın asgari içeriğine örnektir:

Alan	Örnek içerik
Kayıt no	CR-2025-0142
Nesne	PRES3, ürün 4711 reçetesi
Değişiklik	Kalıp sıcaklığı 185 → 190 °C
Gerekçe	Yüzey kusuru DÖF kaydına bağlı iyileştirme
Sınıf	B (onaylı aralık 180–195 °C içinde)
Etki değerlendirmesi	PFMEA ve kontrol planı değişmez; proses mühendisi onayı
Doğrulama	İlk 5 parça yüzey kontrolü, ölçüm kaydı eki
Sürüm	Önceki r11, yeni r12; arşiv etiketi
Geri dönüş	r11 yüklenir, sorumlu: bakım vardiya amiri
Müşteri bildirimi	Gerekli değil; gerekçe CSR madde referansıyla

Bu kayıt, denetçinin sahada rastgele seçtiği bir makinedeki programla eşleştirilebilmeli. Denetçi HMI’daki reçete revizyonunu okur, siz arşivdeki etiketi ve değişiklik kaydını gösterirsiniz. Eşleşmiyorsa bulgu oradadır. Değişiklik ve konfigürasyon süreçlerini üretim ortamına uyarlamak için değişiklik, konfigürasyon ve yama yönetimi ve üretim tesislerinde IT/OT uyum hizmetlerimize göz atabilirsiniz.

Sık sorulan sorular

Operatörün HMI’dan yaptığı parametre ayarı değişiklik sürecine girer mi?

Onaylı aralık içindeki ayar için ayrı değişiklik kaydı gerekmez; ama ayarı kimin, ne zaman, hangi değerden hangi değere yaptığı sistemde kayıtlı olmalıdır. Onaylı aralığın dışına çıkış teknik olarak engellenmeli ve proses değişikliği sürecine yönlendirilmelidir.

Acil arıza müdahalesinde değişiklik süreci nasıl işletilir?

Değişiklik önce uygulanır, en geç bir sonraki iş gününde kayıt açılır ve geriye dönük sınıflandırma yapılır. Değişiklik ürün karakteristiğini etkiliyorsa müdahale süresince üretilen parçalar ayrıca değerlendirilir.

PLC programlarını Git ile yönetmek yeterli mi?

Arşiv ve geçmiş için işe yarar, ama çoğu PLC proje dosyası ikili formatta olduğundan farkı Git’te okuyamazsınız. Fark analizi için üreticinin mühendislik yazılımındaki karşılaştırma işlevi veya endüstriyel sürüm yönetimi araçları gerekir. Sahadaki programın arşivle periyodik karşılaştırılması ise ayrı bir kontroldür.

Her yazılım değişikliği müşteriye bildirilmeli mi?

Hayır. Bildirim gerekliliğini müşterinin özel gereklilikleri ve PPAP kuralları belirler. Ürün karakteristiğini, proses yöntemini veya test tekniğini değiştiren değişiklikler genellikle bildirim gerektirir; ürün etkisi olmayan altyapı değişiklikleri genellikle gerektirmez. Karar ve gerekçesi her durumda kayıtta tutulur.