Статусы документов как ключевой элемент стандартизации информационного обмена в средах общих данных

Ислам А.А., Медведев Д.В., Пронин В.И. Статусы документов как ключевой элемент стандартизации информационного обмена в средах общих данных // Градостроительство и архитектура. - 2025. - Т. 15. - №4. - C. 83-89. doi: 10.17673/Vestnik.2025.04.12

Введение

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

Теория

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

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

Статус — это атрибут единицы информации (документ, модель и т.п.), позволяющий участникам идентифицировать, как правильно её можно использовать в работе, и какая степень «зрелости» ей соответствует. [3]

Движение документов и моделей между зонами СОД сопровождается рядом процессов. Например, переходу материалов из зоны «В работе» в зону «Общее» предшествуют процессы рассмотрения, проверки и согласования. Британцы в своём стандарте уделили много внимания описывая все эти процессы, рассмотрев подробнее методику работы по BS 1192 выделим следующие важные элементы.

● Использование правильных именований файлов и моделей. В стандарте предложена универсальная структура и принцип кодификации.

● Применение статусов.

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

ISO 19650 «Организация и оцифровка информации о зданиях и инженерно строительных работах, включая информационное моделирование зданий (Building Information Modeling, BIM) — Управление информацией с использованием технологий информационного моделирования».

Ниже представлена схема процессов в СОД согласно стандарту BS 1192.

Рис. 1 Определение структуры репозитория документов и данных как части среды общих данных в BS 1192:2007 [5]

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

Рис. 2 Структура среды общих данных

Данная схема, как и в BS 1192 содержит в себе 4 файловые зоны:

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

● Shared — раздел данных «В общем доступе», которые доступны смежным подразделениям и подрядчикам. Служит для координации проекта.

● Published Documentation — в области «Опубликовано» размещаются только готовые и утвержденные документы, которые можно передавать во вне, заказчику или контрагентам.

● Archive — в разделе «Архив» хранятся архивные данные. Область СОД для долгосрочного хранения данных после завершения проекта. [6]

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

Практическое применение статусов документов в СОД

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

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

Рис. 3 Пример схемы регламента по организации коллективного производства информации в СОД

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

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

Созданные регламенты позволяют:

● Максимально оперативно подключать новых сотрудников к проектам;

● Обеспечить повышение производительности труда каждого участника проекта;

● Формировать отчёты и аналитику, выявлять проблемы на ранних этапах;

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

Примеры реализации статусов документов в различных СОД

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

Система Pilot-BIM от разработчика АСКОН, обладает рядом функций для решения задач по подготовке 2D-документов. В том числе: система позволяет задавать определённый статус документам, который будет виден всем участникам проекта: «согласовано», «аннулировано», «на согласовании».

Рис.4 Скриншот из системы Pilot-BIM. [7]

Также статусы есть у замечаний к документам: «Принято», «Отклонено», «Удалено». Они позволяют инициатору контролировать процесс работы над замечанием. Необходимо отметить, что хоть статус документа и статус замечания имеют одинаковое название «статус» это разные информационные сущности и решают они разные задачи.

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

Рис.5 Скриншот из системы Sarex. [8]

Статусы к замечаниям в системе Sarex имеют три состояния: «ожидает», «закрыто», «открыто», по которым их можно фильтровать.

В системе TDMS Фарватер, статус является одним из свойств (атрибутов) каждого информационного объекта. В зависимости от статуса определяются права доступа разных сотрудников к объекту, а также список возможных действий с объектом.

Рис.6 Скриншот из системы TDMS Фарватер. [9]

В системе TDMS Фарватер, документ может перемещаться по статусам только вперед, перевод в предшествующий статус из списка не допустим. Например, из статуса «В работе» перевели в «Завершено», перевести документ в статус, предшествующий «Завершено» невозможно.

Статусы документов в среде общих данных ИНГИПРО основываются на файловых зонах, согласно ISO 19650, которые были подробно рассмотрены в прошлых главах. Статусы в ИНГИПРО представлены в виде кода (идентификатора) с цветом и описанием. Цвет определяет зону, в которой находится файл, а код помогает определить какой участник проекта работает, или должен начать работу над документом в настоящий момент. Набор статусов возможно задать индивидуально под любой проект в настройках системы.

Рис.7 Скриншот из системы ИНГИПРО. [10]

Рис.8 Информация о изменении статусов в ИНГИПРО.

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

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

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

Предложения

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

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

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

Заключение

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

__________________________________________________________________________________________

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

Список источников

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

2. Медведев, Д. В. Формирование экономических обоснованных требований к средам общих данных / Д. В. Медведев, В. И. Пронин, А. А. Ислам // Человек. Общество. Инклюзия (Приложение). – 2023. – № S1-2. – С. 752-759. – EDN ENXSFK.

3. Савенко, А. И. Среда общих данных при реализации строительных объектов с применением BIM / А. И. Савенко, П. В. Черенков // САПР и ГИС автомобильных дорог. – 2019. – № 2(13). – С. 4-11. – DOI 10.17273/CADGIS.2019.2.1. – EDN YCCEZG.

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. BS 1192:2007. Collaborative production of architectural, engineering and construction information — Code of practice. 2008. 38 p.

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

7. Softline [Электронный ресурс] // Pilot-BIM. Работа с моделью - Режим доступа: https://softline.ru/upload/iblock/c19/vyhmxxq6vgw4mk4id54nmy38u211c7nf/Pilot-BIM%20Работа%20с%20моделью.pdf (дата обращения: 17.06.2025).

8. Sarex [Электронный ресурс] // Документация по строительству - Режим доступа: https://www.sarex.io/media/dokumentaciya-po-stroitelstvu (дата обращения: 17.06.2025).

9. Help.farvater [Электронный ресурс] // Перевод документа в требуемый статус - Режим доступа: https://help.farvater.cloud/topics_mc_idh_objects_docint_others_changestatus.html (дата обращения: 17.06.2025).

10. Пронин, В. И. Особенности хранения проектной информации в среде общих данных строительного проекта / В. И. Пронин, Д. В. Медведев, А. А. Ислам // Человек. Общество. Инклюзия. – 2024. – Т. 15, № 1-2. – С. 111-119. – EDN NRLTWU.