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

Слово bottleneck часто переводят как «узкое место». В производстве это ресурс или участок процесса, пропускная способность которого ограничивает выпуск всей системы. Если один рабочий центр способен обработать только 40 часов работы в неделю, а заказам требуется 55 часов, то именно этот ресурс становится ограничением — даже если остальные цеха загружены только на 50–60%.

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

Что bottleneck-анализ должен ответить руководителю производства

Хороший анализ не заканчивается таблицей из двадцати станков с процентом загрузки. Его задача — ответить на несколько практических вопросов:

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

В этом смысле bottleneck-анализ отличается от обычного производственного отчёта. Отчёт показывает состояние системы. Анализ пытается объяснить, какое ограничение формирует это состояние.

Какие данные нужны из 1С

В «1С:ERP» производственный контур содержит данные, которые подходят для такого анализа: производственные этапы и операции, рабочие центры, доступность мощностей, нормативы времени, графики производства и фактическое выполнение. Официальная документация 1С описывает планирование с учётом доступности видов рабочих центров, а на уровне цеха — расписание и загрузку рабочих центров. citeturn0search0turn0search2

Для bottleneck-анализа полезно собрать минимум следующие группы данных:

Данные	Что анализируем	Зачем нужны
Рабочие центры	Станки, линии, участки, группы оборудования	Определить физические ограничения мощности
Технологические операции	Последовательность и состав операций	Понять, какие заказы используют ограничивающий ресурс
Нормативное время	Время обработки, подготовка, переналадка	Рассчитать требуемую мощность
График работы	Смены, календарь, доступность оборудования	Рассчитать реальную доступную мощность
План производства	Заказы, объёмы, сроки	Связать ограничение с клиентскими обязательствами
Факт выполнения	Фактические объёмы и время	Сравнить нормативную и реальную производительность
Простои	Отсутствие материала, поломки, ожидание, организационные причины	Понять, почему доступная мощность меньше календарной

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

Шаг 1. Определяем производственный поток

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

Например, предприятие выпускает корпусные изделия:

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

В 1С:ERP производственный процесс описывается через этапы, ресурсные спецификации и технологические операции. Рабочие центры и их доступность участвуют в планировании производственного графика. citeturn0search0

Шаг 2. Считаем доступную мощность

Базовая формула выглядит просто:

Например, рабочий центр работает 2 смены по 8 часов в течение 5 дней:

16 × 5 = 80 часов календарной мощности в неделю.

Но если 6 часов уходят на плановое обслуживание, 5 часов на переналадки и ещё 4 часа оборудование недоступно из-за организационных ограничений, полезная доступность уже составляет 65 часов.

Это принципиально важно. Если потребность производства составляет 68 часов, а расчёт ведётся от 80 часов, система покажет запас. В реальности ограничение уже существует.

Шаг 3. Считаем потребность в мощности

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

Допустим, на станке нужно изготовить 300 деталей. Норматив обработки одной детали — 8 минут. На переналадки требуется ещё 6 часов.

Тогда:

• 300 × 8 минут = 2 400 минут;
• 2 400 минут = 40 часов;
• 40 + 6 = 46 часов потребности.

Если доступная мощность станка за тот же период — 40 часов, уже появляется дефицит в 6 часов.

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

Шаг 4. Строим матрицу «мощность / потребность»

После расчёта можно собрать простую аналитическую таблицу:

Рабочий центр	Доступно, ч	Потребность, ч	Баланс, ч	Загрузка
Фрезерный участок	160	138	+22	86%
Сверлильный участок	120	118	+2	98%
Сварочный участок	100	132	−32	132%
Покраска	140	97	+43	69%

В этом примере сварочный участок выглядит ограничением: плановая потребность превышает доступную мощность на 32 часа.

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

Почему процент загрузки сам по себе ничего не решает

Предположим, один станок загружен на 99%, а другой — на 75%. Это ещё не означает, что первый является bottleneck.

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

Поэтому анализ должен учитывать минимум четыре измерения:

• загрузка ресурса;
• очередь перед ресурсом;
• влияние ресурса на сроки заказов;
• наличие альтернативного маршрута или ресурса.

Шаг 5. Смотрим очередь перед операцией

Один из самых сильных сигналов bottleneck — накопление незавершённого производства перед конкретной операцией.

Например:

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

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

Шаг 6. Отделяем bottleneck от дефицита материалов

Это одна из самых частых ошибок.

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

Например:

• рабочий центр доступен 80 часов;
• потребность составляет 70 часов;
• фактически выполнено только 45 часов;
• 25 часов потеряно из-за отсутствия материала.

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

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

Шаг 7. Отделяем bottleneck от плохих нормативов

Вторая распространённая причина ложного bottleneck — неверное нормативное время.

Предприятие могло несколько лет назад установить норматив обработки детали 20 минут. Реальный цикл давно составляет 14 минут, но планировщик продолжает рассчитывать загрузку по старому нормативу.

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

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

Поэтому полезно сравнивать:

Показатель	Что показывает
Нормативное время	Как система планирует операцию
Фактическое время	Как операция реально выполняется
Отклонение	Насколько плановая модель отличается от производства
Причина отклонения	Брак, переналадка, ожидание, оборудование, оператор и т. д.

Шаг 8. Учитываем переналадки

Для серийного производства загрузка оборудования часто определяется не только временем обработки.

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

Например:

• обработка — 55 часов;
• переналадка — 12 часов;
• обслуживание — 3 часа;
• доступная мощность — 65 часов.

Фактическая потребность уже составляет 67 часов. Если смотреть только на время обработки, ограничение не видно.

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

Шаг 9. Строим bottleneck по заказам

Самая полезная для руководителя форма анализа — не «какой станок перегружен», а:

«Какие заказы задерживаются из-за какого ограничения?»

Например:

Заказ	Дата отгрузки	Критический ресурс	Дефицит	Риск
Заказ №10452	24.09	Сварка	8 ч	Высокий
Заказ №10471	25.09	Сварка	14 ч	Высокий
Заказ №10489	29.09	Фрезеровка	0 ч	Низкий

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

Как сделать bottleneck-анализ автоматически

Если предприятие делает расчёт один раз в Excel, это полезное упражнение. Но если данные 1С постоянно меняются, статический отчёт быстро устаревает.

Практическая архитектура может выглядеть так:

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

Что считать в отдельном аналитическом контуре

Для bottleneck-аналитики удобно иметь фактовую модель примерно следующего вида:

production_operation
---------------------
id
order_id
product_id
work_center_id
operation_id
planned_start
planned_finish
actual_start
actual_finish
planned_qty
actual_qty
planned_minutes
actual_minutes
setup_minutes
downtime_minutes
status
downtime_reason

Отдельно можно хранить справочники:

• рабочие центры;
• виды рабочих центров;
• операции;
• продукцию и спецификации;
• производственные подразделения;
• календари доступности;
• причины простоев.

Тогда bottleneck engine может пересчитывать показатели без тяжёлых запросов непосредственно к рабочей базе 1С.

Минимальный набор KPI

Для первого дашборда не нужен десяток экранов. Достаточно нескольких показателей.

KPI	Формула / смысл	Что ищем
Load	Потребность / доступная мощность	Перегруженные ресурсы
Queue	Объём работ перед операцией	Накопление НЗП
Plan / Fact	Фактическое время / нормативное	Ошибки нормативов и потери
Downtime	Простой / доступное время	Потерянная мощность
On-time	Заказы, выполненные в срок	Влияние ограничения на клиента
WIP	Незавершённое производство	Где копится очередь

Почему bottleneck нужно считать в динамике

Ограничение производства не обязательно постоянно находится в одном месте.

Сегодня узким местом может быть сварка. Завтра после изменения производственной программы — покраска. Через неделю после ремонта одного из станков — фрезеровка.

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

Поэтому правильный мониторинг должен строить временной ряд:

Тогда планировщик видит не только текущую проблему, но и то, где появится следующее ограничение.

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

Bottleneck-анализ не должен превращаться в бесконечный поиск причин. После обнаружения ограничения нужно пройти несколько практических шагов.

1. Максимально использовать существующую мощность

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

2. Подстроить производственный поток под ограничение

Если bottleneck определяет пропускную способность, нельзя планировать соседние операции так, будто его мощность бесконечна. Избыточный выпуск перед ограничением только увеличивает НЗП и очередь.

3. Проверить альтернативные ресурсы

Часть операций можно передать на другой рабочий центр, изменить маршрут, использовать альтернативную технологию или перераспределить смены. В 1С:ERP параметры рабочих центров и их доступности участвуют в расчёте производственного графика, что позволяет учитывать такие ограничения в планировании. citeturn0search0

4. Только потом увеличивать мощность

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

Главная идея здесь простая: сначала доказать ограничение данными, затем инвестировать в его устранение.

Где здесь появляется AI

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

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

Например, директор спрашивает:

AI-аналитик не должен самостоятельно придумывать цифры. Он вызывает контролируемые инструменты:

get_production_plan()
get_capacity()
get_work_center_load()
get_queue()
get_downtime()
get_delayed_orders()

После этого модель получает структурированный результат и формирует объяснение:

Такой подход отличается от «дать ChatGPT выгрузку из 1С». Сначала считается факт, затем AI объясняет его.

Почему не стоит просто выгрузить всю 1С в Excel и отдать нейросети

Большая выгрузка не решает проблему качества аналитики.

LLM может найти корреляцию, но не должна самостоятельно определять, что именно является производственной мощностью, какая операция является критической и какие бизнес-правила действуют для конкретного предприятия.

Правильнее разделить систему на уровни:

Как выглядит MVP bottleneck-анализа

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

1. Выбрать один производственный поток.
2. Забрать из 1С заказы и операции за 3–6 месяцев.
3. Определить рабочие центры и доступную мощность.
4. Сопоставить нормативное и фактическое время.
5. Рассчитать загрузку и очередь.
6. Выделить 3–5 наиболее вероятных ограничений.
7. Проверить их на фактических просроченных заказах.
8. Собрать дашборд текущего и прогнозного bottleneck.

После этого уже можно добавлять сценарное моделирование: «что будет, если добавить смену», «что будет, если перенести операцию», «что будет, если изменить приоритет заказов».

Пример архитектуры для предприятия на 1С

Для крупного производства мы бы разделяли контур учёта и контур аналитики:

Слой	Ответственность	Пример технологии
ERP	Заказы, производство, материалы, нормативы, факт	1С:ERP
Integration	Получение и доставка данных	Symfony / Go / OData / API
Analytics	История и агрегация производственных фактов	PostgreSQL
Calculation	Загрузка, очередь, ограничения, сценарии	Symfony / SQL / workers
AI	Объяснение и диалог с руководителем	LLM / MCP / AI Gateway
UI	Дашборд и управленческие решения	Web / BI

При таком разделении 1С не становится аналитическим DWH, а нейросеть не получает прямой доступ к таблицам ERP. Каждый слой отвечает за свою задачу.

Типовые ошибки bottleneck-анализа

Ошибка 1. Смотреть только на текущую загрузку

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

Ошибка 2. Считать bottleneck по одному станку

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

Ошибка 3. Игнорировать материалы

Оборудование может быть свободно, но производство всё равно остановится из-за отсутствия полуфабриката.

Ошибка 4. Верить нормативам без проверки факта

Если нормативное время не соответствует реальности, расчёт мощности будет систематически ошибочным.

Ошибка 5. Оптимизировать всё производство одновременно

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

Ошибка 6. Покупать оборудование до анализа

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

Что в итоге получает руководитель

Вместо десятков производственных отчётов руководитель получает одну причинно связанную картину:

• что производим;
• какая мощность доступна;
• где возникает дефицит;
• какая очередь накопилась;
• какие заказы затронуты;
• почему ограничение возникло;
• какие варианты устранения есть.

Именно здесь данные 1С превращаются из учётной истории в инструмент оперативного управления производством.

Итог

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

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

Для «1С:ERP» такой подход особенно естественен: система уже содержит производственные этапы, рабочие центры, графики, операции и данные диспетчеризации.

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

А система должна ответить не предположением нейросети, а расчётом на фактических данных предприятия.