AS9100 Bir Bürokrasi Değil, Kurumsal Hafızadır

Mühendislik ekiplerinde neredeyse evrensel bir tepki vardır: kalite sistemi konuşulmaya başlandığında odadaki enerji düşer. AS9100, doküman, prosedür, kayıt, denetim. Herkesin katlandığı ama kimsenin savunmadığı bir alan.

Bu tepkiyi anlıyorum ve bir kısmını da haklı buluyorum. Ama bu yazının iddiası şu:

Havacılık ve savunma kalite standartlarının hemen her maddesi, geçmişte birinin ödediği bir bedelin karşılığıdır. Standart, o bedeli iki kere ödememek için yazılmış bir hafızadır.

Önce ne olduğu: AS9100 nedir?

AS9100, havacılık, uzay ve savunma sektörü için geliştirilmiş kalite yönetim sistemi standardıdır. ISO 9001'in üzerine kurulur ve ona sektöre özgü ek şartlar getirir. Avrupa'da EN 9100, Japonya'da JISQ 9100 olarak aynı içerikle yayımlanır.

ISO 9001'in ötesine geçtiği başlıca alanlar:

• Konfigürasyon yönetimi: hangi ürünün hangi tasarım sürümüyle üretildiğinin kaydı
• İlk ürün muayenesi (FAI): bir üretim sürecinin ilk çıktısının, tasarımın her bir şartına karşı tek tek doğrulanması
• Risk yönetimi: sadece kalite riski değil, ürün emniyeti riski
• Ürün emniyeti ve taklit/sahte parça önleme
• Tedarik zinciri kontrolü: tedarikçinizin tedarikçisinden sorumlu olmanız
• Özel prosesler: kaynak, ısıl işlem, yüzey kaplama gibi çıktısı sonradan muayeneyle doğrulanamayan süreçlerin ayrıca yeterliliğinin kanıtlanması

Bu maddelere tek tek bakıldığında hiçbiri keyfi değildir. Her biri, sektörde yaşanmış bir başarısızlık sınıfına karşılık gelir.

"Süreç bizi yavaşlatıyor" itirazı

En sık duyulan itiraz bu ve genellikle şu bağlamda gelir: küçük ekip, hızlı gitmek istiyor, prototip aşamasında, süreç yükü orantısız geliyor.

Bu itirazın kısa vadede haklı, uzun vadede yanlış olmasının nedeni şudur:

Süreç sizi korumaz. Sizden sonrakini korur.

Bugün o kartı siz tasarladınız. Hangi direncin neden 1% toleranslı seçildiğini biliyorsunuz. Hangi kondansatörün neden o marka olması gerektiğini, bir keresinde başka markayla yaşanan problemi hatırlıyorsunuz. Hangi vidanın hangi torkla sıkılacağını biliyorsunuz.

Bu bilgi, kayıt altına alınmadığı sürece sizin kafanızda duran bir tekil arıza noktasıdır.

İki yıl sonra ekip değişir. Siz başka projeye geçersiniz. Yeni bir mühendis maliyet düşürmek için o direnci 5% toleranslıyla değiştirir; sebebini bilmediği için değiştirir. Ve sistem, ilk sıcak günde, sahada, müşterinin elinde bozulur.

Konfigürasyon yönetiminin, tasarım gerekçesi kaydının ve değişiklik kontrolünün var oluş sebebi tam olarak budur. Bunlar hızı düşürmek için değil, öğrenilmiş dersin buharlaşmasını önlemek için vardır.

İzlenebilirlik: en sıkıcı, en değerli özellik

Sahadan bir arıza bildirimi geldiğini düşünün. Tek bir üründe.

İzlenebilirliğiniz yoksa cevaplayamayacağınız sorular şunlardır: Bu üründe hangi parti numaralı bileşen kullanıldı? Aynı partiden kaç ürün daha üretildi ve nereye gitti? O parti hangi tedarikçiden, ne zaman geldi? Üretim sırasında hangi tasarım revizyonu geçerliydi?

Bu soruların cevabı yoksa önünüzde iki seçenek kalır: hiçbir şey yapmamak ya da sahadaki her ürünü geri çağırmak. Birincisi emniyet riski, ikincisi şirketi batırabilecek bir maliyettir.

İzlenebilirlik, bu iki kötü seçenek arasında üçüncü bir seçenek yaratır: sadece etkilenen partiyi çağırmak. Bir kalite kaydının bütün maliyeti, tek bir olayda bunu bir kere yapabilmekle fazlasıyla karşılanır.

Peki gerçekten ne zaman bürokrasiye dönüşür?

Standardı savunmak, her uygulamasını savunmak değildir. Süreç gerçekten değer üretmeyi bıraktığı noktalar vardır ve bunları teşhis edebilmek, standardı bilmek kadar önemlidir:

1. Kayıt, kimse okumadığı için tutuluyorsa. Her kaydın bir okuyucusu ve bir kullanım anı olmalıdır. "Denetimde sorulur" tek başına bir gerekçedir ama zayıf bir gerekçedir. Bir kaydın kim tarafından, hangi durumda okunacağını söyleyemiyorsanız, o kayıt gerçekten israftır.

2. Doküman, gerçek işi değil hayali işi tarif ediyorsa. Prosedürde yazan şeyi kimse yapmıyorsa iki sorun vardır, biri değil: prosedür yanlıştır ve insanlar prosedüre uymama alışkanlığı edinmiştir. İkincisi birincisinden çok daha tehlikelidir, çünkü artık hangi prosedüre uyulduğu da bilinmez.

3. Onay zinciri sorumluluğu dağıtmak için uzatılıyorsa. Beş imza, sorumluluğu beşe bölmez; sıfıra indirir. Herkesin onayladığı bir kararın sahibi yoktur. Sağlıklı bir onay zincirinde her imzanın neye baktığı tanımlıdır.

4. Süreç, TRL seviyesine göre ölçeklenmiyorsa. Bu, Ar-Ge kuruluşlarındaki en yaygın hata. TRL 3'teki bir kavram doğrulamasına, TRL 8'deki bir seri üretim ürününün süreç yükünü uygulamak, ne kaliteyi artırır ne emniyeti. Sadece mühendisi standarttan soğutur ve gerçekten gerekli olduğu anda direnç bulursunuz.

Standardın kendisi bu ölçeklemeye izin verir. Uygulamayı ölçekleyemeyen, standardı değil kendi kalite sistemini tasarlayamamış olan kurumdur.

Program yöneticisi için pratik sonuç

Kalite sistemi, proje yöneticisinin başına gelen bir şey değildir; kullanacağı bir araçtır.

• Kalite planını iş kırılım yapısına gömün. Ayrı bir belge olarak dururken kimse okumaz; iş paketlerinin çıktısı olarak durduğunda takip edilir.
• Kalifikasyon ve doğrulama testlerini takvime erken koyun. Bunlar projenin sonuna eklenen formalite değil, kritik yol üzerindeki gerçek işlerdir. Test tesisi randevusu aylar öncesinden alınır.
• Değişiklik kontrolünü tasarım dondurulmadan kurun. Sonradan kurulan değişiklik kontrolü, değişiklikleri kontrol etmez; sadece kaydeder.
• Uygunsuzlukları bir başarısızlık değil, veri olarak yönetin. Uygunsuzluk kaydı az olan kurum iyi kurum değildir; uygunsuzluğu görmeyen kurumdur.

Kapanış

AS9100'ü ve benzeri standartları savunmam, bürokrasiyi sevdiğimden değil.

Bu sektörde bir hatanın bedelini ödeyen taraf çoğu zaman onu yapan taraf değil. Standartların tamamı bu asimetrinin üzerine yazılmıştır. Süreci "bizi yavaşlatan şey" olarak görmek, o bedeli kimin ödediğini görmemektir.

Süreç, geçmişin bugüne bıraktığı nottur. Notu okumamayı seçebilirsiniz, ama o zaman aynı dersi kendiniz ödeyerek öğrenirsiniz.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.