Почему стандарты цифровизации стройки не работают и как их исправить?

Аналитический отчет: Проблемы и перспективы нормативного регулирования цифровизации строительства в России

Введение

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

1. Диагностика основной проблемы: разрыв между теорией и практикой в разработке стандартов

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

1.1. Критика подхода "теоретиков" к стандартизации

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

• Игнорирование природы цифровых стандартов. Регуляторы продолжают писать стандарты в виде текстовых инструкций, в то время как в цифровую эру стандартизация должна быть технической. Вместо описания "как правильно делать" на бумаге, государство должно создавать цифровую инфраструктуру и программные интерфейсы (API), в рамках которых участники рынка могут действовать только корректным, заранее определенным образом.

• Использование устаревших инструментов. Попытки управлять современной IT-отраслью предпринимаются с помощью неадекватных инструментов, таких как Microsoft Word и PowerPoint. Эти инструменты не позволяют создавать машиночитаемые, проверяемые и однозначные нормы.

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

1.2. Неверная модель мотивации и игнорирование реальности

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

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

• Мотивация через монополизацию. Разработчикам ПО предлагается ложная мотивация. Вместо стимула создавать полезный и эффективный продукт, им предлагается "гонка": первым реализовать некомпетентное ТЗ от регулятора и, как следствие, монополизировать рынок, получив возможность диктовать любые цены.

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

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

2. Анализ неэффективных и устаревших нормативов

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

2.1. Провальная реализация XML-схем

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

• Частично работающий пример (пояснительная записка). Реализация XML-схемы для пояснительных записок, выполненная Главгосэкспертизой, является примером плохой, но условно работающей системы. Несмотря на низкое качество реализации, она "со скрипом работает" исключительно благодаря одному фактору: ведомство не только опубликовало стандарт, но и предоставило бесплатный веб-интерфейс для ручного заполнения всех необходимых полей. Это позволило проектировщикам выполнять требование, пусть и в неудобном формате.

• Полностью провальный пример (исполнительная документация). Внедрение XML для исполнительной документации представляет собой образец отвратительной реализации и является полностью нерабочим по ряду причин:

1. Неготовность инфраструктуры: Со стороны Госстройнадзора и государственных заказчиков отсутствуют информационные системы, способные принимать и подписывать документы в данном формате.
2. Отсутствие инструментов: Минстрой не предоставил никаких бесплатных инструментов для валидации (проверки) сгенерированных XML-документов, оставляя разработчиков без возможности протестировать корректность своей реализации.
3. Устаревшие данные: Сами XML-схемы были выгружены из некой коммерческой системы, которая с тех пор уже обновилась и сама перестала им соответствовать. Стандарт был опубликован в неактуальном виде.
4. Непрозрачность и коррупционные риски: Отсутствует открытый API к государственной шине данных. Подключение к ней возможно только по "серым схемам" за дополнительную плату, что создает почву для коррупции и блокирует доступ для независимых разработчиков.

2.2. Нормативы, требующие отмены и переработки

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

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

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

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

3. Искажение рынка: картельный сговор как следствие регулирования

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

3.1. Механизм создания монополии

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

• Участники сговора: В схеме участвуют компании Amethyst Capital, Exon, ЦУС и МСУ.

• Ключевой инструмент: Компания Exon создала продукт ИСУП (Информационная система управления проектами) путем копирования части функционала своего основного коммерческого продукта. Этот продукт был представлен рынку под видом решения от "Росатомстрой".

• Техническая связка: Компании ЦУС и МСУ получили эксклюзивное подключение к ИСУП через закрытую шину данных Buildbus.

• Роль государства: Минстрой выступил соучастником схемы, разместив на своем официальном сайте XML-схемы, которые технически необходимы для передачи данных именно через шину Buildbus в ИСУП. Это создало нормативное требование, которое могут выполнить только участники сговора.

• Техническая зависимость: Система ИСУП до сих пор не является полностью изолированной и "под капотом" использует серверные мощности Exon, что подтверждает ее аффилированность.

3.2. Последствия для отрасли

Данный сговор оказывает крайне негативное влияние на строительный рынок.

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

• Навязывание неэффективных решений: Подрядчики, работающие на госконтрактах, вынуждены покупать дорогое (~1 млн рублей на проект) и неэффективное программное обеспечение "для галочки", чтобы формально соответствовать требованиям договора.

• Формальное использование: Купленное ПО не используется для реального повышения эффективности. Его приобретают лишь для того, чтобы один раз отправить документы в ИСУП. Завышенная цена при таком сценарии использования выглядит как "форма отката". Таким образом, государственное регулирование не только не стимулирует, но и прямо поощряет фиктивную цифровизацию, где дорогостоящие IT-решения служат не инструментом эффективности, а элементом бюрократического ритуала.

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

4. Пути решения: предложения по созданию эффективной нормативной базы

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

4.1. Разработка новых классификаторов и справочников

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

• Классификатор элементов BIM-модели. В качестве успешного примера можно рассматривать классификатор КЦИМ, который уже прошел апробацию в Карелии, Свердловской области и Татарстане и может стать основой для федерального стандарта.

• Классификатор видов работ и справочник конструктивных решений. Такой справочник необходим для корректного формирования цифровой ведомости объемов работ (ВОР) и должен содержать исчерпывающий перечень конструктивных решений для всех видов объектов.

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

• Укрупненные справочники. Для эффективного управления проектами необходимы верхнеуровневые справочники трудоемкости и стоимости для конструктивных решений. Текущая детализация сметных нормативов (ГЭСН) является избыточной для целей оперативного контроля и планирования.

4.2. Пересмотр требований к BIM-моделям

Необходимо изменить подход к формированию требований к информационным моделям.

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

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

4.3. Адаптация успешного зарубежного опыта

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

• Специфичные требования для разного ПО: Вместо создания единого "усредненного" стандарта британские регуляторы разработали отдельные требования для BIM-моделей, созданных в разных программных продуктах. Цель такого подхода — не создавать универсальный, но посредственный стандарт, ограниченный возможностями самого "слабого звена", а, наоборот, максимально использовать сильные стороны каждой программной платформы.

4.4. Обеспечение открытости государственных систем

Для демонополизации рынка и создания здоровой конкуренции необходимо реализовать ключевое требование:

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

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

5. Стратегическое видение: к новому фреймворку нормативного регулирования

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

5.1. Создание машиночитаемых и машинопонимаемых норм

Концепция нового нормативного фреймворка предполагает следующие шаги:

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

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

• Цели и преимущества: Перевод нормативной базы в такой формат откроет принципиально новые возможности:

1. Программная проверка требований на непротиворечивость и отсутствие дублирования еще на этапе их разработки.
2. Однозначная трактовка требований как человеком, так и компьютерными системами, что исключает разночтения.
3. Возможность автоматизированных проверок BIM-моделей, проектной и исполнительной документации на соответствие нормам.

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

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

6. Заключение: оценка роли законодательства и итоговые рекомендации

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

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

Разбор проблемы: Почему цифровая стандартизация в строительстве не работает

Введение: Ключевой конфликт

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

1. Корень проблемы: «Теоретики» против «Практиков»

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

1.1. Старый подход в новом мире

Традиционный подход к стандартизации стал неэффективен по нескольким ключевым причинам:

• Бумажная стандартизация. Раньше нормативы писались на бумаге (ГОСТы, СП), где буквами описывалось, «как правильно» ставить подписи и согласовывать документы. Этот метод абсолютно не подходит для цифровой эры, где процессы должны регулироваться программными интерфейсами, а не текстовыми инструкциями.
• Инструменты теоретиков. Авторы современных стандартов по цифровизации зачастую владеют только Word и PowerPoint. Этими инструментами они пытаются регулировать сложную IT-отрасль, не понимая ее специфики и технологических основ.
• Непонимание разработки ПО. «Теоретики» не имеют практического опыта в создании программных продуктов. Из них получаются плохие продукт-менеджеры и продакт-оунеры. Из-за этого их стандарты превращаются в неэффективные технические задания (ТЗ), которые не воплощаются в работающие решения, а создают барьеры и костыли, которые разработчикам приходится обходить.

1.2. Что такое правильная цифровая стандартизация?

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

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

2. Кейс-стади: Два подхода к XML-стандартам

Сравнение двух примеров внедрения XML-стандартов наглядно демонстрирует разницу между работающим и провальным подходом.

Рис 1

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

3. Последствия неверной стандартизации

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

• Искаженная мотивация разработчиков. Государство создает кривую мотивацию. IT-компании стимулируют не создавать лучший продукт для повышения эффективности, а стремиться первыми выполнить некомпетентное ТЗ от регулятора. Тот, кто сделает это первым, сможет монополизировать рынок и выставлять любую цену, поскольку все участники будут обязаны использовать его решение по нормативному требованию.
• Создание монополий и картельных сговоров. Непрозрачные требования порождают монополии. Яркий пример — картельный сговор компаний Amtiist Capital, EXO, ЦИУС и МСР, организованный компанией Exon. Государственная система ИСУП по сути является копией коммерческого продукта Exon, а под капотом API-запросы на работу с файлами до сих пор идут на серверы самого Exon. Через закрытую шину данных и специфические требования к XML-схемам они полностью блокируют доступ к рынку госконтрактов для других разработчиков.
• Бесполезные расходы для подрядчиков. Подрядчики на госконтрактах вынуждены покупать дорогое ПО («миллион рублей на каждый проект») просто «для галочки». Они приобретают его не для повышения эффективности, а лишь для формального соответствия требованиям, чтобы один раз отправить документы. В реальной работе этот софт, похожий на завуалированный откат, не используется.
• Торможение развития из-за плохих нормативов. Некоторые существующие нормативы прямо мешают цифровизации:

1. SP-33 — некорректно и «криво» описывает принципы работы с BIM.
2. Классификатор строительной информации (КСИ) — написан некомпетентно. То, что сделал Владимир Волкодав с таблицами 4, 5 и 6, — это дикий ужас, который нужно просто удалять.

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

4. Чего на самом деле не хватает отрасли?

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

1. Качественные классификаторы. Необходима замена неработающего КСИ на проверенные аналоги (например, КЦИМ, протестированный в Карелии, Свердловской области и Казани). Также требуется создать единый классификатор видов работ и конструктивных решений, который станет основой для цифровой ведомости объемов работ.
2. Единые и поэтапные требования к BIM-моделям. Вместо того чтобы сразу вводить невыполнимые и избыточно детализированные требования, нужно начать с простых, базовых правил. По мере роста цифровой зрелости отрасли их можно постепенно усложнять.
3. Машиночитаемые и непротиворечивые нормы. Нужен новый фреймворк для нормативных документов. Требования должны быть описаны в машиночитаемом формате (например, JSON) с четким синтаксисом. Это позволит автоматически проверять BIM-модели на соответствие, а также устранять дублирование и противоречия в самих правилах. Существующий «реестр требований» может стать хорошей отправной точкой для этой работы.
4. Адаптация под реальные инструменты. Полезен опыт Великобритании, где требования к BIM-моделям пишутся для конкретных программных продуктов (Revit, ArchiCAD и т. д.). Единый усредненный стандарт заставляет всех опускаться до минимально возможного уровня, урезая функциональность и не позволяя использовать сильные стороны каждого ПО.

Заключение: Два пути регулирования

Сегодня перед регулятором стоят два принципиально разных пути развития цифровой стандартизации в строительстве.

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