POCs не работают в количественной оптимизации цепей поставок
Доказательства концепции являются одним из наиболее частых запросов от наших потенциальных клиентов, желающих опробовать нашу оптимизацию цепей поставок услугу. Однако мы часто отказываем в подобных заявках: во-первых, потому что они наносят вред самой компании клиента, а во-вторых, потому что наносят ущерб и компании Lokad в процессе. Поскольку POCs – или доказательства концепции – так распространены в B2B-софте, обычно трудно понять, почему они могут быть откровенно вредными в случае количественной оптимизации цепей поставок (1). В этой статье мы собрали наши наблюдения по поводу POCs, рассматривая их как «антипаттерн» в управлении цепями поставок.
POCs не обходятся дешевле
Одна из основных предпосылок методологии POC заключается в том, что POCs обходятся дешевле, чем настоящий проект. К сожалению, это предположение почти всегда неверно.
Во-первых, установление узкого охвата внутри всей сети цепей поставок лишь слегка влияет на результат. Раньше поставщики программного обеспечения сталкивались с проблемами масштабируемости, и полномасштабное развертывание обычно требовало значительных первоначальных вложений в аппаратное обеспечение, возможно, включавших и лицензионные сборы за программное обеспечение, такое как базы данных. Без этих инвестиций даже не удавалось начать обработку данных. Однако в эпоху облачных вычислений, это ограничение больше не действует, и если приложение разработано правильно, для начала обработки данных ничего дополнительного не требуется. Счет за облачные вычисления будет расти лишь незначительно с каждым новым клиентом, но в целом эта стоимость ничтожно мала по сравнению, скажем, с расходами на установление контакта с потенциальным клиентом. Во-вторых, основная часть начальных усилий заключается в квалификации данных, за которой следует правильное установление коммерческих B2B-отношений с клиентом.
Еще хуже, наличие большего объема данных обычно облегчает задачу, а не усложняет её, когда речь идет о статистическом прогнозировании. Таким образом, ограничивая объём данных, POCs, как правило, усложняют задачу и, следовательно, увеличивают затраты по сравнению с решением полного набора задач. Наш опыт показывает, что даже когда POCs охватывают лишь 5% всей сети цепей поставок, эти 5% обычно содержат почти всю сложность всей сети в целом. На самом деле, именно потому что POCs включают почти всю сложность полномасштабного проекта, от них изначально и ожидается оправданность.
Отбрасывание сложности — действительно не вариант. Если ваша сеть поставок включает перевозку контейнерами и работу с ненадежными поставщиками, как может POC оказаться убедительным, если эти элементы не учитываются в инициативе? Если игнорировать любое конкретное ограничение, такое как минимальные объемы заказа (MOQ), числовые результаты окажутся непригодными для использования.
Затраты, превышающие стоимость POC, определяются усилиями, которые должны быть приложены с обеих сторон — как компанией Lokad, так и её клиентом — для управления полной сложностью цепей поставок. Эти затраты зависят от особенностей конкретного бизнеса, а масштаб оказывает лишь незначительное влияние на них.
POCs повышают риск неудачи
Выбирая POC, компании часто в итоге начинают пробовать что-либо, чтобы улучшить свою цепь поставок. Однако в этом конкретном случае я хотел бы процитировать Йоду: Делай. Или не делай. Нет попытки. Несмотря на утверждения поставщиков программного обеспечения, оптимизация цепей поставок — сложное дело. Проблема POCs в том, что они предоставляют слишком много свободы для неудач.
- Извлечение истории продаж чертовски сложно. Увы, альтернативы нет: оптимизировать цепь поставок без данных о спросе не получится.
- Электронные запасы неточны. Технологии могут помочь автоматически обнаружить наиболее очевидные отклонения и помочь приоритизировать пересчеты. Однако не редкость, что менеджерам по цепям поставок приходится сталкиваться также с фантомными запасами.
- Прогнозы остаются плохими, что бы ни случилось. Бизнесу следует научиться принимать неопределенное будущее, а не желать, чтобы эта неопределенность исчезала. Вероятностные прогнозы особенно хорошо отражают будущую неопределенность.
Сложности — это множество отговорок для провала.
Существуют ситуации, когда решения ожидаются быть простыми и незамысловатыми: например, создание нового email-аккаунта для нового сотрудника. Однако оптимизация цепей поставок почти всегда является сложной задачей: если компания существует уже более нескольких лет, «простой» этап оптимизации цепей поставок был выполнен много лет назад. Остается только «сложная» часть.
По нашему опыту, большинство POCs терпят неудачу на начальных этапах проекта, когда команды еще борются с проблемами данных. Однако это ничего не говорит о самом решении по оптимизации запасов, поскольку решение так и не проходит испытание.
POCs сбивают с толку инициативы по оптимизации цепей поставок
POCs акцентируют точку зрения, которая не является именно производственной. Руководители ищут показатели, где можно установить контрольные значения или KPI. Однако что, если конкретный KPI окажется вычислять сложнее, чем сама оптимизация? Что если сам KPI, хоть и поучителен, не предлагает никаких практических путей для улучшения ситуации?
Наш опыт показывает, что POCs регулярно отвлекаются на аспекты, которые с точки зрения производства просто не являются обязательными. Попытки учесть эти аспекты обычно приводят к ухудшению POC, поскольку внезапно он становится куда более сложной задачей, чем производство само по себе.
Кроме того, поскольку основная цель POC — получить уверенность в решении, большинство POCs страдает от антипаттерна «приукрашивания», когда клиентская компания давит на поставщика, требуя учитывать каждый нюанс их бизнеса, пусть даже за счет общей надежности решения. В результате получившееся решение часто оказывается слишком хрупким, чтобы быть полезным с точки зрения производства.
Мы также наблюдали, как многие POCs терпели неудачу из-за «воображаемых» проблем. Например, если лучшая модель прогнозирования, эмпирически проверенная на тысячах SKU, оказывается несезонной и превосходит все остальные доступные сезонные модели, следует ли считать это проблемой? Нет никаких сомнений в том, что рассматриваемый бизнес является сезонным: так оно и есть. Но что, если лучшим известным способом прогнозирования спроса является простое игнорирование сезонности в данном случае? Следует ли это считать проблемой? По нашему опыту, эта единичная «проблема» становилась препятствием для многих POCs, тогда как специалисты по цепям поставок сами признавали, что предлагаемые окончательные объемы заказов были обоснованными.
Прямо переходите к производству и корректируйте проект по мере необходимости
POCs обычно, и по праву, воспринимаются как отвлекающие факторы специалистами, которым необходимо поддерживать работу бизнеса в ожидании решения следующего поколения. Наш опыт показывает, что переход непосредственно к производству дешевле и менее рискован. Однако это следует делать с использованием правильной методологии.
Во-первых, провал из-за «логистики данных» — не вариант. Вы не сможете оптимизировать то, что не измеряете. Если данные бессмысленны, то все попытки оптимизации тоже окажутся бессмысленными. Успех обязателен, иначе компания может исчезнуть через несколько лет. Оказывается, что подавляющее большинство усилий связано с этой логистикой данных, и эти инвестиции почти полностью отделены от решения, рассматриваемого для производства. И это хорошо! Если по какой-либо причине решение по оптимизации окажется недостаточным, инвестиции не будут потеряны — их можно просто перенаправить на лучшее альтернативное решение.
Во-вторых, хотя цель — перейти сразу к производству, это не означает, что цифры остаются без проверки, напротив. Старый и новый процессы должны сосуществовать, используя как можно больше «легких плодов» из старого процесса (2), пока новый процесс доводится до совершенства.
Затем обычно возникает множество проблем. Важно разобраться с ними:
- проблемы, которые уже влияли на старый процесс, пусть и более скрытно. Хорошие процессы и хорошие технологии делают проблемы заметными; это не дефект, а достоинство.
- проблемы, которые нельзя решить с помощью внедряемого программного обеспечения. Если выбор SKU ненадежен на складе, не рассчитывайте на то, что модуль прогнозирования спроса сделает его надежным.
- несоответствие между реальными проблемами и ожиданиями. Статистическое прогнозирование глубоко контринтуитивно; не позволяйте вашим ожиданиям затмевать то, что говорят количественные измерения.
- проблемы с дизайном, которые невозможно решить без значительной переработки решения, что обычно происходит, когда программное обеспечение не имеет правильного подхода к решению задачи.
Последний пункт требует рассмотрения другого решения. Однако, как упоминалось выше, это не должно означать конец инициативы, а лишь начало сотрудничества с другим поставщиком.
Отказ от идеи POC обычно означает потерю всего импульса, вложенного в инициативу. Более того, большинство POCs терпят неудачу по неправильным причинам, что означает, что шансы на успех будущих попыток почти не улучшатся, так как реальные вызовы остаются в основном без внимания.
Переход непосредственно к производству на самом деле менее рискован, чем кажется. Это помогает предотвратить целый класс неудач, которые обычно игнорируются в случае с POCs, хотя так быть не должно. Это заставляет инициативу сконцентрироваться на том, что действительно необходимо для достижения улучшений, и отбросить мечтательность. При столкновении с серьезной неудачей поставщика компания все же может использовать свой внутренний импульс и перейти к другому поставщику, не теряя при этом накопленного импульса, как это обычно происходит с POCs.
(1) Существует множество способов оптимизации цепей поставок: лучшие процессы, лучшие поставщики, лучшие перевозчики, лучший найм … Эта статья сосредоточена на количественной оптимизации: проблемах цепей поставок, которые можно решить с помощью статистических прогнозов и/или числовых алгоритмов.
(2) Устранение фантомных запасов выгодно для всех процессов оптимизации запасов. То же самое относится к пересмотру и улучшению оценки запасов.
