В 2022 году компания Autodesk приостановила деятельность в России. Перед проектными и строительными компаниями остро встал вопрос об импортозамещении продуктов Autodesk и других зарубежных вендоров. Застройщик «СЗ «Стадион «Спартак», занимающийся комплексным развитием территории на полуострове Покровское-Стрешнево, успешно перешёл от использования Autodesk BIM 360 Docs на систему SODIS Building CM. Рассказываем об опыте компании.
ООО «СЗ «Стадион «Спартак» является девелопером проекта комплексного развития территории бывшего Тушинского аэрополя. Самый первый знаковый проект компании — один из лучших стадионов Европы, домашний стадион футбольного клуба «Спартак-Москва» — «Открытие Банк Арена». Стадион успешно принял игры Кубка Конфедераций и матчи чемпионата мира по футболу летом 2018 года. В портфель компании также входит жилой комплекс комфорт-класса «Город на реке Тушино — 2018» общей площадью 726 тыс. м².
Ранее специалисты компании активно использовали решение Autodesk BIM 360 Docs, на базе которого были реализованы процессы организации и хранения проектных данных, согласование документации между подразделениями, выдача замечаний проектировщикам и визуальный аудит BIM-моделей.
При переходе с одной системы на другую амбициозных задач не ставилось. Была цель заменить и воссоздать привычные функции BIM 360 Docs, чтобы минимизировать трудозатраты и обеспечить удобство для пользователей. Ещё на этапе выбора ПО проводилось сравнение существующих аналогов и подбирались критерии сравнения согласно понятным потребностям бизнеса. Однако чем больше специалисты компании погружались в тонкости работы и функциональности различных систем, тем больше приходило осознание того, что необходимо расширять и углублять степень автоматизации существующих процессов, охватывая новые области. Поэтому при окончательном выборе системы большое значение имела возможность увеличения степени автоматизации, введение новых функций и процессов, адаптивность под нужды компании и гибкость настроек.
Что привлекло в SODIS Building CM
В результате долгого анализа, тестирования и сравнения систем была выбрана платформа SODIS Building CM, разработанная ГК «СОДИС Лаб». Решающими аргументами среди многих были следующие.
Система имеет одну из самых низких стоимостей лицензирования и внедрения. Разработчик предоставляет услуги по развёртыванию и настройке системы согласно требованиям заказчика, однако всегда есть возможность самостоятельной или совместной настройки. SODIS Building CM обладает практически неограниченной возможностью интеграции со смежными решениями: 1С, SAP, MS Project, Excel, Autodesk и другими. Как и в решении BIM 360 Docs, SODIS Building CM позволяет просматривать форматы Autodesk в браузере без необходимости скачивания больших файлов и установки специализированных приложений. Наиболее значимым преимуществом перед альтернативными решениями является то, что система предлагает практически полную адаптацию под нужды заказчика.
Например, очень гибкий механизм управления ролями пользователей (рисунок 1). Для удобства все пользователи заводятся в модель организационной структуры предприятия и подрядчиков. После этого создаются группы (роли) пользователей согласно выполняемым функциям в системе. Одних и те же пользователей можно включить в несколько групп, если это необходимо им для работы. Для каждой группы назначаются права работы и настраиваются общие папки. Такая гибкость и в то же время универсальность даёт многогранные возможности настройки работы пользователей, особенно при изменении их функций в системе.
Рис. 1 Организация ролевой модели прав в системе SODIS Building
Ещё одним большим преимуществом, которое отличает SODIS Building от конкурентов, является неограниченная возможность настройки разного рода процессов в системе. Изначально процессы формализуются в техническом задании на внедрение, но в данном случае была поставлена задача повторить процессы согласования документации по аналогии с BIM 360 Docs. В решении SODIS Building механизм настройки процессов на порядок мощнее. Всё начинается с настройки необходимых типов данных, например, тип проектная или рабочая документация. Далее для каждого типа описываются необходимые атрибуты, которые формируют карточки документов. В завершении работы в редакторе маршрутов моделируется сам процесс и прописываются механизмы его работы через назначение значений переменных и обработку событий.
Визуализация процесса создается с помощью редактора, напоминающего MS Visio (рисунок 2).
Рис 2. Редактор маршрутов для процесса согласования проектной документации
Таким образом, процесс любой сложности может быть настроен согласно требованиям заказчика.
Да, все эти возможности системы требуют более тщательного анализа существующих процессов и проектирование новых, формирование технического задания на внедрение, последующие настройки среды и их практическую апробацию на пилотном проекте. Необходимые в данном случае дополнительные действия, безусловно, усложняют процесс, но они дают полностью локализованную систему, которая закрывает обозначенные бизнес-процессы заказчика максимально адаптировано согласно разработанному техническому заданию.
Некоторые функции BIM 360 Docs в SODIS Building CM отсутствуют. Например, в системе нельзя сравнивать две версии документов (чертежи DWG или файлов PDF). Подобная возможность в BIM 360 Docs, к которой быстро привыкли сотрудники проектного подразделения компании, позволяет визуально показать изменения файлов относительно друг друга. Также не хватает поддержки электронной подписи и факсимильного штампа выдачи в производство работ. В настоящее время разработчики системы усиленно работают над этими и другими вопросами по усовершенствованию функциональности.
Работа с файлами и папками в SODIS Building CM
Работа по внедрению системы началась с воссоздания папочной структуры проекта для подготовки переноса данных из BIM 360 Docs. Быстро стало ясно, что SODIS Building имеет совершенно отличную логику работы от аналогов, которая основана на атрибутивных карточках. Если, например, в BIM 360 Docs создается папка и в неё загружаются данные, то в SODIS Building сначала создаётся карточка документа, а потом уже в неё загружаются данные. Карточка представляет собой универсальный «контейнер», который описывается необходимыми атрибутами, такими как «наименование проекта», «стадия проекта», «раздел», «дата создания», «автор» и многие другие. Состав и настройка атрибутов может быть уникальной для каждого типа данных системы, всё определяет пользователь согласно решаемым задачам.
Папочная структура проекта формируется автоматически благодаря универсальному механизму «смарт-папок». Такой «смарт-папкой» в системе называется определённый запрос к базе данных проекта для отбора необходимых карточек и настроек их отображения. Пример настройки такой «смарт-папки» приведён на рисунке 3.
После наименования «смарт-папки» указывается нужный тип карточек, в данном случае это редакции рабочей документации. После идут группы фильтров для отбора нужных данных. Правила в фильтрах задаются логическими условиями. После правил можно задать условия группировки и сортировки карточек в папке. Важно понимать, что создаваемые карточки попадают в «смарт-папки» автоматически, то есть при занесении данных в систему нужно создать карточку, описать атрибуты и загрузить в неё файлы, а формирование структуры проекта на основе «смарт-папок» произойдёт сразу после создания карточки. Пользователям в начале было непривычно, что нет необходимости заранее создавать папки для размещения файлов. Однако благодаря гибким возможностям представления данных, адаптируемым под каждую группу или пользователя, такой подход стал удобен и востребован. В зависимости от роли пользователя в системе сотрудники часто сами настраивали дополнительные папки для нужного отбора данных.
Рис 3. Пример настройки «смарт-папки» для редакций рабочей документации
В результате рабочее место отдельного пользователя могло включать в себя множество «смарт-папок» как системных, так и индивидуальных для большего удобства работы.
Рис 4. Пример настройки «смарт-папки» для редакций рабочей документации
Люди быстро привыкли к тому, что это не привычные папки, а система запросов и фильтраций, так как одна и та же карточка может быть отобрана и представлена в разных «смарт-папках». Пример структуры данных приведён на рисунке 4.
Благодаря тому, что вся атрибутика была тщательно проработана заранее, перенос данных из BIM 360 Docs прошёл достаточно быстро и незаметно для пользователей. Проекты мигрировали поочередно. В самом начале шла почтовая рассылка, что выбранный проект блокировался от изменений в BIM 360 Docs. Ночью скрипт выгружал данные проекта на сетевую папку в заданную структуру. Далее назначенные сотрудники «СЗ «Стадион «Спартак» создавали карточки и загружали в них файлы. Согласно описанным атрибутам карточки формировали привычную структуру в «смарт-папках». После завершения переноса данных пользователям давались необходимые права и работа переходила в новую систему.
Среднее время миграции проекта вместе с BIM-моделями составляла не более двух суток. Процессы согласования были также заранее настроены и пользователи могли немедленно приступать к работе.
Довольно быстро оказалось, что стандартного механизма хранения документов в карточке было недостаточно. В связи с частыми изменениями проектов, а на момент внедрения многие проекты проходили стадию рабочей документации, было необходимо ввести механизмы управления и координации изменений. В функциональности SODIS Building как раз удачно оказались проработанные на этот случай отдельные сущности системы — редакции.
С помощью специалистов компании «СОДИС Лаб» были перестроены карточки документации с возможностью хранения файлов не в самих карточках, а в редакциях, которые входили в состав карточек. Таким образом, при согласовании данных файлы фиксировались в редакциях, а при изменениях просто создавалась новая редакция в той же самой карточке. Все итерации согласования и изменений сохранялись в единой карточке документации, разбитой по редакциям. Поначалу это было непривычно, но после прохождения нескольких процессов согласований и внесений изменений в проект, пользователи довольно быстро освоили новые принципы работы системы. На рисунке 5 показан состав редакций внутри карточки.
Рис 5. Список редакций в составе карточки
В данном примере приведён комплект РД раздела АР — СТ26/01-13-АР2.5. В составе карточки мы видим две редакции — основной комплект и изменения, которые вышли позднее.
В системе настроены процессы согласования, о которых мы упоминали выше. Эти процессы были адаптированы под работу с редакциями, когда можно согласовывать редакцию в составе карточки независимо от наличия уже существующих и ранее согласованных редакций. При создании нового документа или при внесении изменений проектная организация формирует новую редакцию, в которую загружает файлы. Далее она в составе карточки идёт по кругу согласования, как предусмотрено в процессе. При согласовании документации представители заказчика сохраняют замечания в теле редакции. Если редакция отклоняется, то проектировщики обновляют данные в ней, создавая новые версии существующих файлов. После редактирования процесс согласования запускается по новому кругу до тех пор, пока не будет согласована текущая редакция. После успешного завершения согласования редакция описывается как согласованная и более изменениям не подлежит. При необходимости внесения правок, создаётся новая редакция и процесс возобновляется. При прохождении процесса согласования система наглядно показывает прошедшие этапы и текущий шаг согласования. На рисунке 6 приведён пример согласования нескольких редакций, когда процесс повторялся многократно.
Рис 6. Пример мониторинга процесса согласования редакций в составе карточки
На каждом этапе мы видим участника и результат его действий. Механизм «смарт-папок» позволяет отслеживать данный процесс путём сбора редакций по каждому шагу согласования или настройкой папки по нужному участнику процесса, где будут собраны редакции, находящиеся у него на рассмотрении в данный момент.
В качестве итога можно отметить, что, несмотря на довольно высокие трудозатраты на начальном этапе внедрения, когда делаются все необходимые настройки, система быстро даёт отдачу благодаря своим неограниченным возможностям адаптации. Можно целенаправленно автоматизировать тот или иной процесс при наличии детально описанного технического задания до мельчайших нюансов. Есть проблемы в плане понимания пользователями принципов работы системы, но они решаются на практике довольно быстро. Произвольный состав атрибутов даёт возможность получения любой отчётности, выгружаемой в формы Excel по шаблонам заказчика. Все технические вопросы быстро решались благодаря сопровождению сотрудников компании «СОДИС Лаб». В настоящий момент внедрение системы SODIS Building CM в «СЗ «Стадион «Спартак» продолжается и планируется реализация новых проектов с помощью данного решения.
