Продукты проекта

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

Скрипты в качестве продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Раскрытие числовых результатов

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

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

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

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

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

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

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

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

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

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

Информационные панели инспектора

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

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

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

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

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

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