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

Поэтому огромный объем бизнес-правил содержится в бизнес-приложениях, как в системах типа Excel, так и в корпоративных решениях. Нередко эти правила становятся своего рода фольклором нового типа – таинственные кнопки в интерфейсе, сделанные легендарным программистом лет 5 назад, которые, чтобы приложение нормально отработало, надо нажимать в определенной последовательности. Нередко кода такого приложения ИТ-служба не имеет и изменить ничего не может.

Поэтому попытки отделить бизнес-логику от программного кода систем начались уже очень давно. Сначала использовались средства СУБД в архитектуре клиент-сервер – триггеры, процедуры. Затем появились серверы среднего звена и трехзвенная архитектура. Это и сейчас основной механизм практической реализации правил и ограничений в бизнес-приложениях.

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

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

Появление систем управления бизнес-правилами (BRMS Business Rules Management Systems) настоящим прорывом в работе с бизнес-логикой. Эти системы обладают высоким быстродействием, встроенными языковыми средствами построения правил, правила отделены от программного кода и могут выполняться как один из внешних сервисов корпоративной информационной системы.

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

Сейчас на рынке уже более 10 систем этого класса. Лидирующие поставщики корпоративных решений, такие как SAP, Oracle, IBM, Microsoft развивают как свои решения в области бизнес-правил, так и привлекают ведущих независимых производителей для усиления своих решений на базе таких продуктов как NetWeaver, WebSphere, Fusion Middleware.

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

Александр Данилов, руководитель практики управления бизнес-правилами департамента управленческого консалтинга IBS.

Управление бизнесом по правилам
Дэвид Хэй

Мой юкатанский давний друг
Купил себе питона с рук,
Но совершил просчёт:

Погиб он вскорости, забыв
Об этих правилах простых,
А змей ещё живёт.

Хилэр Бэллок

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

Все эти подходы были направлены на повышение эффективности бизнес-процессов и процессов разработки. В восьмидесятые ситуация изменилась: информатика и объектно-ориентированное программирование сместили акцент в анализе и проектировании с процессов разработки на организацию и построение структуры данных. В результате более структурированные данные стали отражать организацию и структуру компании более адекватно. Моделирование данных и объектов передвинули фокус с деятельности компании на сущности, которыми управляет компания в процессе деятельности.

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

Мы обнаружили, что существует еще одна иная область знаний, критическая для понимания природы организации – ее бизнес-правила. Бизнес-правило - это утверждение, определяющее или ограничивающее некоторые аспекты бизнеса. Предназначенное для поддержки бизнес-структуры или контроля и влияния на поведение бизнеса, бизнес-правило появляется вследствие ограничений, налагаемых на бизнес. В свою очередь, оно накладывает ограничения на действия самого бизнеса. Поэтому для понимания бизнес-правил организации важно понимать ситуацию с точек зрения различных участников процесса разработки.

Модель Захмана.

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

• Сфера деятельности – понимание причин существования организации, того что делает ее подобной другим компаниям отрасли и что отличает
• Взгляд бизнеса (владельцы процессов) – относится к восприятию компании менеджерами, но не акционерами. Понимают как работает бизнес и используют профессиональный “жаргон”
• Взгляд архитектора – выявление фундаментальных, независимых от технологии сущностей, и представление их бизнесу в его терминах.
• Взгляд системного аналитика – приложение технологий для удовлетворения выявленных на более высоких уровнях модели требований. Эта технологическая перспектива: системы реляционных баз данных, диаграммы объектов, сетевые протоколы и пр.
• Взгляд программиста – взгляд на систему с точки зрения программ и технологий. Разработчики знают различные аспекты применения программных средств, коммуникационных технологий и пр.
• Видение эксплуатации – взгляд на завершенную систему

Но если в процессе разработки существует множество граней, то что же они отражают? Рассматривая историю системной разработки, мы уже отметили две из них: процессы и данные. В эпоху распределенных систем, можно выделить ещё одну – географическое расположение. Где же хранятся и используются данные, и где происходит их обработка? Когда Джон Захман впервые разработал свою модель, она представляла собой таблицу с тремя вышеназванными колонками и шестью строками, отражающие вышеназванные точек зрения. Таким образом, каждая ячейка таблицы представляла собой точку зрения определенных участников проекта на определенный этап разработки системы. Модель данных, например, использовалась для отражения точки зрения архитектора на данные, в то время как диаграмма потоков данных отражала взгляд владельцев процессов.

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

Более всего в 1987 году был непонятен вопрос «почему». На самом высоком уровне существуют бизнес-цели и планы, но как они связаны с целями владельцев бизнес-процессов, архитекторов и проектировщиков?
Так возникли бизнес-правила. С тех пор, в течение десяти лет в ИТ-индустрии появляются материалы, описывающие управление ограничениями бизнеса. В 1995м году пользовательская группа IBM, GUIDE, издала отчет, посвященный управлению требованиями и возможных подходов к описанию бизнес-правил. Рон Росс написал обширную книгу на эту тему. Барбара фон Халле опубликовала множество статей, по программированию и проектированию баз данных. Публикации о бизнес правилах появляются буквально каждый день.

Комментарии: (0)   Рейтинг: