Сегодня мы расскажем вам, как цифровизация работает в процессах технического обслуживания. И причём здесь смартфоны :)
Автор: Анна Хархурина, я владелец продукта «Мобильные обходы и ремонты»
Вы понимаете, что для того, чтобы машина работала лучше и служила дольше, вам надо следить за ней, вовремя реагировать на какие-либо отклонения, не нарушать правила эксплуатации, а самое главное – делать это всё своевременно, чтобы чувствовать себя за рулем уверенно и безопасно.
У нас в СИБУРе похожая ситуация. Сегодня мы расскажем вам, как цифровизация работает в процессах технического обслуживания. И причём здесь смартфоны :)
Все самое интересное и уникальное мы публикуем в альманахе «Управление производством». 300+ мощных кейсов, готовых к использованию чек-листов и других полезных материалов ждут вас в полном комплекте номеров. Оформляйте подписку и получайте самое лучшее!
На заводах СИБУРа в каждый момент времени работают тысячи единиц оборудования – так производственный процесс не прерывается. Причём это оборудование разного класса опасности, в том числе и повышенного.
Чтобы предприятия работали в штатном режиме, на них не случалось аварий, а продукция выпускалась по плану, нужно своевременно контролировать работу оборудования, обслуживать и при необходимости привлекать ремонтное подразделение. Для этого на предприятиях существуют обходы.
Во время обхода работники следят за исправностью оборудования и показателями приборов, выявляют неисправности и либо устраняют их на месте (если задача не сложная), либо регистрируют проблему и привлекают ремонтные службы.
Обходы совершаются с определенной частотой в смену, в зависимости от критичности работы оборудования. И по определенному маршруту. Раньше весь процесс полностью был в оффлайне – обходчик вооружался блокнотом и ручкой, и в любую погоду шёл по маршруту, фиксируя замечания. Карандашом на бумаге – и в дождь, и в снег. По возвращении в операторную работник передавал этот блокнот, чтобы старший по смене зарегистрировал информацию.
Отслеживать обход было невозможно, а соответственно и знать наверняка, что его совершили вовремя и в полной мере. Так появилась потребность в оцифровке процесса, и мы разработали продукт «Мобильные обходы». Он позволяет убедиться, действительно ли обходчик в нужное время был возле нужного оборудования, на самом ли деле он провел требуемые проверки, и все ли выявленные отклонения он зафиксировал.
Наш MVP состоял из web-интерфейса и мобильного приложения. Он предоставлял полную информацию о количестве и качестве обходов. И вот, как:
Первые данные мы запрашивали от предприятий в формате Excel, а потом руками загружали в систему, чтобы у пользователей в web-интерфейсе была информация для работы.
Там же можно было создавать маршруты, назначать их периодичность и наполнять теми единицами оборудования, которые следовало осмотреть. В мобильное приложение уже приходили маршруты-задания для исполнения.
Но как проверить, что обходчик на самом деле был на точке?
Мы решили добавить чекины по NFC-метке – заранее подготовили инфраструктуру, развесили метки и прошили их с записью единиц оборудования, которые требовали осмотра.
Куда именно вешать метки, какие включать единицы оборудования, и какие маршруты формировать, нам подсказывали коллеги с завода. Они лучше знают правила по эксплуатации оборудования, плюс у них богатый личный опыт и экспертиза.
В процессе обхода, разумеется, важно не только зачекиниться, но и зафиксировать отклонения и дефекты. Чем раньше мы найдем дефект и устраним его, тем лучше и безопаснее будет работать производство. Поэтому мы внедрили чек-листы для осмотра оборудования.
Для каждой группы оборудования есть рекомендации, на что особенно важно обратить внимание. Не просто осмотреть в духе «Ну выглядит норм», а проверить уровень масла, снять показания датчика давления и проверить рукой температуру на предмет перегрева корпуса (кстати, сейчас это делают наши датчики интернета вещей), и др. Для удобства обходчиков мы показываем список сразу в момент чекина, чтобы вся нужная информация была под рукой и в быстром доступе. Это заметно повышает качество осмотра.
Дефекты на производстве выявляли и без нашего продукта, но картина была далеко не полной. По многим причинам. Вот пара примеров:
Так, конечно, не пойдёт.
Когда мы делали функционал фиксации дефектов, мы в первую очередь шли от проблемы дискомфорта: чтобы люди пользовались продуктом, важно учитывать контекст обхода и условия работы обходчика. От внешних погодных условий до экипировки – в сибирскую зиму, например, перчатки лучше не снимать.
Когда мы проектировали эти возможности, упор делали на простоту и удобство работы, чтобы количество обращений к интерфейсу было минимальным. При этом мы не забывали о минимальном наборе данных, который требуется для фиксации дефекта – здесь количество кликов или тапов может быть прямо-таки жизненно важным.
В итоге мы выстроили взаимодействие с интерфейсом так, чтобы с ним можно было работать не только с помощью тапов, но и при помощи боковых кнопок или голосового набора. Всё ради того, чтобы руки работников оставались в тепле!
Когда мы выкатили эту фичу, она и правда хорошо и быстро прижилась. И к нам полился огромный поток данных. На некоторых предприятиях объём зафиксированных дефектов увеличился до 400%, но вовсе не потому, что внезапно все стало ломаться – просто мы достигли той самой прозрачности, когда фиксируется любое, даже мельчайшее отклонение.
Чтобы визуализировать такой объём информации мы обратились к коллегам из управления корпоративными данными. Они собрали аналитические дашборды, на которые можно было взглянуть и понять, что делать и как управлять данными дальше.
Информация о дефекте нужна не только для того, чтобы о нём не забыть и вовремя направить ремонтников на устранение. Порой ещё и нужно корректировать стратегию обслуживания оборудования. Информация об условиях эксплуатации и периодичности определённых дефектов на разных видах оборудования позволяет предотвращать и не допускать поломки на схожем оборудовании.
Накапливая эти знания, мы можем строить стратегию ремонта и обслуживания, при этом опираясь не только на рекомендации и опыт, но и на реальные данные. Причём данные, которые полностью релевантны для наших производств и технологий.
После того, как мы стали фиксировать дефекты и выводить информацию на дашборды, у нас, помимо производства, появился еще один внутренний заказчик. Это служба управления надежностью, которая как раз отвечает за стратегии техобслуживания. Сейчас мы с ними прорабатываем новые процессы и возможности развития продукта. Впереди интересный вызов – как не только получать и анализировать данные, но и быстро корректировать стратегию. И исполнять её, сокращая при этом внеплановые поломки и издержки на ремонт.
На производствах есть обязательные для ведения документы, «Сменные журналы». По сути, это логи производства. В них фиксируются все события, произошедшие за смену — кто сегодня в составе, когда смена началась и закончилась, что происходило, как менялся технологический режим, что отдали в ремонт, что вывели из ремонта, где переключили резерв, и др. В общем, максимально подробно.
Так как с «Мобильными обходами» мы начали оцифровывать процессы сразу по нескольким ролям – оператора, диспетчера и начальника смены – то решили не останавливаться на обходах и дефектах. Ведь журналы смен ведут те же самые люди.
Задача оказалась гораздо сложнее: внутри каждого завода, производства и даже каждой установки работают по разным технологиям и режимам. У каждого свой особенный конечный продукт. А ещё у всех 20 с лишним предприятий, на которых работает наш продукт, есть своя иерархия и количество участников, которые вносят записи в журнал. Плюс разные структуры и верификация этих записей.
Оправданный негатив сопровождался требованием вносить данные в один журнал сразу несколькими пользователями и соблюдать преемственность при приёме и передаче от смены к смене.
Мы сделали конструктор, который можно приспособить непосредственно под свои нужды: выстраивать необходимые иерархии и вести записи в табличном или текстовом виде. Или и в том, и другом. Также мы прикрутили к компонентам редакторы для удобства работы, возможность переноса данных от смены к смене, настроили автоматическое предзаполнение информации из систем и добавили электронную подпись. Благо, теперь законодательство это позволяет.
Всё это помогло нам уйти от тонн бумаг (а бумаги на самом деле копилось МНОГО), наладить интеграции этого журнала с различными источниками данных и сократить трудозатраты на ведении бумажных аналогов.
Следующий процесс, который мы решили оптимизировать – выдача распоряжений. Это своего рода таски на производстве. Задания могут быть как для ознакомления (к примеру, информирование о правилах ношения СИЗ), так и для исполнения. К примеру, те же самые отклонения, которые обнаруживают обходчики. Если это возможно устранить своими силами, то начальник смены может создать такое распоряжение на того же обходчика. Выглядеть это будет так:
Ведение такого документа регламентируется, и оно обязательно по требованию надзорных органов. Поэтому мы также прикрутили электронную подпись, чтобы соблюсти форму документа и контролировать ответственность по его исполнению.
Итак, мы получили картину по обходам в реальном времени, с огромным потоком данных по дефектам, добились их фиксации и отражения. А что насчёт устранения дефектов?
Осмотры и ремонты тесно связаны, и в целом это части одного процесса под названием ТОиР —Технологическое обслуживание и Ремонт. Процесс всегда огромный и капиталоёмкий, причём на любом производственном предприятии.
Поэтому мы решили с помощью продукта «Мобильные ремонты» сделать прозрачными вообще все действия: от фиксации дефекта на оборудовании до его устранения, чтобы качественно управлять всем циклом процесса. И если фиксировать дефекты мы научились, то в части ремонта мы решили начать с получения фактической картины: как ремонты проводятся сейчас.
У нас в компании при планировании ремонта используются нормативы, в которых прописаны: какие нужны материалы, сколько потребуется человек, какие им необходимо выполнять операции, даже сколько времени потребуется на каждую операцию – всё это складывается в затраты. При планировании ремонтных работ ориентируются как раз на затраты из этих нормативов.
Чтобы подтвердить и, если нужно, скорректировать такие нормативы мы начали с инструмента для измерения фактических трудозатрат. Пошли короткими итерациями: сначала мы попросили коллег указывать фактическое время начала и окончания по каждой операции и количеству исполнителей. Почти как в плеере с кнопками «старт/стоп», но только на операциях. Дальше, перед тем как менять процессы и поставлять новые, нам потребовалось поменять организационный дизайн, и мы ввели новые роли. К примеру, у нас появилась роль супервайзера с отдельным KPI.
Запустив процесс, мы начали через дашборды внимательно анализировать, что происходит. Когда мы собрали информацию о реальных трудозатратах, мы увидели потенциал, где можно сократить нормативы и затраты компании, а где наоборот стоит планировать на ремонты больше времени или ресурсов. Но в целом, корректировка нормативов – процесс небыстрый, так как он требует большого количества исторических данных по ремонтам и их последующей аналитики.
Кстати, важно отметить: «Мобильные ремонты» – это не только инструмент контроля за исполнением ремонта, но и полезный помощник, который может показать планы на неделю вперёд, чтобы сотрудник мог лучше провести подготовку к ремонту, а во время самого ремонта – загрузить нужные чертежи и отобразить всю историю: что было раньше с оборудованием, какие детали и когда меняли, и др.
Оснащение сотрудников всеми необходимыми инструментами и информацией довольно сильно влияет на качество ремонта, а чем оно выше, тем дольше мы не будем делать ремонт повторно. И тем самым сэкономим деньги.
Собственно, это и есть текущая фаза развития продукта. Дальше – больше! Мы принципиально против подхода, когда все работает «из коробки», ведь практически каждое изменение продукта подразумевает под собой тонны изменений в процессе и наоборот. Без оттачивания этих изменений никакой цифровой продукт не даст никакой дополнительной ценности. Так что мы продолжим усердно работать и рассказывать вам об этом :)
СКАЧАТЬ: Специальный выпуск «Цифровое производство: сегодня и завтра российской промышленности»
И для обходов, и для ремонтов мы используем один стек и микросервисную архитектуру. Сейчас в продуктовой команде 12 человек:
Но кроме команды разработки на наших предприятиях работает распределённая команда по внедрению цифровых продуктов. Эта команда максимально приближена к технологиям на самом производстве – она отвечает за обучение конечных пользователей, внедрение цифрового продукта и его приживаемость (совокупность метрик использования).
Отдельная фишка — это тираж нашего продукта. Мы разворачивали обходы и ремонты постепенно, начиная с установки на одном заводе. Сейчас мы работаем уже на более 20 предприятиях. Чтобы всякий раз не отвлекать команду разработки на тираж, мы спроектировали и разработали Self-Service: когда к системе подключается новый завод, команда внедрения с помощью раздела администрирования может самостоятельно прописать все необходимые маршруты, добавить пользователей и выдать им нужные роли, не привлекая ни одного разработчика.
Это позволяет нам двигаться в развитие функционала и не тратить ресурсы на тираж. А ещё у нас есть выделенная линия поддержки, которая отдельно занимается вопросами и проблемами цифровых продуктов.
Дизайнеров и разработчиков впереди ждёт особый вызов: большая часть наших пользователей – это производственный персонал, который трудится «в полях». Им не нужно навороченное приложение с прикольными фичами, хотя иногда, конечно, нам самим хочется добавить красоты. Но гораздо большее внимание нужно уделять проектированию взаимодействия и изучению контекста использования.
Мы, например, можем пожертвовать размером кнопок в угоду эстетике, но очень скрупулёзно будем рассматривать сценарий с дополнительным кликом или тапом. Ведь с нашими цифровыми продуктами работают, в том числе, и в опасных производственных условиях, так что это всё имеет действительно важное значение.
Все макеты, которые мы берём в разработку, обязательно проходят через серию юзабилити-тестов с пользователями. Да и вообще, выезды в «поля» очень помогают учитывать контекст – как, где и кто использует твой продукт в реальной жизни.
С момента запуска MVP «Мобильных обходов» прошло уже полтора года, а количество наших активных пользователей выросло до 7 000+ в месяц. Нагрузка на сервисы, конечно, тоже возросла, как и наши требования к качеству кода. Так как при растущей нагрузке стабильность сервиса может проседать, мы стали уделять больше внимания написанию автотестов и дополнительным мониторингам.
А ещё радует, что в процессе развития продуктов мы начинаем предоставлять их не только СИБУРу и нашим же заводам, но и совместным предприятиям с другими крупными компаниями. В общем, нам есть куда расти :)
