Yönetimin gözden geçirmesi toplantısının kırk beşinci dakikasında genel müdür slaytı durdurdu: "Şu iç ret oranı yüzde 2,4 diyor. Geçen çeyrek sunumda 1,9'du, ama o zaman da düşüyor demiştik. Hangi rakam doğru?" Kalite müdürünün elindeki sunum üç ayrı Excel'den elle birleştirilmişti; birinde hurda dahil, diğerinde değildi. Toplantı orada raydan çıktı ve gerçek gündem hiç konuşulamadı. Bir kalite yönetim sistemi yazılımı bu tartışmayı baştan bitirir; çünkü rakam sunum hazırlanırken değil, olay kaydedilirken oluşur. Bu yazıda göstergeleri nasıl seçeceğinizi, madde 9.1.1 ve 9.3.2 şartlarını yazılımın nasıl karşıladığını ve işe yarayan bir kalite panosunun neye benzediğini anlatıyoruz.
Kalite raporlaması neden elle hazırlandığında bozulur?
Elle hazırlanan raporun sorunu yorgunluk değil, zaman kayması. Veri ayın sonunda toplanır, iki hafta sonra sunulur, karar üç hafta sonra alınır. O noktada problem ya kendiliğinden geçmiştir ya da büyümüştür. İkinci sorun tanım kaymasıdır: iç ret oranını hesaplayan kişi değişince payda değişir ve trend anlamını yitirir. Üçüncüsü izlenebilirlik yokluğudur; sunumdaki rakamın hangi kayıtlardan geldiğini kimse gösteremez.
Bir kalite yönetim yazılımı bu üç sorunu tek hamleyle çözmez ama kaynağını kurutur. DÖF açıldığında, ret kaydı girildiğinde, müşteri şikâyeti kaydedildiğinde gösterge zaten güncellenmiştir. Ay sonunda yapılan iş veri toplamak değil, veriyi yorumlamak olur.
Dördüncü ve en sinsi sorun ise raporun tek yönlü olmasıdır. Elle hazırlanan sunum donmuş bir görüntüdür; rakamın altına inemezsiniz. Toplantıda "bu yüzde 2,4'ün içinde hangi parça var?" diye sorulduğunda cevap bir sonraki toplantıya ertelenir. O erteleme her seferinde bir aksiyonun doğmamasına yol açar. Sistemden çıkan raporda ise göstergeye tıklandığında listeye, listeden tek bir kayda inilir; tartışma veriyle biter, tahminle değil.
Madde 9.1.1 yazılımdan ne bekler?
ISO 9001 ve IATF 16949 madde 9.1.1, dört soruyu yazılı olarak cevaplamanızı ister: neyi izleyeceksiniz, hangi yöntemle ölçeceksiniz, ne zaman ölçeceksiniz ve sonuçları ne zaman analiz edip değerlendireceksiniz. IATF bunu madde 9.1.1.1 ile sıkılaştırır; imalat proseslerinin istatistiksel olarak izlenmesini ve proses yeterliliği ile performansının sürdürülmesini bekler. Madde 9.1.2 müşteri memnuniyetini, 9.1.3 ise analiz ve değerlendirmeyi ekler.
Yazılım tarafında bunun karşılığı şudur: her gösterge için hesaplama formülü, veri kaynağı, ölçüm sıklığı ve hedef değeri sistemde tanımlı olmalıdır. Formül ekranda görünüyorsa tartışma biter. Proses yeterliliği tarafındaki Cp/Cpk izlemesi için Cp ve Cpk hesaplama yazımız, izleme-ölçme şartının standart tarafı için de IATF 16949 madde 9.1 rehberi işinizi görür.
Hangi göstergeleri izlemeli?
Gösterge seçerken tek ölçüt vardır: bu rakam düştüğünde birinin yapacağı somut bir iş var mı? Yoksa o gösterge süs. Aşağıdaki set, orta ölçekli bir imalatçıda genellikle yeterli oluyor.
| Gösterge | Kaynak modül | Sıklık | Tipik hedef |
|---|---|---|---|
| Müşteri şikâyeti (PPM) | DÖF / şikâyet | Aylık | < 50 PPM |
| İç ret / hurda oranı | Kalite kontrol | Haftalık | < %1,5 |
| DÖF kapanma süresi | DÖF | Aylık | Ortalama < 30 gün |
| Zamanında teslimat | ERP / sevkiyat | Aylık | > %98 |
| Kalibrasyonu geciken ekipman | Kalibrasyon | Haftalık | 0 adet |
| Tedarikçi kabul oranı | Tedarikçi | Aylık | > %97 |
| Açık tetkik bulgusu | Denetim | Aylık | Gecikmiş: 0 |
Tedarikçi tarafındaki PPM hesabının nasıl kurulduğunu PPM hesaplama yazısında, gösterge seçiminin sistem tarafındaki mantığını ise KYS performans göstergeleri sayfasında ayrıntılı bulabilirsiniz.
Bir pres atölyesinde iç ret oranı aylardır yüzde 2 civarında yatay gidiyordu ve kimse rahatsız değildi. Yazılıma geçip veriyi operasyon kırılımında görünce tablo değişti: ortalamayı tek bir kalıp taşıyordu, o kalıpta oran yüzde 11'di. Ortalama rakam üç yıl boyunca sorunu gizlemişti. Panonuzda bir gösterge yataysa, kırılıma inin; genelde altında hareketli iki uç vardır.
YGG raporu yazılımdan nasıl çıkar?
Madde 9.3.2, yönetimin gözden geçirmesine hangi girdilerin geleceğini tek tek sayar: önceki toplantı aksiyonlarının durumu, iç ve dış hususlardaki değişiklikler, müşteri memnuniyeti ve ilgili tarafların geri bildirimi, kalite hedeflerine ulaşma derecesi, proses performansı ve ürün uygunluğu, uygunsuzluklar ve düzeltici faaliyetler, izleme ve ölçme sonuçları, tetkik sonuçları, dış tedarikçi performansı, kaynakların yeterliliği, risk ve fırsatlara yönelik faaliyetlerin etkinliği, iyileştirme fırsatları. IATF buna madde 9.3.2.1 ile maliyet, saha başarısızlıkları ve müşteri karnesi gibi ek girdiler koyar.
Bu liste elle hazırlandığında iki üç gün sürer. Bir kalite yönetim sistemi yazılımı kurulduğunda ise şablon zaten madde sırasına göre tanımlıdır ve her bölüm ilgili modülden beslenir. Kalite müdürünün işi rapor üretmek değil, yorum satırlarını yazmak ve karar önerilerini hazırlamak olur. Toplantı sürecinin standart tarafı için yönetimin gözden geçirmesi yazımıza bakabilirsiniz.
İşe yarayan bir kalite panosu nasıl kurulur?
Pano tasarımında sık yapılan hata her şeyi tek ekrana sığdırmaya çalışmaktır. Rol bazlı üç katman genellikle daha iyi çalışır:
- Vardiya amiri panosu: bugün ve bu hafta. Açık ret kayıtları, bekleyen ilk parça onayları, süresi dolan ölçü aletleri. Aksiyon penceresi saatlerdir.
- Kalite müdürü panosu: bu ay ve son 12 ay. Gösterge trendleri, geciken DÖF listesi, açık tetkik bulguları, tedarikçi karneleri. Aksiyon penceresi haftalardır.
- Üst yönetim panosu: çeyreklik. Hedefe ulaşma yüzdeleri, kalitesizlik maliyeti, müşteri karnesi, kaynak talepleri. Aksiyon penceresi aylardır.
- Uyarı kuralları: panoya bakılmasa da bilgi gitmelidir. Hedef ihlali, geciken aksiyon ve tekrar eden uygunsuzluk için otomatik bildirim kurun.
Raporun görsel tarafına dair ayrıntıları kalite yönetim yazılımı raporlama yazımızda ele aldık.
Denetçi panodaki yeşil kutulara uzun bakmaz. Kırmızı olan bir göstergeyi seçer ve sorar: "Bu hedefin altında kalmış. Buna karşı ne yaptınız, aksiyonu nerede görebilirim?" Göstergeden aksiyona geçilemiyorsa madde 9.1.3 ve 10.2 tarafında soru derinleşir. Tersi de doğru: her göstergesi yeşil olan bir panoda denetçinin ilk düşüncesi hedeflerin fazla gevşek konduğu olur. En sağlam duruş, birkaç kırmızı gösterge ve her birinin altında açık, sorumlusu ve termini olan bir aksiyon listesidir.
Raporlamayı yazılıma taşırken nelere dikkat etmeli?
Önce tanımları dondurun. Her göstergenin pay ve paydası tek cümlelik açıklamayla sistemde yazılı olsun; aksi hâlde altı ay sonra aynı tartışma geri gelir. Sonra veri kaynağını teke indirin; aynı bilgiyi hem ERP'den hem elle giriyorsanız fark kaçınılmazdır. Geçmiş veriyi taşırken de seçici olun. Beş yıllık ham kaydı aktarmak yerine, göstergelerin son 12-24 aylık aylık özetini girmek trend çizgisini kurmaya yeter ve göçü haftalardan günlere indirir.
Son olarak hedefleri sistemde tarihli tutun. Hedef yıl içinde değişebilir; eski hedefi silmek yerine geçerlilik tarihiyle saklayın. Denetçi geçmiş bir aya baktığında o dönemde hangi hedefin geçerli olduğunu görmek ister. Bu ayrıntı basit görünür ama madde 6.2 kalite hedefleri ile madde 9.1.1 izleme arasındaki bağı kanıtlayan tek şeydir.