Десять советов для эффективного моделирования процессов, by Bruce Silver

BPMS Watch: Ten Tips for Effective Process Modeling

By: Bruce Silver, Principal, Bruce Silver Associates
Wednesday January 30, 2008
Спецификация BPMN содержит множество технических определений и правил, но не учит вас тому как создаются модели процессов, которые были бы эффективны в своей первоначальной задаче - максимизации общего понимания того как происходит процесс сейчас (as-is) и каким он должен быть (to-be). Чтобы сделать процесс моделирования эффективным, нужно выйти за рамки спецификации и изучить базовые методологии, передовой опыт, и специфические шаблоны диаграмм для использования в общих ситуациях. Это то чему мы учим в нашем курсе 'Моделирование процессов в BPMN', доступном в онлайн на BPMEssentials.com в открытых классах и на событиях BPM Institute. Для иллюстрации этой точки зрения приведу десять советов для эффективного моделирования в BPMN.

1. Покажите на диаграмме логику процесса. Это абсолютно фундаментальный совет, но те кто только начинает моделировать его обычно игнорируют . Спецификация BPMN описывает различные фигуры и коннекторы, которые отображаются на диаграмме, а также дополнительные детали в атрибутах, видимые только через инструмент моделирования или в подробной документации, которая может быть получена с помощью этого инструмента. Но максимизации общего понимания приходит не от частных лиц, изучающих ваши модели с помощью этого инструмента, ни копанием в сотнях страниц документации. Понимание приходит от группы сидящих за столом и смотрящих на распечатку диаграммы, ее обсуждения, и размышлений о том, как его еще можно улучшить.
   
   Фактически это означает две вещи: Первая - подписи везде в диаграмме - не только деятельности, но и подпроцессы, промежуточные события, шлюзы, последовательность потоков, событий и потоков сообщений. Некоторые требуемые атрибуты, такие как продолжительность события таймера, могут не отображаться на диаграмме. Если нет - добавьте подпись к событию, которое воспроизводит эту информацию. Если вы не видите это на диаграмме - это не реально рассчитать.
   
   Во-вторых, покажите логику обработки исключений прямо на диаграмме. В отличие от многих традиционных нотаций, BPMN предоставляет вам эти инструменты, даже если вы не являетесь разработчиком.
   
   
2. Делайте ваши модели валидными. При том что диаграмма это ключевой выход, модель процесса это больше чем рисунок, и инструмент моделирования это больше чем инструмент для рисования. Настоящий инструмент моделирования содержит семантику и правила BPMN, и дает вам кнопку проверки, которая может показать список ошибок когда вы нарушаете спецификацию. Бесплатный BPMN шаблон Visio этого не делает. Если вы хотите чтобы остальные понимали ваши модели, вам необходимо сначала сделать их валидными, так что вы должны использовать кнопку валидации и научится исправлять ошибки.
   
   
3. Делайте ваши модели иерархическими. То что отличает BPM от традиционных дисциплин управления это его акцент на просмотр бизнеса с кросс-функциональной сквозной перспективы. Фиксирование процессов на плоских моделях, занимающих тридцать футов стены не позволяет понять сквозную перспективу со всех точек зрения. Вместо этого, мы учим методологии сверху-вниз, в которой высокоуровневая диаграмма показывает процесс целиком на одной странице, и использует подпроцессы для расширения детализации процесса на вложенных уровнях диаграмм, так что вы можете увеличивать или уменьшать вашу модель до любого уровня детализации. Его можно распечатать на нескольких страницах, но поддерживается внутренняя целостность единой модели процесса.
   
   
4. Подписывайте деятельности процесса глаголами. BPMN описывает процессы в терминах потока деятельностей, где деятельности буквально означают действия. Они представляют работу выполняемую в процессе. Деятельности это не состояния, не бизнес функции, не используйте случаи взаимодействия. Для усиления этого, мы просим студентов соответственно именовать их деятельности с глагольных конструкций, таких как Проверить Кредит или Подтвердить Заказ, не Проверка Кредита (функция) или Подтвержденный Заказ(состояние). Ресурсы идут для выполнения каждой деятельности, и имя деятельности должно описывать действие, которое она производит.
   
   
5. Укажите типы задач. Тип задачи - это один из атрибутов BPMN, который не имеет стандартизированного представления на диаграмме. Спецификация определяет несколько целевых видов, но в действительности важно различать только две из них: пользователя (задачи человека) и услуги (автоматизированной задачи). К счастью, большинство инструментов BPMN позволяют отличить типы задач по иконкам внутри элементов деятельностей… но вы должны явно указывать какой тип имеется в виду.
   
   
6. Не используйте задачу для управления работой. Еще одна распространенная ошибка начинающих - вставка задач типа Отправить Менеджеру, после чего поток направляется с дорожку (swimlane) менеджера. Это направление потока уже направляется менеджеру, так что задача Отправить Менеджеру просто лишняя. Просто избавьтесь от нее.
   
   Здесь также есть вторая проблема. Передовой опыт в том, чтобы оставить ключевые слова 'Отправить' и 'Получить' ('Send' and 'Receive') для именования задач типов отсылки, которые эквивалентны сообщениям событий. В BPMN 'сообщение' означает сигнал между процессом и некоторой внешней сущностью. Здесь менеджер не внешняя сущность, а участник процесса. Так что это просто не сообщение и не должно быть помечено как Отправить. Если вы хотите общаться с менеджером без перенаправления самой работы просто используйте задачу Оповестить Менеджера. На практике это может показаться сначала мелочью, но в конце концов так будет проще для всех в вашей компании - сразу понять из диаграммы что же здесь происходит.
   
   
7. Различие успешного завершения или сбой показывается в подпроцессе в виде отдельных событий завершения. Каждый возможный путь в подпроцессе должен завершиться событием перед завершением подпроцесса. Вы можете использовать единственное событие окончания для подпроцесса и все маршруты сводить к нему, или вы можете использовать несколько событий окончания и конкретные пути для каждого из них. Поскольку подразумевается что они все будут объединены, технически это не важно. Но есть некоторая выгода в подготовке и маркировке различных событий заверения для каждого конечного состояния подпроцесса, особенно если конечное состояние представляет собой 'успех' и друге 'провал' или другого типа исключения.
   
   Вы можете следить за подпроцессами с помощью шлюзов, проверяющих состояния завершения чтобы продолжить процесс или сделать что-либо еще, например завершить или вернуться на предыдущий шаг. Соответствующая подпись для шлюза сделает эту связь в диаграмме прозрачной. С другой стороны, событие окончания на пути исключения внутри подпроцесса может повторно генерировать исключение, которое оказалось вложено в границе подпроцесса. Это также может прекратить процесс или направить поток по некоторому пути обработки ошибки. И снова соответствующие подписи вызова и отслеживания событий исключений делает связи на диаграмме очевидными.
   
   
8. Используйте подпроцессы для области присоединенных событий. Промежуточные события присоединенные к процессной деятельности означают, что если событие вызвано пока запущена деятельность, прекращение деятельности и продолжение потока процесса из события, вызванного потоком исключения. Хороший трюк обернуть последовательность действий в подпроцесс с единственной целью определения этой области для события. Например, если у вас есть порядок обработки процесса в шагами от A до Z и вы хотите позволить клиенту отменить или изменить заказ без штрафных санкций в любое время между шагами B и G, вы можете обернуть последовательность от B до G в подпроцесс и присоединить событие сообщения а таким образом обработать поток исключения.
   
   
9. Стандартизировать на конкретных диаграммах шаблоны для различных типов исключений. BPMN предоставляет дружественную бизнесу нотацию для описания поведения обработки исключений. Несмотря на то, что спецификация BPMN предоставляет большую свободу средству моделирования, лучший опыт заключается в том, чтобы изучить конкретные диаграммы шаблоны для отличий каждого типа исключений и использовать их последовательно. Например, в нашем курсе, мы даем различные шаблоны для моделирования внутренних исключений бизнес-процессов, системных сбоев, таймаутов, исключения ответы на запрос, нежелательные события, и другие. Опять же, ключевой принцип это понять что имеется в виду только при помощи самой диаграммы.
   
   
10. Используйте согласованный поток сообщений чтобы показать бизнес-контекст. В дополнение к потоку деятельности ваших процессов, BPMN позволяет вам показать взаимодействие между вашим процессом и внешним процессом как пунктирное соединение называемое потоком сообщений. Потоки сообщений обычно представляют обмен с внешним процессом при помощи запросов, ответов и нежелательные событий. В ваших собственных процессах, поток сообщений присоединен к конкретным деятельностям и события отвечающим как именно ваш процесс отвечает на входящий поток сообщений или генерирует исходящий поток. Поскольку вы не контролируете и даже не знаете внутренности внешнего процесса, поток сообщений просто присоединяется к границе пула представляющего этот процесс.
    
    Потоки сообщений могут добавить ценный бизнес-контекст к вашей диаграмме, но важно использовать их последовательно. Например, если вы собираетесь показать все потоки сообщений и к запрашивающему ваш процесс, вы действительно должны показать все из них которые последовательно на каждом уровне вашем модели. То есть, если частный поток сообщений показан во вложенном подпроцессе на третьем уровне, он должен быть также показан на диаграмме верхнего уровня и отмечен на каждом из уровней.

Ни один из этих десяти советов не рекомендуется спецификацией 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. "

ИТ блокнот /Николай Войнов/