Василий Анфиногентов,
Алексей Прошин
«ФОРС – Центр разработки»

Преимущества концепции BPM при интеграции приложений

Источник: журнал "Век качества" №6, 2008г., http://www.agequal.ru/Archive_magazines/AGE_QUALITY_6_2008.pdf

Василий Анфиногентов директор отделения автоматизации деловых процессов

Алексей Прошин директор по инструментальным средствам описания бизнес- процессов

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

В настоящее время внедрение систем управления бизнес-процессами (Business Process Management System – BPMS или BPM) представляет собой одну из актуальных задач для любого ITподразделения крупного или среднего предприятия. По ожиданиям IDC, объем мирового рынка ВРМ к 2011 г. достигнет 5,5 млрд долл., увеличиваясь примерно на 44% ежегодно. Этот рост будет обусловлен несколькими факторами. Вопервых, данный тип решений еще не слишком широко распространен и составляет незначительную долю потенциально возможного рынка. Вовторых, уже существующие инсталляции BPM-систем, которые, хотя пока и автоматизируют лишь определенные, довольно узкие участки бизнеса, но уже хорошо зарекомендовали себя на отдельных проектах, будут масштабироваться на уровень предприятий в целом, охватывая дополнительные бизнес-процессы и подразделения.

По данным аналитической компании Forrester Research, более 25% ITподразделений в прошлом году уже начали подобный проект или предполагают его начать в ближайшем будущем. В связи с этим закономерен интерес к методологии построения и внедрения BPM-систем, к сложным моментам при реализации подобных проектов. Процесс внедрения BPM действительно сопряжен с трудностями, которые лежат в методологической или системной плоскости. Методологическая сложность связана с необходимостью применения парадигмы мышления руководства компании–заказчика. Если раньше она заключалась в стремлении руководства наилучшим образом выполнить свои управленческие функции, то теперь задача состоит в осознании своей роли в общей деятельности, важности обеспечения правильного прохождения базовых, критичных для компании бизнес-процессов. Другими словами, необходимо изменение способа мышления с функциональноориентированного на процессноориентированный.

В зрелых ИТотраслях BPM уже, по сути, используется как стандарт организации управления, хотя это новейшая разработка, воплотившая лучшие мировые достижения в данной области. Без BPM-системы не обойтись там, где требуется отслеживать ход процесса в деталях и где информационная система охватывает около 90% выполняемых операций. В основном это телекоммуникационные компании, финансовые учреждения, госсектор, электроэнергетические предприятия.

Подход к реализации BPM-систем

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

Интеграционный подход требует включения в состав BPM-систем средств описания и реализации взаимодействия с различными существующими на предприятии системами, прежде всего – интеграционных адаптеров. Интеграционный адап тер осуществляет преобразование внутренних интерфейсов взаимо действия, предоставляемых при кладной системой, в стандартные интерфейсы взаимодействия, ис пользуемые в ходе осуществления бизнес-процесса. Компания ФОРС разработала один из таких адапте ров, который позволяет переносить описание процессов, выполненное средствами бизнес-моделирования и анализа Casewise и Oracle Workflow и графически представленное в ви де шаблонов и диаграмм, в матрицу стандарта BPEL (Business Process Execution Language – язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой). В свою очередь, процессный подход требует наличия в составе BPM-системы средств описания по токов работ и их реализации. Более того, использование интеграцион ных возможностей совместно с про цессным подходом означает, что простого представления об интегра ции как об обмене информацией ме жду системами недостаточно. Сама BPM-система является мно гоуровневой. Наравне с исполняе мым уровнем, имеющим визуальный интерфейс, например BPEL, сущест вуют инструменты более высокого уровня, которыми может пользо ваться аналитик. Сейчас уже есть возможность манипулировать раз ными частями большого BPM-реше ния подобно тому, как это происхо дит в технике. Поставщики BPELре шений предоставляют инструмен тальные средства, позволяющие объединить разные уровни системы между собой.

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

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

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

Стандартизация BPM-систем

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

Для решения интеграционной за дачи в рамках BPM-системы требует ся стандартизация описания взаимо действия между BPM-системой и прикладными системами. В настоя щее время является почти обязатель ным использование SOAархитекту ры (ServiceOriented Architecture – сервисориентированная архитек тура – модульный подход к разработ ке ПО, основанный на использова нии сервисов (служб) со стандарти зированными интерфейсами). Как следствие, описание взаимодействия предусматривает применение нота ций WSDL и XSD. В целом хорошей практикой считается применение открытых стандартов, поддержан ных международными организация ми. Это позволяет в дальнейшем ис пользовать в рамках BPM-системы компоненты внешних производите лей, облегчает поддержку системы, работу с ней внешних и внутренних разработчиков.

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

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

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

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