Учёт объектов в монтажной компании: этапы, сроки, отчёты заказчику

Учёт объектов в монтажной организации почти всегда устроен одинаково: таблица в Excel у руководителя, чат по каждому объекту, папка с договорами на диске и прораб, который держит реальную картину в голове. Пока объектов пять — это работает. На пятнадцати объектах руководитель половину дня собирает статусы обзвоном, заказчики дёргают «что там у нас», а просрочка этапа вскрывается, когда сдвигать уже нечего. Разберём, как устроен типовой учёт, где на нём теряются деньги и как выглядит рабочая альтернатива — без обещаний волшебных процентов, только механика.

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

Как обычно устроен учёт объектов: Excel, чаты и память прораба

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

**Таблица объектов.** Одна строка — один объект: адрес, заказчик, сумма договора, условный статус вроде «в работе» или «сдача». Таблицу ведёт руководитель или офис-менеджер, обновляется она по вторникам или когда вспомнили. Что происходит внутри статуса «в работе» — из таблицы не видно.

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

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

Отдельно живут документы: договор в одной папке, смета в почте, допсоглашение у юриста, акты «где-то были». Когда заказчик просит сверку по закрытым этапам, её собирают день-два.

<Callout>

Главный признак, что учёт объектов перестал справляться: чтобы ответить на вопрос «в каком состоянии объект X», нужно позвонить человеку. Система учёта, требующая обзвона, — это не система, это телефонная книга.

</Callout>

Где монтажная компания теряет деньги: этапы без ответственных и просрочки

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

**Этап без ответственного и срока.** Объект «в работе», но кто именно должен закрыть текущий этап и к какой дате — нигде не зафиксировано. Закупка ждёт спецификацию от проектировщика, проектировщик считает, что уже всё отправил, объект стоит неделю. Никто не виноват, потому что ответственность не была назначена — она подразумевалась.

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

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

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

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

<Callout>

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

</Callout>

Почему коробочные CRM не ложатся на объектный процесс монтажа

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

CRM спроектирована вокруг сделки: лид пришёл, менеджер провёл переговоры, выставил счёт, получил оплату, сделка закрыта. Воронка линейна и коротка. Объект в монтаже устроен иначе:

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

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

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

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

Внутренняя админка под объекты: статусы, этапы, документы, уведомления

Рабочая альтернатива — [внутренняя админка](/services/custom-saas), спроектированная под процесс конкретной компании. Не «платформа всего», а компактная система из нескольких сущностей.

**Объект.** Карточка с адресом, заказчиком, договором, суммой, ответственным руководителем проекта. Всё, что относится к объекту, — этапы, документы, история, блокировки — живёт внутри карточки, а не в пяти местах.

**Этапы с маршрутом.** У каждого объекта — свой набор этапов по типовому маршруту компании: обследование, проект, закупка, доставка, монтаж, пусконаладка, сдача, гарантия. У этапа есть ответственный, плановая и фактическая даты, статус. Этап закрывается не словом «готово», а фактом: фото с объекта, подписанным актом, отметкой приёмки. Если у компании несколько типов объектов с разными маршрутами — шаблонов этапов делается несколько.

**Документы, привязанные к этапам.** Договор и смета — на объекте, акт — на этапе, допсоглашение — на допработах. Вопрос «где акт по второму этапу» перестаёт существовать: он там, где этап. Отдельным статусом видно, какие документы не подписаны, — это и есть контроль дебиторки на уровне бумаг.

**Блокировки.** Если этап стоит по вине заказчика, прораб фиксирует блокировку: дата, причина, что нужно от заказчика. С этого момента у компании есть история простоя с датами — аргумент в разговоре о сроках, а не «мы вам звонили».

**Уведомления.** Система сама сообщает ответственному, что до плановой даты этапа осталось три дня, а руководителю — что этап просрочен или объект стоит в блокировке дольше недели. Это ключевая разница с таблицей: таблица молчит, пока в неё не посмотрят.

**Мобильный сценарий для прораба.** Отдельно важно, чтобы прораб мог закрыть этап и прикрепить фото с телефона за минуту. Если внесение данных неудобно человеку на объекте, система умрёт — независимо от того, насколько она хороша для офиса. На задаче [учёта для швейного производства](/blog/where-sewing-production-loses-money) с объёмом около 100 тысяч изделий в месяц главным требованием оказался не функционал, а то, чтобы работник цеха фиксировал операцию в одно действие. В монтаже логика та же, только вместо цеха — объект.

Отчёты заказчику и руководителю: что собирается автоматически

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

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

**Сводка руководителю.** Все объекты на одном экране: этап, отставание от плана, блокировки, неподписанные акты. Утренний обзвон прорабов заменяется взглядом на [дашборд](/services/analytics-bi). Отдельно полезны два среза: объекты с просрочкой больше N дней и деньги, которые ждут только подписания документов.

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

И четвёртый — гарантийный период. После сдачи объект не исчезает: по нему идут заявки и выезды, и если они живут в той же системе, компания видит, сколько ресурса съедают уже сданные объекты. Это отдельный аргумент при ценообразовании следующих договоров. По устройству гарантийные обращения — тот же процесс, что [учёт заявок в сервисной компании](/blog/uchet-zayavok-servisnoy-kompanii): этапы, ответственные, нормативные сроки.

Важная оговорка: отчёты не появляются из воздуха. Они настолько же честны, насколько дисциплинированно закрываются этапы. Поэтому проектировать систему нужно от удобства внесения данных, а не от красоты итогового PDF. Похожая логика сработала на задаче [анализа тендеров для производства](/blog/avtomatizaciya-analiza-tenderov-dlya-proizvodstvennyh-kompanij): ценность дала не витрина с графиками, а то, что данные попадали в систему без дополнительной ручной работы людей.

Как внедрять: от описания процесса до первого контура за 2–8 недель

Ошибка номер один — начинать с выбора технологии или с ТЗ на «систему учёта всего». Рабочая последовательность другая.

**Шаг 1. Описать процесс как он есть.** Пройти путь одного объекта от заявки до гарантии и зафиксировать: какие этапы реально существуют, кто за них отвечает, какие документы возникают, где чаще всего застревает. На этом шаге обычно выясняется, что маршрут в головах у трёх руководителей — три разных маршрута. Уже само это выравнивание приносит пользу до всякой автоматизации.

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

**Шаг 3. Собрать первый контур и запустить на живых объектах.** Реалистичный срок — 2–8 недель в зависимости от сложности: карточки объектов, этапы с ответственными и сроками, документы, базовые уведомления и одна сводка руководителю. Запускать лучше на двух-трёх текущих объектах, собрать возражения прорабов и офиса, поправить неудобное — и только потом переводить все объекты.

**Шаг 4. Наращивать по факту использования.** Отчёты заказчику, блокировки, интеграция с 1С или телефонией, аналитика по маржинальности объектов — всё это добавляется этапами, когда базовый контур прижился. Здесь же появляются ИИ-сценарии: на одном из проектов я собирал [агента квалификации входящих чатов](/blog/ii-agent-kvalifikacii-zayavok) для отдела продаж на amoCRM и телефонии UIS — в монтажной компании похожий агент может первично разбирать входящие заявки на объекты. Но это надстройка над работающим учётом, а не замена ему.

По деньгам ориентиры такие: диагностика с описанием процесса и проектом первого контура — от 50 000 ₽, и она зачитывается в стоимость проекта; первый рабочий контур — от 150 000 ₽. Скажу честно: завершённых монтажных кейсов с измеренными «до и после» у меня пока нет, поэтому я не обещаю проценты экономии — я показываю механику, собранную на задачах из практики в производстве и продажах, и переношу её на объектный процесс.

С чего начать

Если узнали свою компанию в описании таблиц и чатов — опишите процесс тремя строками: сколько объектов ведёте одновременно, где сейчас живёт учёт и какой участок болит сильнее всего (сроки, документы, отчёты заказчику). Я посмотрю вводные и скажу, с какого контура есть смысл начинать и сколько это займёт — без обязательств и презентации на час. Напишите на [MrBoroAI@yandex.ru](mailto:MrBoroAI@yandex.ru) или [оставьте три строки в брифе](/brief?utm=blog_uchet_obektov_montazhnoy_kompanii).

<CTA/>