00:00:07 Важность ERP-систем.
00:02:42 ERP: объяснение некорректного наименования.
00:03:54 Начальная реализация ERP-системы.
00:05:07 Основные возможности ранних ERP-систем.
00:07:34 ERP-системы: сущности, интерфейсы, логика.
00:09:14 Роль ERP в автоматизации бизнеса.
00:09:54 Эволюция ERP-систем и стратегии.
00:11:32 Доменно-специфичные языки в ERP.
00:12:07 Модульная структура ERP-систем.
00:14:22 Роль интеграторов в ERP.
00:16:00 Интеграторы, продвигающие индивидуальные ERP-решения.
00:17:01 Актуальность традиционных ограничений ERP.
00:19:01 Проблематичность необходимости единой ERP-системы.
00:20:01 Трудности обновлений ERP.
00:21:35 Роль оператора ERP и сопутствующие сложности.
00:22:53 Риски/выгоды специализированных поставщиков ERP.
00:25:00 ERP-системы: сложность и вызовы.
00:26:52 Малые компании и приложения по модели SaaS.
00:28:42 Сложные ERP-продукты для компаний среднего размера.
00:30:16 Крупные компании избегают монолитных ERP.
00:31:46 Стратегии ведущих компаний.
00:33:39 Заключительные мысли.
Резюме
В интервью с Кираном Чандлером основатель Lokad, Жоанн Верморель, обсуждает эволюцию систем планирования ресурсов предприятия (ERP). Отслеживая их зарождение в 1970‑х, Верморель выделяет две ключевые инновации — появление реляционных баз данных и сканеров штрихкодов — как определяющие развитие ERP. Он утверждает, что термин «Управление ресурсами предприятия» является более точным для этих систем, которые эволюционировали от индивидуальных решений компаний до готовых представлений бизнес-моделей. Современные функции ERP, такие как интерфейсы CRUD и логика рабочих процессов, автоматизировали рутинные задачи, повышая производительность. Верморель исследует стратегии успешных ERP‑поставщиков, таких как SAP, для управления сложностью системы, а также обсуждает выбор и внедрение ERP для компаний разного масштаба.
Расширенное резюме
В интервью ведущий Киран Чандлер беседует с основателем Lokad, Жоанном Верморелем, чтобы обсудить эволюцию и функциональность систем планирования ресурсов предприятия (ERP).
Верморель излагает истоки ERP‑систем, указывая на их появление в 1970‑х, несмотря на то, что термин «ERP» был введён только в 90‑х. По его словам, две ключевые инновации привели к развитию ERP‑систем. Первая — это развитие вычислительного оборудования до такого уровня, что реляционные базы данных стали возможны. Эти базы данных, хотя и примитивные на первых этапах, предлагали универсальный способ организации данных. Реляционный формат, состоящий из таблиц и столбцов, отлично подходил для моделирования различных бизнес‑операций, включая транзакции, платежи, а также взаимодействие с клиентами и поставщиками.
Вторая важная инновация, которую упоминает Верморель, — изобретение сканеров штрихкодов. Хотя сканеры штрихкодов появились в 1950‑х, только благодаря развитию вычислительной техники в 1970‑х они смогли хранить и обрабатывать значительные объёмы данных. Сочетание этих двух технологий привело к появлению ERP‑систем, известных нам сегодня.
Верморель также затрагивает тему некорректного наименования ERP, утверждая, что это был маркетинговый ход, начатый в 90‑х. Он объясняет, что ERP‑системы практически не связаны с планированием, а ориентированы на управление, что делает термин «Управление ресурсами предприятия» более точным. Он иллюстрирует это описанием того, как на ранних этапах многие компании начали разрабатывать собственные программные системы для управления ресурсами с использованием доступных в то время баз данных и средств ввода данных.
Наблюдая общие потребности бизнеса в представлении таких элементов, как платежи, запасы и сотрудники, некоторые компании начали предлагать готовые версии этих бизнес‑моделей. Верморель указывает, что именно так возникли системы, которые мы сегодня называем ERP, хотя он предлагает рассматривать их как системы управления ресурсами предприятия с учётом их реальной функциональности.
Пользовательские интерфейсы, обычно классифицируемые как интерфейсы CRUD (создание, чтение, обновление, удаление), работают с этими сущностями. Они позволяют выполнять базовые операции ввода данных, такие как добавление нового продукта (создание), просмотр атрибутов существующего продукта (чтение), изменение продукта (обновление) и его удаление (удаление). Этот паттерн CRUD применяется ко всем сущностям в ERP‑системе.
Логика рабочих процессов, третий компонент, где вступает в силу автоматизация. Верморель приводит пример процесса закупок: сначала оформляется заказ на покупку, затем поставщик подтверждает его счетом, после чего поставщик отгружает товары. ERP‑система отслеживает эти шаги, и если товары не получены, пользователь получает уведомление. Если полученные количества не соответствуют заказанным, система предлагает дальнейшие действия, например, связаться с поставщиком для отправки остатка или вернуть товары. Такая автоматизация рутинных задач приводит к значительному повышению производительности.
Переходя к эволюции ERP, Верморель подчёркивает роль поставщиков в формировании этих систем. Он отмечает, что главная задача для них — управление сложностью, поскольку им приходится реализовывать бесконечное множество сущностей, пользовательских интерфейсов и логики. Он упоминает «тройную» стратегию, которую успешные ERP‑поставщики используют для управления этой сложностью и поддержания конкурентоспособности.
Во‑первых, поставщики внедряют определённые технологии для оптимизации создания сущностей, пользовательских интерфейсов и логики. Верморель приводит в пример SAP — успешного поставщика ERP, который разработал свой собственный доменно-специфичный язык программирования ABAP для ускорения внедрения.
Во‑вторых, поставщики корректируют структуру своих предложений и ценовую политику, чтобы отразить затраты и усилия на создание и поддержку разнообразных сущностей. Это часто приводит к модульной ценовой структуре, где сущности группируются в логически взаимосвязанные модули, и клиенты оплачивают только те модули, которые используют.
ERP‑системы, ставшие доминирующей частью мира корпоративного программного обеспечения, постоянно развиваются и адаптируются для удовлетворения потребностей бизнеса и его сложных операций.
Верморель начинает с обсуждения стимулов и бизнес‑модели ERP‑поставщиков. Он объясняет, что у этих поставщиков есть стимул постоянно разрабатывать новые модули или функции для продажи своим клиентам. Поставщики часто рассматривают каждую успешную реализацию как возможность создать и продать дополнительный модуль, что создаёт постоянный цикл продаж и разработки.
Далее разговор переходит к выбору между различными подходами к ERP. Верморель предлагает бизнесу задаться вопросом, актуальны ли ограничения, заложенные в ERP с конца 70‑х, для их сегодняшней ситуации. Он ставит под сомнение необходимость единой, интегрированной системы, утверждая, что такой подход может привести к увеличению сложности и множеству крайних случаев. Вместо этого он предлагает пересмотреть предположение о том, что одна система должна делать всё, и предостерегает от наличия слишком большого количества разрозненных систем.
Обсуждая внедрение новых ERP‑систем, Верморель затрагивает значительные риски и затраты, связанные с переходом на новую систему или обновлением существующей. Он приводит в пример компанию, которая потратила полмиллиарда евро на обновление SAP в 2009 году, подчеркивая, что семантика сущностей в ERP‑системе — во многом определяемая её операторами — часто изменяется тонко, но существенно между версиями, что приводит к множеству крайних случаев и проблем.
Верморель считает, что у небольших поставщиков существуют определённые риски, но лучше выбирать продукт с узким ядром, отражающим текущую сложность и масштаб компании. Он советует избегать чрезмерного количества функций, которые могут нарушить существующие процессы, и рекомендует выбирать продукт, который при необходимости можно дополнить интеграцией.
В обсуждении также затрагивается вопрос выбора подходящей ERP для компаний разного размера. Верморель предлагает, чтобы малые компании с числом сотрудников менее 100 отдавали предпочтение узким, простым и экономичным приложениям по модели Software‑as‑a‑Service (SaaS). Он рекомендует использовать два или три отдельных приложения для удовлетворения конкретных потребностей вместо того, чтобы полагаться на универсальную ERP. Для средних компаний с примерно 500 сотрудниками Верморель советует рассмотреть более сложный ERP‑продукт среднего звена, способный охватить более широкий спектр типовых бизнес‑функций. Однако для крупных компаний с тысячами сотрудников он предостерегает от монолитного подхода к ERP и предлагает стратегию «разделяй и властвуй»: разбить систему на функциональные области и создавать или закупать решения, адаптированные к каждой области, вместо попыток внедрить единую ERP‑систему.
Полная расшифровка
Kieran Chandler: Сегодня мы узнаем, как возник этот класс корпоративного программного обеспечения и как компании могут выбирать из множества различных вариантов. Итак, Жоанн, может быть, начнём с рассмотрения истоков ERP‑систем. Как они появились в первый раз?
Joannes Vermorel: ERP‑системы возникли благодаря двум движущим силам в 70‑х годах. Кстати, термин ERP появился в 90‑х, но то, что мы обычно называем ERP‑системами, началось в 70‑х. Существовало две критические инновации. Первая — системы баз данных. Вычислительная техника развилась до такого уровня, что реляционная база данных стала возможна. Это была первая инновация. Вторая — сканеры штрихкодов. Когда объединяешь эти две инновации, понимаешь, что реляционные базы данных были невероятно универсальны и отлично подходили для моделирования большинства бизнес‑операций, таких как платежи, клиенты, поставщики и транзакции. Стало ясно, что этот формат прекрасно подходит для приёма данных. Штрихкоды были изобретены в 50‑х, но до того, как вычислительная техника достаточно продвинулась в 70‑х, чтобы хранить и обрабатывать значительные объёмы данных, они не имели такого эффекта по сравнению с ручной обработкой.
Kieran Chandler: Хорошо, вы только что коснулись этого. Название ERP появилось немного позже, в 90‑х. ERP означает планирование ресурсов предприятия. Но откуда же взялось это название? Почему именно так решили назваться?
Joannes Vermorel: На самом деле, ERP — это некорректное название. К сожалению, оно больше похоже на маркетинговый ход, появившийся в 90‑х. ERP‑системы практически не связаны с планированием; они ориентированы на управление, поэтому лучше было бы назвать их управлением ресурсами предприятия. Суть в том, что как только появились базы данных и сканеры штрихкодов, многие компании осознали необходимость компьютеризированной системы для управления ресурсами. Они начали разворачивать собственные программные решения на основе баз данных и доступных в то время устройств ввода данных. Другие компании поняли, что у многих бизнесов есть схожие потребности в представлении таких данных, как платежи, запасы для работы с материальными ресурсами и расчёт заработной платы сотрудников. Поэтому некоторые софтверные компании решили: «Давайте сделаем готовые версии этих бизнес‑моделей», и так родилась концепция ERP. В наши дни лучше воспринимать это как ERP не в смысле планирования ресурсов предприятия, а как управления ресурсами предприятия.
Kieran Chandler: Итак, каковы были основные возможности ранних ERP‑систем?
Joannes Vermorel: По сути, ERP состоит из трёх компонентов: сущностей, пользовательских интерфейсов и логики рабочих процессов. Сущности — это абстракции поверх таблиц. Например, если вы хотите представить продукты, у вас будет таблица с названием “products”, однако может существовать несколько таблиц для различных атрибутов или поставщиков. Сущности представляют концепции высокого уровня, такие как продукты, клиенты или транзакции, а не детали реализации их хранения в базе данных.
Пользовательские интерфейсы специально предназначены для операций CRUD: создание, чтение, обновление и удаление. Чаще всего, работая с сущностями, вы используете именно CRUD‑интерфейсы. Вы вводите новые продукты, проверяете детали существующих, изменяете их или удаляете. Это относится ко всем сущностям, таким как транзакции, клиенты и т.д.
Третий элемент — логика рабочих процессов. Возьмём, например, закупку. Сначала вы оформляете заказ, затем поставщик подтверждает его счетом, после чего отгружает товары. ERP‑система отслеживает эти шаги, и если товары не получены, система предупреждает пользователя. Если полученные количества не соответствуют заказанным, система предлагает дальнейшие действия, например, вернуть товары поставщику или запросить недостающие позиции. ERP автоматизирует эти рутинные задачи и повышает производительность, управляя последствиями основных бизнес‑операций.
Kieran Chandler: В мире программного обеспечения, насколько они изменились с тех самых ранних версий? Очень интересно, что чтобы понять эти изменения, нужно осознать динамику, движущую рынок ERP. Особенно ERP‑поставщики играют значительную роль во внедрении этих систем, а не компании, внедряющие их самостоятельно. Давайте разберём это. Большинство поставщиков применяют трёхступенчатую стратегию, которую я называю Аллах. Эта стратегия оказалась успешной для завоевания рынка. В наши дни большинство успешных ERP‑поставщиков используют эти три подхода.
Joannes Vermorel: Основная проблема, с которой сталкиваются поставщики ERP, — это сложность. Чтобы справиться с этой проблемой, им необходимо внедрять бесконечные потоки сущностей и предоставлять пользовательские интерфейсы и рабочие процессы, которые имеют смысл. Первый способ стать более конкурентоспособным — это иметь специальные технологии, которые оптимизируют создание сущностей, пользовательских интерфейсов и логики. Примером такой технологии является специальный язык программирования для конкретной предметной области. Например, успешный поставщик ERP, CP, изобрёл свой собственный специализированный язык программирования под названием ab app, который помог им быстрее внедрять сущности, пользовательские интерфейсы и логику, чем их конкуренты.
Kieran Chandler: Интересно. Значит, второй путь — это корректировка структуры предложения и ценообразования. Можешь подробнее рассказать об этом?
Joannes Vermorel: Конечно. Для поставщика стоимость создания ERP сильно зависит от того, сколько усилий требуется для реализации всех различных элементов. Хотя отдельные части могут быть довольно простыми, суть ERP заключается в решении рутинных задач, таких как обработка квитанций. Поскольку поставщикам приходится создавать и поддерживать множество сущностей, имеет смысл начинать взимать плату не за каждую сущность, а за модули. Модули группируют взаимосвязанные сущности и соответствуют бизнес-потребностям. Это поднимает интересный вопрос о том, как ERP-системы устанавливают стоимость своего программного обеспечения.
Kieran Chandler: Абсолютно. Таким образом, за добавление модулей взимается дополнительная плата. Мы уже обсуждали проблему зависимости от поставщика. Совпадают ли экономические интересы поставщиков ERP с таким модульным ценообразованием?
Joannes Vermorel: Действительно, как только вы внедряете модули, это становится эффективным способом соотнести цену с затратами на реализацию всех функций. Однако это также создаёт специфические стимулы. Поставщики мотивированы продолжать разработку новых модулей, чтобы продавать их поверх уже существующих. Это может привести к бесконечному циклу продажи дополнительных модулей клиентам. Но прежде чем углубляться в детали, давайте перейдём к третьей идее.
Kieran Chandler: Хорошо. В чём заключается третья идея?
Joannes Vermorel: Третья идея заключается в том, что успешные поставщики ERP, ввиду огромной сложности захвата всех мельчайших деталей реальности, находят способы ещё быстрее расти за счёт интеграторов. Поскольку одна компания не может справиться со всем, поставщики ERP сотрудничают с внешними компаниями, известными как интеграторы, чтобы взять на себя завершающий этап, обеспечивая полное и всестороннее решение.
Kieran Chandler: Итак, Жоан, ты упоминал ранее, что Lokad внедряет новую функцию для своих клиентов. Можешь рассказать об этом подробнее?
Joannes Vermorel: Да, действительно. Мы запускаем новую функцию для наших клиентов. Она включает новые сущности, новый пользовательский интерфейс и новую логику. Мы создаём сеть партнёров, называемых интеграторами, для реализации этой функции. С точки зрения бизнес-модели это интересно для компаний, поставляющих ERP, потому что они могут переложить расходы и риски, связанные с этой функцией, на третьих лиц. Существует длинный список функций, которые можно отдать на аутсорсинг сторонним компаниям.
Kieran Chandler: Таким образом, поставщики программного обеспечения переносят риск на интеграторов, а в конечном итоге — на своих клиентов. У интеграторов есть свои стимулы, которые могут не полностью совпадать со стимулами поставщика ПО. Верно?
Joannes Vermorel: Именно. Интеграторы получают стимул предоставлять клиентам высокий уровень кастомизации, поскольку им платят больше за индивидуальные модули, а не за встроенные. Они могут убедить клиентов, что их бизнес уникален и требует решения, отражающего эту уникальность. Это интересная динамика.
Kieran Chandler: Понятно. Значит, существуют разные подходы к ERP-системам. Как определить, какой подход хороший, а какой плохой?
Joannes Vermorel: В наши дни, рассматривая выбор ERP, нужно задаться вопросом, актуальны ли все ограничения, заложенные в ERP в конце 70-х годов, для вашей ситуации. Это зависит от нескольких факторов. Например, идея о том, что всё должно быть интегрировано в одну систему, часто нелогична, так как сложность не растёт линейно. Добавление новых сущностей в систему приводит к большему количеству пограничных случаев и вариаций того, что разные отрасли считают «продуктом».
Kieran Chandler: То есть, вы говорите, что нам нужно пересмотреть предположение о том, что нужна одна система для всего?
Joannes Vermorel: Именно. Это предположение уже неактуально. Наличие 100 отдельных систем, требующих координации, — это сложно, но и одна универсальная система, охватывающая всё, тоже проблематична. Когда вы хотите внести изменения в такую систему, это превращается в масштабный проект, затрагивающий каждую функцию компании.
Kieran Chandler: Понятно. Похоже, переход на новую систему может быть довольно сложным. Некоторые компании испытывали дорогостоящие неудачи, пытаясь перейти на новые ERP-системы. Насколько практичен этот переход?
Joannes Vermorel: Действительно, переход на новую ERP-систему может быть сложным. Мы наблюдали, как компании тратили миллиарды долларов, пытаясь осуществить такие переходы. На практике это не простая задача.
Kieran Chandler: В 2009 году они потратили полмиллиарда евро на обновление ASAP. Это даже не было развертыванием, а просто обновлением. Так что вопрос в том, сложнее ли обновить ERP, чем перейти на новую систему?
Joannes Vermorel: Это очень интересный вопрос. На удивление, обновление ERP обычно оказывается сложнее, чем переход на новую систему. Может показаться противоречащим логике, но именно так я и наблюдал. При миграции на новую ERP у вас нет иллюзии, что это будет масштабное мероприятие. Однако, когда рассматриваете это как просто обновление, может показаться, что всё просто, но на самом деле это может быть очень, очень сложно.
Проблема в том, что при переходе с одной версии на другую происходит семантический сдвиг в определении сущностей. Видите ли, ERP-системы предназначены для представления сущностей, отражающих различные аспекты вашего бизнеса, такие как продукты. Можно подумать, что семантика этих сущностей определяется поставщиком, но это не совсем так. Конечная семантика любой сущности определяется оператором — человеком, который взаимодействует с системой и выполняет ввод данных и рабочие процессы.
Таким образом, истинная семантика сущности определяется человеком, работающим с ERP. К сожалению для поставщиков ERP, у них мало контроля над тем, что люди на самом деле делают с продуктом. Они могут давать рекомендации и проводить обучающие программы, но в конечном итоге это остаётся сложной задачей. Некоторые компании могут решить внедрить немного отличную семантику, чтобы ERP работала в их конкретной ситуации. Это не потому, что они бунтари; это то, что необходимо для работы системы.
Однако проблема возникает, когда вы переходите на следующую версию. Вы можете столкнуться с многочисленными тонкими пограничными случаями, когда сущность внезапно начинает означать не то же самое из-за новых разработок и множества исключений.
Kieran Chandler: Это интересно. С одной стороны, есть крупные монолитные подходы, а с другой — более мелкие, специализированные ERP-компании. Насколько можно доверять этим мелким компаниям, которые, возможно, не выживут в следующем десятилетии?
Joannes Vermorel: Если вы маленькая компания, вам нужна система, где сложность соответствует масштабу вашего бизнеса. Продукты ERP со временем, как правило, становятся всё сложнее. Поэтому, если вы молодая компания, возможно, всего пяти лет, и быстро растёте, неправильно использовать ERP, которому уже три-четыре десятилетия. Эти старые продукты могут быть невероятно сложными — с сотнями, а то и тысячами таблиц и сущностей. Работа с такой сложностью может оказаться подавляющей.
Так что мой совет — рассмотреть варианты с молодыми ERP-компаниями, даже если они сопряжены с определённым риском. Будьте осторожны, чтобы не утонуть в море сложности. По моему опыту управления Lokad более десяти лет, я не встречал компаний, которые оказались в критической ситуации исключительно из-за выбора ERP. Однако внедрение продукта, который намного сложнее, чем соответствует вашему масштабу, может оказаться вредным и даже погубить бизнес. Я часто наблюдал, как компании сталкиваются с проблемами, потому что принимали программное обеспечение, которое оказалось просто слишком сложным по уровню сложности и функционала.
Kieran Chandler: Кажется, что при выборе программного обеспечения для растущей компании критически важно иметь прочное ядро и взаимосвязанные приложения. Жоан, не мог бы ты подробнее рассказать об этой идее?
Joannes Vermorel: Абсолютно. Парадоксально, но лучше иметь систему с узким ядром, которое отражает текущую сложность и масштаб вашего бизнеса, даже если в ней ещё не хватает некоторых функций. Вы всегда можете дополнить недостающие элементы посредством интеграции. С другой стороны, наличие слишком большого количества конфликтующих функций может привести к проблемам. Невостребованные функции часто нарушают рабочие процессы и мешают выполнению простых задач. Полностью интегрированные программные продукты затрудняют удаление или изменение определённых функций без нарушения работы всей системы.
Kieran Chandler: То есть, выбор более компактного продукта не устраняет эти проблемы полностью?
Joannes Vermorel: Нет, масштаб и важность этих проблем зависят от сложности и количества сущностей в программном обеспечении. Однако размер компании также играет роль. Для небольших компаний с числом сотрудников менее 100 рекомендуется искать узкоспециализированное, простое и экономичное решение, например, SaaS-приложение. Возможно, вам понадобится два или три таких приложения для охвата разных областей, таких как управление персоналом, расчёт зарплаты и управление запасами. Нет необходимости иметь один ERP, охватывающий всё. Главное — чтобы у этих приложений были API для извлечения данных, чтобы при необходимости можно было их интегрировать.
Kieran Chandler: Это имеет смысл. А как насчёт компаний среднего размера?
Joannes Vermorel: Для компаний среднего размера, с примерно 500 сотрудниками, можно рассмотреть более комплексный ERP-продукт. Он будет более сложным, с множеством таблиц и функций. На этом этапе у вас возникает множество типичных бизнес-задач, и ERP может справиться с их решением. Возможно, потребуется более длительный проект внедрения и хороший интегратор, но продукт сможет обеспечить необходимую функциональность.
Kieran Chandler: Это гораздо эффективнее по сравнению с небольшими приложениями, которые уже начинают достигать своих пределов. А если вы крупнее, то ситуация меняется снова. Если вы — крупная компания, скажем, с 5000 сотрудниками, то, как правило, действуют два основных принципа. Во-первых, вам нужно разделить систему на части. Знаете, монолит просто не сработает для вас, если вы крупная компания. Если выбрать монолитный ERP, как это делают большинство крупных компаний, то это будет нечто некрасивое, займёт годы и обойдётся невероятно дорого.
Joannes Vermorel: Если посмотреть на то, что делают действительно лучшие крупные компании, то они, как правило, внедряют достаточно индивидуальные решения. И у них есть веские причины для этого. Если вы крупная компания, скорее всего, у вас есть уникальное конкурентное преимущество, которое не является чем-то простым. Оно заложено в вашей организации, которая велика, сложна и, возможно, включает поглощённые компании. Так что вместо того, чтобы говорить: «Я хочу один ERP для всего», что работало при 500 сотрудниках, становится крайне сложно, когда их, скажем, 5000. Поэтому мой совет — разделяй и властвуй. Тот подход, который я рекомендовал, когда вы были маленькими и у вас было несколько приложений, можно пересмотреть совершенно иначе для крупной компании.
Таким образом, я планирую разделить ландшафт на, скажем, до дюжины функциональных областей. А затем для каждой области либо построить, либо купить решение, в зависимости от того, насколько хороши предложения поставщиков. И главный вызов, который я рекомендую учитывать крупным компаниям, — это избавиться от догмы о том, что нужен один ERP для всего. Я считаю, что в большинстве случаев это — чепуха. Если посмотреть на действительно сверхконкурентных игроков, скажем, Amazon, Alibaba, Rakuten, Zalando — тех технологических гигантов, которым приходится управлять физической цепочкой поставок, — то все они выбрали стратегию «разделяй и властвуй» в своём приложенческом ландшафте, активно используя модель «строить или покупать». По сути, ни у одной из этих компаний нет настоящего ERP. У них есть списки продуктов. Некоторые из них ближе к ERP, а большинство компаний даже разрабатывают собственные системы для конкретных частей того, что обычно называют модулем ERP.
Kieran Chandler: Ну, нам придётся на этом закончить, но большое спасибо за ваше время сегодня утром.
Joannes Vermorel: Спасибо, Киран.
Kieran Chandler: Это всё на эту неделю. Пока.
