Планирование ресурсов предприятия (ERP)

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-системе, таких как продукты, платежи, запасы, поставщики… Каждая сущность может занимать одну или несколько таблиц в основной реляционной базе данных. Большинство ERP-систем определяют сотни сущностей, а в самых сложных - до тысяч.
• пользовательских интерфейсов, которые позволяют конечным пользователям просматривать и редактировать данные сущностей. Эти интерфейсы основаны на CRUD-дизайне (Создание / Чтение / Обновление / Удаление), который представляет собой базовый набор операций, ожидаемых конечными пользователями при работе с сущностями.
• бизнес-логики, которая обеспечивает автоматизированное выполнение процессов, устраняя необходимость во многих канцелярских задачах, которые можно автоматизировать на основе чётких правил, например, преобразование заказов клиентов в счета-фактуры.

Поскольку бизнесы невероятно разнообразны и сложны, существует непрекращающийся поток потребностей в новых или усовершенствованных сущностях, пользовательских интерфейсах и бизнес-логике, необходимых для охвата развивающихся бизнес-практик. Это представляет собой огромные текущие усилия со стороны поставщиков ERP-систем. Затем эта задача усугубляется всеми неясностями, возникающими при попытке обслуживать очень разнообразные вертикали. Один и тот же термин, например «платеж», отражает совершенно разные реалии и процессы в разных отраслях. В программном обеспечении сложность, как правило, несёт с собой нелинейные затраты, т.е. поддержка в два раза большего количества функций в продукте стоит намного больше, чем в два раза превышает первоначальные затраты.

В результате поставщики ERP-систем приняли ряд стратегий, чтобы сделать свои программные инвестиции более конкурентоспособными.

Технологии

Чтобы справиться со сложностью, первая стратегия, применяемая поставщиками ERP-систем, заключается в разработке технологий с явной целью снизить затраты, связанные с управлением сложностью.

В частности, многие поставщики ERP-систем создали языки DSL (Domain Specific Programming), предназначенные для дополнения основного языка запросов – ныне обычно это разновидность SQL – используемой в реляционной базе данных. Благодаря хорошо продуманному DSL расширение ERP-системы (т.е. добавление новых сущностей, интерфейсов или логики) для охвата особенностей конкретной компании может быть выполнено с меньшими затратами по сравнению с использованием универсального языка программирования.

Начиная с 2000-х, поставщики ERP-систем с открытым исходным кодом, возникшие с использованием открытых реляционных баз данных, ставших доступны в конце 90-х, обычно приняли альтернативную стратегию плагинов (вместо DSL), при которой ERP-система рассчитана на расширение посредством внедрения пользовательского кода, адаптированного для каждой клиентской компании и написанного на том же универсальном языке программирования, что и сама ERP-система. Эта стратегия проще в реализации для поставщика ERP (не требуется разработка DSL) и соответствует природе ERP с открытым исходным кодом.

Предложение

Поскольку затраты на внедрение и поддержку функций растут с увеличением их общего количества, большинство поставщиков ERP-систем применяют ценовую стратегию, основанную на модулях: функции объединяются в «модули», которые охватывают отдельные функциональные области внутри компании: управление запасами, финансы, расчёт заработной платы и т.д. ERP-система продаётся по модулям, что позволяет клиентским компаниям выбирать наиболее актуальные модули и откладывать остальные для последующих инвестиций.

Стратегия ценообразования на основе модулей также предоставляет поставщику ERP-систем естественную стратегию дополнительных продаж, где существующая клиентская база становится основным целевым сегментом для будущих продаж. Бизнес-области, которые изначально не охватывались первоначальным набором модулей ERP-системы, получают новые специализированные модули, которые, в свою очередь, могут быть проданы клиентским компаниям.

Эта стратегия ценообразования на основе модулей является эффективным механизмом для управления сложностью, поскольку она даёт поставщику ERP-систем прямую обратную связь о тех функциональных областях, где готовность платить наибольшая. Таким образом, она помогает поставщику правильно приоритизировать свои усилия в области разработки программного обеспечения.

Экосистема

Каждая дополнительная функция, добавляемая в ERP-систему, как правило, приносит все меньшую отдачу для поставщика ERP, который правильно приоритизировал свои усилия в области разработки программного обеспечения¹. Действительно, если эту функцию не добавили ранее, скорее всего, это было связано с тем, что она не была достаточным образом актуальна для компаний с самого начала. Затем, сами организации — включая поставщиков ERP — также подвержены дисэкономии от масштаба: добавление дополнительных разработчиков в программный продукт, как известно, не приводит к линейному увеличению эффективности внесённых улучшений.

Таким образом, большинство поставщиков ERP-систем принимают стратегию экосистемы, делегируя последние этапы разработки, необходимые для запуска ERP-системы в данной компании, сторонним компаниям, обычно известным как интеграторы. Эти интеграторы взимают плату с клиентских компаний за внедрение и запуск всех возможностей, которые не предоставляются «сырой» ERP-системой. Исторически, до 2000-х годов, когда компании впервые внедряли ERP-системы, работа интеграторов обычно была сосредоточена на добавлении дополнительных возможностей для ERP-системы. Однако в настоящее время большинство ERP-проектов представляют собой модернизации, поскольку устаревшая ERP-система уже находится в эксплуатации. Таким образом, основная добавленная ценность интегратора заключается в обеспечении плавного перехода от старой ERP-системы к новой. На практике эта работа включает миграцию данных и процессов между системами.

В отличие от поставщиков ERP, для которых бизнес-стратегия ориентирована прежде всего на саму ERP-систему и рассматривается как актив интеллектуальной собственности, интеграторы обычно применяют оплату по количеству отработанных дней. Они выставляют счета за свою работу на основе количества отработанных дней, а права на результаты работы, как правило, по контракту переходят к клиентской компании.

Развитие разнообразной экосистемы интеграторов, как по географическому признаку, так и по отраслям, является эффективным способом снижения врождённой сложности, связанной с разработкой ERP-систем. Практически все крупные поставщики ERP разработали значительные сети интеграторов.

Ограничения ERP-систем

ERP-системы унаследовали большинство ограничений своих базовых реляционных систем². Затем дополнительные ограничения возникают из-за стратегий смягчения сложности, которые мы только что описали в предыдущем разделе. Эти ограничения особенно интересны, поскольку являются конструктивными ограничениями, и, следовательно, маловероятно, что они будут устранены в новых версиях ERP-систем, или, точнее, их устранение, вероятно, приведёт к искажению ERP до такой степени, что дальнейшее использование этого термина будет терять смысл.

Неблагоприятные для объёмных операций чтения или записи

Реляционные базы данных, используемые в ERP-системах, обеспечивают свойства ACID (атомарность, согласованность, изоляция, долговечность) с конструкцией, ориентированной на нагрузку, преимущественно состоящую из небольших операций чтения и записи, которые должны выполняться с низкой задержкой — обычно долей секунды — при примерно равном объёме операций чтения и записи. Детальный анализ реляционных баз данных выходит за рамки данной статьи, но это наблюдение относительно предполагаемой нагрузки для ERP-систем само по себе объясняет многие плохо понимаемые ограничения ERP-систем.

Из-за своего конструктивного подхода на основе реляционных баз данных, ERP-системы в значительной степени не подходят для аналитики, статистики и отчётности, когда объём данных значителен. Доступ к значительному объёму данных в любой ERP-системе — в то время как бизнес-операции продолжаются — всегда является проблемой, потому что когда система испытывает нехватку ресурсов из-за слишком большого количества операций чтения или записи, её производительность падает. На практике это означает, что повседневные операции, такие как обработка штрих-кодов, также замедляются. В худшем случае вся компания может остановиться. Таким образом, каждая операция в ERP-системе, будь то чтение или запись, должна оставаться небольшой, в идеале «тривиальной». Объём данных, который можно считать значительным, резко вырос за последние четыре десятилетия благодаря улучшению и удешевлению компьютерного оборудования. Однако компании воспользовались этим прогрессом для значительного увеличения объёма данных, вводимых в их ERP-системы. В результате современные ERP-системы, как правило, не заметно быстрее, чем две десятилетия назад.

Например, ERP-системы хорошо подходят для отображения уровня запасов для SKU или для обновления его значения при выборе или погрузке единицы, но ERP-системы, как правило, не подходят для отображения консолидированной ежедневной временной шкалы вариаций запасов для SKU за последние три года. Весь сегмент программного обеспечения для Бизнес-аналитики (BI) появился в 90-х годах в качестве отраслевого ответа на аналитические ограничения ERP-систем (и CRM-систем в равной степени). В отличие от ERP-систем, BI-инструменты сконструированы вокруг гиперкубов в памяти, обычно называемых OLAP (Online Analytical Processing). Отказываясь от свойств ACID, OLAP-системы становятся значительно более эффективными с точки зрения аппаратного обеспечения, чем реляционные базы данных, для предоставления агрегированной статистики, такой как продажи за день, за магазин, по категориям и т.д.

Интересно отметить, что большинство поставщиков ERP-систем, похоже, не осознавали полностью это ограничение дизайна в своих собственных продуктах, даже тех, что появились после 90-х, когда сегмент BI стал наглядным доказательством этого состояния дел. Например, большинство поставщиков ERP-систем осмеливались внедрять функции прогнозирования спроса, которые по своей природе полностью противоречат их базовой реляционной базе данных — даже больше, чем обычные функции отчётности. Прогнозирование требует доступа ко всей истории транзакционных данных компании: продаж, возвратов, уровней запасов, скидок и т.д. Хотя расчёт обычно выполняется пакетно в ночное время, что смягчает проблему нехватки ресурсов, описанную выше, реляционные базы данных создают значительные непредвиденные накладные расходы при попытке выполнить такого рода расчёт. В результате, в настоящее время большинство ERP-систем оснащены «наследственными» возможностями прогнозирования³, которые пришли в упадок много лет, а иногда и десятилетия назад.

Неблагоприятные для новых или отличительных парадигм

Стратегия каталогизации сущностей, используемая поставщиками ERP, не масштабируется линейно с точки зрения управления сложностью. Более совершенные инструменты, как обсуждалось выше, обеспечивают лишь линейное снижение нагрузки – относительно количества сущностей – в то время как затраты на сложность растут сверхлинейно. В результате новые или отличительные парадигмы обычно оказываются дорогостоящими как с точки зрения затрат, так и по срокам интеграции, часто доходя до того, что отказ от ERP оказывается лучшей альтернативой. Эти ситуации разнообразны, мы приведем несколько из них ниже, но все они сводятся к парадигмам, которые сложно интегрировать, поскольку они появились на поздних этапах развития ERP.⁴

Достижение нулевого времени простоя сложно, поскольку, как указано выше, любая масштабная операция чтения или записи подвергает ERP риску замедления системы. Поэтому все эти операции обычно выполняются пакетно по ночам, когда активность минимальна или отсутствует. Однако такой подход противоречит требованиям электронной коммерции, появившимся относительно поздно в истории ERP. В результате большинство поставщиков ERP существенно отделили свой модуль электронной коммерции, часто используя отдельную систему баз данных, нарушая неявное правило о том, что все модули ERP должны находиться в одной (или нескольких) базах данных. В итоге модули электронной коммерции, поддерживаемые ERP, оказываются такими же сложными и дорогостоящими для развертывания, как и сторонние приложения.

Работа с секторами ремануфактуринга, где товары следуют сложным циклическим потокам (например, ремонт), в то время как традиционные ERP ориентированы на прямые потоки – от производителей к потребителям, как это обычно наблюдается в секторах FMCG и дистрибуции. Хотя большинство необходимых для ремануфактуринга сущностей (например, продукты, запасы, заказы) уже присутствуют в ERP, их конструкции, как правило, совершенно не соответствуют требованиям ремануфактуринга. Часто оказывается проще полностью заново реализовать эти сущности, чем пытаться адаптировать их из традиционного ERP для таких отраслей.

Обеспечение гарантированно низких задержек, скажем, ниже порога восприятия человеком (то есть менее 50 мс), сложно, поскольку ни ERP, ни ее реляционная база данных не были спроектированы с учетом таких требований. Тем не менее, для управления высокоавтоматизированными системами, такими как роботизированные склады, требуются именно такие задержки, чтобы избежать того, чтобы программная оркестрация становилась узким местом системы. Таким образом, на практике большинство областей, связанных с обработкой «в режиме реального времени» (4), имеют выделенные системы вне ERP.

Интересно, что существуют специализированные ERP — хотя они не всегда называют себя ERP — которые выбрали альтернативные пути разработки, чтобы как следует справиться с этими ситуациями. Обычно такие ERP ориентированы на нишевые отрасли, которые традиционные ERP обслуживают недостаточно хорошо. Однако эти альтернативные пути разработки, как правило, противоречат требованиям массового рынка.

Риски при переходе ERP

Хотя это может показаться парадоксальным, обычно гораздо сложнее обновить ERP, чем просто развернуть ее впервые. Обновления печально известны тем, что могут занимать годы. Даже простое обновление версии ERP — при сохранении того же поставщика — обычно оказывается сложным и требует месяцев усилий. По устным данным, эта сложность регулярно попадает в новости, когда крупные компании публикуют пресс-релизы о том, что их проекты по обновлению ERP превысили бюджет на сотни миллионов долларов или евро. В таких ситуациях вину возлагают на поставщика ERP, интегратора и/или саму компанию. Однако, кажется, большинство не признают, что подобные проблемы присущи самим ERP, как результат воздействия вышеупомянутых рыночных сил.

Затраты на управление сложностью не масштабируются линейно, а сверхлинейно. Когда компания впервые внедряет ERP, у нее есть возможность постепенно интегрировать каждый модуль — по одному за раз. Таким образом, количество сущностей, интерфейсов и логик, задействованных на каждом этапе, относительно невелико, и специализированные расширения могут постепенно внедряться, чтобы ERP соответствовала потребностям компании.

Однако, когда компании приходится переходить на другую ERP, она сталкивается с проблемой одновременного переноса всех модулей. Действительно, ERP по своей природе и под влиянием экономических сил⁵ представляют собой монолитное программное обеспечение, построенное на основе небольшого набора баз данных. Таким образом, когда необходимо развернуть новую ERP, последовательный путь постепенного внедрения, использовавшийся для первоначальной ERP, воспроизвести нельзя. В результате компании приходится переходить по схеме «все или ничего». Это приводит к тому, что начальные затраты на внедрение оказываются очень высокими, а состояние системы после развертывания зачастую представляет собой частично неработающее решение, которое может потребовать несколько лет для исправления.

Технически, обновления всегда сложно реализовать, поскольку импорт сущностей, интерфейсов и логик из старой системы в новую не является операцией один к одному. Семантика сущностей со временем изменяется. Например, поставщик ERP мог начать с таблицы под названием «Orders», предназначенной для клиентских заказов. Однако впоследствии поставщику пришлось учитывать новые, изначально не запланированные, требования по управлению возвратами клиентов. Следующая версия ERP использует таблицу «Orders» для возврата клиентов, но при этом строки теперь содержат отрицательные количества заказов. Это, на первый взгляд безобидное изменение, в итоге значительно усложняет миграцию от старой версии ERP к новой.

Однако обновление к новой ERP или к более поздней версии той же ERP не является единственным вариантом для компаний. На самом деле, существует несколько альтернатив, позволяющих снизить риски при переходе. Естественно, вся экосистема поставщиков ERP и интеграторов ярко заинтересована в продвижении обратного варианта, поскольку это необходимо для выживания их экономической модели.

Вне монолита

ERP появились как программный монолит, то есть программные продукты, в которых все внутренние компоненты тесно взаимосвязаны — необходимость для обеспечения развертывания всех модулей по принципу plug-and-play. Кроме того, до 2010-х годов создание распределенных систем — то есть программного обеспечения, функционирующего на целой группе машин, а не на нескольких центральных — было значительно более сложным и дорогим⁶. Поэтому в значительной степени поставщики ERP (большинство из которых существуют уже десятилетиями) не имели иного выбора, кроме как строить свои продукты как монолит.

Тем не менее, по мере того как облачные вычисления стали массовым явлением, инструменты и библиотеки — часто с открытым исходным кодом — стали более популярными и доступными. В результате затраты и накладные расходы, связанные с разработкой распределенных приложений, неуклонно снижались за последнее десятилетие. Программная индустрия начала активно пересматривать, каким образом дополнительная ценность, которую исторически предоставляли только ERP (или программное обеспечение, подобное ERP), может быть реализована.

Современный подход к корпоративному программному обеспечению заключается в разбиении монолита на серию небольших приложений, которые, в идеале, выполняют одну задачу и делают это хорошо⁷. Связывание этих приложений осуществляется посредством API (интерфейсов программирования приложений), которые как раз предназначены для облегчения специализированных интеграций в разнообразные программные ландшафты. Большинство API разработаны с учетом использования популярных инструментов с открытым исходным кодом, что значительно снижает затраты на разработку, связанные с такими специализированными интеграциями.

Эти приложения иногда имеют более высокие первоначальные затраты на интеграцию по сравнению со встроенными модулями ERP. Однако они обеспечивают значительные долгосрочные преимущества, так как существенно снижают риски дальнейших изменений в программном ландшафте. Компания получает возможность обновлять или заменять отдельное приложение за раз, что оказывается не только гораздо проще, но и дешевле, а также сопряжено с меньшими рисками. Наконец, приложения SaaS (Программное обеспечение как услуга) обычно ориентированы на непрерывную поставку небольших поэтапных изменений. Хотя такая модель создает постоянную — но ограниченную — нагрузку для IT-команд, процесс внесения изменений в SaaS является более органичным, дешевым и менее рискованным по сравнению с ежегодными или двухгодичными обновлениями.

За пределами реляционных баз данных

Реляционные базы данных являются де-факто основой ERP с 80-х годов. Однако с 2010-х годов появились убедительные альтернативы. Наиболее заметной, вероятно, является Event Sourcing (ES) в сочетании с Command Query Responsibility Segregation (CQRS). Этот подход обеспечивает лучшую масштабируемость и задержки, а также позволяет создавать более выразительные конструкции, способные точнее отражать бизнес-цели в различных ситуациях.

Суть event sourcing заключается в трактовке каждого изменения в системе как неизменяемого события. Принцип неизменяемости вдохновлен бухгалтерской практикой: когда строка оказывается неверной в бухгалтерской книге, бухгалтер не стирает ее для исправления ошибки, а добавляет корректирующую строку. Хранение всей истории событий — при условии, что стоимость хранения данных достаточно низка для реализации этой стратегии — дает множество преимуществ: лучшую прослеживаемость, возможность аудита, безопасность… Кроме того, аспект неизменяемости упрощает масштабирование систем, основанных на событиях. Данные можно широко копировать и реплицировать, не беспокоясь об изменениях в них.

Дизайн CQRS признает, что в большинстве систем объемы операций чтения и записи существенно несбалансированы. Во многих случаях объем операций чтения данных превышает объем записи на несколько порядков. Однако реляционные базы данных рассчитаны на (отчасти) симметричные объемы чтения и записи. CQRS явно разделяет обязанности по чтению и записи, обычно на две отдельные подсистемы. Такой подход также дает преимущества, прежде всего, в плане задержек, масштабируемости и эффективности использования аппаратных средств.

Тем не менее, хотя и ES, и CQRS уже популярны в крупных потребительских технологических компаниях и в количественной торговле (финансы), они лишь недавно начали набирать популярность в массовом корпоративном программном обеспечении. В результате инструментарий ES+CQRS все еще находится на ранней стадии по сравнению с его аналогами в области реляционных баз данных. Однако этот подход предоставляет возможности не только для резкого сокращения затрат на оборудование, но и для снижения задержек, которые часто остаются острой проблемой для большинства внедрений ERP.

Точка зрения Lokad

Поскольку ERP даже не подходят для аналитических целей — отсюда и необходимость в инструментах BI (Business Intelligence) — неудивительно, что их результаты оставляют желать лучшего, когда речь заходит о прогнозной аналитике. В качестве анекдотического доказательства, ни одна из революций в области машинного обучения / data science не произошла в ERP, и при столкновении с подобного рода требованиями команды неизменно прибегают к электронным таблицам или ad hoc скриптам.

Сам Lokad возник как специализированное приложение, предназначенное дополнять ERP, а не заменять их, выступая в роли аналитического уровня, ориентированного на прогнозную оптимизацию цепочек поставок. Большинство наших ключевых функций, таких как возможности вероятностного прогнозирования, предназначенные для поддержки обыденных решений в таких областях, как запасы, закупки, производство, ассортимент, ценообразование, совершенно непрактично реализовать внутри ERP-систем.

Примечания