СОД 2.0: от проектного контекста к управлению изменениями в строительстве

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

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

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

Почему контекста недостаточно?

Контекстный слой помогает ответить на важные вопросы:

• Что изменилось в модели, документе или связанной части проекта?
• Какие замечания, задачи и материалы связаны с этим изменением?
• Где сосредоточены основные проблемы и риски?
• Какова текущая ситуация по модели, разделу или зоне? 

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

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

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

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

Изменение как объект управления

В строительном проекте важно не только зафиксировать, что изменился документ или модель. Важно понять, что это изменение означает для проекта.  

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

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

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

Что должно проверяться?  

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

Выполнение требований  

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

Например, изменение положения шахты, трассы инженерной системы или состава помещения может повлиять на:

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

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

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

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

Стоимость

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

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

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

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

Сроки

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

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

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

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

Пример: изменение шахты

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

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

После этого участники проекта выбирают дальнейшее действие:

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

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

СОД 2.0 как среда связанных решений

На этом этапе СОД 2.0 можно рассматривать не просто как место хранения и анализа информации, а как среду управления связанными проектными решениями.

Она связывает:

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

При этом СОД 2.0 не обязана заменять все специализированные системы. Модель продолжает разрабатываться в BIM-системе. Календарный план может вестись в системе планирования. Смета — в сметной или финансовой системе. Исполнительная документация — в системе, принятой на проекте.

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

  Проверяемость и ответственность

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

Первый вид — исходные факты: версии моделей и документов, статусы задач, замечания, сведения из сметы и графика.

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

Третий вид — выводы, которые требуют инженерной и управленческой оценки. 

Например:

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

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

Для каждого значимого решения, влияющего на требования, стоимость, сроки, безопасность или договорные обязательства, необходимо сохранять:

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

Так формируется не просто архив документов, а доказательная история проекта.

 Где ИИ наиболее полезен?

Когда проектный контекст подготовлен, ИИ-ассистент может работать не только как поиск по файлам, но и как помощник при анализе изменений.

Например, он может помочь ответить на вопросы:

1. «Какие требования, проектные решения, замечания и задачи связаны с этим изменением?»
2. «Какие работы, материалы, сметные позиции и операции графика могут быть затронуты, и каковы возможные последствия для стоимости и сроков?»
3. «По каким изменениям ещё не оценено влияние на требования, стоимость, сроки или риски?»
4. «Подготовь сводку для ГИПа по критическим изменениям, открытым вопросам и решениям, влияющим на сроки и бюджет».

При этом система должна различать подтверждённые связи и кандидаты на связь, предложенные ИИ.

Связи, определённые по идентификаторам, объектам, зонам, версиям, задачам, правилам или утверждённым решениям, показываются как подтверждённые.

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

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

Что меняется для участников проекта?

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

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

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

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

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

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

Как начать переход?

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

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

Для этого необходимо определить:

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

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

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

Выводы

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

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

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

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