Kalite mühendisi boş bir tablo açıyor. İlk sütuna "müşteri" yazıyor, ikinci sütuna "şart maddesi". Üçüncü sütunda imleç bekliyor. Aslında zor olan kısım burası; ilk iki sütun kopyalama işidir, üçüncü sütun ise düşünme işi. CSR matrisi hazırlarken matrisin işe yarayıp yaramayacağını belirleyen şey, o üçüncü ve dördüncü sütunun ne olduğudur. Müşteri şartlarını listeleyen bir tabloyla, o şartların nerede karşılandığını gösteren bir tablo arasında dağlar kadar fark var.
Matrisin amacı listelemek değil, eşleştirmek
IATF 16949'un 4.3.2 maddesi müşteri özel şartlarının değerlendirilmesini ve kuruluşun kalite yönetim sisteminin kapsamına dahil edilmesini ister. Buradaki anahtar kelime "dahil edilmesi". Şartı okumuş olmanız, hatta bir listeye yazmış olmanız yetmez; o şartın sisteminizin içinde bir yere oturmuş olması gerekir. Matris, bu oturmayı gösteren haritadır.
Yani her satırın cevaplaması gereken soru şudur: bu şartı biz nerede, hangi dokümanla ve hangi kayıtla karşılıyoruz? Bu soruya cevap veremeyen satır, aslında bir açık listesidir ve öyle işlem görmelidir. Matrisin en değerli çıktısı da budur zaten: hangi şartların karşılıksız kaldığını görmek. Denetimden önce bulmanız gereken şey, karşılanmış şartların listesi değil, karşılanmamışların listesidir.
Sütunlar: yedi kolonluk iskelet
Yıllar içinde denediğim en kullanışlı yapı yedi sütundan oluşuyor. Daha fazlası matrisi bakımı zor hâle getiriyor, daha azı ise soruyu cevaplamıyor. Aşağıdaki tablo hem sütunları hem de örnek doldurulmuş iki satırı gösteriyor.
| Sütun | Örnek satır 1 | Örnek satır 2 |
|---|---|---|
| Müşteri | A Müşterisi | B Müşterisi |
| Kaynak doküman / sürüm | Tedarikçi Kalite El Kitabı, Rev 07 | Kalite Şartnamesi, Rev 03 |
| Şart maddesi | Madde 5.4 | Madde 8.2 |
| Şartın özeti (kendi cümlenizle) | Şikayet sonrası ilk yanıt 24 saat içinde verilir | Yeni parçada ilk 3 ay güvenli devreye alma uygulanır |
| Karşılayan iç doküman | PR-08 Müşteri Şikayetleri Prosedürü | PR-12 Devreye Alma Prosedürü, Ek 2 |
| Uygunluk kanıtı | Şikayet kaydı ilk yanıt zaman damgası | Güvenli devreye alma kontrol formu |
| Sorumlu | Kalite Mühendisi | Proje Mühendisi |
Dördüncü sütunu özellikle vurgulamak istiyorum: şartı kendi cümlenizle özetleyin, kopyala yapıştır yapmayın. Bu iş sıkıcıdır ama kritiktir; çünkü bir cümleyi kendi kelimelerinizle yazamıyorsanız onu anlamamışsınız demektir. Matrisi hazırlarken anlamadığınız her madde, denetimde açıklayamayacağınız bir maddedir.
Şartları ayrıştırma kuralı
Bir CSR matrisi hazırlamanın en çok emek isteyen aşaması burasıdır ve genelde hafife alınır.
Elinizde kırk sayfalık bir tedarikçi kalite el kitabı var. Bunu satırlara nasıl dökeceksiniz? Kural basit: yükümlülük bildiren her cümle bir satırdır. Dokümanı okurken "yapılmalıdır", "sağlanır", "gönderilir", "onay alınır" gibi ifadelerin geçtiği cümleleri işaretleyin. Bir madde numarasının altında üç ayrı yükümlülük varsa üç satır açın.
Bu ayrıştırmayı yapmayan firmalarda tipik hata şudur: madde 6.3 tek satırda "PPAP şartları" diye geçer ve altındaki dokuz alt yükümlülük görünmez. Denetçi o dokuzdan birini sorar, cevap yoktur. Ayrıştırma sıkıcı bir iştir; orta ölçekli bir müşteri dokümanından altmış ile yüz elli arası satır çıkar. Ama bir kez yapılır, sonrasında revizyon bazında güncellenir.
Bilgilendirme amaçlı cümleleri ayrıştırmayın. "Müşterimiz kalitede mükemmelliği hedefler" gibi ifadeler yükümlülük doğurmaz ve matrisi şişirir. Şişmiş bir matris okunmaz, okunmayan matris de güncellenmez.
Matrisi tek başınıza doldurmayın. Satırların yarısı üretime, satın almaya, bakıma ve insan kaynaklarına bakar. Yaptığım en verimli matris çalışması şöyle geçti: her süreç sahibiyle birer saatlik oturum yapıldı, kendi alanına giren satırlar birlikte dolduruldu ve her satırın sorumlusu o oturumda belirlendi. Toplam on iki saat sürdü. Aynı işi kalite biriminin tek başına yaptığı bir başka firmada matris üç haftada bitti ve altı ay sonra süreç sahiplerinin çoğu kendi satırlarından haberdar bile değildi. Denetimde soru üretime gelir, cevabı kalite verirse denetçi bunu hemen fark eder.
Şartları tipine göre gruplayın
Yüz elli satırlık bir matris, gruplanmadığında okunmaz. En işe yarayan gruplama, şartın ne tür bir yükümlülük doğurduğuna göre yapılanıdır. Beş grup çoğu durumu kapsıyor: doküman şartları (bir prosedürünüzün belirli bir içeriği taşıması), kayıt şartları (belirli bir kaydın tutulması ve belirli süre saklanması), bildirim şartları (bir olayın belirli süre içinde müşteriye haber verilmesi), onay şartları (bir işlemden önce müşteri onayı alınması) ve performans şartları (bir hedefin tutturulması).
Bu gruplama neden önemli? Çünkü her grubun riski farklıdır. Doküman şartlarını kaçırmak bir bulgu doğurur; bildirim ve onay şartlarını kaçırmak ise doğrudan ticari sonuç doğurur. Süreç değişikliğini bildirmeden yapan bir tedarikçi, sonrasında ürünü kusursuz olsa bile müşteri gözünde güven kaybeder. Matrisi hazırlarken bildirim ve onay satırlarını ayrı bir renkle işaretleyin ve bunları sahaya en önce indirin.
Onay şartlarının en sık kaçırılanı süreç değişikliği bildirimidir. Tezgâh değişimi, lokasyon değişimi, alt tedarikçi değişimi ve malzeme değişimi neredeyse her müşteride önceden bildirim ve çoğu zaman yeniden onay gerektirir. Bu dört kalemi bir kontrol listesine dönüştürüp değişiklik yönetimi formunuza ekleyin. Geçici bir değişiklik yapmanız gerektiğinde ise izni önceden almanın yolunu sapma izni yazımızda anlattık.
Uygunluk durumu ve boşluk analizi
Yedi sütunluk iskelete bir sütun daha ekleyin: uygunluk durumu. Üç değer yeterlidir — karşılanıyor, kısmen karşılanıyor, karşılanmıyor. Dördüncü bir değer olarak "uygulanabilir değil" de kullanılabilir, ama bunu seçtiğinizde gerekçesini yazmak zorunludur. Gerekçesiz "uygulanabilir değil" işaretlemesi, denetimde en hızlı açılan kutulardan biridir.
Kısmen karşılanan ve karşılanmayan satırlar sizin açık listenizdir. Her birine bir aksiyon, bir sorumlu ve bir tarih yazın. İlk matris çalışmasında bu listenin uzun çıkması normaldir; ilk kez yapılan bir çalışmada onlarca açık bulmak, sistemin kötü olduğunu değil, ilk kez bakıldığını gösterir. Açıkları kapatma işini düzeltici faaliyet kayıtlarıyla yürütürseniz, matris canlı bir belgeye dönüşür.
Açık listesini yönetirken önceliklendirme yapın. Bildirim ve onay şartlarındaki açıklar önce kapanır, doküman içeriğine dair açıklar sonra. Hepsini aynı anda kapatmaya çalışan ekipler üç ay sonra hiçbirini bitirmemiş oluyor. Ayda beş satır kapatan bir plan, kâğıt üzerinde iddialı görünmese de gerçekten yürüyor.
Sürüm değiştiğinde ne olacak?
Matrisin ölüm sebebi neredeyse her zaman aynıdır: kaynak doküman güncellenir, matris güncellenmez. Bunu engellemenin yolu, kaynak dokümanı matrisin içinde sürüm numarasıyla tutmak ve o dokümanı doküman yönetimi düzeninize dış kaynaklı bir kayıt olarak almaktır. Böylece yeni sürüm geldiğinde hangi satırların etkilendiğini tek bir filtreyle görürsünüz.
Yeni sürüm geldiğinde bütün matrisi baştan yazmayın. Eski ve yeni sürüm arasındaki farkı çıkarın, yalnızca değişen maddelerin satırlarını gözden geçirin. Çoğu müşteri, doküman başına bir değişiklik özeti yayımlar; o özet işinizi yarı yarıya kısaltır. Şart dokümanlarına nereden ulaşıldığını ve sürüm takibini ayrı bir yazıda ele aldık.
Denetçi matrisi eline aldığında genelde şunu yapar: rastgele bir satır seçer, o satırda yazan iç dokümanı ister, dokümanı okur ve şartın gerçekten orada karşılanıp karşılanmadığına bakar. Sonra kanıt sütununda yazan kaydı ister. Bu üç adımı geçen bir satır, matrisin tamamına güven kazandırır. Geçemeyen bir satır ise denetçiyi ikinci, üçüncü satıra götürür. En sık gördüğüm zayıflık, iç doküman sütununda kalite el kitabının yazılı olmasıdır; el kitabı çoğu şartı karşılamaz, prosedür karşılar.
Matris ile iç denetimi birbirine bağlamak
Hazırlanan bir CSR matrisi yalnızca denetime hazırlık belgesi değildir; doğru kullanıldığında iç denetim programınızın soru bankası hâline gelir.
Matrisin en az kullanılan ama en değerli çıktısı, iç denetim programınıza girdi olmasıdır. IATF kurallarına göre iç denetim programınız müşteri özel şartlarını da kapsamalıdır. Matrisiniz varsa bu iş kendiliğinden çözülür: denetim planını hazırlarken matristen ilgili satırları çekersiniz ve denetçinin soru listesi hazır olur.
Bunu yapan firmalarda ilginç bir yan etki oluşuyor. İç denetçi, müşteri şartını sorduğu anda süreç sahibi o şartın varlığından haberdar oluyor ve şart sahaya iniyor. Matris dolabında duran bir tablo olmaktan çıkıp bir eğitim aracına dönüşüyor. Bu bağı kurmak için denetim planlamanızda her sürecin altına ilgili CSR satır numaralarını yazmanız yeterli.
Fark analizinde bir ayrıntıya dikkat edin: madde numaraları değişmiş olabilir. Yeni sürümde 7.2 olan madde, eski sürümde 6.4 olabilir. Bu durumda matristeki madde numarası kolonu tek başına eşleştirme için yetmez; şart metnini de karşılaştırmanız gerekir.
Yeni müşteri geldiğinde ilk otuz gün
Yeni bir müşteriyle çalışmaya başladığınızda matris çalışmasını sipariş alındıktan sonra değil, sözleşme aşamasında başlatın. Sebebi ticari: bazı müşteri şartları size doğrudan maliyet yükler — ayrı bir laboratuvar testi, belirli bir yazılım aboneliği, ek bir denetim ya da özel bir izlenebilirlik sistemi. Bunları teklif verirken görmezseniz fiyatınıza yansıtamazsınız ve sonrasında ya zarar edersiniz ya da şartı görmezden gelirsiniz. İkisi de kötü.
Otuz günlük bir plan yeter. İlk hafta dokümanların toplanması ve sürümlerin doğrulanması, ikinci hafta satırlara ayrıştırma, üçüncü hafta süreç sahipleriyle oturumlar, dördüncü hafta açıkların aksiyona bağlanması. Bu planı yürütmek yaklaşık on beş adam-saat tutar. Aynı işi devreye alma haftasında yapmaya kalkarsanız hem eksik yaparsınız hem de kimseyi masaya toplayamazsınız.
Tabloda mı, sistemde mi tutulmalı?
Tek müşterisi olan bir firmada iyi hazırlanmış bir tablo yeterlidir ve bunu söylemekten çekinmiyorum. Yetmediği yer üç müşteriden sonrası. Çünkü o noktada aynı iç dokümana üç farklı müşterinin farklı şartları bağlanır ve doküman revize edildiğinde üç matrisin de etkilenip etkilenmediğine bakmanız gerekir. Bu bağı tabloda kurmak mümkün değil.
Sistemde tutmanın kazandırdığı asıl şey şu: şart satırı ile iç doküman arasındaki bağ canlı olur. Prosedürü revize ettiğinizde, o prosedüre bağlı müşteri şartları listelenir ve "bu revizyon şu üç müşteri şartını etkiliyor" uyarısı alırsınız. PaKalite'de CSR satırlarını doküman kayıtlarına bağlıyoruz; matris ayrı bir dosya değil, dokümanların üzerinden okunan bir görünüm oluyor. İki yöntemi maliyet ve denetim açısından yan yana koyduğumuz karşılaştırma yazımız kararı vermenize yardımcı olabilir. Nereden başlarsanız başlayın, kurmanız gereken ilk şey CSR matrisi değil, o matrisi kimin güncelleyeceğine dair net bir cevaptır.