Останніми роками BIM-спільнота стрімко рухається в бік автоматизації.
Ледь не кожен пост ВІМ ентузіастів демонструє навички автора в програмуванні, і це вражає звичайних спеціалістів будівельної галузі, надаючи ВІМ сакрального значення відомого тільки гуру. Але це як вражає, так і відлякує одночасно.
Але BIM – це не сакральне знання для «обраних».
Це дружня технологія, яку може опанувати кожен – якщо використовувати правильні інструменти для правильних задач.
Python-скрипти, експортування в Parquet, нічні обробки сотень моделей, перевірки через класифікатори й машинну аналітику – усе це стає частиною процесу і більшість користувачів починає сприймати ВІМ як щось складне, що вимагає надзвичайних знань та витрат.
В автоматизації немає нічого поганого.
Такі підходи справді потрібні у великих компаніях або при роботі з великими портфелями проектів.
Але дедалі частіше ми бачимо інший феномен – BIM ускладняється не через моделі, а через надмірне програмування. Ми починаємо “лікувати” BIM кодом там, де вже існують простіші й надійніші рішення.
Програмування починають застосовувати там, де воно не тільки не допомагає, а навіть шкодить – ускладнюючи роботу, підвищуючи ризики помилок і створюючи додаткові технічні бар’єри.
Це помітно у все більшій кількості компаній: намагання будувати цілий ІТ-стек навколо даних, які насправді не потребують такого рівня складності.
То де починається проблема?
Проблема виникає тоді, коли програмування намагається вирішити задачі, для яких воно не призначене.
Наприклад, компенсувати недоліки вихідних даних, виправляти некоректні IFC, або автоматично “здогадуватися”, який параметр мало б містити значення FireRating.
У певний момент автоматизація, яка мала б спростити роботу, починає її ускладнювати:
– з’являються складні скрипти, які важко підтримувати;
– виникають ризики масових помилок у моделях;
– BIM-спеціалісти витрачають час на налагодження коду, а не на перевірку якості інформації в моделі;
– процеси робляться важчими, ніж були до автоматизації.
Усе це відбувається попри те, що на ринку вже є інструменти, які виконують багато подібних задач точніше та безпечніше.
Типовий сценарій: у різних моделях значення FireRating записані як “EI30”, “30min”, “0.5h”, “E60”, “Fire90” тощо.
На перший погляд здається логічним автоматично замінити це скриптом і привести до одного формату.
Проблема в тому, що в моделі можуть бути й інші параметри з подібними назвами – “FireZone”, “FireCompartment”, “FireProtectionClass” – і скрипт може або не змінить нічого, або змінить не те, або (найгірше) змінить щось, що зовсім не FireRating, або знизить рівень вогнезахисту на важливому елементі.
Ці ризики не теоретичні – вони трапляються регулярно.
І без візуального підтвердження їх практично неможливо проконтролювати..
Ще складніше, коли в моделі взагалі немає показника часу або меж пожежного відсіку.
У такій ситуації автоматизація не може визначити правильний FireRating, бо значення залежить не від тексту в параметрі, а від контексту моделі, ролі елемента, типу приміщення, нормативів країни чи класу будівлі.
Тобто програмування намагається вгадати те, що має бути визначено на основі норм і контексту – і саме тут воно стає небезпечним.
Існують задачі, які автоматизація вирішує блискуче: масові експортування, аналітика великих наборів даних, нічні перевірки сотень моделей.
Але на багатьох проєктах це просто не потрібно.
Solibri, Bexel та подібні інструменти вже мають усе, що необхідно для перевірок даних моделі, визначення ролі елементів в контексті моделі, знаходження помилок, перевірки відсутніх або неправильних параметрів та аналізу геометрії, зв’язків та функцій приміщень.
І головне миттєвої комунікації між учасниками проекту з адресацією проблеми та контролю за виконанням.
Їхня сила – у розумінні простору, контексту та логіки будівлі.
Скрипти ж працюють переважно з текстом і таблицями, що робить їх менш надійними там, де рішення залежить від просторових відносин та розуміння будівельних технологій.
Для більшості проектів, де немає потреби завантажувати і аналізувати сотні моделей щоночі, готові інструменти значно ефективніші та безпечніші за кастомне програмування.
Автоматизація має сенс, коли є велика кількість моделей або повторюваних задач, потрібно вести історію змін або масштабну аналітику, необхідна інтеграція з базами даних або ERP або компанія працює з портфелями на сотні проєктів і потрібно нормалізувати великі масиви даних.
У цих випадках програмування не розкіш, а необхідність.
Але у звичайних проектах, де модель перевіряється вручну раз на тиждень, а не щоночі, складні коди тільки створюють зайвий тягар.
Багато думають що – “Автоматизація = менше помилок”. Але якщо виникає велика помилка – вона поширюється миттєво і непомітно.
То що автоматизація – зло? Ні.
Автоматизація – це сила, але за умови правильного керування.
Правильне правило таке – «автоматизація – це інструмент». Вона прискорює процеси, але одночасно робить рух даних непомітним.
Тому без сильного людського контролю автоматизація підвищує ризики, а не знижує їх.
Автоматизація не повинна бути сліпою.
Одна з найважливіших причин, чому Solibri залишається золотим стандартом у перевірці BIM-моделей, це те, що автоматизація в Solibri базується на логіці, а не на даних.
У Python-скриптів логіка йде так:
“Візьми дані – перезапиши – експортуй – онови”
Якщо в даних є помилка – скрипт її масово розмножить.
У Solibri логіка інша:
“Перевір дані за правилами – покажи, що неправильно – нехай людина вирішить”
Solibri ніколи сам нічого не змінює. Він лише оцінює, порівнює, виявляє помилки, дає попередження, показує ризики.
Він не втручається в дані автоматично. Він допомагає людині прийняти правильне рішення.
В кінці кінців хтось має ставити підпис. І краще ставити його коли ти контролюєш процес.
І головне не слід ускладнювати і лякати словом ВІМ тих, хто тільки починає знайомитись з технологією.
ВІМ, а особливо відкритий ВІМ це набір інструментів кожен з яких доцільний для конкретної задачі. Не потрібно недоліки однієї технології компенсувати надмірним програмуванням, коли існують інструменти, які виконують ту саму роботу точніше, безпечніше та зрозуміліше.
