Механическая симпатия: недостающий ингредиент в программном обеспечении цепочки поставок
Когда я начал работать над проблемами цепочки поставок почти двадцать лет назад, я ожидал, что основная сложность будет заключаться в физике: грузовики, суда, поддоны, контейнеры, производственные линии. Вместо этого я столкнулся с экранами, обновление которых занимало несколько секунд, ночными партиями, регулярно переходящими в утро, и «оптимизационными» механизмами, которые приходилось упрощать до уровня, когда они едва превосходили электронные таблицы.
Настоящее узкое место заключалось не в стали или бетоне. Это было программное обеспечение. Точнее, это было наше общее равнодушие к машине, на которой оно работает.
В моей книге Введение в цепочку поставок, я утверждаю, что современные цепочки поставок прежде всего являются механизмами принятия решений в условиях неопределенности. Качество этих решений зависит от качества программного обеспечения, которое их подготавливает, а само программное обеспечение, в свою очередь, ограничено характеристиками вычислительного оборудования — от кэш-памяти процессора до пропускной способности памяти.
За последнее десятилетие я пришёл к убеждению, что практика цепочки поставок не сможет существенно продвинуться дальше, если мы не разовьем то, что я называю механической симпатией: интуитивное понимание того, как на самом деле происходит вычисление, и готовность строить наши методы, исходя из этой реальности, вместо того чтобы её игнорировать.
Что я подразумеваю под «механической симпатией»
Это выражение впервые появилось в автоспорте. Хороший водитель не только отлично следует гоночной трассе, но и «чувствует», на что способен автомобиль, а на что нет. Он избегает резких манёвров, которые перегревают тормоза, прислушивается к звуку двигателя, чувствует, когда шины вот-вот потеряют сцепление. Он проявляет симпатию к машине.
В вычислительной технике эквивалентом является понимание того, что современный сервер — не волшебный, безупречно работающий калькулятор, выполняющий «операции в секунду» в абстрактном смысле. Это физический объект с особенностями: крошечные кэши, которые быстры, но малы, основная память, которая медленнее, диски, ещё медленнее, и сети с задержками, от которых не спрёшь. Разница между учётом этих ограничений и их систематическим игнорированием может обеспечить прирост производительности в один или два порядка.
Яркий пример этого можно увидеть в истории глубокого обучения. Ранние исследования нейронных сетей были одержимы биологическим вдохновением: нейроны, синапсы, правила обучения, звучащие как в нейронауке. Прорыв произошёл, когда исследователи отказались от попыток имитировать мозг и начали безжалостно оптимизировать алгоритмы под GPU и числовую стабильность. Выпрямлённые линейные единицы, мини-батчи, плотные слои, арифметика смешанной точности: многие из этих идей связаны меньше с нейронаукой и больше с учётом возможностей аппаратного обеспечения. Область получила развитие в тот момент, когда продемонстрировала механическую симпатию к кремнию.
Цепочка поставок, конечно, не связана с распознаванием изображений. Но она столь же вычислительно сложна и может извлечь не меньше выгоды из уважительного отношения к машине.
Цепочка поставок как вычислительная задача
О цепочках поставок часто говорят с точки зрения физических потоков: заводы, склады, грузовики и магазины. Менее очевидно то, что за каждым перемещаемым поддоном стоят десятки мелких решений: что купить, что произвести, сколько отправить, где хранить, по какой цене продавать, когда проводить распродажи, какой заказ отдавать приоритет.
Каждое из этих решений принимается в условиях неопределённости. Спрос может резко возрасти или упасть. Сроки поставок могут сдвигаться. Поставщики могут подвести. Транспортные мощности могут исчезнуть за одну ночь. Если мы хотим принимать эти решения систематически лучше, чем на основе человеческих догадок, нам нужны алгоритмы, которые рассматривают множество сценариев, а не только один прогноз; которые сравнивают варианты по ожидаемой прибыли, а не лишь по уровню обслуживания; которые переносят ограничения на всю сеть, а не рассматривают каждый склад или магазин по отдельности.
Всё это требует значительных вычислительных ресурсов. Вероятностный подход, который отслеживает тысячи жизнеспособных вариантов будущего и оценивает решения для каждого из них, выполнит гораздо больше арифметических операций, чем простая формула страхового запаса. Подход на уровне сети, объединяющий управление запасами, ценообразование и планирование мощностей, пропустит через машину гораздо больше данных, чем локальный расчёт точки повторного заказа.
Именно здесь механическая симпатия становится решающей. Если базовый стек программного и аппаратного обеспечения небрежен, если каждый запрос вызывает десятки обменов с транзакционной базой данных, если алгоритмы написаны таким образом, что нивелируют преимущества кэширования и параллелизма, то эти более сложные методы просто не укладываются в требуемое время. В итоге вы сжимаете проблему до размеров, подходящих под возможности машины, вместо того чтобы улучшать саму машину для решения реальной задачи.
Когда я вижу компанию, чей процесс «оптимизации» пополнения запасов должен начинаться в 18:00, чтобы завершиться к 6:00, я понимаю, что организация никогда всерьёз не будет экспериментировать с альтернативами. Каждая новая идея превращается в многонедельный проект, потому что один прогон занимает полдня. Экономика экспериментов рушится.
Основное мнение: аппаратное обеспечение как второстепенное соображение
Если вы изучите основные учебники по цепочке поставок, то найдёте обширные обсуждения сетевого проектирования, стратегий поставок, контрактов, политик управления запасами, видов транспорта и показателей эффективности. Вы также встретите главы об «информационных технологиях», описывающие ERP-системы, инструменты планирования и интеграцию. Чего практически никогда не встретишь, так это серьёзного обсуждения того, как на самом деле работает базовое вычислительное оборудование.
ИТ рассматривается как нейтральный инструмент. Сообщение, в общих чертах, таково: как только вы выбрали программное обеспечение и интегрировали ваши данные, вы можете сосредоточиться на проектировании процессов и управленческих рычагах. Внутренняя суть машины — как устроена память, как хранятся данные, как планируются вычисления — остаётся прерогативой поставщиков и технических специалистов.
Такая же парадигма пронизывает большинство корпоративных программ в нашей области. Системы планирования построены на транзакционных базах данных, которые изначально предназначались для бронирования заказов и обновления уровней запасов, а не для обработки миллиардов вероятностных сценариев за ночь. Архитектура обычно организована вокруг экранов и форм, позволяющих создавать, читать, обновлять и удалять записи. Дополнительные «оптимизационные модули» прикрепляются: прогнозирующий движок здесь, решатель маршрутов там, эвристика для управления запасами где-то ещё.
На первый взгляд всё это выглядит достаточно современно: веб-интерфейсы, облачное развертывание, API, возможно, даже «ИИ» в маркетинговых брошюрах. Однако под капотом вычислительное ядро часто испытывает дефицит ресурсов. Вычисления проходят через слои абстракции, которые фрагментируют данные, рассеивают нагрузку и нивелируют преимущества аппаратного обеспечения. Результатом становится программное обеспечение, которое с трудом справляется с объёмами данных сегодняшнего дня, несмотря на то, что работает на машинах, в тысячи раз быстрее, чем те, что были тридцать лет назад.
Никлаус Вирт как-то остро заметил, что программное обеспечение замедляется быстрее, чем аппаратное ускоряется. В цепочке поставок это можно увидеть напрямую: во многих крупных системах для открытия страницы «подробностей» по одной комбинации продукта и места требуется несколько секунд, хотя базовое оборудование должно просматривать миллионы таких записей за то же время. Мы сумели поглотить почти весь прогресс аппаратного обеспечения из-за слоев неэффективности.
Когда неэффективность закладывается в архитектуру, последствия оказываются не только техническими, но и доктринальными. Если ваша платформа не может позволить себе отслеживать тысячи сценариев для каждого артикула, то вы будете склонны использовать методологии, требующие лишь одного прогноза. Если ваш механизм не может оценивать финансовое влияние решений на уровне всей сети, вы обратитесь к локальным правилам и ключевым показателям эффективности, которые можно рассчитывать изолированно. «Теоретические» ограничения быстро превращаются в «практическую» догму.
Что меняется, когда вы заботитесь о машине
Что происходит, если мы перевернём ситуацию? Допустим, мы исходим из предположения, что машина имеет значение.
Во-первых, мы начинаем разрабатывать потоки данных с учётом локальности. Вместо того чтобы разбросать информацию по десяткам таблиц и просить базу данных собирать её заново для каждого вычисления, мы организуем данные так, чтобы один проход по памяти обеспечивал всё, что требуется алгоритму. Это само по себе может повысить производительность на целый порядок.
Во-вторых, мы предпочитаем пакетные и векторизированные операции вместо посрочной обработки. Аппаратное обеспечение исключительно хорошо справляется с выполнением одной и той же операции многократно на больших массивах. Оно плохо приспособлено для ответа на тысячи мелких, несвязанных запросов, требующих прыжков по памяти и сети. Когда аналитическая часть системы цепочки поставок представлена в виде цельной программы, а не как совокупность транзакций, управляемых формами, становится гораздо легче использовать эту мощь.
В-третьих, мы рассматриваем всю цепочку принятия решений — от исходных данных до величин, указанных в заказах на покупку и списках для комплектации — как то, что можно и нужно профилировать, оптимизировать и со временем перестраивать. Мы перестаём считать «модель» чёрным ящиком и начинаем воспринимать рецепт как программное обеспечение. Именно это позволило таким областям, как компьютерная графика и научные расчёты, эволюционировать от медленных прототипов до промышленных инструментов: инженеры годами устраняли неэффективность на каждом уровне.
Прямое преимущество — это скорость. Вычисление, которое раньше занимало шесть часов, теперь может занимать шесть минут или шесть секунд. Но более глубокое преимущество заключается не в самой цифре, а в том, что позволяет эта скорость. Если ваша команда сможет запустить сотню вариантов политики пополнения запасов за один день вместо одного варианта в неделю, они начнут исследовать ранее немыслимые идеи. Они будут совершенствовать модели в ответ на сбои, проверять альтернативные предположения и постепенно расширять границы экономических возможностей.
Это не гиковская тщеславие, это экономика
Некоторые читатели могут беспокоиться, что всё это звучит как одержимость инженера элегантностью ради самой элегантности. Какая разница, сколько кэш-промахов совершает алгоритм, если полки заполнены, а грузовики отправляются вовремя?
Ответ в том, что неэффективность не бывает бесплатной. В эпоху облачных вычислений за неё приходится платить дважды.
Вы платите напрямую, в виде избыточной инфраструктуры. Если ваше программное обеспечение требует в десять раз больше вычислительных мощностей и памяти, чем необходимо для получения тех же решений, вы заплатите в десять раз больше своему облачному провайдеру или за оборудование — или же согласитесь на выполнение расчётов в десять раз дольше, что является другой формой затрат.
Вы также платите косвенно, через ослабление логики принятия решений. Поскольку неэффективные системы с трудом способны рассчитывать сложные политики в больших масштабах, поставщики упрощают математику, чтобы соответствовать возможностям машины. Они сводят вероятностные распределения к одним числам. Они разъединяют процессы, которые в реальности тесно связаны, чтобы их можно было рассчитывать раздельно. Они прячут грубые приближения за блестящими панелями управления. Вы, возможно, никогда не увидите эти упрощения, но почувствуете их в виде избыточного страхового запаса, упущенных продаж и хрупкой реакции на потрясения.
В отличие от этого, механическая симпатия позволяет направлять ваш вычислительный бюджет туда, где это имеет наибольшее значение: на исследование неопределённости и компромиссов. Эффективная система способна симулировать тысячи вариантов будущего и выбирать решения, которые максимизируют ожидаемую прибыль при контроле риска, вместо того чтобы полагаться на эмпирические правила. Она может позволить себе частые перерасчёты, чтобы решения оставались актуальными при поступлении новых данных. Она может учитывать всю сеть целиком, а не оптимизировать каждый узел в изоляции.
В этом смысле механическая симпатия — это не технический выбор, а экономическая позиция. Она говорит: мы не будем тратить ограниченные вычислительные ресурсы на лишнюю накладку; мы будем использовать их для расчётов, которые действительно изменяют наши денежные потоки.
Чего я ожидаю от лидеров цепочки поставок
Ничто из этого не означает, что каждый руководитель цепочки поставок должен становиться системным программистом. Но я действительно считаю, что руководящим командам необходимо иметь базовое представление о масштабе и направлении. Не нужно разрабатывать движки, чтобы понять, что грузовик, потребляющий в три раза больше топлива, чем его коллеги на том же маршруте, — это проблема. Не нужно быть конструктором микросхем, чтобы осознать, что система, на выполнение расчёта, который мог бы уложиться в секунды, тратит часы.
При выборе программного обеспечения или поставщика вам следует не стесняться задавать вопросы, такие как:
Как часто мы можем реалистично пересчитывать все ключевые решения для всей сети?
Что произойдёт, если мы удвоим количество артикулов или точек — увеличится ли время выполнения вдвое или оно резко возрастёт?
Какое оборудование требуется этой платформе для обработки наших данных, и насколько мы уверены, что эти требования не вырастут в ближайшие два года?
Если ответы уклончивы или никто в комнате не может даже прикинуть порядок величин, значит, что-то не так. В разговоре на LokadTV о вычислительных ресурсах я сравнил это с базовой географией: вам не нужно знать точную высоту каждой горы, но вы должны понимать, проходит ли данная дорога через Альпы или через равнину.
Аналогично, внутренним командам следует поощрять рассматривать свою аналитическую работу как код, который можно профилировать и улучшать, а не как статичные «модели», которые могут быть либо правильными, либо неправильными. Умение анализировать производительность является частью профессиональной компетенции, так же как способность анализировать экономику на единицу продукции является частью финансовой грамотности.
Иное понимание симпатии
В конечном счете, механическая симпатия — это форма уважения.
Это уважение к машине: признание того, что наши серверы не бесконечны, что их особенности и ограничения реальны, и что игнорировать их опасно.
Это уважение к людям, которые зависят от этих машин: планировщикам, которым нужны своевременные и надёжные рекомендации; менеджерам, которым необходимо пространство для экспериментов; руководителям, которые должны выделять капитал, исходя из того, что сообщает программное обеспечение.
И это уважение к самой дисциплине цепочки поставок. Если мы утверждаем, что наша область посвящена принятию лучших решений в условиях неопределённости, мы не можем безразлично относиться к качеству оборудования, которое производит эти решения. Мы обязаны перед собой — и перед компаниями, которые нам доверяют — относиться к вычислительным ресурсам так же серьёзно, как к складам и автопаркам.
Общее мнение заключалось в том, чтобы рассматривать внутреннюю архитектуру аппаратного и программного обеспечения как закулисное дело, которое «возьмёт на себя ИТ». Я считаю, что это мнение исчерпало свою полезность. Чем больше наши цепочки поставок зависят от алгоритмов и данных, тем сильнее нам необходимо поставить машину в центр внимания.
Механическая симпатия не означает превращение каждого планировщика в программиста. Это означает развитие на всех уровнях осознанного любопытства к тому, как действительно работают наши инструменты – и отказ принимать медлительность, непрозрачность и расточительность как нечто неизбежное.
