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 мы выражаем ее через экономические драйверы, то есть задача сводится к минимизации денежных потерь. В настройке этой функции потерь, чтобы она действительно соответствовала бизнесу и отражала сумму денег, находящихся на кону, заложено много ноу-хау. У нас есть две ортогональные задачи. Одна заключается в поиске функции потерь, которая полностью соответствует бизнес-стратегии. Но это не требует каких-либо специальных навыков численной оптимизации. Речь идет просто о том, чтобы иметь что-то, что отражает мой бизнес, используя базовые арифметические операции. Это не что-то замысловатое. Другое — это все, что необходимо для проведения стохастической оптимизации для любой заданной функции потерь.
Конор Дохерти: Мне пришла в голову мысль: когда вы проводите очень качественное или эффективное вероятностное прогнозирование, разве нельзя полностью обойтись без части оптимизации? Ведь если бы вы точно знали, что собираетесь делать или каким будет спрос, зачем вам балансировать все эти другие аспекты? Разве не можно просто заказать то количество, которое вы определили, или ориентироваться на наиболее вероятный результат?
Joannes Vermorel: Если бы вы обладали совершенным знанием будущего, то процесс принятия решений действительно не был бы таким сложным. Хотя даже в подобных ситуациях вам пришлось бы иметь дело с MOQs и фиксированными затратами на оформление заказа, фиксированными транспортными затратами. Даже если бы вы знали будущее идеально, вы все равно столкнулись бы с рядом нелинейностей, которые мешают получить тривиальное немедленное решение.
Но на самом деле ситуация гораздо хуже, поскольку у вас есть только весьма неполное знание о будущем. Это совершенно неразумно утверждать, что мы когда-либо получим прогноз, устраняющий неопределенность. Неопределенность можно сократить, но в значительной степени она остается неизбежной. Таким образом, вы застряли с этой неопределенностью, и очевидного решения нет. Нет очевидного решения.
Conor Doherty: Ладно, вернемся немного к стохастической оптимизации. Вы говорили об ингредиентах. Вы перечислили функцию потерь. Функция потерь не может быть единственным ингредиентом в стохастической оптимизации. Так какие же еще компоненты требуются для этого?
Joannes Vermorel: Когда мы подходим к математической оптимизации, существует три типа компонентов. Первые — это переменные. Переменные — это, по сути, то, что вы можете выбрать. Именно это определяет ваше решение. Ваше решение — это конкретное сочетание переменных.
Если вы хотите рассмотреть дискретную задачу, например, подбор правильного сочетания для замка, скажем, у вас есть четыре переменные. Каждая переменная имеет 10 позиций, и каждое сочетание определяет потенциальное решение. Вам нужно найти то единственное решение, которое щелкнет и откроется.
Первым компонентом являются переменные. В цепочке поставок мы часто сталкиваемся с дискретными задачами, поскольку переменные являются целыми числами. Вы можете заказать ноль единиц, одну единицу, две, три и так далее, но обычно нельзя заказать 0.5 единицы. Дискретный характер усложняет задачу, потому что вы не можете просто перейти от одного решения к другому. Здесь возникают многочисленные сильно нелинейные закономерности.
Например, переход от нуля к одной единице кардинально отличается от изменения на небольшие дробные величины. Кроме того, существуют такие понятия, как MOQ, минимальное количество заказа, когда вам приходится переступать через, скажем, 100 единиц, чтобы даже получить решение.
Conor Doherty: Это ограничение.
Joannes Vermorel: И это приводит меня ко второму компоненту, а именно ограничениям. Обычно вы перечисляете переменные и ограничения. Ограничения — это набор математических выражений над переменными, который указывает, является ли решение допустимым, осуществимым.
Таким образом, в случае пополнения запасов, мы можем заказать сколько угодно единиц, однако у полки есть конечная вместимость. То есть полка может вместить только определенное количество единиц. Также может существовать максимальная дневная пропускная способность для приема товаров, их обработки в магазине или приема на складе, или в любом другом звене вашей цепочки поставок.
И таких ограничений масса. Может быть ограничение, указывающее, что мне нужно иметь как минимум это, это и то, чтобы я мог представить аккуратно оформленную полку. Это могло бы быть ограничением с точки зрения мерчендайзинга в магазине и так далее.
Таким образом, у нас есть переменные, ограничения, и третьим элементом является функция потерь. Функция потерь определяет, для любого решения, удовлетворяющего всем ограничениям, какова потеря, и вы стремитесь её минимизировать. Это просто конвенция.
И эти три элемента вместе определяют общую структуру математической оптимизации. Причина, по которой математики на протяжении последних 100 лет использовали эту структуру, заключается в том, что она действительно очень общая.
И здесь мы даже рассматриваем элемент стохастичности, когда в задачу вносится довольно необычный поворот, а именно функция потерь оказывается недетерминированной. Это не классическая математическая функция, где вы подаете вход и получаете гарантированный результат. Мы говорим, что если вы подаете вход, то выход оказывается случайным.
Conor Doherty: Вернемся к идее ограничений, и поправьте меня, если я ошибаюсь: можно подразделить эти ограничения. Например, вы упомянули вместимость — вместимость ваших полок, склада, сколько может быть обработано в день. Возможно, обработку можно немного увеличить, но вместимость полки остается конечной. Это не изменится в ближайшее время. А MOQs может измениться. То есть, его можно пересмотреть. Таким образом, некоторые из этих ограничений обладают определенной гибкостью. Речь идет именно об этой стохастичности, которая учитывается при принятии решений?
Joannes Vermorel: Не совсем. Ограничения — это буквально математический способ выразить идею о том, что некоторые решения просто недопустимы. Опять же, так же как существует глубокий вопрос — не математический, а относящийся к адекватности функции потерь с точки зрения вашей бизнес-стратегии, аналогично и с ограничениями. Вы можете спросить: действительно ли это ограничение является таковым? Могу ли я инвестировать для устранения этого ограничения или стоит по-другому взглянуть на бизнес?
Опять же, суть в том, что существует две разные перспективы. Одна — это подход моделирования, когда вы стремитесь, чтобы переменные, функции потерь, ограничения точно отражали ваш бизнес. И это по существу не математическая и не алгоритмическая задача. Речь идет о понимании, соответствуют ли эти вещи бизнесу.
Но это не имеет смысла в математическом плане. Ограничение не является ни истинным, ни ложным в математическом смысле. Оно просто есть. Это буквально что-то вроде «максимальная вместимость — 100 единиц». В этом утверждении нет математической обоснованности. Это просто заданное условие. Математик может сказать: «Да, вы выбрали 100». Математически я не могу сказать, является ли 100 хорошим числом. Я могу лишь сказать, например, что если есть ограничение, которое требует, чтобы значение было меньше 100 единиц, а другое ограничение строго требует, чтобы оно было больше 100 единиц, то, могу сказать, решения не существует.
Математика не выносит суждения о типе подаваемых входных данных. Важна лишь внутренняя согласованность. Но интересная особенность стохастической составляющей в стохастическом мире заключается в том, что ограничения внезапно становятся гораздо более тонкими в математическом смысле.
Итак, давайте посмотрим, что означает стохастическая проблема. В старой, недетерминированной оптимизации существовало четкое разделение: решение либо работает, либо не работает из-за ограничений, даже не учитывая функцию потерь. Но что это означает в мире, где функция потерь является стохастической? Допустим, у нас есть склад, на который мы можем передавать заказы на пополнение запасов, и у склада есть дневная входящая пропускная способность.
Таким образом, каждый день у нас есть ограничение на количество единиц, которые мы можем обработать от поставщиков. И поэтому обычно на складе, чтобы учесть это, мы распределяем заказы на пополнение запасов с учетом сроков поставки от поставщиков, чтобы не все поставщики доставляли всё в один и тот же день, что привело бы к превышению дневного лимита по приему товаров на склад.
Рассматривая это с точки зрения стохастической оптимизации, я выбираю количество, а затем возникает изменчивость во времени доставки. Это означает, что если мне очень не повезет, я могу получить решение, которое в теории выглядит абсолютно нормальным. Все заказы на пополнение распределены, но мои самые ранние заказы опаздывают, а поздние заказы приходят даже раньше срока. По случайному стечению обстоятельств все это сваливается в один и тот же день, и в этот день я перегружаю мой склад. Я превышаю номинальную входящую емкость.
Существует множество ситуаций, когда невозможно иметь решение, которое было бы абсолютно допустимым. Это означает, что вам придется мириться с ситуациями, в которых существует вероятность нарушения ограничений. Такова реальность. Это математическое утверждение, которое я делаю. Из-за природы функции потерь и того факта, что ваши решения могут иметь недетерминированные последствия, например, вы выбираете количество, но не имеете полного контроля над днем доставки.
Даже если вы приняли самые лучшие решения, существует вероятность столкновения запасов. Единственный способ абсолютно гарантировать, что этого никогда не произойдет — это обеспечить, чтобы в вашей полной цепочке предстоящих заказов вы никогда не превышали того количества, которое можете принять в любой данный день, с учетом наихудшего сценария, когда все предстоящие заказы доставляются в один и тот же день. Это, безусловно, крайняя мера.
Бизнесу приходится иметь дело с такими ситуациями, когда, да, вероятность превышения мощности составляет одну из 10 000. Но на самом деле идея абсолютного ограничения — скорее математическая концепция. На практике, если вы превышаете свою вместимость, это повлечет за собой затраты.
Когда мы рассматриваем стохастическую оптимизацию, мы видим, что, по сути, ограничения во многом становятся частью функции потерь. Иначе говоря, мы подходим таким образом, что допустим определенная степень терпимости к тому, что ограничения будут нарушены с небольшой вероятностью. Для большинства интересных ситуаций в стохастических оптимизационных задачах в цепочке поставок остается остаточная небольшая вероятность, что ограничения будут нарушены.
Conor Doherty: Когда вы говорите об этой терпимости, вы имеете в виду осуществимость, верно? И, соответственно, она измеряется в чем?
Joannes Vermorel: Это измеряется в той вместимости, которую вы установили для своих задач. Если вы говорите: «Я хочу пополнить магазин», вы принимаете решение так, чтобы оно соответствовало вместимости магазина. Но что, если магазин, по стечению обстоятельств, ничего не продаст в определенный день? Допустим, вы занимаетесь свежими продуктами, сегодня решаете пополнить запасы молока, и принимаете это решение, не зная продаж за день. Но вы все равно предполагаете, что некоторые единицы будут проданы. И если, случайно, в этом магазине, который обычно ежедневно распродает 80% своего запаса свежего молока, сегодня ничего не продается, по чистой случайности, то вы можете оказаться в ситуации, когда пополнение приведет к превышению ограничений.
Ключевое понимание заключается в том, что как только вы оказываетесь в ситуации неопределенности, не только функция потерь изменчива, но и выполнимость ограничений также варьируется. В большинстве интересных случаев ограничения не будут полностью удовлетворены. Было бы ошибкой говорить, что я выбираю только те ситуации, где гарантировано соблюдение ограничений. Почему? Потому что математически вы получите решения, но они будут очень слабыми. Это будут решения в духе: ничего не заказывайте, ничего не делайте, пусть все остается как есть. И это может обеспечить отсутствие нарушения ограничений, но определенно не принесет прибыли.
Conor Doherty: Я хочу вернуться к примеру, который вы привели о получении заказов, их распределении по времени и попытке сделать это максимально экономически выгодным способом. Это, по-видимому, относится к стохастическому подходу. Как предыдущие модели, основанные на математической оптимизации, без учета стохастической составляющей, решали описанную вами проблему?
Joannes Vermorel: Они просто полностью игнорировали эту проблему. В классической детерминистической математической оптимизации ее даже не существовало. Изменчивые последствия ваших решений не учитывались, их просто не существовало.
Существуют способы смягчения этой проблемы. Один из простых способов — расширить определение своей задачи, заявив: “Вместо того чтобы рассматривать одну оптимизацию, я собираюсь совместно оптимизировать, скажем, 100 различных сценариев. И я заявляю, что мое решение должно быть общим для всех возможных будущих вариантов, и я должен удостовериться, что во всех этих вариациях все мои ограничения по-прежнему соблюдаются.”
Так как же вернуться к детерминированному случаю? Ну, можно просто сказать: “Я могу скопировать свою ситуацию 100 раз, представляющих 100 вариантов ситуации, находящихся на 100 траекториях, а затем оптимизировать макрорасширенную задачу, включающую 100 экземпляров одновременно.”
И я могу сделать это с помощью классического решателя, но тогда это только усугубляет проблему, которая уже мешает современным специалистам по цепочке поставок применять инструменты математической оптимизации в первую очередь. А эта проблема — масштабируемость.
Conor Doherty: Хорошо, думаю, настало время применить это к конкретному сектору, чтобы люди могли получить трехмерное понимание того, как теория взаимодействует с реальной сложностью, реальными ограничениями и реальными переменными. Итак, если взять, скажем, компанию MRO, типичного размера, обслуживающую обычный флот, допустим, 10 самолетов, каждый из которых имеет, не знаю, четверть миллиона запчастей, как бы эти три компонента вписывались в стохастическую оптимизацию для MRO по сравнению со старомодной математической оптимизацией, которая, по вашему мнению, не работает?
Joannes Vermorel: Давайте посмотрим, с какими проблемами сталкивается MRO. Мы хотим оптимизировать запасы так, чтобы можно было проводить ремонты. Приезжает комплектующее, оно неисправно, вы начинаете ремонт, и обнаруживаете, какие запчасти вам нужны. Так у вас есть спецификация материалов, но она имеет вероятностный характер, то есть неопределена. Здесь проявляется стохастичность. Существует неопределенность в том, получу ли я комплектующие для ремонта — это колеблющийся спрос. Но как только комплектующее поступает, вы фактически выясняете, что именно нужно для его ремонта.
Проблема в том, что если отсутствует хотя бы одна деталь, вы не можете отремонтировать комплектующее. Таким образом, наличие, скажем, 90% запчастей не решает проблему. Вы застряли. Вам нужны все запчасти для ремонта, иначе ремонт комплектующего невозможен.
В компании Lokad мы начали много лет назад применять вероятностное прогнозирование для подобных ситуаций. Вероятностное прогнозирование заключается в том, чтобы с нужными вероятностями предсказать поступление компонентов на ремонт, предсказать вероятностное распределение деталей, которые вам понадобятся. Таким образом, это будет вероятностная спецификация материалов. А теперь нам нужно решить, что докупать, какие детали следует держать на складе и в каком количестве. При этом для этих деталей существует неопределённость сроков поставки. И некоторые из этих деталей можно ремонтировать.
Для некоторых из них имеется неопределённость не только в том, сколько времени займёт их восстановление после извлечения из агрегата, но и в том, что сама деталь подлежит ремонту. Таким образом, вы можете отремонтировать деталь и вернуть её обратно, или, скорее всего, вы извлекаете деталь, ремонтируете её, но устанавливаете другую деталь в агрегат, так как не хотите ждать, пока отремонтированная деталь вернётся.
Но это означает, что если вы хотите принять решение о необходимости дополнительных деталей, вам нужно учитывать те детали, которые вернутся и уже находятся в процессе ремонта. То есть речь идёт не только о том, что у вас есть на складе, но и о том, что возвращается. А затем есть и другие факторы, такие как процент брака, когда вы пытаетесь отремонтировать, но ремонт оказывается неудачным. Вы могли ожидать, что вернётся, скажем, 10 деталей, а в итоге получите 8, потому что две оказались непригодными для ремонта.
Это часть прогноза, всех этих неопределённостей. А затем, принятые вами решения касаются решения задач закупки деталей. Вопрос в том, следует ли закупить ещё единицы деталей, учитывая все возвращающиеся детали и всё прочее.
Деталь приобретает экономическую ценность, если она способствует ремонту. Но, как замок, о котором я упоминал ранее, действует эффект «щёлчка»: если у вас есть все детали, ремонт возможен, и каждая деталь имеет значение. Но если вам чего-то не хватает, всё это становится лишним грузом. Детали, которые у вас есть, служат только в том случае, если у вас есть полный комплект. Если у вас комплект с недостающей деталью, то возникает задержка для ваших клиентов.
В любом случае, запасы на складе выполняют своё предназначение лишь если у вас есть всё необходимое. А если чего-то не хватает, то встает вопрос: «Сколько времени потребуется на пополнение, ведь в самый последний момент вы обнаружите, что чего-то не хватает, и сколько времени потребуется, чтобы эта деталь стала доступной, если заказ оформлен слишком поздно?»
Если мы рассматриваем простую ситуацию, когда все мои SKU строго независимы, разные клиенты, всё различается, то для каждой товарной позиции я могу вычислить экономический показатель и, учитывая все вероятности, рассчитать ожидаемую прибыль от наличия этой единицы на складе.
Но для MRO такой подход неприменим, поскольку между номерами деталей существуют зависимости. Если я решу закупить одну единицу, она сама по себе может не иметь ценности. Но если я куплю ещё одну единицу, то смогу завершить ремонт, и тогда обе детали будут иметь существенную экономическую ценность.
Пока у вас нет всех деталей, необходимых для вашей вероятностной спецификации материалов, детали, которые у вас есть, по существу бесполезны. Их экономическая ценность проявляется только тогда, когда они используются вместе. По отдельности они не имеют значения. Поэтому, какой бы метод стохастической оптимизации вы ни использовали, вам необходимо анализировать решения не как последовательную покупку деталей по одной или рассмотрение их по отдельности, а совместно. Комбинации определённых единиц, подлежащих приобретению, могут иметь значительно большую экономическую ценность по сравнению с отдельным анализом, когда вы рассматриваете детали по одной.
Conor Doherty: Я постараюсь уловить вашу мысль, потерпите меня, но когда вы описываете все эти стохастические элементы, вы говорите, что, скажем, время восстановления детали может составлять один день, полдня, три дня, четыре дня. Есть ещё один аспект стохастичности, который, предположительно, связан с умением людей выполнять ремонт, то есть сколько времени понадобится человеку после получения детали, что варьируется, чтобы осуществить ремонт. Можно ли учесть и этот уровень стохастичности, то есть человеческую стохастичность?
Joannes Vermorel: Да, люди — это лишь один из видов задержек среди прочих, и их способности могут сильно различаться. Например, одни операторы талантливее других, и им может понадобиться меньше деталей. Кто-то может справиться с ремонтом, используя меньше ресурсов, чем менее талантливый сотрудник, который просто выбрасывает детали, если ремонт не удаётся.
В MRO в авиации компоненты являются высокомодульными, так что компоненты состоят из подкомпонентов, которые, в свою очередь, состоят из деталей. Таким образом, всегда существует вариант, когда, не зная, как правильно отремонтировать, можно просто выбросить целый субмодуль и установить совершенно новый агрегат, вместо того чтобы выявлять конкретную неисправную деталь и менять только её.
Если вы хорошо разбираетесь в диагностике того, что нужно заменить, вы замените именно ту часть, которая неисправна. Если же вы менее опытны, в итоге можете заменить гораздо больше.
Но вернёмся к делу. Суть здесь в том, что, определяя решение, мы должны рассматривать его с точки зрения политики. Это означает, что ваше решение — не обязательно конкретное действие, которое вы совершаете сейчас, а общий принцип, который направляет ваши будущие решения. Политика может регулировать, какие детали должны быть на складе, но также учитывать, как вы реагируете, когда обнаруживаете свою вероятностную спецификацию материалов.
Почему это имеет значение? Допустим, например, вам нужно отремонтировать авиационный двигатель. Некоторые детали, расположенные на внешней части двигателя, будут первыми, которые будут осмотрены. Так что, получая двигатель для ремонта, вы сразу узнаете, что необходимо для внешней части двигателя, потому что при разборке двигателя это первая деталь, которую вы встречаете, ведь двигатель похож на матрёшку с множеством слоёв, ведущих к сердцевине.
Если вы обнаружите деталь на внешней части двигателя, то, скорее всего, у вас будет много времени на её закупку, ведь сначала может пройти много дней на полную разборку двигателя до ядра, а затем постепенная сборка двигателя от ядра к внешности, и деталь для внешней части понадобится именно в конце процесса.
Таким образом, эту деталь мне даже не нужно иметь на складе, потому что к тому времени, когда она понадобится, я смогу заказать её в первый день, а через 60 дней, когда деталь потребуется, она будет у меня в наличии, поскольку срок поставки от поставщиков, скажем, 20 дней.
Когда вы рассматриваете оптимизацию запасов для деталей, необходимо учитывать политику, определяющую, какие детали нужно иметь на складе, и какой будет обычный порядок действий при обнаружении этой вероятностной спецификации материалов.
Если я предполагаю применение другой политики, например, когда сотрудник, занимающийся разборкой двигателя, не имеет информации о наличии или отсутствии деталей на складе, ситуация кардинально меняется: вы разбираете двигатель, затем собираете его, а спустя 60 дней обнаруживаете, что вам не хватает одной детали.
Таким образом, политика выражает последовательность принятия решений, определяя, какие решения будут приниматься и как они повлияют на конечный экономический результат по мере развития ситуации.
У нас здесь две политики: первая — умная, при которой я реагирую, как только получаю информацию, и сразу размещаю заказ; вторая — я жду, пока не наступит момент установки детали, и только тогда понимаю, что она нужна, и размещаю заказ. Если ваша ситуация соответствует второй политике, это означает, что наличие деталей на складе имеет гораздо большую экономическую ценность, поскольку это единственный способ избежать дальнейших задержек в ремонте двигателя из-за отсутствия одной детали.
Если же применяется первая, умная политика, то наличие деталей на внешней части двигателя на складе не имеет экономической ценности. Благодаря политике я не столкнусь с их нехваткой, так как заказы будут размещаться заранее.
Conor Doherty: Какие технологические накладные расходы будут связаны с той реактивностью, которую вы описываете? То есть, если я продвигаюсь в двигатель и обнаруживаю, что мне нужна деталь, это полностью меняет запланированные сроки ремонта.
Joannes Vermorel: Это очень интересный вопрос. Масштабируемость является одной из основных проблем. Когда я говорю о масштабируемости, я имею в виду масштабируемость методов математической оптимизации для цепочек поставок, что уже является препятствием почти на протяжении четырёх десятилетий.
Математическая оптимизация считается абсолютно устоявшейся областью исследований, и существуют крупные компании, которые продают так называемые решатели. Решатели — это программное обеспечение, предназначенное для решения задач математической оптимизации, и они обычно поставляются с собственным языком программирования. Обычно это языки математического программирования, позволяющие описывать ваши переменные, функции потерь и ограничения.
Интересно то, что, несмотря на то, что эти решатели появились на рынке четыре десятилетия назад, и даже существуют open source решатели, в цепочках поставок их практически не используют. Я считаю, что проблема масштабируемости очень серьезна.
Если проанализировать методы, доступные на рынке, то получаем, что в первую очередь применяются хорошо себя ведущие функции потерь — выпуклые функции. Выпуклые функции означают, что у ваших функций плавная кривая, и когда вы выбираете решение, можно плавно скатиться к минимуму, следуя за градиентами. Так, хорошо себя ведущими являются линейные и квадратичные функции. Такие функции не вызывают проблем с масштабируемостью, можно иметь буквально миллиарды переменных. Но задачи, с которыми мы сталкиваемся в цепочках поставок, не обладают такой хорошей структурой.
Затем существует второй класс решателей, таких как метод ветвей и границ, метод ветвей и отсечений, которые, по сути, предполагают, что ограничения доминируют, то есть существует очень мало допустимых решений. У вас столько ограничений, что вы можете исключить целую гиперплоскость из пространства решений. По сути, можно разделить пространство решений пополам и сказать: «Эту половину можно отбросить, ведь я точно знаю, что эти решения никогда не удовлетворят моим ограничениям». И буквально, вы можете отбрасывать половину решений и многократно повторять процесс, пока в итоге не останется очень небольшое пространство, которое можно тщательно исследовать.
Существует множество методов так называемой релаксации задач, когда вы рассматриваете задачу без ограничений, находите идеальное решение, а затем снова вводите ограничения. Но эти задачи, если ограничения не строги, масштабируются очень плохо. Таким образом, масштабируемость этих методов во многом зависит от того, насколько свободы остаётся после применения всех ограничений. Проблема в том, что в цепочках поставок задачи включают множество ограничений, но они не являются сверхстрогими.
Подумайте о замке. У замка 10 000 комбинаций, но только одна правильная, все остальные неверны. В цепочках поставок у вас есть ограничения, но они не настолько жёсткие. Например, в рамках ограничения по вместимости полки остаётся огромное количество вариантов. Вы можете решить разместить больше этих товаров. Если присмотреться, это довольно слабое ограничение. Оно не сводит пространство решений к нескольким вариантам. У вас по-прежнему существует абсолютно огромное число решений.
Все те решатели, которые основаны на методах исключения пространства решений — ветвей и отсечений, ветвей и границ и т.д. — при более чем 1000 переменных, как правило, работают крайне неэффективно. Возможно, если зайти в экстремальные пределы с 10 000 переменными, но это уже предел возможностей. Мы говорим о очень мощных машинах с десятками гигабайт оперативной памяти, десятками ЦП и потенциально с многими часами для получения результата. Так что процесс будет супер медленным, и для 10 000 переменных можно подумать: «О, это уже много». Но на самом деле это совсем немного.
Просто представьте, что в мини-маркете будет 5000 продуктов. Но это не 5000 переменных, ведь вопрос сводится к тому, беру я 0 единиц, 1 единицу, 2 единицы, 3 единицы. Допустим, вы ограничиваете число до 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: Ну, Joannes, большое спасибо за ваше время. У меня больше нет вопросов. И спасибо всем за просмотр. До встречи в следующий раз.
