Холимизирование: Почему оптимизация недостаточна
На протяжении большей части моей карьеры мне говорили, что «оптимизация» — это решение. Если бы только мы могли правильно сформулировать модель, снабдить её достаточным количеством данных и отпустить мощный решатель на волю, машина спокойно выдавала бы наилучшие возможные решения.
Однако в реальных цепочках поставок это обещание редко сбывается. Компании внедряют сложное программное обеспечение, настраивают бесчисленное множество параметров и всё равно оказываются заняты тушением проблем, связанных с отсутствием запасов, избыточными остатками и нервными планировщиками, которые больше не доверяют системе. Математика внутри «черного ящика» может быть прекрасной; решения на складе зачастую таковыми не являются.
В Введении в цепочку поставок, особенно в главах, посвященных решениям и числовым рецептам, я утверждал, что настоящая проблема заключается не в недостатке решателей, а в отсутствии адекватной рамки вокруг самой оптимизации. В этом эссе я хочу пойти еще дальше и дать этому понятию имя: холимизирование, а также глагол холимизировать, образованный сокращением от «целостной оптимизации».
Когда оптимизация основана на неправильном вопросе
Классическая оптимизация в своей простой форме начинается с очень заманчивой постановки:
«Скажите мне, что вы хотите максимизировать или минимизировать, перечислите ограничения, и я найду наилучшее решение.»
На доске это кажется вполне разумным. Но в цепочке поставок такое утверждение скрывает почти всё, что действительно имеет значение.
Что именно мы «максимизируем»? Прибыль в этом месяце? За год? Рост на протяжении нескольких лет? Удовлетворение клиентов в каком-то не до конца измеримом смысле? Устойчивость к сбоям? Или их сочетание?
Какие именно существуют ограничения? Формальные, такие как мощности и сроки поставок, или также неофициальные, например, «эта команда склада не способна реально обработать более 5000 поступающих коробок в день» или «этот станок нельзя перезагружать дважды за неделю»?
И как мы должны измерять ущерб? Является ли отсутствие товара худшей проблемой, чем распродажа по сниженной цене? Насколько хуже, в денежном выражении, и для каких продуктов?
Когда мы внедряем классический оптимизационный движок в цепочку поставок, мы вынуждены отвечать на эти вопросы, кодируя их — явно или неявно — в целевой функции и наборе ограничений. Как только мы это делаем, решатель действительно находит «оптимальные» решения относительно этого кодирования. К сожалению, если кодирование даже немного не соответствует реальности, мы получаем неверные решения ещё быстрее.
Я видел множество вариантов одной и той же истории. Ритейлер внедряет новую систему пополнения запасов, которая с гордостью максимизирует «уровень сервиса» с учётом затрат на запасы и логистику. На бумаге количество отсутствия товара сокращается, но магазины в итоге получают слишком много медленно оборачиваемых размеров и цветов, которые не интересуют покупателей. Производитель устанавливает продвинутую систему планирования, оптимизирующую производственные графики на основе упрощённой модели мощностей; в итоге план выглядит элегантно в интерфейсе, но завод вынужден импровизировать обходные пути, поскольку модель не учитывает критические узкие места на производственной площадке.
В каждом из этих случаев оптимизация как таковая работает. Компьютер делает именно то, что мы от него требовали. Проблема в том, что мы задали неправильный вопрос.
Название отсутствующей дисциплины
Понятие, которое я хочу ввести, выглядит следующим образом:
Холимизирование (сущ.) – Дисциплина целостной оптимизации для сложных, развивающихся систем, где основным объектом проектирования является сама рамка оптимизации: цели, ограничения, семантика данных и грамматика принятия решений. Холимизирование рассматривает оптимизацию как итеративный, экспериментальный процесс, в котором целевая функция, модель и инструментарий развиваются совместно под влиянием обратной связи из реального мира.
Холимизировать (гл.) – Организовывать такой процесс: неоднократно формировать рамки, снабжать систему инструментарием, оптимизировать и рефакторить её, чтобы она оставалась в соответствии с экономической реальностью и намерениями организации.
Оптимизация в узком смысле фокусируется на внутреннем цикле: при заданной цели и фиксированном представлении мира находить решения, экстремизирующие эту цель. Холимизирование же концентрируется на внешнем цикле: как мы формулируем цель, как представляем мир, как обеспечиваем систему инструментами и как всё это меняется со временем.
Другими словами, оптимизация отвечает на вопрос: «Что является наилучшим, если предположить, что мир выглядит так?» Холимизирование же задаётся вопросом: «Смотрим ли мы на мир так, чтобы понятие «наилучшее» имело хоть какой-то смысл?»
Это не абстрактный философский вопрос. В запутанной, развивающейся среде, такой как цепочка поставок, вопрос, который мы оптимизируем, постоянно меняется прямо у нас под ногами. Рынки сдвигаются, ассортимент обновляется, каналы появляются и исчезают, регулирования эволюционируют, а внутренние приоритеты переносятся. Если рамка оптимизации остаётся неизменной, пока мир вокруг неё меняется, расхождение между тем, что считается «оптимальным» на экране, и тем, что разумно в реальности, неуклонно растёт со временем.
Холимизирование — это то название, которое я предлагаю для дисциплины, рассматривающей саму рамку как первостепенный объект работы.
Что означает холимизировать цепочку поставок
Давайте конкретизируем это на примерах из цепочки поставок, ведь именно там я провёл большую часть своего времени.
Представьте себе модного ритейлера, который хочет «улучшить сервис» в магазинах. Если рассматривать оптимизацию в узком смысле, мы могли бы начать с определения сервиса как вероятности того, что при приходе покупателя товар не закончится, и установить цель, например, «уровень сервиса 95%». Затем мы закодировали бы отсутствие товара как затраты, избыток запасов — как другие затраты, и позволили оптимизационному движку находить баланс между ними.
Это приводит к решениям, которые численно аккуратны, но эстетически странны. Магазины в итоге получают технически достаточное количество единиц, однако большинство из них имеет неподходящие размеры или выполнены в одинаково безопасных цветах. С точки зрения модели всё в порядке: цель по уровню сервиса достигнута, а затраты укладываются в рамки. Но для покупателя, который зашёл в магазин, ассортимент выглядит безжизненным.
Если же мы холимизируем, мы признаём, что понятие «сервис» ещё не сформулировано должным образом. Мы превращаем развертывание системы принятия решений в эксперимент с нашими собственными предположениями.
Мы начинаем с внедрения настоящего рецепта принятия решений, основанного на данных и оптимизации, но при этом окружая его инструментарием, предназначенным для выявления «безумных» решений: ассортиментов, которые любой человеческий покупатель сразу посчитает вредными, даже если система пока не может объяснить почему. Мы мониторим магазины, где модель настаивает на отправке неправдоподобного набора размеров и товаров по распродаже. Мы внимательно прислушиваемся к планировщикам, которые жалуются, что система постоянно ограничивает разнообразие в определённых магазинах.
Каждый раз, когда мы сталкиваемся с таким безумием, мы ищем его причину. Возможно, наша целевая функция не предусматривает вознаграждения за разнообразие ассортимента, а учитывает лишь наличие единиц. Возможно, мы так и не зафиксировали практический предел того, как часто магазин может быть обновлён. Возможно, наши исторические данные скрывают эффекты замещения, которые делают некоторые отсутствия товара гораздо менее вредными, чем другие.
Затем мы меняем рамки. Мы вводим количественное понятие разнообразия в целевую функцию, присваивая ему финансовую стоимость. Мы заменяем жесткое ограничение стоимостью или наоборот. Мы добавляем новый класс решений в рецепт, например, когда обновлять витрину или как распределять поставки для хрупких магазинов. Мы расширяем инструментарий, чтобы визуализировать эти новые аспекты, так что следующий виток безумия, если он случится, будет легче диагностировать.
Мы холимизировали ситуацию: вместо того чтобы винить решатель или игнорировать систему, мы использовали сами неудачи решений как сигнал того, что наша рамка неполна и нуждается в развитии.
Аналогичная ситуация происходит при проведении операций по техническому обслуживанию и ремонту. Допустим, вы управляете запасными частями для авиационных двигателей. Наивный подход к оптимизации заключается в том, чтобы рассматривать каждую деталь отдельно: оценить, как часто она понадобится, присвоить стоимость отсутствию товара и стоимость хранения запасов, и позволить системе найти оптимальную точку заказа.
На практике двигатели не ремонтируются таким способом. Реальный ущерб возникает, когда ремонт задерживается из-за отсутствия одной критической детали, даже если у вас завалом запасов десятки других деталей. Затраты — это не просто отсутствие товара на строке в таблице; это дни простоя самолёта.
Холимизирование заставляет нас пересмотреть цель, ориентируясь на что-то более близкое к реальности: например, на сокращение ожидаемых дней задержки на двигатель на единицу бюджета. Это побуждает нас снабжать процесс инструментами, которые дают понять, какие детали постоянно блокируют ремонт. Когда система предлагает закупать большое количество детали, которая на самом деле никогда не является критичной для ремонта, это сигнал о безумии. Когда же она ограничивает запасы детали, которая неоднократно задерживает работу двигателей, это тоже сигнал.
Мы не рассматриваем эти неудачи как постыдные ошибки, которые следует скрывать. Мы воспринимаем их как лучший источник информации о том, где наша рамка ошибочна. Затем мы корректируем способ измерения ущерба, связи между событиями и затратами, а также структуру решений, чтобы будущие оптимизации проводились в более адекватном пространстве.
Таким образом, холимизирование не сводится к отказу от оптимизации. Речь идёт о том, чтобы окружить оптимизацию дисциплинированной практикой извлечения уроков из её ошибок.
Скрытая работа вокруг оптимизационного движка
Если вы заглянете в большую компанию, которая «занимается оптимизацией», то увидите, что основная часть усилий направлена не на разработку алгоритмов. Речь идёт о том, чтобы придать смысл данным, работать с исключениями и согласовывать то, что говорит система, с тем, что позволяет реальность.
Холимизирование делает эту скрытую работу явной и структурированной.
Большая часть сложности заключается в семантике данных. Операционные системы содержат ошеломляющее количество полей, кодов и исторических особенностей. Когда движок принятия решений воспринимает данные как есть, он неизбежно интерпретирует часть из них неправильно. Ограничение, которое когда-то имело значение, может устареть. Поле, которое кажется «временем поставки», на самом деле может быть смесью транзитных и административных задержек. Флаг, который выглядит как «на акции», может применяться непоследовательно в разных регионах.
Без менталитета холимизирования эти проблемы обнаруживаются случайно, часто после того, как ущерб уже нанесён. При холимизировании мы предполагаем с самого начала, что наше толкование данных носит предварительный характер. Мы создаём тесты, сравнения и проверки здравого смысла, которые пытаются опровергнуть наше понимание данных. Когда система предлагает решение, которое перегрузило бы причал, мы не списываем это на «невезение»; мы рассматриваем это как доказательство того, что в нашей картине мира отсутствует какое-либо ограничение.
Еще одним важным компонентом является инструментирование. Сам оптимизационный движок слеп: он принимает данные, выдаёт решения и не имеет мнения о том, насколько разумны эти решения. Холимизирование требует уровня прозрачности, предназначенного не только для отслеживания ключевых показателей эффективности, но и для выявления тех мест, где система ведёт себя так, что людям это кажется абсурдным.
Это может проявляться в различных формах: представления с временным сдвигом, позволяющие нам воспроизводить решения на основе прошлых данных; «микроскопы» для отдельного продукта или объекта, показывающие, как решение развивалось со временем; панели мониторинга, которые выделяют выбросы, а не средние значения. Цель всегда одна: превратить «безумные» переменные в структурированный канал обратной связи, а не в источник разочарования.
Наконец, есть скорость и безопасность итераций. По своей природе холимизирование экспериментально. Нам нужно опробовать новые рамки и уточнённые цели, не подвергая риску весь бизнес каждый раз. Это подразумевает наличие технических возможностей — версионирование рецептов принятия решений, контролируемые развертывания, теневые режимы — а также организационных: чёткое распределение обязанностей, культура, принимающая эксперименты как необходимое условие, и руководство, понимающее разницу между стабильным производственным правилом и пробным тестом.
Всё это — работа. Однако это работа, которую мы уже выполняем неформально всякий раз, когда жалуемся, что «система не понимает». Холимизирование — это попытка дать этой работе правильное название и метод.
Почему новое слово имеет значение
Вы можете справедливо спросить: зачем вообще вводить новый термин? Почему бы не просто говорить о «хорошей практике оптимизации» или «экспериментальном моделировании»?
Мой опыт показывает, что без отдельного названия внешний цикл поглощается внутренним. Как только слово «оптимизация» оказывается на повестке дня, внимание переключается на алгоритмы, решатели и показатели производительности, и разговор уходит от менее комфортного вопроса: оптимизируем ли мы вообще правильное?
В отличие от этого, «холимизирование» само по себе напоминает, что оптимизация — это лишь один компонент более широкой дисциплины. Оно говорит о том, что нас интересует весь цикл: от реальности к данным, от решения и обратно к реальности. Оно подразумевает, что нашим основным артефактом является не решатель, а развивающаяся рамка, в которой решатель работает.
Для моей собственной компании, Lokad, это название также проясняет, что мы пытаемся создать. По своей сути, мы не являемся поставщиком ещё одного оптимизационного движка. Мы стремимся предоставить платформу, где компании смогут холимизировать свои цепочки поставок: место, где данные можно перестраивать, где цели можно выражать в финансовых терминах, где решения могут автоматизироваться, оставаясь при этом понятными, и где каждая неудача системы рассматривается как ценная возможность для обучения тому, как должна развиваться рамка.
Это слово новое, но потребность, которую оно отражает, не нова. Цепочки поставок и многие другие сложные системы уже годами тихо холимизируют себя посредством проб и ошибок, доработок в электронных таблицах и бесконечных совещаний. Я надеюсь, что, дав этому процессу имя и более чёткую форму, мы сможем сделать его более осознанным, более строгим и, в конечном счёте, более эффективным.
Оптимизация, как математика, не исчезнет; если что, она будет продолжать совершенствоваться. Холимизация – это приглашение подняться на один уровень выше, чтобы рассматривать наши модели, цели и ограничения не как нечто священное, а как гипотезы, которые следует проверять по отношению к миру. Только тогда «optimal» перестанет быть формальной меткой в отчёте и начнет напоминать решения, которые мы действительно хотим видеть на практике.
