BIM blokuje rozwój cyfryzacji budownictwa

Rafał Bałdys Rembowski: Zacznijmy od początku. Jak zapytasz dowolnego dużego wykonawcę, czy zna technologię BIM, to odpowie: „Tak, robimy BIM. Jesteśmy najlepsi w Polsce”. W rzeczywistości często nie rozumieją istoty tej technologii. Tymczasem BIM – nie tylko w Polsce – nie spełnił pokładanych w nim nadziei – wiele firm budowlanych boleśnie przekonało się o tym na własnej skórze.

Artem Boiko: Żeby to zrozumieć, musimy się cofnąć do początków. Co ciekawe, BIM nie wywodzi się z budownictwa, lecz z przemysłu produkcyjnego. W latach 80. w sektorze produkcji funkcjonował system zwany BOM (Bill of Materials – zestawienie materiałów), który łączył dane projektowe CAD z systemami biznesowymi – planowaniem przedsiębiorstwa i zarządzaniem obiektami (systemy ERP). Pionierem był tu produkt Pro Engineer, który później stał się fundamentem dla Revita. Kiedy w 2003 roku Autodesk przejął Revit’a, po prostu zaadaptował to rozwiązanie z przemysłu produkcyjnego dla branży budowlanej i przemianował je na BIM (Building Information Modelling). Podstawowa idea pozostała ta sama – chodziło o połączenie danych projektowych z systemami biznesowymi – zmieniła się tylko nazwa i podejście marketingowe. Dlatego przed 2002 rokiem nie znajdziemy przykładów zastosowania BIM’u bo ta koncepcja funkcjonowała po prostu pod inną nazwą. Jest tu jednak kluczowa różnica: o ile przemysł produkcyjny rozwinął systemy otwarte, gdzie dane można było swobodnie wymieniać pomiędzy różnymi programami, o tyle branża budowlana utknęła z zamkniętymi, własnościowymi bazami danych. Dziś, mimo dostępu do zaawansowanych narzędzi jak Revit czy ArchiCAD, ich zamknięta struktura uniemożliwia nam swobodne łączenie danych, co jest standardem w innych branżach. W efekcie ciągle na nowo wymyślamy rozwiązania, które gdzie indziej funkcjonują od dekad.

Rafał Bałdys Rembowski: Warto tu zwrócić uwagę na jedną rzecz – ani w Polsce, ani w Niemczech nie mamy nawyku przykładania takiej wagi do baz danych i samych danych w tym procesie. Wielu osobom BIM kojarzy się wyłącznie z trójwymiarową wizualizacją planowanej konstrukcji. Jak ty postrzegasz kwestię modelowania informacji?

Artem Boiko: W budownictwie i planowaniu kluczowe są obliczenia – przede wszystkim kosztów i czasu. Każdy klient, czy to fundusz private equity, bank czy indywidualny inwestor, potrzebuje szybkiej kalkulacji budżetu i harmonogramu projektu. To główny powód, dla którego tworzymy setki czy nawet tysiące różnych modeli.

Na podstawie konkretnych przypadków określamy wymagania i parametry, które wprowadzamy do programu CAD, tam tworzymy geometrię, by wygenerować nowe parametry – głównie objętość i ilość elementów.

Co ciekawe, do samych obliczeń geometria nie jest potrzebna. Zazwyczaj wystarczą pomiary objętości i ilości dla grup elementów. Problem w tym, że nie możemy automatycznie wyliczyć parametrów objętości bez geometrii. Programy CAD wykorzystują do tego tak zwane jądra geometryczne – miliony linii kodu, które przekształcają geometrię parametryczną zdefiniowaną przez punkty w konkretne wartości objętości, które dopiero potem możemy wykorzystać w obliczeniach.

Rafał Bałdys Rembowski: Dotykamy tu kluczowej kwestii. Mało kto zdaje sobie sprawę, że ta warstwa informacyjna ma znacznie większą wartość dla inwestora i przyszłości projektu niż sama geometria czy poziom szczegółowości modelu. Z tego, co mówisz, wynika, że geometria nie jest tu wcale niezbędna.

Artem Boiko: Proces zaczyna się od zbierania wymagań w formie parametrów – początkowo to tylko notatki lub listy, najczęściej w Excelu. Dziś duże firmy automatyzują projektowanie, używając narzędzi do programowania parametrycznego, takich jak Dynamo czy Grasshopper. Potrafią wygenerować całe projekty w CAD, opierając się na jedynie 10-20 parametrach. Typowy scenariusz wygląda tak: przedstawiciel handlowy spotyka się z klientem, zbiera informacje o projekcie i zapisuje je w arkuszu Excel. Stamtąd możemy automatycznie przenieść dane do programu CAD lub BIM. I to pojawia się problem, bo w tym momencie de-facto tracisz nad nimi kontrolę. Gdy przekładasz te parametry na logikę CAD, program dodaje nowe informacje o geometrii i objętości. W tym momencie tracisz dostęp do pierwotnych danych, a cała koncepcja – od wstępnych założeń po wymagania klienta – zostaje uwięziona w zamkniętym, własnościowym formacie.

Rafał Bałdys Rembowski: To rodzi poważny dylemat dla wykonawców i biur projektowych. Inwestujesz w konkretną technologię, uczysz się zarządzać bazami danych – może to system Autodesk, CADworks albo SolidWorks. Wyobraźmy sobie firmę z Francji pracującą w SolidWorks, która nagle dostaje zlecenie od klienta wymagającego wszystkiego w Revicie. To nie jest teoretyczny scenariusz – to się dzieje nagminnie, prawda? Jak firmy mają podejmować decyzje o inwestycji w konkretną technologię, skoro w każdym przypadku tracą dostęp do własnych danych?

Artem Boiko: Oczywiście, rynek oferuje różne produkty. Sytuacja przypomina trochę erę dominacji Photoshopa, który przez 20 lat nie miał konkurencji – podobnie jak dziś Revit. Teraz mamy GIMP jako alternatywę open-source, analogicznie do OpenBIM. Jest Blender BIM i inne produkty OpenBIM, ale tak naprawdę nie potrzebujemy dwóch czy czterech rozwiązań – potrzebujemy tysięcy, jak w świecie 2D. Powiem wprost: dostęp do wielu narzędzi współpracujących z otwartymi formatami plików jest bezcenny, bo daje swobodę dostosowania do konkretnych potrzeb. Tego zamknięte formaty i własnościowe rozwiązania nigdy nie zapewnią.

Rafał Bałdys Rembowski: Czyli w praktyce mamy do czynienia z wieloma formatami własnościowymi. Każdy wymaga dedykowanego narzędzia do edycji, tak? I nie ma możliwości bezpośredniego przeniesienia projektu z SolidWorks do Revita?

Artem Boiko: Technicznie jest to możliwe, ale tylko dla dużych firm, które stać na zainwestowanie setek tysięcy dolarów w narzędzia do inżynierii wstecznej. Dla małych i średnich firm jak nasza to po prostu zbyt kosztowne i pracochłonne. Potrzebujemy uniwersalnego formatu wymiany danych. Na razie mamy tylko IFC, ale nawet on jest uzależniony od jądra geometrycznego.

Rafał Bałdys Rembowski: Historia IFC jest fascynująca. Z twoich artykułów i wypowiedzi wyłania się ciekawy zwrot akcji. Format, który miał być otwarty i tworzony przez społeczność, w praktyce okazał się projektem sterowanym przez Revit czy Autodesk, zgadza się?

Artem Boiko: Cztery lata temu opublikowałem artykuł o historii BIM-u. Potem skontaktowali się ze mną branżowi specjaliści z ciekawym komentarzem: „Jesteśmy związani umowami NDA z dostawcami. Sami nie możemy opowiedzieć prawdziwej historii IFC, ale ty możesz”. Wiemy na pewno, że IFC powstał na Uniwersytecie Technicznym w Monachium. Jeden z tamtejszych specjalistów podróżował z Leonardem Obermayerem[1] po świecie i w 1994 roku zarejestrował format IFC w Bostonie. Opowiedział mi, jak Patrick MacLeamy[2], ówczesny prezes HOK, nawiązał kontakt z Obermayerem i sprowadził tę technologię do Ameryki, by ostatecznie zarejestrować format IFC pod szyldem Autodesku. Moja subiektywna ocena jest taka, że po prostu zawiązano kartel. Powstała nowa organizacja IAI[3], która miała opracować reguły klasyfikacji dla formatu IFC wywodzącego się z formatu STEP – później przekształciła się ona w buildingSMART.

Rafał Bałdys Rembowski: IFC wydaje się formatem z poprzedniej epoki technologicznej. Możesz wyjaśnić jego strukturę i dlaczego jest tak kłopotliwy w stosowaniu?

Artem Boiko: IFC to rzeczywiście relikt wcześniejszej ery komputerowej. Ma dwie główne części: meta informacje zapisane w znacznikach EXPRESS oraz część geometryczną. Historia meta informacji w znacznikach EXPRESS sięga kart perforowanych z końca lat 70. Jednak szczególnie ciekawa jest część geometryczna, która wymaga tak zwanego jądra geometrycznego. O ile meta informacje z pliku IFC można otworzyć w zwykłym edytorze tekstu, o tyle dane geometryczne są opisane parametrycznie – elementy takie jak ściany czy okna są definiowane przez punkty, linie i wektory, co wymaga zaawansowanych obliczeń matematycznych.

Ta złożoność wynika z tego, że dla branży budowlanej postanowiono użyć tych samych jąder geometrycznych, co dla branży CAD w mechanice.  W inżynierii mechanicznej mamy do czynienia z niezwykle złożonymi wyzwaniami geometrycznymi wymagającymi precyzji, stąd te masywne jądra, a mówimy o dziesiątkach milionów linii kodu. Dla porównania, OpenCascade, jedyne dostępne jądro geometryczne open-source, ma 20 milionów linii kodu – to astronomiczna ilość nawet jak na złożone systemy. Ironia polega na tym, że w budownictwie rzadko potrzebujemy takiego poziomu złożoności i precyzji. W około 90% przypadków wystarcza nam geometria na poziomie LOD 200 lub nawet LOD 100 – nie potrzebujemy precyzyjnego odwzorowania spawów czy gwintów śrub. A jednak pracujemy na narzędziach zdolnych obsłużyć geometrię aż do LOD 1000. To jak używanie Photoshopa do zadań, z którymi świetnie poradzi sobie Canva – instalujesz i opłacasz gigantyczny system z setkami funkcji, podczas gdy potrzebujesz zaledwie kilku podstawowych narzędzi do tworzenia prostych formatów.

Rafał Bałdys Rembowski: To wszystko brzmi skrajnie nieefektywnie, to musi mieć realny wpływ na potrzebną moc obliczeniową i oczywiście wiąże się z niepotrzebnie wysoką emisją.  Dlaczego wciąż tkwimy w tym systemie?

Artem Boiko: Niestety, znajdujemy się teraz całkowicie pod kontrolą dostawców CAD. Szczególnie niepokojące jest to, że wprowadzając format IFC i buildingSMART, nie mieli oni szczerej intencji stworzenia otwartego formatu wymiany danych. Rzeczywistość wygląda tak, że pracując z dostawcami jak Adobe czy Autodesk, masz dostęp tylko do części swoich danych – może 80% przez API – i jesteś zmuszony używać ich produktu do jakiegokolwiek eksportu. Gdybyśmy mieli prawdziwie otwarte narzędzia, pozwalające na dostęp do danych bez tych własnościowych systemów, bylibyśmy w zupełnie innym miejscu – podobnie jak dziś łatwo tworzymy i udostępniamy grafiki. Ale bazy danych CAD i format IFC nigdy nie były naprawdę otwarte – i nigdy nie miały takie być. To jeden z głównych powodów, dla których BIM nie spełnił pokładanych w nim nadziei.

Rafał Bałdys Rembowski: Jaka jest więc największa słabość IFC?

Artem Boiko: Sytuacja jest bardziej skomplikowana niż większość osób przypuszcza. Ewangeliści BIM promują IFC jako uniwersalne rozwiązanie, pomijając fundamentalny problem: każda implementacja IFC opiera się na jądrach geometrycznych – złożonych silnikach matematycznych niezbędnych do obsługi geometrii parametrycznej. Bez tych jąder po prostu nie da się przetworzyć danych geometrycznych.

Co więcej, te jądra były rozwijane przez różne zespoły w różnych krajach, z których każdy stosował własne podejście matematyczne. Nie można po prostu połączyć tych różnych formatów parametrycznych – są ze sobą fundamentalnie niekompatybilne. To tworzy ciekawy paradoks: nawet gdyby firmy chciały uczynić swoje formaty naprawdę otwartymi, nie rozwiązałoby to problemu, bo podstawowa architektura jest zbyt złożona i pofragmentowana, żeby dało się niej korzystać.

Podam konkretny przykład z historii Autodesku. Przez 20 lat firma nie była w stanie opracować własnego modułu eksportu z Revita do IFC i musiała zlecić to jednej z europejskich firm. Historia jest fascynująca: Revit został pierwotnie stworzony przez Leonida Raiza z Sankt Petersburga. Równolegle inny zespół z tego miasta pracował od 1998 roku nad złamaniem formatu DWG poprzez inżynierię wsteczną. Ten zespół dołączył do sojuszu OpenDWG-ODA, któremu Autodesk mocno się sprzeciwiał, obawiając się o bezpieczeństwo swojego głównego formatu. Wypracowane rozwiązanie łamiące forma DWG zostało zintegrowane z Revitem na początku lat 2000., ponieważ autorzy tych rozwiązań znali się i współpracowali ze sobą. Gdy Autodesk przejął Revit w 2002 roku, nie wiedział o obecności tego „złamanego kodu” w samym produkcie. Dopiero po dwóch wersjach odkryli, że mają „wrogi produkt” wbudowany w swoje oprogramowanie i w 2004 roku przeszli na oficjalny RealDWG SDK.

Jednak największa ironia jest taka, że w 2017 roku Autodesk musiał wrócić do tych samych programistów, by stworzyć moduł eksportu do IFC. Czyli nawet sam Autodesk nie potrafił rozgryźć, jak prawidłowo eksportować dane do formatu IFC, który według Wikipedii sami stworzyli.

Rafał Bałdys Rembowski: Patrząc na te fundamentalne problemy, jak widzisz przyszłość IFC?

Artem Boiko: IFC przetrwa, ale nie dlatego, że jest najlepszym rozwiązaniem. Jego przetrwanie gwarantuje wsparcie głównych dostawców CAD, firm konsultingowych i w coraz większym stopniu, rządów. Niepokojące jest to, że dostawcy CAD-BIM i konsultanci, występując w roli doradców rządowych, promują OpenBIM i formaty IFC, przemilczając złożoność jąder geometrycznych i narzędzi wymaganych w tle. Podstawowy problem polega na tym, że kurczowo trzymamy się przestarzałych rozwiązań inżynieryjnych. Spójrzmy, jak ewoluowała edycja obrazów – nie potrzebujemy już złożonych formatów jak GIMP czy PSD, a doskonała kompatybilność między nimi nie jest kluczowa. Nasza branża potrzebuje czegoś na wzór JPEG lub PNG – prostych, wydajnych formatów, które rzeczywiście odpowiadają naszym potrzebom.

Rafał Bałdys Rembowski: I tu na scenę wchodzi NVIDIA z całkowicie nowym pomysłem na sektor budownictwa. NIVIDIA ominęła tradycyjnych dostawców CAD i proponuje nam technologię wprost z przemysłu gier video. Co stoi za tą strategią?

Artem Boiko: To fascynujące, jak wszystko wyewoluowało z sukcesu platform takich jak Unreal Engine i Blender, które operują na geometrii trójkątnej. NVIDIA dostrzegła potencjał wykraczający poza same meta informacje i podstawowe struktury – chcieli zaawansowanych możliwości modelowania 3D bez obciążenia złożonymi jądrami geometrycznymi. Przełomem okazał się format glTF, otwarty standard opracowany przez sojusz obejmujący takich gigantów jak IKEA i Facebook, a pierwotnie stworzony przez Sun Microsystems.

Kluczową innowacją jest przejście z geometrii parametrycznej na siatkę trójkątną. Ta zmiana pozwoliła architektom przenieść się z tradycyjnych narzędzi jak Revit czy ENSCAPE do Unreal Engine, gdzie mogą bezpośrednio pracować nad wizualizacjami, symulacjami i obliczeniami. Potencjał jest ogromny – wystarczy spojrzeć na partnera NVIDIA w Belgii, który tworzy kompletną symulację Singapuru z wszystkimi obiektami w NVIDIA Omniverse. Co więcej, wykracza to daleko poza samą wizualizację – platforma może przetwarzać miliardy siatek trójkątnych i trenować agentów AI do zastosowań budowlanych. Instytut Fraunhofera już wykorzystuje ten system do szkolenia robotów w środowiskach wirtualnych, zanim trafią na rzeczywiste place budowy.

To fundamentalna zmiana w podejściu do danych geometrycznych. Zamiast polegać na złożonych jądrach geometrycznych jak Open CASCADE czy Shape Manager Autodesku, z ich setkami milionów linii kodu, pracujemy na prostych danych siatki trójkątnej. To jak przejście ze złożonego pliku Photoshop PSD do prostego PNG – jest bardziej dostępne, wydajne i praktyczne w rzeczywistych zastosowaniach.

Rafał Bałdys Rembowski: Brzmi rewolucyjnie, ale co z wymaganą mocą obliczeniową? Czy to rzeczywiście jest bardziej wydajne?

Artem Boiko: Tu nie ma prostej odpowiedzi. Choć samo podejście wymaga mniej mocy obliczeniowej, NVIDIA zainwestowała w potężną infrastrukturę z milionami procesorów GPU do obsługi projektów wielkiej skali. Owszem, do symulacji miasta wielkości Singapuru potrzeba tysięcy GPU, ale w dzisiejszych czasach to nie stanowi realnej bariery. Przy mniejszych projektach – pojedynczych budynkach czy konstrukcjach – można spokojnie pracować na Unreal Engine lub podobnych silnikach gier.

Najciekawsze jest to, jak wiąże się to z przyszłością budownictwa. W ciągu następnej dekady zobaczymy place budowy obsługiwane przez roboty zamiast ludzi. Te roboty nie potrzebują geometrii parametrycznej – potrzebują płaskich, ustrukturyzowanych danych z tysięcy, a nawet milionów projektów do efektywnego trenowania modeli AI. I właśnie tutaj podejście NVIDIA naprawdę się wyróżnia.

Rafał Bałdys Rembowski: Jak to wiąże się z inicjatywą standardu USD?

Artem Boiko: Kluczowymi graczami byli tu Apple i NVIDIA, szczególnie ze względu na ich zainteresowanie aplikacjami VR i AR. Choć format glTF był przełomowy, nie spełniał wszystkich potrzeb Apple’a w kontekście tych nowych technologii. I wtedy pojawił się USD, format opracowany przez Pixar Studio. Logika była prosta – skoro format radzi sobie ze złożonymi animacjami filmowymi, poradzi sobie też z modelowaniem placu budowy. To świetny przykład, jak innowacja z jednej branży rewolucjonizuje inną.

Rafał Bałdys Rembowski: Fascynujące, jak nasza branża jest przekształcana przez innowacje z sektora filmowego i gier wideo.

Artem Boiko: Dokładnie. Te branże pokazały nam zupełnie nową drogę. Zamiast złożonych jąder geometrycznych i silników mechanicznych, używają prostych, płaskich struktur danych. To dowodzi, że nie potrzebujemy formatów własnościowych – otwarte standardy jak glTF mogą lepiej służyć naszym potrzebom. Teraz z formatem USD, który można uznać za kolejną ewolucję glTF, powstaje nowy sojusz, obejmujący nawet Autodesk. Ta zmiana dzieje się na naszych oczach. Kiedy firmy zwróciły się do mnie w sprawie konwersji danych z AutoCAD lub IFC do USD, stworzyłem konwerter używając tylko bibliotek Pythona – zajęło mi to trzy godziny. Choć USD to otwarty format obsługujący też geometrię parametryczną jak NURBS, jego prawdziwa siła leży w formatach siatkowych.

Co ciekawe, kraje niemieckojęzyczne były tu pionierami. Główni gracze jak Züblin, Strabag, Hochtief czy Deutsche Bahn używają formatu CPIXML od blisko 20 lat, który jest w 80% podobny do USD. Wybrali go zamiast IFC ze względu na jego ograniczenia jakościowe.

Rafał Bałdys Rembowski: To wygląda na fundamentalną zmianę w sposobie zarządzania danymi budowlanymi. Co to oznacza w szerszej perspektywie?

Artem Boiko: Format USD i inne płaskie formaty naprawdę zmieniają reguły gry. To wykracza daleko poza samo przechowywanie danych geometrycznych – możemy zapisywać informacje o procesach, operacjach, praktycznie każdym aspekcie budownictwa. Obecnie główną przeszkodą nie jest sam format, ale wydobywanie danych z istniejących programów CAD, co wymaga kosztownych narzędzi do inżynierii wstecznej.

Rafał Bałdys Rembowski: Czyli obecna technologia BIM de-facto nas hamuje, zamiast prowadzić do przodu?

Artem Boiko: Dokładnie tak. Otwarte formaty wreszcie dają nam swobodę łączenia dowolnych informacji potrzebnych podczas budowy. Czy chodzi o projekt, czy o wycenę – możesz uzyskać dostęp do danych bez napotykania własnościowych blokad. To eliminuje dwie klasyczne wymówki branży: potrzebę specjalistycznego personelu i drogie licencje. W miarę rozpowszechniania się otwartych formatów, zobaczymy wysyp nowych rozwiązań. Prawdziwym wyzwaniem będzie gotowość firm do szkolenia pracowników w zakresie tych nowych narzędzi. To stawia tradycyjnych dostawców jak Autodesk czy Trimble w trudnej sytuacji – ich obecny model biznesowy może nie przetrwać tej zmiany.

Przesłanie dla liderów branży jest jasne: odchodzimy od zależności od jąder geometrycznych. Nie potrzebujemy ich do zrozumienia czasu i kosztów. Potrzebujemy dostępu do danych w prostych, ustrukturyzowanych formatach, które można konwertować między USD, glTF, COLLADA, OBJ czy OpenGL. Przechowuj je jak chcesz – w bazie danych, SQL, XML, JSON.

Bastiony zamkniętych formatów się walą, ale to nie stanie się z dnia na dzień. Warto zwrócić uwagę, że nawet Autodesk rozpoznał tą sytuację i stąd ich zaangażowanie w inicjatywę USD.

Rafał Bałdys Rembowski: Istnieje jednak obawa, że dostawcy mogą chcieć próbować skomplikować format USD, by zachować kontrolę przez swoje narzędzia. Teraz Autodesk promuje koncepcję „danych granularnych” – jak to oceniasz?

Artem Boiko: Strategia Autodesku ciekawie ewoluuje. Promują koncepcję „danych granularnych”, odchodząc od systemów plikowych w kierunku tego, co nazywają podejściem analitycznym. To w zasadzie to samo, o czym mówiliśmy jako o danych ustrukturyzowanych, tylko w ich opakowaniu marketingowym. Myślę, że w ciągu kilku lat mogą próbować całkowicie odejść od BIM-u – stał się zbyt skomplikowany, a większość ludzi już nie rozumie, co właściwie oznacza.

Pamiętajmy, BIM miał być zintegrowaną bazą danych do dostępu, modyfikacji i tworzenia projektów. Teraz podobne idee przepakowują pod hasłem danych granularnych. Ale promowany przez nich CDE czyli Common Data Environment to tak naprawdę tylko zaawansowane rozwiązanie chmurowe z przeglądarką modeli – nic przełomowego. Prawdziwy przełom nadchodzi z narzędziami inżynierii wstecznej. Weźmy Revita – używa SQLite jako podstawy. Gdy już to wiesz, możesz ominąć interfejs Revita i uzyskać bezpośredni dostęp do bazy danych. Możesz konwertować własnościowe formaty do SQLite lub Excela w kilka minut, bez dotykania oprogramowania CAD.

Szczególnie ciekawe jest połączenie tych baz danych z AI. Zamiast klikać przez niekończące się menu, po prostu wydajesz instrukcje dla agenta AI: „Oto moje dane” i zlecasz mu analizę przedmiaru. Zysk na wydajności jest ogromny – to, co wymaga 17 kliknięć i 10 minut w Revicie lub setek linii kodu w narzędziach BIM, można zrobić w 20 sekund prostym poleceniem tekstowym z modelem językowym. Nie musisz rozumieć złożonych schematów czy własnościowych formatów – AI po prostu przetwarza twoje dane tabelaryczne.

To przejście od SaaS do bezpośredniego dostępu do danych jest rewolucyjne dla naszej branży. Przechodzimy od złożonych, pełnych klikania interfejsów do prostych, opartych na danych przepływów pracy, które możemy automatyzować i wzbogacać sztuczną inteligencją. Przyszłość nie polega na opanowaniu konkretnego oprogramowania – chodzi o efektywne zarządzanie danymi.

Rafał Bałdys Rembowski: Czyli obserwujemy całkowitą demokratyzację danych budowlanych, przełamując stare bariery zamkniętych formatów?

Artem Boiko: Dokładnie tak. Narzędzia do tej transformacji już są – musimy je tylko wdrożyć. Branża musi przestać gonić za magicznymi rozwiązaniami specyficznymi dla budownictwa i zacząć korzystać z prostych podejść, które od lat sprawdzają się w innych branżach.

[1] Leonard Obermeyer (1924-2011) – niemiecki inżynier, założyciel Obermeyer Planen + Beraten, pionier zastosowania systemów CAD w budownictwie. Jego firma odegrała kluczową rolę w rozwoju standardów wymiany danych w branży budowlanej w latach 90. XX wieku.

[2] Patrick MacLeamy – były CEO HOK (1996-2016), jeden z pionierów i promotorów technologii BIM w architekturze. Twórca „Krzywej MacLeamy’ego” ilustrującej wpływ wczesnych decyzji projektowych na koszty realizacji inwestycji. Odegrał kluczową rolę w rozwoju i standaryzacji formatu IFC jako przewodniczący buildingSMART International (2005-2015).

[3] IAI (International Alliance for Interoperability) – międzynarodowa organizacja założona w 1994 roku w celu rozwoju standardów wymiany danych w budownictwie. W 2005 roku przekształcona w buildingSMART International, organizację odpowiedzialną za rozwój i standaryzację formatu IFC oraz innych otwartych standardów w budownictwie cyfrowym