Единый строительный Портал

Ниже — разбор по пунктам и адаптация нашей системы «Единый строительный портал» под новое стратегическое направление Правительства РФ от 2 марта 2026 г. № 398-р. Документ прямо задает рамку до 2030 года для цифровой трансформации строительства и ЖКХ, с упором на единый цифровой контур, машиночитаемые данные, ТИМ/BIM, интеграции, клиентоцентричные сервисы и ИИ. 

Что именно меняется на уровне государственной логики

По документу государство уходит от набора разрозненных ИС к единой цифровой среде в строительстве и ЖКХ. Ключевые акценты такие:

• Все процедуры должны уходить в электронный вид — не только подача документов, но и весь жизненный цикл объекта.
• Машиночитаемость становится обязательной архитектурой, а не “опцией”: XML-шаблоны, реестры, цифровые паспорта, единые форматы обмена.
• ТИМ/BIM и цифровой двойник — это уже не просто инновация, а целевая модель отрасли.
• Интеграция федерального и регионального контуров — через ГИСОГД, “Стройкомплекс.РФ”, пространственные данные, надзор, экспертизу, Госуслуги, ГИС ЖКХ.
• ИИ разрешен и поощряется в экспертизе, аналитике, мониторинге, прогнозировании и сервисах.
• Импортозамещение — не пожелание, а базовый принцип цифровой трансформации.
• Клиентоцентричность — портал должен быть не “архивом документов”, а рабочей средой для граждан, бизнеса и органов власти.  

Что это означает конкретно для нашего портала

Если говорить прямо:

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

Она должна стать операционной платформой жизненного цикла строительства и эксплуатации, где есть:

• единый объектный реестр;
• единый документооборот;
• единые цифровые процессы;
• API-интеграции;
• слой пространственных данных;
• машиночитаемые шаблоны;
• события, статусы, контроль, аналитика;
• подготовка данных для ИИ.

То есть портал надо перестроить из модели:

“услуги + файлы + статусы”

в модель:

“объект + участники + процессы + данные + интеграции + аналитика + сервисы”.

Разбор документа по смысловым блокам и как адаптировать систему

Единая цифровая среда управления отраслью

Документ требует создания единой цифровой среды управления строительством и ЖКХ, а также интеграции региональных систем с федеральными. Отдельно названы ГИСОГД субъектов, “Стройкомплекс.РФ”, система управления проектами госзаказчиков, ЕГРЗ экспертизы и связанные платформы. 

Что делать в портале:

• сделать единый реестр объектов капитального строительства;
• сделать единый реестр участников: застройщик, техзаказчик, проектировщик, подрядчик, эксперт, инспектор, УК, РСО;
• сделать единый реестр процессов: разрешения, экспертиза, строительство, надзор, ввод, эксплуатация;
• перейти на сквозной идентификатор объекта во всех модулях;
• завести единый event log по объекту: кто, что, когда изменил, какой статус, какой документ породил.

Итог: объект становится ядром системы, а не заявление.

Полный перевод процедур в электронный вид

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

Что делать в портале:

• убрать “псевдо-цифру”, где пользователь скачал PDF, распечатал, подписал, загрузил обратно;
• внедрить нативные цифровые формы с маршрутизацией;
• поддержать:
• структурированные заявления;
• машиночитаемые приложения;
• проверки до отправки;
• версионность;
• юридически значимое подписание;
• статусную модель по регламенту.

Минимум обязательных сущностей:

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

Машиночитаемые форматы и XML

Документ несколько раз делает упор на XML-схемы документов, машиночитаемые шаблоны, перевод документации и данных в структурированный формат. 

Это критически важно.

Если у вас сейчас 80% данных — это PDF/скан/Word, система формально работает, но стратегически уже устарела.

Что делать:

• ввести двухконтурную модель документа:
• визуальная форма;
• структурированный слой данных.
• сделать реестр шаблонов XML/JSON-схем;
• все новые процессы проектировать по принципу:
• сначала структура данных;
• потом экран;
• потом печатная форма.

Какие документы переводить первыми:

• градплан / исходно-разрешительная документация;
• задания и исходные данные;
• исполнительная документация;
• акты;
• заключения;
• карточки стройконтроля;
• документы ввода;
• документы ЖКХ по авариям, начислениям, техсостоянию.

ТИМ/BIM как сквозная технология

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

Что это означает для портала:

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

Нужны модули:

• карточка BIM/ТИМ-модели;
• хранение ссылок на модели и их версии;
• связь модели с этапами;
• связь модели с замечаниями, коллизиями, предписаниями;
• визуализация статусов по элементам модели;
• сопоставление модели, сметы, графика, актов и фотофиксации.

Практически:

• хотя бы начать с BIM-light:
• реестр моделей;
• viewer;
• метаданные модели;
• проверки комплектности;
• связь модели с экспертизой и надзором.
• следующий шаг — 4D/5D интеграция:
  
• сроки;
• объемы;
• стоимость;
• факт/план.

Непрерывный мониторинг хода реализации проектов

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

Что делать в портале:

• внедрить панель мониторинга стройки:
• этап;
• статус;
• риски;
• отклонения сроков;
• фотофиксация;
• предписания;
• оплата/контрактация;
• исполнительная документация;
• готовность по видам работ.
• сделать дашборд для руководителя:
  
• просрочки;
• объекты с критическим риском;
• объекты без обновлений;
• расхождение план/факт;
• “красные” контракты;
• объекты без валидной модели/документации.

Архитектурно: нужен не просто кабинет, а управленческий слой BI + событийный слой.

Клиентоцентричный суперсервис

Документ прямо говорит о развитии суперсервиса “Цифровое строительство” и поддержке даже неквалифицированных участников, в том числе физлиц в ИЖС. 

Следовательно, портал должен иметь 3 разные UX-модели:

• гражданин;
• бизнес/профучастник;
• орган власти / контроль / оператор.

Что нужно добавить:

• жизненные ситуации вместо ведомственных разделов:
• построить дом;
• получить разрешение;
• внести изменения;
• пройти экспертизу;
• ввести объект;
• передать объект в эксплуатацию;
• подать обращение по ЖКХ;
• провести ОСС;
• оплатить услуги;
• подать взыскание задолженности.
• умный мастер подачи:
  
• задает вопросы;
• определяет маршрут;
• собирает комплект;
• предупреждает о рисках и пробелах.

Это особенно важно: документ явно двигает систему от “знаешь регламент — подашь” к “система сама ведет пользователя”.

Пространственные данные и карта

В документе зафиксирована интеграция со “Стройкомплекс.РФ” и с единой цифровой платформой пространственных данных. 

Без сильного GIS-слоя портал будет неполным.

Что нужно:

• карта объектов;
• слои:
• земельные участки;
• ОКС;
• зоны;
• инженерка;
• ограничения;
• этапы строительства;
• аварии/инциденты;
• планы развития;
• схемы теплоснабжения/водоснабжения.
• пространственный поиск;
• отображение коллизий территориального планирования;
• привязка документов и статусов к геометрии.

Минимум:

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

ЖКХ: ГИС ЖКХ, Госуслуги, ОСС, задолженность, техсостояние

Во второй части документ очень явно формулирует целевую модель для ЖКХ:

• ОСС в электронном/очно-заочном формате с ГИС ЖКХ;
• начисления и платежки доступны через Госуслуги;
• подача на взыскание задолженности — в электронном виде;
• цифровой учет жилищного фонда и техсостояния;
• цифровые паспорта коммунальной инфраструктуры;
• развитие “умного дома”.  

Для нашего портала это значит:

если мы хотим быть единым порталом, у нас должен быть не только стройблок, но и эксплуатационный ЖКХ-контур.

Нужны модули:

• паспорт МКД / жилого дома;
• техсостояние;
• капремонт;
• инциденты и аварии;
• взаимодействие с УК/РСО;
• начисления и уведомления;
• обращения жителей;
• ОСС;
• задолженность и претензионный блок;
• коммунальная инфраструктура и электронный паспорт объекта.

Ключевая мысль:

строительство и ЖКХ в документе уже рассматриваются как единая цифровая цепочка, а не две независимые отрасли.

Искусственный интеллект

Документ прямо предусматривает внедрение ИИ:

• для оценки застройщика;
• анализа отчетности;
• предиктивной аналитики срыва сроков;
• анализа фото стройки;
• поддержки экспертизы;
• обработки обезличенных данных;
• развития отраслевых сервисов.  

Как адаптировать систему правильно: не надо начинать с “чат-бота ради галочки”. Надо строить прикладной ИИ над качественными данными.

Приоритетные ИИ-сценарии для портала:

• предиктивный риск срыва сроков;
• проверка комплектности документов;
• поиск противоречий и коллизий в данных;
• интеллектуальная маршрутизация заявлений;
• анализ фотофиксации хода работ;
• подсказки инспектору/эксперту;
• поиск аномалий по начислениям/авариям/обращениям ЖКХ;
• умный поиск по нормативке и документам;
• NLP-разбор входящих обращений и автоматическая категоризация.

Но сначала база:

• единые справочники;
• чистые данные;
• структурированные события;
• хранилище обезличенных датасетов;
• MDM/НСИ.

Импортозамещение и технологическая независимость

Документ прямо говорит, что использование российского ПО и программно-аппаратных средств — главный приоритет. Что это значит для системы:

• провести аудит:
• ОС;
• БД;
• брокеры;
• GIS-стек;
• BIM-viewer;
• ECM/ЭДО;
• CI/CD;
• мониторинг;
• криптография;
• офисные конвертеры;
• шины интеграции.
• сформировать матрицу:
• критично зависит от иностранного ПО;
• можно заместить быстро;
• можно оставить временно в изолированном контуре;
• требует перепроектирования.

На уровне архитектуры:

портал должен быть vendor-resilient, иначе через 1–2 года любая интеграция упрется в несовместимость или регуляторные ограничения.

Какой должна стать целевая архитектура портала

Рекомендую целевую модель из 8 слоев.

Слой 1. Единое объектное ядро

• ОКС
• земельный участок
• МКД / жилфонд
• объект коммунальной инфраструктуры
• участники
• документы
• события
• статусы
• геоданные

Слой 2. Процессный движок

• BPM / workflow
• маршруты согласования
• SLA
• регламентные сроки
• эскалации
• проверки комплектности

Слой 3. Документы и машиночитаемость

• шаблоны XML/JSON
• версионность
• электронные формы
• печатные формы
• ЭП
• архив юридически значимых действий

Слой 4. Интеграционный слой

• API gateway
• ESB / event bus
• интеграции с внешними ГИС/реестрами
• витрины данных
• подписка на события

Слой 5. Пространственный слой

• карта
• геообъекты
• пространственные запросы
• тематические слои
• связка карты с процессами

Слой 6. BIM/ТИМ слой

• модели
• viewer
• версии
• элементы
• связь с актами, предписаниями, экспертизой

Слой 7. Аналитика и ИИ

• KPI
• мониторинг
• прогнозы
• риск-скоринг
• предписания на основе аномалий

Слой 8. UX-слой ролей

• гражданин
• застройщик
• проектировщик
• подрядчик
• инспектор
• эксперт
• орган власти
• УК / РСО / оператор ЖКХ

Какие модули надо добавить или переделать в первую очередь

Блок А. Строительство

• Реестр объектов и участников
• Личный кабинет профучастника
• Цифровые заявления и маршруты
• Исполнительная документация в структурированном формате
• BIM/ТИМ-модуль
• Мониторинг стройки
• Интеграция с экспертизой и надзором
• Суперсервис для ИЖС и массовых услуг

Блок Б. ЖКХ

• Паспорт МКД / жилфонда
• Цифровой паспорт коммунальной инфраструктуры
• Инциденты / аварии / диспетчеризация
• ОСС
• Начисления / уведомления / платежный контур
• Долговой контур и электронное взыскание
• Кабинеты УК/РСО/муниципалитета
• Модуль “умный дом / IoT-ready”

Блок В. Сквозные компоненты

• НСИ и классификаторы
• API и интеграционная шина
• Геоплатформа
• Хранилище событий
• BI и KPI
• ИИ-сервисы
• Аудит, безопасность, ЭП, журнал действий

KPI, на которые надо ориентировать систему

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

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

Для внутренней модели управления порталом я бы добавил:

• доля услуг end-to-end без бумаги;
• доля структурированных документов;
• доля объектов со сквозным ID;
• доля объектов с геопривязкой;
• доля объектов с BIM/ТИМ;
• средний срок прохождения маршрута;
• число возвратов из-за некомплектности;
• точность предиктивной модели по срокам;
• доля интеграций, работающих через API без ручного обмена.

Главные разрывы, которые почти наверняка есть сейчас

С высокой вероятностью у большинства таких систем есть 7 типовых проблем:

• система построена вокруг заявлений, а не вокруг объекта;
• данные живут в документах, а не в сущностях;
• интеграции точечные и хрупкие;
• нет единой карты и объектной связности;
• BIM/ТИМ либо отсутствует, либо декоративен;
• ЖКХ-контур не связан со стройконтуром;
• нет нормального data layer для ИИ и мониторинга.

Если это так, то дорабатывать интерфейс бессмысленно, пока не переделан фундамент.

Практическая адаптация: план по этапам

Этап 1. 0–3 месяца

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

Этап 2. 3–6 месяцев

• запустить реестр объектов и участников;
• перевести ключевые услуги на нативные цифровые формы;
• внедрить событийную модель;
• развернуть API gateway;
• сделать базовый GIS-слой;
• внедрить панель мониторинга руководителя.

Этап 3. 6–12 месяцев

• подключить BIM/ТИМ-модуль;
• внедрить цифровую исполнительную документацию;
• запустить модуль ОСС и ЖКХ-паспорта;
• сделать цифровой контур аварий/инцидентов;
• включить риск-скоринг и умные проверки комплектности.

Этап 4. 12–18 месяцев

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

Моя прямая рекомендация по нашей системе

Если адаптировать коротко и без бюрократии, то нам надо сделать 5 стратегических разворотов:

1. Из портала услуг — в платформу жизненного цикла объекта.

2. Из файлового архива — в систему структурированных данных.

3. Из набора кабинетов — в единый цифровой контур участников.

4. Из ручного контроля — в мониторинг и предиктивную аналитику.

5. Из “цифровизации витрины” — в цифровизацию ядра процессов.

Итог

Распоряжение не просто обновляет цели. Оно фактически фиксирует новый стандарт отраслевой ИТ-системы:

• единая среда;
• машиночитаемые данные;
• ТИМ/BIM;
• интеграции;
• пространственный слой;
• цифровой ЖКХ-контур;
• ИИ;
• импортозамещение;
• клиентоцентричность.  

Для Единого строительного портала это означает одно:

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