BPMS: на пороге зрелости

Сначала были коды, затем ассемблер, потом PL/1, Си, Java и .Net — примерно так, повышая уровень абстракции, шла история взросления средств разработки программного обеспечения. На очередном витке развития инструментария разработчик программного обеспечения оперировал все более высокоуровневыми понятиями, которые все больше приближаются к основному заказчику ПО — бизнесу. Можно предположить, что инструменты будущего скоро позволят бизнесменам самостоятельно составлять программы для поддержки новых услуг, примерно так, как сегодня они без посторонней помощи автоматизируют многие операции в настольных офисных приложениях. Готовы ли к такому повороту событий современные системы управления бизнес-процессами?

Бизнес давно пришел к пониманию, что ежедневная производственная деятельность состоит из процессов и ими нужно системно управлять. Еще в 1993 году Майкл Хаммер и Джеймс Чэмпи опубликовали известную работу на эту тему: Reengineering the Corporation: A Manifesto for Business Revolution, в которой предлагали корпорациям пересмотреть свои практики, начиная с переоценки миссии компании, бизнес-целей и потребностей клиентов для выстраивания процессов таким образом, чтобы эти цели достигались максимально эффективно. Первые попытки применить эту методологию действительно походили на революции, но многим из них не суждено было завершиться победой — идеологи недооценили сложность такой организационной перестройки, не учли естественное стремление рядовых участников процесса сопротивляться изменениям.

Технологическая поддержка была также недостаточна для таких масштабных инициатив, хотя средства моделирования бизнес-процессов получили значительный толчок в своем развитии. Было еще далеко до непосредственно исполняемых моделей, а цикл автоматизации каждого процесса строился по жесткой, традиционной для индустрии разработки ПО схеме: сбор и анализ требований, проектирование, разработка и тестирование, внедрение и эксплуатация и для изменчивых бизнес-процессов не подходил?— требования устаревали еще до того, как пользователи получали возможность познакомиться с первой версией разработанного процесса. Стоимость внесения изменений также была высокой.

Почему лучшие знания и практики индустрии разработки ПО дали сбой? Это легко объяснить, если вспомнить, на чем были сосредоточены основные усилия разработчиков бизнес-приложений вплоть до 90-х годов. В основном мастерство оттачивалось на автоматизации учетных функций, и в программном коде воплощались только бизнес-сущности и их взаимосвязи. Бизнес-процесс оставался за рамками системы, навсегда застывал в требованиях, в диаграммах аналитиков, которые они строили на этапе обследования. Однако, как известно, структуры данных изменяются гораздо реже, чем процессы их обработки,?— форма заказа может не меняться десятилетиями, а вот процесс его обслуживания надо серьезно пересматривать каждые полгода и подстраивать каждые две недели, если компания считает себя лидером.

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

Управление бизнес-процессами (Business Process Management, BPM) и сервисная архитектура (Service-Oriented Architecture, SOA) — плоды современного цикла эволюции, приближающие нас к цели — дать бизнес-специалистам возможность непосредственно автоматизировать свои процессы путем составления моделей, построенных с помощью графических инструментов. Действительно, SOA предполагает непосредственное оперирование бизнес-сервисами, а ИТ-гиганты активно покупают сегодня лучших представителей из мира BPM и бизнес-аналитики?— именно эти технологии больше всего интересуют бизнес.

Наиболее передовые системы управления бизнес-процессами (Business Process Management Suite, BPMS) — Lombardi Teamworks, Pegasystems SmartBPM, Savvion BusinessManager, Oracle BPM Suite, Intalio BPMS — можно освоить за 2-4 дня, однако остается еще много моментов, мешающих объявить, что бизнес больше не нуждается в проектах автоматизации процессов.

Современные BPMS?

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

Моделирование

Функция построения моделей бизнес-процессов с помощью графических инструментов является ключевой для BPM. Модели классифицируются по следующим уровням:

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

Считается, что современные BPMS реализуют 80-90% бизнес-требований путем моделирования на бизнес- и технологическом уровнях, а реализация оставшихся 10-20% функционала требует привлечения программистов. Наилучшие результаты, на мой взгляд, показывают продукты, где все три уровня моделирования реализованы в единой среде, например Lombardi Teamworks. Такой подход дает больше возможностей по автоматическому учету влияния изменений, произведенных на одном уровне, на все остальные. Чтобы не шокировать бизнес-пользователей, ненужные технические возможности скрываются в интерфейсе среды разработки модели.

Очень важно четко разграничивать бизнес-модель и ИТ-реализацию. Иначе бизнес-модель быстро «засоряется» технологическими деталями. Разные BPMS по-разному решают эту задачу. От почти полного игнорирования до полноценной поддержки.

Стоимость изменений остается высокой во всех современных BPMS — необходимо тестировать измененный процесс, а цена этой процедуры прямо зависит от разветвленности автоматизированного процесса, количества точек расширения штатных возможностей платформы и от масштаба внесенных изменений. Серьезно снижают затраты функции, позволяющие проверять работу отдельных частей процесса, не проходя весь процесс с самого начала. Лучшие BPMS сегодня предлагают такие возможности, но с некоторыми ограничениями. Дело в том, что реализованная функция часто зависит от контекста выполнения, например от данных, собранных в ходе процесса, и без таких данных она попросту может не работать, а проверить ее автономно невозможно. Поэтому важно это учитывать еще на этапе проектирования процесса. В идеале функции не должны зависеть от контекста, а если это недостижимо, то нужно, по крайней мере, обеспечить максимально простую организацию данных контекста и позаботиться о механизмах его искусственного формирования.

В качестве стандарта графической нотации для моделирования бизнес-процессов наибольшее распространение получила спецификация BPMN (Business Process Modeling Notation), которую средствами графических дизайнеров сегодня поддерживают многие BPMS, например Intalio BPMS, Lombardi Teamworks и Savvion BusinessManager.

Исполнение

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

• Нестандартное представление бизнес-процесса. Модель процесса сохраняется в нестандартном представлении, а сервис исполнения уникален для конкретной BPMS. В качестве примера такого подхода можно привести EMC Documentum.
• Исполнение XPDL. Стандарт XML Process Definition Language (XPDL) был изначально разработан для передачи описаний моделей бизнес-процессов между разными инструментами моделирования. XPDL 2.0 был расширен для сохранения всех особенностей моделей, разработанных в BPMN. В одном XML-документе сохраняются графические данные модели и информация для исполнения. Несмотря на то что XPDL изначально не задумывался как язык исполнения процессов, сервисы некоторых ведущих BPMS принимают процессы для исполнения именно в этом формате, например Fujitsu Interstage BPM.
• Исполнение BPEL. Стандарт описания процессов в формате XML изначально позиционировался как язык исполнения и не содержит информации о графическом представлении модели. Основная задача BPEL — координация автоматического взаимодействия информационных систем. Для подключения людей к участию в процессах было разработано расширение стандарта — BPEL4People. Сервис исполнения этого типа реализует BPM-платформа Intalio.

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

Оптимизация

Еще три-четыре года назад далеко не каждая программная платформа BPM включала инструменты имитационного моделирования, но сегодня все ведущие поставщики добавили эту возможность в состав своих продуктов. Основное назначение инструментов имитационного моделирования — оценка степени влияния изменений в процессе еще до момента реализации этих изменений на практике. Аналитик имеет возможность проиграть различные сценарии на модели процесса «как есть» и получить значения метрик продолжительности, стоимости, длительности ожидания для очередей работ или максимальной длины этих очередей. Затем можно внести в схему процесса планируемые изменения и повторить имитационный эксперимент. Часто попытки улучшить процесс связаны с поиском компромисса между конфликтующими требованиями. Например, добавив дополнительный персонал в пул ресурсов обработки очереди задач, уменьшается время ожидания и длина очереди в моменты пиковых нагрузок, но при этом увеличиваются затраты и простои сотрудников в периоды уменьшения нагрузки.

Само по себе ремесло оптимизации процессов остается очень непростым, независимо от применяемых инструментов. Инструментарий открывает глаза, но не заменяет опыт. Построение полезной имитационной модели требует больших усилий по определению множества параметров, из которых не все могут быть с достаточной точностью оценены без дополнительных исследований и измерений. Например, как часто процесс будет проходить по одному маршруту по сравнению с альтернативным в точке разветвления последовательности работ. Дело значительно облегчается, если изменения вносятся в уже автоматизированный и эксплуатируемый процесс — можно использовать данные, накопленные в ходе исполнения экземпляров такого процесса.

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

Перед BPMS стоит нелегкая задача — с одной стороны, полноценное средство имитационного моделирования должно обладать огромным количеством настроек, чтобы построенная модель была адекватна во всем многообразии ситуаций, а с другой, целевая аудитория BPMS — бизнес-аналитики, и сложный, наукообразный инструмент здесь не приживется.

Управление документами

Сегодня системы управления контентом ECM предлагают очень средние или слабые функции BPM. Обратная ситуация еще хуже — лучшие BPMS имеют лишь зачатки функций управления документами. Ситуацию призвана спасти интеграция BPMS и ECM, однако высока цена такого решения. Позволить себе комбинацию лучших BPMS- и ECM-платформ сегодня могут очень не многие компании, поэтому остается надеяться, что в результате произошедших на рынке поглощений мы скоро увидим комбинированный продукт с приемлемой ценой. Возможно, раньше других такую новость стоит ожидать от компании Oracle, которая в 2006 году поглотила Stellent UCM, а спустя год приобрела одну из лидирующих платформ BPM — AquaLogic BPM в составе продуктов поглощенной BEA.

Прекрасным дополнением к дорогой BPMS может послужить ECM с открытым исходным кодом. Прикладные бизнес-платформы с открытым исходным кодом за последние годы получили существенное развитие, и к ним следует серьезно присмотреться, например стоит обратить внимание на систему Alfresco.

Бизнес-правила

Ведущие поставщики систем управления бизнес-правилами (Business Rule Management Systems, BRMS), такие как Corticon, ILog, Yasu и Fair Isaac, давно и успешно развивают свои системы параллельно с поставщиками BPMS, и сейчас оба рынка сближаются. Бизнес-правила оказались очень удачной концепцией для упрощения логики бизнес-процессов и привлечения бизнес-пользователей к управлению этой логикой. Например, бизнес-процесс согласования закупок должен автоматически определять состав и порядок согласующих в зависимости от суммы, назначения и других параметров закупки. Эта логика может быть непосредственно реализована в шаблоне бизнес-процесса. Но тогда любые изменения в ней потребуют привлечения специалиста по процессу для подготовки и развертывания новой версии целого процесса. Это очевидная, но не единственная проблема. Правило может быть частью более широкой закупочной политики организации, и изменения должны проводиться не на уровне одного правила, а на уровне всей политики, которая может состоять из множества правил, требующих согласованных изменений. BRMS позволяет решать подобные проблемы. Правила разрабатываются и исполняются в системе управления правилами, в бизнес-процесс встраивается только вызов сервиса исполнения правил.

Лозунг, продвигаемый в BRMS, очень похож на идею, лежащую в основе BPM, — каждая «кухарка» может управлять бизнес-правилами. Но платформы бизнес-правил преуспели в реализации этой концепции лучше, чем системы BPM. Наиболее дружественная бизнесу форма определения правил?— таблица решений в Excel, не требующая адаптации от бизнес-пользователей и не вызывающая опасений у ИТ-специалистов в том, что неудачно разработанное правило «обрушит» всю систему.

Кроме таблиц решений, наиболее развитые BRMS, например Ilog и JBoss Rules, предлагают и другие инструменты, позволяющие задавать более сложные правила, не вписывающиеся в простую иерархию вопросов и ответов: определение правил через серию диалоговых окон (wizard); язык правил, подобный естественному языку; графические редакторы правил; алгоритм принятия решения; специальный декларативный язык правил.

Большинство разработчиков BPMS включают подобные возможности в свои системы, но лишь немногие, например компания Pegasystems, развивают собственные полнофункциональные подсистемы управления правилами, предназначенные для управления полным жизненным циклом правил и построения репозитория правил корпоративного уровня. Для подключения правил корпоративного уровня все производители BPMS предлагают интегрировать лучшие платформы бизнес-правил с помощью механизмов SOA.

Мониторинг и анализ

Одна из наиболее привлекательных идей BPM?— измеряемые и наблюдаемые, а значит, управляемые процессы. Технология мониторинга процессов в реальном времени (Business Activity Monitoring, BAM) позволяет своевременно и адекватно реагировать на отклонения от штатного режима, а инструменты бизнес-анализа позволяют организовать учет исторических данных, накопленных в ходе выполнения многих экземпляров процессов. Подсистема BAM выполняет следующие функции:

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

Большинство современных подсистем BAM, например EMC Documentum и Lombardi, позволяют бизнес-пользователям без программирования выполнять базовые функции. Привлечение технических специалистов требуется для идентификации сложных событий и прогнозирования событий, а также в случаях, когда необходимо определить сложную или нестандартную реакцию.

Поддержка групповой работы

К сожалению, аналитики, иногда чересчур прямолинейно, позиционируют BPM-технологии как инструмент, позволяющий бизнес-пользователям обрести полную свободу от ИТ-отдела, специалисты которого в ответ приводят массу аргументов против жизнеспособности BPM. Часто, например, приходится слышать: «Полтора программиста автоматизируют любой бизнес-процесс за две недели на бейсике… и быстренько поменяют его, если понадобится». Интегратору в такой ситуации нередко приходится выступать в роли арбитра.

Потенциал современных BPMS можно раскрыть только путем слаженной работы аналитиков и ИТ-специалистов, но сегодня нет универсальных рецептов, подобных подходам, давно выработанным для традиционного цикла разработки ПО. Наилучший сценарий взаимодействия приходится подбирать для каждого заказчика и каждой BPMS.

Сам по себе workflow-подход не лишен недостатков — имеется много действий которые не могут быть описаны строгой последовательностью заданных работ. Возьмем, к примеру, обработку заказа на доставку груза. Эту задачу можно описать в виде стабильной последовательности шагов лишь на самом верхнем уровне, и попытки ввести подобную простую формализацию на более детальном уровне потерпят неудачу либо дадут жизнь процессам-монстрам, состоящим из сотен автоматизированных этапов. Офисный работник, координирующий сложную мультимодальную доставку, в рамках одного этапа совершает массу действий, не связанных строгой последовательностью, а инициируемых внешними событиями или управляемых на основе экспертного опыта. При этом отдельные задачи в рамках этапа сами по себе представляют сложные процессы. Общая картина, которая складывается в результате, может быть описана сложным множеством взаимосвязанных данных и процессов. Часто такие взаимосвязи складываются в иерархии.

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

Аналогичная ситуации наблюдается с тем, что в России называют делопроизводством и организационно-распорядительным документооборотом. Здесь тоже можно выделить следующие процессы: подготовка, регистрация и исполнение документов, однако эти процессы не поддаются строгому описанию. Основная причина в том, что этот документооборот на самом деле занимается управлением огромным количеством самых разнообразных процессов, не выделяя и не регламентируя каждый из них в отдельности — отдельно автоматизируются лишь некоторые, самые важные для бизнеса, последовательности операций. Например, поступление входящего документа-заявления на получение страхового возмещения инициирует процесс обработки страховых случаев. Таких процессов может быть несколько?— по видам страхования. А что происходит со всеми остальными 100 или 1000 типами входящих документов, которые регулярно получает страховая компания? Ими занимается делопроизводство.

Подобные задачи находятся в поле зрения разработчиков BPMS, предлагающих собственные решения. Сегодня в разных системах встречаются следующие функции управления слабодетерминированными процессами:

• спонтанный (ad-hoc) запуск подпроцессов в любой точке основного детерминированного процесса;
• визуализация взаимосвязанных процессов в виде диаграммы Ганта;
• автоматическое создание рабочей группы (collaboration group) на корпоративном портале, публикация туда необходимой информации, приглашение участников и возврат результатов в процесс по завершении работы группы.

Функционально полного решения на сегодня нет ни у одного из производителей?— сегодня происходит поиск системного подхода путем применения разных технологий организации и визуализации сложно взаимосвязанных данных и процессов (порталы, коллажи (mashups)), управление сложными событиями (Complex Event Processing, CEP), социальные сети.

Интеграция приложений

Здесь требуется участие технических специалистов и программистов, однако для простых сценариев интеграции уже предлагаются достаточно развитые инструменты, позволяющие бизнес-аналитикам или технологам подключать сервисы внешних систем к процессу или использовать данные из внешних баз данных. Настройка подключения сводится к заданию правил отображения данных, поступающих из внешней системы, на переменные процесса с помощью графического интерфейса (data mapper). Часто производители BPMS предусматривают возможность отобразить в форме задачи процесса часть Web-интерфейса другой системы, но реальные сценарии интеграции редко ограничиваются столь примитивными задачами, поэтому в видимой перспективе технические специалисты останутся востребованными.

Репозиторий процессов и сервисов

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

Управление и администрирование

BPMS представляет собой сложный программно-аппаратный комплекс, и задачи по его сопровождению остаются в поле ответственности ИТ-отдела. Для автоматизации задач мониторинга и управления применяются как встроенные в BPMS средства, так и внешние, например IBM Tivoli, HP OpenView, Hyperic HQ, специально предназначенные для решения таких задач платформы.

Продолжение будет?

Знакомство с современными BPMS позволяет сделать вывод, что лучшие производители успешно следуют главной цели BPM — создания инструмента именно для бизнеса, а не еще одной технологической платформы для ИТ-специалистов. Достигается это добавлением в BPMS все большего количества функций, позволяющих решать многообразные задачи автоматизации процессов без программирования на процедурных языках. Такой прямолинейный подход ведет к тому, что инструмент становится слишком сложным для среднего пользователя и напоминает ситуацию с офисными пакетами, большинство возможностей которых не востребовано. Решение проблемы, наверное, возможно через встречное движение всех игроков рынка, более тщательно структурирующих многообразные средства своих продуктов по функциональным ролям, и пользователей, постепенно «переваривающих» новые концепции бурно развивающегося BPM.

В заключение хотелось коротко упомянуть о программных платформах с открытым кодом. Во-первых, бизнес-приложения, разрабатываемые по модели Open Source, уже достигли необходимого уровня зрелости, чтобы начать конкурировать с коммерческими аналогами. Во-вторых, экономическая ситуация, которую мы все сегодня переживаем, заставляет искать альтернативы дорогим решениям. Однако сегодня имеется лишь один продукт такого класса?— полнофункциональная BPM-платформа Intalio, включающая в себя все основные компоненты: дизайнер BPMN, сервис исполнения моделей процессов, BRE, BAM, ECM.

Помимо собственно задачи автоматизации бизнес-процессов, BPM охватывает большинство современных технологий: CEP, EDA, EAI, SOA, BI, Web 2.0, ECM… Ориентация на бизнес-пользователей дает BPM шанс стать лидирующей системной основой, объединяющей если не все, то многие другие технологии под простой и понятной бизнесу идеей.

Сергей Плаунов (SPlaunov@croc.ru) — руководитель проектов компании «Крок» (Москва).