Какая методика планирования производства реализована в 1С:ERP 2.1 согласно определениям?

Всем известно что в типовом решении 1С:ERP реализована революционная методика планирования производства. Но как она соотносится с классическими методиками MRP, APS, ТОС (ББВ)?

Авторы: Лисин Н.Г., Одиноков С. И. (фирма «ИТРП»)

Правда ли, что 1С:ERP использует методы теории ограничений ТОС ( «Барабан-буфер-веревка»)?

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

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

Прежде чем приступить к обсуждению этого вопроса, вкратце напомним, в чем суть, преимущества и возможная область использования методов расчета сквозных межцеховых графиков производства MRP/CRP, APS, ББВ (ТОС, DBR).

MRP/CRP/RCCP (Material Requirements Planning, Capacity Requirements Planning, Rough-Cut Capacity Planning)

График межцеховых передач изделий рассчитывается от плановой даты выпуска изделия по заказу назад во времени (справа -> налево). При этом программа исходит из структуры дерева продукции (дерево конечной продукции разворачивается назад во времени простым разузлованием) и суммарного времени выполнения всех операций над полуфабрикатами (компонентами) в цехах.

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

Можно сделать так, что записываться будут потребности во времени работы только тех мощностей, которые признаны логистами потенциально узкими местами. Это позволит не перегружать систему информацией (методика RCCP).

MRP-CRP2

Также в системе CRP/RCCP содержится информация о доступном фонде времени работы производственных мощностей в каждом интервале, а именно:

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

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

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

  • Положительное значениедефицит 
  • Отрицательное значение — профицит (избыток мощности).

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

CRP1

Таким образом, методика MRP/CRP/RCCP позволяет увидеть дефициты мощностей «постфактум» после процедуры планирования,  но не предлагает выполнить распределение заказов по оси времени, чтобы  эти дефициты устранить. Такая разводка заказов по датам делается логистами вручную на основании их опыта и приоритетов заказов. Далее все заказы перепланируются и снова проверяются на наличие дефицитов.

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

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

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

Такая схема не вызывает особых проблем, если, исходя из принятых заказов клиентов, производство по мощностям загружено не более, чем на 70%. Иначе говоря, «главное продать, а произвести всегда сможем». Неточность планирования сглаживается оставшимися 30%-ным доступным временем работы мощностей.

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

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

Пример такой системы — Модуль планирования и диспетчеризации для 1С:УПП от ИТРП. Также в таком режиме может работать 1С:ERP (режим спецификаций "Не рассчитывать загрузку РЦ").

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

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

Например, если агрегат собирается не менее 10 дней, то новые заказы принимаются не менее чем за 10 дней (при наличии всех материалов). При монопроизводстве (один вид продукции) можно применять еще более простой критерий — например производство может выпускать не более 1 тонны пельменей в сутки…

ATP-MRP

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

При сезонном характере спроса планирование может быть выстроено неоптимально: в сезон низкого спроса производство недогружено, а в сезон высокого спроса — аврал.

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

Для полноты изложения отметим, что при более пристальном рассмотрении вопроса методология  CRP распадается на два подраздела:

  • RCCP (Rough-Cut Capacity Planning). Предварительное планирование производственных мощностей. Процедура  быстрой проверки дефицитов нескольких ключевых мощностей (потенциально «узких» мест) . Смысл выделения этой процедуры только в высокой ее скорости, так как проверяются  не все мощности, а очень ограниченный их перечень.

  • FCRP (Finite Capacity Resource Planning). Окончательное планирование производственных мощностей. Процедура проверки дефицитов всех производственных мощностей.

APS (Advanced Planning and Scheduling)

В ситуации, когда потенциальным ограничением продаж продукции является производство, решением (достаточно относительным) является метод APS.

Главное отличие APS  от MRP/CRP заключается в следующем: при расчете графика межцеховых передач полуфабрикатов программа опускается до технологических операций и планирует операции на конкретные единицы оборудования, захватывая время их работы. Продвинутые APS-системы захватывают также время работы персонала и прочие ограничения производства (время работы оснастки и т.д.).

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

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

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

Можно сказать, что APS-система строит сквозное (по всем цехам) пооперационное расписание работы оборудования для выполнения заказа на уровне глобального диспетчера, снимая эту задачу с цеховых диспетчеров.

APSграфик

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

  • Справа-налево (операции назначаются на временную ось как можно позже, туда, где есть свободное время мощностей). Минусы: срыв графика операций подразделением неминуемо приводит к просрочке даты выполнения заказа. В результате возникает необходимость перепланирования и, как следствие, смещение дат выпуска по заказам, либо сверхурочная/авральная работа. Нервозность графика, перенасыщенность дедлайнами,  высокая «напряженность» производственных партий.
  • Слева — направо (операции назначаются на временную ось как можно раньше, туда, где есть свободное время мощностей, но не раньше даты начала производства, отмеченной в заказе). Минусы: потребности в материалах наступают раньше, чем это реально нужно для выполнения заказа. В целом, это более оптимальный режим, особенно при недозагруженном производстве и неограниченном сроке хранения продукции. Лучше начать выполнять заказ заранее, чтобы гарантированно успеть к сроку.

APS222

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

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

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

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

Примеры таких систем — решения <<Оптипром>> и <<ИТРП:Процессное производство 8>>.

Казалось бы, чего еще желать? Такая система представляется идеальной. График загружает производство на максимальную мощность,  производство согласно графику работает ритмично (без авралов и простоев), реализация за период выводится на максимально возможный объем, клиенты довольны — в результате точного планирования заказы выполняются в срок, моментально определяются возможные сроки выполнения заказа.

Однако не все так просто. В теории — красиво. А на практике возможны проблемы:

  • В результате распределения операций заказов по времени работы оборудования может (к примеру)  наблюдаться следующая картина:  первый заказ с выпуском на 10-е число номенклатуры Х 10 шт. распределился на три дня с запуском 7-го, а второй заказ с выпуском на 20 -е число той же номенклатуры и количества запускать надо уже завтра — он распылился на двадцать дней. Диспетчеру цеха такой график может показаться странным. Зачем запускать 2-го числа, если сдавать 20-го, а цикл производства длится три дня? Такой график может получиться из-за оптимизации переналадок, а также по другим не вполне понятным диспетчеру причинам.
    • Налицо неравномерное сложно  пересекающееся распределение операций заказов разных приоритетов во времени, не всегда очевидное диспетчерам, а значит, существует опасность ухода диспетчеров от этого графика. Многие, вероятно, потребуют у глобального диспетчера просто дать график сдачи изделий по заказам, «а какие операции когда запускать  - с этим мы сами разберемся». Все-таки на уровне глобального диспетчера (межцеховой график) сложно учесть все внутрицеховые нюансы..

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

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

    Примеры (разумеется, это лишь малая часть):

  • ПриказНачальника
    • Токарь Иванов сегодня не в настроении и ему не нужно доверять ответственную деталь, а токаря Козлова нельзя подпускать к старому станку — у него повышенная конусность и он запорет заготовку.  
    • На одном из наших проектов APS — система, как оказалось, не умеет соединять станки в производственную линию как один поточный РЦ (таково требование технологии), с удалением этих станков из фонда доступной мощности. Описать эту совокупность РЦ как один РЦ тоже нельзя — для других изделий они планируются отдельно…
    • Проблема с сопряженными деталями: нельзя сверлить крышку пока не просверлен корпус, хотя крышка и корпус находятся в разных ветках дерева продукции и соединяются лишь на сборке.
    • Сложности возникают с передачей по кооперации на сторону или в другие цеха при нехватке мощностей.
    • Печь может работать не только в синхронном, но и в асинхронном режиме. Она выводится на заданную температуру, а дальше заготовки закладываются и вынимаются не синхронно (одной загрузочной партией), а в разное время, согласно длительности термообработки каждой заготовки.
    • Такие ситуации опытный локальный диспетчер разруливает без проблем, тогда как программа на это не способна. Для этого требуется искусственный интеллект. Вот почему системы, которые дают диспетчеру ориентировочный график сдачи изделий и оставляют простор для творчества при планировании операций внутри цеха, более устойчивы и менее нервозны. APS-система во многом лишает диспетчера цеха возможности маневра и самостоятельности в учете нюансов.
  • APS-системы основаны на сложнейшей математике – в частности,  генетических алгоритмах. Самые простые APS-системы используют эвристические  жадные алгоритмы. В любом случае, воспроизвести (просчитать) результаты планирования вручную невозможно, как невозможно объяснить  опытному логисту, почему программа распланировала именно так, хотя есть другой, более оптимальный план. Действительно, никаких гарантий, что  программа найдет в тысяче вариантов плана самый оптимальный, нет.
  • И наконец, посчитаем сколько плановых операций APS-система должна планировать на месяц вперед.
    • Например, 1000 заказов на готовую продукцию в месяц, по каждому — 1000 операций по всем цехам. Получаем миллион операций, которые необходимо рассчитывать, оптимизировать и записывать в базу данных, скорее всего, ежедневно, а значит на процедуру планирования при трехсменном режиме работы отводится полчаса — час.

Итак,  основными недостатками APS-систем являются:

  • Невозможность учесть все производственные параметры для точного расчета графика. Если для MRP неточный график — это нормально, то для APS — губительно, так как подразумевает неисполнимость графика и его постоянное перепланирование. А это нервозность и неритмичность производства.
  • Организационная сложность в создании, оцифровке нормативной системы (спецификаций, маршрутных карт). Приведение того что есть на предприятии, к формату который требует APS, непрерывная поддержка актуальности этих данных.
  • Высокая требовательность к быстродействию и объемам хранилищ данных.

Если эти недостатки не проявляются на конкретном производстве, то APS-система является абсолютной рекомендацией к использованию.

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

MES (Manufacturing Execution System)

Для полноты картины отметим еще MES-системы. Провести четкую грань между APS и MES-системой не всегда просто. Этой теме посвящено множество исследований.

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

MES

Характерными особенностями MES-систем можно считать:

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

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

ТОС, ББВ/DBR (Теория ограничений систем, «Барабан-буфер-веревка», «Drum, buffer, rope»)

Данная методика является поистине революционной и не сразу была признана корифеями. Создана всемирно известным исследователем Элияху Голдраттом.

ББВ1

Данная гениальная методика бросает вызов традиционным методикам и призвана не только устранить недостатки APS и MRP, но и объединить их достоинства.

ББВ основана на следующих очевидных предпосылках:

  1. Производство чаще всего не является полностью сбалансированным. Пропускную способность производства для каждого вида продукции ограничивает лишь один вид производственного ресурса (мощности). Например некий уникальный дорогой станок. Исключение — поточные и непрерывные  производства, в которых каждый РЦ потока полностью сбалансирован с другими РЦ. Но это не случай ТОС, и  даже не случай когда требуется детальное планирование производства.
  2. Нет смысла детально планировать каждый производственный  участок. Достаточно точно распланировать участок с узким производственным ресурсом — «барабаном«. Это будет основной такт производства. График работы барабана соблюдается неукоснительно. Он должен быть загружен непрерывно с минимумом переналадок. Это значит, что производство загружено максимально.
    • Очевидно, что остановка барабана — эта остановка деятельности всего предприятия. Рассчитать дату выполнения заказа очень просто: для этого нужно назначить обработку заказа на один РЦ — барабан — захватив время его работы. Расписание обработки заказов на один рабочий центр можно составить в Excel.

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

  4. График должен быть таким, чтобы перед барабаном всегда находилась непустая очередь изделий. Это обеспечит непрерывность его загрузки. Чтобы очередь была непустой, исходные материалы надо запускать в производство гораздо раньше, чем того требует длительность обработки до барабана. Например, время такого опережения запуска материалов может быть в 3 раза больше длительности обработки до барабана. Такое время опережения называется временным  «буфером«.
  5. Нет смысла контролировать своевременность сдачи всех изделий цехами. Достаточно контролировать, какие изделия вышли из «зеленой зоны» — т. е. не поступили в очередь к барабану своевременно согласно производственному циклу. Такие изделия/заказы требуют контроля и вмешательства диспетчера.
    • Используется принцип светофора. Если заказ в «зеленой зоне», не обращаем на него внимания. Если заказ в «желтой зоне» — т. е. прошло уже 1/3 буфера, но не более 2/3 буфера, а заказ так и не  вышел к барабану — начинаем разбираться, почему возникла задержка. Если заказ в «красной зоне» — т. е. прошло более 2/3 буфера, а заказ так и не вышел к барабану — срочно вмешиваемся, иначе расписание работы барабана нарушится. Разумеется, за счет других заказов в очереди барабан, скорее всего, не остановится, что говорит о большой устойчивости системы.

ББВ3

Между барабаном и выпуском готовой продукции могут быть выпуски промежуточных полуфабрикатов — в этом случае при планировании необходимо учитывать «завершающий буфер». Другими словами, от обработки на барабане до выпуска готового изделия проходит некоторое фиксированное время, которое учитывается (добавляется) при планировании. Например, если продукцию по заказу надо выпустить 10-го числа, а завершающий буфер — 3 дня, то работа барабана для обработки заказа планируется на 7-е число.
ББВ2

К сожалению, ББВ тоже не является абсолютно универсальной методикой.

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

Итак, мы рассмотрели 3 основные методики планирования. Каждая из них имеет свои плюсы и минусы. У каждой есть свои ограничения. Возможно ли найти универсальную методику, своего рода «золотую середину», обладающую плюсами всех остальных методик, но лишенную их недостатков?

Решаема ли эта задача? Не сродни ли она попыткам средневековых алхимиков превратить свинец в золото или изобрести вечный двигатель?

Поиски «философского камня» в 1С:ERP…

Алгоритм планирования производства 1C:ERP

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

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

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

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

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

ВРЦ состоит из отдельных РЦ, но при планировании учитывается суммарный фонд времени ВРЦ.

В спецификации на этап производства указывается:

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

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

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

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

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

ЕРП

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

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

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

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

Какие выводы можно сделать?

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

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

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

К чему это приводит, покажем на простом примере:
На этапе в одном подразделении выполняются две операции — № 1 и № 2. Интервал планирования — день. Операции выполняются последовательно. Согласно количеству, указанному в заказе, Операция № 1 требует 24 часов времени работы ВРЦ 1, а Операция №2 требует 12 часов времени работы ВРЦ 2. Каждый день доступно по 8 часов работы ВРЦ 1 и ВРЦ 2 . Программа расположит этап производства в трех интервалах (днях), так как считает, что всего требуется 24 часа — по большему времени обработки на ВРЦ 1. При этом на первый день программа назначит 8 часов ВРЦ 1 и 4 часа ВРЦ 2, на второй день — 8 часов ВРЦ 1 и 4 часа ВРЦ 2, а на третий день — 8 часов ВРЦ 1 и 4 часа ВРЦ 2. Получается, что работа ВРЦ 2 распланирована параллельно с ВРЦ 1.

Разумеется, организовать параллельную работу ВРЦ 1 и ВРЦ 2 не всегда возможно. В лучшем случае можно выполнить последовательно-параллельную обработку, используя небольшие передаточные партии. Если же обработке в течение 24+12 часов подлежит одна деталь, то на первую операцию потребуется 24 часа, а на вторую 12 часов. Следовательно, за 3 дня этап выполнить не удастся: на это потребуется 5 дней (3+2), но программа запланирует всего 3 дня. Иными словами, график, который сформирует программа, окажется невыполним.

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

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

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

Как было показано в предыдущем разделе, потребности в мощностях рассчитываются непосредственно в процессе планирования с захватом свободных мощностей, а не «постфактум», как это предусмотрено в CRP/RCCP. В дальнейшем всегда можно посмотреть отчет о потребностях в ВРЦ, рассчитанных при планировании. Таким образом, эта функция CRP/RCCP формально поддерживается.

Однако отчет не удастся посмотреть при использовании режима MRP, так как в этом режиме система ничего не знает о потребностях в мощностях — эти потребности в спецификации не указываются. При планировании в режиме захвата времени ВРЦ получается в принципе бездефицитный график, так как, по сути, формируется расписание захвата ВРЦ по их свободному времени. В этом случае можно посмотреть только отчет «справочно» по потребностям во времени работы ВРЦ, без дефицитов и профицитов. В целом, можно сказать, что концепция CRP/RCCP в 1С:ERP при работе в режиме MRP не реализована.

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

О чем это говорит? Дело в том, что изначально такой режим спецификаций, по-видимому, не предназначался для работы по MRP-алгоритму. Данный режим настройки спецификаций предназначался, скорее всего, для реализации метода «ББВ» в межцеховом планировании.

И здесь начинается самое интересное!

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

Сначала определимся на каком уровне мы рассматриваем планирование в 1С:ERP по методике ББВ. Забудем внутрицеховое управление маршрутными листами, в котором используются так называемые «ключевые ВРЦ». Данная статья посвящена исключительно межцеховому планированию.

Поэтому вопрос формулируется так: реализовано ли в 1C:ERP межцеховое планирование по методике ББВ?

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизации времени переналадки барабана

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

Особенности в реализации ББВ в 1С:ERP в межцеховом планировании

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

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

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

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

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

Это решение имеет свои издержки — например, сложность в синхронном внесении изменений в одинаковые спецификации, отличающиеся лишь описанием в потребности времени работы узких ВРЦ. Все остальное — материалы, трудозатраты и так далее — одинаковы. Если нарушение принципа «Одна информация вводится один раз» не смущает, так вполне можно работать.

Решение проблемы миграции ВРЦ содержится в дополнении ИТРП VIP:1C ERP.

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

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

Подробнее об этой методике>>>

Реализовано ли сквозное планирование по всем цехам в 1С:ERP?

Осталось рассмотреть еще один интересный вопрос — вопрос сквозного планирования межцехового графика по всей структуре продукта (дереву изделия).

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

В одной процедуре планирования формируются запуски-выпуски всех полуфабрикатов в структуре готового изделия и все потребности в материалах.

При этом продвинутые APS и MRP декларируют учет запасов НЗП и различают потребности в полуфабрикатах брутто (валовая потребность) и нетто (чистая потребность).

  • Потребность брутто — сколько всего надо потребить полуфабриката или материала для выпуска другого полуфабриката или продукции
  • Потребность нетто — сколько надо выпустить полуфабриката, с учетом накопленного остатка в НЗП, чтобы покрыть потребность брутто.

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

Кроме того, учет остатков НЗП при планировании может потребоваться в случае, когда под потребность по заказу планируется к выпуску большее количество, чем требуется.

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

Дело в том, что сначала потребность брутто погашается за счет остатка НЗП, а если остатка НЗП не хватило, то возникает потребность нетто, которая и планируется к выпуску.

Решение этой задачи достаточно сложно и приводит к множеству коллизий.
Например, изменение даты выпуска заказа и, как следствие, перепланирование графика по заказу (если потребности этого заказа удовлетворялись за счет остатков НЗП) может привести к внезапной неисполнимости заказа и большому росту потребности во времени работы ВРЦ по заказу. Особенно это вероятно в том случае, если на новую дату выпуска по заказу планово-расчетные остатки НЗП в нужном количестве не обнаружены.

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

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

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

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

Пример. В производстве три последовательных участка- передела №1, №2, №3. После участков 1 и 2 появляются остатки НЗП полуфабрикатов, которые надо учесть при планировании. В результате флажок «Производится в процессе» во всех спецификациях нужно снять. Сначала логист рассчитывает график работы участка №3. Получается потребность в полуфабрикатах №2, выпускаемых участком 2.

В мастере-помощнике логист создает новые заказы на производство полуфабрикатов участка 2 с учетом текущих остатков этих полуфабрикатов и потребности в них участка 3, после чего снова запускает процедуру расчета графика на производство по заказам на участок 2. Получается потребность в полуфабрикатах, выпускаемых участком №1. Логист создает новые заказы на производство с учетом текущих остатков полуфабрикатов № 1 и потребности в них участка 2, и опять запускает процедуру расчета графика на производство по заказам на участок 1. В итоге получается потребность в исходных материалах.

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

Итак, если нужно учесть остатки НЗП, то автоматизированный сквозной расчет графика по всем участкам сразу «одной кнопкой» по всем подразделениям от продукции до материалов в 1С:ERP не получается!

Чем это чревато?

  1. В первую очередь, если заказы на выпуск конечной продукции нестабильны,  а  их даты и состав могут корректироваться,  придется перепланировать график по этим заказам, после чего открыть мастер-помощник и каскадно переформировать все зависимые заказы на производство в несколько итераций – другими словами, заново пройти вручную все итерации планирования. Делать это придется  при любой корректировке заказа на выпуск готовой продукции.
  2. Кроме того, если на каком-то переделе  потребовалось учесть ранее не учитывавшиеся остатки НЗП, нужно разъединить между собой спецификации соседних уровней снятием флажка «Производится в процессе», тем самым добавляя еще одну итерацию планирования. Приходится констатировать, что спецификации в 1С:ERP помимо технологических данных включают в себя логистическую составляющую, которая может быть более динамичной (изменчивой во времени). Из-за этого спецификации придется иногда не просто править, но и кардинально пересматривать их структуру, хотя технологические данные не изменились.

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

Заключение

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

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

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

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

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