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 или какой-то другой странной операцией, замедляющей работу компьютера. Но в системе реального времени не разрешается выполнять ничего сложного или интеллектуального, так как это ухудшает сверхбыстрые операции, необходимые для работы.
Когда я говорю о смерти от тысячи порезов, я имею в виду то, что первый раз, когда вы выполняете операцию не в реальном времени в системе реального времени, вероятно, ничего страшного не произойдет. Это редкость, так что вроде бы все в порядке. Но проблема в том, что вы накапливаете всё больше неопераций в реальном времени, и внезапно те проблемы, которые ранее возникали крайне редко, начинают появляться всё чаще и чаще, пока не станут почти постоянными. Тогда люди просто с ума сходят, спрашивая: “Почему этот конвейер не работает быстрее? Он мог бы.”
Ответ в том, что есть машина, предназначенная для сканирования штрих-кода, и нам нужно дождаться ответа системы. Я видел случаи, когда системе требовалось полминуты, чтобы ответить после сканирования штрих-кода. Речь шла о печати чего-то, чтобы наклеить на коробку, но конвейер ограничивался скоростью, с которой система могла передать заказ принтеру для печати на коробке. Люди просто ждали, пока принтер что-нибудь напечатает.
У вас есть множество вариантов проектирования, и ключевые решения должны приниматься правильно, так чтобы они глубоко соответствовали решаемым проблемам.
Kieran Chandler: Какие основные предположения закладываются в программное обеспечение для цепочки поставок и какие из них, по вашему наблюдению, на самом деле не работают?
Joannes Vermorel: Существует множество подходов к этому. Во-первых, рассмотрите временной масштаб, в котором вы хотите работать. У нас есть задачи, требующие отклика менее миллисекунды — как в случае с управлением конвейером — и задачи, когда необходимо думать на десятилетия вперед, например, при выборе места для фабрик. Каждый раз, когда вы увеличиваете порядок величины, вы принципиально меняете программное обеспечение.
Kieran Chandler: Можете привести примеры различных временных масштабов и соответствующих типов программного обеспечения?
Joannes Vermorel: Конечно. Операционные системы с откликом в доли миллисекунды — это один тип программного обеспечения; от 1 до 10 миллисекунд — другой тип; от 10 до 100 миллисекунд — еще один тип, который обычно представляет ERP-системы с откликом от 10 до 100 миллисекунд. От 100 миллисекунд до 1 секунды — это то, что можно найти в веб-приложениях. Затем, если вы начинаете думать в пределах от 1 до 10 минут, вы уже не работаете в реальном времени, но можете выполнять сложные вычисления. Например, навигационное приложение, такое как Waze, должно предложить маршрут за полминуты, но не обязательно в реальном времени.
Если вы оптимизируете маршрут для грузоперевозок, обычно можно потратить несколько минут на получение результатов, так как это не требует работы в реальном времени. В Lokad мы, как правило, ориентируемся на временные рамки от 1 дня до 1 года. Это оптимальный диапазон для нас, и это означает, что мы можем практически игнорировать всё, что происходит до этого. Если же период превышает один год, мы переходим в область проектирования цепочки поставок, которое становится более ориентированным на карту и изменяет саму суть проблемы.
Kieran Chandler: Давайте поговорим подробнее о реализации программного обеспечения. В чем заключаются ключевые различия между одноарендным и многоарендным программным обеспечением?
Joannes Vermorel: Разница между одноарендным и многоарендным заключается в том, сколько клиентов обслуживается одним и тем же программным обеспечением. Если вы многоарендны, как Lokad, используется одно и то же ПО для всех наших клиентов. В любой момент времени у нас развернута только одна версия, которую мы обновляем еженедельно. Другой подход, более распространенный до появления SaaS, — это одноарендное, когда каждому клиенту предоставляется своя копия программного обеспечения, что часто приводит к кастомизации для крупных клиентов.
Разработка программного обеспечения в итоге приводит к тому, что у вас появляется множество вариантов вашего ПО, работающих одновременно, что представляет собой большую операционную проблему, поскольку это означает, что если в одной из версий появляется ошибка, вам нужно исправить именно эту версию, а затем убедиться, что ошибка исправлена во всех остальных версиях. Кстати, у софтверных компаний это часто приводит к эффекту антиэкономии масштаба: чем больше вы, тем больше проблем с версионностью. Эта проблема очень сильно затрагивает, например, Oracle с их базой данных. У них множество сильно кастомизированных версий, оптимизированных для производительности. У меня нет секретной инсайдерской информации, но из общедоступных сведений видно, что буквально в нескольких инженерных подразделениях Oracle они сталкиваются с проблемой наличия множества вариантов программного обеспечения. Очевидно, что у Oracle огромные инженерные возможности, но тем не менее, это остается большой проблемой. Таким образом, одноарендная модель дает возможность индивидуальной настройки для каждого клиента, но затем приходится иметь дело со значительными накладными расходами на каждого клиента. Многоарендная модель предусматривает одну кодовую базу для всех, без кастомизации, но взамен вы можете развиваться гораздо быстрее и иметь намного меньше проблем с безопасностью.
Kieran Chandler: Когда вы говорите, что рынок все больше движется в сторону SaaS-модели, почему эта модель настолько лучше? Обеспечивает ли она большую гибкость для компании?
Joannes Vermorel: Да, за последнее десятилетие практически все серьезные поставщики программного обеспечения перешли на многоарендную модель, даже классические традиционные настольные приложения. Потому что, очевидно, если ваше приложение — веб-приложение, как Lokad, многоарендность реализуется довольно просто: вы просто разворачиваете обновления на своих серверах, и всё готово. Конечно, когда у вас ПО, работающее на клиентских машинах, например, браузеры вроде Internet Explorer или Google Chrome, ситуация осложняется тем, что у вас нет контроля над клиентским оборудованием. Но угадайте, что сделали поставщики ПО? Они перешли на стратегию evergreen. Например, Google Chrome больше не спрашивает вас об обновлении браузера. Когда Google решает, что ваша версия Chrome устарела и требует замены, обновление происходит дистанционно. Конечно, при отсутствии интернет-соединения обновление не произойдет волшебным образом, но если у вас есть интернет и вы не предприняли действий для блокировки обновлений, оно произойдет практически без вашего участия. И если посмотреть на то, что делает Microsoft с Office 365, ситуация аналогична. Раньше при переходе от одной версии Excel к другой у вас было несколько версий Microsoft Office. Сегодня всё происходит по запросу, и Microsoft сама заботится об обновлении. У вас есть подписка, программа установлена на вашем компьютере, но она может самостоятельно обновиться до следующей версии. И если вы просто позволите этому, если только не отключили возможности обновления, Microsoft обновляет все настольные приложения, чтобы минимизировать проблему множественных версий одного и того же ПО.
Kieran Chandler: Давайте немного поговорим о Lokad. Вы сказали, что существуют определенные базовые предположения, которые должны быть заложены в проектирование ПО и которые могут действительно повлиять на будущие операции. Так какие же базовые предположения вы сделали здесь, в Lokad?
Joannes Vermorel: Их масса, но прежде чем я перейду к основным предположениям, я хотел бы сделать замечание. Если вы встречаете поставщика программного обеспечения, который
Kieran Chandler: …говорит вам: “Все мое ПО, понимаете, мы способны на все, чего сами не сделали”. То есть, программное предположение. Если они рассказывают только об этом, можно предложить при встрече с поставщиком для вашей цепочки поставок спросить: “Какие основные предположения лежат в основе?” И если они говорят что-то расплывчатое типа: “Мы ориентированы на безопасность”, отлично. “Мы ориентированы на скорость” — да, и я тоже. “Мы ориентированы на экономичность” — да. Понимаете, это вроде как наши супер расплывчатые, абсолютно позитивные утверждения. Но когда мы обсуждаем дизайн, с точки зрения проектирования, это компромисс. Это то, что имеет как положительные, так и отрицательные стороны. Так что, если вы можете обсудить это с поставщиком, и всё, что он может вам предоставить — это исключительно положительные стороны, скорее всего, он даже не понимает сути проектирования ПО с самого начала. Так что, Joannes, какие основные предположения проектирования вы заложили в Lokad?
Joannes Vermorel: Первое — это режим пакетной обработки. Что это значит? Это значит, что мы хотим иметь возможность обрабатывать огромные объемы данных и проводить очень умные расчёты. Очевидно, что мы предпочитаем быть максимально умными, а не исключительно быстрыми, что означает, что для нас расчёты, которые обычно выполняются в течение нескольких минут, при этом если они выполняются за секунды, это приятный бонус. Но если не получится, это не такая уж большая проблема. Мы предпочитаем иметь более точные результаты, даже если это занимает немного времени. Кстати, это не потому, что у нас возникают задержки, это просто способ представления результатов. Возможно, для проведения масштабного расчёта потребуется полчаса, но когда вы захотите получить доступ к результатам, они должны быть в реальном времени, так как они предварительно вычислены. Таким образом, это было одно из основных проектных предположений: не в реальном времени, а пакетная обработка. Причина в том, что мы хотим быть максимально выразительными и мощными, чтобы быть настолько умными, насколько это возможно для анализа на мировом уровне. Это одно ключевое предположение. Другое предположение заключалось в том, что мы хотели использовать многоарендность. Очевидно, что в наши дни большинство придерживается этого подхода, но все еще есть компании, особенно в корпоративном сегменте, которые отстают. И я бы сказал, что многоарендность реализована во всей полноте.
Kieran Chandler: Можете объяснить разницу между масштабируемостью (scalable) и горизонтальным масштабированием (scale out)?
Joannes Vermorel: Возможности, предоставляемые облачными технологиями, означают, что мы хотим использовать горизонтальное масштабирование (scale out), а не вертикальное (scale up). Вопрос в том, если вы хотите обрабатывать терабайты данных, сможете ли вы сделать это, используя множество небольших машин, или вам понадобится суперкомпьютер?
Kieran Chandler: Итак, в чем наш главный вывод на сегодня?
Joannes Vermorel: Наш главный вывод заключается в том, что с учетом данных, которые существуют, и при выборе программного обеспечения, это может существенно ограничить ваши будущие возможности. Поэтому нужно полностью осознавать сделанные вами выборы.
Kieran Chandler: Можете подробнее рассказать об этом?
Joannes Vermorel: Мой совет для специалистов по цепочке поставок — быть более осведомленными о базовых предположениях проектирования, которые характеризуют их собственную экосистему приложений. У них есть множество приложений, и смогут ли они назвать хотя бы полдюжины критически важных предположений, объясняющих нюансы продукта. Это может звучать очень технически, но если вы не понимаете эти основные предположения, вам придется сильно пострадать, когда вы осознаете, что пытаетесь сделать то, для чего по своей природе продукт не предназначен. Я часто видел компании, у которых проблемы возникали из-за несоответствия между дизайном программного обеспечения и тем, что они пытались с ним сделать.
Kieran Chandler: Можете привести пример?
Joannes Vermorel: Поставщики стараются демонстрировать уверенность, понимаете, как поставщик, вы пытаетесь продать свое программное обеспечение. Вы хотите вести себя уверенно и сказать клиенту, что ваше ПО для цепочки поставок будет отлично работать в любых ситуациях и мы обо всем позаботимся. Но реальность такова, что если клиент собирается использовать ваше программное обеспечение для задачи, которая выходит за рамки ваших проектных возможностей, вы не можете просто заклеить проблему лентой. Вы не можете просто добавить функцию. Инженеры, работающие на сервере, скажут вам: “Босс, извините, мы не можем этого сделать. Это будет адом.”
Kieran Chandler: Ладно, подытожим. Спасибо, Joannes. Это всё на эту неделю. Большое спасибо, что были с нами, и до встречи в следующий раз. Пока.
