00:22 Введение
02:40 Почему продукт? Потому что капитализм
08:18 Что должен делать продукт?
10:05 Дисэкономия от масштаба в программном обеспечении
12:50 Давайте купим готовый продукт SCO с полки
21:58 Управление цепями поставок vs SCO
25:58 Интерлюдия
28:21 SCO — это не ваш обычный программный продукт
33:26 Ингредиенты программного обеспечения для SCO
42:49 Но таблицы не являются конечной целью
46:51 И Python тоже не является конечным решением
58:52 Цепочка поставок — это не отдел ИТ
01:03:19 В заключение, две проблемы, которые нужно преодолеть
01:07:04 Предстоящая лекция и вопросы аудитории
Описание
Цель инициативы Количественная оптимизация цепей поставок — либо внедрить, либо улучшить программное обеспечение, которое автоматизирует рутинные решения (например, пополнение запасов, обновление цен). Это приложение рассматривается как продукт, требующий инженерной проработки. Теория цепей поставок призвана помочь нам создать приложение, которое направит компанию к повышению эффективности цепей поставок, оставаясь совместимым со всеми производственными ограничениями.
Полная транскрипция
Всем привет, большое спасибо, что присоединились к этой серии лекций по цепям поставок. Я — Жоанн Верморель, и сегодня я представлю «Ориентированную на продукт доставку для оптимизации цепей поставок».
Итак, когда я говорю о продукте, я имею в виду программный продукт. Для тех из вас, кто имел возможность заглянуть под капот современного корпоративного программного обеспечения, это может быть весьма впечатляющим опытом.
Для тех, кто знаком с творчеством Г.Ф. Лавкрафта, существует тревожное сходство. Лавкрафт написал ряд романов, и одной из повторяющихся тем является идея запретного знания. Дело не в том, что вселенную нельзя понять — её можно понять; просто единственное, что сохраняет человечество, — это невежество. Невежество не является проблемой; наоборот, оно защищает нас от вселенной, слишком уж устрашающей для нашего ума. Эта идея нашла отражение во многих современных играх, особенно в ролевых, где, помимо обычных очков здоровья, у персонажей есть очки рассудка. Если вы совершаете определённые действия, наносящие ущерб вашему рассудку, вы теряете очки рассудка. Проблема корпоративного программного обеспечения заключается в создании его с сохранением вашего рассудка, что является одним из требований для создания добавленной стоимости для компании. Итак, продолжим.
Почему же продукт, и в частности, программный продукт? Давайте внимательно рассмотрим, как традиционно работают цепи поставок. Раньше было много людей на местах, которые перемещали вещи, перегружали посылки, водили транспорт и выполняли всю ручную работу. Кроме того, огромное число людей было задействовано в производстве и в магазинах. За последние десятилетия число рабочих с «синей галошей» неуклонно снижалось. В современном производстве практически всё автоматизировано. Некоторые отрасли, такие как текстильная, всё ещё сложно полностью автоматизировать, поэтому они перемещаются туда, где рабочая сила дешевле всего. Факт остаётся фактом: потребность в сырой рабочей силе значительно сократилась.
В итоге получается довольно странная ситуация: если взглянуть в будущее, где автономные транспортные средства уже на повестке дня, то у многих компаний будет больше офисных работников, занятых работой с таблицами Excel для управления цепью поставок, чем «рабочих» на местах для выполнения ручного труда. Именно об этом я говорю, когда упоминаю клерикальную работу.
Ещё один странный момент заключается в том, что цепи поставок многих компаний оцифрованы уже как минимум два десятилетия. Дело не в том, что мы собираемся внедрять программное обеспечение в цепи поставок — они уже управляются и эксплуатируются с помощью ПО. Но если мы взглянем на роль людей в этих системах, то увидим, что люди буквально используются в качестве совместных процессоров в типичной системе управления цепочкой поставок. Существуют операции, которые обычный процессор не может выполнить, и поэтому за выполнение всей задачи отвечают люди. В сочетании с примитивными числовыми методами, такими как ABC-анализ, инвентаризация по методу min-max и подобными методиками, люди в итоге проводят дни, решая внештатные ситуации. Они постоянно имеют дело с исключениями и условиями, которые не укладываются в стандартную схему.
С точки зрения затрат, всё это относится к операционным расходам (OpEx). Вам приходится ежедневно платить целой армии клерков, чтобы решать все рутинные задачи, которые ваша компания вынуждена принимать. Сюда входят решения о том, что покупать, где хранить запасы, стоит ли перемещать единицу товара из одного склада в магазин, и многие другие повседневные решения. Люди принимают эти решения и постоянно занимаются устранением сбоев, чтобы справиться с недостатками наивно генерируемых системой автоматических решений.
Мое предложение для вас сегодня состоит в том, чтобы перейти от операционных расходов (OpEx) к капитальным затратам (CapEx). В этом и заключается суть ориентированной на продукт поставки. Мы хотим создать актив, и зачем? Потому что это капиталистично. Если вы посмотрите на топ-100 самых прибыльных компаний в мире на сегодняшний день, то увидите, что половина из них по прибыли — это компании, занимающиеся программным обеспечением. Они олицетворяют суть ультра-капиталистических компаний, где сначала требуется вложение, а затем возникает устройство или артефакт, который генерирует добавленную стоимость при минимальных дополнительных затратах.
Возвращаясь к теме моей предыдущей лекции, нам нужна роботизация, чтобы вернуть управление в руки руководства. Автоматизация и люди должны работать вместе; присутствие людей не должно быть продиктовано необходимостью компенсировать недостатки глупых запасных политик, вроде min-max. Вместо этого они должны приносить добавленную стоимость, совершенствовать числовые методы и выступать в роли стратегов. Существовал старинный девиз 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 на протяжении десятилетия, это просто не работает.
Вам нужно что-то программируемое, но для работы с программированием не обязательно быть профессионально подготовленным программистом. Помните, вам нужен специалист по цепочке поставок, чтобы можно было в течение часов вносить программные корректировки в систему без открытия заявки и передачи ее в ИТ. Если действовать таким образом, на решение проблем уйдут недели, а не часы. Итак, какой же программный продукт действительно сможет решить проблему?
Что ж, Excel может. Он не выглядит красиво и может не казаться вершиной современного программного обеспечения, но он справляется со своей задачей. Он удовлетворяет всем требованиям.
Универсальное хранилище данных? Да, в некоторой степени в Excel можно разместить множество данных любого типа. Программируемая логика? Абсолютно, Excel полностью программируемый. Универсальный пользовательский интерфейс? Да, вы можете строить гистограммы, линейные графики и использовать множество способов представления данных. Что касается пользовательских интерфейсов, он очень универсален. Возможно, он не самый отполированный, но в плане универсальности он может многое.
Что касается возможностей для совместной работы, они несколько примитивны. Существуют онлайн-версии Excel, которые немного лучше, но в основе всё сводится к тому, что вы можете делиться своими таблицами. Проблема недостатка функций для совместной работы не в том, что это настольное приложение. Проблема в менталитете, присущем электронным таблицам, который не подходит для интенсивного командного взаимодействия. Обычно, если ваш коллега создал очень сложную таблицу, проще создать её заново, чем пытаться понять, что было сделано. Так что проблема отсутствия возможностей для совместной работы кроется в менталитете, присущем таблицам, который по своей природе имеет серьезные ограничения для сотрудничества.
Однако Excel полностью доступен для людей, не являющихся разработчиками, и даже существует Visual Basic for Applications для более сложных задач. По всем параметрам Excel удовлетворяет всем требованиям, что, я считаю, во многом объясняет его операционный успех в большинстве цепочек поставок.
По моему опыту, большинство цепочек поставок в мире – от самых маленьких компаний до самых крупных, от тех, кто никогда не инвестировал ни цента в корпоративное ПО, до тех, кто вложил миллионы долларов в сложные системы оптимизации цепочек поставок – управляются с помощью Excel. Исключений очень мало. Иногда люди используют Excel для пересмотра настроек минимума и максимума в другом ПО, но обслуживание этих настроек поручается работникам, использующим Excel.
Excel управляет миром цепочек поставок сегодня, и я считаю, что это не случайность. В своей основе электронные таблицы решают многие ключевые вопросы. Многие другие варианты кажутся превосходящими, но по умолчанию терпят неудачу, если вы не умеете программировать. Если вы не можете программировать, значит, при столкновении с серьезной проблемой или чрезвычайной ситуацией вам не повезет. Люди возвращаются к Excel в ситуациях, когда отсутствует универсальный пользовательский интерфейс или когда решение недоступно для непрофессионалов. Если только ИТ-команда может решить проблему, сначала люди могут открывать заявки и ждать, но через три месяца почти все вернутся к использованию 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. Вам не приходится задумываться об его обслуживании. Microsoft заключила кровавый пакт десятилетия назад, который гласил: если вы создали таблицу в Excel, то любая следующая версия Excel, появившаяся на рынке, сможет её поддерживать. И самое поразительное то, что если присмотреться к современному Excel, он поддерживает многие форматы таблиц конкурентов, которые уже даже не существуют. Вы все еще можете открыть таблицы, созданные, например, в Lotus Notes и подобных системах. Таким образом, ценностное предложение Microsoft в плане прозрачных обновлений состоит в том, что созданная вами логика будет работать вечно, и да, Excel будет совершенствоваться десятилетиями, но, знаете что? Все уже предусмотрено. Это не то, что можно сказать о переходе с Python 2 на Python 3 — это был настоящий кошмар, занявший десятилетие. Так что Python хорош во многих отношениях, но представьте, что обновления могут происходить в самый неподходящий момент, когда наступает самая страшная пандемия, самый жесткий тариф или самая серьезная чрезвычайная ситуация, и вам нужно, чтобы все было готово и работало. Вы не можете позволить себе полугодовой простой только потому, что необходимо провести обновление. Это несовместимо с оптимизацией цепочки поставок.
Так что теперь нам нужно задуматься: что если мы действительно создадим решение, спроектированное с учетом особенностей цепочки поставок? Это станет темой следующей лекции.
Кроме того, цепочка поставок — это не отдел ИТ. Когда я говорю о поставке, ориентированной на продукт, это не означает, что программное обеспечение является лишь средством, а не целью. Вы не будете продавать своё программное обеспечение по лицензиям или за фиксированную плату, как, скажем, делает Microsoft. В этом видении, которое я представляю в этой лекции, ИТ отвечает за основные процессы — такие ключевые ИТ-практики, как то, что следует или не следует делать в области безопасности, резервного копирования, основной инфраструктуры, управления сетью, синхронизации и управления данными на уровне компании, а также за оказание всей необходимой поддержки и наставничества.
Но суть в том, что управление цепочками поставок должно контролировать решения, связанные с цепочками поставок. Они должны владеть всеми механизмами, генерирующими эти решения, ведь это их основная ответственность. В предыдущей лекции я говорил, что определяет специалиста по цепочке поставок: это тот, кто владеет числовыми решениями, созданными с помощью кода. Это не система, которая принимает решения; это числовые рецепты, записанные одним или несколькими специалистами по цепочкам поставок, и эти специалисты коллективно несут ответственность за эти решения. Они берут их в своё ведение, а задача цепочки поставок — обеспечить согласованность всех решений в компании. Если идет промоакция или масштабная маркетинговая кампания, все должно быть подготовлено вовремя, чтобы успеть запустить процесс. Вы не хотите оказаться в катастрофической ситуации, когда продвигаете продукт в момент, когда ситуация почти напоминает дефицит товара, и вы тратите деньги на маркетинг чего-то, что не можете продать из-за отсутствия запасов, производственных мощностей или возможности своевременного обслуживания.
Таким образом, у нас есть два подразделения с принципиально разными направлениями. В моем идеальном представлении того, каким должен быть ИТ-отдел, ИТ-отдел не занимается обработкой тикетов — это не тот формат работы. ИТ-отдел отвечает за основную инфраструктуру. Это то, что работает бесперебойно и слаженно всё время. Вы даже не замечаете его, так же как и 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, которой уже более века, становится ясно, что она предшествует программному обеспечению. Таким образом, оптимизация цепочки поставок – это то, что происходит с самого начала, независимо от того, есть у вас программное обеспечение или нет.
Конечно, сегодня необходимо иметь соответствующие IT-системы, но мышление совершенно иное. Управление цепочками поставок заключается в том, чтобы выполнять рутинные задачи на отлично, такие как ввод данных, возможно, с поддержкой штрих-кодов и других систем. Но это рутинные задачи, просто представление данных. Проблема в том, что люди хотят, чтобы система выполняла и управление, и оптимизацию цепочки поставок, и в итоге вы получаете продукт, который чрезмерно сложен, обычно содержит массу ошибок и оснащён ненужными функциями, такими как оповещения и исключения, которых лучше избегать. Я вернусь к этому в одной из следующих лекций.
По сути, сегодня внедрение WMS или ERP, если у вас их ещё нет, занимает всего несколько недель. А если система уже есть, то отделение её от процессов принятия решений может занять месяцы.
Вопрос: Когда руководство бизнеса осознает, что пора перейти от отслеживания информации к оптимизации решений по цепочке поставок и, в конечном итоге, начать уделять внимание оптимизации цепочек поставок?
Первое, что нужно понять — это то, что существует две проблемы, и один и тот же программный продукт никогда не сможет охватить оба направления. Я считаю, что это великая иллюзия, и поставщики программного обеспечения вводят в заблуждение в этой области. Если взглянуть на крупнейших поставщиков ERP, их посыл заключается в оптимизации цепочки поставок, но всё, что они на самом деле предоставляют, и все функции их продуктов относятся к области управления цепочками поставок, что гораздо менее привлекательно, поскольку здесь нет ни искусственного интеллекта, ни настоящего интеллекта. В мире программного обеспечения это известно как CRUD-приложения (Create, Read, Update, Delete). 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
