INTEBRIX Optimization Platform
On-prem • Cloud в разработке Запросить демо

INTEBRIX • Подзадача APS

Replanning:
перепланирование без хаоса в производстве

План “живет”: срочные заказы, поломки, дефициты, изменения сменности и приоритетов. Replanning в Intebrix позволяет пересчитать APS так, чтобы сохранить исполнимость и при этом контролировать стабильность: что можно менять, что фиксируем (“freeze window”) и почему план изменился.

✓
Freeze window: фиксируем ближайший горизонт, меняем дальше
✓
Стабильность: минимизируем “дергание” плана (nervousness)
✓
Explained changes: видно, что поменялось и почему
✓
Сценарии: сравнение вариантов переплана по KPI
Запросить демо ← В хаб APS/MRP
On-prem • Cloud в разработке • Пилот 2–6 недель • Интеграции: ERP / 1C / Excel / API
Когда нужен replanning • Как контролируем изменения • KPI переплана • Related / Next • FAQ
Ключевая идея
Перепланирование — это не “пересчитать всё”, а управлять изменениями: что фиксируем, что оптимизируем и какую цену платим за срочность (переналадки, потери, просрочки).
Пилот → Интеграции →

Когда нужен replanning

Список ситуаций, где ручная перекладка обычно либо слишком долгая, либо приводит к лавине ошибок.

Поломка / недоступность ресурса
Ресурс выпал → нужно перераспределить операции по альтернативам и сменам.
DowntimeCapacity
Дефицит материалов (MRP)
Сроки обеспечения изменились → пересчитываем план, учитывая реальную доступность.
MRPShortage
Срочный заказ / смена приоритета
Нужно “втиснуть” срочное, не разрушив весь остальной план.
PriorityDue date
Смена сменности / календарей
Добавили/убрали смены, выходные → перестраиваем исполнимость по мощностям.
CalendarsShifts
Новые ограничения (качество/оснастка)
Запреты, промывки, окна QC → встраиваем как constraints.
ConstraintsQuality
Стабилизация плана
Если “дергается” каждый день — задаем правила стабильности и зоны пересчета.
NervousnessFreeze

Как контролируем изменения

Переплан — это управление областью изменений и их стоимостью. Ниже — базовые механизмы, которые обычно “держат” систему.

Окно заморозки (freeze window)
Фиксируем то, что уже “в работе”, и оптимизируем дальше по горизонту.
Near-term фиксируем
Например 1–3 дня: операции/очередь/оснастка — по регламенту.
Mid-term оптимизируем
Перестраиваем последовательности, партии, распределение по ресурсам.
Long-term планируем
Сценарии “что-если”, подготовка материалов/мощностей на будущее.
Пояснимость изменений
Чтобы план принимали, нужно отвечать на вопрос “почему так?”.
Список изменений
Что сдвинулось, где сменился ресурс, какие операции переставлены.
Причины
Дефицит, поломка, приоритет, ограничение, окно заморозки.
Цена решения
Рост переналадок, просрочка части заказов, пик нагрузки на узкое место.
Важное ограничение
Частота replanning — управляемая величина. Иногда лучше делать пересчет по событию (поломка/дефицит), а иногда — по расписанию (ежедневно/ежесменно) с заданным окном стабильности.
What-if сценарии →

KPI перепланирования

Replanning оценивается не только сроками. Мы обычно фиксируем KPI стабильности и “стоимости” изменений.

Сроки / OTIF
Просрочка, OTIF, выполнение по due dates после событий.
OTIFDue date
Стабильность (nervousness)
Сколько изменений в плане: перестановки, смена ресурса, сдвиги дат.
StabilityFreeze
Setup / потери
Рост/падение переналадок и потерь после пересчета.
SetupLosses
Загрузка узких мест
Пики/провалы на bottleneck при изменении плана и приоритетов.
BottleneckCapacity

FAQ по replanning

Коротко о главном: как часто пересчитывать, что фиксировать, и как избежать “дергания”.

Как часто делать replanning?

Зависит от процесса. Часто: по событию (поломка/дефицит) + регулярный пересчет по расписанию (например ежедневно).

Ключ — freeze window и KPI стабильности, чтобы план не “дергался” без необходимости.

Что фиксировать, чтобы производство не “вставало”?

Обычно фиксируют ближайший горизонт: операции в работе, подготовленную оснастку, выпущенные задания.

Дальше по горизонту допускают перестановки и оптимизацию (setup, batching), сохраняя приоритеты.

Почему система изменила план?

Intebrix показывает изменения и причины: дефицит, поломка, приоритет, новое ограничение, окно заморозки.

Также видно “цену” решения: рост переналадок/потерь или сдвиг части заказов.

Дальше логично: What-if
Сценарии “что-если” помогают заранее оценивать последствия переплана до запуска в работу.
What-if → Setup optimization → В хаб →
Made on
Tilda