Вкратце напомню: BRMS, или Business Rule Management System, — это «тяжёлые» системы для крупных и очень крупных компаний, которые содержат все те вещи, которые часто меняются в ИТ. Например, в банке в BRMS лежат чаще всего правила оценки по кредиту и параметры вкладов, в сотовом операторе — тарифы и нюансы вычисления всех списаний, в страховой компании — коэффициенты страхования, поправочные коэффициенты, параметры новых продуктов.
Разница между «вобьём руками» и «вобьём через BRMS» примерно такая: парни из одной страховой компании, где мы внедряли BRMS, оказались одними из немногих по итогам прошлого года, кто показал возможность работать очень гибко и быстро. Обычно внедрение коэффициента со всеми проверками занимает в среднем 2 недели. Здесь же это делается максимум за 2 дня, минимум — за считанные часы. У них есть данные статистики, на которые крайне быстро можно реагировать и перепроверять разные показатели сотни и тысячи раз. В страховании это означает возможность очень детально подстраиваться под текущую ситуацию (регион, банки) и получать куда больше прибыли.
Мы используем BRMS для оценки стоимости ИТ-проекта — она рассчитывается на основе правил вроде «работают сетевики либо программисты» и десятков переменных вроде стоимости часа специалиста.
Что такого есть в BRMS, чего не сделать конфигурационным файлом?
Итак, с одной стороны — колупание в продакшн-коде, с другой — BRMS. Где-то между ними лежит старый добрый метод среднего и малого бизнеса — конфигурационный файл, что-то вроде XML с переменными.
В целом, пока бизнес маленький, причин применять BRMS нет. Более того, одна только покупка лицензии или даже стоимость внедрения и дотачивания под себя опенсорсного продукта резко ударят по годовому бюджету. Даже несмотря на то, что для системы не требуется коннекторов в каждом участке, у всех уже давно работает через общую шину ESB, которая вызывает BRMS.
А главная потребность именно в BRMS — это рост сложности бизнес-логики. В определённый момент далеко не всё получится загнать в простой файл. Потом нужно будет вводить роли для разных пользователей на редактирование. Потом — писать отдельные функции в коде под отдельные куски правил. Делать средство поиска конфликтов правил и «разруливатель» этих конфликтов. Затем понадобится GUI с инструментов рисования потоков, чтобы было видно, что за чем идёт в процессе, и чтобы можно было посмотреть все ветки. В итоге можно всё это громоздить велосипедами, но всё равно получится какая-никакая, а BRMS.
Например, вот простейшее правило:
Это изображено наглядно при помощи блок-схемы. Это удобно для понимания и чтения всеми сотрудниками компании, кто отвечает за деньги (а не за IT). Дальше при внесении изменений можно добавить пару стрелочек и блоков, и будет не сильно сложнее.
Пример, как это работает
В страховой компании есть такие товарищи — андеррайтеры. Они следят за рынком и прибыльностью компании, ищут возможности для развития. Главный их вопрос — какие сделки с какими дилерами можно заключить (упрощая — какую работу какому контрагенту дать). Как только они что-то находят — формируют бизнес-идею, прикидывают рентабельность, защищаются у руководства.
В старом процессе продолжение такое: защитились — передают бизнес-идею в ИТ-подразделение на реализацию в систему. IT-спецы включают в плановый релиз в следующем квартале и приступают к её разработке — отвлекают вопросами андеррайтеров: «А что вы тут заложили, а как вы именно хотели?» То есть уточняют ТЗ. Разрабатывают. Тестируют. На этапе техтестирования всё стандартно, а вот потом сами андеррайтеры проверяют логику модуля с точки зрения бизнеса. В лучшем случае на это уходит от двух месяцев до квартала, на сложное — два квартала. Ситуация за это время меняется несколько раз: дилера лишат лицензии, цены поменяют, поезд уйдёт, бизнес окажется «слегка тормозом».
В новом процессе все задачи инкапсулируются, по сути. ТЗ андеррайтеры рисуют сами в виде вот такой блок-схемы, как выше (только сложнее и запутаннее). Это уже снимает море головных болей. Затем всё это покрывается автотестом, и через день (или два, если попали на выходные) в техперерывы по ночам — логика добавляется в промышленную систему.
Как встраивается BRMS?
То, что нарисовали андеррайтеры выше на блок-схеме, сразу же сохраняется в виде кода. Код, примерно соответствующий блок-схеме, вот:
Здесь нет правил перевода текста вида «Сделать А равным a1 + a2», условий «Значение для Объект1 равен Х — Да/Нет» в реальный код, как и самого генерируемого кода с логикой на Java. Это более глубокие слои BRMS’а, и для этого нужны отдельные настройки.
Ограничение в том, что андеррайтер пользуется готовой моделью параметров. В её рамках он хозяйничает и может что угодно, там есть покрытие готовым кодом. Продакшн, соответственно, обращается к репозиторию правил как ко внешней библиотеке кода — все эти места обращений надо прописать во время интеграции и покрыть всё кодом.
Когда задача выходит за рамки стандартной модели данных, снова нужна работа ИТ-подразделения. Как правило, такое случается раз в пару лет, потому что на момент внедрения модель задаётся как можно полнее, благо на самом деле не так уж много параметров меняется — сложнее взаимосвязи между ними. Например, у нас в этом проекте для страховой на старте было 350 бизнес-полей, за 6 лет добавилось ещё 10.
Наша система подсчёта стоимости проекта
Около 5 лет назад, когда мы делали коммерческие предложения, то считали затраты по средней часовой ставке компании, накладные расходы тоже считали не так детально, как хотелось, прибавляли возможную прибыль и получали внешнюю стоимость для заказчика. Этот процесс не был гибким, мы не могли себе позволить быстро просчитать различные варианты, учесть факторы, влияющие на стоимость проекта.
Соответственно, нам нужен был инструмент, который позволяет быстро прикидывать стоимость комплексного проекта исходя из его специфики. Например, в зависимости от вида деятельности (услуги по разработке или техподдержке, аутсорсинг, строительно-монтажные работы, поставка оборудования или лицензий), от того, люди каких специальностей и квалификации привлекаются и пр. Мы внедрили BRMS для решения такой задачи.
Кроме того, на базе BRMS есть движок для прокрутки сценариев «что, если», который используется для оценки экономики компании в целом при различных вариантах расчёта. Это даёт возможность принимать решения о распределении затрат между разными видами деятельности для повышения их эффективности, стимулирования перспективных направлений и достижения целей бизнеса (быть поставщиком IT-услуг №1 в стране).
Плюс наши финансисты могут сравнивать данные факта и плана, пересчитанного в BRMS, для корректировки коэффициентов расчёта и «правил игры» в компании.
Как это работает?
a. Получение входных данных из системы учёта выручки и затрат (ERP)
b. Получение плановых данных из системы планирования
c. Распределение выручки и затрат по аналитикам (этапы, виды услуг, направления и прочее) с помощью специальных алгоритмов на основе фактических данных из ERP и планов
d. (BRMS). Расчёт коэффициентов на основе данных из ERP и определённых ранее аналитик
e. (BRMS). Итоговый расчёт прибыли и рентабельности проекта
Если нужны ещё детали, вот тут есть описание проекта.
Для чего ещё может использоваться BRMS?
В целом — для принятия решений там, где нужна быстрая реакция. Например, в кейсе другой страховой компании используется так называемое инвестиционное страхование, фактически модель игры на бирже. BRMS выступает в роли сложного биржевого робота, принимающего столько решений, сколько людям не под силу, но на базе заранее заданных эвристик.
Tata Global Beverages (очень крупный импортёр чая и кофе) использует BRMS как конструктор сайтов. У них куча веб-ресурсов для 19 разных брендов, и их нужно поддерживать на множестве языковых версией. Основные обновления — списки магазинов, цены, карточки новых сортов и товаров. Всё это вносится один раз в центральном офисе, потом летит на перевод и раскидывается по сайтам. То есть здесь BRMS чем-то напоминает продукты, раскатывающие релиз по разным серверам.
MeWatt использует BRMS для уменьшения энергозатрат и выбросов CO2.
Your Move — компания по недвижимости — умудрилась окупать внедрение BRMS за 7 месяцев (обычно дольше, чувствую, за этим стоял широкий размах раздолбайства, которое решилось контролем) — их система раскидывала задачи персоналу по мере появления объектов недвижимости и клиентов. Фактически получилась связка CRM и BRMS. Использовались те же принципы биржевого робота: определялись оптимальные ставки, вешались оперативные задачи и проводились сотни вариантов опытов.
Parker Hannifin — производитель железа мониторинга для нефтянки и подобных сфер — использовали BRMS как живой репозиторий кода для .NET, чтобы очень быстро собирать новые дашборды клиентам.
Ещё тут есть сотни историй у одного из вендоров.
В России с помощью BRMS ещё считается стоимость грузоперевозок (каким маршрутом, через какого подрядчика, каким способом отправлять и компоновать ли с чем-то или нет, ждать ли сезонных изменений или нет и т. п.). Очень много специализированных банковских продуктов.
Резюме
Обычно процесс внедрения BRMS требует изменения руководителей, а это довольно сложно. Поэтому система размножается «почкованием», то есть сначала ставится где-то на одном предприятии сферы, а потом остальные начинают присматриваться и перенимать опыт. Такого, чтобы к нам напрямую обратились с уже сформированной потребностью, было пару раз, и то заказчик думал, что ему нужна фича к ERP или CRM. Мы показывали оба варианта, и один раз был выбран дешёвый и сверхбыстрый костыль, а во второй — именно система, которая в перспективе добавит ценность компании.
Ссылки
- Вендоры: IBM Operational Decision Manager; Oracle Policy Automation; JBOSS BRMS (опенсорсная); Progress Corticon и др.
- Ликбез про BRMS-системы
- Чуть больше про конкретные примеры системы с постоянными изменениями на базе IT-процессов
- Уровни зрелости IT-компании — обычно речь про BRMS заходит где-то на четвёртом.
Автор: КРОК
