Работа с нативными файлами в среде общих данных строительного проекта. Проблемы и решения

Перечень сокращений
ИМ - информационная модель
ЦИМ - цифровая информационная модель
ТИМ - технологии информационного моделирования
СОД - среда общих данных
ИИ - инженерные изыскания
ПД - проектная документация
РД - рабочая документация
ИС - информационная система
ОКС - объект капитального строительства

Введение

Базовые понятия

Для единообразного понимания используемых в статье терминов следует их определить.

“Технологии информационного моделирования есть способ преобразования информации об объекте капитального строительства в информационную модель/модели ОКС, путем построения взаимосвязей внутри и между различными информационными частями посредством использования среды общих данных” [3].

“Среда общих данных (СОД) — это единый программно-технический комплекс для совместной работы участников проекта с информационными моделями на всех стадиях жизненного цикла” [3].

“Технологии информационного моделирования это новый способ производства, обработки, передачи и хранения информации об объекте капитального строительства” [3].

Нативный файл (файл или документ в нативном формате — (Native File) файл внутри информационной системы СОД в “родном” формате, т. е. в том, в котором он был создан специализированным ПО, где производится и оформляется информация. Пример — файлы с разрешениями .dwg, .doc и другие.

Работа с документами в СОД

Когда мы говорим про работу в среде общих данных, то прежде всего стоит упомянуть методологию этой работы. Само понятие СОД было введено вместе представлением методологии, которую предлагается использовать (рис. 1).

Рис. 1

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

Зона “В работе” предполагает, что документы в этом

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

Зона “В общем доступе” предназначена для нахождения в ней тех документов, которыми могут пользоваться (в основном знакомиться) другие участники проекта. Это могут быть смежные подразделения, которые разрабатывают свой раздел документации или представители заказчика. Это еще не тот уровень зрелости документа, когда на данных из него можно строить свои решения, но эти данные можно учитывать.

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

Зона “Архив” сохраняет в себе документы, которые потеряли актуальность. Эта информация сохраняется для того, чтоб было понятно как развивались проектные решения и т. д. Архив — история изменения информации.

Данная методология впервые была предложена Британским стандартом BS1192 и получила дальнейшее развитие в серии стандартов ISO 19650 [4].

Использование этого подхода позволяет решить ряд задач:

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

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

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

Рассмотрим разные подходы к работе с документами внутри СОД.

1. СОД позволяет каким-либо образом редактировать документы внутри себя.

а) Обычно такие СОД предлагают вендоры, которые одновременно с СОД предлагают и системы разработки проектной документации (САПР). В этом случае у вендора получается совместить инструменты работы в CAD и СОД.

Какие преимущества получает пользователь:
+ Некоторые ошибки в документации можно поправить непосредственно в СОД.
+ Нет необходимости переводить документ (чертеж, модель и т.д.) в другой формат (pdf, ifc).

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

Недостатки:
- Привязка к одному вендору. В сложных проектах инструментами одного вендора крайне тяжело выполнить весь объем работ.
- Снижается исполнительская дисциплина. Т. е. в силу того, что специалист “может исправить потом”, меньше себя контролирует в моменты загрузки документов в СОД.

б) Другой случай, когда вендор системы СОД внедряет инструменты, которые позволяют изменять документы. Если эта СОД не является “продолжением” какой-либо CAD-системы, то возможности редактирования внутри нее меньше.

Преимущества, которые получает пользователь, такие же как в а). Недостатки тоже будут те же, с учетом того, что возможности редактирования документов ниже.

2. СОД не позволяет редактировать документы внутри себя

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

Преимущества данного подхода:
+ Так как в системе работа ведется уже с общепринятыми форматами данных, то снижаются требования к квалификации сотрудников, которые взаимодействуют с этой информацией. Т. е. (утрированно) с документом формата .dwg будет работать инженер, а с .pdf может работать сотрудник с любым уровнем подготовки.
+ Повышается исполнительская дисциплина.

Недостатки:
- Специалистами требуется проводить дополнительные операции (перевод в другой формат файла) для размещения документа в СОД.

Рассмотрим эти два подхода с методологической точки зрения:

• Согласно нормативным документам у каждого документа должен быть автор. Если документы в СОД могут изменяться, то вопрос с авторством становится неопределенным.
• То же самое происходит со статусом документа, который должен соответствовать определенной зоне СОД. Если мы вносим изменение в утвержденный документ, то в каком статусе он будет?
• При возможности корректировки документов сложности возникнут с вопросом передачи документации. Т. к. передача при использовании СОД не предполагает физического перемещения документов, то обе стороны должны быть уверены в том, что одна сторона передала, а другая приняла один и тот же документ. Тогда его нельзя изменять.
• Проблема при междисциплинарном взаимодействии. Будут возникать споры из-за того, кто, когда, какие изменения внес, как они влияют на работу соседнего отдела.
• СОД не сможет повторить функционал САПР систем, текстовых и табличных редакторов, систем расчета и сметных систем в полном объеме. Это значит, что специалисты все равно будут использовать нативные системы для внесения изменений в документы. Получается, если есть СОД, которая может немного исправлять документы, но для больших правок нужно идти, например, в САПР, то в итоге мы работу, скорее, усложним. Попутно возникает проблема рассогласованности версий документов. Документ, загруженный в СОД, получил незначительные правки. Для более существенных правок специалист использовал нативный файл на своем диске, после загрузил новую версию в СОД — правки предыдущей версии, внесенные через СОД, пропали.

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

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

Методология работы в СОД предполагает явные поставки информации между специалистами. Такие поставки состоят из “контейнеров информации”. Информация внутри контейнера остается неизменной до новой поставки. Возможность изменения содержания контейнера информации (в частном случае документа) противоречит методологии СОД.

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

Выводы

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

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

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

Список литературы

[1] Пронин, В. И. Организация процесса выбора среды общих данных для проектов объектов капитального строительства / В. И. Пронин // Экономика: вчера, сегодня, завтра. – 2023. – Т. 13, № 5-1. – С. 220-230. – DOI 10.34670/AR.2023.54.86.078. – EDN IMVWNL.

[2] Медведев, Д. В. Уровни развития сред общих данных строительных проектов / Д. В. Медведев, В. И. Пронин // Экономика: вчера, сегодня, завтра. – 2023. – Т. 13, № 5-1. – С. 434-445. – DOI 10.34670/AR.2023.59.18.018. – EDN FVJNAG.

[3] Пронин, В. И. Трактовка понятий "технологии информационного моделирования" (ТИМ) и "среда общих данных" (СОД) / В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 2(54). – С. 140-146. – EDN YXDIPD.

[4] BS EN ISO 19650 1:2018. (Organization and digitalization of information about buildings and civil engineering works, including building information modelling (BIM). Part 1: Concepts and Principles

[5] Пронин, В. И. Формирование задач для выбора информационной системы из стратегических целей проектной организации / В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 3-1(55). – С. 114-119. – EDN CNMXJI.

[6] Пронин, В. И. Коммерциализация технологий информационного моделирования на примере рынка СОД / В. И. Пронин, Д. В. Медведев, А. А. Ислам // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 3-1(55). – С. 141-149. – EDN CSQNSP.

[7] Ислам, А. А. Десктопное или веб-приложение для организации СОД ОКС / А. А. Ислам, В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 3-3(57). – С. 128-135. – EDN GHMTFS.

[8] Медведев, Д. В. Формирование экономических обоснованных требований к средам общих данных / Д. В. Медведев, В. И. Пронин, А. А. Ислам // Человек. Общество. Инклюзия. – 2023. – Т. 14, № 4-2(59). – С. 161-170. – EDN INLKCQ.

[9] Пронин, В. И. Экономические структуры имплементации коммерческих лицензий СОД строительных проектов / В. И. Пронин, Д. В. Медведев, А. А. Ислам // Человек. Общество. Инклюзия. – 2024. – Т. 14, № 4-3(60). – С. 166-176. – EDN AFWSVK.

Реклама. ООО «ИНГИПРО». 2SDnjdsadrH