ШІ-агент для закупівель: як підготувати заявку та узгодити її без ручного листування

Заявка на закупівлю рідко надходить у готовому вигляді. Виробництву потрібна деталь, відділу продажів — доступ до сервісу, офісу — обладнання, але в повідомленні немає артикулу, бюджету, терміну чи причини терміновості. Закупник надсилає запитання, керівник шукає контекст, а узгодження розпадається між електронною поштою, месенджером та ERP-системою.

ШІ-агент тут корисний не як самостійний покупець. Він збирає дозволені дані, ставить питання, на які ще немає відповідей, перевіряє заявку на відповідність правилам компанії та готує зрозумілий пакет документів для прийняття рішення людиною. Договір, вибір постачальника, замовлення та оплата залишаються під контролем відповідальних співробітників.

Розберемо, які етапи процесу закупівлі дійсно можна доручити агенту, в яких випадках йому потрібні ERP-системи та корпоративні документи, і чому останнє рішення має залишатися за людиною.

Де закупівля втрачає час

Проблема часто виникає ще до того, як справа доходить до відділу закупівель. Співробітник знає, що йому потрібен насос, ноутбук або передплата, але не знає внутрішнього коду позиції, залишку на складі, чинного договору та ліміту свого підрозділу. Він описує потребу звичайними словами, а далі кілька людей вручну перетворюють цей опис на коректну заявку.

Частина інформації вже є в системах компанії: характеристики обладнання — в ERP, залишки — у складському обліку, постачальники — у довіднику, правила узгодження — у регламенті, а бюджет — у фінансовому контурі. Але ці відомості знаходяться в різних місцях і доступні різним ролям.

Через це фахівець із закупівель займається не вибором умов, а збором вихідних даних. Керівнику на узгодження надходить або занадто коротка заявка без обґрунтування, або довге листування, з якого важко зрозуміти, що саме потрібно підтвердити.

Що отримує ШІ-агент

Агенту не потрібен необмежений доступ до всієї компанії. Йому надають лише ті джерела та дії, які необхідні для виконання конкретної ролі. Наприклад, він може переглядати заявки свого підрозділу, знаходити позиції в довіднику, перевіряти доступний залишок та переглядати затверджені правила закупівель.

• ERP або облікова система: номенклатура, залишки, діючі замовлення та статуси.
• CRM або сервісна система: пов’язане замовлення клієнта, проєкт або звернення, якщо закупівля виникла на його підставі.
• Корпоративні документи: регламент, ліміти, перелік обов’язкових полів та правила вибору маршруту узгодження.
• Довідник контрагентів: лише дозволена інформація про затверджених постачальників та умови роботи.
• Електронна пошта, форма або Telegram: зручний інтерфейс для уточнень та повідомлень, але не окрема система обліку.

Якщо співробітник не має права переглядати ціни іншого підрозділу або умови закритого договору, агент також не повинен їх показувати. Він діє з урахуванням ролі користувача, а не під загальним обліковим записом із максимальними правами.

Як відбувається подання заявки

Агент збирає відсутні відомості

Співробітник описує потребу звичайною мовою. Агент визначає категорію закупівлі та звіряє повідомлення з обов’язковими полями. Якщо відсутні кількість, термін, підрозділ, проєкт або технічна характеристика, він ставить конкретне запитання, а не надсилає людині порожній шаблон.

Перевіряє, чи потрібна нова закупівля

Перш ніж звернутися до постачальника, агент може перевірити залишок, відкриті замовлення та подібні заявки. Це не означає, що він сам скасовує потребу. Він показує закупнику знайдені збіги: відповідна позиція вже є на складі, замовлення очікує на поставку або така сама заявка перебуває на узгодженні.

Готує пакет документів для узгодження

До заявки додається короткий звіт: що потрібно, для якого процесу, до якого терміну, що вже перевірено та які документи додано. Якщо правила компанії вимагають кількох пропозицій або висновку фахівця, агент зазначає відсутність цих матеріалів і не переводить заявку на наступний етап.

Передає рішення відповідальній особі

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

Що можна виконувати автоматично

Без постійного ручного втручання можна виконувати підготовчі та перевірочні операції, результат яких легко перевірити та скасувати. Конкретний перелік залежить від правил компанії та якості даних.

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

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

Як обробляти винятки

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

Хороший сценарій не змушує модель вгадувати. Для кожного винятку заздалегідь визначається відповідальна роль, канал повідомлення та доступні дії. Замовник отримує причину зупинки та посилання на джерела, а не повідомлення «не вдалося виконати» без пояснення.

Якщо корпоративна система недоступна, агент також не повинен використовувати старе значення як актуальне. Він повідомляє, яке джерело не відповіло, зберігає чернетку та пропонує продовжити після відновлення доступу або передати завдання співробітнику.

Ролі, права та журнал дій

У сфері закупівель недостатньо знати, що агент «вміє працювати з ERP». Потрібно визначити, від чийого імені він переглядає дані та які записи може створювати. Співробітник бачить власну заявку, закупник — робочий пакет і довідники, керівник — підстави для прийняття рішення, а фінансова роль — лише той етап, який належить до її повноважень.

Кожен важливий крок фіксується: хто надіслав запит, які джерела було перевірено, які поля додано, за яким правилом обрано маршрут і хто підтвердив операцію. Журнал потрібен не заради технічної звітності. Він дозволяє відтворити хід узгодження та зрозуміти, де потрібно змінити регламент або дані.

З чого почати впровадження

1. Оберіть один тип заявки, що повторюється. Наприклад, витратні матеріали, обладнання до певного етапу узгодження або продовження корпоративного сервісу.
2. Описати обов’язкові дані та винятки. Які поля потрібні завжди, що можна отримати з систем і за яких умов процес зупиняється.
3. Обмежити джерела та дії. Спочатку достатньо прочитати довідники та створити чернетку без замовлення, відправлення та оплати.
4. Провести тестування на реальних маршрутах. Перевірити звичайні заявки, дублікати, недоступні системи, невідомі позиції та повернення на доопрацювання.
5. Розширювати після перевірки журналу. Новий тип закупівлі додається лише після того, як відповідальні особи зрозуміють, як працює поточний сценарій.

Що отримує бізнес

Результатом такого впровадження є не «автономний відділ закупівель». Бізнес отримує єдиний канал для подання заявок, менше повернень через пропущені дані, зрозумілий пакет документів для узгодження та прозору передачу між ролями.

Замовник бачить уже сформований контекст і займається умовами та винятками. Керівник розуміє, що саме він підтверджує. Ініціатор відстежує статус без повторних повідомлень кожному учаснику. При цьому ERP та регламенти залишаються джерелами обліку та правил, а агент працює в рамках дозволеного процесу.

Перевірка готовності процесу

• Чи є єдиний відповідальний за закупівельний маршрут?
• Чи визначено обов’язкові поля та причини повернення?
• Чи можна однозначно визначити залишок, позицію та відкрите замовлення?
• Чи розділені повноваження ініціатора, закупівельника, керівника та фінансового відповідального?
• Чи зрозуміло, які дії агент лише готує, а які заборонені без підтвердження?
• Чи зберігається історія джерел, змін та рішень?
• Чи є співробітник, якому доручають вирішувати нестандартні ситуації?

Якщо на ці питання є конкретні відповіді, ШІ-агент може стати повноцінним учасником процесу: збирати факти, готувати дії та дбайливо передавати рішення людині. Якщо правила існують лише в листуванні та пам’яті співробітників, спочатку варто впорядкувати сам маршрут — інакше агент лише прискорить існуючу плутанину.