Внедрение количественной цепочки поставок

Количественная цепочка поставок, или Количественная ЦП в кратком виде, представляет собой широкую перспективу на цепочки поставок, которая, просто говоря, стремится максимально использовать человеческий интеллект, дополненный возможностями современных вычислительных ресурсов. Однако эта перспектива не является всеобъемлющей. Она не претендует на то, чтобы быть окончательным решением для вызовов цепи поставок, но является дополнительным подходом, который можно почти всегда использовать для улучшения ситуации.

Инициатива

Количественная цепочка поставок помогает вашей компании улучшить качество обслуживания, снизить избыточные запасы и списания, повысить производительность, снизить закупочные цены и операционные расходы… и так далее. Проблемы цепи поставок сильно различаются в зависимости от различных ситуаций. Количественная цепочка поставок охватывает это разнообразие и стремится справиться с возникающей сложностью. Однако для практиков цепи поставок, которые привыкли к более классическим подходам к оптимизации своих цепей поставок, Количественная цепочка поставок может показаться немного ошеломляющей.

В следующем разделе мы рассмотрим составляющие, необходимые для максимального использования количественной перспективы на цепочку поставок. Мы рассмотрим и уточним цели инициативы по количественной цепочке поставок. Мы рассмотрим роли и навыки команды, ответственной за выполнение инициативы. Наконец, мы дадим краткий обзор методологии, связанной с количественной цепочкой поставок.

Цель

За исключением очень маленьких компаний, цепочка поставок включает миллионы решений ежедневно. Для каждой единицы, находящейся на складе, каждый день компания принимает решение о том, чтобы оставить единицу там, где она находится, а не переместить ее в другое место. Более того, та же логика применяется к несуществующим запасам, которые могут быть произведены или закуплены. Ничего не делать уже само по себе является решением.

Количественная цепочка поставок направлена на оптимизацию миллионов решений, которые компания должна принимать каждый день, и поскольку речь идет о миллионах, если не миллиардах решений в день, компьютеры играют центральную роль в этом предприятии. Это не удивительно, поскольку цепочки поставок были исторически одной из первых корпоративных функций, после бухгалтерии, которая была цифровизирована еще в конце 1970-х годов. Однако Количественная цепочка поставок направлена на взятие цифровизации на новый уровень.

Здесь мы должны признать, что ошибочные попытки внедрения “системы цепочки поставок будущего” были частыми за последние два десятилетия. Слишком часто такие системы только наносили ущерб цепочкам поставок, сочетая в себе эффекты черного ящика и автоматизацию, которая пошла не так, и тем самым генерировали так много плохих решений, что проблемы уже не могли быть исправлены с помощью вмешательства человека.

В некоторой степени Количественная цепочка поставок родилась из этих ошибок: вместо того, чтобы притворяться, что система каким-то образом знает бизнес лучше, чем само управление, фокус должен быть сосредоточен на выполнении выводов, сгенерированных управлением, но с более высокой степенью надежности, ясности и гибкости. Правильно реализованное программное обеспечение является способным инструментом, но, учитывая текущие возможности программного обеспечения, полное исключение людей из решения не является реалистичным вариантом.

Эта амбиция имеет одно немедленное последствие: программное обеспечение, которое компания использует для отслеживания своих продуктов, материалов и других ресурсов, не будет таким же, какое компании нужно для оптимизации своих решений. Действительно, будь то ERP, WMS, MRP или OMS - все такое программное обеспечение в первую очередь фокусируется на управлении процессами компании и потоком вводимых данных. Не поймите нас неправильно, есть огромные преимущества в оптимизации ввода данных и автоматизации всех административных задач. Однако наша точка зрения остается в том, что эти задачи не решают ни в малейшей степени стоящую перед нами задачу, которая заключается в увеличении способности вашей компании выполнять человеческие идеи в масштабе, необходимом для вашей цепочки поставок.

Затем, без измерений нет оптимизации. Поэтому Количественная цепочка поставок очень сильно связана с измерениями - как подразумевает ее название. Решения в области цепочки поставок - закупка запасов, перемещение запасов - имеют последствия, и качество таких решений должно быть оценено финансово (например, в долларах) с учетом здравых деловых перспектив. Однако, чтобы иметь хорошие, надежные метрики, требуется значительное усилие. Одна из целей Количественной цепочки поставок - помочь компании установить такие метрики, что также играет критическую роль на более поздних этапах проекта, при оценке возврата инвестиций (ROI) всей инициативы по цепочке поставок.

Наконец, как уже упоминалось ранее, Количественная цепочка поставок не является всеобъемлющей парадигмой. Она не имеет амбиции исправить или улучшить все в цепочке поставок компании. Она не претендует на то, чтобы помочь вам найти надежных поставщиков или надежных логистических партнеров. Она не обещает помочь вам нанимать отличные команды и поддерживать их высокий дух. Однако, благодаря своему очень конкретному фокусу, Количественная цепочка поставок полностью способна доставить осязаемые результаты.

Роли в проекте

Для реализации Количественной цепочки поставок требуется удивительно небольшое количество человеческих ресурсов, даже при работе с достаточно крупными цепочками поставок. Однако для такой инициативы требуются определенные ресурсы, о которых мы расскажем подробнее в этом разделе. Но прежде чем погрузиться в различные роли и их особенности, давайте начнем с упоминания одного основного принципа Количественной цепочки поставок: компания должна капитализировать каждое человеческое вмешательство.

Этот принцип противоречит тому, что происходит на практике с традиционными решениями в области цепочки поставок: человеческие усилия потребляются решением, а не капитализируются. Чтобы продолжать производить бесконечный поток решений, решению требуется бесконечный поток ручных записей. Такие записи могут иметь различные формы: корректировка сезонных профилей, работа с исключениями и предупреждениями, исправление странных значений прогноза и т. д.

Количественная цепочка поставок стремится изменить эту перспективу. Не только то, что человеческий труд дорог, но и экспертиза в области цепочки поставок, совмещенная с острыми деловыми инсайтами, слишком редка и слишком ценна, чтобы тратиться на рутинные задачи. Корень проблемы, требующей ручного вмешательства, должен быть исправлен: если значения прогноза неверны, то нет смысла изменять сами значения, нужно исправить входные данные или сам алгоритм прогнозирования. Исправление симптомов гарантирует бесконечное решение одних и тех же проблем.

Размер команды, необходимой для выполнения количественной инициативы в цепочке поставок, варьируется в зависимости от масштаба самой цепочки поставок. В нижней части спектра это может быть менее полной ставки (полный рабочий день), обычно для компаний с оборотом менее 20 миллионов долларов. В верхней части спектра это может включать дюжину человек; но в этом случае обычно ставится на кону несколько миллиардов долларов стоимости запасов.

Лидер цепочки поставок: Количественная цепочка поставок - это изменение парадигмы. Для осуществления изменений требуется лидерство и поддержка высшего руководства. Слишком часто руководство цепочки поставок не считает нужным быть слишком прямо вовлеченным в то, что воспринимается как “технические детали” решения. Однако количественная цепочка поставок заключается в выполнении стратегических идей в масштабе. Не делить стратегические идеи с командой, ответственной за инициативу, - это рецепт неудачи. От руководства не ожидается, что они разработают все соответствующие метрики и KPI - так как на их составление требуется много усилий - но от руководства определенно ожидается, что они будут их оспаривать.

Координатор цепочки поставок: хотя сама инициатива количественной цепочки поставок должна быть очень экономной по штату, большинство цепочек поставок не являются такими, или по крайней мере, не настолько экономными. Неудача в привлечении всех заинтересованных сторон может привести к путанице и замедлению инициативы. Таким образом, миссия координатора - собрать все необходимые внутренние отзывы, которые требуются для инициативы, и общаться со всеми заинтересованными сторонами. Координатор уточняет процессы и решения, которые необходимо принять, и получает обратную связь по метрикам и KPI, которые будут использоваться для оптимизации этих решений. Он также обеспечивает то, чтобы решение соответствовало рабочим процессам компании, сохраняя возможность пересмотра этих процессов на более поздних этапах инициативы.

Офицер по данным: количественная цепочка поставок критически зависит от данных, и каждая инициатива должна иметь надежный доступ к данным с точки зрения пакетной обработки. Фактически, инициатива не сводится просто к чтению нескольких строк в системе компании, она включает в себя чтение всей истории продаж, всей истории закупок, всего каталога продуктов и т. д. Офицер по данным обычно делегируется отделом информационных технологий для поддержки инициативы. Он отвечает за автоматизацию всей логики извлечения данных и планирование этой логики для ежедневного извлечения. На практике усилия офицера по данным в основном сосредоточены в самом начале инициативы.

Ученый цепочки поставок: он использует технологию - о которой будет рассказано далее - для объединения идей, собранных координатором, с данными, извлеченными офицером по данным, чтобы автоматизировать принятие решений. Ученый начинает с подготовки данных, что является удивительно сложной задачей и требует много поддержки от координатора, который должен будет взаимодействовать с множеством людей, которые в первую очередь создали данные, чтобы уточнить все, что может быть неясным. Он формализует стратегию, чтобы ее можно было использовать для принятия решений - например, предлагаемые количества перезаказа. Наконец, ученый цепочки поставок оснащает всю цепочку обработки данных панелями инструментов и KPI, чтобы обеспечить ясность, прозрачность и контроль.

Для средних компаний очень эффективно, когда один и тот же человек выполняет роль координатора и сотрудника по обработке данных. Однако, для этого требуется набор навыков, которые не всегда легко найти у одного сотрудника. Тем не менее, если такой человек существует в организации, он может значительно ускорить внедрение инициативы. Для крупных компаний также важно, чтобы координатор, даже если в начале инициативы он не очень хорошо знаком с базами данных компании, мог приобрести определенный уровень знаний по базам данных по мере развития инициативы. Действительно, IT-ландшафт постоянно меняется, и предвидение того, как эти изменения повлияют на инициативу, значительно помогает обеспечить ее успешное выполнение.

Технология

До сих пор мы оставались довольно неопределенными относительно программного обеспечения, необходимого для поддержки количественной цепочки поставок. Однако количественная цепочка поставок критически зависит от технологического стека, используемого для ее реализации. Хотя концептуально каждое программное обеспечение может быть реализовано заново, специалист по цепям поставок требует невероятного количества поддержки от своего стека, чтобы быть хотя бы разумно продуктивным. Кроме того, определенные возможности, такие как прогнозирование и численная оптимизация, требуют значительных предварительных исследований и разработок, которые выходят за рамки того, что специалист по цепям поставок может выполнить в ходе инициативы.

Первым требованием количественной цепочки поставок является платформа для данных с программными возможностями, и, естественно, иметь доступ к платформе для данных, специально разработанной для обработки данных и решения проблем цепей поставок, является определенным преимуществом. Мы говорим о платформе для данных, потому что, хотя современные настольные рабочие станции могут хранить несколько терабайт данных, это не означает, что эти рабочие станции предлагают другие желательные свойства для выполнения инициативы: надежность при сбоях оборудования, возможность аудита всех доступов, совместимость с экспортом данных и т. д. Кроме того, поскольку наборы данных цепей поставок обычно являются большими, платформа для данных должна быть масштабируемой, то есть способной обрабатывать большие объемы данных за короткое время.

Платформа для данных требует программных возможностей, что означает возможность реализовывать и выполнять практически любую произвольную логику обработки данных. Такие возможности предоставляются с помощью языка программирования. Программирование правильно воспринимается как очень техническое умение, и многие поставщики пользуются страхом, вызванным идеей необходимости справляться с решением, требующим “программирования”, чтобы предоставить простые пользовательские интерфейсы с кнопками и меню пользователям. Однако, когда командам по цепям поставок отказывают в программных возможностях, вмешиваются таблицы Excel, именно потому, что Excel предлагает программные возможности с возможностью написания формул, которые могут быть произвольно сложными. Программные возможности - это не просто гаджет, это основное требование.

Наконец, есть значительные преимущества в наличии платформы для данных, специально разработанной для цепей поставок. Фактически, необходимость в платформе для данных какого-либо вида практически не связана с цепями поставок: количественная торговля, осуществляемая банками и фондами, имеет схожие потребности. Однако решения в области цепей поставок не требуют подмиллисекундной задержки, как это делается в высокочастотной торговле. Проектирование платформы для данных - это вопрос компромиссов в инженерии, а также вопрос экосистемы программного обеспечения, которая начинается с поддерживаемых форматов данных. Эти компромиссы в инженерии и экосистема программного обеспечения должны быть согласованы с самими вызовами цепей поставок.

Вторым требованием Количественной цепочки поставок является вероятностный прогнозный движок. Это программное обеспечение отвечает за присвоение вероятности каждому возможному будущему событию. Хотя такой тип прогноза изначально вызывает некоторое беспокойство, поскольку он противоречит интуиции прогнозирования будущего, на самом деле “подвох” заключается в неопределенности: будущее не является определенным, и один прогноз гарантированно будет ошибочным. Классическая перспектива прогнозирования отрицает неопределенность и изменчивость, и в результате компания сталкивается с прогнозом, который должен был быть точным, но на самом деле им не является. Вероятностный прогнозный движок решает эту проблему, разрешая вопрос с помощью вероятностей.

Вероятностный прогнозирование в цепочке поставок обычно является двухэтапным процессом, начинающимся с прогноза срока поставки, а затем следующим за ним прогнозом спроса. Прогноз срока поставки является вероятностным прогнозом: каждой возможной продолжительности срока поставки присваивается вероятность, обычно выраженная в днях. Затем прогноз спроса также является вероятностным прогнозом, и этот прогноз строится на основе прогноза срока поставки, предоставленного в качестве входных данных. Таким образом, горизонт, который должен быть охвачен прогнозом спроса, должен соответствовать срокам поставки, которые сами по себе являются неопределенными.

Поскольку вероятностный прогнозный движок предоставляет наборы вероятностных распределений, его прогнозные результаты содержат гораздо больше данных, чем результаты классического прогнозного движка. Это само по себе не является проблемой, но для того, чтобы избежать слишком большого сопротивления при обработке массивного набора вероятностей, требуется высокая степень сотрудничества между платформой данных и прогнозным движком.

Фазы проекта

Количественная цепочка поставок сильно вдохновлена научно-исследовательской и разработкой программного обеспечения и передовыми практиками, известными в области науки о данных. Методология является высокоитеративной, с низким удельным весом предварительной спецификации и высоким удельным весом гибкости и способности восстановиться после неожиданных проблем и/или неожиданных результатов. В результате эта методология часто воспринимается как довольно удивительная для компаний, которые не глубоко вовлечены в собственную программную индустрию.

Первая фаза - это фаза определения, которая определяет, какие решения в цепочке поставок должны быть охвачены инициативой. В этой фазе также определяется ожидаемая сложность процесса принятия решений и соответствующие данные.

Вторая фаза - это фаза подготовки данных. Она включает в себя создание автоматизированной настройки, которая копирует все необходимые данные из систем компании в отдельную аналитическую платформу. Она также включает подготовку этих данных для количественного анализа.

Третья фаза - это фаза пилотирования и состоит в реализации начальной логики принятия решений, которая генерирует решения, например, предлагаемые объемы закупок, которые уже превосходят процессы компании. Ожидается, что эта логика будет полностью автоматизирована.

Четвертая фаза - это фаза производства, которая позволяет инициативе достичь рабочей скорости, где производительность контролируется и поддерживается, и достигается согласие относительно желаемой степени усовершенствования моделей цепочки поставок.

Фаза определения является наиболее прямолинейной и определяет рутинные решения, которые предполагается охватить инициативой по количественной цепочке поставок. Эти решения могут включать множество ограничений: минимальный объем заказа, полные контейнеры, максимальная емкость склада, … и эти ограничения должны быть тщательно изучены. Затем решения также связаны с экономическими факторами: стоимость хранения, стоимость дефицита товара, валовая прибыль, … и такие экономические факторы также должны быть изучены. Наконец, следует определить соответствующие исторические данные, а также системы, из которых будут извлекаться данные.

Фаза подготовки данных является наиболее сложной фазой; большинство неудач обычно происходят на этом этапе. Получение доступа к данным и их осмысление практически всегда являются недооцененными вызовами. Операционные системы (например, ERP / MRP / WMS / OMS) были разработаны для работы компании, для поддержания ее функционирования. Исторические данные являются побочным продуктом таких систем, поскольку запись данных не была причиной внедрения этих систем в первую очередь. Таким образом, на этой фазе следует ожидать множество трудностей. Столкнувшись с трудностями, большинство компаний имеют несчастную реакцию: давайте отступим и составим полную спецификацию. К сожалению, спецификация может охватить только известные или ожидаемые трудности. Тем не менее, почти все основные проблемы, с которыми сталкиваются на этой фазе, являются элементами, которые нельзя спланировать.

На самом деле, проблемы обычно становятся явными только тогда, когда кто-то начинает проверять данные на генерацию решений, основанных на данных. Если решения оказываются неверными, когда логика считается правильной, то, вероятно, есть проблема с данными. Решения, основанные на данных, обычно довольно чувствительны к проблемам с данными и, следовательно, на самом деле представляют отличный способ проверить, насколько компания контролирует свои собственные данные. Более того, этот процесс проверяет данные таким образом, что это имеет смысл для компании. Качество данных и понимание данных являются лишь средствами для достижения цели: доставки чего-то ценного для компании. Вполне разумно сосредоточить усилия на проблемах с данными, которые оказывают значительное влияние на решения, основанные на данных.

Фаза пилотирования - это фаза, которая ставит управление цепочкой поставок на испытание. Принятие неопределенности с помощью вероятностных прогнозов может быть довольно противоестественным. В то же время, многие традиционные практики, такие как еженедельные или ежемесячные прогнозы, резервные запасы, запасы на складе, оповещения о запасах или ABC-анализ, на самом деле наносят больше вреда, чем пользы. Это не означает, что инициатива по количественной цепочке поставок должна действовать без ограничений. Фактически, на самом деле все наоборот, поскольку количественная цепочка поставок - это все о измеримой производительности. Однако многие традиционные практики в сфере управления цепочкой поставок имеют тенденцию формулировать проблемы таким образом, что это противоречит их решению. Поэтому во время пилотной фазы одной из основных задач руководства цепочкой поставок является сохранение открытого ума и не внесение в инициативу тех самых элементов, которые будут генерировать неэффективность на более поздних этапах. Вы не можете хранить причину, проклиная следствие.

Затем и ученый в области цепочки поставок, и технология также проходят испытание, поскольку логика должна быть реализована для принятия решений в относительно короткие сроки. Начальная цель - просто создать то, что практики воспринимают как разумные решения, решения, которые не требуют ручной коррекции. Мы предлагаем не недооценивать, насколько большой вызов составляет создание “здравых” автоматизированных решений. Традиционные системы управления цепочкой поставок требуют множества ручных корректировок, чтобы вообще функционировать: новые продукты, акции, нехватка товара… Количественная цепочка поставок устанавливает новое правило: для обычных операций больше не допускаются ручные записи, все факторы должны быть встроены в логику.

Координатор цепочки поставок собирает все факторы, рабочие процессы и спецификации, которые должны быть интегрированы в логику принятия решений. Затем ученый в области цепочки поставок реализует первую партию КПЭ, связанных с решениями. Эти КПЭ вводятся для предотвращения появления “черного ящика”, которое часто возникает при использовании передовых численных методов. Важно отметить, что КПЭ разрабатываются совместно с руководителем цепочки поставок, который обеспечивает соответствие измерений стратегии компании.

Фаза производства стабилизирует инициативу и приносит ее на крейсерскую скорость. Решения, созданные логикой, активно используются, и их результаты тесно контролируются. Обычно требуется несколько недель или несколько месяцев, чтобы оценить влияние любого решения в цепочке поставок из-за включенных временных задержек. Таким образом, изменение темпа инициативы в фазе производства замедляется, чтобы стало возможным надежно оценить производительность автоматизированных решений. Инициатива переходит в фазу непрерывного улучшения. Хотя дальнейшие улучшения всегда желательны, необходимо найти баланс между преимуществами возможных усовершенствований логики и соответствующей сложностью этих усовершенствований, чтобы сохранить всю систему поддерживаемой.

Координатор цепочки поставок, освобожденный от своих рутинных задач по вводу данных, теперь может сосредоточиться на стратегических идеях, предложенных управлением цепочкой поставок. Обычно желательные изменения в процессе цепочки поставок, которые могли быть выявлены во время пилотной фазы, были приостановлены, чтобы избежать нарушения операций путем изменения всего сразу. Однако теперь, когда темп изменения логики принятия решений замедлился, становится возможным поэтапно пересматривать процессы, чтобы разблокировать улучшения производительности, требующие более чем просто лучших рутинных решений.

Ученый по цепочке поставок продолжает уточнять логику, уделяя все большее внимание ключевым показателям эффективности и качеству данных. Он также отвечает за пересмотр логики, поскольку со временем становятся видны незначительные недостатки или ограничения, обычно связанные с редкими ситуациями. Затем, по мере изменения процессов, логика принятия решений также пересматривается, чтобы оставаться полностью согласованной с рабочими процессами и стратегией. Кроме того, даже когда внутренние процессы не меняются, общая ИТ-инфраструктура и бизнес-ландшафт все равно продолжают меняться: ученый по цепочке поставок должен обеспечить актуальность логики принятия решений в этом постоянно меняющемся состоянии.

Результаты

Целью количественной цепочки поставок является предоставление действенных решений - предлагаемых количеств для заказов на закупку является архетипическим примером. Ниже мы более подробно разъясняем конкретную форму и механизм предоставления этих решений. Установление четких ожиданий от результатов является важным шагом в пути, который представляет собой количественная цепочка поставок. Кроме того, оптимизированные числовые результаты - не единственный желательный результат: в результаты также должны быть включены несколько других выходных данных, в основном мониторинг состояния данных и ключевые показатели эффективности управления. На практике результаты инициативы количественной цепочки поставок зависят от гибкости программного решения, используемого для поддержки самой инициативы. Тем не менее, они в первую очередь определяются их намерением, которое не зависит от используемой технологии.

Скрипты в качестве результата

Количественная цепочка поставок акцентирует внимание на полностью автоматизированных потоках данных. Это не означает, что программная настройка должна работать автономно. При рассмотрении крупномасштабной цепочки поставок естественно желательно иметь высокую степень близкого наблюдения. Тем не менее, ожидается, что поток данных будет полностью автоматизирован в том смысле, что ни один шаг в потоке фактически не зависит от ручной операции. Действительно, как указано в манифесте, когда в поддержку обработки данных цепочки поставок включены ручные операции, решение просто не масштабируется на практике.

Как прямое следствие этого понимания, результаты инициативы количественной цепочки поставок неизменно являются цельными программными продуктами. Это не означает, что от команды, ответственной за инициативу, ожидается полная реализация всего: программное решение, посвященное количественной цепочке поставок, предлагает возможность сосредоточиться исключительно на соответствующих аспектах вызовов цепочки поставок. Все низкоуровневые технические детали, такие как использование распределенных вычислительных ресурсов, автоматически выделенных в рамках облачной вычислительной платформы, должны быть абстрагированы. Команде не нужно углубляться в такие вопросы, потому что ожидается, что эти аспекты будут должным образом управляться самим инструментарием.

Результаты материализуются в виде скриптов, обычно написанных на языке программирования, способном удовлетворить требования цепочки поставок и обладающему высоким уровнем продуктивности. Здесь используется термин “скрипт” вместо “исходного кода”, но два термина тесно связаны: “скрипт” подчеркивает идею высокой степени абстракции и фокуса на самой задаче, в то время как “исходный код” подчеркивает более низкий уровень перспективы, предназначенный быть точным отражением вычислительного оборудования. Для количественной цепочки поставок, очевидно, наиболее важна перспектива цепочки поставок, а не вычислительное оборудование, которое является техническим аспектом второстепенной важности.

За последнее десятилетие успех пользовательских интерфейсов WYSIWYG (what-you-see-is-what-you-get) для приложений конечных пользователей привел многих поставщиков программного обеспечения для цепочки поставок к попыткам эмулировать этот подход с помощью WYSIWYG-решения для планирования и оптимизации цепочки поставок. Однако урок, вытекающий из почти систематического неудачного опыта с такими интерфейсами, заключается в том, что цепочки поставок являются сложными и не могут обойтись без программных инструментов. Исходя из нашего опыта, ожидать, что инструмент с функцией перетаскивания и редактирования сможет правильно отразить сложные нелинейности, связанные, скажем, с перекрывающимися минимальными объемами заказа (MOQ), является иллюзорным, в лучшем случае. Требуется программная выразительность, потому что в противном случае вызов цепочки поставок не может быть выражен внутри инструмента.

Естественно, с точки зрения конечного пользователя, скрипты - это не то, что ожидают увидеть практики цепочки поставок в качестве конкретного результата инициативы по количественной цепочке поставок. Люди будут взаимодействовать с панелями инструментов, которые содержат объединенные показатели эффективности и таблицы, собирающие предлагаемые решения. Однако эти панели инструментов являются временными и одноразовыми. Они получаются путем повторного запуска скриптов поверх соответствующих данных цепочки поставок. Хотя различие немного тонкое, важно не путать скрипт, который представляет собой реальный результат, с его числовым выражением, которое обычно видно конечному пользователю решения.

Панели инструментов для проверки целостности данных

Прежде чем приступить к доставке оптимизированных решений для цепочки поставок, мы должны убедиться, что данные, обрабатываемые системой, поддерживающей инициативу по количественной цепочке поставок, являются как численно, так и семантически корректными. Цель панелей инструментов для проверки целостности данных, или просто панелей инструментов для проверки данных, заключается в обеспечении высокой степени уверенности в правильности данных, что является неотъемлемым требованием для точности всех числовых результатов, возвращаемых решением. Эти панели инструментов также помогают команде цепочки поставок улучшить качество существующих данных.

Числовые ошибки являются прямолинейными: файл CSV, экспортированный из ERP, указывает, что у продукта ABC есть 42 единицы на складе, в то время как веб-консоль ERP сообщает только о 13 единицах на складе. Здесь явно видно, что у нас есть расходящиеся числа, которые должны быть одинаковыми. Панели инструментов для проверки целостности данных решают эти относительно очевидные проблемы, просто проверяя, что совокупные данные остаются в ожидаемых числовых диапазонах.

Семантические ошибки более тонкие и на практике гораздо сложнее выявить. Большая часть работы, выполняемой во время подготовки данных, фактически заключается в выявлении и устранении всех семантических ошибок. Например: поле stockinv в ERP может быть задокументировано как наличие товара на складе. Таким образом, команда цепочки поставок предполагает, что эта величина не может быть отрицательной, потому что, очевидно, если эти единицы находятся в физической близости на полке, это должна быть положительная величина. Однако документация ERP также может быть немного вводящей в заблуждение, и эта величина могла бы быть более уместно названа доступным запасом, потому что при возникновении нехватки товара и выдаче клиентом предзаказа количество может стать отрицательным, чтобы отразить, что определенное количество единиц уже должно быть доставлено клиенту. Этот случай иллюстрирует семантическую ошибку: число само по себе не является неправильным - неправильным является понимание числа. На практике семантические приближения могут порождать множество несогласованных поведений, которые, в свою очередь, порождают постоянные затраты на трение внутри цепочки поставок.

Панели инструментов для проверки целостности данных объединяют числа, которые позволяют компании мгновенно решить, можно ли доверять данным как достаточно хорошим или нет. Действительно, поскольку решение будет использоваться ежедневно для производственных целей, необходимо, чтобы значительная проблема с данными была выявлена путем близкого к мгновенному осмотра. В противном случае, вероятно, что цепочка поставок будет работать в течение дней, если не недель, на основе неправильных данных. В этом отношении панель инструментов для проверки целостности данных похожа на светофор: зеленый - можно проходить, красный - остановка.

Кроме того, при рассмотрении крупной цепочки поставок обычно существует невозможное количество поврежденных или иным образом неправильных данных. Эти данные возникают из-за ошибочных ручных записей или из-за редких крайних случаев в самих системах компании. На практике для любой крупной цепочки поставок неразумно ожидать, что данные цепочки поставок будут на 100% точными. Вместо этого нам нужно убедиться, что данные достаточно точны, чтобы снизить затраты на трение, вызванные этими ошибками, практически до нуля.

Следовательно, панели управления состоянием данных также должны собирать статистику об обнаруженных ошибках данных. Эта статистика является инструментальной для установления доверия к данным. В этой связи, ученому по цепочке поставок часто приходится устанавливать хорошо выбранные пороги предупреждения, обычно связанные с полной остановкой решения. Необходимо быть осторожным при установлении порогов, потому что, если они слишком низкие, то решение непригодно к использованию, так как оно слишком часто останавливается из-за “обнаруженных проблем с данными”; однако, если они слишком высокие, то затраты на трение, вызванные ошибками данных, могут стать значительными и подорвать преимущества, принесенные самой инициативой.

Помимо сигнализации красного и зеленого цветов, панели управления состоянием данных также предназначены для предоставления приоритетных идей по улучшению данных. Действительно, многие данные могут быть неверными, но и незначительными. Например, не имеет значения, если цена закупки продукта неверна, если спрос на этот продукт исчез несколько лет назад, так как дальнейших заказов на этот продукт не будет.

Количественная цепочка поставок подчеркивает, что детализация ошибок данных, которая может потребовать значительного количества ручной работы, должна иметь приоритет перед оценочным финансовым влиянием самой ошибки данных по сравнению с затратами на труд, связанными с исправлением. Действительно, в зависимости от ситуации, стоимость исправления одной неправильной точки данных может сильно варьироваться и должна учитываться при предложенной приоритизации. Наконец, когда стоимость исправлений считается более дорогой, чем затраты на цепочку поставок, вызванные этими ошибками, процесс улучшения данных может быть прекращен.

Приоритизированные панели управления принятием решений

Как мы видели, только решения в цепочке поставок могут быть действительно оценены с количественной точки зрения. Поэтому неудивительно, что одним из ключевых операционных результатов инициативы по количественной цепочке поставок являются панели управления, которые объединяют решения, полученные в качестве окончательного числового результата всего процесса обработки данных. Такая панель управления может быть такой простой, как таблица, в которой перечислено для каждого продукта точное количество единиц, которые необходимо немедленно заказать. Если присутствуют минимальные объемы заказа (MOQ) или любые другие ограничения на заказ, то предлагаемые количества могут в большинстве случаев быть равными нулю, пока не будут достигнуты соответствующие пороги.

Для простоты мы предполагаем, что эти числовые результаты собраны в панели управления, которая является определенной формой пользовательского интерфейса. Однако сама панель управления - это только один из вариантов, который может быть или не быть актуальным. На практике ожидается, что программное обеспечение, обеспечивающее функционирование инициативы по количественной цепочке поставок, будет очень гибким, то есть гибким с программной точки зрения, предлагая множество способов упаковки этих результатов в различные форматы данных. Например, числовые результаты могут быть объединены в плоские текстовые файлы, которые предназначены для автоматического импорта в основную систему планирования ресурсов предприятия, используемую для управления активами компании.

В то время как формат решений в значительной степени зависит от решаемой задачи в цепочке поставок, большинство задач требуют приоритизации этих решений. Например, процесс вычисления предлагаемых количеств для заказа может быть разложен на приоритизированный список единиц, которые необходимо приобрести. Самая прибыльная единица занимает первое место. Поскольку запасы приносят убытки с убывающей отдачей, вторая единица, приобретенная для того же продукта, обеспечивает уменьшающуюся долю спроса на рынке. Поэтому вторая единица для этого продукта может не быть второй записью в общем списке. Вместо этого вторая наиболее прибыльная единица может быть связана с другим продуктом и т. д. Приоритизированный список единиц, которые необходимо приобрести, концептуально не имеет конца: всегда можно приобрести еще одну единицу. Поскольку спрос на рынке ограничен, все приобретенные единицы станут мертвым запасом после определенного момента. Превращение этого приоритетного списка в конечные количества для закупки требует только введения критерия остановки и суммирования количеств по продукту. На практике, нелинейные ограничения на заказ дополнительно усложняют эту задачу, но для простоты мы оставим эти ограничения в стороне на этом этапе обсуждения.

Принятие решений является естественной операцией с точки зрения количественной цепочки поставок. Поскольку каждое решение связано с финансовым результатом, выраженным в долларах, ранжирование решений от самых прибыльных до наименее прибыльных является прямолинейным. Таким образом, многие, если не большинство, панелей инструментов, которые компилируют предлагаемые решения цепочки поставок, могут ожидать, что на практике они будут представлять собой приоритетные списки решений. Эти панели инструментов содержат списки с высокоприбыльными решениями, перечисленными вверху, и очень неприбыльными решениями, перечисленными внизу. В качестве альтернативы, практики цепочки поставок могут решить обрезать списки, когда решения неприбыльны. Однако, часто можно получить полезные идеи, изучая решения, которые оказываются немного ниже порога прибыльности, даже если компания, очевидно, не планирует действовать по этим неприбыльным записям.

Для создания таких панелей инструментов, основанных на решениях, программное решение, поддерживающее количественную цепочку поставок, должно численно исследовать огромное количество возможных решений. Например, решение должно быть способно рассмотреть финансовое влияние закупки каждой единицы, единицу за единицей, для каждого продукта в каждом месте. Неудивительно, что для этой операции может потребоваться значительные вычислительные ресурсы. К счастью, в настоящее время вычислительное оборудование способно справиться даже с самыми крупными глобальными цепочками поставок. Предполагая, что базовое программное решение архитектурно подходит для количественной цепочки поставок, масштабируемость обработки данных не должна вызывать проблем для команд цепочки поставок.

Прозрачность числовых результатов

Системы, пренебрежительно называемые “черными ящиками” в цепочке поставок и других областях, - это системы, которые генерируют результаты, которые не могут быть объяснены практикующими специалистами, взаимодействующими с этими системами. Количественная цепочка поставок, с ее специфическим фокусом на автоматизированном потоке данных, также сталкивается с риском предоставления того, что команды цепочки поставок классифицируют как “черные ящики”. Действительно, финансовые последствия решений цепочки поставок очень важны для компании, и, хотя новая система может улучшить ситуацию, она также может потенциально создать катастрофы. Хотя автоматизация является очень желательной, это не означает, что команде цепочки поставок необходимо иметь полное понимание того, что предоставляется потоком данных, поддерживающим инициативу количественной цепочки поставок.

Термин “прозрачность” относится к усилиям, необходимым для полной прозрачности решения в пользу команд цепочки поставок. Этот подход подчеркивает, что ни одна технология не является прозрачной по своему устройству. Прозрачность является конечным результатом конкретных усилий, которые являются частью самой инициативы. Даже простая линейная регрессия может давать ошеломляющие результаты на практике. Отложив в сторону нескольких исключительных личностей, большинство людей не имеют интуитивного понимания того, каков “ожидаемый” вывод линейной модели, когда вовлечены 4 и более измерения. Однако проблемы цепочки поставок часто включают десятки переменных, если не сотни. Таким образом, даже упрощенные статистические модели являются де факто черными ящиками для практикующих специалистов цепочки поставок. Естественно, когда используются алгоритмы машинного обучения, как рекомендуется в количественной цепочке поставок, практикующие специалисты остаются еще больше в неведении.

Хотя эффект черного ящика является реальной проблемой, реалистическое решение не заключается в упрощении обработки данных в расчетах, которые немедленно понятны человеческому разуму. Этот подход является рецептом для крайней неэффективности, который полностью разрушает все преимущества современных вычислительных ресурсов, которые могут использоваться для решения сложности современных цепочек поставок. Упрощение процесса - не ответ. Прозрачность - ответ.

Даже самые сложные рекомендации по цепочке поставок могут быть в значительной степени прозрачными для практиков цепочки поставок, просто разложив внутренние расчеты с помощью хорошо выбранных финансовых показателей, которые представляют экономические факторы, поддерживающие саму рекомендацию. Например, вместо простого отображения голой таблицы с двумя столбцами “продукт” и “количество” в качестве предлагаемого заказа, таблица должна включать несколько столбцов, которые помогают принимать решения. Эти дополнительные столбцы могут включать текущий запас, общий спрос за последний месяц, ожидаемое время доставки, ожидаемую финансовую стоимость нехватки товара (если заказ не будет выполнен), ожидаемую финансовую стоимость избыточного запаса (риск, связанный с предлагаемым заказом) и т. д. Столбцы созданы с целью дать команде цепочки поставок быстрые проверки разумности предлагаемых количеств. Через столбцы команда может быстро установить доверие к числовому результату и также выявить некоторые слабые места решения, требующие дальнейшего улучшения.

Расширение панелей инструментов для целей прозрачности - это частично искусство. Генерация миллионов чисел легка, даже если у вас нет больше вычислительных ресурсов, чем доступно на смартфоне. Однако генерация 10 чисел, достойных ежедневного просмотра, очень сложна. Таким образом, основной вызов заключается в определении дюжины или менее ключевых показателей эффективности, которые достаточно освещают рекомендации по цепочке поставок. Хорошие показатели эффективности обычно требуют много работы; они не должны быть наивными определениями, которые обычно вводят в заблуждение в цепочке поставок. Например, даже такой простой столбец, как “единичная цена закупки”, может быть весьма вводящим в заблуждение, если поставщик предлагает скидки при большом объеме, что делает цену закупки зависимой от количества закупаемого товара.

Стратегические панели инструментов

В то время как фокус на мелкомасштабных решениях необходим - поскольку это один из немногих подходов, который позволяет проводить количественную оценку эффективности - цепочке поставок также может потребоваться корректировка в более крупных, более деструктивных масштабах, чтобы повысить эффективность до следующего уровня. Например, закупка большего количества хорошо выбранных единиц товара незначительно повышает уровень обслуживания. Однако, в какой-то момент склад заполняется, и невозможно закупить дополнительные единицы. В этой ситуации следует рассмотреть возможность увеличения складской емкости. Чтобы оценить влияние снятия этого ограничения, мы можем исключить ограничение емкости склада из расчетов и оценить общую финансовую выгоду от работы с произвольным, большим складом. Управление цепочкой поставок может следить за финансовым показателем, связанным с затратами на трение, вызванными самой емкостью склада, и затем решить, когда пришло время рассмотреть возможность увеличения складской емкости.

Обычно цепочки поставок функционируют на основе множества ограничений, которые нельзя пересматривать ежедневно. Эти ограничения могут включать оборотный капитал, емкость склада, задержки в транспортировке, пропускную способность производства и т. д. Каждое ограничение связано с неявной альтернативной стоимостью для цепочки поставок, которая обычно превращается в больше запасов, больше задержек или больше нехватки товара. Альтернативная стоимость может быть оценена через прирост производительности, который будет получен при удалении или ослаблении самого ограничения. Хотя некоторые из этих симуляций могут оказаться сложными для реализации, часто они не более сложны, чем оптимизация рутинных решений, то есть установление количеств закупки.

Количественная цепочка поставок подчеркивает, что возможные затраты, связанные с ограничениями, должны быть частью производственного потока данных и, как правило, должны быть воплощены в специальных инструментах управления, предназначенных для помощи управлению цепочкой поставок принимать решение о необходимости внесения крупных изменений в их цепочку поставок. Эти типы инструментов называются стратегическими инструментами управления. Этот подход отличается от традиционной практики управления цепочкой поставок, которая акцентирует внимание на ад-хок инициативах, когда поставочная цепочка готова достичь предельной производительности. Действительно, ключевые показатели эффективности, предоставляемые стратегическими инструментами управления, обновляются ежедневно или чаще при необходимости, так же, как и остальной поток данных. Им не нужно делать последний момент, последнюю отчаянную попытку, потому что они всегда актуальны и готовы использовать полученные знания из долгосрочной инициативы.

Стратегические инструменты управления поддерживают процесс принятия решений в управлении цепочкой поставок. Поскольку они являются частью потока данных, когда рынок начинает развиваться быстрее, чем обычно, ключевые показатели эффективности остаются актуальными в текущей ситуации компании. Этот подход избегает традиционных проблем, связанных с ад-хок исследованиями, которые неизбежно добавляют дополнительные задержки к уже просроченным проблемам. Этот подход также в значительной степени снижает альтернативную проблему - спешные стратегические решения, которые оказываются нерентабельными - сожаление, которое можно было предвидеть с самого начала.

Инспекторские инструменты

Цепочки поставок являются сложными и непредсказуемыми. Эти свойства делают отладку потока данных чрезвычайно сложной задачей. Однако этот поток данных является основой инициативы Количественной цепочки поставок. Ошибки обработки данных или ошибки могут возникнуть в любом месте в потоке данных. Что еще хуже, наиболее частым типом проблемы является не неправильная формула, а неоднозначная семантика. Например, в начале потока данных переменная stockinv может относиться к доступному запасу (где отрицательные значения возможны), а позже эта же переменная используется с интерпретацией остатка на складе (где ожидаются положительные значения). Неоднозначная интерпретация переменной stockinv может привести к широкому спектру неправильных поведений, начиная от сбоев системы - что очевидно, поэтому только умеренно вредно - до тихой и всеобъемлющей порчи решений в цепочке поставок.

Поскольку цепочки поставок почти всегда состоят из уникального набора программных решений, созданных на протяжении многих лет, нет надежды получить доступ к “проверенному” программному решению, свободному от ошибок. Действительно, большинство проблем возникают на границах системы, когда происходит согласование данных, поступающих из разных систем, или даже просто согласование данных, поступающих из разных модулей в рамках одной и той же системы. Таким образом, независимо от того, насколько проверено программное решение, инструментарий должен уметь удобно поддерживать процесс отладки, так как такого рода проблемы неизбежны.

Целью инспекторских инструментов является предоставление детальных представлений для детального анализа наборов данных цепочки поставок. Однако эти инструменты не являются простыми инструментами для анализа входных таблиц данных. Такой подход, как анализ данных или аналогичный подход к срезу и нарезке данных, упускает суть. Цепочки поставок - это всегда потоки: поток материалов, поток платежей и т. д. Некоторые из самых серьезных проблем с данными возникают, когда “логически” теряется непрерывность потока. Например, при перемещении товаров со склада A на склад B база данных склада B может не содержать несколько записей о продуктах, что приводит к тонкой порче данных, поскольку единицы, поступающие со склада A, получаются на складе B без должного привязывания к своему продукту. Когда числовые результаты кажутся странными, эти инспекторские инструменты являются основным вариантом для ученого по цепочке поставок для быстрого исследования образца данных.

На практике панель инспектора предоставляет точку входа низкого уровня, такую как код товара или SKU, и объединяет все данные, связанные с этой точкой входа, в одном представлении. Когда товары перемещаются через множество мест, как это происходит, например, в авиационных цепях поставок, то панель инспектора обычно пытается восстановить траектории товаров, которые могли проходить не только через несколько физических мест, но и через несколько систем. Собирая все эти данные в одном месте, поставщикам цепочки поставок становится возможным оценить, имеют ли данные смысл: можно ли определить, откуда поступают товары, которые отправляются? Соответствуют ли движения запасов официальным политикам цепочки поставок и т. д.? Панель инспектора является инструментом “отладки”, поскольку она разработана для объединения данных, которые тесно связаны, не с точки зрения информационных технологий, а с точки зрения цепочки поставок.

Панели инспектора являются низкоуровневым аналогом панели контроля состояния данных. Они фокусируются на полностью дезагрегированных данных, в то время как панели контроля состояния данных обычно принимают более высокий уровень в отношении данных. Кроме того, панели инспектора обычно являются неотъемлемой частью усилий по белому ящику. Сталкиваясь с тем, что кажется загадочным рекомендацией, практики цепочки поставок должны тщательно изучить SKU или продукт, чтобы определить, является ли рекомендуемое решение разумным или нет. Панель инспектора обычно настраивается именно для этой цели, включая множество промежуточных результатов, которые вносят свой вклад в расчет конечной рекомендации.

Оценка успеха

Кажется, что это некоторое противоречие, но наш опыт говорит нам, что, несмотря на то, что Количественная Цепочка Поставок уделяет значительное внимание числовым методам и измерениям, метрики обычно дают нам слишком мало информации и часто слишком поздно о том, находится ли инициатива на правильном пути. Почти все метрики могут быть подделаны, и это обычно происходит за счет устойчивости выбранного подхода. Таким образом, Количественная Цепочка Поставок ищет очевидные улучшения: если улучшения настолько незаметны, что для их обнаружения требуются продвинутые измерения, то инициатива, скорее всего, не стоит затраченных усилий и должна считаться неудачей. Напротив, если улучшения заметны и последовательны по многим метрикам, и цепочка поставок в целом кажется более гибкой и реактивной, чем когда-либо, то инициатива, скорее всего, принесла успех.

Метрики могут быть подделаны

Есть причина, по которой инженеры редко оцениваются на основе метрик: они слишком хорошо умеют подделывать метрики, то есть использовать метрики в своих интересах, а не служить интересам компании. Цепочки поставок сложны, и практически все простые метрики могут быть использованы в свою пользу таким образом, что это может быть полностью разрушительно для компании. Может показаться, что это проблема закрытия лазеек, скрывающихся в метриках. Однако наш опыт показывает, что всегда можно найти еще одну лазейку.

История обратной разработки метрик

Давайте возьмем вымышленный интернет-магазин в качестве примера. Руководство принимает решение о необходимости улучшения уровня обслуживания, и поэтому уровень обслуживания становится флагманской метрикой. Команда цепочки поставок начинает работать в соответствии с этой метрикой и приходит к решению, которое заключается в значительном увеличении уровня запасов, что приводит к огромным затратам для компании.

В результате руководство меняет правила, определяется максимальное количество запасов, и команда должна работать в пределах этого ограничения. Команда пересматривает свои показатели и понимает, что самый простой способ снизить уровень запасов - это пометить большие объемы запасов как “нерабочие”, что вызывает агрессивные акции. Уровень запасов действительно снижается, но в процессе также значительно снижаются валовые маржи.

И снова проблема не остается незамеченной, и правила меняются еще раз. Вводится новое ограничение на количество запасов, которые могут быть отмечены как “нерабочие”. Внедрение этого нового правила требует больших усилий, потому что цепочка поставок внезапно сталкивается с “старыми” запасами, которые придется сильно снижать по цене. Чтобы справиться с этим новым правилом, команда увеличивает долю воздушного транспорта по сравнению с морским транспортом. Сроки поставки сокращаются, запасы снижаются, но операционные расходы быстро растут.

Чтобы справиться с операционными расходами, которые выходят из-под контроля, руководство снова меняет правила и устанавливает верхнюю границу процента товаров, которые могут быть доставлены воздушным путем. И снова новое правило приводит к хаосу, потому что оно вызывает серию исчерпания запасов, которые могли быть предотвращены с помощью воздушного транспорта. В результате, вынужденная работать в условиях все более жестких ограничений, команда начинает отказываться от использования скидок, предлагаемых поставщиками. Покупка меньших объемов также является способом сокращения сроков поставки. Однако, вновь, валовые маржи снижаются в процессе.

Возвращение закупочных цен на правильный путь оказывается гораздо более сложной задачей для руководства. Нет простого правила, которое могло бы справиться с этим вызовом, и вместо этого вводится множество целей цен для каждой подкатегории товаров. Многие цели оказываются нереалистичными и приводят к ошибкам. В целом, картина цепочки поставок становится все менее ясной. Под давлением со всех сторон, команда цепочки поставок начинает настраивать неявную функцию процесса планирования спроса: список заменяемых продуктов.

Действительно, руководство рано осознало в процессе, что некоторые исчерпания запасов были далеко не так влиятельными, как другие, потому что некоторые из отсутствующих продуктов имели несколько почти идеальных заменителей. В результате все согласились, что исчерпания запасов по этим продуктам могут быть в значительной степени снижены при вычислении общего уровня обслуживания. Однако команда цепочки поставок, которая теперь работает под огромным давлением, начинает растягивать назначение этого списка на одну-две позиции за пределами его первоначального назначения: продукты, которые не так похожи, включаются в список почти идеальных заменителей. Метрики уровня обслуживания улучшаются, но бизнес - нет.

Ловушка успеха

Метрики могут быть подделаны, и если командам предоставляются токсичные стимулы, метрики, скорее всего, будут использованы в обманчивом манере. Однако ситуация далеко не так плоха, как может показаться. Фактически, наш опыт показывает, что за исключением действительно дисфункциональных корпоративных культур сотрудники, как правило, не склонны подрывать свою работу. Напротив, мы заметили, что большинство сотрудников гордятся тем, что делают правильные вещи, даже если это означает, что политика компании нужно немного растянуть.

Поэтому, вместо того чтобы ограничивать свободу команды, ответственной за внедрение стратегии оптимизации цепочки поставок, важно поощрять команду создавать набор метрик, которые проясняют инициативу по цепочке поставок в целом. Роль руководства заключается не в принуждении к соблюдению правил, основанных на этих метриках, а в вызове стратегического мышления, лежащего в основе этих метрик. Часто первоочередной целью должно быть не улучшение значений метрик, а улучшение самого определения метрик.

На самом деле, все метрики не одинаково ценны для бизнеса. Обычно требуется значительное усилие, чтобы создать метрики, которые дают осмысленную перспективу на бизнес. Эта работа требует не только хорошего понимания бизнес-стратегии, но и глубоких знаний основных данных, которые сопровождаются множеством артефактов и других числовых особенностей. Таким образом, метрики прежде всего следует рассматривать как работу в процессе.

Мы обнаружили, что сильным показателем успеха любого проекта по цепочке поставок является качество метрик, которые устанавливаются в рамках инициативы. Однако это некоторый парадокс, но нет разумной метрики, чтобы оценить актуальность этих метрик. Вот несколько элементов, которые могут помочь оценить качество метрик:

• Существует ли согласие между различными командами цепочки поставок, что метрики отражают суть бизнеса? Или что бизнес-перспективы, неявно продвигаемые метриками, не являются краткосрочными или односторонними?
• Обладают ли метрики реальной глубиной при согласовании чисел с экономическими факторами? Простота желательна, но не за счет неправильного понимания общей картины.
• Правильно ли обрабатываются артефакты данных? Обычно при обработке данных, извлеченных из систем компании, требуется учесть десятки тонких “подводных камней”. Наш опыт говорит нам быть подозрительными, когда исходные данные кажутся достаточно хорошими, так как это обычно означает, что проблемы даже не были идентифицированы как таковые.
• Принимаемые на основе выбранных метрик решения имеют смысл? Если решение, которое в противном случае соответствует метрикам, не кажется разумным, то, скорее всего, оно им не является, и проблема часто заключается в самой метрике.

Во многом создание хороших метрик похоже на ориентацию гравитации к яме успеха: если ничто не вмешивается, естественным ходом действий является скатывание вниз по склону к дну, который, как оказывается, и является местом успеха. Знание точной глубины дна даже не является строго необходимым, если каждый шаг в пути к дну делает компанию лучше.

Разумные решения приводят к лучшей производительности

В цепочке поставок даже лучшие метрики имеют один существенный недостаток: числа обычно приходят с опозданием. Сроки поставки могут быть длительными, и принятые сегодня решения могут не иметь видимого влияния в течение недель, а то и месяцев. Кроме того, Количественная цепочка поставок, которая сильно акцентирует внедрение итеративных и инкрементальных улучшений, дополнительно усложняет этот вопрос. Однако использование неинкрементальных методов было бы еще хуже, хотя и по другим причинам. Поэтому метрики не могут быть единственными сигналами для оценки того, находится ли инициатива на правильном пути.

Принятие разумных решений является простым, но недооцененным сигналом превосходной производительности. Действительно, если ваша компания уже превосходно справляется со своей цепочкой поставок, скорее всего, системы продолжают производить “неразумные” решения, которые затем исправляются вручную командами цепочки поставок. Цель всех “оповещений” или подобных реактивных механизмов именно в том, чтобы смягчить текущие проблемы через непрерывные ручные корректировки.

Внедрение инициативы количественной цепочки поставок до того момента, когда все решения, сгенерированные полностью автоматизированным образом, считаются разумными или безопасными, является гораздо большим достижением, чем осознают большинство практиков. Здесь важно подчеркнуть “автоматизированные” решения: чтобы играть по правилам, не должно требоваться вмешательство человека. Под “разумными” мы понимаем решения, которые все еще выглядят хорошими для практиков даже после нескольких часов исследования случая, что естественно невозможно делать регулярно из-за огромного количества аналогичных решений, которые необходимо принимать каждый день.

Наш опыт показывает, что когда автоматизированные решения считаются надежными, производительность проявляется позже, когда эти решения фактически проходят испытание “в производстве”. Действительно, “тест на разумность” является очень строгим тестом для логики принятия решений. Если ваша компания уже использует нечто очень похожее на количественную цепочку поставок, то, скорее всего, существующие системы, которые у вас есть, далеки от прохождения этого теста. В результате, постоянно допускаются незамеченные ошибки, и компания платит большую цену за этот непрерывный поток проблем.

Затем, с операционной точки зрения, как только решения цепочки поставок становятся автоматизированными, команды цепочки поставок освобождаются от службы постоянного питания своей собственной системы непрерывным потоком ручных записей. Эти приросты производительности могут быть вложены там, где это действительно важно: для уточнения деталей стратегии цепочки поставок или для более тесного контроля поставщиков с целью решения проблем цепочки поставок, возникающих с их стороны. Повышение производительности, достигнутое благодаря чисто количественной оптимизации цепочки поставок, усиливается полученными преимуществами команд цепочки поставок, которые, наконец, могут найти время для улучшения процессов и рабочих процедур.