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

By Léon Levinas-Ménard

Last modified: 2 февраля 2025

Рейтинг поставщиков и обзор (основанный на технической строгости)

Lokad – Высшая техническая надежность. Lokad выделяется своей прозрачностью и глубокой технической экспертизой. Он стал пионером вероятностного прогнозирования и доказал эффективность своих методов в открытом соревновании (заняв место #1 на уровне SKU и #6 в общем зачёте из 909 команд в конкурсе по точности прогнозирования M5 ¹ – единственная команда, возглавляемая поставщиком, оказавшаяся в топе). Lokad публикует подробные материалы о своей архитектуре (например, специализированный язык программирования Envision, облачная автоматизация) и делает акцент на финансово оптимизированных решениях вместо упрощённых показателей. Его ориентация на строгие математические методы (квантильные прогнозы, стохастическая оптимизация) и полностью скриптоспособные, автоматизированные рабочие процессы (через API и программирование) демонстрирует инженерный подход в разработке. Никакие грандиозные утверждения об ИИ/МЛ не озвучиваются без доказательств – напротив, Lokad предоставляет технические аналитические материалы и даже инструменты с открытым исходным кодом для масштабирования данных за пределы возможностей RAM ² ³. Такой уровень открытости и проверенной производительности ставит Lokad на первое место.
Anaplan – Платформа «Excel 2.0». Anaplan по сути является корпоративной версией электронной таблицы с моделью SaaS, работающей на базе проприетарного in-memory-движка Hyperblock ⁴. Технически говоря, Hyperblock – это надёжный многомерный расчётный движок, который позволяет тысячам пользователей совместно работать над моделями планирования в режиме реального времени – подобно суперзаряженному облачному Excel. Хотя Anaplan не является специализированным оптимизатором цепочки поставок (прогнозирование и алгоритмическая оптимизация на этой платформе выступают в роли «второстепенных» функций ⁵), его сильная сторона заключается в прочной архитектуре для моделирования и сценарного планирования. Он не предлагает мистический ИИ; вместо этого предоставляет надёжную, высокопроизводительную среду для создания индивидуальной логики планирования. Короче говоря, это мощный универсальный инструмент для планирования с честным подходом – никаких преувеличенных заявлений о магии прогнозирования, а лишь хорошо сконструированная, масштабируемая система, напоминающая электронную таблицу. Такой прямолинейный технический подход заслуживает у Anaplan высокую оценку по надёжности.
Kinaxis (RapidResponse) – Движок симуляции в оперативной памяти. Kinaxis известен своим уникальным движком параллельной обработки, который позволяет пересчитывать планы поставок в реальном времени по всей организации. Технически Kinaxis разработал собственный движок базы данных с нуля для поддержки этой функции ⁶ ⁷. Результатом стала платформа, оптимизированная для быстрых симуляций «что если»: пользователи могут ветвить сценарии (как Git для данных) и получать мгновенную обратную связь о влиянии изменений ⁸. Система хранит все данные цепочки поставок в оперативной памяти для обеспечения скорости, при этом алгоритмы имеют прямой доступ к данным для максимальной пропускной способности ⁹. Такой дизайн позволяет реализовать истинное одновременное планирование (например, планы продаж, производства и запасов, обновляемые в режиме реального времени одновременно). С инженерной точки зрения, создание специализированного хранилища данных с управлением версиями в оперативной памяти является впечатляющим достижением, обеспечивающим гибкость. Недостатком же является высокая аппаратная требовательность – полностью in-memory подход означает, что масштабирование до огромных объёмов данных может оказаться дорогостоящим (по мере роста требований к RAM) ¹⁰. В целом Kinaxis демонстрирует высокую техническую строгость в архитектуре и производительности, избегая модных заявлений об ИИ.
SAS – Статистическая мощь. SAS – это опытная фирма по разработке аналитического программного обеспечения (основана в 1976 году), которая предоставляет внушительный движок статистического моделирования для решения проблем цепочки поставок. В её флагманском продукте используется специализированный язык для статистики (язык SAS), разработанный ещё в 1970-х ¹¹ – можно назвать его первоначальной платформой для data science. Сильной стороной SAS является глубина её алгоритмов: обширная библиотека моделей временных рядов для прогнозирования, оптимизационных процедур и методов машинного обучения, созданных за десятилетия. Она нанимает одних из самых талантливых инженеров и статистиков отрасли ¹¹ и стала пионером продвинутых методов прогнозирования задолго до того, как «ИИ» стал модным словом. В контексте цепочки поставок SAS часто используется для прогнозирования спроса и анализа запасов. Технически она надежна и проверена – но при этом требует значительных ресурсов. Инструментарий может показаться архаичным (мир во многом перешёл на языки с открытым исходным кодом, такие как Python/R, и, действительно, Jupyter Notebook сейчас является превосходной альтернативой ¹²). SAS не заявляет о магическом ИИ; она опирается на свою репутацию и солидные технологии. Для организаций с достаточной экспертизой SAS предлагает серьёзные аналитические возможности, основанные на реальных алгоритмах (ARIMA, ETS и т.д.) вместо хайпа. Основной её недостаток заключается в том, что это универсальная аналитическая платформа – невероятно мощная под капотом, но требующая квалифицированных пользователей для применения в цепочке поставок, и она не была специально протестирована на недавних конкурсах по прогнозированию (инструменты с открытым исходным кодом часто ей конкурируют ¹³).
Dassault Systèmes (Quintiq) – Специалист по оптимизации. Quintiq (приобретён Dassault Systèmes в 2014 году) – это платформа, сконцентрированная на оптимизации и планировании сложных цепочек поставок. Она оснащена проприетарным специализированным языком, называемым Quill, для моделирования бизнес-ограничений ¹⁴. Этот DSL позволяет инженерам создавать индивидуальные решения (например, пользовательские графики производства или маршрутизационные планы) и использовать математические решатели. Сам факт существования DSL в продукте является доказательством глубокой технологической экспертизы – разработка языка программирования для планировочных задач не является тривиальной ¹⁵. Quintiq превосходно справляется со сценариями, такими как фабричное планирование, оптимизация логистических сетей и другими NP-трудными задачами, где требуется индивидуальная модель оптимизации. Технически это один из самых гибких и мощных оптимизационных движков в программном обеспечении для управления цепочками поставок. Однако фокус Quintiq на оптимизации происходит за счёт других областей: например, его родные возможности прогнозирования достаточно ограничены ¹⁶. Ещё одной проблемой является то, что публичных технических обновлений по Quill немного, что намекает на то, что технология может устаревать или, по крайней мере, не развивается достаточно быстро ¹⁷. Пользователи часто полагаются на консультантов Dassault для настройки решений, и без ясной публичной документации сложно оценить последние инновации. В итоге, Quintiq является первоклассным выбором для сложных задач оптимизации и демонстрирует сильный инженерный подход через свой DSL – но он не так прозрачен или актуален в таких областях, как ИИ/прогнозирование, и его сильные стороны заключаются в том, что реализаторы создают с его помощью собственные решения, а не в «интеллекте» из коробки.
ToolsGroup (SO99+) – Пионер вероятностного прогнозирования с оговорками. Программное обеспечение ToolsGroup (SO99+) давно специализируется на прогнозировании спроса и оптимизации запасов с акцентом на вероятностные модели. Оно предлагает обширную функциональность для цепочки поставок (планирование спроса, пополнение запасов, многоэтажная оптимизация запасов) и было одним из первых поставщиков, пропагандирующих «сильно простое» вероятностное прогнозирование. На бумаге это звучит продвинуто – ToolsGroup утверждает, что моделирует неопределённость спроса и «самонастраивающиеся» прогнозы, что должно обеспечивать более точные целевые уровни запасов. Однако детальный технический анализ вызывает вопросы. Публичные материалы ToolsGroup по-прежнему намекают на использование моделей прогнозирования до 2000 года ¹⁸ – они добавили упоминание «ИИ» в маркетинговых материалах, но без конкретики. Примечательно, что с 2018 года они рекламируют вероятностные прогнозы, одновременно хвалясь улучшением MAPE ¹⁹. Это явное противоречие: если прогнозы действительно представляют собой вероятностные распределения, такие метрики, как MAPE (которая измеряет однозначную точность), уже не применимы напрямую ¹⁹. Такие несоответствия позволяют предположить, что «вероятностная» составляющая может быть поверхностной или что они ориентируются на старые метрики, несмотря на применение новых методов. Кроме того, ToolsGroup использует модные термины вроде «ИИ для обнаружения спроса», но эти утверждения не подтверждены научной литературой или известными бенчмарками ²⁰. На практике многие развертывания ToolsGroup по-прежнему функционируют как автоматизированные системы, основанные на правилах, с оповещениями об исключениях. Вывод: ToolsGroup обладает широкой функциональностью и был пионером в моделировании неопределённости, но отсутствие прозрачности в алгоритмах и разрыв между маркетингом и реальностью в области ИИ/МЛ делают его техническую надёжность лишь умеренной. Это надёжный инструмент, ориентированный на конкретную область, но явно не является передовым по современным стандартам.
Slimstock (Slim4) – Прямолинейный и надёжный. Slimstock – это освежающий аутсайдер, который не гонится за тенденциями. Его программное обеспечение Slim4 фокусируется на общепринятых методах управления цепочками поставок – таких, как классический расчёт страховых запасов, точки повторного заказа, экономичный размер заказа (EOQ) и т.д. ²¹. Другими словами, Slimstock придерживается проверенных, испытанных методов, изучаемых в учебниках. Хотя это означает, что нет изящных алгоритмов ИИ/МЛ или передовых оптимизаторов, это также гарантирует, что Slim4 надёжен и прост для понимания. Поставщик явно избегает расплывчатых заявлений об ИИ и вместо этого делает акцент на практических функциях, соответствующих повседневным потребностям цепочки поставок ²². Эта честность является техническим достоинством: пользователи точно знают, что получают, и поведение системы предсказуемо. Конечно, простота может быть и ограничением – с Slim4 вы не получите вероятностных прогнозов спроса или продвинутых оптимизаторов. Он не предназначен для очень сложных сетей или огромных объёмов данных (а его технологическая архитектура, скорее всего, представляет собой стандартную базу данных с кэшированием в оперативной памяти, подходящую для средних задач). Но для многих компаний простота — залог надёжности, если это означает, что инструмент работает последовательно. Slimstock зарабатывает очки доверия за отсутствие модных лозунгов; его «по существу» подход ценят коллеги как контраст к демонстративным заявлениям об ИИ ²³. В итоге, Slim4 не раздвигает технологические границы, но является надёжным выбором для базового прогнозирования и управления запасами с минимальным хайпом и прозрачной, низкорисковой архитектурой.
o9 Solutions – Машина хайпа высоких технологий. o9 представляет себя как «Цифровой мозг» для корпоративной цепочки поставок, объединяя прогнозирование спроса, планирование поставок, S&OP и даже управление доходами на одной платформе. Технически o9 внедрил множество современных технологических концепций в свой продукт: модель данных в оперативной памяти, графовую базу данных под названием «Enterprise Knowledge Graph (EKG)», а также различные компоненты ИИ/МЛ. Огромная технологическая «масса» o9 просто зашкаливает ²⁴ – по стандартам корпоративного ПО это очень амбициозная архитектура, стремящаяся объединить все данные и аналитические возможности планирования. Однако, если посмотреть критически, многое из этого выглядит как технология ради технологии, без очевидной отдачи. Дизайн o9, основанный на использовании оперативной памяти, гарантирует чрезвычайно высокие затраты на оборудование при масштабировании ²⁵, аналогично работе гигантского BI-куба на постоянной основе. o9 рекламирует свой EKG (граф знаний) как средство для обеспечения превосходного прогнозирования и получения аналитических выводов, управляемых ИИ, но никаких научных доказательств или достоверных бенчмарков не предоставляется ²⁵. Фактически, многие эффектные заявления o9 разваливаются при детальном анализе: компания говорит об ИИ повсюду, однако фрагменты их публичного кода на GitHub демонстрируют довольно банальные техники ²⁶. Например, o9 рекламировала функции, такие как прогнозирование спроса с использованием машинного обучения и симуляции «цифровых двойников», но не продемонстрировала их на каких-либо публичных конкурсах или в рецензируемых исследованиях. Без доказательств мы должны рассматривать их заявления об ИИ как маркетинговый хайп. Тем не менее, у o9 есть свои сильные стороны – это единая платформа (разработанная внутри компании, а не составленная из приобретений) и способность обрабатывать интеграцию данных в крупном масштабе. Для компании, готовой инвестировать в оборудование и справляться с крутой кривой обучения, o9 предлагает гибкость для построения сложных моделей планирования. Но с инженерной точки зрения, это чрезмерно усложнённое решение: много сложности, неясная окупаемость дорогостоящих технологий и потенциальные проблемы с производительностью, если объём данных превысит возможности оперативной памяти. Пока o9 не предоставит весомых доказательств (например, документацию по алгоритмам или результаты бенчмарков), его надёжность остаётся под вопросом.
SAP IBP (Интегрированное бизнес-планирование) – Комплексное, но сложное. SAP IBP является эволюцией наследуемой системы APO от SAP и теперь предлагается в виде облачного решения на базе in-memory базы данных SAP HANA. SAP IBP нацелен на охват всего спектра: прогнозирование спроса, оптимизацию запасов, планирование поставок, планирование продаж и операций и многое другое – всё это тесно интегрировано с системой ERP SAP.
Blue Yonder – Лидер прошлого, превратившийся в лоскутное одеяло. Blue Yonder (ранее известный как JDA Software) предлагает полный набор решений, охватывающий прогнозирование, планирование поставок, мерчендайзинг и исполнение. Это результат многолетних слияний и поглощений, включая приобретение JDA компанией i2 Technologies (планирование цепочки поставок), Manugistics и AI-стартапа Blue Yonder (название которого было перенято) среди прочих ²⁷. К сожалению, корпоративное программное обеспечение – это не простая сумма частей: под единым брендом Blue Yonder скрывается смесь продуктов (многие из которых довольно устарели), скомпонованных поверхностно ²⁷. С технической точки зрения, решения Blue Yonder варьируются от старомодных детерминированных движков прогнозирования до модулей оптимизации запасов, которые принципиально не менялись более 15 лет. Компания активно продвигает возможности «AI» и «ML» в своей платформе Luminate, но подробной информации немного. Фактически, несколько публичных артефактов – таких как проекты с открытым исходным кодом и патенты, приписываемые команде data science Blue Yonder – свидетельствуют о том, что они используют довольно традиционные методы (например, извлечение признаков временных рядов, модели ARMA и линейную регрессию) ²⁸. Эти методы работают, но они представляют собой подходы десятилетней давности, которые часто уступают новым методам. Кажется, что громко рекламируемый AI Blue Yonder может быть просто переупакованной регрессией и эвристиками. Без прозрачных кейс-стадий или технических публикаций, можно предположить, что утверждения Blue Yonder о “революционном AI-прогнозировании” – это маркетинговый шум. Более того, интеграция всех приобретённых компонентов остаётся постоянной проблемой – многие клиенты отмечают трудности с выполнением обещания «от начала до конца», поскольку модули (спрос, предложение, исполнение и т.д.) не подключаются естественным образом без значительной кастомизации. In-memory vs. on-disk? Blue Yonder не рекламирует полностью in-memory архитектуру, как некоторые другие; части системы, вероятно, работают на стандартных реляционных базах данных. Это может снизить затраты, но также означает, что производительность может снижаться, если данные не агрегируются (например, их старые системы часто использовали пакетное планирование). В итоге, Blue Yonder – предостерегающая история: когда-то лидер отрасли, теперь он предлагает широкий, но технически непоследовательный набор решений. Его сильные стороны – опыт в отрасли и обширный функционал, а слабости – устаревшие технологии под свежей покраской и отсутствие убедительных доказательств новых возможностей “AI”.

(Примечание: Существуют и другие поставщики, такие как Infor (с наследуемыми компонентами GT Nexus и Mercia), GAINS Systems (ещё один специалист по оптимизации запасов), John Galt Solutions (прогнозирование спроса для среднерыночного сегмента), Relex Solutions (розничное прогнозирование с in-memory движком) и т.д. В интересах фокусировки выше приведены наиболее заметные или поучительные примеры. Те же скептические критерии применимы и к непроиндивидуально оценённым поставщикам: например, Relex использует in-memory дизайн в стиле OLAP-куба – отлично по скорости, но гарантирует высокие затраты на оборудование для крупных ритейлеров ²⁹; Infor росла за счет поглощений, что привело к проблемам интеграции, схожим с SAP/Blue Yonder; GAINS и John Galt предлагают надёжный базовый функционал, но мало что задокументировано публично о новых методах. Любого поставщика, который не раскрывает технические детали или доказательные показатели, в любом случае оценили бы низко по методологии данного исследования.)*

Глубокий технический анализ

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

Возможности прогнозирования и AI

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

Доказанная эффективность vs. шум: Среди всех поставщиков только Lokad может похвастаться проверенной мировой репутацией в области прогнозирования, чему способствовал открытый конкурс M5. Lokad продемонстрировал свои возможности в вероятностном прогнозировании, заняв лидирующие позиции по точности на уровне артикулов (SKU) ¹. Это придаёт достоверность утверждениям Lokad о лучшей точности прогнозов. В резком контрасте, ни один другой поставщик не опубликовал сопоставимые результаты на независимых тестах. Например, некоторые поставщики рекламируют собственные алгоритмы (один называет свой метод “Procast”), утверждая, что они обеспечивают превосходную точность, однако эти методы отсутствовали среди лидеров конкурса M5 ³⁰. На практике академические подходы с открытым исходным кодом (например, R-пакеты для прогнозирования профессора Роба Хиндмана) зачастую не уступают, а порой и превосходят большинство закрытых проприетарных решений ¹³. Поэтому любое утверждение поставщика о «наиболее точном прогнозировании в отрасли» без публичных доказательств следует считать необоснованным.
Утверждения об AI и машинном обучении: Мы проявили крайнюю скептичность к шуму вокруг AI/ML. Поставщики, такие как o9 Solutions и Blue Yonder, часто используют в своих материалах термины вроде “прогнозирование на основе AI/ML”. Однако при поиске конкретики мы обнаружили совсем немного. В случае o9, их утверждения о том, что основанный на графах “Enterprise Knowledge Graph” обеспечивает лучшие прогнозы, вызывают сомнения и не подкреплены научными данными ²⁵. Blue Yonder аналогично рекламирует AI, но не предоставляет подробностей – единственный взгляд на их технологию даётся через несколько репозиториев с открытым исходным кодом, где видно использование довольно обычных методов анализа временных рядов (ARMA, линейная регрессия, инженерия признаков) ²⁸. Нет доказательств применения глубокого обучения, продвинутых вероятностных методов или других современных AI-технологий, которые могли бы оправдать их маркетинговые заявления. ToolsGroup действительно внедрила концепции машинного обучения (они говорят о “чувствительности к спросу” с использованием машинного обучения), но опять же нет рецензируемых исследований или побед в конкурсах, подтверждающих это ²⁰. Фактически, сочетание «вероятностного прогнозирования» с устаревшими метриками, такими как MAPE, у ToolsGroup говорит о том, что их AI – скорее маркетинговый ход, чем прорыв ¹⁹. Вывод: За исключением Lokad (а также, в некоторой степени, SAS, использующего проверенные временем статистические модели), прогнозирование в большинстве программ для цепей поставок остаётся основано на известных методах (экспоненциальное сглаживание, регрессия, возможно, некоторые методы на основе деревьев) и не представляет собой какой-то запатентованный гениальный AI. Поставщики, обладающие действительно новыми алгоритмами, продемонстрировали бы их публично. Отсутствие независимой валидации говорит само за себя.
Вероятностный против детерминированных подходов: Значимым техническим отличием является то, использует ли поставщик вероятностное прогнозирование (предсказание полного распределения вариантов спроса) или ограничивается одноточечными прогнозами. Lokad с 2012 года активно продвигает использование полных вероятностных распределений и, действительно, оптимизирует решения (например, уровни запасов) непосредственно на основе вероятностных прогнозов. ToolsGroup также заявляет, что способен выдавать вероятностные прогнозы (вероятно, с помощью моделей Монте-Карло для спроса). Однако мы обнаружили, что многие, кто заявляет о “вероятностном” подходе, по сути всё равно используют детерминированные метрики и процессы внутри системы. Например, маркетинговые материалы ToolsGroup о снижении MAPE с помощью вероятностных моделей выглядят нелогично, поскольку MAPE даже не может быть рассчитан для вывода вероятностного прогноза ¹⁹. Это говорит о том, что их процесс в конечном итоге сводится к одноточечному прогнозу (среднему или медиане) для оценки, что нивелирует преимущество вероятностного подхода. Другие поставщики, такие как SAP, Oracle, Blue Yonder, начали упоминать вероятностные термины (например, SAP IBP теперь имеет “статистические ансамбли” и доверительные интервалы), но их пользовательские интерфейсы и отчёты часто по умолчанию показывают единственное числовое значение с традиционными метриками ошибок. Принятие истинного вероятностного прогнозирования требует переосмысления KPI (например, использование Pinball loss, CRPS или уровня обслуживания вместо MAPE). Мы не обнаружили свидетельств того, что какой-либо крупный поставщик, кроме Lokad, на практике зашёл настолько далеко. В итоге, вероятностное прогнозирование – это область, где маркетинг опережает реальность для большинства поставщиков – они могут генерировать распределения «за кулисами», но планировщики всё ещё смотрят на одноточечные прогнозные значения и классические KPI, что указывает на ограниченное применение этой парадигмы.
Метрики прогнозирования и оценка: Важным аспектом технической строгости является то, как поставщик оценивает качество прогнозов. Красным флажком является систематическая зависимость от таких метрик, как MAPE, WAPE или смещение, в качестве единственных показателей успеха, особенно если поставщик утверждает, что использует AI или вероятностные методы. Это связано с тем, что данные метрики поощряют консервативное, нейтральное прогнозирование и могут быть «обмануты» (например, путём обрезки крайних значений). Мы заметили, что поставщики с по-настоящему передовыми возможностями прогнозирования склонны говорить об уровнях обслуживания или бизнес-результатах (например, вероятность отсутствия товара, влияние на затраты) вместо простого MAPE. Например, Lokad акцентирует внимание на снижении «ошибок в долларах» и привязке прогнозов к оптимизации решений ³¹. В отличие от него, ToolsGroup, Blue Yonder и многие другие по-прежнему выделяют процентные ошибки в своих кейсах, что свидетельствует об устаревшем подходе. Если в документации или демонстрации поставщика активно используются панели с показателями MAPE/WAPE, это говорит о том, что их прогнозирование, скорее всего, традиционное. Действительно, неконсистентность ToolsGroup в отношении MAPE уже была отмечена ¹⁹. Короче говоря: по-настоящему современное прогнозирование в цепочке поставок должно подтверждаться вероятностными метриками и реальной проверкой на практике – атрибутами, которые в основном отсутствуют за исключением одного-двух игроков.

Возможности автоматизации и рабочих процессов

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

Lokad: Автоматизация – одна из отличительных черт Lokad. Всё решение построено вокруг специализированного языка (Envision), который позволяет специалистам по цепочкам поставок кодировать свою логику и решения в виде скриптов, запускающихся автоматически по расписанию. Lokad чётко документирует свои каналы обработки данных и менеджер рабочих процессов, который обновляет данные и пересчитывает решения (прогнозы, заказы на пополнение и т.д.) без ручного вмешательства ³² ³³. Они даже упоминают наличие «высокоавтоматизированных настроек» для примерно 100 цепочек поставок в эксплуатации ³³, что означает, что программное обеспечение самостоятельно собирает данные, строит прогнозы и выдает решения (например, предложения по заказам) в полностью автоматическом режиме. Кроме того, Lokad предоставляет API для загрузки данных и скачивания результатов, а также реализовал концепцию «AI Pilot» для автоматизации рутинных задач ³⁴. Всё это указывает на очень высокий уровень настоящей автоматизации – роль пользователя сводится в основном к мониторингу и доработке кода/параметров, а не к ручному нажатию кнопок для каждого плана. Подход Lokad к автоматизации заслуживает доверия и детально проработан с технической стороны (они даже проводили лекции о переходе от ручного к автоматизированному принятию решений ³⁵ ³⁶).
Kinaxis: Kinaxis RapidResponse разработан для быстрого анализа сценариев и совместной работы, а не для полностью автоматизированного планирования. Концепция «конкурентного планирования» подразумевает, что все работают с одним и тем же набором данных с обновлениями в реальном времени, однако обычно участие человека-планировщика необходимо для оценки сценариев и принятия решений. Тем не менее, Kinaxis поддерживает автоматизацию в некоторых аспектах: система может загружать данные из ERP-систем практически в реальном времени, непрерывно выполнять алгоритмы сопоставления спроса и предложения и посылать пользователям оповещения или сообщения об исключениях, если что-то выходит за рамки. Программное обеспечение предоставляет функциональность через API и включает возможность скриптинга (в виде настраиваемых алгоритмов и макросов в своей среде) для продвинутых пользователей. Однако Kinaxis в целом позиционирует себя как инструмент поддержки принятия решений, а не как чёрный ящик, автоматически выпускающий заказы. Поставщик не заявляет громко о «автономной цепочке поставок»; вместо этого он сосредоточен на повышении эффективности планировщиков. Это честная позиция. Это означает, что из коробки RapidResponse всё ещё предполагает участие человека – что может стать ограничением, если требуется система «самоуправляемой» цепочки поставок. Технически Kinaxis может быть глубоко интегрирован (например, часто интегрируется с SAP ERP для выполнения утверждённых планов), но без участия человека в цепочке, работа от начала до конца потребует значительной настройки. Мы не обнаружили доказательств того, что Kinaxis предоставляет рекомендации по принятию решений на базе ИИ (их сильная сторона – быстрая обработка сценариев, заданных пользователями).
o9 Solutions: o9 активно продвигает такие концепции, как «цифровой двойник» организации и ИИ, способного давать рекомендации. Они говорят об «Автоматизации» в контексте своих цифровых ассистентов – предположительно, ботов, способных выявлять инсайты или выполнять некоторые задачи. Однако при отсутствии конкретной технической документации трудно определить, сколько из этого реально. Мы не нашли подробностей вроде «o9 может автоматически выпускать заказы на пополнение через API на основе своих планов» или «o9 использует обучение с подкреплением для самостоятельной настройки параметров». Неопределённость в рассказе o9 об автоматизации вызывает озабоченность: много общих заявлений высокого уровня и мало деталей. Учитывая основание их системы с использованием оперативной памяти, мы подозреваем, что o9 способен на обновление данных в реальном времени и пересчёты, но, вероятно, всё ещё полагается на пользователей для настройки дальнейших действий с этой информацией. Без надёжных источников мы рассматриваем заявления o9 об «автономности» как непроверенные. Возможно, интеграцию o9 через API в системы исполнения осуществить можно (это современное ПО, поэтому поддержка API должна быть), но насколько именно принятие решений автоматизировано с помощью ИИ в o9 остаётся неясным. Доказательства указывают на то, что текущая автоматизация o9 больше направлена на ускорение аналитики (например, мгновенные варианты «что если»), чем на автоматизацию итоговых решений.
Blue Yonder: В последние годы Blue Yonder (особенно после приобретения Panasonic) активно продвигает термин «автономная цепочка поставок», подразумевая систему, способную работать с минимальным участием человека. В их составе действительно присутствуют компоненты, такие как Luminate Control Tower, которые используют ИИ для обнаружения сбоев и, возможно, запуска ответных мер. Однако, учитывая унаследованное ядро Blue Yonder, вероятно, любая автономия достигается посредством наслоения RPA (Robotic Process Automation) или простых ИИ-агентов поверх существующих модулей. Например, система планирования спроса Blue Yonder может генерировать прогноз, а «ИИ»-слой может автоматически корректировать его на основе продаж в реальном времени (сигнал ощущаемого спроса) или отправлять оповещения при отклонениях. Но полностью автоматизированное планирование (например, автоматическая выдача заказов, автоматическая корректировка политики управления запасами) встречается, вероятно, редко в решениях BY – клиенты обычно оставляют проверку и утверждение действий за планировщиками. Отсутствие подробной технической документации о том, как Blue Yonder автоматизирует принятие решений, говорит само за себя. Если бы у них был по-настоящему автономный планировщик, они бы публиковали истории успеха или технические статьи об этом. Вместо этого они в основном проводят маркетинговые вебинары. Таким образом, можно сделать вывод, что Blue Yonder действительно обеспечивает определённую степень автоматизации (например, пакетные задания, обновления планов, возможно, замкнутую интеграцию с системами исполнения), но не является бесспорно лидером в этой области. Вероятно, они используют аналогичный подход на основе управления исключениями, как и в старых системах (просто с новым ИИ-налетом на систему оповещений).
ToolsGroup: ToolsGroup исторически гордилась концепцией «Мощная простая автоматизация». Они утверждали, что их система способна работать в режиме без присмотра в течение длительного времени, привлекая планировщиков только при возникновении исключительных ситуаций. Действительно, философия ToolsGroup заключалась в том, чтобы система автоматически пересчитывала прогноз и перепланировывала каждый день, адаптируясь к новым данным. По мнению многих клиентов ToolsGroup, рабочая нагрузка планировщиков сокращается, поскольку программное обеспечение само корректирует целевые показатели запасов и автоматически рекомендует заказы. Кроме того, ToolsGroup имеет набор инструментов для интеграции утверждённых заказов в ERP-системы. Однако, учитывая ранее отмеченные противоречия, у нас возникают сомнения относительно «интеллекта» этой автоматизации. Возможно, система просто применяет одну и ту же формулу каждый день и отмечает, когда что-то идёт не так (управление исключениями). ToolsGroup действительно предоставляет API и поддерживает запланированные запуски, поэтому, технически, инфраструктура для автоматизации присутствует. Вопрос в качестве автоматизированных решений. Они часто упоминают «самонастройку» – подразумевая, что ПО самостоятельно корректирует параметры модели прогнозирования при поступлении новых данных ³⁷. Если это действительно так, то это полезная автоматизация (исключающая необходимость постоянной ручной перенастройки). Без независимой оценки мы осторожно заявляем, что ToolsGroup предлагает высокую степень автоматизации рутинных задач планирования, но отсутствие прозрачности затрудняет оценку того, насколько «умной» является эта автоматизация (например, действительно ли она обучается и улучшается или просто следует заданным правилам).
Другие поставщики: Большинство других участников рынка поддерживают стандартные возможности автоматизации: интеграция данных через API или пакетная обработка файлов, запланированные запуски планирования и некоторые рабочие процессы на основе исключений. Например, SAP IBP можно настроить на автоматический запуск задачи прогнозирования каждый месяц с последующим заполнением результатов планирования, однако обычно планировщик проверяет полученные данные. Anaplan меньше ориентирован на автоматизацию – это скорее платформа для ручного моделирования, хотя её API можно использовать для передачи и получения данных, а также для автоматизации некоторых расчётов. Dassault/Quintiq можно настроить через скрипты для запуска оптимизационных процедур по расписанию (а DSL Quintiq позволяет программировать настраиваемые автоматические поведения), но, опять же, степень автономности зависит от того, как настроит систему разработчик. GAINS, Relex, Netstock и другие нишевые поставщики рекламируют «сквозную автоматизацию» в пополнении запасов – обычно это означает, что они могут автоматически генерировать заказы на закупку или рекомендации по перемещению товаров между магазинами. Главное различие заключается в том, сколько контроля требуется: по-настоящему автономная система планирования обращается к человеку только в необычных ситуациях и документирует свои решения с обоснованиями. Мы не нашли ни одного поставщика, который полностью достиг бы этого идеала. Либо требуется вмешательство человека для корректировки и утверждения (как в большинстве случаев), либо автоматизированы только самые простые решения, а всё остальное – за человеком.

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

Архитектура системы и масштабируемость

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

Вычисления в оперативной памяти – плюсы и минусы: Несколько ведущих поставщиков полагаются на архитектуру с вычислениями в оперативной памяти, что означает, что программное обеспечение загружает большую часть или все релевантные данные в ОЗУ для быстрого доступа во время вычислений. Это включает Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex и, возможно, Quintiq (для решения сценариев). Преимущество – скорость: доступ к данным в ОЗУ в порядки быстрее, чем к диску. Например, движок Kinaxis загружает все данные в память, что позволяет мгновенно пересчитывать сценарии и выполнять прямые алгоритмические операции с набором данных ⁹. SAP HANA построена на предположении, что аналитика по актуальным данным должна проводиться в оперативной памяти для получения результатов в реальном времени ³⁸ ³⁹. Однако существует фундаментальная проблема у дизайна, полностью зависящего от оперативной памяти: стоимость и масштабируемость. ОЗУ чрезвычайно дорого по сравнению с накопителями. 1 ТБ ОЗУ может стоить в 100 раз дороже, чем 1 ТБ дискового пространства ¹⁰. И объём памяти на серверах физически ограничен (типичные системы имеют от 0,5 до 2 ТБ ОЗУ, тогда как наборы данных в несколько терабайт или петабайт являются обычным делом в больших цепочках поставок). В последние годы ожидаемое резкое снижение стоимости ОЗУ не реализовалось – цены и ёмкости ОЗУ оставались достаточно стабильными ⁴⁰. Это означает, что любая система, требующая загрузки всех данных в память, столкнется с резким ростом затрат на инфраструктуру по мере увеличения объёма данных или достигнет жесткого предела, когда данные просто не смогут уместиться. Мы считаем серьёзной ошибкой архитектуру, основанную исключительно на оперативной памяти, для крупных цепочек поставок, если не приняты меры по смягчению.
Память против диска: современные практики: Примечательно, что технологическое сообщество осознало, что решения, полностью зависящие от оперативной памяти, не являются будущим для больших данных. Новые архитектуры используют многоуровневый подход – хранение «горячих» данных в памяти и «холодных» на SSD, и т.д. ⁴¹ ⁴². Некоторые системы для управления цепочками поставок уже начали применять этот подход. Например, Lokad явно использует методику «spill to disk» в своей облачной инфраструктуре. Их технический директор описал, как они обрабатывают розничный набор данных в 10 миллиардов строк, используя около 37 ГБ ОЗУ плюс быстрый NVMe SSD для обработки избыточных данных ⁴³ ³. Они достигают производительности, близкой к работе с ОЗУ, посредством отображения файлов в память и хранения в ОЗУ только самых «горячих» данных, при этом программное обеспечение умно осуществляет подкачку по мере необходимости ⁴⁴ ⁴⁵. Такой подход обеспечивает существенную экономию – например, за стоимость 18 ГБ высококлассной ОЗУ можно приобрести 1 ТБ NVMe SSD ³, что делает его в 50 раз дешевле за байт, при этом он примерно в 6 раз медленнее при сырых операциях доступа – компромисс, который часто оправдан. Ни один из поставщиков, ориентированных на оперативную память (Kinaxis, SAP, o9 и др.), не описал публично такую адаптивную систему управления памятью, что свидетельствует о том, что их решения могут просто требовать большого объёма ОЗУ или предполагать агрегацию данных для их размещения.
Технологический стек и сложность: Помимо оперативной памяти, ещё одним важным архитектурным элементом является общий технологический стек – монолитные системы против микросервисов, использование современных языков программирования и т.д. Не вдаваясь в детали, мы заметили, что старые поставщики (SAP APO/IBP, Blue Yonder) работают на более монолитных, устаревших стэках, в то время как новые (o9, Anaplan) создавали свои решения с нуля, используя современные технологии. Например, ядро SAP IBP всё ещё включает движки из 2000-х (например, оптимизатор APO), ныне обёрнутые в слой HANA/облака. Это создаёт дополнительную сложность и потенциальную неэффективность (множество уровней абстракции). Blue Yonder также обладает большим количеством устаревшего кода с времён i2 и JDA. Kinaxis несколько уникален – он появился в 90-х, но постоянно рефакторился в собственное ядро базы данных; всё же это проприетарный стек, используемый только ими. Anaplan разработал очень эффективный расчетный движок (на Java) для своего специфического случая использования (Hyperblock), который достаточно оптимизирован для этой цели – но он не является открытым, и приходится мириться с его ограничениями (например, отсутствием SQL-запросов, ограниченной алгоритмической сложностью, так как расчеты проводятся на уровне ячеек). Платформа o9 включает смесь технологий (вероятно, NoSQL/графовая база данных, возможно, Spark или что-то подобное для некоторых задач машинного обучения и т.д.), что делает ее сложной, но теоретически гибкой.
Аппаратное обеспечение и облака: Замечательная тенденция – архитектура, нативная для облака. Многие поставщики теперь предлагают своё программное обеспечение в виде SaaS или, по крайней мере, размещённого в облаке, но не все они действительно созданы как облачные решения. Например, Anaplan и o9 являются многоарендными SaaS (созданными с нуля для облака). Lokad работает нативно в облаке (работает на Microsoft Azure и динамически распределяет ресурсы). SAP IBP размещён в облаке, но по сути каждый клиент представляет собой изолированный экземпляр на HANA (не многоарендный в традиционном смысле). ToolsGroup, Blue Yonder предлагают SaaS-решения, но часто это просто их локальное ПО, размещенное в облаке под их управлением. Почему это важно с технической точки зрения? Облачные архитектуры обычно более эластичны – они могут быстро задействовать вычислительные ресурсы при необходимости (например, для масштабных расчетов планирования) и отключать их потом, что позволяет контролировать затраты. Небазовые облачные системы зачастую требуют покупки ресурсов под пиковую нагрузку, даже если используются время от времени. Кроме того, облачные решения могут лучше интегрироваться с другими облачными сервисами (например, с сервисом машинного обучения или хранилищем данных в облаке). Из нашего анализа видно, что наиболее ориентированными на облако и масштабируемыми по замыслу решениями являются Lokad и o9 (а возможно, и Anaplan), в то время как другие поставщики догоняют их. Однако, просто быть облачным решением не означает хорошей архитектуры – o9 ориентирован на облако, но мы сомневаемся в его подходе, сильно зависящем от оперативной памяти; размещение SAP IBP в облаке не решает проблемы сложности.
Многопоточность и работа в реальном времени: Одним из аспектов архитектуры является то, как система обрабатывает одновременных пользователей и обновления в реальном времени. Kinaxis блестяще справляется с этим: она была разработана так, чтобы несколько планировщиков могли одновременно проводить сценарное планирование на одном и том же наборе данных. Это требует тщательного контроля версий данных и логики блокировки – что Kinaxis достигает с помощью своего механизма ветвления ⁸. Большинство других инструментов традиционно следовали партийной парадигме (сначала планируешь, потом публикуешь, а затем работаешь совместно отдельно). Сейчас многие добавляют функции одновременного планирования. Anaplan позволяет нескольким людям работать над разными частями модели одновременно (так как она по сути ячеечная, как Google Sheets). SAP IBP представил пользовательский интерфейс, похожий на «Microsoft Excel», который умеет по требованию обновлять данные с сервера, но настоящая одновременность (несколько пользователей, редактирующих один и тот же план одновременно) остаётся ограниченной. o9 вероятно поддерживает некоторый уровень одновременной работы благодаря своему графу знаний (несколько пользователей могут корректировать разные узлы). При оценке технического потенциала система, способная действительно работать в реальном времени с большим количеством пользователей, указывает на прочную архитектуру. Kinaxis и Anaplan получают за это дополнительные баллы. Дело не в том, что другие не могут этого добиться, но их устаревшие архитектуры часто затрудняют реализацию – что приводит либо к медленной работе, либо к необходимости последовательной обработки.

Резюме по архитектуре: Мы выявили паттерн: конструкции, ориентированные на оперативную память (Kinaxis, Anaplan, o9, Relex, SAP HANA) обеспечивают скорость, но за счёт масштабируемости и затрат ($$), в то время как гибридные подходы (например, spill-to-disk у Lokad, возможно, инструменты с использованием современных баз данных) более масштабируемы и экономичны. Очевидный тревожный сигнал – любой поставщик, настаивающий на том, что всё должно работать в ОЗУ, считается устаревшим подходом с учётом достижений в скорости SSD и распределённых вычислениях ⁴¹ ⁴². Мы также отмечаем, что архитектура поставщиков, возникшая в результате многочисленных приобретений (например, SAP, Blue Yonder), как правило, чересчур сложна и требует множества настроек. Более простые, разработанные собственными силами архитектуры (единая кодовая база Kinaxis, единый движок Anaplan, единый движок Lokad), как правило, более последовательны и, следовательно, легче поддерживаются технически. При оценке программного обеспечения для цепочки поставок следует спросить: Опубликовал ли поставщик хоть какую-либо информацию о том, как построено их программное обеспечение (микросервисы? Собственная БД? Использование библиотек машинного обучения и т.д.). Отсутствие инженерного обсуждения может означать, что архитектура – это просто чёрный ящик, что часто указывает либо на наследие, либо на отсутствие уверенности в их уникальности.

Интеграция и согласованность модулей (Влияние M&A)

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

Blue Yonder (JDA) является воплощением роста через поглощения. Как уже отмечалось, это «случайная подборка» продуктов из разных эпох ²⁷. JDA приобрела i2 (которая сама имела несколько модулей), ранее приобрела Manugistics, затем RedPrairie (для управления складом), а потом стартап Blue Yonder для ИИ. Каждый компонент имел свою собственную схему базы данных, свою логику. Результат: даже сегодня планирование спроса, планирование поставок и оптимизация запасов в Blue Yonder могут не иметь единой общей модели данных – интеграция построена на интерфейсах. Это тревожный сигнал, поскольку означает, что внедрение полного пакета фактически сводится к интеграции нескольких различных программных продуктов. Когда продукты поставщика не являются по-настоящему едиными, клиенты сталкиваются с такими проблемами, как задержки синхронизации данных, несогласованный пользовательский интерфейс и дублирование функциональности. В случае Blue Yonder: некоторые модули, откровенно говоря, перекрываются (после приобретений у вас может оказаться два способа планирования запасов – один от устаревшего Manugistics и один от i2). Компания прилагала усилия для рационализации этого, но проблема до конца не решена. С технической точки зрения, корпоративное программное обеспечение не «смешивается» как жидкости при слиянии компаний ²⁷ – на это уходят годы переинжиниринга. Мы не видели доказательств того, что Blue Yonder завершила этот переинжиниринг. Таким образом, отсутствие согласованности является серьёзной технической слабостью.
SAP IBP аналогичным образом объединил приобретённые компоненты: покупка SAF, SmartOps и других инструментов компанией SAP привела к появлению разрозненных решений, которые затем были интегрированы под эгидой IBP ⁴⁶. Пользователи отмечали, что IBP имеет различные модули, которые ощущаются как отдельные приложения (например, IBP для спроса против IBP для запасов). Логика оптимизации страховочных запасов в IBP, вероятно, исходит из приобретения SmartOps, тогда как функция обнаружения спроса может быть результатом SAF или внутренних разработок. Интеграция здесь лучше, чем у Blue Yonder (SAP, по крайней мере, переписала интерфейс и разместила всё на базе данных HANA), но, тем не менее, внутри IBP нет единой кодовой базы. SAP прямо предупреждает, что внедрение IBP обычно требует нескольких лет и привлечения экспертов по интеграции, чтобы все модули работали оптимально вместе ⁴⁷. Это утверждение само по себе является тревожным сигналом – оно подразумевает возможное несоответствие и сложность.
Infor (хотя и не в числе топ-10 выше) также объединил различные системы планирования (они приобрели систему планирования цепочки поставок Mercia и GT Nexus и т.д.). Результатом так никогда не получилась по-настоящему единая платформа планирования; Infor, как правило, сосредоточен на системах исполнения. Таким образом, это ещё один пример, когда приобретения не привели к созданию отличного интегрированного продукта для планирования.
Dassault (Quintiq): в данном случае приобретение (со стороны Dassault) не предполагало слияния Quintiq с другим инструментом планирования – Dassault более или менее позволил Quintiq оставаться самостоятельным решением, ориентированным на оптимизацию производства и планирование графиков. Таким образом, внутренняя согласованность Quintiq в порядке (она была разработана самостоятельно и остаётся таковой), но недостаток заключается в том, что она не охватывает все области (например, отсутствует собственное прогнозирование спроса, как отмечено ¹⁶). Портфель Dassault включает и другие продукты (например, Apriso для MES и т.д.), но они не интегрированы с Quintiq на глубоком уровне. Таким образом, с точки зрения интеграции, Quintiq является внутренне последовательным, но функционально узким. С точки зрения пользователя, возможно, придётся интегрировать его с другим инструментом прогнозирования, что требует дополнительных усилий на стороне клиента.
Kinaxis рос в основном органически – он действительно приобрёл небольшую AI-компанию Rubikloud в 2020 году (для розничного ИИ) и инструмент для проектирования цепочки поставок (Castle Logistics) в 2022 году, но это относительно недавние приобретения, и остаётся неизвестным, как они будут интегрированы. Исторически RapidResponse представлял собой один продукт, охватывающий различные аспекты планирования через конфигурацию. Эта согласованность является преимуществом: все модули (спрос, поставки, запасы) используют одну базу данных и единый пользовательский интерфейс в Kinaxis. Аналогичным образом, Anaplan разработала различные приложения для планирования на одной платформе – планы по продажам, финансам и цепочке поставок размещены в единой среде Hyperblock, что технически очень согласовано (просто используются разные шаблоны моделей). o9 Solutions также представляет собой органически разработанную единую платформу, охватывающую многие области (она не росла за счёт приобретения других поставщиков планирования, по крайней мере, крупных). Таким образом, эти три – Kinaxis, Anaplan, o9 – имеют существенное архитектурное преимущество единства. Проблема с ними заключается не в интеграции разрозненных модулей, а в том, способна ли их единая платформа действительно охватывать глубину каждой области.
ToolsGroup & Slimstock: Эти поставщики оставались сосредоточенными на своей нише (прогнозировании спроса и планировании запасов). Они фактически не приобрели другие компании; вместо этого они сотрудничают или интегрируются с системами исполнения по мере необходимости. Это означает, что их программное обеспечение внутренне согласовано (единая кодовая база), что хорошо, но если клиент нуждается в более широких возможностях (например, в планировании производства), ему придётся использовать другой продукт и интегрировать его самостоятельно. В последние годы ToolsGroup действительно начал добавлять функции S&OP и даже приобрёл стартап в области ИИ (Eramos в 2018 году) для машинного обучения, но, опять же, эти функции были интегрированы в основной продукт, а не предлагались отдельно. Таким образом, интеграция не является большой проблемой для ToolsGroup или Slimstock – компромисс заключается в том, охватывает ли их специализированный дизайн достаточный объём для удовлетворения потребностей пользователя.

Резюме по интеграции: С точки зрения скептицизма, многочисленные крупные приобретения в истории поставщика являются предупредительным знаком. Это часто приводит к продукту «всесун», который ни в чём не преуспевает и скрывает сложность. Blue Yonder и SAP являются тому примером – их техническая сложность отчасти проистекает из попыток склеить вместе множество унаследованных компонентов. Напротив, поставщики с единой интегрированной платформой (органически созданной) избегают этих проблем, хотя им всё же нужно доказать, что одна платформа может всё выполнять отлично. При оценке программного обеспечения следует узнать происхождение каждого модуля: если модуль планирования спроса и модуль планирования поставок поступили от разных компаний-основателей, выясните, как они обмениваются данными и является ли интеграция бесшовной или осуществляется посредством интерфейсов. История показывает, что если приобретённая технология не была переписана с нуля в единую архитектуру (что встречается редко из-за затрат и временных рамок), результатом обычно становится система «Франкенштейн». Наши исследования это подтверждают – поставщики с наивысшими оценками за техническую элегантность (Lokad, Kinaxis, Anaplan) строили свои решения комплексно, тогда как те, у кого оценки ниже (Blue Yonder, Infor), накопили разрозненные технологии без полной интеграции.

Критические слабости и тревожные сигналы

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

Необоснованные заявления об «ИИ/машинном обучении»: Будьте крайне скептичны по отношению к любому поставщику, провозглашающему превосходство в ИИ или машинном обучении без твердых технических доказательств. Например, Blue Yonder активно рекламирует ИИ, но предоставляет лишь расплывчатые заявления без содержания ²⁸ – то немногое, что мы видим в их методах, указывает на то, что они полагаются на устаревшие техники, а не на передовые ИИ-решения. Аналогично, o9 Solutions превозносит свой ИИ и интеллект, основанный на графах, однако анализ их публичного кода и материалов показывает «тонны ИИ-ажиотажа» с посредственной аналитикой на практике ²⁶. Если поставщик не может предоставить рецензируемые исследования, патенты, результаты конкурсов или подробные технические статьи для подтверждения своих заявлений об ИИ, считайте это маркетинговой болтовней. По-настоящему продвинутые поставщики с гордостью расскажут о своих алгоритмах.
Отсутствие конкурентного бенчмаркинга (заявления о превосходстве в прогнозировании): Многие поставщики утверждают, что их точность прогнозирования – лучшая в своём классе, но ни один, кроме Lokad, не доказал этого в открытых конкурсах или публикациях. Мы считаем любое подобное заявление фиктивным, если его не подтвердят. Например, собственный алгоритм одного поставщика, который хвалился как «более точный, чем у других», отсутствовал в числе лидеров конкурса M5 ³⁰, что сильно указывает на необоснованность их утверждения. Фактически, ни один традиционный поставщик программного обеспечения для цепочки поставок (за исключением Lokad) не вошёл в топ-100 этого глобального конкурса по прогнозированию. Это серьёзный тревожный сигнал: он подразумевает, что эти поставщики либо не участвовали (возможно, чтобы избежать публичного позора), либо участвовали и показали слабые результаты. Практический совет: Требуйте объективных результатов точности (например, как их инструмент показал себя на стандартном бенчмарке, таком как M5 или M4) – если они не могут предоставить таковые, не покупайтесь на маркетинговый ажиотаж.
Чрезмерное упование на архитектуру, основанную исключительно на оперативной памяти: Поставщиков, продвигающих конструкцию, полностью основанную на оперативной памяти, следует спрашивать о масштабируемости и стоимости. Вычисления в оперативной памяти обеспечивают скорость, но ОЗУ примерно в 100 раз дороже за ГБ, чем дисковое хранилище ¹⁰, и соотношение цена/производительность stagnated в последние годы ⁴⁰. Это делает решения, полностью зависящие от оперативной памяти, не масштабируемыми и дорогостоящими для больших объёмов данных. SAP IBP (HANA) и o9 являются примерами: они гарантируют высокую производительность только если загружать огромные наборы данных в память, что гарантирует высокие затраты на оборудование (или облако) ²⁴ ²⁹. Заметно, что современный системный дизайн отходит от этого подхода – как отметил один эксперт, первоначальная мания на размещение всего в ОЗУ столкнулась с практическими ограничениями, и базы данных «вновь находят свою привязанность к диску», чтобы эффективно обрабатывать «холодные» данные ⁴¹ ⁴². Если поставщик по-прежнему застрял в мышлении, основанном только на оперативной памяти, считайте это архитектурным тревожным сигналом. Более масштабируемые поставщики будут говорить о многоуровневом хранении, облачной эластичности или аналогичных стратегиях для работы с большими объёмами данных без необходимости в бесконечном ОЗУ.
Чёрный ящик от слияний и поглощений (проблемы интеграции): Если пакет продуктов поставщика является результатом многочисленных приобретений, будьте осторожны с пробелами в интеграции и дублированием функциональности. Как мы видели, пакет Blue Yonder представляет собой случайную смесь устаревших продуктов из-за длинной серии слияний ²⁷, и модули SAP IBP произошли от разных приобретённых компаний ⁴⁶, что приводит к сложности и набору инструментов, а не к единому решению. Корпоративное программное обеспечение не смешивается легко посредством слияний и поглощений ²⁷ – если поставщик не провёл полный переинжиниринг (что редко случается из-за затрат и времени), конечный пользователь часто вынужден сам выполнять роль интегратора между модулями. Это может означать непоследовательный пользовательский опыт, дублирование ввода данных и хрупкие интерфейсы. Симптом тревожного сигнала: Внедрение продукта от поставщика требует батальона консультантов на год или более, чтобы заставить модули работать сообща – как даже отмечено в случае SAP ⁴⁷. Предпочитайте поставщиков с единой платформой или с минимальным перекрытием приобретаемых компонентов.
Противоречивые метрики и модные слова: Тонкий, но показатель тревоги возникает, когда техническая история поставщика содержит внутренние противоречия или устаревшие практики, замаскированные под новую терминологию. Один явный пример – ToolsGroup рекламирует вероятностные прогнозы, одновременно ссылаясь на улучшения MAPE ¹⁹ – признак того, что они просто посыпают старые практики новой терминологией (так как использование MAPE для оценки вероятностных прогнозов концептуально неверно). Другой пример – поставщики, заявляющие о применении «продвинутого AI», но затем оценивающие успех по старым метрикам, таким как MAPE или традиционные уровни обслуживания – это указывает на то, что они на самом деле не приняли новую парадигму. Аналогично, обратите внимание на методологии расчёта страхового запаса: поставщик может утверждать, что оптимизирует запасы с помощью AI, но если копнуть глубже и обнаружить, что они всё ещё рассчитывают страховой запас по формуле 1980-х годов (например, с предположением нормального распределения и фиксированным коэффициентом запаса), это является противоречием. Мы действительно обнаружили случаи, когда поставщики говорят о “вероятностном” или “оптимальном” управлении запасами, однако их документация раскрывает стандартные расчёты страхового запаса и использование устаревших метрик, таких как fill rate. Вывод: Несоответствия между тем, что рекламируется, и тем, что фактически измеряется/предоставляется, являются тревожным сигналом. Если поставщик заявляет о своей современности и использовании AI, но применяет те же ключевые показатели эффективности и методы десятилетней давности, их инновации, скорее всего, поверхностны.
Устаревшие алгоритмы и практики: Теория цепочек поставок развивалась (например, от детерминированных к стохастическим моделям, от одноэтапной к многоэтапной оптимизации), но некоторые программные решения не успели за ней. Опора на практики десятилетней давности – это слабость, особенно если поставщики делают вид обратного. Например, инструмент, который всё ещё в основном использует логику страхового запаса + уровень повторного заказа с фиксированными сроками поставки для управления запасами, отстает от времени, если не учитывает изменчивость спроса динамически. Мы заметили, что Slimstock явно сосредотачивается на традиционных формулах (страховой запас, EOQ) ²¹ – они прозрачно об этом заявляют, что приемлемо для базового решения, но это явно не передовые технологии. Если якобы продвинутый поставщик не проявляет прозрачности, возможно, он делает то же самое, просто не признавая этого. Еще один пример: открытые фрагменты кода Blue Yonder указывали на модели ARMA ⁴⁸, которые являются методами прогнозирования 1970-х годов, даже когда их презентация продаж говорит об AI. Infor, Oracle, John Galt и другие из нижнего эшелона также часто полагаются на методы анализа временных рядов и эвристики, которые существуют вечно (например, экспоненциальное сглаживание по Винтерсу, простые оптимизационные решатели) – они работают, но в них нет ничего современного. Тревожным сигналом является не само использование старых методов (старые методы всё ещё могут быть лучшими в некоторых случаях), а их применение при одновременном заявлении об инновационности, либо использование исключительно их, когда для решения проблемы существуют лучшие методы. Всегда выясняйте, какие алгоритмы на самом деле используются (например, «Учтена ли оптимизация запасов для всего распределения спроса или только для одного уровня обслуживания? Применяете ли вы многоэтапную оптимизацию или только расчёты для одного узла?»). Уклончивые или расплывчатые ответы указывают на то, что методология может быть устаревшей.
Отсутствие технической прозрачности: Наконец, мета-тревожный сигнал: если поставщик не предоставляет никакой технической документации – ни white papers, ни эталонной архитектуры, ни объяснения алгоритмов – это уже само по себе является предупреждением. В нашем исследовании поставщики, которые показали хорошие технические результаты (Lokad, Kinaxis, SAS и т.д.), имели хотя бы некоторый технический контент (будь то блоги, научные статьи или технические заметки). Поставщики с низкими оценками часто ограничиваются маркетинговыми брошюрами. Например, попытайтесь найти подробный технический white paper от o9 или Blue Yonder – это практически невозможно, в основном вы получаете только блестящие брошюры. В отличие от них, Lokad опубликовал 18-страничное подробное исследование рынка (на которое мы неоднократно ссылались), сравнивающее подходы поставщиков ⁴⁹ ²⁷ ²⁵, а также видео, демонстрирующие работу их алгоритмов. Когда поставщик остается скрытным относительно того, как работает его решение, стоит задуматься, не потому ли, что оно на самом деле не является особенным. Прозрачность коррелирует с достоверностью. Поставщик, прячущийся за модными словами и не раскрывающий свои методы, вероятно, использует «обычные технологии с излишним блеском».

В заключение, применение крайне скептического, инженерно-ориентированного подхода выявляет, что многие «ведущие» системы оптимизации цепочек поставок полны обещаний и лишены проверяемых инноваций. Отсекая маркетинговую болтовню, мы сосредоточились на том, что осязаемо: структурах данных, алгоритмах, производительности и доказательствах эффективности. Лучшие решения выделялись тем, что предлагали техническое содержание – доказанную точность прогнозирования, четкие архитектурные решения и откровенную документацию – а слабые обнаруживались через противоречия, расплывчатость и устаревшие основы. Это исследование служит напоминанием для любого специалиста по цепочкам поставок: не принимайте заявления поставщиков за чистую монету. Требуйте доказательств, загляните под капот и помните, что в цепочках поставок, как и во всей IT, настоящие достижения state-of-the-art обычно подтверждаются открытой наукой и прочной инженерией – а не просто высокопарными маркетинговыми заявлениями.