Атрибуты информационных контейнеров — это метаданные, которые присваивают контейнерам, чтобы ими управлять в среде общих данных. Контейнеры могут иметь столько атрибутов, сколько необходимо. Обязательные среди них:
• уникальное наименование (ID);
• ревизия;
• статус применения;
• код классификации.

В этом ИМС-посте — о первом из них.

🔠аждому контейнеру в СОД присваивают уникальное наименование (уникальный идентификатор, ID), которое больше никогда не изменится. «Уникальность» заключается в том, что в СОД это название существует только в единственном числе. Его нельзя дублировать для другого контейнера — сама СОД-система не допустит этого.

Зачем так придумано? Чтобы связать историю конкретного контейнера с идентификатором и иметь полный его жизненный трек в зафиксированных транзакциях:
🔵кто и когда контейнер создал;
🔵кто и когда его проверил;
🔵кто и когда его утвердил;
🔵кто и когда его отклонил;
🔵кто и когда его принял и так далее.

Контейнер получает уникальное наименование сразу же при создании и в соответствии с определенными в информационном стандарте правилами наименования (кодификации).

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

🔠равила кодификации полей названия у контейнеров могут быть приняты — в идеале — на общеотраслевом уровне в Национальном приложении к стандарту ИСО 19650. (Сначала, разумеется, потребуется локализовать этот стандарт.)

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

► [Проект/актив]: идентификатор проекта/актива, к которому относится контейнер.

► [Владелец]: название организации (или рабочей группы), которая отвечает за создание контейнера.

► [Функциональная разбивка]: место контейнера в структуре их разбиения в информационной модели по функциональному признаку (например: технические системы, системы водоснабжения и т. д.).

► [Пространственная разбивка]: место контейнера в структуре их разбиения в ИМ по пространственному признаку (например: этаж, секция, корпус и т. д.).

► [Форма]: форма информации, представленная в контейнере (например: «геометрическая (трехмерная) модель», «чертеж PDF», «XML-документ», «текстовый документ» и т. д.);

► [Дисциплина]: функциональная дисциплина, к которой относится информация в контейнере (например: «электрика», «конструкторские решения», «канализация и водопровод» и т. д.);

► [Номер]: серийный номер контейнера (например, 0022, 0023, …) для уникальности наименования, если все остальные поля у нескольких контейнеров совпадают.

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

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

🔠ажно тщательно предварительно готовить правила кодификации наименований.

Например, нужно заранее определить, как называть контейнеры, получаемые на основе контейнеров с BIM-моделями в результате экспорта данных из них. Так, очевидно, что файлы в формате IFC должны называться иначе, чем их исходные трехмерные модели в проприетарном «ревит»-формате RVT. И другие названия, соответственно, должны быть у чертежей в PDF-формате — результатом их информационного производства, будут пользоваться, например, на стройплощадке (там вряд ли пока еще нужна информация, представленная в «бимах»).

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

Продолжение следует. В следующий раз — о ревизиях и версиях информационных контейнеров.

⏩ ИМС-пост # 65 в PDF

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

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

🔠ереход информационного контейнера из состояния «В работе» в «В общем доступе» возможен тогда, когда ответственная рабочая группа проведет его проверку. Эта проверка будет состоять из двух действий: проверки оболочки и содержимого контейнера:

Под проверкой «оболочки» здесь понимается проверка формата и схемы данных контейнера, корректности присвоенных ему метаданных/атрибутов в СОД, соответствия информационным стандартам, методам и процедурам информационного производства и т. д. (разработчики ПО такую проверку называют технической проверкой качества, Quality Assurance Check).

► ☝️В ИМС будем называть это действие «Проверить контейнер».

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

► ☝️Будем называть это действие «Рассмотреть информацию».

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

Таким образом, для того чтобы перевести информационный контейнер из состояния «В работе» в «В общем доступе», рабочей группе нужно:

1️⃣ Проверить контейнер на соответствие информационному стандарту, методам и процедурам производства информации.

2️⃣ Рассмотреть информацию на соответствие уровню потребности в информации.

3️⃣ Утвердить информацию для открытия к ней доступа команде поставки.

4️⃣ Присвоить статус контейнеру, соответствующей цели применения информации в нем («Для координации», «Для рецензирования», «Для просмотра» и т. д.).

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

Ведущая назначенная сторона начинает процесс изменения состояния информационного контейнера. Ей нужно:

1️⃣ Рассмотреть информацию (и при этом выполнить ее техническую проверку, поскольку ведущая назначенная сторона — все-таки поставщик информации, а не ее получатель).

2️⃣ Авторизовать информацию для передачи назначающей стороне.

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

3️⃣ Рассмотреть информацию (и при этом осуществить «коммерческую» ее проверку на соответствие своим требованиям к обмену информацией, определенным в договоре поставки ИМ).
Созданную федеративную информационную модель проверяют с учетом требований к ее координации, полноте и точности. В случае какого-либо несоответствия она возвращается в состояние «В работе» для внесения поправок, и только после этого процесс сдачи-приемки возобновляется. Здесь важно отметить, что ИМ не должны принимать по частям, а только в полной «федеративной сборке».

4️⃣ Принять информацию.

5️⃣ Изменить атрибуты контейнера, тем самым изменив его состояние на «Опубликовано».

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

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

⏩ ИМС-пост # 64 в PDF

Уважаемые коллеги, наша ИМС-библиотека пополнилась очень интересной книгой Артема Бойко — "Навигация в эпоху данных в строительной отрасли, 2-е издание".

Очень здорово и примечательно, что пишут такие книги. Да и вообще, в наше время примечательно, что книги пишут

Артем Бойко. DATA-DRIVEN CONSTRUCTION. Навигация в эпоху данных в строительной отрасли. © 2025 Артём Бойко. Второе издание, переработанное и дополненное.
#имскнига

По отношению к информационной модели (ИМ) СОД решает две задачи, там:
1️⃣ происходит совместное производство ИМ в состояниях контейнеров «В работе» и «В общем доступе» (рассмотрели в прошлых эпизодах);
2️⃣ хранится ИМ в состояниях «Опубликовано» и «В архиве» (рассмотрим ниже).

🔠остояние «Опубликовано» используется для контейнеров, которые были приняты заказчиком как результат информационного производства и вошли в состав ИМ.

Контейнеры в состоянии «Опубликовано»:
► видны всем членам команды проекта/актива (с соответствующими разрешениями);
► нельзя редактировать, доступны только для просмотра;
► будут последними авторизованными ревизиями.

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

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

Не все контейнеры в состояниях «В работе» и «В общем доступе» достигнут состояния «Опубликовано». Например, в ИМ могут быть опубликованы только чертежи в PDF-формате, в то время как их рабочие версии в специфических САПР(или «BIM»)-форматах, на основе которых чертежи выпущены, останутся в «В работе», затем сразу попадая в «В архиве».

🔠остояние «В архиве» используют для промежуточных ревизий информационных контейнеров, которые возникали в процессе производства ИМ. По последовательности ревизий контейнера в «В архиве» можно полностью восстановить историю его создания и, соответственно, всей ИМ.

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

Ревизии попадают в «В архиве» не только (и не столько!) из «Опубликовано», сколько из других состояний, реализованных в процессе СОД («В работе», «В общем доступе»). Жесткое требование СОД-процесса состоит в том, чтобы, как только содержание или метаданные контейнера обновлялись, его предыдущая ревизия в ИМ архивировалась, то есть переходила в состояние «В архиве».

Итак, информационные контейнеры в «В архиве»:
► видны только администраторам СОД;
► нельзя редактировать, доступны только для просмотра;
► следует рассматривать как неактуальные (устаревшие).

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

🔵предоставить историю информационного производства и поставки-приемки модели в случае юридического спора между сторонами;
🔵помочь решить неожиданно возникший вопрос при текущей эксплуатации и техническом обслуживании объекта;
🔵использовать рабочие варианты технических решений в будущих проектах и активах.

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

▼ актуальные ревизии всех контейнеров, представленных в СОД-процессе, в «В общем доступе» и «Опубликовано»;
▼ все неактуальные ревизии в «В архиве»;
▼ все рабочие версии ревизий контейнеров в «В работе».

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

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

⏩ ИМС-пост # 63 в PDF

🔠важаемые коллеги, доводим до вашего сведения, что все материалы, посвященные ИМС (на основе международных стандартов ИСО 19650), в формате PDF-файлов можно найти в ИМС-библиотеке. Содержание прилагаем в файле. Надеемся, что уже в скором будущем мы создадим специальный ИМС-веб-ресурс, где вся информация сможет быть представлена в более структурированном и удобном для просмотра и применения виде.

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

Следите за нами. Не теряйте нас. Делитесь своими инсайтами, размышлениями, комментариями по этой теме:

⏩ Как совместно и взаимовыгодно создавать и использовать федеративные информационные модели и за счет этого повышать эффективность управления организацией?

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

Сегодня — про информационный контейнер в состоянии «В общем доступе».

🔠остояние контейнера «В общем доступе» используется тогда, когда доступ к информации в нем необходимо открыть другим участникам производства модели или заинтересованным лицам: рабочим группам своей команды поставки, другим командам поставок, заказчику ИМ, прочим контрагентам и авторизованным пользователям.

Информационный контейнер в состоянии «В общем доступе»:

► нельзя редактировать, его можно только просматривать и рецензировать (в соответствии с установленными разрешениями, методами и процедурами);

► можно использовать только в целях, для которых информация в нем была утверждена (про статусы контейнеров, с помощью которых определяют цели применения информации, расскажем чуть позже);

► будет последней утвержденной его ревизией (про ревизии и версии ревизий контейнера расскажем чуть позже).

Контейнер в состоянии «В общем доступе» содержит утвержденную для определенной цели информацию. Чтобы эта цель была понятна всей команде поставки или назначающей стороне, ему присваивают специальный атрибут статус применения.

Таким образом, обмен контейнерами в состоянии «В общем доступе» дает возможность разным сторонам, входящим в команду поставки, согласованно осуществлять совместное производство ИМ, постоянно координируя друг с другом создаваемую информацию. Если же по итогам координации в информацию потребуется внести изменения, контейнер должен быть возвращен в состояние «В работе». В прошлом ИМС-посте мы говорили, что редактирование информации может осуществляться только ее авторами в рамках специального рабочего режима.

🔠ногда наряду с состоянием «В общем доступе» используется еще состояние «В общем доступе клиента/заказчика».

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

Но об этом — о состоянии «Опубликовано» — мы будем говорить уже в следующий раз.

⏩ ИМС-пост #62 в PDF

Следующую серию постов посвятим разбору процесса СОД. Определение этой сущности технологии управления информацией мы дали в ИМС-посте #57 «Что собой представляет процесс среды общих данных (СОД)?» (Чтобы вспомнить, посмотрите, пожалуйста, по ссылке.) СОД-процесс можно описать с помощью состояний и атрибутов информационных контейнеров. Начнем с состояний. Сегодня рассмотрим «В работе».

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

Информационные контейнеры в состоянии «В работе»:
► видны только членам рабочей группы (с установленными соответствующими индивидуальными разрешениями);
► доступны для редактирования: содержащаяся в них информация может создаваться или изменяться рабочей группой;
► неутвержденные и потому не могут быть использованы для каких-либо целей.

«В работе» — это единственное состояние, в котором данные доступны для редактирования и кодирования в требуемом технологическом формате.

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

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

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

☝️Важный момент № 2: СОД должна позволять управлять форматами любых файлов, в которых могут быть контейнеры в процессе информационного производства. Это означает, что техническое решение СОД должно при необходимости давать возможность работы и с проприетарными форматами, используемыми в специальных САПР- или BIM/ТИМ-программах, и с открытыми форматами (например, IFC, XML, PDF).

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

Продолжение следует. В следующий раз разберем состояние «В общем доступе»

⏩ ИМС-пост #61 в PDF

Делимся итогами прошедшего вебинара, посвященного теме: «Среда общих данных от проектирования до строительства». Вебинар был проведён Ассоциацией ЭАЦП «Проектный Портал», АРПП «Отечественный софт» при поддержке НОПРИЗ. Участники встречи обсудили ключевые аспекты сред общих данных (СОД) с познавательной точки зрения и их преимущества.

🎯 Некоторые выводы и тезисы:

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

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

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

💡Преимущества использования СОД в проектной деятельности:

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

Благодарим всех участников за плодотворную дискуссию и ждем новых встреч для обсуждения актуальных вопросов цифровизации в строительстве! 🤝🚀

Запись прошедшего вебинара, а также подробное резюме в источнике.
↪️ Ссылка

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

⏩ СТАТЬЯ "ИМС. Чем цифровой двойник отличается от информационной модели?"

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

Цифровые двойники в строительстве — это не революционное явление, а скорее продолжение существующей в отрасли «цифровой эволюции»: от нарисованных вручную чертежей до чертежей САПР, от чертежей САПР до BIM-моделей, от BIM-моделей до федеративных информационных моделей, а теперь — и до цифровых двойников.

ЦД, как и информационные модели, создают, чтобы принимать на их основе эффективные управленческие решения, связанные с использованием активов. Но что отличает цифрового двойника от информационной модели актива (АИМ), так это его связь с физическим активом.

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

https://bim-info.ru/articles/ims-chem-tsifrovoy-dvoynik-otlichaetsya-ot-informatsionnoy-modeli/

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

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

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

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

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

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

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

🔠роблема № 1. Интеллектуальная собственность.

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

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

🔠роблема № 2. Передача метаданных между разными СОД.

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

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

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

⏩ ИМС-пост # 60 в PDF

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

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

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

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

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

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

2️⃣Ведущие назначенные стороны (генеральные проектировщики или основные подрядчики) установили свои собственные СОД-системы, чтобы создавать ИМ в том объеме, который определен договором о поставке информации.

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

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

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

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

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

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

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

☝️👉 Чтобы оставаться верным методологии ИМС (и, соответственно, стандартам ИСО 19650), важно именно перемещать контейнеры между разными техническими решениями (локациями), а не копировать их из одного места в другие. Копирование в данном случае не допускается: в рамках СОД-пространства (неважно, распределенное оно или нет) иметь два идентичных контейнера в один и тот же момент времени 🚫 недопустимо.
➖
В следующий раз, коллеги, рассмотрим принципы и проблемы интеграции разных СОД-систем как бы в одной «экосистеме» с помощью единого для всех СОД-процесса

(продолжение следует)

⏩ ИМС-пост # 59 в PDF

⏩🔠ЦЕНАРИЙ УПРАВЛЕНИЯ ИНФОРМАЦИЕЙ (ИМС-СЦЕНАРИЙ) — описание решения управленческой задачи организации в деятельности, связанной с созданием или использованием активов, на основе принципов ИМС (то есть на основе единой информационной модели) с указанием необходимых для этого способностей (компетенций, квалификации, опыта) и возможностей (ПО, технические средства, процедуры, персонал).

Примечания:

1️⃣Процесс управления информацией не ограничивается лишь формированием «склада информации», которым в контексте ИМС можно представить информационную модель (ИМ). ИМ формируется для того, чтобы структурированная информация, которую она содержит, использовалась далее в разных информационных системах (ИС). И сценариев управления информацией здесь может быть множество.

2️⃣ Каждый конкретный ИМС-сценарий всегда специфичен. Нельзя создать одинаковые сценарии для решения одинаковых задач, но в разных организациях, потому что каждая из них имеет свою собственную систему менеджмента, свои возможности и ограничения в отношении финансовых, трудовых, производственных и прочих ресурсов.
Более того, учитывая, что все сценарии в рамках конкретной организации осуществляются на основе одной ИМ, они неизбежно будут влиять друг на друга и взаимно пересекаться. Отсюда, каждый ИМС-сценарий всегда зависит от других, и это нужно учитывать при «подключении» дополнительных сценариев к существующим. Вероятно, будут случаи, когда, соединяясь, они изменят друг друга настолько, что уместнее рассматривать их вообще как новый сценарий, а не как комбинацию.

Поэтому более уместно говорить не столько о создании отдельных ИМС-сценариев, сколько о методике их разработки. (И мы будем, разумеется, заниматься этим.) Хотя сами по себе описания реально действующих практик в этой области могут служить ориентиром и примеров для других.

3️⃣ Чем больше ИМС-сценариев организация одномоментно реализует, тем ощутимей будут для нее преимущества от управления информацией. Повышение эффективности достигается за счет повторного применения одних и тех же данных при решении разных задач. Например, созданные один раз 3d-модели или базы данных можно использовать потом в разных информационных системах и в разных сценариях. При этом не существует какого-то конечного списка таких сценариев, как и лимита систем, связанных с моделью. Все зависит от уровня процессно-управленческой и производственно-технологической зрелости организации в умении применять системный подход в работе с информацией для достижения своих целей, то есть — от ее уровня ИМС ⭐️

4️⃣ Примеры типовых задач, которые могут быть положены в основу сценариев управления информацией:
🔵Подготовка проектной документации в соответствии с ПП РФ № 87 «О составе разделов проектной документации и требованиях к их содержанию» на основе информационной модели проекта (ПИМ).
🔵Построение календарно-сетевых графиков работ на основе ПИМ.
🔵Создание актов о приемке выполненных работ КС-2 и справок о стоимости выполненных работ КС-3 на основе ПИМ.
🔵Создание сметы затрат на реконструкцию действующего объекта на основе информационной модели актива (АИМ).
🔵Построение графика работ, связанных с техническим обслуживанием инфраструктурного комплекса, на основе АИМ.
🔵Визуализация динамики работы технологических обеспечивающих систем здания на основе АИМ.

5️⃣ Показавшие свою эффективность ИМС-сценарии могут быть положены организацией в ее корпоративную систему информационного менеджмента в строительстве (КСИМС).

Серия вебинаров "Что можно взять у мира для развития ИМС в России?"

№2. Мандат информационного менеджмента в Великобритании (06-03-2025)

⏩ Cсылки на запись вебинара:
💬 RuTube
💬 VKontakte
📱 YouTube

#имс_вебинар

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

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

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

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

Как правило, для формирования необходимой СОД-системы — в зависимости от специфики задач ИМС на этапе проекта или на этапе актива — требуется множество разных интегрированных между собой систем. Например, в СОД-систему может войти:
〰️система управления инженерными данными и техническим документооборотом (СУИД);
〰️система управления геоинформационными данными (ГИС);
〰️система автоматизированного проектирования (САПР);
〰️система информационного моделирования (ТИМ-программы);
〰️система управления проектами (ИСУП) и др.

Помимо этого, организация может включать в состав СОД прочие свои корпоративные информационные системы, чтобы те напрямую использовали данные из информационной модели. Например, это может быть:
〰️система управления активами (EAM-система);
〰️система управления техническим ремонтом и обслуживанием объекта (FM-система, ТОИР-система);
〰️система планирования производственных ресурсов (ERP-система);
〰️финансово-учетная система;
〰️системы управления поставщиками, клиентами, персоналом и др.

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

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

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

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

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

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

⏩ ИМС-пост #58 в PDF

⏩ 🔠🔠🔠🔣ОРИЕНТИРОВАННЫЙ НА БЕЗОПАСНОСТЬ — деятельность организации в рамках цикла информационного менеджмента в строительстве, направленная на обеспечение безопасности чувствительной информации, связанной с активом.

⏩ 🔠УВСТВИТЕЛЬНАЯ ИНФОРМАЦИЯ — информация, несанкционированный доступ к которой, а также утрата, неправильное использование и модификация которой, могут повлечь следующие риски:
🔵отрицательно повлиять на неприкосновенность частной жизни или физическую безопасность отдельного индивида или группы лиц;
🔵стать причиной утраты интеллектуальной собственности или раскрытия коммерческой тайны организации;
🔵стать причиной коммерческого или иного экономического ущерба организации или государству;
🔵поставить под угрозу национальную безопасность, отрицательно повлиять на внутреннюю и внешнюю политику страны.

Примечания:

1️⃣ Представленные нами подходы к реализации информационного менеджмента в строительстве, ориентированного на безопасность, соответствуют методологии, установленной в стандарте ISO 19650–5:2020, Information management using BIM — Part 5: Security-minded approach to information management.

2️⃣ Может возникнуть вопрос, зачем понадобился еще один стандарт в сфере ИБ, если начиная с 2006 года действует (периодически обновляясь) ГОСТ Р ИСО/МЭК 27001 «Системы менеджмента информационной безопасности».

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

3️⃣ Внедрение ИМС с учетом безопасности информации включает в себя следующие этапы:
〰️[1] Идентификация активов, которые могут быть связаны с чувствительной информацией.
〰️[2] Разработка стратегии безопасности для выявления и снижения рисков информационной безопасности.
〰️[3] Внедрение плана управления безопасностью для реализации мер по снижению рисков ИБ.
〰️[4] Определение требований к безопасности, которые войдут в соглашения с поставщиками информации.

4️⃣ Чтобы выполнить вышеперечисленные задачи, разумеется, требуются навыки стратегического менеджмента и соответствующие полномочия, серьезный опыт в проектировании бизнес-процессов и создании организационных политик, глубокое понимание информационной безопасности и информационного менеджмента. Такой организационный проект нельзя выполнить лишь силами информационных менеджеров. Понадобится вовлеченность многих специалистов на разных уровнях управления.

👉 Таким образом, внедрение ИМС, ориентированного на безопасность, — это непростое дело. Мы оставляем для себя задачу описать специфику создания системы управления поставками информации с учетом требований к ее безопасности в наших следующих изданиях. Или это сделают уже последователи методологии, которых, как мы надеемся, будет становиться все больше ✊🤝

P.S. Мы все — информационные менеджеры (с)

⏺⏺⏺Друзья, трансляция вебинара "Мандат информационного менеджмента в строительных проектах Великобритании: что взять для развития ИМС в России?" начнется через полчаса. Присоединяйтесь по ссылке ⏺⏺⏺

Наш вебинар про новый BIM-стандарт США вызвал огромный интерес.

Если пропустили, посмотрите запись на одной из видеоплатформ:
🌐 ВК🔵🎞YT🔵🔤РТ

И приходите на 2й вебинар из серии, посвященной изучению зарубежного опыта:

🔥В четверг 6 марта поговорим про "Мандат информационного менеджмента в строительных проектах Великобритании: что взять для развития ИМС в России?". Разберем:

⚫️Причины смены мандата "BIM Level 2 (BIM Уровень 2)" на "Информационный менеджмент в соответствии с ИСО 19650"
⚫️Содержание требований к управлению информацией, установленных в новом мандате
⚫️Практику применения и текущие результаты

Регистрация по ссылке ⬅️

Уважаемые коллеги, сегодня в 11.00 приходите к нам на вебинар про информационный менеджмент в Великобритании «Что можно взять для развития ИМС в России?»

🔠роцесс СОД — это процесс управления совместным производством информационной модели (ИМ) посредством перевода контейнеров, из которых она состоит, через промежуточные состояния «В работе» и «В общем доступе», прежде чем они войдут в состав ИМ в состоянии «Опубликовано» или «В архиве».

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

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

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

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

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

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

Мы также в свое время рассмотрим примеры документирования СОД-процесса.

⏩ ИМС-пост #57 в PDF

По данным актуальных исследований, более 70% строительных проектов сталкиваются с задержками и перерасходом бюджета — как сократить риски и оптимизировать процесс?

Ответ вы найдёте в новом выпуске подкаста DV Business, где на живом примере компании «Айбим» разбираем самые действенные инструменты цифровизации и BIM-технологий.

Гость подкаста — Алексей Зотов, технологический предприниматель и управляющий партнёр «Айбим». С 2011 года команда компании провела свыше 50 масштабных проектов по автоматизации и внедрению BIM для крупнейших застройщиков, промышленных и инфраструктурных компаний России. В портфолио собственных решений «Айбим» — Larix.EST, Larix.CDB и Larix.CPM, которые в комплексе помогают экономить ресурсы и сокращать сроки строительства.

В подкасте говорят о том, как компания выросла с 2 до 80 человек, строя долгосрочные партнёрства с такими известными застройщиками, как MR Group, и делятся практическими инсайтами:
• Как правильно подойти к 3D-, 4D- и 5D-моделированию и подготовить специалистов к работе с BIM.
• Какие подходы к управлению позволяют стабильно развивать компанию на длительной дистанции.
• Как выстраивать эффективную коммуникацию с клиентами и минимизировать риски в сложных проектах.
• Какие лидерские качества важны для предпринимателя, чтобы вдохновлять команду и добиваться результатов.

Послушать можно по ссылке
Посмотреть на YouTube
Посмотреть в вк

⏩ 🔠АСКАДИРОВАНИЕ ИНФОРМАЦИОННЫХ ТРЕБОВАНИЙ — постепенная детализация и разделение информационных требований на отдельные наборы информации.

⏩ 🔠АБОР ИНФОРМАЦИИ — сгруппированный по установленным признакам объем информации, который можно определить и задокументировать, используя принципы информационного менеджмента в строительстве (ИМС).

Примечания:

1️⃣Каскадирование информационных требований может происходить как в рамках одной организации, так и в многоуровневых цепочках поставок информации между внешними назначенными сторонами.

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

3️⃣На рисунке движение информационных требований происходит вниз: от верхних уровней назначений к нижним. Однако оно может происходить и в противоположном направлении (то есть от нижних к верхним), и на одном уровне взаимодействия: между рабочими группами и даже командами поставок, входящими в команду проекта/актива в одно время.

☝️ Коллеги, создавая «речевой» контекст методологии управления информацией (ИМС), мы используем много новых понятий и определений. Если что-то не встраивается в логику, как вам кажется, или непонятно, или звучит вычурно и потому «не заходит» — пишите в комментариях, спрашивайте, предлагайте свои варианты.

👉 Вы знаете наш исповедимый здесь принцип: сначала понятные смыслы в понятном контексте — затем стандарты, требования, обязательства

🤝

Чтобы избежать потенциальных рисков, возникающих в неконтролируемой файловой структуре, информационные контейнеры в контролируемой среде общих данных (СОД) существуют в так называемых СОСТОЯНИЯХ.

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

Для управления совместным производством информационной модели необходимо, чтобы состояний, в которых может пребывать контейнер, было как минимум четыре:
〰️«В работе»;
〰️«В общем доступе»;
〰️«Опубликовано»;
〰️«В архиве».

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

В свое время мы придумали такую легкую метафору, которую сейчас хотим напомнить. Информационный менеджмент в строительстве (ИМС) — это как функция МТО (материально-технического обеспечения): определить потребность, разместить заказ на производство, произвести поставку, принять на склад. «Складом» в ИМС будет информационная модель. Оттуда заинтересованные стороны берут информацию (в виде геометрических моделей, данных об активе и документации) и используют для решения своих задач, связанных с активом или его созданием. Высший пилотаж — это когда разные информационные системы используют данные из ИМ напрямую, и модель становится цифровым двойником. Но… не все сразу, коллеги, сначала разберемся с основами…

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

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

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

В соответствии с состояниями к контейнерам применяют разные допуски и разрешения, то есть определяют и контролируют:
✴️кто может иметь к контейнерам доступ;
✴️для чего предназначена информация, которую они содержат;
✴️кто должен получить уведомление о выполненных действиях и др.

☝️👉Мы начнем подробно разбирать процедуры СОД-процесса, коллеги, в следующий раз. Оставайтесь с нами.

⏩ИМС-пост #56 в PDF

Уважаемые коллеги, приходите к нам на вебинар. Будет интересно. Обещаем!

В 2021 году в Великобритании приняли государственную стратегию по развитию инфраструктуры — "Transforming Infrastructure Performance: Roadmap to 2030". Она устанавливала требование использовать ISO 19650 "Информационный менеджмент с применением BIM" в проектах с госучастием.

📆 6 марта в 11:00 (МСК) на вебинаре присмотримся к зарубежному опыту, сравним с отечественным и выберем, что можно взять для себя. Разберем:

⚫️Причины смены мандата "BIM Level 2 (BIM Уровень 2)" на "Информационный менеджмент в соответствии с ИСО 19650"
⚫️Содержание требований к управлению информацией, установленных в новом мандате
⚫️Практику применения и текущие результаты

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

✨ 1️⃣1️⃣1️⃣ —  Информационный менеджмент в строительстве

Участие бесплатное
Регистрация по ссылке ⬅️

⏩ 🔠ЛЮЧЕВОЕ СОБЫТИЕ ПОСТАВКИ ИНФОРМАЦИИ —запланированный обмен информацией между назначающей и ведущей назначенной стороной в рамках соглашения между ними. Другими словами, это передача заказчику созданной для него исполнителем информационной модели.

⏩ 🔠РИГГЕРНОЕ СОБЫТИЕ изменяет актив (или его статус), вследствие чего информационная модель актива (АИМ) должно быть обновлена. Триггерные события бывают:
〰️предсказуемые (например: регулярное техническое обслуживание, изменение законодательства, осмотр, инспекция и др.);
〰️непредсказуемые (например: аварийная ситуация, погодная аномалия, изменение законодательства, стихийное бедствие, изменение спроса на коммерческую недвижимость, покупка актива и др.).

Комментарии:

1️⃣Ключевые события поставки информации определяют на основе Плана проекта или Планов, связанных с использованием актива.

2️⃣С помощью ключевых событий происходит формирование и ведение информационных моделей.

3️⃣Организация на основе принципов эффективности сама решает, в отношении каких триггеров будет применять управление информацией (ИМС), и документирует их в Графике триггерных событий.

4️⃣Срок ключевого события поставки информации на этапе использования актива определяется моментом наступления триггерного события, в результате которого запускаются соответствующие процессы в цикле ИМС и начинается совместное информационное производство.

Например: «обновить ИМ не позднее 10 дней после технического обслуживания объекта» означает, что ключевое событие поставки в соответствии с указанным триггером должно произойти “<10+” дней).

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

🔠етаданные (metadata) — это данные, которые определяют и описывают другие данные (ГОСТ 33707–2016. Информационные технологии). В нашем случае метаданные описывают информационный контейнер и информацию, которую он содержит.

Метаданные у файлов могут автоматически создаваться операционными системами и приложениями. Но для нас представляют интерес те специфические метаданные, которые мы будем присваивать контейнерам с помощью технического решения СОД для реализации СОД процесса, то есть для управления ими. Будем называть их — атрибутами информационного контейнера. (☝️Не путать с атрибутами BIM-модели!)

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

Атрибуты группируются на две категории:
➖неизменяемые атрибуты («Уникальный идентификатор», «Классификация»);
➖изменяемые атрибуты («Состояние», «Статус», «Ревизия/версия»).

Подробно их разберем в следующих постах, а сейчас коротко опишем.

➡️УНИКАЛЬНОЕ НАИМЕНОВАНИЕ

У информационного контейнера должно быть неизменяемое Уникальное наименование (уникальный идентификатор, ID), которое:
1) присвоенное в момент создания контейнера, больше никогда не поменяется;
2) существует в СОД в единственном числе у данного контейнера.

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

➡️СОСТОЯНИЕ

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

➡️СТАТУС (или СТАТУС ПРИМЕНЕНИЯ)
С помощью атрибута Статус указывают, в каких целях нужно использовать контейнер (например: «предназначен для координации», «для рецензирования», «для утверждения», «для передачи заказчику» и т. д).

➡️РЕВИЗИЯ И ВЕРСИЯ РЕВИЗИИ
С помощью атрибутов Ревизии и версии можно показать историю изменений контейнера к данному моменту в процессе своего производства.

➡️КЛАССИФИКАЦИЯ
С помощью классификационного кода в качестве атрибута можно описать содержание контейнера в соответствии с выбранной системой классификации (например, с Классификатором строительной информации).

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

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

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

⏩ИМС-пост #55 в PDF

🔠важаемые коллеги, кто не смог неделю назад посмотреть наш вебинар про американскую попытку локализовать ИСО 19650 "Информационный менеджмент с применением BIM", мы выкладываем ссылки на видео и презентацию.

🔠ерез месяц планируем продолжить серию вебинаров "Что нам взять для развития ИМС в России?" и рассказать про Великобританию, а именно про их национальный мандат (то есть требование) использовать ИСО 19650 в инфраструктурных проектах с государственным участием. Следите за нашими анонсами здесь и на корпоративном ТГ-канале.

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

🔠 ИМС ИМ определяют как совокупность связанных информационных контейнеров со структурированной (3d-модели, данные об активе) и неструктурированной (тексты, мультимедиа, изображения) информацией.

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

👉 ИМ — база данных (БД), а СОД — ее система управления (СУБД).

🔠авайте еще раз проясним информационный контейнер в сравнении с файлом.

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

В модели мы имеем дело с множеством контейнеров с разным содержанием, закодированных в разных форматах: .xml, .ifc, .txt, .pdf, .jpeg и др.

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

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

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

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

В файловой среде пользователи могут свободно создавать файлы (то есть контейнеры) и присваивать им разнообразные и часто спонтанные наименования.

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

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

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

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

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

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

⏩ ИМС-пост #54 в PDF

⏩🔠НФОРМАЦИОННЫЙ ПРОТОКОЛ — документ, который готовит назначающая сторона (заказчик ИМ) при подготовке цикла информационного менеджмента в строительстве (ИМС), чтобы затем включить в договоры между всеми задействованными назначенными сторонами в совместном производстве информации.

Информационный протокол предназначен:

1️⃣закрепить в юридически значимых документах требования назначающей стороны по использованию технологий информационного производства;

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

➖
Комментарии:

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

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

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

✔️ Подробно мы расскажем о структуре информационного протокола и представим его шаблон во второй части книги Смирнова Д., Зотова А. «Популярный Информационный менеджмент в строительстве. Часть 2. Цикл управления информацией: функции, процессы, документы». (☝️👉Текущий статус: началась редактура и первая вычитка рукописи, графический дизайнер приступил к созданию инфографики.)

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

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

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

Чтобы правильно понять концепцию среды общих данных, нужно различать ее два аспекта:
▶️ СОД как процесс управления информационными контейнерами в совместной деятельности сторон при производстве, хранении и использовании ИМ;
▶️СОД как техническое решение (или СОД-система) в виде комплекса программных, сетевых и технических средств, с помощью которых выполняется СОД-процесс.

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

🔠 позиции методологии ИМС существует два заблуждения относительно СОД.

1️⃣Первое заблуждение состоит в том, что СОД — это какое-то одно программное решение на одной ИТ-платформе в одном месте (в одном «облаке»).

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

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

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

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

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

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

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

Не допускать:
✅дублирования информации;
✅нецелевого распространения информации;
✅остановки производственных процессов.

Все это позволит реализовать основные принципы работы с информацией, а именно:
🌀 создавать ее один раз, но многократно использовать в разных задачах;
🌀 иметь доступ к ней на постоянной основе;
🌀 иметь надежную и сохраняемую историю производства ИМ;
🌀 проверять и утверждать ее перед тем, как отдать заказчику;
🌀 использовать только в тех целях, для которых она была предназначена.

⏩ИМС-пост #53 в PDF