ШІ пише застосунки для ERP замість щоденних запитів
Райан Кінг, CIO виробника гідравлічних деталей Brennan Industries, будує для колег прості застосунки в Claude Code і Codex. Макет готовий за 45 хвилин. Після погодження агент переписує його на SuiteScript, і застосунок працює вже в NetSuite. За словами Кінга, він закриває до пʼяти проєктів на день, а раніше кожен забирав тиждень і більше. Приклад: екран для дзвінків клієнтів непомітно для менеджера заносить дані в CRM. Його зробили за одне пообіддя.
Агент у чаті витрачає токени на кожному повторенні, а скрипт в ERP — ні. Кінг сам застерігає: без глибокого знання ERP агента не скеруєш.
Цикл одного проєкту: від розмови до запуску
Кінг працює в Claude Code, OpenAI Codex, а останнім часом також у NetSuite Next. Типовий проєкт у нього складається з короткої послідовності, у якій беруть участь двоє: він і колега з бізнесу, якому потрібен інструмент.
- Колега розповідає всі вимоги.
- Кінг менш ніж за годину збирає з агентом макет, за його словами приблизно за 45 хвилин.
- Колега переглядає макет і просить зміни, Кінг їх вносить.
- Після погодження агент створює застосунок на SuiteScript усередині NetSuite, і його запускають.
Раніше, каже Кінг, для такого потрібна була група людей і наради. Частину запитів він узагалі не брав: казав керівництву, що знадобляться розробники й допомога NetSuite, і проєкт скасовували.
Чат чи скрипт в ERP: де проходить межа
Аргумент Кінга побудовано на повторюваності. За його словами, багато компаній просто «віддають задачу в чат» і щоразу дають ШІ її виконувати. Його логіка: якщо дія повторюється постійно, краще один раз побудувати програму в NetSuite, яка робитиме це автоматично. Таке середовище компанія контролює й може підтримувати, і токени не витрачаються на кожне повторення. Агент тут слугує інструментом розробки, а щоденну роботу виконує скрипт.
Приклад з виробництва. Клієнти дзвонять, щоб дізнатися ціну й дату поставки деталі, і таких дзвінків сотні. Раніше слід лишався лише тоді, коли клієнт робив замовлення: перемикатися між екранами, щоб записати, з ким і про що говорили, продавцям було надто незручно. Новий екран, зроблений з Claude, заповнює CRM у NetSuite у фоновому режимі, поки людина робить звичну роботу. Кінг називає три результати: працівник не помічає, що працює з CRM; зібрані дані можна відпрацьовувати; накопичується історія дзвінків, якої раніше не було.
Як ставити завдання агенту
Кінг вважає, що ERP-застосунки стануть простішими: користувач бачитиме лише потрібні поля, а процеси ERP лишаться прихованими. Формулювання, яке він наводить, можна брати за шаблон:
Виходячи з того, як працює наш бізнес, створи форму, на якій є X, Y і Z. Більше нічого. Кінцеві користувачі не повинні робити нічого іншого. Коли я вводжу дані, став запитання щодо цих даних.
Друга частина інструкції описує процес. Кінг наголошує, що агенту треба прямо сказати, які кроки в NetSuite виконати і що заповнювати. Каркас:
У NetSuite процес такий: [крок 1], [крок 2], [крок 3]. Дотримуйся саме його. Заповнюй [записи й поля]. Якщо щось незрозуміло, спитай мене, перш ніж продовжувати.
Межі прийому і що перевірити
Головне обмеження Кінг формулює сам: це не магія, а інструмент, і з ним має працювати людина, яка знає ERP. Без розуміння процесів у системі агента не скеруєш і на його запитання швидко не відповіси. Отже, прийом розрахований на того, хто сам може описати процес крок за кроком. У Brennan це CIO.
- Замовник переглянув і підтвердив макет до переписування на SuiteScript.
- Описаний агенту процес збігається з тим, як ERP використовують саме у вас. Кінг підкреслює, що кожна компанія робить це по-своєму.
- Задача справді повторюється, інакше аргумент про економію токенів не діє.
- Дані, які застосунок пише у фоні, потрапляють у потрібні записи. Користувач цього не бачить і помилки сам не помітить.
«До пʼяти проєктів на день» і «45 хвилин» — це слова самого Кінга про прості застосунки, які він будує. Прогноз, що кожна компанія матиме набір власних застосунків, теж належить йому. Автор статті з цим прогнозом погоджується.