00:00 Введение
02:31 Причины неудачи на практике
07:20 Результат: числовой рецепт 1/2
09:31 Результат: числовой рецепт 2/2
13:01 До сих пор
14:57 Достижение целей сегодня
15:59 Хронология инициативы
21:48 Область применения: прикладной ландшафт 1/2
24:24 Область применения: прикладной ландшафт 2/2
27:12 Область применения: системные эффекты 1/2
29:21 Область применения: системные эффекты 2/2
32:12 Роли: 1/2
37:31 Роли: 2/2
41:50 Пайплайн данных - Как
44:13 Несколько слов о транзакционных системах
49:13 Несколько слов о хранилище данных
52:59 Несколько слов об аналитических системах
57:56 Здоровье данных: низкий уровень
01:02:23 Здоровье данных: высокий уровень
01:06:24 Инспекторы данных
01:08:53 Заключение
01:10:32 Предстоящая лекция и вопросы аудитории
Описание
Проведение успешной предиктивной оптимизации цепи поставок - это смесь мягких и технических проблем. К сожалению, невозможно разделить эти аспекты. Мягкие и технические аспекты тесно переплетены. Обычно это сталкивается с разделением работы, определенным органиграммой компании. Мы наблюдаем, что при неудаче инициативы в цепи поставок, причинами неудачи обычно являются ошибки, допущенные на ранних этапах проекта. Более того, ранние ошибки имеют тенденцию формировать всю инициативу, делая их практически невозможными для исправления. Мы представляем наши ключевые результаты, чтобы избежать этих ошибок.
Полный текст
Добро пожаловать на эту серию лекций о цепи поставок. Я - Жоанн Верморель, и сегодня я представлю “Начало работы с количественной оптимизацией цепи поставок.” Большинство инициатив по анализу данных в цепи поставок терпят неудачу. С 1990 года большинство компаний, занимающихся крупными цепями поставок, запускают крупные инициативы предиктивной оптимизации каждые три-пять лет с малыми или без каких-либо результатов. В настоящее время большинство команд в цепях поставок или науке о данных, начиная очередной раунд предиктивной оптимизации - обычно в рамках проекта прогнозирования или проекта оптимизации запасов - даже не осознают, что их компания уже была там, сделала это и, возможно, уже провалилась полдюжины раз.
Иногда повторные попытки мотивируются уверенностью в том, что на этот раз все будет по-другому, но часто команды даже не знают о множестве неудачных попыток, которые произошли ранее. Анекдотическим подтверждением этого состояния дел является то, что Microsoft Excel остается основным инструментом для принятия решений в области управления цепями поставок, хотя эти инициативы должны были заменить таблицы на более эффективные инструменты. Однако на сегодняшний день очень мало цепей поставок, которые могут функционировать без таблиц.
Цель этой лекции - понять, как дать шанс успеху инициативе в области управления цепями поставок, которая стремится предоставить любой вид предсказательной оптимизации. Мы рассмотрим ряд критических компонентов - эти компоненты просты, но часто они являются контринтуитивными для большинства организаций. В то же время мы рассмотрим ряд анти-паттернов, которые практически гарантируют неудачу такой инициативы.
Сегодня я сосредоточусь на тактическом выполнении начала инициативы в области управления цепями поставок с установкой “сделать дело”. Я не буду обсуждать великие стратегические последствия для компании. Стратегия очень важна, но я обсужу этот вопрос в следующей лекции.
Большинство инициатив в области управления цепями поставок терпят неудачу, и проблема практически никогда не упоминается публично. Академия публикует десятки тысяч статей ежегодно, хвастаясь всевозможными инновациями в области управления цепями поставок, включая фреймворки, алгоритмы и модели. Часто в статьях даже утверждается, что инновация была внедрена где-то в производство. И все же, мое собственное поверхностное наблюдение за миром управления цепями поставок говорит о том, что эти инновации нигде не встречаются. Аналогично, поставщики программного обеспечения обещают превосходные замены для таблиц уже последние три десятилетия, и снова, мое поверхностное наблюдение показывает, что таблицы остаются повсеместными.
Мы возвращаемся к вопросу, который уже затрагивался во второй главе этой серии лекций по управлению цепями поставок. Просто говоря, люди не имеют никаких стимулов рекламировать неудачи, и поэтому они этого не делают. Более того, поскольку компании, занимающиеся управлением цепями поставок, обычно являются крупными, проблема обычно усугубляется естественной потерей институциональной памяти, поскольку сотрудники постоянно перемещаются с одной должности на другую. Вот почему ни академия, ни поставщики не признают эту довольно мрачную ситуацию.
Я предлагаю начать с краткого обзора наиболее частых корневых причин неудачи с точки зрения тактического выполнения. Действительно, эти корневые причины обычно находятся на самом раннем этапе инициативы.
Первая причина неудачи - попытка решить неправильные проблемы - проблемы, которых нет, незначительные или отражающие некое недопонимание самой цепи поставок. Оптимизация процентов точности прогнозирования, вероятно, является архетипом такой неправильной проблемы. Снижение процента ошибки прогнозирования не приводит к прямому увеличению прибыли для компании. Та же ситуация возникает, когда компания преследует определенные уровни обслуживания для своих запасов. Очень редко удается продемонстрировать прибыль в евро или долларах.
Вторая основная причина неудачи - использование несовместимых технологий и дизайна программного обеспечения. Например, поставщики ERP неизменно пытаются использовать транзакционные базы данных для поддержки инициатив по обработке данных, потому что именно на них построена ERP. С другой стороны, команды по науке о данных неизменно пытаются использовать передовой набор инструментов машинного обучения с открытым исходным кодом, потому что это круто. К сожалению, несовместимые технологии обычно вызывают огромное трение и множество случайной сложности.
Третья основная причина неудачи - неправильное распределение труда и организация. В попытке назначить специалистов на каждом этапе процесса компании часто разбивают инициативу на слишком много людей. Например, подготовка данных очень часто выполняется людьми, не отвечающими за прогнозирование. В результате, ситуации “мусор везде” встречаются повсюду. Размывание ответственности за окончательные решения в цепи поставок является рецептом неудачи.
Одна из причин, которую я не указал в этом кратком списке, - это плохие данные. Данные очень часто винят в неудачах инициатив в сфере поставок, что очень удобно, так как данные не могут точно ответить на эти обвинения. Однако данные обычно не виноваты, по крайней мере, не в том смысле, что они борются с плохими данными. Цепь поставок крупных компаний стала цифровой десятилетия назад. Каждый приобретаемый, транспортируемый, преобразуемый, производимый или продаваемый товар имеет электронные записи. Эти записи могут быть не идеальными, но обычно они очень точные. Если люди не справляются с данными, то виноваты не сами транзакции.
Чтобы квантитативная инициатива имела успех, нам нужно вести правильную борьбу. Что мы пытаемся достичь в первую очередь? Одним из ключевых результатов квантитативной цепи поставок является основной числовой рецепт, который вычисляет окончательные решения в цепи поставок. Этот аспект уже обсуждался в Лекции 1.3 в первой главе “Продуктово-ориентированная доставка для цепи поставок”. Давайте вспомним два самых важных свойства этого результата.
Во-первых, результат должен быть решением. Например, принятие решения о том, сколько единиц следует переоформить сегодня для определенного SKU - это решение. Напротив, прогнозирование количества единиц, которые будут запрошены сегодня для определенного SKU, является числовым артефактом. Чтобы получить решение, которое является конечным результатом, требуется множество промежуточных результатов, то есть множество числовых артефактов. Однако мы не должны путать средства с целью.
Второе свойство этого результата заключается в том, что результат, являющийся решением, должен быть полностью автоматизирован в результате чисто автоматизированного программного процесса. Сам числовой рецепт, основной числовой рецепт, не должен включать в себя никаких ручных операций. Естественно, проектирование самого числового рецепта, вероятно, будет сильно зависеть от научного эксперта. Однако выполнение не должно зависеть от прямого вмешательства человека.
Наличие числового рецепта в качестве результата является необходимым условием для превращения инициативы в сфере поставок в капиталистическое предприятие. Числовой рецепт становится производственным активом, который приносит доходы. Рецепт должен быть поддерживаемым, но для этого требуется на один или два порядка меньше людей по сравнению с подходами, в которых люди участвуют на микроуровне принятия решений.
Однако многие инициативы в сфере поставок терпят неудачу, потому что они неправильно формулируют решения в сфере поставок как результат инициативы. Вместо этого эти инициативы сосредотачиваются на предоставлении числовых артефактов. Числовые артефакты предназначены для использования в качестве ингредиентов для достижения конечного решения проблемы, обычно поддерживая сами решения. Самые распространенные артефакты, с которыми сталкиваются в сфере поставок, - это прогнозы, резервные запасы, EOQ, KPI. Хотя эти числа могут быть интересными, они не являются реальными. Эти числа не имеют непосредственного осязаемого физического аналога в сфере поставок и отражают произвольные модельные представления о поставках.
Сосредоточение на числовых артефактах приводит к неудаче инициативы, потому что этим числам не хватает одного важного компонента: прямой обратной связи с реальным миром. Когда решение неправильное, плохие последствия можно проследить до решения. Однако ситуация намного более неоднозначна в отношении числовых артефактов. Действительно, ответственность размывается повсюду, так как существует множество артефактов, которые вносят свой вклад в каждое отдельное решение. Проблема становится еще хуже, когда вмешивается человек.
Этот недостаток обратной связи оказывается смертельным для числовых артефактов. Современные цепи поставок сложны. Выберите любую произвольную формулу для вычисления резервного запаса, экономического объема заказа или KPI; есть огромные шансы, что эта формула неправильна во всех отношениях. Проблема правильности формулы не является математической проблемой; это бизнес-проблема. Речь идет о том, “Действительно ли эти расчеты отражают стратегические намерения, которые я имею для своего бизнеса?” Ответ разнится от одной компании к другой и даже меняется от года к году, поскольку компании развиваются со временем.
Поскольку числовым артефактам не хватает прямой обратной связи с реальным миром, они лишены механизма, позволяющего итерировать от наивной, упрощенной и, скорее всего, грубо неправильной начальной реализации к приближенно правильной версии формулы, которая может быть признана производственного уровня. Тем не менее, числовые артефакты очень соблазнительны, потому что они создают иллюзию приближения к решению. Они создают иллюзию рациональности, научности, даже предприимчивости. У нас есть числа, формулы, алгоритмы, модели. Даже возможно проводить сравнительные испытания и сравнивать эти числа с такими же вымышленными числами. Улучшение по сравнению с вымышленным эталоном также создает иллюзию прогресса и очень утешительно. Но в конечном счете это остается иллюзией, вопросом модельной перспективы.
Компании не получают прибыль, платя людям за просмотр KPI или проведение сравнительных испытаний. Они получают прибыль, принимая одно решение за другим и, надеюсь, становясь лучше в принятии следующего решения каждый раз.
Эта лекция является частью серии лекций по цепям поставок. Я пытаюсь сделать эти лекции отчасти независимыми, но мы достигли точки, где имеет больше смысла смотреть эти лекции последовательно. Эта лекция - первая лекция седьмой главы, которая посвящена выполнению инициатив в сфере цепей поставок. Под инициативами в сфере цепей поставок я имею в виду количественные инициативы в сфере цепей поставок - инициативы, которые стремятся достичь предсказуемой оптимизации для компании.
Первая глава была посвящена моим взглядам на цепи поставок как на область исследования и практику. Во второй главе я представил ряд методологий, необходимых для цепей поставок, так как наивные методологии не справляются с адверсарной природой многих ситуаций в цепях поставок. В третьей главе я представил ряд персонажей цепей поставок с чисто фокусом на проблемах; другими словами, на том, что мы пытаемся решить.
В четвертой главе я представил ряд областей, которые, хотя и не являются прямо цепями поставок, я считаю важными для современной практики цепей поставок. В пятой и шестой главах я представил умные составляющие числового рецепта, предназначенного для принятия решений в цепях поставок, а именно предсказательную оптимизацию (общую перспективу прогнозирования) и принятие решений (в основном математическую оптимизацию, применяемую к проблемам цепей поставок). В этой седьмой главе мы обсудим, как объединить эти элементы в реальную инициативу в сфере цепей поставок, которая стремится привнести эти методы и технологии в производство.
Сегодня мы рассмотрим, что считается правильной практикой для проведения инициативы в сфере цепей поставок. Это включает формирование инициативы с правильным результатом, о котором мы только что говорили, а также с правильным графиком, правильным объемом и правильными ролями. Эти элементы представляют собой первую часть сегодняшней лекции.
Вторая часть лекции будет посвящена конвейеру данных, критическому компоненту для успеха такой инициативы, основанной на данных или зависящей от данных. Хотя конвейер данных является достаточно технической темой, он требует правильного разделения труда и организации между ИТ и цепями поставок. В частности, мы увидим, что контроль качества должен быть в основном в руках цепей поставок, с разработкой отчетов о состоянии данных и инспекторов данных.
Внедрение - это первая фаза инициативы, где создается основной числовой рецепт, который генерирует решение вместе с только поддерживающими элементами. Внедрение заканчивается постепенным внедрением в производство, и во время этого внедрения более ранние процессы постепенно автоматизируются самим числовым рецептом.
При определении соответствующего графика для первой количественной инициативы в сфере цепей поставок в компании можно подумать, что это зависит от размера компании, сложности, типа принимаемых решений в цепях поставок и общего контекста. Хотя это верно в ограниченной степени, опыт, накопленный Lokad за десятилетие и десятки таких инициатив, показывает, что почти всегда подходящим сроком является шесть месяцев. Удивительно, что эти шесть месяцев мало связаны с технологией или даже особенностями цепей поставок; они имеют гораздо больше отношения к людям и организациям самих и времени, необходимому им, чтобы привыкнуть к тому, что обычно воспринимается как очень отличный способ ведения цепей поставок.
Первые два месяца посвящены настройке конвейера данных. Мы вернемся к этому вопросу через несколько минут, но это задержка в два месяца вызвана двумя факторами. Во-первых, нам нужно сделать конвейер данных надежным и устранить редкие проблемы, которые могут проявиться через несколько недель. Второй фактор заключается в том, что нам нужно разобраться в семантике данных, то есть понять, что данные означают с точки зрения цепей поставок.
Месяцы три и четыре посвящены быстрой итерации числового рецепта самого по себе, который будет определять решения в сфере цепей поставок. Эти итерации необходимы, потому что генерация фактических решений в конечном итоге обычно является единственным способом оценить, есть ли что-то неправильное или нет в основном рецепте или во всех предположениях, заложенных в рецепте. Эти два месяца также обычно являются временем, необходимым для того, чтобы специалисты по цепям поставок привыкли к очень количественной, финансовой перспективе, которая определяет эти решения, основанные на программном обеспечении.
Наконец, последние два месяца посвящены стабилизации числового рецепта после того, что обычно является относительно интенсивным периодом быстрой итерации. Этот период также предоставляет возможность для запуска рецепта в условиях, близких к производственным, но еще не являющимся основными. Эта фаза важна для команд по цепям поставок, чтобы получить доверие к этому новому решению.
Хотя было бы желательно сжать этот график еще больше, на самом деле это обычно очень сложно. Настройка конвейера данных может быть ускорена в некоторой степени, если соответствующая ИТ-инфраструктура уже на месте, но знакомство с данными требует времени, чтобы понять, что данные означают с точки зрения цепей поставок. Во второй фазе, если итерация числового рецепта сходится очень быстро, то команды по цепям поставок, скорее всего, начнут исследовать тонкости числового рецепта, что также приведет к задержке. Наконец, последние два месяца обычно требуются для того, чтобы увидеть развертывание сезонности и получить доверие к программному обеспечению, которое принимает важные решения в сфере цепей поставок в производстве.
В целом, на это уходит около шести месяцев, и хотя было бы желательно сжать этот срок еще больше, это вызывает определенные трудности. Однако шесть месяцев уже является значительным временным промежутком. Если с самого начала, на этапе внедрения, когда числовой рецепт еще не определяет решения в сфере цепей поставок, ожидается, что этот период займет более шести месяцев, то инициатива уже находится под угрозой. Если дополнительная задержка связана с извлечением данных и настройкой конвейера данных, то это проблема ИТ. Если дополнительная задержка связана с разработкой или настройкой решения, возможно, предоставленного сторонним поставщиком, то проблема заключается в самой технологии. Наконец, если после двух месяцев стабилизации работы, похожей на производственную, развертывание в производство не происходит, то обычно возникают проблемы с управлением инициативой.
При попытке внедрить новшество, новый процесс или новую технологию в организацию, общая мудрость подсказывает начать с малого, убедиться, что это работает, и постепенно расширяться, опираясь на ранний успех. К сожалению, цепи поставок не слишком дружественны к общей мудрости, и эта перспектива имеет свою специфику, касающуюся определения масштаба цепи поставок. В терминах определения масштаба существуют две основные силы, которые в значительной степени определяют, что является и что не является допустимым масштабом для инициативы в сфере цепей поставок.
Первая сила, влияющая на определение масштаба, - это прикладной ландшафт. Цепь поставок в целом нельзя наблюдать непосредственно; ее можно наблюдать только косвенно через призму корпоративного программного обеспечения. Данные будут получены через эти программные продукты. Сложность инициативы в значительной степени зависит от количества и разнообразия этих программных продуктов. Каждое приложение является собственным источником данных, и извлечение и анализ данных из любого бизнес-приложения обычно является значительной задачей. Работа с большим количеством приложений обычно означает работу с несколькими технологиями баз данных, несогласованными терминологиями, несогласованными концепциями и значительным усложнением ситуации.
Таким образом, при определении масштаба мы должны признать, что допустимые границы обычно определяются самими бизнес-приложениями и их структурой базы данных. В этом контексте “начать с малого” должно быть понято как сохранение начального объема интеграции данных как можно меньшим, сохраняя при этом целостность инициативы в сфере цепей поставок в целом. Лучше углубиться, чем расширяться в плане интеграции приложений. Как только у вас есть ИТ-система, позволяющая получить некоторые записи из таблицы в данном приложении, обычно нетрудно получить все записи из этой таблицы и все записи из другой таблицы в том же приложении.
Одна из распространенных ошибок в области определения границ заключается в выборе выборки. Обычно выборка осуществляется путем выбора небольшого списка категорий товаров, сайтов или поставщиков. Выборка имеет благие намерения, но она не соответствует границам, определенным прикладным ландшафтом. Для реализации выборки необходимо применять фильтры во время извлечения данных, и этот процесс создает ряд проблем, которые могут подвергнуть опасности инициативу в сфере поставок.
Во-первых, фильтрованное извлечение данных из программного обеспечения предприятия требует больше усилий от команды ИТ, чем нефильтрованное извлечение. Фильтры должны быть разработаны с самого начала, и сам процесс фильтрации подвержен ошибкам. Отладка неправильных фильтров всегда трудоемка, поскольку требует многочисленных обменов с командами ИТ, что замедляет инициативу и, в конечном итоге, подвергает ее опасности.
Во-вторых, позволение инициативе выполнять свое внедрение на выборке данных является рецептом для массовых проблем с производительностью программного обеспечения при расширении инициативы впоследствии до полного объема. Плохая масштабируемость или неспособность обрабатывать большое количество данных, при этом удерживая затраты на вычисления под контролем, является очень распространенным дефектом программного обеспечения. Позволяя инициативе работать с выборкой, проблемы масштабируемости замаскированы, но вернутся с воинствующей силой на более позднем этапе.
Работа с выборкой данных делает статистику сложнее, а не проще. Действительно, доступ к большему количеству данных, вероятно, является самым простым способом улучшить точность и стабильность практически всех алгоритмов машинного обучения. Выборка данных противоречит этому пониманию. Таким образом, при использовании небольшой выборки данных инициатива может потерпеть неудачу из-за непредсказуемого числового поведения, наблюдаемого на выборке. Это поведение было бы в значительной степени смягчено, если бы вместо этого использовался весь набор данных.
Системные эффекты - вторая сила, влияющая на определение границ. Цепочка поставок - это система, и все ее части в некоторой степени связаны. Проблема с системами, любыми системами, заключается в том, что попытки улучшить часть системы скорее приводят к перемещению проблем, чем к их решению. Например, рассмотрим проблему распределения запасов в розничной сети с одним центром распределения и множеством магазинов. Если мы выберем один магазин в качестве начальной границы для нашей проблемы распределения запасов, то легко обеспечить этому магазину очень высокое качество обслуживания со стороны центра распределения, зарезервировав для него запасы заранее. Таким образом, мы можем гарантировать, что центр распределения никогда не останется без товара, обслуживая этот один магазин. Однако, это резервирование запасов будет осуществляться за счет качества обслуживания для других магазинов в сети.
Таким образом, при определении границы для инициативы в сфере поставок мы должны учитывать системные эффекты. Граница должна быть разработана таким образом, чтобы в значительной степени предотвратить локальную оптимизацию за счет элементов, находящихся за пределами границы. Эта часть упражнения по определению границ сложна, потому что все границы в некоторой степени протекают. Например, все части цепочки поставок в конечном итоге конкурируют за одинаковое количество денежных средств, доступных на уровне компании. Каждый выделенный где-то доллар - это доллар, который не будет доступен для других целей. Тем не менее, некоторые границы гораздо легче подвергаются игровым манипуляциям, чем другие. Важно выбрать границу, которая склонна смягчать системные эффекты, а не усиливать их.
Для многих практиков в области цепочки поставок мышление о границах инициативы в сфере поставок в терминах системных эффектов может показаться странным. Когда дело доходит до определения границ, большинство компаний склонны проецировать свою внутреннюю организацию на упражнение по определению границ. Таким образом, выбранные границы для границы неизбежно имитируют границы разделения труда, существующие внутри компании. Этот шаблон известен как закон Конвея. Предложенный Мелвином Конвеем полвека назад для систем связи, закон с тех пор был признан имеющим гораздо более широкое применение, включая применимость в области управления цепочкой поставок.
Границы и силосы, которые преобладают в современных цепях поставок, обусловлены разделением труда, являющимся следствием достаточно ручных процессов, используемых для принятия решений в цепи поставок. Например, если компания оценивает, что специалист по управлению предложением и спросом не может управлять более чем 1000 SKU, а у компании всего 50000 SKU для управления, то компании потребуется 50 специалистов по управлению предложением и спросом для этого. Однако, разделение оптимизации цепи поставок на 50 пар рук гарантированно приведет к множеству неэффективностей на уровне компании.
Напротив, инициатива, автоматизирующая эти решения, не должна учитывать те границы, которые отражают устаревшее или скоро устаревшее разделение труда. Числовой алгоритм может оптимизировать все 50000 SKU одновременно и устранить неэффективности, возникающие при противостоянии десятков силосов друг другу. Таким образом, естественно, что инициатива, нацеленная на автоматизацию этих решений, пересекается с многими существующими границами в компании. Компания, или, собственно, ее руководство, должны сопротивляться искушению имитировать существующие организационные границы, особенно на уровне определения рамок, так как это определяет тон для последующих действий.
Цепи поставок сложны с точки зрения аппаратного и программного обеспечения, а также людей. К сожалению, запуск количественной инициативы в области цепей поставок еще больше увеличивает сложность цепи поставок, по крайней мере, на начальном этапе. В долгосрочной перспективе это может фактически существенно снизить сложность цепи поставок, но мы, вероятно, к этому еще вернемся в одной из следующих лекций. Кроме того, чем больше людей участвует в инициативе, тем больше сложность самой инициативы. Если эта дополнительная сложность не будет немедленно под контролем, то есть высокая вероятность, что инициатива рухнет под собственной сложностью.
Таким образом, при размышлении о ролях в инициативе, то есть о том, кто будет делать что, нам нужно думать о наименьшем возможном наборе ролей, который делает инициативу жизнеспособной. Минимизируя количество ролей, мы минимизируем сложность инициативы, что в свою очередь значительно повышает ее шансы на успех. Эта перспектива обычно противоречит интуиции крупных компаний, которые любят работать с крайне детализированным разделением труда. Крупные компании обычно предпочитают крайних специалистов, которые делают только одну вещь. Однако цепь поставок - это система, и, как и все системы, важна перспектива от начала до конца.
Основываясь на опыте, накопленном в Lokad при проведении подобных инициатив, мы выделили четыре роли, которые обычно представляют собой наименьшее жизнеспособное разделение труда для проведения инициативы: руководитель цепи поставок, ответственный за данные, ученый в области цепей поставок и практикующий в области цепей поставок.
Роль руководителя цепи поставок заключается в поддержке инициативы, чтобы она вообще могла произойти. Получение хорошо разработанного числового алгоритма для принятия решений в цепи поставок в производстве представляет собой огромный толчок как с точки зрения прибыльности, так и производительности. Однако это также означает много изменений, которые нужно усвоить. Для того чтобы такие изменения произошли в крупной организации, требуется много энергии и поддержки со стороны высшего руководства.
Роль ответственного за данные заключается в настройке и поддержке конвейера данных. Большая часть их вклада ожидается в первые два месяца инициативы. Если конвейер данных правильно спроектирован, то после этого у ответственного за данные будет очень мало постоянных усилий. Обычно ответственный за данные не участвует в поздних стадиях инициативы.
Роль ученого в области цепей поставок заключается в разработке основного числового алгоритма. Эта роль начинается с необработанных транзакционных данных, предоставленных ответственным за данные. От ответственного за данные не требуется подготовка данных, только их извлечение. Роль ученого в области цепей поставок заканчивается принятием ответственности за принятые решения в цепи поставок. За принятие решения отвечает не программное обеспечение, а ученый в области цепей поставок. Для каждого принятого решения сам ученый должен быть в состоянии обосновать, почему это решение является адекватным.
Наконец, роль практика по управлению цепями поставок заключается в оспаривании решений, сгенерированных числовым алгоритмом, и предоставлении обратной связи ученому по управлению цепями поставок. Практик не имеет надежды принимать решение. Этот человек обычно отвечал за эти решения до сих пор, по крайней мере, в рамках подобласти, и обычно с помощью электронных таблиц и установленных систем. В небольшой компании возможно, что один человек выполняет и роль исполнительного директора по управлению цепями поставок, и роль практика по управлению цепями поставок. Также возможно обойти необходимость в должности ответственного за данные, если данные легко доступны. Это может произойти в компаниях, которые очень зрелы с точки зрения своей инфраструктуры данных. Напротив, если компания очень большая, возможно, что несколько, но только очень немногие, люди занимают каждую роль.
Успешное внедрение основного числового алгоритма имеет значительное влияние на мир практика по управлению цепями поставок. Действительно, в значительной степени целью инициативы является автоматизация предыдущей работы практика по управлению цепями поставок. Однако это не означает, что лучшим решением является увольнение этих практиков после внедрения числового алгоритма в производство. Мы вернемся к этому конкретному аспекту в следующей лекции.
Быть организованным не означает быть эффективным или результативным. Есть роли, которые, несмотря на хорошие намерения, добавляют трение к инициативам в области управления цепями поставок, часто до такой степени, что они полностью проваливаются. В настоящее время первая роль, которая больше всего способствует неудаче таких инициатив, обычно является ролью ученого по данным, особенно когда вовлечена целая команда ученых по данным. Кстати, Lokad узнал это на собственном опыте около десяти лет назад.
Несмотря на сходство в названиях между учеными по данным и учеными по управлению цепями поставок, эти две роли на самом деле очень разные. Ученый по управлению цепями поставок в первую очередь заботится о доставке решений, которые работают в реальном мире. Если это можно достичь с помощью полу-тривиального числового алгоритма, то это еще лучше; поддержка будет легкой. Ученый по управлению цепями поставок полностью отвечает за работу с самыми мелкими деталями цепи поставок. Надежность и устойчивость к окружающему хаосу важнее сложности.
Напротив, ученый по данным фокусируется на умных частях числового алгоритма, моделях и алгоритмах. Ученый по данным, в общих чертах, считает себя экспертом в области машинного обучения и математической оптимизации. В технологическом плане ученый по данным готов изучать последний передовой открытый числовой инструментарий, но обычно не желает изучать трехдесятилетнюю систему планирования ресурсов предприятия, которая используется в компании. Кроме того, ученый по данным не является экспертом по управлению цепями поставок и обычно не желает им стать. Ученый по данным стремится доставить лучшие результаты в соответствии с согласованными метриками. Ученый не стремится заниматься очень обыденными деталями цепи поставок; эти элементы ожидается, что будут обрабатываться другими людьми.
Вовлечение ученых по данным приносит неудачу для этих инициатив, потому что, как только вовлечены ученые по данным, цепь поставок перестает быть фокусом - алгоритмы и модели становятся таковыми. Никогда не недооценивайте силу отвлечения, которое последняя модель или алгоритм представляют для умного, технически подкованного человека.
Вторая роль, которая часто добавляет трение к инициативе в области управления цепями поставок, - это команда бизнес-аналитики (BI). Когда команда BI является частью инициативы, они часто являются помехой, хотя и в значительно меньшей степени, чем команда ученых по данным. Проблема с BI в основном культурная. BI предоставляет отчеты, а не решения. Команда BI обычно готова создавать бесконечные стены метрик, как требуется каждым отделом компании. Это не правильное отношение для количественной инициативы в области управления цепями поставок.
Кроме того, бизнес-аналитика как программное обеспечение является очень специфическим классом анализа данных, ориентированным на кубы или OLAP-кубы, которые позволяют анализировать большинство систем в памяти в корпоративных системах. Такой дизайн обычно не подходит для принятия решений в области управления цепями поставок.
Теперь, когда мы определили инициативу, давайте рассмотрим архитектуру высокого уровня ИТ, которая требуется для этой инициативы.
Схема на экране иллюстрирует типичную настройку конвейера данных для количественной инициативы в сфере поставок. В этой лекции я рассматриваю конвейер данных, который не поддерживает требования к низкой задержке. Мы хотим иметь возможность завершить полный цикл примерно за один час, а не за одну секунду. Большинство решений в сфере поставок, таких как заказы на закупку, не требуют настройки с низкой задержкой. Для достижения конечно-конечной низкой задержки требуется другой тип архитектуры, который выходит за рамки сегодняшней лекции.
Системы транзакций представляют собой первоначальный источник данных и отправную точку конвейера данных. Эти системы включают ERP, WMS и EDI. Они занимаются потоком товаров, таких как закупка, транспортировка, производство и продажа. В этих системах содержится практически все данные, необходимые для основного числового рецепта. Для практически любой крупной компании эти системы или их предшественники существуют уже как минимум два десятилетия.
Поскольку в этих системах содержится практически все необходимые данные, было бы заманчиво реализовать числовой рецепт непосредственно в этих системах. В самом деле, почему бы и нет? Разместив числовой рецепт прямо в ERP, мы избавились бы от необходимости настраивать весь этот конвейер данных. К сожалению, это не работает из-за самой концепции этих транзакционных систем.
Эти системы транзакций неизменно строятся на основе транзакционной базы данных. Этот подход к проектированию корпоративного программного обеспечения остается крайне стабильным уже последние четыре десятилетия. Возьмите любую случайную компанию, и вероятность того, что каждое бизнес-приложение в производстве реализовано поверх транзакционной базы данных, очень высока. Транзакционные базы данных предлагают четыре ключевых свойства, известных под аббревиатурой ACID, что означает Atomicity (атомарность), Consistency (согласованность), Isolation (изоляция) и Durability (надежность). Я не собираюсь углубляться в детали этих свойств, но скажу лишь, что эти свойства делают базу данных очень подходящей для безопасного и параллельного выполнения множества малых операций чтения и записи. Ожидается, что количество операций чтения и записи будет достаточно сбалансированным.
Однако цена, которую приходится платить за эти очень полезные свойства ACID на самом мельчайшем уровне, заключается в том, что транзакционная база данных также является очень неэффективной при обслуживании больших операций чтения. Операция чтения, которая охватывает значительную часть всей базы данных, как правило, если данные обслуживаются через базу данных, которая фокусируется на очень детальной доставке этих свойств ACID, то можно ожидать, что стоимость вычислительных ресурсов будет увеличена в 100 раз по сравнению с архитектурами, которые не ставят такого большого акцента на эти свойства ACID на таком детальном уровне. ACID хорош, но это стоит огромной цены.
Более того, когда кто-то пытается прочитать значительную часть всей базы данных, база данных, скорее всего, становится нереагирующей на некоторое время, так как она выделяет большую часть своих ресурсов для обслуживания этого одного большого запроса. Многие компании жалуются, что их весь бизнес-системы работают медленно и что эти системы часто замирают на одну секунду или дольше. Обычно эта низкая качества обслуживания можно проследить до тяжелых SQL-запросов, которые пытаются прочитать слишком много строк за один раз.
Поэтому основной числовой рецепт не может работать в той же среде, что и транзакционные системы, поддерживающие производство. Действительно, числовым рецептам придется получать доступ к большей части данных при каждом запуске. Таким образом, числовой рецепт должен быть строго изолирован в своей собственной подсистеме, хотя бы для того, чтобы избежать деградации производительности этих транзакционных систем.
Кстати, хотя уже десятилетия известно, что плохая идея - это иметь процесс с интенсивной работой с данными внутри транзакционной системы, это не мешает большинству поставщиков транзакционных систем (ERP, MRP, WMS) продавать интегрированные аналитические модули, например, модули оптимизации запасов. Имея эти интегрированные модули, неизбежно возникают проблемы с качеством обслуживания, предоставляя недостаточные возможности. Все эти проблемы можно проследить до этой единственной проблемы проектирования: транзакционная система и аналитическая система должны быть строго изолированы.
Озеро данных просто. Это зеркало транзакционных данных, нацеленное на очень большие операции чтения. Действительно, мы видели, что транзакционные системы оптимизированы для множества маленьких операций чтения, а не для очень больших. Таким образом, чтобы сохранить качество обслуживания транзакционной системы, правильное проектирование заключается в тщательном реплицировании транзакционных данных в другую систему, а именно в озеро данных. Эта репликация должна быть реализована аккуратно, именно для сохранения качества обслуживания транзакционной системы, что обычно означает чтение данных в очень инкрементальных способах и избегание создания пиковых нагрузок на транзакционную систему.
Как только соответствующие транзакционные данные отражены в озере данных, само озеро данных обслуживает все запросы данных. Дополнительным преимуществом озера данных является его способность обслуживать несколько аналитических систем. В то время как мы здесь обсуждаем цепочку поставок, если маркетинг хочет свою собственную аналитику, им понадобятся те же самые транзакционные данные, и то же самое можно сказать о финансах, продажах и т. д. Таким образом, вместо того, чтобы каждое отделение компании реализовывало свой собственный механизм извлечения данных, имеет смысл объединить все эти извлечения в одно и то же озеро данных, в одну и ту же систему.
На техническом уровне озеро данных может быть реализовано с помощью реляционной базы данных, обычно настроенной для извлечения больших данных, с применением колоночного хранения данных. Озера данных также могут быть реализованы в виде хранилища плоских файлов, обслуживаемых распределенной файловой системой. По сравнению с транзакционной системой, озеро данных отказывается от тонкой транзакционной функциональности. Цель состоит в том, чтобы обслуживать большое количество данных как можно дешевле и надежнее — ничего больше и ничего меньше.
Озеро данных должно отражать исходные транзакционные данные, что означает копирование без изменений. Важно не подготавливать данные в озере данных. К сожалению, команда ИТ, ответственная за настройку озера данных, может искушена упростить и упростить задачи для других команд и немного подготовить данные. Однако изменение данных неизбежно вводит сложности, которые подрывают аналитику на более поздних этапах. Кроме того, строгое соблюдение политики отражения значительно снижает количество усилий, необходимых для настройки и последующего обслуживания озера данных командой ИТ.
В компаниях, где уже есть команда бизнес-аналитики, может быть искушение использовать системы бизнес-аналитики в качестве озера данных. Однако я настоятельно рекомендую не делать этого и никогда не использовать настройку бизнес-аналитики в качестве озера данных. Действительно, данные в системах бизнес-аналитики уже неизбежно сильно преобразованы. Использование данных бизнес-аналитики для принятия автоматизированных решений в цепи поставок приводит к проблемам “мусор внутри, мусор снаружи”. Озеро данных должно питаться только из первичных источников данных, таких как ERP, а не из вторичных источников данных, таких как система бизнес-аналитики.
Аналитическая система содержит основной числовой рецепт. Она также предоставляет все необходимые отчеты для инструментирования самих решений. На техническом уровне аналитическая система содержит “умные части”, такие как алгоритмы машинного обучения и математические алгоритмы оптимизации. Хотя на практике эти умные части не являются доминирующими в кодовой базе аналитических систем. Обычно подготовка данных и инструментирование данных требуют как минимум в десять раз больше строк кода, чем части, связанные с обучением и оптимизацией.
Аналитическая система должна быть отделена от озера данных, потому что эти две системы полностью противоположны с точки зрения технологических перспектив. Как программное обеспечение, озеро данных ожидается быть очень простым, очень стабильным и чрезвычайно надежным. Напротив, аналитическая система должна быть сложной, постоянно развивающейся и крайне производительной с точки зрения эффективности цепи поставок. В отличие от озера данных, которое должно обеспечивать почти идеальное время работы, аналитическая система даже не обязана быть включенной большую часть времени. Например, если мы рассматриваем ежедневные решения по пополнению запасов, то аналитическая система должна работать и быть включенной только один раз в день.
По правилу, лучше допустить сбой аналитической системы в процессе принятия решений, чем получить неверные решения и допустить их попадание в производство. Задержка принятия решений в цепи поставок на несколько часов, например, при оформлении заказов, обычно намного менее критична, чем принятие неверных решений. Поскольку конструкция аналитической системы обычно сильно зависит от умных компонентов, содержащихся в ней, о дизайне аналитической системы в общем случае нельзя сказать многое. Однако есть по крайней мере одно ключевое свойство дизайна, которое необходимо соблюдать для экосистемы: эта система должна быть без состояния.
Аналитическая система должна избегать наличия внутреннего состояния насколько это возможно. Другими словами, вся экосистема должна начинаться с данных, представленных в хранилище данных, и заканчиваться сгенерированными намеренными решениями в цепи поставок, а также сопроводительными отчетами. Часто случается так, что когда внутри аналитической системы есть компонент, который работает слишком медленно, например, алгоритм машинного обучения, возникает искушение ввести состояние, то есть сохранить некоторую информацию из предыдущего выполнения, чтобы ускорить следующее выполнение. Однако это опасно, так как полагаться на ранее вычисленные результаты вместо повторного вычисления всего с нуля каждый раз.
Действительно, наличие состояния в аналитической системе ставит решение под угрозу. В то время как проблемы с данными неизбежно возникнут и будут исправлены на уровне хранилища данных, аналитическая система все равно может возвращать решения, отражающие проблему, которая уже была исправлена. Например, если модель прогнозирования спроса обучается на поврежденном наборе данных о продажах, то модель прогнозирования остается поврежденной, пока она не будет обучена на свежей, исправленной версии набора данных. Единственный способ избежать того, чтобы аналитическая система страдала от эха проблем с данными, которые уже были исправлены в хранилище данных, - это обновлять все каждый раз. В этом суть отсутствия состояния.
По правилу, если часть аналитической системы оказывается слишком медленной для ежедневной замены, то эту часть следует считать страдающей от проблемы производительности. Цепи поставок хаотичны, и наступит день, когда что-то случится - пожар, блокировка, кибератака - и потребуется немедленное вмешательство. Компания должна иметь возможность обновить все свои решения в цепи поставок в течение одного часа. Компания не должна ждать и застревать на 10 часов, пока происходит медленная фаза обучения машинного обучения.
Для надежной работы аналитическая система должна быть должным образом инструментирована. Об этом говорят отчет о состоянии данных и инспекторы данных. Кстати, все эти элементы являются ответственностью цепи поставок, а не IT. Мониторинг состояния данных представляет собой самую первую фазу обработки данных, еще до самой подготовки данных, и происходит внутри аналитической системы. Состояние данных является частью инструментирования числового рецепта. Отчет о состоянии данных указывает, можно ли вообще запускать числовой рецепт. Этот отчет также указывает на источник проблемы с данными, если таковая имеется, чтобы ускорить ее устранение.
Мониторинг состояния данных - это практика в Lokad. За последнее десятилетие эта практика доказала свою ценность для предотвращения ситуаций “мусор внутри, мусор снаружи”, которые, кажется, являются повсеместными в мире корпоративного программного обеспечения. Действительно, когда не удается обработать данные, часто винят плохие данные. Однако важно отметить, что обычно практически не предпринимается никаких усилий по инженерии для обеспечения качества данных в первую очередь. Качество данных не появляется из воздуха; для этого требуются инженерные усилия.
Представленная до сих пор конвейерная система данных довольно минималистична. Зеркалирование данных - это настолько просто, насколько это возможно, что является хорошим для качества программного обеспечения. Тем не менее, несмотря на этот минимализм, здесь все еще есть много движущихся частей: много таблиц, много систем, много людей. Таким образом, ошибки повсюду. Это корпоративное программное обеспечение, и противоположное было бы довольно удивительно. Мониторинг состояния данных существует, чтобы помочь аналитической системе выжить в окружающем хаосе.
Состояние данных не следует путать с очисткой данных. Состояние данных - это только о том, чтобы убедиться, что данные, доступные аналитической системе, являются точным представлением транзакционных данных, существующих в транзакционных системах. Не предпринимается попытка исправить данные; данные анализируются “как есть”.
В Lokad мы обычно разделяем низкоуровневое состояние данных от высокоуровневого состояния данных. Низкоуровневое состояние данных - это панель управления, которая consolide все структурные и объемные особенности данных, такие как очевидные проблемы, например, записи, которые даже не являются разумными датами или числами, или сиротские идентификаторы, которым не хватает ожидаемых парных элементов. Все эти проблемы могут быть видны и на самом деле являются простыми. Сложная проблема начинается с проблем, которые нельзя увидеть, потому что данные отсутствуют. Например, если что-то пошло не так с извлечением данных и данные о продажах, извлеченные из вчерашнего дня, содержат только половину ожидаемых строк, это действительно может поставить под угрозу производство. Неполные данные особенно коварны, потому что они обычно не помешают числовому рецепту генерировать решения, за исключением того, что эти решения будут мусорными, так как входные данные неполные.
Технически, в Lokad мы стараемся поддерживать мониторинг состояния данных на одной панели управления, и эта панель управления обычно предназначена для IT-команды, поскольку большинство проблем, выявленных низкоуровневым состоянием данных, обычно связаны с самим конвейером данных. Идеально, IT-команда должна быть в состоянии сразу определить, все ли в порядке или нет и требуется ли дальнейшее вмешательство.
Мониторинг состояния данных высокого уровня рассматривает все особенности на уровне бизнеса - элементы, которые выглядят неправильно с бизнес-точки зрения. Высокоуровневое состояние данных охватывает такие элементы, как отрицательные уровни запасов или аномально большие минимальные заказные количества. Оно также охватывает такие вещи, как цены, которые не имеют смысла, потому что компания будет работать в убыток или с чрезвычайно высокими маржами. Высокоуровневое состояние данных пытается охватить все элементы, при которых практик поставочной цепи посмотрит на данные и скажет: “Это невозможно, у нас проблема”.
В отличие от отчета о низкоуровневом состоянии данных, отчет о высокоуровневом состоянии данных предназначен в первую очередь для команды поставочной цепи. Действительно, проблемы, такие как аномальные минимальные заказные количества, будут восприниматься как проблемы только практиком, который в некоторой степени знаком с деловой средой. Цель этого отчета - быть в состоянии сразу определить, что все в порядке и дальнейшее вмешательство не требуется.
Ранее я сказал, что аналитическая система должна быть без состояния. Оказывается, что состояние данных - это исключение, которое подтверждает правило. Действительно, многие проблемы могут быть идентифицированы путем сравнения текущих показателей с теми же показателями, собранными за предыдущие дни. Таким образом, мониторинг состояния данных обычно сохраняет некоторое состояние, которое в основном является ключевыми показателями, наблюдаемыми за предыдущие дни, чтобы он мог идентифицировать выбросы в текущем состоянии данных. Однако, поскольку состояние данных - это чисто вопрос мониторинга, худшее, что может произойти, если есть проблема на уровне озера данных, которая была исправлена, а затем у нас есть эхо прошлых проблем в состоянии состояния данных, это серия ложных сигналов от этих отчетов. Логика, генерирующая решения поставочной цепи, остается полностью без состояния; состояние касается только небольшой части инструментария.
Мониторинг состояния данных как на низком, так и на высоком уровне - это вопрос компромисса между риском предоставления неправильных решений и риском непредоставления решений вовремя. При рассмотрении больших поставочных цепей неразумно ожидать, что 100 процентов данных будут правильными - неправильные транзакционные записи случаются, даже если они редки. Таким образом, должен быть объем проблем, который следует считать достаточно низким для работы числового рецепта. Компромисс между этими двумя рисками - быть чрезмерно чувствительным к ошибкам данных или быть слишком терпимым к проблемам данных - сильно зависит от экономической структуры поставочной цепи.
В Lokad мы создаем и настраиваем эти отчеты для каждого клиента отдельно. Вместо того, чтобы преследовать каждый возможный случай повреждения данных, ученый поставочной цепи, который отвечает за реализацию низкоуровневого и высокоуровневого состояния данных и инспекторов данных, о которых я расскажу через минуту, пытается настроить мониторинг состояния данных таким образом, чтобы он был чувствителен к тому роду проблем, которые действительно наносят ущерб и действительно происходят для интересующей поставочной цепи.
На жаргоне Lokad инспектор данных, или просто инспектор, представляет собой отчет, который объединяет все соответствующие данные, касающиеся объекта интереса. Ожидается, что объект интереса будет одним из граждан первого класса с точки зрения цепочки поставок - продуктом, поставщиком, клиентом или складом. Например, если мы рассматриваем инспектор данных для продуктов, то для любого продукта, продаваемого компанией, мы должны иметь возможность видеть на одном экране все данные, привязанные к этому продукту. В инспекторе данных для продуктов фактически есть столько же представлений, сколько и продуктов, потому что, когда я говорю, что мы видим все данные, я имею в виду все данные, привязанные к одному штрих-коду или номеру детали, а не ко всем продуктам в целом.
В отличие от отчетов о состоянии данных низкого и высокого уровня, которые должны быть двумя панелями инструментов, которые можно проверить взглядом, инспекторы реализованы для решения вопросов и проблем, которые неизбежно возникают при проектировании и эксплуатации основного числового рецепта. Действительно, для принятия решения в цепочке поставок часто требуется объединение данных из десятка таблиц, возможно, происходящих из нескольких транзакционных систем. Поскольку данные находятся везде, когда решение выглядит подозрительным, обычно сложно определить источник проблемы. Может быть разрыв между данными, видимыми аналитической системой, и данными, существующими в транзакционной системе. Может быть неправильный алгоритм, который не улавливает статистический паттерн в данных. Может быть неверное восприятие, и решение, которое считается подозрительным, на самом деле может быть правильным. В каждом случае инспектор предназначен для возможности углубленного анализа объекта интереса.
Чтобы быть полезными, инспекторы должны отражать специфику как цепочки поставок, так и прикладного ландшафта. В результате создание инспекторов является практически индивидуальным упражнением. Тем не менее, после завершения работы инспектор представляет собой одну из основных составляющих инструментации самой аналитической системы.
В заключение, хотя большинство количественных инициатив в цепочке поставок предрекают неудачу еще до их начала, это необязательно так. Тщательный выбор результатов, сроков, объема и правил необходим для избежания проблем, которые неизбежно приводят к неудаче таких инициатив. К сожалению, эти выборы часто являются несколько контринтуитивными, как Lokad узнал на собственном опыте за 14 лет работы.
Самое начало инициативы должно быть посвящено настройке конвейера данных. Ненадежный конвейер данных - один из самых надежных способов обеспечить неудачу любой инициативы, основанной на данных. Большинство компаний, даже большинство IT-отделов, недооценивают важность высоконадежного конвейера данных, который не требует постоянного тушения пожаров. В то время как основная часть настройки конвейера данных выпадает на долю IT-отдела, сама цепочка поставок должна быть ответственна за инструментацию аналитической системы, которую она использует. Не ожидайте, что IT сделает это за вас; это задача команды цепочки поставок. Мы видели два разных типа инструментации, а именно отчеты о состоянии данных, которые принимают общую перспективу компании, и инспекторы данных, которые поддерживают глубокую диагностику.
Сегодня мы обсудили, как начать инициативу, но в следующий раз мы увидим, как ее завершить, или, скорее, как привести ее к успешному завершению. На следующей лекции, которая состоится в среду, 14 сентября, мы продолжим наше путешествие и посмотрим, какой вид выполнения требуется для создания основного числового рецепта, а затем постепенно привести принимаемые им решения в производство. Мы также ближе рассмотрим, что это новый способ работы с цепочкой поставок означает для повседневной работы практиков в области цепочки поставок.
Теперь давайте посмотрим на вопросы.
Вопрос: Почему именно шесть месяцев является временным ограничением, после которого реализация считается неправильной?
Я бы сказал, что проблема не в том, что у нас есть ограничение в шесть месяцев. Проблема заключается в том, что обычно инициативы предназначены для провала с самого начала. В этом и заключается проблема. Если ваша инициатива по предсказательной оптимизации начинается с того, что результаты будут доставлены через два года, то можно с уверенностью сказать, что инициатива рано или поздно распадется и не приведет к доставке чего-либо в производство. Если бы я мог, я бы предпочел, чтобы инициатива успешно завершилась за три месяца. Однако шесть месяцев представляют минимальный срок в моем опыте, необходимый для достижения такой инициативы в производство. Любая дополнительная задержка увеличивает риск провала инициативы. Очень сложно сжать этот срок еще больше, потому что после решения всех технических проблем оставшиеся задержки отражают время, необходимое для вовлечения людей в инициативу.
Вопрос: Практики в сфере цепей поставок могут разочаровываться инициативой, которая заменяет большую часть их рабочей нагрузки, такую как отдел закупок, в конфликте с автоматизацией принятия решений. Как бы вы посоветовали справиться с этим?
Это очень важный вопрос, который, надеюсь, будет рассмотрен в следующей лекции. На сегодняшний день я могу сказать, что, по моему мнению, большая часть того, что делают практики в сфере цепей поставок в современных цепях поставок, не очень стимулирует. В большинстве компаний люди получают набор артикулов или номеров деталей и затем бесконечно перебирают их, принимая все необходимые решения. Это означает, что их работа сводится к просмотру электронных таблиц и еженедельному или, возможно, ежедневному перебору. Это неудовлетворительная работа.
Краткий ответ заключается в том, что подход Lokad решает проблему путем автоматизации всех рутинных аспектов работы, чтобы люди, обладающие настоящими знаниями в области цепей поставок, могли начать вызывать основы цепи поставок. Это позволяет им больше общаться с клиентами и поставщиками, чтобы сделать все более эффективным. Речь идет о сборе информации, чтобы мы могли улучшить числовой рецепт. Выполнение числового рецепта утомительно, и очень мало людей сожалеют о старых временах, когда им приходилось ежедневно перебирать электронные таблицы.
Вопрос: Ожидается ли, что практики в сфере цепей поставок будут работать с отчетами о состоянии данных, чтобы оспорить решения, созданные учеными в области цепей поставок?
Ожидается, что практики в сфере цепей поставок будут работать с инспекторами данных, а не с отчетами о состоянии данных. Отчеты о состоянии данных подобны оценке всей компании, которая отвечает на вопрос, достаточно ли данных на входе аналитической системы для работы числового рецепта. Результатом отчета о состоянии данных является двоичное решение: разрешить выполнение числового рецепта или противостоять ему и сказать, что есть проблема, которую нужно исправить. Инспекторы данных, о которых будет рассказано подробнее в следующей лекции, являются точкой входа для практиков в сфере цепей поставок, чтобы получить представление о предлагаемом решении в области цепей поставок.
Вопрос: Возможно ли обновлять аналитическую модель, например, устанавливать политику запасов ежедневно? Система цепи поставок не может реагировать на ежедневные изменения политики, не приведет ли это к появлению шума в системе?
Чтобы ответить на первую часть вопроса, обновление аналитической модели ежедневно, конечно, возможно. Например, когда Lokad работал в 2020 году в условиях введения карантина в Европе, у нас были страны, которые закрывались и открывались всего за 24 часа. Это создавало чрезвычайно хаотическую ситуацию, требующую постоянных немедленных корректировок ежедневно. Lokad работала под этим огромным давлением, управляя карантинами, которые начинались или заканчивались ежедневно по всей Европе в течение почти 14 месяцев.
Таким образом, ежедневное обновление аналитической модели возможно, но не всегда желательно. Действительно, системы цепей поставок имеют много инерции, и первое, с чем должен считаться соответствующий числовой рецепт, это эффект рейки большинства решений. Когда вы уже заказали производство и расходуются сырьевые материалы, вы не можете отменить производство. Вы должны учитывать, что многие решения уже были приняты при принятии новых. Однако, когда вы понимаете, что вашей цепи поставок требуется кардинальное изменение в ее действиях, нет смысла откладывать эту коррекцию только ради отсрочки решения. Лучшее время для внедрения изменений - прямо сейчас.
Что касается аспекта шума в вопросе, здесь все сводится к правильному проектированию численных алгоритмов. Существует множество неправильных проектов, которые нестабильны, где небольшие изменения в данных приводят к большим изменениям в решениях, представляющих результат численного алгоритма. Численный алгоритм не должен быть скачкообразным при малейшем изменении в цепи поставок. Вот почему Lokad принял вероятностную перспективу в прогнозировании. При использовании вероятностной перспективы модели могут быть спроектированы намного более стабильными по сравнению с моделями, которые пытаются уловить среднее значение и становятся скачкообразными при возникновении выброса в цепи поставок.
Вопрос: Одной из проблем, с которыми мы сталкиваемся в цепи поставок с очень крупными компаниями, является их зависимость от различных исходных систем. Разве не чрезвычайно сложно объединить все данные из этих исходных систем в одну унифицированную систему?
Я полностью согласен с тем, что получение всех данных является значительным вызовом для многих компаний. Однако мы должны задать себе вопрос, почему это вызов в первую очередь. Как я уже упоминал ранее, 99% бизнес-приложений, работающих в настоящее время в крупных компаниях, полагаются на основные, хорошо разработанные транзакционные базы данных. Возможно, все еще существуют несколько устаревших реализаций на COBOL, работающих на арканном двоичном хранилище, но это редкость. Подавляющее большинство бизнес-приложений, даже те, которые были развернуты в 1990-х годах, работают с чистой транзакционной базой данных высокого качества на заднем плане.
После того, как у вас есть транзакционная база данных, почему должно быть сложно скопировать эти данные в озеро данных? В большинстве случаев проблема заключается в том, что компании не просто пытаются скопировать данные - они пытаются сделать гораздо больше. Они пытаются подготовить и преобразовать данные, часто усложняя процесс. В большинстве современных настроек баз данных есть встроенные возможности зеркалирования данных, позволяющие реплицировать все изменения из транзакционной базы данных во вторичную базу данных. Это встроенное свойство, вероятно, для 20 наиболее часто используемых транзакционных систем на рынке.
Компании часто сталкиваются с трудностями в консолидации данных, потому что они пытаются сделать слишком много, и их инициативы рушатся из-за собственной сложности. Когда данные сконсолидированы, компании часто допускают ошибку, думая, что подключение данных должно выполняться IT-, BI- или командами по науке о данных. То, что я хочу сказать здесь, заключается в том, что цепочка поставок должна быть ответственна за свои собственные численные алгоритмы, так же как маркетинг, продажи и финансы. Это не должно быть поперечным подразделением поддержки, которое пытается сделать это для компании. Подключение данных из разных систем обычно требует множества бизнес-инсайтов. Крупные компании часто терпят неудачу, потому что они пытаются найти эксперта из IT-, BI- или команд по науке о данных, чтобы выполнить эту работу, когда она должна выполняться внутри интересующего подразделения.
Большое спасибо за ваше время сегодня, за ваш интерес и ваши вопросы. Увидимся в следующий раз после лета, в сентябре.
