Уровни развития сред общих данных строительных проектов

В статье приведен краткий обзор термина «среда общих данных» (СОД) и история развития этого понятия. Статья посвящена уровням развития СОД, в ней освещены принципы организации сред общих данных в исторической перспективе и тенденции их развития.

Исследование вопроса велось через анализ имеющихся СОД у компаний-участников строительных проектов в России на сегодняшний день и анализ запросов со стороны участников строительных проектов.

Главное внимание обращается на то, как достичь необходимых результатов работы с информационными моделями при ведении строительных проектов с использованием сред общих данных.

В основной части статьи дается информация об имеющихся вариантах организации СОД, исторически сформировавшихся в отрасли и получивших свое развитие. Раскрываются понятия «среда общих данных», «информационная модель», «схема процессов СОД». Авторами предлагается теория уровней развития СОД.

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

В заключении кратко разбирается, что необходимо делать для приближения и достижения успешного результата применения СОД, — повышение эффективности работ в строительных проектах на всех стадиях.

Для цитирования в научных исследованиях
Медведев Д.В., Пронин В.И. Уровни развития сред общих данных строительных проектов // Экономика: вчера, сегодня, завтра. 2023. Том 13. № 5А. С. 336-347. DOI: 10.34670/AR.2023.59.18.018

Введение

Появление понятия коллективной работы стало одним из главных направлений развития систем автоматизированного проектирования (САПР) еще в 70-х годах 20-го века. В машиностроении это вылилось в концепции PDM и PLM.

В строительстве же к этому процессу пришли позже. Его результатом стало введение понятия CDE — Common Data Environment. В России это понятие укрепилось в термине Среда Общих Данных — СОД.

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

Этому и посвящена данная статья.

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

Что такое СОД

Определение

Впервые термин «среда общих данных», сокращенно СОД (common data environment (CDE), был применен Мервином Ричардсом и зафиксирован в стандарте BS1192-2007 в Великобритании. В дальнейшем он получил развитие и на сегодняшний день применяется в нормативных документах стран мира.

Общепринятый в международной практике стандарт ISO 19650 определяет это понятие следующим образом:

ISO 19650 3.3.15 common data environment (CDE): “agreed source of information (3.3.1) for any given project or asset (3.2.8), for collecting, managing and disseminating each information container (3.3.12) through a managed process.”

Российские нормативные документы определяют этот термин так:

• ГОСТ Р 10.0.01-2018. «Система стандартов информационного моделирования зданий и сооружений. Термины и определения»:
  Среда общих данных (BIM-среда), СОД (Common Data Environment, CDE): Программный комплекс по управлению, хранению и обмену данными об информационных моделях на всех стадиях жизненного цикла.
• СП 471.1325800.2019. «Информационное моделирование в строительстве. Контроль качества производства строительных работ»:
  Среда общих данных; СОД: Комплекс программно-технических средств, представляющих единый источник данных, обеспечивающий совместное использование информации всеми участниками инвестиционно-строительного проекта.

СОД позволяет всем участникам в равной мере участвовать в формировании и ведении информационных моделей объектов капитального строительства.

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

Выявление коллизий и корректировка проекта на поздних стадиях влечет за собой увеличение стоимости их исправления. Своевременное взаимодействие участников проекта способствует выявлению коллизий на более ранних сроках проекта.

Назначение

Среда общих данных — это один из основополагающих и первоочередных инструментов, с которых начинается внедрение технологии информационного моделирования. СОД предназначена для координации работы межорганизационных команд, синхронизации их деятельности, обмена данными в общем цифровом пространстве проекта.

Цель использования СОД — сокращение сроков и издержек проектов капитального строительства.

Задачи, которые позволяет решить СОД:

• Формирование и ведение информационной модели;
• Организация инженерно-технического документооборота между участниками проекта в электронном виде;
• Сокращение сроков на обмен документами и информацией, сроков на согласование и коммуникации;
• Повышение прозрачности и подконтрольности процессов;
• Сокращение количества ошибок в проектах и коллизий на стройке, сокращение простоев;
• Оценка текущего состояния объекта и его соответствие плану;
• Контроль строительных процессов и выполнения работ.

Ключевой идеей в стандарте BS 1192 была схема процессов в СОД. Она представлена на Схеме 1.

Схема 1 – Хранилище для управления документами и данными

В российском нормотворчестве она была переосмыслена и применена в нескольких нормативных документах и в общем виде представляется так:

На иллюстрации приведена принципиальная схема СОД, включающая в себя 4 файловые зоны:

1. WIP (Work in Progress) — раздел рабочих данных («В работе»). Область СОД для хранения текущих данных одной из групп участников проекта. Информация в зоне WIP доступна только данной группе участников. По мере повышения степени проработки информации доступ к ней может быть предоставлен другим участникам проекта путем перемещения данных в другие файловые зоны.
2. Shared — раздел общих данных («Общий доступ»). Область СОД, где материалы участников проекта хранятся в общем доступе для смежных подразделений и контрагентов. Она используется для координации проекта.
3. Published Documentation — раздел опубликованных данных («Опубликовано»). Область СОД, куда выкладываются готовые, утвержденные материалы для передачи их вовне — контрагентам или заказчику.
4. Archive — раздел архивных данных («Архив»). Область СОД для долгосрочного хранения данных после завершения проекта.

Работа с документами, согласно этой методологии, позволяет проводить в рамках строительного проекта эффективные взаимодействия между всеми участниками.

Это основные теоретические положения СОД. Более подробно с понятиями и определениями, касающимися СОД, можно ознакомиться в нормативных документах Российской Федерации. Мы же в статье сосредоточимся на уровнях СОД, демонстрирующих развитие этого инструмента.

Уровни развития СОД

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

По результату анализа развития этих систем было выделено пять уровней развития сред общих данных:

Уровни демонстрируют историю развития СОД, выделяют особенности каждого типа СОД и показывают тенденции прошлого и будущего.

Кроме того, можно также выделить несколько способов организации СОД. С помощью них можно наблюдать развитие технологии СОД с течением времени.

1. Внутреннее решение

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

2. Клиент-серверное решение

В данном случае уже используется специализированный софт. Схема в общем случае выглядит так: на сервере компании стоит софт, на каждом из ПК пользователей стоит клиентская часть. Возможно, существует web-приложение, которое поддерживает ограниченное количество функций. Такой способ лучше, чем первый, но имеет ряд существенных недостатков. Прежде всего, не происходит командной работы, она эмулируется. Полностью воспользоваться преимуществами системы по-прежнему может только компания-владелец системы.

3. Облачное web-решение

Наиболее перспективный способ организации СОД на сегодняшний день. Главная его особенность в том, что он обеспечивает полнофункциональную работу СОД без привязки к определенным ПК. В проекте может быть любое количество участников, они могут свободно приходить и уходить. Обеспечивается командная работа.

Решения на базе web-сервисов способны обеспечить высокую эффективность организации СОД. Помимо отсутствия проблем, присущих локальным решениям, они предоставляют больше возможностей (например, открытие чертежей и 3D-моделей в браузере без использования специальных программ).

1. Локальная СОД

Первый уровень развития сред общих данных. Возникает такая СОД в компаниях, решивших упорядочить свою деятельность, связанную с проектной документацией. Характеризуются системы первого уровня сходством с системами документооборота и высокой степенью «индивидуальности», так как они призваны оптимизировать деятельность конкретной организации и обеспечить возможность обмена технической документацией проекта внутри одной организации.

Часто такие СОД создаются в результате заказной разработки.

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

Работа с проектной документацией в части создания, проверок и внесения изменений производится в используемых на предприятии привычных программных продуктах: CAD-системах, офисных ПО и т. д. Проектная документация имеет форматы этих систем.

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

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

Однако такие системы не выполняют роль СОД проекта, а принадлежат одному из участников проекта. Это неправильно с точки зрения теории СОД.

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

2. Локальная СОД с подключением сторонних пользователей

Второй уровень зрелости является развитием первого уровня. На этом уровне появляется возможность обмена информацией между несколькими участниками.

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

Зачастую эта задача решается выдачей доступов для загрузки или выгрузки информации в/из локальной СОД одного участника проекта. Это можно назвать «имитацией» общего доступа, поскольку при этом отсутствуют налаженные постоянные цепочки коммуникаций между участниками проекта в разных ролях.

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

К преимуществам по-прежнему можно отнести высокий уровень кастомизации, то есть доработки системы. Система все еще служит оптимизации собственной деятельности организации. Также к преимуществам можно отнести и повышающийся при таком варианте организации СОД уровень контроля контрагентов.

Однако такая система по-прежнему не является СОД в полном понимании этого термина — она не выполняет роль СОД проекта, принадлежит только одному участнику.

При этом добавляется новый риск — возникают конфликты регламентов участников проектов при обращении с информацией.

Могут возникнуть конфликты систем, в которых работают участники проекта, например несоответствие форматов передачи данных.

СОД второго уровня дают возможность ограниченного обмена информацией с внешними компаниями.

3. Межорганизационная СОД

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

Такие СОД невозможно получить из бывших ранее локальными СОД.

Системы третьего уровня обладают одинаковым для всех участников функционалом.

Важной особенностью такого вида сред общих данных является то, что они уже становятся неотъемлемой частью самого проекта. То есть СОД этого уровня развития уже может не принадлежать одному из участников проекта. Однако по-прежнему поддержание работоспособности такой СОД оплачивается кем-то из участников проекта.

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

Как правило, СОД такого уровня развития является продуктом специализированного поставщика, а не конкретного участника проекта.

Часто это облачная система, что позволяет работать с современными технологиями в стройпроектах и использовать передовой опыт в организации IT-систем.

Технологии СОД такого уровня обеспечивают быстрый доступ к этим системам действующих и новых участников.

К недостаткам таких СОД можно отнести общий функционал, без учета индивидуальных потребностей ролей участников проекта.

Конфликты регламентов участников проектов по обращению с информацией устраняются за счет гибких возможностей по настройке доступа к информации внутри СОД.

Такие среды общих данных менее подвержены изменениям по запросу клиента, так как являются разработкой стороннего вендора.

Они позволяют улучшить экономические показатели проекта — сроки, стоимость, качество. То есть такие СОД приносят пользу уже не только компаниям, но и всему проекту в целом.

Часть функционала является общеприменимым, для всех участников проекта он одинаков. Появляется возможность производить: прием, хранение, передачу данных; проверку и согласование документов; контроль развития проекта.

4. Межорганизационная СОД с функциональными модулями по ролям участников

Четвертый уровень СОД является развитием третьего уровня точно так же, как второй уровень является развитием первого.

На четвертом уровне добавляется индивидуальный функционал в соответствии с ключевыми ролями участников проекта. Интерфейс системы также может различаться в зависимости от роли в проекте, но при этом вся система является единым информационным полем.

Важно, что у нее сохраняется роль СОД проекта.

Технологический стек таких СОД обеспечивает быстрый доступ к ней действующих и новых участников. Новые пользователи получают доступ максимально быстро и максимально оперативно способны освоить новый инструмент и рабочие процессы внутри него.

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

На сегодняшний день отрасль только приступает к переходу на этот уровень СОД. Сложность подобных систем и недостаточный уровень развития IT обусловливает сложность создания и полноценного использования таких систем. В данный момент СОД с функциональными модулями для каждого участника проекта еще нет на рынке. Есть системы, способные интегрироваться с другими системами, есть системы, часть функционала которых отвечает запросам пользователей.

С использованием таких СОД возможно дальнейшее улучшение экономических показателей проекта — сроков, стоимости, качества.

Для организации может быть настроена более глубокая оптимизация собственной деятельности каждого из участников проекта.

Появляются дополнительные функции, которые относятся к отдельным ролям: стройконтроль, авторский надзор, нормоконтроль, план-график, КС и прочее.

5. Объединенная СОД

Это финальный уровень зрелости СОД. Это та самая целевая система, к которой стремится вся строительная отрасль.

На этом уровне предполагается интеграция различных информационных систем у всех участников проекта между собой для организации единого информационного поля.

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

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

Такой вариант организации СОД объединяет все преимущества прежних уровней развития.

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

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

Безопасность хранения данных обеспечивается максимально эффективно.

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

Нынешние отраслевые и технологические уровни развития не позволяют реализовать такую СОД. Это задача будущего, над которой необходимо работать сообща участникам строительной сферы и сферы IT.

Заключение

Тема СОД в строительной отрасли еще достаточно молода. Даже теория и методология СОД требует постоянного обновления, актуализации и подтверждения на практике. Вполне вероятно, что многие положения, приведенные в этой статье, будут подвержены изменениям со временем.

Однако уже сегодня мы можем четко выделить тенденции развития СОД как ключевого инструмента в повышении эффективности деятельности участников строительных проектов:

• обеспечение безопасности хранимой и передаваемой информации;
• четкое и эффективное распределение зон ответственности между участниками проекта;
• делегирование полномочий в соответствии с ролями участников в проектах;
• обеспечение удобного и быстрого доступа к СОД новых сотрудников, уменьшение требований к программно-аппаратной части со стороны СОД.

Следуя основной цели СОД — повышение эффективности работ в строительных проектах, мы можем сделать вывод о необходимых действиях, которые стоит предпринять, чтобы ускорить достижение успешного результата.

Важно отметить, что развитие СОД невозможно ускорить, перепрыгнув какой-то из этапов. Это эволюционный процесс, и он должен быть пройден. Чтобы достичь целевой системы, нужно сначала закрыть предыдущий этап. В настоящее время большая часть систем на рынке соответствуют третьему уровню развития.

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

На сегодняшний день актуально отсутствие технологической совместимости сервисов для предоставления пользователям необходимого функционала. IT-отрасли стоит сосредоточиться на этом.

В настоящее время в России оптимальным решением по организации информационного пространства на всех этапах жизненного цикла является схема последовательной обработки и обмена информацией между автоматизированными системами:

САПР ⇔ СОД ⇔ ГИС

Для реализации этой схемы должна быть обеспечена интеграция между указанными системами.

Строительной отрасли необходимо определиться в форматах передачи данных. Должен быть разработан и утвержден единый и открытый формат обмена данными между указанными системами.

Сейчас в РФ в этом направлении наблюдается активная работа — формируются специализированные ГОСТы, разрабатываются шаблоны форматов данных xml-схем, тестируются интеграции различных систем на разных уровнях обеспечения строительной деятельности. Однако работы в этом направлении еще много, и она далека от успешного общеприемлемого результата. Важно договариваться сообща — в совместном диалоге IT и строительной отрасли кроется ускорение достижения успешного результата.

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

Больше интересной информации в Telegram-канале «ИНГИПРО».