Pazartesi sabahı, müşteri denetimine yedi gün kala. Kalite müdürü geçen yılın bir PPAP dosyasını açmak istiyor; dosya yerinde ama içindeki ölçüm raporu boş açılıyor. Bilgi işlem bakıyor: sunucudaki disk üç hafta önce hata vermiş, yedek görevi o günden beri sessizce başarısız oluyormuş. Kimse fark etmemiş, çünkü kimse yedeği geri yüklemeyi hiç denememiş. Bir kalite yönetim sistemi yazılımı seçerken en az modül listesi kadar önemli olan konu tam burada başlar: kayıtlarınız gerçekten korunuyor mu, yoksa korunduğunu mu varsayıyorsunuz? Aşağıda yetkilendirmeden yedek stratejisine, KVKK'dan ISO 9001 ve IATF 16949 madde 7.5.3.2 kayıt koruma şartına kadar sahada işleyen bir düzeni anlatıyoruz.
Kalite verisi neden özel bir koruma ister?
Kalite kayıtları sıradan iş dosyaları değildir. Bir ölçüm raporu, bir sapma onayı ya da bir serbest bırakma kaydı; ürün sahada sorun çıkardığında hukuki savunmanızın da dayanağıdır. Otomotivde bu kayıtların saklama süresi çoğu zaman ürünün üretim ömrü artı bir yıldır; ürün güvenliğiyle ilgili kayıtlarda çok daha uzun süreler istenir. Yani kalite verisi, muhasebe verisinden bile uzun yaşamak zorundadır.
İkinci fark bütünlük tarafındadır. Kalite kaydının değiştirilebilir olması, kaydın kendisini değersizleştirir. Geriye dönük düzeltilebilen bir kontrol formu, denetçi için kanıt değildir. Bu nedenle bir kalite yönetim sistemi yazılımı değerlendirilirken "veriyi saklıyor mu" değil, "veriyi değiştirilemez biçimde saklıyor mu" diye sorulmalıdır.
Yetkilendirme nasıl kurgulanmalı?
Sahada gördüğümüz en sık yapılandırma hatası, herkese aynı geniş yetkinin verilmesidir. "Kolay olsun" diye kurulan bu düzen, madde 7.5.2 onay şartını ve madde 8.7 uygun olmayan çıktı kontrolünü fiilen ortadan kaldırır. Çalışan bir yetki modeli şu ayrımlara dayanır:
| Rol | Görebilir | Yazabilir | Onaylayabilir |
|---|---|---|---|
| Operatör / kontrolcü | Kendi hattının kayıtları | Ölçüm ve uygunsuzluk kaydı | Yok |
| Vardiya amiri | Bölüm geneli | Aksiyon, karantina kararı | Sınırlı (bölüm içi) |
| Süreç sahibi | Kendi süreci | Talimat, kontrol planı taslağı | Kendi süreç dokümanları |
| Kalite yöneticisi | Tümü | Prosedür, DÖF kapanışı | Doküman yayını, DÖF |
| Sistem yöneticisi | Tümü + log | Kullanıcı ve yetki | Yok (ayrılık ilkesi) |
| Denetçi / misafir | Salt okunur | Yok | Yok |
Son iki satır özellikle kıymetlidir. Sistem yöneticisinin kalite onayı verememesi görevler ayrılığı ilkesidir; dış denetçiye ise salt okunur bir hesap açmak, denetim günü ekran başında geçen zamanı ciddi biçimde kısaltır. Denetim gününün kurgusunu denetim takip sistemi yazımızda ayrıntılandırdık.
Yedekleme stratejisi nasıl kurulur?
Yedekleme konuşulurken üç soru sorulur, üçünün de yazılı cevabı olmalıdır: Ne kadar veri kaybını göze alıyoruz? Sistem çöktüğünde kaç saat içinde ayakta olmalıyız? Yedeğin kendisi nerede duruyor? Uygulamada işe yarayan asgari düzen şudur:
- Gecelik tam yedek ve gün içinde saatlik artımlı yedek.
- En az bir kopya farklı fiziksel konumda; aynı sunucu odasındaki ikinci disk yedek sayılmaz.
- Şifreli saklama ve yedek dosyalarına sınırlı erişim.
- Aylık geri dönüş testi: yedekten örnek bir kayıt gerçekten geri yükleniyor mu?
- Yedek başarısızlığında bildirim: sessiz kalan yedek, olmayan yedektir.
Dördüncü madde en çok atlanandır. Yedek almak bir işlem, geri dönebilmek başka bir yetenektir. Test edilmemiş yedek, denetimde de krizde de bir işe yaramaz.
Bir metal işleme firmasında yedek görevi iki yıl boyunca düzenli çalıştı, disk doldu ve son dört ay sessizce hata verdi. Fark edildiğinde kayıp yalnızca dosyalar değildi: kalibrasyon sertifikalarının taranmış kopyaları da gitmişti. Sertifikaları laboratuvardan yeniden istemek üç hafta sürdü ve müşteri denetimi ertelendi. O günden sonra firma basit bir kural koydu: her ayın ilk salısı, rastgele seçilen bir kayıt yedekten geri yükleniyor ve sonuç kalite kayıt sistemine bir satır olarak giriliyor.
Değişmezlik ve iz kaydı neden şart?
Madde 7.5.3.2, kayıtların istenmeyen değişikliklere karşı korunmasını ister. Yazılım tarafındaki karşılığı üç mekanizmadır: onaylanan kaydın kilitlenmesi, her değişikliğin kullanıcı ve zaman damgasıyla loglanması, saklama süresi dolmadan silmenin engellenmesi. Düzeltme gerektiğinde kayıt silinmez; üzerine gerekçeli bir revizyon eklenir. Böylece madde 7.5.3.1 istendiğinde erişilebilirlik şartı da bozulmaz.
İz kaydı ayrıca DÖF süreçlerinde çok işe yarar. "Bu aksiyonu kim, ne zaman kapattı?" sorusunun tek tıkla cevaplanması, madde 10.2.3 kök neden ve madde 10.2.4 hata önleyici faaliyet incelemelerinde zaman kazandırır. Bu konuyu DÖF yönetim yazılımı yazımızda daha ayrıntılı işledik. Doküman tarafındaki revizyon kontrolü için doküman kontrol yazılımı yazımıza bakabilirsiniz.
KVKK ve kişisel veri tarafında ne yapmalı?
Bir kalite yazılımı sandığınızdan çok kişisel veri tutar: personel adı, sicil numarası, eğitim kayıtları, imza görüntüsü, bazen sağlık raporu bilgisi. KVKK açısından bunların işlenme amacının tanımlı, erişimin sınırlı ve saklama süresinin belirli olması gerekir. Pratik adımlar sınırlıdır ama ihmal edilir: kişisel veri içeren alanları rol bazlı gizlemek, dışa aktarılan raporlarda sicil yerine anonim kod kullanmak, ayrılan personelin hesabını silmek yerine pasife almak. Kaydın kendisi silinmez; çünkü izlenebilirlik ve madde 8.5.2 şartı geçmiş kayıtların sahibinin bilinmesini gerektirir.
Denetçi yedekleme prosedürünüzü okumakla yetinmez; "en son ne zaman geri yükleme testi yaptınız, kaydını görebilir miyim?" diye sorar. İkinci sorusu genelde yetkilerle ilgilidir: bir operatör hesabıyla oturum açıp onaylanmış bir kaydı değiştirmeye çalışır. Kayıt değişiyorsa madde 7.5.3.2 uygunsuzluğu yazılır. Üçüncü klasik soru ise şudur: "Yazılım sağlayıcınızla ilişkiniz biterse verinize ne olacak?" Yazılı bir veri teslim maddesi yoksa bu, dış kaynaklı süreç kontrolü kapsamında madde 8.4.1 tarafında bulgu haline gelir.
Erişim yönetimi günlük hayatta nasıl yürür?
Yetki matrisini kurmak bir kerelik iştir; onu güncel tutmak süreklidir. İşe giren, bölüm değiştiren ve ayrılan her personel bu matriste bir hareket demektir. Uygulamada çalışan basit bir düzen şudur: insan kaynakları çıkış formuna "sistem erişimi kapatıldı" satırı eklenir, kalite ve bilgi işlem bu satırı imzalamadan çıkış işlemi kapanmaz. Altı ayda bir de kullanıcı listesi gözden geçirilir; aktif görünen ama aylardır giriş yapmamış hesaplar pasife alınır.
İkinci düzenli iş, yetki değişikliklerinin kaydıdır. Kimin yetkisi ne zaman, kim tarafından ve neden genişletildi? Bu kayıt tutulmuyorsa, bir süre sonra herkesin her şeye eriştiği o tanıdık tabloya geri dönülür. Dış firma personeli için de ayrı bir kural gerekir: danışman ya da tedarikçi kullanıcılarına verilen hesaplar mutlaka bitiş tarihli açılmalı, süre dolduğunda otomatik kapanmalıdır. Dış kaynaklı süreçlerin kontrolü madde 8.4.1 kapsamındadır ve denetçi bu hesapların listesini sorabilir.
Bulut mu, yerel sunucu mu daha güvenli?
Bu tartışma çoğu zaman yanlış eksende yürür. Belirleyici olan sunucunun nerede durduğu değil, kimin neyi taahhüt ettiğidir. Kendi sunucu odasında çalışan bir KOBİ genelde tam zamanlı sistem yöneticisi istihdam etmez; güncellemeler gecikir, yedek testleri unutulur. Bulut tarafında bu işler profesyonel olarak yürür ama sözleşmede şu maddeler aranmalıdır: verinin tutulduğu ülke, yedek sıklığı, geri dönüş süresi taahhüdü, veri sahipliği ve hizmet sonunda dışa aktarım formatı. Karşılaştırmanın ayrıntısını bulut kalite yönetim sistemi yazımızda bulabilirsiniz.
Hangi mimariyi seçerseniz seçin, kararın kendisi bir risk kararıdır ve madde 6.1 risk ve fırsatlar kapsamında kayda geçmelidir. Kurulum aşamasında bu kararı yazılı hale getiren firmalar, bir sonraki denetimde ek kanıt aramak zorunda kalmaz; kurulum ve devreye alma planınıza bu maddeyi eklemekte fayda var.