Jak nazywać pliki modelu i kolejne wersje?
Czytelna nazwa pliku modelu pozwala od razu rozpoznać branżę, zakres opracowania i moment, w którym plik został uzgodniony. W koordynacji dokumentacji budowlanej ten zapis zastępuje domysły i skraca czas szukania właściwej kopii w folderze wymiany.
Gdy każdy uczestnik zapisuje model według własnego zwyczaju, w obiegu pojawiają się pliki o podobnych tytułach i różnej treści. Zespół może wtedy poprawiać opracowanie na podstawie nieaktualnej geometrii, a te same kolizje wracają na kolejne spotkanie koordynacyjne.
Składniki czytelnej nazwy pliku
Praktyczny schemat łączy stałe człony w jednej kolejności: kod projektu, branża, zakres modelu, data wydania i numer wersji. Kolejność opisuje się w instrukcji wymiany danych, zanim pierwszy model trafi na wspólną przestrzeń projektu.
Branżę oznacza się krótkim, uzgodnionym kodem, na przykład ARC dla architektury, KON dla konstrukcji, SAN dla instalacji sanitarnych albo ELE dla instalacji elektrycznych. Zakres doprecyzowuje, czy plik obejmuje cały obiekt, jedną kondygnację, fragment etapu albo tylko model przygotowany do zestawienia.
W nazwie nie stosuje się spacji ani opisów roboczych takich jak ostateczny albo końcowy. Takie dopiski szybko tracą znaczenie i utrudniają porównanie plików. Krótkie kody rozdzielone pojedynczym podkreśleniem łatwiej sortować i zestawić z rejestrem wydań.
Data, numer wersji i status
Data w nazwie oznacza dzień wydania pliku do uzgodnienia, a nie dzień ostatniego zapisu na dysku autora. Format RRRRMMDD układa pliki w porządku chronologicznym i nie zależy od ustawień języka w programie do modelowania.
Numer wersji rośnie tylko wtedy, gdy model zostaje świadomie wydany do wspólnego obiegu. Plik roboczy zostaje u autora i nie zastępuje modelu, który koordynator już sprawdził. Dzięki temu numer w nazwie odpowiada pozycji w rejestrze, a nie liczbie zapisów w trakcie dnia.
Status dopisuje się jako osobny krótki człon, na przykład WIP dla pracy w toku, SHR dla pliku udostępnionego do przeglądu albo PUB dla wersji opublikowanej do dalszej koordynacji. Status i numer wersji zmieniają się razem, ponieważ sama nazwa nie powinna sugerować uzgodnienia, którego jeszcze nie było.
Jak nie pracować na starej kopii
Przykładowy zapis PH_KON_BUD_A_20260315_V03_SHR pokazuje kod projektu, branżę konstrukcyjną, zakres budynku A, datę wydania, trzecią wersję i status udostępnienia do przeglądu. Ten sam układ obowiązuje kolejne pliki, a zmienia się tylko ten człon, który faktycznie odróżnia nowe wydanie od poprzedniego.
Uzgodniony model ma jedną lokalizację wymiany i nazwę, która nie pokrywa się z nazwą pliku roboczego. Po publikacji nowej wersji poprzedni plik trafia do archiwum albo dostaje oznaczenie, że nie służy do dalszego modelowania ani do zestawień koordynacyjnych.
Przed podłączeniem modelu uczestnik sprawdza branżę, datę i numer wersji. Jeśli którykolwiek człon nie zgadza się z rejestrem wydań, plik nie wchodzi do zestawienia koordynacyjnego. Taka kontrola jest krótka, a ogranicza pracę na kopii sprzed ostatnich ustaleń między branżami.
W wiadomości o wydaniu wystarczy podać pełną nazwę pliku, zakres zmian i informację, które wcześniejsze wersje nie są już podstawą koordynacji. Data modyfikacji widoczna w folderze nie wystarcza, ponieważ zmienia się także przy zwykłym kopiowaniu pliku między katalogami.