Wymagania do platformy CDE, które działają – nie tylko na papierze

Wymagania do platformy CDE w większości dokumentów przetargowych wyglądają podobnie: długa lista funkcji, kilka wymagań bezpieczeństwa, wzmianka o modelu SaaS i języku polskim, zgodnie ze standardem opisanym choćby przez buildingSMART. Łatwo wtedy potraktować taką listę jak checklistę do odhaczenia. W rezultacie jednak odhaczona checklista i system, z którym da się realnie pracować, to dwie zupełnie różne rzeczy.

Ten artykuł pokazuje, jak przejść od listy formalnych wymagań przetargowych do wymagań systemu, którego Twój zespół faktycznie będzie używał. Materiał powstał na podstawie rozmów i dokumentów przetargowych zebranych w ramach procesu ofertowego na przestrzeni ostatnich kilku miesięcy.

1. Im dłuższa lista wymagań CDE, tym gorsza umowa

1.1 Jak wygląda wybór platformy CDE w praktyce

Kiedy generalny wykonawca przygotowuje się do przetargu, kompletuje potrzebne dokumenty i weryfikuje, czy obecne rozwiązanie CDE spełnia wymagania. Jeśli nie spełnia – zaczyna poszukiwania nowego dostawcy. Wówczas uwaga naturalnie przenosi się na porównywanie ofert.

Wyszukuje potencjalnych dostawców, kontaktuje się z nimi i porównuje ich systemy z wymaganiami z przetargu. W tym momencie jego uwaga skupia się bardziej na pytaniu „co system ma mieć?”, niż na „co system ma robić dla mnie?”. Jest to subtelna, ale kluczowa różnica – i jedna z najczęstszych pułapek przy wyborze platformy CDE.

1.2 Skąd się bierze ta pułapka?

Każda funkcja na liście wymagań jest opisana jednym, krótkim zdaniem. W konsekwencji takie zdanie nie mówi nic o tym, jak dana funkcja faktycznie działa. Jeśli oprogramowanie „ma” wszystko z listy, łatwo założyć, że będzie dobre. W praktyce poszczególne funkcje to jednak tylko narzędzia – celem wdrożenia oprogramowania jest usprawnienie procesów, nie samo posiadanie funkcji.

1.3 Przykład: proces akceptacji dokumentów

Omówmy to dokładnie na przykładzie popularnej funkcji „proces akceptacji dokumentów” (ang. document acceptance process). Z jednej strony pod tym krótkim opisem może kryć się prosty proces, w którym dokumenty są zatwierdzane kolejno, jeden po drugim, całkowicie manualnie i bez wsparcia dodatkowych mechanizmów automatyzacji.

Z drugiej strony może to być system, w którym kilka osób opiniuje dokument równolegle, a jeśli ktoś nie zdąży w terminie, automatycznie wyświetla się komunikat wszystkim decydentom – a całość jest zapisana w jednym, czytelnym widoku historii. Co istotne, oba rozwiązania spełniają to samo, jednozdaniowe wymaganie – mimo że jedno jest wielokrotnie bardziej zaawansowane od drugiego.

Proces akceptacji dokumentów – zapis z OPZ a wymaganie systemowe

1.4 Zmiana podejścia do definiowania wymagań

Przede wszystkim zmień nastawienie do oprogramowania. Celem aplikacji jest służyć ludziom, automatyzować i porządkować pracę – nie być podkładką na potrzeby przetargu. Zamiast pytać „czy system ma tę funkcję?”, zapytaj „jak ta funkcja zadziała w moim konkretnym procesie?”. Innymi słowy, zamiast listy pięćdziesięciu krótkich punktów wystarczy, że określisz dziesięć punktów z definicją tego, co oznacza spełnienie każdego z nich.

Czy widzisz różnicę?

2. Wymagania funkcjonalne CDE – co system ma robić

Żeby nie być gołosłownym, poniższa analiza opiera się na realnych dokumentach: opisach przedmiotu zamówienia, specyfikacjach warunków zamówienia, załącznikach do umów wdrożeniowych i zapytaniach ofertowych. Dominuje przy tym branża budowlana, jednak materiał pochodzi z różnych modeli kontraktowych i różnej skali inwestycji.

2.1 Wymagania funkcjonalne platformy CDE

Po analizie dokumentów, w sekcji OPZ dotyczącej oprogramowania i platformy CDE niemal zawsze pojawiają się poniższe funkcje:

• Wersjonowanie dokumentów – i pełna historia rewizji
• Konfigurowalny proces akceptacji – i zatwierdzania dokumentów
• Zarządzanie uprawnieniami i rolami – użytkowników
• Filtrowanie i wyszukiwanie – dokumentów po metadanych
• Rejestr korespondencji – pisma, notatki, protokoły przekazania, odpowiedzi
• Powiadomienia e-mail – o zmianach statusów, terminach i zadaniach
• Raporty, zestawienia i dashboardy

2.2 Funkcje, które pojawiają się rzadziej

Rzadziej, ale też regularnie, pojawiają się:

• Aplikacja mobilna – do zgłaszania usterek i zdarzeń na budowie
• Moduł kart materiałowych – składanie, opiniowanie i zatwierdzanie
• Automatyczne protokoły – przekazania dokumentacji
• Obsługa modeli BIM 3D – koordynacja w formacie IFC
• Rejestr aktywów – powiązany z dokumentacją techniczną
• Walidacja kompletności i jakości danych – przed przekazaniem

2.3 Przykład: czego nie mówi Ci nazwa funkcji

Każda z funkcji z pierwszej listy jest na tyle ogólna, że występuje w większości produktów dostępnych na rynku. Sama jej obecność na liście nic Ci nie powie – wartość jest widoczna dopiero w działaniu. Weźmy na przykład „wersjonowanie dokumentów i pełną historię rewizji”. Każdy dostawca powie, że to ma. Jednak co to naprawdę oznacza w codziennej pracy?

Czy każda nowa wersja dokumentu zastępuje poprzednią w widoku głównym, a stare wersje trzeba świadomie odszukać w historii? A może system wyraźnie oznacza, która wersja jest aktualna, a które są archiwalne – widoczne dla każdego, bez dodatkowych kliknięć? Ponadto – czy można porównać dwie wersje obok siebie, czy trzeba je pobrać i otworzyć osobno? „Wersjonowanie dokumentów” w jednym zdaniu mieści wszystkie te warianty. Innymi słowy, dopiero opis tego, jak funkcja ma działać w codziennej pracy, odróżnia produkty od siebie.

3. Bezpieczeństwo, standardy i wsparcie – wymagania CDE w przetargu

Oprócz funkcji, każdy dokument przetargowy zawiera wymagania dotyczące bezpieczeństwa danych, zgodności ze standardami oraz wdrożenia i wsparcia. Każdy z tych obszarów wymaga sprawdzenia czegoś innego u dostawcy – i każdy ma swoje typowe pułapki.

3.1 Wymagania bezpieczeństwa danych w CDE

Ten obszar jest w dokumentach stosunkowo dobrze opisany – prawdopodobnie dlatego, że działy IT i prawne mają tu wyrobione zdanie. Standardowy zestaw wygląda następująco:

• Hosting danych wyłącznie w UE
• Minimum dwa redundantne centra – przetwarzania danych
• Certyfikat ISO 27001 – potwierdzony niezależnym audytem
• Uwierzytelnianie dwuskładnikowe (2FA)
• Dostęp wyłącznie po zalogowaniu
• Rejestr aktywności użytkowników
• Dostępność 24/7 – z zdefiniowanym SLA

3.2 ISO 27001 i ISO 19650 – jakie standardy wymaga rynek

To obszar, który najwyraźniej odróżnia GW początkujących w temacie CDE od tych, którzy mają już za sobą kilka wdrożeń. Podstawowy poziom to ISO 27001 – opisany wyżej, w kontekście bezpieczeństwa danych. Pojawia się powszechnie.

3.3 ISO 19650 jako wyższy poziom wymagań

Wyższy poziom to ISO 19650 – norma zarządzania informacją w środowisku BIM. Określa ona, jak informacja powinna być tworzona, weryfikowana, zatwierdzana i archiwizowana w projektach budowlanych, wyróżniając przy tym cztery obszary robocze: prace w toku, informacje udostępnione, informacje zatwierdzone i archiwum. ISO 19650 pojawia się rzadko – jednak tam, gdzie się pojawia, cały dokument przetargowy jest jakościowo inny.

3.4 Co warto zrobić już teraz

Nawet jeśli ten konkretny przetarg nie wymaga formalnej certyfikacji ISO 19650, warto sprawdzić, czy soft, który wybierasz, obsługuje logikę pracy zgodną z tą normą. Przede wszystkim zabezpiecza Cię to na przyszłość – jeśli w kolejnym przetargu ISO 19650 będzie już wymogiem, nie będziesz musiał zaczynać poszukiwań od nowa.

3.5 Wdrożenie, szkolenia i wsparcie – wymagania dodatkowe

Wdrożenie, szkolenia i wsparcie to obszar, który w dokumentach przetargowych bywa traktowany jako dodatek. W praktyce decyduje o tym, czy system będzie faktycznie używany, czy tylko istniał na papierze. Najczęściej w OPZ są opisane zaledwie jednym słowem. Warto jednak poruszyć te tematy podczas rozmowy z dostawcą:

• Czas realizacji wdrożenia z kamieniami milowymi – nie „do 3 miesięcy”, ale konkretny harmonogram z datami i warunkami odbioru
• Szkolenia dla wszystkich ról – administratorzy, koordynatorzy, wykonawcy, podwykonawcy; odrębnie, nie jedno szkolenie dla wszystkich
• Wsparcie techniczne w języku polskim – z zdefiniowanym czasem reakcji
• Możliwość rekonfiguracji w trakcie umowy – bez konieczności programowania i bez dodatkowych kosztów

3.6 Co pojawia się zbyt rzadko

• Jasność co do gwarancji cen i zakresu usług – na cały okres trwania umowy, nie tylko w pierwszym roku
• Możliwość regularnego, samodzielnego eksportu danych – jako rutynowa opcja w trakcie trwania umowy, nie tylko na wypadek końca współpracy

3.7 Dlaczego to nie jest kwestia funkcji systemu

To nie jest kwestia funkcji systemu, lecz tego, jak zmieniają się warunki w projekcie trwającym kilka lat. W konsekwencji większość GW odkrywa te pytania dopiero wtedy, gdy ceny już wzrosły albo support już się skurczył.

4. Dostęp do dokumentacji CDE po zakończeniu projektu

4.1 Dlaczego to ważne

Projekt się kończy, budowa jest oddana do użytku, umowa z GW się rozlicza. Wówczas pojawia się pytanie: gdzie jest cała dokumentacja – projektowa, wykonawcza, powykonawcza, korespondencja, historia decyzji? Co ważne – czy inwestor może do niej dotrzeć bez udziału kogokolwiek innego?

Inwestor potrzebuje dokumentacji do eksploatacji budynku, gwarancji, ewentualnych przeglądów czy remontów – często przez wiele lat po zakończeniu inwestycji. Z kolei GW może potrzebować dostępu do tych samych danych krócej, na przykład do obrony przed roszczeniami czy rozliczeń. Co istotne, po zakończeniu projektu GW zwykle nie ma już powodu utrzymywać platformy. Problem w tym, że ten temat rzadko jest opisany wprost w wymaganiach przetargowych.

4.2 Co warto wpisać do wymagań

Zamiast ogólnego „zapewnienia dostępu do danych”:

• Eksport dokumentacji wraz z metadanymi i strukturą katalogów – w formacie który da się otworzyć bez oprogramowania dostawcy (np. PDF, DWG, XLSX)
• Jasność czy eksport jest standardową funkcją platformy – dostępną z poziomu interfejsu, czy wymaga zgłoszenia i osobnej wyceny
• Termin realizacji eksportu na żądanie

4.3 Praktyczna rada

Nie czekaj z eksportem do końca projektu. Jeśli platforma pozwala na regularne pobieranie danych w trakcie trwania umowy, warto z tego korzystać okresowo – na przykład przy zamknięciu każdego etapu. Innymi słowy, to co masz już u siebie, jest pewne. Natomiast to, co „będzie dostępne po zakończeniu umowy”, zależy od wielu czynników, na które nie masz wpływu.

5. Jedno wymaganie, trzy zespoły – co naprawdę się zmienia

5.1 Kontekst użycia – dlaczego to samo wymaganie znaczy coś innego dla każdego

Stanowisko i charakter pracy wpływają na to, jak rozumiemy funkcje systemu – to jest kontekst użycia. Weźmy przykład z OPZ: „system musi zapewniać obsługę dużych plików CAD z możliwością podglądu oraz przeglądanie modeli w 3D”. Z perspektywy inwestora to jedno z wielu wymagań na liście – brzmi rozsądnie, koresponduje z tym, że projekt jest projektowany w BIM. Ale to samo zdanie oznacza coś innego dla każdej ze stron.

5.2 Strona GW – kierownicy i inżynierowie budowy

Dla kierowników i inżynierów budowy po stronie GW, którzy do tej pory korzystali tylko z papierowej dokumentacji i nigdy nie otwierali modelu 3D, samo „udostępnienie podglądu modelu 3D” niczego nie zmienia. Model będzie leżał na platformie, nieużywany – formalnie wymaganie spełnione, praktycznie bez znaczenia.

Na placu budowy oprogramowanie jest takim samym narzędziem jak wkrętarka – wymaga wprawy, doświadczenia i solidnego przeszkolenia. Warto przy tym pamiętać o sprzęcie, bo model 3D, żeby otwierał się płynnie, potrzebuje wydajnych smartfonów lub tabletów – nie najsłabszego modelu, który akurat był na stanie.

5.3 Strona projektanta

Projektanta zainteresuje bardziej, w jakiej formie i jakości będzie przekazywał modele. Czy aktualizuje model na platformie przy każdej rewizji, czy tylko na kluczowych etapach? Jeśli wymaganie nie precyzuje tego, projektant zrobi tak, jak mu wygodniej – co może nie być tym, czego inwestor faktycznie oczekiwał.

5.4 Strona inwestora

Dla inwestora to z kolei pytanie, co właściwie chce z tym robić. Czy model 3D ma służyć do weryfikacji zgodności wykonania z projektem, do koordynacji branż, a może do przyszłego zarządzania budynkiem? Jeśli odpowiedź brzmi „jeszcze nie wiem, ale warto to mieć” – wymaganie zostanie spełnione formalnie, a model nigdy nie zostanie użyty w sposób, który uzasadniałby jego utrzymywanie.

5.5 Jak lepiej sformułować wymagania CDE

Każde wymaganie funkcjonalne w OPZ jest jednocześnie instrukcją dla trzech zespołów, które będą musiały zmienić coś w swojej codziennej pracy – nawet jeśli to wymaganie wydaje się „tylko” dotyczyć systemu. Zanim wymaganie trafi do dokumentu, warto przejść przez nie z perspektywy każdej ze stron i zadać proste pytanie: co to oznacza dla codziennej pracy?

Jeśli odpowiedź dla projektanta, GW i zespołu inwestora brzmi „nic się nie zmienia, po prostu klikamy gdzie indziej” – wymaganie jest bezpieczne, ale prawdopodobnie też mało wartościowe. Z kolei gdy odpowiedź brzmi „musimy zmienić sposób, w jaki przekazujemy, odbieramy i sprawdzamy dokumentację” – to jest sygnał, że wymaganie jest realne i ma szansę coś zmienić. Co więcej, to też sygnał, że samo wpisanie go do OPZ nie wystarczy: kto po stronie każdego z trzech zespołów będzie odpowiedzialny za to, żeby ta zmiana faktycznie się wydarzyła?

5. Podsumowanie: jak przygotować wymagania dla platformy CDE, która naprawdę zadziała

Lista wymagań CDE z przetargu to punkt wyjścia, nie specyfikacja techniczna. Mówi Ci, jakie funkcje musi mieć soft, żeby formalnie przeszedł ocenę. Jednak nie mówi, jak te funkcje powinny działać, żeby Twój zespół chciał z nich korzystać. Podsumowując, warto zapamiętać trzy rzeczy z tego artykułu.

5.1 Rozpisz ogólne wymagania na scenariusze

Każde ogólne zdanie z listy – „wersjonowanie”, „proces akceptacji”, „wsparcie techniczne” – kryje w sobie rozwiązania bardzo różnej jakości. Dlatego zanim podpiszesz umowę z dostawcą, rozpisz najważniejsze punkty na konkretne scenariusze – tak jak zrobiliśmy to z procesem akceptacji dokumentów.

5.2 Sprawdź to, czego nie ma na liście

Ponadto część najważniejszych pytań nie pojawia się na liście w ogóle, bo dotyczy nie funkcji systemu, lecz warunków współpracy w czasie: czy ceny są gwarantowane na cały okres umowy, czy eksport danych jest realną, bieżącą opcją, czy dostęp do dokumentacji przetrwa zakończenie projektu.

5.3 Pamiętaj, że wymaganie to zmiana w pracy ludzi

Wreszcie, każde wymaganie to nie tylko zapis w systemie – to zmiana w pracy konkretnych ludzi: kierownika budowy, projektanta, inwestora. W rezultacie soft, który formalnie „ma” funkcję, ale nikt z niego nie korzysta, nie różni się niczym od softu, który tej funkcji nie ma.