Procurement Gatekeeper: как перестать принимать «мусор» на входе в закупки

Procurement Gatekeeper: MVP для автоматизации проверки заявок на закупку.

Проблема, которую видят все, но решают единицы:

«Что в закупках больше всего бесит и отнимает время?
Бесит, когда документы на закупку оформлены как попало.»
«Основная боль — неумение инициаторов планировать.
Это тянет за собой плохие ТЗ, ошибки в закупке и недовольство всех со всех сторон.»

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

• срывам сроков,
• удорожанию закупок,
• формальным рискам (монобренд, жалобы, проверки),
• перегрузке и выгоранию команд закупок.

По оценкам самих закупщиков, до 40–50% рабочего времени уходит не на работу с рынком, а на разбор, исправление и уточнение заявок от инициаторов.

Что такое Procurement Gatekeeper?

Procurement Gatekeeper — это минимально жизнеспособный продукт (MVP), который решает одну конкретную задачу:
формальную проверку заявки на закупку до запуска процедуры.
Ключевой вопрос, на который отвечает инструмент:
«С этой заявкой уже можно начинать закупку — или её нужно возвращать на доработку?»
Без попытки

• оценивать качество ТЗ,
• заменять регламенты,
• «автоматизировать всё».

Только формальный входной контроль.

Какие проблемы решает MVP?

1. «Мусор на входе»
«Когда прилетает заявка от инициатора, чаще всего не хватает ТЗ,
квалификационных требований и базовой информации по предмету закупки.»
Закупщик вынужден тратить время на выяснение очевидных вещей:

• что именно закупаем,
• в каком объёме,
• в какие сроки,
• за счёт какого бюджета.

Решение:
Автоматическая проверка наличия обязательных элементов заявки до старта закупки.

2. Монобренд и нерыночные требования.
«Основная ошибка — пишут конкретный продукт,
не предусмотрев аналоги и диапазоны.»
Такие заявки:

• ограничивают конкуренцию,
• повышают цену,
• создают формальные риски.

Решение:
Поиск явных «красных флагов»:

• упоминаний брендов без альтернатив,
• жёстких формулировок («только», «обязательно»),
• отсутствия диапазонов и допусков.

3. Потери времени на уточнения
«Закупщик не должен тратить время на выяснение:
где бюджет, какая статья, кто отвечает за оценку…»
Каждое уточнение — это:

• задержка старта закупки,
• переписка,
• раздражение с обеих сторон.

Решение:
Генерация готового текста для возврата заявки инициатору
с конкретным списком недостающих элементов.

Как работает MVP?
Технический подход
Инструмент намеренно сделан максимально простым, чтобы:

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

Технологии:

• HTML / CSS / JavaScript
• обработка данных в браузере
• правила на основе шаблонов и регулярных выражений

Чего в MVP нет:

• серверной части,
• баз данных,
• интеграций с ERP,
• сложного ИИ.

Это осознанный выбор: сначала — польза, потом масштабирование.

Логика работы
Вход: Текст заявки или ТЗ
↓
1. Предобработка текста
↓
2. Проверка обязательных элементов:
• предмет закупки
• характеристики
• количество
• сроки
• бюджет
• гарантия
• место поставки
• альтернативы
↓
3. Поиск красных флагов:
• монобренд
• жёсткие формулировки
• отсутствие диапазонов
↓
4. Расчёт процента полноты
↓
Выход: Отчёт + текст для инициатора

Состав обязательных элементов и правил может настраиваться под регламенты конкретной компании!

Что даёт такой подход?

Для закупщика:

• Экономия 10–15 минут на каждой заявке
• (20–30% времени на этапе инициации).
• Меньше переписки и ручных уточнений.
• Формальный и понятный аргумент для возврата заявки.

Для отдела закупок:

• Стандартизированный входной контроль.
• Снижение количества неполных заявок на 40–60%.
• Меньше «ручного героизма».

Для компании:

• Прозрачная статистика типовых ошибок.
• Основа для обучения инициаторов.
• Повышение качества закупок без усложнения процессов.

Ограничения текущего MVP.
Важно понимать, что инструмент не пытается заменить закупщика.
Что он делает?

• проверяет формальную полноту заявки;
• находит явные риски;
• помогает быстрее вернуть заявку на доработку;
• фиксирует типовые проблемы.

Чего он не делает?

• не оценивает качество ТЗ;
• не проверяет техническую корректность характеристик;
• не заменяет регламенты и ответственность инициаторов;
• не автоматизирует весь процесс закупок.

Почему начинать именно с MVP — правильно?
«Если на входе всегда будет полная информация,
то и закупочную документацию можно подготовить быстрее и качественнее.»
Procurement Gatekeeper — это не «большая система».
Это точечное решение самой болезненной точки процесса — входа.
Преимущества подхода:

• быстро запускается,
• не требует внедрения,
• легко адаптируется,
• ценность видна за один рабочий день.

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