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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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