среда, 13 января 2010 г.

Организация сложных BPMN моделей, by Bruce Silver

BPMS Watch: Organizing Complex BPMN Models

By: Bruce Silver, Principal, Bruce Silver Associates

Thursday February 28, 2008
Когда вы начинаете моделировать первые процессы в BPMN, вы видите сложности самой нотации - все типы сообщений, шаблоны контролирования потока, шаблоны обработки исключений, правила потоков выполнения и потоков сообщений. После небольшого обучения и практики, правила и шаблоны диаграмм быстро становятся второй природой, и эта часть моделирования требует все меньше усилий. Но когда вы начинаете применять ваши умения для отображения конечных бизнес-процессов вашей компании, неизбежно обнаруживается новая проблема - управление сложностью моделей. Модели реального мира не похожи на простые упражнения, которыми вы занимались в классе. Они расширяются на множество листов диаграмм, глубоко вложенные иерархии, и множество ссылок нескольких независимых BPMN процессов. Они могут включать множественные ссылки на одну и ту же задачу или подпроцесс, а для удобства обслуживания и управления высокого уровня подпроцессы могут быть объявлены в разных файлах.
В моем курсе Моделирование Процессов в BPMN, предлагаемом через BPM Institute и в интернет на BPMessentials.com, я раньше избегал этой темы, не желая пугать студентов существующими неврозами о использовании событий и потоках исключений. Но как только выпускники заканчивают обучение и приступают к реальным процессам своих компаний, становится понятно что избежать борьбы со сложностью не получится. Так что теперь, в дополнение к советам, каждый моделирующий процессы должен знать (смотрите Десять советов по эффективному моделирования процессов), мы завершим обучение практическим опытом организации сложных моделей реального мира. Далее резюме.

Ключевой принцип BPM как дисциплины управления - это понимание бизнес-процесса как единой конечной сущности, так что мы изучаем методологию в которой весь процесс охватывается на очень высоком уровне диаграммой на одной странице. Эта высокоуровневая диаграмма включает не только грубый вид оркестровки (последовательного потока) вашего процесса, но и абстрактное представление внешних сущностей, взаимодействующих с вашим процессом, таких как запрашивающие стороны (requesters), провайдеры услуг (service providers), источники нежелательных событий, и точки соприкосновения между вашим процессом и другими субъектами, называемая хореографией.
BPMN предоставляет контейнеры для представления каждой такой сущности или процесса, называемые пулами (рools), внутренней или внешней, и все пулы представляющие ваш завершенный процесс должны быть представлены на верхнем уровне диаграммы. Внешние сущности обычно изображаются в виде пула 'черного ящика' – пустые внутри, т.к. вы не знаете и не контролируете их внутренности. Внутренние пулы – ваши собственные процессы – изображающиеся в виде белых прямоугольников потока, показывая оркестровку. Взаимодействия между пулами отображается в виде пунктирных линий называющихся потоком сообщений и представляющих все запросы, ответы и нежелательные события, использующиеся для синхронизации различных сущностей бизнес-процесса.
Цель диаграммы верхнего уровня не показать как работает ваш процесс, а показать как все элементы сквозного процесса работают вместе. Со всеми пулами и потоками сообщений, нужна будет целая комната а не страница, чтобы предоставить более подробную информацию о том что происходит внутри вашего процесса. Это подробно представлено на других листах вашей диаграммы, каждый их которых представляет расширенный вид одного из подпроцессов в диаграмме верхнего уровня, опять же в идеале на одной странице. Эти дочерние диаграммы могут содержать другие подпроцессы, которые также подробно излагаются на своих дочерних диаграммах. Когда сквозной процесс представлен на необходимом уровне детализации, необходимой для моделирования и реализации, вы заканчиваете многоуровневой моделью из множества взаимосвязанных диаграмм.
Каждый инструмент моделирования имеет свой собственный механизм совместного хранения взаимосвязанных элементов. Некоторые используют встроенное хранилище. Тот что мы используем в нашем курсе обычно поддерживает их в виде отдельных листов в одном файле Visio. Каждый лист представляет то что инструмент называет как уровень процесса (Рисунок 1). (События BPMN Link позволяют расширить один уровень процесса на несколько листов, но наша методика запрещает их использование.) Сквозная модель может продолжаться на несколько уровней вложенности. Подпроцесс отображаемых в свернутом виде – как одна деятельность – на родительском уровне может быть расширена в своей собственной диаграмме процесса на уровне ниже. Наш инструмент поддерживает моделирование сверху-вниз при помощи создания и именования дочерних уровней процесса в один клик из свернутого подпроцесса. Подпроцессы могут также использоваться множество раз на одной модели при помощи ссылок, показываемых пунктирными линиями ссылок, как показано на Рисунке 1.

Рисунок 1. Сквозные BPMN модели разбросанные на нескольких вложенных уровнях
Завершенные модели построенные по такому способу могут распространяться на 10 и более листов одного файла Visio. Для управления навигацией, мы рекомендует такое соглашение по именованию в котором имя листа это имя подпроцесса (или пула, для диаграмм верхнего уровня) соединенное с дочерним уровнем вложенности в скобках, например (0) для верхнего уровня, и т.д.. Для действительно сложных моделей, вы можете предпочесть управление подпроцессами в отдельных файлах, которые позволяют более гибкую уровень обслуживания.
Читабельность и трассируемость сверху вниз имеют исключительно важное значение, в том числе для хореографии. Мы рекомендуем также показывать поток сообщений с верхнего уровня до самого нижнего, где он только встречается, что означает воспроизведение внешних пулов и потоков сообщений в дочерних диаграммах.
Обычно ваш процесс начинается с некоторого вида запроса от внешнего субъекта. Это не всегда запрос через веб службу, а возможно также входящий звонок в колл центр или реакция на входящую почту. И как правило реакция включает некоторый вид ответа на запрос, например уведомление о подтверждении или отказе. Лучший способ - это показать все эти взаимодействия в диаграмме верхнего уровня, даже если подробная деятельность, посылающая ответ, может быть определена в глубоко вложенных уровнях.
Это часто требует распространения работы по формированию ответа подтверждения или провала от источника запроса далеко вглубь, вплоть до самого нижнего, с последующим возвратом в самый верх для отправки ответа. BPMN позволяет вам это сделать. Успешное завершение подпроцесса на вложенном уровне N возвращает нормальный поток событий из свернутого подпроцесса на уровне N-1. С другой стороны, ошибка завершения события на вложенном уровне N посылает сигнал о том, что получена ошибка на уровне подпроцесса N-1. Поток исключения из присоединенного события может перейти к другой ошибке или событию, которая вызовет повторное событие исключения, произошедшее на уровне N-2. Будь то успешное завершение подпроцесса или произошедшая ошибка throw-catch, такое распространение можно повторить однажды на одном уровне пока не будет достигнут уровень 0, из которого отправляется ответ на запрос.
Рисунки 2 и 3 показывают как все элементы процесса работают вместе. На верхнем уровне диаграмма имеет внутренний процесс, который называется MyMain, нарисованный как белое поле пула, и черное поле пула представляющего инициатора процесса, провайдера услуги, и другого внутреннего пула отмеченного MyIndependent Subprocess. Последний изображен как черный ящик, т.к. объявлен в отдельном файле Visio. С другой стороны, я мог бы сделать его белым и определить в другой диаграмме верхнего уровня основного файла Visio.

Рисунок 2. Диаграмма верхнего уровня, показывающая все пулы и хореографию

Рисунок 3. Исключения на дочерних уровнях следует распространять на верхний уровень, для того чтобы вернуть ответ
Заметим, что процесс запроса и обоих ответов успешного и неудачного, отправляется из диаграммы верхнего уровня, даже в том случае когда источник сбоя, помеченный Invalid Data, происходит на некотором глубоко вложенном уровне 2 или выше. Это исключение распространяется на уровень 1, присоединенное событие ошибки на B1, и отсюда до уровня 0, присоединенное событие ошибки на B. На уровне 0, поток исключение приводит к сообщению ошибки, которое возвращается отправителю.
Отметим также на уровне 1 хореография между деятельностью названной MyIndependent Subprocess и отдельным пулом с тем же называнием. Это сделано для того, чтобы управлять подпроцессом в отдельном файле. Если мы оставим его в том же фале Visio мы сможем просто расширить MyIndep Subprocess на новый уровень процесса. Это проще, но при этом мы теряем возможности независимого хранения файлов.
Каждая организация должна разработать свои собственные соглашения для управления сложными моделями. Они будут зависеть от используемых инструментов и природы самой сложности. Кроме самой установки соглашений не менее важно научить их последовательному использованию всех людей, вовлеченных в процесс сквозного моделированию. Изучение базовых шаблонов диаграмм - это хорошая стартовая точка, но как только вы начинаете моделировать на BPMN реальность, управление сложностью становится большой проблемой.
Bruce Silver (bruce[at]brsilver.com) is an independent industry analyst covering BPMS technology and the author of the 2006 BPMS Report series on bpminstitute.org."

Комментариев нет:

Отправить комментарий