SSoT, czyli Single Source of Truth (Jedyne Źródło Prawdy), to koncepcja architektury i zarządzania, która leży u podstaw całej filozofii BIM.
W tradycyjnym projektowaniu informacje o obiekcie są rozproszone, architekt ma modele 3D, konstruktor obliczenia, instalator własne modele i schematy, a inwestor tabele w Excelu. Wszyscy uczestnicy muszą mieć aktualne dane, a gdy dochodzi do zmian to każdy z nich musi wprowadzić dane ręcznie w swoich projektach lub dokumentacji.
SSoT – to architektura, w której każda informacja w projekcie jest definiowana tylko raz, w jednym miejscu, a wszyscy uczestnicy procesu mają do niej autoryzowany dostęp.
Trzy Filary SSoT
Wdrożenie jednego Źródła Prawdy opiera się na trzech ściśle powiązanych elementach: technologii, procesach oraz ludziach. W tradycyjnych projektach BIM dla prawidłowego działania SSoT architektura powinna zawierać następujące komponenty:
1. Środowisko: Platforma CDE (Common Data Environment)
Punkt Prawdy (SSoT) nie istnieje bez wspólnej przestrzeni do zarządzania danymi. W tradycyjnych projektach BIM w roli CDE występują BIM 360, Autodesk Construction Cloud, Trimble Connect, Revizto, Dalux, ProjectWise, Aconex, BIMcollab lub inne. Ta przestrzeń przechowuje aktualne dane modelu BIM i niezbędną dokumentację projektową.
2. Własność danych (Model Ownership)
W koncepcji BIM SSoT każdy element modelu ma swojego jedynego właściciela, który odpowiada za prawidłowe wprowadzenie i zmianę danych.
3. Status (Kontrola wersji)
Każdy dokument lub plik w CDE powinien mieć jasne określony status przydatności. Na przykład, zgodnie z normą ISO 19650 najczęściej definiowane statusy mogą być:
– WIP (Work in Progress),
– Shared (Udostępniony) Model sprawdzony wewnętrznie, udostępniony innym branżom do podczytywania jako odnośnik.
– Published (Opublikowany) Wersja zatwierdzona przez inwestora/BIM Managera, gotowa np. do wykonania na budowie.
– Archived (Archiwum) Historia zmian – nic nie jest bezpowrotnie usuwane
Dlaczego to jest tak ważne?
Jedyne źródło prawdy (SSoT) pozwała uniknąć klasycznych patologii projektowych i pozwała opanować potencjalny chaos.
Omówmy to na przykładzie: w projekcie instalacji wodnej budynku była zaprojektowana pompa o napięciu 230V. Dział zakupów zamówił pompę, ale czas realizacji zamówienia był zbyt długi. Żeby uniknąć opóźnienia terminów projektant instalacji wodnej zmienił pompę na alternatywną, jednak napięcie nowej pompy wynosi 24V. W tym czasie firma, która wykonuje instalacje elektryczną na podstawie pierwotnych plików zamawia komponenty instalacji elektrycznej i automatyki na napięcie 230V. Projektant instalacji elektrycznej nie zaktualizował na czas plików instalacji wodnej i zmiana pompy nie została uwzględniona. W przypadku kolejnej zmiany w instalacji wodnej oraz opóźnieniu przy aktualizacji plików powstaje chaos, który prowadzi do błędów w zestawieniach, modelach i dokumentacji wszystkich pokrewnych branż. Konstruktor zaprojektował zły fundament dla pompy, automatyk zamówił złe siłowniki i szafę, chaos powiela się. Kolejnym problemem w tej sytuacji jest brak odpowiedzialności. Projektant instalacji wodnej nie poinformował od razu o zmianach, projektant instalacji elektrycznej nie zaktualizował plików od razu, a konstruktor nie wiedział, że rozmiar pompy się zmienił, bo dostał pliki od elektryka i był pewien że są aktualne.
Wprowadzenie SSoT eliminuje wszystkie wymówki w stylu: „Myślałem, że elektryk to poprawił”, „U mnie na komputerze to wyglądało inaczej”. Każda zmiana w modelu ma przypisanego autora, datę i historię rewizji oraz jest od razu widoczna dla wszystkich uczestników procesu budowlanego.
Jak prawidłowo ustalić i utrzymać SSoT
Wdrożenie SSoT wymaga przemyślanej architektury i jasnych zasad spisanych na samym początku projektu w BEP (BIM Execution Plan). Prawidłowa architektura, dokładne ustalenie roli dla każdego z uczestników procesu budowlanego, nadanie im odpowiednich uprawnień (własności danych) oraz kontrola statusów plików są kluczowymi elementami w funkcjonowaniu SSoT.
Podstawą dobrej architektury jest prawidłowy wybór CDE oraz kanałów wymiany informacji. Również dobrą praktyką jest przyjęcie zasady: „Pliku, którego nie ma na CDE, nie istnieje dla projektu”. Oczywiście również kluczową rolą jest nadanie odpowiednich uprawnień dla wszystkich plików na CDE oraz ograniczenie dostępu do nich osobom nieupoważnionym.
Następnym ważnym krokiem jest ustalenie schematu nazewnictwa plików. Prawidłowa nazwa pliku powinna jednoznacznie określać jego zawartość, bez konieczności otwierania go. Nazwy w stylu: „projekt_v2_poprawiony„, „… ostateczny„, „… najnowszy” oraz podobne są źródłem zamieszanie i powinny zostać całkowicie wyeliminowane ze środowiska. Najlepiej zastosować zalecenia normy ISO 19650 w kwestii nazewnictwa:
PROJEKT-KOD_AUTORA-BRANŻA-POZIOM-TYP_DOKUMENTU-NUMER.dwg
(np. PRJ-XYZ-ARC-01-M3-0001.rvt – Projekt PRJ, autor XYZ, branża architektoniczna, poziom 1, model 3D, numer sektora itp).
Kolejną dobrą praktyką powinna być zasada: linkowanie zamiast kopiowania.
Wszędzie gdzie jest to możliwe należy używać referencji, podczytując inny plik jako tło lub warstwę zamiast tworzenia kopii tego pliku. W takiej konfiguracji, po wprowadzeniu zmian w oryginalnym pliku przez osobę uprawnioną, zostanie ona automatycznie zaktualizowana w naszym pliku. Nieprzestrzeganie tej zasady generuje luki w całym łańcuchu utrzymania jedynego źródła prawidłowej informacji SSoT.
Również bardzo ważnym aspektem utrzymania SSoT jest automatyzacja przepływu pracy (Workflow).
Częstym źródłem błędów lub problemów w prawidłowym działaniu procesów BIM jest czynnik ludzki, – „Zapomniałem wysłać maila”, „źle wpisałem adres”, „Nie sprawdziłem” itp. Większość błędów tego typu pozwala wyeliminować automatyzacja. Prawidłowo skonfigurowane środowisko CDE oraz dedykowana automatyzacja pozwalają skupić się na wykonaniu projektu lub pracach budowlanych nie marnując dużo czasu na procedury. Na przykład: projektant wrzuca model —> koordynator branżowy dostaje powiadomienie o konieczności weryfikacji —> po akceptacji model automatycznie zmienia status z WIP na Shared i staje się widoczny dla reszty zespołu.
Podsumowując: Single Source of Truth to nie tylko technologia chmurowa lub wspólna przestrzeń, lecz bardziej architektura, a nawet kultura pracy, która pozwała utrzymać czystość i spójność informacji w trakcje życia projektu BIM.