автоматизация закупок в битрикс24: смарт-процесс на 6 стадий

почему закупкам нужен отдельный смарт-процесс

Закупка — это не сделка и не задача. У неё нет прямой продажи, но есть чёткий жизненный цикл с несколькими ответственными: инициатор заявки, тот, кто согласует бюджет, закупщик, который работает с поставщиками, и тот, кто принимает товар на складе. Впихивать это в задачи или в сделку — значит либо терять часть данных, либо городить костыли из дополнительных полей. Доработка сделки под чужую логику закупки почти всегда заканчивается тем, что где-то теряется история решений.

Что такое смарт-процесс и когда он вообще нужен, а когда это лишняя сущность, разбирал отдельно в статье про смарт-процессы в Битрикс24 — здесь не повторяю общую теорию, а сразу перехожу к конкретной настройке под закупки.

Главное, что даёт отдельный смарт-процесс закупок — воронка с ответственным на каждой стадии и чёткой точкой, где висит конкретная заявка прямо сейчас. Не «где-то у Марии в почте», а стадия 3 из 6, ответственный — Мария, просрочка — 2 дня.

стадия 1 — заявка от инициатора

Заявку создаёт любой сотрудник компании через простую форму: что нужно закупить, для какого отдела, ориентировочная сумма, срочность. Специально делаю форму короткой — 4-5 полей, не больше, иначе сотрудники начинают обходить процесс и писать напрямую в мессенджер закупщику, и вся автоматизация теряет смысл.

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

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

стадия 2 — согласование бюджета

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

Именно эта стадия — то самое место, где на аудитах в 6 компаниях из 10 заявка зависает на 3-5 дней: согласующий видит сообщение, устно говорит «да, нормально, делай», но нигде это не фиксирует. Формально заявка висит в статусе ожидания, закупщик не решается двигаться дальше без официального согласования, и время теряется без единого реального действия.

Решение простое технически, но требует дисциплины: согласование — это нажатие кнопки в карточке, а не устное «окей» в коридоре. Как только это правило приживается, средний срок этой стадии на моих проектах сокращается с 3-5 дней до одного.

стадия 3 — сбор коммерческих предложений у поставщиков

После согласования бюджета закупщик запрашивает предложения минимум у 2-3 поставщиков — по позициям выше определённого порога суммы это стоит закрепить как обязательное правило, а не оставлять на усмотрение закупщика.

Каждое поступившее предложение фиксируется отдельной карточкой или полем внутри той же заявки — цена, сроки поставки, условия оплаты. Смысл в том, чтобы решение о выборе принималось на основании сравнимых данных, а не по памяти «этот поставщик обычно дешевле».

Срок этой стадии стоит ограничивать явно — 3-5 рабочих дней в зависимости от специфики товара. Без ограничения закупщик может неделями «продолжать собирать предложения» по несрочной позиции, откладывая решение.

стадия 4 — выбор поставщика и согласование условий

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

Здесь же уместно повторное согласование с финансовым директором, если финальная сумма отличается от изначально одобренной больше чем на условный порог — например, на 10-15%. Без такого правила закупщик рискует превысить бюджет уже после первого согласования, и это вскрывается только постфактум.

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

стадия 5 — заказ и контроль поставки

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

Если поставка задерживается, стадия не должна просто «висеть» — правильная реакция это уведомление инициатору заявки о новом сроке, а не молчание до момента, пока человек сам не спросит «а где мой заказ».

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

стадия 6 — приёмка и закрытие

Финальная стадия — подтверждение получения товара или услуги тем, кто изначально создавал заявку, а не закупщиком. Это важное правило: закупщик не может сам себе подтвердить, что заказ выполнен корректно, потому что теряется независимая проверка качества и комплектности.

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

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

роботы и уведомления на переходах между стадиями

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

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

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

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

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