00:22 Введение
02:40 Почему продукт? Потому что капитализм
08:18 Что должен делать продукт?
10:05 Дисэкономия масштаба
12:50 Давайте купим готовый продукт для оптимизации цепочки поставок
21:58 Управление цепочками поставок vs оптимизация цепочки поставок
25:58 Интерлюдия
28:21 Продукт для оптимизации цепочки поставок – это не типичное программное обеспечение
33:26 Программные компоненты для оптимизации цепочки поставок
42:49 Однако таблицы не являются конечной целью
46:51 И Python тоже не является конечной целью
58:52 Цепочка поставок не является подразделением IT
01:03:19 В заключение, две задачи, которые предстоит преодолеть
01:07:04 Предстоящая лекция и вопросы аудитории
Описание
Цель инициативы количественной оптимизации цепочки поставок — либо запустить, либо улучшить программное обеспечение, которое автоматизирует ряд рутинных решений (например, пополнение запасов, обновление цен). Приложение рассматривается как продукт, подлежащий разработке. Теория цепочки поставок предназначена для того, чтобы помочь нам создать приложение, которое направляет компанию к достижению эффективности цепочек поставок, при этом удовлетворяя всем ограничениям, вытекающим из производства.
Полная расшифровка
Всем привет, большое спасибо за участие в этой серии лекций о цепочке поставок. Я Жоаннес Верморель, и сегодня я представлю тему «Продуктово-ориентированная доставка для оптимизации цепочки поставок».
Итак, когда я говорю о продукте, я имею в виду программный продукт. Для тех из вас, кто когда-либо имел привилегию заглянуть под капот современного корпоративного приложения, это может оказаться поистине захватывающим опытом.
Для тех, кто знаком с творчеством Г.Ф. Лавкрафта, существуют тревожные сходства. Лавкрафт написал серию романов, и одной из повторяющихся тем является идея запретного знания. Дело не в том, что вселенную нельзя познать — её можно познать. Просто единственное, что сохраняет человечество, — это неведение. Неведение не является проблемой; это именно то, что защищает нас от вселенной, слишком уж ужасающей для наших умов. Эта идея была переработана во многих современных играх, особенно в ролевых, где, помимо традиционных показателей здоровья, у персонажей есть показатель рассудка. Если вы совершаете определённые действия, наносящие вред вашему рассудку, вы теряете его баллы. Задача корпоративного программного обеспечения заключается в том, чтобы создать его, сохраняя при этом ваше здравомыслие, что является одним из требований для повышения ценности компании. Итак, продолжим.
Почему же продукт, и в частности – программный продукт? Давайте внимательно рассмотрим, как традиционно функционируют цепочки поставок. Раньше на местах работало множество людей, перемещая вещи, раскладывая посылки, управляя транспортными средствами и выполняя всю ручную работу. Кроме того, участвовало множество людей в производстве, а также в магазинах. Однако за последние пару десятилетий наблюдается стабильное сокращение числа рабочих с физическим трудом. Сегодня, в плане производства, многое автоматизировано. Остались лишь несколько отраслей, таких как текстильная, где всё трудно автоматизировать, поэтому эти отрасли переехали туда, где рабочая сила стоит дешевле. Фактически, требования к сырой рабочей силе значительно снизились.
В итоге возникает довольно странная ситуация: если взглянуть в будущее, когда автономные транспортные средства станут нормой, многие компании будут иметь больше офисных работников, работающих с таблицами Excel, управляющих цепочками поставок, чем рабочих с физическим трудом для выполнения ручных операций. Именно это я имею в виду, когда говорю о клерикальной работе.
Еще один своеобразный аспект заключается в том, что цепочки поставок для многих компаний оцифрованы уже не менее двух десятилетий. Дело не в том, что мы собираемся внедрять программное обеспечение в цепочки поставок; они уже управляются и эксплуатируются с помощью ПО. Но если мы рассмотрим роль человека в этих системах, оказывается, что люди буквально используются в качестве сопроцессоров в типичной системе цепочки поставок. Существуют определенные виды операций, которые обычный ЦПУ, процессор машины, выполнить не может, и поэтому вся задача делегируется человеку. В сочетании с упрощёнными числовыми методами, такими как ABC-анализ, учёт по методу мин-макс и другими подобными методиками, люди в итоге тратят свои дни на устранение непредвиденных ситуаций. Они постоянно сталкиваются с исключениями и условиями, которые не вписываются в стандартную схему.
С точки зрения затрат, всё это относится к операционным расходам (OpEx). Каждый день вы должны оплачивать работу целой армии клерков, чтобы они принимали все рутинные решения, необходимые вашей компании. К ним относятся вопросы о том, что покупать, где размещать запасы, перемещать ли единицу товара из одного склада в магазин, а также многие другие повседневные решения. Люди принимают эти решения и борются с проблемами, возникающими из-за неадекватности автоматически, наивно сгенерированных системой решений.
Мое предложение для вас сегодня заключается в том, что мы хотим перейти от операционных расходов (OpEx) к капитальным затратам (CapEx). В этом и заключается суть подхода, ориентированного на продукт. Мы хотим создать актив, а почему? Потому что это соответствует капиталистической логике. Если взглянуть на 100 самых прибыльных компаний в мире, то половина из них по прибыли является компаниями-разработчиками программного обеспечения. Они представляют собой суть ультра-капиталистических компаний, где вы вкладываете средства заранее, а затем получаете устройство или артефакт, который генерирует дополнительную стоимость при минимальных дополнительных вложениях.
Возвращаясь к теме моей предыдущей лекции, нам нужна роботизация, чтобы вернуть управление в руки руководства. Автоматизация и люди должны работать вместе; люди не должны заниматься устранением недостатков глупых политик управления запасами, таких как метод мин-макс. Вместо этого они должны приносить ценность, совершенствовать числовые алгоритмы и выступать в роли стратегов. Существовал старый девиз IBM: “Машины должны работать; люди – думать.” Именно такое мышление лежит в основе этой презентации. Мы хотим превратить цепочку поставок в капиталистический актив, и для этого нам нужно превратить цепочку поставок в машину, которая поставляет программный продукт.
Что же на самом деле делает этот продукт? Оказывается, он делает довольно простую вещь: принимает решения. Не произвольные, неограниченные решения, а рутинные, повседневные, такие как что производить, сколько единиц купить у поставщика и сколько единиц переместить с одного места на другое. На первый взгляд может показаться, что в управлении цепочками поставок задействовано много решений. Однако, если пересмотреть задачи, то даже в самых сложных цепочках поставок требуется всего несколько десятков типов решений ежедневно. Это не ошеломляет, и вполне разумно с точки зрения количества функций. Что интересно, эти решения в основном взаимно исключающие, поэтому существуют ограничения на то, что можно сделать с помощью подхода «разделяй и властвуй». Как только вы решили купить 100 единиц у поставщика, невозможно, чтобы другая подсистема решила купить вместо этого 200 единиц. В какой-то момент вы должны окончательно определиться с количеством единиц для покупки и перемещения с одного места на другое. Эти решения являются дискретными, ограниченными по охвату и в значительной степени взаимоисключающими. Что мы хотим, так это программное обеспечение, которое генерирует решения по заказам полностью автоматически каждый день.
Одно, что, по моему мнению, часто неправильно понимается в отношении программного обеспечения, — это понятие дисэкономии масштабов. В то время как экономия от масштаба знакома большинству, в программном обеспечении всё наоборот: добавление четверти функций может удвоить затраты. Эта концепция объясняет, почему небольшие стартапы могут конкурировать с крупными компаниями — благодаря тому, что они фокусируются на меньшем количестве функций, затраты на вывод продукта на рынок могут быть значительно ниже, чем у большой компании.
Имея в виду концепцию дисэкономии масштабов, мы должны решить: строить ли продукт самостоятельно, покупать его или выбрать иной подход для нашего продукта оптимизации цепочки поставок. Если мы решим купить продукт у поставщика, нам придётся учитывать функции, которые поставщик программного обеспечения должен обеспечить для удовлетворения рынка.
Итак, давайте рассмотрим вариант покупки готового продукта оптимизации цепочки поставок. На этих слайдах я представляю обзор лишь крошечной части всех вопросов, которые нам необходимо решить. У меня есть личный опыт в этом: когда я основал Lokad в 2008 году, я начинал с небольшого программного продукта, ориентированного скорее на прогнозирование, чем на оптимизацию цепочки поставок. По мере работы с клиентами я понимал, что существует так много функций и возможностей, которых у меня не было, а с переходом к новым клиентам обнаруживалось ещё больше недостающих возможностей. Это казалось бесконечным процессом выявления новых требований.
Давайте рассмотрим лишь основные функции. Во-первых, существуют компании, работающие по моделям B2C или B2B, которые демонстрируют совершенно разные схемы управления цепочками поставок. Например, компании B2B обычно имеют меньше клиентов, но эти клиенты заказывают значительно большие объёмы. Это создаёт различные виды рисков, такие как риск потери одного клиента, который составляет значительную долю оборота компании. Затем есть более сложные бизнес-модели, такие как B2B2C или B2B2B.
Рассмотрим различные типы объектов, которые необходимо учитывать, такие как магазины, склады и производственные площадки. Каждый тип объекта сопровождается своими проблемами. Магазины, например, подвержены неточностям в учёте запасов, даже с технологией RFID, просто потому что покупатели могут перемещать товары. Склады и производственные площадки, такие как фермы или горнодобывающие предприятия, имеют свои специфические проблемы и неопределённости в выходе продукции.
Сети цепочек поставок могут иметь различные уровни, или эшелоны, от одноуровневых до многоуровневых систем. Сложность управления цепочкой поставок существенно возрастает с увеличением числа эшелонов. Ещё один важный аспект — топология сети. Дерево — это классическая прямая цепочка поставок, где несколько производственных площадок направляют товары на несколько складов, которые далее распределяют их между многочисленными магазинами. Однако могут существовать и другие топологии, такие как ориентированные ациклические графы (DAG), где один магазин может обслуживаться несколькими складами.
То есть, в принципе, это не просто дерево в смысле графов, оно может реорганизовываться, хотя направление остается только прямым. Но то же самое может происходить с направленным ациклическим графом (DAG), когда имеется несколько поставщиков. В графе цепочки поставок даже могут возникать циклы, если речь идет о ремонте. Например, в горнодобывающей или авиационной отраслях существует множество циклов ремонта для ремонтируемого оборудования.
Теперь, сами запасы имеют не одну природу; они сильно различаются. Нельзя просто сказать: “О, у меня есть эта идея, что у меня есть SKU и всё на этом.” Нет, не совсем, потому что, во-первых, у вас есть сырьё, которое измеряется в таких единицах, как граммы, килограммы или объём. Затем есть готовые единицы, которые представляют собой удобные, чёткие единицы, наиболее распространённые. Но также может быть множество запасов, которые часто обновляются, например, в фармацевтике или пищевой промышленности, где партия сопровождается конкретными сроками годности. Кроме того, может быть совершенно сериализованный инвентарь, где каждая единица имеет свой серийный номер. С точки зрения оптимизации цепочки поставок, это полностью меняет ситуацию, так как каждая из этих категорий представляет собой совершенно различную задачу.
Затем, очевидно, возникают все проблемы маркетплейсов. В Lokad у нас клиенты, находящиеся буквально в каждой возможной ситуации. Есть клиенты, которые продают через сторонние маркетплейсы, есть у которых есть собственный маркетплейс, или и то, и другое. Это может быть что-то второстепенное, что они используют для ликвидации непроданных товаров. Ситуаций очень много.
Теперь, просто для примера, задумайтесь, что такое заказ. Существует спотовый заказ, когда вы просто покупаете что-то прямо на месте, и оно ваше. Но также может быть заказ, который говорит: “Я это покупаю, но не хочу, чтобы товар доставлялся немедленно; я хочу, чтобы он был доставлен через месяц”. Очевидно, с точки зрения оптимизации цепочки поставок, это совершенно другая ситуация, потому что если вы знаете заранее, что вам придётся доставить определённое количество товаров на конкретную дату, вы не хотите прогнозировать это, поэтому это совершенно иное.
А потом есть заказ с конфигурацией, например, когда вы покупаете компьютер онлайн и можете выбрать, сколько памяти, какой объём жёсткого диска, какую операционную систему установить, на каком языке будет работать компьютер, а также выбрать клавиатуру, помимо прочего. Таким образом, может существовать огромный конфигуратор, что снова меняет ситуацию. Это также происходит с такими товарами, как велосипеды или автомобили, и полностью меняет картину, поскольку предоставляет вам варианты и возможности для рассмотрения проблемы оптимизации цепочки поставок, которые совершенно не похожи друг на друга.
Даже для цен возможна единая, предельно простая и линейная цена за единицу, но это не всё. Можно сделать ценовые уступки, например, если покупаете десять единиц, получаете скидку. Или можно внедрить программы лояльности, когда некоторые клиенты с картой лояльности получают скидку, но только на определённые виды товаров или при соблюдении определённых условий. А в B2B можно даже часто проводить переговоры, так что это буквально транзакция, в которой продаётся множество вещей, при этом у вас есть обычная каталожная цена. Однако поставщик может предоставить скидку клиенту, потому что он важен, и так всё и делается. Короче говоря, я только начал говорить, и уже затронул только суть. Я даже не начал касаться основных обязательных моментов. Поэтому остановитесь на мгновение и подумайте, как должен выглядеть готовый корпоративный программный продукт, предназначенный для оптимизации цепочки поставок. Количество функций, которые нужно охватить, просто безумно, и когда вы пытаетесь собрать всё это в один монолит, вы буквально сходите с ума. Мы возвращаемся к идее, что дело не в том, что вселенная непознаваема, а в том, что если вы столкнётесь с обнажённой правдой вселенной, то потеряете рассудок.
Итак, у нас возникла серьезная проблема, и здесь необходимо различать управление цепочкой поставок и оптимизацию цепочки поставок. Это различие я уже упоминал в одной из предыдущих лекций. Существует большое заблуждение относительно управления и оптимизации. Управление связано с бухгалтерским учетом, поддержкой рабочих процессов и, в основном, с процессами ввода данных. Если вы хотите представить всё то, о чем я только что говорил, это огромный объем работы, но это осуществимо. «Ожирённая» система ERP справится с этим. Да, в итоге у вас получится 10 000 таблиц, это будет довольно некрасиво, но возможно. Однако не заблуждайтесь, ERP (которую следовало бы назвать ERM, Управлением корпоративными ресурсами) не сделает многого. Она просто будет отслеживать эти процессы. Таким образом, у вас будет масса сущностей – MOQ, галочка; ценовые уступки, галочка; магазины, галочка; склады, галочка – но никакого интеллекта не требуется. Всё сводится к обычным цифровым аналогам, отражающим данные, что позволяет вводить их в систему, и всё.
Это возможно, потому что здесь можно немного обойти правило «на четверть больше функций – двойная стоимость». Есть одна вещь, о которой я особо не говорил: это работает, если вы полностью разделяете функции. Пока функции не взаимодействуют друг с другом, все в порядке; вас не затрагивает проклятие ухудшения эффектов от масштабирования. С точки зрения ввода данных проблем нет. Вам не нужен пользовательский интерфейс, позволяющий управлять MOQ, связанными с чем-либо, что позволяет добавить дополнительный магазин в сеть. Эти две вещи могут быть полностью раздельными.
Однако в случае оптимизации цепочки поставок то же самое не работает. Если у вас есть MOQ, они окажут глубокое влияние на то, как часто вы размещаете заказы, и как часто вы будете доставлять товары со склада в магазины. Это влечет за собой множество далеко идущих последствий. Невозможно разделить эти процессы, потому что в конечном итоге ваша цепочка поставок представляет собой единую систему, где всё влияет на всё. С точки зрения оптимизации цепочки поставок у вас буквально возникает проблема: все эти компоненты должны быть интегрированы, чтобы обеспечить оптимизацию, и вот здесь всё разваливается.
Со стороны управления в итоге можно получить продукт. Однако для оптимизации цепочки поставок ответ таков: это невозможно. То есть можно создать видимость продукта, но на деле не получится. Даже в компании Lokad, которая начиналась не как компания, специализирующаяся на предсказательной оптимизации цепочки поставок, а как сервис прогнозирования. Если вернуться к блогу Lokad в 2008 году, я начинал с прогнозирования временных рядов, что оказалось серьезно ошибочным. Тем не менее, именно так я и начал. Даже прогнозирование временных рядов, которое является лишь малой долей всей проблемы, оказывается неуправляемым. Вот мой вывод после более чем 12 лет в этом бизнесе.
Если мы вернёмся к специфике создания программного обеспечения, это нечто совершенно уникальное. Если вы не обучались как инженер-программист и не знакомы с тем, как разрабатывают ПО крупные, успешные компании, скорее всего, вы знаете об этом очень мало. Оказывается, это совершенно специфическая область со множеством крайне контринтуитивных аспектов. Традиционным компаниям, особенно тем, кто придерживается классического мышления механических инженеров или маркетологов, чрезвычайно сложно понять, как вообще работает ПО.
Мы рассмотрим эти аспекты более подробно в будущих лекциях, но есть одна книга, которая мне действительно нравится, написанная Джоэлом Спольски, бывшим сотрудником Microsoft, работавшим в ранних командах Microsoft Excel. Он также является соучредителем Stack Overflow и Trello. В 2004 году, когда я был всего лишь студентом, я прочитал его книгу и блог. Книга называется “Joel on Software”, и с юмором она дает представление о том, как выглядит управление успешным программным бизнесом. Это совсем не то, чего ожидают большинство людей за пределами этой индустрии. Я добавлю детали этой книги в описании видео.
Но не забывайте, что оптимизация цепочки поставок – это не обычный программный продукт. Обычно, когда вы работаете с обычным ПО – да, у него есть свои проблемные моменты, в зависимости от типа продукта. Если вы работаете с социальной сетью, множество людей могут публиковать оскорбительный контент, и это совсем другая история. Однако в случае традиционного корпоративного ПО, например, Microsoft Word или Excel, это продукт, в котором важен правильный дизайн, но никаких экстренных ситуаций нет. В случае традиционных программных продуктов нормально тратить годы на доработку дизайна и продукта. Это долгосрочные инвестиции, и нужно смотреть на десятилетия вперед. Нет никакой причины спешить с разработкой. Однако оптимизация цепочки поставок не работает так. Вы не можете сделать выбор, потому что события происходят постоянно, а условия крайне суровы.
Могут возникнуть экстремальные ситуации, такие как пандемия или другие проблемы, например, атаки программ-вымогателей, которые могут отключить половину вашей сети. Вам нужно принимать разумные решения, чтобы максимально использовать оставшиеся у вас ресурсы. Вы можете столкнуться с временной остановкой флота из-за трагических происшествий, с политическими мерами, такими как тарифы, нарушающие вашу стратегию, или с природными катастрофами, такими как цунами, пожары или аномально высокая жара, как в Калифорнии или Австралии. Эти события происходят, и когда они случаются, вам нужно уметь реагировать буквально в течение нескольких часов.
У вас есть ваш программный продукт, но вам нужно внести изменения, и вы хотите внести программные изменения. Помните, если вы мыслите в терминах предоставления программного актива, у вас есть небольшая команда, управляющая ПО, которое, в свою очередь, управляет вашей цепочкой поставок. У вас нет армии клерков, которые целый день тушат пожары. Даже если такая армия и есть, их нужно обучать, а когда случается что-то совершенно неожиданное, у вас оказывается армия, не подготовленная к этой конкретной ситуации. По моему опыту, чем больше людей вам приходится управлять, тем дольше достигаются результаты.
Всего несколько дней назад грузовое судно потеряло более 1800 контейнеров из-за плохих погодных условий. Такие вещи просто случаются, и вы не можете рассчитывать на их полное устранение. Цепочка поставок – это не производственный процесс, где у вас может быть площадка с жестким контролем за всем. По определению, цепочки поставок происходят в огромном мире, где большую часть времени вы не контролируете окружающие факторы. Существует так много сил, неподвластных вашему контролю, что вам нужно уметь справляться с неожиданными событиями. Вы уже знаете, что сюрпризы неизбежны, поэтому нужно быть готовым. Готовность – это не значит, что у вас всё четко спланировано; это значит, что у вас есть система, в которой вы можете отреагировать в течение нескольких часов, если потребуется. Вот суть того, как можно реалистично подойти к решению проблемы.
Теперь, что нам нужно с точки зрения компонентов программного обеспечения для оптимизации цепочки поставок? Во-первых, нам нужно универсальное хранилище данных, чтобы представить все разнообразные типы источников данных. Есть так много вещей, которые мы хотим отразить, поэтому нам нужно нечто очень универсальное в этом отношении, с большим количеством структуры и разнообразия.
Во-вторых, вам нужна программируемая логика. Я возвращаюсь к этой идее: если у вас нет программируемой логики, как вы справитесь со всеми этими проблемами? Как склеить всё это вместе? Вы не можете купить готовый продукт, в котором всё будет заранее запрограммировано для вас; это не работает.
Далее вам нужны универсальные пользовательские интерфейсы, потому что способ, которым вы хотите рассматривать свои проблемы, будет сильно варьироваться от одной ситуации к другой. Ключевые показатели эффективности (KPI) будут совершенно разными для каждой компании, поэтому вам нужен гибкий интерфейс, в котором вы можете представить цифры любым удобным для вас способом; в противном случае это станет большим ограничением.
Кроме того, вам нужны возможности для совместной работы, потому что цепочка поставок по определению подразумевает командную работу. В процесс вовлечено много людей, и он распределён, поэтому возможности для сотрудничества должны быть в центре внимания.
И, наконец, и возможно наиболее спорный момент — вам нужны программируемые возможности, доступные людям, которые не являются профессиональными инженерами-программистами. Это важно по нескольким причинам. Во-первых, на рынке немного квалифицированных разработчиков, поэтому их нанять очень сложно. Во-вторых, чтобы стать талантливым программистом, требуется огромное усилие и преданность делу, и одновременно быть специалистом по цепям поставок — это настоящий вызов.
Найти людей с двойной компетенцией в обеих областях не так уж часто. То же самое относится, если искать кого-то, кто одновременно и программист, и юрист, или программист и врач. Да, вы найдете некоторых людей с такими навыками, но сможете ли вы массово или надежно нанимать их каждый год, если вы крупная компания? По моему опыту управления Lokad в течение десяти лет, это просто не работает.
Вам нужен продукт, который можно программировать, но для работы с ним не обязательно быть профессиональным инженером-программистом. Помните, вам нужен человек со знаниями в области цепочек поставок, потому что вам нужно уметь в течение нескольких часов вносить программные корректировки в систему, не открывая тикет и не передавая всё в IT. Если делать это таким способом, решение проблем занимает недели, а не часы. Так что, какое программное обеспечение действительно может решить эту проблему?
Что ж, Excel может. Он не симпатичный и может не выглядеть вершиной современного ПО, но он выполняет свою задачу. Он удовлетворяет всем требованиям.
Универсальное хранилище данных? Да, в определенной степени вы можете разместить огромное количество данных любого типа в Excel. Программируемая логика? Безусловно, Excel полностью программируемый. Универсальный пользовательский интерфейс? Да, вы можете строить столбчатые диаграммы, линейные диаграммы и множество способов представления данных. Что касается интерфейсов, он очень универсален. Может, он и не самый отточенный, но по универсальности он многое может.
Что касается возможностей для совместной работы, они несколько примитивны. Существуют онлайн-версии Excel, которые немного лучше, но в основе своей вы можете делиться своими таблицами. Проблема нехватки функций для совместной работы не в том, что это десктопное приложение. Проблема в подходе, который присущ работе с таблицами, и который не подходит для интенсивного сотрудничества. Обычно, если у коллеги получилась очень сложная таблица, проще создать ее заново, чем пытаться понять, что он сделал. Таким образом, проблема нехватки возможностей для совместной работы заключается в менталитете, присущем работе с таблицами, который изначально налагает сильные ограничения на сотрудничество.
Однако Excel полностью доступен для непрофессиональных разработчиков, и даже существует Visual Basic for Applications для более сложных задач. Что касается компонентов, Excel удовлетворяет всем необходимым требованиям, что, как я считаю, в значительной степени объясняет его операционный успех во многих цепочках поставок.
По моему опыту, большинство мировых цепочек поставок – от самых маленьких компаний до крупнейших, от тех, кто никогда не инвестировал ни цента в корпоративное ПО, до тех, кто вложил миллионы долларов в сложные корпоративные системы для оптимизации цепочки поставок – управляются с помощью Excel. Исключений очень мало. Иногда люди используют Excel для корректировки настроек min-max в другом ПО, но поддержка этих настроек поручается тем, кто работает с Excel.
Excel сегодня определяет мир цепочек поставок, и я считаю, что это не случайность. В своей основе таблицы фундаментально решают многие важные задачи. Многие другие варианты позиционируются как превосходящие, но по умолчанию терпят неудачу, если вы не умеете программировать. Если вы не умеете программировать, это означает, что когда вы столкнетесь с серьезной проблемой или экстренной ситуацией, у вас не будет шансов. Люди возвращаются к Excel в ситуациях, когда отсутствует универсальный пользовательский интерфейс или решение недоступно для непрофессионалов. Если только IT-команда может добиться результатов, люди сначала открывают тикеты и терпеливо ждут, но через три месяца, скорее всего, все вернутся к Excel, потому что это быстрее. Excel – это не конечная цель, но независимо от того, что мы предложим в качестве превосходной замены, оно должно удовлетворять всем требованиям.
Как мы можем что-то улучшить? Что касается универсального хранения данных, Excel хорош, но не очень масштабируем. Обработка миллионов строк становится проблемой, даже в современных версиях Excel, способных работать с миллионом строк. Проблемы с производительностью быстро возникают при работе в больших масштабах. Программируемая логика в Excel возможна, но она очень хрупкая и ненадежная. Если вы случайно внесете ошибку или баг в свою таблицу, отладка и поиск источника проблемы превращаются в настоящий кошмар. Логика бесконечно дублируется, что приводит к тысячам копий одной и той же логики, и поэтому становится сложно выявлять и исправлять ошибки.
Пользовательский интерфейс не идеален, поскольку он не полностью основан на веб-технологиях, а данные всегда переплетены с интерфейсом. Возможности для совместной работы существуют, но они запутаны. Сотрудничество должно происходить на уровне программируемой логики. Многие поставщики решений по оптимизации цепочек поставок предлагают совместную работу по итогам, например, ручную корректировку прогнозов и возможность участия для нескольких человек. Однако это неверный подход. Сотрудничество необходимо, но оно должно происходить на логическом уровне, на уровне программируемой логики. Excel очень доступен для людей, не являющихся разработчиками, но когда вы хотите сделать что-то немного более сложное, это становится вызовом. В управлении цепочками поставок мы хотим учитывать все возможные сценарии будущего, что означает работу с вероятностными прогнозами, случайными величинами и учетом неопределенности. Хотя это возможно в Excel, это достаточно сложно. Excel прост для выполнения базовых задач, но для более сложных ситуаций нужно стать мастером Excel.
Поддерживаемость имеет значение, ведь вы хотите создать актив, ценность которого будет расти со временем. В случае с таблицами это сложно добиться, и трудно создать что-то по-настоящему точное, по крайней мере в смысле программного продукта.
Актуальные модные темы на сегодня — ИИ и Python, и весь тот ажиотаж вокруг data science. Однако, для управления цепочками поставок, я считаю, что 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 для реального управления цепочками поставок возникают различные проблемы, такие как исключения из-за null-ссылок, ошибки из-за недостатка памяти и длительное время вычислений. Вы можете ожидать 20 минут, пока завершится операция, не зная, закончится ли она вообще или процесс нужно будет просто принудительно завершить и перезапустить. Я просто не знаю, поэтому вам нужно, чтобы у вас было очень точное представление о том, сколько времени это займет. Кстати, если вернуться к Excel, то в наши дни, когда операция занимает некоторое время, Excel предоставляет достаточно надежный индикатор, полоску прогресса, показывающую, сколько времени потребуется. Таким образом, вы хотите иметь систему, и это часть того, что я называю готовностью к производству. Вам нужно решение, которое будет работать автоматически, например, ночью или в рамках ночной пакетной обработки. Вам нужно что-то, что не требует, чтобы дата-сайентист постоянно наблюдал за процессом.
И снова, если у вас возникают проблемы с дата-сайентистами, вам нужна третья компетенция: эксперт по цепочкам поставок, специалист по программной инженерии и эксперт по науке о данных. Возможно, все эти три качества могут быть объединены в одном человеке, но удачи вам с наймом более одного такого специалиста в год, даже если вы большая компания, обладающая всеми этими навыками. Такое встречается крайне редко.
Таким образом, мы хотим иметь систему, которая будет совершенствоваться. Кстати, первое, что мы хотим улучшить — это защита в глубину. Атаки программ-вымогателей набирают обороты, и всякий раз, когда вы внедряете что-то программируемое в свою организацию, вы подвергаете себя риску вымогательства. Ведь как только у вас появляется программа, она может делать массу вещей, включая захват самой машины, на которой работает. Я знаю, что существует масса способов смягчить эти проблемы: можно использовать песочницу, вводить ограничения, предоставлять ограниченные права, и множество других способов. Тем не менее, когда у вас есть нечто вроде универсального языка программирования, ваша поверхность атаки, что является техническим термином, становится абсолютно огромной.
Таким образом, когда вы вставляете такой код, вы существенно увеличиваете свою уязвимость с точки зрения безопасности. И помните, что в обычном программном бизнесе код обычно проходит проверку коллег. Вы проверяете код, существует процесс ревью, кто-то пишет код, а затем коллега его проверяет, чтобы убедиться, что в нём нет никаких подвохов. Но если вернуться к тому, что программное обеспечение должно быть надежным, вы должны уметь реагировать в течение нескольких часов. С точки зрения оптимизации цепочек поставок, процесс проверки кода вам не подходит. Это просто несовместимо с задержками и экстренными ситуациями, с которыми вы столкнетесь.
Таким образом, вам нужно решение, которое обеспечивает защиту в глубину «из коробки». Затем вы хотите иметь систему с прозрачной производительностью, где, да, операции могут занимать время, но вы контролируете процесс. Вы должны заранее знать, сколько времени это займет. Если этого нет, то вы подвергаетесь множеству очень глупых проблем, например, у вас было двухчасовое окно для предоставления результатов, а вы опаздываете. И знаете что? Грузовики уже уехали. Слишком поздно. Поэтому нужно, чтобы это было предусмотрено.
То же самое касается прозрачных обновлений. Вот в чем прелесть Excel. Вам не нужно задумываться о его обслуживании. Microsoft заключила кровавый пакт десятилетия назад, согласно которому, если вы создали Excel-таблицу, любая следующая версия Excel, появляющаяся на рынке, сможет поддерживать ваши таблицы. И самое удивительное, если взглянуть на Excel сегодня, он поддерживает многие конкурирующие форматы от компаний, которых уже не существует. Вы все еще можете читать таблицы, созданные в Lotus Notes и подобных системах. Таким образом, ценностное предложение Microsoft заключается в том, что созданная вами логика будет работать вечно, и да, они будут совершенствовать Excel на протяжении десятилетий, но, знаете ли, всё уже предусмотрено. Этого не скажешь о переходе от Python 2 к Python 3; это был кошмар, занявший десятилетие. Так что Python хорош для многих задач, но представьте, что эти обновления могут происходить в самый неподходящий момент — во время самой тяжелой пандемии, самых жестких тарифов, самой серьезной чрезвычайной ситуации, а вам нужно, чтобы система работала. Вы не можете позволить себе простой в шесть месяцев только ради проведения обновления. Это несовместимо с оптимизацией цепочек поставок.
Итак, теперь нам нужно подумать: что, если мы действительно рассмотрим нечто, что можно спроектировать, учитывая специфику цепочки поставок? Это и станет темой следующей лекции.
Кроме того, цепочка поставок — это не подразделение ИТ. Когда я говорю о поставке, ориентированной на продукт, это не означает, что программное обеспечение является просто средством, а не целью. Вы не будете продавать свое ПО по лицензиям или за определенную плату, как, скажем, делает Microsoft. В этом видении, которое я излагаю на лекции, ИТ отвечает за основные практики, такие как то, что следует и чего не следует делать в плане безопасности, резервного копирования, основной инфраструктуры, сети, управления и синхронизации данных на уровне компании, а также за предоставление всей необходимой консультационной поддержки и наставничества.
Но идея в том, что за решения в цепочке поставок должна отвечать сама цепочка поставок. Она должна владеть всем механизмом, генерирующим эти решения, ведь это её основное право собственности. В предыдущей лекции я сказал, что определяет специалиста по цепочке поставок: это тот, кто владеет числовыми решениями, полученными в результате работы кода. Это не система, которая сама принимает решения; это числовые рецепты, записанные одним или несколькими специалистами по цепочке поставок, и эти специалисты коллективно владеют этими решениями. Они берут на себя ответственность за них, а задача цепочки поставок — обеспечить согласованность всех решений в компании. Если идет акция или масштабное маркетинговое продвижение, результаты должны быть готовы вовремя, чтобы их можно было реализовать. Вы не хотите оказаться в катастрофической ситуации, когда продвигаете что-то, находясь уже в ситуации, близкой к дефициту товара, когда тратите деньги на маркетинг чего-то, что вы даже не можете продать, потому что у вас нет запасов или производственных мощностей для своевременного изготовления или предоставления услуг.
Таким образом, у нас есть два подразделения с совершенно разными целями. В моем идеальном представлении о том, каким должен быть ИТ-отдел, ИТ-отдел — это не то звено, через которое проходят только заявки. Это не так работает. ИТ-отдел отвечает за основную инфраструктуру. Это то, что работает без сбоев всё время. Вы даже не задумываетесь об этом, так же как не замечаете работающий Wi-Fi; вы замечаете его, только когда он не работает. Хороший ИТ-отдел предоставляет всю инфраструктуру так, что о нем даже не вспоминаете. Вы даже не осознаете его существование, потому что оно просто работает, как ваши электронные письма, работающие безупречно, и так далее. Вот в чем суть качественного базового ИТ. И затем, ИТ — это те люди, которые приходят к вам и помогают внедрять практики, которые поддерживают вас. Программируемая логика может быть сложной, поэтому иногда, откуда еще взять наставничества, чтобы немного улучшить свои навыки программирования? Ответ прост: это должна быть функция ИТ. Они должны приходить не для того, чтобы сказать: «Мы напишем код за вас», а для того, чтобы провести консалтинг, чтобы вы смогли реализовать это самостоятельно. Они помогут вам с некоторыми концепциями, возможно, с тем, что является немного более техническим, чем должно быть. Иногда возникает случайная сложность, и ИТ приходит, чтобы поддержать вас. Но в основе своей они не должны делать работу за вас. Они должны быть наставниками и консультантами, чтобы никто не совершил фатальную ошибку, которая могла бы подвергнуть всю компанию риску, например, риску программ-вымогателей или другого системного риска с точки зрения ИТ.
В качестве проверочного теста, если ваше взаимодействие между ИТ и цепочкой поставок происходит через документы, где вы перечисляете спецификации или требования, это не является правильным способом построения хороших отношений между этими двумя подразделениями. Когда я говорю о хороших отношениях, я имею в виду те, которые действительно приносят ценность компании.
В заключение, перед нами стоят две задачи с традиционной стороны управления цепочками поставок, которая могла заниматься программированием, но лишь в рамках Excel-таблиц, даже не осознавая, что это уже форма программирования. Вам нужно преодолеть свои страхи. Вы должны поверить, что мир завтрашнего дня, ваше подразделение, будет отвечать за поставку продукта, функционирующего как программный продукт, и это огромные изменения. Да, но с этим можно справиться. Почему? Потому что если у вас есть правильные инструменты, то да, программа подразумевает программирование, но оно не является фундаментально и радикально сложнее, чем работа в Excel. Снова: сложность не в технических характеристиках инструмента; она кроется в сложности самой цепочки поставок.
Для части аудитории, возможно, больше относящейся к сфере науки о данных или ИТ, необходимо преодолеть самоуверенность. Я неоднократно наблюдал, как специалисты по данным (и я сам отношусь к этой категории) бывают чрезмерно уверены в своей способности довести прототип до стадии производства. Это сложно, и цепочки поставок могут внезапно дать сбой в самый неожиданный момент. Я могу вспомнить один случай, когда несколько лет назад мы начали сотрудничество с ведущей европейской компанией в области электронной коммерции автозапчастей. Мы занимались пополнением их запасов с помощью нашей технологии прогнозирования, предлагали рекомендации по пополнению запасов автозапчастей. На следующей неделе мы обнаружили, что все наши прогнозы оказались завышенными в два раза. Спрос удвоился. Случилось так, что их главный конкурент решил одновременно выйти на несколько рынков – буквально в тот момент, когда мы начинали строить прогноз, один из конкурентов вышел в эфир на всех национальных телеканалах и начал рекламировать свою услугу в интернете. Интересно, что мой клиент даже и не подозревал об этом, и у них были лучшие результаты по поисковой оптимизации. Они были более оптимизированы с точки зрения SEO, так что, по сути, люди видели телевизионную рекламу конкурента, но естественным образом не запоминали его название. Поэтому они обращались к Google и набирали «автозапчасти», пока не оказывались на сайте моего клиента. Чтобы продемонстрировать, насколько хорош Lokad, в первуюю неделю работы наши прогнозы оказались завышенными в два раза, и мы думали: «Что, черт возьми, происходит?» Нам пришлось пересмотреть все, ведь когда спрос удваивается, не все показатели увеличиваются вдвое; одни растут в 10 раз, а многие остаются неизменными.
Таким образом, всё сводится к тому, что нужно уметь быстро реагировать. Речь идёт о страхе и чрезмерной самоуверенности. Большое спасибо за уделённое время.
Сейчас я ознакомлюсь с вопросами, поступившими через чат.
Вопрос: Может ли программное обеспечение принять решение о том, у какого поставщика разместить дополнительный заказ в случае необходимости дополнительной поставки на завтра? Например, упаковки клубники по 200 грамм для офисов в Австралии могут поставляться 10 поставщиками, доставляющими один и тот же товар в распределительный центр в один и тот же день.
Абсолютно, и здесь нужно различать два аспекта: управление цепочкой поставок и оптимизацию цепочки поставок. С одной стороны – управление цепочкой поставок, которое буквально включает в себя все конвейеры извлечения данных, включая EDI, когда вы можете отправить электронный заказ поставщику без какого-либо участия человека. Таким образом, у вас есть электронный мост от начала до конца. Но с другой стороны, это означает, что на стороне оптимизации должна быть программа, работающая непрерывно в течение дня, которая в определённый момент может уведомить сторону управления, сказав: “Пожалуйста, выполните этот заказ”. А затем, со стороны управления, которую курирует ИТ, обеспечивается полное выполнение заказа. Речь идёт о чистой транзакционности; здесь отсутствует интеллектуальная составляющая. Вы получаете заказ с указанным количеством, и именно оптимизационная часть отвечает за то, чтобы при генерации определённого количества соблюдались все ограничения, такие как точный список поставщиков, имеющих право обслуживать эти товары, наличие у них запасов, а также за правильный выбор среди конкурирующих поставщиков и т.д. Может происходить множество процессов. Абсолютно, да, но нам необходимо буквально разделить рутинное выполнение транзакций, которое лежит на стороне управления цепочкой поставок, и включение оптимизационного компонента в тот момент, когда решается вопрос о повторном заказе.
Вопрос: Знаете ли вы, что в данный момент вы конкурируете с чемпионатами по киберспорту?
Нет, в данный момент я не конкурирую с этими чемпионатами по киберспорту, но это очень круто. Кстати, в Lokad мы часто играем в Dota 2, так что управленческая команда тоже принимает участие. Некоторые из наших сотрудников хотят играть в League of Legends, но как генеральный директор компании я категорически против.
Вопрос: Я заметил, что у многих компаний изначально нет ERP или WMS, и руководство занимается оптимизацией цепочки поставок.
Конечно. Оптимизацию цепочки поставок невозможно обойти с первого дня; вам приходится принимать такие решения. Оптимизация цепочки поставок существовала ещё до появления какого-либо программного обеспечения для управления цепочками поставок. Даже если вернуться на 60 лет назад, когда программного обеспечения не существовало, людям всё равно приходилось принимать решения. Таким образом, оптимизация цепочки поставок уже тогда была актуальна – люди делали это с помощью пера и бумаги. Если взглянуть на самые ранние труды по вопросам цепочки поставок, такие как Формула Уилсона, также известная как формула EOQ, она уже имеет вековую историю. Это явно предшествовало программному обеспечению. Так что да, оптимизация цепочки поставок – это то, что происходит с первого дня, независимо от того, используете ли вы программное обеспечение или нет.
Конечно, необходимо иметь надлежащие ИТ-системы, но это совсем другой образ мышления. Управление цепочкой поставок заключается в выполнении рутинных задач на высшем уровне, таких как ввод данных, возможно, с поддержкой штрих-кодов и прочего; это просто представление данных. Проблема в том, что люди хотят одного продукта, который обеспечит и управление цепочкой поставок, и её оптимизацию, и в итоге получается продукт, излишне сложный, обычно с множеством сбоев, и с такими нежелательными функциями, как оповещения и исключения, которых следует избегать. Я вернусь к этому в одной из последующих лекций.
Фактически, в наши дни внедрение WMS или ERP, если у вас его ещё нет, занимает всего несколько недель. Если же он уже имеется, то это может занять месяцы, если вам нужно отделить его от ваших управленческих решений.
Вопрос: Когда руководство бизнеса осознает, что пора перейти от отслеживания информации к оптимизации решений в цепочке поставок и в конечном итоге начать сосредотачиваться на оптимизации цепочки поставок?
Прежде всего, нужно осознать, что существует две проблемы, и один и тот же программный продукт никогда не сможет решать обе. Я считаю, что это великая иллюзия, и поставщики программного обеспечения в этой сфере вводят в заблуждение. Если взглянуть на крупнейших поставщиков ERP-систем, их посыл звучит как оптимизация цепочки поставок, но на деле всё, что они предлагают и выполняют, относится к управлению цепочкой поставок, что гораздо менее привлекательно, ведь здесь нет ни искусственного интеллекта, ни настоящего интеллекта. В мире программного обеспечения это называют CRUD-приложениями (создание, чтение, обновление, удаление). ERP-системы — это просто гигантские наборы CRUD-экранов, где каждый экран может создавать, читать, обновлять или удалять записи в реляционной базе данных, и всё. Проще говоря, 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-системах, я испытываю к ним большое уважение, особенно к тем продуктам AS/400 с командной строкой на старых мейнфреймах IBM. С точки зрения управления, они обычно справляются вполне достойно. Возможно, клиенты на самом деле ищут веб-интерфейс вместо командной строки, но повысит ли это производительность их сотрудников на местах? Я сомневаюсь. Командные строки с текстовыми терминалами могут быть невероятно быстрыми и эффективными, без отвлекающих деталей.
Таким образом, это довольно сложно, потому что нам приходится распутывать всю ту ерунду, которую навязывают наши конкуренты. Кроме того, нам нужно объяснить, что ERP не оптимизирует цепочку поставок и что не существует чего-то вроде ИИ или блокчейна – есть лишь классы статистических моделей. К сожалению, на этом этапе мы теряем большинство потенциальных клиентов. Это одна из причин, почему я веду эти лекции – потому что требуется много часов, чтобы разобраться в сути и объяснить, почему проблему следует смотреть так, как я её вижу.
Вопрос: Какую платформу вы порекомендуете для решения задачи планирования множества продуктов с вероятностным распределением спроса?
Ну, конечно, Lokad. Но имейте в виду, что, будучи генеральным директором Lokad и основным владельцем компании, я действительно нахожусь в конфликте интересов, когда даю своё мнение. Я глубоко убежден, что Lokad – это платформа, которая вам нужна, но, пожалуйста, поймите, что это также компания, которой я владею и которой управляю. Я сделаю всё возможное, чтобы оставаться объективным в этом вопросе.
Кстати, Lokad был буквально разработан для работы с вероятностным распределением спроса, и речь идёт не только о вероятностном распределении спроса. Он также учитывает стохастическое распределение сроков поставки, стохастическое распределение возвратов и многое другое. Нам нужно рассматривать все возможные сценарии с соответствующими вероятностями, учитывая все типы неопределенности. Спрос – один из самых важных факторов, зачастую самый важный, но не единственный.
Думаю, я ответил на все вопросы. Проверяю, не пропустил ли я что-нибудь… Вопросов больше нет. Итак, спасибо всем за просмотр этой лекции, до встречи на следующей неделе, в тот же день, в то же время. До скорой встречи. Прощайте.
Ссылки
- Joel on Software: И обо всем разнообразном и время от времени связанном с вопросами, представляющими интерес для разработчиков, дизайнеров и менеджеров, а также для тех, кто, по счастливой случайности или неудаче, работает с ними в том или ином качестве – Джоэл Сполски, 2004
