Хабрахабр

Хакатон по Data Science в СИБУРе: как это было

Привет!

В мае мы вместе с AI-community организовывали хакатон по направлению «Цифровизация производства». С начала года мы провели около 10 хакатонов и воркшопов по всей стране. До нас хакатон про data science на производстве ещё не делали, и сегодня мы решили подробно рассказать о том, как это было.

Нужно было оцифровать наш бизнес на всех его этапах (от поставок сырья до производства и прямых продаж). Цель была проста. Само собой, должны были решаться и задачи прикладного характера, например:

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

В чём главная ценность таких задач? Правильно, в максимальном приближении к настоящим бизнес-кейсам, а не к абстрактным проектам. Первая задача уже подробно описана на Хабре одним из участников (спасибо, cointegrated Давид!). А второй задачей, вынесенной на хакатон, стала необходимость оптимизировать процесс совмещения плановых ремонтов ж/д-вагонов логистического парка. Это взяли прямо из нашего текущего бэклога, немного адаптировав для участников, дабы сделать её понятнее.

Итак, описание задачи.

Что нужно было сделать

У специалистов по логистике есть специальный календарь, куда вносится информация об отправке вагонов на плановое техобслуживание. Так как вагонов больше двух (сильно больше двух), нужно решение, которое упростит работу сотрудника, сделав его работу проще, интуитивнее, а также поможет ему быстрее принимать те или иные решения на основе предварительного анализа данных.

Поэтому само решение должно включать в себя две составляющие:

  1. Специальный алгоритм на основе анализа данных.
  2. Удобный интерфейс, позволяющий подробно и понятно визуализировать полученные данные и результаты работы алгоритма. На чём именно реализовывать (веб, мобильное приложение, или вообще с помощью бота) — на усмотрение участников.

Вводные данные

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

А главное — как и чем измерить эффективность решения? Казалось бы, ну составил календарь ремонта вагонов и всё, чего тут ещё можно оптимизировать?


Критерии оптимизации плановых ремонтов

У каждого нашего вагона может быть 4 типа ремонтов. Тут стоит начать с того, что ремонт вагона — это не просто ремонт вагона.

  • Капитальный.
  • Деповской.
  • Плановый предупредительный.
  • Вакуумная очистка и гидроиспытания.

У каждого из этих четырёх видов ремонта есть своя стоимость непосредственно ремонта (материалы для починки + оплата работ по ремонту), а также стоимость подготовки к ремонту. Кроме этого, есть ещё и стоимость доставки вагона до депо. А так как вагон едет целенаправленно на ремонт, то едет он порожняком, значит, исключаем тут возможную прибыль за поездку.

Начали ребята, само собой, с гипотез.

Гипотезы

Гипотеза №1. Если совместить несколько ремонтов в один день, можно сэкономить на подготовительных работах.

Гипотеза встретила предложение вида «Да давайте тогда просто при каждом ремонте делать ещё и все остальные, чтобы два раза не вставать, в тот же день».

Местами даже логично. Звучит круто. Но не всё так просто.

В общем, как с машиной. У ремонта (у любого из четырёх) есть не только стоимость, но и утилизация. Если делать ТО слишком часто, не вырабатывая ресурс, теряешь деньги. Прошёл ты техосмотр в январе, и тянешь до следующего техосмотра как можно дольше, чтобы каждый потраченный рубль на первый техосмотр расходовался эффективно.

Но в случае с огромным количеством вагонов такой фальстарт ремонтов может принести довольно серьёзные убытки. Да, с авто пример не совсем совпадает с нашим, все же, ситуации бывают разные, и иногда стоит пройти ТО заранее (а то и 2-3 раза в год), скажем, перед важной долгой поездкой.

Тогда можно просто совмещать эти ремонты так, чтобы утилизация каждого из них была максимально полной. Гипотеза №2.

Возникают вопросы: Уже лучше.

А путь между самими станциями — нет. С какой именно станции вагон выгоднее отправить в ремонт?
Путь от каждой станции до депо мы знаем. Может, вагон осилит перевезти чуть больше груза и отправиться в депо с более дальней станции, но зато заработав на поездке?

Учитываем расстояния между станциями и прибыль от доставки продукции — оптимизируем логистические точки отправки в ремонт. Гипотеза №3.

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

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

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

Черновые эскизы дизайнов

Участники приняли все эскизы и пожелания и ушли думать.

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

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

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

Смотр демо и финал

Тут всё было просто и привычно. У каждой команды есть 5 минут на выступление, а у организаторов — 5 минут на вопросы. Само собой, рамки не были совсем уж жёсткими, и иногда мы выходили за это время.

На всё про всё в таком ритме мы провели часа 3.

Тут помог подход AI-community, по которому фиксировались ещё и промежуточные результаты процесса. Оценивали полученные решения комплексно — подходы к решению задачи в общем и целом, визуализацию, применимость предложений в реальности.

Победители

Главный приз (300 000 рублей) достался команде «Hack.zamAI».

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

При этом оно всё ещё и выглядит достойно и дружелюбно.

Вот тут можно посмотреть демонстрацию их решения.

(видео на GoogleDrive)

Само собой, это не последний наш хакатон.

И обязательно разместим анонс следующего. Хотим сказать спасибо всем, кто участвовал в этом.

Дмитрий Архипов, архитектор, «Цифровизация процессов», СИБУР

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть