Аналіз сценаріїв «що, якщо» у виробничому плануванні: метод

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Аналіз сценаріїв «що, якщо» у виробничому плануванні означає копіювання плану, зміну одного припущення та порівняння результатів. Дізнайтеся про кроки, дані, інструменти та перевірки.

Automatically translated with AI from the original post. Read the English original

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

Головне

• Сценарій «що, якщо» бере ваш базовий план, змінює одне припущення, наприклад простій верстата чи термінове замовлення, і порівнює результат із базовим, перш ніж щось відбудеться насправді.
• Почніть з рішення, потім оберіть два–три важелі та два–три KPI, адже сценарій без рішення за ним є лише вправою.
• Спочатку змінюйте один важіль за раз, а комбінувати їх починайте лише тоді, коли зрозумієте кожен ефект окремо.
• Перевірте модель на минулому періоді, перш ніж довіряти їй майбутнє, адже цінність моделі залежить від того, чи достатньо точні її результати для її призначення.
• Інструменти Microsoft покривають частину роботи: головні плани Dynamics 365 можуть містити альтернативні стратегії планування, а параметри «що, якщо» в Power BI підходять для простих розрахунків, але не для послідовності виконання замовлень.

Що таке сценарій «що, якщо» і чим він не є?

Сценарій — це узгоджений набір припущень щодо майбутнього, який обчислюється в тій самій моделі, що й базовий план. Базовий план — це ваш найкращий поточний план. Усе інше є його варіацією.

Варто розрізняти три поняття, які люди часто плутають.

• Прогноз каже, чого ви очікуєте. Сценарій каже, що станеться, якщо відбудеться щось конкретне.
• Питання «що, якщо» — це питання, яке ви ставите. Симуляція заводу — один із способів відповісти на нього, коли ви запускаєте модель виробництва з обраними вхідними даними. Ще один спосіб — електронна таблиця або розрахунок планування в ERP-системі.
• Перевірка чутливості змінює один вхідний параметр у діапазоні, щоб побачити, наскільки сильно змінюється результат. Вона показує, які припущення заслуговують на вашу увагу.

Мета всіх трьох однакова: з'ясувати наслідки рішення, поки ще легко передумати.

Які рішення варті сценарію?

Запускайте сценарій, коли рішення важко скасувати, коли взаємодіє кілька обмежень або коли відповідь не очевидна з досвіду. Типові тригери у виробничому плануванні:

• Вузьке місце, верстат, буде на ремонті, і вам треба обрати, які замовлення зсунути.
• Клієнт просить раніший термін. Що це зсуває і хто за це платить?
• Відпустки або лікарняні зменшують укомплектування на тиждень.
• Постачальник повідомляє про затримку ключового матеріалу.
• Асортимент продукції незабаром зміниться, і ви хочете знати, чи й далі працює поточна потужність.
• Ви розглядаєте другу зміну, новий буфер або додаткову оснастку.

Пропускайте сценарії для рішень, які дешево й швидко скасувати, і для питань, коли план уже здійсненний із достатнім запасом. Сценарій коштує часу планувальника, тому він має забезпечити краще рішення.

Як проводити аналіз сценаріїв «що, якщо» у виробництві?

Ось послідовність, яка працює і в електронній таблиці, і в спеціалізованому програмному забезпеченні.

1. Запишіть рішення. Одне речення: «Нам треба вирішити X до п'ятниці». Якщо не можете цього сформулювати, сценарій ще не потрібен.
2. Зафіксуйте базовий план. Збережіть поточний план разом із припущеннями: календарі, цикли виробництва, список замовлень, наявність матеріалів. Кожен сценарій порівнюється з цією версією, тож вона не повинна змінюватися під час роботи.
3. Оберіть важелі. Важелі — це речі, які ви можете змінити або які можуть змінитися: потужність, укомплектування персоналом, пріоритети замовлень, строки виконання, надходження матеріалів. Візьміть два-три, які мають значення для цього рішення.
4. Задайте реалістичні діапазони. Запитайте тих, хто знає. Скільки зазвичай триває типовий ремонт? Як часто постачальники запізнюються і на скільки? Не вигадуйте цифр: використовуйте власну історію і позначайте кожну оцінку як оцінку.
5. Оберіть показники. Достатньо двох-трьох KPI: доставка в строк, час виконання, завантаження вузького місця, години понаднормової роботи, незавершене виробництво. Зафіксуйте їх до запуску будь-чого, щоб ніхто потім не обрав найвигідніший.
6. Змінюйте один важіль за раз. Порівнюйте кожен сценарій з базовим планом. Поєднуйте важелі лише тоді, коли розумієте вплив кожного окремо.
7. Порівняйте і прийміть рішення. Розташуйте базовий план і сценарії поруч. Обговоріть, що б ви зробили в кожному випадку, і запишіть рішення та його причину.
8. Ведіть журнал. Збережіть припущення та результат разом із рішенням. Вони знадобляться, коли ви будете аналізувати, що насправді сталося.

Ось гіпотетичний приклад, вигаданий лише для ілюстрації логіки. На дільниці є один вузький прес, який випускає 300 одиниць за зміну. Завод працює десять змін на тиждень, тож потужність становить 3 000 одиниць. Замовлення цього тижня разом дають 2 700 одиниць, що становить 90% потужності. Базовий план є здійсненним, із запасом в одну зміну.

• Сценарій A: Прес простоює дві зміни. Потужність падає до восьми змін, або 2 400 одиниць. Залишається 300 одиниць без покриття, тож деякі замовлення не встигнуть до своїх строків.
• Сценарій B: Той самий простій плюс субботня зміна. Потужність повертається до 2 700 одиниць, але завантаження тепер 100%. Будь-яке подальше збурення означає зрив строку.
• Сценарій C: Той самий простій, а планувальник переносить 300 одиниць низькопріоритетних замовлень на наступний тиждень. Ключові замовлення відвантажуються вчасно, і один клієнт отримує дзвінок сьогодні, а не несподіванку в п'ятницю.

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

Які дані та інструменти вам потрібні?

Почніть з того, що є. Сценарій потребує тих самих вхідних даних, що й сам план: замовлення та строки, маршрути і цикли виробництва, ресурси та календарі, наявність матеріалів. Якщо ці дані ненадійні, кожен сценарій успадковує помилку. Спершу виправте майстер-дані, інакше ви будете сперечатися про модель замість рішення.

Далі оберіть інструмент залежно від складності задачі.

• Електронна таблиця підходить, коли відповідь визначають один-два ресурси і кілька замовлень, як у прикладі вище.
• Планове розрахування у вашій ERP може впоратися із задачами, керованими матеріалами. У Dynamics 365 Supply Chain Management головні плани дозволяють змоделювати різні стратегії планування, а документація Microsoft зазначає, що можна створити скільки завгодно планів і зберігати деякі з них для різних прогнозів або симуляцій. Уточніть у свого партнера з впровадження, як це працює у вашій версії та з вашим механізмом планування, бо на сторінці докладно не описано роботу зі сценаріями. Головне планування працює з матеріалами і потужністю на грубому рівні і не є інструментом детального впорядкування операцій.
• Планувальник із скінченною потужністю або імітаційна модель є правильним вибором, коли взаємодіють спільні верстати, переналагодження, залежні від послідовності, зміни та навички працівників. У такому разі просте розрахунок може виглядати добре, тоді як денний графік є нездійсненним.
• Power BI – добре місце, щоб показувати результати сценаріїв керівникам. Його параметри «що якщо» дозволяють користувачу пересунути повзунок і побачити, як змінюється показник. Microsoft пише, що їх призначено для використання в мірах усередині візуалів, а параметр може мати не більше ніж 1 000 унікальних значень. Тож вони корисні для простих питань на кшталт «що дасть на 5% більше браку для обсягу випуску?» Вони не впорядковують графік роботи. Сприймайте їх як інтерфейс для результатів, а не як рушій.

Який би інструмент ви не обрали, тримайте поза ним дві речі: письмово зафіксовані припущення та журнал рішень. Інструменти змінюються, а документи переживають їх.

Звідки ви знаєте, що відповідям можна довіряти?

Сценарій вартий стільки, скільки модель, на якій він побудований. Допоможуть три перевірки.

Зробіть бектест. Запустіть модель на минулому періоді, результат якого вам відомий. Порівняйте її результати з реальними показниками. У літературі з моделювання це називають операційною валідністю: чи достатньо точно поведінка результатів моделі відповідає її призначенню в межах умов, для яких її буде використано. Стаття Сарджента та його колег з Winter Simulation Conference подає це саме так і наголошує, що ризик користувача моделі, тобто прийняття хибної моделі, має залишатися малим. Простими словами: якщо модель не може відтворити минулий місяць, не використовуйте її, щоб вирішувати про наступний.

Знайте свої драйвери. Змінюйте кожне припущення в його діапазоні та дивіться, які з них рухають результат. Часто домінують два. Саме вони заслуговують на кращі дані. Решту можна залишити грубою оцінкою.

Показуйте діапазон, а не одне число. Твердження на кшталт «ми відвантажимо в четвер» передбачає точність, якої у вас немає. «Між середою і п'ятницею, залежно від часу ремонту» є чеснішим і корисним. Особи, що ухвалюють рішення, здатні працювати з невизначеністю, якщо її видно.

Як зробити це звичкою, а не проєктом?

Робота зі сценаріями провалюється, коли вона залежить від електронної таблиці однієї людини. Кілька практик тримають її живою.

• Призначте відповідального за базовий сценарій і дані моделі. Без цього модель відійде від реальності цеху.
• Проводьте короткий щотижневий слот, де планувальник, керівник виробництва і, за потреби, закупівлі та продажі розглядають відкриті питання. Беріть два-три сценарії, а не двадцять.
• Проводьте огляд після факту. Коли тиждень завершився, порівняйте, що сталося, із тим, що показав сценарій. Де він розійшовся з реальністю і чому? Оновіть модель або діапазони.
• Діліться логікою, а не лише результатом. Якщо керівник виробництва розуміє припущення, він оскаржуватиме їх раніше, а саме для цього й існує вся ця вправа.
• Залучайте фінансистів. Питання вартості, наприклад понаднормові проти запізнілої поставки, потребують тих самих сценаріїв із доданими цифрами витрат. Узгодьте вхідні дані про витрати один раз, щоб цифри не змінювалися між нарадами.

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

Типові помилки

• Запуск сценаріїв без рішення, яке за ними стоїть.
• Одночасна зміна кількох важелів, через що ніхто не знає, що спричинило ефект.
• Порівняння сценаріїв із базовим сценарієм, який тим часом змінився.
• Використання найкращих значень для циклів і часу ремонту.
• Пропуск бектесту, бо модель «виглядає правильно».
• Звіт з одним числом замість діапазону.
• Створення сценаріїв для всього і жодної дії на їх основі.
• Забутий запис рішення, тож під час огляду порівнювати нічого.

Місце Polaris

Якщо ваші питання «що буде, якщо…» стосуються спільних верстатів, змін і мінливого асортименту, симуляція виробничої системи відповість на них швидше, ніж таблиця. iFAKT описує Polaris як ШІ плюс цифровий двійник виробництва, що працює з даними ERP. Модуль Polaris Simulator віртуально перевіряє виробничу систему перед тим, як ухвалювати реальні рішення, зокрема сценарії потужностей, персоналу та буферів, і показує вузькі місця та дисбаланс завантаження. Модуль Polaris Optimizer створює оптимізований план з урахуванням обмежень і аналізує вплив збоїв. Спершу спробуйте це на одному реальному рішенні та перевірте результати за розрахунком у таблиці, якому ви довіряєте.

Пов’язані теми для вивчення

• Планування на випадок збоїв: як заздалегідь підготувати типові дії для поломок обладнання, затримок матеріалів і відсутності персоналу.
• Потужність проти скінченного планування: чому тижневе уявлення про навантаження може виглядати добре, тоді як денний графік не витримує.
• Зміни асортименту: перевірка того, як перехід до складніших варіантів переміщує вузьке місце.
• Валідація моделі на практиці: порівняння змодельованих і фактичних термінів виконання за минулий період.
• Звітність за сценаріями: відображення базового плану та сценаріїв поряд у Power BI, щоб керівники могли простежити логіку.

Наступний крок

Візьміть наступне рішення, яке стоїть перед вами, і сформулюйте його одним реченням. Потім збережіть поточний план як базовий і запустіть на ньому три сценарії, змінюючи щоразу лише один важіль. Такий невеликий раунд аналізу сценаріїв «що буде, якщо» у виробничому плануванні покаже, чи варта ця методика місця у вашій щотижневій нараді.