Denetimin ikinci günü, saat 10.30. Denetçi kalite ofisinde masaya oturur ve tek bir şey ister: doküman master listesinin bugün alınmış çıktısı. Listeyi eline alır, rastgele üç prosedür işaretler ve doğruca üretime iner. Kaynak hattının panosunda asılı iş talimatının sağ üst köşesinde "Rev. 03 — 14.05.2025" yazmaktadır; elindeki listede aynı doküman "Rev. 05 — 02.11.2025" görünür. Doküman revizyon takibi nasıl yapılır sorusunun cevabı işte bu iki satır arasındaki farkta saklıdır. Bulgu artık kaçınılmazdır: kullanım noktasında geçersiz nüsha bulunmaktadır.
Bu sahne hayali değil, her yıl onlarca tedarikçi denetiminde neredeyse aynı cümlelerle tekrarlanıyor. İşin can sıkıcı tarafı şu: firmaların büyük çoğunluğu dokümanı gerçekten güncellemiştir. Sorun güncellemenin kendisinde değil, güncellemeden sahaya uzanan zincirin bir yerinde kopmasındadır. Aşağıda o zinciri halka halka açıyoruz — revizyon numarasının nasıl verileceğinden eski nüshanın nasıl geri çekileceğine kadar.
Standart, doküman revizyon takibinden ne ister?
ISO 9001 madde 7.5.2, dokümante bilgiyi (documented information) oluştururken ve güncellerken uygun tanımlamayı — başlık, tarih, hazırlayan, referans numarası — uygun formatı ve yayından önce uygunluk açısından gözden geçirilip onaylanmasını şart koşar. Madde 7.5.3.1 dokümanın ihtiyaç duyulan yerde ve zamanda kullanılabilir olmasını ister. Asıl can alıcı madde 7.5.3.2'dir: dağıtım ve erişimin, değişiklik kontrolünün, saklama ve elden çıkarmanın yönetilmesini; güncel olmayan dokümanların istenmeyen kullanımının önlenmesini, herhangi bir amaçla saklanacaklarsa uygun biçimde işaretlenmesini bekler.
Otomotivde çıta biraz daha yüksektir. IATF 16949 madde 7.5.3.2.2, müşteri mühendislik standart ve spesifikasyonlarındaki değişikliklerin gözden geçirilmesi, dağıtılması ve uygulanması için dokümante edilmiş bir proses ister ve bu gözden geçirmenin değişikliğin bildirilmesinden itibaren 10 iş gününü aşmamasını şart koşar. Bir müşteri resmi revize olduğunda ona bağlı kontrol planının, FMEA'nın ve iş talimatının kaç gün içinde güncellendiğini kayıtla göstermeniz gerekir. Bu süreyi tutturmanın tek yolu, hangi dokümanın hangi müşteri spesifikasyonuna bağlı olduğunu değişiklik gelmeden önce tanımlamış olmaktır. Konunun genel çerçevesini doküman yönetimi sayfamızda ayrıca açtık.
Revizyon numarası nasıl verilir?
Doküman revizyon takibi kuran her firma ilk burada takılır ve doğrusu şudur: kuralı siz koyarsınız, ama koyduğunuz kurala istisnasız uyarsınız. En sağlam yöntem, her doküman için sıfırdan başlayan ve atlamasız artan tamsayı bir seridir. İlk yayın Rev. 00 da olabilir Rev. 01 de; hangisini seçtiyseniz doküman yönetimi prosedüründe yazılı olsun ve tüm doküman türlerinde aynı uygulansın. Harf ile rakamı karıştıran seriler (A, B, 01, 1.2) birkaç yıl içinde mutlaka çakışır ve o noktadan sonra hangi nüshanın yeni olduğunu kimse söyleyemez.
"Küçük bir düzeltme yaptık, revizyon vermeyelim" cümlesi en sık görülen hatadır. Yazım hatası düzeltmesi bile olsa dosya değişmişse revizyon numarası artar. Aksi hâlde iki farklı içerik aynı revizyon numarasını taşır; sahadaki nüshayla arşivdeki nüshayı ayırmanın hiçbir yolu kalmaz. Ara sürüme ihtiyaç duyuyorsanız bunu onaylı yayın olarak değil taslak olarak tutun ve taslağın dağıtım noktalarına inmesine kesinlikle izin vermeyin.
Revizyon numarası tek başına da yetmez. Yanında iki tarih bulunmalıdır: yayın tarihi ve yürürlük tarihi. Çoğu firma ikisini aynı güne yazar, oysa yeni bir kontrol planının operatör eğitimi tamamlanmadan yürürlüğe girmesi anlamsızdır. Yürürlük tarihini yayından üç-beş gün sonraya koyup o aralıkta eğitimi bitirmek, hem denetimde hem vardiya başlangıcında işinizi kolaylaştırır. Kritik bir talimatta bu tampon süre, hatalı parça üretmekle üretmemek arasındaki farktır.
Doküman master listesi örneği: hangi alanlar bulunmalı?
Master liste denetimin ilk durağıdır, çünkü sistemin tamamının fotoğrafını tek sayfada verir. İç denetimde de dış denetimde de ilk istenen kayıt odur; listede eksik bir sütun varsa denetçi geri kalan her şeyi daha dikkatli okur. Aşağıdaki tablo listede bulunması gereken alanları, her alanın denetimde neyi kanıtladığını ve o alanda en sık yapılan hatayı gösteriyor.
| Alan | Denetimde neyi kanıtlar | En sık yapılan hata |
|---|---|---|
| Doküman kodu | Benzersiz kimlik ve süreç aidiyeti | Aynı kodun iki farklı dokümanda kullanılması |
| Güncel revizyon no | Hangi nüshanın geçerli olduğu | Listenin dosyadan geride kalması |
| Yayın tarihi | Onayın ne zaman verildiği | Onay tarihinden önce yayın tarihi girilmesi |
| Yürürlük tarihi | Sahada ne zaman geçerli olduğu | Eğitim verilmeden aynı gün yürürlüğe alma |
| Hazırlayan / Onaylayan | Yetkilendirmenin doğruluğu | Onaylayanın görevden ayrılmış olması |
| Dağıtım noktaları | Kontrollü kopyaların nerede olduğu | Fotokopiyle çoğalan kayıt dışı nüshalar |
| Sonraki gözden geçirme | Periyodik gözden geçirmenin işlediği | Tarihin yıllardır geçmiş olması |
| Bağlı süreç / standart maddesi | Kapsam boşluğu olmadığı | Alanın hiç doldurulmaması |
Master liste bir Excel dosyasında, dokümanların kendisi ayrı bir sunucu klasöründe tutulduğunda iki kayıt zamanla ayrı yaşamaya başlar. Bir mühendis dosyayı klasörde günceller ama listeyi açmayı unutur; üç ay sonra listede Rev. 04, klasörde Rev. 06 vardır. Denetimde çıkan uyumsuzluğun kök nedeni neredeyse her seferinde budur. Listeyi elle tutulan bir kayıt olmaktan çıkarıp dokümanın kendisinden türeyen bir çıktıya çevirmek, bu bulguyu tek hamlede ortadan kaldırır.
Güncel olmayan doküman kontrolü: zincirin en çok kopan halkası
Yeni revizyonu yayınlamak işin kolay yarısıdır; zor yarısı eskisini sahadan çekmektir. Kâğıt sistemde bunun tek yolu dağıtım listesidir. Her kontrollü kopyanın hangi panoda, hangi ofiste, kimde olduğu yazılı olmalı; yeni revizyon dağıtılırken eski nüsha imza karşılığı geri alınmalıdır. Geri toplama tutanağı denetimde en çok istenen kayıtlardan biridir ve çoğu firmada yoktur.
Arşiv amacıyla saklanacak tek bir eski nüsha bırakılabilir, ancak üzerinde "GEÇERSİZ" ya da "SADECE ARŞİV" ibaresi bulunmak zorundadır. Elektronik ortamda ise mantık tersine döner: eski sürümü silmezsiniz, erişimden kaldırırsınız. Kullanıcının açtığı bağlantı her zaman güncel sürümü getirir, önceki sürümler yalnızca kalite biriminin görebildiği arşivde durur. Denetçinin klasik hamlesi, sistemde bir dokümanın bir önceki sürümünü açmayı denemektir; açılıyorsa doğrudan bulgu yazar.
Panoya asılan çıktılar için pratik bir çözüm var: her sayfaya dokümanın sistemdeki adresine giden bir QR kod basmak. Operatör telefonunu okuttuğunda her zaman güncel sürümü görür, elindeki kâğıt eskimişse fark eder. Bu yöntem, kontrollü kopya sayısını da belirgin biçimde azaltır.
Revizyon geçmişi kaydı: sistemde akış nasıl ilerler?
QDMS türü bir doküman yönetim sisteminde doküman revizyon takibi, bir dosyanın üzerine yazmak değil tanımlı bir iş akışını yürütmektir. Akış revizyon talebiyle başlar: talebi kim açtı, hangi gerekçeyle — müşteri şikâyeti, DÖF çıktısı, proses değişikliği, standart revizyonu. Bu gerekçe alanı boş geçilmemelidir, çünkü denetçi "bu revizyonu neden yaptınız?" diye sorduğunda cevabınız burada durur.
İkinci adımda doküman sahibi taslağı hazırlar ve sistem otomatik olarak bir sonraki revizyon numarasını rezerve eder. Üçüncü adımda görüş verecek fonksiyonlara — üretim, bakım, iş güvenliği — görev düşer ve verdikleri görüş kayda geçer. Dördüncü adımda onay yetkilisi onaylar; onay anında kim, hangi tarihte, hangi saniyede onayladığı imza kaydına yazılır. Beşinci adımda yayın gerçekleşir: yeni sürüm dağıtım listesindeki herkese bildirilir, eski sürüm aynı saniyede arşive düşer ve master liste kendiliğinden güncellenir.
Altıncı adım çoğu firmada atlanır ama en değerlisidir: okundu bildirimi. Dağıtım listesindeki kullanıcı yeni revizyonu açıp "okudum ve anladım" işaretlediğinde, sistem kişi bazında bir kayıt üretir. Denetçi "bu talimatın yeni revizyonundan operatörler nasıl haberdar oldu?" diye sorduğunda, elinizde 14 kişilik imzalı bir liste olur. Yedinci ve son adım, dokümanın bir sonraki periyodik gözden geçirme tarihini takvime yazmaktır; tarih geldiğinde sorumluya görev düşer ve gözden geçirme sonucu "değişiklik yok" olsa bile kayda geçer.
Denetçi doküman revizyon takibini üç soruyla sınar ve üçü birbirine bağlıdır: Bu dokümanın güncel revizyonu kaç? Bu revizyonu kim, ne zaman onayladı? Önceki nüsha sahadan ne zaman toplandı? Üç soruya üç ayrı kaynaktan cevap vermek zorunda kalıyorsanız sistem değil, hafıza çalışıyor demektir. Tek bir ekranda revizyon geçmişi, onay imzaları ve dağıtım kaydı yan yana duruyorsa denetim o konu başlığında beş dakikada biter.
Doküman revizyon takibinde tekrar eden bulgular
Yıllar içinde tekrar eden bulgular şaşırtıcı biçimde aynı. En başta master listenin güncel olmaması gelir; liste ile dosya arasındaki fark tek bir örnekte bile görülse madde 7.5.3.2 uygunsuzluğu yazılır. Hemen arkasından onay kaydının eksikliği geliyor: dokümanın üzerinde bir isim vardır ama o kişinin onayladığına dair imza, tarih ya da sistem kaydı yoktur. Sahada geçersiz nüsha bulunması ise klasiktir — panolarda, tezgâh çekmecelerinde, operatörün kişisel klasöründe. Listeyi periyodik gözden geçirme tarihi kapatır; prosedürünüzde "yılda bir gözden geçirilir" yazıyorsa ve son gözden geçirme üç yıl önceyse, kendi kuralınızı ihlal etmiş olursunuz.
Bir bulgu türü daha var ve genellikle en pahalıya patlayanı odur: dokümanlar arasındaki bağın kopması. Bir kontrol planı revize edilir ama ona bağlı iş talimatı Rev. 02'de kalır; ölçüm sıklığı planda 5 parçada bir, talimatta 10 parçada bir görünür. Operatör talimata bakar, denetçi plana. ISO 9001 açısından bu tek başına bir uygunsuzluktur, otomotivde ise doğrudan ürün riski demektir. Bağlı doküman ilişkisini sistemde tanımlamak, bir doküman revize edildiğinde ona bağlı diğerlerinin sorumlusuna otomatik uyarı gitmesini sağlar.
Bu bulguların ortak kök nedeni tek: revizyon bilgisinin birden fazla yerde, elle tutulması. Kök neden çalışmasını ciddi yapan firmalar bu noktaya hızla varır; yöntem için kök neden analizi yaklaşımımıza bakabilirsiniz. Çözüm de aynı yerden gelir: revizyon numarası, onay kaydı, dağıtım listesi ve master liste tek bir kaydın farklı görünümleri hâline geldiğinde, birinin diğerinden geride kalması fiziksel olarak mümkün olmaz.
Kâğıttan sisteme geçerken nelere dikkat edilir?
Doküman yönetimini bir yazılıma taşıma kararı verdiğinizde ilk iş, mevcut kaosu olduğu gibi aktarmamaktır. Taşımadan önce master listeyi bir kez temizleyin: kullanılmayan dokümanları yürürlükten kaldırın, çift kayıtları birleştirin, kodlama mantığını netleştirin. Bu temizlik iki-üç haftanızı alır ama geçişten sonra kazandırdığı zaman katbekat fazladır; ayrıntılı planı veri taşıma rehberimizde anlattık.
İkinci dikkat noktası, revizyon geçmişinin korunmasıdır. Yeni sisteme yalnızca güncel sürümü taşırsanız, denetçi "bu dokümanın Rev. 03'ünü görebilir miyim?" dediğinde eski klasöre dönmek zorunda kalırsınız. En az son iki-üç revizyonu, onay bilgileriyle birlikte taşımak doğru olan. Kısacası doküman revizyon takibi, yazılıma geçerken en çok korunması gereken kayıttır. PaKalite'nin doküman modülü de bu mantıkla çalışır: her dokümanın revizyon geçmişi, onay imzaları ve dağıtım kaydı aynı ekranda durur, yeni sürüm yayınlandığı anda eski sürüm erişimden kalkar. Böylece denetimde master liste ile sahadaki nüshayı karşılaştırma anı, korkulan değil beklenen bir an hâline gelir.