ERP VS Микросервисы

Продолжение материала, опубликованного ранее, основанного на нашем личном опыте работы со средним бизнесом и Enterprise компаниями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы сейчас задумываетесь об автоматизации сбора данных для аналитики и используете для учета, скажем, только 1С и Excel, то ваша ситуация идеальна для начала интеграции микросервисов.