Дмитрий Потапов, партнер компании AT Consulting, директор блока ERP

С момента появления ERP-систем как отдельного класса программного обеспечения в 90-х годах прошлого века минуло более 20 лет, сменилось несколько поколений разработчиков и интеграторов ERP, появились Интернет и JavaScript, ориентированные на байт-код языки программирования, in-memory СУБД, интеграционные шины, облачные сервисы и много чего еще.

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

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

С другой стороны, не стоит ожидать, что новая ERP-функциональность и стандарты интеграции появятся "из народа", как это происходит со свободным ПО. ERP - слишком закрытый для этого сегмент, в отличие, скажем, от сообщества разработчиков СПО. Доступ к объекту автоматизации ERP - процессам предприятия - возможен только через участие в реальных проектах и профессиональное сообщество. Если Linux можно поставить дома и разбираться самостоятельно, то для того чтобы разобраться с ERP, нужно поступить на работу к производителю ПО, системному интегратору или в ИТ-подразделение компании, внедряющей у себя ERP.

Таким образом, если перед компанией стоит вопрос построения ERP-системы, то на сегодняшний день он сводится к решению, на кого из ведущих поставщиков ERP сделать ставку. Подход best-of-breed при построении на предприятии ERP-ландшафта не работает. Или, точнее, работает в ограниченном масштабе: нишевые решения от других поставщиков ПО лишь дополняют монолит ERP от основного поставщика. 

Здесь стоит сделать одну оговорку. Помимо формулы "ERP от одного поставщика + нишевые решения" я также верю в формулу "два ERP". Например, финансы и HR могут быть от одного поставщика, а иная большая область, например производство или ритейл, - от другого поставщика. Но для выбора формулы "два ERP" должны быть веские причины - например, большие вложения в существующую функциональность.

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

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

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

В третьем круге находятся партнерские решения. Их команды разработки, как правило, не имеют постоянного контакта с разработчиками ядра, интеграция происходит на основании опубликованной документации по API.

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

Основой ERP следует выбирать функциональность "первого круга" или ядра одного из ведущих поставщиков. Собирать best-of-breed-решение для функциональности ядра не имеет никакого смысла. Например, из ядра тяжело вырвать склад или основные средства - слишком много сквозных процессов и точек интеграции со смежными областями (финансами, снабжением, капитальным строительством). Вся эта интеграция хорошо продумана и протестирована основной командой разработчика ПО.

Если заказчику нужна функциональность из второго или третьего круга, то есть модули, не входящие в ядро и имеющие не очень большое количество точек интеграции, то здесь, с оглядкой, можно применить подход best-of-breed. В первую очередь стоит посмотреть на предложение купленных партнерских решений того же поставщика, проанализировать степень их интеграции с ядром, узнать планы их развития на ближайшие годы, наличие консультантов с опытом в этих продуктах. Если планы сомнительные, а консультанты штучные, то можно посмотреть на решения других поставщиков. При этом нужно учитывать тот факт, что организовать техническую поддержку гораздо проще, если имеешь дело с одним поставщиком.

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

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

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

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

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