Всем привет! Меня зовут Сергей Ронжин, я архитектор CPM/IBP‑платформы Optimacros для интегрированного планирования, бюджетирования и бизнес‑аналитики. В статье поделюсь своим опытом — расскажу о планировании в FMCG‑бизнесе и том, какую цену платят компании, когда допускают ошибки в этом процессе. Чтобы добавить статье пользы, поделюсь практическими советами, как от «планирования ради плана» перейти к «планированию для прибыли». Статья будет полезна моделерам и архитекторам CPM/IBP‑решений, а также бизнес‑пользователям FMCG‑компаний и специалистам по планированию.
Реальные боли бизнеса
Планирование в FMCG — не административная задача, а ключевой инструмент управления прибылью. Но есть проблема: разрыв между теоретическими планами и реальными рыночными процессами ведет к прямым финансовым потерям.
Основные ошибки, которые допускает FMCG‑бизнес:
планирование промо не учитывает пропускную способность мощностей;
прогноз продаж оторван от графиков отгрузки;
рост запаса неликвидных позиций на складе идет параллельно с дефицитом ходового товара;
формальная загрузка оборудования скрывает фактические простои из‑за избыточных переналадок;
плановые бюджеты закупок расходятся с фактическим приходом товара;
операционные показатели не подтверждают финансовые прогнозы;
данные в отчетах не соответствуют остаткам на полках.
Почему компании совершают эти ошибки?
Конфликт интересов заложен в саму структуру FMCG‑бизнеса. Продажи хотят иметь бесконечный запас товара на складе и давать огромные скидки, чтобы выполнить план по выручке, но это «убивает» маржинальность. Маркетинг жаждет запускать десятки ярких новинок (SKU), однако для производства это кошмар — частые перенастройки линий ради малых партий повышают себестоимость и снижают эффективность. В это же время логистика разрывается между требованиями продаж «доставить всё вчера» и запросами финансов «сократить расходы на транспорт и запасы». В итоге все выполняют свой KPI, но общая цель компании может страдать из‑за рассинхронизации.
Проблема осложняется тем, что каждый отдел нередко выполняет планирование в своем собственном контуре или изолированном модуле ERP‑системы, не связанном общей бизнес‑логикой с другими отделами. Другое дело, если бы в компании был единый инструмент для планирования. Тогда бы все подразделения видели операционные планы и финансовые прогнозы друг друга. Это называется интегрированным бизнес‑планированием.
Как можно «подружить» планы различных подразделений и создать сквозное планирование на всю компанию? Рассмотрим ниже.
Архитектура современной модели планирования
Современная CPM/IBP‑платформа — это решение корпоративного класса, единый инструмент для работы с задачами корпоративного планирования и управленческой отчетности, который поддерживает на порядок больший объем данных и стабильную многопользовательскую работу. В такой системе модель — это альтернатива сотням файлов, которые используются в конкретной компании для планирования задач.
Технически модель состоит из следующих элементов:
измерения (Dimensions) — справочники (товаров, городов, подразделений), которые задают сквозную структуру данных для всей модели. Они хранятся централизованно и могут быть применены ко всем моделям;
кубы (Cubes) — показатели в таблицах, где каждый показатель содержит бизнес‑логику, служит для ввода/загрузки первичных данных, промежуточных расчетов или расчета итоговых показателей для анализа и принятия управленческих решений;
мультикубы (Multidimensional Cubes, Multicubes) — логическая структура данных, которая служит основой для моделирования и анализа бизнес‑процессов. Представляет собой аналог сводной таблицы в Excel, но с расширенными возможностями;
формулы и скрипты — это каркас алгоритмов расчета. Они позволяют вести системный контроль над применением утвержденного алгоритма планирования, что в конечном счете помогает соблюдать единообразное применение утвержденной целевой методологии;
дашборды и контекстные таблицы — интерфейсы для ввода данных и визуализации отчетов в табличном и графическом виде. Дашборды могут настраиваться проектными командами по предпочтениям пользователей.
Главная особенность модели — сквозная взаимосвязь между показателями и между подразделениями компании вдоль всей цепочки создания ценности. Так, изменение одной цифры в кубе «Производство» приведет по умолчанию к автоматическому пересчету куба «Ожидаемая прибыль» и/или «Прогнозный остаток» в режиме реального времени. Автоматический пересчет можно разорвать, например, для целей согласования (после согласования данные пересчитаются).
В моделях FMCG‑компаний практически всегда встречается сквозная взаимозависимость между показателями: прибыль зависит от своевременной отгрузки, отгрузка — от остатков на складах, остатки — от выпуска продукции, выпуск — от доступных мощностей линий, которые в свою очередь могут быть заняты другой продукцией, так же влияющей на прибыль. Сформировать оптимальный план в условиях мультизависимости не всегда удается Excel‑подобной формульной логикой.
Обычно бизнесу приходится вручную принимать решения: какой продукт поставить в производство в срок, какой ради этого подвинуть «влево»? Не будет ли затоваривания? А может быть, подвинуть на другую, менее мощную линию? Или вообще выгоднее отказаться от производства самых низкомаржинальных позиций, чем выводить операторов на линию в праздники по двойной ставке? Все эти задачи — «по зубам» только планерам с огромным опытом, однако и опыт — не гарантия однозначно оптимального результата.
Кстати, и нейросетям они не «по зубам», так как задачи планирования в корпоративном секторе на миллионы рублей требуют принципиально более высокой степени контроля процесса, которую «черный ящик» ИИ по определению дать не может: не может объяснить, почему и как он выбрал то или иное решение.
Между тем это типичные задачи оптимизации. У них есть математическое решение, но для его нахождения требуются не формулы и не ИИ, а солверы — оптимизационные библиотеки‑«решалки».
Оптимизация в бизнесе — что это?
Задачи по поиску оптимального решения чаще всего сводятся к линейной оптимизации (MILP‑задачам). Все показатели, кубы, клетки модели образуют систему линейных неравенств. Далее задача в LP‑формате передается в солвер — библиотеку для решения оптимизационных задач, которая находит массив решений, удовлетворяющих всем заданным условиям и при этом наилучшим образом влияющих на целевую функцию (например, максимизацию ожидаемой прибыли или минимизацию затрат/потерь).
Например, к платформе Optimacros подключены несколько солверов, в том числе COIN‑OR — open‑source‑библиотека для решения оптимизационных задач производственного уровня, показавшая наилучшие результаты (в совокупности по количеству, сложности и скорости решенных типовых задач) по сравнению с другими библиотеками, доступными на данный момент в России.
Моя цель как архитектора — построить модель так, чтобы создать технически оптимальное решение бизнес‑задачи заказчика и сократить трудоемкость поддержки и развития модели.
Рассмотрим несколько кейсов из сферы FMCG. Каждый пример демонстрирует, как можно архитектурно преодолеть те или иные трудности, возникающие в ходе проекта.
Кейс 1. План производства «горизонтальной нарезкой» для пищевого предприятия
У крупной пищевой компании несколько площадок, широкий ассортимент продукции, жесткие ограничения по мощностям и высокая зависимость финансового результата от точности планирования.
Предыдущая система планирования производства перестала быть устойчивой — поддержка SAP прекращалась, а попытки заменить ее Excel‑моделями приводили к росту ручной работы и потере управляемости.
Основные проблемы, с которыми к нам пришел заказчик:
план производства собирался в несколько итераций с ручными корректировками;
не было единой модели, которая бы одновременно учитывала мощности, партии, спрос и ограничения;
пересчет плана занимал слишком много времени, поэтому решения принимались «по опыту», а не исходя из расчетов;
при изменении методологии приходилось фактически перестраивать процесс заново;
руководство видело отклонения по запасам и загрузке, но не могло точно определить, где возникает потеря эффективности.
Отдельной болью заказчика было рабочее время сотрудников, трудоемкость процесса построения первичных планов и их актуализации. В проект стоило входить хотя бы ради того, чтобы оптимизировать этот ресурс.
Ограничения SAP
В ходе проекта, который начинался как миграция с SAP, мы обнаружили, что под «оптимизацией» в исходной модели понимается приоритизация производства. То есть вместо поиска лучшего ответа на вопросы «что?», «где?», «когда?» и «в каком объеме производить?» система строила прямолинейный план по строго заданной формуле «сначала это, потом это». В SAP это работало как вынужденное решение, но прямого переноса методология не пережила: для того, чтобы превратить задачу в оптимизационную, понадобилось переписывать методологию.
Совместно с заказчиком мы пришли к выводу, который неоднократно наблюдали на других проектах: в SAP нет полноценного оптимизационного модуля.
Декомпозиция задачи почти всегда необходима
Следующим подводным камнем на проекте стал объем задачи: 600 SKU в нескольких вариантах производства, 20 линий, 3 завода, сообщающихся между собой с разным временным шагом, — это неподъемно для оптимизационной библиотеки. К тому же клиенту было важно, чтобы модель строго оперировала минимальными партиями производства и кратными шагами округления партий, что вводило сотни тысяч целочисленных переменных. Их количество наиболее существенно влияет на производительность (время отработки) оптимизатора — специального модуля, который помогает решать оптимизационные задачи. Одним из подходов методологического и архитектурного решения был отказ от целочисленности переменных объема (с последующим округлением цифр на дашбордах) — это на порядки ускоряло решение, но давало погрешность до 30% на некоторых товарах. Ключом решения стал ABC‑XYZ‑анализ номенклатуры выпуска и разделение ассортимента на три категории:
Мы выделили товары‑«хаймуверы» и применили для них метод с округлением (данный оптимизатор считает за секунды и почти не дает погрешности).
Для средних товаров оставили исходную методологию (самая тяжелая часть в плане производительности).
Для товаров, производимых редко и мелкими партиями, мы разработали свою «матрицу переходов», привязав их производство к товарам‑«локомотивам» (находка, которая сильно упростила задачу, подсказав оптимизатору более выгодную ветку дерева решений и сэкономив время на проверке остальных веток).
Таким образом мы «нарезали» справочник SKU “слоями”, применили для каждого слоя наиболее подходящую методологию, внедрили в процесс планирования производства три оптимизатора, запускаемые последовательно. «Нарезка» гибко настраивается на дашборде планера и любой продукт по желанию может быть перемещен в другую категорию и пересчитан в другой методологии.
Agile — подход, оставляющий пространство для экспериментов
Важно, что проект велся в Agile‑формате, и функциональные заказчики всегда были на связи. После каждого этапа мы тестировали модель, вносили изменения в расчеты и постепенно доводили систему до состояния, в котором она могла использоваться в операционной работе.
После внедрения компания получила не просто новый инструмент, а управляемую систему планирования производства с фокусом на максимальный экономический результат.
Основные улучшения в процессах, которые получил заказчик:
план производства формируется автоматически с учетом всех ограничений;
время подготовки плана сократилось с нескольких итераций ручной работы (раньше занимало до двух дней) до одного автоматизированного расчета (4 минуты);
на 20% более маржинальное планирование;
быстрая проверка разных сценариев;
снизилось количество корректировок после утверждения плана;
руководство получило прозрачную модель, в которой видно, из‑за чего возникают излишки, дефицит или перегрузка мощностей.
Отдельный важный результат — появилась возможность менять правила планирования без остановки работы системы. Это означает, что модель развивается вместе с бизнесом, а не устаревает через год после внедрения.
Кейс 2. План производства «вертикальной нарезкой» для крупного международного бренда по изготовлению продуктов питания
Проблема комплексности процессов
Рассмотрим кросс‑функциональную задачу, когда разделить продукты на производственные категории не получается. Более того, от объема выпуска готовой продукции (ГП) на той или иной линии зависит потребность в полуфабрикатах смежных линий. Полуфабрикаты быстро портятся и поэтому они должны быть полностью отгружены со склада производителя неделя в неделю, да еще и с исполнением минимальной партии — MOQ. Это создает необходимость оптимизировать производство всех SKU единой задачей, что делает ее более сложной для библиотеки оптимизации.
По умолчанию производственный план распределяется по неделям таким образом, чтобы производить необходимые объемы в периоде их плановой отгрузки (Just in Time). Если доступных мощностей для производства всех SKU по принципу Just in Time недостаточно, недоудовлетворенная потребность в производстве смещается на другую (менее эффективную) линию или влево по шкале времени (нужно произвести необходимый объем раньше, увеличив таким образом запасы, но гарантировав выполнение планов отгрузок).
Делаем декомпозицию, даже когда она кажется невозможной
Мы применили «вертикальную нарезку» задачи: настроили каскад запусков оптимизационного расчета по неделям, начиная с самой «левой» (наиболее ранней актуальной).
Допустим, сейчас идет тридцатая неделя года — W30 (см. скриншот ниже). На дашборде планер настраивает оптимизатор на период с W30 по W37 и нажимает кнопку. Как только система построит план на ближайшие 8 недель, она сама переназначит себе рамки задачи на период W37–W44 и автоматически начнет искать решение для следующих восьми недель. И так будет повторяться, пока оптимизатор не достигнет заданного горизонта задачи (в нашем случае до двух лет).
Можно выставить более гибкую настройку: в первую итерацию задать более длинной, а шаг следующих итераций выставить меньше — тогда расчет пойдет быстрее, и мы получим обновленный план буквально за время обеденного перерыва. Удобно, когда утром пришли правки и нужно всего лишь перезапустить оптимизатор. В целом время решения оптимизационной задачи может занимать часы и дни (зависит преимущественно от масштаба переменных в задаче, а не от технического инструмента). Если задачу удается решить с приемлемой точностью в пределах одного часа — это победа.
Цена декомпозиции
Описанный выше итеративный подход позволяет «шифтить» (сдвигать) производство влево от деманда не далее края текущей итерации, что может быть критично: планеру нужно внимательно следить, чтобы пиковые недели спроса или праздничные дни (недели ограниченной мощности) не попадали в начало одной из итераций. В приведенном примере план на W37 будет построен дважды. Сперва как завершающая неделя первой итерации — недоудовлетворенная потребность в производстве переедет влево, затем как открывающая неделя следующей итерации — оставшаяся мощность будет занята полностью, двигать план с W38 влево можно будет только за счет расхода Safety Stock (SS) или Out of Stock (OOS) (на момент переноса системы в продуктив в бэклоге проекта находится идея увеличить «нахлест» между итерациями или сделать его настраиваемым, но плюсы и минусы этой идеи пока недостаточно проработаны, чтобы про них рассказывать в этой статье).
Не всегда необходимо задавать оптимизационной модели жесткие ограничения. Можно разрешить ей иногда нарушать базовые ограничения, но с большими штрафами (то есть решением может быть комбинация параметров с выходом за некоторые ограничения, но каждый такой выход за ограничения должен быть оправдан существенной выгодой в смежных параметрах).
Выбранный подход позволил удержать годовое планирование в пределах ночного запуска (в то время как полный прогон всей задачи единым горизонтом требовал нескольких суток) и сохранить требуемую гибкость: разрешить системе нарушать гибкий капаситет (до 168 часов), минимальные и максимальные покрытия на складе, в крайних случаях с очень большими штрафами нарушать минимальные партии ГП и создавать OOS.
Условия задачи — жесткие ограничения vs штрафы
Даже у комплексного подхода с множеством гибких условий есть недостатки: каждое гибкое условие, каждый расчет штрафа — это дополнительное слагаемое в целевую функцию, а значит, к четкой, понятной каждому управленцу функции маржинальности приходится добавлять ничего не значащие с финансовой точки зрения технические слагаемые. Оптимизация одного слагаемого влечет за собой неоптимальное значение другого и наоборот. Чтобы их сбалансировать и добиться желаемых результатов (не всегда экономически обоснованных, а иногда опирающихся на привычку, опыт или устоявшиеся практики, например, с этим продуктом в этом цеху обычно производят этот продукт), применяются различные веса и коэффициенты, которые еще больше размывают получившийся экономический смысл. Иными словами:
В результате оптимизатор старается свести к минимуму уже не совсем косты.
Оптимизация каждого из слагаемых может противоречить друг другу, и чем их больше, тем более спорным является полученное решение.
Тестирование, как и в предыдущем случае, заняло более двух месяцев, так как сбалансировать параметры оптимизационной модели ограничениями и штрафами было непросто. Также при тестировании вскрылись многочисленные неточности мастер‑даты (нормативно‑справочной информации), которые ошибочно говорили системе, что одни продукты дешевле, чем другие (влияет на то, какой продукт система более склонна уводить в Out of Stock).
Результат
Удалось внедрить процесс планирования в необходимой заказчику детализации на текущий и следующий годы, который ранее в компании отсутствовал.
Урок проекта: согласуйте методологию заранее. Когда между пользователями нет единого понимания, что модель должна уметь, какие критерии важнее, а какими можно пожертвовать, балансировка критериев может превратиться в многоитерационный процесс.
Кейс 3. План‑график производства с приоритетами для международного бренда кофе
Обманчивая простота задачи графикования
Когда план производства в разрезе «SKU — линия — неделя» построен, нужно свести график и отдать в цех четкое указание, что и в каком порядке запускать на линию. Казалось бы, здесь ключевой показатель для оптимизации один — минимизация времени переходов. Но если бы это было так просто, задачу графикования производства можно было бы решить в Excel функцией «Поиск решения» — она достаточно хороша для небольших задач перебора (до тысячи переменных).
Перейдем к кейсу. Международный бренд кофе производит до 40 наименований на одной линии, в одну неделю производить нужно до 27 из них. Нужно учитывать переходы между продуктами одного формата (короткие) и переходы между форматами (длинные). Аналогичная матрица переходов есть по блендам. Плюс некоторые виды продукции требуют чисток оборудования.
Сведение задачи к линейной
Задача сводится к линейной через введение нескольких десятков тысяч квази‑булеан‑переменных и должна быстро считаться (до 15 минут на одну линию) дважды в неделю. У специалистов заказчика был «на кончиках пальцев» подход с приоритетами: трудоемкий, но дающий оптимальный план‑график. Таким образом, ключевая ценность, которую может дать оптимизация, это время, необходимое для построения плана. Чтобы оптимизатор точно выполнил запрос по производительности на любых реалистичных объемах входящих данных, опираясь на опыт заказчика, добавили приоритеты:
Первый продукт — в идеале тот же, на котором заканчивается план предыдущей недели (или хотя бы тот же формат, тот же бленд). За это даем системе большой бонус
Ручные приоритеты — клиент выставляет вручную часть цепочки, в которой заранее уверен, чтобы упростить задачу оптимизатору. Можно назначить первым приоритетом несколько продуктов, и тогда система выстроит их в оптимальной последовательности и лишь затем перейдет к следующим.
Переходы между форматами — тот самый ключевой бизнес‑показатель, ради которого всё и затевалось.
Переходы между блендами — менее важный показатель, который добавили в ходе проекта. Если вы не уверены в вашей методологии и хотите внедрять новую систему планирования гибко, используйте Agile‑подход.
Переходы между продуктами — минорный показатель. При прочих равных ранжирует продукты по запрашиваемому объему выпуска.
Последний приоритет — клиент также может знать заранее, на каком продукте или группе продуктов следует закончить. Например, компоненты для производства задерживаются или этот продукт планируется и на следующей неделе.
Приоритизация vs оптимизация
Однако, как мы отмечали в первом кейсе, приоритизация не входит в функционал линейной оптимизационной задачи. Солвер решает задачу целиком и может вернуть ответ, не в полной мере отражающий заданные приоритеты, если сумма костов окажется более оптимальной в подобранном решении. «Нарезка» задачи на 6 последовательных запусков в данном кейсе нецелесообразна, поскольку в каждом приоритете штучное количество продуктов. Поэтому мы присвоили приоритетам коэффициенты — веса — и подобрали их значения так, чтобы дать оптимизатору наиболее очевидное понимание, какие условия ценнее.
Около 2–3 недель у нас ушло на то, чтобы протестировать разные коэффициенты приоритетов — в результате приоритеты на практике соблюдаются во всех реалистичных случаях. Удалось подобрать их так, чтобы система однозначно понимала, что выгоднее исполнить в первую очередь более высокие приоритеты, при этом важно отследить, чтобы вес каждого отдельного перехода не становился пренебрежимо мал.
Результат
Ранее весь график строили вручную в Excel, затем переносили в SAP.
«Сейчас всё в одном окне, плюс в автоматическом режиме появилось разделение ордеров (объемов рана) на разные периоды (отчетные месяцы), обновление факта и пересчет производства остатков. Экономия времени составила примерно 25–30% за счет автоматизации рутины, — поделился специалист клиента. — Из побочных эффектов более точное определение капаситета упаковочных линий с минимальными расхождениями с блоком Production Planning в этой части, что позволяет более точнее планировать производство как в коротком, так и в длинном горизонте. Это и позволяет оптимизировать штатное расписание производственного персонала».
Измеримые эффекты: на что можно рассчитывать
Интегрированное бизнес‑планирование — это кросс‑функциональный процесс, требующий вовлечения топ‑менеджмента и ключевых специалистов автоматизируемых процессов: чтобы внедрить систему, которая их разгрузит, на время проекта придется их загрузить.
Первый шаг — аудит текущих процессов и выявление точек наибольших потерь. Согласование критериев успешного результата. Без этого шага можно потерять много времени над «почти готовым» проектным решением.
Внедрение современных подходов — это эволюция, а не революция. Можно начинать с пилотной выборки продуктов и самого критичного процесса и идти top‑down (сверху вниз) или bottom‑up (снизу вверх). Главное, не бояться экспериментов и быть открытыми к best practice.
При неоднозначности методологии (когда мы внедряем новый процесс, меняем либо ищем новую архитектуру) необходимую гибкость (и микроклимат в команде) даст Agile‑подход к управлению проектом с расчетом по Time&Material.
Так, благодаря методам математической оптимизации происходит переход от планирования как функции к планированию как к конкурентному преимуществу, напрямую влияющему на итоговую прибыль за счет выбора многомерных оптимальных решений.
