В закупках многое решается ещё до первого звонка поставщику.

Если в заявке не хватает исполнения, размеров или требований к замене, можно быстро собрать три предложения. Только окажется, что сравниваем три разных изделия. Таблица заполнена, а решение по-прежнему принять нельзя.

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

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

Для меня полезный результат начинается с правильно разобранной потребности. Что именно требуется? В каком количестве? К какому сроку? Допускается ли аналог? Что в исходных данных пока неизвестно?

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

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

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

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

Коллеги, где у вас обычно возникает больше переделок: в исходной заявке или уже при сравнении предложений?