Где и зачем мы используем BPM процессы

Центральной частью биржи являются торговые системы и их торговые ядра, в которых происходит matching заявок участников рынка и формируется order_log

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

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

Почему так?

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

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

Все эти процессы проходят в бэкофисных системах биржи. Над KYC-проверкой работают несколько подразделений MOEX Group, и мы возлагаем оркестровку и мониторинг этих процессов на исполняемые BPMS схемы, а логику следования оформляем в нотации DMN.

Это удобно по следующим причинам:

• Средства, которыми мы пользуемся, достаточно зрелые, в них решены задачи обеспечения стабильности и производительности.

• Инструментарий сопровождения удобный и наглядный, легко передаётся в руки соответствующих служб сопровождения.

• Разработку можно вести быстро, а также расширять при необходимости инструментарий.

Бизнес у нас уникальный: банков в России сотни, а бирж -  единицы, поэтому заметная часть разработки является эксклюзивной и её приходится вести собственными силами под себя, при этом мы активно ориентируемся на opensource инструменты.

Начали двигаться в сторону BPMS ориентировочно с 2017г, ИСХОДНОЕ СОСТОЯНИЕ НА 2017-18ГГ: оркестрация процессов между сотрудниками выполнялась через обмен email-ами и заполнение форм в приложениях. Некоторая часть бэк-офисных систем была написана на устаревших 4GL инструментах вплоть до Paradox и FoxPro, часть веб приложений – в качестве монолитных Java приложений со своими, написанными под частные задачи, state engine или мини-workflow.

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

1. Фреймворк управления производственным процессом, метриками и качеством.

2. Производственная платформа, включающая ci/cd, фреймворки конфигурирования и мониторинга.

3. Централизованная авторизация, аутентификация.

4. Интеграционные шаблоны.

5. Единые технические сервисы (нотификации, бизнес-логирование, мониторинг процессов, планирование отложенных и регулярных задач).

В бою работает более 100 BPMS схем процессов.  Любая ценная бумага российского фондового рынка попадает в торги через эти процессы. Любой отчет по итогам торговой сессии с 2022 г. на фондовом и валютном рынках оркестрируется также нашими системами.

В качестве BPMS инструмента у нас неплохо прижился движок Camunda, как один из самых зрелых и широко используемых движков семейства Activity. Преимущественно используется v7 ввиду прозрачной склейки с Java  (для реализации machine task просто пишется Java класс).

Как мы получаем описания процессов

Бизнес-аналитики, разбирая задачу или проект, общаются с заказчиком сразу с использованием BPMN моделей, в большинстве случаев рисуя их в camunda modeler.

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

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

От аналитической BPMN схемы до исполняемой - один шаг... но не всегда:

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

• Чаще процесс интегрирует и оркестрирует цепочку систем и тогда делаем каскадирование процессов (управление уходит в подпроцессы) и тогда разработчики, глядя в документы и диаграммы, поступившие от бизнес-аналитиков, разрабатывают физические исполняемые схемы процессов

  

Какие вопросы и задачи решаем, с чем сталкиваемся

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

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

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

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

В своей работе мы активно используем «цикл Plan – Do – Check - Act» и, с некоторой периодичностью, после реализации какого-то количества функциональности, по требованиям наших заказчиков задаёмся вопросами:

1. Насколько используемые нами практики разработки позволяют быстро и эффективно реализовывать требования?

2. Не являются ли какие-то из наших подходов нашими ограничениями?

3. Что мы можем привнести в нашу инфраструктуру и практики разработки, чтобы разрабатывать быстрее?

По результатам анализа принимаем решения, как можно упростить и ускорить.

В настоящее время на уровне корпоративной архитектуры работаем над определением высокоуровневой бизнес‑архитектуры сквозных процессов Биржи, в которой процессы будут максимально перестроены для работы в формате STP: обработка стандартных операций выполняется автоматически, задача человека обработка ошибок или «нестандартных» ситуаций.