Алексей Резниченко,
аналитик компании «Кворум», alexey.reznichenko@quorum.ru

ИТ-поддержка процессной интеграции

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

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

Процессное управление и управление качеством

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

Качество продуктов и услуг предприятия определяется качеством порождающих их процессов. Эта идея лежит в основе практически всех систем управления качеством, которые внедряются современными предприятиями для усовершенствования производственных процессов, мониторинга нужд и ожиданий заказчиков, обеспечения конкурентоспособности на внутреннем и внешнем рынках, обеспечения прозрачности процессов как для руководства компании, так и для заказчика. И все эти системы, ориентированные на различные методики: ISO 9000, Capability Maturity Model (CMM, CMMI), EFQM, 6sigma и т. д., основаны на процессном подходе к управлению.

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

Поддержка бизнес-процессов

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

Рис. 1 Архитектура ИСП для поддержки формализованных бизнес-процессов

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

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

Помимо системы управления workflow, в платформу процессной интеграции, как правило, входят система обработки сообщений класса MOM (Message-Oriented Middleware) и средства класса EAI (Enterprise Application Integration, интеграция приложений предприятия), дополняющие возможности системы workflow по интеграции приложений.

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

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

В России для моделирования и анализа бизнес-процессов достаточно широко используются средства моделирования программных систем: Rational Rose, Designer/2000, Bpwin и т. д., однако наиболее эффективны методики и комплекты инструментов класса BPA (Business Process Analysis, анализ бизнес-процессов), которые специально для этого разработаны компаниями Popkin Software, IDS Scheer, Proforma, Meta Software и рядом других.

Как правило, в таких комплектах предлагается четыре «взгляда» — процессы, функции (с целями), данные, организация — на моделирование и анализ бизнес-процессов, для каждого из которых поддерживается три уровня анализа — требования, спецификации, реализация, — см. рис. 2).

Рис. 2. «Взгляды» и уровни анализа бизнес-процессов

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

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

BPM: workflow полезно для здоровья бизнес-процессов

В самом общем виде систему класса workflow можно определить как систему управления потоком работ и заданий, которые в соответствии с некоторым сценарием направляются исполнителям, людям или программам, для выполнения. Многие распространенные «жесткие» системы класса workflow реализуют, как правило, достаточно простые и предопределенные сценарии управления потоком работ и заданий, которые сводятся в основном к описанию маршрутизации заданий. Подсистемы workflow с такими сценариями широко используются в документообороте. Отсюда и пренебрежительное отношение у части российских ИТ-специалистов к workflow в целом: «А что оно делает? Доставляет документ из пункта А в пункт Б...».

Работа с документами и их перемещение (docflow) присущи многим бизнес-процессам. Исторически функциональность workflow первое широкое применение получила именно в системах документооборота, запросы которых во многом и определили ее развитие.

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

Бизнес-процессы сложны по структуре, они могут быть вложенными, то есть включать подпроцессы, в том числе и параллельно выполняющиеся. На их ход влияют различные события, в частности результаты работы одного бизнес-процесса служат входными данными для другого, кроме того, бизнес-процессы взаимодействуют между собой. В принципе функциональность систем workflow, соответствующих «эталонной модели workflow» организации Workflow Management Coalition, при правильном применении позволяет достаточно эффективно автоматизировать управление бизнес-процессами [2].

В последние годы многие системы workflow были расширены, чтобы максимально полно поддерживать цикл работ по совершенствованию бизнес-процессов. Его образуют: описание и моделирование («как есть») — анализ — оптимизация («как должно быть») — автоматизация — анализ (выполнения автоматизированных бизнес-процессов) — оптимизация и перепроектирование (по результатам анализа выполнения и/или из-за изменений требований бизнеса). Расширенные таким образом системы workflow теперь определяются как системы класса BPM (Business Process Management, управление бизнес-процессами).

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

Возможности средств моделирования систем класса BPM и комплектов класса BPA частично пересекаются, но модели, построенные с их использованием, предназначены для разных лиц. Модели, полученные средствами класса BPA, — прежде всего для бизнес-аналитиков, а модели систем класса BPM — для разработчиков и непосредственного исполнения системами workflow. К тому же модели, полученные средствами типа BPA, как правило, нужно детализировать для исполнения в конкретной системе BPM. Организациям, которые ставят задачу описать, проанализировать свои бизнес-процессы и повысить их эффективность посредством автоматизации, нужны и те и другие средства.

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

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

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

Рис. 3. Схема коррекции развития процесса с помощью “двигателя” и монитора workflow

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

Развитие систем класса BPM продолжается, и наибольшее внимание сейчас уделяется обеспечению возможности использования Web-сервисов и в целом «погружению» этих систем в вычислительную среду и архитектуру, построенные на основе Web-сервисов (Service-Oriented Architecture, SOA).

Платформа процессной интеграции — это не только workflow/BPM

Система класса workflow/BMP является ядром платформы процессной интеграции, ее основным, но, как правило, не единственным компонентом. Участникам бизнес-процесса, людям и приложениям, совместно использующим различные данные, необходим стандартный механизм работы с этими данными, которого нет в системах workflow/BPM. Системы класса (Message-Oriented Middleware, MOM) могут быть таким механизмом. Практически всегда в крупных проектах по автоматизации бизнес-процессов workflow и MOM дополняют друг друга.

Привлекает все большее внимание применение в интеграционных платформах «общей шины предприятия» ESB (Enterprise Service Bus), основанной на использовании функциональности системы класса MOM и стандартов JMS (Java Message Service). Кратко ее можно определить так: ESB = MOM+JMS+XML+WebServices+... (о концепции и основных особенностях ESB см. [3]). Функциональность ESB реализуется, как правило, «поверх» системы класса MOM в дополнительном к ней продукте. Применительно к интеграции шина ESB позволяет использовать Web-сервисы для стандартизации, а значит, и упрощения, взаимодействия между участниками бизнес-процессов и компонентами интеграционной платформы.

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

Особенности применения процессной интеграции

В последние годы такие компании, как IBM, Oracle, BEA Systems, Microsoft, прилагают значительные усилия по развитию средств процессной интеграции в своих интеграционных платформах. Но, как отмечено в исследованиях аналитических фирм (Gartner и др.), большого успеха workflow/BPM добиваются небольшие специализированные компании. Организациям, которым интеграция приложений нужна для управления явно определенными бизнес-процессами, имеет смысл продумать возможность формирования платформы из доступных на рынке продуктов или воспользоваться платформой, уже сформированной компанией, действующей в качестве консультанта и интегратора в области BPM и EAI. Вообще-то услуги консультанта и интегратора при реализации интеграционного проекта весьма желательны, так как большинство современных интеграционных продуктов сложны, и, хотя поставщики осознают эту проблему и работают над ее решением, что отметила Gartner в своем прогнозе на 2004 год, радикального их упрощения в обозримом будущем ожидать не приходится.

Как перейти к процессному управлению

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

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

Эти варианты определяют и разные сценарии применения средств процессной интеграции. Во многих случаях информационную систему предприятия можно разделить на основную информационную систему и специализированные системы.

В варианте быстрого и полного перехода организации на процессно-ориентированное управление интеграция существующих приложений основной и специализированных систем в рамках бизнес-процессов благодаря применению платформы процессной интеграции вряд ли практична, так как потребует много времени, а приложения, скорее всего, станут непроизводительны. В этом случае имеет смысл заменить основную информационную систему — например, ERP-систему для промышленного предприятия или автоматизированную банковскую систему для банка — на новую, построенную на базе платформы процессной интеграции. Приложения дополнительных информационных систем можно связать, используя эту же платформу. По сути, такой сценарий построения информационной системы предприятия предлагает компания SAP AG, ERP-система которой основана на интеграционной платформе — сервере приложений SAP NetWeaver. По этому же пути идет и компания «Кворум», АБС NEXT которой построена на одноименной интеграционной платформе NEXT.

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