Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0
• Расчетное время, особенности и формы возможных результатов.
• Результаты, которые становятся триггерами для других процессов.
Конечно, этот список варьируется от одного поставщика к другому, но ведущие поставщики обеспечивают большинство пунктов. При выборе BPMS важно быть уверенным, что система обеспечит как сегодняшние, так и завтрашние потребности – если система не обладает достаточной гибкостью, то при изменении требований придется искать ей замену. Поэтому требования к BPMS должны включать перечень данных, которые могут понадобиться для контроля за прохождением процесса, за взаимодействием с унаследованными приложениями и т. д.
Поскольку репозиторий поддерживает совместную разработку, возникает проблема разграничения доступа при одновременной работе. В прошлом, когда BPMS использовались в основном для решения частных задач, эта проблема остро не стояла, но с превращением BPMS в операционную среду она становится критической. Поэтому целесообразно привлекать к выбору BPMS и к конфигурированию ее репозитория архитектора и администратора баз данных.
10.4. Как добиться эффекта от технологий BPM
Успех перехода на новые технологии зависит от способности понять истинные возможности и назначение инструментария, а также от возможности тесно взаимодействовать с выбранным поставщиком ПО. Надо решить, как будут применяться BPM и технологии BPM, и разработать архитектуру, в которой они будут сочетаться с бизнес-операциями и IТ-средой вашей компании. Также надо понимать, как будет происходить работа с данными и как инструментарий BPM будет поддерживать совместную работу внутри организации и при взаимодействии с партнерами.
Примечание: содержание этого раздела не является всесторонним или исчерпывающим. Ниже рассматриваются лишь некоторые наиболее важные вопросы стратегии использования BPMS и технологий BPM.
10.4.1. Архитектура инфраструктуры BPM
Архитектура – это просто схема. Архитектура BPM – это схема того, как сочетаются друг с другом различные компоненты BPM. Сегодня доступно множество подобных архитектур. Как обычно, некоторые из них лучше, другие хуже, и некоторые больше других подойдут вашей компании и вашим представлениям о том, как BPM и BPMS должны поддерживать бизнес-операции. Внедрение BPM часто начинается без мыслей об использовании ПО: они появляются с развитием проекта в ответ на бизнес-потребности. Это нормально, и это правильно, но выбор средств определенно скажется как на IТ, так и на бизнесе. Это влияние может быть описано в целевой архитектуре операционной среды: как бизнес и IТ будут работать в новой среде, и кто за что будет отвечать.
Пример того, как могут выглядеть собранные вместе компоненты 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 возможности совместной работы позволяют множеству людей работать над одной бизнес-моделью, невзирая на географическую удаленность. Формируется виртуальная команда: вне зависимости от того, где находятся эксперты, они совместно участвуют в создании и согласовании новых схем бизнеса, бизнес-правил, способов измерения эффективности.
Все члены команды имеют дело с одними и теми же моделями и одной и той же информацией – это очень важное преимущество перед традиционными подходами к проектированию бизнеса и корпоративных систем. Каждый, кого могут затронуть изменения, имеет возможность принять участие в определении схемы будущих операций. Это задает совершенно иную динамику. Становится реальным осуществлять все изменения вместе с людьми, а не над ними.
Кроме того, графические модели намного легче воспринимать, чем традиционные спецификации в виде текстов и списков. Их можно быстро рассмотреть на любом уровне детализации, и каждая группа может выбрать оптимальный для себя уровень детализации. Это значительно стимулирует желание людей участвовать в работе и снижает затраты их времени на участие в проекте.
В то же время могут возникать определенные сложности в силу новизны возможностей, предоставляемых BPMS, для многих людей в компании. Меняются политики, состав участников и приложений. Международной компании следует принимать во внимание особенности местных законодательств и организовать доступ к системе командам из разных стран в режиме 24/7. К тому же если компания планирует предлагать свою продукцию на различных рынках, то эти вопросы придется решать в любом случае. BPMS позволяет собрать соответствующую информацию и использовать ее там, где это необходимо. Таким образом, BPMS облегчает экспансию бренда.
10.4.4. Недооцененные возможности
Основной проблемой использования систем BPMS в прошлом было то, что их редко рассматривали в качестве операционной среды и редко обращали внимание на архитектуру. Большинство организаций применяли BPMS ограниченно, для решения частных задач. Единые политики в части использования BPMS и корпоративного BPM обычно отсутствовали.
