Większość naszych wpisów na blogu powinno rozpoczynać od tych samych wykresów:
Firmy nie zbierają danych nawet w sytuacji, kiedy wiedzą, że dany problem przerodzi się w spór z inwestorem, wiem to z doświadczenia, bo piszę opinie w sporach budowlanych. Dlaczego tak się dzieje – nie wiem, ale mam swoje przypuszczenia. Budowlanka od zawsze zmaga się z problemem utraty danych, a odkąd rozwój technologii przyśpieszył ten problem tylko narasta. Oprócz problemów na etapie rozwiazywania sporów, prowadzi to również do szeregu innych uciążliwości, które wymagają angażowania ludzi do wykonywania często niepotrzebnych czynności: ktoś musi zadzwonić, ktoś musi zestawić to w excelu, ktoś inny dorabia do tego rysunki, jeszcze ktoś inny szuka atestów itd. na każdym poziomie / etapie zarządzania projektem. Firmy oczywiście jakoś to ogarniają, ale na ogół nie zadają sobie pytania, jak wyglądałby świat, który jest bardziej poukładany, a ponieważ mniej więcej podobnie jest w każdej firmie, to konkurencyjność jest jakby zachowana.
To dane z raportu: BIG DATA in construction o którym pisaliśmy wcześniej na blogu.
Oczywiście na rynku funkcjonuje wiele rozwiązań, które mogą pomóc nad tym zapanować, ale te są przeważnie drogie i wymagają równie drogich wdrożeń (to są dwa oddzielne procesy). Trzeba być też świadomym, że nawet rozbudowane systemy do zarządzania procesami nie są w stanie zassać wszystkich rodzajów / formatów danych, które potokami przepływają przez realizację. I tutaj właśnie swoją rolę do odegrania mogą mieć tzw. data lakes, czyli jeziora danych. Ponieważ polskie tłumaczenie brzmi w mojej ocenie głupio, więc będę posługiwał się dalej terminem data lake / data lakes.
Co to jest data lake i data lakehouse?
To miejsce, gdzie wszystkie pliki z projektu można załadować do wspólnego worka i nadać temu sens, czyli informacyjna kasza beton czołg i ślimak. A tak bardziej formalnie, data lake to scentralizowane repozytoria zaprojektowane do przechowywania, przetwarzania i analizowania dużych ilości danych z różnych źródeł. Ich ogromną zaletą jest to, że przechowywane dane mogą być nieustrukturyzowane jak i ustrukturyzowane. W przeciwieństwie do tradycyjnych baz danych, data lake przechowują surowe dane w ich rodzimym formacie. Oczywiście integralną częścią takiego rozwiązania muszą być narzędzia do strukturyzacji danych lub ich analizy w formie nieprzetworzonej i tutaj mamy już do czynienia z data lakehouse, o czym szerzej będziemy pisać w kolejnych postach.
Wydaje się, że dla całego sektora AEC tego typu rozwiązania to wręcz zbawienie, bo projekty budowlane generują ogromne ilości danych, począwszy od dokumentów projektowych i umów, aż po raporty dotyczące wykorzystania sprzętu i zapisy konserwacji. Dane te są zwykle rozproszone w różnych systemach, formatach i lokalizacjach, co utrudnia ich efektywne wykorzystanie. Data lakes umożliwią firmom projektowym, konsultingowym i budowlanym przechowywanie wszystkich rodzajów danych w jednym miejscu, zapobiegając ich utracie i gwarantując, że cenne informacje będą zawsze dostępne, z czym jak wiemy firmy mają największy problem.
Wydaje się to mało intuicyjne, ale wykorzystując data lake i nawet nie ustrukturyzowane dane, organizacje mogą stosować zaawansowane narzędzia analizy danych i algorytmy uczenia maszynowego w celu znalezienia wzorców, trendów i zależności w danych. Chodzi więc o możliwość odnalezienia cennych prawidłowości, które inaczej byłyby zupełnie niedostrzegalne. Te wnioski mogą pomóc w optymalizacji procesów zarządczych, redukcji kosztów, poprawie bezpieczeństwa i poprawie ogólnej wydajności projektu. Na przykład, analiza wykorzystywanych jednostek sprzętu może pomóc w przewidywaniu potrzeb konserwacji, a analiza harmonogramów projektów może pomóc w identyfikacji potencjalnych wąskich gardeł i optymalizacji organizacji pracy. Możliwości są praktycznie nieograniczone, choć oczywiście trzeba pamiętać, że w pierwszej kolejności te dane trzeba zbierać. Aby w pełni wykorzystać korzyści płynące z data lakes, firmy budowlane muszą wziąć pod uwagę kilka czynników podczas implementacji tego typu rozwiązań:
1. Konieczne jest określenie solidnych praktyk i ram zarządzania danymi dla utrzymania jakości danych i zapewnienia, że dane są wykorzystywane odpowiedzialnie. Obejmuje to definiowanie właścicieli danych, kontroli dostępu i polityki użytkowania.
2. Integracja danych. Integracja danych z różnych źródeł i formatów jest niezbędna do stworzenia zintegrowanego data lake. Może to obejmować korzystanie z narzędzi do pobierania danych, API, lub niestandardowych skryptów do ekstrakcji, transformacji i ładowania danych do data lake.
3. Dobór narzędzi analitycznych. Wybór odpowiednich narzędzi i platform analitycznych typu data lakehouse jest niezbędny, aby jak najlepiej wykorzystać zgromadzone dane. Bez nich data lake to tylko katalogi z plikami – w dużym uproszczeniu.
4. Cyberecurity i compliace. Zapewnienie, że dane są przechowywane bezpiecznie i zgodnie z przepisami branżowymi, jest kluczowe. Może to obejmować szyfrowanie danych, wprowadzanie kontroli dostępu i regularne audyty bezpieczeństwa. Na naszym blogu często nie poświęcamy tym kwestiom miejsca przyjmując je po prostu jak warunek brzegowy. Dowolna technologia musi spełniać te wymagania bezwarunkowo.
Obserwując trendy należy się spodziewać, że data lakes staną się dominującą techniką przechowywania i przetwarzania danych w organizacjach, które angażują w swoje procesy wielu interesariuszy i niezliczone formaty danych. W miarę postępu narzędzia analityczne będą potrafiły wyciągnąć z tych niepoukładanych danych jak najwięcej cennych informacji lub wiedzy. Należy się też spodziewać także głębokiej integracji data lakes z rozwiązanymi typu biznes intelligence, żeby zarządy organizacji mogły podejmować tzw. poinformowane decyzje. Zagadnieniom data lakes, a szczególnie konkretnym narzędziom poświęcimy więcej miejsca w kolejnych wpisach.
Dodaj komentarz