Chociaż poniższy tekst nie jest gotowym scenariuszem idealnego dokumentu EIR, stanowi jego charakterystykę i odpowiedź na zasadnicze pytanie: dlaczego pełni on tak istotną rolę w całym procesie projektowym?
Celem każdego procesu projektowego, niezależnie od jego specyfiki, jest sukces. Celem idealnym, do którego powinny dążyć wszystkie strony tego procesu, jest sukces obopólny – taki, by każdy był beneficjentem danej inwestycji. BIM daje nam takie możliwości, jednakże dużo zależy od relacji pomiędzy wszystkimi uczestnikami procesu. Ogromną rolę w całym przedsięwzięciu odgrywa świadomy inwestor. Bazowanie na utartym schemacie: „Poproszę projekt w BIM”, bez określonych warunków brzegowych opisanych przez inwestora, jest prostą drogą do porażki. Z pomocą przychodzi dokument o nazwie Employer’s Information Requirements (EIR), opisany w brytyjskich standardach dotyczących BIM pod sygnaturą PAS_1192_2_2013.
Employer’s Information Requirements (EIR)
Nazwę dokumentu EIR możemy przetłumaczyć na język polski jako „Wymagania Informacyjne Zamawiającego”. Jego odpowiednik, tak samo jak w przypadku BEP (plan realizacji BIM), nie występuje w dokumentach procesu inwestycyjnego stosowanych w naszym kraju. Rozpatrując technologię BIM w kontekście prawa zamówień publicznych, EIR może – a nawet powinien – stać się częścią Specyfikacji Istotnych Warunków Zamówienia (SIWZ). EIR jest częścią dokumentacji przetargowej udostępnianej przez zleceniodawcę w trakcie procesu udzielania zamówienia. Jest bazą, podstawą dalszych działań – dokumentem, w którym inwestor określa swoje wymagania w stosunku do rodzaju informacji, norm oraz procesów, których oczekuje od wykonawcy przy stosowaniu technologii BIM podczas realizacji projektu.
Schemat powiązań został już opisany w innych artykułach, należy natomiast przypomnieć, że odpowiedzią na wymagania zawarte w EIR jest przygotowanie planu realizacji BIM, w skrócie BEP (BIM Execution Plan), w którym zostanie zawarty opis sposobu spełnienia postawionych wymagań.
Plan realizacji BIM (BEP) sporządzany jest w formie Pre_Contract na etapie składania ofert, a następnie – po dokonanym wyborze oferenta – opracowany zostaje plan BEP w formie Post Contract. Przygotowanie obu planów BEP pozostaje po stronie realizującego projekt. BEP w formie Post Contract powinien być wynikiem pracy obu stron, ponieważ doprecyzowuje on sposób realizacji EIR.
Sekcje wymagań dla EIR
W większości przypadków opisane poniżej zagadnienia bezpośrednio odwołują się do brytyjskich dokumentów, dlatego uwzględniając polskie realia, powinno się te zagadnienia traktować jak wytyczne określające wymagania inwestora.
PAS_1192_2_2013 opisuje trzy sekcje wymagań dla EIR, których nazwy możemy przetłumaczyć jako:
- Information management – wymagania dotyczące zarządzania informacją.
- Commercial management – wymagania dotyczące danych realizacyjnych.
- Competence assessment – wymagania dotyczące kompetencji oferentów.
Przyznam szczerze, że powyższa kategoryzacja jest dla mnie dosyć „specyficzna” i mało przejrzysta, zwłaszcza że niektóre opisy wymagań się powtarzają. Moim zdaniem o wiele lepszą i bardziej przyjazną technicznie klasyfikacją jest podział na wymagania związane z zarządzaniem procesem projektowym (Management), kryteria techniczne (Technical) oraz wymagania z zakresu danych pożądanych w związku z realizacją inwestycji (Commercial).
Elementy EIR
Opisane przeze mnie zagadnienia są sugestią co do wymagań, które inwestor powinien zawrzeć w dokumencie EIR. Opracowanie „Wymagań Informacyjnych Zamawiającego” w zależności od potrzeb związanych z rodzajem projektu w technologii BIM może być bardziej lub mniej rozbudowane.
Dokument EIR powinien zawierać:
Część wprowadzającą – skrótowo opisującą cel, któremu służy opracowanie. Precyzuje ona oczekiwania w stosunku do planu realizacji BIM (BEP) przygotowywanego przez oferentów oraz określa listę pojęć użytych w dokumencie.
Wymagania techniczne – Ogólne wymagania odnoszące się do zawartości danych opracowywanych podczas pracy nad projektem.
- Platforma oprogramowania – opis wymagań dotyczących wyboru programów użytych podczas procesów projektowych i koordynacyjnych. Tematyka, która była i jest punktem zapalnym wielu dyskusji w tematyce zamówień publicznych.
Wskazywanie przez zamawiającego konkretnego oprogramowania obarczone jest zawsze ryzykiem protestów i oskarżeń o narzucanie rozwiązań wybranych producentów. Ważną kwestią jest możliwość wymiany danych przy użyciu różnych platform projektowych. Wiąże się to z możliwością zapisu modeli lub modelu w formacie IFC.
W praktyce zdarzają się sytuację, kiedy inwestor może wymagać od potencjalnych wykonawców użycia konkretnego oprogramowania, np. bezpośrednio związanego ze stosowanymi przez niego systemami informatycznymi. W tym przypadku inwestor powinien zachować ostrożność i być świadomym swoich wyborów oraz ich konsekwencji. Chociażby zachowanie aktualności wersji proponowanych formatów, których nowszych wersji nie odczytują niektóre platformy projektowe.
- Skala szczegółowości modelu – w tym miejscu należy zawrzeć wymogi związane z ilością szczegółów geometrycznych i informacji wprowadzanych w miarę wzrostu szczegółowości modelu. Zagadnienia są ogromnie ważne, ponieważ to te wymagania określają, do czego może posłużyć nam model w kolejnych krokach realizacji projektu.
Ze względu na brak jednolitych uzgodnień na polskim rynku w praktyce funkcjonują definicje zarówno z rynku amerykańskiego LOD (level of development – BIM forum), jak i brytyjskiego LOD (level of definition), na który składają się dwie części – level of detail oraz level of information.
Rodzaj i odpowiednie zdefiniowanie własnych wymagań pod kątem modeli BIM, dopasowane do poszczególnych etapów inwestycji, powinny być związane z dużą świadomością inwestora.
Istotną sprawą dla zamawiającego jest nadrzędny cel modelu BIM. Należy określić, czy jest to realizacja modelu zakończona na etapie przetargu z wykorzystaniem BIM-u do przedmiarów, czy model został stworzony do usprawnienia zarządzania lub koordynacji na budowie. Ważnym aspektem jest też świadomość, że skale (LOD) nie odnoszą się do całego modelu, lecz do jego komponentów – w związku z tym ważne jest zrozumiałe zdefiniowanie ogólnych wymagań architektonicznych, konstrukcyjnych i instalacyjnych.
- Format wymiany danych – inwestor definiuje wymagania co do formatu wymiany danych, które otrzymuje od wykonawcy. Tak jak w przypadku definiowania platformy, ze względu na prawo zamówień publicznych, format ten nie powinien być narzucony. Inwestor może się odnieść do tzw. otwartych formatów wymiany informacji, takich jak IFC oraz COBie, które służą do przenoszenia danych związanych z zarządzaniem budynkiem w formie tabeli. Jednocześnie zamawiający może wymagać przekazania plików w formatach natywnych.
- Koordynaty lokalizacji modelu lub modeli – w przypadku pracy w technologii BIM bardzo istotną rolę pełnią koordynaty i tzw. wspólny punkt wstawienia.
Niejednokrotnie okazuje się, że modele rozmijają się wzajemnie ze względu na lokalizację, szczególnie podczas pracy różnych wykonawców.
Taka sytuacja bezpośrednio prowadzi do kosztownych konsekwencji. W przypadku gdy przesunięcie jest wyraźne, możemy świadomie zareagować. Problem pojawia się przy niezbyt widocznym przesunięciu modeli, co w przypadku obiektów skomplikowanych technologicznie może prowadzić do tragicznych w skutkach błędów, np. związanych z otworowaniem w elementach konstrukcyjnych. W przypadkach takich jak rozbudowy istniejących obiektów zamawiający może podać konkretne koordynaty, do których powinni się odnieść oferenci, tworząc swój model BIM.
Określenie wymogów
Istotne jest też określenie wymogów co do jednostek stosowanych podczas prac z modelami BIM.
- Wymagania wobec systemu szkoleń – jeżeli w zakres oferty wchodzi specyficzne oprogramowanie związane z obsługą modelu informacyjnego, takie jak aplikacje do zarządzania nieruchomością lub oprogramowanie do koordynacji, inwestor może zdefiniować swoje potrzeby odnośnie do systemu szkoleń swojego personelu.
Wymagania z zakresu administrowania
Czyli dział, w którym zamawiający definiuje swoje wymagania obejmujące standardy projektów, koordynacji, przeglądów oraz współpracy.
- Standardy – opis wymagań dotyczących podziału modeli, systemu nazewnictwa dokumentów, rysunków oraz modeli, numeracji rewizji w odniesieniu do przeznaczenia. Paragraf, który w zależności od potrzeb inwestora i jego standardów pracy może być rozbudowany, zaczynając od wymaganej struktury folderów (lub propozycji wymagań) aż do kwestii związanych z wielkością opisów na rysunkach.
- Rola i zakres odpowiedzialności uczestników procesu – wymagania, które wykonawca powinien zawrzeć w swoim planie realizacji BIM (BEP), dotyczące wskazania kluczowych osób w zespole projektowym związanych z procesem tworzenia i zarządzania modelem.
Brytyjski PAS 1192-2 posiada odpowiednio opisane poszczególne funkcje, takie jak Information Manager czy Task Team Manager. W odniesieniu do polskiego rynku możemy traktować ten dokument jako wytyczną.
Inwestor może narzucić lub oczekiwać propozycji takiego podziału wraz z podaniem doświadczenia osób pełniących te funkcje lub oczekiwać propozycji takiej struktury ze strony wykonawcy.
- Zarządzanie i bezpieczeństwo danych – opis wymagań lub oczekiwań w zakresie przedstawienia przez wykonawcę struktur informatycznych do przechowywania oraz dystrybuowania danych.
Paragraf pozornie oczywisty, ale inwestor powinien mieć świadomość dotyczącą takich rozwiązań, jak przechowywanie danych w środowiskach chmurowych. Zastosowanie niektórych z tych rozwiązań nie zawsze może spełniać wymagania zamawiającego pod względem bezpieczeństwa danych (obiekty rządowe lub o podwyższonym stopniu ochrony informacji).
- Koordynacja i schematy wykrywania kolizji – wymagania dotyczące wykluczenia i redukcji kolizji projektowych oraz kontroli, jakości w odniesieniu do szczegółowości modeli. Określenie lub doprecyzowanie oczekiwań w obrębie systemu rewizji i numeracji wydań oraz przepływu informacji. Zdefiniowanie schematu rozwiązań poszczególnych kolizji międzybranżowych, a także sprecyzowanie systemu raportowania.
- Współpraca – opis wymagań z zakresu szerzej ujętej współpracy – podział ról i obowiązków, wskazanie konkretnych osób odpowiedzialnych za poszczególne części modelu lub jego fazy. Dodatkowo opis określa oczekiwany czas, etap i sposób dystrybucji danych oraz wymagania odnoszące się do platformy CDE, uściślając, czy oprócz wymiany tradycyjnych form dokumentów elektronicznych dana platforma powinna współpracować z modelami BIM.
- Analizy – wymagania co do zawartości modelu pod kątem analiz, np. energetycznych, harmonogramowania, kosztorysów lub wykorzystania modeli BIM w analizie bezpieczeństwa i higieny pracy.
Wymagania danych realizacyjnych – opis warunków dotyczących celu, które inwestor chce osiągnąć przy pomocy informacji BIM, kompetencji oraz zakresu i treści danych BIM w powiązaniu z odpowiednimi etapami realizacji projektu.
- Punkt dostarczenia danych – dziwnie brzmiąca nazwa, która w strukturach brytyjskich wymagań funkcjonuje jako Data Drops – co można dosłownie przetłumaczyć jako „upuszczanie danych”. Osobiście wolę określenie „Fazy dostarczenia danych”. Data Drops w większości przypadków powiązane są z fazami projektu. Zamawiający powinien określić oczekiwany zbiór danych w odniesieniu do rozwoju modelu BIM, których wymaga na każdym z kluczowych etapów inwestycji. Projekt w technologii BIM, w zależności od aktualnego stadium, powinien umożliwiać pobranie tych danych.
Wymagania względem Data Drops mogą wskazywać na przekazanie danych w formie modeli (IFC), raportów, rysunków oraz dokumentacji w formatach PDF. - Cele – określają możliwe wykorzystanie informacji pozyskanych przez model BIM, dodatkowe wymagania inwestora odnośnie do podziału dla części modelu w zależności od przeznaczenia – prostym przykładem są budynki biurowe i wydzielanie kondygnacji pod kątem aranżacji przestrzeni biurowych, tzw. fit out – cele mogą być sformułowane w sposób ogólny, ale istotne jest, by uszczegółowić tę część w planie realizacji BIM (BEP).
- Zakres kompetencji BIM – inwestor powinien wymagać, by potencjalni wykonawcy przedstawili zakres swojego doświadczenia na etapie sporządzenia planu realizacji BIM. Należy wyszczególnić takie aspekty, jak liczba i ewentualne przykłady sporządzanych planów realizacji BIM (dotyczy to BEP w formie post-contract), wskazanie procedur i ustaleń, (według których oferent sporządza projekty oraz pracuje w technologii BIM), a także podział zasobów personelu wraz ze wskazaniem kluczowych członków zespołu BIM i ich doświadczenia. Gotowe szablony, które mogą posłużyć jako przykład do odpowiedniego sformułowania wymagań, znajdują się na stornie brytyjskiego Construction Project Information Committee – CPIC.
Oprócz opisu tych wymagań inwestor powinien załączyć materiały dodatkowe, takie jak tabela szczegółowości dostarczanego modelu, gdzie potencjalny wykonawca doprecyzuje poziomy szczegółowości elementów modelu w zależności od etapu procesu projektowego. Przedstawione przeze mnie powyżej części EIR są podstawą do sformułowania Planu Realizacji BIM. Nie jest to podział obowiązkowy, a w kontekście całego zakresu ani minimalny, ani maksymalny. Wszystko zawsze będzie zależało od projektu, którego dotyczy, oraz poziomu wiedzy BIM zamawiającego i oferentów. Inwestor, decydując się na projekt w technologii BIM, powinien znać podstawowe pojęcia funkcjonujące w tym środowisku oraz mieć pełną świadomość konsekwencji, które stoją za tymi pojęciami. Polski rynek budowlany, tak szturmowany przez firmy sprzedające oprogramowanie, które pozwala tworzyć modele BIM, nie mając własnych regulacji, w dużej mierze próbuje opierać się na ustaleniach brytyjskich – ale czy to dobrze?
Trudno o jednoznaczna ocenę – zawsze jednak lepiej uczyć się na cudzych doświadczeniach, niż samemu popełniać błędy. Tym, co może dodatkowo irytować, jest brak wspólnego i funkcjonującego tłumaczenia nazwy EIR na język polski. Ale to w natłoku informacji jest już szczegółem. Na etapie wdrożenia BIM ilość elementów, które można zawrzeć w dokumencie EIR, może doprowadzić do zawrotu głowy. Ważne, by wiedzieć, które z nich wybrać i dopasować do swoich potrzeb. Aspekt obopólnej korzyści, o którym pisałem wcześniej, w technologii BIM jest dla mnie bardzo istotny. Uważam, że zasada in = out jest kluczowa przy projektach wspieranych tą technologią. Jeżeli oczekujemy dobrego rezultatu i efektywnej realizacji projektu, to chcielibyśmy, żeby inwestor świadomie dał coś od siebie. Wtedy z pełną świadomością może żądać oczekiwanego rezultatu.
Michał Zając
Michał Zając
Architekt ,BIM Manager. Absolwent wydziału Budownictwa i Architektury Zachodniopomorskiego Uniwersytetu Technologicznego. Praktyk i entuzjasta technologii BIM. Członek Stowarzyszenia BIM dla Polskiego Budownictwa. Konsultant i trener w Fundacji Europejskie Centrum Certyfikacji BIM. Doświadczenie projektowe zdobył podczas pracy nad skomplikowanymi obiektami przemysłowymi i budynkami użyteczności publicznej. Przez ostatnie 10 lat pracuje wyłącznie w oparciu o technologię BIM. Odpowiedzialny za system szkoleń, tworzenie standardów i procedur oraz zarządzanie zespołem BIM.
