MRP не работает… Какая альтернатива?

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


    Альтернатива MRP: синхронное планирование и оптимизация ?



    Введение


    Многолетние усилия поставщиков информационных систем ERP (Enterprise resource planning — планирование ресурсов предприятия) класса в России наконец-то завершились успехом: руководство значительной доли отечественных предприятий уверены, что такие системы им необходимы, поскольку они действительно могут ( как заявляется) решить проблемы планирования производства и снабжения. Российские ведущие разработчики один за другим анонсируют наличие в своих системах функций планирования и управления производством, соответствующих «стандарту» MRP-II (Manufacturing Resource Planning — , планирование ресурсов производства). В различных отраслях промышленности даже начинают появляться предприятия, внедрившие ERP системы и пытающиеся управлять с их помощью производством. Однако планировать с их помощью почему то оказывается сложнее, чем прежде. Почему? Многоопытные консультанты заявляют, что причина в том, что «…не та культура производства, неточные спецификации и техпроцессы, постоянные конструкторские изменения, неоперативное отслеживание уровня запасов…», и, о, ужас, «…нет агрегированного стратегического и/или мастер планирования».

    Все это так, но многие ли задавались вопросом: все ли западные методы управления (особенно 30-и летней давности) так хороши, как преподносится? Одно дело планировать работу западного предприятия в 50 – 100 человек, долго и успешно работающего в стабильном окружении, другое дело «вертеться» в российских условиях, управляя встающим на ноги промышленным гигантом, или молодым развивающимся заводом, скорости реакции которого на изменение спроса позавидовали бы многие западные конкуренты. Возможно, корни многих неудачных внедрений ERP систем на российских промышленных предприятия лежат именно в попытке использовать для планирования несовершенный алгоритм, который эффективен, только тогда, когда «все хорошо»?
    Сейчас мало кого удивишь или заинтересуешь подробным описанием алгоритмов расчета потребностей и планирования. Тем не менее, автор взял на себя смелость еще раз кратко описать алгоритм работы MRP планирования и разобрать, почему же он в практическом применении не эффективен на многих наших реальных предприятиях. Более того, это не просто отторжение того, что всем хорошо известно, и предлагалось, в частности когда-то и автором. В статье предлагается другой алгоритм планирования, лишенный традиционных недостатков MRP II. Данный метод может быть применен для любого предприятия с дискретным производством или непрерывным производством, которое может быть сведено к дискретному.

    Планирование ресурсов по MRP-II. Что не так?


    Напомним кратко принципы расчета потребностей по MRP-II алгоритму.

    Начальные данные:

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

    Планирование

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

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

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

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

    Алгоритм выглядит достаточно целостно и логично. И в теории это действительно так. Если еще его разобрать на примере производства реального изделия (фонарик, лопата, стол, велосипед, компьютер, и т.д.) сомнений никаких вообще не остается: нам это подходит. Но постойте! Для того, чтобы производить фонарик или лопату, собирать из основных блоков компьютер, автоматизированный расчет потребностей может производиться с помощью таблиц Excel’я. Таким предприятиям не нужна сложная автоматизированная система планирования. MRP же функции расчета потребностей стремятся использовать российские предприятия, производящие довольно сложные изделия.

    И в этом случае, на практике MRP-II расчет никак не может им помочь. Почему? Потому, что…

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

    Правда, в этом случае системой будут сформированы сообщения по исключениям. Однако, на практике их может быть такое количество, что для их «разбора» реального времени, отпущенного на планирование, может просто не хватить. Рассмотрим среднестатистическое российское промышленное предприятие с общей численностью примерно 500 человек. Допустим, оно принимает в среднем несколько десятков заказов клиентов в день и выпускает изделия «сложнее велосипедов», т.е. имеющих спецификацию, состоящую из нескольких десятков строк. Этим условиям отвечает большинство российских промышленных предприятий практически всех отраслей промышленности. Для него отклонения от идеальности количество исключений после каждого запуска MRP будет исчисляться сотнями записей. «Счастливые» пользователи систем с MRP-II алгоритмом планирования с этим фактом хорошо знакомы. В итоге: план нереальный.

    2. MRP планирует без учета реальной загрузки ресурсов. При планировании назад используется стандартное фиксированное время опережения, т.е. общее непооперационное время производства. То, что какой-либо рабочий участок может быть занят в это момент времени алгоритм не учитывает. Существует однако выход: запуск функции CRP (Capacity Requirement Planning – планирование производственных ресурсов), с помощью которой чаще всего удается «расшить» узкие места. При этом, как правило, меняются и сроки производства всех планируемых системой деталей. Т.е. после запуска функции CRP необходимо перезапустить MRP, который опять сформирует план производства без учета сегодня и ограниченности ресурсов. И так – по кругу…

    В теории, такие последовательные приближения при формировании планов, вполне осуществимы. Однако, как правило, в практике российских предприятий, когда мы решаем задачи планирования для десятков и более изделий имеющих, как правило, более пяти уровней вложенности и состоящих из десятков – сотней — тысяч узлов, деталей, компонентов в итоге такого планирования все равно получается нереальный план. Не говоря уж о том, что при расчете загрузки мощностей (CRP) невозможно автоматизированное планирование с учетом альтернативных маршрутов а сам расчет (CRP или MRP-расчет) при конечных вычислительных мощностях будет длиться не один час. Конечно, скорость расчета зависит от ПО и вычислительных мощностей. Но на основе практического опыта, автор может заключить, что для среднего машиностроительного предприятия с базой данных в 30 тысяч изделий (что не так уж и много для наших машиностроителей), узлов, деталей, материалов и комплектующих, производящий изделия, имеющие 5 – 7 уровней вложенности, MRP и CRP расчет в среднем будет занимать около 4х часов каждый.

    3. MRP не может решить вопрос о изменении сроков выпуска конкретного головного изделия при возникновении проблем с каким-либо комплектующим нижнего уровня, т.к. ничего не знает о корневом источнике потребности. Недостаток этот заложен в самом алгоритме расчета. MRP рассчитывает потребности сверху вниз, уровень за уровнем для всех изделий базы данных (см. рис. 1). В силу этого, корректно определить источник потребности в большинстве случаев не представляется возможным.

    image

    В итоге, для MRP все заказы «серые» (см. ниже). Т.е. при возникновении проблем в производстве компонента, входящего в несколько изделий определить, например, какому клиенту надо сообщить о переносе сроков заказа не представляется возможным.

    image

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

    Какова альтернатива?


    Альтернатива существует в виде сравнительно недавно появившегося и уже взятого на вооружение многими ERP поставщиками алгоритма планирования, используемого в некогда позиционировавшихся совершенно обособленно APS и MES системах (APS — Advanced Planning and Scheduling System — синхронное планирование и оптимизация — СПО, MES – Manufacturing Execution System). Сейчас APS алгоритм считается прорывом в практике управления промышленными предприятиями, сравнимым с разработкой алгоритма MRP-II более трех десятилетий тому назад. «…обязанный в немалой степени развитию компьютерных технологий, APS предлагает не только быстрейшие, но и лучшие ответы на извечные вопросы промышленного предприятия:

    • что мы можем произвести;
    • когда мы сможем отгрузить;
    • как мы лучше сможем использовать имеющиеся ресурсы для удовлетворения спроса…»

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

    И, прежде чем перейти к описанию СПО алгоритма заметим, что APS не является:

    • только средством «быстрого и тонкого планирования»,
    • быстрым вариантом MRP-II,
    • оптимизатором планирования или вторым этапом внедрения MRP-II/ERP системы,
    • алгоритмом планирования только для совсем идеальных данных,
    • методологией только для продвинутых предприятий и предприятий, работающих под заказ,
    • стандартом APICS.

    Планирование ресурсов по APS. Как это работает


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

    Начальные данные:

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

    APS алгоритм использует для расчета принципиально отличную от MRP, реальную модель предприятия, т.е. не абстрактные и жестко-определенные рабочие центры (участки) с одинаковыми машинами в нем, которые, как правило, должны соответствовать рабочим участкам и не могут быть «размазаны» по нескольким цехам или всему предприятию, а реальные ресурсы завода, т.е. люди, станки или группы оборудования, площади, инструменты и оснастка и т.д. (рис. 3). В рамках MRP II адекватное описание бригады рабочих, одновременно выполняющих работы на нескольких рабочих участках приводит к тому, что для рабочих центров в ERP системе численность рабочих определяется как определяются 1,5; 3,17 человека и т.д.

    image

    В отличие от классической MRP, ресурсы APS алгоритма (оптимизационно-сетевая модель) могут иметь дополнительные качественные атрибуты, такие как квалификация рабочих или их разряд, характеристика оборудования или инструмента, например, «старый», «новый», где «старость» оборудования может определяться например реальной группой точности или скоростью обработки. Также для каждого ресурса может быть определен свой график работы, и ресурсы могут быть объединены в группы ресурсов, что является приблизительным аналогом рабочих участков (рабочих центров) MRP-модели. Более того, ресурсы могут быть объединены в группы ресурсов, также имеющих вполне реальное название («токари 2-го разряда», «токари 6-го разряда» — см. выше. В случае отсутствия для персонала предприятия ГОСТированной разрядной сетки, может использоваться своя, которая реально существует на каждом предприятии. Один из примеров – стаж работы.


    Пример определения техпроцесса в новой модели предприятия выглядит следующим образом.
    Изделие А:

    • операция 050 «прецизионная металлообработка»; необходимые группы ресурсов: прецизионная обработка и токарь 6-го разряда, необходимые ресурсы: рабочий 6-го разряда, станок №1.
    • операция 055 «нормальная металлообработка»; необходимые группы ресурсов: нормальная обработка, токарь 2-го разряда, необходимые ресурсы: рабочий 2-го разряда ИЛИ рабочий 3-го разряда ИЛИ рабочий 6-го разряда, станок №1. ИЛИ станок №2.

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

    Планирование


    Формирование плана производства или плана отгрузки по заказам клиентов с использованием APS алгоритма будет следующим.

    Шаг 1. Расчет потребностей в материалах. Определение самой ранней даты начала работ, даты закупок и даты отгрузки/даты выпуска готового изделия

    Расчет производится по алгоритму MRP, но с двумя существенными отличиями.

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

    image

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

    image

    Шаг 2. Определение дат начала/завершения работ с учетом загрузки существующих ресурсов.
    «Проталкивание», т.е. планирование «снизу-вверх, из прошлого вперед».


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

    1) по заданным в системе правилам из определенной для этой операции группы ресурсов подбирается доступный ресурс, операция переопределяется для него,

    2) если такого ресурса нет, все операции данной детали последовательно переносятся в ближайшее свободное временное «окно» первого свободного ресурса. Таким образом, определяются даты начала/завершения каждой операции для производства данного компонента или готового изделия (рис. 6).

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

    3. Действия по пп 1 – 2 выполняются по всей структуре изделия снизу – вверх, пока не будет определена итоговая дата готовности конечного изделия.

    image

    Шаг 3. Сокращение общего времени производства.
    «Вытягивание», т.е. планирование «сверху–вниз, из настоящего в прошлое».

    К определенной выше дате итогового окончания работ «подтягиваются» даты производства/закупок всех деталей/материалов рассматриваемого изделия с учетом загрузки ресурсов, т.е. для деталей/материалов нижнего уровня переопределяются даты начала/завершения работ на более поздние (в общем случае).

    image

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

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

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

    В режиме общего перепланирования для всего горизонта планирования обнуляются все спланированные ранее потребности (кроме выпущенных в производство заданий), выбирается последовательность объектов к планированию (план, производственные задания, потребности в пополнении страхового запаса, прогноз спроса, заказы клиентов и т.д.). Далее, по алгоритму, описанному выше последовательно планируется один за другим выбранные изделия.
    При таком перепланировании даты завершения спланированных ранее, но не выпущенных в производство заданий могут измениться («съехать» вперед). Однако общий план, тем не менее, будет реальным.

    Оптимизация

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

    Заключение


    Нельзя сказать, что APS алгоритм та самая волшебная кнопка, которая идеально спланирует все и вся на предприятии Корпоративная информационная система с APS алгоритмом планирования – только необходимое, но недостаточное условие эффективного планирования деятельности промышленного предприятия. Однако использование старых и неэффективных алгоритмов планирования в корпоративной системе может значительно ограничить шансы компании на успех.
    Если вы выбираете ERP систему, которая помимо всего прочего должна решать и задачи производственного планирования – выбирайте систему, которая может решить эту задачу именно на вашем предприятии, систему со встроенным алгоритмом реального планирования. Поскольку своими силами внедрить подобную систему, как правило невозможно, необходимо очень тщательно подходить к выбору компании, берущей на себя роль внешнего консультанта. В качестве одного из критериев выбора следует использовать уровень компетентности ее сотрудников в области современных методов планирования среди которых, как видно из статьи должен присутствовать APS.

    И еще… Для решения задачи производственного планирования деятельности реального российского большого предприятия не всегда необходимо закупать за огромные деньги и мучительно долго внедрять всю ERP систему с или без APS модуля. Очень часто бывает возможно сравнительно быстро внедрить на предприятии только APS функциональность + интерфейсы с существующими системами учета запасов и CAD – PDM системами. Это, как правило очень быстрые (не более полугода) и эффективные проекты. Но это возможно только если компания-поставщик понимает, что и как необходимо делать, а так же обладает для этого необходимым инструментом, т.е. ERP системой с функциями планирования, построенными с использованием APS алгоритма. Но как это сделать — материал для отдельной статьи.

    … и тогда успешных проектов и эффективно работающих российских предприятий будет больше!

    Еще одной альтернативой MRP II является использование для управления нашими предприятиями технологии Точно Вовремя. Рассмотрение этого стандарта требует отдельной публикации.

    Питеркин С.В.

    ПРИЛОЖЕНИЕ

    «Более подробно об алгоритме планирования MRP»

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

    image

    image

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

    image

    Также возможен расчет нетто-потребностей с учетом правила партии (минимальная партия заказа, кратность партии, периодичность заказа).

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

    image

    Алгоритм расчета можно проиллюстрировать с помощью следующей схемы

    image

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

    Подробнее
    Реклама

    Комментарии 12

      0
      Как же все это далеко от реальности… Такое впечатление, что со времен Гантта ничего никуда не двинулось — а ведь это далеко не так! Меня всегда смешило, что так называемая «задача разузлования» изучается экономистами целый семестр, в то время как ее математическое выражение крайне просто (обратная от разности матрицы входжения и единичной) и изучать там просто нечего. Так и тут — народ носится с ERP MRP-II и другими системами, невзирая на практику, которая говорит о полной неадекватности теории таких систем реальности. Уж лучше почитать Майкла Пинедо — практичнее будет!
        0
        1. Кроме как «почитать Майкла Пинедо» какие-то еще замечания по существу будут? Можно упомянуть еще про Factory Physics, Forrester, Bruker, и др. не говоря уж о Первозванском и Канторовиче. Кстати, только первые из 2х рассматривают задачу Planning, которая на минуточку, принципиально отличается от задачи Scheduling. И упор у них, как и у Pinedo, к сожалению в основном на scheduling. В статье упор — именно на Planning! Но без глубокой математики конечно…
        2. MRP-ii — не система. И не алгоритм(ы)- для тех, кто понимает. ERP — класс (разных!) систем. Статья не про это, прочитайте еще раз.
        3. Разузлование (в MRP) действительно крайне простая штука. Хотя не видел (русских) экономистов, которые это знают. Разузлование в сетевых APS алгоритмах — сложнее. И совсем уж не такое простое про программировании (если есть цель, чтобы работало быстро). Но — не квантовая механика конечно.
        4. Самое сложное — применение всего это в реальности: может, но не всегда и не везде. 80 или даже 90% сложности планирования реального производства — это не математика. Ни разу. В т.ч. об этом — в следующих статьях.
        5. "… полной неадекватности теории таких систем реальности" — это в РФ, с редкими исключениями. На западе — ИТ-системы управления (включая, но далеко не ограничиваясь ERP) поддерживающие методы (включая, но далеко не ограничиваясь MRP-ii) — просто must. Без всяких волшебных математических или цифровых чудес, которые только «в это стране» рассматриваются как волшебные палочки.

        Комменты по существу — приветствуются.
        Питеркин Сергей
          +2
          Дело попросту в том, что я-то как раз создаю вычислительные ядра систем планирования, и они работают на реальном (очень крупном) производстве. Часть проблем вы перечислили, конечно, правильно… Но оставили за бортом самые сложные (и теоретически, и практические), без решения которых все эти системы остаются игрушечными. Кстати, величины задач у вас приведены для предприятий маленького масштаба — в реальности глубина дерева сборки редко меньше 50, общее число планирумых операций часто переваливает за миллиард, число «станков» вполне может быть за десятки тысяч, есть такие «милые» вещие как одновременное параллельное выполнение ветвей сборки (что приводит к возникновению леса на подуровне дерева), компактификации частей дерева, параллельное выполнение массовых операций (что может составить до 70% всех операций), и главное — все это надо считать за минуты…
          Вот например, вспомогательная задача планирования перемещений — я даже не нашел не то что ее решения, а даже постановки (по крайней мере, в источниках за последние 30 лет) — для ее целочисленного решения наилучшее известное мне решение имеет даже алгоритмическую сложность 2^(N), а ведь это крайне востребованная задача для диспетчера группы участков.

          И зря вы киваете на «зарубеж» — там все еще хуже, чем у нас. И это объяснимо — производительность (эффективность) у нас выше (даже не знаю, почему — может больше «крутятся»), хотя и оснащенность ИТ-средствами не очень…
            0
            1. Вычислительные ядра — это отлично. Крупные производства — тоже. Наша практика частично есть тут www.rightstep.ru/customers
            2. Вы предлагаете примеры в статье расписывать страниц на 50 реального дерева изделий ???
            3. Приведите пример изделия с 50 уровнями дерева. Думаю, речь идет и технологической структуре? Т.е. уровни конструкторского вхождения + тех.операции?
            Такие деревья в нашей практике доходят до сотен тысяч и даже миллионов позиций…
              0
              1. Описанный алгоритм — не для всех. Это очевидно. Для «средних» (западных) заводов в неск. 10ков-100тен чел., работающих позаказно и 100% в комм.рынкеи конкурирующих за сроки и «уровень обслуживания» при мин. затрат на НзП, и похожих на них наших — оч.даже подходит. В других случаях — другие подходы (методы) и алгоритмы. Статья не про это.
              2. Наши «детские заводы» (ссылка в посте рядом) делают действительно «детские изделия», здесь Вы с 50 уровнями сборки всех сделали. Интересно, что это такое,(только) собирается через 50 уровней.А еще же агрегатная сборка, мехсборка, мехобработка и пару-тройку и более… уровней производственно-логистической цепочки… Можно не отвечать, я понимаю, что это суперсекретный завод :))
              3. Задача точного планирования «ярдов» операций, теоретически решаемая практически не решается за вменяемое время. Это — простая математика. И второй вопрос: а надо эту задачу решать? Современная теория операционного менеджмента (не у нас...) говорит, что нет.На уровне Planning- одна модель(и конечно-же без станков и операций), на уровне SChedulling — другая, «местами» (где надо) — и до операций и о станков. Но на ограниченном временном промежутке, и с допущениями, что делает задачу счетной.
              4. Если вы математик — вы конечно будете решать все задачи прямолинейно. В т.ч. и «вспомогательную задачу перемещений». Для большинства же реальных производств эту задачу можно решить без математики, через простейшие или продвинутые (но тоже простые) инструменты вытягивания.
              5. Ну и про запад и про нашу эффективность — конечно насмешили. Спасибо! Хотя, у нас «в этой стране» многие создают под себя собственные вселенные. Как например наши госорганы и гос и квази гос «промышленные» холдинги. Возможно, что в вашей вселенной- все наоборот: планирование ярдов операций и лямов станков на неск.лет вперед, каждому сотруднику план работ каждый час с точностью до секунд, автоматический сбор/пересбор партий запуска, партий обработки, расстановка и перетасовка очередей и пр.и пр., и всё это — с постоянной синхронизацией по всей цепочке и с учетом аналитик запасов типа ГОЗ/Коммерция и приоритетов заказов… И осталось то только — спланировать перемещения… Успеха! :))
              Питеркин Сергей
                0
                Просто я считаю, что описанный вами алгоритм имеет скорее экспериментальный интерес, но не практический. Я, действительно, математик (правда, я не очень понял, что значит, что буду решать задачи прямолинейно — как-то в таком ключе, честно, не думал, потому что процесс решения как минимум всегда итеративен, но чаще совсем не сводится ни к линейному, ни к циклам), поэтому всегда стараюсь понять и изложить собственно формулировку задачи, как бы это ни было трудно. Это помогает понять, что в задаче новое, что уже решенное. Ну и оценить решение, если оно есть.

                Вот вы пишите, что миллиарды планируемых операций задача практически нерешаемая. Но это не так. Это верно, если поступать как современные программисты — то есть совершенно ненаучно, нагромождая неэффективность и сложность друг на друга, в то время как основной задачей всегда является достижение простоты. Простой пример из того, что я писал выше — решение задачи разузлования можно делать даже на СУБД (например Postgesql имеет рекурсивные запросы), но это на порядок медленнее чем то же делает ERP (SAP,..) система, но она это делает это на порядки медленнее, чем прямое решение матричного уравнения LINPACK, но это на порядки медленнее, чем рекурсивное вычисление синтезированным алгоритмом. Пока мне удается решать такие задачи достаточно быстро я буду уверен, что основная проблема планирования — это неверно спроектированные ERP системы…

                Про эффективность могу привести близкий мне пример — я часто заказываю PCB, причем и в Европе, и в России, и в Китае (ну так вот получается). Прибыль у всех производителей примерно одинаковая, материалы и технологии тоже примерно похожы, поэтому эффективность прямо отражается в цене. Так вот кв. дециметр стоит в Китае $10 в России $30 а в Европе $80. Вот примерно так и соотносятся эффективности, по моему наблюдению, во многих областях промышленности…
            0

            Статья интересная — много теории, но было бы интересно узнать use case. Например при общей численности предприятия в 15 человек, стабильно выпускающих порядка 1000 единиц электронной продукции в год, в том числе по индивидуальным заказам, есть смысл внедрения MRP?
            При том, что сейчас планированием занимается аж 1 человек с помощью того же Excelя? Уменьшится у него работы? Какова выгода предприятию от внедрения MRP кроме уменьшения объема склада и увеличения оборотных средств, если с этим и сейчас у предприятия особых проблем нет?

              +1
              Планированием может заниматься и один человек даже без экселя, «на глаз» определяя потребности и сроки. Но если очень важны такие показатели как точность и детализация, тогда в любом случае нужно больше, чем 1 человек и обычный эксель. Особенно если потери от неправильного планирование большие, даже если не реальные, а возможные.
                0
                Задайте вопрос по другому: проблемы (бизнес-проблемы) связанные с планированием — есть? Если нет, или нет явных областей улучшения, которые помогут быстрее и больше зарабатывать — не парьтесь. Теоретически и практически не запрещено «Excel + 1 человеку» делать такие планы, производство по которым вполне устраивает рынок и собственника.
                Сергей Питеркин
                  0

                  Тут как бы сложно с явными областями для улучшения и эффектом от их внедрения. Особенно для малого предприятия. Есть просто практический интерес:


                  1. Обеспечить возможность поставки любого стандартного продукта со склада в 90% случаев при наличии минимального склада готовой продукции и компонентов и гарантированно в течении Х дней для изделий по индивидуальному заказу.
                  2. "Хочу все знать" — иметь возможность четко отслеживать статус производства руководителем без особых знаний.
                  3. Возможность деланья всего этого одной левой рукой любым человеком без особых знаний и подготовки.

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

                    0
                    Не Excel — однозначно. И не MRP конечно.
                    Нужна «нормальная» система планирования: и методология, особенно для решения п.1. и нормальная ИТ-система: планирование и мониторинг.
                      0

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

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

              Самое читаемое