Szablony projektów BIM: jak je zbudować, żeby skrócić start każdego nowego zlecenia

Potrzebujesz szablonów BIM, które uruchamiają nowy projekt w kilka minut, a nie w kilka godzin. Klucz: zbudować je raz, utrzymać w ryzach i sprawić, by zespół korzystał z nich bez kombinowania. Poniżej konkretne kroki, co umieścić w szablonie, jak to poukładać i jak nie wpaść w typowe pułapki.

• Na co odpowiedzieć przed startem:
  • Co dokładnie ma dawać szablon BIM po otwarciu – gotowe arkusze, widoki, zestawienia, ustawienia eksportu?
  • Jaki poziom LOD/LOI zakładasz na poszczególnych etapach i jak to egzekwujesz filtrami/legendami?
  • Jakie nazewnictwo i parametry wspólne są obowiązkowe, a które są opcjonalne?
  • Co trafia do szablonu, a co zostaje w bibliotece zewnętrznej?
  • Jak rozwiązujesz współrzędne, worksharing i linki międzybranżowe?
  • Jak uruchamiasz QA/QC: reguły, widoki kontrolne, automatyzacja (Dynamo/Python)?
  • Jak wersjonujesz i dystrybuujesz szablony, żeby nie było „mamy 7 różnych wersji w obiegu”?
  • Jak wdrażasz zespół i mierzysz adopcję?

1. Zanim zaczniesz: trzy pułapki, które psują każdy szablon

Krok 1: oddziel szablon od „starter project”

Szablon (template) to czysty plik startowy bez danych projektowych. Starter project to demonstracyjny układ z przykładowymi widokami/arkuszami, który pomaga nowym osobom zrozumieć standard – nadaje się do przejrzenia, nie do kopiowania. Zmieszanie tych dwóch kończy się przenoszeniem przypadkowych ustawień, poziomów i arkuszy z cudzym logo.

Krok 1: utrzymaj jeden plik .rte/.rfa/.dwt bez żadnych referencji do poprzedniego projektu. Krok 2: trzymaj „starter” w osobnym folderze „Edukacja/Przykłady” i jasno oznacz, że służy tylko jako podgląd.

Praktyczny trik: dodaj w szablonie widok „READ_ME – instrukcja startu” z krótką listą czynności na pierwsze 15 minut oraz linkiem do wiki firmowej.

Krok 2: nie kopiuj starego modelu jako bazy

Kopiowanie końcowego RVT z poprzedniego zlecenia to szybka droga do błędów: pozostają ukryte style, filtry, nieużywane materiały, martwe worksety, rozjechane współrzędne i pozostałości po linkach. Czysty szablon zbuduj od zera albo z firmowego „seed file”, ale po gruntownym odchudzeniu.

Minimalny proces sanityzacji, jeśli bazujesz na seed file:

• Usuń wszystkie linki, importy CAD i obrazy.
• Ustaw domyślne współrzędne i zeruj punkt bazowy/survey (o ile standard biura nie narzuca inaczej).
• Wyczyść style linii, hatchy, materiałów, wzorów i zmapuj do standardu.
• Przejrzyj obiekty systemowe: poziomy, siatki, fazy, zestawy kategorii – usuń zbędne.
• Utwórz od nowa widoki i arkusze – nie zostawiaj nic „po kimś”.

Krok 3: zakres – jeden ogólny + warianty branżowe

Jeden gigantyczny szablon BIM „do wszystkiego” robi się ciężki, wolny i skomplikowany. Lepiej: szablon ogólny (wspólne standardy) + lekkie warianty branżowe (A/K/MEP). Wspólne parametry i nazewnictwo trzymaj centralnie, a branżowe różnice (widoki, filtry, rodziny) dokładaj w wariantach.

Przykład: biuro instalacyjne operuje na „MEP_Base.rte” (naming, parametry wspólne, filtry QA, ustawienia eksportu) oraz „MEP_HVAC.rte” i „MEP_Plum.rte” (dedykowane rodziny, zestawienia i filtry kolorujące systemy). Modyfikacje ogólne dotykają jednego pliku; branżowe – swoich wariantów.

Co sprawdzić po tej sekcji

• Czy twój plik szablonu otwiera się w poniżej 10 sekund na typowej stacji roboczej?
• Czy w szablonie nie ma arkuszy z logo klienta, importów CAD i linków?
• Czy masz rozdzielone: Template vs Starter Project?
• Czy wyznaczyłeś, które elementy trafiają do ogólnego szablonu, a które do wariantów branżowych?

2. Filary szablonu: cele, standardy i poziomy informacji (LOD/LOI)

Krok 1: wyciągnij cele z EIR/BEP

Szablon BIM musi odzwierciedlać wymagania informacyjne klienta (EIR) oraz sposób pracy ustalony w BEP. Zdefiniuj:

• Jakie zestawienia i transmittale masz generować z modelu?
• Jakie formaty wymiany: IFC, NWD/NWC, RVT, COBie?
• Jakie klasyfikacje i kody muszą być przypisane (np. Uniclass, OmniClass, CCS)?
• Jakie atrybuty będą obowiązkowe: status, dyscyplina, autor, rewizja, data, ID elementu?

Następnie budujesz w szablonie gotowe zestawienia z odpowiednimi kolumnami, presety eksportu oraz filtry.

Krok 2: przypisz LOD/LOI do etapów

Ustal matrycę: na jakim etapie projekt ma jaką gęstość geometrii (LOD) i informacji (LOI). To nie tylko hasło – to realne filtry, widoki i reguły QA, które w szablonie oznaczają brakujące dane.

Krok 3: zmapuj parametry obowiązkowe

Stwórz listę parametrów, które muszą istnieć na każdym elemencie, ścianie, rodzinie i typie. To są twoje parametry wspólne (shared parameters). Mapuj je do kategorii i zdefiniuj jako:

• Wymagane: np. Kod klasyfikacji, Status_Projektowy, Dyscyplina, Autor, Faza.

Rozpisz parametry w trzech koszykach i powiąż je z etapami oraz eksportem.

• Wymagane (zawsze): Kod_klasyfikacji, Status_Projektowy, Dyscyplina, Autor, Faza, Data_Aktualizacji.
• Warunkowe (wg etapu): np. Odporność_Ogniowa od etapu PB, Kod_Produktu od PW, Nr_Pokoju po ustaleniu układu funkcjonalnego.
• Opcjonalne (pomocnicze): Uwagi, Opis_Szczegółowy – nie blokują QA, ale poprawiają czytelność.

Krok 1: utrzymuj jeden plik shared parameters z kontrolą dostępu. Nie duplikuj GUID-ów, nie zmieniaj nazw parametrom już wdrożonym w rodzinach.

Krok 2: przypisz parametry do kategorii i grup w UI (np. „Dane BIM”), tak by były w tym samym miejscu w oknie Właściwości. Ustal konwencję nazewnictwa z prefixem, np. PJT_ dla firmowych, COBie_ dla eksportowych.

Krok 3: zmapuj parametry do eksportu IFC/COBie (Psets). Jeśli używasz niestandardowych nazw, dodaj reguły mapowania w presetach eksportu. Unikniesz sytuacji „parametr jest w modelu, ale nie wyszedł do IFC”.

Przykład: PJT_Kod_klasyfikacji → mapowanie do Classification.Reference w IFC; COBie_SerialNumber zostaje jako natywny dla eksportu COBie.

Co sprawdzić po tej sekcji

• Czy każdy element ma przypisaną Dyscyplinę i Fazę bez ręcznych wyjątków?
• Czy masz jeden shared parameters.txt i czy jest zablokowany przed edycją ad hoc?
• Czy presety eksportu poprawnie mapują kluczowe parametry do Psetów IFC/COBie?

3. Widoki, filtry i arkusze: pakiet startowy gotowy po otwarciu

Krok 1: struktura przeglądarki widoków

Utwórz logiczne foldery w przeglądarce, aby każdy nowy projekt wyglądał tak samo.

• 00_SETUP – READ_ME, widoki startowe, siatki/scope boxy.
• 10_MODEL – widoki robocze dyscyplin (A/K/MEP) z odpowiednimi szablonami widoków.
• 20_DOK – widoki na dokumentację (czyste, bez koloryzacji QA).
• 90_QAQC – widoki kontrolne z filtrami błędów, kolorowankami LOD/LOI.

Praktyczny sens: każdy wie, gdzie modelować, gdzie sprawdzać i skąd drukować – mniej pytań na czacie.

Krok 2: filtry kontrolne, które łapią braki

• Brak_Klasyfikacji – elementy bez Kod_klasyfikacji w czerwieni.
• Zła_Faza – elementy w niepoprawnej fazie (np. „Istniejące” w nowym projekcie) na pomarańczowo.
• Bez_Systemu_MEP – rodziny MEP nieprzypisane do systemu w fiolecie.
• LOD_Ponad_Etap – elementy zbyt „detalne” jak na aktualny etap, wyszarzone.

Przykład: widok QA „A_QA – klasyfikacja” z aktywnymi filtrami pozwala jednym rzutem oka złapać braki przed wysyłką NWC.

Krok 3: arkusze i ramki tytułowe bez brandingu klienta

• Arkusze wzorcowe A1/A2 z neutralnym tytułblokiem firmowym i polami na: Projekt, Etap, Rewizja, Autor.
• Scope boxy o nazwach SB_Pion, SB_Poziom_01, SB_Strefa_A gotowe do przypięcia widoków.
• Placeholdery dla tabel rewizji i legend – bez treści, ale z formatowaniem.

Oszczędność: ustawione marginesy, skale i siatka układu skracają skład pierwszych arkuszy do kilku minut.

Krok 4: gotowe zestawienia pod decyzje

• ZT_Elementy_typami – kolumny: Rodzina, Typ, Ilość, Kod_klasyfikacji, Faza; sortowanie po Rodzina/Typ.
• ZT_Drzwi – Szerokość, Wysokość, Kierunek, EI, Kod_klasyfikacji; pole wyliczane „Braki” = IF(EI=””, „BRAK EI”, „”).
• ZT_Powierzchnie – Strefa, Pomieszczenie, Powierzchnia_Netto, Status; sumy częściowe po strefach.

Co sprawdzić po tej sekcji

• Czy folder 90_QAQC ma minimum 3 widoki kontrolne z aktywnymi filtrami?
• Czy arkusze wzorcowe nie zawierają logotypów klientów i danych historycznych?
• Czy każde zestawienie posiada kolumnę „Braki” lub filtr pokazujący nieuzupełnione pola?

4. Biblioteka rodzin i typów: co wrzucić do szablonu, a co do biblioteki

Krok 1: zasada 80/20

W szablonie trzymaj tylko najlżejsze i najczęściej używane typy. Reszta w zewnętrznej bibliotece z przyciskiem „Wczytaj z biblioteki”. Szablon ma się otwierać szybko.

Krok 2: typy domyślne i materiały placeholder

• Typy „GEN_” dla elementów bazowych (np. GEN_Ściana_WeW_12), z materiałem MAT_Placeholder.
• Brak detali producenta – dodajesz je dopiero na etapie PW.

Krok 3: standard parametrów rodzin

• Parametry instancji: Poziom_Montażu, Numeracja, Faza.
• Parametry typu: Kod_klasyfikacji, Opis_Typu, Producent (puste).
• Zakaz swobodnych parametrów typu „Komentarz2”. Używaj wspólnych parametrów z pliku firmowego.

Krok 4: kontrola jakości rodzin

• Geometrycznie lekkie: brak nadmiarowych zaokrągleń, symbolika 2D tam, gdzie 3D niepotrzebne.
• Punkt bazowy i orientacja zgodne ze standardem (Insertion Point = 0,0,0; osie zgodne z projektem).
• Test: rodzina wczytana do pustego pliku nie generuje ostrzeżeń.

Co sprawdzić po tej sekcji

• Czy w szablonie pozostały wyłącznie typy „GEN_” i najczęstsze profile/materialy?
• Czy żadna rodzina nie przekracza rozsądnie kilkuset kB bez powodu?
• Czy każda rodzina używa tych samych wspólnych parametrów GUID?

5. Koordynacja międzybranżowa i linki: ustaw raz, używaj zawsze

Krok 1: wspólne współrzędne i punkt bazowy

Ustal jeden sposób pracy z układem współrzędnych: Publish/Acquire lub ręczne dopasowanie do Survey Point – i opisz to w READ_ME w szablonie.

• Preset: widok „00_SETUP – osie i punkty” z odblokowanym Survey/Internal/Project Base Point.
• Reguła: linki zawsze By Shared Coordinates; zakaz „Auto – Origin to Origin” w projektach wielobranżowych.

Przykład: link A do K po „Shared”, test kolizji w NWC bez przesunięć o „tajemnicze” 50 mm.

Krok 2: worksety dla linków i tła

• WS_LINK_A, WS_LINK_K, WS_LINK_MEP – domyślnie zamknięte w szablonie.
• WS_TŁA_DWG – linki DWG wyłączone z drukowania i zestawień.

Praktyczny sens: szybsze otwieranie i czysta dokumentacja bez przypadkowych teł.

Krok 3: nazewnictwo plików i paczki publikacyjne

• Schemat: ORG-PROJ-DYS-Model-P01-S1.rvt (organizacja–projekt–dyscyplina–rodzaj–rewizja–status).
• Zdefiniuj „Publish Sets” dla NWC/IFC: SET_Koordynacja, SET_Wymiana_IFC_PB.

Przykład: eksportujesz „SET_Koordynacja” i wiesz, że wszystkie widoki mają ten sam template i wyłączone rodziny tymczasowe.

Krok 4: kontrola kolizji – widoki i presety

• Widoki „QA_Kolizje_A_vs_MEP” z włączonymi tylko kategoriami do testu.
• Preset NWC: Convert element properties = On, Coordinates = Shared, Divide File into Levels = Off (stabilność ID).

Co sprawdzić po tej sekcji

• Czy linki domyślnie ładują się na Shared Coordinates i trafiają do odpowiednich worksetów?
• Czy istnieją gotowe „Publish Sets” do NWC/IFC i opis w READ_ME jak ich używać?
• Czy DWG są zawsze linkowane (nie importowane) i wyłączone z druku?

6. Automatyzacja startu: skrypty, które oddają godzinę pierwszego dnia

Krok 1: panel startowy

Dodaj do szablonu arkusz „00_SETUP – Panel” z przyciskami/odnośnikami (pyRevit/Dynamo) do najczęstszych akcji.

• Ustaw Info Projektu – nazwa, etap, kod projektu.
• Utwórz poziomy i osie z CSV – precyzja bez ręcznego klikania.

Krok 2: wypełnianie i porządkowanie parametrów

• Skrypt „Set_Faza_Dyscyplina” – ustawia wartości domyślne dla nowych elementów.
• Skrypt „Rename_Views” – porządkuje nazwy wg wzorca: DYS_Etap_Typ_Poziom_Skala.

Przykład: po wczytaniu rodzin, jednym kliknięciem dopisujesz PJT_Kod_klasyfikacji wg katalogu bazowego.

Krok 3: szybkie zlecenie publikacji

• Batch eksport NWC/IFC z nazwą pliku wg reguły i docelową lokalizacją (szablon ścieżek).
• Generowanie arkuszy z Excela: numer, tytuł, skala, przypięty widok.

Ostrzeżenie: przypnij wersje skryptów do wersji oprogramowania. Zmieniona wersja Revita = test regresji przed wdrożeniem.

Co sprawdzić po tej sekcji

• Czy panel startowy ma min. 3 działania: info projektu, osie/poziomy, publikacja?
• Czy skrypty nie nadpisują istniejących wartości bez potwierdzenia?
• Czy nazwy plików po eksporcie spełniają firmowy schemat?

7. Nazewnictwo, kody i rewizje: konsekwencja od dnia 1

Krok 1: wzorzec nazw widoków i poziomów

• Poziomy: L01_Parter, L02_Piętro_1.
• Widoki: A_PB_Rzut_L01_1-100, K_PW_Prz_L02_1-50.
• Scope boxy: SB_Strefa_A, SB_Pion_1.

Praktyczny sens: jeden filtr i sortowanie alfabetyczne ogarnia setki widoków.

Krok 2: kody rodzin i typów

• Rodzina: A-DOOR-DW; typ: DW-090x210_EI30.
• Materiały: MAT_Beton_C25/30, MAT_Placeholder (bez assetów wizualnych domyślnie).

Ostrzeżenie: nie mieszaj separatorów. Ustal „_” dla opisów i „-” dla hierarchii.

Krok 3: rewizje i statusy publikacji

• Rewizje: sekwencja numeryczna dla wewnętrznych (01, 02), alfanumeryczna dla zewnętrznych (A, B, C).
• Statusy zgodne z ISO 19650: S0_WIP, S1_Shared, S3_Review, S4_Accepted.

Przykład: arkusz z rewizją „02 S1” jednoznacznie mówi, że to wersja do koordynacji, nie do budowy.

Co sprawdzić po tej sekcji

• Czy nazwy widoków generują się wg jednego wzorca i zawierają dyscyplinę, etap, poziom i skalę?
• Czy kody typów drzwi/okien przenoszą się do zestawień bez ręcznej korekty?
• Czy status publikacji jest widoczny na tytułbloku i w metadanych pliku?

8. Wydajność i higiena pliku: lekki szablon to szybki start

Krok 1: minimalny zestaw stylów i materiałów

• Lineweights/LinePatterns – tylko niezbędne; duplikaty usuń.
• Materiały bez ciężkich tekstur wstępnie; appearance assets dodawaj dopiero na PW.

Efekt: otwieranie szablonu w sekundy, nie w minuty.

Krok 2: zero importów na stałe

• DWG zawsze jako Link do WS_TŁA_DWG, wyłączony w arkuszach.
• Zakaz „Explode” DWG – zamiast tego trace/oversketch w dedykowanym widoku roboczym.

Krok 3: ostrzeżenia i detektory błędów

• Widok „QA – Ostrzeżenia” z filtrem na elementy: Nieprawidłowe ograniczenia, Zduplikowane typy.
• Zestawienie „ZT_Uwagi_Modelu” – liczy ostrzeżenia per kategoria, czerwona flaga > 0.

Krok 4: procedura „Purge & Audit”

• Skrypt „Purge_Soft” – usuwa nieużywane typy „GEN_” i materiały tymczasowe.
• Checklist przed publikacją: Purge, Kompaktuj, Sprawdź rozmiar pliku.

Krótki przykład: redukcja z 220 MB do 140 MB bez utraty treści – wyłącznie porządkami.

Co sprawdzić po tej sekcji

• Czy w szablonie nie ma importowanych DWG i nieużywanych materiałów?
• Czy istnieje widok i zestawienie do monitorowania ostrzeżeń?
• Czy masz gotowy skrypt lub procedurę „Purge_Soft” przed publikacją?

9. Arkusze i wydruki: przewidywalne PDF od pierwszego dnia

Krok 1: tytułblok z metadanymi projektowymi

• Pola: Projekt, Kod_Projektu, Status (ISO 19650), Rewizja, Data, Autor, Sprawdzający.
• Elementy warunkowe: znacznik „PRELIMINARY – NOT FOR CONSTRUCTION” automatycznie włącza się dla S0/S1/S3.

Przykład: zmieniasz Status na S1_Shared w „Informacjach o projekcie” i wszystkie tytułbloki aktualizują stempel bez edycji arkuszy.

Krok 2: szablony widoków pod druk

• Template „PRINT_1-100_A”, „PRINT_1-50_K”, „PRINT_Detale” – spójne grubości linii, style wymiarów, filtry branżowe.
• Reguła: na arkusz trafiają tylko widoki z przypisanym template „PRINT_*”.

Praktyczny sens: brak losowych nadpisań i identyczny wygląd dokumentacji niezależnie od autora.

Krok 3: zestawy drukowania i nazewnictwo plików

• Print Sety: PDF_PB, PDF_PW, DWG_Eksport – gotowe do batch druku.
• Reguła nazwy pliku: ORG-PROJ-DYS-Etap-Rew-Arkusz.pdf (automatyzuj w skrypcie).

Przykład: „ACME-1234-A-PB-A02-AR-201_Rzut_1-100.pdf” – plik sortuje się poprawnie w chmurze i CDE.

Krok 4: kontrola grafiki i czcionek

• Jedna rodzina czcionek (np. Noto Sans) – bez lokalnych zamienników.
• Lineweights/Patterns dopięte do skal druku, test próbny: A3 i A1.

Co sprawdzić po tej sekcji

• Czy wszystkie arkusze korzystają z jednego tytułbloku i czy status ISO zmienia stempel?
• Czy każdy widok na arkuszu ma przypisany szablon „PRINT_*”?
• Czy wydruki z „PDF_PB” trafiają do folderu i z nazwą zgodną ze schematem?

10. Zestawienia i dane: gotowe do kosztorysu i kontroli

Krok 1: „Master” zestawienia branżowe

• ZS_Drzwi_PB, ZS_Ściany_A, ZS_Belki_K, ZS_Instalacje_MEP – z polami: Kod_klasyfikacji, Typ, Ilość, Jednostka.
• Ukryte kolumny techniczne: GUID, Faza, Workset do QA.

Krok 2: Key Schedules do standaryzacji

• KS_Wykończenia_Pomieszczeń, KS_Klasy_Ogniowe – wprowadzają spójne wartości słownikowe.
• Efekt: brak literówek w zestawieniach i poprawne grupowanie.

Krok 3: filtry QA w zestawieniach

• QA_Elementy_bez_Kodu, QA_Typy_bez_Producenta – widoczne tylko w folderze „QA”.
• Kolor ostrzeżenia ustawiony przez warunkowe formatowanie (jeśli narzędzie wspiera).

Krok 4: wymiana z Excelem

• Predefiniowane mapowania kolumn: Typ → Type Name, Kod_klasyfikacji → Classification.Code, Ilość → Qty.
• Skrypt eksport/import pilnuje separatorów i formatu liczb (kropka vs przecinek).

Przykład: kosztorysant importuje „ZS_Drzwi_PB.csv” i bez ręcznych poprawek łączy po Kod_klasyfikacji.

Co sprawdzić po tej sekcji

• Czy każde główne zestawienie ma ustandaryzowane nazwy kolumn i jednostki?
• Czy istnieją zestawienia QA wychwytujące puste kody i statusy?
• Czy eksport do CSV/Excel zachowuje kodowanie i separatory zgodne z firmowym szablonem?

11. IFC i klasyfikacje: eksport, który przechodzi weryfikację

Krok 1: presety eksportu IFC

• Profile: IFC4_DesignTransfer, IFC2x3_Coordination – zapisane w szablonie.
• Ustawienia: Base Quantities = On, Property Sets = Custom + Default, Phases → Construction Status.

Krok 2: mapowanie klasyfikacji

• Pole Kod_klasyfikacji mapowane do: IfcClassificationReference (np. Uniclass/OmniClass/Uniformat/CCS).
• Prefiks systemu w osobnym parametrze: Klasyfikacja_System = „Uniclass2015”.

Krok 3: minimalny zestaw PSetów informacyjnych

• Pset_ManufacturerTypeInformation: ModelReference, ArticleNumber (może być puste na PB).
• Pset_Asset: SerialNumber – uzupełniany dopiero na etapie wykonawczym.

Krok 4: test „kostki kontrolnej”

• Rodzina testowa „QA_IFC_Cube” z wypełnionymi parametrami – eksport/ponowny import sprawdza mapowanie.
• Reguła: dopóki cube nie przechodzi walidacji w narzędziu odbiorcy, nie publikujesz modelu.

Przykład: odbiorca wymaga Uniclass – po eksporcie w przeglądarce IFC widzisz „Pr_30_59_72” przy drzwiach, nie „n/a”.

Co sprawdzić po tej sekcji

• Czy presety IFC są zapisane i opisane w READ_ME?
• Czy Kod_klasyfikacji i Klasyfikacja_System poprawnie lądują w Psetach?
• Czy „QA_IFC_Cube” przechodzi test roundtrip w docelowym narzędziu?

12. Utrzymanie szablonu: wersje, dystrybucja, kontrola zmian

Krok 1: wersjonowanie semantyczne

• Nadawaj wersje: v1.4.2 (major.minor.patch) + data w „Informacjach o projekcie”.
• Changelog w pliku CHANGELOG.md w repo – co zmieniono i dlaczego.

Krok 2: centralny magazyn i prawa dostępu

• Szablon w repo tylko do odczytu dla zespołów, zapisy lokalne zablokowane.
• Dystrybucja przez narzędzie IT (np. aktualizacja przy starcie) – brak „lokalnych kopii v1_final_final”.

Krok 3: testy dymne po aktualizacji

• Otwarcie, utworzenie poziomów, eksport PDF/IFC, publikacja NWC – maksimum 10 minut testu.
• Jeśli któryś test odpada, blokujesz wydanie i wracasz do patch.

Krok 4: pętla informacji zwrotnej

• Formularz „Request_Szablon” – propozycje zmian w jednym kanale.
• Limit: 1 release/miesiąc – mniej chaosu na projektach rozpoczętych.

Co sprawdzić po tej sekcji

• Czy wersja szablonu jest widoczna na arkuszu i w metadanych?
• Czy każdy wie, skąd pobrać aktualną wersję i jak zgłosić zmianę?
• Czy test dymny jest spisany i wykonywany przed publikacją?

13. Warianty branżowe: ile szablonów naprawdę potrzebujesz

Krok 1: trzon wspólny + lekkie odchyłki

• 1 szablon bazowy + 3 paczki różnic: A_AddOn, K_AddOn, MEP_AddOn.
• Różnice: kategorie, filtry, zestawienia, skróty klawiaturowe – rdzeń identyczny.

Krok 2: skale i detale

• Paczka „Detale_PW” ładowana tylko, gdy wchodzisz w PW; PB zostaje lekki.
• Osobne „PRINT_*” dla 1:200/1:100/1:50 – brak ręcznego mieszania grubości linii.

Krok 3: lokalizacja i język

• Słowniki parametrów: PL/EN w dwóch plikach wspólnych GUID – zmieniasz wyłącznie etykiety.
• Eksporty IFC z mapą językową PSetów (jeśli wymagane przez zamawiającego).

Co sprawdzić po tej sekcji

• Czy rdzeń szablonu jest jeden, a różnice branżowe są ładowane jako AddOn zamiast forka pliku?
• Czy paczki detali i biblioteki wysokiej rozdzielczości są opcjonalne i nie dociążają PB?
• Czy masz dwa słowniki językowe z tymi samymi GUID, tak aby przełączenie etykiet nie psuło mapowań?

14. Start projektu w 15 minut: procedura od zera do pierwszego arkusza

Żeby skrócić rozruch, trzymaj się niezmiennego scenariusza. Poniżej gotowy przebieg, który możesz wpleść do onboardingu zespołu.

Krok 1: utwórz projekt z właściwej wersji szablonu

• Nowy plik z „_BIM_Template_vX.Y.Z” – nie z „ostatnio używane”.
• Sprawdź wersję na tytułbloku i w „Informacjach o projekcie” – musi odpowiadać ogłoszonej w repo.

Krok 2: uzupełnij metadane projektu

• Pola obowiązkowe: Projekt, Kod_Projektu, Klient, Status ISO, Faza_aktywna.
• Wpisz Klasyfikacja_System (np. „Uniclass2015”) i prefiks organizacji (np. „ACME”).

Krok 3: załaduj pakiet branżowy

• Z kreatora wybierz: A_AddOn, K_AddOn lub MEP_AddOn – ładuje filtry, zestawienia i style.
• Nie ładuj wszystkich paczek naraz. Rdzeń + jeden AddOn na plik roboczy; kolejne branże w osobnych modelach i jako linki – inaczej rośnie waga i chaos w filtrach.
• Po imporcie AddOn sprawdź foldery „QA_*” i „PRINT_*” – muszą pojawić się w przeglądarce projektu bez duplikatów.

Krok 4: poziomy, osie i siatki

• Utwórz poziomy według wzoru: L00_Part, L01_Part… i przypisz im Strefę/Segment jeśli projekt jest dzielony.
• Siatki: reguła nazewnictwa „A–Z” w jednym kierunku, „1–99” w drugim – bez liter „I/O” (pomyłki na budowie).
• Od razu przypisz szablony widoków do rzutów kondygnacji: „WIP_1-100_A” lub branżowe odpowiedniki.

Krok 5: linki i układ współrzędnych

• Załaduj: geodezję, siatkę konstrukcyjną, modele partnerów – jako Link, nie „Import”.
• Ustaw układ współrzędnych: Shared Coordinates z pliku referencyjnego (geodezja). Zablokuj przypadkowe przesunięcia (pin linków).
• Szablon powinien mieć widok „QA_Coordinates” – sprawdź zera: Project Base Point, Survey Point, kierunek północy.

Krok 6: współdzielenie i worksety

• Włącz Worksharing. Aktywuj predefiniowane worksety: WKS_Arch_Model, WKS_Opis, WKS_Link_K, WKS_Link_MEP, WKS_QA.
• Reguła: linki trafiają tylko do swoich worksetów; model chwilowy/testowy – do WKS_QA (łatwo wyłączyć).