Свою ERP заказывают не целиком: агенты собирают её по одному процессу за раз

Разработка ERP начинается с ответа, какой результат сотрудники должны получить без ручного переноса данных. ERP связывает заказы, запасы и производство общим учётом. Красивой таблицы для этого мало.

Первый процесс стоит выбирать по повторяющейся потере времени или ошибке. В учебном примере торговой компании это резерв товара под заказ. Менеджер обещает поставку, а склад должен видеть, что этот товар уже занят.

Границу такого заказа проводят от подтверждения заявки до снятия резерва при отгрузке или отмене. Внутри нужны правила изменения количества, права сотрудников и проверка свободного остатка. Это пример постановки, не наш клиентский кейс.

Если заказать только «экран склада», приёмка закончится показом экрана. Чтобы принять процесс, сотрудник должен провести операцию и сверить результат. Подробный шаблон задачи для агента уже есть в соседнем разборе.

Своя система не требует сразу заменить то, что уже работает. Axmor на странице ERP-разработки описывает отдельные модули и сервисы вокруг существующего учёта. Поэтапный подход был и до агентов.

В нашем примере резерв можно вести в новом модуле, сохранив учёт фактических остатков в действующей системе. Но источник каждого значения назначают заранее. Две программы, каждая из которых сама решает, сколько товара свободно, дадут два разных ответа.

Surf предлагает проверять обмен до переключения сотрудников, Firecode описывает выпуск ключевых модулей поэтапно. Мы прочитали их страницы 7 октября 2026. Из этих подходов следует полезное условие заказа: работающий обмен входит в приёмку первого процесса.

Если старый код надо менять постепенно, приёмы разобраны в статье про технический долг. ERP добавляет вопрос учёта: кто записывает факт, кто получает его копию и где сотрудник увидит расхождение.

Агенту для кода нужен описанный процесс. В техническом разборе Surf агент получает карту системы и пишет нужное изменение; тесты и линтер проверяют результат. Поэтому неверно считать, что студии вообще не используют агентов.

Инженер ведёт машину агентов: переводит договорённости в описание, ограничивает изменения и проверяет работу. Для резерва он фиксирует момент подтверждения заказа и правила отмены. Агент собирает формы, обмен и проверки по этим правилам.

На нашем сайте описание живёт рядом с кодом. На открытой карте машины 7 октября 2026 указаны 387 тысяч строк описаний и 391 тысяча строк кода. Это объём нашего проекта, не норматив документации для ERP.

Общее описание сохраняет смысл при следующей задаче. Если менеджер попросит частичную отгрузку, агент должен прочитать прежние правила резерва. Файл и порядок его чтения разобраны в статье о правилах для ИИ-агентов.

Своя админка стала внутренним инструментом vibecoding.ru. Но учёт заявок сайта не проверяет производственные партии или складские остатки. Свою CRM мы разбирали отдельно; здесь интересует следующий шаг от интерфейса к связанным операциям.

Правила вашей ERP должны проходить её проверки. Количество строк и тестов само по себе не отвечает, совпали ли остатки после отмены заказа. Ответ даёт конкретная сверка.

Демонстрация показывает ход без ошибок. Для ERP важны и отмена, и повторный запрос, и оборванный обмен. К каждому такому случаю нужен ожидаемый результат в учёте.

В примере резерва повторная отправка подтверждения не должна занять товар ещё раз. После разрыва связи сотрудник должен видеть, завершилась ли операция. Сообщение «готово» при неподтверждённом обмене создаёт обещание товара, которого может не быть.

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

2 685 тестов на каждом пуше указаны на /open в снимке 7 октября 2026. Для вашего процесса нужны свои проверки. Число чужих зелёных тестов не подтверждает правильность вашего остатка.

Критерии готовности принимает сотрудник, который знает операцию. Разработчик проверяет код и обмен; кладовщик сверяет остаток и отмену. Решение о запуске остаётся у назначенного руководителя.

Агенту хватает вымышленных заказов для проверки логики. Если в материалах есть данные людей, подготовку примеров разбирает статья о персональных данных и ИИ-агентах.

Старый учёт и новый модуль сверяют на выбранных операциях до переключения. Расхождения сначала объясняют и исправляют. Скриншот похожих сумм не заменяет сверку отдельных заказов.

Условия допуска и восстановления после поломки разобраны в статье об ответственности за ошибки ИИ. В заказе ERP они превращаются в проверяемый вопрос: что происходит с уже принятыми операциями при возврате к прежнему модулю?

ERP-система для производства требует границы, понятной цеху. Для пилота можно выбрать передачу материала в работу и запись фактического выпуска. В пример сразу включают возврат остатка и брак.

План выпуска и факт выпуска должны оставаться разными записями. Если экран автоматически списывает весь план как выполненный, руководитель видит выпуск, которого ещё не было. Агент не может сам решить, когда мастер подтверждает результат.

Правила единиц измерения тоже задаёт предприятие. Материал на входе и изделие на выходе могут учитываться по-разному. Из пересчёта должны быть видны расход и потери, а не только зелёный статус задания.

Это учебный пример выбора процесса, а не рассказ о нашем заводе. Если нельзя выделить операцию без переделки всего учёта, первой работой станет разбор данных и зависимостей. Покупать весь набор экранов до такого разбора рано.

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

Цена месяца разработки не равна цене готовой ERP. На подписке «Все проекты» 500 000 ₽ в месяц дают три потока работы; условия проверены 7 октября 2026. Поток означает одну задачу в работе и очередь следующих. Ночные дежурства, архитектурные решения и найм в тариф не входят.

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

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

Замер делают по одной и той же операции. Время подтверждения, расхождения учёта и ручные исправления сравнивают до и после запуска. Количество написанного кода не показывает, стало ли проще отгружать товар.

Расхождение становится правилом, правило становится тестом, агент исправляет код. Когда повторная проверка и сотрудник принимают результат, можно добавлять соседний процесс. Так система растёт по обратной связи от работы.

1. Выберите завершённый процесс и назовите результат в учёте. Заказ на набор экранов оставляет проверку данных за пределами приёмки.
2. Назначьте источник каждого значения. До запуска проверьте обмен, отмену и повтор операции.
3. Получите описание правил вместе с кодом и тестами. Сотрудник должен принять результат своей операции.
4. Сравните один процесс до и после запуска. Следующий заказывайте по обнаруженным расхождениям и ручной работе, которая осталась.