00:00:00 Неудачи SAP запускают это глубокое погружение
00:02:15 Миллиарды потеряны на ERP — это только верхушка айсберга
00:06:15 Ошибки наследия в дизайне преследуют современные системы
00:10:20 Логика захвата рынка за разрастанием ERP
00:12:26 CRUD-приложения и коммодификация ERP
00:16:30 HANA была стратегическим поворотом SAP к аналитике
00:20:38 Почему табличные базы данных терпят неудачу в отчетности
00:26:23 Колоночные базы данных: преимущества и скрытые затраты
00:30:21 Ставка на оперативную память - это пари, которое не увенчалось успехом
00:34:31 Коллизии производительности в гибридных базах данных
00:40:41 Гибридное программное обеспечение проваливается во всем
00:42:33 Система интеллекта: третий парадигм
00:46:59 Ранние ERP ошибочно продавались как интеллектуальные
00:52:33 Почему S/4HANA не может быть всем одновременно
00:58:43 Провал Google в CRUD показывает культурное несоответствие
01:05:02 Программируемость — ключ к системам принятия решений
01:10:38 Экономический провал подхода «все в одном»
01:16:30 Почему модернизация ERP настолько медленная и затратная
01:22:06 Оптимизируйте решения — а не только процессы
01:27:24 Советы по созданию собственного слоя записей
01:34:13 Решения с открытым исходным кодом и истинная стоимость товарных технологий
Резюме
В содержательной беседе между Конором Дохерти из Lokad и генеральным директором Джуаннесом Верморелем они обсуждают финансовые неудачи, связанные с внедрением программного обеспечения SAP. Верморель разъясняет основные проблемы объединения систем записей, систем отчетности и систем интеллекта в единое ERP решение, что приводит к неэффективности и конфликтам. Они обращают внимание на дорогостоящие провалы, которые испытали такие компании, как DHL и Lidl, вследствие ошибочных стратегий SAP, особенно в части интеграции HANA. Верморель выступает за специализированные системы и решения с открытым исходным кодом, такие как PostgreSQL, которые предлагают надежный функционал при более низких затратах, отводя компании от сложного и неэффективного объединения программного обеспечения.
Расширенное резюме
В свете недавних разоблачений, выявивших многочисленные финансовые потери, связанные с внедрением программного обеспечения SAP крупными корпорациями, Конор Дохерти, директор по коммуникациям в Lokad, сел вместе с Джуаннесом Верморелем, генеральным директором и основателем Lokad, для углубленной беседы. Их разговор, охватывающий проблемы разработки корпоративного программного обеспечения и ловушки амбициозных, но ошибочных стратегий SAP, предлагает богатый и поучительный анализ.
Верморель объясняет тонкие различия между программными системами, используемыми компаниями: системами записей, системами отчетности и системами интеллекта. Основная проблема возникает, когда компании пытаются объединить эти три различных системы в одном программном решении, что неизбежно приводит к конфликтам и неэффективности. Этот сценарий иллюстрируется включением в ERP-решения SAP принципиально несовместимых элементов, таких как HANA, что со временем приводит к значительным стратегическим и операционным неудачам.
Примеры неудач, связанных с SAP, поражают воображение. По словам Конора, такие компании, как DHL, Lidl, Spar и Asda, сообщили о потерях, составляющих сотни миллионов долларов, из-за внедрения ERP SAP. Эти убытки — лишь малая часть более масштабного экономического застоя, испытанного этими организациями в течение длительных периодов, посвященных обновлению систем. Верморель отмечает, что подобные проекты замораживают усилия по модернизации и подавляют другие цифровые преобразования, что резко увеличивает истинные затраты этих проектов.
По мнению Вермореля, суть проблемы уходит корнями в ключевые решения, принятые SAP десятилетия назад. Изначально SAP сосредоточилась на системах записей — по сути, на сложных электронных реестрах, охватывающих все аспекты деятельности компании. Такая стратегия «захвата рынка» привела к широкому охвату, но также вызвала коммодификацию CRUD (создание, чтение, обновление, удаление) операций. К началу 2000-х произошел переход к системам отчетности, что привело к созданию сложных, но громоздких аналитических инструментов.
Одним из ключевых решений, принятых SAP, стала интеграция HANA — колоночной базы данных в оперативной памяти, предназначенной для улучшения аналитических возможностей, но не подходящей в качестве базовой базы данных для транзакционных операций. Верморель подробно описывает, как эта стратегическая ошибка имела широкомасштабные последствия, замедляя основные процессы и создавая проблемы с производительностью, которые требовали обширного и дорогостоящего переразработки для их решения.
В интервью затрагивается внутренний конфликт между потребностями в дизайне различных программных систем. Системы записей требуют быстрой обработки транзакций с высокой степенью надежности, в то время как системы отчетности требуют обширных возможностей аналитики данных. Объединение этих систем с системами интеллекта, целью которых является автоматизация принятия решений посредством программируемости, еще более усложняет архитектуру программного обеспечения. Это противоречие сравнивают с попыткой создать транспортное средство, которое одновременно является отличным самолетом и фантастической лодкой — предприятие, обреченное на получение посредственного гибрида.
Конор поднимает вопрос о роли механической симпатии при выборе программных решений — по сути, о понимании внутренних характеристик и ограничений программного обеспечения, таких как различия между табличными и колоночными базами данных. Такие базовые знания могут помочь компаниям избегать дорогостоящих решений.
Оптимистичный взгляд Вермореля подчеркивает потенциал открытых решений, таких как PostgreSQL. Он выступает за использование этих доступных и надежных систем, утверждая, что их скромная стоимость и высокая функциональность предоставляют жизнеспособный путь для обхода ловушек, продемонстрированных ошибками SAP.
В заключение, обсуждение Вермореля и Дохерти подчеркивает важное предостережение: в то время как амбициозные программные решения обещают объединить разнообразные функции под одной крышей, реальность такова, что такие интеграции часто приводят к излишней сложности и проблемам с производительностью. Компаниям следует рассмотреть специализированные системы, адаптированные к их конкретным потребностям, извлекая выгоду из богатого спектра открытых решений, которые обеспечивают высокое инженерное качество без сопутствующих чрезмерных затрат. Этот разговор служит ориентиром для компаний на пути цифровой трансформации, позволяя избегать исторических ошибок, оказавшихся экономически вредоносными.
Полная расшифровка
Конор Дохерти: С возвращением на Lokad. В свете недавних новостей о том, что некоторые очень крупные компании потеряли огромные суммы денег из-за своих внедрений SAP, Джуаннес и я решили сесть и обсудить, что же именно пошло не так. Джуаннес описывает трудности, связанные с разработкой корпоративного программного обеспечения, а также излагает свою точку зрения на различия между системами записей, системами отчетности и системами интеллекта. Как утверждает Джуаннес, когда компании пытаются создать все три системы в одном программном решении, начинают возникать проблемы.
Как всегда, если вам нравится то, что вы слышите, подпишитесь на наш канал YouTube и следите за нами в LinkedIn. А теперь я представляю вам сегодняшний разговор. Так что, Джуаннес, спасибо, что присоединились ко мне в Black Lodge. Позвольте немного подготовить почву для вас.
Во вступлении я отметил, что одной из причин нашего собрания является обсуждение очень крупных компаний, потерявших огромные суммы денег. Конечно, это довольно общее утверждение. Фактически, к возникновению этого разговора привел пост, который несколько разлетелся по LinkedIn от Энтони Миллера, друга нашего канала, где он собрал множество весьма обвинительных цифр, касающихся компаний с многомиллиардными оборотами, сообщавших о потерях в сотни миллионов долларов, которые они приписывали своим внедрениям SAP.
Итак, если процитировать или перефразировать, я должен сказать, что, по всей видимости, DHL потеряла более 370 миллионов долларов, пытаясь внедрить решение от SAP и IBM. Lidl в Германии — ну, прежде чем кто-то поправит меня в комментариях, это Lidl в Ирландии, Lidl на континенте, но фактически Lidl в Ирландии — они сократили убытки после того, как потратили полмиллиарда евро. Таким образом, они прекратили внедрение после расходов в размере полмиллиарда евро.
SPAR, голландская сеть, как я полагаю, сообщила о потерях в $109 миллионов продаж из-за внедрения SAP. То есть, это следствие внедрения. А ASDA зафиксировала расхождения в запасах на сумму $25,5 миллионов между их SAP ERP и их WMS. Конечно, есть и другие примеры, но суть в том, что это убытки на сумму более миллиарда долларов или миллиарда евро. Так что мы говорим не о мелочи.
Итак, я перехожу к вопросу: Джуаннес, что именно идет не так с этими огромными компаниями и их внедрениями SAP?
Джуаннес Верморель: И, конечно, общим знаменателем всех этих проблем является выбор неправильного поставщика, SAP. Но, эм, также, я считаю, к сожалению, что эти цифры — лишь верхушка айсберга. На самом деле, по моим неофициальным наблюдениям, потери в разы больше, и это только те, о которых говорят. То есть, они не признают истинных затрат.
Они просто, эм, например, признают факт того, что заплатили деньги за неработающее решение. То, чего они не признают, это то, что обычно процесс занимал много лет для реализации многих из этих проектов. На самом деле, компания замораживалась на полдесятилетия, иногда на целое десятилетие, не имея возможности делать что-либо, кроме как сосредоточиться на обновлении ERP.
Так что, понимаете, это означает, что вы не только потратили сотни миллионов, но на самом деле это делает лишь малую часть ущерба, потому что на самом деле вы приостановили всю модернизацию, всю цифровизацию, все текущие преобразования, которые могли бы происходить, поскольку вам приходилось заниматься обновлением ERP. И я видел это много раз, когда компании идут на многолетние проекты, где всё приостанавливается ради этого. Затраты абсолютно колоссальны.
То есть, это, безусловно, свидетельство качества этих компаний, что они выживают в этом процессе, потому что, будем честны, например, в индустрии программного обеспечения любой, кто приостанавливает своё развитие на полдесятилетия, просто погибнет. То есть, их заменят технологии с тремя поколениями вперед. Так что, респект этим компаниям за выживание. Это означает, что они владеют абсолютным мастерством в своей области, чтобы выжить так долго с таким дисфункциональным процессом.
Реальность такова, что перспективы абсолютно мрачные. И если мы копнем глубже за этим общим знаменателем, чтобы исследовать основную причину, потому что обвинения в адрес SAP не проясняют ситуацию, я считаю, что корневая причина — это серия ошибок, совершенных давно, буквально десятилетия назад.
Конор Дохерти: Речь идет об ошибках в бизнес-решениях или же о программных ошибках? Что именно вы подразумеваете под ошибками?
Джуаннес Верморель: Я подразумеваю стратегические ошибки в дизайне, совершенные сотрудниками SAP десятилетия назад. Эти провалы можно проследить до ошибок, допущенных десятилетия назад. И это интересно, потому что при анализе этих неудач начинается игра в обвинения: «Интегратор был некомпетентен» или «Менеджмент изменений в компании был осуществлен неправильно» или «IT отдел компании не соответствовал необходимому уровню», или то, или то, и так далее. Просто отговорки, отговорки, отговорки.
И действительно, каждый провал выглядит по-своему уникальным, так как это всегда очень специфический беспорядок. Но опять же, это не дает удовлетворительного объяснения. Я думаю, что если вы хотите действительно понять, почему возникают все эти проблемы, это связано с особенностями крупных поставщиков корпоративного программного обеспечения. Существуют явные корневые причины, которые можно проследить до решений, принятых десятилетия назад. Сейчас мы лишь наблюдаем, как разворачиваются их последствия.
Зрители могут не осознавать, но когда вы управляете компанией по разработке программного обеспечения, вам приходится жить со своими грехами, с прошлыми ошибками очень долго, возможно, навсегда. И это очень странно, ведь можно было бы подумать, что программное обеспечение полностью изменяемо, что можно изменить всё, что было сделано. Но реальность иная.
Возвращаясь к теме, когда речь идёт об архитектурных решениях, совершенные ошибки могут преследовать вас бесконечно. Эти ошибки будут преследовать вас вечно и отравлять всё, чем вы занимаетесь. Люди видят симптомы — все проблемы, — но не обязательно могут проследить их до корневой причины, которая зачастую так стара, что её просто не замечают.
Конор Дохерти: Ну, SAP, для справки, — это огромная компания, история которой насчитывает более 50 лет. Так что когда речь идёт о корневых причинах и стратегических дизайнерских решениях, принятых десятилетия назад и преследующих SAP ERP в 2025 году, это довольно экстремальные утверждения, требующие дополнительных доказательств. Можете ли вы привести пример стратегического дизайнерского решения из 1970-х, которое до сих пор преследует SAP ERP в 2025 году?
Джуаннес Верморель: Итак, SAP начала свою деятельность в конце 70-х, и то, что я называю системами записей, — именно то, что люди называют ERP, CRM, WMS и всеми этими программными продуктами, которые по сути являются электронным аналогом того, что происходит в компании. В этих системах записей отсутствует интеллект; можно сказать, это роскошные бухгалтерские книги. Если оглянуться в прошлое, успешными были те поставщики, которые занимались наибольшим «захватом рынка».
Что я имею в виду под захватом территории? Если вы начинаете управлять запасами, вам нужно управлять сотрудниками, затем заказами, затем платежами, затем закупками, клиентами, поставщиками, партнёрами и так далее. Идея в том, что вам нужно захватить “территорию” полного охвата — охвата, максимально обширного для ваших записей. Если оглянуться назад, скажем, на 80-е, то конкуренция захвата территории была в разгаре. Реальность заключалась в том, что для любой компании, начинающей использовать доминирующего вендора (в то время это мог быть SAP, Oracle или IBM), наступал эффект: победитель забирает всё.
Вы — клиентская компания, вы используете программное обеспечение от вендора; как только вы начинаете работать с этим вендором, вы практически переводите весь бизнес на него. Почему? Потому что в то время распределённое инженерное ПО было абсолютным. Это означало, что если всё программное обеспечение не находилось в одном мейнфрейме, вы оказывались в затруднительном положении. Теоретически можно было заниматься сетевыми технологиями (мы же в 80-х), и некоторые банки делали это тогда, но это было чрезвычайно сложно и дорого.
Реалистично, единственным экономически жизнеспособным решением для управления запасами и поставщиками и их синхронизации было свести всё к одной системе. Таким образом, чтобы выиграть, вендор должен был охватывать всё. Именно это в итоге обеспечило успех вендоров, которые разрабатывали то, что называли ERP и CRM. Эти большие мега-системы оказались успешными благодаря массивному охвату. Что это подразумевает? Это означает, что вам нужно охватить как можно больше территории, и в итоге вы затрагиваете абсолютно всё.
Но это не создаёт особого стимула для достижения гиперконсистенции, гиперинтеграции. Речь идёт скорее о том, чтобы как можно быстрее захватить как можно больше территории. В процессе крупные игроки поняли, что CRUD (создание, чтение, обновление, удаление) приложения являются полным товаром. Программная отрасль поняла, что этот процесс — простой товар. Если вам нужна система записей, CRUD-приложение — всё очень просто.
Вам нужна реляционная база данных и фреймворк, предоставляющий серию представлений для каждой сущности, предлагающих пользовательский интерфейс для выполнения CRUD-операций для всех сущностей. Вы можете создать клиента, обновить клиента, удалить клиента и так далее. Вы можете сделать то же самое для клиентов, поставщиков, счетов и прочего. Очень быстро вендоры поняли, что этот процесс — просто товар. Фаза захвата территории практически закончилась в 2000-х. К 2000 году не всё было охвачено — возникали новые области, например, электронная коммерция.
В то время её не было; её нужно было создавать. Постоянно появляются новые вещи, но большая часть территории уже была захвачена, и это стало проблемой. Такие вендоры, как SAP, увидели, что коммодитизация наступает с огромной силой. Эти системы записей просты и должны стоить очень дешево — буквально копейки. Так как же сохранить прибыль и маржу, если вы продаёте технологию, которая является полным товаром?
Вот где они увидели “серебряную подкладку”: системы отчётов. В середине 90-х появилась компания Business Objects, создавшая первый крупный успех в продаже технологии OLAP (Online Analytical Processing) — системы отчётов. Это был потрясающий успех. Business Objects была приобретена в 2006 или 2007 году компанией SAP. Люди поняли, что, возможно, ценность заключается именно в системах отчётов. В то время это казалось весьма изысканным.
Очевидно, что в отличие от электронных записей, когда у вас уже есть всё необходимое о клиентах в базе данных, ваша ценность ограничена. Ожидается, что вы предоставите электронные аналоги для бизнеса. Как только у вас есть удовлетворительное электронное представление бизнеса, добавлять что-то сверх того уже некому. Есть лишь ограниченное число вещей, которые можно добавить для описания продукта в базе данных, клиента и так далее. В итоге возникает стремление к аналитике. SAP это понял и решил сделать ставку на второй этап, начиная с 2010 года с HANA.
Для меня это суть большинства современных проблем. Думаю, это произошло из-за решения сделать ставку на HANA. Если вспомнить то решение, то SAP всё ещё сталкивался с одной стратегической проблемой: залежимостью от сторонних баз данных. В 2000-х они в основном полагались на базы данных Oracle, немного на Microsoft и IBM DB2, но в основном на Oracle. Это означало, что ERP того времени, SAP ECC и все их комплекты (с множеством продуктов и приобретений) зависели от сторонней базы данных.
Это было проблемой, потому что значительная часть ценности уходила другой компании-разработчику программного обеспечения. Из-за коммодитизации соревноваться за сужающийся рынок было проблематично. SAP решил запустить собственный уровень базы данных, кодовое название HANA. Четко понимая, что они хотят сделать сильный акцент на аналитику, они нацелились на систему, которая была колоночной и работала в оперативной памяти. Это одно решение 2010 года предопределило возникновение ошибки.
ERP S4 был выпущен только в 2015 году. Так что, как только они получили свою новую систему базы данных, им понадобилось несколько лет, чтобы перестроить собственную ERP-технологию на основе этой новой базы. Но если вернуться назад, думаю, суть ошибки, которая сейчас развивается, можно проследить до HANA. Теперь нужно понять немного больше. Это немного сложнее, поэтому, возможно, я уделю немного времени, чтобы объяснить, что здесь происходит.
Для системы записей нужна табличная база данных, то есть традиционная база данных. Итак, что такое табличная база данных? Это база данных, в которой данные организованы в таблицах, построчно. Это одна вещь, которую необходимо учитывать в компьютерных системах: локальность ссылок чрезвычайно важна для производительности. Это означает, что когда вы хотите получить доступ к набору данных, для высокой производительности все эти данные должны находиться в одном месте системы, в одном и том же месте.
Представим, что вы хотите обновить поставщика. У поставщика много информации — его имя, местоположение, сертификаты, и так далее. То есть, можно подумать обо всех атрибутах сущности поставщика в системе. Это будет таблица. Возможно, таблица будет называться “Поставщики”, и она будет содержать десятки, возможно, сто столбцов. Так что если вы организуете базу данных в табличном виде, это означает, что когда вы выбираете поставщика, вам показываются все данные о нём.
Вся информация о данном поставщике как бы сосредоточена в одном месте системы. И если вы хотите обновить данные, всё происходит так же. Если же у вас табличное представление данных, очень просто добавить строку или удалить её. Опять же, все эти данные аккуратно сгруппированы. Это работает отлично. Так что для табличных баз данных, для систем записей, они просто идеальны.
Но они совершенно не подходят для аналитики. Вот в чём проблема. Это основная причина, по которой Business Objects, знаете, все инструменты BI, бизнес-аналитика добились первоначального успеха. Потому что в 90-х они начали предоставлять то, что называлось OLAP, то есть кубы, гиперкубы, которые располагаются рядом с базой данных и гораздо удобнее для осуществления аналитики.
И почему так? Представьте, например, что у вас есть таблица с заказами, и в этой таблице имеется столбец, содержащий сумму, выраженную, скажем, в долларах для простоты. Но в таблице заказов, помимо этого столбца, может содержаться около 100 столбцов. Теперь вы хотите вычислить, сколько продаж в долларах у вас было за прошлый год. Реальность такова, что если вы хотите вычислить этот оборот за прошлый год, который представляет собой сумму значений столбца, то при использовании табличной базы данных вам придётся просмотреть по сути всю таблицу. Система пройдёт через каждую строку, и в итоге не сможет выделить нужный столбец суммы, потому что он полностью утонул среди остальных.
Таким образом, чтобы вычислить итог этого одного столбца, вы оказываемся вынуждены просматривать всю таблицу, которая может содержать в сотни раз больше информации, чем одна цифра, которую вы хотите получить для каждой строки, что значительно замедляет систему. Решение заключается в том, чтобы организовать базу данных по колоночной схеме. Что это означает? Вместо группировки данных по строкам, вы группируете их по столбцам.
Внезапно, если вы хотите выбрать столбец и выполнить операцию, например, “Я хочу суммировать всё, что находится в этом столбце”, процесс становится супербыстрым, потому что вы получаете доступ к этому столбцу в изоляции. Вам не нужны идентификаторы заказа, клиента, продукта и все остальные столбцы, которые можно найти в таблице заказов. Вы изолируете единственный нужный столбец. То же самое касается выбора по дате: вы можете выбрать столбец даты и применить фильтр.
Это будет в тысяч раз эффективнее. Это очень круто. И, кстати, исторически эта колоночная схема появилась, когда люди начинали заниматься корпоративной аналитикой, сначала используя гиперкубы, технологии OLAP. Но очень быстро, к концу 2000-х, люди поняли, что колоночные базы данных просто лучше. Таким образом, был период, когда Business Objects работали с гиперкубами, а технология быстро эволюционировала в их превосходящую версию, а именно колоночные базы данных.
Хорошо, теперь колоночные базы данных гораздо лучше подходят для аналитики. Так что для всех этих систем отчётов это фантастическая новость. У нас появляется нечто, что гораздо лучше подходит для аудитории. Кстати, колоночной базой данных может быть, например, Spark — реализация с открытым исходным кодом, предоставляющая колоночную базу данных.
Это невероятная масштабируемость для обработки, и это очень, очень эффективно с точки зрения производительности. Теперь это не означает, что у этой системы нет компромисса. Компромисс заключается в том, что колоночная база данных по своей природе совершенно непригодна для системы записей. Во-первых, если вы организуете данные по столбцам, то при обновлении строки затрагиваются многочисленные столбцы. Вам нужно определить правильное место в каждом столбце, и если у вас 100 столбцов, это означает, что вам придётся обновлять 100 отдельных мест в системе.
В то время как раньше, с табличной базой данных, вы могли сделать одно обновление, которое было бы локальным. Но здесь данные организованы по столбцам. Таким образом, если вы хотите обновить запись, она будет распределена по многим столбцам. Это будет в тысячи раз менее эффективно. Опять же, бесплатного обеда не бывает. Либо вы организуете данные в табличной форме, что отлично подходит для систем записей, либо выбираете колоночную базу данных, отлично подходящую для систем отчётов. Невозможно иметь и то, и другое одновременно.
SAP решил полностью перейти на HANA, которая была колоночной базой данных. Думаю, именно это решение предопределило провал всего, что они делали на базовом уровне — систем записей.
Conor Doherty: Ладно, просто чтобы вставить слово, так как было рассказано очень много, это было хорошо, спасибо. Но, чтобы я, как слушатель этого сейчас, мог ориентироваться, могут спросить: «Вы серьёзно утверждаете, что DHL, Spar и Asda потеряли в общей сложности товар на миллиард долларов из-за внедрения, связанного с ошибками между колоночным и табличным подходами в аналитике? Это основная причина проблемы. Такое утверждение?»
Joannes Vermorel: В значительной степени, да. То есть…
Conor Doherty: Подтверди это для меня.
Joannes Vermorel: Да, дело в том, что когда совершаются критические архитектурные ошибки, они имеют тенденцию приводить к тысячам побочных эффектов. Не потому, что что-то чрезвычайно хаотично и сложно — коренная причина сама по себе может быть очень простой и не сложной. Примером может служить вращение Земли. Земля, по сравнению с Солнцем, имеет наклон оси, что вызывает чрезвычайно сложную систему сезонов с жаркими и холодными периодами, ветрами и множеством других явлений, являющихся последствием этого простого наклона.
Таким образом, коренная причина может быть чрезвычайно простой, но если взглянуть на последствия, они оказываются невероятно сложными и разнообразными, и всё же их можно проследить до чего-то очень простого.
Conor Doherty: Согласен, и это прекрасный астрономический пример.
Joannes Vermorel: Здесь это означает, что, приняв решение, которое было полезно для их аналитики, но вредно для их системы записей, они создали систему, которая работает чрезвычайно медленно. Здесь мы также можем увидеть своего рода риск, на который пошёл SAP в 2010 году. Они сделали не только колоночную систему; они также сделали её in-memory. Это была ещё одна ошибка. Идея сделать систему in-memory означает, что все данные будут находиться в DRAM, то есть в той же оперативной памяти, которая используется для серверов.
Мысли того времени заключались в том, что DRAM станет невероятно дешёвой и намного быстрее в будущем, что будет замечательно. Компании-разработчики программного обеспечения склонны говорить: «Сейчас у нас проблема с производительностью, но если мы примем правильные решения, то прогресс в аппаратном обеспечении нивелирует эту проблему в будущем.» Они верят, что если вычислительное оборудование станет в сто раз быстрее или лучше в нужном направлении, то все проблемы с производительностью, которые есть сейчас, могут исчезнуть в течение нескольких лет.
Microsoft была печально известна тем, что так поступала долгое время. Они выпускали программное обеспечение, которое едва работало на каких-либо машинах, а через несколько лет, когда всё ускорялось, программы начинали работать отлично. Проблема в том, что с 2010 года оперативная память не продвинулась так значительно за полтора десятилетия. Да, она немного улучшилась, но только немного по сравнению со всем остальным, особенно по сравнению с другими формами хранения данных, такими как SSD.
Оперативная память едва изменилась с точки зрения стоимости, скорости, латентности и всего прочего, а твердотельные накопители (SSD) улучшились более чем в тысячу раз за тот же период. Так что они полностью сделали ставку на надежду, что эта технология улучшится на порядки, но этого не произошло и, скорее всего, не произойдет по множеству причин. Другие области в компьютерных науках развиваются с бешеной скоростью.
Графические карты, то есть GPU, используемые для ИИ, развиваются с огромной скоростью. То есть существует множество других областей, которые развиваются с бешеной скоростью, но эта не так сильно. Проблема в том, что единственная жертва, которую вы приносите, используя базу данных, сделав её колоночной для системы записей, заключается в том, что задержка станет просто ужасной.
Всё будет работать медленно, почти по замыслу. И это уже было проблемой с узким местом табличного дизайна. Это уже было проблемой, но здесь вы делаете её намного, намного хуже. Что означает, что в результате вы будете постоянно тушить пожары, пытаясь устранить все проблемы, вызванные изначально вашей неправильной архитектурой.
Конор Дохерти: Ну, это создаёт идеальный переход, потому что я как раз собирался сказать то же самое. Если вы просто примените то, что только что описали — систему учёта и систему отчётов — систему учёта, ваш ERP, в конкретном случае, когда вы сканируете штрих-коды, система обновляется, и вы сразу знаете, сколько товара у вас находится на складе в любой момент или сколько у вас в магазине. Ладно, круто. Это, я полагаю, требует довольно низкой задержки?
Йоаннес Верморель: Абсолютно.
Конор Дохерти: Ладно, круто. А что насчёт структуры дизайна для этой системы учёта? Это означает, что либо вы идёте на риск, либо платите ценой хорошей системы отчётов, которая по существу предназначена только для бизнес-отчётности. В чём же борьба? Потому что, как вы говорите, существует противостояние, но я не понимаю, в чём именно… Вы хотите, чтобы система, ваше рациональное ядро, работало сверхбыстро при сканировании штрих-кода. То есть, вы сканируете штрих-код, он издаёт сигнал, система регистрирует это, всё в порядке. Штрих-код действительно существует в вашей системе. Всё. Вот тот самый звук, который вы слышите — система подтверждает, что всё записано. Всё в порядке. Дальше. Идеально.
Йоаннес Верморель: Теперь проблема в том, что, во-первых, если вы выберете колонковую архитектуру, эта единичная операция, которая просто подтверждает, что вы что-то сканировали, будет по определению гораздо медленнее, потому что придётся обрабатывать десятки данных, связывая их с помощью множества разрозненных колонок в вашей системе.
Таким образом, у вас возникает первая преграда, которая по замыслу значительно усложняет создание такой сверхбыстрой системы, потому что, как уже говорилось, колонковые базы данных отлично подходят для масштабной аналитики, но они не быстро реагируют. В этих базах данных нет ничего, что действительно разработано для низкой задержки. Именно не для этого они были созданы. Их сам дизайн в некотором роде противоречит этому.
Теперь проблему усугубляет ещё один момент: вы утверждаете, что слой вашей базы данных будет использоваться как для системы учёта, так и для всего остального. То есть для тех задач, которые управляют вашим инвентарём, учётом рабочего времени сотрудников — там, где требуется абсолютная точность. И вы также хотите, чтобы система была чрезвычайно отзывчива, когда кто-то регистрируется или проходит по бейджу.
Вы не хотите, чтобы система говорила: “Дайте мне 20 секунд, чтобы проверить, являетесь ли вы настоящим сотрудником и можете ли вы сегодня воспользоваться бейджем.” Нет! Вы хотите, чтобы всё работало супербыстро. Бейдж, звук, мгновенно! Иначе всё замедляется.
А теперь дело в том, что та же самая система, поскольку вы спроектировали её как колонковую базу данных с явной целью проведения аналитики, является и системой учёта, и системой отчётов — да. Что произойдёт: люди будут составлять отчёты. Вы говорите: “Хорошо, у нас есть система, которая буквально создана для проведения изящной аналитики. Давайте проведём изящную аналитику!”
Но каков же итог изящной аналитики? Итог в том, что вы выполняете операции, при которых приходится обрабатывать очень большие объёмы данных. И это совершенно противоречит требованиям низкой задержки. У вас есть этот центральный компонент базы данных, который используется всеми процессами. Он должен быть общим, иначе не будет целостности. Люди не будут иметь единого представления о том, каков текущий уровень запасов.
Если у всех нет единого понимания уровня запасов, это означает, что кто-то на сайте может заказать единицу, которой у вас нет, потому что кто-то другой уже выбрал её, и информация обновляется с задержкой. Электронная коммерция может полагать, что ещё осталась одна единица, когда на самом деле её нет. Это полный хаос!
Поэтому необходимо обеспечить целостность, чтобы не столкнуться с множеством глупых проблем. Сейчас ваш ресурс реляционной базы данных используется для задач, которые требуют молниеносной работы, и для тяжёлых задач — ваших отчётов, где вы, например, просите: “Проанализируйте всех клиентов, совершивших более трёх покупок в прошлом году по категориям” и тому подобное.
Таким образом, у вас появляются вычислительно тяжёлые запросы, проходящие через значительную часть всех имеющихся данных. Вот в чём противоречие. Суть аналитики не в том, чтобы извлечь конкретный артикул или клиента. Аналитика — это сканирование каждого клиента для получения статистики по тому или иному параметру.
Я просканирую всю свою историю продаж за последние несколько лет, чтобы проанализировать тренды. Таким образом, у вас оказывается система, в которой имеется множество операций, чрезвычайно “прожорливых” к ресурсам. И опять же, как же смягчить тот факт, что это полностью портит задержку?
Я имею в виду, ответ заключается в том, что вы “бросаете” на проблему больше аппаратного обеспечения. Какого оборудования вам нужно? Вам нужна оперативная память, потому что вы ещё в 2010 году решили, что это будет колонковая система, работающая в памяти. Не повезло!
Если бы мир пошёл другим путём, если бы DRAM стала в тысячу раз дешевле и быстрее, это был бы идеальный выбор. Но этого не случилось и, скорее всего, не случится. То есть, эта технология — DRAM — всё ещё развивается, но никак не так быстро, как большинство других технологий компьютерного оборудования.
Это одна из технологий, которая развивается медленней всего, особенно в части задержки, где почти за два десятилетия изменений практически не произошло. Существуют даже категории задач, особенно связанные с задержкой, где не стоит ожидать улучшений в ближайшее время.
Улучшения произойдут, но не в этой области. То есть, люди, которые поставили всё на кон — как в покере, идя ва-банк, — хотя их карты не были хорошими. Именно это и произошло в 2010 году. И сегодня мы видим, как последствия проявляются самым разнообразным образом.
Конор Дохерти: Ещё раз, я хочу попытаться суммировать всё это насколько возможно. Исправьте меня, если я ошибаюсь. Выбор дизайнерских решений, которые делаются для того, чтобы добиться успеха в первой категории программного обеспечения — корпоративном ПО, которое вы описываете как системы учёта, — противоречит тем решениям, которые вы бы приняли, если хотели бы добиться успеха в аналитическом программном обеспечении, таком как система отчётов.
И попытка делать и то, и другое одновременно — гибридизация, как вы сказали — приводит, по сути, к перетягиванию каната, когда вы можете и то, и другое делать, но в итоге будете справляться с ними хуже, чем если бы делали их по отдельности.
Йоаннес Верморель: Более или менее да. Точно. Вот в чём проблема: нельзя иметь нечто, что одновременно является и отличной лодкой, и отличным самолётом. Либо одно, либо другое. Если пытаться сделать и то, и другое, то получится и то, и другое посредственное.
Конор Дохерти: Ну, поскольку я, опять же, знаком с блогом, где вы впервые представили эту концепцию — сейчас будет немного сложнее. Но прежде чем продолжим, давайте подытожим пройденное. Вы использовали аналогию спринта и тяжёлой атлетики. То, что делает вас очень хорошим — и мне это нравится, потому что аналитика охватывает всё. Мне понравилась идея тяжёлой атлетики как аналогии.
Вы можете быть очень, очень хорошим тяжелоатлетом. Если вы хотите поднять с земли 200, 300 или 400 килограммов, для этого нужно быть внушительных размеров. Это движение, основанное на силе. Пробежать 100 метров менее чем за 10 секунд? Вы не сможете этого, если ваш вес составляет 150 килограммов; это просто невозможно. Так что вы можете быть отличным в аэробном беге, или же вы можете добиться мирового уровня в анаэробном тяжёлом атлетизме. Нельзя быть и тем, и другим одновременно, и если пытаться, то ни в одном из них у вас не получится по-настоящему преуспеть.
Йоаннес Верморель: Да, именно так. Но дело в том, что, поскольку я знаком с тем местом, где вы представили эту точку зрения, существует на самом деле третья категория корпоративного ПО. Мы уже обсудили системы учёта — ERP, ведение списков данных, учет единиц товарных запасов — есть системы отчётов — BI-инструменты, по существу для аналитики и презентации данных. И существует третья категория программного обеспечения, которую мы ещё не затрагивали.
Конор Дохерти: Что это такое?
Йоаннес Верморель: Третья категория — это системы интеллекта. Интересно то, что система интеллекта, в отличие от первых двух категорий, нацелена непосредственно на принятие решений. Вот и всё. Примечательно, что если взглянуть на историю корпоративного ПО с самого начала, в конце 70-х, то любое корпоративное ПО, независимо от его фактического функционала, всегда продавалось как система интеллекта, что довольно странно.
Таким образом, не имеет значения, продаёте ли вы систему интеллекта или нет. Пока вы ориентированы на предприятия, она будет продаваться как система интеллекта — лучшие решения для вас.
Конор Дохерти: Да, и это очень странно. Возьмём, к примеру, программное обеспечение для управления запасами. Фактически, это всего лишь бухгалтерская книга. Оно просто считает, сколько у вас запасов. Когда вы что-либо забираете, количество запасов уменьшается. Когда что-либо добавляете — увеличивается. Вот и всё. Оно ничего не делает, кроме как является электронным отражением ваших запасов.
Йоаннес Верморель: Эти продукты неизменно продавались с девизом “У вас будет меньше дефіцита товаров и меньше избытка запасов”, что никак не связано с самой бухгалтерской книгой.
Конор Дохерти: Нет, я имею в виду, можно сказать, что вы будете работать эффективнее при ведении учёта запасов. Может быть, ошибок при вводе будет меньше, но утверждать, что вы будете принимать лучшие решения относительно запасов — зачем это? Программа этого не делает. Она просто сообщает, что у вас есть. Она просто позволяет вам принимать решения, возможно, немного лучше.
Но это как играть в шахматы на настоящей доске или на компьютерной. Конечно, если вы хотите хранить записи всех предыдущих партий, электронная версия удобнее, но тот факт, что игра идёт на компьютере, не сделает вас лучшим шахматистом. Скорее всего, это даже отвлекает и может сделать вас хуже в шахматах.
Не гарантируется, что решения, принимаемые с помощью компьютера, автоматически лучше, только потому что вы взаимодействуете с компьютером, а не пишете пером на бумаге. Это может случаться, но сама система не предназначена для этого логически. Я даже утверждал бы, что по моему личному опыту, когда просишь людей действительно задуматься, экран компьютера по сути отвлекает.
Я бы сказал, что если вы хотите принимать действительно хорошие решения, я сомневаюсь, что экран, перегруженный информацией, поможет сосредоточиться и вдумчиво обдумать вопрос.
Йоаннес Верморель: Это очень смелое заявление. Чтобы было ясно, мы не отрицаем ценность системы учёта. Суть, как я понимаю, в том, чтобы не путать возможности вашей системы учёта с возможностями программного обеспечения, которое специально разработано для принятия решений.
Чтобы оправдать тех ранних поставщиков корпоративного ПО, всё было крайне расплывчато. Сейчас нам совершенно ясно — эти системы учёта, примитивные приложения, системы отчётов со всеми бизнес-аналитическими инструментами и современной аналитикой, а затем системы интеллекта, обладающие возможностями прогнозирования, оптимизации, с идеей буквальной автоматизации процессов принятия решений — такое классифицирование тогда было совершенно неясно.
Они пытались делать всё три сразу, и в 70-х первых системах управления запасами их продавали как “Мы будем напрямую автоматизировать все решения по управлению запасами.” Так их и позиционировали. Сообщество считало, что управлять запасами очень просто. Управление в том смысле, что само слово “управление” подразумевает не только ведение бухгалтерии.
Когда в 70-х говорили об управлении запасами, имелось в виду всё, что мог бы делать менеджер, а не только вести бухгалтерию. Он также принимал бы решения относительно запасов. Так что, когда люди думали об управлении запасами, они представляли себе систему, которая выполняет полный комплекс задач — отслеживает запасы и принимает все соответствующие решения. Но оказалось, что это не так.
Поэтому мы разделили эту сферу на управление запасами и оптимизацию запасов — оптимизацию, относящуюся к системам интеллекта. Но в то время это было совершенно неясно. То же самое с аналитикой — вы можете выводить данные на экран, но люди ещё не осознавали, насколько вырастут базы данных и с какими проблемами придётся столкнуться при извлечении статистики.
Сбор статистики был возможен с самого начала. Эти системы обычно работали ночью, один раз проходя через всю базу данных для сбора статистики. Так что это было возможно, даже используя табличную базу данных: можно было организовать ночные пакетные задания для сбора нужной статистики, но это было крайне неудобно из-за медлительности процесса.
Вам приходилось заранее подготавливать логику, а как только она была готова, ждать ночного пакета для её выполнения. Ошибку в коде обнаруживали только на следующий день. Операционно это был настоящий кошмар. Это было возможно, но уровень трения был просто за гранью.
Именно поэтому такие инструменты, как Business Objects, по сути, разработали OLAP-технологии с гиперкубами, где анализ можно провести за считанные секунды. Это полностью изменило правила игры, потому что внезапно вам не нужно было, скажем, реализовывать что-то и ждать до завтра, чтобы увидеть, допустили ли вы ошибку. Вы могли делать это в 100 раз быстрее, чем раньше.
Конор Дохерти: Ранее вы упомянули S4/HANA, который был выпущен в 2015 году. На момент записи этого разговора ему почти десять лет — думаю, до дня прошло уже десять лет, два дня назад. Теперь, изучив маркетинговые материалы по нему, особенно согласно вашей классификации, он был представлен как обладающий всеми возможностями системы учёта, системы отчётов и, благодаря алгоритмам принятия решений на базе ИИ, системы интеллекта. Таким образом, вы осветили проблемы, возникающие при попытке совмещать системы учёта и системы…
Joannes Vermorel: Некоторые аналитические методы, на мой взгляд, просто перевернули игру, потому что внезапно вам не приходилось внедрять что-либо и ждать до завтра, чтобы узнать, что получилось не так. Повторюсь, теперь вы могли делать это в 100 раз быстрее, чем раньше.
Conor Doherty: Ну, снова, вы, собственно, упомянули SAP S/4HANA, выпущенный в 2015 году. На самом деле, на момент записи этого разговора прошло почти 10 — кажется, ровно 10 лет, как два дня назад. Рассмотрев маркетинговые материалы по этому поводу, и, используя вашу классификацию, его по сути представляли как систему учёта, систему отчетности и, благодаря решениям на базе ИИ, систему интеллекта. Таким образом, вы уже осветили проблемы, возникающие при одновременной работе систем учёта и отчетности. Что же произойдёт, если попытаться объединить все три системы в одном решении?
Joannes Vermorel: Да, я имею в виду, что мы пытаемся быть одновременно поездом, лодкой и самолётом, и это ещё хуже. Знаете, это как входить в область Франкенштейна, где всё становится по-настоящему уродливым. Реальность такова, что всё работает против вас как против поставщика программного обеспечения, если вы пытаетесь объединить все три системы. Просто остановитесь на секунду, чтобы осознать, что это на самом деле подразумевает.
Систему учёта обычно продают с расчетом за оператора, за место, за пользователя. Именно так продаются подобные решения сегодня; это очень типичный показатель. Если же речь идёт о системе интеллекта, такой подход не имеет смысла, ведь в ней как бы исключаются пользователи. О, да, ведь ваша цель — принимать отличные решения. Очевидно, чем лучше вы становитесь, тем меньше пользователей вам нужно. В конечном счёте, в клиентской компании будет лишь несколько пользователей, отвечающих за контроль ваших решений. Если же стоимость определяется количеством пользователей, это не сработает; возникает конфликт стимулов. Но, конечно, это лишь один из множества нюансов.
Проблема в том, что те инженеры-программисты, которые вам нужны, совершенно другие. Кстати, я думаю, что одной из компаний, пострадавших от обратного эффекта, была Google. Google была пионером в области систем интеллекта. Какое разумное решение тогда приняла Google? Это был поиск; мой запрос звучал так: определите, какой из миллиарда сайтов наиболее релевантен. Это решение должно приниматься очень умно. Google заработала своё состояние благодаря тому, что решения принимались на высочайшем уровне — по крайней мере, лучше, чем у конкурентов. Они построили всю свою команду на идее, что у них будут очень умные инженеры, способные решать чрезвычайно сложные задачи, ведь принятие решений почти всегда сопряжено с высокой сложностью.
Вот почему вы хотите поручить их выполнение компьютеру. Если бы они не были сложными, это даже не называлось бы решением. Если что-то сводится к простой арифметике, вы скажете: “Ладно, это всего лишь базовый расчёт, ничего особенного, двигаемся дальше.” Google наняла массу талантливых инженеров для создания этих изящных систем. Но когда дело доходило до разработки систем учёта, которые обыденны, скучны и повторяемы, они потерпели неудачу.
Если присмотреться к истории Google, всё обыденное было выброшено за борт. У них был Google Reader — блог-ридер, который был широко принят. Он был простым, сыроватым приложением, но для Google сыроватое приложение было недостаточно, поэтому они его убрали. У них было десятки подобных продуктов, где если приложение было сыроватым — в смысле Create, Read, Update, Delete — его выпускали, но не могли поддерживать, потому что это было для них ниже по статусу.
Это настоящая проблема, когда вся ваша компания ориентирована на разработку систем интеллекта: ваши инженеры не стремятся делать скучную, повторяющуюся работу. Наоборот, если вы десятилетиями занимаетесь системами учёта, ваша команда привыкла проектировать тысячи экранов, считая: “Ладно, этому ПО понадобится 5000 или 20000 отдельных функций, каждая из которых крайне проста и не представляет никакой сложности,” но их всё равно нужно реализовывать.
Что касается инженерного состава и корпоративной культуры, ситуация совершенно иная. По моему мнению, в SAP сложилась команда, ориентированная на стратегию захвата рынка — давайте наймем огромное количество инженеров, способных создать кучу экранов и функций, каждая из которых по отдельности чрезвычайно проста. А затем они пытаются перейти к системам интеллекта, и это оборачивается катастрофой.
Одной из областей, где можно увидеть специалистов, отлично работающих в сфере систем интеллекта, является достижение технологических прорывов, которые проявляются в виде проектов с открытым исходным кодом. Например, Google, возможно, потерпела неудачу в поддержке сырых приложений, но сумела выпустить ценные фрагменты технологий с открытым исходным кодом, которые очень сложны в инженерном плане благодаря их талантливым специалистам. Если сравнить с SAP, я не уверен, что смог бы назвать хотя бы один интересный проект с открытым исходным кодом, возникший там.
Conor Doherty: Знаете, мне пришло в голову, что мы довольно много времени уделили структурам систем учёта и отчетности, но на самом деле не обсудили, каковы именно стратегические архитектурные решения для системы интеллекта и почему они несовместимы с двумя другими архитектурами. Например, Lokad — это система решений, система интеллекта; что в её устройстве делает попытку объединить её с системой учёта проблематичной, мягко говоря?
Joannes Vermorel: Я бы сказал, что система интеллекта по своей основе имеет некоторые сходства с системой отчетности. Вы хотите видеть представление данных в виде колонок — это имеет смысл для аналитики. Но затем, от системы интеллекта вы требуете быстрой программируемости. Если вам нужна гибкость для разработки процесса принятия решений, вам требуется нечто крайне выразительное. Кстати, именно поэтому таблицы Excel часто используются для поддержки процессов принятия решений; с Excel вы получаете язык программирования, что очень важно.
Формулы Excel могут быть сделаны произвольно сложными, и если хочется, можно даже программировать с помощью VBA или Python. Excel программируем, и поэтому его часто используют в качестве инструмента для поддержки систем интеллекта. Вам нужна программируемость, что является совершенно иным подходом по сравнению с системами отчетности, где всё должно быть доступно для всех. Здесь вы находитесь в области WYSIWYG (What You See Is What You Get); у вас есть изящные интерфейсы, что характерно для систем отчетности.
Conor Doherty: Также мне кажется, что здесь присутствует экономическая перспектива, которую мы ещё не затронули. И опять же, вы человек экономики, человек Томаса Соувелла.
Мне кажется, что с точки зрения программного обеспечения разумным решением является попытка купить «три в одном», где у вас одновременно есть система учёта, отчетности и интеллекта. Но это можно отложить в сторону. Разве не существует экономического аргумента, что с учётом компромиссов может оказаться дешевле купить по сути один продукт, который хотя бы заявляет о возможности выполнения всех трёх функций, а не три отдельные подписки на три разных продукта, три отдельные проблемы, а также необходимость обучать всех работе с тремя разными системами?
Joannes Vermorel: Да, я имею в виду, это буквально история F-35. Мы говорим об этом американском истребителе, который станет самым дорогим самолётом в истории. Проблема в том, что эти вещи не являются линейными.
Если вы скажете: “Я хочу, чтобы мой самолёт был превосходен в ближнем бою, отлично справлялся на дальних дистанциях, был стелс и мог вертикально взлетать”, в итоге получается, что при каждом добавлении функции цена всей системы удваивается.
В итоге вы получаете один самолёт, стоимость которого может составлять цену десяти других — один для дальних операций, один для тактического боя с другим самолётом, один для стелс, один для вертикального взлёта. Вам не обязательно иметь всё это вместе и так далее. Видите, это не линейно. Вы не можете просто объединить все эти функции в одном решении.
Теперь можно было бы сказать, что если бы SAP решил создать три абсолютно независимые системы — одну для учёта, одну для отчетности, третью для интеллекта — и установить «китайские стены» между этими подразделениями, чтобы они функционировали независимо, это могло бы сработать. Но так не поступили.
Искушение объединить всё вместе, включая приобретённые сторонние решения, оказалось слишком велико. Такая смесь просто токсична. Вы берёте продукты, которые плохо сочетаются, и получаете что-то нефункциональное. Думаю, именно это мы и наблюдаем сейчас.
Возвращаясь к хронологии, у нас появилась HANA в 2010 году. На запуск S/4 на её основе потребовалось пять лет. Большинство этих неудач буквально накапливались десятилетиями. Мы говорим о процессах, разворачивающихся в течение десятилетия.
Мы наблюдаем неудачи HANA, которые только начинают становиться видимыми для публики. Это лишь вершина айсберга. Возможностные издержки многих компаний просто безумны, потому что обновление занимает так много лет. Речь идёт об обновлениях, длительностью свыше пяти лет, что просто немыслимо.
Это безумие. Посмотрите, ChatGPT и генеративный ИИ не существовали пять лет назад. Вы опоздаете на этот бой. К тому же были приняты крайне плохие решения, такие как полностью полагаться на in-memory системы, что приводило к перерасходу на инфраструктуру.
Если у вас уйма оборудования, намного больше, чем нужно, это означает, что потребуется больше системных администраторов, больше сотрудников IT для управления всем этим. Всё становится невероятно сложным. Это не только сложнее, но и медленнее. Всё это накапливается, что приводит к значительно большим затратам, снижению скорости и необходимости в большем количестве людей, что усугубляет альтернативные издержки.
Затем сотрудники на управленческом уровне начинают паниковать, так как на кону стоит так много. Это ещё больше замедляет процесс. Это как порочный круг. Проблемы только начинают становиться видимыми. Компании изо всех сил стараются, чтобы их внутренние косяки никогда не становились достоянием публики, ведь это плохая реклама. Вы не хотите выставлять напоказ свою некомпетентность. Если можно разобраться с этим за закрытыми дверями, тем лучше.
Подумайте, насколько острой должна быть проблема, чтобы в итоге обнародовать все эти подробности. Почти ни в одном случае, если только компания не является публичной и не находится под сильным давлением, чтобы раскрыть информацию, такая информация не будет обнародована.
Conor Doherty: Что ж, вы упоминали альтернативные издержки несколько раз. Вы говорили об издержках, когда вас затягивает процесс внедрения. Внезапно вы застреваете в этом процессе, лишаясь возможности переключиться на что-то другое. К тому же, с этим связаны постоянно растущие расходы на обслуживание.
Еще одно измерение этого вопроса — я записал здесь «совершенствуемость». С точки зрения альтернативных издержек, если взять все три класса программного обеспечения отдельно, они, теоретически, работают лучше, когда их содержать раздельно: отдельная система учёта, отдельная система отчетности и отдельная система интеллекта.
Вы пытаетесь довести каждую до совершенства. Существует верхний предел того, насколько совершенна может быть система учёта. Как только достигается 100% точность, на этом всё. Например, сколько бутылок на столе? Две. Вот и всё. Ничего больше улучшить уже нельзя.
Как только задержка составляет 50 миллисекунд, это уже не имеет значения — люди этого не замечают. Что касается системы отчетности, насколько хорошим может выглядеть дашборд? Мы можем спорить об эстетике, но есть предел тому, сколько времени и денег вы готовы вложить, прежде чем начнут наступать убывающие отдачи.
Система интеллекта, как вы сказали, связана с принятием решений. В философии Lokad это означает оценку рентабельности каждого принятого решения. Теоретически мне кажется, что не существует такой точки совершенства, когда можно сказать: “Это лучшее решение, которое я когда-либо мог принять.”
Это не обязательно можно довести до совершенства. Вы можете постоянно улучшать алгоритм для принятия лучших решений. Я не прав?
Joannes Vermorel: Так что, нет, но мы также должны развеять одно заблуждение. Математики сказали бы: “Ах, но как только ты достиг оптимума, ты лучший.” Знаете, по определению, как только у тебя есть оптимальное решение, его уже нельзя сделать лучше. И для любой, я бы сказал, математической задачи, если взять задачу и сказать: “Вот она, задача,” то можно найти оптимальное решение для этой задачи.
Но неверно мыслить так в бизнесе, потому что выбор задачи очень произволен. Знаете, вы можете решить: “Ладно, это, возможно, оптимально для этой модели, но я могу переосмыслить свой бизнес, и тогда у меня появится новая модель с ещё большей отдачей.” Таким образом, доступные варианты не являются статичными. Вы сами решаете, что готовы делать, и в рамках того, что вы готовы делать, может существовать оптимум, но в основе возможности безграничны.
Нет — единственный предел, как я его вижу, — это человеческая изобретательность. Так что, если вы скажете: “Мой оптимум бессмыслен, потому что он существует в рамках формальных ограничений”, то я отвечу: “Я могу решать только в пределах, знаете, я проведение линию в песке, и говорю: могу рассматривать только эту область, и да, в рамках этой области мой оптимум может быть таков, возможно, я даже смогу это математически доказать.”
Но реальность такова, что это всего лишь нарисованная линия в песке. Вы можете пойти куда угодно. Таким образом, суть в том, что, действительно, когда речь идёт о бизнес-решениях, нет никаких ограничений, кроме интеллекта и изобретательности людей, которые будут работать над этим.
Теперь, я считаю, что индустрия программного обеспечения поняла это очень рано. Знаете, именно поэтому, начиная с 70-х годов, все поставщики делали акцент на преимуществах, выраженных в терминах улучшенного принятия решений. Они буквально рекламировали систему интеллекта, потому что понимали, что проблема наличия электронной репрезентации вашего инвентаря конечна. Как только это будет выполнено правильно, что вы будете делать?
Оказалось, что люди проходили через этапы. Сначала были текстовые интерфейсы, затем графические — например, на рабочем столе, эпоха десктопов, «толстых клиентов» 90-х. Сегодня есть веб-приложения, а теперь и мобильные приложения. Так что оказалось, что даже на уровне интерфейса, пользовательского интерфейса, произошла серия переходов.
Даже если задача была конечной, оказалось, что компании-разработчики программного обеспечения всё ещё были заняты просто обновлением от текстового терминала к графическому интерфейсу, к веб-приложению, а теперь к мобильному приложению. Но дело в том, что всем было совершенно ясно, что всё это когда-нибудь закончится, в том смысле, что оно не будет расти бесконечно, превращаясь во что-то чрезвычайно масштабное.
Вот почему очень рано многие поставщики, включая SAP, начинали позиционировать себя как противники таких решений, даже если их программное обеспечение на деле не имело никакого отношения к принятию лучших решений.
Conor Doherty: Ну, мне кажется, что мы много говорили о теории, а это хорошо. Теория в сочетании с практикой — и я, конечно, хочу сделать это немного более практичным. Хочу задать вам вопрос так: в начале эпизода я упомянул DHL, Asda, Spar. Были и другие примеры из поста Энтони Миллера.
Если бы вы оказались сегодня в комнате, если бы вы были в зале заседаний с принимающими решения, с большими шишками, крупными игроками, и они сказали: “Хорошо, Йоаннес, что нам делать дальше? Мы пробовали это, это не сработало. Какой бы был ваш совет?”
Joannes Vermorel: Мой совет очень прост. Системы учета стали полностью товароподобными ещё больше чем десять лет назад. Так что давайте двигаться поэтапно. Ваша база данных будет, скажем, PostgreSQL. Она с открытым исходным кодом, она превосходна.
Вот как обстояли дела еще в 2010 году, когда SAP заявляла: “У нас было так много проблем, мы рассматриваем Oracle как стратегическую угрозу.” То, чего они не осознавали, заключалось в том, что Oracle был незначительным. Реальным вызовом на самом деле был open source.
Таким образом, реляционная база данных, которая сегодня побеждает, фактически — это open source базы данных. Реляционные базы данных теперь абсолютно коммодизированы до такой степени, что лучшие продукты — это проекты с открытым исходным кодом, и PostgreSQL на порядок опережает Oracle и частные решения.
Итак, мы оказались в ситуации, когда крупный поставщик, SAP, который хотел сдержать другого поставщика, Oracle, в итоге разработал технологию, которая оказалась уступающей продукту с открытым исходным кодом — то есть PostgreSQL.
А откуда мне знать, что она уступает? Посмотрите хоть на Hacker News или обсудите, чем сегодня занимаются стартапы. Я проанализировал сотни стартапов. Я никогда не видел, чтобы стартап использовал реляционную базу данных, не являющуюся open source, за последнее десятилетие. Никогда.
Они использовали бы только базы данных с открытым исходным кодом. Я никогда не видел, чтобы стартап, например, использовал Oracle Database. Никогда. Это даёт понять, что люди, разбирающиеся в технологиях, не делают такого выбора. Прежде всего, я бы сказал этому залу руководителей: “Для уровня базы данных вам нужно выбрать один из отличных вариантов с открытым исходным кодом, доступных на рынке.”
Это может быть PostgreSQL. Эти решения превосходны, и если вы этого не сделаете, упущенные возможности будут огромны, потому что, выбрав одну из этих баз данных, вы получаете дополнительно буквально миллион+ инженеров-программистов, которые уже владеют этими технологиями, по сравнению с частными, малоизвестными технологиями, значительно сложнее в эксплуатации. Это была первая проблема.
Затем, что вам нужно сверху? По сути, вам нужен фреймворк для развертывания примитивного приложения поверх базы данных. Таких фреймворков существует масса, и, опять же, они доступны в open source. Это может быть Django, если вы работаете с Python, или MVC-фреймворк в ASP.NET для Microsoft, который также с открытым исходным кодом. Список можно продолжать. Эти фреймворки существуют для всех основных стеков — Python, Java, .NET.
Поскольку всё это полностью коммодизировано, либо вы выбираете для системы учета поставщика, который уже работает на open source — такие есть, либо вы просто делаете всё самостоятельно, и это даже не так дорого. Дело в том, что если вы в итоге запускаете пятилетний проект по обновлению ERP, вам будет гораздо выгоднее просто постепенно развертывать собственную замену.
За шесть месяцев вы могли бы получить серию модулей, которые уже обновляются и заменяются, если вы делаете это сами или с помощью IT-компании. И снова — приятное в том, что системы учета полностью коммодизированы, что очень просто найти людей, способных это сделать. Эти задачи очень просто аутсорсить, а если хотите — можно выполнить и внутри компании.
Порог вхождения очень низкий; это очень дешёво. Если посмотреть на все технологически подкованные компании в этом мире — например, Zalando — они разработали свою собственную ERP; им этого вполне хватает. Если взглянуть на Amazon, они поступают так же; JD.com ведёт себя аналогично. Все цифровые аборигены видят это как очевидное решение для системы учета.
Системы учета полностью коммодизированы. В конечном итоге, эти продукты, безусловно, не должны быть дорогими. Если они дорогие, то план Б будет таким: “Хорошо, знаете, я просто сделаю это сам.” Если вы попросите маляра написать роспись для стены в вашем доме, а он скажет, что это будет стоить 2 миллиона евро,
знаете, это же всего четыре квадратных метра, но если я не смогу сделать лучше, вы скажете: “Хорошо, я просто сделаю это сам.” Если это единственный вариант, я бы сделал это сам. Да, я бы предпочёл не заниматься покраской, но, знаете, речь не идёт о запуске ракет в космос. Речь идёт о чем-то достаточно простом.
Conor Doherty: Ну, опять же, поскольку, как видите, я делаю обильные заметки. Но следующий вопрос, который я хотел задать, был таков: после того, как мы разграничили три класса, и вы снова оказались в зале с руководителями, при этом наши потенциальные интересы, как вам известно, очевидны. Lokad сам по себе является поставщиком. Что касается затрат для каждого из этих классов, поскольку вы уже несколько раз за последние две-три минуты отмечали: “Смотрите, в принципе, вы могли бы сделать это сами.”
То есть, если вы технологически подкованы, вы можете, и вы — цифровые, термин, который использовался — цифровые аборигены, вы могли бы разработать собственную систему учета. Ладно, тогда, по идее, это должно стоить меньше, чем система отчетов и система интеллектуальных решений. Или как вы… как вы распределяете бюджет в этом отношении?
Joannes Vermorel: То есть, очевидно, что системы учета намного проще, чем всё остальное. Знаете, они были первыми. Технология полностью коммодизирована. Open source предоставляет все необходимые компоненты. Разработка примитивного приложения — яркий пример того, для чего существуют интегрированные среды разработки.
Таким образом, инструментарий превосходен, фреймворк превосходен, и инструментарий тоже превосходен. У вас есть масса инженеров с огромной продуктивностью, и теперь, благодаря LLM, даже ещё лучше. Это тот случай, когда генеративный ИИ просто великолепен для написания огромного количества неинтеллектуального кода. Эти инструменты отлично справляются с этим.
Conor Doherty: Так $20 миллиардов — вот что мы должны брать.
Joannes Vermorel: Да, так что это должно быть относительно, то есть, опять же, довольно дешёво для компаний как базовый вариант. Если вы в итоге заплатите более одной десятой того, что платили за аналогичные системы 10 лет назад, это обдирайство. Знаете, это должно быть вашим базовым уровнем. Таким образом, вы должны стремиться к тому: “Мы сделаем это снова, но с бюджетом в десятую часть.” И это даже не предел.
Я думаю, учитывая эволюцию технологий, это отправная точка. Я почти уверен, что если бы вы пошли по безумно агрессивному пути — скажем, если бы Илон Маск взялся за это — получилось бы: “Я сделаю это в 100 раз дешевле.” Но я бы сказал, что ваш следующий ERP-проект должен стоить в десятую часть от того, что вы тратили 10 лет назад. Думаю, это разумный базовый уровень, по крайней мере для систем учета.
Для системы отчетов технология довольно стандартизирована. Проблема в том, что она обычно оказывается очень затратной, потому что компания просто хочет несметное количество отчетов. Затраты связаны с индивидуальной разработкой неограниченного количества отчетов — безумно высокого их числа.
Таким образом, когда у вас есть система отчетов, в какой-то момент люди скажут: “О, но я бы хотел иметь несколько отчетов, готовых шаблонов прямо из коробки.” И тогда поставщик скажет: “Да, без проблем, сколько вам нужно?” И затем они предоставят список, и вы получите тысячи отчетов. Если вы так поступите, то это окажется невероятно дорого, просто потому что вы запрашиваете так много.
Так что здесь должно быть довольно дешево, потому что технология достаточно стандартизирована, но дороже, чем системы учета. Это сложнее, поэтому я бы не советовал разрабатывать всё самостоятельно. Но опять же, с open source технологиями, такими как Spark, это не так сложно. Хотя и сложнее, чем системы учета.
Здесь, я думаю, если вы хотите сдерживать бюджет, вам нужно держать свои требования под контролем. Существует соблазн, особенно в крупных компаниях, требовать бесконечный список отчетов, которые никто никогда не будет использовать. Это оказывается чрезвычайно дорого, потому что все эти люди время от времени должны просматривать эти цифры, и в этом нет особого смысла.
Так что держите это кратко и целенаправленно, и затраты не будут очень высокими. На самом деле, они должны быть намного меньше, чем ваши базовые затраты на ERP 10 лет назад. Я говорил, что новая ERP должна стоить почти в десять раз меньше. Система отчетов должна обходиться лишь в малую часть этих затрат, не более 20% от стоимости ERP следующего поколения.
Вот о чём мы говорим — о чем-то очень небольшом. В конечном итоге, отчёты не должны стоить миллионы или десятки миллионов за представление базовой описательной статистики о вашем бизнесе. В этом нет смысла. Технологии настолько продвинулись, что это должно быть очень дешёво.
Conor Doherty: Когда вы впервые предложили категоризацию трёх классов или классификацию трёх типов корпоративного ПО — вы — я не могу точно вспомнить соотношение, но это было что-то вроде: 90% вашего IT-бюджета должно идти на системы интеллектуальных решений.
Joannes Vermorel: Разделение, которое я предложил, было следующим: 20% для систем учета, 5% для систем отчетов и 75% для систем интеллектуальных решений. Вот что я предлагаю как эвристику для подавляющего большинства компаний.
В то время как сегодня происходит следующее: 75% на ERP, 20% на бизнес-аналитику или системы отчетов, и всего 5% на системы интеллектуальных решений. Я говорю, что эти цифры неверны. Их нужно поменять местами. Почему вы должны тратить основную часть своих денег на системы интеллектуальных решений?
Очевидно, что Lokad — это системы интеллектуальных решений, так что аудитория должна тратить на них много денег. Но реальность такова, что отдача от инвестиций именно в этом и проявляется. Именно здесь вы можете получить большую отдачу, если решения приняты правильно. Системы отчетов в основном нужны для того, чтобы убедиться, что у вас всё в порядке.
Они служат для того, чтобы оглянуться и проверить, соответствуете ли вы своим собственным процессам, идёте ли вы в ногу с планом. Но в основе ни одна компания не достигала огромного успеха, смотря только назад. Вот в чём проблема систем отчетов. Вы смотрите в зеркало заднего вида.
Если хотите выиграть гонку, нельзя выигрывать, постоянно глядя в зеркало заднего вида. В какой-то момент нужно смотреть вперёд.
Conor Doherty: Мне пришло в голову, что у меня действительно есть ноутбук передо мной, и у него есть Wi-Fi. Блог, о котором я говорил, на самом деле называется “The Three Classes of Enterprise Software”. Он был опубликован в июне прошлого года.
Чтобы уточнить цифры, вы правильно вспомнили, как компании, подавляющее большинство компаний, обычно распределяют свои расходы — их IT-бюджет: 75% на системы учета (вы шутливо добавили “неправильно” в скобках после этого), 20% на системы отчетов, тоже “неправильно”, и 5% на системы интеллектуальных решений, с добавлением “совершенно неправильно” в конце.
То есть перевернуто: 75% на системы интеллектуальных решений, 5% на системы отчетов и 20% на системы учета. Ну, я настоятельно рекомендую прочитать блог. Он очень хорош.
А теперь, последний вопрос, прежде чем мы начнем завершать, и он возник у меня. Это момент, который вы уже поднимали ранее и в своих лекциях, и который я несколько раз упоминал в разговорах здесь: роль механической симпатии. И нам не нужно долго об этом говорить, но мне кажется, что базовое знакомство, скажем, с тем, какие параметры или архитектурные решения необходимы для успеха в инструменте, который вы собираетесь купить, имеет значение.
Если вы хотя бы немного в курсе этого, вы сможете понять: “Возможно, это не для меня.” Так что, ещё раз, даже разница между колонковыми и табличными базами данных — если вы хорошо понимаете, что использует эта система и для чего вам она нужна, это может сразу заставить вас пересмотреть потенциально дорогое решение.
Joannes Vermorel: Да. И опять, если вернуться к ошибкам, которые совершила SAP в 2010 году… То есть, HANA была выпущена в 2010 году, так что, вероятно, они уже несколько лет работали над этим. И в то время, я предполагаю, это выглядело как хорошая идея, знаете, казалось: “Ладно, давайте предположим, что задержки в компьютерных системах просто улучшатся, будут продолжать улучшаться, а память станет намного дешевле.”
Ведь если мы посмотрим, в чем большая разница между 2010 годом и, скажем, 15 лет назад, в 1995 году. За эти 15 лет память стала радикально дешевле и радикально более доступной. Я помню, в 1995 году, первый компьютер, которым я пользовался, Windows 95, имел примерно 8 мегабайт памяти.
А затем, к 2010 году, я полагаю, это был Windows 7 или что-то в этом роде. Я предполагаю, что в то время у меня было 8 гигабайт, знаете, так что память увеличилась в тысячу раз за этот период. А задержка сократилась примерно в 50 раз или что-то подобное.
Итак, если бы всё продолжалось в том же направлении, это было бы невероятно. Это означало бы, что, знаете, в 2010 году у меня было 8 ГБ на компьютере. Если бы через 15 лет всё улучшилось тем же образом, сегодня у меня было бы 8 терабайт на компьютере. Конечно, это не то, что у меня сейчас. Никто не располагает 8 терабайтами на своём компьютере.
Но вы видите, что если бы технологии развивались так же, как за предыдущие 15 лет, у людей было бы именно столько. И если бы у нас также снизилась задержка, проблема в том, что скорость света — это настоящая головная боль, понимаете. Физика не играет в нашу пользу. Эта скорость света как бы мешает.
Но, тем не менее, я думаю, именно в этом и заключалась их трагическая ошибка. А затем из-за этого пришлось чрезмерно усложнять так много вещей, потому что это что-то вроде первородного греха. Из-за этого пришлось применять кучу временных решений, чтобы… Когда у вас есть масштабная проблема в дизайне, можно попытаться заклеить её скотчем. Можно, но всё будет работать неуклюже.
Итак, когда вы сталкиваетесь с проблемами производительности, вы можете решить их, добавив дополнительное аппаратное обеспечение. Да, вы, конечно, можете начать покупать супердорогое оборудование — это будет первым шагом. Но затем можно чрезмерно усложнять определённые вещи, чтобы они не работали слишком неэффективно. Потому что, в основном, при достаточном уровне инженерии, некоторые из этих проблем можно смягчить.
Но, тем не менее, SAP хочет охватить всё, с той амбициозностью, о которой я говорил. Вы хотите быть системой учета для одной области, а они хотят быть системой учета для всего. Это означает, что площадь, где могут возникать проблемы с производительностью именно из-за этого выбора, просто колоссальна.
И я считаю, что мы видим, как всё происходит в замедленном режиме, как вещи медленно рушатся. Вот что мы наблюдаем. Это занимает много времени. Понадобилось пять лет, чтобы выпустить ERP на базе HANA, это S/4. А затем потребовались годы, чтобы продать ERP их первой компании.
Потому что, опять же, когда вы хотите продать корпоративное программное обеспечение, сделку не заключаешь за шесть месяцев; это часто занимает несколько лет. Так, внедрение длится примерно полдесятилетия, а затем, может быть, после пяти лет это и становится вашим планом для обновления.
Это безумие. Но реальность такова, что вы начинаете терпеть неудачи, потому что на это уходит не полдесятилетия, а целое десятилетие. Мы просто становимся свидетелями провалов, вызванных ошибочными решениями, принятыми много лет назад. И мы прослеживаем их на протяжении прошлых десятилетий. Думаю, мы будем продолжать видеть, как эти проблемы вновь возникают, но это не ново. Это всего лишь отражение ошибок, совершённых давно.
И теперь единственное, что мы действительно можем посоветовать, — это не повторять древние ошибки. Но самое безумное то, что эти ошибки были совершены так давно, что люди в SAP… то есть ошибки SAP и людей, которые их приняли, думая, что это правильно.
И интересное дело в том, что эти ошибки были совершены так давно, что люди могут подумать: “О, но сейчас всё должно быть в порядке.” Они собрали свои дела. Они собрали свои умы. Это решено. Потому что, очевидно, если бы я в роли поставщика предлагал такой продукт, я бы сказал: “Уважаемый клиент, будьте уверены, что мы извлекли уроки из наших ошибок. Эти недостатки исправлены. Мы так многому научились на этих ошибках. Они больше не повторятся.”
Я бы сказал, не совсем, потому что проблема всё ещё укоренена в самой основе вашей технологии. HANA по-прежнему занимает центральное место во всех предложениях SAP. Пока она здесь… Да, вы в беде. Вам придётся распутывать всё это, чтобы, возможно, войти в более здравые области.
В наши дни, если они не изменят курс и просто не уберут HANA, не перейдут на PostgreSQL или иной open-source, а затем не пересмотрят своё предложение так, чтобы получить легкие приложения с чётким разделением, — интеграция через интернет сегодня довольно проста, — они могли бы создать супер модульный дизайн.
Если они не начнут это делать, изначальные грехи остаются: амбиция быть системой для всего плюс неправильный движок в основе системы.
Conor Doherty: Ну, чтобы закончить на позитивной ноте, есть ли какие-нибудь конструктивные советы, которыми вы могли бы поделиться с людьми, чтобы они, возможно, смогли обойти, как бы сказать, “минные поля”, созданные некоторыми из этих огромных компаний?
Joannes Vermorel: То есть, по-настоящему положительный момент, и это то, что огорчает меня, когда я вижу эти ошибки, заключается в том, что сообщество с открытым исходным кодом предоставило нечто невероятно замечательное. PostgreSQL — это чудо инженерного искусства. Это open source. Это магия.
Мы живем в эпоху, когда, буквально, за небольшую цену — правда, за ваше интернет-соединение, конечно, нужно платить — но за невероятно низкую цену вы можете получить великолепно разработанные системы или инженерные решения, которые представляют сотни лет опыта некоторых из самых блестящих инженеров нашего века. Это невероятно, и вы можете получить это бесплатно. Вот мое мнение.
