Здравствуйте и добро пожаловать в очередной выпуск полезных советов от Microsoft на М365FM. С вами был ведущий Мирко Петерс. Сегодняшняя тема – та, о которой слышал почти каждый, кто работает с цепочками поставок, но мало кто действительно ее понимает. Управление транспортировкой в Dynamics 365. Вот в чем проблема. Клиент размещает заказ, товар находится на складе, перевозчику нужно время для погрузки, клиент ожидает доставку, а позже на стол кого-то попадает в счет за перевозку. Годами эти этапы хранились в отдельных электронных таблицах, телефонных звонках, при искурантах и передавались между командами. И это создает пробелы. Склад может подготовить товар до того, как у транспортной компании появится план. Финансовый отдел может увидеть счет, не зная, за что кто-то договорился заплатить. Итак, что же такое управление транспортировкой? Проще говоря, это транспортный отдел внутри Dynamics 365 Supply Chain Management.

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

Каждое перемещение связано с людьми, датами, пространством и деньгами. Без общей системы каждая команда видит только свою часть. Отдел продаж видит заказ клиента. Отдел закупок видит заказ поставщика. Сотрудники склада видят товары, которые им нужно собрать, упаковать, принять или разместить. Команда по транспортировке видит список товаров, которые необходимо переместить, часто после того, как все остальные уже выполнили свою часть работы. И именно здесь начинаются задержки и путаница. Вот конкретный пример. Представьте, что на складе есть 10 заказов от клиентов, готовых к отправке в один и тот же город. Если никто не свяжет эти заказы до бронирования транспорта, компания может организовать несколько частично выполненных рейсов, или перевозчик может прибыть раньше, чем склад узнает, какие товары должны быть в транспорте. Товары готовы, но перемещение не спланировано. Поэтому управление транспортировкой предоставляет место для этого перемещения в Dynamics 365 Supply Chain Management.

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

Иногда поставщик контролирует эту поездку, иногда ваша компания организует ее. В любом случае, вам нужен четкий план доставки товаров в нужное место и их получение по прибытии. Исходящая транспортировка означает перемещение товаров из вашего бизнеса. Клиент заказал продукцию. Склад подготавливает ее, а перевозчик или служебный автомобиль доставляет ее клиенту. Оба потока связаны с перемещением, но отправная точка различается. Входящая начинается с заказа на покупку и поставщика. Исходящая начинается с заказа на продажу и клиента. Существует также третий тип, который часто упускают из виду новички – заказы на перемещение. Заказ на перемещение перемещает запасы между вашими собственными складами. Возможно, на одном складе слишком много запасов, и другому складу они нужны. Покупка клиентам не предусмотрена, но физические товары все равно нуждаются в транспортировке. В 365 году Transportation Management заказы на перемещение относятся к исходящей транспортировке и могут планироваться вместе с заказами на продажу.

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

Он начинается с уже имеющихся у вас записей. Заказ на продажу содержит то, что купил клиент. Заказ на покупку перечисляет то, что поставщик должен отправить. Отгрузка группирует эти товары в более конкретную запись об отгрузке, готовую к объединению с другими. Итак, какую отправную точку следует использовать? Это зависит от того, как работает ваша компания. Некоторые команды планируют заранее, рассматривая непосредственно строки заказа. Другие команды сначала создают заказы, а затем решают, что будет перевозиться вместе. Оба пути приводят к одному и тому же вопросу, что должно быть в одном транспортном средстве. Вот самое простое определение. Груз — это цифровая запись о запланированном перемещении товаров. Вы можете представить это как один грузовик, один прицеп, один контейнер или одну группу грузов, которые перевозятся вместе. Это позволяет вам видеть, какие товары должны быть вместе, прежде чем начнется физическая работа.

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

Они отправляются с одного склада, должны проехать примерно в одно и то же время, помещаются в пределах допустимых размеров транспортного средства и соответствуют вашим правилам отгрузки. Система помогает объединить эти записи, вместо того, чтобы полагаться на то, что кто-то найдет закономерность в электронной таблице. Теперь у этой группы есть общий план. Ваш склад видит, что должно быть в грузе. Планировщик перевозок видит общее пространство и вес. Людям не нужно заново создавать тот же список в электронных письмах, заметках или отдельном файле. Но вот в чем дело. Группировка товаров – это не просто добавление большего количества товаров. У грузовика есть ограничения – вес, площадь пола, высота. У контейнера свои правила. Если система группирует товары, не проверяя эти ограничения, груз может выглядеть нормально на экране, но не пройти проверку на погрузочной площадке. Dynamics 365 использует шаблоны грузов, чтобы помочь избежать этого.

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

Проще говоря, она проверяет, соответствуют ли товары установленным вами ограничениям. Эти значения не фиксируются навсегда. Планировщик может изменить их, когда реальные потребности изменятся. Возможно, перевозчик отправит другой прицеп. Возможно, маршрут допускает другую высоту. Шаблон предоставляет стандартное правило, а изменение обрабатывает исключение без перестройки всего. Вернемся к этим шести заказам клиентов. Каждый отдельный груз может занимать 15% грузовика. При планировании по отдельности можно отправить шесть почти пустых автомобилей. Объединив заказы в один груз, можно заполнить большую часть грузовика, и еще останется место для дополнительных. Это более эффективное использование пространства. Теперь та же идея работает в обоих направлениях. Для планирования входящих перевозок создайте груз, состоящий из товаров, поступающих от поставщика. Транспортный план связан с ожидаемым поступлением, поэтому склад знает, что должно быть доставлено и готовиться к прибытию.

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

В любом случае, перевозчик несет ответственность за саму поездку. Это различие важно, потому что вам все равно нужен план, даже если грузовик принадлежит вам. При работе со сторонним перевозчиком вы заранее согласовываете цены и услуги. При работе со своим собственным автопарком вам все равно может потребоваться расчет стоимости транспортировки, особенно если стоимость доставки указана в заказах клиента. Dynamics 365 Transportation Management поддерживает обе ситуации. Затем есть маршрут. Маршрут – это запланированный путь от места погрузки до места назначения, а также выбор способа доставки. Он отвечает на практические вопросы. С какого склада перевозчик забирает груз? Какой клиент или место получает товар? Какая транспортная компания осуществляет доставку? Представьте себе доставку с вашего основного склада клиенту в другой конец страны. Один маршрут может использовать стандартную автомобильную грузоперевозку, которая стоит дешевле, но занимает больше времени.

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

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

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

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

От двери склада до двери клиента план транспортировки полезен только тогда, когда люди могут фактически превратить его в реальную отгрузку. Для исходящего заказа поток обычно начинается с того, что клиент что-то покупает. Заказ на продажу сообщает бизнесу, что хочет клиент, куда это нужно доставить и когда это должно прибыть. Этот заказ становится отгрузкой, и груз присоединяется к запланированной загрузке с другими товарами, движущимися по тому же маршруту. Затем склад берет на себя дальнейшую работу. Работники отбирают товары со склада, упаковывают их и доставляют в соответствующую зону погрузки. Поскольку груз относится к одной партии, команда может видеть, какие товары должны быть отправлены вместе и какой перевозчик их заберет. Когда транспортное средство прибывает, товары перемещаются со склада к перевозчику, а перевозчик доставляет их клиенту. Каждый этап связан с одной и той же записью о перемещении.

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

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

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

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

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

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

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

Итак, где же на самом деле находится управление транспортом? Оно должно быть интегрировано в Dynamics 365 Supply Chain Management, работающую на приложениях Finance & Operations. Это его дом. Вот кому он подходит. Компаниям, которым необходим структурированный способ планирования входящих поставок, исходящих от грузок клиентам, перемещения запасов между площадками компании, используя при этом собственные записи о перевозчиках, таблице тарифов и правила загрузки. Теперь давайте проясним распространенное заблуждение. Бизнес-централ отличается. В бизнес-централ нет встроенного модуля управления транспортировкой. Если вы используете бизнес-централ и вам нужно планирование транспортировки, вы обращаетесь к сторонней системе управления транспортировкой. Это и есть граница. Давайте также четко обозначим границу с другой стороны. Встроенный модуль не заменяет все порталы перевозчиков, сервисы отслеживания грузов в реальном времени или расширенные инструменты отслеживания.

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

Поделитесь этой полезной информацией с тем, кто изучает Dynamics 365 Supply Chain Management. Затем посмотрите наши эпизоды о складском хозяйстве и инвентаризации. Каждая партия товара по-прежнему зависит от того, что находится за дверью склада.