BPEL: Новый взгляд на описание бизнес-процессов
Начальная страница сайта  Статьи  

Новый взгляд на описание бизнес-процессов

Автор: Волков Юрий Ольгердович, yvolk@yurivolkov.com

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

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

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

Поэтому обычно владелец процесса просто пишет в текстовом редакторе своеобразный рассказ (называемый регламентом, технологической схемой, сценарием и т. п.), согласовывает его в установленном порядке и передаёт данный текст (возможно, с картинками) разработчику. А уже разработчик переводит это описание бизнес-процесса на язык Системы (т.е на язык машины).

А в чём проблема?

Проблема, как говорится, стара, как мир: владелец процесса видит одно описание бизнес-процесса, а реально работает (исполняется Системой) совсем другое (исполняемое описание бизнес-процесса). Насколько они соответствуют друг другу, понять принципиально сложно, потому что фактически эти описания изложены на разных языках! Как в такой ситуации управлять процессом — непонятно. Ведь успешно управлять можно только тем, что понимаешь, а делать это через “переводчика” очень непросто…

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

Что делать

Я предлагаю решать эти проблемы непосредственно в том текстовом описании бизнес-процесса, которое создаётся его владельцем (а также его помощниками - аналитиками, консультантами и др.) и которое должно быть ему понятно настолько, чтобы он мог поставить под ним свою подпись.

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

Такой подход требует и новых терминов (абстракций), позволяющих описать бизнес-процесс как в статике (структура), так и в динамике (поведение).

Во всём остальном составленное описание — это обычный рассказ, повествование, построенное по правилам естественного (например, русского) языка, а не языка программирования.

Данное предложение по сути направлено на формализацию “рассказов”, описывающих требования к системе. В этом смысле оно дополняет рекомендации А. Кобёрна по описанию требований в виде текстовых вариантов использования (use case) [1].

Что касается графических описаний бизнес-процессов (рисунков, диаграмм и т. п.), то для владельца процесса они являются менее строгими и полными и служат для облегчения восприятия текста. Обсуждение таких описаний, а также специальных инструментов моделирования выходит за рамки данной статьи (см. статью [5] "Диаграммы для описания бизнес-процессов").

Новый взгляд

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

А ведь такой взгляд действительно есть, и изложен он в спецификации языка исполнения бизнес-процессов BPEL (Business Process Execution Language [2])! Эта открытая спецификация создана совместными усилиями мировых лидеров разработки программного обеспечения и в настоящее время является стандартом де-факто. Дальнейшее её развитие осуществляет международная некоммерческая организация OASIS [3].

Уже существуют и появляются новые механизмы (engines — “движки”) исполнения бизнес-процессов. После загрузки в любой такой “движок” описания бизнес-процесса, соответствующего спецификации BPEL, механизмы различных производителей автоматически и единообразно исполнят его.

"Но постойте", - скажет читатель, "а разве BPEL — это не язык программирования?"

На это можно ответить следующим образом. Данная спецификация в первую очередь содержит искомое нами детальное определение того, что такое бизнес-процесс и какие слова используются при его описании. А уже вслед за смысловой частью идут описания конструкций языка в формате XML, которые нам (владельцам бизнес-процессов и аналитикам) не нужны, но которые гарантируют, что Система понимает используемые там слова и выражения так же, как и мы.

Другое дело, что данная спецификация не предназначена для того, чтобы её читали владельцы процессов, — она слишком строга для неспециалиста в сфере информационных технологий. Чтобы владелец мог использовать спецификацию BPEL, описывая бизнес-процесс в текстовом документе на естественном языке, необходим специально адаптированный комментарий к данной спецификации, где в качестве примеров будут использоваться не фрагменты XML-файлов, а понятные ему образцы фраз. Думаю, такие комментарии будут появляться по мере расширения практического применения BPEL. И данная статья - две копейки в копилку таких комментариев.

И ещё: эта спецификация конечно же требует высококачественного перевода на русский язык. (В связи с этим замечу, что русскоязычная терминология в переводе книги [1], коротко говоря, плохая и пользоваться ей нужно очень осторожно...)

Но что конкретно?

Сразу оговорюсь: в рамках данной статьи невозможно (да и не нужно!) в полной мере объяснить метамодель бизнес-процесса, содержащуюся в спецификации BPEL. Моя задача сейчас — только показать читателям, что она действительно существует.

В качестве примера представьте себе интернет-услугу резервирования номеров в отелях, которую Турфирма оказывает Покупателю, выступая в качестве посредника между Покупателем и Отелем (с заглавной буквы — названия ролей участников процесса). В ходе процесса Покупатель запрашивает у Турфирмы список отелей и информацию о них, сведения о наличии номеров и ценах на определённый период, а потом заказывает номера в выбранном отеле. После этого Турфирма передаёт запрос на резервирование номеров Отелю. Получив подтверждение, что номера зарезервированы, Покупатель оформляет в Турфирме их оплату. (Подробнее аналогичный пример рассмотрен в [4]).

Используя подход BPEL, уточним приведённое выше текстовое описание:

Мы говорим о том, что в данный момент составляется описание бизнес-процесса под названием “Резервирование номеров в отелях” для Турфирмы, т. е. мы описываем бизнес-процесс, исполняемый в Турфирме. Это — уточнение взгляда на процесс. (На самом деле, для того, чтобы указанная интернет-услуга работала, у Отеля тоже должен исполняться процесс резервирования номеров, соответствующий процессу Турфирмы и взаимодействующий с ним.)

Мы говорим о том, что у Турфирмы есть несколько сервисов (service), которые обмениваются сообщениями (message) с сервисами партнёров (partner). Сервисы — это некие (элементарные) действия, которые могут быть выполнены тем или иным приложением. А кроме того, другие автоматизированные системы могут исполнять предписанные бизнес-процессы, вызывая эти сервисы в определённой последовательности. Партнёрами в данном случае являются Покупатель и Отель.

Далее мы указываем на то, что процесс длительный и обладает состоянием (state). Последнее означает, что процесс, например, “помнит” о том, что вполне определённый Покупатель ожидает подтверждения резервирования. И если он обратится к Турфирме с вопросом, подтверждено ли это резервирование (отправив соответствующее сообщение), то процесс его “узнает”, поскольку хранит информацию о предыдущих действиях данного Покупателя, т. е. хранит текущее состояние процесса. Заметьте, что мы не думаем о том, как и где процесс хранит своё состояние: это - дело техники.

Затем мы уточняем, что система Турфирмы одновременно взаимодействует с множеством Покупателей, т. е. для каждой операции резервирования создаётся свой экземпляр (instance) процесса “Резервирование номеров в отелях”. И каждый из них сохраняет состояние  — ведь у различных экземпляров свои Покупатели, а кроме того, процессы резервирования находятся на разных этапах: один Покупатель только просматривает предложения, а другой ожидает подтверждения резервирования. Понятие "экземпляра" процесса - очень глубокое и существенное для создания правильных описаний процессов. К нему нужно привыкнуть...

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

Выводы

Итак, описание, основанное на спецификации BPEL, помогает их владельцу развертывать автоматизированные бизнес-процессы, которыми он действительно может управлять:

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

Литература

1. Кобёрн А. Современные методы описания функциональных требований к системам. М.: “Лори”, 2002. См также домашнюю страницу А. Кобёрна в Интернете: http://alistair.cockburn.us/.

2. Спецификация языка BPEL версии 1.1. Адрес: http://www.ibm.com/developerworks/webservices/library/ws-bpel/.

3. Рабочие документы спецификации языка WS-BPEL версии 2.0 на сайте OASIS: www.oasis-open.org/committees/documents.php?wg_abbrev=wsbpel.

4. Clune Jim. "BPEL in Service-Oriented Architecture”. Адрес: www.sys-con.com/story/?storyid=47666&DE=1.

5. Юрий Волков. "Диаграммы для описания бизнес-процессов". Адрес: http://yurivolkov.com/articles/Diagrams_for_business_processes_ru.html.


Последнее изменение: 27 февраля 2007 г.

Первый вариант данной статьи опубликован 20 сентября 2005 г. в "PC Week/Russian Edition", №34 2005г., стр.42, 55; http://www.pcweek.ru

Hosted by uCoz