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

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

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

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

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

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

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

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

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

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%. Мы контролируем риски, гарантируем надежность оборудования для производственных задач и имеем объективную картину для планирования ремонтного фонда.

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

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

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

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