Прораб пишет в WhatsApp: «Нужен кабель 3×2,5 — срочно». Снабженец отвечает «ок». Через три дня на объекте нет кабеля, а в чате уже 200 сообщений про другие позиции. Никто не помнит, кто что заказал, в каком количестве и на какой объект.
Заявка на материалы — начало всей цепочки снабжения. Если она теряется или оформлена «на словах», дальше ломаются закупка, согласование и приёмка. В этой статье — как устроить заявки так, чтобы их было видно, понятно и невозможно «забыть в чате».
Заявка на материалы — начало всей цепочки снабжения. Если она теряется или оформлена «на словах», дальше ломаются закупка, согласование и приёмка. В этой статье — как устроить заявки так, чтобы их было видно, понятно и невозможно «забыть в чате».
Почему заявки теряются
На стройке заявки часто идут не через один канал, а через всё сразу:
Проблема не в том, что люди «плохие». Проблема в том, что канал общения ≠ система учёта. Чат удобен для уточнений. Он не умеет держать реестр заявок, лимиты бюджета и статус «заказано / в пути / на объекте».
Когда заявок десятки в неделю и объектов несколько, без единого реестра снабжение работает в режиме тушения пожаров.
Когда заявок десятки в неделю и объектов несколько, без единого реестра снабжение работает в режиме тушения пожаров.
Что должна содержать заявка на материалы
Минимум, без которого снабженец не может нормально закупить:
Хорошая заявка отвечает на вопрос снабженца: что, сколько, куда, к какому сроку и из какого плана.
Если позиции выбирают из ресурсной ведомости, а не «из головы», сразу видно лимиты и меньше дублей («уже заказали на соседнюю секцию»).
Если позиции выбирают из ресурсной ведомости, а не «из головы», сразу видно лимиты и меньше дублей («уже заказали на соседнюю секцию»).
Как выглядит рабочий процесс заявки
Прораб на объекте
- Открывает мобильное приложение (или веб — если так принято).
- Выбирает позиции из ресурсной ведомости / бюджета проекта.
- Указывает количество, срок, при необходимости — фото или чертёж.
- Отправляет на согласование или сразу в снабжение (по регламенту компании).
- Дальше видит статус по каждой позиции: принято, в работе, заказано, в пути, на объекте — без звонков «ну как там?».
Снабженец (ОМТС)
- Работает с единым реестром заявок, а не с лентой чатов.
- Берёт заявку в работу, запрашивает КП, сравнивает предложения.
- Ведёт счёт и согласование в той же системе.
- Прораб и руководитель видят прогресс без ручных сводок.
Руководитель проекта / снабжения
- Видит очередь, просрочки и заявки без движения.
- Может согласовывать крупные позиции до закупки.
- Понимает обеспеченность: что ещё не заказано, что уже едет.
Связка с концом цепочки: когда материал привезли, приёмка УПД закрывает позиции заявки — цикл замыкается.
Реестр заявок: зачем он нужен
Реестр — это не «красивая таблица». Это операционный инструмент:
- Очередь — что в работе, что ждёт, что просрочено
- Фильтры — по объекту, статусу, снабженцу, дате
- История — кто создал, кто менял, какие комментарии
- Связь с документами — КП, счета, оплаты, поставки
- Прозрачность для объекта — прораб не «стучит в дверь», а смотрит статус
Без реестра компания платит временем: снабженец ищет заявку в чатах, прораб дублирует заказ, руководитель узнаёт о проблеме, когда бригада уже стоит.
В кейсах внедрения строительные компании прямо фиксируют задачу: заявки не теряются, маршрут закупки понятен, материалы приезжают вовремя — см. кейсы на pusk.app/cases.
Типичные ошибки при заявках на материалы
«Срочно в чат — так быстрее»
Быстрее в момент отправки. Медленнее через день, когда никто не помнит контекст. Срочные заявки тоже должны попадать в реестр — со статусом приоритета.
«Заказываем не из плана»
Позиции «на память» дают дубли, пересорт и выход за бюджет. План (ресурсная ведомость) — источник правды для номенклатуры.
«Одна заявка на всё подряд»
Смешивать срочное и плановое в одном списке без приоритетов — снабжение не понимает, с чего начать.
«Нет статуса — значит, позвоним»
Звонки масштабируются плохо. Статус в системе снимает 80% уточняющих звонков.
«Закрыли заявку, когда оплатили счёт»
Оплата ≠ поставка. Статусы должны различать: заказано, оплачено, в пути, принято на объекте.
«Подрядчик пишет снабженцу напрямую»
Если подрядчикам нужен заказ материалов — лучше ограниченный доступ к проекту, чем ещё один канал в обход реестра.
Чек-лист: заявки у вас под контролем
Поставьте «да», если процесс устойчив:
- Есть единый канал/система для заявок (не только мессенджер)
- У каждой заявки есть объект, номенклатура, количество, срок, автор
- Позиции по возможности берутся из ресурсной ведомости
- Есть реестр со статусами по позициям
- Прораб видит статус без звонка в снабжение
- Срочные заявки помечены, но тоже в учёте
- Заявка связана со счетами и поставками
- После приёмки позиции закрываются фактом, а не «на словах»
Если больше трёх пунктов «нет» — потери уже идут в дублях, простоях и нервах команды. Про то, как это связано с уходом от таблиц: система снабжения вместо Excel.
Что даёт ПУСК.Снабжение для заявок
ПУСК.Снабжение — облачная система для закупок и снабжения на строительных объектах. Заявки — первая точка входа в процесс:
- Заявки с объекта — прораб создаёт заявку в мобильном приложении (iOS/Android) из ресурсной ведомости
- Фото и чертежи — прямо в карточке заявки, без отдельной переписки
- Единый реестр — снабжение видит все заявки по проектам и статусам
- Контроль лимитов — видно, если закупка уходит выше заложенного
- Согласования и чат — обсуждение в карточке, не в разрозненных чатах
- Связь до приёмки — от заявки к счёту и поставке; приёмка по фото УПД закрывает цикл
- Отчёт по обеспечению — на объекте / в пути / не заказано
Внедрение: 1–7 дней. Пробный период: 14 дней.
Функции: pusk.app/product · Кейсы: pusk.app/cases · Калькулятор окупаемости: pusk.app/efficiency_calculator
Итог
Заявка на материалы на стройке работает, когда она не «сообщение в чате», а документ с объектом, номенклатурой, количеством, сроком и статусом в едином реестре. Прораб видит, что происходит с заказом; снабжение не ищет заявки по переписке; руководитель понимает обеспеченность объекта.
Если заявки оформляют из плана, ведут в одном месте и доводят до приёмки — цепочка снабжения перестаёт зависеть от памяти и удачи.
