Попытки освоить бизнес-логику для ИТ-систем начались в нашей стране примерно в 1820-х. Тогда один из основателей русской кибернетики статский советник (и сын инженера-полковника) Семен Николаевич Корсаков сделал две вот такие штуки:

^{Прямолинейный гомеоскоп}

^{Простой компаратор}

Это то, что мы бы сегодня назвали механическими зачатками современных экспертных систем. Помните новость про то, что IBM распространяет свой искусственный интеллект по больницам? Так вот, С. Н. Корсаков начал делать что-то похожее минимум за 150 лет до этого. Его идея была предельно проста: нужно раздать устройства врачам на местах, и тогда врачи смогут копить опыт вместе, не делать общие ошибки и вообще лечить по стандартам. Компаратор служил средством дифдиагностики, а более простой гомеоскоп мог выступать в роли автомата, куда врач заносил симптомы и получал на выходе заболевание.

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

В общем-то, мы не очень далеко ушли от 1800-х

Современные бизнес-процессы во многом напоминают работу такого механического устройства. Например, для банка может работать правило: если клиент пользуется услугами более 3 лет (передвинули один рычаг) и сумма его счета больше 3 миллионов рублей (передвинули второй), то следует считать его VIP-клиентом (система сделала вывод). Ещё пример бизнес-правила — если сумма договора больше $300 000, то необходимо согласование с финансовым директором.

Теперь представьте, что вы руководите крупным банком или страховой компанией. У вас есть проблема с тем, что решения на местах принимаются крайне рандомно. Как сельские врачи будут использовать 100 собственных кастомных подходов к пациентам с одной и той же проблемой, так и каждое ваше отделение принимает решение о выдаче кредита или оценке риска чуть ли не по фазе луны. Разумеется, первая мысль — это внедрить чёткие правила, основанные на эвристиках или линейных сравнениях.

Так вот, именно для реализации этих правил используются BRMS-системы. Прелесть в том, что это теперь не таблички в Excel, не мнение коммерческого директора филиала и не совет коллеги, а конкретные механики. Бизнес-правила компании ведутся в едином хранилище в понятном пользователям виде. Корпоративные системы вызывают расчет правил из BRMS и получают результат.

При этом правила изменяют бизнес-пользователи без участия ИТ, и эти правила могут меняться реально быстро без кодирования. Все системы всегда используют единую версию правил. Есть контроль обязательного соблюдения правил.

Почему это важно? Ну, например, я знаю одну крупную розничную сеть, где для автоматизации используются только собственные кастомные разработки. Для этого они располагают региональным офисом разработки, где сидит 200+ разработчиков. Бизнес быстро развивается, и руководство справедливо считает гибкость одним из важных конкурентных преимуществ. Поэтому при необходимости что-то поменять в бизнес-процессах или бизнес-правилах, даже в мелочах, они садятся за свой код и быстро-быстро его переписывают. Сложность внесения изменений растёт, а сроки всегда жмут, поэтому зачастую громоздятся костыли. Разумеется, такая система крайне нестабильна. Плюс надо быть почти археологом, чтобы повторно использовать уже написанный когда-то код. Думаю, вам такая ситуация прекрасно знакома по проектам, откуда вы в ужасе бежали.

Не меньше проблем такая реализация доставляет и собственнику бизнеса — он привязывается к конкретным людям, конкретным решениям и в результате начинает платить всё больше. Энтропия растёт.

С другой стороны, большие компании, которые задумались об этом заранее и занялись построением грамотной архитектуры, таких проблем могут избежать. В частности, одним из элементов «правильной» архитектуры может быть BRMS.

Действует это так: есть пользовательский интерфейс настройки правил, есть само хранилище правил, и есть движок исполнения бизнес-правил. Например, сайт может запросить расчет размера скидки, ваша 1С может запросить проверку счёта по определенным параметрам и т.п. BRMS-система «скармливает» входящие данные хранящимся в репозитории правилам и выдаёт результат. Кстати, среди всего прочего это позволяет делать аналитические вещи, например, отслеживать машины, которые ремонтировались в течение недели по одной и той же поломке в разных местах (частый пример мошенничества на запчастях в автосервисах).

Пример

Одна из возможных реализаций – IBM ILOG JRules (ныне IBM WODM). Например, на ней мы делали BRMS-систему для одной крупной страховой компании с четырьмя сотнями филиалов по стране. Там было важно учесть кучу правил для ОСАГО и КАСКО, рассчитывать комиссию, быстро вносить изменения в правила, делать так, чтобы описание тарифа точно соответствовало расчёту в системе, плюс дать возможность заказчику самостоятельно вносить изменения в правила.

Исходная ситуация была такова: алгоритмы расчета тарифов были зашиты в коде информационных систем и в Excel-калькуляторах. Для изменения тарифов использовался стандартный ИТ-цикл «постановка задачи – разработка – тестирование — развертывание». Цикл изменений занимал несколько недель. Результат после внедрения — скорость изменения тарифа уже несколько дней, правила меняют андеррайтеры, а ИТ только сопровождает процесс; есть единый источник правил (для сотрудников и систем), благодаря этому есть полная прозрачность и точность расчётов во всех системах.

При внедрении основную работу сделали аналитик, инженер и менеджер. Они собрали более 200 параметров для расчета правил, получили десятки тысяч базовых правил. На выходе — время одного принятия решения системой менее 1 секунды, а 30 000 расчетов выполняются менее 3 минут.

Прелесть системы в гибкости и возможности практически любых настроек. Правила задаются простым человеческим языком, вроде «Если объем продаж агента за период > 1 000 000 рублей, то установить размер комиссии 20%».

Разумеется, кроме ILOG есть и решения от других вендоров, например, Oracle Automation Policy, плюс есть опенсорс-платформы, самая известная из которых JBoss Drools.

Что это значит с точки зрения ИТ?

Как минимум:

1. Меньше становится рутинного кодирования по реализации бизнес-правил. Их можно задавать декларативно.
2. Поскольку кода становится меньше, его проще сопровождать.
3. Больше усилий придется тратить на интеграцию систем, что требует более высокой квалификации разработчиков.

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

Что это значит с точки зрения пользователя?

Независимость от ИТ. Теперь не надо стучаться к разработчикам, чтобы поменять тарифы, например. Это значит, что резко растёт скорость принятия и внедрения решений внутри компании.

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

Что ещё умеет BRMS-система?

Она умеет делать event-processing. То есть пропускать через себя поток в сотни тысяч и миллионы событий, которые обрабатываются заданными бизнес-правилами. Это может быть полезно для выявления закономерностей. Пример с поиском недобросовестных действий персонала автосервисов я уже приводил. Ещё один пример — поиск тенденций рынка, например, определённые алерты при, скажем, снижении потребления трафика абонентами сотового оператора с определенными признаками. Есть фрод-детекшн, например, принятие решений по факту двух снятий денег: в ресторане в Москве и в банкомате в Китае через два часа.

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

Какие сюрпризы вскрываются при внедрении?

По моей практике — обнаруживается куча незадокументированных правил. Их нужно просто описать в BRMS. Гораздо веселее, что почти на каждом внедрении для руководства компании становится сюрпризом, какие правила используются там, куда они даже не заглядывали. Бывает, что какая-нибудь доисторическая времянка, написанная первым программистом компании за 15 минут и с кучей багов становится основой для модуля расчёта чего-то важного, и поверх обрастает всевозможными интеграциями как грибами. Ещё сюрприз для ряда подрядных и внутренних разработчиков компании — сразу снижается уровень зависимости от них. Уже не нужны «сусанины», которые единственные разбираются, как работает модуль — всё описывается в единой системе.

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

Где можно использовать?

Пожалуй, основных индикаторов, когда следует использовать BRMS, два: наличие большого числа правил и необходимость их регулярного изменения. Например, в страховой компании среднего размера используется порядка 2000 бизнес-правил. Конечно, далеко не все бизнес-правила нуждаются в автоматизации. Например, «договор на сумму более 300 000 рублей должен утверждать коммерческий директор» — это правило, которое прямо напрашивается на контроль через BRMS. А «на территорию вход только в респираторе» — скорее, на действия охранника на месте. Всё, что требует аналитики, однообразности, контроля и чёткого соблюдения в информационных системах, стоит выносить в BRMS.

Если говорить об отраслях, то BRMS пригодны фактически для использования в любой отрасли, где активно используются информационные системы.

Как понять, дозрела ли компания до BRMS?

Для начала – попробовать оценить, насколько сложно у вас будет внедрить BRMS-подход. Если у вас одна точка, мало людей, бизнес-правила простые и ошибки нарушения правил не очень критичны, то пока дешевле без внедрения новой системы. Если компания большая, цена ошибочного решения высока, ИТ-решения меняются медленно, плюс хочется иметь больше контроля над ситуацией – тогда BRMS может быть вашим выбором. Следует учесть, что лицензии на такой софт дорогие — суммы исчисляются десятками тысяч долларов (впрочем, есть и opensource-решения).

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

P.S. Если есть вопросы, которые вы не хотите задавать в комментариях, пишите на Iomehin@croc.ru.

Автор: IOmehin

Источник