Количественный SCM против классической APS

Joannes Vermorel

Пока цепочки поставок получили ранний старт на пути к цифровизации еще в 80-х и 90-х годах с электронным управлением запасами и EDI (Electronic Data Interchange), многие поставщики программного обеспечения – и, следовательно, большинство их клиентов – постепенно отставали от времени в последующие два десятилетия. Хотя обновление пользовательских интерфейсов относительно просто, например, превращение настольных приложений в веб-приложения, гораздо сложнее пересмотреть основные архитектурные решения, лежащие в основе программного обеспечения. Большинство этих решений никогда не были разработаны для облачных вычислений, машинного обучения или ориентированного на мобильные устройства опыта пользователя – если перечислять лишь некоторые.

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

Таким образом, давайте внимательнее рассмотрим традиционные модули, как они обычно встречаются в передовых¹ системах APS (Advance Planning and Scheduling), с особым интересом к пополнению запасов в двухуровневой сети – например, склады и магазины – и сравним эти модули с подходом Lokad к предоставлению предиктивной оптимизации. Для краткости в дальнейшем мы будем взаимозаменяемо называть это количественной цепью поставок (видение) или Lokad (программная реализация).

Модуль календаря

Модуль календаря предоставляет механизмы для тонкой настройки условий заказа, то есть для определения когда покупать в ситуациях, когда обходиться без фиксированного цикла заказов невозможно.

Само по себе представление о том, что специалисты по цепям поставок должны тонко настраивать график заказов, является неверным подходом к решению проблемы. Заказы сопряжены с различными типами ограничений: календарными, минимального объема заказа, бюджетными и т.д. Некоторые ограничения могут быть нестрогими, например: “нет расписания, любой день годится, кроме 4 июля и 25 декабря”, или строгими, как “контейнер должен быть полностью заполнен”. В любом случае система должна искать – среди всех допустимых вариантов заказа – те, которые максимально увеличивают ROI. Этот процесс, «оптимизация», должен быть строго автоматизирован. Нет никакой причины что-либо настраивать вручную. Высокопроизводительные числовые решатели не были доступны в 80-х, но сегодня это уже не так.

Таким образом, в Lokad мы собираем все соответствующие ограничения, которые сами по себе рассматриваются как данные, то есть «базу данных» допустимых графиков заказов, и затем запускаем соответствующие числовые решатели для выполнения задачи.

Смотрите также: Люди в современной цепи поставок.

Модуль событий

Модуль событий управляет всплесками и падениями спроса, связанными с плановыми событиями, такими как запуск нового продукта, рекламные кампании, ценовые акции, выпуск новых каталогов и флаеров.

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

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

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

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

Модуль ускоренного управления заказами

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

Весь подход, основанный на исключениях и оповещениях, является довольно устаревшей перспективой для смягчения проблем в сложных системах программного обеспечения. Этот подход был широко принят поставщиками программного обеспечения еще в 80-х и 90-х годах, поскольку исключения и оповещения достаточно просто реализовать на основе SQL базы данных. Для этого требуется всего лишь SELECT-запрос с несколькими условиями WHERE. Однако в целом данный подход неэффективно использует ограниченные ресурсы, которыми являются специалисты по цепям поставок, так как он склонен быстро перегружать их до такой степени, что оповещения уже не являются «оповещениями», и теряется ощущение неотложности или необходимость принятия мер.

Lokad предпочитает и обеспечивает строгую приоритизацию на основе ROI для «элементов» интереса, которые представлены специалистам по цепям поставок. Как правило, генерировать 1 миллион чисел в день легко, а производить 10 чисел, достойных внимания человека, каждый день – сложно. Просроченные заказы не всегда имеют значение: возможно, уровень запасов все еще высок, или, может быть, это просто повторяющаяся проблема для этого поставщика, которая продолжается вечно. Неполные поставки также должны автоматически обрабатываться для корректировки платежей поставщика, но они не всегда требуют немедленного реагирования. Чтобы «элемент» имел ROI, он должен быть действенным, и ROI представляет собой соответствующую оценку эффективности действия. Lokad выделяется за счет предоставления индивидуальной приоритизации, точно адаптированной к специфике интересующей цепочки поставок.

Модуль сделки/предварительной закупки

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

Большинство систем APS изначально были реализованы с наивной точки зрения, где предполагалось, что единичная цена является достаточной с точки зрения ценообразования для вычисления оптимального объема заказа. Однако реальность имела более высокий уровень детализации. Поставщики часто имеют сложные ценовые структуры: минимальные объемы заказа, ценовые уступки, скидки по квартальным квотам, временные сделки и т.д.

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

Модуль анализа заказов

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

Это еще один пример несколько упрощенного дизайна программного обеспечения, ориентированного на простоту реализации. Еще в 80-х годах было сложно проводить анализ на уровне всей сети, поэтому большинство поставщиков программного обеспечения по умолчанию использовали дизайн, предполагающий «изоляцию SKU». Каждый SKU обрабатывается изолированно, и вычисленные статистические оценки — например, ожидаемая вероятность отсутствия товара для следующего цикла заказов — полностью специфичны для конкретного SKU.

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

На практике Lokad предоставляет приоритизированные объемы заказов, которые напрямую отражают экономику цепочки поставок от начала до конца.

Модуль переноса избыточных запасов

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

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

Таким образом, у Lokad есть встроенные возможности для оптимизации на уровне сети в подобном роде, фактически перебирая все доступные варианты перемещения запасов. Самая сложная часть этой задачи — правильно отразить экономическое трение, связанное с перемещением запасов. Действительно, трение обычно не отражается должным образом при перемещении запасов на уровне SKU. Например, транспортные расходы, как правило, крайне нелинейны: если требуется отправить грузовик, нужно максимально использовать его доступную емкость.

К сожалению, число вариантов растет намного быстрее, чем число SKU. Рассмотрим сеть, в которой 2000 товаров хранятся на 10 складах, что в сумме дает 10 x 2000 = 20 000 SKU. Общее число связей, которые необходимо рассмотреть для перемещения запасов, составляет 10 x (10 - 1) * 2000 = 180 000 связей, что намного превышает исходное число SKU. Для читателей, знакомых с алгоритмами, это прямой пример квадратичной сложности.

Однако, учитывая современные вычислительные мощности, этот конкретный случай квадратичной сложности в основном не является проблемой — при условии, что основное программное обеспечение было должным образом спроектировано для такого типа численного исследования. Действительно, сети поставок очень редко превышают 10 000 точек, даже если речь идет о самых крупных компаниях; и несколько эвристик могут быть использованы для значительного сокращения числа связей, которые необходимо исследовать на практике, так как многие пары точек не имеют смысла, например, перебалансировка запасов между Парижем и Сиднеем.

Однако еще в 80-х и 90-х годах, из-за доступного на то время вычислительного оборудования, системы APS уже с трудом справлялись с числом SKU. Естественно, в этом контексте решение проблем квадратичной сложности было просто невозможно.

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

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

Модуль планирования

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

Подход Lokad начинается с установления четкого разделения между фактами и прогнозами. Рассмотрим сеть B2B-ритейла. Если клиент 10 февраля объявляет, что закажет 1000 единиц с ожидаемой датой поставки 1 марта, то это объявление является фактом. Если у этого клиента есть привычка в последний момент изменять предполагаемую дату доставки — обычно откладывая её на 1 неделю — то эту закономерность необходимо учитывать. Однако анализ этой закономерности относится к категории прогнозов.

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

Кроме того, сбор фактов не должен осуществляться аналитическим слоем, ни в Lokad, ни в APS. И не потому, что программное обеспечение не способно на это. Создание ПО для сбора фактов относительно просто, но оно приводит к возникновению большого количества случайной зависимости от поставщика. Ведь как только данные начинают поступать в систему компании, эта система становится де факто главным контроллером этих данных.

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

Модуль прогнозов

Модули прогнозов позволяют покупателям создавать отчёты, прогнозирующие будущий спрос и будущие закупки до года вперёд. Эти прогнозы могут быть переданы поставщикам, чтобы они могли планировать свои производственные мощности точнее.

Необработанные прогнозы вредны и больше не считаются здравой практикой в цепочках поставок. Ознакомьтесь с антипаттерном голых прогнозов для получения дополнительной информации. Это не означает, что у Lokad отсутствуют возможности прогнозирования, у нас они есть. Однако мы утверждаем, что классический подход к прогнозированию временных рядов просто ошибочен и должен быть прекращён. Классические временные ряды могут работать для товаров с очень высоким объёмом и стабильным спросом, но для всего остального — особенно для хаотичного или прерывистого спроса — оптимальным решением является вероятностное прогнозирование.

Более того, исторические модели прогнозирования временных рядов — например, Holt-Winters или ARIMA — испытывали серьёзные недостатки, если история продукта была слишком короткой, слишком хаотичной, слишком атипичной или имела слишком низкий объём… Большинство поставщиков ПО реагировали на эти проблемы двумя подходами, каждый из которых имел свои недостатки:

• Человеческие копроцессоры: поскольку модель прогнозирования часто выдаёт бессмысленные результаты, система привлекает человеческих операторов — то есть планировщиков — в качестве «копроцессоров», чтобы вручную корректировать прогнозы, когда «числа кажутся неверными». К сожалению, эта задача бесконечна, так как прогнозы нужно постоянно обновлять, что заставляет планировщиков попадать в нескончаемый цикл ручных корректировок. Такая практика также приводит к нежелательным побочным эффектам, когда операторы начинают считать прогнозы ошибочными и, основываясь исключительно на интуиции, исправляют их даже тогда, когда они верны.
• Соревнование моделей: поскольку каждая модель прогнозирования временных рядов обладает своими сильными и слабыми сторонами, логика подсказывает, что соревнование множества моделей позволит системе «выбрать» наилучшую модель для каждой конкретной ситуации. К сожалению, это терпит неудачу по двум причинам. Во-первых, все модели основаны на временном ряде и, следовательно, подвержены одним и тем же ограничениям. Во-вторых, все модели являются «классическими» и не способны предоставить вероятностные прогнозы, необходимые для цепочки поставок.

Более того, прогнозирование касается не только спроса. Также следует прогнозировать сроки поставки. Кроме того, имеет значение структура цепочки поставок. В B2B стабильный поток продаж может скрывать тот факт, что все заказы поступают от одного клиента. Если этот клиент будет потерян, многие товары мгновенно окажутся избыточными или превратятся в «мертвый» запас. Правильная предиктивная оптимизация цепочки поставок должна учитывать этот риск. Технология Lokad разработана с учетом этого.

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

Модуль безопасности

На удивление, в некоторых APS функции безопасности не встроены по умолчанию в систему, а предоставляются как отдельный модуль. Цель модуля безопасности — предотвратить доступ для некоторых пользователей. Он также позволяет управлять действиями компонентов и ограничивать просмотр важных разделов системы, таких как факторы контроля компании, администрирование товаров, управление поставщиками, заказы, сделки и другие компоненты.

В терминологии программирования здесь речь идёт о поперечных задачах аутентификации и авторизации.

• Аутентификация гарантирует, что конечные пользователи, выполняющие действия в системе, действительно являются теми, за кого система их принимает. Здесь Lokad применяет современный подход, согласно которому аутентификацию необходимо делегировать всякий раз, когда это возможно. Конечные пользователи не должны иметь ещё один пароль. Вместо этого Lokad использует SAML как де факто отраслевой стандарт для делегирования аутентификации федеративному управлению идентификацией (FIM).
• Авторизация обеспечивает детальный контроль над тем, кто что может делать в системе. Здесь Lokad использует обширную каноническую систему ACL (список контроля доступа), которая также является де факто практикой современных корпоративных систем. Кроме того, Lokad обладает возможностями персонализации, которые дополняют ACL с точки зрения пользовательского опыта.

Lokad активирует все свои функции безопасности по умолчанию, независимо от того, какой пакет был изначально продан нашим клиентам. Мы считаем, что опциональная безопасность⁴ — ужасная практика со стороны поставщиков ПО. Обеспечение безопасности ПО и так чрезвычайно сложно; такая практика только усугубляет ситуацию.

Если быть справедливыми, аспект ACL, вероятно, является наименее сложной проблемой в области безопасности программного обеспечения. Более интересный вопрос заключается в том, насколько архитектура системы обеспечивает безопасность по замыслу. Однако ответ на этот вопрос выходит за рамки данной статьи.

Экспорт в Excel

Модуль экспорта в Excel предоставляет простой способ переноса данных для использования в других системах или для анализа.

Поскольку создание таблиц Excel⁵ достаточно просто, многие поставщики, включая Lokad, предлагают возможности в этой области. Однако более тщательный анализ показывает, что большинство поставщиков предоставляют лишь недоделанные решения. Рассмотрим основные моменты качественной реализации экспорта в Excel:

• Полная история экспорта: система должна предоставлять возможность отслеживать и повторно загружать каждый Excel-файл, когда-либо экспортированный. Ведь при обнаружении неверных данных в таблице — проблема, которая произойдёт (даже если только из-за неправильного ввода данных) — отсутствие полной прослеживаемости пути кода, приведшего к созданию этой таблицы, значительно усложнит, замедлит — а иногда и предотвратит — попытки отладки и исправления проблемы.
• Максимальное использование возможностей таблиц: специалисты ожидают возможность генерации насыщенных таблиц до 1 миллиона строк⁶, то есть фактически предела, установленного самим Excel. Таким образом, система должна уметь генерировать тяжёлые таблицы, чтобы не мешать специалистам, которые хотят самостоятельно анализировать данные в привычном инструменте. Само собой, специалисты также ожидают, что такие объёмные экспорты будут выполняться быстро.
• Встроенная защита от атак через электронные таблицы: Excel является опасным вектором атак для крупных организаций. К сожалению, обеспечение безопасности таблиц, генерируемых системой, не может быть сделано задним числом; это должно быть неотъемлемой частью дизайна практически с первого дня.
• Программируемая настройка экспорта: Работа с двумя программными продуктами — APS и Excel — уже достаточно сложна для специалистов по цепям поставок. Ситуация не должна ухудшаться из-за таблиц, которым всегда требуется дополнительная обработка после экспорта для придания им пригодности. Это подразумевает, что всё происходит до экспорта, внутри APS. Таким образом, APS должен обладать программируемыми возможностями для правильной подготовки таблиц перед экспортом.

Lokad предоставляет всё вышеперечисленное, в то время как большинство наших конкурентов — нет. Дьявол кроется в деталях.

Заключение

Мы убеждены, что Lokad представляет собой более простое программное обеспечение, чем большинство APS на рынке. Однако наша способность обеспечивать эффективность цепей поставок с помощью предиктивных технологий выше. Действительно, большая часть сложности APS является случайной, возникшей в результате архитектурных решений, принятых десятилетия назад для давно ушедших внутренних проблем. Однако большинство архитектурных решений, однажды принятых, не могут быть изменены.