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 Предстоящая лекция и вопросы аудитории
Описание
Цепи поставок не могут быть охарактеризованы определёнными количественными законами - в отличие от электромагнетизма - но общие количественные принципы всё же наблюдаются. Под «общими» мы подразумеваем принципы, применимые к (почти) всем цепям поставок. Выявление таких принципов представляет первостепенный интерес, поскольку они могут использоваться для облегчения создания numerical recipes предназначенных для predictive optimization цепей поставок, а также для повышения их общей эффективности. Мы рассмотрим два кратких списка принципов: несколько наблюдательных принципов и несколько принципов оптимизации.
Полная стенограмма
Всем привет, добро пожаловать в эту серию лекций о цепях поставок. Я Жоанн Верморель, и сегодня я представлю несколько «Количественных принципов для цепей поставок». Для тех, кто смотрит лекцию в прямом эфире на YouTube, вы можете задавать свои вопросы в любой момент через чат YouTube. Однако во время лекции я не буду читать ваши вопросы. В конце лекции я вернусь к чату и постараюсь ответить хотя бы на большинство вопросов.
Количественные принципы представляют большой интерес, потому что в цепях поставок, как мы видели на первых лекциях, они связаны с управлением опциональностью. Большинство этих опций имеют количественную природу. Вам нужно решить, сколько купить, сколько произвести, сколько переместить запасов, а возможно, и определить ценовую точку – поднять её или опустить. Таким образом, количественный принцип, способный улучшить численные рецепты для цепей поставок, представляет большой интерес.
Однако, если бы я спросил большинство авторитетов или экспертов в области цепей поставок, какие их основные количественные принципы для цепей поставок, я подозреваю, что часто получил бы ответ в виде ряда техник для улучшения time series или нечто подобного. Моя личная реакция такова: хотя это интересно и актуально, это упускает суть. Я считаю, что в основе недопонимания лежит сама природа прогресса – что такое прогресс и как можно реализовать его в контексте цепей поставок? Позвольте привести иллюстративный пример.
Шесть тысяч лет назад было изобретено колесо, а спустя шесть тысяч лет был изобретён чемодан на колёсах. Изобретение датируется 1949 годом, как показано на этом патенте. К тому времени, когда был изобретён чемодан на колёсах, мы уже освоили атомную энергию и даже взорвали первые атомные бомбы.
Далее, спустя 20 лет, в 1969 году человечество отправило первых людей на Луну. На следующий год чемодан на колёсах был усовершенствован – с чуть лучшей ручкой, напоминающей поводок, как показано на этом патенте. Но он всё ещё оставался не очень удобным.
Затем, спустя 20 лет, когда у нас уже был глобальный GPS, служащий гражданским целям почти десятилетие, наконец была изобретена подходящая ручка для чемодана на колёсах.
Здесь можно выделить как минимум два интересных урока. Во-первых, не существует очевидной стрелы времени, если говорить о прогрессе. Прогресс происходит крайне хаотично и нелинейно, и очень трудно оценить, какой прогресс должен происходить в одной области, основываясь на том, что происходит в других. Это один из аспектов, который нам нужно помнить сегодня.
Во-вторых, прогресс не следует путать с утонченностью. Можно иметь нечто значительно превосходное, но при этом гораздо более простое. Если взять пример чемодана, то, увидев его, конструкция становится совершенно очевидной и само собой разумеющейся. Но было ли это легкой задачей? Я бы сказал, что абсолютно нет. Простой доказательством того, что управление цепями поставок являлось сложной задачей, является тот факт, что передовой индустриальной цивилизации понадобилось чуть более четырех десятилетий, чтобы решить эту проблему. Прогресс обманчив тем, что он не подчиняется правилу утонченности. Очень трудно определить, каким был мир до наступления прогресса, так как прогресс буквально меняет ваше восприятие мира по мере его возникновения.
Теперь вернёмся к обсуждению цепей поставок. Это шестая и последняя лекция в этом прологе. На сайте Lokad доступен исчерпывающий план всей серии лекций о цепях поставок, который вы можете изучить онлайн. Две недели назад я представил тенденции 20 века для цепей поставок, используя чисто качественную перспективу проблемы. Сегодня же я выбрал противоположный подход, используя довольно количественную перспективу для данного набора проблем в качестве противопоставления.
Сегодня мы рассмотрим ряд принципов. Под принципом я подразумеваю нечто, что может быть использовано для улучшения разработки численных рецептов в целом для всех цепей поставок. Здесь заложена амбиция обобщения, и именно поэтому довольно сложно найти что-то, имеющее первостепенное значение для всех цепей поставок и всех численных методов их улучшения. Мы рассмотрим два кратких списка принципов: наблюдательные принципы и принципы оптимизации.
Наблюдательные принципы применимы в том, как можно количественно получать знания и информацию о цепях поставок. Принципы оптимизации касаются того, как действовать после получения качественной информации о вашей цепи поставок, а именно, как использовать эти принципы для улучшения ваших процессов оптимизации.
Давайте начнём с наблюдения за цепью поставок. Меня удивляет, когда люди говорят о цепях поставок так, как будто их можно наблюдать напрямую своими глазами. Для меня это весьма искажённое восприятие реальности цепей поставок. Цепи поставок невозможно наблюдать напрямую человеческим глазом, по крайней мере, с количественной точки зрения. Это связано с тем, что цепи поставок по замыслу распределены географически и могут включать потенциально тысячи SKU и десятки тысяч единиц. С вашими человеческими глазами вы сможете наблюдать цепь поставок только в её сегодняшнем виде, но не такой, какой она была в прошлом. Вы не в состоянии запомнить больше, чем несколько чисел или крошечную долю числовых значений, связанных с вашей цепью поставок.
Всякий раз, когда вы хотите наблюдать цепь поставок, вы будете делать это косвенно с помощью корпоративного программного обеспечения. Это весьма специфический способ наблюдения за цепями поставок. Все количественные наблюдения, которые можно провести о цепях поставок, осуществляются через это конкретное средство: корпоративное программное обеспечение.
Давайте охарактеризуем типичный фрагмент корпоративного программного обеспечения. Он будет содержать базу данных, так как подавляющее большинство такого ПО сконструировано именно так. Программное обеспечение, скорее всего, включает около 500 таблиц и 10,000 полей (поле — по сути столбец в таблице). Как исходная точка, у нас есть система, которая потенциально содержит огромный объём информации. Однако в большинстве случаев только крошечная часть этой сложности ПО действительно актуальна для рассматриваемой цепи поставок.
Разработчики программного обеспечения проектируют корпоративное ПО с учётом очень разнообразных ситуаций. Рассматривая конкретного клиента, скорее всего, используется лишь крошечная часть возможностей этого ПО. Это означает, что, хотя теоретически может быть 10,000 полей для исследования, на практике компании используют лишь малую их часть.
Задача состоит в том, чтобы отделить релевантную информацию от несуществующих или нерелевантных данных. Мы можем наблюдать цепи поставок только через корпоративное программное обеспечение, и может быть задействовано более одного программного продукта. В некоторых случаях поле никогда не использовалось, и данные в нём постоянны, содержащие только нули или пустые значения. В такой ситуации легко исключить это поле, так как оно не несёт никакой информации. Однако на практике количество полей, которые можно исключить этим методом, может составлять лишь около 10%, поскольку многие функции в программе использовались на протяжении многих лет, даже если это было случайно.
Чтобы определить поля, которые никогда не использовались по назначению, мы можем обратиться к инструменту, называемому информационной энтропией. Для тех, кто не знаком с теорией информации Шеннона, этот термин может показаться пугающим, но на самом деле всё гораздо проще. Информационная энтропия заключается в количественной оценке объёма информации в сигнале, при этом сигнал определяется как последовательность символов. Например, если у нас есть поле, содержащее только два типа значений — истина или ложь, и столбец случайным образом колеблется между этими значениями, столбец содержит массу данных. В то же время, если только одна строка из миллиона имеет значение истина, а все остальные — ложь, то поле в базе данных практически не содержит никакой информации.
Информационная энтропия очень интересна, поскольку позволяет количественно оценить, в битах, объём информации, содержащейся в каждом поле вашей базы данных. Проведя анализ, вы можете ранжировать эти поля от наиболее информативных до наименее и исключить те, которые почти не содержат релевантной информации для оптимизации цепей поставок. На первый взгляд информационная энтропия может показаться сложной, но понять её не составляет труда.
Например, используя предметно-ориентированный язык программирования, мы реализовали информационную энтропию в качестве агрегатора. Взяв, скажем, таблицу с данными из плоского файла data.csv с тремя столбцами, мы можем построить сводку объёма энтропии в каждом столбце. Этот процесс позволяет легко определить, какие поля содержат наименьшее количество информации, и исключить их. Используя энтропию в качестве ориентира, вы можете быстро начать проект, а не затрачивать на это годы.
Переходя к следующему этапу, мы делаем первые наблюдения за цепями поставок и размышляем о том, чего ожидать. В естественных науках по умолчанию предполагается нормальное распределение, также известное как колоколообразная кривая или гауссово распределение. Например, рост 20-летнего мужчины или его вес имеют нормальное распределение. В мире живых существ многие измерения подчиняются этой закономерности. Однако, когда речь идёт о цепях поставок, это не так. Практически ничего интересного в цепях поставок не подчиняется нормальному распределению.
Вместо этого практически все распределения, представляющие интерес для цепей поставок, подчиняются закону Ципфа. Распределение Ципфа иллюстрируется в приведённой формуле. Чтобы понять эту концепцию, представьте популяцию продуктов, где измеряемой величиной является объём продаж для каждого продукта. Вы ранжируете продукты от наибольшего до наименьшего объёма продаж за определённый период, например, за год. Вопрос заключается в том, существует ли модель, предсказывающая форму кривой, и, зная ранг, способная дать ожидаемый объём продаж. Именно об этом и говорит распределение Ципфа. Здесь f представляет форму закона Ципфа-Мандельброта, а k обозначает k-ый по величине элемент. Существует два параметра, q и s, которые, по сути, обучаются, аналогично тому, как у нормального распределения есть μ (среднее) и σ (дисперсия). Эти параметры можно использовать для подгонки распределения под заинтересованную популяцию. Закон Ципфа-Мандельброта включает эти параметры.
Важно отметить, что практически каждая популяция, представляющая интерес для цепей поставок, подчиняется распределению Ципфа. Это относится к продуктам, клиентам, поставщикам, акциям и даже к единицам отгрузки. Распределение Ципфа по сути является потомком принципа Парето, но оно более пригодно для анализа и, на мой взгляд, более интересно, так как предоставляет явную модель того, чего ожидать от любой популяции в цепях поставок. Если вы столкнётесь с популяцией, не подчиняющейся закону Ципфа, скорее всего, проблема кроется в данных, а не в настоящем отклонении от принципа.
Для применения концепции распределения Ципфа в реальном мире вы можете использовать Envision. Если мы взглянем на этот фрагмент кода, увидим, что для применения этой модели к реальному набору данных требуется всего несколько строк кода. Здесь я предполагаю, что существует интересующая популяция в виде плоского файла с названием “data.csv”, где одна колонка представляет количество. Обычно у вас был бы идентификатор продукта и само количество. На 4-й строке я вычисляю ранги с помощью агрегатора рангов и сортировки по количеству. Затем, между 6-й и 11-й строками, я вхожу в блок дифференцируемого программирования, явно обозначенный с помощью Autodev, где я объявляю три скалярных параметра: c, q и s, точно как в формуле слева на экране. После этого я рассчитываю предсказания модели Ципфа и использую среднеквадратичную ошибку между наблюдаемым количеством и предсказанием модели. Вы буквально можете провести регрессию распределения Ципфа, написав всего несколько строк кода. Даже если это звучит сложно, на самом деле всё довольно просто с правильными инструментами.
Это подводит меня к еще одному аспекту наблюдения за цепочками поставок: числа, которые вы ожидаете на любом уровне цепочки, малы, обычно меньше 20. У вас будет не только немного наблюдений, но и сами числа будут небольшими. Конечно, этот принцип зависит от используемых единиц измерения, но под “числами” я имею в виду те, которые имеют каноническое значение с точки зрения цепочки поставок и которые вы пытаетесь наблюдать и оптимизировать.
Причина, по которой у нас есть только маленькие числа, связана с экономией от масштаба. Возьмем, к примеру, футболки в магазине. Магазин может иметь в наличии тысячи футболок, что кажется большим числом, но на самом деле у него сотни различных видов футболок с вариациями размеров, цветов и дизайна. Когда вы начинаете рассматривать футболки с точки зрения релевантности для цепочки поставок, то есть на уровне SKU, у магазина не будет тысячи единиц для данного артикула; вместо этого их будет всего горстка.
Если у вас большее количество футболок, вы не будете хранить тысячи футболок вразброс, так как это станет кошмаром с точки зрения их обработки и перемещения. Вместо этого вы упакуете футболки в удобные коробки, что и происходит на практике. Если у вас есть распределительный центр, работающий с большим количеством футболок, поскольку вы отправляете их в магазины, скорее всего, эти футболки фактически будут упакованы в коробки. Возможно, у вас даже будет коробка, содержащая полный ассортимент футболок с различными размерами и цветами, что облегчает обработку по цепочке. Если у вас много коробок, вы не получите тысячи таких коробок. Вместо этого, если у вас десятки коробок, вы аккуратно организуете их на поддонах. Один поддон может вмещать несколько десятков коробок. Если у вас много поддонов, они, скорее всего, будут организованы не по отдельности, а в виде контейнеров. А если у вас много контейнеров, вы будете использовать грузовое судно или что-то подобное.
Моя мысль заключается в том, что когда речь заходит о числах в цепочке поставок, действительно важным всегда является малое число. Этой ситуации нельзя избежать простым переходом на более высокий уровень агрегации: по мере перехода на более высокий уровень, начинает действовать эффект масштаба, и вы вынуждены вводить механизм группировки, чтобы снизить операционные расходы. Это происходит многократно, поэтому, независимо от масштаба — будь то конечный продукт, продаваемый поштучно в магазине, или массово производимый товар — всё сводится к игре с малыми числами.
Даже если у вас есть фабрика, производящая миллионы футболок, скорее всего, вы работаете с гигантскими партиями, и число, представляющее интерес, — не количество футболок, а количество партий, которое будет значительно меньше.
К чему я клоню эту мысль? Во-первых, посмотрите, как выглядят большинство методов в научных вычислениях или статистике. Оказывается, что в большинстве других областей, не связанных с цепочками поставок, преобладают большие объемы наблюдений и большие числа, где точность имеет решающее значение. Однако в цепочке поставок числа малы и дискретны.
Мое предложение заключается в том, что нам нужны инструменты, основанные на этом принципе, которые глубоко учитывают тот факт, что у нас будут маленькие числа, а не большие. Если ваши инструменты разработаны исключительно с учетом закона больших чисел — будь то из-за огромного количества наблюдений или самих больших чисел — то они абсолютно не подходят для цепочки поставок.
Кстати, это имеет серьезные программные последствия. Если у вас маленькие числа, существует множество способов заставить программные слои воспользоваться этим наблюдением. Например, если вы посмотрите на данные транзакционных строк гипермаркета, вы заметите, что, согласно моему опыту и наблюдениям, 80% строк содержат количество, равное единице, которое продается конечному клиенту гипермаркета. Так что, нужны ли 64 бита информации для представления этого? Нет, это полная трата места и вычислительного времени. Принятие этой концепции может привести к операционному выигрышу в один или два порядка. Это не просто мечтательные предположения; существуют реальные операционные выгоды. Вы можете думать, что современные компьютеры очень мощные, и это так, но если у вас в распоряжении больше вычислительной мощности, вы сможете использовать более продвинутые алгоритмы, которые работают ещё лучше для вашей цепочки поставок. Бессмысленно тратить вычислительную мощность только потому, что ваша парадигма ожидает больших чисел, в то время как на самом деле преобладают маленькие.
Это подводит меня к последнему наблюдательному принципу на сегодня: закономерности есть повсюду в цепочке поставок. Чтобы это понять, давайте рассмотрим классическую задачу цепочки поставок, в которой обычно считается, что закономерностей нет: оптимизацию маршрута. Классическая задача оптимизации маршрута включает список доставок, которые необходимо выполнить. Вы можете разместить доставки на карте и хотите найти маршрут, минимизирующий время транспортировки. Вам нужно установить маршрут, который проходит через каждую точку доставки, минимизируя общее время транспортировки. На первый взгляд эта задача выглядит как чисто геометрическая проблема, в решении которой не участвуют никакие закономерности.
Однако я утверждаю, что эта точка зрения совершенно неверна. Подходя к задаче с этой стороны, вы рассматриваете математическую проблему, а не проблему цепочки поставок. Цепочки поставок — это повторяющиеся процессы, в которых проблемы проявляются многократно. Если вы занимаетесь организацией доставок, скорее всего, вы осуществляете их каждый день. Это не просто один маршрут; это буквально один маршрут в день, по крайней мере.
Более того, если вы занимаетесь доставками, у вас, вероятно, есть целый автопарк транспортных средств и водителей. Проблема заключается не только в оптимизации одного маршрута; она заключается в оптимизации всего автопарка, и этот процесс повторяется каждый день. Именно здесь проявляются все закономерности.
Во-первых, точки на карте распределены не случайным образом. Существуют горячие точки, или географические районы с высокой плотностью доставок. Могут быть адреса, на которые поступают доставки почти каждый день, например, штаб-квартира крупной компании в большом городе. Если вы крупная компания электронной коммерции, вы, вероятно, доставляете посылки по этому адресу каждый рабочий день. Эти горячие точки не являются неизменными; у них есть своя сезонность. Некоторые районы могут быть очень тихими летом или зимой. Существуют закономерности, и если вы хотите отлично справляться с оптимизацией маршрутов, вам нужно учитывать не только, где будут возникать эти горячие точки, но и как они будут смещаться в течение года. Кроме того, необходимо учитывать дорожное движение. Не стоит думать только о геометрическом расстоянии, ведь движение зависит от времени. Если водитель отправляется в определённое время, по мере движения по маршруту дорожная ситуация изменяется. Чтобы хорошо справляться с этой задачей, нужно учитывать закономерности трафика, которые меняются и могут быть надежно предсказаны заранее. Например, в Париже в 9:00 и 18:00 весь город оказывается полностью заторен, и вам не нужно быть экспертом в прогнозировании, чтобы это знать.
Также происходят непредвиденные события, такие как аварии, которые нарушают обычные закономерности движения. Если рассматривать доставки с математической точки зрения, предполагается, что все точки доставки одинаковы, но это не так. У вас могут быть VIP-клиенты или конкретные адреса, куда нужно доставить половину отгрузки. Эти ключевые точки вашего маршрута необходимо учитывать для эффективной оптимизации.
Также нужно учитывать контекст, и часто данные о мире бывают несовершенными. Например, если мост закрыт, а программное обеспечение об этом не знает, проблема заключается не в том, что изначально не узнали об этом, а в том, что система так и не научилась на этой ошибке и постоянно предлагает маршрут, который, как считается, оптимален, но оказывается бессмысленным. В результате люди начинают бороться с системой, что не является хорошим практическим решением задачи оптимизации маршрутов с точки зрения цепочки поставок.
Суть в том, что когда мы рассматриваем ситуации в цепочке поставок, закономерностей встречается повсюду. Мы должны быть осторожны, чтобы не увлечься элегантными математическими структурами, и помнить, что эти соображения применимы также к прогнозированию временных рядов. Я взял задачу оптимизации маршрутов в качестве примера, потому что в этом случае она наиболее очевидна.
В заключение, нам необходимо наблюдать за цепочкой поставок со всех доступных измерений, а не только за теми, которые кажутся очевидными или где решение представляется элегантным.
Это приводит меня ко второй серии принципов, касающихся того, как мы должны смотреть на нашу цепочку поставок. До сих пор мы рассматривали четыре принципа: косвенное наблюдение, корпоративное программное обеспечение, разбор хаоса для определения того, что действительно важно, и энтропию. Мы наблюдали, что распределения часто подчиняются закону Ципфа, и даже при малых числах можно увидеть возникновение закономерностей. Вопрос в следующем: как действовать? С математической точки зрения, когда мы хотим определить наилучший курс действий, мы проводим какую-либо оптимизацию, что является количественной перспективой.
Первое, что следует заметить, — как только в производстве запускается логика оптимизации для цепочек поставок, возникают проблемы, такие как баги. Корпоративное программное обеспечение — очень сложное существо, и оно часто полно ошибок. Когда вы разрабатываете собственную логику оптимизации для своей цепочки поставок, возникнет множество проблем. Однако если логика достаточно хороша, чтобы быть внедренной в производство, то любые возникающие проблемы, вероятно, являются краевыми случаями. Если бы это не были краевые случаи, и программное обеспечение или логика давали сбой каждый раз, они никогда бы не попали в производство.
Суть этого принципа в том, что решение любой проблемы требует от пяти до десяти итераций. Когда я говорю «пять-десять итераций», я имею в виду, что вы столкнётесь с проблемой, изучите её, поймёте её коренную причину, а затем попробуете применить исправление. Но чаще всего это исправление не решает проблему. Вы обнаружите, что внутри проблемы скрывалась другая, или что проблема, которую вы думали исправить, не была истинной причиной, или что ситуация выявила более широкую группу проблем. Вы могли исправить небольшой пример более масштабной проблемы, но будут возникать и другие вопросы — варианты той проблемы, которую вы думали решить.
Цепочки поставок — это сложные, постоянно меняющиеся системы, функционирующие в реальном мире, что затрудняет разработку решения, которое было бы корректным для всех ситуаций. В большинстве случаев вы прилагаете максимум усилий для исправления проблемы, а затем вынуждены тестировать свою обновлённую логику в реальных условиях, чтобы понять, работает она или нет. Вам придётся проводить итерации, чтобы устранить проблему. Если исправление проблемы требует от пяти до десяти итераций, это существенно влияет на скорость адаптаций и частоту обновления или пересчёта логики оптимизации цепочек поставок. Например, если у вас есть логика, которая создаёт квартальный прогноз на следующие два года и вы запускаете её только раз в квартал, на исправление любых проблем, с которыми вы столкнётесь, уйдет от одного до двух лет, что является невероятно долгим сроком.
Даже если у вас есть логика, запускаемая каждый месяц, как в случае с процессом S&OP (Планирование продаж и операций), на исправление проблемы всё равно может уйти до года. Вот почему так важно увеличить частоту запуска логики оптимизации цепочки поставок. Например, в Lokad каждая часть логики запускается ежедневно, даже для прогнозов на пять лет вперёд. Эти прогнозы обновляются ежедневно, даже если они меняются незначительно с дня на день. Цель заключается не в достижении статистической точности, а в том, чтобы логика запускалась достаточно часто для исправления любых проблем или ошибок в разумные сроки.
Это наблюдение не уникально для управления цепочками поставок. Умные инженерные команды таких компаний, как Netflix, популяризировали идею хаос-инжиниринга. Они осознали, что краевые случаи редки, и единственный способ исправить эти проблемы — повторять эксперимент чаще. В результате они создали программное обеспечение под названием Chaos Monkey, которое вносит хаос в их программную инфраструктуру, создавая сетевые сбои и случайные аварийные остановки. Цель Chaos Monkey — ускорить выявление краевых случаев, позволяя инженерной команде быстрее их исправлять.
Хотя может показаться противоречивым добавлять дополнительный уровень хаоса в ваши операции, этот подход оказался эффективным для Netflix, известного своей отличной надёжностью. Они понимают, что при возникновении проблемы, связанной с программным обеспечением, для её решения требуется много итераций, и единственный способ добраться до сути проблемы — это быстро проводить итерации. Chaos Monkey — это всего лишь один из способов ускорить этот процесс.
С точки зрения цепочки поставок, “Обезьяна Хаоса” может не применяться напрямую, однако концепция повышения частоты запуска вашей логики оптимизации цепочки поставок остаётся весьма актуальной. Какая бы логика для оптимизации цепочки поставок ни использовалась, она должна работать с высокой скоростью и частотой; иначе вы никогда не решите ни одну из возникающих проблем.
Теперь устоявшиеся цепочки поставок являются квази-оптимальными, и когда я говорю “устоявшиеся”, я имею в виду цепочки, функционирующие в течение двух десятилетий или более. Другими словами, предыдущие операторы вашей цепочки поставок не были все некомпетентны. Когда вы рассматриваете инициативы по оптимизации цепочки поставок, слишком часто встречаются грандиозные амбиции, такие как сокращение уровней запасов наполовину, повышение уровня сервиса с 95% до 99%, устранение дефицита товаров или сокращение сроков поставки вдвое. Это масштабные, односторонние шаги, когда вы сосредотачиваетесь на одном ключевом показателе и пытаетесь его кардинально улучшить. Однако я заметил, что эти инициативы почти всегда терпят неудачу по весьма простой причине: когда берёшь цепочку поставок, функционирующую десятилетиями, обычно в способах её организации содержится скрытая мудрость.
Например, если уровень сервиса составляет 95%, то при попытке повысить его до 99% весьма вероятно, что вы значительно увеличите запасы, что приведёт к образованию огромного количества мертвых запасов. Аналогично, если у вас имеется определённое количество запасов и вы запускаете масштабную инициативу по их сокращению вполовину, вы, вероятно, создадите значительные проблемы с качеством обслуживания, которые окажутся неустойчивыми.
Что я наблюдал, так это то, что многие специалисты по цепочкам поставок, не понимающие принципа, что устоявшиеся цепочки являются односторонне квази-оптимальными, склонны к колебаниям вокруг локального оптимума. Заметьте, я не утверждаю, что устоявшиеся цепочки поставок являются оптимальными, но они односторонне квази-оптимальны. Если вспомнить аналогию с Гранд-Каньоном, то река вырезает оптимальный путь благодаря односторонней силе гравитации. Если бы вы применили силу, в десять раз большую, река всё равно приняла бы множество извилистых форм.
Суть в том, что в случае устоявшихся цепочек поставок, если вы хотите добиться значительных улучшений, необходимо одновременно корректировать множество переменных. Сосредоточение на одной переменной не принесёт желаемых результатов, особенно если ваша компания десятилетиями функционировала в рамках статус-кво. Ваши предшественники, вероятно, делали некоторые вещи правильно в своё время, поэтому вероятность столкнуться с чрезвычайно неработающей цепочкой поставок, на которую никто не обращал внимания, минимальна. Цепочки поставок представляют собой крайне сложные проблемы, и хотя можно создать масштабно полностью дисфункциональные ситуации, это происходит крайне редко.
Ещё один аспект, который следует учитывать, заключается в том, что локальная оптимизация лишь перемещает проблемы, а не решает их. Чтобы это понять, нужно осознать, что цепочки поставок являются системами, и при рассмотрении эффективности цепей поставок важна всего системная производительность. Локальная эффективность имеет значение, но она лишь часть общей картины.
Распространённое мнение состоит в том, что можно применить стратегию “разделяй и властвуй” для решения проблем в целом, а не только задач цепочки поставок. Например, в розничной сети с многочисленными магазинами вы можете захотеть оптимизировать уровни запасов в каждом магазине. Однако проблема заключается в том, что если у вас есть сеть магазинов и распределительных центров, каждый из которых обслуживает множество магазинов, то чрезвычайно легко микроскопически оптимизировать один магазин, добившись отличного уровня сервиса в нём за счёт всех остальных.
Правильное понимание таково: когда в распределительном центре доступна единица товара, следует задать себе вопрос: где эта единица нужна сильнее всего? Какое действие будет для меня наиболее выгодным? Оптимизация распределения запасов, или задача распределения запасов, имеет смысл только на уровне всей системы, а не на уровне отдельного магазина. Если оптимизировать процессы в одном магазине, это, скорее всего, создаст проблемы в другом.
Когда я говорю “локальный”, этот принцип не следует понимать исключительно в географическом смысле; он может быть также чисто логическим внутри цепочки поставок. Например, если вы — компания электронной коммерции с множеством категорий товаров, вы можете захотеть распределить различные бюджеты между этими категориями. Это ещё один вариант стратегии “разделяй и властвуй”. Однако, если вы распределяете бюджет и назначаете фиксированную сумму для каждой категории в начале года, что произойдёт, если спрос на товары в одной категории удвоится, а в другой сократится вдвое? В таком случае возникает проблема неправильного распределения средств между этими двумя категориями. Сложность здесь в том, что нельзя применить никакую логику “разделяй и властвуй”. Если использовать техники локальной оптимизации, вы можете непреднамеренно создать проблемы в процессе формирования якобы оптимизированного решения.
Это подводит меня к последнему принципу, который, вероятно, является самым замысловатым из представленных сегодня: лучшие проблемы важнее лучших решений. Это может вызывать крайнее замешательство, особенно в определённых академических кругах. Классическое образование преподносит ситуацию так: вам сначала представляют чётко определённую проблему, а затем вы начинаете искать для неё решения. Например, в математической задаче один студент может предложить более краткое, более элегантное решение, и это считается наилучшим.
Однако в реальности в управлении цепочками поставок всё происходит иначе. Чтобы проиллюстрировать это, вернёмся на 60 лет назад и рассмотрим проблему приготовления пищи — крайне трудоёмкую задачу. В прошлом люди представляли, что в будущем роботы смогут выполнять кулинарные задачи, значительно повышая производительность человека, ответственного за приготовление пищи. Такой образ мышления был распространён в 1950-х и 1960-х годах.
Перенесёмся в наше время, и становится очевидно, что развитие пошло другим путём. Чтобы минимизировать усилия по приготовлению пищи, люди теперь покупают готовые блюда. Это ещё один пример смещения проблемы. Обеспечение супермаркетов готовыми блюдами представляет собой более сложную задачу с точки зрения цепочки поставок, чем поставка сырья, из-за увеличенного числа артикулов и более короткого срока годности. Проблема была решена с помощью превосходного решения для цепочки поставок, а не посредством улучшенного кулинарного решения. Проблема приготовления пищи была полностью устранена и переопределена как обеспечение приемлемой еды с минимальными усилиями.
Что касается цепочек поставок, академическая точка зрения часто сосредоточена на поиске лучших решений для существующих проблем. Хорошим примером служат соревнования Kaggle, где у вас есть набор данных, проблема и потенциально сотни или тысячи команд, соревнующихся за лучшее предсказание по этим наборам данных. Проблема чётко определена, и тысячи решений конкурируют друг с другом. Проблема такого подхода в том, что создаётся впечатление, будто для улучшения вашей цепочки поставок нужно просто найти лучшее решение.
Суть принципа в том, что лучшее решение может дать лишь незначительное улучшение, и то только незначительное. Обычно действительно помогает то, что проблема переосмысливается, а это оказывается удивительно сложной задачей. Это касается и количественных проблем. Вам необходимо переосмыслить вашу реальную стратегию цепочки поставок и ключевую проблему, которую следует оптимизировать.
Во многих кругах проблемы воспринимаются как статичные и неизменные, и тогда ищут лучшие решения. Я не отрицаю, что улучшенный алгоритм прогнозирования временных рядов может оказаться полезным, но прогнозирование временных рядов относится к области статистического прогнозирования, а не к мастерству управления цепочками поставок. Если вернуться к моему первоначальному примеру с дорожным чемоданом, то ключевое улучшение у чемодана на колесах заключалось не в самих колесах, а в ручке. На первый взгляд это не имеет ничего общего с колесами, и именно поэтому потребовалось 40 лет на появление решения – нужно мыслить нестандартно, чтобы выявить лучшую проблему.
Этот количественный принцип заключается в том, чтобы бросить вызов проблемам, с которыми вы сталкиваетесь. Возможно, вы недостаточно усердно анализируете проблему, и существует тенденция влюбляться в решение, в то время как следует сосредоточиться на самой проблеме и тех аспектах, которые вам непонятны. Как только проблема чётко определена, наличие хорошего решения обычно сводится к обыденному процессу выполнения, что не представляет особой сложности.
В заключение, предмет цепочек поставок обладает множеством впечатляющих и авторитетных точек зрения. Они могут быть весьма изощрёнными, но вопрос, который я хотел бы задать этой аудитории, таков: не может ли всё это оказаться глубоко ошибочным? Мы действительно уверены, что такие элементы, как прогнозирование временных рядов и операционные исследования, являются правильными подходами к решению проблемы? Независимо от уровня изощрённости и десятилетий инженерных усилий, вложенных в эти направления, действительно ли мы на правильном пути?
Сегодня я представляю серию принципов, которые, как я считаю, имеют первостепенное значение для управления цепочками поставок. Однако они могут показаться странными большинству из вас. У нас существуют два мира — проверенный и странный, и вопрос в том, что произойдёт через несколько десятилетий.
Прогресс, как правило, развивается хаотично и нелинейно. Смысл этих принципов в том, чтобы позволить вам принять мир, полный хаоса, где есть место неожиданностям. Эти принципы могут помочь вам разрабатывать более быстрые, надёжные и эффективные решения, которые улучшат ваши цепочки поставок с количественной точки зрения.
Теперь перейдём к вопросам.
Вопрос: Как распределения Ципфа соотносятся с законом Парето?
Закон Парето — это эмпирическое правило 80-20, но с количественной точки зрения распределение Ципфа является явной предсказательной моделью. Оно обладает предсказательными возможностями, которые можно напрямую проверить на наборах данных.
Вопрос: Не следует ли рассматривать распределение Ципфа–Мандельброта как логарифмическую кривую для наблюдения колебаний в цепочке поставок, как эпидемиологи делают при подсчёте случаев и смертей?
Абсолютно. На философском уровне вопрос заключается в том, живёте ли вы в стране посредственности или в стране экстремумов. Цепочки поставок и большинство человеческих дел существуют в мире крайностей. Логарифмические кривые действительно полезны, если вы хотите визуализировать амплитуду акций. Например, если вы хотите увидеть амплитуды всех прошлых акций для крупных розничных сетей за последние 10 лет, использование обычного масштаба может сделать всё остальное невидимым, просто потому что самая крупная акция была настолько больше остальных. Таким образом, использование логарифмического масштаба может помочь вам увидеть вариации более чётко. С распределением Ципфа–Мандельброта я предлагаю модель, которую можно буквально запустить несколькими строками кода, что представляет собой нечто большее, чем просто логарифмическое представление данных. Тем не менее, я согласен, что основная интуиция остаётся той же. Для более высокого философского уровня я рекомендую ознакомиться с работами Насима Талеба о Mediocristan и Extremistan в его книге “Антихрупкость”.
Вопрос: Что касается локальной оптимизации цепочек поставок, вы имеете в виду использование базовых данных, которые поддерживают сотрудничество в рамках сети цепочки поставок и SNLP?
Моя проблема с локальной оптимизацией заключается в том, что крупные компании, управляющие масштабными цепочками поставок, обычно имеют матричную организационную структуру. Эта структура, с её менталитетом “разделяй и властвуй”, по сути приводит к локальной оптимизации. Например, рассмотрите две разные команды — одну, отвечающую за прогнозирование спроса, и другую — за принятие решений по закупкам. Эти две задачи — прогнозирование спроса и оптимизация закупок — полностью переплетены. Нельзя проводить локальную оптимизацию, сосредоточившись только на процентной ошибке прогнозирования спроса, а затем отдельно оптимизировать закупки, основываясь на эффективности обработки. Существуют системные эффекты, которые необходимо рассматривать вместе.
Главная проблема для большинства крупных, устоявшихся компаний, управляющих значительными цепочками поставок сегодня, заключается в том, что при стремлении к количественной оптимизации необходимо думать на уровне всей системы и всей компании. Это противоречит десятилетиям формирования матричной организации внутри компании, когда сотрудники сосредоточены исключительно на своих чётко определённых границах, забывая о более широкой картине.
Другой пример этой проблемы — запасы в магазине. Запасы выполняют две функции: с одной стороны, они удовлетворяют спрос клиентов, а с другой — выступают в качестве товара. Для достижения оптимального уровня запасов необходимо учитывать как проблему качества обслуживания, так и проблему привлекательности магазина. Привлекательность магазина заключается в том, чтобы сделать его внешне привлекательным и интересным для клиентов, что является задачей маркетинга. В компании есть как маркетинговый отдел, так и отдел цепочки поставок, и естественно они не работают вместе при оптимизации цепочки поставок. Моя мысль в том, что если не объединить все эти аспекты, оптимизация не сработает.
Что касается вашего вопроса о SNLP, проблема в том, что люди собираются вместе только для проведения совещаний, что не является эффективным. Несколько месяцев назад мы опубликовали эпизод Lokad TV о SNLP, так что вы можете обратиться к нему, если захотите подробнее обсудить SNLP.
Вопрос: Как следует распределить время и усилия между стратегией цепочки поставок и её количественным исполнением?
Это отличный вопрос. Ответ, как я упоминал во второй лекции, заключается в полной автоматизации рутинных задач. Это позволяет вам уделять всё своё время и энергию постоянному стратегическому совершенствованию ваших числовых рецептов. Если вы тратите более 10% своего времени на решение рутинных задач цепочки поставок, у вас возникает проблема в методологии. Эксперты по цепочкам поставок слишком ценны, чтобы тратить своё время и энергию на рутинные задачи, которые следовало бы автоматизировать с самого начала.
Вам нужно следовать методологии, которая позволяет посвящать почти всю вашу энергию стратегическому мышлению, которое затем немедленно воплощается в виде превосходных численных алгоритмов, управляющих ежедневным выполнением цепочек поставок. Это относится к моей третьей лекции о поставках, ориентированных на продукт, то есть о поставках программного обеспечения.
Question: Возможно ли гипотетически рассмотреть некий анализ потолка, наилучшее улучшение, возможное для проблем цепей поставок с учётом их системной формулировки?
Я бы сказал: нет, абсолютно нет. Думая, что существует какой-то оптимум или потолок, можно приравнять это к утверждению о том, что существует предел человеческой изобретательности. Хотя у меня нет доказательств того, что предела изобретательности не существует, это одно из моих основных убеждений. Цепочки поставок — это сложные проблемы. Вы можете трансформировать проблему и даже превратить то, что кажется большой проблемой, в большое решение и потенциал для роста компании. Например, посмотрите на Amazon. В начале 2000-х Джефф Безос понял, что для того чтобы быть успешным ритейлером, ему понадобится огромная, надёжная программная инфраструктура. Но эта массивная, промышленного уровня инфраструктура, необходимая для функционирования электронной коммерции Amazon, была невероятно дорогостоящей, обходясь компании в миллиарды. Поэтому команды Amazon решили превратить эту облачную вычислительную инфраструктуру, которая представляла собой огромные инвестиции, в коммерческий продукт. Сегодня эта масштабная вычислительная инфраструктура является одним из основных источников прибыли Amazon.
Когда вы начинаете размышлять о сложных проблемах, вы всегда можете переопределить проблему на более высокий уровень. Именно поэтому я считаю ошибочным думать, что существует некое оптимальное решение. Если мыслить в терминах анализа потолка, вы рассматриваете фиксированную проблему, и с этой точки зрения решение может оказаться, скорее, квазиидеальным. Например, если взглянуть на колёса современных чемоданов, они, вероятно, являются квазиидеальными. Но не упускаем ли мы что-то совершенно очевидное? Возможно, существует способ сделать колёса значительно лучше, изобретение, которое ещё не было совершено. Как только мы его увидим, оно покажется совершенно самоочевидным.
Вот почему мы должны считать, что для этих проблем не существует потолка, поскольку сами проблемы произвольны. Вы можете переопределить проблему и решить, что игра будет вестись по совершенно другим правилам. Это озадачивает, потому что людям нравится думать, что у них есть аккуратно сформулированная проблема, и что они могут найти решение. Современная западная система образования акцентирует внимание на поиске решения, когда вам дают проблему и оценивают качество вашего решения. Однако гораздо интереснее вопрос — качество самой проблемы.
Question: Лучшие решения решают проблемы, но иногда поиск наилучшего решения может потребовать как времени, так и денег. Существуют ли для этого обходные пути?
Абсолютно. Снова, если у вас есть решение, которое теоретически правильно, но его реализация занимает целую вечность, оно не является хорошим решением. Такой подход часто встречается в определённых академических кругах, где сосредотачиваются на поиске идеального решения по узким математическим критериям, не имеющим ничего общего с реальным миром. Именно об этом я и говорил, когда упоминал о правильной задаче оптимизации.
Каждый квартал или около того какой‑то профессор обращается ко мне с просьбой просмотреть его онлайн-алгоритм для решения задачи оптимизации маршрута. Большинство рецензируемых мною статей в наши дни сосредоточены на онлайн-методах. Мой ответ всегда один: вы решаете не ту проблему. Мне не интересны ваши решения, потому что вы даже не думаете правильно о самой проблеме.
Прогресс не следует путать с утонченностью. Это ошибочное представление о том, что прогресс движется от чего‑то простого к чему‑то сложному и утонченному. На самом деле, прогресс часто достигается путём начала с чего‑то невероятно запутанного и, благодаря превосходному мышлению и технологиям, обретения простоты. Например, если вы посмотрите мою последнюю лекцию о тенденциях цепей поставок в 21‑веке, вы увидите Машину Марли, которая доставляла воду во дворец Версаля. Это была безумно сложная система, тогда как современные электрические насосы гораздо проще и эффективнее.
Прогресс не обязательно заключается в дополнительной утончённости. Иногда она требуется, но это не является существенным ингредиентом прогресса.
Question: Крупные розничные сети управляют уровнем своих запасов, но должны выполнять заказы почти мгновенно. Иногда они решают проводить промо-акцию самостоятельно, без инициативы поставщика. Какой подход к прогнозированию и подготовке на стороне поставщика вы бы предложили?
Во-первых, мы должны рассмотреть проблему с другой точки зрения. Вы предполагаете прогнозную перспективу, в которой ваш клиент, крупный ритейлер, внезапно проводит масштабную промо-акцию. Но разве это так уж плохо? Если они продвигают ваши продукты, не уведомляя вас, это просто факт жизни. Если вы оглянетесь на историю, они обычно делают это регулярно, и даже существуют определённые закономерности.
Если вернуться к моим принципам, то закономерности встречаются повсюду. Во-первых, вам следует принять точку зрения, что будущее нельзя предсказать; вместо этого вам нужны вероятностные прогнозы. Даже если вы не можете идеально предвидеть колебания, они могут оказаться не полностью неожиданными. Возможно, вам стоит изменить правила игры, а не позволять поставщику полностью вас удивлять. Может быть, вам нужно согласовать обязательства, связывающие ритейлера, розничную сеть и поставщика. Если розничная сеть начнёт масштабное продвижение, не предупредив поставщика, последний не может быть реалистично признан ответственным за снижение качества обслуживания.
Возможно, решение заключается в более совместном подходе. Может быть, поставщику стоит провести более качественную оценку рисков. Если материалы, продаваемые поставщиком, не являются скоропортящимися, возможно, будет выгоднее иметь пару месяцев запасов. Люди часто мыслят в терминах нулевой задержки, нулевых запасов и нуля всего, но действительно ли это то, чего ожидают от вас ваши клиенты? Возможно, ваши клиенты ожидают дополнительную ценность в виде обильных запасов. Снова, ответ зависит от различных факторов.
Вам нужно рассматривать проблему с разных сторон, и не существует простого решения. Вам следует действительно тщательно обдумать проблему и рассмотреть все доступные варианты. Возможно, речь идёт не об увеличении запасов, а о расширении производственных мощностей. Если наблюдается резкий всплеск спроса, и обеспечить массовый прирост не слишком затратно, а поставщики поставщиков могут быстро обеспечить материалы, возможно, всё, что вам нужно, — это более универсальные производственные мощности. Это позволит перенаправлять мощности на то, что в данный момент испытывает всплеск.
Кстати, такое действительно существует в некоторых отраслях. Например, упаковочная индустрия располагает огромными мощностями. Большинство машин в этой области — промышленные принтеры, которые являются относительно недорогими. Люди, работающие в упаковочном бизнесе, как правило, имеют множество принтеров, которые большую часть времени не используются. Однако когда происходит крупное событие или крупный бренд решает провести масштабное продвижение, у них есть возможность напечатать тонны новых упаковок, соответствующих новому маркетинговому импульсу бренда.
Таким образом, всё действительно зависит от различных факторов, и я прошу прощения за отсутствие окончательного ответа. Но могу с уверенностью сказать, что вам нужно действительно тщательно обдумать проблему, с которой вы сталкиваетесь.
На этом завершается сегодняшняя лекция, шестая и последняя в прологе. Через две недели, в тот же день и час, я представлю лекцию о личностях в цепях поставок. До встречи в следующий раз.
