Проблемы классических ERP и перспективы альтернативной модульной архитектуры

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

В этом посте я возьму на себя смелость и брошу вызов общепринятым представлениям. Подвергну критике всё, что сегодня с большим или меньшим успехом применяется в России, опишу концептуальную альтернативу классическим ERP. Забегая вперёд скажу, что в качестве альтернативы мы видим необходимость создавать платформу для установки отдельных модулей для разных уровней и задач, которая, при этом будет брать на себя функциональную нагрузку одновременно MES, ERP и DSS (Decision Support System) систем. Подробнее под катом. 

Проблемы классических ERP-систем 

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

• избыточная функциональность в единой разделяемой системе;

• ригидность подходов к процессам;

• ограничение возможностей планирования и моделирования;

• необходимость дополнительных средств для организации систем принятия решений;

• направленность на решение системных задач предприятия и соблюдение процессных регламентов без возможности их гибкой адаптации под пользователя;

• проблема план-фактной отчетности и анализа;

• высокая стоимость владения, не связанная с объемом использующихся функций и привязанная исключительно к количеству пользователей.

Далее имеет смысл описать общие проблемы популярных ERP-систем. Если речь о России, то наиболее распространены следующие продукты такого рода:

• 1С:ERP Управление предприятием

• SAP S/4HANA

• Microsoft Dynamics AX (Axapta)

• Oracle ERP

• Парус

Наиболее показательной, как и одной и самых популярных сегодня является SAP S/4HANA. Это наиболее развитая и зрелая система, которая прошла колоссальный путь, став эталоном, на который равняются. Мы не умаляем заслуг разработчиков 1С-предприятия, Oracle ERP и других, но SAP S/4HANA, по нашему мнению, превосходит каждую из них как архитектурно, так и функционально. А кроме того, как и другие, лучше всего отражает недостатки существующей концепции и выбранной архитектуры. В этом отношении все перечисленные системы создавались по её образу и подобию.

Могу привести метафорическую аналогию, если SAP S/4HANA - это специалист, закончивший университет, то, например, 1C-предприятие, одарённый ребёнок, который собирается покинуть детский сад и пойти в школу.

Желания руководителей

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

На практике, качественное внедрение SAP S/4HANA, 1С-предприятие или других ERP-систем действительно отчасти облегчает работу компании в целом. Но это не касается исполнителей задач и руководства компании по отдельности. Классические ERP-системы накладывают жесткие регламентные ограничения на работу специалистов, тогда как реальная работа предприятия не может постоянно находиться в узких рамках регламентов, какими бы качественными они ни были и сколько бы ситуаций не описывали. Руководство предприятий также попадает в ловушку регламентов процессного подхода и, работая с ERP, часто вынуждено действовать неоптимально, испытывает сложности с точностью и актуальностью получаемых данных. 

Проблемы планирования

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

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

Ограниченность отчетности

Само предоставление отчетности в классических ERP нередко представляет собой проблему. Несмотря на заверения вендоров о стандартизированном “полном” наборе “всех необходимых” отчетов, во всех системах, с которыми мы работали, приходится отчетность допиливать и перенастраивать.

Например, мы для себя SAP S/4HANA внедряли трижды, и только с третьего раза руководство получило ту систему, которую хотели. В ней было ноль Z-разработки, всё настроено стандартными средствами, но даже там отчетность приходилось допиливать. Важно, что в нашем случае речь шла о предприятии, оказывающем услуги по разработке и внедрению.

Совершенно другая ситуация с производственными компаниями, где для получения необходимых показателей нужно учитывать тысячи различных значений и типов данных. И формирование отчетности для уровня принятия решений в таких компаниях несопоставимо более сложная задача. Внедрение на таких предприятиях обычно приводит к тому, что установленную систему порой сложно назвать SAP S/4HANA или 1C, настолько глубоко там проводится кастомизация решений. 

Необходимость в дополнительной BI-системе

Даже в таких глубоко измененных продуктах руководители не могут получить ту отчетность, которая им необходима. Приходится отдельно внедрять и настраивать BI-системы. Что увеличивает стоимость как самого внедрения, так использования (лицензии) и поддержки.  

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

Большинство распространенных и не слишком дорогих решений в этой области - витрины, для которых нужно создавать шины данных, привязывать источники, интегрировать со сторонними API. Любое решение всегда будет использовать эти компоненты, наше не исключение. Но существующие разнообразные решения, что называется “идут кто в лес, кто по дрова”, так как нет единой унифицированной платформы. 

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

 Всё зависит от конкретных специалистов: какой набор ПО они лучше знают и какие методики организации хранилищ они предпочитают. 

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

Во многом по причине функциональной недостаточности существовавших в тот момент ERP-систем SAP S/4HANA создавал свою SAP S/4HANA 4 HANA. Большой объём данных требовал вычислений, проводимых в ОЗУ, была применена In-Memory СУБД SAP HANA, чтобы уменьшить временные затраты. 

Почему мы считаем, что ERP должны стать принципиально другими?

Анализируя изложенные выше проблемы, мы поняли, что в полной мере ни одна ERP-система не решает проблем наверху. Полноценные экосистемы верхнего уровня, в которых строятся отчеты, которые облегчают планирование и принятие решений (то, что 20 лет назад называли “leadtop”или “рабочий стол руководителя”, а сегодня именуется DSS и BI), не являются частью ни одной современной ERP. Такие функции туда в полной мере не интегрированы.   

BI-система, в нашем её понимании, должна агрегировать и удобно представлять информацию о рабочих процессах, бухгалтерскую и финансовую отчетность, данные от систем диспетчеризации, систем электронного документооборота. Более того, часто имеет смысл отражать там данные, собранные с уровня АСУ ТП. При этом важно было, чтобы вся эта информация отображалась на одной “витрине” с возможностью гибкой настройки в зависимости от нужд конкретной компании.  

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

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

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

Таким образом исчезает классический треугольник, где есть последовательные уровни: АСУТП, MES, ERP и BI.

Вместо этого мы предлагаем создавать единую базу данных, связанную с уровнем АСУ ТП, с одной стороны, и с множеством модулей, с другой. Объединить модули и Data Lake должна платформа, представляющая собою API, которому, в частном случае, могут быть привязаны только те модули, которые необходимы предприятию. Система должна корректно упорядочивать данные в базе и передавать их различным модулям, при необходимости обмениваться с внешними источниками.   

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

При этом исчезает необходимость в большом зоопарке систем от разных вендоров и покупке общих лицензий — будет платформа — как основная часть  конструктора системы и модули, как отдельные модули конструктора.  

В сухом остатке

Применив платформенное решение в качестве альтернативы классическим ERP мы получаем:

• Сокращение пути от уровня АСУ ТП до уровня принятия решений;

• Снижение стоимости владения лицензией и возможность гибко управлять расходами при покупке конкретных модулей и лицензий для них;

• Делегировать создание модулей различным вендорам, благодаря чему быстро увеличить количество функций;

• Регулярное расширение возможностей системы, за счет создания новых модулей с минимальными затратами;

• Получение полноценной DSS-системы в виде отдельного модуля, без необходимости сложной кастомной доработки

• Оптимизация расходов на поддержку;

• Возможность быстрого масштабирования при расширении и развитии бизнеса, без значительных вложений в Z-разработку.

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