Czy kiedykolwiek zastanawiałeś się, dlaczego pomimo gwałtownego wzrostu ilości danych cyfrowych w zarządzaniu informacjami o projektach budowlanych, zrozumienie tych danych przez interesariuszy wydaje się stale maleć?
Podstawowa przyczyna: silosy informacyjne, które fragmentują zarządzanie informacjami w projektach budowlanych na każdym etapie.
Table of Contents
Paradoks danych: wzrost a zrozumienie
Przez cały cykl życia projektów budowlanych zarządzanie informacjami stoi przed paradoksalnym wyzwaniem:
- Produkcja danych cyfrowych rośnie wykładniczo
- Sensowna interpretacja informacji dramatycznie spada
- Interesariusze projektu mają trudności z utrzymaniem kompleksowego zarządzania informacjami w projektach budowlanych.
Zjawisko to zostało trafnie zilustrowane w badaniu, które pokazuje wyraźny spadek zrozumienia informacji wraz z przejściem do każdej fazy projektu.
Dlaczego informacje są tracone i dlaczego jest to problem?
Nie każda utrata danych jest szkodliwa. Niektóre informacje w naturalny sposób stają się archiwalne w miarę rozwoju projektu. Jednak skala erozji wiedzy jest często znacznie większa niż to jest uzasadnione.
Dlaczego zarządzanie informacjami w projektach budowlanych konsekwentnie kończy się niepowodzeniem? Wyłania się kilka krytycznych czynników:
- Zmieniające się składy zespołów
- Różne zespoły obsługują różne fazy projektu
- Podczas gdy niektóre role (np. architektów) pozostają niezmienne, wiele zespołów odchodzi w trakcie trwania projektu.
- Nowi członkowie zespołu dołączają później, wnosząc różne perspektywy.
- Nieciągłość oprogramowania
- Wczesne etapy projektu opierają się w dużej mierze na narzędziach do tworzenia BIM.
- Fazy budowy polegają na przeglądarkach i rozwiązaniach mobilnych
- Inne etapy opierają się na jeszcze innych narzędziach lub arkuszach kalkulacyjnych
- To przejście tworzy bariery w dostępie do zintegrowanych informacji
- Zmiana obszarów zainteresowania Każdy etap projektu ma odrębne cele:
- Planowanie: Funkcja
- Projektowanie: Kształt i forma
- Budowa: Detale i materiały
- Zarządzanie obiektem: Konserwacja i eksploatacja
Praktyczny przykład: Instalacja sprzętu medycznego
Etap 1: Planowanie urządzeń medycznych
Etap 2: Projekt
Etap 3: Budowa
Etap 4: Zakupy
Etap 5: Montaż i testowanie
Etap 6: Zarządzanie obiektem
Proponowane rozwiązania
Aby ograniczyć utratę informacji i usprawnić zarządzanie informacjami w projektach budowlanych, zalecam:
- Ulepszoną cyfryzację
- Wyjście poza samo posiadanie danych cyfrowych
- Zapewnienie dostępu do danych odpowiednim interesariuszom
- Połączenie silosów
- Tworzenie płynniejszych przejść między etapami projektu
- Minimalizacja fragmentacji danych
- Kompleksowa historia danych
- Prowadzenie rejestru decyzji, notatek i zmian
- Zapewnienie kontekstu dla nowych członków zespołu
Jak możemy to zrobić?
Najlepiej byłoby to osiągnąć bez konieczności wprowadzania zbyt wielu zmian w naszych obecnych praktykach.
Używaj podobnych procesów.
Korzystaj z tego samego oprogramowania.
Czy to w ogóle możliwe?
Tak.
Musimy spojrzeć na tę ciągłość z perspektywy danych.
Wróćmy do przykładu sprzętu i przeanalizujmy jego ścieżkę przepływu informacji:
- Najpierw jest on tworzony w bazie danych (lub Excelu) z pewnymi informacjami o wymaganiach
- Następnie projektant modeluje urządzenie w oprogramowaniu BIM.
- Na placu budowy istnieje on w modelu IFC, rysunku i specyfikacji technicznej dostępnej dla zespołu odpowiedzialnego za dany zakres prac.
- W przypadku zamówień istnieje w innym arkuszu kalkulacyjnym lub dedykowanym oprogramowaniu.
- Montaż i testowanie – kolejna lista kontrolna w celu sprawdzenia, czy sprzęt został dostarczony i czy działa prawidłowo.
- Dokumentacja powykonawcza nadal działa jako folder z plikami pdf, wykresami i schematami opisującymi dany typ sprzętu.
Czy widzisz tutaj wątek?
Te same lub podobne dane wędrują z jednego oprogramowania do drugiego. Możemy to połączyć za pomocą nici.
Unikalny znacznik obiektu.
Coś takiego jak opisałem tutaj.
Dlaczego miałoby to pomóc?
Ponieważ możemy traktować tę wartość jako klucz pierwotny i wyszukiwać wymagane informacje z innych źródeł danych.
Tak jak działa to w relacyjnych bazach danych.
Relacyjna baza danych i kardynalności
To, co chcemy osiągnąć, to możliwość płynnego importowania lub doszukiwania danych z jednego źródła do drugiego i prawidłowego kojarzenia tych samych obiektów z różnych źródeł. Aby to osiągnąć, musimy wykorzystać posiadane zbiory danych w sposób umożliwiający tworzenie relacji między nimi.
Zrobiłem już pewne wprowadzenie do tego, czym są bazy danych i wyjaśniłem kilka prostych terminów. Można to znaleźć tutaj.
Kolejnym tematem w świecie baz danych są relacje i ich kardynalność.
Kardynalność w relacyjnych bazach danych odnosi się do relacji liczbowych między jednostkami w różnych tabelach. Określa ona, ile wystąpień jednego obiektu może być powiązanych z wystąpieniami innego.
Kluczowe typy kardynalności to:
- One-to-One (1:1): Każdy rekord w tabeli A odnosi się do dokładnie jednego rekordu w tabeli B i odwrotnie. Na przykład, każdy budynek ma dokładnie jeden numer pozwolenia na budowę, a każdy numer pozwolenia na budowę należy tylko do jednego budynku.
- One-to-Many / Many-to-One (1:*/ *:1): Pojedynczy rekord w tabeli A może odnosić się do wielu rekordów w tabeli B, ale każdy rekord w B odnosi się tylko do jednego rekordu w A. Na przykład wiele pokoi znajduje się na jednym piętrze budynku.
- Many-to-Many (*:*): Wiele rekordów w tabeli A może odnosić się do wielu rekordów w tabeli B. Ta relacja wymaga pośredniej tabeli łączącej. Na przykład, wielu wykonawców może pracować nad wieloma projektami. Wykonawca może być przypisany do kilku projektów budowlanych, a każdy projekt może zatrudniać wielu wykonawców.
Aby uzyskać wyczerpujące wyjaśnienie zarówno kardynalności, jak i kluczy, możesz odwiedzić artykuł Database.Guide na temat relacji w bazie danych.
Właściwości klucza pierwotnego w BIM
Skupiając się jednak na naszym przykładzie ścieżki dla danych obiektów na wszystkich etapach projektu. Aby móc zachować informacje, musimy ustanowić możliwość wymiany danych obiektów między różnymi programami. W każdym projekcie wykorzystywanych jest wiele różnych programów.
Jak to działa
- Ustalenie spójnego identyfikatora podczas wczesnego planowania
- Przeniesienie tego identyfikatora przez projektowanie, budowę, zakupy i zarządzanie obiektem
- Umożliwienie płynnego wyszukiwania i kojarzenia danych
Gdzie szukać kardynalności i identyfikatorów?
We właściwościach obiektów.
Jednak różne przypadki użycia i oprogramowanie opierają się na różnych właściwościach, których możemy użyć jako klucza pierwotnego. Zajmiemy się tym szczegółowo w następnym artykule.
Przyjrzyjmy się teraz, jak może wyglądać potencjalny przepływ pracy:
- Planowanie obiektu w bazie danych z unikalnym kluczem
- Przeniesienie klucza do oprogramowania projektowego
- Eksport do IFC na plac budowy – wartość klucza znajduje się we właściwościach IFC.
- W przypadku systemów zakupowych należy użyć tego samego klucza do zebrania danych zarówno z oprogramowania do planowania, jak i modeli.
- Uwzględnienie klucza w listach kontrolnych dostawy i testowania
- Jeśli dokumentacha powykonawcza jest w folderach – nadaj mu nazwę klucza pierwotnego. Jeśli w oprogramowaniu – użyj klucza ustalonego w modelu i innych bazach danych.
Jak widać mamy pełne dane i wiedzę dostępną przez cały proces budowy dla każdego obiektu, który podąża tą ścieżką.
Podsumowanie
Traktując dane projektowe jako ciągły, wzajemnie połączony ekosystem, możemy znacznie usprawnić zarządzanie informacjami w projektach budowlanych. Celem nie jest tylko zachowanie danych, ale stworzenie płynnego mechanizmu transferu wiedzy na wszystkich etapach projektu.
W następnym artykule przedstawię konkretne przykłady implementacji unikalnych kluczy obiektów na różnych platformach oprogramowania.
