WEBVTT

00:00:00.000 --> 00:00:06.680
Коли клієнт натискає «купити» на вашому сайті, потрібний товар може лежати на складі у магазині на іншому кінці міста або у партнера з доставки.

00:00:06.820 --> 00:00:11.340
Утім, клієнт очікує лише двох речей – чіткої обіцянки та пакунка біля своїх дверей.

00:00:11.480 --> 00:00:15.200
Вітаємо у черговому епізоді Microsoft Knowledge Nuggets на М365FM.

00:00:15.360 --> 00:00:20.000
Я Мо Пітерс, і сьогодні ми розглянемо інтелектуальне управління замовленнями в Dynamic з 365-ма простою мовою.

00:00:20.120 --> 00:00:23.980
Ми простежимо за цим замовленням від кліку на сторінці оплати до процесу, який забезпечує його доставку.

00:00:30.000 --> 00:00:34.320
Він просто спрямовує потрібних людей і системи так, щоб робота виконувалася в правильному місці.

00:00:34.780 --> 00:00:36.880
Чому замовлення стають хаотичними?

00:00:37.240 --> 00:00:43.360
Уявіть, що ви продаєте одні й ті самі навушники через свій сайт, фізичні магазини, онлайн-маркетплейс та колл-центр.

00:00:43.540 --> 00:00:46.380
Для клієнта це все просто різні способи купити навушники.

00:00:46.540 --> 00:00:50.520
Але за лаштунками кожен канал передає деталі замовлення в абсолютно різні системи.

00:00:50.640 --> 00:00:53.960
На вашому сайті зберігається один запис, у магазині на касі інший,

00:00:53.960 --> 00:00:58.600
Маркетплейс надсилає дані у власному форматі, а оператор колл-центру створює замовлення деінде.

00:00:58.740 --> 00:01:03.120
Одна проста обіцянка клієнту розпадається на кілька рухомих частин, які не взаємодіють між собою.

00:01:03.260 --> 00:01:05.660
А складські запаси додають ще один рівень складності.

00:01:05.780 --> 00:01:07.700
На головному складі може бути 20 пар.

00:01:07.840 --> 00:01:11.160
У магазині через дорогу 5 і ще один склад також має запаси.

00:01:11.260 --> 00:01:13.460
Але він далі, а вартість доставки там вища.

00:01:13.600 --> 00:01:17.540
Частина товару вже зарезервована для інших замовлень, повернень або покупців у магазині.

00:01:17.540 --> 00:01:20.360
Тому цифра поруч із товаром насправді не вирішує проблему.

00:01:20.520 --> 00:01:22.560
Потім вам потрібно вирішити, як доставити товар.

00:01:22.680 --> 00:01:23.940
Чи має його відправити склад.

00:01:24.120 --> 00:01:25.440
Чи має це зробити магазин.

00:01:25.560 --> 00:01:27.380
Або клієнт може забрати його самостійно.

00:01:27.460 --> 00:01:29.780
А якщо хтось купує два товари, але жодна локація не має обох,

00:01:29.860 --> 00:01:32.940
чи розділяти замовлення на дві посилки, чи чекати, поки все можна буде відправити разом.

00:01:33.060 --> 00:01:36.500
Кожен вибір впливає на вартість, термін доставки та обіцянку, яку ви дали клієнту.

00:01:36.500 --> 00:01:39.880
Два десятиліття тому компанії виконували ці завдання в окремих системах за допомогою різних команд.

00:01:40.060 --> 00:01:41.460
Відділ продажів приймав замовлення.

00:01:41.600 --> 00:01:42.960
Хтось перевіляв наявність на складі.

00:01:43.120 --> 00:01:44.120
Склад отримував запит.

00:01:44.260 --> 00:01:45.900
Партнер з доставки отримував інший запит.

00:01:46.060 --> 00:01:47.940
Відділ розрахунків займався своєю частиною пізніше.

00:01:48.060 --> 00:01:50.660
Це працювало добре, коли замовлення були простими, а обсяги – невеликими.

00:01:50.780 --> 00:01:51.720
Але ось у чому річ.

00:01:51.900 --> 00:01:55.460
Коли оновлення між системами рухаються повільно, люди починають заповнювати ці прогалини вручну.

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

00:01:59.520 --> 00:02:03.520
і тим часом товар може бути проданий через інший канал, перш ніж оновлення запасів дійде до сайту.

00:02:03.640 --> 00:02:05.940
Тепер у вас є замовлення на те, чого ви не можете надіслати.

00:02:06.120 --> 00:02:07.860
Саме так стається перевищення обсягів продажу.

00:02:08.000 --> 00:02:10.220
І саме тому вибір варіантів доставки займає забагато часу.

00:02:10.340 --> 00:02:14.720
Команди постійно копіюють дані з місця на місце, а клієнти отримують розмиті відповіді замість конкретики.

00:02:14.720 --> 00:02:20.220
Для клієнта вся ця складність не має значення, адже він ставить лише одне запитання – де моє замовлення?

00:02:20.360 --> 00:02:24.840
Компанії насправді потрібне єдине місце, де можна бачити шлях замовлення через усі пов'язані бізнес-додатки,

00:02:24.940 --> 00:02:27.260
водночас дозволяючи кожному додатку робити свою справу.

00:02:27.380 --> 00:02:29.000
Відділ продажів реєструє продаж.

00:02:29.160 --> 00:02:30.720
Склад керує збором та пакуванням.

00:02:30.860 --> 00:02:32.420
Служба доставки забезпечує відправлення.

00:02:32.560 --> 00:02:33.880
Бухгалтерія опрацьовує платежі.

00:02:34.020 --> 00:02:35.880
Нікому не потрібно викидати всі наявні системи.

00:02:35.880 --> 00:02:37.700
Бракує лише координатора між ними.

00:02:37.880 --> 00:02:44.220
Ой, місце, яке може прийняти замовлення, зрозуміти наступні кроки та спрямувати роботу без ланцюга ручних передач.

00:02:44.360 --> 00:02:45.500
Ось у чому проблема.

00:02:45.760 --> 00:02:50.800
Dynamics 365 Intelligent Oda Management відповідає цьому простому визначенню.

00:02:50.940 --> 00:02:55.040
То що саме таке Dynamics 365 Intelligent Oda Management?

00:02:55.860 --> 00:02:57.880
Ми розберемо це простими словами.

00:02:58.680 --> 00:03:00.340
Ось найпростіше визначення.

00:03:00.340 --> 00:03:08.960
Це хмарний додаток, який приймає замовлення та веде його через усі системи компанії від моменту надходження до завершення виконання та оплати.

00:03:09.240 --> 00:03:11.180
Уявіть жвавий залізничний вокзал.

00:03:11.320 --> 00:03:13.240
Поїзди прибувають з різних напрямків.

00:03:13.380 --> 00:03:15.100
Пасажирам потрібні різні платформи.

00:03:15.280 --> 00:03:17.600
Деякі пересадки швидкі, інші потребують очікування.

00:03:17.780 --> 00:03:20.540
Intelligent Oda Management працює як диспетчерська вокзалу.

00:03:20.660 --> 00:03:25.400
Він не керує поїздом і не продає квитки, але бачить увесь маршрут і підказує кожній системі, що робити далі.

00:03:25.400 --> 00:03:28.680
Microsoft побудувала Intelligent Oda Management на базі Dataverse.

00:03:28.680 --> 00:03:33.820
Dataverse – це спільна платформа даних для багатьох додатків Dynamics 365 та Pava Platform.

00:03:34.000 --> 00:03:38.900
Простими словами, це надає бізнес-додаткам єдине місце та формат для зберігання інформації.

00:03:39.100 --> 00:03:43.180
Це означає, що замовлення не має зовсім іншого значення в кожному екрані чи системі.

00:03:43.300 --> 00:03:48.940
Ця спільна основа допомагає, але вам не обов'язково купувати всі інші додатки Dynamics 365, щоб користуватися Intelligent Oda Management.

00:03:49.160 --> 00:03:53.080
Компанія може використовувати Dynamics 365 Finance або Supply Chain Management.

00:03:53.080 --> 00:03:58.240
Інша може мати власну складську систему, інший інтернет-магазин або службу доставки від іншого постачальника.

00:03:58.420 --> 00:04:01.980
Цей додаток може працювати як з продуктами Microsoft, так і з іншими бізнес-рішеннями.

00:04:02.100 --> 00:04:04.120
Точки підключення називаються провайдерами.

00:04:04.260 --> 00:04:08.800
Провайдер передає дані про замовлення та виконання між Intelligent Oda Management та іншою системою.

00:04:08.960 --> 00:04:10.980
Уявіть провайдера як перекладача на вході.

00:04:11.120 --> 00:04:13.580
Одна система надсилає замовлення у власному форматі.

00:04:13.580 --> 00:04:20.720
Провайдер розпізнає цей формат, передає інформацію в Intelligent Oda Management і може надіслати наступний запит у форматі, зрозумілому, іншій системі.

00:04:20.840 --> 00:04:24.820
Отже, додаток збирає інформацію про замовлення в одному місці, навіть якщо воно було оформлене деінде.

00:04:24.980 --> 00:04:27.540
Клієнт може зробити покупку через торговельний сайт AIO.

00:04:27.740 --> 00:04:30.420
Інший може оформити замовлення через систему точок продажу.

00:04:30.580 --> 00:04:34.100
Бізнес-клієнт може надіслати електронне замовлення через B2B-процес.

00:04:34.100 --> 00:04:39.320
Інтелектуальне управління замовленнями надає компанії єдине місце для перегляду замовлень та відстеження етапу їх виконання.

00:04:39.500 --> 00:04:41.480
Не кожне замовлення проходить однаковий шлях.

00:04:41.600 --> 00:04:44.940
Одне може очікувати на наявність товару, інше може вже перебувати на складі.

00:04:45.080 --> 00:04:47.440
Третє може потребувати виставлення рахунку після доставки.

00:04:47.600 --> 00:04:51.240
Додаток відстежує цей стан, щоб команда бачила не лише статус «Замовлення отримано».

00:04:51.240 --> 00:04:54.100
Вони можуть бачити, на якому саме етапі шляху перебуває замовлення.

00:04:54.100 --> 00:04:56.200
Ось момент, який люди іноді пропускають.

00:04:56.200 --> 00:04:59.280
Інтелектуальне управління замовленнями не бере на себе всю роботу.

00:04:59.500 --> 00:05:04.980
Воно не стає раптом екраном збирання для комірника, мережею доставки перевізника чи системою рахунків фінансового відділу.

00:05:05.100 --> 00:05:08.080
Ці підключені додатки продовжують виконувати свою спеціалізовану роботу.

00:05:08.260 --> 00:05:11.300
Інтелектуальне управління замовленнями спрямовує передачу даних між ними.

00:05:11.540 --> 00:05:16.100
Воно отримує запит, перевіряє маршрут, передає завдання далі та чекає на наступне оновлення.

00:05:16.100 --> 00:05:21.700
Тепер простежимо за одним замовленням, оскільки шлях замовлення робить усю концепцію набагато зрозумілішою.

00:05:21.860 --> 00:05:24.760
Шлях замовлення – це правила, що керують роботою.

00:05:24.920 --> 00:05:30.940
Уявіть, що клієнт замовляє два товари на вашому сайті пізно ввечері і хоче, щоб обидва були доставлені завтра.

00:05:31.100 --> 00:05:36.900
Інтернет-магазин фіксує замовлення ім'я клієнта, адресу доставки, дві товарні позиції та обраний спосіб доставки.

00:05:37.060 --> 00:05:41.480
Провайдер передає це замовлення в систему інтелектуального управління і шлях замовлення розпочинається.

00:05:41.480 --> 00:05:48.420
Перш ніж хтось спробує виконати його, система перевіряє замовлення, щоб переконатися, що вся інформація наявна і відповідає правилам компанії.

00:05:48.620 --> 00:05:51.520
Вона перевіряє заголовок замовлення щодо даних клієнта та доставки.

00:05:51.720 --> 00:05:54.140
Вона перевіряє кожну позицію щодо продукту та кількості.

00:05:54.340 --> 00:05:59.360
Вона підтверджує, що адреса містить достатньо інформації для доставки і перевіряє відповідність правилам каналу продажу.

00:05:59.540 --> 00:06:03.980
Ця первинна перевірка зупиняє поширення помилкових даних, перш ніж вони спричинять проблеми.

00:06:04.080 --> 00:06:06.120
Уявіть замовлення без номера квартири.

00:06:06.120 --> 00:06:11.860
Якщо воно одразу потрапить на склад, а потім до перевізника, проблему можуть помітити лише тоді, коли посилку не вдасться доставити.

00:06:12.020 --> 00:06:17.120
Етап перевірки виявляє проблему раніше, поки ще є час зв'язатися з клієнтом або притримати замовлення.

00:06:17.260 --> 00:06:19.880
Основою для цієї роботи є потік оркестрації.

00:06:20.080 --> 00:06:22.380
Цей вислів звучить технічно, але він простий.

00:06:22.500 --> 00:06:29.920
Потік оркестрації – це візуальна карта, яка вказує системі управління, що робити, коли надходить інформація про замовлення та приходять події від підключених систем.

00:06:29.920 --> 00:06:32.640
Ви створюєте цю карту на основі власних бізнес-процесів.

00:06:32.760 --> 00:06:35.540
Базовий потік замовлення може починатися з моменту надходження нового замовлення.

00:06:35.680 --> 00:06:37.160
Він перевіряє заголовок і рядки.

00:06:37.320 --> 00:06:39.560
Він надсилає замовлення для прийняття рішень щодо виконання.

00:06:39.700 --> 00:06:42.620
Після цього він надсилає замовлення на виконання до потрібної підключеної системи.

00:06:42.720 --> 00:06:46.560
Коли робота досягає потрібного етапу, він може надіслати інформацію про замовлення постачальнику послов з виставлення рахунків.

00:06:46.680 --> 00:06:48.180
Кожна дія має чітке завдання.

00:06:48.180 --> 00:06:51.100
Перевірка заголовка замовлення звіряє основні деталі замовлення.

00:06:51.200 --> 00:06:54.300
Перевірка рядка замовлення звіряє окремі товари та їхню кількість.

00:06:54.440 --> 00:06:58.420
Надсилання на виконання передає замовлення на виконання постачальнику, який відповідає за цю роботу.

00:06:58.560 --> 00:07:02.100
Надсилання рахунку передає інформацію про замовлення постачальнику послуг з виставлення рахунків.

00:07:02.200 --> 00:07:08.520
Ці назви звучать як позначки на панелі керування заводом, і це корисно, оскільки кожна позначка точно вказує, що відбувається в цей момент потоку.

00:07:08.620 --> 00:07:11.760
Але реальному бізнесу часто потрібно більше, ніж одна пряма лінія.

00:07:11.760 --> 00:07:15.780
Можливо, замовлення з веб-сайту йдуть одним шляхом, а від бізнес-клієнтів – іншим.

00:07:15.940 --> 00:07:18.420
Можливо, один тип продукту потребує спеціального схвалення.

00:07:18.580 --> 00:07:21.460
Можливо, замовлення може рухатися далі, лише якщо перший крок успішний.

00:07:21.680 --> 00:07:24.660
Інтелектуальне управління замовленнями включає умови для такого вибору.

00:07:24.780 --> 00:07:26.800
Умова створює шлях, так і шлях – ні.

00:07:26.960 --> 00:07:30.600
Якщо попередня дія успішна, замовлення може продовжуватися шляхом – так.

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

00:07:33.940 --> 00:07:37.980
Це не вирішує кожну проблему само по собі, але забезпечує заплановану реакцію процесу замість того,

00:07:38.120 --> 00:07:40.580
щоб покладатися на те, що команда випадково виявить помилку.

00:07:40.700 --> 00:07:42.220
Також існують розділювачі.

00:07:42.360 --> 00:07:45.780
Розділювач спрямовує потік на кілька шляхів на основі визначених вами правил.

00:07:45.920 --> 00:07:49.240
Ви можете використовувати його, коли замовлення з різних джерел потребують різних перевірок,

00:07:49.320 --> 00:07:51.500
або коли різні частини роботи потребують різних маршрутів.

00:07:51.500 --> 00:07:55.320
Деякі розділені шляхи можуть знову з'єднуватися пізніше, тоді як інші продовжуються окремо.

00:07:55.480 --> 00:07:58.280
Користувацькі дії охоплюють завдання, унікальні для бізнесу.

00:07:58.400 --> 00:08:03.220
Можливо, у компанії є власна виробнича система або система партнера, яка не охоплена стандартною дією.

00:08:03.360 --> 00:08:05.820
Користувацька дія може підключити цей крок до потоку замовлень,

00:08:05.940 --> 00:08:09.540
щоб маршрут відображав увесь процес, а не приховував частину в листах чи ручній роботі.

00:08:09.660 --> 00:08:11.880
Повернімося до нашого замовлення з двох позицій.

00:08:11.880 --> 00:08:15.800
Система отримує його з веб-сайту та перевіряє дані клієнта, адресу та товарні позиції.

00:08:15.940 --> 00:08:18.880
Потім замовлення досягає етапу прийняття рішення щодо виконання.

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

00:08:24.040 --> 00:08:27.880
Якщо правила компанії вимагають іншого результату, замовлення може обрати інший шлях.

00:08:28.000 --> 00:08:32.540
Можливо, для двох товарів потрібні окремі запити на виконання, можливо, замовлення потребує іншого вибору доставки.

00:08:32.540 --> 00:08:37.620
Потік не вгадує. Він слідує правилам, створеним бізнесом і подіям, які повертають підключені системи.

00:08:37.740 --> 00:08:39.440
Ця остання частина має значення.

00:08:39.600 --> 00:08:44.240
Інтелектуальне управління замовленнями може спрямовувати роботу, але підключені системи звітують, коли робота просувається вперед.

00:08:44.340 --> 00:08:46.940
Постачальник послуг з виконання замовлень може отримати запит.

00:08:47.040 --> 00:08:49.480
Білінговий провайдер може отримати деталі замовлення.

00:08:49.640 --> 00:08:52.300
Ці події забезпечують рух замовлення через весь процес.

00:08:52.460 --> 00:08:54.980
Отже, цей додаток – не одна гігантська система заміни.

00:08:54.980 --> 00:08:59.300
Це набір правил, що об'єднує спеціалістів, надаючи кожній системі потрібну роботу в потрібний час.

00:08:59.440 --> 00:09:01.140
Інтернет-магазин приймає замовлення.

00:09:01.300 --> 00:09:03.380
Система виконання замовлень займається їх опрацюванням.

00:09:03.480 --> 00:09:05.480
Білінгова система займається виставленням рахунків.

00:09:05.620 --> 00:09:08.520
Інтелектуальне управління замовленнями керує маршрутом між цими завданнями.

00:09:08.660 --> 00:09:12.580
Відповідальні за процес замовлення фахівці можуть створювати ці потоки безпосередньо в додатку.

00:09:12.580 --> 00:09:18.540
Їм не потрібно писати кожен шлях як традиційний код і не потрібно просити IT-адміністратора змінювати кожне бізнес-правило.

00:09:18.720 --> 00:09:22.220
Це дає команді з логістики можливість моделювати саме той процес, який їм потрібен.

00:09:22.340 --> 00:09:24.180
Проте ці зміни потребують обережності.

00:09:24.360 --> 00:09:27.920
Потік оркестрації залишається неопублікованим, поки ви його створюєте та тестуєте.

00:09:28.080 --> 00:09:30.600
На цьому етапі вхідні дані не проходять через потік.

00:09:30.780 --> 00:09:34.720
Після публікації потік та його дії запускаються, коли дані надходять у систему.

00:09:34.720 --> 00:09:37.900
Після публікації ви не можете редагувати цей потік безпосередньо.

00:09:38.000 --> 00:09:42.840
Якщо бізнесу потрібні зміни, команда може зупинити опублікований потік, що повертає його до неопублікованого стану.

00:09:42.980 --> 00:09:46.140
Вони можуть відредагувати потік, а потім опублікувати нову версію, коли вона буде готова.

00:09:46.240 --> 00:09:49.920
Така організація спонукає команди тестувати маршрут до того, як ним підуть реальні замовлення.

00:09:50.060 --> 00:09:53.160
Маршрут працює лише тоді, коли він знає, які запаси є в наявності.

00:09:53.160 --> 00:09:57.640
Це підводить нас до оперативної інформації про запаси, що стоїть за кожним рішенням щодо виконання.

00:09:57.800 --> 00:10:01.320
Видимість запасів – це розуміння того, що ви можете реально продати.

00:10:01.480 --> 00:10:02.560
Ось проста істина.

00:10:02.740 --> 00:10:06.080
Ви не можете виконати замовлення, якщо не знаєте, що маєте цей товар на складі.

00:10:06.220 --> 00:10:12.080
Звучить очевидно, але запаси можуть ховатися на складі у магазині, у партнерському пункті або в різних юридичних особах всередині однієї компанії.

00:10:12.240 --> 00:10:17.500
Коли кожна локація веде власний облік, ви не можете відповісти на просте запитання, що я можу гарантувати цьому клієнту прямо зараз.

00:10:23.160 --> 00:10:25.040
Як табло запасів у розподільчому центрі.

00:10:25.160 --> 00:10:31.060
Замість того, щоб дзвонити на кожен склад і просити когось перевірити, процес замовлення дивиться на один спільний огляд, куди надходять дані з усіх ваших систем.

00:10:31.240 --> 00:10:35.720
Тепер, якщо товар відображається як запас десь, це не означає, що він може виконати будь-яке замовлення.

00:10:35.840 --> 00:10:44.280
Продукт може лежати на складі, але вже бути зарезервованим або він знаходиться в магазині, що продає лише локально, або він просто занадто далеко, щоб дотриматися обіцяного клієнту терміну доставки.

00:10:44.280 --> 00:10:49.440
Існує велика різниця між запасами, які десь існують, і запасами, які можуть виконати це замовлення прямо зараз.

00:10:49.540 --> 00:10:52.760
Уявіть, що клієнт купив куртку онлайн і хоче отримати її завтра.

00:10:52.940 --> 00:10:55.000
На вашому головному складі її вже немає.

00:10:55.180 --> 00:11:04.320
Без актуальних даних про запаси ваш сайт може прийняти замовлення за старими показниками, і тоді склад отримає запит на товар, якого не може надіслати, через що клієнт дізнається про це лише після оплати.

00:11:04.500 --> 00:11:06.280
Це створює зайву роботу для всіх.

00:11:06.280 --> 00:11:13.140
Завдяки об'єднаній інформації про запаси інтелектуальна система управління замовленнями бачить, що на головному складі куртки немає, але вона є в магазині поруч.

00:11:13.280 --> 00:11:16.120
Якщо цей магазин підтримує доставку, він може виконати замовлення.

00:11:16.260 --> 00:11:19.520
Якщо клієнт обрав самовивіз, той самий магазин стає точкою видачі.

00:11:19.680 --> 00:11:22.060
Рішення починається з кращого огляду залишків.

00:11:22.240 --> 00:11:26.340
Для компанії з кількома юридичними особами цей огляд охоплює запаси всіх підрозділів.

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

00:11:32.140 --> 00:11:36.480
Процес обробки замовлення використовує дані про запаси в реальному часі для вибору подальших дій.

00:11:36.680 --> 00:11:40.820
Склад, магазин або інше джерело запасів, як і раніше, веде власні записи.

00:11:40.980 --> 00:11:46.640
Видимість запасів надає актуальні дані для ширшого процесу замовлення, де їх можуть використовувати правила виконання.

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

00:11:54.140 --> 00:12:00.420
Замість пошуку в кількох системах з надією, що інформація збігається, команда бачить стан запасів, що вплинув на вибір способу виконання.

00:12:00.580 --> 00:12:03.900
Звісно, бачити всі можливі місця – це ще не відповідь на всі питання.

00:12:04.100 --> 00:12:06.240
Ви можете знайти товар у п'яти точках.

00:12:06.420 --> 00:12:11.360
Одна найближча до клієнта, інша з більшим запасом, третя дозволяє відправити обидва товари разом.

00:12:16.640 --> 00:12:19.180
Виконання

00:12:19.180 --> 00:12:21.140
Оптимізація

00:12:21.140 --> 00:12:24.160
Вибір найкращого місця для відправлення замовлення

00:12:24.160 --> 00:12:29.740
Оптимізація порівнює можливі місця виконання замовлення та обирає одне з них на основі встановлених вами правил.

00:12:29.880 --> 00:12:33.480
Простою мовою, вона відповідає на питання, звідки має надійти це замовлення.

00:12:33.660 --> 00:12:35.600
Найкраще не завжди означає найближче.

00:12:35.780 --> 00:12:39.220
Найближчий магазин може мати товар, але доставка звідти може коштувати дорожче.

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

00:12:46.080 --> 00:12:48.940
Кожна компанія має вирішити, чому надавати перевагу в правилах.

00:12:49.080 --> 00:12:51.420
Деякі бізнеси ставлять швидкість доставки на перше місце.

00:12:51.600 --> 00:12:53.580
Інші хочуть мінімізувати витрати на доставку.

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

00:13:00.460 --> 00:13:04.680
Інтелектуальне управління замовленнями використовує стратегії виконання, що відображають ці вибори.

00:13:04.840 --> 00:13:07.360
Думайте про це як про вибір маршруту для фургона доставки.

00:13:07.540 --> 00:13:12.160
Найкоротша дорога не завжди найшвидша, адже можуть бути затори, дорожні роботи чи затримки в дорозі.

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

00:13:19.700 --> 00:13:22.540
Повернімося до клієнта, який придбав два товари онлайн.

00:13:22.700 --> 00:13:25.200
У магазині за 10 хвилин від нього є перший товар.

00:13:25.200 --> 00:13:28.320
На складі є обидва товари, але він розташований далі.

00:13:28.660 --> 00:13:35.940
Якщо магазин відправить перший товар, а склад – другий, клієнт отримає дві посилки вчасно, але це підвищить витрати на доставку.

00:13:35.940 --> 00:13:38.580
Склад може відправити обидва товари разом.

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

00:13:43.300 --> 00:13:46.780
Правила можуть надавати перевагу меншій кількості відправлень та нижчим витратам на доставку.

00:13:46.780 --> 00:13:52.460
Але якщо доставка на завтра важливіша за відправлення товарів разом, система може вибрати магазин для одного товару, а склад – для іншого.

00:13:52.580 --> 00:13:53.800
Це і є розділене замовлення.

00:13:53.940 --> 00:13:56.480
Розділене замовлення не означає, що система дала збій.

00:13:56.620 --> 00:14:00.780
Це може бути плановим рішенням, коли жодна локація не може виконати замовлення повністю належним чином.

00:14:00.960 --> 00:14:04.900
Бізнес вирішує, коли доцільно розділяти замовлення за допомогою обраної стратегії виконання.

00:14:04.900 --> 00:14:08.040
Такий самий підхід підтримує купівлю онлайн з відправкою з магазину.

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

00:14:12.680 --> 00:14:16.560
Тож цей магазин стає джерелом виконання замовлення, навіть якщо клієнт там ніколи не був.

00:14:16.700 --> 00:14:19.920
Це також підтримує купівлю онлайн із самовивозом у магазині.

00:14:20.100 --> 00:14:25.200
Система використовує дані про запаси та місцезнаходження, щоб знайти магазин для самовивозу,

00:14:25.200 --> 00:14:29.940
тому клієнт отримує зручний варіант, а компанія спрямовує замовлення, куди потрібно.

00:14:30.480 --> 00:14:34.420
Ці рішення не обов'язково мають бути окремими для кожного каналу продажу.

00:14:34.420 --> 00:14:40.800
Без єдиного процесу прийняття рішень вебсайт, маркетплейс і кол-центр можуть потребувати власних правил маршрутизації.

00:14:40.960 --> 00:14:45.200
Коли бізнес змінює політику доставки або починає використовувати магазини для виконання замовлень,

00:14:45.300 --> 00:14:47.180
командам доводиться оновлювати кілька систем.

00:14:47.400 --> 00:14:51.700
Оптимізація виконання замовлень зосереджує цей процес в одному місці протягом усього шляху замовлення.

00:14:51.700 --> 00:14:56.580
Вебсайт продовжує приймати замовлення, маркетплейс – замовлення, а магазин – продавати товари.

00:14:56.580 --> 00:15:06.980
Але компанія може змінити спосіб вибору локації без перебудови правил у кожному каналі, отримуючи більше контролю, коли рухаються запаси, змінюються обіцянки щодо доставки або з'являються нові опції.

00:15:07.200 --> 00:15:13.400
Однак стратегія виконання може порівнювати локації лише тоді, коли необхідна інформація надходить від систем, що нею володіють.

00:15:13.400 --> 00:15:19.820
Замовлення мають надходити, оновлення запасів мають приходити, а партнери з виконання – отримувати завдання та звітувати про прогрес.

00:15:19.960 --> 00:15:22.540
Ця робота з підключення залежить від провайдерів.

00:15:22.540 --> 00:15:25.840
Провайдери та підключення – це двері до будівлі.

00:15:26.000 --> 00:15:30.980
Щоб інтелектуальне керування замовленнями виконувало свою роботу, йому потрібен надійний спосіб взаємодії з усім навколо.

00:15:31.100 --> 00:15:33.060
Провайдери – це те, що робить це можливим.

00:15:33.180 --> 00:15:39.240
Провайдер – це, по суті, підключення, яке передає дані замовлень та оновлення виконання між інтелектуальним керуванням, замовленнями та іншою системою.

00:15:39.360 --> 00:15:42.960
Інформація передається в обох напрямках, тому нікому не потрібно копіювати її вручну.

00:15:43.080 --> 00:15:45.180
Уявіть будівлю з багатьма дверима для доставки.

00:15:45.180 --> 00:15:50.160
Одні двері отримують замовлення з вашого інтернет-магазину, інші з'єднуються з вашою системою обліку запасів.

00:15:50.280 --> 00:15:53.000
Треті надсилають завдання на склад або партнеру з доставки.

00:15:53.140 --> 00:15:57.300
Кожні двері мають чітке призначення, а провайдери керують інформацією, що проходить крізь них.

00:15:57.460 --> 00:16:00.040
Microsoft створює частину цих коннекторів самостійно.

00:16:00.200 --> 00:16:02.300
Вони називають їх провайдерами першої сторони.

00:16:02.440 --> 00:16:09.980
Вони з'єднують інтелектуальне керування замовленнями з такими програмами, як Dynamics 365 Supply Chain Management, Dynamics 365 Commerce або Dynamics 365 Finance.

00:16:09.980 --> 00:16:15.540
Служби обліку запасів і виконання замовлень у межах інтелектуального керування також використовують ці провайдери для обміну даними.

00:16:15.680 --> 00:16:17.860
Тепер, імовірно, у вас уже є інші системи.

00:16:17.960 --> 00:16:19.860
Ось тут і стають у пригоді сторонні провайдери.

00:16:20.020 --> 00:16:22.220
Вони підключають сервіси, які Microsoft не розробляє.

00:16:22.360 --> 00:16:26.320
Можливо, це ваша наявна платформа електронної комерції, торговий майданчик, логістична компанія або складська система.

00:16:26.520 --> 00:16:28.940
Мета полягає не в тому, щоб змусити вас використовувати певний набір програм.

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

00:16:32.640 --> 00:16:35.820
За лаштунками ці провайдери використовують коннектори Pava Otamate.

00:16:35.980 --> 00:16:40.280
Pava Platform має понад 200 готових коннекторів, тому у вас є багато варіантів для старту.

00:16:40.440 --> 00:16:43.840
А якщо жоден з них не підходить, ви або ваш партнер можете створити власного провайдера.

00:16:44.000 --> 00:16:46.260
Кожна підключена програма продовжує виконувати свою роботу.

00:16:46.420 --> 00:16:48.140
Ваш інтернет-магазин фіксує покупку.

00:16:48.320 --> 00:16:50.200
Система обліку запасів відстежує залишки.

00:16:50.340 --> 00:16:52.440
Партнер з виконання пакує та доставляє замовлення.

00:16:52.440 --> 00:16:54.720
Система виставлення рахунків опрацьовує фінанси.

00:16:54.820 --> 00:16:58.380
Інтелектуальне керування замовленнями координує повідомлення та наступні кроки між усіма ними.

00:16:58.540 --> 00:17:03.120
Коли ці системи обмінюються оновленнями, ваш бізнес може бачити, що відбувається в межах усього процесу замовлення.

00:17:03.300 --> 00:17:06.100
Більше не потрібно шукати інформацію на окремих екранах.

00:17:06.920 --> 00:17:08.520
Інсейти та загальну картину

00:17:08.520 --> 00:17:12.760
Ця спільна інформація надає набагато чіткіше уявлення про вашу роботу із замовленнями.

00:17:12.760 --> 00:17:18.040
Інтелектуальне керування замовленнями включає інформаційні панелі PAVABI, які об'єднують показники замовлень та виконання в одному місці.

00:17:18.180 --> 00:17:20.980
Служба підтримки клієнтів може знайти замовлення, які перестали рухатися.

00:17:21.120 --> 00:17:24.140
Операційний відділ може помітити заблоковані маршрути або затримки виконання.

00:17:24.280 --> 00:17:27.220
А бізнес-лідери можуть шукати закономірності в межах усього процесу.

00:17:27.380 --> 00:17:30.500
Без такого огляду затримка може здаватися ізольованою проблемою.

00:17:30.500 --> 00:17:39.140
Але коли дані зібрані разом, ваша команда може помітити, що багато замовлень сповільнюється у конкретного партнера з виконання або що певний варіант доставки створює більше винятків, ніж очікувалося.

00:17:39.320 --> 00:17:43.800
Інформаційна панель не вирішує проблему сама по собі, але вона допомагає людям знати, де саме шукати.

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

00:17:45.400 --> 00:17:56.440
Інтелектуальне управління замовленнями об'єднує стійку реєстрації, що приймає запити, складську дошку з наявністю товарів, планувальник маршрутів для вибору місця виконання та звітний центр, де команди бачать перебіг усіх процесів.

00:17:56.560 --> 00:18:00.300
Кожна частина має своє завдання, але замовлення пов'язує їх усіх.

00:18:01.140 --> 00:18:04.520
Висновок «Одне замовлення, одна скоординована подорож».

00:18:04.520 --> 00:18:06.980
Дякую, що приєдналися до цієї порції знань.

00:18:06.980 --> 00:18:12.580
Інтелектуальне управління замовленнями прокладає єдиний прямий маршрут через увесь ваш процес від первинного отримання до кінцевого рахунку.

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

00:18:15.940 --> 00:18:19.940
Ви побачите, як саме Dynamics 365 та Pava Platform виконують роботу за лаштунками.