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-х годах. Однако намерение было уже очевидно. Эти компьютерные системы сразу же показались подходящими для автоматизации самых повторяющихся решений в цепочке поставок, таких как пополнение запасов.
Самое удивительное для меня в том, что это сообщество, похоже, несколько забыло о своих прежних амбициях. В наши дни, чтобы звучать футуристично, консалтинговые фирмы или IT-компании иногда используют термин “автономная цепочка поставок”, чтобы передать идею механизации рутинных решений в цепочке поставок. Однако мне термин “автономный” кажется неуместным. Мы не говорим “автономная логистика”, имея в виду конвейер с системой сортировки. Конвейер механизирован, а не автономен. Он по-прежнему требует технического контроля, но данное новшество составляет лишь малую часть рабочей силы, которую в противном случае потребовалось бы компании для перемещения товаров без конвейера. Что касается решений в цепочке поставок, цель не в том, чтобы полностью исключить участие человека в организации и добиться по-настоящему автономной технологии. Цель заключается лишь в том, чтобы освободить человека от самой трудоёмкой и примитивной части процесса. Именно такую точку зрения придерживались в публикациях четырёх десятилетий назад, и именно ей я следую в этой лекции.
В 1990-х годах, похоже, поставщики, как поставщики ERP, так и специалисты по оптимизации запасов, в значительной степени отказались от идеи достижения автоматизированных решений в цепочке поставок. Оглядываясь назад, можно сказать, что упрощённые модели 1970-х годов, которые в значительной степени игнорировали многие важные факторы, такие как неопределённость, были очевидной коренной причиной того, почему автоматизация в то время не увенчалась успехом. Однако устранение этой коренной причины оказалось вне возможностей технологий того периода. Вместо этого поставщики программного обеспечения переключились на системы управления исключениями. Эти системы должны генерировать оповещения о запасах на основе правил, установленных самой клиентской компанией. Логика была такова: пусть автоматизация обрабатывает большинство пунктов, которые можно обрабатывать автоматически, чтобы сосредоточить человеческое вмешательство на сложных случаях, выходящих за пределы возможностей машины.
Сразу отметим, что продажа системы управления исключениями — крайне выгодное дело для поставщика программного обеспечения, но гораздо менее выгодное для клиентской компании. Во-первых, управление исключениями перекладывает ответственность за эффективность цепочки поставок с поставщика на клиента. После внедрения системы управления исключениями, если результаты окажутся неудовлетворительными, вина возлагается на клиента. Они должны были настроить лучшие оповещения, чтобы предотвратить возникновение аварийных ситуаций с самого начала.
Во-вторых, создание системы для управления параметризованными оповещениями о запасах является простой задачей для поставщика программного обеспечения, если поставщику не нужно указывать какие-либо параметры, регулирующие исходные оповещения. Действительно, с аналитической точки зрения, способность генерировать хорошее оповещение о запасах означает, что вы можете разработать правило, которое надёжно выявляет неправильные решения по запасам. Если вы можете создать правило, способное надёжно выявлять неправильные решения по запасам, то по определению это же правило можно использовать для надёжного формирования правильных решений по запасам. Фактически, правило просто должно использоваться в качестве фильтра для предотвращения принятия неправильных решений.
В-третьих, управление исключениями — это довольно хитрая стратегия для поставщика программного обеспечения, использующая особенности человеческой психологии. Действительно, эти оповещения эксплуатируют механизм, известный эмпирическим психологам как “приверженность и последовательность”. Этот механизм создаёт сильную, но в значительной степени случайную привязанность к продукту. Короче говоря, как только сотрудники начинают корректировать числовые показатели запасов, это уже не произвольные числа. Это их числа, их работа, и поэтому сотрудники эмоционально привязываются к системе, независимо от того, обеспечивает ли система действительно превосходную эффективность цепочки поставок или нет.
В целом, управление исключениями является технологическим тупиком, поскольку в общем случае создание надёжных исключений и надёжных оповещений так же сложно, как и разработка надёжной автоматизации принятия решений. Если вы не можете доверять своим оповещениям и исключениям, то всё равно придётся проводить их ручную проверку, что сводит процесс к исходной точке. Процесс принятия решений остаётся полностью ручным.
Эта серия лекций о цепочках поставок включает два десятка эпизодов. На данный момент, можно сказать, все элементы, которые мы представили до сих пор, имели явную цель — довести дело до того момента, когда мы стоим на пороге запуска этой инициативы количественной оптимизации цепочки поставок в производство. Более конкретно, речь идёт о числовом рецепте, который мы хотим применить для прогнозирования, и именно эта задача является основой сегодняшней лекции.
В этих лекциях я использую термин “числовой рецепт” для обозначения последовательности вычислений, которые берут сырые исторические данные на входе и выдают окончательные решения. Эта терминология намеренно расплывчата, поскольку она отражает множество различных концепций, методов и техник, которые были подробно рассмотрены в предыдущих главах лекций. В первой главе мы увидели, почему цепочки поставок должны стать программируемыми и почему так важно иметь возможность внедрить такой числовой рецепт в производство. Постоянно растущая сложность самих цепочек поставок делает автоматизацию как никогда актуальной. Также существует необходимость превратить практику управления цепочками поставок в капиталистическое предприятие.
Вторая глава посвящена методологиям. Действительно, цепочки поставок являются конкурентными системами. Такое сочетание сводит на нет наивные методологии. Среди представленных нами методологий особое значение для сегодняшней темы имеют персонажи цепочки поставок и экспериментальная оптимизация. Персонажи цепочки поставок являются ключом к принятию правильной формы решений. Мы вернёмся к этому моменту через несколько минут. Экспериментальная оптимизация необходима для достижения действительно работающего результата. И снова, мы также вернёмся к этому моменту через несколько минут.
Третья глава рассматривает проблему, откладывая в сторону решение через персонажей цепочки поставок. Эта глава пытается охарактеризовать классы задач по принятию решений, которые необходимо решить. В ней показывается, что упрощённые подходы, основанные лишь на выборе правильного количества для каждого SKU, не соответствуют реальным ситуациям. Почти всегда присутствует глубина в форме решений.
Четвёртая глава рассматривает элементы, необходимые для понимания современной практики управления цепочками поставок, где программные компоненты представлены повсеместно. Эти элементы являются основными для понимания более широкого контекста, в котором работает числовой рецепт и на самом деле большинство процессов цепочки поставок. Действительно, многие учебники по цепочкам поставок подразумевают, что их методы и формулы работают в вакууме. Это не так. Практическое применение имеет значение.
Пятая и шестая главы посвящены прогнозированию и принятию решений соответственно. Эти главы охватывают интеллектуальные аспекты числового рецепта, включающие техники машинного обучения и методы математической оптимизации. Наконец, седьмая и текущая глава посвящена реализации инициативы количественной оптимизации цепочки поставок, цель которой — внедрить числовой рецепт в производство и затем поддерживать его работу. В предыдущей лекции мы обсудили, что требуется для старта инициативы, заложив при этом надлежащие технические основы, включая настройку правильного конвейера извлечения данных. Сегодня мы хотим перейти к финишной прямой и воплотить этот числовой рецепт в действие.
Мы начнём с краткого обзора предыдущей лекции, а затем перейдём к трём важным аспектам заключительных этапов инициативы. Первый аспект касается проектирования числового рецепта. Однако я не буду говорить о проектировании числовых составляющих рецепта, а о проектировании самого инженерного процесса, который окружает числовой рецепт. Мы рассмотрим, как подойти к этой задаче, чтобы дать инициативе шанс на появление удовлетворительного решения.
Второй аспект касается правильного развертывания числового рецепта. Действительно, компания начинает с ручного процесса и должна завершить его автоматизированным. Адекватное развертывание может в значительной степени снизить риск, связанный с этим переходом, или, точнее, снизить риск, связанный с числовым рецептом, который по крайней мере изначально окажется дефектным.
Третий аспект касается изменений, которые необходимо внести в компании после внедрения автоматизации. Мы увидим, что роли и задачи сотрудников подразделения цепочки поставок должны претерпеть значительные изменения.
В предыдущей лекции мы увидели, как запустить количественную инициативу в цепочке поставок. Давайте повторим самые важные моменты. Итоговый результат — это эксплуатационный числовой рецепт, то есть программное обеспечение, которое управляет определённой категорией решений в цепочке поставок, например, пополнением запасов. Этот числовой рецепт, как только он будет запущен в эксплуатацию, обеспечит ту автоматизацию, которую мы ищем. Решения не следует путать с числовыми артефактами, такими как прогнозы спроса, которые являются лишь промежуточными результатами, способствующими расчёту самих решений.
Объём инициативы должен соответствовать как системе цепочки поставок, так и её базовой прикладной среде. Внимание к системным свойствам цепочки поставок имеет решающее значение, чтобы не смещать проблему вместо её решения. Например, если оптимизация запасов в одном магазине розничной сети проводится за счёт ущерба другим магазинам, такая оптимизация теряет смысл. Также важно учитывать прикладной ландшафт, поскольку нам необходимо минимизировать первоначальные затраты на интеграцию данных. IT-ресурсы почти всегда являются узким местом, и мы должны быть осторожны, чтобы не усугубить это ограничение.
Наконец, мы определили четыре роли для этой инициативы, а именно: исполнитель по цепочке поставок, специалист по данным, учёный по цепочке поставок и практик по цепочке поставок. Исполнитель по цепочке поставок отвечает за стратегию, проведение изменений и арбитраж в выборе моделей. Специалист по данным отвечает за настройку канала передачи данных, который обеспечивает аналитическому слою доступ к соответствующим транзакционным данным. В этой лекции мы предполагаем, что канал передачи данных уже настроен. Учёный по цепочке поставок отвечает за реализацию числового рецепта, что включает множество инструментов, а не только умные алгоритмические решения. Наконец, практик по цепочке поставок — это человек, участвующий в процессе ручного принятия решений. Обычно он выполняет роль планировщика по запасам и спросу, хотя терминология может варьироваться. В начале инициативы от него ожидается переход к роли сетевого менеджера к концу инициативы. Мы вернёмся к этому моменту позже в лекции.
Цепочки поставок весьма благоприятны для автоматизации процессов принятия решений. Существует множество рутинных, высоко повторяющихся решений, которые носят количественный характер. К сожалению, подход, предлагаемый в большинстве учебников по цепочке поставок, обычно слишком упрощён. Я не утверждаю, что методы, представленные в учебниках, слишком просты или примитивны. Однако я лишь говорю о том, что задачи, представленные в этих учебниках, зачастую выглядят упрощёнными. Рассмотрим, к примеру, ситуацию с пополнением запасов. Учебный подход ищет оптимальную политику запасов для определения, сколько единиц следует заказать повторно. Это нормально, но зачастую такой ответ оказывается довольно неполным.
Например, нам может понадобиться решить, будут ли товары доставляться воздушным или морским транспортом, при этом оба способа представляют компромисс между сроком поставки и стоимостью транспортировки. Мы можем выбрать одного поставщика среди нескольких подходящих вариантов. Мы можем определить конкретный план отгрузки с несколькими датами отправки, если количество товара достаточно велико, чтобы требовать нескольких поставок.
Третья глава этой серии, посвящённая персонам в цепочке поставок, представила подробный обзор реальных ситуаций, в которых почти всегда присутствуют тонкости, выходящие за рамки выбора одной конкретной величины для данного SKU. Таким образом, учёный по цепочке поставок, совместно с практиком и исполнителем, должен начать с выявления полной формы решения. Полная форма решения должна включать все элементы, способствующие формированию фактической работы цепочки поставок. Выявление полной формы решения — задача непростая.
Во-первых, разделение труда, реализуемое в большинстве компаний, управляющих большой цепочкой поставок, обычно фрагментирует разные аспекты решения между несколькими сотрудниками и иногда между различными отделами. Например, один человек определяет количество для повторного заказа, в то время как другой решает, какому поставщику будет отправлен заказ.
Во-вторых, более тонкие аспекты решения, такие как просьба к поставщику ускорить заказ в случае резкого скачка спроса, часто остаются без внимания, поскольку практики не осознают, что эти аспекты также могут и должны быть автоматизированы. Я предлагаю зафиксировать описание этой полной формы решения не в виде серии слайдов, а в виде полноценного текста. В частности, текст должен разъяснять «почему». В чём именно заключается суть каждого аспекта решения? Действительно, в то время как некоторые аспекты решения могут быть достаточно очевидными, как, например, количество для повторного заказа, другие могут остаться упущенными или забытыми. Например, поставщик может предложить за определённую цену возможность вернуть товар в течение шести месяцев, если упаковки останутся нетронутыми. Применение этой опции или её отсутствие должны учитываться при принятии решения, но этому легко можно пренебречь.
Неспособность выявить полную форму решения в цепочке поставок или, что ещё хуже, неправильное её определение является одним из самых надёжных способов провала инициативы. В частности, реакция, обусловленная устаревшими практиками, является одной из самых частых ошибок, совершаемых в крупных компаниях. Суть такой реакции заключается в том, чтобы принять форму решения, которая на самом деле не имеет смысла для компании и её цепочки поставок, но всё же применяется, потому что подходит под существующее транзакционное программное обеспечение или под существующий процесс в организации.
Например, может быть принято решение, что пополнение запасов должно контролироваться посредством вычисления уровней резервного запаса вместо прямого расчёта фактических количеств для повторного заказа. Вычисление резервных запасов может показаться проще, так как эти значения уже присутствуют в ERP-системе. Таким образом, если значения резервных запасов будут пересчитаны, их можно будет легко внедрить в ERP, заменив ту формулу, которая фактически использовалась в DRP.
Однако резервные запасы имеют существенные недостатки. Даже такая базовая вещь, как минимальное количество заказа (MOQ), не укладывается в концепцию резервного запаса. По крайней мере, эта реализация предпочтительна не из-за программного обеспечения, а благодаря существующим процессам в организации.
Например, в розничной сети может быть две команды планирования: одна, отвечающая за пополнение запасов в магазинах, и другая, за комплектование распределительных центров. Однако эти две задачи по сути одно и то же. Как только для магазинов определены количества повторных заказов, остается нет места для решения вопроса о том, сколько персонала требуется для распределительных центров. Таким образом, миссии этих двух команд принципиально пересекаются. Такое разделение труда работает до тех пор, пока в процесс вовлечены люди. Люди хорошо справляются с неоднозначными требованиями. Однако эта неоднозначность представляет огромную преграду для любой попытки автоматизировать как пополнение запасов, так и требования к комплектованию персонала.
Этот антипаттерн, вызванный устаревшими практиками, очень соблазнителен, поскольку минимизирует объём необходимых изменений. Однако автоматизация решения меняет подход к его формированию. Часто, если сохранить устаревший дизайн, количественная инициатива в цепочке поставок обречена на провал.
Во-первых, это ещё больше усложняет разработку числового рецепта, которая и так является достаточно сложной задачей. Действительно, шаблоны, подходящие для разделения труда среди людей, не подходят для программного обеспечения, которое действует механически.
Во-вторых, устаревший подход исключает многие потенциальные преимущества автоматизации. Ведь во многих процессах цепочки поставок неэффективность наблюдается на границах внутри компании. Автоматизация устраняет необходимость в большинстве этих границ, которые были введены из-за специфической организации разделения труда, не имеющей смысла, если у вас есть один компьютер, управляющий всем процессом. Не позволяйте решениям, принятым два или три десятилетия назад, диктовать будущее вашей цепочки поставок.
После того как форма решения была правильно определена, учёный по цепочке поставок приступает к созданию самого числового рецепта, используя исторические транзакционные данные. В этой серии лекций выделено две главы, посвящённые тонкостям алгоритмических методов, которые можно использовать для обучения и оптимизации. Сегодня я не буду возвращаться к этим аспектам. Скажем так, учёный по цепочке поставок принимает ряд решений, чтобы создать первоначальный числовой рецепт, опираясь на свои знания, опыт и доступные инструменты.
При наличии правильных инструментов и методов этот первоначальный вариант может и должен быть реализован в течение нескольких дней, максимум пары недель. Дело не в передовых исследованиях, направленных на открытие какой-то новой технологии, а в адаптации известных методов с учетом особенностей интересующей цепочки поставок. Действительно, числовой рецепт должен очень строго отражать все нюансы решения, как они были определены в его полной форме.
Даже если учитывать очень компетентного учёного по цепочке поставок, использующего лучшие инструменты, которые можно купить, бессмысленно ожидать, что числовой рецепт окажется правильным с первой попытки. Цепочки поставок слишком сложны и запутаны, особенно их цифровые представления, чтобы числовой рецепт мог сработать идеально с первого раза. Внутренние числовые методы, такие как наличие метрик и контрольных показателей, не могут обнаружить ошибку в интерпретации данных учёного по цепочке поставок.
Для каждого столбца в каждой таблице, полученной из транзакционной системы, управляющей компанией, обычно существует несколько возможных способов интерпретации данных. Учитывая, что речь идёт о десятках столбцов, интегрируемых в числовой рецепт, ошибки гарантированы. Единственный способ оценить корректность числового рецепта — испытать его и получить реальные отзывы. Этот вопрос обсуждался во второй главе этой серии в лекции под названием «Экспериментальная оптимизация».
Таким образом, учёный по цепочке поставок должен сотрудничать с практиком, чтобы определить случаи, когда числовой рецепт в его текущей форме всё ещё даёт безумные результаты. Грубо говоря, учёный по цепочке поставок реализует панель управления, которая объединяет решение, которое было бы принято числовым рецептом сегодня, а практик пытается выявить строки, которые кажутся безумными.
Основываясь на этой обратной связи, учёные дополнительно оснащают числовой рецепт средствами контроля. Этот контроль принимает форму индикаторов, которые пытаются ответить на вопрос: почему в данном контексте было принято это, на первый взгляд, безумное решение? На основе таких данных можно решить, требует ли числовой рецепт доработки, например, из-за неправильного моделирования экономического драйвера, или же безумное решение оказалось правильным, просто оно отличается от того, как ранее работала компания.
Экспериментальная оптимизация — это высоко итерационный процесс. Как правило, при наличии правильных инструментов один учёный по цепочке поставок, работающий полный рабочий день, должен быть способен представлять новую итерацию числового рецепта каждый день для практикующего специалиста. Если числовой рецепт правильно оснащён индикаторами, то по мере продвижения инициативы практикующему специалисту не потребуется более двух часов в день для предоставления обратной связи по последней итерации числового рецепта.
Итерационный процесс завершается, когда числовой рецепт перестаёт генерировать безумные результаты, то есть когда практик больше не может идентифицировать решения, явно наносящие ущерб компании. Отсутствие безумных решений может показаться низкой планкой по сравнению с нашей общей целью — генерировать лучшие решения, чем при ручном процессе. Однако следует помнить, что числовой рецепт изначально разрабатывался для математической оптимизации долгосрочного экономического интереса компании. Если результаты адекватны, то оптимизация работает, а что ещё более важно, это также доказывает, что сам оптимизационный критерий в некоторой степени корректен.
Хотя высоко итерационный инженерный процесс числового рецепта может исправить множество проблем, присутствующих в первоначальной реализации, одних итераций недостаточно, если сама перспектива, лежащая в основе оптимизации, неверна. В этой серии лекций я уже говорил, что оптимизация должна проводиться по финансовому показателю, то есть метрике, выраженной в евро или долларах. Однако позвольте уточнить: неиспользование финансовой метрики — это ошибка, которая ставит под угрозу всю инициативу.
К сожалению, крупные организации обычно избегают финансовых метрик. Вместо этого они предпочитают идеализированные метрики, которые выражаются в процентах и представляют собой некое совершенство, которого можно было бы достичь, если бы в зависимости от случая было достигнуто либо 0 процентов, либо 100 процентов. Естественно, совершенство не принадлежит этому миру, и такая предельная ситуация никогда не будет достигнута. Уровни обслуживания являются, например, архетипом идеализированной метрики. Уровень обслуживания 100% недостижим, так как для этого потребовалось бы необоснованно большое количество запасов.
Некоторые менеджеры в крупных компаниях обожают эти идеализированные метрики. Команды регулярно собираются для обсуждения того, что можно сделать для дальнейшего улучшения этих показателей. Поскольку эти метрики неизбежно зависят от факторов, находящихся вне контроля компании, их можно бесконечно пересматривать. Например, уровни обслуживания зависят от объёма спроса, выраженного клиентами, и от сроков поставки, предлагаемых поставщиками. Ни спрос, ни сроки поставки не находятся под полным контролем компании.
Эти идеализированные метрики в некоторой степени работают как корпоративные цели, когда люди остаются в процессе принятия решений, поскольку на них изначально не уделяется особого внимания. Например, даже если все согласятся, что уровень обслуживания должен быть повышен, планировщики всё равно будут оставлять много недокументированных исключений. Уровень обслуживания будет систематически повышаться, за исключением случаев, когда риск запасов слишком высок, когда минимальный объём заказа слишком велик, если продукт скоро будет выведен из ассортимента или если для продукта не осталось бюджета и т.д.
К сожалению, эти идеализированные метрики становятся ядом при внедрении автоматизированного процесса. Дело в том, что эти метрики являются неполными и не отражают того, что на самом деле желаемо для компании. Например, достижение 100% уровня обслуживания нежелательно, поскольку это привело бы к массовым излишкам запасов. Возможно – не неразумно, а возможно – попытаться реализовать все эти ограничения, все эти исключения поверх идеализированных метрик. То есть создать числовой рецепт, нацеленный на идеализированные метрики с множеством ограничений, имитирующих то, что может происходить в голове планировщика. Например, можно было бы определить правило, согласно которому уровень обслуживания должен повышаться, если запасы остаются ниже уровня, достаточного для четырех месяцев. Однако такая стратегия разработки и фактической реализации числового рецепта чрезвычайно ненадежна. Прямая финансовая оптимизация — это значительно более безопасный и превосходный путь.
Для достижения эффективного сотрудничества между специалистом по цепочке поставок — или, скорее, специалистами, во множественном числе — и учёным по цепочке поставок, я рекомендую с самого начала принять стратегию двойного запуска. Числовой рецепт должен выполняться ежедневно параллельно с уже существующим ручным процессом. При двойном запуске компания фактически принимает решение дважды через два конкурирующих процесса. Однако, несмотря на трения, двойной запуск предлагает существенные преимущества. Во-первых, специалист по цепочке поставок нуждается в свежих решениях, отражающих текущую ситуацию, чтобы провести свою оценку. В противном случае специалист даже не сможет понять автоматизированное решение, не сможет выделить те его части, которые кажутся безумием. Действительно, с точки зрения специалиста решения, отражающие ситуацию цепочки поставок трёхнедельной давности, уже устарели. Нет большого смысла тратить часы на пересмотр прошлых уровней запасов.
Напротив, если автоматизированные решения свежи и отражают текущую ситуацию, то они конкурируют с решениями, которые специалист намеревается принять вручную. Эти автоматизированные решения можно пока рассматривать как предложения.
Во-вторых, ежедневный запуск числового рецепта обеспечивает полное функциональное тестирование всего потока данных каждый день. Дело в том, что числовой рецепт должен возвращать не только разумные результаты, но и безупречно работать с точки зрения IT-инфраструктуры. Цепочки поставок и так достаточно хаотичны, и числовой рецепт не должен добавлять еще один слой хаоса. Внедрение рецепта в условиях, эквивалентных производственным, как можно раньше гарантирует, что редкие проблемы выявятся своевременно, и, таким образом, специалист по данным и учёные цепочки поставок смогут их быстро исправить. Как правило, к концу первой трети — то есть к концу третьего месяца после начала инициативы по количественным поставкам — двойной запуск должен быть введён в эксплуатацию, даже если числовой рецепт еще не готов к работе в производственной среде.
Также, к концу первого месяца двойного запуска, если учёный справится со своей задачей должным образом, специалист должен начать замечать закономерности в списке автоматизированных решений, которые в противном случае были бы упущены, даже если остаются некоторые безумные строки, требующие дальнейшего улучшения числового рецепта.
Как только двойной запуск вступит в силу, от специалиста по цепочке поставок ожидается, что он будет уделять некоторое время — один или два часа в день — на анализ решений, сгенерированных числовым рецептом, и стараться выявлять те моменты, которые всё ещё кажутся не вполне разумными. Однако иногда ситуация просто оказывается неясной. Решение может показаться неожиданным — возможно, числовой рецепт работает медленно, а может и нет. В таком случае специалист испытывает неуверенность и должен попросить учёного добавить дополнительные средства контроля, чтобы прояснить ситуацию. Этот процесс как раз и называется в данной серии лекций «открытием черного ящика» числового рецепта. Открытие черного ящика — это процесс, в ходе которого числовой рецепт становится максимально прозрачным для заинтересованных сторон. Это хорошо, даже необходимо для того, чтобы выстроить доверие к числовому рецепту.
При условии, что автоматизированные решения собраны в таблице на панели управления, наиболее типичным инструментом контроля будут дополнительные столбцы рядом со столбцами с решениями. Например, если речь идет о количествах для повторного заказа, то очевидными дополнительными столбцами могут быть такие, как количество запасов на складе, ожидаемое среднее время поставки, ожидаемый средний ежедневный спрос и т.д. Этот инструментальный контроль имеет решающее значение для того, чтобы специалист мог быстро оценить разумность автоматизированных решений. Однако мы должны учитывать, сколько дополнительного контроля накладывается поверх числового рецепта. Каждый индикатор, вводимый для иллюстрации автоматизированного решения в рамках процесса открытия черного ящика, еще больше загромождает представление о самих решениях. Чрезмерное количество, пусть даже чего-то хорошего, может обернуться негативными последствиями. Если спустя два месяца работы специалист продолжает регулярно запрашивать дополнительные показатели, в то время как поток данных уже стабилизирован, тогда у нас может возникнуть проблема.
Коренная причина проблемы может быть связана с изощренными элементами числового рецепта. В главах 5 и 6 этой серии мы увидели, что не все техники и модели равны с точки зрения интерпретируемости. Многие модели по своей природе очень непрозрачны, даже для специалистов по данным, которые их используют. Я не собираюсь сегодня подробно обсуждать классы моделей, подходящие для интерпретации. Для целей данного обсуждения я просто предположу, что модели, встроенные в числовой рецепт, должным образом интерпретируемы с точки зрения цепочки поставок. В этом контексте, когда инициатива, кажется, застревает из-за бесконечного потока запросов на дополнительное оборудование контроля, наиболее вероятной коренной причиной является паралич анализа. Специалист по цепочке поставок чрезмерно анализирует числовой рецепт. Это и есть суть паралича анализа. Специалист подвергает числовой рецепт такому уровню проверки, который превосходит тот, что применяется к ручному процессу. Задача руководителя цепочки поставок — обеспечить, чтобы инициатива не застряла в параличе анализа. И если это всё же происходит, что может случиться, то руководителю следует мягко напомнить команде, что и ручные решения несовершенны. Мы стремимся к улучшению по сравнению с ручным процессом, а не к совершенству.
Как только числовой рецепт перестанет генерировать безумные решения и когда сами решения будут сопровождаться, как кажется, адекватным уровнем контроля, наступает время для постепенного перехода от ручного процесса к автоматизированному. Как правило, эта точка должна быть достигнута в течение двух–четырёх месяцев после начала двойного запуска. С первого дня двойного запуска числовой рецепт должен работать в рамках всей инициативы. Таким образом, в теории переход от ручных решений к автоматизированным может произойти практически за одну ночь.
Однако на практике часто всё обстоит не так, как в теории. Если речь идет о крупной компании, важно перевести все решения с одного процесса на другой за одну ночь. Цепочки поставок чрезвычайно сложны, и мы должны ожидать неожиданных ситуаций. Поэтому разумнее начать с небольшого операционного объёма, например, с одной товарной категории, и затем расширяться. На самых ранних этапах перехода целесообразно выделять одну или, может быть, две недели на каждую итерацию. И специалист по цепочке поставок, и учёные цепочки поставок должны внимательно отслеживать, как реализуются автоматизированные решения. И если в этом ограниченном объёме операций ничего неожиданного не происходит, даже если числовой рецепт больше не генерирует кажущихся безумными решений, могут всё же возникнуть проблемы с интеграцией автоматизированных решений в транзакционные системы. Как только числовой рецепт будет работать в производстве несколько недель, даже если масштаб был относительно небольшим, целесообразно ускорить итерации.
Переход может сопровождаться более значительными приростами на каждой итерации, и продолжительность итераций может быть сокращена, возможно, до двух итераций в неделю. Действительно, общий временной промежуток перехода к автоматизированному процессу должен быть достаточно коротким. В противном случае сама задержка перехода создаёт новые виды рисков. Цепочка поставок, как и её прикладное окружение, постоянно меняются. Как правило, переход не должен превышать двух–четырёх месяцев в зависимости от масштаба и сложности компании.
По мере того как цепочка поставок переходит от ручного процесса к автоматизированному, внутри организации также должны произойти изменения. Большие организации известны своей инертностью к изменениям, но существует два принципиально различных направления изменений. Организация может добавить процесс или может убрать процесс.
Убрать процесс гораздо сложнее, чем добавить. Добавление процесса предполагает найм сотрудников, и единственное противодействие в этом случае исходит от самого верха компании, так как это требует дополнительной бюджетной линии. Удаление процесса означает увольнение сотрудников или, по крайней мере, ликвидацию их должностей с последующим сохранением и переобучением персонала. При удалении процесса ситуация обратная: можно ожидать сопротивления со стороны всей организации, за исключением её самого верха.
Самый простой способ внедрения числового рецепта в производство — сохранить двойной запуск на неопределённый срок. Существующий ручной процесс сохраняется и теперь использует автоматизированные решения в качестве простых предложений. Этот подход кажется безопасным и может даже дать незначительные преимущества, поскольку автоматические предложения помогают специалистам выявлять одни из самых серьёзных ошибок, присущих ручному процессу. Однако бессрочное сохранение двойного запуска приводит к оседанию процесса, когда организация не избавляется от чего-либо.
Чтобы практики в цепочке поставок стали капиталистическим предприятием — производительным активом, организация должна отказаться от ручного процесса. Ручной процесс — это тупик; он не будет совершенствоваться с течением времени. Организация должна перенаправить всё время и энергию, затрачиваемые на ручной процесс, на постоянное улучшение автоматизированного. Сохранение ручного процесса лишь мешает максимально использовать преимущества автоматизации и того, что она может предложить. В частности, пока продолжаются ручные вмешательства, ничего не является по-настоящему воспроизводимым, а оптимизация требует воспроизводимости.
Автоматизация принятия решений, даже если речь идёт о банальных и повторяющихся, представляет собой сдвиг в парадигме управления цепочками поставок. Изменение настолько значительное, что его можно было бы полностью отвергнуть. Однако перемены неизбежны. Два века постепенной механизации нашей экономики ясно показали: как только что-то можно автоматизировать, оно автоматизируется. Со временем возврата к прежнему состоянию не будет. Компания Lokad управляет около 100 цепочками поставок в условиях высокой автоматизации, что является живым доказательством того, что автоматизация цепочек поставок уже здесь; она просто пока не получила широкого распространения.
Одно из крупнейших изменений, которое предстоит внедрить нашим клиентам, касается роли планировщика спроса и предложения. Основной формат этой роли, который носит различные названия в отрасли — такие как менеджеры по запасам, категоричные менеджеры или менеджеры по снабжению — предполагает, что сотруднику поручается управление списком SKU, количество которых может варьироваться от 50 до 5000 в зависимости от объёма потока. Планировщик отвечает за постоянное наличие SKU из этого списка, инициируя пополнение запасов или запуск производственных партий, или то и другое. Деление труда очевидно: с увеличением числа SKU увеличивается и количество планировщиков.
Основное внимание планировщика направлено внутрь. Этот человек тратит много времени на анализ чисел, которые либо объединены в таблицу, либо отображаются на панелях управления. Планировщики могут использовать корпоративные программные инструменты, но почти всегда окончательные решения они принимают в таблицах, которые ведут лично. Цель таблицы – предоставить доступный и полностью настраиваемый числовой контекст для поддержки решений, принимаемых планировщиком. Рутинная работа планировщика заключается в еженедельном, а возможно и ежедневном, пересмотре полного списка SKU.
Однако, как только числовой рецепт внедрен в производство, нет смысла продолжать ручной пересмотр списка SKU планировщиком. Планировщик должен перейти к роли менеджера сети. Освободившись от рутин, связанных с данными, менеджер сети может уделять время общению с участниками сети – как с поставщиками вверх по цепочке, так и с клиентами вниз по цепочке – и пересматривать предпосылки, лежащие в основе конструкции числового рецепта. Основная опасность для числового рецепта заключается не в потере его точности, а в утрате его актуальности. Менеджер сети пытается выявить то, что пока не видно через призму данных. Речь идет не о микроменеджменте числового рецепта или о внесении числовых корректировок в сами решения, а о выявлении факторов, которые числовой рецепт игнорирует или неправильно интерпретирует.
Менеджер сети обобщает выводы, предназначенные как для ученых в области цепочки поставок, так и для руководителей цепочки поставок. На основании этих выводов ученые могут корректировать или перестраивать числовой рецепт с учетом обновленного понимания ситуации.
К сожалению, противодействовать внедрению числового рецепта – не единственный способ для планировщика сохранить статус-кво. Другая стратегия заключается в продолжении прежней рабочей рутины: продолжать пересматривать список SKU, но вместо того чтобы отменять решения, просто докладывать все обнаруженные, если таковые имеются, замечания ученому в области цепочки поставок. Люди любят свои привычки, а сотрудники крупных компаний – еще больше.
Проблема такого подхода в том, что как только автоматизация вступает в силу, ученые в области цепочки поставок могут напрямую наблюдать результаты автоматизированного процесса – и положительные, и отрицательные. У планировщика и ученых есть доступ к одним и тем же данным; однако ученый, по определению, имеет доступ к более мощным аналитическим инструментам, чем планировщик. Таким образом, после внедрения автоматизации дополнительная ценность обратной связи планировщика быстро уменьшается, когда речь идет о постоянном улучшении числового рецепта.
Так как у планировщика теперь больше времени на анализ, он, вероятно, попросит ученого разработать больше индикаторов и панелей управления. Это приводит к «KPI-туризму»: увеличивается число индикаторов для обзора до такой степени, что их простое рассмотрение становится полноценной работой. Такая нагрузка также отвлекает ученых. На этом этапе, после внедрения, улучшение числового рецепта требует довольно глубокого понимания слабых мест фактической реализации. Ученый находится в наилучшей позиции для этой работы, в то время как планировщик менее подходит для этого. Чтобы быть полезным, планировщик должен стать менеджером сети и, как уже отмечалось ранее, начать смотреть наружу. Иначе позиция планировщика превращается в KPI-туризм.
Работа руководителя цепочки поставок во многом определяется организацией и её процессами. Пока повседневные решения остаются результатом ручного процесса, у организации нет иного выхода, как принять разделение труда, при котором каждый планировщик работает со своим списком SKU. Таким образом, руководитель цепочки поставок прежде всего является менеджером команды планировщиков. Если компания достаточно велика, чтобы оправдать наличие среднего звена руководства, то руководитель может управлять планировщиками косвенно. Тем не менее, структура цепочки поставок остается неизменной: пирамида, в основании которой находятся планировщики. По необходимости быть хорошим руководителем цепочки поставок означает быть хорошим наставником для этих планировщиков. Руководитель не принимает решения по цепочке поставок – решения принимают сами планировщики. Улучшение решений в первую очередь зависит от того, насколько лучше работают планировщики.
Поставщики программного обеспечения для цепочки поставок утверждают, что их инструменты могут иметь значение. Однако, как мы уже отмечали, для принятия этих решений почти всегда используются таблицы, независимо от того, сколько инструментов внедрено в компании. Таким образом, в конечном итоге все сводится к тому, что планировщики делают со своими собственными таблицами.
Как только класс решений в цепочке поставок автоматизирован, роль руководителя цепочки поставок существенно меняется. Работа больше не заключается в наставничестве большой команды планировщиков, выполняющих вариации одной и той же задачи. Теперь задача руководителя цепочки поставок – сделать все возможное, чтобы компания максимально использовала автоматизацию цепочки поставок. Руководитель должен стать владельцем программного продукта, который фактически управляет решениями в цепочке поставок.
Действительно, фокус и вклад ученых в области цепочки поставок направлены внутрь, как и прежние усилия планировщиков. Ученые могут улучшить числовой рецепт только изнутри. От них не требуется перестраивать прикладной ландшафт или более широкие процессы компании. Это задача руководителя цепочки поставок. В частности, руководитель становится ответственным за разработку дорожной карты для непрерывного совершенствования автоматизации.
Пока решения принимались планировщиками, дорожная карта была во многом самоочевидной. Планировщики продолжали делать то, что они делают, и задача на следующий квартал во многом была похожа на задачу предыдущего. Однако как только внедряется автоматизация, улучшение числового рецепта почти всегда включает в себя выполнение чего-то, что никогда ранее не делалось. При создании программного обеспечения, если вы все делаете правильно, вы не повторяетесь – вы движетесь дальше. Как только одно понимание достигнуто, необходимо искать новое. Задача людей, работающих под руководством владельца программного продукта, по своей природе постоянно меняется.
Новые направления и цели не падают с неба. Ответственность за то, чтобы направлять развитие программного продукта для цепочки поставок в благоприятное русло, лежит на руководителе цепочки поставок.
Большинство ежедневных проблем, с которыми сталкиваются цепочки поставок, являются проблемами программного обеспечения. Так было уже более десяти лет в развитых странах, даже в компаниях, где все решения вручную выводятся из таблиц. Эта ситуация является прямым следствием того, что цепочки поставок находятся на пересечении множества систем: ERP, CRM, WMS, OMS, PIM и десятков других аббревиатур из трех букв, любимых поставщиками корпоративного программного обеспечения, описывающих различные компоненты, содержащие все данные, представляющие интерес для цепочки поставок. Цепочки поставок требуют сквозного взгляда на бизнес, и, как результат, они объединяют большую часть прикладного ландшафта компании. Однако большинство компаний, по-видимому, до сих пор выбирают руководителей цепочки поставок, которые знают очень мало о программном обеспечении. Что еще хуже, некоторые из этих руководителей не собираются когда-либо изучать программное обеспечение. Такая ситуация является антишаблоном «анализаторской шины в цепочке поставок». Когда я говорю о программном обеспечении, это следует понимать как тему, которую я освещал в четвертой главе этой серии лекций, с темами от вычислительного оборудования до инженерии программного обеспечения.
В наши дни неграмотность в области программного обеспечения среди топ-менеджеров цепочки поставок сулит компании огромные проблемы. Либо руководство считает, что справится без экспертизы в программном обеспечении, либо уверено, что справится с привлечением внешних экспертов по программному обеспечению. В любом случае последствия будут не самыми лучшими.
Если топ-менеджмент считает, что он сможет обойтись без экспертизы в программном обеспечении, то компания потеряет позиции на всех электронных каналах – как с точки зрения продаж, так и закупок. Однако, поскольку многие сотрудники понимают, что эти электронные каналы играют важную роль, независимо от того, нравится ли это руководству или нет, теневой IT будет процветать. Более того, будьте уверены, что при следующем крупном переходе на новое программное обеспечение в компании этот переход будет крайне плохо организован, что приведет к длительным периодам низкого качества обслуживания из-за проблем с программным обеспечением, которых следовало бы вообще избежать.
Если руководство считает, что сможет справиться с привлечением сторонних экспертов по программному обеспечению, ситуация немного лучше, но не существенно. Полагаться на сторонних экспертов можно, если у вас узкая, самодостаточная задача, например, обеспечение соответствия процесса найма определенному нормативу. Однако задачи цепочки поставок не являются изолированными; они распространяются на всю компанию и очень часто – даже за ее пределами. Самая частая ловушка, связанная с мыслью о том, что экспертизу можно аутсорсить, заключается в том, что на крупных поставщиков программного обеспечения выдавливаются необоснованно большие суммы денег в надежде, что они решат проблемы за вас. Неудивительно – они этого не сделают. Единственное средство от этих проблем – это элементарная грамотность в области программного обеспечения на уровне топ-менеджмента.
Сегодня мы очертили путь внедрения автоматизированных решений в цепочке поставок. Этот процесс представляет собой смесь дизайна, инженерии и управления изменениями. Это трудный путь, на котором множество кажущихся простыми или обнадеживающими вариантов ведут прямо к провалу инициативы. Для успеха инициатива требует значительной эволюции ролей и задач как топ-менеджмента цепочки поставок, так и ее сотрудников.
Для компаний, глубоко укоренившихся в своих ручных процессах, проведение такой инициативы может показаться непреодолимым, и поэтому сохранение статус-кво кажется единственным вариантом. Однако я не согласен с этим выводом по двум пунктам. Во-первых, хотя путь и труден, он дешев, по крайней мере по сравнению с большинством бизнес-инвестиций. Реинвестировав ежегодные затраты на пятерых планировщиков спроса, компания может автоматизировать работу 50 планировщиков. Естественно, крупные поставщики корпоративного программного обеспечения могут утверждать, что для старта требуется десятки миллионов долларов, но существуют гораздо более экономичные альтернативы. Во-вторых, путь может быть трудным, но он вовсе не является опциональным. Компании, в которых работают целые армию клерков, принимающих повседневные, повторяющиеся решения в цепочке поставок, также страдают от длительных, самоналоженных сроков, обусловленных внутренними процессами. Такие компании не смогут оставаться конкурентоспособными по сравнению с теми, которые автоматизировали процесс принятия рутинных решений. Конкурентное преимущество от автоматизации всегда невелико в начале; однако, по мере того как автоматизацию можно совершенствовать, а ручной процесс – нет, конкурентное преимущество становится экспоненциально сильнее со временем. На данный момент автоматизированные решения в цепочке поставок могут восприниматься как нечто футуристическое, но через два десятилетия будет обратная ситуация. Ручные процессы станут восприниматься как архаичные остатки прошлой эпохи.
На этом лекция на сегодня завершается. Через минуту мы перейдем к вопросам. Следующая лекция состоится в первую неделю ноября, в среду, в 15:00 по парижскому времени, как обычно. Мы вернемся к третьей главе с персонажем цепочки поставок. Речь пойдет о вымышленной компании Stuttgart, которая занимается автомобильным послепродажным обслуживанием. Мы увидим, что автомобильная отрасль – это отрасль отраслей, и она представляет собой целый ряд довольно специфичных вызовов, которые, как и прежде, недостаточно отражены в учебниках по цепочке поставок.
Давайте перейдем к вопросам.
Вопрос: Требует ли количественная цепочка поставок своего идеального разделения труда?
Да, это может быть постепенный переход, но суть в том, что разделение труда в ручном процессе определялось тем, что планировщик может управлять только ограниченным числом 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, так как для него это может оказаться отвлекающим. Нет необходимости вовлекать генерального директора в каждую мелкую баталию.
Миссия директора по цепочке поставок заключается в том, чтобы работать с руководителем финансов, маркетинга и отдела продаж для достижения согласия относительно того, как измерять финансовое воздействие таких факторов, как качество обслуживания. Это их задача. Нет необходимости в согласовании различных метрик, поскольку они уже предварительно унифицированы благодаря работе, проведенной под руководством главы цепочки поставок или директора по цепочке поставок, в зависимости от принятой в компании должности.
На этом сегодняшняя лекция заканчивается. Увидимся в следующий раз в первую неделю ноября.
