00:00:00 Введение и разъяснение темы
00:02:55 Компании, пересматривающие старые подходы с использованием ИИ
00:04:28 Неудачи умных инженеров в цепях поставок
00:05:44 Автоматизированный перевод сайта Lokad с помощью LLM
00:09:15 Четыре ключевых доказательства неудач
00:12:24 Почему RFP не работают
00:21:28 Почему временные ряды не работают
00:32:47 Почему запасы безопасности не работают
00:50:04 Почему уровни сервиса не работают
01:09:59 Вопросы аудитории
01:32:15 Заключительные мысли
Резюме
В недавнем выпуске LokadTV Конор Дохерти и Жоаннес Верморель обсудили внутренние недостатки мейнстримового управления цепями поставок, особенно чрезмерную зависимость от ИИ. Верморель раскритиковал устоявшиеся практики, такие как запросы предложений, прогнозирование временных рядов, расчёт запаса безопасности и уровни сервиса, утверждая, что они устарели и экономически нецелесообразны. Он подчеркнул, что ИИ не может исправить эти глубокие проблемы, так как пока не достиг уровня интеллекта человека. Верморель предположил, что практические корректировки, основанные на опыте специалистов, зачастую компенсируют недостатки этих методов. Беседа завершилась сессией вопросов и ответов, что подчеркнуло сложность отказа от устоявшихся процессов в крупных компаниях.
Расширенное резюме
В недавнем выпуске LokadTV Конор Дохерти, директор по коммуникациям в Lokad, принял участие в содержательной дискуссии с Жоаннесом Верморелем, генеральным директором и основателем Lokad, о ловушках инициатив в области ИИ в управлении цепями поставок. Беседа, состоявшаяся в новой студии Lokad, вращалась вокруг утверждения Вермореля, что мейнстримовые подходы к управлению цепями поставок, особенно с участием ИИ, по сути, ошибочны и обречены на провал.
Верморель начал с критики устоявшихся практик в управлении цепями поставок, которые, по его мнению, оставались неизменными с конца 1970-х годов. Он утверждал, что простое добавление ИИ к этим устаревшим методам не является решением, а скорее бессмысленной затеей. Верморель подчеркнул, что неудачи прошлых инициатив в области цепей поставок, даже если их возглавляли очень умные инженеры, должны служить предупреждением против чрезмерной зависимости от ИИ.
Конор Дохерти возразил, указав, что многие воспринимают ИИ как панацею для проблем цепей поставок. Верморель ответил, отметив ограничения ИИ на примере ChatGPT. Он объяснил, что если даже высокоинтеллектуальные инженеры не смогли решить эти проблемы, то нереально ожидать успеха от ИИ, который ещё не достиг уровня интеллекта человека. Он подчеркнул, что ИИ может снижать затраты и повышать эффективность в областях, где решения уже известны, но он не может решить фундаментально ошибочные проблемы.
Дискуссия затем перешла к конкретике, почему Верморель считает, что текущие практики в цепях поставок ошибочны. Он выделил четыре ключевые области: запросы предложений (RFP), прогнозирование временных рядов, формулы для расчёта запаса безопасности и уровни сервиса. Верморель утверждал, что RFP, особенно для enterprise software, не работают, поскольку предполагают уровень знаний и конкретики, который является нереалистичным. Он сравнил этот процесс с написанием подробной спецификации для смартфона без понимания его сложности, что приводит к отбору, часто дисквалифицирующему лучших поставщиков.
Прогнозирование временных рядов, по мнению Вермореля, является ещё одной ошибочной практикой. Он объяснил, что данные временных рядов могут давать ложное представление, поскольку не учитывают важные нюансы, например, разницу между наличием одного крупного клиента и множества мелких. Этот недостаток детализации может привести к плохому принятию решений и увеличению рисков.
Формулы расчёта запаса безопасности и уровни сервиса также подверглись критике за их неэкономичный и чрезмерно упрощённый характер. Верморель утверждал, что эти метрики не учитывают более широкий экономический контекст и часто приводят к субоптимальным решениям. Он предположил, что более целостный подход, учитывающий всю систему и её экономическое воздействие, был бы более эффективным.
Конор Дохерти обратил внимание на то, что многие компании всё ещё добиваются значительного успеха, используя эти ошибочные методы. Верморель признал это, однако объяснил, что успех связан с практическими корректировками на основе опыта специалистов, а не с теоретическими моделями, преподаваемыми в управлении цепями поставок. Он отметил, что эти специалисты часто полагаются на таблицы и ручные корректировки для устранения недостатков устоявшихся методов.
Беседа завершилась сессией вопросов и ответов, в ходе которой аудитория могла задать интересующие её вопросы. Верморель подчеркнул, что главным препятствием для перемен в крупных компаниях является сложность отказа от устоявшихся процессов. Он отметил, что внедрение новых технологий, таких как ИИ, намного проще, чем устранение устаревших практик, даже если последние могли бы привести к лучшим результатам.
В заключение, по мнению Вермореля, современные мейнстримовые подходы к управлению цепями поставок по своей сути ошибочны, и ИИ, хотя и может быть полезен в некоторых случаях, не способен решить эти глубокие проблемы. Он выступает за более экономически обоснованный подход, учитывающий всю систему и её сложности, а не за упрощённые и устаревшие метрики.
Полная расшифровка
Conor Doherty: Добро пожаловать на LokadTV, сегодня мы в прямом эфире из нашей, надо сказать, прекрасной новой студии. Мы заканчиваем 2024 год с безобидной и лёгкой темой, основанной на обсуждении на SCT Tech. Жоаннес Верморель, сидящий непосредственно слева от меня, расскажет, почему, по его мнению, инициативы в области ИИ в цепях поставок, вероятно, обречены на крах и провал. Не стесняйтесь задавать вопросы в прямом эфире, и мы немного позже к ним вернёмся. Пока вы с нами, подпишитесь на наш канал YouTube и следите за нами в LinkedIn.
Conor Doherty: И ещё один организационный момент, прежде чем мы начнём говорить о том, насколько мы умнее всех остальных. Было бы невежливо не отметить усилия стольких людей, благодаря которым студия, которую вы видите перед собой, выглядит так прекрасно. Всё — от экранов позади меня до микрофонов перед Жоаннесом и мной — является результатом огромной работы в Lokad, в особенности Максима Лариё, работающего за камерой, и Батиста Грисона. Большое спасибо вам обоим за ваши усилия. А теперь, Жоаннес, скажи, почему люди такие глупые?
Joannes Vermorel: В общем, я думаю, что это проклятие человеческого вида, включая меня самого. Но, честно говоря, с этим игривым заголовком я хотел привлечь внимание к тому, что то, что я обычно называю мейнстримовым подходом к управлению цепями поставок, на протяжении последних четырёх десятилетий оказалось в значительной степени нефункциональным. Технологии и практики в этой сфере по сути зашли в тупик. То, что компании делают сегодня, концептуально почти не изменилось с конца 70-х. Это те же числовые рецепты, те же идеи, и это работает не очень хорошо.
Теперь идея о том, что можно просто оставить всё как есть и добавить немного волшебного ИИ-порошка, после чего все проблемы исчезнут, на мой взгляд — безумие, или, как сказано в заголовке, глупость. Снова повторю, я не думаю, что люди в конце 70-х были глупыми, чтобы попробовать такое. Я просто хочу сказать, что после четырёх десятилетий непрерывных неудач отсутствие обучения на прошлых ошибках и есть источник глупости. Когда я вижу компании, пытающиеся пересмотреть свои подходы и процессы в цепях поставок с использованием генеративного ИИ, мне не нужно ждать, чтобы увидеть, как всё развернётся. Я уже знаю, что это просто не сработает. Это будет огромной тратой времени, сил и денег.
Conor Doherty: Но многие, на самом деле, рассматривают ИИ как некое универсальное средство для решения проблем цепей поставок. То есть, всё, что сломано, имеет недостатки или основано на неправильных предположениях, будет исправлено благодаря внедрению генеративного ИИ, например. Так вы утверждаете, что в основе этого подхода лежит заблуждение?
Joannes Vermorel: Абсолютно. Давайте на секунду остановимся и представим, что ChatGPT обладает уровнем интеллекта инженера из MIT. Отлично, у нас теперь искусственный общий интеллект. Оказывается, многие конкуренты Lokad за последние четыре десятилетия делали именно так. Они берут инженеров из MIT, поручают им крупные проекты в области цепей поставок, с целью избавиться от электронных таблиц и автоматизировать решения. Они очень умны, им дают бюджет и время, но всё равно терпят неудачу.
Эти неудачи не являются исключением. Практически любая компания, которую я знаю, с оборотом свыше одного миллиарда долларов и существующая, скажем, более 20 лет, имеет за плечами три или четыре неудачные инициативы в области цепей поставок. Эти инициативы, направленные на устранение электронных таблиц путём внедрения более умных, гораздо более интегрированных числовых рецептов, потерпели неудачу. Так что теперь вопрос: если даже высокоинтеллектуальные инженеры не смогли добиться успеха, то почему вы думаете, что использование чего-то с уступающим интеллектом, ведь, будем честны, ChatGPT пока не достиг уровня интеллекта человека, внезапно приведёт к успеху?
Автоматизация интеллекта приносит преимущество в виде сокращения затрат. Например, в Lokad мы роботизировали перевод нашего сайта. Если вы посмотрите на сайт Lokad.com, то увидите, что он доступен на многих языках. В течение десятилетия мы делали это с помощью профессиональных переводчиков. Сейчас же всё выполняется автоматически с использованием крупных языковых моделей. Отлично. Мы сэкономили средства, но по сути это была проблема, которую мы уже умели решать вручную с помощью людей. ИИ не решил неразрешимую проблему — перевод. Он просто позволил нам делать это дешевле и быстрее, и это замечательно.
Но если теперь вернуться к исходной проблеме, а именно к прогнозной оптимизации в цепях поставок, если все ваши предыдущие попытки провалились, несмотря на то, что у вас были в распоряжении очень умные инженеры, то почему вы думаете, что наличие менее гениальных и чуть более «фешенебельных» инструментов действительно изменит ситуацию?
Conor Doherty: То, что вы только что упомянули, наталкивает на следующий вопрос: когда вы используете термин «глупость», я хотел бы немного его разобрать. Я понимаю, что он был преднамеренно провокационным, но даже при этом, когда вы говорите о компаниях, принимающих решения на основе ошибочных предположений — мы ещё вникнем в детали — а когда вы упоминаете, что компании постоянно совершают ошибки, это одна из форм ошибки. Возможно, вы могли бы щедро отнести это к глупости. Есть ещё альтернатива — невежество. Невежество нейтрально.
Глупость, тупость, идиотизм — эти термины изначально использовались в психиатрической литературе и относились к когнитивным нарушениям. Они имеют очень специфическое значение. Невежество же нейтрально. У вас и у меня IQ может достигать 180 в худший день, но мы оба не знаем многого. Я ничего не понимаю в ботанике, мне неизвестно, как шнуруются шнурки, но я не глуп. У меня есть все необходимые нейронные ресурсы для обучения этому; у меня просто нет времени или доступа к информации. Так что, если говорить о том, что компании принимают плохие решения, приводящие к ужасным или субоптимальным результатам, а затем есть компании, которые вообще не знают об альтернативных парадигмах, — считаете ли вы это двумя справедливыми представлениями проблемы или просто результатом глупости людей, совершающих ошибки?
Joannes Vermorel: Да, это справедливое представление проблемы, которое подводит нас к вопросу, что же именно мы наблюдаем. Когда мы вникаем в детали, становится понятно, говорим ли мы о глупости или о невежестве. Мое сегодняшнее утверждение заключается в том, что при детальном рассмотрении очевидно, что называть это невежеством — это преувеличение.
Conor Doherty: Давайте перейдём к деталям. У вас есть четыре ключевых доказательства, или четыре способа показать, что вы считаете проблемой либо естественную глупость, либо естественное невежество в корпоративном принятии решений. Это RFP, прогнозирование временных рядов, формулы для расчёта запаса безопасности и уровни сервиса. Мы рассмотрим каждое из них систематически, но с общей точки зрения, в чём, по вашему мнению, заключается суть этих четырёх концепций?
Joannes Vermorel: Я выбрал четыре, но их может быть и 20. По крайней мере, четыре основных ингредиента мейнстримовой теории и практики управления цепями поставок. Эти элементы можно найти, вероятно, в 90% крупных компаний. В небольших компаниях ситуация варьируется, но эти практики, как правило, довольно униформны среди крупных фирм. Из-за их повсеместности мы можем посмотреть на эти практики и задаться вопросом: имеет ли это хоть какой-то смысл? Нужно ли мне иметь докторскую степень MIT, чтобы понять, что это полная ерунда или нет?
Если за одну минуту вы можете понять, что это полная ерунда, просто внимательно изучив ситуацию, то мы однозначно относимся к кате глупости. Если единственный способ осознать свою ошибку — провести очень замысловатый, сложный эксперимент, требующий больших затрат и времени, тогда это больше ошибка, относящаяся к невежеству.
Conor Doherty: Как я уже сказал, давайте разберём их по порядку. Итак, первое доказательство в вашем аргументе — существование RFP. Предполагаю, что это общий термин для запросов предложений, запросов котировок, запросов информации и т.д. Это всё?
Joannes Vermorel: Да, и снова, конкретно для корпоративного программного обеспечения, предназначенного для оптимизации цепочки поставок. Мы можем обсудить это… Я не говорю о том, что RFP является правильным способом закупки оптовой бумаги или какого-то явно очевидного товара. Контекст — цепочка поставок, да. И, более конкретно, если вы хотите иметь штрих-кодовые принтеры для вашей цепочки поставок, это не то, о чем я говорю. Я говорю конкретно о том, что вы хотите закупить для поддержки процесса принятия решений. Под цепочкой поставок я имею в виду именно это. Я не имею в виду логистику, я не имею в виду найм водителей грузовиков. Я имею в виду процессы принятия решений, которые управляют потоком. То есть все мелкие детали: что вы покупаете, что производите, по какой цене продаете, куда складываете запасы — всё это.
Conor Doherty: Ладно, тогда я сразу же возвращаю вопрос к вам. Что не так в использовании процесса RFP для выбора поставщика?
Joannes Vermorel: RFP полностью нефункциональны. Если вы хотите понять, для кого предназначен RFP, просто представьте, что вам приходится в документе Word описывать все, что вы ожидаете от вашего смартфона. Это полный абсурд. Вы не знаете. У него огромное количество функций. Большая часть работы вашего смартфона происходит благодаря множеству вещей, о которых вы не имеете представления. Просто перечислить все эти функции — это колоссальная работа, и если вы попытаетесь описать, что, по вашему мнению, делает ваш смартфон, скорее всего, вы допустите массу ошибок.
Представьте, что у вас есть сотни пунктов, которые нужно учесть, и каковы шансы, что, составив сотни страниц требований к вашему смартфону, вы получите документ, который дисквалифицирует и Samsung, и Apple? Скорее всего, именно так и будет.
Корпоративное программное обеспечение чрезвычайно сложно, и эта сложность в первую очередь отражает проблему, которую вы хотите решить. Оптимизация цепочки поставок сама по себе очень сложна и запутана, поэтому нельзя ожидать суперглавного простого решения. Вы же не покупаете железо тоннами или сырьевую нефть. Вы приобретаете нечто очень утонченное, и это означает, что у вас нет поставщиков, которые могли бы замещать друг друга. Нет простого соответствия между тем, что предлагает поставщик X, и тем, что предлагает поставщик Y.
Проблема RFP заключается в том, что он предполагает, что вы уже точно знаете своё решение, что у вас есть полная спецификация, а затем вы пытаетесь направить, по сути, большое количество поставщиков к вашему списку требований. Программное обеспечение просто не работает так. Создание хорошего программного обеспечения занимает около десятилетия, с небольшими отклонениями. Ни один поставщик не пойдет на кардинальную адаптацию своей технологии ради вашего RFP. Вы заставляете всех пробираться через сотни страниц абсурдных требований.
Процесс настолько нелогичен, что обычно, когда мы получаем RFP, документ содержит что-то вроде 400–600 вопросов, и эти вопросы полны орфографических ошибок. Очень часто даже название клиентской компании написано с ошибками, потому что людям было все равно на сами вопросы. Это поручили интернам, консультантам или кому угодно. Вы создаёте огромный объём бумажной работы, и никто даже не понимает, что означают половина вопросов, так как они сформулированы ужасно. Большинство вопросов даже не являются вопросами, а замаскированными требованиями.
Затем поставщик отвечает десятками, возможно, сотнями страниц ответов, которые никто не читает. Существует комитет, который рассматривает их по этапам, и мысль о том, что из этого абсолютно иррационального процесса может выйти рациональное решение, просто поражает воображение. В реальной жизни нет ситуации, когда вы, как отдельный человек, участвовали бы в таком безумном процессе. Почему вы думаете, что вдруг, только потому что вы работаете в крупной компании, то, что в обычной жизни выглядело бы совершенно безумно, вдруг становится разумным просто потому, что это стандартная практика крупной корпорации? Это не так.
Conor Doherty: Итак, ещё несколько моментов, которые стоит разобрать, поскольку их много. Прежде всего, касается ли ваша критика… О, извините, позвольте вернуться. Я видел некоторые из RFP, о которых вы говорите. Я видел примеры вроде: “У вас ещё есть факс? Храните ли вы ваши факсовые отчёты в огнеупорных шкафах?” То есть, я видел такие вещи. Конечно, это абсурд в чистом виде. Это RFP в его нынешнем виде. Вы говорите, что в вакууме, без учета плохого исполнения, в общем, концепция использования RFP для поиска программного обеспечения — это просто безумие? И если ответ да, пожалуйста, объясните, какая альтернатива может быть.
Joannes Vermorel: Нет, идея проведения маркетинговых исследований не является безумной. Конечно, если вы хотите выбрать поставщика, вам нужно провести маркетинговое исследование. Но мысль о том, что необходимо придерживаться устоявшихся практик RFI, RFP, — это абсурд. Вот моя точка зрения. Эти практики глубоко ошибочны, чрезвычайно, чрезвычайно ошибочны. Когда у вас есть процесс, который полностью не работает, импровизация оказывается куда лучше.
Если вы занимаетесь чем-то, что не работает, что настолько ужасно, прекратите это делать, и почти всё остальное окажется лучше. Всё, что не станет ещё более бюрократичным. Я считаю, что крупным компаниям лучше воспользоваться неформальным процессом, и всё. Если вы готовы рассмотреть возможность более совершенного процесса, то существует альтернативный путь. Об этом я говорю в одной из моих лекций по антагонистическим маркетинговым исследованиям, где изложен лучший способ действий. Но даже без знания этого лучшего пути, просто отказ от этого бессмысленного процесса уже будет улучшением.
Наличие чрезмерно бюрократичного процесса — это не хорошо. Это ужасно. Это замедляет всё, размывает ответственность всех и неблагоприятно влияет на отбор поставщиков. Представьте, опять же, вернёмся к Apple. Вы действительно думаете, что Apple, если вы проведёте для них RFP, обратят на вас внимание? Изменят ли они свой драгоценный iPhone, чтобы угодить вашим корпоративным требованиям? Нет, они этого не сделают. Таким образом, вы фактически заставляете хороших поставщиков сами отказываться от участия в вашем маркетинговом исследовании, что является полной нелепостью. Это противоположно вашим интересам.
На мой взгляд, когда у вас есть что-то вроде рака, удалите рак и не задавайте себе вопрос: “Что я поставлю вместо рака?” Если вы удалили рак, вы уже сделали что-то хорошее. Это улучшение. Теперь мы можем обсудить, что могло бы быть ещё лучше, что поставить взамен, но первая задача — признать, что, устраняя рак, вы улучшаете ситуацию.
К сожалению, и вот к чему приводит бюрократическая глупость, — это мысль, что единственная альтернатива бюрократическому кошмару — это ещё один вид бюрократического кошмара. Это полнейшая нелепость. Честно говоря, за 15 лет в бизнесе я не встречал ни одного RFP, который не был бы глубоко, глубоко нефункциональным. Это лишь вариации между кругами ада. Некоторые RFP напоминают пятый круг ада, другие — девятый круг ада. Это просто различие в уровне ночного кошмара, но в остальном они все одинаково ужасны.
Conor Doherty: Это были бы Томас Совелл и Данте Алигьери в течение 60 секунд. Было очень здорово. Хотя, на самом деле, это переходит от первого пункта, касающегося RFP и критики RFP и RFQ и тому подобного. Это своего рода способ выбора поставщика AI.
Joannes Vermorel: Точно.
Conor Doherty: Позвольте закончить вопрос, так как я немного перехожу к другой теме. Второй пункт: как только вы выбрали поставщика AI, мы переходим ко второму аспекту — прогнозированию временных рядов, которое вы приводите как второе доказательство того, почему ваша инициатива в области AI провалится. Это происходит после того, как вы уже выбрали поставщика. В чём же проблема с временными рядами?
Joannes Vermorel: Итак, как только вы выбрали… Прежде всего, скорее всего, благодаря вашему RFP, вы выберете очень плохого поставщика. Это неизбежно. Ваш процесс не имеет никакого смысла, поэтому, скорее всего, вы получите одного из худших поставщиков, который специализируется на выполнении всего, что соответствует требованиям RFP, независимо от количества абсурдных пунктов. Вы уже находитесь в положении, когда провал почти гарантирован, даже если поставщик не был бы настолько нефункциональным. Но вы действительно выбрали нефункционального поставщика с самого начала. И вот мы подошли к временным рядам.
Временные ряды — это как Альфа и Омега современной традиционной концепции цепочки поставок. Что такое временной ряд? Это просто последовательность точек, распределённых по определённому интервалу. Это может быть одно значение в день, одно в неделю или в месяц. Когда я говорю о перспективах временных рядов, я имею в виду, что вы смотрите на всё через призму ваших продаж или потока за день, за неделю, за месяц — в агрегированном виде. Всё как-то укладывается в эти временные ряды.
Очевидно, что с этими временными рядами вы хотите, или, по крайней мере, согласно традиционной теории цепочки поставок, должны стремиться к прогнозам временных рядов, то есть к их продлению в будущее. Если у вас есть данные продаж до сегодняшнего дня, вам нужен прогноз, который представляет собой просто продление этих временных рядов в будущее. То есть вы получите данные о продажах на завтра, послезавтра и так далее.
Conor Doherty: Что не так с тем, чтобы получить одну конкретную точку данных для планирования, например, спрос на следующей неделе составит 10 единиц? Звучит отлично.
Joannes Vermorel: Основная проблема в том, что вашу цепочку поставок нельзя адекватно представить с помощью временных рядов. И что это означает?
Начнём с очень простой ситуации. У вас есть продукт, который стабильно продаётся 1,000 единиц в день. Он продавался по 1,000 единиц в день, скажем, последние три года. Отлично. Итак, как выглядит будущее? Теперь я рассмотрю две ситуации, имеющие абсолютно одинаковую историю. Ситуация номер один: у вас тысяча различных клиентов, и они время от времени заказывают этот продукт. В сумме эти 1,000 клиентов обеспечивают 1,000 единиц в день. Некоторые клиенты уходят, некоторые приходят, но всё стабильно. Это и формирует временной ряд. А что это говорит? Это говорит о стабильном спросе, который кажется достаточно устойчивым. Тысяча клиентов — это не миллионы, но и не ноль, так что выглядит неплохо.
А теперь вторая ситуация — у вас 1,000 единиц в день, но от одного клиента. Да, этот клиент стабильно заказывает 1,000 единиц в день последние несколько лет, но это всего лишь один клиент. Какие же шансы, что спрос завтра упадёт до нуля и останется нулевым навсегда? Конечно, в первой ситуации с тысячей клиентов я бы не сказал, что это невозможно, но вероятность крайне мала. Даже если произойдёт катастрофическое событие, наносящее ущерб бренду, большинство клиентов даже этого не заметят. Даже если случится крупный случай мошенничества, у вас всё равно останутся сотни клиентов, которые узнают об этом не сразу. Таким образом, вероятность того, что все эти клиенты в идеальной координации прекратят покупки в один и тот же день, не невозможна, но крайне мала. Говорим о вероятности в один к миллиону, вероятно. Это редкость.
А теперь наоборот: если у вас есть только один клиент, одному менеджеру достаточно решить сменить поставщика, и вуаля — вы переходите к нулю. Если вы считаете, что потеря этого лояльного клиента происходит раз в десятилетие, то вероятность составляет примерно 0,1%. Это не один к миллиону; это в несколько порядков больше. Вероятность всё ещё невелика, но по сравнению с первой ситуацией она говорит о том, что такое произойдёт, скорее всего, через несколько лет. Если дать достаточно времени, скажем, десятилетие, это практически гарантировано. Здесь я описываю две очень простые ситуации, имеющие одинаковое представление по временным рядам. В этом и заключается суть проблемы: временные ряды — упрощённая модель. Вы можете столкнуться с несколькими совершенно различными ситуациями, которые, тем не менее, представлены одним и тем же временным рядом.
Conor Doherty: И это имеет значение. Почему?
Joannes Vermorel: Потому что ваши решения будут совершенно разными. Если у вас тысяча клиентов, вы можете быть очень консервативны с запасами. Вы можете сказать, например: “О, у нас будет запас на несколько месяцев, потому что всё в порядке. Если мы потеряем некоторых клиентов, мы скорректируем производство, чтобы избежать избытка товара. Даже если потеряем клиентов, у нас будет время распродать запасы.” Напротив, если у вас один клиент, то, если этот клиент перестанет заказывать, ваши запасы надолго превратятся в мёртвый груз. Всё, что у вас останется — это неизбежное списание запасов.
Таким образом, с точки зрения принятия решений в цепочке поставок у вас две совершенно разные ситуации, требующие совершенно разных решений. Вот почему я говорю, что временные ряды — это безумие. Гипотеза заключается в том, что если вы представите всё как временные ряды, что и делает традиционная концепция цепочки поставок, тогда можно принимать обоснованные решения. А я говорю: нет, нельзя. Нельзя, потому что временные ряды не позволяют зафиксировать некоторые базовые детали вашей деятельности. Вы просто остаётесь слепы. Неважно, сколько у вас временных рядов; всё равно вы застряли с тем фактом, что это неверное представление данных. Это крайне упрощённая модель ваших данных.
Conor Doherty: Извините, просто чтобы разобрать для тех, кто, возможно, не понял, к чему вы клонили, с точки зрения управления рисками нужно применять различные подходы в финансовом распределении, поскольку ваша экспозиция различна.
Joannes Vermorel: Это совершенно разные вещи. Снова, если мы посмотрим на скоропортящиеся товары в магазине, временные ряды позволят вам отобразить уровень запасов с течением времени. То есть, сколько единиц у вас находится на складе, скажем, йогуртов. Но реальность такова, что ваши продукты скоропортящиеся, у них есть сроки годности. Рассмотрим: у вас на складе 10 единиц. Это представление с точки зрения временного ряда. За день до этого у вас было 11 единиц или что-то в этом роде. Ваш уровень запасов фиксирован. Это представление во временном ряду. Теперь вы думаете: “У меня 10 единиц на складе. Это хорошо или плохо? Достаточно ли их?”
Позвольте мне рассмотреть две ситуации. Ситуация A: 10 йогуртов, которые у вас есть на складе, истекут через месяц. Это хорошо. Тот, кто зайдет в магазин, увидит йогурты с оставшимся сроком годности в месяц. Это неплохо для йогуртов. А теперь ситуация B: 10 йогуртов истекают завтра. Это очень плохо. Вашим клиентам не понравится, что им приходится брать йогурты, срок годности которых истекает уже завтра. Возможно, один клиент купит один йогурт, чтобы съесть его на следующий день, но любая мама, делающая покупки для семьи и планирующая неделю, не купит йогурты, которые истекают завтра.
Таким образом, при той же записи — 10 единиц сегодня, что представляет уровень запасов — вы упускаете очень важную информацию, а именно распределение сроков годности. Если у вас есть программная система, полностью сконструированная вокруг этой идеи временных рядов, эта информация всегда будет игнорироваться системой, потому что система даже не может её увидеть. Это не является частью парадигмы временных рядов.
Conor Doherty: И снова, чтобы быть предельно ясным для всех слушающих, скажу: “Хорошо, я все это слышу, понимаю, что вы имеете в виду, следую вашим примерам. Как это влияет на ИИ? Как ИИ вписывается в эту картину?” Даже если вы используете временные ряды или вероятностное прогнозирование.
Joannes Vermorel: Если у вас есть парадигма, в которой ключевая информация теряется — как именно происходит с временными рядами — не имеет значения, смотрит на нее ИИ, очень умный инженер или кто-либо еще. Ключевая информация уже утрачена. Если вы смотрите на данные продаж через призму временных рядов, вы не можете увидеть разницу между одним и многими клиентами. Вы не видите сроков годности. Существует множество вещей, которые просто остаются незамеченными. Если что-то не видно — будь то ИИ, умный инженер или программа, применяющая какие-то правила — основная необходимая информация уже потеряна. Не имеет значения, сколько технологий вы надстроите над этой парадигмой.
Conor Doherty: Хорошо, давайте немного продолжим. Мы рассмотрели первые два подхода: RFP и временные ряды. Третий и четвертый, возможно, можно объединить под метрики, а именно страховые запасы и уровни обслуживания. Обсуждая их по отдельности или вместе, в чем ваше возражение против них? Ведь они довольно распространены. Большинство компаний придерживаются достаточно строгих политик по страховым запасам и уровням обслуживания.
Joannes Vermorel: Проблема со страховыми запасами, для аудитории, в том, что вы предполагаете, что у вас есть прогноз спроса на основе временных рядов, и вы предполагаете, что ваш спрос имеет нормальное распределение, что ваши сроки поставки распределены нормально, а затем выбираете уровень обслуживания. Это дает вам целевое количество запасов, которое необходимо держать под рукой, и это называется страховым запасом. Вот что на самом деле представляет собой страховой запас.
Технически, у вас есть рабочий запас, который является средним спросом, а страховой запас — это дополнительная составляющая поверх среднего спроса. Но это всего лишь технический момент. В целом, если сложить рабочий запас и страховой запас, получится целевое количество запасов, которое вы хотите держать.
В чем же проблема? Проблема в том, что это неправильный способ взгляда на управление запасами. Цель компании — получать прибыль. Страховой запас — это неэкономичный подход к принятию решений. Что это означает? Это означает, что этот метод даже не пытается оптимизировать прибыль. Проблема в том, что у нас есть способ, который даже не стремится оптимизировать прибыль. Почему вы думаете, что этот метод окажется прибыльным?
Как же на самом деле оптимизировать для получения прибыли? Всё очень просто. Рассмотрим, допустим, простую ситуацию — магазин. Выбираете первую единицу товара, которая позволит максимизировать вашу отдачу. Я выбираю эту единицу и размещаю её в магазине. Именно она дает наибольшую отдачу. Затем я выбираю вторую единицу, которая также максимизирует отдачу. Поскольку это магазин, скорее всего, вторая единица будет не тем же продуктом, что и первая.
Суть в том, что я хочу распределить дополнительные единицы, чтобы покрыть больший спрос. Если я говорю, что можно заказать только первую единицу, вы выбираете одну единицу. Теперь, если я скажу, что можно выбрать вторую единицу, вы, скорее всего, захотите взять что-то иное, ведь по крайней мере вы хотите расширить охват спроса в магазине. Если я скажу, что можно выбрать третью единицу, вы снова выберете что-то немного иное.
Суть моего утверждения в том, что подход страховых запасов представляет собой абсолютно неэкономичный взгляд. Он рассматривает продукт в магазине отдельно, и, повторюсь, для аудитории: в небольшом супермаркете может быть около 5000 различных товаров на полках. Он рассматривает один продукт в изоляции, и затем вы самостоятельно решаете, нужно ли вам его больше или меньше. Я говорю, что это абсурд.
Давайте еще раз посмотрим. Если вы делаете это вручную, находясь в продуктовом магазине, вы не будете думать в изоляции о том, нужно ли вам больше или меньше чего-либо. Это компромисс. У вас ограничено место на полках, ограничены деньги, поэтому вы подумаете: «Хватит ли у меня этого? Стоит ли мне пополнить запасы этого продукта, или есть ли что-то еще, что я должен заказать в первую очередь?» Вот так вы рассчитываете возврат инвестиций. Вот так можно мыслить с экономической точки зрения.
Я говорю, что страховой запас — это неэкономичный подход. Это математически интересный метод, по крайней мере с образовательной точки зрения, возможно, для студентов прикладной математики просто как небольшое упражнение. Но если говорить о реальных цепочках поставок, и опять же, я беру очень простую ситуацию, как продуктовый магазин — самый простой пример, который можно представить, — мы видим, что это неэкономичный подход. Так что у нас проблема, Хьюстон. Этот метод даже не пытается улучшить итоговую прибыль моей компании. Это просто неправильно.
Альтернатива, которую я описал, довольно проста. Речь идет о выборе того, что дает наибольшую отдачу. Я выбираю первую единицу, затем вторую и так далее. Мы можем вдаваться в технические подробности того, как именно это делается, но это всего лишь технические моменты. Моя критика страховых запасов заключается в том, что этот метод не может быть разумным подходом, потому что он неэкономичен. На практике вы очень часто сталкиваетесь с абсурдными ситуациями. Например, вы рассчитываете, исходя из страховых запасов, все товары, которые должны быть в вашем магазине, и итоговые цифры просто не сходятся.
Видите, вот к чему все приводит — к абсурду. Ваш страховой запас указывает, что всем этим продуктам нужны именно такие количества, и поскольку все рассчитывается в изоляции, у вас получается 5000 продуктов, и для каждого из них назначается своя цифра. Если сложить все эти количества, итог не укладывается.
Если вернуться к вашему ИИ, что должен делать ваш ИИ? Снова, ваша парадигма говорит, что вы рассчитываете страховой запас. Ваш ИИ, возможно, поможет вам вычислить страховой запас точнее. Я даже не уверен, как это поможет. Но реальность такова, что у вас есть парадигма, которая изначально сломана. Ваш ИИ, независимо от того, как он рассчитывает страховой запас, все равно столкнется с этими странными парадоксами. Какой смысл улучшать что-либо, если используется неэкономичный подход? Ваш ИИ не может извлечь смысл из того, что не имеет экономического значения.
Conor Doherty: Прежде чем перейти к уровням обслуживания, я хотел бы вернуться к одному моменту, который вы упомянули. Вы описали страховые запасы как неэкономичный подход. Я это понял. Вы также говорили о рассмотрении SKU в изоляции, и это ошибочно. Тогда, противоположный подход, видимо, заключается в рассмотрении вещей в комбинации. Можете ли вы немного подробнее рассказать об этом, о разнице между изоляцией и комбинацией?
Joannes Vermorel: Да, я имею в виду, что цепочка поставок — это система. Это означает, что вы не можете отделить части, не изменив их сущность. Продукт, выставленный на полке в продуктовом магазине, — это не то же самое, если продавать его в изоляции. Люди, заходя в продуктовый магазин, ожидают ассортимент товаров, а не один продукт. И то же самое относится практически к любой нетривиальной цепочке поставок. Реальная цепочка поставок будет именно такой. Если вы производите автомобили, вам нужно собрать все эти детали, чтобы в конце дня получить функционирующее транспортное средство. Вы не можете убрать колеса и сказать, что это автомобиль. Автомобиль без колес — не автомобиль, а просто нечто иное.
В основе существуют системы, в которых много различных типов физических товаров, и они имеют смысл только тогда, когда они объединены. Это не значит, что, например, автомобиль не будет работать вовсе, если убрать колеса. В магазине вы можете решить, что, возможно, не хотите держать горчицу на полке. Возможно, клиентам нормально, если у вас нет горчицы, а может, наоборот, вам нужно иметь три различных вида горчицы.
Очевидно, многое зависит от того, что именно вы рассматриваете. Это не черно-белый вопрос. Но в основе, когда вы начинаете продавать горчицу в продуктовом магазине, это имеет смысл только в контексте того, с чем она продается. Так что я говорю, что если вы принимаете подход, рассматривающий эти вещи в изоляции, вы упускаете суть. Вы упускаете то, что делает магазин привлекательным. Вы упускаете динамику процессов.
Люди заходят в ваш продуктовый магазин и покупают не один товар. Некоторые клиенты могут зайти и купить один предмет, но большинство возьмут корзину и купят много товаров. То, что я хочу сказать, так это то, что когда вы придерживаетесь этого подхода страхового запаса, вы принимаете очень странный, чрезмерно упрощенный математический подход, который рассматривает ваши SKU, ваши продукты, в жесткой изоляции друг от друга. Даже рассматривая самую простую цепочку поставок, какую только можно представить — например, продуктовый магазин — этот подход уже лишен смысла. Так почему же вы думаете, что он будет иметь больше смысла в чем-то более сложном, например, в авиации или MRO, или в чем-то еще?
Conor Doherty: У Lokad есть специальный термин для этого — «подход корзины». Кажется, пару недель назад или, может, месяц назад мы действительно выпустили флеш-карту в LinkedIn, описывающую это. Как вы сказали, люди обычно не заходят в супермаркет и не покупают только одну вещь. Они приходят с определенным списком, и отсутствие одного товара может привести к потерям. Если люди покупают несколько товаров, они заходят и покупают 10 предметов, а 11-го, который им нужен, нет, и если этот 11-й товар критически важен, вы теряете не просто продажи 11-го предмета. Если человек уходит из-за отсутствия этого критически важного товара, вы теряете всю продажу, содержащуюся в корзине. Это и есть корзинный подход. Между всеми этими вещами существует взаимосвязь.
Joannes Vermorel: Да, и дело в том, что если мы вернемся к страховому запасу и ИИ, как только вы приняли подход страхового запаса, не имеет значения, будет ли ваш ИИ суперумным или суперглупым, дешевым или дорогим — он уже оказался в безвыходном положении, где решения просто не существует. Вот почему я говорю, что природная глупость всегда перевешивает искусственный интеллект. Не имеет значения, насколько технология изощренна, насколько она доступна, насколько ее можно поддерживать. Всё это становится совершенно неважным, потому что вы уже сформулировали задачу в абсурдной форме.
Conor Doherty: Я с вами согласен. Действительно, соглашусь, однако я бы сказал, что это отличный пример различия, о котором я упоминал ранее, между природной глупостью и невежеством. То, что мы только что описали, является реальным явлением, но оно очень абстрактно. Оно требует определенного понимания взаимосвязей между вещами, которые неочевидны с первого взгляда.
Joannes Vermorel: Я не согласен. Каждый раз, когда вы общаетесь с кем-то, кто совершенно необразован и управляет магазином, он понимает, что это не магия. Мы не говорим о сверхсложной математике. Просто обратитесь к любому продавцу, который занимается этим всего неделю, — и он поймет, что ассортимент имеет значение. Вы не можете определить оптимальное количество товара для продукта, рассматривая его полностью отдельно от остальных.
На самом деле, это своего рода очень замысловатая абсурдность, которую способен пропагандировать только профессор университета. Это абсурд, и единственный способ успешно продвигать подобную идею — находиться в среде, где вы полностью защищены от реальных последствий этой крайне плохой идеи. Если бы вы управляли магазином, вы бы так не думали. Проверьте сами: просто поговорите с кем-либо в вашем районе, кто управляет каким-либо магазином. Если они думают так, как я описал, — нет. Если вы пообщаетесь с тем, кто занимается управлением запасами, оформляет заказы на пополнение, как в семейных магазинах, они, очевидно, смотрят на проблему в целом.
Conor Doherty: Это действительно хороший момент. Здесь нужно провести различие, и мне хотелось бы узнать ваше мнение об этом. Разница между огромными мультимиллиардными конгломератами с невероятно большими цепочками поставок, оформляющими заказы — скажем, сотнями тысяч в день, — и небольшими семейными магазинами, где это магазин Джоаннеса и Джоаннес каждый день вынужден доставать деньги из кармана для покупки этих товаров.
Это напоминает то, что сказал Питер Коттон, когда мы разговаривали с ним полтора года назад. Он сказал, что вы принимаете совершенно разные решения, когда на кону стоят ваши собственные деньги. То, как вы рассматриваете проблему, меняется кардинально, когда вам приходится доставать деньги из кармана. Так что мне интересно: почему вы считаете, что очень крупные компании принимают плохие решения, а если взять пример обычного соседнего магазина.
Joannes Vermorel: Вот где кроется безумие. Крупные компании не принимают таких плохих решений, потому что, несмотря на их заявления, они следуют политике поддержания страховых запасов. А их сотрудники не следуют ей. Вот где это становится безумием. Какова же реальная картина? Реальная картина такова: есть университетские профессора, которые утверждают, что необходимо поддерживать страховые запасы. Есть учебники по цепочке поставок, которые говорят, что нужно делать страховые запасы. Есть поставщики, использующие ИИ для цепочки поставок, которые заявляют, что у них есть ИИ-управляемые страховые запасы. Прекрасно. Затем есть компании, использующие системы, основанные на страховых запасах, или, как их иногда называют, буферами или как-то иначе. Существует множество вариантов.
В конечном итоге, у вас есть специалисты по цепочке поставок — планировщики спроса и предложения, менеджеры по категориям, менеджеры по запасам (названия варьируются) — которые используют свои электронные таблицы для совершенно иных целей. Обычно типичная реакция, которую я слышу, такова: когда я обсуждаю это с этими людьми, они говорят: “О да, страховые запасы — это часть нашего плана. В следующем году, когда мы станем более зрелыми, мы будем использовать их по-настоящему. Но пока у нас так много проблем, что мы делаем что-то совершенно иное. В моих электронных таблицах я работаю по-другому. Я знаю, что это бардак, но это как-то работает. С дополнительным обучением я смогу однажды использовать страховые запасы.”
Это безумие, потому что на деле то, что делает этот человек, имеет смысл. Эта альтернативная методика — именно то, что имеет смысл, а страховые запасы — это просто фарс, окружающий фарс, который не работает. Он не работает хотя бы с 1979 года, как отметил Рассел Акофф. Именно поэтому электронные таблицы никогда не уйдут при таких условиях.
Когда вы заявляете, что замените все эти запутанные электронные таблицы программной автоматизацией, это терпит неудачу. Неудача происходит потому, что страховые запасы — это плохая идея. Неважно, используете ли вы страховые запасы на базе ИИ; это все равно плохая идея. Это идея настолько плохая, что она не работает. Крупные компании пытаются, терпят неудачу и возвращаются к электронным таблицам. Люди придерживаются мнения: “Я делаю что-то немного по-своему. Когда получу больше знаний, буду использовать страховые запасы, но пока мне нужно что-то, что действительно работает.”
Conor Doherty: На этой ноте вы подробно объяснили, в чем заключаются недостатки страховых запасов. Предполагаю, что аналогичная критика относится и к уровням сервиса. Они не совсем одно и то же, но с точки зрения процессов принятия решений, какая же политика применяется для достижения решения? Объясните, в чем заключается ваша проблема с уровнями сервиса, пожалуйста.
Joannes Vermorel: Моя проблема с уровнями сервиса в том, что уровень сервиса является крайне дефектным косвенным показателем качества обслуживания. На самом деле, он почти не имеет ничего общего с качеством обслуживания. То, чего вы хотите, — это качественно обслуживать своих клиентов. Это само собой разумеется, когда вы управляете цепочкой поставок.
Теперь давайте рассмотрим обычный модный розничный магазин. Что означает высокий уровень сервиса? Если приравнивать высокое качество обслуживания к уровню сервиса, это означает, что высокое качество обслуживания равно высокому уровню сервиса. Если вы считаете, что уровень сервиса является хорошим косвенным показателем качества обслуживания, то высокое качество обслуживания подразумевает высокий уровень сервиса.
Если у вас есть магазин, продающий коллекцию вашего модного бренда, что значит иметь высокий уровень сервиса? Это фактически означает, что до самого конца вашей коллекции у вас остаётся каждый продукт, по крайней мере в нескольких экземплярах, на полках. Если уровень сервиса высок, это значит, что ваш магазин до последнего момента полон товаров. Как же вы затем разместите в магазине следующую коллекцию?
Вам нужно освободить место, уступив старую коллекцию, что означает признание того, что для этих товаров уровень сервиса опустится до нуля. Клиенты могут быть вполне довольны, несмотря на то, что для многих товаров уровень сервиса равен нулю. По мере того как одни товары выводятся из ассортимента, другие поступают, и клиенты остаются довольными. Между качеством обслуживания, которое существует только в глазах клиента, и тем, что вы измеряете числовым рецептом — уровнем сервиса — нет никакой корреляции.
Если уровень сервиса является крайне плохим косвенным показателем качества обслуживания, почему вы думаете, что ИИ, предназначенный для управления вашим уровнем сервиса, будет принимать решения, имеющие смысл для вашей компании? Как и моя критика страховых запасов, это не экономическая точка зрения. Здесь у вас есть концепция уровня сервиса, которая не отражает качество обслуживания. Вы даёте ИИ инструмент — уровень сервиса, и он вынужден с ним работать, но оказывается, что этот инструмент совершенно неадекватен для решения проблемы, а именно качества обслуживания.
Conor Doherty: Вы использовали несколько удачных фраз, одна из которых была “уровень сервиса является крайне дефектным косвенным показателем качества обслуживания” и “качество обслуживания существует только в глазах клиентов”. Но это приводит к двухчастному вопросу. Во-первых, какой показатель является хорошим косвенным? И во-вторых, если качество обслуживания существует только в глазах клиентов, то как компании могут на самом деле определить, что у них хорошее качество обслуживания?
Joannes Vermorel: Это очень хорошие вопросы. Давайте сначала рассмотрим косвенные показатели. Проведем несколько мысленных экспериментов. Это способ отсеять действительно плохие варианты. Нам даже не нужно проводить реальный эксперимент в настоящем магазине; можно сделать это мысленно. Это очень дешево. Итак, первое: мы должны согласиться, что если взять магазин с теми же товарами на полках, ничего не меняется. То, что мы считаем качеством обслуживания, не изменится. Если я посмотрю на тот же магазин, с теми же товарами, в то же время, и ничего не изменю, то качество обслуживания, как я его понимаю, не должно меняться.
Давайте ещё раз обратимся к уровню сервиса. Многие компании измеряют уровень сервиса, определяя процент товаров, которые отсутствуют или присутствуют на складе. Если 97% ваших товаров есть в наличии, у вас будет 97%-й уровень сервиса. Существует несколько способов рассмотреть уровень сервиса, например, через stockouts. Это происходит, когда проводится оптимизация страховых запасов, что является немного иной перспективой. Но здесь многие компании работают именно с таким видом отчётов, поэтому я и буду использовать этот.
Теперь представим концептуально, что мы решили удвоить ассортимент магазина. То есть у нас был модный магазин с, скажем, 3000 различными артикулами. Теперь мы заявляем, что в этом магазине должно быть 6000 товаров, но в магазине по-прежнему находятся те же 3000 позиций. Концептуально, в компьютерной системе, управляющей магазином, мы просто объявили, что ассортимент в два раза больше — с большим количеством вариантов, цветов, размеров.
Изменилось ли что-либо с точки зрения клиентов? Очевидно, нет. Это все тот же магазин, те же брюки на полках, те же цвета, те же размеры. Ничего не изменилось. Но в компьютерной системе мы удвоили диапазон допустимого ассортимента. Сделав это, мы разделили уровень сервиса, измеряемый вашей системой, пополам. Если раньше он составлял, скажем, 97%, то теперь он примерно 48%, хотя в магазине ничего не изменилось.
Вот почему я говорю, что если у вас есть косвенный показатель, который, при изменении настроек компьютера, не меняя ничего в магазине, способен приводить к произвольным большим изменениям ваших чисел, то этот показатель — полнейший бред. Любой показатель, который вы хотите использовать в качестве косвенного способа оценки качества обслуживания, очевидно, не должен зависеть от технических деталей ваших компьютерных систем. Было бы безумно, если бы физик сказал: “Каков вес этой бутылки?” и ответ зависел от того, настроена ли компьютерная система на русском или французском языке. Это просто безумие. Очевидно, что ответ должен быть абсолютно независимым. Или представьте, если вес зависит от того, это Linux-машина или Windows-машина. Безумие. Таким образом, вы ищете характеристики, которые должны быть совершенно независимы от вашей компьютерной системы.
То, что я продемонстрировал с уровнем сервиса, показывает, что, играя с ассортиментом, можно добиться значительных колебаний уровня сервиса. Это демонстрация того, насколько на самом деле безумна эта мера. По-моему, если мы обращаемся к качеству обслуживания, мы возвращаемся к идее, что если что-то принципиально безумно, то с этим нужно работать без него. Даже если альтернативы нет, это как опухоль; удалите опухоль, и вам будет лучше без неё. Пока не думайте о том, что следует поставить вместо опухоли.
Можем ли мы получить действительно качественные измерения качества обслуживания? Да, можем. Это совершенно другая область обсуждения, и я предпочёл бы не вдаваться в неё. Но вы понимаете мою мысль. Никаким искусственным интеллектом нельзя преодолеть естественную глупость. Как бы ни были совершенны ваши методы, если ваша исходная предпосылка плоха, это не решит проблему. Если вы начинаете с неправильной концепции, с разрушенной парадигмой, не имеет значения, сколько инструментов вы добавите; ваша парадигма останется сломанной.
Conor Doherty: Да, хорошо, мы можем это принять. Но непосредственная реакция на это такова: когда вы говорите, что эти идеи глупы и парадигмы сломаны, и они не приведут к лучшим решениям, очевидный ответ приходит от генерального директора, который говорит: “О чем вы говорите? В прошлом году мой оборот составил 10 миллиардов благодаря страховым запасам, уровням сервиса, запросам предложений и прогнозированию по временным рядам.” Хотя одновременно может быть истинно множество утверждений, и даже если они конфликтуют, вы, несомненно, понимаете, что для некоторых людей, услышав фразы типа “вы глупы, что делаете это” или “вы некомпетентны” или “это плохие идеи”, они просто указывают на конечный результат и говорят: “Но посмотрите, у меня всё действительно отлично. О чем вы говорите?”
Joannes Vermorel: Давайте начнем сначала. Модные магазины. У нас есть клиенты, и за эти годы мы вели обсуждения с потенциальными клиентами, которые впоследствии стали нашими клиентами. Они говорили, что оптимизируют уровень сервиса. Вот что они говорят, и если вы посмотрите на процесс, так оно и прописано. Но когда начинаешь смотреть, что делают на практике специалисты, оказывается, что они этого не делают. Мы возвращаемся к страховым запасам. Оказывается, что магазины, в основном модный магазин, когда приближается новая коллекция, внезапно решают, что заказывать существенно меньше. Они сознательно допускают резкое падение уровня сервиса. Затем, когда наконец наступает время для новой коллекции, наступает период коротких распродаж, и вдруг оказывается, что места для новой коллекции достаточно.
Таким образом, мы находимся в ситуации, когда компании, особенно высшее руководство, заявляют, что используют уровень сервиса, а на деле не используют. Люди на местах действуют иначе. Вот почему, когда вы пытаетесь автоматизировать, это снова терпит неудачу. Когда вы пытаетесь автоматизировать, вы фактически пытаетесь навязать эту дисфункциональную идею вашей цепочке поставок, что вступает в противоречие с реальностью, и поэтому проваливается. Люди снова возвращаются к электронным таблицам.
Интересно то, что в современном мире цепочек поставок существует огромное количество когнитивного диссонанса. Некоторые из основных постулатов, такие как временные ряды, страховые запасы и уровни сервиса, полностью не работают. Практики действуют совершенно иначе, чем то, что записано в электронных таблицах. Вместо того чтобы воспринимать уровни сервиса как что-то обязательное, они берут их лишь как индикатор и действуют с большой свободой.
Если переформулировать вопрос как “Является ли принципиально неправильным иметь уровень сервиса в качестве какого-либо индикатора?”, я бы сказал, что нет. Это всего лишь одна описательная статистика среди многих других описательных статистик. В этой области может быть масса описательных статистик. Они не хороши и не плохи; они просто более или менее структурированы и дают вам примерно представление о происходящем. Но теория цепочки поставок говорит вам нечто совершенно иное.
Они не говорят, что уровень сервиса — это элемент описательной статистики; они утверждают, что это ваша цель, и вы должны принимать решения, соответствующие этой цели. Я говорю о том, что люди в крупных компаниях почти всегда так не поступают, и они правы. Как и со страховыми запасами, если спросить их, они скажут: “О да, у нас есть цели по уровню сервиса. Нам нужна большая зрелость, и однажды мы будем это делать. Но пока нам нужно что-то, что работает.”
Мы снова оказываемся в безумном положении, когда практики осознают, что делают не то, что предписано, и считают, что займутся этим, когда повзрослеют, наберут больше опыта, возможно, когда у них появится поддержка ИИ. Но этого не произойдет, потому что концепция сломана. Как элемент описательной статистики это приемлемо, а как инструмент для принятия управленческих решений — совершенно не годится.
Conor Doherty: Ну, мне пришлось это обрисовать. Если аргумент таков — и поправьте меня, если я ошибаюсь, — но если аргумент сводится к тому, что в некоторых компаниях существуют эти политики и эти метрики, а практики их просто игнорируют, но при этом есть компании, которые работают действительно, действительно хорошо, вы утверждаете, что они достигают такого успеха благодаря слепой удаче и интуиции практиков, которые просто " кидают пальцем в воздух", угадывая и случайно попадая в точку?
Joannes Vermorel: Нет, я просто говорю, что многие из этих проблем, знаете ли, если не использовать полностью дефектный подход, можно найти грубые решения, которые все же работают для вас. Видите ли, для грамотного управления местным продовольственным магазином не требуется докторская степень Стэнфорда. Вы можете справиться с этим гораздо проще. Вы даже можете постепенно обнаруживать, что работает, а что нет.
Таким образом, я утверждаю, что эти компании могут добиваться успеха, явно не благодаря теории цепочки поставок. У них есть люди с небольшим опытом, которые нашли числовые рецепты, которые просто работают. Они работают достаточно хорошо. Доказательство того, что эта теория не работает, заключается в том, что все эти крупные компании пытались автоматизировать процессы множество раз — примерно раз в пять лет за последние три десятилетия — и каждый раз терпели неудачу. Каждый раз люди возвращались к электронным таблицам.
Почему вы обращаетесь к электронной таблице? Формула страхового запаса крайне проста. Направлять решения по управлению запасами для достижения целевых уровней обслуживания тоже чрезвычайно просто с точки зрения программирования. Это проще простого, мы говорим о примерно 50 строках кода, может быть, и меньше. Так что если бы это работало, всё уже было бы развернуто, и работа всех этих людей уже была бы автоматизирована.
Мой аргумент в том, что это не так, автоматизация далеко не достигнута, потому что эти парадигмы сломаны, и, следовательно, они не могут быть автоматизированы как таковые. То, что содержат эти электронные таблицы, используемые специалистами по цепям поставок, — это альтернативные методики, которые обычно довольно просты, которые, кажется, работают, но концептуально несовместимы как со страховым запасом, так и с уровнями обслуживания.
Конор Дохерти: Итак, какие практические стратегии, по вашему мнению, специалисты по цепям поставок могут теперь использовать, чтобы принимать экономически более обоснованные решения в области цепочек поставок?
Йоаннес Верморель: Видите ли, если мы попытаемся вернуться к ИИ, то суть в том, что вы должны отказаться от иллюзии, что понятия, которые вам известны, которые преподавали в школе или в какой-то ассоциации по цепям поставок, эти понятия просто дисфункциональны. Если вы попытаетесь внедрить сложные инструменты, возможно, генеративный ИИ или глубокое обучение или блокчейн или что угодно еще, что вы можете придумать, это просто не сработает.
Первым шагом является признание того, что у вас есть парадигматическая проблема. Это громкое слово, чтобы просто сказать, что наша теория полностью неверна. Оказалось, что то, что мы делали инстинктивно, на самом деле было лучшим вариантом. А если вы хотите сделать это по-настоящему изысканно, вы можете попытаться формализовать этот экономический инстинкт, который заключается в том, чтобы не делать ничего, что наносит компании серьезный ущерб и является дорогостоящим. Это просто более формальный способ сказать то же самое.
А затем, возможно, когда у вас появится правильная перспектива, вы сможете внедрить изысканные технологии, и именно этим в основном занимается Lokad. Но суть в том, что всё начинается с правильного определения проблемы с точки зрения, которая имеет смысл. Пока вы застряли в дисфункциональной или глупой точке зрения, виртуозность в технологиях не имеет значения. Вот в чем печаль. Именно поэтому я могу с относительной уверенностью сказать, что эти поставщики ИИ потерпят неудачу. Не имеет значения, талантливы они или нет, не имеет значения, насколько их технологии хороши или плохи, дешевы они или неимоверно дороги. Всё это совершенно несущественно. Это не сработает, потому что предпосылки, на которых они работают, нарушены.
Конор Дохерти: Хорошо, Йоаннес, спасибо. Вопросов больше нет, но я сейчас перейду к вопросам из зала. Большое спасибо. Итак, без определённого порядка, ссылаясь на четыре доказательства, ваши четыре подхода: запросы предложений, временные ряды, страховые запасы и уровни обслуживания. Если эти практики так плохо служат компаниям, то что, по вашему мнению, мешает руководящим командам просто отказаться от них?
Йоаннес Верморель: Изменить что-либо в крупных компаниях сложно, но существуют изменения, которые ещё сложнее. По моему опыту, я видел, что в любой компании, независимо от размера, удаление чего-либо примерно на два порядка, то есть в 100 раз сложнее, чем добавление. Добавить новый процесс — легко, добавить новую должность — легко, добавить новый программный продукт — легко.
Удалить что-либо чрезвычайно сложно, особенно во Франции. Но везде, знаете ли, можно пошутить о том, что во Франции есть Banque de France — учреждение, посвящённое управлению валютой, которой не существовало с 1992 года. У нас есть антиинституция, которая занимается управлением валютой, которой не было 30 лет. И, кстати, в Париже там работает примерно 14 000 человек. Но видите, то, что происходит в государственных масштабах, происходит и в меньшем масштабе в крупных компаниях. Бюрократия имеет тенденцию расти сама по себе — это закон Паркинсона.
Так что вопрос в том, почему руководство не избавляется от того, что не работает? Дело в том, что люди уже делают что-то иное. Официальная корпоративная политика гласит, что все используют страховые запасы. Но на деле существует так много ручных корректировок, осуществляемых через электронные таблицы, что фактически компания использует нечто совершенно иное. Такова действительность. Мы имеем фарс, в котором продолжают изображать, что компания управляется через страховые запасы. Я говорю: знаете, страховой запас по-прежнему считается важной особенностью цепочки поставок компании. Но на самом деле — нет. В конечном итоге руководство задаст вопрос: что я выиграю, официально заявив, что страховых запасов больше нет? В конечном счёте, это ничего не меняет, потому что люди уже их не используют.
Так что это то же самое. Как только появляется отчетность по уровню обслуживания, это уже не имеет особого смысла. Но положительный эффект от удаления этого в краткосрочной перспективе ограничен. В долгосрочной перспективе выгоды огромны, потому что это прокладывает путь для реализации чего-то действительно более логичного. Но в краткосрочной перспективе выгоды ограничены. Опять же, добавление чего-либо гораздо проще.
Если вернуться к ИИ, это также объясняет, почему так охотно принимаются технологии ИИ. Всё происходит по принципу добавления. Мы собираемся добавить еще один класс вещей в организацию, и это очень приятно и легко, в отличие от того, чтобы сказать: «Мы собираемся убрать один класс вещей, который мешает компании быть более эффективной, прибыльной и лучше обслуживать клиентов». Для менеджера гораздо сложнее сказать: «Я просто сокращаю штат, и всё станет работать лучше».
Просто представьте, что произошло с Илоном Маском в Twitter, когда он сказал: «Я уволил 80% сотрудников, и Twitter, теперь X, стал более динамичным, чем когда-либо. У него больше пользователей, чем когда-либо, и в целом добавлено тонны функций, которые предыдущая команда, которая была в пять раз больше, не могла реализовать за прошлые десятилетия». Это отражает силу вычитания, но это чрезвычайно сложно. Это очень, очень сложно. Поэтому я бы сказал, что ничего не меняется, потому что удаление чего-либо чрезвычайно трудно, даже если это критически важно.
Конор Дохерти: Спасибо. Следующий вопрос, он очень хорошо сформулирован. Учитывая ваше исторически резкое неприятие вмешательства человека, считаете ли вы это примером естественной глупости?
Йоаннес Верморель: Ручные корректировки. Знаете, всё зависит. Если мы вмешиваемся в числовую формулу, которая абсолютно бессмысленна, то это хорошо. Я имею в виду, что становится ещё более безумно, если вы оказываетесь в ситуации, когда ваши числовые формулы бессмысленны.
Конор Дохерти: Когда вы говорите “числовые формулы”?
Йоаннес Верморель: Это всё, что вычисляет ваши решения по цепочке поставок, например, сколько нужно заказать, сколько произвести, куда распределить запасы и так далее.
Таким образом, если у вас есть числовые формулы, которые бессмысленны, вполне нормально вручную корректировать эти безумные результаты при принятии решений. А теперь происходит следующее: в организации оказывается много людей, которые проводят целые дни, корректируя решения вручную. На мой взгляд, это необходимо, потому что иначе компания просто натолкнулась бы на стену из-за этих абсолютно бессмысленных решений.
Теперь получается, что бюрократия всегда растёт. Это закон Паркинсона. Бюрократия расширяется. Если у вас есть люди, которые проводят все свои дни, вручную корректируя числовые решения, то появятся люди, которые будут тратить весь день на постепенную корректировку числовых артефактов. Что такое артефакт? Артефакт — это просто нечто, что существует в вашей системе, например, уровень обслуживания, прогноз, ежедневный прогноз, месячный прогноз, бюджет или что угодно.
Что-то, с чем можно поиграть. Это число не оказывает ощутимого влияния на ваш бизнес. Возможно, оно может иметь негативный эффект, если от этого артефакта зависят какие-либо решения. Но очень часто решения не имеют никакого отношения к артефактам. Так что думайте об этом как об игре с KPI и тому подобным. Это будет несущественно, за исключением, возможно, в глазах руководства, потому что у вас есть число, которое выглядит лучше.
Но опять же, бюрократия растёт. Итак, вы начали с ситуации, когда у вас были люди, которые вручную корректировали необходимые решения. А теперь бюрократия расширяется. Появляется много людей, которые корректируют артефакты, числовые артефакты, то есть неважные вещи. Это будут те, кто играет с ABC-классами, с уровнями обслуживания, с коэффициентами для страховых запасов, кто играет с коэффициентами сезонности и т.д. Список бесконечен.
И я говорю, что да, эти числовые корректировки совершенно безумны и бесполезны. И, кстати, подход Lokad, и вот почему люди говорят, что я к этому отношусь с презрением, заключается в том, что если у вас есть разумная числовая формула, то не должно возникать необходимости в ручном вмешательстве. Если вам нужно вручную корректировать результаты, значит, ваша числовая формула безумна. Я говорю о решениях. Так что, если решение безумно, вам нужно исправлять числовую формулу и продолжать исправлять её до тех пор, пока ни одна строка не будет безумной.
Пока ваша числовая формула порождает безумные решения, вы должны продолжать её дорабатывать, без исключений. И именно поэтому, кстати, в Lokad мы в целом крайне пренебрежительно относимся к этим ручным корректировкам. Корректировки решений просто отражают то, что у вас плохая числовая формула. А корректировки числовых артефактов отражают бюрократическую суету, которая изначально абсолютно бессмысленна и которую можно было бы полностью устранить, и это всё равно ничего бы не изменило для компании.
Конор Дохерти: Да, это лечение симптомов, а не причины.
Йоаннес Верморель: По сути, да, именно так. И еще, это делается в интересах бюрократий. Опять же, это закон Паркинсона. Бюрократия имеет тенденцию расти. Так что, если вы умножите количество клерков, занимающихся этими ручными корректировками, в 10 раз, у вас будет в 10 раз больше обновлений этих значений. Это не улучшит вашу цепочку поставок.
Конор Дохерти: Ну, для меня этого достаточно. Спасибо. Следующий вопрос. Он состоит из двух частей. Как системы ERP усугубили проблему и почему они не справляются с вероятностными прогнозами? Ранее вы коснулись вероятностных прогнозов лишь косвенно, но можете подробнее объяснить.
Йоаннес Верморель: Я бы сказал, что ERP-системы усугубили проблему, в первую очередь благодаря маркетологам, сделав ситуацию весьма запутанной. Во-первых, в ERP нет буквы «П» — это управление ресурсами предприятия. Здесь нет планирования. То, что у вас есть, — это транзакционная система. Она предназначена исключительно для обработки транзакционных потоков. Это по сути электронный аналог вашего физического потока. И это хорошо. Это дает вам электронное представление о том, что физически происходит в вашей цепочке поставок. Это хорошо.
Теперь проблема в том, что планирование внезапно становится… Это то, что я называю системой записей. При планировании мы внезапно входим в сферу систем интеллекта и принятия решений. А почему ERP-системы усугубили ситуацию? Потому что поставщики очень быстро поняли к концу 90-х, что системы записей, также известные как CRUD-приложения (Create, Read, Update, Delete), уже стали товаром массового производства. Это произошло еще 20 лет назад.
Сегодня это стало ещё более безумно стандартизированным. И, кстати, если вы хотите добиться реального применения генеративного ИИ в качестве инструмента повышения производительности, написание кода для CRUD-приложений — это превосходно. Так что теперь, с помощью, в основном, ChatGPT, вы можете буквально создавать приложения, похожие на ERP, супер-быстро, потому что эти вещи простые. Это множество шаблонного кода; его предостаточно. Это невероятно повторяемо. Это не высшая инженерия.
Таким образом, в качестве инструментов повышения производительности, ИИ работает невероятно хорошо для управления ресурсами предприятия, знаете ли, для ERM. Теперь, возвращаясь к этой запутанной ситуации. Ожидания от ваших компьютерных систем, предназначенных для работы с системой интеллекта и принятия решений, совершенно отличаются от ожиданий от системы записей. Например, сколько миллисекунд вы можете позволить себе, чтобы система была занята выполнением задачи. Если это система записей, ответ — менее миллисекунды. Всё, что вы делаете, должно завершаться за миллисекунду.
Почему? Потому что ваша система, ваше ERM, скажем так, опирается на централизованную базу данных, и это общий ресурс для всех процессов в вашей компании. Всё сводится к этой единой базе данных. Если вы заморозите эту базу данных на миллисекунду, это означает, что всё остальное будет задержано на миллисекунду. Вы можете сказать: «О, миллисекунда — ничего». Да, но теперь это делают 500 человек. Ладно, не 500, а теперь 500 миллисекунд задержки, что начинает быть заметным.
Теперь, что если несколько из этих запросов заморозят ваше реляционное ядро? Я немного упрощаю. Тогда внезапно у вас получится система, которая работает очень, очень медленно. Внезапно сканирование штрих-кода может занять несколько секунд, прежде чем система зафиксирует, что вы только что сделали. И именно поэтому многие компании жалуются: «О, моя ERP-система такая медленная». Ответ неизменно один: она медленная, потому что вы загрузили в неё то, чего не следовало.
ERP, то есть управление ресурсами предприятия, должно обрабатывать только те задачи, которые можно вычислить за доли миллисекунды, то есть крайне простые. Если вы делаете что-то, что не является чрезвычайно простым, это означает, что вы заморозите систему. Вы будете использовать ресурсы, которые как-то заморозят вашу систему на измеряемый промежуток времени. И если у вас достаточно людей, делающих это, а речь идет о крупных компаниях, где множество процессов и людей, ваша система станет невероятно медленной. И именно поэтому современные ERP все ещё работают так же медленно, как и 20 лет назад. Хотя с точки зрения вычислительной мощности у нас компьютеры как минимум в тысячу раз мощнее. Ответ таков: почему же система всё ещё медленная? Потому что возникает некое равновесие.
Если что-то замедляет ERP настолько, что другим пользователям приходится ждать несколько секунд, прежде чем система отреагирует, то IT department просто отключит систему и предотвратит это. И вы это понимаете. Таким образом, они действуют как полиция потребления ERP. И если кто-то ведет себя чрезмерно, IT в какой-то момент вмешается и просто помешает этому человеку или этому программному обеспечению создавать столько проблем для остальных. Итак, существует некий баланс, который сходится к равновесию: система медленная, но терпимая. Именно поэтому большинство ERP-систем работают очень медленно, но не настолько медленно, чтобы было невыносимо. Потому что если вы перейдете в невыносимую область, IT вмешается и просто отключит систему.
Таким образом, мы возвращаемся к системам интеллекта. Напротив, если задуматься, если вы хотите рассчитать пополнение запасов магазина, вы изучите многолетнюю историю продаж. Вы захотите посмотреть, что происходит с тысячами, возможно десятками тысяч клиентов. То есть, очевидно, это связано с обработкой огромного объема данных. Здесь, безусловно, вы готовы инвестировать немного больше, чем миллисекунду вычислений. Вычисления стоят дешево.
Проблема в том, что если у вас есть ERP, ваши ресурсы делятся между всей компанией. Поэтому то, что вам нужно — это система интеллекта, которая находится за пределами ERP, и эта система может тратить столько времени, сколько необходимо для проведения этих сложных расчетов. Так что, если вернуться к исходному вопросу, системы записей должны справляться с транзакционными операциями, то есть с очень простыми правилами.
Прогнозирование на основе вероятностей является архетипом того, что вы не хотите видеть в своей системе записей. Опять же, как только вы начинаете говорить о вероятностном прогнозировании, речь идет о распределениях вероятностей. Эти объекты, с точки зрения памяти, занимают много места. Понадобится много пространства, чтобы сохранить все эти вероятности. Можно действовать достаточно умно различными способами, но давайте будем предельно очевидны. По сравнению с исходными данными, здесь вы явно добавляете много дополнительных затрат. Вы макрорасширяете свои данные, чтобы оценить все эти вероятности.
Таким образом, по сути, у вас есть нечто, что по замыслу может быть очень мощным, да, но практически по своей природе не предназначено для работы в режиме реального времени. Если вы начинаете заниматься сложными вероятностными оценками, то вы уже не в тех пределах, где возможны вычисления в реальном времени. Вам нужна система, в которой можно выделить гигабайты памяти и потратить, будем безумными, несколько секунд на вычисления. Это приемлемо. Большинство решений в цепочке поставок могут позволить себе задержку в несколько секунд, но не ваш ERP.
Conor Doherty: Ну, повторюсь, в продолжение этой темы о системах интеллекта и ненадобности проводить вычисления в реальном времени в зависимости от того, что именно вы пытаетесь рассчитать. Чтобы дать представление о порядке величины, если взять, скажем, заказ на пополнение запасов, если речь идет о магазине или клиенте, допустим, 300 магазинах и, для округления, 50 000 SKU, то расчет займет порядка 10-12 часов, то есть ночной переработки для принятия этих решений, в отличие от системы записей, которая просто…
Joannes Vermorel: Да, но вы хотите, чтобы ваши расчеты обычно укладывались, как у нас в Lokad, в пределах 60 минут, хотя по совершенно другой причине. Так что, да, в теории может быть расчет, который занимает 10 часов. На практике это очень плохая идея, потому что если ваш расчет прерывается и его приходится начинать заново, это ведет к операционным проблемам.
Таким образом, вы хотите, чтобы ваши вычисления были достаточно короткими, чтобы при необходимости их можно было быстро перезапустить. И вторая причина, которая еще более важна, заключается в том, что изначально этот расчет, скорее всего, не будет правильным. Как я уже говорил, числовой рецепт, пока он дает безумные результаты, требует модификации и обновления до тех пор, пока не получится рецепт, который не генераирует никаких безумных решений, что означает множество итераций.
Если у вас есть система, где расчет завершается менее чем за 60 минут, это означает, что инженер может проводить, возможно, пять-шесть итераций в день. Если же расчет занимает 10 часов, это означает одну итерацию в день. Вам действительно нужна система, в которой инженер может выполнять множество итераций за день. И часто в Lokad, когда мы находимся в режиме проектирования, создавая новый числовой рецепт, мы стараемся укладывать расчет в пару минут, чтобы проводить буквально десятки итераций каждый день.
Conor Doherty: Есть примеры, когда, скажем, при переходе от розничной торговли к таким областям, как аэрокосмическая промышленность, вам нужно, чтобы решения принимались за несколько минут, а не за целый час. Например, 60 минут могут обернуться катастрофическими финансовыми последствиями. Так что, опять же, речь не о том, что самое быстрое возможное время — 60 минут. Все зависит от контекста конкретной отрасли.
Joannes Vermorel: Абсолютно. Но также нужно понимать, что между одной миллисекундой — что должно быть вашим целевым показателем производительности внутри ERP — и одной минутой разница составляет почти пять порядков величины. Это очень разные временные рамки. Это буквально более чем в 10 000 раз, знаете ли. Что означает, что можно действовать совершенно по-разному.
Если вы хотите работать в режиме меньше миллисекунды, это чрезвычайно сложно. Множество вещей просто невозможно. Даже скорость света относительно медленная. Если речь идет о процессах, происходящих менее чем за миллисекунду, это означает, что свет проходит всего около 300 километров. Это может показаться большим расстоянием, но если думать в терминах туда-обратно, то одна миллисекунда — это буквально время прохождения света. Вы не можете рассчитывать на перемещение более чем на 150 километров, если нужно возвращаться обратно.
Таким образом, видите, речь идет о такой скорости, что любая сетевая коммуникация оказывается вне игры. Поэтому, если вы хотите удерживать производительность на уровне ниже миллисекунды, никакая сетевая передача данных не допускается. Даже загрузка данных с вращающегося диска практически исключена. Магнитный диск, вращающийся с определенной скоростью, имеет задержку порядка 10 миллисекунд. Так что даже загрузка с такого диска невозможна.
Со SSD-накопителем, то есть с твердотельным диском, вы можете добиться своих целей, но даже там количество доступов будет ограничено. Возможно, получится выполнить лишь несколько операций. Таким образом, существует огромная разница между тем, что можно сделать за миллисекунду, и тем, что можно сделать за минуту. С точки зрения проектирования компьютеров, это совершенно разные задачи. Если у вас есть целая минута, вы можете выполнить множество сетевых вызовов, провести сложные расчеты, загрузить огромное количество данных. Это значительно упрощает инженерную задачу.
Conor Doherty: Ну, Joannes, спасибо. Вопросов больше нет. Большое спасибо за ваше время. Мы уже около полутора часов, так что дам вам минуту на заключительное слово. Есть ли что-то, что вы хотели бы сказать перед завершением?
Joannes Vermorel: Нет, мне хотелось бы выразить глубокое уважение ко всем, кто занимается процессами искусственного интеллекта в своих цепочках поставок, потому что, увы, эти процессы потерпят неудачу. Мне очень жаль. Мне очень жаль, ребята. Так происходит. Не принимайте это близко к сердцу. Я думаю, можно найти утешение в том, что ваши навыки становятся неважными, понимаете. И, кстати, навыки вашего поставщика также становятся незначительными в этот момент. Так что не имеет значения, хороши вы или плохи. Это позволяет вам не слишком критично оценивать себя при столкновении с неудачей. Не принимайте это слишком лично. Неудача была гарантирована. Она была обречена с самого начала.
Conor Doherty: Да, хорошо. На этой жизнерадостной и праздничной ноте, Joannes, большое спасибо за ваше время, и всем большое спасибо за просмотр. Увидимся в 2025 году.
