CDE to obieg informacji, nie dysk z plikami: kto zgłasza RFI, kto odpowiada, jakie są statusy i kiedy pytanie się zamyka. Do tego submittals z wersjami, przepływ w trzech narzędziach i checklista wdrożenia na jedno spotkanie.
CDE nie jest dyskiem, na który zespół wrzuca pliki. CDE to obieg informacji: ktoś zgłasza pytanie, ktoś odpowiada, a status mówi, czy odpowiedź już obowiązuje. Poniżej rozkładam ten obieg na RFI i na akceptacje, bez rankingu funkcji i bez cen.
Pytania wykonawcy obsługuję od kilku lat i widzę, że projekty nie różnią się narzędziem, tylko tym, czy ktoś pilnuje statusów. Ten sam Dalux w jednym biurze skraca ustalenia do jednego dnia, a w innym zbiera pytania, których nikt nie zamyka.
Dysk Google i SharePoint przechowują pliki. CDE przechowuje informację razem z jej przeznaczeniem: status mówi, czy rysunek nadaje się do koordynacji, czy już do budowy.
SharePoint nie jest gorszy w przechowywaniu. Microsoft opisuje historię wersji jako sposób na przywrócenie pliku i ślad zmian (Microsoft Learn, dostęp 2026-10-26). Brakuje mu natomiast dwóch rzeczy: słownika statusów i osoby, która zamyka pytanie.
| Co sprawdzasz | Dysk Google albo SharePoint | CDE w rozumieniu ISO 19650 |
|---|---|---|
| Nazwa i numer | dowolne, często z opisem w środku | uzgodniona konwencja, numer i status |
| Wersje | historia zmian pliku | rewizja z numerem P albo C |
| Kto kończy temat | nikt, wątek urywa się w mailu | właściciel procesu, status i data |
| Czego szukasz | plik | odpowiedź na pytanie, z datą i autorem |
Projekt, w którym CDE jest folderem na Dysku, poznaję po nazwach plików. Leżą tam final, final_2 i final_po_uwagach, a nikt nie potrafi powiedzieć, który poszedł do zamawiającego. Nazwa pliku nigdy nie powinna nieść opisu, bo opis zmienia się szybciej niż numer. Czym jest sama platforma CDE, opisałem w wpisie Czym jest platforma CDE (dostęp 2026-10-26).
ISO 19650 w pięciu zdaniach
ISO 19650 opisuje zarządzanie informacją o obiekcie, nie modelowanie. Ustala, kto zamawia informację (EIR), kto ją produkuje (BEP z planami MIDP i TIDP) i kto ją odbiera. Jednostką pracy jest kontener informacji: rysunek, model, zestawienie albo specyfikacja, każdy ze statusem i rewizją. CDE jest w tej normie uzgodnionym źródłem informacji, a nie jednym z kanałów obok maila i komunikatora. Seria ma sześć części: pierwsze dwie opublikowano w grudniu 2018, część szósta w 2025 (ISO 19650-1:2018, ISO 19650-6:2025, dostęp 2026-10-26).
Nazewnictwo plików, statusy i rewizje rozłożyłem na części w wpisie ISO 19650 po ludzku (dostęp 2026-10-26).
Obieg RFI: kto zgłasza, kto odpowiada, kiedy zamykamy
RFI zamyka się wtedy, gdy odpowiedź trafiła do dokumentu albo do modelu. Odpowiedź w mailu, nawet poprawna, zostawia pytanie otwarte, bo nikt nie wie, czy dokument zdążył się zmienić.
Zgłasza ten, kto natrafił na brak w dokumentacji: najczęściej wykonawca albo projektant innej branży. Odpowiada autor dokumentu. Koordynator jest filtrem i sprawdza, czy pytanie jest kompletne, zanim trafi do projektanta. W Dalux każdy wykonawca jest przypisany do work package, a workflow obsługuje pytania dotyczące specyfikacji i rysunków (Dalux HelpCenter, Request for information, dostęp 2026-10-26).
Statusy w narzędziach są krótkie. Dalux prowadzi zadanie przez New, Ongoing, Reported ready, Awaiting approval oraz Approved, closed (Dalux HelpCenter, Task statuses, dostęp 2026-10-26). BIMcollab nazywa je Active, Resolved i Closed, a przy workflow akceptacji dochodzą Resolved, To approve oraz Resolved, Approved (BIMcollab HelpCenter, dostęp 2026-10-26).
Przykład rekordu zamkniętego w jednym dniu wygląda tak. To mój szablon pól, a nie zrzut z narzędzia, więc możesz go przepisać do dowolnego CDE.
| Pole | Wartość w przykładzie RFI-014 |
|---|---|
| Numer | RFI-014 |
| Zgłasza | wykonawca instalacji sanitarnej, 2026-10-26, 08:12 |
| Dotyczy | rysunek wentylacji, poziom 2, kolizja kanału z belką |
| Odpowiada | projektant branży sanitarnej |
| Odpowiedź | kanał obniżony o 150 mm, nowa rewizja C02 rysunku |
| Status po odpowiedzi | Resolved, 2026-10-26, 15:40 |
| Zamknięcie | Closed po podmianie rysunku w CDE, 2026-10-27, 09:05 |
Zamykam RFI, gdy spełnione są trzy warunki. Odpowiedź jest wpięta w dokument albo model, status zmienił się na Closed, a data i autor zostali w historii. Jeśli brakuje jednego z nich, pytanie zostaje otwarte i wraca na najbliższe spotkanie koordynacyjne.
Submittals i akceptacje: kolejność, wersje, historia
Submittal to rekord z kolejnością recenzentów, a nie plik wysłany mailem. Kolejność jest treścią: krok startuje po zamknięciu etapu przed nim, a osoba odpowiedzialna za następny ruch jest widoczna w rekordzie (SubmittalLink Help Center, dostęp 2026-10-26).
Odpowiedź ma nazwę i kilka dozwolonych wartości. Procore podaje domyślnie Approved, Approved as Noted, Revise and Resubmit i Rejected (Procore Help, dostęp 2026-10-26). Approved as Noted nie znaczy „prawie dobrze”, tylko „można produkować, ale uwagi trzeba wprowadzić”.
Wersje rosną, a numer sprawy zostaje ten sam. Pierwsze wydanie to C01, poprawka to C02. Odpowiedzi z wersji C01 zostają przy C01, więc po pół roku widać, kto i kiedy zaakceptował co.
Historia jest tu ważniejsza niż sam plik. Wpis odpowiada na cztery pytania: kto odpowiedział, kiedy, na którą wersję i z jakim komentarzem. Bez tego nie odtworzysz, dlaczego w styczniu zamówiono inną pompę niż w projekcie.
Dalux, BIMcollab i Thinkproject: przepływ, nie cennik
Trzy narzędzia różnią się miejscem, w którym mieszka pytanie. To miejsce decyduje o tym, kto musi wejść do systemu, żeby odpowiedzieć.
| Narzędzie | Gdzie mieszka pytanie | Kto prowadzi status | Co zostaje w historii |
|---|---|---|---|
| Dalux | zadanie typu RFI w module Field, w work package i w workflow | kierownik budowy jako filtr, projektant jako autor odpowiedzi | każde działanie ze znacznikiem czasu |
| BIMcollab | issue powiązany z widokiem i obiektem modelu | zespół koordynacyjny, statusy Active, Resolved, Closed | status, komentarz, widok, przypisanie |
| Thinkproject | rekord w CDE powiązany z dokumentem i komunikacją | właściciel informacji, workflow zgodny z ISO 19650 | ślad audytowy, rewizje, decyzje i akceptacje |
Dalux stawia na zadanie w kontekście budowy. Pytanie dostaje workflow i work package, więc trafia do właściwej osoby bez ręcznego adresowania (Dalux HelpCenter, dostęp 2026-10-26). Wykonawca wybiera typ zadania i nie zastanawia się nad adresatem, co przy dużej liczbie podwykonawców jest główną oszczędnością czasu.
BIMcollab trzyma pytanie przy widoku modelu. Issue jest powiązany z pozycją i obiektem, więc odpowiedź dotyczy konkretnego elementu, a nie całego rysunku (BIMcollab, dostęp 2026-10-26). Ta sama zasada działa w drugą stronę: koordynator widzi w modelu wszystkie otwarte uwagi bez otwierania listy.
Thinkproject idzie ścieżką dokumentu. Rekord jest powiązany z dokumentem, komunikacją i akceptacją, a całość ma być gotowa na audyt (Thinkproject, dostęp 2026-10-26). Ten model pasuje do projektów, w których odpowiedź żyje w specyfikacji i w rysunku, a model jest tylko jednym z załączników.
Wybór sprowadza się do jednego pytania: gdzie ląduje odpowiedź. Jeśli w modelu, wygrywa narzędzie modelowe. Jeśli w rysunku i specyfikacji, wygrywa CDE dokumentowe. Zestawienie funkcji jest w wpisie Ranking platform CDE (dostęp 2026-10-26).
Pięć błędów wdrożenia
- Brak słownika statusów. Zespół używa statusów z narzędzia, ale nikt nie napisał, co znaczy A1 w tym projekcie.
- Uprawnienia skopiowane z dysku. Każdy widzi wszystko, więc nikt nie odpowiada za nic.
- RFI bez właściciela odpowiedzi. Pytanie trafia do kolejki zespołu, a nie do osoby, i czeka tydzień.
- Brak zasady zamykania. Rekord zostaje w stanie „odpowiedziano”, bo nikt nie sprawdził, czy dokument się zmienił.
- Migracja historii na koniec. Stare wersje wchodzą po miesiącu, bez statusów, i od tego dnia nikt nie ufa nowemu systemowi.
Pierwszy i czwarty błąd mają jedno źródło: brak słownika statusów. Statusy i rewizje rozłożyłem osobno w wpisie ISO 19650 po ludzku (dostęp 2026-10-26).
Checklista wdrożenia na jedno spotkanie
Spotkanie trwa 90 minut i kończy się decyzjami, nie prezentacją. Potrzebujesz trzech rzeczy: listy uczestników z rolami, słownika statusów i jednego otwartego RFI jako próbki.
- Role, 10 minut. Ustal, kto zgłasza, kto odpowiada, kto zamyka.
- Słownik statusów, 15 minut. Przepisz statusy z aneksu krajowego i przypisz je do stanów w narzędziu.
- Jeden RFI, 20 minut. Przeprowadź prawdziwe pytanie przez cały obieg, na ekranie.
- Zasada zamknięcia, 10 minut. Zapisz trzy warunki z sekcji o RFI jako regułę projektu.
- Submittals, 15 minut. Wybierz pięć typów dokumentów, które przechodzą akceptację, i kolejność recenzentów.
- Uprawnienia, 10 minut. Trzy grupy: autor, koordynator, odbiorca.
- Terminy, 5 minut. Ustal, ile dni ma odpowiedź i co się dzieje po przekroczeniu.
- Następne spotkanie, 5 minut. Data przeglądu po dwóch tygodniach i jedna osoba odpowiedzialna.
Agenda spotkania koordynacyjnego i rejestr decyzji są w wpisie Szablony spotkania koordynacyjnego (dostęp 2026-10-26).
Kiedy to nie zadziała
Trzy przypadki, w których obieg z tego wpisu nic nie da, warto rozpoznać przed wdrożeniem.
- Projekt bez wymogu informacyjnego. Jeśli zamawiający nie opisał EIR, statusy nie mają podstawy umownej i pierwszy spór kończy się powrotem do maila.
- Podwykonawca bez dostępu do CDE. Jeśli pracuje wyłącznie na PDF-ach z maila, obieg zatrzymuje się na granicy jego skrzynki, choćby po Twojej stronie wszystko działało.
- Biuro z jednym modelem i jednym odbiorcą. Narzut na role, statusy i terminy bywa większy niż zysk, więc wystarczy nazwa pliku i wersja.
EIR i statusy to elementy serii ISO 19650, więc projekt bez nich nie ma podstawy, żeby wymagać ich od podwykonawcy (ISO 19650-1:2018, dostęp 2026-10-26).
Źródła
Jak powstał ten materiał: obieg opisałem z własnej praktyki i z dokumentacji producentów, bez uruchomienia demo CDE, bo każde z trzech narzędzi wymaga konta z weryfikacją mailową. Rekord RFI-014 jest przykładem wzorcowym, a nie zapisem z systemu. Nie testowałem workflow akceptacji w BIMcollab, bo dostęp do niego zależy od planu, o czym mówi dokumentacja.
Wszystkie adresy sprawdzone 2026-10-26 w przeglądarce i przez REST API bloga.
- ISO, ISO 19650-1:2018, pojęcia i zasady, wydanie z grudnia 2018, potwierdzone w 2024.
- ISO, ISO 19650-6:2025, informacja o bezpieczeństwie i higienie pracy, wydanie z 2025.
- Dalux HelpCenter, Request for information (RFI), praca z work package i workflow.
- Dalux HelpCenter, Task statuses, lista statusów zadania: New, Ongoing, Reported ready, Awaiting approval, Approved closed.
- Dalux HelpCenter, Inbox as a subcontractor, skrzynka podwykonawcy grupowana według statusów zadań.
- BIMcollab HelpCenter, Colors of issues based on their status, statusy Active, Resolved, Closed i workflow akceptacji.
- BIMcollab, Issue management, powiązanie issue z pozycją i obiektem modelu.
- Thinkproject, NextGen CDE, rekordy dokumentów, RFI i ślad audytowy.
- SubmittalLink Help Center, Submittal review workflow and ball in court, kolejność kroków recenzji.
- Procore Help, Manage custom submittal responses, domyślne odpowiedzi na submittal.
- Microsoft Learn, About version history, historia wersji w SharePoint i OneDrive.
- UK BIM Framework, ukbimframework.org, wytyczne do wdrożenia zarządzania informacją.
Rysunek w tekście jest mój: `Grafiki/w12-diagram-stany-informacji-v1.png`, wykonany skryptem PIL 2026-10-26. Nie ma w nim zrzutów z CDE, bo każde demo wymaga konta z weryfikacją mailową, a takiego konta nie zakładałem.
Sprawdź również:
- Jak utrzymać model 3D w Revicie w dobrej kondycji?
- BCF w projekcie: od kolizji do zamknięcia uwagi
- IFC dla MEP: eksport z Revita bez bólu
- CDE w praktyce: RFI, submittals i akceptacje
- ISO 19650 po ludzku: nazewnictwo, statusy i metadane
Ujawnienie AI: Treść tego artykułu przygotował agent AI pracujący na mojej instalacji Hermesa, na podstawie mojej praktyki, dokumentacji producentów i norm. Rysunek wykonał skrypt, a tekst przeszedłem i zaakceptowałem przed publikacją.
