WEBVTT

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

00:00:04.460 --> 00:00:06.000
Я ваш ведучий Мірко Пітерс.

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

00:00:09.300 --> 00:00:10.880
але мало хто розуміє її по-справжньому.

00:00:11.040 --> 00:00:13.240
Управління транспортуванням у Dynamics 365.

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

00:00:15.040 --> 00:00:17.160
Клієнт робить замовлення, товар лежить на складі,

00:00:17.240 --> 00:00:20.000
перевізнику потрібен час на забір, клієнт чекає на доставку,

00:00:20.080 --> 00:00:22.240
а пізніше комусь на стіл лягає рахунок за фрахт.

00:00:22.240 --> 00:00:25.480
Роками ці етапи існували в окремих таблицях, телефонних дзвінках, прайс-листах

00:00:25.480 --> 00:00:26.940
та передавалися між командами вручну.

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

00:00:28.700 --> 00:00:31.500
Склад може підготувати товар раніше, ніж транспортний відділ матиме план.

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

00:00:34.760 --> 00:00:36.720
То що ж таке управління транспортуванням?

00:00:36.820 --> 00:00:41.240
Простою мовою, це логістичний центр у середині системи управління ланцюгами постачання Dynamics 365.

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

00:00:44.660 --> 00:00:48.620
Ми плануватимемо завантаження, обиратимемо маршрути і тарифи, відправлятимемо товари та перевірятимемо вартість перевезень.

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

00:00:55.520 --> 00:00:57.960
Чому існує управління транспортуванням?

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

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

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

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

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

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

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

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

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

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

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

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

00:01:41.240 --> 00:01:45.560
Транспортний відділ бачить список вантажів, що мають бути перевезені часто вже після того, як усі інші виконали свою роботу.

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

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

00:01:48.980 --> 00:01:52.540
Уявіть, що на складі готово 10 клієнтських замовлень для одного міста.

00:01:52.680 --> 00:01:57.360
Якщо ніхто не об'єднає ці замовлення до бронювання транспорту, компанія може організувати кілька напівпорожніх поїздок,

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

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

00:02:03.280 --> 00:02:08.480
Тож управління транспортуванням надає цьому переміщенню чітке місце в межах Dynamics 365 Supply Chain Management.

00:02:08.480 --> 00:02:14.040
Це не окремий споживчий додаток для доставки, де ви вводите номер відстеження і спостерігаєте, як посилка рухається на карті.

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

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

00:02:20.120 --> 00:02:21.660
Складська робота готує товари.

00:02:21.820 --> 00:02:25.380
Управління транспортуванням планує, як ці товари переміщуватимуться між локаціями.

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

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

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

00:02:33.740 --> 00:02:36.040
Склад надає фактичні запаси та вантажні доки.

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

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

00:02:41.300 --> 00:02:44.300
Вхідне транспортування означає переміщення товарів у ваш бізнес.

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

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

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

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

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

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

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

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

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

00:03:19.100 --> 00:03:22.320
Можливо, на одному складі забагато товарів, а інший їх потребує.

00:03:22.320 --> 00:03:26.160
Купівля клієнтом тут не задіяна, але фізично товари все одно треба перевезти.

00:03:26.280 --> 00:03:30.680
У 365 Transpitation Management замовлення на переміщення належать до вихідного сценарію

00:03:30.680 --> 00:03:32.860
і можуть плануватися разом із замовленнями на продаж.

00:03:32.980 --> 00:03:35.520
Це логічно, якщо уявити вантажну платформу.

00:03:35.640 --> 00:03:38.860
О, чи прямує піддон до клієнта, чи на інший склад компанії,

00:03:38.860 --> 00:03:44.300
хтось все одно має організувати транспорт, забронювати місце і відправити його через ті самі двері.

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

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

00:03:52.560 --> 00:03:53.840
Склад готує позиції.

00:03:54.040 --> 00:03:56.920
Управління транспортуванням перетворює цю потребу на транспортний план.

00:03:57.100 --> 00:04:00.820
Коли виникає потреба перевезти товари, системі спочатку потрібен дієвий план доставки.

00:04:00.960 --> 00:04:02.280
Планування завантаження.

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

00:04:07.820 --> 00:04:09.180
Планування завантаження.

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

00:04:13.240 --> 00:04:13.420
Я.

00:04:13.860 --> 00:04:16.120
І дозвольте мені відразу розвінчити один міф.

00:04:16.120 --> 00:04:17.880
План доставки не починається з нуля.

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

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

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

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

00:04:29.300 --> 00:04:30.720
Отже, з чого краще почати?

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

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

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

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

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

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

00:04:47.560 --> 00:04:52.400
Ви можете уявити це як одну вантажівку, один причіп, один контейнер або набір відправлень, що прямують разом.

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

00:04:56.720 --> 00:04:58.660
Ось момент, у якому багато хто помиляється.

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

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

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

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

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

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

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

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

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

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

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

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

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

00:05:44.160 --> 00:05:45.660
Ця група тепер має спільний план.

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

00:05:48.240 --> 00:05:50.520
Транспортний планувальник бачить загальний обсяг і вагу.

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

00:05:54.140 --> 00:05:55.060
Але тут є нюанс.

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

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

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

00:06:02.620 --> 00:06:07.700
Якщо система групує товари без перевірки цих лімітів, вантаж може виглядати нормально на екрані, але не пройдена на вантажувальній рампі.

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

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

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

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

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

00:06:27.740 --> 00:06:32.460
Отже, якщо вантаж занадто важкий або займає забагато місця, планувальник бачить, що він не підходить для цього відправлення.

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

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

00:06:41.660 --> 00:06:45.340
Один із вбудованих підходів називається об'ємним плануванням завантаження.

00:06:45.500 --> 00:06:47.680
Це звучить технічніше, ніж є насправді.

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

00:06:53.400 --> 00:06:56.580
Простими словами, вона перевіряє, чи вписується товар у встановлені вами ліміти.

00:06:56.740 --> 00:06:58.400
Ці значення не зафіксовані назавжди.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:07:54.820 --> 00:07:58.140
Тепер вантаж показує, що має транспортуватися разом.

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

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

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

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

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

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

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

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

00:08:25.640 --> 00:08:28.000
особливо якщо витрати на доставку вказані в замовленнях клієнтів.

00:08:28.140 --> 00:08:31.720
Dynamics 365 Transportation Management підтримує обидві ситуації.

00:08:31.880 --> 00:08:32.780
А ще є маршрут.

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

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

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

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

00:08:43.040 --> 00:08:45.160
Яка служба перевізника здійснює перевезення?

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

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

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

00:08:54.720 --> 00:08:57.800
Точка відправлення та кінцева точка одні, але вибір транспорту різний.

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

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

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

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

00:09:10.620 --> 00:09:14.380
Отже, маршрут вказує, як рухатимуться товари, а тариф – скільки ви очікуєте заплатити.

00:09:14.540 --> 00:09:17.760
Ці дві ідеї нерозривні, оскільки дешевий маршрут може зірвати терміни доставки,

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

00:09:20.300 --> 00:09:23.420
Транспортне планування – це не просто пошук вантажівки, це вибір послуги,

00:09:23.540 --> 00:09:26.720
що відповідає вашим зобов'язанням перед клієнтом і правилам витрат компанії.

00:09:26.880 --> 00:09:30.360
Dynamics 365 включає робоче місце, маршрути та тарифи.

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

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

00:09:37.360 --> 00:09:40.860
Замість того, щоб перевіряти одну таблицю перевізника за іншою та порівнювати в окремому файлі,

00:09:40.860 --> 00:09:43.460
ви розглядаєте варіанти, пов'язані з цією потребою в доставці.

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

00:09:47.380 --> 00:09:52.440
Система не знає, що кожен клієнт цінує швидкість більше за вартість, оскільки бізнеси працюють по-різному.

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

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

00:10:00.140 --> 00:10:01.800
Рішення все одно приймають люди.

00:10:01.800 --> 00:10:07.640
Управління транспортуванням надає вам узгоджені варіанти та очікувані витрати, поки ваш бізнес вирішує, який компроміс прийнятний.

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

00:10:10.080 --> 00:10:14.320
Інформація про тарифи надходить із таблиць, які ваша компанія вводить і підтримує в Dynamics 365.

00:10:14.800 --> 00:10:18.780
Розглядаєте ці таблиці як збережені записи про узгоджені ціни перевізників і правила маршрутизації.

00:10:18.780 --> 00:10:23.640
Якщо ви домовилися про ціну за певну послугу та напрямок, ця інформація зберігається в системі та підтримує планування.

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

00:10:26.600 --> 00:10:31.620
Наприклад, ви працюєте з кількома постійними перевізниками, обслуговуєте знайомі маршрути і оновлюєте ціни при зміні контрактів.

00:10:31.720 --> 00:10:35.680
Транспортний планувальник використовує вже записані тарифи замість того, щоб шукати їх у старих листах.

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

00:10:38.000 --> 00:10:41.700
Вбудований модуль не працює як онлайн-магазин, підключений до кожного перевізника.

00:10:41.880 --> 00:10:46.640
Він не отримує автоматично свіжі ціни з поточних каналів зв'язку і не порівнює їх у широкій мережі в реальному часі.

00:10:46.760 --> 00:10:52.620
Якщо вашій компанії потрібен пошук тарифів у кількох перевізників, онлайн-бронювання або детальніші оновлення статусу відправлення зазвичай підключають сторонню систему.

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

00:10:55.080 --> 00:10:56.960
Воно чітко визначає свою функцію.

00:10:56.960 --> 00:11:04.200
Ці інструменти забезпечують структуроване планування перевезень у межах управління ланцюгами постачання, використовуючи дані про перевізників, маршрути і тарифи.

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

00:11:07.140 --> 00:11:12.680
Ви не використовуватимете його як карту, де вводите номер накладної та стежите за іконкою транспортного засобу на дорозі.

00:11:12.820 --> 00:11:16.580
Цей модуль зосереджений на бізнес-рішеннях щодо транспортування до і під час відправлення.

00:11:16.580 --> 00:11:21.680
Які товари рухаються разом, який перевізник їх обслуговує, який маршрут застосовується, якою має бути вартість рейсу.

00:11:21.800 --> 00:11:26.220
Коли ваша компанія обирає цей план, команди складу та транспортування мають втілити його в життя.

00:11:26.400 --> 00:11:31.600
Відворіт складу до дверей клієнта транспортний план корисний лише тоді, коли його можна перетворити на реальне відправлення.

00:11:31.760 --> 00:11:35.460
Для вихідного замовлення потік зазвичай починається з моменту, коли клієнт щось купує.

00:11:35.640 --> 00:11:39.700
Замовлення на продаж повідомляє бізнесу, що хоче клієнт, куди це має потрапити і коли має прибути.

00:11:39.700 --> 00:11:44.380
Це замовлення стає відправленням, яке додається до запланованого вантажу разом з іншими товарами для одного рейсу.

00:11:44.500 --> 00:11:45.920
Далі справу бере на себе склад.

00:11:46.100 --> 00:11:50.020
Працівники відбирають товари зі зберігання, пакують їх і доставляють у потрібну зону завантаження.

00:11:50.180 --> 00:11:55.120
Оскільки відправлення належить до вантажу, команда бачить, які товари мають виїхати разом і який перевізник їх забере.

00:11:55.300 --> 00:11:59.900
Коли транспорт прибуває, товари переміщуються зі складу до перевізника, а той доставляє їх клієнту.

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

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

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

00:12:07.300 --> 00:12:13.200
Транспортний планувальник міг тримати окремий список, а хтось біля воріт завантаження шукав в імейлах, який перевізник має взяти, які піддони.

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

00:12:16.860 --> 00:12:20.080
З управлінням транспортуванням вантаж надає командам спільний запис.

00:12:20.300 --> 00:12:27.760
Склад бачить товари, пов'язані з вантажем, планувальник, деталі відправлення, а координатор – запланованого перевізника та послугу.

00:12:27.760 --> 00:12:34.240
Замість передавання паперових списків люди працюють з інформацією, пов'язаною з одним замовленням і відправленням.

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

00:12:35.620 --> 00:12:39.080
На складі є замовлення для кількох клієнтів в одному районі доставки.

00:12:39.280 --> 00:12:44.840
Один клієнт замовив коробки засобів для чищення, інший – паперові вироби, а третій – невелику партію обладнання.

00:12:44.840 --> 00:12:49.480
Кожне замовлення потребує комплектації та пакування, але транспортній команді не потрібно розглядати їх як окремі рейси.

00:12:49.620 --> 00:12:51.920
Вони об'єднують ці відправлення в один запланований вантаж.

00:12:51.920 --> 00:12:56.100
Працівники складу комплектують кожне замовлення, правильно його пакують і готують до відправлення в зону завантаження.

00:12:56.260 --> 00:12:59.600
Запис про завантаження повідомляє їм, що всі ці відправлення транспортуються разом.

00:12:59.740 --> 00:13:03.040
Коли прибуває перевізник, команда передає товари одним запланованим рейсом,

00:13:03.160 --> 00:13:06.180
замість того, щоб в останній момент намагатися підібрати піддони для водія.

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

00:13:08.600 --> 00:13:12.620
Проте за лаштунками бізнес спланував цю доставку як частину масштабнішого переміщення.

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

00:13:15.620 --> 00:13:19.340
замість того, щоб працювати на випередження або чекати на інструкції, які надійшли запізно.

00:13:19.480 --> 00:13:22.920
Вхідні перевезення діють за тією ж логікою лише в іншому напрямку.

00:13:23.120 --> 00:13:27.100
Замовлення на закупівлю свідчить про те, що ваша компанія очікує отримання товарів від постачальника.

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

00:13:33.280 --> 00:13:37.560
Постачальник відправляє вантаж, перевізник доставляє його на ваш об'єкт, а склад приймає.

00:13:37.660 --> 00:13:40.880
Персонал із приймання може підготуватися, оскільки знає, що має прибути.

00:13:41.040 --> 00:13:44.060
Вони можуть перевірити заплановане завантаження відповідно до товарів, що прибули на рампу.

00:13:44.160 --> 00:13:48.720
Це значно зручніше, ніж неочікувана поява вантажівки, коли хтось намагається з'ясувати, до якого замовлення належать піддони.

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

00:13:51.600 --> 00:13:54.820
Один підрозділ компанії відправляє запаси, а інший – отримує їх.

00:13:54.820 --> 00:14:00.640
Перший склад готує товари та відправляє їх, а другий склад очікує на ті ж самі товари і оприбутковує їх до своїх запасів.

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

00:14:06.280 --> 00:14:10.140
Завантаження об'єднує процеси відправлення та отримання навколо одного запланованого переміщення.

00:14:10.140 --> 00:14:13.820
Вибір клієнтом способу доставки також залишається прив'язаним до рішення про відправлення.

00:14:13.820 --> 00:14:18.820
Якщо планувальник обирає швидшу службу доставки, тому що клієнту потрібні товари терміново, цей вибір пов'язується з відправленням.

00:14:19.420 --> 00:14:23.960
Якщо бізнес використовує дешевший сервіс, оскільки термін доставки це дозволяє, такий вибір також фіксується.

00:14:24.120 --> 00:14:28.160
Працівники можуть відстежити вартість доставки до конкретного маршруту та перевізника, які були обрані.

00:14:28.280 --> 00:14:32.520
Транспортний засіб може покинути рампу, а товари – безпечно прибути, але роботу ще не завершено.

00:14:32.660 --> 00:14:36.520
Після цього перевізник надсилає рахунок за перевезення, і хтось має його перевірити.

00:14:36.520 --> 00:14:42.020
Витрати на фрахт та їх звірка. Товари вже залишили склад, і доставка може бути навіть виконана.

00:14:42.180 --> 00:14:44.160
Потім надходить рахунок від перевізника.

00:14:44.340 --> 00:14:49.900
Цей рахунок потрібно перевірити, оскільки сума в ньому має відповідати транспортному рішенню, яке компанія спланувала раніше,

00:14:50.020 --> 00:14:54.440
включаючи перевізника, маршрут, послугу, деталі вантажу та очікувану вартість фрахту.

00:14:54.580 --> 00:15:00.180
Під час планування Dynamics 365 може розрахувати очікувану вартість транспортування на основі тарифів компанії.

00:15:00.180 --> 00:15:04.240
Ця очікувана сума дає бізнесу точку відліку до того, як перевізник попросить оплату.

00:15:04.360 --> 00:15:07.100
Пізніше перевізник надсилає свій рахунок на вантажоперевезення.

00:15:07.280 --> 00:15:11.980
Звірка вантажів означає порівняння цього рахунка з тарифом і деталями відправлення, вже внесеними в систему.

00:15:12.140 --> 00:15:17.380
Простою мовою, компанія перевіряє, чи виставив перевізник ту суму, на яку компанія очікувала за фактично надану послугу перевезення.

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

00:15:20.000 --> 00:15:23.980
У рахунку перевізника також вказано 500 доларів і деталі відправлення збігаються.

00:15:24.140 --> 00:15:28.000
Цей рахунок проходить процес перевірки без перешкод, оскільки плановий запис і рахунок збігаються.

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

00:15:30.920 --> 00:15:34.940
Можливо, тарифна таблиця була неправильною, можливо, перевізник виставив рахунок за іншу послугу,

00:15:35.020 --> 00:15:37.900
або вантаж змінився після планування і на рахування потребує пояснення.

00:15:38.040 --> 00:15:40.860
Без пов'язаного запису фінансовий відділ бачить лише номер рахунка та суму,

00:15:40.860 --> 00:15:44.520
а потім витрачає час на запити до складу та транспортної команди, щоб з'ясувати, що сталося.

00:15:44.640 --> 00:15:48.240
Управління транспортуванням підтримує зв'язок транспортного рішення з цією перевіркою.

00:15:48.380 --> 00:15:52.780
Правила дозволяють порівнювати рахунок перевізника з очікуваною сумою та плановою інформацією про відправлення.

00:15:52.900 --> 00:15:56.780
Коли деталі відповідають прийнятим у компанії правилам, рахунок може рухатися далі.

00:15:56.940 --> 00:16:00.480
Коли деталі не збігаються, система надсилає розбіжність комусь на розгляд.

00:16:00.660 --> 00:16:03.900
Це означає, що люди не схвалюють кожен транспортний рахунок на ослів.

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

00:16:07.720 --> 00:16:11.100
або комусь із фінансового відділу потрібно запитати, чому виникло додаткове нарахування.

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

00:16:14.260 --> 00:16:16.620
Сенс у тому, щоб помітити невідповідність до моменту оплати.

00:16:16.760 --> 00:16:19.580
Це об'єднує операційний та фінансовий відділи навколо одного і того самого відправлення.

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

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

00:16:23.960 --> 00:16:29.100
Склад відправляє товар, а фінансовий відділ звіряє пізніший рахунок із записом про те, що планувала компанія.

00:16:29.260 --> 00:16:32.680
Кожна команда бачить свою частину, але вони працюють із пов'язаними даними.

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

00:16:35.140 --> 00:16:38.760
Компанії, яким потрібен масштабний, високоавтоматизований аудит вантажоперевезень,

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

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

00:16:45.660 --> 00:16:50.140
Вбудований модуль обробляє планову вартість і звірку в межах управління ланцюгами постачень,

00:16:50.260 --> 00:16:54.080
тоді як інша система може розширити ці можливості, якщо бізнесу потрібно більше.

00:16:54.480 --> 00:16:59.500
Зберіть усі ці елементи разом і з'явиться повна картина того, де це підходить, а де ні.

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

00:17:02.560 --> 00:17:07.560
Воно належить до Dynamics 365 Supply Chain Management, що працює на базі додатків Finance & Operations.

00:17:07.780 --> 00:17:09.840
Це його дім. Ось кому це підходить.

00:17:10.000 --> 00:17:13.220
Компанії, яким потрібен структурований підхід до планування вхідних поставок,

00:17:13.220 --> 00:17:15.900
від вантажень клієнтам, переміщення запасів між підрозділами,

00:17:16.020 --> 00:17:19.320
використовуючи власні записи про перевізників, тарифи та правила завантаження.

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

00:17:21.920 --> 00:17:23.620
Business Central – це інша історія.

00:17:23.780 --> 00:17:26.700
Business Central не містить цього вбудованого модуля управління перевезеннями.

00:17:26.820 --> 00:17:29.100
Якщо ви використовуєте Business Central і вам потрібне планування транспортування,

00:17:29.100 --> 00:17:31.500
вам варто звернути увагу на сторонню систему управління перевезеннями TMS.

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

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

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

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

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

00:17:42.500 --> 00:17:44.840
ширший вибір логістичних партнерів або глибоке відстеження товарів

00:17:44.840 --> 00:17:47.080
після виходу з ДОКа підключається сторонні рішення TMS.

00:17:47.240 --> 00:17:49.380
Ці інструменти відповідають за зовнішню діяльність.

00:17:49.540 --> 00:17:51.220
Згадайте приклад з офісною будівлею.

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

00:17:54.120 --> 00:17:56.840
Він взаємодіє із замовленнями, складською роботою та фінансами.

00:17:57.000 --> 00:17:59.440
Він утримує власний план перевезень компанії в цілісності.

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

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

00:18:05.980 --> 00:18:08.020
Висновок. Наступна порція знань.

00:18:08.180 --> 00:18:10.120
Ось найпростіший спосіб – це зрозуміти.

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

00:18:13.880 --> 00:18:16.000
Потім воно пов'язує цей рух із витратами на фрахт,

00:18:16.000 --> 00:18:17.580
які компанія перевіряє згодом.

00:18:17.580 --> 00:18:18.740
Це повний цикл.

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

00:18:21.340 --> 00:18:25.900
Поділіться цією порцією знань із тими, хто вивчає Dynamics 365 Supply Chain Management.

00:18:26.120 --> 00:18:28.920
А далі ознайомтеся з нашими епізодами про склад та інвентаризацію.

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