Czym jest BIM Execution Plan w kontekście zamówień publicznych
Instrukcja „jak pracujemy w BIM”, a nie tylko formalny załącznik
BIM Execution Plan (BEP) w inwestycjach publicznych pełni przede wszystkim funkcję instrukcji organizacyjno‑technicznej. To uzgodniony przez strony opis tego, jak konkretny zespół będzie realizował wymagania BIM na danym kontrakcie: kto co robi, w jakim narzędziu, w jakim formacie, kiedy, w jakiej strukturze folderów i według jakich standardów. Dobrze przygotowany BEP jest punktem odniesienia przy każdym sporze o zakres, jakość modelu lub terminy dostarczenia informacji.
W sektorze publicznym BEP bywa traktowany jak formalny załącznik „do odhaczenia”, ale w praktyce to on decyduje, czy proces wymiany informacji BIM będzie spójny. Jeżeli w BEP nie ma konkretnych zasad, ludzie wracają do pracy „po staremu”: modele są aktualizowane różnie, pliki krążą po mailach, a przy odbiorach nikt nie potrafi ustalić, skąd biorą się rozbieżności.
Kluczowa cecha dobrego BIM Execution Plan w inwestycjach publicznych to jednoznaczność. Każdy uczestnik projektu powinien móc odpowiedzieć na pytania: „co dokładnie mam dostarczyć?”, „w jakim momencie?”, „według jakich parametrów?”. Jeżeli po lekturze BEP da się formułować sprzeczne interpretacje, dokument nie spełnia swojej funkcji, nawet jeśli formalnie „istnieje”.
Pre‑contract BEP vs post‑contract BEP – dwa różne narzędzia
W praktyce funkcjonują dwa główne typy BIM Execution Plan:
pre‑contract BEP – przygotowywany na etapie oferty, jako element odpowiedzi na wymagania zamawiającego,
post‑contract BEP – rozwinięty dokument roboczy tworzony i uzgadniany po podpisaniu umowy.
Pre‑contract BEP służy przede wszystkim do pokazania, że wykonawca rozumie wymagania EIR/OPZ i ma realny plan ich zrealizowania. Tu nie ma jeszcze szczegółowych harmonogramów modelowania, ale powinna się znaleźć koncepcja organizacji informacji, wybór kluczowych narzędzi, wstępny opis ról i odpowiedzialności, a także ogólna strategia koordynacji międzybranżowej. W zamówieniach publicznych ten dokument często jest oceniany w kryteriach pozacenowych – deklaracje w nim złożone stają się później punktem odniesienia dla zamawiającego.
Post‑contract BEP to już narzędzie operacyjne. Wypracowuje się go zwykle w pierwszych tygodniach po podpisaniu umowy, często w kilku rundach uzgodnień z zamawiającym. Tu muszą się pojawić konkretne tabele LOD/LOI, dokładny opis cyklu publikacji modeli, zasady nazewnictwa plików, workflow w CDE, sposób raportowania kolizji, strukturę kodów klasyfikacyjnych i inne ustalenia, które realnie będą wpływały na codzienną pracę. W projektach publicznych post‑contract BEP bywa też aktualizowany w trakcie trwania kontraktu – istotne, by sposób tych aktualizacji był jasno opisany.
BEP a EIR/OPZ – co, jeśli wymagania są niejasne lub ich brak
BEP jest zawsze wtórny wobec wymagań zamawiającego: EIR (Employer’s Information Requirements) i/lub OPZ powinny określać co ma zostać dostarczone, a BIM Execution Plan – jak to zostanie wykonane. W polskiej praktyce pojawiają się trzy typowe scenariusze:
opis wymagań jest rozbudowany i spójny – BEP głównie uszczegóławia i porządkuje zasady,
wymagania są fragmentaryczne, często sprzeczne – BEP pełni funkcję „naprostowania” i uzupełnienia,
brak realnego EIR, w OPZ pojawia się jedynie hasło „projekt w technologii BIM” – BEP staje się głównym dokumentem porządkującym całe podejście do informacji.
W dwóch ostatnich przypadkach BIM Execution Plan w inwestycjach publicznych musi zawierać minimalny zestaw uzgodnień, bez którego projekt informacyjnie się rozsypie. Chodzi m.in. o zdefiniowanie: zakresu modelowania, poziomów szczegółowości, ról BIM, struktury środowiska CDE, formatu wymiany danych, częstotliwości koordynacji i zasad akceptacji modeli. Zamawiający nie zawsze jest przygotowany, by sformułować to samodzielnie – BEP jest więc szansą, by urealnić i uporządkować wymagania, a przy okazji zabezpieczyć interes wykonawcy.
BEP jako załącznik do umowy kontra dokument roboczy
W projektach publicznych BIM Execution Plan może mieć dwojaką rangę formalną:
załącznik do umowy – staje się wtedy dokumentem kontraktowym, naruszenie jego postanowień może skutkować roszczeniami,
dokument roboczy zatwierdzony przez zamawiającego – nie jest wprost częścią umowy, ale pozostaje punktem odniesienia przy odbiorach.
W pierwszym wariancie każda zmiana w BEP wymaga zwykle formalnej ścieżki zatwierdzeń (aneks, protokół uzgodnień, pisemna zgoda). Zaletą jest większa ochrona obu stron: zamawiający może jasno egzekwować deklarowany poziom szczegółowości i zakres danych, a wykonawca ma mocny argument, gdy żąda się od niego informacji niewynikających z BEP. Wadą jest utrudniona elastyczność – trudniej reagować na nieprzewidziane okoliczności.
W drugim wariancie BIM Execution Plan ma charakter bardziej operacyjny, łatwiej go aktualizować, ale ryzykiem jest mniejsza przewidywalność wymagań. Jeśli zamawiający przy odbiorze zacznie oczekiwać informacji, których nie było w BEP, spór o to, „co obejmowała cena”, staje się trudniejszy. Rozsądny kompromis to model, w którym kluczowe elementy BEP (zakres, LOD/LOI, wymagane formaty, kluczowe daty informacyjne) są załącznikiem do umowy, a szczegóły techniczne i procedury operacyjne – wersjonowanym dokumentem roboczym.
Ramy prawne i standardy odniesienia dla BEP w sektorze publicznym
PZP i opis przedmiotu zamówienia a wymagania BIM
W polskim systemie prawnym Prawo zamówień publicznych przesądza, że opis przedmiotu zamówienia musi być jednoznaczny i wyczerpujący. Jeśli w OPZ pojawia się wymóg projektowania lub realizacji z wykorzystaniem BIM, to parametry tego wymogu stają się elementem kontraktu. Tu właśnie wchodzi BIM Execution Plan w inwestycjach publicznych: konkretyzuje, jak te wymagania będą wykonane.
W praktyce najczęściej spotykane opcje to:
w OPZ opisane są tylko cele: „prowadzenie projektu w technologii BIM, zapewnienie modelu powykonawczego” – BEP musi przełożyć te ogólne hasła na konkretne procedury,
OPZ zawiera odwołanie do EIR lub wytycznych BIM zamawiającego – BEP musi być z nimi spójny i wypełnić luki,
zamawiający w OPZ narzuca szczegółowe formaty, poziomy szczegółowości, strukturę klas, a nawet nazwy folderów – BEP opisuje jedynie sposób dochowania tych wymagań po stronie wykonawcy.
W każdym z tych wariantów brak spójnego BEP zwiększa ryzyko sporów o zakres i jakość dostarczanych danych. Z prawnego punktu widzenia to właśnie w BIM Execution Plan najłatwiej udokumentować, że wykonawca zorganizował proces informacyjny z należytą starannością – ważne zwłaszcza w sytuacjach, gdy pojawiają się opóźnienia lub błędy wynikające z niespójnych danych po stronie zamawiającego.
Normy, standardy i wytyczne – jak z nich korzystać z głową
Najczęściej przywoływanym zestawem norm odnoszących się do zarządzania informacją w BIM jest seria PN‑EN ISO 19650. W praktyce wiele zamówień publicznych odwołuje się do niej wprost, często dość ogólnie („projekt należy prowadzić zgodnie z normą ISO 19650”). Problem w tym, że norma opisuje ramy procesowe, a nie konkretny, gotowy szablon BEP.
Traktowanie ISO 19650 jak „instrukcji obsługi” prowadzi do dwóch typowych uproszczeń:
powstają BEP‑y, które są kompilacją fragmentów normy, ale nie przekładają się na realną organizację pracy,
ignorowane są lokalne uwarunkowania prawne, w tym specyfika PZP, polskich wytycznych branżowych i zwyczajów projektowych.
Praktyczne podejście wygląda inaczej: normy traktuje się jako punkt odniesienia, a BIM Execution Plan w inwestycjach publicznych buduje się wokół realnych potrzeb kontraktu. Często równie istotne jak ISO 19650 są wewnętrzne standardy zamawiających, np. wytyczne GDDKiA, standardy miejskie, instrukcje dużych spółek infrastrukturalnych. W BEP trzeba jasno zaznaczyć, które standardy są obowiązujące i w jakiej kolejności są stosowane w razie sprzeczności.
Co jest „twardym” wymaganiem, a co doprecyzowuje się w BEP
W zamówieniach publicznych istotne jest rozróżnienie między tym, co musi być określone w dokumentacji przetargowej, a tym, co może zostać doprecyzowane w BIM Execution Plan. Z grubsza można to ująć tak:
„twarde” wymagania – przedmiot zamówienia (np. obowiązek dostarczenia modeli branżowych, zakres dokumentacji, wymóg modelu powykonawczego, określone formaty danych przekazywanych zamawiającemu),
ustalenia doprecyzowywane w BEP – organizacja procesu (harmonogram publikacji modeli, szczegółowa struktura CDE, narzędzia, role BIM, sposób raportowania kolizji, szczegółowe workflow uzgodnień).
Jeżeli BEP zaczyna rozszerzać „twarde” wymagania, np. zwiększa poziom szczegółowości modeli ponad to, co wynika z OPZ, w praktyce oznacza to nieformalną zmianę zakresu zamówienia. Zamawiający często nie widzi w tym problemu, dopóki nie pojawią się roszczenia finansowe. Dlatego w BIM Execution Plan warto wyraźnie oznaczyć, które zapisy są odtworzeniem wymagań zamawiającego, a które są propozycją wykonawcy (i na ile mają charakter zobowiązania).
Ryzyka kopiowania zagranicznych wzorów BEP
Częsta praktyka to import gotowych szablonów BIM Execution Plan z projektów zagranicznych, głównie brytyjskich, norweskich czy niemieckich. Na pierwszy rzut oka dokument wygląda profesjonalnie: jest obszerny, pełen terminologii, odwołań do standardów i piktogramów workflow. Problem pojawia się, gdy zestawi się go z polską rzeczywistością prawną i kontraktową.
Najczęstsze pułapki takiego kopiowania to:
przeniesienie ról i odpowiedzialności, które w polskich realiach są nierealne (np. bardzo szerokie kompetencje BIM Managera do zmiany zakresu prac),
odwołania do niedostępnych lub nieobowiązujących standardów krajowych, systemów klasyfikacji czy platform CDE,
zapisy sprzeczne z PZP, np. narzucające wykonawcy obowiązki, których nie ma w OPZ, lub wprowadzające procedury sprzeczne z SIWZ.
BIM Execution Plan w inwestycjach publicznych powinien być zlokalizowany – dostosowany do lokalnych przepisów, praktyk i możliwości rynku. Zagraniczny wzór może być inspiracją, ale każdy zapis trzeba przejść krytycznie: czy da się go realnie zastosować tu i teraz, w polskim trybie zamówień publicznych, z tym zamawiającym, tym zespołem i tym zakresem?
Relacja BEP – EIR – OPZ: kto narzuca zasady, a kto je doprecyzowuje
Logika podziału ról: zamawiający wymaga, wykonawca opisuje sposób realizacji
Fundamentalna zasada: zamawiający opisuje „co”, wykonawca opisuje „jak”. EIR (lub odpowiednik w OPZ) powinien określać wymagania informacyjne: jakie modele, w jakich fazach, do jakich celów, z jakimi danymi. BIM Execution Plan ma pokazać, jak zespół wykonawcy zamierza to osiągnąć: jakie przyjmie narzędzia, procedury, strukturę komunikacji i odpowiedzialności.
W idealnym świecie EIR jest spójny, precyzyjny i realny. W polskiej praktyce rzadko jest tak dobrze. Dlatego pierwszym krokiem przygotowania BEP jest gruntowna lektura EIR/OPZ z filtrowaniem wymagań na:
realne i możliwe do spełnienia w założonym budżecie i czasie,
niejasne – wymagające doprecyzowania w pytaniach do zamawiającego lub w BEP,
sprzeczne ze sobą lub niewykonalne technicznie.
Dopiero na tej podstawie sensownie buduje się BIM Execution Plan w inwestycjach publicznych. Próba „wciśnięcia” wszystkiego mechanicznie do BEP, bez weryfikacji realności wymagań, kończy się dokumentem, którego zespół nie jest w stanie realizować.
Jak czytać i interpretować EIR/OPZ pod kątem BEP
Praktyczne podejście do EIR/OPZ obejmuje kilka kroków analizy. Dobrze jest wykonać je jeszcze przed złożeniem oferty, a potem doprecyzować na etapie post‑contract BEP:
Mapa wymagań – zestawienie wszystkich fragmentów OPZ/EIR, które dotykają BIM, modeli, danych, formatów, raportowania. Wygodnie jest zrobić to w formie tabeli (wymaganie – źródło – komentarz).
Macierz odpowiedzialności – przypisanie każdemu wymaganiu konkretnej roli po stronie wykonawcy (autor, weryfikator, osoba zatwierdzająca) oraz wskazanie, po której stronie leży decyzja biznesowa (zamawiający vs. wykonawca).
Identyfikacja kolizji wymagań – spisanie miejsc, w których EIR, OPZ, PFU, projekt umowy i normy BIM mówią coś innego. To właśnie te punkty powinny zostać omówione z zamawiającym przed zatwierdzeniem BEP.
Ocena wpływu na koszty i harmonogram – przypisanie wymaganiom szacowanego wpływu na nakład pracy (np. poziom szczegółowości modelu, gęstość przeglądów koordynacyjnych). Bez tego dyskusja o zmianie wymagań BIM jest czysto teoretyczna.
Dopiero po takiej „obróbce” EIR/OPZ da się odpowiedzialnie zaprojektować proces w BEP. W przeciwnym razie dokument staje się zbiorem pobożnych życzeń, których nikt nie jest w stanie realnie monitorować. Widać to szczególnie przy dużych zamówieniach infrastrukturalnych, gdzie część wymagań BIM została przeniesiona z innych projektów bez refleksji, czy rynek jest w stanie je dowieźć w danym budżecie.
W praktyce przydaje się proste rozróżnienie na wymagania „krytyczne” i „warunkowe”. Te pierwsze muszą zostać spełnione bez względu na okoliczności (np. formaty przekazania modelu powykonawczego). Te drugie da się negocjować lub etapować (np. poziom szczegółowości informacji eksploatacyjnych). BEP jest dobrym miejscem, aby taki podział nazwać wprost i zaproponować kolejność wdrażania wymogów, zamiast udawać, że wszystko będzie gotowe od pierwszego dnia.
Największy błąd to mechaniczne przepisywanie do BEP ogólnych sformułowań z EIR/OPZ, bez przełożenia ich na procedury. Jeśli zamawiający żąda „cotygodniowej koordynacji międzybranżowej”, BEP powinien odpowiedzieć: kto inicjuje sesję, w jakim narzędziu, jaką metodą oznaczane są kolizje, jak dystrybuowane są raporty, kto i w jakim czasie odpowiada na zadania. Bez takich konkretów BIM Execution Plan w inwestycjach publicznych jest trudny do egzekwowania i staje się wyłącznie „papierową” protezą zgodności z normami.
Dobrze przygotowany BEP nie gwarantuje sukcesu kontraktu, ale znacząco ogranicza pole interpretacji i rozmycia odpowiedzialności. Im wcześniej zostanie potraktowany jako narzędzie zarządzania ryzykiem – a nie tylko załącznik „do odhaczenia” – tym większa szansa, że technologia BIM przełoży się na realną kontrolę informacji, a nie tylko na kolejną warstwę dokumentów w teczce zamówienia publicznego.
Źródło: Pexels | Autor: ThisIsEngineering
Minimalna treść BIM Execution Plan w inwestycjach publicznych
Zakres kontraktu i powiązanie z innymi dokumentami
Na początku BEP powinien jasno określać, czego dotyczy i do czego jest „podpięty”. W praktyce chodzi o kilka prostych, ale kluczowych elementów:
identyfikacja kontraktu (nazwa zadania, numer postępowania, strony umowy, data),
lista dokumentów nadrzędnych wobec BEP (OPZ/PFU, EIR, projekt umowy, aneksy, standardy zamawiającego),
informacja, które dokumenty są priorytetowe w razie sprzeczności (np. kontrakt > OPZ > EIR > BEP > standardy wewnętrzne).
Bez takiego „adnotowania” BEP bywa traktowany jako równoważny z OPZ, co rodzi spory: czy wykonawca ma obowiązek realizować zapisy BEP wykraczające poza przedmiot umowy. Zwykle odpowiedź powinna wynikać wprost z tego rozdziału.
Zakres modeli i produktów informacyjnych
Kluczowy fragment BEP w inwestycjach publicznych to opis tego, co ma powstać w wymiarze informacyjnym. Nie chodzi tylko o modele, ale też o raporty, zestawienia i pliki pośrednie. Najczęściej stosuje się tabelaryczne ujęcie:
lista modeli branżowych (architektura, konstrukcja, instalacje, drogowy, mostowy, sanitarny itp.),
model koordynacyjny – kto go tworzy, z czego i w jakiej częstotliwości,
produkty końcowe: modele powykonawcze, zbiory danych eksploatacyjnych, paczki przekazywane do systemu zamawiającego.
W praktyce przydaje się macierz: produkt informacyjny – autor – odbiorca – format – moment dostarczenia. Dzięki temu widać, czy np. model branżowy ma być formalnym produktem kontraktowym, czy tylko narzędziem wewnętrznym wykonawcy, z którego wynikają rysunki.
Poziom szczegółowości modeli i informacji
Jednym z najbardziej konfliktogennych obszarów jest poziom szczegółowości modeli. BEP powinien go opisać w sposób maksymalnie konkretny, unikając wyłącznie „etykiet” typu LOD 300/350 bez rozwinięcia. W praktyce działa to lepiej, gdy:
poziom szczegółowości odnosi się do konkretnych kategorií obiektów (np. słupy, belki, armatura, znaki drogowe), a nie do całej branży,
różnicuje się geometrię i atrybuty – co jest odwzorowane przestrzennie, a co tylko opisowo,
wiąże się poziom z fazą projektu: inaczej przy koncepcji, inaczej przy PFU, jeszcze inaczej przy dokumentacji wykonawczej czy modelu powykonawczym.
Sztywny zapis typu „wszystkie elementy w modelu wykonawczym w LOD 400” w zamówieniach publicznych zwykle kończy się roszczeniami. BEP może tu pełnić rolę „reduktora” – realnie opisać, jaki poziom jest możliwy w zadanym budżecie i gdzie potrzebne są kompromisy.
Standardy nazewnictwa, struktury i klasyfikacji
BIM Execution Plan w inwestycjach publicznych bez części standaryzacyjnej szybko staje się zbiorem indywidualnych przyzwyczajeń. Minimalny zestaw obejmuje:
strukturę plików – jak nazywane są pliki modeli, na jakiej zasadzie rozdziela się branże, odcinki, fazy (np. kod zamówienia–branża–odcinek–faza–wersja),
strukturę modeli – podział na poziomy, strefy, sekcje, obiekty cząstkowe (przejścia, wiadukty, budynki),
nazewnictwo widoków, zestawień, arkuszy w plikach natywnych (szczególnie, jeśli zamawiający oczekuje ich przekazania),
system klasyfikacji – czy używany jest lokalny standard (np. klasyfikacja obiektów drogowych zamawiającego), czy dedykowana struktura przygotowana na potrzeby kontraktu.
Dużym błędem jest kopiowanie z zagranicznych BEP referencji do systemów typu Uniclass czy CoClass bez sprawdzenia, czy zamawiający ma jakiekolwiek narzędzie, aby te klasy wykorzystać. Czasem lepszym rozwiązaniem jest prostsza, ale konsekwentna klasyfikacja dostosowana do OPZ i sposobu rozliczania robót.
Organizacja zespołu BIM i podział odpowiedzialności
Role BIM a role kontraktowe
Standard ISO 19650 wprowadza nazwy ról BIM, ale w zamówieniach publicznych trzeba je zderzyć z realnymi rolami kontraktowymi. BEP powinien precyzować, gdzie dana funkcja jest:
osobnym stanowiskiem (np. dedykowany BIM Manager po stronie lidera konsorcjum),
funkcją pełnioną „po godzinach” przez inną rolę (np. projektant branżowy będący jednocześnie Model Coordinator),
wspólną rolą dla kilku kontraktów (częste w mniejszych firmach).
Trzeba też jasno rozgraniczyć kompetencje: BIM Manager w BEP nie może dostać uprawnień do zmiany zakresu projektu czy kosztów, jeśli w kontrakcie za te decyzje odpowiada kierownik projektu. Inaczej dokument generuje oczekiwania, których żadna ze stron formalnie nie może spełnić.
Zakres zadań kluczowych ról BIM
Dobrze zdefiniowane role BIM przekładają się na listy konkretnych czynności. Przykładowo:
BIM Manager (po stronie wykonawcy): przygotowanie i aktualizacja BEP, nadzór nad zgodnością standardów, prowadzenie przeglądów koordynacyjnych wysokiego poziomu, raportowanie do kierownika kontraktu i zamawiającego.
Model Coordinator / Koordynator Branżowy: kontrola jakości modeli branżowych przed publikacją, udział w przeglądach kolizji, pilnowanie zgodności nazewnictwa i struktur.
Autor modelu: tworzenie i aktualizacja modelu, reagowanie na uwagi z koordynacji, utrzymanie porządku w atrybutach i strukturze pliku.
Przedstawiciel zamawiającego ds. BIM (jeżeli występuje): weryfikacja zgodności z wymaganiami, decyzje w punktach spornych, odbiór kamieni milowych informacyjnych.
Te opisy nie powinny być oderwane od czasu pracy i budżetu. Jeżeli od koordynatora wymaga się codziennych przeglądów modeli przy jednoczesnym pełnym etacie projektanta, BEP opisuje sytuację, która w praktyce nie ma szans działać.
Macierz odpowiedzialności (RACI) w realiach PZP
Macierz RACI ma sens wtedy, gdy odzwierciedla rzeczywiste kompetencje. W inwestycjach publicznych przydaje się osobna macierz dla:
procesu modelowania (kto odpowiada za które branże, kto weryfikuje, kto zatwierdza do publikacji),
procesu koordynacji (inicjowanie sesji, opracowanie raportów, zatwierdzanie rozwiązań kolizyjnych),
przekazywania danych zamawiającemu (przygotowanie paczek, kontrola jakości, formalny odbiór).
W praktyce barierą często jest to, że zamawiający nie wyznacza formalnie roli odpowiedzialnej za decyzje BIM po swojej stronie. BEP może tę lukę nazwać, ale nie rozwiąże problemu za zamawiającego – na etapie zatwierdzania dokumentu trzeba wyjaśnić, kto faktycznie będzie te decyzje podejmował.
Procesy i procedury: jak BEP przekłada wymagania na praktykę
Workflow tworzenia, weryfikacji i publikacji modeli
Nawet dobry opis wymagań nie pomaga, jeśli brakuje procedury: w jakiej kolejności powstają modele, kto je sprawdza i kiedy trafiają do wspólnego środowiska danych. W ujęciu minimalnym BEP powinien opisać:
proces tworzenia modelu na roboczo (lokalne pliki, zasady pracy zespołowej, częstotliwość synchronizacji),
wewnętrzną weryfikację przed publikacją (checklista jakości, kontrola kolizji wewnątrzbranżowych, walidacja nazw i parametrów),
publikację do CDE (kto jest uprawniony, jak nadaje się statusy typu „roboczy”, „do koordynacji”, „zatwierdzony”),
archiwizację wersji (jak długo trzyma się starsze wersje, w jaki sposób są identyfikowane).
Bez tego zespół pracuje „po swojemu”, a każda branża inaczej rozumie moment, w którym model jest gotowy do koordynacji. W zamówieniach publicznych, przy rotacji personelu, takie rozjazdy dość szybko przekładają się na spory o odpowiedzialność za błędy.
Procedura koordynacji międzybranżowej i zarządzania kolizjami
Deklaracja „będziemy prowadzić regularną koordynację BIM” jest bezwartościowa, jeśli nie idzie za nią procedura. Typowy, działający w praktyce schemat opisany w BEP obejmuje:
ustalenie częstotliwości sesji (np. co dwa tygodnie przy intensywnej fazie projektowania),
przygotowanie zaktualizowanych modeli przez branże do określonej daty,
scalenie i wstępną analizę przez koordynatora (np. zestaw reguł kolizyjnych, stref kontrolnych),
spotkanie koordynacyjne z udziałem branż i BIM Managera,
generowanie raportu z kolizji w postaci zadań (BIM issue tracker, pliki BCF lub system CDE),
określenie terminów i odpowiedzialnych za rozwiązanie poszczególnych kolizji,
weryfikację wdrożenia zmian na kolejnej sesji.
Najczęstsza pułapka: brak powiązania tych działań z harmonogramem projektowania. BEP powinien odnieść częstotliwość koordynacji i terminy zamykania kolizji do kluczowych kamieni milowych projektowych i kontraktowych, inaczej proces BIM funkcjonuje obok realnego terminu złożenia dokumentacji.
Zarządzanie zmianą w modelach a procedury kontraktowe
Modele w publicznych zamówieniach często stają się nieformalnym miejscem wdrażania zmian projektowych. Jeśli BEP nie wiąże zmian w modelach z procedurą zarządzania zmianą w kontrakcie (np. FIDIC lub wzór krajowy), pojawia się ryzyko wykonywania prac poza zakresem.
Bezpieczny schemat, który można odwzorować w BEP, to m.in.:
oznaczanie w modelu rozwiązań „proponowanych” odmiennie niż zatwierdzone (np. osobny status, faza, kolor),
powiązanie zmian w modelu z formalnym wnioskiem o zmianę (Change Request) lub zapytaniem do zamawiającego,
jasne reguły: kiedy i na jakiej podstawie zmiana w modelu staje się wiążąca dla dokumentacji i wykonawstwa.
Bez takich zapisów BIM Execution Plan w inwestycjach publicznych potrafi nieświadomie „legalizować” zmiany poza rygorami PZP, a to prosta droga do sporów przy rozliczeniu końcowym.
Strategia testów i kontroli jakości danych
Jakość modeli i danych nie poprawi się od samego istnienia BEP. Dokument powinien opisywać jak i kiedy testuje się modele oraz informacje, nie tylko „czy”. W praktyce oznacza to m.in.:
listę kontrolną dla autorów modeli (np. poprawność jednostek, zgodność z układem współrzędnych, wypełnienie kluczowych parametrów),
procedurę okresowej walidacji modeli przez koordynatora (reguły sprawdzania geometrii, atrybutów, klasyfikacji),
testy przekrojowe w CDE (czy paczki danych są kompletne, czy nazwy plików spełniają standardy, czy właściwe formaty trafiają do odpowiednich folderów),
mechanizmy monitorowania zgodności z wymaganiami zamawiającego (np. okresowe raporty zgodności z EIR).
Tu szczególnie przydaje się rozróżnienie na minimum obowiązkowe i dodatki. Próba wprowadzenia w jednym kontrakcie pełnego zestawu zaawansowanych testów automatycznych, bez przygotowania zespołu i narzędzi, kończy się tym, że nikt tych procedur realnie nie wdraża.
Wspólne środowisko danych (CDE) w kontraktach publicznych
Architektura CDE: kto dostarcza, kto administruje
Jedno z częstszych źródeł zamieszania: czy CDE zapewnia zamawiający, czy wykonawca, czy obie strony używają równoległych systemów. BEP musi tę kwestię rozstrzygać jednoznacznie, opisując:
dostawcę platformy (zamawiający lub wykonawca, ewentualnie wskazany podmiot trzeci),
zakres odpowiedzialności administratorów po obu stronach,
zasady nadawania i odbierania uprawnień użytkownikom,
procedurę zgłaszania problemów technicznych i czas reakcji.
W praktyce pojawia się też pytanie o środowisko „robocze” po stronie wykonawcy. Jeśli firmy korzystają z własnych systemów wymiany plików, BEP powinien opisać, jak i kiedy następuje transfer danych do oficjalnego CDE kontraktu oraz które środowisko jest w razie sporu traktowane jako referencyjne.
Struktura folderów i statusy dokumentów
Przejrzysta struktura CDE jest równie ważna jak sam wybór platformy. W kontraktach publicznych dobrze sprawdza się podział oparty na:
etapach cyklu życia (koncepcja, projekt budowlany, projekt wykonawczy, realizacja, eksploatacja),
typach informacji (modele, rysunki, zestawienia, korespondencja, raporty koordynacji, uzgodnienia formalne),
statusie dojrzałości (robocze, do przeglądu, zatwierdzone, zarchiwizowane).
Dość dobrze sprawdza się prosty szkielet: obszar WIP (Work In Progress) dla pracy roboczej zespołów, Shared dla informacji współdzielonych między branżami, Published dla informacji zatwierdzonych kontraktowo oraz Archive. W PZP kluczowe jest jednak dookreślenie, które z tych obszarów traktuje się jako miejsce złożenia „oficjalnej” dokumentacji na potrzeby terminów umownych i wniosków o płatność.
Same foldery nie wystarczą bez spójnego systemu statusów dokumentów i modeli. BEP powinien opisywać, jakie statusy są dopuszczalne (np. S0–S4, A–B–C lub inny, jasno zdefiniowany zestaw), kto może je nadawać oraz co w praktyce oznacza przejście ze statusu roboczego do zatwierdzonego. Bez tego każda strona interpretuje statusy „po swojemu” – zamawiający uważa, że coś jest już wiążące, projektant traktuje to nadal jako propozycję.
W realnych projektach publicznych problemem bywa równoległe funkcjonowanie kilku systemów nazewnictwa i statusów: jednego w CDE, drugiego w wewnętrznych procedurach wykonawcy i trzeciego w dokumentach zamawiającego. BEP może ograniczyć chaos, jeżeli wprost pokaże mapowanie tych systemów (np. tabela: status w CDE → status w procedurze jakości → konsekwencje kontraktowe). To żmudne, ale zwykle oszczędza sporo czasu przy pierwszym większym sporze o „czy ten plik był oficjalny”.
W tle pozostaje jeszcze kwestia uprawnień: kto ma prawo umieszczać dane w strefie „zatwierdzonej” i czy każda publikacja wymaga akceptacji po stronie zamawiającego. W kontraktach o dużej liczbie uczestników zbyt restrykcyjny model (wszystko przez jedną osobę) paraliżuje pracę, zbyt luźny – rozmywa odpowiedzialność. BEP nie rozwiąże tego magicznie, ale może wymusić decyzję i zapisać ją w sposób, który potem da się obronić przed kontrolą lub KIO.
Starannie napisany BIM Execution Plan w inwestycjach publicznych nie jest ozdobnikiem do oferty, tylko częścią „instrukcji obsługi” całego zamówienia. Im mniej w nim życzeniowych deklaracji, a więcej konkretnych reguł powiązanych z PZP, harmonogramem i realnymi kompetencjami zespołu, tym większa szansa, że BIM będzie wsparciem kontraktu, a nie kolejnym źródłem sporów.
Źródło: Pexels | Autor: Gustavo Fring
Role i odpowiedzialności w procesie BIM
Nawet najlepsze procedury zapisane w BEP nie działają, jeśli nie przypisano im konkretnych osób. Rola „BIM” pojawia się w dokumentach przetargowych coraz częściej, ale zakres obowiązków bywa niedookreślony, albo wręcz sprzeczny między SIWZ, ofertą i tym, co ląduje finalnie w BEP. To klasyczny przepis na rozmycie odpowiedzialności.
Macierz ról i odpowiedzialności (RACI)
Praktycznym narzędziem jest prosta macierz ról (często w formie tabeli RACI), która pokazuje, kto:
R (Responsible) – wykonuje daną czynność,
A (Accountable) – ponosi za nią odpowiedzialność końcową,
C (Consulted) – powinien być konsultowany,
I (Informed) – musi zostać poinformowany o wyniku.
W BEP taka macierz powinna obejmować nie tylko „funkcje BIM”, ale też klasyczne role kontraktowe. Typowe procesy, dla których warto ją zdefiniować, to m.in.:
walidacja zgodności z EIR oraz wymaganiami formalnymi,
procedura wprowadzania zmian projektowych w modelu,
przygotowanie modeli na potrzeby rozliczeń, obmiarów, roszczeń.
Bez takiego rozpisania często kończy się na stwierdzeniu „BIM Manager się tym zajmie”, podczas gdy w praktyce część zadań wymaga decyzji zamawiającego, część – projektanta wiodącego, a część – koordynatora branżowego po stronie wykonawcy. Macierz nie rozwiąże konfliktów interesów, ale zmusza strony do ich ujawnienia, zanim dojdzie do pierwszego większego sporu.
Rozgraniczenie ról: BIM Manager, BIM Koordynator, autor modelu
Na kontraktach publicznych szczególnie bolesne są sytuacje, gdy od BIM Managera oczekuje się jednocześnie zarządzania kontraktem, prowadzenia koordynacji oraz naprawiania błędów w modelach. To trzy różne poziomy odpowiedzialności. BEP powinien je jasno rozgraniczać:
BIM Manager – odpowiada za procesy, standardy, zgodność z wymaganiami zamawiającego, raportowanie i kontrolę nad całością środowiska informacyjnego. Decyduje „jak” zespół pracuje.
BIM Koordynator (często branżowy lub międzybranżowy) – prowadzi koordynację modeli, konfiguruje reguły kolizyjne, przygotowuje raporty, pilnuje stosowania standardów w praktyce.
Autor modelu (projektant, asystent) – odpowiada za zawartość merytoryczną modelu i jego zgodność z projektem, a nie za cały proces BIM.
Bez zapisów w BEP łatwo o sytuację, w której BIM Koordynator zostaje w praktyce „odkurzaczem” do naprawiania cudzych modeli. To nie tylko nieskuteczne, ale też groźne kontraktowo – poprawiając modele innych branż, przejmuje na siebie część odpowiedzialności za ich treść.
Udział zamawiającego w procesach BIM
W kontraktach publicznych kluczowe jest też zdefiniowanie roli zamawiającego: czy pełni funkcję aktywnego uczestnika procesu BIM (np. ma własny zespół BIM, korzysta z CDE na bieżąco), czy ogranicza się do roli odbiorcy modeli na określonych kamieniach milowych. BEP powinien określać m.in.:
kto po stronie zamawiającego akceptuje modele i raporty jako spełniające EIR,
jaki jest tryb udzielania odpowiedzi na zapytania związane z modelem (RFI dot. kolizji, braków danych),
czy zamawiający bierze udział w sesjach koordynacyjnych, a jeśli tak – na jakim etapie i w jakim zakresie.
Jeżeli zamawiający nie ma własnych kompetencji BIM, BEP powinien to uwzględniać, np. przewidując prostszy zakres raportowania i bardziej „klasyczne” formy przekazywania informacji (zestawienia, raporty PDF, zrzuty ekranów), zamiast zakładać, że każda osoba po stronie publicznej będzie samodzielnie obsługiwać przeglądarkę modeli.
Model jako wsparcie obmiarów i rozliczeń
Coraz częściej w zamówieniach publicznych modele mają wspierać obmiary i rozliczenia. To potencjalnie duże ułatwienie, ale tylko wtedy, gdy BEP określa zasady użycia modeli w sposób spójny z kontraktem i dokumentami przetargowymi. W przeciwnym razie model staje się „dodatkową opinią”, a i tak wszystko liczy się ręcznie z rysunków.
Zakres wykorzystania modeli do obmiarów
Pierwsze pytanie, na które trzeba odpowiedzieć w BEP, brzmi: czy model jest:
wyłącznie źródłem pomocniczym (wizualizacja, ułatwienie koordynacji),
źródłem danych obmiarowych pomocniczych, które wymagają weryfikacji z dokumentacją tekstową i rysunkową,
czy też stanowi główne źródło danych ilościowych, a rozbieżności z rysunkami rozstrzyga się na jego korzyść.
W praktyce większość kontraktów publicznych kończy na poziomie „pomocniczym”, nawet jeśli w dokumentach marketingowych pojawiają się hasła o „modelu jako źródle prawdy”. BEP powinien odzwierciedlać realny stan uzgodnień, a nie życzeniowe wizje.
Wymagania na potrzeby zestawień i obmiarów
Jeśli model ma wspierać obmiary, trzeba zawczasu wskazać, jakie informacje i w jakiej jakości są do tego niezbędne. BEP może to precyzować poprzez:
definicję parametrów ilościowych (np. pole brutto/netto, długość efektywna, objętość betonu konstrukcyjnego, masa stali),
opisy zasad modelowania pod obmiary (np. ściany dzielone na odcinki zgodnie z podziałem technologicznym, elementy prefabrykowane modelowane jako odrębne instancje),
wskazanie, które zestawienia będą generowane automatycznie, a które pozostaną poza zakresem BIM.
Bez takich doprecyzowań pojawia się typowy problem: zamawiający oczekuje, że model „się policzy”, wykonawca zakłada, że model jest tylko narzędziem koordynacji, a projektant nie modeluje szczegółów decydujących o ilościach (np. brakuje wszystkich przewiązek, nadlewów czy podkładów). Spór jest wtedy kwestią czasu.
Modele a roszczenia i rozliczenia końcowe
W BEP warto ująć też zasady używania modeli w kontekście roszczeń, robót dodatkowych i rozliczenia końcowego. Kluczowe pytania to m.in.:
czy model może być dowodem na to, że dany zakres robót został ujęty w projekcie (lub nie),
jak rozstrzyga się rozbieżności między modelem a dokumentacją 2D,
jak dokumentować w modelu wprowadzone zmiany, aby dało się później odtworzyć „stan na dzień podpisania aneksu”.
Próby wykorzystania modelu do rozliczeń bez wcześniejszych zapisów w BEP prowadzą zwykle do sytuacji, w której każda ze stron wybiera ten fragment informacji (model lub rysunek), który jest dla niej korzystniejszy. To prosta droga do przeciągających się sporów.
Modele powykonawcze i przekazanie informacji do eksploatacji
Publiczni zamawiający coraz częściej oczekują modeli powykonawczych, ale rzadko precyzują, co to w praktyce znaczy i jak te modele będą używane po zakończeniu inwestycji. BEP jest dobrym miejscem, aby to doprecyzować – inaczej modele „as-built” stają się nieaktualne już w dniu odbioru.
Definicja modelu powykonawczego w kontrakcie
Podstawowa kwestia to rozróżnienie między:
modelem odzwierciedlającym projekt powykonawczy (zgodny z dokumentacją zatwierdzoną po zmianach),
modelem odzwierciedlającym rzeczywisty stan obiektu po realizacji (uwzględniającym odchyłki montażowe, zamiany materiałów, zmiany na budowie).
W większości kontraktów publicznych realnie osiągalny jest pierwszy wariant; drugi wymaga już systematycznego pozyskiwania danych z budowy (np. z pomiarów skanerem 3D, geodezji powykonawczej czy systemów zarządzania wykonawstwem). BEP powinien jasno opisywać, do którego poziomu zespół dąży, i jak będzie to weryfikowane przy odbiorze.
Zakres aktualizacji modeli w trakcie robót
Jeśli modele mają być podstawą modeli powykonawczych, BEP musi określać, jak w trakcie budowy wprowadza się do nich zmiany. W praktyce sprawdza się m.in.:
powiązanie aktualizacji modeli z obiegiem poleceń zmiany i protokołów konieczności,
oznaczanie w modelu elementów wykonanych odmiennie niż w pierwotnym projekcie (np. parametrem statusu lub osobną fazą),
ustalenie minimalnej częstotliwości aktualizacji (np. raz w miesiącu lub po zakończeniu kluczowego etapu robót).
W przeciwnym razie modelem powykonawczym staje się „nadrabiany na szybko” plik aktualizowany po zakończeniu inwestycji, gdy część informacji jest już nieodtwarzalna lub wymaga ponownego przeglądu budowy.
Wymogi informacyjne na potrzeby eksploatacji
Modele dla użytkownika końcowego (np. jednostki budżetowej, operatora obiektu) różnią się od modeli „projektowo-wykonawczych”. BEP powinien wskazywać minimalny zestaw informacji niezbędnych w eksploatacji, np.:
identyfikatory urządzeń i elementów, spójne z systemem CMMS/CAFМ zamawiającego,
dane serwisowe (okresy przeglądów, wymagania gwarancyjne, istotne parametry eksploatacyjne),
powiązanie obiektów w modelu z dokumentami zewnętrznymi (karty katalogowe, instrukcje, certyfikaty).
Jeżeli zamawiający nie korzysta jeszcze z żadnego systemu FM, rozsądne bywa zdefiniowanie w BEP jedynie takiego zakresu danych, który da się utrzymać w aktualności przy użyciu prostych narzędzi (np. arkuszy kalkulacyjnych). Modele przeładowane informacjami, których nikt nie aktualizuje, szybko tracą wartość.
Standardy danych, klasyfikacja i interoperacyjność
Bez uzgodnionych standardów danych modele z poszczególnych branż nie tworzą spójnego zestawu informacji, tylko zbiór niekompatybilnych plików 3D. W kontraktach publicznych dochodzi do tego jeszcze jeden wymiar: obowiązek zapewnienia interoperacyjności i unikania nadmiernego przywiązania do jednego dostawcy oprogramowania.
System klasyfikacji i kodyfikacja obiektów
W BEP trzeba jasno wskazać, jakiego systemu klasyfikacji używa się w projekcie (np. krajowego, branżowego, międzynarodowego), a także jak łączy się go z istniejącymi systemami zamawiającego, jeśli takie już funkcjonują. Kluczowe elementy to:
lista stosowanych klasyfikacji (np. dla elementów budowlanych, procesów, wyposażenia),
zasady nadawania kodów (np. kto je tworzy, jak zapewnia się ich unikalność),
wymóg stosowania kodów w nazwach, parametrach modeli i dokumentach 2D.
Bez tego zamawiający otrzymuje na końcu projektu zestaw modeli, w których każda branża opisuje te same elementy w inny sposób, a zbudowanie z tego spójnej bazy do zarządzania obiektem wymaga dodatkowego, kosztownego etapu „porządkowania danych”.
Wymogi dotyczące formatów wymiany danych
BEP powinien precyzować, które formaty są uznawane za referencyjne kontraktowo (np. IFC, otwarte formaty płaskie) oraz jakie formaty natywne dopuszcza się jako robocze. Typowa struktura wygląda następująco:
formaty natywne – dla pracy wewnętrznej zespołów (nie są przekazywane jako materiał rozstrzygający spory),
formaty wymiany – np. IFC, BCF, DWG, używane do koordynacji międzybranżowej i przekazywania informacji zamawiającemu,
formaty archiwalne – wspierające długoterminową czytelność (np. PDF/A, otwarte wersje IFC).
Trzeba przy tym uczciwie wskazać typowe ograniczenia: eksport IFC nie jest idealną kopią modelu natywnego, a zakres przenoszonych danych zależy od konfiguracji eksportera. BEP powinien przynajmniej określać minimalne wymagania w tym zakresie (np. jakie klasy obiektów muszą się pojawić w IFC, jakie parametry są obligatoryjne), zamiast zakładać, że „program sam to zrobi”.
Spójność parametrów i słowników
Parametry w modelach to drugie po geometrii źródło nieporozumień. Jedna branża używa skrótu „PN”, inna „No. części”, trzecia „Marka”; wszystko dotyczy tego samego identyfikatora. BEP powinien wprowadzać:
listę kluczowych parametrów wymaganych dla danych typów obiektów,
spójne nazewnictwo parametrów (zwłaszcza tych, które będą eksportowane do IFC),
opis formatów danych (np. czy data ma format ISO, jak zapisuje się wartości logiczne, jakie stosuje się jednostki).
Przy bardziej złożonych zadaniach przydaje się też wspólny słownik wartości dla wybranych parametrów (np. typów pomieszczeń, statusów elementów, rodzajów urządzeń). Jeżeli każda branża opisuje to samo pomieszczenie inną nazwą funkcji, zamawiający nie wyciągnie z tego wiarygodnych raportów. BEP może odwoływać się do istniejących standardów (np. słowników branżowych) lub wprowadzać projektowy „mini‑standard” opisany w prostym arkuszu i udostępniony wszystkim uczestnikom procesu.
Dobrym testem spójności słowników jest wczesne wykonanie próbnych eksportów IFC i zestawień danych. Jeżeli już na etapie koncepcji lub wstępnego projektu okaże się, że te same informacje trafiają do różnych pól, a filtry nie działają prawidłowo, jeszcze da się to skorygować zapisem w BEP i prostymi szablonami parametrów. Próba porządkowania tych kwestii na etapie rozliczeń końcowych kończy się z reguły ręcznym poprawianiem tysięcy rekordów – zwykle poza budżetem i harmonogramem.
Trzeba też uwzględnić ograniczenia konkretnych narzędzi. Nie każdy program obsłuży identyczne nazwy parametrów czy typy danych, a część konfiguracji (np. mapowanie do IFC) będzie wymagała dodatkowej pracy po stronie zespołów. BEP nie zastąpi tej konfiguracji, ale może jasno zdefiniować oczekiwany wynik, terminy przygotowania szablonów i odpowiedzialność za ich dystrybucję. Minimalizuje to ryzyko, że różne biura i wykonawcy zaczną pracować na własnych, niekompatybilnych standardach.
Im bardziej precyzyjny, realistyczny i egzekwowany BEP, tym mniejsze pole do uznaniowości i późniejszych sporów. Dokument, który łączy wymagania zamawiającego z realnymi możliwościami rynku, staje się praktycznym narzędziem zarządzania informacją, a nie tylko załącznikiem „odfajkowanym” przy podpisywaniu umowy.
Źródło: Pexels | Autor: Thirdman
Procedury weryfikacji modeli i kontroli jakości danych
Bez opisanych i egzekwowanych procedur kontroli jakości model stopniowo traci wiarygodność. Na papierze „wszystko jest w BIM‑ie”, natomiast przy pierwszej próbie wygenerowania zestawienia okazuje się, że część elementów nie ma przypisanych klas, innych nie uda się odfiltrować, a kolizje „nie wychodziły”, bo ktoś wyłączył fragment modelu z widoku.
Zakres i częstotliwość kontroli modeli
BEP powinien doprecyzowywać, co konkretnie jest sprawdzane, jak często i przy użyciu jakich narzędzi. Standardowy, przydatny podział obejmuje:
kontrolę geometrii – kompletność modelu, podstawowa poprawność odwzorowania, zgodność z założonym poziomem szczegółowości,
kontrolę kolizji – międzybranżową i wewnątrzbranżową, z wyszczególnieniem krytycznych obszarów (np. trasy głównych instalacji),
kontrolę danych – obecność i poprawność kluczowych parametrów, zgodność z przyjętym słownikiem,
kontrolę formalną – poprawność struktury plików, nazewnictwa, przypisania faz i rewizji.
Sama deklaracja, że „koordynacja będzie prowadzona w cyklach dwutygodniowych”, niewiele daje, jeśli nie ma listy elementów faktycznie podlegających sprawdzeniu i sposobu, w jaki raportuje się wyniki.
Odpowiedzialność za jakość i ścieżka akceptacji
Jeżeli każda branża rozumie „jakość modelu” po swojemu, spory są nieuniknione. W BEP trzeba jednoznacznie wskazać:
kto odpowiada za przygotowanie modeli branżowych do koordynacji (z imienia/funkcji, nie tylko nazwy firmy),
kto odpowiada za koordynację międzybranżową (koordynator BIM po stronie wykonawcy, inżyniera, zamawiającego),
jak wygląda ścieżka akceptacji – kiedy model traktuje się jako „roboczy”, „do koordynacji”, a kiedy jako „zatwierdzony do realizacji”.
Przydatna bywa prosta matryca odpowiedzialności (RACI) powiązana z kamieniami milowymi kontraktu. Tam, gdzie jej nie ma, często dochodzi do sytuacji, w której każdy zakłada, że kontrolę „zrobi ktoś inny”, a braki wychodzą na jaw dopiero przy rozliczeniu lub w czasie budowy.
Kryteria jakościowe dla odbioru modeli
Odbiór modeli bez wyraźnych kryteriów kończy się oceną „na oko” lub sporem, czy błąd jest „istotny”. W BEP należy opisać co najmniej:
minimalny zestaw parametrów, które muszą być uzupełnione dla danej kategorii elementów,
dopuszczalny poziom braków (np. procent brakujących wartości dla wskazanych pól, jeśli w ogóle przewiduje się taki margines),
minimalny zakres kontroli kolizji oraz sposób raportowania nierozwiązanych kolizji,
zasady postępowania z błędami krytycznymi (np. warunek wstrzymania akceptacji modeli powykonawczych).
Nie chodzi o tworzenie katalogu kar za każdy brak parametru, tylko o zrozumiałą granicę pomiędzy niedoskonałością akceptowalną a błędem uniemożliwiającym realne użycie modelu.
Raporty z koordynacji i śledzenie zmian
W praktyce spory nie wynikają z tego, że błędy się pojawiły, tylko że nikt nie potrafi wykazać, kiedy je zgłoszono i kto miał je poprawić. Dlatego BEP powinien porządkować kwestię raportowania:
format raportów z koordynacji (np. BCF, raport PDF z listą kolizji, zestawienie w XLSX),
sposób przypisywania zadań i terminów (np. identyfikator sprawy, odpowiedzialny podmiot, termin usunięcia),
zasady aktualizacji statusów (np. „nowa”, „w trakcie”, „do weryfikacji”, „zamknięta”),
archiwizację raportów jako formalnej części dokumentacji.
Brak formalnego śledzenia zmian skutkuje tym, że na naradzie koordynacyjnej wszyscy zgadzają się, iż „trzeba to poprawić”, po czym temat rozpływa się w gąszczu maili i nieprecyzyjnych notatek.
Modele czasowe i kosztowe w kontraktach publicznych
Coraz częściej w zamówieniach publicznych pojawiają się zapisy o 4D czy 5D, ale ich rozumienie bywa bardzo różne. U jednego zamawiającego oznacza to tylko proste powiązanie modelu z harmonogramem Gantta na potrzeby wizualizacji, u innego – oczekiwanie półautomatycznych obmiarów i kontroli kosztów na podstawie modeli. BEP powinien doprecyzowywać, jaką funkcję te rozszerzenia mają pełnić w danym projekcie.
Zakres wykorzystania BIM 4D
Modele 4D mogą służyć do kilku celów jednocześnie, ale w większości publicznych kontraktów stosuje się jeden–dwa z nich. BEP powinien wskazywać, czy 4D ma służyć głównie do:
wizualnego uzasadnienia organizacji robót (np. dla mieszkańców lub służb miejskich),
wspierania planowania dostaw i frontów robót,
analizy kolizji czasowych (np. równoległe prace na ograniczonej przestrzeni),
kontroli postępu i porównania planu z realizacją.
Od wybranego zastosowania zależy m.in. poziom szczegółowości powiązań między modelem a harmonogramem, częstotliwość aktualizacji oraz to, kto faktycznie będzie z tych danych korzystał (planista, kierownik budowy, zamawiający).
Zasady powiązania modelu z harmonogramem
Najczęstsza pułapka 4D to próba „podpięcia” pojedynczych elementów modelu do setek zadań harmonogramu bez przygotowania struktury pośredniej. BEP powinien wskazywać:
na jakim poziomie agregacji tworzy się powiązania (np. brygady robocze, sekcje konstrukcyjne, odcinki instalacji),
kto odpowiada za utrzymanie spójności kodów między strukturą WBS harmonogramu a strukturą modelu,
jak często aktualizuje się powiązania wraz ze zmianami projektu i harmonogramu.
Bez tego model 4D jest atrakcyjną, ale oderwaną od realiów wizualizacją, której nikt nie aktualizuje po pierwszych większych zmianach.
Wykorzystanie modeli do obmiarów i szacowania kosztów (5D)
W kontraktach publicznych oczekiwania wobec 5D bywają szczególnie nierealistyczne. Założenie, że „model policzy wszystko sam”, zderza się z wymaganiami kosztorysowania według katalogów norm i specyficznych zasad rozliczeniowych. W BEP warto doprecyzować kilka kluczowych obszarów:
cel użycia 5D – wsparcie szacowania na etapie koncepcji, kontrola zmian, czy też podstawowe narzędzie rozliczeń,
zakres obmiarów modelowych – które kategorie robót są wspierane przez model, a gdzie obmiar pozostaje tradycyjny,
powiązanie z pozycjami kontraktowymi – czy tworzy się dedykowane kody obmiarowe w modelu, czy wykorzystuje się istniejące klasyfikacje zamawiającego.
Jeżeli model ma być traktowany jako jeden z dowodów przy rozliczeniach, trzeba też określić, jak rozstrzyga się rozbieżności między obmiarem modelowym, inwentaryzacją w terenie i pomiarami tradycyjnymi.
Ograniczenia i warunki stosowania 4D/5D
Nie każde zadanie nadaje się do pełnego 4D/5D. Drobne roboty wykończeniowe lub powtarzalne elementy małej architektury mogą generować więcej pracy przy modelowaniu niż realnych korzyści przy planowaniu. BEP powinien dopuszczać racjonalne wyjątki, np.:
niepełne odzwierciedlenie harmonogramu dla prac o niskim ryzyku kolizji czasowych,
szacowanie zbiorcze dla drobnych elementów, bez szczegółowego rozbijania ich na poziomie modelu,
odstępstwa od dokładności obmiaru modelowego tam, gdzie i tak decydują pomiary in situ.
Nadmierne formalizowanie 4D/5D, bez uwzględnienia specyfiki robót, prowadzi do sytuacji, w której zespół produkuje modele głównie po to, aby spełnić zapis w kontrakcie, a faktyczne decyzje i tak zapadają na podstawie tradycyjnych harmonogramów i kosztorysów.
Środowisko CDE i zarządzanie obiegiem informacji
W wielu projektach publicznych największym problemem nie są same modele, tylko chaos w obiegu informacji: kilka niezsynchronizowanych serwerów, równoległy obieg mailowy i brak jasnej odpowiedzi na pytanie, który plik jest „obowiązujący”. BEP powinien przekładać wymagania kontraktowe dotyczące CDE na praktyczne zasady pracy.
Struktura folderów i wersjonowanie
Abstrahując od konkretnego narzędzia (platforma chmurowa, serwer zamawiającego), trzeba zdefiniować podstawową strukturę przechowywania danych. Typowy, przejrzysty podział obejmuje:
obszar roboczy zespołów (modele i dokumenty w opracowaniu),
obszar współdzielony do koordynacji (wersje przeznaczone do uzgodnień międzybranżowych),
obszar zatwierdzony/kontraktowy (materiały formalnie zatwierdzone),
BEP powinien opisywać, kto ma dostęp do którego obszaru, jakie ma uprawnienia (odczyt, zapis, zatwierdzanie) i jak oznacza się przejście pliku z jednej „strefy” do drugiej. Bez tego nawet najlepsze narzędzie CDE staje się tylko kolejnym miejscem przechowywania plików.
Reguły nazewnictwa plików i modeli
Nawet prosty system nazewnictwa znacząco redukuje ryzyko pomyłek. W BEP warto opisać schemat nazwy pliku/modelu, obejmujący co najmniej:
identyfikator projektu i kontraktu,
branżę lub dyscyplinę (np. AR, ST, ME, EL),
obszar lub obiekt (np. budynek, sekcja, odcinek),
typ dokumentu/modelu (projekt, model koordynacyjny, model powykonawczy),
numer rewizji i status (np. „DO UZG.”, „ZATW.”).
Najczęstszy błąd to pozostawienie nazewnictwa „swobodnej inwencji” poszczególnych biur, co przy wielu uczestnikach kończy się plikami o nazwach w stylu „model_nowydobudowy_final_ver2_poprawione_konstrukcja2.rvt”.
Proces przekazywania i zatwierdzania informacji
Każde przekazanie informacji (model, rysunki, raporty z koordynacji) powinno mieć odzwierciedlenie w prostym, ale jednoznacznym procesie. BEP może odwoływać się do procedur kontraktowych (np. podania, zapytania, roszczenia), lecz przydatne jest doprecyzowanie BIM‑owego „szczegółu”, np.:
kto inicjuje publikację nowej wersji modelu do obszaru współdzielonego,
w jaki sposób zamawiający/inżynier jest powiadamiany o dostępności nowej wersji,
jak jest dokumentowana akceptacja lub odrzucenie (np. komentarz w CDE, osobny protokół),
jak rozwiązuje się konflikty, gdy kilka branż jednocześnie wprowadza zmiany w tym samym obszarze.
Tam, gdzie te zasady nie są doprecyzowane, „zatwierdzenie” modelu polega często na milczącym braku sprzeciwu, co w sporze sądowym trudno obronić jako jednoznaczne oświadczenie woli.
Integracja CDE z innymi systemami zamawiającego
W większych organizacjach publicznych CDE nie funkcjonuje w próżni – istnieją już systemy obiegu dokumentów, repozytoria, czasem także platformy przetargowe i rejestry decyzji administracyjnych. BEP powinien przynajmniej zarysowywać:
które dokumenty trafiają równolegle do systemu kancelaryjnego (np. formalne decyzje, protokoły),
jakie formaty są akceptowane przez systemy zamawiającego jako „dokument rozstrzygający”,
jak zapewnia się spójność identyfikatorów spraw pomiędzy CDE a innymi rejestrami.
Brak powiązania CDE z formalnym obiegiem dokumentów powoduje, że część istotnych uzgodnień istnieje wyłącznie jako komentarze do modeli lub zadania w systemie, które z punktu widzenia procedur administracyjnych „nie istnieją”.
Szkolenia, kompetencje i wsparcie dla uczestników projektu
Najlepszy BEP nie zadziała, jeśli osoby odpowiedzialne za jego wdrożenie nie rozumieją zapisów lub nie mają narzędzi, aby je zrealizować. W zamówieniach publicznych dodatkową trudnością są rozproszone zespoły i różny poziom dojrzałości BIM po stronie wykonawców, projektantów i samego zamawiającego.
Minimalne wymagania kompetencyjne
W BEP można – i zwykle warto – określić minimalne wymagania wobec kluczowych ról związanych z BIM, takich jak koordynator BIM, liderzy branż, administrator CDE. Zwykle obejmuje to:
podstawowy zakres wiedzy technicznej o BIM (standardy, pojęcia, formaty wymiany danych),
znajomość narzędzi wymaganych w projekcie (oprogramowanie modelujące, przeglądarki modeli, platforma CDE) na poziomie adekwatnym do roli,
umiejętność czytania i egzekwowania zapisów BEP oraz powiązanych procedur kontraktowych,
doświadczenie w pracy w środowisku wielobranżowym i podstawy zarządzania zmianą.
Opis kompetencji nie musi przyjmować formy sztywnego katalogu certyfikatów. Lepiej zdefiniować efekty, jakich oczekuje się od danej roli (np. samodzielne przygotowanie zestawu kontroli koordynacyjnej, konfiguracja pakietów publikacyjnych w CDE) i dopiero do nich ewentualnie przypisać przykładowe szkolenia czy certyfikacje. Sztywne wymaganie konkretnego „papieru” bywa wygodne przetargowo, ale w praktyce eliminuje część kompetentnych osób, a nie gwarantuje realnych umiejętności.
Plan szkoleń i wdrożenia narzędzi
BEP powinien jasno wskazywać, jak uczestnicy projektu mają dojść do zakładanych kompetencji. Typowy, sensowny plan obejmuje co najmniej:
szkolenie wstępne z zasad BEP i obsługi CDE dla wszystkich uczestników,
krótkie sesje przypominające przy kluczowych kamieniach milowych (np. start fazy wykonawczej, początek modelowania powykonawczego).
Te działania nie muszą być rozbudowane ani drogie. Bardziej krytyczna jest ich terminowość i powiązanie z rzeczywistymi zadaniami. Szkolenie z obsługi CDE przeprowadzone pół roku przed pierwszą publikacją modelu jest w praktyce bezużyteczne. Lepiej zaplanować krótsze, ale bliżej osadzone w harmonogramie warsztaty, najlepiej z wykorzystaniem realnych danych projektowych zamiast „książkowych” przykładów.
Wsparcie operacyjne i kanały pomocy
W projektach publicznych z udziałem wielu podmiotów nieuniknione są sytuacje, w których ktoś „utknie” na problemie technicznym lub proceduralnym. BEP powinien wskazywać, gdzie w takich przypadkach szukać pomocy. Zazwyczaj sprawdza się prosta drabinka wsparcia:
w pierwszej kolejności – wewnętrzny koordynator BIM po stronie danego wykonawcy/projektanta,
następnie – główny koordynator BIM projektu lub administrator CDE,
w razie sporu interpretacyjnego – wyznaczony przedstawiciel zamawiającego lub inżyniera kontraktu.
Równolegle przydaje się jeden, jasno opisany kanał zgłaszania problemów (np. dedykowana skrzynka, moduł zgłoszeń w CDE) oraz krótki, realny termin reakcji. Jeżeli uczestnicy nie wiedzą, gdzie zgłosić błąd w konfiguracji CDE czy wątpliwości co do wymaganego poziomu LOD, szybko wracają do maili i prywatnych dysków, a cały system BIM traci spójność.
Utrzymywanie i aktualizacja kompetencji w trakcie projektu
Wieloletnie inwestycje publiczne mają tę cechę, że zespoły się zmieniają: pojawiają się nowi projektanci, podwykonawcy, czasem wymienia się kluczowy personel po stronie zamawiającego. BEP powinien przewidywać, jak w takich sytuacjach zachować minimalną ciągłość kompetencji BIM. Sprawdza się np. wymaganie, aby:
zmiana osoby na kluczowym stanowisku BIM była formalnie zgłaszana i akceptowana,
nowa osoba odbyła skrócone szkolenie wdrożeniowe obejmujące specyfikę danego kontraktu,
wiedza krytyczna (ustalenia koordynacyjne, specyficzne konwencje modelowania) była utrzymywana w formie aktualizowanej dokumentacji projektowej, a nie „w głowie” jednej osoby.
Czasem wystarcza prosty „pakiet startowy” dla nowych członków zespołu, zawierający aktualny BEP, skróconą instrukcję pracy w CDE, listę głównych kontaktów BIM oraz kilka przykładowych, prawidłowo przygotowanych modeli i raportów. Taki zestaw, uzupełniony krótką rozmową wdrożeniową z koordynatorem, ogranicza ryzyko, że nowa osoba będzie przez tygodnie odtwarzać błędy, które projekt dawno już przepracował. W dużych kontraktach sensowne bywa także okresowe, syntetyczne „odświeżenie” dla całego zespołu – nie tyle szkolenie narzędziowe, co przegląd, co faktycznie działa w procesach BIM, a co wymaga korekty.
Praktycznym narzędziem jest też prosta ewidencja szkoleń i kompetencji projektowych, prowadzona przez głównego koordynatora BIM lub inżyniera kontraktu. Nie musi to być rozbudowany system HR – często wystarczy tabelaryczne zestawienie z informacją, kto brał udział w jakim szkoleniu, kiedy i w jakiej roli. Przy każdej większej zmianie zespołu łatwo wtedy sprawdzić, gdzie pojawiają się luki i które obszary wymagają uzupełnienia. Bez takiej ewidencji zamawiający zwykle dowiaduje się o braku kompetencji dopiero przy pierwszej poważnej awarii procesu (np. nieudane przekazanie danych do systemu utrzymaniowego).
Przy dłuższych projektach przydaje się pewna elastyczność: technologie i standardy BIM zmieniają się szybciej niż cykl inwestycyjny. W BEP można z góry dopuścić aktualizację narzędzi czy formatów wymiany danych pod warunkiem, że zostanie przeprowadzona kontrolowana aktualizacja kompetencji (np. krótkie warsztaty + uaktualnienie instrukcji CDE), a nie spontaniczna decyzja pojedynczego biura projektowego. Bez tego typowy scenariusz wygląda tak, że część zespołu pracuje już w nowej wersji oprogramowania i formatach IFC, podczas gdy pozostali wciąż generują pliki „po staremu”, co rozsadza proces koordynacji.
Dobrze przygotowany BEP w inwestycji publicznej nie jest zbiorem życzeń zamawiającego ani katalogiem funkcji oprogramowania, lecz przełożeniem potrzeb biznesowych i prawnych na konkretne obowiązki, formaty danych, terminy i role. Im bardziej te ustalenia są mierzalne, testowalne i powiązane z realną strukturą odpowiedzialności, tym mniejsze ryzyko, że BIM skończy jako hasło w SIWZ, a nie narzędzie zarządzania informacją w cyklu życia obiektu.
Najczęściej zadawane pytania (FAQ)
Czym jest BIM Execution Plan (BEP) w zamówieniach publicznych?
BIM Execution Plan to uzgodniona instrukcja organizacyjno‑techniczna opisująca, jak konkretny zespół będzie realizował wymagania BIM na danym kontrakcie publicznym. Nie jest to tylko formalny załącznik, ale praktyczny opis: kto co robi, w jakich narzędziach, w jakich formatach, kiedy i w jakiej strukturze środowiska danych.
Dobrze przygotowany BEP jest później punktem odniesienia przy każdym sporze o zakres modelu, jakość danych czy terminy przekazywania informacji. Jeżeli po lekturze dokumentu różne osoby dochodzą do sprzecznych interpretacji, to z perspektywy praktyki projektowej BEP nie spełnia swojej funkcji – nawet jeśli formalnie „jest w papierach”.
Co musi się znaleźć obowiązkowo w BEP przy inwestycjach publicznych?
Minimalny zestaw elementów, bez których projekt informacyjnie się rozsypie, obejmuje przede wszystkim:
jasno zdefiniowany zakres modelowania (co jest modelowane, a co pozostaje w 2D/dokumentacji opisowej),
poziomy szczegółowości LOD/LOI dla poszczególnych branż i etapów,
role i odpowiedzialności (BIM Manager, BIM Coordinator, autorzy modeli, strony zatwierdzające),
strukturę i zasady pracy w CDE (podział na foldery, stany plików, sposób zatwierdzania),
wymagane formaty wymiany danych (np. IFC, natywne formaty, formaty raportów),
harmonogram publikacji modeli oraz częstotliwość koordynacji międzybranżowej,
zasady akceptacji modeli i raportowania kolizji/błędów.
Przy braku sensownie opisanego EIR/OPZ to właśnie BEP staje się kluczowym dokumentem, który te kwestie porządkuje. Jeżeli czegoś brakuje w BEP, w praktyce trudno później egzekwować to przy odbiorze.
Jaka jest różnica między pre‑contract BEP a post‑contract BEP?
Pre‑contract BEP przygotowuje się na etapie składania oferty. Służy głównie do pokazania, że wykonawca rozumie wymagania zamawiającego (EIR/OPZ) i ma realny, choć jeszcze ogólny, plan ich realizacji. Zawiera koncepcję organizacji informacji, wybór głównych narzędzi, opis ról i ogólnych zasad koordynacji, ale zwykle bez bardzo szczegółowych harmonogramów i tabel LOD/LOI.
Post‑contract BEP powstaje już po podpisaniu umowy. To dokument operacyjny, rozwinięty i dostosowany do konkretnego kontraktu. Znajdują się w nim szczegółowe tabele LOD/LOI, dokładny opis cyklu publikacji modeli, zasady nazewnictwa plików, workflow w CDE, reguły raportowania kolizji i struktury klasyfikacyjne. Ten dokument bywa aktualizowany w trakcie trwania kontraktu, ale sposób wprowadzania zmian też powinien być w nim jasno opisany.
Jak BEP ma się do EIR/OPZ zamawiającego? Czy może „naprawić” słabe wymagania?
BEP jest zawsze wtórny wobec wymagań zamawiającego: EIR/OPZ mówią, co ma być dostarczone, a BEP – jak to będzie zrobione. W idealnym scenariuszu EIR/OPZ są spójne, a BEP tylko uszczegóławia zasady. W polskiej praktyce częściej spotyka się jednak wymagania fragmentaryczne lub hasłowe („projekt w technologii BIM”).
W takich sytuacjach BEP często przejmuje rolę „prostowania” niespójności i doprecyzowywania wymagań – oczywiście w granicach tego, na co zgodzi się zamawiający. Dobrze napisany BEP pomaga urealnić oczekiwania (np. co do poziomu szczegółowości modeli) i jednocześnie zabezpiecza wykonawcę, bo dokumentuje, co zostało uzgodnione, a czego już nie.
Czy BIM Execution Plan musi być załącznikiem do umowy w zamówieniach publicznych?
Nie ma jednego obowiązkowego modelu. W praktyce stosuje się dwa podejścia: BEP jako formalny załącznik do umowy lub BEP jako dokument roboczy zatwierdzony przez zamawiającego. Każde rozwiązanie ma swoje konsekwencje.
Jeśli BEP jest załącznikiem do umowy, naruszenie jego zapisów może rodzić roszczenia, a każda zmiana zwykle wymaga formalnej procedury (aneks, protokół). To zwiększa bezpieczeństwo obu stron, ale zmniejsza elastyczność. Gdy BEP ma status dokumentu roboczego, łatwiej go aktualizować, jednak ryzyko sporów o to, „czy to było w cenie”, rośnie – zwłaszcza gdy przy odbiorze pojawiają się nowe, nieopisane wcześniej oczekiwania informacyjne.
Jakie normy i standardy powinno się uwzględniać przy tworzeniu BEP w sektorze publicznym?
Najczęściej przywoływanym punktem odniesienia jest seria PN‑EN ISO 19650 dotycząca zarządzania informacją w BIM. W wielu postępowaniach publicznych pojawia się ogólny zapis o prowadzeniu projektu „zgodnie z ISO 19650”. Trzeba jednak pamiętać, że to zbiór ram procesowych, a nie gotowy szablon BEP – samo przekopiowanie fragmentów normy do dokumentu rzadko przekłada się na realną organizację pracy.
Przy tworzeniu BEP lepiej traktować normy jako kontekst i punkt odniesienia, a nie „ściągę”. Oprócz ISO 19650 trzeba uwzględnić konkretne zapisy PZP, lokalne wytyczne zamawiającego, a także zwyczaje branżowe i realne możliwości zespołów projektowych. Inaczej powstaje dokument teoretycznie „zgodny z normą”, ale nierealny do zastosowania na budowie czy w biurze projektowym.
Jak przygotować dobry BEP, gdy zamawiający ma bardzo ogólne wymagania typu „projekt w BIM”?
W takiej sytuacji kluczowe jest, aby wykonawca sam zaproponował minimalny, spójny zestaw zasad i przedstawił go zamawiającemu do akceptacji. Zwykle zaczyna się od zdefiniowania zakresu modelowania, oczekiwanego przeznaczenia modeli (koordynacja, przedmiary, model powykonawczy) oraz docelowych formatów przekazania danych.
Praktyczne podejście to zaproponowanie w BEP kilku jasnych rozstrzygnięć zamiast pozostawiania „szarej strefy”. Przykład: określenie, że model powykonawczy będzie miał LOD X, obejmie elementy konstrukcyjne, architekturę i instalacje główne, w formacie IFC oraz natywnym, z aktualizacją co określony etap prac. Im mniej niedopowiedzeń zostanie na etapie tworzenia BEP, tym mniejsze ryzyko konfliktów przy odbiorze inwestycji.
