Результаты проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инспекторские панели мониторинга

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

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

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

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

Одна из самых странных проблем, с которыми столкнулась компания Lokad при исследовании наборов данных цепочки поставок, была связана с так называемыми телепортированными деталями. Компания — в данном случае авиалиния — имела запас авиадеталей как в материковой Европе, так и в Южной Азии. Поскольку безопасность полётов является абсолютным требованием для эксплуатации, компания вела безупречные записи о перемещении всех деталей. Однако, используя недавно разработанную инспекторскую панель мониторинга, команда Lokad обнаружила, что некоторые детали перемещались из Азии в Европу и наоборот, якобы всего за 2 или 3 минуты. Поскольку авиадетали транспортируются самолётами, время перевозки, как ожидалось, должно было составлять как минимум дюжину часов — определённо не минуты. Сразу возникло подозрение на проблему с часовыми поясами или иными вопросами времени, однако временные записи также оказались безупречными. Затем, при дальнейшем анализе данных, выяснилось, что детали, которые, казалось, были телепортированы, на самом деле использовались и устанавливали на самолёты в месте их посадки, что было ещё более озадачивающим. Позволив командам цепочки поставок самим взглянуть на инспекторские панели мониторинга, загадка наконец была раскрыта. Телепортированные детали оказались колёсами самолётов, состоящими из двух половинных колёс и шины. Колесо можно было демонтировать, разобрав две половинные части и шину. В крайнем случае, если обе половинные части и шина извлекаются, физически ничего не остаётся. Таким образом, полностью разобранное колесо можно было свободно собрать заново в любом месте, полностью игнорируя его исходное местоположение.

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