AI-агент закупівель: де ламається поточний процес постачання
Заявка на закупівлю рідко надходить в одному форматі: пошта, робочий чат, таблиця відділу, усна домовленість після наради.
Фахівець із постачання вручну зводить це в загальний реєстр, уточнює номенклатуру й досилає пропущені поля — і обробка заявок на закупівлю розтягується ще до того, як з'явиться перша пропозиція постачальника.
Далі починаються ручні звіряння постачальників. Ціни, строки відвантаження, мінімальна партія та умови оплати живуть у листуванні, а не в спільній базі: порівнювати доводиться за останнім листом, історія цін ніде не накопичується.
Та сама позиція в різних постачальників іде під різними артикулами й фасуваннями — зіставлення тримається на пам'яті конкретної людини, а не на правилах, тому за її відсутності процес зупиняється.
Окреме вузьке місце — очікування підтверджень. Узгодження йде в месенджер, губиться серед інших обговорень, ініціатор по кілька разів уточнює статус.
Поки заявка чекає, пропозиція постачальника спливає, строк постачання зсувається, і частина позицій іде в термінову закупівлю на гірших умовах.
Ціна цих ділянок — не в одній помилці, а в накопиченні: помітна частка заявок іде поза регламентом, строк від потреби до замовлення зростає, термінові закупівлі стають нормою, а економія на умовах губиться непомітно.
Вузькі місця процесу закупівель майже завжди лежать не в переговорах, а в ручній передачі даних між людьми. Розбираємо, як AI-агент закупівель закриває кожну з цих ділянок — від розбору вхідної заявки до готового замовлення.
Що змінюється після впровадження агента закупівель
Перший зсув видно на циклі заявки. Раніше збір потреби, звіряння з довідником, запит пропозицій і узгодження розтягувалися на дні, і майже кожну дію виконували руками.
AI-агент закупівель збирає дані з облікової системи та пошти, перевіряє залишки й чинні договори та віддає закупівельнику готову заявку з розрахунком — людина ухвалює рішення, а не переносить цифри.
Частка ручних операцій падає до рівня, який видно за завантаженням відділу: типові закупівлі йдуть автоматичним маршрутом, у фахівця залишаються нетипові позиції, переговори та робота з ризиками.
Час обробки заявки скорочується в рази — очікування відповіді від постачальника й внутрішні узгодження йдуть паралельно, а не по черзі.
Якість даних про постачальників перестає залежати від пам'яті співробітників: історія цін, фактичних строків і рекламацій живе в одному реєстрі.
Частка прострочень падає завдяки ранньому попередженню — агент порівнює поточний строк з історією за позицією та ескалює заявку до того, як постачання зірвано.
Частина помилок зникає не рідше, а зовсім: дублі позицій, закупівля за застарілим прайсом, загублені заявки, узгодження в обхід регламенту. Перевірка йде до відправлення, а не після.
Агент працює в контурі 1С:ERP через штатні інтерфейси, тому дані не розходяться між таблицями та обліковою системою.
Режими роботи агента: автономність і контроль людиною
Режим роботи агента — це не загальне налаштування «увімкнути автономію», а політика рівня категорії закупівлі. Для кожної категорії окремо визначається, що агент закриває сам, де він зобов'язаний зупинитися на підтвердженні людиною і які заявки йдуть у розбір винятків вручну.
Такий підхід дозволяє почати з жорстких правил і скриптів і розширювати межі автономності в міру накопичення статистики, не переписуючи інтеграцію.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та скрипти | Повторювані закупівлі фіксованої номенклатури, довгі рамкові угоди | Не працює на нових категоріях, ламається на нестандартному запиті |
| Підтвердження людиною | Перші місяці експлуатації, нові категорії, значущі замовлення | Швидкість обмежена доступністю того, хто погоджує, накопичується черга заявок |
| Автономія в межах лімітів | Усталене коло постачальників, типові обсяги, задані пороги | Потребує актуальних лімітів і моніторингу, пороги потрібно переглядати |
| Розбір винятків після дії | Високий потік типових заявок, зрілі правила та накопичена історія | Помилку видно вже після дії, потрібні журнал рішень і швидкий відкат |
Межі автономності переглядають за накопиченими даними: якщо в категорії агент довго працює без відкатів і повернень, поріг підвищують; після серії відхилень категорію повертають на підтвердження людиною.
Кожне рішення агента потрапляє до журналу з обґрунтуванням, використаними умовами та джерелом даних — тому розбір винятків займає хвилини, а не години звіряння листування.
Етапи впровадження: аудит процесу, схема, перевірка, передача
Роботу починаємо не з налаштування моделі, а з розбору процесу: хто ініціює заявку, де погоджують, на якому кроці підключається постачальник і які винятки обробляють вручну.
Без цього агент відтворює не регламент, а звички відділу — і розходження спливають уже на живих закупівлях. Нижче — порядок етапів впровадження агента з артефактом і точкою контролю на кожному кроці.
- Опис процесу закупівель як є. Інтерв'ю із закупівельниками, розбір історії заявок і договорів, фіксація розвилок і ручних обходів. На виході — схема потоку з позначкою, де рішення можна формалізувати, а де воно залишається за людиною.
- Карта правил ухвалення рішень. З опису виділяємо умови: категорія, строк, історія постачальника, відхилення ціни від звичної. Кожне правило отримує пріоритет і ознаку, за якою агент його застосовує.
- Проєктування рішень агента. Ділимо дії на три групи: виконує сам, пропонує з підтвердженням, ескалює людині. Окремо прописуємо поведінку за браку даних — заявка не «зависає», а йде на ручний розбір за індивідуальним розрахунком.
- Зв'язок з обліковою системою. Налаштовуємо обмін довідниками, заявками, статусами й документами, права агента обмежуємо потрібними операціями. Кожне рішення пишеться до журналу з підставою та посиланням на правило.
- Перевірка на історичних даних. Проганяємо агента на минулих закупівлях і звіряємо з фактичними рішеннями. Рахуємо частку збігів, розходження розбираємо: правила уточнюємо, спірні випадки залишаємо людині.
- Приймання результату та передача. Контрольні сценарії на робочому контурі, регламент винятків, навчання закупівельників і передача документації з картою правил і точками контролю.
Конфігурація агента, політики доступу та інтеграції
Агент закупівель працює не у вакуумі: він читає номенклатуру, історію закупівель і ліміти з облікової системи та діє від імені компанії. Тому разом із рішенням замовнику передається вся обв'язка — від правил вибору постачальника до порядку дій чергового інженера. Нижче перелік того, що залишається в контурі замовника і живе без нашої участі.
- Конфігурація агента — картки за класами закупівель: категорії, пороги кількості, пріоритети постачальників, правила підбору аналога, стоп-умови, за яких заявка не йде далі.
- Політики доступу та ролі — хто бачить листування, хто затверджує відхилення від умов, хто змінює ліміти. Агент працює під окремим сервісним обліковим записом із мінімально потрібними правами, а не від суперкористувача.
- Інтеграція з обліковою системою — схема обміну: які довідники читаються, як часто, за якою ознакою зіставляються позиції; поведінка за недоступності системи та порядок повторних спроб.
- Регламент ескалації — умови зупинки та передачі задачі людині: нестандартна позиція, конфлікт умов, спір щодо умов постачання, мовчання контрагента довше заданого строку.
- Шаблони повідомлень — тексти запитів, нагадувань і відмов мовою контрагента, з підстановкою змінних і правилами тональності.
- Інструкції із супроводу — де дивитися журнал рішень агента, як відтворити конкретний кейс, як відкотити зміну налаштувань і до кого йти за відхилення від очікуваної поведінки.
Комплект передаємо до вашого репозиторію під контролем версій: будь-яка зміна конфігурації проходить рев'ю, а не правиться «на місці». Опишіть задачу — повернемося з оцінкою та планом передачі.
Кейс: агент у постачанні — метрики до і після
Що було до впровадження
Постачання розбирало заявки вручну: інженер відкривав лист, звіряв позицію з номенклатурним довідником у 1С, перевіряв складські залишки, уточнював в ініціатора строки і лише потім збирав пакет на узгодження.
На рядок ішло 20–30 хвилин, а цикл узгодження заявки розтягувався до 4–7 робочих днів. За 60–80 заявок на тиждень черга накопичувалася, і частина позицій ішла в терміновий обхід регламенту — саме там виникали розходження в номенклатурі.
Що змінили і що отримали
Кейс автоматизації закупівель будувався не на заміні людей, а на знятті рутини.
Агент закупівель приймає заявку з пошти та форми, приводить позиції до довідника, підтягує залишки, історію цін і попередніх постачальників, сам запитує відсутнє в ініціатора та надсилає пакет маршрутом узгодження.
Фахівець із постачання підключається лише там, де рішення виходить за правила: нестандартна позиція, новий постачальник, перевищення ліміту.
| Метрика | До | Після |
|---|---|---|
| Заявок без ручного втручання | 0% | 74% |
| Цикл узгодження заявки | 4–7 днів | 1–2 дні |
| Розходження в номенклатурі | 12% | 1,5% |
| Час фахівця з постачання на рядок | 20–30 хв | 4–6 хв |
Клас усунених відмов — розходження номенклатури, дублі позицій і заявки, що пішли на узгодження без підтвердженого бюджету, — закривається на вході. Зняте навантаження з постачання пішло не в простій, а в роботу з постачальниками та термінові закупівлі замість розбору черги.
Чим агент відрізняється від правил і скриптів?
Правила та скрипти працюють, поки заявка надходить у розмічену форму: позиція обрана з довідника, кількість — числове поле, постачальник — зі списку.
Такий сценарій відтворюваний: однаковий вхід дає однаковий вихід, а збій повторюється на тестовому наборі й лікується правкою однієї умови.
Ламається це на вільному тексті. «Ті самі фільтри, що минулого разу, але більше і з доставкою на склад» — під таку фразу правило не написати: варіантів формулювання десятки, а в довіднику п'ять схожих позицій із різними характеристиками.
Набір умов обростає винятками, кожне нове зачіпає попередні, і частка заявок, що йдуть на ручний розбір, зростає.
Агент розбирає формулювання цілком: виділяє позиції, зіставляє їх із довідником та історією закупівель, добудовує відсутні умови — одиницю виміру, кратність упаковки, строк — і позначає впевненість за кожним рядком. За неоднозначного збігу він не вгадує, а формує уточнювальне питання заявнику та фіксує причину.
Межа проходить за ціною помилки. Ліміти, узгодження й аудит залишаються за детермінованими перевірками: агент готує дані та обґрунтування, рішення ухвалює правило. Це зберігає відтворюваний слід за кожною заявкою та знижує ручний розбір без втрати контролю.
Часті технічні питання перед стартом
Перед стартом перевіряють не те, чи вміє система читати листи, а як вона поводиться в спірних випадках. Нижче — відповіді на інженерні сумніви, які найчастіше вирішують долю проєкту.
Що відбувається, якщо агент помилиться?
Агент не пише до облікової системи напряму: він готує чернетку з обґрунтуванням і посиланням на джерело, а запис проходить підтвердження за порогом упевненості. Усе нижче порога йде людині в чергу розбору, рішення логуються — версія правил, вхідні дані, результат.
Як система обробляє нестандартні заявки?
Відхилення розпізнається за структурою: нова категорія, нетипове поєднання полів, незнайоме формулювання. Такі заявки агент не додумує, а позначає та передає відповідальному із зазначенням, чого не вистачило для рішення.
Чи потрібні зміни в обліковій системі?
На старті достатньо читання довідників та історії заявок — обробка йде в окремому контурі зі звірянням. Якщо облікова система віддає дані через штатні інтерфейси, доопрацювань майже не потрібно, а запис вмикається після паралельної роботи.
Чи є обмеження за категоріями та ролями?
Межі задає замовник: категорії, доступні контрагенти, ролі, коло тих, хто підтверджує. Категорії з неформальними умовами залишаються за людиною — агент готує довідку, але рішення не ухвалює.
Хто відповідає за рішення агента?
Правила та пороги затверджує замовник, спірні випадки завжди за людиною: агент виконує регламент, а не ухвалює рішення. Журнал показує, чому запропоновано варіант, а за підсумкову заявку відповідає співробітник, який її підтвердив.
Обговоримо задачу: з чого почнемо роботу
Перша розмова — не презентація рішення, а розбір процесу закупівель: хто ініціює заявку, де вона погоджується, на якому кроці з'являється постачальник і які винятки ламають регламент.
Потрібен весь шлях цілком, включно з ручними обходами й таблицями, які живуть поза обліковою системою — саме там агент найчастіше й дає ефект, а не в парадній частині процесу.
Підготовка до старту з боку замовника — мінімальна, але конкретна:
- вибірка закритих закупівель: заявки, отримані пропозиції, підсумкові умови — у будь-якому форматі, у якому вони є;
- довідники постачальників і номенклатури як є, без попереднього чищення: якість даних ми оцінимо самі;
- маршрути узгодження та матриця відповідальних — за категоріями, обсягами та підрозділами;
- доступи й дані для першого контуру: обліковий запис лише на читання, копія бази або тестовий стенд, канал обміну;
- обмеження щодо даних: що не можна виносити за периметр і що потрібно знеособити до старту;
- критерії приймання: метрики, які фіксуємо до початку робіт, щоб потім було з чим порівнювати результат;
- відповідальний з вашого боку, хто підтверджує логіку та приймає роботу за етапами.
З цими ввідними готуємо план робіт щодо агента: обсяг першого контуру, етапи, склад команди, залежність строків від готовності даних і точки, де потрібне ваше рішення.
Повертаємося з планом та оцінкою в обумовлений строк, із явними припущеннями — щоб далі обговорювати не очікування, а конкретні кроки.
Опишіть задачу в повідомленні: які системи задіяні, які дані доступні та що хочете отримати на виході. Зідзвонимося, уточнимо деталі та повернемося з оцінкою й планом запуску.
