Resources

Capacity planning: как находить узкие места и управлять загрузкой

“Мощностей не хватает” — это почти всегда не про «купить станки», а про то, что мощность не измерена, ограничения не формализованы, а загрузка управляется “по ощущениям”. Capacity planning превращает это в управляемую систему: где узкое место, сколько реальной мощности, что можно обещать клиенту и что делать, чтобы не ломать план.

Запросить демо → Практический playbook

Формат: аналитический разбор + практические принципы. Цифры — ориентиры из публичных кейсов и исследований (переносимость зависит от контекста).

Содержание

Capacity planning

Что такое capacity planning

Зачем оно бизнесу и где ошибки.

Basics

Как находить узкие места

Методы, сигналы, диагностика.

Bottleneck

Playbook управления загрузкой

Шаги, пороги, горизонты.

Practice

Метрики и контроль

Utilization, WIP, lead time, adherence.

KPI

Эффекты и ориентиры

Публичные цифры “до/после”.

Cases

Источники

Кейсы и материалы для проверки.

Links

Bottleneck → • Календари/смены → • Маршруты/нормативы →

Термины из глоссария в этой статье

Короткие определения — по ссылкам (откроется глоссарий на нужном термине):

Capacity planning Bottleneck Executable schedule Plan-fact Календари/смены Constraints-first Setup / Переналадка

Открыть глоссарий целиком →

Что такое capacity planning и почему “мощность” почти всегда переоценена

Capacity planning — это система ответов на вопросы: сколько мы реально можем произвести/перевезти в заданном горизонте, какие ресурсы ограничивают выпуск, и как меняется выполнимость плана при сценариях.

“Номинальная” vs “доступная” мощность

Номинал (паспорт/план) ≠ реальность. Реальная мощность зависит от сменности, календарей, простоев, переналадок, квалификации, окон обслуживания и ограничений по материалам. См. глоссарий: календари/смены, setup/переналадка.

RealityCalendars

Почему планы “не исполняются”

Частая причина — план строится без конечных мощностей или без реальных правил “как работает поток”. Результат: расписание на бумаге, а в цехе/логистике — другая реальность. См. глоссарий: исполнимое расписание.

FeasibilitySchedule

Задача управления

Цель — не “100% загрузка”, а управляемый баланс: сервис (OTD/OTIF), стабильность плана, WIP/очереди, стоимость, переналадки и риск срыва. В зрелом контуре это фиксируется через plan-fact.

BalancePlan-fact

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

Как находить узкие места: 5 практичных методов

Узкое место — ресурс/операция/плечо, которое ограничивает выпуск или сервис. См.: bottleneck.

1) Очередь и WIP “перед ресурсом”

Самый надёжный признак: перед узким местом всегда накапливается очередь. Если в одном месте постоянно WIP/ожидание — это кандидат №1 на constraint.

WIPQueue

2) Невыполнимость по календарю

Если при корректных календарях и сменности план не помещается в доступное время — проблема не “в людях”, а в дефиците мощности (или в ошибочных нормативах).

CalendarsFeasibility

3) Нормативы и маршруты

Часто bottleneck “искусственный”: нормативы времени устарели, маршруты неполные, переналадки считаются “где-то отдельно”. См.: маршруты и нормативы.

StandardsRouting

4) Смена ассортимента = сдвиг узкого места

Constraint может “переезжать” при другом миксе заказов и партий. Поэтому важны сценарии и анализ чувствительности (what-if).

MixWhat-if

5) Малые проценты, большие последствия

Если ресурс уже загружен “под потолок”, прибавка эффективности на 1–2 п.п. может дать заметную добавку к выпуску/стоимости. В публичном кейсе по заполнению фур рост заполнения с 96% до 98–99% дал ≈2% отправок “бесплатно”.

UtilizationEconomics

Пример (IBM) →

Ключ: искать не “самый загруженный”, а “самый ограничивающий”

Узкое место — то, что ограничивает поток и сервис, а не то, что “по отчёту красиво загружено”. Практика: соединить загрузку, очереди, календарь и KPI “план-факт”.

BottleneckFlow

Playbook: как управлять загрузкой и не убить стабильность плана

Ниже — минимальный набор правил, который работает и в производстве, и в логистике.

Шаг 1. Соберите “правду мощности”

Календари/сменность, доступность, нормы времени, переналадки, ограничения совместимости. Это база для любой модели. Без неё capacity planning превращается в “красивый отчёт”.

Master dataReality

Шаг 2. Разведите горизонты

Долгий горизонт — агрегатные мощности и инвестиционные решения. Средний — баланс спроса/выпуска/мощностей. Короткий — исполнимое расписание и диспетчеризация.

LongMidShort

Шаг 3. Защитите bottleneck

Правило: bottleneck должен работать максимально предсказуемо. Не ломайте его частыми срочными перестановками — это обычно дороже, чем кажется.

BottleneckStability

Шаг 4. Управляйте партиями и переналадками

Большая часть потерь мощности — не “простои”, а плохая последовательность и “рваные” партии. Нужна модель A→B и учёт setup во времени и стоимости.

SetupSequence

Шаг 5. Ограничьте “героизм”

Оvertime, ручные ускорения, постоянные “внеплановые” — это симптом, что мощность/ограничения не управляются системно. Вводите правила: что можно обещать, а что требует согласования.

GovernanceRules

Шаг 6. Закрепите процесс через plan-fact

Если нет измеримого “план-факт” и причин отклонений — вы не управляете мощностью, вы реагируете на хаос. См.: plan-fact.

Plan-factRoot causes

Показать на демо →

Быстрый старт

Самый эффективный пилот: 1 узкое место + 1 семейство продуктов + реальные календари/переналадки. Дальше — сценарии и фиксация эффекта через KPI.

Запросить демо → Capacity planning (модуль) →

Метрики: что мерить, чтобы управление загрузкой было “не по ощущениям”

Важно: метрики должны быть связаны с решениями (что меняем, когда видим отклонение).

Utilization (загрузка)

По ключевым ресурсам: план/факт, простои, переналадки, эффективность смен. Но не гонитесь за 100%: перегруз часто увеличивает очереди, WIP и сроки.

Utilization

WIP / очередь перед bottleneck

WIP — главный индикатор “затыка”. Управляя WIP, вы управляетe lead time и предсказуемостью.

WIPFlow

Schedule adherence / plan-fact

Сколько реально выполнено “как планировали”. Чем выше adherence, тем меньше ручного героизма и тем лучше прогнозируемость сервиса.

AdherencePlan-fact

Эффекты: какие “до/после” встречаются в публичных кейсах

Это ориентиры. В реальном проекте эффект фиксируется через ваши KPI и план-факт на ваших данных.

APS/планирование и загрузка (публичный кейс)

В кейсе Siemens Drives по planning & scheduling зафиксированы результаты: -20% inventory, -60% WIP, +14% utilization, +4% delivery capability (и заявленная экономия первой фазы).

CaseUtilizationWIP

Источник (Siemens case study) →

Ускорение потока (пример количественного “до/после”)

В исследовании по улучшению потока через VSM lead time снизился с 9.5 до 2.17 дней, а on-time delivery рос до целевого уровня. Это хорошая иллюстрация: узкое место + поток + дисциплина данных дают измеримый эффект.

Lead timeOTD

Источник (SAGE paper) →

Эффект “пара процентов”

Когда ресурс уже почти “под потолок”, небольшое улучшение загрузки/потерь может дать непропорциональный эффект. В кейсе IBM по оптимизации загрузки фур рост заполнения с 96% до 98–99% дал ≈2% отправок бесплатно.

UtilizationEconomics

Источник (IBM) →

Как корректно “прибить” эффект в вашем случае

Перед пилотом фиксируем базу (как сейчас): adherence, WIP, lead time, OTD/OTIF, overtime, переналадки, долю ручных ускорений. На пилоте сравниваем сценарии и внедряем правила принятия решений: что меняем, когда видим отклонение, и кто утверждает изменения.

PilotPlan-factKPI

Источники и чтение

Материалы, на которые опирались для цифр и формулировок.

Siemens case study (Opcenter APS / planning & scheduling): -20% inventory, -60% WIP, +14% utilization, +4% delivery capability. Ссылка
Lockamy & McCormack (VSM, flow improvements): lead time 9.5 → 2.17 days, on-time delivery improvements. PDF
IBM (linehaul load optimization): 96% → 98–99% full; ≈2% shipments free. Ссылка