От планов к ставкам: почему цепочки поставок нуждаются в автономных решениях
Когда я опубликовал Introduction to Supply Chain, многие читатели просили меня подробнее раскрыть одну идею, которая тихо проходит через всю книгу: сдвиг в сторону автономного принятия решений в цепочках поставок. Не «больше панелей», не «больше оповещений», а программное обеспечение, которое принимает и выполняет ежедневные решения, не дожидаясь, пока человек нажмёт «утвердить».
В этом эссе я хочу прояснить, что я имею в виду под автономными решениями, почему считаю их экономически неизбежными и как эта позиция противоречит мейнстримовому подходу к цепочкам поставок, основанному на планах, прогнозах и встречах.
Реальная задача цепочки поставок: делать ставки целый день
Если убрать всю терминологию, цепочка поставок — это механизм для ставок.
Каждый заказ на покупку, каждое распределение товаров между складами, каждое изменение цены является небольшой ставкой: мы жертвуем одним вариантом, чтобы выбрать другой в условиях неопределенности в надежде улучшить долгосрочную прибыль. Мы никогда не знаем будущее; мы все равно выделяем ресурсы.
С этой точки зрения, ежедневная работа цепочки поставок — это не «поддержание плана», а выбор из вариантов. Чем больше у вас ассортиментных единиц, маршрутов и клиентов, тем больше появляется таких вариантов. Даже скромные розничные торговцы делают десятки тысяч таких микроставок каждый день; крупные сети — миллионы.
Когда такие решения принимаются по одному людьми, склонившимися над электронными таблицами, ограничивающим фактором уже не являются грузовики, корабли или складские площади. Это человеческое внимание. Это количество часов в неделе планировщика.
Автономное принятие решений — это моя попытка серьёзно устранить это узкое место.
Что я имею в виду под «автономными решениями»
Под автономными решениями я подразумеваю нечто очень конкретное:
Программное обеспечение обрабатывает записи компании и соответствующие внешние сигналы; оно вычисляет предлагаемые действия; и эти действия выполняются автоматически при нормальных условиях. Планировщику не нужно перечитывать количество. Менеджеру не нужно подписывать заявку. Программа напрямую записывает заказ в систему учёта.
Если условия выходят за рамки — повреждение данных, странный рыночный шок, противоречивые ограничения — программа останавливается и сигнализирует о проблеме. Но остановка — это исключение, а не правило. В обычном случае решения принимаются без участия человека.
Цель здесь — не «помочь планировщикам принимать решения быстрее». Цель состоит в том, чтобы сократить количество решений, требующих участия человека.
Это требует, чтобы две вещи были выражены с полной ясностью.
Во-первых, мы должны определить, что означает «хорошо» в терминах денег. Дополнительная единица на складе обеспечивает некоторую защиту от исчерпания запасов, но замораживает оборотный капитал, занимает место на складе и может привести к увеличению списаний позже. Каждый из этих эффектов имеет денежное воздействие. Если мы не сможем выразить компромисс в денежном эквиваленте, от машины нельзя ожидать правильного выбора.
Во-вторых, мы должны определить пространство допустимых вариантов: какие поставщики, какие сроки поставки, какие виды транспорта, какие маршруты, какие минимумы и максимумы, какие нормативные и физические ограничения. Машина не сможет соблюдать ограничения, которые мы никогда не определили.
Как только у нас появится понятный экономический критерий и ясное описание допустимого, аргументы в пользу автономных решений станут очевидными. Повторяющиеся решения, имеющие одинаковую структуру, следует закодировать один раз в виде вычисления, а затем ежедневно выполнять программным обеспечением в большом масштабе.
Другими словами: если решение принимается часто, имеет структуру и регулируется устойчивой экономикой, то повторный выбор его человеком каждое утро — это трата ресурсов.
Простой мысленный эксперимент
Представьте себе единую систему, которая наблюдает за каждым сигналом спроса, каждой позицией запасов, каждым обновлением сроков поставки, каждой стоимостью; и которая затем выпускает — без вмешательства человека — каждый заказ на покупку, заказ на перемещение, волну комплектации и изменение цены.
В таком мире не остаётся ничего, что можно было бы «согласовать» на встречах по планированию продаж и операций; встреча исчезает, потому что машина уже примиряет спрос, предложение и финансы в каждом принятом решении. Нет необходимости в отдельных «политиках управления запасами» или «целевых показателях уровня обслуживания»; эти понятия заложены в экономическом расчёте.
Этот мысленный эксперимент — не научная фантастика. Многие цифровые компании уже действуют таким образом в определённых областях: реклама, кредитный скоринг, динамическое ценообразование. В этих сферах полностью автоматизированные движки принятия решений используются уже годы, поскольку человеческое время реакции и память просто не могут поспевать.
Цепочки поставок отстают, преимущественно по историческим причинам, а не потому, что их по своей сути трудно автоматизировать.
Как мейнстрим воспринимает цепочки поставок
Чтобы понять столкновение, нам нужно кратко взглянуть на то, как сама дисциплина описывает себя.
Профессиональные организации, такие как CSCMP, определяют управление цепочками поставок как планирование и управление всеми видами деятельности, связанными с поиском источников, закупками, преобразованием и логистикой, в сочетании с координацией и сотрудничеством с партнёрами по каналам. ASCM использует схожую терминологию и предоставляет словарь именно для стандартизации этой лексики.
Такие модели, как SCOR, организуют эту деятельность в набор процессов: Plan, Source, Make (или Transform), Deliver (иногда делится на Order и Fulfill), Return и Enable или Orchestrate. Эти процессы сопровождаются обширными наборами показателей и лучших практик.
Кроме того, доминирующим управленческим ритуалом является планирование продаж и операций (Sales & Operations Planning) и его более поздняя версия — интегрированное бизнес-планирование (Integrated Business Planning). Идея, вкратце, состоит в создании единого консенсусного прогноза спроса и использовании его в качестве основы для согласования производства, закупок, логистики и финансов в динамическом горизонте.
Если вы посетите встречу по S&OP в крупной компании сегодня, вы почти наверняка увидите:
- Слайды, заполненные прогнозами временных рядов по семействам, регионам или SKU.
- Целевые уровни обслуживания и оборот запаса.
- Анализ разрывов по сравнению с бюджетом.
- Календарь предварительных встреч и обзоров на высшем уровне, предназначенный для того, чтобы привести всех к «единому набору чисел».
Эти практики не безумны. Это попытка навести порядок в сложной организации. Но они отражают определённое представление о сути проблемы.
В этом видении центральным элементом является план: совокупность временных рядов, проецируемых в будущее. Задача менеджеров — привести реальность в соответствие с этим планом или продолжать пересматривать план, пока цифры снова не станут приемлемыми. Автоматизация в этом контексте в основном означает более удобные панели, более плавные рабочие процессы и более последовательное параметрирование традиционных формул.
Моя точка зрения резко расходится именно в этом моменте.
От планов к ставкам
Мейнстрим начинается с плана и движется в обратном направлении. Моя картина начинается со ставки и движется вперёд.
В мире, ориентированном на план, вопрос звучит так: «Как заставить все функции согласовать будущее?» В мире, ориентированном на ставку, вопрос: «Учитывая наши знания, куда следует вложить следующий дополнительный евро, паллет или час производственных мощностей?»
План является, в лучшем случае, побочным эффектом ответа на второй вопрос; он не является первичным объектом. Если варианты на завтра изменятся, план должен измениться вместе с ними. Цель состоит не в том, чтобы следовать плану, а в том, чтобы делать прибыльные ставки в условиях неопределенности, день за днем.
Это звучит абстрактно, поэтому позвольте мне провести сравнение двух точек зрения по нескольким аспектам.
1. Роль прогноза
В мейнстримовой практике прогноз является основным управляющим сигналом. S&OP и IBP придают огромное значение построению единого прогноза временных рядов на месяц или неделю и последующему согласованию всех с этой кривой. Метрики точности, такие как MAPE и смещение, становятся центральными показателями эффективности.
По моему опыту, в этом есть две проблемы.
Во-первых, агрегирование спроса в аккуратные временные интервалы скрывает именно те поведения, которые имеют наибольшее значение: неравномерные продажи, акции, каннибализация между продуктами, непостоянные сроки поставки, коррелированные шоки. Гладкая кривая приносит утешение, но не истину.
Во-вторых, прогноз тихо заменяет собой само решение. Вместо того чтобы спросить: «Стоит ли нам заказать ещё один контейнер этого товара по данной цене, учитывая наши ограничения?», мы спрашиваем: «Каков спрос в следующем месяце?», а затем позволяем старой формуле пополнения превращать этот ответ в заказы. Если формула экономически наивна — а большинство из них таковы — то тот факт, что мы улучшили точность прогноза на два пункта, ничего не говорит о прибыли.
В автономном, ориентированном на ставки мире мне по-прежнему нужны взгляды на будущее, но они не ограничиваются временными рядами спроса. Мне нужны вероятностные оценки многих вещей: состава корзины, сроков поставки, возвратов, состава каналов, влияния изменений цен. И они нужны только в той мере, в какой помогают мне сравнивать варианты в денежном выражении.
Внимание смещается с вопроса «Насколько точен мой прогноз спроса?» на вопрос «С учетом всех неопределенностей, какой вариант имеет наилучший ожидаемый финансовый результат?»
2. Что мы автоматизируем
Мейнстримовые инструменты обычно описываются как «системы поддержки принятия решений». Системы планирования, центры управления и IBP-платформы агрегируют данные, показывают ключевые показатели эффективности, выделяют исключения и иногда предлагают действия, но редко выполняют что-либо без подтверждения человеком.
Человек намеренно остаётся «в цикле» практически для каждого решения. С точки зрения управления это кажется безопасным, но экономически затратно. Планировщик, которому приходится одобрять сотню предложений по пополнению запасов в день, не сможет глубоко вникнуть ни в одно из них; он быстро просматривает, принимает большинство, немного корректирует некоторые и надеется, что ничего не взорвется.
В отличие от этого, автономное принятие решений направлено на то, чтобы убрать человека из цикла там, где логика повторяющаяся, а экономические принципы хорошо понятны.
Программа считывает записи, оценивает варианты и принимает решение. Если возникает ничья или что-то выходит за рамки шаблона, она останавливается и запрашивает помощь. Тот факт, что решение автоматизировано, не означает, что оно произвольное; это просто означает, что логика была зафиксирована один раз вместо того, чтобы импровизироваться каждый день заново.
Авианосная аналогия полезна. Для современного самолёта по умолчанию используется автопилот в режиме крейсерского полёта, а не ручное управление. Пилот присутствует для выполнения взлёта, посадки и решения нестандартных ситуаций. Никто не считает это потерей престижа для пилота; это признание того, что машина лучше поддерживает стабильную траекторию на протяжении многих часов.
Цепочка поставок имеет свою «крейсерскую фазу»: бесчисленные повторяющиеся выборы, которые скучны именно потому, что они следуют знакомым шаблонам. Именно эти решения должны быть автономными.
3. Архитектура: где живёт решение?
Модель SCOR и большинство ERP-систем предполагают, что планирование и выполнение существуют в одном и том же транзакционном ядре. Заказы хранятся там, параметры хранятся там, и встроенная логика превращает их в рекомендуемые действия.
В результате, на практике, бизнес-логика разбросана по конфигурационным таблицам, пакетным заданиям, пользовательским отчётам и экспорту в электронные таблицы. Когда что-то идёт не так, сложно понять, почему было принято то или иное решение. Когда вы хотите улучшить логику, вам приходится искать все места, где спрятаны старые правила.
Чтобы автономное принятие решений работало, я предпочитаю более чёткое разделение.
Система учёта остаётся единственным источником правды для транзакций и основных данных. Аналитические системы могут продолжать рассказывать истории о прошлом. Но логика принятия решений — та часть, которая превращает данные в конкретные обязательства — живёт в отдельном слое, с которым проще работать, версиировать, тестировать и откатывать изменения.
Иногда я называю этот слой «движком принятия решений», но ярлык менее важен, чем сама дисциплина. Главное — рассматривать логику, которая выделяет деньги, пространство и время, как первостепенный артефакт, а не как туман параметров, кружащихся внутри различных инструментов.
Когда это сделано правильно, каждое автоматизированное решение можно проследить до понятной логики и конкретного снимка данных. Это противоположность чёрного ящика.
4. Управление и стимулы
В мейнстримовом управлении важность часто отождествляется с численностью сотрудников и календарем встреч. Менеджера, который руководит большой командой планирования и возглавляет основной процесс S&OP, считают стратегически центральным. Поставщики усиливают это, продавая лицензии по пользователям и объявляя «принятие пользователями» ключевым показателем успеха.
Автономное принятие решений переворачивает шкалу престижа. Лучший комплимент, который можно сделать команде, — это то, что миллионы правильных решений принимаются каждую неделю практически без чьего-либо вмешательства. Основное внимание в управлении уделяется качеству логики принятия решений и её влиянию на прибыль и риск, а не количеству людей, взаимодействующих с системой.
Это не просто философия; это влияет на контракты. Если поставщику платят за каждое рабочее место, у него мало стимулов автоматизировать эти места. Если команда получает вознаграждение за поддержание обширного ритуала встреч, она подсознательно будет защищать этот ритуал.
Если же мы вознаграждаем улучшение качества автономных решений — меньше исчерпания запасов при том же уровне запасов, лучшее использование мощностей, лучшие маржи при том же уровне риска — тогда как внутренние, так и внешние участники будут двигаться в правильном направлении.
«Разве это не опасно?» – распространённые возражения
Каждый раз, когда я выступаю за автономные решения, возникают три возражения.
Первое — это страх потерять контроль. Менеджеры беспокоятся о передаче ответственности за принятие решений программному обеспечению. Мой ответ в том, что большинство крупных организаций уже делегируют решения программам; они просто делают это неявно через формулы и параметры, встроенные в существующие инструменты. Когда планировщик полагается на правило пополнения, которое он едва понимает, он на самом деле не находится «под контролем». Он лишь является человеком-интерфейсом для устаревшего алгоритма.
Выводя логику на поверхность, явно выражая экономику и версионируя код, мы фактически обретаем контроль. Мы можем тестировать альтернативные политики бок о бок. Мы можем проиграть прошлый год с другой системой правил. Мы можем точно увидеть, какое изменение вызвало тот или иной результат.
Второе возражение — страх хрупкости. Что, если модель окажется неверной? Здесь, как и прежде, полезно сравнение с мейнстримом. Компания, работающая по заранее установленным формулам для определения безопасных запасов и приблизительным целям уровня сервиса, уже подвержена ошибкам модели; они просто скрыты под слоями привычек. Несопровождаемое принятие решений должно сочетаться с механизмами быстрой диагностики сбоев: правила остановки, контроль экономических результатов и возможность перейти на более простую стратегию до завершения расследования.
Третье возражение касается людей. Делает ли это видение планировщиков ненужными?
Это, безусловно, меняет характер работы. В мире, где решения принимаются автономно, уменьшается потребность в людях, которые корректируют заказы вручную, и возрастает спрос на тех, кто может правильно настроить экономические модели и ограничения, кто может ставить под сомнение данные, проводить эксперименты и интерпретировать результаты. Центр тяжести смещается от повторяющихся микрорешений к разработке и поддержанию самой системы принятия решений.
Для организаций, готовых на такие перемены, человеческая работа становится более интересной, а не менее.
Как выглядит день без вмешательства
Позвольте мне нарисовать скромную картину.
В розничной торговле за ночь система принятия решений анализирует вчерашние продажи, текущие запасы, поступления и обновлённые сроки поставщиков. Она знает стоимость капитала, штрафы за задержки доставки и закономерности уценки в конце сезона. Она предлагает заказы на закупку и переводы на текущий день. Для подавляющего большинства артикулов и локаций экономическая модель является стандартной; заказы автоматически передаются в ERP.
Небольшая доля случаев выглядит странно: поставщик, который внезапно удвоил срок поставки, товар, спрос на который возрос до небывалых высот, или конфликт ограничений на ключевом складе. Система не пытается быть изобретательной в таких ситуациях; она останавливается и формирует досье. Утром специалисты разбираются в этих случаях, принимают решение и, при необходимости, корректируют логику для следующих запусков.
В сети поставок запасных частей система постоянно переоценивает, какие детали стоит хранить и где, учитывая коэффициенты отказов, сроки ремонта, критичность оборудования и затраты на хранение. Она меняет политику наличия без лишней церемонии по мере изменения условий, поскольку базовый экономический расчет меняется. Никто не собирается на квартальный обзор для ручного изменения «ABC-классов».
В транспортировке маршрутизация и консолидация осуществляются аналогичным образом. Система знает кривые затрат для различных перевозчиков, типов транспортировки и уровней сервиса. Она распределяет грузы по направлениям, исходя из общих затрат и влияния на сервис, а не по иерархии правил, составленной пять лет назад на семинаре.
Для этого не требуется мистический искусственный интеллект. Необходимы точные данные, честная экономика и готовность доверить повседневные решения программному обеспечению.
Почему это противостояние имеет значение
Может возникнуть соблазн рассматривать автономное принятие решений как нишевую особенность в архитектуре программного обеспечения или как ещё один «подход» среди многих. Но я не воспринимаю это так.
План-центричный взгляд и взгляд, основанный на ставках, отвечают на разные вопросы.
План-центричный подход задаёт вопрос: «Как мы можем объединить людей вокруг единого видения будущего?» Он естественно сосредоточен на достижении консенсуса, собраниях и совершенствовании процессов.
Подход, основанный на ставках, спрашивает: «Учитывая неопределённость, с которой мы сталкиваемся, как мы можем распределить ограниченные ресурсы уже сегодня так, чтобы повысить долгосрочную прибыль?» Он фокусируется на экономике, на потоке средств в учёте и на том, как воплотить это мышление в программном обеспечении.
Оба подхода заботятся об уровнях сервиса, затратах и рисках. Оба ценят сотрудничество. Но только один из них создан для того, чтобы выживать в мире, где количество и скорость принимаемых решений будет продолжать расти, тогда как внимание человека остаётся ограниченным.
В моей книге я утверждаю, что управление цепочками поставок лучше всего рассматривать как отрасль прикладной экономики — дисциплину, задача которой заключается в распределении ограниченных ресурсов в условиях неопределённости. Если это так, то естественный исход становится очевидным. Там, где экономические модели понятны и закономерности стабильны, следует позволить машинам принимать решения автономно. Там, где экономика неясна или мир только что изменился, следует привлекать человеческие усилия для уточнения компромиссов и обновления логики.
Будущее принадлежит не тем, у кого самые красивые планы. Оно принадлежит тем, кто способен превратить более точное мышление в лучшие решения в широком масштабе, без необходимости каждое утро заново вводить цифры вручную.
