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

Last modified: February 2nd, 2025

Введение

Рынок программного обеспечения для оптимизации электронной коммерции полон смелых заявлений об использовании магии на базе ИИ, однако пристальный взгляд под капотом показывает, что лишь немногие поставщики действительно выполняют обещание по совместной оптимизации запасов, цен и ассортимента с использованием передовых технологий. В этом исследовании мы оцениваем ведущие решения для чистой электронной коммерции (онлайн-ритейлеры без физических магазинов) и ранжируем наиболее значимых поставщиков — в том числе Lokad, RELEX Solutions, Blue Yonder и ToolsGroup — исходя из их технических достоинств и недостатков. Lokad выступает лидером благодаря своему единому, вероятностному подходу и высокой степени автоматизации, в то время как RELEX и Blue Yonder предлагают комплексные системы, сбалансированные сложностью ИИ «черного ящика» и устаревшим багажом соответственно. ToolsGroup предлагает проверенную оптимизацию запасов, основанную на надежной математике, но сталкивается с проблемами интеграции по мере расширения в области ценообразования и ассортимента. На протяжении всего исследования мы применяем глубоко скептический подход: прорубая сквозь маркетинговые приукрашивания, проверяя заявления поставщиков с помощью независимых данных и подчеркивая часто не озвучиваемые оговорки (например, неспособность оптимизировать решения комплексно или зависимость от дорогостоящих архитектур). Цель исследования — нарративный технический анализ, ставящий правду выше шумихи, чтобы участники рынка электронной коммерции могли понять, кто действительно продвигает современные технологии, а кто отстает.

Критерии золотого стандарта: совместная оптимизация и передовые технологии

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

Помимо совместной оптимизации, действительно передовые решения должны использовать современные методы и архитектуры:

• Вероятностное прогнозирование: Вместо однозначных прогнозов спроса следует использовать распределения вероятностей, чтобы учесть неопределенность спроса. Это особенно важно для электронной коммерции, характеризующейся волатильными моделями спроса и «длинным хвостом» артикулов. Традиционные инструменты (например, старые модули SAP или Oracle), выдающие одно число и величину страховочного запаса, часто недооценивают реальную изменчивость ^{1 2}. Ведущие поставщики сейчас делают акцент на вероятностных или «стохастических» моделях, которые количественно определяют диапазон возможных результатов.
• Экономическая оптимизация: Решения должны приниматься с учетом экономических целей (прибыль, затраты, целевые уровни обслуживания), а не только эвристических правил. Например, действительно оптимизированная система учтет маржу прибыли и затраты на хранение товаров при определении уровней запасов и цен. Она будет отдавать приоритет действиям, которые максимизируют ожидаемую прибыль или минимизируют суммарные затраты, а не слепо добиваться заданного уровня заполнения. Это требует встроения параметров затрат/доходов в алгоритмы.
• Масштабируемость и экономичность: Данные электронной коммерции огромны (потенциально миллионы артикулов, ежедневные транзакции, множество каналов). Программное обеспечение должно обрабатывать данные в большом объеме без чрезмерных затрат на оборудование или медленной работы. Архитектуры, наивно хранящие все в оперативной памяти (RAM), могут стать неприемлемо дорогими при масштабировании. Современные разработки мудро используют облачные вычисления, например, распределенную обработку, дисковые хранилища данных и эффективные алгоритмы. Решение, требующее гигантского серверного парка или дорогостоящих платформ (например, чрезмерного использования облака данных Snowflake), может негативно сказаться на окупаемости инвестиций. Напротив, умное проектирование позволяет обрабатывать данные в терабайтах за считанные часы на стандартных облачных инстансах ^{3 4}.
• Эффекты каннибализации и замещения: При принятии решений по ассортименту и ценообразованию система должна учитывать влияние одних товаров на спрос других. Например, если два товара являются близкими заменителями, исключение одного из ассортимента приведет к перенаправлению спроса на другой (эффект каннибализации). Для этого требуются не только простейший OLAP-анализ или вручную определяемые группы товаров, а модели, которые изучают кросс-эластичность или коэффициенты привязки. Многие устаревшие инструменты предполагают, что спрос на каждый товар независим, что приводит к ошибкам как в прогнозировании, так и в планировании ассортимента. Современный поставщик должен явно моделировать подобные взаимосвязи (например, с использованием машинного обучения на основе данных транзакций для выявления товарных аффинитетов).
• Влияние рыночной площадки и конкуренции: Чисто электронные игроки часто зависят от динамики рыночных площадок — например, конкуренции на Amazon или eBay, продавцов третьих сторон и т.д. Программное обеспечение для оптимизации должно, по возможности, учитывать такие сигналы, как цены конкурентов или отсутствие товара на складе маркетплейсов. Немногие справляются с этим хорошо. Это сложная, но все более актуальная задача: например, если у конкурента заканчиваются запасы популярного товара, ваша система должна распознать возможность и скорректировать цену или рекламный бюджет. Аналогично, если вы продаете как напрямую, так и через маркетплейсы, система должна оптимизировать работу между каналами (избегая, например, чрезмерных запасов на собственном сайте, когда товар продается через Amazon FBA).
• Многоканальные и омниканальные возможности: Даже без физических магазинов, у продавца электронной коммерции может быть несколько онлайн-каналов (собственный сайт, маркетплейсы, возможно, региональные сайты). Оптимизационный движок должен целостно учитывать многоканальный спрос и запасы — признавая, например, что запасы являются общими или что решения по ценообразованию в одном канале могут влиять на другой. «Комплексное» планирование — это не просто модное выражение; оно означает, что программное обеспечение видит полную картину (от поставщиков до клиентов, через все каналы продаж).
• Высокая степень автоматизации («роботизация»): Основное обещание этих систем — автономное принятие решений. Теоретически они должны работать без присмотра, генерируя заказы на пополнение запасов, обновления цен и т.д., без необходимости ежедневного ручного вмешательства. На практике все поставщики все еще допускают настройку пользователем, однако мы отдаем предпочтение тем, которые минимизируют необходимость ручной подстройки. Будьте осторожны с решениями, которые хвастаются автоматизацией, но при этом предоставляют десятки настроек (параметры, коэффициенты весов, правила) — это внутреннее противоречие. Истинная автоматизация достигается, когда алгоритмы самостоятельно находят оптимальные настройки, а не когда пользователей просят постоянно калибровать систему. Лучшие системы используют модели самообучения, которые корректируются по мере поступления новых данных, так что со временем решения остаются оптимальными без вмешательства человека ⁵. Чем меньше настроек «водителя» требуется поддерживать пользователю, тем убедительнее автоматизация.
• Надежная, экономичная архитектура: Мы уже затронули вопрос экономичности, но стоит отметить, что некоторые современные решения используют облачные хранилища данных (например, Snowflake) для масштабирования. Это может избавить от проблем с инфраструктурой, но вводит модель затрат, основанную на использовании. Если инструмент планирования требует обработки огромных объемов данных на платформе типа Snowflake, затраты могут взлететь (аналогично прайсингу на основе MIPS от IBM в 1990-х, где увеличение использования CPU означало экспоненциальный рост сборов). Идеальное решение обрабатывает большие данные с помощью умных алгоритмов, чтобы использование облака (и, соответственно, затраты) оставалось разумным ⁴. Аналогично, решения, приобретенные через слияния, могут оказаться лоскутным одеялом из модулей на разных технологических платформах, что приводит к высоким затратам на интеграцию для заказчика (как в денежном выражении, так и в системной задержке). Преимущество облачных решений, интегрированных с самого начала, заключается в устранении избыточного перемещения данных без создания новых узких мест.

С установленными критериями мы переходим к анализу поставщиков. Мы ранжируем Lokad, RELEX, Blue Yonder и ToolsGroup как наиболее значимых игроков в оптимизации электронной коммерции и оцениваем каждого согласно приведенным выше параметрам. Анализ выполнен в нарративном стиле — с акцентом на то, как каждый поставщик решает проблему и где требуется скептицизм, — а не в виде перечня функций. Важно, что мы опираемся на достоверные данные (и прямые цитаты) по мере возможности, избегая распространенной ловушки принятия заявлений поставщиков за чистую монету.

1. Lokad – Единая количественная оптимизация с вероятностным фундаментом

Lokad выделяется как поставщик, который явно ориентирован на идею совместной оптимизации с использованием передовых технологий. В отличие от традиционного программного обеспечения для управления цепочками поставок, Lokad не представляет собой набор модулей (прогнозирования, MRP и т.д.), которые можно настраивать, а выступает как программная платформа, на которой для каждого клиента реализована единая логика оптимизации. Этот подход, который они называют «Quantitative Supply Chain», может требовать больше работы аналитиков на начальном этапе, но дает решение, нацеленное на оптимизацию всех решений одновременно — запасов, ценообразования, пополнения — все в одном. Философия Lokad заключается в том, что прогнозы являются лишь средством достижения цели, а истинная задача — оптимизировать решения (например, сколько закупать, какую цену устанавливать), с учетом всех ограничений и экономических компромиссов.

В основе лежит вероятностное прогнозирование. Lokad был одним из первых, кто применил полные распределения вероятностей для спроса и даже доказал свои возможности на нейтральной арене соревнований по прогнозированию. В престижном конкурсе M5 Forecasting Competition (2020) команда Lokad заняла 6-е место по всему миру из 909 команд ⁶ — впечатляющее подтверждение их технологии, учитывая, что M5 фокусировался на детальных данных розничной торговли (с которыми сталкиваются компании электронной коммерции). Примечательно, что M5 требовал вероятностных (квантильных) прогнозов, что соответствует сильной стороне Lokad. Этот результат демонстрирует не только академическую состоятельность, но и практическую значимость: их прогнозы были одними из лучших, что является основой для оптимизации запасов и ценообразования. Более того, генеральный директор компании подчеркнул, что после определенного момента дальнейшее повышение точности прогнозирования дает уменьшающуюся отдачу по сравнению с улучшением моделирования решений ⁷. Иными словами, Lokad делает акцент на оптимизации решений (заказных объемов, распределения и т.д.) с использованием вероятностных прогнозов, а не на погоне за незначительным улучшением точности, которое может не оказать существенного влияния на итоговые результаты. Такой подход освежает и важен для электронной коммерции: он признает, что управление такими аспектами, как дефицит запасов, прерывистый спрос и эффекты замещения, зачастую важнее, чем незначительное процентное улучшение в показателях прогнозирования ⁷.

С технологической точки зрения, Lokad является современным решением, ориентированным на инженерные достижения. Они разработали собственную облачную технологическую платформу (включая специализированный язык для написания оптимизационных скриптов под названием «Envision»). Эта платформа предназначена для эффективной и экономичной обработки больших объемов данных. Например, система Lokad регулярно обрабатывает от гигабайт до терабайт данных клиентов (заказы, клики и т.д.) за несколько часов в ночное время, чтобы сформировать решения на следующий день ^{8 3}. Для этого они избегают загрузки всех данных в оперативную память; вместо этого используются файлы с отображением в память и колонковое хранение на диске, что позволяет обрабатывать наборы данных, превышающие объем памяти машины, за счет использования быстрых SSD ^{3 9}. Они прямо отмечают, что Envision (их движок) поддерживает наборы данных, превышающие оперативную память даже целого кластера, посредством «умного сброса на NVMe-диски», и что параллельные операции автоматически распределяются между ядрами и машинами ³. Итог: Lokad может масштабироваться до чрезвычайно больших ассортиментов артикулов, не требуя от клиента инвестировать абсурдное количество оперативной памяти или специализированного оборудования. Фактически, они подчеркивают, что для работы требуется минимальное оборудование — что позволяет избежать ситуации, когда «нажатие кнопки запуска стоит сотни долларов» в виде облачных расходов ⁴. Это тонкий, но важный момент: он отличает их от некоторых тяжелых корпоративных систем, которые, хотя и способны обрабатывать большие данные, делают это за огромные затраты. Подход Lokad ближе к оптимизированному конвейеру для обработки больших данных, напоминающему Apache Spark или Google BigQuery, но созданному специально для расчетов в цепочке поставок. Такой акцент на эффективности позволяет решению оставаться экономичным по мере масштабирования — что является большим плюсом для eTailers с миллионами записей.

Обработка ценообразования и ассортимента в Lokad осуществляется не через отдельные модули, а посредством единой логики оптимизации. Поскольку платформа по сути основана на коде, можно смоделировать взаимодействия. Например, можно написать скрипт, который гласит: «для каждого продукта учитывайте вероятностный спрос при различных ценах, принимайте во внимание доступность запасов и время пополнения, а затем выбирайте цену, максимизирующую ожидаемую маржу за вычетом затрат на хранение, при условии, что дефицит встречается не слишком часто» — это упрощенное описание, но оно иллюстрирует, что решения по ценообразованию и запасам могут приниматься совместно. Если товар переизбыточен, код может предусмотреть скидку для ускорения продаж; если товара в дефиците, он может повысить цену для распределения запасов среди самых платежеспособных клиентов. Немногие другие поставщики позволяют добиться такого уровня взаимодействия. Решение Lokad, по сути, генерирует собственные политики принятия решений, адаптированные к данным продавца.

Эффекты каннибализации и замещения обрабатываются естественным образом, если подать правильные данные. Например, можно включить параметр «если товар A недоступен, сколько его спроса перейдет к товару B» — такие взаимосвязи могут быть выявлены на основе исторических данных (анализируя прошлые дефициты или изменения ассортимента) и затем использованы в оптимизации. Поскольку Envision является полноценным языком программирования, эти сложные динамики спроса можно зафиксировать в коде. Документация Lokad свидетельствует, что они активно этим занимаются: система «выявляет корреляции между товарами, каналами и временными периодами» и принимает решения соответственно, вместо того чтобы предполагать независимость каждого артикула ¹⁰. Она не полагается на простую экстраполяцию временных рядов; система рассчитывает полные распределения вероятностей для спроса, учитывая акции, дефициты, сезонные сдвиги и т.д. ¹¹. Улавливая эти факторы (включая ситуации, когда спрос был потерян из-за отсутствия товара), Lokad избегает классической проблемы «мусора во входных данных» при прогнозировании на основе предвзятых данных о продажах.

Еще одна область, в которой Lokad демонстрирует себя – это конкурентная разведка и интеграция внешних данных. Платформа может принимать любые релевантные данные – например, цены конкурентов, веб-трафик, даже календари маркетинговых кампаний – в качестве дополнительных входных сигналов. Они явно упоминают возможность включения «внешних сигналов, таких как ценообразование конкурентов» и маркетинговых календарей, а также легкость экспериментов с новыми алгоритмами или входными данными благодаря программной архитектуре ¹². Практически говоря, если у компании электронной коммерции, например, есть собранные данные о ценах конкурентов или она знает, что уровень запасов у партнера на маркетплейсе является индикатором, эти данные можно подключить к модели Lokad для уточнения решений. Это значительно гибче, чем большинство готовых решений, способных обрабатывать только внутренние данные. Это говорит о подходе «прозрачного ящика»: вместо скрытия логики, Lokad позволяет настроить её по своему усмотрению. Тем не менее, подход Lokad требует участия специалиста по цепочке поставок для настройки – это не интерфейс «укажи-и-нажимай» для новичков. Для некоторых это может быть недостатком; однако выгода заключается в решении, которое точно соответствует бизнесу и может действительно автоматизировать принятие решений с учётом уникальных правил компании.

Автоматизация и автономия: Можно утверждать, что Lokad является самым близким к «полностью роботизированному» планировщику цепочки поставок в этой группе. Философия заключается в том, что как только скрипты (логика) настроены и проверены, система может работать ежедневно (или внутри дня) и выдавать рекомендованные решения без вмешательства человека. Многие пользователи Lokad фактически доверяют системе генерацию заказов на закупку и предложений по ценообразованию, которые планировщики затем кратко проверяют или даже выполняют автоматически. Поскольку система самоадаптивна (она ежедневно дообучает прогнозы с последними данными и соответственно переоптимизирует), она не требует ручной настройки параметров. Фактически, Lokad достаточно резко критикует индустриальную привычку бесконечной настройки – они подчёркивают, что их система «не полагается на примитивные методы временных рядов» и работает без постоянной ручной “настройки” со стороны пользователей ¹⁰. Сложная задача корректировки сезонности, событий и нестабильного спроса выполняется алгоритмами, а не за счёт того, что планировщики подгоняют прогнозы. Один из ключевых моментов – это действуемость: Lokad выдаёт решения (или рекомендации, пригодные для реализации) вместо простых диагностических данных. Например, вместо того чтобы просто сигнализировать, что определённый товар может закончиться (как это делают некоторые дашборды «контрольной башни»), система прямо рекомендует количество заказа или изменение цены для устранения проблемы. Цель – «рекомендовать корректирующие действия, а не просто выдавать сигнал тревоги», что крайне важно для работы без присмотра ¹³. В условиях быстро меняющейся среды электронной коммерции система, которая просто сообщает о наличии проблемы, недостаточна – вы хотите, чтобы она подсказывала что с этим делать, а возможно, даже сама принимала меры. Lokad создан именно для этого.

Учитывая все похвалы, возникает вопрос: где стоит проявить скептицизм к Lokad? Главное предостережение заключается в том, что подход Lokad является крайне индивидуальным и техническим. Это не решение SaaS, которое можно просто включить и сразу увидеть красивый пользовательский интерфейс со всеми ответами. Оно требует от компании-пользователя определённого уровня зрелости данных и доверия к количественным методам. Кроме того, существует неявная зависимость от команды Lokad («специалистов по цепочке поставок»), особенно в процессе первоначальной настройки – по сути, они действуют как ваша расширенная команда для внедрения решения. Это отличается от модели, когда устанавливается хорошо определённое программное обеспечение. Если клиент не готов участвовать в таком совместном, технически насыщенном процессе, у него могут возникнуть трудности. Однако именно эта модель обеспечивает глубину оптимизации. Это классический компромисс: гибкость и мощь против простоты использования. Lokad явно оптимизирован для мощности и гибкости.

С точки зрения рынка, ценностное предложение Lokad кажется особенно соответствующим потребностям электронной коммерции. Компании электронной коммерции сталкиваются со множеством задач – нехваткой товара, избытком запасов, нестабильными всплесками спроса из-за акций или воздействия инфлюенсеров и т.д. – и часто прибегают к совокупности инструментов (BI-дашбордов, разовых скриптов на Python и т.д.) для устранения пробелов, оставленных их ERP или WMS. По сути, Lokad позиционирует себя как специализированный уровень, который принимает все эти сигналы и выдаёт почти оптимальный план. Они явно противопоставляют себя примитивным инструментам, предлагаемым маркетплейсами или ERP, отмечая, что те «обрабатывают лишь часть» проблем, с которыми сталкиваются компании электронной коммерции ^{14 15}. Например, маркетплейс Amazon может предоставить прогноз спроса на следующую неделю – но он не интегрирует затраты цепочки поставок или многоскладские запасы. Технология Lokad сконструирована так, чтобы обрабатывать каждый релевантный сигнал до уровня отдельного SKU, без сбоев и без того, чтобы пользователи вручную управляли электронными таблицами ¹⁶. Это сильное ценностное предложение, если оно реализовано согласно заявленному.

Подводя итог по Lokad: он занимает верхнюю позицию в нашем списке благодаря своей целостной способности к оптимизации и передовым технологиям. Он безоговорочно соответствует критерию совместной оптимизации – запасы, ценообразование и многое другое могут оптимизироваться вместе посредством его программной платформы. Он использует вероятностное прогнозирование и экономические драйверы (они делали квантильные прогнозы ещё до того, как это стало модным, что подтверждается их успехом на конкурсе M5 ⁶) и не избегает сложных эффектов, таких как замещение товаров или мультиканальные корреляции. Его архитектура масштабируема и ориентирована на экономию, избегая ловушки использования жёстких in-memory вычислений ^{3 4}. Уровень автоматизации очень высок, требуется минимальная ручная настройка, а акцент ставится на выработку решений, а не просто на предоставление аналитики ¹³. Скептицизм по отношению к Lokad может касаться не столько того, работает ли технология – все указывает на её работоспособность – сколько того, готова ли организация принять такое решение, основанное на глубокой науке о данных. Также остаётся вопрос об опыте работы на больших масштабах; Lokad меньше некоторых конкурентов, хотя у него есть заметные клиенты (например, дистрибьюторы промышленного обслуживания, модные интернет-магазины и т.д., согласно их кейс-стади). С учётом всего вышесказанного, Lokad заслуживает высшей оценки как по-настоящему передовой поставщик оптимизации для электронной коммерции в нашем исследовании.

2. RELEX Solutions – оптимизация розничной торговли на основе ИИ (с оговорками)

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

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

Приносят ли это результаты? Клиенты RELEX часто сообщают об улучшении точности прогнозов и сокращении случаев отсутствия товара, особенно в промоакционных и сезонных ситуациях, где традиционные методы испытывали трудности. Например, RELEX интегрирует прогнозы погоды и утверждал, что для некоторых товаров, чувствительных к погоде, ошибка прогнозирования снижалась до 75% в условиях необычной погоды ¹⁹. Мы воспринимаем такие конкретные заявления с долей скептицизма – они могут быть выбраны из лучших примеров. Тем не менее, подход RELEX, вероятно, действительно добавляет ценность в краткосрочное прогнозирование («чувствование спроса») за счёт корректировки прогнозов на основе самой последней информации. По сути, их модели машинного обучения постоянно донастраивают базовый прогноз с учётом новых сигналов данных. Это похоже на то, что некоторые называют «чувствованием спроса» (использование данных почти в реальном времени для обновления краткосрочных прогнозов). В своих материалах RELEX объединяет «чувствование спроса» с более широким ML-прогнозированием, а не рассматривает его как отдельный модуль. Они продвигают идею «непрерывного, автоматизированного пере-прогнозирования» по мере изменения ситуации.

Что касается совместной оптимизации, насколько хорошо RELEX охватывает вопросы ценообразования и ассортимента помимо управления запасами? Исторически RELEX был наиболее силен в области пополнения запасов и распределения (обеспечивая отсутствие дефицита в магазинах или распределительных центрах). Планирование ассортимента (решение, какие товары должны поставляться в какие магазины или какие SKU предлагать) также входило в их пакет, как и оптимизация планограмм (планирование торгового пространства). Оптимизация цен оставалась недоработанной до недавнего времени – но в 2022 году RELEX представил возможность оптимизации цен на основе ИИ ^{20 21}. Они позиционируют эту функцию как полностью интегрированную с их планированием акций. Например, их инструмент планирования акций и инструмент оптимизации цен используют одни и те же данные и интерфейс, так что ритейлер может спланировать акцию, а система порекомендует оптимальную глубину скидки, временные рамки и т.д., при этом автоматически учитываются последствия для управления запасами. Это, безусловно, движется в направлении совместной оптимизации. Однако неясно, действительно ли RELEX одновременно оптимизирует цену и запасы или делает это последовательно (сначала устанавливается цена, а затем корректируется поток запасов). В идеальной совместной оптимизации вы учитывали бы ограничения по запасам при установлении цены (например, не стоит агрессивно продвигать товар, если запасы ограничены). Интегрированная платформа RELEX, вероятно, позволяет реализовать такой кросс-функциональный подход – например, система может заметить: «У нас недостаточно запасов в распределительном центре, чтобы поддержать эту акцию во всех магазинах», и могла бы либо отметить, либо скорректировать это. Они упоминают необходимость согласования ценообразования и акций с цепочкой поставок, чтобы обеспечить выполнимость планов ²². Таким образом, RELEX осознаёт необходимость разрушения силосов.

Один из инсайдерских взглядов: привлекательность RELEX заключается в том, что он объединяет всё (спрос, предложение, операции) в одной платформе для пользователя. Например, мерчендайзеры могут видеть общие прогнозы и ограничения между отделами ²². Это означает, что планировщик может понять, какое влияние решение по ценообразованию окажет на цепочку поставок и наоборот. Такая видимость является значительным улучшением по сравнению с разрозненными инструментами. Но видимость – это не то же самое, что полноценная алгоритмическая оптимизация. Мы предполагаем, что, хотя RELEX предоставляет очень последовательный пользовательский опыт и модель данных, часть процесса принятия решений всё ещё может осуществляться поэтапно. Оптимизация цен может выдавать идеальную цену, а модуль управления запасами затем планировать вокруг неё. Тесная интеграция гарантирует отсутствие конфликтов, но это не обязательно решает единую задачу оптимизации, максимизирующую прибыль с учётом затрат на запасы одновременно. Достижение последнего является сложной задачей, и немногие вендоры (за исключением, возможно, Lokad, как обсуждалось) пытаются сделать это явно.

С точки зрения технологической архитектуры, RELEX довольно продвинут. Они создали собственный in-memory движок базы данных на ранних этапах (колоночная БД, оптимизированная для временных рядов и иерархических данных), что позволяло им быстро вычислять прогнозы для тысяч магазинов x SKU. Многие кейс-стади упоминают, что RELEX заменил электронные таблицы и устаревшие системы и сразу смог обрабатывать данные с куда большей детализацией (например, переход от недельного к ежедневному планированию или планирование, специфичное для каждого магазина, вместо универсального подхода). Для электронной коммерции это означает, что RELEX, вероятно, без проблем справится с прогнозами на уровне SKU для глобального онлайн-магазина. У них присутствуют облачные развертывания, и они могут масштабироваться. Мы не обнаружили конкретных нареканий на стоимость технологий RELEX; если уж на то пошло, они гордятся эффективностью вычислений (их академические основатели значительно оптимизировали алгоритмы). Одной из особенностей является концепция in-memory «Live database», которая, при неправильной настройке, может требовать большого объёма оперативной памяти – но это лишь предположение. В целом, масштабируемость RELEX не вызывает нареканий на рынке; они обслуживают огромные сети продуктовых магазинов с десятками тысяч SKU и множеством магазинов, что сопоставимо или превышает объёмы данных многих интернет-ритейлеров.

Автоматизация и роль планировщиков: RELEX часто говорит об «автономном планировании», а также об «усиленных решениях». Они не позиционируют свой инструмент как чёрный ящик, который заменяет планировщика. На самом деле, они делают упор на удобство использования – например, их пользовательский интерфейс, настраиваемые панели и управление исключениями. Система будет автоматически генерировать заказы на покупку или рекомендации по перемещению, но обычно планировщик просматривает и утверждает их (особенно на ранних стадиях внедрения). В RELEX существует концепция «исключений прогноза», при которой, если прогноз ИИ сильно отклоняется из-за какой-либо аномалии, система это отмечает. Также у них имеется функция моделирования, позволяющая планировщикам увидеть почему система предлагает то или иное (по крайней мере, в общих чертах, например: «потому что погода была жаркой, мы прогнозируем увеличение на +50%»). Микко Kärkkäinen заявил: «лучшие решения в своём классе используют прагматичный ИИ и вычислительную мощность для оптимизации задач… автономно, без участия человека» ²³, а также описал «автономное розничное планирование, которое самообучается и самооптимизируется, разрушая барьеры» ⁵. Таким образом, по крайней мере в видении, RELEX стремится к в значительной степени автономной системе. Мы остаёмся несколько скептичными по поводу полной автономии: крупные ритейлеры, использующие RELEX, всё ещё имеют команды планирования. Однако эти команды, вероятно, теперь управляют по исключениям, что является формой частичной автономии.

Одно из противоречий, на которое стоит обратить внимание в случае с RELEX (и похожими поставщиками) — обещание как крайней гибкости, так и крайней автоматизации. Они утверждают, что система очень гибкая (например, можно настроить, как работают правила ценообразования или скорректировать модели прогнозирования), и при этом заявляют, что она самостоятельно настраивается. Налицо противоречие: если пользователь может много чего переопределить вручную, система на практике может зависеть от этих ручных настроек. Если действительно доверять ИИ, тогда необходимости в ручном переопределении должно уменьшаться. Ссылка RELEX на «самонастройка» подразумевает последнее — что со временем системе потребуется меньше ручной корректировки параметров ⁵. Мы действительно видели упоминание о том, что подход RELEX превращает планировщиков скорее в супервайзеров. Например, в одной статье отмечалось, что система RELEX освобождает планировщиков от рутинных задач, позволяя им сосредоточиться на стратегических шагах ²⁴. Тем не менее, источник из агрегированных отзывов SelectHub сообщил, что некоторым пользователям части RELEX казались «неуклюжими», и возникали проблемы, такие как прогнозирование некоторых ограничений (например, предельные значения грузоперевозок), требующих обходных решений ²⁵. Это свидетельствует о том, что всё не так волшебно; пользователи всё ещё сталкиваются с моментами, когда им приходится вмешиваться или когда инструмент работает не так гладко.

Известные проблемы или опасения: Публично не задокументировано случаев «неудач» RELEX, как это бывает у некоторых (нет заголовков судебных исков). Компания в целом имеет положительные отзывы. Однако анонимные обсуждения инсайдеров иногда упоминают, что внедрение RELEX в очень крупных, сложных средах может выявлять проблемы. Например, интеграция данных может представлять собой серьёзную проблему (если исходные данные плохие, RELEX может выдавать некачественные планы, и ответственность сваливается либо на инструмент, либо на данные). Кроме того, агрессивный рост RELEX (они быстро привлекли множество клиентов) означает, что некоторые заказчики могут не получить такого же уровня поддержки, как, скажем, у Lokad. Это не критика самого программного обеспечения, а критика реальных результатов: сколько проектов RELEX действительно достигают обещанных ключевых показателей эффективности? Поставщики любят ссылаться на лучшие примеры улучшений («снижение запасов на X% у клиента Y!»), но редко упоминают случаи, когда показатели так и не были достигнуты. Мы подозреваем, что у RELEX, как и у всех поставщиков, были некоторые проекты, не оправдавшие ожиданий, возможно, из-за неэффективного управления изменениями или из-за того, что розничный продавец недостаточно доверял системе, чтобы действовать по её рекомендациям. На партнёрском саммите даже Blue Yonder признали, что неэффективное управление изменениями и проблемы с данными являются причиной большинства неудач проектов ²⁶ — то же, вероятно, относится к внедрениям RELEX.

Ещё один отмеченный аспект: RELEX, как правило, включает много внешних данных, включая такие источники, как Google Trends, данные о местоположении с мобильных устройств для прогнозирования посещаемости и т.д. Для игрока в сфере электронной коммерции некоторые из этих данных (например, посещаемость) не имеют значения, но другие (погода, тренды) важны. Следует задаться вопросом: действительно ли мне нужны все эти потоки данных? Для некоторых электронных бизнесов простые модели, основанные на истории продаж, могут быть почти такими же эффективными. RELEX, безусловно, продвигает идею о том, что больше данных обеспечивает лучшие прогнозы. Результаты соревнования M5 (в котором, насколько нам известно, RELEX не участвовал публично) показали, что сложные модели действительно превосходят простые, но зачастую с незначительным перевесом. Лучшие методы часто представляли собой ансамбли из множества моделей, не сильно отличающиеся от того, что RELEX, возможно, использует внутри. Но, что интересно, чистый подход машинного обучения не однозначно превосходил традиционные методы в этих конкурсах — комбинация статистических моделей, тщательно настроенных, как правило, приходила победителем. Таким образом, если сопоставить утверждения RELEX с такими эталонами, как M5, мы видим, что вероятностное прогнозирование действительно ценно (как они и утверждают), но также обнаруживаем, что нет единого волшебного рецепта среди лучших методов — всё сводится к тщательному моделированию. В отсутствие публикации RELEX своих показателей точности на таких стандартных наборах данных мы остаёмся настороже. Совет скептиков для всех, кто рассматривает использование RELEX, звучит так: требуйте конкретных доказательств улучшений и определите чёткий базовый уровень. Например, если RELEX заявляет «мы улучшили точность прогнозирования на 30%», уточните: «на 30% относительно какого показателя и исходного уровня?» Часто поставщики измеряют улучшения по сравнению со сценарием, благоприятствующим их инструменту (например, по сравнению с наивными прогнозами или с плохим годом). Рекомендация данного исследования: требуйте ясности в определении базовых уровней для любых заявлений о производительности.

В резюме, RELEX Solutions занимает место одного из ведущих поставщиков, потому что интегрированно охватывает ключевые области (спрос, запасы, ценообразование) и широко использует современные методы ИИ/МЛ. Его сильные стороны включают очень детальное прогнозирование, учитывающее множество факторов, возможности для активного продвижения и сезонного планирования, а также единую платформу, предоставляющую всем заинтересованным лицам единый источник правды. Он соответствует требованиям по масштабируемости (проверено в крупных розничных сетях), по управлению каннибализацией (с помощью продвинутых моделей прогнозирования, учитывающих перекрёстное влияние между продуктами ²⁷), по рынку/омниканальности (система может одновременно планировать для онлайн и офлайн, и, вероятно, принимать данные конкурентов при их наличии). RELEX также стремится к автоматизации, заявляя о моделях с самонастройкой и автономных решениях, хотя на практике остаётся определённый контроль со стороны пользователей. Основные оговорки касаются сложности и непрозрачности, присущих его подходу, основанному на ИИ – пользователям приходится в некоторой степени доверять «чёрному ящику» – а также необходимости отделять хайп от реальности в маркетинге. Мы оцениваем RELEX высоко, но с оговоркой: это мощный инструмент, который требует тщательного внедрения и культуры, основанной на данных, чтобы быть полностью использованным. Мы также рекомендуем потенциальным пользователям остерегаться «AI washing» в индустрии; сообщения RELEX считаются одними из наиболее достоверных (так как у них действительно есть настоящая технология), но даже заявления Микко о «сотнях факторов» ¹⁷ следует рассматривать скорее как энтузиазм по поводу ИИ, а не как гарантию существенно лучших результатов по сравнению с конкурентами. В контексте электронной коммерции RELEX, безусловно, справится с задачей, только убедитесь, что вы тщательно измеряете его результаты и следите за тем, используются ли все эти шикарные функции на практике или просто без дела лежат в программном обеспечении.

3. Blue Yonder – Легендарный гигант, трансформирующийся (заявления против реальности)

Blue Yonder (ранее известная как JDA Software) является гигантом в области программного обеспечения для цепочек поставок, с десятилетиями опыта в системах планирования для розничной торговли и производства. У компании есть комплексное решение, которое охватывает прогнозирование, пополнение запасов, управление складами, транспортировку, управление персоналом и ценообразование (после приобретения специалиста по ценообразованию Revionics в 2020 году). Для игроков в сфере электронной коммерции Blue Yonder предлагает решения, изначально созданные для крупных ритейлеров и компаний сектора потребительских товаров – можно считать их корпоративным гигантом в этой области. Однако с этим наследием связаны как сильные стороны (надежная функциональность, масштабируемость, опыт в отрасли), так и значительные слабости (устаревшие технологии в некоторых частях, проблемы интеграции из-за многочисленных приобретений и послужной список, включающий некоторые громкие неудачи).

С точки зрения совместной оптимизации, история Blue Yonder несколько противоречива. У них действительно есть компоненты для всех элементов: например, их Luminate Demand Edge для прогнозирования, Luminate Allocation/Replenishment для управления запасами и Revionics для ценообразования. На бумаге можно использовать все три компонента для достижения скоординированной стратегии – например, прогнозирование поступает и в план управления запасами, и в модели оптимизации цен, а оптимизация цен может учитывать эластичность спроса (что по сути является прогнозированием спроса при разных ценовых уровнях). Blue Yonder, безусловно, продвигает идею от начала до конца, “от планирования до исполнения” под своей платформой Luminate. Однако на практике многие из этих модулей развивались отдельно и были объединены только недавно. Например, оптимизационный движок цен Revionics имеет свою историю и был интегрирован после приобретения. Задача Blue Yonder заключается в том, чтобы сделать это единым, связанным решением. Компания признала, что в прошлом у них была фрагментированная система; в результате в 2023 году они объявили о крупной архитектурной трансформации: переход на “единую модель данных и платформу приложений” в облаке Snowflake ²⁸. Это большое событие – по сути, переформатирование их продуктов, чтобы все они читали/записывали данные в одно большое облачное хранилище (Snowflake), благодаря чему исчезнут разрозненные данные. Генеральный директор объявил видение “операционной системы цепочки поставок для мира”, где все приложения Blue Yonder обмениваются данными свободно ²⁸.

Мы рассматриваем это видение как одновременно обещающее и проблематичное. Обещающее, потому что, если его достигнуть, оно действительно решило бы множество проблем с интеграцией (например, больше не пришлось бы использовать пакетные интерфейсы между планированием спроса и ценообразованием – они буквально смотрели бы на одни и те же данные в Snowflake). Проблематичное, потому что это чрезвычайно амбициозно и рискованно. Даже консалтинговая фирма-партнёр Blue Yonder отметила, “Хотя и видение, мы считаем, что полное устранение интеграций может быть чрезмерно оптимистичным для большинства клиентов.” ²⁹. У клиентов данные расположены во многих местах, не всё они будут аккуратно размещаться в Snowflake, поэтому кастомная интеграция всё равно понадобится для систем, не принадлежащих Blue Yonder ²⁹. Короче говоря, стратегия Blue Yonder является работой в процессе — ответом на восприятие их как «наследия». Они явно заявили, что не станут навязывать «кризисные события» (немедленный отказ от старых технологий), а постепенно будут переводить устаревшие модули в микросервисную архитектуру, позволяя клиентам мигрировать в своём темпе ^{30 31}. Это означает, что в данный момент клиент Blue Yonder всё ещё может использовать, скажем, старое локальное решение для планирования спроса JDA с интеграцией в облако Revionics. Полностью единая платформа может стать доступной через пару лет. Пока же, совместная оптимизация у Blue Yonder более ручная: вы можете использовать их инструменты параллельно, но часто это зависит от пользователя для координации (например, чтобы действия команды по ценообразованию вливались в план управления запасами).

Blue Yonder действительно отмечает многие технологические достижения на бумаге: теперь они интегрируют машинное обучение в прогнозирование (используя технологии от компании Blue Yonder GmbH, которую они приобрели в 2018 году и которая специализировалась на ИИ для розничной торговли). Они заявляют, что используют “интерпретируемый ИИ, машинное обучение и даже генеративный ИИ” в различных приложениях ³². У них, безусловно, имеются передовые алгоритмы для оптимизации пополнения запасов, распределения и т.д., разработанные на протяжении десятилетий. Но следует быть скептичными, поскольку у Blue Yonder также много технического долга. Многие из их ключевых алгоритмов были разработаны в 90‑х или в начале 2000‑х компаниями i2 Technologies или JDA. Их совершенствовали, да, но до недавней переписи на облачную архитектуру большая часть работала на старых системах (некоторые решения требовали баз данных Oracle и т.д.). Поэтому, когда Blue Yonder продвигает “когнитивное, основанное на МЛ планирование”, стоит задаться вопросом: действительно ли это новая технология или просто новый брендинг? Например, их планирование спроса теперь может использовать МЛ для оценки повышения прогноза для праздничных дней, что хорошо, но действительно ли базовая архитектура использует вычислительные мощности современного облака или же она ограничена рамками устаревшей системы?

Один конкретный исторический момент: Blue Yonder (JDA) приобрела i2 Technologies в 2010 году. i2 была известна решениями, ориентированными на оптимизацию, но также была известна неудачными внедрениями. Известно, что после того как JDA купила i2, Dillard’s (крупный универмаг) выиграл судебный процесс на сумму $246M по обвинению в том, что программное обеспечение i2 не выполнило обещанного ^{33 34}. Это стало огромным позором – по сути, программное обеспечение и проект провалились настолько, что убытки клиента превысили более чем в 30 раз стоимость программного обеспечения. Эта сага, хоть и произошла 15 лет назад, подчеркивает, что даже высокорейтинговые поставщики могут допустить серьезные промахи, если технология переоценивается или внедрена некорректно. Blue Yonder пришлось понести эти расходы и извлечь уроки (надеемся). Это подчёркивает, почему мы сохраняем скептицизм: крупные поставщики могут хвастаться «продуктами мирового класса», но существуют доказательства того, что они не работают так, как рекламируется в некоторых случаях. У каждого поставщика бывают неудачи; у Blue Yonder, по крайней мере, был один случай, доведённый до публичных судов.

Надо отдать должное Blue Yonder – они стали более открыто говорить о решении проблем. На их партнёрском саммите 2023 года они откровенно обсудили «красные проекты» (проблемные внедрения) и обнаружили, что основными причинами были не сами алгоритмы, а “неэффективное управление изменениями и проблемы с миграцией/интеграцией данных” ²⁶. Они отметили, что правильная работа с данными и поддержка клиента при адаптации процессов имеют решающее значение. Такой самоанализ полезен – это означает, что Blue Yonder понимает, почему проваливаются проекты. Это также соответствует общей теме нашего анализа: часто дело не в том, что математика неверна, а в том, что интеграция в реальном мире даётся с трудом. То, что Blue Yonder акцентирует внимание на проблемах интеграции данных, говорит о сложности их системы. Ведь если бы их модули были действительно безупречно интегрированы, миграция данных не была бы такой головной болью. Тот факт, что это происходит, подразумевает, что клиентам, возможно, приходилось проводить значительную сверку данных для использования полного комплекса. Единый уровень данных Snowflake призван решить эту проблему, но, как уже было сказано, пока рано.

Давайте рассмотрим современные возможности Blue Yonder для сценария электронной коммерции:

• Прогнозирование спроса: Blue Yonder Luminate Demand (особенно с Demand Edge) использует машинное обучение для учета множества факторов (погода, события, цены). Они также перешли к вероятностным прогнозам; по крайней мере, они поддерживают использование доверительных интервалов или квантилей в планировании. Пример из их блога: они не используют ИИ просто для наложения факторов на базовый уровень, а для ежедневного полного перестроения прогноза с использованием последних данных, автоматически учитывая такие нюансы, как сдвиги в календаре, и самокорректируясь по мере поступления новых фактических данных ^{35 36}. Они утверждают, что это устраняет необходимость для планировщиков вручную вносить коррективы или устанавливать профили сезонности – модель сама их изучает и адаптируется ³⁶. Это полностью соответствует передовой практике прогнозирования. Подход Blue Yonder здесь теоретически обоснован: непрерывное обучение, признание неопределенности (они говорят об риске пере-/недопрогнозирования и компромиссах в затратах ³⁷), и использование МО для выявления сложных взаимосвязей (например, как различные погодные условия или акции влияют на спрос, без того чтобы человек явно задавал эти взаимосвязи).
• Управление запасами и пополнение: Это всегда было сильной стороной JDA/Blue Yonder. Они предлагают многоуровневую оптимизацию запасов (MEIO), что означает, что они могут оптимизировать уровни запасов в распределительных центрах и центрах исполнения заказов для электронной коммерции, учитывая сроки поставки, изменчивость спроса и т.д., чтобы достичь целевых уровней обслуживания. Инструменты Blue Yonder могут генерировать рекомендуемые количества заказов, уровни страхового запаса и тому подобное. Исторически эти алгоритмы основывались на правилах/эвристиках или использовали линейное программирование для решения конкретных задач. Сейчас их, вероятно, дополняют предсказания на основе машинного обучения, но основная оптимизация, вероятно, представляет собой смесь исследований операций и моделирования. BY, безусловно, способен справляться с крупномасштабным планированием SKU; многие ритейлеры из списка Fortune 500 использовали JDA для пополнения запасов в магазинах, что сопоставимо по масштабу с большим электронным складом, обслуживающим клиентов.
• Ассортимент: У Blue Yonder есть инструменты управления категориями, которые помогают определять ассортимент (какой ассортимент товаров и в каких магазинах). Для игрока, работающего исключительно в сфере электронной коммерции, планирование ассортимента может означать решение о том, какие новые продукты добавить или убрать. Инструменты BY могут использовать атрибуты и данные о производительности для оценки изменений ассортимента. Однако это, как правило, периодический стратегический процесс, а не непрерывный.
• Оптимизация цен: В результате приобретения Revionics Blue Yonder получила мощный механизм оптимизации цен, который широко используется в розничной торговле (особенно в продуктовых и универсальных магазинах) для установления базовых цен, акционных скидок и ценовых снижений. Revionics использует ИИ для моделирования эластичности цен и даже влияния цен конкурентов, после чего рекомендует изменения цен, позволяющие достигать таких целей, как рост маржи или доходов, с учетом правил ценообразования (например, окончание цены на .99 и т.д.). Теперь, в составе Blue Yonder, Revionics известен как Luminate Pricing. Теоретически этот механизм, в сочетании с прогнозами спроса от Blue Yonder, замыкает цикл – можно смоделировать, как изменение цены повлияет на спрос и запасы, и выбрать оптимальную цену. Blue Yonder продвигает это как «автономное ценообразование на базе ИИ», способное работать так часто, как это необходимо (даже в течение дня для электронной коммерции, если потребуется).

Остается большой вопрос: Насколько хорошо эти компоненты действительно работают вместе сегодня? Blue Yonder утверждает, что они работают. Например, они могут заявить, что их ценовое решение может принимать прогнозы из их решения по прогнозированию спроса и выдавать цены, которые затем используются решением для управления запасами для планирования заказов. Но если эти интеграции не работают в режиме реального времени или требуют дополнительной ИТ-работы, цикл может оказаться не таким плотным, как хотелось бы. Реалистично, пользователь Blue Yonder в 2023 году, занимающийся электронной коммерцией, может использовать ценовой инструмент отдельно от инструмента для управления поставками, возможно, с еженедельными пакетными обновлениями эластичности прогноза. Это совместное планирование, но не священный грааль мгновенной совместной оптимизации.

Что касается утверждений об ИИ/МО, Blue Yonder иногда страдает от избыточного использования модных терминов в маркетинге. Они применяют такие выражения, как «когнитивный», «основанный на машинном обучении» и тому подобное. Стоит проверить, есть ли в этом реальная суть. Действительно, есть некоторые доказательства: например, Blue Yonder (изначально немецкое подразделение) разработала алгоритмы, о которых публиковались статьи (их команда выиграла один из ранних конкурсов по розничному прогнозированию в 2014 году, используя нейронные сети). Кроме того, портфель патентов Blue Yonder велик (свыше 400 патентов), что свидетельствует о большом объёме НИОКР ³⁸. Однако количество патентов не равняется качеству продукта – это лишь показывает, что они опробовали множество техник. Скептическая перспектива заключается в том, чтобы спросить у Blue Yonder конкретные результаты: например, участвовали ли они в M5 или каком-либо нейтральном тестировании? Публично – нет. Существуют ли кейс-стадии с конкретными цифрами «до/после»? Некоторые есть, но зачастую кейс-стадии поставщиков выглядят приукрашенно и лишены ясного базового уровня. Blue Yonder действительно говорит что-то вроде «X ритейлер показал рост прибыли на Y% с использованием нашего ценообразования» – но без контекста это выглядит как маркетинг.

Также необходимо учитывать стоимость и сложность с Blue Yonder. Это крупные корпоративные системы. Внедрение может занять месяцы или годы и включает не только настройку программного обеспечения, но и переработку бизнес-процессов. Blue Yonder обычно требует либо своих профессиональных услуг, либо привлечения партнерской компании для реализации. Общая стоимость владения может быть очень высокой (лицензия + услуги + ИТ). Для игрока, работающего исключительно в электронной коммерции, особенно среднего размера, Blue Yonder может оказаться избыточной или слишком медленной в реализации по сравнению с более гибкими SaaS-решениями. Даже крупные компании иногда сомневаются: показательным событием в отрасли была отмена SAP-проекта стоимостью 500 млн евро компанией Lidl (крупным глобальным ритейлером) в 2018 году после того, как проект не оправдал ожиданий ³⁹. Это был SAP, а не Blue Yonder, но это иллюстрирует, что огромные проекты могут провалиться, съев огромные бюджеты. Проекты Blue Yonder аналогично сложны; действительно, их партнер JBF Consulting отметил, что конкурент Manhattan Associates выбрал иной подход (требующий повторной реализации для их новой платформы), в то время как BY пытается осуществить более плавную миграцию ⁴⁰. Факт того, что Manhattan выбрал путь «повторной реализации для перехода на новые технологии», указывает на то, что такие переходы не являются тривиальными. Blue Yonder пытается избежать кошмарных обновлений за счёт постепенной эволюции – но это также означает, что клиенты могут сейчас использовать не вполне современную технологию, ожидая новинок.

С точки зрения автоматизации, Blue Yonder сегодня, вероятно, менее автоматизирован, чем то, к чему стремятся Lokad или RELEX. Многие клиенты BY используют инструменты для генерации рекомендаций, которые затем планировщики утверждают или корректируют. Blue Yonder продвигает концепцию «автономной цепочки поставок» (особенно после приобретения Panasonic в 2021 году, когда они начали говорить о подключении данных IoT к автоматизированным решениям) ⁴¹. Но можно с уверенностью сказать, что значительная часть их клиентской базы всё еще находится в гибридном режиме: системой доверяют при принятии некоторых решений, а остальные вмешиваются вручную. Например, типичная ситуация — система предлагает заказы, но планировщик рассматривает исключения (точно так же, как с RELEX). Или ценовая система предлагает изменения цен, но менеджер по мерчандайзингу их пересматривает, возможно, отклоняя те, что не соответствуют стратегии бренда. Программное обеспечение может многое делать, но у компаний сложившиеся процессы, которые не меняются за одну ночь.

Конкурентная разведка и торговые площадки: Ценовое решение Blue Yonder (Revionics) действительно интегрирует данные о ценах конкурентов – в нем есть функция конкурентного реагирования, которая может принимать цены конкурентов для корректировки ваших собственных ⁴². Таким образом, для электронной коммерции, если у вас есть поток данных о ценах конкурентов, Revionics может включить их в свою оптимизацию (например, не устанавливать цену выше цены конкурента более чем на X%, чтобы сохранить ценовой имидж, или соответствовать самой низкой цене, если необходимо). Это является плюсом в совместной оптимизации цен. На торговых площадках Blue Yonder конкретно не имеет модуля управления площадками, как это делают некоторые поставщики, специализирующиеся на электронной коммерции (например, инструменты типа channel advisor для Amazon). Поэтому можно использовать Blue Yonder для основного планирования, а для управления тактиками, специфичными для торговых площадок (реклама, buy-box и т.д.), потребуется отдельный инструмент. Это выходит за рамки возможностей Blue Yonder и не является их недостатком, а скорее указывает на то, что электронная коммерция имеет аспекты, которые эти традиционные поставщики не охватывают (и Lokad, и RELEX также не включают ставки за рекламу, если быть объективными).

Учитывая масштаб и наследие Blue Yonder, следует также тщательно анализировать внутренние противоречия в их сообщениях. Например, Blue Yonder может рекламировать «персонализацию и ценообразование в режиме реального времени» на своей коммерческой платформе, в то время как их решения для планирования исторически работали пакетными режимами (ночное планирование, еженедельные перепланирования и т.д.). Они движутся в сторону более активного использования данных в режиме реального времени (их партнерство со Snowflake отчасти направлено на обеспечение почти реального времени обмена данными). Но если поставщик утверждает «динамическое ценообразование и оптимизацию запасов в режиме реального времени», спросите: означает ли это, что система пересчитывает данные непрерывно или просто способна быстро реагировать при срабатывании? И действительно ли вам нужно реальное время для принятия решений по ассортименту? Скорее всего, нет – это более стратегический вопрос. Таким образом, критически настроенный взгляд заметит, когда маркетинговый язык становится несвязным. Широкий маркетинг Blue Yonder порой попадает в ловушку обещания всего (от долгосрочной стратегии до мгновенного исполнения).

Опасения по поводу стоимости Snowflake: Следует подчеркнуть тонкий, но важный момент: построение Blue Yonder на платформе Snowflake может изменить модель затрат для клиентов. Вместо традиционных лицензий клиенты могут оказаться вынуждены платить за использование облака (кредиты Snowflake) на основе объёма данных и частоты запросов. Если приложения Blue Yonder выполняют интенсивные вычисления в Snowflake, счёт клиента может резко возрасти. Это аналогично старой системе тарификации IBM мейнфреймов по MIPS — вы платите больше, чем больше используете систему, что может отговорить от полноценного использования. Blue Yonder и Snowflake, вероятно, согласуют определённое ценообразование, но пользователю следует остерегаться «шока от счета», если сценарии планирования запускаются очень часто на больших объёмах данных. Это вполне реальное соображение, поскольку планирование цепочки поставок может быть вычислительно затратным (особенно при проведении симуляций сценариев или вероятностных расчётов). Неэффективный процесс в Snowflake может израсходовать большое количество кредитов. Blue Yonder, вероятно, учла это (им необходимо, чтобы всё работало коммерчески), но это стоит иметь в виду. Модель затрат, не согласованная с бизнес-ценностью (например, оплата за обработанные данные, а не за результат), напоминает ловушки прошлых эпох.

В заключение, Blue Yonder занимает место чуть ниже чисто специализированных новых решений с точки зрения реализации видения «следующего поколения». Он безусловно обладает богатым функционалом и имеет множество успешных внедрений, но с технически скептической точки зрения, мы видим компанию в процессе трансформации. Они пытаются модернизироваться, и в этом процессе много говорят об ИИ, интеграции и автоматизации. Однако, пока эта трансформация не будет полностью осуществлена, клиентам следует осторожно относиться к разрывам между модулями и реальным объёму усилий, необходимых для достижения обещанных результатов. Набор инструментов Blue Yonder, безусловно, может поддерживать операции в электронной коммерции (многие крупные ритейлеры с омниканальным бизнесом также используют BY для своей e-com части), и его охват не имеет равных (ни у одного из других поставщиков нет столь широкого спектра, включая такие подразделы, как логистика). Однако, если фирме, работающей в электронной коммерции, необходима только оптимизация спроса и поставок, Blue Yonder может оказаться слишком тяжеловесным выбором, если только им явно не нужна эта корпоративная надежность или они уже используют его в других областях. Наше скептическое исследование считает заявления Blue Yonder о передовых технологиях несколько сомнительными до тех пор, пока не будут доказаны – технология имеет опыт, но бремя доказательства лежит на них, чтобы показать, что десятилетиями существующее ПО действительно стало «ориентированным на ИИ» и интегрированным. На данный момент мы рекомендуем рассматривать Blue Yonder как мощный, но громоздкий вариант, который выбирают, если вам нужно очень обширное решение и есть ресурсы для его внедрения, и, возможно, не в качестве первого выбора, если на первом месте стоят гибкость и быстрый ROI.

4. ToolsGroup – пионер оптимизации запасов, расширяющийся до полного розничного решения

ToolsGroup – ветеран в области планирования цепочки поставок, известный особенно своей экспертизой в прогнозировании спроса и оптимизации запасов. Его флагманское решение, исторически называлось SO99+ (Service Optimizer 99+), широко использовалось для планирования запасов с учетом уровня обслуживания и многоуровневой оптимизации. Проще говоря, ToolsGroup отлично помогал компаниям определить «какой минимальный запас мне нужен в каждой точке для достижения уровня обслуживания X?» в условиях неопределенности – критическая задача как для распределения, так и для электронной коммерции. ToolsGroup был одним из первых, кто коммерчески внедрил вероятностное прогнозирование и долго выступал за отказ от детерминированных прогнозов в пользу использования полного распределения спроса ^{43 2}. Этот подход полностью соответствует тому, что мы сегодня считаем передовыми технологиями (а также был принят и другими поставщиками).

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

Хотя ToolsGroup исторически был сосредоточен на прогнозировании спроса и управлении запасами, в последние годы он осознал, что ценообразование, акции и ассортимент – это дополнительные составляющие, которые он ранее не предлагал. Для решения этой задачи ToolsGroup приобрёл компанию под названием JustEnough в 2018/2019 годах (JustEnough позже стала частью Mi9 Retail, а затем была продана ToolsGroup). Программное обеспечение JustEnough охватывало функции финансового планирования мерчендайзинга, планирования ассортимента, распределения и оптимизации скидок – по сути, функции розничного мерчендайзинга, включая ценовые скидки. С этим приобретением ToolsGroup расширил своё присутствие с чисто цепочки поставок до того, что можно назвать розничным планированием. Теперь они продвигают интегрированное решение, способное выполнять всё – от стратегического планирования до исполнения, объединяя возможности SO99+ и JustEnough.

Однако интеграция этих продуктов вызывает значительный скептицизм. Объединение двух разных программных платформ не является простой задачей. ToolsGroup работала над интеграцией моделей данных (они упоминают, что «используют одну и ту же модель данных для тактического и операционного планирования», чтобы обеспечить единое представление о реальности ⁴⁴). Они даже запустили нечто, называемое «Розничная торговля в режиме реального времени», которое соединяет систему планирования JustEnough с Inventory Hub для получения данных почти в режиме реального времени ^{45 46}. Идея заключается в том, что по мере совершения продаж (или перемещения запасов) эти события мгновенно поступают в систему планирования, позволяя на лету корректировать распределение или пополнение. Это свидетельствует о том, что ToolsGroup стремится внедрить более динамичное, непрерывное планирование, а не фиксированные периодические циклы — цель, схожая с подходом других современных поставщиков.

Но давайте разберём это: когда ToolsGroup называет своё решение «Розничная торговля в режиме реального времени, единственное решение, которое реагирует на поведение покупателей в моменте» ⁴⁵, это смелое заявление. Это фактически подразумевает, что они могут скорректировать план сразу же при изменении ситуации. Возможно, система может автоматически инициировать перемещение запасов или ускорить выполнение заказа, если сегодня неожиданно наблюдается всплеск продаж. Если это действительно так, то возможности системы внушают доверие — размывая границы между планированием и исполнением. Однако скептический взгляд заключается в том, что «в режиме реального времени» вероятно относится лишь к некоторым функциям (например, к быстрому перераспределению запасов) и не распространяется, например, на полную переоптимизацию ассортимента, которую вряд ли осуществляют в режиме реального времени. Также стоит отметить, что все поставщики сейчас используют термин «в режиме реального времени» в маркетинге (чаще всего это означает обновление каждые несколько минут или ежечасно, что вполне нормально). Генеральный директор ToolsGroup сама отметила, что розничным торговцам нужно быстро адаптироваться, чтобы предотвратить эрозию маржи при изменении спроса ⁴⁷, что соответствует действительности. Система якобы автоматически пересчитывает и предлагает заказы или перемещения, как только поступают новые данные ⁴⁸.

При условии, что ToolsGroup эффективно интегрировала JustEnough, пользователь их системы мог бы, например, спланировать ассортимент для каждого магазина или канала с помощью модуля JustEnough, затем эта информация поступала бы в целевые запасы в SO99+ и одновременно планировать скидочное ценообразование для товаров на исходе жизненного цикла с использованием их оптимизации. Это охватывает аспекты совместной оптимизации — особенно если прогнозы спроса и параметры запасов учитывают запланированный график скидок. Возможно, процесс всё ещё остаётся последовательным (сначала определяются скидки, а затем анализируется результат по запасам), если только не разработана комбинированная модель оптимизации (что маловероятно для такого широкого охвата). Тем не менее, это единое решение в плане потока данных.

Там, где ToolsGroup явно соответствует современным критериям, так это в вероятностном прогнозировании и оптимизации уровня обслуживания. На протяжении многих лет они утверждали, что прогнозы, представленные одним числом, недостаточны, и что планирование нужно проводить с учетом вероятностей. Например, они предоставляют не просто «ожидаемый спрос = 100», а кривую, показывающую, что существует 10%-ная вероятность того, что спрос превысит 120, и так далее. Затем их оптимизация использует эти данные для определения уровней запасов так, чтобы, скажем, в 95% случаев спрос мог быть удовлетворён ^{49 50}. Такой подход по своей природе учитывает неопределенность и даже эффект каннибализации до некоторой степени (особенно если использовать их модель для коррелированных продуктов). Интересный аспект: ToolsGroup часто утверждала, что применение вероятностного прогнозирования может продлить срок службы устаревающих ERP-систем планирования (например, SAP APO), предоставляя им более качественную информацию ^{1 51}. Это подчеркивает, что отличительной особенностью ToolsGroup была прежде всего математика прогнозирования и управления запасами, а не наличие комплексного пользовательского интерфейса для планирования.

А как насчёт автоматизации и простоты использования? Традиционно ToolsGroup представляла собой скорее «бэкэнд-движок» с несколько громоздким пользовательским интерфейсом, по мнению некоторых пользователей. С тех пор они улучшили интерфейс (новый веб-интерфейс и т.д.). Но, что важнее, они делают акцент на автоматизации планирования. Их материалы утверждают, например, «встроенная автоматизация сокращает рабочую нагрузку при планировании до 90%» ⁵². Они также часто приводят примеры клиентов, которые достигли сокращения рабочей нагрузки планировщиков на 40–90% и уменьшения запасов на 20–30% после внедрения решений ToolsGroup ^{53 54}. Это впечатляющие цифры. Заявление о снижении запасов кажется правдоподобным, если у компании ранее были серьезные проблемы с неэффективностью или избыточными запасами из-за недоверия к прогнозам. Сокращение рабочей нагрузки планировщиков подразумевает, что система способна автоматизировать гораздо больше процессов. Это соответствует нашим ожиданиям: вероятностная система должна снижать количество экстренных ситуаций (так как планирование с учетом неопределенности сводит к минимуму неожиданные ситуации, и планировщикам не приходится экстренно перемещать запасы вручную). Однако скептик может заметить, что сокращение рабочей нагрузки на 90% — это, вероятно, наивысший предел (возможно, случай, когда штат планировщиков сократился с 10 до 1 после внедрения — возможно, но не является типичным). А снижение запасов на 20–30% может быть результатом того, что изначально компания держала слишком большие запасы «на всякий случай». В цепочке поставок обычно при оптимизации наблюдается снижение запасов примерно на 10–15%, если ранее всё было в приемлемых пределах. Таким образом, мы подозреваем, что заявленные показатели ToolsGroup ⁵³ представляют собой наилучшие сценарии. Примечательно, что они представлены в виде диапазонов — это подразумевает, что результаты могут значительно варьироваться в зависимости от клиента.

Одним из преимуществ ToolsGroup является стабильность и узкая специализация. Они занимаются оптимизацией цепочки поставок уже 30 лет (компания основана в 1993 году). Они не так велики, как Blue Yonder, и не так модны, как RELEX, но имеют преданную клиентскую базу и глубокую экспертизу в своей области. Для компании электронной коммерции, ориентированной на рентабельность запасов — то есть на избежание как нехватки, так и избытка запасов — решение ToolsGroup является чрезвычайно зрелым. Их многоуровневая оптимизация может особенно принести пользу интернет-ритейлерам с несколькими центрами выполнения заказов или тем, кто также хранит продукцию на складах 3PL, и т.д. Это позволяет рационально распределять запасы туда, где они наиболее необходимы, при этом поддерживая центральные резервы на минимальном уровне.

Однако слабой стороной ToolsGroup является оптимизация цен. Приобретение JustEnough дало им возможность оптимизировать скидки (определять график скидок для товаров на исходе жизненного цикла). Это полезно для электронной коммерции с сезонными товарами или модной продукцией. Но им всё ещё не хватает настоящей оптимизации динамического ценообразования, подобной тому, что предлагают Revionics/Blue Yonder или специализированные поставщики ценовых решений. Оптимизация скидок касается ценообразования для товаров, приближающихся к концу срока службы или для проведения акций. Обычная ежедневная оптимизация цен (для маржинальности или конкурентного позиционирования) не является сильной стороной ToolsGroup. Возможно, у них имеются базовые возможности или они сотрудничают с партнёрами. Это означает, что если приоритетом является совместная оптимизация цен и запасов, ToolsGroup может уступать таким компаниям, как Blue Yonder или RELEX, которые имеют специализированные ценовые движки. ToolsGroup всё же может оптимизировать запасы при заданной цене, но не подскажет оптимальную цену для максимизации прибыли (за исключением сценариев скидочного ценообразования для убывающих товаров). Это важное различие: их «оптимизация» ориентирована преимущественно на снабжение (поддержание уровней запасов, пополнение), а не на формирование спроса (ценообразование, продвижение) — несмотря на добавление некоторых инструментов для влияния на спрос через поглощение.

Что касается технологического стека, ToolsGroup теперь предлагает облачное SaaS-решение и даже позиционирует некоторые из своих продуктов под модными названиями, такими как «Inventory Hub» и «Fulfill.io». Это показывает, что они стремятся модернизироваться и, возможно, привлечь более широкий рынок, включая компании среднего звена в электронной коммерции. При этом базовый движок по-прежнему использует современные статистические методы и, вероятно, написан на C++ или аналогичном языке для вычислений. Нам не доводилось слышать о проблемах с производительностью у ToolsGroup; у них имеются примеры клиентов, работающих с миллионами комбинаций SKU и местоположений. Если уж и существует слабое место, то оно заключается в том, что их воспринимают как инструмент для оптимизаторов — мощный, но требующий настройки специалистами. Они пытались упростить работу за счет большего количества готовых решений на базе машинного обучения. Например, они интегрируют определение спроса (используя краткосрочные тренды для корректировки прогнозов) и утверждают, что применяют машинное обучение для выявления наиболее влиятельных факторов спроса ⁵⁵. Они также развеяли миф в своем блоге о том, что вероятностные прогнозы не могут корректироваться человеком — уточнив, что они могут учитывать суждения, но математическая модель учтет историческую предвзятость. Это отражает сбалансированный подход: человек не полностью исключается, но его действия сопровождаются более качественными данными.

Эффекты каннибализации: вероятностная модель ToolsGroup может, при соответствующей настройке, учитывать каннибализацию (например, если задать взаимозаменяемость товаров, система сможет смоделировать сценарии, когда при отсутствии одного товара часть спроса переходит к другому). Однако это, вероятно, требует дополнительных усилий по настройке взаимосвязей или использования их алгоритмов машинного обучения для кластеризации товаров. Неясно, насколько это автоматизировано. Но ToolsGroup действительно акцентировала внимание в своем блоге на решении проблем, связанных с «длинным хвостом, прерывистым спросом и большим количеством каналов» в 2017 году, что фактически свидетельствует о том, что традиционные инструменты не справляются, и для этого требуются вероятностные методы ⁵⁶. Они специально упоминают «больше каналов сбыта, когда агрегированный спрос приходит из нескольких источников» как пример, при котором прогнозы, представленные одним числом, оказываются неэффективными, намекая на то, что их решение лучше справляется с мультиканальными данными ⁵⁶. Таким образом, интернет-магазин, торгующий через собственный сайт и Amazon, например, мог бы использовать ToolsGroup для планирования совокупного спроса. Инструмент создавал бы общий прогноз и, возможно, позволял бы оптимально распределять запасы по каналам (хотя распределение по каналам обычно проще, когда все отправляется из одного центра, но в случае раздельных складских пулов это имеет значение).

Один из аспектов, на который стоит обратить внимание при использовании ToolsGroup (как и у любого поставщика комплексных решений, полученных в результате поглощения) — это согласованность пользовательского опыта. Все ли модули прогнозирования, управления запасами и ассортимента теперь интегрированы в один интерфейс, или же пользователю приходится переходить между разными системами? Они работали над объединением интерфейса, но окончательная оценка потребует отзывов пользователей. Вероятно, объединённость пока не так совершенна, как у RELEX, где вся платформа разработана внутри компании.

Если говорить об опыте работы, то у ToolsGroup множество успешных кейсов, часто демонстрирующих снижение запасов и улучшение уровня обслуживания. У них не было широко известных публичных провалов, как это случалось с SAP или JDA. Они меньше по размеру, поэтому каждый проект может получать больше внимания. Тем не менее, поскольку их часто продавали производственным и дистрибуционным компаниям, некоторые представители розничной торговли и электронной коммерции знают их не так хорошо. Выход на рынок розничной торговли через JustEnough означает, что некоторые ранние клиенты JustEnough теперь пользуются решениями ToolsGroup. Сам JustEnough получил смешанные отзывы (был приемлем в плане планирования, но, возможно, ограничен в масштабируемости — неясно). Поэтому ToolsGroup пришлось доработать эти модули. С позиции скептиков, мы бы рекомендовали проверить, насколько действительно интегрирована аналитика. Например, может ли система автоматически распознать, что запланированная акция в модуле JustEnough должна скорректировать прогноз спроса в SO99+? Скорее всего, да — они интегрировали механизмы, учитывающие промоакции. Они упоминают «инсайты обнаружения спроса помогают тонко настроить статистический прогноз» ⁵⁷, что подразумевает учет таких факторов, как акции или последние тренды, для корректировки базовых прогнозов.

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

• Вероятностное прогнозирование? Да, они активно продвигают эту идею ^{49 43}.
• Экономическая оптимизация? В каком-то смысле да, для запасов (они оптимизируют соотношение обслуживания и затрат), хотя не так явно в плане прибыли, как это делает Lokad. Это больше «достижение уровня обслуживания при минимальных запасах», что представляет собой форму оптимизации затрат.
• Масштабируемость? В целом да, без тревожных сигналов. Их подход эффективен (без применения грубой силы).
• Каннибализация? Возможно, с помощью продвинутого моделирования, но это не их основная гордость.
• Рыночная конкуренция? Не является их встроенной функцией — это решается внешними средствами или посредством входных данных. ToolsGroup не будет самостоятельно отслеживать цены конкурентов или подобное.
• Автоматизация? Да, на высоком уровне. После настройки система способна автоматизировать многие задачи планирования, генерируя предложения по заказам, которые планировщики просто утверждают. Они демонстрируют значительное сокращение рабочей нагрузки и снижение влияния человеческого фактора.
• Скептицизм в отношении заявлений поставщика: Маркетинг ToolsGroup на самом деле несколько сдержан по сравнению с другими, помимо упомянутых улучшений, к которым мы уже относились с осторожностью. Они концентрируются на возможностях технологии (их блоги о вероятностном планировании содержательны и не представляют собой просто маркетинговый шум). Однако они присоединились к моде на «искусственный интеллект», называя всё «с поддержкой ИИ». Следует отметить, что они сочетают традиционные методы операционного исследования и машинного обучения, что является здоровым сочетанием.

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

Для чисто электронной коммерции выбор в пользу ToolsGroup, вероятно, будет зависеть от того, является ли оптимизация запасов основной проблемой и требуется ли проверенное, относительно автономное решение для её решения. Если да, то ToolsGroup может стать отличным выбором, обеспечивая быстрые результаты в сокращении запасов и улучшении уровня обслуживания. Однако если компания также стремится к активной оптимизации цен или к передовым омниканальным стратегиям скидок, возможности ToolsGroup могут уступать тем, кто специализируется на ценовой оптимизации, таким как Blue Yonder или RELEX, или специализированным инструментам для ценообразования. Возможно, потребуется сочетать их решение с другим инструментом для оптимизации цен, что приведет к проблемам интеграции. (Интересно, что ToolsGroup, возможно, не возражает против такого сочетания — исторически они нередко работали параллельно с другими системами, сосредотачиваясь на запасах, в то время как другая система отвечала за ценообразование.)

В заключение, ToolsGroup занимает позицию технически надежного поставщика, эволюционировавшего из специализированного решения в комплексную платформу. Мы ценим их инженерную строгость в прогнозировании и их прагматичный подход к неопределенности (они давно развеяли миф о том, что «прогноз всегда неверен», планируя на основе вероятностей). Мы остаемся осторожными в отношении их недавнего расширения: смогут ли их новые розничные модули работать на одном уровне с их основным решением. Внутреннее противоречие, которое мы наблюдаем, заключается в их заявлении о полной интеграции — если появятся какие-либо недоработки (например, необходимость ручного экспорта/импорта данных между модулями), это подорвет их позицию. Но исходя из имеющейся информации, ToolsGroup, похоже, предоставляет более единый опыт после интеграции JustEnough. Они даже следуют тренду использования данных в режиме реального времени в планировании, что заслуживает похвалы.

Наконец, как и с другими, проверка заявлений поставщиков для ToolsGroup. Когда они, например, говорят «доступность продукта более чем на 90%, на 20–30% меньше запасов, снижение объёма работ на 40–90%» ^{53 54} – разумный скептицизм подсказывает, что эти результаты достижимы, но не гарантированы. Эти цифры, вероятно, получены от разных клиентов, каждый из которых достиг одной из этих высоких отметок, а не от одного, достигшего их всех одновременно. Никто не должен ожидать, что его запасы сократятся на 30%, в то время как уровень обслуживания поднимется выше 90% и число планировщиков сократится на 90% одновременно. Как правило, реальность предполагает компромиссы и поэтапное улучшение. Методология ToolsGroup действительно может привести к значительному улучшению, но мы советуем устанавливать реалистичные цели и измерять прогресс по ходу дела. Хорошая новость в том, что ориентация ToolsGroup на измеримые результаты (процент обслуживания, денежные запасы) соответствует поиску истины – по этим показателям очень ясно, работает система или нет.

---

Разоблачая преувеличения: уроки и рекомендации

По мере работы с этими поставщиками выявились несколько общих тем противостояния хайпа и реальности, которые должен иметь в виду руководитель eCommerce:

• Остерегайтесь модных терминов: Такие слова, как «основано на ИИ, когнитивное, чувствующее спрос, в реальном времени, автономное», употребляются свободно. Убедитесь, что за ними стоят конкретные возможности. Например, «чувство спроса» часто звучит отлично – использование данных о продажах за вчера или обсуждений в социальных сетях для корректировки сегодняшнего прогноза – но на практике это может лишь незначительно корректировать цифры и по сути является краткосрочным прогнозированием. Отраслевые эксперты иногда называют «чувство спроса» возможным «mootware» – чем-то, что существует, но не приносит существенной ценности сверх того, что и так делает хорошее прогнозирование ⁵⁸. Не поддавайтесь концепциям «vaporware» без доказательств. Спросите у поставщика: что именно делает ваш ИИ, чего не может моя текущая система, и можете ли вы это доказать? Если они говорят «мы учитываем 300 факторов», требуйте пояснений, действительно ли эти факторы влияют на результат или просто делают привлекательную презентацию.
• Базовые показатели и эталоны: Всегда устанавливайте чёткую исходную точку (например, оборот запасов за прошлый год, коэффициент выполнения заказов, валовая прибыль) и выясните, согласится ли поставщик измерять улучшения относительно неё. Многие заявляют процентные улучшения, которые звучат впечатляюще, но не имеют смысла без соответствующего контекста. Также обращайте внимание на участие во внешних эталонах (например, конкурсах по прогнозированию или публичных кейсах с конкретными цифрами). Конкурс M5 был таким эталоном, который отделил зерна от плевел в прогнозировании – заметно, что ни один из крупных традиционных поставщиков не публиковал там результаты, в то время как небольшой игрок (Lokad) делал это и преуспевал ⁵⁹. Это показывает, кто уверен в своей технологии.
• Сложность интеграции: Если поставщик рос за счёт слияний и поглощений (Blue Yonder, ToolsGroup), будьте осторожны с обещаниями, что «теперь это единая платформа». Часто на полную интеграцию уходит годы. В течение этого времени вы можете фактически использовать отдельные системы с некоторыми интерфейсами. При реализации могут возникнуть скрытые затраты на объединение компонентов. Кроме того, два приобретённых компонента могут иметь разное представление о данных (например, один использует недельные интервалы, другой – ежедневные, или разные определения иерархии продуктов). Это может привести к компромиссам или несоответствиям. Будет разумно пообщаться с клиентами, которые уже интегрировали эти модули.
• Структура затрат: Оценивайте не только лицензионные/абонентские платежи за программное обеспечение, но и эксплуатационные затраты (если применимо) и необходимую инфраструктуру. Как уже отмечалось, решение, основанное на чем-то вроде Snowflake, может переложить облачные вычислительные затраты на вас. Или решение, требующее большого объёма памяти, может заставить вас использовать более дорогие облачные инстансы. Один поставщик может установить высокую абонентскую плату, включая все вычисления; другой может быть дешевле, но потребовать значительные затраты на AWS/Azure для необходимой мощности. Убедитесь, что вы сравниваете общую стоимость владения. Мы упоминали, как модель Snowflake может напоминать недостатки мейнфреймов IBM – следите за тарифами, основанными на использовании, и требуйте прозрачности от поставщиков, использующих эту модель.
• У каждого поставщика бывают неудачи: Важно помнить, что ни один поставщик не будет выделять свои провальные проекты, но они все ими обладают. Реализация не менее важна, чем сам инструмент. Мы видели, как даже такие ведущие поставщики, как SAP или i2 (теперь в составе Blue Yonder), имели провальные проекты на миллионы долларов ^{39 33}. Причины зачастую кроются в плохих данных, несогласованных ожиданиях или в том, что компания не принимает результаты работы системы. При оценке спрашивайте поставщиков, как они справляются с проектами, не достигающими поставленных целей. Есть ли у них (анонимные) примеры извлечённых уроков? Blue Yonder проявил скромность, признавая типичные причины неудач ²⁶. Поставщик, заявляющий «у нас 100% успеха», не является реалистичным. Настаивайте на обсуждении возможных ошибок и способов их минимизации.
• Противоречия между оперативностью и глубиной аналитики: Как отмечалось, некоторые аналитические процессы (например, планирование ассортимента для всей сети) не могут работать в режиме реального времени – они требуют серьёзной обработки данных и деловых обсуждений. Если поставщик утверждает, что его решение обеспечивает и «оперативную реакцию», и «целостную оптимизацию», вам нужно разобраться, какие части решения соответствуют какому обещанию. Например, ToolsGroup может обновлять позиции запасов в реальном времени, однако основная оптимизация может выполняться раз в день. RELEX способен обрабатывать данные почти в реальном времени, но планирование некоторых процессов (например, оптимизация цен с помощью ИИ) всё ещё может осуществляться пакетным методом ночью. Поймите, как часто каждая часть решения работает в соответствии с потребностями вашего бизнеса. Оперативность важна для оперативного выполнения (например, обновления доступных запасов или динамического изменения цен), но для стратегических решений критичны глубина и тщательность.
• Человеческое вмешательство против автономности: Все поставщики утверждают о некотором уровне автономности, но также о возможности вмешательства человека. Это вопрос спектра. Ключевой вопрос: работает ли система по умолчанию в автономном режиме с выделением исключений или же по умолчанию требует проверки каждого решения пользователем? Для реального повышения эффективности вам нужен первый вариант. Красным флагом является, если поставщик подчёркивает количество рычагов и настроек, которыми обладает пользователь – это может означать, что инструмент требует постоянного контроля для получения хороших результатов (что противоречит обещанию автоматизации). Идеально, если система сама настраивает эти рычаги (как Blue Yonder, устраняющий необходимость ручной установки сезонных профилей с помощью машинного обучения ³⁶). Доверяйте, но проверяйте: во время демонстраций или тестовых запусков оцените, сколько ручной настройки требуется, чтобы результаты выглядели убедительно.
• Подробности ИИ/МО: Вдавайтесь в суть утверждений поставщика об использовании ИИ. Спросите: используют ли они машинное обучение для прогнозирования? Какие алгоритмы (если могут назвать)? Применяют ли они библиотеки с открытым исходным кодом (если всё проприетарно, это может говорить о том, что они не отстают от новейших методов; все ведущие ИИ-решения используют открытые библиотеки, такие как TensorFlow/PyTorch, или, по крайней мере, известные алгоритмы). Если поставщик размахивает фразой «проприетарный ИИ-движок», но не может объяснить её понятными словами, стоит насторожиться. И наоборот, если они могут, например, сформулировать «мы используем градиентный бустинг для базовых прогнозов и модель обучения с подкреплением для оптимизации цен», это демонстрирует реальные инвестиции в технологию. Также проверьте, публиковала ли их команда или участвовала ли в академических и отраслевых форумах по своим методам – это признак серьёзного подхода.

Наконец, мы подчёркиваем, что нужно ориентироваться на поиск истины: настаивайте на данных и результатах испытаний, а не на блестящих обещаниях. Если возможно, проведите пилотный проект или proof-of-concept, где каждому поставщику даётся подмножество ваших данных для прогнозирования или оптимизации, и оцените результаты количественно. Например, предоставьте данные за два года и попросите их прогнозировать третий год (по которому уже есть фактические данные) – посмотрите, кто окажется ближе или кто выявит сложные паттерны спроса. Либо поручите им оптимизировать сценарий, а затем смоделировать затраты/результаты обслуживания, используя ваши реальные данные, для подтверждения. Немногие поставщики добровольно участвуют в соревновательных тестированиях, но хорошие часто соглашаются, потому что уверены в своей науке. Например, Lokad часто участвует в пилотных проектах. Blue Yonder и RELEX иногда проводят этапы «discovery», напоминающие пилотные проекты. Просто убедитесь, что у вас есть чёткие критерии успеха.

В конечном итоге, на рынке программного обеспечения для оптимизации в eCommerce не наблюдается недостатка в самопровозглашённых «чудесах ИИ», но, применяя глубокий скептицизм и требуя инженерных доказательств, можно отсеять лишний шум. Это исследование показало, что Lokad лидирует в технических инновациях и фокусе, RELEX – в унифицированной функциональности для розничной торговли (с некоторыми элементами хайпа, за которыми стоит следить), Blue Yonder – в широте и опыте (на фоне сложного технологического обновления), а ToolsGroup – в специализированных оптимизационных возможностях (с растущей интеграцией). Каждый из них может принести значительные преимущества, но ни один не является универсальным решением «подключи и работай». Истина в том, что успешная оптимизация достигается с помощью правильного инструмента и правильной стратегии внедрения. Благодаря изложенным выше выводам и предостережениям, компания в сфере eCommerce может подойти к этим поставщикам с ясным пониманием и сделать выбор, основанный на фактах и обоснованных рассуждениях, а не только на маркетинговом блеске.

Сноски