Уявіть, що клієнт хоче отримати 100 велосипедів наступного місяця. Рами прибувають із запізненням. Колеса лежать на іншому складі. А ваша складальна лінія вже завантажена роботою на найближчі два тижні. Отже, що вам купувати? Що вам будувати? Що вам переміщати? І коли вам потрібна кожна деталь? А вже ж! Міл Копетас із М365FM. Цей екскурс узнання стосується Dynamics 365 Master Planning. Це частина управління ланцюгами постачання, яка вирішує ці питання залаштунками. Уявіть свій бізнес як офісну будівлю з прибудованим складом. Замовлення надходять через одні двері. Запаси лежать на полицях. Постачальники доставляють товари на вантажну платформу. Виробництво перетворює деталі на готову продукцію. Генеральне планування охоплює всю будівлю, замість того, щоб залишати кожну команду зі своїм окремим списком. Сьогодні ми з Гертманом простежимо за одним замовленням велосипедів від запиту клієнта до дій із постачання.

Dynamics 365 пояснює, чому бізнесу потрібен план, а не електронна таблиця. До появи інструментів інтегрованого планування компанії працювали з розрізнаною інформацією. Відділ продажів мав замовлення клієнтів в одному місці. Складські команди перевіряли запаси в іншій системі, відділ закупівель відстежував терміни постачальників у листах чи таблицях, а виробництво ввело власні записи про те, що фабрика може збудувати цього тижня. Кожен список виглядав правильним окремо. Проблеми починалися, коли хтось намагався відповісти на одне запитання клієнта. От, чи зможемо ми доставити 100 велосипедів до обіцяної дати? Ayola Tafts. Уявіть, що на складі сьогодні є 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. Думайте про BOM як про рецепт одного велосипеда. Він перераховує раму, колеса, ланцюг, сидіння, кермо, гальма, болти та будь-яку іншу деталь, необхідну для його створення. Якщо замовлення потребує 70 велосипедів, планування розширює це замовлення до переліку частин, необхідних для всіх 70.

Це може дуже швидко перетворитися на довгий список. Вам може знадобитися 70 рам, 140 коліс, 70 ланцюгів, 70 сидінь і сотні дрібних болтів. Планувальнику не доводиться рахувати кожну деталь вручну. Специфікація матеріалів дає Dynamics 365 структуру, завдяки якій система може простежити попит від готового велосипеда до кожного компонента. Але самі лише деталі не створять велосипеди. Для виробництва також потрібен маршрут. Маршрут описує робочі кроки, необхідні для створення виробу, збирання рами, встановлення коліс, перевірка гальм і пакування готового велосипеда. Кожен крок може потребувати ресурсу. Таким ресурсом може бути конвоєрна лінія, верстек, фарбувальна камера, верстат або група людей з відповідними навичками. Планування використовує цю інформацію, щоб розмістити роботу в потрібний час. Замість того, щоб розглядати виробництво як щось, що відбувається миттєво, саме тут дати починають рухатися назад.

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

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

Dynamics 365 не надсилає замовлення постачальнику самостійно і не розпочинає роботу на заводі. Вона надає плановальнику запропоновану кількість і дату на основі даних, які вона бачить. Людина все одно перевіряє, чи правильний постачальник, чи реальна дата і чи варто бізнесу схвалювати цю дію. Уявіть невелику проблему з нашим замовленням на велосипеди. Здається, все готово, крім одного колеса. Планове постачання покриває рами, ланцюги, сидіння і майже всі колеса. Але одне колесо прибуває через день після того, як воно потрібне для збірки. Без цього колеса один велосипед не може бути завершений. Хоча склад може здаватися повним деталей, генеральне планування простежує розрив до його джерела. Планувальник бачить, що дефіцит не походить від самого замовлення клієнта. О, він походить від дати постачальника у замовленні на закупівлю коліс. Це дає плановальнику конкретну інформацію для дій. Запросити раніше доставку, знайти іншого постачальника або змінити дату виробництва.

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

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

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

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

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

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

План все ще показує останній розрахований результат, що корисно, коли команді потрібно мати єдине узгоджене бачення на день. Але ця стабільність має свою ціну. Новий попит може залишатися поза межами статичного плану деякий час, особливо якщо ваш бізнес виконує планування раз на ніч або раз на тиждень. Планувальник може знати про існування клієнтського замовлення, але статичний план ще не перерахував відповідне постачання. Саме тут допомагає динамічний план. Динамічний план відображає поточний попит у реальному часі. Планувальники можуть бачити вплив нових замовлень на продаж та іншого попиту, не чекаючи на наступний повний запуск головного планування. Це погляд на короткострокову перспективу. Динамічні плани ігнорують прогнози та зосереджуються на тому, що відбувається зараз. Припустімо, клієнт робить несподіване замовлення на 200 велосипедів сьогодні в день. Перш ніж обіцяти дату доставки, планувальник може відкрити динамічний план і перевірити наслідки.

Чи створює нове замовлення-дефіцит? Чи переносить воно існуючу потребу на пізнішу дату? Чи викликає воно нову пропозицію щодо закупівлі або виробництва? Це дає команді практичний огляд типу «що якщо». Ви не змінюєте статичний план лише заради аналізу одного нового замовлення. Ви спочатку перевіряєте ймовірний вплив, а потім вирішуєте, чи потребує замовлення уваги зараз, чи може почекати до наступного запланованого розрахунку. Статичні та динамічні плани відповідають на пов'язані, але різні питання. Статичний план запитує, що нам радив зробити наш останній офіційний розрахунок планування. Динамічний план запитує, як виглядає поточний попит прямо зараз. В основі обох планів лежить механізм планування для хмарних середовищ Dynamics 365. Оптимізація планування – це сучасний механізм, який Microsoft використовує для головного планування. Він обчислює потреби поза межами основного бізнес-додатку, що зменшує навантаження на систему, яку люди використовують для повсякденної роботи.

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

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

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

Для нашого замовлення велосипедів наявні запаси покривають частину потреби. Планування пропонує постачання для решти, а планувальник підтверджує дію. Це повертає нас до запитання, на яке має відповісти кожна команда. Що має статися далі? Висновок. Один пов'язаний план. Головне планування бере попит, рівні запасів, дати доставки постачальників, виробничі графіки та потужності, перетворюючи все це на дії для перегляду вашою командою. Планові замовлення лише започатковують прийняття рішень людьми. Вони не завершують його. Ось чому планувальники залишаються незамінними. Підписуйтесь на вашій улюбленій подкаст-платформі та поділіться цим корисним досвідом з тими, хто вивчає керування ланцюгами постачання в Dynamics 365.