WEBVTT

00:00:00.000 --> 00:00:04.360
Вітаємо вас на ще одному епізоді Microsoft Knowledge Nuggets, тут на М365FM.

00:00:04.480 --> 00:00:05.980
Ваш ведучий Мірко Пітерс.

00:00:06.120 --> 00:00:10.900
Сьогоднішня тема – це те, про що чув майже кожен, хто працює з ланцюгами постачання, але мало хто справді розуміє.

00:00:11.100 --> 00:00:13.620
Dynamics 365 Transportation Management.

00:00:13.820 --> 00:00:14.820
Ось у чому проблема.

00:00:15.000 --> 00:00:18.800
Клієнт робить замовлення, товар лежить на складі, перевізнику потрібен час на вивезення,

00:00:18.920 --> 00:00:22.260
клієнт чекає на доставку, а згодом на чий стіл потрапляє рахунок за фрахт.

00:00:22.260 --> 00:00:26.980
Роками ці етапи існували в окремих таблицях, телефонних дзвінках, прайс-листах та через передачу завдань між командами.

00:00:27.120 --> 00:00:28.600
О, і це створює прогалини.

00:00:28.780 --> 00:00:31.400
Склад може підготувати товари до того, як транспорт матиме план.

00:00:31.580 --> 00:00:34.540
Фінанси можуть побачити рахунок, не знаючи, про що хтось домовився щодо оплати.

00:00:34.700 --> 00:00:36.920
Отже, що саме таке управління транспортуванням?

00:00:37.040 --> 00:00:41.360
Простою мовою – це транспортний відділ у межах Dynamics 365 Supply Chain Management.

00:00:41.660 --> 00:00:44.540
Він об'єднує складські ворота, постачальників, клієнтів та перевізників.

00:00:44.540 --> 00:00:48.660
Ми плануватимемо завантаження, обиратимемо маршрути і тарифи, відправлятимемо товари та перевірятимемо витрати на фрахт.

00:00:48.720 --> 00:00:53.720
Наприкінці цього епізоду ви побачите, як усі ці частини складаються докупи, щоб полегшити ваше робоче життя.

00:00:58.300 --> 00:00:59.980
Почнемо з базової істини.

00:01:00.120 --> 00:01:04.060
Фізичні товари не рухаються лише тому, що замовлення на продаж з'явилося на екрані.

00:01:04.220 --> 00:01:07.700
Їм потрібен вантажівка, причіп, контейнер або інший спосіб переміщення.

00:01:07.700 --> 00:01:14.220
Хтось має знати, звідки товар виїжджає, куди має прибути, скільки місця він займає, коли має відправитися і скільки має коштувати поїздка.

00:01:14.380 --> 00:01:17.960
Коли ви уявляєте одну коробку, що прямує до одного клієнта, це звучить просто.

00:01:18.160 --> 00:01:21.780
Але реальна компанія може відправляти багато замовлень з одного складу в той самий день,

00:01:21.900 --> 00:01:26.400
приймати товари від кількох постачальників і переміщувати запаси між власними об'єктами одночасно.

00:01:26.560 --> 00:01:29.860
З кожним переміщенням пов'язані люди, дати, простір та гроші.

00:01:30.020 --> 00:01:33.060
Без спільної системи кожен відділ бачить лише свою частину роботи.

00:01:33.060 --> 00:01:35.200
Відділ продажів бачить замовлення клієнта.

00:01:35.320 --> 00:01:37.380
Відділ закупівель бачить замовлення постачальника.

00:01:37.520 --> 00:01:41.040
Працівники складу бачать товари, які потрібно відібрати, упакувати, прийняти або розмістити.

00:01:41.200 --> 00:01:43.480
Транспортна команда бачить список того, що має бути переміщений,

00:01:43.560 --> 00:01:45.580
часто вже після того, як усі інші зробили свою справу.

00:01:45.660 --> 00:01:47.680
І саме тут починаються затримки та плутанина.

00:01:47.800 --> 00:01:48.940
Ось конкретний приклад.

00:01:49.100 --> 00:01:52.580
Уявіть, що на складі готово десятьох замовлень клієнтів для одного і того ж міста.

00:01:52.580 --> 00:01:55.140
Якщо ніхто не об'єднає ці замовлення перед бронюванням транспорту,

00:01:55.220 --> 00:01:57.320
компанія може організувати кілька напівпорожніх рейсів,

00:01:57.400 --> 00:02:00.700
або перевізник прибуде раніше, ніж склад зрозуміє, які товари належать до цього вантажу.

00:02:00.840 --> 00:02:03.060
Товари готові, але переміщення не сплановане.

00:02:03.220 --> 00:02:08.520
Отже, управління транспортуванням надає цьому процесу належне місце в системі Dynamics 365 Supply Chain Management.

00:02:08.760 --> 00:02:10.700
Це не окремий споживчий додаток для відстеження,

00:02:10.840 --> 00:02:13.960
де ви вводите номер накладної та спостерігаєте за рухом посилки на карті.

00:02:13.960 --> 00:02:17.480
Натомість він працює з бізнес-записами, що вже містяться в підключеній платформі.

00:02:17.600 --> 00:02:19.840
Замовлення створює потребу в переміщенні товарів.

00:02:19.980 --> 00:02:21.900
Складська робота готує товари до відправки.

00:02:22.060 --> 00:02:25.400
Управління транспортуванням планує, як ці товари рухатимуться між локаціями.

00:02:25.560 --> 00:02:27.940
Уявіть це як транспортний відділ у бізнес-центрі.

00:02:28.060 --> 00:02:30.600
Команда з продажу приносить запит від клієнта до відділу.

00:02:30.740 --> 00:02:33.380
Відділ закупівель повідомляє, що постачальник надійшли товари.

00:02:33.580 --> 00:02:36.140
Склад надає фактичні запаси та доступ до вантажних платформ.

00:02:36.140 --> 00:02:39.460
Транспортний відділ пов'язує ці запити з транспортним планом компанії.

00:02:39.600 --> 00:02:41.100
Існує два основні напрямки.

00:02:41.280 --> 00:02:44.380
Вхідне транспортування означає, що товари надходять до вашого бізнесу.

00:02:44.520 --> 00:02:47.580
Ви замовили товари у постачальника, і вони мають потрапити на ваш склад.

00:02:47.760 --> 00:02:50.840
Іноді поїздку контролює постачальник, іноді – ваша компанія.

00:02:51.000 --> 00:02:55.220
У будь-якому разі вам потрібен чіткий план доставки товарів у потрібне місце та їхнього приймання.

00:02:55.420 --> 00:02:58.740
Вихідне транспортування означає, що товари вирушають з вашого бізнесу.

00:02:58.860 --> 00:03:00.280
Клієнт замовив продукти.

00:03:00.280 --> 00:03:04.300
Склад готує їх, а перевізник або власний транспорт компанії доставляє їх клієнту.

00:03:04.440 --> 00:03:07.040
Обидва потоки стосуються руху, але мають різні вихідні точки.

00:03:07.240 --> 00:03:09.740
Вхідний потік починається із замовлення на закупівлю та постачальника.

00:03:09.880 --> 00:03:12.260
Вихідний потік починається із замовлення на продаж та клієнта.

00:03:12.400 --> 00:03:15.760
Існує також третій тип, який початківці часто пропускають – замовлення на переміщення.

00:03:15.920 --> 00:03:19.020
Замовлення на переміщення рухає запаси між вашими власними локаціями.

00:03:19.220 --> 00:03:22.240
Можливо, на одному складі забагато запасів, а іншому вони потрібні.

00:03:22.240 --> 00:03:26.180
Тут немає продажу клієнту, але фізичні товари все одно потребують транспортування.

00:03:26.340 --> 00:03:32.860
У системі 365 Transportation Management замовлення на переміщення належать до сценарію вихідних відправлень і планується разом із замовленнями на продаж.

00:03:32.980 --> 00:03:35.360
Це логічно, якщо уявити вантажний майданчик.

00:03:35.560 --> 00:03:39.260
Адже незалежно від того, чи прямує піддон до клієнта, чи на інший склад компанії,

00:03:39.400 --> 00:03:44.380
комусь все одно потрібно організувати транспорт, зарезервувати місце і відправити його через ті самі двері.

00:03:44.380 --> 00:03:49.760
Отже, цей інтегрований підхід замінює старий ланцюжок окремих списків та телефонних дзвінків на спільну інформацію.

00:03:49.920 --> 00:03:52.480
Замовлення повідомляє системі, що потрібно перемістити.

00:03:52.640 --> 00:03:53.800
Склад готує товари.

00:03:53.980 --> 00:03:57.000
Управління транспортуванням перетворює цю потребу на план перевезення.

00:03:57.160 --> 00:04:00.880
Коли товари мають вирушити в дорогу, системі спершу потрібен робочий план доставки.

00:04:01.020 --> 00:04:02.080
Планування вантажу.

00:04:02.300 --> 00:04:07.660
Сьогоднішня корисна порада про те, що потрібно кожній логістичній команді, хоча пояснюють це всі по-різному.

00:04:07.840 --> 00:04:08.920
Планування вантажу.

00:04:08.920 --> 00:04:12.340
Ви можете почати планування транспортування як із замовлень, так і з відправлень.

00:04:12.480 --> 00:04:14.360
Я Мірко Петерс із М365.

00:04:14.520 --> 00:04:16.520
FM і дозвольте мені одразу розвіяти один міф.

00:04:16.620 --> 00:04:18.060
План доставки не створюється з нуля.

00:04:18.240 --> 00:04:20.040
Він починається із записів, які у вас уже є.

00:04:20.200 --> 00:04:22.160
Замовлення на продаж містить те, що придбав клієнт.

00:04:22.280 --> 00:04:24.960
Замовлення на купівлю містить перелік того, що має надіслати постачальник.

00:04:25.200 --> 00:04:29.140
Відправлення групує ці товари в більш цілісний транспортний запис, готовий до поєднання з іншими.

00:04:29.280 --> 00:04:30.680
Отже, з чого варто почати?

00:04:30.680 --> 00:04:32.900
Це залежить від того, як працює ваша компанія.

00:04:33.060 --> 00:04:35.840
Деякі команди планують заздалегідь, працюючи безпосередньо з рядками замовлень.

00:04:35.980 --> 00:04:38.940
Інші команди спочатку створюють відправлення, а потім вирішують, що транспортувати разом.

00:04:39.080 --> 00:04:42.920
Обидва шляхи ведуть до одного і того самого питання, що має бути завантажено на один транспортний засіб.

00:04:43.060 --> 00:04:44.360
Ось найпростіше визначення.

00:04:44.520 --> 00:04:47.460
Вантаж – це цифровий запис для запланованого переміщення товарів.

00:04:47.620 --> 00:04:52.420
Можна уявити це як одну вантажівку, один причіп, один контейнер або набір відправлень, що перевозяться разом.

00:04:52.420 --> 00:04:56.520
Це дає вам єдине місце, де можна побачити, які товари мають бути разом до початку фізичної роботи.

00:04:56.640 --> 00:04:58.740
А тепер момент, у якому багато хто помиляється.

00:04:58.880 --> 00:05:01.480
Вантаж не означає, що всі товари вмістяться в одну фізичну коробку.

00:05:01.620 --> 00:05:04.280
Це означає, що система групує товари навколо одного плану транспортування.

00:05:04.460 --> 00:05:06.760
Кілька відправлень для клієнтів можуть розділяти одну вантажівку.

00:05:06.940 --> 00:05:09.320
Велике замовлення може заповнити весь причіп самостійно.

00:05:09.440 --> 00:05:13.540
Контейнер від постачальника також може стати вантажем ще до того, як ваш склад отримає товари.

00:05:13.540 --> 00:05:16.740
Суть у тому, щоб перестати розглядати кожне замовлення як окрему поїздку.

00:05:16.880 --> 00:05:20.340
Уявіть, що дистриб'ютор має шість клієнтських замовлень, готових до доставки на п'ятницю.

00:05:20.500 --> 00:05:23.940
Усі шість знаходяться в одній зоні, і кожне замовлення заповнює лише частину вантажівки.

00:05:24.100 --> 00:05:28.160
Надсилання шести напівпорожніх машин – це марнування місця та шість окремих транспортних завдань.

00:05:28.280 --> 00:05:31.120
Натомість команда може згрупувати сумісні відправлення в один вантаж.

00:05:31.280 --> 00:05:33.940
Сумісні означає, що вони можуть логічно подорожувати разом.

00:05:33.940 --> 00:05:36.800
Вони виїжджають з одного складу, мають бути відправлені приблизно в один час,

00:05:36.900 --> 00:05:39.500
відповідають обмеженням транспортного засобу та вашим правилам доставки.

00:05:39.640 --> 00:05:42.340
Система допомагає об'єднати ці записи, замість того, щоб покладатися на когось,

00:05:42.420 --> 00:05:44.020
хто шукатиме закономірності в електронній таблиці.

00:05:44.160 --> 00:05:45.680
Тепер ця група має спільний план.

00:05:45.880 --> 00:05:48.100
Ваш склад бачить, що саме входить до складу вантажу.

00:05:48.260 --> 00:05:50.520
Планувальник перевезень бачить загальну вагу та обсяг.

00:05:50.520 --> 00:05:54.140
Людям не потрібно переписувати один і той самий список в емейлах, нотатках чи окремих файлах.

00:05:54.140 --> 00:05:54.980
Але є нюанс.

00:05:55.140 --> 00:05:58.060
Групування товарів – це не просто додавання більшої кількості предметів разом.

00:05:58.180 --> 00:06:00.740
Вантажівка має обмеження вага, площа підлоги, висота.

00:06:00.900 --> 00:06:02.520
Контейнер має свої власні правила.

00:06:02.720 --> 00:06:04.780
Якщо система групує товари без перевірки цих обмежень,

00:06:04.880 --> 00:06:07.620
вантаж може виглядати добре на екрані, але не пройти на вантажній платформі.

00:06:07.740 --> 00:06:11.220
Dynamics 365 використовує шаблони вантажів, щоб допомогти уникнути цього.

00:06:11.280 --> 00:06:15.640
Сприймайте шаблон вантажу як багаторазовий набір обмежень для певного типу транспортного засобу чи контейнера.

00:06:15.640 --> 00:06:20.020
Створіть один для невеликої вантажівки, інший для більшого причепа, ще один для морського контейнера.

00:06:20.160 --> 00:06:24.400
Кожен шаблон містить обмеження щодо ваги, об'єму, висоти та інших правил, необхідних вашій компанії.

00:06:24.580 --> 00:06:27.620
Шаблон надає вантажу певну форму ще до того, як ви почнете його наповнювати.

00:06:27.780 --> 00:06:30.240
Тож, якщо відправлення занадто важке або займає забагато місця,

00:06:30.340 --> 00:06:32.420
планувальник бачить, що воно не підходить для цього вантажу.

00:06:32.600 --> 00:06:36.620
Рішенням може бути другий транспортний засіб, інший шаблон або інше групування відправлень.

00:06:36.620 --> 00:06:41.620
Програмне забезпечення не підіймає піддони, але воно надає вашій команді чіткіший план до початку фізичної роботи.

00:06:41.740 --> 00:06:45.460
Один із вбудованих підходів називається формуванням вантажу на основі об'єму.

00:06:45.620 --> 00:06:47.720
Це звучить складніше, ніж є насправді.

00:06:47.860 --> 00:06:53.180
Це означає, що система використовує максимальну висоту та вагу з вашого шаблону при створенні або пропонованні вантажу.

00:06:53.320 --> 00:06:56.520
Простою мовою вона перевіряє, чи вписуються товари в межі, які ви встановили.

00:06:56.680 --> 00:06:58.440
Ці значення не є фіксованими назавжди.

00:06:58.560 --> 00:07:01.000
Планувальник може змінити їх, коли змінюються реальні потреби.

00:07:01.000 --> 00:07:03.040
Можливо, перевізник надіслав інший причіп.

00:07:03.100 --> 00:07:04.980
Можливо, маршрут дозволяє іншу висоту.

00:07:05.140 --> 00:07:09.420
Шаблон задає загальне правило, а зміна налаштувань обробляє виняток без необхідності все переробляти.

00:07:09.600 --> 00:07:11.640
Повернімося до тих шести замовлень клієнтів.

00:07:11.780 --> 00:07:14.460
Кожне з них окремо може займати 15% вантажівки.

00:07:14.600 --> 00:07:17.580
Якщо планувати окремо, можна відправити шість майже порожніх машин.

00:07:17.720 --> 00:07:21.760
Згруповані в один вантаж, ті самі замовлення можуть заповнити більшу частину однієї вантажівки, залишивши місце для іншого.

00:07:21.760 --> 00:07:23.420
Це краще використання простору.

00:07:23.520 --> 00:07:25.360
Ця сама ідея працює в обох напрямках.

00:07:25.520 --> 00:07:28.880
Для планування вхідних вантажів створіть вантаж на основі товарів, що надходять від постачальника.

00:07:29.020 --> 00:07:33.480
План перевезення пов'язується з очікуваним надходженням, тому склад знає, що має прибути і готується до отримання.

00:07:33.660 --> 00:07:38.460
Замість того, щоб дізнаватися про доставку лише тоді, коли вона з'являється на воротах, команда отримувачів має запланований запис.

00:07:38.640 --> 00:07:43.580
Для планування вихідних вантажів виберіть складські товари, які потрібно відправити клієнтам, і згрупуйте їх у вантаж.

00:07:43.580 --> 00:07:47.280
Склад готує ці товари на основі даних про вантаж, а не за розрізненим списком.

00:07:47.460 --> 00:07:52.540
Для одного повного вантажу все одно потрібен спосіб перевезення, компанія для транспортування та очікувана вартість.

00:07:52.940 --> 00:07:54.820
Маршрути, перевізники та тарифи.

00:07:55.180 --> 00:07:58.060
Тепер вантаж показує вам, що має подорожувати разом.

00:07:58.260 --> 00:08:02.660
Далі вам потрібно вирішити, хто це перевозитиме, яку службу вони використають і якою має бути вартість поїздки.

00:08:02.800 --> 00:08:05.260
Компанію, яка перевозить ваші товари, називають перевізником.

00:08:05.440 --> 00:08:08.580
Це може бути зовнішня транспортна компанія, яка забирає та доставляє ваш вантаж.

00:08:08.580 --> 00:08:11.920
Це також може означати ваш власний автопарк, якщо у вас є власні вантажівки та водії.

00:08:12.100 --> 00:08:15.240
У будь-якому випадку перевізник відповідає за фізичне виконання поїздки.

00:08:15.380 --> 00:08:19.200
Ця відмінність важлива, тому що вам все одно потрібен план, навіть якщо вантажівка належить вам.

00:08:19.380 --> 00:08:22.460
Зі стороннім перевізником ви домовляєтеся про ціни та послуги заздалегідь.

00:08:22.600 --> 00:08:25.380
З власним автопарком ви все одно можете захотіти розрахувати вартість перевезення,

00:08:25.480 --> 00:08:28.020
особливо якщо витрати на доставку відображаються у замовленнях клієнтів.

00:08:28.020 --> 00:08:31.740
Dynamics 365 керування транспортуванням підтримує обидві ситуації.

00:08:31.960 --> 00:08:32.800
Далі йде маршрут.

00:08:32.940 --> 00:08:36.660
Маршрут – це запланований шлях від місця забору до пункту призначення разом із вибором послуги.

00:08:36.840 --> 00:08:38.500
Він відповідає на практичні питання.

00:08:38.680 --> 00:08:40.680
З якого складу перевізник забирає вантаж?

00:08:40.820 --> 00:08:42.860
Який клієнт або об'єкт отримує товари?

00:08:43.020 --> 00:08:45.020
Яка служба перевізника виконує поїздку?

00:08:45.180 --> 00:08:48.520
Уявіть доставку, що вирушає з вашого головного складу до клієнта в іншому кінці країни.

00:08:48.520 --> 00:08:52.100
Один маршрут може використовувати стандартні автомобільні перевезення, що дешевші, але триваліші.

00:08:52.220 --> 00:08:54.740
Інший може використовувати швидшу, дорожчу послугу.

00:08:54.840 --> 00:08:57.660
Початок і кінець ті самі, але вибір транспорту змінюється.

00:08:57.820 --> 00:08:59.820
Тариф – це очікувана плата за цей вибір.

00:08:59.960 --> 00:09:02.300
Це не випадкове число, введене в останню хвилину.

00:09:02.440 --> 00:09:06.340
Тарифи базуються на цінових угодах з перевізниками в поєднанні з деталями відправлення чи маршруту.

00:09:06.340 --> 00:09:10.120
Звідки вирушають товари, куди прямують, яка послуга використовується обсяг транспортування.

00:09:10.260 --> 00:09:12.460
Отже, маршрут вказує, як мають переміщатися товари.

00:09:12.580 --> 00:09:14.680
Тариф показує, скільки ви очікуєте заплатити.

00:09:14.840 --> 00:09:17.880
Ці дві ідеї не розривні, бо дешевий маршрут може порушити терміни доставки,

00:09:17.940 --> 00:09:20.360
а швидкість може коштувати дорожче, ніж дозволяє замовлення.

00:09:20.480 --> 00:09:22.700
Планування перевезень – це не просто пошук вантажівки,

00:09:22.800 --> 00:09:26.720
це вибір послуги, яка відповідає з обов'язанням перед клієнтом та правилам витрат компанії.

00:09:26.720 --> 00:09:30.440
Dynamics 365 містить робоче місце для тарифів і маршрутів.

00:09:30.560 --> 00:09:32.700
Назва звучить офіційно, але мета проста.

00:09:32.880 --> 00:09:37.060
Вона дає плановальникам змогу порівнювати варіанти маршрутів і тарифів для відправлення поруч.

00:09:37.220 --> 00:09:39.100
Замість того, щоб перевіряти таблиці одного перевізника,

00:09:39.200 --> 00:09:40.680
потім іншого і порівнювати в окремому файлі,

00:09:40.740 --> 00:09:43.140
ви розглядаєте варіанти, що стосуються цієї потреби у відправленні.

00:09:43.280 --> 00:09:45.640
Можливо, один варіант доставить товар клієнту раніше.

00:09:45.820 --> 00:09:47.440
Можливо, інший коштує менше.

00:09:47.440 --> 00:09:50.900
Система не знає, що кожен клієнт цінує швидкість більше за ціну,

00:09:51.040 --> 00:09:52.420
бо бізнес працює по-різному.

00:09:52.580 --> 00:09:56.480
Клієнт міг заплатити за термінову доставку, тому швидший маршрут має сенс.

00:09:56.640 --> 00:09:59.980
Інший погоджується на довший термін і нижча ціна підходить краще.

00:10:00.160 --> 00:10:01.800
Люди все ще приймають рішення.

00:10:01.960 --> 00:10:05.280
Управління транспортуванням надає вам узгоджені варіанти та очікувані витрати,

00:10:05.440 --> 00:10:07.680
тоді як ваш бізнес вирішує, який компроміс кращий.

00:10:07.840 --> 00:10:09.840
Ось що насправді робить вбудований модуль.

00:10:09.840 --> 00:10:11.880
Інформація про тарифи надходить із тарифних таблиць,

00:10:11.940 --> 00:10:14.360
які ваша компанія вносить і підтримує в Dynamics 365.

00:10:14.860 --> 00:10:18.740
Вважайте ці таблиці збереженими записами узгоджених цін перевізників і правил маршрутизації.

00:10:18.920 --> 00:10:21.140
Якщо ви домовилися про ціну на певну послугу та напрямок,

00:10:21.240 --> 00:10:23.640
ця інформація залишається в системі та підтримує планування.

00:10:23.780 --> 00:10:26.440
Це добре працює, коли ваші тарифи відповідають відомим угодам.

00:10:26.580 --> 00:10:28.660
Наприклад, ви працюєте з кількома постійними перевізниками,

00:10:28.660 --> 00:10:31.600
обслуговуєте знайомі маршрути та оновлюєте ціни, коли змінюються контракти.

00:10:31.720 --> 00:10:33.720
Планувальник перевезень використовує вже записані тарифи,

00:10:33.780 --> 00:10:35.660
замість того, щоб шукати в старих електронних листах.

00:10:35.780 --> 00:10:37.920
Але є дещо, що багато хто розуміє неправильно.

00:10:38.100 --> 00:10:40.500
Вбудований модуль не діє як торговий майданчик у реальному часі,

00:10:40.580 --> 00:10:41.880
підключений до кожного перевізника.

00:10:42.080 --> 00:10:44.420
Він не отримує автоматично актуальні ціни з живих стрічок

00:10:44.420 --> 00:10:46.560
і не порівнює їх у реальному часі в широкій мережі.

00:10:46.560 --> 00:10:49.300
Якщо вашій компанії потрібен порівняльний аналіз тарифів кількох перевізників,

00:10:49.300 --> 00:10:51.260
онлайн-бронювання або детальні оновлення статусу вантажу

00:10:51.260 --> 00:10:52.680
зазвичай підключають сторонню систему.

00:10:52.820 --> 00:10:55.040
Це не є недоліком управління транспортуванням.

00:10:55.220 --> 00:10:56.860
Воно чітко визначає свою роль.

00:10:57.000 --> 00:10:59.600
Ці інструменти забезпечують структуроване планування перевезень

00:10:59.600 --> 00:11:01.440
у межах управління ланцюгами постачання,

00:11:01.580 --> 00:11:04.120
використовуючи дані про перевізників, маршрути і тарифи.

00:11:04.220 --> 00:11:07.000
І це також неспоживчий веб-сайт для відстеження посилок.

00:11:07.000 --> 00:11:08.900
Ви не використовуватимете його як карту,

00:11:08.980 --> 00:11:10.840
де вводиш номер накладної і спостерігаєш,

00:11:10.840 --> 00:11:12.740
як значок автомобіля рухається дорогою.

00:11:12.880 --> 00:11:14.620
Цей модуль зосереджений на бізнес-рішеннях

00:11:14.620 --> 00:11:16.620
щодо транспортування до та під час відправлення.

00:11:16.760 --> 00:11:19.240
Які товари перевозити разом, який перевізник їх обслуговує,

00:11:19.400 --> 00:11:21.680
який маршрут обрати, якою має бути вартість поїздки.

00:11:21.820 --> 00:11:23.340
Як тільки компанія обирає план,

00:11:23.480 --> 00:11:26.120
складські та транспортні команди повинні втілити його в життя.

00:11:26.320 --> 00:11:27.780
Від дверей складу до дверей клієнта

00:11:27.780 --> 00:11:29.520
транспортний план допомагає лише тоді,

00:11:29.520 --> 00:11:31.660
коли його можна перетворити на реальне відправлення.

00:11:31.660 --> 00:11:34.260
Для вихідного замовлення процес зазвичай починається з того,

00:11:34.400 --> 00:11:35.460
що клієнт купує товар.

00:11:35.580 --> 00:11:37.060
Замовлення на продаж вказує бізнесу,

00:11:37.140 --> 00:11:39.660
що потрібно клієнту, куди це має потрапити і коли має прибути.

00:11:39.800 --> 00:11:41.100
Це замовлення стає відправленням,

00:11:41.180 --> 00:11:42.700
яке приєднується до запланованого вантажу

00:11:42.700 --> 00:11:44.360
разом з іншими товарами на той самий рейс.

00:11:44.460 --> 00:11:45.940
Потім роботу бере на себе склад.

00:11:46.120 --> 00:11:47.680
Працівники збирають товари зі зберігання,

00:11:47.780 --> 00:11:50.000
пакують їх і доставляють у потрібну зону навантаження.

00:11:50.000 --> 00:11:51.820
Оскільки відправлення є частиною вантажу,

00:11:51.820 --> 00:11:53.880
Команда бачить, які товари мають поїхати разом

00:11:53.880 --> 00:11:55.120
і який перевізник їх забере.

00:11:55.300 --> 00:11:56.360
Коли прибуває транспорт,

00:11:56.460 --> 00:11:58.340
товари переміщуються зі складу до перевізника,

00:11:58.480 --> 00:11:59.760
а той доставляє їх клієнту.

00:11:59.940 --> 00:12:02.500
Кожен крок під'єднаний до одного і того самого запису про переміщення.

00:12:02.660 --> 00:12:04.620
Це звучить будинно, але уявіть, як це було раніше.

00:12:04.840 --> 00:12:06.920
Комплектувальник міг працювати за роздрукованим замовленням.

00:12:07.020 --> 00:12:09.200
Транспортний планувальник міг мати окремий список.

00:12:09.200 --> 00:12:11.640
А хтось біля воріт навантаження міг шукати в електронних листах,

00:12:11.720 --> 00:12:13.360
який перевізник має забрати, які палити.

00:12:13.360 --> 00:12:15.080
Якщо змінювалася хоча б одна деталь,

00:12:15.180 --> 00:12:16.680
усім потрібна була оновлена версія.

00:12:16.840 --> 00:12:18.660
Завдяки управлінню транспортуванням вантаж

00:12:18.660 --> 00:12:20.020
надає командам спільний запис.

00:12:20.220 --> 00:12:22.320
Склад бачить товари, що належать до вантажу,

00:12:22.440 --> 00:12:24.180
планувальник бачить деталі відправлення,

00:12:24.280 --> 00:12:26.160
а особа, що організовує отримання

00:12:26.160 --> 00:12:28.100
запланованого перевізника та послугу.

00:12:28.340 --> 00:12:30.380
Замість передачі кількох паперових списків

00:12:30.380 --> 00:12:31.940
люди працюють з інформацією,

00:12:32.040 --> 00:12:34.240
пов'язаною з одним і тим самим замовленням.

00:12:34.360 --> 00:12:35.460
Ось простий приклад.

00:12:35.640 --> 00:12:37.860
На складі є замовлення для кількох клієнтів

00:12:37.860 --> 00:12:39.100
в одній зоні доставки.

00:12:39.260 --> 00:12:41.440
Один клієнт замовив коробки мийних засобів,

00:12:41.600 --> 00:12:42.760
інший – паперові вироби,

00:12:42.860 --> 00:12:44.760
а третій – невелику партію обладнання.

00:12:44.900 --> 00:12:46.540
Кожне замовлення потрібно зібрати та запакувати,

00:12:46.680 --> 00:12:48.300
але транспортна команда не повинна розглядати їх

00:12:48.300 --> 00:12:49.460
як абсолютно окремі поїздки.

00:12:49.640 --> 00:12:52.000
Вони призначають відправлення до одного запланованого вантажу.

00:12:52.180 --> 00:12:53.860
Персонал складу збирає кожне замовлення,

00:12:53.940 --> 00:12:56.060
правильно пакує його та готує до зони завантаження.

00:12:56.060 --> 00:12:57.640
Запис про вантаж повідомляє їм,

00:12:57.760 --> 00:12:59.480
що всі ці відправлення подорожують разом.

00:12:59.480 --> 00:13:00.620
Коли прибуває перевізник,

00:13:00.740 --> 00:13:03.200
команда передає товари для одного запланованого переміщення,

00:13:03.340 --> 00:13:05.100
замість того, щоб намагатися в останню хвилину

00:13:05.100 --> 00:13:06.240
підібрати піддони для водія.

00:13:06.400 --> 00:13:08.640
Клієнт все одно отримує власне замовлення.

00:13:08.780 --> 00:13:11.000
Проте за лаштунками бізнес спланував цю доставку

00:13:11.000 --> 00:13:12.600
як частину ширшого переміщення.

00:13:12.780 --> 00:13:14.700
Цей зв'язок допомагає складу працювати разом

00:13:14.700 --> 00:13:16.820
із транспортною командою, а не випереджати її

00:13:16.820 --> 00:13:19.060
або чекати на інструкції, які надходять запізно.

00:13:19.200 --> 00:13:21.180
Вхідні перевезення дотримуються тієї самої

00:13:21.180 --> 00:13:23.200
пов'язаної ідеї просто в іншому напрямку.

00:13:23.200 --> 00:13:24.880
Замовлення на закупівлю свідчить про те,

00:13:24.880 --> 00:13:27.020
що ваша компанія очікує товари від постачальника.

00:13:27.160 --> 00:13:28.920
Коли ваш бізнес організовує перевезення,

00:13:29.060 --> 00:13:31.120
запланований вхідний вантаж пов'язує вхідні товари

00:13:31.120 --> 00:13:33.280
з поїздкою ще до того, як вони потраплять на склад.

00:13:33.500 --> 00:13:34.780
Постачальник відправляє вантаж,

00:13:34.900 --> 00:13:36.620
перевізник доставляє його на ваш об'єкт,

00:13:36.700 --> 00:13:37.640
а склад приймає його.

00:13:37.800 --> 00:13:39.500
Персонал з прийому може підготуватися,

00:13:39.600 --> 00:13:40.840
бо знає, що має прибути.

00:13:41.000 --> 00:13:42.940
Вони можуть звірити запланований вантаж із товарами,

00:13:43.060 --> 00:13:44.960
що з'являються на доці, це набагато зрозуміліше,

00:13:44.960 --> 00:13:46.360
ніж несподівана поява вантажівки

00:13:46.360 --> 00:13:48.660
та спроби з'ясувати, до якого замовлення належать піддони.

00:13:48.800 --> 00:13:51.400
Замовлення на переміщення також відповідають цьому процесу.

00:13:51.520 --> 00:13:53.260
Один об'єкт компанії відправляє запаси,

00:13:53.320 --> 00:13:55.000
а інший об'єкт компанії отримує їх.

00:13:55.140 --> 00:13:57.180
Перший склад готує товари та відправляє їх,

00:13:57.300 --> 00:13:59.000
а другий склад очікує ті самі товари

00:13:59.000 --> 00:14:00.620
та приймає їх до своїх запасів.

00:14:00.760 --> 00:14:03.100
Наприкінці цієї поїздки немає стороннього клієнта,

00:14:03.220 --> 00:14:05.220
але компанії все одно потрібна чітка передача

00:14:05.220 --> 00:14:06.100
між двома локаціями.

00:14:06.100 --> 00:14:08.320
Вантаж поєднує роботу з відправлення та отримання

00:14:08.320 --> 00:14:10.140
навколо одного запланованого переміщення.

00:14:10.300 --> 00:14:12.080
Вибір доставки клієнтом також залишається

00:14:12.080 --> 00:14:13.760
пов'язаним із рішенням про відправлення.

00:14:13.900 --> 00:14:16.000
Якщо планувальник обирає швидшу службу перевізника,

00:14:16.100 --> 00:14:17.660
тому що клієнту потрібні товари швидко,

00:14:17.760 --> 00:14:19.300
цей вибір пов'язується з відправленням.

00:14:19.420 --> 00:14:21.260
Якщо бізнес використовує менш дорогий сервіс,

00:14:21.360 --> 00:14:22.760
оскільки дата доставки це дозволяє,

00:14:22.840 --> 00:14:24.040
цей вибір також враховується.

00:14:24.220 --> 00:14:26.280
Люди можуть відстежити вартість доставки до маршруту

00:14:26.280 --> 00:14:28.080
та вибору перевізника, який її створив.

00:14:28.200 --> 00:14:29.800
Транспортний засіб може залишити док,

00:14:29.880 --> 00:14:31.280
а товари можуть прибути безпечно,

00:14:31.420 --> 00:14:32.560
але робота ще не завершена.

00:14:32.720 --> 00:14:35.040
Після цього перевізник надсилає рахунок за фрахт,

00:14:35.100 --> 00:14:36.460
і хтось має його перевірити.

00:14:36.700 --> 00:14:38.500
Витрати на фрахт та їх звірка.

00:14:38.760 --> 00:14:39.940
Товари залишили склад,

00:14:40.100 --> 00:14:42.020
і доставка може бути навіть завершена.

00:14:42.200 --> 00:14:44.120
Тоді надходить рахунок від перевізника.

00:14:44.300 --> 00:14:45.680
Цей рахунок потребує перевірки,

00:14:45.680 --> 00:14:48.320
оскільки сума в ньому має відповідати транспортному рішенню,

00:14:48.400 --> 00:14:49.820
яке компанія планувала раніше,

00:14:49.820 --> 00:14:52.020
включаючи перевізника, маршрут, послугу,

00:14:52.140 --> 00:14:54.380
деталі вантажу та очікувану вартість перевезення.

00:14:54.480 --> 00:14:56.140
Під час планування Dynamics 365

00:14:56.140 --> 00:14:58.360
може розрахувати очікувану вартість перевезення

00:14:58.360 --> 00:15:00.120
на основі тарифної інформації компанії.

00:15:00.300 --> 00:15:02.260
Ця очікувана сума дає бізнесу відправну точку

00:15:02.260 --> 00:15:04.460
ще до того, як перевізник надійшли запит на оплату.

00:15:04.640 --> 00:15:07.020
Пізніше перевізник надсилає свій рахунок за фрахт.

00:15:07.120 --> 00:15:09.380
Узгодження фрахту означає порівняння цього рахунка

00:15:09.380 --> 00:15:10.920
з тарифами та деталями відправлення,

00:15:11.040 --> 00:15:12.020
вже внесеними в систему.

00:15:12.020 --> 00:15:13.740
Простою мовою, компанія перевіряє,

00:15:13.820 --> 00:15:16.140
чи виставив перевізник рахунок на очікувану суму за послугу,

00:15:16.240 --> 00:15:17.420
яка фактично перевезла вантаж.

00:15:17.540 --> 00:15:20.000
Уявіть, що в плані вказана сума 500 доларів.

00:15:20.180 --> 00:15:22.340
Рахунок перевізника також містить 500 доларів

00:15:22.340 --> 00:15:23.880
і деталі відправлення збігаються.

00:15:24.060 --> 00:15:26.280
Цей рахунок проходить процес перевірки без перешкод,

00:15:26.380 --> 00:15:28.560
оскільки запланований запис і рахунок збігаються.

00:15:28.720 --> 00:15:30.740
Але рахунки не завжди збігаються з планом.

00:15:30.920 --> 00:15:32.620
Можливо, тарифна таблиця була помилковою,

00:15:32.620 --> 00:15:34.980
можливо, перевізник виставив рахунок за іншу послугу

00:15:34.980 --> 00:15:36.400
або вантаж змінився після планування

00:15:36.400 --> 00:15:37.900
і на рахування потребує пояснення.

00:15:38.040 --> 00:15:40.020
Без пов'язаного запису фінансовий відділ може бачити

00:15:40.020 --> 00:15:41.120
лише номер рахунка та суму,

00:15:41.200 --> 00:15:42.500
витрачаючи час на з'ясування того,

00:15:42.660 --> 00:15:44.440
що сталося у складської та транспортної команд.

00:15:44.640 --> 00:15:46.480
Управління транспортуванням підтримує зв'язок

00:15:46.480 --> 00:15:48.220
транспортного рішення з цією перевіркою.

00:15:48.360 --> 00:15:50.040
Правила дозволяють порівняти рахунок перевізника

00:15:50.040 --> 00:15:52.100
з очікуваною сумою та запланованою інформацією

00:15:52.100 --> 00:15:52.700
про відправлення.

00:15:52.700 --> 00:15:55.160
Коли деталі відповідають прийнятим у компанії правилам,

00:15:55.240 --> 00:15:56.840
рахунок може бути опрацьований далі.

00:15:56.960 --> 00:15:58.120
Коли деталі не збігаються,

00:15:58.280 --> 00:16:00.640
система спрямовує розбіжність на перевірку фахівцю.

00:16:00.780 --> 00:16:03.060
Це означає, що люди не схвалюють кожну суму

00:16:03.060 --> 00:16:04.040
за фрахт на ослів.

00:16:04.140 --> 00:16:06.520
Транспортному планувальнику може знадобитися підтвердити,

00:16:06.660 --> 00:16:08.420
що перевізник використав іншу послугу

00:16:08.420 --> 00:16:11.140
або фінансисту з'ясувати причину додаткових нарахувань.

00:16:11.140 --> 00:16:13.980
Справа не в тому, щоб вважати кожну невідповідність помилкою.

00:16:13.980 --> 00:16:15.800
Справа в тому, щоб помітити невідповідність

00:16:15.800 --> 00:16:16.700
до здійснення платежу.

00:16:16.820 --> 00:16:18.500
Це об'єднує операційний та фінансовий відділи

00:16:18.500 --> 00:16:19.540
навколо одного відправлення.

00:16:19.660 --> 00:16:21.920
Транспортна команда обирає перевізника та послугу.

00:16:22.040 --> 00:16:23.920
Цей вибір формує очікувану вартість.

00:16:24.100 --> 00:16:26.280
Склад відправляє вантаж, а фінансовий відділ перевіряє

00:16:26.280 --> 00:16:28.100
отриманий рахунок на відповідність запису про те,

00:16:28.200 --> 00:16:29.120
що планувала компанія.

00:16:29.260 --> 00:16:30.660
Кожна команда бачить свою частину,

00:16:30.660 --> 00:16:32.800
але вони працюють із пов'язаною інформацією.

00:16:32.920 --> 00:16:35.060
Проте вбудований процес має чіткі межі.

00:16:35.060 --> 00:16:36.820
Компанії, яким потрібен масштабний,

00:16:36.960 --> 00:16:38.560
високоавтоматизований аудит фрахту,

00:16:38.680 --> 00:16:41.220
часто додають сторонню систему управління транспортуванням.

00:16:41.320 --> 00:16:43.240
Ці інструменти можуть забезпечити глибші зв'язки

00:16:43.240 --> 00:16:45.660
з перевізниками та більше автоматизованих правил перевірки.

00:16:45.820 --> 00:16:47.700
Вбудований модуль опрацьовує планові витрати

00:16:47.700 --> 00:16:50.080
та звірку всередині управління ланцюгами постачання,

00:16:50.220 --> 00:16:52.360
тоді як інша система може розширити ці можливості,

00:16:52.360 --> 00:16:53.800
якщо бізнесу потрібно більше.

00:16:53.920 --> 00:16:55.600
Зберіть усі ці будівельні блоки разом

00:16:55.600 --> 00:16:57.380
і почне вимальовуватися повна картина,

00:16:57.380 --> 00:16:59.920
де це застосовується і чого цей інструмент не робить.

00:17:00.020 --> 00:17:02.680
Отже, де насправді знаходиться управління транспортуванням.

00:17:02.860 --> 00:17:05.640
Воно належить і до складу Dynamics 365 Supply Chain Management,

00:17:05.800 --> 00:17:07.460
що працює в додатках Finance & Operations.

00:17:07.720 --> 00:17:08.460
Це його дім.

00:17:08.640 --> 00:17:09.980
Ось для кого воно підходить.

00:17:10.120 --> 00:17:11.960
Компаніям, яким потрібен структурований спосіб

00:17:11.960 --> 00:17:14.300
планування вхідних поставок, вихідних відправлень клієнтам,

00:17:14.300 --> 00:17:15.860
переміщення запасів між майданчиками,

00:17:15.940 --> 00:17:17.640
використовуючи власні записи перевізників,

00:17:17.720 --> 00:17:19.260
таблиці тарифів та правила завантаження.

00:17:19.380 --> 00:17:21.880
Тепер давайте прояснимо поширену причину непорозумінь.

00:17:22.000 --> 00:17:23.640
Business Central – це інша справа.

00:17:23.760 --> 00:17:25.680
Business Central не містить цього вбудованого модуля

00:17:25.680 --> 00:17:26.860
управління транспортуванням.

00:17:26.960 --> 00:17:29.240
Якщо ви працюєте в Business Central і вам потрібне планування перевезень,

00:17:29.320 --> 00:17:31.680
вам слід звернути увагу на сторонні системи управління транспортуванням.

00:17:31.780 --> 00:17:32.880
Це межа можливостей.

00:17:33.060 --> 00:17:35.180
Давайте також окреслимо межі з іншого боку.

00:17:35.180 --> 00:17:37.380
Вбудований модуль не замінює всі портали перевізників,

00:17:37.480 --> 00:17:40.020
сервіси відстеження трафіку чи інструменти розширеного трекінгу.

00:17:40.020 --> 00:17:42.580
Коли бізнесу потрібні актуальні тарифи від багатьох перевізників,

00:17:42.680 --> 00:17:44.760
ширший вибір логістів або глибше відстеження після того,

00:17:44.900 --> 00:17:47.220
як товари покинули склад, підключається сторонній ТМС.

00:17:47.340 --> 00:17:49.540
Ці інструменти обробляють зовнішню активність.

00:17:49.720 --> 00:17:50.980
Згадайте офісну будівлю.

00:17:51.140 --> 00:17:54.100
Управління транспортуванням – це транспортний відділ всередині цієї будівлі.

00:17:54.100 --> 00:17:56.920
Він пов'язаний із замовленнями, складськими роботами та фінансами.

00:17:57.060 --> 00:17:59.280
Він об'єднує власний транспортний план компанії.

00:17:59.280 --> 00:18:02.960
Зовнішні інструменти перевізників можуть обробляти діяльність за межами цього відділу.

00:18:03.120 --> 00:18:05.080
Два різні рівні, що працюють разом.

00:18:05.920 --> 00:18:08.040
Висновок. Наступний фрагмент знань.

00:18:08.200 --> 00:18:10.200
Ось найпростіший спосіб подумати про це.

00:18:10.360 --> 00:18:13.820
Управління транспортуванням перетворює бізнес-замовлення на запланований рух товарів.

00:18:13.820 --> 00:18:17.600
Потім воно пов'язує цей рух із витратами на фрахт, які компанія перевіряє згодом.

00:18:17.720 --> 00:18:21.220
Це повний цикл. Підписуйтесь на вашій улюбленій подкаст-платформі.

00:18:21.220 --> 00:18:25.780
Поділіться цим фрагментом знань з тим, хто вивчає Dynamics 365 Supply Chain Management.

00:18:25.980 --> 00:18:29.000
Потім ознайомтеся з нашими наступними епізодами про склад та інвентаризацію.

00:18:29.140 --> 00:18:32.080
Кожне завантаження все одно залежить від запасів, що знаходяться за дверима складу.