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

Joannes Vermorel

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

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

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

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

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

Идея, что практики в области цепей поставок должны точно настраивать свое расписание заказов, является неправильным подходом к проблеме. Заказы сопровождаются несколькими типами ограничений: календарными, MOQs, бюджетными и т. д. Некоторые ограничения могут быть гибкими, например, “нет расписания, любой день подходит, кроме 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 (Access-Control List), которая также является де-факто практикой современных корпоративных систем. Lokad также предлагает некоторые возможности персонализации, которые дополняют ACL с точки зрения пользовательского опыта.

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

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

Экспорт в Excel

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

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

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

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

Заключение

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