• Главная
• О журнале
  • О журнале
  • Распространение
  • Редакционный совет
  • Редакция
  • Рубрики
  • Список рецензентов статей
  • Правила рецензирования
  • Авторы
  • Russian Logistics Journal
• Новости
  • Календарь мероприятий
  • Размещение пресс-релизов
  • Новости логистики
• Подписка
  • Подписка через агентства
  • Редакционная подписка
  • Электронная рассылка
• Реклама
  • Реклама в журнале
  • Реклама на сайте
• Архив
• Контакты

Внедрение IBP: сложности и преимущества

Скачать статью в формате PDF

ВНЕДРЕНИЕ IBP: СЛОЖНОСТИ И ПРЕИМУЩЕСТВА

Михаил Нелькин, генеральный директор компании «Философия.ИТ»

Федор Егоров, эксперт команды «Философия.ИТ»

Сегодня ERP, CRM, BI и прочие системы управления бизнесом в том или ином виде внедрены во всех крупных компаниях. Особняком среди них стоят системы интегрированного планирования (Integration Business Planning, IBP). Сейчас они только набирают популярность, но крупные компании все больше задумываются о переносе своих оптимизационных алгоритмов из разрозненных Excel-систем и самописных систем в централизованные решения этого типа. Внедрение IBP-решения технически сложно и требует качественных исходных данных. В этой статье описана суть IBP-системы, ее структура и то, как правильно внедрять такие решения.

IBP-система включает две компоненты: Demand Planning и Supply Chain Planning – буквально «планирование спроса» и «планирование цепочки поставок». На практике встречаются решения, которые используют только одну из компонент, но обычно они дополняют друг друга.

Demand Planning

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

Лучшей стратегией оптимизации деятельности компании считалась минимизация затрат на снабжение: уменьшение запасов, сокращение сроков поставки и т.д. Так как продажи были стабильными, для прогнозирования спроса использовались и давали приемлемый результат относительно примитивные инструменты, в частности, Excel.

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

Необходимо учитывать, что спрос зависит от огромного количества факторов, его прогнозирование вручную – очень сложная задача, и сегодня для построения прогнозов используются системы класса Demand Planning (DP).

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

Система Demand Planning использует не только «грубые» методы прогнозирования, такие как скользящее среднее и экспоненциальное сглаживание, но и более совершенные: ARIMA, ARIMAX и dynamic regression.

Современное DP-решение имеет встроенные механизмы интерпретации данных: графики, инструменты what-if-анализа и сравнения, а также способно выгружать данные в Excel таблицы.

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

Второй шаг − интеграция решения с локальными системами для получения информации: в IBP загружаются данные из справочников позиций, регионов и т.д., а также истории продаж. На этом этапе часто возникают проблемы: исходные данные часто плохого качества, не структурированы или не поддаются обработке. Например, для построения точного прогноза сбыта оптимальной историей являются данные о фактических продажах, но не всегда у компании есть техническая инфраструктура для сбора такой информации. Часто компании в качестве истории продаж используют альтернативные источники, например, данные по заказам на продажу, что снижает качество прогноза. Устранить несовершенство исходных данных – нетривиальная задача и одно из препятствий на пути внедрения DP-решения.

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

Собственно, консенсус-план продаж – это и есть результат работы DP-системы. План показывает, сколько товара и в каких точках продажи можно реализовать, то есть отражает веру компании в возможности спроса, подкрепленную расчетами. Обычно плановый объем заведомо превышает производственные возможности компании, и возникает закономерный вопрос: каким образом удовлетворить этот спрос?

На этот вопрос помогает ответить решение класса Supply Chain Planning (SCP).

Supply Chain Planning

В 1996 году некоммерческая организация SCC представила стандарт SCOR (Supply-chain Operations Reference), предложив операционную модель оптимального управления цепочками поставок. Впрочем, хоть SCOR и содержит рекомендации по построению бизнес-процессов на организационном уровне, он не дает ясных алгоритмов планирования снабжения, логистики, производства или сбыта с экономической точки зрения.

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

Чтобы соблюсти баланс, необходимо оценить преимущество одного решения над другим с помощью прозрачной экономической оценки того или иного плана. Иными словами, необходимо принять план, максимизирующий маржинальный доход предприятия – этот подход известен как «стоимостная» или cost-based-оптимизация.

Для комплексного планирования поставок в SCP-решении используется математический аппарат, известный как «Линейное программирование» (LP) или «Целочисленное линейное программирование» (MILP). На рынке существует несколько математических оптимизаторов, решающих эту задачу: CPLEX, Gurobi, XPRESS, а также множество SCP-решений, работающих на базе этих библиотек.

Обобщенно процесс планирования можно описать тремя шагами:
1. Сбор ограничений: переменных затрат и «жестких» ограничений.
2. Построение и расчет модели для оптимизатора.
3. Интерпретация результатов работы SCP-системы и их экспорт в смежные системы для исполнения плана.

Рассмотрим каждый этап подробнее.

Сбор ограничений. На данном этапе нужно собрать и связать между собой все значимые бизнес-ограничения. Источниками данных являются ERP- и CRM-системы, системы бюджетирования, корпоративные хранилища данных, АСУ транспорта, MES-системы и пр. Хорошо, если SCP-решение поставляет тот же вендор, что и локальные системы: например, SAP APO SNP предусматривает бесшовную интеграцию с SAP ERP. Но даже в этом случае интегрированы будут не все ограничения.

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

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

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

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

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

Интерпретация результатов расчета. На этом этапе данные расчета превращаются в понятные для пользователя объекты: заявки на закупку, заказы на перемещения, производственные задания и пр. В рамках этого шага производится парсинг, т.е. разбор результатов планирования до нужной заказчику детализации, и, если это необходимо, пеггинг (pegging), в ходе которого материальные потоки по транспортной сети обогащаются аналитикой конечного заказа на продажу. Затем производится экспорт данных из транзакционного OLTP-хранилища в OLAP-структуры для последующего анализа построенного плана с помощью BI отчетности. Финал этапа − выгрузка результатов планирования в смежные системы для их дальнейшего исполнения.

Помимо технических сложностей есть и организационные задачи, которые нужно решить в ходе проекта. Для проведения интегрированного планирования, охватывающего все сферы деятельности компании, лучше всего сформировать отдельное подразделение. Сотрудники такого отдела должны размещать ответственность за результаты планирования в одной области для исключения конфликтов интересов между службами компании – логистикой, снабжением, сбытом и т.д. Также отдел должен заниматься операционной работой с ограничениями: поддерживать актуальность и целостность, корректировать в рамках what-if-анализа и пр. Наконец, подразделение будет поддерживать IBP-систему в функциональной части и своевременно добавлять новые бизнес-ограничения в модель.

Заключение

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

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

Эксперты нашей команды располагают богатым опытом внедрения IBP-решений на базе продуктов ведущих мировых производителей ПО – SAP и Oracle. Наша команда успешно реализовала ряд проектов по внедрению как Demand Planning, так и Supply Chain Planning компонент, наработав экспертизу по ключевым аспектам внедрения. Наш опыт включает моделирование ограничений для бизнес-процессов, организацию бизнес-процессов для максимально полного использования IBP-системы, декомпозицию сложных моделей на составные части, интеграцию со смежными системами и визуализацию планирования, в том числе с помощью BI-инструментов.