Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


 
BPM на практике: жизненный цикл бизнес-процесса

Литература:

Автор: Rashid N. Khan 

Оригинал статьи: Practical BPM: The Business Process Lifecycle

Первая из двух частей колонки "BPM на практике", объясняющая, что такое жизненный цикл процесса.

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

Рисунок 1. Детальный взгляд на жизненный цикл процесса

Стадия 1: Определение ролей и связей

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

Стадия 2: Определение бизнес-процессов

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

Стадия 3: Моделирование и оптимизация бизнес-процессов

После того, как выявлены потребности и определены требования, бизнес-аналитик переводит их в серию заданий, которые необходимо выполнить для того, чтобы удовлетворить эти требования. Это детальный дизайн с точки зрения бизнеса. Бизнес-аналитик может также смоделировать процесс для того, чтобы убедиться, что эта модель позволит достигнуть требуемого результата. Такой порядок позволит сделать предположения об объеме заданий, стоимости каждого шага, наличии ресурсов и времени, необходимом для выполнения каждого шага. Цель – создание полного определения процесса с точки зрения бизнеса, чтобы убедиться, что процесс соответствует требованиям и ожиданиям его владельца.

Стадия 4: Разработка бизнес-процесса

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

Стадия 5: Интеграция с другими приложениями

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

Стадия 6: Установка и администрирование

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

Стадия 7: Исполнение процесса

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

Стадия 8: Отчеты

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

Стадия 9: Оптимизация

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

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

Стадии

Инструментарий

Роли

Определение ролей и связей

Организационная диаграмма

Владелец процесса

Определение процесса

Среда моделирования

Владелец процесса

Моделирование и оптимизация

Среда моделирования

Бизнес-аналитик

Разработка

Среда разработки

ИТ-разработчик

Интеграция

Среда разработки

Программист

Инсталляция

Среда администрирования

ИТ-администратор

Исполнение

Клинтское приложение

Участники процесса

Измерение

Отчеты

Бизнес-аналитик

Таблица 1. Жизненный цикл BPM

Бизнес-процесс имеет жизненный цикл, на протяжении которого различные категории людей взаимодействуют с этим процессом. Эти люди имеют разные навыки и поэтому требуются разные наборы инструментов, которые должна предоставить BPM-система для того, чтобы быть системой масштаба предприятия.

Комментарии
#1 Александр Тимченко, 13.12.2008 18:25

Подскажите, как Владельцу процесса влиять на этап разработки или интеграции? Если модель создана, а реальная среда не позволяет ее интегрировать?

#2 Анатолий Белайчук, 15.12.2008 12:18

Известно как влиять - административными методами. Если Вы владелец процесса, то, по определению, в Вашем распоряжении должны быть какие-то ресурсы.

#3 Анатолий Белайчук, 15.12.2008 12:23

А статья по-моему не слишком глубокая. Во-первых, роли опредеяются на входе в цикл - крайне сомнительно. Во-вторых, отсутствует "малый цикл": до начала полновесной разработки процесс должен пройти несколько кругов моделирования и быстрого прототипирования.

#4 Юлия Вагнер, 15.12.2008 18:30

Согласна с Анатолием. По поводу цикла есть о чем поспорить. По существу, описанное напоминает традиционную разработку - нет той изюминки, которая отличает BPM-подход. К примеру, стадия 7 - передача в эксплуатацию - происходит только после того, как полностью выполнен промышленный вариант. Но с практической точки зрения выполнять, скажем, интеграцию, целесообразно только тогда, когда процесс уже приживется и места стыковки будут не только обозначены архитектором, но подтверждены жизненной необходимостью. Иначе возникает угроза того, что дорогостоящая, ресурсоемкая работа может оказаться напрасной, если в реальной жизни процесс не приживется.
Без сомнения, существуют большой и мылый цикл разработки. Малый - этап прототипирования, который позволяет достичь результата в короткие сроки и малыми затратами. Дальше - запуск в реальную жизнь "полупромышленного" варианта - часть ввода информации в систему или часть действий пока остаются ручными, но уже можно собирать статистику и оценивать процесс с точки зрения эффективности. И только тогда, когда это заработает, можно приступать к промышленной разработке.
Данный подход имеет неудобство - сотрудникам придется вводить информацию вручную, без справочников и прочих удобств (недолго, кстати!). Но здесь надо разъяснять, что преимущества такого подхода и экономия средств на лишней разработке - это выгода для организации (которая, между прочим, может стать и прямой выгодой для сотрудников в виде поощрений). Кстати, разъяснительная работа - это тоже часть методологии BPM - помните?

#5 Юлия Вагнер, 15.12.2008 18:51

Александр, по первой части вопроса: что Вы понимаете пов выражением "влиять на этап разработки"? Владелец поставил задачу и имеет право ожидать адекватного резутьтата. Если результат не удовлетворяет - изучать переданную программистам схему процесса, смотреть - что не так понято и в чем причина. Подразумевается ведь, что схема передается уже рабрчая? Программист ничего не выдумывает? Или мы о разном говорим?

Вторая часть вопроса не совсем понятна - что означает "модель создана, а реальная среда не позволяет интегрировать"? Архитектор создает модель, не отвечающую реальным условиям? Как такое может получиться?

#6 Дмитрий Медведев, 22.01.2009 00:00

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

#7 Анатолий Белайчук, 22.01.2009 08:25

Дмитрий, обратите внимание на рисунок в начале статьи.

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права