Цифровые бизнес-процессы давно уже стали нормой для большинства компаний — многие предприятия переводят в электронный вид сквозные процессы, в которые вовлечены удаленные подразделения и множество информационных систем. Однако ИТ-инфраструктура динамична: она постоянно усложняется и масштабируется, отвлекая все больше ресурсов компании на свое обслуживание, что делает весьма затратным ее дальнейшее развитие. Применение шины данных предприятия (Enterprise Service Bus, ESB) [1] и технологий роботизации бизнес-процессов (Robotic Process Automation, RPA) [2] в ряде случаев позволяет решать проблему сложности, обеспечивая контролируемое масштабирование корпоративной информационной системы.

На сегодняшний день существуют три способа интеграции корпоративных систем:

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

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

Устаревшая система. Заказчик более десяти лет использует одну систему учета договоров и бюджетирования, но со временем появились другие решения и потребовалось передавать данные из старой системы в новые. Однако унаследованная система разрабатывалась много лет назад и не развивалась, поэтому чаще всего такие системы вообще не имеют API, что не позволяет работать через ESB.

«Чужая» система. Органы исполнительной власти столицы используют систему электронного документооборота МосЭДО, в которой обязаны работать все, несмотря на то что есть и другие внутренние системы. Такая же ситуация встречается в крупных холдингах. Классический способ сбора данных через API в этом случае невозможен: доступ к программным интерфейсам таких систем ограничен требованиями информационной безопасности и юридическими нормами. Поэтому ESB также не работает.

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

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

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

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

Интеграция через программных роботов

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

Таким образом, тандем ESB + RPA расширяет классический способ интеграции благодаря применению программных роботов, что позволяет интегрировать фактически любые системы. При этом снижается стоимость реализации интеграционных решений — отпадает необходимость в изменении или замене работающих, но не имеющих API информационных систем.

***

Совместное применение ESB и RPA при решении задач интеграции позволяет обеспечить контролируемое развитие корпоративной системы при масштабировании информационного пространства компании, а также оперативно менять бизнес-процессы, что особенно важно в условиях цифровой экономики. Развертывание новых информационных систем в существующем ИТ-ландшафте оказывается менее затратным: для их ввода в эксплуатацию достаточно подключить систему к общей корпоративной шине данных, а не интегрировать со всеми существующими системами. Кроме того, ускоряется внедрение новых систем, а стоимость интеграции с унаследованными и закрытыми системами сокращается. Дополнительным преимуществом является сокращение стоимости сопровождения и обновления интеграционных решений.

Литература

1. Леонид Черняк. Что делать с хаосом данных? // Открытые системы. СУБД. — 2013. — № 09. — C. 16–20. URL: https://www.osp.ru/os/2013/09/13038279 (дата обращения: 02.09.2019).

2. Наталья Дубова. Трансформируйся или умри: «большая семерка» ОC, версия 2019 // Открытые системы. СУБД.— 2018. — № 04. — C. 12–15. URL: https://www.osp.ru/os/2018/04/13054610 (дата обращения: 02.09.2019).

Иван Середкин (i.seredkin@hyperup.ru) — директор по развитию, компания HyperUp (Москва).