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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чек-листы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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