Внедрение автоматизированных решений в поставочную цепочку - Лекция 7.2

00:00 Введение
03:39 Автоматизация всегда была целью
06:28 Управление и предупреждения об исключительных ситуациях
10:27 История до настоящего момента
14:33 Наше внедрение в производство сегодня
15:59 Резюме: результаты, объем и роли
19:01 Выявление формы решения
23:00 Ответ, основанный на наследии
27:20 Итерации к нулевому проценту безумия
32:30 Амбициозные метрики
36:27 Двойной запуск: ручной + механический
39:19 Анализ паралича
43:21 Постепенное внедрение автоматизации
46:08 Процессная седиментация
48:57 От планировщика к менеджеру сети
52:46 Турист по KPI
54:58 Лидерство: от тренера до владельца продукта
58:46 Аналоговый босс поставочной цепочки
01:02:25 Заключение
01:04:44 7.2 Внедрение автоматизированных решений в производство - Вопросы?

Описание

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

Полный текст

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третий аспект связан с изменениями, которые должны произойти в компании после внедрения автоматизации. Мы увидим, что роли и задачи людей в подразделении цепи поставок должны претерпеть существенные изменения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новые направления и цели не падают с неба. Ответственность за направление развития программного продукта цепи поставок лежит на исполнительном директоре цепи поставок.

Большинство повседневных проблем, с которыми сталкиваются цепи поставок, являются проблемами программного обеспечения. Это уже более десяти лет так в развитых странах, даже в компаниях, где все решения принимаются вручную на основе электронных таблиц. Эта ситуация является прямым следствием того, что цепи поставок находятся на перекрестке множества систем: ERP, CRM, WMS, OMS, PIM и десятки трехбуквенных аббревиатур, любимых поставщиками корпоративного программного обеспечения, описывающих различные части корпоративного программного обеспечения, содержащие все интересующие данные для цепей поставок. Цепи поставок требуют комплексного взгляда на бизнес, и в результате они связывают большую часть прикладного ландшафта компании. Однако большинство компаний, кажется, все еще выбирают лидеров цепи поставок, которые мало что знают о программном обеспечении. Еще хуже, некоторые из этих лидеров не имеют намерения узнать что-либо о программном обеспечении. Это является анти-паттерном “аналитической цепи поставок”. Когда я говорю о программном обеспечении, это следует понимать как ту тему, которую я рассмотрел в четвертой главе этой серии лекций, с темами, начиная от вычислительного оборудования до программной инженерии.

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

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

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

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

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

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

Давайте посмотрим на вопросы.

Вопрос: Требуется ли квантитативной цепи поставок собственный идеальный способ разделения труда?

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

Вопрос: Использование процентов вместо финансовых показателей помогает скрыть неэффективность устаревшего процесса. Какова вероятность успеха инициативы в таком случае?

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

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

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

Вопрос: Крупные компании используют гораздо больше KPI, чем им нужно. Как вы вызываете все KPI при внедрении инициативы?

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

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

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

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

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

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

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

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

Вопрос: С учетом представленной перспективы, как вы подходите к проблеме согласования различных прогнозов компании, таких как продажи, запасы и другие?

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

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

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

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

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

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

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

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

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

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

Это завершает сегодняшнюю лекцию. Увидимся в следующий раз в первую неделю ноября.