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

На предприятиях с достаточно большим опытом процедуры оптимизации процессов постоянно совершенствовались: в конце 80-х и в начале 90-х годов наблюдалось повальное увлечение реинжинирингом, автоматизация процессов и документооборота (workflow) стала популярной в середине 90-х, а вторая половина десятилетия ознаменовалась появлением BPM-приложений и Web-служб как средства организации процессов и интеграции информационных систем.

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

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

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

BPM-приложения, созданные такими компаниями, как HandySoft, Savvion и Fuego, поддерживают проектирование, анализ, оптимизацию и автоматизацию бизнес-процессов. Логика процесса в упомянутых программных разработках отделена от приложений, которые ее реализуют. Эти системы могут управлять взаимоотношениями участников процесса, объединять внутренние и внешние ресурсы процесса, выполнять мониторинг эффективности процессов. Поэтому не удивительно, что BPM-системы быстро стали одной из наиболее интересных технологий в области корпоративного ПО. Немногим системам в будущем будет уделено столько же внимания, сколько BPM. Тем не менее, как я объясню ниже, самые большие трудности внедрения BPM-систем проистекают из тех движущих сил, которые и делают эти решения столь привлекательными.

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

Категории процессов

Бизнес-процессы можно разделить на три категории: «процесс — процесс», «человек — процесс» и «человек — человек». На рис. 1 эти категории представлены в системе координат сложность — длительность. В простом процессе обычно выполняется обмен данными между приложениями (например, при выполнении транзакции в ERP-системе), а сложные процессы, как правило, задействуют несколько приложений или сотрудников (пример — разработка продукта). Длительность — это период времени от начала до конца процесса; в ERP-транзакциях обычно выполняется простое преобразование данных, поэтому их длительность невелика. А вот на разработку продуктов зачастую уходят месяцы.

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

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

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

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

Отношение к Web-службам

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

Внимательно проследив процесс развития Web-служб, вы обнаружите, что определений этого термина почти столько же, сколько и предлагающих их компаний. Delphi Group определяет Web-службу как XML-объект, состоящий из данных, прикладного кода, логики процесса, а также любой комбинации этих компонентов, к которым можно обращаться по любой сети TCP/IP с применением протокола SOAP (Simple Object Access Protocol) для интеграции, языка WSDL (Web Services Definition Language) для самоописания служб и интеграционной спецификации (UDDI) для регистрации и поиска служб в общедоступных или частных каталогах. Определение Web-служб в нетехнических терминах выглядит примерно так: Web-службы — это бизнес-активы, которые можно предоставлять в совместный доступ, объединять, применять и повторно использовать в корпоративной ИТ-инфраструктуре. Пользователем Web-служб может быть как человек, так и машина.

Выполненный Delphi Group опрос покупателей ПО показал, как много путаницы возникает вокруг Web-службы. Разброс определений Web-служб, данных респондентами, простирался от «механизм поддержки совместного бизнеса» (75% опрошенных) до «модель бизнеса в Интернете» (57%), часто встречались также формулировки «среда разработки Web-сайтов» (42%) и «парадигма разработки ПО» (42%). При более близком знакомстве с Web-службами компании лучше поймут конкретные приложения этой ИТ-модели и, несомненно, обнаружат новые области ее применения.

Важно понять, какие базовые стандарты лежат в основе Web-служб. Хотя почти четверть респондентов не знакомы с SOAP, тем не менее большинство верно ответили, что это стандартный интерфейс интеграции приложений. Очень немногие (3,2%) спутали SOAP с UDDI, но существенное число опрошенных (15,9%) неправильно сказали, что это средство описания Web-служб, хотя эту функцию выполняет WSDL.

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

Опрошенные признают важную роль XML, SOAP, Java 2 Enterprise Edition (J2EE) Connector Architecture, UDDI и WSDL в ориентированной на Web-службы стратегии. Язык XML — это очевидная основа, на которой будут базироваться Web-службы. Этот стандарт практически единодушно принят в качестве их обязательного компонента. Большая часть (53%) принявших участие в опросе компаний уже приступили к организации поддержки XML в существующих приложениях, что позволит им воспользоваться преимуществами этого языка. По-видимому, респонденты понимают также важность SOAP — 70% сообщили, что уже занялись обеспечением SOAP-интерфейсов для своих бизнес-приложений или планируют это сделать в течение года.

Инфраструктура Web-служб

Организации по-разному решают проблему неопределенности требований к инфраструктуре. Многие (41%) создают смешанную (с поддержкой J2EE и продуктов Microsoft) среду развертывания. А вот 36% опрошенных ориентируются исключительно на Microsoft-совместимую среду и еще 16% — только на UNIX и J2EE.

Есть ли понимание Web-служб или нет, они уже здесь и никуда не денутся — только 25% принявших участие в опросе совсем не планируют их внедрять. Интересно, что 39% планируют внедрять Web-службы в области управления бизнес-процессами, закрепляя связь между Web-службами и BPM-решениями. Среди других областей применения Web-служб — корпоративные порталы (53%), управление контентом (37%), интеграция приложений предприятия — EAI (39%), управление отношениями с клиентами — CRM (29%) и электронная коммерция (39%).

Треть компаний (34%) еще не определились, стоит ли применять Web-службы для распределенной обработки крупных вычислительных задач. А те, что решили этот вопрос положительно, планируют внедрить Web-службы для распределенной обработки очень скоро — до 2003 года.

Где имеет смысл применять Web-службы

Компании также задумываются, где лучше всего применять Web-службы для решения внутрикорпоративных задач. Хотя Web-службы универсальны и не ориентированы на строго определенные внутрикорпоративные инициативы или решение задач конкретных подразделений, наиболее часто их применяют в корпоративных порталах (21%), BPM (15%) и EAI (15%). Эти ответы ясно говорят о том, что компании хотят, чтобы EAI-решения предоставляли информацию — будь то портал, контекст процесса или приложение.

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

Свыше двух третей респондентов (70%) в настоящее время находятся в процессе внедрения бизнес-портала. Логично предположить, что эти организации будут применять для портальной интеграции данных, приложений и процессов Web-службы, а не жестко фиксированные портлеты, которые придется перепрограммировать заново при каждом изменении в процессе или приложении. Кроме того, развертываемым порталам все чаще приходится «выходить» за пределы компании через брандмауэр. По мере развития этой тенденции бизнес-портал станет местом, где сотрудники будут создавать, публиковать и использовать Web-службы.

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

Начало эволюции и первые трудности

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

Проект Business Process Management Initiative (http://www.bpmi.org) предлагает технические ресурсы и информацию для решения задач интеграции бизнес-процессов.

Естественно, поначалу не избежать трудностей. Участникам опроса кажется, что в предлагаемых Web-службах отсутствуют определенные возможности. Среди основных функций, которые пользователи хотели бы видеть в более полной версии Web-служб, — стандарты управления процессами, распределенная (между Web-службами и бизнес-объектами) аутентификация, метрики и мониторинг качества обслуживания (Quality of Service, QoS), гарантии целостности транзакции и доставки (nonrepudiation) и возможность совместного доступа не только к данным и контенту.

Web-службы — вперед

Несмотря на отсутствие единого определения Web-служб, организации предпринимают первые шаги по их применению — собственными силами (77%) или с привлечением бизнес-партнеров (36%), обладающих большим опытом. Однако 19% респондентов рассматривают недостаток опыта в создании ориентированной на сервисы архитектуры как основное препятствие на пути развертывания Web-служб. Среди других препятствий к внедрению Web-служб компании отмечают различия в стандартах внедрения (18%), отсутствие аналогичных успешно завершенных проектов (15%) и необходимость изменения культуры организации в связи с внедрением Web-служб (18%).

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

В процессе внедрения Web-служб компании по-разному будут оценивать успех проекта. В частности, они будут смотреть, насколько архитектура Web-служб позволяет оптимизировать использование существующей инфраструктуры и ПО (43%), задействовать внутренние ресурсы для разработки (38%), сократить время развертывания (40%) и начальные расходы на развертывание (25%), а также снизить совокупную стоимость владения (18%).

Самая большая группа респондентов (23%) планирует на протяжении последующих трех лет затратить на связанные с Web-службами проекты менее 100 тыс. долл., за ней следуют 18%, готовых на те же цели и в те же сроки потратить менее 250 тыс. долл. Поскольку затраты обычно пропорциональны размеру ИТ-проекта, разумно будет предположить, что входящие в эти группы компании предполагают начать с небольших проектов. Однако одно из обещанных преимуществ Web-служб — развитие существующей ИТ-инфраструктуры в противовес полной замене информационных систем. Во многих случаях для развертывания Web-служб не требуется новых инвестиций в оборудование или приложения — нужны лишь небольшие затраты на написание ПО для поддержки SOAP и XML.

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

Пара, которая должна встретиться

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

Барри Мэрфи (Barry Murphy) — старший аналитик компании Delphi Group (Бостон). Он возглавляет консалтинговые проекты, проводит исследования и читает лекции о программных инструментальных средствах и приложениях для управления бизнес-процессами, Web-службах и ПО управления знаниями. С ним можно связаться по e-mail: bjm@delphigroup.com.