Подходим К Логистике И Доставке Продукции

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

Но что делать, когда появляется проект с низким уровнем уверенности? Специально для таких ситуаций, когда на старте ничего не ясно, а текущий процесс необходимо серьезно оптимизировать или даже радикально изменить, мы написали специальный продуктовый фреймворк.

Если вам интересно, мы подробно разберем это в одном из следующих постов.

И в этом мы поговорим о том, как мы помогли одному из наших заводов оптимизировать автомобильную логистику.

О фурах и водителях, погрузке полимеров, MVP и сарафанном радио — ниже под катом.



Подходим к логистике и доставке продукции

Важно: пост немного гибридный, здесь и бизнес, и продукт, и техническая часть.

Если вас не очень интересуют бизнес-компоненты, смело начинайте читать с раздела «Как мы обеспечили работу приложения в офлайн-режиме».

В 2020 году мы открыли крупный завод под кодовым названием ЗСНХ (он же ЗапСибНефтеХим), который начал постепенно выходить на заявленную проектную мощность.

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

Логистика практически любого завода состоит из следующих элементов: 1. Входящая логистика - когда на завод завозится сырье и другие вещи, необходимые для создания конечного продукта; 2. Производство - тут все понятно (но если хотите подробностей, то они Прямо здесь ); 3. Исходящая логистика — когда готовая продукция бережно загружается в транспорт и отправляется в путь.

В случае с ЗСНХ исходящая логистика состоит в основном из экспорта готовой продукции железнодорожным транспортом в контейнерах или автомобильным транспортом.

Когда логистический отдел проанализировал пропускную способность завода, к нам в «СИБУР Диджитал» пришли и сказали, что у них потенциальная проблема в той самой исходящей логистике.

И, если железная дорога — более-менее известная величина в этом уравнении, то автотранспорт вызывает много вопросов.

В чем смысл? Завод выпускает продукцию, допустим, речь идет о полипропиленовых гранулах.

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

Проектная мощность – расчетная величина, но реальность часто вносит свои коррективы.

Так вот здесь.

Логисты, надо отдать им должное, смогли прийти к нам с проблемой, которую они предсказанный , и под рукой его еще не было.

Мы вооружились нашей структурой и пошли посмотреть, чем мы можем помочь.



Прогресс

Прежде всего необходимо было понять, как выстраиваются процессы «как есть».

В ходе анализа выяснилось, что бизнес-процессов нет. Конечно, дело не в том, что их вообще не было, просто их там только начали строить.

С одной стороны, это к лучшему, ведь строить какую-то систему с нуля — это очень интригующе, это действительно интересно.

С другой стороны, недостатком этого состояния является то, что здесь меньше места для ошибки.

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

К тому же, раз уж вы описали ошибки, значит, по крайней мере, вы их точно не повторите.

Если ты это хорошо записал.

В нашем случае нет процессоров = нет ошибок, на которых можно учиться.



Открытие

Мы внимательно изучили, что и как вообще работают наши коллеги, в чем особенности логистики на автомобильном транспорте в отличие от железнодорожного и как вообще выстроить всю эту систему, чтобы она работала адекватно.

Мы описали процесс, поняли, что ничего не понятно, и решили сделать MVP в рамках проекта под названием «Time Windows».

Здесь нужно понимать, что «ЗапСибНефтеХим» — достаточно уникальное место с точки зрения расположения.

250 км направо – и Тюмень.

430 км влево – Ханты-Мансийск.

Тобольское шоссе — федеральная трасса, но она всё же наша-наша, а потому среднего качества.

А в случае зимы и -30 или лета и +30 эти дистанции могут занимать совсем разное количество времени.

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

Поэтому мы договорились с 5 постоянными клиентами, которые хотели поучаствовать в нашем эксперименте.

Мы делали MVP без интеграции, просто чтобы посмотреть, как всё будет работать с точки зрения операционных процессов, и проверить свои гипотезы относительно самой системы на пользователях.

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

Итак, MVP разработан, приступим к эксперименту.

Гипотезы были следующие

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

Временные окна для автомобилей были разделены на три периода: с 00.00 до 09.00, с 09.00 до 17.00 и с 17.00 до конца суток.

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

Результаты MVP показали, что всё работает как надо, поэтому мы пошли дальше, готовясь к продакшену и различным интеграциям.

Здесь следует отметить, что ИТ-ландшафт в СИБУРе сложен, и не только из-за количества различных систем, но и из-за разных уровней доступа к ним.

Все это должно максимально соответствовать нормам безопасности.

Это тоже тема, достойная отдельного поста и марафона согласований с силовиками.



От MVP к продукту



Подходим к логистике и доставке продукции

В рамках исследования и тестирования MVP мы поняли, что существует большое количество логических ограничений, которые необходимо учитывать в процессе разработки нашего решения:
  • у нас много разных марок полиэтилена и полипропилена - некоторые марки отгружаются только от конкретных ворот, а не от каких-то свободных, к которым можно подъехать в удобное время,
  • другие бренды могут загружаться в определенное время,
  • а еще нужно спрогнозировать наличие конкретной марки на складе, чтобы машина не подъезжала к воротам откуда еще нечего грузить,
  • и многое другое подобное.

Тогда необходимо было настроить динамическое управление расписанием, чтобы завод мог правильно управлять количеством мест во временных интервалах.

В процессе работы мы объединили заводы «ЗапСибНефтеХим» и бывший Тобольский СИБУР, так что по сути в систему пришлось интегрировать склад другого завода.

А под Новый 2021 год мы начали работать с интеграциями в EWM и ERP, писать модули с расписаниями, алгоритмы со сложной логикой и многое другое.

В марте 2021 года мы начали переходить в прод.

Процессы и люди

Поначалу это было сложно с точки зрения людей.

Большинство водителей — люди довольно далекие от IT, и объяснить всем, зачем вообще нужна эта система, как она работает и почему с ней круче, чем без нее, было довольно сложной задачей.

Три вещи помогли.

1. Документальный подход. Когда ты планируешь на бумаге и в ряде договоров все, что касается временных окон, в которые тебе нужно попасть.

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

2. Персональный подход. Если возможно, донесите до каждой компании и до тех водителей, до которых мы доходим, почему система полезна.

Специально для него.

3. Сарафанное радио.

На удивление, это рабочая штука - водители начали активно обмениваться между собой информацией, что есть такая-то штука, что она работает, и в общем не зря.



Что теперь

Сейчас мы в производстве, за эти полгода нам удалось добиться следующих результатов:
  • около 77% вагонов отправляются под погрузку вовремя,
  • по срокам загрузки самого грузовика непосредственно на складе завод в 90% случаев стал соответствовать установленным нами нормам,
  • стало возможным существенно увеличить производительность завода,
  • обеспечил новый уровень непрерывности работы.

Конечно, есть куда расти.

Мы стремимся к тому, чтобы не менее 80% автомобилей прибывали вовремя.

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



Как мы обеспечили работу приложения в автономном режиме

На заводе есть Интернет, так как к нему подключено очень много вещей.

Однако пользователи нашего приложения все равно находят места, где связь не очень хорошая.

Честно говоря, этого недостаточно.

Сотрудники решили проблему по старинке — просто подошли к коллеге, у которого связь в пределах видимости, и загрузили туда новую информацию на страницу.

Когда им это надоело, они обратились к нам с просьбой - дать им возможность выгружать в Excel графики прибытия и отправления транспортных средств и транспортные окна.

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

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

Поэтому мы просто решили сделать офлайн-версию приложения.

Да, все кэшируется.

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

Для этого нам нужно было реализовать прогрессивное веб-приложение PWA. Мы использовали сервис-воркеров для кэширования нашей разметки.

Он состоит из файлов html и js и на каждой странице приложения разный.

Наш JS разделен на куски, чтобы при входе в приложение пользователи не были вынуждены загружать всю пачку страниц, а загружали только то, что им нужно.

Поэтому страницы должны храниться в кеше.

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

Для хранения данных в расписании мы используем Index DB — встроенный инструмент браузера.

А для рабочих мы используем политику network first — пользователь всегда первым загружает данные из Интернета.

Если сети нет и разметка не загружается, то только из кеша.

Еще одна вещь, которая нам помогла, — это использование оптимистичный интерфейс.

Как следует из названия, это подход, который надеется на лучшее.

В чем смысл? В качестве примера возьмем работу какого-нибудь чата.

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

Как на самом деле работают чаты.

Пользователь отправляет сообщение, и оно сразу же помечается как отправленное (поскольку это ожидаемое поведение сообщения).

Даже если спина еще не сказала, что все хорошо.

Если на сервере возникла проблема, появится сообщение об ошибке.

Если проблем нет, сообщение останется в статусе «отправлено».

Для пользователя это всё равно происходит довольно быстро в большинстве случаев, и он не замечает разницы.

Но Optimistic UI фактически сообщает о событии как о произошедшем еще до того, как оно действительно произошло.

Мы имеем то же самое.

Приложение визуально похоже на Trello, канбан-доску.

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

При перетаскивании карточки из окна А в окно Б мы сразу рисуем ее в Б, заранее, даже если бэкенд не подтвердил, что все действительно перенесено.

Но если есть проблемы со связью и что-то не сохраняется, то мы показываем сообщение об ошибке и карта будет возвращена из Б в А.

Но мы не заставляем пользователя ждать с постоянно крутящимся прелоадером в ожидании ответа от бэкера.

Теги: #Транспорт #Продуктовый менеджмент #мобильные приложения #МВП #логистика #продуктовый подход #Сибур

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.