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. Я не буду читать чат во время лекции; однако в самом конце лекции я вернусь к чату для сессии вопросов и ответов.
Сегодняшняя тема — что именно получает компания, нанимая опытного директора по цепочкам поставок с, возможно, двадцатилетним или тридцатилетним опытом. Что именно ищет компания, и можем ли мы, хоть в небольшой степени, воспроизвести приобретение этого опыта за гораздо более короткое время? Именно об этом и говорят негативные знания.
Когда мы рассматриваем очень опытного человека, того, кто работает в сфере уже два десятилетия, мы действительно ожидаем, что он воспроизведёт решения, процессы или технологии, которые он внедрял одна-две декады назад в других компаниях? Вероятно, нет. Хотя такое может случиться в незначительной степени, я подозреваю, что это обычно крайне незначительная причина.
Когда вы ищете очень опытного человека, цель не в том, чтобы воспроизвести то, как всё делалось раньше. Главная ценность состоит в том, чтобы привлечь того, кто умеет избегать всевозможных ошибок и обладает опытом, чтобы гарантировать, что множество наивных и плохих идей не будут реализованы в вашей компании. Существует поговорка: в теории и на практике всё одно и то же, но на практике — нет. Именно такова суть негативных знаний.
Мое предложение для вас заключается в том, что плохие бизнес-идеи повсюду. Под плохими я подразумеваю идеи, которые, если реализовать их, окажутся совершенно нерентабельными для компании. Чтобы проиллюстрировать это, я только что ввел запрос “smart refrigerators” в поисковик патентов Google. 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% уровне обслуживания, так как это абсолютно несбалансированно с экономической точки зрения и неустойчиво. Попытки двигаться в этом направлении приведут лишь к вреду для компании. Решение заключается во внедрении здоровой дозы экономических драйверов в практику управления цепочками поставок.
Теперь третий антипаттерн, Инициация Джедая, проявляется, когда высшее руководство многих крупных компаний постоянно оказывается под давлением СМИ из-за непрекращающегося потока модных терминов. Эти ключевые слова включают искусственный интеллект, блокчейн, облачные вычисления, большие данные, IoT и так далее. Лидеры мнений утверждают, что если их компания не адаптируется к этим трендам, она устареет. Существует постоянный страх упустить что-то важное, который действует как мощная сила, оказывающая постоянное давление на высшее руководство большинства крупных компаний, управляющих большими цепочками поставок.
Симптомы Инициирования Джедая можно наблюдать, если в вашей компании есть подразделение с молодыми, энтузиастичными инженерами, в должностных названиях которых присутствуют модные слова, такие как исследователи искусственного интеллекта, инженеры блокчейна или data scientists. Девиз — “овладей силой”, где сила является модным словом, вызывающим интерес в данный момент. Руководство нанимает, возможно, молодых или неопытных сотрудников и поручает им сделать что-то великое для компании, не вникая в технические аспекты этих концепций.
В итоге эти команды создают интересные прототипы, которые в конечном счете не приносят реальной пользы для компании. В результате, несмотря на то, что всё начиналось с идеи, что компания будет революционизирована в соответствии с модным словом дня, устоявшиеся методы и технологии остаются доминирующими и не меняются под влиянием модного слова или дополнительной команды, созданной вокруг него.
Что касается анекдотических данных, сегодня, в 2021 году, подавляющее большинство компаний с командой по data science получает ровно нулевую отдачу от инвестиций. Команда data science создает шикарные прототипы на Python с использованием открытых библиотек, которые выглядят очень круто, но по практической окупаемости для подавляющего большинства рынка — это ровно ноль. Именно на такую инициативу погружается высшее руководство, словно на Инициацию Джедая: они читают в прессе, что data science — это новый тренд, поэтому нанимают команду data science. Как маленький анекдотический факт, я замечаю, что эти команды не только довольно молоды и неопытны, но и остаются таковыми со временем. Это происходит потому, что текучесть кадров очень высока. Можно иметь компанию, которая является очень стабильной и надежной, где средняя продолжительность работы составляет обычно от пяти до десяти лет, за исключением команды data science, где люди в среднем остаются 18 месяцев. Одна из причин, по которой из этих команд ничего ценного не получается, заключается в том, что люди приходят, создают несколько прототипов, а затем уходят. Для компании это не приводит к созданию накопленного капитала и никогда по-настоящему не трансформирует компанию.
Что касается рефакторинга этого решения, то сначала единственный выход — вести за собой своим примером. Если вы действительно хотите заниматься data science, то высшее руководство должно быть хорошо осведомлено в этой области. Например, Джефф Безос демонстрировал знакомство с передовыми методами машинного обучения своего времени. Amazon может добиться большого успеха, используя машинное обучение, но это происходит потому, что высшее руководство очень хорошо разбирается в нюансах. Ведение за собой примером имеет решающее значение.
Во-вторых, вы должны убедиться, что, нанимая этих молодых, энтузиастичных и потенциально талантливых инженеров, вы сталкиваете их с реальными проблемами, а не с мета-проблемами. Это должно быть связано с реальностью. Это возвращает нас к моей предыдущей лекции об эмпирической, экспериментальной оптимизации. Если вы нанимаете data scientist для сегментации клиентов или для проведения лучшего ABC-анализа для вашей компании, это не реальные проблемы. Это просто выдуманные числа. Если же вы нанимаете этих людей и поручаете им реальное пополнение запасов, делая их ответственными за точные количества, которые нужно пополнить от ряда поставщиков, то это действительно реально. Именно поэтому, десятилетие назад, Lokad перешёл внутренне от специалистов по data science к специалистам по цепям поставок. Суть заключалась в том, чтобы иметь совершенно иной подход и уйти от этого анти-паттерна Инициации Джедая.
Невклидовский ужас. В этом контексте у вас есть компания, которая управляет обширной цепочкой поставок, и ИТ-инфраструктура крайне сложна. Существуют различные корпоративные программные продукты, такие как ERP, WMS и EDI, которые сами по себе являются сложными. Затем добавляется весь «клей», связывающий эти компоненты, и в итоге общая картина оказывается ошеломляюще сложной. Как же понять, что вы действительно находитесь в компании, которая столкнулась с неадаптированным решением? Какие признаки этого? Признаки таковы, что каждый в компании ощущает, что в ИТ-подразделении царит вопиющая некомпетентность. Сотрудники ИТ выглядят перегруженными и словно не понимают, что происходит в системе, которую им предстоит управлять и поддерживать. Еще один симптом — вы видите ИТ-проблемы, которые ежедневно влияют на производство. Это ключевые признаки неадаптированного решения.
Последствие наличия неадаптированной ИТ-инфраструктуры заключается в том, что изменения, которые необходимо внести в компанию, обычно требуют изменений и в ИТ-системах. Современные цепочки поставок в значительной степени определяются их программными компонентами. Все эти изменения происходят очень медленно, и это всегда трудоёмкий процесс, при котором даже незначительные изменения занимают вечность. При любом изменении обычно возникают многочисленные откаты. Как говорится, два шага вперёд — три шага назад, затем снова два шага вперёд и один шаг назад. Изменения происходят не только медленно, но и сопровождаются постоянными регрессиями. Ситуация на самом деле не улучшается с течением времени; в лучшем случае, она стагнирует.
Что касается корневых причин, то руководство на самом деле не обращает внимания на мелочи, а нериск-техническое руководство не интересуется всеми этими ИТ-системами. Это приводит к подходу, который я называю инкрементализмом, при котором любые изменения, которые они хотят внести в ИТ-систему компании, например, инициируются цепочками поставок. Когда необходимо внести изменения, руководство всегда говорит: “Пожалуйста, выберите самый простой путь, тот, который требует минимальных усилий и времени, чтобы мы могли как можно быстрее увидеть результаты”. Вот в чём суть инкрементализма.
Я считаю, что инкрементализм является очень опасной корневой причиной. Проблема инкрементализма заключается в том, что это буквально смерть от тысячи порезов. Каждое отдельное изменение, внесённое в систему, делает её немного более сложной, немного менее управляемой и немного труднее для тестирования. Хотя каждое отдельное изменение само по себе незначительно, когда вы складываете десятилетие, полное десятков ежедневных изменений в ИТ-системах, вы получаете океан сложности. Каждое изменение сделало систему более сложной, и общая картина полностью теряется. Спустя десятилетие вы оказываетесь с массивной, запутанной системой, которая выглядит безумной.
Как небольшой анекдотический факт, можно заметить, что до сих пор существуют очень крупные компании в сфере электронной коммерции, где, как потребитель, вы регулярно сталкиваетесь с их периодическими сбоями. Такое никогда не должно происходить. В компании электронной коммерции в 2021 году время работы должно быть таким, чтобы допустимый простой составлял около 10 минут в год. Каждая секунда простоя — это упущенная возможность. Проектирование программного обеспечения для корзины покупок в 2021 году уже не является ракетостроением; это на самом деле довольно простое ПО с точки зрения корпоративного программного обеспечения. Нет никаких причин не иметь постоянно работающую систему. Однако реальность такова, что когда вы видите, что электронная коммерция выходит из строя, обычно дело не в корзине покупок, а в неадаптированном решении, находящемся непосредственно за электронной коммерцией. Простои в электронной коммерции являются лишь отражением проблемы, случившейся где-то в ИТ-инфраструктуре.
Если мы хотим рефакторить неадаптированное решение, нам следует перестать искать самый простой способ внесения изменений. Мы должны стремиться не к лёгкому решению, а к простому решению. Простое решение отличается от лёгкого в одном ключевом моменте: оно делает всю картину немного аккуратнее и разумнее, что облегчает внесение дальнейших изменений в будущем. Вы можете сказать: “Но это же чисто технический вопрос, так что это работа ИТ”. Я бы ответил: нет, абсолютно не так. Это, во многом, проблема цепей поставок. Принятие простого решения — это не вопрос наличия простого решения с точки зрения ИТ; это вопрос наличия простого решения с точки зрения цепи поставок.
Простота решения и его предполагаемый эффект, заключающийся в том, чтобы облегчить внедрение будущих изменений, зависят от вашего плана развития. Какие будущие изменения вы хотите внести в свою ИТ-инфраструктуру? ИТ-подразделению, как правило, не хватает времени, чтобы стать экспертами по цепям поставок и точно знать, в каком направлении вы хотите развивать компанию через десятилетие с точки зрения исполнения цепей поставок. Именно управление цепями поставок должно обладать этим видением и направлять развитие, возможно, с поддержкой ИТ, в направлении, где изменения со временем становятся всё проще в реализации.
Наконец, как последний анти-паттерн на сегодня, защитник дьявола. Контекст обычно представляет собой крупную компанию, столкнувшуюся с серьёзными проблемами в цепях поставок, которая решила обратиться к крупному поставщику, вложив значительные средства. Инициатива запускается, и через несколько месяцев, обычно около шести, поставщик почти ничего не может показать. Большие деньги были направлены поставщику, а итоговые результаты почти отсутствуют. Кстати, в 2021 году шесть месяцев — это много времени. Если у вас есть программная инициатива, которая не приносит ощутимых, промышленного уровня результатов за шесть месяцев, вам следует сильно беспокоиться, потому что, по моему опыту, если вы не можете предоставить ощутимые результаты за шесть месяцев, инициатива обречена, и вы никогда не получите положительную отдачу от инвестиций для компании.
Что происходит: руководство видит, как проект задерживается, и итоговые результаты почти отсутствуют. Высшее руководство, вместо того чтобы становиться всё более агрессивным по отношению к технологическому поставщику и занимать передовые позиции, внезапно меняет сторону и становится крайне защитником поставщика. Это очень загадочно. Вы запускаете крупную инициативу, вкладываете много денег в другую компанию, а инициатива движется вперёд, но плохо и дает скудные результаты. Вместо того чтобы признать, что инициатива на самом деле проваливается, руководство удваивает усилия и начинает защищать поставщика, что крайне странно. Как будто действует некий синдром Стокгольма, когда кто-то причиняет вам вред, но если вред достаточно велик, в какой-то момент вы начинаете симпатизировать этим людям.
Руководство и сама инициатива становятся слишком велики, чтобы потерпеть неудачу, и в результате тратится огромное количество денег и упускается масса возможностей, особенно с точки зрения времени. По мере продвижения инициативы теряются деньги, но что ещё важнее, теряется время — шесть месяцев, один год, два года. Реальная цена — это время. В качестве анекдотического свидетельства можно регулярно читать в прессе о крупномасштабных провалах при внедрении ERP-систем для проектов, которые длятся почти десятилетие или иногда от пяти до десяти лет. Вы думаете: как может быть проект на пять лет? Ответ: люди продолжают удваивать усилия в этом проекте, и требуется буквально годы, чтобы наконец признать, что это был полный провал и что он никогда не сработает.
Ещё один анекдотический факт: будучи внутри компании и наблюдая за многолетними, эпическими провалами внедрения ERP, часто случается, что проект прекращается не потому, что люди соглашаются с тем, что поставщик действительно провалился. Сценарий таков, что в какой-то момент высшее руководство, принимавшее решение о привлечении поставщика, просто переходит в другие компании. Когда почти все те, кто изначально участвовал в решении привлечь крупного поставщика, покидают компанию, оставшиеся, не чувствуя такой приверженности к этому поставщику, коллективно соглашаются закрыть проект и закончить дело.
Что касается рефакторенного решения, я считаю, что компании должны быть более терпимыми к неудачам. Необходимо строго относиться к проблемам, но мягко — к людям. Если вы культивируете культуру, в которой говорится: “Нужно сделать всё правильно с первого раза”, это очень вредно, потому что это означает, что неудач станет не меньше. Это недопонимание человеческого разума и природы человека думать, что если у вас культура, допускающая неудачи, то на самом деле будет больше неудач. Да, будет немного больше мелких неудач, но при этом люди будут склонны признавать ошибки и двигаться дальше. Если же, наоборот, у вас культура “сначала сделай правильно”, тогда практически никто не может потерять лицо. Поэтому даже когда существует нечто совершенно дисфункциональное, инстинкт самосохранения у вовлечённых людей заключается в том, чтобы удваивать усилия в том, что не работает, лишь бы сохранить лицо и, возможно, перейти в другую компанию, чтобы не столкнуться с последствиями своих ошибок.
Подводя итог, можно сказать, что существует положительное знание в противовес отрицательному знанию. Положительное знание, по сути, связано с решением проблем; это своего рода интеллект на уровне PhD, способный решать головоломки и переходить от одного решения к лучшему. Можно оценить, что одно решение лучше другого, и вершиной такого мышления является достижение оптимального решения. Однако то, что люди думают, что ищут — оптимальные решения, которые являются абсолютно действительными и бессмертными — на деле оказываются очень эфемерными решениями.
Например, за время существования моей компании Lokad мы прошли через шесть поколений движков прогнозирования. Положительное знание эфемерно в том смысле, что это знание, это решение, подвергается риску, когда появляется что-то лучшее, и вы просто отказываетесь от него. В Lokad мы прошли через утомительное упражнение по полномасштабному переписыванию нашей технологии прогнозирования с нуля шесть раз с самого начала в 2008 году. Именно поэтому я говорю, что положительное знание очень эфемерно, поскольку оно быстро устаревает, когда появляются новые, лучшие решения.
Наоборот, если вы посмотрите на отрицательное знание, то это совершенно другая перспектива. Вы думаете о роковых ошибках, и тот тип интеллекта, который вы хотите заполучить, — это уличный ум, способный помочь выжить на опасной улице ночью. Главное внимание уделяется не головоломкам или вещам, которые очень сложно понять и которые требуют переноса; речь идёт о том, чего вы не знаете, или о табу. Дело не в том, чего вы не знаете, а в том, что люди не расскажут вам, или в том, что люди даже солгут, лишь бы сохранить лицо. Отрицательное знание заключается в борьбе против всех этих табу, мешающих увидеть реальность такой, какая она есть.
При негативном знании мышление не направлено на прогресс; это мышление выживания. Вы просто хотите выжить, чтобы сражаться ещё один день. Это совершенно иной взгляд, и именно такого рода подход инстинктивно ищут компании, нанимая опытного директора по цепочке поставок. Они хотят быть уверены, что благодаря этому человеку компания проживёт ещё один день. Возможно, удивительно, но негативное знание оказывается гораздо более устойчивым. Это по сути те недостатки человеческой природы, которые присутствуют, и они не меняются со временем только потому, что появилась новая технология, подход или метод. Эти вещи останутся с нами.
В заключение, я бы сказал, что негативное знание имеет первостепенное значение для всех сложных проблем; цепочка поставок — лишь область интереса данной лекции, но это не единственная сфера, где можно применять негативное знание.
Антипаттерны в цепочке поставок — это лишь несколько примеров, но я уверен, что можно выделить десятки других, которые позволят зафиксировать проблемы, постоянно возникающие в реальных цепочках поставок. Мы не можем надеяться охватить всё с помощью антипаттернов, но я верю, что сможем уловить значительную их часть. Прочитав книгу об антипаттернах в области программного обеспечения, по моему субъективному мнению, я получил эквивалент пяти лет опыта в разработке ПО всего за 200 страниц. Надеюсь, что для сборника антипаттернов цепочки поставок мы также сможем воспроизвести этот эффект, когда кто-то сможет получить опыт, равный примерно пяти годам, за гораздо более короткий промежуток времени, возможно, всего за несколько недель.
На этом всё для этой лекции. Следующая лекция будет посвящена оценке поставщиков, и это очень интересная проблема. Современные цепочки поставок живут или умирают благодаря программным продуктам, которые их поддерживают, и вопрос в том, как мы анализируем эти программные продукты и выбираем правильные решения и нужных поставщиков. Несмотря на то, что у меня достаточно конфликтов интересов, это интересная проблема, и вопрос в том, как мы можем создать методологию, при которой, даже если у всех людей есть предвзятость, мы сможем добиться определённых объективных результатов.
Теперь я отвечу на вопросы.
Вопрос: Что составляет хороший прогноз в условиях вероятностной оптимизации и как измерить его качество? Есть ли место для ручного обогащения данных?
Хороший вероятностный прогноз имеет метрики для оценки вероятностной точности, но, вероятно, это не то, на что вы обращаете внимание. В рамках инициативы по экспериментальной оптимизации вам нужно будет оптимизировать. Метрики, такие как перекрестная энтропия или вероятность, применимы к вероятностным прогнозам. Более того, вы постепенно обнаружите аспекты, выявляющие неадекватные решения. Прогноз — это всего лишь средство для достижения цели, которой является решение. Вам следует уделять внимание именно решениям. Мы кратко коснулись этого в предыдущей лекции об экспериментальной оптимизации. Процесс одинаков как для классических, так и для вероятностных прогнозов. Если вам понадобятся реальные примеры вероятностных прогнозов, эта тема будет подробно рассмотрена в последующих лекциях. Прошу прощения за некоторое отклонение при ответе на этот вопрос.
Вопрос: Что вы думаете о применении ИИ (позитивное исследование) для поддержки вашего ИИ (искусственного интеллекта)? Какие техники вы будете использовать для логического анализа больших наборов данных, и почему коэффициенты конверсии снижаются, несмотря на хорошую общую производительность? Как бороться с причиной этой активности?
ИИ, как совокупность алгоритмов, в настоящее время в основном основан на глубоком обучении. Глубокое обучение — это набор техник, которые отлично справляются с крайне неструктурированными данными. Настоящий вопрос, который вы должны себе задать, заключается в том, как связать это с реальностью. В цепочке поставок данные, как правило, очень разрежены. Большинство товаров в любом магазине продаются менее чем одной единицей в день. Большие наборы данных оказываются таковыми только в совокупности, если рассматривать очень крупную компанию с огромным количеством транзакций. Если же рассматривать детали, которые действительно имеют значение, данных у вас оказывается не так много.
Позитивное исследование, с точки зрения методологий, на самом деле сводится к экспериментальной оптимизации, обсуждавшейся в предыдущей лекции.
Вопрос: Многие менеджеры не понимают силу data science, и предоставление им фиктивных проблем считается безопасным путём. Если они не хотят вникать в изучение data science, какой альтернативный способ заставит их поверить в data science и подход «сначала решение»? Как начать с малого и затем масштабировать?
Для начала, если есть люди, которые не верят в ту или иную технологию, это вполне нормально. Возьмём, к примеру, Уоррена Баффета. Он — очень состоятельный инвестор, который всю свою жизнь инвестировал в компании, которые понимал. Он вкладывается в компании с простыми бизнес-моделями, такими как железнодорожные перевозки или компании по лизингу мебели. Уоррен Баффет сказал: “Мне не интересно разбираться во всех этих технологиях.” Например, когда его спрашивали, почему он не инвестировал в Google, Баффет ответил: “Я ничего не понимаю в том, чем занимается Google, так что, пусть это и хорошее вложение, я недостаточно умен для этого. Я просто буду инвестировать в компании, которые понимаю.”
Моя мысль такова: для руководства ввязываться в области, которые вы не понимаете, — это полное заблуждение. В какой-то момент, если вы не готовы приложить усилия, это просто не сработает. Это и есть антипаттерн «джедая» — руководство не готово приложить усилия и считает, что простого найма умных, молодых, талантливых инженеров достаточно для решения всех проблем. Если бы всё было так, успех Amazon был бы невозможен. Если бы традиционной розничной сети компании достаточно было нанять нескольких инженеров для запуска интернет-магазина и конкурировать с Amazon, они бы все так поступили. До примерно 2005 года у этих компаний было значительно больше инженерных ресурсов и возможностей, чем у самого Amazon.
Проблема в том, что это заблуждение, и именно об этом говорит негативное знание — освещении проблем, которые встречаются повсеместно. Вот почему вам нужен запоминающийся заголовок, чтобы донести суть проблемы до менеджмента. Также не стоит бояться учиться новому. Если вы действительно извлечёте лучшее из новой технологии, она обычно не так сложна. Не всё является сверхтехническим; многие элементы можно объяснить. Например, даже такие технологии, как блокчейны — половину из этих, якобы, сверхсовременных технологий блокчейна можно объяснить десятилетнему ребёнку. Многие идеи, лежащие в их основе, на самом деле довольно просты. Существует масса случайных математических технических нюансов, которые очень сложны, но это не суть проблемы.
Таким образом, мой ответ таков: если руководство хочет верить в сказки, в такой ситуации мало что можно сделать. Если же руководство готово инвестировать в data science, оно должно также быть готово уделить немного времени на понимание того, что такое data science. В противном случае — это чистое заблуждение.
На сегодня всё. Большое спасибо, и следующая лекция состоится в тот же день, в среду, через две недели, в то же время. До встречи.
Ссылки
- ‘‘AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis’’. Вильям Дж. Браун, Рафаэль К. Малво, Хэйс У. “Skip” McCormick, Томас Дж. Мowbray, 1998
