Как мы оцифровали обходы. Часть 1: пилот и чек-листы

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

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

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

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

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

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

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

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

Работник на обходе со взрывозащищённым смартфоном
Работник на обходе со взрывозащищённым смартфоном

Обходы: пилотная версия

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

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

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

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

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

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

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

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

Метки в интерфейсе
Метки в интерфейсе

Чек-листы

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

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

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

  • Неудобно переписывать на бумагу, когда стоишь на открытой установке на высоте двухэтажного дома. В минус сорок. И ночью;

  • Пока шёл до операторной, отвлекли, и забыл вовремя передать инфу;

  • Увидел пустяковый дефект и устранил его сам. И решил никому не говорить;

  • Или проблему устранила ремонтная служба, но информацию всё равно нигде не отразили – «а зачем, всё же работает».

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

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

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

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

И снова о данных

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

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

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

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

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

На этом пора говорить “To be continued” J В следующей части мы расскажем, как оцифровали тонны бумаг, объединили push-уведомления и подписи распоряжений в один процесс и начали делать цифрового помощника для проведения ремонтов.

И по традиции, мы всегда рады вашим вопросам. До встречи в следующей части!

Источник: https://habr.com/ru/company/sibur_official/blog/589153/


Интересные статьи

Интересные статьи

Специально для тех, кто любит хорошее кино и качественный звук, мы подготовили подборку фильмов, в которых можно увидеть первоклассную Hi-Fi и High End аппаратуру. Самые интересные модели проигрывател...
Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование Как стать DevOps инженер...
Всем привет. Я решил наконец-то разобраться, как работает интерпретатор Python. Для этого стал изучать одну статью-книгу и задумал заодно перевести её на русский язык. Дело в том, что перевод...
Исторически утилиты командной строки в Unix-системах развиты лучше чем в Windows, однако с появлением нового решения ситуация изменилась. Windows PowerShell позволяет системным администраторам...
И снова здравствуйте. Это продолжение статьи про организацию студенческого хакатона. В этот раз расскажу про проблемы появляющиеся прямо во время хакатона и как мы их решали, локальные ивенты ко...