О методике планирования производства в 1С:ERP, по сравнению с классическими методиками

Авторы: Одиноков С., Лисин Н., Вепринцев А.

Известно, что в типовом решении 1С:ERP реализована передовая методика планирования производства. Алгоритмы планирования 1С:ERP при этом частично опираются на классические методики: MRP, APS, ТОС (ББВ). Можно ли сказать, что в 1С:ERP вошли лучшие концепции из этих теоретических моделей?

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

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

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

В каждом подразделении описываются виды рабочих центров (ВРЦ), имеющиеся в  подразделении, а также доступный суммарный плановый фонд времени работы ВРЦ.

В спецификации на этап производства указывается, рабочее время каких ВРЦ подразделения необходимо захватить при выполнении спецификации этапа. В спецификации этапа следует указывать только потенциально узкие места (ВРЦ) подразделения. В этом случае график межцеховых передач по заказу будет строиться согласно захвату времени работы этих ВРЦ, без учета тех ВРЦ, которые не являются узкими местами.

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

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

Программа выполняет последовательное планирование заказов по очереди заказов, по порядку. Временная ось разбивается на равные интервалы (например, сутки или недели – самые употребительные интервалы). Если выбран вариант планирования слева-направо, то система осуществляет поиск интервала планирования для размещения этапов производства правее даты «Начать не ранее» вперед по времени. В варианте справа-налево поиск интервала начинается от другой точки отсчета – слева от даты потребности, назад по оси времени.

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

Следующий этап размещается в следующем интервале, в котором есть свободное время необходимых ВРЦ. Таким образом, программа постепенно «поднимается» вверх по структуре изделия и определяет расчетную дату выпуска по заказу.

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

• Если раньше — все нормально.
• Если позже, диспетчер либо передоговаривается с клиентом на более позднюю дату, которая получилась при планировании, либо передвигает заказ по очереди вперед и перепланирует его, а заодно перепланирует и все последующие заказы очереди, так как этот новый заказ выталкивает из плановой загрузки оборудования последующие заказы, и даты их выпуска смещаются вправо. Получается более ранняя расчетная дата выполнения нового заказа. Заказ двигается вперед по очереди до тех пор, пока не получится расчетная дата выпуска, устраивающая клиента.
• Поскольку при перемещении заказа в очереди новый заказ может вытолкнуть расчетную дату выпуска других уже согласованных заказов вправо, то новые даты выпуска по последующим заказам тоже надо пересогласовывать с клиентами. В этом и кроется основная причина «нервозности» производства для APS-подобных систем.

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

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

Какие выводы можно сделать о достоинствах такой модели планирования, относительно классических методик?

С описанием классических определений и теоретических концепций планирования при желании вы можете предварительно ознакомиться в нашей отдельной статье …

Реализован ли в 1С:ERP алгоритм APS?

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

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

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

Важно, что загрузка ВРЦ  в данном случае учитывается именно в процессе планирования и непосредственно влияет на ход планирования (в MRP-системах загрузка мощностей тоже будет учтена, но уже постфактум – как констатация: получился ли план выполнимым или нет).

Можно считать, что такой расчет не позволит уплотнить загрузку ВРЦ настолько, насколько это позволяет APS. Поэтому может потребоваться дополнительная буферизация, искусственное занижение доступного фонда работы и не 100% загрузка оборудования в графике. И в этом смысле методика 1С:ERP ближе к MRP-системам.

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

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

Итак, можно утверждать, что алгоритм планирования производства 1С:ERP — нечто «среднее» между MRP и APS, компромиссный вариант.

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

Реализован ли в 1С:ERP алгоритм MRP/CRP/RCCP?

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

В первом случае на выполнение этапа будет выделяться фиксированное время, указываемое в спецификации и не зависящее от количества обрабатываемых изделий по заказу. Для этого в спецификации этапа надо снять флажок «Использовать виды рабочих центров». В этом случае мы получаем планирование по алгоритму MRP. Причем это будет достаточно усеченный MRP, поскольку длительность этапов распланированного заказа никак не зависит от количества готовых изделий в заказе. Например, на выполнение заказа из 1 шт. и 1000 шт. программа отведет 3 дня, согласно суммарной длительности этапов заказа. Также важно понимать, что расчет сроков обеспечения материалами осуществляется до процедуры расчета графика на основе данных обеспечения в цепочках поставок.

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

Во втором случае в настройках видов рабочих центров устанавливается переключатель в положение «Не учитывать ограничение». В этом случае длительность производства планируется исходя из плановой доступности вида рабочего центра, но это не является ограничением. В этом случае можно сказать о том, что мы получаем расчет по классическому алгоритму MPR + СRP, однако без учета загрузки рабочих центров.

Отметим, что результат расчета графика производства не полностью соответствует классическому определению результата планирования в MRP. Фактически мы получаем только график потребностей в материалах, но мы не получаем графика заказов на обеспечение этих потребностей (заказы на закупку и заказы на производство полуфабрикатов), поскольку процедуры обеспечения потребностей выполняются отдельно от расчета графика, а не являются его частью.

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

Реализован ли в 1С:ERP алгоритм ББВ (ТОС)?

Как отмечалось выше, в 1С:ERP можно использовать варианты:

1. Для этапа производства (в спецификации) можно настроить время работы ВРЦ (причем нескольких ВРЦ), которое захватывается этапом при обработке заданного в спецификации количества изделий и становится недоступным для других менее приоритетных заказов.
2. Указать, что этап производства выполняется фиксированное время для любого количества изделий и не захватывает время работы ВРЦ.

Если в производстве есть ярко выраженный узкий ВРЦ, то можно поступить проще: в спецификации, которая задействует этот «узкий» ВРЦ, достаточно указать потребное время работы этого ВРЦ (вариант 1), а в остальных спецификациях на полуфабрикаты в структуре продукта использовать фиксированное время выполнения этапа (вариант 2).

В результате:

Узкий ВРЦ будет «барабаном».

• Цепочка спецификаций перед барабаном с фиксированным временем выполнения будет «веревкой».
• Суммарное фиксированное (!) время выполнения цепочки спецификаций перед барабаном будет «предшествующим» временным буфером. В каждой спецификации важно указывать утроенное (как это рекомендуется в общем случае ТОС) фиксированное время обработки изделий. Иначе говоря,  время обработки изделия должно соответствовать суммарному времени операций на количество, указанное в спецификации на барабан.
• Суммарное фиксированное (!) время выполнения цепочки спецификаций после барабана будет «завершающим буфером».

Пример: если барабан способен обрабатывать 100 шт в час, то во всех предшествующих спецификациях (этапах) проставляется фиксированное время обработки: временной норматив на обработку 100 шт умноженный на 3.

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

Получаем ББВ в чистом виде!

У этой методики возможны следующие расширения:

1.Если в структуре продукта на разных уровнях есть несколько потенциально узких ВРЦ, то в соответствующих этапах (спецификациях) вводится потребное время работы этих ВРЦ. В результате получаем планирование цепочки узких ВРЦ, загружаемых последовательно при выполнении заказа. Например, если заданы два «узких» ВРЦ в разных подразделениях (т.е. разных этапах-спецификациях) и заказ проходит последовательно через эти ВРЦ, то планироваться будут три буфера:

• предварительный перед ВРЦ1
• промежуточный между ВРЦ1 и ВРЦ2
• завершающий после ВРЦ2

2. Иногда при обработке изделия в цехе задействованы параллельно два узких ВРЦ — например, станок и оператор. Оба ВРЦ являются узким местом, но график работы у них разный. То оператор уходит на больничный, то станок встает на ремонт. Возможна ситуация, когда оператор одновременно обслуживает два станка — это значит, что потребное время оператора в спецификации будет равно половине потребного времени работы ВРЦ.

Пример. Нормативное время загрузки ВРЦ на этапе составляет10 часов, а оператора, обслуживающего этот ВРЦ — 5 часов. Это значит, что 2 станка работают параллельно по 10 часов, а один оператор работает 10 часов на двух станках одновременно (так называемый «многостаночник»). В спецификации этапа можно указать два и более ВРЦ с разными потребными временами для выполнения спецификации. Получаем несколько параллельно работающих «барабанов» в цехе (например, станок +оператор), работу которых программа будет загружать, исходя из доступного фонда их рабочего времени.

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

Узкий ВРЦ указывается непосредственно в спецификации. Если ассортимент выпускаемой продукции большой, то необходимо убедиться, что в каждой спецификации ВРЦ (один или несколько) указан правильно.

Если возможна миграция ВРЦ с некоторой даты (например, из-за изменения состава ассортимента продукции), то, скорее всего, придется переделывать действующие спецификации с этой даты — а именно, менять ВРЦ в спецификациях, если ВРЦ, который стал узким, в списке потенциально узких ВРЦ в спецификации не присутствует.

Получается, что правки спецификаций приходится выполнять не из-за изменения технологии изготовления отдельного продукта, а из-за изменения ассортимента выпускаемой продукции, что нелогично и неудобно. При изменении «узкого ВРЦ» необходимо зайти во все спецификации и выяснить у технологов (или извлечь из PDM-системы) операционные времена ВРЦ, которые теперь стали узкими. После этого операционные времена (потребности во времени работы) ВРЦ , которые стали «узкими», надо вписать, а потребности во времени работы ВРЦ, которые перестали быть узкими — удалить.

Суть этого решения заключается в следующем: в спецификации описываются все потребные времена работы всех ВРЦ (согласно пооперационной техкарте), как узких, так и не узких. Эта информация стабильна; ее проще актуализировать и поддерживать синхронность с PDM-системой. Не нужно вводить несколько комплектов одинаковых по сути спецификаций и дублировать информацию; не нужно при очередной миграции заходить во все спецификации и заменять в них ВРЦ. «Узкие» ВРЦ назначаются на подразделение экспертным путем отдельным документом с заданной даты, с которой предполагается миграция. При расчете графика производства по заказу программа захватывает время работы только тех ВРЦ, которые на дату планирования считаются узкими по подразделению.

Заключение

В этой статье мы постарались изложить основные моменты методик, опуская все подробности. Разумеется, в APS, MRP и ББВ существует множество нюансов, о которых можно прочитать в специальной литературе. Мы не ставили целью детально описать функционал планирования 1C:ERP, а лишь хотели показать, насколько близка реализация планирования производства 1С:ERP к классическим методикам.

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

• полностью реализована методика ББВ, с некоторыми ее модификациями;
• реализована простая модель MRP (длительность этапа не зависит от размера заказа);
• в упрощенном, оригинальном виде реализована APS (расчет не по операциям,  а по совокупному агрегированному времени захвата мощностей этапами производства).

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

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

[evc_social_likes]