Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0 - Коллектив авторов

• взаимодействуют подразделения;

• принимаются решения и назначается ответственность;

• меняется процесс;

• проверяются процедуры;

• применяются способы и методы.

В настоящее время существует множество тесно связанных с SOA программных продуктов, к которым относятся сервисные каталоги и репозитории[214], ESB, системы комплексной обработки событий (CEP)[215], BPMS и т. д. Достичь успеха и реализовать преимущества SOA может компания любого масштаба. Но много и тех, кто потерпел неудачу. Перечисленные продукты предоставляют стандартную платформу для реализации SOA на предприятии, но без систематического рассмотрения и утверждения необходимой стратегии, стандартов, методов регулирования и программ подготовки персонала программное обеспечение просто не даст ожидаемого эффекта. Поэтому любой организации, серьезно рассматривающей переход на SOA, расширение области применения SOA или испытывающей проблемы с внедрением SOA, необходимо решить эти вопросы как можно раньше.

10.3.7.4. Переход на SOA

При переходе на SOA следует обратить внимание на следующее.

• Концепция, стратегическое планирование, одобрение со стороны высшего руководства, выделение бюджета и управление ожиданиями.

• Стратегия оценки эффективности бизнеса – от стратегических целей до операционной эффективности сервиса.

• Оценка готовности к переходу на SOA – текущая технологическая среда и архитектура.

• Описание стратегии SOA – включая описание способов применения и перспективный план реализации[216].

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

• Регулирование – полный жизненный цикл сервисов.

• Определение сервисов, которые будут реализованы в прототипе SOA, и требований к прототипу, включая отчет по результатам и его анализ.

• Определение типов сервисов, которые будут реализованы.

• Приобретение компетенций в области SOA: подготовка и тестирование персонала, выбор и внедрение ПО.

• Как будут разрабатываться, тестироваться и внедряться элементы SOA – сервисы, EAI адаптеры и т. д.

• Как будет внедряться и использоваться ESB, включая переделку существующих механизмов коммуникаций.

Примечание: приведенный список содержит ключевые вопросы, но не является исчерпывающим.

10.3.7.5. Применение SOA

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

Подход SOA предлагает новый способ разработки программных модулей, основанный на стандартизированных сервисах и интерфейсах, который можно использовать для внешних по отношению к BPMS приложений. Но и приложения, созданные в среде BPMS, концептуально соответствуют SOA – они выполняют одну функцию, они стандартизированы и могут использоваться повторно.

К компонентам BPM, следующим подходу SOA, относятся:

• процессный движок – доступ через SOA к данным, необходимым для выполнения очередной задачи;

• EAI-адаптеры, реализованные в виде сервисов SOA;

• бизнес-аналитика (BI) – операционная статистика, аудит и т. п.;

• управление правилами – описание и исполнение;

• управление процессом – мониторинг и контроль действий и работ;

• управление эффективностью – получение данных из приложений BPMS, унаследованных и других приложений, использующих протоколы SOA.

10.3.8. Сервисная шина предприятия (ESB)

Сервисная шина предприятия (ESB) – это сочетание архитектуры программного обеспечения, программных средств и коммуникационной среды, управляющих передачей данных между компьютерами. Коммуникационная среда ESB в передаче сообщений выполняет функцию посредника: прикладные системы подключаются к ней для обмена информацией друг с другом. Программное обеспечение ESB получает сообщение от приложения посредством адаптера для того протокола, который данное приложение использует. Адаптер преобразует полученные данные к стандартному внутреннему формату ESB. Затем ESB определяет получателя сообщения, сверяясь с загруженным в него набором правил маршрутизации. Передача данных также осуществляется через адаптер, при этом происходит еще одно преобразование данных – на этот раз из внутреннего формата к формату протокола, поддерживаемого приложением-получателем. Еще одна важная функция ESB, помимо гибкой маршрутизации и преобразования протоколов, – обеспечение гарантированной доставки. ESB сохраняет сообщения во внутренней очереди и в случае временной недоступности приложения-получателя повторяет попытки доставки.

Таким образом, программное обеспечение ESB располагается между приложениями и работает через адаптеры EAI, давая любым приложениям возможность взаимодействовать друг с другом через стандартный формат сообщений ESB.

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

Упрощение интерфейсов и сокращение их числа снижают риски и затраты и позволяют быстро вносить в приложения изменения.

ESB отлично дополняет BPMS, а в некоторых случаях (как, например, IBM WebSphere и TIBCO) они фактически являются одним целым.

10.3.9. Репозиторий BPMS и хранение транзакционных данных

Репозиторий BPMS хранит бо́льшую часть данных о процессах компании. Однако обычно в нем не хранятся все данные транзакций, совершаемых в ходе выполнения процесса. Ввиду большого объема такой информации для ее хранения часто используется внешняя СУБД. Решение о том, какие данные будут храниться в репозитории BPMS, а какие вовне, часто принимается исходя из их использования. Например, информация, необходимая для управления процессом, – исполнители задач, маршруты потоков работ, экранные формы – обычно хранится в BPMS. Любой проект внедрения BPMS требует участия специалистов по СУБД для определения, где что будет храниться и какие базы данных будут использоваться для хранения транзакционных данных.

Процессный репозиторий может хранить следующую информацию о процессах и потоках работ.

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

• Кто является владельцем процесса.

• Что процесс делает.

• Какие действия выполняются, и как они связаны друг с другом.

• Какие технологии используются.

• Какие триггеры или события инициируют процесс.

• Каковы ожидаемые результаты.

• Какие проблемы может вызывать каждое действие.

• Когда процесс был инициирован.

• Где процесс выполняется.

• Как процесс взаимодействует или связан с другими процессами.

• Как процесс взаимодействует с процессами других бизнес-единиц и других предприятий.

• Какова интенсивность и продолжительность процесса.

• Как передаются результаты.

• Зачем процесс нужен, и насколько он соответствует стратегическим целям.

• SLA, KPI, целевые значения и т. п.

• Метрики процессов, такие как время выполнения, количество необходимых ресурсов, минимальное и максимальное количество одновременно исполняющихся экземпляров, прямые и косвенные затраты и т. п.

• Бизнес-правила.

• Тип и источник данных, связанных с процессом.

• Нормативные требования.

• Расчетное время, особенности и формы возможных результатов.

• Результаты, которые становятся триггерами для других процессов.