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

От Léon Levinas-Ménard

Последнее изменение: February 2nd, 2025

Программное обеспечение для планирования цепочки поставок предназначено для оптимизации решений (что производить, складировать или перемещать, и когда) в условиях неопределённости – а не просто для регистрации транзакций. Как говорится в одном определении, цепочка поставок – это «количественное, но практичное владение возможностями при столкновении с изменчивостью и ограничениями… с акцентом на развитие и выбор вариантов, а не на непосредственное управление базовыми операциями.» ¹ Другими словами, лучшие инструменты планирования сосредоточены на оптимизации (например, определении оптимальных уровней запасов или производства), а не только на транзакционном управлении (отслеживании заказов и запасов). Это исследование сравнивает ведущих поставщиков программного обеспечения для планирования цепочки поставок и прогнозирования, делая акцент на очевидных технических доказательствах вместо маркетинга. Мы оцениваем каждого поставщика по ключевым критериям:

Вероятностное прогнозирование – Предоставляют ли они не только точечные прогнозы, но и полное распределение или продвинутые модели? Если заявлено «AI/ML» прогнозирование, есть ли доказательства (например, отличные результаты в мировых конкурсах по прогнозированию, таких как M5), подтверждающие это?
Степень автоматизации – Может ли система запускать прогнозирование и планирование без присмотра (полностью роботизировано) без постоянного вмешательства человека? Насколько автономна способность принятия решений?
Масштабируемость и производительность – Может ли технология эффективно обрабатывать большие объёмы данных? (Остерегайтесь архитектур, работающих в памяти, которые плохо масштабируются при росте объёма данных и стагнации затрат на память.)
Интеграция технологий и приобретения – Построено ли решение на единой технологической платформе или представляет собой набор приобретённых модулей? Долгая история слияний и поглощений может привести к фрагментации и несогласованности технологий.
Техническая надёжность – Подкреплены ли технологические заявления поставщика научными принципами или инженерными доказательствами? Мы смотрим дальше модных слов (таких как «AI/ML», «определение спроса») в поисках конкретных объяснений или подтверждения коллегами.
Последовательность и противоречия – Совместимы ли сообщения поставщика? (например, утверждение о вероятностном прогнозировании наряду с показателями детерминированной точности, такими как MAPE, может служить тревожным сигналом.)
Устаревшие практики – Мы отмечаем устаревшие методы (например, упрощённые формулы страхового запаса), которые противоречат современной вероятностной оптимизации.
Ориентированность на принятие решений – Производит ли программное обеспечение только прогнозы, или же оно предоставляет оптимизированные решения (план заказов, целевые уровни запасов) на основе этих прогнозов? Истинная цель — поддерживать процесс принятия решений, а не просто генерировать числа.

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

Ниже мы сначала ранжируем ведущих поставщиков программного обеспечения для планирования цепочки поставок по технологическому лидерству, с кратким объяснением для каждого. После краткого обзора следуют подробные сравнения, структурированные по вышеупомянутым техническим критериям. Все утверждения подкреплены ссылками на авторитетные источники (в формате【source†line】).

Ведущие поставщики, ранжированные по технологическому совершенству

Lokad – Передовая вероятностная оптимизация Lokad лидирует в технологических инновациях, являясь пионером в области вероятностного прогнозирования и действительно ориентированного на принятие решений планирования. Уже в 2012 году Lokad выступил за вероятностные прогнозы (почти на десятилетие опережая остальных) и построил всё своё решение вокруг этой концепции ². В отличие от поставщиков, которые рассматривают прогнозирование и планирование как отдельные этапы, система Lokad (построенная на предметно-ориентированном языке Envision) напрямую генерирует оптимизированные решения (заказы, уровни запасов) на основе вероятностных моделей. Техническая надёжность Lokad исключительна — она открыто документирует свои методы, а её команда достигла наивысшей точности на уровне SKU в престижном конкурсе прогнозирования M5 (среди 909 команд) ³. Эта победа в реальных условиях при детальном прогнозировании подчёркивает передовые предсказательные возможности Lokad. Платформа является облачной и полностью автоматизированной (прогнозы и оптимизации выполняются без присмотра по расписанию) и обходится без ограничений дизайна, основанного на работе в памяти, используя масштабируемые облачные вычисления. В итоге, Lokad устанавливает эталон с помощью своего вероятностного, ориентированного на автоматизацию и подкреплённого доказательствами подхода к оптимизации цепочки поставок.
Kinaxis – Быстрое планирование с использованием in-memory технологии и развивающегося ИИ Kinaxis — это устоявшийся лидер, известный своим сверхбыстрым движком «одновременного планирования». Его платформа RapidResponse использует архитектуру in-memory для обеспечения моделирования сценариев в реальном времени по данным о поставках, спросе и запасах. Такой дизайн позволяет планировщикам мгновенно проводить анализ «что если», что является важным преимуществом для оперативности. Однако сильная зависимость от вычислений в памяти может означать высокие затраты на оборудование и ограничения масштабируемости по мере роста данных (крупные развертывания требуют огромного объёма оперативной памяти) ⁴. Традиционно Kinaxis концентрировался на детерминированном планировании (с использованием правил, задаваемых пользователями, и ручных корректировок). Осознав сдвиг в отрасли, Kinaxis недавно принял вероятностные методы, интегрируя приобретения и партнёрства: например, он добавил вероятностный многоступенчатый механизм оптимизации запасов (MEIO) (от партнёра Wahupa) и приобрёл компанию, занимающуюся прогнозированием спроса с использованием ИИ (Rubikloud). Эти дополнения привносят передовое прогнозирование и моделирование неопределённости в Kinaxis, хотя как дополнительные модули они вызывают вопросы о согласованности технологического стека. Сообщения Kinaxis относительно «ИИ» и машинного обучения более сдержаны по сравнению с некоторыми конкурентами — они подчёркивают сочетание человеческого и машинного интеллекта. На практике Kinaxis превосходит в автоматизации перерасчёта планов (каждый раз, когда данные изменяются, система может автономно сбалансировать планы поставок и спроса), но исторически он всё ещё полагался на планировщиков для установки параметров и не полностью автоматизировал окончательные решения. С его новыми вероятностными модулями Kinaxis движется в сторону более автоматизированного принятия решений в условиях неопределённости, хотя и с детерминированного наследия. В итоге, Kinaxis предлагает мощную платформу для планирования в реальном времени и догоняет по части прогнозирования, основанного на ИИ, но должен доказать, что его новые вероятностные функции глубоко интегрированы, а не поверхностны.
o9 Solutions – Большие амбиции и большие данные o9 Solutions — новый участник рынка (основан в 2009 году), которого часто называют «цифровым мозгом» для цепочки поставок. С технологической точки зрения, o9 обладает невероятными амбициями — он построил широкую платформу с графовой моделью данных (Enterprise Knowledge Graph, «EKG») и обслуживает огромные, сложные наборы данных (что делает его популярным среди крупных предприятий, ищущих комплексное средство планирования). Однако подход o9 имеет свои компромиссы. По сообщениям, система использует дизайн на основе in-memory, который, хотя и обеспечивает быструю аналитику, “гарантирует высокие затраты на оборудование” для крупномасштабного применения ⁴. Это вызывает вопросы масштабируемости, поскольку увеличение оперативной памяти становится дорогостоящим и в конечном итоге сталкивается с ограничениями (особенно учитывая, что цены на память уже не падают так быстро). o9 активно продвигается вокруг AI/ML, но необходимо уметь отделять суть от хайпа: многие его заявления (например, что его граф знаний уникально улучшает прогнозирование) являются сомнительными без научного обоснования ⁵. Фактически, анализ публично доступных технологических элементов o9 на GitHub показывает, что он в основном использует стандартные методы (ничего принципиально нового, что могло бы оправдать грандиозный брендинг «AI») ⁶. o9 поддерживает вероятностное планирование сценариев в определённой степени — он может моделировать несколько сценариев спроса и проводить симуляции, — но неясно, предоставляет ли он действительно вероятностное распределение прогнозов или просто анализ сценариев. Платформа может автоматизировать определённые задачи планирования, однако o9 часто позиционирует себя как средство поддержки принятия решений, оставляя окончательное управление «цифровым мозгом» за человеком. В целом, o9 — это технологически насыщенная платформа с широкими возможностями, но её зависимость от вычислений в памяти и нечеткость заявлений об ИИ сказываются на её воспринимаемом техническом лидерстве. Она является лидером скорее благодаря интегрированному видению и работе с большими данными, чем благодаря доказанно уникальной точности прогнозирования.
Relex Solutions – Автоматизация для ритейла (с ограничениями) Relex Solutions (основана в 2005 году) специализируется на прогнозировании спроса в ритейле, пополнении запасов и планировании пространства. Она заработала репутацию благодаря высокоавтоматизированному пополнению запасов в магазинах – несколько крупных продуктовых сетей используют Relex для автоматического прогнозирования спроса на уровне магазинов и генерации заказов с минимальным участием человека. Эта комплексная автоматизация в сложной розничной среде является заметным преимуществом. Relex также рекламирует современные методы прогнозирования с использованием машинного обучения, адаптированные для ритейла (с учётом промоакций, местных событий и т.д.). Однако подробный анализ выявляет некоторые архитектурные и методологические ограничения. Система Relex использует дизайн OLAP-куба в памяти ⁷ для обеспечения очень быстрой аналитики и отчётности. Хотя это обеспечивает быстрые дашборды, это увеличивает затраты на оборудование и по своей сути не решает сложные задачи оптимизации. Фактически, подход Relex, ориентированный на работу в реальном времени и детализацию, может конфликтовать с оптимизацией на уровне всей сети — ему может быть сложно оптимально согласовать решения в крупной сети поставок при наличии таких явлений, как каннибализация товаров или их замены ⁸. Также имеются признаки того, что прогнозные модели Relex не настолько «следующего поколения», как рекламируется — данные свидетельствуют о том, что большая часть их подхода основывается на методах до 2000 года (например, регрессия, сглаживание временных рядов) ⁹, пусть и применяемых в масштабах крупных предприятий. Они часто хвастаются 99%+ наличием товаров на складе для ритейлеров, но отраслевые опросы (например, ассоциаций ECR) показывают, что типичное наличие на полке ниже, что ставит под сомнение такие общие заявления. Relex имеет в основном согласованный технологический стек (разработанный для ритейла) и не рос за счёт крупных приобретений, что положительно сказывается на согласованности. В итоге, Relex является лидером в автоматизации для ритейла и может обеспечить впечатляющую работу без постоянного контроля, однако её техническая глубина в области прогнозной науки вызывает вопросы, и архитектура, основанная на работе в памяти, означает, что она разделяет проблемы масштабируемости с другими.
ToolsGroup – Ранний новатор, ныне рекламирующий «ИИ» ToolsGroup (основана в 1993 году) предлагает программное обеспечение SO99+, исторически известное благодаря прогнозированию, основанному на уровне обслуживания, и оптимизации запасов. За годы до того, как «ИИ» стал модным словом, ToolsGroup способствовал популяризации вероятностных концепций в цепочке поставок — например, моделированию изменчивости спроса для определения страховых запасов, необходимых для достижения требуемого уровня обслуживания. На практике их инструмент может строить вероятностное распределение спроса (особенно для товаров с медленным оборотом) и рассчитывать целевые уровни запасов для достижения заданного коэффициента заполнения. Однако в последние годы позиционирование ToolsGroup изменилось в сторону хайпа вокруг AI/ML, и здесь пробиваются трещины в надёжности. Они активно рекламируют планирование с поддержкой «ИИ», но публичные сигналы указывают на то, что их основные алгоритмы по сути остаются устаревшими (до-2000 статистическими моделями) ¹⁰. Примечательно, что с 2018 года они начали называть свой результат «вероятностными прогнозами», одновременно хвалясь улучшениями MAPE ¹¹ — явное несоответствие, так как MAPE (метрика ошибки детерминированного прогноза) «не применима к вероятностным прогнозам» ¹². Это говорит о недопонимании или маркетинговой хитрости (например, возможно, они генерируют вероятностные прогнозы, но всё ещё оценивают их, сравнивая медиану с фактическими значениями с помощью MAPE — что упускает суть вероятностных методов). ToolsGroup также продвигает «определение спроса» для краткосрочной корректировки прогнозов, однако такие заявления не подтверждены научной литературой ¹² и зачастую представляют собой переупакованные скользящие средние. С положительной стороны, решение ToolsGroup является достаточно функциональным для планирования цепочки поставок (охватывая прогнозирование спроса, оптимизацию запасов, S&OP и т.д.) и может работать в режиме без участия человека (автоматическое формирование предложений по пополнению запасов каждую ночь). Его ориентация на оптимизацию (достижение целевых показателей обслуживания при минимальных запасах) соответствует подходу, ориентированному на принятие решений. Однако недавнее позиционирование ToolsGroup с упором на ИИ без чётких технических доказательств, а также архитектура, которая, возможно, не является современной облачной (скорее ориентирована на один сервер), немного снижает его технологическое лидерство. Короче говоря, ToolsGroup — это проверенный игрок в моделировании вероятностных запасов, но ему нужна большая прозрачность, чтобы подтвердить свои новые заявления об ИИ и убедиться, что его методы не застопорились.
Blue Yonder – Мощное наследие, фрагментарные технологии Blue Yonder (основанная в 1985 году как JDA Software, затем переименованная после приобретения небольшой AI-компании Blue Yonder) является гигантом в области планирования цепочки поставок. Она предлагает решения для планирования спроса, планирования поставок, розничной торговли и многого другого. На протяжении десятилетий Blue Yonder (BY) накопила большой портфель за счет многих приобретений – от Manugistics (оптимизация цепочки поставок) до компонентов i2 Technologies, а недавно – стартапа Blue Yonder AI. Результат – «смешанная коллекция продуктов, большинство из которых устарели», даже если они объединены под одним брендом ¹³. Технологически наследуемые модули Blue Yonder (например, Прогнозирование спроса или Исполнение заказов) часто используют устаревшие методы (например, эвристическое прогнозирование, планирование на основе правил с учетом страховых запасов). Компания действительно демонстрирует «AI/ML» в своем маркетинге, но утверждения, как правило, расплывчаты и малообоснованы ¹⁴. Любопытный факт: у Blue Yonder есть всего несколько проектов с открытым исходным кодом на GitHub (например, tsfresh, PyDSE, Vikos), которые намекают на базовые подходы к прогнозированию – это в первую очередь традиционные методы, такие как извлечение признаков + модели ARIMA/линейной регрессии ¹⁵, а не современные методы глубокого обучения или вероятностные модели. Иными словами, «AI» BY, скорее всего, больше шумиха, чем прорыв. Связность платформы вызывает вопросы – планирование, пополнение запасов и оптимизация запасов могут существовать как отдельные движки, которые не работают слаженно как единое целое (интеграция требует значительных усилий по реализации). Blue Yonder действительно обладает очень сильными возможностями оптимизации в отдельных областях (например, их наследуемые алгоритмы i2 для оптимизации сети цепочки поставок, если их модернизировать, могут быть мощными). И многие крупные предприятия используют Blue Yonder для автоматизации плановых задач (например, для генерации прогнозов, которые запускают процесс MRP, установления уровней страховых запасов и т.д., при этом планировщики корректируют результаты на основе исключений). Однако, по сравнению с новыми технологическими лидерами, Blue Yonder выглядит технически застоявшейся: она в значительной степени придерживается детерминированного прогнозирования (часто измеряемого старыми метриками, такими как MAPE или смещение), использует устаревшие практики, такие как формулы для расчета страховых запасов в качестве основного элемента планирования и лишь слабо включает терминологию AI. Учитывая её ресурсы, Blue Yonder могла бы эволюционировать, но на данный момент она олицетворяет компромисс крупного поставщика: широкая функциональность при разрозненной, устаревающей технологической базе ¹³. Мы оцениваем её ниже более перспективных конкурентов с технологической точки зрения.

(Другие заметные поставщики: SAP IBP и Oracle SCM Cloud также предоставляют пакеты для планирования цепочки поставок, но в основном это расширения их транзакционных ERP-систем. Они наследуют значительный технический долг и сложность от устаревших систем и приобретений. Например, предложение для планирования от SAP представляет собой смесь компонентов, таких как SAP APO, SAP HANA, а также приобретенных инструментов (SAF для прогнозирования, SmartOps для управления запасами) – по сути, «коллекция продуктов», требующая значительных усилий по интеграции ¹⁶. Эти решения, связанные с ERP, хотя и мощные в некоторых аспектах, в общем не являются лидерами в области науки о прогнозировании или автоматизации, поэтому они исключены из верхних строчек.)

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

Вероятностное прогнозирование: За рамками детерминированных моделей

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

Lokad выделяется глубоким внедрением вероятностного прогнозирования. Он был одним из первых, кто продвигал вероятностные модели (с 2012 года) ² и постоянно совершенствовал эту возможность. Подход Lokad использует вероятностное распределение спроса как основу для всех оптимизаций – например, вычисляя ожидаемую прибыль при различных объемах запасов посредством интеграции по распределению спроса. Надежность технологий прогнозирования Lokad подтверждается глобальными соревнованиями: команда Lokad достигла наивысшей точности на уровне артикулов в соревновании по прогнозированию M5 ³, что является высокооцененным эталонным испытанием. Важно, что M5 целиком посвящено вероятностному прогнозированию (рейтинги основывались на взвешенных метриках ошибок распределения), и результаты Lokad указывают на то, что их методы действительно находятся на передовом уровне, генерируя точные вероятностные распределения на детальном уровне. На практике Lokad выдает не просто число, а полное вероятностное распределение (или сценарии) для спроса каждого товара, которое напрямую используется в сценариях оптимизации решений.
ToolsGroup, за свою заслугу, уже много лет предлагает вероятностные функции в контексте оптимизации уровня обслуживания. Их программное обеспечение может создавать явное распределение спроса (часто с помощью модели прерывистого спроса или другого статистического метода), а затем рассчитывать целевые запасы для достижения требуемой вероятности обслуживания. Однако существует разница между наличием вероятностной модели под капотом и полным принятием этой концепции. Маркетинг ToolsGroup, начиная с 2018 года, свидетельствует о попытке ребрендинга в качестве лидера вероятностного прогнозирования, но они ослабляют это, одновременно упоминая улучшения MAPE наряду с вероятностными прогнозами ¹². Это противоречие – если действительно прогнозируется распределение, основным показателем успеха не должен быть MAPE (который предполагает единственное «правильное» число). Тот факт, что они по-прежнему опираются на детерминированные метрики, указывает на то, что они, возможно, продолжают генерировать точечные прогнозы, используя распределения лишь для моделирования требований к запасам. Таким образом, хотя у ToolsGroup имеются вероятностные возможности, сложность этих методов, возможно, не является передовой, и степень их приверженности вероятностным подходам по сравнению с использованием их в качестве дополнительной функции остается неясной.
Kinaxis исторически не предоставляла вероятностные прогнозы в своем основном предложении (она полагалась на точечные прогнозы, вводимые пользователями или генерируемые с помощью простых статистических методов). Признавая этот пробел, Kinaxis заключила партнерство с Wahupa для интеграции вероятностного MEIO (многоуровневая оптимизация запасов) ¹⁷. Более того, Kinaxis приобрела AI-компанию (Rubikloud), специализирующуюся на машинном обучении для прогнозирования спроса (вероятно, по своей природе вероятностное, например, с интервалами прогнозирования). По состоянию на 2023 год Kinaxis начала продвигать «Planning.AI» или аналогичные возможности, явно признавая необходимость «принятия неопределенности» и использования вероятностной науки в принятии решений ¹⁸. Это положительное развитие, но поскольку оно относительно новое, зрелость вероятностного прогнозирования в Kinaxis все еще развивается. Мы не видели, чтобы Kinaxis или ее партнеры участвовали в публичных соревнованиях по прогнозированию или публиковали подробную методологию, поэтому техническое подтверждение их вероятностных возможностей ограничивается лишь их заявлениями.
o9 Solutions также акцентирует внимание на моделировании неопределенности в концепции – их граф знаний способен хранить множество причинно-следственных факторов, и они утверждают, что генерируют лучшие прогнозы посредством связывания данных. Но, опять же, мы не обнаружили публичных доказательств того, что o9 предоставляет вероятностные прогнозы на практике (нет опубликованных показателей точности или открытых алгоритмов). Упоминаний о байесовских сетях или методе Монте-Карло в их материалах немного. Элементы, обнаруженные в репозиториях кода o9, кажутся сосредоточенными на типичных методах прогнозирования, а не на новых вероятностных алгоритмах ⁶. Пока o9 не продемонстрирует иное, мы должны предположить, что она в первую очередь предоставляет улучшенные детерминированные прогнозы (возможно, с анализом сценариев), и любое обозначение «вероятностное» скорее является маркетинговым.
Relex Solutions работает в розничной торговле, где изменчивость (особенно для акций или скоропортящихся товаров) высока. Они, вероятно, используют некоторые вероятностные подходы внутренне (например, для оценки распределения спроса на товары, участвующие в акциях, или для расчета потребности в страховых запасах для магазина с заданным уровнем обслуживания). Однако публичные материалы Relex не провозглашают термин «вероятностное прогнозирование» явно; они больше говорят о том, как машинное обучение улучшает точность прогнозов (обычно подразумевая более точечные прогнозы). Рецензии коллег указывают на то, что их технологии прогнозирования кажутся дородовыми до 2000 года ⁹, что, вероятно, означает преимущественно детерминированные методы, такие как экспоненциальное сглаживание, возможно с учетом сезонности и тренда – методики, генерирующие точечные прогнозы и, возможно, стандартное отклонение для расчета страховых запасов. Таким образом, Relex, вероятно, продолжает опираться на старую парадигму: сначала прогноз, а затем добавление буфера, а не предоставление полного вероятностного распределения для пользователя.
Blue Yonder в своем традиционном планировании спроса использует различные статистические модели (ARIMA, экспоненциальное сглаживание, возможно, некоторые методы машинного обучения для учета причинных факторов) для формирования прогнозов, как правило, агрегированных и построенных на консенсусном процессе – по сути, детерминированных. Blue Yonder начала упоминать вероятностные термины в некоторых контекстах (так как это стало модно), но, учитывая, что их открытые проекты свидетельствуют об использовании методов ARIMA и регрессии ¹⁵, можно с уверенностью сказать, что вероятностное прогнозирование не является их сильной стороной. Они также продолжают использовать такие метрики, как MAPE, смещение и т.д., которые являются детерминированными. Мы не видели, чтобы Blue Yonder принимала участие в известных эталонных соревнованиях по прогнозированию.
Другие поставщики: John Galt Solutions продвигает алгоритм «Procast», утверждая о его превосходной точности, но один обзор отметил, что это утверждение вызывает сомнения, поскольку Procast отсутствовал среди лидеров крупных соревнований по прогнозированию, таких как M5 ¹⁹. Фактически, доступные инструменты с открытым исходным кодом для прогнозирования (например, Prophet или R-пакеты от Hyndman) предположительно работают не хуже или лучше ²⁰. Это подчеркивает общую тему: настоящие инновации проявляются там, где существует открытая оценка. Отсутствие большинства поставщиков (за исключением Lokad) на публичных соревнованиях указывает на то, что многие из них на самом деле не опережают академические круги или открытый исходный код в области прогнозирования, иначе они смогли бы это доказать на этих площадках.

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

Степень автоматизации: планирование без участия человека vs. с участием человека

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

Lokad разработан с учетом автоматизации. Его сценарная среда Envision позволяет закодировать и запланировать всю логику прогнозирования и пополнения запасов. Многие внедрения Lokad работают на полностью роботизированной основе, при которой ежедневно или еженедельно система автоматически загружает новые данные, пересчитывает прогнозы, оптимизирует решения (например, генерирует объемы заказов или планы распределения) и передает их в ERP или систему исполнения – все это без ручной корректировки. Философия заключается в том, что если модели настроены правильно, ручное вмешательство должно быть минимальным, и планировщики могут сосредоточиться на исключениях или улучшении моделей, а не на рутинной корректировке. Истории успеха Lokad часто подчеркивают кардинальное снижение нагрузки на планировщиков благодаря этой автоматизации. По сути, Lokad рассматривает планировщиков скорее как специалистов по данным или руководителей процесса, а не как людей, ежедневно вручную настраивающих элементы планирования.
Relex Solutions также обеспечивает высокий уровень автоматизации, особенно в пополнении запасов. Например, для продуктовых ритейлеров Relex может автоматически генерировать заказы для магазинов каждый день, учитывая прогнозы, наличие товаров на складе и сроки поставки. Сообщается, что некоторые ритейлеры, использующие Relex, доверяют системе настолько, что подавляющее большинство заказов отправляются автоматически, а планировщики лишь проверяют предложения, выходящие за рамки норм. Система Relex поддерживает рабочие процессы для обработки исключений (например, может сигнализировать, если прогноз существенно отклоняется от нормы, после чего человек проводит проверку), но в остальном она предназначена для автоматического выполнения планирования спроса и оформления заказов. Это ключевое преимущество в розничной торговле, где масштаб (миллионы комбинаций артикул-магазин) делает ручное планирование невозможным. Однако стоит отметить, что достижение такой автоматизации часто требует стабильных, зрелых моделей и узкой специализации (например, для основных продуктовых товаров). В более сложном многоуровневом производственном планировании Relex менее заметен. Тем не менее, в своей области Relex доказывает, что автоматизированное прогнозирование и пополнение запасов достижимо, пусть и в рамках ограничений архитектуры, основанной на оперативной памяти.
Kinaxis предлагает автоматизацию перерасчёта – благодаря параллелизму, каждый раз при изменении данных, система способна распространять изменения через модель цепочки поставок (свод материалов, запасы, мощности) для автоматического обновления всех зависимых планов. Это форма автоматизации (устраняющая необходимость вручную перезапускать отдельные циклы планирования для каждого уровня). Однако Kinaxis традиционно ожидает, что планировщики будут хотя бы частично вовлечены: они настраивают сценарии, анализируют результаты и решают, какой сценарий утвердить. Kinaxis может автоматизировать рутинные решения посредством своей системы оповещений (например, автоутверждение плана, если запасы превышают порог), но в целом используется как инструмент поддержки принятия решений вместо «тёмного» автопилота. Тем не менее, с интеграцией ИИ и более продвинутого прогнозирования, Kinaxis движется в сторону более автоматизированного принятия решений. Например, его новый MEIO может автоматически перераспределять буферы запасов между уровнями при каждом запуске планирования, причем пользователь может принять результат, если только что-то не покажется неверным. Компания также инвестирует в то, что она называет «самовосстанавливающимися цепочками поставок», что подразумевает большую автономию. Однако, учитывая базу клиентов (часто аэрокосмическую, автомобильную и т.д., где планировщики действуют с осторожностью), полностью автономное планирование не является нормой для развертываний Kinaxis.
o9 Solutions аналогично обычно внедряется как платформа планирования, где пользователи (планировщики, менеджеры по спросу и др.) активно взаимодействуют – корректируя прогнозы, сотрудничая при составлении планов S&OP, проводя сценарии. Система, безусловно, технически способна автоматизировать расчёты (например, можно настроить периодические обновления прогнозов), но философия o9 больше склоняется к дополнению человеческих планировщиков ИИ-инсайтами, а не к их замене. Маркетинговый термин «цифровой двойник организации» подразумевает, что система отражает вашу цепочку поставок в программном обеспечении; однако зеркало обычно отражает то, что вы делаете, и не принимает решений самостоятельно. Мы не обнаружили доказательств того, что какую-либо компанию используют o9 в полностью автономном режиме; скорее, это инструмент, предоставляющий единую модель данных и аналитику для облегчения межфункционального планирования. Автоматизация ориентирована на интеграцию (автоматизацию потоков данных между модулями) больше, чем на автоматизацию принятия решений.
ToolsGroup традиционно предлагала подход «низкого вмешательства в планирование». Их инструмент SO99+ можно настроить на автоматическое создание статистических прогнозов для каждого SKU, затем расчёт целевых уровней запасов и даже предложение заказов на пополнение. Многие компании среднего размера действительно использовали его для автогенерации заказов на закупку или производственных предложений, при этом планировщики лишь просматривали исключения (например, случаи, когда система не уверена из-за необычных обстоятельств). Достигнутый уровень автоматизации зависит от доверия к рекомендациям системы. ToolsGroup часто подчёркивает, что их вероятностный подход приводит к более надёжным рекомендациям по запасам, что, в свою очередь, делает компании более склонными к автоматизации заказов в большей степени. Однако, если модели ToolsGroup настроены неправильно, пользователи могут часто их переопределять. С точки зрения технических возможностей, ToolsGroup определённо может работать в пакетном автономном режиме для прогнозирования и первоначального планирования. Но, возможно, он не справляется с динамическим перепланированием так же хорошо, как, например, Kinaxis (это больше ночное пакетное планирование).
Blue Yonder (JDA) включает компоненты, такие как ESP (Enterprise Supply Planning) и Fulfillment, которые могут автоматически выпускать заказы на поставку или рекомендации по перемещению запасов на основе прогнозов и политик управления запасами. Многие пользователи Blue Yonder действительно полагаются на автогенерируемые результаты: например, система может автоматически создавать заказы на распределение для пополнения региональных складов до целевых уровней запасов. Модуль Demand от Blue Yonder способен еженедельно или ежемесячно автоматически формировать базовые прогнозы. Однако исторически реализации JDA/Blue Yonder включают значительный объём ручных операций: планировщики спроса корректируют прогнозы, планировщики поставок анализируют рекомендованные системой заказы и т.д. Программное обеспечение поддерживает автоматизацию, но не обязательно поощряет менталитет «без вмешательства» – это скорее рабочая панель планировщика. Кроме того, учитывая фрагментарный характер набора решений BY, достижение сквозной автоматизации может потребовать значительных усилий по интеграции (гарантировать, что план спроса переходит в модуль плана поставок, который без ручного вмешательства переходит в выполнение, может быть непростой задачей). Таким образом, хотя это технически возможно, на практике у клиентов Blue Yonder часто присутствует значительный человеческий контроль над планами.

В итоге, возможности автоматизации присутствуют во всех ведущих инструментах в различной степени, но философия и практическое применение различаются. Lokad и Relex известны тем, что раздвигают границы действительно автономного планирования в своих нишах (Lokad обеспечивает полностью запрограммированные «автопилоты цепочек поставок» для различных отраслей, а Relex — в розничной торговле). Традиционные крупные вендоры относятся к автоматизации более осторожно, часто оставляя окончательное решение за планировщиком. Это зачастую связано с проблемами доверия – если прогнозы системы не являются достаточно надёжными, пользователи не позволят ей работать в режиме автопилота. Это подчёркивает, что автоматизация так хороша, насколько хорош ум, лежащий в её основе: ключевая причина, по которой требуются вероятностные, ориентированные на принятие решений инструменты, заключается в том, чтобы сделать автоматизацию жизнеспособной (система должна самостоятельно принимать правильные решения). При оценке вендоров компании должны задаваться вопросом: Может ли эта система работать самостоятельно в течение месяца и поддерживать или улучшать наши показатели? Лучшие технологии приближаются к ответу «да» на этот вопрос, тогда как другие по-прежнему принципиально требуют ручного контроля.

Масштабируемость и производительность: Архитектура имеет значение

Планирование цепочек поставок часто сталкивается с большими данными (огромное количество SKU, магазинов, заказов, сигналов IoT и т.д.) и сложными вычислениями (оптимизация по множеству переменных). Основная архитектура каждого решения – будь то хранение данных в оперативной памяти или распределённая система, способ обработки растущих объёмов данных – напрямую влияет на его масштабируемость и производительность. Неправильный выбор архитектуры может привести либо к медленной работе, либо к непомерно высоким затратам на оборудование (или и к тому, и к другому), особенно по мере роста бизнеса. Основные моменты масштабируемости для вендоров:

In-Memory против распределённых вычислений: Основной момент – разница между решениями, которые загружают большинство данных в оперативную память для быстрого расчёта, и теми, которые используют более распределённые, по требованию вычисления (в облачном стиле). Kinaxis, o9, Relex и SAP IBP все обладают сильной компонентой хранения в памяти. Движок Kinaxis был создан на основе идеи, что все релевантные данные планирования находятся в памяти для мгновенного пересчёта – это работает до определённого предела, но масштабирование свыше нескольких терабайт данных в памяти становится чрезвычайно затратным и технически сложным. O9 и Relex также «гарантируют высокие аппаратные расходы» из-за in-memory дизайна ⁴ ⁷ – по сути, пользователь платит за очень большие серверы или кластеры с огромным объемом оперативной памяти. Такой подход имел свои преимущества 10–20 лет назад, когда память была дешёва, а объемы данных были скромнее, но сейчас цены на память стабилизировались, а сложность данных возросла, что делает эту стратегию менее перспективной. В отличие от этого, Lokad полностью основан на облаке и не требует хранения всех данных в оперативной памяти. Он использует вычисления по требованию (например, параллельную обработку данных на множестве машин по необходимости с последующим освобождением ресурсов). Это означает, что он может масштабироваться для решения очень больших задач посредством добавления вычислительных узлов, а не за счет ограничения объема памяти одного сервера. Облачная архитектура Lokad также активно использует дисковое и сетевое хранилище там, где это необходимо, что соответствует современным трендам работы с большими данными (когда распределённое хранение и вычисления, например, парадигмы MapReduce, справляются с масштабом).
Производительность в масштабах крупного бизнеса: Более старые модули Blue Yonder (например, APO от SAP или наследие самого JDA) иногда испытывали трудности с большими задачами, требующими агрегации или сегментации данных для выполнения расчетов. Новые облачные версии (BY Luminate) вероятно улучшили ситуацию за счёт лучшего управления памятью и, возможно, эластичного масштабирования, но доказательств этому немного. SAP IBP использует HANA (in-memory колоночная база данных); она способна обрабатывать большие объёмы данных, но требует очень высоких затрат на инфраструктуру и часто нуждается в предварительной агрегации данных до определённых уровней, чтобы планирование завершалось вовремя. Планирование Oracle использует реляционную базу данных, которая может частично выгружать данные на диск, однако расчёты могут выполняться медленнее (хотя Oracle использует оптимизацию базы данных). ToolsGroup, как правило, работала с наборами данных среднего размера (от тысяч до десятков тысяч SKU) на одном сервере; производительность может снижаться при очень большом числе SKU, если вычислительный процесс не будет соответствующим образом ограничен (например, если сосредоточиться только на ключевых позициях). Они недавно перешли на облачные решения, которые, видимо, способны масштабироваться, но неясно, были ли основные алгоритмы переработаны для распределённых вычислений или просто перенесены на мощные виртуальные машины.
Недостатки подходов: Следует отметить изъян «in-memory дизайна». Несколько вендоров применили подход моделирования всей цепочки поставок в одной гигантской модели, размещённой в памяти (аналогично OLAP-кубу или огромной электронной таблице в оперативной памяти). Это обеспечивает высокую скорость для небольших и средних кейсов, но не масштабируется линейно – его сложно распределить, и увеличение объёма данных может привести к комбинаторному взрыву потребностей в памяти. Исследование вендоров Lokad чётко указывает на это для o9 и Relex: их дизайн «обеспечивает впечатляющую отчётность в режиме реального времени», но по своей природе увеличивает затраты на оборудование и плохо сочетается с задачами глобальной оптимизации ⁷. Аналогичным образом, собственные материалы Kinaxis косвенно признают ограничения: например, более ранняя документация Kinaxis отмечала, что 32-битные системы с ~4 ГБ ОЗУ были ограничивающим фактором, и хотя 64-битные системы позволяют больше, их возможности не безграничны ²¹. Основная проблема в том, что объёмы данных растут быстрее, чем возможности оперативной памяти. Если ритейлер хочет планировать на уровне магазин-SKU-день для 2 000 магазинов и 50 000 SKU, это составляет 100 миллионов временных рядов – in-memory куб такого размера (с историей и будущими периодами) может содержать десятки миллиардов ячеек, что является непрактичным. Распределённый подход, обрабатывающий данные по магазинам или с интеллектуальным разбиением, является более масштабируемым.
Параллелизм против пакетной обработки: Главное преимущество Kinaxis заключается в параллелизме (всё пересчитывается одновременно в памяти). Это отлично подходит для интерактивного использования, но означает, что полная модель должна быть доступна в памяти. Системы, ориентированные на пакетную обработку (например, ночной запуск Lokad или даже подход ToolsGroup), могут масштабироваться за счёт разделения задачи (например, прогнозирование для каждого SKU по отдельности, что является ярко выраженным параллелизмом). Например, Lokad’s Envision способен разбивать задачи на подзадачи, выполняющиеся параллельно в облаке – вы жертвуете возможностью интерактивного взаимодействия в реальном времени ради масштабируемости и сырой вычислительной мощности. В зависимости от бизнес-требований, тот или иной подход может быть предпочтительнее. Но если цель – получить максимально точный план, пакетный процесс, способный за ночь перебрать огромные пространства сценариев, может оказаться лучше упрощённого расчёта в реальном времени.

Вывод: Решения, такие как облачная платформа Lokad, созданы для горизонтального масштабирования и способны обрабатывать большие объемы данных без ограничения, тогда как решения, ориентированные на хранение в памяти (Kinaxis, o9, Relex, SAP) рискуют столкнуться с узкими местами масштабируемости и нарастающими затратами по мере усложнения данных. Компании, оценивающие эти решения, должны тщательно учитывать объём данных своей цепочки поставок и траекторию их роста. Примечательно, что некоторые новые стартапы в области планирования с использованием «ИИ» сознательно избегают in-memory монолитов, предпочитая микросервисы или фреймворки для работы с большими данными. Также стоит отметить, что настройка производительности часто ложится на команду внедрения – если вендор требует значительной агрегации или отсечения данных, чтобы модель помещалась в памяти, это является тревожным сигналом для масштабируемости. По-настоящему масштабируемые технологии способны обрабатывать детализированные данные, не вынуждая вас их упрощать.

Интеграция технологий и поглощения: Единые платформы против франкен-наборов

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

Blue Yonder (JDA) является одним из самых ярких примеров роста за счёт приобретений. За эти годы JDA приобрела Manugistics (для алгоритмов планирования цепочек поставок), i2 (хотя сделка сорвалась в 2008 году), Intactix (для планирования торговых площадей), RedPrairie (для управления складами) и стартап Blue Yonder (для прогнозирования с использованием AI/ML), среди прочего. Это означает, что нынешний набор решений Blue Yonder представляет собой мозаику: например, планирование спроса может осуществляться старым движком Manugistics, исполнение — чем-то иным, оптимизация цен поступила в результате другого приобретения и т.д. Исследование Lokad отмечало, что «корпоративное программное обеспечение не становится однородным посредством M&A… под брендом BY лежит случайная коллекция продуктов» ¹³. Они пытаются объединить их под платформой «Luminate» с единым интерфейсом и, возможно, общим слоем данных в Azure, но в глубине души собрать всё это в единый, гладко работающий механизм крайне сложно. Клиенты часто внедряют лишь отдельные компоненты, и чтобы они могли взаимодействовать, требуется индивидуальная интеграция. Несоответствия неизбежно возникают (например, один модуль может поддерживать вероятностную логику, а другой — нет; один использует один оптимизационный решатель, а другой — иной). Фрагментарная технологическая база также означает, что противоречивые практики могут сосуществовать в одном наборе решений (например, один модуль BY может рекламировать продвинутый ML, в то время как другой всё ещё использует формулы страхового запаса, созданные 20 лет назад).
SAP также сочетала собственную разработку и приобретения. В частности, SAP приобрела SAF (вендора прогнозирования) в 2009 году, SmartOps (вендора оптимизации запасов) в 2013 году ¹⁶, а ранее самостоятельно разработала APO. Всё это было интегрировано в облачное решение SAP Integrated Business Planning (IBP). В результате SAP IBP включает различные модули (Прогнозирование, Запасы, Поставка), которые, несмотря на нахождение под единым зонтиком, иногда ощущаются как отдельные продукты. Прогнозирование может использовать алгоритмы SAF, а оптимизация запасов – логику SmartOps. В обзоре коллеги называют набор решений SAP «коллекцией продуктов» и предупреждают, что сложность высока, часто требуя «лучших интеграторов – и нескольких лет – для достижения успеха» ²². Иными словами, интеграция оставляется на команду внедрения, и сборка всех компонентов в единое целое может оказаться длительным процессом.
Kinaxis, до недавнего времени, была в основном результатом органического развития – их основной продукт RapidResponse разрабатывался внутри компании на протяжении десятилетий. Это придало ему единый вид (одна модель данных, один пользовательский интерфейс). Однако за последние 3-4 года Kinaxis совершила несколько стратегических приобретений/партнерств для устранения пробелов: например, партнерство с Wahupa для вероятностной оптимизации запасов ¹⁷, приобретение Rubikloud для прогнозирования с помощью ИИ и приобретение Prana (поставщика аналитики в области цепей поставок) в 2021 году. Kinaxis интегрирует их через свою расширяемую платформу (они рекламируют «безкодовую» интеграцию через свой пользовательский интерфейс для этих новых возможностей), но, по сути, это отдельные движки, которые связываются. Например, MEIO от Wahupa может работать как сервис, прикрепленный к RapidResponse, а не как собственный код внутри него. Со временем Kinaxis, вероятно, объединит их более тесно, но всегда существует риск того, что это станет слабо связанным дополнением (например, вы подаете данные о вариативности прогноза на движок Wahupa и получаете уровни страховочных запасов – нечто дополнительное). По сравнению с поставщиками с десятками приобретений, Kinaxis остается относительно связной, но стоит следить за тем, чтобы она не пошла по пути «франкен-набора».
o9 Solutions в основном построена внутри компании своими основателями (бывшими сотрудниками i2). Это единая платформа с модулями, разработанными на одной основе. o9 приобрела очень мало (одно незначительное приобретение – компания, занимающаяся сетями цепей поставок, а недавнее – стартап в области ИИ/МО под названием Processium, но ничего существенного в алгоритмах планирования, насколько известно). Поэтому технологический стек o9 более унифицирован, чем у более старых конкурентов – всё построено на Enterprise Knowledge Graph от o9 и использует единый фреймворк UI. Это плюс для согласованности (нет дублирования схем баз данных и т.д.). Минус в том, что если какая-либо часть их технологий слаба, у них нет возможности легко исправить это через приобретение – им придется разрабатывать самостоятельно. Пока что им удается справляться внутренней разработкой, пусть и с оговорками, о которых мы говорили (например, возможно, за кулисами используются банальные методы прогнозирования).
ToolsGroup в значительной степени росла органически вокруг своего продукта SO99+. Насколько нам известно, они не осуществляли крупных приобретений других поставщиков решений для планирования. Таким образом, их модули прогнозирования спроса, оптимизации запасов и пополнения были разработаны совместно, что дает последовательное, хоть и несколько монолитное, приложение. Задача ToolsGroup заключалась в модернизации – их архитектура и интерфейс устарели к 2010-м годам, но с тех пор они предприняли шаги по переходу в облако и обновлению интерфейса. Тем не менее, связность – одна из причин, по которой ToolsGroup относительно понятна: она выполняет одну задачу (оптимизацию уровня сервиса) от начала до конца без необходимости подключения других инструментов.
Relex Solutions также создала свою платформу с нуля специально для розничной торговли. Они действительно приобрели несколько компаний в смежных областях (недавно – решения для управления персоналом и планирования торговых площадей), но их основной механизм прогнозирования и пополнения является собственным. Этот механизм единый (отсюда они могут, например, показывать любую метрику пользователю в реальном времени, поскольку все данные находятся в одной оперативной базе данных). Приобретения в новых направлениях могут создавать проблемы интеграции, но Relex все еще далека от шквального приобретения старых поставщиков.
Ключевая проблема фрагментированных наборов решений заключается не только в технических издержках, но и в функциональном несоответствии: если один модуль разработан для одного подхода (например, детерминированного планирования с учетом страховочных запасов), а другой модуль предполагает вероятностные входные данные, они могут конфликтовать. Например, модуль оптимизации запасов, приобретенный в рамках одной сделки, может рассчитывать уровни страховочных запасов, с которыми модуль планирования спроса из другого приобретения не справляется в своем интерфейсе, что приводит к путанице или дублированию данных. Действительно, мы наблюдали случаи, когда поставщики продвигают вероятностное прогнозирование в маркетинге, а их модуль планирования продаж и операций продолжает использовать MAPE и сводные прогнозы с одним числом – внутреннее противоречие, вероятно, возникающее из-за различных продуктовых линий.

In contrast, a vendor with a coherent platform can implement changes (like moving to probabilistic methods) across the board more easily. It’s telling that Lokad, which is fully unified (they built everything around their Envision language and cloud backend), can focus its message clearly on probabilistic optimization without internal inconsistency. Similarly, Anaplan (a general planning platform) is very unified technically (one Hyperblock engine), though it lacks specialized supply chain algorithms; Anaplan’s consistency is great, but its specialization is limited ²³.

Thus, from a technology perspective, buyers should be wary of suites born of many mergers – ask whether the forecasting piece and the planning piece truly share the same engine or data model. If not, the result may be integration pain and potentially contradictory outputs.

Техническая достоверность: Прорезая шумиху вокруг ИИ/МО

В эпоху, когда каждый поставщик заявляет о «цепочке поставок, управляемой ИИ» и «прогнозах с применением машинного обучения», крайне важно тщательно проверять, как они обосновывают эти заявления. Мы ищем конкретные технические доказательства использования передовых методов – такие как рецензируемые исследования, документированные проприетарные алгоритмы, вклад в open-source или показатели в нейтральных тестах. Мы также проверяем на неправильное использование модных слов – когда что-то называют ИИ, хотя на деле это просто конструкция if-else, например. Вот как обстоят дела у поставщиков:

Lokad демонстрирует высокую техническую достоверность. Она не просто заявляет об использовании ИИ; компания публикует материалы, объясняющие её алгоритмы (например, лекцию, подробно рассказывающую о том, как работала их модель прогнозирования, победившая конкурс M5 ²⁴). Генеральный директор и команда активно участвуют в технических обсуждениях (через блоги, лекции), объясняя, почему выбираются определенные подходы (например, ансамблирование квантильных прогнозов или использование pinball loss при обучении). Они также открыто признают ограничения таких конкурсов, как M5, и то, как реальные проблемы цепей поставок отличаются ²⁵ ²⁶ – эта детальность указывает на серьезный инженерный подход, а не на маркетинговую болтовню. Кроме того, основное новшество Lokad, язык программирования Envision, является уникальным техническим артефактом – это не просто универсальный ML, а предметно-специфичный язык, созданный для оптимизации цепей поставок ²⁷. Это конкретная технологическая разработка, которую могут оценить посторонние (а некоторые части задокументированы публично). Lokad не опирается на платные цитаты аналитиков; вместо этого, она приглашает к рецензированию своих методов. Такая открытость и акцент на науке вместо слоганов задают золотой стандарт достоверности.
Blue Yonder, с другой стороны, склонна использовать нечеткий язык в отношении ИИ, например, «интегрируя ИИ/МО в нашу платформу Luminate», не уточняя, какие техники или модели применяются. Исследование Lokad прямо указывает, что утверждения Blue Yonder об ИИ имеют «мало или вовсе не имеют содержания», а несколько доступных материалов свидетельствуют о применении старомодных методов прогнозирования (ARMA, регрессия) ¹⁴. Например, BY может заявлять «мы используем ИИ для обнаружения сдвигов в спросе», но если на деле используется линейная регрессия по недавним продажам (техника десятков лет назад), то это растягивает понятие ИИ. Наличие проектов с открытым исходным кодом, таких как tsfresh (извлечение признаков из временных рядов), является плюсом для прозрачности BY, но сами проекты являются хорошо известными универсальными инструментами, а не проприетарными прорывными разработками. Отсутствие опубликованных результатов или участия в конкурсах со стороны команд data science BY дополнительно намекает на то, что их заявления больше продиктованы маркетингом. Короче говоря, Blue Yonder не предоставила убедительных технических доказательств для поддержки своего агрессивного позиционирования в ИИ – что является тревожным знаком в оценке достоверности.
o9 Solutions также вызывает скептицизм. Они продвигают концепцию Enterprise Knowledge Graph (EKG) как отличительную особенность, намекая, что это форма ИИ, выявляющая взаимосвязи в данных. Хотя графовые базы данных полезны, нет ничего по своей сути «гениального» в хранении данных в виде графа – важны алгоритмы, работающие поверх. Исследование Lokad отмечает, что заявления o9 о прогнозировании на основе графа не подтверждаются научной литературой ²⁸. Более того, GitHub o9 (если копнуть глубже) не выявил революционных алгоритмов, и их рассказы об ИИ часто сводятся к общим возможностям (например, «продвинутая аналитика» или «прогнозирование с МЛ»), имеющимся у многих. Они используют модные термины («цифровой мозг», «ИИ/МО», «knowledge graph»), но без внешней валидации. Пока o9 не опубликует, скажем, техническую статью о том, как их ML-модели превосходят конкурентов, или пока не появится кейс с детальными данными, лучше считать, что ИИ от o9 в основном – шумиха – возможно, стандартные МЛ-модели (нейронные сети, градиентный бустинг и т.д.) в обертке хорошего маркетинга. Мы также отмечаем, что в сообществе цепей поставок действительно прорывные концепции ИИ (например, глубокое обучение с подкреплением для оптимизации или новые вероятностные модели) обычно обсуждаются в академических или открытых форумах – мы не увидели, чтобы o9 выступали в таких рамках, что указывает на отсутствие уникальных технологий.
Kinaxis в своём маркетинге была относительно сдержанной – они не перегружают каждое предложение термином «ИИ», что отчасти хорошо (меньше завышенных ожиданий). Однако по мере интеграции партнёров по ИИ, они стали выделять его больше. Один хороший знак: блог-пост, написанный совместно с генеральным директором Wahupa ²⁹ ³⁰, в котором обсуждаются вероятностные против статистических методов, показывает, что Kinaxis готова углубляться в науку (упоминая теорию вероятностей, принятие решений в условиях неопределенности и т.д.). Это указывает на попытку обосновать их предложения на прочной методологии. Но Kinaxis всё ещё должна доказать эффективность этих методов. Например, они не опубликовали детальный отчет в виде «наш новый ML-прогнозирование улучшило точность на X% по сравнению с нашим старым подходом» – вероятно, потому что интеграция всё ещё продолжается. Таким образом, достоверность Kinaxis находится в переходном состоянии: исторически они не заявляли себя как технологический лидер в области прогнозирования (и поэтому не вводили в заблуждение), а теперь, когда они утверждают, что используют продвинутую аналитику, нам придется ждать доказательств. Партнерство с Wahupa, по крайней мере, демонстрирует признание того, что было необходимо внешнее экспертное мнение – что заслуживает доверия (они не притворялись, что полностью освоили вероятностные методы; они пригласили специалиста).
ToolsGroup, к сожалению, подорвала свою достоверность, присоединившись к модному тренду ИИ без должных доказательств. Комментарий исследования о том, что их заявления об ИИ являются «сомнительными» и что публичные материалы до сих пор намекают на модели до 2000 года, говорит о многом ¹⁰. Это предполагает, что ToolsGroup, возможно, делает мало больше, чем переименовывает существующие функции под названием «ИИ». Например, ToolsGroup может рекламировать «ИИ для определения спроса» – а при проверке это может оказаться просто правилом, придающим больший вес недавним продажам (а не настоящим ИИ, а лишь алгоритмической настройкой). Без опубликованных подробностей трудно дать им преимущество сомнения. Их достоверность была выше в начале 2000-х, когда они действительно опережали конкурентов в вероятностных моделях оптимизации запасов; теперь она страдает от возможной стагнации.
SAS (которую мы не оценили как лучшую, но она входит в состав) является примером, когда техническая достоверность в целом высока (SAS имеет долгую историю в статистике), но их базовые технологии устарели. Методы прогнозирования SAS хорошо задокументированы (они буквально написали учебник по многим статистическим методам), но это также означает, что они могут не включать последние методы машинного обучения, если не проводить индивидуальную настройку в SAS. Исследование Lokad признаёт SAS пионером, хотя теперь её обогнали такие инструменты с открытым исходным кодом, как Python notebooks ³¹. SAS обычно не преувеличивает свои возможности – они полагаются на свою репутацию – но как решение для цепей поставок, их реже используют «из коробки» (чаще компания задействует SAS для создания индивидуального решения).
Общее наблюдение: Быстрый способ проверить техническую искренность поставщика – посмотреть, признают ли они иногда ограничения или подходящие сценарии применения своих технологий. Поставщики, увлеченные маркетингом, заявят, что их ИИ решает всё. Те, кто действительно обладает технологиями, скажут: «вот что оно делает и вот где может работать не так эффективно». Например, Lokad часто обсуждает, как определенные модели не работают для некоторых типов спроса (например, почему некоторые подходы проваливаются при прерывистом спросе и т.д.), что демонстрирует интеллектуальную честность ²⁶ ³². Мы нашли лишь немногих поставщиков, кроме Lokad, готовых вести столь детальную публичную дискуссию. Большинство остальных придерживаются расплывчатых общих формулировок, что должно насторожить искушенного клиента.

В заключение, конкретные доказательства технической мощи – такие как результаты конкурсов, подробные технические блоги или даже обсуждения в сообществах пользователей – встречаются редко у многих известных поставщиков. Lokad лидирует в представлении доказательств (победа в M5, открытые объяснения). Другие, такие как Blue Yonder и o9, предлагают шумиху с намёками на устаревшие технологии, что ставит под сомнение их заявленную «революцию в ИИ» ¹⁵. Потенциальный покупатель должен требовать от поставщиков объяснения конкретными терминами, как работают их алгоритмы и почему они лучше – и быть осторожным, если ответ сводится лишь к маркетинговой болтовне. Истинную ценность ИИ/МО в цепях поставок можно продемонстрировать (например, «мы используем методы градиентного бустинга деревьев для выявления нелинейных факторов спроса, таких как погода, и доказали 5%-ное улучшение по сравнению с базовым уровнем для 1000 SKU» – такое утверждение убедительнее, чем «наш ИИ находит скрытые закономерности в ваших данных»).

Последовательность и противоречия в подходах поставщиков

A яркий признак поверхностных инноваций – когда в сообщениях или методологии поставщика присутствуют внутренние противоречия. Мы искали такие противоречия – например, проповедь неопределенности, но измерение успеха детерминированными метриками, или утверждения об устранении старых практик, при этом продолжая их использовать «под капотом». Некоторые примечательные наблюдения:

Вероятностные против детерминированных метрик: Как уже упоминалось, ToolsGroup виновна в этом – они рекламируют возможность вероятностного прогнозирования, но демонстрируют результаты в терминах снижения MAPE (средней абсолютной процентной ошибки) ¹². MAPE является метрикой ошибки точечного прогноза; если вы действительно используете вероятностное прогнозирование, вы бы говорили о калибровке, вероятностном логарифмическом правдоподобии, pinball loss (для квантилей) или, по крайней мере, о достигнутом уровне сервиса. Придерживаясь MAPE, ToolsGroup фактически противоречит своей вероятностной концепции. Это несоответствие говорит о том, что либо их «вероятностный» выход является лишь преобразованным детерминированным прогнозом, либо это маркетинговое наложение, которое не поддерживается глубоко в их R&D.
Ажиотаж вокруг demand sensing: Многие поставщики используют термин «demand sensing» для того, чтобы подразумевать, что у них есть специальный краткосрочный прогноз, который фиксирует последние тенденции (например, с использованием очень недавних продаж или внешних сигналов). ToolsGroup, SAP и GAINSystems – все использовали этот термин. Исследование отмечает, что заявления о «demand sensing» зачастую являются «vaporware», не подтверждёнными литературными данными ³³. Если поставщик утверждает «наш ИИ предвидит изменения спроса на 3 месяца вперёд», но не может объяснить, как именно (и никакие рецензируемые исследования не подтверждают, что такое вообще возможно надёжно), это является красным флагом. Противоречие возникает, когда тот же поставщик всё ещё использует базовую модель временных рядов. По сути, они берут стандартный прогноз с экспоненциальным сглаживанием, затем добавляют поправку за последнюю неделю и называют это «сенсинг». Противоречие: представляют незначительную доработку как прорыв.
Использование детерминированных KPI: Обратите внимание, если кейс-стади или интерфейс поставщика всё ещё вращаются вокруг детерминированных KPI, таких как MAPE, смещение или сигналы отслеживания, даже если они утверждают, что всё основано на ИИ/МЛ. Например, если поставщик хвалит машинное обучение, но их демо показывает, как планировщики работают над улучшением MAPE прогноза или используют сегментацию по ABC для установки страховых запасов, это противоречиво. Истинное планирование, основанное на ML и вероятностном подходе, сместило бы фокус на такие показатели, как ожидаемые затраты, вероятность нехватки запасов или другие стохастические меры – а не на традиционные показатели MAPE или классификации по ABC (которые предполагают предсказуемую, статичную категоризацию спроса). Мы наблюдали такое раздвоение личности в некоторых руководствах крупных поставщиков: одна глава рассказывает о новом модуле ИИ, а другая всё ещё инструктирует пользователя по настройке параметров ARIMA или правил страховых запасов.
Философия страховых запасов: Значительное философское противоречие заключается в том, что поставщики, говорящие об управлении неопределённостью, всё же сосредотачивают свой процесс на «страховом запасе». Понятие страхового запаса основано на детерминированном прогнозе плюс резерв. В полностью вероятностной модели вместо этого рассчитывается оптимальный уровень запасов напрямую, исходя из распределения спроса и целей обслуживания (что фактически объединяет «базовый» и «страховой» в одно решение). Если поставщик говорит «мы оптимизируем запасы с помощью ИИ», спросите, требует ли он от пользователя ввода «желаемого уровня обслуживания» для расчёта страхового запаса по нормальному распределению. Если да, то на самом деле ничего не изменилось – они просто переодевают старый расчёт страхового запаса в новую формулировку. Например, оптимизация запасов в Blue Yonder (исторически) рассчитывала страховой запас на основе дисперсии и целевых показателей сервиса – это не по сути вероятностная оптимизация; это применение формулы. Поставщики, такие как Lokad, явно отвергают термин «страховой запас» как устаревший, поскольку в настоящей стохастической оптимизации весь запас рассматривается как обслуживающий распределение спроса, а не только та его часть, которая обозначена как «страховой». Таким образом, если поставщик рекламирует «планирование следующего поколения», но их руководство по решению требует поддержания настроек страхового запаса, это свидетельствует о проблеме последовательности.
Волшебство ИИ против контроля пользователя: Некоторые поставщики одновременно утверждают «наш ИИ будет автономно управлять вашей цепочкой поставок» и «мы предоставляем пользователям полный контроль и прозрачность процесса планирования». Необходимо найти баланс, но чрезмерно широкие утверждения могут противоречить друг другу. Если ИИ действительно автономен, пользователю не нужно постоянно за ним следить; если же пользователь должен постоянно вмешиваться, то система не является по-настоящему автономной. Маркетинг часто обещает и то, и другое («автопилот И ручное вмешательство!»), но на практике решение, как правило, склоняется в ту или иную сторону. Мы не указываем конкретного поставщика, однако заметили общие обещания полной автоматизации, сопровождаемые скриншотами с десятками параметров планирования, которые пользователи обязаны настроить – сигнал смешанных посланий.

В нашем исследовании один яркий пример преодоления противоречий – это то, как Lokad позиционирует себя в отличие от мейнстрима. Lokad открыто критикует такие показатели, как MAPE, и концепции вроде страхового запаса в своем образовательном контенте, выстраивая свою методологию соответствующим образом (с использованием вероятностных метрик и прямым вычислением решений) ¹² ³². В отличие от этого, поставщики вроде GAINSystems заявляют, что ориентированы на оптимизацию, но всё же выделяют такие вещи, как demand sensing и алгоритмы сопоставления, которые относятся к более ранним эпохам ³³ – фактически пытаясь ехать одновременно и на двух лошадях. John Galt Solutions утверждает, что их запатентованный алгоритм прогнозирования превосходит все остальные, однако он отсутствует в независимых рейтингах и, вероятно, не лучше, чем open-source согласно рецензиям ¹⁹, что является противоречием между заявлением и доказательствами.

Чтобы подвести итог, при оценке поставщиков важно проверять внутреннюю последовательность: практикуют ли они то, что проповедуют? Если поставщик много говорит об управлении неопределённостью и оптимизации, их материалы не должны одновременно превозносить детерминированные метрики или упрощённые методы. Несоответствия зачастую указывают на то, что «новая концепция» носит лишь поверхностный характер.

Устаревшие практики: признаки устаревшего планирования

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

Страховой запас как костыль: Как уже обсуждалось, использование страхового запаса как отдельной подушки, добавляемой к прогнозу, является устаревшим подходом. Дело не в том, что страховой запас «плох» – для вариативности всегда нужен резерв – однако современные методы включают вариативность напрямую. Если основной метод поставщика – «прогнозирование с использованием сглаживания, затем расчёт страхового запаса = z-оценка * сигма * sqrt(lead-time)», то это теория 1960-х, которая всё ещё используется. Slimstock’s Slim4, например, с гордостью применяет такие мейнстримные формулы (страховой запас, EOQ) и открыто об этом заявляет ³⁴. Slimstock по правде получает признание за честность: он фокусируется на «обычных, но критически важных практических вопросах», а не на притворстве использования ИИ ³⁵. Но с точки зрения технологического лидерства такие практики устарели. Lokad и Wahupa (партнёр Kinaxis) выступают за переход к прямому вычислению оптимальных точек/количеств заказа на основе вероятностных моделей, исключая искусственное разделение «текущих запасов и страхового запаса». Многие устаревшие системы (SAP, Oracle, старые JDA) всё ещё зависят от параметров страхового запаса. Это тревожный сигнал, что их базовая математика почти не изменилась. По-настоящему оптимизационно ориентированная система позволила бы вводить стоимость хранения запасов по сравнению со стоимостью нехватки и затем находить оптимальную политику – никогда не называя что-либо явно «страховым запасом», а просто выдавая оптимальный уровень запаса для каждого товара.
MAPE и детерминированные метрики: Фокусировка на MAPE, смещении и подобном в качестве основного показателя успеха может считаться устаревшей, поскольку эти метрики не коррелируют напрямую с бизнес-результатами (например, может быть низкий MAPE, но низкий уровень обслуживания) и игнорируют неопределённость. Более современные подходы отдают предпочтение метрикам, таким как pinball loss (квантильный убыток) для прогнозов или ожидаемым затратным метрикам для планирования. Если в кейс-стади поставщика критерий успеха звучит как «мы повысили точность прогноза с 70% до 80% по MAPE», то они несколько застряли в прошлом. Акцент John Galt’s на точности прогноза также относится к этому (и подвергся критике со стороны коллег) ¹⁹. Современный подход мог бы звучать как «мы сократили нехватку запасов на X% или запасы на Y% при том же уровне обслуживания» – это ориентированность на результаты, а не просто на MAPE.
Эвристическая сегментация (ABC, XYZ): Более ранние процессы планирования часто сегментируют товары по объёму (ABC) или вариабельности (XYZ) и применяют различные параметры планирования для каждой группы. Это эвристика, используемая для преодоления ограничений вычислительной мощности или упрощённых моделей – когда к товарам класса A применяют один метод (возможно, с большей ручной настройкой), а к товарам класса C – другой (например, правила min-max). Хотя сегментация по-прежнему может быть полезна, она становится несколько устаревшей, если имеется возможность оптимизировать каждый SKU индивидуально и непрерывно. Система, которая делает сильный акцент на ручной классификации по ABC или требует, чтобы вы классифицировали спрос как «неровный против плавного» и т.д., может использовать это как костыль из-за отсутствия алгоритмов, способных автоматически эффективно обрабатывать различные паттерны спроса. Многие устаревшие системы (а иногда и новые) всё ещё так работают. В идеале система на базе ИИ автоматически изучала бы шаблон для каждого SKU и не требовала участия человека в классификации.
Ручное корректирование прогнозов как правило: Традиционное планирование спроса предполагает, что пользователи регулярно корректируют статистические прогнозы на основе суждений (маркетинговой информации и т.д.). Хотя вклад человека ценен, если точность системы настолько низка, что планировщикам приходится пересматривать многие прогнозы каждый цикл, такая система по сути является устаревшей. Современные системы стремятся свести корректировки к минимуму, используя больше данных (так что модель уже «знает», что маркетинг проводит акцию, например). Если поставщик продолжает подчеркивать, как легко пользователям вручную корректировать прогнозы, это может указывать на то, что его алгоритм не заслуживает доверия «прямо из коробки». Тенденция – корректировки лишь на основе исключений.
Зависимость от таблиц: Если вы обнаружите, что решение поставщика часто вынуждает пользователей экспортировать данные в Excel для окончательного анализа или использовать Excel в качестве интерфейса (как это делают некоторые инструменты среднего рынка), это признак незрелого решения. Передовые инструменты предоставляют всю необходимую аналитику и поддержку принятия решений непосредственно на платформе. (Anaplan интересен в этом отношении: по сути, это облачная таблица с усиленными возможностями, то есть, с одной стороны, он придерживается парадигмы таблиц, но в контролируемой, многопользовательской среде – одновременно современный и старомодный подход).

По собранным данным: Slimstock намеренно использует старые, но проверенные методы (страховой запас, EOQ) ³⁴ – они открыто заявляют об этом, что заслуживает похвалы, но эти методы можно считать устаревшими на фоне вероятностной оптимизации. GAINSystems (менее известный, но давно существующий поставщик) также, по всей видимости, придерживается классических моделей прогнозирования, и даже их заявленные возможности ML (например, «matching and clustering») являются техниками до 2000 года ³³, что указывает на отсутствие значительных нововведений. Обзор Lokad на GAINSystems явно называет их vaporware, что свидетельствует о том, что они считают эти методы устаревшими или неэффективными на практике ³³.

Blue Yonder и SAP несут в себе много наследия – например, стандартная настройка SAP во многих внедрениях до сих пор использует ABC для установления различных уровней страхового запаса или применяет простые скользящие средние для прогнозирования малых значений. Если их новое «IBP с машинным обучением» не пересматривает эти основы, то по сути это винтажное наследие в новой упаковке. Наличие противоречивых метрик (например, заявления об инновациях при использовании MAPE) мы уже обозначали как несоответствие, но это также свидетельствует о приверженности устаревшим метрикам. В заключение, если компания ищет самое передовое решение, она должна быть осторожна с любым поставщиком, чье решение всё ещё вращается вокруг параметров страхового запаса, правил сегментации ABC и точности прогноза в процентах в качестве основного KPI. Это признаки того, что решение основано на практиках прошлого века. Вместо этого следует искать поставщиков, которые делают акцент на уровнях обслуживания, затратах и вероятностях – языке современной науки о цепочке поставок.

Прогнозирование, ориентированное на принятие решений: от предсказаний к действиям

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

Lokad ориентирован на принятие решений в высшей степени. Фактически, они зачастую умаляют важность самого прогноза, настаивая на том, что важнее решение (имплицитная философия: «прогноз хорош только если приводит к хорошему решению»). Используя Lokad’s Envision, процесс не ограничивается прогнозированием спроса; типичный рабочий процесс Lokad вычисляет, например, ожидаемую прибыль или штраф для различных вариантов решений (например, заказ 100 единиц против 200 единиц) на основе вероятностного прогноза, а затем выбирает решение, максимально повышающее ожидаемый результат. Выходной результат для пользователя не «спрос будет 120», а «закажите 130 единиц» (например), вместе с обоснованием (например, это количество уравновешивает риск нехватки запасов и избытка с учётом распределения прогноза и ваших затрат). Это и есть настоящая предписывающая или ориентированная на решение аналитика. Таким образом, Lokad обеспечивает, чтобы прогноз напрямую переходил к выполнению. Он даже учитывает ограничения (такие как минимальные объемы заказа, срок годности, бюджетные лимиты) при оптимизации. Так что Lokad явно соответствует требованиям по превращению предсказаний в действия.
ToolsGroup также ориентирован на принятие решений, в частности для решений по запасам и пополнению. Его инструмент SO99+ не просто прогнозирует; он рекомендует уровни запасов и точки пере-заказа, позволяющие достичь целевых уровней обслуживания. На практике, реализация ToolsGroup для каждого SKU выдаёт: «вам следует держать X единиц страхового запаса и делать заказ, когда запасы падают до Y, что означает заказ Z единиц прямо сейчас». Это решение (количество для пополнения), выведенное из прогноза. Таким образом, ToolsGroup всегда был ориентирован не только на прогнозирование, но и на предписывающий вывод. Ограничение заключается в типе решения: в основном, оно касается политики запасов (у них имеется и оптимизация планирования производства, но их сильная сторона – распределение). Также рекомендации ToolsGroup хороши лишь настолько, насколько качественно смоделирована неопределённость прогноза (что нами и критиковалось). Следует отдать должное тому, что ToolsGroup не ожидает, что пользователь возьмет прогноз и затем вручную примет решение о заказе; он автоматизирует этот расчёт.
Blue Yonder и другие устаревшие комплексы часто разделяют прогнозирование и планирование. Например, BY Demand даёт прогноз, затем BY Supply (или Fulfillment) берёт этот прогноз и рассчитывает планы. В интегрированной реализации, да, конечный результат — рекомендация по принятию решения (например, главный производственный график или план развертывания). Blue Yonder действительно предлагает модули полной оптимизации планирования – например, их модуль Fulfillment порекомендует, как пополнить запасы распределительных центров из центрального склада (это фактически система DRP, которая использует прогноз и данные о текущих запасах для создания плановых заказов). Их модуль Production planning может создать оптимизированную последовательность производства или график. Таким образом, BY как комплекс охватывает принятие решений, но насколько оптимальны или интегрированы эти решения, зависит от того, реализованы ли все компоненты и настроены ли они. Исторически критикой было то, что результаты одного модуля не всегда были оптимальными для следующего (например, если прогноз не учитывает ограничения, с которыми столкнется планирование поставок, получаются невыполнимые планы). Подход, ориентированный на принятие решений, действительно учитывал бы эти ограничения при прогнозировании или в объединённой оптимизации. Новое сообщение Blue Yonder о “автономной цепочке поставок” подразумевает, что они хотят замкнуть цикл (прогноз -> решение автоматически), но с учётом смешения технологий, неясно, насколько это плавно.
Kinaxis ориентирован в первую очередь на принятие решений/выход, в том смысле, что его основная цель — быстро генерировать действенные планы (планы поставок, прогнозы запасов и т.д.). Пользователь обычно работает с этими планами и может подтверждать или корректировать решения (например, ускоряя заказ или перераспределяя поставки). С новым дополнением MEIO от Kinaxis теперь явно оптимизируется один набор решений: буферы запасов (то есть Kinaxis теперь может рекомендовать уровни страховых запасов, уравновешивая затраты и уровень обслуживания ³⁶). Ранее Kinaxis позволял вам моделировать различные уровни страховых запасов и видеть результаты, но не обязательно указывал на лучший вариант; с вероятностным MEIO он пытается математически найти оптимальное решение. Для других областей (например, производства и планирования распределения) Kinaxis использует эвристику или оптимизацию «под капотом» (в нём есть несколько оптимизационных решателей для составления графиков и распределения) — но большая часть мощности Kinaxis заключается в симуляции, а не в жёсткой оптимизации. То есть, он может очень быстро смоделировать результат пользовательского решения, но часто оставляет выбор сценария за человеком. В общем, Kinaxis создаёт полный набор рекомендованных действий (как плановые заказы, перепланировки) практически в реальном времени — определённо поддержка принятия решений — но не всегда автоматически выбирает «оптимальный» план без участия человека, за исключением специальных функций, как MEIO, или когда план очевиден (например, он детерминированно перенесёт спрос в требования к поставкам).
o9 Solutions также направлена на создание планов (наборов решений) в области спроса, поставок, запасов и т.д. У o9 есть оптимизационные движки для определённых задач – например, планирование поставок с использованием линейного программирования для минимизации затрат или максимизации прибыли при заданных ограничениях. Это часть их концепции «цифровой мозг», которая предполагает нахождение оптимального распределения ресурсов. Однако не каждый клиент o9 использует её оптимизированным образом; некоторые могут просто использовать её платформу для совместного планирования (что фактически может быть ручным принятием решений, но с лучшей видимостью данных). Вопрос в том, поддерживает ли o9 нативно вероятностную оптимизацию решений? Вероятно, не в полной мере; она может проводить анализ сценариев («если мы произведём на 10% больше, каков будет результат?»), но не обязательно вычислять ожидаемое значение по сценариям. Таким образом, ориентирована на принятие решений (она предоставляет рекомендованные планы цепочки поставок), но оптимальность при неопределённости — неочевидна.
Relex Solutions, будучи ориентированным на розничную торговлю, в первую очередь выдаёт заказы для магазина или распределительного центра и целевые показатели запасов. Relex отлично справляется с прямым формированием этих решений (он фактически работает как автоматизированная система пополнения запасов, исходя из прогноза и параметров). Он также может оптимизировать такие задачи, как распределение полочного пространства против запасов (с помощью своего нового подхода объединённого планирования и планирования пространства), что является компромиссом принятия решений, уникальным для розничной торговли (например, если пространство ограничено, как сбалансировать запасы и ассортимент). Решения Relex в основном основаны на правилах, заданных пользователем (например, целевые уровни обслуживания или количество дней с запасами), но система выполняет расчёты, чтобы сформировать фактические заказы, соответствующие этим правилам. Определённо, она ориентирована на принятие решений (она не просто говорит «прогноз на эту неделю — 100 единиц» — она говорит розничному торговцу: закажите 50 дополнительных единиц прямо сейчас, потому что текущий запас составляет 50, прогноз — 100, а время поставки таково и так далее). Если что, Relex может склоняться к слишком тактическому подходу (он закажет с надлежащей регулярностью, но, возможно, не учтёт долгосрочные сетевые последствия — каждый узел оптимизирован локально исходя из уровня обслуживания).

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

Lokad и ToolsGroup явно связывают прогнозы с решениями, используя цели по затратам/обслуживанию (Lokad через свои пользовательские скрипты, оптимизирующие ожидаемые затраты, ToolsGroup через целевые уровни обслуживания, приводящие к решениям по запасам).
Kinaxis и o9 создают комплексные планы и позволяют изучать решения, при этом Kinaxis недавно добавил более формальную оптимизацию (оптимизация запасов и т.д.).
Blue Yonder имеет отдельные модули оптимизации, которые могут генерировать решения (если использовать их полностью, можно получить план для всего – но их согласование требует усилий).
Relex очень хорошо автоматизирует определённый набор решений (пополнение запасов), а в других, таких как долгосрочное планирование мощности, — менее эффективно.

При оценке решений компании должны настаивать на следующем: «После того как ваша система выдаст прогноз, какие решения она порекомендует, и как она гарантирует, что эти решения являются лучшими?» Если поставщик не может дать чёткий ответ или кажется, что пользователь останется интерпретировать прогнозы вручную, такой поставщик, вероятно, не действительно ориентирован на оптимизацию. Этот вопрос выявляет, например, будет ли шикарный прогноз на основе машинного обучения фактически способствовать снижению запасов или останется просто красивой цифрой на графике.

Заключение

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

Lokad вышел в лидеры благодаря своим передовым достижениям в вероятностном прогнозировании и радикальной ориентации на оптимизацию решений — качествам, подтверждённым внешними бенчмарками (например, победой в соревновании M5) и прозрачным техническим общением ³ ². Это демонстрирует, как скептицизм по отношению к мейнстрим-подходам (например, сомнения относительно ценности таких метрик, как MAPE или концепций страховых запасов) может привести к более надёжному решению, соответствующему основам экономики ¹² ³².

Другие поставщики, такие как Kinaxis и o9 Solutions, активно инвестируют в AI/ML и создали впечатляюще широкие платформы, но им всё ещё нужно убедить рынок в том, что их «AI» представляет собой нечто большее, чем только поверхностная технология, и что их архитектуры будут масштабироваться без непомерных затрат ⁴. Долговременные игроки, такие как Blue Yonder (JDA) и SAP, обладают богатым опытом и функционалом в сфере цепочки поставок, однако их наследие (фрагментированные системы из многочисленных поглощений и устаревшие алгоритмы) проявляется, что приводит к противоречиям и более медленному прогрессу в технологических инновациях ¹³ ¹⁶. Специалисты нишевого сегмента, такие как ToolsGroup и Relex, предлагают мощные решения в своих областях (оптимизация запасов и пополнение запасов в рознице соответственно), но у каждого есть свои ограничения — ToolsGroup нужно подкреплять свои заявления об AI более современной технологией ¹⁰, а in-memory подход Relex может оказаться неэффективным за пределами его зоны оптимальности ⁷.

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

Кроме того, по мере роста сложности цепочки поставок, масштабируемость и автоматизация — это не просто желательные функции, а необходимость. Решения, застрявшие в ручных, Excel-ориентированных практиках или не способные обрабатывать большие данные без использования колоссального оборудования, в долгосрочной перспективе не подойдут предприятиям. Скептицизм исследования по отношению к универсальным in-memory архитектурам подтверждается данными — более распределённые, облачные подходы демонстрируют преимущества как по затратам, так и по возможностям.

Наконец, окончательным эталоном для любого программного обеспечения по оптимизации цепочки поставок являются результаты, которые оно даёт: снижение затрат на запасы, повышение уровня обслуживания, более быстрая реакция и более эффективные рабочие процессы планировщиков. Достижение этого требует не только умных математических расчётов — это требует интеграции этих расчётов в единый, автоматизированный процесс принятия решений, соответствующий бизнес-реалиям. Лучшие поставщики — это те, кто замыкает цикл между прогноз -> оптимизация -> решение -> результат прозрачным и научно обоснованным способом. Те, кто застревают на разрозненных циклах (прогнозирование в изоляции или правила принятия решений, оторванные от неопределенности), остаются позади.

В заключение, компании, оценивающие решения для планирования цепочки поставок, должны тщательно, с технической точки зрения, анализировать каждого претендента. Прорвитесь сквозь блестящие брошюры и задайте те сложные вопросы, которые мы рассмотрели: Предоставляет ли поставщик вероятностные прогнозы или только отдельные цифры? Может ли их система работать автономно и доказана ли её масштабируемость? Является ли технология единой или представляет собой набор устаревших компонентов? Объясняют ли они свой «AI» понятными, фактическими терминами? Настаивая на таком уровне строгости, можно определить настоящих технологических лидеров в области оптимизации цепочки поставок — тех, кто способен принимать превосходные решения, а не просто создавать красивые информационные панели. Рейтинги и анализ, приведённые здесь, служат отправной точкой, определяя Lokad, Kinaxis, o9, Relex, ToolsGroup и Blue Yonder (среди прочих) в качестве ключевых игроков, каждый из которых имеет свои сильные стороны и ограничения. Ответственность за подтверждение своих заявлений лежит на поставщиках, а на пользователях — оставаться здорово скептичными и руководствоваться доказательствами при выборе «мозга», который будет управлять их цепочкой поставок.