WEBVTT

00:00:00.120 --> 00:00:02.200
Здравствуйте и добро пожаловать в очередной выпуск полезных

00:00:02.200 --> 00:00:04.340
советов от Microsoft на М365FM.

00:00:04.500 --> 00:00:05.980
С вами был ведущий Мирко Петерс.

00:00:06.140 --> 00:00:08.220
Сегодняшняя тема – та, о которой слышал почти каждый,

00:00:08.420 --> 00:00:10.540
кто работает с цепочками поставок, но мало кто действительно

00:00:10.540 --> 00:00:11.120
ее понимает.

00:00:11.260 --> 00:00:13.680
Dynamics 365 Transportation Management.

00:00:13.920 --> 00:00:14.700
Вот в чем проблема.

00:00:14.880 --> 00:00:17.240
Клиент размещает заказ, товар находится на складе,

00:00:17.360 --> 00:00:19.600
перевозчику нужно время для погрузки, клиент ожидает

00:00:19.600 --> 00:00:21.800
доставку, а позже на стол кого-то попадает счет за

00:00:21.800 --> 00:00:22.240
перевозку.

00:00:22.400 --> 00:00:24.240
Годами эти этапы хранились в отдельных электронных

00:00:24.240 --> 00:00:26.620
таблицах, телефонных звонках, прайс-листах и передавались

00:00:26.620 --> 00:00:27.240
между командами.

00:00:27.340 --> 00:00:28.520
И это создает пробелы.

00:00:28.520 --> 00:00:30.660
Склад может подготовить товар до того, как у транспортной

00:00:30.660 --> 00:00:31.560
компании появится план.

00:00:31.700 --> 00:00:33.740
Финансовый отдел может увидеть счет, не зная, за что

00:00:33.740 --> 00:00:34.700
кто-то договорился заплатить.

00:00:34.820 --> 00:00:36.860
Итак, что же такое управление перевозками?

00:00:37.020 --> 00:00:40.900
Проще говоря, это транспортный отдел внутри Dynamics 365 Supply Chain

00:00:40.900 --> 00:00:41.280
Management.

00:00:41.520 --> 00:00:44.140
Он связывает складские помещения, поставщиков, клиентов и

00:00:44.140 --> 00:00:44.640
перевозчиков.

00:00:44.740 --> 00:00:46.760
Мы планируем загрузки, выбираем маршруты и тарифы,

00:00:46.880 --> 00:00:48.600
отправляем товары и проверяем стоимость перевозки.

00:00:48.720 --> 00:00:51.320
К концу этого эпизода вы увидите, как все эти элементы

00:00:51.320 --> 00:00:53.660
складываются воедино, чтобы облегчить вашу работу.

00:00:55.360 --> 00:00:57.940
Зачем существует управление транспортировкой?

00:00:57.940 --> 00:01:00.000
Давайте начнем с основной истины.

00:01:00.160 --> 00:01:03.120
Физические товары не перемещаются просто потому, что на экране

00:01:03.120 --> 00:01:04.100
есть заказ на продажу.

00:01:04.280 --> 00:01:06.980
Им нужен грузовик, прицеп, контейнер или другой способ

00:01:06.980 --> 00:01:07.660
транспортировки.

00:01:07.800 --> 00:01:09.940
Кто-то должен знать, откуда товары отправляются, куда

00:01:09.940 --> 00:01:12.100
они должны прибыть, сколько места они занимают, когда

00:01:12.100 --> 00:01:13.780
они должны отправиться и сколько должна стоить

00:01:13.780 --> 00:01:14.200
поездка.

00:01:14.340 --> 00:01:16.680
Теперь, когда вы представляете себе одну коробку, отправляемую

00:01:16.680 --> 00:01:18.040
одному клиенту, это звучит просто.

00:01:18.200 --> 00:01:20.340
Но реальная компания может отправлять множество заказов

00:01:20.340 --> 00:01:22.480
с одного и того же склада в один и тот же день, получать

00:01:22.480 --> 00:01:24.600
товары от нескольких поставщиков и одновременно перемещать

00:01:24.600 --> 00:01:26.340
запасы между своими собственными площадками.

00:01:26.340 --> 00:01:29.580
Каждое перемещение связано с людьми, датами, пространством

00:01:29.580 --> 00:01:30.160
и деньгами.

00:01:30.340 --> 00:01:32.840
Без общей системы каждая команда видит только свою

00:01:32.840 --> 00:01:33.180
часть.

00:01:33.380 --> 00:01:35.120
Отдел продаж видит заказ клиента.

00:01:35.320 --> 00:01:37.160
Отдел закупок видит заказ поставщика.

00:01:37.340 --> 00:01:39.140
Сотрудники склада видят товары, которые им нужно

00:01:39.140 --> 00:01:41.000
собрать, упаковать, принять или разместить.

00:01:41.160 --> 00:01:42.760
Команда по транспортировке видит список товаров, которые

00:01:42.760 --> 00:01:44.600
необходимо переместить, часто после того, как все остальные

00:01:44.600 --> 00:01:45.580
уже выполнили свою часть работы.

00:01:45.680 --> 00:01:47.740
И именно здесь начинаются задержки и путаница.

00:01:47.900 --> 00:01:48.840
Вот конкретный пример.

00:01:48.980 --> 00:01:51.120
Представьте, что на складе есть 10 заказов от клиентов,

00:01:51.320 --> 00:01:52.680
готовых к отправке в один и тот же город.

00:01:52.680 --> 00:01:54.520
Если никто не свяжет эти заказы до бронирования

00:01:54.520 --> 00:01:56.240
транспорта, компания может организовать несколько

00:01:56.240 --> 00:01:58.060
частично выполненных рейсов, или перевозчик может

00:01:58.060 --> 00:02:00.140
прибыть раньше, чем склад узнает, какие товары должны

00:02:00.140 --> 00:02:00.740
быть в транспорте.

00:02:00.820 --> 00:02:03.080
Товары готовы, но перемещение не спланировано.

00:02:03.220 --> 00:02:05.540
Поэтому управление транспортировкой предоставляет место для

00:02:05.540 --> 00:02:08.460
этого перемещения в Dynamics 365 Supply Chain Management.

00:02:08.640 --> 00:02:10.920
Это не отдельное приложение для доставки товаров потребителям,

00:02:11.000 --> 00:02:13.280
где вы вводите номер отслеживания и наблюдаете за перемещением

00:02:13.280 --> 00:02:14.000
посылки по карте.

00:02:14.160 --> 00:02:16.720
Вместо этого оно работает с бизнес-записями, уже находящимися

00:02:16.720 --> 00:02:17.620
в подключенной платформе.

00:02:17.800 --> 00:02:19.900
Заказ создает потребность в перемещении товаров.

00:02:19.900 --> 00:02:21.740
Работа на складе подготавливает товары.

00:02:21.860 --> 00:02:24.040
Управление транспортировкой планирует, как эти товары

00:02:24.040 --> 00:02:25.540
будут перемещаться между локациями.

00:02:25.640 --> 00:02:28.020
Представьте это как транспортный отдел в офисном здании.

00:02:28.220 --> 00:02:30.420
Отдел продаж приносит запрос от клиента на стол.

00:02:30.580 --> 00:02:32.860
Отдел закупок получает информацию о том, что поставщик

00:02:32.860 --> 00:02:33.440
отправит товары.

00:02:33.620 --> 00:02:35.940
Склад доставляет фактический товар и открывает погрузочные

00:02:35.940 --> 00:02:36.200
ворота.

00:02:36.340 --> 00:02:39.020
Транспортный отдел связывает эти запросы с планом транспортировки

00:02:39.020 --> 00:02:39.400
компании.

00:02:39.640 --> 00:02:41.220
Существует два основных направления.

00:02:41.400 --> 00:02:43.680
Входящая транспортировка означает перемещение товаров

00:02:43.680 --> 00:02:44.200
в ваш бизнес.

00:02:44.400 --> 00:02:47.060
Вы заказали товары у поставщика, и эти товары должны попасть

00:02:47.060 --> 00:02:51.000
на ваш склад. Иногда поставщик контролирует эту поездку, иногда ваша компания организует ее.

00:02:51.120 --> 00:02:55.340
В любом случае, вам нужен четкий план доставки товаров в нужное место и их получение по прибытии.

00:02:55.500 --> 00:02:59.680
Исходящая транспортировка означает перемещение товаров из вашего бизнеса. Клиент заказал

00:02:59.680 --> 00:03:04.340
продукцию, склад подготавливает ее, а перевозчик или служебный автомобиль доставляет ее клиенту.

00:03:04.440 --> 00:03:08.680
Оба потока связаны с перемещением, но отправная точка различается. Входящая начинается с заказа

00:03:08.680 --> 00:03:12.860
на покупку и поставщика. Исходящая начинается с заказа на продажу и клиента. Существует также

00:03:12.860 --> 00:03:16.820
третий тип, который часто упускают из виду новички, заказы на перемещение. Заказ на перемещение

00:03:16.820 --> 00:03:20.740
перемещает запасы между вашими собственными складами. Возможно, на одном складе слишком много

00:03:20.740 --> 00:03:24.820
запасов, и другому складу они нужны. Покупка клиентам не предусмотрена, но физические товары

00:03:24.820 --> 00:03:29.340
все равно нуждаются в транспортировке. В 365 году Transportation Management заказы на перемещение

00:03:29.340 --> 00:03:32.640
относятся к исходящей транспортировке и могут планироваться вместе с заказами на продажу.

00:03:32.760 --> 00:03:36.600
Это становится понятным, если представить себе погрузочную площадку. Независимо от того,

00:03:36.780 --> 00:03:41.000
отправляется ли поллета платящему клиенту или на склад другой компании, кто-то все равно должен

00:03:41.000 --> 00:03:45.000
организовать транспорт, зарезервировать место и отправить ее с того же склада. Таким образом,

00:03:45.000 --> 00:03:49.180
этот взаимосвязанный подход заменяет старую цепочку отдельных списков и телефонных звонков

00:03:49.180 --> 00:03:53.840
общей информацией. Заказ сообщает системе, что нужно перевести. Склад подготавливает товары.

00:03:54.000 --> 00:03:57.880
Управление транспортировкой превращает эту потребность в план транспортировки. Как только товары

00:03:57.880 --> 00:04:02.140
нужно перевести, системе сначала нужен рабочий план отгрузки. Планирование загрузки

00:04:02.140 --> 00:04:06.240
Сегодняшний полезный совет посвящен тому, что необходимо каждой логистической команде,

00:04:06.420 --> 00:04:09.160
но часто объясняется по-разному. Планирование загрузки

00:04:09.160 --> 00:04:12.600
Вы можете начать планирование транспортировки как с заказов, так и с отгрузок.

00:04:12.600 --> 00:04:17.240
Я Мирко Петерс из М365 FM и позвольте мне сразу развеять один миф. План отгрузки не

00:04:17.240 --> 00:04:21.360
начинается с нуля. Он начинается с уже имеющихся у вас записей. Заказ на продажу содержит то,

00:04:21.480 --> 00:04:24.780
что купил клиент. Заказ на покупку перечисляет то, что поставщик должен отправить.

00:04:24.920 --> 00:04:28.580
Отгрузка группирует эти товары в более конкретную запись об отгрузке, готовую к объединению с

00:04:28.580 --> 00:04:32.660
другими. Итак, какую отправную точку следует использовать? Это зависит от того, как работает ваша

00:04:32.660 --> 00:04:36.660
компания. Некоторые команды планируют заранее, непосредственно анализируя позиции заказа. Другие команды

00:04:36.660 --> 00:04:40.380
сначала создают отгрузки, а затем решают, что будет перевозиться вместе. Оба пути приводят к одному

00:04:40.380 --> 00:04:44.200
и тому же вопросу, что должно быть в одном транспортном средстве. Вот самое простое определение.

00:04:44.420 --> 00:04:48.500
Груз — это цифровая запись о запланированном перемещении товаров. Вы можете представить это как

00:04:48.500 --> 00:04:52.460
один грузовик, один прицеп, один контейнер или одну группу грузов, которые перевозятся вместе.

00:04:52.640 --> 00:04:56.380
Это позволяет вам видеть, какие товары должны быть в одной группе, прежде чем начнется физическая

00:04:56.380 --> 00:05:00.600
работа. Теперь вот, что многие понимают неправильно. Груз не означает, что каждый товар помещается в

00:05:00.600 --> 00:05:03.940
одну физическую коробку. Это означает, что система группирует товары в соответствии с одним планом

00:05:03.940 --> 00:05:07.380
транспортировки. Несколько отгрузок клиентам могут перевозиться на одном грузовике. Крупный

00:05:07.380 --> 00:05:11.560
заказ может заполнить весь прицеп. Контейнер, прибывающий от поставщика, также может стать

00:05:11.560 --> 00:05:15.560
грузом еще до того, как ваш склад получит товар. Суть в том, чтобы перестать рассматривать каждый

00:05:15.560 --> 00:05:19.160
заказ как отдельную поездку. Представьте, что у дистрибьютора есть шесть заказов клиентов,

00:05:19.400 --> 00:05:23.320
готовых к доставке в пятницу. Все шесть находятся в одном месте, и каждый заказ занимает только часть

00:05:23.320 --> 00:05:26.420
грузовика. Отправка шести полупустых транспортных средств приводит к нерациональному использованию

00:05:26.420 --> 00:05:29.860
пространства и созданию шести отдельных транспортных заданий. Вместо этого команда может объединять

00:05:29.860 --> 00:05:33.880
совместимые грузы в одну партию. Совместимость означает, что они могут разумно перемещаться вместе.

00:05:34.060 --> 00:05:36.900
Они отправляются с одного склада, должны проехать примерно в одно и то же время, помещаются в

00:05:36.900 --> 00:05:39.600
пределах допустимых размеров транспортного средства и соответствуют вашим правилам перевозки.

00:05:39.760 --> 00:05:43.020
Система помогает объединить эти записи, вместо того, чтобы полагаться на то, что кто-то найдет

00:05:43.020 --> 00:05:46.860
закономерность в электронной таблице. Теперь у этой группы есть общий план. Ваш склад видит,

00:05:47.020 --> 00:05:51.380
что должно быть в грузе. Планировщик перевозок видит общее пространство и вес. Людям не нужно заново

00:05:51.380 --> 00:05:55.600
тот же список в электронных письмах, заметках или отдельном файле. Но вот в чем дело. Группировка

00:05:55.600 --> 00:05:59.420
товаров – это не просто объединение большего количества предметов. У грузовика есть ограничения,

00:05:59.620 --> 00:06:03.540
вес, площадь пола, высота. У контейнера свои правила. Если система группирует товары,

00:06:03.660 --> 00:06:06.820
не проверяя эти ограничения, груз может выглядеть нормально на экране, но не пройти проверку

00:06:06.820 --> 00:06:11.140
на погрузочной площадке. Dynamics 365 использует шаблоны грузов, чтобы помочь избежать этого.

00:06:11.280 --> 00:06:14.760
Представьте себе шаблон груза как многоразовый набор ограничений для определенного типа транспортного

00:06:14.760 --> 00:06:18.740
средства или контейнера. Создайте один для небольшого грузовика, другой для более крупного прицепа,

00:06:18.740 --> 00:06:22.400
еще один для морского контейнера. Каждый шаблон содержит ограничения по весу, объему,

00:06:22.560 --> 00:06:26.640
высоте и другим правилам, необходимым вашей компании. Шаблон определяет форму груза до начала

00:06:26.640 --> 00:06:30.380
его заполнения. Таким образом, если груз весит слишком много или занимает слишком много места,

00:06:30.540 --> 00:06:34.000
планировщик видит, что он не подходит для этой партии. Решением может быть использование второго

00:06:34.000 --> 00:06:37.660
транспортного средства, другого шаблона или другой группировки грузов. Программное обеспечение

00:06:37.660 --> 00:06:41.780
не поднимает поллеты, но оно предоставляет вашей команде более четкий план до начала физической работы.

00:06:42.000 --> 00:06:46.780
Один из встроенных подходов называется формированием груза на основе объема. Это звучит сложнее,

00:06:46.780 --> 00:06:51.260
чем нужно. Это означает, что система использует максимальную высоту и вес из вашего шаблона

00:06:51.260 --> 00:06:55.460
груза при формировании или предложении груза. Проще говоря, она проверяет, соответствуют ли товары

00:06:55.460 --> 00:06:59.420
установленным вами ограничениям. Эти значения не фиксируются навсегда. Планировщик может изменить

00:06:59.420 --> 00:07:03.440
их, когда реальные потребности изменятся. Возможно, перевозчик отправит другой прицеп. Возможно,

00:07:03.680 --> 00:07:08.060
маршрут допускает другую высоту. Шаблон предоставляет стандартное правило, а изменение обрабатывает

00:07:08.060 --> 00:07:12.520
исключение без перестройки всего. Вернемся к этим шести заказам клиентов. Каждый отдельный груз

00:07:12.520 --> 00:07:17.160
может занимать 15% грузовика. При планировании по отдельности можно отправить шесть почти пустых

00:07:17.160 --> 00:07:20.100
автомобилей. Объединив заказы в один груз, можно заполнить большую часть грузовика,

00:07:20.260 --> 00:07:23.500
и еще останется место для дополнительных. Это более эффективное использование пространства.

00:07:23.600 --> 00:07:27.000
Теперь та же идея работает в обоих направлениях. Для планирования входящих перевозок создайте

00:07:27.000 --> 00:07:30.340
груз, состоящий из товаров, поступающих от поставщика. Транспортный план связан с ожидаемым

00:07:30.340 --> 00:07:34.140
поступлением, поэтому склад знает, что должно быть доставлено и готовиться к прибытию. Вместо того,

00:07:34.240 --> 00:07:37.620
чтобы узнавать о доставке только тогда, когда она появляется у ворот, команда приемки имеет

00:07:37.620 --> 00:07:41.100
запланированную запись. Для планирования исходящих перевозок выберите товары со склада,

00:07:41.180 --> 00:07:45.140
которые необходимо отправить клиентам, и сгруппируйте их в груз. Склад подготавливает эти товары

00:07:45.140 --> 00:07:49.320
на основе деталей груза, а не разрозненного списка. Для одного полного груза все еще нужен

00:07:49.320 --> 00:07:54.900
способ транспортировки – компания-перевозчик и ожидаемая стоимость. Маршруты, перевозчики и тарифы

00:07:54.900 --> 00:07:59.780
Теперь груз показывает, что нужно перевозить вместе. Далее вам нужно решить, кто будет перевозить

00:07:59.780 --> 00:08:03.860
груз, какой службой он воспользуется и сколько должна стоить эта поездка. Компания, которая перевозит

00:08:03.860 --> 00:08:06.980
ваши товары, называется перевозчиком. Это может быть сторонняя транспортная компания,

00:08:06.980 --> 00:08:10.180
которая забирает и доставляет ваш груз. Это также может быть ваш собственный автопарк,

00:08:10.300 --> 00:08:13.820
если вы используете собственные грузовики и водителей. В любом случае, перевозчик несет

00:08:13.820 --> 00:08:17.580
ответственность за саму поездку. Это различие важно, потому что вам все равно нужен план,

00:08:17.780 --> 00:08:21.120
даже если грузовик принадлежит вам. При работе со сторонним перевозчиком вы заранее

00:08:21.120 --> 00:08:24.480
согласовываете цены и услуги. При работе со своим собственным автопарком вам все равно может

00:08:24.480 --> 00:08:28.100
потребоваться расчет стоимости транспортировки, особенно если стоимость доставки указана в заказах клиента.

00:08:28.260 --> 00:08:33.940
Dynamics 365 Transportation Management поддерживает обе ситуации. Затем есть маршрут. Маршрут – это запланированный

00:08:33.940 --> 00:08:37.640
путь от места погрузки до места назначения, а также выбор способа доставки. Он отвечает на

00:08:37.640 --> 00:08:42.460
практические вопросы. С какого склада перевозчик забирает груз? Какой клиент или место получает

00:08:42.460 --> 00:08:46.460
товар? Какая транспортная компания осуществляет доставку? Представьте себе доставку с вашего

00:08:46.460 --> 00:08:49.580
основного склада клиенту в другой конец страны. Один маршрут может использовать стандартную

00:08:49.580 --> 00:08:52.640
автомобильную грузоперевозку, которая стоит дешевле, но занимает больше времени. Другой может

00:08:52.640 --> 00:08:56.240
использовать более быструю, но более дорогую услугу. Начальные и конечные точки одинаковы,

00:08:56.360 --> 00:08:59.860
но выбор способа транспортировки меняется. Тариф – это ожидаемая стоимость за этот вариант.

00:08:59.860 --> 00:09:03.800
Это не случайное число, введенное в последнюю минуту. Тарифы формируются на основе ценовых

00:09:03.800 --> 00:09:07.100
соглашений с перевозчиками в сочетании с деталями отгрузки или маршрута. Учитывается место

00:09:07.100 --> 00:09:10.720
отправления груза, место назначения, используемая услуга, объем перевозимого груза. Таким образом,

00:09:10.860 --> 00:09:14.600
маршрут определяет, как должен перемещаться груз. Тариф определяет ожидаемую стоимость доставки.

00:09:14.720 --> 00:09:17.680
Эти два понятия взаимосвязаны, поскольку дешевый маршрут может привести к невыполнению

00:09:17.680 --> 00:09:20.440
обещаний по доставке, а скорость может стоить дороже, чем позволяет объем заказа.

00:09:20.440 --> 00:09:23.560
Планирование транспортировки – это не просто поиск грузовика, это выбор услуги,

00:09:23.740 --> 00:09:26.720
соответствующие обязательствам перед клиентом и правилам ценообразования компании.

00:09:26.900 --> 00:09:31.860
Dynamics 365 включает в себя рабочую область, тарифы и маршруты. Название звучит формально,

00:09:32.080 --> 00:09:36.560
но цель проста. Она предоставляет планировщикам место для сравнения вариантов маршрутов и тарифов

00:09:36.560 --> 00:09:40.440
для отгрузки. Вместо того, чтобы проверять таблицы разных перевозчиков и сравнивать их в отдельном файле,

00:09:40.560 --> 00:09:43.420
вы рассматриваете варианты, связанные с данной потребностью в доставке. Возможно,

00:09:43.580 --> 00:09:47.420
один вариант позволит доставить груз клиенту быстрее. Возможно, другой обойдется дешевле.

00:09:47.420 --> 00:09:50.740
Система не знает, что каждый клиент ценит скорость больше, чем стоимость,

00:09:50.920 --> 00:09:54.340
потому что предприятия работают по-разному. Клиент мог заплатить за срочную доставку,

00:09:54.520 --> 00:09:58.140
поэтому более быстрый маршрут имеет смысл. Другой клиент соглашается на более длительную

00:09:58.140 --> 00:10:01.920
доставку, и более низкая стоимость ему больше подходит. Люди по-прежнему принимают решения.

00:10:02.100 --> 00:10:05.460
Управление транспортом предоставляет вам согласованные варианты и ожидаемые затраты,

00:10:05.600 --> 00:10:10.000
а ваш бизнес – возможность выбора оптимального компромисса. Вот что на самом деле делает встроенный модуль.

00:10:10.140 --> 00:10:13.600
Информация о тарифах поступает из таблиц тарифов, которые ваша компания вводит и поддерживает

00:10:13.600 --> 00:10:17.420
в Dynamics 365. Рассматривайте эти таблицы как сохраненные записи о согласованных ценах

00:10:17.420 --> 00:10:21.040
перевозчиков и правилах маршрутов. Если вы договорились о цене на определенную услугу и маршрут,

00:10:21.200 --> 00:10:24.420
эта информация хранится в системе и поддерживает планирование. Это хорошо работает,

00:10:24.560 --> 00:10:27.940
когда ваши тарифы соответствуют известным соглашениям. Например, вы работаете с несколькими

00:10:27.940 --> 00:10:31.280
постоянными перевозчиками, обслуживаете знакомые маршруты и обновляете цены при изменении

00:10:31.280 --> 00:10:34.500
контрактов. Планировщик транспорта использует уже зарегистрированные тарифы, вместо того,

00:10:34.600 --> 00:10:37.840
чтобы искать их в старых электронных письмах. Но вот что многие неправильно понимают.

00:10:37.840 --> 00:10:41.960
Встроенный модуль не работает как онлайн-магазин, подключенный ко всем перевозчикам. Он не

00:10:41.960 --> 00:10:45.620
автоматически получает свежие цены из текущих источников и не сравнивает их в широкой сети в

00:10:45.620 --> 00:10:48.740
режиме реального времени. Если вашей компании требуется сравнение тарифов нескольких перевозчиков,

00:10:48.820 --> 00:10:51.360
ссылки на бронирование в режиме реального времени или более подробной информации о статусе

00:10:51.360 --> 00:10:55.240
доставки, вы обычно подключаете стороннюю систему. Это не недостаток управления транспортом. Это

00:10:55.240 --> 00:10:59.560
четко определяет его задачу. Эти инструменты обеспечивают структурированные планирования транспортировки

00:10:59.560 --> 00:11:03.400
в рамках управления цепочкой поставок, используя информацию о перевозчике, маршруте и тарифах,

00:11:07.840 --> 00:11:12.120
как карту, где вы вводите один номер отслеживания и наблюдаете, как значок транспортного средства

00:11:12.120 --> 00:11:16.140
едет по дороге. Этот модуль фокусируется на решениях по транспортировке бизнеса, да и во время

00:11:16.140 --> 00:11:19.960
отгрузки. Какие товары перемещаются вместе, какой перевозчик их обрабатывает, какой маршрут

00:11:19.960 --> 00:11:23.780
применяется, сколько должна стоить поездка. После того, как ваша компания выберет этот план,

00:11:23.980 --> 00:11:27.800
складские и транспортные команды должны его реализовать. От двери склада до двери клиента план

00:11:27.800 --> 00:11:31.800
транспортировки полезен только тогда, когда люди могут фактически превратить его в реальную отгрузку.

00:11:31.940 --> 00:11:36.620
Для исходящего заказа поток обычно начинается с того, что клиент что-то покупает. Заказ на продажу сообщает

00:11:36.620 --> 00:11:40.140
бизнесу, что хочет клиент, куда это нужно доставить и когда это должно прибыть. Этот заказ

00:11:40.140 --> 00:11:43.080
становится отгрузкой, и груз присоединяется к запланированной загрузке с другими товарами,

00:11:43.180 --> 00:11:46.980
движущимися по тому же маршруту. Затем склад берет на себя дальнейшую работу. Работники отбирают

00:11:46.980 --> 00:11:50.580
товары со склада, упаковывают их и доставляют в соответствующую зону погрузки. Поскольку груз

00:11:50.580 --> 00:11:54.340
относится к одной партии, команда может видеть, какие товары должны быть отправлены вместе и какой

00:11:54.340 --> 00:11:58.060
перевозчик их заберет. Когда транспортное средство прибывает, товары перемещаются со склада к

00:11:58.060 --> 00:12:01.960
перевозчику, а перевозчик доставляет их клиенту. Каждый этап связан с одной и той же записью о

00:12:01.960 --> 00:12:05.960
перемещении. Это звучит обыденно, но представьте себе старый способ. Сборщик заказов мог работать

00:12:05.960 --> 00:12:09.900
по распечатанному заказу. Планировщик перевозок мог иметь отдельный список, а кто-то у погрузочной

00:12:09.900 --> 00:12:13.020
двери мог просматривать электронную почту, чтобы проверить, какой перевозчик должен забрать

00:12:13.020 --> 00:12:17.400
какие паллеты. Если какая-то деталь менялась, всем требовалась обновленная версия. С управлением

00:12:17.400 --> 00:12:22.000
перевозками груз предоставляет командам общую запись. Склад может видеть товары, связанные с грузом,

00:12:22.120 --> 00:12:25.980
планировщик перевозок может видеть детали отгрузки, а человек, организующий забор груза,

00:12:25.980 --> 00:12:30.200
может видеть запланированного перевозчика и услугу. Вместо того, чтобы передавать несколько бумажных

00:12:30.200 --> 00:12:34.300
списков, люди работают с информацией, связанной с одним и тем же заказом и отгрузкой.

00:12:34.480 --> 00:12:38.640
Вот простой пример. У склада есть заказы для нескольких клиентов в одном и том же районе

00:12:38.640 --> 00:12:42.840
доставки. Один клиент заказал коробки чистящих средств, другой – бумажную продукцию,

00:12:43.040 --> 00:12:46.780
а третий – небольшую партию оборудования. Каждый заказ требует комплектации и упаковки,

00:12:46.920 --> 00:12:50.280
но транспортной команде не нужно рассматривать их как совершенно отдельные рейсы. Они объединяют

00:12:50.280 --> 00:12:53.960
все отправления в один запланированный груз. Сотрудники склада комплектуют каждый заказ,

00:12:53.960 --> 00:12:58.360
правильно упаковывают его и подготавливают к погрузке. В накладной указано, что все эти грузы

00:12:58.360 --> 00:13:02.120
перевозятся вместе. Когда прибывает перевозчик, команда передает товары в рамках одного

00:13:02.120 --> 00:13:05.800
запланированного рейса, вместо того, чтобы в последнюю минуту пытаться подобрать водителя для

00:13:05.800 --> 00:13:10.600
отдельных палет. Клиент по-прежнему получает свой заказ. Однако за кулисами компания запланировала

00:13:10.600 --> 00:13:15.280
эту доставку как часть более крупного рейса. Эта связь помогает складу работать совместно с транспортной

00:13:15.280 --> 00:13:20.500
командой, а не опережать ее или ждать инструкций, которые поступают слишком поздно. Входящие перевозки

00:13:20.500 --> 00:13:25.620
следуют той же идее, только в обратном направлении. Заказ на покупку сообщает вам, что ваша компания

00:13:25.620 --> 00:13:29.940
ожидает товары от поставщика. Когда ваша компания организует перевозку, запланированный входящий

00:13:29.940 --> 00:13:33.940
груз связывает поступающие товары с рейсом до того, как товары достигнут склада. Поставщик

00:13:33.940 --> 00:13:38.480
отправляет груз, перевозчик доставляет его на ваш склад, и склад его принимает. Сотрудники приемки

00:13:38.480 --> 00:13:42.200
могут подготовиться, потому что они знают, что должно прибыть. Они могут сверить запланированную

00:13:42.200 --> 00:13:46.260
загрузку с товарами, прибывшими на склад. Это гораздо понятнее, чем появление грузовика без предупреждения

00:13:46.260 --> 00:13:50.120
и попытки определить, к какому заказу на покупку относятся поллеты. Заказы на перемещение

00:13:50.120 --> 00:13:55.140
также вписываются в этот процесс. Один склад отправляет товар, а другой принимает его. Первый

00:13:55.140 --> 00:14:00.240
склад подготавливает и отправляет товары, а второй ожидает те же товары и принимает их на свой

00:14:00.240 --> 00:14:04.740
склад. В конце этого пути нет внешнего клиента, но компании все равно необходима четкая передача

00:14:04.740 --> 00:14:08.940
информации между двумя складами. Груз связывает работу по отправке и приемке в рамках одного

00:14:08.940 --> 00:14:13.240
запланированного перемещения. Выбор способа доставки клиентам также остается связанным с решением

00:14:13.240 --> 00:14:17.240
о доставке. Если планировщик выбирает более быструю транспортную компанию, потому что клиенту

00:14:17.240 --> 00:14:21.460
срочно нужны товары, этот выбор связан с отгрузкой. Если компания использует более дешевую услугу,

00:14:21.620 --> 00:14:25.640
потому что позволяет дата доставки, этот выбор также связан. Люди могут отследить стоимость доставки

00:14:25.640 --> 00:14:29.400
до маршрута и выбора перевозчика, которые ее определили. Транспортное средство может покинуть

00:14:29.400 --> 00:14:33.860
склад, и товары могут прибыть в целости и сохранности, но работа все еще не закончена. Перевозчик высылает

00:14:33.860 --> 00:14:40.240
счет за перевозку, и кто-то должен его проверить. Расчет стоимости перевозки и сверка. Товар уже отправлен со склада,

00:14:40.240 --> 00:14:45.160
и доставка может быть даже завершена. Затем приходит счет фактура от перевозчика. Этот счет фактура

00:14:45.160 --> 00:14:49.120
нуждается в проверке, поскольку сумма в нем должна соответствовать выбранному компании ранее

00:14:49.120 --> 00:14:53.920
варианту транспортировки, включая перевозчика, маршрут, услугу, детали груза и ожидаемую стоимость

00:14:53.920 --> 00:14:58.940
перевозки. В процессе планирования Dynamics 365 может рассчитать ожидаемую стоимость перевозки на основе

00:14:58.940 --> 00:15:03.700
информации о тарифах компании. Эта ожидаемая сумма дает бизнесу отправную точку до того, как перевозчик

00:15:03.700 --> 00:15:08.800
запросит оплату. Позже перевозчик высылает свой счет за перевозку. Сверка стоимости перевозки означает сравнение

00:15:08.800 --> 00:15:12.720
этого счета фактуры с тарифом и деталями отгрузки, уже зарегистрированными в системе. Проще говоря,

00:15:12.880 --> 00:15:16.240
компания проверяет, выставил ли перевозчик счет на ту сумму, которую компания ожидала за услугу,

00:15:16.340 --> 00:15:20.380
фактически перевисшую товар. Представьте, что в плане указана стоимость в 500 долларов. В счете

00:15:20.380 --> 00:15:24.480
фактуры от перевозчика также указана сумма в 500 долларов, и детали отгрузки совпадают. Этот счет

00:15:24.480 --> 00:15:28.280
фактура имеет четкий путь через процесс проверки, поскольку запись о планировании и счет фактура

00:15:28.280 --> 00:15:32.400
совпадают. Но счета фактуры не всегда соответствуют плану. Возможно, таблица тарифов была неверной,

00:15:32.400 --> 00:15:36.200
Возможно, перевозчик выставил счет за другую услугу, или, возможно, груз изменился после планирования,

00:15:36.360 --> 00:15:38.000
и требуется объяснение причины начисления платы.

00:15:38.120 --> 00:15:41.260
Без связанной записи финансовый отдел может видеть только номер счета фактуры и сумму,

00:15:41.380 --> 00:15:44.520
а затем тратить время на выяснение причин, произошедшего у складской и транспортной команд.

00:15:44.680 --> 00:15:48.260
Управление транспортировкой обеспечивает связь решения о транспортировке с этой проверкой.

00:15:48.400 --> 00:15:52.680
Правила могут сравнивать счет фактуру перевозчика с ожидаемой суммой и информацией о запланированной отгрузке.

00:15:52.820 --> 00:15:56.800
Когда детали соответствуют принятым в компании правилам, счет фактура может быть одобрен.

00:15:56.800 --> 00:16:00.560
Если детали не соответствуют, система отправляет расхождение на проверку.

00:16:00.680 --> 00:16:03.940
Это означает, что люди не утверждают каждую плату за перевозку вслепую.

00:16:04.080 --> 00:16:07.540
Планировщику транспортировки может потребоваться подтвердить, что перевозчик использовал другую услугу,

00:16:07.600 --> 00:16:11.000
или сотруднику финансового отдела может потребоваться выяснить, почему появилась дополнительная плата.

00:16:11.180 --> 00:16:14.340
Смысл не в том, чтобы предполагать, что каждое несоответствие является неправильным, не так ли?

00:16:14.440 --> 00:16:16.680
Смысл в том, чтобы заметить несоответствие до оплаты.

00:16:16.760 --> 00:16:19.540
Это объединяет операционные и финансовые отделы вокруг одной и той же отгрузки.

00:16:19.700 --> 00:16:21.880
Транспортная команда выбирает перевозчика и услугу.

00:16:21.880 --> 00:16:23.880
Этот выбор определяет ожидаемую стоимость.

00:16:24.080 --> 00:16:26.880
Склад отправляет товары, а финансовый отдел проверяет последующий счет фактуру,

00:16:27.040 --> 00:16:29.240
сопоставляя его с записями о запланированных компаниях и операциях.

00:16:29.320 --> 00:16:32.720
Каждая команда видит свою часть, но они рассматривают взаимосвязанную информацию.

00:16:32.940 --> 00:16:35.120
Встроенный процесс имеет четкую область применения.

00:16:35.300 --> 00:16:38.960
Компании, которым необходим крупномасштабный, высокоавтоматизированный аудит грузоперевозок,

00:16:39.140 --> 00:16:41.260
часто добавляют стороннюю систему управления транспортом.

00:16:41.400 --> 00:16:45.740
Эти инструменты могут обеспечить более тесную связь с перевозчиками и более автоматизированные правила проверки.

00:16:45.740 --> 00:16:50.020
Встроенный модуль обрабатывает плановые затраты и сверку в рамках управления цепочкой поставок,

00:16:50.140 --> 00:16:53.760
в то время как другая система может расширить эту работу, когда бизнесу это необходимо.

00:16:54.000 --> 00:16:57.620
Соедините все эти компоненты вместе, и начнет вырисовываться полная картина,

00:16:57.740 --> 00:16:59.800
показывая, где он находится и чего не делает.

00:16:59.960 --> 00:17:02.680
Итак, где же на самом деле находится управление транспортом?

00:17:02.820 --> 00:17:05.760
Оно должно быть частью системы управления цепочкой поставок Dynamics 365,

00:17:06.080 --> 00:17:07.820
работающей на приложениях для финансов и операций.

00:17:07.900 --> 00:17:09.760
Это его дом. Вот кому оно подходит.

00:17:09.900 --> 00:17:12.960
Компаниям, которым необходим структурированный способ планирования входящих поставок,

00:17:12.960 --> 00:17:15.900
исходящих от грузок клиентам, перемещения запасов между площадками компаний,

00:17:16.040 --> 00:17:19.240
используя при этом собственные записи о перевозчиках, таблицы тарифов и правила загрузки.

00:17:19.340 --> 00:17:22.160
Теперь давайте проясним распространенный момент, вызывающий путаницу.

00:17:22.340 --> 00:17:23.560
Бизнес-централ отличается.

00:17:23.740 --> 00:17:26.720
В бизнес-централ нет встроенного модуля управления транспортировкой.

00:17:26.840 --> 00:17:29.480
Если вы используете бизнес-централ и вам нужно планирование транспортировки,

00:17:29.620 --> 00:17:31.720
вы обращаетесь к сторонней системе управления транспортировкой.

00:17:31.820 --> 00:17:32.740
Это и есть граница.

00:17:32.920 --> 00:17:35.160
Давайте также четко обозначим границу с другой стороны.

00:17:35.360 --> 00:17:37.100
Встроенный модуль не заменяет все порталы перевозчиков,

00:17:37.100 --> 00:17:40.040
сервисы отслеживания трафика в реальном времени или расширенные инструменты отслеживания.

00:17:40.180 --> 00:17:42.240
Когда компании нужны актуальные тарифы от множества перевозчиков,

00:17:42.340 --> 00:17:45.160
более широкий выбор перевозчиков или более глубокое отслеживание после отгрузки товаров,

00:17:45.280 --> 00:17:47.320
она подключается к сторонней системе управления транспортировкой.

00:17:47.440 --> 00:17:49.500
Эти инструменты обрабатывают внешние операции.

00:17:49.720 --> 00:17:50.980
Вспомните офисные здания.

00:17:51.180 --> 00:17:54.020
Управление транспортировкой – это транспортный отдел внутри этого здания.

00:17:54.200 --> 00:17:56.860
Он связан с заказами, складскими операциями и финансами.

00:17:57.000 --> 00:17:59.320
Он объединяет собственный план транспортировки компании.

00:17:59.560 --> 00:18:03.040
Внешние инструменты перевозчиков могут обрабатывать операции за пределами этого отдела.

00:18:03.040 --> 00:18:09.120
Два разных уровня работают вместе. Заключение. Следующий важный момент. Вот как это проще

00:18:09.120 --> 00:18:12.940
всего представить. Управление транспортировкой преобразует заказы компании в запланированное

00:18:12.940 --> 00:18:16.120
перемещение товаров. Затем оно связывает это перемещение с затратами на перевозку,

00:18:16.260 --> 00:18:20.340
которые компания проверяет впоследствии. Это полный цикл. Подпишитесь на подкаст на вашей

00:18:20.340 --> 00:18:25.440
любимой платформе. Поделитесь этой полезной информацией с тем, кто изучает Dynamics 365 Supply Chain

00:18:25.440 --> 00:18:29.320
Management. Затем посмотрите наши эпизоды о складском хозяйстве и инвентаризации. Каждая

00:18:29.320 --> 00:18:32.100
партия товара по-прежнему зависит от запасов, находящихся за дверями склада.