И одно только слово твердит Айболит - BPM, BPM, BPM

Business Process Management: от идеи к практической реализации

"Начинайте немедленно. Вопрос не в том, будет ли ваша компания использовать технологию BPM, а в том, когда она сумеет сделать это", - заявил недавно аналитик из фирмы AMR Research Эрик Астволд. От обилия трехбуквенных аббревиатур у ИТ-специалистов уже рябит в глазах, и ажиотаж вокруг еще одной (именующей технологию управления бизнес-процессами - Business Process Management), казалось бы, не должен разжигаться серьезными людьми без особых причин. Однако и посетивший в этом году нашу страну глава компании SAP AG Хенинг Кагерманн настаивал в своем выступлении, что именно развитие платформ развертывания бизнес-процессов определит будущее всей отрасли систем корпоративного управления. В чем же причина столь пристального внимания к BPM?

Понятие бизнес-процесса возникло, пожалуй, вместе с современным промышленным способом производства. Процессный подход к управлению предприятием, получивший широкое распространение в последние годы, на интуитивном уровне для любого менеджера гораздо ближе и естественнее функционального, лежащего в основе большинства учетно-управленческих систем. Ведь если рассматривать с позиций такой системы любую организацию, то следует сделать вывод, что она занимается чем угодно: бухгалтерским учетом, закупками комплектующих, управляет складским хозяйством, принимает и увольняет сотрудников, а вовсе не выпускает самолеты, продает продовольственные товары или кредитует население. Конечно, все функциональные подразделения на предприятии присутствуют и выполняют свою работу, но делают они ее в рамках тех или иных бизнес-процессов. Иными словами, по мере выполнения бизнес-процесса в соответствии с его логикой нужные функции или услуги поручаются соответствующему функциональному подразделению или передаются автоматизирующей его работу информационной системе. Многолетние исследования показали справедливость для бизнес-процессов правила 80/20. Оказалось, что 80% затраченного времени приходится на ожидание завершения тех или иных этапов и лишь 20% - непосредственно на выполнение предусмотренных в них заданий. Отсюда следует, что если для повышения эффективности бизнес-процессов попытаться, к примеру, удвоить скорость выполнения отдельных заданий, то суммарный выигрыш составит всего 10%. Вывод очевиден - нужно оптимизировать бизнес-процессы в целом.

А так ли все просто?

Как правило, ИС реального современного предприятия представляет собой причудливую смесь разнородных программных и аппаратных средств. Поэтому упомянутая выше простая схема поочередной выдачи бизнес-процессом заданий множеству прикладных систем превращается в задачу, выполнение которой настолько трудоемко, что нередко из-за этого хоронится и само воплощение идеи автоматизированного процессного управления. С точки зрения ИС каждый бизнес-процесс это некое суперприложение, построенное на основе отдельных функций не знающих ничего друг о друге прикладных систем. Следовательно, такое суперприложение должно уметь не только инициировать нужные функции отдельных прикладных программ, но и координировать их работу в соответствии с логикой бизнес-процесса. Не случайно появились стандарты, содержащие метафорические, но тем не менее весьма строго определенные понятия "хореографии" и "оркестровки". В рамках завоевывающей все большую популярность сервисно-ориентированной архитектуры (SOA) роль таких "готовых к употреблению" функций разнородных приложений выполняют Web-сервисы. К сожалению, сегодня далеко не все учетно-управленческие системы построены в этой архитектуре, но движение в направлении SOA провозгласили уже многие вендоры, в том числе и лидеры отрасли SAP и Oracle.

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

Глубокие корни

Направление BPM возникло в результате конвергенции четырех сегментов рынка корпоративных систем:

  - Workflow Automation - автоматизация процессов, выполняемых людьми;

 - Enterprise Application Integration (EAI) - интеграция приложений и информационный обмен между гетерогенными системами;

 - Business Process Modeling and Analysis - моделирование и анализ бизнес-процессов;

  - Business Activity Monitoring (BAM) - мониторинг и анализ эффективности работы предприятия в целом и выполняемых им операций.

Большая часть поставщиков BPM-систем в прошлом занималась автоматизацией потоков работ (workflow), но впоследствии к ним примкнули поставщики продуктов EAI, а в самое последнее время и лидеры рынка ERP. Нередко наиболее успешные разработчики систем workflow и BPM приобретаются более крупными игроками. Свежие примеры - покупка фирмы Staffware одним из ведущих игроков сегмента EAI компанией Tibco и поглощение Collaxa корпорацией Oracle.

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

Сначала опишем

Средства проектирования присутствуют на рынке достаточно давно: одно из наиболее известных в нашей стране - ARIS Toolset немецкой компании IDS Sheer. Они позволяют визуально проектировать в графической среде специальные блок-схемы, описывающие структуру и логику бизнес-процессов (см. рис. 1). С их помощью можно также верифицировать построенные модели и выявлять в них логические противоречия, тупиковые или избыточные ветви. Кроме того, они дают возможность строго документировать бизнес-процессы, архивировать их, переносить на другие близкие по тем или иным параметрам предприятия. Основная претензия к подобным инструментам со стороны пользователей сводилась к тому, что построенные модели предназначались не для компьютеров, а для людей. Для реализации спроектированного бизнес-процесса в информационной системе нужно было привлекать разработчиков, умеющих писать новые программные модули или настраивать существующие с учетом логики построенной модели, а также обеспечивать в случае необходимости интеграцию разнородных приложений.

Рис. 1. Проще всего проектировать бизнес-процесс в визуальной среде

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

Оригинальное решение данной проблемы в своей технологии Adaptive Discovery предлагает фирма Ultimus (www.ultimus.com). В ее основе лежит концепция итерационной модернизации модели бизнес-процесса, осуществляемой уже на этапе эксплуатации. После того как основные контуры процесса зафиксированы в модели (к примеру, описано 70% его логики), он утверждается и передается на исполнение. Если же складывается ситуация, не описанная в такой "черновой" модели, и процесс "не знает", кому следует передать выполнение очередного задания, включаются средства автоматического оповещения, пересылающие сообщение эксперту или их группе, а те доопределяют процесс таким образом, чтобы его выполнение было продолжено.

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

Потом исполним

Большой прогресс был достигнут с появлением "движков" (engine), способных исполнять бизнес-процессы, описанные с помощью средств моделирования. По сути это интерпретаторы языков моделирования, а точнее, их подмножества (так называемых языков исполняемых бизнес-процессов), которые функционируют на том или ином сервере приложений. Наиболее популярным из них сегодня является язык BPEL (более подробно о Business Process Execution Language рассказано в статье Юрия Волкова, см. с. 42). Такой движок не выполняет заданий, входящих в состав бизнес-процесса, сам он лишь следит за логикой маршрутизации заданий и в зависимости от соблюдения в точках ветвления заранее заданных условий передает эти задания на исполнение компьютерной программе или человеку.

Совокупность подобных условий иногда не совсем корректно называют бизнес-правилами. На самом деле бизнес-правила имеют более широкий смысл. Чаще всего они поддерживаются специальным модулем, работающим отдельно от BPM-системы, и формулируются на языке, близком к естественному. Модуль мониторинга бизнес-правил следит за их выполнением не в какой-то отдельной точке ветвления, а в рамках процесса в целом или даже совокупности процессов. Такие правила могут описывать, к примеру, исключительные ситуации, требующие вмешательства человека. Поскольку они не отражаются в BPEL-описаниях, требующих строгого соблюдения синтаксиса, сформулировать их по силам менеджерам функциональных подразделений, а не только сотрудникам ИТ-департамента. Важно и то, что бизнес-правила могут иметь сложную взаимосвязанную структуру и способны использовать информацию, недоступную "движку" бизнес-процессов. Так, если правило гласит: "Заказы Золотых клиентов объемом свыше 5 тыс. долл. получают специальную поддержку", то интерпретатор бизнес-процесса сразу же выявит ситуацию с превышением цены, но ему не будет известно, что такое Золотой клиент. А монитор бизнес-правил легко найдет правило, описывающее Золотого клиента, и проверит всю сложную языковую конструкцию в целом.

Понятно, что для автоматизированного исполнения сложных гетерогенных бизнес-процессов "движок" должен использовать внешние средства непосредственной интеграции приложений или интеграции, осуществляемой с участием человека (к примеру, считывающего данные из распечатки отчета одной программы и вводящего их в экранную форму другого). Наиболее естественно такая интеграция реализуется в архитектуре SOA, где "движок" просто вызывает нужные ему Web-сервисы или посылает сообщения вполне определенным сотрудникам с предложением выполнить задание, которое по тем или иным причинам нельзя автоматизировать. Подобные задания в BPM называют неструктурированными: они в отличие от структурированных не описываются фиксированным набором инструкций и жестких логических правил. В частности, принимая решение о выдаче клиенту кредита, банковский служащий может руководствоваться не только сведениями из его кредитной истории, но и личными впечатлениями. Поскольку до полной победы SOA еще очень далеко, все BPM-системы поддерживают интеграционные платформы, позволяющие организовывать взаимодействие между прикладными системами не только через Web-сервисы, но и посредством программных адаптеров. Этим же объясняется тот факт, что спецификация BPEL, создававшаяся изначально с ориентацией только на SOA и называвшаяся BPEL4WS, т. е. BPEL for Web Services, в настоящее время допускает и иные механизмы взаимодействия разнородных приложений.

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

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

Очевидно, что для полноценного функционирования BPM-системы она должна быть дополнена серверами приложений, интеграции, идентификации пользователей, обмена сообщениями, коллективной работы и т. д. Иными словами, заказчику нужен целый стек хорошо подогнанных друг к другу технологий. Неудивительно, что среди лидеров рынка BPM мы видим крупнейших поставщиков системного ПО и базовых программных технологий: BEA, IBM, Microsoft, Oracle и SAP. И хотя разработчики, сосредоточившие свои усилия только на BPM-системах (Ultimus, SeeBeyond, Vitria, WebMethods и др.), успешно конкурируют с грандами отрасли, им трудно будет соперничать с поставщиками комплексных прикладных платформ. Не исключено, что многие из них будут куплены более крупными игроками (недавно объявлено о предстоящем поглощении фирмы SeeBeyond компанией Sun Microsystems).

Затем проследим

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

Рис. 2. Работа по совершенствованию

бизнес-процесса никогда не останавливается

Необходимо также собирать статистику, характеризующую эффективность выполнения процессов, и, анализируя ее, находить пути для их оптимизации. Для этого BPM-системы должны обладать средствами сбора данных со специальных "программных датчиков" и их аналитической обработки. Иногда с помощью инструментов такого рода удается выявлять взаимосвязь и взаимозависимость разных бизнес-процессов.

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

Куда идет рынок BPM

Сведения о мировом рынке BPM крайне скудны. По оценкам IDC, на нем сегодня работают около сотни вендоров. Суммарный их доход составил в 2004 г. почти 1 млрд. долл. До 2009 г. прогнозируется его 20%-ный ежегодный рост и выход на уровень 3 млрд. долл. Стимулируется он как естественным желанием повысить качество менеджмента, так и требованиями недавно принятых нормативных актов Sarbanes - Oxley и Basel II, предписывающих жесткую регламентацию процессов финансового управления, их документирование и поддержку. Стоимость лицензий на ПО BPM варьируется в широких пределах - от десятков до сотен тысяч долларов. Мощным акселератором здесь может стать успешное развитие архитектуры SOA.

Версия для печати