00:00:00 Введение в интервью
00:02:15 Вероятностное прогнозирование и оптимизация цепей поставок
00:04:31 Стохастическая оптимизация и принятие решений
00:06:45 Составляющие стохастической оптимизации: переменные, ограничения, функция потерь
00:09:00 Взгляды на моделирование и оптимизацию
00:11:15 Ограничения и худшие сценарии в оптимизации
00:13:30 Неопределенность, ограничения и плохие решения
00:15:45 Детерминированная оптимизация и изменяющиеся сценарии
00:18:00 Операции в MRO-пространстве и оптимизация запасов
00:20:15 Неопределенность в сроках поставки и ремонтных деталях
00:22:30 Последствия отсутствия деталей и ограничения классического подхода
00:24:45 Стохастические элементы и стохастичность, основанная на человеческом факторе в цепях поставок
00:27:00 Ремонт авиадвигателя и поиск деталей
00:29:15 Оптимизация запасов и вероятностный список материалов
00:31:30 Политики оптимизации цепей поставок и реактивность
00:33:45 Проблемы масштабируемости и выпуклые функции в цепях поставок
00:36:00 Расслабление проблемы и ограничения в задачах цепей поставок
00:38:15 Инструменты локального поиска и приемлемое решение в цепях поставок
00:40:30 Метаэвристические генетические алгоритмы и проблемы масштабируемости
00:42:45 Математическая оптимизация как проблема масштабируемости
00:45:00 Разработка стохастической оптимизационной технологии Lokad
00:47:15 Взаимосвязи в цепях поставок и решение проблем с помощью денег
00:49:30 Ограничения на полки и пример инвентаризации йогурта
00:51:45 Подведение итогов стохастической оптимизации и неопределенности
00:54:00 Роль решателя в оптимизации цепей поставок
00:56:15 Уточнение термина ‘решатель’ и вычисление окончательного решения
00:58:30 Оспаривание решения решателя и потенциальные недостатки
01:00:45 Основные выводы: важность стохастической оптимизации
01:03:00 Игнорирование неопределенности в цепях поставок и преимущества хорошего решателя
01:05:15 Зависимости и взаимосвязи в нетривиальных цепях поставок
01:07:30 Конец интервью

Резюме

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

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

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

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

В контексте компании по обслуживанию, ремонту и модернизации (MRO) Верморель объясняет, что оптимизация запасов является важной. Спецификация материалов является стохастической, и если одна часть отсутствует, компонент не может быть отремонтирован. Lokad использует вероятностные прогнозы для предвидения поступления компонентов и необходимых для ремонта деталей. Решения о закупке деталей должны учитывать возвращаемые детали и возможные уровни брака. Цель состоит в решении проблем закупки деталей.

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

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

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

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

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

Полный текст

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

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

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

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

Конор Доэрти: Например, попытайтесь не потерять слишком много денег с результатом этого решения.

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

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

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

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

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

Конор Доэрти: И как настроить эту функцию потерь в свете всей этой стохастичности?

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

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

Жоанн Верморель: Если бы у вас было идеальное знание о будущем, то, действительно, процесс принятия решений не был бы таким сложным. Однако даже в таких ситуациях вам пришлось бы иметь дело с МОК и постоянными затратами на заказ, постоянными транспортными расходами. Даже если бы вы идеально знали будущее, вы все равно столкнулись бы с несколькими нелинейностями, которые мешают вам найти тривиальное немедленное решение.

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

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

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

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

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

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

Конор Доэрти: Это ограничение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конор Доэрти: Когда вы говорите о терпимости, это та выполнимость, о которой вы говорите, верно? И, расширяя, это измеряется в?

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

Ключевое понимание заключается в том, что как только вы оказываетесь в ситуации, где есть неопределенность, не только ваша функция потерь меняется, но и удовлетворение ограничений также меняется. Для большинства интересных ситуаций вы получаете ограничения, которые не будут полностью удовлетворены. Было бы ошибкой сказать, что я хочу идти только в ситуации, где я гарантированно буду соблюдать свои ограничения. Почему? Потому что математически вы получите решения, но они будут очень плохими. Это будут решения вроде “не заказывайте ничего, не делайте ничего, просто пусть будет”. И это даст вам удовлетворение в смысле отсутствия нарушения ограничений, но оно определенно не принесет вам прибыль.

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

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

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

Как же вернуться к детерминированному случаю? Ну, вы можете просто сказать: “Я могу скопировать свою ситуацию 100 раз, что представляет 100 вариантов ситуации, которые будут на 100 траекториях, и затем оптимизировать макро-расширенную проблему, которая имеет 100 экземпляров сразу”.

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

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

Жоанн Верморель: Давайте посмотрим, с какими проблемами мы сталкиваемся в MRO. Мы хотим оптимизировать запасы, чтобы вы могли выполнять свои ремонты. У вас есть компонент, который приходит, он неисправен, вы начинаете ремонт, вы обнаруживаете детали, которые вам нужны. Итак, у вас есть смета, но смета вероятностная, поэтому она неопределенная. Здесь происходит стохастичность. У вас есть неопределенность в том, получите ли вы компоненты для ремонта, это колеблющийся спрос. Но как только вы получите компонент, вы фактически узнаете, что вам действительно нужно для ремонта компонента.

Проблема в том, что если одна деталь отсутствует, вы не можете отремонтировать компонент. Итак, видите ли, иметь, скажем, 90% деталей не решает проблему. Вы застряли. Вам нужны все детали для ремонта или вы вообще не сможете отремонтировать компонент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что эта деталь мне даже не нужна на складе, потому что к тому времени, когда мне понадобятся детали, я могу заказать детали в первый день, и когда мне действительно понадобятся детали через 60 дней, у меня уже будут готовые детали, потому что мое время поставки от поставщиков было, скажем, 20 дней.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И мы также хотим учесть стохастический аспект проблемы. Потому что вы видите, когда я упоминал эту проблему для этих мини-маркетов, где у нас было 50 000 переменных, если мы макро-расширим с 100 траекториями, как я описал, чтобы учесть возможные будущие события, то у нас получится 5 миллионов переменных. Таким образом, это быстро раздувается, и снова этого недостаточно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conor Doherty: Итак, программный инструмент, о котором вы говорите, программный инструмент решателя, который автоматически пересчитывает оптимизацию или решение, о котором вы говорите, значит, сокращает количество работы, которую должен выполнить традиционный практикующий специалист по цепочке поставок, верно?

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

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

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

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

Joannes Vermorel: Решатель очень просто проверить. Вы можете просто сказать: “Вот мое лучшее решение. Давайте проверим это решение по функции потерь”. Все, что нужно, чтобы доказать, что ваш решатель не очень хорош, - показать решение, которое лучше, чем то, которое было найдено решателем.

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

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

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

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

Conor Doherty: Что бы вы сказали, является ли ключевым выводом для людей, которые слушали это?

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

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

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

Conor Doherty: Ну, Джоаннес, спасибо вам большое за ваше время. У меня больше нет вопросов. И спасибо всем за просмотр. Увидимся в следующий раз.