ОБЗОР ПО ДЛЯ BIM
drogomireckij a - ОБЗОР ПО ДЛЯ BIM

Алексей Дрогомирецкий

специалист BIM-технологий

Сегодня рынок уже достаточно велик, чтобы сделать невозможным выбор ПО под конкретную задачу без детальных знаний. 

За всё время развития технологии BIM моделирования появилось и постоянно развивается множество различных программных продуктов. В публикации «Поговорим о коллизиях!» я уже писал о том, как важно правильно выбрать набор программного обеспечения для проектирования объекта.

Наиболее продуктивным способом выбора под каждую конкретную задачу обычно является наличие в штате компании человека, который занимается пилотным тестированием продуктов. Нужно понимать, что, если в организации есть десяток человек, каждый из которых является специалистом в одном продукте, то их коммуникация между собой, с большой долей вероятности, не даст нужного результата, так как каждый будет нахваливать свой продукт, преуменьшая недостатки и выводя на передний план достоинства. Поэтому только человек, обладающий универсальными знаниями, сможет максимально честно и, насколько это возможно, объективно сравнить разные программы между собой. 

Далеко не каждая организация может позволить себе нанимать на работу человека, который уже является универсальным BIM-специалистом, поскольку его заработная плата в рынке, даже в регионе, на сегодняшний день может достигать шестизначных сумм. Также весьма затратно для компании содержать в штате человека, который в течение значительного промежутка времени будет посвящать бóльшую часть своего рабочего дня изучению и сравнению ПО. Поэтому я собрал для Вас базу информации по этому вопросу, то есть набор основных сравнительных характеристик и критериев оценки программного обеспечения, который в ряде случаев поможет решить, какой продукт наиболее удачен для той или иной задачи; либо, как минимум, даст точку отсчёта и некий вектор – направление, в котором Вам необходимо углубить знания для принятия решения.

В ходе повествования я буду обозначать очередной критерий и пояснять его суть, то есть что он в себя включает. А также приводить лучшие и худшие примеры реализации данного параметра в различных программных продуктах.

Выделим основные группы критериев оценки программного обеспечения:
1. Базовые
2. Взаимодействие “Open BIM”
3. Дополнительные

Сегодня поговорим о первой группе базовых критериев, которые интересуют проектную организацию в первую очередь при выборе ПО.

Первый и основной критерий – это специализация. То есть под какой раздел или разделы проектной и рабочей документации «заточен» данный продукт; и насколько это программное обеспечение универсально. Ведь, нет смысла сравнивать между собой инструмент архитектора и ПО для конструктора – это всё равно, что сравнить шпатель и молоток. А, приобретая универсальный продукт, можно предложить персоналу использовать одну лицензию на двух, трёх или даже четырёх специалистов. При данном подходе важно не увлекаться, поскольку такое решение реалистично только на первых этапах внедрения и лишь в том случае, если количество объектов, выполняемых с использованием BIM технологии, ограничивается небольшим процентом от общего количества выполняемой проектным отделом работы, а сроки по этим объектам весьма растянуты.

Из первого критерия сразу вытекает второй – это удобство работы и разнообразие функционала для каждого конкретного специалиста. Надо понимать, что, чем более универсален продукт, тем сложнее разработать набор инструментов для каждого отдельного специалиста, который сравнится по качеству с узконаправленным продуктом. Так происходит, во-первых, из-за штата специалистов компании-разработчика ПО, который должен кратно увеличиваться вместе с ростом числа специализаций. Во-вторых, из-за необходимости увязки между собой сразу нескольких наборов инструментариев внутри единого продукта, что тоже, в свою очередь, требует от разработчика решения серьёзных управленческих и коммуникационных проблем. В текущих реалиях разработчик ПО обычно старается не пропорционально увеличить штат, а сэкономить или, как сейчас модно говорить, «оптимизировать» процессы, и, по факту, при расширении до пяти направлений (АР+КР+ОВ+ВК+ЭОМ) увеличить штат в лучшем случае всего в 2 раза или вообще выполнять своими силами. Так, например, если над пятью направлениями Ренги сегодня, на десятый год разработки данного продукта, трудятся 20-25 разработчиков (на момент февраля 2020 года актуальная информация была 23 человека), то команда разработчиков ArchiCAD ещё при выходе версии 4.55 1994 года, когда архикаду было также 10 лет, уже тогда насчитывала более 20 человек, хотя они закрывали в основном одно направление – архитектуру. А сегодня их команда насчитывает уже порядка 200 программистов, которые, помимо постоянного апгрейда и расширения функционала архитектора, добавляют дополнительные функции для:

– лучшего в отрасли Open BIM взаимодействия;

– отличного по качеству картинки инструмента 3д-визуализации;

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

В свою очередь Autodesk, хоть и насчитывает несколько тысяч разработчиков, но при этом развивает сразу несколько десятков продуктов – актуальное их число на сегодня – 83.

Третий критерий – это стоимость и доступные типы лицензирования, то есть имеются ли постоянные версии ПО и в какой период они окупаются. Либо данный продукт поставляется только по ежегодной подписке, что благоприятно при старте, но невыгодно на дистанции. 

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

Далее, мы переходим к ещё одному аспекту – это баги и ошибки (будь то критические закрытия программы, блокировка отдельных функций или ошибки в подсчёте спецификаций), скорость их устранения, а также лояльность технической поддержки к пользователю. Сложно, или даже невозможно, объективно ранжировать разработчиков по этому принципу. Но общую тенденцию выделить можно однозначно – чем больше продуктов (или специализаций, о чём я говорил выше) ведёт один вендор, тем значительнее баги и проблемы могут сохраняться в отдельных его продуктах в течение весьма продолжительного промежутка времени. Страдают в этом случае чаще всего те продукты, которые не пользуются популярностью, либо не входят в текущую стратегию развития компании-разработчика, которая может периодически бросать все свои силы на релиз какого-либо нового продукта.

В данной публикации мы разобрали первую группу критериев оценки ПО – базовые критерии. В следующих частях материала мы раскроем так же взаимодействие в концепции “Open BIM” и дополнительные критерии, на которые следует обратить внимание при выборе программного продукта.