Pamiętam to, jakby to było wczoraj. Jeden z tych pierwszych dni na projekcie Nowego Szpitala Uniwersyteckiego w Stavanger, kiedy nadal czułem się jak dzieciak przy stole dla dorosłych.
Szef zadzwonił, omówił wyzwania projektowe, a potem wysłał mi długą listę zadań. Większość z nich to była związana z walidacją danych, których, jak to zwykle bywa na dużych projektach, nikt nie miał czasu zrobić, a terminy zbliżały się nieubłaganie.
Otworzyłem Solibri z pewnością kogoś, kto myśli, że walidacja danych to kolejny „checkbox” do odhaczenia. Wciąż żywo pamiętam, jak patrzyłem na 140 modeli IFC i mówiłem do siebie: „No dobra, ile to może zająć?”
Kilka godzin później poznałem odpowiedź.
Piętnaście różnych reguł sprawdzania, które badały tylko pięć właściwości. Reguły nadpisujące się nawzajem, czasami wręcz sobie przeczące. Mnóstwo wykrytych uwag na tym samym elemencie – kompletnie bez sensu.
Czułem się, jakbym chodził po gęstej dżungli. Nie dało się odróżnić, co jest poprawne, a co błędne. A zegar tykał – model miał być sprawdzony do piątku.
Nie byłem wtedy doświadczonym koordynatorem BIM, ale robiłem wszystko, żeby wyglądać profesjonalnie, jednocześnie panikując w środku. Ten pierwszy tydzień nauczył mnie bolesnej prawdy: dobry proces walidacji danych IFC po prostu nie istniał. A na dużych projektach ze sztywnymi wymaganiami ten potrafi być zabójczy.
Dlaczego nasze procesy sprawdzania danych IFC ciągle zawodzą
Bądźmy przez chwilę absolutnie szczerzy. Branża nadal traktuje dane jak coś opcjonalnego. Coś, czym „zajmiemy się później”.
Moje dwie największe frustracje, którymi chcę się z tobą podzielić:
- Tworzenie wymagań danych jest potwornie żmudne – branżowe i krajowe standardy są albo nieistniejące, albo niespójne.
- Proces walidacji danych jest zaniedbany – bardzo mało narzędzi potrafi naprawdę rzetelnie walidować IFC, a jeszcze mniej robi to w sposób prosty.
Podnieś rękę, jeśli coś brzmi znajomo:
- Wymagania żyją w dziesięciu różnych plikach i nikt nie wie, który jest aktualny.
- Projektanci dostarczają modele, które wyglądają poprawnie… dopóki nie zajrzysz do IFC.
- Oprogramowanie walidacyjne krzyczy o błędach, które nie mają sensu.
- Nazwy właściwości zmieniają się w zależności od osoby eksportującej model.
- Dwie osoby czytające to samo wymaganie interpretują je inaczej.
Co jest jeszcze bardziej frustrujące? Każdy próbuje zrobić wszystko jak trzeba. Projektanci, wykonawcy, koordynatorzy. Nawet klient robi, co może.
A jednak pracujemy w systemie, który opiera się na:
- PDF-ach i Excelach pisanych dla ludzi, nie dla komputerów,
- Arkuszach Excel zarządzanych przez trzy różne osoby,
- Wymaganiach, które potrafią się wzajemnie wykluczać,
- Pół-manualnych procesach walidacji, które zjadają godziny tygodniowo.
Im większy projekt, tym gorzej. Każda branża rozumie wymagania inaczej. Pomnóż to przez kilkadziesiąt IFC tygodniowo i otrzymujesz poziom chaosu, którego żaden zestaw reguł nie utrzyma.
Nie brakuje nam wysiłku. Brakuje nam struktury.
Jak to wyglądało w praktyce
1. Tworzenie zestawów reguł walidacji danych
Używam Solibri do walidacji danych. To jedno z niewielu narzędzi, które naprawdę potrafi to robić.
Ale jego biblioteka reguł jest dość uboga. Spędziłem niezliczone godziny dopracowując reguły, próbując osiągnąć dwa cele:
- wiarygodne wyniki,
- zero fałszywych alarmów.
Efekt?
- Mnożenie tych samych błędów na jednym elemencie,
- Uznawanie poprawnych danych za błędne, bo brakuje funkcji w regułach.
Najgorsze? Każda poprawka jednej reguły psuła dwie inne. Jak debugowanie spaghetti-kodu.
2. Ręczna robota przed każdą walidacją
Przed każdym sprawdzeniem modelu musiałem:
- pobrać IFC,
- załadować reguły,
- ustawić filtry,
- zresetować kontekst,
- uruchomić walidację,
- przejrzeć tysiące uwag,
- oddzielić prawdziwe błędy od szumu,
- przygotować prezentację,
- wyeksportować BCF,
- powiadomić branże.
Wiele dało się zautomatyzować, ale i tak często, zanim skończyłem, projektanci zdążyli już wrzucić nowe modele. Czułem się jakbym gonił autobus, którego nigdy nie złapie.
3. Katastrofa kopiuj-wklej z wymaganiami
Nowa faza projektu SUS? Myśleliśmy, że będzie łatwo i użyjemy wymagań z poprzedniej.
Pomyłka.
Dwa tygodnie czyszczenia, audytów, poprawek, synchronizacji i ustaleń. W tym czasie projektanci projektowali dalej – według starych wymagań.
Proces okazał się zbyt kruchy, żeby przetrwać zmianę zespołu.
| Nazwa właściwości | Typ obiektu | Opis | Wymaganie | Format danych | Przykład | Etap projektu | |||
|---|---|---|---|---|---|---|---|---|---|
| Projekt Budowlany | Projekt Wykonawczy | Budowa | Eksploatacja | ||||||
| Name | IfcBuilding | Kod budynku | Musi | [NN] | 81 | X | X | X | X |
| Name | IfcBuildingStorey | Numer piętra | Musi | [NN] | 01 | X | X | X | X |
| IsExternal | Wszystkie ściany, stropy, słupy itd. | Określa, czy obiekt jest zewnętrzny czy wewnętrzny | Musi | True/False | True | X | X | X | X |
| Drop | Kanały, rury | Określa spadek elementu | Może | N.N | 0.2 | X | X | ||
| AirflowMin | Nawiewniki, kanały, regulatory przepływu | Minimalna wartość zaprojektowanego przepływu powietrza | Musi | [NN] l/s | 100 l/s | X | X | X | |
Wycinek wymiagań IFC z tabeli stworzonej jako dokument PDF.
Musi istnieć lepszy sposób
Problemem nigdy nie byli projektanci. Problemem był system.
Potrzebowaliśmy sposobu, żeby:
- wymagania były jasne,
- łatwe do sprawdzenia,
- jednoznaczne,
- możliwe do walidacji przed eksportem IFC,
- przewidywalne w koordynacji.
Potrzebowaliśmy metody, a nie kolejnego PDF-a.
I taka metoda istnieje – ale musisz ją zobaczyć na żywo. Łatwiej jest to pokazać niż opisać w artykule, nawet jakby miał 5000 słów.
Join the Live IFC Masterclass
📅 Wtorek, 25 listopada 2025
🕓 16:00–18:00 CET
💻 Online (darmowa rejestracja)
Zobaczysz na żywo:
- jak działa schema IFC,
- dlaczego niejasne wymagania psują projekty,
- demonstrację uporządkowanego formatu wymagań,
- jak poprawnie eksportować modele IFC,
- jak walidować dane,
- jak komunikować błędy.
Jeśli brzmi to interesująco, dołącz i przynieś ze sobą swój największy ból głowy związany z OpenBIM.
Rozwiążemy go razem.
Jeśli przycisk nie działa, zarejestruj się tutaj.




