00:54 Введение
02:25 О природе прогресса
05:26 До сих пор
06:10 Несколько количественных принципов: наблюдательные принципы
07:27 Решение “иголки в стоге сена” с помощью энтропии
14:58 Популяции цепей поставок распределены по закону Ципфа
22:41 В принятии решений цепей поставок преобладают малые числа
29:44 Паттерны повсюду в цепях поставок
36:11 Несколько количественных принципов: принципы оптимизации
37:20 Для исправления любой проблемы в цепи поставок требуется от 5 до 10 раундов
44:44 Старые цепи поставок однонаправленно квази-оптимальны
49:06 Локальная оптимизация цепей поставок только смещает проблемы
52:56 Лучшие проблемы превосходят лучшие решения
01:00:08 Заключение
01:02:24 Предстоящая лекция и вопросы аудитории
Описание
В то время как цепи поставок не могут быть охарактеризованы определенными количественными законами - в отличие от электромагнетизма - все же можно наблюдать общие количественные принципы. Под ‘общими’ мы подразумеваем применимые к (почти) всем цепям поставок. Раскрытие таких принципов является важным, поскольку они могут быть использованы для облегчения разработки численных рецептов, предназначенных для предсказательной оптимизации цепей поставок, но они также могут быть использованы для усиления этих численных рецептов в целом. Мы рассмотрим два кратких списка принципов: несколько наблюдательных принципов и несколько принципов оптимизации.
Полный транскрипт
Привет всем, добро пожаловать на эту серию лекций о цепях поставок. Я - Жоанн Верморель, и сегодня я представлю вам несколько “Количественных принципов для цепей поставок”. Для тех из вас, кто смотрит лекцию в прямом эфире на YouTube, вы можете задавать свои вопросы в любой момент времени через чат YouTube. Однако, я не буду читать ваши вопросы во время лекции. Я вернусь к чату в конце лекции и постараюсь ответить хотя бы на большинство вопросов.
Количественные принципы представляют особый интерес, потому что в цепях поставок, как мы видели во время первых лекций, они включают в себя владение опциональностью. Большинство этих вариантов имеют количественную природу. Вам нужно решить, сколько купить, сколько произвести, сколько запасов переместить и, возможно, ценовую точку - хотите ли вы повысить или понизить цену. Таким образом, количественный принцип, который может повысить эффективность численных рецептов для цепей поставок, представляет особый интерес.
Однако, если бы я спросил большинство авторитетов или экспертов в области цепей поставок о их основных количественных принципах для цепей поставок, я подозреваю, что часто я получил бы ответ вроде серии техник для лучшего прогнозирования временных рядов или чего-то эквивалентного. Мое личное мнение заключается в том, что, хотя это интересно и актуально, это также упускает суть. Я считаю, что в основе этого недоразумения лежит сама природа прогресса - что такое прогресс и как можно реализовать что-то вроде прогресса в отношении цепей поставок? Позвольте мне начать с иллюстрирующего примера.
Шесть тысяч лет назад было изобретено колесо, а через шесть тысяч лет был изобретен колесный чемодан. Изобретение датируется 1949 годом, как показано на этом патенте. К моменту изобретения колесного чемодана мы уже освоили атомную энергию и даже взорвали первые несколько атомных бомб.
Через 20 лет, в 1969 году, человечество отправило первых людей на Луну. В следующем году колесный чемодан улучшается с немного лучшей ручкой, которая выглядит как поводок, как показано на этом патенте. Она все еще не очень хорошая.
Затем, через 20 лет, к тому времени у нас уже была глобальная система позиционирования GPS, которая обслуживала гражданских лиц уже почти десятилетие, и наконец была изобретена правильная ручка для колесного чемодана.
Здесь есть по крайней мере два интересных урока. Во-первых, не существует такой вещи, как очевидная стрелка времени в отношении прогресса. Прогресс происходит в высокохаотичной, нелинейной манере, и очень сложно оценить прогресс, который должен произойти в одной области, исходя из того, что происходит в других областях. Это один из элементов, которые мы должны иметь в виду сегодня.
Второе, что прогресс не следует путать с утонченностью. У вас может быть нечто значительно превосходящее, но также значительно более простое. Если я возьму пример с чемоданом, то после того, как вы увидите один, дизайн будет выглядеть совершенно очевидным и самоочевидным. Но была ли это легкая проблема для решения? Я бы сказал, что абсолютно нет. Простое доказательство того, что управление цепями поставок было сложной проблемой для решения, заключается в том, что передовая промышленная цивилизация потребовала немного больше четырех десятилетий, чтобы решить эту проблему. Прогресс обманчив в том смысле, что он не подчиняется правилу утонченности. Очень сложно определить, каким был мир до того, как произошел прогресс, потому что он буквально меняет ваше представление о мире по мере его возникновения.
Теперь вернемся к нашему обсуждению цепей поставок. Это шестая и последняя лекция в этом прологе. Существует всеобъемлющий план, который вы можете проверить онлайн на веб-сайте Lokad по всей серии лекций по цепям поставок. Две недели назад я представил тенденции 20-го века в области цепей поставок, принимая чисто качественную перспективу на проблему. Сегодня я принимаю противоположный подход, принимая довольно количественную перспективу на этот набор проблем в качестве контрпункта.
Сегодня мы рассмотрим набор принципов. Под принципом я понимаю то, что может быть использовано для улучшения проектирования численных рецептов в общем для всех цепей поставок. У нас есть амбиции по обобщению здесь, и именно здесь довольно сложно найти вещи, которые являются ключевыми для всех цепей поставок и всех численных методов для их улучшения. Мы рассмотрим два кратких списка принципов: наблюдательные принципы и принципы оптимизации.
Наблюдательные принципы применяются к способу получения количественных знаний и информации о цепях поставок. Принципы оптимизации относятся к тому, как вы действуете, когда вы получили качественные знания о своей цепи поставок, а именно, как использовать эти принципы для улучшения процессов оптимизации.
Давайте начнем с наблюдения за цепью поставок. Мне непонятно, когда люди говорят о цепях поставок, как если бы они могли наблюдать их непосредственно своими глазами. Для меня это очень искаженное представление о реальности цепей поставок. Цепи поставок нельзя наблюдать непосредственно человеком, по крайней мере, не с количественной точки зрения. Это связано с тем, что цепи поставок, по своей природе, являются географически распределенными и включают в себя потенциально тысячи SKU и десятки тысяч единиц. С помощью своих глаз вы можете наблюдать только цепь поставок такой, какой она есть сегодня, а не такой, какой она была в прошлом. Вы не можете запомнить больше, чем несколько чисел или крошечную долю чисел, связанных с вашей цепью поставок.
Когда вы хотите наблюдать за цепью поставок, вы будете делать такие наблюдения косвенно с помощью прикладного программного обеспечения. Это очень специфический способ взглянуть на цепи поставок. Все наблюдения, которые можно сделать количественно о цепях поставок, происходят через эту конкретную среду: прикладное программное обеспечение.
Давайте характеризуем типичное прикладное программное обеспечение. Оно будет содержать базу данных, так как подавляющее большинство такого программного обеспечения разработано таким образом. Вероятно, в программе будет около 500 таблиц и 10 000 полей (поле - это в основном столбец в таблице). В качестве точки входа у нас есть система, которая потенциально содержит огромное количество информации. Однако в большинстве случаев только крошечная доля этой сложности программного обеспечения фактически является актуальной для интересующей нас цепи поставок.
Производители программного обеспечения разрабатывают прикладное программное обеспечение, учитывая очень разнообразные ситуации во всем мире. При рассмотрении одного конкретного клиента вероятность того, что используется только крошечная доля возможностей программного обеспечения, довольно велика. Это означает, что, хотя в теории может быть 10 000 полей для исследования, на практике компании используют только небольшую долю этих полей.
Проблема заключается в том, как отсортировать актуальную информацию от несуществующих или несущественных данных. Мы можем наблюдать цепи поставок только через прикладное программное обеспечение, и может быть задействовано более одной программы. В некоторых случаях поле никогда не использовалось, и данные постоянны, содержащие только нули или пустые значения. В этой ситуации легко исключить поле, потому что оно не содержит никакой информации. Однако на практике количество полей, которые можно исключить с помощью этого метода, может составлять всего около 10%, так как многие функции в программном обеспечении использовались на протяжении многих лет, даже если только случайно.
Чтобы определить поля, которые никогда не использовались, мы можем обратиться к инструменту, называемому информационной энтропией. Для тех, кто не знаком с теорией информации Шеннона, этот термин может показаться запугивающим, но на самом деле он гораздо проще, чем кажется. Информационная энтропия заключается в количественной оценке информации в сигнале, где сигнал определяется как последовательность символов. Например, если у нас есть поле, которое содержит только два типа значений, true или false, и столбец случайным образом колеблется между этими значениями, то в столбце содержится много данных. В отличие от этого, если только одна строка из миллиона содержит значение true, а все остальные строки содержат значение false, то поле в базе данных практически не содержит никакой информации.
Информационная энтропия очень интересна, потому что она позволяет количественно оценить количество информации в каждом поле вашей базы данных в битах. Проведя анализ, вы можете ранжировать эти поля от самых богатых до самых бедных в терминах информации и удалять те, которые почти не содержат какую-либо значимую информацию для оптимизации цепочки поставок. Информационная энтропия может показаться сложной на первый взгляд, но ее несложно понять.
Например, представим себе специализированный язык программирования, в котором мы реализовали информационную энтропию в качестве агрегатора. Взяв таблицу, такую как данные из плоского файла с названием data.csv с тремя столбцами, мы можем построить сводку о том, сколько энтропии присутствует в каждом столбце. Этот процесс позволяет легко определить, какие поля содержат наименьшее количество информации и удалять их. Используя энтропию в качестве руководства, вы можете быстро начать проект, вместо того чтобы тратить на это годы.
Перейдя к следующему этапу, мы делаем наши первые наблюдения о цепях поставок и рассматриваем, что ожидать. В естественных науках стандартным ожиданием являются нормальные распределения, также известные как колоколообразные кривые или гауссовы. Например, рост 20-летнего мужчины или его вес будут иметь нормальное распределение. В мире живых существ многие измерения следуют этому закону. Однако, когда речь идет о цепях поставок, это не так. Практически ничто интересное в цепях поставок не имеет нормального распределения.
Вместо этого практически все распределения, которые интересны в цепях поставок, имеют распределение Зипфа. Распределение Зипфа иллюстрируется данной формулой. Чтобы понять эту концепцию, рассмотрим популяцию продуктов, где измерением интереса является объем продаж каждого продукта. Вы бы ранжировали продукты от наибольшего до наименьшего объема продаж за определенный период времени, например, за год. Вопрос заключается в том, существует ли модель, которая предсказывает форму кривой и, зная ранг, предоставит ожидаемый объем продаж. Вот в чем и состоит распределение Зипфа. Здесь f представляет собой форму закона Зипфа-Мандельброта, а k относится к k-му наибольшему элементу. Есть два параметра, q и s, которые в основном изучаются, так же как у нормального распределения есть mu (среднее) и sigma (дисперсия). Эти параметры могут быть использованы для подгонки распределения к интересующей популяции. Закон Зипфа-Мандельброта охватывает эти параметры.
Важно отметить, что практически каждая популяция, интересующаяся цепями поставок, следует распределению Зипфа. Это верно для продуктов, клиентов, поставщиков, промоакций, и даже единиц отправки. Распределение Зипфа является потомком принципа Парето, но оно более управляемое и, по моему мнению, более интересное, так как предоставляет явную модель того, чего ожидать для любой интересующей популяции в цепи поставок. Если вы сталкиваетесь с популяцией, которая не имеет распределения Зипфа, то скорее всего проблема заключается в данных, а не в истинном отклонении от принципа.
Для использования концепции распределения Ципфа в реальном мире вы можете использовать Envision. Если мы посмотрим на этот фрагмент кода, вы увидите, что для применения этой модели к реальным данным требуется всего несколько строк кода. Здесь я предполагаю, что есть интересующая нас популяция в плоском файле с названием “data.csv” с одним столбцом, представляющим количество. Обычно у вас есть идентификатор продукта и количество. На строке 4 я вычисляю ранги с использованием агрегатора рангов и сортирую их по количеству. Затем, с 6 по 11 строку, я вхожу в блок дифференцируемого программирования, явно указывая Autodev, где я объявляю три скалярных параметра: c, q и s, как в формуле слева на экране. Затем я вычисляю прогнозы модели Ципфа и использую среднеквадратичную ошибку между наблюдаемым количеством и прогнозом модели. Вы можете буквально регрессировать распределение Ципфа всего несколькими строками кода. Даже если это звучит сложно, это довольно просто с правильными инструментами.
Это приводит меня к еще одному наблюдательному аспекту цепей поставок: числа, которые вы ожидаете на любом уровне цепи поставок, обычно небольшие, обычно меньше 20. У вас не только будет немного наблюдений, но и числа, которые вы наблюдаете, также будут небольшими. Конечно, этот принцип зависит от используемых единиц, но когда я говорю “числа”, я имею в виду те, которые имеют канонический смысл с точки зрения цепи поставок, то есть те, которые вы пытаетесь наблюдать и оптимизировать.
Причина, по которой у нас есть только небольшие числа, заключается в экономии масштаба. Давайте возьмем футболки в магазине в качестве примера. В магазине может быть тысячи футболок в наличии, что кажется большим числом, но на самом деле у них есть сотни разных типов футболок с различиями в размере, цвете и дизайне. Когда вы начинаете рассматривать футболки с точки зрения цепи поставок, которая является SKU, в магазине не будет тысяч единиц футболок для определенного SKU; вместо этого у них будет всего несколько.
Если у вас большее количество футболок, у вас не будет тысяч футболок, разбросанных повсюду, так как это было бы кошмаром с точки зрения обработки и перемещения. Вместо этого вы упакуете эти футболки в удобные коробки, что и происходит на практике. Если у вас есть центр распределения, который занимается большим количеством футболок, потому что вы отправляете их в магазины, то скорее всего эти футболки на самом деле находятся в коробках. Возможно, у вас даже есть коробка, содержащая полный ассортимент футболок разных размеров и цветов, что упрощает их обработку по цепи. Если у вас есть много коробок, у вас не будет тысяч таких коробок. Вместо этого, если у вас есть десятки коробок, вы будете аккуратно организовывать их на поддонах. Один поддон может вместить несколько десятков коробок. Если у вас есть много поддонов, вы не будете организовывать их как отдельные поддоны; скорее всего, вы будете организовывать их как контейнеры. И если у вас есть много контейнеров, вы будете использовать грузовое судно или что-то подобное.
Мой посыл заключается в том, что когда речь идет о числах в цепи поставок, действительно значимое число всегда является небольшим числом. Эту ситуацию нельзя избежать, просто перейдя на более высокий уровень агрегации, потому что, переходя на более высокий уровень агрегации, начинает действовать некая экономия масштаба, и вы хотите ввести механизм пакетирования для снижения операционных затрат. Это происходит несколько раз, поэтому независимо от того, на каком уровне масштаба вы смотрите, будь то конечный продукт, продаваемый поштучно в магазине, или массовый производимый предмет, это всегда игра небольших чисел.
Даже если у вас есть фабрика, производящая миллионы футболок, вероятно, у вас есть гигантские партии, и числа, которые вас интересуют, это не количество футболок, а количество партий, которое будет гораздо меньше.
К чему я прихожу с этим принципом? Во-первых, вам нужно посмотреть на то, как выглядят большинство методов научных вычислений или статистики. Оказывается, что в большинстве других областей, не связанных с цепочкой поставок, преобладает противоположное: большое количество наблюдений и большое количество, где важна точность. Однако в цепочке поставок числа малы и дискретны.
Мое предложение состоит в том, что нам нужны инструменты, основанные на этом принципе, которые глубоко учитывают и принимают во внимание тот факт, что у нас будет мало чисел вместо больших чисел. Если у вас есть инструменты, которые были разработаны только с учетом закона больших чисел, либо из-за большого количества наблюдений, либо из-за самих больших чисел, то у вас полное несоответствие, когда дело доходит до цепочки поставок.
Кстати, это имеет глубокие последствия для программного обеспечения. Если у вас мало чисел, есть много способов сделать так, чтобы программные слои воспользовались этим наблюдением. Например, если вы посмотрите на набор данных строк транзакций для гипермаркета, вы заметите, что, основываясь на моем опыте и наблюдениях, 80% строк имеют количество, которое продается конечному клиенту в гипермаркете, равное единице. Итак, вам нужно 64 бита информации, чтобы представить эту информацию? Нет, это полное пустая трата места и времени обработки. Принятие этой концепции может привести к операционному преимуществу в один или два порядка. Это не просто пустые мечты; есть реальные операционные выгоды. Вы можете подумать, что современные компьютеры очень мощные, и это так, но если у вас есть больше вычислительной мощности в вашем распоряжении, вы можете использовать более продвинутые алгоритмы, которые делают вещи, которые еще лучше для вашей цепочки поставок. Бессмысленно тратить эту вычислительную мощность только потому, что у вас есть парадигма, которая ожидает больших чисел, когда преобладают малые числа.
Это приводит меня к моему последнему наблюдательному принципу на сегодня: в цепочке поставок повсюду присутствуют шаблоны. Чтобы понять это, давайте рассмотрим классическую проблему цепочки поставок, где обычно считается, что шаблоны отсутствуют: оптимизация маршрута. Классическая проблема оптимизации маршрута включает список доставок, которые должны быть сделаны. Вы можете разместить доставки на карте и хотите найти маршрут, который минимизирует время транспортировки. Вы хотите установить маршрут, который проходит через каждую точку доставки, минимизируя общее время транспортировки. С первого взгляда эта проблема кажется полностью геометрической проблемой без вовлечения шаблонов в ее решение.
Однако я предлагаю, что такая перспектива совершенно неверна. Подходя к проблеме с этого ракурса, вы смотрите на математическую проблему, а не на проблему цепочки поставок. Цепочки поставок - это повторяющиеся игры, в которых проблемы проявляются снова и снова. Если вы занимаетесь организацией доставок, вероятно, вы делаете доставки каждый день. Это не просто один маршрут; это буквально один маршрут в день, по крайней мере.
Более того, если вы занимаетесь доставками, у вас, вероятно, есть целый парк транспортных средств и водителей. Проблема заключается не только в оптимизации одного маршрута; это оптимизация всего парка, и эта игра повторяется каждый день. Именно здесь появляются все шаблоны.
Во-первых, точки не распределены случайным образом на карте. У вас есть горячие точки или географические области с высокой плотностью доставок. У вас могут быть адреса, которые получают доставки почти каждый день, например, штаб-квартира крупной компании в большом городе. Если вы крупная интернет-компания, вы, вероятно, доставляете посылки на этот адрес каждый рабочий день. Эти горячие точки не являются неизменными; у них есть своя сезонность. Некоторые районы могут быть очень тихими летом или зимой. Есть шаблоны, и если вы хотите быть очень хорошими в игре оптимизации маршрута, вам нужно учитывать не только то, где эти горячие точки будут происходить, но и то, как они будут перемещаться в течение года. Кроме того, у вас есть проблема с учетом трафика. Вы не должны думать только о геометрическом расстоянии, так как трафик зависит от времени. Если водитель начинает в определенный момент времени в течение дня, по мере продвижения по своему маршруту трафик будет меняться. Чтобы хорошо играть в эту игру, вам нужно учитывать шаблоны движения трафика, которые меняются и могут быть надежно предсказаны заранее. Например, в Париже в 9:00 утра и в 6:00 вечера весь город полностью забит, и вам не нужно быть экспертом в прогнозировании, чтобы знать это.
Также есть ситуации, которые происходят на месте, например, аварии, которые нарушают обычные паттерны движения. Если мы посмотрим на доставки с математической точки зрения, то предполагается, что все точки доставки одинаковы, но это не так. У вас могут быть VIP-клиенты или конкретные адреса, куда вам нужно доставить половину вашей партии. Эти ключевые этапы в вашем маршруте должны быть учтены для эффективной оптимизации маршрута.
Вам также необходимо учитывать контекст, и часто у нас есть неполные данные о мире. Например, если мост закрыт, и программное обеспечение об этом не знает, проблема не в том, что мы не знали о закрытии моста в первый раз, а в том, что программное обеспечение никогда не учитывает эту проблему и всегда предлагает маршрут, который должен быть оптимальным, но на самом деле является бессмысленным. Люди начинают бороться с системой, что не является хорошим практическим решением оптимизации маршрута с точки зрения цепи поставок.
Суть в том, что, когда мы рассматриваем ситуации в цепи поставок, везде есть множество паттернов. Мы должны быть осторожными, чтобы не отвлекаться элегантными математическими структурами и помнить, что эти рассуждения также применимы к прогнозированию временных рядов. Я взял проблему оптимизации маршрута в качестве примера, потому что она была более явной в этом случае.
В заключение, нам необходимо наблюдать за цепью поставок со всех наблюдаемых измерений, а не только тех, которые очевидны или где решение представляется элегантным способом.
Это приводит меня к второй серии принципов, связанных с тем, как мы должны смотреть на нашу цепь поставок. До сих пор мы видели четыре принципа, связанных с тем, как мы должны смотреть на нашу цепь поставок: косвенное наблюдение, корпоративное программное обеспечение, разборка беспорядка для определения того, что является значимым, а что нет, и энтропия. Мы заметили, что распределения часто следуют закону Ципфа, и даже с небольшими числами мы все равно можем увидеть возникающие паттерны. Вопрос теперь в том, как нам действовать? С математической точки зрения, когда мы хотим принять лучшее решение, мы выполняем оптимизацию какого-то вида, что является количественной перспективой.
Первое, что следует отметить, это то, что как только у нас есть оптимизационная логика в производстве для цепей поставок, возникают проблемы, такие как ошибки. Корпоративное программное обеспечение является очень сложным существом и часто полно ошибок. Когда вы разрабатываете свою собственную оптимизационную логику для вашей цепи поставок, возникнет множество проблем. Однако, если кусок логики достаточно хорош, чтобы быть внедренным в производство, то любые проблемы, с которыми мы сталкиваемся сейчас, вероятно, являются крайними случаями. Если бы это не был крайний случай, и программное обеспечение или логика работали неправильно каждый раз, оно никогда не попало бы в производство.
Идея этого принципа заключается в том, что для исправления любой проблемы требуется от пяти до десяти раундов. Когда я говорю о пяти-десяти раундах, я имею в виду, что вы столкнетесь с проблемой, рассмотрите ее, поймите корень проблемы, а затем попытайтесь применить исправление. Но большую часть времени исправление не решит проблему. Вы обнаружите, что внутри проблемы скрывалась другая проблема, или проблему, которую вы думали, что исправили, на самом деле не была настоящей причиной, или ситуация выявила более широкий класс проблем. Вы могли исправить небольшой экземпляр более широкого класса проблем, но будут продолжаться другие проблемы, которые являются вариантами той, которую вы думали, что решили.
Цепи поставок являются сложными, постоянно меняющимися существами, которые работают в реальном мире, что затрудняет создание дизайна, который правильно работает во всех ситуациях. В большинстве случаев вы прикладываете максимум усилий, чтобы исправить проблему, а затем вам приходится проверять вашу исправленную логику на опыте реального мира, чтобы увидеть, работает ли она или нет. Вам придется проводить итерации, чтобы исправить проблему. С принципом, что требуется от пяти до десяти итераций для исправления проблемы, это имеет глубокие последствия для скорости адаптации и частоты обновления или пересчета логики оптимизации цепи поставок. Например, если у вас есть логика, которая производит квартальный прогноз на следующие два года, и вы запускаете эту логику только один раз в квартал, потребуется от одного до двух лет, чтобы исправить любые проблемы, с которыми вы столкнетесь с этой логикой прогнозирования, что является невероятно долгим временем.
Даже если у вас есть логика, которая выполняется каждый месяц, например, в случае процесса планирования продаж и операций (S&OP), может потребоваться до года, чтобы исправить проблему. Поэтому важно увеличить частоту запуска логики оптимизации цепи поставок. Например, в Lokad каждый кусочек логики запускается ежедневно, даже для прогнозов на пять лет вперед. Эти прогнозы обновляются ежедневно, даже если они не меняются сильно от одного дня к другому. Цель не в достижении статистической точности, а в том, чтобы убедиться, что логика запускается достаточно часто, чтобы исправить любые проблемы или ошибки в разумные сроки.
Это наблюдение не является уникальным для управления цепями поставок. Умные инженерные команды в компаниях, таких как Netflix, популяризовали идею хаос-инжиниринга. Они поняли, что крайние случаи были редкими, и единственный способ исправить эти проблемы - повторять опыт чаще. В результате они создали программное обеспечение под названием Chaos Monkey, которое добавляет хаос в их программную инфраструктуру, создавая сетевые сбои и случайные сбои. Цель Chaos Monkey - ускорить проявление крайних случаев, позволяя инженерной команде быстрее их исправить.
Хотя может показаться парадоксальным вводить дополнительный уровень хаоса в свои операции, такой подход доказал свою эффективность для Netflix, которая известна своей отличной надежностью. Они понимают, что когда они сталкиваются с проблемой, связанной с программным обеспечением, требуется много итераций для ее решения, и единственный способ добраться до корня проблемы - это быстро итерироваться. Chaos Monkey - всего лишь один из способов увеличить скорость итераций.
С точки зрения цепи поставок Chaos Monkey может быть не применим, но концепция увеличения частоты запуска логики оптимизации цепи поставок все равно является очень актуальной. Какая бы логика у вас ни была для оптимизации вашей цепи поставок, она должна работать с высокой скоростью и частотой; в противном случае вы никогда не исправите ни одну из проблем, с которыми сталкиваетесь.
Теперь старые цепи поставок являются квази-оптимальными, и когда я говорю “старые”, я имею в виду цепи поставок, которые работают двадцать лет или дольше. Другими словами, ваши предшественники в цепи поставок не были все неспособными. Когда вы рассматриваете инициативы по оптимизации цепи поставок, слишком часто есть большие амбиции, такие как сокращение уровня запасов вдвое, увеличение уровня обслуживания с 95% до 99%, устранение дефицита товара или сокращение сроков поставки вдвое. Это большие однонаправленные движения, где вы фокусируетесь на одном KPI и пытаетесь значительно его улучшить. Однако я заметил, что эти инициативы почти всегда терпят неудачу по очень простой причине: когда вы берете цепь поставок, которая работает десятилетиями, обычно есть некоторая скрытая мудрость в том, как все было сделано.
Например, если уровень обслуживания составляет 95%, вероятно, что если вы попытаетесь повысить его до 99%, вы значительно увеличите уровень запасов и создадите огромное количество мертвого запаса в процессе. Аналогично, если у вас есть определенное количество запасов и вы запускаете масштабную инициативу по сокращению его вдвое, вы, вероятно, создадите значительные проблемы с качеством обслуживания, которые невозможно поддерживать.
Что я заметил, так это то, что многие практики в области цепей поставок, которые не понимают принципа того, что старые цепи поставок однонаправленно квази-оптимальны, имеют осцилляции вокруг локального оптимума. Имейте в виду, что я не говорю, что старые цепи поставок являются оптимальными, но они являются однонаправленно квази-оптимальными. Если вы посмотрите на аналогию с Великим Каньоном, река вытесняет оптимальный путь из-за однонаправленной силы гравитации. Если бы вы применили силу, в десять раз сильнее, река все равно претерпела бы множество изгибов.
Суть в том, что при старомодных цепях поставок, если вы хотите добиться значительных улучшений, вам нужно одновременно настраивать множество переменных. Фокусировка только на одной переменной не приведет к желаемым результатам, особенно если ваша компания работает десятилетиями по привычной схеме. Ваши предшественники, вероятно, делали несколько вещей правильно в свое время, поэтому вероятность натолкнуться на сильно дисфункциональную цепь поставок, на которую никто никогда не обращал внимания, минимальна. Цепи поставок - это сложные проблемы, и хотя возможно создать полностью дисфункциональные ситуации в масштабе, это будет происходить крайне редко, в лучшем случае.
Еще один аспект, который следует учесть, заключается в том, что локальная оптимизация только смещает проблемы, а не решает их. Чтобы понять это, нужно понять, что цепи поставок - это системы, и когда мы говорим о оценке эффективности цепей поставки, нас интересует только общая эффективность системы. Локальная эффективность имеет значение, но это только часть картины.
Обычный способ мышления заключается в том, что вы можете применить стратегию “разделяй и властвуй” для решения проблем в общем случае, а не только проблем цепей поставок. Например, в розничной сети с множеством магазинов вы можете хотеть оптимизировать уровни запасов в каждом магазине. Однако проблема заключается в том, что если у вас есть сеть магазинов и дистрибуционных центров, обслуживающих множество магазинов, то микрооптимизация одного магазина и достижение отличного качества обслуживания для этого магазина будет происходить за счет всех остальных магазинов.
Правильная перспектива заключается в том, чтобы думать о том, что когда у вас есть одна единица товара в дистрибуционном центре, вопрос, который вы должны себе задать, звучит так: где эта единица наиболее нужна? Какое движение будет наиболее прибыльным для меня? Проблема оптимизации отгрузки товаров или проблема распределения запасов имеет смысл только на уровне системы, а не на уровне магазина. Если вы оптимизируете то, что происходит в одном магазине, вы, скорее всего, создадите проблемы в другом магазине.
Когда я говорю “локально”, этот принцип не должен пониматься только с географической точки зрения; это также может быть чисто логическим вопросом внутри цепи поставок. Например, если вы являетесь интернет-компанией с множеством категорий товаров, вы можете хотеть выделить разные бюджеты для различных категорий. Это еще один тип стратегии “разделяй и властвуй”. Однако, если вы разбиваете свой бюджет и выделяете фиксированную сумму на каждую категорию в начале года, что произойдет, если спрос на товары в одной категории удвоится, а спрос на товары в другой категории уменьшится вдвое? В этом случае у вас возникает проблема неправильного распределения средств между этими двумя категориями. Проблема здесь заключается в том, что вы не можете применять какую-либо логику “разделяй и властвуй”. Если вы используете методы локальной оптимизации, вы можете создать проблемы, создавая ваше предполагаемое оптимальное решение.
Это приводит меня к последнему принципу, который, вероятно, является самым сложным среди всех принципов, которые я представил сегодня: лучшие проблемы превосходят лучшие решения. Это может быть чрезвычайно запутанным, особенно в некоторых академических кругах. Типичный способ представления вещей через классическое образование заключается в том, что вам представляется хорошо определенная проблема, и затем вы начинаете искать решения для этих проблем. В математической задаче, например, один студент может предложить более краткое, более элегантное решение, и это считается лучшим решением.
Однако, на самом деле, в управлении цепями поставок все происходит не так. Чтобы проиллюстрировать это, вернемся на 60 лет назад и посмотрим на проблему приготовления пищи, очень трудоемкую деятельность. Люди в прошлом представляли себе, что роботы могут быть использованы в будущем для выполнения задач по приготовлению пищи, тем самым значительно повышая производительность для ответственного за приготовление человека. Такое мышление было распространено в 1950-х и 1960-х годах.
Вернемся к сегодняшнему дню, и очевидно, что все развивается не так. Чтобы минимизировать усилия по приготовлению пищи, люди теперь покупают готовые блюда. Это еще один пример смещения проблемы. Поставка супермаркетам готовых блюд является более сложной с точки зрения управления цепями поставок, чем поставка сырья, из-за увеличенного количества ссылок и более коротких сроков годности. Проблема была решена благодаря более эффективному решению для управления цепями поставок, а не путем предоставления лучшего решения для приготовления пищи. Проблема приготовления пищи была полностью устранена и переопределена как предоставление приемлемого блюда с минимальными усилиями.
В терминах цепей поставок, академическая перспектива часто сосредотачивается на поиске лучших решений для существующих проблем. Один хороший пример - это соревнования Kaggle, где у вас есть набор данных, проблема и потенциально сотни или тысячи команд, соревнующихся, чтобы получить лучший прогноз по этим данным. У вас есть четко определенная проблема и тысячи решений, конкурирующих друг с другом. Проблема с таким подходом заключается в том, что он создает впечатление, что если вы хотите достичь улучшения в своей цепи поставок, вам нужно лучшее решение.
Суть принципа заключается в том, что лучшее решение может помочь незначительно, но только незначительно. Обычно то, что действительно помогает, - это переопределение проблемы, и это удивительно сложно. Это также относится к количественным проблемам. Вам нужно пересмотреть свою фактическую стратегию управления цепями поставок и ключевую проблему, которую вы должны оптимизировать.
Во многих кругах люди думают о проблемах так, будто они являются статичными и неизменными, ища лучшие решения. Я не отрицаю, что лучший алгоритм прогнозирования временных рядов может быть полезен, но прогнозирование временных рядов относится к области статистического прогнозирования, а не к владению управлением цепями поставок. Если мы вернемся к моему первоначальному примеру с чемоданом для путешествий, ключевым улучшением для чемодана на колесиках была не колеса, а ручка. Это было нечто, что на первый взгляд не имело ничего общего с колесами, и поэтому потребовалось 40 лет, чтобы придумать решение - вам нужно думать нестандартно, чтобы появилась лучшая проблема.
Этот количественный принцип заключается в том, чтобы вызывать сомнения в проблемах, с которыми вы сталкиваетесь. Возможно, вы недостаточно серьезно задумываетесь о проблеме, и есть тенденция влюбляться в решение, в то время как вы должны сосредоточиться на проблеме и на том, что вы не понимаете в ней. Как только у вас есть четко определенная проблема, иметь хорошее решение обычно является простым вопросом выполнения, что не так сложно.
В заключение, управление цепями поставок как область исследования имеет множество впечатляющих и авторитетных точек зрения. Они могут быть сложными, но вопрос, который я хотел бы задать этой аудитории, заключается в том, может ли все это быть серьезно ошибочным? Мы действительно уверены, что такие элементы, как прогнозирование временных рядов и операционное исследование, являются правильными точками зрения на проблему? Независимо от уровня сложности и десятилетий инженерных исследований и усилий, вложенных в эти направления, мы действительно идем в правильном направлении?
Сегодня я представляю серию принципов, которые, по моему мнению, имеют первостепенное значение для управления цепями поставок. Однако, они могут показаться странными для большинства из вас. У нас есть два мира - проверенный и странный - и вопрос в том, что произойдет через несколько десятилетий.
Прогресс обычно развивается хаотично и нелинейно. Идея этих принципов заключается в том, чтобы позволить вам принять мир, который является крайне хаотичным, где есть место для неожиданностей. Эти принципы могут помочь вам разрабатывать более быстрые, надежные и эффективные решения, которые принесут улучшение вашим цепям поставок с количественной точки зрения.
Теперь перейдем к некоторым вопросам.
Вопрос: Как распределение Ципфа сравнивается с законом Парето?
Закон Парето - это правило, что 80% результатов достигается 20% усилий, но с количественной точки зрения распределение Ципфа является явной предиктивной моделью. Оно имеет предиктивные возможности, которые можно проверить на наборах данных очень простым способом.
Вопрос: Не лучше ли рассматривать распределение Ципфа-Мандельброта как логарифмическую кривую, чтобы видеть колебания в цепях поставок, как это делают эпидемиологи при отчете о случаях и смертях?
Абсолютно. Философский вопрос заключается в том, живете ли вы в стране Среднестатистических или Экстремальных. Цепи поставок и большинство человеческих дел существуют в мире крайностей. Логарифмические кривые действительно полезны, если вы хотите визуализировать амплитуду акций. Например, если вы хотите увидеть амплитуды всех прошлых акций для крупных розничных сетей за последние 10 лет, использование обычной шкалы может сделать все остальное невидимым, просто потому что самая большая акция была настолько больше остальных. Поэтому использование логарифмической шкалы может помочь вам более ясно видеть вариации. С распределением Ципфа-Мандельброта я предоставляю вам модель, которую вы можете буквально реализовать всего несколькими строками кода, что больше, чем просто логарифмическое представление данных. Однако я согласен, что основная интуиция та же самая. Для философской перспективы на высоком уровне рекомендую ознакомиться с работой Нассима Талеба о Медиокристане против Экстремистана в его книге “Антихрупкость”.
Вопрос: При обсуждении оптимизации локальных цепей поставок вы учитываете базовые данные, которые поддерживают сотрудничество в сети цепей поставок и SNLP?
Моя проблема с локальной оптимизацией заключается в том, что крупные компании, управляющие крупными цепями поставок, обычно имеют матричные организации. Эта организационная структура, с ее подходом “разделяй и властвуй”, приводит к локальной оптимизации по своей природе. Например, рассмотрим две разные команды - одна отвечает за прогнозирование спроса, а другая за принятие решений о закупках. Эти две проблемы - прогнозирование спроса и оптимизация закупок - полностью переплетены. Вы не можете выполнять локальную оптимизацию, фокусируясь только на проценте ошибки в прогнозировании спроса, а затем отдельно оптимизировать закупки на основе эффективности обработки. Есть системные эффекты, и вы должны учитывать все их вместе.
Самая большая проблема для большинства крупных, устоявшихся компаний, управляющих значительными цепями поставок сегодня, заключается в том, что, стремясь к количественной оптимизации, вы должны думать о системе в целом и о компании в целом. Это противоречит десятилетиям оседания матричной организации внутри компании, где люди стали сосредоточены только на своих четко определенных границах, забывая о большой картине.
Еще одним примером этой проблемы является запас товара в магазине. Запас служит двум целям: с одной стороны, он удовлетворяет потребности клиентов, а с другой - выступает в качестве товара. Чтобы иметь правильное количество запасов, вам нужно решить проблему качества обслуживания и проблему привлекательности магазина. Привлекательность магазина заключается в том, чтобы сделать его привлекательным и интересным для клиентов, что является скорее маркетинговой проблемой. В компании у вас есть отдел маркетинга и отдел цепей поставок, и они не естественным образом сотрудничают при оптимизации цепей поставок. Моя точка зрения заключается в том, что, если вы не объедините все эти аспекты вместе, оптимизация не сработает.
Что касается вашей озабоченности SNLP, проблема заключается в том, что люди собираются только для проведения встреч, что не очень эффективно. Мы опубликовали эпизод Lokad TV о SNLP несколько месяцев назад, так что вы можете обратиться к нему, если хотите провести конкретное обсуждение SNLP.
Вопрос: Как следует распределить время и энергию между стратегией цепи поставок и количественным выполнением?
Это отличный вопрос. Ответ, как я упоминал в своей второй лекции, заключается в том, что вам нужна полная роботизация рутинных задач. Это позволяет вам уделять все свое время и энергию непрерывному стратегическому улучшению ваших числовых рецептов. Если вы тратите более 10% своего времени на рутинные аспекты выполнения цепи поставок, у вас проблема с вашей методологией. Эксперты по цепям поставок слишком ценны, чтобы тратить свое время и энергию на рутинные проблемы выполнения, которые должны быть автоматизированы с самого начала.
Вам нужно следовать методологии, которая позволяет вам уделять почти всю свою энергию стратегическому мышлению, которое затем немедленно реализуется в виде превосходных числовых рецептов, управляющих повседневным выполнением цепи поставок. Это связано с моей третьей лекцией о поставке, ориентированной на продукт, где я имею в виду поставку программного обеспечения, ориентированную на продукт.
Вопрос: Возможно ли гипотезировать некий анализ потолка, лучшее улучшение возможно для проблем цепи поставок, учитывая их системную формулировку?
Я бы сказал нет, абсолютно нет. Думать, что существует некий оптимум или потолок, равносильно сказать, что есть предел человеческому изобретательству. Хотя у меня нет никаких доказательств того, что нет предела человеческому изобретательству, это одно из моих основных убеждений. Цепи поставок - это сложные проблемы. Вы можете преобразовать проблему и даже превратить то, что кажется большой проблемой, в большое решение и потенциал для роста компании. Например, посмотрите на Amazon. Джефф Безос в начале 2000-х понял, что для успешного ритейлера ему понадобится масштабная, надежная программная инфраструктура. Но эта масштабная промышленная инфраструктура, которая ему понадобилась для работы электронной коммерции Amazon, была невероятно дорогой, стоила компании миллиарды. Поэтому команды в Amazon решили превратить эту инфраструктуру облачных вычислений, которая была огромной инвестицией, в коммерческий продукт. В настоящее время эта масштабная вычислительная инфраструктура является одним из основных источников прибыли для Amazon.
Когда вы начинаете думать о сложных проблемах, вы всегда можете переопределить проблему более превосходным способом. Вот почему я считаю, что ошибочно считать, что существует некое оптимальное решение. Когда вы думаете в терминах анализа потолка, вы смотрите на фиксированную проблему, и с точки зрения фиксированной проблемы у вас может быть решение, которое, вероятно, квази-оптимально. Например, если посмотреть на колеса на современных чемоданах, они, вероятно, квази-оптимальны. Но есть ли что-то, что совершенно очевидно, чего мы не замечаем? Может быть, есть способ сделать колеса намного лучше, изобретение, которое еще не было сделано. Как только мы его увидим, оно покажется совершенно самоочевидным.
Вот почему нам нужно думать, что для этих проблем нет никакого потолка, потому что проблемы произвольны. Вы можете переопределить проблему и решить, что игра будет идти по совершенно другим правилам. Это озадачивает, потому что люди любят думать, что у них есть четко определенная проблема и они могут найти решения. Современная западная система образования акцентирует внимание на поиске решений, где мы даем вам проблему и оцениваем качество вашего решения. Однако гораздо более интересным вопросом является качество самой проблемы.
Вопрос: Лучшие решения решают проблемы, но иногда поиск лучшего решения может стоить и время, и деньги. Есть ли обходные пути для этого?
Конечно. Опять же, если у вас есть решение, которое теоретически правильно, но занимает вечность для реализации, это не хорошее решение. Такое мышление склонно быть распространенным в некоторых академических кругах, где они сосредотачиваются на поиске идеального решения согласно узколобым математическим критериям, которые не имеют ничего общего с реальным миром. Вот о чем я говорил, когда упоминал правильную оптимизационную проблему.
Каждый квартал ко мне приходит профессор и просит меня просмотреть его онлайн-алгоритм для решения проблемы оптимизации маршрута. Большинство статей, которые я сейчас рецензирую, сосредоточены на онлайн-вариантах. Мой ответ всегда один и тот же: вы не решаете правильную проблему. Мне не интересно ваше решение, потому что вы даже не правильно мыслите о самой проблеме.
Прогресс не следует путать с утонченностью. Это ошибочное восприятие, что прогресс идет от чего-то простого к чему-то сложному. На самом деле, прогресс часто достигается путем начала с чего-то невероятно запутанного и, благодаря превосходному мышлению и технологиям, достижения простоты. Например, если вы посмотрите на мою последнюю лекцию о тенденциях в снабжении на 21 век, вы увидите Машину Марли, которая подавала воду во дворец Версаля. Это была безумно сложная система, в то время как современные электрические насосы намного проще и эффективнее.
Прогресс не всегда заключается в дополнительной утонченности. Иногда это требуется, но это не является существенным элементом прогресса.
Вопрос: Большие розничные сети увеличивают свой уровень запасов, но должны немедленно выполнять заказы. Иногда они решают сделать промо-акцию самостоятельно, не инициированную поставщиком. Какой подход следует выбрать для прогнозирования и подготовки соответствующих мер на уровне поставщика?
Сначала мы должны посмотреть на проблему с другой стороны. Вы предполагаете прогнозную перспективу, где ваш клиент, крупный розничный продавец, делает большую акцию, которая появляется из ниоткуда. Во-первых, это такая плохая вещь? Если они продвигают ваши продукты, не предупредив вас, это просто факт жизни. Если вы посмотрите на свою историю, они обычно делают это регулярно, и даже есть шаблоны.
Если я вернусь к своим принципам, шаблоны повсюду. Во-первых, вам нужно принять перспективу, что вы не можете прогнозировать будущее; вместо этого вам нужны вероятностные прогнозы. Даже если вы не можете идеально предвидеть колебания, они могут быть не совсем неожиданными. Возможно, вам нужно изменить правила игры, а не позволять поставщику полностью удивлять вас. Возможно, вам нужно договориться о обязательствах, которые связывают розничного продавца, розничную сеть и поставщика. Если розничная сеть начинает активно продвигать товары, не предупредив поставщика, поставщик не может реалистично нести ответственность за поддержание качества обслуживания.
Возможно, решение заключается в более сотрудничестве. Возможно, поставщик должен иметь более точную оценку рисков. Если материалы, продаваемые поставщиком, не подвержены порче, может быть более выгодно иметь пару месяцев запасов. Люди часто думают о том, чтобы иметь нулевую задержку, нулевой запас и нулевое все, но это действительно то, что ваши клиенты ожидают от вас? Возможно, то, что ожидают ваши клиенты, это добавленная стоимость в виде обильного запаса. Опять же, ответ зависит от различных факторов.
Вам нужно рассмотреть проблему с разных сторон, и здесь нет простого решения. Вам нужно очень хорошо подумать о проблеме и рассмотреть все доступные варианты. Возможно, проблема не в большем запасе, а в большей производственной мощности. Если возникает всплеск спроса, и это не слишком дорого иметь массовый рост, и поставщики поставщиков могут быстро предоставить материалы, может быть, все, что вам нужно, это более гибкая производственная мощность. Это позволило бы вам перенаправить вашу производственную мощность на то, что сейчас растет.
Кстати, это существует в некоторых отраслях. Например, упаковочная промышленность имеет огромные мощности. Большинство машин в упаковочной промышленности - это промышленные принтеры, которые относительно недороги. Люди в упаковочном бизнесе обычно имеют много принтеров, которые большую часть времени не используются. Однако, когда происходит большое событие или крупный бренд хочет сделать массовый прорыв, у них есть возможность печатать тонны новых упаковок, которые соответствуют новому маркетинговому прорыву бренда.
Так что все действительно зависит от различных факторов, и я извиняюсь за то, что у меня нет однозначного ответа. Но что я могу однозначно сказать, так это то, что вам нужно очень хорошо подумать о проблеме, с которой вы сталкиваетесь.
Это завершает сегодняшнюю лекцию, шестую и последнюю из пролога. Через две недели, в тот же день и в то же время, я буду рассказывать о личностях в снабжении. Увидимся в следующий раз.
