Sistem Belgelendirme Yazılımı Nasıl Çalışır? Başvurudan Sertifikaya Dijital Süreç

Sistem belgelendirme yazılımı neyi yönetir?

Sistem belgelendirme yazılımı; başvuruyu, kapsam incelemesini, denetim süresini, denetçi yetkinliğini, Aşama 1 ve Aşama 2 kayıtlarını, bulguları, bağımsız gözden geçirmeyi, kararı, sertifikayı ve gözetim çevrimini aynı izlenebilir dosyada yönetir.

Buradaki değer, kâğıt formu ekrana taşımaktan daha büyüktür. Belgelendirme kuruluşu her müşteri için hangi bilginin ne zaman alındığını, planın hangi girdilerle kurulduğunu, denetim kanıtlarının hangi bulguyu desteklediğini ve kararın hangi yetkili kayıt üzerinden verildiğini gösterebilmelidir. Yazılım bu zinciri görünür kılar; belgelendirme kuruluşunun teknik sorumluluğunu, tarafsızlık yükümlülüğünü veya yetkili kararını devralmaz.

Dijital dosyanın omurgası nasıl kurulmalı?

Sağlam omurga; müşteri kaydını değil, başvuru kapsamından sertifika çevrimine kadar birbirine bağlı ve sürümlenmiş karar kanıtlarını merkeze alır.

ISO/IEC 17021-1:2015, yönetim sistemi denetimi ve belgelendirmesi yapan kuruluşların yetkinliği, tutarlılığı ve tarafsızlığı için ilke ve şartları tanımlar. ISO’nun resmî özetine göre yönetim sistemi belgelendirmesi üçüncü taraf uygunluk değerlendirme faaliyetidir. Bu nedenle CRM’de açılmış bir “satış fırsatı”, teknik açıdan incelenmiş bir belgelendirme başvurusu değildir. İki kayıt bağlantılı olabilir; fakat amaçları, yetkileri ve onay kapıları farklıdır. [1]

Başvuru incelemesi neden bir form onayından ibaret değildir?

Başvuru incelemesi, kuruluşun talebini belgelendirme kapsamına çevirmeli; faaliyeti, sahaları, personeli, standardı, program kurallarını ve kaynak yeterliliğini birlikte değerlendirmelidir.

Başvuru ekranında yalnız firma adı, çalışan sayısı ve standart seçimi bulunması yeterli değildir. Faaliyetlerin hangi sahalarda ve vardiyalarda yürütüldüğü, geçici veya sanal sahaların bulunup bulunmadığı, dış kaynak kullanılan kritik süreçler, entegre sistem talebi, önceki sertifikasyon durumu ve transfer ihtiyacı gibi bilgiler teknik incelemeyi değiştirir. İlk girilen bilgi daha sonra güncellendiğinde sistem eski yanıtı silmemeli; değişikliğin teklif, süre, ekip ve kapsam üzerindeki etkisini değerlendirme görevi üretmelidir.

TÜRKAK, yönetim sistemi belgelendirme kuruluşlarının ISO/IEC 17021-1’in yanında ilgili yönetim sistemi standardına özgü yeterlilik dokümanlarını, IAF zorunlu dokümanlarını ve uygulanabilir EA/TÜRKAK dokümanlarını karşılaması gerektiğini açıklar. Örneğin ISO 9001, ISO 14001, ISO/IEC 27001 veya ISO 45001 dosyalarının uzmanlık ve ek normatif doküman setleri aynı değildir. Yazılım bu farklılığı tek bir genel “ISO belgesi” ürününe indirgememeli; program ve kapsam bazında yönetmelidir. [2]

Denetim süresi ve ekip ataması nasıl birbirine bağlanır?

Önce denetim süresinin gerekçeli hesabı yapılır; ardından bu süreyi ve kapsamı karşılayabilecek yetkin, tarafsız ve müsait ekip planlanır.

IAF MD 5:2023, kalite, çevre ve iş sağlığı ve güvenliği yönetim sistemlerinde ilk denetim süresinin Aşama 1 ile Aşama 2 toplamı olarak başvuru incelemesinin parçası olduğunu belirtir. Etkili personel sayısı başlangıç noktasıdır; fakat tek faktör değildir. Risk veya karmaşıklık, saha ve vardiya yapısı, dil, yüksek mevzuat yoğunluğu, dış kaynak süreçleri ve geçici sahalar gibi değişkenler de dikkate alınır. Hesap sonucunun ve yapılan düzeltmelerin dayanağı kaydedilmelidir. [3]

Bu nedenle yazılım yalnız “personel sayısını seç, gün sayısını getir” yaklaşımıyla tasarlanmamalıdır. Kural setinin sürümü, giriş verisinin anlık görüntüsü, ekleme/azaltma faktörleri, açıklama, onaylayan kişi ve yeniden hesaplama nedeni birlikte saklanmalıdır. Konunun hesap mantığını ayrıntılı olarak ele alan IAF MD 5 denetim süresi rehberi, taban süre ile kuruluşa özgü düzeltmenin neden ayrı tutulması gerektiğini açıklar.

Ekip atamasında da yalnız takvim uygunluğu aranmaz. Denetçinin sektör/kod yeterliliği, ilgili standart yetkinliği, rolü, önceki görevleri, tarafsızlık veya çıkar çatışması beyanı ve gerekirse teknik uzman desteği görünmelidir. Uygun kişi bulunamadığında sistem süreyi gizlice azaltmamalı veya kapsamı başka bir koda taşımamalı; planlama istisnasını yetkili incelemeye göndermelidir.

Aşama 1’den belgelendirme kararına kayıt nasıl ilerler?

Her aşama kendi amacı ve çıktısıyla kapanmalı; sonraki adım, önceki aşamanın onaylanmış çıktısını referans almalı ve geriye dönük değişiklik yeni sürüm oluşturmalıdır.

Aşama 1 kaydı; denetime hazır olma durumunu, önemli saha ve kapsam koşullarını, Aşama 2 planını etkileyen noktaları ve takip edilmesi gereken hususları görünür kılmalıdır. Aşama 2’de denetim planı, örneklenen süreçler, görüşmeler, doküman ve uygulama kanıtları ile bulgular aynı dosyada ilişkilendirilir. Bir bulgu yalnız metin ve sınıf değildir; dayandığı kanıt, ilgili şart, sorumlu, termin, sunulan düzeltme ve doğrulama sonucu ile yaşam döngüsüne sahiptir.

Dosya karar aşamasına geldiğinde sistem “tüm kutular doluysa otomatik sertifika üret” mantığına geçmemelidir. Eksik veya çelişkili kayıtları kontrol etmek, karar yetkilisine özet ve kaynak bağlantıları sunmak yararlıdır; ancak kararın kapsamı, koşulları, gerekçesi, tarihi ve yetkilisi ayrıca kaydedilmelidir. Daha sonra bulgu veya kapsam verisi değişirse eski karar sessizce güncellenmemeli; yeniden değerlendirme ihtiyacı doğmalıdır.

Transfer ve uzaktan denetim dosyaları aynı akışa sığar mı?

Ortak kayıt omurgası kullanılabilir; fakat transfer incelemesi ve uzaktan denetim, kendine özgü zorunlu kontrol ve kanıt alanlarıyla ayrı senaryolar olmalıdır.

IAF MD 2:2023, akredite yönetim sistemi sertifikalarının transferinde sertifikanın geçerliliği, akreditasyon kapsamı ve transfer öncesi inceleme için asgari kontroller tanımlar. Askıda olduğu bilinen sertifikanın normal transfer dosyası gibi kabul edilmemesi ve gerekli bilgilerin doküman incelemesiyle, ihtiyaç halinde transfer öncesi ziyaretle değerlendirilmesi yazılımda kontrol listesine dönüşebilir. Ancak sistem bu incelemenin sonucunu kendiliğinden “uygun transfer” olarak vermemelidir. [4]

Uzaktan teknik kullanımda ise hangi faaliyetin bilgi ve iletişim teknolojisiyle yürütüldüğü, kullanılan yöntem, katılımcı, süre, bağlantı güvenliği, kanıt erişimi ve plan içindeki yeri kaydedilmelidir. IAF MD 4:2023, denetim/değerlendirme amaçlı ICT kullanımına ilişkin çerçeve sunar. Uzaktan yapılabilen bir görüşme ile sahada görülmesi gereken bir proses aynı şey değildir; program ve risk sınırı yetkili planlamada korunmalıdır. [5]

Sertifika yayımlandıktan sonra süreç neden bitmez?

Sertifika, üç yıllık çevrimin tek çıktısıdır; gözetim, kapsam değişikliği, askı, geri çekme, yeniden belgelendirme ve doğrulama kayıtları yaşam döngüsünü sürdürür.

Sertifika kartında kapsam, standart, saha, geçerlilik, karar, ilk yayın ve revizyon bilgileri birbirinden ayrılmalıdır. Belge PDF’si değişmez bir çıktı olarak saklanırken düzeltme veya kapsam değişikliği yeni sürüm üretmelidir. Müşteri portalı güncel belgeyi göstermeli; iç kullanıcı eski sürümlerin neden ve ne zaman değiştiğini görebilmelidir.

TÜRKAK’ın 2 Aralık 2024 tarihli duyurusuna göre TBDS altyapısı denetim bilgilerinin izlenmesini kapsayacak şekilde genişletildi ve 1 Ocak 2025’ten itibaren TÜRKAK’tan akredite yönetim sistemi belgelendirme kuruluşlarının ilk belgelendirme, gözetim, belge yenileme ve diğer denetim bilgilerini sisteme girmesi zorunlu hale geldi. Bu durum, iç kaydın resmî bildirim alanlarıyla eşleşmesini önemli kılar; ancak yazılımdaki “gönderildi” durumu gerçek servis yanıtı ve referans numarası olmadan başarılı sayılmamalıdır. [6]

Denetimde savunulabilir bir dijital kayıt nasıl görünür?

Savunulabilir kayıt; yalnız son PDF’yi değil, girdiyi, sürümü, işlemi yapan kişiyi, zamanı, gerekçeyi, onayı ve önceki değeri birlikte gösterir.

• Sürüm: Başvuru, hesap, plan, rapor, bulgu ve sertifika değişiklikleri eski veriyi ezmez.
• Rol ayrımı: Satış, planlama, denetçi, teknik gözden geçiren, karar yetkilisi ve yönetici farklı yetki setlerine sahiptir.
• Kanıt bağlantısı: Her bulgu, ilgili şart ve doğrulama kanıtına; her karar, kullanılan dosya sürümüne bağlanır.
• İstisna gerekçesi: Süre, ekip, tarih veya kapsam değişikliği serbest bir not değil, yetkili onaylı kayıt üretir.
• Bildirim kanıtı: E-posta veya portal teslimi, yalnız gönder düğmesine değil teknik sonuca ve teslim zamanına dayanır.
• Erişim günlüğü: Kritik içerik görüntüleme, indirme ve değişiklikleri müşteri ve rol sınırıyla izlenir.

ISO 19011:2026, denetim ilkeleri, denetim programlarının yönetimi ve denetçi yetkinliği için güncel rehber sunar; ISO’nun resmî sayfası bu standardın tek başına sertifikasyona yol açmadığını da açıkça belirtir. Yazılım tasarımında bu rehberden program yönetimi ve denetim disiplini için yararlanılabilir, fakat üçüncü taraf belgelendirme şartlarının yerine konulamaz. [7]

Sistem belgelendirme yazılımına geçiş nasıl yapılmalı?

En güvenli geçiş, önce gerçek süreç ve yetki haritasını çıkarmak, sonra tek programda pilot yapmak ve doğrulanan modeli kontrollü biçimde genişletmektir.

1. Mevcut dosyayı parçalarına ayırın

Başvuru formu, hesap tablosu, teklif, denetçi dosyası, plan, rapor, bulgu, karar tutanağı, sertifika ve bildirim kayıtlarını çıkarın. Aynı bilginin hangi dosyalarda tekrarlandığını, hangisinin kaynak kabul edildiğini ve kimin değiştirebildiğini belirleyin.

2. Tek program ve sınırlı müşteri grubuyla pilot yapın

En karmaşık istisnayı değil, gerçek süreci temsil eden yönetilebilir bir kapsamı seçin. Pilot başarı ölçütü yalnız işlem hızı olmamalıdır; eksik veri, yeniden planlama nedeni, yanlış ekip atama uyarısı, açık bulgu görünürlüğü ve karar dosyasına erişim de ölçülmelidir.

3. Entegrasyonları kanıtıyla doğrulayın

ERP/CRM, e-posta, e-imza, TBDS veya müşteri portalı bağlantılarında yalnız başarılı senaryo denenmemelidir. Tekrar gönderim, yetki hatası, servis kesintisi, kısmi aktarım ve düzeltme senaryoları kayıp kayıt üretmeden ele alınmalıdır.

4. Kural ve standardı sürümlendirin

IAF dokümanı, program kuralı, standart veya kurum prosedürü değiştiğinde açık işlerin hangi sürümde devam edeceği belirlenmelidir. Eski dosya bugünkü hesapla yeniden yazılmamalı; dönemin kuralı görünür kalmalıdır.

En sık yapılan tasarım hataları nelerdir?

En yaygın hatalar; CRM durumunu teknik karar sanmak, yetkinliği takvim müsaitliğine indirgemek ve onaylanmış kayıtları geçmişi korumadan değiştirmektir.

• Her standardı aynı iş akışına zorlamak: Ortak omurga kurulabilir; program ve normatif doküman farklılıkları ayrı kural setinde kalmalıdır.
• Denetim süresini gizli formülle vermek: Kullanıcı girdiyi, kural sürümünü, düzeltme faktörünü ve gerekçeyi görebilmelidir.
• Teknik kararı otomatikleştirmek: Sistem eksikliği işaretleyebilir; belgelendirme kararı yetkili ve izlenebilir insan değerlendirmesi olmalıdır.
• Sertifika PDF’sini ana kayıt yapmak: PDF çıktı; karar, kapsam, saha, sürüm ve çevrim verisinin yerine geçmez.
• Entegrasyon sonucunu varsaymak: TBDS, e-posta veya portal gönderimi gerçek teknik yanıtla doğrulanmalıdır.
• Eski dosyayı silmek: Revizyon, önceki kanıt ve karar ilişkisini ortadan kaldırmamalıdır.

Vizyon Alia bu akışı nasıl destekler?

Vizyon Alia; başvuru ve tekliften denetçi planlamaya, saha/denetim kayıtlarından karar ve sertifika çevrimine kadar belgelendirme dosyasını tek süreç omurgasında yönetmek üzere yapılandırılır.

Vizyon Alia çözüm sayfası üzerinden modül yaklaşımını inceleyebilir, belgelendirme yazılımı hizmet sayfasında süreç ve entegrasyon seçeneklerini görebilirsiniz. Kurulumda mevcut form ve prosedürlerin doğrudan kopyalanması yerine kapsam, rol, karar, sürüm ve entegrasyon kuralları kuruluşun gerçek işleyişiyle birlikte doğrulanmalıdır.

Demo öncesinde bir anonimleştirilmiş başvuru, gerçek denetim süresi hesabı, yetkinlik matrisi, bulgu örneği ve sertifika revizyon senaryosu hazırlamak sonucu somutlaştırır. VizyonTech ile süreç analizi planlarken bu beş örnek üzerinden uçtan uca pilot akış kurulabilir.

Sık sorulan sorular