Предиктивное обслуживание на российском заводе: что нужно, чтобы оно заработало

Чтобы предсказывать отказ, нужна история отказов. Не модель, не датчик, не подписка на облако — а записи вида «единица оборудования → дата → симптом → что сломалось → сколько простояли».

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

Вывод один: первый шаг предиктивного обслуживания — не покупка, а запись. Если история отказов не оцифрована, любой алгоритм — это алгоритм на пустом месте.

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

Предиктивное обслуживание (синоним — прогнозное обслуживание, от англ. predictive maintenance) — подход к техническому обслуживанию и ремонту (ТОиР), при котором решение о вмешательстве принимается не по календарю, а по фактическому состоянию агрегата и расчётному времени до отказа.

Полезная рамка уровней зрелости — она общеизвестна в отрасли:

Это рамка отрасли, а не наш замер. Цифр из материалов по уровням зрелости мы не приводим: они не сверены с первоисточником.

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

Здесь только то, что можно проверить. Оба факта — не российские, у обоих есть ограничения, и об этом сказано прямо. Индустриальный контекст — что уже работает на российских заводах, а что пока только в презентациях — мы разбирали в отдельной статье и здесь не повторяем.

42 % немецких промышленных компаний применяли ИИ в производстве к началу 2025 года, и 82 % считают применение ИИ решающим для конкурентоспособности отрасли — Bitkom, пресс-релиз «Industrial AI», 14 ноября 2025 (bitkom.org). Источник прочитан.

Сокращение незапланированных простоев примерно на четверть — результат у одной химической компании, где связали ИИ-прогнозную аналитику с программой операционного совершенства: PwC Belgium, 2025 (pwc.be). Источник прочитан.

Оба факта — не российские. Немецкие 42 % — опрос промышленных компаний Германии, 25 % — кейс одной химической компании. Переносить их на российский завод напрямую нельзя: ни по базе, ни по условиям, ни по тому, что считалось эффектом.

Есть класс работ, где цифры получены не на заводе. Это не значит, что они бесполезны, — но подписывать их надо честно.

Симуляция цифрового двойника: −70 % дефектов, −30 % времени выполнения заказа, −20 % энергопотребления на единицу продукции — Kinebas, Ivanov, Ivanov, Edelweiss Applied Science and Technology, том 9, выпуск 10, с. 541–555, 2025 (страница с абстрактом на RePEc: econpapers.repec.org). Прочитан абстракт.

По абстракту: применена симуляционная методология на цифровом двойнике производственной системы, сравнены три сценария — базовые операции с традиционными Lean-практиками, обычная автоматизация и интеграция «когнитивной робототехники». Рамка работы — украинские предприятия.

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

Использовать такие материалы правильно — как указание, куда смотреть, а не как доказательство. Модель говорит «в этом направлении есть потенциал, проверьте у себя» — и не говорит «у вас будет так же».

Это самый важный раздел статьи, и он короткий.

Что неизвестно по российским заводам: средний внеплановый простой на единицу оборудования; доля заводов, применяющих мониторинг состояния и прогнозную аналитику; типовая окупаемость таких проектов; сколько проектов доведено до эксплуатации, а не закрыто на пилоте.

Почему этих данных нет — три структурные причины:

По российским заводам сопоставимых публичных данных нет — по крайней мере, мы их не нашли. Данных нет, придумывать не будем. Поэтому дальше — способ измерить это у вас, а не средняя цифра по стране.

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

Ни одно из пяти условий не про софт. Четыре из пяти не требуют закупки.

Дальше есть числа — «год», «30–40 записей», «три–пять единиц». Держите в голове, что это наш ориентир из практики, а не измеренная величина из исследования: публичных замеров по российским заводам не существует (см. раздел 5), поэтому такие ориентиры у нас идут как рекомендация, а не как норма.

Условие 1. История отказов хотя бы за год. Минимум: единица оборудования, дата, что отказало, сколько это заняло времени. Год — потому что меньше не даёт повторяемости: узел должен отказать несколько раз, иначе считать нечего. Практически достаточно 30–40 записей по одной единице оборудования — это наш ориентир из практики, а не норматив из исследования.

Условие 2. Список критичного оборудования. Критичное — там, где остановка стоит дороже всего: узкое место маршрута, агрегат без резерва, линия с единственным поставщиком запчастей. Наш ориентир из практики — короткий список: три–пять единиц, а не весь парк. Начинать с полного парка — верный способ не закончить.

Условие 3. Хотя бы один измеримый параметр. Датчик — не обязательно вибродиагностика. Самый дешёвый параметр — наработка: моточасы, число циклов, тоннаж. Дальше по сложности: температура, потребление тока, давление, вибрация. Важно то, что обычно пропускают: параметр должен иметь базовую линию. Нормальная вибрация для одного эксгаустера не равна норме для другого — она зависит от агрегата, установки, режима. Без предварительного набора «как выглядит норма» любой порог будет выдуманным.

Условие 4. Назначенный владелец процесса. Один человек, у которого это в должностных обязанностях: обычно начальник службы ТОиР или главный механик. Не «ИТ-служба» и не «рабочая группа» — а конкретная фамилия, отвечающая за то, что записи ведутся, а сигналы разбираются. Это условие чаще всего и отсутствует: проект без владельца живёт до первого конфликта интересов между цехом и ремонтной службой.

Условие 5. Регламент: что делает мастер при отклонении. Самый недооценённый пункт. Регламент отвечает на четыре вопроса: кто получает сигнал; что обязан проверить и в какой срок; при каких условиях останавливает агрегат (и кто это разрешает); что делать с ложным срабатыванием, чтобы систему не отключили через месяц.

Без регламента данные остаются графиками на экране. Пилоты, которые «не дали результата», очень часто умирают именно здесь.

Ближайший к теме публичный российский пример — система прогнозного обслуживания эксгаустеров на аглофабрике ЕВРАЗа в корпоративном блоге компании: «Эксгаустеры и где они обитают», Habr, 15 апреля 2025 (habr.com). Источник прочитан. Компания сообщает, что внеплановые простои исключены, а расходы на ремонт снизились вдвое, — но это самоотчёт компании о своём проекте, независимого подтверждения нет, и работает там прогнозная аналитика на данных датчиков, а не нейросети или языковые модели (авторы подчёркивают это прямо), поэтому подавать кейс как «ИИ-консультант на заводе» нельзя.

Коротко: не оцифровывать всё — взять три–пять агрегатов, завести таблицу с минимумом полей и восстановить историю назад, насколько помнят мастера.

Что делать, если журнал ремонтов ведётся в тетради, а часть истории — в Excel у механика?

Это не «внедрение системы», а работа на полставки одного человека в течение месяца — и она даёт больше, чем пилот с датчиками на оборудовании, по которому нет истории. С логикой потерь в производстве это соотносится так: бережливое производство и ИИ.

Основной страх понятный: «чтобы всё это поставить, придётся останавливать производство». Останавливать не нужно.

Что измерять первым. Параметр, который (а) уже измеряется или измеряется дёшево и (б) меняется до отказа, а не в момент отказа. Для большинства агрегатов это температура и потребляемый ток: они часто уже есть в шкафу управления. Вибрация информативнее, но требует датчиков и настройки.

Где не надо останавливать линию. Измерение состояния, как правило, ставится на работающем оборудовании: внешние датчики, снятие сигналов с существующих приводов и контроллеров. Остановка нужна только там, где датчик физически встраивается внутрь узла.

Как не менять парк станков. Ничего из перечисленного не требует замены оборудования. Прогнозная модель работает поверх того, что есть; ограничение — не возраст станка, а наличие измеримого сигнала и истории.

Как встроить в действующий график ТОиР. Плановые ремонты не отменяются. Меняется одно: при получении прогноза ремонт смещается в ближайшее плановое окно, а не выполняется «внезапно».

Что проверить до первого прогноза. Собственную базу: как выглядит норма для этого агрегата в разных режимах. Без неё модель будет выдавать ложные срабатывания, а ложные срабатывания убивают доверие к системе быстрее, чем её отсутствие.

Мы описываем порядок работ, а не нормативы. Нормативы по ТОиР — отдельные документы (регламенты, паспорта оборудования, отраслевые требования), и в статье мы их не заменяем.

Где оно не работает:

И прямая граница нашего продукта. LeanAgent — это ИИ-консультант на сайте. Он обрабатывает обращения: отвечает на вопросы клиентов, квалифицирует запросы, передаёт сложное человеку. Он не управляет производством, не читает данные с датчиков и не делает предиктивное обслуживание. Предиктивное обслуживание и ИИ-консультант — разные задачи; мы не продаём первое и не делаем вид, что продаём.

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

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

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

Шаг 1. Выгрузить историю ремонтов за год — даже из тетради. Единица оборудования, дата, симптом, что сделали, часы простоя. Задача — не полнота, а наличие: 30+ записей по критичному агрегату уже дают, с чем работать. Это наш ориентир из практики.

Шаг 2. Отметить три–пять единиц, где простой стоит дороже всего. Считается просто: часы простоя × стоимость часа простоя для этого агрегата. Не «важность вообще», а именно деньги или невыполненные отгрузки за час остановки. Количество единиц — тоже наш ориентир, а не норматив.

Шаг 3. Ввести один числовой параметр наработки и писать его в ту же таблицу. Моточасы — самый дешёвый вариант. Через два-три месяца есть первые данные, на которых можно считать наработку до отказа, а не спорить о ней.

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

1. У нас журнал ремонтов в тетради. Нам это вообще доступно? Да, но не сразу и не в полном виде. Начать можно с переноса истории ремонтов в таблицу: единица оборудования, дата, что сломалось, сколько стояли. Прогноз без истории отказов невозможен, а история у вас есть — просто не в системе.

2. У нас 40 станков разных годов. Всё оцифровывать? Нет. Начинают с трёх-пяти единиц, где простой стоит дороже всего. Остальное — потом, если первый опыт подтвердится. Оцифровка всего парка сразу — самая частая причина, по которой такие проекты не доходят до результата.

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

4. В отчёте про −25 % простоев — это про нас? Нет. Это кейс одной химической компании в отчёте PwC, а не средний результат, и там измерялась связка «ИИ-аналитика плюс программа операционного совершенства». Мы приводим его как пример порядка величины, с пометкой источника. Переносить эту цифру на свой завод нельзя.

5. Мы уже поставили мониторинг на один станок, но не понимаем, что делать с данными. Это типичная остановка на середине. Без регламента («система показала отклонение — что делает мастер, кому звонит, что отключает») данные остаются графиками. Регламент дешевле датчиков, и его часто забывают.

6. А ИИ-консультант на сайте — это часть предиктивного обслуживания? Нет, это разные задачи. Консультант на сайте обрабатывает обращения клиентов. Мы говорим об этом прямо, потому что смешивать темы — значит обещать то, чего продукт не делает.

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

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

Читайте также: ИИ на российских заводах: что уже работает, а что пока только в презентациях · Бережливое производство и ИИ: где потери убирает алгоритм, а не человек · Бот или живой оператор: считаем, что дешевле · Правило первой минуты: почему горячий лид остывает до звонка · Все статьи блога

Павел Гмир, основатель LeanAgent. Производственный опыт: ТОиР, эксплуатация оборудования, организация службы ремонта на действующем производстве. Обсудить можно в Telegram или в TenChat.