|
|||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
Литература: Автор: 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-система для того, чтобы быть системой масштаба предприятия. Комментарии |
|||||||||||||||||||||||||||
Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | |||||||||||||||||||||||||||
|
Подскажите, как Владельцу процесса влиять на этап разработки или интеграции? Если модель создана, а реальная среда не позволяет ее интегрировать?
Известно как влиять - административными методами. Если Вы владелец процесса, то, по определению, в Вашем распоряжении должны быть какие-то ресурсы.
А статья по-моему не слишком глубокая. Во-первых, роли опредеяются на входе в цикл - крайне сомнительно. Во-вторых, отсутствует "малый цикл": до начала полновесной разработки процесс должен пройти несколько кругов моделирования и быстрого прототипирования.
Согласна с Анатолием. По поводу цикла есть о чем поспорить. По существу, описанное напоминает традиционную разработку - нет той изюминки, которая отличает BPM-подход. К примеру, стадия 7 - передача в эксплуатацию - происходит только после того, как полностью выполнен промышленный вариант. Но с практической точки зрения выполнять, скажем, интеграцию, целесообразно только тогда, когда процесс уже приживется и места стыковки будут не только обозначены архитектором, но подтверждены жизненной необходимостью. Иначе возникает угроза того, что дорогостоящая, ресурсоемкая работа может оказаться напрасной, если в реальной жизни процесс не приживется.
Без сомнения, существуют большой и мылый цикл разработки. Малый - этап прототипирования, который позволяет достичь результата в короткие сроки и малыми затратами. Дальше - запуск в реальную жизнь "полупромышленного" варианта - часть ввода информации в систему или часть действий пока остаются ручными, но уже можно собирать статистику и оценивать процесс с точки зрения эффективности. И только тогда, когда это заработает, можно приступать к промышленной разработке.
Данный подход имеет неудобство - сотрудникам придется вводить информацию вручную, без справочников и прочих удобств (недолго, кстати!). Но здесь надо разъяснять, что преимущества такого подхода и экономия средств на лишней разработке - это выгода для организации (которая, между прочим, может стать и прямой выгодой для сотрудников в виде поощрений). Кстати, разъяснительная работа - это тоже часть методологии BPM - помните?
Александр, по первой части вопроса: что Вы понимаете пов выражением "влиять на этап разработки"? Владелец поставил задачу и имеет право ожидать адекватного резутьтата. Если результат не удовлетворяет - изучать переданную программистам схему процесса, смотреть - что не так понято и в чем причина. Подразумевается ведь, что схема передается уже рабрчая? Программист ничего не выдумывает? Или мы о разном говорим?
Вторая часть вопроса не совсем понятна - что означает "модель создана, а реальная среда не позволяет интегрировать"? Архитектор создает модель, не отвечающую реальным условиям? Как такое может получиться?
Может быть я чего-то не понял, но как мне показалось явтор привёл именно список стадий, входящих в жизненный цикл BPM без указания на какую-либо определённую последовательность этих стадий. Просто - список.
Дмитрий, обратите внимание на рисунок в начале статьи.