Yatırım toplantısında IT müdürü kollarını kavuşturur: "Zaten SharePoint'imiz var, ayrıca yazılım almayalım." Kalite müdürü karşı çıkmak ister ama elindeki argüman "orada onay akışı yok" cümlesinden ileri gitmez ve tartışma iki departmanın birbirini ikna edemediği bir yerde asılı kalır. Oysa SharePoint doküman yönetimi yeterli mi sorusunun cevabı duyguyla değil, denemeyle bulunur. Bir denetçi karşınıza oturduğunda size ürün adı sormaz; belirli kanıtları ister. O kanıtları listeleyip iki sistemde tek tek denerseniz tartışma yarım günde biter ve karar herkesin gördüğü bir tabloya dayanır.
Denetçinin isteyeceği yedi kanıt
ISO 9001 madde 7.5.3, dokümante bilginin (documented information) erişilebilir ve kullanıma uygun olmasını, yeterince korunmasını, dağıtımının ve değişikliklerinin kontrol edilmesini ister. Bu cümleyi sahaya indirdiğinizde yedi somut kanıt çıkar: onay kaydı, revizyon geçmişi, güncel sürümün tekliği, eski sürümün kullanımdan kaldırılması, dağıtım listesi ve okundu teyidi, erişim yetkisi, saklama süresi ve imha kaydı. Denetim bu yedi başlığın dışına pek çıkmaz.
Tartışmayı bu listeye indirmenin faydası şudur: IT müdürüyle "hangi yazılım daha iyi" diye değil, "şu yedi kanıtı mevcut kurulumda nasıl üretiyoruz" diye konuşursunuz. Bu soruya cevap veremediğiniz her satır, denetimde bulgu adayıdır. Denetim mantığının bütününe denetim sayfamızdan bakabilirsiniz.
SharePoint doküman yönetimi yeterli mi, sorunun doğru hâli
SharePoint ciddi bir platformdur; sürüm geçmişi, kullanıma alma ve iade (check-out / check-in), meta veri sütunları, izin grupları ve onay akışı kurgulayabileceğiniz araçlar barındırır. Yani teknik olarak yedi kanıtın çoğu SharePoint üzerinde kurulabilir. Doğru soru "SharePoint yeterli mi" değil, "bizim SharePoint kurulumumuz bu yedi kanıtı bugün üretiyor mu" sorusudur. Çoğu şirkette cevap hayırdır, çünkü platform kalite dokümanı için değil dosya paylaşımı için açılmıştır.
Aradaki fark şuradan doğar: bir doküman yönetim sistemi kalite kurallarını varsayılan olarak dayatır, SharePoint ise siz kurgularsanız uygular. Onay akışını tasarlamak, revizyon numarasını meta veriye bağlamak, yürürlükten kalkan sürümü otomatik arşive taşımak ve okundu teyidi toplamak ayrı ayrı yapılandırma işleridir. Bu emeği harcayacak bir IT kaynağınız varsa yol açıktır; yoksa "var olan sistemi kullanalım" kararı, denetimden birkaç ay önce panik hâlinde geri alınır.
Yedi kanıtın iki sistemde karşılığı
Aşağıdaki tablo, yedi kanıtın ortak klasör veya varsayılan bir SharePoint kütüphanesinde ve kalite odaklı bir doküman yönetim sisteminde nasıl karşılandığını gösterir. Tablo bir üstünlük listesi değil, kendi kurulumunuzu işaretleyeceğiniz bir kontrol formudur.
| Denetçinin istediği kanıt | Ortak klasör / varsayılan SharePoint | Doküman yönetim sistemi |
|---|---|---|
| Onaylayan kim, ne zaman onayladı | Dosya özelliklerinde yazar bilgisi; onay ayrı bir e-postada | Onay adımı kayıt altında, imza tarihiyle |
| Revizyon geçmişi ve neyin değiştiği | Sürüm geçmişi var, değişiklik gerekçesi yok | Revizyon no, gerekçe ve fark alanı zorunlu |
| Güncel sürümün tekliği | Kopyalar masaüstlerinde ve e-postalarda çoğalır | Tek yayın kaydı; kopya alma kısıtlanabilir |
| Eski sürümün kullanımdan kaldırılması | Elle arşiv klasörüne taşınır, unutulabilir | Yeni revizyon yayınlanınca eski otomatik pasifleşir |
| Dağıtım listesi ve okundu teyidi | Toplu e-posta; kimin açtığı izlenmez | Kişi bazlı görev, okundu tarihi kayıtlı |
| Kim hangi dokümanı görebilir | Klasör izinleri; alt klasörlerde kayar | Rol bazlı yetki, doküman tipine göre tanımlı |
| Saklama süresi ve imha | Kural yazılı, uygulaması kişiye bağlı | Doküman tipine bağlı süre, süre dolunca uyarı |
Tablodaki orta sütun kötü bir sistem tarifi değil, yapılandırılmamış bir sistem tarifidir. SharePoint'te bu satırların her biri iş akışı, sütun ve izin kurgusuyla düzeltilebilir. Mesele bu kurgunun kimin tarafından, ne kadar sürede yapılacağı ve her sürüm yükseltmesinden sonra kimin doğrulayacağıdır.
Bir denetimde sistemi kanıtlamanın en hızlı yolu şudur: denetçiden bir talimat seçmesini isteyin, ekranda açın, sağ üstte revizyon numarasını ve onay tarihini gösterin, ardından o revizyonun dağıtım listesinden hattaki operatörün okundu kaydını çıkarın. Bu üç ekran 30 saniye sürer. Aynı zinciri ortak klasörde göstermeye çalıştığınızda üç ayrı yerden (klasör, e-posta kutusu, imza föyü) parça toplarsınız ve o arada denetçi zaten kararını vermiş olur.
Revizyon kilidi ve iki kişinin aynı dosyayı açması
Ortak klasörün klasik hatası şudur: prosedürü kalite şefi düzenlerken üretim müdürü de aynı dosyayı açar, ikisi de kaydeder ve biri diğerinin değişikliğini siler. SharePoint'te kullanıma alma özelliği bu riski kapatır, ancak varsayılan olarak zorunlu değildir ve çoğu kütüphanede kapalı gelir. Bir doküman yönetim sisteminde ise revizyon açmadan dosyaya dokunamazsınız; düzenleme yetkisi tek kişiye kilitlenir ve revizyon kapanana kadar yayında olan sürüm değişmez.
Bu farkın denetimdeki yansıması şudur: kimin neyi ne zaman değiştirdiğini gösteremediğinizde, değişikliklerin kontrol edildiğini de kanıtlayamazsınız. Standardın istediği şey dosyanın kendisi değil, o dosyanın üzerindeki kontroldür.
Onay akışı: e-posta zinciri kanıt sayılır mı
Uygulamada en sık karşılaşılan savunma "onayı e-postayla aldık" cümlesidir. Bu bir kayıttır, ama zayıf bir kayıttır. Denetçi e-postanın hangi revizyona ait olduğunu, onaydan sonra dosyada değişiklik yapılıp yapılmadığını ve onaylayanın bu yetkiye sahip olup olmadığını sorar. Üçüne birden cevap veremezseniz, onay kaydı dokümana bağlı değil, insan hafızasına bağlıdır.
Sistem içi onay akışında bu üç soru kendiliğinden cevaplanır: onay belirli bir revizyon numarasına iliştirilir, onaydan sonra içerik kilitlenir ve onaylayan rol tanımından gelir. SharePoint'te de onay iş akışı kurulabilir; kritik olan bu akışın kalite dokümanı kütüphanesinde zorunlu kılınması ve devre dışı bırakılamamasıdır.
Onay akışında ikinci mesele reddin nasıl işlediğidir. Bir doküman onaydan geri döndüğünde gerekçe kayıt altına alınmalı, doküman taslak durumuna dönmeli ve yayındaki sürüm hiç etkilenmemelidir. E-posta üzerinden yürütülen onaylarda ret genelde hiç kaydedilmez; onaycı sözlü olarak uyarır, hazırlayan düzeltir ve neyin neden değiştiği kaybolur. Denetçi "bu revizyon neden iki kez onaya girmiş?" diye sorduğunda cevabınız sistemde durmalı.
Bir başka fark da hatırlatmalarda ortaya çıkar. Gözden geçirme tarihi yaklaşan bir prosedür için sorumluya kendiliğinden bir görev düşmesi gerekir. Dosya paylaşım platformlarında bu iş takvim hatırlatmasıyla ya da bir kişinin not defteriyle yürütülür; o kişi izne çıktığında sistem durur. Süresi gelen dokümanları listeleyen bir rapor, denetimden önce çıkarılan en değerli çıktılardan biridir.
Okundu teyidi ve dağıtımın kanıtlanması
Bir talimatı revize ettiniz, ilgili herkese duyurdunuz. Denetçi hatta iner ve operatöre sorar: "Bu işi hangi talimata göre yapıyorsun?" Operatör iki revizyon önceki kâğıdı gösterirse, sistemde dosyanın güncel olması sizi kurtarmaz. Bu yüzden dağıtım listesi ve okundu teyidi, doküman yönetiminin en çok ihmal edilen ama denetimde en çok işe yarayan parçasıdır.
Toplu e-posta ile gönderilen bir duyuru, okunduğunu kanıtlamaz. Kişi bazlı görev atayan ve okundu tarihini kaydeden bir yapıda ise denetçiye tek ekranda "bu revizyonu 14 kişiye dağıttık, 14'ü de üç gün içinde okudu" diyebilirsiniz. Denetim öncesi hangi kayıtların hazır olması gerektiğini doküman denetimine hazırlık listemizde madde madde topladık.
Dış kaynaklı dokümanlar ve saklama süresi
Otomotivde ek bir katman daha vardır: müşteri çizimleri, mühendislik spesifikasyonları ve standartlar. IATF 16949, mühendislik standartlarındaki değişikliklerin gözden geçirilmesi ve etkilenen kayıtların güncellenmesi için makul bir süre tanır ve bu sürenin takip edilmesini bekler. Ortak klasörde duran bir müşteri çizimi için "bu en son sürüm mü, ne zaman kontrol ettik?" sorusunun kayıtlı bir cevabı genelde yoktur.
Aynı sorun saklama sürelerinde de görülür. Kayıt tipine göre saklama süresi tanımlanmış olabilir, ama süresi dolan kaydın imha edildiğini ya da süresi dolmadan silinmediğini kim izliyor? Klasör yapısında bu iş bir kişinin takvimine kalır. ISO 9001 maddelerinin yazılımdaki tam karşılığını madde 7.5 yazımızda tek tek eşleştirdik.
Bulunabilirlik: klasör ağacı mı, meta veri mi
Ortak klasörün ikinci büyük sorunu aramadır. Klasör ağacı tek bir mantığa göre kurulur; genelde departman kırılımıyla. Ama aynı talimat hem bakımı hem üretimi ilgilendirdiğinde ağaç yetmez ve dosya iki yere kopyalanır. O andan sonra iki kopya ayrı yaşamaya başlar, biri revize edilir diğeri unutulur. Denetimde iki farklı sürüm ortaya çıktığında hangisinin geçerli olduğunu açıklamak mümkün olmaz.
Meta veriyle çalışan bir yapıda dosya tek kayıttır; tip, sahip bölüm, ilgili süreç ve ilgili ekipman alanlarıyla etiketlenir. Kullanıcı ister bölümden ister süreçten arar, aynı kayda ulaşır. SharePoint bunu sütunlarla yapabilir ve iyi kurgulanmış bir kütüphanede gerçekten iyi çalışır; ancak kullanıcılar sütunları boş bırakabiliyorsa yapı ilk aydan itibaren bozulur. Zorunlu alan tanımı olmayan hiçbir meta veri şeması ayakta kalmaz.
Kayıtların bütünlüğü: hücre sessizce değişir
Doküman tarafı hallolsa bile geriye kayıtlar kalır. ISO 9001, uygunluk kanıtı olarak tutulan dokümante bilginin istenmeyen değişikliklere karşı korunmasını ister. Excel'de tutulan bir kontrol kaydında bu şartı karşılamak mümkün değildir; bir hücre değiştiğinde ne eski değer, ne değiştiren kişi, ne de gerekçe kalır. Ortak klasörde dosya sürüm geçmişi olsa bile, hangi hücrenin neden değiştiğini kimse okuyamaz.
Kayıt bütünlüğü, SharePoint doküman yönetimi yeterli mi sorusunun en az konuşulan ama denetimde en çok işe yarayan boyutudur. Ölçüm sonuçları, kontrol formları ve uygunsuzluk kayıtları düzenleme kilidi altında tutulmalı; bir düzeltme gerekiyorsa üzerine yazılmamalı, düzeltmenin kendisi ayrı bir iz olarak kaydedilmelidir. Bunu bir dosya paylaşım platformunda kurmak, doküman tarafını kurmaktan çok daha zordur.
Karar: hangi durumda hangisi
SharePoint doküman yönetimi yeterli mi sorusuna verilecek dürüst cevap şudur: yedi kanıtı kurgulayacak IT kaynağınız, bu kurguyu yazılı hâle getirecek disiplininiz ve her sürüm değişiminden sonra doğrulayacak bir sahibiniz varsa yeterlidir. Bunlardan biri eksikse, kalite kurallarını varsayılan olarak getiren bir sistem daha az emekle daha çok kanıt üretir. Karar noktası ürünün markası değil, kuralın kim tarafından uygulandığıdır.
İkinci bir ölçüt de kapsamdır. İş yalnız dosya saklamakla bitmiyor, düzeltici faaliyet, denetim planı, eğitim kaydı ve ekipman kalibrasyonu da aynı dokümanlara bağlanıyorsa, bunları ayrı ayrı SharePoint listeleriyle kurmak orta vadede pahalı bir özel geliştirmeye dönüşür. PaKalite bu noktada birbirine bağlı 18 modülü kendi sunucunuza kurulan tek bir yapıda toplar; doküman yönetimi tarafını incelemek karşılaştırma tablonuzu doldurmanızı kolaylaştırır. Kararı toplantı masasındaki en yüksek sese göre değil, yukarıdaki yedi satırı iki sistemde de tek tek deneyerek verin.