Мужчины, машины и настоящая работа цепочки поставок
Когда я сажусь за стол с руководителями, чтобы поговорить о цепочках поставок, они почти всегда начинают с обсуждения складов, грузовиков, персонала и иногда поставщиков. Компьютеры появляются где-то на заднем плане: тут система планирования, там электронная таблица и, конечно, ERP «то, на чем всё работает». Неявная картина всегда одинакова: люди — в центре, а машины созданы для помощи.
В своей книге Введение в цепочки поставок я исследовал совершенно иную картину, утверждая, что большая часть того, что мы называем «практикой управления цепочками поставок», на самом деле представляет собой программную проблему в маскировке. В этом эссе я хочу изложить эту идею более простыми словами и напрямую противостоять общепринятой точке зрения, доминирующей как в учебниках, так и в залах заседаний.
Как мы незаметно обесценили компьютеры
В значительной части литературы и в большинстве компаний компьютеры рассматриваются как изощрённые лопаты.
Конечно, их наличие необходимо. Никто уже не будет управлять глобальной сетью, используя бумагу и факс. Системы фиксируют транзакции, хранят основные данные, генерируют отчёты и делают прогнозы. Планировщики заходят в систему каждое утро, смотрят на информационные панели, совмещают данные системы со своим «деловым чутьём» и принимают решения.
Тон всегда остаётся схожим: технологии предоставляют поддержку. Они собирают данные, проводят расчёты, показывают красные и зелёные индикаторы, возможно, предлагают рекомендуемое количество заказа. Но от человека ожидается, что он «возьмёт на себя» ответственность за решение. Программное обеспечение выступает в роли аналитика, а планировщик — в роли лица, принимающего решения.
На бумаге это звучит обнадеживающе. Это уважает опыт, интуицию и ответственность. Это помогает избежать страха, что «система управляет бизнесом». Это соответствует нашему интуитивному ощущению, что серьёзные решения должны приниматься серьёзными людьми.
Проблема в том, что эта картина больше не соответствует масштабу и сложности современных цепочек поставок.
Цепочка поставок как совокупность мелких ставок
Каждый день ваша компания делает поразительное количество маленьких обязательств.
Вы решаете, сколько единиц каждого товара закупать у каждого поставщика. Вы выбираете, какому складу должны поступить те или иные количества. Вы распределяете ограниченные запасы между каналами и клиентами. Вы принимаете или отклоняете срочные заказы. Вы решаете, какие товары заслуживают место на полке и по какой цене. Вы принимаете определённые сроки поставки от транспортных компаний и отклоняете другие.
Каждое из этих обязательств — это маленькая ставка на неопределённое будущее: ставка на то, что заказ прибудет вовремя, что эта акция увеличит объём продаж, что этот запас безопасности будет достаточным, но не избыточным. Ни одна из этих ставок сама по себе не является героической, но вместе они формируют итоговую прибыль и убытки.
Отличительной чертой современных цепочек поставок является не то, что они глобальны или быстры; это уже знакомо. Особенность в том, что число таких ставок взрывно возросло. Ассортимент товаров расширяется. Каналы multiplication. Сроки поставок колеблются. Ожидания клиентов растут. «Поверхность принятия решений» становится слишком большой, чтобы любая команда людей могла контролировать её, не говоря уже об оптимизации вручную.
В таком окружении традиционная модель — люди в центре, машины, предоставляющие поддержку в принятии решений — просто не масштабируется. Люди становятся узким местом не там, где нужно: не в порту или на складе, а перед экранами.
Почему компьютеры должны быть в центре
У компьютеров есть одна суперсила: они отлично справляются с выполнением огромного количества мелких, структурированных вычислений снова и снова, не уставая и не скучая.
Цепочка поставок — как раз такая задача. Большинство оперативных решений, отнимающих время у команд планирования, являются повторяющимися. Они повторяются день за днем, с изменениями в данных, но с похожей структурой. У них есть четкие входные данные: прогнозы, затраты, мощности, ограничения, бизнес-правила. У них есть четкие выходные данные: количества, даты, местоположения, цены. Они не тривиальны, но они структурированы.
Когда вы это принимаете, возникает другая архитектура.
Вместо того чтобы считать компьютеры инструментами для подготовки информации для людей, вы начинаете воспринимать их как машины, которые действительно принимают рутинные решения. Не «ассистентские» машины, а «машины для принятия решений».
Это не означает создание гигантского монолитного мозга, контролирующего всё. Это означает сознательное построение программного обеспечения, которое в обычных условиях может:
- читать соответствующие данные,
- оценивать множество возможных вариантов,
- выбирать один вариант с учетом явной экономической цели,
- и выдавать конкретное указание: строку заказа на покупку, перемещение запасов, распределение или установление цены.
Люди по-прежнему существуют в этом мире, но они уже не тратят дни, подталкивая отдельные заказы. Они работают вокруг механизма принятия решений, а не через него.
Это основное изменение: от компьютеров, которые поддерживают принятие решений, к компьютерам, которые принимают решения там, где решения мелкие, многочисленные и повторяющиеся.
Для чего на самом деле нужны люди
Размещение машин в центре не делает людей менее значимыми; оно возлагает на них ответственность за иные аспекты.
Во-первых, люди должны решить, что программное обеспечение вообще может делать. Это означает определение пространства допустимых вариантов. Разрешен ли кросс-докинг между этими объектами? Допускаются ли замены между этими двумя SKU? Можем ли мы отправлять частичные заказы этому клиенту? Можем ли мы использовать воздушную перевозку для этого продукта в этом регионе? Компьютеры не изобретают варианты; они выбирают среди тех, которые мы предоставляем.
Во-вторых, люди должны определить, что означает «хорошо». Речь идет не о расплывчатых стремлениях типа «отличное обслуживание» или «экономия запасов», а об явных компромиссах. Насколько болезненно отсутствие товара с финансовой точки зрения для различных продуктов и клиентов? Насколько дорого обходится устаревание? Как мы действительно оцениваем время выполнения заказа по сравнению с затратами на каждом маршруте? Как нам урегулировать спор между двумя бизнес-единицами, конкурирующими за одну и ту же ограниченную мощность?
Когда мы точно ответим на эти вопросы, мы зададим программному обеспечению объективную функцию. Мы скажем ему, чего хотим, на языке, который он сможет применить к каждому решению.
В-третьих, люди должны следить за смыслом данных. Со временем поля в системе используются повторно, переосмысляются и применяются не по назначению. Ранее столбец означал «обещанную дату доставки», а теперь иногда означает «запрошенную дату». Флаг, который раньше указывал на семейство продуктов, теперь тихо переназначается для обозначения внутренней акции. Если никто не будет внимателен, программное обеспечение продолжит вычислять очень точную ерунду.
Наконец, люди должны вмешиваться, когда мир меняется быстрее, чем модели или правила. Они должны иметь возможность сказать: это ограничение больше не действует; это наказание слишком велико; этот вариант поставки теперь политически неприемлем; это время выполнения больше не заслуживает доверия. Они не вмешиваются, вручную редактируя тысячи заказов, а меняют предпосылки, порождающие эти заказы.
Таким образом, в этом представлении люди — не клерки, полирующие таблицы. Они — дизайнеры, экономисты и хранители механизма принятия решений. Их задача — разработать правила игры, установить счет и наблюдать за тем, когда игра перестает отражать реальность.
Основной взгляд, изложенный прямо
Позвольте мне теперь изложить общепринятое мнение таким образом, который будет понятен большинству практиков.
В типичной компании программный ландшафт состоит из трех уровней.
На нижнем уровне транзакционные системы фиксируют происходящее: заказы, поступления, отгрузки, счета. Над ними располагаются инструменты отчетности и панели мониторинга, которые суммируют эту историю по разным срезам: по продукту, клиенту, региону, периоду времени. Сверху располагаются системы планирования, которые используют данные с нижнего уровня, рассчитывают прогнозы, применяют эвристические методы или оптимизации и формируют «предложения».
Эти предложения затем анализируются планировщиками. Они сопоставляют их со своими знаниями о рынке, особенностями поставщиков, политикой клиентов, реальностью складов. Некоторые из них принимаются, другие корректируются, а оставшиеся отменяются. Во многих организациях значительная часть этого этапа происходит в электронных таблицах, вне рамок какой-либо формальной системы.
Подразумеваемая философия ясна: системы существуют для информирования и оказания помощи. Люди, особенно планировщики, должны принимать решения. Если что-то идет не так, объясняется это часто тем, что «система недостаточно гибкая», или «данные были неверными», или «алгоритм не учел этот особый случай», поэтому «необходим был планировщик для исправления».
Учебники подтверждают этот шаблон. Информационные технологии описываются как «движущая сила» или «фактор, способствующий» эффективности цепочки поставок. Они обеспечивают прозрачность, интеграцию, скорость и аналитическую сложность. Но всегда существует этап, на котором человек, принимающий решение, вновь занимает верхнюю ступень пирамиды, кому и отчитывается система.
Эта картина не является полностью ошибочной. Она отражала реальность того, что долгое время было возможно. Системы были негибкими. Масштабная оптимизация была дорогостоящей. Качество данных оставляло желать лучшего. Включение человека в процесс было безопасным и прагматичным решением.
Но мы придерживались этой модели дольше, чем это было оправдано.
Где я расходясь с общепринятым мнением
Мое несогласие с общепринятым мнением можно выразить одной простой фразой:
Для большинства операционных решений нам больше не следует стремиться к поддержке принятия решений; нам следует стремиться к автоматизации принятия решений.
Это не означает слепую автоматизацию. Это означает, что когда решение является мелким, частым и структурно схожим во многих случаях, мы должны разрабатывать программное обеспечение, которое выполняет его от начала до конца, при этом люди сосредотачиваются на проектировании и мониторинге этого механизма, а не на его ежедневном исполнении.
Из этого простого утверждения вытекают несколько противоречий.
Общепринятый подход предполагает значительные инвестиции в создание большего числа панелей мониторинга и найм большего числа планировщиков. Я же предпочел бы инвестировать в меньшее число планировщиков, которые действуют скорее как количественные владельцы продукта, и в большее число инженеров, способных закодировать бизнес-логику непосредственно в коде, а не через конфигурацию.
Общепринятый подход пытается приобрести системы, которые достаточно «настраиваемы», чтобы справляться с большинством ситуаций «из коробки». Я считаю, что любая серьезная цепочка поставок будет содержать множество уникальных особенностей и ограничений, которые нельзя адекватно отразить лишь с помощью флажков и таблиц параметров. В какой-то момент кто-то должен написать код.
Общепринятый подход рассматривает комбинацию ERP, модулей планирования и BI как завершенный стек: данные внизу, инсайты посередине, решения наверху. Я же вижу этот стек как лишь наполовину построенный. Отсутствующий слой — это тот, который берет на себя ответственность за большинство реальных обязательств в бизнесе.
Прежде всего, общепринятый подход настаивает, что именно люди должны «принимать» решения. Я же утверждаю, что для подавляющего большинства рутинных решений людям выгоднее решать, как следует принимать решения, а не принимать их одно за другим.
«А что если система работает неправильно?»
Распространённое возражение кажется немедленным и обоснованным: что происходит, если система ошибается?
Если мы позволим программному обеспечению размещать заказы, распределять запасы и устанавливать цены, и программное обеспечение совершит ошибку, последствия могут быть серьезными. Когда человек участвует в процессе, по крайней мере, кто-то мог бы это заметить.
Я считаю, что это возражение важно, но оно имеет двоякий эффект.
Когда вы полагаетесь на людей для исправления результатов систем, которые изначально заданы неверно, вы просто меняете один вид ошибки на другой. Индивидуальные ошибки могут быть обнаружены, но структурные ошибки сохраняются. Никто не располагает достаточным временем или умственными ресурсами, чтобы заметить, что вся логика системы немного сбита, что штраф неправильно откалиброван, или что ограничение изменилось. Люди тушат пожары; они редко занимаются полной переработкой.
В автоматизированной системе вы вынуждены явно учитывать этот риск.
Вам необходим мониторинг, который отслеживает не только уровни обслуживания и оборачиваемость запасов, но и способен связывать сбои с конкретными предположениями. Вам нужна возможность приостановить автоматизацию для определённой группы продуктов или регионов при обнаружении аномалии. Вам также необходимы журналы аудита: четкие записи о том, почему система выбрала то или иное решение, с какими входными данными и по какой внутренней логике.
И самое главное, вам нужна культура, принимающая, что программное обеспечение является первоклассным активом. Оно заслуживает проектирования, тестирования, рефакторинга и управления. Оно не может быть непрозрачным чёрным ящиком, за который «отвечает поставщик» или «решает ИТ». Если программное обеспечение управляет повседневным бизнесом, то улучшение и корректировка его работы становится одной из основных обязанностей организации цепочки поставок.
Это может звучать рискованнее, чем требовать от планировщиков «следить за предложениями», но на практике это часто снижает риск, а не увеличивает его. Ошибки становятся легче обнаруживаемыми. Исправления оказываются системными, а не локальными. Знания накапливаются в коде вместо того, чтобы исчезать, когда опытный планировщик уходит.
Где я все еще согласен с общепринятым мнением
Несмотря на эти разногласия, существуют области, в которых я полностью согласен с общепринятым мнением.
Я согласен, что информация является центральной. Без своевременных и надежных данных любые амбиции по автоматизации остаются фантазией.
Я согласен, что организационные барьеры представляют собой серьезное препятствие. Если отделы закупок, логистики, продаж и финансов не могут договориться об основных определениях и общих целях, ни одна система не сможет их спасти.
Я согласен, что цепочка поставок — это не только математика и механизмы. Отношения с поставщиками, доверие между партнерами, нормативные ограничения и геополитические потрясения имеют огромное значение. Даже самый совершенный механизм принятия решений не способен заставить корабль появиться в заблокированном канале.
Моя точка зрения более ясна: когда речь идет о ежедневной работе по определению количеств, сроков и распределению в больших сетях, мы кардинально недооцениваем потенциал уже имеющихся машин. Мы загоняем талантливых людей в бюрократические циклы, где они вносят минимальную дополнительную ценность, но потребляют огромное количество организационной энергии.
Иная цель
Если вы всерьез воспримете мою точку зрения, цель выглядит примерно так.
Большинство ежедневных операционных решений — что заказывать, куда распределять, сколько отгружать, когда пополнять запасы — принимаются автоматически программным обеспечением при нормальных условиях. Программное обеспечение работает по четким, явным правилам и экономическим целям, а его поведение прозрачно и подлежит аудиту.
Планировщики не начинают свой день с пролистывания списков исключений. Они начинают свой день, наблюдая за работой самой системы принятия решений: где она работает хорошо, где ведёт себя непредсказуемо, где предположения могли устареть. Они работают с инженерами, чтобы усовершенствовать логику, улучшить данные и скорректировать экономические компромиссы.
Когда происходят сбои, люди вмешиваются не посредством микроменеджмента отдельных заказов, а изменяя параметры игры: запрещая определённые виды транспорта, открывая временные варианты поставок, пересматривая штрафы и приоритеты. Система затем пересчитывает бесчисленные мелкие ставки, подразумеваемые этими новыми условиями.
Карьеры в цепочке поставок развиваются соответственно. Меньше времени тратится на «борьбу с системой» и «исправление плана». Больше времени уделяется пониманию экономики бизнеса, воплощению этого понимания в программном обеспечении и разработке устойчивых вариантов действий в условиях неопределённого мира.
В такой организации компьютеры уже не являются лопатами. Они — механизм цепочки поставок. Люди являются архитекторами, экономистами и хранителями этого механизма.
Это та точка зрения, которую я хотел разъяснить здесь. Она резко отличается от общепринятого представления об ИТ как о службе поддержки и о людях как о главных лицах, принимающих решения. Но я считаю, что она ближе к реальности того, куда цепочки поставок могут и должны двигаться дальше.
