Умное планирование производства в 1С ERP: когда типового функционала недостаточно

Введение: как устроено производственное планирование в 1С ERP

Большинство промышленных предприятий в России в качестве основной учётной системы используют программные продукты на платформе «1С:Предприятие». Конфигурация «1С:ERP Управление предприятием 2» (далее — 1С ERP) является флагманским решением для комплексной автоматизации.

Что даёт 1С ERP предприятию?

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

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

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

Какие объекты производственного учёта есть в 1С ERP? 

Для управления производством в 1С ERP предусмотрены следующие объекты:

1. Ресурсная спецификация — справочник, в котором описывается поэтапный процесс изготовления продукции: сырьё и материалы, трудозатраты (сварочные, фасовочные, слесарные работы), производственные операции и их последовательность. Например, для зубной пасты спецификация может включать: загрузку сырья через люк, перемешивание, варку, охлаждение, слив, фасовку.
2. План производства — документ сквозного планирования. В классической модели он формируется на основе плана продаж: что нужно продать → то нужно произвести → под это нужно закупить сырьё. Затем план производства становится потребностью для плана закупок.
3. Заказ на производство — документ, в котором фиксируются: какая продукция или полуфабрикаты должны быть произведены, в каком количестве, по какой спецификации, и в какие ориентировочные даты.
4. Этап производства — документ, который строится на основании заказа на производство. Именно на этом этапе происходит детальное планирование: назначаются графики, диспетчирование, списание сырья, фиксация фактических трудозатрат и выпуска. Этап является основанием для документов выпуска из производства.
5. Документ выработки сотрудников — фиксирует конкретных исполнителей по выполненным работам (слесарные, варочные, фасовочные). Эти данные затем интегрируются с подсистемой кадров и зарплаты, а при закрытии месяца трудозатраты ложатся в себестоимость продукции, делая её расчёт более точным и прозрачным.
6. Заказы переработчикам и давальческая схема — для ситуаций, когда предприятие либо передаёт часть производства сторонней организации, либо само выступает переработчиком.

Таким образом, 1С ERP предоставляет полноценный инструментарий для сквозного производственного планирования. Но почему же на многих предприятиях планировщики по-прежнему сидят в Excel? Разберём это на реальном кейсе.

Проблема: почему Excel и типовой 1С не справляются 

Прежде чем перейти к кейсу, важно понять, в чём заключаются объективные недостатки ERP-систем (не только 1С, но и любых других).

Недостатки ERP-систем в контексте планирования:

1. Сложность внесения данных. Чтобы получить качественную отчётность по всем процессам, нужно занести огромное количество справочников и документов. На обычном предприятии с рядовыми и возрастными сотрудниками это приводит к ошибкам, сопротивлению и постоянным обращениям в IT-отдел.
2. Взаимозависимость отделов. Документ одного отдела может не провестись, потому что смежный отдел что-то не занёс или занёс с ошибкой. Это создаёт «эффект домино» и задержки.
3. Неоперативность. Данные часто заносятся с опозданием, ресурсы ограничены (10–15 человек на всё предприятие), и в итоге система не даёт той оперативной картины, которая нужна для повседневного планирования.
4. Высокий порог квалификации. Не каждый сотрудник способен быстро разобраться, почему не провёлся документ или почему ошибка в проводках.

Реальный кейс: производство зубной пасты

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

Характеристики предприятия:

• две производственные площадки;
• более 1000 единиц готовой продукции;
• десятки рабочих центров: варочные аппараты (где варится основа пасты) и фасовочные конвейеры (где паста фасуется в тюбики и упаковывается в коробки);
• отдел планирования — три человека (производственные диспетчеры);
• текущий инструмент планирования — Excel.

Двойная задача планировщика:

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

Причём речь идёт об оперативном планировании: например, 16 апреля планировщик строит план на 19 апреля и при необходимости корректирует планы на 17–18 апреля с учётом уже случившихся фактов.

Как планировщик работает сегодня (реальная практика):

1. Планировщик собирает данные из разных источников:
   • из УПП (учётная система) — рецептуры (ресурсные спецификации), данные по продажам;
   • из специальных программ адресного хранения (склад сырья);
   • от операторов-упаковщиков — в устной форме или в виде письменных заданий.
2. Все эти данные он складывает в несколько Excel-файлов.
3. Запускает исторически сложившиеся макросы (которые работают успешно много лет).
4. Получает подготовленные данные и начинает ручное планирование.

Почему это работает, но плохо?

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

1. Зависимость от конкретного сотрудника. Если ключевой планировщик уволится или заболеет — процесс может встать или сильно ухудшиться.
2. Человеческий фактор. Планировщик — не машина. Он не может перебрать в уме все комбинации загрузки оборудования для ассортимента в 1000+ позиций и 100+ рабочих центров. Он действует на основе опыта, а значит, его план почти гарантированно неоптимален.
3. Сложность масштабирования. Если компания открывает новую площадку, нужно либо нанимать ещё одного планировщика, либо перегружать существующих.
4. Обратная связь через жалобы. Планировщик узнаёт о неоптимальности плана только тогда, когда поступают жалобы от отдела продаж («товар не успели к акции, склады пустые») или от производства («полсмены простояли из-за долгих переналадок»).

Какие ещё ограничения есть в реальном производстве?

Планировщик должен учитывать множество технологических нюансов. Вот только некоторые из них, которые были в разобранном кейсе:

• Схема аппаратов и конвейеров. Ближайший варочный аппарат к ближайшему конвейеру — это эффективно (короткий шланг, продукт не застревает). Но если нужно, можно подключить дальний конвейер длинным шлангом — просто эффективность будет ниже. Планировщик должен стремиться к оптимальным связкам.
• Порядкозависимые переналадки. Если сварили зелёную пасту (для детей), а потом варить белую (стандартную) — нужно 120 минут на отмывку чана. А если после белой варить белую — переналадка 2 минуты. Если меняется диаметр тюбика (28 мм взрослый, 22 мм детский) — тоже требуется время на переналадку оборудования.
• Ограниченность людей. На два рабочих центра может быть один сотрудник. Это нужно учитывать, чтобы не запланировать одновременную работу, требующую двух человек, если в смене только один.

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

Почему типовой 1С не решает эту задачу?

У команды разработки возникло закономерное желание — реализовать планирование силами самой 1С, используя типовые механизмы (заказы на производство → этапы). Но при попытке внедрения выявились серьёзные ограничения.

Что не так с типовым механизмом 1С:

1. Низкая скорость формирования этапов. Даже для 10 номенклатур формирование этапов занимает около 2 минут, а распроведение — около 3 минут. В этапах задействованы 42 регистра, которые связаны с другими системами.
2. Невозможность оперативного пересчёта. Для задач «давайте попробуем убавить, прибавить, пересчитать по-другому» (а это 90% работы планировщика в Excel) такой механизм категорически не подходит.
3. Архитектурные ограничения платформы:

• • 1С изначально создавалась как система учёта финансовых транзакций, а не для математической оптимизации. Основное «узкое горлышко» — операции ввода-вывода с базой данных.
  • Для задач планирования нужна скорость арифметических операций и работы со структурами данных. На практике скорость вычислений в 1С в боевом режиме в 30–50 раз ниже, чем на низкоуровневых языках типа C++ (особенно если включена отладка).
  • В 1С все числа представлены в десятичной форме, а не в экспоненциальной, что дополнительно замедляет математические операции.
  • Прикладной уровень 1С не поддерживает многопоточные вычисления. Даже если у вас есть эффективный алгоритм, он будет работать только на одном ядре.
  • В 1С нет готовых библиотек для математической оптимизации (в отличие от Python, C++, Java, C#).

Вывод: типовой 1С не предназначен для решения сложных комбинаторных задач, связанных с оперативным планированием производства с тысячами комбинаций.

Что предлагает рынок: готовые APS-системы

APS (Advanced Planning and Scheduling) — класс систем для продвинутого планирования и составления расписаний. Это отдельное программное обеспечение, которое устанавливается на отдельный сервер и имеет свою собственную базу данных.

Как устроена классическая APS-система:

1. Вы передаёте в APS данные из вашей учётной системы (1С, SAP, Oracle и др.): спецификации, заказы, приоритеты, графики работы, остатки сырья.
2. APS, используя встроенные алгоритмы оптимизации, строит оптимальное расписание.
3. Планировщик работает в интерфейсе APS либо смотрит результат, интегрированный обратно в учётную систему.

Плюсы APS-систем:

• Не нужно разрабатывать свои алгоритмы — они уже есть «из коробки».
• Многие APS заточены под типовые производственные процессы.
• Можно достаточно быстро получить результат (если процесс укладывается в стандартную модель).

Минусы APS-систем (проблемы, с которыми сталкиваются предприятия):

1. Ограничение функциональности. Любая готовая система имеет заранее определённый набор возможностей. Если у вас есть специфическое технологическое ограничение (например, «длинные шланги между аппаратами и конвейерами» или «только определённые пары аппарат-конвейер допустимы»), готовая APS может его не поддерживать. А доработать её, в отличие от 1С, вы не сможете — кнопки «Конфигуратор» там нет.
2. Привязка к разработчику. Если нужно что-то изменить или добавить — вы зависите от вендора APS, его сроков, его цен и его компетенций.
3. Проблемы с интерфейсом. В одних APS рабочие места интегрируются в интерфейс 1С (пользователь не замечает переключения). В других — это совершенно отдельная программа со своим интерфейсом. Для многих заказчиков это неприемлемо: «Мы не хотим два окна, мы хотим всё в 1С».
4. Интеграционная сложность. Нужно настраивать обмен данными между 1С и APS, поддерживать его актуальность при каждом изменении в цеху, отлаживать протоколы передачи, обрабатывать ошибки синхронизации.

Когда APS подходит, а когда — нет?

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

Альтернативный путь: собственная разработка через оптимизационные библиотеки

Если готовая APS не подошла, остаётся вариант разработать собственное решение.

Как это обычно делается:

1. Выбирается одна или несколько оптимизационных библиотек (обычно на C++, Python, Java, C#). Эти библиотеки содержат готовые алгоритмы для решения комбинаторных задач: смешанное целочисленное программирование (MILP), метод ветвей и границ, генетические алгоритмы, имитацию отжига и т.д.
2. Разработчик (уже не 1С-специалист, а математик-программист) пишет решающий модуль, который использует эти библиотеки для построения расписания.
3. Настраивается интеграция между 1С и этим модулем: выгрузка исходных данных (спецификации, заказы, ограничения), запуск расчёта, загрузка результата обратно в 1С.

Какие проблемы возникают на этом пути:

1. Инфраструктурные затраты — главная боль. По оценкам авторов вебинара, 70–80% времени разработчика уходит не на математическую модель и не на алгоритмы, а на написание протоколов обмена, отладку интеграции, сериализацию/десериализацию данных, поддержку актуальности выгрузок, обработку ошибок связи. Это «паразитные задачи», которые не добавляют ценности заказчику, но отнимают ресурсы.
2. Высокий порог входа. Нужен специалист, который одновременно разбирается в 1С (чтобы правильно выгрузить данные) и в математической оптимизации (чтобы правильно поставить задачу и выбрать алгоритм). Таких людей на рынке мало, стоят они дорого.
3. Сложность отладки. Ошибка может быть на любом из этапов: неправильно выгрузили данные из 1С → неправильно передали → неправильно обработали в решателе → неправильно загрузили результат обратно. Отлаживать такой конвейер — долго и мучительно.
4. Документация по библиотекам. Документация к оптимизационным библиотекам часто разрозненная, неполная, неактуальная, на английском языке, а иногда ссылается прямо на академические статьи. Это замедляет разработку.
5. Поддержка изменений. Если в цеху изменилась технология (добавился новый аппарат, изменились переналадки, поменялись схемы связок), нужно вносить изменения и в модель, и в интеграцию, и тестировать заново всё целиком.

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

Решение: оптимизационная библиотека О2 (Оптимизация Операций)

Именно для того, чтобы устранить разрыв между «гибкостью самописного решателя» и «простотой внедрения внутри 1С», была создана оптимизационная библиотека О2.

Что такое О2?

О2 — это решение, которое позволяет разработчику 1С описывать математическую модель планирования прямо на встроенном языке 1С, а все «тяжёлые» вычисления выполняются отдельной службой-решателем, установленной локально на сервере предприятия.

Архитектура решения:

text

[1С:Предприятие] → [Расширение О2] → [Модель на языке 1С] → [Решатель (отдельная служба)] → [Оптимальное расписание] → [Обратно в 1С]

Как это работает шаг за шагом:

1. Разработчик 1С устанавливает расширение О2 на свою базу (никаких дополнительных зависимостей).
2. Разработчик описывает модель прямо в коде 1С:
   • объявляет переменные (неизвестные величины, которые нужно найти, — например, на каком аппарате и в какое время варить каждую партию);
   • задаёт ограничения (например, «время варки не может быть меньше 2 часов», «переналадка после зелёной пасты — 120 минут», «конвейер 3 может работать только с аппаратами 1 и 2»);
   • задаёт целевую функцию (то, что нужно оптимизировать: минимизировать время переналадок, максимизировать загрузку оборудования, минимизировать простои, максимизировать маржу).
3. Вызовом одного метода Решить() модель автоматически преобразуется в специальный формат и отправляется решателю.
4. Решатель — это отдельная служба, которая устанавливается на сервер предприятия двойным кликом (как 1С-сервер). Внутри решателя — набор промышленных оптимизационных алгоритмов на C++/Python, которые быстро перебирают комбинации и находят оптимальное или близкое к оптимальному решение.
5. Готовое решение возвращается в 1С.
6. Разработчик подставляет полученные значения в свои документы, диаграммы Ганта, отчёты.

Пример кода модели (упрощённый, для понимания):

1С

// 1. Создаём модель

Модель = О2.СоздатьМодель("ПроизводственноеРасписание");

// 2. Объявляем переменные

Переменные = Модель.ДобавитьПеременные("Количество_столов", "Количество_стульев");

// 3. Ограничения: количество не может быть отрицательным

Переменные.Количество_столов.НижняяГраница = 0;

Переменные.Количество_стульев.НижняяГраница = 0;

// 4. Ресурсные ограничения (древесина, краска)

Модель.ДобавитьОграничение("Древесина", "1*Количество_столов + 0.5*Количество_стульев <= 20");

Модель.ДобавитьОграничение("Краска", "2*Количество_столов + 1*Количество_стульев <= 18");

// 5. Целевая функция (максимизируем прибыль)

Модель.Максимизировать("100*Количество_столов + 50*Количество_стульев");

// 6. Решаем!

Результат = Модель.Решить();

// 7. Используем результат

Сообщить("Оптимально произвести столов: " + Результат.Значение("Количество_столов"));

Сообщить("Оптимально произвести стульев: " + Результат.Значение("Количество_стульев"));

(Это пример простой задачи «столы-стулья» для демонстрации синтаксиса. В реальной задаче переменных — тысячи.)

Преимущества подхода О2:

1. Пишут 1С-разработчики. Не нужно искать редкого математика-программиста. Ваши штатные 1С-специалисты, которые знают структуру базы и бизнес-процессы, сами описывают модель.
2. Данные не нужно выгружать и синхронизировать. Модель работает прямо с данными в 1С (запросами к регистрам, справочникам, документам). Отпадает 70–80% «паразитной» работы.
3. Решатель не нужно программировать. Он устанавливается как готовая служба. Внутри — проверенные, промышленные алгоритмы.
4. Транспорт не нужно писать. Модель → решатель → результат — уже реализовано в расширении.
5. Документация есть. На сайте продукта — собранная, структурированная документация на русском языке с примерами. Можно скачать готовую обработку EPF и посмотреть, как решаются типовые задачи.
6. Гибкость. Вы описываете именно ваши ограничения (порядкозависимые переналадки, удалённость конвейеров, совмещение профессий, любые специфические правила).
7. Единый интерфейс. Планировщик остаётся в 1С, не переключается между окнами.

Какие типы задач можно решать с помощью О2 (не только производство)?

Библиотека О2 не ограничивается производственным планированием. Вот далеко не полный перечень классов задач, для которых уже есть готовые модели и алгоритмы:

Как это выглядит в 1С: демонстрация на примере зубной пасты

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

Интерфейс рабочего места (АРМ планировщика):

Разработчики создали специализированное рабочее место в 1С, которое состоит из нескольких вкладок.

Вкладка 1: Потребность к производству

Здесь отображаются:

• Потребность в продукции — может быть загружена из месячного плана продаж или добавлена вручную (например, если отдел продаж сообщил о срочном приоритетном заказе).
• Расшифровка продукции по сырью — мгновенный расчёт, сколько сырья потребуется для выполнения плана.
• Возможности варки и фасовки — система показывает, сколько продукции можно физически сварить и расфасовать при текущих мощностях.
• Уходимость по продажам — приоритеты: что делать в первую очередь, что во вторую, что в третью.

Вкладка 2: Ресурсы по предварительному плану

Здесь система раскладывает заказанную продукцию на этапы производства. Например, для зубной пасты:

• Этап 1: варка заготовки основы
• Этап 2: варка самой пасты
• Этап 3: изготовление коробки (параллельно с варкой)
• Этап 4: фасовка

Для каждого этапа видны требуемые ресурсы, время, трудозатраты.

Настройки алгоритма:

Планировщик может задать параметры оптимизации перед расчётом:

• Максимальное время планирования — например, 30 секунд. Алгоритм ищет лучшее решение в пределах этого времени.
• Коэффициент учёта удалённости — приоритет связки «ближайший варочный аппарат — ближайший конвейер» (чем выше коэффициент, тем сильнее алгоритм старается минимизировать длину шлангов).
• Коэффициент учёта загрузки — система стремится подобрать аппарат так, чтобы загрузка была максимальной (например, если нужно сварить 500 кг, не брать аппарат на 2000 кг, если есть аппарат на 600 кг).

Запуск расчёта:

Планировщик нажимает кнопку «Заполнить расписание». Алгоритм работает заданное время (например, 30 секунд), перебирает комбинации и возвращает готовый график производства по обеим площадкам.

Визуализация — диаграмма Ганта:

Самый наглядный результат — цветная диаграмма Ганта, где можно увидеть:

• Какие аппараты (конкретно: аппарат 54, 56, 157 и т.д.) и когда заняты.
• Сколько требуется операторов и упаковщиков на каждом рабочем центре.
• Процент загрузки каждого аппарата.
• Зелёным цветом — то, что система распланировала сейчас (актуально).
• Серым цветом — то, что было запланировано ранее (например, на 18 апреля).
• Розовым цветом — переналадки (например, после зелёной пасты 120 минут на отмывку).

Особенности отображения:

• На конвейерах и аппаратах маркировки работа привязана к сменам людей (смена 12 часов).
• Варочные аппараты работают круглосуточно.
• Во время фасовки пасты варочный аппарат не может выполнять другую работу (он опорожняется). Это отображается дополнительным цветным блоком.

Ручная корректировка и пересчёт:

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

Что происходит с документами 1С?

Решение не использует типовые заказы на производство и этапы на этапе планирования (это слишком тяжеловесно и медленно). Вместо этого:

1. Планирование ведётся в лёгких регистрах и вспомогательных таблицах.
2. Оперативный план хранится в доработанном документе «Оперативный план» (нетиповом).
3. Накануне рабочего дня (например, 16 апреля для плана на 17 апреля) на основе оперативного плана создаются обычные заказы на производство. Такой подход обеспечивает скорость планирования (как в Excel) при сохранении стандартного документооборота 1С для производства.

Пример изменения коэффициента:

Если планировщик увеличит «коэффициент учёта загрузки» со среднего до 100, алгоритм пересчитает расписание и начнёт максимально загружать самый большой аппарат (например, аппарат 157), чтобы сварить всё в нём, а не размазывать по мелким. Это видно на изменении процента загрузки аппаратов до и после.

Статья написана по итогам вебинара (видео) "Умное планирование производства в 1С:ERP на основе математической оптимизации".