На производстве это повторяется слишком часто.

• 1С:ERP уже есть.

• Заказы в системе есть.

• Нормативы есть.

• Остатки, графики, ресурсы — тоже.

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

Получается странная, но очень знакомая картина: учётный контур в системе уже живёт, а оперативное планирование — ещё нет.

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

Где проходит граница между ERP и реальным расписанием

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

Если упростить, разницу можно описать так:

• ERP отвечает на вопрос: что нужно произвести

• APS отвечает на вопрос: как именно это лучше произвести

Типовой ERP-контур хорошо справляется с задачами уровня:

• какие есть заказы;

• какие нужны материалы;

• какие ресурсы доступны;

• какие нормативы и маршруты заданы;

• в каком объёме нужно выполнить план.

Но как только начинаются вопросы уровня цеха, задача резко усложняется:

• на какой конкретно ресурс поставить операцию;

• что делать при поломке оборудования;

• как пересобрать график после срочного заказа;

• как уменьшить переналадки;

• как не перегрузить узкий участок;

• как сбалансировать сроки, ресурсы и загрузку.

Именно здесь проходит граница: ERP хранит и организует данные о производстве, а APS нужен там, где требуется построить детальное расписание с учётом множества ограничений одновременно.

Почему Excel побеждает там, где уже есть ERP

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

Он позволяет быстро:

• руками изменить логику;

• перестроить последовательность;

• учесть неформальные ограничения;

• отразить то, что не укладывается в типовой сценарий.

Пока производство относительно простое, это терпимо.

Но на сложном производстве Excel начинает ломаться сразу в нескольких местах:

1. План держится на конкретном человеке.

2. Перепланирование плохо воспроизводится.

3. Сложно быстро пересчитать несколько сценариев.

4. Ошибки не локализованы в системе.

5. ERP и реальная картина в цехе начинают расходиться.

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

Что такое APS — без маркетинга и лишних слов

Если убрать аббревиатуры и презентационные формулировки, APS работает с задачей такого типа:

Есть:

• множество заказов;

• множество операций;

• множество ресурсов;

• множество ограничений;

• одна или несколько целей.

Нужно:

• построить лучший допустимый план;

• причём не «вообще хороший», а хороший по выбранному критерию.

Например, критерий может быть таким:

• минимизировать просрочки;

• сократить переналадки;

• выровнять загрузку;

• не сорвать приоритетные заказы;

• уменьшить конфликты в плане.

То есть APS-подход нужен там, где требуется:

• учитывать много ограничений одновременно;

• быстро пересчитывать сценарии;

• находить лучший вариант из допустимых;

• снижать потери и конфликты в производственном плане.

Где здесь появляется математическая оптимизация

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

Формально она начинает выглядеть примерно так:

Дано:

• ресурсы R

• операции O

• временные окна T

• ограничения C

• целевая функция F

Найти:

schedule(O, R, T)

такой, чтобы:

• соблюдались ограничения C;

• оптимизировалась функция F.

Это уже не про абстрактную математику. Это прикладная задача оптимизации:

• описать переменные;

• задать ограничения;

• сформулировать целевую функцию;

• передать модель в решатель.

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

Почему внешний APS-контур — не всегда лучший вариант

Исторически APS-системы часто жили отдельно от ERP. Схема была примерно такой:

ERP -> выгрузка данных -> APS
APS -> расчёт -> обратная загрузка в ERP

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

• интеграционная сложность;

• расхождение данных;

• задержки при обмене;

• дублирование логики;

• отдельный стек сопровождения;

• отдельная зона ответственности.

Отсюда возникает логичный архитектурный вопрос:

Можно ли оставить ERP ядром системы, а расчётный слой встроить рядом, не вынося всю задачу в отдельный продукт?

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

Как это выглядит в случае О2

Сильная сторона О2 — не просто в оптимизации как таковой, а в том, как именно она встроена в контур 1С.

Схема работы выглядит так:

1. В коде 1С формируется оптимизационная модель.

2. Модель сериализуется и передаётся во внешний решатель.

3. Решатель выполняет вычисления.

4. Результат возвращается обратно в 1С.

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

То есть по сути:

• 1С — это источник данных, место формирования модели и прикладная бизнес-логика;

• solver — вычислительный сервис.

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

Упрощённая схема потока данных

[Документы и регистры 1С]
            |
            v
[Сбор исходных данных]
            |
            v
[Построение модели в 1С]
            |
            v
[Serialize -> Solver]
            |
            v
[Оптимизационный расчёт]
            |
            v
[Результат -> обратно в 1С]
            |
            v
[График / рекомендации / план]

Ценность такого подхода в том, что вычислительный сервис остаётся именно вычислительным сервисом, а не превращается во «вторую ERP».

Что в этой схеме важно для архитектора 1С

1. Не возникает вторая полноценная бизнес-система

Здесь важно понимать: речь не о готовом APS-интерфейсе, а об инструменте моделирования и расчёта.

Не так:

1С + ещё одна большая система

А так:

1С + сервис расчёта модели

2. Бизнес-логика остаётся там, где ей и место

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

3. Можно использовать текущие данные ERP без тяжёлого ETL

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

4. Порог входа для команды ниже

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

5. Сложные вычисления локализуются в отдельном слое

Для архитектора это выглядит довольно рационально:

• учёт, документы, проводки, регистры — в 1С;

• сложный расчёт расписания — в solver;

• результат — обратно в 1С.

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

Где такой подход реально полезен

Такой подход особенно актуален там, где уже не хватает линейного планирования:

• планирование производства;

• оптимальное распределение ресурсов;

• назначение исполнителей;

• маршрутизация;

• балансировка потоков;

• оптимизация загрузки оборудования;

• другие комбинаторные задачи.

И здесь есть важный нюанс: О2 — это не готовый экран APS, а инфраструктура для моделирования и расчёта.

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

Когда потребность в APS-слое уже назрела

Обычно это видно по нескольким сигналам:

• производственный план постоянно «дотягивают руками»;

• без Excel оперативное планирование не работает;

• один сбой ломает весь график;

• типового механизма хватает только на базовый уровень;

• перепланирование занимает слишком много времени;

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

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

Что посмотреть дальше

Этой теме посвящён бесплатный вебинар: «Умное планирование производства в 1С:ERP на основе математической оптимизации» 16 апреля, 15:00 (МСК)

В программе:

• типовые механизмы планирования в 1С:ERP;

• кейс планирования в Excel;

• ограничения текущего подхода;

• блок «Почему 1С — это не APS»;

• подходы к реализации APS-систем;

• практические примеры.

Для участников заявлены:

• понимание границы типового планирования;

• понимание роли APS-подхода;

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

• 30 дней полной версии О2;

• запись и презентации.

Вывод

Если совсем коротко, то вывод звучит так:

ERP без APS-слоя умеет учитывать, но не всегда умеет выбирать лучший производственный план.

Именно в этой точке возникает потребность не в «ещё одной системе», а в механизме, который может:

• взять данные из 1С;

• учесть ограничения;

• просчитать сценарий;

• вернуть результат обратно в прикладной контур.

Для сложного производства это уже не nice-to-have, а вполне логичный следующий шаг развития архитектуры.