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