Supply Chain automation или как автоматизировать цепочки поставок

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

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

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

Задача прогнозирования потребления

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

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

Оценка потребления

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

Откуда взять потребление?

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

Другой вариант – введение условных норм. Например норм потребления бумаги, норм на расход средств индивидуальной защиты и т.д. Этот подход тоже имеет недостатки. Во-первых, алгоритмы нормирования просты и не учитывают многие особенности потребителей, в результате чего разные потребители могут получить одинаковое количество ТМЦ и для каждого оно будет не оптимальным – у одного возникнет избыток, а у другого недостаток этих ценностей. Во-вторых, нормы почти не меняются во времени, что еще сильнее усугубляет эффект избытка или недостатка ТМЦ: в случае большого избытка возникает затоваривание на объекте-потребителе, а в случае недостатка увеличивается количество срочных заказов на поставку ТМЦ. Это неэффективно и дорого.

Третий вариант - прогнозирование.

Оценка запаса

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

Если запас есть, то для определения будущей поставки его нужно учитывать. То есть в уравнение добавляется еще одна величина – J(t).

Как можно учесть запас? Хорошо, когда есть аудит запасов – система по хранению и учету информации о запасах ТМЦ во временном разрезе. Если такая система есть, то информация берется из нее напрямую, и тогда все понятно. А что делать, если такой информации нет? Провести аудит – сложно и дорого: например, можно держать штат сотрудников, проводящих инвентаризацию запасов, или попробовать заняться разработкой решений на базе алгоритмов компьютерного зрения для оценки запасов. С точки зрения эффективности и стоимости реализации оба варианта не целесообразны.

В реальности

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

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

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

Другие данные о потребителях

Данные, характеризующие объекты, специфичны для каждого типа потребителя. Для продающих отделений это информация о проведенных операциях в разрезе продуктов, а также информация из электронной системы учета очередей. Во всех отделениях, где принтеры подключены к системе централизованного сбора информации о распечатках, – данные  из этой системы. Как их можно использовать?

Основная идея использования данных, характеризующих деятельность объекта-потребителя, состоит в следующем: одна и та же активность требует схожего количества расходных материалов. Например ситуация с бумагой: мы знаем, что операция ипотечного кредитования требует в среднем 5 листов бумаги, операция по выдаче кредита – 3 листа, а операция по открытию депозита – 1 лист, и эти числа условно постоянны. Тогда потребители с одинаковым профилем операций должны справляться одинаковыми объемами ТМЦ. Как можно учесть эти соображения при моделировании?

Двухмодельный подход

Мы использовали двухмодельный подход с основной и ограничивающей моделью. Основная модель разработана на данных о прошлых поставках и прогнозирует количество ТМЦ, которое точно удовлетворит потребность объекта. Ограничивающая модель, разработанная на данных об операциях, прогнозирует количество ТМЦ, которое необходимо для удовлетворения потребности объектов с похожим профилем операций. Далее финальный прогноз определяется как простой ансамбль результатов этих двух моделей. Он всегда не больше прогноза основной модели, т.е. прогноза, основанного на данных о прошлых поставках. Таким образом, мы плавно снижаем поставки товарно-материальных ценностей и стремимся к реальному потреблению. Сейчас ограничивающие модели существуют для различных номенклатурных групп и основаны на различных источниках информации. Для ускорения их разработки мы применили инструментарий автоматической разработки моделей AutoML, который помог нам быстрее обработать множество широких таблиц и автоматизировать этапы генерации и отбора признаков, подбора гиперпараметров, выбора финального алгоритма.

Первые результаты подхода можно оценить на примере с поставками бумаги. За период чуть менее года общие поставки снизились на 10% в моменте и более 30% накопительно.

Источник: https://habr.com/ru/post/673336/


Интересные статьи

Интересные статьи

В четверг 15 апреля компания Codecov опубликовала сообщение о взломе собственной инфраструктуры и потенциальной утечке данных у клиентов. Главный продукт Codecov предназначен для разработ...
В предыдущей части мы разобрали, как работает политика хранения для заданий первоначального бэкапа и создания его архивной копии. В этой части мы продолжим начатое и рассмотрим хранение н...
Всем привет. Когда я искал информацию о журналировании (аудите событий) в Bitrix, на Хабре не было ни чего, в остальном рунете кое что было, но кто же там найдёт? Для пополнения базы знаний...
Как-то у нас исторически сложилось, что Менеджеры сидят в Битрикс КП, а Разработчики в Jira. Менеджеры привыкли ставить и решать задачи через КП, Разработчики — через Джиру.
Как широко известно, с 1 января 2017 года наступает три важных события в жизни интернет-магазинов.