Понятие 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 платформы — это целые комплексы программных и методологических средств.
Статья состоит из следующих разделов:
  1. Краткие обзоры внутреннего строения Pega и IBM BPM, а также краткое описание методологий внедрения. Данные обзоры не претендуют на абсолютную полноту описания, а приведены в справочных целях, но, надеюсь, они будут очень полезны для первичного погружения. Для получения более полной информации необходимо обратиться к документации соответствующей платформы.
  2. Основные сравнительные тезисы, сгруппированные в таблицу. Каждая строка таблицы соответствует одному из сравниваемых аспектов или особенностей, а колонки соответствуют реализации данных аспектов в разных платформах: Pega и IBM соответственно.
  3. Уникальные преимущества обеих платформ.


Обзор архитектуры 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 предоставляет единое пространство для сбора и управления требованиями, для разработки и тестирования функциональности и для работы конечного пользователя с бизнес-приложением.
При наилучшем сценарии последовательность действий будет следующей:
  1. Выбрать первый проект, который показывает наилучший баланс между объемом затрат и потенциальным эффектом; в дальнейшем можно будет переходить к остальным проектам;
  2. Создать приложение, дальнейшие шаги выполняются с использованием средств DCO, т.е. непосредственно в системе;
  3. Зафиксировать бизнес-цели и требования;
  4. Внести спецификации, описывающие, как должна работать система, связать их с целями и/или требованиями;
  5. Разбив работу на отдельные участки, по каждому выполнить следующие шаги:
    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 предполагается следующий подход:
  1. Выбрать проект, который показывает наилучший баланс между объемом затрат и потенциальным эффектом;
  2. Описать бизнес-цели в BlueworksLive;
  3. Описать бизнес-процесс в BlueworksLive;
  4. Провести серию встреч с пользователями для прогона процесса, описанного в BlueworksLive (так называемый Playback 0);
  5. Перенести процесс из BlueworksLive в Process Center для начала разработки;
  6. Далее итерационно:
    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-платформ или более подробное описание, пишите, возможно, это станет темой для следующей статьи.

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