Привет! Меня зовут Андрей Грачев, я менеджер по продукту в СИБУРе.
В СИБУРе мы регулярно проводим «остановочные ремонты».
Это что-то вроде профилактического обслуживания, планового обслуживания и ремонта, во время которого полностью останавливается вся установка или ее часть.
Такие ремонты необходимы для обеспечения бесперебойной работы предприятия в будущем.
Но, понятно, что в настоящее время завод не зарабатывает, поэтому важно сделать все как можно быстрее.
Для этого необходимо оптимально спланировать и провести работу.
Так возникла идея создать собственное мобильное приложение для стоп-ремонтов, которое позволило бы сделать процесс управления работами более организованным и минимизировать потери времени.
Расскажем, как мы это сделали, что получилось в итоге и к чему мы стремимся сейчас.
Зачем все это нужно?
Сначала расскажу, что такое стоп-ремонт. Это комплекс мероприятий по ремонту большого количества заводского оборудования, который необходимо проводить в течение определенного периода времени – например, раз в год, ежеквартально или с другой периодичностью.За это время останавливается производство, на завод приезжает подрядчик и ремонтируется все необходимое.
Это может длиться неделю, несколько недель; на «Сибур-Химпроме», например, завод остановился почти на месяц.
Столь масштабный ремонт практически всего оборудования на заводе можно представить как большой проект. У него есть подготовительные работы, на которых станция постепенно снижает мощность и отключается.
Существует активная фаза, когда агрегаты заменяются и обслуживаются, и фаза возобновления производства.
За 10-11 месяцев до начала остановочного ремонта все ответственные лица начинают планировать эту процедуру, создаются наряды на работы, которые необходимо выполнить.
Таким образом, к моменту начала работ накапливается большой пул задач, которые необходимо выполнить в отведенное на ремонт время.
Эти задачи часто взаимосвязаны: не выполнив одно, нельзя приступить к другому.
Например, мы не можем что-то отремонтировать в насосе, потому что надо сначала его отключить, снять оборудование, препятствующее разборке этого узла, и только потом работать с насосом.
Из этих связей строится продолжительность всего остановочного ремонта.
Ремонтные работы при остановке имеют «критический путь».
Как правило, из года в год на каждом предприятии действуют неизменные операции, без которых завод не может быть запущен.
Получается, что критический путь — это самое продолжительное время, которое можно потратить на остановочный ремонт. Все остальное планируется так, чтобы оно либо соответствовало времени остановочного ремонта, либо хотя бы не удлиняло его.
Это значит, что эти работы должны проходить параллельно.
Как все происходило раньше?
До сих пор все это делалось так: люди в SAP в течение года создают заказы, которые помечаются как требующие остановочного ремонта.Когда приходит время, все заказы от SAP загружаются в так называемый «дефектный лист», на основании которого механики составляют график остановочного ремонта.
Это сотни строк в Excel, из которых потом нужно понять перечень необходимых работ, сколько времени и людей это займет, и вовремя выстроить логику: что после чего будет ремонтироваться.
На всех предприятиях СИБУРа это делается практически одинаково – вручную в Excel. Только одно предприятие — «Сибур-Химпром» научилось это делать в плановой службе «Примавера».
Для нас это крайне неудобно с точки зрения интерфейса и пользовательских сценариев.
Конечно, мы смотрели в сторону других сервисов, например MS Project. Но их функционал нам был либо недостаточен, либо пришлось бы тратить много времени и соответственно денег на обучение.
Поэтому мы решили разработать собственный продукт. Когда мы начинали, картина в СИБУРе была такая: все пытаются спланировать серьезный проект в таблицах Excel. Все это распечатывается, и ставятся подписи заинтересованных лиц, утверждающих график.
Затем, во время остановочного ремонта, люди собираются на планерки и группируются в штабы, где на экране выводится файл Excel, и в нем выставляются проценты выполнения задач.
Подобные многочисленные и регулярные встречи необходимы для сбора и обновления информации.
Представитель подрядчика рассказывает, что было сделано, какие есть проблемы, а представитель заказчика записывает все в бумажный документ. Затем другой человек собирает информацию от каждого ответственного лица, консолидирует ее и готовит централизованный отчет. Это все сложно и долго, люди до ночи остаются на работе.
Первый прототип
Мы думали, что управление любым проектом строится на базовых вещах: планировании процессов и прозрачности происходящего в любой момент времени.Для обеспечения прозрачности необходимо предоставлять в систему актуальную информацию о том, что происходит во время ремонта.
Мы детально изучили производственные процессы, поняли, как происходят остановочные ремонты, и предложили структуру, при которой можно соблюдать график.
Мы решили сначала не ломать существующий процесс и не лезть в пользовательские сценарии людей.
Кто привык планировать в Excel — пусть планируют. Любой, кто учился в Примавере, должен там работать.
Изначально наш продукт представлял собой систему визуализации создаваемых ими графиков.
Мы разработали приложение для iOS, Android и браузерную веб-версию.
В сервис загружается график вместе с ответственными, исполнителями и контролерами — тремя основными ролями при остановочном ремонте.
Это важный момент, поэтому остановлюсь на нем подробнее и покажу, как все работает на примере.
Есть задание починить насос.
У задачи есть исполнитель – это бригадир подрядной организации, осуществляющей ремонт конкретного объекта.
Ответственный – несет ответственность за то, чтобы все было подготовлено к ремонту, он должен сдать объект в ремонт и затем принять его, подтвердив, что подрядчик выполнил работу в полном объеме и может приступить к другим задачам.
Обычно это делает механик по установке.
Контролёры – это высшее руководство предприятия, люди, которые хотят постоянно видеть, чтобы работа шла по графику.
Пользовательские роли
Ответственные и исполнители имеют доступ как к приложению, так и к веб-версии.Подрядчик видит задачи, которые поставлены перед ним на сегодня, а также на все остановочные ремонты.
У исполнителя есть последовательность этих задач.
Приступая к работе, он должен нажать соответствующую кнопку и ввести в программу количество человек, которые работают над этой задачей.
Руководству важно знать, соответствует ли количество людей, работающих над этой задачей, запланированному.
Исполнитель нажимает кнопку и работа начинается.
Приложение отслеживает длительность процесса.
Если срок пройден, а подрядчик не нажал кнопку завершения, ответственному лицу приходят уведомления о задержке.
Это значит, что ответственное лицо идет и смотрит, что произошло.
Если все в порядке и подрядчик выполняет работу в установленные сроки, он нажимает кнопку «Отправить отчет» и пишет, что выполнил работу на 100%.
Затем ответственному лицу также приходит уведомление о том, что все сделано, ему нужно пойти и посмотреть результат. Вот как работает образец для подражания.
Люди могут не держать в голове всего, что происходит на вверенной им территории; они видят расписание на каждый день и получают уведомления о процессе.
Также мы предусмотрели возможность работы с задачами, которые длятся более одного дня.
Функционирует это так же, как и с небольшими задачами, только в конце каждого дня нужно вводить в программу отчеты: например, сегодня работа выполнена на 50%.
Ответственное лицо получает уведомление и должно проверить правильность этой информации.
В противном случае он отклоняет отчет и заставляет исполнителя поставить другую цифру.
Что касается веб-версии, то ее функционал немного другой; он предназначен больше для контролеров - руководства предприятия.
Мы поняли, что люди привыкли получать информацию о ходе всей работы в диаграммах Ганта.
Они видят плановые факты, связи, статистику мобилизации человеческих ресурсов, сколько людей мы хотели видеть на заводе во время ремонта и сколько реально работает. И, соответственно, по всем производственным установкам контролер может посмотреть ход работы и оперативно увидеть отклонения от графика.
Внеплановая работа
Всегда при остановочном ремонте появляются скрытые дополнительные работы, которые невозможно игнорировать.Например, при разборке оборудования происходит поломка детали, которая не видна при сборке агрегата.
Эти задачи также включены в график и принято решение о выполнении скрытых работ при остановочном ремонте.
Все занесено в программу.
Если эта дополнительная работа повлияет на продолжительность всего остановочного ремонта, то программа автоматически отложит все остальные задачи на время, необходимое для выполнения этой скрытой работы.
То же самое и в обратном случае — если какие-то задачи выполняются быстрее запланированного, график оптимизируется.
Для таких случаев мы с командой разработали серьезную систему сообщений и push-уведомлений, чтобы предупреждать людей, приступающих к работе, о том, что они рано или поздно смогут ее сделать.
И тут выявился интересный момент. Мы серьезно переборщили с этими уведомлениями.
Где мы ошиблись?
Дело в том, что мы там ввели «график четвертого уровня» — большой подробный план всех остановочных ремонтов.Оно оказалось слишком подробным для наших целей.
Оказалось, что пользователи получали уведомления о каждой мелочи, которая может быть незначительной для процесса в целом.
Ведь когда человек работает без приложения, он не каждый день смотрит график работы.
Он просто знает: чтобы отремонтировать условный насос, нужно выполнить множество операций (разобрать его, почистить, заменить агрегаты, собрать, проверить и так далее).
И человеку, который проверяет, как работает подрядчик, не нужно контролировать прохождение каждого из этих этапов.
Достаточно посмотреть на результат работы в целом и соблюдение заявленных сроков.
То есть, если перейти к уведомлениям, контроллер должен узнать о двух событиях: начале ремонта и завершении ремонта.
Поэтому мы корректировали приложение на лету.
Для начала попросили изменить графики и увеличить их.
Потом отказались от некоторых мелких событий и все стало работать более плавно, пользователь стал меньше отвлекаться на уведомления.
Какой результат?
Доработав приложение, мы получили сервис, позволяющий постоянно иметь актуальную информацию по предприятию: что сейчас ремонтируется, на каком этапе процесса и когда срок сдачи.Это позволяет планировать работу и составлять график.
По сути, эта система управления проектами ремонта при остановке представляет собой расширенный менеджер задач.
Изначально мы заявляли, что основной метрикой является сокращение времени остановочных ремонтов.
Понятно, как это оценить в деньгах: ведь мы знаем, сколько стоит час или день простоя производства.
Поэтому нашей целью было ускорить остановочный ремонт. Теперь мы видим, что важна и аналитика — оценка того, что происходит во время остановочного ремонта, до мельчайших деталей.
Если мы зафиксируем действия пользователя, как и когда он принял работу, какие комментарии написал, что пошло не так, как проходят согласования, мы увидим образование скрытых дефектов, поймем, кто как работает - тогда мы сможем проанализировать и понять много о производственных процессах.
Как раз для их оценки у нас есть «Функция эффективности производства».
После каждого ремонта собирается определенный объем данных: сколько денег было потрачено, сколько было запланировано, как быстро мы выполнили ремонт. 
Конечно, мы предусматриваем дальнейшее развитие проекта.
Пока это только первый шаг в сборе статистики по остановочным ремонтам.
Мы хотим собрать достаточно данных, чтобы можно было с ними поработать и сделать больше выводов.
Например, нам нужно отремонтировать насос.
Это делает X человек, и это занимает Y времени.
Соответственно, все последующее планирование любого ремонта может основываться на этой модели.
Мы сможем планировать работу, исходя из того, что у нас уже есть аналитика, подтвержденная данными, а значит, мы не будем завышать или занижать ожидания относительно сроков.
Наше приложение можно использовать не только для производства.
Это может быть управление капитальным строительством или любые другие сферы, где применяется аналогичный подход к планированию работ.
Кто работал над проектом?
Над проектом работала группа людей как внутри СИБУРа, так и у подрядчиков.Разработка серверной части и фронтенда полностью легла на плечи подрядчика; внутри команды мы занимались проектированием логики и интерфейса приложения.
В качестве консультантов были привлечены руководитель остановочного ремонта, механик, непосредственно работавший по графикам, главный инженер, контролирующий процесс, и директор предприятия.
На все про все ушло полгода (исследования, пилотирование, интерфейсы и разработка).
Каково будущее продукта?
В ближайшем будущем нас ждет несколько ключевых обновлений.До сих пор возникают проблемы с расчетом физических объемов в рамках какой-либо задачи, например, по замененной арматуре.
Наших коллег на предприятии интересуют не только относительные, но и абсолютные показатели: нам нужно понимать, какой процент работ выполнен, сколько арматуры из 1000 условной уже заменено.
В настоящее время это не учтено в графике подачи заявок.
Мы подумаем, как это реализовать.
Пока мы можем говорить только о ходе выполненных работ и проценте их выполнения, а также фиксировать ситуации отставания или опережения графика.
Возможно (и такое понимание уже есть), мы весь процесс планирования остановочного ремонта перенесем на свой проект. Возможно, вся разработка будет осуществляться собственными силами.
Будем рады видеть в команде новых коллег: владельцев продуктов, продуктовых дизайнеров, разработчиков.
Список актуальных вакансий по ссылке hh.ru .
Теги: #Android #Android-разработка #it-инфраструктура #производство #Управление продуктом #интерфейсы #UX #ui #интерфейс #Сибур #нефтехимия #цифровая нефтехимия
-
Оптимистическое Влияние Онлайн-Игр На Детей
19 Oct, 24 -
Ubuntu 18.04 Рут На Zfs
19 Oct, 24 -
Allofmp3.Com Окончательно Закрыт
19 Oct, 24 -
Http-Сервер За 15 Минут
19 Oct, 24
