Почему инициативы по искусственному интеллекту терпят неудачу в сфере поставок - Ep 168

00:00:00 Введение и уточнение темы
00:02:55 Компании пересматривают старые подходы с помощью искусственного интеллекта
00:04:28 Неудачи умных инженеров в сфере поставок
00:05:44 Автоматический перевод веб-сайта Lokad с помощью LLM
00:09:15 Четыре ключевых доказательства неудач
00:12:24 Почему запросы на предложения неэффективны
00:21:28 Почему временные ряды неэффективны
00:32:47 Почему безопасные запасы неэффективны
00:50:04 Почему уровни обслуживания неэффективны
01:09:59 Вопросы аудитории
01:32:15 Заключительные мысли

Резюме

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

Расширенное резюме

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

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

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

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

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

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

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

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

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

Полный текст

Конор Доэрти: Добро пожаловать на LokadTV, транслирующуюся сегодня прямо из нашей новой студии. Мы закрываем 2024 год с безобидной и легкой темой, основанной на его обсуждении на SCT Tech. Джоаннес Верморель, сидящий рядом со мной, объяснит свою точку зрения о том, почему инициативы по использованию искусственного интеллекта в цепях поставок, вероятно, обречены на провал. Не стесняйтесь задавать свои вопросы в прямом эфире, и мы ответим на них немного позже. Пока вы здесь, подпишитесь на наш YouTube-канал и следите за нами в LinkedIn.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конор Доэрти: Хорошо, тогда я сразу же бросаю тебе мяч. Что не так с использованием процесса RFP для поиска поставщика?

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

Представьте себе, что вам нужно охватить сотни пунктов, и каковы шансы того, что, составив сотни страниц требований к вашему смартфону, вы получите документ, который дисквалифицирует как Samsung, так и Apple? Скорее всего, да.

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

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

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

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

Конор Доэрти: Хорошо, еще раз, несколько моментов, которые нужно разобрать, потому что их много. Прежде всего, ваша критика… Ой, извините, позвольте мне вернуться назад. Я видел некоторые из тех RFP-запросов, о которых вы говорите. Я видел некоторые примеры вроде “У вас еще есть факс-машина? Храните ли вы отчеты факса в огнестойких шкафах?” Я имею в виду, я видел такие вещи. Конечно, это абсолютно бессмысленно. Это RFP-запрос в его текущем состоянии. Вы говорите, что в общем, вне зависимости от плохой реализации, концепция использования RFP-запросов для поиска программного обеспечения - это просто абсолютно безумная вещь? И если ответ на это утвердительный, объясните, пожалуйста, какова будет альтернатива.

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

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

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

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

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

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

Жоанн Верморель: Именно так.

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

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

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

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

Conor Doherty: Что не так с тем, чтобы получить одну действенную точку данных для планирования, например, спрос на следующую неделю составит 10 единиц? Звучит замечательно.

Joannes Vermorel: Основная проблема заключается в том, что вашу цепь поставок нельзя осмысленно представить с помощью временных рядов. Что это означает?

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

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

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

Conor Doherty: И это имеет значение. Почему?

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

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

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

Joannes Vermorel: Это совершенно разное. Опять же, если мы посмотрим на перехватываемые товары в магазине, временные ряды позволят вам представить ваш уровень запасов в течение времени. Итак, сколько у вас единиц товара в наличии в магазине для йогуртов, скажем? Но реальность в том, что ваши товары подвержены порче, поэтому у них есть срок годности. Давайте снова рассмотрим, у вас есть 10 единиц товара в наличии. Это представление временного ряда. Накануне у вас было 11 единиц, и так далее. У вас есть текущий уровень запасов. Это представление временного ряда. Теперь вы думаете: “У меня есть 10 единиц товара в наличии. Это хорошо или плохо? Достаточно или нет?”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конор Доэрти: У Локада есть специальный термин для этого, например, перспектива корзины. Я думаю, мы даже несколько недель назад или, может быть, месяц назад опубликовали на LinkedIn карточку, описывающую это. Как вы сказали, люди обычно не заходят в супермаркет и не покупают только одну вещь. Они покупают с определенным списком в голове, и отсутствие одной вещи может привести к потерям. Если люди покупают несколько вещей, они заходят и покупают 10 предметов, и 11-й предмет, который они хотели, не оказывается в наличии, и это критически важный предмет, то вы не теряете только продажи 11-го предмета. Если человек уходит из-за отсутствия 11-го критического предмета, вы теряете все продажи в этой корзине. Так что это перспектива корзины. Между всеми этими вещами есть взаимосвязь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Именно поэтому я говорю, что с помощью мысленных экспериментов, если у вас есть показатель, который, когда вы настраиваете настройки компьютера, не меняя ничего в магазине, вы можете произвольно изменять ваши цифры, то ваш показатель - полная ерунда. Что бы вы ни хотели использовать в качестве показателя качества обслуживания, очевидно, он не должен зависеть от технических деталей вашей компьютерной системы. Было бы безумием, если бы физик сказал: “Какой вес у этой бутылки?”, и ответ зависит от того, настроена ли компьютерная система на русский или французский язык. Это просто безумие. Ответ очевидно полностью независим. Или представьте себе, что вес зависит от того, является ли это машина с Linux или Windows. Безумие. Вы ищете характеристики, которые должны быть полностью независимы от вашей компьютерной системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конор Доэрти: Хорошо, ну, Йоаннес, спасибо. У меня больше нет вопросов, но сейчас я перейду к некоторым вопросам из аудитории. Большое спасибо. Итак, в произвольном порядке, относясь к четырем доказательствам, к вашим четырем способам: RFP, временным рядам, запасам безопасности и уровням обслуживания. Если эти практики так плохо служат компаниям, то что, по вашему мнению, мешает руководству просто отказаться от них?

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

Удалить что-либо очень сложно, особенно во Франции. Но везде, знаете ли, мы можем пошутить о том, что во Франции есть Банк Франции, который является учреждением, посвященным управлению валютой, которая не существует с 1992 года. У нас есть анти-учреждение, которое занимается управлением валютой, которая не существует уже 30 лет. И, кстати, в Париже работает около 14 000 сотрудников. Но вы видите, то, что происходит на грандиозном уровне в государственных структурах, происходит на меньшем уровне в крупных компаниях. Бюрократии имеют тенденцию расти самостоятельно, это закон Паркинсона.

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

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

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

Представьте себе, что произошло с Илоном Маском в Twitter, когда он сказал: я только что уволил 80% сотрудников, и Twitter, теперь X, стал более гибким, чем когда-либо. У него больше пользователей, чем когда-либо, и в целом они добавили множество функций, которые предыдущая команда, в пять раз больше, не могла сделать за предыдущие десятилетия. Это отражает силу удаления вещей, но это крайне сложно. Это очень, очень сложно. Так что я бы сказал, что эти вещи не движутся, потому что удаление чего-либо крайне сложно, даже если это критически важно.

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

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

Конор Доэрти: Когда вы говорите о числовых рецептах.

Йоаннес Верморель: Это то, что вычисляет ваши решения в цепи поставок, например, сколько вы должны заказать, сколько вы должны произвести, где вы должны распределить запасы и так далее.

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

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

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

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

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

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

Конор Доэрти: Да, это лечение симптомов, а не причины.

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

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

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

Теперь проблема в том, что планирование внезапно… Вот что я называю системой записей. Планирование внезапно входит в область системы интеллекта, принятия решений. Теперь, почему системы ERP ухудшили ситуацию? Потому что поставщики очень быстро поняли к концу 90-х годов, что системы записей, также известные как CRUD-приложения (Create, Read, Update, Delete), уже стали товаром. Это уже было товаром 20 лет назад.

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

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

Почему? Потому что ваша система, ваше ERM, скажем, основывается на централизованной базе данных, и это общий ресурс для всех и каждого процесса в вашей компании. Так что все сходится к этой одной базе данных. Если вы заморозите эту базу данных на миллисекунду, это означает, что все остальное будет задержано на миллисекунду. Вы можете сказать: “О, миллисекунда - это ничто”. Да, но теперь у вас есть 500 человек, делающих это. Хорошо, это не 500, теперь это 500 миллисекунд задержки, которые начинают становиться заметными.

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

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

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

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

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

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

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

Конор Доэрти: Что ж, еще раз, чтобы продолжить эту тему о системах интеллекта и о необходимости реального времени в расчетах в зависимости от того, что вы пытаетесь рассчитать. Так что, чтобы дать представление о масштабе, если речь идет о заказе на пополнение запасов, если вы говорите о магазине или клиенте, скажем, 300 магазинов и, для округления, 50 000 SKU, вы будете говорить о 10 часах, 12 часах, как обработке на ночь для принятия этих решений, в отличие от системы записей, которая просто будет…

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

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

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

Conor Doherty: Однако есть примеры, снова, чтобы перейти, скажем, от розницы к чему-то вроде авиакосмической отрасли. Есть примеры, когда вы хотели бы, чтобы решения генерировались за несколько минут, а не даже за час. Например, 60 минут может быть катастрофическим с финансовой точки зрения. Так что снова, это не значит, что самое быстрое, что мы можем сделать, это 60 минут. Это зависит от контекста отрасли.

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

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

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

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

Conor Doherty: Хорошо, Joannes, спасибо. Вопросов больше нет. Большое спасибо за ваше время. Прошло около полутора часов, поэтому я дам вам минуту для заключительной мысли. Что-нибудь, что вы хотите сказать, прежде чем мы уйдем?

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

Conor Doherty: Да, хорошо. Ну, на этой радостной и праздничной ноте, Joannes, большое спасибо за ваше время и спасибо всем за просмотр. Увидимся в 2025 году.