Standard BIM w biurze projektowym: parametry, nazwy i odpowiedzialność
Standard BIM nie jest dokumentem, który ma dobrze wyglądać w folderze. Jest językiem pracy zespołu. Jeśli parametry, nazwy i odpowiedzialność są niejasne, model może być trójwymiarowy, ale informacyjnie pozostaje kruchy.
Parametr to obietnica
Każdy parametr obiecuje, że jakaś informacja będzie dostępna w określonym miejscu, w określonej formie i w określonym momencie. Jeśli ta obietnica nie jest jasna, parametr staje się pustą kolumną. Można go dodać do modelu, ale nikt nie wie, kto ma go uzupełnić, kiedy i według jakiego słownika.
Dlatego przy parametrach ważniejsze od samej nazwy jest znaczenie. Co dokładnie przechowuje ten parametr? Czy jest tekstem, liczbą, kodem, wyborem ze słownika? Czy może być pusty? Czy trafia do zestawienia, etykiety, eksportu IFC, raportu koordynacyjnego?
Nazwy są interfejsem zespołu
Nazwy widoków, arkuszy, typów, plików i eksportów są pierwszym interfejsem użytkownika w biurze projektowym. Jeżeli każdy nazywa rzeczy inaczej, ludzie tracą czas nie dlatego, że nie znają programu, ale dlatego, że muszą zgadywać intencję innych osób.
Dobra konwencja nazewnicza nie powinna być przesadnie akademicka. Musi być wystarczająco prosta, żeby ludzie jej używali, i wystarczająco jednoznaczna, żeby dało się ją sprawdzić automatycznie. To ostatnie jest kluczowe: jeśli standardu nie da się walidować, będzie zależał wyłącznie od pamięci i dyscypliny.
Odpowiedzialność jest częścią standardu
Wiele standardów opisuje, co ma być zrobione, ale nie mówi, kto odpowiada za utrzymanie reguły. To prosta droga do erozji. Kto aktualizuje słownik wartości? Kto zatwierdza nowy parametr? Kto decyduje, czy wyjątek jest dopuszczalny? Kto poprawia szablon po projekcie pilotażowym?
Bez odpowiedzialności standard staje się statyczny, a projekty są dynamiczne. Po kilku miesiącach dokument przestaje pasować do praktyki. Ludzie zaczynają tworzyć lokalne obejścia, a automatyzacja musi obsługiwać coraz więcej wyjątków.
Automatyzacja standardu
Najzdrowsza automatyzacja standardu nie zaczyna od masowej zmiany modelu. Zaczyna od raportu. Najpierw pokaż, które elementy nie spełniają reguły. Dopiero potem decyduj, co można poprawić automatycznie, a co wymaga decyzji projektanta.
To podejście buduje zaufanie. Zespół widzi, że narzędzie nie zabiera kontroli, tylko odsłania miejsca wymagające uwagi. Z czasem część reguł można automatycznie naprawiać, ale raport nadal powinien pozostać podstawą rozmowy o jakości danych.
Źródła i punkty odniesienia
W tle tego tematu są standardy buildingSMART, szczególnie openBIM i IDS, oraz dokumentacja Autodesk dotycząca parametrów Revit. Ten wpis nie jest streszczeniem normy, tylko praktyczną próbą przełożenia tych idei na codzienną pracę biura projektowego.