Особенности проекта внедрения MRP по точке перезаказа

Подробности: Опубликовано: 31.03.2018 10:27; Автор: Степанов Дмитрий Юрьевич; Просмотров: 12503

Аннотация: статья содержит описание сложностей, возникающих при внедрении функционала планирования потребности в материалах на основе точки перезаказа (Reorder Point). Разбираются вопросы сбора статистической информации, интеграции бизнес-процессов, обработки и загрузки данных в корпоративную информационную систему, а также постепенного продуктивного запуска.
Скачать: PDF (статья), PDF (выпуск №1).
Ключевые слова: планирование точка перезаказа, планирование по точке заказа, ППМ по точке заказа, метод планирования по точке дозаказа, планирование точка заказа, точка перезаказа формула, управление по точке перезаказа, управление запасами точка заказа, формула определения точки заказа, reorder point.

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

Одним из немногих функционалов информационной системы, выносимых в отдельный подпроект внедрения, является планирование потребностей в материалах (Material Requirement Planning, далее – MRP) [1]. Существуют различные типы MRP в зависимости от вида производства и сложности планирования: планирование на основе потребления, планирование по точке перезаказа (Reorder Point, далее – ROP), сезонное планирование и др.

Простейшим видом MRP является планирование по точке перезаказа (Reorder Point - ROP). Суть ROP сводится к измерению параметров, характеризующих состояние склада: текущий уровень запаса продукции и значение точки перезаказа для неё. Если значение точки перезаказа превышает текущий уровень запаса, запускается процедура пополнения продукции за счёт внутреннего производства или закупки у внешнего поставщика (рис. 1). Внедрение ROP в стандарте ERP (Enterprise Resource Planning) пророчит сложности [2]. В частности:

сбор статистической информации;
интеграция бизнес-процессов и управление изменениями КИС;
обработка и загрузка данных в КИС;
запуск планирования материалов в КИС.

Рис. 1. Принципиальная схема планирования по точке заказа

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

Сбор статистической информации

Схематически процедура ROP дана на рис. 1. Анализируя приведённый рисунок, можно выделить следующие основные параметры, используемые при обработке точки перезаказа:

значение текущего запаса продукции на складе;
значение точки перезаказа для продукции;
время пополнения запаса (плановые сроки поставки);
объём заказа.

Рассмотрим, как работает процедура ROP в КИС. Ежедневно, чаще всего в ночные часы, на складе выполняется замер текущего уровня запаса продукции. Предварительно вручную для каждой номенклатуры продукции устанавливается значение точки перезаказа. Если значение запаса ниже точки перезаказа, запускается процедура пополнения, допустим через закупку от поставщика.

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

ТочкаПерезаказа = ПотреблениеВДень / ПлановыеСрокиПоставки, (1)

где ПотреблениеВДень характеризует объём потребляемой продукции за 1 день, ПлановыеСрокиПоставки – сроки поставки материалов от поставщика на склад в днях. Итого, если ежедневно требуется 5 штук продукции, а время поставки составляет 3 дня, то точка перезаказа согласно (1) будет равна 15. Расчет вполне интуитивен: если каждый день потребляется 5 единиц материала, то имеется 3 дня (15/5=3) для пополнения склада, что и будет являться плановым сроком поставки.

Запомним параметры формулы (1) для дальнейшего анализа. Рассмотрим следующий параметр из рис. 1: объём заказа. Как же правильно рассчитать данный параметр? Воспользуемся формулой Уилсона для определения оптимальной партии поставки (Economic Order Quantity, далее – EOQ) [3].

EOQ = √(2 * ЗатрОбрЗак * ПотребВМес / ЗатратХранСклад), (2)

где ЗатрОбрЗак определяют затраты в рублях на обработку 1 заказа на поставку продукции от поставщика до склада, ПотребВМес – количество продукции, потребляемое за 1 месяц, ЗатратХранСклад – затраты в рублях на хранение данной продукции на собственном складе в месяц. Последний параметр зависит от стоимости продукции и рассчитывается по формуле (3).

ЗатратХранСклад = Процент * СтоимостьПродукции, (3)

где СтоимостьПродукции задаёт цену закупаемой продукции, а Процент определяет % на затраты хранения в зависимости от стоимости.

Так что же даёт EOQ? Формулы (2)-(3) задают количество продукции, которое будет заказываться у поставщика каждый раз при срабатывании точки перезаказа. В связи с этим возникает закономерный вопрос, а какое количество продукции оптимально заказывать и каково оптимальное число заказов у поставщика за месяц?

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

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

значение текущего запаса продукции на складе;
значение потребления продукции в день и за 1 месяц;
время пополнения запаса (плановые сроки поставки);
затраты на обработку 1 заказа на поставку;
стоимость продукции.

Таким образом, выполнение простейшей задачи по определению значения точки перезаказа превращается в сбор и анализ значительного объёма исторической информации, требующий немалых трудозатрат. Так может не тратить время и указать значение данных параметров, не особо вдаваясь в детали? Согласно формуле (1) подобное может привести к дефициту продукции, когда запас материала полностью исчерпан, а его пополнение ещё не выполнено; следуя формулам (2)-(3), неизбежно увеличение себестоимости продукции за счёт косвенных затрат.

Интеграция бизнес-процессов и управление изменениями КИС

Имплементация процедуры ROP в случае, когда базовые бизнес-процессы уже реализованы в КИС, требует выравнивания бизнес-транзакций системы. Рассматривая функционал точки перезаказа современных КИС, следует упомянуть о ABC и XYZ анализе [4], характеризующем стоимость запасов и регулярность их потребления (рис. 2). В проектах внедрения КИС, например, SAP ERP [5], функционал ROP используется для уровня СX матрицы ABC-XYZ. В частности, широкое применение точки перезаказа нашло в планировании запасных частей на производственных предприятиях. Обычно стоимость запчастей невысока, а регулярность потребления достаточно стабильна, тем самым подобные материалы отожествимы с CX уровнем матрицы.

Рис. 2. ABC и XYZ матрица стоимости запасов и регулярности потребления

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

во-первых, требуется понять, на какие существующие процессы функционал ROP явно влияет. Например, как было сказано ранее, операции ремонта связаны с закупкой, запасами и сбытом. В результате проделанного анализа может возникнуть необходимость в кастомизации процессов КИС, ранее не планируемых к изменению;
во-вторых, путём регрессионного тестирования можно идентифицировать существующие процессы КИС, выполнение которых в заданной последовательности потенциально влияет на работу процедуры ROP. В подобных случаях порядок выполнения бизнес-транзакций подлежит изменению. Например, открытые заказы на закупку рассматриваются SAP ERP как плановые поступления, что снижает объём закупаемой продукции согласно ROP. Последнее приведёт к дефициту товаров в случае, если заказы на закупку открыты, однако срок действия их давно истёк. Изменение процесса потребует регулярного контроля и закрытия подобных заказов;
и, наконец, в-третьих, процедура планирования сильно зависит от данных системы как основных, так и переменных. Малейшая ошибка, например, в основной записи материала, может привести к совершенно непоправимым результатам планирования. Как было рассмотрено на примере выше, аналогично дело обстоит и с переменными данными. Если до внедрения функционала точки перезаказа пользователям КИС позволялась некая неточность ведения данных, то после – исключено.

Рис. 3. Схема идентификации и управления изменениями

Обработка и загрузка данных в КИС

Выполнив сбор, анализ и расчёт параметров планирования материалов переходим к не менее важному этапу: обработке и загрузке данных в КИС. Типовые шаги обработки данных приведены на рис.4 и включают: очистку данных, в ходе которой удаляются устаревшие и некорректные данные, потенциально влияющие на ход работы информационной системы; выгрузку информации во внешний файл для целей дальнейшего анализа и последующей трансформации, суть последней заключается в преобразовании данных к формату, необходимому для загрузки в КИС; а также непосредственную загрузку в систему [6]. Важно отметить, что каждая из перечисленных активностей завершается операцией проверки результатов, валидация позволяет устранить человеческие ошибки в случае очистки, выгрузки и трансформации, кроме того, убедиться в правильности финальной загрузки данных в корпоративную информационную систему.

Рис. 4. Процесс обработки и загрузки данных в КИС

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

ответственному за планирование сотруднику поступает запрос на включение нового материала в список планирования по ROP;
сотрудник планирования собирает и анализирует параметры планирования для нового материала, используя историческую информацию. В результате определяются: значение точки перезаказа, плановые сроки поставки и объём заказа;
ответственный за данные сотрудник проводит их очистку в КИС исключительно в разрезе нового материала. Очистке подлежат переменные данные системы, как то: заявки и заказы на закупку, резервирования, сбытовые заказы, сетевые графики проекта и прочие объекты на примере системы SAP ERP;
сотрудник планирования или ответственный за данные осуществляет выгрузку мастер-данных во внешний файл с целью дальнейшего обновления и трансформации. Основными данными системы SAP EPR могу служить материалы, инфо-записи, книги источников поставок и прочее;
используя ранее найденные параметры планирования, планировщик преобразует результаты выгрузки в файл трансформации, имеющий заданный формат. Файл передаётся команде, ответственной за данные, для дальнейшего ввода в КИС;
загруженные в КИС данные подлежат валидации как сотрудником, отвечающим за данные, так и планировщиком.

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

Запуск планирования материалов в КИС

Хорошей практикой считается продуктивный запуск КИС с использованием подэтапа стабилизации (рис. 5) [7]. Под стабилизацией промышленного запуска подразумевается последовательное увеличение нагрузки, подаваемой на информационную систему. После успешного прохождения ряда итераций, увеличивающих объём обрабатываемых основных и переменных данных КИС, следует переход к полноценному использованию системы. В чём смысл данного подхода? Основная идея заключается в быстром устранении недочётов и дефектов КИС на ранних этапах эксплуатации, когда объём данных ещё минимален. Более того, конечные пользователи проходят проверку «боем», допуская, обсуждая и устраняя ошибки при тщательной поддержке, не нанося значительного урона системе.

Если обратиться к функционалу ROP, стабилизация работы системы будет заключаться в последовательном увеличении числа материалов, планируемых по точке перезаказа. Допустим, в первую неделю планируется 100, далее 500 и, наконец, 1000 материалов. Планирование на минимальном объёме данных позволяет выявить возможные недоработки как информационной системы, так и бизнес-процессов. Пользователь, курирующий планирование, должен убедиться в корректности следующих позиций:

обновлённых данных;
функционала планирования ROP;
созданных ROP документов.

Действительно, после внедрения процедуры планирования обновление данных становится процессом «бизнес как есть» (Business As Usual), минуя разовые активности перехода (Cutover Activities). Сама процедура обновления подразумевает подготовку списка материалов для планирования, сбор статистической информации и расчёт параметров планирования, очистку исторических данных, а также загрузку и валидацию данных планирования, следуя подходу на рис. 4.

Рис. 5. Типовая методология внедрения КИС

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

Заключение

В работе были рассмотрены типовые сложности, возникающие в процессе внедрения функционала планирования потребностей в материалах на основе точки перезаказа. Достаточно сложно описать все возможные проблемы имплементации в виду сильной зависимости от выбранного программного продукта КИС, как то: SAP ERP, Oracle eOBS, MS NAV или др. Цель же данной работы заключалась в задании тех проблемных областей, с которыми неминуемо столкновение в процессе внедрения. Перспективным направлением дальнейшего развития работы является анализ планирования материалов на основе потребления и разузлования промышленных спецификаций.

Литература

Гаврилов Д.А. Управление производством на базе стандарта MRPII. – СПб.: Питер, 2008. – 416 с.
Wallace T. ERP: Making it happen. – Canada: John Wiley & Sons, 2001. – 375 p.
Mandal B. Decision making in Inventory Management. – NY.: LAP Lambert Academic Publishing, 2011. – 118 p.
Логистика / Дыбская В.В. и др. – М.: Эксмо, 2009. – 944 с.
SAP ERP. Построение эффективной системы управления. / Пер. с англ. под ред. Т. Качинская - М.: Альпина Паблишер, 2008. – 356 с.
Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень данных. - М., 2017. – URL: http://stepanovd.com/training_erp_1-10ru.html?lang=RU.
Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: модели и уровни внедрения систем. - М., 2017. – URL: http://stepanovd.com/training_erp_1-3ru.html?lang=RU.

Выходные данные статьи

Степанов Д.Ю. Особенности внедрения MRP по точке перезаказа // Корпоративные информационные системы. – 2018. – №1. – С. 30-39. – URL: http://corpinfosys.ru/archive/issue-1/47-2018-1-rop.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №1

Обзор открытой корпоративной информационной системы Odoo;
Применение Agile Scrum в проектах SAP;
Анализ каскадной, итерационной и спиралевидной моделей внедрения систем;
Особенности проекта внедрения MRP по точке перезаказа;
Сложности внедрения WMS-систем на примере SAP ERP.