Программное обеспечение для оптимизации розничной торговли, Февраль 2025

От Léon Levinas-Ménard

Last modified: February 2nd, 2025

Введение: Сегодня розничные торговцы сталкиваются со сложными задачами оптимизации, охватывающими уровни запасов, ценовые стратегии и ассортимент товаров. Ряд поставщиков программного обеспечения обещают решения на базе «искусственного интеллекта», способные справиться с этими задачами, однако отделить истинные технологические инновации от устаревших систем и маркетингового шума требует тщательного анализа. В данном исследовании ведущие поставщики программного обеспечения для оптимизации розницы оцениваются по строгим критериям. Мы уделяем внимание возможностям совместной оптимизации (запасов, цен и ассортимента вместе), вероятностному прогнозированию (настоящим AI/ML прогнозам против упрощенных методов), экономическому моделированию решений (принятию решений на основе прибыли и альтернативных издержек вместо статических правил), масштабируемости и экономичности (способности обрабатывать крупные розничные сети без чрезмерных требований к оборудованию), учету сложных розничных факторов (например, каннибализация продуктов, эффекты замещения, скоропортящиеся товары/срок годности), автоматизации (уровня автономного принятия решений против необходимости ручного вмешательства), интеграции технологий (согласованного технологического стека против «Франкенштейнских» платформ, собранных из приобретений) и скептического отношения к модным словам («чувствительность спроса», «plug-and-play» и т.д.). Каждый поставщик анализируется с инженерной тщательностью, с использованием достоверных данных и минимизацией опоры на маркетинговые заявления. Ниже мы ранжируем поставщиков от самых продвинутых до наименее продвинутых, выделяя их сильные стороны, слабости и правду, скрытую за их заявлениями.

Критерии оценки платформ для оптимизации розницы

Прежде чем перейти к профилям поставщиков, суммируем основные применяемые критерии оценки:

Совместная оптимизация (Запасы + Цены + Ассортимент): Оптимизирует ли решение эти аспекты комплексно, признавая их взаимозависимость? Или они функционируют раздельно? По-настоящему продвинутые платформы рассматривают цены, запасы и ассортимент как взаимосвязанные рычаги единой задачи оптимизации, а не как отдельные модули ¹. Например, изменение цены должно влиять на прогнозы запасов и решения по ассортименту в единой модели.
Вероятностное прогнозирование и ИИ: Использует ли поставщик современные технологии AI/машинного обучения для создания вероятностных прогнозов (распределения спроса, а не единичных точечных предсказаний)? Вероятностное прогнозирование имеет решающее значение для обоснованных решений в условиях неопределенности ². Мы ищем доказательства применения моделей машинного обучения, нейронных сетей или других технологий ИИ, которые улучшают точность прогнозирования за счет изучения сложных закономерностей (сезонность, тренды, акции и т.д.) и количественной оценки неопределенности. Поставщики, продолжающие использовать упрощенные методы (например, ручную настройку или базовые формулы) или рассматривающие прогнозы как детерминированные значения, подвергаются критике.
Экономическое принятие решений: Обуславливаются ли решения платформы экономическими целями (максимизация прибыли, соотношение затрат на хранение против потерь от отсутствия товара, окупаемость использования торговых площадей и т.д.)? Оптимизация розницы требует большего, чем просто достижения уровня обслуживания – это означает максимизацию ожидаемой прибыли в условиях неопределенности. Мы отдаем предпочтение решениям, которые включают в свои алгоритмы маржу, затраты на хранение, расходы на уценку и альтернативные издержки. Правила на основе эвристик или целевых показателей обслуживания могут оказаться неэффективными, если игнорировать конечную цель – рентабельность ³.
Масштабируемость и экономичность: Способно ли программное обеспечение эффективно обрабатывать розничные данные на уровне предприятия (тысячи магазинов, миллионы SKU, большой объем транзакций)? Решения, зависящие от монолитных вычислений в оперативной памяти (например, загрузка всех данных в ОЗУ), могут испытывать трудности с масштабированием или требовать непомерно дорогое оборудование ⁴. Мы предпочитаем облачные архитектуры, микросервисы и распределенные вычисления, которые масштабируются экономически эффективно, и критикуем решения, известные высокими затратами на оборудование или низкой производительностью при работе с большими данными.
Учёт сложных розничных факторов: Реальный спрос в рознице хаотичен – каннибализация продуктов (продвижение одного продукта, забирающее продажи у другого ⁵ ⁶), эффекты замещения (когда товар отсутствует, спрос на похожий товар возрастает), «эффект ореола» (взаимное повышение продаж сопутствующих товаров ⁷), сезонные всплески, региональные различия и скоропортящиеся товары с установленными сроками годности. Мы оцениваем, учитывают ли алгоритмы каждого поставщика эти сложности – например, с помощью машинного обучения для выявления взаимосвязей между продуктами ⁸ ⁹ или отслеживания запасов по сроку годности. Решения, предполагающие независимость спроса на каждый продукт или игнорирующие скоропортящиеся товары, менее готовы к будущим вызовам современной розницы.
Автоматизация и автономная работа: Обещание «автономной розницы» заключается в том, что система может принимать большинство оперативных решений (заказы, изменения цен, уценки, изменения ассортимента) автоматически, позволяя людям сосредоточиться на стратегических исключениях. Мы оцениваем, обеспечивает ли программное обеспечение безконтактное планирование – например, автоматические заказы на пополнение запасов на основе прогнозов, автоматическую корректировку цен в установленных пределах – или всё еще зависит от того, чтобы планировщики постоянно вручную проверяли и корректировали решения. Поставщики, рекламирующие ИИ, должны, в идеале, снижать ручную нагрузку («рутинная работа по планированию», как это иногда называют ¹⁰), а не увеличивать её.
Интеграция технологий против «Франкенштейнских» платформ: Многие крупные поставщики росли за счет приобретений, присоединяя отдельные инструменты для прогнозирования, ценообразования и планирования под единым брендом. Мы исследуем, является ли решение поставщика согласованной платформой или набором модулей с разными интерфейсами и моделями данных. Интеграция типа «Frankensoft» часто приводит к высокой сложности и долгим срокам внедрения ¹¹. По-настоящему современные решения, как правило, строятся на едином технологическом стеке или, по крайней мере, бесшовно интегрируются посредством микросервисов. Мы критикуем поставщиков, у которых отдельные части до сих пор не функционируют как единое целое (несмотря на маркетинговые заявления о «единосторонней» платформе).
Скептицизм в отношении модных слов и хайпа: Технологическая сфера розницы изобилует модными словами, такими как «чувствительность спроса», «интеграция на основе ИИ, plug-and-play», «когнитивная цепочка поставок» и т.д. Наш анализ отфильтровывает расплывчатые заявления и ищет подтверждения. Поставщики, опирающиеся на жаргон без ясных объяснений или рецензируемых исследований, подвергаются критической оценке. Например, «чувствительность спроса» часто воспринимается как универсальное решение, однако некоторые эксперты считают это маркетинговым трюком, не приносящим новой ценности ¹². Мы отмечаем такие случаи и отдаем предпочтение поставщикам, которые предоставляют конкретные, достоверные доказательства своих возможностей.

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

1. Lokad – Единая, вероятностная оптимизация с скептическим ИИ

Lokad — новый игрок на рынке (основана в 2008 году), который с нуля построил свою платформу вокруг вероятностного прогнозирования и оптимизации решений для розницы и цепочки поставок. В отличие от многих конкурентов, Lokad намеренно стремился объединить ценообразование, управление запасами и планирование спроса в единой системе, а не рассматривать их как отдельные изолированные функции ¹³ ¹⁴. Такой подход основан на понимании того, что ценовые решения напрямую влияют на спрос и потребности в запасах, и наоборот. Основатель Lokad отметил, что исторически прогнозирование и ценообразование осуществлялись разными инструментами, но на самом деле «спрос и ценообразование глубоко взаимосвязаны», что побудило Lokad объединить эти функции в единую аналитическую структуру ¹⁵ ¹⁶. Они даже разработали собственный предметно-ориентированный язык программирования («Envision») для моделирования решений в цепочке поставок, что позволило создать высоко кастомизированную оптимизацию, которая объединяет логику ценообразования, управления запасами и формирования ассортимента ¹⁷ ¹⁶.

Совместная оптимизация: Философия Lokad заключается в том, что нельзя оптимизировать запасы, не учитывая ценовую стратегию, и наоборот. Они объединили ценообразование и планирование спроса в одной платформе – например, их система может оптимизировать количество повторных заказов, одновременно предлагая корректировки цен, что гарантирует, что ценообразование не выводит спрос из строя запасов ¹. Внутреннее исследование описывает стратегию «ценообразования на основе запасов», где цены динамически корректируются в зависимости от уровня запасов, эффективно координируя ценообразование с доступностью товаров. Благодаря использованию одних и тех же данных (история продаж, информация о продукте и т.д.) для моделей ценообразования и прогнозирования, Lokad избегает изолированности данных, характерной для традиционных IT-систем розницы ¹⁸ ¹⁶. Этот совместный подход является передовым, хотя и требует от ритейлеров принятия алгоритмического ценообразования – важного аспекта управления изменениями. Готовность Lokad решать задачи ценообразования и управления запасами совместно обеспечивает ей по-настоящему перспективные возможности, которые недоступны многим устаревшим поставщикам.

Вероятностное прогнозирование и ИИ: Lokad является ярым сторонником вероятностного прогнозирования. Их платформа создает полные распределения вероятностей спроса (для каждого товара и периода) вместо простых точечных прогнозов. Lokad утверждает – и мы с этим согласны – что «для цепочек поставок вероятностные прогнозы необходимы для принятия надежных решений в условиях неопределенного будущего», что позволяет оптимизировать решения на основе ожидаемых значений и рисков ³. За счет учета диапазона возможных исходов спроса и их вероятностей, прогнозы Lokad естественным образом поддерживают экономическое принятие решений: «вероятностная перспектива естественным образом способствует экономическому приоритизированию решений на основе их ожидаемой, но неопределенной отдачи» ³. На практике это означает, что Lokad может оценить, например, ожидаемую рентабельность хранения дополнительной партии товара против риска порчи, используя полное распределение спроса. Технически Lokad использует передовые модели машинного обучения (включая квантильную регрессию и глубокое обучение) для создания этих прогнозов, и они опубликовали доказательства использования таких методов, как дифференцируемое программирование для временных рядов. Поскольку их внимание сосредоточено на точности ИИ и количественной оценке неопределенности, они избегают упрощенных метрик; в частности, они критически относятся к таким показателям, как MAPE (средняя абсолютная процентная ошибка), когда он применяется к вероятностным прогнозам, считая их концептуально некорректными ¹⁹. Это демонстрирует глубину понимания прогнозирования, которая отличает их от поставщиков, просто прибивающих к своим данным ярлык «ИИ». Технология прогнозирования Lokad явно находится на переднем крае, хотя иногда требует квалифицированной настройки с использованием их скриптового языка.

Экономическая логика решений: Вся структура Lokad построена вокруг экономической оптимизации. Они часто рассматривают проблемы цепочки поставок как задачу «максимизации ожидаемой прибыли» в условиях неопределенности, а не как достижение произвольных уровней обслуживания или минимизацию случаев отсутствия товара. Например, их алгоритмы явно учитывают альтернативные издержки отсутствия товара, затраты на хранение и расходы на уценку при рекомендации закупок запасов или изменениях цен. Благодаря тому, что они создают вероятностные прогнозы, они могут вычислить ожидаемую рентабельность каждого решения (например, сколько прибыли приносит добавление еще одной единицы товара по сравнению с риском, что она останется непроданной). Это шаг вперед по сравнению со многими инструментами, которые полагаются на заранее установленные целевые уровни обслуживания; Lokad пытается динамически вычислять оптимальный уровень обслуживания для каждого товара, исходя из экономики. По сути, их решения напрямую связаны с финансовыми результатами (например, максимизацией ожидаемого вклада маржи), что соответствует критерию оптимизации, ориентированной на прибыльность. Этот подход основан на их убеждении, что оптимизация цепочки поставок – это не только сокращение затрат, но и рациональное распределение ресурсов для максимизации отдачи. Одним из последствий является возможность комбинировать оптимизацию цен с прогнозированием спроса – избегая ловушки инструментов ценообразования, игнорирующих ограничения запасов. Собственно, сами Lokad предупреждают, что «оптимизация цен в изоляции – независимо от прогнозирования спроса – отстает от современных стандартов» ²⁰ ²¹. Внедряя ценообразование в цикл прогнозирования и оптимизации, они обеспечивают, чтобы расчеты прибыли отражали истинную реакцию спроса. В целом, экономическая направленность Lokad является лучшей в своем классе; однако это требует доверия к алгоритму. Ритейлерам необходимо быть готовыми доверить алгоритму принятие решений о компромиссах в области прибыльности, которое ранее выполняли планировщики вручную, что может стать культурным барьером.

Масштабируемость и архитектура: Lokad предоставляет свое решение в виде облачного сервиса (часто на инфраструктуре Microsoft Azure). Вместо того чтобы требовать от клиентов использования тяжелых серверов с вычислениями в оперативной памяти на месте, Lokad выполняет вычисления в своем облачном кластере, масштабируясь по мере необходимости. Эта модель вычислений по требованию избегает подхода «жестко запрограммированного куба в оперативной памяти», который используют некоторые устаревшие инструменты и который «обеспечивает впечатляющую оперативную отчетность, но гарантирует высокие затраты на оборудование» ²². В отличие от этого, Lokad может обрабатывать большие наборы данных за счет распределения нагрузки в облаке, и клиенты платят только за фактическое время вычислений. Это экономически эффективно и масштабируемо – можно добавить больше вычислительных узлов для решения большой задачи на несколько часов, вместо того чтобы закупать постоянный сервер для пиковых нагрузок. Архитектура Lokad ориентирована на код (с использованием скриптов Envision), что означает, что сложные вычисления компилируются и выполняются эффективно на сервере, а не осуществляются через громоздкий настольный интерфейс. Такой дизайн зарекомендовал себя на достаточно крупных розничных наборах данных (например, у них есть клиенты с десятками миллионов сочетаний SKU и точек продаж). Однако стоит отметить, что Lokad — более мелкий поставщик, и его масштабируемость, хотя обычно надежна, может еще не быть испытанной на абсолютно крупнейших розничных данных (например, масштаба Walmart) в той степени, как у SAP или Oracle. Тем не менее, их облачный подход принципиально более масштабируем, чем устаревшие локальные системы, зависящие от памяти. Экономическая эффективность также высока: пользователям не приходится лицензировать огромное оборудование или платить за простаивающие вычисления, поскольку ценообразование Lokad по модели SaaS основано на фактическом использовании. В целом, современная облачная архитектура Lokad дает ей преимущество в масштабируемости и стоимости, при условии, что клиенты открыты для менее традиционной, ориентированной на код системы.

Управление сложными факторами розничной торговли: Поскольку платформа Lokad по сути представляет собой гибкую программируемую среду для оптимизации, её можно настроить для явного учета сложных явлений в розничной торговле. Например, пользователи могут моделировать взаимосвязи между продуктами (заменители или комплементы) в своих скриптах Envision, чтобы прогнозы и заказы учитывали эффекты каннибализации или ореолов. Если продукты A и B являются заменителями, система Lokad может обрабатывать транзакционные данные и обнаруживать, что при отсутствии продукта A продажи продукта B растут, соответственно корректируя прогнозы. Это не обязательно функция «из коробки», переключаемая галочкой – для создания правильной модели требуется работа специалистов по данным – но такая возможность существует. Аналогичным образом могут моделироваться эффекты акций: Lokad может использовать календари промоакций в качестве входных данных и даже оптимизировать цены во время акций. Что касается скоропортящихся товаров и сроков годности, Lokad может учитывать оставшийся срок хранения в своей логике оптимизации (например, посредством повышения приоритета продажи товаров по мере приближения их срока истечения с помощью скидок или посредством предотвращения перепроизводства товаров с коротким сроком службы). Главное преимущество – гибкость: в отличие от жестких устаревших систем, подход Lokad позволяет закодировать практически любое ограничение или фактор, если у вас есть данные и экспертиза. Недостаток в том, что у системы может не быть готового «модуля каннибализации» – пользователь (или команда Lokad) должен реализовать эту логику. Тем не менее, многие поставщики вообще игнорируют эти тонкости. Собственная команда Lokad публиковала материалы на темы интеграции каннибализации в прогнозы с помощью машинного обучения (например, определение заменителей по корреляциям продаж), что свидетельствует о том, что они осведомлены и способны решать эти задачи на уровне ведущих розничных специалистов ⁸ ⁹. На практике для ритейлера со сложной динамикой категорий Lokad, скорее всего, выполнит индивидуальный проект моделирования. Такой специализированный подход может обеспечить очень точное управление такими факторами, как каннибализация, но требует консультационного взаимодействия, а не готового plug-and-play-решения.

Автоматизация: Видение Lokad ясно направлено на безруководственное принятие решений. Их платформа часто описывается как «Supply Chain Optimization as a Service», что подразумевает, что пользователь настраивает систему, а она автоматически генерирует решения (например, заказы на пополнение или изменения цен) на постоянной основе ²³. Цель заключается в том, чтобы планировщики перестали выполнять ручные расчеты и перешли к контролю за решениями, управляемыми ИИ. Система Lokad способна генерировать ежедневные или еженедельные рекомендации по заказам, которые можно напрямую интегрировать в ERP-систему ритейлера для исполнения с минимальным участием человека. Поскольку прогнозы являются вероятностными, а оптимизация основана на прибыли, идея заключается в том, что система принимает оптимальное решение и не нуждается, скажем, в интуитивной проверке каждого объёма заказа планировщиком. Конечно, на практике компании часто изначально проверяют рекомендации, но, как сообщается, многие клиенты Lokad достигли высокого уровня автоматизации (обрабатывая вручную только исключения, такие как новые продукты или крупные события). Акцент на режиме «автопилота» является отличительной чертой – в то время как некоторые устаревшие инструменты служат для поддержки принятия решений, полагаясь на интерпретацию планировщика, Lokad стремится быть программным обеспечением для принятия решений. Один из примеров успешной автоматизации: продовольственный ритейлер, использующий Lokad, смог запустить автоматическое пополнение магазина, которое адаптивно подстраивалось под изменения спроса, одновременно достигая значительного сокращения порчи и дефицита товаров ²⁴. Это соответствует отраслевым исследованиям, согласно которым автоматическое пополнение, основанное на прогнозах, может сократить отходы двузначными процентами ²⁴. Скриптовый язык Lokad позволяет пользователям кодировать бизнес-правила (например, никогда не допускать, чтобы запасы опускались ниже минимального уровня представления), так что автоматизация учитывает реальные ограничения. В целом, Lokad получает высшие оценки за продвижение действительно безруководственной оптимизации. Единственный нюанс заключается в том, что первоначальная настройка (кодирование и тестирование модели) требует значительных усилий; пока модель не будет доработана, нежелательно автоматизировать решения. Но после настройки система может работать с минимальным участием человека, значительно превосходя уровень автоматизации в устаревших системах MRP или планирования.

Интеграция технологий: Lokad полностью разработан внутри компании на единой технологической платформе. Он не рос за счет приобретения программного обеспечения других компаний, а был разработан с собственным движком прогнозирования, оптимизационным решателем и скриптовым языком. Это позволяет создать очень интегрированную платформу – все функции (прогнозирование, ценообразование, оптимизация запасов) работают на единой модели данных и одном языке. Нет необходимости интегрировать «модули» через интерфейсы; всё выполняется в среде Envision. Это ярко контрастирует с некоторыми конкурентами, которым приходится объединять купленные инструменты ценообразования с отдельными решениями для планирования. Единый подход Lokad снижает сложность и предотвращает несоответствия. Например, результат прогноза спроса напрямую поступает в логику оптимизации ценообразования в том же скрипте – без необходимости пакетной передачи файлов или неудобных вызовов API между разными системами. Более того, платформа Lokad относительно легковесна (она не требует полноценной реляционной базы данных или OLAP-куба; их системы хранения и вычислений оптимизированы для конкретных задач). Можно сказать, что технологический стек Lokad «готов к будущему», поскольку он постоянно совершенствуется в комплексе, а не содержит устаревших компонентов, нуждающихся в замене. Недостаток этой оригинальной технологии в том, что она уникальна – клиентам приходится осваивать метод работы Lokad, который отличается от типичных инструментов планирования с графическим интерфейсом. Но с инженерной точки зрения, согласованность технологического стека превосходна. Нет «Франкенштейна» из приобретенных частей; даже их интерфейс и аналитика созданы специально вокруг их основного движка. Эта простота также означает меньше точек отказа при интеграции – что является большим плюсом при достижении полной автоматизации.

Скептицизм в отношении хайпа: Примечательно, что Lokad открыто относится с недоверием к отраслевым модным словам, и это мышление пронизывает позиционирование их продукта. Компания публиковала критику таких концепций, как «чувствование спроса», называя это «еще одним модным словом для цепочки поставок, которое не оправдывает ожиданий», по сути, мутным программным обеспечением (ПО, которое существует, но не приносит ожидаемой ценности) ¹². Такой скептический взгляд на самом деле является их сильной стороной: он свидетельствует о том, что Lokad пытается основывать свой продукт на твердой научной базе, а не на модном маркетинге. Например, Lokad не поддался моде на «блокчейн в цепочке поставок» и не преувеличивал роль «цифрового двойника» (о чём также говорил их основатель). Вместо этого они сосредотачиваются на конкретных технических возможностях, таких как вероятностное прогнозирование и оптимизация квантилей. Что касается утверждений поставщиков, заявления Lokad, как правило, конкретны. Они избегают обещать невероятно простую реализацию «plug-and-play» или магический ИИ «из коробки». Фактически, они часто предупреждают, что внедрение продвинутой оптимизации является сложным процессом и требует индивидуальной адаптации под каждый бизнес (отсюда их акцент на программном языке для кодирования особенностей каждого клиента). Эта честность освежает в области, где полно завышенных обещаний. Недостаток такого скромного маркетинга может сделать Lokad менее ярким по сравнению с конкурентами, громко заявляющими о «автономной цепочке поставок с когнитивным ИИ». Но с точки зрения поиска истины, заявления Lokad, как правило, подкреплены фактами – например, если они говорят о снижении запасов на 5% у клиента, то это обычно подтверждено детальными кейс-стадиями, а не общими заявлениями. Они даже открыто обсуждают ограничения методов (в блогах Lokad можно найти статьи, где анализируются неудачи классических методов). Эта прозрачность повышает доверие. В целом, Lokad предстает как решение для техно-специалистов – основанное на прочных принципах инженерного дела и аналитики, объединяющее прогнозирование и оптимизацию, и избегающее хайпа. Такой подход, можно сказать, является золотым стандартом технической изощренности (вероятностное, ориентированное на прибыль, построенное в облаке). Основной нюанс в том, что Lokad – компания меньшего масштаба и менее проверенная в условиях массовых операций по сравнению с некоторыми лидерами рынка, и её модель требует квалифицированной индивидуальной реализации для каждого клиента, а не готового продукта. Но с точки зрения сырой мощности и перспективного дизайна, Lokad занимает одно из первых мест среди поставщиков в области розничной оптимизации.

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

Источники: Интеграция данных ценообразования и планирования от Lokad ²⁵; акцент на вероятностных прогнозах для надежных, ориентированных на прибыль решений ³; критика модных терминов, таких как чувствование спроса ¹².

2. RELEX Solutions – Объединенное планирование для розничной торговли с передовым ИИ (и с непростой работой)

RELEX Solutions (основана в 2005 году) – быстрорастущий поставщик, специализирующийся на планировании и оптимизации в ритейле, охватывающий прогнозирование, пополнение запасов, распределение, ассортимент, а теперь и оптимизацию цен. RELEX заработала репутацию в секторах продовольственного и специализированного ритейла, обеспечивая измеримые улучшения в доступности товаров и сокращении отходов. Их платформа создана специально для решения вызовов розничной торговли (товары с коротким сроком годности, огромное количество SKU, планирование для каждого магазина) и известна использованием продвинутого машинного обучения и in-memory движка обработки данных для оперативной реакции в реальном времени. RELEX предлагает единое решение, охватывающее прогнозирование спроса, автоматическое пополнение, планирование пространства и ассортимента, а недавно – и ценообразование, что делает его одним из немногих поставщиков, помимо Lokad, способных охватить все три ключевых направления (запасы, ценообразование, ассортимент) в интегрированном виде. Компания обладает сильной инженерной культурой (основана тремя докторскими выпускниками в области компьютерных наук) и значительно инвестировала в исследования и разработки в области ИИ для розничной торговли. Мы оцениваем RELEX очень высоко за её специфические для ритейла возможности и доказанные результаты, отмечая при этом некоторые потенциальные недостатки, связанные с тяжеловесностью системы и необходимостью подтверждать маркетинговые заявления конкретными данными.

Совместная оптимизация: Платформа RELEX довольно целостна для розничных операций. Изначально она начиналась с прогнозирования и пополнения запасов, но затем расширилась до оптимизации ассортимента и планограммирования, а также предлагает модули оптимизации цен ²⁶. Это означает, что ритейлер может использовать RELEX для определения какие товары предлагать в каждом магазине (ассортимент), сколько закупать (запасы) и по какой цене продавать (ценообразование) – всё в рамках одной системы. Интеграция этих элементов всё ещё находится в процессе совершенствования – исторически RELEX выделялась в оптимизации запасов (пополнение магазинов/центров распределения) и планировании пространства, и только недавно добавила возможности оптимизации цен. Однако они заявляют, что их оптимизация цен синхронизирована с их прогнозным движком, что позволяет принимать решения по ценообразованию с полным учетом влияния на спрос ²⁷. Например, RELEX может смоделировать, как изменение цены на ключевой товар повлияет не только на его продажи, но и на товары-комплементы или заменители, благодаря тем же базовым моделям прогнозирования. Кроме того, функция планирования акций в RELEX связывает ценовые акции с процессом прогнозирования спроса: акции вносятся в систему, которая затем корректирует прогнозы и предлагает формировать запасы, а также может рекомендовать механику проведения акций. Такой уровень совместного учета является значительным преимуществом. Особо выделяется способность RELEX координировать пространство (емкость полок) с прогнозированием – к примеру, если изменения в ассортименте или ценах ожидается привести к увеличению объема продаж, система сигнализирует о недостатке места на полках. Тем не менее, RELEX пока может не оптимизировать одновременно и цену, и запасы в одном алгоритме (скорее, сначала прогнозируется спрос при заданной цене, а затем оптимизируется пополнение запасов, а не проводится одновременная оптимизация для достижения максимальной прибыли). Все же, в рамках одной платформы, обратные связи работают теснее, чем если бы ритейлер использовал отдельные инструменты. RELEX явно позиционирует себя как решение для «единого розничного планирования», и кейс-стадии показывают, что клиенты используют его от начала до конца (от долгосрочных решений по ассортименту до ежедневных заказов в магазинах). Мы даем RELEX высокую оценку за широкие возможности; явных функциональных пробелов в розничной сфере не наблюдается. Единственный минус заключается в том, что интеграция всех этих компонентов может быть сложной – это единое решение, однако внедрение каждого модуля (мерчендайзинг, цепочка поставок, ценообразование) является масштабным проектом.

Прогнозирование на основе вероятностей и ИИ: RELEX известен своим широким использованием ИИ/МЛ для повышения точности и детализации прогнозов. Они разработали модели машинного обучения, которые учитывают множество факторов спроса: «сезонность, тренды, особенности будних дней, акции, изменения в оформлении витрин, праздники, погода, действия конкурентов» и др. ²⁸ ²⁹. Такой многофакторный подход выходит за рамки традиционных методов анализа временных рядов. Алгоритмы МЛ RELEX автоматически выявляют, какие факторы важны для каждого продукта (выбор признаков), и могут обнаруживать сдвиги в моделях спроса (определение точек изменений при внезапных изменениях трендов) ³⁰ ³¹. Одной из впечатляющих техник, которую они используют, является объединение данных для разреженных выборок – для товаров с медленными продажами модель группирует похожие продукты, чтобы извлечь сигнал и улучшить прогнозы ³¹. Всё это – современные методы ИИ, которые вы ожидаете увидеть в академической среде, теперь применяемые в коммерческом инструменте. Результат, по их словам, – прогнозы, которые «превосходят традиционные методы по скорости, точности и детальности» ³². Действительно, RELEX часто приводит показатели, такие как значительное процентное улучшение точности прогнозов или уровня сервиса после внедрения. Они в определенной степени учитывают неопределенность – например, их система может генерировать различные сценарии или доверительные интервалы для акций (они учитывают эффекты каннибализации и ореола в прогнозах акций с помощью МЛ для интерпретации исторических данных ⁹). Во время акций они явно корректируют прогнозы для связанных товаров, снижая или повышая их на основе выявленных отношений каннибализации/ореола ⁹, тем самым снижая избыточные запасы для товаров, пострадавших от каннибализации, и избегая дефицита для товаров с эффектом ореола. Это демонстрирует продвинутое вероятностное понимание перекрестного влияния между продуктами. Неясно, предоставляет ли RELEX полные распределения вероятностей для всех товаров (возможно, они внутренне моделируют сценарии, но планировщики в основном видят скорректированные точечные прогнозы). Однако их подход к вариативности является продвинутым – например, они упоминают учет присущей «волатильности, характерной для розничных данных» с использованием соответствующих алгоритмов ³⁰. Другим примером ИИ является прогнозирование для новых продуктов или медленно реализующихся товаров с использованием профилей похожих товаров, что является подходом на базе ИИ к классической задаче прогнозирования «аналогичных товаров». Приверженность RELEX к МЛ также подтверждается участием в исследовательских проектах ЕС и публикацией whitepapers (они участвовали в проекте ЕС Horizon 2020 по ИИ для розничной торговли). В целом, технология прогнозирования RELEX является передовой среди поставщиков для розничной торговли, можно даже сказать, что лидирующая в применении ИИ для планирования в рознице. Возможно, они не используют термин «вероятностное прогнозирование» так часто, как Lokad, но на практике включают неопределенность посредством моделирования (для акций) и анализа чувствительности. Они даже применяют ИИ для непрогнозных задач, таких как распознавание изображений при аудите полок (после приобретения). Основной недостаток: такие сложные модели ИИ могут оказаться «черным ящиком» для пользователей, и доверие должно быть заслужено. Но их результаты (например, сокращение порчи на 30% для сети супермаркетов за счет более точных прогнозов свежести ²⁴) свидетельствуют об эффективности их ИИ.

Экономическое принятие решений: Оптимизация в RELEX исторически была направлена на уровень сервиса и свежесть вместо явной оптимизации прибыли – что понятно, учитывая их основной сегмент – продуктовые магазины (где предотвращение пустых полок и порчи имеет первостепенное значение). Однако они добавляют больше аналитики, ориентированной на экономические показатели. Например, их рационализация ассортимента использует ИИ для оценки сквозной прибыльности каждого продукта по магазину: система выявляет товары с низкой результативностью, которые не оправдывают занимаемое место на полке, анализируя продажи, маржу и затраты ³³. Они подчеркивают, что этот ИИ «выявляет сквозную прибыльность для каждого товара в каждом магазине, выделяя слабых исполнителей» ³³ – эффективно связывая решения по ассортименту с финансовыми результатами (отсекая неприбыльные сегменты). Это показывает, что RELEX понимает, что оптимизация должна быть связана с прибылью, а не только с объемами. В оптимизации запасов RELEX позволяет устанавливать разные целевые уровни сервиса для каждого продукта, возможно, с учетом маржи (ключевые товары против менее прибыльных). Это не чисто подход, основанный на альтернативных издержках, как у Lokad, но позволяет приблизительно расставить экономические приоритеты, обеспечивая повышенную доступность там, где это финансово важно. Со стороны ценообразования, поскольку у RELEX теперь есть модуль оптимизации цен, прибыльность становится приоритетной: оптимизация цен нацелена на установление таких цен, которые соответствуют бизнес-целям, зачастую на максимизацию маржи или выручки в рамках заданных ограничений. Можно предположить, что их ценовой ИИ учитывает эластичность и компромиссы маржи (аналогично Revionics или Blue Yonder pricing). Кроме того, их планирование акций стремится максимизировать успех промо-мероприятий – что включает оценку прироста в сравнении с уступками по марже. Ярким свидетельством экономической ориентации являются их кейс-стадии: например, Franprix (французский ритейлер) достиг снижения порчи на 30% И уменьшения дефицита на 67% с использованием RELEX, улучшив прибыльность за счет сокращения потерь и увеличения продаж ²⁴. Они по сути оптимизировали баланс между затратами на отходы и уровнем сервиса, что является оптимизацией, ориентированной на прибыль, если на то посмотреть. Другим примером является использование внешних данных (например, прогнозов пассажиропотока в аэропортах для магазинов WHSmith) для согласования поставок с реальным спросом и предотвращения избыточных запасов свежих продуктов ³⁴ – опять же, для сокращения потерь (затрат) и увеличения продаж. Всё это показывает, что решения RELEX, хотя и не решают формальную задачу максимизации прибыли, весьма ориентированы на экономические результаты (снижение затрат на отходы, рост продаж, лучшая оборачиваемость запасов). Возможно, они не предоставляют явных расчетов «ожидаемой прибыли» для каждого решения, как делает Lokad, но достигают схожих результатов, фокусируясь на бизнес-показателях, коррелирующих с прибылью (например, процент порчи, процент дефицита, выручка). По мере внедрения ценообразования можно ожидать, что RELEX будет двигаться в направлении единой оптимизации прибыли (например, оптимизируя графики скидок для сезонных товаров, чтобы достичь максимально возможной маржи без излишков запасов). В итоге, ДНК RELEX несколько более операционная (уровень сервиса и потери), чем финансовая, но они явно признают и учитывают экономику розничной торговли в своих алгоритмах, что делает их гораздо большим, чем просто механизмом слепых правил.

Масштабируемость и производительность: Архитектура RELEX знаменита тем, что построена на высокопроизводительной, базе данных в оперативной памяти с колоночным хранением всех розничных данных, что позволяет очень быстро выполнять вычисления на больших наборах данных (ключевой фактор для планирования на уровне магазина и SKU). Преимущество заключается в аналитике в реальном времени – пользователи, например, могут мгновенно видеть влияние изменения параметра на заказы или оперативно пересчитывать прогноз для тысяч магазинов. Такой дизайн произвел впечатление на многих ритейлеров, но требует значительного использования аппаратных ресурсов. Фактически, критический анализ отметил, что «архитектура в оперативной памяти, подобная BI-кубу, обеспечивает впечатляющие возможности отчетности в реальном времени, но гарантирует высокие затраты на оборудование» ²². Это касается подхода RELEX: хранение данных в памяти обеспечивает скорость, но масштабирование, скажем, для национальной сети супермаркетов с миллионами комбинаций SKU-магазин может требовать очень большого объема памяти и вычислительной мощности. Обычно RELEX разворачивается как облачное решение для клиентов (их хостят в облаке, возможно, на AWS или Azure, но это не указывается публично), и, безусловно, они могут масштабироваться для крупных клиентов (у них есть несколько ритейлеров с оборотом в несколько миллиардов долларов). Вопрос заключается в экономической эффективности – RELEX может требовать больше облачных ресурсов (и, соответственно, затрат) для достижения своей быстрой работы по сравнению с пакетными решениями. С точки зрения масштабируемости RELEX доказал свою способность работать для крупных ритейлеров в Европе и Северной Америке. Система способна обрабатывать заказы для каждого магазина в тысячах точек ежедневно. Для среднего клиента RELEX часто управляет десятками тысяч SKU с прогнозированием, обновляемым несколько раз в день. Узким местом может стать добавление новых модулей: интеграция данных об ассортименте и планограммах (которые очень объемны) с прогнозным модулем может дополнительно увеличивать объемы данных. RELEX решает эту проблему, оптимизируя свои алгоритмы и, возможно, перераспределяя некоторые вычисления на диск или распределенные узлы, но по своей сути приложение остается ресурсоемким. Они также предоставляют информационные панели и инструменты моделирования «что если», использующие быстрые вычисления – однако, общий набор данных, находящийся в памяти, и является ключевым фактором. Следует отметить, что цены на память снизились, а масштабируемость облака улучшается, поэтому интенсивный подход RELEX сегодня более осуществим, чем десятилетие назад. Тем не менее, клиенты, ориентированные на снижение затрат, могут посчитать требования к инфраструктуре RELEX высокими по сравнению с более простыми решениями. Существуют анекдотические свидетельства того, что для реализации RELEX необходимы мощные серверы или большие затраты на облако для поддержания работы в реальном времени. В этом отношении RELEX жертвует некоторой экономической эффективностью в пользу скорости и детальности.

Управление сложными факторами розничной торговли: Вот где RELEX действительно выделяется – его функциональность специально разработана для розничных сценариев. Эффекты каннибализации и ореола явно учитываются в прогнозировании акций: как уже обсуждалось, система изучает взаимосвязи из транзакционных данных (например, какие товары являются заменителями, а какие – дополнениями) и корректирует прогнозы в соответствии с этим ⁸ ⁹. Немногие поставщики имеют это встроенным; команда специалистов по данным RELEX опубликовала информацию о том, как они используют обучение правилам ассоциации на данных корзин для выявления этих взаимосвязей, а не полагаются на ручные допущения ⁸. Это означает, что когда вы проводите акцию на товар X, RELEX автоматически снижает базовый прогноз для товара Y, если Y обычно подвергается каннибализации со стороны X (и наоборот для эффекта ореола). Это не только повышает точность прогнозов, но и способствует принятию лучших решений по управлению запасами (уменьшая запасы товара Y, поскольку он будет продаваться меньше во время акции X) ⁹. Что касается замены, RELEX может учитывать эффекты нехватки товара: если товара A нет, их прогноз для товара B может временно увеличиваться, если B является его заменителем. Это, вероятно, достигается за счет тех же выявленных взаимосвязей; некоторые клиенты предоставляют RELEX данные о позициях запасов в магазинах, чтобы система могла обнаруживать упущенные продажи и шаблоны замещения. Срок годности и порча являются важными аспектами для RELEX, особенно в розничной торговле свежими продуктами. Их решение может отслеживать возраст запасов и обладает функциональностью для управления сроком годности ³⁵. Например, RELEX может отдавать предпочтение продаже более старых партий (FEFO – first-expire, first-out), а их прогнозы для свежих товаров учитывают ограниченный срок хранения (обычно они рекомендуют меньшие, но более частые пополнения для товаров с коротким сроком службы). Они даже предоставляют инструменты для мониторинга порчи и предупреждают, если товар приближается к сроку годности без продаж ³⁶. Один из клиентов RELEX, Franprix, зафиксировал значительное сокращение порчи благодаря прогнозированию на дневном уровне и автоматическим заказам в магазинах для свежих продуктов ²⁴ ³⁷ – что доказывает, что RELEX справляется со скоропортящимися товарами гораздо лучше, чем традиционные системы, которые часто игнорируют сроки годности. RELEX также учитывает выставочное пространство и визуальный мерчендайзинг в прогнозировании: если товар получает дополнительное место на витрине, прогноз может быть соответственно увеличен (их МЛ выявляет эту корреляцию). Кроме того, их модули для работы с персоналом и исполнения обеспечивают, что если прогнозы или планы меняются (например, при резком росте спроса), персонал магазина получает уведомления, чтобы, скажем, выпечь больше хлеба или быстрее пополнить запасы (замыкая операционный цикл). Еще одним сложным фактором является погода – RELEX имеет встроенные корректировки прогнозов на основе погодных условий, что критически важно для сезонных категорий (например, мороженое в жаркие дни). Многие заявляют о прогнозировании погоды; RELEX фактически реализовал это, настроив машинное обучение для каждого региона ²⁹. В итоге, RELEX, вероятно, обладает самым полным набором инструментов для управления сложностями розничной торговли: от перекрестного влияния товаров до внешних факторов и ограниченного срока хранения. Они решают эти задачи в значительной степени автоматически при помощи ИИ, что является их ключевым отличием. Однако следует помнить, что использование всех этих возможностей требует предоставления RELEX большого объема данных (данных по корзинам, погодных сводок, информации о запасах и т.д.) и доверия рекомендациям системы. Но для розничных торговцев, стремящихся справиться со сложностью, RELEX предлагает проверенный инструментарий. Мы даем им полную оценку по этому критерию.

Автоматизация: RELEX поддерживает высокий уровень автоматизации, хотя часто настраивается так, чтобы оставить возможность человеческого контроля. На практике многие клиенты RELEX используют автоматическое пополнение запасов на уровне магазинов и распределительных центров: система генерирует ежедневные или внутридневные заказы для каждого SKU-магазина, которые переходят непосредственно к выполнению, если не помечены для проверки. Как уже отмечалось, только у 24% торговых сетей в одном опросе автоматика заказа магазина основывалась на прогнозах, но те, кто её внедрил (с такими системами, как RELEX), отметили снижение потерь на 10–40% ³⁸ ²⁴. Пример Franprix – сокращение порчи на 30% благодаря автоматизированным заказам – подчеркивает, что автоматизация RELEX работает ²⁴. Система имеет механизм оповещения, чтобы привлечь внимание человека к исключениям (например, «прогноз значительно снизился по необъяснимой причине» или «заказ ограничен из-за нехватки складского пространства»), но в остальном может работать в режиме автопилота. Философия RELEX часто описывается как «алгоритмическая торговля», где решения принимаются системой. Они также автоматизируют пересмотр ассортимента, предлагая, какие товары добавить или убрать в каждом магазине за период, и даже автоматизируют рекомендации по снижению цен для распродажи. Одной из ярких областей автоматизации является исполнение промоакций: RELEX может автоматически доставлять товар в магазины в ожидании акций, а затем забирать его, если продажи отстают, без вмешательства планировщика. Кроме того, благодаря системе в реальном времени, планировщикам не приходится выполнять рутинные пакетные обработки или ручные пересчёты – система обновляет прогнозы и планы непрерывно по мере поступления новых данных (продажи, запасы и т.д.). Это позволяет перейти к непрерывному планированию с минимальным числом ручных вмешательств. Стоит отметить, что RELEX обычно всё же привлекает планировщиков для контроля – например, планировщик может утвердить изменение ассортимента или исправить слишком агрессивный заказ, особенно на ранних этапах внедрения. Но тенденция среди пользователей заключается в растущем доверии к ИИ и, соответственно, в увеличении уровня автоматизации. RELEX предоставляет инструменты моделирования, чтобы планировщики могли проверить: «если я позволю системе заказывать автоматически, что произойдет с отсутствием товара на полке по сравнению с запасами?» и таким образом укрепить уверенность. По сравнению с устаревшими системами, которые часто создают план, требующий последующей доработки человеком, RELEX гораздо ближе к автономной работе. Они также начали продвигаться под лозунгом «автономное планирование», подобно Blue Yonder. С нашей скептической точки зрения, можно сказать, что RELEX доказал свою автоматизацию в пополнении запасов, хорошую автоматизацию в прогнозировании (ручное прогнозирование не требуется), частичную автоматизацию в управлении ассортиментом (рекомендации всё ещё пересматриваются мерчандайзерами) и возникающую автоматизацию в ценообразовании (например, динамическое снижение цен). По мере роста возможностей ИИ, мы ожидаем, что RELEX ещё больше снизит необходимость в человеческих корректировках. Таким образом, они показывают очень хорошие результаты в автоматизации, уступая лишь решениям типа Lokad, которые с самого начала созданы для работы в автопилоте.

Интеграция технологий: RELEX представляет собой единую платформу, в основном разработанную внутри компании. Они не собирали своё основное планировочное ядро посредством поглощений – оно было создано самой компанией. Различные функциональные возможности (прогнозирование спроса, пополнение запасов, распределение, планирование выкладки товаров, управление персоналом) используют общую платформу данных. Это означает меньше проблем с интеграцией внутри системы: например, модуль планирования ассортимента подключается напрямую к модулю прогнозирования, так что когда вы исключаете товар из ассортимента, прогнозы и заказы автоматически становятся равными нулю после его исключения. Согласованность обычно на высоком уровне; пользователи получают доступ к этим функциям через единый интерфейс. RELEX совершил несколько приобретений (мобильное приложение для исполнения заказов в магазине, технологию распознавания изображений и т.д.), но они являются дополнениями, а не ядром планировочной логики. Одной из потенциальных сложностей является архитектура, основанная на хранении данных в памяти – всё, что живёт в одной гигантской модели памяти, может затруднить внесение изменений или интеграцию новых типов данных. Однако, похоже, им удаётся управлять этим с помощью современных методов работы с базами данных. По сравнению со старыми поставщиками, у которых продукты для ценообразования и управления запасами зачастую совершенно раздельны (часто в результате поглощений), решения RELEX ощущаются более цельными. Например, их оптимизация цен – более новый компонент, но, вероятно, он был разработан или тесно интегрирован так, чтобы использовать те же данные прогнозирования и интерфейс пользователя. Нет необходимости экспортировать прогнозы во внешний инструмент для ценообразования – всё находится внутри RELEX. Это уменьшает риск возникновения противоречивых предположений между модулями. Другой момент интеграции: RELEX подключается к системам исполнения (ERP, POS и т.д.) через API, и у них достаточно надёжные инструменты интеграции (что является нормой для любого поставщика). Поскольку RELEX развивался как единый продукт, он избегает ярлыка «Франкенштейн», которым часто называют старых конкурентов вроде JDA/Blue Yonder и SAP. Тем не менее, по мере расширения RELEX (особенно в области ценообразования) поддержание чистоты единой платформы остаётся постоянной задачей. Мы не видели сообщений о крупных проблемах, поэтому предполагаем, что им удалось сохранить интеграцию. Одним из аспектов, за которым следует наблюдать, является то, насколько безупречно взаимодействуют микросервисы RELEX (если они действительно разделили приложение на сервисы). Gartner отметил «инструменты управления данными и моделирования ограничений» RELEX как примечательные ³⁹ – что указывает на их интегрированный способ управления всеми бизнес-правилами и данными. Это говорит о высоком уровне интеграции, где различные ограничения (такие как полочное пространство, сроки поставок, размеры упаковки и т.д.) одновременно поступают в один решатель, а не обрабатываются по отдельности. В итоге, RELEX – одно из более технически последовательных решений в этой области, с минимальными признаками разрозненности, свойственными продуктам с насыщенной историей слияний и поглощений. Это значительное преимущество по сравнению с устаревшими пакетами.

Скептицизм в отношении маркетинговых заявлений: RELEX, как и многие молодые компании, свободно использует модные термины, такие как AI/ML, в маркетинговых материалах, но в их случае за словами стоит реальное содержание. Они говорят о «Живом ритейле» и «раскрепощении ИИ» – что, безусловно, маркетинговые штампы – но также публикуют конкретные результаты и методологии. Например, у них есть блог-посты и материалы, подробно описывающие, как их машинное обучение работает для ритейла (рассматриваются вопросы объединения, обнаружения трендов и т.д.) ⁴⁰ ³⁰. Такая прозрачность – это хорошо; это не просто магическая коробка с ИИ, они по крайней мере описывают подход. RELEX также склонен давать слово клиентам – многие их заявления подкреплены статистикой из кейс-стади (например, ритейлер XXXX повысил доступность товара на полках на Y% при одновременном сокращении запасов на Z%). Такие данные выглядят более убедительно, чем расплывчатые заявления. Они также используют такие термины, как «автономный», «когнитивный» и т.д., но пока не обещают того, что не может обеспечить их программное обеспечение. Одной из областей, за которой следует наблюдать, является «чувствительность спроса» – RELEX иногда использует этот термин для описания своей краткосрочной прогнозной способности (с учетом недавних продаж для корректировки ближайших прогнозов). Мы знаем, что концепция чувствительности спроса подвергалась критике как модное словечко ¹², но в случае RELEX их подход фактически представляет собой более частое прогнозирование с использованием последних данных, что является приемлемым. Интеграция «plug-and-play» – не то, что RELEX чрезмерно акцентирует; они признают, что внедрение требует усилий (интеграция данных, настройка параметров). Фактически, некоторые клиенты отмечали, что проекты RELEX требуют значительных усилий (что ожидаемо для мощных инструментов). Таким образом, RELEX не продвигает ложное заявление о «мгновенной выгоде». Они также избегают чрезмерно вычурного жаргона – вы не увидите, чтобы они рекламировали блокчейн или квантовые вычисления без уважительной причины (хотя забавно, что их приобретение «Evo» использует термин «квантовое обучение» для своего ИИ – но это отдельно). Если уж на то пошло, самое большое маркетинговое заявление RELEX заключается в том, что они могут управлять всем спектром аспектов розничного планирования в рамках одного единого решения и быстро приносить значимые результаты. Мы с долей скептицизма спрашиваем: может ли одна система действительно преуспеть во всём – от долгосрочной стратегии ассортимента до ежедневного пополнения запасов и ценообразования? Это амбициозно. RELEX обладает сильными возможностями во многих областях, но некоторые (например, ценообразование) являются более новыми и не испытаны так же, как специализированные конкуренты. Таким образом, хотя они предлагают все компоненты, ритейлер может обнаружить, что один из них менее зрелый. Это нюанс, который их маркетинговые материалы могут упустить. Кроме того, реализация стольких функций в одной системе может стать громоздкой – проблема, не поднимаемая в маркетинге. Однако, если сбалансировать модные термины и реальность, RELEX – один из лучших: их заявления об улучшениях, основанных на ИИ, подтверждаются алгоритмами и доказательствами клиентов, и они в целом избегают чрезмерного употребления модного жаргона. Мы оцениваем их честность в маркетинге как относительно высокую.

Итог: RELEX Solutions – это динамичный игрок в оптимизации розничной торговли с единой платформой, охватывающей прогнозирование, пополнение запасов, ассортимент и ценообразование. Она использует машинное обучение в широком масштабе для учета реальных факторов розничной торговли (промоакции, погода, каннибализация ⁹ и т.д.) и доказала значительное улучшение результатов для ритейлеров (более высокая доступность, меньшая порча ²⁴). Система поддерживает совместное планирование ассортимента, запасов и, в определённой степени, ценообразования, хотя оптимизация цен для них является более новой функцией. Вероятностное прогнозирование и прогнозирование с использованием ИИ – одно из их ключевых преимуществ ²⁸ ³¹, как и способность элегантно справляться со свежими товарами и сложностью. Масштабируемость, как правило, доказана, хоть и требует значительных ресурсов ²². RELEX обеспечивает высокий уровень автоматизации (особенно в пополнении запасов) и располагает согласованным технологическим стеком, разработанным для розничной торговли. Хотя некоторые аспекты (например, оптимальные решения для прибыли, полностью единая оптимизация цены и запасов) могут быть не так естественны, как в подходе Lokad, RELEX представляет собой одно из самых будущеподготовленных и инновационных решений для крупных ритейлеров. Его ориентация на реальность (а не на теорию) и ощутимые применения ИИ делают его первоклассным конкурентом – можно даже сказать лидером среди поставщиков, специализирующихся на розничной торговле. Основные риски – его сложность (внедрение всех функций – задача не из легких) и необходимость обеспечения того, чтобы шумиха («ИИ повсюду!») трансформировалась в удобные для пользователя и поддерживаемые решения. На сегодняшний день, судя по всему, RELEX в значительной мере оправдывает свои обещания, что делает его одним из лучших выборов для ориентированных на будущее оптимизаций в рознице.

Источники: Факторы прогнозирования на основе ML от RELEX (паттерны спроса, промоакции, внешние события) ²⁸; обработка каннибализации посредством ML в прогнозировании промоакций ⁹; доказанное снижение порчи за счет автоматизированного пополнения запасов, основанного на прогнозах ²⁴; анализ прибыльности ассортимента с применением ИИ ³³.

3. o9 Solutions – Амбициозное интегрированное планирование с большими обещаниями (и оговорками)

o9 Solutions (основана в 2009 году) позиционирует себя как создатель «Цифрового мозга» для корпоративного планирования – платформы, которая объединяет прогнозирование спроса, планирование цепочки поставок, управление доходами и многое другое на основе графовой модели данных. Видение o9 заключается в том, чтобы стать единым решением для комплексного планирования, устраняя барьеры между планированием спроса, управлением запасами/поставками, коммерческим планированием и даже финансовым планированием. В контексте розничной торговли o9 может быть настроена для мерчандайзинга и планирования ассортимента, прогнозирования спроса, планирования поставок, а также обладает возможностями для управления ростом доходов (RGM), которое включает в себя оптимизацию ценообразования и промоакций ⁴¹. Теоретически, это покрывает все аспекты совместной оптимизации. o9 получила распространение в секторах товаров народного потребления, производства и некоторых розничных/ориентированных на потребителя компаний, часто делая акцент на своём современном подходе ИИ/ML и графа знаний по сравнению со старыми APS (системами продвинутого планирования). Однако, с точки зрения скептического инженера, o9 представляет собой своего рода парадокс: она очень технологически продвинута в архитектуре, но некоторые эксперты ставят под сомнение, насколько её ИИ имеет существенную основу, а не является просто модным словечком. Мы высоко оцениваем o9 за широкий функционал и платформенный подход, но с оговорками относительно реальной реализации прогнозирования и тяжёлой инфраструктуры, которая может потребоваться.

Совместная оптимизация: Основное ценностное предложение o9 заключается в интегрированном планировании всех функций. Для ритейлера это означает, что одна система o9 способна справляться с финансовым планированием мерчандайзинга, принятием решений по ассортименту, прогнозированием спроса, планированием поставок/пополнением запасов и ценовой стратегией, всё в единой связке. Они явно продвигают своё решение для управления ростом доходов (RGM), которое «интегрирует управление ростом доходов, планирование спроса, цепочку поставок и интегрированное бизнес-планирование (IBP) в единую платформу» ⁴¹. Это говорит о том, что ценообразование и промоакции (RGM) не являются отдельными модулями – они входят в планирование спроса, которое, в свою очередь, связано с планированием поставок, всё в рамках o9. На практике у o9 имеются модули или приложения для каждой области, объединённые под одной крышей. Например, внедрение o9 может включать модель ценовой эластичности в модуле прогнозирования спроса, чтобы планировщики могли видеть, как изменение цены скажется на прогнозе, и сразу же понимать, как это повлияет на запасы или производственные планы. Их концепция Корпоративного графа знаний (EKG) означает, что все данные (товары, локации, поставщики, ограничения и т.д.) связаны, как в сети, что позволяет любому изменению (например, новому решению по ассортименту или изменению цены) распространять влияние по всему графу. Это эффективно в теории: такая система может позволить действительно одновременную оптимизацию – корректировку цен и перераспределение заказов одновременно для максимальной прибыли и уровня обслуживания. Однако неясно, осуществляет ли o9 в данный момент автоматическую оптимизацию по этим направлениям или лишь обеспечивает единый анализ. Часто клиенты используют o9 для прогонки сценариев: например, сценарий 1 – цена x, заказ y; сценарий 2 – цена x+5%, заказ z – с последующим сравнением результатов. Это интегрированное планирование, но не обязательно единый алгоритм оптимизации. Тем не менее, o9 способна вычислять сложные сценарии благодаря своему движку. Это одна из немногих систем, которая реально может объединить планирование ассортимента (мерчандайзинг) с цепочкой поставок – так что ритейлер может разработать стратегию для категории (какие SKU в каких магазинах), а o9 одновременно спланирует запасы и пополнение для них, чтобы обеспечить соответствие поставок мерчандайзинговому плану. Многие устаревшие системы выполняют это разрозненно и поэтапно. o9 также продвигает сотрудничество с поставщиками и многоуровневое планирование в рамках одной платформы, что означает, что вопросы поставок на верхнем уровне могут влиять на решения по мерчандайзингу на нижнем уровне. Всё это целостное объединение является ключевым преимуществом и весьма прогрессивным. Основная проблема – это сложность: моделирование всех этих элементов в одной системе требует значительной настройки и интеграции данных. Некоторые пользователи сообщают, что, хотя o9 может делать всё, их внедрение может сначала сосредоточиться на одной-двух областях (например, на прогнозировании спроса и планировании поставок), оставляя ценообразование или ассортимент для последующих этапов. Таким образом, совместная оптимизация пока больше является потенциалом, чем мгновальной реальностью. Мы даем o9 высокие оценки за видение и архитектуру в области совместной оптимизации, но с оговорками относительно того, сколько клиентов действительно используют её для полностью интегрированных решений по ценообразованию и запасам. Тем не менее, возможности платформы очевидны, и это больше, чем можно сказать о большинстве других.

Вероятностное прогнозирование и ИИ: o9 безусловно позиционирует себя как платформа, управляемая ИИ. У неё есть специализированный ML-движок, способный обрабатывать множество внешних переменных (они демонстрируют такие данные, как Google Trends, погода, социально-экономические данные) в процессе прогнозирования. Граф знаний иногда представляют как средство для улучшения ИИ – связывая все данные, он, как утверждается, помогает алгоритмам машинного обучения находить предикторы спроса. Однако необходим критический взгляд. Один независимый анализ отметил: «Многие заявления о прогнозировании с использованием графовой базы данных (EKG) вызывают сомнения и не подтверждаются научной литературой. Много шума вокруг ИИ, но элементы, найденные на Github, указывают на посредственные методы.» ⁴². Это свидетельствует о том, что реальные методы прогнозирования o9 могут быть не такими революционными, как подразумевает их маркетинг – возможно, они используют вполне стандартные модели временных рядов или регрессию «под капотом», несмотря на модную терминологию. Действительно, o9 подвергался критике за обозначение даже простейших интерактивных функций как «ИИ». Например, быстрое создание сценариев является отличительной чертой их инструмента (благодаря вычислениям в оперативной памяти), но само по себе планирование сценариев не является ИИ – это просто симуляция. Тем не менее, o9 обладает возможностями машинного обучения: они могут создавать ML-модели для акций, для введения новых продуктов (с использованием атрибутивного прогнозирования) и т.д. Они приобрели небольшую AI-компанию (Fourkind) для усиления своей науки о данных. Таким образом, это не пустой шум; они внедрили машинное обучение для распознавания шаблонов и обнаружения аномалий в прогнозах. Возможно, их методы схожи с тем, что используют и другие современные поставщики. Существует мало доказательств того, что графовая модель по своей природе улучшает точность прогнозов – она в основном помогает с организацией данных. Прогнозирование в o9 может быть вероятностным в том смысле, что они поддерживают моделирование Монте-Карло для сценариев (например, симулируют 1000 вариантов спроса для анализа распределения результатов), но мы не видели, чтобы они по умолчанию выводили полные распределения вероятностей так, как это делает Lokad. Таким образом, в плане зрелости чисто вероятностного прогнозирования они могут уступать специализированным игрокам. Однако o9 использует ИИ и иными способами: например, у них есть инструмент оценки рисков цепочки поставок на основе ИИ для прогнозирования возможных перебоев, что выходит за рамки классического прогнозирования. Они также представляют новый ассистент Generative AI (чат-бот для запросов к системе), который больше ориентирован на пользовательский интерфейс, чем на само прогнозирование, но демонстрирует их инвестиции в технологии ИИ. В итоге мы оцениваем возможности ИИ o9 как хорошие, но, возможно, не настолько дифференцированные, как заявлено. Они определённо опережают устаревшие системы AP, полагающиеся на ручное прогнозирование, но по сравнению с конкурентами, такими как RELEX или Lokad, подход o9 в прогнозировании может показаться менее сфокусированным (ведь o9 также балансирует многие другие аспекты планирования). Скептицизм экспертов ⁴² указывает на то, что не стоит воспринимать все заявления об ИИ от o9 буквально. Мы хотим видеть больше независимой проверки повышения их точности прогнозов. До тех пор мы считаем их ИИ заслуживающим доверия, но несколько переоценённым в маркетинге.

Экономическое принятие решений: Гибкую платформу o9 можно настроить для оптимизации различных задач, включая финансовые. В контексте интегрированного бизнес-планирования (IBP) o9 часто помогает компаниям оценивать сценарии по выручке, марже, уровню обслуживания и другим параметрам. Для розничной торговли их модуль RGM должен явно учитывать эластичность цен и маржу – таким образом, связывая решения напрямую с прибылью и выручкой. Они способны выполнять what-if сценарии по прибыльности: например, «Что если мы снизим цену на эту категорию на 5%? Как изменятся прибыль и объем? И смогут ли наши поставщики справиться?» Это согласует планирование с финансовыми метриками. Однако возникает вопрос: оптимизирует ли o9 автоматически или просто предоставляет «песочницу» для экспериментов. Часть ценности o9 заключается в обеспечении межфункциональных решений: например, пользователь может заметить, что определённый план акции приведет к потерям продаж из-за ограничений поставок, и принять решение о корректировке для максимизации прибыли с учетом этих ограничений – всё это реализуется в рамках инструмента o9. Это способствует экономическому принятию решений (благодаря прозрачности и быстрым симуляциям). Кроме того, в o9 встроены оптимизационные решатели (как для цепочки поставок, так и, предположительно, для ценообразования). Они могут выполнять операции типа многоуровневой оптимизации запасов (уравновешивая запасы между распределительными центрами и магазинами для минимизации затрат при достижении заданного уровня обслуживания) и оптимизации календаря акций (выбор оптимального графика промоакций для достижения целей). Эти задачи тесно связаны с экономическими компромиссами. Например, o9 может оптимизировать распределение ассортимента – определять, сколько фасингов или какие товары разместить в каждом магазине для максимизации определённого показателя (например, продаж или прибыли) в условиях ограниченного пространства. Это математическая оптимизация, согласованная с экономическими целями. Поскольку платформа o9 настраиваемая, один ритейлер может задать целевую функцию «максимизировать ожидаемую маржу за вычетом затрат на хранение», а другой – «максимизировать выручку с ограничениями X». Инструмент поддерживает оба варианта. Он гибкий, но это также означает, что сам o9 не предписывает экономический подход – его можно использовать более вручную или эвристически, если так решит клиент. Их маркетинговые заявления о «ориентированном на принятие решений планировании» и «цифровом мозге» подразумевают, что система приведет вас к оптимальному решению. Однако некоторые критики утверждают, что эффектные демо-версии o9 по-прежнему опираются на значительный человеческий анализ, а не на полностью автоматизированные оптимальные решения ⁴². Мы предполагаем, что типичное применение o9 заключается в представлении сценариев и ключевых показателей (затраты, прибыль и т.д.) для планировщиков, которые уже и принимают решение, вместо того чтобы система выдавала единственно оптимальный ответ. Что касается альтернативных затрат, неясно, рассчитывает ли o9 их автоматически (например, стоимость отсутствия товара с точки зрения утраченной прибыли – вероятно, может, если настроено). При оптимизации цен, если используется RGM o9, он, скорее всего, математически оптимизирует цены для достижения финансовой цели с учетом кривых эластичности спроса, подобно другим инструментам оптимизации цен. Таким образом, да, платформа может работать экономически. В целом, o9 обеспечивает экономическое принятие решений (так как предназначена для объединения оперативного и финансового планирования), но степень автоматизации может варьироваться. Мы отдаем им должное за связь планирования с бизнес-результатами (их торговое предложение часто направлено на преодоление разрыва между финансами и планированием цепочки поставок). Однако следует учитывать, что достижение по-настоящему оптимальных решений с точки зрения прибыли с o9 может потребовать значительной работы по построению модели и её настройки в процессе внедрения.

Масштабируемость и архитектура: Архитектура o9 является одной из её отличительных черт – платформа использует современный, вычислительный движок, работающий в оперативной памяти, и Корпоративный граф знаний для представления данных в высокосвязной, но эффективной структуре. Это позволяет быстро обходить связи и выполнять расчёты. Они часто демонстрируют почти мгновенное распространение изменений (например, измените прогноз – и план поставок обновится моментально). По сути, это похоже на то, как Kinaxis обеспечивает параллелизм, но с особенностями графовой БД. Однако, как ранее отмечал скептик, «технический масштаб o9 зашкаливает, даже по корпоративным меркам. Дизайн, основанный на оперативной памяти, гарантирует высокие затраты на оборудование.» ⁴. Другими словами, o9 загружает в память огромное количество данных и вычислительных операций, поэтому для работы в крупной компании могут понадобиться мощные серверы или значительные расходы на облачные ресурсы, аналогично ситуации с RELEX. o9 работает на облачной платформе (у них есть SaaS-решение, зачастую на Azure), что обеспечивает эластичность. Но если ритейлер использует o9 для моделирования всей своей сети с детальными финансовыми и коммерческими данными, модель может оказаться чрезвычайно большой. Одно преимущество: графовая модель может быть более эффективной по использованию памяти, чем наивные таблицы, поскольку элегантно хранит взаимосвязи. Тем не менее, критик считает, что система все же достаточно «тяжёлая». Действительно, на ранних этапах некоторые развертывания o9 были известны высоким потреблением памяти. Вероятно, это улучшили, и с облачными технологиями они могут масштабироваться горизонтально до определённой степени (хотя некоторые расчёты все еще требуют большого общего объема памяти). Масштабируемость по количеству пользователей – на хорошем уровне, поскольку множество пользователей могут сотрудничать в системе, каждый просматривая свою часть, благодаря высокопроизводительному бэкенду. o9 используется компаниями из списка Fortune 500, что подтверждает её масштабируемость для крупных предприятий (включая очень большие компании потребительских товаров и глобальную сеть быстрого питания). Экономическая эффективность – это уже другой вопрос: по свидетельствам, o9 не является дешёвым в эксплуатации, учитывая корпоративное ценообразование и потребности в ресурсах. Если бюджет ограничен, возможно, предпочтительнее использовать более легкое решение для части задач. Но если цените интегрированное планирование в реальном времени на уровне предприятия, o9 обеспечивает это, что, по сути, требует больше вычислительных мощностей. С точки зрения производительности, o9 может пересчитывать планы очень часто (некоторые делают это ежедневно или даже в течение дня для определённых краткосрочных горизонтов), что является улучшением по сравнению с недельными пакетными расчетами старых систем. Они также используют микросервисы и «платформенный» подход, благодаря которому отдельные части плана можно обновлять без полного перерасчёта. Граф знаний обновляется по мере поступления новых данных. Это современный и масштабируемый дизайн. Подводя итог, o9 технически масштабируется до решения очень больших задач, но пользователям следует быть готовыми к значительному потреблению ресурсов (платформа мощная, но требовательная). По сравнению с действительно легкими специализированными решениями, o9, вероятно, будет использовать больше памяти, поскольку решает более крупную интегрированную задачу. Таким образом, в оценке масштабируемости мы даем o9 высокие баллы за возможности, но средние – за экономическую эффективность.

Обработка сложных факторов розничной торговли: «Из коробки» o9 может не обладать таким количеством заранее установленных функций, специфичных для ритейла, как, например, RELEX, но его можно настроить для работы с ними. Например, каннибализация и «ореол» – модели машинного обучения o9 способны обнаруживать эти явления при анализе транзакционных данных, подобно тому, как это делает RELEX. Вероятно, для этого требуется, чтобы команда data science определила необходимые признаки или воспользовалась ML-ассистентом o9. Мы не нашли явных ссылок на встроенное моделирование каннибализации промоакций в материалах o9; скорее всего, это делается через их ML-прогнозирование, а не через отдельный модуль. Эффект замещения также можно учитывать, поскольку o9 способен отслеживать уровни запасов – можно настроить правило или ML-модель, согласно которой, при отсутствии одного SKU, спрос на коррелирующий SKU возрастает. Однако это, возможно, потребуется смоделировать явно. Срок годности/скоропортящиеся товары: o9 может управлять атрибутами партий (его модель данных позволяет учитывать такие характеристики товара, как срок годности). Ритейлер может использовать o9 для планирования производства и распределения с учетом ограничений по сроку хранения (например, обеспечить доставку товаров в магазины с достаточным оставшимся сроком годности). Но, возможно, потребуется настраивать ограничения и цели. Это не специализированное решение для свежих продуктов, поэтому оно не будет автоматически рассчитывать прогнозы порчи, если вы не реализуете соответствующую логику. В отличие от него, некоторые поставщики включают это «из коробки». Таким образом, o9 может это делать, но пользователь должен предусмотреть это в модели. Промоакции и сезонность определённо учитываются – прогнозирование и планирование в o9 отражают эффекты акций (существует модуль планирования промо, который позволяет задавать акции, после чего корректируются прогнозы и планы поставок). Также предусмотрено планирование многоуровневых запасов, что позволяет оптимизировать распределение запасов между распределительными центрами и магазинами с учетом изменчивости – способ элегантно справляться с неопределенностью спроса. Мы предполагаем, что o9, будучи мультиотраслевым решением, не имеет стольких специализированных для розничной торговли алгоритмов «из коробки» (например, он не будет автоматически предлагать «этот товар является заменой для того», если не настроить соответствующую логику). Но его гибкость означает, что любой розничный фактор можно смоделировать. Они также предоставляют так называемые «control towers» – по сути, панели управления для мониторинга показателей, таких как отсутствие товара, упущенные продажи, избыток запасов, что помогает выявлять проблемы, например, каннибализацию или неподходящий ассортимент. Кроме того, граф знаний o9 может интегрироваться с внешними данными, поэтому, к примеру, данные о погоде могут быть использованы для корректировки прогнозов (если пользователь настроит эту возможность). Многие розничные клиенты o9, вероятно, используют внешние сигналы спроса. Оптимизация ассортимента является неотъемлемой частью их предложения (они включают решения для «мерчандайзинга и планирования ассортимента»), то есть с помощью аналитики определяют идеальный ассортимент для конкретного магазина с учетом местных предпочтений и ограничений по площади. В сочетании с их IBP это позволяет обеспечить осуществимость изменений ассортимента с точки зрения поставок. Это решает проблему сложности локализованного спроса. В целом, o9 способен учитывать сложные факторы, но для реализации этих возможностей требуется квалифицированная команда внедрения. Возможно, он не так готов «из коробки» к деталям розничной торговли, как решения, ориентированные исключительно на ритейл, но после настройки он может конкурировать с ними. Отметим, что ранние экспертные комментарии подразумевают, что некоторые продвинутые технологии o9 могут на самом деле основываться на более простых методах (упоминаются open-source проекты, такие как tsfresh, ARIMA и т.д. в контексте o9), что может означать, что некоторые сложные явления решаются достаточно базовыми техниками (например, линейная регрессия для промо – которая работает, но не является передовой). Если это так, o9, возможно, потребуется углубить свой подход, чтобы действительно учесть, скажем, нелинейные эффекты каннибализации. Тем не менее, учитывая их ресурсы и фокус на ИИ, вероятно, ситуация улучшается. Мы оценим их как хорошие по гибкости в отношении сложности, но со средними результатами по проверенному опыту в специфичных для ритейла случаях (например, для свежих продуктов).

Автоматизация: Платформа o9 в первую очередь является инструментом для планирования и поддержки принятия решений – она превосходно справляется с быстрым созданием планов и сценариев. Автоматическое выполнение в значительной степени зависит от организации пользователя. Многие пользователи o9 по-прежнему привлекают планировщиков для выбора сценариев и утверждения планов. Однако o9 предоставляет возможность для непрерывного планирования. Они акцентируют внимание на таких концепциях, как «what-if в реальном времени» и «непрерывное перепланирование», что намекает на автоматизацию (система постоянно обновляет план по мере изменения условий). Например, если спрос в одном регионе резко возрастает, o9 может автоматически перераспределить запасы в плане и предложить ускоренные поставки. Некоторые в маркетинге называют подход o9 «самостоятельным планированием», но на деле он зачастую дополняет работу планировщиков, а не заменяет их. Тем не менее, o9 внедрили функции, такие как AI-агенты, способные мониторить данные и давать рекомендации. А их новый GenAI Orchestrator, как утверждают, «позволяет компаниям принимать более быстрые и умные решения, а также повышать продуктивность планировщиков» ⁴³ – в основном, ускоряя получение инсайтов планировщиками. Полностью автономная автоматизация (например, автоматическое выполнение заказов или изменение цен) обычно не упоминается в контексте o9. Как правило, o9 передает оптимизированные планы в ERP или исполнительную систему, которая затем их реализует. Таким образом, автоматизация в контексте o9 заключается скорее в автоматизации процесса планирования (без ручного расчета в таблицах, автоматических обновлений прогнозов, автоматических оповещений при отклонении плана и т.д.), чем в автоматизации исполнения. Разница по сравнению с такими системами, как Lokad или RELEX, заключается в том, что o9 автоматизирует расчеты и предоставляет рекомендацию по принятию решения, но окончательное решение часто принимает человек; в то время как Lokad/RELEX зачастую настроены на автоматическое формирование реального заказа или изменения цены. Однако, если компания захочет, она может трактовать результаты o9 как автоматически утвержденные решения. Например, o9 может ежедневно формировать предложения по заказам, которые сразу поступают в систему управления заказами – это возможно. Либо система может рассчитывать новые трансфертные цены или предложения по снижению цен и передавать их в магазины. Возможности есть, но типичные пользователи o9 (обычно крупные компании) предпочитают, чтобы в критических решениях участвовал человек. Следует отметить, что сильная сторона сценарного планирования o9 фактически снижает необходимость в методе проб и ошибок со стороны людей – система сама может моделировать бесчисленные сценарии (почти как автоматический мозговой штурм). Таким образом, в определённом смысле, она автоматизирует оценку вариантов, оставляя человеку выбор среди лучших опций. Это значительно ускоряет процесс принятия решений. Что касается продуктивности планировщиков, o9 берет на себя рутинную работу. Кроме того, у них есть рабочие процессы (например, утверждения, уведомления), которые могут автоматически направлять исключения к нужному специалисту. Чтобы сохранить скептицизм, маркетинг o9 с концептом «Цифровой мозг» может намекать на самостоятельно управляемую цепочку поставок, но на деле это больше похоже на очень хорошую кабину для принятия решений, требующую опытного пилота. Мы даем им средне-высокую оценку за автоматизацию расчетов планирования, но ниже – за полностью автономное исполнение. По сравнению с устаревшими системами, требующими множества ручных вводов, o9 является значительным шагом вперед. В сравнении с идеалом AI, управляющего розничными операциями, o9 пока не достиг этого уровня (как и большинство других).

Интеграция технологий: o9 была создана как единая платформа с нуля (бывшими сотрудниками i2 Technologies), поэтому она не унаследовала лоскутное одеяло из приобретенных модулей – что является плюсом для интеграции. Ее архитектура микросервисов и единая модель данных означают, что все части системы бесшовно взаимодействуют друг с другом. Отдельные базы для прогнозирования и планирования поставок не требуются; вся информация содержится в Knowledge Graph. Это позволяет избежать традиционных проблем интеграции между, скажем, системой прогнозирования и системой оптимизации запасов. Все данные загружаются один раз в o9, а затем различные «приложения» внутри нее работают с этими общими данными. Пользовательский опыт также унифицирован (у них есть веб-интерфейс, общий для всех модулей, с настраиваемыми панелями). Таким образом, с точки зрения пользователя, это ощущается как единая система для всех задач планирования. Это явное преимущество по сравнению с решением в стиле Франкенштейна. Однако, по мере роста o9, к ней добавлялось множество функций и, возможно, были приобретены одна-две небольшие компании (например, консалтинговая фирма по ИИ и, возможно, компания по дизайну цепочки поставок). В этих периферийных областях может потребоваться дополнительная интеграция, но основное планирование остается единым. Один эксперт охарактеризовал o9 как «архетип крупного технологического поставщика» с «огромным технологическим потенциалом», подразумевая, что внутренняя структура весьма сложна ⁴. Это намекает на то, что, хотя o9 и не является сборной конструкцией из приобретений, сама платформа огромна – что потенциально может усложнять ее внедрение или обслуживание. Но это внутренняя сложность, а не проблема интеграции разрозненных технологий. Корпоративные покупатели часто предпочитают интегрированную платформу, такую как o9, поскольку это сокращает количество поставщиков и интерфейсов. Это сильная сторона o9 – вы покупаете одну платформу вместо отдельных систем прогнозирования, планирования поставок, S&OP и т.д. Риск в том, что если какая-то часть платформы не будет лучшей в своем классе, вы все равно будете вынуждены ее использовать, если не интегрировать другое средство (что сводит на нет смысл). Что касается «согласованности технологического стека», o9 действительно последовательно – в основном она построена на технологическом стеке Microsoft (.NET и т.д.) и использует разработанную ими структуру графовой базы данных. Таким образом, мы не наблюдаем проблем с копированием данных между подсистемами или с несогласованной логикой. Компромисс: принятие o9 означает адаптацию ваших процессов к платформенному подходу o9, что может стать значительным изменением. Но с точки зрения IT, это, вероятно, упрощает ситуацию по сравнению с использованием множества устаревших систем. Короче говоря, o9 – не Франкенштейн, а инженерный мозг (хоть и очень сложный). Это хорошо для долгосрочной поддержки, если клиент полностью принимает систему, но на начальном этапе может быть ошеломляющим. Мы считаем, что o9 полностью соответствует критерию «согласованного технологического стека».

Скептицизм в отношении хайпа: Если среди поставщиков в этом списке есть тот, кто вызывает «хайповый» сигнал тревоги, это, возможно, o9. Они свободно используют модные слова – Enterprise Knowledge Graph™, Digital Brain, AI/ML, а теперь и Generative AI. Их маркетинг отточенный, но иногда неясный в технических подробностях, сосредотачиваясь на общих преимуществах. Например, они заявляют о наличии AI/ML фреймворка, но вы услышите меньше подробностей о том, какие именно алгоритмы они используют (в то время как такие поставщики, как Lokad или ToolsGroup, могут открыто обсуждать использование вероятностных моделей или нейросетей, o9 остается на более высоком уровне). Некоторые наблюдатели отрасли действительно обвиняли o9 в том, что это «AI-театр», демонстрируя эффектные демо с множеством аналитики, но за кулисами используя довольно стандартные методы ⁴². Ранее упомянутый отчет Lokad поместил o9 почти в конец рейтинга, ссылаясь на «огромный хайп вокруг AI» и то, что тривиальные интерактивные функции оформляются как AI ⁴². Это жесткая критика, вероятно, со стороны конкурентов, но она подтверждает, что маркетинг o9 опережает документально подтвержденные результаты. o9 также именует функции футуристическими терминами – например, заявляя о «движке квантового обучения» (термин, заимствованный из их приобретения Evo в 2023 году), который звучит передово, но по сути представляет собой ансамблевый подход в машинном обучении. Они говорят о «технологии графовых кубов» для соединения данных ⁴⁴, что нормально, но может сбивать с толку клиентов. Ощущение спроса и цифровой двойник – это другие модные фразы, которые o9 может использовать (хотя, если быть справедливым, они представляют это как knowledge graph/цифровой мозг, а не как двойник). Скептик должен задаться вопросом: достигают ли компании тех драматических результатов, на которые намекает o9 (например, увеличение доходов на 10% исключительно за счет лучшего планирования)? Некоторые действительно сообщают о хороших результатах, но независимых подтверждений меньше, поскольку o9 моложе, чем, скажем, SAP. Еще один аспект хайпа: o9 часто позиционирует себя как plug-and-play облачная платформа, которую можно внедрить быстрее, чем старые системы. Однако сообщалось, что некоторые внедрения занимают значительное время и требуют консультаций (поскольку моделирование всего предприятия – задача не из легких). Таким образом, идея о том, что вы можете просто развернуть o9 и сразу получить интегрированное планирование, выглядит оптимистично. Это, в общем, быстрее, чем внедрение нескольких отдельных инструментов, но не «мгновенно». Тем не менее, достижения o9 нельзя списывать со счетов: они действительно внедрили современные технологии и интерфейс в область, где это было необходимо, и многие клиенты довольны. Вероятно, они действительно предоставляют гораздо лучшие возможности планирования, чем те, что были у клиентов ранее. Таким образом, хайп отчасти оправдан – o9 является системой планирования следующего поколения. Главное – правильно интерпретировать их заявления: если они говорят «наш AI будет автономно оптимизировать ваш бизнес», воспринимайте это с долей скепсиса. Вместо этого знайте, что «наша платформа позволит вам лучше моделировать и оптимизировать ваш бизнес, но ваша команда будет участвовать в управлении». Мы советуем потенциальным клиентам требовать конкретных демонстраций или доказательств любых громких заявлений, особенно касательно точности прогнозов, основанных на AI, или улучшения ROI. Фреймворк силен; применение определяет результат. В заключение, маркетинг o9, безусловно, агрессивен в использовании модных слов, поэтому мы рекомендуем сохранять здоровый скептицизм. Тем не менее, с точки зрения содержания, у них есть мощная платформа, поддерживающая значительную часть заявлений – просто имейте в виду, что не все, что называется «AI», является по-настоящему инновационным AI (некоторые решения – лишь эффективные вычисления). Мы даем o9 среднюю оценку за честность маркетинга: у них есть подлинные технологические инновации, но они также превышают рамки хайпа больше, чем другие, что требует тщательной проверки со стороны покупателей.

Итог: o9 Solutions представляет впечатляюще широкую и интегрированную платформу для оптимизации розничной торговли, стремясь служить «цифровым мозгом», объединяющим мерчендайзинг, цепочку поставок и ценовые решения. Ее архитектура Knowledge Graph и in-memory движок обеспечивают быстрое, параллельное планирование и богатый анализ сценариев, которому немногие могут сравниться. o9 поддерживает совместное рассмотрение цен, спроса и предложения, что позволяет согласовать стратегии по ассортименту и ценообразованию с ограничениями по запасам и поставкам в одном инструменте – видение истинного IBP. Платформа использует AI/ML для прогнозирования и аналитики, хотя степень ее совершенства в этой области остается предметом обсуждения ⁴². Система, безусловно, может учитывать сложные факторы и большие объемы данных, хотя и требует значительных вычислительных ресурсов. Масштабируемость соответствует корпоративным требованиям (используется компаниями с оборотом в несколько миллиардов долларов), но эффективность затрат может вызывать вопросы (in-memory подход требует мощного оборудования) ⁴. o9 наделяет планировщиков возможностями автоматизации расчетов и сценарного планирования, хотя это зачастую система поддержки принятия решений, а не полностью автономный исполнитель. С технологической точки зрения, это единая платформа, созданная внутри компании, что позволяет избежать недостатков сборных решений в стиле Франкенштейна. Основные оговорки связаны с ее склонностью к хайпу – некоторые заявления о чудодейственном AI или «мгновенной» трансформации следует воспринимать критически – а также с сложностью внедрения такой комплексной системы. Для перспективных организаций, готовых инвестировать в единую платформу планирования, o9 является одним из ведущих претендентов, предлагая архитектуру, готовую к будущему, и гибкость. Однако успешный проект с o9 требует разделения маркетинговых заявлений и реальности, а также гарантии, что решение настроено для полного использования его потенциала (а не для воспроизведения старых процессов на блестящей новой системе). По нашему скептическому рейтингу, o9 получает высокие оценки за видение и интеграцию, умеренные – за доказанное отличие в AI, и требует тщательной проверки его обещаний, перегруженных модными словами. Это остается одной из самых передовых платформ – просто подходите с открытыми глазами, чтобы убедиться, что содержание соответствует продающему заявлению.

Источники: Критика in-memory дизайна и заявлений об AI o9 ⁴; утверждение об интегрированной платформе RGM (ценообразование) и планирования o9 ⁴¹; взгляд Blue Yonder на использование данных для связывания влияния цены с запасами (подобный подход применяет o9) ²⁷.

4. ToolsGroup – Проверенная оптимизация запасов, эволюционирующая в единую систему розничного планирования (с AI дополнениями)

ToolsGroup является устоявшимся поставщиком (основана в 1993 году), исторически известным своим программным обеспечением Service Optimizer 99+ (SO99+), ориентированным на прогнозирование спроса и оптимизацию запасов. У компании крепкие традиции в производстве и дистрибуции, а также множество клиентов из розничной торговли и потребительских товаров для планирования пополнения запасов. В последние годы ToolsGroup расширила свои возможности за счет приобретений – в частности, пакета для розничного планирования JustEnough и компании в области AI Evo – чтобы предложить более полную платформу оптимизации розничной торговли, включающую планирование ассортимента и мерчендайзинга, прогнозирование спроса, оптимизацию запасов и теперь оптимизацию цен ⁴⁵ ⁴⁶. Фирма давно знаменита использованием вероятностного прогнозирования для планирования запасов и философией высокоавтоматизированного, ориентированного на уровень сервиса планирования цепочек поставок. Теперь, с приобретенными модулями и улучшениями на основе AI, она стремится к совместной оптимизации запасов и цен, предоставляя сквозное планирование в розничной торговле (они именуют это «Планированием, ориентированным на принятие решений»). Мы оцениваем ToolsGroup как солидного, технически компетентного игрока с глубокими знаниями в области оптимизации запасов, хотя отмечаем, что компания находится в переходном периоде интеграции новых компонентов. Она превосходит в отдельных областях (прогнозирование неопределенности, автоматизация), но требует тщательной проверки в отношении того, насколько действительно единое и современное ее комбинированное решение является.

Совместная оптимизация: Исторически ToolsGroup фокусировалась на стороне запасов – обеспечивая правильные уровни запасов для достижения целевого обслуживания с учётом неопределённости. Ценообразование и ассортимент не входили в её сферу. С приобретением JustEnough (специалиста по финансовому планированию товаров, ассортименту и распределению) и интеграцией AI для оптимизации цен Evo, ToolsGroup теперь рекламирует возможность оптимизировать ценообразование и запасы вместе. Например, их новое предложение включает программное обеспечение Retail Pricing, которое может моделировать, как изменения цен влияют на спрос и суммарный доход ⁴⁷ ⁴⁸, и, что важно, делает это с полным обзором запасов ⁴⁸. Интеграция ценообразования с запасами означает, что система учитывает текущие запасы при предложении ценовых мер – что необходимо для совместной оптимизации (нет смысла снижать цену, если товара для продажи нет, например). Они подчёркивают, что их инструмент ценообразования предоставляет «полный обзор текущих запасов и скорости продаж», благодаря чему решения по ценообразованию принимаются с учётом запасов по всей цепочке поставок ⁴⁸ ⁴⁹. Это указывает на скоординированный подход: если запасы высоки, система может инициировать снижение цен; если запасы ограничены, цена может оставаться неизменной или даже расти (если это соответствует стратегии). Кроме того, дорожная карта ToolsGroup с Evo предусматривает динамическую оптимизацию цен, интегрированную в планирование поставок ⁵⁰ ⁵¹. AI Evo специализировался на объединении решений по ценам и запасам – их CEO отметил, что цель заключается в обеспечении «оптимальных расчётов цены и запасов» совместно для поддержки лучших решений по всей цепочке создания ценности ⁵². Это свидетельствует о наличии единого алгоритма оптимизации или, по крайней мере, тесно взаимосвязанных алгоритмов: одного, который находит цену, максимизирующую прибыль с учетом ограничений запасов и ожидаемого спроса, и другого, который определяет план запасов, поддерживающий этот спрос при выбранных ценах. Пока рано – Evo был приобретён в конце 2023 года ⁴⁶, поэтому интеграция, вероятно, продолжается – но ToolsGroup явно намерена объединить оптимизацию цен и запасов под одной крышей, а не как последовательные этапы. Что касается ассортимента, компонент JustEnough предоставляет инструменты для планирования ассортимента и распределения (решения о том, какие товары отправлять в какие магазины, как распределять начальные запасы и т.д.). Это теперь сосуществует с прогнозированием спроса и пополнением запасов. Если интеграция выполнена хорошо, это означает, что ToolsGroup может оптимизировать весь жизненный цикл продукта: планировать ассортимент, устанавливать начальное распределение, прогнозировать спрос, контролировать и пополнять запасы, а также корректировать цены (скидки) к завершению жизненного цикла. Все элементы присутствуют на бумаге. Вопрос в том, насколько слаженно они будут работать вместе. Поскольку ранее эти функции были представлены отдельными продуктами, интеграция может пока не быть идеально бесшовной (хотя ToolsGroup утверждает, что обладает «модульной архитектурой решения», которую они объединяют в единую систему ⁵³). Мы предполагаем, что совместная оптимизация в случае ToolsGroup может на данный момент осуществляться последовательно (модуль ценообразования берёт прогноз от модуля прогнозирования и оптимизирует цены; модуль управления запасами получает полученный спрос и оптимизирует наличие товара). Со временем, с продвинутой аналитикой Evo, они могут объединить это в один цикл, который напрямую оптимизирует прибыль (и цену, и количество). Пока же мы дадим ToolsGroup заслуженное признание за решительный переход к совместной оптимизации – немногие поставщики в этой категории обладают возможностями и по ценам, и по запасам. Некоторые первые результаты: ToolsGroup (с Evo) работала с ритейлерами, такими как Decathlon, в области ценообразования и наблюдала рост маржи при соблюдении ограничений по запасам ⁵⁴ ⁵⁵ (информация по кейсу подразумевает итеративные A/B тесты для нахождения оптимальных цен, улучшающих маржу без ущерба для имиджа бренда, проводимые с учётом запасов). Это практическая форма совместной оптимизации (тестирование цены, основанное на данных о запасах и марже). В целом, ToolsGroup стремительно эволюционирует от нишевого игрока в оптимизации запасов к целостному решению для оптимизации розницы. Возможно, на данный момент он уступает Lokad или o9 по степени интеграции оптимизации, но находится на верном пути и уже охватывает три столпа (запасы, ценообразование, ассортимент).

Прогнозирование на основе вероятностей и AI: ToolsGroup была пионером в вероятностном прогнозировании спроса для цепочки поставок. Задолго до того, как это стало модным, SO99+ генерировала распределения спроса вместо единичных чисел, что позволяло вычислять оптимальные уровни запасов для достижения заданной вероятности обслуживания. Такой подход выделял её среди многих устаревших инструментов, использующих средние прогнозы и формулы для расчёта страховых запасов. ToolsGroup обладает обширной интеллектуальной собственностью в этой области – например, с помощью моделирования Монте-Карло или аналитических вероятностных моделей для прогнозирования изменчивости спроса по SKU, а затем определения политики запасов. Это было одной из их ключевых сильных сторон; клиенты часто достигали высокого уровня обслуживания с меньшими запасами, поскольку методы ToolsGroup лучше учитывали неопределённость (в отличие от простых методов расчёта страховых запасов). Они продолжают просвещать рынок о ценности вероятностного прогнозирования (их материалы утверждают, что оно необходимо в условиях неопределённости ⁵⁶). Однако, важное замечание: в прошлом ToolsGroup часто докладывала такие метрики, как MAPE, клиентам и в маркетинговых материалах. Обзор Lokad указал на несоответствие, когда ToolsGroup рекламировала вероятностное прогнозирование с 2018 года наряду с заявлениями о снижении MAPE, несмотря на то, что «MAPE не применяется к вероятностным прогнозам» ¹⁹. Это означает, что либо их маркетинг не успевал за методологией (используя привычную метрику, даже если она не вполне применима), либо они всё ещё генерировали прогноз со средней величиной для сравнения. В любом случае, они явно придерживаются вероятностного мышления. Что касается искусственного интеллекта и машинного обучения, ToolsGroup интегрирует больше методов машинного обучения для обработки факторов, влияющих на спрос, и распознавания шаблонов. Традиционно их прогнозирование было более статистическим (например, метод Кростона для прерывистого спроса и т.д.), но теперь в нём присутствуют такие функции, как учёт причинных факторов, регрессия для промоакций и даже ансамбли машинного обучения. Приобретение Evo принесло современный AI – «quantum learning» Evo по сути является продвинутым алгоритмом машинного обучения (возможно, закрытым ансамблем или методом обучения с подкреплением), нацеленным на быстрое нахождение оптимальных решений ⁵⁷. Интеграция Evo явно заявляет, что он добавляет «нелинейную оптимизацию, квантовое обучение и продвинутую предписывающую аналитику» в их решения ⁵¹. Это говорит о повышении уровня сложности AI, особенно для решений в области ценообразования и промоакций, которые по своей природе являются нелинейными. Они также приобрели компанию под названием AI.io (ранее известную как Halo Business Intelligence) несколько лет назад, что дало им инструмент рабочего места для прогнозирования спроса на основе AI. Таким образом, ToolsGroup определённо внедряет AI. Тем не менее, их маркетинг в области AI иногда вызывает вопросы, как отметил обзор Lokad: «ToolsGroup демонстрирует обширные возможности, однако их заявления об ‘AI’ вызывают сомнения. Публичные материалы намекают на прогнозные модели до 2000 года. Заявления о ‘чувствовании спроса’ не подтверждены научной литературой.» ¹⁹. Это подразумевает, что до недавнего времени ToolsGroup, возможно, переименовывала в AI то, что по сути являлось многолетними методами прогнозирования (такими как Croston, ARIMA), без применения настоящего современного машинного обучения. И использование терминов вроде «чувствование спроса» (как они упоминали в брошюрах) не было подкреплено чем-то новым. Мы воспринимаем это как призыв внимательно относиться к заявлениям ToolsGroup об AI. Однако, с недавним дополнением EvoAI (2023), мы ожидаем, что суть AI в ToolsGroup значительно усилится – Evo была молодой компанией, основанной на ML для оптимизации цен и запасов, и ToolsGroup демонстрирует конкретные новые функции, полученные от неё (например, автоматический выбор моделей, адаптивные алгоритмы, реагирующие на недавние изменения, и т.д.). Кроме того, вероятностный подход ToolsGroup сам по себе является видом AI (стохастическое моделирование), даже если его не называют «машинным обучением» – это продвинутая аналитическая техника, которой многим другим не хватало. Таким образом, в области прогнозирования ToolsGroup демонстрирует высокую эффективность. В плане новейших AI они догоняют конкурентов. В целом, ToolsGroup обеспечивает надежное качество прогнозов и теперь предлагает больше информации о факторах, влияющих на спрос, и о взаимосвязях между ценой и спросом благодаря ML. Мы даём им высокий балл за вероятностное прогнозирование (одним из немногих, кто занимается этим в широком масштабе) и средний – за инновации в AI (они совершенствуются, но имеют историю завышенных ожиданий). Сочетание старых и новых методов может дать мощный эффект, если реализовано правильно: например, использование ML для обнаружения изменения шаблонов (скажем, сдвиг из-за COVID), а затем применение вероятностной модели для корректировки целевых запасов. ToolsGroup, вероятно, уже применяет такие гибридные подходы.

Экономическое принятие решений: Традиционно подход ToolsGroup к управлению запасами формулировался как оптимизация уровня обслуживания – вы задаёте целевой уровень обслуживания или коэффициент выполнения, а их алгоритм находит минимально необходимые запасы для его достижения с учётом неопределённости. Это косвенно экономичный подход (лучшее обслуживание предотвращает потерю продаж, меньше запасов – снижает затраты на их хранение), но он не направлен напрямую на максимизацию прибыли. Они, однако, внедрили многоуровневую оптимизацию запасов (MEIO), которая по своей сути балансирует затраты на запасы и затраты от дефицита, основываясь на экономических принципах. С их новой стратегией прибыльность становится более важной. Генеральный директор ToolsGroup заявил, что объединение с JustEnough направлено на предоставление розничным торговцам «полного обзора на 360 градусов, который является в режиме реального времени, прогнозным и действенным… клиенты могут более эффективно улучшать доступность продукта и опережать конкурентов в управлении современным переменчивым спросом» ⁵⁸. Хотя эта цитата подчёркивает обслуживание и оперативность, пресс-релиз по приобретению Evo говорит более прямо: «расширяет наше лидерство в динамической оптимизации цен… что позволяет сделать следующий шаг к планированию, ориентированному на принятие решений … что необходимо для создания автономной цепочки поставок будущего» ⁵¹. Термин «ориентированное на принятие решений» предполагает акцент на результате решения (чаще всего финансовом). Основатель Evo говорил о создании видения «умных решений для управляющих через оптимальные расчёты цены и запасов» ⁵² – что явно означает использование оптимизации для максимизации определённого показателя (вероятно, прибыли или дохода), а не просто для достижения целевых показателей обслуживания. И действительно, «адаптивный AI Evo предоставляет необходимый ингредиент для создания автономной цепочки поставок» ⁵⁷ – предположительно, этот ингредиент заключается в постоянной корректировке решений на основе результатов, что аналогично максимизации ключевых показателей эффективности. Что касается ценообразования, прибыльность, безусловно, является главным фактором – решение ToolsGroup в этой области направлено на «максимизацию прибыльности за счёт создания стратегии ценообразования, основанной на данных» ⁵⁹. Оно позволяет устанавливать цены по заданным правилам, а также с помощью ML адаптироваться к изменениям спроса и «максимизировать маржу» в установленных пределах ⁶⁰. Указание, что «можно сформировать разные цены… с полным обзором… запасов и скорости продаж, что помогает удовлетворять спрос и минимизировать затраты по всей цепочке поставок» ⁴⁸ показывает, что инструмент ценообразования учитывает не только маржу в отрыве от других факторов, но и затраты на хранение запасов, а также, возможно, предотвращение уценок (снижение затрат). Это экономичный подход – принятие ценовых решений с учётом затрат цепочки поставок. В управлении запасами ToolsGroup также может учитывать затраты на хранение против затрат при дефиците, оптимизируя уровень обслуживания с экономической точки зрения. Фактически, целевые уровни обслуживания могут быть выведены из экономической модели (например, более высокое обслуживание для товаров с высокой рентабельностью). Неясно, проводит ли ToolsGroup это явно, но клиенты часто выполняют такую классификацию самостоятельно. Теперь, с предписывающей аналитикой Evo, мы ожидаем, что ToolsGroup перейдёт к рекомендациям по оптимальным решениям с точки зрения прибыли (например, какой объём товара хранить и по какой цене для максимизации ожидаемой прибыли с учётом неопределённости). Все необходимые составляющие уже присутствуют, и, предположительно, команда Evo обладает этой методологией (их академический опыт указывает на экспертизу в области исследований операций). Небольшое предостережение: послания ToolsGroup всё ещё часто ссылаются на традиционные KPI (обслуживание, сокращение запасов) больше, чем на прямую прибыль. Но это типично для других игроков в области управления цепочками поставок. Существуют доказательства того, что они начинают уделять больше внимания прибыльности – например, их функция оптимизации ассортимента (вероятно, от JustEnough) для исключения нерентабельных SKU, что согласует ассортимент с финансовым вкладом. Также, клиентские истории упоминают сокращение запасов и улучшение продаж/обслуживания (что приводит к повышению прибыли). Нет публичного примера того, что ToolsGroup прямо максимизирует показатель прибыли, но объединение оптимизации цен и запасов по своей сути направлено в этом направлении. Мы дадим ToolsGroup довольно высокую оценку, отмечая их давний подход «обслуживание с минимальными затратами» и новый акцент на ценовую маржинальность. Возможно, они ещё не так увлечены понятием альтернативных издержек, как Lokad, но однозначно они вышли за рамки простых эвристик.

Масштабируемость и экономическая эффективность: Изначальная версия SO99+ от ToolsGroup обычно разворачивалась локально или как хостинговое решение для средних и крупных компаний. Она не настолько «тяжёлая», как некоторые крупные системы APS; по замыслу, она сосредоточена на «сложных задачах» (прогнозирование, расчёты запасов) и не занимается массивной интеграцией данных. Многие компании среднего размера успешно использовали её. Она достаточно математически оптимизирована, что означает, что вычислительные затраты на оптимизацию запасов не слишком велики (решение задачи распределения запасов с помощью алгоритмов и, возможно, линейного программирования для многоуровневой цепочки). Для прогнозирования спроса у них был собственный движок, способный обрабатывать большое количество временных рядов за ночь (например). Сейчас они предлагают полноценное облачное SaaS-решение, которое, вероятно, легче масштабировать по мере необходимости. В отчёте Gartner за 2024 год ToolsGroup был отмечен как новый участник и выделен за «доступную стартовую стоимость» и «прозрачное ценообразование», а также за использование в качестве единого глобального решения для некоторых клиентов (что подразумевает возможность масштабирования на глобальном уровне) ⁶¹ ⁶². Это говорит о том, что ToolsGroup считается относительно экономичным и масштабируемым для своей категории. Действительно, их исторический упор на компании среднего рынка означал, что им приходилось быть более готовыми к использованию «из коробки» и не требовать целой армии IT-специалистов. В розничной торговле объемы данных могут быть большими (на уровне магазина и SKU). JustEnough (приобретённая розничная система) была известна обслуживанием крупных розничных сетей (у неё были клиенты, такие как Sephora, насколько я знаю), поэтому она справляется с достаточно большим ассортиментом. Однако некоторые аспекты, такие как оптимизация цен (если выполнять детальную работу по ценам на уровне магазина), могут оказаться ресурсоёмкими. Вероятно, типичное развёртывание ToolsGroup всё ещё остаётся несколько ориентированным на пакетную обработку – например, ночные или еженедельные пересчёты прогнозов, обновление запасов – а не в режиме реального времени, что подходит для многих случаев. Это означает, что им не обязательно всё время держать все данные в оперативной памяти 24/7; они могут вычислять данные и освобождать память. Это гораздо эффективнее с точки зрения затрат, чем постоянный подход с хранением всего в памяти. С другой стороны, для интеграции с динамическим ценообразованием может потребоваться более частый цикл вычислений. Они рекламируют «отзывчивый ИИ» с помощью Evo, что означает более быстрые перерасчёты при изменении условий ⁵⁷. Технология Evo может позволить выполнять оптимизацию почти в режиме реального времени (Evo, будучи стартапом, вероятно, использует облачные технологии и, возможно, GPU-вычисления для ускорения процессов). ToolsGroup также приобрела Onera в 2022 году для обеспечения видимости запасов в реальном времени и оптимизации выполнения заказов ⁶³, что означает, что они движутся в сторону принятия решений по выполнению заказов в электронной коммерции в режиме реального времени. Эти дополнения могут увеличить требуемые вычислительные ресурсы. Но с учётом их рыночного позиционирования ToolsGroup будет стремиться делать это эффективно, чтобы привлечь также и средние розничные сети, а не только гигантов ритейла. Современная архитектура несколько модульная: ядро SO99+ (возможно, на C++) плюс облачные сервисы, соединённые с модулями JustEnough (возможно, на .NET или Java). Интеграция этих систем может временно добавить накладные расходы (общение двух систем). Но ToolsGroup активно интегрируется – например, «Благодаря недавно интегрированному движку EvoAI, JustEnough возглавляет эволюцию планирования розничной торговли на базе искусственного интеллекта» ⁶⁴, что указывает на то, что они внедряют Evo непосредственно в решение JustEnough/ToolsGroup, а не держат его отдельно. Отметим, что инфраструктура ToolsGroup обычно легче, чем у SAP или Blue Yonder. Например, для проекта ToolsGroup может не потребоваться внутренняя IT-команда для управления огромными серверами – они управляют этим через SaaS. Они отмечают, что «модульная архитектура позволяет клиентам легко выбирать необходимые продукты и объединять их в единое связное решение» ⁵³ – что подразумевает, что нет необходимости загружать всё, если это не требуется, что способствует масштабируемости (вы можете использовать только движок расчёта запасов, если он вам нужен). В итоге, ToolsGroup является умеренно масштабируемым (подходит для многих крупных розничных сетей, но, возможно, не доказал свою эффективность в масштабах крупнейших гипермаркетов по всему миру) и, как правило, экономичным (особенно с их прозрачным ценообразованием и акцентом на автоматизацию, снижающей рабочую нагрузку планировщиков). Они не будут столь молниеносными, как системы с постоянным хранением данных в оперативной памяти для огромных объёмов, но и не потребуют астрономических ресурсов для получения результатов. Учитывая положительный обзор от Gartner в части затрат и наличие множества клиентов среднего и крупного бизнеса, мы считаем ToolsGroup относительно эффективным. Кроме того, они упоминают предложение «Inventory Hub» для обнаружения событий в цепочке поставок в режиме реального времени ⁶², что показывает, что они модернизируются для работы в реальном времени без, предположительно, необходимости использования экстраординарного аппаратного обеспечения (вероятно, с применением потоковой обработки). Публичных жалоб на производительность ToolsGroup не так уж много, что обычно указывает на её адекватность. Таким образом, ToolsGroup получает высокую оценку по этому критерию, с незначительной оговоркой, что интеграция нескольких приобретений может временно увеличить нагрузку на систему, если не провести оптимизацию (но пока признаки благоприятные).

Управление сложными розничными факторами: Исторически ToolsGroup превосходно справлялась с неопределённостью спроса и его изменчивостью, включая прерывистый спрос, медленно реализующиеся товары и изменчивость поставок. Возможно, она не была так специализирована на специфических для розничной торговли явлениях, таких как каннибализация или истечение срока годности «из коробки». Однако благодаря комплексу JustEnough они получили возможности в розничном сегменте: JustEnough предоставил прогнозирование акций, распределение (с учетом вместимости магазина и мерчандайзинга) и планирование уценок. Таким образом, у ToolsGroup теперь есть возможности для проведения акций — например, они могут смоделировать рост продаж в результате акции и распределить его во времени, что по своей сути справляется с каннибализацией на базовом уровне (если акция приводит к ранним продажам, то в последующие периоды наблюдается спад и т.д.). Автоматически ли они выявляют каннибализацию между товарами? Возможно, не так автоматически, как RELEX, но они могут учитывать эффекты акций, если они известны. Что касается эффектов замещения (когда отсутствие товара ведёт к продажам альтернативного), ToolsGroup не делала на этом особого акцента в представленных материалах. Это может оставаться пробелом, если не настроить вручную. Что касается эффектов «ореола» (товары-компаньоны), то, вероятно, ситуация аналогична – потребуется ручное моделирование взаимосвязей или использование ИИ. Это область, где их новый ИИ (Evo) мог бы помочь, обнаруживая корреляции. Движок Evo потенциально может анализировать данные транзакций для корректировки прогнозов или рекомендаций по ценообразованию для взаимосвязанных товаров. Без конкретных доказательств будем считать, что ToolsGroup может справляться с этими аспектами с определёнными усилиями, хотя исторически это не было их сильной стороной. Истечение срока годности и скоропортящиеся товары: ToolsGroup имела клиентов в сфере продовольственного распределения, но не ясно, насколько хорошо она оптимизирует запасы свежих товаров на уровне магазина. Вероятно, это не их основное направление. Они могут учитывать сроки поставки и размеры партий, но ограничения, связанные с истечением срока годности, потребуют явного моделирования (например, рассмотрения истекающих товаров как отдельного SKU или корректировки прогноза с течением времени). Модуль распределения JustEnough может справляться с сезонными товарами (обеспечивая распродажу до конца сезона с помощью уценок), что схоже по концепции с обработкой скоропортящихся товаров. Действительно, оптимизация уценок (часть JustEnough) по сути направлена на выбор оптимального момента для снижения цен с целью распродажи запасов без остатков – что аналогично задаче «истечения срока годности» в конце сезона. Инструмент ценообразования ToolsGroup помогает в этом, рекомендуя, когда снижать цены и на сколько, чтобы избежать обесценивания запасов при максимизации доходов ⁴⁸. Таким образом, они действительно решают экономическую сторону проблемы скоропортящихся товаров (распродажа до образования излишков). Что касается локализации ассортимента: планирование ассортимента JustEnough позволяет группировать магазины и адаптировать ассортимент, так что ToolsGroup может оптимизировать ассортимент с учетом локальных особенностей спроса и ограничений по площади. Это косвенно решает проблему каннибализации (если два товара конкурируют, оптимизация ассортимента может принять решение о выборе одного для небольших магазинов). Ограничения по месту и экспозиция: через JustEnough ToolsGroup может моделировать количество мест на полке или ёмкость магазина, что влияет на распределение и пополнение запасов. Это не так детализировано, как специализированные решения для планограмм, но на уровне планирования этот аспект учтён. Акции: ToolsGroup занимается прогнозированием акций и может планировать запасы для проведения акций (есть кейсы, где они помогали улучшить наличие товаров во время акций). Новый ИИ, вероятно, улучшает прогнозирование эффекта акций, анализируя предыдущие кампании более точно (возможно, схоже с краткосрочным «чувством спроса», хотя Lokad критиковал заявления о «чувстве спроса» как неподкрепленные ⁶⁵). Что касается конкретно каннибализации/ореола: прямых упоминаний не найдено, так что, возможно, здесь всё ещё требуется участие планировщика для корректировки. Философия ToolsGroup всегда заключалась в упрощении работы планировщиков – они создали автоматизацию, позволяющую планировщикам концентрироваться на исключениях. Они, вероятно, учитывают исключения в случаях отсутствия товара или аномальных продаж, но неясно, связываются ли они с логикой взаимозаменяемости. С учетом умеренных доказательств можно оценить ToolsGroup как компетентного, но не лидера в решении сложных розничных вопросов. Они охватывают базовые аспекты розничного планирования (неопределенность спроса, акции, завершение жизненного цикла) и довольно неплохо справляются с оптимизацией ассортимента, но всё ещё отстают в передовых аспектах (например, моделирование каннибализации или замещения с использованием методов машинного обучения).

Автоматизация: Исторически ToolsGroup гордилась своей автоматизацией и «безучастным» планированием. Фактически, одно из преимуществ SO99+ заключалось в том, что он мог автоматически задавать политики пополнения запасов и генерировать заказы на пополнение с минимальным вмешательством со стороны планировщиков. Многие клиенты сообщают, что после внедрения ToolsGroup они тратят гораздо меньше времени на решение проблем с прогнозированием или управлением запасами, поскольку система автоматически адаптируется к изменениям и сигнализирует только по исключительным случаям. Они используют такие термины, как «самоадаптирующийся» для описания своего прогнозирования – то есть система сама адаптируется к новым паттернам спроса, снижая необходимость постоянного вмешательства в прогнозы. Концепция «Мощно-простой» (один из их слоганов) подразумевает упрощение задач планировщика посредством автоматизации. На практике установка ToolsGroup часто запускает ночные пакетные процессы для обновления прогнозов и целей по запасам, а затем предлагает заказы для каждого товара в конкретном магазине. Планировщики просматривают только те товары, при которых возникают исключения (например, очень низкий уровень обслуживания или слишком высокие запасы). Это, по сути, безучастное планирование для значительной части ассортимента. Один из кейсов (из прошлых маркетинговых материалов) сообщал, что клиент автоматизировал 90% пополнения запасов SKU, оставляя ручную проверку только для верхних 10% исключений. Это свидетельствует о высоком уровне автономии. Теперь, с интеграцией JustEnough, который включает задачи планирования, традиционно выполняемые вручную (например, создание планов ассортимента, установление начального распределения, составление финансовых планов), ToolsGroup, возможно, потребуется сохранять баланс между автоматизацией и пользовательским вводом. Планирование ассортимента обычно требует стратегического вмешательства мерчендайзеров, что не может быть полностью автоматизировано. Однако ToolsGroup может автоматизировать аналитическую часть (например, выделять товары с низкой эффективностью для исключения ³³). Со стороны ценообразования, динамическое ценообразование может быть автоматизировано до определённых пределов – модуль ценообразования ToolsGroup позволяет задавать правила и затем автоматически применять изменения цен в рамках установленных ограничений ⁶⁶. Например, розничный продавец может настроить автоматическое снижение цен для товаров с запасами, превышающими определённое количество дней, что инструмент сможет выполнить без ручных вычислений. Они явно указывают на необходимость «установки правил ценообразования, а затем их автоматического применения в рамках заданных границ» ⁶⁶ – это автоматизация с элементами контроля. Таким образом, большая часть принятия решений может осуществляться без вмешательства: система контролирует запасы и спрос, и если условия соответствуют правилам (возможно, с поддержкой рекомендаций ИИ), она может внести изменения в цены. Это пример действительно автономных действий в ценообразовании (хотя, вероятно, первоначально с участием менеджера). Аналогично, предложения по пополнению запасов могут быть автоматически переданы в ERP для выполнения заказов. ToolsGroup часто делает акцент на управлении исключениями, подразумевая: если исключений нет, доверяй результату системы. С внедрением ИИ Evo они намекают на переход к «автономной цепочке поставок» ⁵⁷. Они даже использовали этот термин, следуя отраслевой тенденции. Технология Evo может позволить более непрерывную оптимизацию (например, корректировать прогнозы в середине месяца, если продажи отклоняются, и пересчитывать заказы соответственно, всё автоматически). Новые функции ToolsGroup, такие как Inventory Hub (сигналы в режиме реального времени), указывают на возможность обнаруживать событие (например, всплеск спроса) и автоматически реагировать, перераспределяя запасы либо ускоряя поставки. Детали не разглашаются, но это, вероятно, и есть цель. В целом, ToolsGroup всегда ориентировалась на безучастное планирование – позволяя системе самостоятельно решать рутинные задачи. Есть данные, что некоторые клиенты управляют значительной частью операций с минимальным участием планировщиков. Таким образом, ToolsGroup получает высокую оценку в области автоматизации. Единственное ограничение возникает при переходе в новые области, такие как планирование ассортимента и ценообразование, где стратегия пользователя играет большую роль – но даже там они обеспечивают автоматизацию тактических аспектов (например, автоматическое выделение товаров для уценки или систематическое ранжирование магазинов по продажам для распределения). Сочетание автоматизации, основанной на правилах (для бизнес-ограничений), и предложений, основанных на ИИ (для сложных решений), позиционирует ToolsGroup как поставщика, способного существенно снизить объём ручного планирования.

Интеграция технологий: Недавняя стратегия ToolsGroup включала приобретения, что естественно вызывает вопрос интеграции платформ. На данный момент у них есть SO99+ (их наследный движок), JustEnough (теперь часто называемый ToolsGroup Retail Planning) и AI-движок Evo, плюс технология Onera в реальном времени. Они активно интегрируют их: например, в пресс-релизе говорится «интеграция решений Evo с SO99+ и JustEnough предложит клиентам наиболее эффективное, оптимизированное в реальном времени решение для цепочки поставок и оптимизации цен» ⁴⁶, что указывает на то, что все три объединяются в одно предложение. Они подчеркивают, что их модульная архитектура позволяет клиентам выбирать именно то, что им нужно, и все компоненты работают вместе ⁵³. Это намекает, что они создали интерфейсы или общую модель данных (или находятся в процессе её создания), благодаря чему данные перетекают между модулями без ручного вмешательства. Хорошим знаком является то, что JustEnough принадлежит ToolsGroup с 2018 года (через приобретение Mi9); за это время им удалось интегрировать основные компоненты. Действительно, ToolsGroup во многих случаях продвигает объединенное решение под единым именем. Вероятно, они объединили пользовательский интерфейс в определённой степени – возможно, ещё не полностью единый интерфейс для всего, но уже близко к этому. Они внедрили AI Evo в JustEnough, как упоминалось ⁶⁴, что демонстрирует настоящую техническую интеграцию, а не продажу отдельных компонентов. Это обнадеживает: похоже, ToolsGroup сознательно стремится избежать изолированного функционирования этих модулей. Однако стоит признать, что некоторое время система, вероятно, представляла собой «набор» отдельных компонентов – например, пользователь вынужден был пользоваться интерфейсом SO99+ для одних настроек и интерфейсом JustEnough для других. Это сначала может оказаться не очень удобным. Относительно небольшой размер ToolsGroup может способствовать более оперативной интеграции – меньше бюрократических препятствий по сравнению с SAP. Цель явно заключается в создании целостного комплекса планирования от начала до конца. Они обмениваются данными: например, сформированный прогноз (вероятно, с помощью SO99+ или Evo) заполняет как планирование запасов, так и финансовое планирование ассортимента. При отсутствии доказательств обратного можно предположить, что ToolsGroup добилась значительного прогресса в интеграции этих приобретений. Возможно, существуют незначительные несоответствия (например, методы прогнозирования в SO99+ могут отличаться от нативных методов JustEnough – но, вероятно, выбор в конечном итоге падёт на более эффективный вариант). Что касается технологической базы, то исторически ToolsGroup использовала клиент-серверную архитектуру на базе Windows для SO99+, тогда как JustEnough был веб-ориентирован на .NET. Теперь же все предлагается через облачный веб-интерфейс. Вероятно, кодовая база не полностью объединена, но внешне для пользователя система может казаться единым порталом. Если интеграция выполнена успешно, то с точки зрения пользователя это и есть интеграция (аналогично тому, как Microsoft со временем бесшовно объединяет приобретённые продукты в пакет Office). Следует отметить, что базовая технология ToolsGroup (оптимизация запасов) была очень надёжной и проверенной временем. Они не отказались от неё – напротив, построили систему вокруг неё. Это хорошо, поскольку им не приходится изобретать велосипед, но также означает, что в основе системы лежит более старый код. Иногда старый код может не идеальным образом сочетаться с новыми микросервисами. У нас нет прямых данных по этому поводу, так что это стоит иметь в виду. Собственные комментарии ToolsGroup о конкурентах часто сводились к тому, что крупные поставщики комплексных решений напоминают Франкенштейна; теперь ToolsGroup нужно избегать этого сами. Путём активной интеграции, а не простого ребрендинга, они, по-видимому, осознают эту проблему. Например, приобретения SAP привели к получению «смешанного набора» решений и трудностям в интеграции ¹¹, как отмечалось ранее. ToolsGroup прямо заявляют, что объединение розничного планирования JustEnough с их автоматизацией и оптимизацией запасов обеспечивает уникальное решение, и что «продукты работают вместе как единое целое» ⁵³. Мы осторожно доверяем этому, но не исключаем возможности некоторых несовершенств (например, пользователь может столкнуться с необходимостью настройки основных данных в двух местах, если интеграция окажется неполной). В целом, ToolsGroup находится на этапе средней интеграции – изначально не объединённые, но активно движущиеся в этом направлении. Мы дадим им умеренную оценку: они лучше, чем компании, которые просто приобрели и оставили компоненты разрозненными, но ещё не настолько интегрированы, как платформа, созданная с нуля. Со временем (и по мере того как они, вероятно, переведут компоненты на единую облачную архитектуру) они должны достичь высокой степени интеграции. Пока же, по крайней мере, видение и действия направлены на избежание эффекта Франкенштейна.

Скептицизм в отношении хайпа: Маркетинг ToolsGroup сочетает в себе практичность и модные высказывания. Они не так шумно заявляют о себе, как некоторые другие, но всё же подхватывали такие модные термины, как AI, обнаружение спроса, автономность и т.д. в последние годы. Как уже отмечалось, анализ Lokad специально указывал на хайп ToolsGroup: «утверждения об ‘AI’ вызывают сомнения… утверждения об ‘обнаружении спроса’ не подтверждены» ¹⁹. Например, ToolsGroup публиковали материалы об «обнаружении спроса» (краткосрочные корректировки), что могло быть просто броской речью, обозначавшей использование скользящего среднего недавних продаж – не что-то принципиально новое. Это может ввести в заблуждение менее опытных клиентов, заставив их поверить в наличие какой-то магии. Также ToolsGroup иногда приводят невероятные результаты клиентов (например, «запасы сократились на 30% при повышении уровня сервиса до 99%»), что, хотя и может быть правдой в отдельном случае, звучит слишком хорошо, чтобы быть нормой. Нам необходимо видеть последовательные доказательства. С другой стороны, ToolsGroup существует уже давно и обычно пользуется хорошей репутацией за достижение результатов – так что их хайп обычно не безоснователен. Возможно, они чрезмерно использовали терминологию AI около 2018 года, когда все это делали. Теперь, когда они действительно приобрели AI-компанию, их заявления об AI могут восприниматься серьёзнее. Они упоминают «квантовое обучение», что, если честно, звучит как модное слово (квантовые вычисления на самом деле не используются – это просто бренд для их алгоритма). Это отчасти хайпово. Но при этом они намекают, что за этим скрывается нечто конкретное (нелинейная оптимизация, предписывающая аналитика) ⁵¹. Они также начали позиционировать себя как «Лидер в SPARK Matrix для розничного прогнозирования и пополнения» ⁶⁷ – ссылаясь на рейтинги аналитиков, что может быть результатом влияния вендоров. Это маркетинг, но не чрезмерный. Одну вещь стоит отметить: ToolsGroup теперь говорит об «автономности». Нужно внимательно отнестись к тому, насколько действительно автономной может оказаться система. Хотя они могут автоматизировать многое, полностью автономная цепочка поставок – это процесс. Пока они представляют это как цель (а именно: «путь к планированию, ориентированному на принятие решений (автономное)» ⁵⁷), это приемлемо. Если бы они утверждали, что интеграция «подключи и работай», это было бы преувеличением – ведь внедрение ToolsGroup всё равно требует интеграции и настройки. Однако, учитывая, что целевая аудитория ToolsGroup – средний бизнес, они подчеркивают более быструю реализацию по сравнению с крупными ERP-проектами. Они часто акцентируют внимание на простоте использования, что вполне правдоподобно и не является чистым хайпом. В плане умеренности модных слов они, вероятно, занимают среднюю позицию: не самые явные злоупотребители, но всё же используют модные термины. Противоречия, связанные с использованием неподходящей метрики (MAPE для вероятностных прогнозов), стали небольшим сигналом тревоги ⁶⁸ – это показывает, что маркетинг стремился подчеркнуть числовое улучшение, даже если оно не было методологически обоснованным. Мы бы предпочли честное общение вроде «наш подход отличается, вот почему традиционные метрики не применимы, вот какие метрики лучше». Возможно, ToolsGroup упростили объяснения ради продаж. Тем не менее, учитывая долгую историю успешной работы с клиентами и высокий уровень продления контрактов, можно сделать вывод, что они, в целом, выполняют свои обещания. Их заявления подкреплены примерами из практики. Они не продают воздушные замки; они предлагают проверенные технологии, обновленные посредством приобретений. Таким образом, хайп в основном сводится к позиционированию продуктов как «AI» или «квантовых», когда на деле используется стандартное машинное обучение. Это довольно типично для отрасли. Мы рекомендуем проявлять осторожность, но не отвергать полностью. Пользователю следует уточнить, как именно работает их AI, как реализовано обнаружение спроса и т.д. ToolsGroup, вероятно, сможет дать разъяснения (даже если окажется, что это выглядит как «мы используем машинное обучение для корректировки краткосрочных прогнозов с учётом последних продаж и сигналов по запасам» – что вполне приемлемо, лишь не звучит мистически). В итоге, маркетинговая стратегия ToolsGroup за последние несколько лет включает модные слова, через которые следует смотреть критически, но при этом делается упор на конкретные результаты (уровень сервиса, сокращение запасов и т.д.). Мы даем им среднюю оценку за скептицизм в отношении хайпа: хотя они не обходятся без модных слов, по сути их предложения более содержательны, чем просто пустые обещания (с небольшим минусом за некоторые вводящие в заблуждение формулировки, указанные внешним анализом).

Итог: ToolsGroup – это зрелый, но развивающийся игрок в области оптимизации розничной торговли. Он опирается на десятилетия опыта в оптимизации запасов с использованием вероятностного прогнозирования, дополненные возможностями по планированию ассортимента и оптимизации цен благодаря приобретениям. В результате ToolsGroup теперь может заниматься совместной оптимизацией запасов и цен – используя прогнозы спроса, учитывающие изменения цен, и принимая решения по ценовой политике с учетом запасов ⁴⁸. Их усилия по интеграции превращают ранее разрозненные инструменты в целостный комплекс планирования, хотя некоторые нюансы интеграции могут ещё устраняться. Сильная сторона ToolsGroup в вероятностном моделировании означает, что система надёжно справляется с неопределённостью спроса и разрабатывает стратегии пополнения запасов для обеспечения высокого уровня сервиса при минимальных затратах, а её новые улучшения с применением AI направлены на постоянную адаптацию этих решений в режиме реального времени ⁵⁷. У компании есть доказанный опыт автоматизации процессов планирования – многие рутинные задачи прогнозирования и пополнения запасов могут выполняться без участия человека, а планировщики занимаются только исключениями. Теперь, с появлением модулей для ценообразования и ассортимента, автоматизация распространяется и на эти области (например, автоматизированные скидки по правилам ⁶⁶ и AI-рекомендации по изменению ассортимента). Что касается сложностей розничной торговли, ToolsGroup в достаточной мере охватывает базовые задачи (прогнозирование для акций, сезонные распродажи, кластеризацию магазинов), хотя, возможно, ещё не обеспечивает автоматического обнаружения каннибализации или моделей замещения на том уровне, на каком это делают некоторые специализированные системы. Их подход к экономической оптимизации сместился от простого поддержания уровня сервиса к включению показателей прибыли (особенно в решениях для ценообразования и ассортимента ³³). Пользователям следует учитывать присутствие некоторой маркетинговой претенциозности – ToolsGroup свободно использует модные термины вроде «автономный» и «AI», и сторонняя критика отмечала некоторые их прошлые заявления об AI как преувеличенные ¹⁹. Однако, учитывая ощутимые улучшения, о которых говорят многие клиенты, и значительные инвестиции ToolsGroup в новые технологии (например, Evo), содержательная база их заявлений значительна. В нашем рейтинге ToolsGroup выступает как технически сильное и прагматичное решение: оно может не обладать эффектностью чистого AI-стартапа или масштабами мега-корпорации, но предлагает сбалансированное, продвинутое решение для ритейлеров, стремящихся оптимизировать планирование с меньшей долей хайпа и более конкретными результатами.

Источники: Интеграция ценообразования с обзором запасов ⁴⁸; критика заявлений ToolsGroup по AI и обнаружению спроса ¹⁹; ToolsGroup/Evo о достижении оптимальных решений для ценообразования+запасов ⁵¹ ⁵².

5. Blue Yonder (formerly JDA) – Мощный розничный комплекс, перестроенный для SaaS, но с наследием прошлого

Blue Yonder, ранее известный как JDA Software, является одним из крупнейших и старейших поставщиков программного обеспечения для оптимизации розничной торговли и цепочки поставок. Он предлагает комплексное решение, включающее прогнозирование спроса, пополнение запасов, распределение, управление категориями (ассортимент), оптимизацию цен и markdown-оптимизацию, управление складами, планирование рабочей силы и многое другое. В 2020 году JDA ребрендировался в Blue Yonder после приобретения немецкой AI-компании с одноимённым названием. С тех пор Blue Yonder (BY) перевёл значительную часть своего портфеля на единую платформу Luminate с использованием микросервисов и позиционирует себя как сквозное, AI-управляемое решение для оптимизации цепочки поставок и мерчандайзинга ⁶⁹. Безусловно, он удовлетворяет всем функциональным требованиям: немногим поставщикам удаётся сравниться с широтой предложений по оптимизации розничной торговли от Blue Yonder. Однако комплекс Blue Yonder также является результатом десятилетий приобретений (i2, Manugistics, Arthur, RedPrairie и т.д.), и хотя новая облачно-нативная архитектура Luminate является современной, под капотом некоторые алгоритмы и модули уходят корнями в наследственные подходы. Острая оценка конкурента прямо заявила: «Blue Yonder — результат длительной серии слияний и поглощений… под брендом BY находится разнородная коллекция продуктов, многие из которых устарели. Blue Yonder активно использует AI, но его заявления расплывчаты и не имеют существенной базы; проекты с открытым исходным кодом намекают на подходы до 2000-х (ARMA, линейная регрессия).» ⁷⁰. Это подчёркивает основное скептическое замечание: Является ли Blue Yonder по-настоящему передовой технологией или это лишь переупакованный наследственный гигант? Мы оцениваем Blue Yonder несколько ниже в нашем списке, не потому что ему не хватает возможностей (их предостаточно), а из-за опасений по поводу его согласованности, эффективности и ясности представляемых заявлений. Все же, как доминирующий игрок, он заслуживает пристального внимания.

Совместная оптимизация: Комплекс решений Blue Yonder по сути предоставляет отдельные, но интегрированные модули для оптимизации цен, прогнозирования спроса и пополнения запасов, а также планирования ассортиментной и мерчендайзинговой стратегии. Теоретически, розничный торговец, использующий все решения Blue Yonder, может достичь совместной оптимизации за счёт взаимодействия этих модулей. Например, Blue Yonder предлагает приложения Lifecycle Pricing (оптимизация обычных цен, оптимизация уценок, оптимизация промо-акций), которые получают входные данные из прогнозов спроса, поступающих от их движка Luminate Demand Planning. Эти прогнозы спроса, в свою очередь, учитывают ценовые эффекты, поскольку система прогнозирования Blue Yonder (изначально приобретённая у немецкого Blue Yonder) включает моделирование эластичности. Как объяснил Майкл Орр из Blue Yonder, «Blue Yonder использует данные для понимания того, как потребители, вероятно, будут вести себя и как изменение цены может повлиять на уровни запасов», помогая розничным торговцам избежать установки цен слишком высоко или слишком низко ²⁷. Это демонстрирует, что оптимизация цен в BY не проводится в изоляции: она явно моделирует, как изменения цен влияют на спрос и, следовательно, на запасы. Более того, планирование исполнения заказов Blue Yonder может быть связано с ценовыми решениями, обеспечивая, что если запланировано снижение цены (что вызовет всплеск спроса), планы поставок будут соответствующим образом корректироваться. Аналогично, инструмент управления категориями Blue Yonder (ранее известный как JDA Category Management) помогает определить ассортимент и планограммы; эти решения затем используются в их системах прогнозирования спроса и пополнения запасов. У них существовала общая концепция под названием «интегрированное розничное планирование», которая согласовывала финансовые планы по товарам, планы по категориям и планы поставок. На практике исторически клиенты JDA часто запускали эти процессы как полуотдельные из-за сложности инструментов. Но с появлением Luminate BY заявляет об более бесшовной интеграции с помощью единой платформы. Они подчёркивают свою «архитектуру микросервисов», поддерживающую сквозное планирование ⁶⁹ – то есть, например, сервис планирования промо-акций может на ходу вызвать сервис прогнозирования спроса для получения обновлённого прогноза при различных ценовых сценариях. Одновременный подход Blue Yonder к планированию (например, «Harmony» в их пользовательском интерфейсе) может показать планировщику влияние решений на различные функции. Таким образом, Blue Yonder способен на совместную оптимизацию, поскольку все части могут взаимодействовать: ценовые решения формируют прогнозы, которые, в свою очередь, влияют на запасы, и наоборот. Однако можно усомниться, насколько оптимальной является эта координация. Часто процесс может оставаться последовательным (сначала прогноз с предполагаемой ценой, затем оптимизация запасов на основе него, а затем итеративная отдельная оптимизация цен с учётом ограничений по запасам). Есть свидетельства того, что Blue Yonder стремится к истинной параллельной оптимизации: например, их новая концепция «Автономное планирование» вероятно предусматривает динамическое замыкание этих процессов. Приобретение компанией Blue Yonder фирмы по оптимизации цен (они сотрудничали с dunnhumby, но недавно, как я полагаю, интегрировали свои внутренние возможности с ML-платформой BY из Германии) гарантирует наличие передовых алгоритмов оптимизации цен. В целом, Blue Yonder предоставляет инструменты для совместной оптимизации, но достижение этого пользователем зависит от реализации нескольких модулей. Поскольку комплекс Blue Yonder модульный, некоторые клиенты могут использовать, например, только планирование спроса и поставок, но не ценообразование, и таким образом не достигать полной совместной оптимизации с BY. Для тех, кто использует полный комплекс, Blue Yonder, безусловно, способен совмещать вопросы запасов, ценообразования и ассортимента. При этом стоит отметить, что решения Blue Yonder изначально не были созданы как единое целое – они были интегрированы. Хотя Luminate добился прогресса в их соединении, возможно, интеграция всё ещё не так плотна, как в единой модели оптимизации (например, ценовой движок может не учитывать текущие уровни запасов, если не настроен и т.д.). Учитывая все аргументы, Blue Yonder заслуживает высокой оценки потенциала совместной оптимизации, с оговоркой, что для реализации этого потенциала может потребоваться значительные усилия.

Вероятностное прогнозирование и ИИ: Прогнозирование спроса от Blue Yonder (компонент от немецкого Blue Yonder, часто называемый Cognitive Demand Planning) основано в значительной степени на ИИ/ML. Они опубликовали улучшения, позволяющие достичь примерно на 12% большей точности прогнозов с использованием ML по сравнению с традиционными методами ⁷¹. Их подход обрабатывает огромное количество данных – включая погодные условия, события, онлайн-сигналы – для предсказания спроса. Хотя, скорее всего, для операционных целей генерируется одно число-прогноз, базовые модели могут выдавать вероятностные результаты. Фактически, оригинальное решение Blue Yonder (Германия) было известно автоматическим выбором модели (подобно подходу AutoML) и могло выдавать доверительные интервалы. Неясно, предоставляет ли производственная система распределения, но они подчеркивают важность сценарного планирования и симуляций. Например, они позволяют планировщикам моделировать несколько сценариев спроса, что подразумевает наличие распределения результатов за кулисами ⁷². Blue Yonder также упоминала о «симуляции Монте-Карло» в некоторых белых книгах по планированию поставок. Учитывая их широкую команду специалистов по данным, можно с уверенностью сказать, что прогнозирование Blue Yonder по крайней мере учитывает стохастичность, даже если не предоставляет явной функции распределения вероятностей для каждого товара. Они позиционируют его как «Cognitive» или «Machine Learning» прогнозирование. Кроме того, они приобрели возможности прогнозирования заказов клиентов из своих наследственных систем (например, методы i2 для вероятностных сроков поставки и так далее). Однако критики, такие как Lokad, указывали, что открытые компоненты, использованные Blue Yonder (tsfresh для извлечения признаков, Vikos – возможно, библиотека для прогнозирования, и PyDSE) свидетельствуют о зависимости от довольно традиционных методов ⁷³. Tsfresh используется для генерации признаков временных рядов (например, для извлечения сезонных метрик) – это полезно, но само по себе не представляет революционный ИИ. Упоминание ARMA и линейной регрессии подразумевает, что основное прогнозирование всё ещё может строиться на статистических моделях, дополненных признаками ML. Иными словами, «ИИ» Blue Yonder зачастую может представлять собой хорошо настроенное экспоненциальное сглаживание плюс регрессию для учёта причинных факторов. Это не обязательно плохо – эти методы доказали свою эффективность, но они уступают наиболее современным подходам глубокого обучения. Blue Yonder, безусловно, активно продвигает свой ИИ: такие термины, как «когнитивный», «машинное обучение», «ИИ/ML движки» встречаются в их материалах ⁷¹ ⁷⁴. Неясность того, как именно они это реализуют (возможно, это коммерческая тайна), порождает скептицизм по поводу «обмана ИИ». Но мы знаем, что у них есть талантливые специалисты (немецкая команда была сильна в академическом плане), так что, вероятно, система надежна, хоть и не демонстрирует излишней эффектности. Blue Yonder также применяет ИИ в других областях: например, их оптимизация цен использует машинное обучение для оценки эластичности цен и перекрестных эффектов; их планирование поставок использует эвристические методы и, возможно, ML для настройки параметров; их микро-исполнение использует ИИ для определения, с какого склада следует выполнить заказ и т.д. Они также продвигают «Luminate Control Tower», который использует ИИ для прогнозирования сбоев и выработки рекомендаций. Многие из этих процессов опираются на классификацию или прогнозирование ML за кулисами. Являются ли они вероятностными? Возможно, они выдают оценки риска или вероятности событий. В маркетинговых материалах Blue Yonder говорят о «оптимизационных движках с поддержкой ИИ, обрабатывающих огромные объемы данных… достигающих когнитивной автоматизации» ⁷⁵ ⁷⁶, что звучит впечатляюще, но не даёт конкретики. Можно с уверенностью сказать, что Blue Yonder использует большое количество ИИ, но из-за широкого охвата некоторые части могут не быть самыми передовыми. Например, пользователь на Reddit однажды отметил, что прогнозирование JDA (ныне BY) не было уникальным и многие по-прежнему использовали устаревшую логику с настройкой параметров. Патенты и исследования Blue Yonder могут пролить больше света (у них есть патенты на много-сценарное прогнозирование ⁷⁷). Исходя из этого, можно сказать, что Blue Yonder безусловно интегрировал ИИ/ML (особенно после приобретения Blue Yonder GmbH) в своё прогнозирование и оптимизацию. Это приводит к более точным прогнозам и, предположительно, к возможностям сценарного анализа. Однако скептический взгляд, высказанный Lokad, о том, что под капотом может находиться множество линейных моделей, упакованных как ИИ, указывает на необходимость осторожного подхода. Мы даём Blue Yonder высокую оценку за наличие функций ИИ/ML, но отмечаем, что некоторые конкуренты, разработавшие системы с нуля с применением ML (например, RELEX или Lokad), могут иметь преимущество в отдельных методах благодаря меньшей наследственности. Blue Yonder активно инвестирует в новейшие технологии (например, они упоминают исследования Generative AI для ассистентов планирования). Таким образом, они стараются оставаться на передовой.

Экономическое принятие решений: Решения Blue Yonder, особенно в области ценообразования и цепочки поставок, явно учитывают прибыльность и затраты. Для ценообразования Blue Yonder (исходя из изначально Revionics или их собственного решения) использует целевые функции, такие как максимизация маржи, дохода или достижение финансовой цели. Их оптимизация цен не ограничивается простым следованием правилам – она использует эластичность для выбора таких цен, которые максимизируют выбранный показатель при соблюдении ограничений (например, конкурентных ценовых индексов или уровней запасов). Таким образом, это по своей сути экономическая оптимизация. В области оптимизации запасов Blue Yonder (или наследственные системы JDA/i2) имел модули, такие как Multi-Echelon Inventory Optimization (MEIO), которые действительно стремились минимизировать общие затраты (затраты на хранение, затраты из-за отсутствия запасов) для заданного уровня обслуживания или максимизировать обслуживание в рамках бюджета – классическая оптимизация соотношения затрат и выгод. На практике некоторые клиенты использовали лишь целевой уровень обслуживания, но потенциал для оптимизации, основанной на затратах, был присутствующим. Инструменты Blue Yonder S&OP / IBP позволяют интегрировать финансовые планы и ограничения, что означает, что процесс планирования может оптимизироваться с учётом маржи или прибыльности (например, достижение целевого дохода при минимальных затратах и т.д.). Ещё одна область – распределение: инструмент распределения Blue Yonder может быть настроен так, чтобы распределять товары по магазинам таким образом, чтобы максимизировать прогнозируемый объём продаж (а значит, и прибыль), а не просто осуществлять равномерное распределение. Их планирование ассортимента может включать метрики вклада категории в прибыль для определения того, какие товары следует оставить, а какие – исключить. Поскольку исторически Blue Yonder обслуживал в первую очередь розничных торговцев, ориентированных на маржу (например, модные ритейлеры, использующие оптимизацию уценок для максимизации валовой рентабельности), им приходилось внедрять экономическую логику. Критика «неясности» ⁷³ может указывать на то, что ИИ Blue Yonder не до конца ясно интерпретирует экономические параметры (например, не показывает, какую прибыль приносит тот или иной прогноз), однако их модули оптимизации определённо используют экономические параметры (эластичность цен, затраты и т.д.). Например, решение Blue Yonder по оптимизации запасов заявляет, что оно «устраняет избыток запасов и снижает затраты на устаревание, поддерживая высокий уровень обслуживания» ⁷⁸ – что, по сути, является балансировкой затрат на устаревание и уровня обслуживания, т.е. экономическим компромиссом. Их оптимизация промо-акций учитывает эффект от акций против вложений в маржу для рекомендации наиболее прибыльных промо-мероприятий. Что касается альтернативных издержек, Blue Yonder может явно их не выводить, но их планировщики могут оценить их по сценарию: например, если запас товара A не будет пополнен, упущенная прибыль будет выступать в роли альтернативных издержек. Инструменты Blue Yonder могут смоделировать такой сценарий. Основная критика заключается в том, что Blue Yonder заявляет об использовании ИИ, однако может применяться множество линейных регрессий (которые обычно уже учитывают факторы затрат). Поэтому можно считать, что Blue Yonder хорошо справляется с экономическим подходом. Одним из потенциальных недостатков может быть то, что некоторые устаревшие части системы всё ещё могут использовать эвристические правила (например, некоторые старые системы пополнения запасов JDA были основаны на правилах min/max). Но, скорее всего, они уже заменены оптимизированными подходами. При стремлении Blue Yonder к «автономному планированию» часто упоминаются финансовые метрики как ключевой драйвер. В материале BusinessWire приводится цитата клиента, использующего передовые технологии BY: «Используя ИИ/ML, мы повышаем точность прогнозов и создаём цепочку поставок, готовую к будущему, что улучшает нашу финансовую эффективность» ⁷⁹. Таким образом, экономика находится в центре. Тем не менее, полное внедрение возможностей Blue Yonder может быть сложным – некоторые клиенты могут не использовать все функции экономической оптимизации из-за их сложности, предпочитая более ручной подход. Но потенциал присутствует. Мы даём Blue Yonder высокую оценку за наличие экономически ориентированных модулей (ценообразование, уценка, MEIO), хотя, возможно, с небольшим снижением, если некоторые из этих модулей не полностью интегрированы или удобны в использовании, что может приводить к субоптимальному применению.

Масштабируемость и экономическая эффективность: Наследие локальных решений Blue Yonder было известно своей “тяжеловесностью” – требовало значительных серверных мощностей и памяти, особенно в случае старого следа JDA. Однако в последние годы Blue Yonder перешла на нативную облачную платформу микросервисов на Microsoft Azure, что должно улучшить масштабируемость. В отчёте Gartner MQ отмечалось, что сильными сторонами Blue Yonder является «комплексная архитектура микросервисов» и способность обеспечивать сквозное планирование для множества предприятий ⁶⁹. Микросервисы означают, что монолитные приложения были разбиты на меньшие сервисы, которые могут масштабироваться независимо. Это, вероятно, улучшает производительность (например, масштабирование службы прогнозирования спроса для множества товаров отдельно от масштабирования службы планирования поставок). Среда Microsoft Azure также обеспечивает эластичность и, возможно, более низкие затраты на масштабирование по сравнению с локальными установками, поскольку можно на время развернуть мощные вычислительные ресурсы для пакетной обработки, а затем их выключить. Тем не менее, Blue Yonder остаётся одним из наиболее дорогих и корпоративных решений. Запуск всех этих продвинутых модулей означает обработку огромного объёма данных (особенно при использовании высокой детализации). Исторически поступали жалобы на долгие времена выполнения некоторых процессов JDA или на сложности с быстрой обработкой крайне больших объёмов данных. Рефакторинг микросервисов был направлен на решение многих этих проблем. Сейчас Blue Yonder может похвастаться почти реальным временем пересмотра прогноза для чувствительности спроса и частыми перепланированиями в их контрольном центре. Ещё один аспект – обработка данных: использование базового облачного озера данных Blue Yonder может улучшить методы хранения и доступа к данным по сравнению с устаревшими реляционными моделями. С другой стороны, широкий набор функций означает значительные накладные расходы на интеграцию; платформа Blue Yonder старается это компенсировать, но, скорее всего, остаётся достаточно нагруженной. Что касается экономической эффективности, Blue Yonder обычно нацелен на крупные предприятия с большими бюджетами, поэтому его выбирают не ради экономии затрат, а за его возможности. Это может требовать значительных расходов на Azure для заказчика (либо Blue Yonder включает это в SaaS-стоимость). Если розничный торговец пытается внедрить все модули BY, проект и последующие расходы могут оказаться очень высокими. Таким образом, экономическая эффективность не является главным достоинством BY – важна полнота функционала. Ещё один важный момент: старые модули Blue Yonder часто работали в памяти (JDA имел in-memory OLAP для планирования чисел). Такая концепция in-memory могла означать высокое потребление памяти. Но с микросервисами, возможно, они используют масштабируемые пуллы памяти Azure более эффективно. Конкурентная критика от Lokad конкретно утверждала: «корпоративное ПО не сводимо путём M&A, под BY лежит сумбурная коллекция… утверждения туманные, open-source намекает на устаревшие технологии» ⁷⁰. Хотя это касалось в основном интеграции и шумихи, такое высказывание косвенно указывает на неэффективность — «сумбурная коллекция» часто подразумевает, что каждая часть может иметь свою собственную инфраструктуру, не оптимизированную, что приводит к большему общему потреблению ресурсов. Мы подозреваем, что Blue Yonder улучшила интеграцию с Luminate, но избыточность всё ещё может сохраняться. Например, модуль ценообразования может иметь своё собственное хранилище данных, отличное от хранилища для прогнозирования, если оно не объединено — то, что Luminate и предназначен для решения, но это требует времени. В итоге: Масштабируемость – Blue Yonder может удовлетворить потребности крупнейших розничных сетей (многие из десятки лучших мировых ритейлеров используют какой-либо компонент Blue Yonder), что доказывает его способность обрабатывать огромные объёмы данных. Производительность может быть не мгновенной из коробки, но при доработке и использовании облачных вычислений система вполне работоспособна. Экономическая эффективность – возможно, на нижнем уровне; система, как правило, требует большого количества ресурсов и стоит дорого. Переход на SaaS может снизить затраты на локальный IT для клиентов, но эти затраты превращаются в абонентскую плату. Кроме того, как крупный поставщик, BY может устанавливать премиальные цены. Таким образом, если стоимость является критерием, Blue Yonder часто уступает более легковесным решениям. Если же критерием выступают исключительно мощность и полнота функционала, BY подходит. Мы оценим их как средних по масштабируемости (поскольку да, они масштабируются, но потенциально с высокими затратами и сложностью).

Учет сложных розничных факторов: Решения Blue Yonder явно охватывают практически все сложные факторы, о которых только можно подумать:

Каннибализация и эффект ореола: Их машинное обучение для прогнозирования спроса обладает возможностью учитывать межпродуктовые влияния (вероятно, они включают признаки, показывающие, находятся ли товары-заменители на акции и т.д.). Также их инструмент оптимизации акций учитывает каннибализацию – например, при рекомендации акций система измеряет, приведёт ли акция для Продукта A к снижению продаж Продукта B, и рассчитывает чистый прирост. У Blue Yonder был модуль под названием Эффективность акций, который выполнял нечто подобное. Кроме того, их аналитика по управлению категориями часто оценивает влияние ценовых изменений на категорию (чтобы, например, не поднять цену на один товар и не потерять маржу на сопутствующих продуктах). Примечательно, что стратег Blue Yonder может устанавливать эластичности, включающие перекрёстные эффекты. В статье Business Insider Revionics (ныне отдельная компания под Aptos) рассказывал о применении ИИ для имитации ситуации, когда снижение цены на тесто для тортов приводит к увеличению продаж яиц ⁸⁰, что является сценарием эффекта ореола. Ценовое решение Blue Yonder аналогично решению Revionics, поскольку они конкурируют, так что, предположительно, BY может также моделировать такие межпродуктовые исходы. Кроме того, прогнозирование акций в Blue Yonder специально может учитывать факторы каннибализации, поскольку это является отраслевым стандартом.
Замещение (эффекты отсутствия на складе): Планирование спроса в Blue Yonder может использовать информацию о позиционной доступности; если товар отсутствует, логика прогноза может объяснить падение не снижением спроса, а недостатком наличия. Немецкая система машинного обучения Blue Yonder была известна тем, что учитывала коэффициенты наличия на складе, чтобы не ошибочно интерпретировать отсутствие товара как снижение спроса. Кроме того, планирование заказов в Blue Yonder может включать правила замещения – например, если товара X нет, система может заранее увеличить поставки заменяющего товара Y (некоторые продвинутые пользователи используют именно такой подход).
Срок годности/скоротопортящиеся товары: Blue Yonder имеет большое число клиентов в сегменте продуктовой торговли, поэтому они разработали функции для скоропортящихся товаров. Например, их система пополнения запасов может учитывать срок годности – чтобы не заказывать столько, что товар успеет испортиться. Они также могут оптимизировать производство непосредственно в магазинах (например, для свежих продуктов, у них существуют решения в управлении персоналом, интегрированные для планирования производства свежих товаров – косвенно снижая потери). Прогнозирование Blue Yonder позволяет детализировать данные до уровня дня, что имеет решающее значение для свежих товаров, и использует сезонность по дням недели и тому подобное. Приводятся примеры (например, случай с Knauf в BusinessWire по цепочке поставок, а также некоторые примеры из продуктовой сферы), где «с помощью BY уровень порчи снизился и т.д.» – хотя RELEX также приводил примеры в этом направлении. Скорее всего, у Blue Yonder есть аналогичные истории успеха (я припоминаю случай с 7-Eleven, где BY использовалась для прогнозирования свежих продуктов).
Планограмма и ограничения по пространству: Решение Blue Yonder по управлению категориями является фактически отраслевым стандартом для создания планограмм и планирования торговых площадей. Оно напрямую влияет на планирование ассортимента и пополнения запасов, предоставляя данные о том, сколько места выделено для каждого продукта в каждом магазине (так что служба планирования поставок знает максимальное количество товара, которое можно разместить на полке). Системы Blue Yonder точно используют эту информацию – например, если планограмма выделяет 2 фасада для товара, система не отправит больше, чем может разместиться. Кроме того, BY может оптимизировать, в какие магазины доставлять новый товар, основываясь на имеющемся пространстве и локальном спросе (например, если на полке не может поместиться больше артикулов, товар может не включаться в ассортимент).
Факторы рабочей силы и исполнения: Несколько косвенно, но BY также учитывает, как план будет выполнен – например, планирование рабочей силы для разгрузки поставок, если для акции отправляется дополнительный инвентарь, и т.д. Это демонстрирует, насколько их подход интегрирован для розничных операций.
Омниканальность: Новые возможности Blue Yonder также учитывают компромиссы при выполнении заказов (отправка из магазина против распределительного центра), что не является прямым вопросом, но представляет собой ещё одну сложность, которую они оптимизируют (затраты против скорости и т.д. – выходит за рамки данного обсуждения).
Погодные и внешние факторы: Эти аспекты учитываются с помощью машинного обучения в прогнозировании спроса, что является «сложным фактором» в условиях переменчивости спроса. По сути, Blue Yonder имеет решение или функцию практически для каждого сложного сценария в розничной торговле. Проблема заключается в том, что необходимо не только внедрить, но и настроить эти функции. Исторически некоторые розничные торговцы испытывали трудности с внедрением продвинутых моделей каннибализации в JDA, поскольку это было сложно и требовало поддержки специалистов по анализу данных. Теперь, с помощью автоматизации на базе ИИ, BY пытается реализовать это самостоятельно. Вероятно, это работает, хотя пользователь может не иметь возможности легко увидеть или контролировать процесс (сценарий «когнитивного чёрного ящика»). Тем не менее, можно с уверенностью предположить, что BY охватывает эти сложности, потому что их конкуренты тоже так делают, и им нужно было поспевать. На самом деле, Blue Yonder имеет функцию, называемую анализом переноса спроса (из старого JDA), которая специально измеряла каннибализацию внутри категорий для помощи в принятии решений по ассортименту – то есть количественно определяла, как спрос переходит от одного продукта к другому, если один из них отсутствует или находится под акцией. Таким образом, да, эта концепция присутствует. Учитывая всё вышесказанное, Blue Yonder, вероятно, получает высшую оценку за учет сложных факторов, ведь за десятилетия любую проблему розничного торговца JDA/Blue Yonder добавляли функциональность для её решения (или приобретали компанию, которая это делала). Единственное замечание: иногда старые подходы могут быть менее автоматизированными (требуя ручной настройки взаимосвязей и т.д.), тогда как новые поставщики учатся делать это автоматически. Blue Yonder теперь пытается реализовать автоматическое обучение с помощью ИИ, но доверять этому требует определённой веры, поскольку они не всегда раскрывают подробности. Критика конкурентов относительно использования старых методов ⁷³ предполагает, что их моделирование каннибализации может использовать линейную регрессию (что всё же может адекватно захватывать процессы, если выполнено правильно). Это не обязательно является недостатком, просто не выглядит инновационно. Мы оценим BY очень высоко по этому критерию, с незначительным замечанием, что настройка может оказаться сложной.

Автоматизация: Видение Blue Yonder, выраженное в концепциях «Автономная цепочка поставок» и «Когнитивное планирование», по сути, заключается в автоматизации. Они рекламируют, что их Luminate Planning может автоматически корректировать планы с минимальным участием человека, а их алгоритмы способны самооптимизироваться. Например, «алгоритмическое базовое прогнозирование» Blue Yonder значительно снижает нагрузку на человеческих аналитиков – планировщики затем сосредотачиваются только на исключениях (таких как новые продукты или крупные события). Многие клиенты BY используют автоматическое пополнение запасов: система генерирует заказы, которые сразу переходят в стадию исполнения, если не зафиксированы как исключения. Система Fulfillment BY имела функции, такие как «адаптивные, обучающиеся уровни безопасных запасов», что означало меньше ручной настройки параметров. В вопросах ценообразования Blue Yonder (как и другие инструменты для ценообразования) может осуществлять автономное обновление цен в рамках заданных правил – например, автоматически снижать цены каждый понедельник, исходя из текущей скорости реализации по сравнению с планом. Я предполагаю, что некоторые розничные клиенты BY позволяют системе самостоятельно принимать определённые ценообразовательные решения (особенно по снижению цен, которые могут быть локализованными и частыми – слишком много для ручного управления). Даже система Luminate Control Tower Blue Yonder может автоматически разрешать отдельные исключения (например, если поставщик опаздывает, автоматически ускоряя поставку из другого источника) – это автоматизация на стадии исполнения. Однако исторически Blue Yonder также была известна тем, что ориентировалась на планировщиков: система предоставляет отличные рекомендации, но многие компании по-прежнему задействуют множество планировщиков для корректировки этих рекомендаций (частично из-за сложности системы или недостаточного доверия к ней). Переход к «автономности» всё ещё в процессе. Собственные публикации в блоге Blue Yonder о повышении точности прогнозов акцентируют внимание на том, чтобы позволить ИИ выполнять основную работу и ограничивать ручное вмешательство ⁸¹, что подразумевает поддержку автоматизации. У них есть концепция исключений/оповещений, которая способствует подходу «управления по исключениям» – характерной черте автоматизации (вмешиваться только при необходимости). После приобретения Blue Yonder компанией Panasonic в 2021 году также возник акцент на подключении к IoT и автоматизации даже физических решений (например, регулирование расположения товаров на полках с помощью робототехники на основе изменений в плане — перспективное направление, однако пока на уровне идеи). С другой стороны, поскольку инструменты BY так богаты функционалом, некоторые пользователи могут стать чрезмерно зависимыми от ручной настройки (например, корректировка десятков параметров, выполнение ручных сценариев «что если» и т.д.), что может затруднить полноценную автоматизацию. Нет сомнений, что Blue Yonder способна обеспечить высокий уровень автоматизации, но то, насколько успешно будет реализована автоматизация в конкретном случае, может варьироваться. Я помню кейс-стадии, где розничные торговцы сообщали, что BY автоматически генерировала 90% их заказов, что аналогично примерам ToolsGroup. Так что, вероятно, использование передовых практик действительно дает такие результаты. Учитывая активный маркетинг концепции «автономности» Blue Yonder, можно предположить, что они внедряют новые функции для повышения уровня автоматизации (например, автопилот для моделей ИИ – автоматическое переключение алгоритмов при изменении трендов; или советник по сценарию – рекомендующий лучший сценарий). У них даже есть цифровой ассистент (возможно, с голосовыми запросами для планирования) – не прямая автоматизация, но снижающая потребность в ручном анализе. Таким образом, BY ориентирована на автоматизацию, хотя, возможно, исторически пользователи не использовали её в полной мере из-за вопросов доверия или сложности. Мы оценим их высоко, но не идеально, как это могут сделать более мелкие, agile-поставщики, поскольку внедрение BY до уровня, когда можно полностью доверить системе выполнение задач без надзора, может занять больше времени. Но как только это будет достигнуто, система должна функционировать надёжно. Сайт Panasonic называет это «Реализацией Автономной цепочки поставок™ с Blue Yonder» ⁸² – они регистрируют торговую марку Автономная цепочка поставок, так что это подразумевает именно то, что они имеют в виду! Чтобы сохранить скептический настрой: отметим, что на данный момент полностью автономное планирование всё ещё встречается редко в отрасли, даже с BY – человеческий надзор остаётся. Однако BY значительно снижает нагрузку на персонал.

Интеграция технологий: Blue Yonder является классическим примером платформы, созданной посредством многочисленных приобретений (с 1980‑х до 2010‑х годов). Однако с примерно 2015 года они инвестировали в её унификацию. Платформа Luminate — их ответ: микросервисы в общем облаке, общая модель данных частично (есть Luminate Data Hub) и единый стиль интерфейса. Они добились прогресса – например, модули прогнозирования спроса и пополнения запасов теперь бесшовно используют один и тот же интерфейс и данные (в отличие от старых решений JDA, где Прогноз спроса и Исполнение были отдельными приложениями, требующими пакетной интеграции). Микросервисная архитектура означает, что новые возможности могут внедряться и подключаться без изменений монолита. Но давайте будем предельно ясны: внутри некоторые модули, вероятно, всё ещё работают на унаследованном коде (просто размещённом в облаке). Это означает, что интеграция осуществляется на уровне интерфейсов, а не через переписывание всего кода в единой кодовой базе (что было бы нереалистично за короткое время). Они опубликовали API старого кода в виде микросервисов и оркестрируют их. Это работает в значительной степени, как отметил Gartner, назвав это «всеобъемлющей микросервисной архитектурой» ⁶⁹, что является комплиментом. Ещё один плюс: Blue Yonder в значительной мере объединил свой интерфейс (интерфейс Luminate Experience). Пользователь, теоретически, может перейти с экрана планирования спроса к экрану управления запасами в рамках одного портала. Существует концепция Luminate Planning Workbench, которая пытается объединить несколько функций для планировщика. Тем не менее, критики, такие как Lokad, утверждают «корпоративное программное обеспечение не смешивается посредством M&A» ⁷⁰ – подразумевая, что объединить приобретённые продукты по-настоящему не так просто. Blue Yonder пытается сделать это, но, возможно, остаются некоторые изъяны: например, ценовое решение (первоначально отдельный продукт) может ещё не полностью ощущаться как часть планирования спроса в едином интерфейсе и может требовать отдельной настройки. Интеграция данных может стать проблемой: подают ли прогнозы спроса автоматически данные для моделей модуля оптимизации цен? Или их приходится экспортировать? Blue Yonder, вероятно, уже интегрировал это, но не факт. Замечание «случайная подборка продуктов, большинство из которых устарели» ⁷⁰ звучит резко – возможно, оно относится к некоторым старым модулям, таким как наследуемое планирование товаров JDA или старые оптимизационные движки, которые не обновлялись. Также высказывание «утверждения расплывчаты и не имеют существенного содержания» ⁸³ намекает, что иногда BY утверждает, что у них объединённый искусственный интеллект, но на деле это может быть лишь слабо интегрированными компонентами. Тем не менее, надо отдать должное Blue Yonder – они перевернули платформу больше, чем многие другие; например, они контейнеризовали старые алгоритмы, создали современные интерфейсы и связали их вместе. Ещё один аспект интеграции: Blue Yonder охватывает от планирования до исполнения в рамках одной компании (WMS, TMS для исполнения, а также инструменты планирования). Они также интегрировали эти компоненты (инвентарное планирование, например, может видеть запасы WMS практически в реальном времени и т.д.). Таким образом, теоретически, можно управлять всей цепочкой поставок на основе технологий Blue Yonder, что представляет собой интеграцию, выходящую за рамки простого планирования – большой плюс, если это удаётся. Исторически эти системы также работали изолированно (наследие JDA и RedPrairie). У них есть нечто, называемое Luminate Control Tower, которое объединяет и отображает данные по планированию и исполнению в одном представлении. Так наблюдается прогресс в интеграции. Учитывая всё вышеизложенное, Blue Yonder прошёл долгий путь, но всё ещё, вероятно, не столь проворен в интеграции, как продукт, разработанный с нуля внутри компании. Архитектура теперь позволяет интеграцию, и всё зависит от применения. Мы оценим интеграцию Blue Yonder как умеренно-высокую: безусловно, исторически это был «франкенштейнский» набор модулей, которым провели операцию по объединению – частично успешно, но всё ещё видно, что некоторые части выполнены в старом стиле. Сложность остаётся высокой. Например, для внедрения полного набора решений BY может потребоваться несколько команд экспертов, поскольку каждый модуль обладает своей глубиной. Это указывает на то, что на практике продукт не является полностью «единым» решением, а скорее «семейством продуктов под одной платформенной крышей». Между тем, ToolsGroup или Lokad ближе к единому решению, охватывающему несколько областей (меньше функций, но более интегрированного по замыслу). Таким образом, интеграция Blue Yonder лучше, чем у фрагментарных решений SAP, но, вероятно, уступает единым решениям.

Скептицизм относительно шумихи: Маркетинг Blue Yonder использует множество модных слов: «Когнитивный», «Автономный», «AI/ML», «От начала до конца» и т.д. Некоторые утверждения лишены конкретики (например, «улучшение прогноза на 12%» – улучшение относительно какого базового уровня? Или «поддерживается AI», но без подробностей о методе). Они выстраивают яркий нарратив «цифрового мозга», подобного o9, и иногда демонстрируют ограниченную прозрачность в том, как это работает. В одной из критических оценок говорилось: «утверждения расплывчаты и не имеют существенного содержания… проекты с открытым исходным кодом намекают на подходы до 2000 года» ⁷³, по сути обвиняя Blue Yonder в AI-washing (маркетинге старого вина в новых бутылках). Действительно, Blue Yonder быстро провёл ребрендинг после приобретения, позиционируясь как «пионер AI», что вызвало вопросы, поскольку JDA до этого не ассоциировалась с этим. Тем не менее, Blue Yonder обладает реальными AI-технологиями (унаследованными с приобретённой команды), но, возможно, они не настолько продвинуты, как заявляют. Например, называние их прогноза «когнитивным» может быть преувеличением – он продвинут, да, но многие другие предлагают схожие методы прогнозирования с помощью ML. Термин «когнитивный» подразумевает почти человеческое мышление, что является частью шумихи. Также термин «автономная цепочка поставок» – благородная цель, но любая такая система по-прежнему требует человеческого управления. Они иногда используют зарегистрированные товарные знаки, такие как «Autonomous Supply Chain™», что является маркетинговым приёмом. Ещё одна область хайпа – Blue Yonder рекламирует «чувство спроса» – концепцию, которую они приняли (некоторые из их решений, например, краткосрочное прогнозирование, по сути реализуют это чувство спроса). Как отметил Lokad, чувство спроса зачастую оказывается хайпом, если оно не реализовано должным образом. Blue Yonder, вероятно, имеет собственный метод (например, использование данных о продажах за прошлую неделю с увеличенным весом для корректировки краткосрочных прогнозов), но действительно ли он улавливает внешние сигналы или просто реагирует плавным сглаживанием – остаётся вопросом. Если бы они чрезмерно рекламировали это как «AI, ощущающий сдвиги спроса в реальном времени на основе социальных медиа» или подобное, возникли бы обоснованные сомнения в практичности. Также присутствует хайп интеграции: они заявляют о единой платформе, но, как уже обсуждалось, за кулисами структура не настолько однородна – маркетинг может скрывать сложности интеграции. С другой стороны, у Blue Yonder имеется множество реальных кейс-стадий и отзывов. Они не выдумывают результаты – у них есть крупные клиенты, которые публично делятся успехами (например, увеличением коэффициента заполнения, ростом выручки и т.д.). Blue Yonder также, как правило, не раскрывает слишком много технических деталей, что может создавать впечатление, будто за модными словами они прячутся. Для искателя истины материалы BY могут вызывать недоумение, поскольку они часто говорят о результатах и высокоуровневых возможностях, вместо того чтобы объяснять: «мы используем алгоритмы X, Y, Z». Но в материалах для корпоративных продаж редко вдаются в подробности алгоритмов. Это не уникально для Blue Yonder. По крайней мере, конкурентный анализ от Lokad выделил их за то, что они особенно часто прибегают к модным словам без достаточной научной новизны ⁷³. Учитывая, что мы хотим наказывать за расплывчатые заявления и хайп, Blue Yonder получает определённое снижение – они определённо много хайпят в последние годы. В качестве примера, документ Lokad поставил Blue Yonder на 12-е место из 14, конкретно указывая на их хайп и устаревшие основы ⁷⁰. Это предвзятый источник (конкурент Lokad), но он созвучен с предостережением не воспринимать все маркетинговые заявления BY буквально. Ещё один пример: Blue Yonder может утверждать «plug-and-play SaaS – быстрое достижение ценности», но многие клиенты сталкиваются с мульти-летними внедрениями – то есть разрыв между маркетинговыми заявлениями и реальностью лёгкости внедрения. Это также создаёт хайп относительно интеграции или удобства использования. Таким образом, покупателю следует сохранять здоровый скептицизм относительно заявлений о простоте и единой платформе – за кулисами это всё ещё могут быть отдельные модули, требующие значительных усилий по интеграции.

Итоги: Blue Yonder — это набор оптимизационных решений для ритейла, богатый функционалом, охватывающий управление запасами, ценообразование и планирование ассортимента (а также аспекты исполнения) – по сути, покрывающий все грани оптимизации ритейла. Он был модернизирован с помощью AI/ML (например, «когнитивное» прогнозирование спроса ²⁷) и облачной платформы, и способен совместно оптимизировать решения в традиционно разрозненных областях (например, принятие решений по ценообразованию, влияющих на планы управления запасами, и наоборот) ²⁷. Инструменты Blue Yonder явно учитывают рентабельность и расходы при принятии решений – от оптимизации цены, балансирующей маржу и объём, до оптимизации запасов, уравновешивающей уровень сервиса и затраты на хранение ⁷⁸. Решение способно моделировать сложные ритейловые динамики, такие как каннибализация, эффект гало и ограничения срока годности в рамках своих процессов прогнозирования и планирования, благодаря продвинутым алгоритмам и десятилетиям опыта в ритейловой науке о данных. Например, оно использует машинное обучение для выявления эффектов замещения товаров и промо-каннибализации, так что прогнозы и пополнения корректируются соответственно ⁸ ⁹. Благодаря недавней переархитектуризации на основе микросервисов Blue Yonder улучшил интеграцию ранее разрозненных модулей, предлагая более единую платформу Luminate с общими данными и единым пользовательским интерфейсом ⁶⁹. Это обеспечивает более высокий уровень автоматизации: многие клиенты Blue Yonder позволяют системе автоматически генерировать прогнозы, заказы и даже рекомендации по ценам, вмешиваясь только при возникновении исключений. Blue Yonder активно продвигает концепцию «Автономная цепочка поставок», и хотя путь к полной автономии ещё предстоит, их решения действительно позволяют принимать автоматизированные, основанные на данных решения в масштабе (один крупный клиент сообщил, что планировщики действуют по принципу «только по исключениям», в то время как система самостоятельно обрабатывает 95% пополнений по SKU для магазинов).

Однако, требуется скептический взгляд относительно заявлений Blue Yonder. Учитывая, что решения компании сложены из компонентов, приобретённых в ходе слияний и поглощений, некоторые из них до сих пор содержат унаследованные алгоритмы ⁷⁰. Единство платформы, несмотря на значительные улучшения, может быть не таким безупречным, как у единой системы, разработанной с нуля – внедрение всех частей может быть сложным и требовать значительных ресурсов. Кроме того, стоит отметить заметный маркетинговый хайп Blue Yonder: такие термины, как «когнитивный» и «автономный», используются свободно, порой превосходя реальные возможности программного обеспечения ⁷³. Независимые анализы отмечали, что за модными словами Blue Yonder зачастую используются проверенные (а иногда и устаревшие) аналитические методики ⁷³ – эффективные, но не магически преобразующие ситуацию с помощью AI. Дополнительно, затраты и сложность решения Blue Yonder могут быть высокими – для полного использования всех возможностей могут потребоваться значительные вложения времени, денег и квалифицированного персонала, что снижает достоверность концепции «plug‑and‑play». Короче говоря, Blue Yonder является крайне мощным решением – его можно считать эталоном функционального богатства и экспертизы в ритейле – и он продолжает развиваться с применением современных AI и облачных технологий. Он безусловно способен обеспечить передовую оптимизацию, если его правильно реализовать и использовать. Но необходимо пробить завесу маркетингового хайпа и тщательно оценить, на чём основаны каждое из заявлений. Там, где Blue Yonder демонстрирует явную ценность (например, доказанные улучшения точности прогнозирования, измеримое сокращение потерь в скоропортящихся товарах или увеличение продаж за счёт оптимизированного ценообразования), мы признаём его как продукт высшего класса. Там, где он опирается на расплывчатый маркетинг или умалчивает сложности интеграции, мы остаёмся осторожными.

В нашем рейтинге Blue Yonder остаётся ведущим поставщиком в области оптимизации ритейла благодаря своему масштабу и постоянным инновациям ⁶⁹, но мы несколько снижаем его оценки из-за технического наследия и маркетингового преувеличения. Для крупных ритейлеров, ищущих универсальную, энд‑ту‑энд систему и готовых к инвестициям, Blue Yonder часто является серьёзным конкурентом или стандартом. Для тех, кто отдает предпочтение гибкости, экономичности или простоте, обширный подход Blue Yonder может показаться чрезмерным.

Источники: Платформа Luminate Blue Yonder на базе микросервисов и её возможности ⁶⁹; заявление о связи влияния цен с уровнем запасов ²⁷; критический анализ заявлений BY относительно AI и их унаследованных технологий ⁷⁰ ⁷³.

6. SAP (SAP IBP & Retail) – Модернизированный комплект для крупных игроков, но всё ещё догоняет (Внимание: наследие)

SAP, гигант корпоративного программного обеспечения, предлагает возможности оптимизации ритейла через свою систему SAP Integrated Business Planning (IBP) для цепочки поставок и комплект SAP for Retail (в который входят инструменты планирования ассортимента и ценообразования, приобретённые ранее). Решения SAP охватывают прогнозирование спроса, планирование запасов и поставок, финансовое планирование ассортимента и мерчендайзинга, а также оптимизацию скидок. За последнее десятилетие SAP перешла от своих старых модулей APO (Advanced Planner & Optimizer) и других унаследованных решений для ритейла к новой облачной платформе IBP. Однако предложения SAP остаются несколько фрагментированными между системой IBP, ориентированной на цепочку поставок, и розничными приложениями, такими как CAR (Customer Activity Repository) и Retail apps. Поскольку критерии оценки подчёркивают необходимость избегать унаследованных подходов и «франкенштейнской» интеграции, SAP часто приводят в пример именно эти проблемы. Откровенная оценка 2021 года отмечала: «SAP (1972) приобрела SAF, KXEN, SmartOps… эти приложения работают на базе собственной технологии (F&R, APO, HANA). Корпоративное программное обеспечение не становится однородным посредством M&A, и под SAP лежит случайная подборка продуктов. Сложность велика, и для достижения успеха потребуются лучшие интеграторы – плюс ещё несколько лет» ¹¹. Это подчёркивает проблему SAP: множество компонентов слабо интегрированы, что требует значительных усилий при внедрении.

Совместная оптимизация: Модули SAP исторически работали разрозненно: например, SAP Demand Forecasting (часть F&R) генерировал прогнозы, которые передавались в отдельные системы SAP Pricing (из приобретённой Khimetrics) и SAP Assortment Planning (из другого компонента). В последние годы SAP пыталась объединить планирование в IBP – но IBP в первую очередь охватывает планирование спроса, запасов и поставок. Ценообразование и ассортимент находятся за пределами IBP, в других розничных решениях. Это означает, что настоящая совместная оптимизация (запасы + ценообразование + ассортимент вместе) не является сильной стороной SAP «из коробки». Возможно, потребуется соединить IBP, например, с SAP Markdown Optimization (который был отдельным продуктом) нестандартным способом. Были попытки: например, SAP Unified Demand Forecast (часть CAR) должен был предоставлять единый прогноз для всех последующих систем (таких как пополнение запасов и ценообразование). Если это реализовано, то, по крайней мере, цены и запасы будут согласованы по одному сигналу спроса. Однако фактическое совместное принятие решений – например, учет затрат на запасы при оптимизации цен – вероятно, требует индивидуальной интеграции. У SAP есть решение SAP Retail Optimization (старый Khimetrics) для ценообразования, которое может учитывать ограничения запасов при снижении цен (так что в этом ограниченном случае оно действительно совместно оптимизирует цены для распродажи с учетом доступных запасов). Также системы мерчендайзинга SAP слабо связывают планы продаж с планами поставок. В целом, архитектура SAP не оптимизирует эти процессы комплексно, а лишь передает выводы одной системы в качестве входа для другой. Например, IBP может сформировать план поставок, исходя из предполагаемой ценовой стратегии; если затем цены изменяются, планировщику придется обновлять сценарии IBP. Это не является автоматической обратной связью. SAP IBP развивается с появлением таких функций, как «Integrated Financial Planning», которые связывают финансовые результаты с планами поставок (здесь есть элемент совместной оптимизации, по крайней мере, при балансировании затрат и доходов). Но по сравнению с новыми поставщиками SAP отстает в бесшовной интеграции между функциями. Критика сложности ¹¹ свидетельствует о том, что даже обеспечение того, чтобы все компоненты SAP эффективно взаимодействовали, представляет собой крупный проект. Таким образом, мы оцениваем SAP низко по показателю совместной оптимизации. Это можно достичь, но требуется «самые лучшие интеграторы – плюс несколько лет» ⁸⁴ (прямая цитата) – не самое лестное одобрение.

Прогнозирование вероятностей и ИИ: SAP IBP включает модуль для «Demand», который предлагает некоторую предиктивную аналитику и даже интеграцию машинного обучения (они позволяют использовать SAP Analytics Cloud или внешние библиотеки ML для создания прогнозов, которые затем передаются в IBP). SAP также приобрела KXEN в 2013 году – инструмент для анализа данных, предположительно предназначенный для внедрения ML в различных областях. Однако собственное прогнозирование в IBP в основном продолжает традиции APO (статистические модели, такие как экспоненциальное сглаживание, метод Крокстона и т.д.). Они внедрили «Demand Sensing» в IBP, что представляет собой алгоритм (приобретенный у SmartOps), использующий недавние краткосрочные тренды для корректировки ближайших прогнозов – подход, который некоторые считают преувеличенной скользящей средней с взвешиванием. Это полезно, но не является полноценной революцией ИИ. SAP сейчас интегрирует больше возможностей ML – например, они применяют машинное обучение для прогнозирования запуска новых продуктов (на основании сопоставления шаблонов похожих товаров). Также у них есть оптимизационный движок (из SmartOps) для многоуровневого планирования запасов (более стохастический). В целом, инновации SAP в области ИИ для планирования отстают от специализированных решений. В рейтингах по планированию цепочек поставок MQ, Gartner часто отмечает ограниченность встроенного ML в SAP IBP по сравнению с другими. Они полагаются на партнеров или свою платформу Data Intelligence для продвинутого машинного обучения. Для оптимизации ценообразования инструмент SAP (из Khimetrics) использовал сложные алгоритмы (с элементами ML для оценки эластичности и т.д.), но этот инструмент в последнее время не получал значительных обновлений и, возможно, не является тесно интегрированным. Ходят слухи, что SAP может отказаться от части этих инструментов или заменить их новым сервисом на базе ИИ – неясно, но ничего заметного. Как отмечалась в критике, SAP пришлось совмещать множество приобретённых предиктивных компонентов (SAF занимался прогнозированием, SmartOps – оптимизацией запасов, KXEN – универсальным ML). Вероятно, им так и не удалось полностью интегрировать их в единый когерентный ИИ-движок. Вероятностное прогнозирование: основанный на SAF модуль F&R действительно генерировал распределения для времени выполнения и использовал уровни обслуживания для определения страховых запасов (то есть имел частичный вероятностный подход), но я не думаю, что SAP IBP по своей сути создает полные распределения вероятностей для спроса; он фокусируется на единственном числе и скорректированном значении, полученном по методу «sensing». Возможно, они предоставляют некоторые доверительные интервалы. С точки зрения шумихи, SAP использует модные термины, такие как «predictive analytics» и «machine learning», но их реально реализованный ИИ скромен. Мы оцениваем SAP относительно низко по продвинутому ИИ-прогнозированию – он хорошо покрывает базовые потребности (известен своим надежным, пусть и традиционным, прогнозированием), но не лидирует в области вероятностного прогнозирования или ML. Они пытаются догнать конкурентов, обеспечивая возможность внешней интеграции ИИ. Тем временем, некоторые клиенты SAP могут экспортировать данные для проведения ML-анализов в Python, а затем возвращать результаты – что указывает на то, что встроенные возможности SAP могут оказаться недостаточными.

Экономическое принятие решений: Исторически инструменты планирования SAP были ориентированы на метрики, а не на оптимизацию прибыли сами по себе. APO позволял устанавливать целевые уровни обслуживания или минимизировать затраты в планировании поставок, но не осуществлял прямую максимизацию прибыли. Розничные решения SAP для ценообразования (например, Markdown Optimization) однозначно имели экономическую направленность – они оптимизировали маржу или увеличение выручки от акций. Это математические решения оптимизации, нацеленные на максимизацию определенной функции (с учетом ограничений, таких как запасы или бюджет). Таким образом, в ценообразовании SAP демонстрировала силу в экономической оптимизации (Khimetrics была пионером в алгоритмах оптимизации розничных цен). В области запасов система MEIO от SAP (из SmartOps) стремилась минимизировать общие затраты при достижении заданного уровня обслуживания – опять же, экономический подход, хоть и с ограничением на службу. SAP IBP включает модуль «Inventory Optimization», который, вероятно, использует этот движок SmartOps для балансировки между затратами на запасы и уровнем обслуживания. Таким образом, этот компонент по своей сути направлен на управление прибылью/затратами. Планирование ассортимента в SAP, зачастую выполняемое в SAP Merchandise Planning, обычно носит эвристический характер (планировщики моделируют финансовые результаты, но это не алгоритм, который автоматически определяет, какие SKU исключить на основе ROI, даже если он может выделять товары с низкой прибылью для содействия принятию решений). В общем, SAP позволяет отслеживать финансовые показатели – например, IBP может показывать предполагаемую выручку и маржу в планах, однако пользователь зачастую сам принимает решения о компромиссах, а система не максимизирует результат автоматически. Существует также SAP Profit Optimization в определенных контекстах (возможно, в их инструменте по проектированию цепочки поставок или в сценариях S&OP), но об этом упоминается редко. Поскольку SAP ориентирована на планировщиков, принимающих решения, её часто используют как инструмент «что если», а не автооптимизатор. Тем не менее, их подсистемы для ценообразования и запасов действительно проводят оптимизацию «под капотом». Мы дадим им среднюю оценку: не настолько бесшовно ориентированы на прибыль, как, например, решения Lokad или новейшие подходы ToolsGroup, но они охватывают компромиссы затрат. Хорошим примером является новая функция IBP от SAP – расчеты «Return on Inventory Investment» для помощи в расстановке приоритетов. Но если система лишь вычисляет и показывает ROI, а не применяет алгоритм для максимизации ROI, то это другое. Учитывая всю сложность, многие клиенты SAP используют её по заранее заданным правилам (например, достигая целевых показателей выполнения, составляя бюджеты OTB для ассортимента на основе суждений планировщика). Таким образом, это не вершина оптимальности решений, но система способна работать, если правильно настроена. Критика, называющая приобретенные решения SAP «предсказуемой цепочкой поставок», подразумевает, что у SAP были компоненты для включения предиктивного анализа затрат и выгод, но интеграция отставала ¹¹. Мы склоняемся к мнению, что SAP отстает в автоматической оптимизации прибыли. Масштабируемость и эффективность затрат: Фирменной особенностью SAP является выполнение вычислений в оперативной памяти – SAP HANA представляет собой базу данных, работающую в памяти, которая лежит в основе IBP и других приложений. Она очень быстра для определённых задач, но чрезвычайно требовательна к памяти и стоит дорого. Многие компании считают, что решения SAP дороги для масштабирования, поскольку требуются большие объемы памяти HANA. Например, SAP IBP требует, чтобы все данные планирования находились в памяти HANA для быстрого выполнения расчетов, что может быть дорого для крупных ритейлеров (терабайты памяти). Это соответствует нашему критерию избегания решений с высокой нагрузкой на оперативную память. Действительно, один анализ отметил о другом поставщике (Relex): «Дизайн в памяти обеспечивает высокую скорость, но гарантирует высокие затраты на аппаратное обеспечение» ²² – что в точности соответствует подходу SAP. Таким образом, эффективность затрат вызывает сомнения; подход SAP часто обеспечивает быстрый отклик, но за счет высокой стоимости инфраструктуры (если только не переложить часть нагрузки на более дешевое хранилище, что, однако, снизит скорость). Облачное предложение SAP пытается смягчить это, обрабатывая данные в их HANA Cloud и взимая подписную плату, но по сути, затраты перекладываются на подписчика. Исторически внедрение SAP APO или F&R было достаточно масштабируемым – они могли обрабатывать огромные объемы (их использовали крупные глобальные компании), но иногда требовались ночные пакетные запуски или упрощение для соблюдения временных ограничений. IBP на базе HANA значительно сокращает время расчетов (некоторые циклы выполняются за минуты, тогда как в APO это занимало часы). Таким образом, масштабируемость по производительности улучшена, но по объему данных она ограничена бюджетом на память. SAP подходит для крупных предприятий (некоторые из крупнейших используют его), однако такие проекты часто требуют серьезного аппаратного обеспечения и оптимизации. Итак, SAP масштабируется для больших объемов данных, но не так эффективно по затратам, как, возможно, распределенные облачные решения. Что касается эффективности затрат: SAP известна как дорогостоящее решение в целом (лицензии, инфраструктура, затраты на интеграторов). Цитата из MQ ⁸⁴ о «самых лучших интеграторах плюс несколько лет» указывает на то, что внедрение требует значительных временных и человеческих ресурсов. Если измерять чистую вычислительную эффективность, HANA обеспечивает высокую производительность, но стоит дорого (очень высокая цена за ГБ оперативной памяти). Кроме того, некоторые модули SAP, такие как для ценообразования, имели отдельные движки, которые могли плохо масштабироваться (старый Khimetrics работал на Oracle DB и имел ограничения по размерам оптимизационных задач). Сейчас ситуация неясна. Учитывая все это, мы оцениваем SAP низко по эффективности затрат и умеренно по масштабируемости (она способна обрабатывать большие объемы данных, но за счет высокой стоимости и сложности, что и должно учитываться по критериям). Это в основном демонстрирует «чрезмерные вычислительные затраты», которых стоит избегать, если возможно.

Обработка сложных факторов розничной торговли: Розничные решения SAP действительно учитывают ряд сложностей:

Каннибализация/Эффект ореола: Прогнозирование в SAP (особенно через CAR Unified Demand Forecast) могло учитывать причинные факторы, включая проведение акций для связанных товаров и т.д., но исторически SAP была слабее в этой области. Метод SAF в основном ориентировался на один товар. У них был модуль SAP Promotion Management for Retail, который мог оценивать рост продаж и каннибализацию с использованием определенных моделей. Также оптимизация markdown от SAP учитывала перекрестные эффекты между товарами (возможно, в рамках категорий). Но, честно говоря, SAP не была известна как лучший в прогнозировании акций – многие ритейлеры использовали сторонние решения или выполняли это вручную. Возможно, KXEN предназначалась для выявления корреляций (например, с помощью ML для обнаружения паттернов каннибализации). Насколько хорошо это было интегрировано, остается неясным.
Замещение: SAP F&R имела функциональность для учета замещений (если товар отсутствует, система предлагала замену в заказах). Также при анализе упущенных продаж учитывалось, был ли заказ компенсирован другим товаром. Однако неясно, реализовано ли это «из коробки» или требует индивидуальной настройки. Логика MRP в ERP SAP по умолчанию не поддерживала замещения в планировании, это было больше аналитическое решение.
Скоропортящиеся товары: SAP имела F&R (Forecasting & Replenishment), специально адаптированную для продуктового сектора с учетом срока годности. Система позволяла устанавливать правила, чтобы не отправлять больше товара, чем может быть продано до истечения срока, и отслеживать возраст запасов. Многие продуктовые ритейлеры использовали SAP F&R для свежих товаров и получали улучшения. IBP может пока не включать всю эту логику «из коробки», но, возможно, через SAP CAR Fresh Inventory или аналогичные решения. SAP также имеет расширение для «планирования срока годности» в PP/DS. Таким образом, ограничения по сроку годности в планировании поставок учитываются в определенной степени.
Пространство/ассортимент: Инструмент планирования ассортимента SAP учитывает ограничения по пространству в магазинах на высоком уровне (например, максимальное количество категорий). Это не так интегрировано, как связь с планограммами от Blue Yonder, но они интегрируются с данными планограмм в CAR, чтобы гарантировать, что заказы магазинов не превышают вместимость полок согласно установленным правилам. Возможно, это не полностью автоматизировано, но реализуемо. У них была интеграция между SAP F&R и данными планограмм (через SAP Landscape Management), что позволяет учитывать ограничения по пространству в заказах.
Прогнозирование акций: CAR от SAP включает модель «Demand Influencing Factor», в рамках которой при прогнозировании учитываются акции, праздники и т.д. с использованием регрессии или ML. Таким образом, прогнозирование акций производится с учетом роста продаж. Многие клиенты SAP используют этот подход (с переменным успехом).
Внешние факторы (например, погода): С помощью KXEN или теперь предиктивных возможностей SAP Analytics Cloud система позволяет учитывать такие переменные. Были реализации, когда погода влияла на заказы сезонных товаров с использованием инструментов SAP, хотя в формате plug-and-play это не представлено. В итоге, SAP может справляться с этими задачами, но часто требует настройки статистических моделей или использования их новых предиктивных сервисов. Это не так «из коробки», как у некоторых специализированных поставщиков. Критика, называющая ассортимент решений SAP «случайным», указывает на отсутствие синергии – например, компонент прогнозирования акций может не бесшовно передаваться в систему пополнения запасов, и требуется интеграция. Если эта интеграция не срабатывает, то, например, каннибализация, выявленная одним модулем, может не передаваться в другие. Поскольку SAP IBP относительно новая, некоторые продвинутые функции еще не до конца развиты; например, там было базовое прогнозирование, а только недавно (с 2022+) начали добавлять ML-ориентированное «demand sensing» или внешние сигналы спроса. Я бы оценил SAP как среднюю по сложным факторам – у них есть возможности, но они не так продвинуты или автоматизированы, как у некоторых конкурентов. Например, ритейлеру может понадобиться вручную настроить, как акция на товар A снижает спрос на товар B в системе SAP, тогда как RELEX может выявлять это автоматически. Также в их материалах недостаточно освещается решение по каннибализации; некоторые клиенты могут полагаться на внешние инструменты (например, используя SAP HANA для запуска кастомного ML, чтобы выявить каннибализацию, а затем внести коррективы). Поэтому я бы немного снизил им оценку в этом аспекте.

Автоматизация: Философия SAP традиционно больше ориентирована на «поддержку планирования», чем на «безучетное планирование». Часто требуется, чтобы планировщики запускали пакетные задания и анализировали результаты. Например, SAP APO был очень интерактивным инструментом, где планировщикам приходилось часто публиковать прогнозы, запускать оптимизацию и т.д. SAP IBP улучшил некоторые аспекты автоматизации с помощью оповещений и расписаний, но это все еще инструмент циклического планирования, а не непрерывного автономного управления. У многих клиентов SAP по-прежнему существуют большие команды планирования, проводящие анализ сценариев «что если» в таблицах IBP. В розничной торговле решения SAP, такие как Merchandise Planning и Assortment, по сути являются инструментами ручного планирования (похоже на Excel, но интегрированными). Они не автоматизированы – планировщикам требуется устанавливать цели и выбирать ассортимент. Оптимизация ценообразования может быть автоматизирована в определенной степени (алгоритм выдает рекомендации по ценам, но обычно аналитик по ценообразованию их проверяет/одобряет в SAP). Пополнение запасов в SAP (либо через F&R, либо через ERP MRP) автоматизировано для генерации предложений по заказам, которые затем могут быть автоматически преобразованы в заказы на поставку при соблюдении допусков; это делалось довольно часто. Таким образом, пополнение запасов в магазинах могло осуществляться без участия человека – многие продуктовые ритейлеры делали это с помощью SAP F&R или теперь CAR/Unified Demand Forecast плюс автоматического создания заказов в S/4. Это сильная сторона – SAP может довольно хорошо автоматизировать пополнение запасов, как только оно настроено (как и любая достойная система). Недостаток, возможно, заключается в способности автоматически пересматривать планы «на лету» с помощью машинного обучения – они все еще зависят от пакетных циклов (ежедневных или еженедельных). Также существуют оповещения об исключениях, которые сигнализируют о расхождении продаж, чтобы планировщик мог быстро внести коррективы вручную (полуавтоматически). IBP представил такие функции, как «самонастройка прогнозов» (система автоматически выбирает лучшую модель, без необходимости ручного выбора). Это базовая автоматизация. Маркетинг SAP с призывом к «чувствительности спроса» подразумевает более частую автоматизацию обновлений прогноза с использованием последних данных, что частично автоматизировано. Но по сравнению с другими, SAP не продвигает концепцию полной автономности; основное внимание уделяется поддержке эффективности работы планировщиков. Серьезная зависимость от интеграторов указывает на то, что это не просто автопилот, который можно включить. Поэтому я оцениваю SAP ниже по уровню автоматизации. Его внедрение часто требует значительных усилий и все еще нуждается в существенном ручном контроле. Многие процессы остаются управляемыми планировщиками (с поддержкой системных расчетов). Таким образом, они, вероятно, не достигают цели «полностью автономного» планирования. Также существует внутренняя политика: пользователи SAP ожидают возможности вмешательства; они доверяют системе до определенной степени, но не полностью позволяют ей работать самостоятельно. Без доказательств того, что какой-либо клиент SAP осуществляет полностью автономное планирование, я предполагаю, что таких случаев нет или они редки. (В отличие от ToolsGroup или Blue Yonder, у которых есть подобные упоминания).

Технологическая интеграция: История SAP действительно заключается в последовательности приобретений, сложенных поверх основной технологии:

У них была собственная система APO (для цепочки поставок) и отдельная система Forecasting & Replenishment (F&R) для розничной торговли.
Затем они приобрели SAF (прогнозирование спроса), SmartOps (оптимизация запасов) и частично интегрировали их в APO или IBP.
Приобрели Khimetrics (оптимизация цен) и Retek (системы мерчандайзинга), интегрировав их в состав SAP Retail.
KXEN (машинное обучение) интегрирован в их аналитические предложения.
Всё это работает поверх HANA или ECC. Это как раз «Франкенштейн». Подход SAP к интеграции этих систем таков: в IBP они перестроили функции APO на HANA и добавили логику SmartOps для управления запасами, а возможно, и некоторые идеи SAF для спроса. Но первоначально IBP страдал от недостатка функциональности (некоторые утверждают, что раннее прогнозирование в IBP было проще, чем в старом APO или SAF, и сейчас они догоняют). Со стороны SAP Retail: некоторые компоненты были объединены в CAR (Customer Activity Repository), который пытается быть единой платформой для данных о спросе и аналитики (например, единый прогноз спроса, управление акциями). CAR должен был интегрировать транзакции магазинов с планированием – хороший шаг в направлении интеграции. Однако исторически CAR и IBP не взаимодействовали беспрепятственно (сейчас они соединяются через API). Главная проблема SAP заключается в наличии двух параллельных платформ (IBP для цепочки поставок и CAR для планирования розничной торговли). Имеется перекрытие и потенциальный конфликт, хотя они позиционируют IBP для специалистов по цепочке поставок, а CAR – для специалистов по мерчандайзингу. Интеграция между ценообразованием, ассортиментом и планированием поставок в SAP часто осуществляется через интеграцию с основным ERP (например, передача прогнозов в ERP, откуда данные поступают в другой модуль – а не единый механизм). В критической заметке ¹¹ говорится: «эти приложения построены на собственной технологии… под брендом SAP — беспорядочная совокупность… высокая сложность, необходимы ведущие интеграторы и годы для достижения успеха». Это как раз подытоживает проблемы интеграции – их можно исправить с помощью лучших консультантов, но они не интегрированы элегантно «из коробки». Многие клиенты SAP в розничной торговле жалуются на несколько систем, которые дублируют данные (например, эластичность цен может рассчитываться в инструменте ценообразования и отдельно учитываться в инструменте прогнозирования без связи). Решением SAP стало перенесение всего в базу данных HANA, чтобы данные можно было легко обмениваться на уровне базы данных, а также разработка сценариев интеграции с использованием SAP Cloud Platform или CPI. Однако это требует дополнительных усилий. Поскольку SAP продает целый набор решений (ERP, планирование, выполнение), теоретически он должен обеспечивать глубокую интеграцию. На практике разные модули появлялись в разное время и были сшиты вместе. Интеграция в SAP не так хороша, как у микро-сервисов Blue Yonder или даже модульного набора ToolsGroup. Часто требуется выполнение индивидуальных проектов для выравнивания потоков данных. Таким образом, SAP явно подпадает под категорию «Франкенштейна» в некоторой степени (они как минимум признали это и пытались объединить через HANA и CAR, но, по мнению экспертов, до конца проблему не решили). Таким образом, по критерию технологической интеграции мы даем SAP низкую оценку. Само это высказывание из нашего источника является экспертным резюме их проблем с интеграцией ¹¹. Это говорит о том, что даже SAP часто приходится сотрудничать с интеграторами, такими как Accenture или EY, чтобы успешно внедрить их решения для планирования.

Скептицизм в отношении хайпа: SAP не раздувает шумиху вокруг ИИ так ярко, как некоторые другие, но в своем маркетинге они используют модные слова (говорят о «встроенном ML», «чувствительности спроса», «цифровом двойнике цепочки поставок» и т.д.). Многие в отрасли скептически относятся к заявлениям SAP, поскольку иногда функциональности не так развиты, как первоначально рекламировалось (например, ранний IBP не имел некоторых обещанных возможностей, реализованных позже). Кроме того, SAP часто представляет видение «интегрированного сквозного планирования», которое звучит отлично, но многие знают, что на практике это несколько модулей, которые необходимо интегрировать с существенными усилиями. Таким образом, существует разрыв. Маркетинг SAP вокруг IBP делает акцент на «быстром развертывании» (так как это облачное решение) и «удобных панелях управления» – отчасти верно, но развертывание IBP все же может занять год или более для сложных случаев. Что касается ИИ, SAP, как правило, не преувеличивает свои реальные предложения – они признают, что в передовой аналитике зависят от партнеров. Иронично, что SAP может быть более консервативен в раздувании хайпа, чем более мелкие поставщики. Их шумиха в основном связана с интеграционными заявлениями (например, «Интегрированное бизнес-планирование» звучит как полностью интегрированное решение, хотя на самом деле охватывает только планирование цепочки поставок, а не всей розничной торговли). Еще один пример: «Пополнение запасов по спросу» SAP – модное выражение вокруг методологии DDMRP, которую они продвигают, что некоторые считают хайпом/трендом, а не проверенным решением во всех случаях. Они присоединились к этой тенденции. Также часто используются такие термины, как «Цифровая цепочка поставок» в маркетинге SAP. Учитывая размеры SAP, их хайп, возможно, менее преувеличен по тону, но они определенно представляют свое решение как готовое к будущему универсальное, в то время как критики видят его как сложное и отчасти устаревшее. Таким образом, с точки зрения скептицизма, мы предостерегаем, что многие обещанные преимущества SAP достигаются только за счет значительной кастомизации или могут быть не настолько автоматизированными, как подразумевается. Независимое исследование дало SAP среднюю оценку среди поставщиков и явно указало на сборную конструкцию от слияний и поглощений и сложность ¹¹. Это, по сути, означает: «не думайте, что все работает бесшовно; внутри всё довольно запутанно». Поэтому оценка с учетом хайпа является справедливой. Мы можем сказать, что SAP достаточно прозрачен для крупных клиентов, сообщая, что требуется серьезная реализация – возможно, не такой блестящий хайп, но их маркетинг сглаживает вопрос о том, сколько усилий требуется для его успешной работы. Таким образом, умеренный скептицизм в отношении хайпа – не так перегружен модными словами, как o9 или Blue Yonder, но всё же содержит множество оптимистичных утверждений, требующих проверки реальностью.

Резюме: Предложения SAP по оптимизации розничной торговли являются всеобъемлющими на бумаге, но страдают от того, что представляют собой наследие сборной конструкции, которое не полностью перешло в современную эру, управляемую ИИ. Платформа SAP IBP и связанные с ней розничные модули, безусловно, могут решать задачи управления запасами, ценообразования и формирования ассортимента, но не в по-настоящему едином, совместно оптимизированном режиме. Совместная оптимизация ограничена из-за разрозненных инструментов: например, планирование спроса и пополнение происходят в IBP или F&R, в то время как планирование ценообразования и ассортимента осуществляется в отдельных модулях SAP с передачей данных пачками. В SAP отсутствует единый движок, который одновременно оптимизирует запасы и цены (эти решения координируются людьми и процессами, а не одним алгоритмом).

SAP действительно использует ИИ/ML в отдельных областях – например, алгоритмы «чувствительности спроса» для корректировки краткосрочных прогнозов или машинное обучение для прогнозов новых продуктов – но большая часть его прогнозирования по-прежнему основана на традиционных методах и правилах, заданных пользователями ¹¹. Примечательно, что SAP пришлось приобретать специализированные компании (SAF, SmartOps) для дополнения APO, и даже сегодня вероятностное прогнозирование и продвинутое машинное обучение не встроены настолько нативно, как у некоторых конкурентов. Планирование в SAP обычно выдает прогноз в виде одного числа и полагается на сценарных планировщиков для оценки неопределенности, а не выводит полное распределение вероятностей спроса (хотя оптимизация запасов учитывает изменчивость через расчеты уровня обслуживания или страховочного запаса). Что касается экономической оптимизации, инструменты SAP могут быть настроены для оптимизации определенных финансовых показателей (их оптимизация уценки максимизирует маржу, оптимизация запасов минимизирует затраты для достижения целевого уровня обслуживания и т.д.), но, как правило, это оптимизация, специфичная для модуля, а не сквозная максимизация прибыли для всей розничной операции. Планировщики, использующие SAP, все еще часто балансируют несколько задач вручную (например, уравновешивая доходы и запасы посредством собственных корректировок, а не благодаря автоматизации ИИ).

Одной из главных проблем набора решений SAP является масштабируемость против стоимости. SAP сильно опирается на свою базу данных HANA в оперативной памяти. Хотя это обеспечивает быструю обработку больших объемов данных (например, позволяет выполнять очень детальное прогнозирование по магазинам и SKU почти в режиме реального времени), это *«гарантирует высокие затраты на оборудование» ²² и может быть дорогостоящим при масштабировании. Известно, что SAP IBP работает лучше всего на HANA с значительным выделением памяти, что может быть избыточным (и завышенно оцененным) для некоторых задач. Это противоречит критерию экономической эффективности; подход SAP может работать в условиях корпоративного масштаба, но не без значительных расходов на инфраструктуру и лицензионного обеспечения.

Когда речь заходит о сложных факторах розничной торговли (каннибализация, замещение, порча и т.д.), у SAP имеются возможности, но они часто требуют значительной настройки и не являются «готовыми к использованию», как некоторые новые решения. Например, SAP может моделировать акции и даже некоторые эффекты каннибализации с помощью аналитики Customer Activity Repository (CAR) или посредством настройки перекрестной эластичности в инструменте ценообразования, но эти взаимосвязи не определяются автоматически – обычно они зависят от аналитиков, вводящих предположения, или от отдельных анализов вне основного цикла планирования. Аналогично, SAP F&R мог учитывать срок годности для скоропортящихся товаров и ограничивать заказы соответственно, но внедрение планирования для свежих продуктов в SAP исторически представляло сложность и иногда было менее продвинутым, чем специализированные инструменты (некоторые ритейлеры обращались к индивидуальным решениям для свежей продукции).

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

Наконец, технологическая интеграция является проблемной. Решение SAP по оптимизации розничной торговли действительно представляет собой «беспорядочную совокупность», возникшую в результате многочисленных приобретений поверх основного ERP ¹¹. Несмотря на усилия, такие как SAP IBP (предназначенный для объединения планирования цепочки поставок на одной платформе) и SAP CAR (предназначенный для объединения транзакционных данных и аналитики розничной торговли), реальность такова, что инструменты SAP для управления запасами, ценообразования и ассортимента не работают как единое целое. Достижение бесшовного потока требует значительной интеграционной работы (часто выполняемой опытными интеграторами SAP в рамках длительных проектов) ⁸⁴. Даже в этом случае пользователи могут столкнуться с множеством пользовательских интерфейсов и дублированием данных. Эта несогласованная архитектура — именно тот сценарий «Франкенштейна», которого следует опасаться, — когда решение технически способно на всё, но ощущается как несколько систем, скрепленных вместе, что приводит к высокой сложности и затратам на обслуживание.

Скептицизм оправдан при оценке заявлений SAP. Компания часто позиционирует IBP и свой розничный набор решений как «интегрированное сквозное решение», но эксперты отмечают, что «корпоративное программное обеспечение не так просто объединяется посредством слияний и поглощений» ¹¹ — что указывает на то, что интеграция SAP отстает от заявленной концепции. Кроме того, в маркетинге SAP встречаются такие модные термины, как «реальное время», «прогнозное» и «чувствительность спроса», однако многие пользователи считают, что извлечение реальной ценности из этих возможностей требует значительных усилий и настройки. В итоге, возможности SAP по оптимизации розничной торговли являются широкими, но не глубокими в некоторых современных областях, и надежными, но не элегантными. Они представляют собой скорее наследие корпоративного подхода: мощные по охвату и способные масштабироваться в больших масштабах, но громоздкие, дорогие и сложные – часто требующие значительных человеческих и IT-ресурсов для достижения результатов ⁸⁴.

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

Источники: Критика накопленной сложности продукта SAP и проблем интеграции ¹¹; высокоуровневое сравнение, что in-memory решения (например, SAP) жертвуют производительностью ради снижения стоимости оборудования ²².

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

Сводка рейтинга поставщиков:

Lokad – Отличается объединенной, вероятностной оптимизацией; высоко инновационный, с минимумом хайпа ²⁵ ³.
RELEX Solutions – Розничная платформа с глубоким применением машинного обучения и интегрированным планированием; продвинутое моделирование акций и каннибализации ⁹.
o9 Solutions – Прорывное интегрированное планирование «Цифровой мозг» с широким охватом, но следует проявлять осторожность по отношению к заявленному ИИ в сравнении с реальной реализацией ⁴.
ToolsGroup – Проверенный оптимизатор запасов, развивающийся в полноценный розничный пакет; хорошая автоматизация, хотя в настоящее время происходит интеграция новых поглощений ¹⁹ ⁵¹.
Blue Yonder – Всеобъемлющий розничный пакет, переосмысленный с применением ИИ; чрезвычайно функциональный, но всё ещё сохранивший черты устаревшей системы «под капотом» ⁷⁰.
SAP (IBP & Retail) – Мощный игрок с широким охватом; затруднен наследуемой сложностью и меньшей гибкостью, требующей масштабной интеграции ¹¹.

Каждый поставщик обладает своими сильными и слабыми сторонами, как было подробно описано выше. В итоге, такие компании, как Lokad и RELEX, делающие акцент на настоящей совместной оптимизации, вероятностных прогнозах и современном технологическом стеке с нуля ²⁵ ³, выделяются как готовые к будущему и соответствующие нашим критериям. Другие, в частности крупные устаревшие системы, были вынуждены внедрять современные технологии в старую архитектуру и могут показывать результаты, но не без отягощения старой архитектурой и иногда необоснованных маркетинговых заявлений ⁷⁰. Пользователи должны взвесить эти компромиссы, используя скептический, инженерно-ориентированный подход, чтобы выбрать решение, которое действительно удовлетворяет их потребности без искусственного блеска хайпа.