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

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

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

Почему график производства в 1С:ERP не сходится: четыре картины

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

1. Этапы «разъехались» по дням

Подготовка 2 часа, варка 3 часа. Интервал планирования — день. Система ставит первый этап на сегодня, второй — на завтра, потому что считает доступность целыми интервалами, а не стыкует минуты. Планировщик видит трёхдневный цикл там, где работы на одну смену — и перестаёт верить графику.

2. Переналадка есть в справочниках — но не в графике этапов

Матрица переналадок в 1С:ERP есть: регистр «Длительность переналадки» хранит время перехода для вида рабочего центра по паре «текущий вариант наладки → следующий». Описать «с продукта А на продукт Б — сорок минут мойки, с Б на А — ноль» система позволяет.

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

3. «Первое допустимое» вместо разумного

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

4. Перепланировать один этап — целая операция

Этап производства в 1С:ERP — одновременно плановый и учётный документ: он двигает десятки регистров, включая себестоимость и незавершённое производство. Сдвинуть один этап руками — значит распровести и перепровести цепочку. На форумах это называют «танцами с бубном», и именно поэтому график боятся трогать: цена ошибки — не в плане, а в учёте.

Где ломается планирование производства в ERP: пищевое, фарма, химия и другое процессное производство

Процессное производство устроено не как последовательность операций над деталью, а как цикл: сварили партию — разлили — сварили следующую. У него четыре особенности, которых типовой планировщик не видит.

Ёмкость — это ресурс, а не станок

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

Партия и рецептура вместо детали и спецификации

Объём партии задаётся ёмкостью, а не заказом. Заказ на 7 тонн при котле на 10 — либо неполная варка, либо две партии с остатком. В процессном производстве часто заводят столько спецификаций, сколько ёмкостей, и получают справочник, с которым невозможно работать. Это симптом: система просит описать процесс в чужих терминах.

Переход между продуктами зависит от пары «что было — что будет»

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

Загрузка считается в тоннах на линию в сутки, а не в заказах

Планировщик на пищевом или фармзаводе думает не «какой заказ следующий», а «сколько тонн какого продукта линия выпустит в смену». Заказы клиентов и план продаж раскладываются в суточную загрузку линий. Типовой заказ на производство с этапами эту логику воспроизводит с трудом — поэтому рядом с ERP почти всегда появляется свой АРМ диспетчера или Excel с макросами.

Номинальная скорость против реальной: почему график по паспорту невыполним

Это самая недооценённая причина, и она не зависит от отрасли. В спецификации записана производительность линии — паспортная или расчётная. График строится по ней. Но реальная линия останавливается: переналадки, мойки, мелкие простои, ожидание сырья, брак, замедленный ход. Совокупная эффективность оборудования — OEE — у обычного производства составляет 50–65 %. Линия за смену делает чуть больше половины того, что записано в её паспорте.

График, посчитанный по номинальной скорости, при OEE 60 % невыполним всегда: в него заложено на 40 % больше выпуска, чем линия физически даёт. Планировщик держит эту поправку в голове, внедренец — нет. Система показывает, что заказ будет готов в среду, производство знает, что в пятницу, и через месяц графику никто не верит.

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

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

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

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

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

Матрица переходов и мойки: почему одного времени наладки мало

Для процессного производства правило переналадки — таблица «из продукта А в продукт Б — столько-то минут». Все соусы ко всем соусам, все препараты ко всем препаратам. Часть клеток — ноль, часть — сорок минут мойки, часть — запрет перехода вообще. В 1С:ERP для такой таблицы есть штатное место — регистр «Длительность переналадки» по парам вариантов наладки. Вопрос в том, кто её читает: межцеховой график — нет, только пооперационный контур, который процессному производству не нужен.

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

Что не считать рабочим центром

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

Правило простое: рабочий центр — то, что реально ограничивает выпуск и за что конкурируют партии. Ёмкость варки, линия розлива, иногда — конкретный сотрудник, если он один умеет вести процесс. Всё остальное — свойство этапа, а не отдельный ресурс. Буферная ёмкость на 2–3 тонны перед линией — часть линии, а не склад. Чем тоньше модель, тем точнее график.

Как модуль планирования 1С:ERP считает график производства: механика для тех, кто хочет проверить

Ни в документации, ни на курсах это обычно не описывают простыми словами. Производственное планирование 1С:ERP на межцеховом уровне — планирование ERP 2.5 по этапам — считается так.

1. Очередь. Проведённые заказы на производство — в очередь: приоритет, затем подразделение, затем порядок. Планировщик берёт их по одному.
2. Этапы по цепочке. Внутри заказа этапы размещаются последовательно: каждый после предшественников — или, при планировании «к дате», назад от даты потребности.
3. Первое свободное место. Для этапа ищется первый интервал, где у вида рабочего центра хватает доступности. Нашёл — занял.
4. Интервал — день или час. Мощность считается как «вид рабочего центра × интервал», не по конкретному станку и не в минутах.
5. Материалы — флаг, а не ограничение. График отмечает необеспеченность, но не ждёт поставку; двигать ли этап — решает диспетчер.
6. Перепланирование — регламентное. Пересчёт идёт через очередь заданий; при сотнях заказов это не онлайн.

Ключевое слово — по одному. Это не оптимизатор, а размещатель: первое допустимое расписание, а не лучшее. Оптимизация — варианты расписания, минимизация переналадок — есть только на пооперационном уровне и только внутри окна модели.

Динамическое и пооперационное планирование в 1С:ERP 2.5: когда нужно, а когда нет

Динамическое планирование производства в 1С:ERP 2.5 — структура заказа, при которой этапы рассчитываются по мере выполнения предыдущих, а не все сразу. Полезно, когда заказ длинный и на старте неизвестно, как пойдут первые этапы. Способ расчёта оно не меняет: динамическое планирование производства в ERP не добавляет ни учёта ёмкостей, ни переходов между продуктами — это тот же планировщик, включённый позже.

Пооперационное планирование 1С:ERP 2.5 — расписание по конкретным станкам внутри этапа: маршрутные карты, нормы на операцию, варианты наладки, данные по каждому рабочему центру. Именно здесь, и только здесь, работает матрица переналадок и правило «минимизировать переналадки» при выборе станка. Выигрыш это даёт там, где внутри этапа много операций на разных станках — в машиностроении, приборостроении, металлообработке. Там же уместны оперативное планирование ERP по сменам, диспетчеризация и сменные задания по операциям.

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

Когда типового планирования в 1С:ERP хватает — и когда нужен свой алгоритм

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

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

«Свой» не значит «вместо ERP». Типовые объекты — заказ на производство, этапы, ресурсные спецификации, рабочие центры, доступность — остаются, и вместе с ними весь учёт, себестоимость и НЗП, которые на них держатся. Меняется только то, как этапы расставляются во времени: с ёмкостью как ресурсом, с матрицей переходов на уровне этапов, с планированием от розлива назад и с реальной, а не номинальной скоростью линий. У нас такой алгоритм расчёта этапов есть — он работает поверх типовых объектов 1С:ERP и не требует ни замены планировщика, ни включения пооперационного контура.

Как это делается и сколько стоит — на странице внедрение 1С:ERP на производстве, там же про достройку уже работающей ERP.