APP Motors проверяет задачи в цеху каждые пять минут и напоминает о простоях

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

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

От устного поручения до задачи

Сценарий начинается прямо в цеху. Руководитель диктует поручение, телефон распознаёт речь, а модель раскладывает текст по полям: название, описание, срочность, срок и исполнитель. Перед созданием человек проверяет результат.

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

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

Здесь же обнаружился показательный баг: функция получала контекст проектов и похожих задач, но не включала его в запрос к модели. Тесты проходили, поскольку подменяли вызов уровнем выше. Автор добавил проверку собранного запроса целиком. Для команды, внедряющей LLM, это вполне прикладной урок: проверять нужно и данные, которые действительно доходят до модели.

Кто напоминает о простое

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

Задачи можно связывать отношением «нужно для»: чертёж требуется для детали, деталь — для сборки. Программа ищет активную задачу без незакрытых подзадач и проверяет, давно ли по ней было движение. Для критической цепочки порог составляет четыре часа, для обычной — два дня. Приоритет берётся по самой срочной задаче цепочки.

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

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

Что стоит перенять и что проверить

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

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

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

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