Материал: Оптимизация плана производства и поставок с использованием системы планирования IBM ILOG Plant PowerOps

Итак, в ходе обсуждения темы данной главы было определено, что использование IBM ILOG Plant PowerOps актуально далеко не для всех типов производственных процессов, а следовательно, и для отраслей. Усилия по использованию этого программного обеспечения чаще всего уместны лишь для капиталоемких крупносерийных производств с выраженным узким местом или производственных линий.

2. Решение задачи

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

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

2.1 Создание модели

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

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

Таблица с данными по материалам

Модель предлагает разделять постоянные и переменные данные. Постоянные данные не меняются в ходе процесса оптимизации. Переменные - меняются. Для каждого из типа данных предлагается отдельное графическое представление.

Процесс изготовления стола из заготовки состоит из двух этапов (далее - последовательность действий). Обработка на фрезерном станке и лакировка (действия). Отдельно создаются модификации действий для дубового и соснового столов, так как они потребляют разные материалы. Время на совершение действий и их стоимость также различается: 120 и 240 единиц времени для дубового и 100 и 200 для соснового столов на обработку и лакировку соответственно (см. Рис.4). Тут же могут быть добавлены и ограничения, одним из которых является определение порядка действий (см Рис.5). Зелеными стрелками обозначены отношения Конец-Начало, согласно которому процесс на конце стрелки не может начаться, пока не закончится процесс в её начале. Логично, что не имеет смысл лакировать стол до тех пор, пока его не обработали. Промежуточные действия - подготовка к работе фрезеровщика и лакировщика.

Редактирование времени и стоимости модификаций действий

Определение последовательности действий

Для действий необходимо определить ресурсы, которые в них задействованы. Это могут быть как люди, так и основные средства. В упрощенной модели используются только люди: фрезеровщик и лакировщик. Характеристика каждого ресурса оформляется отдельно (см. Рис.6). Для каждого ресурса может быть определено время на наладку (или подготовку к работе для работников), описываемое матрицей наладки оборудования. Матрица закрепляется за каждым ресурсом и состоит из нескольких состояний , переход из одного в другое стоит денег и времени (см Рис.7). Для начала определенного действия указывается состояние, необходимое для его начала.

Таблица Ресурсы

Таблица наладки оборудования/подготовки рабочего места

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

Структура производства

Структура процессов

Ещё одна информация, которую необходимо задать - календарь, в котором указаны смены, выходные, перерывы на работу и т.д. В нашем случае имеет место лишь одна смена длинной в 8 часов, которая начинается в 8:00. Для отображения это информации также существует графическая интерпретация. За каждым ресурсов закрепляется собственный календарь, по которому он и работает.

Визуализация календаря

Единственная информация, принадлежащая к переменным данным и вводимая пользователем, - спрос. Для него указывается окно, в которое должна осуществляться поставка с возможным уточнением её даты. Кроме того, обязательна информация о выручке с единицы продукта и о штрафе за срыв поставки. Эти данные являются стимулом для функционирования компании, и если установить их значение равным нулю, оптимизатор, скорее всего, примет решение ничего не производить.

Таблица Спрос

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

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

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

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

IBM ILOG Plant PowerOps дает возможность определять полномочия пользователей программы .

Полномочия пользователей в IBM ILOG Plant PowerOps

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

.2 Оптимизация

IBM ILOG Plant PowerOps состоит из четырех модулей: планирования производства, определения размера партий, составления детальных графиков и закрепления за спросом. Каждый из модулей решает специфические задачи в процессе оптимизации. В большинстве случаев они работают последовательно в указанном выше порядке и функционируют согласно следующему алгоритму:

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

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

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

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

Процесс оптимизации

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

Таблица Производственные заказы.

Таблица Материальные потоки

Таблица График действий

Таблица Запланированное производство

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

График Гантта

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

Таблица загруженности ресурсов

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

KPI также представлены в виде таблицы.

Важным моментом является возможность дублировать модели. Это позволяет моделировать множество ситуаций, фактически используя "What-If"-анализ. Например, можно имитировать ситуацию введения сверхурочных работ или изменение последовательностей действий на производстве.

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

2.3 Эффективность модели

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

Именно поэтому требуется взять описание производственной системы, предложенный разработчиками программы. В роли такого сценария в данной работе будет выступать производство конфет. Это намного более сложный процесс, описание которого займет большое количество времени, однако всё, что нам требуется знать для анализа это то, что производственная система занесена в IBM ILOG Plant PowerOps , начальные и конечные значения KPI, критерии оптимизации производства. Веса каждого KPI в модели равны.

Специфика данного кейса, как можно заметить из KPI, заключается в том, что совершенно не обязательно знать показатель выручки. Достаточно лишь оценить стоимость срыва контракта (non-delivery cost), стоимость потери просроченного товара (waste cost), стоимости переналадки оборудования, избыточного или недостаточного уровня запасов на складе. Оптимизируя TCO по данным видам затрат, программа оптимизирует производство

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

Так как веса критериев одинаковы, имеем право складывать KPI с целью получения кумулятивного показателя. До оптимизации суммарные затраты составили 3 062 033 155, 43 у.е. После они оказались равны 3 058 572 856 у.е., что позволило сократить затраты на 3 460 299,14 у.е. или 0,13% Это произошло благодаря некоторому увеличению затрат на переналадку оборудования и смещению равновесия в сторону увеличения затрат, связанных с избыточным уровнем запасов на складе. Данная экономия была получена за период 1 год 20 дней. С учетом того, что информационные системы требуют обновления минимум каждые 7-10 лет, даже при достаточно жестком уровне стоимости денег (15%) за 7 лет программа сможет окупить единовременную инвестицию примерно в 13 094 310.12 у.е.