Podniesienie poziomu cyfryzacji wymaga zmian.
Żadna zmiana nie przychodzi bez dodatkowych kłopotów i wysiłku.
Unikalne kodowanie obiektów daje wiele możliwości, ale ma też wymagania do sprostania.
W moim ostatnim artykule przedstawiłem korzyści płynące z przejścia na wyższy poziom i przypisania każdemu obiektowi unikalnego kodu klasyfikacji.
Dziś chciałbym skupić się na drugiej stronie – wyzwaniach i dlaczego nie przychodzi to bezproblemowo. Dzięki temu będziesz miał pełny obraz do oceny.
Wyzwania pojawiają się w każdej fazie projektu, więc omówię je w kolejności. Na koniec podam kilka wskazówek, jak sobie z nimi radzić i moją osobistą opinię na temat całego procesu.
Spis treści
Wyzwania podczas projektowania
Pierwszym wyzwaniem jest stworzenie wartościowych klasyfikacji.
Projekt wykonawczy to czas, w którym wzbogacamy modele o większość danych i w którym stale zachodzą zmiany. Jest to również etap, na którym projektanci tworzą pełny kod klasyfikacyjny – tuż przed przygotowaniem modelu do budowy.
Jest to również etap, na którym oprogramowanie projektowe pokazuje swój zupełny brak wspierania użytkowników w tworzeniu wysokiej jakości danych.
To ostre słowa. Pozwól, że to rozwinę.
Znam dwa podejścia do tworzenia kodów klasyfikacyjnych:
- Tworzenie pełnego ciągu klasyfikacyjnego jako jednej właściwości obiektu.
- Podzielenie kodu na wiele logicznych części (zdefiniowanych przez klasę obiektu, system, typ, instancję itp.) i utworzenie właściwości złożonej.
Oba te sposoby zawodzą, gdy są stosowane w całym procesie.
Nie dlatego, że metody są wadliwe. Ale dlatego, że zbyt łatwo jest popełnić błąd.
Wartości tych właściwości muszą być wypełniane ręcznie ( co jest podatne na błędy) lub za pomocą skryptu (co jest skomplikowane). Nie ma możliwości automatycznego generowania wartości wewnątrz środowiska oprogramowania.
Ostatecznie projektanci, z których wielu po raz pierwszy pracuje z unikalnym kodowaniem obiektów, muszą albo ręcznie pisać długie kody właściwości, albo postępować zgodnie ze skomplikowanymi procedurami skryptów opracowanymi przez kogoś, kto może być tylko częściowo zaangażowany w ich projekt.
Wszystko to skutkuje błędnym projektem i eksportem IFC. To prowadzi nas do kolejnego wyzwania.
Wyzwania podczas koordynacji
Modele IFC są eksportowane i czekają na kontrolę kolizji i walidację danych, zanim zostaną przeniesione na plac budowy. Zadaniem BIM Koordynatorów jest dostosowanie modelu do wymagań określonych w EIR. Unikalne kody i klasyfikacje obiektów to kolejny zestaw danych, który musi być sprawdzany i zarządzany. Stąd wyzwania.
Więcej walidacji danych
Posiadanie większej liczby wymaganych pól danych oznacza włączenie ich do procesu BIM Koordynacji. Walidacja danych również może nie być tak prosta, jak się wydaje. Wiele popularnych programów do koordynacji BIM świetnie nadaje się do sprawdzania kolizji, ale brakuje im podstawowych funkcji walidacji danych (tak, mówię o Navisworks).
Ponieważ wartości klasyfikacji nie są ani danymi liczbowymi, ani logicznymi, ale tekstem, nie jest łatwo sprawdzić, czy są one poprawne. Najłatwiej byłoby utworzyć inteligentną regułę REGEX, ale nie widziałem jeszcze oprogramowania do sprawdzania poprawności danych, które by to obsługiwało.
Dlatego należy utworzyć zestaw reguł sprawdzania poprawności danych, które uwzględnią wszystkie możliwości.
Utrzymanie jakości danych
Jedna udana kontrola danych nie wystarczy. Kody są złożone i z tego powodu trudno jest utrzymać ich jakość podczas długiego procesu projektowania i budowy.
Widzę trzy atrybuty jakości danych (dowiedz się, co to jest), które mogą być szczególnie trudne do utrzymania w dłuższej perspektywie: format, spójność i unikalność.
Format
Nazwa klasyfikacji | Numer klasyfikacji |
---|---|
Uniclass 2015 | Ss_65_80_37: Air handling units. |
Omniclass | 23 37 13 13: Modular indoor air handling units. |
Norwegian TFM | 360.001: Ventilation system. |
IVZ.001: Air handling units (Components). | |
Swedish Coclass | VVS.30.AC: Air handling units (Functional System). KP.CD.AC: Air handling units (Components). |
CCI Classification | M-31.60.10: Air handling units (Mechanical Systems → HVAC Systems → Air Distribution Equipment). |
Przykładowe wartości klasyfikacji dla centrali wentylacyjnej. Ponieważ nie znam ich wszystkich, ChatGPT pomógł mi z przykładami, więc mogą wystąpić błędy.
Spójność
Spójność danych oznacza, że te same dane reprezentują informacje w różnych systemach. Weźmy przykładową wartość klasyfikacji M-31.60.10 z powyższej tabeli. Opisuje ona centralę wentylacyjną i kod ten musi być dokładnie taki sam w każdym modelu, oprogramowaniu FM, bazie danych, schemacie systemu i dokumentacji serwisowej. Ten sam numer jest również zapisany na tabliczce znamionowej elementu zamontowanego na urządzeniu.
A ponieważ mamy tak wiele różnych i oddzielonych od siebie silosów informacji, trudno jest nimi zarządzać i mieć wszystko zsynchronizowane przez cały czas.
Unikalność
Wyzwania podczas budowy
Na etapie budowy kody są już utworzone i zatwierdzone. Dlatego wykonawcy używają ich do wielu celów:
- Zamawianie materiałów
- Sprawdzanie wymagań dotyczących elementów
- Dostarczanie dokumentacji materiałowej (jeden zestaw dokumentów może być przypisany do różnych kodów obiektów)
- Tworzenie tabliczek znamionowych do umieszczenia na elemencie na miejscu.
Widzę dwa główne wyzwania związane z używaniem unikalnych kodów obiektów na placu budowy:
- Błędna pisownia lub błędne umieszczenie tabliczki znamionowej z kodem
- Późne zmiany w projekcie
Pierwszy z nich wynika z braku zrozumienia kodowania. Kiedy chodziłem po placu budowy, spotykałem się z tym, że tabliczka znamionowa jest albo zainstalowana na innym elemencie niż powinna, albo jest jakąś skróconą wersją tego, czym powinna być. Albo w ogóle jej nie ma.
Zamawiający wymaga prawidłowej tabliczki znamionowej na określonych elementach, więc ostatecznie jest to kolejny punkt na liście kontrolnej, który kierownik budowy musi zweryfikować, akceptując zakres prac wykonawcy.
Jednak zdecydowanie największym wyzwaniem na tym etapie są późne zmiany projektowe. Ma to wpływ na każdy etap procesu budowlanego.
- Zamówienia są realizowane według numeru klasyfikacji – jeśli numer zostanie usunięty lub zmieniony – może to skutkować dostarczeniem nieprawidłowych materiałów na plac budowy.
- Produkty są przypisane do kodów. Dlatego akceptacja produktów odbywa się poprzez kody klasyfikacyjne. Jeśli element zmieni kod – wypada z pętli, powodując opóźnienia.
- Dokumentacja jest powiązana z kodami lokalizacji, typu i instancji – zmiana lub usunięcie kodu skutkuje brakiem dokumentacji MOM.
- Wreszcie najbardziej uciążliwe – jeśli zmiana nastąpi tak późno, że element jest już zamontowany na miejscu z tabliczką znamionową – należy wyprodukować i zainstalować kolejną. A to już dużo dodatkowej pracy!
Istniejące rozwiązania
Projektowanie
Nie możemy wiele zrobić z samym oprogramowaniem do modelowania. Możemy jednak spróbować wesprzeć lub zwiększyć ich możliwości. Korzystanie z rozwiązań firm trzecich może zwiększyć niezdolność do kontrolowania jakości właściwości klasyfikacji.
Głównym wyzwaniem jest tworzenie prawidłowych i unikalnych kodów klasyfikacyjnych. Jest na to kilka rozwiązań. Widzę dwa wykonalne:
- Stworzenie skryptu, który koduje typy zgodnie z ich kategorią, a następnie nadaje każdej instancji w ramach typu unikalny numer.
- Korzystanie z oddzielnego oprogramowania bazy danych do tworzenia i zarządzania kodami (z zachowaniem unikalności) i wysyłania kodów do oprogramowania do modelowania. Poprzez API lub inny import (w zależności od wybranego oprogramowania).
Koordynacja
Aby zminimalizować dodatkowy czas poświęcany na sprawdzanie kodowania obiektów, zalecałbym korzystanie z jak największej liczby szablonów i konfigurowanie zautomatyzowanych procesów sprawdzania.
Istnieją również możliwości monitorowania spójności danych poprzez połączenie bazy danych kodowania i modeli IFC w jeden dashboard. Połączenie na żywo ze wszystkimi źródłami może być trudne, ale istnieje możliwość zasilania PowerBI regularnie generowanymi eksportami Excel.
Budowa
Największą obawą i czynnikiem destrukcyjnym są zmiany. Musimy odzyskać kontrolę nad procesami zmian krytycznych danych.
Mając to na uwadze, sugerowałbym zmianę procesu – po wykonaniu projektu i utworzeniu unikalnego kodu, ustanowienie sztywnego reżimu zmian i zezwolenie tylko kilku osobom w organizacji na zmianę tego, co zostało ustalone.
Zdaję sobie sprawę, że stanowiłoby to wąskie gardło we wdrażaniu ważnych i uzasadnionych zmian. Ale dzięki takiemu ograniczeniu moglibyśmy zawęzić zmiany do absolutnej konieczności. A uważam, że późne zmiany są największym zagrożeniem dla harmonogramu projektów i wyników finansowych.
Moja opinia
Powiedziawszy to wszystko o możliwościach (poprzedni wpis), ale także o wyzwaniach i istniejących rozwiązaniach, pozwolę sobie na kilka osobistych refleksji.
Uważam, że zarówno dostępne rozwiązania programowe, jak i zrozumienie tej kwestii, nie są wystarczająco dojrzałe, aby czerpać korzyści z unikalnego kodowania w zarządzaniu obiektami.
Mówiąc bardziej szczegółowo:
Oprogramowanie
Aby zarządzać procesem budowy, zespół potrzebuje 50 lub więcej różnych programów, z których połowa często przenika się nawzajem. Aby zarządzać kodowaniem obiektów, musisz upewnić się, że wszystkie komponenty są przez cały czas zsynchronizowane.
To niemożliwe.
Większość oprogramowania nie komunikuje się ze sobą – jesteś skazany na eksport i import z Excela. Wymaga to mnóstwa skryptów lub pełnoetatowego stanowiska, które zajmuje się tylko ręczną synchronizacją.
Moim zdaniem oprogramowanie, którego używamy w naszej branży, nie jest wystarczająco dobre, jeśli chodzi o zarządzanie danymi i ich interoperacyjność.
Czynnik ludzki
Unikalne kodowanie to proces wymagany przez niektórych właścicieli budynków od zaledwie kilku lat. Nie jest to standard branżowy. Jeśli nie jest to wymagany standard, wielu nie zadaje sobie trudu, aby być na bieżącoi i po prostu nie jest przyzwyczajonych do unikalnego kodowania i rygorystycznych procesów, których wymaga.
Może być też tak, że po prostu nie znam lepszego procesu do zarządzania tym wszystkim w bardziej płynny sposób. Jeśli Ty znasz – daj mi znać w komentarzu lub wyślij nam maila!