Заявки на закупку: задачи, процесс и автоматизация

Заявка на закупку — это формализованное описание потребности подразделения в товаре, работе или услуге. В ней фиксируют, что требуется, в каком количестве, к какому сроку, для какой цели и за счёт какого бюджета. После проверки и согласования заявка становится основанием для планирования или проведения закупки.

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

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

Для чего нужна заявка на закупку

Заявка создаёт единый вход в закупочный процесс. Внутренний заказчик описывает результат, а закупочная функция получает данные для выбора процедуры и планирования нагрузки. Руководители видят будущие обязательства до появления договора и счёта.

Правильно организованный процесс позволяет:

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

Заявка, заказ и план закупок: не одно и то же

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

Что включить в заявку

Форма должна собирать данные, необходимые для решения, но не перекладывать профессиональную работу закупщика на инициатора. Набор полей зависит от категории.

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

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

Маршрут заявки на закупку

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

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

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

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

Кто участвует в процессе

Инициатор отвечает за деловую потребность и исходные требования. Руководитель подтверждает приоритет. Финансовый контролёр проверяет бюджет и статью расходов. Закупщик выбирает процедуру, уточняет требования к рынку и координирует исполнение. Технический эксперт помогает с характеристиками и критериями приёмки. Юрист подключается к договорным условиям, а приёмочная роль подтверждает результат.

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

Плановые и внеплановые заявки

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

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

Категоризация и объединение потребностей

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

Однотипные заявки можно объединять, если совпадают предмет, допустимые сроки и существенные условия. Консолидация повышает объём закупки и сокращает число процедур, но не должна скрывать исходных заказчиков. Каждая позиция сохраняет связь с подразделением, бюджетом, местом поставки и ответственным за приёмку.

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

Как управлять изменениями заявки

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

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

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

Как контролировать сроки

Типичные проблемы

• Свободное описание вместо структуры. Закупщик каждый раз уточняет количество, срок и критерии.
• Одна форма для всех категорий. Для услуг, оборудования и стандартных материалов нужны разные поля.
• Согласование ради согласования. Участники не понимают, какое решение должны принять.
• Потеря связи после одобрения. Инициатор не видит закупку, договор и ожидаемую поставку.
• Срочность без основания. Почти каждая заявка получает высокий приоритет, и система перестаёт помогать.
• Отсутствие версии. Изменения требований не фиксируются и создают спор при приёмке.

Автоматизация процесса

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

Интеграция с ERP позволяет проверить номенклатуру, остатки и бюджет; связь с договорным контуром — передать утверждённые условия; со складом — получить факт приёмки. На странице Comindware Управление закупками показан сквозной процесс от сбора заявок до контроля поставок. Решение работает на базе Comindware Platform и допускает настройку форм и маршрутов под регламенты компании.

Чек-лист настройки

1. Определите границу между потребностью, заявкой, закупкой и заказом.
2. Разделите обязательные поля по категориям.
3. Назначьте владельцев решений на каждом этапе.
4. Настройте проверку дублей, бюджета и комплектности.
5. Зафиксируйте правила изменения утверждённой заявки.
6. Свяжите заявку с последующими объектами процесса.
7. Добавьте сроки, уведомления и эскалации.
8. Запустите пилот и измерьте причины возвратов.

Частые вопросы

Кто создаёт заявку на закупку?

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

Нужно ли согласовывать каждую заявку?

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

Можно ли изменить заявку после согласования?

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

Чем заявка отличается от технического задания?

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

Как объединять похожие заявки?

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

Какая аналитика нужна руководителю?

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

Похожие записи:

Итоги конференции CNews «Роботизация бизнес-процессов 2021» 3 мифа о BPM и BPMS Нотация BPMN 2.0: ключевые элементы и описание Comindware — Один из Первых Успешных Выпускников Сколково 2021