Kontrol planı revizyonu üç haftadır kalite şefinin masasında duruyor. İki imza alınmış, üçüncüsü eksik; onaylayacak müdür iki haftalık yurt dışı ziyaretinde. Bu süre boyunca saha eski revizyonla üretim yapmaya devam ediyor ve durumu kimse ölçmüyor. Doküman onayı gecikiyor cümlesini herkes söylüyor ama kaç gün geciktiğini soran çıkmıyor. Ölçülmeyen bir gecikme, gecikme sayılmıyor.
Ölçmediğiniz süreyi yönetemezsiniz
Bu sahne bende yıllardır aynı soruyu doğuruyor: revizyonu hazırlamak iki gün sürüyorsa, onaylatmak neden üç hafta sürüyor? Cevap genelde tek bir yerde toplanıyor ve o yeri bulmak sanıldığından kolay.
Onay süresini ölçmek için karmaşık bir sisteme ihtiyacınız yok. İki tarih yeter: revizyonun onaya gönderildiği tarih ve yayına alındığı tarih. Bu iki tarihi bir yıl boyunca her doküman için kaydedin, ortalamayı hesaplayın. Yaptığım ilk ölçümlerde çıkan rakamlar çoğu firmayı şaşırtıyor; ortalama on beş günün üstüne çıkabiliyor.
Ortalamadan daha önemlisi dağılımdır. Onayların yüzde doksanı kaç günde tamamlanıyor? Ortalama sekiz gün olabilir ama uzun kuyruktaki birkaç doküman kırk gün bekliyorsa gerçek sorun oradadır. Ortalamaya bakan yönetici rahatlıyor, kuyruğa bakan yönetici sorunu görüyor.
Ölçüme başlamak için yazılıma da ihtiyacınız yok. Bir sayfalık bir kayıt tablosu ve üç aylık sabır yeterli. Ölçmediğiniz sürece doküman onayı gecikiyor cümlesi bir şikâyet olarak kalıyor; ölçtüğünüz anda bir yönetim konusuna dönüşüyor. Kâğıtla yürüyen bir sistemde bu ölçümü tutmanın kendi yükü de var; bu eşiği Excel mi QDMS mi yazımızda tartışmıştık.
Süreyi adım adım kırın
Toplam süre gerçeği gizler. Onay akışını adımlara ayırıp her adımın süresini ayrı ölçün. Aşağıdaki tablo, üç imzalı bir akışta ölçtüğümüz gerçek bir dağılımı gösteriyor. Kendi sayılarınız farklı olacak, ama şeklin benzer çıkmasına şaşırmayın.
| Adım | Ortalama süre | En uzun | Hedef |
|---|---|---|---|
| Hazırlık ve kalite ön kontrolü | 2 gün | 5 gün | 2 gün |
| Süreç sahibi onayı | 1,5 gün | 4 gün | 2 gün |
| Üretim müdürü onayı | 9 gün | 23 gün | 3 gün |
| Kalite yöneticisi onayı | 1 gün | 3 gün | 2 gün |
| Yayın ve dağıtım | 1,5 gün | 4 gün | 1 gün |
| Toplam | 15 gün | 39 gün | 10 gün |
Tabloya bakın: darboğaz tek bir adımda. Toplam süreye bakarak "doküman süreci yavaş" demek ve herkesi sıkıştırmak, dört kişiyi boşuna rahatsız eder. Kırılım elinizde olduğunda konuşma da tek kişiyle yapılır ve genelde o kişinin gerçek bir kapasite sorunu olduğu ortaya çıkar.
Bekleyen onayları bir liste hâlinde her pazartesi sabahı ilgili müdürlere gönderin. Uzun bir rapor değil; doküman adı, kaç gündür beklediği ve kimde olduğu. Üç kolon yeter. Bunu bir tesiste uygulamaya başladığımızda ortalama onay süresi ilk ayda gözle görülür biçimde düştü ve hiçbir yeni sistem kurulmamıştı. Görünürlük tek başına davranışı değiştiriyor; kimse listede en uzun bekleyen satırın sahibi olmak istemiyor.
Kırılımı çıkarırken bir şey daha fark ediyorsunuz: gecikmenin bir bölümü onaylayıcıdan değil, dokümanın kendisinden geliyor. Eksik hazırlanmış bir revizyon onaylayıcıya gittiğinde geri dönüyor, düzeltiliyor, tekrar gidiyor. Bu gidiş gelişler tek bir uzun bekleme gibi görünüyor. Ret sayısını ayrıca sayın; yüksekse sorun hazırlık aşamasındadır ve onaylayıcıyı sıkıştırmak hiçbir işe yaramaz.
Kaç imza gerçekten gerekli
Gecikmenin en büyük kaynağı imza sayısıdır ve imzaların çoğu gereksizdir. Çoğu doküman için iki onay yeter: içeriğin doğruluğundan sorumlu süreç sahibi ve sistem uygunluğundan sorumlu kalite. Üçüncü bir imza ancak gerçek bir katkı sağlıyorsa eklenmeli.
Sırf hiyerarşi gereği eklenen imzalar iki zarar veriyor. Birincisi süreyi uzatıyor. İkincisi, sorumluluğu dağıtarak azaltıyor: beş kişinin imzaladığı bir dokümanda hiç kimse içeriği gerçekten okumuyor, herkes bir öncekinin okuduğunu varsayıyor. İçeriği okuyan kişi sayısı, imza sayısıyla ters orantılı çalışıyor.
Kontrol planı, FMEA ve müşteri onayı gerektiren dokümanlar bu kuralın istisnası. Orada çok fonksiyonlu onay zaten gerekli; IATF 16949'un kontrol planı maddesi (8.5.1.1) kontrol planının ürün, proses ya da ölçüm yönteminde değişiklik olduğunda gözden geçirilip güncellenmesini ister ve bu gözden geçirme tek bir kişinin işi değildir. İstisnayı kural hâline getirmeyin; her doküman kontrol planı değil. Kontrol planı revizyonlarının kendine özgü kurallarını kontrol planı sayfamızda ayrı ayrı ele aldık.
İmza sayısını azaltmadan önce her imzanın ne aradığını yazın. Süreç sahibi içeriğin sahada uygulanabilir olduğunu doğruluyor. Kalite, dokümanın sistem kurallarına ve referans verdiği diğer dokümanlara uygunluğuna bakıyor. Üçüncü kişi neye bakıyor? Bu soruya somut cevap veremiyorsanız o imza akıştan çıkabilir. Bu alıştırmayı yaptığımız bir firmada onay adımlarının belirgin bir bölümü tek bir toplantıda elendi.
Vekil onaylayıcı: en ucuz çözüm
Onay akışlarının kilitlenmesinin bir numaralı sebebi izin ve seyahat. Çözümü basit: vekil onaylayıcı tanımlayın. Vekalet önceden yazılı verilsin, hangi doküman tiplerini kapsadığı ve hangi tarihler arasında geçerli olduğu belirtilsin.
Sistem üzerinden yürüyen akışlarda vekalet tanımlandığında kayıt vekile otomatik düşüyor ve iz kaydında hem asıl onaylayıcı hem vekil görünüyor. Denetçi bunu sorduğunda cevap hazır oluyor. Kâğıt üzerinde yürüyen akışlarda ise vekalet çoğu zaman sözlü kalıyor ve dönüşte "ben vekalet vermedim" tartışması çıkıyor. Sahiplik ve vekaletin rol bazlı kurulmasını süreklilik yazımızda ayrıntılı anlattık.
Vekaletin bir de yetki sınırı olmalı. Vekil, asıl onaylayıcının bütün yetkilerini almak zorunda değil. İş talimatlarını onaylayabilir ama kontrol planını onaylayamaz diyebilirsiniz. Bu sınırı yazılı koyduğunuzda hem akış hızlanıyor hem de kimse taşıyamayacağı bir sorumluluğun altına girmiyor.
Sıralı mı paralel mi
Klasik akış sıralıdır: birinci onaylar, sonra ikinci, sonra üçüncü. Bu yapı gecikmeyi toplar; her adımın beklemesi bir sonrakine eklenir. Oysa çoğu durumda ikinci ve üçüncü onaylayıcının birbirini beklemesi için hiçbir sebep yoktur.
Paralel akışta doküman aynı anda iki kişiye gider ve ikisi de onayladığında ilerler. Bu değişiklik tek başına toplam süreyi ciddi biçimde kısaltıyor. Bir uyarı: paralel akış, onaylayıcılardan birinin ret vermesi durumunda ne olacağını netleştirmenizi gerektiriyor. Kural şu olsun: bir ret gelirse akış durur, doküman hazırlayana döner ve düzeltme sonrası onaylar sıfırlanır. Akış tasarımının ayrıntısını onay iş akışı yazımızda ele aldık.
Paralel akışın bir yan faydası daha var: onaylayıcılar birbirinin yorumunu görebiliyor. Süreç sahibi bir şerh düştüğünde kalite bunu okuyup kendi değerlendirmesini ona göre yapıyor. Sıralı akışta bu bilgi genelde kayboluyor, çünkü herkes yalnızca kendi adımına bakıyor. Doküman onayı gecikiyor sorununun bir parçası da bu bilgi kopukluğu.
Doküman tipine göre hedef koymak
Bütün dokümanlara aynı hedefi koymak işe yaramıyor; bir iş talimatı ile bir kalite el kitabının gözden geçirme ihtiyacı aynı değil. Aşağıdaki dağılım, orta ölçekli bir tedarikçide kurduğumuz hedef yapısı. Kendi doküman tiplerinize göre uyarlayın.
| Doküman tipi | Onay sayısı | Hedef süre | Akış |
|---|---|---|---|
| İş talimatı | 2 | 5 iş günü | Sıralı |
| Form / kayıt şablonu | 1 | 3 iş günü | Tekli |
| Prosedür | 2 | 10 iş günü | Paralel |
| Kontrol planı | 3 | 15 iş günü | Paralel |
| FMEA | 3 | 15 iş günü | Paralel |
| Kalite el kitabı | 2 | 20 iş günü | Sıralı |
Hedefleri koyduktan sonra ilk üç ay ceza uygulamayın, sadece ölçün. İnsanlar yeni bir ölçümle karşılaştıklarında önce onu manipüle etmeye çalışıyor; üç ay sabredince gerçek davranış oturuyor. Dördüncü aydan itibaren hedefin dışında kalan kayıtları gözden geçirin ve sebeplerini not edin. Sebeplerin çoğu izin, seyahat ve içerik eksikliği çıkıyor; üçünün de ayrı çözümü var.
Bekleyen revizyonun gerçek maliyeti
Onay bekleyen doküman zararsız değildir. Revizyon bir müşteri şartı değişikliğinden ya da bir düzeltici faaliyetten doğuyorsa, bekleme süresi boyunca saha bilerek eski yöntemle çalışıyor demektir. Üç haftalık bekleme, üç haftalık bilinen risk anlamına geliyor.
Bunun için acil yayın yolu tanımlayın. Sınırlı onayla yürürlüğe alma, gerekçenin kayda geçirilmesi ve normal onayın sonradan tamamlanması. Bu istisnanın kuralları prosedürünüzde yazılı olsun; yazılı değilse istisna kural hâline geliyor ve altı ay sonra bütün dokümanlar acil yayınla çıkıyor. Kaç acil yayın yapıldığını da ayrıca sayın; sayı artıyorsa asıl sorun onay süresindedir.
ISO 9001'in 7.5.2 maddesi, dokümante edilmiş bilginin oluşturulup güncellenirken uygunluk ve yeterlilik açısından gözden geçirilip onaylanmasını ister. Standart bir süre vermez; onayın yapılmış olmasını ister. Yani uzun onay süresi tek başına bulgu değildir. Bulgu iki yerden çıkar: onaysız bir dokümanın sahada kullanılıyor olması ve gecikmeyi gören, yöneten bir mekanizmanın bulunmaması. Onay süresini ölçüp gözden geçirmeye koyduğunuzda bu konu denetimde hızla kapanır.
Bir başka gizli maliyet de eğitimde ortaya çıkıyor. Revizyon yayınlandığında ilgili personelin bilgilendirilmesi gerekiyor; üç hafta geciken bir yayın, eğitim planını da üç hafta öteliyor. Vardiya devirlerinde anlatılacak değişiklik birikince kimse hepsini hatırlamıyor ve yayın sonrası ilk haftada hata sayısı artıyor.
Hedef koymak ve panoyu kurmak
Ölçüm yaptıktan sonra hedef koyun. Doküman tipine göre ayrı hedefler mantıklı: iş talimatı beş iş günü, prosedür on iş günü, kontrol planı on beş iş günü gibi. Hedefi tek bir sayıya indirmeye çalışmayın; farklı dokümanların gerçekten farklı gözden geçirme ihtiyacı var.
Panoda üç sayı bulunsun: ortalama onay süresi, hedefin içinde kalan onayların oranı ve şu an bekleyen en uzun kaydın gün sayısı. Üçüncüsü en çok işe yarayanı, çünkü bir eylem çağrısı taşıyor. Bu panoyu aylık kalite raporunun içine koyun; ayrı bir rapor hazırlamayın. Doküman yönetiminin geri kalan çerçevesini doküman yönetimi sayfamızda topladık.
Türkiye'de bu tür sistemler çoğu zaman QDMS adıyla anılıyor; QDMS aslında Bimser firmasının ürün adı ve pazarda köklü bir yeri var. Hangi ürüne bakarsanız bakın, onay süresi açısından üç şeyi test edin: vekil ataması var mı, paralel onay kurulabiliyor mu, ve onay süresi raporu hazır geliyor mu. PaKalite'de bu üçü kutudan çıkar ve bekleyen onay listesi haftalık olarak ilgili kişilere gider. Yine de bir uyarı: yazılım imza sayısını sizin yerinize azaltmaz. Doküman onayı gecikiyor sorununun yarısı akış tasarımında, yarısı araçta. Önce akışı sadeleştirin, sonra araca geçin.