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