Подходим к логистике и фурам продуктово
Принято считать, что разработка цифровых продуктов в крупной промышленной компании это очень скучно, если целевое решение понятно (бизнес уж точно знает, что ему надо): длинные ТЗ для подрядчика перетекают в сжатые сроки сроки и строго определенные бюджеты. Но что же делать, когда появляется проект с низким уровнем определенности?
Специально для подобных ситуаций, когда на старте ничего не понятно, а текущий процесс необходимо серьезно оптимизировать или вообще кардинально изменить, мы написали специальный продуктовый фреймворк. Если будет интересно, мы подробно разберем его в одном из следующих постов.
А в этом — расскажем о том, как мы помогли одному из наших заводов оптимизировать автомобильную логистику. Про фуры и водителей, погрузку полимеров, MVP и сарафанное радио — под катом.
Важно: пост немного гибридный, здесь и про бизнес, и про продукт, и техническая часть. Если вам не очень интересны бизнес-составляющие, смело начинайте читать с раздела «Как мы обеспечили офлайн-работу приложения».
В 2020 у нас открылся большой завод под кодовым названием ЗСНХ (он же ЗапСибНефтеХим), который начал постепенно выходить на заявленную проектную мощность. Под этим понятием (если речь идет о заводе) понимается множество разных цифр и показателей, но мы в рамках этого поста будем говорить только о логистике.
Логистика практически любого завода состоит из следующего
1. Входящая логистика — когда на завод привозят исходное сырье и прочие штуки, необходимые для создания конечного продукта;
2. Производство — тут всё понятно (но если хотите деталей, то они вот тут);
3. Исходящая логистика — когда готовый продукт заботливо загружают в транспорт и посылают в добрый путь.
В случае с ЗСНХ исходящая логистика состоит в основном из вывоза готовой продукции по железной дороге в контейнерах или автотранспортом.
Когда блок логистики анализировал пропускную способность завода, они пришли к нам, в SIBUR Digital, и сказали, что у них есть потенциальная проблема в той самой исходящей логистике. И, если железная дорога является величиной более или менее известной в данном уравнении, то вот автотранспорт вызывал много вопросов.
В чем суть. Завод производит продукт, допустим, мы говорим о гранулах полипропилена. Если сильно упрощать, весь этот продукт по трубе попадает в фасовочный цех, фасуется по мешкам и отправляется на большой склад. После чего все эти мешки лежат на складе и ждут, пока их развезут на склады клиентам.
Проектная мощность — величина расчетная, но реальность часто вносит свои коррективы. Так и тут. Логисты, к их чести, смогли прийти к нам с проблемой, которую они предсказали, а не уже имели на руках. Мы вооружились своим фреймворком и пошли смотреть, чем можем помочь.
Ход работы
Прежде всего, нужно было разобраться, как построены процессы as-is.
В процессе анализа выяснилось отсутствие бизнес-процессов. Разумеется, не то чтобы их не было совсем, просто их только начинали там выстраивать. С одной стороны, оно и к лучшему, потому что строить какую-то систему вообще с нуля сильно интригует, это реально интересно.
С другой стороны, минус такого состояния — меньше права на ошибку. Если приходишь со своим подходом на уже существующий процесс, то можешь проанализировать все его плюсы и минусы, разобрать допущенные ошибки и предложить варианты улучшения. Кроме того, раз уже расписал ошибки — значит, хотя бы их точно не повторишь. Если хорошо записал.
В нашем случае нет процессоров = нет ошибок, на которых можно было бы научиться.
Discovery
Мы тщательно изучили, что и как у коллег вообще работает, в чем особенности логистики в плане автотранспорта в отличие от ж/д, как вообще выстроить всю эту систему, чтобы она адекватно работала. Описали процесс, поняли, что ничего не ясно, и решили делать MVP в рамках проекта под названием «Временные окна».
Здесь надо понимать, что ЗапСибНефтеХим — довольно уникальное место с точки зрения локации. 250 км направо — и Тюмень. 430 км налево — Ханты-Мансийск. Тобольский тракт — трасса хоть и федеральная, но всё-так наша, родная, поэтому среднего качества. И в случае зимы и -30 или лета и +30 эти расстояния могут занять сильно разное количество времени. Сама суть временного окна в том, что для конкретной машины выделяется конкретный промежуток времени, в который она должна подъехать, загрузиться и уехать.
Поэтому мы договорились с 5 лояльными клиентами, которые захотели поучаствовать в нашем эксперименте. MVP мы делали безинтеграционный, чтобы просто посмотреть, как все будет работать с точки зрения операционных процессов, и обкатать на пользователях наши гипотезы в части самой системы.
Компании согласились почти сразу, потому что для них это тоже выигрышная история, ведь их машины не будут простаивать в ожидании погрузки, заводу будет проще все планировать, да и общая прозрачность процесса ощутимо увеличится.
Итак, MVP задизайнен, приступаем к эксперименту. Гипотезы были такие
система ощутимо стабилизирует загрузку склада завода;
система поможет значительно более точно предсказывать время нахождение машины на площадке;
система даст машине возможность заранее планировать время приезда на завод, до назначенного окна.
Временные окна для машин были разделены на три промежутка с 00.00 до 09.00, с 09.00 до 17.00 и с 17 до конца суток.
Во время пилота мы обкатывали различные варианты системы управления слотированием, и в итоге решили сделать ее достаточно гибкой, чтобы в будущем завод мог ей полноценно управлять в зависимости от разных ситуаций без привлечения команды разработки.
Результаты MVP показали, что всё работает как надо, поэтому мы пошли дальше, готовиться к проду и к различным интеграциям.
Здесь надо отметить, что IT-ландшафт в СИБУРе непростой, и не только из-за количества разных систем, но и из-за разного уровня доступа к ним. Всё это должно максимально отвечать стандартам безопасности. Это тоже тема, достойная отдельного поста и марафона согласований с безопасниками.
От MVP к проду
В рамках исследования и тестирования MVP мы поняли, что есть большое количество логических ограничений, которые нужно учитывать в процесса разработки нашего решения:
у нас есть множество различных марок полиэтилена и полипропилена — некоторые марки отгружаются только с конкретного гейта, а не с любого свободного, к которому можно подъехать в удобное время,
другие марки могут грузиться в определенное время,
а ещё надо прогнозировать наличие конкретной марки на складе, чтобы машина не подъехала к тому гейту, откуда пока и грузить-то нечего,
и еще множество подобных штук.
Затем надо было настроить динамическое управление расписанием, чтобы завод смог нормально управлять количеством мест во временных слотах.
В процессе работы у нас произошло объединение заводов, ЗапСибНефтеХима и бывшего СИБУР Тобольска, так что в систему надо было интегрировать по сути склад еще одного завода. И примерно под новый год 2021 мы начали работать с интеграциями в EWM и ERP, писали модули с расписанием, алгоритмы со сложной логикой и многое другое.
В марте 2021 мы начали заезжать в прод.
Процессы и люди
Первое время сложно было именно с точки зрения людей. Водители в большинстве своем — люди, довольно далекие от IT, и объяснить каждому, зачем вообще эта система, как работает и почему с ней круче, чем без нее — это был тот еще челлендж. Помогли три вещи.
1. Документальный подход. Когда вы планируете на бумаге и в ряде договоров все, что касается временных окон, в которые надо попадать. Такое своеобразное SLA для водителя и транспортной компании, чтобы не было ситуаций, когда водитель какой-то компании приехал на три часа позже нужного времени, и из-за этого у всех остальных график поехал.
2. Личный подход. По возможности донести до каждой компании и до тех водителей, до которых дотянемся, почему система полезна. Конкретно для него.
3. Сарафанное радио. На удивление рабочая штука — водители стали активно обмениваться между собой информацией, что есть вот такая-то штука, что она работает, и вообще всё не зря.
Что сейчас
Сейчас мы в проде, за эти полгода смогли достичь таких результатов:
порядка 77% машин отправляется под погрузку вовремя,
в части времени загрузки самой фуры непосредственно на складе завод стал в 90% случаев укладываться установленные нами нормативы,
появилась возможность значительно увеличить пропускную способность завода,
обеспечили новый уровень бесперебойность работы.
порядка 77% машин отправляется под погрузку вовремя,
в части времени загрузки самой фуры непосредственно на складе завод стал в 90% случаев укладываться установленные нами нормативы,
появилась возможность значительно увеличить пропускную способность завода,
обеспечили новый уровень бесперебойность работы.
Конечно, есть куда расти. Целимся в то, чтобы как минимум 80% машин приезжали вовремя. Измеряем именно в процентах, потому что само количество машин у нас довольно плавающее: в среднем 300 в сутки, но день ото дня может быть от 250 до 350.
Сейчас мы хоть и передали инструмент на поддержку, но все равно наблюдаем за своим детищем: помогаем воспитывать водителей и достаточно часто снимаем с логистов и транспортных компаний обратную связь (какие бы еще показатели они хотели видеть в системе, какие метрик измерять, какую функциональность добавить для удобства использования системы).
Как мы обеспечили офлайн-работу приложения
Интернет на заводе есть, так как на нем много чего завязано. Однако пользователи нашего приложения все равно находят такие места, где связь не очень хорошая. Прямо скажем, недостаточная. Сотрудники решали проблему старым дедовским способом — просто пойти к тому коллеге, у которого в пределах видимости связь есть, и подгрузить новую информацию на страничку там.
Когда им это поднадоело, они пришли к нам с запросом — сделать им возможность выгружать расписания прибытия-убытия автомобилей и транспортные окна в Excel.
Но мы как продуктологи решили идти тут не просто от желания пользователей, а именно от их потребностей. Выгрузка в Excel им нужна была для того, чтобы сделать себе локальную копию расписания и сверяться с ним, если вдруг онлайн-страничка с расписанием в приложении капризничает из-за плохой сети.
Поэтому мы просто решили сделать офлайн-версию приложения. Да, все на кэшах.
Когда сеть есть, все обновления расписания подтягиваются и сразу сохраняются в кэше, при этом доступны и остальные функции приложения — можно посмотреть отчеты, поменять расписание, перетасовать транспортировки в плане и прочее. А когда сети нет, приложение переходит в режим «Держи тебе расписание табличкой только для просмотра».
Для этого нам нужно было реализовать PWA, progressive web app. В два захода.
Первый — использовать сервис-воркеры для кэширования нашей разметки. Она состоит из html- и js-файлов, и на каждой странице приложения она разная. JS у нас поделен на чанки, чтобы пользователи при заходе в приложение не были вынуждены грузить весь бандл страниц, а грузили только то, что нужно. Поэтому страницы должны быть сохранены в кэше.
Всю работу на себя берет библиотека work box, которую мы используем, чтобы не писать вручную каждый воркер, потому что это заняло бы слишком много времени.
Для сохранения данных в расписании мы используем Index DB, встроенный инструмент браузера. А для воркеров используем политику network first — пользователю в первую очередь всегда загружаются данные из интернета. Если сети нет и разметка не прогружается — то только тогда уже из кэша.
Второй — использование optimistic UI. Как следует из названия, это подход, который надеется на лучшее. В чем суть.
Возьмем для примера работу какого-нибудь чата. Как все должно быть устроено — пользователь отправляет через UI сообщение, оно уходит на бэкенд, бэкенд его обрабатывает, если все ок — сообщение помечается как отправленное.
Как чаты работают на самом деле. Пользователь отправляет сообщение, и оно сразу помечается отправленным (потому что это ожидаемое поведение сообщения). Даже если бэк еще не сказал, что все в порядке. Если на бэке будет проблема, то покажется сообщение об ошибке. Если проблемы не будет, то сообщение так и останется в статусе «отправлено».
Для пользователя это все равно происходит в большинстве случаев довольно быстро, и он не замечает разницы. Но Optimistic UI на самом деле сообщает о каком-то событии как о свершившемся, пока оно еще де-факто не наступило.
У нас то же самое. Приложение визуально похоже на Trello, такая канбан-доска. И пользователи перетаскивают там карточки для изменения статусов. При перетаскивании карточки из окна А в окно Б мы сразу отрисовываем ее в Б, заранее, даже если бэк не подтвердил, что все правда перенеслось. А вот если проблемы со связью и что-то не сохранилось, то уже тогда показываем сообщение об ошибке.
Но не держим пользователя в ожидании с прелоадером, который постоянно крутится в ожидании ответа от бэка.
