Cztery wersje rysunku, dwa pliki z dopiskiem final i nikt nie wie, który poszedł do zamawiającego. Pokazuję, jak ISO 19650 porządkuje nazwy plików, statusy i metadane, i daję gotowy standard nazewnictwa z checklistą wdrożenia.
Ostatni odbiór dokumentacji, w którym brałem udział, zaczął się od pytania, która wersja rysunku wentylacji jest obowiązująca. Na dysku leżały cztery pliki z trzech tygodni, dwa z dopiskiem final i jeden z dopiskiem final_poprawiony_po_uwagach. Nikt nie potrafił powiedzieć, który poszedł do zamawiającego. Skończyło się telefonem do osoby na urlopie.
To nie historia o niechlujstwie, tylko o braku jednej uzgodnionej zasady. ISO 19650 mówi dokładnie o tym, tylko językiem trudnym do przebrnięcia, bo pisano ją dla zamawiających.
W tym wpisie pokażę:
- co z ISO 19650 naprawdę trzeba wiedzieć, żeby pracować,
- jak zbudować nazwę pliku z siedmiu pól i jakich wartości używać,
- czym różni się status od rewizji i kiedy plik wolno wysłać dalej,
- które metadane warto wypełniać, a które są kosztem bez zysku,
- jak wdrożyć standard nazw w tydzień, bez konsultanta i nowego oprogramowania.
Na końcu znajdziesz gotowy standard nazewnictwa i checklistę wdrożenia do pobrania, w PDF i w XLSX.
ISO 19650 w trzech akapitach
ISO 19650 to norma o zarządzaniu informacją, nie o modelowaniu. Nie ma w niej nic o rodzinach w Revicie ani o eksporcie IFC. Są zasady: kto odpowiada za informację, w jakim stanie musi być, zanim ktoś inny na niej pracuje, i jak udowodnić, że plik na ekranie jest tym, o którym rozmawia zespół. Seria ma pięć części, ale w biurze projektowym liczą się dwie: pojęcia i faza realizacji.
Podstawowym pojęciem nie jest plik, ale kontener informacji: każdy identyfikowalny zestaw informacji, czyli rysunek PDF, model IFC, zestawienie stali, specyfikacja albo raport. Kontener ma nazwę, metadane (status, rewizję, klasyfikację) i miejsce w wspólnym środowisku pracy, czyli w CDE. Norma nie przesądza, czy CDE to Dalux, BIMcollab czy folder na serwerze z porządnymi uprawnieniami. Przesądza, że to uzgodnione źródło informacji, a nie jeden z kilku równoległych kanałów. Jeśli obok działa mail i WeTransfer, CDE przestaje być źródłem prawdy. Czym różni się od zwykłego dysku, pisałem we wpisie Czym jest platforma CDE.
Trzecia rzecz to odpowiedzialność. Zamawiający określa w EIR, jakiej informacji potrzebuje, lider zespołu przekłada to na BEP i plan dostaw MIDP, a każdy zespół zadaniowy rozpisuje własny TIDP. Brzmi jak biurokracja, ale sens jest prosty: ktoś musi powiedzieć, co ma być dostarczone i kiedy, zanim ktokolwiek zacznie rysować.
I najważniejsze zdanie z całej normy: ISO 19650 nie narzuca jednego sposobu nazywania plików. Wymaga, żeby konwencja była uzgodniona, zapisana i stosowana przez wszystkich. Brytyjski aneks krajowy pokazuje jedną z możliwych konwencji i to ona zrobiła największą karierę w branży. Możesz użyć innej. Nie możesz nie mieć żadnej.
Nazewnictwo: siedem pól, które robią całą robotę
Konwencja z brytyjskiego aneksu składa się z siedmiu pól rozdzielonych myślnikiem. Kolejność jest ustalona, bo nazwa ma być czytelna od lewej do prawej i sortowalna. Każde pole ma zamknięty słownik wartości: nazwa ma dać się jednoznacznie zbudować i odczytać.
| Pole | Co wpisać | Przykład |
|---|---|---|
| 1. Projekt | Kod projektu, nadany raz, 2 do 6 znaków | OS22 |
| 2. Originator | Kod organizacji, która wytworzyła informację | BIP |
| 3. Bryła lub system | Podział przestrzenny albo systemowy, 2 znaki | B1 |
| 4. Poziom lub lokalizacja | Kondygnacja lub lokalizacja, 2 znaki | 01 |
| 5. Typ | Rodzaj kontenera, 2 znaki | DR |
| 6. Dyscyplina | Branża autora, 1 lub 2 znaki | P |
| 7. Numer | Numer sekwencyjny, 4 do 6 cyfr | 0142 |
Złożona nazwa: OS22-BIP-B1-01-DR-P-0142. Czyta się ją bez zaglądania do tabeli: projekt Osiedle Słoneczne 2022, biuro BIP, budynek 1, pierwsze piętro, rysunek, branża sanitarna, numer 142. Nazwa nie mówi, co jest na rysunku, i dobrze, bo od tego jest tabelka rysunkowa i opis w CDE.
Trzy zasady, na których to stoi. Nazwa identyfikuje kontener, nie opisuje go, więc nie ma w niej miejsca na ostateczny ani poprawiony. Status i rewizja nie należą do nazwy, dopóki plik jest w CDE, tylko do metadanych; wyjątkiem jest sytuacja, gdy kontener opuszcza CDE, wtedy dopisuje się je na końcu jako sufiks. Numer jest sekwencyjny w obrębie pozostałych pól i się nie powtarza, bo numer rysunku z tabelki to inna rzecz niż numer kontenera.
Kody typów i dyscyplin: gotowa lista na start
Nie wymyślaj kodów od zera. Najczęstsze typy to DR rysunek, M3 model 3D, M2 model 2D, SP specyfikacja, RP raport, SH zestawienie, CA obliczenia, CM model zbiorczy, MI notatka ze spotkania, SU inwentaryzacja. Dyscypliny: A architekt, S konstruktor, M mechanika, E elektryka, P instalacje sanitarne, H ogrzewanie i wentylacja, K zamawiający, W wykonawca, Z opracowania ogólne.
Tu polska praktyka rozjeżdża się z brytyjską. W aneksie H i P to dwie dyscypliny, bo w Wielkiej Brytanii wentylacja i wod-kan to zwykle dwie firmy, a w Polsce często jeden projektant. Albo dzielisz pliki na H i P, albo definiujesz własny kod, na przykład I dla instalacji, i zapisujesz go w standardzie. Zła jest tylko sytuacja, w której połowa zespołu używa H, a połowa P.
Warto zapamiętać dwa kody: ZZ znaczy wszystkie bryły albo kondygnacje, XX znaczy, że pole nie dotyczy kontenera. Bez nich ludzie wpisują w pole poziomu nazwę budynku albo zostawiają puste miejsce.
Statusy i rewizje: dwie różne rzeczy, które ludzie mieszają
Status mówi, do czego informacja się nadaje. Rewizja mówi, którą iteracją jest. Mieszanie tych dwóch rzeczy to najczęstszy powód, dla którego zespół przestaje ufać dokumentacji. Plik może być trzecią rewizją i nadawać się tylko do koordynacji, a pierwszą i być zatwierdzony do budowy.
| Status | Znaczenie | Stan w CDE |
|---|---|---|
| S0 | Praca w toku, wewnątrz zespołu autora | WIP |
| S1 | Nadaje się do koordynacji międzybranżowej | Shared |
| S2 | Nadaje się do informacji i jako odniesienie | Shared |
| S3 | Nadaje się do przeglądu i komentarzy | Shared |
| S4 | Nadaje się do przeglądu i zatwierdzenia | Shared |
| S5 | Nadaje się do przeglądu i akceptacji | Shared |
| A1, A2 i kolejne | Zatwierdzone lub przyjęte, wydanie umowne | Published |
| B1, B2 i kolejne | Częściowe zatwierdzenie z uwagami | Published |
| CR | Dokument powykonawczy do eksploatacji | Published |
Cyfra przy statusie A i B to nie numer rewizji, tylko etap, na którym informacja została wydana. Projekt definiuje ją w swoim standardzie informacyjnym. Bez tego po dwóch miesiącach nikt nie wie, czy A2 to zatwierdzenie na etapie koncepcji, czy drugie zatwierdzenie w tym samym etapie.
Rewizje mają dwie rodziny. Wstępne, nieumowne, dostają prefiks P: P01, P02. Umowne, formalnie wydane, dostają C: C01, C02. Praca w toku może dostać numerację po kropce, na przykład P01.01, co pozwala odróżnić dwa wydania tego samego dnia.
Zasada do każdego BEP: nazwa i numer kontenera nie zmieniają się nigdy, zmienia się status i rewizja. Jeśli nazwa zmienia się przy każdej korekcie, to w nazwie siedzi opis.
Kiedy plik wolno puścić dalej
Najprostsza reguła, jaką znam: plik wychodzi z WIP dopiero wtedy, kiedy jest kompletny w zakresie, który deklarujesz w statusie. Jeśli oznaczasz coś jako S1 do koordynacji, inny branżysta może na tym pracować i nie traci czasu na dopytywanie o braki. Wysłanie niedokończonego pliku ze statusem S1 kończy się poprawianiem cudzych luk.
Drugi próg to publikacja. Status A dostaje informacja sprawdzona i zaakceptowana przez osobę do tego uprawnioną, w małym biurze zwykle właściciela albo kierownika projektu. Musi to być zapisane, inaczej status A nadaje ten, kto akurat wysyła maila.
Metadane: sześć pól i koniec
Minimum z aneksu to trzy pola: status, rewizja i klasyfikacja. W praktyce dochodzą trzy, bez których nie da się pracować: kto wydał, kiedy i w jakim celu. Razem sześć. Wszystko powyżej jest opcjonalne i powinno mieć uzasadnienie w zastosowaniu.
| Pole | Minimum czy nadmiar | Po co |
|---|---|---|
| Status | Minimum | Mówi, do czego informacja się nadaje |
| Rewizja | Minimum | Daje ślad zmian i porządek wydań |
| Klasyfikacja | Minimum | Pozwala grupować informacje niezależnie od folderów |
| Autor wydania | Praktyka | Wiadomo, do kogo wrócić z pytaniem |
| Data wydania | Praktyka | Porządkuje wydania i wykrywa spóźnienia |
| Cel wydania | Praktyka | Odróżnia wydanie do koordynacji od wydania do budowy |
| Opis poziomu rozwoju | Nadmiar | Duplikuje status i nikt go nie aktualizuje |
| Numer umowy | Nadmiar | Wynika z projektu, nie zmienia się per plik |
| Tagi i kategoria | Nadmiar | Działa tylko przy zamkniętej liście wartości |
Klasyfikacja to miejsce, w którym najłatwiej zrobić sobie krzywdę. Aneks podaje Uniclass i OmniClass, oba porządne, ale żaden nie jest w Polsce standardem. Jeśli nie masz systemu klasyfikacji, nie udawaj, że masz. Jedno pole kategoria z zamkniętą listą dziesięciu wartości działa lepiej niż Uniclass wpisany na wyczucie, bo taki wpis wygląda jak dane, a nie jest.
Druga zasada: metadane wypełnia autor przy eksporcie, nie koordynator po fakcie. Koordynator uzupełniający statusy za cały zespół robi to dobrze przez dwa tygodnie, a potem przestaje, bo ma własne rysunki. Metadane muszą powstawać razem z informacją.
Wdrożenie w tydzień: kolejność, która ma znaczenie
Ten plan nie wymaga nowego oprogramowania ani konsultanta. Wymaga jednej osoby z kilkoma godzinami dziennie i jednego spotkania z zespołem. Kolejność ma znaczenie, bo każdy krok korzysta z poprzedniego.
- Inwentaryzacja. Wypisz dwadzieścia najczęstszych typów plików, które wychodzą z biura, nie teoretycznych, tylko wysyłanych. To lista wartości do pola typ.
- Kody. Ustal kod projektu, kody organizacji, podział na bryły, listę kondygnacji i dyscyplin. Wszystko jako zamknięte słowniki, nie jako dobra wola.
- Standard na jednej stronie. Tabela pól, dopuszczalne wartości, jeden pełny przykład i nazwisko właściciela standardu.
- Struktura CDE. Drzewo folderów z podziałem na WIP, Shared, Published i Archive oraz zasada, kto przenosi pliki między nimi.
- Statusy i rewizje. Wybierz kody, których naprawdę będziesz używać, i opisz przejścia między nimi. Sześć kodów stosowanych konsekwentnie bije piętnaście na papierze.
- Szkolenie i pierwsza kontrola. Czterdzieści pięć minut z zespołem, na ich własnych plikach, potem sprawdzenie dziesięciu przypadkowych plików z ostatniego miesiąca.
- Poprawki i zamknięcie. Popraw standard tam, gdzie okazał się niepraktyczny, ustaw datę przeglądu za trzy miesiące i zapisz, kto pilnuje stosowania.
Punkt szósty jest najważniejszy. Standard niesprawdzony na realnych plikach zawiera pole, którego nie da się wypełnić, albo kod, którego nikt nie rozumie.
Typowe błędy wdrożeniowe
Standard bez właściciela. Po pół roku nikt nie pamięta, czy B1 i B2 to budynki, czy podziemia. Właściciel nie musi być kierownikiem, musi być osobą, do której idzie się z pytaniem.
Nazwy dłuższe niż ścieżka. Windows ma historyczny limit 260 znaków na pełną ścieżkę i choć od Windows 10 da się go poluzować ustawieniem LongPathsEnabled, nie każdy program to respektuje. Projekt, inwestycja, bryła, kondygnacja, branża i plik nie chce się otworzyć przez sieć.
Brak zmiany rewizji przy zmianie statusu. Plik dostaje status A i zostaje przy rewizji P02. Po tygodniu ktoś poprawia rysunek, rewizja dalej P02, status dalej A. W środku są dwie różne treści pod jednym identyfikatorem. Każda zmiana treści to nowa rewizja, każda zmiana przeznaczenia to nowy status.
Nazwa opisowa i słowa final, ostateczny, do wysyłki. Rzut_pietra_1_instalacje_poprawiony.dwg to notatka, nie nazwa kontenera. Słowo ostateczny było prawdziwe przez jeden dzień, potem pojawia się final_2 i konwencja się rozsypuje.
Drugi kanał poza CDE. Mail z załącznikiem jest szybszy, więc ludzie go używają, a potem w CDE leży wersja starsza o dwa dni. Rozwiązaniem nie jest zakaz, tylko skrócenie drogi: cztery kliknięcia i ludzie wrzucą, dwanaście i wyślą mailem.
Brak zasady dla plików spoza standardu. Co zrobić ze skanem uzgodnienia, dokumentacją dostawcy i zdjęciem z budowy. Bez takiej zasady pliki lądują w pierwszym lepszym folderze. Wystarczy jeden kod typu i reguła: dokument zewnętrzny trafia do korespondencji, z kodem dostawcy w polu originator.
Nadmiar metadanych. Dwadzieścia pól, z których połowa jest pusta, wygląda profesjonalnie i nic nie wnosi. Zespół wypełnia je przez pierwszy miesiąc, potem tylko te wymagane przez system. Sześć prawdziwych pól jest warte więcej niż dwadzieścia fałszywych.
Podsumowanie
ISO 19650 nie jest dokumentem, który trzeba przeczytać od deski do deski, żeby pracować. Cztery rzeczy zmieniają codzienną pracę: kontener ma jednoznaczną nazwę, status mówi, do czego się nadaje, rewizja mówi, którą wersją jest, a metadane są kompletne w szóstce pól.
Największą korzyść widać pół roku później, przy odbiorze dokumentacji albo przy pytaniu wykonawcy o konkretny rysunek. Standard nazw działa tak samo w małym biurze bez CDE i w projekcie publicznym, więc nie trzeba czekać na platformę.
Jak taki porządek wygląda w praktyce wdrożenia, przeczytasz we wpisach Jak wdrożyć BIM, część 1 i Wdrażanie BIM w Twoim biurze, część 2. Jeśli szukasz narzędzia, a nie standardu, pomocny będzie ranking platform CDE. Ciekawym przypadkiem wersjonowania poza CDE jest też GitHub jako repozytorium dokumentacji projektowej.
Standard nazewnictwa i checklista do pobrania
Przygotowałem paczkę z tym, co opisuję powyżej, w formie gotowej do użycia w biurze:
- standard nazewnictwa: pola, dopuszczalne wartości i trzy przykłady (bez CDE, z CDE, projekt publiczny),
- drzewo folderów CDE z podziałem na stany informacji, gotowe do skopiowania,
- statusy i rewizje wraz z zasadami przejść,
- checklistę wdrożenia, dwanaście punktów w kolejności,
- wersję PDF do czytania i XLSX do edycji.
Wersja XLSX to szablon: wpisz swoje kody w miejsce przykładowych i rozdaj zespołowi. PDF wydrukuj i powieś przy stanowisku, bo standardy, które żyją tylko na dysku, umierają.
Pobierz standard nazewnictwa i checklistę: wersja PDF oraz wersja XLSX.
Źródła
Norma ISO 19650 jest dokumentem płatnym, więc podaję opracowania, na których się opierałem. Tabele kodów są uproszczone i dostosowane do polskiej praktyki.
- Centre for Digital Built Britain, BIM Toolkit, National Annex Guidance (PDF), wzór aneksu krajowego do ISO 19650-2 z przykładami pól, statusów i rewizji.
- UK BIM Framework (IMI Framework), standardy i wytyczne do wdrożenia zarządzania informacją, prowadzone przez BSI i nima.
- PD(io), UK National Annex status and use reference table, omówienie statusów z podziałem na role.
- Autodesk Knowledge Network, ISO 19650 naming standard template, przykład konfiguracji standardu nazw.
- Microsoft Learn, Maximum path length limitation, źródło o limicie 260 znaków i ustawieniu LongPathsEnabled.
- buildingSMART, openBIM i standardy wymiany informacji, w tym IFC i BCF.
