IYNO (Айно) — компания, которую в 2017 году запустила команда лидеров рынка с более чем 10-летним опытом в проектировании и строительстве, разработке и внедрении комплексных информационных систем. Компания видит свою миссию в создании и развитии платформы с одноименным известным названием, которая предоставляет достоверные, актуальные и своевременные данные для принятия решения на всех этапах жизненного цикла объекта строительства, обеспечивает бесшовный процесс передачи информации между застройщиком, подрядчиком и банком в режиме реального времени. Расскажем о том каким образом IYNO сокращает трудозатраты при работе с данными. В методологии IYNO учтены все сложности, встречающиеся в процессе формирования ведомостей объёмов работ и материалов, и реализованы функции, позволяющие их избежать. Мы не изобрели принципиально новый процесс, но позволили существенно сократить трудозатраты специалистов при работе с данными BIM модели и ускорили движение данных от проектной модели до ведомостей объёмов работ.
В этой статье я описал далеко не весь функционал IYNO, а только то, что вы можете прямо сейчас бесплатно протестировать в IYNO Start на своих или демо-данных. Если вы хотите знать roadmap разработки, напишите нам через сайт iyno.ru или любым удобным для вас способом связи. И я, и Анастасия Морозова будем рады ответить на ваши вопросы.
Технология информационного моделирования зданий BIM долгое время рассматривалась как способ эффективной совместной разработки проектных решений, выпуска проектной и рабочей документации, повышения качества проектов, их визуализации, вариативной проработки и обоснования решений. И тут современные IT-инструменты справляются великолепно. Огромное число проектных компаний освоили проектирование с применением BIM, систематизировали свои процессы, разработали или адаптировали под собственные нужды регламенты, библиотеки и шаблоны. Но заканчивается путь информационной модели всегда одинаково, разобранная на чертежи и спецификации она продолжает путь в сметный отдел, отдел ПТО и далее на строительную площадку в виде классической «бумажной» документации.
Первыми после проектировщиков в BIM-процесс вовлеклись специалисты сметных отделов и ПТО. На поверхности лежит идея автоматизации разработки ведомостей объёмов работ и повышения их качества. Суть решения заключается в сопоставлении (привязке) элементов информационных моделей со справочником работ, содержащим информацию о потребности в материалах и иных ресурсах. Каждая работа агрегирует какой-либо атрибут связанных с ней элементов, тем самым определяется её суммарное количество.
Рис. 1. Сопоставление элементов информационной модели со справочником работ
На первый взгляд, процесс выглядит довольно легко, но на практике задача решается не так просто. Необходимо иметь высокие компетенции в работе с BIM системами, формировать сводные модели и непрерывно контролировать их информационное наполнение. Полный цикл от получения моделей до выпуска ведомостей занимает продолжительное время, за которое проект успевает пройти несколько итераций изменений и данные документов перестают быть цельными, актуальными и нужными.
Сложность процесса зачастую приводит к тому, что ПТО и сметный отдел решают свои задачи классическим способом по 2D документации. Попытка переложить расчёт объёмов работ и материалов из модели на BIM-подразделения не приводит к качественно иному процессу, ведь расчёт необходимо проверить, а без владения тем же BIM-инструментарием это можно сделать только по чертежам вручную.
В итоге автоматизация процесса формирования ведомостей выполняется формально. Внедрены новые инструменты, новые процессы, данные берутся из BIM, но ускорения и сокращения трудозатрат не происходит. В чём же коренная сложность организации BIM-процесса для решения задач ПТО и сметного отдела и как ее можно упростить, не снижая эффективности работы? Сложностей на самом деле несколько, и каждая из них заслуживает отдельного внимания. В свое время команда IYNO на собственном опыте столкнулась с этими сложностями и нашла результативное решение. Теперь хотим поделиться им и с вами.
Камни BIM преткновения
Сложность экспорта данных и формирования сводной модели
Привязка элементов моделей к справочнику работ не является базовым функционалом ПО для разработки информационных моделей и выпуска проектной и рабочей документации, но есть множество решений, позволяющих выполнять расчёт ведомостей объёмов работ с применением BIM. Все подобные системы предполагают либо расширение функционала базового ПО для моделирования плагинами, либо экспорт исходных информационных моделей в сторонний формат и объединение их на своей стороне в сводную модель.
Работа по первому сценарию неэффективна по многим причинам:
- Каждому специалисту необходимо приобрести дорогостоящее и многофункциональное ПО, предназначенное для моделирования лишь для того, чтобы установить на него плагин расчёта ведомости объёмов работ.
- Крупные проекты состоят из десятков моделей. Для примера, комплексная модель ЖК площадью 200 тыс. м2 может состоять из 60 моделей по различным разделам и корпусам. Одновременное их открытие в тяжёлом исходном формате требует применения высокопроизводительного компьютера, да и в этом случае комфортной работа не будет. Открытие моделей поштучно или какими-то фрагментами также будет неудобной, ведь открытие даже одной модели занимает до нескольких минут, а их десятки.
- Если сопоставление элементов с работами хранится в самих моделях, то при получении свежего релиза от проектировщика потребует проработки сопоставлений заново.
Работа в отдельном ПО с предварительной выгрузкой моделей в промежуточный формат также имеет сложности.
- Процесс трансформации формата моделей и формирование сводной сборки занимает довольно много времени. Часто это связано с открытием каждого исходного файла и экспорта его данных с последующей сборкой всех промежуточных файлов в сводный.
- Работа в ПО для формирования ведомости объёмов работ ведётся в однопользовательском режиме, а вовлечение в процесс формирования ведомостей работ специалистов по различным направлениям требует создания для каждого из них своего рабочего файла или организации поочерёдной работы. В любом случае необходимо будет управлять множеством версий файлов и не забывать следить за обновлениями для каждого участника процесса.
В любом из указанных вариантов присутствует большое количество рутинных, непроизводственных трудозатрат, связанных с работой в множестве файлов, конвертацией и ведением архива версий.
Сложность определения состава работ для элементов. Опять и опять
Информационные модели имеют некую базовую декомпозицию элементов. Например — по категориям, семействам и их типам. Таким образом, мы можем понять, что перед нами Стена/Базовая стена/Стена бетонная толщиной 200 мм. Для определения состава работ и материалов для данной конструкции нам недостаточно этой информации. Дополнительно необходимо определить марку бетона, армирование, расположение в подземной или наземной части здания и т. п. Зачастую для декомпозиции строительных и инженерных конструкций предлагается использовать классификатор элементов, но если пытаться в нём отразить всю необходимую для определения работ информацию, то он будет очень объёмный. Его будет сложно поддерживать, а применять его придётся проектировщику, указывая для каждого элемента код по классификатору и не забывать обновлять его в случае изменений свойств элемента. Получается, что автоматизация деятельности одного участника проекта происходит за счёт существенного увеличения трудозатрат другого.
Из данной ситуации можно выйти, анализируя атрибуты элементов моделей. Их тип, материал и расположение могут храниться в отдельных атрибутах, и ПО для расчёта ведомостей позволяет сформировать правила выбора элементов по значениям их атрибутов. Например, выбрать все стены по разделу КЖ, в надземной части здания, толщиной 200 мм и определённым классом бетона. Но и тут есть сложности. Зачастую интерфейс создания правил такого поиска очень сложен, а процесс — трудоёмок. Это напоминает программирование или продвинутую работу в Excel, когда мы для каждого случая прописываем условие, используя булеву алгебру.
Самое неприятное, что часто для поиска и выбора элементов применяется анализ атрибутов элементов, но сама привязка элементов к работе осуществляется всё равно по их id — уникальному номеру, задаваемому каждому элементу автоматически при его создании. Это приводит к тому, что, например, бетонная стена толщиной 200 мм была привязана к соответствующей работе «Возведение бетонных стен толщиной 200 мм», но в дальнейшем, при развитии проекта, она изменила свои свойства, толщину, марку бетона или вообще стала кирпичной, но привязана она осталась к первоначально сопоставленной работе. В итоге нам на каждой итерации проектной модели необходимо не только определять, какие новые конструкции пока не связаны с работами, но и выявлять ошибки существующих связей. Все это значительно увеличивает трудозатраты и повышает вероятность ошибки.
Сложность разнообразия информационных требований
Над проектами зачастую трудятся десятки специалистов. Разработка ведётся не в едином файле, а в множестве связанных между собой моделей по различным разделам, системам и корпусам. Каждая проектная компания стремится минимизировать трудозатраты по их разработке, и в основном это обеспечивается следующими инфраструктурными мероприятиями:
- Разработка регламентов. Выстраивание типового, повторяющегося из проекта в проект процесса проектирования с применением BIM и внедрения данного процесса в производственный цикл. Оформляется данный процесс в виде набора регламентов, актуализация и внедрение которых происходит непрерывно.
- Разработка шаблонов. Стоит пояснить, что «шаблон» — это не типовое проектное решение, а преднастроенный файл модели, содержащий все необходимые наработки для моделирования, оформления чертежей и спецификаций, совместной работы и выполнения инженерных расчётов. В шаблонах содержатся правила описания компонентов моделей — параметры. В параметры компонентов при разработке проекта вносится всевозможная информация, описывающая артикулы и производителей изделий и материалов, принадлежность их к системам и частям здания, инженерные характеристики, количественные показатели. Далее информация из параметров отображается на чертежах и учитывается при разработке спецификаций. Качественный шаблон в совокупности с регламентами и инструкциями это залог успеха проектной компании, без него на каждом проекте придётся начинать новую жизнь, проходить по старым граблям и заново обучать специалистов.
- Разработка библиотек компонентов (семейств). Разработка компонентов информационных моделей (семейств) занимает весомую долю в общих трудозатратах проекта. Компоненты должны соответствовать шаблонам проектов, так что даже публичные или предоставленные производителями оборудования и материалов библиотеки компонентов требуют адаптации.
- Разработка средств автоматизации. Применение плагинов и скриптов стало неотъемлемой частью разработки моделей. Они позволяют сократить до нуля множество рутинных, не творческих задач, найти оптимальное проектное решение, выполнить анализ проекта и т. д. Важно отметить, что в основном скрипты и плагины разрабатываются под конкретные шаблоны проектов, ведь на вход они получают информацию из конкретных параметров компонентов моделей и на выходе записывают информацию в конкретные параметры библиотечных компонентов, размещённых в моделях.
Российское сообщество BIM-специалистов проделало огромную работу по разработке унифицированных регламентов, шаблонов и правил разработки семейств. Данные стандарты позволили совершить значительный прорыв в освоении технологии BIM в строительной отрасли, но в отрыве от конкретных проектов и компаний невозможно предусмотреть решение всех возможных задач и разработать единый, устраивающий всех процесс. Регламенты и шаблоны продолжают развитие внутри проектных компаний, тем самым совместимость их между собой постепенно утрачивается.
Технический заказчик, впервые применяя BIM для решения своих задач, адаптируется под принимаемые от проектировщика модели, выстраивает процесс автоматизации расчёта ведомости объёмов работ и материалов и согласовывает дополнительные требования по их информационному наполнению. Настраиваются справочники работ с указанием суммируемых показателей конструкций, формируются поисковые запросы для выборки из информационных моделей однотипных элементов с целью дальнейшей их привязки к работам. Это непростая задача, но, пройдя первую итерацию, можно использовать наработки для актуализации ведомостей работ и автоматизации расчётов на всех последующих проектах.
Для повторного применения выстроенного цикла необходимо выдать проектной компании информационные требования, в которых учитывается требуемая для расчёта ведомостей степень детализации и информационного наполнения моделей. В этот момент наступает конфликт интересов технического заказчика и проектировщика. В проектной компании возникает естественное желание сохранить свои наработки, шаблоны и скрипты автоматизации, ведь при сохранении привычной инфраструктуры проектировщику не потребуются дополнительные трудозатраты на её доработку и адаптацию сотрудников. Учитывая, что у проектной компании и даже конкретного проектировщика одновременно в работе могут находиться проекты разных заказчиков с разными информационными требованиями, это полностью рушит идею о едином автоматизированном производственном процессе, накоплении библиотек элементов и развитии шаблонов.
Рис. 2. Картина мира Заказчика и Проектировщика. Заказчик выдаёт всем проектировщикам требования, но у проектировщика несколько заказчиков и у каждого из них свои требования.
Даже при ответственном отношении проектной компании к контролю качества моделей в такой ситуации неизбежны ошибки в соблюдении требований к информационному наполнению, что приводит к дополнительным издержкам трудозатрат и времени на их выявление и устранение.
Сложность конвертации единиц измерения
Неочевидная, но неприятная сложность, добавляющая трудозатраты и не дающая полностью автоматизировать процесс. В строительстве количество многих работ и материалов принято измерять не в единицах измерения системы СИ, а в километровых бухтах, двухсотлитровых бочках, тысячах метров квадратных и прочих нестандартных единицах. Эти единицы измерения относятся к физическим величинам (длина, объём, площадь и т. д.), и, например, перевод значения из кубических метров в двухсотлитровую бочку выполняется банальным умножением на коэффициент k=5. К сожалению, распространённое ПО не предполагает такую тщательную работу с единицами измерения, и количественные показатели ведомостей объёмов работ и материалов выдаются из них в кг, м, м2, м3 и штуках. Дальнейшая конвертация в требуемые единицы измерения происходит в Excel, но это мало того, что требует существенных трудозатрат, так и приводит к ошибкам.
Совокупность указанных проблем не создаёт условий для радикального сокращения трудозатрат и ускорения на этапе формирования ведомостей объёмов работ на основе BIM модели, а высокая сложность задачи требует вовлечения в процесс дорогостоящих BIM- и IT-специалистов. В результате даже если проект выполнен проектировщиком с помощью BIM, заказчик фактически не может работать с BIM данными и продолжает принимать решения на основе ручных расчетов.
IYNO предлагает решение
Команда IYNO не понаслышке знает о сложностях и особенностях применения BIM на всех этапах инвестиционно-строительных проектов. Начиная с 2017 года мы выстраивали цикл управления строительством на основании данных BIM-моделей. Разработанная нами методология включает в себя не только формирование на основе информационных моделей ведомостей объёмов работ и материалов, но и фиксацию факта выполнения работ по каждому элементу, взаимосвязь работ по элементам с исполнительной документацией, реестром дефектов и нарушений. За эти годы мы чётко сформулировали концепцию единого бесшовного процесса и вложили её в разработку IYNO.
IYNO — это российская облачная платформа для управления стройкой на основе достоверных BIM-данных. В линейке продуктов IYNO широкий спектр решений для формирования ведомостей объёмов работ и материалов, управления строительством и даже для осуществления банковского финансово-строительного контроля.
Сегодня мы бы хотели рассказать о нашем базовом продукте IYNO Start: постараемся показать, как он справляется с описанными выше сложностями.
Обеспечение совместной работы и интеграция с СОД
Классические десктопные приложения постепенно уступают место облачным решениям. Нам уже привычно редактировать документы в облаке, создавать презентации, работать с календарными графиками, хранить файлы и обмениваться ими. Даже ПО для BIM-моделирования, хоть и представлено в виде десктопных приложений, но обеспечивает совместную работу через облачные среды общих данных (СОД). IYNO — это облачная многопользовательская система, позволяющая нескольким пользователям вести одновременную работу над проектами, распределить сферы ответственности и полностью сохранить историю изменения данных проекта. IYNO имеет возможность интегрироваться с облачными СОД. На данный момент реализована интеграция с Autodesk Construction Cloud, но прорабатываются интеграции с отечественными системами и даже разрабатывается собственная система файлового документооборота с возможностью конвертации моделей из проприетарных закрытых форматов в формат, который отображается в браузерном 3D-Viewer и позволяет извлечь данные элементов модели.
Модели, хранящиеся в СОД в виде отдельных файлов, объединяются в сводную модель на стороне IYNO, а отобразить её можно как целиком, так и настраивая требуемый для решения текущих задач набор входящих в неё моделей. Информация об их элементах выгружается в базу данных проекта и обновляется вслед за изменениями моделей в СОД.
Рис. 3. Выбор моделей, хранящихся в СОД, и их версий для подключения к проекту
Рис. 4. Смена версии на актуальную для моделей проекта
Рис. 5. Формирование сводной модели по выбранным разделам проекта
Тем самым решается первая сложность, связанная с первичной передачей информации от проектировщика. Модели, опубликованные и согласованные в СОД, в тот же момент попадают в работу по формированию ведомостей, а актуализация ранее сформированной ведомости происходит автоматически. Экономятся часы, а иногда дни (ночи) на подготовку данных для принимающих решение.
Правила привязки элементов к работам
Для определения состава работ для элементов сводной модели необходимо проанализировать их атрибутивный состав. Сделать это можно как в табличной форме, так и в виде так называемого дерева элементов. Дерево — это иерархическое представление состава моделей, но не общепринятое группирование элементов по моделям/категориям/семействам/типам, а настраиваемое группирование по любым атрибутам элементов. Например, для определения перечня работ по монолитным железобетонным конструкциям необходимо понимать тип конструкции, её толщину, марку бетона, коэффициент армирования и расположение конструкции в надземной или подземной части здания. Именно по этим атрибутам мы и выстраиваем дерево элементов и в каждой ветке дерева имеем возможность выбрать набор элементов, который далее сопоставим с выполняемыми работами. Причём к работе привяжется именно правило выборки элементов (ветки дерева) и при следующих итерациях произойдёт обновление элементов, привязанных к работе. Новые элементы, соответствующие правилу, будут добавлены к работе, а элементы с изменившимися свойствами — исключены.
Рис. 6. Правила выбора элементов в виде дерева
Для задач по определению работ для элементов различных инженерных систем, архитектурных компонентов и конструкций может быть сформировано неограниченное количество преднастроенных иерархий дерева элементов.
Правила привязки элементов к работам можно использовать не только на последующих итерациях проекта, но и на последующих проектах. Это означает, что накопленный на каждом проекте опыт компании не пропадёт даром и на последующих проектах эффект от автоматизации будет ещё выше.
Нормализация данных
Без выстроенного конвейера данных невозможно получить положительный эффект от автоматизации процесса, но его выстраивание нецелесообразно делать на каждом проекте заново. Если на каждом проекте сталкиваться с новыми именами атрибутов, то придётся перенастраивать настройки иерархий элементов, правила привязки элементов к работам и прочие автоматизации.
Одним из ключевых преимуществ IYNO является возможность нормализации данных. Суть процесса в том, что в аккаунте компании-пользователя ведётся свой справочник атрибутов. Это целевые атрибуты, которые участвуют в формировании конфигураций дерева элементов, в правилах привязки элементов к работам, декомпозиции их по этажам и корпусам, считывания их количественных показателей и прочих процессов IYNO. Это условно статичный справочник, не зависящий от моделей, полученных от проектной организации.
На старте проекта необходимо осуществить сопоставление атрибутов (маппинг), содержащихся в моделях проекта (исходных атрибутов), с целевыми атрибутами. Маппинг не занимает много времени, а его результаты можно использовать и на последующих проектах. В среднем для комплексного проекта на это затрачивается порядка двух часов при первой итерации загрузки данных.
Рис. 7. Маппинг исходных атрибутов на целевые
Подобный подход сокращает объём информационных требований к проектировщику, ведь теперь надо требовать именно данные, а не конкретные имена атрибутов (параметров), что в свою очередь позволяет проектной компании работать в привычных шаблонах, использовать наработанные библиотеки элементов и скриптов.
Это положительно сказывается на качестве проектов и скорости их разработки, а Застройщику даёт возможность работать с многими проектными организациями, не навязывая работу по своим параметрам.
Ядро физических величин и единиц измерения
Справочник физических величин и единиц измерения является неотъемлемой частью IYNO. Справочник редактируемый и позволяет добавлять собственные единицы измерения и задавать им коэффициенты перевода. Возможность создавать единицы измерения очень важна при работе и с государственными справочниками работ (ГЭСН), ведь множество из них измеряется в весьма сложных единицах: «400 м укладываемой трубы», «10 опор» или «3,2 м».
Единицы измерения в исходных атрибутах моделей проекта могут быть описаны совершенно по-разному. Например, миллиметр описывается как «мм», «mm», “autodesk. unit. unit: millimeters-1.0.1″ и др. Это зависит от исходного формата информационной модели и даже версии применяемого для её разработки ПО. Для того чтобы при загрузке информации из исходных атрибутов в проект система разобралась, в какой единице они записаны, имеется возможность маппинга исходных единиц измерения на целевые (хранящиеся в справочнике).
Рис. 8. Интерфейс справочника единиц измерения
Единицы измерения используются для описания целевых атрибутов и работ, причём не обязательно атрибут, применяемый для определения количества работы, и сама работа имеют одинаковую единицу измерения, но принадлежать одной величине они обязаны.
Пример:
- В исходной модели атрибут «Length» у элементов трубопроводов измеряется в «mm» (в системе определяется как «мм»).
- В аккаунте IYNO исходный атрибут «Length» смапплен с целевым атрибутом «Длина», измеряемым в «м».
- Работа «Укладка полиэтиленовых труб газопроводов в траншею с подвижного барабана, диаметр газопровода: до 63 мм» измеряется в «400 м укладываемой трубы».
Тогда, если в исходной модели у трубопровода длина («Length») составляет 40 000 mm, в IYNO она будет отображена как «Длина» = 40 «м», а попав в работу, элемент добавит к её количеству 0,1 «400 м укладываемой трубы».
Причём к той же работе могут быть прикреплены элементы, у которых исходное значение атрибута записано в иных единицах измерения, главное, чтобы они относились к физической величине — Длина.
Рис. 9. Принцип маппинга атрибутов и единиц измерения в IYNO
Эффект IYNO
В результате мы получили процесс, не требующий постоянного контроля единиц измерения в исходных информационных моделях и какой-либо постобработки данных. Тем самым настроенный однажды процесс применим к последующим проектам без изменений, существенно сокращается число ошибок и трудозатрат.
Рис. 10. Автоматически актуализируемая ведомость объёмов работ с возможностью выгрузки в сторонние форматы
IYNO Start позволяет компаниям сократить информационные требования к проектировщику. Команда проекта имеет возможность сфокусироваться на качественных проектных решениях, а не на адаптации шаблонов и семейств, сокращается число ошибок. В IYNO формирование и обновление сводной нормализованной модели происходит автоматически, а вслед за обновлёнными проектными данными обновляются и ведомости объёмов работ, не требующие доработки вручную.
Автоматизация любых процессов имеет много общего:
- Мы не должны автоматизировать деятельность одних подразделений за счёт увеличения трудозатрат других.
- Результаты автоматизации должны быть измеримы, скорость процессов и качество результатов должны возрастать, а трудоёмкость сокращаться.
- Автоматизация должна быть не проекта, а компании. Важно чтобы выстроенный конвейер был универсальным, применялся и совершенствовался на всех проектах компании. Иначе — трудозатраты на автоматизацию могут перевесить эффект.
IYNO Start формирует именно автоматический процесс и повышает эффективность бизнеса!
Посмотреть запись вебинара «Цифровизация ПТО: как эффективно настроить работу с данными»:
Авторы: Роман Митин, Анастасия Морозова
Источник: http://isicad.ru/