Müşteri resmi iki ay önce Rev.C'ye çıkmış. Delik çapının toleransı daralmış, bir de yüzey pürüzlülüğü şartı eklenmiş. Tezgâhın yanındaki kontrol planı ise hâlâ Rev.B; operatör eski toleransla ölçüyor ve her parça geçiyor. Değişiklik e-postası proje mühendisine gelmiş, o da resmi ortak klasöre atmış ve orada durmuş. Mühendislik değişikliği yönetimi denilen iş, tam olarak bu e-postanın durduğu noktadan sonra başlar.
Değişiklik tek bir doküman değil, bir zincirdir
Müşteri resmi zincirin ilk halkasıdır. Ondan sonra proses akış şeması, PFMEA, kontrol planı, çalışma talimatı, ölçüm talimatı, kontrol formu ve ambalaj talimatı gelir. Bir de görünmeyen halkalar vardır: mastar ve fikstür, hata yakalama düzeneğinin ayar değeri, operatör eğitim kaydı, ilk parça onay kriterleri. Bunların hepsi aynı revizyondan etkilenmez; ama hepsi bakılmalıdır.
Aradaki fark burada. Bakılmayan doküman ile bakılıp "etkilenmedi" kararı verilen doküman arasında dünya kadar mesafe var. Birincisi denetimde bulgu, ikincisi temiz bir kayıt. Zincirin tamamını listeleyip her satıra bir karar yazmak, günde on beş dakika süren ama üç haftalık karantinayı önleyen bir alışkanlık.
Zincirin bir de sessiz halkası var: müşterinin gönderdiği resmin kendisi. Çoğu firmada müşteri resimleri kontrollü doküman sayılmaz, ortak klasörde durur ve revizyon takibi yapılmaz. Oysa dış kaynaklı doküman olarak kayıt altına alınmaları, güncel revizyonlarının listelenmesi ve dağıtımlarının izlenmesi gerekir. Kaynak halka kontrolsüzse, ondan sonraki bütün halkalar da şansa kalır.
Zincirin haritasını çıkarın
Aşağıdaki tablo, bir pres-kaynak tesisinde kullandığımız etki haritasıdır. Sol kolon değişikliğin türünü, sağ kolonlar hangi dokümanların zorunlu olarak gözden geçirileceğini gösterir. Bunu bir kez hazırlayıp değişiklik formunun arkasına eklerseniz, her seferinde "başka ne etkilenir" diye düşünmek zorunda kalmazsınız.
| Değişiklik türü | Zorunlu gözden geçirilen | Karar sahibi | Tipik süre |
|---|---|---|---|
| Ölçü / tolerans değişimi | Kontrol planı, ölçüm talimatı, kontrol formu, mastar | Kalite mühendisi | 3 – 5 gün |
| Malzeme değişimi | PFMEA, kontrol planı, IMDS bildirimi, giriş kalite kriteri | Proje mühendisi | 2 – 4 hafta |
| Proses akışı değişimi | Akış şeması, PFMEA, kontrol planı, yerleşim, talimat | Proses mühendisi | 2 – 6 hafta |
| Yeni özel karakteristik | Kontrol planı, SPC planı, operatör eğitimi | Kalite müdürü | 1 – 2 hafta |
| Ambalaj değişimi | Ambalaj talimatı, etiket şablonu, sevkiyat kaydı | Lojistik | 1 hafta |
| Alt tedarikçi değişimi | Onaylı tedarikçi listesi, giriş kontrol planı, müşteri bildirimi | Satın alma + kalite | 4 – 8 hafta |
Tablodaki en kritik satır sonuncusu. Alt tedarikçi değişimi çoğu firmada satın almanın iç işi sayılır ve kaliteye haber bile verilmez; oysa müşteri gözünde bu, bildirim gerektiren bir değişikliktir. Kontrol planının her revizyonunda "bu değişiklik hangi kayıttan geliyor" sorusunun cevabı yazılı olmalı.
Haritayı çıkarırken ikinci bir kolon daha ekleyin: müşteri bildirimi gerekir mi? Bu soruyu her satır için önceden cevaplarsanız, değişiklik geldiğinde tartışma yaşanmaz. Kararı müşterinin özel şartlarına dayandırın ve dayanağı kolonun içine yazın. "Kaliteye sorulur" yazan bir satır, pratikte "kimse sormaz" demektir.
E-posta neden yetmiyor?
E-posta bir bildirim aracıdır; takip aracı değildir. Kime gönderildiğini gösterir, kimin ne yaptığını göstermez. Gelen kutusunda bekleyen bir bildirimin sahada karşılığı yoktur. Üstelik e-postada zincir görünmez: kontrol planı güncellendi mi, talimat basıldı mı, eski nüshalar geri toplandı mı — hiçbiri e-postadan okunmaz.
Çözüm karmaşık değil. Her müşteri bildirimi bir kayıt numarası alır, o kaydın altında etkilenen dokümanlar satır satır listelenir ve her satırın bir sorumlusu ile termini olur. Zincir, bütün satırlar kapandığında kapanır. Açık kalan tek bir satır bile değişikliğin sahaya yansımadığını gösterir. Bu mantığı kurmadan yapılan mühendislik değişikliği yönetimi, bir insanın hafızasına bağlı kalır.
Değişiklik bildirim formunda ne bulunmalı?
Formu sadeleştirin ama şu alanları çıkarmayın: değişikliğin kaynağı (müşteri, iç iyileştirme, tedarikçi, DÖF), müşteri doküman numarası ve revizyonu, değişikliğin özeti, etkilenen parça numaraları, müşteri onayı gerekip gerekmediği, yürürlük tarihi ve kesme noktası, etkilenen doküman listesi ve stok kararı. Sekiz alan. Bundan uzun formlar doldurulmuyor, bundan kısası ise takip edilemiyor.
Etkilenen doküman listesini boş bırakılabilir bir alan yapmayın; formun çekirdeği odur. Her satırın yanına "güncellendi / etkilenmedi / beklemede" seçeneği koyun. PFMEA satırının "etkilenmedi" işaretlendiği durumlarda gerekçe isteyin — tolerans daraldıysa tespit derecesi genelde değişir ve bu satır çoğu zaman haksız yere atlanır.
Ayda bir, sahadan rastgele üç kontrol planı fotoğrafı çekin ve revizyon numaralarını sistemdeki güncel revizyonla karşılaştırın. On dakika sürer. Bunu bir yıl boyunca yaptığım bir tesiste ilk üç ayda sekiz uyumsuzluk çıktı; sonraki dokuz ayda hiç çıkmadı. Sebep yazılım değildi — ekip artık kontrol edileceğini biliyordu. Ölçülen şeyin düzelmesi, kalitede en eski ve en ucuz kuraldır.
Yürürlük tarihi ve kesme noktası
Değişikliğin ne zaman geçerli olacağı bir takvim kararı değil, stok kararıdır. Elinizde eski revizyona göre üretilmiş 4.000 adet yarı mamul varsa, "1 Ağustos'tan itibaren yeni revizyon" demek işi çözmez; o gün üretilen ama eski stoktan beslenen parçalar ne olacak? Kesme noktasını lot numarasıyla tanımlayın: "LT-26-0714 numaralı lottan itibaren Rev.C geçerlidir." Böylece sevkiyat kaydına bakan herkes hangi parçanın hangi revizyonla üretildiğini görebilir.
Stok kararını da yazın. Eski revizyon stoku hurdaya mı gidecek, müşteri sapma izniyle mi kullanılacak, yeniden mi işlenecek? Bu üç seçenekten hangisi seçilirse seçilsin karar kayda geçmeli, çünkü altı ay sonra maliyet tartışması çıktığında herkes başka bir şey hatırlıyor. Müşteri onayı gerektiren değişikliklerde ise yürürlük tarihi, onay tamamlanmadan belirlenemez; PPAP tarafındaki bildirim ve yeniden sunum şartlarını atlamak, sonradan yazılan uzun açıklama mektuplarının bir numaralı sebebidir.
Bir de tersine bakın: müşteri bildirimi olmadan sizin yaptığınız değişiklikler. Kalıp tamiratından sonra ölçü değişmiş, tedarikçi bobin genişliğini değiştirmiş, boya tedarikçisi formülünü güncellemiş olabilir. Bunların hiçbiri size resmi bir bildirimle gelmez; sahadan duyulur. Bu yüzden değişiklik kaydını açma yetkisini yalnızca proje mühendisine vermeyin, üretim ve bakım da açabilsin. Kayıt açmanın önündeki her engel, kayıtsız değişiklik üretiyor.
Devreye alırken ilk parçayı yeniden onaylayın
Değişiklik yürürlüğe girdiği vardiyada üretilen ilk parça, sıradan bir ilk parça değildir. Yeni revizyona göre ölçülmesi, kaydının değişiklik numarasıyla birlikte tutulması ve onaylanmadan seri üretime geçilmemesi gerekir. Bunu atlayan tesislerde en sık yaşanan olay şudur: kontrol planı güncellenmiştir, talimat basılmıştır, ama tezgâhtaki ölçü ayarı hâlâ eskidir ve ilk iki saatlik üretim eski toleransla çıkar.
İlk parça formuna küçük bir alan ekleyin: "değişiklik kaydı numarası". Boşsa rutin ilk parça, doluysa değişiklik doğrulamasıdır. Bu tek alan sayesinde altı ay sonra "bu revizyon sahada ne zaman gerçekten başladı" sorusuna kayıtla cevap verebilirsiniz. Aynı kaydı müşteri sorduğunda da doğrudan gönderirsiniz; e-posta arşivinde arama yapmak zorunda kalmazsınız.
Eski revizyona göre üretilmiş kontrollü kopyaların geri toplanması da bu aşamada yapılır. Yeni talimatı asmak yetmez; eskisinin panodan, klasörden ve operatörün önlük cebinden çıkması gerekir. Geri toplama kaydı tutulmayan tesislerde iki revizyon aylarca yan yana yaşıyor ve hangisinin geçerli olduğunu vardiyaya göre değişen cevaplar belirliyor.
Değişiklik yoğunluğunu ölçün
Mühendislik değişikliği yönetimini iyileştirmenin en hızlı yolu, onu ölçmeye başlamaktır. Üç sayı yeter: ayda kaç değişiklik bildirimi geldi, ortalama kaç günde kapandı, kaç tanesi terminini aştı. Bu üç sayıyı bir yıl boyunca izleyen bir tesiste, gecikmelerin neredeyse tamamının tek bir kaynaktan geldiğini gördük — dış proses talimatları, çünkü onları güncellemek taşeronla yazışma gerektiriyordu ve kimse o süreyi plana koymamıştı.
| İzlenen sayı | Nereden çıkar | Ne zaman alarm verir |
|---|---|---|
| Aylık bildirim adedi | Açılan değişiklik kayıtları | Kişi başına düşen adet iki katına çıktığında |
| Ortalama kapanma süresi | Kayıt açılış – son satırın kapanışı | Süre üç ay üst üste uzadığında |
| Termini aşan satır oranı | Etkilenen doküman satırları | Oran onda biri geçtiğinde |
| En çok geciken doküman tipi | Gecikmiş satırların kırılımı | Aynı tip iki çeyrek üst üste başta olduğunda |
Ölçmenin ikinci faydası kapasite tartışmasını gerçekçi kılıyor. Ayda yirmi değişiklik bildirimi gelen bir firmada tek bir proje mühendisinin bu işi yürütmesi mümkün değildir; sayı masaya konduğunda tartışma "daha dikkatli olalım"dan çıkıp kaynak planlamasına dönüşür. Yönetim gözden geçirme toplantısına bu üç sayıyı götürün, tek tek olayları değil.
Üçüncü faydası ise denetim tarafında. Bir denetçi değişiklik yönetimini sorduğunda elinizde işleyen bir liste olması, tek tek dosya açıp göstermekten çok daha güçlü bir kanıttır. Açık kalan satır varsa bile, o satırın termininin ve sorumlusunun belli olması sistemin çalıştığını gösterir; asıl kötü tablo, hiç listenin olmamasıdır.
QDMS tarafında zinciri kurmak
Türkiye'de doküman yönetim yazılımları çoğu zaman QDMS adıyla anılıyor; QDMS aslında Bimser'in ürün adı ve pazarda köklü bir yeri var. Ürün adı ne olursa olsun, değişiklik takibinde aradığınız üç yetenek aynı: dokümanlar arasında ilişki kurabilmek, bir değişiklik kaydına birden fazla dokümanı görev olarak bağlayabilmek ve yürürlüğe girme anında eski revizyonu otomatik olarak yürürlükten kaldırabilmek.
Üçüncüsü en çok atlanan yetenek. Yeni revizyon yayınlandığında eskisi kendiliğinden arşive düşmüyorsa, sahada iki revizyon aynı anda geçerli görünür ve operatör hangisine bakacağını bilemez. Onay akışının nasıl kurulacağını doküman onay iş akışı yazımızda ayrıntılı anlattık. PaKalite'yi kurarken değişiklik kaydını doküman revizyonunun üstüne oturttuk; etkilenen doküman listesindeki her satır kendi sorumlusuna görev olarak düşüyor. Bu mantığı kâğıt üzerinde de kurabilirsiniz — şart olan tek şey, zincirin tek bir kayıt numarası altında toplanması.
Zinciri kıran üç alışkanlık
Birincisi değişikliği tek kişiye emanet etmek. Proje mühendisi izne çıktığında zincir duruyor. İkincisi eğitim halkasını atlamak: doküman güncelleniyor, operatöre kimse söylemiyor. Yeni bir ölçüm noktası eklendiyse operatörün bunu okumuş ve anlamış olduğunun kaydı gerekir; okundu teyidi bunun için var.
Üçüncüsü ve en pahalısı, değişikliğin etkinliğini doğrulamamak. Kontrol planını güncellediniz, talimatı bastınız, eğitimi verdiniz — peki iki hafta sonra sahaya gidip yeni ölçümün gerçekten yapıldığını kim kontrol etti? Katmanlı proses denetimi soru listesine son üç değişikliği eklemek, bu doğrulamayı kendiliğinden yaptırır ve doküman yönetimi ile saha arasındaki boşluğu kapatır.
Denetçi mühendislik değişikliği yönetimini genelde tersten yoklar. Sahadan bir kontrol planı alır, üzerindeki revizyon tarihine bakar ve "bu revizyon neden çıktı" diye sorar. Cevap bir müşteri bildirimine dayanmalı, o bildirimin numarası kontrol planında ya da değişiklik kaydında görünmeli. Sonra aynı bildirimden etkilenen diğer dokümanları ister; biri güncellenmemişse zincirin kapanmadığı orada anlaşılır. İyi hazırlanmış bir değişiklik kaydı, bu üç soruyu tek ekranda bitirir.
Dördüncü bir hata daha var ve bu kalite biriminin kendi ürettiği bir sorun: değişikliği yalnızca müşteriden gelenlerle sınırlı saymak. İç iyileştirmeler, DÖF sonrası yapılan proses değişiklikleri, kalıp tamiratları ve yeni bir hata yakalama düzeneğinin devreye alınması da birer mühendislik değişikliğidir ve aynı zincire girer. İç kaynaklı bir değişikliğin kontrol planına yansımaması, müşteri kaynaklı olanın yansımamasıyla aynı bulguyu doğurur.
Nereden başlanır?
Bugüne kadar birikmiş değişiklikleri geriye dönük düzeltmeye çalışmayın; altından kalkamazsınız. Son altı ayın müşteri bildirimlerini alın, her biri için etkilenen doküman listesini bir kez çıkarın ve açık kalanları kapatın. Bundan sonrası için de tek kural koyun: müşteriden gelen her doküman revizyonu, bir değişiklik kaydı açılmadan klasöre atılmayacak. Bu tek kural, mühendislik değişikliği yönetimini kişiye bağlı olmaktan çıkarıp sisteme bağlar. Gerisi zaten kendiliğinden yürür.