И снова здравствуйте! Это Анна Хархурина, владелец продукта «Мобильные обходы и ремонты», и я продолжаю рассказывать об оцифровке процессов, связанных с техобслуживанием и ремонтом на производстве.
На производствах есть обязательные для ведения документы, «Сменные журналы». По сути, это логи производства. В них фиксируются все события, произошедшие за смену — кто сегодня в составе, когда смена началась и закончилась, что происходило, как менялся технологический режим, что отдали в ремонт, что вывели из ремонта, где переключили резерв, и др. В общем, максимально подробно.
Так как с «Мобильными обходами» мы начали оцифровывать процессы сразу по нескольким ролям – оператора, диспетчера и начальника смены – то решили не останавливаться на обходах и дефектах. Ведь журналы смен ведут те же самые люди.
![](https://webcf.waybackmachine.org/web/20220515115808/https://habrastorage.org/getpro/habr/upload_files/41e/ed2/aa0/41eed2aa0c098471da322e55fb841696.png)
Первую версию электронного журнала мы сделали одинаковой для всех предприятий. За что оперативно словили волну оправданного негатива от коллег.
Задача оказалась гораздо сложнее: внутри каждого завода, производства и даже каждой установки работают по разным технологиям и режимам. У каждого свой особенный конечный продукт. А ещё у всех 20 с лишним предприятий, на которых работает наш продукт, есть своя иерархия и количество участников, которые вносят записи в журнал. Плюс разные структуры и верификация этих записей.
Оправданный негатив сопровождался требованием вносить данные в один журнал сразу несколькими пользователями и соблюдать преемственность при приёме и передаче от смены к смене.
Мы сделали конструктор, который можно приспособить непосредственно под свои нужды: выстраивать необходимые иерархии и вести записи в табличном или текстовом виде. Или и в том, и другом. Также мы прикрутили к компонентам редакторы для удобства работы, возможность переноса данных от смены к смене, настроили автоматическое предзаполнение информации из систем и добавили электронную подпись. Благо, теперь законодательство это позволяет.
Всё это помогло нам уйти от тонн бумаг (а бумаги на самом деле копилось МНОГО), наладить интеграции этого журнала с различными источниками данных и сократить трудозатраты на ведении бумажных аналогов.
Распоряжения
Следующий процесс, который мы решили оптимизировать – выдача распоряжений. Это своего рода таски на производстве. Задания могут быть как для ознакомления (к примеру, информирование о правилах ношения СИЗ), так и для исполнения. К примеру, те же самые отклонения, которые обнаруживают обходчики. Если это возможно устранить своими силами, то начальник смены может создать такое распоряжение на того же обходчика. Выглядеть это будет так:
1. Обходчик проводит осмотр;
2. Фиксирует в приложении найденные дефекты;
3. Начальник смены в режиме реального времени видит дефект в интерфейсе;
4. Принимает решение и ставит обходчику дополнительную задачу;
5. Обходчику приходит push-уведомление о том, что можно здесь и сейчас сделать своими силами;
![](https://webcf.waybackmachine.org/web/20220515115808/https://habrastorage.org/getpro/habr/upload_files/9b7/689/e13/9b7689e13273d0019f6f79c31bfffa33.png)
6. Обходчик выполняет задачу и отмечает это в приложении;
7. Начальник смены видит актуальный статус распоряжения;
8. Готово, все справились!
Ведение такого документа регламентируется, и оно обязательно по требованию надзорных органов. Поэтому мы также прикрутили электронную подпись, чтобы соблюсти форму документа и контролировать ответственность по его исполнению.
Мобильные ремонты
Итак, мы получили картину по обходам в реальном времени, с огромным потоком данных по дефектам, добились их фиксации и отражения. А что насчёт устранения дефектов?
Осмотры и ремонты тесно связаны, и в целом это части одного процесса под названием ТОиР —Технологическое обслуживание и Ремонт. Процесс всегда огромный и капиталоёмкий, причём на любом производственном предприятии.
Поэтому мы решили с помощью продукта «Мобильные ремонты» сделать прозрачными вообще все действия: от фиксации дефекта на оборудовании до его устранения, чтобы качественно управлять всем циклом процесса. И если фиксировать дефекты мы научились, то в части ремонта мы решили начать с получения фактической картины: как ремонты проводятся сейчас.
![](https://webcf.waybackmachine.org/web/20220515115808/https://habrastorage.org/getpro/habr/upload_files/ea8/739/779/ea8739779be002d005642e8418ccd406.png)
У нас в компании при планировании ремонта используются нормативы, в которых прописаны: какие нужны материалы, сколько потребуется человек, какие им необходимо выполнять операции, даже сколько времени потребуется на каждую операцию – всё это складывается в затраты. При планировании ремонтных работ ориентируются как раз на затраты из этих нормативов.
Чтобы подтвердить и, если нужно, скорректировать такие нормативы мы начали с инструмента для измерения фактических трудозатрат. Пошли короткими итерациями: сначала мы попросили коллег указывать фактическое время начала и окончания по каждой операции и количеству исполнителей. Почти как в плеере с кнопками «старт/стоп», но только на операциях. Дальше, перед тем как менять процессы и поставлять новые, нам потребовалось поменять организационный дизайн, и мы ввели новые роли. К примеру, у нас появилась роль супервайзера с отдельным KPI.
Запустив процесс, мы начали через дашборды внимательно анализировать, что происходит. Когда мы собрали информацию о реальных трудозатратах, мы увидели потенциал, где можно сократить нормативы и затраты компании, а где наоборот стоит планировать на ремонты больше времени или ресурсов. Но в целом, корректировка нормативов – процесс небыстрый, так как он требует большого количества исторических данных по ремонтам и их последующей аналитики.
Кстати, важно отметить: «Мобильные ремонты» – это не только инструмент контроля за исполнением ремонта, но и полезный помощник, который может показать планы на неделю вперёд, чтобы сотрудник мог лучше провести подготовку к ремонту, а во время самого ремонта – загрузить нужные чертежи и отобразить всю историю: что было раньше с оборудованием, какие детали и когда меняли, и др.
Оснащение сотрудников всеми необходимыми инструментами и информацией довольно сильно влияет на качество ремонта, а чем оно выше, тем дольше мы не будем делать ремонт повторно. И тем самым сэкономим деньги.
Собственно, это и есть текущая фаза развития продукта. Дальше – больше! Мы принципиально против подхода, когда все работает «из коробки», ведь практически каждое изменение продукта подразумевает под собой тонны изменений в процессе и наоборот. Без оттачивания этих изменений никакой цифровой продукт не даст никакой дополнительной ценности. Так что мы продолжим усердно работать и рассказывать вам об этом :)
Команда и процессы
И для обходов, и для ремонтов мы используем один стек и микросервисную архитектуру. Сейчас в продуктовой команде 12 человек:
● 2 бэкендера;
● 2 фронтендера;
● 2 тестировщика;
● 2 Android-разработчика;
● 1 аналитик;
● 1 дизайнер;
● 1 скрам-мастер;
● 1 владелец продукта;
Но кроме команды разработки на наших предприятиях работает распределённая команда по внедрению цифровых продуктов. Эта команда максимально приближена к технологиям на самом производстве – она отвечает за обучение конечных пользователей, внедрение цифрового продукта и его приживаемость (совокупность метрик использования).
Отдельная фишка — это тираж нашего продукта. Мы разворачивали обходы и ремонты постепенно, начиная с установки на одном заводе. Сейчас мы работаем уже на более 20 предприятиях. Чтобы всякий раз не отвлекать команду разработки на тираж, мы спроектировали и разработали Self-Service: когда к системе подключается новый завод, команда внедрения с помощью раздела администрирования может самостоятельно прописать все необходимые маршруты, добавить пользователей и выдать им нужные роли, не привлекая ни одного разработчика.
Это позволяет нам двигаться в развитие функционала и не тратить ресурсы на тираж. А ещё у нас есть выделенная линия поддержки, которая отдельно занимается вопросами и проблемами цифровых продуктов.
Обратная связь и планы
Дизайнеров и разработчиков впереди ждёт особый вызов: большая часть наших пользователей – это производственный персонал, который трудится «в полях». Им не нужно навороченное приложение с прикольными фичами, хотя иногда, конечно, нам самим хочется добавить красоты. Но гораздо большее внимание нужно уделять проектированию взаимодействия и изучению контекста использования.
Мы, например, можем пожертвовать размером кнопок в угоду эстетике, но очень скрупулёзно будем рассматривать сценарий с дополнительным кликом или тапом. Ведь с нашими цифровыми продуктами работают, в том числе, и в опасных производственных условиях, так что это всё имеет действительно важное значение.
Все макеты, которые мы берём в разработку, обязательно проходят через серию юзабилити-тестов с пользователями. Да и вообще, выезды в «поля» очень помогают учитывать контекст – как, где и кто использует твой продукт в реальной жизни.
С момента запуска MVP «Мобильных обходов» прошло уже полтора года, а количество наших активных пользователей выросло до 7 000+ в месяц. Нагрузка на сервисы, конечно, тоже возросла, как и наши требования к качеству кода. Так как при растущей нагрузке стабильность сервиса может проседать, мы стали уделять больше внимания написанию автотестов и дополнительным мониторингам.
А ещё радует, что в процессе развития продуктов мы начинаем предоставлять их не только СИБУРу и нашим же заводам, но и совместным предприятиям с другими крупными компаниями. В общем, нам есть куда расти :)