jakosc danych - feature image

Co Musisz Wiedzieć O Jakości Danych?

Brak danych jest lepszy niż złe dane. Nie jestem pewien czy to cytat znanej osoby (na pewno nie jest to Albert Einstein, ani Peter Drucker), ale bardzo mi sie podoba. Poza tym, naprawdę zawiera dużo prawdy. Ze złych danych wynikają błędne decyzje. Jeżeli zaś nie ma danych, wtedy decyzje nie są oparte o dane (intuicja, ktoś, coś?). Dbałość o jakość danych jest następnym krokiem operacyjnego wykorzystania BIM-wskich danych projektowych.

W poprzednich wpisach wiele napisałem na temat samych danych (co to jest oraz jakiego typu dane posiadamy). Również wyjaśniłem jak bardzo istotne są dobrej jakości dane. Ale co definuje jakość danych? Jak to zmierzyć aby wiedzieć czy jakość danych jest dobra czy nie? Dlaczego to jest ważne? Postaram sie odpowiedziec na te pytania poniżej.

Spis treści

Co to jest jakość danych? Atrybuty jakości danych

Zacznijmy jednak znowu od podstaw: co to jest jakość danych i co to znaczy że posiadamy dane dobrej jakości.

Jakość danych wskazuje nam do jakiego poziomu te dane spełniają swój cel. Innymi słowy:

  1. Mamy cele biznesowe. Mogą być różne: przedstawiać rzeczywistość, pozwalać podjąć decyzję na bazie zebranych danych, lub też wykonać zadanie biznesowe.
  2. Zbieramy pokrewne dane.
  3. Podejmujemy decyzje biznesowe w oparciu o zebrane dane.

Jakość danych określa jak wiarygodne są zebrane dane.

Aby móc ocenić czy dane są wiarygodne czy też nie, należy najpierw zmierzyć oraz wyznaczyć ich jakość. W tym celu mierzymy następujące atrybuty:

  • Zgodność
  • Dokładność
  • Kompletność
  • Format
  • Unikatowość
  • Aktualność

Postaram się opisać te atrybuty wraz z przykładami dla lepszego zrozumienia.

Zgodność

Zgodność mierzy czy każde wystąpienie punktu danych we wszystkich źródłach istnieje i czy jest takie same. Dane zgodności odnośnie mumeru pokoju oznacza iż ten sam numer wszędzie występuje: w modelu, w arkuszu kalkulacyjnym pokoju, w oprogramowaniu do zarządzania obiektem.

Stanowi on podstawowy miernik jeśli projekt stosuje wiele baz danych. Dla każdego punktu danych, musisz ustalić która baza danych jest żródłem prawdy i komunikować to podczas trwania całego projektu. Innymi słowy, żródło pawdy to mistrz danych (data master). W przypadku niezgodności, żródło prawdy nadpisuje każdą inną bazę danych.

Metryka do ocenienia tego atrybutu to liczba niezgodności

Przykład z numerem pomieszczenia:

Przykład z unikalnym kodowaniem (TFM):

Dokładność

Dokładność sprawdza czy dane używane w naszym modelu odpowiadają rzeczywistości. Czyli te wskaźniki sprawdzaja prawidłowe i nieprawidłowe wartości. Jeżeli dany obiekt jest zaznaczony jako “kontrukcyjny”, ale to jest 10cm płyta gips-kartonowa ściana wewnętrzna, to wiesz że coś jest nie tak. Często też przytrafiają się literówki, które sprawiają iż dane są niewłaściwe.

Metryka to stosunek liczby obiektów z niewłasciwymi danymi do liczby obiektów z prawidłowymi danymi.

Wrong use of string data type
Przykład nieprawidłowych danych przy nazwie Oddziału Szpitalnego w bazie danych programu pokoju.

Kompletność

Ten atrybut informuje nas czy dane są kompletne, tzn. czy wszystkie dostępne punkty danych zostały wykorzystane w bazie danych. Pomiar ten idzie w parze z LOIN (Poziom Wymaganej Informacji) oraz wymaganiami projektowymi. Czy wszystkie obiekty posiadają wartości wymagane na tym etapie projektu?

Metryka to liczba obiektów, które nie posiadaja wszystkich wymaganych wartości.

comprehensiveness data quality
Przykład wymagań odn. własciwości oraz przykład niekompletności danych projektowych, ktore powinny odpowiadać stawianym wymaganiom.

Format

Wprowadzone dane odpowiadaja wymaganemu formatowi dla danej właściwości. Wiele właściwości wymaga specyficznego formatu. Np., ognioodporność posiada format “EIXX”, gdzie XX to wartości opisane w standardzie (np. EI30, EI60, EI90). Inny przykład to klasa betonu opisanego w Eurokodzie: C30/37. Uzgodniony format daty również może być mylący przy międzynarodowej obsadzie (DD.MM.YYYY czy MM/DD/YYYY lub też YYYY-MM-DD).

Metryka ocenia stosunek danych w niewlasciwym formacie.

Unikatowość

Ten atrybut zlicza ile duplikatów znajduje się w naszej bazie danych. Pomiar ten jest istotny zwłaszcza wtedy, kiedy istnieje wymaganie unikatowego kodowania elementów, które będzie użyte przy późniejszych etapach projektu.

Metryka wyznaczająca ten atrybut to liczba duplikatów.

Duplicated data-Solibri
Przykład duplikowanych etykiet właściwości w Solibri (zaznaczone na żółto i turkusowo). Stanowią one wewnętrzne wymagania danych projektowych w EIR.

Aktualność

Dane muszą być zaktualizowane i odzwierciedlać rzeczywistość przez wymagany okres czasu. Po jakimś czasie, dane są odświeżone (czy to ręcznie importowane czy tez jako automatyczny proces). Jest to niesłychanie ważne podczas fazy projektowania i budowania, gdzie trwają nieustanne zmiany w naszych danych.

Metryka wyznaczająca ten atrybut to liczba nieaktualnych rejestrów.

Timeliness ifc files
Przykład plików IFC. Czy oznacza to że niektóre zespoły zakończyły pracę czy też że pliki IFC nie zostały ekspediowane do CDE?

Dlaczego jakość danych jest istotna?

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.

Nierzetelne informacje = utrata zaufania

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.

Przykład

Na powyższym zrzucie widzisz elementy, którym przypisano nieprawidłowy numer kontrahenta (K29002 zamiast K2902). Załóżmy że kontrahent K2902 filtruje wszystkie obiekty objęte jego odpowiedzialnościa i używa danych do:

  • Policzenia ile łazienek musi zamontować na tym piętrze, i w oparciu o to przygotować harmonogram prac
  • Wysłania listę numerów drzwi do dostawcy automatyki do drzwi
  • Policzenia jakiego typu i ile elementów musi dostarczyć w tygodniu 43

Jeżeli jedynie polega na tym 1 filtrze (czego w rzeczywistości nie powinien robić, upraszczam nieco), to może to skutkować następującym: :

  • Harmonogram prac robi sie zbyt napięty (dodatkowa łazienka)
  • Automatyka do drzwi nie jest zaprogramowana do tych drzwi
  • Elementy do dodatkowej łazienki w ogóle nie przybywają na plac budowy.

Niekompletne dane

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.

Zduplikowane dane

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ć?

Przykład

Przypuścmy, że posiadamy model projektanta i dostawca okien również dostarcza swój model (ponieważ niektóre okna są złożone w kształtach jak i wymaganiach). Projektant powinien usunąć ze swojego modelu wszystkie okna stworzone w modelu dostawcy. Ale jeden typ okien został zduplikowany i nie został wychwycony podczas koordynacji.

Zakontraktowany blacharz zlicza okna aby zamówić wystarczająco materiałów do zrealizowania zamówienia. W rezultacie na teren budowy przybywa 15% więcej blachy niż powinno. Blacharz jest sfrustrowany, ponieważ nie ma miejsca na przechowanie nadmiaru materiału na terenie budowy, więc musi odesłać nadmiar z powrotem i zapłacić dodatkowo za transport.

Jak przeprowadzić kontrole jakości danych w projektach BIM?

Dla każdego z wyżej wymienionych atrybutów, możemy zdefiniować metrykę, przeprowadzić kontrole jakości oraz ustanowić próg zgodności jakości. Ponieważ każdy projekt posiada odmienne specyfikacje oraz wymagania, niebędne jest aby uzgodnić hierarchię kontroli jakości oraz ich częstotliwość. Wymagane metryki mogą być dołączone w co-tygodniowych BIM koordynacjach, podczas gdy inne mogą być sprawdzane tylko parę razy podczas całego okresu istnienia projektu. Lub też zupełnie pominięte.

Pozwól że opiszę inne możliwe kontrole jakości danych przy pomocy przykładów z mojego doświadczenia oraz podzielę sie swoimi uwagami na temat co jest istotne na naszych projektach. Nie musisz się ze mna zgadzać! Ale proszę pamiętaj aby dostosować to do potrzeb swojego projektu.

Zgodność

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.

Numery obiektów wg.TFM przechowywane są w dwóch oddzielnych bazach danych: dRofus (baza danych wymagań, TFM generator kodów i wzorzec) oraz plików IFC (numer TFM wysłany z dRofus). Oba żródła są później importowane do pojedynczej bazy danych i przeniesione do systemu Zarządzania Nieruchomościami. dlatego też zgodność danych jest tak istotne tutaj- chcesz aby każdy obiekt z bazy danych TFM odpowiadał temu samemu obiektowi w modelach.

Jako, że na projekcie pracuje ponad setka ludzi którzy recznie wprowadzaja dane w obu miejscach, pewne jest że przytrafiają sie pomyłki. Warto zdawać sobie sprawę, że trudno jest kontrolować dane tutaj, gdyż obie bazy danych są potężne (grubo ponad 2,5 miliona obiektów).

TFM i IFC - consistency check
Formuła Excel dzięki której otrzymujemy wynik PRAWDA/FAŁSZ odn. tego które znaki TFM istnieją w bazie danych, ale nie w modelu.

Biorąc pod uwagę fakt, że kontrola odbywa sie na interfejsie dwóch różnych programów, musieliśmy posłużyć się starym, dobrym Excelem aby porównać oba źródła. Wyeksportowałem wszystkie obiekty z obu źródeł w jeden arkusz kalkulacyjny Excel i porównałem je przy użyciu formuły. Wyniki (PRAWDA/FAŁSZ) są następnie umieszczone na dashboardzie do dalszych analiz i przydziału zadań.

Jest to bardzo uciążliwy proces, więc w minionym roku wykonaliśmy to tylko dwa razy, ostatnia kontrola jest przewidziana tuż przed końcem procesu projektowego.

Dokładność

Ten atrybut głównie podlega kontroli przez projektantów podczas kontroli jakości oraz Koordynacji BIM modelu. Jasno określony zestaw reguł które opierają się na normach i standardach https://bimcorner.com/a-few-words-about-rule-based-model-checking/ jest najlepszą drogą postępowania tutaj. Przede wszystkim, standardowe zasady wyznaczone przez oprogramowanie sprawdzające kolizje.

Przykładowe zasady przy kontroli dokładności:

  • Ognioodporność musi być z uzgodnionej listy
  • Wysokie ściany musza być odpowiednio grube
  • Otwory nie moga być zbyt blisko krawędzi ścian
accurracy check
Przykład zestawu reguł w Solibri do sprawdzenie dokładności w typach ścian.

Kompletność

Ten atrybut również jest kontrolowany przez IFC za pomocą specyficznego zestawu reguł. Jedynym warunkiem tutaj jest: ISTNIEJE/NIE ISTNIEJE. Przeprowadzam tę kontrole dla właściwości IFC zdefiniowanych w danym projekcie, które klient wymaga.

Przykładowe właściwości, które należy sprawdzić dla każdego obiektu przy kontroli kompletności (przykładNye SUS):

  • “Obszar Kontrolny”
  • “Wskażnik Dojrzałości Modelu”
  • “Odpowiedzialny Kontrahent ”
bim data quality check for comprehensiveness
Powyższy zestawy reguł są wprowadzane do menedżera zestawu reguł w Solibri. Musieliśmy stworzyć własny zestaw reguł..

Format

Ten atrybut również jest kontrolowany w  IFC model checker (w naszym przypadku Solibri) lub w zewnętrznej bazie danych. Kontrolujemy prawidłowy format pod kątem zgodności z wymaganiami. Ten etap może stać sie kompleksowy, gdy zechcemy sprawdzić czy każdą wartość posiada odpowiednie formatowanie prawidłowej wartości.

Modelowe zasady które należy sprawdzić przy kontroli formatu:

  • Łatwy przy kontroli ognioodporności: Jeden z of (EI30, EI60, EI90, EI120)
  • Bardziej skomplikowany: stała formuła dla samego kodu TFM: [+][0-9]{6}[=][0-9]{3}[.][0-9]{3,}[:][0-9]{2,}[-][A-Z]{3}[.][0-9]{3,}[T][/][0-9]{3,}$

Unikatowość

Kontrola unikatowości obiektów BIM jest stosunkowo łatwym zadaniem: programy sprawdzające modele IFC posiadają wbudowaną funkcję która sprawdza zduplikowane obiekty. Kontrola unikatowości właściwości jest trudniejszym zadaniem. Czasami oprogramowanie zezwala tylko unikatowe wartości (tak jak baza danych dRofus do kodowania TFM), ale w wielu przypadkach jest to mrówcza oraz czasochłonna ręczna kontrola.

W takich przypadkach, Twój projekt musi zdefiniować które dane są warte tego aby im sie przyjrzeć i kontrolować duplikaty. Przeglądarki IFC są również pomocne, ponieważ umożliwiają przemiar informacji – jest to najłatwiejszy sposób wykrycia które właściwości posiadają najwięcej duplikatów. Zawężasz rezultaty aby mieć pełną listę obiektów ze zduplikowanymi danymi. Często projektanci popełnili błąd przy eksporcie do IFC, dlatego może warto im podesłać niniejsze artykuły:

https://bimcorner.com/pl/reguly-eksportu-do-ifc-czesc-1-dlaczego-jest-to-wazne/ https://bimcorner.com/pl/reguly-eksportu-do-ifc-czesc-2-co-eksportowac-a-czego-nie/

Aktualność

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.

Podsumowanie

Po przeprowadzeniu tych wszystkich kontroli, otrzymasz ogólny obraz stanu w jakim znajduje sie projekt. Jednakże, jest to tylko sytuacja w danym momencie. Jeżeli chcesz być na bieżąco z jakością danych, dobrym pomysłem jest dołączyć rezultaty takiego audytu kontroli jakości do dashboarda w PowerBI.

Reasumując, całościowa kontrola jakości danych zabiera dużo czasu i wysiłku. Z drugiej zaś strony, wiele atrybutów podlega kontroli wraz z BIM koordynacją. Inne zaś, mogą być zautomatyzowane lub umieszczone na pulpicie.

W efekcie końcowym, uzyskujesz pełen obraz jakości danych w Twoim projekcie, jakie dane są poprawne, a gdzie należy popracować. Dzięki takiemu audytowi, interesariusze projektu mają rozeznanie które dane są już gotowe do użytku, a które jeszcze nie powinny być brane pod uwagę przy podejmowaniu decyzji biznesowych.

Źródła

Spodobał Ci się ten artykuł? Podziel się nim !

Dużo czasu i wysiłku poświęcamy na tworzenie wszystkich naszych artykułów i poradników. Byłoby świetnie, gdybyś poświęcił chwilę na udostępnienie tego wpisu!

Udostępnij:

Komentarze:

Subscribe
Powiadom o
guest
0 Comments
najstarszy
najnowszy
Inline Feedbacks
View all comments

Autor:

Pobierz przewodnik po projektach BIM:

Po przeczytaniu tego poradnika dowiesz się:

  1. Jak BIM jest wykorzystywany przy największych projektach w Norwegii
  2. Jakie były wyzwania dla zespołu projektowego i jak zostały rozwiązane
  3. Jakie były wyzwania na budowie i jakie było nasze podejście do nich

Najnowsze wpisy: