O BIMie, ale tak po ludzku. Świat BIMu jest różnorodny, dlatego Multibim

Natknąłeś się na ten artykuł – widzisz BIM i chcesz uciekać? Nie rób tego! Opowiem Ci, jak wygląda BIM, ale bez zbędnych filozofii. Jeśli uznasz, że zmarnowałeś czas, który poświęciłeś na ten tekst – Daj mi znać, obiecuję to zrekompensować!

Od prawie dwudziestu lat z zaciekawieniem przyglądam się działalności buildingSMART International, która pracuje nad rozwojem standardów wymiany informacji. Standardów, czyli takiej ścieżki wymiany informacji, która będzie zrozumiała dla każdego programu i człowieka zaangażowanego w proces budowlany. Świadomość potrzeby stosowania tak zwanych otwartych standardów do dziś nie jest jeszcze powszechna, ale każdy kto już teraz zacznie wdrażać takie rozwiązania – zacznie wygrywać. Zacznie budować przyszłość.

O kiełkowaniu technologii (BIM)

Gdy przeszło 20 lat temu, będąc na pierwszym roku studiów, zetknąłem się z możliwościami parametrycznego projektowania 3D nikt jeszcze nie nazywał tego BIMem. Na odpowiedni program natrafiłem szczęśliwym zbiegiem okoliczności – Archicad, bo o nim mowa, był wówczas bardzo mało popularny – spośród 350 osób studiujących architekturę, tylko kilka używało Archicada – pozostali kreślili w „cadzie”. 

Oceniając wówczas łatwość i szybkość tworzenia projektów w 3D, wyrażałem z przekonaniem opinię, że „za dwa, góra 3 lata, nikt nie będzie rysował na płasko”. Optymizm, który mi towarzyszył pozostał ze mną do dziś, ale doświadczenie każe bardziej realistycznie patrzeć na dynamikę adaptacji nowych technologii. 

Wdrożenie BIM – korzyści, nie konieczność

„Wdrożę technologię BIM, gdy inwestor będzie tego wymagał – inaczej nie ma to dla mnie sensu”. Zetknąłeś się z podobną opinią? A może sami się z nią zgadzacie? 

Miałem okazję i szczęście pracować z bardzo różnorodnymi projektami: od domów jednorodzinnych, poprzez mieszkaniówki różnej skali, centra handlowe, budynki przemysłowe, centra komunikacyjne, biurowce, po zabytkowe kamienice, czy stacje elektroenergetyczne. Bywałem projektantem, ale to nie jedyna funkcja, którą pełniłem. Nasz zespół realizował z zastosowaniem BIM szereg projektów w Polsce, Norwegii, Finlandii, Niemczech i innych krajach Europy. We wszystkich projektach technologia BIM była stosowana, ale w różnym zakresie. Prawie zawsze niektóre zespoły realizowały część procesów metodami i narzędziami „tradycyjnymi”: cad, excel, word…

Żadne moje doświadczenie nigdy nie potwierdziło, aby jakąkolwiek część dokumentacji projektowej warto było rysować w 2D i realizować inaczej niż w technologii BIM. Wielokrotnie obserwowaliśmy, jak czasochłonna i kłopotliwa jest praca z tworzonymi „ręcznie” rysunkami 2D. Jak problematyczne okazują się arkusze kalkulacyjne, które nie są powiązane z projektem czy opisy tworzone bez stosowania auto-tekstów. Dotyczyło to w szczególności zmian projektowych, które w technologii BIM wprowadza się tylko raz – w modelu. 

Czy BIM jest Ci potrzebny?

Wdrożenie technologii BIM ma sens dla każdego projektanta, niezależnie od skali, rodzaju, etapu, czy trybu realizacji projektu. Pozwalam sobie wyrazić tę opinię i rzucić wyzwanie tym, którzy się z nią nie zgadzają, ponieważ jestem przekonany, że projektowanie w technologii BIM zawsze oszczędza czas. Nieraz sporo, nierzadko bardzo dużo, ale zawsze bilans jest pozytywny. Lepsza kontrola nad jakością projektu czy większa przyjemność samego projektowania to wartość dodana.    

Kluczowe są sprawdzone narzędzia działające w technologii BIM

Nie unikam stwierdzenia, że w Multibim wdrażamy najlepsze narzędzia. Ktoś powie: „twierdzisz, że są najlepsze, ponieważ je sprzedajecie”. Ale narzędzi jest olbrzymia ilość, a nasze portfolio to właśnie te a nie inne programy. Dlaczego?  

Ponieważ wiemy, że są najlepsze, ponieważ to sprawdziliśmy. A co to znaczy „najlepsze”? Jakimi kryteriami oceny należy się kierować? Zagadnienie jest bardzo złożone, a próba oceny niezwykle skomplikowana. 

Wybór przez doświadczenie

Uczestnicząc w dziesiątkach projektów realizowanych z zastosowaniem niemalże wszystkich ważniejszych programów obserwowaliśmy, jak sprawdzają się one w praktyce. Analizowaliśmy narzędzia pod względem kompatybilności i interoperacyjności, wartości użytkowych, wydajności. A w reszcie kosztów – nie tylko licencji, ale też koniecznych inwestycji we wdrożenie i szkolenia personelu. Przyglądaliśmy się polityce producentów. Obserwowaliśmy jak podchodzą do swoich klientów i czym się kierują kształtując np. politykę cenową i licencyjną.

Niska cena, drogi koszt

Wybierając oprogramowanie kierujemy się z pewnością bezpośrednimi kosztami zakupu i utrzymania licencji. Tu wskazówka ode mnie: patrzmy długoterminowo. Wieczyste licencje są początkowo droższe, ale po dwóch lub trzech latach zaczynamy na nich oszczędzać. 

Programy, na których pracujemy decydują pośrednio o zysku lub stracie zanotowanych na konkretnych projektach, o krótkoterminowym i długoterminowym wyniku ekonomicznym firmy. 

Narzędzia to konkretne wymagania dotyczące infrastruktury – stacji roboczych i serwerów. Od doboru narzędzi zależy często wybór naszej firmy do realizacji projektu. A co wydaje mi się najważniejsze – płynność i ciągłość pracy, a także zadowolenie lub frustracja zespołu – wartość trudno przeliczalna na pieniądze, ale w istocie bezcenna. 

Klient wymaga plików natywnych – co z tym zrobić?

Kolejna opinia, z którą będę polemizował, dotyczy konieczności stosowania oprogramowania jednej firmy w ramach pracowni. Spotykam się ze stwierdzeniami: „Pracujemy na tym oprogramowaniu, ponieważ wymaga tego od nas inwestor/deweloper”. 

Oczywiście: „klient nasz pan” i jeśli gotowy jest zapłacić za pliki źródłowe (natywne dla danego oprogramowania), stanowiące know-how pracowni – dlaczego nie! Zwracajmy jednak na to uwagę inwestorom i odpowiednio wyceniajmy takie produkty. Warto pamiętać, że wymagania plików natywnych często nie są poprzedzone analizą i są stawiane bez świadomości konsekwencji. W praktyce inwestor zazwyczaj nie potrzebuje plików natywnych a wystarczające, wręcz lepiej dostosowane do potrzeb są opublikowane pliki IFC, PDF, XLS i inne, czyli pliki z zastosowaniem otwartych standardów.

Wybór oprogramowania – mniej ideologii, więcej pragmatyki

Podczas naszego kilkunastoletniego doświadczenia, zdarzało się, że otrzymywaliśmy zamówienie na pliki konkretnego oprogramowania. Nie zawsze plików Archicada. Tworzymy wówczas projekt w odpowiednim narzędziu lub proponujemy dostarczenie pliku w rozszerzeniu dostępnym dla każdego oprogramowania. Nie porzucamy oprogramowania Archicad, bo wg nas jest on zdecydowanie wydajniejszy i tańszy, przez co stał się naszym ulubionym narzędziem.

Pracownie, które motywują fakt stosowania tylko jednego oprogramowania BIM wymaganiami inwestora, częstokroć wykonują niektóre prace projektowe w prostym „cadzie”. Pomimo, że ich programy pochodzą od jednego producenta, różnią się od siebie bardziej, niż Archicad od jakiegokolwiek programu BIM. Czy argument jest zatem trafny?

Wniosek może być jeden – jeśli mamy swobodę wyboru oprogramowania, stosujmy takie, które ma najlepszy stosunek jakości (szeroko rozumianej) do kosztów jakie generuje. Takie oprogramowanie pozwala na osiągnięcie najlepszych rezultatów w najniższej cenie, co przekłada się na wartość biznesową dla naszej pracowni i dla klientów.

Standardy openBIM – wolność, której nie powinniśmy oddawać

Wybór narzędzi powinien być autonomiczną decyzją podyktowaną potrzebami technicznymi i biznesowymi projektantów. W tym duchu pracują specjaliści związani z szeroko rozumianym budownictwem działający wspólnie w ramach buildingSMART. Stworzone przez tę organizację otwarte standardy takie jak IFC służący do transferu modeli, czy BCF służący do komunikacji, dają nam tę swobodę. Jako standardy ISO są one powszechnie stosowane przez podmioty procesów budowlano-inwestycyjnych na całym świecie. Ich popularność rośnie z roku na rok, a już w tej chwili są wymagane w wielu krajach europejskich. 

Nie sposób nie zgodzić się ze stwierdzeniem, że inwestorom powinno zależeć na najlepiej wykonanej pracy projektowej. Fakt, że niektórzy z nich zamykają sobie drogę do współpracy z wieloma projektantami wymagając natywnych formatów oprogramowania, wydaje się trudny do wytłumaczenia. Gdy spotkamy się z takimi wymaganiami, spróbujmy przeanalizować potrzeby inwestora – być może zastosowanie otwartych standardów buildingSMART będzie dla klienta nie tylko wystarczające, ale i korzystniejsze. Będzie na pewno tańsze.