Как сократить автопарк на 23% и повысить качество доставки? Результаты внедрения TMS-системы в «ОМА»

Андрей Мыльников — инженера-программиста 1С «Интернет-строй гипермаркета ОМА». Евгений Маркевич — эксперт в области интеграции и внедрения программных продуктов «Infinium»

Вступительное слово

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

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

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

Первый этап — анализ каналов продаж как ключевой этап внедрения логистической системы

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

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

Второй этап — от файлового обмена к автоматизации: пошаговый подход к интеграции

Вторым этапом была интеграция с ERP-системой. Но здесь, наверное, не совсем правильно будет сказать вторым. Она шла у нас параллельно с третьим этапом. В связи с тем, что на уровне законодательства клиент «ОМА» был обязан перейти работать на защищенную систему. О защите персональных данных уже говорил Михаил Алексеевич.

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

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

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

Третий этап — оптимизация B2C-доставки: зонирование и управление распределенной сетью складов

Третьим этапом была настройка общего модуля TMS. Здесь бы я хотел остановиться на настройке зонирования на карте для B2C доставки и создании необходимых складов с требуемыми параметрами. Для чего было зонирование? У клиента есть такой тип доставки, как розничный клиент. Это заказы, которые оформляются непосредственно в магазине, и, соответственно, специалистом на карте были отрисованы географические зоны доставки. И, когда клиент оформлял розничную доставку в магазине, специалист торгового зала добавлял заказы на карту, и в той зоне, в которой данный адрес находился. На основании этой зоны начислялась стоимость доставки. Это упростило работу и, в целом, ускорило процесс обработки входящих заявок.

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

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

Цели, которые стояли при внедрении TMS: унификация логистических процессов, сокращение расходов, повышение прозрачности и контроля

Далее рассмотрим цели, которые у нас стояли при внедрении TMS. Цели объединю в три группы. Первая группа — это унификация логистических процессов. Важно было достичь единообразия маршрутизации каналов продаж полностью, чтобы было единое рабочее пространство логиста и единая программная инфраструктура. То есть ранее во время маршрутизации логисту либо диспетчеру было необходимо, допустим, производить мониторинг транспорта в одном ПО, строить маршруты по одному каналу продаж в другом ПО, по третьему каналу продаж в третьем, что, в принципе, затрудняло работу.

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

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

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

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

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

Объективность построения маршрутов: 95% маршрутов без участия логиста и автоматизация получения статусов водителями

На данный момент система, я думаю, где-то на 95% строит маршруты автоматически, без какого-то субъективного мнения логиста. Потому что часто встречалось, что есть ситуация: «Я с тобой дружу, ты мой любимчик, ты сегодня поедешь сюда. А с тобой не дружу, ты сегодня поедешь туда». Соответственно, теперь маршруты строятся на 95% системой. Единственное, какие-то корректировки в приоритетности заказа, там загрузки, не загрузки, это уже определяет логист со своей стороны.

И автоматизация получения статусов. Каждый водитель пользуется мобильным приложением BTS Routе, в котором детально отображены статусы по заказу, то есть он выезжает на заказ, нажал «поехали», это видит и диспетчер, эти статусы видно и в 1С.

Нажал «приехал», «завершил», и видно, заказ вообще был завершен, он завершен успешно, либо он по какой-то причине был завершен с отказом. Причина в том числе тоже указывается.

Разработка расширенного фильтра: гибкая маршрутизация для сложной логистики «OMA»

Третья часть — это разработки Infinium для клиента — компании «OMA».

Первая разработка — это был разработанный расширенный фильтр с множественным выбором. Что он дал? Из-за того, что каждый канал продаж имеет свои особенности, то есть можно фильтровать не только по каналу продаж. Допустим, я хочу выбрать «опт», можно фильтровать по любым текстовым полям, по любым данным, которые есть. То есть логист в момент маршрутизации может отобрать по любому параметру любой пул заказов и его маршрутизировать, и с ним работать в течение дня. Также есть у логиста возможность этот расширенный фильтр в течение дня менять, расширить диапазон дат, фильтровать по какому-то другому параметру: по складу отгрузки, с подъемом, без подъема он едет там и так далее.

Общая боль – контроль доставки, группировка заказов и мгновенные уведомления, исключающие ошибки

Одно из ключевых — группировка заказа в приложении — это такая, наверное, общая боль не только клиента «OMA», но, наверное, и других. Как это работает? В приложении есть возможность группировать либо склады загрузки, либо адреса, куда мы едем, либо и то, и другое.

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

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

То есть водитель в приложении BTS Routе заходит в заказ, который нужно загрузить, у него сразу есть переход на товары, которые нужно доставить. И он, соответственно, смотрит. Если чего-то нет, есть кнопка редактирования заказа. Он нажимает, и ответственному лицу в течение нескольких секунд уходит уведомление, что этого товара нет по какой-то причине. Если, допустим, там какой-то брак, можно приложить фотографию, сфотографировать и оперативно реагировать на ситуацию, чтобы не привезти клиенту то, чего он не ожидал, либо не довезти заказ в полном объеме.

10% прироста грузоподъемности без нарушений: алгоритм оптимизации загрузки транспорта

И модуль поставщиков при промежуточной загрузке заказа, здесь попрошу внимание обратить на график. Видно, что максимальная грузоподъемность автомобиля у нас изначально была 1,5 тонны, 1500 килограмм. По итогу одного рейса максимальная грузоподъемность была увеличена почти на 10%.

За счет чего? Я говорил, что у «ОМА» большое количество складов, может быть большая загрузка в одном рейсе. То есть, может быть, 3, 4, 5 складов, в зависимости от того, где находятся товары, и, соответственно, какая зона обслуживания к тому либо иному складу относится.

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

Вот, коллеги, я хотел бы дальше передать свое слово Андрею, он расскажет о показателях эффективности и особенностях интеграции с 1С.

Благодарю, Евгений. Добрый день, коллеги. Меня зовут Андрей Мыльников, я инженер-программист 1С компании «ОМА». В проекте по внедрению 1С я в том числе занимался разработкой архитектуры и непосредственной разработкой функциональности взаимодействия с 1С посредством API. Сегодня я хочу рассказать о том, каким образом у нас устроена конфигурация 1С, какие объекты конфигурации участвуют в целом в работе, и как в целом наши показатели эффективности, благодаря сотрудничеству с TMS Infinium, выросли и в целом покажу на примерах.

Интеграция 1С и TMS: как синхронизируются справочники, заявки и рейсы

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

И справочник сотрудников — это непосредственно логисты, которые работают с TMS. Здесь была реализована следующая вещь: при изменении любых карточек или элементов этих справочников формируется соответствующий запрос, который приводит к изменениям этих значений в TMS. Например, при заведении нового автомобиля в TMS формируется этот автомобиль с теми реквизитами, которые заполнил логист: грузоподъемность, объем грузового отсека и так далее.

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

Это могут быть документы: счет, заказ покупателя и так далее. Для некоторых случаев это может быть обработка. И в результате работы с этими документами возникает единая, скажем, логистическая единица, в которой работает именно транспортная логистика «ОМА». Этот документ называется «заявка на доставку». Он представляет собой в целом аналог заказа в TMS и характеризуется всеми теми необходимыми параметрами, которые необходимы для маршрутизации, то есть плановая дата, это точка погрузки, точка разгрузки, это масса, это объем перевозимого груза, это состав этой заявки и так далее.

И после того, как эти заявки в каком-то количестве были включены в маршрут, возникает документ «рейс», который по сути является аналогом маршрута TMS. Он включает в себя заявки, консолидирует их, и на основании рейса впоследствии формируется акт оплаты транспортных услуг.

Интеграция 1С и TMS: как синхронизируются справочники, заявки и рейсы

Кроме справочников, документов, при взаимодействии с TMS у нас имеются в наличии регистры, сделаны специально для целей взаимодействия по API. Это регистр сведений, который называется «фиксация состояния заявок» и «фиксация состояния рейсов». Я чуть подробнее расскажу, для каких целей они нужны. И, собственно, регламентное задание, которое автоматизирует работу по API.

Это регламентное задание для создания заявок, для создания обновлений рейсов и получения актуальных статусов. Более подробно по работе с заявками. У нас есть регламентное задание, которое выполняется каждые 15 минут. Это регламентное задание работает следующим образом. То есть, вначале мы получаем выборку тех заявок, которые подлежат выгрузке из TMS. На сегодняшний день специфика компании предусматривает выгрузку заявок с плановой датой доставки сегодня плюс 4 дня включительно.

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

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

Прогнав эту выборку через этот регистр, мы понимаем, что у нас есть определенный массив заявок для создания, определенный массив для обновления и для удаления. Далее регламентное задание формирует объект JSON на основании тех значений, которые были зафиксированы в этой заявке и отправляет их по API в TMS. Если интересно, могу коротко сказать, что такое JSON.

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

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

Здесь, в принципе, похожий механизм, только в данном случае мы обрабатываем уже распределенные, смаршрутизированные в TMS маршруты, тоже посредством API, с расписанием 1 раз в 30 минут это регламентное задание выполняется. Каким образом оно работает? Мы получаем список ранее распределенных логистом маршрутов – тех маршрутов, которые также удовлетворяют нашим условиям: это сегодня плюс 4 дня включительно и это те маршруты, которые заблокированы, то есть на них оставлен замочек.

Это означает, что маршрут… В целом, логист предполагает, что он финализирован и в таком состоянии должен быть выполнен. Далее регламентное задание сравнивает те полученные из TMS данные с теми данными, которые у нас в нашей учетной системе хранятся. Здесь как раз участвует тот регистр сведений, про который я говорил, это фиксация состояния рейса.

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

Это также может быть полезно в тех случаях, когда мы хотим получить рейс за какой-то прошлый период, либо рейс, например, который сформирован, скажем, на неделю вперед, чтобы он был в нашей учетной системе, чтобы мы не дождались, пока наступит его плановая дата, которая попадёт в наш диапазон. Последнее регламентное задание, оно выполняется каждые 5 минут. Его задача заключается в том, что мы получаем актуальные статусы, про которые говорил Евгений, статусы курьер может отметить в своем приложении BTS Routе, по какой-то причине там он может установить статус «отказ», либо наоборот «успех». Также статус может установить диспетчер в своем рабочем кабинете.

И эти статусы мы забираем из TMS посредством API каждые 5 минут. Сравниваем те статусы, которые были получены из TMS с теми, которые были зафиксированы в нашей учетной системе. В случае, если эти статусы совпадают, мы пропускаем такую заявку, если статус отличается, записываем новое значение. Таким образом, это регламентное задание позволяет нам всегда поддерживать актуальную информацию для заказчика перевозки.

Показатели эффективности внедрения TMS: на 24% меньше рейсов, на 9% выше утилизация

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

Значит, при маршрутизации вручную без использования TMS логистами количество рейсов, условно, это 100%, ну, предположим, 10 штук. После того, как мы внедрили TMS и стали использовать его, количество рейсов в среднем упало на 23,9%, ну, ориентировочно на 24.

Транспортные расходы за аналогичный период со 100% упали до 94,8%. Здесь надо понимать, что за месяц, на самом деле, на дистанции это существенная величина, поскольку это и сокращение расходов на амортизацию, на ГСМ, все остальные, связанные с транспортом показатели. Дальше, средняя утилизация транспорта у нас выросла на 9%. Здесь средняя утилизация взята бОльшая величина между утилизацией по массе и утилизацией по объему. И средняя масса рейсов примерно на 24% «приросла» за аналогичный период, за месяц.

Здесь выборка за 4 дня на примере канала B2B. Мы можем увидеть, что в среднем в разрезе дней количество рейсов при маршрутизации вручную составляло 22, 36, 29, при маршрутизации посредством TMS их количество снизилось в среднем на 27%.

Итоги внедрения TMS

Теперь я хочу подвести итоги нашего выступления с Евгением. После того как мы, можно сказать, внедрили и закрыли проект внедрения TMS, были достигнуты наши заявленные изначально к проектам цели: это унификация логистических процессов, были оптимизированы транспортные расходы, был обеспечен контроль и прозрачность работы наемного транспорта в частности, и полностью реализованы технические средства взаимодействия нашей учетной системы 1С и TMS посредством API. Благодарю за внимание. Спасибо. Если есть вопросы, пожалуйста.

ВОПРОСЫ:

ВОПРОС 1. Сколько составили затраты на внедрение системы и через сколько они у вас окупились?

– Добрый день. «Мингаз». Меня зовут Сергей. Скажите: сколько составили затраты на внедрение системы этой и через сколько они у вас окупились?

– Затраты имеются ввиду трудозатраты команды разработчиков?

– Нет. Затраты на оборудование автомобилей, затраты на внедрение, на программное обеспечение. Финансовые затраты, связанные с внедрением системы?

ОТВЕТ

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

ВОПРОС 2. Как окупилось, какие сроки внедрения этой программы, этого модуля?

– «Коммунарка».  Я, может быть, в продолжение вопроса Сергея. Если это является коммерческой тайной, информация непосредственно о затратах, тогда расскажите, как окупилось, какие сроки внедрения этой программы, этого модуля?

ОТВЕТ

– Ну, можно сказать, что когда в целом у нас была разработана наша интеграция посредством API, когда мы заработали в целом с TMS по всем каналам доставки, логисты начали маршрутизировать доставки, с момента начала разработки до полного, так скажем, завершения на сегодняшний день это составило около двух с половиной месяцев. В этот срок входит и проработка архитектуры, именно если говорить про техническую часть, и разработка самого функционала, то есть элементарных заданий, подготовка этих документов и связанных с ними технических вопросов. Естественно, какие-то финансовые показатели начали меняться в положительную сторону именно после того, как мы завершили вот эти все работы, связанные с разработками нашей учетной системы; те доработки, про которые говорил Евгений, в целом, они тоже были востребованы, и к моменту, когда мы уже получили в готовом виде этот функционал, в среднем прошло два с половиной-три месяца.

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

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

ОТВЕТ

–  Выдать заказы, которые ранее были уже загружены?

–  Да, совершенно верно.

– Ну, отвечу сразу на второй вопрос. Это вообще зависит от габарита груза и какой транспорт непосредственно ездит.

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

Вот. Касательно первого вопроса это про управление двором. Андрей, может здесь более подробно про склад рассказать.

– Ну, что касается склада, здесь специфика такая.

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

И поэтому именно в этом контексте нагрузка на склад, можно сказать, что она была оптимизирована, поскольку если мы маршрутизируем непосредственно TMS, мы можем допускать какие-то субъективные ошибки. Да, в маршруте мы можем потом это переделывать. Это приводит к тому, что на складе необходимо менять приоритеты сборки, необходимо освобождать один участок, потом другой, потом перемешивать этот товар.

В целом, вот, именно в этом смысле внедрение TMS помогло снизить нагрузку на склад.

ВОПРОС 4. Как вы организовывали систему отклонений от построенного маршрута, если происходили какие-то сбои передачи данных, то есть, скажем так, датчик где-то перестал работать по маршруту?

– Здравствуйте. Компания «Туровский молочный комбинат». Скажите, пожалуйста, как вы организовывали систему отклонений от построенного маршрута в транспорте, если происходили какие-то сбои передачи данных, то есть, скажем так, датчик где-то перестал работать по маршруту? У нас есть такие области. В этом случае, если есть отклонения от того, что мы готовы были наемным перевозчикам заплатить, и они не согласны с этим.

– Как, Андрей? Или мне рассказать?

– Ну, это, скорее, такой организационный вопрос, касающийся логистики. Тут я, наверное, не могу подсказать именно в полном объеме на ваш вопрос, дать ответ, поскольку я именно работаю с 1С. Вот. Этот вопрос можно будет адресовать нашим коллегам. Здесь присутствуют сотрудники управления логистикой, в частности, руководитель отдела аналитики. Вот. Поэтому как-то так.

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

ВОПРОС 5. Водитель является ответственным лицом, то есть после его уведомления уже происходят какие-то действия с заказом в 1С, и там уже принимают решения другие. То есть, не может ли это повлиять на решение некоторых вопросов с водителем, который захочет решить в свою пользу?

– День добрый. Меня зовут Владислав. Представляю «Мамонт».

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

ОТВЕТ

– Здесь следующим образом построена работа. Если у нас получат статус, что какой-то из товаров в составе доставки отсутствует, бракован, любые другие причины, в 1С это будет отражено на уровне просто статуса доставки, потому что она завершена, например, по каким-то объективным причинам. Ну, имею в виду, завершена в части того товара, который отсутствует.

– Но не в полном объеме, да?

– Да, да. Вот. И здесь как бы на стороне 1С в этом плане все. Дальше все дальнейшие действия уже организованы на самих торговых объектах, на складах. И, ну, большая часть, наверное, таких случаев — это просто замена того товара, который отсутствует либо по каким-то причинам не может быть доставлен, либо в целом отказ от его доставки.

ВОПРОС 6. Как изменился уровень сервиса? Мерили или нет? Как учитываете ситуацию на дорогах? Как программа «под капотом» отрабатывает вообще? Какие карты берет? Можете пояснить?

– Да, Демидов Иван, «Armtek» компания. Два вопроса.

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

ОТВЕТ

– Про сервис? Ну, у меня нет на сегодняшний момент объективных данных про уровень сервиса, но, как я уже говорил, есть сотрудники отдела аналитики, которым можно будет просто адресовать.

ВОПРОС 7. Учитывается ли конфликтность материалов? Допустим, кирпичи нельзя грузить на верх лампочек.

– Константин, «Мамонтбай». Учитывается ли конфликтность материалов? Допустим, кирпичи нельзя грузить на верх лампочек.

ОТВЕТ

– Ну, товарное соседство, да, имеете? Ну, это можно учесть, задав определенный тег. Да, то есть, если в одной машине вы везете кирпичи, понятно, что в этой машине вы уже лампочки не повезете либо какой-то хрупкий товар. Поэтому на стороне TMS задается тег, что такая-то машина везет такую-то группу товаров, такая-то – такую группу товаров. Соответственно, они между собой не пересекаются.

Смотрите полное видео выступления на нашем YouTube-канале!