И снова здравствуйте! Это Анна Хархурина, владелец продукта «Мобильные обходы и ремонты», и я продолжаю рассказывать об оцифровке процессов, связанных с техобслуживанием и ремонтом на производстве.

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

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

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

Задача оказалась гораздо сложнее: внутри каждого завода, производства и даже каждой установки работают по разным технологиям и режимам. У каждого свой особенный конечный продукт. А ещё у всех 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+ в месяц. Нагрузка на сервисы, конечно, тоже возросла, как и наши требования к качеству кода. Так как при растущей нагрузке стабильность сервиса может проседать, мы стали уделять больше внимания написанию автотестов и дополнительным мониторингам.

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

Как мы оцифровали обходы. Часть 2: журналы и ремонты