Почему коммерческий инжиниринг не спешит менять BIM-софт
Евгений Булычев — заместитель начальника отдела информационного моделирования «Рок Энд Милл».
«Чтобы обучить сотрудника современному BIM-софту и вывести его на профессиональный уровень, нужны годы практики. Поэтому, когда специалист долго работает в одной программной среде, просто предложить ему другой продукт недостаточно. Без поддержки компании такой переход может оказаться для него слишком затратным по времени и усилиям», — отмечает Евгений Булычев, руководитель отдела информационного моделирования «Рок Энд Милл»
По словам эксперта, на профессиональное освоение сложного BIM-софта может уходить около трех лет. За это время специалист выстраивает собственную систему работы: накапливает библиотеки, шаблоны, скрипты, привычные сценарии. Это перестройка всего рабочего процесса. На сложных инженерных задачах это особенно трудно сделать. Опытный проектировщик может годами работать в одной среде, постепенно повышая производительность. При переходе на другой инструмент ему приходится заново осваивать значительную часть операций.
Реальная стоимость миграции включает не только лицензии. В нее входят обучение сотрудников, время на адаптацию, перестройка внутренних стандартов и процессов, перенос накопленных наработок и возможное снижение производительности на переходном этапе. Сопутствующая инфраструктура — настройка рабочей среды, подготовка библиотек и шаблонов, консультации разработчика, время BIM-специалистов — все это затраты, которые редко учитываются при сравнении по цене лицензии.
«Недостаточно просто дать софт проектировщику. Нужен целый BIM-отдел, который будет его сопровождать: настраивать, подготавливать и передавать проектировщику уже готовое решение. Проектировщик — он художник, а мы ему готовим краски и кисти», — объясняет Булычев.
Более низкая стоимость отдельной лицензии еще не означает более низкую стоимость владения. Если новый продукт требует создания дополнительной инфраструктуры и постоянного сопровождения, экономический эффект необходимо считать на уровне всего рабочего процесса.
Крупные промышленные компании могут создавать пилотные проекты, выделять команды для тестирования новых решений, взаимодейство-вать с разработчиками и формировать требования к продукту. В ре-зультате они становятся не только пользователями, но и участниками развития отечественного ПО. Пилотные проекты дают разработчикам обратную связь от реальных пользователей. Компании формируют требования к функциональности, выявляют ограничения и помогают определить, какие инструменты нужны проектировщикам. Так фор-мируется экосистема: разработчики совершенствуют продукты, компании получают подходящие инструменты, рынок — новых специалистов с практическим опытом.
Для коммерческого инжиниринга ситуация иная: проектная компания работает в рамках конкретных сроков, бюджета и обязательств перед заказчиком. «Нам необходимо выполнять проекты, соблюдать сроки и зарабатывать. Поэтому мы можем внедрять новый инструмент там, где он уже позволяет решать рабочие задачи с приемлемой эффективностью», — объясняет Евгений Булычев.
Осторожность коммерческого бизнеса не означает отказ от отече-ственных технологий. Речь о другом подходе: сначала проверяется конкретная задача, затем оценивается результат, и только после этого принимается решение о масштабировании.
«Чтобы отечественный софт развивался, его нужно использовать в реальных проектах. В крупных компаниях есть возможность выделять ресурсы на такую работу: тестировать продукты, давать разработчикам обратную связь, ждать доработок. Для коммерческой проектной компа-нии такой процесс гораздо сложнее встроить в текущую экономику проектов», — отмечает Булычев.
«В подразделение пришли молодые специалисты, которые умеют с ним работать, и поэтому технология закрывает конкретные задачи», — рассказывает эксперт.
В более сложных направлениях картина иная. В «Рок Энд Милл» тестировали отечественные решения для задач инженерного обеспечения — вентиляции и электрики. После оценки возможностей и необходимых ресурсов от дальнейшего перехода отказались: для полноценного внедрения требовались дополнительное обучение, настройка рабочей среды, постоянное взаимодействие с консультантами и отдельный специалист, который занимался бы развитием решения внутри подразделения.
«Чтобы двигать такой софт внутри отдела, нужен человек, который будет этим заниматься всерьез: разбираться, общаться с разработчиками и постепенно настраивать работу. Это требует отдельного ресурса», — отмечает Булычев.
Импортозамещение происходит не по принципу полной замены одного стека другим. Рынок движется к точечной замене отдельных инструментов — там, где продукт достаточно зрелый и есть компетенции.
-
Renga — BIM-платформа для архитектурного и инженерного проектирования.
-
NanoCAD и решения на его базе — для задач проектирования и информационного моделирования конструкций.
-
IndorSoft — инфраструктурное проектирование, дороги и генпланы.
Зрелость продуктов различается в зависимости от задачи.
«Если говорить о том, где отечественные решения уже показывают себя лучше, я бы выделил направление генплана и транспорта. В частности, IndorSoft — это как раз история про Civil 3D и дороги, и по тому, что я вижу и слышу от коллег, у них решение уже действительно работает», — говорит Булычев.
Вопрос импортозамещения стоит рассматривать не на уровне «российский или зарубежный софт», а на уровне конкретных инженерных задач.
В ближайшей перспективе наиболее реалистичный сценарий для коммерческого инжиниринга — гибридный подход.
Компания использует привычные решения там, где переход приведет к существенным потерям производительности, и одновременно внедряет отечественные продукты там, где они уже способны закрывать рабочие задачи.
Постепенно это позволяет накапливать внутреннюю экспертизу, обучать специалистов, тестировать новые продукты на ограниченном количестве задач и оценивать экономический эффект. Заодно разработчики получают обратную связь не только от крупных промышленных заказчиков, но и от коммерческого инжиниринга, где особенно важны скорость, удобство и предсказуемость результата.
Опыт отдельных подразделений показывает: успешное внедрение начинается не с решения «заменяем весь стек», а с ответа на более узкий вопрос — какую конкретно задачу новый продукт уже способен закрыть без существенных потерь.
Нехватка специализированного функционала В некоторых случаях задачу удается решить только через обходные сценарии — фактически создавая внутри модели дополнительные элементы, компенсирующие отсутствие нужного инструмента.
«В Renga, например, пока не хватает функционала. Там многое приходится решать через моделирование — появляются своеобразные «костыли». Для промышленного проектирования это особенно чувствительно, потому что объекты часто нестандартные и типовых инструментов может не хватать», — говорит Булычев.
Организация модели и обмен данными
При работе с некоторыми отечественными решениями сложные разноуровневые объекты приходится разделять на отдельные файлы, а затем собирать и координировать в отдельной среде общих данных. Это создает дополнительные операции и может потребовать приобретения и сопровождения еще одного ПО. Проблема выходит за пределы одной функции: меняется весь процесс работы с моделью.
Отдельный вопрос — отсутствие понятного для рынка сравнительного теста производительности. Перечень функций не показывает, насколько быстро проектировщик выполнит реальную задачу.
По мнению Булычева, показательной была бы демонстрация полного рабочего цикла на одном и том же объекте: от моделирования до получения чертежей и спецификаций, выгрузки модели и передачи данных в смежные системы. Если российский продукт позволяет выполнить этот цикл за сопоставимое время с привычным ПО, необходимость перехода можно оценивать предметно.
«Если бы мне показали в отечественном софте весь процесс — от моделирования до получения чертежей, спецификаций и выгрузки моделей — и в сравнении с условной Tekla Structures было бы видно, что по времени это занимает столько же или даже меньше, вопросов о переходе было бы гораздо меньше», — отмечает эксперт.
Такой подход позволяет перейти от абстрактного спора о том, «лучше» или «хуже» российский продукт, к измеримым критериям: сколько времени занимает задача, сколько операций требуется, какие дополнительные инструменты используются и какой результат получает проектировщик.
Для проектной компании принципиальны: возможность решить конкретную инженерную задачу, скорость работы, техподдержка, обучение, совместимость с другими инструментами и стоимость перехода. К этому стоит добавить готовность компании инвестировать в инфраструктуру вокруг продукта — ведь даже хороший инструмент не даст результата без настроенной рабочей среды, библиотек, шаблонов и человека, отвечающего за развитие решения.
Следующий этап — это не только доработка функциональности, но и появление прозрачных бенчмарков, реальных кейсов внедрения и понятной экономики перехода. Вопрос уже не в том, переходить ли на отечественный BIM вообще. Вопрос в том, какие задачи уже можно передать российским решениям без потери качества — и где такой переход пока экономически преждевременен.
Опубликовано в журнале “Золото и технологии”, № 3 (73)/осень 2026 г.
