W wielu postępowaniach publicznych na usługi projektowe lub roboty budowlane pojawiają się zapisy dotyczące oprogramowania. O ile stawianie wymogów dot. wykorzystania odpowiednich narzędzi do obsługi projektu – w tym CDE – w zasadzie nikogo nie dziwi, to zapisy odnoszące się do konieczności wykonania projektu w określonym programie komputerowym/dostarczenia projektu w formacie zamkniętym jednego producenta lub informacje o tym, że Zamawiający dysponuje takim narzędziem (najczęściej jest to właśnie tytułowy Revit), stanowią dość ciekawe – i często nieco kontrowersyjne – przypadki a pod postami cytującymi treść takich wymagań toczą się, czasem bardzo burzliwe, dyskusje na temat zasadności tych wymagań.
Rysunek 1. Specyfikacja Warunków Zamówienia dla zamówienia publicznego na opracowanie Przedprojektowej Koncepcji Funkcjonalno-Użytkowej dla zadania: „Budowa z przebudową budynków H i D dla potrzeb Mazowieckiego Szpitala Bródnowskiego w Warszawie Sp. z o.o.”; znak: MSB/PN/06/03/2021 (29.03.2021)
Rysunek 2. Zapytanie ofertowe w przedmiocie zamówienia: “Inwentaryzacja nieruchomości przy ul. Pawła Stalmacha 8 w Siemianowicach Śląskich – Zadanie nr 3: Inwentaryzacja obiektów” (opracowanie: 12.03.2021)
Rysunek 3. Załącznik nr 10 do wzoru umowy ZP/98/2021 w postępowaniu pn. „Łódzkie Centrum Toksykologii” (31.12.2021)
Oczywiście trudno jednoznacznie wskazać przyczynę ich wprowadzania jednak można pokusić się o wytypowanie kilku dość prawdopodobnych powodów:
- po pierwsze: inwestor ma istotny cel w stawianiu wymagań dot. oprogramowania (wtedy wspomniane dyskusje wynikają z tego, że inwestor nie wskazał go w dokumentacji lub wskazał, ale wykonawcy tego nie zauważyli),
- po drugie: autorzy dokumentacji przyjęli strategię “na-wszelki-wypadek”, która teoretycznie ma zabezpieczyć potencjalne interesy zamawiającego (których jednak nie potrafi jednoznacznie określić i wykazać w dokumentacji postępowania) pozostawiając sobie możliwość wykorzystania tego narzędzia w imię zasady “może nam się to przydać więc wpiszmy” (patrz: rysunek 3),
- i w końcu może być tak, że dystrybutor oprogramowania wykonał dobrą robotę i zasiał w głowie inwestora potrzebę posiadania jego narzędzia.
Niezależnie od przyczyny na początek należy zastanowić się, czy inwestor w ogóle powinien wskazywać nazwy konkretnych narzędzi, których stosowania/udostępnienia wymaga. W przypadku inwestorów prywatnych z uwagi na dowolność w kształtowaniu treści umów wyrażoną w treści Art. 3531 Kodeksu cywilnego nie ma żadnych ograniczeń w tym zakresie:
“Strony zawierające umowę mogą ułożyć stosunek prawny według swego uznania, byleby jego treść lub cel nie sprzeciwiały się właściwości (naturze) stosunku, ustawie ani zasadom współżycia społecznego.”
W przypadku zamawiających z sektora publicznego sytuacja jest jednak zgoła odmienna. Muszą oni bowiem stosować się do zapisów ustawy Prawo zamówień publicznych (Dz. U. 2019 poz. 2019). A tu szczególnie elektryzujące są dwa zapisy.
Na początek zastanówmy się nad treścią art. 99 ust.4:
“Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.”
Czytając powyższy zapis pobieżnie moglibyśmy dojść do wniosku, że opis przedmiotu zamówienia eliminuje z postępowania tych wykonawców, którzy nie dysponują (nie pracują) w konkretnym oprogramowaniu. Zgodnie ze stanowiskiem UZP, wyrażonym na stronie internetowej Urzędu nie jest to jednak wystarczające:
“(…) określenie [przedmiotu zamówienia] w sposób obiektywny, z zachowaniem zasad ustawowych, nie jest jednoznaczne z koniecznością zdolności realizacji zamówienia przez wszystkie podmioty działające na rynku w danej branży.”
Taka interpretacja skłania do dalszej analizy treści ustawy Prawo zamówień publicznych, konkretnie art. 99 ust. 5:
“Przedmiot zamówienia można opisać przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli zamawiający nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”.”
Czy to więc oznacza, że jednak można wskazać, że wykonawca ma dostarczyć zamawiającemu projekt wykonany w konkretnym oprogramowaniu? Nie do końca. Po pierwsze: ze świecą szukać zapisów dot. zakresu równoważności, a te – zgodnie z treścią Informatora Urzędu Zamówień Publicznych Nr 4/2020 – są niezbędne, aby zamawiający mógł skorzystać z “furtki”, jaką otwiera przytoczony zapis Pzp. Co więcej, poza cechami pożądanymi, zamawiający powinien także wskazać te niepożądane, co zdarza się jeszcze rzadziej.
Po drugie, jak wskazano na stronie wprzetargach.pl:
“Uzasadnione potrzeby podmiotu zamawiającego mogą zatem usprawiedliwiać ograniczenie kręgu potencjalnych wykonawców oraz wpływać na zakres oferowanych przez nich usług, dostaw i robot budowlanych, o ile wynikają one z celu, dla którego podmiot zamawiający wszczyna określone postępowanie, a cel ten jest nakierowany na realizację tychże potrzeb i w żaden inny sposób nie może zostać osiągnięty (zasada proporcjonalności), zaś wymagania zamawiającego związane są z istotą przedmiotu zamówienia i jego indywidualnymi właściwościami pozwalającymi na osiągnięcie wskazanego wyżej celu (zob. KIO 2184/13).”
Jak wynika z powyższego prawnie poprawne ujęcie w opisie przedmiotu zamówienia wymagania dotyczącego wykorzystania w ramach jego realizacji konkretnego narzędzia jest zadaniem skomplikowanym i dość wymagającym, ale nie niemożliwym.
Czy jednak wysiłek włożony w opracowanie odpowiednich zapisów w ogóle ma sens? Po co inwestorowi/zamawiającemu narzędzie do PROJEKTOWANIA?
Jeśli pochylimy się nad obowiązkiem inwestora wskazanymi w Prawie budowlanym. Zgodnie z treścią 18 ust. 1:
“Do obowiązków inwestora należy zorganizowanie procesu budowy, z uwzględnieniem zawartych w przepisach zasad bezpieczeństwa i ochrony zdrowia, a w szczególności zapewnienie:
1) opracowania projektu budowlanego i, stosownie do potrzeb, innych projektów,
2) objęcia kierownictwa budowy przez kierownika budowy,
3) opracowania planu bezpieczeństwa i ochrony zdrowia,
4) wykonania i odbioru robót budowlanych,
5) w przypadkach uzasadnionych wysokim stopniem skomplikowania robót budowlanych lub warunkami gruntowymi, nadzoru nad wykonywaniem robót budowlanych
– przez osoby o odpowiednich kwalifikacjach zawodowych.”
Obiektywnie rzecz biorąc żadne z powyższych obowiązków nie wskazuje wprost na istnienie potrzeby dysponowania narzędziem do projektowania. Uzasadnia jednak stawianie wymagań w zakresie oprogramowania w odniesieniu do podmiotów, które będą realizować ww. zadania (oczywiście w zakresie adekwatnym do przedmiotu umowy, stopnia skomplikowania zamówienia itd.).
Można oczywiście tłumaczyć takie wymaganie możliwością przeglądu oraz – finalnie – dokonania odbioru przedmiotu zamówienia, ale format natywny nie jest jedynym, który daje sposobność na dopełnienie wspomnianych czynności. Poza formatami tradycyjnie wykorzystywanymi w procesach budowlanych (jak dwg i pdf) na uwagę zasługuje otwarty format wymiany danych BIM – mowa oczywiście o IFC. Jako jego zalety należy wskazać możliwość otwarcia w wielu narzędziach (w sporym zakresie – darmowych w komercyjnym użytku), niezależność od natywnego narzędzia wykorzystywanego przez autora projektu oraz powszechne zastosowanie. Nierzadko również CDE wykorzystywane w ramach projektu posiada możliwość obsługi tego formatu. W końcu – format ten zdecydowanie ogranicza możliwość wprowadzenia do projektu nieautoryzowanych przez autora projektu zmian, mogących potencjalnie mieć nawet tragiczne skutki, jeśli takie zmiany nie zostałyby zauważone.
Przy korzystaniu z formatów natywnych często podaje się także, że zawiera on znaczne ilości informacji, które stanowić mogą tajemnice przedsiębiorstwa wykonującego projekt. Do takich informacji należeć mogą wykorzystane w ramach pracy algorytmy lub rozszerzenia opracowane z wykorzystaniem API udostępnionego przez producenta oprogramowania i wszelkie inne usprawnienia, które budują przewagę technologiczną danej firmy, a których usunięcie mogłoby spowodować niepełne lub wadliwe działanie modelu natywnego.
Dodatkową trudność w wykorzystaniu modelu natywnego mogą powodować także ograniczenia samego narzędzia wykorzystanego do projektowania. Nie jest tajemnicą, że producenci programów, próbując nieco “wymusić” na użytkownikach ciągłą aktualizację oprogramowania czasem ograniczają kompatybilność różnych wersji swoich produktów. Takie działanie powoduje, że dysponując modelem wykonanym np. w wersji Revit 2021 nawet otwarcie go w wersji 2022 naraża użytkownika na wystąpienie błędów, które wcześniej nie występowały. Na wielu blogach czy forach dotyczących Revita można przeczytać, że tego typu zabiegi mogą skutkować błędami. Przyczynę w prosty sposób wyjaśnia pani Agnieszka Zakrzewska-Kowalska na cgwisdom.pl:
“Jak wiadomo, każdy program posiada jakąś bazę danych, utworzoną na zasadzie „tabelki” zawierającej wiersze i kolumny. W starszych wersjach ta baza danych była mniejsza w stosunku do nowych wersji. W dodatku z każdą nową wersją programu, oprócz samej ilości danych zmienia się sposób ich segregacji, tzn. że pewne dane są przypisywane do innych miejsc w „tabeli” w systemie.”
To w przypadku Revit najczęściej skutkuje brakiem lub błędnym odczytem rodzin, błędami w wyświetlaniu szablonów, opisów i innych elementów modelu natywnego.
Zapewnienie tej samej jakości w kolejnych wersjach modelu wymaga więc analizy i nierzadko wprowadzenia odpowiednich korekt, które nie są ujęte w typowo stosowanych zapisach dot. przekazania praw autorskich do projektu (w tym do modelu).
Rozwiązaniem może być zaniechanie aktualizacji (co uchroni od wyżej wymienionych problemów), jednak postępując w ten sposób narażamy się na ryzyko bezpowrotnej utraty danych zawartych w pliku natywnym. Wynika to z braku wsparcia dla starszych wersji oprogramowania, o czym informuje sam Autodesk na swojej stronie internetowej:
“Subscribers to the Revit product receive access to the current version plus the three versions prior. Up to five versions prior can be retrieved through the Autodesk Virtual Assistance (AVA).”
PL: Subskrybenci produktu Revit otrzymują dostęp do bieżącej wersji oraz trzech wcześniejszych. Za pośrednictwem usługi Autodesk Virtual Assistance (AVA) można pobrać do pięciu wcześniejszych wersji.
Oznacza to, że po pięciu latach (wersje wydawane są co roku) tracimy możliwość otwarcia pliku nie tylko w jego “naturalnym” środowisku, a także w ogóle. Taki sam skutek zapewne miałoby całkowite przebudowanie programu, np. celem zwiększenia jego wydajności, jak miało to miejsce w przypadku AutoCAD wiele lat temu, kiedy plików zapisanych w kilkuletnich wtedy wersjach programu nie dało się w ogóle otworzyć.
Niestety niewielu inwestorów jest świadoma tych problemów i ich konsekwencji. Model natywny w dość powszechnym mniemaniu uchodzi za produkt, który zapewnia trwały dostęp do danych opracowanych przez projektanta. Czy jednak słusznie jego rola jest oceniana tak wysoko? To oczywiście w dużej mierze zależy od technicznych uwarunkowań konkretnego oprogramowania ale należy mieć na uwadze, że wspomniane problemy dotyczą każdego z narzędzi. Taka jest cena ich rozwoju.
Karolina Wróbel
M.A.D. Engineers
