00:00:08 Введение в прогнозирование спроса и агрегацию данных.
00:00:41 Различные типы гранулярности в прогнозировании спроса.
00:02:00 Проблемы различных уровней агрегации данных при прогнозировании.
00:05:28 Дизагрегированный уровень: SKU в день, и восстановление других уровней агрегации.
00:08:31 Крайние случаи и проблемы с скоропортящимися товарами в прогнозировании спроса.
00:09:42 Важность детализированной информации в агрегации данных.
00:11:01 Восстановление необходимого уровня агрегации из самых детализированных данных.
00:13:01 Ограничения методов временных рядов при работе с очень дизагрегированными данными.
00:15:01 Методы временных рядов и предположение, что будущее будет таким же, как и прошлое.
00:17:00 Соблазнительная и вводящая в заблуждение природа моделей временных рядов.
00:19:03 Обсуждение недостатков агрегации в прогнозировании.
00:20:00 Исследование важности детализации при принятии решений.
00:21:38 Анализ релевантных горизонтов и их влияние на решения в цепочке поставок.
00:23:48 Аргументы против произвольной агрегации и ее потенциального влияния на эффективность цепочки поставок.
00:26:35 Рекомендация сконцентрироваться на детализации, обусловленной решениями, и избегать преждевременной оптимизации.
Резюме
Joannes Vermorel, основатель Lokad, обсуждает важность выбора правильного уровня агрегации данных для прогнозирования спроса в интервью с Nicole Zint. Рассматриваются два измерения: временное и структурное, включая временные интервалы, используемые для агрегации данных, и организацию цепочки поставок. Vermorel отмечает, что ежедневный уровень и SKU наиболее применимы для большинства сетей цепочки поставок, но крайние случаи могут требовать более детализированных данных. Vermorel предупреждает об ограничениях моделей временных рядов в прогнозировании цепочки поставок, призывая к более широкому взгляду, который учитывает такие факторы, как скоропортящиеся товары, каннибализация, замена и переменные сроки поставок. Он акцентирует внимание на важности детализации, обусловленной решениями, и необходимости расширения горизонтов прогнозирования за рамки сроков поставок.
Расширенное резюме
В этом интервью ведущая Nicole Zint обсуждает прогнозирование спроса и правильный уровень агрегации данных с Joannes Vermorel, основателем Lokad — компании-разработчика программного обеспечения, специализирующейся на оптимизации цепочек поставок. Они исследуют различные типы детализации в прогнозировании спроса и их влияние на методы прогнозирования.
Vermorel объясняет, что существует два основных измерения, которые следует учитывать при выборе уровня детализации для прогнозирования спроса: временное и структурное. Временное измерение относится к временным интервалам, используемым для агрегации данных, таким как почасовой, ежедневный, еженедельный, ежемесячный или ежегодный. Структурное измерение связано с организацией цепочки поставок, включая продуктовые категории и географию. Это может включать агрегацию данных по SKU (Stock Keeping Unit), по артикулу, по семейству продуктов, по суперсемейству или по категории, а также агрегирование по филиалам, регионам или странам.
Говоря о типах прогнозов, связанных с этими уровнями детализации, Vermorel упоминает, что концепция бизнес-аналитики, или гиперкубов, популяризированная в 1990-х, имеет отношение к данному вопросу. Исторические данные могут быть представлены в виде векторов, причем каждый уровень детализации создает уникальный вектор. Когда добавляется временное измерение, эти векторы можно интерпретировать как данные временных рядов, которые затем можно использовать для прогнозирования.
Этот подход в первую очередь относится к прогнозам на основе временных рядов, что является основным методом в отрасли. Vermorel отмечает, что на основе одних и тех же данных может быть построено множество прогнозов из-за разнообразия возможных уровней агрегации.
В интервью также затрагивается технический термин «равномерно распределенные» в отношении временных рядов. Равномерно распределенные временные ряды имеют регулярные, одинаковые интервалы между точками данных. Vermorel признает, что большинство специалистов в области цепочек поставок, возможно, никогда не задумывались о работе с нерегулярными временными рядами, так как равномерно распределенные ряды являются более распространенными. Однако он отмечает, что некоторые интервалы, такие как месяцы, не являются строго регулярными в физическом смысле, поскольку месяцы имеют разную продолжительность.
Этот сегмент интервью сосредоточен на важности выбора подходящего уровня детализации при прогнозировании спроса. Существует два основных измерения, которые следует учитывать: временное и структурное. На основе выбранного уровня детализации из одних и тех же данных можно получить различные типы прогнозов, при этом прогнозы на основе временных рядов являются наиболее распространенными в отрасли. Кроме того, обсуждается концепция равномерно распределенных временных рядов, что подчеркивает потенциальные сложности при работе с переменными временными интервалами.
Vermorel рассказывает о горизонтах прогнозирования, детализации, обусловленной решениями, и о том, как важно не ограничивать свое мышление в области управления цепочками поставок.
Они обсуждают проблемы уровней агрегации данных в оптимизации цепочек поставок. Vermorel объясняет, что выбор уровня агрегации зависит от специфики отрасли, так как в некоторых отраслях может потребоваться более детализированный подход. Он также подчеркивает, что ежедневный уровень и уровень SKU являются наиболее осмысленными для большинства сетей цепочек поставок. Однако он отмечает, что в крайних случаях, таких как perishable, могут потребоваться более детализированные данные. Vermorel акцентирует внимание, что каждое произвольное решение об агрегации данных имеет свои плюсы и минусы, и крайне важно понимать, откуда берутся эти решения. Когда его спрашивают, можно ли восстановить более детальный уровень данных из самого детализированного уровня, Vermorel объясняет, что при агрегации данных всегда теряется часть информации. Таким образом, чем более детализированы данные, тем точнее будет прогноз. Однако самые детализированные данные — это не агрегированные данные, а исходные транзакционные данные. Он объясняет, что люди останавливаются на уровне SKU в день, потому что это последний уровень, на котором можно работать с временными рядами. Если же идти дальше, то придётся отказаться от перспективы временных рядов, так как данные не структурированы как временной ряд.
Также в интервью обсуждаются ограничения моделей временных рядов в прогнозировании цепочек поставок с ведущей Nicole Zint. Vermorel отмечает, что, хотя отрасль цепочек поставок обычно работает с ментальной моделью временных рядов, методы, основанные на временных рядах, демонстрируют плохие результаты при работе с разреженными, непредсказуемыми и прерывистыми данными. Он утверждает, что существует фундаментальная асимметрия между прошлым и будущим, и предположение, что будущее будет точно таким же, как прошлое, является ошибочным. Vermorel также критикует практику агрегации данных, которая, по его мнению, приводит к потере информации и несоответствующим метрикам, и предполагает, что единственный релевантный горизонт для принятия решений — это тот, который имеет значение для конкретного решения.
Vermorel начинает с того, что объясняет, что горизонты прогнозирования должны выходить за рамки сроков поставок, поскольку они не всегда хорошо вписываются в традиционную модель временных рядов. Он утверждает, что горизонт принятия решений должен учитывать не только период между настоящим моментом и прибытие товара, но и время, необходимое для продажи полученных товаров. Применимый горизонт зависит от таких факторов, как ожидаемая скорость реализации запасов и изменчивость спроса. Хотя нет четкого ограничения на то, насколько далеко в будущее следует смотреть, Vermorel признает, что прогнозы становятся менее точными по мере увеличения горизонта. В конечном счете, компромисс заключается в балансировке затрат на вычислительные ресурсы и потенциальных улучшениях цепочки поставок.
Обсуждая детализацию, Vermorel подчеркивает, что она должна определяться теми решениями, которые компания намерена принимать. Он советует не путать потребность в визуализации с другими требованиями к прогнозированию и оптимизации, поскольку детализация может быть произвольной и приводить к потере данных. Вместо этого он рекомендует сосредотачиваться на решениях, которые оказывают ощутимое финансовое влияние на цепочку поставок, таких как пополнение запасов или корректировка цен.
Vermorel предупреждает о том, чтобы не зацикливаться на уровнях агрегации, которые он рассматривает как сугубо технический аспект проблемы. Современные компьютерные системы обладают достаточной мощностью для обработки различных уровней детализации, и нет необходимости накладывать произвольные ограничения на мышление. Раньше агрегация данных для визуализации представляла собой проблему, но современные системы легко справляются с этим, даже с детализацией до миллисекунд.
Интервьюируемый также предостерегает от того, чтобы полагаться исключительно на традиционные подходы с использованием кубов данных для оптимизации цепочек поставок. Он утверждает, что такой подход может наложить ненужные ограничения и сузить спектр возможных решений. Для более комплексного взгляда на цепочку поставок следует учитывать такие факторы, как скоропортящиеся товары, каннибализация, замена и переменные сроки поставок. Vermorel призывает к более широкому взгляду и избеганию произвольных ограничений, которые могут затруднять решение проблем в управлении цепочками поставок.
В заключение, Joannes Vermorel выступает за учет более широкого спектра факторов при оптимизации цепочек поставок, расширение горизонтов прогнозирования за рамки сроков поставок и применение детализации, обусловленной принятием решений. Он подчеркивает важность открытого мышления и использования современных компьютерных систем для эффективного решения сложных проблем цепочек поставок.
Полная транскрипция
Nicole Zint: Когда речь идет о прогнозировании спроса, существует невероятное разнообразие методов и уровней агрегации данных, которые выбираются как между компаниями, так и внутри них. Некоторые прогнозируют на ежедневной основе, другие — на еженедельной, ежемесячной или ежегодной. Некоторые прогнозы выполняются на уровне SKU, другие — на уровне категорий. Это поднимает вопрос: какой же является правильным уровнем агрегации данных? Это тема сегодняшнего выпуска. Прежде чем мы углубимся в ответ на этот вопрос, Joannes, какие существуют типы детализации для выбора в прогнозировании спроса?
Joannes Vermorel: В прогнозировании спроса существует по сути два основных измерения проблемы. Первое — временное, которое касается того, хотите ли вы агрегировать транзакционные данные по часам, дням, неделям, месяцам или годам. Второе измерение обычно связано с топологией продукта/цепи поставок, поэтому вы можете выбрать агрегацию по SKU, по артикулу, по семейству продуктов, по суперсемейству, по категории и т.д. Кроме того, есть географические локации, по которым вы можете агрегировать данные — по филиалам, регионам или странам. Два основных измерения — это время и структура вашего каталога/сети цепочки поставок, что создает матрицу возможностей при выборе уровня детализации.
Nicole Zint: Когда мы говорим об этой детализации, о каких прогнозах идет речь? Существует ли какой-то определенный тип прогноза?
Joannes Vermorel: По сути, у вас есть модель, популяризированная в 90-х годах, по сути под названием бизнес-аналитика или гиперкубы. Это способ представить ваши исторические данные в виде векторов. Вы выбираете уровень детализации, скажем, по SKU в неделю, и для каждого отдельного SKU на недельном уровне у вас есть вектор значений, который, благодаря наличию временного измерения, можно интерпретировать как временной ряд. Затем этот временной ряд можно прогнозировать в будущее. Благодаря множеству возможных уровней агрегации может быть построено множество прогнозов на основе одних и тех же данных. Таким образом, когда мы обсуждаем эту проблему, речь идет о прогнозах на основе временных рядов, по крайней мере, это основная практика в отрасли.
Nicole Zint: А как насчет временной шкалы в временных рядах: все ли они равномерно распределены или существует другой подход?
Joannes Vermorel: «Равномерно распределенные» — это очень технический термин, с которым большинство специалистов в области цепей поставок, возможно, никогда не сталкивались. Равномерное распределение — это технический момент, когда вы говорите, что ваш временной ряд разделен на интервалы, которые абсолютно регулярны. Однако имейте в виду, что это своего рода абстракция, поскольку, например, месяцы не являются строго регулярными в физическом смысле. Физики скажут, что некоторые месяцы длиннее других, так что регулярность обусловлена лишь нашим календарем.
Nicole Zint: Еще один вопрос относительно месяцев: в месяце может быть разное количество, скажем, пятниц или выходных, и если мы видим всплески продаж по пятницам, разве это не исказит данные?
Joannes Vermorel: Здесь мы подходим к вопросу: какой уровень агрегации выбрать? Может возникнуть множество соображений. Очевидно, что некоторые уровни агрегации имеют определенные эффекты. Если рассматривать почасовой уровень, для большинства отраслей он может быть чрезмерно дизагрегированным и может быть нецелесообразным ночью, так как, например, в ритейле ночью почти ничего не происходит. Поэтому это может быть нецелесообразно.
Joannes Vermorel: Затем, действительно, если вы выберете ежемесячную агрегацию, это всегда проблематично, поскольку некоторые месяцы содержат пять раз определенный день недели, а иногда — четыре или пять. Это сложный момент, который может ввести определенные смещения в представлении этих данных и, возможно, повлиять на построение прогноза. Но то же самое относится и к другим измерениям, таким как агрегация по SKU, по продукту или по категории — все они вызывают собственные вопросы.
Nicole Zint: Итак, когда речь заходит о различных уровнях агрегации данных, нельзя ли технически просто выбрать, скажем, SKU за день, который является самым дезагрегированным уровнем, а затем реконструировать практически любой другой уровень агрегации из него?
Joannes Vermorel: Во-первых, да, существует искушение использовать сверхдезагрегированные уровни. В цепочке поставок самый разумный уровень дезагрегации по времени — это ежедневный. Однако это довольно произвольное решение. Мы могли бы решить, что данные собираются по минутам, и, например, если вы управляете колл-центром и хотите оценить частоту поступления звонков, наблюдения будут гораздо более детализированными. Таким образом, всё сводится к тому, что имеет смысл в типичной ситуации в цепочке поставок.
Теперь, если мы немного оглянемся в прошлое, нам нужно понять, откуда мы пришли. Давайте рассмотрим типичный магазин с 10 000 SKU в типичной розничной сети из 100 магазинов. То есть, речь идёт даже не о очень большой розничной сети. Речь идет о 10 000, умноженных на 100, что равно 1 миллиону SKU, а затем ежедневные данные. Если мы хотим иметь историю за три года, это будет примерно тысяча дней. Таким образом, речь идёт об одном миллиарде точек данных. Чтобы представить агрегированные по дням данные на уровне SKU в скромной розничной сети, мы уже говорим об одном миллиарде точек данных.
На компьютере это уже составило бы четыре гигабайта памяти. Если оглянуться немного в прошлое, то становится ясно, что подобная ёмкость памяти даже была недоступна до 90-х годов. Кстати, термин “business intelligence” как класс инструментов enterprise software появился в 90-х именно тогда, когда на рынке появились компьютеры с гигабайтной памятью. Таким образом, эти две вещи шли рука об руку. Вам нужны были компьютеры, способные обрабатывать такие огромные объёмы данных.
Nicole Zint: Итак, эти большие кубы на самом деле представляли собой программное обеспечение, разработанное для вычислений в оперативной памяти, что было просто отличным способом сказать “давайте воспользуемся этой новой возможностью случайного доступа к памяти”. Исходя из этого, это стало стандартом, хотя не следует забывать, что это было довольно произвольное решение. Когда говорят, что это самый мелкий уровень, который имеет смысл для цепочек поставок, действительно ли ежедневная агрегация и уровень SKU являются точными?
Joannes Vermorel: Да, но тут много крайних случаев. Например, если у вас есть скоропортящийся продукт, возникает вопрос: достаточно ли агрегации по дням и по SKU, чтобы дать точную картину уровня запасов? Если речь идёт о скоропортящемся продукте, ответ — нет. Может сложиться впечатление, что у вас 10 единиц на складе, но если 9 из этих 10 единиц истекают уже завтра, то фактически у вас в наличии одна полноценная единица плюс девять, находящихся на грани исчезновения. Таким образом, в этом случае уровень запасов недостаточно детализирован, как и уровень SKU. Вам хотелось бы иметь уровень запасов с минимальным сроком годности в одну неделю, а возможно, и с запасом на месяц. То есть, вы бы ввели ещё одно измерение, чтобы получить более полную интуицию.
Nicole Zint: А как насчёт времени? Подходит ли ежедневный уровень или следует рассмотреть более детализированный вариант?
Joannes Vermorel: Ежедневный уровень может быть достаточным, за исключением случаев, когда некоторые магазины работают, скажем, только в выходные или только утром. Если вы не знаете, что у вас есть магазин, открытый лишь полдня, вы недополучаете информацию. Возможно, более детализированный уровень, такой как утро и вечер, даст вам более ценную информацию. Каждое произвольное решение относительно уровня агрегации имеет свои плюсы и минусы. Мой посыл заключается в том, что это довольно произвольно, и никакой абсолютной истины в этом нет, но очень важно понимать, откуда берутся эти решения.
Nicole Zint: Скажем, мы нашли самый детализированный уровень, который укладывается в наши бюджетные рамки. Если у нас есть доступ к самому детализированному уровню, но мы всё же хотим посмотреть прогноз на еженедельной основе, можно ли просто реконструировать нужный нам уровень, исходя из этого детализированного уровня?
Joannes Vermorel: Абсолютно. Если мы обратимся к исходной истории транзакций, то при любой агрегации вы теряете часть информации. Независимо от того, какой вид агрегации вы проводите, всегда можно восстановить более высокий уровень, исходя из самых детализированных данных.
Nicole Zint: На самом деле, это процесс с потерями, так что вы теряете информацию. Получается, у вас будет меньше информации, и, несомненно, это означает, что точность снизится, верно? Чем выше агрегация, тем ниже точность?
Joannes Vermorel: Да, но дело в том, что именно по этой причине мы и настраивали такую агрегацию. Я бы сказал, что это обусловлено кубовой структурой, поскольку у нас есть программное обеспечение, работающее довольно быстро. Идея в том, что когда у вас есть гиперкуб, операции “разрезать и перемешать” выполняются очень эффективно. Это сугубо техническая причина. Таким образом, если вы хотите перейти от ежедневного уровня к недельному, это очень эффективная операция, которую можно осуществить на кубе.
Действительно, с точки зрения чистой теории информации, при переходе на более агрегированный уровень мы теряем информацию. Так что в теории, если мы хотим получить более точное представление о будущем, нам следует работать с самыми дезагрегированными данными. Однако люди считают, что самые детализированные данные — это данные по SKU за день, и я бы сказал: подождите, самые детализированные данные — это даже не агрегированные данные; это сырые транзакционные данные.
Причина, по которой люди останавливаются на уровне “по SKU за день”, заключается в том, что это последний уровень, на котором вы ещё работаете со временными рядами. Если вы захотите пойти дальше и работать с исходной историей транзакций, то, по сути, вам придётся отказаться от подхода временных рядов. Почему? Потому что данные не структурированы как временные ряды. Это буквально реляционные данные, то есть таблицы в вашей базе данных. Они больше не организованы как временные ряды, уж точно не как равномерно распределённые ряды.
Временные ряды появляются только тогда, когда вы, по сути, создаёте векторы, где говорите: за период (период может быть днём, неделей или месяцем) у вас есть некоторое количество, после чего вы формируете вектор этих количеств. Затем вы хотите расширить это с помощью модели временных рядов. Если вы работаете просто с таблицей, содержащей, скажем, 100 столбцов, это не временной ряд; это просто реляционная таблица в базе данных. Это довольно распространено, но это не временной ряд. Ограничением становится сам выбранный метод прогнозирования.
Вопрос в том, почему это так привлекательно? Ответ заключается в том, что большинство отраслей цепочки поставок работают с ментальной моделью временных рядов. Очевидно, если вы решили, что всё должно соответствовать модели временных рядов, то гиперкуб становится очень привлекательным, поскольку всё, что вы рассматриваете — при условии, что одно из измерений представляет время, — является временным рядом в той или иной степени агрегации.
Но вот в чём суть. Хотя в теории теория информации говорит, что чем больше мы дезагрегируем, тем больше информации у нас будет, и, следовательно, тем больше мы можем узнать о будущем, на практике методы временных рядов, большинство из них, а не все, как правило, показывают очень слабые результаты на очень разреженных, непредсказуемых, прерывистых данных. Проблема в том, что при работе с очень детализированными данными методы временных рядов становятся менее эффективными.
Nicole Zint: С точки зрения вашего метода временных рядов, а не с реальной точки зрения, где у вас больше данных, ваш вектор становится всё более разреженным, то есть содержит больше нулей. А метод временных рядов предполагает, что будущее будет похоже на прошлое. Отсюда и возникает предположение, что будущее симметрично прошлому?
Joannes Vermorel: Да, но это верно для всех методов, основанных на данных. Все такие методы в той или иной степени опираются на идею, что будущее будет таким же, как прошлое. Видите ли, не имеет большого значения, можно назвать это машинным обучением, ИИ, временными рядами — идея всегда остаётся той же. Все наши статистические методы основаны на представлении о том, что будущее будет повторять прошлое.
Nicole Zint: Но ведь, если вы будете более детализировать, вы потеряете, возможно, сезонные колебания и тому подобное, верно?
Joannes Vermorel: Нет, характеристика временных рядов носит сугубо технический характер. Дело в том, что модель временных рядов даёт вам высоко симметричную картину, в которой будущее по структуре данных выглядит точно так же, как и прошлое. Это нечто, что свойственно именно временным рядам. Когда говорят “то же самое”, да, но я делаю утверждение о будущем. Это утверждение не обязано иметь ту же форму, вид и формат, что мои исторические данные. Так что может быть, а может и не быть.
С временными рядами всё выглядит невероятно заманчиво, но я считаю, что это также сильно вводит людей в заблуждение. Это невероятно заманчиво, потому что фактически будущее и прошлое являются абсолютно симметричными. И когда я говорю об этой абсолютной симметрии, просто представьте свой гиперкуб или куб. У вас есть измерение для SKU, измерение для дней, измерение для чего-то ещё, и, по сути, будущее заключается в том, чтобы взять ваше измерение для дней и расширить его, скажем, на 100 дополнительных ячеек.
И вот, появляется будущее, и вы говорите, что прогноз заключается просто в заполнении пробелов. То есть, буквально, вы говорите, что это те же самые данные: есть данные, которые я наблюдал, а затем данные, в которых я заполняю пробелы с помощью моей модели прогнозирования временных рядов. Однако существует радикальная и фундаментальная асимметрия между прошлым и будущим.
Если вы придерживаетесь классической перспективы среднего прогноза временных рядов, вы делаете вид, что будущее точно такое же, как прошлое, по своей природе, а не только в том, что оно ещё не наступило. Это буквально означает, что по формату данных, по способу восприятия, вы утверждаете, что всё полностью одинаково. А моя позиция, которая больше является философским заявлением, чем научным, заключается в том, что нет, будущее совсем не такое, оно сильно отличается.
Nicole Zint: Я до сих пор вижу много запросов на предложения (RFP), где у поставщиков спрашивают: “Можете ли вы предоставить нам все эти уровни сразу? Различные уровни агрегации — почему?”
Joannes Vermorel: Снова, это стандартный вопрос. Люди настаивают на этом, потому что так они привыкли, но важно понимать, что различные уровни агрегации могут привести к совершенно разным результатам и выводам.
Nicole Zint: Логическая ошибка здесь в том, что вы начинаете с модели временных рядов, а эта модель имеет свой аналог в индустрии программного обеспечения для business intelligence, где всё по сути представлено в виде куба или его срезанных вариантов. Теперь люди понимают, что теряют информацию при агрегации, но почему — остаётся неясным. Метрика говорит им, что их очень детализированный прогноз — полный отстой. На самом деле, возможно, дело в том, что они используют неправильный метод, и прогноз действительно очень слабый.
Joannes Vermorel: Итак, они говорят: “Ладно, наш прогноз ужасен”. А я отвечаю: “Нам нужна возможность подняться на более высокий уровень агрегации. Это может быть, скажем, недельный прогноз или прогноз по продукту вместо прогноза по SKU”. Но они не знают, какой именно уровень выбрать. Поэтому, когда они обращаются к поставщику, они хотят оставить себе опции, и в итоге получают полусмешные RFP с более чем сотней вопросов, требующих наличия всех уровней агрегации.
Просто потому, что, с их точки зрения, они сохраняют возможность выбора уровня, на котором хотят применять модель прогнозирования временных рядов. Но здесь я действительно ставлю под сомнение сам факт: зачем вообще агрегировать данные и почему метод прогнозирования должен терять данные до того, как начнёт работать? Вы теряете данные, и это проблема, а увеличение агрегации только приводит к ещё большей их потере.
А если вы скажете: “Но подождите, мы не можем работать на супер детализированном уровне, потому что наша метрика, представляющая процент ошибки, показывает, что он очень плох”. Мы говорим: “Да, но вы оптимизируете не процент ошибки, а сумму ошибки в долларах. А вы смотрите на процентную метрику, так что это как бы не соответствует сумме в долларах”.
Nicole Zint: Да, именно. Потому что если поддаться этой логической ошибке, вы перейдёте от ежедневного к недельному прогнозу, получите лучшую точность, затем от недельного к месячному — ещё лучшую, а затем и от месячного к годичному. И тогда люди говорят: “О, подождите, годовой прогноз — что мне делать с годовым прогнозом? Если решения принимаются еженедельно, то как месячный прогноз может вам помочь?”
Joannes Vermorel: Вот в чём проблема. На самом деле, единственный релевантный горизонт — это тот, который имеет значение для вашего решения. Но давайте рассмотрим очень простое решение, например, пополнение запасов. Приведём пример того, каким может быть релевантный горизонт. Ответ весьма сложный. Во-первых, у вас будут сроки поставки, но срок поставки не гарантирован. Допустим, у вас зарубежный поставщик, поэтому сроки поставки могут варьироваться — это не константа. Таким образом, ваш срок поставки может составлять примерно 10 недель, но при этом иметь огромные колебания.
Некоторые из этих вариаций, кстати, сезонны, как китайский Новый год. Фабрики в Китае закрываются, поэтому вы получаете ещё четыре недели сроков поставки. Таким образом, если смотреть только на сроки поставки, горизонт очень изменчив и требует собственного прогноза. Кстати, одна из проблем с моделями временных рядов в том, что мы обычно рассматриваем только продажи. Всё остальное, что нужно прогнозировать, например сроки поставки, остаётся неизменным. А иногда, даже хуже — их вообще может не быть.
Nicole Zint: Таким образом, куб даже не отражает определённую логику; он выбран довольно произвольно. Ваш горизонт — это ваши сроки поставки, но сроки поставки заслуживают прогнозного “красного зонирования”, которое на самом деле не вписывается в эту модель временных рядов и кубовое программное обеспечение. Но должен ли ваш горизонт для оценки обоснованности вашего решения ограничиваться только сроками поставки?
Joannes Vermorel: Нет, потому что, очевидно, если вы решите разместить повторный заказ сейчас, вы хотите удовлетворить спрос, который возникнет между настоящим моментом и датой прибытия вашего продукта. Но затем вам придётся продать то, что вы только что получили. Чтобы оценить уместность заказа на закупку, вы должны посмотреть, что произойдёт потом. И как далеко в будущее следует заглядывать? Что ж, это зависит. Если заказ, который вы размещаете, сопровождается всплеском спроса, то вы можете получить товар и продать всё в течение двух дней. Но что, если всё наоборот, и затем спрос падает? Вы можете держать запас в течение целого года, очевидно, не если он скоропортящийся, но я просто упрощаю.
Таким образом, горизонт, который применим, зависит в значительной мере от того, как вы смотрите в будущее, и является прогнозом сам по себе, потому что это прогноз, в котором вам нужно предсказать сроки выполнения заказа. И затем горизонт, который мы должны учитывать, даже если мы смотрим только на спрос, зависит от того, как быстро вы ожидаете фактически реализовать свой запас. Таким образом, в конечном итоге нет чёткого ограничения с точки зрения применимого горизонта для вашего прогноза. Единственная проблема в том, что чем дальше мы заглядываем в будущее, тем менее точным становится прогноз.
Однако это технический момент, и в какой-то момент возникает компромисс между стоимостью вычислительных ресурсов и потенциальным предельным улучшением для вашей цепочки поставок. Но, понимаете, с концептуальной точки зрения нет ограничения на то, как далеко вы хотите заглянуть в будущее.
Nicole Zint: Итак, подытожим: уровень детализации всегда должен соответствовать уровню решений, которые вы хотите принимать?
Joannes Vermorel: Да, я бы сказал, что ваша детализация будет во многом определяться принимаемыми решениями. Но имейте в виду, что идея необходимости агрегации подразумевает определённый метод, который вы хотите использовать. Мой совет — сосредоточьтесь на самом решении, которое вы принимаете. Решения — это то, что оказывает ощутимое влияние на вашу цепочку поставок, например, повторное размещение заказа, повышение или понижение цены и другие действия, которые имеют реальное финансовое воздействие на цепочку поставок. Однако я бы сказал: берегитесь самой идеи детализации. Это довольно выдуманно, произвольно, и не путайте вашу потребность в визуализации — что, впрочем, нормально, ведь вы хотите иметь возможность визуализировать — с нужной для принятия решений детализацией.
Nicole Zint: Временные ряды — невероятно мощный инструмент для визуализации данных. Однако не путайте эту потребность в визуализации с другими требованиями к прогнозированию и оптимизации, которым не обязательно работать с какой-либо выдуманной детализацией. Когда я говорю о выдуманной детализации, я имею в виду всё, что не является простым отражением данных, как они существуют в ваших корпоративных системах. Любая агрегация, которую вы добавляете сверху, приведёт к потере данных.
Joannes Vermorel: Возможно, это окажется хорошим компромиссом в том смысле, что агрегация может сэкономить процессорное время или память, а может и нет. Это чрезвычайно техническая дискуссия, и мой совет — не заниматься преждевременной оптимизацией. Старайтесь не воспринимать уровни агрегации как неразрешимые проблемы; в контексте визуализации они в основном являются простыми задачами. С современными компьютерными системами очень легко иметь избыток возможностей по сравнению с вашими реальными потребностями.
В 90-х годах агрегация данных по дням была вызовом, но в наши дни это уже не проблема. Если какой-либо поставщик говорит вам, что у него есть ограничение — история за пять лет, это просто странно. Такого ограничения не существует. Существует множество способов справиться с любой степенью детализации, даже до миллисекунды. Однако это не обязательно что-то разумное, и вы не хотите применять это к настоящему кубу, где для каждой ячейки используется по одному байту памяти. Это очень технический аспект.
Современные системы предоставят вам любую необходимую агрегацию и даже больше. Это не является ограничением. Не стройте рассуждения по принципу, пытаясь продумать все методы, которые вы хотите использовать на основе этого куба, как будто это единственный способ взглянуть на проблему. Это не так. Многое теряется, например, скоропортимость, каннибализация, замещение и изменчивость сроков выполнения заказа. Тот факт, что вы структурируете всё в куб, накладывает огромные ограничения на то, о чём вы можете думать относительно вашей цепочки поставок, и это плохо. Мой совет — не загоняйте свой разум в клетку. Просто постарайтесь сохранять широкий взгляд, ведь существует множество произвольных ограничений, которые не способствуют решению проблем вашей цепочки поставок.
Nicole Zint: Большое спасибо, Joannes, за то, что поделились своими мыслями по этой теме. Спасибо за просмотр, и увидимся на следующей неделе.
