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

Полный текст

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

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

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

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

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

• ▪ Использование правильных наименований файлов и моделей. В стандарте предложена универсальная структура и принцип кодификации.
• ▪ Применение статусов. Данная методология получила дальнейшее развитие в серии стандартов ISO 19650 [4].

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

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

 

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

Fig. 1. Definition of the document and data repository structure as part of the Common Data Environment in BS 1192:2007 [5]

 

В российской практике данная схема была переосмыслена и в общем виде представляется следующим образом (рис. 2):

 

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

Fig. 2. Structure of the Common Data Environment

 

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

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

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

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

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

 

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

Fig. 3. Example of a regulation scheme for organizing collaborative information production in CDE

 

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

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

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

• ▪ максимально оперативно подключать новых сотрудников к проектам;
• ▪ обеспечить повышение производительности труда каждого участника проекта;
• ▪ формировать отчёты и аналитику, выявлять проблемы на ранних этапах.

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

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

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

 

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

Fig. 4. Screenshot from the Pilot-BIM system [7]

 

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

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

 

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

Fig. 5. Screenshot from the Sarex system [8]

 

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

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

 

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

Fig. 6. Screenshot from the TDMS Farwater system [9]

 

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

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

 

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

Fig. 7. Screenshot from the INGIPRO system [10]

 

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

Fig. 8. Information on status changes in INGIPRO

 

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

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

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

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

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

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

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

Об авторах

Амир Ашраф Ислам

ООО «Ингипро»

Автор, ответственный за переписку.
Email: amir@ingipro.com

менеджер проектов

Россия, 129626, г. Москва, ул. Павла Корчагина, 2

Дмитрий Валерьевич Медведев

ООО «Ингипро»

Email: medvedev@ingipro.com
SPIN-код: 6477-4763

руководитель проектов

Россия, 129626, г. Москва, ул. Павла Корчагина, 2

Вадим Игоревич Пронин

ООО «Ингипро»

Email: pronin@ingipro.com

директор по развитию

Россия, 129626, г. Москва, ул. Павла Корчагина, 2

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

Дополнительные файлы