Статьи

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

Автор: Волков Юрий Ольгердович, 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 [2]. Если же с её помощью нельзя описать какую-то сложную логику, то значит, эта логика должна быть вынесена за рамки описания бизнес-процесса и реализована в виде сервиса, к которому будет обращаться наш бизнес-процесс. И это — не недостаток данной спецификации, а осознанное решение её создателей ограничить сложность описания бизнес-процессов, провести границу между тем, что делает и о чём думает владелец процесса, а чём — разработчик;
• ставя в более строгие рамки автора описания бизнес-процесса, мы вынуждаем его сосредоточиться на бизнес-стороне задачи и ориентироваться на уже существующие механизмы исполнения бизнес-процессов, а не изобретать свой собственный.

В результате мы получаем документ, понятный гораздо более широкой аудитории, в том числе и разработчику системы. Теперь он не создаёт описание бизнес-процесса с нуля, а только уточняет существующее, полученное от владельца процесса, а затем излагает его в строгой форме, полностью соответствующей спецификации 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