Предпосылки к сотрудничеству
Заказчик хотел снизить производственные потери, основной причиной которых были сбои в работе и поломки оборудования. Компании требовалось решение, которое позволило бы выявлять и устранять признаки неисправностей на ранней стадии.
Клиент обратился к нам с идеей создания полнофункциональной платформы для профилактического обслуживания. Решение должно было оптимизировать критически важные производственные процессы по следующим направлениям:
- Сокращение времени простоя и финансовых потерь, связанных с поломками и сбоями оборудования;
- Снижение простоев, вызванных плановыми ремонтными работами;
- Минимизация затрат на техническое обслуживание;
- Обеспечение безопасности и охраны труда.
Что предстояло сделать
На этапе анализа мы поняли, что новое решение не получится «надстроить» поверх старой системы — они просто не совместимы. Поэтому оптимальным выходом стала миграция данных со старой ERP-системы на ее современную версию, которую мы решили доработать и дополнить функцией профилактического обслуживания.
Для этого нам необходимо было решить ряд задач:
Миграция и синхронизация данных между двумя системами
При переходе от устаревшего «типового» решения к индивидуально разработанной системе было важно сохранить все критически важные данные клиента. Нужно было перенести в новую структуру базы данных архив за пять лет и одновременно внедрить новую функциональность в платформу.
Повышение производительности
Из-за ограниченной производительности устаревшей системы было невозможно внедрить функцию прогнозного обслуживания, которая позволила бы клиенту обрабатывать большие объемы данных о состоянии оборудования, поступающих одновременно с множества машин.
Методология и подход
Для работы на этом проекте мы выбрали гибкий подход к управлению по методологии Agile. При выборе мы руководствовались следующими причинами:
- Меняющиеся требования: мы работали в динамичных условиях, согласовывая действия с клиентом на любом этапе разработки. Так как процесс миграции связан с трудностями и скрытыми подводными камнями, предугадать которые заранее невозможно, мы регулярно сообщали о статусе проекта, чтобы своевременно корректировать планы.
- Локдаун и удаленная работа: реализация проекта пришлась на период глобальной пандемии, что потребовало организации удаленного взаимодействия между нашей командой и заказчиком.
В соответствии с подходом Agile мы разбили процесс разработки на двухнедельные спринты и по завершении каждого из них предоставляли отчеты о проделанной работе. Дополнительно каждую неделю мы синхронизировались с клиентом по статусу проекта. Благодаря такому прозрачному формату коммуникации нам удавалось оперативно решать возникающие проблемы и гибко адаптировать требования клиента к новой архитектуре данных.
В результате мы оптимизировали процесс разработки и в сжатые сроки представили готовое к выходу на рынок решение.
Обслуживание, ориентированное на надежность (RCM)
Клиент обратился к нам с идеей реализации решения на основе подхода RCM (Reliability-Centered Maintenance). Это методика технического обслуживания, направленная на повышение надежности оборудования, снижение простоев и сокращение необходимости в замене основных активов.
RCM основывается на нескольких ключевых принципах:
Обеспечение работоспособности оборудования
Главная цель — поддерживать активы в рабочем состоянии, чтобы они эффективно выполняли свои функции.
Идентификация сценариев отказов
Определение возможных причин, по которым оборудование может выйти из строя — как полностью, так и частично.
Анализ видов и последствий отказов
Анализ потенциальных причин сбоев, оценка их последствий и ранжирование по степени серьезности и общему риску.
Приоритизация обслуживания на основе рисков
Определение приоритетов технического обслуживания с учетом рисков, связанных с отказами оборудования, включая аспекты безопасности, воздействия на окружающую среду и влияние на производственные процессы.
Выбор оптимальной стратегии обслуживания
Принятие решений о наиболее подходящей стратегии — будь то профилактическое, предиктивное, регламентированное или корректирующее обслуживание — в зависимости от выявленных рисков отказов.
Постоянное улучшение
Регулярная переоценка и корректировка стратегий технического обслуживания по мере появления новых данных и информации.
Мы планировали разработать программное обеспечение, которое позволило бы клиенту формировать планы технического обслуживания оборудования по принципам RCM. Процесс состоял из следующих шагов:
1. Создание каталога оборудования с разбивкой на отдельные единицы
Каждой единице мы присваивали уровень критичности, рассчитанный на основе заранее определенных критериев.
2. Разработка стратегии обслуживания для каждой единицы
Стратегия представляла собой последовательность действий, необходимых для поддержания оборудования в рабочем состоянии. Каждое действие было направлено либо на снижение вероятности отказа, либо на уменьшение последствий в случае его наступления.
3. Формирование технологической карты
Технологическая карта содержала пошаговую инструкцию по обслуживанию конкретной единицы. Соблюдение этой инструкции позволяло снизить риски возникновения негативных событий.
4. Составление плана технического обслуживания
Из технологической карты мы брали перечень действий и необходимых ресурсов, а затем превращали его в задания для ремонтного персонала.
5. Выполнение работ в соответствии с выбранной стратегией и контроль их качества
Если работы выполнялись некачественно или выявлялись неисправности, исполнитель фиксировал это для последующего анализа.
6. Сбор статистики по неисправностям и анализ их корневых причин
При необходимости вносились корректировки в стратегии обслуживания.
Матрица рисков
Мы разработали матрицу, в которой все риски были распределены по уровням критичности. Затем провели анализ приоритетов, определив, какие стратегии обслуживания необходимо применять в разных условиях и режимах эксплуатации. После этого протестировали различные сценарии, чтобы подобрать оптимальную стратегию для каждого уровня риска.
MVP
На этом этапе мы создали базовые таблицы в Microsoft Excel и разработали в них планы ремонтов и осмотров. Несмотря на простоту такого подхода к управлению задачами, он дал впечатляющие результаты: мы выявили избыточные операции, которые не снижали риск отказов, и исключили их. Также нам удалось повысить качество стратегий обслуживания, что привело к сокращению числа аварий и снижению затрат на техобслуживание.
Решение
В установленный срок мы представили полнофункциональную платформу для профилактического обслуживания.
Полный цикл предиктивного обслуживания
На основе подхода RCM мы разработали следующие решения, ставшие частью новой платформы:
Инструменты интеллектуальной оценки рисков
Новая платформа позволяла удобно отслеживать все выявленные риски на основе заранее заданных критериев.
Во время внутренних мозговых сессий мы расставили приоритеты, сосредоточившись на самых критичных рисках и ключевых единицах оборудования. На этом этапе мы активно опирались на данные о прошлых сбоях — уведомления, сигналы и сообщения, собранные из старой системы клиента.
Каждую единицу мы оценивали по четырем основным критериям: безопасность работы, влияние на окружающую среду, качество продукции и финансовые риски — именно они легли в основу нашей матрицы рисков.
Для примера можно рассмотреть вагонопрокидыватель. Если заклинивает один из опорных роликов, это снижает производительность, но не приводит к аварии. А вот разрушение подшипника на роторе — это уже аварийная остановка на длительное время и большие расходы на замену.
После анализа мы сформировали рекомендации, как избежать или смягчить выявленные риски.
Дашборды для мониторинга производительности в реальном времени
Мы разработали дашборды, которые позволяли операторам оценивать потенциальные финансовые потери при наступлении того или иного риска, а также затраты на его предотвращение.
На основе ранее сформированных рекомендаций наша команда создала стратегии профилактического обслуживания для каждого выявленного риска.
Например, разрушение подшипникового узла из-за механического износа — это негативное событие. Чтобы его избежать, оператор должен регулярно смазывать подшипник. Для этого необходимо остановить оборудование, задействовать двух инженеров и использовать 0,5 кг смазки. Такая операция может занять до двух часов.
При этом подобные задачи, как правило, были периодическими: например, смазка подшипника — раз в месяц, осмотр узла — раз в год.
Все стратегии имели версионность: их можно было улучшать, пересматривать или адаптировать, если оператор находил более эффективные или экономичные методы обслуживания, либо изменялись условия эксплуатации конкретного оборудования.
Реализация стратегий
Мы настроили систему создания заданий (ордеров) в планировщике платформы, чтобы обеспечить выполнение разработанных стратегий обслуживания. Например, если оператору нужно было ежемесячно менять смазку в механизмах, он мог назначить повторяющееся задание на ответственную команду или подразделение.
Для каждого задания мы указывали всю необходимую информацию:
- Объем работ (например, проверка подшипников и их смазка);
- Материалы (например, закупка 0,5 кг смазки);
- Инструменты (например, гаечные ключи и прочее), необходимые для выполнения задачи.
Анализ первопричин отказов
Мы исследовали случаи сбоев и поломок, определяя и фиксируя их корневые причины. Например, выходит из строя двигатель. Благодаря реализованной нами визуализации причинно-следственных связей в формате mind map — по аналогии с Miro — можно было наглядно определить исходную причину проблемы. Как и в Miro, пользователи могли совместно работать с картой: добавлять элементы, комментировать и структурировать информацию. Такой формат сделал мозговой штурм более эффективным и позволил быстрее разрабатывать меры по предотвращению повторных сбоев.
Гибко настраиваемое управление доступом и ролями
Чтобы обеспечить высокий уровень безопасности критически важных данных на платформе, мы внедрили инструмент управления доступом Microsoft Azure Identity Access Management и адаптировали его под требования и внутренние процедуры клиента.
Наша команда реализовала сложную, гибко настраиваемую логику распределения прав доступа с учетом ролей и разрешений, создав настраиваемую систему, основанную на ролевой модели. В первую очередь были определены роли в зависимости от должностей сотрудников, которым требовался доступ к системе:
- Инженер по надежности;
- Главный специалист по надежности, специалист по надежности, специалист по рекомендациям;
- Координатор КИВ, наблюдатель КИВ, специалист по рекомендациям КИВ;
- Руководитель отдела, менеджер по планированию, участники рабочей группы.
Администратор платформы мог создавать индивидуальные роли для пользователей с расширенными правами. Например, роли с возможностью утверждать рекомендации или роли с доступом только к определенным отделам и связанным с ними инцидентам оборудования. Таким образом можно было выстроить полноценную иерархию ролей:
Компания → Производственная площадка → Отдел → Рабочая зона → Оборудование → Детали оборудования
Когда пользователь с определенной ролью входил в систему, автоматически включалась фильтрация данных в соответствии с его правами и доступами. Например, он мог видеть всю информацию в пределах своего металлургического завода, но иметь право утверждать рекомендации только для конкретного оборудования в своей рабочей зоне.
Дополнительно пользователи могли группировать и фильтровать данные по настраиваемым критериям, таким как типы оборудования, инструменты обработки или время возникновения неисправности.
Каждая роль включала набор разрешений, и один пользователь мог иметь несколько ролей одновременно. Это особенно важно, когда необходимо временно заменить сотрудника, например, на период отпуска или больничного. В таких случаях каждому разрешению можно было задать срок действия.
Наконец, мы реализовали умную систему управления рекомендациями в зависимости от роли пользователя. Система автоматически определяла, кто должен утвердить тот или иной документ, исходя из роли, набора прав и привязанных производственных площадок или единиц оборудования.
Миграция на SAP S/4HANA
Параллельно с разработкой платформы мы провели миграцию данных клиента с устаревшей системы на SAP S/4HANA и интегрировали в нее новый функционал. В частности, мы перенесли каталог оборудования со всеми интеграциями, связями и зависимостями. Также были запущены проекты миграции SAP MRS и Work Manager, благодаря чему все процессы технического обслуживания были централизованы в единой информационной системе.
Почему именно SAP S/4HANA?
Эта платформа позволила нам автоматизировать все необходимые процессы внутри предприятия, снизить зависимость от человеческого фактора, повысить скорость производства и, в конечном счете, повысить удовлетворенность заказчика и увеличить прибыль.
Однако решение о выборе SAP S/4HANA было принято и по ряду более специфических причин:
- Устаревшая версия SAP ERP. На момент миграции клиент использовал SAP ECC 6.0. Однако разработка этой системы уже была остановлена, а к 2027 году официальная поддержка и вовсе прекратится. Да, формально оставалось еще время, но оно было необходимо для полноценного развертывания и оптимизации новой системы (что мы продолжаем делать и сейчас).
- Функциональная несовместимость. Планируемые нами улучшения, доработки и кастомизации могли либо не поддерживаться старой системой, либо значительно замедлить ее работу.
- Сильная зависимость от нестандартного кода. В SAP S/4HANA мы стремились сократить использование кастомных решений, чтобы ускорить вывод новых функций и упростить сопровождение системы.
- Ограниченные возможности масштабирования. Устаревшая система клиента не справлялась с растущими объемами производства. Перенос на облачную инфраструктуру SAP S/4HANA открыл широкие возможности масштабирования и развития.
Новая архитектура данных
При разработке новой архитектуры данных нашей целью было обеспечить высокое удобство использования и упростить развертывание системы. В итоге мы выстроили следующий рабочий процесс: пользователь работал через браузер, проходил аутентификацию через Active Directory и получал уведомления о важных событиях по электронной почте.
Данные информационной системы хранились в реляционной СУБД, которая была интегрирована с ERP-системой. Это позволяло получать справочники и передавать стратегии обслуживания для исполнения, а также формировать отчеты в SAP Business Warehouse (SAP BW).
Дополнительно мы реализовали двустороннюю интеграцию с SAP ERP, благодаря чему данные передавались в режиме реального времени в обоих направлениях. Пользователи могли как забирать информацию из SAP для аналитики, так и отправлять в нее свои вводные данные.
Технологический стек
- ERP — S/4HANA
- Управление данными — OracleDB
- Клиентская часть — JavaScript, ReactJS
- Серверная часть — Java
- Управление доменами — Microsoft Active Directory
- Управление аутентификациями — Kerberos SSO
- Разработка и развертывание — Docker, Kubernetes
Результаты
Интеграция функции предиктивного обслуживания в новую платформу клиента позволила достичь значимых результатов:
- Система обеспечила непрерывный контроль качества работы оборудования и диагностику его состояния. Это позволило отслеживать тенденции, прогнозировать возможные отказы и предотвращать их заранее. Благодаря этому удалось сократить затраты на повторное техобслуживание и более эффективно планировать поставки запчастей;
- Миграция на SAP S/4HANA значительно расширила функциональность платформы. Например, при анализе критичности теперь учитывается не только стоимость часа простоя оборудования, но и затраты на материалы для ремонта и оплату труда сотрудников. Также при формировании списка потенциальных отказов система автоматически использовала исторические данные;
- Снижение затрат на ремонты на 40% и повышение надежности оборудования на 3% благодаря полному контролю рисков и точной, основанной на данных оценке стоимости ремонтов;
- Годовое планирование обслуживания и ремонтных процессов теперь строится на объективных данных, что позволило добиться высокой финансовой эффективности.
- Повышение производительности платформы. Теперь чтение данных занимает менее 1 секунды. Сохранение и редактирование — до 3 секунд. Обработка больших объемов данных: выполнение основного действия в стратегии обслуживания — до 3 секунд. Остальные действия выполняются асинхронно.
- Обеспечены масштабируемость и широкое использование. На текущий момент:
- 1000+ пользователей в пяти компаниях клиента;
- 1,5 млн объектов добавлено в каталог оборудования;
- 20 000 стратегий обслуживания разработано;
- 140 000 технологических карт создано;
- 400 000 действий выполнено.
Эти достижения показывают, что переход на предиктивное обслуживание не только повысил эффективность работы предприятия, но и заложил основу для дальнейшего развития и масштабирования.