25 июня 2018
Люди и технологии: вместе эффективнее
Три истории из жизни наших пользователей
Три истории из жизни наших пользователей
Автор: Дмитрий Слиньков
ИТ следит за товарами «от грядки до полки». Звучит фантастично? Да! Часто кажется, что в XXI-м веке наличие компьютера, Интернет и хоть какого-то аналитического софта автоматически приносит всем нам любые необходимые данные. Но не тут-то было. Практика показывает: даже специализированное для отраслевых нужд ПО нуждается в постоянном совершенствовании и понимании.
Под «пониманием» мы имеем в виду вот такие живые истории. Целых три.
Под «пониманием» мы имеем в виду вот такие живые истории. Целых три.
История первая
Поставщик А (вполне себе реальный) совместно с ритейлером Б используют систему CSR.
Исторически, у поставщика А очень хороший показатель взаимодействия с сетью — service level (отношение доставленного объема к заказанному) — на уровне 99,9%. То есть, они всегда могут обеспечить тот объем, который заказывает сеть. Но есть проблема с показателем так называемой «своевременности». Заказ на определенную дату они не могут привезти вовремя. Такие проблемы важно решать вместе с ритейлером. Последний частенько просит нас ему в этом помочь. Приезжаем к поставщику А, открываем «их» систему, показываем в системе поставщику вкладку "Сроки поставки", на ней показаны все заказы с отклонением в один и более дней. Берем период три месяца, смотрим показатель сервис левел — 100%. А сервис левел тайм — чуть более 70%. Это очень мало, очень. Что ж, переходим на вкладку "Контроль поставок на РЦ". На ней представлена информация о поминутной приемке. Получаем информацию из внутренних складских систем самой сети: когда по времени регистрируются машины, когда началась разгрузка палет и когда приемку закрыли. Всё это поминутно там представлено. Вместе смотрим дальше и быстро находим первый блок проблем. Сеть формирует заказы, например, с 23:30, то есть, хочет, чтобы ей привезли заказ «сегодня в 23:30». А время на разгрузку больших заказов — час минимум. Получается, что у клиента «промежуточное» окно между двух суток. И таких заказов у А довольно много. Ещё раз: поставщик приезжает в 23:30, начинается его разгрузка, наступают следующие сутки, поставка принимается следующим днем и... сеть автоматически (и де-факто безосновательно) снижает показатель эффективности сервис левел тайм.
После таких разборов поставщик может аргументированно просить сеть изменить его показатели: «Коллеги, смотрите, вы даёте нам промежуточные окна. Либо меняйте окна так, чтобы они умещались в сутки, либо меняйте алгоритм показателя SLT».
Исторически, у поставщика А очень хороший показатель взаимодействия с сетью — service level (отношение доставленного объема к заказанному) — на уровне 99,9%. То есть, они всегда могут обеспечить тот объем, который заказывает сеть. Но есть проблема с показателем так называемой «своевременности». Заказ на определенную дату они не могут привезти вовремя. Такие проблемы важно решать вместе с ритейлером. Последний частенько просит нас ему в этом помочь. Приезжаем к поставщику А, открываем «их» систему, показываем в системе поставщику вкладку "Сроки поставки", на ней показаны все заказы с отклонением в один и более дней. Берем период три месяца, смотрим показатель сервис левел — 100%. А сервис левел тайм — чуть более 70%. Это очень мало, очень. Что ж, переходим на вкладку "Контроль поставок на РЦ". На ней представлена информация о поминутной приемке. Получаем информацию из внутренних складских систем самой сети: когда по времени регистрируются машины, когда началась разгрузка палет и когда приемку закрыли. Всё это поминутно там представлено. Вместе смотрим дальше и быстро находим первый блок проблем. Сеть формирует заказы, например, с 23:30, то есть, хочет, чтобы ей привезли заказ «сегодня в 23:30». А время на разгрузку больших заказов — час минимум. Получается, что у клиента «промежуточное» окно между двух суток. И таких заказов у А довольно много. Ещё раз: поставщик приезжает в 23:30, начинается его разгрузка, наступают следующие сутки, поставка принимается следующим днем и... сеть автоматически (и де-факто безосновательно) снижает показатель эффективности сервис левел тайм.
После таких разборов поставщик может аргументированно просить сеть изменить его показатели: «Коллеги, смотрите, вы даёте нам промежуточные окна. Либо меняйте окна так, чтобы они умещались в сутки, либо меняйте алгоритм показателя SLT».
История вторая
Раньше их показатель SLT был 60%, сейчас – под 90%
Компания В на протяжении почти трех лет говорит сети, мол «Коллеги, зафиксируйте, пожалуйста, нам окна разгрузки на определенное время. Допустим, на 4 часа утра. Для нас это было бы решением всех проблем: четкие отношения с транспортной компанией, своевременные поставки и высокие показатели, без очередей». Потому что, если поставщик приезжает не вовремя, все планы сбываются. Очень часто это становится огромным снежным комом. Очереди из опоздавших фур — настоящая головная боль для РЦ.
И вот компания В подключается к нашей системе, получают отчетность «день-в-день», стремительно улучшают показатель «сервис левел тайм» до 100% и, благодаря выделенному временному слоту, они всегда успевают делать поставки вовремя. Раньше их показатель SLT был 60%, сейчас – под 90%.
И вот компания В подключается к нашей системе, получают отчетность «день-в-день», стремительно улучшают показатель «сервис левел тайм» до 100% и, благодаря выделенному временному слоту, они всегда успевают делать поставки вовремя. Раньше их показатель SLT был 60%, сейчас – под 90%.
История третья
Те же «окна разгрузки», но вид с немного другого ракурса. Поставщик Д (букву «Г» пропустим — вдруг, кто-то себя узнает и обидится). Его окно — с 14:00 до 15:00. Смотрим в системе и видим, что у него всё больше и больше заказов в 14:15 или даже в 14:30. Возникает ощущение, что Д думает так: если сеть сказала, что окно с 14 до 15, значит это «моё время подъезда».
Вежливо, но настойчиво спрашиваем логистов: «Скажите пожалуйста, что вы понимаете под окном, которое выделяет сеть?»
Специалисты отвечают: «Время, в которое мы должны приехать».
Вот в чем ключевая проблема: они думают, что плановое время — это «окно явки», хотя на самом деле является интервалом выделяемым на полную разгрузку. Рекомендовали приезжать за 15-20 минут до этих выделенных окон: «Как только вы начнете это делать, ваши показатели SLT пойдут вверх. Потому что, когда поставщик приезжает не в выделенные временные окна, он встает в общую очередь».
Вот такие «открытия» делают иногда наши пользователи. Иногда на систему нужно просто взглянуть тщательнее — и она раскроет вам много интересного.
Вежливо, но настойчиво спрашиваем логистов: «Скажите пожалуйста, что вы понимаете под окном, которое выделяет сеть?»
Специалисты отвечают: «Время, в которое мы должны приехать».
Вот в чем ключевая проблема: они думают, что плановое время — это «окно явки», хотя на самом деле является интервалом выделяемым на полную разгрузку. Рекомендовали приезжать за 15-20 минут до этих выделенных окон: «Как только вы начнете это делать, ваши показатели SLT пойдут вверх. Потому что, когда поставщик приезжает не в выделенные временные окна, он встает в общую очередь».
Вот такие «открытия» делают иногда наши пользователи. Иногда на систему нужно просто взглянуть тщательнее — и она раскроет вам много интересного.
Выводы?
Вот так мы работаем над тем, чтобы каждый потребитель получал необходимый ему товар вовремя, в нужном ему месте и по самой оптимальной цене. Не только программируем :)
То есть, мы уже где-то на полпути к этому будущему — «от грядки до полки».
Приобщайтесь — читайте наш блог, регистрируйтесь на тест-драйв системы Click Service Retail.
То есть, мы уже где-то на полпути к этому будущему — «от грядки до полки».
Приобщайтесь — читайте наш блог, регистрируйтесь на тест-драйв системы Click Service Retail.
Photo credit: ria.ru
Читать другие статьи блога