QDMS Seçerken Sorulacak 20 Soru: Kontrol Listesi

Demo toplantısı bir saat sürdü, ekranlar akıcıydı, herkes memnun ayrıldı. Altı ay sonra denetçi masaya bir prosedürün iki revizyonunu koyup "neyin değiştiğini gösterin" dediğinde sistemde böyle bir ekran olmadığı anlaşıldı. Çünkü demoda kimse bunu istememişti. QDMS nasıl seçilir sorusunun cevabı satıcının sunumunda değil, sizin hazırladığınız test listesindedir. Aşağıdaki 20 soru, demoda satıcıya anlattırılacak değil yaptırılacak testlerdir; her birinin altında o testin hangi denetim şartını koruduğu yazıyor. QDMS nasıl seçilir tartışmasını bitiren şey, ekranda canlı görülmüş bir testtir.

Demoya girmeden önce hazırlamanız gereken üç dosya

Demoyu satıcının hazırladığı örnek veriyle izlemek en büyük hatadır. Örnek veri her zaman temizdir; sizin dokümanlarınız değildir. Toplantıdan önce şunları hazırlayın: gerçek bir prosedürünüzün iki farklı revizyonu, geçen yıl kapanmış bir müşteri şikâyeti dosyası ve güncel doküman master listenizin bir kesiti. Satıcıdan bu üç dosyayı demo sırasında sisteme girmesini isteyin. Bir QDMS demosunun değeri, kendi verinizle çalıştırılıp çalıştırılamadığıyla ölçülür.

Toplantıya kimlerin katılacağı da sonucu belirler. Kalite yöneticisi, doküman sorumlusu, bir üretim şefi ve bilgi işlemden bir kişi masada olmalı. Üretim şefi olmadan yapılan demolarda sahadaki kullanılabilirlik hiç test edilmez; sistem canlıya alındığında da tıkanma tam orada başlar. Süreyi iki saatten kısa tutmayın.

Bir de şu kuralı koyun: klavyeyi demonun bir bölümünde siz kullanın. Satıcı ekranı gezdirdiğinde her şey akıcı görünür, çünkü yolu ezbere bilir. Aynı işlemi ilk kez gören bir doküman sorumlusu yaptığında kaç tıkla bittiğini, hangi alanın zorunlu olduğunu ve hata mesajının anlaşılır olup olmadığını görürsünüz. Sistemi günde otuz kez açacak kişi sizin ekibinizdeki o kişidir; onun kaç saniyede kayıt girdiği, satıcının kaç saniyede girdiğinden çok daha anlamlı bir ölçüdür.

Doküman kontrolü: 1-6. sorular

1. Aynı prosedürün iki revizyonunu tek ekranda karşılaştırın. Neyin değiştiğini satır satır görebiliyor musunuz? ISO 9001 7.5.3.2 değişikliklerin kontrolünü ister; denetçinin ilk sorduğu şey de budur.
2. Yürürlükten kalkmış bir dokümanı arayın. Sistem onu bulup "geçersiz" damgasıyla gösteriyor mu, yoksa tamamen mi siliyor? Eski nüsha saklanmalı ama yanlışlıkla kullanılamamalı.
3. Bir dokümanı yayınlayın ve master listenin kendiliğinden güncellenmesini izleyin. Liste elle tutuluyorsa o sistem doküman yönetimi yapmıyor, dosya saklıyor demektir.
4. Dış kaynaklı bir dokümanı sisteme alın. Müşteri çizimi ya da bir standart kopyası; sistem bunu ayrı bir kategoride, revizyon takibiyle tutabiliyor mu?
5. Bir dokümana saklama süresi tanımlayın. IATF 16949 7.5.3.2.1 kayıtların saklama sürelerini belirlemenizi ister. Süre dolduğunda sistem uyarıyor mu?
6. Kelime aramasını gerçek metin üzerinde deneyin. PDF'in içindeki bir cümleyi aratın. Yalnız dosya adında arama yapan sistem, 900 dokümanlık arşivde işe yaramaz.

Bu altı testin ortak amacı şu: dokümanın kendisini değil, dokümanın etrafındaki kontrolü görmek. Dosya saklamayı her paylaşım klasörü yapar; farkı revizyon geçmişi, geçersiz nüshanın işaretlenmesi ve listenin kendiliğinden güncellenmesi yaratır. Üçüncü test özellikle önemli, çünkü elle tutulan bir master liste er ya da geç dokümanın gerçek revizyonuyla ayrışır ve denetçi bu ayrışmayı gördüğü anda listenin tamamına güvenmemeye başlar. Bu konudaki ayrıntıyı doküman yönetimi sayfamızda ele aldık.

Onay akışı, yetki ve okundu kaydı: 7-11. sorular

7. Üç kademeli bir onay akışı kurdurun. Hazırlayan, kontrol eden, onaylayan. Akışı ekranda canlı tanımlayabiliyorlar mı, yoksa bu iş "geliştirme talebi" mi oluyor?
8. Onaycı izinde olsun. Vekâlet devri var mı? Vekâlet devri olmayan sistemlerde bayram tatilinde onay bekleyen dokümanlar birikir.
9. Bir kullanıcıya yalnız okuma yetkisi verin. O kullanıcı dokümanı indirebiliyor mu, yazdırabiliyor mu, yazdırdığında üzerine "kontrolsüz kopya" ibaresi düşüyor mu?
10. Yayınlanan dokümanın okundu kaydını çıkarın. Yeni revizyonu kimin okuduğunu, kimin okumadığını listeleyebiliyor musunuz? Bu liste denetimde en çok istenen çıktılardan biridir.
11. Onay geçmişini bir kayıt olarak dışa aktarın. Kim, ne zaman, hangi sürümü onayladı bilgisi sistemden çıkmıyorsa, sistemin kendisi kanıt üretmiyor demektir.

Onuncu soruyu atlamayın. Revizyon çıkarmak kolay kısımdır; zor olan, o revizyonun okunduğunu kanıtlamaktır. Denetim sırasında sahadaki nüshanın numarasıyla sistemdeki okundu kaydı yan yana konur ve ikisinin tutması beklenir. Okundu kaydı üretmeyen sistemlerde bu kanıtı imza föyleriyle toplamaya çalışırsınız; föyler ise her zaman eksik çıkar. On birinci soru sistemin kendi ürettiği kanıtla ilgili: onay geçmişi dışa aktarılamıyorsa denetim öncesi ekran görüntüsü biriktirmeye başlarsınız, bu da işin özüne aykırıdır.

Denetim, DÖF ve kök neden bağı: 12-15. sorular

12. Yıllık iç denetim programını sisteme girdirin. Program takvimi, denetçi ataması ve süreç kapsamı ekranda mı? ISO 9001 9.2 iç denetim programının planlanmasını ister.
13. Bir denetim bulgusundan düzeltici faaliyet açtırın. Bulgu ile DÖF kaydı arasında bağ kuruluyor mu, yoksa iki ayrı kayıt mı doğuyor?
14. DÖF içinde kök neden analizi ekranı isteyin. 5 Neden ya da balık kılçığı sistemin içinde mi, yoksa ekli Word dosyası olarak mı duruyor? Ekli dosya, analizin raporlanamaz olması demektir.
15. Kapatılmış bir DÖF'ün etkinlik doğrulamasını gösterin. Faaliyet kapandıktan 60 gün sonra sistem etkinlik kontrolü için görev açıyor mu? Etkinlik doğrulaması olmayan DÖF süreci denetimde bulgu alır.

On dördüncü soruda en sık aldığımız cevap şu oluyor: "Analiz dosyasını kayda ekleyebilirsiniz." Ekleyebilirsiniz elbette, ama o zaman geçen yıl açılan 40 DÖF'ün kaç tanesinde kök nedenin insan faktörü, kaç tanesinde makine kaynaklı çıktığını hiçbir zaman raporlayamazsınız. Yönetimin gözden geçirmesine götüreceğiniz eğilim analizi tam da bu veriden doğar. Kök neden alanları sistemin içinde tanımlıysa aynı hatanın farklı hatlarda tekrar ettiğini bir raporla görürsünüz; ekli dosyada ise ancak birileri hatırlarsa fark edilir.

Otomotiv gereksinimleri: 16-18. sorular

16. Müşteri özel şartlarını (CSR) nereye kaydedeceğinizi sorun. IATF 16949 4.3.2 müşteri özel şartlarının kalite yönetim sisteminize dahil edilmesini ister. Sistem CSR'ı müşteri bazında ve revizyon takibiyle tutabiliyor mu?
17. Mühendislik spesifikasyonu değişikliği senaryosu kurdurun. IATF 16949 7.5.3.2.2 müşteri mühendislik standartlarındaki değişikliklerin gözden geçirilmesi için on iş günlük bir sınır koyar. Sistem bu süreyi takip edip uyarabiliyor mu?
18. Bir ölçüm cihazının kalibrasyon kaydını açtırın. Sertifika, sonraki kalibrasyon tarihi ve cihazın hangi kontrol planında kullanıldığı bağlı mı? Kalibrasyonu geçmiş bir cihazla yapılan ölçümleri geriye dönük listeleyebiliyor musunuz?

Bu üç soru, genel amaçlı bir doküman yazılımı ile otomotiv için kurgulanmış bir sistemi ayıran yerdir. Otomotivde çalışan bir firmada QDMS değerlendirmesi bu üç sorunun cevabı alınmadan kapatılmamalı. IATF 16949 uygulayan bir tedarikçide CSR takibi ve mühendislik spesifikasyonu değişikliği, doküman kontrolünün doğal parçasıdır; sonradan eklenen bir alan değildir.

Altyapı, veri sahipliği ve destek: 19-20. sorular

19. Verinin nerede durduğunu ve nasıl geri alacağınızı sorun. Kendi sunucunuzda mı, satıcının bulutunda mı? Sözleşme sona erdiğinde doküman ve kayıtların tamamı okunabilir bir dosya seti olarak elinize geçiyor mu, bunun bir bedeli var mı? Cevabı sözleşmeye yazdırın.
20. Destek yanıt süresini ve sürüm politikasını yazılı isteyin. Kritik arızada kaç saat, normal talepte kaç iş günü? Yeni sürümler bakım bedeline dahil mi? Sürüm yükseltmesinin kapsam dışı kaldığı sözleşmeler üçüncü yılda ek fatura üretir.

On dokuzuncu soru otomotiv tedarikçileri için çoğu zaman belirleyici olan sorudur. Müşteri çizimleri, özel karakteristik listeleri ve tedarikçi performans verileri, birçok müşteri sözleşmesinde şirket dışına çıkarılamayacak bilgi kategorisindedir. Sistemi kendi sunucunuza kurmak bu yükü baştan çözer. Yirminci soruda ise sözlü teminatla yetinmeyin: "arıza durumunda hemen bakarız" cümlesi, denetim haftasında sistem açılmadığında hiçbir işe yaramaz. Saat cinsinden bir yanıt süresi ve sürüm politikası sözleşme ekine yazılsın.

Hangi soru hangi şartı koruyor

Aşağıdaki tablo, demoda yaptıracağınız testleri karşılık geldikleri şartla ve kabul kriteriyle eşleştiriyor. Toplantıya bu tabloyu çıktı alıp götürün, her satırın yanına geçti ya da kaldı yazın.

Demodan sonra ne yapmalı

Toplantı biter bitmez, hafızanız tazeyken tabloyu doldurun. Kaldı yazdığınız her satır için satıcıdan yazılı cevap isteyin: bu özellik var mı, yok mu, geliştirme kapsamında mı? Sözlü verilen "yaparız" sözleri sözleşme ekine girmediği sürece bir değer taşımaz. Yazılı cevabın altına o özelliğin hangi sürümde ve hangi tarihte geleceğini de yazdırın; tarihsiz bir taahhüt taahhüt değildir. Üç satıcıyla görüştüyseniz üç doldurulmuş tabloyu yan yana koyduğunuzda QDMS nasıl seçilir sorusunun cevabı çoğu zaman kendiliğinden çıkar. İkinci adım referans ziyareti: satıcının verdiği referansa memnuniyeti değil, sistemi kaç ayda canlıya aldıklarını, kaç doküman aktardıklarını ve son denetimde doküman kontrolünden bulgu alıp almadıklarını sorun.

Üçüncü adım maliyet tarafı. Demoda beğendiğiniz sistemin üç yıllık toplam bedelini çıkarmadan karar vermeyin; kalemleri QDMS fiyatları ve maliyet kalemleri yazısındaki tabloyla doldurabilirsiniz. Bu 20 soruyu kendi süreçlerinize göre çoğaltmak da serbest; asıl mesele soruların sayısı değil, cevapların ekranda canlı görülmüş olmasıdır. Aynı listeyi PaKalite'yi değerlendirirken de uygulayın: kapsamı modüller sayfasından karşılaştırıp her maddeyi demoda tek tek denetleyin.

Bu üç adımı tamamladığınızda QDMS nasıl seçilir sorusu artık bir tercih değil, doldurulmuş bir tabloya bakma işidir. Kararın kendisi kadar önemli olan bir şey daha var: nasıl karar verdiğinizi kayıt altına almak. Değerlendirme tablosunu, satıcı cevaplarını ve referans görüşmesi notlarını tek bir dosyada saklayın. İki yıl sonra sistemin bir eksiği tartışmaya açıldığında, o eksiğin baştan bilinip bilinmediğini yalnızca bu dosya gösterir.