Вид
 

LiveInternet

  Рейтинги
  Еще дневник из 1,50 млн. (+1,51 тыс. сутки)

IT преступность Базы данных Гаджеты Коупные сделки в IT Бренды Web сервисы Выставки и форумы VoIP решения Кластеры Сетевые архитектуры Методы сетевой защиты Современные браузеры Социальные сети Интелектуальные системы Процессоры Инвестиции в IT Мобильные устройства Ноутбуки Рынок СУБД Свободное ПО CRM системы Технологии видеочипов

Машина Времени

Суббота, 28 Марта 2009 г. 14:39 (ссылка)
Процитировано 1 раз +в цитатник или сообщество +поставить ссылку
Нет ничего более обидного,чем делая поиск по необходимой информации,найти нужное,и кликая по найденной странице,обнаружить,что она более не существует.
К сожалению,такое случается часто.Часть страниц удаляется,не поддерживаются больше сервера и прочее.Однако шансы найти утраченную страницу существуют.
Всё зависит от того,по какой причине я не могу её получить.



Полный цикл управления бизнес-процессами с применением инструментов, поддерживающих стандарты


Оригинал: Closed Loop BPM using Standards based Tools , An Oracle White Paper, ноябрь 2004

Введение

Бизнес-процессы – это основа любой успешной компании. Эти процессы объединяют системы, партнеров и сотрудников для достижения ключевых стратегических и тактических целей. Возрастающее число компаний присматриваются к Web-сервисам и сервис-ориентированной архитектуре (Service Oriented Architecture, SOA) для решения проблем интеграции, возникающих при соединении приложений. BPEL и другие стандарты в области Web-сервисов предлагают открытый, переносимый и стандартизованный способ решения типичных проблем развития приложений. Они позволяют создавать решения на базе SOA, которые обеспечивают гибкость бизнеса при максимальном использовании уже задействованных ресурсов и минимизации стоимости развертывания новых приложений.

Желание располагать адаптивными бизнес-процессами, которые могут быть тонко настроены и оптимизированы, чтобы соответствовать изменяющимся условиям бизнеса, нормативным требованиям законодательства и давлению конкуренции, привело к системам управления бизнес-процессами полного цикла (closed loop Business Process Management (BPM) systems). Oracle BPEL Process Manager + инструменты моделирования других производителей – это полная и легкая в применении платформа для проектирования и развертывания BPM-решений полного цикла.

Рис. 1.BPM-решение полного цикла

Жизненный цикл процесса состоит из следующих шагов или задач:

  • Моделирование процесса (Model the process) – во время этого шага владельцы бизнес-процессов создают высокоуровневую модель, состоящую из задач, которые должны выполняться, и нужных для этого ресурсов. Кроме того, делаются некоторые предположения о времени выполнения и стоимости каждой задачи.
  • Имитация и анализ (Simulate and Analyze) — полученная высокоуровневая модель используется для “прогона” некоторых гипотетических сценариев с целью обнаружения критических участков (paths) и “узких горлышек” (bottlenecks). Полученная информация применяется для тонкой настройки процесса перед его развертыванием.
  • Внедрение и документирование (Implement and document) — во время этого шага высокоуровневый бизнес-процесс, точнее его описание высокого уровня, преобразуется в модель исполняемого процесса. Сам же процесс документируется для того, чтобы он мог использоваться для обучения и сопровождения в будущем.
  • Развертывание и исполнение (Deploy and Execute) – этот шаг включает развертывание процесса для BPM-“движка” (BPM-engine) и его исполнение для реализации сквозных (end to end) потоков [управления и данных] между системами и людьми.
  • Мониторинг (Monitor) – во время этого шага происходит мониторинг бизнес-процессов с целью получения ключевых индикаторов эффективности и других метрик. Это шаг выполняется, как правило, с применением средства мониторинга бизнес-активности (Business Activity monitoring tool) совместно с BPM-“движком”.
  • Оптимизация и перепроектирование (Optimize and Redesign) – после того, как над системой в течение некоторого времени проведен мониторинг, полученные за это время метрики (historical metrics) могут быть использованы для дальнейшей оптимизации процесса. Реальная пропускная способность процесса и метрики использования могут быть введены в инструмент имитации, чтобы получить оптимальную исполненительную модель.

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

II. Моделирование процессов с применением BPMN

В качестве стандарта для моделирования бизнес-процессов получает признание BPMN (Business Process Modeling Notation - нотация моделирования бизнес-процессов), разработанная организацией Business Process Modeling Initiative (BPME.org).

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

BPMN напрямую отображается на языки исполнения бизнес-процессов, такие как BPEL и BPML. BPMN предоставляет нотацию для моделирования, а BPEL является языком описания исполнения процессов.

К ключевым особенностям BPMN относятся:

  • Пулы и лейны (Pools and lanes- бассейны и дорожки) — эти сущности используются для демаркации процессов и систем. Пул используется, чтобы разделить различные бизнес-сущности или участников. Действия (activities) внутри пулов – это модульные (self-contained) процессы. Лейны (Lanes) используются для описания и разделения действий в пулах (как бы водные дорожки в бассейне– прим.ред ). Они, как правило, используются для группирования действий по функциям или ролям.
  • События и действия (Events and activities) — События используются для представления того, что происходит в процессе бизнес-деятельности. У этих событий обычно есть причины/эффекты (следствия), и они могут влиять на сам поток. Действия ссылаются на работу, которая исполняется, либо как единая задача, либо как набор задач (подпроцесс).
  • Соединенные объекты (Connect objects) — различные сущности BPMN могут быть соединены через последовательность операций, поток операций (sequence flow), чтобы отметить порядок, в котором действия выполняются, поток сообщений, чтобы отметить сообщения между сущностями, или ассоциацию, используемую для ассоциирования текста и других артифактов с объектами потока (flow objects).
  • Проектирование сложного процесса (Complex process design) - BPMN может использоваться, как для высокоуровневого описания процессов, так и для описания сложных процессов со многими уровнями детализации. Процессы могут включать детализирующие представления (drill down views) для описания деталей более низкого уровня (lower levels of detail) внутри отдельных диаграмм.
  • Моделирование и контроль сообщений (Model message and control) — в дополнение к спецификации порядка операций в потоке BPMN обеспечивает представление об объектах данных для моделирования того, как документы, данные и другие объекты используются и изменяются во время процессного потока.
  • BPMN предоставляет нотацию моделирования, которая обеспечивает переход от бизнес-определений к карте исполнения процесса (process execution map). Объекты BPMN обладают богатым набором атрибутов, которые позволяют легко отображать эти объекты в описания BPEL, стандарт defacto для исполнения процессов.
  • Нотация BPMN расширяема и позволяет использовать ассоциации и аннотации для установления взаимоотношений с другими артифактами внутри или вне вашей системы. Например, можно соотнести бизнес-процессы с функциями, которые они выполняют, с данными, которые они используют, с системами, на которых они развернуты, и т.д.

Рассмотрим пример процесса LoanFlow (), который используется типичным брокером займов (loan broker). Этот брокер займов принимает запрос от клиента, выполняет кредитную проверку (credit check) с обращением к внешней службе и затем направляет это прошение к двум различным агентствам по предоставлению займов (loan agencies). После получения предложений от них лучшее будет отобрано и клиент будет уведомлен об этом.

На этапе моделирования обычно специфицируются участники (LoanBroker, CreditRating service, StarLoanService, UnitedLoanService и клиент). Процесс LoanFlow оркестрирует взаимодействия между этими сервисами. Для этого необходимо специфицировать последовательность событий и поток сообщений между этими сущностями, используя BPMN. Рис. 2 иллюстрирует высокоуровневую модель процесса в BPMN и детализацию для подмножества этого процесса, когда соответствующий менеджер (loan offer) обращается к двум различным агентствам по предоставлению займов.

III. Имитация и анализ

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

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

  • Вычислить среднее (average elapsed) время транзакции, полную, от начала до конца (end-to-end) пропускную способность и стандартные отклонения (deviation) для определения того, насколько эти отклонения соответствуют допустимым по соглашениям об уровне обслуживания SLA (Service Level Agreements);
  • Идентифицировать “узкие места” при использовании процесса и ресурсов;
  • Определить количественно человеческие и другие ресурсы, необходимые для завершения задач, чтобы соответствовать заданным SLA;
  • Вычислить ожидаемые оценки ошибок и рейтинги уровней обслуживания по 6 сигма (six sigma);
  • Определение оптимизации, необходимой для перехода процесса на уровень “как должно быть”;

Продолжая пример LoanFlow из Секции II, можно смоделировать режим заполнения и время обработки прошений о займе для каждого агентства, о предоставлении займов, а затем “прогнать” имитацию, чтобы оценить пропускную способность или время ответа для сквозного потока. Также, если мы предположим, что есть некоторое, достаточное для выполнения этой задачи, количество агентов по займам в StarLoan и UnitedLoan, и мы зададим некоторое среднее время для обработки прошения о займе, то имитация поможет определить использование ресурсов и число нужных ресурсов на основе ожидаемых запросов на займы.

IV. Документирование и внедрение

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

Следующий после документирования шаг – это внедрение бизнес-процессов. Язык BPEL (Business Process Execution Language) становится очевидным стандартом внедрения для объединения множества синхронных и асинхронных сервисов в коллективные (collaborative) потоки и транзакции. При разработке BPEL воспользовались результатами более чем десяти исследований его предшественников – языков XLANG и WSFL. Он включает следующие концепции:

  • Web Services/WSDL - как компонентная модель
  • XML - как модель данных
  • Шаблоны синхронного и асинхронного обмена сообщениями
  • Детерминированная и недетерминированная координация потока
  • Иерархическое управление исключительными ситуациями
  • Долгоживущая единица работы/компенсации (Long-running unit of work/compensation)
OracleBPEL Designer предоставляет графический и дружественный интерфейс для построения BPEL-процессов. Что выделяет Oracle BPEL Designer – так то, что BPEL – это его “родной” формат. Это означает, что процессы, построенные с применением этого инструмента, 100% переносимы, и, кроме того, он позволяет разработчикам просматривать и модифицировать исходный код на BPEL, не снижая полезности этого инструмента.

Если высокоуровневый процесс смоделирован на BPMN, он прежде всего экспортируется к скелетному (skeletal) BPEL-процессу, который как правило, состоит из областей действия процесса (process scopes), действий по вызову/получению (invoke/receive activities) и партнерских связей к соответствующим сервисам (partner links to the appropriate services).

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

  • Идентифицирование операций web-сервисов, которые вызываются различными сервисами;
  • Специфицирование типов XSD для сообщений, которыми обмениваются различные сущности;
  • Моделирование карты трансформаций для различных типов сообщений, посылаемых и получаемых из различных систем;
  • Специфицирование положения конечных точек (endpoint) и параметров соединения для вовлеченных сервисов.

Если мы рассмотрим пример LoanFlow, описанный ранее,то для кода наBPEL, сгенерированного из средства моделирования BPMN, потребуется включение URL для этих сервисов, XSD для прошения об займе и предложения займа, а также определение трансформаций данных между документами, которые передаются между сервисами. Рис. 3 показывает процесс LoanFlow, смоделированный в Oracle BPEL Designer.

V. Развертывание и исполнение

Наиболее критичным этапом в жизненном цикле процесса является его развертывание на платформе, которая может оркестрировать поток и выполнять различные задачи этого процесса. Оркестрирование набора сервисов в сквозной поток процесса требует выполнения множества технических требований, включая соединение (binding) с разнородными системами, шаблоны для синхронного и асинхронного обмена сообщениями, манипулирование данными, координация в потоке, управление исключительными ситуациями, недетерминированные события, компенсирующие транзакции (compensating transactions), управление версиями, и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. ПродуктOracle BPEL Process Manager обеспечивает наиболее зрелую, масштабируемую и полную реализацию механизма исполнения BPEL, доступную сегодня. Некоторые из ключевых функций этого сервера:
  • Поддержка стандартов — механизм включает непосредственную поддержку стандартов BPEL и web-сервисов;
  • Производительность и масштабируемость – высокопроизводительный BPEL-механизм исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” ("dehydration"), так что состояние долгоживущих потоков автоматически поддерживается в базе данных. Возможно применение кластеров для обеспечения масштабируемости и отказоустойчивости;
  • Продвинутые функции – другие важные функции включают автономную работу с версиями, секционирование процесса и продвинутое управление исключительными ситуациями;
  • Множество платформ развертывания - BPEL Server использует OC4J как базовый J2EE-сервер приложений с поддержкой большинства основных коммерческих серверов приложений;
  • Встроенные сервисы интеграции — они позволяют использовать продвинутые возможности соединений и трансформаций из стандартного BPEL-процесса. Эти возможности включают поддержку для трансформаций и соединений с использованием механизма XSLT/Xquery, а также множества тиражируемых приложений и унаследованных систем . Расширяемая схема соединения WSDL обеспечивает соединения по протоколам и форматам сообщений, другим нежели SOAP. Соединения доступны для JMS, электронной почты, JCA, HTTP и многих других протоколов для связи с сотнями внутренних (back-end) систем.
  • Сервис пользовательской задачи (User task service), предоставляется как встроенный BPEL-сервис для обеспечения интеграции людей и выполняемых ими вручную задач в BPEL-потоки.
  • BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console и Java API.

На рисунке 4 показана архитектура BPEL Process Manager и сопутствующих компонентов.

VI. Мониторинг

Измерение ключевых метрик процессов и “видимость” (visibility) в реальном времени исполнения процессов критичны для оценки производительности развернутых бизнес-процессов. Oracle Business Activity Monitoring (BAM) – это критичный компонент нашего полного BPM-решения.

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

Ключевые концепции Oracle BAM таковы:

  • Бизнес-события (Business Events) – перехват таких интересных событий как изменение информации о клиентах, изменения в описи товаров, заказах на покупку из широкого ряда информационных систем предприятия (EIS).
  • Составные события (Composite events) – определение, агрегирование, соотнесение и фильтрация событий от различных конечных систем.
  • Метрики и ключевые индикаторы эффективности (КПЭ или KPI) – выполнение сложной обработки составных событий для генерации метрик и КАЭ.
  • Сигналы (Alerts) – уведомление пользователей через различные каналы (электронная почта, голосовая почта, пэйджеры,..) на основе превышения пороговых значений и/или порогов рисков для некоторых ключевых метрик.
  • Визуализация в масштабе реального времени - широкий набор средств визуализации в масштабе реального времени на BAM-панели для показа данных самых последних событий и детализации при анализе основных факторов.

См. рисунок 5.

Продолжим наш пример с LoanFlow из Секции II . После того, как процесс развернут, BAM-панель может быть использована, чтобы ответить на критические бизнес-вопросы:

  • (a) Запросы на займы, предоставленные сегодня, на этой неделе, в этом месяце.
  • (b) Предложения займов по агентствам
  • (c) Среднее время обработки одного займа
  • (d) средняя кредитная оценка (скоринг) лиц, желающих получить заем.

Также BAM-панель может отобразить сигналы:

  • (a) были предоставлены займы многим лицам с низкой скоринговой оценкой
  • (b) процент отвергнутых прошений о займах больше 10%.

Последний факт можно использовать для переоценки критериев отбора или для того, чтобы предпринять некоторые предупредительные действия. Рисунок 6 показывает BAM-панель с некоторыми ключевыми метриками для процесса LoanFlow.

VII. Оптимизация и перепроектирование

BAM закрывает отсутствующее звено между исполнением процесса и перепроектированием. Традиционно имитация процессов основана на предположениях и догадках. Проблема такого подхода в том, что надежны только результаты, а предположения делались на этапе моделирования. При применении BAM, как данные реального времени, так и исторические данные, накопленные за период времени, могут быть использованы, чтобы промоделировать процесс “как есть” (“as-is”) и создать оптимальный процесс “как должно быть” ("to-be"). Благодаря таким успешным итерациям процесс может быть тонко настроен, что приведет к значительной экономии ресурсов и средств.

События в BAM также могут быть использованы для оптимизации развернутых процессе в реальном времени, благодаря изменениям потока бизнес-процесса. Сигналы (alerts) BAM также могут начать новые бизнес-процессы для обработки исключительных ситуаций или быть использованы для прерываний процессов.

Еще раз рассмотрим пример LoanFlow. На этапе оптимизации должны использоваться данные реальной обработки на основе ежедневных/ежемесячных отчетов и затем прогоны инструмента имитации для обнаружения возможных узких мест и уровней обслуживания (predict SLA). Это может привести к перепроектированию процесса. Например, к добавлению новых сервисов при оформлении займа, что соответствовать требованиям по времени ответ. Некоторые из этих метрик также могут использоваться в реальном масштабе времени. Например, если какое-то из агентств слишком долго не отвечает, процесс может продолжать работу только с одним предложением займа (применительно к одному агентству), чтобы удовлетворить SLA-требованиям обслуживания.

VIII. Партнеры

Корпорация Oracle установила партнерские отношения с рядом поставщиков, чтобы предоставить средства моделирования и имитации вместе с Oracle BPEL Process Manager и инструментом Oracle Business Activity Monitoring. В число этих поставщиков входят Popkin Systems and Software Ltd ( www.popkin.com ) — продукты Popkin System Architect и Popkin Simulator II могут быть использованы для моделирования и анализа процессов. При этом применяется BPMN и экспорт в формате BPEL для развертывания на платформе Oracle.

За более подробной информацией о моделировании процессов с использованием этих средств, их внедрении и развертывании с Oracle BPEL Process Manager, обращайтесь по адресу http://www.oracle.com/technology/products/integration/index.html

IX. Заключение

BPM-системы полного цикла критичны для разработки эффективных бизнес-процессов, которые должны быстро реагировать на изменяющиеся бизнес-условия. Oracle AS Integration – это в настоящее время наиболее полная BPM-платформа на рынке. Она обеспечивает реализацию всего жизненного цикла процесса, включая моделирование, имитацию, внедрение, исполнение, мониторинг и оптимизацию бизнес-процессов.

CitCity

Комментарии

Юра, Чтв 23 Апр 2009 14:20:26:То что надо, что бы препод отвязался

Комментарии заморожены.

Введение

Бизнес-процессы – это основа любой успешной компании. Эти процессы объединяют системы, партнеров и сотрудников для достижения ключевых стратегических и тактических целей. Возрастающее число компаний присматриваются к Web-сервисам и сервис-ориентированной архитектуре (Service Oriented Architecture, SOA) для решения проблем интеграции, возникающих при соединении приложений. BPEL и другие стандарты в области Web-сервисов предлагают открытый, переносимый и стандартизованный способ решения типичных проблем развития приложений. Они позволяют создавать решения на базе SOA, которые обеспечивают гибкость бизнеса при максимальном использовании уже задействованных ресурсов и минимизации стоимости развертывания новых приложений.

Желание располагать адаптивными бизнес-процессами, которые могут быть тонко настроены и оптимизированы, чтобы соответствовать изменяющимся условиям бизнеса, нормативным требованиям законодательства и давлению конкуренции, привело к системам управления бизнес-процессами полного цикла (closed loop Business Process Management (BPM) systems). Oracle BPEL Process Manager + инструменты моделирования других производителей – это полная и легкая в применении платформа для проектирования и развертывания BPM-решений полного цикла.

Рис. 1.BPM-решение полного цикла

Жизненный цикл процесса состоит из следующих шагов или задач:

  • Моделирование процесса (Model the process) – во время этого шага владельцы бизнес-процессов создают высокоуровневую модель, состоящую из задач, которые должны выполняться, и нужных для этого ресурсов. Кроме того, делаются некоторые предположения о времени выполнения и стоимости каждой задачи.
  • Имитация и анализ (Simulate and Analyze) — полученная высокоуровневая модель используется для “прогона” некоторых гипотетических сценариев с целью обнаружения критических участков (paths) и “узких горлышек” (bottlenecks). Полученная информация применяется для тонкой настройки процесса перед его развертыванием.
  • Внедрение и документирование (Implement and document) — во время этого шага высокоуровневый бизнес-процесс, точнее его описание высокого уровня, преобразуется в модель исполняемого процесса. Сам же процесс документируется для того, чтобы он мог использоваться для обучения и сопровождения в будущем.
  • Развертывание и исполнение (Deploy and Execute) – этот шаг включает развертывание процесса для BPM-“движка” (BPM-engine) и его исполнение для реализации сквозных (end to end) потоков [управления и данных] между системами и людьми.
  • Мониторинг (Monitor) – во время этого шага происходит мониторинг бизнес-процессов с целью получения ключевых индикаторов эффективности и других метрик. Это шаг выполняется, как правило, с применением средства мониторинга бизнес-активности (Business Activity monitoring tool) совместно с BPM-“движком”.
  • Оптимизация и перепроектирование (Optimize and Redesign) – после того, как над системой в течение некоторого времени проведен мониторинг, полученные за это время метрики (historical metrics) могут быть использованы для дальнейшей оптимизации процесса. Реальная пропускная способность процесса и метрики использования могут быть введены в инструмент имитации, чтобы получить оптимальную исполненительную модель.

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

II. Моделирование процессов с применением BPMN

В качестве стандарта для моделирования бизнес-процессов получает признание BPMN (Business Process Modeling Notation - нотация моделирования бизнес-процессов), разработанная организацией Business Process Modeling Initiative (BPME.org).

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

BPMN напрямую отображается на языки исполнения бизнес-процессов, такие как BPEL и BPML. BPMN предоставляет нотацию для моделирования, а BPEL является языком описания исполнения процессов.

К ключевым особенностям BPMN относятся:

  • Пулы и лейны (Pools and lanes- бассейны и дорожки) — эти сущности используются для демаркации процессов и систем. Пул используется, чтобы разделить различные бизнес-сущности или участников. Действия (activities) внутри пулов – это модульные (self-contained) процессы. Лейны (Lanes) используются для описания и разделения действий в пулах (как бы водные дорожки в бассейне– прим.ред ). Они, как правило, используются для группирования действий по функциям или ролям.
  • События и действия (Events and activities) — События используются для представления того, что происходит в процессе бизнес-деятельности. У этих событий обычно есть причины/эффекты (следствия), и они могут влиять на сам поток. Действия ссылаются на работу, которая исполняется, либо как единая задача, либо как набор задач (подпроцесс).
  • Соединенные объекты (Connect objects) — различные сущности BPMN могут быть соединены через последовательность операций, поток операций (sequence flow), чтобы отметить порядок, в котором действия выполняются, поток сообщений, чтобы отметить сообщения между сущностями, или ассоциацию, используемую для ассоциирования текста и других артифактов с объектами потока (flow objects).
  • Проектирование сложного процесса (Complex process design) - BPMN может использоваться, как для высокоуровневого описания процессов, так и для описания сложных процессов со многими уровнями детализации. Процессы могут включать детализирующие представления (drill down views) для описания деталей более низкого уровня (lower levels of detail) внутри отдельных диаграмм.
  • Моделирование и контроль сообщений (Model message and control) — в дополнение к спецификации порядка операций в потоке BPMN обеспечивает представление об объектах данных для моделирования того, как документы, данные и другие объекты используются и изменяются во время процессного потока.
  • BPMN предоставляет нотацию моделирования, которая обеспечивает переход от бизнес-определений к карте исполнения процесса (process execution map). Объекты BPMN обладают богатым набором атрибутов, которые позволяют легко отображать эти объекты в описания BPEL, стандарт defacto для исполнения процессов.
  • Нотация BPMN расширяема и позволяет использовать ассоциации и аннотации для установления взаимоотношений с другими артифактами внутри или вне вашей системы. Например, можно соотнести бизнес-процессы с функциями, которые они выполняют, с данными, которые они используют, с системами, на которых они развернуты, и т.д.

Рассмотрим пример процесса LoanFlow (), который используется типичным брокером займов (loan broker). Этот брокер займов принимает запрос от клиента, выполняет кредитную проверку (credit check) с обращением к внешней службе и затем направляет это прошение к двум различным агентствам по предоставлению займов (loan agencies). После получения предложений от них лучшее будет отобрано и клиент будет уведомлен об этом.

На этапе моделирования обычно специфицируются участники (LoanBroker, CreditRating service, StarLoanService, UnitedLoanService и клиент). Процесс LoanFlow оркестрирует взаимодействия между этими сервисами. Для этого необходимо специфицировать последовательность событий и поток сообщений между этими сущностями, используя BPMN. Рис. 2 иллюстрирует высокоуровневую модель процесса в BPMN и детализацию для подмножества этого процесса, когда соответствующий менеджер (loan offer) обращается к двум различным агентствам по предоставлению займов.

III. Имитация и анализ

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

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

  • Вычислить среднее (average elapsed) время транзакции, полную, от начала до конца (end-to-end) пропускную способность и стандартные отклонения (deviation) для определения того, насколько эти отклонения соответствуют допустимым по соглашениям об уровне обслуживания SLA (Service Level Agreements);
  • Идентифицировать “узкие места” при использовании процесса и ресурсов;
  • Определить количественно человеческие и другие ресурсы, необходимые для завершения задач, чтобы соответствовать заданным SLA;
  • Вычислить ожидаемые оценки ошибок и рейтинги уровней обслуживания по 6 сигма (six sigma);
  • Определение оптимизации, необходимой для перехода процесса на уровень “как должно быть”;

Продолжая пример LoanFlow из Секции II, можно смоделировать режим заполнения и время обработки прошений о займе для каждого агентства, о предоставлении займов, а затем “прогнать” имитацию, чтобы оценить пропускную способность или время ответа для сквозного потока. Также, если мы предположим, что есть некоторое, достаточное для выполнения этой задачи, количество агентов по займам в StarLoan и UnitedLoan, и мы зададим некоторое среднее время для обработки прошения о займе, то имитация поможет определить использование ресурсов и число нужных ресурсов на основе ожидаемых запросов на займы.

IV. Документирование и внедрение

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

Следующий после документирования шаг – это внедрение бизнес-процессов. Язык BPEL (Business Process Execution Language) становится очевидным стандартом внедрения для объединения множества синхронных и асинхронных сервисов в коллективные (collaborative) потоки и транзакции. При разработке BPEL воспользовались результатами более чем десяти исследований его предшественников – языков XLANG и WSFL. Он включает следующие концепции:

  • Web Services/WSDL - как компонентная модель
  • XML - как модель данных
  • Шаблоны синхронного и асинхронного обмена сообщениями
  • Детерминированная и недетерминированная координация потока
  • Иерархическое управление исключительными ситуациями
  • Долгоживущая единица работы/компенсации (Long-running unit of work/compensation)
OracleBPEL Designer предоставляет графический и дружественный интерфейс для построения BPEL-процессов. Что выделяет Oracle BPEL Designer – так то, что BPEL – это его “родной” формат. Это означает, что процессы, построенные с применением этого инструмента, 100% переносимы, и, кроме того, он позволяет разработчикам просматривать и модифицировать исходный код на BPEL, не снижая полезности этого инструмента.

Если высокоуровневый процесс смоделирован на BPMN, он прежде всего экспортируется к скелетному (skeletal) BPEL-процессу, который как правило, состоит из областей действия процесса (process scopes), действий по вызову/получению (invoke/receive activities) и партнерских связей к соответствующим сервисам (partner links to the appropriate services).

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

  • Идентифицирование операций web-сервисов, которые вызываются различными сервисами;
  • Специфицирование типов XSD для сообщений, которыми обмениваются различные сущности;
  • Моделирование карты трансформаций для различных типов сообщений, посылаемых и получаемых из различных систем;
  • Специфицирование положения конечных точек (endpoint) и параметров соединения для вовлеченных сервисов.

Если мы рассмотрим пример LoanFlow, описанный ранее,то для кода наBPEL, сгенерированного из средства моделирования BPMN, потребуется включение URL для этих сервисов, XSD для прошения об займе и предложения займа, а также определение трансформаций данных между документами, которые передаются между сервисами. Рис. 3 показывает процесс LoanFlow, смоделированный в Oracle BPEL Designer.

V. Развертывание и исполнение

Наиболее критичным этапом в жизненном цикле процесса является его развертывание на платформе, которая может оркестрировать поток и выполнять различные задачи этого процесса. Оркестрирование набора сервисов в сквозной поток процесса требует выполнения множества технических требований, включая соединение (binding) с разнородными системами, шаблоны для синхронного и асинхронного обмена сообщениями, манипулирование данными, координация в потоке, управление исключительными ситуациями, недетерминированные события, компенсирующие транзакции (compensating transactions), управление версиями, и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. ПродуктOracle BPEL Process Manager обеспечивает наиболее зрелую, масштабируемую и полную реализацию механизма исполнения BPEL, доступную сегодня. Некоторые из ключевых функций этого сервера:
  • Поддержка стандартов — механизм включает непосредственную поддержку стандартов BPEL и web-сервисов;
  • Производительность и масштабируемость – высокопроизводительный BPEL-механизм исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” ("dehydration"), так что состояние долгоживущих потоков автоматически поддерживается в базе данных. Возможно применение кластеров для обеспечения масштабируемости и отказоустойчивости;
  • Продвинутые функции – другие важные функции включают автономную работу с версиями, секционирование процесса и продвинутое управление исключительными ситуациями;
  • Множество платформ развертывания - BPEL Server использует OC4J как базовый J2EE-сервер приложений с поддержкой большинства основных коммерческих серверов приложений;
  • Встроенные сервисы интеграции — они позволяют использовать продвинутые возможности соединений и трансформаций из стандартного BPEL-процесса. Эти возможности включают поддержку для трансформаций и соединений с использованием механизма XSLT/Xquery, а также множества тиражируемых приложений и унаследованных систем . Расширяемая схема соединения WSDL обеспечивает соединения по протоколам и форматам сообщений, другим нежели SOAP. Соединения доступны для JMS, электронной почты, JCA, HTTP и многих других протоколов для связи с сотнями внутренних (back-end) систем.
  • Сервис пользовательской задачи (User task service), предоставляется как встроенный BPEL-сервис для обеспечения интеграции людей и выполняемых ими вручную задач в BPEL-потоки.
  • BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console и Java API.

На рисунке 4 показана архитектура BPEL Process Manager и сопутствующих компонентов.

VI. Мониторинг

Измерение ключевых метрик процессов и “видимость” (visibility) в реальном времени исполнения процессов критичны для оценки производительности развернутых бизнес-процессов. Oracle Business Activity Monitoring (BAM) – это критичный компонент нашего полного BPM-решения.

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

Ключевые концепции Oracle BAM таковы:

  • Бизнес-события (Business Events) – перехват таких интересных событий как изменение информации о клиентах, изменения в описи товаров, заказах на покупку из широкого ряда информационных систем предприятия (EIS).
  • Составные события (Composite events) – определение, агрегирование, соотнесение и фильтрация событий от различных конечных систем.
  • Метрики и ключевые индикаторы эффективности (КПЭ или KPI) – выполнение сложной обработки составных событий для генерации метрик и КАЭ.
  • Сигналы (Alerts) – уведомление пользователей через различные каналы (электронная почта, голосовая почта, пэйджеры,..) на основе превышения пороговых значений и/или порогов рисков для некоторых ключевых метрик.
  • Визуализация в масштабе реального времени - широкий набор средств визуализации в масштабе реального времени на BAM-панели для показа данных самых последних событий и детализации при анализе основных факторов.

См. рисунок 5.

Продолжим наш пример с LoanFlow из Секции II . После того, как процесс развернут, BAM-панель может быть использована, чтобы ответить на критические бизнес-вопросы:

  • (a) Запросы на займы, предоставленные сегодня, на этой неделе, в этом месяце.
  • (b) Предложения займов по агентствам
  • (c) Среднее время обработки одного займа
  • (d) средняя кредитная оценка (скоринг) лиц, желающих получить заем.

Также BAM-панель может отобразить сигналы:

  • (a) были предоставлены займы многим лицам с низкой скоринговой оценкой
  • (b) процент отвергнутых прошений о займах больше 10%.

Последний факт можно использовать для переоценки критериев отбора или для того, чтобы предпринять некоторые предупредительные действия. Рисунок 6 показывает BAM-панель с некоторыми ключевыми метриками для процесса LoanFlow.

VII. Оптимизация и перепроектирование

BAM закрывает отсутствующее звено между исполнением процесса и перепроектированием. Традиционно имитация процессов основана на предположениях и догадках. Проблема такого подхода в том, что надежны только результаты, а предположения делались на этапе моделирования. При применении BAM, как данные реального времени, так и исторические данные, накопленные за период времени, могут быть использованы, чтобы промоделировать процесс “как есть” (“as-is”) и создать оптимальный процесс “как должно быть” ("to-be"). Благодаря таким успешным итерациям процесс может быть тонко настроен, что приведет к значительной экономии ресурсов и средств.

События в BAM также могут быть использованы для оптимизации развернутых процессе в реальном времени, благодаря изменениям потока бизнес-процесса. Сигналы (alerts) BAM также могут начать новые бизнес-процессы для обработки исключительных ситуаций или быть использованы для прерываний процессов.

Еще раз рассмотрим пример LoanFlow. На этапе оптимизации должны использоваться данные реальной обработки на основе ежедневных/ежемесячных отчетов и затем прогоны инструмента имитации для обнаружения возможных узких мест и уровней обслуживания (predict SLA). Это может привести к перепроектированию процесса. Например, к добавлению новых сервисов при оформлении займа, что соответствовать требованиям по времени ответ. Некоторые из этих метрик также могут использоваться в реальном масштабе времени. Например, если какое-то из агентств слишком долго не отвечает, процесс может продолжать работу только с одним предложением займа (применительно к одному агентству), чтобы удовлетворить SLA-требованиям обслуживания.

VIII. Партнеры

Корпорация Oracle установила партнерские отношения с рядом поставщиков, чтобы предоставить средства моделирования и имитации вместе с Oracle BPEL Process Manager и инструментом Oracle Business Activity Monitoring. В число этих поставщиков входят Popkin Systems and Software Ltd ( www.popkin.com ) — продукты Popkin System Architect и Popkin Simulator II могут быть использованы для моделирования и анализа процессов. При этом применяется BPMN и экспорт в формате BPEL для развертывания на платформе Oracle.

За более подробной информацией о моделировании процессов с использованием этих средств, их внедрении и развертывании с Oracle BPEL Process Manager, обращайтесь по адресу http://www.oracle.com/technology/products/integration/index.html

IX. Заключение

BPM-системы полного цикла критичны для разработки эффективных бизнес-процессов, которые должны быстро реагировать на изменяющиеся бизнес-условия. Oracle AS Integration – это в настоящее время наиболее полная BPM-платформа на рынке. Она обеспечивает реализацию всего жизненного цикла процесса, включая моделирование, имитацию, внедрение, исполнение, мониторинг и оптимизацию бизнес-процессов.