Как работает автоматизация процессов в Goldman Sachs

Коллеги из Camunda проводят “Camunda Days”, на котором сообщество делится своим опытом. В июне на таком мероприятии выступили Ричард Тарлинг (Richard Tarling) и Рэндал Граебнер (Randall Graebner) из Goldman Sachs. Goldman Sachs это один из крупнейших в мире инвестиционных банков. На встрече рассказали про то как банк управляется с 14000 уникальных процессов и 1000 разработчиков с помощью Camunda. Презентация, видеозапись и тезисы доклада на русском языке в этой статье.

Бизнес-процессы

Результаты

Подход к автоматизации workflow “платформатизировался”,  в банке создали платформу для разработки приложений. The Firm(так называют банк) начинала с простейших задач по автоматизации workflow, но постепенно пришла к таким показателям.

  • 100% сотрудников используют “платформу”.
  • 5000 сотрудников используют каждый день.
  • 2 000 000 процессов создаются и закрываются каждый день. Примерно половина задач в экземплярах делается вручную.
  • 1000 разработчиков, которые создают приложения, использующие workflow.
  • 300-400 технических команд, использующих платформу для своих процессов.
  • 14000 уникальных описаний бизнес-процессов в BPMN.

Началось всё с почты

10 лет назад в банке была команда, которая работала с общим e-mail ящиком. Если клиенты что-то спрашивали, то они просто писали на этот ящик. В банке могло быть 20 человек, которые постоянно проверяли это ящик и работали с этими письмами: отвечали, оформляли сделки и так далее. Если 20 человек смотрят в один ящик, то на одно письмо клиент мог получить 3 ответа. Требовался способ этого избежать.

Коллеги построили централизованный движок задач, который решал эту проблему: он брал письма из этого e-mail ящика и перемещал их в приложение. Когда кто-то хотел ответить на письмо, он помечал письмо “В работе”.  Когда работу с письмом заканчивал — то отмечал “Сделано”.

jBPM для создания процессов

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

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

Банк создал библиотеку и делился ею с конечными потребителями — они пытались управлять ею, устанавливать её. Поскольку они не всё понимали, для Firm была очень высока стоимость поддержки.

Переход к Camunda

Основной причиной перехода было наличие плагина к Eclipse и браузерные приложения bpmn.io, в которых конечный пользователь или разработчик не должен был реально понимать как всё устроено, они просто рисовали картину и — бац! — она работает.

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

У такого подхода есть недостатки: допустим у вас есть операционный департамент, еще есть инвестиционный департамент,  департамент ценных бумаг и так далее. В таком случае банк получает “стены”, департаменты не могут делиться информацией. Чтобы справиться с этой проблемой банк построил “агрегационный слой”  над сервисами: на одной страничке была доступна информация из множества сервисов.

Масштабирование

Здесь включается bpmn.io — банк использует этот инструмент для построения flow. Банк расширил этот инструмент, чтобы он интегрировался с движком задач, чтобы задачи отображались в пользовательском интерфейсе.

Банк сделал автоматический скрипт валидации моделей на best practice. А когда команда готова выйти в продакшн, в банке используется процесс ревью.

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

Но проблема оставалась — такой подход всё равно не масштабировался, приходилось все делать руками.

Так что банк решил работать дальше над так называемыми “Workflow элементами”. Например, банк создал дашборд под названием “Workflow Control Center”. Он используется, когда команде нужен новый движок Camunda для своего приложения. Команда заполняет форму, это запускает экземпляр процесса. Сам процесс запрашивает железо, обновляет базу данных, создает логины и пароли, проходит 15-20 разных шагов для настройки новой системы. Банк использует движок Camunda для установки новых движков. Это помогает масштабироваться горизонтально.

Например, у банка есть команда “Margin Call”. В день бывает несколько миллионов запросов. Если бы банк размещал их приложения на общем движке, то соседний продукт мог бы “сложить” общий движок, а банк получил бы кучу проблем с регулятором. Поэтому у них свой, отдельный движок. Если им нужно больше ресурсов, то они могут масштабироваться самостоятельно — они могут зайти в Control Center, нажать пару кнопок и получить масштабированный движок.

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

Вопросы из зала

  • Пользователи — это внутренние сотрудники или внешние, клиенты, тоже?

Сейчас это только внутренние сотрудники.

  • Как сейчас у вас основные сложности?

База данных. Чтобы работать 24х7х365 база данных должна быть максимально отказоустойчивая и масштабируема.

  • Вы использовали встраиваемую модель Camunda для производительности?

Встраивание дало нам немного производительности, но нет, мы использовали встраивание для изоляции и обеспечения слабой связности. Чтобы одна команда не влияла на другую команду. Ну и так для горизонтального масштабирования по железу. Мы, конечно, может дать одному сервису 64гб памяти, но предел всё таки есть.

  • А что на счёт переиспользования, похоже у вас там точно что-то повторяется в 14000 процессов?

У нас особо нет возможности разобраться, что они там делают внутри. Каждая техническая команда отвечает за их собственные бизнес-процессы. Частенько эти процессы вызывают другие системы, синхронно и асинхронно. И такие вызовы могут быть полностью одинаковыми в соседних процессах. Мы такие случаи отлавливать не можем, мы просто должны быть уверены что они следуют лучшим практикам.

  • Используете Camunda Optimize?

Нет, пока не используем. Мониторинг это то место, где у нас пока есть проблемы.

  • Что, получается бизнес-аналитики создают схемы?

Бизнес-аналитики работают со своей командой, и они часто инициируют создание схемы — ставят квадратики, называют их как требуется. А потом тех.команда проверяет, что процесс реализуем и имеет смысл.

  • Как вы подготавливаете аналитиков к такой работе?

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

Принятие решений

Банк начал заниматься сервисами по моделированию решений примерно 3 года назад. В банке было несколько родственных продуктов. Так как у нас была платформа по процессам вокруг Camunda, банк решили создать свою собственную платформу вокруг решений и правил. Она полностью горизонтально масштабируется в нашем частном облаке, глобально распределена. Весь доступ к сервисам предоставляется через прокси HAProxy по REST.

Движок решений — это обёртка вокруг нескольких движков правил. Банк начинал с Drools как движка и средства моделирования от “одного из вендоров”. Это средство моделирования формировало Drools-правила.

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

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

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

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

Так что наш движок делает всё, что нужно для правил:

 

  • Считывает данные
  • Трансформирует данные
  • Введёт их по потоку
  • Принимает решение

Так же коллеги взяли от Camunda использование In-memory Database H2. Кроме того, из-за того что не нужно постоянное хранение данных в базе, коллеги отключили некоторые фишки, типа сериализации, чтобы ускорить производительность. Также поработали над логированием и аудитом, упростили их для производительности.

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

После того как Camunda выпустила DMN.io библиотеку для моделирования в браузере, банк внимательно на неё смотрит и думает о том, как бы на неё переехать.

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

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

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

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

Причиной для разработки своего интерпретатора была необходимость в высокой производительности. jDMN, так называется собственный движок, в некоторых местах быстрее в 40 раз, чем Drools.

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

От переводчика

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

Комментарии

Вам так же понравится

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: