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

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

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

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

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

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

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

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

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

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

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

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

Платформа процессной интеграции — это не только 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.

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

Литература

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

Что такое BPM?

BPM — эта аббревиатура применительно к бизнес-процессам первоначально означала Business Process Modeling, моделирование бизнес-процессов. В настоящее время, когда речь идет о моделировании (и анализе) бизнес-процессов, преимущественно используется аббревиатура BPA (Business Process Analysis, анализ бизнес-процессов).

А BPM в последние годы применительно к бизнес-процессам почти всегда расшифровывается как Business Process Management — управление бизнес-процессами. При этом имеется в виду, что соответствующие программные инструменты позволяют не только моделировать, но и контролировать, и управлять исполнением бизнес-процессов. Базовый набор этих инструментов включает средства моделирования и анализа бизнес-процессов, а также систему управления workflow и дополнительные средства.

Достаточно часто BPM встречается как аббревиатура от Business Performance Management — управление производительностью бизнеса. Это направление относят к прикладным аналитическим (Business Intelligence) технологиям.

Два подхода к управлению

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

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

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

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

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

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

BPM и платформа NEXT

Некоторые из компаний-лидеров в дополнение к «двигателю» workflow на основе бизнес-правил предлагают и обработку бизнес-объектов в рамках объектно-ориентированного подхода, но, возможно, наиболее полная реализация этого подхода достигнута в ядре интеграционной платформы NEXT (расширении системы Oracle Workflow корпорации Oracle до уровня BPM), которое разработала компания «Кворум» (www.quorum.ru).

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

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