Workflow zgodności budynkowej

Zestaw dowodów kontrolowany przez proces

Oprogramowanie do zgodności budynkowej nie jest tylko magazynem plików. Musi zarządzać zestawem dowodów stojącym za każdą regulowaną decyzją.

• Dowody projektowe: rysunki, specyfikacje, obliczenia konstrukcyjne i dokumenty strategii pożarowej.
• Dowody produktowe: certyfikaty testów, deklaracje właściwości użytkowych, gwarancje i karty danych producenta.
• Dowody duty-holder: rekordy kompetencji, nominacje, akceptacje i metadane osoby odpowiedzialnej.
• Dowody zmian: RFI, akceptacje, rewizje, dokumenty zastąpione i historia decyzji.
• Wygenerowane rezultaty: pakiety Gateway, pakiety przekazania mieszkańcom, eksporty Golden Thread i paczki audytowe.

Czego BSR naprawdę oczekuje w pakiecie Gateway 2

Tekst prawny jest szeroki, ale operacyjnie oczekiwanie sprowadza się do czterech zdolności.

• Pochodzenie: źródło każdego rekordu kompetencji duty-holder, decyzji projektowej i specyfikacji materiałowej.
• Wersjonowanie: który dokument obowiązywał w dniu decyzji, kto go zatwierdził i co zmieniło się później.
• Referencje krzyżowe: strategia pożarowa powinna cytować rysunek konstrukcyjny, ten powinien prowadzić do certyfikatu testowego systemu fasady i tak dalej przez cały łańcuch.
• Trwałość: pakiet musi być możliwy do obrony 30 lat po przekazaniu, nie tylko w dniu złożenia Gateway 2.

Narzędzia, wyzwalacze i przepływ danych

Wyzwalaczem jest zwykle nowe przesłanie pliku, rewizja, RFI, decyzja projektowa, akceptacja albo żądanie pakietu Gateway w CDE, takim jak Asite, Procore, Viewpoint, Autodesk Construction Cloud lub SharePoint. Proces zostawia CDE jako magazyn plików, a nad nim dodaje walidację, cytaty, sprawdzenia dat ważności i strukturalne powiązania. Dlatego ten temat leży pomiędzy zgodnością budynkową a szerszą automatyzacją dokumentów zgodności.

• CDE pozostaje źródłem plików i dokumentacji projektu.
• Proces klasyfikuje dokumenty i przypisuje je do projektu, budynku, etapu i duty-holder.
• Reguły walidacji sprawdzają ważność, standardy, osoby odpowiedzialne i brakujące referencje.

Model wdrożenia, który przetrwa audyt

Działający model nie polega na wymianie CDE, tylko na położeniu procesu dokumentów nad nim. CDE nadal przechowuje pliki; proces koduje strukturę Golden Thread: kto podjął decyzję, na jakim dokumencie się oparł, która wersja obowiązywała i jakie dowody to potwierdzają.

1. Pobieranie. Każdy rysunek, certyfikat, rekord kompetencji, strategia pożarowa i obliczenie konstrukcyjne trafia do typowanej skrzynki powiązanej z projektem i budynkiem.
2. Ekstrakcja. Agenci asystujący dokumentom czytają skanowane certyfikaty kompetencji, raporty testowe BS i rekordy podobne do CV, zwracając strukturalne, cytowalne dane z numerem strony dla każdej tezy.
3. Walidacja. Reguły duty-holder, śledzenie dat ważności, referencje BS / EN i sprawdzenia akredytacji zamieniają braki w świadome, zalogowane decyzje, a nie przeoczenia.
4. Generowanie. Paperless tworzy pakiet Gateway 2 / Gateway 3 ze zwalidowanych danych, nie z kopiowania ręcznego. Opisy dla podwykonawców mogą powstawać z jednego zatwierdzonego źródła.
5. Audyt. Dla każdego dokumentu widoczny jest ślad pokazujący dokładnie, który dowód wspierał którą decyzję, z możliwością eksportu jako jeden PDF albo archiwum.

Jak wygląda realny Golden Thread w systemie

Konkretnie: to graf zapytań, w którym każdy węzeł jest regulowaną decyzją, a każda krawędź cytatem do dokumentu źródłowego. Gdy BSR pyta, dlaczego wskazano konkretny system fasady, odpowiedź jest przejściem przez graf: decyzja projektowa -> strategia pożarowa -> certyfikat testowy produktu -> rekord kompetencji producenta. Każdy węzeł jest podpisany, oznaczony czasem i powiązany z konkretnym duty-holder. To nie wymaga wyrzucenia CDE - wymaga procesu nad nim.

Jak praktycznie podejść do zgodności budynkowej

Oprogramowanie do zgodności budynkowej nie może być kolejnym magazynem plików. Jeśli system tylko pozwala wrzucać dokumenty, nie tworzy Golden Thread. Potrzebna jest warstwa, która wiąże każdy dowód z budynkiem, etapem Gateway, duty-holder, decyzją, wersją dokumentu i cytatem do źródła.

Praktyczne wdrożenie zaczyna się od jednego typu dowodu, np. rekordów kompetencji albo dokumentów strategii pożarowej. Gdy klasyfikacja, cytaty i daty ważności działają w jednym obszarze, ten sam model można przenieść na certyfikaty produktów, rysunki, RFI, akceptacje i eksport Gateway.

Najważniejsze terminy w tym obszarze to oprogramowanie do zgodności z Building Safety Act, oprogramowanie Golden Thread, pakiet dowodowy Gateway 2, pakiet przekazania Gateway 3 i dowody kompetencji Principal Designer. Część oficjalnych nazw rynku UK warto zostawić, ale wyjaśnienie powinno być po polsku.

• MVP: klasyfikacja dokumentów CDE, daty ważności i lista brakujących dowodów.
• Etap drugi: graf decyzji łączący rysunki, certyfikaty, akceptacje i duty-holder.
• Etap trzeci: eksport pakietu Gateway z referencjami do źródeł i komentarzami audytowymi.

Zarządzanie i model odpowiedzialności

Największe ryzyko w projektach BSA nie polega na tym, że dokument nie istnieje. Ryzyko polega na tym, że nikt nie potrafi udowodnić, która wersja obowiązywała, kto ją zatwierdził i na jakim dowodzie oparto decyzję. Proces musi mieć właścicieli: kto odpowiada za typ dokumentu, kto może zatwierdzić wyjątek i kto widzi rozbieżności.

Ta warstwa zarządzania pozwala używać istniejącego CDE bez dużej zmiany pracy zespołu. CDE pozostaje tam, gdzie zespół trzyma pliki, a proces staje się warstwą kontroli i dowodów nad nim. To zmniejsza opór przed wdrożeniem i poprawia gotowość audytową.