Очередная статья о том как и зачем нам переходить на BIM. Пособие для компаний и для Минстроя (лучше поздно чем слишком поздно).

Вообще BIM – это очень обширная технология, и целей её применения придумали уже гораздо больше, чем 25. Поэтому самое первое что нужно сделать перед переходом на BIM – составить перечень проблем, которые в принципе есть в стройке и мешают людям и машинам быть эффективными в ней. Перечень, кстати, можно составить методом опроса – среди сотрудников госорганов, подведомственных и региональных организаций, генпроектировщиков, генподрядчиков, субподрядчиков, специалистов по организации строительства, НОПРИЗ, НОСТРОЙ, профильных ассоциаций, экспертиз и т.п. Сейчас все любят опросы проводить, так что дарю идею всем желающим. Только нужно иметь силы потом выбрать все повторяющиеся, и составить не слишком длинный список из самого важного.

Теперь кратко опишем, какие действия предпринимает инженер (инженеры), чтобы в соответствии со всеми этими требованиями запроектировать будущий объект.

1. Перечень может быть таким к примеру:

   1) - неточные обмеры при реконструкции, потом в помещения не влезает оборудование

   2) - неточные объёмы материалов в спецификациях, потом приходится дозаказывать

   3) - неточные плановые сроки строительства, потом по факту всегда всё сдвигается вправо

   4) - неверные данные о ТЭПах объекта в разных местах (Экспертиза, ГАСН, заказчик, БТИ, архитектурный департамент)

   5) - неверные данные от подрядчиков о фактически выполненных объемах работ (пишут, что сделали больше, чем по факту)

   6) - неверные данные о стоимости материалов, за которые платит заказчик (в КС-2 написано по сметам, генподрядчик купил у подрядчика за меньшую сумму, подрядчик у поставщика – за ещё меньшую)

   7) - некачественная проектная документация, разделы не увязаны друг с другом, сети пересекаются, на стройке тратят время на переделку и дозаказ материала

2. Далее для каждой задачи пробуем найти решение, проверяя все имеющиеся технологии:

   1) - делаем все обмеры тахеометром, потом по точкам делаем чертежи;
   - делаем фотографии каждой стены, потом фотограмметрией собираем ортофотопланы стен, по ним с контрольными точками делаем замеры;
   - делаем лазерное сканирование, по облакам точек чертим чертежи – план и разрез;
   - делаем лазерное сканирование, по облакам точек строим обмерную 3D-модель в софте который позволяет выпустить из неё также и чертежи

   2) – пишем скрипт для сбора данных с чертежа в спецификацию автоматом на LISP, и к нему – регламент для проектировщиков, где какой должен быть тип линий чтобы скрипт правильно считал; в регламент прописываем процедуру контроля правильности типов линий;
   - вместо чертежей собираем 3D BIM-модель по разделу, в спецификацию данные выводим с модели

   3) … и так далее, для каждой задачи можно найти несколько способов решения, одним из которых возможно будет применение относящегося к технологии BIM инструментария

3. Далее выбираем одну, самую важную на наш взгляд проблему (или ту, решение которой с помощью BIM выглядит самым простым и очевидным), и смотрим, является ли её решение с помощью BIM наиболее разумным. Выбирать, если говорим про уровень Минстроя, тоже можно голосованием – среди тех же, кто участвовал в формировании перечня проблем на «нулевом» шаге, перед шагом 1. Предположим для примера, что выбрана проблема пространственных коллизий на стройке.
4. Далее последовательность действий такая:

   1. Ответить на вопрос «Зачем», для себя, и для всех, кто будет участвовать в процессе. Любое новшество, и BIM в том числе, полезно не само по себе, а когда решает конкретную задачу, устраняет конкретную проблему. В нашем случае: в строительстве есть проблема не увязанных друг с другом чертежей, т.н. «пространственные коллизии». Эта проблема приводит к увеличению сроков (на разработку авторских листов, к примеру) и некорректному определению объёма материалов в начале работ (нужны доп. отводы, повороты и т.п., длина коммуникаций увеличивается, подрядчики по инженерии перерезают несущие конструкции что приводит к снижению прочности и т.п.).

   2. Второй вопрос – «Как». Есть ли какое-то новшество, которое способно устранить проблему? Вообще устранять любую проблему можно разными способами. Конкретно эту раньше решали методом наложения друг на друга в плане различных систем (т.н. «сводный план сетей») и поиском мест их пересечения, изображения этих мест в разрезе и т.п. Эта система несовершенна, т.к. контроль был только визуальный, не все места находились, и при увязке обычно не учитывались конструкции (например, определить коллизии воздуховода и металлической фермы так нельзя, раскосы фермы идут под углом, и вычислить, где они пересекутся с воздуховодом, практически невозможно в плоскости). Новый способ решения – трёхмерное моделирование (даже не BIM, точнее всего лишь небольшая часть BIM). Вместо чертежей в плоскости делаем всё в 3D. Есть ли программное обеспечение, которое позволит решить эту проблему, поиск пространственных коллизий, не породив новых проблем, например, как из 3D получить чертежи? Да, есть. Смотрим какие есть примеры на рынке, формируем регламент, по которому будем работать на пилотном проекте (регламент должен написать кто-то кто уже прошёл этот путь, самим не получится). Далее приступаем к пилоту. Шагов будет несколько.

   • Первый шаг – моделирование: Revit, Renga. При правильной начальной настройке (шаблоне) после вычерчивания модели у нас есть возможность получить и 3D (элемент новой технологии) и чертежи – такие же как раньше (на самом деле даже лучше, это уже побочный положительный эффект). Чертежи дальше идут на стройку и используются как раньше.
   • Второй шаг – поиск коллизий: Navisworks, Solibri, Pilot BIM, BSF-manager, Collaborate Pro. Вообще можно их искать и вручную, визуально, можно даже в самом Revit, но для максимально эффективного и автоматизированного поиска нужен специальный софт, и он есть. Чтобы эффективно решать эту задачу, практика показывает, что нужна кроме софта методология (матрица коллизий и определение приоритетов, кто под кого подстраивается), а также возможность достаточно детальной настройки софта (что с чем проверять, что игнорировать, какие допуски установить по расстояниям – то есть что считать пересечкой, можно ли автоматизировать процесс при большом числе файлов для проверки и т.п.).
   • Третий шаг – отправка отчёта о коллизиях исполнителям и заказчику. Такая возможность тоже есть, либо через html-файл, либо через плагины, либо через bcf-файл. Процедура отправки, в каком формате и т.п., должна быть прописана в регламентах, чтобы не было бардака.
   • Четвёртый шаг – повторение первого, моделирование откорректированных 3D-моделей с целью устранить коллизии, и далее происходит итерационный процесс их устранения до получения идеала (идеала обычно не получается, поэтому в методологии должно быть прописано какое число коллизий и каких считается приемлемым и модель можно считать принятой).
   • Выдача получившегося результата (традиционных чертежей) на стройплощадку для выполнения работ (и проверки, достигнута ли цель). Цель была – получить отсутствие пространственных коллизий на этапе строительства. Технология применяется, и достижение цели контролируется – то есть после передачи на стройку должен быть контроль за вопросами подрядчиков по строительству, где коллизии всё же возникают – разобраться почему так возникло (смонтировали не по проекту, заменили сечение так как нужного не было, спрямили одну сеть не зная что она кривая чтобы потом без коллизий проложить другую сеть, или в матрице коллизий проектировщики не учли какой-то важный раздел, или не всё выпускалось из модели и что было плоское с тем и пересеклось, и т.п.).
   • По итогам пилота сделать выводы: новая технология работает/работает но плохо/не работает, и если работает плохо либо не работает – разобраться в чём причина: либо инструмент выбрали не тот (например устранением коллизий хотели сократить сроки строительства, а сократить не получилось – потому что они не из-за коллизий длинные а из-за сроков поставки оборудования, или согласований в ведомствах, или подрядчика слабого поставили), либо не всем объяснили как с ним обращаться (подрядчики спрямляли коммуникации вместо того чтобы по проекту прокладывать, или допуски и матрицу коллизий неправильно настроили, или с ПО не научили обращаться ответственного за работу в нём и он не справился). Делаем выводы по результатам, принимаем решение – работаем так дальше на других проектах, или отказываемся от этой технологии так как цель не достигается, или допиливаем методологию/скиллы/ПО и работаем дальше с допиленным. В управлении качеством это называется циклом Деминга (PDCA), в кибернетике примерно то же самое называют циклом Бойда (НОРД).

   3. Внедрение технологии на всех проектах. После успеха на «пилоте» (или «успеха с замечаниями», когда что-то нужно доработать) можно расширять новую технологию на другие проекты – знакомить всех сотрудников и подрядчиков с новым методом, объяснять, что и как тут работает, какие можно ошибки допустить, для чего это предназначено и для чего – не предназначено, что делать если что-то пошло не так, к кому обращаться. Именно на этом этапе можно начинать писать государственные или корпоративные стандарты – как применять конкретную технологию (3D-моделирование) для решения конкретной задачи (устранение пространственных коллизий). При написании стандарта желательно учесть, что ПО может быть разное, функционал может отличаться, поэтому стандартизировать только то, что принципиально для достижения результата и не зависит от ПО (фактически стандартизируется методология). Корпоративные политики допускают стандартизировать и ПО, а вот на государственном уровне это невозможно.

5. Параллельно с решением «самой важной» по итогам голосования задачи можно попробовать на пилотном проекте решать ещё одну-две задачи из топ-перечня по важности, если есть понимание что они могут быть решены использованием того же ПО и той же методологии. Если не могут – нужно искать те, что могут, чтобы не распыляться на много новых методологий и программ сразу. Но в любом случае ставить сразу более трёх целей при внедрении новой технологии – значит обычно не достичь ни одной, т.к. внимание распыляется, слишком много новой информации, и в итоге все только разочаровываются в возможностях нового метода устранять проблемы. Переходить к решению следующих задач из списка можно лишь после того, как прошли пилоты по первым трём, то есть для следующих трёх пилот должен быть тот, где первые три уже перешли в фазу «привычной» технологии.

Итого – что бы я рекомендовал делать для успешного перехода на BIM (или любую другую комплексную технологию, которая по обещаниям экспертов может решать сразу много задач):

- собрать перечень проблем в отрасли от максимального количества причастных (опрос из открытых вопросов, затем обработка ответов с объединением одинаковых)

- отранжировать методом голосования среди тех же кто отвечал на первый вопрос – какая проблема мешает больше всего, построить проблемы в списке от самой важной к неважным

- выбрать пилотные проблемы, выбрать пилотные проекты, где будут пробовать их решать, в команду пилотных проектов включить сотрудников кто будет в курсе происходящего и по итогам создаст внятные отчёты, а возможно и проекты стандартов по решению конкретных проблем

- далее по итогам пилотов писать стандарты и рекомендовать их применение в (Минстрою – в госзаказе, частным компаниям – у себя внутри), параллельно делая новые пилоты для решения новых задач из списка. Не везде решением проблемы будет BIM, но какая разница какую технологию будут использовать на пилоте, лишь бы она приносила результат.

Будучи единожды запущенным, этот процесс должен привести к постоянному улучшению качества работы в конкретной компании, или во всей отрасли в части госзаказа, если речь про Минстрой. Опросы, например, можно сделать ежегодными, и по их результатам оценивать проникновение новых технологий, пропадают ли «самые важные» проблемы с верхних позиций по мере внедрения новых технологий, или нет, соответственно если не пропадают – реагировать, узнавать почему не пропадают, а если пропадают – переходить к решению следующих по важности, тех которые в этом году окажутся в верхней части списка.