Где и зачем мы используем BPM процессы
Центральной частью биржи являются торговые системы и их торговые ядра, в которых происходит matching заявок участников рынка и формируется order_log
Именно к торговому ядру (вернее к шлюзу) подключаются участники торгов. При этом, чтобы торговая система (ТС) могла работать, в неё к началу ежедневной торговой сессии должны попасть описания торговых инструментов и описания клиентов и их параметров подключения к ТС.
Этим у нас занимаются бэк-офисные процессы, в исполнение которых вовлечены несколько различных подразделений Московской Биржи. Если в двух словах описать эти процессы: они долгие и сложные.
Почему так?
Приведем пример – допустим, пришла к нам мошенническая фирма, выпустила облигации, участники рынка купили эти облигации, а фирма вместо того, чтобы исполнять обязательства перед держателями облигаций, перевела все полученные от рынка средства на офшор на Каймановых островах и была такова. Кто за это ответит? Кого будут сажать в тюрьму?
Чтобы избежать подобных ситуаций, как при допуске к торгам финансовых инструментов, так и при допуске к торгам участников этих торгов, выполняются KYC проверки и тех и других, причем в зависимости от роли в торгах и от рынка (например, валютный, фондовый, рынок деривативов) – процессы, по которым биржа будет проверять участника торгов или эмитента финансовых инструментов, будут свои и будут состоять из разных шагов и разных наборов проверок.
Все эти процессы проходят в бэкофисных системах биржи. Над KYC-проверкой работают несколько подразделений MOEX Group, и мы возлагаем оркестровку и мониторинг этих процессов на исполняемые BPMS схемы, а логику следования оформляем в нотации DMN.
Это удобно по следующим причинам:
Средства, которыми мы пользуемся, достаточно зрелые, в них решены задачи обеспечения стабильности и производительности.
Инструментарий сопровождения удобный и наглядный, легко передаётся в руки соответствующих служб сопровождения.
Разработку можно вести быстро, а также расширять при необходимости инструментарий.
Бизнес у нас уникальный: банков в России сотни, а бирж - единицы, поэтому заметная часть разработки является эксклюзивной и её приходится вести собственными силами под себя, при этом мы активно ориентируемся на opensource инструменты.
Начали двигаться в сторону BPMS ориентировочно с 2017г, ИСХОДНОЕ СОСТОЯНИЕ НА 2017-18ГГ: оркестрация процессов между сотрудниками выполнялась через обмен email-ами и заполнение форм в приложениях. Некоторая часть бэк-офисных систем была написана на устаревших 4GL инструментах вплоть до Paradox и FoxPro, часть веб приложений – в качестве монолитных Java приложений со своими, написанными под частные задачи, state engine или мини-workflow.
Сейчас у нас есть своя бэкофисная платформа, состоящая из следующих элементов:
Фреймворк управления производственным процессом, метриками и качеством.
Производственная платформа, включающая ci/cd, фреймворки конфигурирования и мониторинга.
Централизованная авторизация, аутентификация.
Интеграционные шаблоны.
Единые технические сервисы (нотификации, бизнес-логирование, мониторинг процессов, планирование отложенных и регулярных задач).
В бою работает более 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» и, с некоторой периодичностью, после реализации какого-то количества функциональности, по требованиям наших заказчиков задаёмся вопросами:
Насколько используемые нами практики разработки позволяют быстро и эффективно реализовывать требования?
Не являются ли какие-то из наших подходов нашими ограничениями?
Что мы можем привнести в нашу инфраструктуру и практики разработки, чтобы разрабатывать быстрее?
По результатам анализа принимаем решения, как можно упростить и ускорить.
В настоящее время на уровне корпоративной архитектуры работаем над определением высокоуровневой бизнес‑архитектуры сквозных процессов Биржи, в которой процессы будут максимально перестроены для работы в формате STP: обработка стандартных операций выполняется автоматически, задача человека обработка ошибок или «нестандартных» ситуаций.
