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

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

Инициатива

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

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

Амбиции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технологии

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

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

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

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

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

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

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

Этапы проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоговые результаты

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

Скрипты как итоговый результат

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

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

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

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

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

Панели мониторинга состояния данных

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

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

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

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

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

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

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

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

Приоритетные панели принятия решений

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

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

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

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

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

Объяснение числовых результатов

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

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

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

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

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

Стратегические панели

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

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

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

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

Инспекторские дашборды

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

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

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

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

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

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

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

Метрики можно манипулировать

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

История обратного проектирования метрик

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

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

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

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

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

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

Подводный камень успеха

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

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

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

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

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

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

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

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

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

Доведение инициативы Внедрения количественной цепочки поставок до такой точки, где все решения – генерируемые полностью роботизированным способом – считаются разумными или безопасными, является куда большим достижением, чем осознают большинство практиков. Здесь важен акцент на «роботизированных» решениях: согласно правилам, не должно требоваться никакого человеческого вмешательства. Под «разумными» мы понимаем решения, которые всё ещё выглядят убедительно для специалистов даже после нескольких часов изучения вопроса; что, естественно, невозможно делать регулярно ввиду огромного количества подобных решений, принимаемых ежедневно.

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

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