WEBVTT

00:00:00.000 --> 00:00:12.460
Представьте, что клиент хочет получить 100 велосипедов в следующем месяце. Рамы прибудут с опозданием. Колеса лежат на другом складе, а ваша сборочная линия уже загружена работой на ближайшие две недели. Итак, что вы купите? Что вы будете собирать? Что вы будете перевозить? И когда вам понадобится каждая деталь?

00:00:12.460 --> 00:00:40.080
Ага, Мил Капитас из М365FM. Этот выпуск посвящен Dynamics 365 Master Planning EU, части управления цепочками поставок, которая решает эти вопросы за кулисами. Представьте свой бизнес как офисное здание с пристроенным складом. Заказы поступают через одну-две. Товары лежат на полках. Поставщики привозят товары на погрузочную площадку. Производство превращает детали в готовую продукцию. Главное планирование охватывает все здание, а не оставляет каждую команду со своим отдельным списком.

00:00:40.080 --> 00:01:07.960
Сегодня мы с Гертманом проследим за одним заказом велосипедов от запроса клиента до действий по обеспечению поставок. Dynamics 365 показывает, почему бизнесу нужен план, а не электронная таблица. До появления инструментов связного планирования компании работали с разрозненными данными. Отдел продаж хранил заказы клиентов в одном месте. Складские команды проверяли остатки в другой системе. Отдел закупок очлеживал даты поставок в письмах или таблицах. А производство вело свои записи о том, что фабрика может выпустить на этой неделе. Каждый список выглядел верным по отдельности.

00:01:07.960 --> 00:01:13.840
Проблемы начинались, когда кто-то пытался ответить на один вопрос клиента. О, сможем ли мы доставить 100 велосипедов к обещанной дате?

00:01:13.980 --> 00:01:21.580
Иола Тафтес. Представьте, что на складе сегодня есть 30 готовых велосипедов. Это хорошее начало, но по заказу все еще не хватает 70 велосипедов.

00:01:21.660 --> 00:01:29.000
А для этих 70 велосипедов нужны рамы, колеса, цепи, сиденья, болты, упаковочные материалы, люди для сборки и время на соответствующих станках.

00:01:29.000 --> 00:01:37.180
Простой подсчет запасов говорит лишь о том, что лежит на полке прямо сейчас. Он не скажет вам, прибудут ли еще 70 рам до того, как они понадобятся производству.

00:01:37.320 --> 00:01:45.620
Он не скажет, покрывает ли уже открытый заказ на закупку колеса. И он не скажет, достаточно ли у фабрики времени, чтобы собрать все воедино до даты доставки.

00:01:46.120 --> 00:01:49.960
Вот здесь планирование становится чем-то большим, чем просто подсчет.

00:01:49.960 --> 00:01:56.580
Когда клиент заказывает 100 велосипедов, система учитывает спрос на 100 штук. Она вычитает 30 уже имеющихся велосипедов.

00:01:56.700 --> 00:02:02.020
Затем она очлеживает, что нужно сделать для оставшихся 70. Она проверяет компоненты, необходимые для готового велосипеда.

00:02:02.140 --> 00:02:06.420
Она проверяет поставки, которые уже в пути. И она проверяет сроки, установленные для каждой задачи.

00:02:06.560 --> 00:02:11.020
Одна отсутствующая деталь может изменить весь ответ. У вас может быть достаточно колес и достаточно сидений.

00:02:11.160 --> 00:02:15.880
Но если для поставки рам от поставщика требуется две недели, их покупка за день до сборки никак не поможет.

00:02:15.880 --> 00:02:20.180
Заказ может выглядеть выполнимым в таблице, пока вы не разместите каждую деталь в календаре.

00:02:20.280 --> 00:02:24.480
И этот календарь постоянно меняется. Поставщик может перенести дату доставки на более ранний срок.

00:02:24.620 --> 00:02:27.140
Другой заказ на продажу может занять запас, который вы считали свободным.

00:02:27.300 --> 00:02:29.400
Производственное задание может быть завершено с опозданием.

00:02:29.580 --> 00:02:35.720
Когда эти данные разбросаны, сотрудники тратят все время на звонки, письма, проверки и обновления своей собственной версии плана.

00:02:35.920 --> 00:02:41.560
Dynamics 365. Главное планирование объединяет текущий спрос и текущее предложение в единое представление.

00:02:41.560 --> 00:02:46.180
Оно одновременно считывает заказы клиентов, складские запасы, входящие поставки и производственную информацию.

00:02:46.380 --> 00:02:49.780
Затем система определяет, где предложение покрывает спрос, а где сохраняется дефицит.

00:02:49.920 --> 00:02:55.640
Вместо того, чтобы заставлять каждую команду вручную сопоставлять данные, система создает предлагаемые действия на основе всей видимой информации.

00:02:55.800 --> 00:02:58.820
Это не означает, что система управляет бизнесом самостоятельно.

00:02:58.960 --> 00:03:03.340
Планировщик по-прежнему проверяет предложения, задает вопросы и решает, что нужно сделать.

00:03:03.500 --> 00:03:07.120
Но планировщик начинает с целостной картины, а не с набора отдельных списков.

00:03:07.240 --> 00:03:08.940
Представьте таблицу как фотографию.

00:03:08.940 --> 00:03:12.300
Она фиксирует запасы в конкретный момент, и это может быть полезно.

00:03:12.480 --> 00:03:18.660
Главное – планирование ближе к перспективному графику, так как оно связывает количество с датами, входящими поставками и будущим спросом.

00:03:18.840 --> 00:03:23.580
Следующий шаг – разделение различных видов спроса, которые может учитывать процесс планирования.

00:03:23.940 --> 00:03:25.260
Три режима планирования.

00:03:25.940 --> 00:03:28.340
Вот в чем особенность Dynamics 365.

00:03:29.540 --> 00:03:31.500
Существует не один способ планирования.

00:03:31.740 --> 00:03:35.980
Режим планирования, который вы используете, зависит от вопроса, на который вашему бизнесу нужен ответ.

00:03:35.980 --> 00:03:42.800
Компании, обрабатывающей текущие заказы клиентов, требуется совершенно иной взгляд, чем той, что готовит материалы к следующему сезону.

00:03:42.880 --> 00:03:44.720
Первый режим – главное планирование.

00:03:44.940 --> 00:03:47.980
Это ваш повседневный план, который рассчитывает чистые потребности.

00:03:48.160 --> 00:03:53.800
Это означает, что система оценивает, что вам нужно, и вычитает ресурсы, которые у вас уже есть или которые вы ожидаете получить.

00:03:53.980 --> 00:04:02.260
Она учитывает реальную деловую активность, заказы клиентов, отправленные поставщикам заказы на закупку, производственные заказы на цеху и запасы на складе.

00:04:02.260 --> 00:04:04.960
Представьте заказ клиента на 100 единиц продукта.

00:04:05.080 --> 00:04:08.720
На вашем складе есть 30 единиц, которые планирование может использовать для этого заказа.

00:04:08.840 --> 00:04:13.220
Система не будет предлагать покупать или производить все 100 единиц заново, так как она видит эти 30 как имеющийся запас.

00:04:13.360 --> 00:04:15.980
Таким образом, она рассчитывает оставшуюся потребность в 70 единиц.

00:04:16.100 --> 00:04:18.320
Эти оставшиеся 70 – и есть чистая потребность.

00:04:18.500 --> 00:04:21.320
Реальный план может включать больше, чем просто запас на полке.

00:04:21.520 --> 00:04:26.500
Возможно, еще 20 единиц должны поступить от поставщика до даты, запрошенной клиентом.

00:04:26.500 --> 00:04:31.640
В этом случае система учитывает и эти 20 единиц, сокращая объем необходимого пополнения.

00:04:31.820 --> 00:04:33.620
Но решающие значения не имеют сроки.

00:04:33.780 --> 00:04:38.020
Если эти 20 единиц прибудут после ожидаемой даты поставки, они не принесут особой пользы.

00:04:38.160 --> 00:04:41.260
Вы физически получите их, но слишком поздно для конкретной задачи.

00:04:41.420 --> 00:04:44.380
Главное планирование рассматривает количество и сроки в совокупности.

00:04:44.520 --> 00:04:47.740
Ведь простое число общего запаса может привести к неверному результату.

00:04:47.880 --> 00:04:50.580
Для многих компаний это план, который используется чаще всего.

00:04:50.760 --> 00:04:55.520
Microsoft называет главное планирование краткосрочным процессом, обычно охватывающим период от одной недели до шести месяцев.

00:04:55.520 --> 00:04:59.900
Точный диапазон зависит от того, сколько времени занимает поставка или производство продукции.

00:05:00.080 --> 00:05:04.200
Компания, закупающая простые местные товары, может планировать лишь на несколько недель вперед.

00:05:04.360 --> 00:05:10.520
Но производителю, чьи детали требуют месяцев ожидания, нужно смотреть дальше, часто на весь срок производственного цикла.

00:05:10.640 --> 00:05:15.020
В противном случае планирование обнаружат нехватку слишком поздно, когда избежать ее уже невозможно.

00:05:15.240 --> 00:05:17.320
Второй режим – это прогнозное планирование.

00:05:17.500 --> 00:05:22.140
В отличие от работы с подтвержденными заказами, прогнозное планирование опирается на ожидаемый спрос.

00:05:22.140 --> 00:05:28.680
Возможно, отдел продаж ожидает роста спроса на велосипеды летом, или ретейлер планирует крупную акцию в конце года.

00:05:28.840 --> 00:05:32.840
Это прогнозы, основанные на ожиданиях команды, а не на подтвержденных заказах.

00:05:32.960 --> 00:05:39.940
Они полезны, так как ожидание каждого клиентского заказа может оставить слишком мало времени на закупку сырья или подготовку мощностей.

00:05:40.100 --> 00:05:44.880
Для товаров с длительным циклом поставки решения нужны заранее, еще до поступления заказов от клиентов.

00:05:45.000 --> 00:05:47.580
Прогнозное планирование рассчитывает воловые потребности.

00:05:47.580 --> 00:05:50.980
Это значит, что расчет начинается с ожидаемого объема спроса.

00:05:51.120 --> 00:05:58.120
Если прогноз ожидает 500 велосипедов в июле, планирование сразу учитывает всю потребность в 500-й год единиц.

00:05:58.260 --> 00:06:01.140
Представьте это как взгляд на предстоящую нагрузку на бизнес.

00:06:01.380 --> 00:06:05.040
Вы можете планировать материалы и мощности, исходя из этого ожидаемого объема.

00:06:05.200 --> 00:06:10.620
Возможно, потребуется заранее договориться с поставщиками, подготовить склад или проверить производственные мощности.

00:06:10.780 --> 00:06:14.900
Прогнозы могут меняться, и фактические продажи могут отличаться от ожидаемых.

00:06:14.900 --> 00:06:19.380
И все же они дают более широкий обзор, чем план, основанный только на уже размещенных заказах.

00:06:19.540 --> 00:06:21.700
Далее идет межфирменное главное планирование.

00:06:21.920 --> 00:06:25.520
Оно применяется, когда одному юридическому лицу требуются поставки от другого.

00:06:25.640 --> 00:06:30.780
Например, одна компания в группе производит товар, а другая продает его клиентам в другой стране.

00:06:30.880 --> 00:06:33.100
Продающая компания видит клиентский спрос.

00:06:33.340 --> 00:06:37.280
Производственная компания должна видеть потребность в поставках, которую создает этот спрос.

00:06:37.500 --> 00:06:40.660
Межфирменное планирование связывает эти потребности между компаниями,

00:06:40.820 --> 00:06:44.320
включая планируемый спрос и поставки, еще не ставшие твердыми заказами.

00:06:44.320 --> 00:06:48.200
Таким образом, компании не планируют деятельность так, словно работают в одиночку.

00:06:48.300 --> 00:06:51.140
Торговая компания может планировать поставки от производственной,

00:06:51.340 --> 00:06:55.980
а производственная компания видит, что ей нужны материалы и мощности для обеспечения этого спроса.

00:06:56.080 --> 00:06:59.560
Эта связь передает сигнал планирования от одного юридического лица к другому.

00:06:59.720 --> 00:07:01.440
Каждый режим начинается со спроса.

00:07:01.560 --> 00:07:07.460
Но спрос – это лишь первый сигнал, поскольку один готовый продукт может создать цепочку потребностей во множестве комплектующих.

00:07:07.620 --> 00:07:11.060
От одного заказа к цепочке поставок давайте рассмотрим пример с велосипедом,

00:07:11.060 --> 00:07:14.080
так как именно здесь мастер планирования начинает свою основную работу.

00:07:14.240 --> 00:07:19.180
Представьте, что клиент размещает заказ на 70 велосипедов с доставкой к определенной дате.

00:07:19.380 --> 00:07:21.860
Эта дата – не просто пометка для отдела продаж.

00:07:22.020 --> 00:07:25.220
Это отправная точка, от которой планирование идет в обратном порядке,

00:07:25.400 --> 00:07:28.780
определяя, что должно произойти, прежде чем велосипеды покинут склад.

00:07:29.000 --> 00:07:31.120
Готовый велосипед – это только первый уровень.

00:07:31.300 --> 00:07:34.980
Dynamics 365 проверяет спецификацию материалов, которую часто называют BOM.

00:07:34.980 --> 00:07:37.640
Думайте о спецификации, как о рецепте одного велосипеда.

00:07:37.740 --> 00:07:43.400
В ней перечислены рама, колеса, цепь, сидение, руль, тормоза, болты и все остальные детали, необходимые для сборки.

00:07:43.520 --> 00:07:48.360
Если в заказе 70 велосипедов, планирование расширяет этот заказ до перечня деталей для всех 70 штук.

00:07:48.500 --> 00:07:50.740
Это очень быстро может превратиться в длинный список.

00:07:50.860 --> 00:07:55.460
Вам может потребоваться 70 рам, 140 колес, 70 цепей, 70 сидений и сотни мелких болтов.

00:07:55.620 --> 00:07:58.140
Планировщику не нужно пересчитывать каждую деталь вручную.

00:07:58.380 --> 00:08:01.240
Спецификация материалов предоставляет Dynamics 365 структуру,

00:08:01.240 --> 00:08:04.720
благодаря которой система может проследить спрос от готового велосипеда до каждого компонента.

00:08:04.860 --> 00:08:07.580
Но одних лишь деталей недостаточно для производства велосипедов.

00:08:07.700 --> 00:08:09.440
Для производства также необходим маршрут.

00:08:09.620 --> 00:08:16.760
Маршрут описывает этапы работы, необходимые для создания изделия, сборка рамы, установка колес, проверка тормозов и упаковка готового велосипеда.

00:08:16.900 --> 00:08:18.920
Для каждого этапа может потребоваться ресурс.

00:08:19.060 --> 00:08:24.780
Этим ресурсом может быть сборочная линия, верстак, покрасочная камера, станок или группа людей с соответствующими навыками.

00:08:24.940 --> 00:08:28.180
Планирование использует эту информацию для распределения работы в нужное время.

00:08:28.180 --> 00:08:32.660
Вместо того, чтобы считать производство мгновенным процессом, здесь даты начинают отчитываться назад.

00:08:32.860 --> 00:08:39.160
Если клиенту нужны велосипеды в пятницу, производственный заказ должен быть завершен в четверг, чтобы склад успел их упаковать и отправить.

00:08:39.300 --> 00:08:41.460
Сборка может потребоваться начать уже во вторник.

00:08:41.640 --> 00:08:43.680
Рамы и колеса должны прибыть к понедельнику.

00:08:43.880 --> 00:08:48.580
Если поставщику нужно 10 дней на доставку колес, то заказ на закупку должен уйти от вас еще раньше.

00:08:48.820 --> 00:08:50.920
Дата клиента создает целую цепочку дат.

00:08:51.080 --> 00:08:56.140
Dynamics 365 работает по этой цепочке в обратном порядке, учитывая сроки выполнения операций.

00:08:56.140 --> 00:09:04.100
Время выполнения – это просто срок, необходимый для чего-либо, будь то доставка детали поставщиком, перемещение товаров на складе или завершение работы на фабрике.

00:09:04.280 --> 00:09:06.320
Задержка детали может сдвинуть весь процесс.

00:09:06.540 --> 00:09:09.480
Предположим, система находит 70 рам в наличии.

00:09:09.660 --> 00:09:14.180
Она также видит открытый заказ на 140 колес с доставкой до начала сборки.

00:09:14.340 --> 00:09:18.300
Эти поставки покрывают потребность в колесах, а рамы уже покрывают свою часть.

00:09:18.300 --> 00:09:19.980
Затем система проверяет цепи.

00:09:20.120 --> 00:09:23.640
Возможно, в наличии есть только 40 цепей и нет заказа на поставку остальных 30.

00:09:23.820 --> 00:09:26.600
Планирование видит нехватку и предлагает способ ее покрытия.

00:09:26.740 --> 00:09:30.740
Такая же проверка проводится для готовых велосипедов, всех деталей для них и промежуточных работ.

00:09:30.880 --> 00:09:32.280
Некоторый запас уже существует.

00:09:32.460 --> 00:09:34.240
Имеющиеся запасы могут закрыть потребность.

00:09:34.400 --> 00:09:37.180
Открытый заказ на закупку может закрыть ее, если товар придет вовремя.

00:09:37.320 --> 00:09:40.640
Открытый производственный заказ может закрыть ее, если фабрика закончит работу вовремя.

00:09:40.740 --> 00:09:44.400
Когда ни один из этих источников не покрывает спрос, план создает запланированный заказ.

00:09:44.400 --> 00:09:47.560
Запланированный заказ на закупку предлагает приобрести что-то у поставщика.

00:09:47.720 --> 00:09:50.880
Запланированный производственный заказ предлагает изготовить что-то внутри компании.

00:09:51.100 --> 00:09:55.380
Запланированный заказ на перемещение предлагает перевести запасы с одного объекта или склада на другой.

00:09:55.540 --> 00:09:57.400
Это предложение, а не обязательство.

00:09:57.580 --> 00:10:03.080
Dynamics 365 не отправляет заказ поставщику и не начинает работу в цеху без вашего участия.

00:10:03.240 --> 00:10:07.520
Система предоставляет планировщику предлагаемое количество и дату на основе доступных данных.

00:10:07.720 --> 00:10:12.780
Специалист проверяет, подходит ли поставщик, реально ли дата и стоит ли компании одобрять это действие.

00:10:12.780 --> 00:10:15.460
Представьте небольшую проблему с нашим заказом велосипедов.

00:10:15.560 --> 00:10:17.500
Все выглядит готовым, кроме одного колеса.

00:10:17.640 --> 00:10:21.160
Запланированные поставки покрывают рамы, цепи, сидения и почти все колеса.

00:10:21.260 --> 00:10:24.100
Но одно колесо прибывает через день после того, как оно нужно для сборки.

00:10:24.260 --> 00:10:26.560
Без этого колеса один велосипед не может быть собран.

00:10:26.720 --> 00:10:31.280
Даже если склад полон деталей, мастер планирования очлеживает причину нехватки до самого источника.

00:10:31.460 --> 00:10:35.020
Планировщик видит, что нехватка возникла не из самого заказа клиента.

00:10:35.260 --> 00:10:37.860
Она вызвана датой поставки в заказе на закупку колес.

00:10:38.020 --> 00:10:40.380
Это дает планировщику конкретную задачу для решения.

00:10:40.380 --> 00:10:44.000
Запросить более раннюю доставку, найти другого поставщика или изменить дату производства.

00:10:44.100 --> 00:10:45.860
План может предложить варианты поставок.

00:10:45.920 --> 00:10:47.680
Но следующий вопрос не менее полезен.

00:10:47.760 --> 00:10:51.160
Почему Dynamics 365 связала это поступление с этим спросом?

00:10:51.280 --> 00:10:53.900
Чтение чистых потребностей – это диалог планирования.

00:10:54.040 --> 00:10:57.940
Поэтому планировщики используют страницу «Чистые потребности», чтобы разобраться в этих связях.

00:10:58.080 --> 00:11:01.500
Эта страница собирает всю историю планирования по одному товару в одном месте.

00:11:01.740 --> 00:11:04.400
Здесь отображается весь спрос на товар и все источники снабжения,

00:11:04.600 --> 00:11:07.020
которые могут его покрыть с датами напротив каждой строки.

00:11:07.200 --> 00:11:09.280
Возьмем, к примеру, велосипедное колесо.

00:11:09.280 --> 00:11:12.900
В верхней части вы выбираете площадку или склад, где требуется это колесо.

00:11:13.020 --> 00:11:19.140
Ниже Dynamics 365 показывает все связанные транзакции, продажи, закупки, складские запасы и производство – все в одном списке.

00:11:19.300 --> 00:11:22.580
Спрос отображается как отрицательное число по отношению к вашим доступным запасам.

00:11:22.720 --> 00:11:24.780
Этот спрос может возникать из разных источников.

00:11:24.960 --> 00:11:28.060
Заказ на продажу требует колеса, потому что клиент заказал велосипеды.

00:11:28.140 --> 00:11:30.140
Прогноз создает ожидаемый будущий спрос.

00:11:30.340 --> 00:11:32.940
Производственный заказ требует колеса согласно плану завода.

00:11:33.040 --> 00:11:36.100
А заказ на перемещение создает спрос, когда другой склад запрашивает товары.

00:11:36.100 --> 00:11:38.000
Каждая строка отвечает на простой вопрос.

00:11:38.000 --> 00:11:40.960
Кому нужен этот товар? Сколько им нужно? И к какой дате?

00:11:41.120 --> 00:11:43.840
Это звучит просто, но помогает избежать распространенной ошибки.

00:11:44.000 --> 00:11:48.160
Люди часто видят общее количество и полагают, что оно относится к одному клиенту или заказу,

00:11:48.260 --> 00:11:51.260
хотя один и тот же товар может покрывать несколько заказов на разные даты.

00:11:51.440 --> 00:11:55.360
Со стороны снабжения у вас есть текущие складские запасы – то, что уже в наличии.

00:11:55.560 --> 00:11:58.320
Затем идут заказы на закупку у поставщиков, производственные заказы,

00:11:58.380 --> 00:12:01.660
которые компания планирует выполнить, перемещение между складами и плановые заказы,

00:12:01.740 --> 00:12:04.080
которые система предлагает, но которые еще никто не создал.

00:12:04.080 --> 00:12:07.780
Страница сортирует все по дате. Прокручивая список, вы можете наблюдать,

00:12:07.960 --> 00:12:11.840
как меняется доступное количество. В начале месяца запас может выглядеть достаточным,

00:12:11.940 --> 00:12:16.220
затем снижаться при расходе деталей на производство и снова расти при поступлении поставки от поставщика.

00:12:16.420 --> 00:12:20.180
Сроки меняют результат. Предположим, в понедельник на складе есть 100 колес,

00:12:20.340 --> 00:12:25.280
но во вторник производственный заказ требует 80, а в среду появляется потребность клиента еще на 30.

00:12:25.480 --> 00:12:30.240
Общий спрос превышает запас, даже если в пятницу поступит заказ на закупку 50 колес.

00:12:30.240 --> 00:12:34.300
Пятничная поставка не решит проблему нехватки в среду. Такое пошаговое представление по датам

00:12:34.300 --> 00:12:38.860
объясняет, почему система делает свои предложения. Dynamics 365 не просто случайно запрашивает

00:12:38.860 --> 00:12:42.940
больше колес. Она точно видит, когда доступное снабжение падает ниже спроса, который нужно

00:12:42.940 --> 00:12:46.760
покрыть. Теперь вы можете задать более конкретный вопрос. Какая строка снабжения покрывает

00:12:46.760 --> 00:12:50.740
какую строку спроса? Эта связь называется привязкой. Пикгин. Привязка – это механизм планирования

00:12:50.740 --> 00:12:54.360
Dynamics 365 для связывания спроса и снабжения. Она соединяет потребность, например,

00:12:54.480 --> 00:12:57.500
производственный заказ на велосипеды с источником, который должен ее покрыть, например,

00:12:57.500 --> 00:13:01.460
заказом на закупку колес или плановым заказом на закупку. Система создает эту связь во время

00:13:01.460 --> 00:13:06.220
расчета планирования. Если спрос меняется, планирование может пересчитать эту связь. Возможно,

00:13:06.440 --> 00:13:10.700
клиент перенес дату доставки или поставка по заказу на закупку задерживается. Тогда привязка

00:13:10.700 --> 00:13:14.560
может указать на другой источник снабжения или создать новый плановый заказ там, где возник

00:13:14.560 --> 00:13:18.860
дефицит. Это помогает отследить всю цепочку целиком. Начните с заказа на продажу, найдите связанный

00:13:18.860 --> 00:13:22.540
с ним производственный заказ, перейдите к необходимым деталям и определите заказ на закупку, который их

00:13:22.540 --> 00:13:27.040
покрывает. Иногда требуется больше контроля. Здесь на помощь приходит маркировка. Маркировка – это

00:13:27.500 --> 00:13:31.680
связь между транзакцией поставки и транзакцией спроса. Она указывает системе, что данная поставка

00:13:31.680 --> 00:13:35.320
должна покрыть именно этот спрос, не позволяя алгоритму планирования свободно перенаправлять ее.

00:13:35.440 --> 00:13:39.940
Представьте, что вы вешаете ярлык на две связанные записи. Вы можете пометить конкретный заказ

00:13:39.940 --> 00:13:44.180
на закупку колес как предназначенный для определенного производственного заказа, поскольку эти колеса

00:13:44.180 --> 00:13:48.920
были приобретены именно для него. Планирование учитывает эту связь более строго, чем обычную привязку.

00:13:49.040 --> 00:13:54.400
Тем не менее, маркированная поставка – не самая прочная связь. Резервирование надежнее. Когда вы резервируете

00:13:54.400 --> 00:13:58.660
запас или ожидаемую поставку под конкретный спрос, вы создаете жесткую связь. Это количество

00:13:58.660 --> 00:14:02.280
откладывается для выбранного заказа на продажу, производственного заказа или другого спроса.

00:14:02.360 --> 00:14:06.200
И генеральное планирование считает резервирование приоритетным по сравнению с обычной привязкой

00:14:06.200 --> 00:14:11.060
и маркировкой. Представьте, на складе есть 10 колес, но они зарезервированы для срочного заказа на

00:14:11.060 --> 00:14:15.280
ремонт. Позднее может поступить другой заказ, требующий колес, но планирование не может считать

00:14:15.280 --> 00:14:19.320
эти 10 зарезервированных колес доступными. Системе нужно найти другие источники или предложить новые

00:14:19.320 --> 00:14:22.520
поставки, так как резервирование уже закрепило их за другим объектом. Итак, привязка,

00:14:22.520 --> 00:14:26.420
маркировка и резервирование дают три уровня связи. Привязка – это автоматическое сопоставление

00:14:26.420 --> 00:14:30.120
системой. Маркировка – это ручная, более фиксированная связь. Резервирование закрепляет

00:14:30.120 --> 00:14:34.080
поставку за конкретной потребностью. Оно – самое сильное из этих трех. Как только вы научитесь

00:14:34.080 --> 00:14:37.500
видеть эти связи, плановые заказы перестанут казаться неясными инструкциями.

00:14:37.660 --> 00:14:42.240
Следующий вопрос. Как часто меняется представление планирования и как быстро Dynamics 365 может

00:14:42.240 --> 00:14:45.820
его рассчитать? Статическое, динамическое планирование и оптимизация планирования.

00:14:46.020 --> 00:14:48.940
Страница чистых потребностей показывает результат планирования, но не каждый план

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

00:14:52.520 --> 00:14:56.240
генерального планирования. Это дает планировщикам стабильную картину, которую можно изучать в течение

00:14:56.240 --> 00:15:00.320
дня, не опасаясь, что каждая новая транзакция изменит показатели. Представьте, что крупный заказ на

00:15:00.320 --> 00:15:05.300
продажу поступает в 11 часов утра. Если статический план был запущен ночью, этот новый заказ не появится

00:15:05.300 --> 00:15:09.200
в его предложениях до следующего запуска. План все еще показывает последний рассчитанный результат,

00:15:09.440 --> 00:15:13.700
что удобно, когда команде нужно единое согласованное представление на день. Однако у этой стабильности

00:15:13.700 --> 00:15:18.020
есть своя цена. Новый спрос может некоторое время оставаться вне статического плана, особенно если ваш бизнес

00:15:18.020 --> 00:15:21.900
запускает планирование раз в день или раз в неделю. Планировщик может знать о существовании клиентского

00:15:21.900 --> 00:15:25.920
заказа, но статический план еще не пересчитал необходимый объем поставок. Именно здесь помогает

00:15:25.920 --> 00:15:29.400
динамический план. Динамический план показывает текущий спрос в режиме реального времени.

00:15:29.580 --> 00:15:32.960
Планировщики могут видеть влияние новых заказов на продажу и другого спроса, не дожидаясь полного

00:15:32.960 --> 00:15:36.760
цикла генерального планирования. Это взгляд на краткосрочную перспективу. Динамические планы не

00:15:36.760 --> 00:15:41.640
учитывают прогнозы и фокусируются на том, что происходит прямо сейчас. Допустим, сегодня днем клиент размещает

00:15:41.640 --> 00:15:46.840
заказ на 200 велосипедов. Прежде чем обещать дату доставки, планировщик может открыть динамический

00:15:46.840 --> 00:15:51.800
план и оценить последствия. Создает ли новый заказ дефицит? Сдвигает ли он существующую потребность

00:15:51.800 --> 00:15:55.940
на более поздний срок? Вызывает ли он необходимость в новой закупке или производстве? Это дает

00:15:55.940 --> 00:16:00.540
команде практический взгляд на ситуацию, что, если вы не меняете статический план только ради

00:16:00.540 --> 00:16:05.060
проверки одного нового заказа. Вы сначала проверяете вероятное влияние, а затем решаете, требует ли заказ

00:16:05.060 --> 00:16:09.080
внимания сейчас или может подождать следующего запланированного запуска планирования. Статические и

00:16:09.080 --> 00:16:13.260
динамические планы отвечают на связанные, но разные вопросы. Статический план спрашивает,

00:16:13.480 --> 00:16:17.660
что нам предписывал сделать последний официальный расчет? Динамический план спрашивает,

00:16:17.840 --> 00:16:22.520
как выглядит текущий спрос прямо сейчас? В основе обоих планов лежит механизм планирования для

00:16:22.520 --> 00:16:27.760
облачных сред Dynamics 365. Оптимизация планирования – это современный механизм, который Microsoft

00:16:27.760 --> 00:16:31.880
использует для генерального планирования. Он рассчитывает потребности вне основного бизнес-приложения,

00:16:32.180 --> 00:16:36.600
что снижает нагрузку на систему, используемую для ежедневной работы. Старые циклы планирования могли

00:16:36.600 --> 00:16:40.620
занимать много времени. Отчеты клиентов и партнеров показывают, что задачи, занимавшие когда-то

00:16:40.620 --> 00:16:44.320
часы, теперь выполняются за минуты с помощью оптимизации планирования. Более быстрые расчеты

00:16:44.320 --> 00:16:48.640
означают, что команды могут обновлять план чаще, не дожидаясь конца дня, чтобы увидеть изменение

00:16:48.640 --> 00:16:52.560
спроса, но быстрый ответ все еще может быть неверным. Оптимизация планирования может быстро

00:16:52.560 --> 00:16:56.280
обрабатывать огромные объемы взаимосвязанных данных. Тем не менее, она работает только на основе

00:16:56.280 --> 00:16:59.780
данных, предоставляемых вашим бизнесом. Если время выполнения заказа у поставщика указано неверно,

00:16:59.900 --> 00:17:03.520
предложенная дата заказа тоже может быть ошибочной. Если система думает, что на складе есть 500 колес,

00:17:03.520 --> 00:17:06.580
а их там нет, она может пропустить предложение о закупке, которое вам действительно необходимо.

00:17:06.740 --> 00:17:10.340
А если в спецификации материалов отсутствует какая-либо деталь, планирование не сможет создать

00:17:10.340 --> 00:17:13.960
потребность для этой детали. Расчет может завершиться за минуты, но работа фабрики все равно

00:17:13.960 --> 00:17:18.140
остановится, если этой детали нет в наличии. Также изменился сам процесс запуска планирования.

00:17:18.280 --> 00:17:22.260
При оптимизации планирования планы являются регенеративными. Это означает, что каждый прогон

00:17:22.260 --> 00:17:26.060
пересматривает все потребности заново, вместо использования старого подхода, чистого изменения,

00:17:26.180 --> 00:17:29.920
который обновлял только позиции с новыми требованиями. Думайте об этом как о пересчете всей

00:17:29.920 --> 00:17:33.420
картины планирования каждый раз. Это устраняет неопределенность относительно того,

00:17:33.600 --> 00:17:37.180
не было ли упущено какое-либо раннее изменение, в то время как быстрый движок делает полный

00:17:37.180 --> 00:17:41.240
пересчет более практичным для многих компаний. Скорость помогает, но именно частота данных

00:17:41.240 --> 00:17:46.080
определяет, можно ли доверять плану. Когда план выдает свои предложения, следующая задача — решить,

00:17:46.260 --> 00:17:50.560
что требует действий в первую очередь. Но что делает главное планирование, а чего оно не делает?

00:17:50.740 --> 00:17:56.620
Итак, вот самое простое определение. Главное планирование берет все данные из Dynamics 365 и предлагает,

00:17:56.620 --> 00:18:01.060
что купить, произвести или переместить, с указанием дат и количества. Планировщик проверяет

00:18:01.060 --> 00:18:05.160
эти плановые заказы перед тем, как действовать. Он проверяет поставщика, дату доставки,

00:18:05.320 --> 00:18:08.780
количество и то, может ли завод справиться с работой. После подтверждения фиксации этого

00:18:08.780 --> 00:18:12.280
предложения превращает его в реальный заказ на закупку, производственный заказ или заказ на

00:18:12.280 --> 00:18:16.300
перемещение. Но главное планирование не может видеть будущее. Прогнозы — это лишь оценки,

00:18:16.500 --> 00:18:20.300
а реальные заказы клиентов могут измениться за одну ночь. И оно определенно не заменяет

00:18:20.300 --> 00:18:25.300
планировщиков людей. Люди по-прежнему управляют рисками поставщиков, обещаниями клиентам и исключениями.

00:18:25.300 --> 00:18:29.700
Система просто не может судить. Одних запасов тоже недостаточно. Эти запасы могут прибыть

00:18:29.700 --> 00:18:33.220
слишком поздно, находиться не на том складе или быть уже зарезервированными под другой заказ.

00:18:33.360 --> 00:18:37.140
Чтобы получить хорошие результаты, начните с чистых данных, корректных записей об изделиях,

00:18:37.320 --> 00:18:41.500
точных сроков выполнения, правильных спецификаций, актуальных запасов и реалистичного спроса.

00:18:41.620 --> 00:18:45.440
Для нашего заказа на велосипеды имеющиеся запасы покрывают часть потребности. Планирование

00:18:45.440 --> 00:18:49.760
предлагает поставку остального, а планировщик подтверждает действие. Это возвращает нас к вопросу,

00:18:49.800 --> 00:18:53.000
на который должна ответить каждая команда. Что должно произойти дальше?

00:18:53.000 --> 00:18:58.060
Вывод. Единый связный план. Главное планирование берет спрос, уровень запасов,

00:18:58.200 --> 00:19:02.760
даты доставки поставщиков, графики производства и мощности, превращая все это в действие для

00:19:02.760 --> 00:19:07.220
проверки вашей командой. Плановые заказы лишь начинают процесс принятия решений человеком. Они его

00:19:07.220 --> 00:19:11.060
не завершают. Вот почему планировщики остаются незаменимыми. Подписывайтесь на любимой платформе

00:19:11.060 --> 00:19:14.120
для подкастов и поделитесь этой полезной информацией с тем, кто изучает управление цепочками

00:19:14.120 --> 00:19:15.240
поставок в Dynamics 365.