Хабр 0 комментариев

СИБУР: Как мы оцифровали обходы и ремонты

Сегодня мы расскажем вам, как цифровизация работает в процессах технического обслуживания. И причём здесь смартфоны :)

Автор: Анна Хархурина, я владелец продукта «Мобильные обходы и ремонты»

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

Вы понимаете, что для того, чтобы машина работала лучше и служила дольше, вам надо следить за ней, вовремя реагировать на какие-либо отклонения, не нарушать правила эксплуатации, а самое главное – делать это всё своевременно, чтобы чувствовать себя за рулем уверенно и безопасно.

У нас в СИБУРе похожая ситуация. Сегодня мы расскажем вам, как цифровизация работает в процессах технического обслуживания. И причём здесь смартфоны :)

Все самое интересное и уникальное мы публикуем в альманахе «Управление производством». 300+ мощных кейсов, готовых к использованию чек-листов и других полезных материалов ждут вас в полном комплекте номеров. Оформляйте подписку и получайте самое лучшее!

ПРО ОБХОДЫ

На заводах СИБУРа в каждый момент времени работают тысячи единиц оборудования – так производственный процесс не прерывается. Причём это оборудование разного класса опасности, в том числе и повышенного.

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

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

Обходы совершаются с определенной частотой в смену, в зависимости от критичности работы оборудования. И по определенному маршруту. Раньше весь процесс полностью был в оффлайне – обходчик вооружался блокнотом и ручкой, и в любую погоду шёл по маршруту, фиксируя замечания. Карандашом на бумаге – и в дождь, и в снег. По возвращении в операторную работник передавал этот блокнот, чтобы старший по смене зарегистрировал информацию.

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

ПИЛОТНАЯ ВЕРСИЯ

Наш MVP состоял из web-интерфейса и мобильного приложения. Он предоставлял полную информацию о количестве и качестве обходов. И вот, как:

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

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

Но как проверить, что обходчик на самом деле был на точке?

Мы решили добавить чекины по NFC-метке – заранее подготовили инфраструктуру, развесили метки и прошили их с записью единиц оборудования, которые требовали осмотра.

Так выглядит чекин

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

ЧЕК-ЛИСТЫ

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

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

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

  • Неудобно переписывать на бумагу, когда стоишь на открытой установке на высоте двухэтажного дома. В минус сорок. И ночью;
  • Пока шёл до операторной, отвлекли, и забыл вовремя передать инфу;
  • Увидел пустяковый дефект и устранил его сам. И решил никому не говорить;
  • Или проблему устранила ремонтная служба, но информацию всё равно нигде не отразили – «а зачем, всё же работает».

Так, конечно, не пойдёт.

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

Когда мы проектировали эти возможности, упор делали на простоту и удобство работы, чтобы количество обращений к интерфейсу было минимальным. При этом мы не забывали о минимальном наборе данных, который требуется для фиксации дефекта – здесь количество кликов или тапов может быть прямо-таки жизненно важным.

В итоге мы выстроили взаимодействие с интерфейсом так, чтобы с ним можно было работать не только с помощью тапов, но и при помощи боковых кнопок или голосового набора. Всё ради того, чтобы руки работников оставались в тепле!

И О ДАННЫХ

Когда мы выкатили эту фичу, она и правда хорошо и быстро прижилась. И к нам полился огромный поток данных. На некоторых предприятиях объём зафиксированных дефектов увеличился до 400%, но вовсе не потому, что внезапно все стало ломаться – просто мы достигли той самой прозрачности, когда фиксируется любое, даже мельчайшее отклонение.

Чтобы визуализировать такой объём информации мы обратились к коллегам из управления корпоративными данными. Они собрали аналитические дашборды, на которые можно было взглянуть и понять, что делать и как управлять данными дальше.

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

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

После того, как мы стали фиксировать дефекты и выводить информацию на дашборды, у нас, помимо производства, появился еще один внутренний заказчик. Это служба управления надежностью, которая как раз отвечает за стратегии техобслуживания. Сейчас мы с ними прорабатываем новые процессы и возможности развития продукта. Впереди интересный вызов – как не только получать и анализировать данные, но и быстро корректировать стратегию. И исполнять её, сокращая при этом внеплановые поломки и издержки на ремонт.  

СМЕННЫЕ ЖУРНАЛЫ

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

Так как с «Мобильными обходами» мы начали оцифровывать процессы сразу по нескольким ролям – оператора, диспетчера и начальника смены – то решили не останавливаться на обходах и дефектах. Ведь журналы смен ведут те же самые люди. 

Первую версию электронного журнала мы сделали одинаковой для всех предприятий. За что оперативно словили волну оправданного негатива от коллег. 

Задача оказалась гораздо сложнее: внутри каждого завода, производства и даже каждой установки работают по разным технологиям и режимам. У каждого свой особенный конечный продукт. А ещё у всех 20 с лишним предприятий, на которых работает наш продукт, есть своя иерархия и количество участников, которые вносят записи в журнал. Плюс разные структуры и верификация этих записей.

Оправданный негатив сопровождался требованием вносить данные в один журнал сразу несколькими пользователями и соблюдать преемственность при приёме и передаче от смены к смене. 

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

Всё это помогло нам уйти от тонн бумаг (а бумаги на самом деле копилось МНОГО), наладить интеграции этого журнала с различными источниками данных и сократить трудозатраты на ведении бумажных аналогов. 

РАСПОРЯЖЕНИЯ

Следующий процесс, который мы решили оптимизировать – выдача распоряжений. Это своего рода таски на производстве. Задания могут быть как для ознакомления (к примеру, информирование о правилах ношения СИЗ), так и для исполнения. К примеру, те же самые отклонения, которые обнаруживают обходчики. Если это возможно устранить своими силами, то начальник смены может создать такое распоряжение на того же обходчика. Выглядеть это будет так:

  1. Обходчик проводит осмотр;
  2. Фиксирует в приложении найденные дефекты;
  3. Начальник смены в режиме реального времени видит дефект в интерфейсе;
  4. Принимает решение и ставит обходчику дополнительную задачу;
  5. Обходчику приходит push-уведомление о том, что можно здесь и сейчас сделать своими силами;
  6. Обходчик выполняет задачу и отмечает это в приложении;
  7. Начальник смены видит актуальный статус распоряжения;
  8. Готово, все справились!

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

МОБИЛЬНЫЕ РЕМОНТЫ

Итак, мы получили картину по обходам в реальном времени, с огромным потоком данных по дефектам, добились их фиксации и отражения. А что насчёт устранения дефектов?

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

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

У нас в компании при планировании ремонта используются нормативы, в которых прописаны: какие нужны материалы, сколько потребуется человек, какие им необходимо выполнять операции, даже сколько времени потребуется на каждую операцию – всё это складывается в затраты. При планировании ремонтных работ ориентируются как раз на затраты из этих нормативов.

Чтобы подтвердить и, если нужно, скорректировать такие нормативы мы начали с инструмента для измерения фактических трудозатрат. Пошли короткими итерациями: сначала мы попросили коллег указывать фактическое время начала и окончания по каждой операции и количеству исполнителей. Почти как в плеере с кнопками «старт/стоп», но только на операциях. Дальше, перед тем как менять процессы и поставлять новые, нам потребовалось поменять организационный дизайн, и мы ввели новые роли. К примеру, у нас появилась роль супервайзера с отдельным KPI. 

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

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

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

Собственно, это и есть текущая фаза развития продукта. Дальше – больше! Мы принципиально против подхода, когда все работает «из коробки», ведь практически каждое изменение продукта подразумевает под собой тонны изменений в процессе и наоборот. Без оттачивания этих изменений никакой цифровой продукт не даст никакой дополнительной ценности. Так что мы продолжим усердно работать и рассказывать вам об этом :)

СКАЧАТЬ: Специальный выпуск «Цифровое производство: сегодня и завтра российской промышленности»

КОМАНДА И ПРОЦЕССЫ

И для обходов, и для ремонтов мы используем один стек и микросервисную архитектуру. Сейчас в продуктовой команде 12 человек: 

  • 2 бэкендера;
  • 2 фронтендера;
  • 2 тестировщика;
  • 2 Android-разработчика;  
  • 1 аналитик;
  • 1 дизайнер;
  • 1 скрам-мастер;
  • 1 владелец продукта.

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

Отдельная фишка — это тираж нашего продукта. Мы разворачивали обходы и ремонты постепенно, начиная с установки на одном заводе. Сейчас мы работаем уже на более 20 предприятиях. Чтобы всякий раз не отвлекать команду разработки на тираж, мы спроектировали и разработали Self-Service: когда к системе подключается новый завод, команда внедрения с помощью раздела администрирования может самостоятельно прописать все необходимые маршруты, добавить пользователей и выдать им нужные роли, не привлекая ни одного разработчика. 

Это позволяет нам двигаться в развитие функционала и не тратить ресурсы на тираж. А ещё у нас есть выделенная линия поддержки, которая отдельно занимается вопросами и проблемами цифровых продуктов. 

ОБРАТНАЯ СВЯЗЬ И ПЛАНЫ

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

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

Все макеты, которые мы берём в разработку, обязательно проходят через серию юзабилити-тестов с пользователями. Да и вообще, выезды в «поля» очень помогают учитывать контекст – как, где и кто использует твой продукт в реальной жизни. 

С момента запуска MVP «Мобильных обходов» прошло уже полтора года, а количество наших активных пользователей выросло до 7 000+ в месяц. Нагрузка на сервисы, конечно, тоже возросла, как и наши требования к качеству кода. Так как при растущей нагрузке стабильность сервиса может проседать, мы стали уделять больше внимания написанию автотестов и дополнительным мониторингам.

А ещё радует, что в процессе развития продуктов мы начинаем предоставлять их не только СИБУРу и нашим же заводам, но и совместным предприятиям с другими крупными компаниями. В общем, нам есть куда расти :) 

0 комментариев
Отправить
обсуждения
Здесь больше организационных вопросв, чем в самой платформе. Можно взять за основу Фабрику идей у Ев... СУМЗ: «Фабрика идей» и «Доска решения проблем» переходят на цифровую платформу
Белоярская АЭС принимает группы студентов, они могут быть и старше 18 лет. Но в целом да, в настояще... Туризм на АЭС: не развлечение, но просвещение
Отличный пример цифровизации или "умной фабрики", коллеги! А можете поделиться платформой ... СУМЗ: «Фабрика идей» и «Доска решения проблем» переходят на цифровую платформу
Узнайте больше Альманах “Управление производством” 300+ мощных кейсов, готовых к использованию чек-листов и других полезных материалов
Альманах “Управление производством”