Обзор методов построения систем управления бизнес правилами

При автоматизации принятия различных экономических решений (например, автоматизация принятий решений по кредитным заявкам) большинство организаций сталкивается с необходимостью разработки и внедрений специализированного программного обеспечения, относящегося к классу систем управления бизнес правилами (англ. business rules management system (BRMS)) [1]. Данный класс систем по принципу своей работы близок к системам поддержки принятия решений (СППР). Однако не всегда бывает достаточным выбрать только технологию программного обеспечения, гораздо важнее правильно применить данную технологию. Выделим основные преимущества BRMS технологии:

• •    Архитектура.

• •    Возможность интеграции с корпоративными приложениями.

• •    Удобное представление различных знаний.

• •    Формирование наборов правил из независимых правил.

• •    Создания хранилищ правил, поддерживающих механизм версий.

Согласно положению Базель банковские структуры должны обеспечить регулярный цикл валидации модели, включающий контроль устойчивости и производительности. [2] Поэтому необходим эффективный инструментарий, обеспечивающий валидацию построенных математических моделей.

Системы класса BRMS позволяют достаточно легко работать с правилами и фактами. Правило это выражение, которое имеет структуру ЕСЛИ x, ТО y или может быть преобразовано к данной структуре. Например, формула ДОХОД=ДОХОД1+ДОХОД2 никак не может являться правилом, в данном случае это всего лишь выражение. Приведем некоторый пояснительный пример: «Если заемщик мужчина принадлежит к социальноэкономической группе А и является холостым, то ему необходимо отказать». При формализации данного выражения, написанного на русском языке к виду правила получится следующее:

«ЕСЛИ ЗАЕМЩИК. ПОЛ =M, и ЗАЕМЩИК. ГРУППА=А и ЗАЕМЩИК. СЕМЕЙНЫЙСТАТУС=ХОЛОСТ, то ОТКАЗАТЬ»

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

• •    Правила должны быть написаны как можно более эффективно.

• •    Правила должны иметь ожидаемый результат выполнения.

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

• •    Правила должны быть легко перенастраиваемые при изменении условий.

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

ЕСЛИ ТИПКЛИЕНТА=КОРПОРАТИВНЫЙ ТО

УМЕНЬШИТЬ СТАВКУ НА 1 И

УВЕЛИЧИТЬ СУММУ НА 10000

Однако предположим, что возникла необходимость увеличивать сумму, только в случае, если корпоративный клиент выбрал определенный продукт. В этом случае правило придется изменить. Было бы логично разбить первоначальное правило на два атомарных:

ЕСЛИ ТИПКЛИЕНТА=КОРПОРАТИВНЫЙ ТО

УМЕНЬШИТЬ СТАВКУ НА 1

ЕСЛИ ТИПКЛИЕНТА=КОРПОРАТИВНЫЙ, ТО

УВЕЛИЧИТЬ СУММУ НА 10000

В данном случае менее затруднительно и более наглядно произвести необходимые изменения:

ЕСЛИ ТИП КЛИЕНТА=КОРПОРАТИВНЫЙ, ТО

УМЕНЬШИТЬ СТАВКУ НА 1

ЕСЛИ         (ТИПКЛИЕНТА=КОРПОРАТИВНЫЙ         И

ПРОДУКТ=СПЕЦИАЛНЫЙ) ТО

УВЕЛИЧИТЬ СУММУ НА 10000

В большинстве систем класса BRMS реализован функционал табличного задания правил. Пример подобной таблицы приведен на Рис. 1.

Каждая из ячеек данной таблицы представляет собой отдельное правило, например, для левой верхней ячейки имеем:

ЕСЛИ Income ЛЕЖИТ В ИНТЕРВАЛЕ ОТ 7500 ДО 9999 и Card Type Student Bronze, ТО

Credit limit = 1000

Card Type CondrionRy

Income Condition (Credit Limit Action|Credit Limit Action|Credit Limit Action

7,500 - 9,999	1,000	1,500	2,000
10,000 - 19,999	1,100	1,600	2,100
20,000 - 29,999	1,200	1,700	2,200
30,000 - 39,999	1,500	2,200	2,700
40,000 - 49,999	2,000	2,500	3,000
50,000 - 59,999	2,500	2,800	3,300
60,000 - 69,999	3,500	3,800	4,000
70,000 - 79,000	4,000	4,500	4,800
80,000 - 89,999	4,500	4,700	5,200
90,000 - 99,999	5,000	5,200	5,700

Рис. 1 – Таблица решения.

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

Рис. 2- Пример дерева решений.

Одно из возможных правил этого дерева: ЕСЛИ i1>=10000, ТО Decision Approve.

При построении бизнес логики работы систем класса BRMS первоначально необходимо построение большого количества имитационных моделей, т.к. по сути каждое правило отражает закономерности их работы. Поэтому актуален вопрос не только об анализе (в.т.ч. и визуальном) различных статистических закономерностей, но и о гибком механизме представления и передачи информации. Средства для решения подобного класса задач более подробно были описаны в [3].

В реальных системах получил широкое распространение расширяемые язык разметки (англ. eXtensible Markup Language) – XML. [4] Являясь по сути текстовым форматом данных XML достаточно просто позволяет хранить структурированные данные. Для обработки же файлов такого формата создано большое различным приложений, а в силу текстового формата файлы xml могут быть использованы для построения обмена информацией между различными системами.