Представьте, что клиент хочет получить 100 велосипедов в следующем месяце. Рамы прибудут с опозданием. Колеса лежат на другом складе, а ваша сборочная линия уже загружена работой на ближайшие две недели. Итак, что вы купите? Что вы будете собирать? Что вы будете перевозить? И когда вам понадобится каждая деталь? Ага, Мил Капитас из М365FM. Этот выпуск посвящен Dynamics 365 Master Planning EU, части управления цепочками поставок, которая решает эти вопросы за кулисами. Представьте свой бизнес как офисное здание с пристроенным складом. Заказы поступают через одну-две. Товары лежат на полках. Поставщики привозят товары на погрузочную площадку. Производство превращает детали в готовую продукцию. Главное планирование охватывает все здание, а не оставляет каждую команду со своим отдельным списком. Сегодня мы с Гертманом проследим за одним заказом велосипедов от запроса клиента до действий по обеспечению поставок. Dynamics 365 показывает, почему бизнесу нужен план, а не электронная таблица. До появления инструментов связного планирования компании работали с разрозненными данными. Отдел продаж хранил заказы клиентов в одном месте. Складские команды проверяли остатки в другой системе. Отдел закупок очлеживал даты поставок в письмах или таблицах. А производство вело свои записи о том, что фабрика может выпустить на этой неделе. Каждый список выглядел верным по отдельности.

Проблемы начинались, когда кто-то пытался ответить на один вопрос клиента. О, сможем ли мы доставить 100 велосипедов к обещанной дате? Иола Тафтес. Представьте, что на складе сегодня есть 30 готовых велосипедов. Это хорошее начало, но по заказу все еще не хватает 70 велосипедов. А для этих 70 велосипедов нужны рамы, колеса, цепи, сиденья, болты, упаковочные материалы, люди для сборки и время на соответствующих станках. Простой подсчет запасов говорит лишь о том, что лежит на полке прямо сейчас. Он не скажет вам, прибудут ли еще 70 рам до того, как они понадобятся производству. Он не скажет, покрывает ли уже открытый заказ на закупку колеса. И он не скажет, достаточно ли у фабрики времени, чтобы собрать все воедино до даты доставки. Вот здесь планирование становится чем-то большим, чем просто подсчет. Когда клиент заказывает 100 велосипедов, система учитывает спрос на 100 штук. Она вычитает 30 уже имеющихся велосипедов.

Затем она очлеживает, что нужно сделать для оставшихся 70. Она проверяет компоненты, необходимые для готового велосипеда. Она проверяет поставки, которые уже в пути. И она проверяет сроки, установленные для каждой задачи. Одна отсутствующая деталь может изменить весь ответ. У вас может быть достаточно колес и достаточно сидений. Но если для поставки рам от поставщика требуется две недели, их покупка за день до сборки никак не поможет. Заказ может выглядеть выполнимым в таблице, пока вы не разместите каждую деталь в календаре. И этот календарь постоянно меняется. Поставщик может перенести дату доставки на более ранний срок. Другой заказ на продажу может занять запас, который вы считали свободным. Производственное задание может быть завершено с опозданием. Когда эти данные разбросаны, сотрудники тратят все время на звонки, письма, проверки и обновления своей собственной версии плана. Dynamics 365. Главное планирование объединяет текущий спрос и текущее предложение в единое представление.

Оно одновременно считывает заказы клиентов, складские запасы, входящие поставки и производственную информацию. Затем система определяет, где предложение покрывает спрос, а где сохраняется дефицит. Вместо того, чтобы заставлять каждую команду вручную сопоставлять данные, система создает предлагаемые действия на основе всей видимой информации. Это не означает, что система управляет бизнесом самостоятельно. Планировщик по-прежнему проверяет предложения, задает вопросы и решает, что нужно сделать. Но планировщик начинает с целостной картины, а не с набора отдельных списков. Представьте таблицу как фотографию. Она фиксирует запасы в конкретный момент, и это может быть полезно. Главное – планирование ближе к перспективному графику, так как оно связывает количество с датами, входящими поставками и будущим спросом. Следующий шаг – разделение различных видов спроса, которые может учитывать процесс планирования.

Три режима планирования. Вот в чем особенность Dynamics 365. Существует не один способ планирования. Режим планирования, который вы используете, зависит от вопроса, на который вашему бизнесу нужен ответ. Компании, обрабатывающей текущие заказы клиентов, требуется совершенно иной взгляд, чем той, что готовит материалы к следующему сезону. Первый режим – главное планирование. Это ваш повседневный план, который рассчитывает чистые потребности. Это означает, что система оценивает, что вам нужно, и вычитает ресурсы, которые у вас уже есть или которые вы ожидаете получить. Она учитывает реальную деловую активность, заказы клиентов, отправленные поставщикам заказы на закупку, производственные заказы на цеху и запасы на складе. Представьте заказ клиента на 100 единиц продукта. На вашем складе есть 30 единиц, которые планирование может использовать для этого заказа. Система не будет предлагать покупать или производить все 100 единиц заново, так как она видит эти 30 как имеющийся запас.

Таким образом, она рассчитывает оставшуюся потребность в 70 единиц. Эти оставшиеся 70 – и есть чистая потребность. Реальный план может включать больше, чем просто запас на полке. Возможно, еще 20 единиц должны поступить от поставщика до даты, запрошенной клиентом. В этом случае система учитывает и эти 20 единиц, сокращая объем необходимого пополнения. Но решающие значения не имеют сроки. Если эти 20 единиц прибудут после ожидаемой даты поставки, они не принесут особой пользы. Вы физически получите их, но слишком поздно для конкретной задачи. Главное планирование рассматривает количество и сроки в совокупности. Ведь простое число общего запаса может привести к неверному результату. Для многих компаний это план, который используется чаще всего. Microsoft называет главное планирование краткосрочным процессом, обычно охватывающим период от одной недели до шести месяцев. Точный диапазон зависит от того, сколько времени занимает поставка или производство продукции.

Компания, закупающая простые местные товары, может планировать лишь на несколько недель вперед. Но производителю, чьи детали требуют месяцев ожидания, нужно смотреть дальше, часто на весь срок производственного цикла. В противном случае планирование обнаружат нехватку слишком поздно, когда избежать ее уже невозможно. Второй режим – это прогнозное планирование. В отличие от работы с подтвержденными заказами, прогнозное планирование опирается на ожидаемый спрос. Возможно, отдел продаж ожидает роста спроса на велосипеды летом, или ретейлер планирует крупную акцию в конце года. Это прогнозы, основанные на ожиданиях команды, а не на подтвержденных заказах. Они полезны, так как ожидание каждого клиентского заказа может оставить слишком мало времени на закупку сырья или подготовку мощностей. Для товаров с длительным циклом поставки решения нужны заранее, еще до поступления заказов от клиентов. Прогнозное планирование рассчитывает воловые потребности.

Это значит, что расчет начинается с ожидаемого объема спроса. Если прогноз ожидает 500 велосипедов в июле, планирование сразу учитывает всю потребность в 500-й год единиц. Представьте это как взгляд на предстоящую нагрузку на бизнес. Вы можете планировать материалы и мощности, исходя из этого ожидаемого объема. Возможно, потребуется заранее договориться с поставщиками, подготовить склад или проверить производственные мощности. Прогнозы могут меняться, и фактические продажи могут отличаться от ожидаемых. И все же они дают более широкий обзор, чем план, основанный только на уже размещенных заказах. Далее идет межфирменное главное планирование. Оно применяется, когда одному юридическому лицу требуются поставки от другого. Например, одна компания в группе производит товар, а другая продает его клиентам в другой стране. Продающая компания видит клиентский спрос. Производственная компания должна видеть потребность в поставках, которую создает этот спрос.

Межфирменное планирование связывает эти потребности между компаниями, включая планируемый спрос и поставки, еще не ставшие твердыми заказами. Таким образом, компании не планируют деятельность так, словно работают в одиночку. Торговая компания может планировать поставки от производственной, а производственная компания видит, что ей нужны материалы и мощности для обеспечения этого спроса. Эта связь передает сигнал планирования от одного юридического лица к другому. Каждый режим начинается со спроса. Но спрос – это лишь первый сигнал, поскольку один готовый продукт может создать цепочку потребностей во множестве комплектующих. От одного заказа к цепочке поставок давайте рассмотрим пример с велосипедом, так как именно здесь мастер планирования начинает свою основную работу. Представьте, что клиент размещает заказ на 70 велосипедов с доставкой к определенной дате. Эта дата – не просто пометка для отдела продаж.

Это отправная точка, от которой планирование идет в обратном порядке, определяя, что должно произойти, прежде чем велосипеды покинут склад. Готовый велосипед – это только первый уровень. Dynamics 365 проверяет спецификацию материалов, которую часто называют BOM. Думайте о спецификации, как о рецепте одного велосипеда. В ней перечислены рама, колеса, цепь, сидение, руль, тормоза, болты и все остальные детали, необходимые для сборки. Если в заказе 70 велосипедов, планирование расширяет этот заказ до перечня деталей для всех 70 штук. Это очень быстро может превратиться в длинный список. Вам может потребоваться 70 рам, 140 колес, 70 цепей, 70 сидений и сотни мелких болтов. Планировщику не нужно пересчитывать каждую деталь вручную. Спецификация материалов предоставляет Dynamics 365 структуру, благодаря которой система может проследить спрос от готового велосипеда до каждого компонента. Но одних лишь деталей недостаточно для производства велосипедов.

Для производства также необходим маршрут. Маршрут описывает этапы работы, необходимые для создания изделия, сборка рамы, установка колес, проверка тормозов и упаковка готового велосипеда. Для каждого этапа может потребоваться ресурс. Этим ресурсом может быть сборочная линия, верстак, покрасочная камера, станок или группа людей с соответствующими навыками. Планирование использует эту информацию для распределения работы в нужное время. Вместо того, чтобы считать производство мгновенным процессом, здесь даты начинают отчитываться назад. Если клиенту нужны велосипеды в пятницу, производственный заказ должен быть завершен в четверг, чтобы склад успел их упаковать и отправить. Сборка может потребоваться начать уже во вторник. Рамы и колеса должны прибыть к понедельнику. Если поставщику нужно 10 дней на доставку колес, то заказ на закупку должен уйти от вас еще раньше. Дата клиента создает целую цепочку дат.

Dynamics 365 работает по этой цепочке в обратном порядке, учитывая сроки выполнения операций. Время выполнения – это просто срок, необходимый для чего-либо, будь то доставка детали поставщиком, перемещение товаров на складе или завершение работы на фабрике. Задержка детали может сдвинуть весь процесс. Предположим, система находит 70 рам в наличии. Она также видит открытый заказ на 140 колес с доставкой до начала сборки. Эти поставки покрывают потребность в колесах, а рамы уже покрывают свою часть. Затем система проверяет цепи. Возможно, в наличии есть только 40 цепей и нет заказа на поставку остальных 30. Планирование видит нехватку и предлагает способ ее покрытия. Такая же проверка проводится для готовых велосипедов, всех деталей для них и промежуточных работ. Некоторый запас уже существует. Имеющиеся запасы могут закрыть потребность. Открытый заказ на закупку может закрыть ее, если товар придет вовремя.

Открытый производственный заказ может закрыть ее, если фабрика закончит работу вовремя. Когда ни один из этих источников не покрывает спрос, план создает запланированный заказ. Запланированный заказ на закупку предлагает приобрести что-то у поставщика. Запланированный производственный заказ предлагает изготовить что-то внутри компании. Запланированный заказ на перемещение предлагает перевести запасы с одного объекта или склада на другой. Это предложение, а не обязательство. Dynamics 365 не отправляет заказ поставщику и не начинает работу в цеху без вашего участия. Система предоставляет планировщику предлагаемое количество и дату на основе доступных данных. Специалист проверяет, подходит ли поставщик, реально ли дата и стоит ли компании одобрять это действие. Представьте небольшую проблему с нашим заказом велосипедов. Все выглядит готовым, кроме одного колеса. Запланированные поставки покрывают рамы, цепи, сидения и почти все колеса.

Но одно колесо прибывает через день после того, как оно нужно для сборки. Без этого колеса один велосипед не может быть собран. Даже если склад полон деталей, мастер планирования очлеживает причину нехватки до самого источника. Планировщик видит, что нехватка возникла не из самого заказа клиента. Она вызвана датой поставки в заказе на закупку колес. Это дает планировщику конкретную задачу для решения. Запросить более раннюю доставку, найти другого поставщика или изменить дату производства. План может предложить варианты поставок. Но следующий вопрос не менее полезен. Почему Dynamics 365 связала это поступление с этим спросом? Чтение чистых потребностей – это диалог планирования. Поэтому планировщики используют страницу «Чистые потребности», чтобы разобраться в этих связях. Эта страница собирает всю историю планирования по одному товару в одном месте. Здесь отображается весь спрос на товар и все источники снабжения, которые могут его покрыть с датами напротив каждой строки.

Возьмем, к примеру, велосипедное колесо. В верхней части вы выбираете площадку или склад, где требуется это колесо. Ниже Dynamics 365 показывает все связанные транзакции, продажи, закупки, складские запасы и производство – все в одном списке. Спрос отображается как отрицательное число по отношению к вашим доступным запасам. Этот спрос может возникать из разных источников. Заказ на продажу требует колеса, потому что клиент заказал велосипеды. Прогноз создает ожидаемый будущий спрос. Производственный заказ требует колеса согласно плану завода. А заказ на перемещение создает спрос, когда другой склад запрашивает товары. Каждая строка отвечает на простой вопрос. Кому нужен этот товар? Сколько им нужно? И к какой дате? Это звучит просто, но помогает избежать распространенной ошибки. Люди часто видят общее количество и полагают, что оно относится к одному клиенту или заказу, хотя один и тот же товар может покрывать несколько заказов на разные даты.

Со стороны снабжения у вас есть текущие складские запасы – то, что уже в наличии. Затем идут заказы на закупку у поставщиков, производственные заказы, которые компания планирует выполнить, перемещение между складами и плановые заказы, которые система предлагает, но которые еще никто не создал. Страница сортирует все по дате. Прокручивая список, вы можете наблюдать, как меняется доступное количество. В начале месяца запас может выглядеть достаточным, затем снижаться при расходе деталей на производство и снова расти при поступлении поставки от поставщика. Сроки меняют результат. Предположим, в понедельник на складе есть 100 колес, но во вторник производственный заказ требует 80, а в среду появляется потребность клиента еще на 30. Общий спрос превышает запас, даже если в пятницу поступит заказ на закупку 50 колес. Пятничная поставка не решит проблему нехватки в среду. Такое пошаговое представление по датам объясняет, почему система делает свои предложения. Dynamics 365 не просто случайно запрашивает больше колес. Она точно видит, когда доступное снабжение падает ниже спроса, который нужно покрыть. Теперь вы можете задать более конкретный вопрос. Какая строка снабжения покрывает какую строку спроса? Эта связь называется привязкой. Пикгин. Привязка – это механизм планирования Dynamics 365 для связывания спроса и снабжения. Она соединяет потребность, например, производственный заказ на велосипеды с источником, который должен ее покрыть, например, заказом на закупку колес или плановым заказом на закупку. Система создает эту связь во время расчета планирования. Если спрос меняется, планирование может пересчитать эту связь. Возможно, клиент перенес дату доставки или поставка по заказу на закупку задерживается. Тогда привязка может указать на другой источник снабжения или создать новый плановый заказ там, где возник дефицит. Это помогает отследить всю цепочку целиком. Начните с заказа на продажу, найдите связанный с ним производственный заказ, перейдите к необходимым деталям и определите заказ на закупку, который их покрывает. Иногда требуется больше контроля. Здесь на помощь приходит маркировка. Маркировка – это связь между транзакцией поставки и транзакцией спроса. Она указывает системе, что данная поставка должна покрыть именно этот спрос, не позволяя алгоритму планирования свободно перенаправлять ее.

Представьте, что вы вешаете ярлык на две связанные записи. Вы можете пометить конкретный заказ на закупку колес как предназначенный для определенного производственного заказа, поскольку эти колеса были приобретены именно для него. Планирование учитывает эту связь более строго, чем обычную привязку. Тем не менее, маркированная поставка – не самая прочная связь. Резервирование надежнее. Когда вы резервируете запас или ожидаемую поставку под конкретный спрос, вы создаете жесткую связь. Это количество откладывается для выбранного заказа на продажу, производственного заказа или другого спроса. И генеральное планирование считает резервирование приоритетным по сравнению с обычной привязкой и маркировкой. Представьте, на складе есть 10 колес, но они зарезервированы для срочного заказа на ремонт. Позднее может поступить другой заказ, требующий колес, но планирование не может считать эти 10 зарезервированных колес доступными. Системе нужно найти другие источники или предложить новые поставки, так как резервирование уже закрепило их за другим объектом. Итак, привязка, маркировка и резервирование дают три уровня связи. Привязка – это автоматическое сопоставление системой. Маркировка – это ручная, более фиксированная связь. Резервирование закрепляет поставку за конкретной потребностью. Оно – самое сильное из этих трех. Как только вы научитесь видеть эти связи, плановые заказы перестанут казаться неясными инструкциями.

Следующий вопрос. Как часто меняется представление планирования и как быстро Dynamics 365 может его рассчитать? Статическое, динамическое планирование и оптимизация планирования. Страница чистых потребностей показывает результат планирования, но не каждый план обновляется одинаково. Статический план меняется только тогда, когда кто-то запускает процесс генерального планирования. Это дает планировщикам стабильную картину, которую можно изучать в течение дня, не опасаясь, что каждая новая транзакция изменит показатели. Представьте, что крупный заказ на продажу поступает в 11 часов утра. Если статический план был запущен ночью, этот новый заказ не появится в его предложениях до следующего запуска. План все еще показывает последний рассчитанный результат, что удобно, когда команде нужно единое согласованное представление на день. Однако у этой стабильности есть своя цена. Новый спрос может некоторое время оставаться вне статического плана, особенно если ваш бизнес запускает планирование раз в день или раз в неделю. Планировщик может знать о существовании клиентского заказа, но статический план еще не пересчитал необходимый объем поставок. Именно здесь помогает динамический план. Динамический план показывает текущий спрос в режиме реального времени.

Планировщики могут видеть влияние новых заказов на продажу и другого спроса, не дожидаясь полного цикла генерального планирования. Это взгляд на краткосрочную перспективу. Динамические планы не учитывают прогнозы и фокусируются на том, что происходит прямо сейчас. Допустим, сегодня днем клиент размещает заказ на 200 велосипедов. Прежде чем обещать дату доставки, планировщик может открыть динамический план и оценить последствия. Создает ли новый заказ дефицит? Сдвигает ли он существующую потребность на более поздний срок? Вызывает ли он необходимость в новой закупке или производстве? Это дает команде практический взгляд на ситуацию, что, если вы не меняете статический план только ради проверки одного нового заказа. Вы сначала проверяете вероятное влияние, а затем решаете, требует ли заказ внимания сейчас или может подождать следующего запланированного запуска планирования. Статические и динамические планы отвечают на связанные, но разные вопросы. Статический план спрашивает, что нам предписывал сделать последний официальный расчет? Динамический план спрашивает, как выглядит текущий спрос прямо сейчас? В основе обоих планов лежит механизм планирования для облачных сред Dynamics 365. Оптимизация планирования – это современный механизм, который Microsoft использует для генерального планирования. Он рассчитывает потребности вне основного бизнес-приложения, что снижает нагрузку на систему, используемую для ежедневной работы. Старые циклы планирования могли занимать много времени. Отчеты клиентов и партнеров показывают, что задачи, занимавшие когда-то часы, теперь выполняются за минуты с помощью оптимизации планирования. Более быстрые расчеты означают, что команды могут обновлять план чаще, не дожидаясь конца дня, чтобы увидеть изменение спроса, но быстрый ответ все еще может быть неверным. Оптимизация планирования может быстро обрабатывать огромные объемы взаимосвязанных данных. Тем не менее, она работает только на основе данных, предоставляемых вашим бизнесом. Если время выполнения заказа у поставщика указано неверно, предложенная дата заказа тоже может быть ошибочной. Если система думает, что на складе есть 500 колес, а их там нет, она может пропустить предложение о закупке, которое вам действительно необходимо.

А если в спецификации материалов отсутствует какая-либо деталь, планирование не сможет создать потребность для этой детали. Расчет может завершиться за минуты, но работа фабрики все равно остановится, если этой детали нет в наличии. Также изменился сам процесс запуска планирования. При оптимизации планирования планы являются регенеративными. Это означает, что каждый прогон пересматривает все потребности заново, вместо использования старого подхода, чистого изменения, который обновлял только позиции с новыми требованиями. Думайте об этом как о пересчете всей картины планирования каждый раз. Это устраняет неопределенность относительно того, не было ли упущено какое-либо раннее изменение, в то время как быстрый движок делает полный пересчет более практичным для многих компаний. Скорость помогает, но именно частота данных определяет, можно ли доверять плану. Когда план выдает свои предложения, следующая задача — решить, что требует действий в первую очередь. Но что делает главное планирование, а чего оно не делает?

Итак, вот самое простое определение. Главное планирование берет все данные из Dynamics 365 и предлагает, что купить, произвести или переместить, с указанием дат и количества. Планировщик проверяет эти плановые заказы перед тем, как действовать. Он проверяет поставщика, дату доставки, количество и то, может ли завод справиться с работой. После подтверждения фиксации этого предложения превращает его в реальный заказ на закупку, производственный заказ или заказ на перемещение. Но главное планирование не может видеть будущее. Прогнозы — это лишь оценки, а реальные заказы клиентов могут измениться за одну ночь. И оно определенно не заменяет планировщиков людей. Люди по-прежнему управляют рисками поставщиков, обещаниями клиентам и исключениями. Система просто не может судить. Одних запасов тоже недостаточно. Эти запасы могут прибыть слишком поздно, находиться не на том складе или быть уже зарезервированными под другой заказ.

Чтобы получить хорошие результаты, начните с чистых данных, корректных записей об изделиях, точных сроков выполнения, правильных спецификаций, актуальных запасов и реалистичного спроса. Для нашего заказа на велосипеды имеющиеся запасы покрывают часть потребности. Планирование предлагает поставку остального, а планировщик подтверждает действие. Это возвращает нас к вопросу, на который должна ответить каждая команда. Что должно произойти дальше? Вывод. Единый связный план. Главное планирование берет спрос, уровень запасов, даты доставки поставщиков, графики производства и мощности, превращая все это в действие для проверки вашей командой. Плановые заказы лишь начинают процесс принятия решений человеком. Они его не завершают. Вот почему планировщики остаются незаменимыми. Подписывайтесь на любимой платформе для подкастов и поделитесь этой полезной информацией с тем, кто изучает управление цепочками поставок в Dynamics 365.