Moje ulubione powiedzonko to że brak danych jest lepsze od złych danych. Jeżeli projekt ma stosować stworzone dane, dane te muszą zapewnić wartościowe i rzetelne dane dla wszystkich stron zaangażowanych w dany projekt. Dane o wysokiej jakości umożliwią płynny przepływ pracy, oraz szybsze podejmowanie decyzji. Z drugiej zaś strony, dane o niskiej jakości zapowiadają ciąg nieodpowiednich i niechcianych następstw i problemów przy naszym projekcie. Pozwól że zajmę się teraz tymi następstwami, które wg. mnie są najpowszechniejsze i sprawiają najwięcej kłopotów.
Kiedy ktoś nieustannie napotyka na nieprawidłowe dane, prowadzi to do dwojakich konsekwencji. Jeżeli dana osobie zależała od tych danych, to popełni błąd. Może to być błąd projektowy, który doprowadzi do czasochłonnego przeprojektowania, nieprawidłowy obmiar/kosztorysowanie, co doprowadzi do niekompletnego zamówienia, itd. Jeżeli zdarzy się to parę razy, to nastąpi utrata zaufania do danych. Wtedy osoba ta zacznie albo spędzać więcej czasu na kontrolę jakości danych, lub – co gorsze – stworzy swoje własne źródło danych (złamany atrybut unikatowości). W rezultacie dojdzie do utraty zaufania w pierwotne żródło danych, co doprowadzi do rzadszych aktualnień, a w ostatecznym rozrachunku zlikwiduje aktualność danych.
Jest to połączone z wymaganiami projektowymi. Jeżeli dane projektowe stanowią bazę do budowy, a właściwości obiektów nie są kompletne, kontrahent nie jest w stanie opracować prawidłowej kolejności elementów do zamontowania na budowie. Niekompletne dane stwarzają czynniki ryzyka – grupa kontrahentów zamawia materiały, które w ich opini są wystarczające (może się okazać że nie), podczas gdy inni mogą poprosić o informacje, co spowolni cały proces.
Mogą się pojawić duplikaty w obiektach modelu (dwie ściany umieszczone jedna na drugiej) lub we własciwościach (dwie właściwości z tą samą wartością). Pierwszy przypadek skutkuje złym przedmiarem oraz zamówieniem, drugi przypadek skutkuje cięższym modelem oraz nieprawidłowym zarządzaniem danych. Jeżeli duplikat właściwości jest używany jako dane wejściowe w innym miejscu, doprowadzi do dwuznaczności – ktorą właściwość powinienem użyć?
Właściciel budowy Uniwersyteckiego Szpitala w Stavanger ma wysokie wymagania odnośnie jakości etykietowania systemów technicznych na terenie budowy jak i w modelu. System ten opiera sie na Norweskiej Klasyfikacji Obiektów (Tverrfaglig Merkesystem – TFM). Ten standard podaje opis jak kodować każdy element budowy.
Aktualność danych jest zapewniona podczas wgrywania nowych wersji modeli oraz bazy danych i przy połączeniu tych żródeł razem. Na naszym projekcie, zaplanowaliśmy cotygodniowe eksporty IFC oraz importy danych do naszych systemów zarządzania danymi.
