Антипаттерны в цепочке поставок

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

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

Плохое руководство

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

Запрос предложений из ада

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

Хрупкий POC

Проведение POC (proof of concept) актуально, если вы планируете приобрести простую, практически товарную услугу, например, услугу печати визитных карточек. Инициатива в области цепочки поставок по своей природе сложна. Цепочка поставок требует координации множества участников. Существует множество уровней данных, которые необходимо использовать. Есть десятки рабочих процессов, которые нужно учитывать. POC или пилотные проекты малого масштаба приносят больше вреда, чем пользы, поскольку по своей сути они упускают из виду главное достоинство успешной инициативы по оптимизации цепочки поставок: её способность работать в масштабах. Большинство людей привыкли к принципу эффекта масштаба, однако, когда речь идет об оптимизации цепочки поставок, мы, прежде всего, сталкиваемся с эффектом недостижения экономии от масштаба, когда с ростом сложности проблемы правильные решения давать становится все сложнее. Достижение успеха для небольшого распределительного центра вовсе не гарантирует, что решение будет работать так же эффективно при управлении десятками различных распределительных центров.

Отрицание неопределенности

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

Доверие стажеру

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

Смерть от планирования

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

Разделение прогнозирования и оптимизации

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

Франкенштейнизация программного обеспечения

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

Инициативы, управляемые модными словами

Около 2010 года в розничной торговле было модно искать способы использовать погодные прогнозы для уточнения прогнозов спроса. В 2012 году стало популярно учитывать данные социальных сетей при составлении прогнозов спроса. В 2014 году доминировали технологии Big Data, которые в 2016 году сменил машинное обучение. Каждый следующий год приносит новую волну модных терминов. Хотя повторное рассмотрение старой проблемы с новой точки зрения никогда не вредит, потеря фокуса на основных проблемах почти неизбежно ставит под угрозу любую уже начатую инициативу. Если что-то кажется слишком хорошим, чтобы быть правдой, то, вероятно, так оно и есть. Улучшения в цепочке поставок достигаются нелегким трудом. Убедитесь, что любая новинка, которую вы хотите внедрить, действительно направлена на решение основных проблем, с которыми сталкивается ваша цепочка поставок.

Плохая реализация IT

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

Остерегайтесь защитных механизмов IT

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

Недооценка объема работы с данными

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

Искушение расширяемой платформой

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

Ненадежное извлечение данных

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

Плохие числовые рецепты

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

ABC-анализ

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

Резервный запас

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

Ручные корректировки прогнозов

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

Оповещения и мониторинг некорректных прогнозов

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

Заклеивание исторических данных

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

Сроки поставки как граждане второго сорта

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

Лженаука

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

Фантастические бизнес-кейсы

Решения для цепочек поставок, безусловно, не единственная область корпоративного программного обеспечения, где поставщики делают смелые заявления, но, как говорится, если что-то кажется слишком хорошим, чтобы быть правдой, скорее всего, так оно и есть. Мы сами наблюдали, что почти каждый январь на выставке NRF в Нью-Йорке, одной из крупнейших розничных торговых выставок в мире, существующей уже более века, один из крупных поставщиков смело заявляет, что уровни запасов могут быть сокращены вдвое благодаря их новому решению. Если бы только 1/10 этих заявлений оказалось правдивыми, вся индустрия достигла бы почти идеальных уровней запасов еще десятилетие назад. Существует так много способов манипулировать цифрами бизнес-кейсов, что большинство поставщиков даже не лгут в прямом смысле. Наиболее распространенный случай заключается в том, что компания, рекламируемая как «образец» для данного решения, изначально имела крайне дисфункциональную цепочку поставок, и поэтому столь значительный прогресс был возможен, когда спустя год все вернулось в нормальное состояние.

Доверьте прогнозирование команде продаж

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

Проверенные решения

Поиск проверенного решения, способного принести ощутимые выгоды компании, очень похожей на вашу, может показаться вполне рациональным. С точки зрения анекдотов, именно так поступала Nokia, как и бесчисленные другие компании, пока те не исчезли. Большинство крупных компаний не действует так быстро, когда дело касается выбора сложного решения. Процесс выбора поставщика может легко занять до одного года. Затем достижение оптимального режима работы с выбранным решением может занять еще один год. Мониторинг результатов и завоевание доверия к ним может потребовать еще 1 или 2 года, особенно для тех цепочек поставок, где не все решения являются устойчивыми и где система может быстро вернуться к прежнему уровню эффективности, как только поставщик перестанет постоянно присутствовать на объекте для корректировки решения. После этого может пройти еще один год, прежде чем поставщик в конечном итоге представит вашей компании эти заслуженно накопленные доказательства. Фатальный недостаток такого подхода заключается в том, что ваша компания не может позволить себе прийти на вечеринку с опозданием в 5 лет. Когда речь идет о программном обеспечении, 5 лет — это очень долго. Большинство программ уже считаются устаревшими к 5-му году; почему же ваше решение для цепочки поставок должно быть исключением?

Плохие метрики, плохие показатели

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