Уровень ИМС

ИНТЕРВЬЮ С ДМИТРИЕМ СМИРНОВЫМ (АЙБИМ): ОТ ТЕОРИИ К ПРАКТИКЕ ИМС

Говорят, любого слона можно съесть по кусочкам. Но в строительном цифровом менеджменте мы имеем дело со зверем покрупнее — с китом. Не зря он стал символом ИМС - методологии, которую создает компания АЙБИМ!

Чтобы понять, что это за зверь и с чем его едят, мы расспросили Дмитрия Смирнова, одного из авторов книг «Популярный ИМС».

⏩ Что такое информационный менеджмент в строительстве простыми словами?

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

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

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

⏩ Почему BIM-модель сама по себе не решает проблему путаницы в данных?

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

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

⏩ Какую роль в этой системе играет ISO 19650?

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

При этом ISO 19650 — не готовая инструкция на все случаи жизни и не описание конкретной программы. Стандарт задаёт принципы, которые каждая организация должна адаптировать к своим проектам, активам, структуре и системе управления. Его ценность именно в том, что разные участники получают согласованные правила взаимодействия.

Здесь нужно обязательно сказать, что в настоящий момент существующие стандарты ISO серии 19650 пересматриваются, и в 2027 их опубликуют в новых редакциях. Но наша книга уже содержит методологические инновации, которые войдут в нормативные документы.

⏩ Что изменит искусственный интеллект в управлении строительными проектами и активами в виде зданий и сооружений?

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

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

СИЛА ИСКУССТВЕННОГО ИНТЕЛЛЕКТА — В КОНТЕКСТЕ ИМС

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

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

потребность → требование → информационная задача → результат → ревизия → проверка → решение → фактическое использование.

Каждое звено отвечает на отдельный вопрос. Зачем информация понадобилась? Кто должен её произвести и кому передать? Какой результат ожидается? По каким критериям его проверяют? Какая ревизия действительно рассматривалась? Кто принял решение и где сведения затем применили?

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

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

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

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

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

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

ИИ НЕ ИСПРАВИТ ИНФОРМАЦИОННЫЙ БЕСПОРЯДОК

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

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

Представим вопрос: «Какую схему вентиляции разрешено использовать для выполнения работ?» В хранилище находятся пять вариантов. Самый новый файл содержит исправления, но ещё не прошёл техническую проверку и не был авторизован. Предыдущая ревизия официально опубликована, однако её уже заменяют. Если эти различия существуют только в переписке или памяти участников, ИИ может уверенно выбрать не тот документ.

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

Для надёжной работы ИИ необходимы связи: какая потребность породила требование; какой информационный результат ожидался; кто отвечает за контейнер; какая ревизия передана; какие проверки она прошла; какое решение принято; кем и для какого применения она авторизована.

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

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

Искусственный интеллект может ускорить работу с информацией. Если информация не упорядочена, он рискует так же ускорить ошибку. Поэтому путь к надёжному ИИ начинается не с алгоритма, а с информационного менеджмента.

ШЕСТЬ ВОПРОСОВ К ХОРОШЕМУ ИНФОРМАЦИОННОМУ ТРЕБОВАНИЮ

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

В информационном менеджменте в строительстве (ИМС) информационное требование — это структурированное описание потребности. Проверить его качество помогают шесть вопросов.

1. Кому нужна информация? Получатель — не абстрактный «заказчик», а конкретная функция или группа: служба эксплуатации, специалист по закупкам, проектировщик смежного раздела. От компетенций и процессов получателя зависит форма результата.

2. Зачем она нужна? Цель связывает информацию с деятельностью или решением. «Для выбора насоса», «для планирования обслуживания» и «для подтверждения соответствия» требуют разных сведений даже об одном объекте.

3. Какой уровень информационной потребности (УИП) достаточен? Здесь определяют необходимое количество, качество и детализацию. Не максимум возможных атрибутов, а ровно тот уровень, который позволяет достичь цели без дефицита и перепроизводства данных.

4. В каком формате и каким способом передать результат? Таблица, модель, документ или их сочетание; схема данных, единицы измерения, правила именования, канал поставки — всё это должно быть согласовано до начала производства информации.

5. Какие вспомогательные ресурсы использовать? Шаблоны, классификаторы, справочники, нормативные документы и примеры помогают поставщику одинаково понять требование и снижают пространство для догадок.

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

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

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

ПОЧЕМУ «ПЕРЕДАЙТЕ ВСЮ ДОКУМЕНТАЦИЮ» НЕ РАБОТАЕТ?

Перед завершением проекта заказчик нередко формулирует требование просто: «Передайте всю документацию». Кажется, что так надёжнее: чем больше файлов получено, тем меньше риск что-то потерять. На практике слово «всю» не создаёт полноту — оно скрывает отсутствие определённой потребности в информации.

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

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

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

Хорошее информационное требование определяет, кому и зачем нужна информация, какое содержание и уровень информационной потребности (УИП) достаточны, в каком формате и каким способом представить результат, какие справочные материалы использовать и к какому сроку выполнить поставку. Тогда поставщик понимает границы работы, а получатель — по каким признакам проверять результат.

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

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

ПРИНЯТО — НЕ ЗНАЧИТ ИСПОЛЬЗОВАНО

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

В информационном менеджменте в строительстве (ИМС) важно различать Acceptance и Actual Use — приёмку и фактическое использование. Между ними может оказаться значительный разрыв.

Эксплуатирующая организация, например, получила информационную модель актива (АИМ) со сведениями об оборудовании. Формально всё поставлено: паспорта, гарантийные сроки, регламенты обслуживания и идентификаторы элементов. Но специалисты продолжают пользоваться прежними таблицами, потому что новая информация не встроена в их процессы технического обслуживания и ремонта. Поставка принята, а управленческий результат не достигнут.

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

Поэтому цепочка ИМС не должна заканчиваться на приёмке:

⏩ потребность → требование → информационная задача → результат → проверка → приёмка → использование → решение или действие.

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

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

Приёмка отвечает на вопрос: «Получили ли мы то, что заказывали?» Использование — на вопрос: «Помогло ли это выполнить работу, принять решение или управлять активом?» Для зрелого ИМС необходимы оба ответа.

ПРОВЕРЕНО — НЕ ЗНАЧИТ ПРИНЯТО

В проектной переписке слово «проверено» часто звучит как окончательный вердикт: документ можно передавать дальше и использовать. Но что именно проверили? Наличие обязательных полей? Правильность расчёта? Соответствие требованиям заказчика? Или заказчик уже согласился принять результат? Это разные вопросы — и отвечать на них могут разные стороны.

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

Техническая проверка (Technical Verification) подтверждает, что информационный контейнер оформлен по установленным правилам. Например, у него правильный идентификатор, заполнены обязательные атрибуты, соблюдён формат, отсутствуют повреждения, а модель содержит требуемые объекты и параметры. Во многих случаях такие проверки можно автоматизировать.

Валидация или рассмотрение информации (Information Validation/Review) отвечает уже не на вопрос «правильно ли оформлено?», а на вопрос «пригодно ли содержание для установленной цели?». Наличие параметра огнестойкости можно проверить автоматически. Но соответствует ли его значение нормам и проектному решению, может оценить компетентный специалист.

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

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

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

Фраза «проверка пройдена» полезна только тогда, когда понятно: какая именно проверка, по каким критериям, кем выполнена и какое решение после неё принято.

«АКТУАЛЬНАЯ ВЕРСИЯ» — ЕЩЁ НЕ РАЗРЕШЕНИЕ

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

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

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

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

Статус применения отвечает на другой вопрос: для чего разрешено использовать данную ревизию. Один и тот же чертёж может быть пригоден для координации, но не авторизован для строительства; модель — разрешена для расчёта объёмов, но не для заказа оборудования. Слова «проверено», «принято» и «можно применять» описывают разные управленческие действия и не должны подменять друг друга.

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

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

«Самая новая» отвечает только на вопрос времени. «Разрешённая для конкретной цели» — на вопрос управления. В ответственном проекте нужны оба ответа.

СОД — НЕ ПРОСТО ОБЩАЯ ПАПКА

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

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

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

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

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

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

Общая папка отвечает на вопрос: «Где лежит файл?» Зрелая СОД — ещё и на вопросы: «Что это за информация, в каком она состоянии, кто за неё отвечает и что с ней разрешено делать?» Именно эта разница превращает хранение файлов в информационный менеджмент.

СНАЧАЛА ЗАДАЧА — ПОТОМ ИНФОРМАЦИЯ

Фраза «нам нужна информационная модель» звучит убедительно, но почти ничего не говорит поставщику информации. Какая модель? Для кого? К какому сроку? И главное — для какой деятельности и решения какой задачи?

В информационном менеджменте в строительстве (ИМС) потребность в информации не должна возникать сама по себе. Её источник — практическая задача: выбрать вариант, утвердить решение, оценить риск, спланировать работы, принять результат, организовать обслуживание актива.

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

Логика получается такой:

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

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

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

И обратная ошибка: сначала заказать дорогостоящую 3D-модель или базу данных, а затем искать им применение. В таком случае технология начинает формировать потребность вместо того, чтобы обслуживать деятельность организации. Результат может выглядеть впечатляюще, но не поддерживать ни одного реального решения.

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

Хорошая информационная модель (ИМ) — не та, в которой содержится всё. Это модель, в которой нужная информация появляется своевременно до того, как возникает необходимость принимать решение на ее основе.

ЧЕМ БОЛЬШЕ ИНФОРМАЦИИ, ТЕМ ЛУЧШЕ?

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

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

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

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

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

Для формализации этой меры применяется уровень информационной потребности (УИП; Level of Information Need). УИП помогает определить, зачем и кому нужна информация, когда её следует поставить, к какому объекту она относится и как должен быть описан ожидаемый информационный результат.

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

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

ЗАЧЕМ ОТРАСЛЕВОМУ СПЕЦИАЛИСТУ ИМС?

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

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

Профессиональная компетентность помогает специалисту понять, какое техническое решение является правильным. ИМС отвечает на другую группу вопросов:

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

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

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

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

Поэтому владеть ИМС — не значит обязательно становиться BIM-менеджером или ИТ-специалистом. Это значит понимать правила совместной работы с информацией в современной строительной отрасли.

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

ИНФОРМАЦИОННАЯ МОДЕЛЬ — ЭТО НЕ ОБЯЗАТЕЛЬНО 3D-МОДЕЛЬ

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

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

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

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

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

3D-модель остаётся важным компонентом ИМ, но не является её обязательным центром. Более того, в конкретном ИМС-сценарии федеративная модель может вообще не содержать геометрию — например, если решение принимается на основе реестров, документов и эксплуатационных данных.

Поэтому вопрос «Есть ли у нас информационная модель?» нельзя сводить к вопросу «Есть ли у нас 3D?». Правильнее спросить: объединена ли необходимая информация так, чтобы её можно было найти, проверить и использовать для предусмотренной цели?

ЗДАНИЕ ПОСТРОЕНО. А ГДЕ ИНФОРМАЦИЯ О НЁМ?

К моменту ввода объекта в эксплуатацию информации обычно накоплено более чем достаточно: проектная и исполнительная документация, расчёты, спецификации, паспорта оборудования, акты, 3D-модели, журналы работ. Но большое количество переданных файлов ещё не означает, что организация получила пригодную для работы информацию.

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

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

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

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

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

Завершить строительство физического актива и сформировать пригодную для использования АИМ — два разных результата. Если второй не запланирован заранее, эксплуатация почти неизбежно начнётся с нового сбора уже когда-то созданной информации.

⏩ ИМС-пост # 126. Структура ПОИП. 7. Предложения по технологиям информационного производства. Часть 8 (8)

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

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

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

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

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

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

👉 Но здесь важно помнить следующее: BIM в определении стандартов ИСО 19650 — это не технология трехмерного информационного моделирования, а технология работы с разными форматами данных в едином информационном пространстве, которое называется СРЕДОЙ ОБЩИХ ДАННЫХ. И эта СОД не ограничивается какой-то одной информационной системой, как это обычно принято считать. В контексте стандартов (и, соответственно, ИМС) это, скорее, «мета-СОД», которая связывает разные «обычные» СОД и участников информационного производства в работе с объектами капитального строительства на разных этапах из жизненного цикла.

Но давайте остановимся на этом моменте. Продолжим уже после августовских отпусков.

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

⏩ ИМС-пост # 125. Структура ПОИП. 6. Предложения по информационному стандарту. Часть 7 (8)

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

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

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

🔠аковы особенности информационных стандартов в ИМС?

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

Например, в области строительства и эксплуатации капитальных объектов и градостроительных территорий они представлены:
🔵стандартами по разработке и оформлению технических решений в соответствии с Системой проектной документации для строительства (СПДС);
🔵сводами правил по информационному моделированию в строительстве (BIM/ТИМ-стандарты);
🔵нормативами по управлению геоданными (ГИС-стандарты);
🔵техническими спецификациями схем и форматов данных
и другими источниками.

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

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

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

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

Назначающая сторона может сама устанавливать требования к оформлению этого документа/ресурса — на основе сложившейся практики или руководствуясь отраслевыми нормативными документами в этой области (например, ГОСТ Р 57563–2017 / ИСО 12911:2012 «Моделирование информационное в строительстве. Основные положения по разработке стандартов информационного моделирования зданий и сооружений»).

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

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