00:00:07 Важность проектирования программного обеспечения в современных цепях поставок.
00:01:22 Общие проблемы проектирования программного обеспечения в управлении цепями поставок.
00:02:37 Проблемы реального времени в программных системах в цепях поставок.
00:04:55 Как сложные операции могут влиять на системы реального времени.
00:07:13 Системы реального времени забиты не реальными операциями.
00:09:13 Важность выбора дизайна и временного масштаба в программном обеспечении для цепей поставок.
00:12:31 Различия между одноарендным и многопользовательским программным обеспечением.
00:14:11 Проблемы с несколькими версиями программного обеспечения в одноарендных приложениях.
00:15:33 Преимущества многопользовательского программного обеспечения и переход к моделям SaaS.
00:17:56 Важность понимания основных предположений в проектировании программного обеспечения для практиков в области цепей поставок.
00:19:18 Основные предположения дизайна Lokad, включая режим пакетной обработки и многопользовательский режим.
00:21:35 Заключительные мысли о понимании выбора программного обеспечения и его влиянии на будущие операции.
00:23:36 Заключительные мысли.
Резюме
В интервью с Жоаннесом Верморелем, основателем Lokad, обсуждается влияние проектирования программного обеспечения на оптимизацию цепи поставок. Часто возникают проблемы из-за проблем проектирования, а не из-за ошибок или сбоев, что может сделать программное обеспечение медленным, неинтуитивным и сложным в настройке. Обработка данных в реальном времени - это ключевая функция, которая может влиять на операции. Однако, фокусировка на быстрых и простых операциях может затруднить выполнение сложных процессов, таких как прогнозирование или анализ на уровне всей сети. Важно понимать предположения проектирования программного обеспечения, чтобы предотвратить проблемы, возникающие из несоответствия между дизайном программного обеспечения и намеренным использованием компании.
Расширенное резюме
В этом интервью ведущий Киран Чандлер обсуждает с Жоаннесом Верморелем, основателем Lokad, влияние проектирования программного обеспечения на операции компании, особенно в контексте оптимизации цепи поставок. Верморел подчеркивает важность проектирования программного обеспечения в современных цепях поставок, которые полагаются на несколько уровней программного обеспечения, таких как ERP-системы, MRP-системы, WMS-системы, OMS-системы и EDI-системы, для эффективной работы.
Проблемы, с которыми сталкиваются клиенты Lokad, часто возникают из-за проблем с проектированием их программного обеспечения, а не из-за очевидных ошибок или сбоев. Эти проблемы проектирования могут сделать программное обеспечение медленным, неинтуитивным, медленным и сложным в настройке. Как объясняет Верморел, эти проблемы часто возникают из-за несоответствия между основными проектными решениями, принятыми для программного обеспечения, и реальной реальностью цепи поставок, для которой оно предназначено.
Одной из ключевых особенностей архитектуры программного обеспечения, которая может повлиять на операции цепи поставок, является его способность обрабатывать данные в режиме реального времени. Верморел указывает на то, что хотя настоящая обработка данных в реальном времени невозможна из-за конечной скорости света, многие системы поставщиков цепи поставок разработаны для приближенной обработки данных в реальном времени. Например, когда товар берется с полки, программное обеспечение немедленно уменьшает уровень запаса. Однако такой подход в реальном времени может иметь непредвиденные последствия.
Когда программное обеспечение разработано для быстрых и простых операций, становится сложно выполнить более сложные операции, такие как прогнозирование или анализ на уровне всей сети. Эти сложные операции требуют более сложной обработки данных, которая может быть невозможна в системе, оптимизированной для обновлений в реальном времени в масштабе малых объемов.
Жоанн Верморел подчеркивает критическую важность проектирования программного обеспечения для оптимизации цепи поставок. Проблемы, с которыми сталкиваются клиенты Lokad, часто возникают из-за проблем проектирования, которые делают программное обеспечение медленным, неинтуитивным и сложным в настройке, вследствие несоответствия между основными проектными решениями программного обеспечения и реальной реальностью цепи поставок. Возможность обработки данных в реальном времени является одной из ключевых особенностей архитектуры программного обеспечения, которая может повлиять на операции цепи поставок. Однако, когда программное обеспечение разработано для быстрых и простых операций, становится сложно выполнить более сложные операции, такие как прогнозирование или анализ на уровне всей сети, требующие более сложной обработки данных.
Верморел объясняет, что проблемы, с которыми сталкиваются практики в области цепи поставок, использующие такое программное обеспечение, не всегда очевидны, так как они часто проявляются как медленное накопление проблем, которое он называет “смертью от тысячи порезов”.
Одной из ключевых проблем является необходимость функциональности в реальном времени в определенных сценариях, таких как сканирование товаров на высокоскоростном конвейере. Когда в систему вводятся операции, не работающие в реальном времени, общая производительность может быть отрицательно затронута, что приводит к замедлениям и задержкам. Это может привести к увеличению фрустрации среди пользователей и снижению эффективности.
Верморел подчеркивает важность правильного выбора основных проектных решений, которые должны глубоко соответствовать проблемам, которые программное обеспечение пытается решить. В контексте программного обеспечения для цепи поставок делаются различные основные предположения, и если они не выполняются, могут возникнуть проблемы в дальнейшем.
Временной масштаб, в котором работает программное обеспечение, является важным фактором. Верморел описывает различные типы программного обеспечения, необходимые для различных временных масштабов, начиная от времени отклика в субмиллисекундах для управления конвейерными лентами до долгосрочного планирования, включающего решения о размещении заводов на протяжении нескольких лет или даже десятилетий. Каждое увеличение временного масштаба требует другого типа программного обеспечения с уникальными возможностями.
В Lokad обычно фокусируются на временных масштабах от одного дня до одного года, что требует другого подхода к проектированию программного обеспечения. Верморел также касается различий между многопользовательским и однопользовательским программным обеспечением, что является важным аспектом для разработчиков программного обеспечения, хотя меньше известно большинству компаний.
Они обсуждают различия между многопользовательским и однопользовательским программным обеспечением, преимуществами модели SaaS и основными предположениями, которые определяют проектирование программного обеспечения Lokad.
Верморел объясняет, что многопользовательское программное обеспечение обслуживает нескольких клиентов, используя одну и ту же версию программного обеспечения, в то время как однопользовательское программное обеспечение предполагает предоставление каждому клиенту собственной настраиваемой версии. Lokad является многопользовательским, с одной базой кода, обновляемой еженедельно. Этот подход имеет несколько преимуществ, включая упрощенное версионирование и меньше проблем с безопасностью. Верморел сравнивает это с однопользовательским программным обеспечением, которое позволяет настраивать каждого клиента, но требует управления несколькими версиями, что приводит к операционным проблемам.
Он наблюдает, что за последнее десятилетие многие серьезные компании по разработке программного обеспечения перешли к многопользовательскому режиму. Для веб-приложений, таких как Lokad, многопользовательский режим довольно прост, но для программного обеспечения, работающего на клиентских машинах, это может быть более сложно. Одним из решений этой проблемы является стратегия “вечнозеленого” программного обеспечения, как в случае с Google Chrome и Microsoft Office 365. Эти приложения обновляются автоматически, без участия пользователя, тем самым устраняя проблемы, связанные с наличием нескольких версий одного и того же программного обеспечения.
При обсуждении архитектуры программного обеспечения Lokad Верморель подчеркивает важность понимания основных предположений поставщика. Он предупреждает относительно поставщиков, которые утверждают, что их программное обеспечение может делать все, и подчеркивает, что проектирование связано с компромиссами, имеющими как положительные, так и отрицательные аспекты. Он призывает потенциальных клиентов задавать поставщикам программного обеспечения вопросы о их основных предположениях и быть осторожными с теми, кто предоставляет только общие, положительные ответы.
Основные предположения архитектуры Lokad включают пакетный режим обработки, который Верморель объясняет выбранным, потому что он позволяет лучше оптимизировать и управлять ресурсами.
Одним из ключевых принципов является приоритет умных вычислений перед скоростью. Lokad предпочитает иметь точные и подробные вычисления, даже если это занимает больше времени, в отличие от более быстрых, менее точных вычислений. Программное обеспечение разработано для пакетной обработки, а не для реального времени, что позволяет более выразительный и мощный анализ.
Еще одним основным предположением является важность многопользовательского режима и использование возможностей, предлагаемых облачными вычислениями. Lokad стремится использовать возможности масштабирования, а не увеличения мощности, что означает использование нескольких меньших машин для обработки больших объемов данных вместо полагания на один мощный суперкомпьютер.
Верморель подчеркивает важность понимания основных предположений архитектуры программного обеспечения для практиков в сфере цепей поставок. Это понимание помогает предотвратить проблемы, возникающие из несоответствия между архитектурой программного обеспечения и предполагаемым использованием компанией. Поставщики могут утверждать, что их программное обеспечение универсально и подходит для различных ситуаций, но на самом деле определенные ограничения архитектуры могут затруднить его эффективность в некоторых приложениях.
Полный текст
Кирен Чандлер: Сегодня мы собираемся понять, как эти решения могут закрепить компанию в определенной нише, а также понять некоторые основные предположения, лежащие в их основе. Итак, Джоаннес, мы говорим немного о том, как плохой дизайн программного обеспечения может повлиять на компанию. Какие проблемы вы видите?
Джоаннес Верморель: Первая проблема заключается в том, что дизайн программного обеспечения имеет решающее значение для цепей поставок. Современные цепи поставок работают на программном обеспечении. У вас есть грузовики, машины, конвейеры, а также большие объемы программного обеспечения, такие как ваша система планирования ресурсов предприятия (ERP), система планирования материалов (MRP), система управления складом (WMS), система управления заказами (OMS), электронный обмен данными (EDI) и множество других слоев. Современные цепи поставок не могут функционировать без большого количества программного обеспечения. Когда я общаюсь с клиентами Lokad, они часто сталкиваются с проблемами, связанными с прикладным ландшафтом цепи поставок. Существует множество проблем, связанных с программным обеспечением, но они не всегда являются ошибками или сбоями. Проблемы с дизайном гораздо более распространены; они делают вещи медленными, неинтуитивными, медленными, и настройка системы занимает вечность. Когда вы пытаетесь провести анализ причин, вы часто видите, что проблемы на самом деле являются проблемами с дизайном программного обеспечения, где были приняты основные фундаментальные решения о дизайне программного обеспечения, и они полностью не соответствуют реальности интересующей цепи поставок.
Кирен Чандлер: Итак, какие особенности архитектуры программного обеспечения могут быть настолько важными? С какими проблемами вы сталкивались с вашими клиентами?
Жоанн Верморель: Давайте скажем, например, в реальном времени. Многие программные продукты для управления цепочкой поставок сегодня ориентированы на операции в реальном времени. Под реальным временем я имею в виду, что если вы решите взять одну единицу с полки, уровень запаса сразу уменьшится. Это кажется очень разумным. Однако, как только у вас есть такое программное обеспечение, которое разработано для работы в реальном времени, любые сложные вычисления будут вызывать большие проблемы. Причина в том, что если ваше программное обеспечение разработано для очень быстрых и простых операций, выполнение сложных операций, таких как прогнозирование или анализ на уровне всей сети, будет затруднительным. Это связано с тем, что ваше программное обеспечение разработано для очень быстрых и простых операций, и когда вам нужно обработать умеренно сложный объем данных, это будет сложно.
Кирен Чандлер: И если у вас есть большая детализированная версия, это замедлит всех, включая вещи, которые должны быть очень быстрыми, например, просто сканирование штрих-кода и звуковой сигнал. Я отсканировал, вы можете переходить к следующему товару. Насколько очевидны некоторые из этих проблем? Вы должны сочувствовать практику поставок. Я имею в виду, здесь происходит многое, и с этим программным обеспечением происходит многое под капотом. Так насколько очевидно, что некоторые из этих проблем существуют?
Жоанн Верморель: Это не очевидно, потому что обычно это не является очевидной ошибкой, которая приводит к сбою системы. Это больше похоже на смерть от тысячи порезов. Позвольте мне проиллюстрировать: у вас есть система, которая должна работать в режиме реального времени. Когда что-то сканируется на высокоскоростном конвейере, вы должны иметь возможность сканировать товары тремя товарами в секунду или что-то в этом роде. Вы должны быть действительно быстрыми и иметь время отклика в миллисекундах.
Итак, что происходит, если время от времени у вас есть вычисление, которое занимает несколько секунд вместо миллисекунд? Если у вас есть только одна операция, время от времени занимающая несколько секунд, и ваша система в реальном времени хорошо разработана, вероятно, большая часть других операций будет оставаться очень быстрыми, поэтому это не будет сильно влиять. За исключением случая, если вам не повезет и в то же самое время у вас есть, скажем, десять разных операций, которые занимают несколько секунд для вычисления. Это просто поглощает, в этот конкретный момент времени, все вычислительные ресурсы.
Итак, что произойдет, это то, что система, которая должна была сканировать и давать вам обратную связь в миллисекундах, внезапно займет одну секунду. Это не идеально, но с этим можно жить. Однако время от времени у вас возникает ситуация, когда вы ожидали мгновенной реакции, но внезапно возникает двух- или трехсекундная задержка. Кстати, иногда такое можно увидеть даже в местных супермаркетах. У вас есть касса, и сканирование товаров происходит очень плавно, но в какой-то момент они просто сканируют что-то, и проходит три секунды, а затем звуковой сигнал.
Здесь у вас есть система реального времени, которая была забита в нереальную операцию. Я не знаю, что это было, может быть, обновление Windows или какие-то странные вещи, которые происходят и замедляют работу машины. Но в системе реального времени вы не можете выполнять никакие умные или сложные операции, потому что это будет ухудшать работу сверхбыстрых операций, которые вы хотите выполнить.
Когда я говорю о смерти от тысячи порезов, это потому, что первый раз, когда вы выполняете нереальную операцию в системе реального времени, вероятно, ничего плохого не произойдет. Это редкость, поэтому вы в порядке. Но проблема в том, что вы накапливаете все больше и больше нереальных вещей, и внезапно эти проблемы, которые были очень редкими, начинают становиться все более частыми и частыми, пока они не становятся супер частыми. Тогда люди просто сходят с ума и говорят: “Почему этот конвейер не работает быстрее? Он мог бы.”
Ответ заключается в том, что есть машина, которая должна сканировать штрих-код, и нам нужно подождать, чтобы система ответила. Я видел ситуации, когда системе требовалось полминуты, чтобы ответить после сканирования штрих-кода. Это было связано с печатью чего-то, чтобы положить на коробку, но конвейер был ограничен скоростью, с которой система могла передать заказ на печать чего-то на коробке. Люди просто ждали, чтобы принтер что-то напечатал.
У вас есть множество вариантов дизайна, которые должны быть очень правильными, в тех аспектах, которые глубоко соответствуют проблемам, которые вы пытаетесь решить.
Кирен Чандлер: Какие ключевые основные предположения делаются в программном обеспечении для цепочки поставок, и какие из них, по вашему мнению, не работают на самом деле?
Жоанн Верморель: Есть много способов подойти к этому. Во-первых, рассмотрите временной масштаб, в котором вы хотите работать. У нас есть вещи, которые должны работать с временем от субмиллисекундного времени отклика, что вам нужно буквально для управления конвейерной лентой, до решений, где вам нужно думать о десятилетиях вперед, например, о размещении фабрик. Каждый раз, когда вы добавляете порядок величины, вы фундаментально меняете программное обеспечение.
Кирен Чандлер: Можете ли вы привести примеры разных временных масштабов и соответствующих типов программного обеспечения?
Жоанн Верморель: Конечно. Субмиллисекунда - это один тип программного обеспечения; от 1 до 10 миллисекунд - это будет другой тип программного обеспечения; от 10 до 100 миллисекунд - это будет еще один тип, который обычно является программным обеспечением ERP с временем отклика от 10 до 100 миллисекунд. От 100 миллисекунд до 1 секунды вы получаете то, что можно найти в веб-приложении. Затем, если вы начинаете думать от 1 минуты до 10 минут вперед, вы уже не находитесь в режиме реального времени, но можете начать делать сложные вычисления. Например, навигационное приложение, такое как Waze, должно предоставить маршрут в течение полуторы минут, но не обязательно в режиме реального времени.
Если вы оптимизируете маршрут для доставки грузовиков, вы можете потратить несколько минут на получение результатов, так как это не требует реального времени. В Lokad мы обычно сосредоточены на временных рамках от 1 дня до 1 года. Это наша зона комфорта, и это означает, что мы можем практически игнорировать все, что находится до этого. Если мы выходим за год, мы попадаем в область проектирования цепочки поставок, которая более ориентирована на карты и меняет проблему.
Кирен Чандлер: Давайте поговорим больше о реализации программного обеспечения. Какие ключевые различия между программным обеспечением для одного арендатора и множественного арендатора?
Жоанн Верморель: Разница между одним арендатором и множественным арендатором заключается в том, скольким клиентам вы обслуживаете с помощью одного и того же программного обеспечения. Если вы являетесь множественным арендатором, как Lokad, это то же самое программное обеспечение, обслуживающее всех наших клиентов. У нас всегда есть только одна версия, развернутая онлайн в любой момент времени, и мы обновляем это программное обеспечение еженедельно. Другой способ, который был более распространен до появления SaaS, - это одиночный арендатор. Этот подход предполагает предоставление каждому клиенту собственной копии программного обеспечения, что часто приводит к настройке для крупных клиентов.
Создание программного обеспечения означает, что внезапно у вас появляется множество вариантов вашего программного обеспечения, которые случайно работают одновременно, что является большой операционной проблемой, потому что это означает, что если в одной версии произошла ошибка, вам нужно исправить эту версию, но вы должны убедиться, что ошибка также исправлена во всех остальных версиях. Кстати, это проблема, при которой у компаний-разработчиков программного обеспечения есть анти-экономия масштаба. Чем больше вы, тем больше проблем у вас с версионированием. Кстати, эта проблема очень сильно влияет на Oracle, например, с базой данных Oracle. У них есть множество сильно настроенных версий, оптимизированных для производительности. У меня нет секретной информации изнутри, но по общедоступной информации можно видеть, что буквально в некоторых отделах инженерии в Oracle они борются с тем, что у них есть множество вариантов программного обеспечения. Очевидно, у Oracle есть множество возможностей в области инженерии, но, тем не менее, это остается большой проблемой. Таким образом, одиночный арендатор дает вам возможность настраивать под каждого клиента, но затем вам приходится иметь дело с накладными расходами на каждого клиента. Множественный арендатор дает вам возможность иметь одну кодовую базу для всех, без настройки, но взамен вы можете развиваться намного быстрее и также иметь гораздо меньше проблем с безопасностью.
Кирен Чандлер: Когда вы говорите, что рынок все больше движется в сторону такой модели SaaS, почему именно эта модель лучше? Обеспечивает ли она большую гибкость для компании?
Жоанн Верморель: Да, за последнее десятилетие практически все серьезные поставщики программного обеспечения перешли к многопользовательскому режиму, даже классические традиционные настольные приложения. Потому что, очевидно, если вы веб-приложение, как, например, Lokad, то быть многопользовательским довольно просто. Вы просто развертываете все на своих собственных системах, и все готово. Очевидно, когда у вас есть программное обеспечение, которое работает на клиентских машинах, например, веб-браузер, Internet Explorer или Google Chrome, это сложнее, потому что у вас нет контроля над клиентскими машинами. Но догадайтесь, что сделали поставщики программного обеспечения? Они перешли к стратегии “вечнозеленого” программного обеспечения. Например, Google Chrome больше не спрашивает вас о обновлении браузера. Когда Google решает, что ваша версия Chrome устарела и должна быть заменена, Google обновляет ваш браузер удаленно. Очевидно, в следующий раз, когда вы подключаетесь к Интернету и тому подобное, они не могут волшебным образом обновить ваше программное обеспечение, если у вас нет подключения к Интернету. Но предполагая, что у вас есть подключение к Интернету и вы не сделали никаких специфических штук с вашей машиной, чтобы предотвратить обновление, обновление произойдет практически без вашего вмешательства. И когда вы смотрите на то, что делает Microsoft с Office 365, это то же самое. Раньше у вас был ряд версий Microsoft Office, когда вы переходили от одной версии Excel к следующей. В настоящее время это происходит по требованию, и Microsoft заботится об обновлении. У вас есть подписка, программное обеспечение установлено на вашей машине, но оно может само обновиться до следующей версии. И если вы просто позволите этому произойти, если вы не отключили опции обновления, Microsoft просто обновляет все настольные приложения, чтобы уменьшить проблему наличия множества версий одного и того же программного обеспечения.
Кирен Чандлер: Давайте поговорим немного о Lokad. Вы сказали, что есть определенные основные предположения, которые необходимо сделать при проектировании программного обеспечения, и которые могут серьезно повлиять на будущую работу. Так какие основные предположения вы сделали здесь, в Lokad?
Жоанн Верморель: Их множество, но прежде чем я перейду к основным предположениям, я хотел бы сделать замечание. Если вы встретите поставщика программного обеспечения, который
Кирен Чандлер: Который говорит вам, что все мое программное обеспечение, вы знаете. Мы способны делать все, что мы не делали. Вы знаете, такое предположение о программном обеспечении. Если они дают вам только это, могу ли я предложить вам, знаете, когда вы встречаете поставщика программного обеспечения для вашей цепочки поставок, спросите их, какие основные предположения? И если они говорят вам что-то неопределенное, например, “мы разработаны для обеспечения безопасности”, отлично. “Мы разработаны для скорости”, да, я тоже. “Мы разработаны для экономии затрат”, да. Знаете, это такие наши супер неопределенные, абсолютно положительные вещи. Но когда мы говорим о проектировании, точка зрения проектирования - это компромисс. Это то, что имеет положительные и отрицательные аспекты. Поэтому, если вы можете обсудить с поставщиком программного обеспечения, и все, что они могут дать вам, это положительные аспекты, вероятно, они даже не понимают суть проектирования программного обеспечения в первую очередь. Итак, Жоанн, какие основные предположения в проектировании вы внедрили в Lokad?
Жоанн Верморель: Первое - это режим пакетной обработки. Что это означает? Это означает, что мы хотим иметь возможность обрабатывать огромные объемы данных и выполнять очень умные вычисления. Очевидно, потому что мы хотим быть очень умными, а не очень, очень быстрыми, что означает, что для нас имеет значение, чтобы вычисления выполнялись за несколько минут, но то, что они могут выполняться за несколько секунд, является своего рода бонусом. Но если мы не можем этого сделать, это не такая большая проблема. Мы предпочитаем иметь более точные числа, даже если это занимает некоторое время. Кстати, это не потому, что у нас есть наши части, которые смотрят на это время, это просто представление результатов. Так что, возможно, вам потребуется, скажем, полчаса, чтобы выполнить масштабные вычисления, но когда вы захотите получить доступ к этим результатам, они должны быть в режиме реального времени, но они уже предварительно вычислены. Так что вы видите, это было основное предположение в проектировании. Нет реального времени, только пакетная обработка. И причина в том, что мы хотим быть очень выразительными и очень мощными и, таким образом, быть такими умными, как только можно для, я бы сказал, всемирного анализа. Так что это одно из основных предположений. Еще одно предположение заключалось в том, что мы хотели иметь многопользовательский режим. Очевидно, в настоящее время большинство людей делают это, но все еще есть компании, особенно в корпоративном секторе, которые отстают. И я бы сказал, что многопользовательский режим реализован полностью.
Кирен Чандлер: Можете объяснить разницу между масштабируемостью и горизонтальным масштабированием?
Жоанн Верморель: Возможности, предлагаемые облачными технологиями, означают, что мы хотим иметь возможности горизонтального масштабирования, а не вертикального. Вопрос в том, если вы хотите обрабатывать терабайты данных, можете ли вы сделать это, накапливая тонны маленьких машин, или вам нужен суперкомпьютер для этого?
Кирен Чандлер: Итак, какой наш основной вывод сегодня?
Жоанн Верморель: Наш основной вывод заключается в том, что в отношении данных, которыми мы располагаем, и в отношении выбора программного обеспечения, это может очень сильно ограничить ваши будущие действия. Поэтому вам необходимо полностью понимать сделанные вами выборы.
Кирен Чандлер: Можете разъяснить это?
Жоанн Верморель: Мое предложение для практиков цепочки поставок - быть более осведомленными о базовых проектных предположениях, которые характеризуют их собственный прикладной ландшафт. У них есть много приложений, и они могут ли предоставить мне полдюжины критических кодовых предположений, которые объясняют суть продукта. Это может показаться очень техническим, но если вы не понимаете эти базовые проектные предположения, вы будете страдать, когда поймете, что пытаетесь сделать что-то, для чего этот продукт не подходит по своей природе. Часто я видел много компаний, где их проблемы возникают из-за несоответствия между дизайном программного обеспечения и тем, что они пытаются сделать с его помощью.
Кирен Чандлер: Можете привести пример?
Жоанн Верморель: Производители пытаются быть очень уверенными, вы знаете, как производитель, вы пытаетесь продать свое программное обеспечение. Вы хотите действовать уверенно и сказать клиенту, что ваше программное обеспечение для цепочки поставок будет хорошим во всех ситуациях, и мы покрываем вас. Но реальность заключается в том, что если клиент собирается использовать ваше программное обеспечение для чего-то, что выходит за рамки его возможностей, вы не можете просто приклеить к нему что-то. Вы не можете просто добавить функцию. Инженеры-программисты на заднем конце скажут вам: “Босс, извините, мы не можем это сделать. Это будет адом”.
Кирен Чандлер: Хорошо, давайте подведем итоги. Спасибо, Жоанн. Это все на этой неделе. Большое спасибо за внимание, и увидимся в следующий раз. Пока!
