Kaynak hattındaki bir operatör iş talimatını bulmak için sisteme girdi ve arama kutusuna müşterinin adını yazdı. Çıkan ilk sonuç iş talimatı değildi; müşteriyle imzalanmış çerçeve sözleşmenin birim fiyat ekiydi. Dosyayı açtı, birkaç saniye baktı, kapattı ve vardiya amirine söyledi. O sabah açılan kaydın başlığı "yetkisiz erişim" olmalıydı ama gerçek başlık şuydu: yanlış kopyalanmış varsayılan rol. Kimse kötü niyetli davranmamıştı. Kurulum sırasında üretim için açılan rol, kalite rolünden çoğaltılmış ve çoğaltılırken sözleşme kategorisinin okuma yetkisi üzerinde unutulmuştu. Sahada gördüğüm qdms kullanıcı yetkileri sorunlarının neredeyse tamamı bu noktadan doğuyor: yetki tek tek verilmiyor, hazır bir rolden çoğaltılıyor.
Rol kopyalamak neden bu kadar tehlikeli
Yeni bir kalite yazılımı devreye alınırken en hızlı ilerleyen adım rol tanımlamadır. Önce bir "Kalite Uzmanı" rolü açılır, içine gereken her şey konur. Sonra "Üretim Mühendisi" rolü onun kopyası olarak yaratılır, üzerinden birkaç kutucuk kaldırılır. Ardından "Bakım Şefi", "Satın Alma Uzmanı", "Depo Sorumlusu" hep aynı yöntemle çoğaltılır. Üç ay sonra sistemde on dört rol vardır ve hiçbirinin hangi rolden türediğini kimse hatırlamaz. Çoğaltma yöntemi yetki eklemeyi kolaylaştırır, eksiltmeyi ise unutturur.
Doğru sıra tam tersidir. Hiçbir yetkisi olmayan boş bir rolden başlanır ve o rolün işini yapabilmesi için gereken en az yetki tek tek eklenir. Buna en az ayrıcalık ilkesi (least privilege) denir. Bir operatörün prosedür yazma ekranını görmesi için hiçbir sebep yoktur; bakım şefinin müşteri şikâyeti dosyasını açmasına da gerek yoktur. Eksik yetki, kullanıcı birkaç saat içinde telefon açtığı için hemen fark edilir ve düzeltilir. Fazla yetki ise iki yıl boyunca kimsenin dikkatini çekmez. Yetkilendirmede asıl risk, eksikte değil fazlada saklıdır.
Yetki matrisi ekranda değil, kâğıtta kurulur
QDMS kullanıcı yetkileri kurgusuna doğrudan yazılımın yönetim ekranından başlamak en sık yapılan hatadır. Ekranda onlarca kutucuk vardır ve hepsini işaretlemek dakikalar sürer; oysa o kutucukların hangisinin kime ait olacağı bir yönetim kararıdır, teknik bir tercih değil. Önce bir tablo çizin: satırlara rolleri, sütunlara doküman ve kayıt kategorilerini yazın. Hücrelere dört harften birini koyun; O okuma, G giriş ve düzenleme, A onaylama, Y yayınlama demektir. Bu tabloyu kalite yöneticisi, süreç sahipleri ve bilgi işlem birlikte imzalasın. Aşağıdaki matris, otomotiv yan sanayide çalışan bir firmada kullandığımız iskeletin sadeleştirilmiş hâlidir.
| Rol | Prosedür / talimat | Kalite kayıtları | Müşteri sözleşmeleri | Personel dosyaları |
|---|---|---|---|---|
| Operatör | O (yalnız kendi hattı) | G (kendi kaydı) | Yok | Yok |
| Vardiya amiri | O (tüm üretim) | G + A | Yok | Yok |
| Kalite uzmanı | O + G | G + A | O | Yok |
| Süreç sahibi (müdür) | O + G + A | O + A | O | O (kendi ekibi) |
| Kalite yöneticisi | O + G + A + Y | O + A | O | O |
| Sistem yöneticisi | Y (içerik yetkisi yok) | Yok | Yok | Yok |
| Dış denetçi (süreli) | O (yayınlanmış sürüm) | O | Yok | Yok |
Tablodaki iki satır özellikle dikkat ister. Sistem yöneticisi satırında içerik yetkisi yoktur; teknik yönetici sürümü ve kullanıcıyı yönetir ama kalite kararı vermez. Dış denetçi satırında ise erişim başlangıç ve bitiş tarihiyle tanımlanır. İkinci taraf denetimlerinde müşteri denetçisine açılan hesabın denetim bittikten sonra kapatılmaması, gördüğüm en yaygın açık kapıdır. Doküman kategorilerinin nasıl kurgulanacağı konusunda doküman yönetimi sayfamız ayrıntılı bir çerçeve veriyor.
Okuma, onaylama ve yayınlama üç ayrı yetkidir
Kurulumların çoğunda bu üçü tek bir "tam yetki" kutucuğunda birleşir. Sonuç şudur: bir süreç sahibi kendi yazdığı prosedürü kendi onaylar, aynı dakikada yayınlar ve eski sürüm arşive düşer. Denetçi kayıt geçmişine baktığında hazırlayan, onaylayan ve yayınlayan alanlarında aynı ismi görür. Bu tek başına bir uygunsuzluk değildir ama mutlaka soru getirir: bu dokümanın içeriğini yazandan başka kim doğruladı?
Ayrımı şöyle kurun. Yazma yetkisi taslak üretir ve taslak, dağıtım listesindeki kimsenin göremeyeceği bir durumdadır. Onaylama yetkisi içeriğin teknik doğruluğunu üstlenir; bu yetki dokümanın konusuna göre farklı kişilerde olur. Bir kalibrasyon talimatını metroloji sorumlusu onaylar, bir kaynak talimatını proses mühendisi. Yayınlama yetkisi ise sistemsel bir işlemdir: sürüm numarasını yükseltir, dağıtım listesini tetikler, eski sürümü kullanımdan kaldırır. Bu son yetkinin bir ya da en fazla iki kişide toplanması sistemde başıboş sürüm dolaşmasını engeller.
Dördüncü bir yetki daha var ve çoğu firmada hiç konuşulmuyor: silme. Yayınlanmış bir dokümanı ya da kapatılmış bir kaydı kimse silememelidir, sistem yöneticisi bile. Yürürlükten kaldırma ile silme arasındaki fark denetimde ölçülen bir farktır; yürürlükten kalkan doküman arşivde okunabilir kalır, silinen doküman izlenebilirliği bitirir. Kurulumda silme yetkisini hiçbir role vermeyin, yalnızca yanlışlıkla açılmış boş kayıtlar için gerekçe zorunlu bir iptal akışı tanımlayın. Bu tek karar, üç yıl sonra "o kaydın nereye gittiğini bilmiyoruz" cümlesini kurmanızı engeller.
Yetki matrisini kurduktan sonra şu testi yapın: gerçek bir operatör hesabıyla sisteme girin ve arama kutusuna sırayla "fiyat", "maliyet", "sözleşme", "bordro" yazın. Beş dakikalık bu deneme, üç haftalık yetki tartışmasından daha çok şey gösterir. Aynı testi bir de vardiya amiri hesabıyla tekrarlayın. Karşınıza çıkmaması gereken tek bir dosya varsa, sorun matriste değil kategorilendirmededir; dokümanlar yanlış klasöre atılmış demektir.
Departman bazlı erişim mi, kategori bazlı erişim mi
İki yaklaşım var ve ikisi de tek başına yetersiz kalıyor. Departman bazlı erişimde kullanıcı hangi departmandaysa o departmanın klasörünü görür. Kurması kolaydır ama kısıtı açıktır: aynı departmandaki bir stajyerle bir müdür tıpatıp aynı şeyi görür. Kategori bazlı erişimde ise doküman türü belirleyicidir; müşteri sözleşmeleri kategorisini kim görecekse departmanı ne olursa olsun o görür. Bu da tersinden sorun çıkarır: presleme talimatını görmesi gereken üretim personeli, döküm talimatını da görür.
Sahada çalışan çözüm ikisinin kesişimidir. Kullanıcı, hem rolünün kategori yetkisine hem de bulunduğu organizasyon biriminin kapsamına giren dokümanı görür. Bu kurgu kurulumda yarım gün fazladan iş çıkarır ama sonraki iki yılda onlarca özel istisna tanımlamaktan kurtarır. İstisna, yetkilendirmenin düşmanıdır: bir kullanıcıya rolünün dışında elle verilen tek bir yetki, altı ay sonra kimsenin açıklayamadığı bir açıklığa dönüşür. Elle verilmiş her yetkiyi bir gerekçe alanıyla birlikte kaydedin, gerekçe yoksa yetkiyi vermeyin.
Onaycı hiyerarşisi ve izin günlerinde kilitlenen akışlar
QDMS kullanıcı yetkileri matrisi bittiğinde iş bitmez; onay akışının kim tarafından, hangi sırayla yürütüleceği ayrı bir tasarımdır. Bir düzeltici faaliyet kaydının kapatılması için önce süreç sahibinin etkinlik değerlendirmesi, ardından kalite yöneticisinin kapatma onayı gerekiyorsa, bu iki adım sistemde sabit tanımlanmalıdır. Serbest bırakılan onay akışlarında kayıt "kim ilgilenirse" mantığıyla haftalarca bekler ve kapanma süresi ortalaması sessizce altmış günün üzerine çıkar.
Asıl tıkanma noktası vekâlettir. Kalite yöneticisi iki hafta yıllık izne çıktığında onayına bağlı bütün akışlar durur. Kurulumda her onaycı için bir yedek onaycı tanımlayın ve vekâletin tarih aralığıyla devreye girmesini sağlayın. Süre dolduğunda yetki kendiliğinden geri dönmelidir. Elle açılıp elle kapatılması gereken vekâletler kapatılmaz; iki yıl sonra bakarsınız ki bir asistan hesabı hâlâ kalite yöneticisi adına onay atabiliyor. Akışın adım sırasını kurarken DÖF sayfamızdaki aşamalar iyi bir başlangıç noktası olur.
Onay hiyerarşisini kurarken bir kuralı baştan koyun: hiç kimse kendi açtığı kaydı kendi kapatamaz. Bir uygunsuzluğu tespit eden kalite uzmanı, düzeltici faaliyetin etkinliğini de kendi değerlendiriyorsa değerlendirme tarafsız olmaz. Aynı kural iç denetim bulguları için de geçerlidir; bulguyu yazan denetçi, kapatma onayını veremez. Sistem bu kısıtı tanımlama seviyesinde uygulayabiliyorsa insan hatasına yer kalmaz. Uygulayamıyorsa kuralı prosedüre yazıp her yönetim gözden geçirmesinde örnekleme yaparak kontrol edin.
Yetki değişikliğini kayıt altına almak
ISO 9001 madde 7.5.3.2, dokümante bilgi (documented information) için dağıtım, erişim, geri çağırma ve kullanımın kontrol edilmesini ister. Maddenin istediği şey bir yazılım özelliği değil, bir yönetim disiplinidir: kimin neye erişeceğine bilinçli olarak karar verilmiş olmalı ve bu karar değiştiğinde değişiklik izlenebilmelidir. Denetçi karşısında "bu kullanıcıya bu yetkiyi kim verdi" sorusuna cevap veremiyorsanız, erişim kontrol altında değil demektir.
Pratikte üç kayıt yeterlidir. Birincisi imzalı yetki matrisidir; hangi rolün neye erişeceğini gösterir, revizyon numarası taşır ve yılda bir gözden geçirilir. İkincisi kullanıcı-rol atama formudur; yeni personelin hangi role atandığını, talebi kimin yaptığını ve kimin uyguladığını içerir. Üçüncüsü sistemin kendi yetki değişikliği günlüğüdür. Bu günlüğün saklama süresini kendi kayıt saklama prosedürünüzle hizalayın; IATF 16949 kapsamında çalışıyorsanız kayıt saklama süreleriniz zaten tanımlıdır. Bu üç kayıt bir arada olduğunda yetki denetimi on dakikada biter.
Yetkilendirmeyi denetlemenin en hızlı yolu, geçen yıl ayrılmış bir personelin adını kullanıcı listesinde aratmaktır. Aktif görünen bir hesap bulunursa konuşma oradan ISO 9001 madde 5.3'e, yani görev ve yetkilerin atanmasına kayar. İkinci klasik hamle şudur: son altı ayda yetkisi değişen bir kullanıcı seçilir ve değişiklik talebinin yazılı kaydı istenir. Kayıt yoksa bulgu, yetkinin kendisinden değil kararın belgesizliğinden yazılır.
İlk 90 günde yapılacak yetki gözden geçirmesi
Devreye alma sonrası ilk üç ay, QDMS kullanıcı yetkileri ile sahadaki gerçeğin en çok çeliştiği dönemdir. Kurulumda geniş verilen yetkiler "önce çalışsın, sonra kısarız" mantığıyla bırakılır ve kısılmaz. Bunu engellemenin tek yolu takvime yazılmış bir gözden geçirmedir. Kurulumun 30, 60 ve 90. günlerinde sistem yöneticisi kullanıcı listesini çıkarsın, her süreç sahibiyle kendi ekibinin yetkilerini tek tek doğrulasın. Bu üç toplantı toplamda altı saat sürer ve sonrasında yılda bir tekrar yeterlidir.
Gözden geçirmede dört şeye bakın: hiç giriş yapmamış hesaplar, ayrılmış personel hesapları, rolünün dışında elle yetki eklenmiş kullanıcılar ve bir yıldır hiç kullanılmamış yetkiler. Dördüncüsü en çok göz ardı edilenidir. Bir kullanıcı yayınlama yetkisine sahipse ama on iki ayda hiç yayın yapmamışsa, o yetkinin orada durması için sebep kalmamış demektir. Yetki, verilen değil düzenli olarak geri alınan bir şey olarak düşünüldüğünde sistem sağlıklı kalır. Çıkan listeyi bir sonraki iç denetim programına madde olarak yazın. O zaman yetki kontrolü, denetim yaklaştığında telaşla yapılan ayrı bir hazırlık olmaktan çıkar; zaten yürüyen bir kontrolün çıktısı hâline gelir.
Yazılımın bu işi ne kadar kolaylaştırdığı
QDMS kullanıcı yetkileri yönetimini zorlaştıran şey kural sayısı değil, kuralların dağınıklığıdır. Doküman yetkisi bir ekranda, onay akışı başka bir ekranda, vekâlet üçüncü bir yerde tutulduğunda bir personelin ayrılması üç ayrı işlem gerektirir ve biri mutlaka atlanır. Bu yüzden bir kalite yönetim sistemi yazılımı değerlendirirken tek soruyu net sorun: bir kullanıcının bütün yetkileri, onaycı olduğu akışlar ve vekâletleri tek ekranda görülebiliyor mu? Biz PaKalite'de o tabloyu tek sayfaya sığdırdık: on sekiz modül aynı rol tanımını paylaştığı için bir rolde yapılan değişiklik bütün modüllerde aynı anda geçerli oluyor. Kurulumun teknik tarafı için şirket içi kurulum yazımıza da bakın; yetki matrisi kurulum takviminin ikinci haftasına denk gelir ve orada hazır olmazsa pilot kullanım gecikir.