BCF jest tyle wart, ile dyscyplina zamykania uwag. Pokazuję, co jest w pliku uwagi, kto zamyka temat, jakie terminy ustawić i jak policzyć czas zamknięcia na pięciu uwagach z demo.
BCF w projekcie jest tyle wart, ile dyscyplina zamykania uwag. Sam eksport kolizji z Revita albo Navisworks daje plik, który po tygodniu leży w mailu i nikt nie wie, co z niego zostało. Poniżej rozkładam obieg uwagi na cztery pola, statusy, terminy i raport, który da się policzyć.
W koordynacji widzę ten sam wzorzec od lat. Zespół potrafi wyeksportować sto kolizji w kwadrans, a potem zamyka je w rozmowie na spotkaniu, bez śladu w pliku. Wpis jest o tym, co zrobić, żeby plik był jedynym miejscem prawdy.
Plik do pobrania i wszystkie liczby w tym tekście pochodzą z jednego demo: biuro, poziom +2, pięć uwag, eksport z 2026-10-23. Demo zbudowałem sam, więc nic tu nie jest zapisem z cudzego projektu.
Co zawiera plik BCF: viewpoint, komentarz, status, przypisanie
Plik BCF to paczka z jedną uwagą: obraz problemu, komentarz z datą i autorem, status oraz osoba odpowiedzialna. Reszta pól jest dodatkiem, który porządkuje pracę, ale bez tych czterech uwaga nie istnieje.
Viewpoint to nie zrzut ekranu, choć tak się go czasem traktuje. W środku siedzi kamera, kierunek patrzenia, pole widzenia, lista elementów wskazanych i ukrytych oraz płaszczyzny cięcia. Dzięki temu druga osoba otwiera dokładnie ten widok, a nie szuka kolizji w całym modelu. BIMcollab opisuje to zachowanie wprost: podwójne kliknięcie uwagi przenosi do jej widoku w modelu (BIMcollab Help Center, Get started with BCF Manager Revit, dostęp 2026-10-26).
Komentarz jest rozmową z datami. W pliku demo pierwsza uwaga ma cztery wpisy: zgłoszenie, prośbę o dwa dni, informację o nowej wersji modelu i zamknięcie. Każdy z autorem i znacznikiem czasu, więc po miesiącu widać, kto co powiedział.
Status i przypisanie to dwa osobne pola i dlatego łatwo je pomylić. Status mówi, na jakim etapie jest uwaga, a przypisanie, kto ma wykonać następny ruch. Uwaga otwarta i przypisana do architekta nie znaczy, że architekt pracuje: znaczy, że do niego należy decyzja. Nazwy pól w pliku sprawdziłem w schemacie BCF 2.1 z repozytorium buildingSMART: Title, Priority, DueDate, AssignedTo, Status, Comments, Viewpoints (BCF-XML, dostęp 2026-10-26).
Uwaga powstaje tam, gdzie widać kolizję, i wraca tam, gdzie trzeba ją poprawić. Pomiędzy tymi dwoma miejscami jest plik albo platforma, a nie mail z opisem i zrzutem.
W Revicie nie ma eksportu BCF z pudełka, potrzebna jest wtyczka, na przykład BCF Manager z Autodesk App Store (BIMcollab BCF Manager for Revit, dostęp 2026-10-26). W Navisworks Clash Detective eksportuje testy kolizji do plików Navisworks, nie do BCF (Autodesk Knowledge, Export Clash Tests, dostęp 2026-10-26). Do BCF też potrzebna jest wtyczka, co Autodesk opisuje w artykule pomocy o eksporcie danych BCF z Navisworks.
Drugi krok to wybór między plikiem a platformą. Plik wysyłany mailem sprawdza się przy dwóch firmach i jednym modelu. Przy pięciu branżach i cotygodniowej koordynacji lepsza jest lista uwag w BIMcollab albo w CDE, bo tam status żyje na serwerze, a nie w załączniku.
Trzeci krok to powrót do modelu. Poprawka trafia do nowej wersji modelu, a uwaga dostaje komentarz z numerem wersji i czeka na sprawdzenie. Ważna zasada: poprawka nie tworzy nowego tematu, tylko zamyka stary. Inaczej po dwóch miesiącach macie dwa razy więcej uwag niż problemów.
Statusy i terminy: kto zamyka uwagę i kiedy
Uwagę zamyka ten, kto ją zgłosił, a nie ten, kto ją poprawił. To jedno zdanie rozstrzyga większość sporów o to, czy problem został rozwiązany.
W BIMcollab statusy mają kolory, które pomagają w przeglądzie listy. Aktywna uwaga jest czarna, aktywna po terminie czerwona, rozwiązana niebieska, zamknięta szara. Przy workflow akceptacji dochodzą dwie nazwy: rozwiązana do akceptacji i rozwiązana zaakceptowana, przy czym ten wariant nie jest dostępny we wszystkich planach. Kolory i nazwy statusów sprawdziłem w BIMcollab Help Center, Colors of issues based on their status, dostęp 2026-10-26.
Termin jest polem w pliku, nie ustaleniem w mailu. Data w polu terminu daje dwie rzeczy: czerwoną flagę po przekroczeniu i podstawę do raportu. W demo jedna uwaga ma przekroczony termin o 25 godzin, bo poprawka była gotowa dzień po dacie.
| Status w pliku | Co znaczy w zespole | Kto zmienia | Termin reakcji |
|---|---|---|---|
| Open | zgłoszone, trwa ustalanie rozwiązania | autor poprawki | 2 dni robocze na odpowiedź |
| Resolved | poprawka jest w modelu, czeka na sprawdzenie | zgłaszający | 1 dzień roboczy na sprawdzenie |
| Closed | poprawka przyjęta, uwaga zamknięta | zgłaszający, nie autor poprawki | brak, wpis zostaje w historii |
Zamykam uwagę, gdy spełnione są trzy warunki. Poprawka jest w nowej wersji modelu albo dokumentu, status zmienił się na Closed, a komentarz podaje numer wersji i datę. Brak jednego z nich oznacza, że uwaga wraca na najbliższe spotkanie koordynacyjne, nawet jeśli wszyscy wiedzą, że problem jest rozwiązany.
Priorytety: co krytyczne, co może poczekać
Priorytet w pliku BCF jest wolnym tekstem, więc bez własnego słownika każdy wpisze co innego. W schemacie to zwykłe pole tekstowe, bez listy dozwolonych wartości (BCF-XML, dostęp 2026-10-26). Dlatego słownik ustala zespół, a nie program.
Moja skala ma cztery stopnie i każdy ma termin. K1 krytyczny oznacza kolizję, która blokuje prowadzenie trasy albo przejście instalacji przez strefę, i ma dzień na odpowiedź. K2 wysoki to przenikanie w miejscu, gdzie zmiana jednej branży wymusza zmianę drugiej, i ma trzy dni. K3 średni to jakość modelu: duplikaty, brak parametrów, i ma tydzień. K4 niski to uwagi montażowe i estetyka, które czekają do następnej rewizji.
Do K4 zaliczam na przykład brak miejsca na obejmę pod sufitem podwieszanym. To nie kolizja, ale wykonawca musi o tym wiedzieć przed montażem. Wpis w pliku jest tańszy niż telefon w środku montażu.
Priorytet bez terminu jest ozdobą. Jeśli K2 ma trzy dni, to data w polu terminu wynika z priorytetu, a nie z widzimisię zgłaszającego. Wtedy raport pokazuje, ile uwag wysokich przekroczyło termin, i to jest liczba, którą warto pokazywać na spotkaniu.
Raportowanie: uwagi otwarte, czas zamknięcia, powtarzające się problemy
Raport z BCF ma trzy liczby, które coś znaczą. Pierwsza to liczba uwag otwartych według priorytetu, druga to średni czas zamknięcia, trzecia to liczba powtórzeń tego samego problemu.
W pliku demo jest pięć uwag: dwie zamknięte, dwie otwarte i jedna rozwiązana, czekająca na sprawdzenie. Średni czas zamknięcia to 29 godzin i 4 minuty, licząc od zgłoszenia do zamknięcia. Ta średnia kryje dwa różne przypadki: jedna uwaga zamknęła się w 3 godziny 45 minut, druga w 54 godziny 23 minuty. Sama średnia bez rozrzutu nie mówi nic o tym, gdzie leży problem.
Powtórzenia wyłapuję po powiązaniu tematów. W demo jedna uwaga jest powiązana z poprzednią, bo po obniżeniu trasy kanał wrócił w belkę na sąsiedniej osi. To najważniejsza informacja w raporcie: nie chodzi o to, że uwag jest pięć, tylko o to, że ten sam kanał koliduje drugi raz.
Trzecia liczba to uwagi po terminie. Jedna na pięć w demo, czyli dwadzieścia procent, i to przy pięciu uwagach jest anegdotą, nie trendem. Przy pięćdziesięciu uwagach ten sam wskaźnik mówi już, czy zespół ma problem z terminami, czy z priorytetami.
Przykład na demo: jedna kolizja od zgłoszenia do zamknięcia
Uwaga BCF-001 z demo pokazuje cały obieg w dwa dni. Kanał nawiewny 400×200 na rzędnej +3,20 przechodził przez belkę B-12 na osi 4, przenikanie 180 mm. Zgłoszenie poszło z Navisworks 19 października o 6:12, po teście K-04 strop kontra wentylacja.
Tego samego dnia o 14:40 konstruktor poprosił o dwa dni, bo belka była w przeliczeniach. To jest wartość komentarza: zamiast ciszy i ponagleń, w pliku została data i powód. 21 października o 8:05 projektant wentylacji wpisał nową wersję modelu W-12 z obniżoną trasą, a o 12:35 koordynator sprawdził widok i zamknął uwagę.
Obraz powyżej nie jest zrzutem z Revita. To render z kamery, którą plik BCF zapisał w widoku uwagi, wykonany skryptem na geometrii demo. Pokazuje sedno: druga osoba widzi ten sam kadr, bez szukania miejsca kolizji.
Cały plik jest do pobrania razem z tym wpisem: cztery tematy z widokami i piąty bez widoku, trzynaście komentarzy, pięć statusów. Możesz otworzyć go w dowolnym narzędziu czytającym BCF 2.1 i zobaczyć, jak wygląda uwaga, która ma komplet pól. Paczkę ZIP z plikiem dołączyłem do materiałów wpisu jako W14-przyklad-bcf-v1.zip, bo WordPress nie przyjmuje rozszerzenia .bcf.
Checklista wdrożenia BCF w zespole
Wdrożenie BCF to jedno spotkanie i jedna decyzja o tym, kto zamyka uwagi. Reszta to ustalenia, które mieszczą się na jednej stronie.
- Słownik statusów. Zapisz, co znaczą Open, Resolved i Closed w tym projekcie, i kto zmienia każdy z nich.
- Skala priorytetów. Cztery stopnie z terminami, ustalone przed pierwszym eksportem, nie po.
- Właściciel zamknięcia. Ustal, że zamyka zgłaszający, i powiedz to zespołowi na głos.
- Pole przypisania. Wpisuj osobę, nie dział i nie firmę. Uwaga przypisana do działu czeka tydzień.
- Numer wersji w komentarzu. Każda poprawka dostaje numer modelu albo dokumentu, w którym jest.
- Jedno miejsce na statusy. Plik albo platforma, nie jedno i drugie, bo wersje się rozjadą.
- Przegląd listy raz w tygodniu. Piętnaście minut na uwagi po terminie i powtórzenia.
- Jedna uwaga na problem. Powtórzenie oznaczaj jako powiązanie, nie jako nowy temat.
Punkt szósty jest w praktyce najtrudniejszy, bo wygodniej wysłać plik mailem i mieć spokój. Do momentu, w którym trzeba odpowiedzieć, która wersja jest aktualna.
Kiedy to nie zadziała
BCF nie naprawi obiegu, którego nie ma. Trzy przypadki rozpoznasz przed wdrożeniem.
- Zespół bez wspólnego modelu. Jeśli każda branża pracuje na własnym pliku bez koordynacji, BCF daje tylko obrazki bez adresu w modelu.
- Plik wysyłany mailem bez miejsca na statusy. Dwie kopie po dwóch tygodniach rozjeżdżają się, a nikt nie wie, która jest prawdziwa.
- Brak osoby, która zamyka uwagi. Koordynator, który tylko przekazuje pliki, zostawia po miesiącu sto otwartych tematów i zero decyzji.
Do tego dochodzą wersje. Starsze narzędzia czytają BCF 2.1, nowsze obsługują 3.0, która bazuje na 2.1 (BCF-API, dostęp 2026-10-26). Jeśli w zespole są oba, eksportuj w wersji, którą otworzy najstarsze narzędzie.
Źródła
Jak powstał ten materiał: plik BCF zbudowałem skryptem na potrzeby wpisu, na wymyślonym modelu demo (biuro, poziom +2), i sprawdziłem każdy plik XML schematem BCF 2.1 z repozytorium buildingSMART. Nie mam konta w BIMcollab ani w CDE, więc nie ma tu zrzutów z tych narzędzi: rejestracja wymaga potwierdzenia adresu mailowego, a takiego konta nie zakładałem. Rysunki są moje, wykonane skryptem PIL 2026-10-26.
- buildingSMART, BCF-XML, schemat i dokumentacja formatu BCF, wersja 2.1 i 3.0, dostęp 2026-10-26.
- buildingSMART, BCF-API, specyfikacja usługi sieciowej BCF, zależność 3.0 od 2.1, dostęp 2026-10-26.
- BIMcollab Help Center, Colors of issues based on their status, statusy i kolory, aktualizacja 2026-01-22, dostęp 2026-10-26.
- BIMcollab Help Center, Get started with BCF Manager Revit, obieg uwagi w Revicie, aktualizacja 2026-03-03, dostęp 2026-10-26.
- BIMcollab, BCF Managers, wtyczki do Revita 2027 i Navisworks 2026, dostęp 2026-10-26.
- Autodesk App Store, BIMcollab BCF Manager for Autodesk Revit, wtyczka do wymiany BCF w Revicie, dostęp 2026-10-26.
- Autodesk Knowledge Network, Export Clash Tests, eksport testów kolizji w Navisworks, wersja 2026, dostęp 2026-10-26.
- Autodesk Support, Export of .BCF data from Navisworks, wskazanie wtyczki do eksportu BCF. Strona blokuje roboty, treść potwierdzona w indeksie wyszukiwarki 2026-10-26.
- ISO, ISO 19650-2:2018, dostawa informacji o obiekcie, wydanie 2018, dostęp 2026-10-26.
- Wpisy na blogu: ISO 19650 po ludzku, IFC dla MEP, Czym jest platforma CDE, Ranking platform CDE, Szablony spotkania koordynacyjnego, dostęp 2026-10-26.
Plik do pobrania: W14-przyklad-bcf-v1.zip, w środku W14-przyklad-bcf-v1.bcf (BCF 2.1, 5 tematów, 26 kB).
Ujawnienie AI: Treść tego artykułu przygotował agent AI pracujący na mojej instalacji Hermesa, na podstawie mojej praktyki koordynacyjnej i dokumentacji producentów. Plik demo i rysunki wykonały skrypty, a tekst przeszedłem i zaakceptowałem przed publikacją.
