Dane pod kontrolą – doświadczenia lotniska w Pradze z wdrożenia i skalowania Autodesk Build (obecnie Autodesk Forma)

Daniel Šmejkal był prelegentem Autodesk BIM DAYS 2026 | Building Value – jego prezentacja dostępna jest na stronie www.autodesk.com/pl/campaigns/bimdays2026.

Jakie wyzwanie stało przed lotniskiem w Pradze, kiedy zaczynaliście wdrażać Autodesk Build (obecnie Autodesk Forma)?

Daniel Šmejkal: Największym wyzwaniem była skala przedsięwzięcia, które zaplanowaliśmy. Lotnisko w najbliższych latach wejdzie w okres największej rozbudowy, kiedy znacząca część terenu stanie się placem budowy. To, co zamierzamy jest z operacyjnego punktu widzenia podobne do zarządzania małym miastem: infrastruktura techniczna, budynki biurowe, obiekty publiczne, technologie lotniskowe. I to wszystko musi działać, być modernizowane i rozbudowywane.

Zaczynaliśmy już w 2018 roku od jednego małego projektu BIM i kilku licencji BIM 360 Docs. To były naprawdę skromne początki. Ale bardzo szybko okazało się, że jeśli chcemy utrzymać kontrolę nad dokumentacją i procesami przy dziesiątkach, a później ponad stu projektach rocznie, to potrzebujemy środowiska, które da się skalować. I tu Autodesk Build (obecnie Autodesk Forma) okazał się naturalnym kierunkiem.

Kiedy skala zaczęła rosnąć, co okazało się największym problemem?

Skala sama w sobie. W pewnym momencie mieliśmy już setki aktywnych projektów i ponad 2 tys. użytkowników. I wtedy okazało się, że ręczna administracja po prostu nie działa. Każda zmiana, nawet drobna, jak nazwa folderu czy właściwość pliku – musiała być powtarzana projekt po projekcie. To prowadziło do niespójności. Raporty zaczęły się „rozsypywać”, bo dane z projektów nie były jednolite. A kiedy masz do czynienia z tak ogromną skalą przedsięwzięcia, wówczas jeden błąd powielony sto razy okazuje się naprawdę dużym problemem. Wtedy zrozumieliśmy, że bez automatyzacji i centralnego zarządzania danymi nie utrzymamy jakości.

A jak poradziliście sobie z edukacją tak dużej liczby użytkowników?

Na początku szkoliliśmy ludzi indywidualnie. To działało przy kilku projektach, ale przy dwóch tysiącach użytkowników było kompletnie nie do utrzymania. Dlatego stworzyliśmy portal edukacyjny przeznaczony zarówno dla pracowników, jak i dla firm zewnętrznych. Są tam wideo, instrukcje, diagramy, całe workflow dotyczące Autodesk Build i Autodesk Docs. Dzięki temu onboarding stał się powtarzalny, a my nie musimy prowadzić dziesiątek szkoleń miesięcznie. To był jeden z kluczowych elementów, który pozwolił nam poradzić sobie z tak dużą skalą.

W którym momencie pojawiło się przekonanie, że bez API nie da się prowadzić projektu o tak dużej skali?

To przyszło naturalnie, kiedy zobaczyliśmy, że zmiany w standardach nie przenoszą się na istniejące projekty. Z perspektywy użytkownika Autodesk Build traktuje każdy projekt jako osobny byt. Korzystając z API, możesz działać jednocześnie na wielu projektach i danych. Jeśli więc chcieliśmy zmienić strukturę folderów, role czy metadane, musieliśmy robić to ręcznie. Przy kilkuset projektach jest to niewykonalne. I wtedy API okazało się absolutnym „game changerem”. Zadania, które normalnie zajęłyby setki godzin, zaczęliśmy wykonywać w kilka minut i to bezbłędnie. Wtedy właśnie poczuliśmy, że odzyskujemy kontrolę nad środowiskiem.

Jakie procesy zautomatyzowaliście?

Najważniejsze były trzy rzeczy. Po pierwsze – automatyczne tworzenie projektów. Połączyliśmy Autodesk Construction Cloud z naszym ERP i projekty powstają same, z poprawnymi nazwami, strukturą i rolami. Drugim elementem jest zarządzanie użytkownikami. Uprawnienia dla pracowników są nadawane automatycznie na podstawie danych z systemów wewnętrznych. Warto zwrócić uwagę także na masowe aktualizacje standardów. Jeśli zmieniamy strukturę folderów albo role, możemy wdrożyć to jednocześnie na całym portfolio. Do tego dochodzą nasze własne narzędzie, który sprawdza kompletność dokumentacji i generuje raport jako issue w Autodesk Build. To znacząco przyspieszyło pracę projektantów i nadzoru.

Czy wszystkie projekty były traktowane tak samo, czy musieliście podejść do nich w sposób zindywidualizowany?

Szybko odkryliśmy, że jedno, takie samo podejście do wszystkich projektów nie działa. Dlatego podzieliliśmy projekty na trzy kategorie: strategiczne, średnie i małe. Te strategiczne, takie jak rozbudowa terminala, mają pełne workflow, BIM, dokładny nadzór i wsparcie Information Managera. Projekty średnie korzystają z części funkcji Autodesk Build, a małe, często składające się zaledwie z kilkunastu rysunków, mają tylko podstawowe workflow. Ta elastyczność była konieczna. Gdybyśmy próbowali wdrożyć pełny zestaw narzędzi w każdym projekcie, system by się zatkał.

Jakie lekcje wynieśliście z dotychczasowych doświadczeń pracy nad projektem?

Po pierwsze, automatyzować jak najwcześniej. Inicjując ten proces, już na początku unikamy wielu niespójności. Po drugie, trzeba projektować governance od razu z myślą o skali, nawet jeśli zaczyna się od jednego projektu. Po trzecie – nie polegać na ręcznej administracji. Ona zawsze zawiedzie przy dużej liczbie projektów. I po czwarte – inwestować w edukację, bo nawet najlepsze narzędzia nie działają, jeśli ludzie nie rozumieją procesów.

A najważniejszy wniosek?

Skalowanie Autodesk Build to nie jest tylko technologia. To połączenie data governance, automatyzacji procesów, edukacji i elastyczności operacyjnej. Dopiero te cztery elementy razem sprawiają, że środowisko działa stabilnie przy setkach projektów i tysiącach użytkowników.