Взгляд производителя
Несколько дней назад потенциальный клиент задал несколько острых вопросов относительно применимости перспективы Количественной Цепи Поставок для решения вызовов цепи поставок, с которыми сталкиваются многие крупные производственные компании.
Рассмотрим случай, когда из относительно небольшого количества типов рабочих ячеек/машин выходит много товаров, которые могут быть изготовлены в следующем недельном цикле, при условии наличия персонала и сырья. Каким должен быть спрос и возможности поставки компании, чтобы вероятностное прогнозирование было значительно превосходным по сравнению с хорошей, стандартной системой планирования ресурсов, такой как JDA или SAP APO? Не будет ли достаточно агрегированных прогнозов, которые менее изменчивы и, следовательно, лучше подходят для традиционного прогнозирования и системы планирования ресурсов?
Вероятностное прогнозирование касается не только спроса, но и включает в себя все аспекты, которые остаются неизбежно неопределенными: спрос, а также сроки поставки, возвраты, изменения цен и т. д. Чем больше неопределенности, тем больше конкурентного преимущества имеет любой численный подход, который решает проблему неопределенности заранее, а не игнорирует ее. Агрегирование «классических» прогнозов - это численный эквивалент подметания грязи под ковер. Ежемесячный прогноз может быть более точным - измеренным в процентах - по сравнению с ежедневным; однако, дополнительная точность оплачивается дополнительной задержкой на рынке, так как статистический индикатор по своей сути охватывает весь месяц.
Игнорирование структурных рисков, таких как потеря крупного клиента и всего его текущего потока заказов, является рецептом для создания постоянного потока мертвого инвентаря со временем, так как все клиенты в конечном итоге уйдут - даже если это будет для их возвращения через год. На более прозаическом уровне игнорирование изменчивости сроков поставки приводит к неэффективному распределению запасов, потому что именно запасы предназначены для покрытия изменчивости сроков поставки. Без вероятностного прогноза неопределенность даже не оценивается должным образом. Как правило, изменчивость сроков поставки никогда не имеет нормальное распределение.
Однако, вероятностные прогнозы - это только численные артефакты. В конечном счете, важны только решения, их эффективность измеряется в евро, а не в промежуточных численных артефактах, используемых для их создания - таких как классические или вероятностные прогнозы. Основная слабость системы планирования ресурсов заключается в том, что они просто не оптимизируют цепь поставок с финансовой точки зрения. Улучшение MAPE прогнозирования - это пустая трата; важна только окупаемость инвестиций. Вероятностные прогнозы побеждают не потому, что они более точны, а потому, что они намного удобнее превращаются в решения, оптимизированные с учетом произвольных критериев окупаемости.
Таким образом, если финансовые ставки в цепи поставок имеют значение, APS никогда не является “достаточно хорошим” в моей книге, потому что APS даже не пытается оптимизировать решения в цепи поставок с финансовой точки зрения. На практике команды цепи поставок вынуждены нести всю ответственность за финансовую производительность через свои таблицы Excel; APS не заслуживает похвалы за это.
Количественная цепь поставок и DDMRP конкурируют как соответствующие числовые рецепты для операционного горизонта. Однако, не сталкивается ли Количественная цепь поставок с аналогичными проблемами в отношении ограничений поставок? Или вы явно моделируете их? Как вы обеспечиваете тактический горизонт, чтобы достаточно заранее выявить проблемы с производственной мощностью и дать руководству возможность их исправить, например, путем запроса мощности?
В отличие от DDMRP, Количественная цепь поставок (QSC) поставляется с “упакованными” числовыми рецептами. QSC - это просто принципиальный подход к созданию полезных рецептов, предназначенных для прямого использования в производстве и их постепенного совершенствования. Сбор и развитие числовых инструментов, достаточно гибких для работы с разнообразными ограничениями цепи поставок (например, MOQs, BOMs, денежные потоки, штрафы за нарушение сроков обслуживания и т. д.), является основной задачей QSC.
В Lokad мы активно разрабатываемся от одного поколения технологий к другому уже более десяти лет. Мы представили две алгебры для решения этого класса проблем, а также несколько нелинейных решателей, последняя итерация на сегодняшний день - дифференцируемое программирование. Весь смысл этих инструментов заключается в том, чтобы позволить специалисту по цепям поставок - как уже отмечалось - явно моделировать все эти ограничения. Поскольку сами ограничения разнообразны, требуется некоторая программная выразительность, чтобы хотя бы иметь возможность адекватно моделировать эти ограничения.
Затем финансовая перспектива - один из основных принципов QSC - предлагает замечательные идеи, когда речь идет о ограничениях цепи поставок. В частности, становится возможным оценить стоимость преимуществ, связанных с устранением любого заданного ограничения. Действительно, вызов заключается не столько в том, чтобы поднять проблему с производственной мощностью, сколько в том, чтобы оправдать прибыльность любых инвестиций, которые могут быть сделаны в этой конкретной области.
На практике всегда (почти) существует несколько вариантов, конкурирующих в решении одной и той же проблемы: возможно, можно заранее накопить запасы вместо увеличения производственной мощности, возможно, можно увеличить партии производства для увеличения пропускной способности, возможно, цены должны быть повышены при достижении пиковой производственной мощности и т. д. Подход QSC позволяет приоритизировать все эти варианты на основе ROI; список приоритетов постоянно обновляется вместе с входными данными.
На практике единственным ограничением для прогнозирования будущего является статистическая неопределенность, сопутствующая этому. Большинство “ориентированных на данные” инвестиций - дополнительные запасы, дополнительная мощность - отрицательно влияют на рыночные сдвиги, что делает их неактуальными. Эта проблема затрагивает все количественные методы - как QSC, так и DDMRP - единственное известное мне смягчение - это явное вероятностное прогнозирование.
Некоторые демонстрации от SAP на IBP показывают много интересного в возможности прогнозирования и визуализации влияния задержки поставки, а также возможности работы с тактическим горизонтом. Вы видите, что Lokad играет здесь, тем самым устраняя необходимость в таких инструментах? Или вы видите APO/IBP как относительно простой промежуточный слой с использованием этих преимуществ, а Lokad как систему дифференциации/инновации, которая проводит решения для выполнения (закупка, производство, трансферные ордера) и передает их через APO/IBP?
Lokad представляет собой аналитический слой, который находится поверх транзакционного слоя, обычно ERP или WMS. Цель состоит в том, чтобы генерировать окончательные решения, которые уже соответствуют всем применимым ограничениям, исключая необходимость дальнейшей “умной” обработки данных. В этом отношении Lokad занимает ту же функциональную нишу, что и SAP APO и SAP IBP.
Что касается пользовательского опыта, я считаю, что веб-панели управления Lokad также являются плавными и отзывчивыми. Однако в настоящее время создание красивых панелей управления и возможностей “что если” относительно просто для разработчиков программного обеспечения. Визуализация влияния задержки поставки хороша, но я склонен считать, что это не очень капиталистический способ использования времени сотрудников цепочки поставок. Программное обеспечение для цепочки поставок слишком часто поглощает чрезмерное количество рабочей силы, просто чтобы продолжать функционировать.
Мы идем в противоположном направлении: каждый час, потраченный на Lokad, должен быть инвестирован в улучшение решения, выполнение которого полностью автоматизировано. Таким образом, вернувшись к примеру задержки поставки, я бы заметил, что задержка поставки - это всего лишь симптом предыдущих неправильных решений: возможно, недостаточно пополнение запасов немного поздно, возможно, выбор ненадежного поставщика или ненадежного перевозчика, возможно, неправильная приоритизация отгрузок между клиентами, конкурирующими за одни и те же запасы и т.д.
Фокусировка на числовом рецепте, который генерирует все мирские решения цепочки поставок, не очень привлекательна с визуальной точки зрения - конечно, не так сильно, как возможности “что если”. Lokad также может предоставлять возможности “что если”, однако, если нет ясного пути превратить эти усилия в поток лучших решений, автоматически генерируемых решением, я не советую своим командам идти по такому пути.
При рассмотрении конфигураций цепочки поставок (открытые/закрытые производственные единицы и склады; каким клиентам выделять какой ЦОД и т.д.), ценность инвестиций в гибкость и сокращение сроков поставки от поставщика или собственной производственной ячейки, т.е. дизайн цепочки поставок Llamasoft - обычно основанный на сценариях, которые невозможно построить на основе истории: можно ли использовать Lokad для таких вопросов?
В конце 90-х годов многие эксперты предвидели, что будущее фотографии - цифровое, и аргентическая фотография обречена, но спустя 20 лет мы все еще находимся на десятилетиях от наличия технологии машинного обучения, способной производить такие высокоуровневые идеи, просто “пережевывая” базы патентов.
Квантитативная цепочка поставок - и Lokad - в своей сути является статистической. Когда речь идет о оптимизации решений в цепочке поставок, которые являются полными статистическими выбросами как по своей величине, так и по частоте, например, принятие решения о открытии нового завода, статистическая перспектива в лучшем случае слаба и часто вводит в заблуждение.
Учитывая время выполнения заказов, Lokad гораздо более подходит для принятия решения о том, следует ли использовать авиаперевозку для каждой отдельной отправки, а не для принятия решения о том, следует ли переместить стратегических поставщиков из Азии в Северную Америку.
Как правило, если решение в цепочке поставок может быть пересмотрено ежедневно, то это хороший кандидат для Lokad. Исторические данные не обязательно должны соответствовать сценариям, которые предполагаются. Исследование альтернативных взаимосвязей между клиентами и ЦОД - именно такие проблемы предназначены для решения Envision.
