Ana yüklenicinin tedarik zinciri denetçisi toplantı odasına girdi, dosyasını açmadan önce tek bir soru sordu: "Kalite kayıtlarınız fiziksel olarak hangi sunucuda duruyor?" Kalite müdürü bulut tabanlı bir yazılım kullandıklarını, verinin Avrupa'daki bir veri merkezinde tutulduğunu söyledi. Denetçi not defterine tek satır yazdı ve gündeme geçti. İki hafta sonra gelen raporda teknik bulguların hiçbiri yoktu; yalnızca o tek satır vardı. Savunma sanayi kalite yönetim sistemi kurarken karşılaşacağınız ilk eşik, prosedürlerinizin olgunluğu değil; verinin nerede durduğu ve kimin eline geçebileceğidir.
Denetimin ilk sorusu neden sunucunun adresi?
Savunma programlarında teknik veri, ürünün kendisi kadar korunması gereken bir varlıktır. Bir teknik resim, bir malzeme şartnamesi ya da bir ölçüm raporu; hangi parçanın nerede, hangi toleransla üretildiğini gösterir. Bu bilgi kalite kayıtlarının içinde yaşar. Ana yüklenici, tedarikçisinin kalite sistemine baktığında önce sistemin barındırdığı veriyi, sonra sistemin kendisini değerlendirir.
Tesis Güvenlik Belgesi kapsamında çalışan bir işletmede gizli dereceli bilginin işlendiği ortamların denetlenebilir olması beklenir. Denetlenebilir olmak; sunucuya fiziksel erişimin kontrol altında olması, log kayıtlarının doğrudan erişilebilir olması ve üçüncü bir tarafın veriye yönetici hakkıyla ulaşamaması demektir. Bir bulut sağlayıcının sistem yöneticisi teknik olarak veritabanına erişebiliyorsa, bu durumu sözleşme metniyle kapatmak zordur. Denetçi de zaten sözleşmeye değil, teknik gerçeğe bakar.
Bulut QMS savunma tedarik zincirinde nerede tıkanır
Bulut tabanlı bir kalite yazılımı tek başına kötü bir tercih değildir; otomotivde ya da beyaz eşyada çoğu tedarikçi için gayet iyi çalışır. Savunmada tıkanma noktası şudur: program sözleşmesinin gizlilik eki genellikle verinin yurt dışına çıkmamasını, alt yüklenicilerin bildirilmesini ve veriye erişen personelin güvenlik soruşturmasından geçmiş olmasını ister. Bulut hizmetinde veri merkezini işleten firma da veriye teknik erişimi olan bir taraftır ve çoğu zaman bu listeye giremez.
İkinci tıkanma noktası internet bağımlılığıdır. Kapalı ağda çalışan bir üretim tesisinde vardiya başındaki operatör iş talimatının güncel revizyonunu göremiyorsa, ISO 9001 madde 7.5.3'ün istediği "kullanım noktasında uygun dokümanın bulunabilir olması" şartı fiilen karşılanmamış olur. Şirket içi kurulumun en somut faydası tam da budur: dış hat kesilse bile sistem ayakta kalır. On premise kalite yazılımı tercihi savunmada bir konfor meselesi değil, bir çalışma şartıdır.
Şirket içi kurulumun karşıladığı somut şartlar
Aşağıdaki tablo, savunma tedarikçisi sözleşmelerinde en sık geçen beş şartın iki barındırma modelinde nasıl karşılandığını gösteriyor. Tablodaki satırlar genel geçer pazarlama cümleleri değil, sözleşme eklerinde gerçekten yazan maddelerin karşılığıdır.
| Sözleşme şartı | Bulut barındırma | Şirket içi kurulum |
|---|---|---|
| Verinin ülke sınırları içinde kalması | Sağlayıcının veri merkezi konumuna bağlı, yazılı taahhüt gerekir | Sunucu tesiste, konum tartışma konusu değil |
| Veriye erişen personelin bildirilmesi | Sağlayıcının sistem yöneticileri bildirim listesine giremez | Yalnızca kendi BT personeliniz; güvenlik soruşturması yapılabilir |
| Kapalı ağda çalışabilme | İnternet kesildiğinde erişim durur | Yerel ağda kesintisiz çalışır |
| Program sonunda verinin imhası | Sağlayıcıdan imha tutanağı talep edilir | Kendi diskinizde; tutanaklı imha doğrudan yapılır |
| Denetçiye ham erişim logu sunulması | Sağlayıcının verdiği rapor formatıyla sınırlı | Veritabanı düzeyinde tam log erişimi |
Tablodaki son satır sahada en çok işe yarayanıdır. İkinci taraf denetiminde denetçi "şu teknik resmi son altı ayda kim indirdi?" diye sorduğunda, ham log üzerinden anında cevap verebilmek denetimin seyrini değiştirir. Sağlayıcıya destek talebi açıp üç gün beklemek ise denetim gününde hiçbir işinize yaramaz.
Erişim yetkisi tasarımı: kim neyi görür
Savunma sanayi kalite yönetim sistemi kurarken en çok emek isteyen kısım yetki tasarımıdır. Klasik hata, yetkiyi departmana göre vermektir: "kalite departmanı tüm dokümanları görsün". Oysa savunmada doğru kırılım programdır. Aynı kalite mühendisi A programında tam yetkiliyken B programının teknik dosyasını hiç görmemelidir. Bu ilkeye bilme gereği (need to know) denir ve sözleşme eklerinde açıkça yazar.
İşleyen bir yetki matrisi dört katmandan oluşur: rol (kalite mühendisi, üretim şefi, iç denetçi), kapsam (hangi program ya da müşteri), doküman sınıfı (prosedür, teknik resim, kalite kaydı) ve işlem hakkı (görüntüleme, indirme, yazdırma, revize etme). Dördünün kesişimi tek bir hücreye karşılık gelir. ISO 9001 madde 7.5.3.2 erişimi tam bu ayrımla tarif eder: yalnızca görme izni ile görüp değiştirme izni farklı şeylerdir. Doküman yönetimi kurgunuz bu ayrımı desteklemiyorsa yetki tasarımı kâğıt üstünde kalır.
Yazdırma hakkını görüntüleme hakkından ayırmayan sistemler, kontrolsüz kopya üretiminin ana kaynağıdır. Bir tedarikçide tezgâh panolarına asılı teknik resimleri sistemdeki güncel revizyonlarla karşılaştırdığımızda, bir bölümünün yürürlükten kalkmış sürümler olduğu görüldü; hepsi de sistemden, yetkili kişilerce yazdırılmıştı. Çözüm basit: teknik resim sınıfında yazdırma hakkını iki kişiyle sınırlayın ve her çıktının alt köşesine kullanıcı adı ile zaman damgası bastırın.
AS9100 ve program şartlarının QMS'e yansıması
Savunma ve havacılık tedarikçilerinin büyük kısmı AS9100 belgesi taşır. AS9100, ISO 9001'in üzerine sektöre özgü şartlar ekler ve bunların üçü doğrudan kalite yazılımını ilgilendirir. Madde 8.1.2 konfigürasyon yönetimini ister: ürünün hangi revizyondaki parçalardan oluştuğunu ve o revizyonun hangi kayıtla onaylandığını izleyebilmeniz gerekir. Madde 8.1.3 ürün güvenliğini, madde 8.1.4 ise sahte parça girişinin önlenmesini şart koşar; ikincisi tedarikçi onayı ve malzeme sertifikası kayıtlarını doğrudan etkiler.
Bir başka ağır başlık ilk parça muayenesidir. AS9102 formatındaki ilk parça muayene raporu, her karakteristiğin teknik resimdeki balon numarasıyla eşleşmesini ister. Bu yüzlerce satırlık bir kayıttır ve elektronik tabloda tutulduğunda resim revizyonu değiştiğinde hangi satırların yeniden ölçüleceği kaybolur. AS9100 kalite yazılımı arayan işletmelerin çoğu, farkında olmadan aslında bu eşleştirme sorununu çözecek bir yapı arıyor. Bu üç maddeyi kayıt düzenine çevirmek, bir savunma sanayi kalite yönetim sistemi kurmanın en somut kısmıdır.
İzlenebilirlik ve konfigürasyon kaydı
Savunmada izlenebilirlik, otomotivdeki parti bazlı izlenebilirlikten daha derindir. Genellikle seri numarası bazında ve ürünün ömrü boyunca istenir. Bir parçanın hangi malzeme partisinden, hangi ısıl işlem fırınından, hangi operatörle ve hangi resim revizyonuyla üretildiğinin kaydı teslimden on yıl sonra bile sorulabilir. Kayıt saklama süresi de bu yüzden savunma sözleşmelerinde çoğu zaman "program ömrü artı belirli bir süre" olarak tanımlanır.
Bu derinlikteki izlenebilirliği kâğıt formlarla sürdürmek mümkün değil. Kayıtların ilişkisel bir yapıda tutulması, yani seri numarasından malzeme sertifikasına, oradan tedarikçi onay kaydına tek hamlede gidebilmeniz gerekir. Tedarikçi yönetimi ile üretim kayıtları ayrı sistemlerde durduğunda bu zincir daha ilk halkada kopar. Kopan zinciri denetim gününde değil, kriz gününde fark edersiniz.
İkinci taraf denetiminde en verimli yöntem, rastgele bir sevk irsaliyesi seçip geriye doğru yürümektir: seri numarasından üretim kaydına, oradan malzeme sertifikasına ve tedarikçi onay listesine. Bu yürüyüşü 15 dakikada tamamlayamayan bir sistem, geri çağırma anında da tamamlayamaz. Böyle bir bildirim geldiğinde size tanınan süre ise genellikle saatlerle ölçülür.
Şirket içi kurulumda gözden kaçan üç başlık
Sunucuyu tesise koymak işin kolay kısmı; zor kısmı o sunucunun sorumluluğunu üstlenmektir. Birincisi yedekleme. Gecelik yedek alınıyor olması yeterli değil, yedekten geri dönüşün denenmiş olması gerekir. Yılda en az bir kez kayıtlı bir geri dönüş tatbikatı yapın ve tutanağını iç denetim dosyasına koyun. Denetçi prosedürü değil, tatbikat kaydını ister.
İkinci başlık güncelleme disiplini. Kapalı ağdaki bir sunucu güncelleme almadığında güvenlik açıkları sessizce birikir. Güncelleme paketlerinin kontrollü biçimde içeri alınması ve önce test ortamında denenmesi için yazılı bir akış kurun. Geriye bir de kimsenin konuşmak istemediği soru kalıyor: sunucu odasında yangın ya da su baskını olduğunda kalite kayıtlarınızın ikinci kopyası nerede duruyor? Aynı binada duran bir yedek disk, felaket senaryosunda yedek sayılmaz. Şirket içi kurulan bir savunma sanayi kalite yönetim sistemi, felaket senaryosunu da kendi sorumluluğuna alır. Yedek kopyanın başka bir tesiste, şifreli ve erişimi kayıt altına alınmış biçimde durması gerekir; bunu da gizlilik derecesi izin veren bir yöntemle çözmek zorundasınız. Uygulamada en yaygın çözüm, şifreli disklerin haftalık olarak ikinci bir tesise taşınması ve her taşımanın tutanakla kayda geçirilmesidir. Tutanak olmadığında, disk yerinde dursa bile denetimde kanıt sayılmaz.
Uygunsuzluk ve düzeltici faaliyet akışı nasıl kurulur
Savunma müşterileri uygunsuzluk bildirimlerinde otomotivdekine benzer bir disiplin bekler, ama tek fark önemlidir: sapma onayı (deviation) ve şartname dışı kabul (waiver) süreçleri neredeyse her programda devrededir. Ölçüsü tolerans dışına çıkan bir parçayı hurdaya ayırmak yerine müşteriye sapma onayı için sunarsınız; müşteri kabul ederse parça sevk edilir, ama bu kabul kaydının parçanın seri numarasına bağlanması gerekir. Bu bağ kurulmadığında beş yıl sonra o parça sorgulandığında elinizde yalnızca bir e-posta kalır.
Uygunsuzluk kaydından düzeltici faaliyete geçişte ise en sık görülen hata, kök neden analizini atlayıp doğrudan düzeltmeye gitmektir. "Parça yeniden işlendi" bir düzeltmedir, düzeltici faaliyet değildir. Aynı hatanın üç ay sonra tekrar etmesi, denetçi için kök neden analizinin yapılmadığının en açık kanıtıdır. Kök neden analizi ile düzeltici faaliyet kaydını aynı akışta tutmak, bu tekrarları görünür kılar.
Bir de tekrar eden uygunsuzlukların program bazında raporlanması var. Ana yüklenici üç aylık gözden geçirme toplantılarında genellikle programa özel bir uygunsuzluk tablosu ister: kaç adet açıldı, kaçı kapandı, ortalama kapanma süresi kaç gün. Kayıtlarınız program alanı taşımıyorsa bu tabloyu her çeyrekte elle çıkarmak zorunda kalırsınız. Uygunsuzluk kaydına program alanını en baştan koymak, üç yıl boyunca her çeyrekte iki gün kazandırır.
Kurulum sırası: önce matris, sonra yazılım
Yeni bir savunma sanayi kalite yönetim sistemi kurarken sıralama şu olmalı: önce program bazlı yetki matrisini kâğıda dökün, sonra doküman sınıflarını ve saklama sürelerini tanımlayın, en son yazılımı seçin. Tersten gidildiğinde yazılımın desteklemediği bir yetki modeline zorlanır ve sistemi kurduktan altı ay sonra baştan yapmak zorunda kalırsınız. Yetki modelini sonradan değiştirmek, kayıt geçmişini de bozar.
Yazılım seçiminde bakılacak asgari şartlar bellidir: tamamen kendi sunucunuzda çalışabilmesi, kullanıcı bazlı erişim logu tutması, doküman sınıfı ve program kırılımında yetki verebilmesi, kayıtları birbirine ilişkisel biçimde bağlayabilmesi. PaKalite bu ihtiyaç için şirket içi kurulumla çalışır ve 18 bağlı modülü tek veritabanında tutar; kapsamı modüller sayfasından inceleyebilirsiniz. Tercihiniz ne olursa olsun bu dört şart pazarlık konusu değil; program sözleşmesi askıya alındıktan sonra düzeltilebilen bir karar değil bu.