WEBVTT

00:00:00.000 --> 00:00:02.300
Уявіть, що клієнт хоче отримати 100 велосипедів наступного місяця.

00:00:02.380 --> 00:00:03.760
Рами прибувають із запізненням.

00:00:03.880 --> 00:00:05.280
Колеса лежать на іншому складі.

00:00:05.380 --> 00:00:07.500
А ваша складальна лінія вже завантажена роботою на найближчі два тижні.

00:00:07.620 --> 00:00:08.620
Отже, що вам купувати?

00:00:08.800 --> 00:00:09.600
Що вам будувати?

00:00:09.800 --> 00:00:10.740
Що вам переміщати?

00:00:10.900 --> 00:00:12.320
І коли вам потрібна кожна деталь?

00:00:12.460 --> 00:00:12.960
А вже ж!

00:00:13.040 --> 00:00:15.420
Міл Копетас із М365FM.

00:00:15.540 --> 00:00:19.380
Цей екскурс узнання стосується Dynamics 365 Master Planning.

00:00:19.600 --> 00:00:23.720
Це частина управління ланцюгами постачання, яка вирішує ці питання залаштунками.

00:00:23.720 --> 00:00:26.760
Уявіть свій бізнес як офісну будівлю з прибудованим складом.

00:00:26.880 --> 00:00:28.620
Замовлення надходять через одні двері.

00:00:28.800 --> 00:00:30.140
Запаси лежать на полицях.

00:00:30.260 --> 00:00:32.400
Постачальники доставляють товари на вантажну платформу.

00:00:32.560 --> 00:00:34.800
Виробництво перетворює деталі на готову продукцію.

00:00:34.960 --> 00:00:40.220
Генеральне планування охоплює всю будівлю, замість того, щоб залишати кожну команду зі своїм окремим списком.

00:00:40.420 --> 00:00:45.900
Сьогодні ми з Гертманом простежимо за одним замовленням велосипедів від запиту клієнта до дій із постачання.

00:00:46.100 --> 00:00:51.020
Dynamics 365 пояснює, чому бізнесу потрібен план, а не електронна таблиця.

00:00:51.020 --> 00:00:55.440
До появи інструментів інтегрованого планування компанії працювали з розрізнаною інформацією.

00:00:55.600 --> 00:00:58.000
Відділ продажів мав замовлення клієнтів в одному місці.

00:00:58.140 --> 00:01:02.860
Складські команди перевіряли запаси в іншій системі, відділ закупівель відстежував терміни постачальників у листах чи таблицях,

00:01:02.940 --> 00:01:05.920
а виробництво ввело власні записи про те, що фабрика може збудувати цього тижня.

00:01:06.040 --> 00:01:07.900
Кожен список виглядав правильним окремо.

00:01:08.020 --> 00:01:11.040
Проблеми починалися, коли хтось намагався відповісти на одне запитання клієнта.

00:01:11.040 --> 00:01:13.780
От, чи зможемо ми доставити 100 велосипедів до обіцяної дати?

00:01:13.920 --> 00:01:14.840
Ayola Tafts.

00:01:14.880 --> 00:01:17.660
Уявіть, що на складі сьогодні є 30 готових велосипедів.

00:01:17.800 --> 00:01:21.040
Це звучить як гарний початок, але замовлення все ще потребує ще 70 велосипедів.

00:01:21.720 --> 00:01:28.980
А для цих 70-тьох велосипедів потрібні рами, колеса, ланцюги, сидіння, болти, пакувальні матеріали, люди для їх збирання та час на відповідних верстатах.

00:01:29.120 --> 00:01:32.580
Простий підрахунок запасів показує лише те, що зараз лежить на полиці.

00:01:32.580 --> 00:01:36.980
Це не скаже вам, чи встигнуть прибути ще 70 рам до того, як вони знадобляться виробництву.

00:01:37.100 --> 00:01:40.840
Це не скаже вам, чи покриває відкрите замовлення на закупівлю вже наявні колеса.

00:01:40.980 --> 00:01:45.580
І це не скаже вам, чи має фабрика достатньо часу, щоб зібрати все разом, додати доставки.

00:01:45.760 --> 00:01:49.580
Ось у чому річ, ось де планування стає чимось більшим, ніж просто підрахунок.

00:01:50.180 --> 00:01:54.020
Коли клієнт замовляє 100 велосипедів, система дивиться на попит у 100 одиниць.

00:01:54.140 --> 00:01:56.680
Вона віднімає 30 велосипедів, які вже є в наявності.

00:01:56.800 --> 00:01:59.120
Потім вона відстежує, що має статися для решти 70.

00:01:59.120 --> 00:02:01.880
Вона перевіряє деталі, необхідні для готового велосипеда.

00:02:01.980 --> 00:02:03.940
Вона перевіряє постачання, яке вже в дорозі.

00:02:04.040 --> 00:02:06.500
І вона перевіряє дати, закріплені за кожним етапом роботи.

00:02:06.620 --> 00:02:08.780
Одна відсутня деталь може змінити всю відповідь.

00:02:08.900 --> 00:02:10.980
Можливо, у вас достатньо коліс і сидінь.

00:02:11.080 --> 00:02:15.680
Але якщо для постачання рам потрібно два тижні, закупівля їх за день до збирання не допоможе.

00:02:15.920 --> 00:02:20.060
Замовлення може виглядати реальним у таблиці, доки ви не розмістите кожну деталь у календарі.

00:02:20.180 --> 00:02:21.940
І цей календар постійно змінюється.

00:02:21.940 --> 00:02:24.320
Постачальник може перенести дату до ставки на ранішу.

00:02:24.420 --> 00:02:27.140
Інше замовлення на продаж може забрати запаси, які, як ви думали, були вільними.

00:02:27.280 --> 00:02:28.940
Виробниче завдання може завершитися із запізненням.

00:02:29.560 --> 00:02:35.600
Коли ці дані знаходяться в різних місцях, люди витрачають весь час на дзвінки, листи, перевірку та оновлення власної версії плану.

00:02:35.760 --> 00:02:37.280
Dynamics 365

00:02:37.280 --> 00:02:41.580
Головне планування збирає поточний попит і поточну пропозицію в єдиний огляд планування.

00:02:41.800 --> 00:02:46.220
Воно считує замовлення клієнтів, наявні запаси, надходження поставок та інформацію про виробництво разом.

00:02:46.220 --> 00:02:49.700
Потім воно визначає, де пропозиція покриває попит, а де залишається дефіцит.

00:02:49.780 --> 00:02:55.640
Замість того, щоб змушувати кожну команду вручну пов'язувати все докупи, система створює пропозиції дій на основі наявної інформації.

00:02:55.820 --> 00:02:58.220
Це не означає, що система керує бізнесом самостійно.

00:02:58.920 --> 00:03:03.140
Планувальник все ще перевіряє пропозиції, ставить запитання та вирішує, що робити.

00:03:03.280 --> 00:03:06.880
Але планувальник починає роботу з цілісної картини, а не з купи окремих списків.

00:03:07.020 --> 00:03:09.100
Уявіть електронну таблицю як фотографію.

00:03:09.260 --> 00:03:12.260
Вона фіксує запаси в один момент часу, і це може бути корисним.

00:03:12.260 --> 00:03:18.680
Головне планування – це радше перспективний графік, оскільки воно пов'язує кількість із датами, надходженням поставок і майбутнім попитом.

00:03:18.860 --> 00:03:23.240
Наступний крок – розділити різні типи попиту, які може считувати процес планування.

00:03:23.840 --> 00:03:25.220
Три режими планування.

00:03:25.560 --> 00:03:28.540
Отже, ось що важливо знати про Dynamics 365.

00:03:29.220 --> 00:03:31.560
Не існує лише одного способу планування.

00:03:31.760 --> 00:03:36.020
Режим планування, який ви використовуєте, залежить від питання, на яке потрібно відповісти вашому бізнесу.

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

00:03:42.840 --> 00:03:44.760
Перший режим – це головне планування.

00:03:44.940 --> 00:03:47.880
Це ваш щоденний план, який розраховує чисті потреби.

00:03:48.000 --> 00:03:53.800
Це просто означає, що система дивиться на те, що вам потрібно, і віднімає запаси, які ви вже маєте або очікуєте отримати.

00:03:53.980 --> 00:04:02.100
Вона считує реальну бізнес-активність, замовлення від клієнтів, замовлення на закупівлю постачальникам, виробничі замовлення на цеху та інвентар на складі.

00:04:02.100 --> 00:04:08.580
Уявіть замовлення клієнта на 100 одиниць продукції. На вашому складі є 30 одиниць, які планування може використати для цього замовлення.

00:04:08.740 --> 00:04:13.300
Система не намагається запропонувати купити або виготовити всі 100 одиниць знову, оскільки бачить ці 30 як наявну пропозицію.

00:04:13.440 --> 00:04:18.160
Отже, вона розраховує залишкову потребу в 70 одиниць. Ці 70 одиниць і є чистою потребою.

00:04:18.340 --> 00:04:21.280
Реальний план може включати більше, ніж просто запаси на полиці.

00:04:21.460 --> 00:04:26.220
Можливо, ще 20 одиниць мають надійти від постачальника до запитаної клієнтом дати.

00:04:26.220 --> 00:04:31.680
У такому разі система враховує і ці 20 одиниць, залишаючи ще менший дефіцит для покриття.

00:04:31.840 --> 00:04:38.000
Але дати визначають результат. Якщо ці 20 одиниць надійдуть після того, як клієнт очікує на доставку, вони не дуже допоможуть.

00:04:38.160 --> 00:04:41.340
Ви фізично їх отримаєте, але запізно для конкретної потреби.

00:04:41.500 --> 00:04:44.280
Головне планування розглядає кількість і терміни разом.

00:04:44.460 --> 00:04:47.580
Звичайна загальна цифра запасів може дати вам хибну відповідь.

00:04:47.720 --> 00:04:50.580
Для багатьох компаній це план, який запускають найчастіше.

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

00:04:55.660 --> 00:04:59.840
Точний діапазон залежить від того, скільки часу займає постачання або виробництво.

00:04:59.980 --> 00:05:04.220
Компанія, що купує прості місцеві товари, може планувати лише на кілька тижнів уперед.

00:05:04.300 --> 00:05:10.480
Але виробнику деталей, на які йдуть місяці, потрібно дивитися далі, часто на весь період повного циклу виробництва.

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

00:05:14.980 --> 00:05:17.160
Другий режим – це прогнозне планування.

00:05:17.160 --> 00:05:22.060
Замість того, щоб починати з підтверджених замовлень, прогнозне планування базується на очікуваному попиті.

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

00:05:28.880 --> 00:05:32.920
Це прогнози, засновані на очікуваннях команди, а не на підтверджених замовленнях.

00:05:33.040 --> 00:05:39.840
Вони корисні, бо очікування кожного замовлення клієнта може залишити за мало часу на закупівлю сировини чи планування виробництва.

00:05:39.840 --> 00:05:44.880
Товари з тривалим циклом постачання потребують рішень заздалегідь ще до отримання фінального замовлення.

00:05:45.000 --> 00:05:50.780
Прогнозне планування розраховує валові потреби. Це означає, що воно починається з очікуваного обсягу попиту.

00:05:50.960 --> 00:05:57.920
Якщо прогноз передбачає 500 велосипедів у липні, планування спочатку враховує повну потребу в 500 одиниць і працює від цього.

00:05:58.140 --> 00:06:01.300
Сприймайте це як погляд у майбутнє на навантаження, що очікує бізнес.

00:06:01.300 --> 00:06:04.960
Ви можете планувати матеріали та потужності відповідно до цього очікуваного обсягу.

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

00:06:10.960 --> 00:06:14.680
Прогнози можуть змінюватися і реальні продажі можуть не збігатися з ними.

00:06:14.880 --> 00:06:19.160
Проте вони дають ширший огляд, ніж план, заснований лише на вже розміщених замовленнях.

00:06:19.280 --> 00:06:21.680
Крім того, існує міжфірмове головне планування.

00:06:21.920 --> 00:06:25.320
Воно стає в пригоді, коли одна юридична особа потребує постачання від іншої.

00:06:25.320 --> 00:06:30.800
Наприклад, одна компанія у вашій групі може виробляти товар, тоді як інша продає його клієнтам в іншій країні.

00:06:30.940 --> 00:06:33.240
Компанія-продавець бачить попит клієнтів.

00:06:33.400 --> 00:06:37.200
Компанія-виробник має бачити потребу в постачанні, яку створює цей попит.

00:06:37.320 --> 00:06:40.400
Міжфірмове планування поєднує ці потреби через кордони компаній,

00:06:40.520 --> 00:06:44.300
включно з плановим попитом і постачанням, що ще не стали твердими замовленнями.

00:06:44.440 --> 00:06:48.080
Отже, компанії не планують свою діяльність так, ніби вони працюють поодинці.

00:06:48.080 --> 00:06:51.340
Торговельна компанія може планувати постачання від виробничої компанії,

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

00:06:55.980 --> 00:06:59.500
Зв'язок передає сигнал планування від однієї юридичної особи до іншої.

00:06:59.660 --> 00:07:01.400
Кожен режим починається з попиту.

00:07:01.580 --> 00:07:07.520
Але попит – це лише перший сигнал, оскільки один готовий виріб може створити ланцюжок потреб у багатьох складниках нижчого рівня.

00:07:07.660 --> 00:07:13.820
Перехід від одного замовлення до ланцюга постачання на прикладі велосипеда – це те, де головне планування починає свою реальну роботу.

00:07:13.820 --> 00:07:19.200
Уявіть, що клієнт розміщує замовлення на 70 велосипедів і просить доставити їх у конкретну дату.

00:07:19.400 --> 00:07:22.000
Ця дата – не просто примітка для відділу продажів.

00:07:22.140 --> 00:07:28.680
Це точка, від якої планування рухається назад, запитуючи, що має статися, перш ніж ці велосипеди зможуть залишити склад.

00:07:28.880 --> 00:07:31.000
Готовий велосипед – це лише перший рівень.

00:07:31.180 --> 00:07:34.920
Dynamics 365 перевіряє специфікацію матеріалів, яку часто називають BOM.

00:07:35.140 --> 00:07:37.600
Думайте про BOM як про рецепт одного велосипеда.

00:07:37.600 --> 00:07:43.240
Він перераховує раму, колеса, ланцюг, сидіння, кермо, гальма, болти та будь-яку іншу деталь, необхідну для його створення.

00:07:43.380 --> 00:07:48.200
Якщо замовлення потребує 70 велосипедів, планування розширює це замовлення до переліку частин, необхідних для всіх 70.

00:07:48.440 --> 00:07:50.760
Це може дуже швидко перетворитися на довгий список.

00:07:50.880 --> 00:07:55.440
Вам може знадобитися 70 рам, 140 коліс, 70 ланцюгів, 70 сидінь і сотні дрібних болтів.

00:07:55.620 --> 00:07:58.100
Планувальнику не доводиться рахувати кожну деталь вручну.

00:07:58.100 --> 00:08:04.920
Специфікація матеріалів дає Dynamics 365 структуру, завдяки якій система може простежити попит від готового велосипеда до кожного компонента.

00:08:05.060 --> 00:08:07.260
Але самі лише деталі не створять велосипеди.

00:08:07.460 --> 00:08:09.300
Для виробництва також потрібен маршрут.

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

00:08:16.840 --> 00:08:18.780
Кожен крок може потребувати ресурсу.

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

00:08:24.640 --> 00:08:28.100
Планування використовує цю інформацію, щоб розмістити роботу в потрібний час.

00:08:28.260 --> 00:08:32.680
Замість того, щоб розглядати виробництво як щось, що відбувається миттєво, саме тут дати починають рухатися назад.

00:08:32.860 --> 00:08:38.920
Якщо клієнту потрібні велосипеди в п'ятницю, готове виробниче замовлення має бути завершене вчетвер, щоб склад міг їх запакувати та відвантажити.

00:08:39.080 --> 00:08:41.340
Збирання, можливо, доведеться розпочати у вівторок.

00:08:41.480 --> 00:08:43.860
Рами та колеса, можливо, повинні надійти до понеділка.

00:08:43.860 --> 00:08:48.760
Якщо постачальнику потрібно 10 днів на доставку коліс, то замовлення на купівлю має залишити вашу компанію ще раніше.

00:08:48.920 --> 00:08:50.820
Дата клієнта створює ланцюжок DAT.

00:08:50.960 --> 00:08:56.040
Dynamics 365 працює у зворотному порядку через цей ланцюжок, враховуючи час виконання замовлень.

00:08:56.180 --> 00:09:03.840
Час виконання замовлення – це просто час, необхідний для чогось чи то постачальник, що доставляє деталь, склад, що переміщує товари, чи фабрика, що завершує роботу.

00:09:04.020 --> 00:09:06.440
Затримка однієї деталі може змістити все інше.

00:09:06.440 --> 00:09:09.220
Припустімо, система знаходить 70 рам на складі.

00:09:09.360 --> 00:09:14.380
Вона також бачить відкрите замовлення на 140 коліс із доставкою, запланованою до початку збірки.

00:09:14.540 --> 00:09:18.240
Це постачання покриває потребу в колесах, тоді як рами вже покривають свою частину.

00:09:18.380 --> 00:09:19.920
Потім система перевіряє ланцюги.

00:09:20.080 --> 00:09:23.580
Можливо, в наявності лише 40 ланцюгів і жодне замовлення на закупівлю не передбачає отримання решти 30.

00:09:23.780 --> 00:09:26.580
Планування бачить розрив і створює пропозицію щодо його усунення.

00:09:26.580 --> 00:09:30.540
Така ж перевірка проводиться для готових велосипедів, деталей до них та будь-якої проміжної роботи.

00:09:30.660 --> 00:09:32.280
Певна кількість запасів уже існує.

00:09:32.440 --> 00:09:34.200
Наявні запаси можуть задовольнити потребу.

00:09:34.340 --> 00:09:37.180
Відкрите замовлення на закупівлю може її задовольнити, якщо товари надійдуть вчасно.

00:09:37.320 --> 00:09:40.740
Відкрите виробниче замовлення може її задовольнити, якщо фабрика завершить роботу вчасно.

00:09:40.860 --> 00:09:44.200
Коли жодне з цих джерел не покриває попит, план створює планове замовлення.

00:09:44.360 --> 00:09:47.460
Планове замовлення на закупівлю пропонує придбати щось у постачальника.

00:09:47.460 --> 00:09:50.980
Планове виробниче замовлення пропонує виготовити щось у межах вашого бізнесу.

00:09:50.980 --> 00:09:55.260
Планове замовлення на переміщення пропонує перевести запаси з одного місця чи складу на інший.

00:09:55.400 --> 00:09:57.300
Це пропозиції, а не зобов'язання.

00:09:57.500 --> 00:10:03.100
Dynamics 365 не надсилає замовлення постачальнику самостійно і не розпочинає роботу на заводі.

00:10:03.260 --> 00:10:07.400
Вона надає плановальнику запропоновану кількість і дату на основі даних, які вона бачить.

00:10:07.560 --> 00:10:12.660
Людина все одно перевіряє, чи правильний постачальник, чи реальна дата і чи варто бізнесу схвалювати цю дію.

00:10:12.820 --> 00:10:15.340
Уявіть невелику проблему з нашим замовленням на велосипеди.

00:10:15.500 --> 00:10:17.580
Здається, все готово, крім одного колеса.

00:10:17.580 --> 00:10:20.980
Планове постачання покриває рами, ланцюги, сидіння і майже всі колеса.

00:10:21.080 --> 00:10:24.040
Але одне колесо прибуває через день після того, як воно потрібне для збірки.

00:10:24.200 --> 00:10:26.680
Без цього колеса один велосипед не може бути завершений.

00:10:26.840 --> 00:10:31.080
Хоча склад може здаватися повним деталей, генеральне планування простежує розрив до його джерела.

00:10:31.320 --> 00:10:34.820
Планувальник бачить, що дефіцит не походить від самого замовлення клієнта.

00:10:35.000 --> 00:10:38.040
О, він походить від дати постачальника у замовленні на закупівлю коліс.

00:10:38.180 --> 00:10:40.420
Це дає плановальнику конкретну інформацію для дій.

00:10:40.420 --> 00:10:43.880
Запросити раніше доставку, знайти іншого постачальника або змінити дату виробництва.

00:10:44.000 --> 00:10:45.600
План може запропонувати постачання.

00:10:45.760 --> 00:10:47.640
Але наступне питання є не менш корисним.

00:10:47.820 --> 00:10:51.300
Чому Dynamics 365 поєднала саме це постачання з цим попитом?

00:10:51.440 --> 00:10:53.800
Читання чистих потреб – це планувальний діалог.

00:10:54.000 --> 00:10:57.760
Тому планувальники використовують сторінку чистих потреб, щоб дослідити цей зв'язок.

00:10:57.880 --> 00:11:01.540
Ця сторінка збирає повний планувальний діалог для одного елемента в одному місці.

00:11:01.760 --> 00:11:04.380
Вона показує кожну потребу в товарі та кожне джерело постачання,

00:11:04.540 --> 00:11:06.980
що може її покрити з датами поруч із кожним рядком.

00:11:06.980 --> 00:11:09.140
Візьмемо як приклад велосипедне колесо.

00:11:09.280 --> 00:11:12.800
У верхній частині ви обираєте майданчик або склад, де це колесо необхідне.

00:11:12.940 --> 00:11:19.180
Нижче Dynamics 365 відображає всі пов'язані транзакції, продажі, закупівлі, запаси та виробництво – все в одному списку.

00:11:19.320 --> 00:11:22.540
Попит відображається як від'ємне число відносно ваших доступних запасів.

00:11:22.700 --> 00:11:24.600
Цей попит може виникати з багатьох джерел.

00:11:24.760 --> 00:11:27.820
Замовлення на продаж потребує коліс, оскільки клієнт замовив велосипеди.

00:11:27.960 --> 00:11:30.180
Прогноз створює очікуваний попит у майбутньому.

00:11:30.180 --> 00:11:32.880
Виробниче замовлення потребує коліс згідно з планом заводу.

00:11:33.000 --> 00:11:35.880
А замовлення на переміщення створює попит, коли інший склад запитує запаси.

00:11:36.000 --> 00:11:37.780
Кожен рядок відповідає на просте запитання.

00:11:37.920 --> 00:11:39.000
Кому потрібен цей товар?

00:11:39.180 --> 00:11:40.280
Скільки саме їм потрібно?

00:11:40.400 --> 00:11:41.140
І на яку дату?

00:11:41.320 --> 00:11:43.860
Це звучить просто, але допомагає уникнути поширеної помилки.

00:11:44.020 --> 00:11:48.080
Люди часто бачать загальну кількість і припускають, що вона належить одному клієнту або завданню,

00:11:48.080 --> 00:11:51.380
хоча один і той самий товар може забезпечувати кілька замовлень на різні дати.

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

00:11:55.380 --> 00:11:59.540
Далі йдуть замовлення на закупівлю від постачальників, виробничі замовлення, які планує бізнес,

00:11:59.680 --> 00:12:03.920
переміщення між складами та планові замовлення, які пропонує система, але ще не були створені.

00:12:04.100 --> 00:12:05.760
Сторінка сортує все за датою.

00:12:06.000 --> 00:12:09.440
Прокручуючи список, ви можете спостерігати, як змінюється доступна кількість.

00:12:09.440 --> 00:12:13.440
Запасів може бути достатньо на початку місяця, потім вони зменшуються через виробничі потреби,

00:12:13.500 --> 00:12:16.160
а згодом знову зростають, коли надходить поставка від постачальника.

00:12:16.160 --> 00:12:21.920
Час змінює результат. Припустімо, у понеділок на складі є 100 коліс, але у вівторок для виробничого замовлення

00:12:21.920 --> 00:12:25.160
потрібно 80, а всереду з'являється потреба клієнта на 30.

00:12:25.440 --> 00:12:30.300
Загальний попит перевищує запаси, навіть якщо у п'ятницю надійде замовлення на 50 коліс.

00:12:30.440 --> 00:12:32.760
П'ятнична поставка не вирішує дефіцит середи.

00:12:32.760 --> 00:12:36.060
Це відображення по датах пояснює, чому система надає саме такі пропозиції.

00:12:36.240 --> 00:12:39.320
Dynamics 365 не просто випадково запитує більше коліс.

00:12:39.460 --> 00:12:43.160
Вона точно бачить, коли доступне постачання падає нижче рівня попиту, який необхідно покрити.

00:12:43.160 --> 00:12:47.480
Тепер ви можете поставити більш конкретне запитання. Який рядок постачання покриває який рядок попиту?

00:12:47.660 --> 00:12:49.420
Цей зв'язок називається прив'язкою Pagin.

00:12:49.540 --> 00:12:52.980
Прив'язка – це внутрішній механізм планування Dynamics 365 між попитом і пропозицією.

00:12:53.180 --> 00:12:56.660
Вона з'єднує потребу як от виробниче замовлення на велосипеди з джерелом, що має її покрити,

00:12:56.660 --> 00:12:59.520
наприклад, замовленням на купівлю коліс або плановим замовленням на закупівлю.

00:12:59.660 --> 00:13:02.420
Система будує цей зв'язок під час розрахунку планування.

00:13:02.600 --> 00:13:05.700
Якщо попит змінюється, планування може перерахувати зв'язок.

00:13:05.700 --> 00:13:09.940
Можливо, клієнт переносить дату доставки або постачання за замовленням на закупівлю затримується.

00:13:10.100 --> 00:13:14.880
Тоді прив'язка може вказати на інше джерело постачання або створити нове планове замовлення там, де виник дефіцит.

00:13:15.060 --> 00:13:16.900
Це допомагає відстежити весь ланцюг.

00:13:16.900 --> 00:13:19.800
Почніть із замовлення на продаж, перегляньте пов'язане з ним виробниче замовлення,

00:13:19.880 --> 00:13:22.720
простежте його до необхідних деталей і знайдіть відповідне замовлення на закупівлю.

00:13:22.840 --> 00:13:24.400
Іноді вам потрібно більше контролю.

00:13:24.580 --> 00:13:26.180
Саме тут у гру вступає маркування.

00:13:26.180 --> 00:13:29.740
Маркування – це ручний зв'язок між операцією постачання та операцією попиту.

00:13:29.960 --> 00:13:32.500
Воно вказує системі, що це постачання має покривати саме цей попит,

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

00:13:35.360 --> 00:13:38.360
Уявіть це як наклеювання етикетки на два пов'язані записи.

00:13:38.360 --> 00:13:42.820
Ви можете позначити конкретне вхідне замовлення на закупівлю коліс для певного виробничого замовлення,

00:13:42.900 --> 00:13:45.400
оскільки ці колеса були придбані саме для цієї роботи.

00:13:45.520 --> 00:13:48.820
Планування враховує цей зв'язок надійніше, ніж звичайне прив'язування.

00:13:48.820 --> 00:13:51.960
Проте маркуване постачання – це не найміцніший доступний зв'язок.

00:13:52.180 --> 00:13:53.560
Резервування є міцнішим.

00:13:53.700 --> 00:13:56.680
Коли ви резервуєте запаси або вхідне постачання під конкретний попит,

00:13:56.780 --> 00:13:58.020
ви створюєте жорсткий зв'язок.

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

00:14:02.360 --> 00:14:06.720
І головне планування розглядає резервування як пріоритет над звичайним прив'язуванням і маркуванням.

00:14:06.840 --> 00:14:11.140
Уявіть, що на складі є 10 коліс, але вони зарезервовані під термінове ремонтне замовлення.

00:14:11.140 --> 00:14:14.340
Пізніше може надійти замовлення від іншого клієнта, якому теж потрібні колеса,

00:14:14.420 --> 00:14:17.320
але планування не може вважати ці 10 зарезервуваних коліс вільнодоступними.

00:14:17.440 --> 00:14:21.520
Воно має знайти інше постачання або запропонувати нове, оскільки резервування вже закріпило їх за іншою метою.

00:14:21.520 --> 00:14:24.580
Отже, прив'язування, маркування та резервування дають вам три рівні зв'язку.

00:14:24.720 --> 00:14:26.840
Прив'язування – це автоматичне зіставлення системою.

00:14:26.980 --> 00:14:28.960
Маркування – це ручний, більш фіксований зв'язок.

00:14:29.100 --> 00:14:31.380
Резервування закріплює постачання за конкретною потребою.

00:14:31.380 --> 00:14:32.960
Воно є найсильнішим із трьох.

00:14:33.100 --> 00:14:37.480
Коли ви навчитися бачити ці зв'язки, заплановані замовлення перестануть здаватися незрозумілими інструкціями.

00:14:37.660 --> 00:14:42.940
Наступне питання – як часто змінюється це бачення планування і як швидко Dynamics 365 може його розрахувати?

00:14:43.140 --> 00:14:45.620
Статичне, динамічне та оптимізація планування.

00:14:45.800 --> 00:14:49.660
Сторінка чистих потреб показує результат планування, але не кожен план оновлюється однаково.

00:14:49.840 --> 00:14:53.300
Статичний план змінюється лише тоді, коли хтось запускає завдання головного планування.

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

00:14:58.860 --> 00:15:01.980
Уявіть, що велике замовлення на продаж надходить об 11-й годині ранку.

00:15:02.160 --> 00:15:07.040
Якщо статичний план був запущений вночі, це нове замовлення не з'явиться в пропозиціях до наступного запуску планування.

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

00:15:12.620 --> 00:15:14.280
Але ця стабільність має свою ціну.

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

00:15:19.980 --> 00:15:24.780
Планувальник може знати про існування клієнтського замовлення, але статичний план ще не перерахував відповідне постачання.

00:15:25.000 --> 00:15:26.640
Саме тут допомагає динамічний план.

00:15:26.820 --> 00:15:29.340
Динамічний план відображає поточний попит у реальному часі.

00:15:29.480 --> 00:15:33.880
Планувальники можуть бачити вплив нових замовлень на продаж та іншого попиту, не чекаючи на наступний повний запуск головного планування.

00:15:33.880 --> 00:15:35.840
Це погляд на короткострокову перспективу.

00:15:35.840 --> 00:15:39.380
Динамічні плани ігнорують прогнози та зосереджуються на тому, що відбувається зараз.

00:15:39.480 --> 00:15:43.320
Припустімо, клієнт робить несподіване замовлення на 200 велосипедів сьогодні в день.

00:15:43.460 --> 00:15:48.000
Перш ніж обіцяти дату доставки, планувальник може відкрити динамічний план і перевірити наслідки.

00:15:48.160 --> 00:15:50.060
Чи створює нове замовлення-дефіцит?

00:15:50.140 --> 00:15:52.480
Чи переносить воно існуючу потребу на пізнішу дату?

00:15:52.660 --> 00:15:55.580
Чи викликає воно нову пропозицію щодо закупівлі або виробництва?

00:15:55.580 --> 00:15:58.500
Це дає команді практичний огляд типу «що якщо».

00:15:58.500 --> 00:16:01.960
Ви не змінюєте статичний план лише заради аналізу одного нового замовлення.

00:16:02.100 --> 00:16:05.920
Ви спочатку перевіряєте ймовірний вплив, а потім вирішуєте, чи потребує замовлення уваги зараз,

00:16:06.000 --> 00:16:08.160
чи може почекати до наступного запланованого розрахунку.

00:16:08.360 --> 00:16:11.600
Статичні та динамічні плани відповідають на пов'язані, але різні питання.

00:16:11.800 --> 00:16:16.040
Статичний план запитує, що нам радив зробити наш останній офіційний розрахунок планування.

00:16:16.260 --> 00:16:19.780
Динамічний план запитує, як виглядає поточний попит прямо зараз.

00:16:19.780 --> 00:16:24.260
В основі обох планів лежить механізм планування для хмарних середовищ Dynamics 365.

00:16:24.260 --> 00:16:29.140
Оптимізація планування – це сучасний механізм, який Microsoft використовує для головного планування.

00:16:29.320 --> 00:16:31.660
Він обчислює потреби поза межами основного бізнес-додатку,

00:16:31.780 --> 00:16:35.180
що зменшує навантаження на систему, яку люди використовують для повсякденної роботи.

00:16:35.320 --> 00:16:37.460
Старі розрахунки планування могли тривати довго.

00:16:37.660 --> 00:16:40.900
Звіти від клієнтів і партнерів свідчать, що робота з планування, яка раніше займала години,

00:16:41.000 --> 00:16:43.160
тепер завершується за хвилини завдяки оптимізації планування.

00:16:43.160 --> 00:16:46.120
Швидші розрахунки означають, що команди можуть частіше оновлювати план,

00:16:46.120 --> 00:16:48.880
замість того, щоб чекати кінця дня, щоб побачити, чи змінився попит,

00:16:48.980 --> 00:16:50.940
але швидша відповідь все одно може бути неправильною.

00:16:51.220 --> 00:16:54.760
Оптимізація планування може швидко обробити величезну кількість пов'язаних даних.

00:16:54.860 --> 00:16:57.460
Однак вона працює лише з тими записами, які надає ваш бізнес.

00:16:57.640 --> 00:16:59.620
Якщо час виконання замовлення постачальником вказано неправильно,

00:16:59.720 --> 00:17:01.500
рекомендована дата замовлення також може бути помилковою.

00:17:01.640 --> 00:17:04.400
Якщо система вважає, що на складі є 500 коліс, хоча їх там немає,

00:17:04.400 --> 00:17:06.540
вона може пропустити необхідну пропозицію на закупівлю.

00:17:06.540 --> 00:17:08.780
І якщо у специфікації матеріалів пропущено деталь,

00:17:08.860 --> 00:17:11.360
планування не зможе створити потребу для цієї відсутньої деталі.

00:17:11.480 --> 00:17:14.320
Розрахунок може завершитися за хвилини, але виробництво зупиниться,

00:17:14.440 --> 00:17:15.780
коли цієї деталі не виявиться.

00:17:15.960 --> 00:17:18.120
Також є зміна в тому, як виконується планування.

00:17:18.300 --> 00:17:20.700
З оптимізацією планування плани є регенеративними.

00:17:20.820 --> 00:17:23.260
Це означає, що кожен розрахунок переглядає всі потреби заново,

00:17:23.260 --> 00:17:25.160
замість використання старішого підходу чистих змін,

00:17:25.240 --> 00:17:28.140
який оновлював лише елементи з новими потребами з часу останнього розрахунку.

00:17:28.140 --> 00:17:31.520
Сприймайте це як перерахунок повної картини планування кожного разу.

00:17:31.620 --> 00:17:33.380
Це усуває певну невизначеність щодо того,

00:17:33.500 --> 00:17:35.340
чи не вислизнула попередня зміна з розрахунку,

00:17:35.420 --> 00:17:37.240
а швидший механізм робить повний перерахунок

00:17:37.240 --> 00:17:38.840
більш практичним для багатьох компаній.

00:17:39.000 --> 00:17:41.640
Отже, швидкість допомагає, але саме чисті дані визначають,

00:17:41.760 --> 00:17:43.000
чи заслуговує план на довіру.

00:17:43.140 --> 00:17:44.660
Коли план видає свої пропозиції,

00:17:44.660 --> 00:17:47.780
наступне завдання – вирішити, що потребує дій у першу чергу.

00:17:47.920 --> 00:17:50.720
Але що робить головне планування, а чого воно не робить?

00:17:50.840 --> 00:17:52.400
Ось найпростіше визначення.

00:17:52.400 --> 00:17:55.380
Головне планування збирає всі дані в Dynamics 365

00:17:55.380 --> 00:17:58.380
і пропонує, що купити, виробити або перемістити

00:17:58.380 --> 00:17:59.980
з урахуванням дат і кількості.

00:18:00.120 --> 00:18:03.060
Планувальник переглядає ці планові замовлення перед виконанням.

00:18:03.240 --> 00:18:05.740
Він перевіряє постачальника, дату доставки, кількість і те,

00:18:05.860 --> 00:18:07.380
чи зможе завод впоратися з роботою.

00:18:07.380 --> 00:18:09.540
Після підтвердження фіксація пропозиції перетворює її

00:18:09.540 --> 00:18:11.540
на реальне замовлення на закупівлю, виробниче замовлення

00:18:11.540 --> 00:18:12.680
або замовлення на переміщення.

00:18:12.820 --> 00:18:14.960
Але головне планування не може бачити майбутнє.

00:18:14.960 --> 00:18:17.700
Прогнози – це лише оцінки, а реальні замовлення клієнтів

00:18:17.700 --> 00:18:18.760
можуть змінитися за ніч.

00:18:18.920 --> 00:18:21.000
І воно точно не замінює планувальників людей.

00:18:21.180 --> 00:18:23.120
Люди все ще контролюють ризики постачальників,

00:18:23.240 --> 00:18:25.020
обіцянки клієнтам та виняткові ситуації.

00:18:25.260 --> 00:18:26.980
Система просто не може оцінити ці речі.

00:18:27.180 --> 00:18:28.800
Самих запасів також недостатньо.

00:18:28.800 --> 00:18:31.320
Ці запаси можуть надійти запізно, лежати не на тому складі

00:18:31.320 --> 00:18:33.160
або бути зарезервованими під інше замовлення.

00:18:33.320 --> 00:18:35.800
Щоб отримати гарні результати, почніть із чистих даних,

00:18:35.860 --> 00:18:38.240
точних записів про товари, правильних термінів виконання,

00:18:38.240 --> 00:18:41.400
коректних специфікацій, актуальних залишків та реалістичного попиту.

00:18:41.600 --> 00:18:44.880
Для нашого замовлення велосипедів наявні запаси покривають частину потреби.

00:18:44.980 --> 00:18:48.180
Планування пропонує постачання для решти, а планувальник підтверджує дію.

00:18:48.320 --> 00:18:51.440
Це повертає нас до запитання, на яке має відповісти кожна команда.

00:18:51.440 --> 00:18:52.940
Що має статися далі?

00:18:53.380 --> 00:18:55.320
Висновок. Один пов'язаний план.

00:18:55.480 --> 00:18:59.320
Головне планування бере попит, рівні запасів, дати доставки постачальників,

00:18:59.440 --> 00:19:03.860
виробничі графіки та потужності, перетворюючи все це на дії для перегляду вашою командою.

00:19:03.860 --> 00:19:06.600
Планові замовлення лише започатковують прийняття рішень людьми.

00:19:06.760 --> 00:19:07.800
Вони не завершують його.

00:19:08.000 --> 00:19:09.860
Ось чому планувальники залишаються незамінними.

00:19:09.980 --> 00:19:11.540
Підписуйтесь на вашій улюбленій подкаст-платформі

00:19:11.540 --> 00:19:12.840
та поділіться цим корисним досвідом з тими,

00:19:12.940 --> 00:19:15.120
хто вивчає керування ланцюгами постачання в Dynamics 365.