Подход к
интеграции автоматизированных систем и автоматизации корпоративного управления,
основанный на предварительном описании бизнес-процессов, включающих в себя
сервисы (услуги) предприятия и его партнёров, и последующем их исполнении и
контроле с помощью автоматизированной системы завоёвывает сегодня всё большую
популярность. Однако для его успешного применения необходимо по-новому
взглянуть на описания бизнес-процессов (регламенты, технологические
схемы, сценарии и т. д.), которые традиционно составляются в текстовом виде и
понятны их владельцам (т. е. руководителям и представителям компаний).
Причем этот новый взгляд нужен как самим владельцам процессов, являющимся
авторами описаний, так и разработчикам (техническим специалистам),
реализующим эти описания в автоматизированной системе.
Слова о бизнес-процессах предприятия, объединяющих людей, документы,
оборудование и т. п. в единый работающий организм, кочуют из одной публикации в
другую. Мы в очередной раз читаем о том, что их нужно автоматизировать в рамках
единой системы, которая становится активной по отношению к внешнему миру и в
том числе к людям, участвующим в процессах. В результате система становится
управляющей, а мы — владельцы процессов, сидя наверху, контролируем их
исполнение и управляем как самими бизнес-процессами, так и участвующими в них
людьми. В итоге же мы управляем предприятием (учреждением, корпорацией,
отраслью и т. п.) в целом.
Однако затем обсуждение данной темы обычно переходит в русло технических
деталей, и читатель, если он не специалист в информационных технологиях,
понимает, что дальнейшее изложение к нему уже не относится. Даже если его
внимание пытаются привлечь словами о том, что современные чудесные средства
описания бизнес-процессов предназначены для их владельцев, он всё равно в это
не верит (и я склонен с ним согласиться).
Обычно владелец процесса просто пишет в текстовом редакторе своеобразный рассказ
(называемый регламентом, технологической схемой, сценарием и т. п.),
согласовывает его в установленном порядке и передаёт данный текст (возможно, с
картинками) разработчику. А уже разработчик переводит это описание
бизнес-процесса на язык системы.
А в чем проблема?
Проблема, как говорится, стара, как мир: владелец процесса видит одно описание
бизнес-процесса, а реально работает (исполняется системой) совсем другое
(исполняемое описание бизнес-процесса). Насколько они соответствуют друг
другу, понять принципиально сложно, потому что фактически эти описания изложены
на разных языках! Как в такой ситуации управлять процессом – непонятно.
Ведь успешно управлять можно только тем, что понимаешь, а делать это через
"переводчика" очень непросто…
Совершенно искренне желая составить такое описание бизнес-процесса, которое было
бы ориентировано на исполнение системой, его владелец сталкивается со
следующими проблемами.
-
Прежде всего неизвестно, какие слова (абстракции) нужно использовать для
описания бизнес-процессов и как из этих слов складывать понятные системе фразы.
А те абстракции, которые берутся из естественного человеческого языка,
определены недостаточно строго. Более того, нет понимания того, с какой же
точки смотреть на все это. Например, при взгляде изнутри организации
на ее взаимодействие с партнёром получится одно описание, а при взгляде "со
стороны" на это же взаимодействие – другое. В результате описания
получаются слишком упрощёнными, так что их просто недостаточно для реализации
бизнес-процессов в автоматизированной системе. (Мы имеем в виду реальные,
взятые из жизни процессы!)
-
Логика управления бизнес-процессом перемешана с остальной частью приложений (со
сложными алгоритмами, интерфейсом пользователя и т. д.). Интуитивно понятно,
что где-то граница между ними должна быть проведена, что нам следует управлять
процессом на высоком уровне, не углубляясь в излишние детали. Но у каждого
человека могут быть свои представления о месте этой границы.
-
Существует разрыв между владельцами процессов и разработчиками, который
препятствует созданию систем процессного управления. Поскольку разработчики
смотрят на процесс со своих позиций и создают его описание другим способом,
нежели владельцы (т. е. отвечающим особенностям механизма исполнения процессов
в системе), то обеспечить эффективное взаимодействие этих двух групп
специалистов в рамках проекта бывает очень сложно. Поэтому зачастую и нет
понятного владельцам процесса соответствия между поведением работающей системы
и тем, что написано в техническом задании на нее.
Что делать
Предлагается решать эти проблемы непосредственно в том текстовом описании
бизнес-процесса, которое создаётся его владельцем (а также его
помощниками – аналитиками, консультантами и др.) и которое должно быть ему
понятно настолько, чтобы он мог поставить под ним свою подпись.
При этом необходимо сформировать определённый, достаточно строгий и одинаково
понимаемый всеми заинтересованными лицами, взгляд на то, что такое бизнес-процесс,
из чего он состоит и каков его жизненный цикл. (Тут я уже немного забегаю
вперёд: еще нужно определить, что такое жизненный цикл бизнес-процесса.)
Такой подход требует и новых терминов (абстракций), позволяющих описать
бизнес-процесс как в статике (структура), так и в динамике (поведение).
Во всем остальном составленное описание — это обычный рассказ, повествование,
построенное по правилам естественного (например, русского) языка, а не языка
программирования.
Данное предложение по сути направлено на формализацию "рассказов", описывающих
требования к системе. В этом смысле оно дополняет рекомендации А. Кобёрна по
описанию требований в виде текстовых вариантов использования (use case) [1].
Что касается графических описаний бизнес-процессов (рисунков, диаграмм и т.
п.), то для владельца процесса они являются менее строгими и полными и служат
для облегчения восприятия текста. Обсуждение таких описаний, а также
специальных инструментов моделирования выходит за рамки данной статьи.
И вот мы наконец подошли к конкретному вопросу: откуда же взять этот новый взгляд
на описание бизнес-процессов? Очень хочется, чтобы он уже был достаточно
проработан, популярен и открыт, т. е. не привязан ни к каким частным правам.
А ведь такой взгляд действительно есть, и изложен он в спецификации языка
исполнения бизнес-процессов 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 выступает в качестве
соглашения между владельцем процесса и разработчиком системы и потому в случае
разногласий или взаимного непонимания может играть роль справочника.