BIM Execution Plan w inwestycjach publicznych: co powinno się w nim znaleźć obowiązkowo

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.

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 pochodne: raporty kolizji, zrzuty widoków, przekroje, zestawienia materiałów, raporty postępu modelowania,
• 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:

1. ustalenie częstotliwości sesji (np. co dwa tygodnie przy intensywnej fazie projektowania),
2. przygotowanie zaktualizowanych modeli przez branże do określonej daty,
3. scalenie i wstępną analizę przez koordynatora (np. zestaw reguł kolizyjnych, stref kontrolnych),
4. spotkanie koordynacyjne z udziałem branż i BIM Managera,
5. generowanie raportu z kolizji w postaci zadań (BIM issue tracker, pliki BCF lub system CDE),
6. określenie terminów i odpowiedzialnych za rozwiązanie poszczególnych kolizji,
7. 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.