Прогнозирование срока поставки - Лекция 5.3

00:00 Введение
02:55 Вопрос сроков поставки
09:25 Реальные сроки поставки (1/3)
12:13 Реальные сроки поставки (2/3)
13:44 Реальные сроки поставки (3/3)
16:12 История до сих пор
19:31 ETA: 1 час от сейчас
22:16 CPRS (резюме) (1/2)
23:44 CPRS (резюме) (2/2)
24:52 Кросс-валидация (1/2)
27:00 Кросс-валидация (2/2)
27:40 Сглаживание сроков поставки (1/2)
31:29 Сглаживание сроков поставки (2/2)
40:51 Составление срока поставки (1/2)
44:19 Составление срока поставки (2/2)
47:52 Квазисезонный срок поставки
54:45 Модель срока поставки лог-логистического типа (1/4)
57:03 Модель срока поставки лог-логистического типа (2/4)
01:00:08 Модель срока поставки лог-логистического типа (3/4)
01:03:22 Модель срока поставки лог-логистического типа (4/4)
01:05:12 Неполная модель срока поставки (1/4)
01:08:04 Неполная модель срока поставки (2/4)
01:09:30 Неполная модель срока поставки (3/4)
01:11:38 Неполная модель срока поставки (4/4)
01:14:33 Спрос в течение срока поставки (1/3)
01:17:35 Спрос в течение срока поставки (2/3)
01:24:49 Спрос в течение срока поставки (3/3)
01:28:27 Модульность прогностических техник
01:31:22 Заключение
01:32:52 Предстоящая лекция и вопросы аудитории

Описание

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

Полный текст

Добро пожаловать на эту серию лекций по цепи поставок. Меня зовут Йоханнес Верморель, и сегодня я буду говорить о “Прогнозировании сроков поставки”. Сроки поставки, и вообще все применимые задержки, являются фундаментальным аспектом цепи поставок при попытке сбалансировать предложение и спрос. Нужно учитывать задержки, которые возникают. Например, давайте рассмотрим спрос на игрушку. Правильное предвидение сезонного пика спроса перед Рождеством не имеет значения, если товары получены в январе. Сроки поставки определяют мелкий шрифт планирования так же, как и спрос.

Сроки поставки варьируются; они очень варьируются. Это факт, и я представлю некоторые доказательства через минуту. Однако на первый взгляд это предложение вызывает недоумение. Непонятно, почему срок поставки должен так сильно варьироваться. У нас есть производственные процессы, которые могут работать с допуском менее микрометра. Более того, в рамках производственного процесса мы можем контролировать эффект, скажем, применение источника света, до одной микросекунды. Если мы можем контролировать преобразование материи до микрометра и до микросекунды, с достаточной усердностью, мы должны быть в состоянии контролировать поток спроса с сопоставимой степенью точности. Или может быть и нет.

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

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

Согласно основной литературе по цепи поставок, сроки поставки едва стоят пары сносок. Это утверждение может показаться экстравагантным преувеличением, но, боюсь, это не так. Согласно Google Scholar, специализированному поисковому движку, посвященному научной литературе, запрос “прогнозирование спроса” за 2021 год возвращает 10 500 статей. Беглый осмотр результатов показывает, что действительно подавляющее большинство этих записей обсуждают прогнозирование спроса во всех возможных ситуациях и рынках. Тот же запрос, также за 2021 год, в Google Scholar для “прогнозирование срока поставки” возвращает 71 результат. Результаты для запроса прогнозирования срока поставки настолько ограничены, что всего за несколько минут можно ознакомиться с исследованиями за весь год.

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

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

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

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

Майами - это вымышленная авиационная MRO. MRO означает обслуживание, ремонт и капитальный ремонт. Каждому лайнеру ежегодно требуются тысячи деталей, чтобы продолжать летать. Отсутствие одной детали, вероятно, приведет к приземлению самолета. Длительность ремонта ремонтопригодной детали, также называемая TAT (время оборота), определяет, когда вращающаяся деталь снова становится пригодной для использования. Однако TAT варьируется от нескольких дней до нескольких месяцев, в зависимости от объема ремонта, который не известен на момент снятия детали с самолета. Эти TAT требуют прогноза.

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

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

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

Таким образом, давайте взглянем на несколько реальных сроков поставки. На экране три гистограммы, которые были построены путем компиляции наблюдаемых сроков поставки, связанных с тремя механическими деталями. Эти детали заказываются у одного и того же поставщика, расположенного в Западной Европе. Заказы поступают от компании, также расположенной в Западной Европе. Ось x указывает на продолжительность наблюдаемых сроков поставки, выраженных в днях, а ось y указывает на количество наблюдений, выраженных в процентах. В дальнейшем все гистограммы будут придерживаться тех же соглашений, с осью x, связанной с продолжительностью, выраженной в днях, и осью y, отражающей частоту. Из этих трех распределений мы уже можем сделать несколько наблюдений.

Во-первых, данные разрежены. У нас есть всего несколько десятков точек данных, и эти наблюдения были собраны на протяжении нескольких лет. Эта ситуация типична; если компания делает заказы только раз в месяц, то потребуется почти десятилетие, чтобы собрать более 100 наблюдений сроков поставки. Таким образом, все, что мы делаем в терминах статистики, должно быть ориентировано на малые числа, а не на большие. В самом деле, мы редко получаем роскошь иметь дело с большими числами.

Во-вторых, сроки поставки непостоянны. У нас есть наблюдения, варьирующиеся от нескольких дней до квартала. Хотя всегда можно вычислить средний срок поставки, полагаться на какое-либо среднее значение для любой из этих деталей было бы неразумно. Также очевидно, что ни одно из этих распределений даже отдаленно не является нормальным.

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

Давайте взглянем на вторую партию сроков поставки. Эти продолжительности отражают время, необходимое для ремонта трех различных деталей самолета. Первое распределение, по-видимому, имеет два мода плюс хвост. Когда распределение имеет два мода, это обычно намекает на существование скрытой переменной, которая объясняет эти два мода. Например, могут быть два различных типа ремонтных операций, каждый тип связан со своим сроком поставки. Второе распределение, по-видимому, имеет один мод плюс хвост. Этот мод соответствует относительно короткой продолжительности, около двух недель. Это может отражать процесс, когда деталь сначала проверяется, и иногда деталь считается пригодной для использования без дальнейшего вмешательства, отсюда и гораздо более короткий срок поставки. Третье распределение, по-видимому, полностью распределено, без очевидного мода или хвоста. Здесь могут быть задействованы несколько процессов ремонта, которые объединяются вместе. Разреженность данных, с всего тремя десятками наблюдений, затрудняет дальнейшие выводы. Мы вернемся к этому третьему распределению позже в этой лекции.

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

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

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

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

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

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

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

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

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

Сегодня мы сосредоточимся на сроках поставки. Мы только что увидели, почему важны сроки поставки, и только что рассмотрели короткую серию реальных сроков поставки. Таким образом, мы продолжим с элементами моделирования сроков поставки. Поскольку я буду принимать вероятностную перспективу, я кратко представлю Continuous Rank Probability Score (CRPS), метрику для оценки качества вероятностного прогноза. Я также представлю кросс-валидацию и вариант кросс-валидации, который подходит для нашей вероятностной перспективы. Имея эти инструменты в руках, мы представим и оценим нашу первую не-наивную вероятностную модель для сроков поставки. Данные о сроках поставки разрежены, и первым пунктом в нашем повестке дня является сглаживание этих распределений. Сроки поставки могут быть разложены на серию промежуточных фаз. Таким образом, предполагая, что некоторые разложенные данные о сроках поставки доступны, нам нужно что-то, чтобы воссоздать эти сроки поставки, сохраняя вероятностный угол.

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

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

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

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

Среди этих инструментов есть непрерывный ранговый вероятностный балл (CRPS). Формула дана на экране. CRPS является обобщением метрики L1, то есть абсолютной ошибки, но для вероятностных распределений. Обычный вариант CRPS сравнивает распределение, названное здесь F, с наблюдением, названным здесь X. Значение, полученное из функции CRPS, однородно с наблюдением. Например, если X - это срок поставки, выраженный в днях, то значение CRPS также выражается в днях.

CRPS можно обобщить для сравнения двух распределений. Это то, что делается на экране. Это всего лишь незначительное изменение предыдущей формулы. Суть этой метрики остается неизменной. Если F - это истинное распределение сроков поставки, а F_hat - это оценка распределения сроков поставки, то CRPS выражается в днях. CRPS отражает количество различий между двуми распределениями. CRPS также можно интерпретировать как минимальное количество энергии, которое требуется для переноса всей массы от первого распределения, чтобы оно приняло точную форму второго распределения.

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

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

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

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

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

Давайте вернемся к одному из реальных сроков поставки, которые мы ранее видели на экране. Слева гистограмма связана с третьим распределением времени ремонта авиации. Это те же наблюдения, что и ранее, и гистограмма просто была растянута вертикально. Таким образом, две гистограммы слева и справа имеют одинаковый масштаб. Для левой гистограммы у нас около 30 наблюдений. Это не так много, но это уже больше, чем мы часто получаем.

Гистограмма слева называется эмпирическим распределением. Это буквально сырая гистограмма, полученная из наблюдений. В гистограмме есть одно ведро для каждой продолжительности, выраженной в целом числе дней. Для каждого ведра мы подсчитываем количество наблюдаемых сроков поставки. Из-за разреженности эмпирическое распределение выглядит как штрих-код.

Здесь есть проблема. Если у нас есть два наблюдаемых срока поставки ровно за 50 дней, имеет ли смысл говорить, что вероятность наблюдения либо 49 дней, либо 51 день равна ровно нулю? Нет. Очевидно, что существует спектр продолжительностей; мы просто случайно не имеем достаточно точек данных, чтобы наблюдать реальное базовое распределение, которое, скорее всего, гораздо более гладкое, чем это распределение в виде штрих-кода.

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

Через минуту результаты выставлены на показ. Ошибка CRPS, связанная с распределением в виде штрих-кода, составляет 1,6 дня, в то время как ошибка CRPS, связанная с гладким распределением, составляет 1,4 дня. Эти две цифры были получены с помощью кросс-валидации. Меньшая ошибка указывает на то, что в смысле CRPS распределение справа является наиболее точным из двух. Разница в 0,2 между 1,4 и 1,6 не так велика; однако ключевой момент здесь заключается в том, что у нас есть гладкое распределение, которое не прерывается на определенных промежуточных продолжительностях с нулевой вероятностью. Это разумно, поскольку наше понимание ремонтов говорит нам, что эти продолжительности, скорее всего, окажутся реальными, если ремонты повторяются. CRPS не отражает истинной глубины улучшения, которое мы только что привнесли, сгладив распределение. Однако, по крайней мере, снижение CRPS подтверждает, что это преобразование обосновано с точки зрения статистики.

Давайте теперь взглянем на исходный код, который создал эти две модели и вывел эти две гистограммы на экран. Все вместе, это достигается в 12 строках кода, если исключить пустые строки. Как обычно в этой серии лекций, код написан на Envision, специфическом для предметной области языке программирования Lokad, посвященном прогнозной оптимизации цепочек поставок. Однако здесь нет магии; эту логику можно было бы написать на Python. Но для рода проблем, которые мы рассматриваем в этой лекции, Envision более краток и самодостаточен.

Давайте рассмотрим эти 12 строк кода. В строках 1 и 2 мы читаем Excel таблицу, которая имеет один столбец данных. В таблице содержится 30 наблюдений. Эти данные собираются в таблице под названием “H”, которая имеет один столбец под названием “days”. В строке 4 мы строим эмпирическое распределение. Переменная “R” имеет тип данных “ranvar”, и справа от присваивания функция “ranvar” является агрегатором, который принимает наблюдения на вход и возвращает гистограмму, представленную типом данных “ranvar”. В результате тип данных “ranvar” предназначен для одномерных целочисленных распределений. Мы ввели тип данных “ranvar” в предыдущей лекции этой главы. Этот тип данных гарантирует постоянный объем памяти и постоянное время вычисления для каждой операции. Недостатком “ranvar” как типа данных является то, что вовлечена потеря данных при сжатии, хотя потеря данных, вызванная сжатием, была спроектирована так, чтобы быть незначительной для целей цепочки поставок.

В строке 5 мы сглаживаем распределение с помощью встроенной функции под названием “smooth”. Под капотом эта функция заменяет исходное распределение на смесь распределений Пуассона. Каждый корзину гистограммы преобразуется в распределение Пуассона со средним, равным целочисленной позиции корзины, и, наконец, смесь назначает вес каждому распределению Пуассона пропорционально весу самой корзины. Другой способ понять, что делает эта функция “smooth”, - представить, что она эквивалентна замене каждого отдельного наблюдения на распределение Пуассона со средним, равным самому наблюдению. Все эти распределения Пуассона, по одному на наблюдение, затем смешиваются. Смешивание означает усреднение соответствующих значений корзин гистограммы. Переменные “ranvar” “R” и “S” не будут использоваться снова до строк 14 и 15, где они отображаются.

В строке 7 мы начинаем блок Монте-Карло. Этот блок - это своего рода цикл, и он будет выполнен 100 раз, как указано 100 значениями, которые следуют сразу после ключевого слова Монте-Карло. Блок Монте-Карло предназначен для сбора независимых наблюдений, которые генерируются в соответствии с процессом, включающим степень случайности. Вы можете задаться вопросом, почему в Envision есть специальная конструкция Монте-Карло, а не просто цикл, как обычно бывает в основных языках программирования. Оказывается, что наличие специальной конструкции приносит значительные преимущества. Во-первых, это гарантирует, что итерации действительно независимы, вплоть до семян, используемых для получения псевдослучайности. Во-вторых, это предлагает явную цель для автоматического распределения рабочей нагрузки по нескольким ядрам процессора или даже по нескольким машинам.

В строке 8 мы создаем случайный вектор булевых значений в таблице “H”. С этой строкой мы создаем независимые случайные значения, называемые отклонениями (истинными или ложными), для каждой строки таблицы “H”. Как обычно в Envision, циклы абстрагированы через массивное программирование. С этими булевыми значениями мы разделяем таблицу “H” на две группы. Это случайное разделение используется для процесса кросс-валидации.

В строках 9 и 10 мы создаем два “ranvars” с именами “A” и “B” соответственно. Мы снова используем агрегатор “ranvar”, но на этот раз мы применяем фильтр с ключевым словом “when” сразу после вызова агрегатора. “A” генерируется только с использованием строк, где значение в “a” истинно; для “B” это противоположно. “B” генерируется только с использованием строк, где значение в “a” ложно.

В строках 11 и 12 мы собираем интересующие нас данные из блока Монте-Карло. В Envision ключевое слово “sample” может быть размещено только в блоке Монте-Карло. Оно используется для сбора наблюдений, которые делаются при многократном прохождении процесса Монте-Карло. В строке 11 мы вычисляем среднюю ошибку, выраженную в терминах CRPS, между двумя эмпирическими распределениями: подвыборкой из исходного набора времен ведения. Ключевое слово “sample” указывает, что значения собираются в течение итераций Монте-Карло. Агрегатор “AVG”, который означает “среднее” справа от присваивания, используется для получения одной оценки в конце блока.

В строке 12 мы делаем почти то же самое, что и в строке 11. На этот раз, однако, мы применяем функцию “smooth” к “ranvar” “B”. Мы хотим оценить, насколько близка гладкая вариант от наивного эмпирического распределения. Оказывается, что он ближе, по крайней мере в терминах CRPS, чем его оригинальные эмпирические аналоги.

В строках 14 и 15 мы выводим на экран гистограммы и значения CRPS. Эти строки генерируют фигуры, которые мы видели на предыдущем слайде. Этот скрипт дает нам базовую линию для качества эмпирического распределения нашей модели. В самом деле, хотя эта модель, “штрих-код”, безусловно, наивна, это все же модель, и причем вероятностная. Таким образом, этот скрипт также дает нам лучшую модель, по крайней мере в смысле CRPS, через гладкий вариант исходного эмпирического распределения.

Сейчас, в зависимости от вашего знакомства с языками программирования, это может показаться сложным для понимания. Однако, я хотел бы подчеркнуть, насколько просто создать разумное вероятностное распределение, даже когда у нас нет больше, чем несколько наблюдений. Хотя у нас есть 12 строк кода, только строки 4 и 5 представляют собой настоящую моделирующую часть упражнения. Если бы нас интересовал только гладкий вариант, то “ranvar” “S” мог бы быть написан одной строкой кода. Таким образом, это буквально однострочник в терминах кода: сначала применить агрегацию ranvar, а затем применить гладкий оператор, и мы закончили. Остальное - это просто инструментарий и отображение. С правильными инструментами, вероятностное моделирование, будь то срок поставки или что-то еще, может быть сделано чрезвычайно простым. Здесь нет грандиозной математики, нет грандиозного алгоритма, нет грандиозных программных компонентов. Это просто и удивительно так.

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

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

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

Формула для суммы двух независимых, одномерных, целочисленных случайных величин представлена на экране. Эта формула просто говорит, что если мы получаем общую продолжительность Z дней, и если у нас есть K дней для первой случайной величины X, то у нас должно быть Z минус K дней для второй случайной величины Y. Этот тип суммирования известен, в общем говоря, в математике как свертки.

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

Давайте применим эти свертки на практике. Рассмотрим время транзита, которое можно разложить на две фазы: задержку при отправке, за которой следует задержка при прохождении таможни. Мы хотим смоделировать эти две фазы с помощью двух независимых случайных величин, а затем воссоздать время транзита, сложив эти две случайные величины.

На экране гистограммы слева создаются скриптом справа. В строке 1 задержка при отправке моделируется как свертка распределения Пуассона плюс константа. Функция Пуассона возвращает тип данных “ranvar”; добавление трех имеет эффект смещения распределения вправо. Получившийся “ranvar” присваивается переменной “C”. Этот “ranvar” отображается в строке 3. Его можно увидеть слева на самой верхней гистограмме. Мы узнаем форму распределения Пуассона, которое было смещено вправо на несколько единиц, в данном случае на три единицы. В строке два таможенное оформление моделируется как смесь Дирака в нуле и Пуассона в пяти. Дирак в нуле происходит восемьдесят процентов времени; вот что означает эта константа 0.8. Она отражает ситуации, когда большую часть времени товары даже не проверяют на таможне и проходят без каких-либо заметных задержек. В противном случае, двадцать процентов времени товары проверяются на таможне, и задержка моделируется как распределение Пуассона со средним значением пять. Получившийся ranvar присваивается переменной с именем D. Этот ranvar отображается в строке четыре и виден слева на средней гистограмме. Этот асимметричный аспект отражает то, что большую часть времени таможня не добавляет никакой задержки.

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

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

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

Дифференцируемое программирование - это сочетание двух техник: стохастического градиентного спуска и автоматического дифференцирования. Стохастический градиентный спуск - это техника оптимизации, которая подталкивает параметры одно наблюдение за другим в противоположном направлении градиентов. Автоматическое дифференцирование - это техника компиляции, как в компиляторе языка программирования; она вычисляет градиенты для всех параметров, которые появляются в общей программе.

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

На строках с одного по шесть мы представляем некоторые имитационные заказы на закупку с четырьмя наблюдениями, с датой заказа и датой получения. На практике эти данные не были бы жестко закодированы, но мы бы загрузили эти исторические данные из систем компании. На строках восьмой и девятой мы вычисляем, пересекается ли срок выполнения с Китайским Новым годом. Переменная “T.overlap_CNY” - это булев вектор; он указывает, затрагивает ли наблюдение Китайский Новый год или нет.

На строке 12 мы вводим блок “autodiff”. Таблица T используется как таблица наблюдений, и есть 1000 эпох. Это означает, что каждое наблюдение, то есть каждая строка в таблице T, будет посещена тысячу раз. Один шаг стохастического градиентного спуска соответствует одному выполнению логики внутри блока “autodiff”.

На строках 13 и 14 объявляются два скалярных параметра. Блок “autodiff” будет изучать эти параметры. Параметр A отражает базовый срок выполнения без учета эффекта Китайского Нового года, а параметр B отражает дополнительную задержку, связанную с Китайским Новым годом. На строке 15 мы вычисляем X, прогноз срока выполнения нашей модели. Это детерминированная модель, а не вероятностная; X - это точный прогноз срока выполнения. Правая сторона присваивания проста: если наблюдение пересекается с Китайским Новым годом, то мы возвращаем базовое значение плюс компонент Нового года; в противном случае мы возвращаем только базовое значение. Поскольку блок “autodiff” принимает только одно наблюдение за раз, на строке 15 переменная T.overlap_CNY относится к скалярному значению, а не к вектору. Это значение соответствует той строке, которую выбрали в качестве строки наблюдения в таблице T.

Параметры A и B обернуты в экспоненциальную функцию “exp”, что является небольшим трюком дифференцируемого программирования. Действительно, алгоритм, который управляет стохастическим градиентным спуском, обычно достаточно консервативен, когда речь идет о приращениях параметров. Таким образом, если мы хотим изучить положительный параметр, который может стать больше, скажем, 10, то обертывание этого параметра в экспоненциальный процесс ускоряет сходимость.

На строке 16 мы возвращаем среднеквадратичную ошибку между нашим прогнозом X и наблюдаемой продолжительностью, выраженной в днях (T.days). Опять же, внутри этого блока “autodiff” T.days - это скалярное значение, а не вектор. Поскольку таблица T используется как таблица наблюдений, возвращаемое значение рассматривается как потеря, которая минимизируется через стохастический градиентный спуск. Автоматическое дифференцирование распространяет градиенты от потери обратно к параметрам A и B. Наконец, на строке 19 мы отображаем два значения, которые мы изучили, соответственно, для A и B, которые являются базовым и новогодним компонентом нашего срока выполнения.

Это завершает наше повторное введение дифференцируемого программирования как универсального инструмента, который изучает статистические закономерности. Отсюда мы будем возвращаться к блокам “autodiff” с более сложными ситуациями. Однако давайте еще раз подчеркнем, что даже если это может показаться немного сложным, здесь на самом деле ничего сложного нет. Возможно, самым сложным фрагментом кода в этом скрипте является внутренняя реализация функции “ChineseYearStart”, вызываемой на строке восемь, которая является частью стандартной библиотеки Envision. В нескольких строках кода мы вводим модель с двумя параметрами и изучаем эти параметры. Еще раз, это простота замечательна.

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

На экране у нас функция плотности вероятности лог-логистического распределения. Это параметрическое распределение, которое зависит от двух параметров, альфа и бета. Параметр альфа - это медиана распределения, а параметр бета определяет форму распределения. Справа можно получить короткую серию форм через различные значения бета. Хотя эта формула плотности может выглядеть пугающей, это буквально учебный материал, как формула для вычисления объема сферы. Вы можете попытаться расшифровать и запомнить эту формулу, но это даже не обязательно; вам просто нужно знать, что существует аналитическая формула. Как только вы знаете, что формула существует, найти ее в Интернете занимает менее минуты.

Наша цель - использовать лог-логистическое распределение для изучения вероятностной модели срока выполнения. Для этого мы собираемся минимизировать логарифмическую вероятность. Действительно, в предыдущей лекции в рамках этой пятой главы мы видели, что существует несколько метрик, которые подходят для вероятностной перспективы. Некоторое время назад мы вернулись к CRPS (Continuous Ranked Probability Score). Здесь мы возвращаемся к логарифмической вероятности, которая принимает байесовскую перспективу.

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

Таким образом, чтобы вычислить логарифмическую вероятность лог-логистического распределения, мы применяем логарифм к его функции плотности вероятности. Аналитическое выражение дано на экране. Это выражение может быть реализовано, и это именно то, что делается в трех строках кода ниже.

В строке один вводится функция “L4”. L4 означает “логарифмическая вероятность лог-логистического” - да, это много L и много логов. Эта функция принимает три аргумента: два параметра альфа и бета, плюс наблюдение x. Эта функция возвращает логарифм вероятности. Функция L4 украшена ключевым словом “autodiff”; ключевое слово указывает, что эта функция предназначена для дифференцирования через автоматическое дифференцирование. Другими словами, градиенты могут течь назад от возвращаемого значения этой функции к ее аргументам, параметрам альфа и бета. Технически градиент течет назад через наблюдение x также; однако, поскольку мы будем сохранять наблюдения неизменными во время процесса обучения, градиенты не окажут никакого влияния на наблюдения. В строке три мы получаем буквальную транскрипцию математической формулы прямо над скриптом.

Давайте теперь соберем все вместе со скриптом, который изучает параметры вероятностной модели времени выполнения на основе лог-логистического распределения. В строках один и три мы генерируем нашу имитационную тренировочную выборку. В реальных условиях мы бы использовали исторические данные вместо генерации имитационных данных. В строке один мы создаем “ranvar”, который представляет исходное распределение. Для выполнения упражнения мы хотим изучить обратно эти параметры, альфа и бета. Функция лог-логистического распределения является частью стандартной библиотеки Envision и возвращает “ranvar”. В строке два мы создаем таблицу “H”, которая содержит 1 000 записей. В строке три мы рисуем 1 000 отклонений, которые случайным образом выбираются из исходного распределения “R”. Этот вектор “H.days” представляет тренировочную выборку.

В строке шесть у нас есть блок “autodiff”; здесь происходит обучение. В строках семь и восемь мы объявляем два параметра, альфа и бета, и чтобы избежать числовых проблем, таких как деление на ноль, к этим параметрам применяются границы. Альфа должна оставаться больше 0,01, а бета должна оставаться больше 1,0. В строке девять мы возвращаем потерю, которая является противоположностью логарифма вероятности. Действительно, по соглашению, блоки “autodiff” минимизируют функцию потерь, и поэтому мы хотим максимизировать вероятность, отсюда и минус. Функция “log_likelihood.logistic” является частью стандартной библиотеки Envision, но под капотом это просто функция “L4”, которую мы реализовали на предыдущем слайде. Так что здесь нет никакой магии; это все автоматическое дифференцирование, которое заставляет градиент течь назад от потерь к параметрам альфа и бета.

В строках 11 и 12 изображаются исходное распределение и изученное распределение. Гистограммы ограничены 200; это ограничение делает гистограмму немного более читаемой. Мы вернемся к этому через минуту. Если вы задаетесь вопросом о производительности части “autodiff” этого скрипта, она выполняется менее чем за 80 миллисекунд на одном ядре процессора. Дифференцируемое программирование не только универсально; оно также хорошо использует вычислительные ресурсы, предоставляемые современным вычислительным оборудованием.

На экране у нас две гистограммы, полученные нашим скриптом, который мы только что рассмотрели. Наверху - исходное распределение с двумя исходными параметрами, альфа и бета, на 80 и 4 соответственно. Внизу - изученное распределение с двумя параметрами, изученными через дифференцируемое программирование. Эти два пика справа связаны с хвостами, которые мы усекли, так как эти хвосты достаточно далеко тянутся. Кстати, хотя это редко, но случается, что некоторые товары получают более чем через год после их заказа. Это не относится ко всем вертикалям, конечно, не к молочным продуктам, но к механическим деталям или электронике это случается время от времени.

Хотя процесс обучения не является точным, мы получаем результаты в пределах одного процента от исходных значений параметров. Это демонстрирует, по крайней мере, что эта максимизация логарифма вероятности через дифференцируемое программирование работает на практике. Распределение лог-логистического может быть или не быть подходящим; это зависит от формы распределения времени выполнения, с которым вы столкнулись. Однако, мы можем вполне выбрать любое альтернативное параметрическое распределение. Все, что нужно, это аналитическое выражение функции плотности вероятности. Существует огромный выбор таких распределений. Как только у вас есть формула из учебника, прямая реализация через дифференцируемое программирование обычно делает остальное.

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

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

Давайте вернемся к нашей вероятностной модели времени выполнения, но на этот раз учтем неполные наблюдения. Другими словами, мы хотим иметь дело с наблюдениями, которые иногда являются только нижней границей для окончательного времени выполнения. Для этого мы можем использовать функцию распределения (CDF) лог-логистического распределения. Эта формула написана на экране; опять же, это материал из учебника. CDF лог-логистического распределения имеет простое аналитическое выражение. В дальнейшем я буду называть эту технику “техникой условной вероятности” для работы с цензурированными данными.

На основе этого аналитического выражения CDF мы можем пересмотреть логарифмическую вероятность лог-логистического распределения. Сценарий на экране представляет собой пересмотренную реализацию нашей предыдущей реализации L4. В строке один у нас практически та же декларация функции. Эта функция принимает дополнительный четвертый аргумент, булево значение с именем “is_incomplete”, которое указывает, как предполагает название, является ли наблюдение неполным или нет. В строках два и три, если наблюдение полное, то мы возвращаемся к предыдущей ситуации с обычным лог-логистическим распределением. Таким образом, мы вызываем функцию логарифма вероятности, которая является частью стандартной библиотеки. Я мог бы повторить код предыдущей реализации L4, но эта версия более краткая. В строках четыре и пять мы выражаем логарифмическую вероятность в конечном итоге наблюдения времени выполнения больше, чем текущее неполное наблюдение, “X”. Это достигается через CDF и, точнее, через логарифм CDF.

Теперь мы можем повторить нашу настройку сценария, который изучает параметры лог-логистического распределения, но на этот раз в присутствии неполных времен выполнения. Сценарий на экране почти идентичен предыдущему. В строках с одного по три мы генерируем данные; эти строки не изменились. Отметим, что H.N - это автоматически созданный вектор, который неявно создается в строке два. Этот вектор нумерует сгенерированные строки, начиная с одного. Предыдущая версия этого сценария не использовала этот автоматически созданный вектор, но в настоящее время вектор H.N появляется в конце строки шесть.

Строки пять и шесть действительно важны. Здесь мы цензурируем время выполнения. Это как если бы мы делали одно наблюдение за временем выполнения в день и обрезали наблюдения, которые слишком свежи, чтобы быть информативными. Это означает, например, что 20-дневное время выполнения, начатое семь дней назад, появляется как семидневное неполное время выполнения. К концу строки шесть мы создали список времен выполнения, где некоторые из последних наблюдений (те, которые закончились бы после настоящей даты) неполные. Остальная часть сценария осталась без изменений, за исключением строки 12, где вектор H.is_complete передается как четвертый аргумент функции правдоподобия. Таким образом, мы вызываем, в строке 12, функцию дифференцируемого программирования, которую мы только что представили минуту назад.

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

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

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

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

Прогнозы времени выполнения обычно предназначены для сочетания с прогнозами спроса. Действительно, давайте теперь рассмотрим простую ситуацию с пополнением запасов, как показано на экране.

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

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

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

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

На строках один и два мы устанавливаем временные рамки, которые начинаются 1 января и заканчиваются 1 марта. В сценарии прогнозирования эта временная шкала не была бы жестко задана. На четвертой строке вводится простая вероятностная модель спроса: распределение Пуассона, повторяющееся изо дня в день на протяжении всего этого временного интервала. Спрос будет в среднем одна единица в день. Здесь я использую простую модель спроса ради ясности. В реальной ситуации мы бы, например, использовали ESSM (Ensemble State Space Model). Модели состояния пространства - это вероятностные модели, и они были представлены в самой первой лекции этой главы.

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

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

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

Давайте взглянем на мелкий шрифт. В строке 10 мы генерируем одну траекторию для спроса. В строке 11 мы генерируем дату поступления первого заказа, предполагая, что мы заказываем сегодня. В строке 12 мы генерируем дату поступления второго заказа, предполагая, что мы делаем заказ через один цикл заказа. В строке 13 мы вычисляем, что остается в запасе на руках на первую дату поступления. Это начальный запас на руках минус спрос, наблюдаемый за продолжительность первого срока поставки. Максимальный ноль говорит о том, что запас не может уйти в минус. Другими словами, мы предполагаем, что мы не берем никакого недостатка. Это предположение о недостатке могло бы быть изменено. Случай с недостатком оставлен в качестве упражнения для аудитории. В качестве подсказки, дифференцируемое программирование может быть использовано для оценки процента необслуженного спроса, который успешно преобразуется в недостаток, в зависимости от того, сколько дней остается до возобновления наличия запасов.

Возвращаясь к скрипту, в строке 14 мы вычисляем допустимый спрос, который является спросом, происходящим в течение окна ответственности. В строках 15 и 16 мы собираем две случайные величины интереса через ключевое слово “sample”. В отличие от первого скрипта Envision этой лекции, который занимался кросс-валидацией, мы здесь стремимся собрать распределения вероятностей из этого блока Монте-Карло, а не просто средние значения. В обеих строках 15 и 16 случайная величина, которая появляется справа от присваивания, является агрегатором. В строке 15 мы получаем случайную величину для запаса на руках при поступлении. В строке 16 мы получаем другую случайную величину для спроса, который происходит в течение окна ответственности.

В строках 18 и 19 эти две случайные величины выставляются на показ. Теперь давайте на секунду остановимся и пересмотрим весь этот скрипт. Строки с одного по семь посвящены только настройке тестовых данных. Строки 18 и 19 просто показывают результаты. Единственная реальная логика происходит в течение восьми строк между строками 9 и 16. На самом деле, вся реальная логика находится, в некотором смысле, в строках 13 и 14.

С помощью всего нескольких строк кода, меньше 10, независимо от того, как мы считаем, мы сочетаем вероятностный прогноз срока поставки с вероятностным прогнозом спроса, чтобы составить некий гибридный вероятностный прогноз, имеющий реальное значение для цепочки поставок. Отметим, что здесь нет ничего, что действительно зависит от специфики прогноза срока поставки или прогноза спроса. Были использованы простые модели, но вместо них могли быть использованы более сложные. Это ничего бы не изменило. Единственное требование - иметь две вероятностные модели, чтобы стало возможным генерировать эти траектории.

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

Нижняя гистограмма представляет спрос, связанный с окном ответственности. У нас есть примерно 10% шанса столкнуться с нулевым спросом. Этот результат также может быть воспринят как удивительный. В самом деле, мы начали это упражнение со стационарным Пуассоновским спросом в одну единицу в день в среднем. У нас семь дней между заказами. Если бы не меняющийся срок поставки, шанс получить нулевой спрос за семь дней должен был быть меньше 0,1%. Однако скрипт доказывает, что это явление гораздо более частое. Причина в том, что маленькое окно ответственности может произойти, если первый срок поставки дольше обычного, а второй срок поставки короче обычного.

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

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

Настоящая глава в этой серии лекций называется “Прогнозирующее моделирование” вместо “Прогнозирования спроса”, как это обычно бывает в основных учебниках по цепочке поставок. Причина этого названия главы должна была стать постепенно очевидной по мере продвижения по настоящей лекции. В самом деле, с точки зрения цепочки поставок, мы хотим прогнозировать эволюцию системы цепочки поставок. Спрос, безусловно, важный фактор, но это не единственный фактор. Другие меняющиеся факторы, такие как срок поставки, должны быть прогнозированы. Еще более важно, все эти факторы должны, в конечном итоге, прогнозироваться вместе.

В самом деле, нам нужно объединить эти прогнозирующие компоненты, чтобы поддержать процесс принятия решений. Таким образом, важно не искать какую-то конечную модель прогнозирования спроса. Эта задача в значительной степени является заблуждением, в конечном итоге, потому что дополнительная точность будет достигнута способами, которые противоречат лучшим интересам компании. Больше сложности означает больше непрозрачности, больше ошибок, больше вычислительных ресурсов. Как правило, чем сложнее модель, тем труднее успешно операционно сочетать эту модель с другой моделью. Важно собрать коллекцию прогнозирующих техник, которые можно составить по своему усмотрению. Вот о чем говорится модульность с точки зрения прогнозирующего моделирования. В этой лекции было представлено полдюжины техник. Эти техники полезны, поскольку они рассматривают критически важные реальные аспекты, такие как неполные наблюдения. Они также просты; ни один из примеров кода, представленных сегодня, не превышал 10 строк фактической логики. Самое главное, эти техники модульные, как конструктор Lego. Они хорошо работают вместе и могут быть почти бесконечно перекомбинированы.

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

В заключение, несмотря на то, что срок поставки в значительной степени игнорируется академическим сообществом, срок поставки может и должен быть прогнозирован. Рассмотрев короткую серию реальных распределений сроков поставки, мы выявили две проблемы: во-первых, сроки поставки меняются; во-вторых, сроки поставки редки. Таким образом, мы ввели моделирование техник, которые подходят для работы с наблюдениями сроков поставки, которые оказываются одновременно редкими и непредсказуемыми.

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

Следующая лекция состоится 8 марта. Это будет среда в то же время дня, 3 часа дня по парижскому времени. Сегодняшняя лекция была технической, но следующая будет в основном нетехнической, и я буду обсуждать случай ученого по цепочкам поставок. В самом деле, основные учебники по цепочкам поставок подходят к цепочкам поставок, как если бы модели прогнозирования и оптимизации возникали и работали из ничего, полностью игнорируя их “мокрую” составляющую, то есть людей, которые отвечают за это. Таким образом, мы более внимательно рассмотрим роли и обязанности ученого по цепочкам поставок, человека, который должен возглавить инициативу по количественной цепочке поставок.

Теперь я перейду к вопросам.

Вопрос: Что, если кто-то хочет сохранить свой запас для дальнейшего инноваций или по другим причинам, отличным от концепции “точно в срок” или других концепций?

Это действительно очень важный вопрос. Концепция обычно рассматривается через экономическое моделирование цепочки поставок, которое мы технически называем “экономическими драйверами” в этой серии лекций. Вы спрашиваете, лучше ли не обслуживать клиента сегодня, потому что в более поздний момент времени будет возможность обслужить ту же единицу другому человеку, который важнее по той или иной причине. В сущности, вы говорите, что можно получить больше ценности, обслуживая другого клиента позже, возможно, VIP-клиента, чем обслуживая клиента сегодня.

Это может быть так, и это случается. Например, в авиационной промышленности, допустим, вы поставщик MRO (обслуживание, ремонт и модернизация). У вас есть свои обычные VIP-клиенты - авиакомпании, которые вы регулярно обслуживаете по долгосрочным контрактам, и они очень важны. Когда это происходит, вы хотите быть уверены, что всегда сможете обслуживать этих клиентов. Но что, если другая авиакомпания позвонит вам и попросит одну единицу? В этом случае, что произойдет, это то, что вы могли бы обслужить этого человека, но у вас нет с ним долгосрочного контракта. Так что то, что вы собираетесь делать, это поднять свою цену так, чтобы она была очень высокой, убедившись, что вы получаете достаточно ценности, чтобы компенсировать потенциальный дефицит запасов, с которым вы можете столкнуться в более поздний момент времени. Итак, по этому первому вопросу, я считаю, что это не столько вопрос прогнозирования, сколько вопрос правильного моделирования экономических драйверов. Если вы хотите сохранить запасы, то вам нужно создать модель - модель оптимизации, где рациональным ответом будет не обслуживать клиента, который просит одну единицу, пока у вас еще есть запасы в резерве.

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

Вопрос: В течение последних нескольких лет большинство задержек в цепочке поставок произошло из-за войны или пандемии, что очень трудно прогнозировать, потому что раньше у нас не было таких ситуаций. Каково ваше мнение по этому поводу?

Мое мнение заключается в том, что сроки поставки всегда были переменчивыми. Я работаю в мире цепочек поставок с 2008 года, и мои родители работали в области цепочек поставок еще за 30 лет до меня. Насколько мы можем помнить, сроки поставки всегда были непостоянными и менялись. Всегда происходит что-то, будь то протест, война или изменение тарифов. Да, последние пару лет были чрезвычайно непостоянными, но сроки поставки уже довольно сильно колебались.

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

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

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

Вопрос: Можем ли мы создать эти гистограммы и рассчитать CRPS в Microsoft Excel, например, используя дополнения Excel, такие как itsastat или которые содержат множество распределений?

Да, вы можете. Один из нас в Lokad на самом деле создал таблицу Excel, которая представляет собой вероятностную модель для ситуации с пополнением запасов. Суть проблемы в том, что в Excel нет встроенного типа данных гистограммы, поэтому все, что у вас есть в Excel, - это числа - одна ячейка, одно число. Было бы элегантно и просто иметь одно значение, которое является гистограммой, где у вас есть полная гистограмма, упакованная в одну ячейку. Однако, насколько мне известно, это невозможно в Excel. Тем не менее, если вы готовы потратить около 100 строк или около того, чтобы представить гистограмму, хотя это и не будет так компактно и практично, вы можете реализовать распределение в Excel и провести некоторое вероятностное моделирование. Мы опубликуем ссылку на пример в разделе комментариев.

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

Вопрос: Срок поставки можно разбить на компоненты, такие как время заказа, время производства, время транспортировки и т.д. Если кто-то хочет более детального контроля над сроками поставки, как бы этот подход изменился?

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

В этой лекции мы занимаемся моделированием. Само по себе это не действие; речь идет только о наблюдении, анализе и прогнозировании. Однако, если мы можем разложить срок поставки и проанализировать основное распределение, мы можем использовать вероятностное моделирование для оценки того, какие компоненты варьируются больше всего и какие из них оказывают наибольшее негативное влияние на нашу цепочку поставок. Мы можем заниматься “что-если” сценариями с этой информацией. Например, возьмите одну часть вашего срока поставки и спросите: “Что, если хвост этого срока поставки был немного короче, или если средний был немного короче?” Затем вы можете снова все составить, перезапустить свою прогностическую модель для всей вашей цепочки поставок и начать оценивать влияние.

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

Вопрос: Я считаю, что это предлагает возможность пересчитать наши сроки поставки в SAP, чтобы предоставить более реалистичный срок и помочь минимизировать наше системное притяжение и отталкивание. Это возможно?

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

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

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

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

Это действительно интересный вопрос. У нас есть два поставщика одного и того же товара. Вопрос будет в том, насколько схожи товары и поставщики. Во-первых, нам нужно рассмотреть ситуацию. Если один поставщик случайно находится рядом, а другой поставщик - на другой стороне мира, вам действительно нужно рассматривать эти вещи отдельно. Но допустим, интересная ситуация, когда два поставщика довольно похожи и это один и тот же товар. Стоит ли объединять эти наблюдения или нет?

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

Вопрос: Я полагаю, что количество, которое заказывается, и какие продукты заказываются вместе, также могут влиять на срок поставки в конечном итоге. Могли бы вы рассмотреть сложность включения всех переменных в эту тип проблемы?

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

Цикл заказа - это ваше собственное творение. Теперь, что вы говорите, так это то, что есть неопределенность относительно точного момента времени для следующего срока поставки заказа, потому что вы не знаете точно, когда будете заказывать. Действительно, вы абсолютно правы. Что происходит, так это то, что когда у вас есть возможность реализовать это вероятностное моделирование, внезапно, как обсуждалось в шестой главе этой серии лекций, вы не хотите говорить, что цикл заказа составляет семь дней. Вместо этого вы хотите принять политику перезаказа, которая максимизирует возврат инвестиций для вашей компании. Таким образом, что вы можете сделать, это на самом деле спланировать будущее так, что если вы перезакажете сейчас, вы можете принять решение сейчас, а затем применить свою политику изо дня в день. В какой-то момент времени в будущем вы делаете перезаказ, и теперь у вас есть своего рода ситуация “змея ест свой хвост”, потому что лучшее решение о заказе на сегодня зависит от решения о следующем заказе, которое вы еще не приняли. Эта проблема известна как проблема политики, и это проблема последовательного принятия решений. Под капотом то, что вы действительно хотите, это создать некий политический объект, математический объект, который управляет вашим процессом принятия решений.

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

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

Вот и все на сегодня. Не забудьте, 8 марта, в то же время дня, это будет среда, 3 часа дня. Спасибо, и до следующего раза.