СОД в строительстве: вызовы, подходы и пути развития

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

Как можно это исправить? Ответы постарался дать генеральный директор инжиниринговой компании ICE Unity Андрей Ерофеев. В рамках конференции ПРО ТИМ СОД он рассмотрел причины отставания строительной отрасли в цифровизации, пути решения этой задачи и предложил слушателям идеальный образ среды общих данных.

Про актуальность СОД и почему в строительстве всё «не так»

По словам Ерофеева, термин в настоящее время имеет достаточно расплывчатое значение. Под ним подразумевают программные продукты с различным функционалом: от простых систем хранения данных до комплексных платформ управления проектами. Затем эксперт напомнил, как интерес к СОД усилился после появления облачного решения Autodesk BIM 360 — платформы, объединившей традиционные папки и файлы в облаке.

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

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

1. Документо-центричный подход

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

2. Творческое сопротивление

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

3. Прозрачность как угроза

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

4. Автоматизация без процессов

Одна из ключевых ошибок при внедрении цифровых решений — попытка автоматизировать несуществующие или плохо сформулированные процессы. Без четко выстроенной структуры работы никакая система не сможет работать эффективно. Это правило хорошо известно в IT‑среде: автоматизация хаоса порождает автоматизированный хаос.

5. Отсутствие исполнителей и ролей

Даже самые лучшие решения не могут быть реализованы без участия человека. Эксперт отметил, что на предприятиях часто нет чёткого понимания о том, кто именно должен заниматься цифровыми инициативами. Нет никаких утвержденных ролей, например, BIM‑оператора, цифрового технического заказчика или специалиста по цифровому управлению строительством (DCM).

Скачать презентацию спикера

Что уже должно было быть реализовано в СОД?

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

1. Рассеивание внимания

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

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

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

2. Разделение информационных потоков

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

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

3. Workflow и согласования

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

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

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

4. Cтруктура приложения

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

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

5. Значение открытых API и расширяемости систем

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

Что можно и нужно делать сегодня?

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

1. Модель как база данных

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

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

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

2. Проблема ввода данных и необходимость MDM‑систем

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

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

3. Структуры декомпозиции: PBS, WBS, OBS и пр.

По мнению Андрея Ерофеева, важнейшим элементом в управлении проектами являются так называемые структуры декомпозиции (breakdown structures), которые описывают конфигурацию проектных и организационно-технологических решений, а также помогают ими управлять:

• PBS (Product Breakdown Structure) — структурная декомпозиция продукта
• WBS (Work Breakdown Structure) — структурная декомпозиция проекта
• OBS (Organizational Breakdown Structure) — иерархия участников и ролей
• FBS, GBS — функциональные и технологические структуры, часто применяемые в промышленных проектах

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

4. IDS и LOIN

Понятие LOIN (Level of Information Need) подразумевает под собой требования к уровню проработки информации, основанные не на абстрактных стандартах, а на реальных потребностях проекта. Такой подход «от задач к данным» помогает отказаться от формального выполнения нормативов и перейти к осмысленной работе с конкретной целью.

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

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

5. Переход к единым моделям и тяжёлым САПР

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

Преимуществом подобного подхода является устранение барьеров в коммуникации: не нужно запрашивать актуальные версии файлов, пересылать их по почте, проверять на актуальность. Все изменения происходят в реальном времени и доступны всем участникам проекта. Примерами таких систем служат зарубежные NX от Siemens, CATIA от Dassault Systems и PTC Creo. Среди отечественных аналогов подобных систем можно вспомнить PlantLinker.

Что следует разрабатывать в будущем?

В завершение своего выступления Андрей Ерофеев озвучил пять напутствий для разработчиков программных продуктов для нужд строительной отрасли:

1. От BIM к управлению закупками

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

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

2. Smart-стандарты и надежды на автоматизацию проверки соответствия

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

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

3. Управление знаниями как следующий этап цифровизации

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

4. Искусственный интеллект и терминологический консенсус

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

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

5. От проектирования задач к проектированию действий

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

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

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

Остались вопросы?

Запросить консультацию у эксперта

Выводы

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

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