Согласования, которые длятся неделями: как маршруты в СОД ускоряют стройку в десятки раз

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

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

1. - Прораб пишет служебную записку.

2. - Начальник участка подписывает её и передаёт в ПТО.

3. - Инженер ПТО оформляет официальное письмо, регистрирует его в журнале исходящей документации.

4. - Секретарь отправляет письмо проектировщику (обычной или электронной почтой).

5. - Письмо лежит у проектировщика 2–3 дня — у него свои задачи в приоритете.

6. - Проектировщик выпускает ответ, регистрирует его у себя.

7. - Ответ приходит в ПТО, инженер прикладывает его к делу.

8. - ГИП ставит визу (если он на объекте, а не в командировке).

9. - Согласование передаётся заказчику.

10. - Технадзор проверяет, подписывает.

11. - Только теперь прораб получает разрешение работать с новым материалом.

Итог: 2–3 недели вместо 10 минут. За это время на площадке уже зальют бетон по старой версии — и потом будут разбираться, кто виноват. А если поставка аналога горит, бригада будет простаивать.

Почему согласования буксуют: анатомия проблемы

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

Ключевые «пожиратели времени» в такой системе:

1. Физическое перемещение документов. Письма ходят между бытовками, офисами и объектами. Если ГИП уехал на совещание, визу придётся ждать его возвращения.

2. Отсутствие приоритизации. Проектировщик не видит, что согласование «горит» — у него в очереди 15 таких же писем. Он отвечает в порядке общей очереди.

3. Ручное отслеживание статусов. Никто не знает точно, где сейчас документ. Приходится звонить, писать, уточнять. Каждое такое уточнение — ещё 15–30 минут потерянного времени.

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

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

📖 Читайте также: Почему 30% замечаний на стройке теряются между Excel, почтой и мессенджерами

Цена долгих согласований в цифрах

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

Исследование ГК «Экзон», проведённое на базе более 200 строительных объектов в регионах России, показало чёткую структуру потерь:

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

Переведём это в деньги. Один день простоя типового жилого комплекса площадью 30 тыс. м² обходится застройщику в 7 млн рублей в регионе и 13,5 млн рублей в Москве. Если из-за затянувшегося согласования замены материала бригада из 15 человек простаивает неделю — это от 49 до 94,5 млн рублей потерь только на одном объекте.

И это без учёта репутационных рисков, срыва сроков сдачи объекта и штрафов по госконтрактам.

📖 Читайте также: 10 проблем на стройплощадке, которые решает среда общих данных

Судебные риски: когда молчание стоит миллионы

Долгие согласования — это ещё и юридическая ловушка. Когда решение принимается неделями, на площадке часто не ждут и работают «на свой страх и риск». А потом всплывают проблемы.

Кейс из арбитражной практики (дело № А08-10714/2024, сентябрь 2025 года). Подрядчик закупил материалы строго по смете, предоставленной госзаказчиком. В процессе работ выяснилось, что указанные в проекте фланцевые подставки физически невозможно установить — существующие гидранты смонтированы иначе. Подрядчик написал письмо заказчику, но согласование замены материалов затянулось. Пришлось покупать новый материал, а старый ушёл в убыток из-за низкого спроса.

Суд взыскал с госзаказчика более 882 тысяч рублей убытков (с учётом НДС). Ключевой аргумент суда: подрядчик до начала работ не мог предвидеть невозможность использования материалов, так как проектная документация не давала об этом представления.

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

Масштабнее ситуация выглядит в отчёте Счётной палаты РФ за 2025 год. Проверка реконструкции аэропортов показала, что низкое качество проектной документации и затянутые согласования изменений привели к удорожанию госконтрактов почти на 4 миллиарда рублей:

• Грозный — на 2,8 млрд руб.

• Благовещенск — на 1,07 млрд руб.

• Магнитогорск — на 274 млн руб.

Из 65 объектов, которые планировалось завершить в отчётный период, сроки были сдвинуты по 57. Основные причины — именно низкое качество документации и проблемы с согласованием изменений.

А в Саратове бывший главный инженер муниципального предприятия получил два года колонии общего режима за принятие ошибочной проектно-сметной документации по реконструкции трамвайных маршрутов. Ошибки в расчётах привели к дополнительным затратам на 68 млн рублей, а общий ущерб от увеличения стоимости проекта превысил 3 миллиарда рублей.

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

📖 Читайте также: Один неправильный чертёж может стоить миллионы: как управлять версиями проектной документации

Как это решает СОД/CDE

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

Как работает согласование в современной СОД

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

2. Автоматическая маршрутизация. Система сама определяет, кому нужно согласовать. Запрос уходит проектировщику, ГИПу и технадзору одновременно или последовательно — в зависимости от настроек.

3. Push-уведомления. Каждый участник получает уведомление на телефон: «Новый запрос на изменение №47. Срок — 24 часа». Не нужно проверять почту или ждать письма.

4. Прозрачные статусы. Все видят, на ком сейчас находится запрос. Если участник затягивает, система автоматически напоминает ему и показывает руководителю «узкое место» процесса.

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

6. Автоматическая публикация изменений. Как только все согласования получены, новая версия документа автоматически переходит в статус «Утверждено» (Published). Прораб сразу видит актуальную версию на планшете — без звонков и ожиданий.

7. Цифровой след (Audit Trail). Каждое действие фиксируется: кто создал, кто согласовал, кто отклонил, с какими комментариями, в какое время. Это готовая доказательная база для суда.

📖 Читайте также: Четыре контейнера порядка: как зоны WIP, Shared, Published и Archive спасают проекты от хаоса

Живой пример: 18 часов против 35 минут

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

Сценарий 1: Без СОД (классический процесс)

15:00 — прораб заметил проблему на площадке.
16:00 — дошёл до бытовки, записал в журнал.
16:10 — позвонил ГИПу, тот попросил прислать фото.
16:15 — прораб сфотографировал, отправил в WhatsApp.
16:20 — ГИП переслал проектировщику.
19:00 — проектировщик ответил вечером (предложение сдвинуть шахту на 40 см).
09:00 следующего дня — прораб узнал ответ на утренней планёрке.

Итого: 18 часов. Из них 14 часов — ночное время, когда работа на площадке стояла.

Сценарий 2: С мобильной СОД (например, Pocket)

15:00 — прораб создал замечание в приложении, прикрепил фото, указал координаты на чертеже.
15:02 — проектировщик и ГИП получили push-уведомления.
15:15 — проектировщик открыл чертёж в приложении, выпустил новую версию с пометкой «сдвинуть шахту на 40 см».
15:20 — ГИП согласовал изменение.
15:25 — новая версия автоматически перешла в статус Published.
15:30 — прораб получил уведомление, открыл обновлённый чертёж, продолжил работу.

Итого: 30 минут. Без простоев, без звонков, без ожидания утра.

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

📖 Читайте также: Стройка переехала в смартфон: почему мобильный доступ к проектам стал необходимостью

Что делать компаниям

Если вы узнали свою компанию в описании «эстафеты» с бумажными письмами, вот пошаговый план изменений:

Шаг 1. Оцифруйте типовой маршрут согласования

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

Шаг 2. Внедрите мобильную СОД с поддержкой маршрутов

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

• Мобильный интерфейс. Согласование должно занимать 30 секунд на смартфоне, а не 10 минут за компьютером.

• Push-уведомления. Участники должны узнавать о новых задачах мгновенно.

• Прозрачные статусы. Каждый видит, на ком сейчас «завис» документ.

• Автоматические напоминания. Система сама «пинает» тех, кто затягивает.

• Офлайн-режим. Согласование должно работать даже при плохом интернете на площадке.

Шаг 3. Закрепите регламент

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

Шаг 4. Замерьте результат

Через месяц после внедрения соберите метрики:

• Среднее время согласования запроса.

• Количество «зависших» запросов (без ответа более N дней).

• Количество простоев из-за ожидания согласований.

Сравните с «до». Обычно разница впечатляет: время согласования сокращается в 10–30 раз.

Сравнительная таблица: согласования «до» и «после» СОД

Согласования — это не бюрократия, а управление рисками

Многие руководители воспринимают долгие согласования как неизбежное зло: «Так исторически сложилось, так все работают». Но на самом деле это не традиция, а системная ошибка процесса, которая стоит компании миллионов рублей.

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

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

Это не «очередная программа». Это способ перестать терять деньги на бюрократии и сфокусироваться на том, что действительно важно — на строительстве.

Запросить демо и настроить маршруты согласования под ваш объект →