00:15 Введение
02:28 Умный холодильник
05:28 Смещение выживших
07:28 История до сих пор
08:46 О табу (резюме)
12:06 Эвристика отклонения (резюме)
13:34 Низкокачественные положительные знания
15:27 Антипаттерны программного обеспечения, 1/2
20:11 Антипаттерны программного обеспечения, 2/2
25:34 Антипаттерны цепи поставок
27:00 Голые прогнозы
32:36 100% уровень обслуживания
37:06 Инициация Джедая
44:31 Неевклидов ужас
51:45 Адвокат дьявола
57:35 Резюме, отрицательные знания для цепей поставок
01:01:04 Заключение
01:02:45 Предстоящая лекция и вопросы аудитории
Описание
Антипаттерны - это стереотипы решений, которые кажутся хорошими, но на практике не работают. Систематическое изучение антипаттернов было начато в конце 1990-х годов в области программной инженерии. При применении антипаттерны превосходят простые отрицательные результаты, так как их легче запомнить и осмыслить. Антипаттерн-подход является важным аспектом для цепи поставок и должен рассматриваться как один из фундаментальных принципов ее отрицательных знаний.
Полный транскрипт
Привет всем, добро пожаловать на эту серию лекций по цепи поставок. Я Йоанн Верморель, и сегодня я буду рассказывать о отрицательных знаниях в цепи поставок. Для тех из вас, кто смотрит лекцию в прямом эфире, вы можете задавать вопросы в любой момент времени через чат YouTube. Я не буду читать чат во время лекции, однако я вернусь к нему в самом конце лекции для сессии вопросов и ответов.
Сегодня тема интереса - что на самом деле компания получает, когда нанимает опытного директора по цепи поставок с двадцатилетним опытом. Что именно ищет компания, и можем ли мы в некоторой степени воспроизвести приобретение этого опыта за гораздо более короткое время? Вот в чем суть отрицательных знаний.
Когда мы смотрим на очень опытного человека, кто работал два десятилетия в определенной области, мы действительно ищем, чтобы этот человек повторял решения, процессы или технологии, которые он реализовал один или два десятилетия назад в других компаниях? Вероятно, нет. Хотя это может случиться в незначительной степени, я подозреваю, что обычно это очень редкое явление.
Когда вы ищете очень опытного человека, целью не обязательно является повторение вещей так, как они делались в прошлом. Основная ценность, которую вы хотите получить, заключается в том, чтобы взять человека, который знает, как избежать всевозможных ошибок и имеет опыт, чтобы гарантировать, что множество очень наивных и плохих идей не будут реализованы в вашей компании. Есть такое выражение, что в теории практика и теория одно и то же, но на практике это не так. Вот в чем суть отрицательных знаний.
Мое предложение для вас заключается в том, что плохие бизнес-идеи повсюду. Когда я говорю плохие, я имею в виду идеи, которые, если реализованы, окажутся совершенно нерентабельными для компании. Чтобы проиллюстрировать это, я просто ввел запрос “умные холодильники” в поисковую систему Google Patents. Google Patents - это специализированная поисковая система, предоставляемая Google, и вы можете искать в базе патентов. И вот мы получаем 130 000 результатов патентов, поданных на умные холодильники.
Примите это число с некоторой долей скептицизма, так как, вероятно, есть много дубликатов. Однако беглый осмотр результатов показывает, что очень ясно, у нас есть несколько сотен, если не несколько тысяч компаний, которые за последние несколько десятилетий приложили все усилия, чтобы провести исследования и разработки и подать патент на умные холодильники. Когда вы посмотрите на вид идей, найденных в этих патентах, вы увидите, что это всегда комбинация взятия этого очень распространенного прибора, холодильника, и добавления чего-то, например, дешевой электроники. Мы сочетаем два варианта, и вуаля, у нас есть какое-то решение.
Для какой проблемы, однако? Это очень неясно. Просто чтобы дать вам представление о большинстве патентов, это такая идея, что если у вас есть холодильник с какими-то датчиками, сам холодильник будет определять, если у вас заканчивается молоко, и автоматически сделает заказ для вас. Мы находимся в 2021 году, и насколько мне известно, умные холодильники не существуют. Не то, чтобы они технически невозможны - они очень даже возможны. Просто рынка для них буквально нет. Итак, у нас огромное количество решений на рынке, ищущих проблему. За последние два десятилетия я, по моим оценкам, видел дважды в год стартап, продвигающий умный холодильник какого-то вида. Интересно, что я никогда не получал обратной связи от этих стартапов. Я не вел учет, но с большой вероятностью могу предположить, что каждый стартап, который я видел, продвигающий умный холодильник за последние два десятилетия, потерпел неудачу. Однако, хотя идея очень широко распространена и популярна, как показывают тысячи патентов, последствия этих идей, которые плохи, потому что, вероятно, большинство этих стартапов просто обанкротились, не распространялись.
Здесь мы видим очень интересную вещь: благодаря опыту вы можете получить такого рода знания, которые не доступны наблюдателям на рынке. Вы можете видеть темную сторону, то есть то, чего не хватает, то, что было обещано и анонсировано, но оказалось не очень успешным.
Есть очень заметный исторический пример из Второй мировой войны. Армия США провела исследование самолетов, возвращающихся на базу, чтобы собрать информацию о расположении попаданий пуль на самолете. То, что вы видите на экране, по сути, является сбором расположения пуль, наблюдаемого на самолетах, возвращающихся с полей боя на базу. Изначально офицеры армии следовали логике, что им нужно добавить бронепластины в областях, которые получили наибольшее количество попаданий, в областях, которые очевидно были под самым сильным огнем во время боя.
Затем другой джентльмен, Абрахам Вальд, сказал нет, это совершенно наоборот. Дело в том, что то, что вы видите, это самолеты, которым удалось вернуться на базу. То, что вы не видите, это то, что, скорее всего, когда в этой области было попадание пули, оно оказалось смертельным как для самолета, так и для экипажа, или и для того, и для другого. Так что, если вам нужно добавить какие-либо бронепластины, вы должны сделать это именно во всех областях, где вы не видите самолеты, возвращающиеся на базу с попаданиями пуль. Именно эти области нужно защищать.
То, что указал Авраам, заключается в том, что существует явление, известное как эффект выжившего, где то, что вы наблюдаете, в основном является выжившими, а не всеми самолетами, которые не вернулись на базу. Идея отрицательных знаний точно такая же: вы берете эту фотографическую картину и негатив, и именно остальное вам действительно нужно привлечь внимание, потому что именно там происходят настоящие плохие вещи. Это суть, я бы сказал, отрицательных знаний.
Это четвертая лекция в моей серии лекций, первая лекция второй главы. В первой главе пролога я представил свои взгляды на цепочку поставок, как на область исследования, так и на практику. Мы видели, что цепочка поставок в основном представляет собой совокупность сложных проблем, в отличие от простых проблем. Сложные проблемы очень сложно решить, потому что они не поддаются ни простому изучению, ни простой практике. В изучении и практике сложных проблем есть фундаментальное препятствие. Вот почему вторая глава посвящена методологиям.
В этой лекции мы используем качественный подход, как и в случае с персонами цепочки поставок, которая была первой лекцией в этой главе. Мы рассмотрим различные качественные подходы, которые могут помочь улучшить цепочки поставок таким образом, чтобы они были контролируемыми, надежными и, возможно, в конечном итоге измеримыми.
Резюме: Хотя эта лекция посвящена отрицательным знаниям, это не первый раз в этой серии лекций, когда я затрагиваю элементы, которые можно было бы отнести к кусочкам отрицательных знаний. Во время первой лекции этой второй главы о персонах цепочки поставок я представил свои взгляды на кейс-исследования. Я сказал, что положительные кейс-исследования, то есть кейс-исследования, представляющие положительные результаты, связанные с интересующим нас решением, сопровождаются массовыми конфликтами интересов, которые фактически полностью подрывают доверие к достоверности результатов. С другой стороны, я заявил, что отрицательные кейс-исследования вполне приемлемы, потому что эти конфликты интересов, хотя они и могут присутствовать, намного менее интенсивны.
В этой лекции о персонах цепочки поставок я представил фантастическое отрицательное кейс-исследование “Последние дни Target Canada” Джо Кастальдо, в котором подробно описывается эпическое сбоев цепочки поставок, в результате которого Target Canada обанкротился. Это своего рода отрицательные знания, где объектом изучения является буквально то, что не работает, в отличие от того, что мы можем сделать, чтобы что-то действительно работало.
Можем ли мы использовать отрицательные кейс-исследования в качестве основной практики для наших отрицательных знаний в области цепочки поставок? Я бы сказал, что в основном нет, по двум очень отличающимся причинам. Первая причина заключается в том, что отрицательные кейс-исследования очень редки. Я предполагаю, просто наугад, что на самом деле есть более 100 раз больше патентов на умные холодильники, которые совершенно бесполезны, чем отрицательных кейс-исследований о цепочках поставок. Итак, у нас есть очень практическая проблема: хотя эти отрицательные кейс-исследования имеют первостепенное значение и вызывают большой научный интерес, они оказываются крайне редкими. У нас так мало этого материала, что очень сложно использовать его в качестве основы наших отрицательных знаний в области цепочки поставок.
Вторая проблема - понятность. Те отрицательные кейс-исследования, как фантастическая статья “Последние дни Target Canada”, показывают, что происходит десятки проблем одновременно, и все эти проблемы полностью переплетены, что в конечном итоге приводит к эпическому провалу. Проблема заключается в том, что эти кейс-исследования - это буквально реальная жизнь, и эти события очень сложны. Сложно общаться и рассуждать об этих кейс-исследованиях, потому что детали имеют значение, и они очень плотные. Есть еще одна проблема: как вы это передадите более широкой аудитории?
На моей последней лекции об экспериментальной оптимизации мы также рассмотрели другой вид негативных знаний: эвристики отклонения. Это в основном простые трюки, которые можно использовать, когда есть предложение в терминах количественного решения, выдвигаемое в качестве потенциального кандидата для улучшения вашей цепочки поставок. Вы можете использовать ряд эвристик или простых правил, чтобы отбросить решения, которые с очень высокой степенью уверенности просто не сработают. Однако здесь у нас возникает проблема масштабируемости. Эти эвристики работают только потому, что они непонятны. Если бы они стали широко известными среди кругов управления цепочками поставок, научные статьи и программное обеспечение для управления цепочками поставок были бы адаптированы и изменили свою риторику, что привело бы к большей путанице. Эти эвристики очень эффективны, но если бы они стали популярными, они все равно сохранили бы свою действительность, но потеряли бы свою эффективность в качестве фильтров, просто потому, что люди обратили бы внимание на обход этих эвристик.
Вот почему эти эвристики, хотя и очень интересны, не могут быть использованы в качестве основы для наших негативных знаний, которые мы хотим сформировать для цепочки поставок.
Кроме того, мы не должны путать негативные знания с низкокачественными положительными знаниями. Разница действительно заключается в намерении. Например, намерение резервных запасов состоит в том, чтобы предоставить компаниям контролируемый способ обеспечения качества обслуживания, которое они получат. Намерение положительное; это решение для чего-то, что должно работать. Теперь реальность заключается в том, что модель резервных запасов основана на полностью неправомерных предположениях: будущий спрос и сроки поставки предполагается нормально распределенными, хотя эти предположения фактически неверны. Я никогда не наблюдал наборы данных цепочки поставок, где либо спрос, либо сроки поставки были нормально распределены. Интересующие нас распределения фактически являются распределениями Зипфа, о которых я говорил в своих предыдущих лекциях о количественных принципах для цепочки поставок. С правильной точки зрения, резервные запасы являются фальсифицированными, но тем не менее, резервные запасы определенно находятся в области положительных знаний, хотя, возможно, это будет спорное знание очень низкого качества.
Во время этой лекции у нас не будет времени углубляться во все элементы, которые, с моей точки зрения, квалифицируются как очень низкокачественные положительные знания, но я с радостью отвечу на вопросы о любом из этих элементов во время сессии вопросов и ответов.
Когда речь идет о фактических отрицательных знаниях практического интереса, существует книга под названием “Анти-паттерны: рефакторинг программного обеспечения, архитектур и проектов в кризисе”, которая является вехой в истории программной инженерии. Опубликованная в 1998 году, эта книга начинается с небрежного наблюдения о том, что в программной индустрии, когда есть хорошие идеи и проекты, использующие эти хорошие идеи, поставщики программного обеспечения видят, как хорошие идеи поглощаются успехом проекта. Авторы задают вопрос, остается ли хорошая идея хорошей практикой после реализации продукта, и ответ в основном отрицательный. Существует преимущество первого движения, которое является очень специфичным для программной индустрии, и в результате у нас возникает проблема. Практически любой набор правил, которые вы бы использовали для прогнозирования успеха чего-либо в программной индустрии, самоуничтожающийся, из-за того факта, что самые лучшие подходы обычно поглощаются успехом, который они генерируют. Авторы “Анти-паттернов” заметили, что по их мнению практически невозможно гарантировать успех программной инициативы. Однако они также заметили, что ситуация очень асимметрична, когда речь идет о неудачах. Они отметили, что можно с высокой степенью уверенности (иногда граничащей с уверенностью) предсказать, что данный проект собирается потерпеть неудачу. Это очень интересно, потому что вы не можете гарантировать успех, но у вас может быть что-то вроде науки, которая гарантирует неудачу. Еще лучше, эти знания о элементах, которые гарантируют неудачу, кажется, чрезвычайно стабильны со временем и очень независимы от технических аспектов компании или рассматриваемой отрасли.
Если мы вернемся к исходной идее умного холодильника, мы увидим, что все эти патенты на умные холодильники чрезвычайно разнообразны по представленным решениям. Но оказывается, что все эти патенты на умные холодильники приводят к неудачам в бизнесе, потому что все они подпадают под одну и ту же категорию: решение, ищущее проблему. Комбинация повсеместного прибора с дешевой электроникой создает решение, но это действительно имеет смысл? В этом случае почти никогда.
Авторы “Анти-паттернов” начали свое путешествие, изучая коренные причины неудач программного обеспечения и выявили семь смертных грехов программной инженерии, которые являются поспешностью, безразличием, узколобостью, алчностью, невежеством, гордостью и завистью. Эти проблемы будут независимы от контекста и используемых технологий, потому что они являются неизменными свойствами самой человеческой природы. Когда вы ищете директора по цепочке поставок с двадцатилетним опытом, это будет человек, который просто прожил дольше и усвоил большую часть проблем, возникающих, когда вовлечены реальные люди со всеми видами недостатков.
Идея авторов заключается в том, что полезно формализовать эти знания, чтобы сделать их более усвояемыми и понятными, чтобы было легче общаться и рассуждать об этих проблемах. Вот суть анти-паттернов - формат для захвата кусочков отрицательных знаний.
В своей книге авторы представляют шаблон для анти-паттерна, который начинается с запоминающегося названия, легкого для запоминания. Вам нужно характеризовать масштаб, будь то уровень исходного кода, уровень архитектуры программного обеспечения, уровень компании или уровень отрасли. Вы хотите определить фактические коренные причины и связанные с ними последствия. Вы хотите характеризовать действующие силы, симптомы и непредвиденные последствия, которые люди не ожидают и которые полностью подрывают ожидаемые преимущества исходного решения.
Авторы утверждают, что вам нужно представить анекдотические доказательства, и поэтому они используют вымышленные компании в своих анти-паттернах. Это делается для избежания табу, связанных с обсуждением реальных компаний и реальных людей, что может помешать установлению честного общения. Шаблон анти-паттерна должен заканчиваться переработанным решением, которое является путем преобразования того, что по сути является ошибочным решением, в вариант этого решения, который действительно работает в реальном мире, где непредвиденные последствия смягчены и, в идеале, устранены.
Эта лекция не о противопаттернах в снабжении, но просто чтобы привести два примера противопаттернов в программном обеспечении, о которых вы могли слышать, первый - Золотой Молоток. Золотой Молоток - это идея, что когда у вас в руках есть золотой молоток, все остальное - гвозди. Этот противопаттерн в основном утверждает, что если вы спросите у программиста Java, как он бы решил новую проблему, он, скорее всего, предложит написать программу на Java для решения этой проблемы. Если вы представите другую проблему тому же человеку, он скажет, что и эту проблему также можно решить с помощью программы на Java. Если вы представите 20 разных проблем, каждый раз ответ будет: “Я считаю, что программа на Java справится”. Это огромное предубеждение, когда люди с опытом в определенной технологии имеют тенденцию перерабатывать свои технические знания для решения новых проблем, вместо того, чтобы потратить время на оценку того, действительно ли их знания технически релевантны для решения новой проблемы. Интеллектуально намного проще придерживаться того, что вы действительно знаете.
Еще один пример - Анализ Паралича. В мире программного обеспечения есть много ситуаций, когда возможности бесконечны, и соблазнительно сказать: “Вместо того, чтобы испытывать 20 разных подходов, которые обречены на провал, давайте очень тщательно подумаем о дизайне, и только когда мы абсолютно уверены, что у нас есть правильное решение в голове, мы приступим к его реализации”. К сожалению, это очень сложно выполнить и обычно приводит к анализу паралича, когда больше времени и усилий тратится на рассмотрение множества потенциальных вариантов, вместо того, чтобы просто попробовать решение и посмотреть, работает оно или нет.
Очевидно, что мы обсудили, что эта книга посвящена противопаттернам в программном обеспечении, и я считаю, что инженерия программного обеспечения имеет много общего с проблемами, с которыми мы сталкиваемся в снабжении, особенно с оптимизацией снабжения. Оба поля в основном являются сборниками сложных проблем, и современное снабжение во многом связано с созданием программного продукта. Таким образом, существует определенная степень перекрытия между проблемами снабжения и проблемами инженерии программного обеспечения, но эти два поля не находятся на полной разнице в световых годах.
Здесь я представлю пять противопаттернов в снабжении, которые можно найти в письменной форме на веб-сайте Lokad, с более подробной презентацией для заинтересованных.
Первый - Голые прогнозы. Вдохновленный рассказом “Новое платье императора” Ганса Христиана Андерсена, контекст - компания с текущей инициативой по улучшению точности прогнозирования. Некоторые симптомы включают долгосрочные прогнозы, о которых жалуются все - производство, маркетинг, продажи, закупки, и даже снабжение, причем отдел прогнозирования обычно является частью снабжения. Были попытки улучшить точность прогноза за последние один или два десятилетия, но кажется, что несмотря на все усилия, есть бесконечная серия оправданий от ответственных за прогнозирование людей, чтобы оправдать его низкую точность.
Дело в том, что есть следующая инициатива, целью которой является привести точность прогноза в порядок, исправить эту проблему с неточным прогнозом раз и навсегда. Вот как работает противопаттерн Голые прогнозы. Непреднамеренные последствия этого заключаются, во-первых, в том, что это не приведет к значительно более точным прогнозам. Во-вторых, прохождение еще одной инициативы просто создаст еще более сложную организацию, где то, что началось как маленькая практика по доставке прогноза, становится все более сложным, с участием большего числа людей в производстве этих прогнозов. В итоге вы получаете нечто, что все так же неточно, но превратилось из чего-то скромного и неточного в большую бюрократию, которая все так же неточна, как и раньше.
Я считаю, что корневая причина здесь заключается в том, что я называю наивным рационализмом или иллюзией науки. Когда начинается эта инициатива, проблема представляется себя совершенно объективной: “Мы собираемся создавать более точные прогнозы согласно метрике, скажем, средней абсолютной ошибке”. Все это кажется очень простым, с четко определенной проблемой. Однако проблема заключается в том, что все это очень наивно, потому что нет прямой связи между точностью прогнозирования и прибыльностью компании. Вы должны искать способы улучшения прибыльности компании, поэтому вы должны думать в терминах долларов или евро ошибки, а не процентов ошибки.
Фундаментально, корневая причина заключается в том, что эти прогнозы являются самостоятельными и не получают обратной связи от реального бизнеса. Точность прогнозирования - это просто числовой артефакт; это не реальный, осязаемый возврат инвестиций для бизнеса. Как анекдотическое доказательство, если бы я получал дополнительную зарплату в тысячу долларов каждый раз, когда я вел дискуссию по телефону с директором цепи поставок, который сказал мне, что они начинают новую инициативу по улучшению точности прогнозирования, я был бы еще богаче.
Главное заключается в том, что, с точки зрения переработанного решения, пока прогнозы остаются голыми, это не сработает. Вам нужно надеть на них одежду, и эта одежда - это решения. Как мы исследовали в предыдущей лекции с экспериментальной оптимизацией, если прогнозы не прямо связаны с реальными жизненными, осязаемыми решениями, такими как сколько купить, сколько произвести или повысить или понизить цены, вы никогда не получите реальную обратную связь, которая имеет значение. Реальная обратная связь, которая имеет значение, не является KPI на измерение обратного теста; важными являются именно эти решения. Таким образом, с точки зрения переработанного решения для решения проблемы голого прогноза, это в основном означает, что те же люди, которые генерируют прогноз, должны жить с последствиями этих прогнозов, когда речь идет о фактических решениях цепи поставок, которые реализуются поверх них.
Второй пример - это Мифический 100% Уровень сервиса. Ситуация обычно начинается следующим образом: совет директоров собирается, и где-то в прессе или в социальных сетях некоторые люди громко жалуются на качество обслуживания. Это выглядит нехорошо для компании, так как кажется, что компания не выполняет обещания, которые она дала. Совет директоров оказывает огромное давление на генерального директора, чтобы он что-то сделал с этой проблемой качества обслуживания, которая негативно сказывается на бренде, имидже и, возможно, на росте компании. Генеральный директор говорит: “Нам действительно нужно положить конец этой бесконечной серии проблем с качеством обслуживания”. Итак, генеральный директор обращается к вице-президенту по цепи поставок и просит его положить конец этим проблемам с качеством обслуживания. Вице-президент по цепи поставок, в свою очередь, просит директора цепи поставок сделать то же самое, и директор цепи поставок просит менеджера цепи поставок решить эту проблему. Менеджер цепи поставок затем повышает уровень обслуживания до очень высокого значения, близкого к 100%.
И вот, даже если в краткосрочной перспективе у вас получается немного более высокий уровень обслуживания, очень скоро проблемы с качеством обслуживания возвращаются. Эти более высокие уровни обслуживания неустойчивы, и вы сталкиваетесь с колебаниями запасов, излишними запасами, и, хотя целью было повышение уровня обслуживания, часто через шесть или двенадцать месяцев уровень обслуживания снижается.
Корневая причина здесь заключается не только в незнании, но и в мечтательности. Математически говоря, если вы хотите 100% уровень обслуживания, это означает бесконечное количество запасов, что технически невозможно. У вас есть мощное мечтательное мышление, что вы можете полностью решить эту проблему, хотя это невозможно. В лучшем случае вы можете смягчить проблемы с качеством обслуживания; вы никогда не сможете полностью их устранить.
Что касается анекдотических доказательств, я видел, что многие компании сталкиваются с наибольшими трудностями из-за того, что у них есть такая установка на мифический целевой уровень обслуживания в 100%. Если ваша компания не готова принять тот факт, что для некоторых продуктов (не для всех или самых важных) уровни обслуживания будут снижены намеренно, то вы идете к большим проблемам. Единственный способ действительно улучшить качество обслуживания - это сначала принять тот факт, что если фокус на всем, это эквивалентно тому, что фокуса вообще нет. Пока вы не готовы принять тот факт, что для некоторых SKU уровень обслуживания будет намеренно снижен как приемлемый результат, вы не сможете улучшить общее качество обслуживания.
Что касается переработанных решений, переработанное решение - это экономические факторы. Это точка, которую я представил во второй лекции первой главы, визию для количественной цепи поставок. Экономические факторы показывают, что у вас есть стоимость дефицита товара и стоимость хранения, и здесь нужно найти баланс. Вы не можете просто стремиться к 100% уровню обслуживания, потому что это полностью несбалансировано с экономической точки зрения; это неустойчиво. Попытка двигаться в этом направлении - очень ошибочное решение, потому что это только навредит компании. Решение заключается во внедрении здоровой доли экономических факторов в вашу практику управления цепями поставок.
Теперь третий анти-паттерн, Инициация Джедая, можно увидеть, когда топ-менеджмент во многих крупных компаниях постоянно подвергается давлению со стороны СМИ из-за постоянного потока модных слов, направленных в их сторону. Эти модные слова включают искусственный интеллект, блокчейн, облачные вычисления, большие данные, интернет вещей и т. д. Инфлюенсеры говорят им, что если их компания не адаптируется к этим тенденциям, она станет устаревшей. Существует постоянный страх пропустить что-то важное, который действует как мощная сила, непрерывно давящая на топ-менеджмент большинства крупных компаний, которые управляют большими цепями поставок.
Симптомы Инициации Джедая можно наблюдать, если в вашей компании есть подразделение с молодыми, энтузиастичными инженерами, у которых в должностных названиях есть модные слова, такие как исследователи искусственного интеллекта, блокчейн-инженеры или специалисты по обработке данных. Девизом является “овладение силой”, где сила - это модное слово, актуальное на данный момент. Руководство берет, пожалуй, молодых или неопытных людей и говорит им сделать что-то великое для компании, но без участия или знания технических аспектов этих концепций.
В результате эти команды создают интересные прототипы, которые в конечном итоге не способны принести реальную ценность для компании. В результате, хотя все начиналось с идеи, что компания будет революционизирована в соответствии с модным словом дня, практики и технологии прошлого остаются преобладающими, не измененными модным словом или дополнительной командой, созданной вокруг него.
Что касается анекдотических доказательств, в настоящее время, в 2021 году, подавляющее большинство компаний с командой по науке о данных не получают никакой отдачи от своих инвестиций. Команда по науке о данных создает фантастические прототипы на языке Python с использованием библиотек с открытым исходным кодом, которые очень круты, но в практическом плане отдача от инвестиций для подавляющего большинства рынка составляет ровно ноль. Именно такую инициацию Джедая принимает топ-менеджмент: они читают в прессе, что наука о данных - это новый тренд, поэтому они нанимают команду по науке о данных. Как интересный факт, я вижу, что эти команды не только довольно молоды и неопытны, но и остаются такими со временем. Это связано с высокой текучестью кадров. В компании может быть очень прочная и надежная структура, где средняя текучесть составляет обычно от пяти до десяти лет, за исключением команды по науке о данных, где люди в среднем остаются на 18 месяцев. Одна из причин, по которой из этих команд ничего ценного не выходит, заключается в том, что люди приходят, создают несколько прототипов и уходят. Для компании это не приносит капитализации, и она никогда не смогла действительно преобразиться.
В отношении рефакторинга этого решения, во-первых, нет другого пути, кроме как давать пример. Если вы хотите действительно заниматься наукой о данных, топ-менеджмент должен быть очень хорошо знаком с наукой о данных. Например, Джефф Безос показал знание передовых методов машинного обучения своего времени. Amazon может быть очень успешным в области машинного обучения, но это происходит потому, что топ-менеджмент очень хорошо знаком с деталями. Вести примером является важным аспектом.
Во-вторых, вы должны убедиться, что когда вы нанимаете этих молодых, энтузиастичных и потенциально талантливых инженеров, вы сталкиваете их с реальными проблемами, а не метапроблемами. Это должно быть связано с реальностью. Это возвращается к моей предыдущей лекции о эмпирической, экспериментальной оптимизации. Если вы нанимаете научного сотрудника по данным для сегментации клиентов или для лучшего ABC-анализа для вашей компании, это не реальные проблемы. Это просто выдуманные числа. Если вы нанимаете этих людей и поручаете им ответственность за фактическое пополнение запасов и за точные количества, которые должны быть пополнены у ряда поставщиков, это очень реально. Вот почему десять лет назад Lokad внутренне перешел от научных сотрудников по данным к научным сотрудникам по цепям поставок. Смысл заключался в том, чтобы иметь совершенно иное обязательство и избавиться от этого антипаттерна инициации Джедая.
Ужас неевклидов. В этом контексте у вас есть компания, которая управляет большой цепочкой поставок, и ИТ-ландшафт очень сложен. Есть несколько крупных программных продуктов, таких как ERP, WMS и EDI, которые сами по себе сложны. Затем у вас есть все связующие элементы, которые соединяют все это вместе, и весь образ получается ошеломляюще сложным. Итак, как вы узнаете, что вы на самом деле находитесь в компании, которая сталкивается с неакклиматизированным решением? Какие симптомы? Симптомы заключаются в том, что каждый в компании чувствует, что в ИТ-отделе царит безудержная неспособность. Люди из ИТ выглядят перегруженными и кажется, что они не понимают, что происходит в системе, которую они должны управлять и поддерживать. Еще одним симптомом является то, что вы видите проблемы в ИТ, которые ежедневно влияют на производство. Это ключевые симптомы неакклиматизированного решения.
Последствием наличия неакклиматизированного ИТ-ландшафта является то, что изменения, которые необходимо внести в компанию, и, как правило, когда в компании происходит изменение, необходимо также внести изменения в ИТ-системы. Современные поставочные цепи в значительной степени управляются своими программными компонентами. Все эти изменения происходят очень медленно, и это всегда утомительный процесс, где даже небольшие изменения занимают вечность. Всякий раз, когда есть какая-то степень изменения, обычно возникает множество регрессий. Как говорят, вы делаете два шага вперед и три шага назад, затем снова делаете два шага вперед и один шаг назад. Изменение не только медленное, но и сопровождается постоянным потоком регрессий. Ситуация действительно не улучшается со временем; в лучшем случае она застаивается.
В терминах коренных причин, руководство действительно не заботится о мелочах, и не-ИТ-руководство действительно не заботится о всех этих ИТ-системах. Это приводит к подходу, который я называю инкрементализмом, когда любые изменения, которые они хотят, чтобы произошли в ИТ-системе компании, эти изменения будут запрошены поставочными цепями, например. Всякий раз, когда происходит изменение, которое должно произойти, руководство всегда говорит: “Пожалуйста, выберите самый простой путь, путь, который требует наименьшего количества усилий и времени, чтобы мы могли увидеть это реализовано как можно скорее.” Вот в чем суть инкрементализма.
Я считаю, что инкрементализм является очень опасной коренной причиной. Проблема инкрементализма заключается в том, что это буквально смерть от тысячи порезов. Каждое отдельное изменение, которое вносится в систему, делает ее немного более сложной, немного более неуправляемой и немного более сложной для тестирования. Хотя каждое отдельное изменение незначительно, когда вы накапливаете десятилетие десятков изменений, вносимых в ИТ-системы ежедневно, вы получаете океан сложности. Каждое изменение сделало систему более сложной, и общая картина полностью потеряна. Пройдя десятилетие, вы получаете массивную, запутанную систему, которая выглядит неразумно.
Как пример анекдотического доказательства, вы можете видеть, что до сих пор существуют очень крупные компании электронной коммерции, где, как потребитель, вы регулярно видите, что у них бывают перерывы в работе. Такие вещи не должны происходить. Как компания электронной коммерции в 2021 году, ваше время работы должно быть примерно 10 минут простоя в год. Каждая секунда простоя - упущенная возможность. Проектирование программного обеспечения для корзины покупок в 2021 году уже не является ракетной наукой; это на самом деле очень обычное программное обеспечение с точки зрения предприятия. Нет никакой причины, чтобы не иметь что-то, что всегда включено. Однако реальность заключается в том, что когда вы видите, что электронная коммерция не работает, обычно это не ошибка корзины покупок; это неакклиматизированное решение, находящееся непосредственно за электронной коммерцией. Отказ электронной коммерции - это всего лишь отражение проблемы, которая произошла где-то в ИТ-ландшафте.
Если мы хотим переработать неакклиматизированное решение, мы должны перестать искать самое простое решение для внесения изменений. Нам нужно думать не о простом решении, а о простом решении. Простое решение отличается от простого решения важным образом: оно делает весь ландшафт немного более аккуратным и здравым, что облегчает внесение последующих изменений в будущем. Вы можете сказать: “Но это просто технический вопрос, поэтому это работа ИТ.” Я бы сказал, нет, абсолютно нет. Это в значительной степени проблема поставочной цепи. Принятие простого решения - это не вопрос наличия простого решения с точки зрения ИТ; это наличие простого решения с точки зрения поставочной цепи.
Простота решения и его предполагаемое последствие в виде упрощения внесения последующих изменений зависят от вашего плана развития. Какие будущие изменения вы хотите внести в свой ИТ-ландшафт? ИТ, как подразделение, не имеет времени быть экспертами по поставочной цепи и точно знать, куда вы хотите направить компанию через десять лет в плане выполнения поставочной цепи. Это должно быть управление поставочной цепью, которое имеет эту видение и должно направлять развитие, потенциально с поддержкой ИТ, в направлении, где изменения становятся все более легкими для внедрения со временем.
Наконец, последний анти-паттерн на сегодня - адвокат дьявола. Контекст обычно связан с крупной компанией, у которой возникли серьезные проблемы с поставками и которая решила обратиться к крупному поставщику, выложив на стол много денег. Инициатива запускается, и через несколько месяцев, обычно около шести месяцев, у поставщика почти нет результатов. Много денег было потрачено на поставщика, а результатов практически нет. Кстати, в 2021 году шесть месяцев - это долгий срок. Если у вас есть программная инициатива, которая не дает осязаемых результатов производственного уровня за шесть месяцев, вам следует очень волноваться, потому что, по моему опыту, если вы не можете доставить осязаемые результаты за шесть месяцев, вероятно, инициатива обречена, и у компании никогда не будет положительного возврата от инвестиций.
В результате руководство видит, что проект задерживается, и результатов практически нет. Топ-менеджмент, вместо того чтобы становиться все более агрессивным по отношению к техническому поставщику и быть на переднем крае технологий, внезапно меняет сторону и становится очень защитническим по отношению к поставщику. Это очень странно. Вы запускаете большую инициативу, отдаете много денег другой компании, и инициатива движется вперед, но плохо и практически не дает результатов. Вместо того чтобы объяснить, что инициатива фактически терпит неудачу, руководство усиливает свою защиту поставщика, что очень странно. Это похоже на синдром Стокгольмского синдрома, когда кто-то причиняет вам вред, но если он причиняет достаточно вреда, то в какой-то момент вы начинаете нравиться этим людям.
Руководство и сама инициатива становятся слишком важными, чтобы потерпеть неудачу, и в результате теряется огромное количество денег и масса упущенных возможностей, особенно в плане времени. По мере продвижения инициативы теряются деньги, но, что более важно, теряется время - шесть месяцев, год, два года. Реальная стоимость - это время. В качестве своего рода анекдотического доказательства для такого рода вещей, вы можете читать очень часто в прессе о масштабных неудачах внедрения ERP-систем для проектов, которые длится почти десятилетие или иногда пять-десять лет. Вы думаете, как можно иметь проект продолжительностью в пять лет? Ответ заключается в том, что люди продолжают усиливать этот проект, и требуется буквально годы, чтобы, наконец, признать, что это полная неудача и что он никогда не сработает.
Еще один кусочек анекдотического доказательства заключается в том, что, будучи внутри и наблюдая за многолетними, масштабными неудачами внедрения ERP-систем, часто бывает так, что проект прекращается не потому, что люди соглашаются с тем, что поставщик действительно потерпел неудачу. Игра идет так, что в какой-то момент высшее руководство, которое было вовлечено в решение о привлечении поставщика в первую очередь, просто переходит в другие компании. Когда практически все те люди, которые изначально были частью решения о привлечении крупного поставщика, покидают компанию, другие люди, которые не чувствуют такой приверженности к этому конкретному поставщику, просто соглашаются закрыть его и считают, что дело сделано.
В плане рефакторинга решения я считаю, что компании должны быть более терпимы к неудачам. Вы должны быть строгими по отношению к проблемам, но мягкими по отношению к людям. Если вы выращиваете культуру, где говорите такие вещи, как “Мы должны сделать все правильно с первого раза”, это очень вредно, потому что это означает, что у вас будет меньше неудач. Это неправильное понимание человеческого разума и человеческой природы думать, что если у вас есть культура, которая терпит неудачи, вы на самом деле получаете больше неудач. Да, вы получаете незначительно больше небольших неудач, но что вы получаете, так это людей, склонных признавать ошибки и двигаться дальше. Если, наоборот, у вас есть культура “сделать все правильно с первого раза”, то практически никто не может потерять лицо. Так что даже когда есть что-то абсолютно дисфункциональное, выживание инстинкта людей, вовлеченных в это, состоит в усилении этой вещи, которая не работает, только чтобы сохранить свое лицо и, возможно, перейти в другую компанию, чтобы им не пришлось сталкиваться с последствиями своих ошибок.
Подведем итоги: у нас есть положительные знания против отрицательных знаний. Положительные знания в основном связаны с решением проблем; это своего рода интеллект доктора наук, интеллект, связанный с решением проблем, где у нас есть головоломки и мы можем двигаться от одного решения к лучшему решению. Можно оценить, что одно решение лучше другого, и вершина этого рода мышления - достижение оптимального решения. Однако то, что люди думают, что они ищут - оптимальные решения, которые являются абсолютно правильными и бессмертными - то, что они получают, это очень эфемерные решения.
В качестве примера, на протяжении существования моей компании Lokad мы прошли через шесть поколений прогностических движков. Положительные знания эфемерны в том смысле, что эти знания, эти решения, находятся под угрозой, когда появляется что-то лучшее, и вы просто отбрасываете это знание. В Lokad мы провели трудное упражнение по переписыванию нашей собственной технологии прогнозирования с нуля шесть раз с самого начала в 2008 году. Вот почему я говорю, что положительные знания очень эфемерны, потому что они быстро устаревают, поскольку появляются новые, лучшие решения.
Напротив, если вы посмотрите на отрицательные знания, это совершенно другая перспектива. Вы думаете в терминах грубых промахов, и тот вид интеллекта, который вы хотите захватить, - это уличный интеллект, тот, который помогает вам выжить на плохой улице ночью. Фокус здесь не столько на головоломках или вещах, которые очень сложно понять и включают передачу; это больше о том, чего вы не знаете или о запретах. Это не то, чего вы не знаете; это то, что люди не скажут вам, или то, что люди даже будут врать вам только потому, что хотят сохранить лицо. Отрицательные знания - это борьба против всех этих запретов, которые мешают вам видеть реальность такой, какая она есть.
С отрицательными знаниями мы не думаем о прогрессе; это мышление о выживании. Вы просто хотите выжить, чтобы сражаться еще один день. Это совершенно другая перспектива, и именно такое отрицательное знание компании инстинктивно ищут, когда они ищут очень опытного директора по цепочке поставок. Они хотят убедиться, что благодаря этому человеку компания проживет еще один день. Что может быть удивительным, так это то, что отрицательные знания обычно более долговечны. Здесь вовлечены преимущественно недостатки человеческой природы, и они не меняются со временем только потому, что появляется новая технология, подход или метод. Эти вещи остаются.
В заключение, я бы сказал, что отрицательные знания имеют первостепенное значение для всех сложных проблем, и цепочка поставок - только фокус интереса этой лекции, но это не единственная область, где можно применять отрицательные знания.
Анти-паттерны цепочки поставок - это всего лишь несколько примеров, но я уверен, что можно выделить десятки других, чтобы захватить проблемы, которые продолжают возникать в реальных цепочках поставок. Мы не можем надеяться захватить все через анти-паттерны, но я верю, что мы можем захватить значительную часть. После прочтения книги об анти-паттернах программного обеспечения, мое субъективное мнение было таково, что я получил эквивалент пятилетнего опыта в программной инженерии всего за 200 страниц. Моя надежда в том, что для коллекции анти-паттернов цепочки поставок мы также сможем повторить этот эффект, где кто-то сможет получить эквивалент пятилетнего опыта за гораздо меньшее время, возможно, всего несколько недель.
Это все для этой лекции. Следующая лекция будет посвящена оценке поставщиков, что является очень интересной проблемой. Современные цепочки поставок живут или умирают от программных продуктов, которые их поддерживают, и вопрос в том, как мы рассуждаем о этих программных продуктах и как мы выбираем правильные их поставщиков. Несмотря на то, что у меня было много конфликтов интересов, это интересная проблема, и вопрос в том, как мы можем иметь методологию, где даже если у всех людей есть предубеждения, мы можем получить некоторые непредвзятые результаты из метода.
Теперь я отвечу на вопросы.
Вопрос: Что является хорошим прогнозом в условиях вероятностной оптимизации и как измерить качество? Есть ли место для ручного обогащения?
Хороший вероятностный прогноз имеет метрики для вероятностной точности, но это, вероятно, не то, на что вы смотрите. В рамках экспериментальной инициативы по оптимизации вы захотите оптимизировать. Метрики, такие как перекрестная энтропия или правдоподобие, применяются к вероятностным прогнозам. Более важно то, что вы будете постепенно открывать, когда вы определите безумные решения. Прогноз - это всего лишь средство к достижению цели, которая заключается в принятии решения. Вам нужно обращать внимание на решения. Мы кратко затронули этот вопрос в предыдущей лекции об экспериментальной оптимизации. Процесс такой же для классических или вероятностных прогнозов. Если вы хотите иметь примеры вероятностных прогнозов в реальном мире, это будет подробно рассмотрено в последующих лекциях. Извините, что я немного отклонился в ответе на этот вопрос.
Вопрос: Что вы думаете о использовании ИИ (Исследование восхищения) для поддержки вашего ИИ (Искусственный интеллект)? Какие техники вы будете использовать для логического обнаружения больших наборов данных и почему конверсионные показатели снижаются, несмотря на хорошую общую производительность? Что нужно решить, чтобы устранить причину активности?
ИИ, как набор алгоритмов, в настоящее время в основном является глубоким обучением. Глубокое обучение - это набор техник, которые очень хорошо справляются с высоко неструктурированными данными. Вопрос, который вам действительно следует задать себе, - это как связать это с реальностью. В цепи поставок данные обычно очень разрежены. Большинство товаров в любом магазине продаются менее чем по одной единице в день. Большие наборы данных являются большими только в совокупности, когда вы смотрите на очень большую компанию с огромным количеством транзакций. Если вы смотрите на те гранулярности, которые действительно имеют значение, у вас не так много данных.
Исследование восхищения, с точки зрения методологий, на самом деле является экспериментальной оптимизацией, рассмотренной в предыдущей лекции.
Вопрос: Многие менеджеры не понимают силу науки о данных, и предоставление им вымышленных проблем - это безопасный путь. Если они не хотят углубляться в изучение науки о данных, каким альтернативным способом можно заставить их верить в науку о данных и подходы, основанные на принятии решений? Как начать с малого и расшириться в большое?
Во-первых, если у вас есть люди, которые не верят в определенную технологию, это вполне нормально. Возьмем, к примеру, Уоррена Баффетта. Он очень богатый инвестор, который всю жизнь инвестировал в компании, которые он понимает. Он инвестирует в компании с простыми бизнес-моделями, например, компании железнодорожного транспорта или компании по аренде мебели. Уоррен Баффетт сказал: “Мне не интересно понимать все эти технологии”. Например, когда люди спрашивали его, почему он не инвестирует в Google, Баффетт отвечал: “Я ничего не понимаю в том, что делает Google, поэтому, хотя это может быть хорошая инвестиция, я не настолько умный для этого. Я просто буду инвестировать в компании, которые я понимаю”.
Мой посыл в том, что для менеджмента я считаю полной иллюзией рисковать в областях, которые вы не понимаете. В какой-то момент, если вы не готовы приложить усилия, это просто не сработает. В этом случае срабатывает анти-паттерн Джедая - менеджмент не готов приложить никаких усилий, и они думают, что просто найм умных, молодых, интеллектуальных инженеров решит проблему. Если бы это было так, у Amazon не было бы такого успеха. Если бы традиционная розничная сеть могла просто нанять несколько инженеров, чтобы запустить интернет-магазин и конкурировать с Amazon, они бы все это сделали. До примерно 2005 года у этих компаний было значительно больше ресурсов и возможностей в области инженерии, чем у самого Amazon.
Проблема в том, что это иллюзия, и вот в чем суть отрицательных знаний - пролить свет на такого рода проблемы, которые повсеместны. Вот почему вам нужен привлекательный заголовок, чтобы донести проблему до менеджеров. Вы также не должны бояться узнавать новые вещи. Когда вы действительно берете хорошую часть новой технологии, она обычно не такая сложная. Не все является сверхтехническим; многие аспекты могут быть объяснены. Например, даже что-то вроде блокчейнов - половина из этих якобы суперпродвинутых технологий блокчейна могут быть объяснены 10-летним детям. Многие идеи, лежащие в основе этих технологий, на самом деле довольно просты. Есть масса случайных математических технических деталей, которые очень сложны, но это не суть проблемы.
Итак, мой ответ вам будет таким: если руководство хочет верить в сказки, в этой ситуации мало что можно сделать. Если руководство готово инвестировать в науку о данных, они также должны быть готовы потратить немного времени на понимание сути науки о данных. В противном случае это просто иллюзия.
Вот и все на сегодня. Большое спасибо, и следующая лекция состоится в тот же день, в среду, через две недели, в то же время. Увидимся тогда.
Ссылки
- ‘‘Антипаттерны: рефакторинг программного обеспечения, архитектур и проектов в кризисе’’. Уильям Дж. Браун, Рафаэль С. Мальво, Хейс В. “Скип” Маккормик, Томас Дж. Моубрэй, 1998
