Kalite müdürü 1 Ağustos'ta iki haftalık izne çıktı. 15 Ağustos'ta döndüğünde onay kuyruğunda 14 doküman bekliyordu; bunların dördü yeni müşteri projesinin iş talimatıydı ve üretim bu süre boyunca bir önceki revizyonla çalışmıştı. Kimse kötü niyetli değildi: sistemde onay yetkisi tek bir kişiye bağlıydı ve o kişi yoktu. İşte bir doküman onay iş akışı tam olarak bu senaryoya göre kurulur; normal günlerde değil, birinin olmadığı günlerde ayakta kalıyorsa doğru kurulmuştur.
Standart onaydan ne istiyor?
Bir dokümanın yayınlanmadan önce uygunluk ve yeterlilik açısından gözden geçirilip onaylanması, ISO 9001'in dokümante bilgiyi ele alan 7.5.2 maddesinin doğrudan şartıdır. Madde metni kaç imza atılacağını söylemez; "yetkili biri baktı ve uygun buldu" kaydını arar. IATF 16949 buna kayıtların saklanması şartını ve kontrol planının müşteri onayına tabi olabilmesini ekler. Yani doküman onay iş akışı bir bürokrasi katmanı değil, dokümanın doğruluğunu kimin teyit ettiğinin izidir.
Pratikte bunun karşılığı üç roldür: hazırlayan içeriği yazar, kontrol eden teknik doğruluğu ve diğer dokümanlarla tutarlılığı bakar, onaylayan yürürlüğe girmesine karar verir. Bu üçlünün ayrılması, aynı kişinin hem yazıp hem onaylamasını engeller. Küçük firmalarda kontrol eden ile onaylayanın aynı kişi olduğu durumlara sık rastlanır; bu da denetimde açıklanması gereken bir noktadır.
Akışı kurmadan önce: doküman türü matrisi
Doküman onay iş akışı kurgulanırken en sık yapılan hata, bütün dokümanlara tek bir zincir tanımlamaktır. Kalite el kitabıyla bir kontrol formunun aynı zincirden geçmesi, formun üç hafta beklemesine yol açar. Doğru başlangıç, doküman türü bazında bir matris çizmektir. Bu matris hem sistemde kural olarak tanımlanır hem de doküman yönetimi prosedürünün eki olur.
| Doküman türü | Hazırlayan | Kontrol eden | Onaylayan | Hedef süre |
|---|---|---|---|---|
| Kalite el kitabı | Kalite yöneticisi | Süreç sahipleri | Genel müdür | 15 iş günü |
| Prosedür | Süreç sahibi | Kalite yöneticisi | Bölüm müdürü | 10 iş günü |
| İş talimatı | Üretim mühendisi | Vardiya amiri | Üretim müdürü | 5 iş günü |
| Form | Süreç sahibi | — | Kalite yöneticisi | 3 iş günü |
| Kontrol planı | Kalite mühendisi | Üretim müdürü | Kalite yöneticisi | 7 iş günü |
Tablodaki hedef süreler süs değildir; sistemde zaman aşımı kuralının dayanağıdır. Bir iş talimatı beş iş gününde yayınlanacaksa, üçüncü günde hatırlatma, beşinci günde üst amire eskalasyon kurulur. Kontrol planı gibi başka kayıtlara bağlı dokümanlarda zinciri kurarken kontrol planı revizyon mantığını da hesaba katın; PFMEA değişikliğinden doğan bir revizyon, form onayından farklı bir hızla ilerlemelidir.
Vekalet kuralı: kuyruğun kilitlenmemesi için
Yukarıdaki 14 dokümanlık tıkanmanın tek çözümü vekalettir. Vekalet, sistemde başlangıç ve bitiş tarihi olan bir kayıt olarak tanımlanmalıdır. "Ali Bey yokken Ayşe Hanım onaylasın" sözlü mutabakatı denetimde imza yetkisi sorusunu karşılamaz. Vekilin attığı onay, doküman geçmişine "X adına vekaleten Y" biçiminde düşmeli ve vekalet tarih aralığı kayıtta görünmelidir.
Vekalette iki incelik var. Birincisi, vekil asıl onaylayanla eşdeğer yetkinlikte olmalıdır; üretim müdürünün yerine bakım teknisyenini vekil yapmak, kaydı doldurur ama onayın anlamını boşaltır. İkincisi, vekalet süresi bittiğinde kuyrukta kalan dokümanlar otomatik olarak asıl onaylayana dönmelidir. Bunu kurmazsanız, iki hafta sonra kimsenin bakmadığı bir vekil kuyruğu oluşur.
Bir tedarikçide onay akışını kurduktan sonra ilk ay 62 doküman yayınlandı, ortalama onay süresi 11 gün çıktı. Kademe kademe baktığımızda 11 günün 7 günü tek bir kontrol kademesinde geçiyordu: teknik müdür haftada bir gün fabrikadaydı. Çözüm yazılımda değildi; o kademeyi proses mühendisine devrettik ve süre 4 güne indi. Onay akışı ölçülmeden düzeltilmez.
Ret senaryosu: doküman nereye düşer?
Onay akışının en çok ihmal edilen dalı rettir. Kural nettir: ret her zaman hazırlayana döner, bir önceki onaycıya değil. Ret gerekçesi zorunlu alan olmalıdır; "uygun değil" yazan bir ret, hazırlayana hiçbir şey söylemez ve doküman iki tur daha döner. Gerekçe metni dokümanın revizyon geçmişinde kalıcı olarak saklanır, çünkü bir yıl sonra "bu talimat neden iki kez geri döndü?" sorusunun cevabı oradadır.
İkinci kural: hazırlayan düzeltip yeniden gönderdiğinde akış baştan başlar. Daha önce onay vermiş kademelerin onayı düşer, çünkü inceledikleri metin artık değişmiştir. Bunu atlayan kurgularda, ilk kademede onaylanan bir metnin son kademede tamamen değişmiş hâli, ilk onaycının imzasıyla yayınlanır. Denetçi revizyon geçmişini açtığında bu tutarsızlığı görür.
Zaman aşımı, hatırlatma ve eskalasyon
Elektronik doküman onayının kâğıda göre asıl üstünlüğü, beklemenin görünür olmasıdır. Klasördeki bir dosya kimseye "üç gündür bekliyorum" demez; sistemdeki kayıt der. Kurulumda üç kural yeterlidir: hedef sürenin yarısında ilgili kişiye hatırlatma, hedef sürede ikinci hatırlatma ve amire bilgi, hedef sürenin iki katında otomatik eskalasyon. Eskalasyonun ne anlama geldiğini prosedürde yazın; onay yetkisi bir üst kademeye geçiyor mu, yoksa sadece bilgilendirme mi yapılıyor?
Hatırlatmaları günde bir e-postayla sınırlayın. Her doküman için ayrı bildirim gönderen sistemler, üç gün içinde spam klasörüne düşer ve onay bekleyen doküman takibi tamamen işlevsizleşir. Kişiye günde tek bir özet gitmesi, içinde bekleyen dokümanların listesi ve gün sayısı olması yeterlidir.
Seri mi, paralel mi onay?
Seri onayda doküman kademeleri sırayla dolaşır: kontrol eden onaylamadan onaylayanın önüne düşmez. Paralel onayda ise aynı anda birden fazla kişiye gider ve hepsi onay verince tamamlanır. İkisinin de yeri var. Teknik doğruluğun kademeli olarak inşa edildiği prosedürlerde seri akış doğrudur; birden fazla bölümün görüş verdiği kontrol planı ya da ambalaj talimatı gibi dokümanlarda paralel akış süreyi belirgin biçimde kısaltır.
Paralel akışta iki kural koyun. Birincisi, bir kişinin reddi tüm turu düşürür ve doküman hazırlayana döner; "üç kişiden ikisi onayladı, yeterli" mantığı kalite dokümanında kabul edilemez. İkincisi, paralel kademedeki kişi sayısını dörtle sınırlayın. Altı kişilik bir paralel kademe, pratikte en yavaş kişinin hızıyla çalışır ve seri akıştan daha uzun sürer.
Bir de karma kurgu var ve doküman onay iş akışını en verimli hâle getiren de genelde budur: kontrol kademesi paralel, onay kademesi tek kişi. Görüş verecek herkes aynı anda bakar, nihai kararı tek yetkili verir. Kontrol planı gibi çok fonksiyonlu bakış gerektiren dokümanlarda bu kurgu, hem standardın beklediği çok disiplinli değerlendirmeyi karşılar hem de kuyruğu uzatmaz.
Acil revizyon için hızlı yol
Müşteriden gelen bir 8D kapanışı ya da sahada tespit edilen bir güvenlik riski, bazen dokümanın aynı gün değişmesini gerektirir. Normal akışın beş iş günü sürdüğü bir sistemde bu mümkün değildir ve insanlar sistemi atlayarak elle düzeltme yapar. Bunu önlemenin yolu, akışı esnetmek değil, tanımlı bir acil revizyon yolu kurmaktır.
Acil yolun üç şartı olmalı. Birincisi, kim başlatabileceği isim isim yazılı olsun; genelde kalite yöneticisi ve üretim müdürü yeterlidir. İkincisi, gerekçe zorunlu alan olsun ve dokümana kalıcı olarak işlensin. Üçüncüsü, acil onayla yayınlanan doküman için sistem otomatik bir takip görevi açsın: 10 iş günü içinde normal akıştan geçirilip teyit edilecek. Bu üçüncü şart olmadan acil yol, zamanla varsayılan yola dönüşür.
Acil revizyon sayısını da ölçün. Ayda 20 dokümanın 6'sı acil yoldan geçiyorsa sorun aciliyette değil, normal akışın süresindedir. Bu oran, onay zincirinin gereğinden uzun kurulduğunun en güvenilir işaretidir ve iyileştirme için düzeltici faaliyet açmaya değer bir veridir.
Onay süresini ölçmek
Akış kurulduktan sonra iki gösterge yeterlidir. Birincisi gönderimden yayına kadar geçen toplam gün; ikincisi kademe bazında bekleme süresi. İkinci gösterge tıkanan yeri tek bakışta gösterir ve tartışmayı kişiselleştirmekten çıkarır. Kuyrukta 10 günü aşan doküman sayısını haftalık izleyin ve yönetimin gözden geçirmesine somut veri olarak götürün.
Bu iki gösterge aynı zamanda sistemin gerçekten kullanıldığının kanıtıdır. Ortalama onay süresi 2 güne düşmüş ama yayınlanan doküman sayısı ayda 3'e inmişse, insanlar dokümanı revize etmekten vazgeçmiş demektir; bu iyi bir haber değildir. Kalite yönetim yazılımı seçerken bu iki raporun hazır gelip gelmediğine bakın, çünkü sonradan eklemek genellikle zordur.
Akışı prosedürde nasıl yazarsınız?
Sistemde kurduğunuz doküman onay iş akışı, doküman yönetimi prosedürüne birebir aynı biçimde yazılmalıdır. Denetçi ikisini karşılaştırır ve fark bulursa bulgu yazar; çünkü prosedür ne yaptığınızı anlatan belgedir, sistem ise nasıl yaptığınızı gösteren uygulamadır. En sık rastlanan uyumsuzluk, prosedürde "ıslak imza" yazarken sistemde elektronik onay kullanılmasıdır.
Prosedürde beş şeyin yazılı olması yeterlidir: doküman türü bazında rol matrisi, hedef onay süreleri, vekalet kuralı, ret durumunda izlenecek yol ve acil revizyon yetkisi olan görevler. Bunların hepsini prosedür metnine gömmek yerine, matrisi ek olarak vermek daha iyidir; matris değiştiğinde prosedürün tamamını revize etmek zorunda kalmazsınız, yalnızca eki güncellersiniz.
Bir de elektronik onayın geçerliliği meselesi var. Sistemde atılan onayın kimin tarafından, hangi tarihte atıldığının kayıt altına alındığını ve kullanıcı adı-şifre ile kimlik doğrulaması yapıldığını prosedürde açıkça belirtin. Bu cümle, "ıslak imza olmadan bu onay geçerli mi?" sorusunun cevabıdır ve denetimde bir kez sorulur, bir daha sorulmaz. Onay kaydının doküman kimliğiyle nasıl eşleştiği konusunda doküman yönetimi çerçevesi yol gösterir.
Kurulumda en sık yapılan dört hata
Birincisi, herkesi onaycı yapmak. Onay kademesine eklenen her kişi süreyi uzatır ve sorumluluğu dağıtır; "beş kişi baktı" demek, kimsenin dikkatle bakmadığı anlamına gelir. İkincisi, vekaleti tanımlamamak. Üçüncüsü, ret gerekçesini serbest bırakmak. Dördüncüsü ise dokümanın yayın tarihini onay tarihiyle karıştırmak: onay 12 Mart'ta alınmış olabilir ama yayın, eğitim ve dağıtım tamamlandıktan sonra 18 Mart'ta yürürlüğe girer. Bu iki tarihi ayrı tutmayan sistemlerde, sahada henüz dağıtılmamış bir doküman geçerli görünür.
Doküman onay iş akışı bittiği yerde dağıtım başlar: onaylanan doküman kime gidecek, kim okuduğunu teyit edecek? Bu iki adım birbirinin devamıdır; ayrı ayrı kurgulandığında arada doküman kaybolur. Dağıtım tarafı için dağıtım listesinin dondurulması, kod yapısı için ise kodlama sistemi yazısı işinizi görür. Onayla dağıtımın aynı platformda yürümesi, yayın tarihinde hangi revizyonun kime gittiğini ikinci bir yere kaydetme zahmetini ortadan kaldırır.