Kiedy wdrożenie wspólnego środowiska danych (CDE) w firmie kończy się niepowodzeniem, często obwiniamy za to oprogramowanie lub wskazujemy palcem na „oporne” zespoły.
Ale oto niewygodna prawda: ludzie nie omijają CDE, bo są leniwi lub niekompetentni. Pod ogromną presją projektową (co zdarza się dość często) instynkt ludzki zawsze wybierze najszybszą drogę, która wymaga najmniejszego wysiłku.
Dzisiaj chciałbym porozmawiać o błędach, które popełniamy, wdrażając CDE w firmie.
Chcę przedstawić psychologiczne wyjaśnienie, dlaczego przypadkowo sprawiamy, że nasze CDE jest opcjonalne.
By ten wpis był bardziej konkretny, jako przykład CDE posłuży mi Autodesk Forma (dawniej ACC).
Tysiąc Wyjątków - Czyli powolna śmierć twojego CDE
W wielu firmach z branży AEC typowe wdrożenie wygląda następująco.
1. Kierownictwo inwestuje w licencje Autodesk Forma.
Załóżmy, że jesteś tam menedżerem BIM, który organizuje to wszystko dla swojej firmy.
Tworzysz przejrzystą strukturę folderów, przyznajesz uprawnienia i organizujesz tygodniowe szkolenie. Wszyscy uczestnicy szkoleń kiwają głowami i zgadzają się na korzystanie z niego.
Myślisz sobie – wielki sukces!!!
Kiedy Pojawia Się Presja, Wygrywają Nawyki
Wtedy uderza rzeczywistość.
Ludzie zaczynają pracować nad projektami w nowym środowisku CDE.
Ale… mija czas
…..i zbliża się termin realizacji dużego projektu, zmiana w projekcie wymaga natychmiastowej odpowiedzi, a poziom stresu gwałtownie rośnie. Aby przyspieszyć pracę, projektanci zaczynają udostępniać modele i pliki PDF za pośrednictwem e-maili.
Dokumenty są wysyłane przez czaty w Teams, a decyzje zaczynają być podejmowane przez telefon.
Narodziny Ukrytego Procesu
W tym momencie wdrożenie nie tylko napotkało drobną przeszkodę; po cichu umarło.
Nie zakończyło się to ogromną, dramatyczną porażką, ale tysiącem małych wyjątków (tych opisanych powyżej).
W ciągu trzech tygodni te wyjątki stają się nową normą.
Wpadłeś w frustrującą pętlę, w której płacisz za najnowocześniejsze oprogramowanie w chmurze, ale Twoim faktycznym „systemem prawdy” jest chaotyczna mieszanka czatów w Teams, wątków w Outlooku i lokalnych plików. Aby przerwać ten cykl, musimy zająć się dwoma podstawowymi błędami ludzkimi i procesowymi.
Błąd nr 1: Mylenie narzędzia z modelem operacyjnym
Pierwszą pułapką jest przekonanie, że zakup platformy CDE, takiej jak Autodesk Forma, automatycznie zapewnia porządek. Tak nie jest.
Autodesk Forma to narzędzie. Common Data Environment to model operacyjny: powtarzalny sposób zarządzania informacjami, dzięki któremu zespoły mogą mieć pewność, które informacje są aktualne, które są skoordynowane, a które mają charakter oficjalny.
Norma ISO 19650 jest tu przydatna, ponieważ traktuje CDE jako zarządzany proces dla „kontenerów informacji” przechodzących przez kontrolowane stany. Nie musisz w pełni spełniać wymagań ISO, aby na tym zyskać. Potrzebujesz jednak podstawy.
Tą podstawą jest prosty szkielet pojedynczego źródła prawdy (SSOT – Single Source of Truth). Cztery części, które działają razem:
1) Stany Informacji (Gdzie Znajduje Się Praca a Gdzie Prawda)
Zespoły ponoszą porażkę, gdy w projekcie mają foldery bez wspólnego znaczenia. Ludzie przesyłają pliki, ale nikt nie wie, do czego służy każdy obszar, więc pod presją każdy wymyśla własne zasady.
Napraw to w pierwszej kolejności. Zdefiniuj stany informacji i granice. W ISO 19650 te stany są przedstawione następująco:
- WIP – (Work In Progress) służy do pracy. Znajdują się tu wersje robocze i iteracje. Tu twój zespół pracuje przez większość czasu. Nie jest to źródło koordynacji pomiędzy branżami.
- Shared “Wspólne” – jeśli informacja wpada tutaj to służy ona do koordynacji. To miejsce, w którym zespoły wymieniają się pracą w celu uzgodnienia działań. Nie jest to ostateczny wersja informacji.
- Published – “Opublikowane” to oficjalna informacja która idzie “w świat” Np: do klienta. Jeśli coś ma charakter umowny, zostało wydane lub jest „bezpieczne do wykorzystania”, znajduje się tutaj.
- Archive – “Archiwum” – to historia. Służy ono zapewnieniu identyfikacji i do ewentualnego wglądu, a nie codziennej pracy.
Wewnętrznie, w waszym zespole czy firmie możecie te stany nazywać jak chcecie.
Termin „wspólne” można nazwać „koordynacja”, a „WIP” „aktualnym projektem”.
Nazwy nie mają znaczenia. Liczy się znaczenie.
2) Nazewnictwo i Metadane (Zapewnij Przewidywalność Wyszukiwania)
Jeśli w każdym projekcie pliki nazywane są inaczej, użytkownicy tracą zaufanie do platformy. Wtedy zaczynają pytać. Potem tworzą duplikaty. W końcu zakładają lokalne „ostateczne” foldery.
Nazewnictwo nie musi być idealne. Musi być na tyle spójne, aby każdy mógł szybko stwierdzić:
co to jest, kto to stworzył, do jakiego pakietu należy, jaka to wersja i w jakim stanie się znajduje.
Na początku wystarczy „minimalny” standard.
Celem jest przewidywalność, a nie elegancja.
3) Uprawnienia (Ochrona Prawdy)
SSOT upada, jeśli każdy może nadpisać lub edytować oficjalne informacje.
Uprawnienia to nie tylko kwestia bezpieczeństwa. To kontrola przepływu pracy. Zapobiegają przypadkowemu chaosowi i powstrzymują obszar „Opublikowane” przed przekształceniem się w dysk współdzielony z brandingiem.
Prosta zasada działa najlepiej:
- Użytkownicy mogą swobodnie tworzyć i edytować w swoich obszarach w WIP
- Zespoły mogą współpracować w obszarze Shared
- Obszar Published jest chroniony i służy konkretnym celom. Tylko uprawnione role mogą publikować lub udostępniać na zewnątrz.
Jeśli obszar Published jest edytowalny przez wszystkich, przestaje być źródłem prawdy.
4) Zasada Publikacji (Jak Informacja Staje Się Oficjalna)
To właśnie ten brakujący element w większości firm.
SSOT oznacza: „mamy jasną zasadę określającą, w jaki sposób informacja staje się oficjalna, i przestrzegamy jej”.
To moment, w którym zapadają prawdziwe decyzje:
Czy informacja jest nadal w fazie projektu, czy gotowa do koordynacji?
Czy jest skoordynowana i gotowa do publikacji?
Czy jest bezpieczna w użyciu dla klienta lub wykonawcy?
Jeśli tego nie zdefiniujesz, publikacje będą odbywać się na skróty: zatwierdzenia emailowe, wiadomości w Teams, ustne „wygląda ok” i lokalne kopie. To natychmiast łamie SSOT.
Nie potrzebujesz skomplikowanego procesu, aby zacząć. Wystarczy nawet prosta zasada:
Published jest aktualizowane tylko wtedy, gdy pakiet jest kompletny i celowo opublikowany.
Później możesz to właściwie wdrożyć w Forma, korzystając z funkcji Reviews/Approvals + Transmittals. Ale zmiana sposobu myślenia zaczyna się już teraz: wszystko, co jest udostępniane na zewnątrz, musi być sprawdzone i zatwierdzone w sposób umożliwiający śledzenie.
Spójrz poniżej na grafikę. Informacja z jednego stanu przechodzi do drugiego
Np: z WIP do Shared, tylko wtedy gdy jest sprawdzona i zaaprobowana. 👇
To właśnie w tym miejscu, wykorzystuje się narzędzie “Review / Approval” w Autodesk Forma, do sprawdzenia jakości informacji i ewentualnego zaakceptowania go do następnego stanu.
Błąd nr 2: Szkolenie skupiające się na kliknięciach zamiast na „dlaczego”
Większość szkoleń dotyczących CDE koncentruje się głównie na funkcjach oprogramowania.
Firmy zatrudniają zewnętrznych specjalistów, którzy spędzają całe dnie na prezentowaniu interfejsu użytkownika, pokazując pracownikom, gdzie mają klikać, jak przesyłać pliki i jak otwierać zakładkę recenzji.
Następnie zakładają, że ludzie z dnia na dzień zmienią swoje nawyki wypracowane przez dziesięć lat pracy z pocztą elektroniczną i dyskami lokalnymi.
Dlaczego Samouczki Oparte na Klikaniu Przycisków Zawodzą
Szkolenie to nie to samo, co wdrożenie.
Szkolenia oparte na funkcjach ignorują psychologiczny aspekt zmiany.
Pod presją terminów ludzie nie przejmują się funkcjami oprogramowania; zależy im na „przetrwaniu :)” i „wykonaniu pracy”.
Jeśli nie rozumieją, dlaczego kontrolowane stany mają znaczenie lub w jaki sposób lokalne kopie niszczą jedyne źródło prawdy projektu, powrócą do tego, czemu ufają: swojego lokalnego dysku twardego
Przejście na Scenariusze Oparte na Rolach
Zamiast tego należy szkolić pracowników pod kątem pełnionych ról, a nie funkcji oprogramowania.
Kierownik projektu potrzebuje innego rodzaju wsparcia niż inżynier budowy czy koordynator BIM. Szkolenia należy opierać na rzeczywistych scenariuszach projektowych, a nie na menu oprogramowania. Na przykład, zamiast uczyć, jak korzystać z narzędzia do przesyłania plików, pokaż im:
„Właśnie otrzymaliśmy uwagi klienta dotyczące Pakietu A. Oto, jak je przetwarzamy, jak powiązujemy decyzję z rekordem modelu i jak potwierdzamy, że ostateczna odpowiedź jest oficjalna”.
Wyznaczanie Strażników Informacji
Ponadto nie próbuj zmieniać wszystkiego naraz. Wybierz dwie lub trzy zasady, których nie da się obejść, na przykład „żadnych lokalnych kopii modeli projektowych”, i konsekwentnie je egzekwuj przez następne cztery tygodnie.
Aby zasady te były przestrzegane w praktyce, wyznacz „strażnika informacji” lub lidera w każdym zespole realizacyjnym. Nie potrzebujesz globalnego administratora siedzącego w odległym biurze korporacyjnym; potrzebujesz kogoś na pierwszej linii, kto będzie pilnował przestrzegania zasad i pomagał współpracownikom, gdy presja osiągnie szczyt.
Podsumowanie
Autodesk Forma zapewnia Twojemu zespołowi możliwość doskonałej organizacji danych projektowych, ale nie jest w stanie wymusić na ludziach dyscypliny. Wdrożenia CDE nie kończą się niepowodzeniem dlatego, że ludzie chcą łamać zasady; kończą się niepowodzeniem, ponieważ sposób wdrożenia sprawia, że stare nawyki pozostają łatwiejszym rozwiązaniem.
Określając najpierw proces i przenosząc nacisk szkolenia z obsługi oprogramowania na ludzkie procedury pracy, przestajesz traktować CDE jako opcjonalną wersję próbną oprogramowania.
Zmienisz je w niepodważalną, zaufaną podstawę realizacji Twoich projektów.
Jeśli chcesz przestać walczyć ze starymi nawykami i wreszcie przekształcić swoje CDE w potęgę operacyjną, zapisz się do mojego newslettera CDE ROI Accelerator, aby otrzymywać praktyczne, sprawdzone w boju strategie bezpośrednio na swoją skrzynkę mailową.
Sprawdź szczegóły tutaj: https://cderoiaccelerator.com/
Dzięki za czytanie!
