Anasayfa  /  Blog  /  Uyumluluk

AS9100'de Konfigürasyon Yönetimi ve Mühendislik Değişiklik Kontrolü

Mühendislik değişikliklerinin üretime kontrolsüz yansıması uygunsuzluk ve teslimat riski doğurur. AS9100 konfigürasyon yönetimini ERP'de adım adım kurmanın yolu.

Savunma sanayi ve havacılık projelerinde bir ürün, ilk teslimattan son teslimata kadar çoğu zaman birden fazla mühendislik değişikliğinden geçer. Bir ölçü toleransı daraltılır, bir malzeme muadiliyle değiştirilir, bir montaj sırası güncellenir. Bu değişikliklerin her biri tek başına küçük görünebilir; ancak hangi parçanın hangi revizyona göre üretildiği, hangi stokun hâlâ kullanılabilir olduğu ve müşteriye teslim edilen ürünün onaylı tasarımla birebir örtüşüp örtüşmediği sorularına net cevap verilemediğinde, sorun artık mühendislik değil uyumluluk sorunudur. AS9100 gereklilikleri bu nedenle konfigürasyon yönetimini kalite sisteminin temel unsurlarından biri olarak ele alır. Bu yazıda konfigürasyon yönetiminin ERP üzerinde nasıl kurgulanacağını, değişiklik akışının hangi adımlardan oluşması gerektiğini ve sık yapılan hataları ele alıyoruz.

Özet

Konfigürasyon yönetimi, ürünün tanımlandığı teknik verilerin (çizim, ürün ağacı, rota, spesifikasyon) kontrollü biçimde değiştirilmesini ve her üretilen birimin hangi onaylı tanıma göre üretildiğinin kanıtlanabilmesini sağlar. ERP'de bunun için revizyon kontrollü ana veri, resmi bir değişiklik talebi ve onay akışı, açık iş emirleri ile stoklar üzerinde yapılan etki analizi ve değişikliğin geçerlilik noktasının açıkça tanımlanması gerekir. Değişikliği yalnızca mühendislik dokümanında güncelleyip üretim, satın alma ve depo tarafına sistematik olarak yansıtmamak, en yaygın uygunsuzluk kaynaklarından biridir.

1. Konfigürasyon Yönetimi Neden Bir ERP Konusudur

Birçok kuruluşta konfigürasyon yönetimi mühendislik biriminin sorumluluğunda görülür ve doküman yönetim sistemi ya da paylaşımlı klasörler üzerinden yürütülür. Oysa bir mühendislik değişikliğinin gerçek etkisi üretim sahasında, depoda ve tedarik zincirinde ortaya çıkar. Çizim güncellendiği hâlde ERP'deki ürün ağacı eski revizyonda kalıyorsa, planlama eski malzemeyi sipariş eder, üretim eski rotaya göre çalışır ve kalite eski kontrol planıyla muayene yapar.

Bu nedenle konfigürasyon yönetimi, teknik verinin tek bir doğru kaynaktan yönetildiği ve bu verinin iş emirlerine, satın alma siparişlerine ve muayene kayıtlarına bağlandığı bir yapı gerektirir. ERP, bu bağlantıyı kuran sistemdir. Mühendislik tarafındaki doküman sistemi ayrı kalabilir; ancak onaylı revizyonun ERP'ye aktarılması ve ERP'deki operasyonel kayıtların bu revizyona referans vermesi zorunludur.

2. Temel Yapı Taşları

Konfigürasyon öğesi

Konfigürasyon öğesi, bağımsız olarak tanımlanan, izlenen ve değişikliği kontrol edilen ürün veya alt montajdır. Her parçanın konfigürasyon öğesi olarak ele alınması gerekmez; müşteri sözleşmesi, ürünün kritikliği ve bakım gereksinimleri hangi seviyede kontrol yapılacağını belirler. Bu kararın baştan verilip belgelenmesi, ileride gereksiz bürokrasiyi ya da kontrol boşluklarını önler.

Revizyon ve parça numarası kuralı

Bir değişikliğin mevcut parça numarasında revizyon artışıyla mı yoksa yeni bir parça numarasıyla mı yönetileceği, kuruluşun yazılı bir kuralına dayanmalıdır. Yaygın yaklaşım, değişiklik parçanın form, uyum veya fonksiyonunu etkiliyorsa ve eski ile yeni parça birbirinin yerine kullanılamıyorsa yeni parça numarası verilmesi; birbirinin yerine kullanılabilirlik korunuyorsa revizyon artırılmasıdır. ERP'de bu kural, parça kartında zorunlu alanlar ve onay adımlarıyla desteklenmelidir.

Temel konfigürasyon

Temel konfigürasyon, belirli bir anda onaylanmış ve dondurulmuş ürün tanımıdır. Sonraki her değişiklik bu referansa göre tanımlanır. ERP'de temel konfigürasyonun, ürün ağacı ve rotanın o andaki onaylı revizyonları olarak geri çağrılabilmesi, denetimde ve müşteri sorgularında büyük kolaylık sağlar.

3. Değişiklik Talebinden Uygulamaya: Adım Adım Akış

Kontrollü bir mühendislik değişikliği, gayri resmi bir e-posta veya sözlü talimatla değil, kayıt altına alınan bir süreçle yürütülmelidir. Aşağıdaki akış çoğu savunma sanayi üreticisi için uygulanabilir bir çerçeve sunar.

  1. Değişiklik talebinin açılması: Talep; gerekçe, etkilenen parça ve dokümanlar, talep eden birim ve önerilen çözümle birlikte kaydedilir. Kaynak müşteri, tedarikçi, sahadan gelen bir uygunsuzluk veya iç iyileştirme olabilir.
  2. Sınıflandırma: Değişikliğin form, uyum, fonksiyon, güvenlik veya güvenilirlik üzerinde etkisi olup olmadığı değerlendirilir. Sözleşme gerekliliklerine bağlı olarak bazı değişiklikler müşteri onayı olmadan uygulanamaz.
  3. Etki analizi: Açık iş emirleri, yarı mamul, stok, açık satın alma siparişleri, tedarikçideki işler, fikstür ve takımlar, CNC programları, kontrol planları ve daha önce teslim edilmiş ürünler gözden geçirilir.
  4. Onay: Mühendislik, kalite, üretim ve gerektiğinde satın alma ile müşteri onayları alınır. Onaylayanlar ve tarihler sistemde kayıtlı olmalıdır.
  5. Geçerlilik noktasının belirlenmesi: Değişikliğin hangi tarihten, hangi seri numarasından, hangi lottan veya hangi iş emrinden itibaren geçerli olacağı açıkça tanımlanır.
  6. Ana verinin güncellenmesi: Yeni revizyon ERP'de ürün ağacı, rota, operasyon talimatları ve kontrol planıyla birlikte yayınlanır; eski revizyon yeni işler için kullanıma kapatılır.
  7. Uygulamanın doğrulanması: Değişiklik sonrası ilk üretimde gerekli muayeneler yapılır; ihtiyaç hâlinde ilk parça muayenesi kısmen veya tamamen tekrarlanır.
  8. Kapanış: Tüm aksiyonlar tamamlandığında talep kapatılır ve değişiklik kaydı ilgili ürün geçmişine bağlanır.

4. Etki Analizi ve Stok Kararları

Değişiklik sürecinin en çok atlanan adımı etki analizidir. Mühendislik tarafında doğru bir karar alınmış olsa bile, depoda ve sahada bekleyen eski revizyon malzemeler için ne yapılacağı belirlenmezse, bu malzemeler fark edilmeden yeni ürünlere karışabilir. ERP'nin, bir parça numarası ve revizyon için tüm açık kayıtları tek ekranda listeleyebilmesi bu analizin güvenilirliğini doğrudan etkiler.

Eski revizyon stok ve yarı mamuller için verilecek kararlar genellikle aşağıdaki seçeneklerden biridir:

DurumOlası kararERP'de yapılması gereken
Eski ve yeni parça birbirinin yerine kullanılabilirStok bitene kadar kullanEski revizyonun tüketimine izin ver, stok sıfırlandığında revizyonu kapat
Eski parça yeniden işlenerek yeni revizyona getirilebilirYeniden işleYeniden işleme iş emri aç, muayene sonrası revizyonu güncelle
Eski parça yalnızca belirli ürün veya müşteri için uygunSınırlı kullanımStoku ayrı lokasyona veya bloke statüye al, kullanım kısıtını kayda bağla
Eski parça kullanılamazHurda veya iadeStoku bloke et, uygunsuz ürün sürecini başlat, maliyet etkisini kaydet
Teslim edilmiş ürünler etkileniyorMüşteriyle değerlendirmeEtkilenen seri ve lotları listele, müşteri bildirimi ve saha aksiyonunu kaydet

Etki analizinin mali boyutu da göz ardı edilmemelidir. Hurdaya ayrılan stok, yeniden işleme maliyeti ve iptal edilen satın alma siparişleri, değişiklik kararının bir parçası olarak genel müdürlük ve finans birimince görülebilir olmalıdır. Bu görünürlük, değişikliklerin yalnızca teknik değil, işletme kararı olarak da değerlendirilmesini sağlar.

5. Sık Yapılan Hatalar

  • Revizyonun yalnızca çizimde güncellenmesi: Teknik doküman değişir, ancak ERP'deki ürün ağacı ve rota eski hâlde kalır. Sonuçta sahada doğru çizim, yanlış malzeme ve yanlış operasyon sırası bir arada bulunur.
  • Geçerlilik noktasının belirsiz bırakılması: Değişikliğin hangi iş emrinden itibaren uygulanacağı tanımlanmadığında, aynı dönemde üretilen parçaların bir kısmı eski, bir kısmı yeni revizyona göre üretilir ve bu ayrım sonradan kanıtlanamaz.
  • Açık iş emirlerinin gözden kaçması: Değişiklik onaylandığında sahada devam eden iş emirleri otomatik olarak güncellenmez. Bu iş emirleri için ayrı bir karar verilmesi ve kaydedilmesi gerekir.
  • Tedarikçi tarafının unutulması: Fason işlem veya satın alınan parçalarda tedarikçiye yeni revizyonun iletilmediği durumlar sık görülür. Satın alma siparişinin revizyon bilgisini taşıması ve değişiklikte güncellenmesi bu riski azaltır.
  • Geçici sapmaların kalıcı değişiklik gibi yönetilmesi: Belirli bir lot için onaylanan sapma izni, kalıcı tasarım değişikliği değildir. İkisinin aynı kayıt türüyle yönetilmesi, sapmanın süresiz uygulanmasına yol açabilir.
  • Onayların sistem dışında kalması: Onaylar e-posta veya ıslak imzalı formlarla alınıp ERP'ye bağlanmadığında, denetimde değişiklik geçmişini yeniden kurmak zaman alır ve eksik kalır.
  • Yazılım ve program revizyonlarının kapsam dışı bırakılması: CNC programları, test yazılımları ve gömülü yazılım sürümleri de ürün konfigürasyonunun parçasıdır ve aynı disiplinle yönetilmelidir.

Hızlı kontrol listesi

  • Her parça kartında geçerli revizyon ve revizyon geçmişi görülebiliyor mu?
  • İş emri, satın alma siparişi ve muayene kaydı, kullanılan revizyonu kayıt altına alıyor mu?
  • Bir değişiklik talebinden etkilenen tüm açık kayıtlar tek bir listede görülebiliyor mu?
  • Eski revizyon yeni iş emirlerinde kullanılmaya kapatılabiliyor mu?
  • Sapma izinleri süre veya miktar sınırıyla tanımlanıyor mu?
  • Teslim edilmiş bir seri numarasının üretildiği konfigürasyon geri çağrılabiliyor mu?

6. Sonuç

Konfigürasyon yönetimi, yalnızca mühendislik biriminin doküman düzeni değil; üretim, planlama, satın alma, kalite ve finansın aynı ürün tanımı üzerinde çalışmasını sağlayan bir disiplindir. AS9100 gereklilikleri açısından beklenen, her değişikliğin gerekçesiyle kayıt altına alınması, etkisinin değerlendirilmesi, yetkili kişilerce onaylanması ve üretilen her birimin hangi onaylı tanıma göre üretildiğinin gösterilebilmesidir. Bu beklentiyi karşılamanın en güvenilir yolu, revizyon kontrolünü ERP'nin ana verisine yerleştirmek ve değişiklik akışını operasyonel kayıtlarla doğrudan ilişkilendirmektir.

Kuruluşların bu yapıyı kurarken kendi ürün yapılarına, müşteri sözleşmelerine ve iç onay hiyerarşilerine uygun bir kurgu tasarlaması gerekir. opac, savunma sanayi ve üretim kuruluşları için geliştirdiği şirketlere özel ERP çözümlerinde değişiklik yönetimi, revizyon kontrolü ve etki analizini AS9100 gerekliliklerine uygun biçimde yapılandırarak bu sürecin sistematik yürütülmesine destek olur. Hangi araç kullanılırsa kullanılsın, başlangıç noktası aynıdır: değişiklik kuralını yazılı hâle getirmek, geçerlilik noktasını her seferinde açıkça tanımlamak ve hiçbir revizyonun sistem dışında kalmamasını sağlamak.

Bu konuyu şirketiniz özelinde değerlendirelim.

Görüşme Planlayın
Blog

Diğer Yazılar