Четыре технологические линии и упаковка вставали из-за внезапных поломок: ремонт занимал дни, запчасти закупались «на всякий случай», а данные с датчиков годами лежали в архиве мёртвым грузом. Агент читает телеметрию, видит аномалию до отказа, сам создаёт наряд на обслуживание и заявку на запчасть — и делает это в среднем за 14 часов до остановки линии.
Производственное предприятие пищевого направления: четыре технологические линии, упаковочный узел и собственная ремонтная служба. Работа в две смены, около 340 сотрудников, выпуск идёт непрерывно — остановка линии означает не только потерянные часы, но и списанное сырьё, переналадку и срыв отгрузок в сети розницы. Предприятие работает в Центральном и Приволжском федеральных округах, отгрузки идут по РФ и в страны СНГ.
Парк — примерно 1 240 единиц оборудования, включая приводы, насосы, компрессоры, транспортёры и фасовочные машины. С датчиков снимается около 380 телеметрических параметров: вибрация, температура подшипников и редукторов, ток приводов, давление, расход, наработка. Данные писались в историк несколько лет — но никто их системно не смотрел: операторы реагировали на остановку по факту, а инженеры разбирали причины уже после простоя.
Ремонтная служба — 14 человек: слесари, электрики, специалисты по контрольно-измерительным приборам. Заявки жили в ERP и в бумажных журналах, запчасти заказывались в момент аварии, а не заранее. Главный инженер сформулировал задачу без иллюзий: «Мы не хотим систему, которая будет предсказывать всё. Нам нужно, чтобы она честно говорила: вот узел, вот сколько у него осталось, вот что заказать. И чтобы не кричала по пустякам». Посмотрите, как похожие задачи решаются в услуге AI-аналитика.
Если читаете по диагонали: за восемь недель мы развернули контур мониторинга телеметрии, который читает данные датчиков по OPC UA, ловит аномалии до отказа на Isolation Forest и LSTM, создаёт наряд на обслуживание и заявку на запчасть в ERP, а инженеру присылает контекст: какой узел, какое отклонение, сколько примерно осталось до отказа. Результат: простои −34%, 23 предотвращённые аварии, расход запчастей −19%, точность детекции по участкам 58–91% — честный разброс, который зависит от полноты датчиков.
Внешне производство работало устойчиво: план выпуска выполнялся, отгрузки шли, ремонтники справлялись. Но экономика держалась на героизме — на людях, которые по звуку и вибрации определяли, что узел «уже не тот», и на аварийных закупках, когда подшипник выходил из строя в пятницу вечером. Предприятие уже пробовало решать это точечно: закупало систему диспетчеризации с экранами в цехе, вводило еженедельные обходы и таблицы в Excel, а один из инженеров пытался строить графики трендов вручную раз в месяц.
Экраны показывали текущие значения, но не отвечали на вопрос «что будет через сутки». Обходы помогали, но занимали у ремонтной службы почти день в неделю и не покрывали всё оборудование. Ручные графики устаревали раньше, чем их успевали построить. Итог — 41 незапланированная остановка за год и стойкое ощущение, что данные-то есть, а решения всё равно принимаются вслепую.
Мы разобрали 41 аварию за год и посчитали стоимость каждой причины. Все суммы — оценка Лидерс AI по данным предприятия, а не гарантия экономии.
41 незапланированная остановка за год, средняя продолжительность — 9,5 часа. Сюда входит не только потерянный выпуск, но и списание сырья, промывка линии, переналадка и перепланирование отгрузок. Остановка в сезон особенно дорогая: продукт не отгружается, а полка в рознице не ждёт.
Оценка потери: около 17,9 млн ₽ в год при стоимости часа простоя 46 000 ₽.
Среднее время от остановки до запуска — 14 часов, и больше половины этого времени уходило не на работу, а на ожидание: согласование, поиск запчасти, вызов подрядчика, уточнение, кто именно должен приехать. Ремонтники приступали к работе, когда линия уже стояла несколько часов.
Оценка потери: около 8,4 часа ожидания на каждый инцидент — 386 000 ₽ на одну аварию.
Склад запчастей на 4,2 млн ₽, из которых 18% позиций не двигались больше года — их закупали «на всякий случай» после прошлых аварий. Одновременно критичные позиции отсутствовали, и их покупали в срочном порядке с наценкой до 40% у посредников.
Оценка потери: около 1,4 млн ₽ в год на срочные закупки и замороженные остатки.
380 параметров писались в историк, но использовались как архив: посмотреть, что было во время аварии, можно было только вручную и только по запросу. Тренды не анализировались, пороги не настраивались, никто не смотрел, как меняется вибрация узла месяц к месяцу.
Оценка потери: данные, которые могли предотвратить десятки остановок, лежали без применения — самая дорогая потеря из всех.
Решение «пора менять подшипник» принималось по опыту конкретного специалиста. При уходе одного слесаря в отпуск среднее время диагностики выросло почти на треть, а смены передавали знания устно. Формализованных правил, по каким признакам узел считается проблемным, не существовало.
Оценка потери: +30% ко времени диагностики в периоды без ключевых специалистов.
Чтобы понять, какое оборудование «проблемное», инженер выгружал данные из ERP и журналов вручную — два дня работы раз в месяц. Из-за задержки решения по замене оборудования принимались с опозданием на квартал, а бюджет на ремонт формировался по прошлогодним цифрам.
Оценка потери: 24 дня в год рабочего времени инженера и запоздалые решения по замене узлов.
Инвентаризировали 1 240 единиц оборудования и 380 параметров, восстановили карту отказов за 24 месяца и разобрали все 41 аварию по узлам. Нашли девять узлов, где аномалия видна заранее: подшипники транспортёров, редукторы фасовки, приводы насосов. Здесь и начинается экономия.
Собрали двухуровневую схему: Isolation Forest ищет многомерные выбросы в текущем окне телеметрии, LSTM отслеживает тренд и оценивает, сколько времени осталось до выхода параметра за границу. Пороги настроили отдельно по каждому участку — общий порог на весь парк даёт либо пропуски, либо лавину ложных срабатываний.
Запустили мониторинг на линии розлива и упаковочном узле. Проверяли на исторических данных за 18 месяцев: модель должна была предупредить не менее чем о 70% известных аварий минимум за 12 часов до остановки. Первые пороги калибровали вместе с главным механиком — он же и был главным скептиком проекта.
Связали агента с ERP и историком: он сам создаёт наряд на обслуживание с перечнем узлов и значений, формирует заявку на запчасть из спецификации, отправляет уведомление в Telegram дежурному инженеру и обновляет статус после ремонта. Данные читаются по OPC UA, контур развёрнут на серверах предприятия.
Обучили 14 ремонтников и 6 операторов: как читать тревогу, как различать уровни, как оспорить срабатывание и как менять пороги. Отдали документацию по модели, регламент реакции и дашборд надёжности. Дальше пороги правятся внутри предприятия — без нас.
Это не диспетчеризация с экранами и не «умный» дашборд, который показывает то же, что и раньше, только красивее. AI-мониторинг — это контур, который превращает поток телеметрии в конкретные действия: наряд, заявку на запчасть, уведомление и обоснование. Система не просто сообщает, что параметр вышел за границу, — она показывает, какой узел деградирует, с какой скоростью и сколько времени осталось до отказа.
Отдельно про границы: система не останавливает линию и не блокирует оборудование. Она предупреждает и готовит документы, а решение принимает главный механик или дежурный инженер. Именно так снимается главное возражение ремонтной службы: «машина не будет решать за нас, когда вставать».
На экране — состояние четырёх линий: активные аномалии, остаток времени до отказа, наряды в работе и динамика простоев по участкам. Ниже — что делает каждый модуль.
Читает данные с контроллеров по OPC UA, приводит параметры к единому виду, считает агрегаты по окнам и хранит историю в PostgreSQL. Отдельно следит за качеством данных: если датчик молчит или выдаёт «замороженное» значение, это фиксируется как отдельное событие — на таком датчике нельзя строить прогноз.
Каждые несколько минут пересчитывает состояние узлов: Isolation Forest ищет выбросы, LSTM оценивает тренд и остаток времени до отказа. Тревоги делятся на информационные и требующие действия, а ложные срабатывания разбираются с механиком и уходят в калибровку порогов.
Создаёт наряд в ERP с узлами и значениями, подбирает запчасти из спецификации, ставит заявку в очередь, уведомляет дежурного инженера и обновляет статус после ремонта. Если авария всё же произошла, система сохраняет предысторию — почему предупреждение не сработало или почему им не воспользовались.
Замеры велись по историку телеметрии, журналу нарядов в ERP и отчётности ремонтной службы. Производственная программа не менялась: те же четыре линии, та же смена, та же численность ремонтной службы. Суммы в рублях — оценки по данным предприятия.
| Метрика | До | После | Эффект |
|---|---|---|---|
| Простои оборудования | 412 ч/год | 272 ч/год | −34%; ≈ 6,4 млн ₽ сохранённой маржи |
| Предотвращённые аварии | — | 23 за 8 месяцев | каждая — это ≈ 9,5 ч простоя |
| Расход запчастей | 100% | 81% | −19%; ≈ 1,1 млн ₽ в год |
| Точность детекции по участкам | — | 58–91% | 91% на линии розлива, 58% на упаковке |
| Время до предупреждения | 0 (по факту остановки) | медиана 16 ч | есть окно на плановый ремонт |
| От аномалии до наряда | 6,5 ч вручную | 4 минуты | 98% нарядов создаются без диспетчера |
| Среднее время ремонта (MTTR) | 14 ч | 8 ч | −43%; запчасть уже на складе или в пути |
| Аварийные закупки с наценкой | 34 заказа/год | 7 заказов/год | ≈ 480 000 ₽ в год экономии |
| Отчёт по надёжности | 2 дня вручную раз в месяц | автоматически к 8:00 | 24 дня в год возвращены инженеру |
Как это читать. Снижение простоев — не результат «умного ИИ», а следствие того, что ремонт перестал быть аварийным: у службы появилось окно в 12–24 часа, за которое можно подготовить запчасть, инструмент и людей. Расход запчастей упал по той же причине: деталь меняют тогда, когда она действительно изношена, а не тогда, когда всё встало. И честно про точность: разброс 58–91% по участкам — это разброс по полноте данных. Там, где нет датчиков вибрации, модель видит только косвенные признаки, и мы говорим об этом прямо, а не показываем одну красивую цифру.
Проект разбит на два этапа: пилот на линии розлива и масштабирование на все четыре линии и упаковку. Оплата — этапами 30/40/30, как и во всех проектах Лидерс AI. Инфраструктура включает серверную часть в контуре предприятия, лицензии моделей, хранение истории и мониторинг качества детекции.
| Статья | Сумма | Комментарий |
|---|---|---|
| Пилот (аудит + одна линия) | 240 000 ₽ | Линия розлива и упаковка, проверка на истории за 18 месяцев |
| Масштабирование (4 линии + интеграции) | 620 000 ₽ | OPC UA, PostgreSQL, ERP, наряды, заявки на запчасти, дашборд |
| Инфраструктура | ≈ 34 000 ₽/мес | Серверы в контуре, модели, хранение истории телеметрии |
| Итого проект | 860 000 ₽ | Тариф «Автоматизация направления», оплата 30/40/30 |
Окупаемость — около 2,1 месяца. Расчёт консервативный: в него взяты только сокращение простоев и расхода запчастей, при стоимости часа простоя 46 000 ₽. Эффект от снижения сверхурочных и от переноса ремонтов в плановое окно мы не считали — он есть, но зависит от загрузки смен. Медианная окупаемость по всем 42 проектам — 3,1 месяца; здесь быстрее, потому что час простоя в непрерывном производстве стоит дорого. Как мы считаем такую экономику, разобрано в статье сколько денег приносит AI-агент.
Что не входило: ремонт оборудования, закупка датчиков и контроллеров, автоматическая остановка линий и ведение бюджета ремонтной службы. Это остаётся за вашими инженерами и службой снабжения.
Как устроена автоматизация процессов →Мы не строили отдельную «систему предиктивной аналитики», а соединили то, что уже стояло на предприятии: датчики и контроллеры дали данные, историк — глубину истории, ERP — процессы ремонта и снабжения. Агент стал слоем, который превращает телеметрию в наряд.
Источник данных: вибрация, температура подшипников и редукторов, ток приводов, давление, расход, наработка. Протокол OPC UA читает значения напрямую из контроллеров, без ручных выгрузок.
Рабочее хранилище телеметрии и событий: нормализованные параметры по окнам, история аномалий, статусы нарядов, журнал действий агента. На этих данных пересчитываются пороги и проверяется точность модели.
Модель формулирует понятное описание аномалии для инженера: какой узел, что именно отклоняется, на сколько и что проверить. Она же собирает отчёт по надёжности и объясняет, почему сработала или не сработала тревога.
Процессы обслуживания и снабжения: наряды, спецификации, склад запчастей, заявки. Агент создаёт документы в ERP и обновляет статусы, поэтому ремонтная служба работает в привычной системе, а не в отдельном приложении.
Схема связей: контроллеры и датчики → OPC UA → PostgreSQL → детекция аномалий (Isolation Forest + LSTM) → LLM-описание → наряд и заявка на запчасть в ERP → уведомление дежурному инженеру. Контур развёрнут на серверах предприятия, доступы разграничены по ролям, каждое действие агента фиксируется в журнале. Подробнее про связку технологий — в статье n8n + LLM + CRM.
«Я был тем человеком, который на первой встрече сказал: у нас уже есть диспетчеризация, и она ничего не изменила. Мне показали не презентацию, а разбор наших же аварий: вот эта остановка была видна за сутки, вот эта — за шесть часов, а вот эту модель бы не поймала, потому что датчик на узле умер ещё в прошлом году. После этого разговора стало понятно, что дело не в магии, а в том, что данные наконец кто-то читает. Сейчас утро дежурного начинается не с обхода, а с карточки: какой узел в зоне риска, что заказать, в какое окно встать на ремонт. Отдельно ценю, что система не пытается остановить линию за меня. Она приносит аргументы, решение остаётся моим».
Отдельно отметим то, о чём редко пишут в кейсах предиктивного обслуживания: первый месяц служба реагировала на каждую тревогу и часть срабатываний оказалась лишней — доля ложных доходила до 22%. Мы не стали прятать это в отчёте, а вместе с главным механиком прошли три итерации калибровки порогов, снизив долю до 6%. Именно эта работа, а не сама модель, определила, будет ли система использоваться или её отключат через две недели. Про типичные ошибки внедрения мы подробно писали в статье почему AI-проект не окупился.
Не нашли свой вопрос? Напишите в Telegram или позвоните по номеру.
Если задача похожа на вашу, посмотрите, как мы решали её в других отраслях. Полный список — в разделе все кейсы.
Шесть юрлиц, закрытие месяца шесть дней и кассовые разрывы, о которых узнавали постфактум. Агент сводит данные с банком, прогнозирует cash-flow и предупреждает о разрывах заранее.
Тот же принцип работы с потоком данных, только вместо датчиков оборудования — телематика 42 машин: агент прогнозирует ETA, перестраивает рейсы на ходу и предупреждает о просрочках.
18 400 счетов и актов в месяц разносились вручную. Если у вас наряды и заявки живут в учётной системе, этот кейс показывает, как агент закрывает документооборот без оператора.
Работаем по России и СНГ: внедряли проекты в Москве, Санкт-Петербурге, Екатеринбурге и других городах. О команде — в разделе о нас, связаться можно через контакты.
Разберём, какие данные с оборудования у вас уже есть, какие отказы можно было предотвратить и что для этого нужно. Посчитаем стоимость часа простоя, покажем расчёт и смету со сроками. Без презентаций и давления: даже если вы решите ничего не внедрять, карта парка и расчёт останутся у вас.
Ответим в течение 30 минут в рабочее время. Пришлём вопросы для подготовки, чтобы не тратить ваше время.
Мы свяжемся с вами в течение 30 минут в рабочее время и пришлём вопросы для подготовки к аудиту.