Сравнение ведущих BPM-платформ: Pega и IBM BPM

Источник: habrahabr

Понятие BPM (Business Process Management) все более плотно входит в жизнь больших и малых корпораций. Суть его в том, чтобы рассматривать бизнес-процессы компании, как активы, используя которые можно увеличить прибыльность своего бизнеса. Инструмент, который вы для этого используете, может быть любым: лист бумаги, текстовый документ, Visio или любое другое средство создания диаграмм… Но есть класс инструментов, которые специально предназначены для того, чтобы послужить инструментом для трансформации вашего бизнеса - это BPM-платформы.
Задача для такой платформы ставится двояко: с одной стороны необходимо визуализировать бизнес-процесс, а с другой стороны - его нужно исполнить.

Я не буду описывать весь рынок таких платформ, это неплохо сделано в статье независимого агентства Gartner, откуда я взял иллюстрацию выше (полный текст можно скачать с сайта Pega или IBM, но потребуется регистрация, или нагуглить самостоятельно по заголовку: "Gartner BPM Magic Quadrant 2014").
Цель же данной статьи - провести сравнение технических возможностей двух лидирующих платформ, Pega и IBM BPM, доступных на текущий момент (осень 2014), с точки зрения опыта их использования в проектах по автоматизации бизнес-процессов .

Если вы задумали трансформировать свой бизнес или вам нужно IT-решение, которое позволит достичь бизнес-целей, поставленных высшим руководством, или вы просто интересуетесь BPM-решениями, то добро пожаловать под кат.

Принципы сравнения

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

Краткие обзоры внутреннего строения Pega и IBM BPM, а также краткое описание методологий внедрения. Данные обзоры не претендуют на абсолютную полноту описания, а приведены в справочных целях, но, надеюсь, они будут очень полезны для первичного погружения. Для получения более полной информации необходимо обратиться к документации соответствующей платформы.
Основные сравнительные тезисы, сгруппированные в таблицу. Каждая строка таблицы соответствует одному из сравниваемых аспектов или особенностей, а колонки соответствуют реализации данных аспектов в разных платформах: Pega и IBM соответственно.
Уникальные преимущества обеих платформ.

Обзор архитектуры Pega

Ядро Pega представляет собой java enterprise приложение, запускаемое на любом application сервере. На базе этого ядра построен стек классов, составляющих базовый Framework PRPC, включая непосредственно сам портал разработчика, доступный через браузер (т.к. этот портал используется и внутренней командой разработки, то можно сказать, что Pega разработана на Pega).
Для понимания того, как работает Pega, необходимо определить два базовых понятия: класс и правило:

Класс - это стандартная единица для объектно-ориентированной парадигмы, представляющая собой структуру, содержащую некоторые связанные данные и методы для их обработки.
Правило - это экземпляр одного из специальных встроенных (т.е. определенных в одном из фреймворков) классов, назначаемый или присваиваемый другим классам. Правила можно рассматривать как реализацию паттерна Стратегия (также иногда упоминается как Behavior; полное описание паттерна есть на вики): правило, принадлежащее классу, определяет его свойство (property), поведение (flow, flow action), способ отображения данных (section) и многое другое.

Любое Pega-приложение состоит из набора классов, определяющих либо структуру данных (тогда они хранятся в ветке Data-), либо структуру работ или кейсов (в ветке Work-). Каждый из этих классов может наследовать свойства и методы (определяемые правилами) от классов, определенных во фреймворках, либо от других классов приложения. Любой класс может переопределить правило, заданное в базовом классе.
Pega имеет множество разнообразных фреймворков, на основе которых может строиться конечное приложение с использованием наследования, для примера приведу только некоторые из них:

PRPC сам по себе является фреймворком;
DSM - для построения систем принятия решений;
CPM - для построения систем взаимодействия с клиентами;
Различные индустриальные пакеты: финансовые, страховые, энергетические и другие.

Pega, подход

Основа подхода базируется на трех вещах:

Situational Layer Cake (Слоистая архитектура): за счет наследования и полиморфизма, реализованных в виде Rule Resolution Mechanism, Pega позволяет добиться того, чтобы бизнес-процесс для конкретного клиента изменялся в зависимости от самых разнообразных условий, например, как от уровня лояльности данного клиента, так и от регионального законодательства обслуживающего офиса.
6R - это концепция построения комплексного решения, которое обеспечивает получение (Receiving) и назначение (Routing) задач, отчетность (Reporting), реагирование (Responding), сбор информации (Researching), принятие решения и разрешение (Resolving) кейсов.
DCO (Direct Capture of Objectives) - это методология и набор поддерживающих ее средств, направленные на то, чтобы в рамках проекта разрабатывалось только то, что реально нужно бизнесу.

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

Выбрать первый проект, который показывает наилучший баланс между объемом затрат и потенциальным эффектом; в дальнейшем можно будет переходить к остальным проектам;
Создать приложение, дальнейшие шаги выполняются с использованием средств DCO, т.е. непосредственно в системе;
Зафиксировать бизнес-цели и требования;
Внести спецификации, описывающие, как должна работать система, связать их с целями и/или требованиями;
Разбив работу на отдельные участки, по каждому выполнить следующие шаги:
1. Провести DCO-сессию с пользователями, чтобы верифицировать единое понимание спецификаций (обращаю внимание, что DCO-сессии служат для верификации спецификаций перед непосредственным началом их разработки, а не для первичного сбора требований);
2. Реализовать функциональность по данным спецификациям;
3. Показать пользователям результат.

В подходе Pega есть ложка дегтя: для использования всех средств DCO необходимо создать приложение, чтобы в нем можно было определять бизнес-цели, фиксировать требования и прописывать спецификации. Однако, при создании приложения через AppExpress необходимо указать такие данные, как цели, набор кейсов и бизнес-объектов, а также выбрать базовый фреймворк и необходимую структуру слоев приложения, что подразумевает, что часть работы по сбору требований уже должна была быть проведена.

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

Обзор архитектуры IBM

Стек платформ IBM представляют собой java enterprise приложения, запускаемые на сервере websphere application server.
IBM BPM имеет следующие элементы:

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

IBM BPM состоит из следующих частей:

Репозиторий процессов - хранит всю информацию о процессах, сервисах, структурах данных и т.п.;
Process server - исполняющий компонент, обеспечивающий работу бизнес-процессов;
Process center - компонент, обеспечивающий доступ к репозиторию процессов для разработки;
Process designer - среда разработки, основанная на eclipse;
Портал - среда работы конечных пользователей (может не использоваться);
Process data warehouse - хранилище статистической информации о прохождении экземпляров процессов;
Blueworks Live - облачный сервис по моделированию и документированию бизнес-процессов. Построенная модель может быть импортирована в process designer, но на практике эта возможность используется редко.

IBM BPM имеет следующие уровни лицензий:

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

IBM имеет различные сопряженные продукты, для примера приведу некоторые из них:

ODM - платформа для бизнес-правил;
Case manager - платформа для создания и организации набора кейсов;
Integration bus - интеграционная шина.

IBM, подход

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

Выбрать проект, который показывает наилучший баланс между объемом затрат и потенциальным эффектом;
Описать бизнес-цели в BlueworksLive;
Описать бизнес-процесс в BlueworksLive;
Провести серию встреч с пользователями для прогона процесса, описанного в BlueworksLive (так называемый Playback 0);
Перенести процесс из BlueworksLive в Process Center для начала разработки;
Далее итерационно:
1. Разработать часть бизнес-процесса;
2. Показать результаты пользователям (Playback 1..N).

Сравнительные тезисы

В таблице ниже приведено сравнение различных особенностей платформ Pega и IBM.

PEGA	IBM
Управление требованиями и проектом
Pega предоставляет интрументы DCO для управления бизнес-целями, требованиями (ЧТО приложение должно делать) и спецификациями (КАК приложение должно работать) с возможностью указания связей между ними. Также со спецификациями можно связать результаты разработки, чтобы отслеживать прогресс проекта.	В IBM есть возможность ввода целей в BlueworksLive, ввода описаний шагов бизнес-процессов (аналог спецификации в Pega) в BlueworksLive, но нет возможности ввести общие требования, связать цели со спецификациями или с реализацией.
Различия в позиционировании
Pega это единый инструмент для автоматизации кейсов, процессов и/или бизнес-правил. Для автоматизации интеграции рекомендуется использовать внешнюю шину данных.	IBM BPM это единый инструмент для автоматизации процессов и интеграции. Для кейсов и бизнес-правил в стеке IBM есть отдельные продукты.
Pega имеет возможность делегирования отдельных правил бизнес-пользователям в то время, пока над остальными работают программисты.	IBM BPM не имеет возможности отделять часть правил и/или бизнес-процесса, чтобы их могли изменять пользователи во время "боевой" эксплуатации, но подобный инструмент есть в IBM ODM: там есть возможность предоставлять доступ на изменение отдельных бизнес-правил разным группам людей.
Архитектурные различия
Pega имеет объектно-ориентированную архитектуру. В ней возможно и рекомендуется инкапсулировать в одном классе объект данных, логику обработки этих данных и интерфейсы для ввода и вывода.	IBM имеет сервисно-ориентированную архитектуру (SOA). В нем невозможно инкапсулировать в одной единице объект данных, логику обработки этих данных и интерфейсы для ввода и вывода.
В Pega экземпляр кейса имеет единую область данных, доступную в т.ч. для всех его шагов, подпроцессов и секций экранных форм. Отдельную область данных имеют под-кейсы: настройка маппинга входных данных для них похожа на аналогичную в IBM, а выходные данные агрегируются через отдельный специальный механизм.	В IBM BPM каждый экземпляр процесса или сервиса ограничен своей областью данных. Для передачи данных от одного процесса к другому (например, при открытии экранной формы с данными процесса) необходимо явно указывать входные и выходные переменные и осуществлять их маппинг при каждом вызове.
Pega предоставляет возможность переиспользования любого созданного правила в другом приложении благодаря механизму Ruleset-ов. Сложность переиспользования дополнительных непредусмотренных изначально компонент: низкая.	В IBM BPM переиспользование отдельных компонент в другом приложении возможно только путем выделения их в специальные toolkit-ы, что может потребовать рефакторинга уже созданных и работающих приложений. Сложность переиспользования дополнительных непредусмотренных изначально компонент: высокая.
Использование техник и механизмов
Pega имеет небольшой набор возможностей кастомизироваться хард-кодом, но обладает очень широким набором стандартных компонент.	IBM BPM обладает существенно меньшим набором стандартных компонент, но позволяет легко разработать собственные на языках JavaScript и/или Java.
В Pega есть встроенный механизм адаптации интерфейса под мобильные устройства.	У IBM BPM из коробки пока нет механизма адаптации под мобильные интерфейсы, но есть дополнительная подключаемая библиотека (toolkit), позволяющая этого достичь.
Контролы и события в Pega позволяют реализовать AJAX отправку и обновление данных автоматически, путем выбора соответствующих опций в дизайнере.	В IBM обновление данных без перезагрузки формы реализуется по отдельности: есть специальные типы сервисов, поддерживающие AJAX-вызовы, а у контролов есть возможность обработки Javascript-событий. Однако, связь событий и сервисов, маппинг данных и обработка результатов выполняется вручную программистом.
Для работы с данными внешних систем используются DataPage, предназначенные для отделения слоя интеграции от слоя данных и слоя бизнес-логики. При использовании данных внешней системы, например, на экранной форме, в общем случае, не нужно беспокоиться о том, как и когда эти данные были получены.	Для операций с данными внешних систем используются специальные типы сервисов. Отделение слоя интеграции от слоя бизнес-логики поддерживается вручную программистами (например, внутренними правилами и рекомендациями по разработке). Для использования данных внешних систем, необходимо либо получить их в качестве входной переменной, либо непосредственно вызывать интеграционные сервисы.
Пользовательские функции
В стандартном портале есть социальные функции: обмен сообщениями, информация об участниках процесса. Возможно использование при любых вариантах вызова процесса.	В стандартном портале есть социальные функции: обмен сообщениями, информация об участниках процесса, помощь экспертов. Возможно использование только при использовании стандартного портала.
Все почтовые оповещения (о новой задаче, о просрочке и т.п.) настраиваются по отдельности для каждой задачи.	Стандартные оповещения в IBM BPM включаются сразу на всё приложение и автоматически оповещают пользователей о всех новых задачах. Однако, оповещения также приходят в случае, если пользователь сам запустил какой-то дополнительный сервис. В связи с этим, в комплексных проектах используются редко.
Стандартных отчетов в Pega больше, чем в IBM BPM, и они дают более полное представление о прохождении процесса. Все дополнительные отчеты реализуются на той же технологии, что и стандартные и размещаются в едином пространстве интерфейса.	Все дополнительные отчеты реализуются на той же технологии, что и стандартные. Также есть несколько особых отчетов в среде разработки, которые используются для анализа эффективности процесса и прогнозирования результатов любых изменений. Инструмент очень мощный, но требует настроенного сервера разработки и установленной среды разработки. В связи с этим, используется крайне редко.
Порог вхождения для начала работы в Pega Developer Portal: Бизнес-экспертам проще, т.к. на базовом уровне для этого не требуется навыков программирования. Программисту сложнее, т.к. требуется более комплексное понимание архитектуры и удержание в памяти большего числа аспектов.	Порог вхождения для начала работы в IBM BPM Process Designer: Бизнес-экспертам сложнее, т.к. среда предназначена для программирования. Программисту проще, т.к. для базового уровня достаточно знания небольшого числа специфических элементов.

Уникальные преимущества

В данном разделе описаны особые преимущества платформ, не имеющие аналога в другой платформе.
Уникальные преимущества Pega:

Декларативные правила - это правила, задающие определенные характеристики приложения (например, формулу расчета бизнес-данных), которые должны выполняться на любой момент времени. PRPC самостоятельно обеспечивает вызов и исполнение этих правил.
_{Например, правила declare expression, задающие формулу для вычисления значения переменной. Исполнение этой формулы обеспечивается движком одним из двух вариантов:

Пересчитывать результат при каждом изменении любой переменной, входящей в формулу;
Пересчитывать результат при каждом чтении значения рассчитываемой переменной.}
Средства dco: оценка трудоемкости проекта; создание различных срезов документации; взаимосвязи между целями, требованиями и спецификациями.

Уникальные преимущества IBM BPM:

Наглядность единого сквозного процесса в BPMN 2.0 (если такой процесс возможно построить).
Возможности по анализу и прогнозированию результатов изменения процесса.
_{Например, можно увидеть, как часто экземпляры бизнес-процесса двигались по той или иной ветке, посчитать суммарные операционные затраты. Потом сделать изменение в бизнес-процессе и посмотреть на прогнозные изменения в операционных затратах и других KPI.}

Вместо заключения

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

Знать свою платформу: очень часто в реальных проектах на платформах реализуется то, что и так есть, но чуть-чуть по-другому (другой пользовательский портал, своя система уведомлений и т.п.).
Еще раз - знать свою платформу: не менее часто в реальных проектах на таких платформах пытаются реализовать что-то, для чего они не предназначены (популярный вариант - всякие учетные системы).
Ставить бизнес-цели: если проект затевается для того, чтобы "потратить бюджет", то вряд ли он будет успешным, какая бы хорошая платформа ни была выбрана. В противовес этому, если проект разрабатывается с пониманием, что его внедрение позволит компании сэкономить N миллионов рублей ежемесячно, тогда у нужных людей появляется стимул принимать нужные решения в нужное время.
Вовлекать бизнес-пользователей в процесс разработки: еще одна частая проблема в том, что в больших проектах расстояние от бизнес-заказчика до программиста измеряется парой десятков руководителей, аналитиков с двух-трех сторон, архитекторов, прочих сочувствующих и мегабайтами документов. В результате просто реализуется не то, что нужно.

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