00:22 Введение
02:40 Почему продукт? Потому что капитализм
08:18 Что должен делать продукт?
10:05 Программные дезэкономии масштаба
12:50 Давайте купим готовый продукт SCO
21:58 SCM против SCO
25:58 Интерлюдия
28:21 SCO - не обычное программное обеспечение
33:26 Программные компоненты для SCO
42:49 Однако электронные таблицы - не конечная цель
46:51 Python тоже не является конечной целью
58:52 Цепь поставок - не отдел IT
01:03:19 В заключение, две преодолеваемые проблемы
01:07:04 Предстоящая лекция и вопросы аудитории
Описание
Целью квантитативной инициативы в области цепи поставок является либо доставка, либо улучшение программного приложения, автоматизирующего ряд рутинных решений (например, пополнение запасов, обновление цен). Приложение рассматривается как продукт, который должен быть разработан. Теория цепи поставок помогает нам доставить приложение, которое направляет компанию на достижение эффективности цепи поставок, соблюдая все ограничения, связанные с производством.
Полный текст
Привет всем, большое спасибо за участие в этой серии лекций по цепи поставок. Я - Жоанн Верморель, и я буду представлять “Продуктно-ориентированную доставку для оптимизации цепи поставок”.
Итак, сначала, когда я говорю о продукте, я имею в виду программный продукт. Для тех из вас, кто когда-либо имел привилегию изучать, что находится под капотом современного предприятия программного обеспечения, это может быть довольно интересным опытом.
Для тех, кто знаком с творчеством Г.П. Лавкрафта, есть некоторые тревожные сходства. Лавкрафт создал серию романов, и одной из повторяющихся тем является идея запретного знания. Не то чтобы вселенная не могла быть известна, она может. Просто единственное, что сохраняет человечество, - это невежество. Невежество - не проблема; это самая вещь, которая защищает нас от вселенной, слишком ужасной для наших умов. Эта идея была использована во многих современных играх, особенно в ролевых играх, где, помимо традиционных очков здоровья, у персонажей есть очки рассудка. Если вы делаете определенные вещи, которые наносят вред вашему рассудку, вы теряете очки рассудка. Проблема с предприятий программным обеспечением заключается в том, чтобы создавать его, сохраняя свой рассудок, что является одним из требований для добавления ценности компании. Итак, продолжим.
Почему продукт, а именно программный продукт? Давайте внимательно рассмотрим, как традиционно функционируют цепочки поставок. Традиционно, на месте было много людей, перемещающих вещи, перетаскивающих пакеты, управляющих транспортными средствами и выполняющих всю ручную работу. Также было много людей, занятых в производстве и в магазинах. Что происходит постепенно на протяжении последних нескольких десятилетий, так это то, что количество людей с рабочими профессиями постоянно сокращается. В настоящее время, с точки зрения производства, вещи в значительной степени автоматизированы. Есть всё ещё несколько отраслей, таких как текстильная промышленность, где сложно автоматизировать всё, поэтому эти отрасли переехали туда, где рабочая сила самая дешевая. Реальность заключается в том, что требования к ручному труду были существенно снижены.
Вы оказываетесь в довольно странной ситуации, когда, глядя вперед на фоне автономных транспортных средств, у многих компаний будет больше работников-офисных работников, занимающихся таблицами Excel spreadsheets для управления цепочкой поставок, чем людей с рабочими профессиями, выполняющих ручные операции. Это то, о чем я говорю, когда говорю о клерикальной работе.
Еще одной особенностью является то, что цепочки поставок были цифровизированы для многих компаний уже как минимум два десятилетия. Не так, будто мы собираемся внедрять программное обеспечение в цепочки поставок; цепочки поставок уже управляются и функционируют с помощью программного обеспечения. Но когда мы смотрим на роль людей в этих программных системах, люди буквально используются в качестве человеческих сопроцессоров в средней цепочке поставок. Есть определенные типы операций, которые обычный ЦП, процессор в машине, не может выполнить, и поэтому весь процесс делегируется человеку. В сочетании с упрощенными числовыми методами, такими как ABC анализ, инвентаризация мин-макс и подобными методами, люди постоянно занимаются тушением пожаров. Они всегда имеют дело с исключениями и условиями, которые не соответствуют стандартной структуре.
С точки зрения затрат, все это является операционными расходами (OpEx). Вам приходится платить армии клерков каждый день, чтобы справляться со всеми рутинными решениями, которые ваша компания должна принимать ежедневно. Сюда входят вопросы о том, что покупать, где размещать запасы, перемещать ли одну единицу из одного склада в магазин и многие другие рутинные решения. Эти решения принимаются людьми, которые пытаются справиться с недостатками автоматических решений, генерируемых наивно системой.
Моя предложение для вас сегодня заключается в том, что мы хотим перейти от операционных расходов к капитальным затратам (CapEx). В этом и заключается суть продуктовой доставки. Мы хотим создать актив, и почему? Потому что это капиталистически. Если посмотреть на топ-100 самых прибыльных компаний в мире сегодня, то половина из них, с точки зрения прибыли, являются компаниями-разработчиками программного обеспечения. Они представляют собой сущность ультра-капиталистических компаний, где вы вкладываете средства в начале, а затем получаете устройство или артефакт, который генерирует добавленную стоимость с минимальными дополнительными инвестициями.
Вернемся к теме моей предыдущей лекции. Нам нужна роботизация, чтобы вернуть управление в руки менеджеров. Автоматизация и люди должны работать вместе; люди не должны заниматься недостатками глупых политик управления запасами, таких как мин-макс. Вместо этого они должны добавлять стоимость, улучшать числовые алгоритмы и действовать как стратеги. Раньше у IBM был девиз: “Машины должны работать, люди должны думать”. Именно такое мышление лежит в основе этой презентации. Мы хотим превратить цепочку поставок в капиталистический актив, и для этого нам нужно превратить цепочку поставок в машину, которая создает программный продукт.
Что на самом деле делает этот продукт? Оказывается, он делает что-то довольно простое: он принимает решения. Не произвольные, открытые решения, а рутинные, повседневные решения, такие как что производить, сколько единиц покупать у поставщика и сколько единиц перемещать из одного места в другое. С первого взгляда может показаться, что в управлении цепочкой поставок вовлечено множество решений. Однако, когда вы изучаете задачи, даже самые сложные цепочки поставок требуют всего нескольких десятков типов решений, которые необходимо принимать каждый день. Это не превышает разумных пределов по количеству функций. Интересно, что эти решения в значительной степени являются исключительными, поэтому есть ограничения на то, что можно сделать с помощью подхода “разделяй и властвуй”. Когда вы решили закупить 100 единиц у поставщика, другая подсистема не может решить закупить 200 единиц вместо этого. В какой-то момент вам придется определиться, сколько единиц покупать и перемещать из одного места в другое. Эти решения являются дискретными, ограниченными по объему и в значительной степени исключительными. Мы хотим иметь программное обеспечение, которое каждый день полностью автоматически принимает решения о заказе.
Одна вещь, которую я считаю часто плохо понимаемой в отношении программного обеспечения, это понятие дезэкономии масштаба. В то время как экономии масштаба знакомы большинству людей, в программном обеспечении ситуация обратная: добавление четверти новых функций может удвоить стоимость. Это объясняет, почему маленькие стартапы могут конкурировать с крупными компаниями - потому что они сосредотачиваются на меньшей доле функций, стоимость вывода их продукта на рынок может быть значительно меньше, чем у крупной компании.
Имея в виду понятие дезэкономии масштаба, нам нужно решить, строить ли, покупать или выбрать другой подход для нашего продукта по оптимизации цепочки поставок. Если мы решим купить продукт у поставщика, мы должны учесть функции, которые поставщик программного обеспечения должен предоставить для обслуживания рынка.
Итак, давайте рассмотрим возможность покупки готового продукта по оптимизации цепочки поставок. На этих слайдах я предоставляю обзор всего лишь крошечной части того, с чем нам нужно иметь дело. У меня есть личный опыт в этом вопросе, так как когда я основал Lokad в 2008 году, я начал с небольшого программного продукта, ориентированного скорее на прогнозирование, чем на оптимизацию цепочки поставок. Когда я начал работать с клиентами, я понял, что у меня не хватает так многих функций и возможностей, и по мере того, как я продвигался к другим клиентам, я обнаруживал еще больше недостающих возможностей. Казалось, что это бесконечный процесс обнаружения новых требований.
Давайте рассмотрим основные функции. Во-первых, у нас есть компании, которые являются B2C или B2B и которые проявляют совершенно разные модели управления цепями поставок. Например, у компаний B2B обычно меньше клиентов, но эти клиенты заказывают гораздо большие объемы. Это создает разные типы рисков, такие как риск потери одного клиента, который составляет значительную часть оборота компании. Затем есть более сложные бизнес-модели, такие как B2B2C или B2B2B.
Рассмотрим различные типы объектов, которые нужно охватить, такие как магазины, склады и производственные объекты. Каждый тип объекта имеет свои собственные проблемы. Например, магазины часто страдают от неточности инвентаризации, даже при использовании технологии RFID, просто потому, что покупатели могут перемещать товары. Склады и производственные объекты, такие как фермы или горнодобывающие предприятия, имеют свои собственные проблемы и неопределенности в производственном выходе.
Сети цепей поставок могут иметь разные уровни, или этажи, от одноэтажных до многоэтажных систем. Сложность управления цепью поставок значительно возрастает с увеличением числа этажей. Еще одним важным аспектом является топология сети. Древовидная топология - это классический путь прямой цепи поставок, где несколько производственных объектов отправляют товары в несколько складов, которые в свою очередь распределяют их во множество магазинов. Однако могут существовать и другие топологии, такие как направленные ациклические графы (DAG), где один магазин может обслуживаться несколькими складами.
Таким образом, это не просто дерево в терминах графов, оно может быть переподключено, хотя все еще только вперед. Но то же самое может произойти с помощью направленного ациклического графа (DAG), когда у вас есть несколько поставщиков. В вашей цепи поставок могут даже быть петли, которые возникают, когда требуется ремонт. Например, в горнодобывающей промышленности или в авиационной отрасли существует множество петель с ремонтопригодным оборудованием.
Теперь сам инвентарь не имеет одной единой природы; он очень разнообразен. Нельзя просто сказать: “О, у меня есть идея, что у меня есть SKU и это все”. Нет, не совсем так, потому что сначала у вас есть сырье, которое измеряется буквально в количествах, таких как граммы, килограммы или объем. Затем у вас есть единицы, которые являются хорошими, чистыми единицами, которые преобладают. Но затем у вас также может быть много инвентаря, который происходит очень часто, например, в фармацевтической или пищевой отрасли, где партия поставляется с определенными сроками годности. Затем у вас может быть даже полностью сериализованный инвентарь, где каждая единица имеет свой собственный серийный номер. В терминах оптимизации цепи поставок это полностью меняет игру, поэтому это совершенно другая проблема, когда вы смотрите на каждый из этих аспектов.
Затем, очевидно, у вас есть все проблемы рынков. В Lokad у нас есть клиенты в буквально каждой возможной ситуации. У нас есть клиенты, которые продают на стороннем рынке, у них может быть собственный рынок или у них может быть и то, и другое. Это может быть что-то вторичное, чтобы они могли использовать его для ликвидации непроданных товаров. Существует множество ситуаций.
Теперь, просто для примера, подумайте на минуту о том, что такое заказ. У вас есть заказ на месте, где вы просто покупаете что-то прямо с прилавка, и оно становится вашим. Но затем у вас также может быть заказ, который говорит: “Я покупаю это, но я не хочу, чтобы это было доставлено немедленно; я хочу, чтобы это было доставлено через месяц”. Очевидно, с точки зрения оптимизации цепи поставок, это совершенно другая игра, потому что если вы знаете заранее, что вам нужно доставить определенное количество товаров в определенную дату, вы не хотите прогнозировать это, поэтому это совершенно другая вещь.
И затем у вас есть настроенный заказ, например, когда вы покупаете компьютер онлайн и можете выбрать, сколько памяти, сколько жесткого диска, какая операционная система, на каком языке будет настроен ваш компьютер и какая клавиатура будет, среди прочего. Таким образом, у вас может быть массовый конфигуратор, и это снова меняет ситуацию. То же самое происходит с велосипедами или автомобилями и полностью меняет ситуацию, когда у вас есть такие вещи, потому что это дает вам варианты и способы рассмотреть проблему оптимизации цепи поставок, которые совершенно разные.
Даже для цен, у вас может быть цена за единицу, которая является фиксированной, очень простой и линейной, но это не единственное. Вы можете иметь скидки на цену, например, если вы покупаете десять единиц, то получаете скидку. Или у вас могут быть программы лояльности, где некоторые клиенты с лояльной картой могут получить скидку, но только на определенные типы товаров или только в зависимости от определенных условий. И затем у вас даже может быть, в B2B, очень частые вещи, которые обсуждаются, поэтому это буквально сделка, где будет продано много вещей, но у вас есть регулярная каталожная цена. Однако поставщик может предоставить скидку клиенту, потому что они важны, и это просто так делается. В итоге, я только что говорил несколько минут, и я только коснулся основы. Я даже не начал затрагивать необходимые вещи. Поэтому просто остановитесь на мгновение и попробуйте подумать о том, как будет выглядеть готовое предприятие, которое должно обеспечивать оптимизацию цепи поставок. Количество функций, которые нужно реализовать, просто безумно большое, и когда вы пытаетесь представить, как объединить все эти вещи в монолит, вы буквально теряете рассудок. Мы возвращаемся к идее, что дело не в том, что вселенная не может быть известна, просто если вы сталкиваетесь с голой правдой вселенной, вы теряете рассудок.
Итак, у нас есть серьезная проблема, и здесь нам нужно различать управление цепью поставок от оптимизации цепи поставок. Это различие я уже ввел в одной из своих предыдущих лекций. Существует большая путаница между стороной управления и стороной оптимизации. Управление связано с ведением учета, поддержкой рабочих процессов и в основном с вводом данных. Если вы хотите представить все то, о чем я только что рассказал, это много работы, но это выполнимо. “Ожирелая” ERP может справиться с этим. Да, у вас будет 10 000 таблиц, это будет довольно некрасиво, но это возможно. Но не заблуждайтесь, ERP (которая должна называться ERM, управление ресурсами предприятия) не сделает многое. Она просто будет отслеживать все эти вещи. Так что у вас будет тонны сущностей - MOQs, проверка; скидки на цену, проверка; магазины, проверка; склады, проверка - но вам не нужно иметь никакой степени интеллекта. Это просто о мирных цифровых аналогах для отражения данных, делая возможным ввод данных в систему, и все.
Это возможно, потому что здесь мы можем немного сжульничать с этим правилом “на четверть больше функций - удвоение стоимости”. Есть одна вещь, которую я не сказал об этом: это работает, если вы полностью изолируете свои функции. Пока функции не взаимодействуют друг с другом, все в порядке, вы не подвержены этому проклятию неэкономии масштаба. С точки зрения ввода данных, проблем нет. Вам не нужно иметь пользовательский интерфейс, который позволяет вам управлять MOQs, связанными с тем, что позволяет вам добавлять дополнительный магазин в сеть. Эти две вещи могут быть полностью изолированы.
Однако, когда речь идет об оптимизации цепи поставок, то же самое не верно. Если у вас есть MOQs, они будут иметь глубокие последствия для того, как часто вы заказываете, как часто вы будете доставлять вещи со склада в магазины. Есть множество далеко идущих последствий. Вы не можете изолировать вещи, потому что, в конечном счете, ваша цепь поставок - это всего лишь одна система, где все влияет на все. Так что с точки зрения оптимизации цепи поставок у вас буквально возникает проблема, что все эти вещи должны быть включены, если вы хотите достичь оптимизации, и именно здесь все разваливается.
С точки зрения управления, вы можете потенциально получить продукт. Однако, для оптимизации цепочки поставок, ответ таков, что вы не можете. Я имею в виду, вы можете притворяться, но буквально вы не можете. Даже в Lokad, который начал свою деятельность не как компания, специализирующаяся на предсказательной оптимизации цепочек поставок, а как сервис прогнозирования. Если вы вернетесь к блогу Lokad в 2008 году, то увидите, что я начал с прогнозирования временных рядов, что было крайне ошибочным. Тем не менее, так я начал. Даже для прогнозирования временных рядов, которое является малой частью всей проблемы, это невозможно. Это мой вывод после более чем 12 лет работы в этой сфере.
Если мы вернемся к конкретному миру создания программного обеспечения, это нечто особенное. Если вы не прошли обучение в качестве программиста и не знакомы с тем, как крупные успешные компании по созданию программного обеспечения производят его, то вероятно, вы о нем знаете очень мало. Оказывается, это очень специфический мир с множеством противоречивых аспектов. Традиционные компании, особенно те, у которых классическое механическое инженерное мышление или маркетинговое мышление, испытывают огромные трудности с пониманием того, как работает программное обеспечение вообще.
Мы рассмотрим эти аспекты более подробно в будущих лекциях, но есть одна книга, которая мне очень нравится, написанная Джоэлом Спольски, бывшим сотрудником Microsoft, который работал в первых командах Microsoft Excel. Он также является сооснователем Stack Overflow и Trello. В 2004 году, когда я был только студентом, я прочитал его книгу и блог. Книга называется “Joel on Software” и юмористически позволяет вам понять, как выглядит успешный бизнес по созданию программного обеспечения. Это очень отличается от того, чего ожидают большинство людей, не связанных с этой отраслью. Я добавлю подробности о этой книге в описание видео.
Но давайте помнить, что оптимизация цепочки поставок - это не ваш обычный программный продукт. Обычно, когда вы имеете дело с обычным программным продуктом - я имею в виду, да, у вас могут быть некоторые антагонистические поведения, в зависимости от типа программного продукта. Если вы имеете дело с социальной сетью, у вас может быть множество людей, размещающих ненавистный контент, что является совершенно другой игрой. Однако, когда речь идет о классическом корпоративном программном обеспечении, таком как Microsoft Word или Excel, это продукт, в котором вы хотите иметь правильный дизайн, но нет никакой необходимости в срочности. В случае традиционных программных продуктов нормально потратить годы на совершенствование дизайна и продукта. Это долгосрочные инвестиции, и вы должны смотреть вперед на десятилетия. Нет никакой причины торопиться с разработкой. Однако, оптимизация цепочки поставок не работает так. У вас нет выбора, так как события происходят постоянно, и местность очень неровная.
Могут возникать экстремальные ситуации, такие как пандемия или другие проблемы, такие как вымогательство, которые могут парализовать половину вашей сети. Вам нужно принимать умные решения, чтобы максимально использовать возможности, которые у вас все еще есть в распоряжении. Вы можете столкнуться с проблемой наземного парка из-за трагических происшествий, политических маневров, таких как тарифы, которые нарушают вашу стратегию, или природных стихийных бедствий, таких как цунами, пожары и жаровни, как в Калифорнии или Австралии. Эти события случаются, и когда они происходят, вам нужно быть способным реагировать буквально в течение нескольких часов.
У вас есть ваш программный продукт, но вам нужно внести изменения, и вы хотите внести программные изменения. Помните, если вы нацелены на создание программного актива, у вас есть небольшая команда, которая разрабатывает программное обеспечение, которое, в свою очередь, управляет вашей цепочкой поставок. У вас нет армии клерков, которые занимаются тушением пожаров весь день. Даже если у вас есть армия клерков, вам нужно их обучить, и когда происходит что-то совершенно неожиданное, вы оказываетесь с армией, которая не была подготовлена к этой конкретной ситуации. По моему опыту, чем больше людей вам нужно управлять, тем дольше занимает достижение чего-либо.
Всего несколько дней назад грузовое судно потеряло более 1800 контейнеров из-за плохих погодных условий. Такие вещи случаются, и вы не можете надеяться их исключить. Цепочка поставок не похожа на производство, где у вас может быть производственный участок со всеми тщательно контролируемыми элементами. По определению, цепочки поставок происходят в большом мире, где большую часть времени вы не имеете контроля над элементами. Существует так много сил, находящихся вне вашего контроля, что вам нужно уметь справляться с неожиданными событиями. Вы уже знаете, что сюрпризы будут случаться, поэтому вам нужно быть готовыми. Быть готовым не означает иметь все тщательно спланировано; это означает иметь систему, в которой вы можете реагировать в течение нескольких часов, если это необходимо. Вот суть того, что вы можете сделать, чтобы реалистично подойти к проблеме.
Итак, что нам нужно в терминах программных компонентов для оптимизации цепочки поставок? Во-первых, нам нужно универсальное хранилище данных для представления всех различных типов источников данных. Существует так много вещей, которые мы хотим представить, поэтому мы хотим что-то очень универсальное в этом отношении, с большим количеством структуры и разнообразия.
Во-вторых, вам нужна программируемая логика. Я возвращаюсь к этой идее: если у вас нет программируемой логики, как вы справляетесь со всеми этими проблемами? Как вы объединяете все эти вещи вместе? Вы не можете купить готовый продукт, в котором все будет заранее запрограммировано для вас; это не работает.
Затем вам нужен универсальный пользовательский интерфейс, потому что способ, которым вы хотите смотреть на свои проблемы, будет сильно отличаться от ситуации к ситуации. Ключевые показатели эффективности будут полностью отличаться от одной компании к другой, поэтому вам нужен универсальный пользовательский интерфейс, где вы можете представлять числа любым удобным для вас способом; в противном случае это будет большим ограничением.
Вы также хотите иметь возможности для совместной работы, потому что цепочка поставок - это командная работа по определению. В нее вовлечено много людей, и она распределена, поэтому возможности для совместной работы должны быть в центре внимания.
Наконец, и, возможно, более спорно, вам нужны программируемые возможности, доступные людям, не обученным программистами. Это важно по нескольким причинам. Во-первых, на рынке труда нет многих обученных программистов, поэтому найти их очень сложно. Во-вторых, становление талантливым программистом требует такого большого усилия и преданности, что одновременно быть талантливым программистом и специалистом по цепочкам поставок - это вызов.
Не очень распространено найти людей, которые обладают двойными компетенциями в обоих областях. То же самое относится, если вы ищете человека, который является одновременно программистом и юристом, или программистом и врачом. Да, вы найдете некоторых людей с такими наборами навыков, но сможете ли вы делать это в масштабе или надежно нанимать больше таких людей каждый год, если вы крупная компания? Из моего опыта работы в Lokad в течение десятилетия, это просто не работает.
Вам нужно что-то программное, но вам не нужно быть профессионально обученным программистом, чтобы справиться с программированием. Помните, что вам нужен человек с компетенцией в области цепочки поставок, потому что вам нужно уметь справляться в течение нескольких часов с применением программных корректировок к вашей системе без открытия заявки и передачи ее в IT. Если вам приходится делать это таким образом, то на решение проблем уходит несколько недель, а не часов. Итак, какое программное обеспечение на самом деле может решить проблему?
Хорошо, Excel может. Он не слишком красив и может не казаться вершиной современного программного обеспечения, но он справляется с задачей. Он отмечает все галочки.
Универсальное хранилище данных? Да, в некоторой степени, вы можете поместить много данных любого вида в Excel. Программируемая логика? Абсолютно, Excel полностью программируемый. Универсальный пользовательский интерфейс? Да, вы можете иметь столбчатые диаграммы, линейные диаграммы и множество способов представления данных. В терминах пользовательских интерфейсов он очень универсальный. Он может быть не самым идеальным, но в плане универсальности он может многое сделать.
В терминах возможностей совместной работы он немного грубоват. У вас есть некоторые версии Excel, которые работают онлайн, что немного лучше, но в основном вы можете делиться своими электронными таблицами. Проблема отсутствия возможностей совместной работы не заключается в том, что это приложение для настольных компьютеров. Проблема заключается в подходе, который лежит в основе электронных таблиц и который не подходит для интенсивной совместной работы. Обычно, если у вас есть коллега, создавший очень сложную таблицу, проще воссоздать таблицу, чем пытаться разобраться, что они сделали. Таким образом, проблема отсутствия возможностей совместной работы заключается в подходе, который сопровождает электронные таблицы и который по своей сути имеет сильные ограничения для совместной работы.
Однако Excel полностью доступен для непрограммистов, и даже есть Visual Basic для приложений для выполнения более сложных задач. В терминах компонентов Excel отвечает всем требованиям, что, я считаю, в значительной степени объясняет его операционный успех в большинстве цепей поставок.
По моему опыту, большинство цепей поставок в мире, от самых маленьких компаний до самых крупных, от тех, кто ни разу не вложил ни цента в корпоративное программное обеспечение, до тех, кто вложил миллионы долларов в сложное корпоративное программное обеспечение для оптимизации цепей поставок, управляются с помощью Excel. Есть очень немного исключений. Иногда люди используют Excel для изменения настроек минимума и максимума в другом программном обеспечении, но поддержка этих настроек делегируется тем, кто работает с Excel.
Сегодня Excel определяет мир цепей поставок, и я считаю, что это не случайность. В своей сути электронные таблицы фундаментально решают множество правильных проблем. Многие другие варианты представлены как превосходные, но они терпят неудачу по умолчанию, если вы не умеете программировать. Если вы не умеете программировать, это означает, что когда вы сталкиваетесь с серьезной проблемой или чрезвычайной ситуацией, у вас нет никаких шансов. Люди будут возвращаться к электронным таблицам Excel в ситуациях, когда отсутствует универсальный пользовательский интерфейс или когда решение недоступно для непрограммистов. Если только команда IT может достичь результатов, люди могут сначала открывать заявки и терпеливо ждать, но через три месяца все, скорее всего, вернутся к использованию электронных таблиц Excel, потому что это быстрее. Excel не является конечной целью, но что бы мы ни предложили в качестве превосходной замены, оно должно отвечать правильным требованиям.
Как сделать что-то лучше? В терминах универсального хранилища данных Excel хорош, но не очень масштабируем. Обработка миллионов строк становится проблемой, даже с современными версиями Excel, которые могут обрабатывать миллион строк. Проблемы с производительностью возникают быстро при работе в масштабе. Программируемая логика в Excel возможна, но она очень хрупкая и ломкая. Если вы случайно допустите ошибку или ошибку в своей электронной таблице, отладка и определение источника проблемы становится кошмаром. Логика бесконечно дублируется, что приводит к тысячам копий одной и той же логики, что затрудняет идентификацию и исправление ошибок.
Пользовательский интерфейс не идеален, поскольку он не полностью основан на вебе, и данные всегда переплетены с интерфейсом. Существуют возможности совместной работы, но они неопрятны. Совместная работа должна происходить на уровне программной логики. Многие поставщики оптимизации цепей поставок предлагают совместную работу по результатам, такую как ручное настройка прогнозов и возможность участия нескольких людей. Однако это неправильный подход. Сотрудничество должно происходить, но оно должно происходить на логическом уровне, на уровне программной логики. Excel очень доступен для непрограммистов, но когда вам нужно сделать что-то немного сложнее, это становится сложным. В управлении цепями поставок мы хотим иметь дело со всеми возможными будущими ситуациями, что означает работу с вероятностными прогнозами, случайными величинами и учетом неопределенности. Хотя это возможно в Excel, это довольно сложно. Excel легок для простых задач, но для более сложных ситуаций вам нужно стать волшебником Excel.
Важна поддерживаемость, поскольку вы хотите создать актив с растущей стоимостью со временем. С электронными таблицами это сложно достичь, и трудно создать что-то действительно точное, по крайней мере, в смысле программного продукта.
Слова-модные термины сегодня - это ИИ и Python, со всеми трендами и шумихой вокруг науки о данных. Однако, по моему мнению, для управления цепями поставок Python уступает Excel.
Не поймите меня неправильно; я обожаю Python и считаю его блестящим языком. Я даже обучаю его своей 10-летней дочери. Однако есть несколько причин, почему Python не является лучшим выбором для управления цепями поставок. Во-первых, для его использования требуются программные инженеры. Хотя Python является одним из самых доступных языков программирования, когда вам нужно сделать что-то более сложное, вам понадобится команда программных инженеров, что создает проблемы, когда вам нужны люди, которые являются и экспертами по цепям поставок, и программными инженерами.
У Python есть хорошие возможности, но обработка зависимостей довольно сложна, и управление пакетами плохое. Пакеты - это строительные блоки, которые предоставляют дополнительные возможности, и когда вы говорите, что хотите использовать Python, вас интересует не только язык, но и весь экосистема пакетов, таких как NumPy, Pandas, TensorFlow и SciPy - все это сторонние зависимости или программные библиотеки. Управление пакетами было плохим на протяжении десятилетия, и хотя оно улучшается, прогресс медленный. Есть много аспектов дизайна системы, которые затрудняют ее улучшение.
Производительность также низкая, в основном по дизайну. Производительность вычислений относится к качеству работы Python по использованию доступной вычислительной мощности вашего компьютера. Удивительно, но Microsoft Excel делает это намного лучше. Excel высоко оптимизирован, использует многопроцессорные и многопоточные системы и выполняет логику, скомпилированную нативно. Microsoft вложил много сил в то, чтобы сделать Excel чрезвычайно быстрым.
В отличие от этого, у Python есть врожденные проблемы, из-за которых производительность часто на 100 раз медленнее, чем могла бы быть на вашем компьютере в теории. Хотя это может показаться приемлемым для некоторых, учитывая мощность современных компьютеров, это не идеально для компаний с объемами транзакций более 50 миллионов долларов. Вы хотите что-то, что изначально обеспечивает хорошую производительность.
Идея использования сторонней библиотеки, такой как NumPy, для решения проблемы производительности Python только добавляет сложности. Вы можете решить проблему производительности, но создаете новую проблему, вводя дополнительную сложность NumPy, с которой вам нужно иметь дело и поддерживать со временем. Это также повышает требования к программной инженерии.
При попытке реализовать решения на Python для реального управления цепями поставок возникают различные проблемы, такие как исключения нулевой ссылки, исключения из-за нехватки памяти и длительное время вычислений. Вы можете оказаться в ожидании 20 минут, чтобы вычисление завершилось, не уверены, закончится ли оно когда-нибудь, или стоит ли просто прервать процесс и перезапустить его. Я просто не знаю, поэтому вы хотите, чтобы у вас была очень, очень хорошая представление о том, сколько времени это займет. Кстати, если я вернусь к Excel, сейчас, когда есть операция, которая занимает некоторое время для завершения, Excel даст вам довольно надежный индикатор, полосу прогресса, показывающую, сколько времени это займет. Итак, вы хотите, и это часть того, что я называю готовностью к производству. Вы хотите иметь нечто, потому что, снова же, скорее всего, программное обеспечение, которое вы создаете, будет работать без присмотра, ночью или во время ночного пакета, например. Вы хотите, чтобы это не требовало от ученого по данным присматривать за всем этим.
И снова, если у вас есть проблема с учеными по данным, тогда вам нужна третья компетенция: эксперт по цепям поставок, эксперт по программной инженерии и теперь эксперт по ученым по данным. Возможно, у одного человека может быть все три качества, но удачи с наймом более одного человека в год, даже если вы крупная компания, которая обладает всеми этими навыками. Это просто очень редко.
Итак, мы хотим иметь что-то, что улучшит ситуацию. Кстати, первое, что мы хотим улучшить, это защиту в глубину. Атаки с использованием программ-вымогателей становятся все более распространенными, и когда вы внедряете что-то программное в свою организацию, вы подвергаете себя риску атаки программ-вымогателей. Потому что внезапно, когда у вас есть программа, она может делать множество вещей, включая захват самой машины, на которой она работает. Я знаю, что существует множество способов смягчить проблемы; вы можете использовать песочницы, ограничивать доступ, иметь ограниченные права, и существует множество способов ограничить проблемы. Тем не менее, когда у вас есть что-то вроде общего языка программирования, ваша площадь атаки, это технический термин, абсолютно гигантская.
Так что, в основном, когда вы подключаете такой код, вы себя массово подвергаете риску в терминах проблем безопасности. И помните, что в обычном программном инжиниринге код проходит проверку коллегами. Вы проверяете код, у вас есть процесс проверки кода, когда кто-то создает код, и есть коллега, который будет проверять код, чтобы убедиться, что в коде нет никаких недоразумений. Но если я вернусь к тому факту, что программное обеспечение должно быть надежным, вам нужно иметь возможность реагировать в течение нескольких часов. Вы не сможете, с точки зрения оптимизации цепи поставок, иметь процесс проверки кода. Это просто несовместимо с задержками и чрезвычайными ситуациями, с которыми вы столкнетесь.
Поэтому вам нужно иметь что-то, что обеспечит вам защиту в глубину по умолчанию. Затем вы хотите иметь что-то с прозрачной производительностью, где да, вещи могут занимать время, но вы должны быть в контроле. Вам нужно знать заранее, сколько времени это займет. Если у вас этого нет, то вы подвергаете себя множеству очень глупых проблем, например, у вас было двухчасовое окно для доставки результатов, и вы опоздали. И вы знаете что? Грузовики уже уехали. Слишком поздно. Поэтому вам нужно иметь что-то, где об этом позаботились.
То же самое относится к прозрачным обновлениям. Вот в чем красота Excel. Вам не нужно думать о поддержке Excel. Десятилетия назад Microsoft заключил пакт кровью, который гласил: если вы создали электронную таблицу в Excel, то любая следующая версия Excel, которая появится на рынке, сможет поддерживать ваши таблицы. И самое невероятное в том, что если вы посмотрите на современный Excel, он поддерживает множество конкурирующих форматов Excel конкурентов, которые уже давно не существуют. Вы все еще можете читать таблицы, созданные с помощью Lotus Notes и подобных программ. Таким образом, предложение Microsoft в терминах прозрачных обновлений заключается в том, что логика, которую вы создали, будет работать вечно, и да, они будут продолжать улучшать Excel на протяжении десятилетий, но вы знаете что? Об этом позаботились. Это не то, что вы видите при переходе с Python 2 на Python 3; это был кошмар, и это заняло десятилетие. Итак, Python отлично подходит для многих вещей, но представьте себе, что эти обновления произойдут в самые неподходящие моменты, когда у вас будет самая худшая пандемия, самые плохие тарифы, самая критическая ситуация, и вам нужно, чтобы все было готово и работало. Вы не можете позволить себе полгода простоя только из-за обновления. Это несовместимо с оптимизацией цепи поставок.
Итак, теперь нам нужно подумать о том, что, если бы мы рассмотрели что-то, что могло бы быть разработано с учетом цепи поставок? Это будет темой следующей лекции.
Кроме того, цепь поставок - это не отдел IT. Когда я говорю о поставке, связанной с продуктом, снова, это не означает, что программное обеспечение является только средством, а не целью. Вы не будете продавать свое программное обеспечение по лицензиям или за плату, как, скажем, делает Microsoft. В этом видении, которое я излагаю перед вами в этой лекции, IT отвечает за основные практики, основные практики IT, такие как то, что вы должны делать или не делать в терминах безопасности, резервного копирования, основной инфраструктуры, вашей сети, как управлять и синхронизировать все в терминах данных на уровне компании и предоставлять все руководство и коучинг.
Но идея заключается в том, что цепочка поставок должна владеть решениями по цепочке поставок. Они должны владеть всем аппаратом, который генерирует эти решения по цепочке поставок, поэтому это их основное владение. В предыдущей лекции я сказал, что определяет ученого по цепочке поставок: ученый по цепочке поставок - это тот, кто владеет числовыми решениями, полученными из кода. Это не система, которая принимает решения; это числовые рецепты, которые были записаны одним или несколькими учеными по цепочке поставок, и эти ученые по цепочке поставок коллективно владеют этими числовыми решениями. Они берут на себя ответственность за это, и ответственность цепочки поставок заключается в том, чтобы убедиться, что все решения в компании согласованы. Если идет продвижение или большая маркетинговая акция, вещи должны быть произведены вовремя, чтобы быть готовыми к обслуживанию. Вы не хотите оказаться в катастрофической ситуации, когда вы продвигаете что-то, когда вы уже находитесь в ситуации почти дефицита, когда вы тратите деньги на маркетинговую акцию для чего-то, что вы даже не можете продать, потому что у вас нет товара или возможности производить их или предоставлять услуги вовремя и т.д.
Итак, у нас есть два подразделения, которые имеют очень разные цели. В моем идеальном представлении о том, что должен быть отдел информационных технологий, отдел информационных технологий не является подразделением, где вы передаете заявки. Так это не работает. Отдел информационных технологий отвечает за основную инфраструктуру. Это то, что работает беспрепятственно все время. Вы даже не обращаете внимания, так же как работает Wi-Fi. Вы не обращаете внимания на Wi-Fi; вы обращаете внимание на Wi-Fi только тогда, когда он не работает. Хороший отдел информационных технологий предоставляет всю инфраструктуру так, чтобы вы даже не обращали на них внимания. Вы даже не осознаете, что они существуют, потому что это просто работает, так же как безупречно работают ваши электронные письма и т.д. Вот в чем суть хороших основных информационных технологий. И затем информационные технологии - это такие люди, которые приходят к вам и помогают вам установить все те практики, которые помогут вам. Программируемая логика немного сложна, поэтому иногда, где вы будете получать обучение, чтобы стать немного лучше в программировании? Ну, ответ заключается в том, что это должны быть информационные технологии. Они должны приходить не с тем, чтобы сказать: “Мы сделаем это за вас”, а скорее: “Мы будем вас тренировать, чтобы вы могли реализовать это сами. Мы поможем вам с несколькими концепциями, возможно, поможем вам с некоторыми вещами, которые должны быть немного более техническими, чем они должны быть”. Иногда у вас возникает случайная сложность, поэтому информационные технологии находятся рядом, чтобы поддержать вас. Но в основном они не здесь, чтобы делать работу за вас. Они должны быть наставниками и тренерами, чтобы убедиться, что никто не совершает терминальную ошибку, которая могла бы подвергнуть всю компанию риску вымогательства или чего-то, что могло бы быть системным риском с точки зрения информационных технологий для компании.
Как проверка на прочность, если ваше взаимодействие между информационными технологиями и цепочкой поставок происходит через документы, в которых вы перечисляете спецификации или требования, это не правильный способ установить хорошие отношения между этими двумя подразделениями. Когда я говорю о хороших отношениях, я имею в виду то, что действительно добавит ценность для компании.
В заключение, у нас здесь две проблемы со стороны традиционного управления цепочкой поставок, которые могли заниматься программированием, но только на краю для электронных таблиц Excel, даже не осознавая, что это уже форма программирования. Вам нужно преодолеть свои страхи. Вам нужно думать о том, что мир завтрашнего дня, ваше подразделение, будет отвечать за создание продукта, который работает как программный продукт, и это огромное изменение. Да, но с этим можно справиться. Почему? Потому что если у вас есть правильные инструменты, да, вовлечено программирование, но это не фундаментально, радикально сложнее, чем Excel. Опять же, проблема не в техничности инструмента; она буквально в сложности самой цепочки поставок. Проблема сложна не потому, что ваш инструмент сложно использовать, а потому, что у вас сложная цепочка поставок в первую очередь.
Для части аудитории, которая, возможно, больше на стороне ученых-исследователей данных или IT, вам нужно преодолеть чрезмерную уверенность. Я видел снова и снова, как ученые-исследователи данных, и я включаю себя в эту категорию, были чрезмерно уверены в своей способности привести прототип в производство. Это сложно, и цепочки поставок имеют способность взорваться в вашем лице самым неожиданным образом. Я могу вспомнить только одну историю, когда много лет назад мы начали с ведущей европейской компании электронной коммерции автозапчастей. Мы занимались пополнением их запасов с помощью нашей технологии прогнозирования, делая предложения по пополнению запасов запчастей для автомобилей. На следующей неделе мы увидели, что все наши прогнозы ошибочны в два раза. Спрос удвоился. Что произошло, заключалось в том, что их главный конкурент решил одновременно выйти в несколько стран, буквально в то время, когда мы начинали наш прогноз, один из конкурентов решил выйти на все национальные телевизионные каналы и начать транслировать свою услугу онлайн. Интересно то, что мой клиент даже не знал об этом, и у них были лучшие результаты по оптимизации поисковых систем. Они были более оптимизированы с точки зрения SEO, поэтому, фактически, люди видели рекламу конкурента по телевизору, но они естественно не помнили имя конкурента. Итак, они заходили на Google и набирали “автозапчасти”, пока не попадали на веб-сайт моего клиента. Чтобы продемонстрировать, насколько великой была Lokad, в первую неделю, когда мы начинали, мы ошибались в два раза, и мы думали: “Что, черт возьми, происходит?” Мы должны были все пересмотреть, потому что, когда вы видите, что спрос удваивается, это не значит, что все удваивается; некоторые вещи увеличиваются в 10 раз, а многие вещи остаются без изменений.
Так вот, вам нужно быть способным быстро реагировать. Вот в чем дело: страх и чрезмерная уверенность. Большое спасибо за время.
Теперь я посмотрю на вопросы через чат.
Вопрос: Может ли программное обеспечение принимать решение о том, с каким поставщиком разместить дополнительный заказ в случае необходимости большего количества на завтра? Например, 200-граммовые контейнеры с клубникой в офисах в Австралии могут иметь 10 поставщиков, доставляющих одни и те же продукты в дистрибуционный центр в один и тот же день.
Абсолютно, и здесь нам нужно различать две стороны управления цепочкой поставок и оптимизации цепочки поставок. Есть сторона управления цепочкой поставок, которая буквально означает наличие всех конвейеров данных, включая EDI, где вы можете отправить электронный заказ поставщику без какого-либо вмешательства человека. Таким образом, у вас есть электронный мост от начала до конца. Но затем это означает, что вам нужно иметь на стороне оптимизации программное обеспечение, которое работает непрерывно в течение дня и, в какой-то момент, может уведомить сторону управления, говоря: “Пожалуйста, выполните этот заказ”. А затем, на стороне управления, которая будет управляться IT, они просто убеждаются, что этот заказ полностью выполнен. Это просто вопрос чистой транзакционности; больше нет никакого интеллекта. Вы получили заказ, который говорит “это количество”, и за выполнение этого заказа отвечает сторона оптимизации, которая должна убедиться, что при генерации определенного количества вы соблюдаете все ограничения, такие как точный список поставщиков, которые даже имеют право обслуживать эти продукты, есть ли у них остаток на складе и как сделать правильный выбор между всеми конкурирующими поставщиками и т. д. Могут происходить множество вещей. Абсолютно да, но нам действительно нужно разделить мирское исполнение, которое является транзакционной частью, лежащей на стороне управления цепочкой поставок, от наличия оптимизационного компонента в тот момент, когда вы решаете, что вам нужно заказать больше.
Вопрос: Вы знаете, что вы сейчас конкурируете с чемпионатами мира по киберспорту?
Нет, я сейчас не конкурирую с этими чемпионатами по киберспорту, но это очень круто. Кстати, в Lokad мы часто играем в Dota 2, так что и руководство компании тоже играет. Некоторые из наших сотрудников хотят играть в League of Legends, но как генеральный директор компании я категорически против этого.
Вопрос: Я видел, что многие компании вообще не имеют ERP или WMS, и что руководство работает над оптимизацией цепочки поставок.
Да, абсолютно верно. Вы не можете избежать оптимизации цепочки поставок с самого начала; вам нужно принимать эти решения. Оптимизация цепочки поставок существовала еще до появления какого-либо программного обеспечения для управления цепочкой поставок. Даже если мы вернемся 60 лет назад, когда не было программного обеспечения, люди все равно должны были принимать решения. Так что оптимизация цепочки поставок уже была вещью; люди делали это с помощью ручки и бумаги. Если посмотреть на самые ранние работы по цепочке поставок, такие как формула Уилсона, также известная как формула EOQ, ей уже сто лет. Она явно предшествует программному обеспечению. Так что да, оптимизация цепочки поставок - это то, что происходит с самого начала, независимо от того, есть ли у вас программное обеспечение в вашей организации или нет.
Теперь, действительно, вам нужно иметь правильные ИТ-системы, но это совершенно другой подход. Управление цепочкой поставок заключается в том, чтобы очень хорошо выполнять мелкие задачи, такие как ввод данных, возможно, с поддержкой штрих-кодов и других вещей. Но это связано с очень простыми задачами, просто представление данных. Проблема в том, что люди хотят, чтобы одно и то же решение делало и управление цепочкой поставок, и оптимизацию цепочки поставок, и в результате получается продукт, который слишком сложен, обычно супер ошибочный, и вам нужно иметь плохие функции, такие как предупреждения и исключения, которых следует избегать. Я вернусь к этому в следующей лекции.
Фундаментально, в настоящее время развертывание WMS или ERP, если у вас его еще нет, занимает несколько недель. Если у вас уже есть, это может занять несколько месяцев, если вы разъедините это от ваших решений.
Вопрос: Когда руководство компании может понять, что пришло время перейти от отслеживания информации к оптимизации решений в цепочке поставок и, в конечном итоге, начать сосредотачиваться на оптимизации цепочки поставок?
Первое, что нужно понять, это то, что с самого начала существуют две проблемы, и одно и то же программное обеспечение никогда не решит обе проблемы. Я думаю, что это большая иллюзия, и поставщики программного обеспечения в этой области были невероятно путающими. Если посмотреть на крупнейших поставщиков ERP, их сообщение связано с оптимизацией цепочки поставок, но все, что они фактически предлагают и все, что делает их продукт, связано с управлением цепочкой поставок, что намного менее привлекательно, потому что здесь нет искусственного интеллекта или реального интеллекта. В мире программного обеспечения это известно как CRUD-приложения (Create, Read, Update, Delete). ERP - это просто гигантская коллекция экранов CRUD, где каждый экран может создавать, читать, обновлять или удалять строки из реляционной базы данных, и все. ERP - это, упрощая немного, коллекция тысяч таблиц для различных сущностей. Для каждой логически объединенной сущности у вас есть один или два экрана, и все. Так что, если я вернусь к вашему вопросу о руководстве, проблема в том, что если вы менеджер, вы читаете брошюру поставщика ERP, и поставщики ERP говорят вам, что это решение оптимизирует вашу цепочку поставок. Ответ: нет, абсолютно нет. Оно улучшит производительность и обеспечит точное ведение учета вашей цепочки поставок. Это уже много, так как это может значительно снизить кражи, потери, неправильное размещение товаров и улучшить производительность с помощью штрих-кодов для склада. В этих продуктах есть много добавленной стоимости. Я не отрицаю ценность, которую приносит ERP или WMS; она огромна, но это не связано с оптимизацией цепочки поставок. WMS, например, по своей природе является чем-то, что заботится о складе; он не заботится о всей цепочке поставок, которая включает клиентов и поставщиков. Он по своей природе сосредоточен на конкретных местах, а не на всей цепочке.
Вопрос: Как можно плавно перейти с Python на Envision или заставить их работать вместе?
Мы действительно использовали их вместе в нескольких ситуациях в прошлом. Для аудитории Envision - это язык программирования, разработанный компанией Lokad, который был специально создан для предиктивной оптимизации цепей поставок. В следующей лекции я продемонстрирую Envision, чтобы люди могли лучше понять, о чем я говорю, на примере реального кода.
Исторически мы использовали Python и Envision вместе, потому что, когда мы начинали, у Envision были очень ограниченные возможности, поэтому многих вещей не хватало, и мы использовали Python по умолчанию во многих ситуациях. С течением времени мы постепенно расширяли возможности Envision, поэтому мы постепенно отказались от необходимости использования компонентов Python. Это не только компоненты Python; это также ряд инструментов, которые нужно объединить вместе, например, Airflow.
Кстати, синтаксис Envision был специально выровнен во многих аспектах с Python. Я сознательно выбрал такой синтаксис Envision, который не вызывает антагонизма у программистов Python, чтобы если вы знакомы с Python, вы могли выучить Envision за неделю. Он отличается в тонких и глубоких аспектах, но с точки зрения синтаксиса есть много общего. У Python есть много достоинств, таких как простота и чистота дизайна. Даже если я говорю, что Python не удовлетворяет всем требованиям и создает серьезные проблемы в производстве, из которых нельзя восстановиться, это не означает, что Python не имеет достоинств. Я считаю, что у Python есть много достоинств. Опять же, мы говорим конкретно о том, как запускать цепи поставок в производстве, что является очень конкретной проблемой.
Вопрос: Как вы объясните клиенту, что его ERP-система не оптимизирует ничего?
Это очень сложно, потому что, честно говоря, самая неприятная ситуация возникает, когда потенциальный клиент обращается ко мне и говорит: “Наша ERP-система, устаревшая ERP-система, не приносит никакой ценности, и теперь мы хотим перейти к следующей ERP-системе, которая обеспечивает оптимизацию цепей поставок”. Это ужасная ситуация для меня, потому что мне приходится объяснять клиенту, что он ищет не один продукт, а два: один, который заменит его ERP-систему и лучше управляет стороной управления, и один, который будет выполнять оптимизацию.
Когда вы думаете об этих устаревших ERP-системах, я очень уважаю их, особенно те продукты AS/400 с командной строкой на старых IBM-мейнфреймах. С точки зрения управления проблемой они обычно делают очень хорошую работу. То, что клиенты действительно ищут, может быть веб-интерфейсом, а не командной строкой, но сделает ли это их команды на месте более продуктивными? Я вызываю это сомнения. Командные строки с текстовыми терминалами могут быть невероятно быстрыми и продуктивными без отвлечений.
Так что это довольно сложно, потому что нам нужно разобраться со всем бредом, который навязывают наши конкуренты. Кроме того, нам нужно объяснить, что ERP-система не будет оптимизировать цепь поставок и что таких вещей, как искусственный интеллект или блокчейн, на самом деле не существует, есть только классы статистических моделей. К сожалению, на этом этапе мы теряем большинство потенциальных клиентов. Вот почему я вообще провожу эти лекции, потому что требуется много времени, чтобы докопаться до сути и объяснить, почему мы должны видеть проблему так, как я ее вижу.
Вопрос: Каково ваше рекомендация по выбору платформы для решения сложности планирования нескольких продуктов с вероятностным распределением спроса?
Конечно, Lokad. Но имейте в виду, что, будучи генеральным директором Lokad и основным владельцем компании, у меня есть конфликт интересов в моем мнении. Я глубоко убежден, что Lokad - это платформа, которая вам нужна, но, пожалуйста, поймите, что это также компания, которой я владею и руководствую. Я сделаю все возможное, чтобы оставаться объективным в этом вопросе.
Кстати, Lokad был буквально создан для работы с вероятностным распределением спроса, и это не только вероятностное распределение спроса. Он также учитывает стохастическое распределение срока поставки, стохастическое распределение возвратов и многое другое. Мы должны рассматривать все возможные будущие с вероятностями, учитывая все виды неопределенностей. Спрос является очень важным, обычно самым важным, но это не единственное значение.
Я думаю, что я ответил на все вопросы. Просто проверяю, не пропустил ли что-то… Нет дополнительных вопросов. Так что, спасибо всем за просмотр этой лекции, и увидимся на следующей неделе, в тот же день, в то же время. До скорой встречи. До свидания.
Ссылки
- Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - By Joel Spolsky, 2004
