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

Пример того, как могут выглядеть собранные вместе компоненты BPMS, показан на рис. 10.3[217].

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

Современные архитектуры систем BPMS, как правило, включают два уровня: уровень представления[218] (обычно реализуется веб-сервером) и уровень процессов, где движок исполняет загруженные в него процессные модели. Исполнение включает также вызов веб-сервисов и внешних программных модулей.

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

10.4.2. Определение бизнес-требований и требований к данным

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

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

В рамках традиционного подхода определение требований к изменениям в операциях и в компьютерных системах начинается с фиксации разницы между старой и новой моделями бизнеса. Затем люди из бизнеса и из IТ преобразуют эти требования в спецификации, исходя из которых можно разработать программное обеспечение, составить планы тестирования и программы обучения. При использовании BPMS такой подход становится анахронизмом. В среде BPMS новая схема вместе с описанием правил и дизайном экранных форм сама является и новыми требованиями, и спецификацией. Автоматическая генерация приложений из моделей ставит знак равенства между моделью и требованиями.

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

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

10.4.3. Совместная командная работа

Таким образом, в среде BPM с использованием BPMS схема бизнеса становится требованиями, а бизнес-правила становятся логикой. Это приводит к новому типу взаимодействия между бизнесом и IТ, переопределяя роли, которые каждая из сторон играет в бесконечной эволюции операций и приложений. К счастью, предоставляемые системами BPMS возможности совместной работы позволяют множеству людей работать над одной бизнес-моделью, невзирая на географическую удаленность. Формируется виртуальная команда: вне зависимости от того, где находятся эксперты, они совместно участвуют в создании и согласовании новых схем бизнеса, бизнес-правил, способов измерения эффективности.

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

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