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

«Пре­до­твра­ще­ние сбоев при создании поставки в SAP TM»
Наталия Пирожкова:
Полезная статья. Используем это на практике, также отправляем повторно запрос на создание поставки из списков с неудачной попыткой создания поставки. Если отправлять поставки из списка ЕФ ,...
«Рассылка извещений о со­зда­ни­и­/и­зме­не­нии заказа на пе­ре­ме­ще­ние»
Матигулла Мухатдинов:
Добрый день. Столкнулся с одной проблемой. При изменении заголовка и текста электронной почты выдается сообщение, предупреждающее, что изменения не сохраняются в базе данных а только локально. Это...
«Рассылка извещений о со­зда­ни­и­/и­зме­не­нии заказа на пе­ре­ме­ще­ние»
Матигулла Мухатдинов:
Спасибо. Большая польза от подробного описания. Матигулла Мухатдинов

Планирование и оптимизация запаса с помощью SAP Advanced Safety Stock Planning и SAP SmartOps

1560

Ключевое понятие

Решение SAP SmartOps Enterprise Inventory Optimization (EIO) предоставляет всесторонний процесс в масштабах всего предприятия для оптимизации, управления и контроля уровней пополнения запаса для готовых изделий и сырья во всей логистической цепочке. 

Поддержание оптимального уровня запаса продукции в логистической цепочке может решить судьбу любой производственной или логистической компании. Уровень ниже оптимального приведет к дефициту и последующим потерям продаж, а слишком высокий уровень съедает часть рентабельности компании. Ранее компания SAP предлагала решение для планирования запаса в рамках своих основных решений SAP ERP Central Component (ECC) и Advanced Planning and Optimization (APO). Недавно компания SAP приобрела SmartOps, что позволило ей предложить расширенные возможности планирования и оптимизации запаса в системе Advanced Safety Stock Planning (ASSP).

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

Неопределенность спроса возникает в результате ошибок при прогнозировании потребностей клиента (т.е. недооценка или переоценка потребностей клиента). При расчете страхового запаса учитываются прогноз из SAP Demand Planning и колебания потребности на основе исторических прогнозов и реализованной потребности. Для вычисления точности своего прогноза в системе используются значения из двух показателей временных рядов в области планирования: плановое количество потребности и реализованное количество потребности (т.е. фактические продажи). Показатели временных рядов являются показателями APO, которые хранятся в инфо-кубе.

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

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

Данная статья включает в себя четыре раздела:

  • Пример внедрения APO ASSP
  • Пример внедрения SmartOps Enterprise Inventory Optimization (EIO)
  • Обзор динамического планирования запаса ECC
  • Сходные черты и различия между приложениями для планирования запаса SAP

Пример внедрения APO ASSP

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

Компания имеет огромную сеть логистической цепочки с 7 табачными фабриками и 12 субподрядными местоположениями для производства упакованных продуктов питания. Из всех этих местоположений производства продукция поступает на четыре больших склада (которые называются материнскими узлами), разделенными по четырем регионам страны. Эти огромные хранилища, в свою очередь, распределяют материалы по 35 складам, с которых материалы перемещаются 1200 дистрибьюторам.

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

Эта компания внедрила APO ASSP для поддержания оптимального уровня запаса готовых изделий на уровне дистрибьютора (т.е. в 1200 центрах распределения).

Трудности во время внедрения ASSP 

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

Техническая трудность: Некоторые линейки продуктов компании часто продавались со скидками. Это были категории упакованных продуктов питания, например, готовые к употреблению продукты. Продажи по этим категориям в значительной степени зависели от рекламных мероприятий (т.е. продажи росли при наличии рекламы и падали после завершения рекламного мероприятия). Предложить оптимальный уровень страхового запаса для этих позиций со спорадической потребностью представляло сложность для инструмента APO ASSP, поскольку этот инструмент предназначен для позиций с постоянной потребностью. Эти часто рекламируемые позиции не вошли в объем внедрения APO ASSP.

Примечание.
Несмотря на то, что APO предлагает функциональность планирования рекламных мероприятий, ожидаемое повышение во время рекламного периода вводится в систему вручную плановиком. Ожидаемое повышение не рассчитывается системой автоматически. Часто догадка плановика относительно этого значения оказывается неверна, в результате чего повышается неточность прогноза во время периода рекламных мероприятий (т.е. фактические продажи будут намного выше или ниже прогноза). Поскольку расчет страхового запаса ASSP зависит от точности прогноза, низкая точность приводит к некорректному вычислению страхового запаса. Поэтому, как показывает мой опыт, многие компании стремятся использовать ASSP, главным образом, для стабильных продуктов, но не для продуктов, которые часто включаются в рекламные мероприятия.

Техническая трудность: В APO ASSP предполагается, что количество дефицита всегда относится к предшествующему заказу и может быть поставлено позднее (т.е. потери продаж не возникнут). Этот подход работал в табачной отрасли, поскольку на этом рынке компания работала практически монопольно. Дистрибьюторы заполняли количество по следующему заказу дополнительным количеством дефицита из последнего заказа (при наличии). Однако это было не вполне справедливо для упакованных продуктов питания и быстроподвижных потребительских товаров, где любой дефицит мог означать потерю продаж для компании, поскольку в этом случае клиент покупал продукцию конкурентов. По этой причине компания ввела ручной контроль. Иначе эта опция называется полосой страхового запаса. 

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

Для некоторых позиций ведение этих данных в отдельном файле Excel выполнял индивидуальный закупщик, который обрабатывал конкретную позицию. Колебания поставок рассчитывались по данным в этом файле Excel. Для других позиций, данные по которым были недоступны, принималось разумное допущение (например, колебания поставок от 40% до 50%). Во время внедрения компания ввела систему регистрации данных фактических колебаний поставок для будущего использования. Данные колебаний поставок часто оказываются недоступными во многих компаниях.

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

Техническая трудность: Фоновое задание планирования страхового запаса требовало много времени на выполнение, поскольку в нем участвовало большое число комбинаций местоположений продуктов (больше 10 000 продуктов и около 1 500 местоположений). Компании приходилось делать много повторов с идентификаторами выбора, чтобы найти оптимальное время выполнения. 

Понятие полосы страхового запаса 

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

В рамках полосы страхового запаса для каждой категории определялся уровень сервиса бета с минимальной и максимальной полосами страхового запаса. Например, для конкретной категории, табака, для крупного продавца уровень сервиса бета мог составлять 99,9%, количество дней страхового запаса в рамках этой верхней и нижней границ полосы – 2 и 6 дней. Для любого продукта этой категории, если фоновое задание страхового запаса выдает требуемое количество дней страхового запаса в рамках этой верхней и нижней границ полосы, рассчитанный системой страховой запас принимается. Однако если рассчитанный системой страховой запас оказывается ниже или выше определенной полосы, макрос корректирует это значение до ближайшей (верхней или нижней) границы полосы.

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

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

В Табл. 1 представлен пример определения компанией уровня сервиса с верхней и нижней границами полосы для различных категорий продуктов в ее портфеле. Это решение было промежуточным. До перехода к продуктивной эксплуатации компании пришлось привыкать к нему, поскольку даже после нескольких месяцев моделирования результаты статистического прогноза не были адекватными для ряда СЕИ. Мой опыт показывает, что во многих компаниях даже при условии доступности качественных данных и выбора лучшей модели прогнозирования отсутствует гарантия того, что значения статистического прогноза, предоставленные системой для некоторых СЕИ, будут близки к реальности (т.е. фактическим продажам). Часто система начинала предоставлять приемлемые результаты только через несколько месяцев.

Категория  Уровень сервиса бета Более низкая полоса страхового запаса (в днях) Более высокая полоса страхового запаса (в днях)
Табак (продавцы с большими объемами)  99,9 2 6
Табак (продавцы с малыми объемами)  99,9 6 10
Упакованные продукты питания   95 2 6
Продукты питания, готовые к употреблению  95 6 10
Продукты личной гигиены  99 2 6

Табл. 1

Уровни сервиса для разных продуктов

 

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

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

Шаги по настройке основных данных и конфигурирования

Внедрение APO ASSP для этого проекта требовало выполнения настройки основных данных и шагов конфигурирования системы. Большинство данных являлись стандартом для APO, использовалось несколько пользовательских макросов для написания правил полос страхового запаса. Начнем с настройки основных данных. 

Параметры настройки основных данных, ведение которых выполнено в APO ASSP для данного проекта, представлены на Рис. 1. Для вызова этого экрана запустите транзакцию основной записи продукта /SAPAPO/MAT1 и выберите в меню "APO > Master Data > Product > Lot size" (APO > Основные данные > Продукт > Размер партии). Был указан метод страхового запаса (поле метода $$tk) BT. BT означает уровень сервиса бета и метод цикличности заказов на поставку. Как говорилось выше, уровень сервиса бета подразумевает ориентацию на количество. Метод цикличности заказов на поставку использовался по той причине, что пополнение запасов в центрах распределения со складов компании выполнялось на основе цикла заказов. В поле уровня сервиса (%) было выполнено ведение значения уровня сервиса, необходимого для комбинации продукта и местоположения. В данном случае для упакованных продуктов питания определен уровень сервиса 95,0.

Рис. 1

Основные данные после ведения в основной записи продукта APO для ASSP

 

Период цикла заказа вводится в поле "Target Days’ Supply" (Целевая обеспеченность запасами) на закладке "Lot size" (Размер партии) в основной записи продукта. Цикл заказа описывает обычное число периодов между двумя прогонами планирования заказа. Здесь указано значение 5,00 (т.е. длина цикла заказа составляет пять дней).

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, введите в правом верхнем углу логин и пароль.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.