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

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

Происхождение и мотивация

В 70-х годах стало очевидно, что электронные записи имеют множество преимуществ по сравнению с традиционными бумажными документами. Электронные записи становились дешевле, быстрее и надежнее, чем бумажные записи. Две изобретения, предшествовавшие появлению ERP-систем, сыграли ключевую роль в развитии электронных записей: считыватели штрих-кодов (1950-е годы) и реляционные базы данных (1970-е годы). Считыватели штрих-кодов предложили более эффективный способ управления потоками товаров, увеличивая производительность и снижая количество ошибок. Однако, хотя считыватели штрих-кодов значительно улучшили сбор данных во многих ситуациях, хранение, организация и обработка электронных записей оставались открытой проблемой на протяжении двух десятилетий. Реляционные базы данных стали ответом программной индустрии на эту проблему в конце 70-х годов, и спустя пять десятилетий они остаются доминирующей практикой в области управления бизнес-данными.

Однако голые системы реляционных баз данных, как правило, продавались по высокой цене в начале 80-х годов, так как каждая компания самостоятельно разрабатывала способы представления всего в своей базе данных: продукты, клиенты, счета, платежи и т. д. Таким образом, в 80-х годах появился ряд компаний, продававших “преднастроенные” реляционные системы. Эти продукты позже были объединены под общим названием ERP-системы, термин, придуманный в 90-х годах. К сожалению, акроним ERP является неправильным, и вместо “планирования” он должен был означать “управление ресурсами предприятия”. Действительно, планирование - в лучшем случае - является второстепенной задачей для ERP-систем. Как подробно описано далее, прогнозирование аналитики существенно противоречит основному дизайну ERP-систем.

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

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

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

Проектирование ERP-систем

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

• сущностей, то есть всех понятий или объектов, которые ERP-система должна представлять, таких как продукты, платежи, запасы, поставщики… Каждая сущность может включать одну или несколько таблиц в базе данных. Большинство ERP-систем определяют сотни сущностей, а самые сложные ERP-системы - тысячи.
• пользовательских интерфейсов, которые позволяют конечным пользователям просматривать и редактировать данные сущностей. Эти интерфейсы в основном основаны на дизайне CRUD (Create / Read / Update / Delete), который представляет собой наиболее базовые операции, которые ожидают конечные пользователи при работе с сущностями.
• бизнес-логики, которая предоставляет автоматизированное поведение, устраняющее необходимость во многих административных задачах, которые можно автоматизировать на основе четко определенных правил, например, преобразование заказов клиентов в счета клиентов.

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

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

Технология

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

В частности, многие поставщики ERP-систем разработали языки DSL (специфические для области программирования), которые предназначены для дополнения базового языка запросов - обычно варианта 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.

Противоречие грубым чтениям или записям

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

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

Например, ERP-системы хорошо подходят для отображения уровня запасов SKU или для обновления его значения при выборе или загрузке единицы, но ERP-системы обычно не подходят для отображения объединенного ежедневного графика изменений запасов SKU за последние три года. Весь сегмент программного обеспечения Бизнес-аналитика (BI) появился в 90-х годах как отраслевой ответ на аналитические ограничения ERP-систем (и CRMs). В отличие от 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 мог начать с таблицы с названием “Заказы”, предназначенной для клиентских заказов. Однако, по мере развития, поставщику пришлось удовлетворить новые требования, которые изначально не планировались, по управлению возвратами клиентов. Следующая версия ERP повторно использует таблицу “Заказы” для возвратов клиентов, однако эти строки теперь имеют отрицательное количество заказов. Это кажущееся незначительное изменение в конечном итоге значительно усложняет миграцию с предыдущей версии ERP на новую.

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

За пределами монолита

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

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

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

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

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

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

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

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

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

Взгляд Lokad

Поскольку ERPs не подходят даже для аналитических целей - отсюда и необходимость инструментов BI (Business Intelligence) - неудивительно, что их рекорд весьма печален, когда речь идет о предиктивной аналитике. Как анекдотическое доказательство, ни одна из революций в области машинного обучения / науки о данных не произошла в ERPs, и сталкиваясь с такими требованиями, команды неизменно прибегают к таблицам Excel или к специальным скриптам.

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

Примечания