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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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