Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Записи с ключевым словом ‘BPMN’

Необходимые и избыточные элементы BPMN: события

В прошлой заметке мы выяснили, что при всем многообразии развилок в BPMN, строго необходимыми являются две из пяти: “или/или” и “и”.

Перейдем к событиям. События в BPMN классифицируются по типу (13 вариантов) и по месту (8 вариантов). Рассмотрим классификацию по типам:

1. Простое событие

» читать дальше

Тонкий слой под названием “процесс”

Как это не парадоксально, но термин “процесс” остается самым неоднозначным в BPM - недавняя дискуссия на форуме BPM.com это наглядно демонстрирует.

  • Когда мы разрабатывали профстандарт, одно из рабочих вариантов названия было “Специалист по управлению процессами”. И на одном из обсуждений мы получили замечание: “Уточните, о каких процессах идет речь - процессами пищеварения вы собираетесь управлять?” В самом деле, на бытовом уровне мы процессами называем все что угодно, от пищеварения до образования галактик.
  • Среди консультантов по управлению распространен взгляд на процессы как на любую упорядоченную деятельность, нацеленную на получение определенного результата. В таком определении есть смысл - если в фокусе нашего внимания находится эффективность бизнеса, то для нас нет большой разницы между деятельностью в рамках функциональных подразделений, кросс-функциональных процессов или проектов. Но если погружаться в конкретику, то такое определение процесса становится непродуктивным: конечно, мы можем принять, что проект - это тоже процесс, просто нацеленный на однократный результат, но методы управления проектами и процессами ведь существенно разные, как ни крути. К слову, в последнее время для обозначения широкого спектра деятельности вместо термина “процесс” стали употреблять “бизнес-способность”. Мне этот термин нравится, поскольку позволяет объединить процессы и проекты, не сливая их в одно.
  • В контексте BPMN определение процесса сужается еще больше. Во-первых, в BPMN есть четкая разница между процессом и подпроцессом: первый инициируется внешним событием (сообщением, таймером или просто волевым решением), второй вызывается. Во-вторых, BPMN в упор не видит уровни выше отдельного процесса - такие сущности, как, например, “цепочка создания ценности”, “вспомогательные бизнес-процессы” или “продвижение продукции”. В BPMN нет средств для моделирования групп процессов.

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

См.также

Необходимые и избыточные элементы BPMN: развилки

Полная палитра BPMN включает сотни элементов (если считать все возможные комбинации). И хотя профессионал знать их должен все, не надо стремиться все их использовать.

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

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

Попробуем ответить на эти вопросы и показать, какие элементы абсолютно необходимы, а без каких можно обойтись, заменив их другими.

Начнем с развилок.

» читать дальше

Потоки сообщений, события-сообщения и задачи-сообщения

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

Опасно! Не пытайтесь повторить.

Я заметил, что те, кто обходятся задачами, развилкам и потоками управления, рисуют схемы более понятные и прямолинейные, чем те, кто в курсе существования сообщений. События-сообщения и задачи-сообщения похожи на автоматические задачи: они предназначены для процессных движков, а не для того, чтобы их обрабатывали люди.

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

Неправильно:
email через сообщение
Правильно: email через пользовательскую задачу
(ручной процесс)
Правильно: email через задачу-сценарий
(процесс, реализованный в BPMS)

Если вам надо показать, что какая-то задача взаимодействует с внешним миром (например, с заказчиком или поставщиком), то можно использовать пул - черный ящик и сообщения, прикрепленные непосредственно к задаче:

Но лучше не засорять диаграмму потоками сообщений и черными ящиками. Ведь если задача называется “Get customer’s commitment”, то и так понятно, что она взаимодействует с клиентом:

Использование черных ящиков и сообщений имеет смысл только в одном случае: если вам надо отобразить ВСЕ сообщения, входящие в / исходящие от внешнего контрагента, чтобы специфицировать “коммуникационный контракт” с ним.

И завершая эту заметку,- о различиях между событиями-сообщениями и задачами-сообщениями: их основные функции тождественны; небольшое различие проистекает из общего различия между событиями и задачами. К последним можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), что иногда бывает удобно:

BPMN с ручным приводом

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

В качестве примера, исполнитель A должен передать эстафетную палочку либо B, либо C в зависимости от результатов выполнения назначенной ему задачи Task 1:

Исполнитель A должен отдавать себе отчет, что он отвечает за исполнение не только задачи, но и следующей за ней развилкой “или-или”. Он должен знать и понимать что означает следующий элемент и как его обрабатывать. В примере выше это достаточно очевидно - догадаться, что это развилка, способен каждый - но другие элементы BPMN не столь очевидны.

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

Задачи на вызов сервиса, задачи на выполнение сценария? Забудьте, они вам не понадобятся; автоматическая процедура, запускаемая пользователем - это пользовательская задача, а не сценарий или сервис.

Элементы BPMN, которые можно рекомендовать для использования в процессах, которые будут исполняться без движка:

  • пулы и дорожки
  • объекты данных, хранилища данных, потоки данных
  • аннотации и ассоциации
  • потоки управления и потоки сообщений
  • задачи: пользовательские и ручные; никаких сценариев, сервисов, бизнес-правил, отправки и получения сообщений
  • цикл по объектам необходим; стандартный цикл избыточен и поэтому не рекомендуется
  • подпроцессы: встроенные и повторно-используемые, только свернутые (развернутые не рекомендуются), “по требованию”; подпроцессы-обработчики избыточны, сложны и поэтому не рекомендуются
  • развилки: “или-или”, “и”; никаких комплексных и по событиям; развилки “и/или” избыточны и нетривиальны и поэтому не рекомедованы
  • события: простое, таймер, сообщение (включая прикрепленные прерывающие и непрерывающие), останов, ошибка
  • полностью за рамками: транзакция, компенсация, отмена

Дополнено: задачи-сообщения и события сообщения лучше оставить за рамками сокращенной палитры. Подробнее о сообщениях в BPMN >>

Как видим, лишь небольшое число элементов BPMN пригодны для использования в схемах процессов, которые будут исполняться вручную.

С другой стороны, поразительно как много можно смоделировать даже со столь ограниченной палитрой. Чем более профессиональны вы в BPMN, тем меньше элементов вы используете на постоянной основе.

Процессные паттерны: планирование-исполнение (четыре варианта)

Некая организация живет по плану: на регулярной основе планы составляются, затем пункты плана выполняются.

1. Антипаттерн: планирование и исполнение в одном процессе

Проблема этой диаграммы в том, что планирование длится, пока не будут выполнены все пункты плана. » читать дальше

Что является процессом в BPMN (и что не является)

Термин “процесс” многозначен и в зависимости от контекста может означать очень разные вещи. Это создает сложность для тех, кто начинает изучать BPMN. В помощь им эта краткая заметка.

1. Процесс BPMN повторяем

Не является процессом в понимании BPMN, например “Ликвидация компании”, так как он исполняется лишь один раз. (Конечно если вы не специализируетесь на предоставлении услуг в этой области.)

2. Процесс BPMN предсказуем

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

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

Такие последовательности действий, развивающиеся по непредсказуемым наперед сценариям, в зависимости от контекста следует трактовать как проекты или кейсы.

3. Процесс BPMN нетривиален

Если вы не можете декомпозировать процесс на несколько задач, то это, с точки зрения BPMN, не процесс. Процесс состоит из множества связанных задач и/или подпроцессов, т.е. не атомарен.

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

4. Процесс BPMN конкретен

У процесса BPMN есть четко определенное стартовое событие, заранее определенная цепочка действий и определенные варианты завершения.

Не является процессом в понимании BPMN, например, “Бюджетный процесс”. С точки зрения BPMN, это несколько процессов (утверждение бюджета, отчетность по исполнению бюджета) плюс несколько задач, являющихся частью “чужих” процессов,  например, задача “Проверить наличия бюджета” в процессе “Закупка”.

Аналогично, “Продвижение продукции” с точки зрения BPMN - это не процесс, а семейство родственных процессов. Также не процессом, а семейством процесса являются вещи с названием “Управление чем-то”.

5. Процесс BPMN дискретен

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

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

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

6. Входы и выходы процесса BPMN - это, в первую очередь, события

Распространенным является взгляд на процесс как на нечто перерабатывающее входы в выходы. В такой трактовке входы и выходы - это ресурсы.

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

Старт процесса - это всегда обработчик события, происходящего вовне, завершение - это инициатор события во внешней среде. В частном, но распространенном случае, событие может быть т.н. “пустым” (None Event), т.е. “волюнтаристским” на старте процесса или “никаким” на его завершении.

7. Процесс BPMN - это история объекта, а не субъекта

Не пытайтесь моделировать в BPMN процессы типа “Рабочий день сотрудника”.

Правильный подход - процессы типа “Прохождение клиентской заявки”.

8. Процесс BPMN не завершается, пока не выполнена вся работа

Процесс в BPMN стартует тогда, когда нам пришло в голову выполнить некую последовательность действий или когда нас на это сподвигло внешнее событие (например, клиентский заказ), и не завершается до самого конца, т.е. пока еще есть что делать (например, до завершающего звонка клиенту после отгрузки в рамках контроля качества сервиса).

“Здесь у нас процесс продажи заканчивается и начинается процесс бухгалтерии” - плохая идея, в данном случае налицо один кроссфункциональный процесс, а не два отдельных.

9. Процесс BPMN клиенто-ориентирован

Рассматривайте процесс как сквозной, ориентируйтесь не на границы между подразделениями, а на взгляд заказчика (в идеале - внешнего клиента): начните с исходного обращения заказчика и доведите процесс до выдачи заказчику ценного для него результата.

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

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

10. Процесс BPMN - это не микро, а макро-менеджмент

Использовать BPMN для детальной регламентации деятельности на одном рабочем месте возможно, но любим мы его не за это. Если сотрудники не обучены, то это конечно проблема, но это не процессная, а функциональная проблема. И для нее существует масса решений помимо BPMN.

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

В решении подобных проблем BPMN незаменим, так как позволяет сделать схему взаимодействия участников процесса явной и одинаково трактуемой всеми заинтересованными сторонами - руководством, бизнес-подразделениями и “процессными технологами” (в том числе ИТ-специалистами), задача которых - воплотить эту схему в жизнь.

(English) Live Process Analysis & Modeling Experience

Этот контент доступен на языках: English.

Процессный паттерн: «Найдите жертву»

Какие только красоты не рисуют начинающие авторы, чтобы средствами BPMN показать взаимодействие с внешними участниками процесса!

Характерный пример:

Рис.1

Тут целый букет ошибок: » читать дальше

Расскажите историю

Периодически приходится видеть BPMN-диаграммы типа следующей:

BPMN-диаграмма процесса оплаты счетов, неправильно

Здесь изображен процесс «Оплата счетов», состоящий из взаимодействующих друг с другом «процесса бухгалтерии», «процесса финансового отдела бизнес-единицы» и «процесса финансового отдела концерна». » читать дальше

Copyright © 2008-2017 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии