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