Вітаємо вас на ще одному епізоді Microsoft Knowledge Nuggets, тут на М365FM. Ваш ведучий Мірко Пітерс. Сьогоднішня тема – це те, про що чув майже кожен, хто працює з ланцюгами постачання, але мало хто справді розуміє. Dynamics 365 Transportation Management. Ось у чому проблема. Клієнт робить замовлення, товар лежить на складі, перевізнику потрібен час на вивезення, клієнт чекає на доставку, а згодом на чий стіл потрапляє рахунок за фрахт. Роками ці етапи існували в окремих таблицях, телефонних дзвінках, прайс-листах та через передачу завдань між командами. О, і це створює прогалини. Склад може підготувати товари до того, як транспорт матиме план. Фінанси можуть побачити рахунок, не знаючи, про що хтось домовився щодо оплати. Отже, що саме таке управління транспортуванням? Простою мовою – це транспортний відділ у межах Dynamics 365 Supply Chain Management. Він об'єднує складські ворота, постачальників, клієнтів та перевізників.

Ми плануватимемо завантаження, обиратимемо маршрути і тарифи, відправлятимемо товари та перевірятимемо витрати на фрахт. Наприкінці цього епізоду ви побачите, як усі ці частини складаються докупи, щоб полегшити ваше робоче життя.

Почнемо з базової істини. Фізичні товари не рухаються лише тому, що замовлення на продаж з'явилося на екрані. Їм потрібен вантажівка, причіп, контейнер або інший спосіб переміщення. Хтось має знати, звідки товар виїжджає, куди має прибути, скільки місця він займає, коли має відправитися і скільки має коштувати поїздка. Коли ви уявляєте одну коробку, що прямує до одного клієнта, це звучить просто. Але реальна компанія може відправляти багато замовлень з одного складу в той самий день, приймати товари від кількох постачальників і переміщувати запаси між власними об'єктами одночасно. З кожним переміщенням пов'язані люди, дати, простір та гроші. Без спільної системи кожен відділ бачить лише свою частину роботи. Відділ продажів бачить замовлення клієнта. Відділ закупівель бачить замовлення постачальника. Працівники складу бачать товари, які потрібно відібрати, упакувати, прийняти або розмістити.

Транспортна команда бачить список того, що має бути переміщений, часто вже після того, як усі інші зробили свою справу. І саме тут починаються затримки та плутанина. Ось конкретний приклад. Уявіть, що на складі готово десятьох замовлень клієнтів для одного і того ж міста. Якщо ніхто не об'єднає ці замовлення перед бронюванням транспорту, компанія може організувати кілька напівпорожніх рейсів, або перевізник прибуде раніше, ніж склад зрозуміє, які товари належать до цього вантажу. Товари готові, але переміщення не сплановане. Отже, управління транспортуванням надає цьому процесу належне місце в системі Dynamics 365 Supply Chain Management. Це не окремий споживчий додаток для відстеження, де ви вводите номер накладної та спостерігаєте за рухом посилки на карті. Натомість він працює з бізнес-записами, що вже містяться в підключеній платформі. Замовлення створює потребу в переміщенні товарів.

Складська робота готує товари до відправки. Управління транспортуванням планує, як ці товари рухатимуться між локаціями. Уявіть це як транспортний відділ у бізнес-центрі. Команда з продажу приносить запит від клієнта до відділу. Відділ закупівель повідомляє, що постачальник надійшли товари. Склад надає фактичні запаси та доступ до вантажних платформ. Транспортний відділ пов'язує ці запити з транспортним планом компанії. Існує два основні напрямки. Вхідне транспортування означає, що товари надходять до вашого бізнесу. Ви замовили товари у постачальника, і вони мають потрапити на ваш склад. Іноді поїздку контролює постачальник, іноді – ваша компанія. У будь-якому разі вам потрібен чіткий план доставки товарів у потрібне місце та їхнього приймання. Вихідне транспортування означає, що товари вирушають з вашого бізнесу. Клієнт замовив продукти. Склад готує їх, а перевізник або власний транспорт компанії доставляє їх клієнту.

Обидва потоки стосуються руху, але мають різні вихідні точки. Вхідний потік починається із замовлення на закупівлю та постачальника. Вихідний потік починається із замовлення на продаж та клієнта. Існує також третій тип, який початківці часто пропускають – замовлення на переміщення. Замовлення на переміщення рухає запаси між вашими власними локаціями. Можливо, на одному складі забагато запасів, а іншому вони потрібні. Тут немає продажу клієнту, але фізичні товари все одно потребують транспортування. У системі 365 Transportation Management замовлення на переміщення належать до сценарію вихідних відправлень і планується разом із замовленнями на продаж. Це логічно, якщо уявити вантажний майданчик. Адже незалежно від того, чи прямує піддон до клієнта, чи на інший склад компанії, комусь все одно потрібно організувати транспорт, зарезервувати місце і відправити його через ті самі двері. Отже, цей інтегрований підхід замінює старий ланцюжок окремих списків та телефонних дзвінків на спільну інформацію.

Замовлення повідомляє системі, що потрібно перемістити. Склад готує товари. Управління транспортуванням перетворює цю потребу на план перевезення. Коли товари мають вирушити в дорогу, системі спершу потрібен робочий план доставки. Планування вантажу. Сьогоднішня корисна порада про те, що потрібно кожній логістичній команді, хоча пояснюють це всі по-різному. Планування вантажу. Ви можете почати планування транспортування як із замовлень, так і з відправлень. Я Мірко Петерс із М365. FM і дозвольте мені одразу розвіяти один міф. План доставки не створюється з нуля. Він починається із записів, які у вас уже є. Замовлення на продаж містить те, що придбав клієнт. Замовлення на купівлю містить перелік того, що має надіслати постачальник. Відправлення групує ці товари в більш цілісний транспортний запис, готовий до поєднання з іншими. Отже, з чого варто почати? Це залежить від того, як працює ваша компанія.

Деякі команди планують заздалегідь, працюючи безпосередньо з рядками замовлень. Інші команди спочатку створюють відправлення, а потім вирішують, що транспортувати разом. Обидва шляхи ведуть до одного і того самого питання, що має бути завантажено на один транспортний засіб. Ось найпростіше визначення. Вантаж – це цифровий запис для запланованого переміщення товарів. Можна уявити це як одну вантажівку, один причіп, один контейнер або набір відправлень, що перевозяться разом. Це дає вам єдине місце, де можна побачити, які товари мають бути разом до початку фізичної роботи. А тепер момент, у якому багато хто помиляється. Вантаж не означає, що всі товари вмістяться в одну фізичну коробку. Це означає, що система групує товари навколо одного плану транспортування. Кілька відправлень для клієнтів можуть розділяти одну вантажівку. Велике замовлення може заповнити весь причіп самостійно. Контейнер від постачальника також може стати вантажем ще до того, як ваш склад отримає товари.

Суть у тому, щоб перестати розглядати кожне замовлення як окрему поїздку. Уявіть, що дистриб'ютор має шість клієнтських замовлень, готових до доставки на п'ятницю. Усі шість знаходяться в одній зоні, і кожне замовлення заповнює лише частину вантажівки. Надсилання шести напівпорожніх машин – це марнування місця та шість окремих транспортних завдань. Натомість команда може згрупувати сумісні відправлення в один вантаж. Сумісні означає, що вони можуть логічно подорожувати разом. Вони виїжджають з одного складу, мають бути відправлені приблизно в один час, відповідають обмеженням транспортного засобу та вашим правилам доставки. Система допомагає об'єднати ці записи, замість того, щоб покладатися на когось, хто шукатиме закономірності в електронній таблиці. Тепер ця група має спільний план. Ваш склад бачить, що саме входить до складу вантажу. Планувальник перевезень бачить загальну вагу та обсяг.

Людям не потрібно переписувати один і той самий список в емейлах, нотатках чи окремих файлах. Але є нюанс. Групування товарів – це не просто додавання більшої кількості предметів разом. Вантажівка має обмеження вага, площа підлоги, висота. Контейнер має свої власні правила. Якщо система групує товари без перевірки цих обмежень, вантаж може виглядати добре на екрані, але не пройти на вантажній платформі. Dynamics 365 використовує шаблони вантажів, щоб допомогти уникнути цього. Сприймайте шаблон вантажу як багаторазовий набір обмежень для певного типу транспортного засобу чи контейнера. Створіть один для невеликої вантажівки, інший для більшого причепа, ще один для морського контейнера. Кожен шаблон містить обмеження щодо ваги, об'єму, висоти та інших правил, необхідних вашій компанії. Шаблон надає вантажу певну форму ще до того, як ви почнете його наповнювати. Тож, якщо відправлення занадто важке або займає забагато місця, планувальник бачить, що воно не підходить для цього вантажу.

Рішенням може бути другий транспортний засіб, інший шаблон або інше групування відправлень. Програмне забезпечення не підіймає піддони, але воно надає вашій команді чіткіший план до початку фізичної роботи. Один із вбудованих підходів називається формуванням вантажу на основі об'єму. Це звучить складніше, ніж є насправді. Це означає, що система використовує максимальну висоту та вагу з вашого шаблону при створенні або пропонованні вантажу. Простою мовою вона перевіряє, чи вписуються товари в межі, які ви встановили. Ці значення не є фіксованими назавжди. Планувальник може змінити їх, коли змінюються реальні потреби. Можливо, перевізник надіслав інший причіп. Можливо, маршрут дозволяє іншу висоту. Шаблон задає загальне правило, а зміна налаштувань обробляє виняток без необхідності все переробляти. Повернімося до тих шести замовлень клієнтів. Кожне з них окремо може займати 15% вантажівки.

Якщо планувати окремо, можна відправити шість майже порожніх машин. Згруповані в один вантаж, ті самі замовлення можуть заповнити більшу частину однієї вантажівки, залишивши місце для іншого. Це краще використання простору. Ця сама ідея працює в обох напрямках. Для планування вхідних вантажів створіть вантаж на основі товарів, що надходять від постачальника. План перевезення пов'язується з очікуваним надходженням, тому склад знає, що має прибути і готується до отримання. Замість того, щоб дізнаватися про доставку лише тоді, коли вона з'являється на воротах, команда отримувачів має запланований запис. Для планування вихідних вантажів виберіть складські товари, які потрібно відправити клієнтам, і згрупуйте їх у вантаж. Склад готує ці товари на основі даних про вантаж, а не за розрізненим списком. Для одного повного вантажу все одно потрібен спосіб перевезення, компанія для транспортування та очікувана вартість.

Маршрути, перевізники та тарифи. Тепер вантаж показує вам, що має подорожувати разом. Далі вам потрібно вирішити, хто це перевозитиме, яку службу вони використають і якою має бути вартість поїздки. Компанію, яка перевозить ваші товари, називають перевізником. Це може бути зовнішня транспортна компанія, яка забирає та доставляє ваш вантаж. Це також може означати ваш власний автопарк, якщо у вас є власні вантажівки та водії. У будь-якому випадку перевізник відповідає за фізичне виконання поїздки. Ця відмінність важлива, тому що вам все одно потрібен план, навіть якщо вантажівка належить вам. Зі стороннім перевізником ви домовляєтеся про ціни та послуги заздалегідь. З власним автопарком ви все одно можете захотіти розрахувати вартість перевезення, особливо якщо витрати на доставку відображаються у замовленнях клієнтів. Dynamics 365 керування транспортуванням підтримує обидві ситуації. Далі йде маршрут.

Маршрут – це запланований шлях від місця забору до пункту призначення разом із вибором послуги. Він відповідає на практичні питання. З якого складу перевізник забирає вантаж? Який клієнт або об'єкт отримує товари? Яка служба перевізника виконує поїздку? Уявіть доставку, що вирушає з вашого головного складу до клієнта в іншому кінці країни. Один маршрут може використовувати стандартні автомобільні перевезення, що дешевші, але триваліші. Інший може використовувати швидшу, дорожчу послугу. Початок і кінець ті самі, але вибір транспорту змінюється. Тариф – це очікувана плата за цей вибір. Це не випадкове число, введене в останню хвилину. Тарифи базуються на цінових угодах з перевізниками в поєднанні з деталями відправлення чи маршруту. Звідки вирушають товари, куди прямують, яка послуга використовується обсяг транспортування. Отже, маршрут вказує, як мають переміщатися товари. Тариф показує, скільки ви очікуєте заплатити.

Ці дві ідеї не розривні, бо дешевий маршрут може порушити терміни доставки, а швидкість може коштувати дорожче, ніж дозволяє замовлення. Планування перевезень – це не просто пошук вантажівки, це вибір послуги, яка відповідає з обов'язанням перед клієнтом та правилам витрат компанії. Dynamics 365 містить робоче місце для тарифів і маршрутів. Назва звучить офіційно, але мета проста. Вона дає плановальникам змогу порівнювати варіанти маршрутів і тарифів для відправлення поруч. Замість того, щоб перевіряти таблиці одного перевізника, потім іншого і порівнювати в окремому файлі, ви розглядаєте варіанти, що стосуються цієї потреби у відправленні. Можливо, один варіант доставить товар клієнту раніше. Можливо, інший коштує менше. Система не знає, що кожен клієнт цінує швидкість більше за ціну, бо бізнес працює по-різному. Клієнт міг заплатити за термінову доставку, тому швидший маршрут має сенс.

Інший погоджується на довший термін і нижча ціна підходить краще. Люди все ще приймають рішення. Управління транспортуванням надає вам узгоджені варіанти та очікувані витрати, тоді як ваш бізнес вирішує, який компроміс кращий. Ось що насправді робить вбудований модуль. Інформація про тарифи надходить із тарифних таблиць, які ваша компанія вносить і підтримує в Dynamics 365. Вважайте ці таблиці збереженими записами узгоджених цін перевізників і правил маршрутизації. Якщо ви домовилися про ціну на певну послугу та напрямок, ця інформація залишається в системі та підтримує планування. Це добре працює, коли ваші тарифи відповідають відомим угодам. Наприклад, ви працюєте з кількома постійними перевізниками, обслуговуєте знайомі маршрути та оновлюєте ціни, коли змінюються контракти. Планувальник перевезень використовує вже записані тарифи, замість того, щоб шукати в старих електронних листах. Але є дещо, що багато хто розуміє неправильно.

Вбудований модуль не діє як торговий майданчик у реальному часі, підключений до кожного перевізника. Він не отримує автоматично актуальні ціни з живих стрічок і не порівнює їх у реальному часі в широкій мережі. Якщо вашій компанії потрібен порівняльний аналіз тарифів кількох перевізників, онлайн-бронювання або детальні оновлення статусу вантажу зазвичай підключають сторонню систему. Це не є недоліком управління транспортуванням. Воно чітко визначає свою роль. Ці інструменти забезпечують структуроване планування перевезень у межах управління ланцюгами постачання, використовуючи дані про перевізників, маршрути і тарифи. І це також неспоживчий веб-сайт для відстеження посилок. Ви не використовуватимете його як карту, де вводиш номер накладної і спостерігаєш, як значок автомобіля рухається дорогою. Цей модуль зосереджений на бізнес-рішеннях щодо транспортування до та під час відправлення. Які товари перевозити разом, який перевізник їх обслуговує, який маршрут обрати, якою має бути вартість поїздки.

Як тільки компанія обирає план, складські та транспортні команди повинні втілити його в життя. Від дверей складу до дверей клієнта транспортний план допомагає лише тоді, коли його можна перетворити на реальне відправлення. Для вихідного замовлення процес зазвичай починається з того, що клієнт купує товар. Замовлення на продаж вказує бізнесу, що потрібно клієнту, куди це має потрапити і коли має прибути. Це замовлення стає відправленням, яке приєднується до запланованого вантажу разом з іншими товарами на той самий рейс. Потім роботу бере на себе склад. Працівники збирають товари зі зберігання, пакують їх і доставляють у потрібну зону навантаження. Оскільки відправлення є частиною вантажу, Команда бачить, які товари мають поїхати разом і який перевізник їх забере. Коли прибуває транспорт, товари переміщуються зі складу до перевізника, а той доставляє їх клієнту. Кожен крок під'єднаний до одного і того самого запису про переміщення.

Це звучить будинно, але уявіть, як це було раніше. Комплектувальник міг працювати за роздрукованим замовленням. Транспортний планувальник міг мати окремий список. А хтось біля воріт навантаження міг шукати в електронних листах, який перевізник має забрати, які палити. Якщо змінювалася хоча б одна деталь, усім потрібна була оновлена версія. Завдяки управлінню транспортуванням вантаж надає командам спільний запис. Склад бачить товари, що належать до вантажу, планувальник бачить деталі відправлення, а особа, що організовує отримання запланованого перевізника та послугу. Замість передачі кількох паперових списків люди працюють з інформацією, пов'язаною з одним і тим самим замовленням. Ось простий приклад. На складі є замовлення для кількох клієнтів в одній зоні доставки. Один клієнт замовив коробки мийних засобів, інший – паперові вироби, а третій – невелику партію обладнання. Кожне замовлення потрібно зібрати та запакувати, але транспортна команда не повинна розглядати їх як абсолютно окремі поїздки.

Вони призначають відправлення до одного запланованого вантажу. Персонал складу збирає кожне замовлення, правильно пакує його та готує до зони завантаження. Запис про вантаж повідомляє їм, що всі ці відправлення подорожують разом. Коли прибуває перевізник, команда передає товари для одного запланованого переміщення, замість того, щоб намагатися в останню хвилину підібрати піддони для водія. Клієнт все одно отримує власне замовлення. Проте за лаштунками бізнес спланував цю доставку як частину ширшого переміщення. Цей зв'язок допомагає складу працювати разом із транспортною командою, а не випереджати її або чекати на інструкції, які надходять запізно. Вхідні перевезення дотримуються тієї самої пов'язаної ідеї просто в іншому напрямку. Замовлення на закупівлю свідчить про те, що ваша компанія очікує товари від постачальника. Коли ваш бізнес організовує перевезення, запланований вхідний вантаж пов'язує вхідні товари з поїздкою ще до того, як вони потраплять на склад.

Постачальник відправляє вантаж, перевізник доставляє його на ваш об'єкт, а склад приймає його. Персонал з прийому може підготуватися, бо знає, що має прибути. Вони можуть звірити запланований вантаж із товарами, що з'являються на доці, це набагато зрозуміліше, ніж несподівана поява вантажівки та спроби з'ясувати, до якого замовлення належать піддони. Замовлення на переміщення також відповідають цьому процесу. Один об'єкт компанії відправляє запаси, а інший об'єкт компанії отримує їх. Перший склад готує товари та відправляє їх, а другий склад очікує ті самі товари та приймає їх до своїх запасів. Наприкінці цієї поїздки немає стороннього клієнта, але компанії все одно потрібна чітка передача між двома локаціями. Вантаж поєднує роботу з відправлення та отримання навколо одного запланованого переміщення. Вибір доставки клієнтом також залишається пов'язаним із рішенням про відправлення. Якщо планувальник обирає швидшу службу перевізника, тому що клієнту потрібні товари швидко, цей вибір пов'язується з відправленням.

Якщо бізнес використовує менш дорогий сервіс, оскільки дата доставки це дозволяє, цей вибір також враховується. Люди можуть відстежити вартість доставки до маршруту та вибору перевізника, який її створив. Транспортний засіб може залишити док, а товари можуть прибути безпечно, але робота ще не завершена. Після цього перевізник надсилає рахунок за фрахт, і хтось має його перевірити. Витрати на фрахт та їх звірка. Товари залишили склад, і доставка може бути навіть завершена. Тоді надходить рахунок від перевізника. Цей рахунок потребує перевірки, оскільки сума в ньому має відповідати транспортному рішенню, яке компанія планувала раніше, включаючи перевізника, маршрут, послугу, деталі вантажу та очікувану вартість перевезення. Під час планування Dynamics 365 може розрахувати очікувану вартість перевезення на основі тарифної інформації компанії. Ця очікувана сума дає бізнесу відправну точку ще до того, як перевізник надійшли запит на оплату.

Пізніше перевізник надсилає свій рахунок за фрахт. Узгодження фрахту означає порівняння цього рахунка з тарифами та деталями відправлення, вже внесеними в систему. Простою мовою, компанія перевіряє, чи виставив перевізник рахунок на очікувану суму за послугу, яка фактично перевезла вантаж. Уявіть, що в плані вказана сума 500 доларів. Рахунок перевізника також містить 500 доларів і деталі відправлення збігаються. Цей рахунок проходить процес перевірки без перешкод, оскільки запланований запис і рахунок збігаються. Але рахунки не завжди збігаються з планом. Можливо, тарифна таблиця була помилковою, можливо, перевізник виставив рахунок за іншу послугу або вантаж змінився після планування і на рахування потребує пояснення. Без пов'язаного запису фінансовий відділ може бачити лише номер рахунка та суму, витрачаючи час на з'ясування того, що сталося у складської та транспортної команд. Управління транспортуванням підтримує зв'язок транспортного рішення з цією перевіркою.

Правила дозволяють порівняти рахунок перевізника з очікуваною сумою та запланованою інформацією про відправлення. Коли деталі відповідають прийнятим у компанії правилам, рахунок може бути опрацьований далі. Коли деталі не збігаються, система спрямовує розбіжність на перевірку фахівцю. Це означає, що люди не схвалюють кожну суму за фрахт на ослів. Транспортному планувальнику може знадобитися підтвердити, що перевізник використав іншу послугу або фінансисту з'ясувати причину додаткових нарахувань. Справа не в тому, щоб вважати кожну невідповідність помилкою. Справа в тому, щоб помітити невідповідність до здійснення платежу. Це об'єднує операційний та фінансовий відділи навколо одного відправлення. Транспортна команда обирає перевізника та послугу. Цей вибір формує очікувану вартість. Склад відправляє вантаж, а фінансовий відділ перевіряє отриманий рахунок на відповідність запису про те, що планувала компанія.

Кожна команда бачить свою частину, але вони працюють із пов'язаною інформацією. Проте вбудований процес має чіткі межі. Компанії, яким потрібен масштабний, високоавтоматизований аудит фрахту, часто додають сторонню систему управління транспортуванням. Ці інструменти можуть забезпечити глибші зв'язки з перевізниками та більше автоматизованих правил перевірки. Вбудований модуль опрацьовує планові витрати та звірку всередині управління ланцюгами постачання, тоді як інша система може розширити ці можливості, якщо бізнесу потрібно більше. Зберіть усі ці будівельні блоки разом і почне вимальовуватися повна картина, де це застосовується і чого цей інструмент не робить. Отже, де насправді знаходиться управління транспортуванням. Воно належить і до складу Dynamics 365 Supply Chain Management, що працює в додатках Finance & Operations. Це його дім. Ось для кого воно підходить. Компаніям, яким потрібен структурований спосіб планування вхідних поставок, вихідних відправлень клієнтам, переміщення запасів між майданчиками, використовуючи власні записи перевізників, таблиці тарифів та правила завантаження.

Тепер давайте прояснимо поширену причину непорозумінь. Business Central – це інша справа. Business Central не містить цього вбудованого модуля управління транспортуванням. Якщо ви працюєте в Business Central і вам потрібне планування перевезень, вам слід звернути увагу на сторонні системи управління транспортуванням. Це межа можливостей. Давайте також окреслимо межі з іншого боку. Вбудований модуль не замінює всі портали перевізників, сервіси відстеження трафіку чи інструменти розширеного трекінгу. Коли бізнесу потрібні актуальні тарифи від багатьох перевізників, ширший вибір логістів або глибше відстеження після того, як товари покинули склад, підключається сторонній ТМС. Ці інструменти обробляють зовнішню активність. Згадайте офісну будівлю. Управління транспортуванням – це транспортний відділ всередині цієї будівлі. Він пов'язаний із замовленнями, складськими роботами та фінансами. Він об'єднує власний транспортний план компанії.

Зовнішні інструменти перевізників можуть обробляти діяльність за межами цього відділу. Два різні рівні, що працюють разом. Висновок. Наступний фрагмент знань. Ось найпростіший спосіб подумати про це. Управління транспортуванням перетворює бізнес-замовлення на запланований рух товарів. Потім воно пов'язує цей рух із витратами на фрахт, які компанія перевіряє згодом. Це повний цикл. Підписуйтесь на вашій улюбленій подкаст-платформі. Поділіться цим фрагментом знань з тим, хто вивчає Dynamics 365 Supply Chain Management. Потім ознайомтеся з нашими наступними епізодами про склад та інвентаризацію. Кожне завантаження все одно залежить від запасів, що знаходяться за дверима складу.