Теория ограничений TOC и bottleneck-анализ производства

На производстве часто пытаются повысить эффективность отдельных участков: увеличить загрузку станков, сократить время переналадки, повысить производительность операторов, автоматизировать отчётность. Проблема в том, что локальное улучшение не обязательно увеличивает выпуск всего предприятия.

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

Именно эту проблему рассматривает Theory of Constraints (TOC) — теория ограничений, связанная с работами Элияху Голдратта. Её центральная идея проста: сначала нужно найти ограничение системы, затем управлять им, а уже после этого переходить к следующему ограничению. В TOC этот подход формализован в пяти фокусирующих шагах — Identify, Exploit, Subordinate, Elevate и возврат к поиску нового ограничения.

Что такое Theory of Constraints

Теория ограничений рассматривает предприятие как связанную систему. Производство состоит из последовательности операций, рабочих центров, людей, оборудования, материалов и правил планирования. Если один элемент имеет меньшую доступную пропускную способность относительно потребности системы, он может стать ограничением.

В простом виде производственный поток можно представить так:

Заготовка
    ↓
Операция 10
    ↓
Операция 20
    ↓
Операция 30 ← ограничение
    ↓
Операция 40
    ↓
Готовое изделие

Если операция 30 физически способна обработать меньше объёма, чем требуется downstream-процессам, именно она ограничивает скорость прохождения потока.

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

Bottleneck и constraint — одно и то же?

В производственном контексте термины часто используют как синонимы, но полезно различать их по смыслу. Bottleneck обычно означает узкое место производственного процесса — ресурс или операция, ограничивающие поток. Constraint в TOC шире: ограничением может быть не только станок, но и правило, политика, нехватка материала, рынок, спрос или другое условие системы.

Понятие	Что означает	Пример
Bottleneck	Физическое узкое место производственного потока	Станок с недостаточной мощностью
Capacity constraint	Ресурс с ограниченной доступной мощностью	Рабочий центр с дефицитом часов
Material constraint	Ограничение из-за обеспечения	Нехватка критического материала
Policy constraint	Ограничение, созданное правилом управления	Правило запуска партий, создающее очереди
Market constraint	Ограничение со стороны спроса	Недостаточный объём заказов

Почему высокая загрузка ещё не означает bottleneck

Одна из распространённых ошибок — искать узкое место только по проценту загрузки. Например, рабочий центр загружен на 97%, а другой — на 82%. На первый взгляд первый ресурс кажется очевидным bottleneck.

Но одного процента недостаточно. Нужно смотреть, сколько мощности требуется для выполнения конкретного производственного плана, когда возникает очередь, какие заказы проходят через ресурс, сколько времени занимает переналадка и какова фактическая доступность.

Поэтому корректный bottleneck-анализ должен связывать минимум четыре слоя данных:

Как провести bottleneck-анализ производства

1. Определить производственный поток

Сначала нужно понять, какие операции формируют путь изделия от сырья до готового продукта. Для сложного производства одного списка рабочих центров недостаточно. Необходимо видеть технологические маршруты и зависимости между операциями.

Например, два изделия могут использовать один и тот же станок, но проходить через него в разные моменты времени. Если анализировать только справочник оборудования, реальная конкуренция за мощность будет незаметна.

2. Рассчитать потребность в мощности

Для каждого рабочего центра рассчитывается потребность в часах:

Потребность = Σ(Количество × Норма времени) + Время переналадок

Затем потребность сравнивается с доступной мощностью ресурса.

Дефицит мощности = Потребность − Доступная мощность

Коэффициент нагрузки = Потребность / Доступная мощность

Это уже значительно полезнее обычного показателя «загрузка станка», потому что показывает связь между производственной программой и доступным ресурсом.

3. Найти очередь перед ресурсом

Реальное узкое место часто видно не только по загрузке, но и по очереди перед операцией. Если перед рабочим центром регулярно накапливаются полуфабрикаты, а после него поток ускоряется, это сильный сигнал для дополнительного анализа.

Важно смотреть динамику. Очередь, возникшая один раз из-за крупной партии, не обязательно означает постоянное ограничение.

4. Проверить фактическую доступность

Расчётная мощность может существенно отличаться от фактической. На ресурс влияют:

• аварийные простои;
• плановое обслуживание;
• переналадки;
• отсутствие оператора;
• ожидание материала;
• ожидание инструмента;
• брак и повторная обработка;
• изменение производственной программы.

Поэтому bottleneck-анализ должен использовать не только нормативы, но и факт.

5. Посчитать вклад ограничения в выпуск

Следующий вопрос — насколько конкретный ресурс действительно ограничивает общий поток. Для этого полезно связать его с заказами, сроками, объёмом выпуска и экономикой продукции.

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

Как выглядит bottleneck-анализ на данных 1С

В 1С:ERP уже могут находиться данные, необходимые для такого анализа: ресурсные спецификации, этапы производства, технологические операции, нормы времени, рабочие центры и данные производственного планирования. Официальная документация 1С описывает ресурсные спецификации как инструмент, содержащий этапы производства, продукцию, материалы, трудовые нормы и технологические операции, а также данные для расчёта загрузки рабочих центров.

На практике аналитический контур можно построить следующим образом:

1С:ERP
  ↓
Заказы + спецификации + маршруты
  ↓
Integration Layer
  ↓
PostgreSQL / Analytics DB
  ↓
Bottleneck Engine
  ↓
Загрузка + очереди + дефицит мощности
  ↓
Dashboard / AI Analyst

При этом 1С остаётся источником операционных данных, а аналитический слой рассчитывает показатели, необходимые для оперативного управления.

Какие показатели стоит смотреть

Показатель	Что показывает	Зачем нужен
Load	Отношение потребности к доступной мощности	Поиск потенциального дефицита мощности
Queue	Объём работ перед операцией	Выявление накопления WIP
Plan / Fact	Плановый и фактический выпуск	Контроль исполнения программы
Downtime	Потери доступного времени	Поиск причин недоступности ресурса
Setup time	Время переналадок	Поиск скрытой потери мощности
WIP	Незавершённое производство	Контроль накопления между операциями
OTIF	Выполнение заказов в срок и полном объёме	Связь ограничения с клиентским результатом

Пять шагов TOC: что делать после обнаружения bottleneck

Найти bottleneck — только начало. TOC предлагает последовательность из пяти фокусирующих шагов. Важно не перескакивать сразу к покупке нового оборудования: сначала нужно использовать существующее ограничение максимально эффективно, затем подчинить ему остальные процессы и только после этого рассматривать увеличение мощности.

Шаг 1. Identify — найти ограничение

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

На этом этапе важно не путать локальную проблему с системным ограничением.

Шаг 2. Exploit — максимально использовать ограничение

Если bottleneck найден, сначала нужно убрать потери внутри уже существующей мощности. Например:

• исключить необязательные простои;
• обеспечить постоянную подачу материала;
• не допускать ожидания инструмента;
• сократить лишние переналадки;
• обеспечить качественный вход перед ограничением;
• не ставить на bottleneck задачи, которые можно выполнить иначе.

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

Шаг 3. Subordinate — подчинить остальные процессы ограничению

Это один из наиболее важных и часто пропускаемых принципов TOC. Если bottleneck способен обработать 100 единиц в смену, запускать upstream-процессы на 150 единиц не означает получить 150 единиц готовой продукции.

Избыток превращается в WIP и очередь. Поэтому остальные ресурсы должны работать в режиме, который поддерживает ограничение, а не пытается независимо максимизировать собственную загрузку.

Шаг 4. Elevate — увеличить мощность ограничения

Если после эксплуатации существующего ресурса и подчинения остальных процессов ограничения всё ещё недостаточно, можно увеличивать его мощность:

• добавить оборудование;
• расширить сменность;
• добавить персонал;
• модернизировать ресурс;
• передать часть операций внешнему исполнителю;
• изменить технологический маршрут.

Это уже инвестиционное решение, которое имеет смысл принимать после анализа того, что можно получить без капитальных затрат.

Шаг 5. Repeat — вернуться к первому шагу

После снятия ограничения система меняется. Bottleneck может перейти на другой ресурс. Поэтому TOC — не разовый отчёт, а цикл постоянного улучшения.

Найти ограничение
       ↓
Использовать его максимально
       ↓
Подчинить остальные процессы
       ↓
Увеличить мощность при необходимости
       ↓
Найти новое ограничение
       ↺

Почему нельзя просто повысить загрузку всех станков

На многих предприятиях KPI построены вокруг локальной эффективности: процент загрузки, количество обработанных деталей, коэффициент использования оборудования.

Если каждый участок пытается максимизировать собственный показатель независимо от потока, система начинает производить больше полуфабрикатов, чем может пройти через ограничение. Это может увеличивать WIP и сроки прохождения заказа, не увеличивая выпуск готовой продукции.

Именно поэтому TOC предлагает оценивать систему целиком, а не только эффективность отдельных ресурсов. Lean и TOC могут использоваться совместно: Lean помогает системно работать с потоком и потерями, а TOC задаёт фокус на ограничении, которое в данный момент сильнее всего влияет на результат системы.

Динамический bottleneck: почему одного отчёта недостаточно

На реальном производстве ограничение может меняться в зависимости от продуктового микса и горизонта планирования. Сегодня узким местом является термообработка, через неделю — механообработка, а в следующем месяце — участок сборки.

Поэтому полезно считать bottleneck не только «на текущий момент», но и по временным окнам:

Горизонт	Вопрос
Смена	Что ограничивает выпуск прямо сейчас?
Неделя	Где сформируется очередь?
Месяц	Какой ресурс станет дефицитным?
Квартал	Нужно ли расширять мощность?

Такой подход позволяет перейти от реактивного управления к прогнозированию ограничения.

Как связать TOC с производственным планированием

Bottleneck-анализ особенно полезен, когда он не существует отдельно от планирования. Результат анализа должен влиять на порядок запуска заказов, сроки, приоритеты и распределение доступной мощности.

Например:

Заказы
  ↓
План производства
  ↓
Расчёт потребности в мощности
  ↓
Bottleneck analysis
  ↓
Ограничение
  ↓
Приоритеты и последовательность запуска
  ↓
Сменные задания
  ↓
Факт производства
  ↓
Новый расчёт

Так формируется замкнутый цикл: план создаёт потребность в мощности, bottleneck-анализ показывает ограничение, а факт производства позволяет пересчитать ситуацию.

Где здесь 1С, MES и SCADA

Для промышленного предприятия обычно нет необходимости заставлять одну систему решать все задачи. ERP хранит бизнес-контекст и производственное планирование, MES отвечает за оперативное управление производством, SCADA получает технологические данные от оборудования.

1С:ERP
   │
   ├── заказы
   ├── спецификации
   ├── планирование
   └── обеспечение
        │
        ▼
Integration Layer
        │
        ├───────────────┐
        ▼               ▼
       MES            Analytics
        │               │
        ▼               ▼
      SCADA        Bottleneck Engine
        │               │
        └───────┬───────┘
                ▼
         Руководитель
         производства

В такой архитектуре bottleneck-аналитика становится отдельным вычислительным слоем, который собирает данные из нескольких источников и возвращает управленческий результат.

Можно ли использовать AI для bottleneck-анализа

Да, но AI лучше использовать не как замену расчётному ядру. Сам bottleneck должен определяться на основе формализованных данных и правил: мощности, потребности, маршрутов, очередей, простоев и факта.

LLM полезна следующим уровнем — для объяснения результата и подготовки управленческих действий.

1С + MES + SCADA
        ↓
Детерминированные расчёты
        ↓
Bottleneck Engine
        ↓
Business Tools
        ↓
LLM
        ↓
Почему возникло ограничение?
Что будет через неделю?
Какие заказы затронуты?
Что можно сделать без CAPEX?

Такой подход соответствует архитектурному принципу: AI должен объяснять и оркестрировать контролируемые бизнес-инструменты, а не самостоятельно придумывать производственные показатели.

Какие инструменты можно дать AI-аналитику

Вместо прямого доступа LLM к базе 1С можно предоставить ограниченный набор бизнес-инструментов:

get_work_center_load()
get_capacity_demand()
get_production_queue()
get_bottlenecks()
get_downtime()
get_production_orders()
get_material_shortages()
get_plan_fact()
get_shift_assignments()

Тогда запрос руководителя:

«Какое узкое место у нас сейчас и какие заказы оно задерживает?»

превращается в последовательность контролируемых запросов к данным, а LLM формирует объяснение и связывает показатели в понятный управленческий ответ.

Минимальный MVP bottleneck-аналитики

Необязательно сразу строить полноценную MES или сложную систему производственного планирования. Для первого этапа достаточно взять один производственный участок и один горизонт планирования.

Как выглядит архитектура production-grade

┌──────────────────────┐
│       1С:ERP         │
│ заказы / спецификации│
│ производство / план  │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Integration Layer   │
│ API / events / queue │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Analytics PostgreSQL │
│ факт / план / WIP     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  Bottleneck Engine   │
│ capacity / queue     │
│ load / plan-fact     │
└──────────┬───────────┘
           │
      ┌────┴────┐
      ▼         ▼
 Dashboard    AI Analyst
      │         │
      └────┬────┘
           ▼
      Руководитель

Типичные ошибки при внедрении TOC-аналитики

Ошибка	Что происходит
Искать bottleneck только по загрузке	Можно принять локально загруженный ресурс за системное ограничение
Использовать только нормативы	Расчёт расходится с реальным производством
Игнорировать очереди	Теряется один из важных признаков ограничения
Максимизировать загрузку всех ресурсов	Растут WIP и незавершённое производство
Сразу покупать оборудование	Можно инвестировать до того, как использована текущая мощность
Давать LLM прямой доступ к БД	AI начинает зависеть от физической структуры данных и получает слишком широкий доступ
Считать bottleneck один раз	Анализ устаревает после изменения продуктового микса и производственной программы

Что даёт TOC-подход производству

TOC не является ещё одним отчётом о загрузке оборудования. Это способ изменить саму логику производственного управления: вместо попытки улучшать всё одновременно предприятие фокусируется на факторе, который ограничивает поток системы.

В цифровом производстве этот подход особенно полезен, когда данные из 1С, MES и оборудования уже существуют, но не собраны в единую аналитическую модель.

Тогда задача выглядит не как «поставить ещё один dashboard», а как построить контур:

Данные
  ↓
Единая модель производства
  ↓
Расчёт мощности
  ↓
Bottleneck
  ↓
Управленческое действие
  ↓
Факт
  ↓
Новый расчёт

А следующий уровень — добавить AI поверх этого контура, чтобы руководитель мог задавать вопросы обычным языком: какое ограничение возникло, почему оно возникло, какие заказы затронуты, что произойдёт при изменении плана и какие действия доступны без капитальных вложений.

FAQ

Что такое bottleneck-анализ?

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

Чем bottleneck отличается от обычного анализа загрузки?

Анализ загрузки показывает состояние отдельного ресурса. Bottleneck-анализ связывает ресурс с потоком всей системы, очередями, производственной программой, доступной мощностью и результатом.

Можно ли сделать bottleneck-анализ на данных 1С:ERP?

Да. В качестве исходных данных могут использоваться производственные заказы, ресурсные спецификации, технологические операции, рабочие центры, нормы времени, доступная мощность и фактические результаты.

Нужно ли покупать MES?

Не обязательно. Для первого этапа можно построить аналитический контур поверх существующих данных. Если требуется оперативное управление цехом, диспетчеризация и связь с оборудованием, архитектура может быть расширена MES и SCADA-контуром.

Можно ли автоматизировать TOC-анализ?

Да. Расчёт ограничения, мощности, очередей и дефицита можно выполнять автоматически. AI при этом можно использовать для объяснения результатов и подготовки сценариев действий.

Итог

Теория ограничений начинается с простого вопроса: что сейчас ограничивает поток всей системы?

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

После этого TOC задаёт последовательность действий: найти ограничение, максимально использовать его, подчинить ему остальные процессы, при необходимости увеличить его мощность и снова начать поиск ограничения.

В связке с 1С:ERP, MES, SCADA, PostgreSQL и AI это превращается в постоянный цифровой контур управления производственной пропускной способностью.