Жоаннес Верморель, март 2020 г.Под планированием ресурсов предприятия (ERP) подразумевается целый класс программ для поддержки повседневных операций компании и отслеживания ее ресурсов, в особенности наличных денежных средств, сырья, заготовок в работе, конечной продукции, клиентских заказов, заказов на закупку и заработных плат. Системы ERP обычно включают себя множество модулей для ключевых коммерческих функций — бухгалтерии, поставок, дистрибуции, финансов, продаж и т. д. — которые хорошо интегрированы в единую систему для обеспечения надлежащего потока информации (об операциях) между функциями. В основе систем ERP обычно лежат реляционные базы данных, и в целом они достаточно громоздки: в них используется большое число разнообразных единиц (товаров, клиентов, счетов и т. д.), различные интерфейсы, и все это к тому же можно настраивать.
Происхождение и предпосылки
Уже в 70-е годы появилось понимание, что электронный документооборот дает множество преимуществ по сравнению с традиционным бумажным. Использовать электронные документы становилось все дешевле, системы становились все быстрее и надежнее. До появления ERP огромную роль в распространении электронного документооборота сыграли два изобретения: сканеры штрих-кодов (1950-е) и реляционные базы данных (1970-е). Сканеры штрих-кодов позволяли эффективнее и с меньшим количеством ошибок управлять потоками товаров. Тем не менее, хотя они позволили значительно улучшить сбор данных во многих ситуациях, проблема хранения, организации и обработки электронных данных оставались открытой еще два десятилетия. Реляционные базы данных, которые появились в конце 70-х годов, позволили ее решить. С тех пор прошло пятьдесят лет, а реляционные базы данных до сих пор являются ядром большинства систем управления коммерческими данными.
Однако простые системы с реляционными базами данных, которые продавались в начале 80-х, были очень дорогими, потому что каждой компании приходилось самостоятельно решать, в каком виде представлять данные: товары, клиентов, счета, выплаты и т. п. Так в 80-е появились разработчики, которые продавали системы с «настроенными» реляционными базами. Позже такие системы стали называть ERP — данное наименование появилось только в 90-е. К сожалению, сам термин ERP (планирование ресурсов предприятия) не очень удачный: точнее было бы сказать «управление», а не «планирование». В самом деле, планирование — это в лучшем случае второстепенная задача для ERP. Как будет видно далее, прогностическая аналитика идет вразрез с основными принципами ERP.
Системы ERP стали популярны, потому что они упрощали целые серии операций, которые раньше требовали значительных усилий. Например, для размещения заказа на закупку товара нужно было указать имя и адрес поставщика в специальной форме. В самом заказе можно было указывать только действующие артикулы изделий. Затем по получении товара нужно было проверить, совпадает ли полученное количество с заказанным, после чего доставка
подтверждалась, и нужно было составлять платежное поручение по шаблону с указанием надлежащей суммы, даты, соответствующей требованиям поставщика об оплате, и с точным указанием его банковского счета. Все это было в ERP, и эти системы позволяли автоматически производить проверку соответствия.
Рынок ERP стал быстро расти в конце 90-х, что было связано с постоянным развитием вычислительной техники (процессоров, оперативной памяти, систем хранения информации), так что эти системы стали доступны компаниям любого размера.
В 90-е системы ERP стали программным ядром большинства крупных компаний, где коммерческая деятельность вращалась вокруг потока товаров. Компании, которые работали в основном в сфере услуг, напротив, выбирали системы управления отношениями с клиентами (CRM). У ERP и CRM много общего — например, и те, и другие используют реляционные базы данных. В центре внимания большинства функций систем ERP находятся операции, тогда как системы CRM направлены на клиентов.
Разработки ERP
Системы ERP весьма разнообразны, поскольку на рынке есть множество разработчиков, которые продвигали свою продукцию в течение нескольких десятилетий. Тем не менее большинство из них построены на очень схожих принципах. С самого начала ERP представляли собой «настроенное» ПО, в основе которого лежали реляционные базы данных. Таким образом, процесс разработки ERP подразумевает составление следующих списков:
- единицы — все предметы или понятия, которые должны быть отражены в ERP, например товары, платежи, поставщики и т. д. Каждой единице может соответствовать одна или несколько таблиц в соответствующей реляционной базе данных. Большинство ERP определяют сотни единиц, а самые сложные из них — до нескольких тысяч.
- пользовательские интерфейсы — чтобы конечные пользователи могли просматривать и редактировать данные единиц. Интерфейсы создаются по принципу CRUD (создание / чтение / обновление / удаление), определяющему самые базовые операции, которые конечный пользователь может производить с единицами.
- бизнес-процессы — дают возможность автоматического выполнения множества офисных задач, если их можно автоматизировать с помощью четких правил — например, клиентские заказы можно преобразовывать в счета.
Поскольку коммерческая деятельность сложна, и она различается в зависимости от компании, то и потребность в постоянном добавлении или редактировании единиц, пользовательских интерфейсов и бизнес-процессов никогда не исчезает — это необходимое условие работы системы в развивающейся компании. Все это требует от поставщиков ERP постоянно прикладывать огромные усилия. Ситуация усугубляется погрешностями, которые появляются при использовании одной системы в очень разных сферах. Одно и то же понятие «платеж» может означать совершенно разные вещи и процессы в зависимости от отрасли, в которой работает компания. В сфере программирования сложность приводит к нелинейным затратам: добавление двойного набора функций в продукт обходится намного дороже, чем его исходная стоимость помноженная на два.
Как следствие, поставщики ERP разработали определенные стратегии повышения конкурентности своих инвестиций в ПО.
Технология
Первая стратегия, которой пользуются разработчики ERP для борьбы со сложностью, заключается в разработке технологий, которые позволили бы снизить расходы при работе с ней.
В частности, многие поставщики ERP разрабатывали предметно-ориентированные языки (DSL), которые должны были дополнять базовые языки запросов для реляционных баз данных, которые лежали в основе всего — сегодня они обычно представляют собой языки структурированных запросов (SQL). Хороший DSL, который расширяет возможности ERP (добавляет новые единицы, интерфейсы или процессы), позволяет проще подстраиваться к особенностям конкретной компании, нежели если делать это с помощью обычного языка программирования.
Начиная с 2000-х, поставщики ERP
с открытым кодом, которые появились в конце 90-х вместе с реляционными базами данных с открытым кодом, часто использовали иную стратегию подстраивания (вместо DSL): ERP дополнялись кодом, который был уникален для каждого клиента и который был написан на том же обычном языке программирования, что и сама ERP-система. Поставщикам ERP проще реализовать именно такую стратегию (так как не нужно разрабатывать DSL), и она согласуется с принципом открытого кода самой ERP.
Предложение
Из-за того что увеличение числа функций приводит к росту расходов на их реализацию и поддержку, большинство поставщиков ERP переходят на продажу системы по модулям: функции группируются в наборы или «модули», которые соответствуют определенным сферам деятельности компании типа управления запасами, финансов, выплат и т. п. Системы ERP продаются по отдельным модулям, что позволяет клиентам выбирать наиболее интересные наборы функций, оставляя остальное на потом.
Эта стратегия позволяет поставщикам ERP естественным образом повышать дополнительные продажи среди существующей клиентской базы. Если какие-либо сферы деятельности не были отражены в первоначальном наборе модулей ERP-системы, то при появлении соответствующих функций их можно предлагать клиентам.
Стратегия модульных продаж — это эффективный механизм для борьбы со сложностью, потому что она позволяет разработчикам ERP-систем выяснить, за какие функции клиенты охотнее заплатят. Таким образом, она помогает поставщикам правильно устанавливать приоритеты при разработке ПО,
Экосистема
Чем больше функций добавляется в ERP-системы, тем меньше обычно прибыль для разработчика, который правильно расставил приоритеты (1). На самом деле, если функция не появилась раньше, то, вероятно, дело в том, что она нужна далеко не всем компаниям. Кроме того, сами организации — в том числе поставщики ERP-систем — часто несут убытки от масштаба: подключение к работе над системой дополнительных специалистов обычно не приносит очевидных плюсов с точки зрения улучшения продукта.
Именно поэтому большинство поставщиков ERP-систем применяют экосистемную стратегию: они делегируют
последние этапы разработки, необходимые, чтобы их ERP-система заработала в определенной компании, сторонним организациям, так называемым
интеграторам. Интеграторы берут с клиентов деньги за развертывание и реализацию всех возможностей ERP, которые не заложены в «сырую» систему. Вплоть до 2000-х при первом приобретении компанией ERP-системы работа интеграторов заключалась в основном во внедрении дополнительных возможностей. Сегодня большинство ERP-проектов представляют собой работу по
переходу на новый уровень и отказ от
старых ERP-систем. Таким образом, заслуга интеграторов заключается по большому счету в том, чтобы обеспечить плавный переход от старой ERP-системы на новую. На практике это подразумевает перенос данных и процессов из одной системы в другую.
В отличие от поставщиков ERP, коммерческие стратегии которых направлены непосредственно на их ERP-системы, которые считаются объектами интеллектуальной собственности, интеграторы часто работают по трудодням. Они выставляют счета в зависимости от того, сколько дней проработали, тогда как права интеллектуальной собственности на выполненные работы, как правило, переходят клиенту в соответствии с договором.
Создание экосистемы из разнообразных интеграторов, которые будут работать в различных регионах и отраслях — это эффективный способ снижения сложности при разработке ERP-систем. Практически у всех крупных поставщиков ERP-систем есть обширные сети интеграторов.
Ограничения ERP-систем
Системы ERP имеют большинство тех же ограничений, что и реляционные базы данных, которые лежат в их основе (2). Стратегии, направленные на снижение сложности, которые мы описали в предыдущем разделе, также накладывают свои ограничения. Эти ограничения крайне важны, потому что они являются
«врожденными» для ERP-систем и вряд ли будут сняты в новых версиях. Более того, для устранения этих ограничений могут потребоваться такие глубокие изменения, что итоговый продукт едва ли можно будет назвать ERP-системой.
Лучше, чем просто чтение и запись данных
Реляционные базы данных, которые используются в ERP-системах, имеют следующие свойства: атомарность, согласованность, изолированность, долговечность (ACID), которые достигаются благодаря тому, что работа с ними подразумевает в основном операции чтения и записи небольшого количества данных, которые должны выполняться с небольшим периодом ожидания (как правило, выражающимся в долях секунды), причем считано и записано должно быть примерно одинаковое количество информации. Подробный разбор реляционных баз данных не входит в задачи данной статьи, однако понимание
предполагаемых рабочих процедур в ERP-системах помогает осознать их ограничения.
Из-за того что в основе ERP-систем лежат реляционные базы данных, они чаще всего непригодны для аналитики, статистической обработки данных и составления отчетов по большим объемам данных. Обработка больших объемов информации в любой ERP-системе — при том что работа компании не останавливается — это
всегда сложная задача, потому что из-за большого количества операций считывания или записи система замедляется. На практике это означает, что такие рутинные действия, как считывание штрих-кодов, тоже происходят медленнее. В худших случаях вся деятельность компании останавливается. Таким образом, необходимо, чтобы все операции в ERP-системе, будь то чтение или запись, были маленькими, «тривиальными». Благодаря развитию и удешевлению вычислительной техники граница большого объема данных значительно повысилась за последние сорок лет. Однако увеличился и объем данных, которые стали попадать в ERP-системы. Как следствие, быстродействие современных ERP-систем за двадцать лет увеличилось не очень заметно.
Например, ERP-системы отлично подходят для отображения уровня запасов по
SKU или для изменения соответствующих значений, когда единица товара добавляется или убавляется, однако они не подходят для отображения ежедневных общих колебаний запасов по SKU за последние три года. Реакцией на ограничения ERP-систем (как и CRM) в плане аналитики стало возникновение в 90-е годы целого сегмента ПО — систем бизнес-аналитики (BI). В отличие от ERP системы BI строятся на
гиперкубах в оперативной памяти, и их часто называют системами оперативной аналитической обработки (OLAP). Отказываясь от ACID, системы OLAP оказываются куда более эффективными, чем реляционные базы данных, с точки зрения оборудования. Они способны выдавать обобщенные статистические данные, например продажи по дням, магазинам, категориям и т. д.
Любопытно заметить, что большинство поставщиков ERP-систем, похоже, не вполне понимали ограничения собственной продукции, даже если они появились на рынке
после 90-х, когда системы BI уже сделали эти ограничения очевидными. Например, большинство поставщиков ERP-систем стали заниматься прогнозированием спроса, несмотря на то что его сложно реализовать в реляционных базах данных, сложнее даже, чем организовать обычные функции
отчетности. Для прогнозирования требуется доступ ко всем данным об операциях компании: продажам, прибыли, уровням запасов, скидкам и т. д. Расчеты, как правило, предполагается выполнять ночью, чтобы сгладить последствия недостатка ресурсов, о которых мы писали выше, однако такие расчеты в реляционных базах данных подразумевают высокие накладные расходы. Как следствие, сегодня в большинство ERP-систем внедряются возможности прогнозирования (3), которые устарели много лет, а то и десятилетий назад.
Лучше, чем новые или уникальные парадигмы
Стратегия составления перечня единиц, которая используется поставщиками ERP-систем, не предполагает возможности линейного масштабирования для управления сложностью. Улучшенные инструменты, как уже говорилось выше, позволяют лишь немного снизить нагрузку (с точки зрения количества единиц), тогда как расходы из-за сложности растут в геометрической прогрессии. Как следствие, новые или уникальные парадигмы обычно оказываются дорогостоящими как в плане расходов, так и в плане задержек интеграции — порой даже оказывается, что проще вообще отказаться от ERP-системы. Таких ситуаций великое множество, и мы перечислим ниже лишь некоторые из них. Все они сводятся к парадигмам, которые сложно интегрировать, потому что они слишком
поздно появились в ERP-системах (4).
Достижение
нулевого операционного простоя является сложной задачей, потому что, как говорилось ранее, чтение или запись больших объемов данных может привести к замедлению работы ERP-системы. Поэтому такие операции выполняются ночью, когда большинство или вообще все другие процессы остановлены. Однако такой порядок не согласуется с условиями работы интернет-компаний, которые появились значительно позже первых ERP-систем. В результате большинство поставщиков ERP-систем стали отделять модули для интернет-торговли и зачастую создавали для них собственные базы данных — это нарушало один из ключевых принципов ERP-систем: все модули должны работать на одной базе. Как следствие, развертывать модули интернет-торговли в ERP-системах зачастую сложно и дорого, и они выглядят, как сторонние приложения.
В сфере
заводского восстановления изделий товары движутся по сложным циклическим потокам (ремонтным), тогда как наиболее популярные ERP-системы рассчитаны на
прямые потоки — от производителя к потребителям — как это обычно бывает в дистрибуции и продажах ходовых товаров. Несмотря на то что большинство единиц (товаров, запасов, заказов), используемых при восстановлении, уже есть в ERP-системах, они совершенно не подходят для данной отрасли. Чаще всего под определенные отрасли проще создать новые единицы, чем настроить те, что уже существуют в традиционных ERP-системах.
Гарантированно поддерживать
небольшой период ожидания, скажем, менее 50 мс (что незаметно для человека), крайне сложно, потому что ни ERP-системы, ни реляционные базы данных не разрабатывались под соответствующие требования. Тем не менее для управления системами с высокой степенью автоматизации, такими как роботизированные склады, требуется как раз такой период ожидания, чтобы ПО не тормозило работу всей системы. Именно поэтому во многих сферах, где требуется обработка «в режиме реального времени» (4), используется что-то кроме ERP.
Интересно отметить, что существуют специальные ERP-системы (создатели которых открещиваются от такого определения), которые пошли несколько иным путем как раз для работы с подобными случаями. Такие ERP, как правило, разрабатываются под конкретные отрасли, с которыми не справляются обычные ERP-системы. С другой стороны, такие альтернативные варианты часто не соответствуют стандартным требованиям.
Риски при переходе с одной ERP-системы на другую
Это может показаться странным, но чаще всего
обновить ERP-систему гораздо сложнее, чем просто
развернуть ее с нуля. Переход на новую систему может длиться годами. Даже просто обновление
версии ERP — когда поставщик остается прежним — обычно оказывается сложной задачей на несколько месяцев труда. Забавно видеть, как эта проблема регулярно мелькает в новостях, где крупные компании публикуют пресс-релизы, в которых говорится, что на обновление ERP-системы у них ушло на сотни миллионов долларов или евро больше, чем планировалось изначально. В этом обвиняют поставщиков ERP, интеграторов и/или саму компанию. Однако мало кто понимает, что подобные проблемы
естественны для ERP-систем, и они определяются рыночными силами, о которых говорилось выше.
Расходы из-за сложности растут не в арифметической, а в геометрической прогрессии. Если компания приобретает ERP-систему впервые, то она может постепенно приобретать модуль за модулем. Таким образом, число единиц / интерфейсов / процессов в каждом модуле сравнительно небольшое, а потому разработать специальные расширения для подстройки ERP-системы под потребности компании вполне возможно.
Если же компания хочет перейти с одной ERP-системы на другую, то ей приходится переносить
все модули одновременно. С точки зрения дизайна и экономических сил (5), системы ERP представляют собой
программные монолиты, которые выстраиваются на небольшом наборе баз данных. Таким образом, развертывание новой ERP-системы не может идти
пошагово, как в случае с первой системой. Компании приходится идти ва-банк. Как следствие, расходы на реализацию проекта сразу же вырастают до небес. По завершении перехода система работает через раз, и на устранение недоработок уходит несколько лет.
С технической точки зрения осуществлять переход всегда сложно, потому что импорт единиц / интерфейсов / процессов из старой системы в новую выполняется один к одному. Семантика единиц меняется с течением времени. Например, изначально поставщик ERP-системы мог предлагать помещать в таблицу «Заказы» запросы, которые компания получает от клиентов. Через некоторое время появились новые требования, которых не было изначально — теперь поставщик должен учитывать возвраты товара. В следующей версии ERP-системы в таблицу «Заказы» начинают попадать и возвраты, только теперь в соответствующих ячейках ставится знак «минус». Такое, казалось бы, безобидное изменение крайне осложняет переход со старой версии ERP-системы на новую.
Тем не менее переход на новую систему или на новую версию существующей ERP-системы — не
единственный выход для компании. Существуют различные варианты снижения рисков при переходе. Разумеется, поставщики ERP-систем и интеграторы заинтересованы в обратном — это залог их выживания при существующей экономической модели.
За пределами монолита
ERP-системы с самого начала были
программным монолитом. Иначе говоря, все их внутренние компоненты были тесно связаны — это обязательное условие для
автоматической конфигурации новых модулей при подключении. Кроме того, до 2010-х создание распределенных систем — т. е. программ, которые работали бы с огромным количеством машин, а не с несколькими центральными компьютерами — было очень сложной и дорогой задачей (6). Во многом из-за этого поставщикам ERP-систем (которым тогда было по несколько десятков лет) не оставалось ничего, кроме как создавать монолитные продукты.
Тем не менее по мере распространения облачных вычислений определенные инструменты и библиотеки — зачастую с открытым кодом — стали более популярными и доступными. Как следствие, расходы на разработку распределенных приложений в последние десять лет постоянно снижались. Компании, занимающиеся разработкой ПО, стали искать новые способы создания добавочной стоимости, которая ранее создавалась лишь через ERP (или подобные системы).
Согласно современному подходу, корпоративное ПО из монолита должно превратиться в набор более мелких приложений, которые в идеале выполняют только одну функцию, но делают это хорошо (7). Соединение приложений выполняется с помощью интерфейсов прикладного программирования (API), которые как раз предназначены для интеграции различных приложений. Большинство API могут использовать популярные инструменты API с открытым кодом, что значительно снижает расходы на разработку и интеграцию.
Расходы на интеграцию таких приложений иногда выше, чем для встроенных модулей ERP-систем. Однако это выгоднее в долгосрочной перспективе, потому как такая интеграция значительно снижает риски, связанные с дальнейшим развитием информационной среды компании. Компания получает возможность оптимизировать или заменять по одному приложению за раз, что не только проще, но и дешевле, да и риски в таком случае ниже. Наконец, приложения, поставляемые как услуга (SaaS), как правило, рассчитаны на поэтапное внедрение небольших изменений. Такая схема обеспечивает постоянную, но ограниченную нагрузку на сотрудников информационного отдела, а потому процесс обновления в SaaS представляется нам более органичным, и он сопровождается меньшими рисками и затратами, нежели ежегодные или двухлетние обновления.
За пределами реляционных баз данных
Реляционные базы данных были
де-факто основой ERP-систем с 80-х годов. С 2010-х появились привлекательные альтернативные варианты. Самым заметным, вероятно, является
порождение событий (ES) вместе с
разделением ответственности на команды и запросы (CQRS). Данный подход обеспечивает непревзойденные возможности масштабирования при минимальных периодах ожидания, а также более точно отражает цели компании в различных ситуациях.
Суть
порождения событий заключается в том, что каждое изменение системы рассматривается как неизменное событие. Принцип неизменности был заимствован из бухучета: при обнаружении ошибки в книге учета бухгалтер не уничтожает старые данные, но добавляет дополнительную строку с правками. Хранение данных обо всех событиях (при условии что расходы на их хранение достаточно невелики, чтобы был смысл использовать эту стратегию) приносит много пользы: улучшается контролепригодность, аудитопригодность, безопасность и т. д. Кроме того, такой подход упрощает масштабирование систем на базе событий. Данные можно копировать и повторять, не обращая внимания на изменения в них.
Подход
CQRS основан на предположении, что в большинстве систем объемы
считывания и
записи данных сильно различаются. Во многих случаях объем считанных данных превышает объем записанных данных на несколько порядков. Реляционные базы данных, напротив, ориентируются на сбалансированное (в определенной мере) соотношение чтения и записи данных. Системы CQRS четко разделяют ответственность за считывание и запись — для этого обычно создаются две разных подсистемы. Это также полезно с точки зрения периода ожидания, возможностей масштабирования и эффективности работы оборудования.
Хотя ES и CQRS весьма популярны в крупных потребительских технологических компаниях и в количественном трейдинге (финансы), они лишь недавно начали применяться в базовых коммерческих программных системах. Как следствие, инструменты ES+CQRS находятся еще в процессе разработки, в отличие от реляционных баз данных. Тем не менее данный подход позволяет не только резко снизить расходы на оборудование, но и сократить период ожидания, который раньше был острой проблемой для большинства ERP-систем.
Точка зрения Lokad
Системы ERP не подходят для аналитики — отсюда и потребность в инструментах бизнес-аналитики (BI) — поэтому их результаты в сфере
прогностической аналитики не впечатляют. На самом деле, революции в сфере машинного самообучения и интеллектуальной обработки данных не затронули ERP-системы, поэтому при работе с соответствующими требованиями до сих пор используются электронные таблицы или
ситуативные скрипты.
Даже система Lokad появилась как специализированное аналитическое приложение для прогностической оптимизации цепей поставок, которое дополняло бы — но не заменяло — ERP-системы. Большинство наших ключевых функций, такие как
вероятностное прогнозирование, предназначены для поддержки рутинных решений, связанных с запасами / закупками / производством / ассортиментом / расценками, и их просто-напросто непрактично применять в рамках ERP-систем.
Примечания
(1) Данный подход немного упрощает ситуацию. На практике разработка ПО за последние несколько десятилетий сделала огромный скачок вместе с вычислительными ресурсами. В результате возможности, которые были бы слишком дорогостоящими в 80-е, спустя несколько десятилетий могли оказаться значительно более дешевыми. Понимая это, поставщики ERP действительно пересматривают приоритеты в своей работе.
(2) Самые первые ERP-системы из 70-х или, вернее сказать, ERP-подобные программы, потому как данный термин появился намного позже, полагались на примитивные базы данных в виде неструктурированных файлов. Реляционные базы данных были лучше неструктурированных файлов практически во всех отношениях. Таким образом, первые разработчики ERP-систем успешно перешли на реляционные базы данных. Тем не менее при обработке всей базы данных целиком неструктурированные файлы на практике были эффективнее при одинаковых вложениях в оборудование, по крайней мере, до тех пор, пока в 2010-х не появились реляционные базы данных со столбцами.
(3) Из-за того что многие поставщики ERP-систем пробовали разрабатывать и внедрять прогностические
функции, поставщики баз данных, в свою очередь, тоже пытались добавлять такие
возможности в свои системы. Насколько мне известно, такие встроенные «возможности прогнозирования» в базах данных встречаются очень часто и почти никогда не используются (либо выдаваемые ими результаты тщательно подгоняются в таблицах Excel). В итоге они нужны только поставщикам для обратной совместимости.
(4) Обработка данных в режиме реального времени — это очень субъективный термин. С технической точки зрения, даже скорость света накладывает строгие ограничения на то, какой период ожидания может быть достигнут в распределенных системах. Весь смысл ERP-системы заключается в координации поставщиков, фабрик, складов и т. д., расположенных в разных регионах.
(5) Главный коммерческий аргумент при поэтапной покупке системы заключается в том, что конфигурация новых модулей происходит (почти)
автоматически. Цена за простоту установки — жесткая связь между модулями, т. е. монолитный дизайн. Изменения в одном модуле будут иметь последствия для множества других.
(6) Распределенные компьютерные системы появились много десятилетий назад. До широкого распространения
облачных вычислений в 2010 году почти все коммерческое ПО строилось по модели клиент-сервер, когда все процессы и данные централизованы на нескольких устройствах. Обычно это внешний интерфейс, серверная часть и база данных. Облачные вычисления, напротив, задействуют целую
армию машин — это позволяет повысить надежность и производительность.
(7) Такой была исходная философия Unix. Специализированные коммерческие приложения, появившиеся после 2010-х, как правило, не такие узконаправленные, как инструменты Unix. Кроме того, эти приложения уже на один или два порядка менее сложны, чем ERP-системы. Также не следует путать данный подход с микросервисами — это способ внутренней разработки самих приложений.
