KESA ve UBKS verilerini izlenebilir tutmanın yolu, iki kaydı tek dosyada eritmek değil; ortak baca ve iş kimliği altında kaynak, sürüm, sorumlu, zaman, bütünlük özeti ve revizyon bağını birlikte korumaktır.
KESA ve UBKS neden aynı kayıt değildir?
Kısa cevap: KESA hesabı teknik hesap kaynağını, UBKS ise baca kontrol ve kayıt bağlamını temsil eder. Birinin varlığı diğerinin güncel veya doğru olduğunu tek başına kanıtlamaz.
Kesa Technische Software, kesa-aladin'i Avrupa standartlarına göre baca ve atık gaz sistemi hesabı yapan bir yazılım olarak tanımlar. UBKS ise kendi bilgi merkezinde Ulusal Baca Kontrol ve Kayıt Sistemi olarak yer alır. Bu iki kaynağı birbirinin yerine geçirmek yerine aynı tesis, bina, ısıtıcı ve baca kimliği altında çapraz referanslamak gerekir.
VizyonTech iş akışındaki teknik karşılık, KESA kaynak dosyasını ve çıktısını ayrı kayıtlar olarak saklamak; UBKS referansını, durumunu ve kanıtını da ayrı nesne olarak yönetmektir. Ortak iş kimliği ilişkiyi kurar, fakat kaynakların özgünlüğünü ortadan kaldırmaz.
Her kayıt için hangi alanlar tutulmalıdır?
Kısa cevap: Dosya adından fazlası gerekir. Kaynağı yeniden bulmayı, değişikliği açıklamayı ve rapordaki değeri geriye doğru izlemeyi sağlayan asgari bir veri sözlüğü kullanılmalıdır.
| Kayıt grubu | Zorunlu alanlar | Kontrol sonucu |
|---|---|---|
| Ortak kimlik | Tesis/bina, iş emri, baca kodu, ısıtıcı veya cihaz kimliği | İki kaynak doğru fiziksel bacaya bağlanır |
| KESA kaynağı | Özgün kaynak dosya, dosya hash'i, yazılım sürümü, hesap tarihi, hazırlayan | Çıktının hangi kaynak ve ortamda üretildiği görülür |
| Hesap çıktısı | Çıktı dosyası, çıktı hash'i, kontrollü yöntem/standart referansı, teknik gözden geçiren | Kaynak ile yayımlanan sonuç arasındaki bağ korunur |
| UBKS kaydı | Kayıt referansı, durum, kayıt zamanı, işlemi yapan, kanıt dosyası veya doğrulama kaydı | Dış kayıt bağlamı ve son kontrol zamanı görünür olur |
| Revizyon | Eski-yeni sürüm bağı, değişiklik nedeni, etkilenen alanlar, onaylayan | Sessiz üzerine yazma engellenir |
Hash, dosyanın içeriğinin değişip değişmediğini kontrol etmeye yarayan teknik bir özettir; tek başına belgenin doğru veya yetkili olduğunu kanıtlamaz. Yetki, teknik gözden geçirme ve kaynak doğrulaması ayrıca yapılmalıdır.
KESA dosyası sisteme alınırken ne doğrulanmalıdır?
Kısa cevap: Aktarım, yalnız dosya yükleme değildir. Dosyanın kaynağı, formatı, bütünlüğü, yazılım sürümü ve doğru baca kimliği doğrulanmadan kayıt kabul edilmemelidir.
KESA üreticisi yazılımın ve içerdiği teknik verilerin güncellenebildiğini açıklar. Bu nedenle yalnız sonuç PDF'sini saklamak, hesabın hangi yazılım ve veri ortamında üretildiğini görünmez bırakabilir. Kaynak dosya ile insan tarafından okunabilir çıktı birlikte tutulmalı; hesap oluşturulduğunda kullanılan program sürümü kaydedilmelidir.
- Dosya uzantısı ve içerik tipini izin verilen listeyle doğrulayın; dosya adına güvenmeyin.
- Kaynak dosya için SHA-256 gibi bütünlük özeti üretin ve sonradan değişiklik kontrolünde kullanın.
- KESA yazılım sürümünü, hesap tarihini ve hesabı hazırlayan yetkiliyi kaydedin.
- Dosyadaki proje/baca tanımıyla iş emrindeki tesis, cihaz ve baca kimliğini karşılaştırın.
- Kaynak dosya ile hesap çıktısını aynı revizyon numarası altında, fakat ayrı nesneler olarak saklayın.
VizyonTech, KESA'nın hesap doğruluğunu veya bir kaydın resmî kabulünü kendiliğinden garanti etmez. Yazılımın görevi, yetkili kişinin yaptığı kontrolü ve kullandığı kanıtı görünür ve geri izlenebilir kılmaktır.
UBKS kaydı KESA hesabıyla nasıl eşleştirilmelidir?
Kısa cevap: Eşleştirme dosya adına göre değil, ortak fiziksel varlık kimlikleri ve doğrulanmış bir çapraz referans üzerinden yapılmalıdır.
UBKS referansı sisteme girildiğinde kayıt zamanı, kaydı yapan kişi, doğrulama zamanı ve o anda görülen durum ayrı alanlarda tutulur. Ekran görüntüsü kullanılıyorsa yalnız destekleyici kanıt sayılmalı; okunabilir referans ve kontrol kaydı yapılandırılmış alanda da bulunmalıdır. Kullanıcının yetkili erişimle yaptığı doğrulama kaydı, resmî sistem arayüzünü taklit eden yerel bir ekranla değiştirilmemelidir.
- Önce tesis/bina, ısıtıcı ve baca kodu eşleşmesini kontrol edin.
- KESA hesabının revizyonu ile UBKS kaydının kontrol zamanını birlikte gösterin.
- Çap, yükseklik, cihaz veya güzergâh gibi kritik alanlarda fark varsa otomatik kapanış yerine inceleme görevi açın.
- UBKS tarafındaki yeni bir durum bilgisini eski kaydın üzerine yazmayın; zaman damgalı yeni olay olarak ekleyin.
- Dış sistem erişilemediğinde son görülen veriyi güncelmiş gibi sunmayın; doğrulama durumunu "bekliyor" olarak koruyun.
Bir değişiklik olduğunda revizyon zinciri nasıl korunur?
Kısa cevap: Yeni hesap veya kayıt, eski sürümü silmemeli. Değişiklik nedeni, etkilediği rapor alanları ve yeniden onay gereksinimi açık bir olay zincirinde tutulmalıdır.
Örneğin ısıtıcı gücü, baca yüksekliği, çap, malzeme veya güzergâh değiştiğinde önce yeni saha verisi kaydedilir. Ardından yeni KESA revizyonu oluşturulur; eski dosya salt okunur kalır. Kritik alanlar karşılaştırılır, UBKS kaydının yeniden kontrol gerektirip gerektirmediği yetkili kullanıcıya görev olarak atanır. Nihai rapor yalnız güncel revizyonların tamamı teknik gözden geçirmeden geçtiğinde yayımlanır.
| Kapı | Kanıt | Eksikte davranış |
|---|---|---|
| Kimlik eşleşmesi | İş, bina, ısıtıcı ve baca kimliği | Aktarımı karantinaya al |
| Kaynak bütünlüğü | Kaynak dosya, hash, KESA sürümü ve hazırlayan | Hesap revizyonunu kabul etme |
| Dış kayıt kontrolü | UBKS referansı, durum ve doğrulama zamanı | Teknik kapanışı beklet |
| Fark incelemesi | Kritik alan karşılaştırması ve gerekçe | Onay görevi aç |
| Rapor yayını | Güncel revizyon bağı ve yetkili teknik onay | Yayını engelle |
Yetki, yedekleme ve veri bütünlüğü nasıl ele alınmalıdır?
Kısa cevap: İzlenebilirlik yalnız geçmiş ekranı değildir; kimin neyi görebildiği ve değiştirebildiği, değişikliğin nasıl kaydedildiği ve kaydın nasıl geri getirileceği de kontrol edilmelidir.
ISO'nun sayfasına göre ISO/IEC 17025:2017'nin üçüncü baskısı 2023'te yeniden teyit edilmiştir ve laboratuvarların yetkinliği ile tutarlı işletimine ilişkin güncel çerçevedir. TÜRKAK'ın LIMS bilgilendirme kılavuzu da laboratuvar bilgi yönetim sistemlerini standardın bilgi yönetimi bağlamında ele alır. Teknik sonuç; rol bazlı erişim, değiştirilemez olay izi, kontrollü düzeltme, yedekleme ve geri yükleme testlerinin süreç tasarımına dahil edilmesidir.
Ham dosyayı yükleyen kişi kendi kaydını teknik olarak onaylamamalı; hazırlayan, gözden geçiren ve yayımlayan roller ihtiyaca göre ayrılmalıdır. Bir düzeltme gerekiyorsa eski değer, yeni değer, neden, zaman ve kullanıcı kaydedilir. Yedek alındığını varsaymak yerine geri yükleme denemesiyle kanıt üretilir.
Uygulanabilir kısa kontrol listesi
Kısa cevap: Aşağıdaki yedi kontrolün tamamı geçmeden KESA–UBKS zinciri rapora hazır sayılmamalıdır.
- Her bacaya değişmeyen bir ana kimlik verin; proje adını kimlik yerine kullanmayın.
- KESA kaynak dosyasını, çıktısını, sürümünü ve hash'ini aynı hesap revizyonuna bağlayın.
- UBKS referansı, durum, kontrol zamanı ve doğrulayan kullanıcıyı ayrı alanlarda tutun.
- Kritik saha alanlarını iki kayıt arasında karşılaştırın ve farkları görevle yönetin.
- Eski sürümleri silmeyin; yeni revizyonu önceki sürüme açıkça bağlayın.
- Hazırlayan, gözden geçiren ve yayımlayan roller için yetki kapıları kurun.
- Eksik kaynak, açıklanmamış fark veya bekleyen dış doğrulamada rapor yayınını durdurun.
Vizyon Baca çözüm kapsamını inceleyebilir; mevcut KESA ve UBKS iş akışınızdaki kimlik, revizyon ve onay kapılarını değerlendirmek için VizyonTech ile iletişime geçebilirsiniz.
Kaynaklar
- The Software: kesa-aladin — Kesa Technische Software GmbH, erişim 18 Temmuz 2026
- Software maintenance ve güncel teknik veri açıklaması — Kesa Technische Software GmbH, erişim 18 Temmuz 2026
- Ulusal Baca Kontrol ve Kayıt Sistemi Bilgi Merkezi — UBKS, erişim 18 Temmuz 2026
- ISO/IEC 17025:2017, üçüncü baskı; 2023'te teyit edildi — International Organization for Standardization
- Laboratuvar Bilgi Yönetim Sistemleri (LIMS) Bilgilendirme Kılavuzu — TÜRKAK