Анализ сценариев «что если» в планировании производства: метод

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

Анализ сценариев «что если» в планировании производства означает сохранение базового плана, изменение одного допущения и сравнение результата до того, как что-либо произойдёт на самом деле. Допущением может быть станок, который простаивает две смены, срочный заказ, отсутствующий материал или новая модель сменного графика. Сравнение показывает, как каждый выбор влияет на сроки поставки, загрузку и сверхурочные. Эта статья предназначена для планировщиков производства, которым нужен повторяемый метод, а не разовая таблица, и которые хотят понимать, какие данные, инструменты и проверки делают ответы надёжными.

Ключевые выводы

• Сценарий «что если» берёт ваш базовый план, меняет одно допущение, например остановку станка или срочный заказ, и сравнивает результат с базовым планом до того, как что-либо произойдёт на самом деле.
• Начните с решения, затем выберите два–три рычага и два–три ключевых показателя, потому что сценарий без решения, на которое он опирается, — это всего лишь упражнение.
• Сначала меняйте один рычаг за раз и объединяйте рычаги только после того, как поймёте эффект каждого по отдельности.
• Проверьте модель на прошедшем периоде, прежде чем доверять ей будущий, ведь ценность модели зависит от того, достаточно ли точны её результаты для её целей.
• Инструменты 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, чтобы руководители могли проследить логику.

Следующий шаг

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