Анатолий Белайчук

технический директор компании «Бизнес-Консоль» (Москва) bell@b-k.ru

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

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

Свою лепту в сумятицу, связанную с BPM, вносят маркетинговые приемы производителей, расширительно толкующих используемые ими термины. Можно вспомнить, как в свое время все СУБД в одночасье стали «реляционными». Нечто похожее наблюдается и сейчас: о наличии систем категории BPM в их продуктовых линейках заявляют многие поставщики, хотя это не всегда обоснованно. К примеру, в качестве BPM позиционируются столь разные программные продукты, как дизайнер бизнес-процессов (IDS Scheer ARIS), программное обеспечение промежуточного слоя для координации Web-сервисов (Oracle BPEL) и ориентированное на работу с персоналом BPM-приложение (Fujitsu Interstage).

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

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

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

Попытаемся сформулировать ключевые тезисы, позволяющие сориентироваться в тематике BPM.

BPM — это не программа

Как следует из определения, которое дает Wikipedia (www.wikipedia.org), BPM — это управленческая методология. Следует различать BPM как методологию реорганизации и оптимизации бизнес-процессов и как программный инструментарий, часто используемый с этой целью. Подобное программное обеспечение вообще-то следует называть Business Process Management System (BPMS) или BPM-системой, однако зачастую его именуют просто BPM.

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

Новизна BPM

Иногда можно услышать, что BPM существовал всегда. Подобные утверждения исходят из чересчур расширительной трактовки термина, которая мешает уловить суть того, что возникло в управлении бизнес-процессами относительно недавно и сейчас обозначается этой аббревиатурой. Новый подход начал развиваться приблизительно с 2000 года, а всплеск числа публикаций о BPM пришелся на 2003 год. BPM сменил популярный в 90-е годы реинжиниринг бизнес-процессов [1], однако нужно учесть следующее:

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

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

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

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

BPM и workflow

С употреблением этих терминов возникла немалая путаница [2]. Сам по себе термин workflow означает «последовательность работ, составляющих процесс», но его принято использовать и для обозначения функции управления потоком работ в традиционных системах документооборота. А Business Process Management есть расширение workflow, но в BPM больше внимания уделяется автоматически выполняемым шагам бизнес-процесса (т.е. межсистемному взаимодействию) и мониторингу бизнес-процессов (т.е. сбору статистики выполнения бизнес-процессов).

Теоретически, BPM-системы должны равно хорошо координировать задачи, выполняемые как людьми (human-to-human flow), так и автоматизированными системами (system-to-system flow). Однако на практике сегодняшние BPM-системы лучше справляются либо с тем, либо с другим [3]. В частности, стандарт BPEL в своем нынешнем виде описывает координацию вызовов Web-сервисов и не рассматривает взаимодействие с людьми [4].

Системы, ориентированные на координацию выполняемых людьми работ, иногда называют workflow-системами (еще одно значение этого термина), а аналитики Gartner обозначают их термином Pure-Play BPM. Термин «BPM-система» иногда используется в узком смысле — «система, ориентированная на интеграцию»; в Gartner такую систему называют Integration BPM. Встречается также собирательный термин «системы BPM и workflow».

Компоненты BPM

Распространенная ошибка — воспринимать BPM-систему как еще одну «рисовалку бизнес-процессов». Действительно, визуальный редактор (или дизайнер) бизнес-процессов, являющийся компонентом BPM-системы, мало чем отличается от традиционного инструментария реинжиниринга бизнес-процессов (средств рисования IDEF- или DFD-диаграмм). Но в BPM-системе рисование схемы бизнес-процесса является не завершающим этапом работы, а ее началом.

Готовая схема бизнес-процесса в виде XML-файла загружается в «движок» (BPM engine), а затем начинают стартовать экземпляры бизнес-процесса. Скажем, в бизнес-процессе сервисного обслуживания автомобиля экземпляр бизнес-процесса — это клиентский заказ. Каждый заказ проходит через последовательность шагов: менеджер оговаривает с клиентом объем работы, проводит первичный осмотр автомобиля, потом автомобиль отправляется мастеру в цех, тот выполняет свою задачу, наконец, клиент расплачивается и забирает автомобиль. Кроме того, в ходе реализации заказа возможны дополнительные согласования с клиентом.

«Движок» хранит информацию об экземплярах бизнес-процесса: кем и когда он запущен, на каком шаге сейчас находится и кто отвечает за его выполнение. Бизнес-процесс может запускаться вручную (в нашем примере это делает менеджер) или программно (скажем, на сайте автосервиса клиент самостоятельно записывается на техобслуживание). Менеджер, мастер и бухгалтер видят в окне браузера списки порученных каждому из них заданий. Когда задание выполнено, сотрудник автосервиса вводит необходимые данные, нажимает кнопку на Web-форме, и бизнес-процесс переходит на следующий шаг. Клиент же имеет возможность отслеживать через сайт ход выполнения его заказа.

У экземпляра бизнес-процесса есть контекст — набор реквизитов, определенных в схеме бизнес-процесса. В нашем примере это марка и номер автомобиля, фамилия и телефон клиента, наименования необходимых для ремонта запчастей и т.п. Такие данные могут храниться либо непосредственно во внутренней базе данных «движка» BPM, либо в специализированной внешней системе или базе данных (тогда пишется программа, связывающая «движок» с этой системой). Часть шагов бизнес-процесса (например, выписка счета) допустимо выполнять автоматически. Можно предусмотреть и дополнительные средства контроля. Скажем, если процесс задержался на каком-то шаге дольше, чем того требует регламент, по SMS автоматически отправляется уведомление менеджеру.

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

Дизайнер, «движок» и монитор являются стандартными компонентами BPM и соответствуют управленческой практике: разработка схемы бизнес-процесса, исполнение и анализ. Развитые BPM-системы помимо этих компонентов могут включать в себя модули Business Rule Engine (BRE), Business Activity Monitoring (BAM) и др. [5]. Существуют и программные продукты, реализующие отдельные компоненты BPM, — скажем, только проектирование бизнес-процессов.

BPM и корпоративные приложения

Как и в СУБД, где сначала определяется схема данных, а затем в нее заносятся сами данные, в BPMS сначала определяется схема, а уж потом в соответствии с нею создаются экземпляры бизнес-процессов. Схема данных в первом случае и схема бизнес-процесса во втором могут быть произвольными — в зависимости от предметной области.

Сегодня многие ERP- и CRM-системы включают встроенные модули BPM, предназначенные для решения упомянутой проблемы изменчивости бизнес-процессов. Благодаря такому модулю перенастройка системы выполняется быстрее, с небольшими затратами на программирование или вовсе без него. Поставщики таких систем разрабатывают собственные модули BPM, что было характерно и для СУБД.

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

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

В области интеграции технология BPM пересекается с SOA (service-oriented architecture — «сервис-ориентированная архитектура»). Отсутствие стандарта на взаимодействие систем разных производителей до сих пор делало интеграцию занятием, перспективным преимущественно для самих интеграторов и пугавшим заказчиков неприемлемо высокими расходами и рисками. Как известно, неудовлетворенный заказчик с легкостью делает неудовлетворенным разработчика. В результате отрасль пришла к пониманию необходимости решения этой проблемы. SOA обеспечивает стандарт на интерфейсы и среду, в которой такие интерфейсы могут публиковаться и вызываться, а BPM — смысловую нагрузку и правила, согласно которым системы должны передавать друг другу информацию и управление.

Речь, конечно, не идет о возврате к «лоскутной» автоматизации — набору слабосвязанных программ и дублирующих друг друга баз данных. Но понятно, что путь создания единой всеохватывающей системы является тупиковым, приводит к появлению неповоротливых нежизнеспособных монстров. Современная архитектура — двухуровневая. Внизу находятся тесно интегрированные системы, внутри которых располагается единая база данных с присущими ей классическими «короткими» транзакциями. На верхнем уровне системы связываются друг с другом при помощи BPMS в рамках «длинных» транзакций.

Преимущества такой архитектуры становятся очевидными при рассмотрении задачи, состоящей в интеграции цепочки «поставщики — клиенты» и создании «виртуальной корпорации». Рамки бизнес-процесса раздвигаются, и вслед за границами функциональных подразделений рушатся границы предприятий. Считается, что на Западе предприятия уже научились отстраивать бизнес-процессы, и сегодня актуальной для бизнеса стала интеграция между компаниями [6]. С технической точки зрения интеграция гетерогенных корпоративных приложений на основе бизнес-процессов выполняется с помощью так называемых «композитных» (composite) приложений [7], которые представляют собой пользовательские интерфейсы одновременно к бизнес-функциям корпоративных приложений и к «движкам» BPM.