Gözetim denetiminin ikinci saatiydi. Denetçi kalite politikasını okudu, hedefleri sordu, sonra tek bir cümleyle konuyu değiştirdi: "Geçen yılki YGG kararlarından hangisi kapandı, bana gösterin." Odada üç dakika sessizlik oldu; kararlar toplantı tutanağının içinde bir paragraf olarak duruyordu, takip eden bir kayıt yoktu. Bulgu kaçınılmazdı. ISO 9001'in maddeleri aslında tam da böyle bağlantı noktalarında sınanır ve bir kalite yönetim sistemi yazılımı en çok orada işe yarar: kararı kayda, kaydı sorumluya, sorumluyu termine bağlar. Bu yazıda standardın madde 4'ten madde 10'a kadar olan şartlarını yazılım karşılığıyla birlikte ele alıyoruz.
ISO 9001 kalite yönetim sistemi yazılımı ne işe yarar?
Standardın istediği şey sürekli üretilen kanıttır. Politika yazmak bir kerelik iştir; ama süreç performansını izlemek, uygunsuzluğu ele almak, tetkik yapmak ve gözden geçirmek yıl boyunca akar. Bu akışın kâğıtta tutulması mümkün, sürdürülmesi zordur. ISO 9001'e göre kurulmuş bir kalite yönetim sistemi yazılımı maddelerin karşılığını modüllere çevirir; her kaydın tarihi, sahibi ve durumu kendiliğinden oluşur.
Standardın maddelerine bütün olarak bakmak isterseniz ISO 9001:2015 maddeleri yazımız iyi bir başlangıç.
Madde 4 ve 5 yazılımda nasıl karşılanır?
Madde 4.1 kuruluşun bağlamını, 4.2 ilgili tarafların beklentilerini, 4.3 kapsamı ve 4.4 süreçler ile etkileşimlerini ister. Yazılımdaki karşılığı süreç kartlarıdır: her süreç için sahip, girdi, çıktı, gösterge ve bağlı dokümanlar tanımlanır. Bağlam ve ilgili taraf analizleri de kayıt olarak tutulur; yıllık gözden geçirmede geçmiş sürüm karşılaştırılabilir.
Madde 5.1 liderlik, 5.2 kalite politikası ve 5.3 rol, sorumluluk ve yetkilerle ilgilidir. Yazılımda politikanın yayınlanmış sürümü ve okundu bilgisi; rollerin ise yetki matrisi olarak tanımlanması beklenir. Politika metnini nasıl yazacağınızı kalite politikası nasıl yazılır yazımızda anlattık.
Madde 5.3 için küçük ama işe yarar bir uygulama şudur: yetki matrisini ayrı bir Word dosyasında değil, doğrudan yazılımın rol tanımları üzerinde kurun. Böylece kâğıttaki sorumluluk ile sistemdeki yetki aynı şey olur. Aksi halde denetimde sık görülen bir tutarsızlık ortaya çıkar: prosedürde onay yetkisi kalite müdüründeyken sistemde beş kişinin onaylayabildiği görülür.
Madde 6 ve 7 için hangi modüller gerekir?
Madde 6.1 risk ve fırsatları ele almayı, 6.2 ölçülebilir kalite hedeflerini, 6.3 ise değişikliklerin planlanmasını ister. Risk kaydı ve hedef takibi modülleri bunları karşılar; hedefler gösterge tablosuna bağlandığında yıl ortasında nerede olduğunuz kendiliğinden görünür.
Madde 7 kaynakları toplar ve yazılımın en yoğun çalıştığı bölümdür:
- 7.1.5.1 / 7.1.5.2 izleme ve ölçme kaynakları: ekipman envanteri, kalibrasyon periyodu, sertifika ve izlenebilirlik kaydı.
- 7.2 yetkinlik: görev bazlı yetkinlik matrisi, eğitim planı ve etkinlik değerlendirmesi.
- 7.3 farkındalık: politika ve hedeflerin duyurulması, okundu takibi.
- 7.5.1 / 7.5.2 / 7.5.3 dokümante bilgi: tek yürürlükteki sürüm, onay akışı, erişim yetkisi ve saklama süresi.
Kalibrasyon tarafını kalibrasyon takip programı yazımızda ayrıntılı ele aldık.
Madde 6.2 için en sık görülen hata, hedefi ölçülemez yazmaktır. "Müşteri memnuniyetini artırmak" bir niyettir. "Yıl sonunda müşteri şikâyet sayısını 24'ten 14'e düşürmek" hedeftir; yazılıma girilebilir, aylık izlenir ve YGG'de tartışılacak bir veri üretir. Hedefi sisteme girerken ölçüm formülünü de yazın; altı ay sonra kimse "bunu nasıl hesaplıyorduk" diye sormasın.
Madde 8 operasyon şartları nasıl yönetilir?
Operasyon maddesi üretim sahasına en yakın olanıdır. 8.1 operasyonel planlama ve kontrol, 8.2 müşteri şartlarının gözden geçirilmesi, 8.3 tasarım ve geliştirme, 8.4 dışarıdan sağlanan proses ve ürünlerin kontrolü, 8.5.1 üretim ve hizmet sunumunun kontrolü, 8.5.2 tanımlama ve izlenebilirlik, 8.6 ürün ve hizmetlerin serbest bırakılması, 8.7 uygun olmayan çıktının kontrolü.
| Madde | Şart | Yazılım karşılığı |
|---|---|---|
| 8.2 | Müşteri şartlarının gözden geçirilmesi | Sipariş/şartname gözden geçirme kaydı |
| 8.4.1 | Tedarikçi kontrolü ve değerlendirme | Tedarikçi listesi, puanlama, PPM izleme |
| 8.5.1 | Kontrollü şartlarda üretim | Kontrol planı, talimat erişimi, proses kaydı |
| 8.5.2 | Tanımlama ve izlenebilirlik | Parti/lot kaydı, etiket, geri izleme |
| 8.6 | Serbest bırakma | Son kontrol onayı ve yetkili imzası |
| 8.7 | Uygun olmayan çıktı | Karantina, karar kaydı, bertaraf/tamir izi |
Tedarikçi tarafını tedarikçi performans yazılımı yazımızda derinleştirdik.
Madde 9 ve 10 performans ve iyileştirmede yazılım ne yapar?
Madde 9.1 izleme, ölçme, analiz ve değerlendirme; 9.2 iç tetkik; 9.3 yönetimin gözden geçirmesi. Madde 10.2 ise uygunsuzluk ve düzeltici faaliyeti tarif eder ve dikkat edilmesi gereken bir ayrıntı taşır: 10.2.1 uygunsuzluğun kontrol altına alınmasını ve sonuçlarıyla başa çıkılmasını, kök nedenin incelenmesini ve benzer uygunsuzlukların olup olmadığının değerlendirilmesini ister. Yani "hatalı parçayı ayırdık" cevabı düzeltici faaliyet sayılmaz.
Yazılım burada üç şeyi otomatikleştirir: tetkik programının takvime bağlanması, bulguların doğrudan DÖF'e dönüşmesi ve YGG girdilerinin (madde 9.3.2) hazır rapor olarak toplanması. Denetçinin başta sorduğu "geçen yılki karar kapandı mı" sorusunun cevabı da böylece iki tıkla verilir. İç tetkik kurgusunu KYS iç denetim yazımızda bulabilirsiniz.
Madde 9.3.2 yönetimin gözden geçirmesinin girdilerini tek tek sayar: önceki gözden geçirme kararlarının durumu, iç ve dış hususlardaki değişiklikler, müşteri memnuniyeti ve ilgili tarafların geri bildirimi, kalite hedeflerinin karşılanma derecesi, proses performansı ve ürün uygunluğu, uygunsuzluklar ve düzeltici faaliyetler, izleme ve ölçme sonuçları, tetkik sonuçları, dış tedarikçilerin performansı, kaynak yeterliliği, risk ve fırsat aksiyonlarının etkinliği, iyileştirme fırsatları. On iki başlık. Bunları yılda bir kez elle derlemek birkaç gün sürer; yazılımda hepsi zaten kayıt olarak durduğu için toplantı girdisi tek bir rapordan çıkar.
Yazılım kullanan firmalarda denetçinin favori kontrolü şudur: rastgele bir DÖF açar ve kök neden alanına bakar. Orada "operatör dikkatsizliği" yazıyorsa, sistemin ne kadar modern olduğunun önemi kalmaz; madde 10.2.1'in kök neden şartı karşılanmamıştır. Yazılım kök neden yöntemini (5 neden, balık kılçığı) zorunlu alan yaparsa bu bulgu büyük ölçüde önlenir.
Belgelendirmeye giderken nelere dikkat edilmeli?
Yazılıma yeni geçmiş bir firmanın ilk belgelendirme denetimi biraz farklı geçer. Denetçi genellikle geçiş tarihinden önceki kayıtları da görmek ister. Bu yüzden göç sırasında eski kayıtların tarihlerini koruyun; sistemin açılış tarihiyle damgalanan bir arşiv, izlenebilirliği zayıflatır. Aynı şekilde geçiş dönemine ait paralel kayıtları (bir süre hem kâğıt hem sistem tutulan dönemi) ayıklamadan bırakmayın; iki farklı kaynakta iki farklı sonuç görmek denetimde açıklaması en zor durumlardan biridir. Süreç boyunca izlenecek adımları ISO 9001 belgelendirme süreci yazımızda sıraladık. Otomotivde çalışıyorsanız ek şartlar için IATF 16949 kalite yönetim sistemi yazılımı yazısına geçin.