00:00 Введение
02:52 Предпосылки и отказ от ответственности
07:39 Наивный рационализм
13:14 История до настоящего момента
16:37 Учёные, мы нуждаемся в вас!
18:25 Человек + Машина (проблема 1/4)
23:16 Настройка (проблема 2/4)
26:44 Поддержка (проблема 3/4)
30:02 IT-бэклог (проблема 4/4)
32:56 Миссия (работа учёного 1/6)
35:58 Терминология (работа учёного 2/6)
37:54 Результаты (работа учёного 3/6)
41:11 Сфера ответственности (работа учёного 4/6)
44:59 Ежедневная рутина (работа учёного 5/6)
46:58 Ответственность (работа учёного 6/6)
49:25 Должность в цепях поставок (HR 1/6)
51:13 Найм учёного (HR 2/6)
53:58 Обучение учёного (HR 3/6)
55:43 Оценка учёного (HR 4/6)
57:24 Удержание учёного (HR 5/6)
59:37 От одного учёного к другому (HR 6/6)
01:01:17 Об IT (корпоративная динамика 1/3)
01:03:50 О финансах (корпоративная динамика 2/3)
01:05:42 О лидерстве (корпоративная динамика 3/3)
01:09:18 Планирование в старом стиле (модернизация 1/5)
01:11:56 Конец S&OP (модернизация 2/5)
01:13:31 Бизнес-аналитика в старом стиле (модернизация 3/5)
01:15:24 Прощание с Data Science (модернизация 4/5)
01:17:28 Новая договорённость для IT (модернизация 5/5)
01:19:28 Заключение
01:22:05 7.3 Учёный по цепям поставок - Вопросы?
Описание
В основе инициативы Количественная цепь поставок находится Учёный по цепям поставок (SCS), который занимается подготовкой данных, экономическим моделированием и составлением отчетов по KPI. Умная автоматизация решений по цепям поставок является конечным результатом работы SCS. SCS принимает на себя ответственность за принятые решения. SCS обеспечивает человеческий интеллект, усиленный вычислительной мощностью машин.
Полная стенограмма
Добро пожаловать в эту серию лекций по цепям поставок. Меня зовут Жоанн Верморель, и сегодня я представлю учёного по цепям поставок с точки зрения количественной цепи поставок. Учёный по цепям поставок — это человек или, возможно, небольшая группа людей, отвечающих за запуск инициативы по управлению цепями поставок. Этот человек контролирует создание, а затем поддержание числовых рецептов, которые генерируют необходимые решения. Также он отвечает за предоставление всех необходимых доказательств остальной части компании, подтверждая, что принятые решения обоснованы.
Девиз количественной цепи поставок заключается в том, чтобы максимально использовать возможности, которые современное аппаратное и программное обеспечение могут предложить цепям поставок. Однако воплощение этой идеи на практике наивно. Человеческий интеллект всё ещё является краеугольным камнем всей инициативы, и по ряду причин его пока нельзя красиво упаковать с точки зрения цепей поставок. Цель этой лекции — понять, почему и как роль учёного по цепям поставок за последнее десятилетие стала проверенным временем решением для максимального использования современного ПО в целях управления цепями поставок.
Достижение этой цели начинается с понимания значительных узких мест, с которыми всё ещё сталкивается современное ПО при попытке автоматизировать принятие решений в цепях поставок. Исходя из этого нового понимания, мы представим роль учёного по цепям поставок, которая по сути является ответом на эти узкие места. Наконец, мы увидим, как эта роль в малой или большой степени переопределяет всю компанию. Действительно, учёный по цепям поставок не может работать в изоляции, как сило внутри компании. Так же, как учёному необходимо сотрудничать с остальной частью компании для достижения результатов, остальная часть компании также должна сотрудничать с учёным для того, чтобы это произошло.
Прежде чем двигаться дальше, я хотел бы повторить отказ от ответственности, который я озвучил в первой лекции этой серии. Настоящая лекция почти полностью основана на уникальном десятилетнем эксперименте, проведенном в компании Lokad, поставщике enterprise software, специализирующемся на оптимизации цепей поставок. Все эти лекции сформированы на основе пути Lokad, но когда речь идет о роли учёного по цепям поставок, связь становится еще прочнее. В значительной степени путь самой компании Lokad можно прочитать через призму нашего постепенного открытия роли учёного по цепям поставок.
Этот процесс все еще продолжается. Например, около пяти лет назад мы отказались от традиционного подхода data scientist с введением программных парадигм для обучения и оптимизации. В настоящее время в Lokad работает около трех десятков учёных по цепям поставок. Наши самые способные учёные, благодаря своим достижениям, получили доверие в принятии решений в крупном масштабе. Некоторые из них отвечают за параметры, стоимость запасов которых превышает полмилиарда долларов. Это доверие распространяется на широкий спектр решений, таких как заказы на закупку, производственные заказы, заказы на распределение запасов или ценообразование.
Как вы, возможно, понимаете, это доверие пришлось заслужить. Действительно, очень немногие компании доверили бы своим сотрудникам такие полномочия, не говоря уже о стороннем поставщике, таком как Lokad. Заработать такое доверие — процесс, который обычно занимает годы, независимо от технологических возможностей. Однако, спустя десятилетие, Lokad растет быстрее, чем когда-либо в первые годы, и значительная часть этого роста поступает от наших существующих клиентов, которые расширяют сферу решений, доверенных Lokad.
Это возвращает меня к моей начальной мысли: эта лекция почти наверняка сопровождается всевозможными предвзятостями. Я пытался расширить эту перспективу, опираясь на аналогичный опыт за пределами Lokad; однако сказать на эту тему не так уж много можно. Насколько мне известно, существует несколько технологических гигантов, а точнее, несколько огромных компаний электронной коммерции, которые достигают уровня автоматизации принятия решений, сопоставимого с тем, что достигает Lokad.
Однако эти гиганты обычно выделяют в два порядка больше ресурсов, чем могут позволить себе обычные крупные компании, привлекая сотни инженеров. Для меня целесообразность таких подходов неясна, так как они могут работать только в исключительно прибыльных компаниях. В противном случае огромные затраты на заработную плату могут легко превысить выгоды, полученные от более эффективного управления цепями поставок.
Кроме того, привлечение инженерных талантов в таком объеме становится отдельной задачей. Найти одного талантливого программиста достаточно сложно; нанять 100 из них требует поистине выдающегося бренда работодателя. К счастью, представленная сегодня перспектива значительно проще. Многие инициативы в области цепей поставок, проводимые в Lokad, реализуются одним учёным по цепям поставок, а второй работает в качестве замены. Помимо экономии на зарплате, наш опыт показывает, что существует значительная польза для цепей поставок, связанная с меньшим количеством сотрудников.
Основной подход в цепях поставок опирается на прикладную математику. Методы и алгоритмы представлены таким образом, что человеческий оператор полностью исключается из процесса. Например, формула резервного запаса и формула экономичного объема заказа воспринимаются как чисто математическая задача. Личность человека, использующего эти формулы, его навыки или опыт, например, не только не имеют значения, но даже не включены в презентацию.
В более широком смысле данная позиция широко используется в учебниках по цепям поставок и, следовательно, в программном обеспечении для цепей поставок. Несомненно, кажется более объективным исключить человеческий компонент из процесса. В конце концов, корректность теоремы не зависит от человека, излагающего доказательство, и, аналогично, эффективность алгоритма не зависит от того, кто совершил последнее нажатие клавиши при его реализации. Этот подход нацелен на достижение высшей формы рациональности.
Однако я утверждаю, что эта позиция наивна и представляет собой еще один пример наивного рационализма. Мое утверждение тонкое, но важное: я не говорю, что результат числового рецепта зависит от человека, который в конечном итоге его запускает, и не утверждаю, что характер математика имеет какое-либо отношение к обоснованности его теорем. Вместо этого мое утверждение заключается в том, что интеллектуальный подход, связанный с этой перспективой, не подходит для анализа цепей поставок.
Реальный рецепт для цепей поставок — это сложное произведение мастерства, и его автор вовсе не так нейтрален и незначителен, как может показаться. Проиллюстрируем это, рассмотрев два идентичных числовых рецепта, отличающихся только именованием переменных. На числовом уровне оба рецепта дают идентичные результаты. Однако в первом рецепте выбраны понятные, осмысленные имена переменных, тогда как во втором используются криптичные и непоследовательные имена. В производственной среде второй рецепт (тот, у которого криптичные и непоследовательные имена переменных) — это катастрофа, которая только и ждет, когда случится. Каждое изменение или исправление ошибки во втором рецепте потребует усилий в несколько раз больше, чем выполнение того же задания в первом рецепте. Фактически, проблемы с именованием переменных настолько часты и серьёзны, что многие учебники по программной инженерии посвящают целую главу этому вопросу.
Ни математика, ни алгоритмика, ни статистика не выносят суждения о пригодности имен переменных. Пригодность этих имён, очевидно, определяется взглядом наблюдателя. Хотя у нас есть два числово идентичных рецепта, один из них считается значительно превосходящим другой по, на первый взгляд, субъективным причинам. Мое утверждение, которое я отстаиваю, состоит в том, что в этих субъективных аспектах также можно найти рациональность. Эти вопросы не следует откровенно отвергать только потому, что они зависят от субъекта или человека. Напротив, опыт Lokad свидетельствует о том, что при использовании одних и тех же программных инструментов, математических методов и библиотеки алгоритмов некоторые учёные по цепям поставок достигают лучших результатов. Фактически, личность ответственного учёного является одним из лучших предикторов успеха инициативы.
Предполагая, что врожденный талант не может полностью объяснить разницу в успехе в цепях поставок, мы должны учитывать те элементы, которые способствуют успешным инициативам, будь то объективные или субъективные. Именно поэтому в Lokad мы в течение последних десятилетий прилагали большие усилия для совершенствования нашего подхода к роли учёного по цепям поставок, что и является темой этой лекции. Нюансы, связанные с профессией учёного по цепям поставок, не следует недооценивать. Масштаб улучшений, достигаемых за счет этих субъективных элементов, сопоставим с нашими наиболее заметными технологическими достижениями.
Эта серия лекций предназначена в качестве учебного материала для учёных по цепям поставок Lokad. Однако я также надеюсь, что эти лекции могут представлять интерес для более широкой аудитории практиков цепей поставок или даже студентов. Лучше всего смотреть эти лекции последовательно, чтобы полностью понять, с чем сталкиваются учёные по цепям поставок.
В первой главе мы увидели, почему цепи поставок должны стать программными и почему крайне желательно иметь возможность запускать числовой рецепт в эксплуатацию. Постоянно растущая сложность цепей поставок делает автоматизацию более необходимой, чем когда-либо. Кроме того, существует финансовая необходимость в превращении практик управления цепями поставок в капиталистические.
Вторая глава посвящена методологиям. Цепи поставок представляют собой конкурентные системы, и такое сочетание сводит на нет наивные методологии. Роль учёных можно рассматривать как противоядие против наивного подхода прикладной математики.
Третья глава рассматривает проблемы, с которыми сталкиваются специалисты по цепям поставок. Эта глава пытается охарактеризовать классы проблем принятия решений, которые необходимо решить. Она показывает, что упрощённые подходы, такие как выбор правильного количества запасов для каждой SKU, не соответствуют реальным условиям; в принятии решений всегда присутствует глубина.
Четвёртая глава рассматривает элементы, необходимые для осознания современной практики управления цепями поставок, в которой программные компоненты повсеместны. Эти элементы являются фундаментальными для понимания более широкого контекста, в котором функционирует цифровая цепь поставок.
Пятая и шестая главы посвящены прогнозному моделированию и принятию решений соответственно. Эти главы охватывают «умные» части числового рецепта, включающие машинное обучение и математическую оптимизацию. Примечательно, что в этих главах собраны техники, которые зарекомендовали себя в руках учёных по цепям поставок.
Наконец, седьмая, и данная, глава посвящена реализации инициативы количественного управления цепями поставок. Мы увидели, что требуется для запуска инициативы при закладке правильных основ. Мы увидели, как пересечь финишную черту и запустить числовой рецепт в эксплуатацию.
Сегодня мы увидим, какого человека нужно, чтобы всё это произошло.
Роль учёного направлена на решение проблем, встречающихся в академической литературе. Мы рассмотрим работу учёного по управлению цепочками поставок, включая его миссию, сферу деятельности, ежедневный распорядок и интересующие аспекты. Это описание работы отражает современную практику в Lokad.
Новая позиция в компании вызывает ряд вопросов, поэтому учёных необходимо нанимать, обучать, оценивать и удерживать. Мы рассмотрим эти вопросы с точки зрения управления человеческими ресурсами. От учёного ожидается сотрудничество с другими отделами компании, помимо отдела цепочки поставок. Мы увидим, какие взаимодействия предполагаются между учёными и ИТ, финансами и даже руководством компании.
Учёный также представляет возможность для компании модернизировать персонал и операции. Эта модернизация является самой сложной частью пути, поскольку устранить устаревшую позицию гораздо труднее, чем ввести новую.
Задача, которую мы поставили перед собой в этой серии лекций, — систематическое улучшение цепочек поставок с помощью количественных методов. Суть этого подхода заключается в максимальном использовании возможностей современной вычислительной техники и программного обеспечения для цепочек поставок. Однако нам необходимо выяснить, что всё ещё относится к области человеческого интеллекта и что может быть успешно автоматизировано.
Граница между человеческим интеллектом и автоматизацией во многом зависит от технологий. Ожидается, что передовые технологии механизируют более широкий спектр решений и обеспечат лучшие результаты. С точки зрения цепочки поставок это означает принятие более разнообразных решений, таких как ценообразование наряду с решениями по пополнению запасов, а также выработку лучших решений, которые дополнительно повышают прибыльность компании.
Роль учёного воплощает ту грань, где встречаются человеческий интеллект и автоматизация. Хотя рутинные заявления об искусственном интеллекте могут создавать впечатление, что человеческий интеллект вот-вот будет автоматизирован, по моему пониманию современного состояния дел, общий искусственный интеллект остаётся далёким. Действительно, человеческие инсайты всё ещё крайне необходимы при разработке количественных методов, применимых к цепочкам поставок. Даже установление базовой стратегии для цепочки поставок остаётся во многом вне досягаемости возможностей программного обеспечения.
В более широком смысле, у нас пока нет технологий, способных решать плохо сформулированные или неопределённые задачи, которые являются обычным явлением в цепочках поставок. Однако, как только узкая, чётко определённая проблема будет выделена, можно ожидать, что автоматизированный процесс изучит её решение и даже полностью автоматизирует его с минимальным или отсутствующим участием человека.
Эта точка зрения не является новаторской. Например, фильтры против спама получили широкое распространение. Эти фильтры решают сложную задачу: отделяют важное от неважного. Однако разработка следующего поколения фильтров всё ещё в значительной степени остаётся за людьми, даже если новые данные могут использоваться для их обновления. Действительно, спамеры, пытающиеся обойти антиспам-фильтры, постоянно изобретают новые методы, которые нейтрализуют простые обновления, основанные на данных.
Таким образом, хотя человеческие инсайты всё ещё необходимы для создания автоматизации, неясно, почему поставщик программного обеспечения, такой как Lokad, например, не смог бы разработать грандиозный движок для цепочки поставок, способный решить все эти задачи. Безусловно, экономика программного обеспечения благоприятствует созданию подобного масштабного движка. Даже если первоначальные инвестиции велики, поскольку ПО может воспроизводиться практически бесплатно, поставщик заработает состояние на лицензионных сборах, перепродавая этот движок множеству компаний.
В 2008 году Lokad действительно начала путь создания грандиозного движка, который можно было бы развернуть как готовый программный продукт. Точнее, в то время Lokad сосредоточилась на создании масштабного прогнозного движка, а не движка для цепочки поставок. Однако, несмотря на относительно более скромные амбиции, поскольку прогнозирование составляет лишь малую часть общей задачи цепочки поставок, Lokad потерпела неудачу в создании такого масштабного прогнозного движка. Количественная перспектива оптимизации цепочки поставок, представленная в этой серии лекций, возникла из пепла этих грандиозных замыслов.
С точки зрения цепочки поставок оказалось, что существует три основных узких места, требующих решения. Мы увидим, почему этот грандиозный движок был обречён с первого дня и почему, скорее всего, мы ещё находимся десятилетиями от такого инженерного достижения.
«Приложный ландшафт» типичной цепочки поставок — это джунгли, которые выросли в хаотичном порядке за последние две-три декады. Этот ландшафт не похож на французский формальный сад с чёткими геометрическими линиями и аккуратно подстриженными кустами; это джунгли, одновременно яркие, но полные колючек и враждебной фауны. Более того, цепочки поставок являются продуктом своей цифровой истории. Может существовать несколько полуизбыточных «ERP-систем», незавершённых домашних кастомизаций, пакетных интеграций, особенно с системами, возникшими в результате поглощения компаний, и пересекающихся программных платформ, конкурирующих за одни и те же функциональные области.
Идея о том, что какой-то грандиозный движок можно просто подключить, является иллюзорной, если учесть текущее состояние технологий программного обеспечения. Объединение всех систем, функционирующих в цепочке поставок, представляет собой существенную задачу, полностью зависящую от человеческих инженерных усилий.
Анализ совокупных расходов показывает, что обработка данных составляет не менее трёх четвертей общих технических затрат, связанных с инициативой по оптимизации цепочки поставок. В то же время разработка интеллектуальных компонентов численной рецептуры, таких как прогнозирование и оптимизация, занимает не более нескольких процентов от общих усилий. Таким образом, наличие готового, масштабного движка в значительной степени не влияет на затраты или сроки. Для автоматической интеграции такого движка в зачастую хаотичный ИТ-ландшафт, характерный для цепочек поставок, потребовался бы встроенный интеллект на уровне человека.
Более того, наличие любого грандиозного движка ещё больше усложняет задачу. Вместо того чтобы иметь дело с одной сложной системой — приложным ландшафтом, — теперь у нас имеется две сложные системы: приложный ландшафт и грандиозный движок. Сложность интеграции этих систем определяется не их суммой, а произведением их сложностей.
Влияние этой сложности на инженерные затраты является крайне нелинейным, как уже отмечалось в первой главе этой серии лекций. Первое серьёзное узкое место в оптимизации цепочки поставок — это настройка численной рецептуры, требующая специализированных инженерных усилий. Это узкое место в значительной степени нивелирует те преимущества, которые можно было бы ожидать от любого готового масштабного движка для цепочки поставок.
Хотя настройка требует значительных инженерных усилий, это может быть разовой инвестицией, подобной оплате входного билета. К сожалению, цепочки поставок — живые организмы, постоянно развивающиеся. День, когда цепочка поставок перестанет меняться, станет днём банкротства компании. Изменения происходят как внутри компании, так и снаружи.
Внутри компании приложный ландшафт постоянно меняется. Компании не могут заморозить его, даже если захотят, так как многие обновления предписаны поставщиками корпоративного программного обеспечения. Игнорирование этих требований освободило бы поставщиков от их контрактных обязательств, что недопустимо. Помимо технических обновлений, любая значимая цепочка поставок неизбежно внедряет и выводит из эксплуатации программные решения по мере изменений в самой компании.
Вне компании рынки также постоянно меняются. Постоянно появляются новые конкуренты, каналы продаж и потенциальные поставщики, в то время как некоторые исчезают. Нормативные требования постоянно эволюционируют. Хотя алгоритмы могут автоматически фиксировать некоторые простые изменения, такие как рост спроса на определённую категорию товаров, у нас пока нет алгоритмов, способных справляться с изменениями рынка в их сущности, а не только по величине. Проблемы, которые пытается решить оптимизация цепочки поставок, сами по себе меняются.
Если программное обеспечение, ответственное за оптимизацию цепочки поставок, не справляется с этими изменениями, сотрудники возвращаются к таблицам. Таблицы могут быть примитивными, но, по крайней мере, сотрудники могут адаптировать их под конкретные задачи. По свидетельствам, подавляющее большинство цепочек поставок всё ещё используют таблицы для принятия решений, а не для транзакций. Это наглядное доказательство того, что сопровождение программного обеспечения потерпело неудачу.
С 1980-х годов поставщики корпоративного программного обеспечения выпускают продукты для автоматизации принятия решений в цепочках поставок. Большинство компаний, управляющих крупными цепочками поставок, уже внедрили несколько таких решений за последние десятилетия. Однако сотрудники неизменно возвращаются к своим таблицам, что доказывает: даже если настройка изначально считалась успешной, с сопровождением возникли проблемы.
Сопровождение — второе основное узкое место в оптимизации цепочки поставок. Численная рецептура требует активного сопровождения, даже если её выполнение может проходить без постоянного контроля.
На данном этапе мы доказали, что оптимизация цепочки поставок требует не только первоначальных ресурсов для разработки программного обеспечения, но и непрерывных инженерных ресурсов. Как уже отмечалось в этой серии лекций, только программные возможности могут реально справиться с разнообразием проблем, возникающих в реальных цепочках поставок. Таблицы действительно считаются программируемыми инструментами, и их выразительность, в отличие от кнопок и меню, делает их столь привлекательными для специалистов по цепочкам поставок.
Поскольку большинство компаний вынуждены обеспечивать наличие ресурсов для разработки ПО, естественно прибегнуть к помощи ИТ-отдела. К сожалению, цепочка поставок не является единственным отделом, придерживающимся такого подхода. Каждый отдел, включая продажи, маркетинг и финансы, в итоге осознаёт, что автоматизация их процессов принятия решений требует инженерных ресурсов. Более того, им также приходится иметь дело с транзакционным уровнем и всей сопутствующей инфраструктурой.
В результате, большинство компаний с крупными цепочками поставок сегодня имеют ИТ-отделы, заваленные задачами на многие годы вперёд. Таким образом, ожидание, что ИТ-отдел выделит дополнительные постоянные ресурсы для цепочки поставок, лишь усугубляет проблему. Вариант выделения дополнительных ресурсов для ИТ уже был исчерпан и, как правило, больше не является жизнеспособным. Эти компании уже сталкиваются с серьёзными проблемами неэффективного масштабирования в ИТ-отделе. Накопление задач в ИТ представляет собой третье большое узкое место в оптимизации цепочки поставок.
Постоянные инженерные ресурсы необходимы, но основная их часть не может поступать от ИТ. Некоторая поддержка от ИТ возможна, но она должна быть ограниченной.
Эти три основных узких места объясняют, почему необходима специализированная роль: учёный по цепочке поставок — это то название, которым мы обозначаем постоянные инженерные ресурсы, необходимые для автоматизации рутинных решений и сложных процессов принятия решений в цепочке поставок.
Перейдём к более точному определению на основе практики Lokad. Миссия учёного по цепочке поставок заключается в создании численных рецептур, которые ежедневно генерируют рутинные решения, необходимые для функционирования цепочки поставок. Работа учёного начинается с извлечения данных из баз, собранных по всему приложному ландшафту. От учёного ожидается написать код рецептуры, которая обрабатывает эти данные и выводит её в производство. Учёный несёт полную ответственность за качество решений, генерируемых рецептурой. Решения не генерируются какой-то окружающей системой; они являются прямым выражением инсайтов учёного, реализованных через рецептуру.
Этот аспект является принципиальным отличием от того, что обычно подразумевается под ролью data scientist. Однако миссия на этом не заканчивается. От учёного по цепочке поставок ожидается способность предоставить доказательства в поддержку каждого решения, сгенерированного рецептурой. Это не какая-то непрозрачная система, отвечающая за решения; это человек — учёный. Он должен уметь встретиться с руководителем цепочки поставок или даже с генеральным директором и убедительно обосновать любое принятое решение.
Если учёный не находится в положении, способном нанести компании значительный ущерб, значит, что-то не так. Я не призываю наделять кого-либо, и уж точно не учёного, огромными полномочиями без надзора или ответственности. Я лишь указываю на очевидное: если у вас нет возможностей негативно повлиять на компанию, независимо от того, как плохо вы работаете, то вы не сможете и положительно её повлиять, даже если будете работать безупречно.
Крупные компании, к сожалению, по природе своей избегают рисков. Поэтому очень заманчиво заменить учёного аналитиком. В отличие от учёного, непосредственно ответственного за решения, аналитик лишь помогает прояснить ситуацию. Аналитику, как правило, не наносят вред, и он не может сделать ничего, кроме как потратить своё время и некоторые вычислительные ресурсы. Однако безвредность не является сутью роли учёного по цепочке поставок.
Давайте на минуту обсудим термин «учёный по цепочке поставок». Эта терминология, к сожалению, несовершенна. Я впервые ввёл это выражение как вариацию «data scientist» около десяти лет назад, с идеей позиционировать эту роль как разновидность дата-сайентиста с сильной специализацией в области цепочек поставок. Мысли о специализации оказались верными, а вот мнение о data science — нет. Я вернусь к этому вопросу в конце лекции.
“Инженер по цепочке поставок” мог бы быть лучшей формулировкой, поскольку она подчёркивает стремление овладеть и контролировать область, а не просто понять её. Однако, как обычно понимается, от инженеров не ожидается, что они будут на передовой действий. Правильный термин, вероятно, был бы quant в области цепочки поставок, то есть количественный специалист по цепочке поставок.
В финансах кван или количественный трейдер — это специалист, который использует алгоритмы и количественные методы для принятия торговых решений. Кваны могут сделать банк чрезвычайно прибыльным или, наоборот, крайне убыточным. Человеческий интеллект усиливается посредством машин, как в положительном, так и в отрицательном смысле.
В любом случае, выбор правильной терминологии — аналитик, учёный, инженер, оперативник или quant — остаётся за широким сообществом. Ради согласованности, в остальной части этой лекции я буду использовать термин учёный.
Основной результат работы учёного — это программное обеспечение, точнее, числовой рецепт, отвечающий за генерацию ежедневных решений в цепочке поставок, представляющих интерес. Этот рецепт представляет собой сборник всех скриптов, участвующих от самых ранних этапов подготовки данных до финальных стадий корпоративной проверки самих решений. Этот рецепт должен соответствовать промышленным стандартам, то есть быть способным работать без присмотра, а генерируемые им решения по умолчанию вызывать доверие. Естественно, это доверие должно быть заслужено изначально, и постоянный контроль должен обеспечивать его сохранность с течением времени.
Доставка рецепта промышленного уровня имеет первостепенное значение, чтобы превратить практику цепочки поставок в продуктивный актив. Этот аспект уже обсуждался в предыдущей лекции, посвящённой поставке, ориентированной на продукт.
Помимо этого рецепта существует множество вторичных результатов. Некоторые из них также представляют собой программное обеспечение, даже если они не способствуют напрямую генерации решений. К ним относятся, например, все инструменты, которые учёный должен внедрить для создания и последующего обслуживания самого рецепта. Другие элементы предназначены для коллег внутри компании, включая всю документацию по самой инициативе и рецепту.
Исходный код рецепта отвечает на вопрос «как» — как это делается? Однако исходный код не отвечает на вопрос «почему» — почему это делается? «Почему» должно быть задокументировано. Часто корректность рецепта зависит от тонкого понимания намерения. Предоставленная документация должна максимально облегчать плавный переход от одного учёного к другому, даже если предыдущий учёный не готов поддерживать этот процесс.
В Lokad наш стандартный подход заключается в создании и поддержке обширного свода по инициативе, называемого Совместным Руководящим Руководством (JPM). Это руководство является не только полным операционным справочником по рецепту, но и сборником всех стратегических идей, лежащих в основе модельных выборов, сделанных учёными.
На техническом уровне работа учёного начинается с извлечения необработанных данных и заканчивается генерацией окончательных решений по цепочке поставок. Учёному приходится работать с данными, извлечёнными из существующих бизнес-систем в их сыром виде. Поскольку каждая бизнес-система, как правило, имеет собственный технологический стек, само извлечение обычно лучше поручить IT-специалистам. Нереально ожидать, что учёный освоит полдюжины диалектов SQL или API-технологий лишь для того, чтобы получить доступ к бизнес-данным. С другой стороны, от IT-специалистов не следует ожидать ничего, кроме предоставления сырых данных, ни преобразования, ни их подготовки. Данные, предоставленные учёному, должны максимально соответствовать тем, что представлены в бизнес-системах.
На противоположном конце конвейера рецепт, созданный учёным, должен генерировать окончательные решения. Элементы, связанные с развёртыванием решений, не входят в компетенцию учёного. Они важны, но во многом независимы от самого решения. Например, при рассмотрении заказов на покупку установление окончательных количеств входит в обязанности учёного, тогда как генерация PDF-файла — документа заказа, требуемого поставщиком, не входит. Несмотря на эти ограничения, объём работы достаточно велик. В результате возникает соблазн, хотя и ошибочный, дробить задачи на серию подпроектов. В крупных компаниях это искушение становится особенно сильным и должно быть отвергнуто. Дробление задач является самым надёжным способом создания многочисленных проблем.
Если на верхних уровнях кто-то пытается помочь учёным, предварительно обработав входные данные, такая попытка неизбежно приводит к эффекту «мусор на входе, мусор на выходе». Бизнес-системы и так достаточно сложны; предварительное преобразование данных лишь добавляет дополнительный случайный уровень сложности. На среднем звене, если кто-то пытается помочь учёным, взяв на себя сложную часть рецепта, например, прогнозирование, учёные сталкиваются с чёрным ящиком в середине собственного рецепта. Такой чёрный ящик подрывает усилия учёных по обеспечению прозрачности. А на нижнем звене, если кто-то пытается помочь учёному посредством дополнительной реоптимизации решений, эта попытка неизбежно создаёт путаницу, и логика двух уровней оптимизации может даже противоречить друг другу.
Это не означает, что учёный должен работать в одиночку. Может быть сформирована команда учёных, но объём задач остаётся прежним. Если создаётся команда, должно быть коллективное владение рецептом. Это означает, например, что если в рецепте обнаруживается дефект, любой член команды должен иметь возможность вмешаться и исправить его.
Опыт Lokad показывает, что оптимальное распределение обязанностей для учёного по цепочке поставок выглядит так: 40% времени на программирование, 30% на общение с остальными подразделениями компании и 30% на написание документов, учебных материалов и обмен опытом с коллегами, занимающимися цепочками поставок или являющимися учёными по цепочкам поставок.
Программирование, безусловно, необходимо для реализации самого рецепта. Однако как только рецепт переходит в стадию эксплуатации, большинство усилий по программированию направлены не на сам рецепт, а на его инструментальное сопровождение. Для улучшения рецепта учёному нужны дополнительные инсайты, а, в свою очередь, эти инсайты требуют внедрения специального инструментария.
Общение с остальной компанией имеет первостепенное значение. В отличие от S&OP, цель этих обсуждений не в том, чтобы завышать или занижать прогноз. Речь идёт о том, чтобы убедиться, что модельные выборы, заложенные в рецепте, по-прежнему точно отражают как стратегию компании, так и все её операционные ограничения.
Наконец, развитие институциональных знаний компании об оптимизации цепочки поставок — будь то через прямое обучение самих учёных или через подготовку документов для коллег — является критически важным. Эффективность рецепта во многом отражает компетентность учёного. Нет ничего удивительного в том, что общение с коллегами и получение обратной связи являются одними из самых эффективных способов повышения компетентности учёных.
Главное отличие учёного по цепочке поставок, каким его видит Lokad, от традиционного дата-сайентиста заключается в личной ответственности за достижение реальных результатов. Это может показаться незначительным, но опыт говорит обратное. Десятилетие назад Lokad на собственном опыте убедился, что приверженность созданию промышленного рецепта не является само собой разумеющейся. Напротив, стандартное отношение людей, обученных как дата-сайентисты, заключается в том, что эксплуатация рассматривается как второстепенный вопрос. Традиционный дата-сайентист ожидает управлять интеллектуальными элементами, такими как машинное обучение и математическая оптимизация, в то время как решение всех случайных проблем, возникающих в реальной цепочке поставок, слишком часто воспринимается как нечто ниже его уровня.
Тем не менее, приверженность созданию промышленного рецепта подразумевает работу с самыми случайными вопросами. Например, в июле 2021 года многие европейские страны столкнулись с катастрофическими наводнениями. Один из клиентов Lokad в Германии столкнулся с затоплением половины своих складов. Учёный по цепочке поставок, отвечавший за этот клиентский счёт, почти за одну ночь пришлось реорганизовать рецепт, чтобы максимально использовать эту крайне ухудшившуюся ситуацию. Исправление заключалось не в создании грандиозного алгоритма машинного обучения, а в наборе декодированных эвристических правил. И наоборот, если учёный по цепочке поставок не владеет решением, то он не сможет разработать промышленный рецепт. Это вопрос психологии. Доставка промышленного рецепта требует огромных умственных усилий, и ставки должны быть реальными, чтобы сотрудник смог полностью сосредоточиться на задаче.
Разъяснив обязанности учёного по цепочке поставок, давайте обсудим, как это выглядит с точки зрения управления персоналом. Во-первых, среди корпоративных вопросов учёный должен подчиняться руководителю цепочки поставок или, по крайней мере, тому, кто квалифицируется как руководитель высшего звена в области цепочки поставок. Не имеет значения, работает ли учёный внутри компании или является внешним специалистом, как это часто бывает в Lokad. Главное, чтобы учёный находился под непосредственным контролем того, кто обладает полномочиями исполнительного директора по цепочке поставок.
Одна из распространённых ошибок — поручить учёному подчиняться руководителю IT или руководителю аналитики данных. Поскольку создание рецепта является задачей программирования, руководство в области цепочки поставок может не чувствовать себя вполне комфортно при наблюдении за таким процессом. Однако это неверно. Учёный нуждается в надзоре со стороны того, кто может одобрить, что сгенерированные решения являются приемлемыми, или, по крайней мере, обеспечить такое одобрение. Размещение учёного где-либо, кроме прямого подчинения руководству по цепочке поставок, приводит к тому, что работа застревает на стадии прототипов и так и не переходит в эксплуатацию. В такой ситуации роль неизбежно сводится к аналитической, и первоначальные амбиции количественной инициативы в области цепочки поставок остаются нереализованными.
Лучшие учёные по цепочке поставок показывают результаты, значительно превосходящие средние показатели. Это опыт Lokad, который отражает закономерность, выявленную десятилетия назад в IT-индустрии. Компании, занимающиеся разработкой ПО, давно заметили, что лучшие программисты работают как минимум в 10 раз продуктивнее средних, а посредственные инженеры могут даже иметь отрицательную продуктивность, ухудшая качество кода с каждым часом работы.
В случае учёных по цепочке поставок превосходная компетентность не только повышает производительность, но, что более важно, улучшает конечную эффективность цепей поставок. Даже при использовании тех же программных средств и математических инструментов два учёных не достигают одинаковых результатов. Таким образом, наём человека с потенциалом стать одним из лучших учёных имеет первостепенное значение.
Опыт Lokad, основанный на найме более 50 учёных, показывает, что неспециализированные инженерные кадры зачастую оказываются весьма хорошими. Как бы ни было контринтуитивно, люди с формальным образованием в области data science, статистики или компьютерных наук обычно не являются лучшими кандидатами на позицию учёного по цепочке поставок. Такие специалисты слишком часто слишком усложняют рецепт и не уделяют достаточно внимания обыденным, но критически важным аспектам цепочки поставок. Способность обращать внимание на множество деталей и неутомимость в преследовании пограничных числовых аномалий являются ключевыми качествами лучших учёных.
По опыту Lokad, хорошие результаты часто демонстрируют молодые инженеры, которые провели несколько лет в аудите. Помимо знакомства с корпоративными финансами, талантливые аудиторы, похоже, развивают способность ориентироваться в океане корпоративной документации, что соответствует повседневной работе учёного по цепочке поставок.
Хотя правильный найм гарантирует, что у новых сотрудников есть потенциал, следующим шагом является обеспечение их должного обучения. Стандартная позиция Lokad заключается в том, что не ожидается, что люди заранее будут знать что-либо о цепочке поставок. Знание цепочки поставок — это плюс, но академическая подготовка в этой области оставляет желать лучшего. Большинство образовательных программ по цепочке поставок ориентированы на управление и лидерство, но для молодых выпускников крайне важно иметь прочные базовые знания по тем темам, которые освещаются во второй, третьей или четвёртой главах этой серии лекций. К сожалению, часто это не так, и количественные дисциплины в этих программах могут быть недостаточно развиты. В результате учёные по цепочке поставок должны обучаться непосредственно на рабочем месте. Эта серия лекций отражает тип учебных материалов, используемых в Lokad.
Оценка работы учёных по цепочке поставок важна по множеству причин, таких как обеспечение рационального расходования средств компании и определение повышений. Применяются стандартные критерии: отношение, трудолюбие, профессионализм и т.д. Однако здесь есть один парадоксальный аспект: лучшие учёные достигают таких результатов, что проблемы цепочки поставок становятся практически незаметными, сопровождаясь минимумом драматизма.
Обучение учёного поддержке существующих рецептов при сохранении прежнего уровня эффективности цепочки поставок занимает около шести месяцев, тогда как обучение созданию рецепта прогнозирования с нуля требует порядка двух лет. Сохранение талантов является критически важным, особенно учитывая, что наём опытных учёных по цепочке поставок пока не является возможным.
Во многих странах средний срок работы инженеров моложе 30 лет в области программного обеспечения и смежных областях довольно невысок. Lokad достигает более высокого среднего срока за счёт заботы о благополучии сотрудников. Компании не могут дарить счастье своим сотрудникам, но они могут избежать ситуации, когда сотрудники становятся несчастными из-за бессмысленных процессов. Сохранение здравомыслия имеет огромное значение для удержания персонала.
Компетентного и опытного ученого по цепочкам поставок нельзя ожидать, что он быстро возьмется за существующий рецепт, поскольку рецепт отражает уникальную стратегию компании и особенности цепочек поставок. Переход от одной цепочки к другой может занять около месяца при лучших условиях. Не разумно, чтобы крупная компания зависела от одного ученого; Lokad гарантирует, что два ученых владеют любым рецептом, используемым в производстве, в любой момент. Последовательность крайне важна, и одним из способов её обеспечения является совместное создание руководства с клиентами, что может способствовать незапланированным переходам между учёными.
Роль ученого по цепочкам поставок требует необычного уровня сотрудничества с несколькими отделами, особенно с ИТ. Правильное выполнение рецепта зависит от системы извлечения данных, за которую отвечает ИТ.
В начале первой количественной инициативы в сфере цепочек поставок происходит относительно интенсивное взаимодействие между ИТ и ученым, которое длится примерно два-три месяца. Затем, как только система извлечения данных налажена, взаимодействие становится менее частым. Этот диалог гарантирует, что ученый осведомлен о плане развития ИТ и о любых обновлениях или изменениях программного обеспечения, которые могут повлиять на цепочку поставок.
На начальном этапе количественной инициативы по цепочкам поставок происходит относительно интенсивное взаимодействие между ИТ и учёными. В течение первых двух-трёх месяцев ученому приходится общаться с ИТ несколько раз в неделю. Затем, как только система извлечения данных внедрена, взаимодействие становится гораздо менее частым — примерно раз в месяц или реже. Помимо устранения случайных сбоев в системе, этот диалог гарантирует, что ученый в курсе плана развития ИТ. Любое обновление или замена программного обеспечения может требовать от учёного работы, занимающей дни или даже недели. Чтобы избежать простоев, рецепт необходимо модифицировать с учётом изменений в прикладном ландшафте.
Рецепт, реализованный учёным, оптимизирует возврат в долларах или евро. Мы обсуждали этот аспект в самых первых лекциях данной серии. Однако от учёного не следует ожидать, что он будет решать, как моделировать затраты и прибыль. Хотя он должен предлагать модели, отражающие экономические драйверы, окончательное решение о корректности этих драйверов остаётся за финансовым отделом. Многие практики в цепочках поставок обходят проблему, сосредотачиваясь на процентах, таких как уровни сервиса и точность прогнозирования. Однако эти проценты почти не коррелируют с финансовым состоянием компании. Таким образом, учёный должен регулярно взаимодействовать с финансовым отделом и подвергать сомнению выбор моделей и предположения, заложенные в числовом рецепте.
Выборы в финансовом моделировании являются временными, так как они отражают меняющуюся стратегию компании. От учёного также ожидается разработка инструментов, связанных с рецептом для финансового отдела, таких как максимальная прогнозируемая сумма оборотного капитала, связанного с запасами на предстоящий год. Для средних и крупных компаний разумно проводить ежеквартальный обзор работы, выполненной учёным по цепочкам поставок, с участием финансового руководителя.
Одна из самых больших угроз для достоверности рецепта — случайное извращение стратегических намерений компании. Слишком многие практики в цепочках поставок обходят стратегию, прячась за процентами, используемыми в качестве показателей индикаторов. Завышение или занижение прогноза посредством планирования продаж и операций (S&OP) не заменяет четкого определения стратегических намерений. Учёный не отвечает за стратегию компании, но рецепт окажется некорректным, если он её не понимает. Соответствие рецепта стратегии должно быть специально продумано.
Самый прямой способ проверить, понимает ли учёный стратегию, — попросить его вновь объяснить её руководству. Это позволяет легче выявить недопонимания. Теоретически, это понимание уже задокументировано учёным в руководстве по инициативе. Однако опыт показывает, что у руководителей редко бывает время подробно изучать оперативную документацию. Простая беседа ускоряет процесс для обеих сторон.
Эта встреча не предназначена для того, чтобы учёный объяснял всё о моделях цепочек поставок или финансовых результатах. Единственная цель — обеспечить правильное понимание человеком, владеющим цифровой ручкой. Даже в крупной компании разумно, чтобы учёный встречался с генеральным директором или другим ответственным руководителем хотя бы раз в год. Преимущества рецепта, более согласованного с намерениями руководства, огромны и зачастую недооцениваются.
Улучшения в цепочках поставок являются частью непрерывной цифровой модернизации. Это требует определённой реорганизации самой компании. Хотя изменения могут быть не кардинальными, искоренение устаревших практик является непростой задачей. При правильном выполнении продуктивность учёного по цепям поставок значительно выше, чем у традиционного планировщика. Ничего необычного, что один учёный отвечает за запасы на сумму более полувиллиарда долларов или евро.
Возможно резкое сокращение численности сотрудников в цепочках поставок. Некоторые клиентские компании Lokad, которые исторически находились под огромным конкурентным давлением, применили этот подход и выжили частично благодаря полученным сбережениям. Однако большинство наших клиентов выбирают более постепенное сокращение штата, поскольку планировщики естественным образом переходят на другие должности.
Оставшиеся планировщики перенаправляют свои усилия на работу с клиентами и поставщиками. Собранная ими обратная связь оказывается чрезвычайно полезной для учёных по цепочкам поставок. Действительно, работа учёного по своей природе ориентирована внутрь компании. Они работают с данными компании, и порой трудно понять, чего просто нет.
Многие представители бизнеса уже давно призывают к укреплению связей как с клиентами, так и с поставщиками. Однако это легче сказать, чем сделать, особенно если усилия постоянно нейтрализуются из-за решения текущих проблем, успокоения клиентов и давления на поставщиков. Учёные по цепочкам поставок могут обеспечить столь необходимое облегчение в обоих направлениях.
S&OP (Планирование продаж и операций) — это широко распространённая практика, предназначенная для обеспечения согласованности в компании посредством общего прогноза спроса. Однако, независимо от первоначальных амбиций, процессы S&OP, которые мне приходилось наблюдать, лучше всего характеризуются бесконечной чередой непродуктивных встреч. За исключением внедрения ERP-систем и соблюдения нормативных требований, я не могу вспомнить ни одну корпоративную практику, которая бы опустошала душу так, как S&OP. Советский Союз мог раствориться, но дух Госплана живёт через S&OP.
Глубокая критика S&OP заслужила бы отдельную лекцию. Однако, для краткости, я просто скажу, что учёный по цепочкам поставок является превосходной альтернативой S&OP по всем существенным параметрам. В отличие от S&OP, учёный по цепям поставок основывается на реальных решениях. Единственное, что мешает учёному стать ещё одним звеном раздутой корпоративной бюрократии, — это не его характер или компетентность, а его участие в реальных решениях.
Планировщики, менеджеры по запасам и производственные менеджеры часто являются активными пользователями разнообразных бизнес-отчётов. Эти отчёты обычно создаются корпоративными программными продуктами, которые принято называть инструментами бизнес-аналитики. Обычная практика в цепочках поставок состоит в экспорте серии отчётов в электронные таблицы с последующим использованием набора формул для их полуавтоматического объединения с целью формирования необходимых решений. Однако, как мы увидели, рецепт учёного заменяет эту комбинацию бизнес-аналитики и электронных таблиц.
Кроме того, ни бизнес-аналитика, ни электронные таблицы не подходят для поддержки реализации рецепта. Бизнес-аналитика лишена выразительности, поскольку соответствующие расчёты невозможно выразить средствами этих инструментов. Электронные таблицы страдают от недостаточной поддерживаемости и иногда масштабируемости, но прежде всего – от поддерживаемости. Конструкция электронных таблиц во многом несовместима с принципом корректности по замыслу, что крайне необходимо для нужд цепочек поставок.
На практике оснащение рецепта, реализованного учёным, действительно включает множество бизнес-отчётов. Эти отчёты заменяют те, что ранее генерировались с помощью бизнес-аналитики. Эта эволюция не обязательно означает конец эпохи бизнес-аналитики, поскольку другие отделы всё ещё могут извлечь пользу из этого класса инструментов. Однако, что касается цепочек поставок, введение учёного по цепям поставок знаменует конец эпохи бизнес-аналитики.
Если отложить в сторону несколько технологических гигантов, которые могут позволить себе задействовать сотни, а то и тысячи инженеров для решения каждой программной задачи, типичные результаты работы команд data science в обычных компаниях оказываются плачевными. Обычно эти команды не добиваются ничего существенного. Однако data science как корпоративная практика является лишь последней итерацией серии модных корпоративных трендов.
В 1970-х операционные исследования были в моде. В 1980-х популярными были системы правил и эксперты по знаниям. На рубеже веков активно искали специалистов по data mining. Начиная с 2010-х, data science и специалисты в этой области считаются следующим большим трендом. Все эти корпоративные тенденции следуют одной схеме: появляется настоящая инновация в программном обеспечении, люди чрезмерно воодушевляются ею и решают насильно внедрить её в компанию посредством создания нового специализированного отдела. Это происходит потому, что всегда гораздо проще добавить подразделение, чем изменить или удалить уже существующее.
Однако data science как корпоративная практика терпит неудачу, поскольку не укореняется в реальных действиях. Это принципиально отличает учёного по цепям поставок, который с первого дня берёт на себя ответственность за принятие реальных решений, от ИТ-отдела.
Если отложить в сторону эго и феодальные владения, учёный по цепям поставок представляет гораздо более выгодное предложение, чем прежний статус-кво. Типичный ИТ-отдел завален годами невыполненных задач, и требование дополнительных ресурсов не является разумным, так как это лишь повышает ожидания других отделов и ещё больше усугубляет ситуацию.
Напротив, учёный по цепям поставок способствует снижению ожиданий. Он ожидает лишь предоставления необработанных данных, а их анализ остаётся его задачей. Он не требует ничего от ИТ-отдела в этом отношении. Учёного по цепям поставок не следует воспринимать как санкционированную корпорацией версию теневого ИТ. Речь идёт о том, чтобы отдел цепочек поставок взял на себя ответственность за свою основную компетенцию. ИТ-отдел управляет низкоуровневой инфраструктурой и транзакционным слоем, в то время как уровень принятия решений в цепях поставок должен полностью находиться в ведении отдела цепочек поставок.
ИТ-отдел должен быть посредником, а не лицом, принимающим решения, за исключением действительно ИТ-ориентированных частей бизнеса. Многие ИТ-отделы осознают свой накопленный список задач и поддерживают этот новый подход. Однако если инстинкт защиты того, что они воспринимают как свою территорию, слишком силён, они могут отказаться от передачи уровня принятия решений в цепях поставок. Такие ситуации болезненны и могут быть разрешены только посредством прямого вмешательства генерального директора.
С некоторого расстояния наш вывод может быть таков, что роль учёного по цепям поставок представляет собой более специализированный вариант data scientist. Изначально именно так Lokad пытался решить проблемы, связанные с корпоративной практикой data science. Однако мы поняли уже десять лет назад, что этого недостаточно. Понадобилось несколько лет, чтобы постепенно выявить все элементы, представленные сегодня.
Учёный по цепям поставок не является дополнением к цепочке компании; это разъяснение ответственности за рутинные ежедневные решения в цепочке поставок. Чтобы максимально эффективно использовать этот подход, цепочка поставок, или по крайней мере её планировочная составляющая, должна быть перестроена. Соседние отделы, такие как финансы и операции, также должны адаптироваться к изменениям, пусть и в меньшей степени.
Формирование команды учёных по цепям поставок требует значительных усилий от компании, но при правильном подходе продуктивность оказывается высокой. На практике каждый учёный заменяет от 10 до 100 планировщиков, прогнозистов или менеджеров по запасам, что приводит к огромной экономии на зарплатах, даже если учёные получают более высокую оплату. Учёный по цепям поставок демонстрирует новый подход к работе с ИТ, переориентируя его как средство обеспечения, а не как поставщика решений, устраняя многие, если не большинство, ИТ-узких мест.
В более широком смысле этот подход может быть применён и в остальных не-ИТ отделах компании, таких как маркетинг, продажи и финансы. Каждый отдел сталкивается с рутинными ежедневными решениями, от которых он также мог бы значительно выиграть благодаря автоматизации. Однако, как и учёный по цепям поставок прежде всего является экспертом в области цепочек поставок,
Однако, так же как учёный по цепям поставок прежде всего является экспертом в области цепочек поставок, маркетинговый учёный или маркетинговый аналитик должен быть прежде всего экспертом в маркетинге. Перспектива учёного прокладывает путь к максимально эффективному сочетанию машинного и человеческого интеллекта в начале XXI века.
Следующая лекция состоится 10 мая, в среду, в то же время, в 15:00 по парижскому времени. Сегодняшняя лекция была не технической, но следующая будет в значительной мере технической. Я представлю методы оптимизации ценообразования. В традиционных учебниках по цепям поставок цены обычно не рассматриваются как элемент цепочки; однако, ценообразование существенно влияет на баланс спроса и предложения. Кроме того, ценообразование часто является областью с высокой степенью специфичности, так как слишком просто неверно подойти к решению задачи, если думать в абстрактных терминах. Таким образом, мы сузим наше исследование до вторичного автомобильного рынка. Это будет возможностью вернуться к элементам, представленным в Стутгарте, одной из персон, которую я представил в третьей главе этой серии лекций.
А теперь я продолжу с вопросами.
Вопрос: Академическому сообществу потребовалось почти десятилетие, чтобы понять, что область data science появилась и что её следует преподавать в старших классах. Видите ли вы уже аналогичные изменения в академических кругах по цепям поставок с принятием науки о цепях поставок?
Во-первых, я не знаю, чтобы data science преподавалась в старших классах во Франции. Им почти не преподают ничего, связанного с компьютерами в средней школе, не говоря уже о data science. Мне не очень понятно, где они вообще найдут профессоров или учителей, чтобы это делать. Но я понимаю, что вы хотите, чтобы ученики средней школы обладали цифровой грамотностью. По моему опыту, знакомство с программированием — это очень хорошо, и начать можно даже раньше, начиная с семи или восьми лет, в зависимости от зрелости ребенка. Это можно делать даже в начальной школе, но речь идет только об основных понятиях программирования: переменных, последовательностях инструкций и тому подобном. Я считаю, что data science значительно выходит за рамки того, что следует преподавать в средней школе, если только у вас нет вундеркиндов или чего-то подобного. Для меня это однозначно область, предназначенная для университетского уровня, будь то бакалавриат или последипломное образование.
Действительно, академическому сообществу понадобилось десятилетие, чтобы продвинуть data science, но давайте остановимся на мгновение. Я описывал data science как корпоративную практику, что является своего рода зеркальным отображением того, как академия преподаёт data science. Таким образом, нужно подумать о проблеме, и, на мой взгляд, одна из проблем в том, что невероятно сложно преподавать то, чем сам не занимаешься. По крайней мере, на университетском уровне, если не меньше. Что я наблюдаю, так это то, что проблема уже существует: те, кто преподают data science, не являются теми, кто действительно занимается data science в значимых компаниях, таких как Microsoft, Google, Facebook, OpenAI и тому подобное.
Что касается цепей поставок, у нас аналогичная проблема, и доступ к людям с необходимым опытом просто невероятно сложен. Я надеюсь, и это мой нескромный рекламный ход, что в ближайшие недели Lokad начнет предоставлять материалы, предназначенные для учебных программ по цепям поставок. Мы начнем продвигать материалы, оформленные таким образом, чтобы они были пригодны для преподавателей, чтобы они могли использовать эти идеи. Очевидно, им придется самостоятельно оценить, действительно ли материалы, предлагаемые Lokad, стоят того, чтобы их преподавать студентам.
Вопрос: Не используется ли специализированный язык Lokad где-либо ещё? Помимо Lokad, как вы мотивируете потенциальных новых сотрудников изучать то, что, скорее всего, им больше никогда не понадобится на следующей работе?
Именно в этом я и видел проблему с data scientists. Люди буквально подавали заявки с фразами: «Я хочу работать с TensorFlow, я человек TensorFlow» или «Я человек PyTorch». Это не правильное отношение. Если вы отождествляете свою личность с набором технических инструментов, вы упускаете суть. Задача заключается в понимании проблем цепей поставок и в их количественном решении для принятия производственных решений.
В этой лекции я упоминал, что ученому по цепям поставок требуется шесть месяцев, чтобы освоить поддержку рецепта, и два года, чтобы разработать рецепт с нуля. Сколько времени требуется, чтобы полностью освоить Envision, наш запатентованный язык программирования? По нашему опыту, это занимает три недели. Envision — мелкая деталь по сравнению с общей задачей, но она важна. Если ваши инструменты слабы, вы столкнетесь с огромными непредвиденными проблемами. Однако, давайте будем реалистами: это всего лишь небольшая часть общей головоломки.
Люди, работающие в Lokad, значительно расширяют свои знания о проблемах цепей поставок. Язык программирования можно переписать на других языках, но, возможно, это потребует большего количества строк кода. То, что особенно молодые инженеры часто не осознают, так это то, насколько многие технологии временные. Они не служат долго, обычно всего пару лет, прежде чем их заменяют чем-то новым.
Мы стали свидетелями бесконечной смены технологий. Если кандидат говорит: «Меня действительно интересуют технические детали», вероятно, он не является подходящим кандидатом. Вот в чем была моя проблема с data scientists – они стремились к модным, передовым решениям. Цепи поставок — чрезвычайно сложные системы, и когда ошибка имеет место, она может обойтись в миллионы. Вам нужны инструменты производственного уровня, а не последние, не испытанные пакеты.
Лучшие кандидаты искренне стремятся стать профессионалами в области цепей поставок. Главное — это сами цепи поставок, а не детали языка программирования.
Вопрос: Я получаю степень бакалавра в области управления цепями поставок, транспорта и логистики. Как я могу стать ученым в сфере цепей поставок?
Во-первых, я призываю вас подать заявку в Lokad. У нас постоянно открыты вакансии. Но если говорить серьёзно, ключ к тому, чтобы стать ученым в области цепей поставок, заключается в получении возможности работать в компании, которая готова автоматизировать свои решения в цепях поставок. Самое важное — это ответственность за принятые решения. Если вы найдете компанию, готовую дать этому шанс, это значительно поможет вам стать ученым.
Когда вы столкнетесь с проблемами принятия производственных решений, вы осознаете важность тем, которые я обсуждаю в этой серии лекций. Когда вы будете иметь дело с прогнозами, от которых зависят запасы на миллионы долларов, заказы и перемещения товаров, вы поймете огромную ответственность и необходимость правильного проектирования с самого начала. Я почти уверен, что другие компании будут расти и получать еще больше возможностей. Но даже в моих смелых мечтах я не думаю, что каждая компания на Земле будет использовать Lokad. Всегда найдется множество компаний, которые выберут свой путь, и с этим всё будет в порядке.
Вопрос: Так как 40% рабочего дня ученого в области цепей поставок посвящено программированию, какой язык программирования вы посоветуете изучать в первую очередь студентам бакалавриата, особенно тем, кто изучает управление?
Я бы сказал, что стоит выбрать тот язык, который легко доступен. Python — хороший вариант. Мой совет — попробовать несколько языков программирования. Ожидания от инженера по цепям поставок практически противоположны ожиданиям от разработчиков программного обеспечения. Для разработчиков мой стандартный совет — выбрать один язык и углубиться в него, тщательно изучив все его нюансы. Но для людей, являющихся универсалами, я бы сказал, что следует действовать наоборот. Попробуйте немного SQL, немного Python, немного R. Обратите внимание на синтаксис Excel и, возможно, ознакомьтесь с такими языками, как Rust, просто чтобы понять, как они выглядят. Так что выбирайте то, что под рукой. Кстати, Lokad планирует сделать Envision свободно доступным для студентов, так что следите за новостями.
Вопрос: Считаете ли вы, что графовые базы данных окажут значительное влияние на прогнозы в цепях поставок?
Абсолютно нет. Графовые базы данных существуют более двух десятилетий, и хотя они интересны, они не так мощны, как реляционные базы данных, такие как PostgreSQL и MariaDB. Для прогнозов в цепях поставок наличие графоподобных операторов не является решающим. В соревнованиях по прогнозированию ни один из топ-100 участников не использовал графовую базу данных. Однако существуют задачи, которые можно решить с помощью глубокого обучения, применяемого к графам, что я продемонстрирую в следующей лекции о ценообразовании.
Что касается вопроса о том, должны ли ученые по цепям поставок участвовать в определении целей в проектах клиентского data science, я считаю, что корень проблемы в исходном предположении, что сначала следует заниматься data science, прежде чем понять проблему, которую мы пытаемся решить. Однако, если переформулировать вопрос, должны ли ученые по цепям поставок участвовать в определении целей оптимизации цепей поставок? Да, безусловно. Когда ученый пытается выяснить, чего мы действительно хотим, это является сложной задачей, требующей тесного сотрудничества со стейкхолдерами для постановки правильных целей. Так что, должны ли ученые участвовать? Абсолютно, это критически важно.
Однако давайте уточним, что это не инициатива в области data science; это инициатива, связанная с цепями поставок, которая использует данные как один из компонентов. Мы действительно должны начинать с проблем и амбиций в цепях поставок, а затем, поскольку мы стремимся максимально использовать современное программное обеспечение, нам необходимы эти ученые. Они помогут значительно прояснить ваше понимание проблемы, ведь грань между тем, что реализуемо в программном обеспечении, и тем, что остается исключительно прерогативой человеческого интеллекта, весьма размыта. Вам нужны ученые, чтобы ориентироваться в этой неопределенности.
Надеюсь увидеть вас через два месяца, 10 мая, на следующей лекции, где мы обсудим ценообразование. До встречи.
