Привет, Хабр! Большинство людей хотят получить максимум эффекта, прикладывая минимум усилий. Например, было бы круто создать идеальный сервис для клиента, но потратить на это как можно меньше денег. Или повысить уникальные товарные свойства продукта без соразмерного увеличения себестоимости. А как думаете, можно ли существенно снизить затраты на техническое обслуживание и ремонт оборудования и при этом повысить его общую эффективность? Мы в «Северстали» сделали это!

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

Что болит у производственной компании?

Любая производственная компания стремится снизить потери и риски, уменьшить негативное влияние на экологию и повысить безопасность сотрудников.

Анализируя причины потерь, мы пришли к выводу, что часть из них связана с техническим состоянием оборудования, его отказами и неисправностями. Но как добиться необходимого уровня надежности техники? И как это сделать, чтобы не увеличивать затраты на техобслуживание и не останавливаться на плановое ТО для обеспечения идеального состояния? Да и нужно ли это делать для всего (очень разношерстного) парка оборудования? А как понять, в какой момент важнее всего иметь это идеальное состояние? А как успеть все привести в порядок за короткое время и с ограниченным количеством персонала?

 Мы начали с теории.

Теория и практика ТОиР

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

В процессах ТОиР выделяют три подхода:

  1. Реактивное обслуживание. Агрегат работает до отказа. Ремонтируют его только после аварийной остановки.
    Плюсы: не останавливаемся на плановые ТО.
    Минусы: аварийный ремонт, как правило, дольше, дороже планового и срывает сроки производства продукции.

  2. Превентивное обслуживание. Это плановые ремонты и профилактика по регламенту.
    Плюсы: не допускаем критичного износа, минимизируем аварии, обеспечиваем план производства.
    Минусы: часто переобслуживаем оборудование — останавливаем агрегат и меняем запчасти, когда их состояние вполне позволяло поработать еще некоторое время. 

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

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

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

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

Сталевоз перевозит жидкую сталь между переделами
Сталевоз перевозит жидкую сталь между переделами

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

Это значит, при планировании ТОиР нужно учитывать множество факторов: критичность техники в момент времени, влияние на смежное оборудование, наличие резерва, экономическую целесообразность, загрузку. А еще есть требования законодательства к состоянию определенных видов механизмов!

В общем, когда начинаешь погружаться в теорию, голова идет кругом. Как же это освоить на практике?

Поиски решения привели нас к идее технического обслуживания, ориентированного на надежность (ТООН или RCM — Reliability Centered Maintenance). Эта методология позволяет выстроить управление процессами ТОиР таким образом, чтобы достигать требуемого уровня готовности оборудования с минимальными затратами. Звучит, как то, что нам надо. Выглядит так:

Методология технического обслуживания, ориентированного на надежность
Методология технического обслуживания, ориентированного на надежность

А работает так:

  1. Составляем каталог оборудования, разбиваем его на узлы. Каждому узлу присваиваем ранг критичности. Он рассчитывается по многомерной матрице критериев.
    Возьмем для примера вагоноопрокидыватель. Если на нем заклинит один из 16 опорных роликов, это снизит производительность агрегата, но не приведет к аварии. А вот разрушение подшипника на роторе — это аварийная длительная остановка и затраты на замену.

  2. Разрабатываем стратегию для каждого узла.
    Стратегия — это необходимый набор ремонтных действий для поддержания требуемого уровня состояния оборудования. При этом каждое действие направлено на снижение вероятности или тяжести последствий негативного события.
    Так, разрушение подшипникового узла из-за механического износа — негативное событие. Чтобы этого не произошло, нужно регулярно смазывать подшипник. Для смазки подшипников одного ролика потребуется остановка, два человека на два часа и 0,5 кг смазки.
    Очень важно при разработке стратегии учесть все возможные риски для оборудования, чтобы определить необходимые мероприятия ТОиР.

  3. Стратегии собираем в техкарту — инструкцию по обслуживанию агрегата, выполнение которой приведет к минимизации рисков возникновения негативного события.
    Для вагоноопрокидывателя в техкарту входят работы по проверке и смазке роликов, техобслуживание двигателей, пополнение масла в редукторе и т.д.

  4. Составляем план техобслуживания, куда из техкарты подтягиваем действия и необходимые ресурсы. План превращаем в сменные задания для ремонтного персонала.

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

  6. Копим статистику по неисправностям, расследуем их причины. Отслеживаем эффективность, вносим изменения в стратегии.

Что ж, план понятен, переходим к реализации.

Вагоноопрокидыватели переворачивают железнодорожные вагоны для разгрузки
Вагоноопрокидыватели переворачивают железнодорожные вагоны для разгрузки

Внедрение методологии ТООН

Про методологию ТООН мы узнали в 2012 году. В это время у нас уже был создан каталог оборудования в самописной АСУ ТОиР. Там же вели техническую документацию, планировали ресурсы, запасные части и расходники.

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

Для MVP использовали старый добрый MS Excel, в нем же создавали план ремонтов и обходов. На пилотных участках мы получили вдохновляющие результаты: нашли и исключили избыточные операции, которые не снижали риск отказа, и повысили качество стратегий обслуживания, что снизило количество аварий и уменьшило затраты на ТОиР.

Одновременно шло внедрение модуля PM в SAP ERP. Каталог оборудования переезжал туда, обрастал интеграциями и связями, стартовали пилотные проекты по SAP MRS и Work Manager. Таким образом все исполнение ремонтных работ получило свою информационную систему. Логично было и для ТООН выбрать ИТ-инструмент, чтобы жить в едином информационном пространстве.

В 2015 году мы купили и внедрили ИТ-систему по стратегическому управлению надежностью и эффективностью производственных активов. Это позволило тиражировать подход риск-ориентированного ТОиР на все подразделения группы компаний «Северсталь», выстроить процессы, набрать статистику по реализации стратегий, проводить анализ их эффективности и оперативно корректировать. И все было неплохо.

Но если вы читаете наш блог регулярно, то догадываетесь, что будет дальше :) 

Разработка ПО «Надежность»

В 2019 году в компании приняли решение переходить на S/4HANA. Наш текущий инструмент ТООН не поддерживал интеграцию с новой ERP-платформой. Встала задача как минимум сохранить работоспособность ИТ-решения ТООН, а в идеале — повысить его возможности.  

Мы взвешивали разные варианты: апгрейд существующей системы, покупка и внедрение нового ПО, разработка собственного решения.

После продолжительных дискуссий в 2020 году стартовал agile-проект разработки нового ПО. В основу функциональности легли шесть модулей:

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

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

  3. Реализация стратегий. Формируем нормативы для корректирующего и превентивного технического обслуживания оборудования, передаем на исполнение

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

  5. Разбор отказов. Анализируем повторяемость и интенсивность отказов, оцениваем эффективность программы ТОиР. Устраняем корневые причины отказов.

  6. Управление рекомендациями. Разрабатываем мероприятия по повышению общей эффективности оборудования. Проверяем их исполнение.

При проработке архитектуры руководствовались принципом – обеспечение высокого уровня юзабилити, максимально простое развертывание. Пользователь работает в браузере, аутентифицируется через Active Directory, рассылки о значимых событиях получает в почту. Данные информационной системы храним в реляционной СУБД, интегрируемся с ERP для получения справочников и передачи стратегий на исполнение, отчётность формируем в BW. 


Верхнеуровневая архитектура ПО «Надежность»
Верхнеуровневая архитектура ПО «Надежность»

Писали бэкенд на Java, а фронтэнд на Javascript (React). Java приложения крутится на JVM (Java Virtual Machine), все упаковано в Docker контейнере под оркестрацией Kubernetes (K8s), что позволяет не привязываться к конкретной платформе. 

Конечно, мы столкнулись с кучей проблем при разработке. Особенно тяжело было переходить с коробочного решения на самописное. Было важно не потерять предыдущий опыт: пришлось мигрировать пятилетний объем исторических данных в новую структуру БД и адаптировать проверки и алгоритмы. С другой стороны, производственные подразделения стали наполнять беклог все новыми хотелками — почувствовали, что больше нет ограничений «коробки». В бурном потоке требований приходилось выстраивать целевой продукт и отсеивать малоэффективные доработки. И все это в условиях тотального локдауна и удаленки.

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

Модуль «Анализ критичности»
Модуль «Анализ критичности»

В продуктив ПО «Надежность» запустили в ноябре 2021 года. Сейчас у нас более 1000 пользователей в пяти компаниях, 1,5 миллиона технических мест в каталоге оборудования, 20 тысяч стратегий, 140 тысяч техкарт, 400 тысяч действий. Настроена отчетность, аналитика, моделирование, встроенные проверки по основным методологическим требованиям, а также есть высокие оценки пользователей на основании обратной связи.

Но мы не останавливаемся на достигнутом — беклог развития растет. Более того, модуль исполнения у нас теперь тоже свой — мы не стали перевозить в новую ERP решения MRS и Work Manager. Но об этом я расскажу в следующий раз :)

Что дальше?

За время внедрения методологии ТООН в «Северстали» мы достигли грандиозных успехов — снизили ремонтные затраты на 40% и при этом повысили коэффициент технической готовности оборудования на 3%. Мы контролируем риски, гарантируем надежность оборудования для производственных задач и имеем объективную картину для планирования ремонтного фонда.

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

Но самое главное — мы создали продукт, который содержит нашу экспертизу, методику и практики.

Мы уже зарегистрировали ПО «Надежность» в Роспатенте и теперь занимаемся внесением его в Единый реестр российских программ для электронных вычислительных машин и баз данных. А это значит, что мы готовы делиться нашим ПО с другими производственным компаниями. Ведь все хотят снизить свои потери и эффективно управлять затратами.

А как вы снижали затраты и повышали уровень сервиса для своих клиентов?

Комментарии (5)


  1. Vassam
    14.07.2022 21:52
    +3

    Нужная, конечно, система. Я на весьма "традиционном" производстве работаю, где показания с показометра до сих пор глазами снимаются и в журнальчик записываются, а далее в журнальчик никто никогда не смотрит, и часто недоумеваю, почему нельзя выстроить нормальную информационную систему, стоимость которой в разы, в десятки раз меньше стоимости оборудования и в сотни-тысячи - меньше стоимости производимой продукции. Ну намного же легче всем, от рабочего, до главного инженера, если хотя бы температуры редукторов будут фиксироваться и намекать всем на скорый ремонт, чем когда на повышенную температуру редуктора внимание обращаешь из-за того, что он докрасна раскалился и краска с него облезла, да всё это посреди какого-нибудь производственного завала - другого редуктора нет, запчастей нет, планы по выпуску горят, физически доступ к редуктору затруднён. Намного легче, когда каждый рабочий, приходя на смену и глянув в монитор, увидит тонкие места и сроки ТО-ТР, а не один человек за всё это беспокоится и в документацию завода-производителя тычет, а 200 человек плюют - и без смазки поработает.


    1. oapeshina
      15.07.2022 10:38

      Да, контроль "здоровья" оборудования - один из основных принципов надёжности. В одной из следующих статей расскажем, как это реализовано у нас.


  1. Tomasina
    15.07.2022 00:07

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

    Плюс внедрение цифровой системы хотя бы мониторинга тоже денег стоит, а к ней также нужен молодой специалист на обслуживание. Итого затраты возрастут (работник-то не один), а выход продукции останется тот же.

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


    1. oapeshina
      15.07.2022 10:47
      +1

      Вы затронули действительно сложную тему)
      Давайте разобьём на две:
      1. Как развить культуру принятия новых технологий. Мы работаем над этим повышением общего уровня цифровой грамотности (например, Как мы сделали программу обучения) и формированием отношения: "цифровизация повышает качество работы и жизни, а не отнимает у вас зарплату".
      2. Эффекты от внедрения цифровых инструментов. Да, создание и поддержка ПО стоит денег. Но при этом мы повышаем скорость, качество и безопасность производственных операций. На примере Надёжности - благодаря актуализации стратегий от условий производства, мы значительно снизили ремонтные затраты. Зачастую это действительно снижает затраченное сотрудником время, давая возможности делать другие, иногда более творческие задачи. При этом, если у сотрудника повысилась квалификация, значимо расширился функционал - здесь очевидно будет пересмотр вознаграждения.


    1. Vassam
      15.07.2022 23:41

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

      Касательно новых задач и оплаты труда - вопрос во многом политический и экономический, да, у нас любят грузить всем подряд за те же деньги и не любят повышать зарплаты за дополнительную квалификацию. Но это результат убийства профсоюзов и странного отношения властьимущих к своей стране - декларируя патриотизм и стремление к развитию, реальное стремление - дёшево производить продукцию в своей стране, где ФОТ - традиционно первая и самая простая статья экономии (где-то, вроде, я читал, что и Северсталь этим грешна, хотя может это про Норникель было), и дорого продавать её туда, где это не так, что да, приводит к тому, что наёмному работнику невыгодно повышать/расширять квалификацию, потому как работать за пятерых с доплатой в условный коробок спичек - прямой вред себе любимому. С точки же зрения здравого смысла и холодных цифр, грамотная, интегрированная система мониторинга, технического обслуживания, информирования соответствующих подразделений, организации складских запасов и закупок просто обязана быть выгодной как работодателю, так и работнику.