Термин “процесс” многозначен и в зависимости от контекста может означать очень разные вещи. Это создает сложность для тех, кто начинает изучать 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 незаменим, так как позволяет сделать схему взаимодействия участников процесса явной и одинаково трактуемой всеми заинтересованными сторонами - руководством, бизнес-подразделениями и “процессными технологами” (в том числе ИТ-специалистами), задача которых - воплотить эту схему в жизнь.

Часто приходится видеть диаграммы BPMN, в которых используются задачи на отправку (send task), чтобы показать, что мы отправили документы во внешнюю организацию, а задачи на получение (receive task) – чтобы смоделировать получение ответа. Или, что практически то же самое, используются события send message, receive message. » читать дальше

Вы сильно упростите себе работу над BPMN диаграммами и одновременно сделаете их более простыми и понятными, если примете следующие допущения:

1. Вся информация сохраняется
2. У организации есть механизм назначения и передачи поручений
3. К каждой задаче прилагается инструкция
4. У задач есть нормативные сроки, а у организации - механизм их контроля

1. Вся информация сохраняется

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

Тексты на тему BPMS в первую очередь акцентируют внимание на бизнес-процессах: схемы, нотации, оркестровка и хореография… Во вторую очередь внимание обычно уделяется разработке экранных форм к шагам процесса и функциональности пользовательского портала. Еще дальше на периферии – бизнес-правила и интеграция. И совсем не в фокусе обычно оказывается моделирование данных на этапе разработки и манипулирование данными в ходе исполнения процесса.

Между тем схема процесса и схема данных – это два ключевых аспекта архитектуры любого процессного приложения, а моделирование процессов и моделирование данных являются для процессного инженера ключевыми компетенциями. Причем не только ключевыми, но и равноправными. » читать дальше

Недавний опрос на ebizQ «What is the most important question to ask when starting a BPM project?» собрал рекордное число откликов. При этом Питер не уточнил роль – какая сторона задает вопрос? Поскольку большинство активных участников (писателей) форума – BPM-вендоры или консультанты, то вопрос они формулировали так, как бы они его задали потенциальному клиенту. Большинство сошлось на том, что самые главные вопросы – о контексте, целях и метриках успеха проекта BPM, (с чем я полностью согласен).

Но давайте оборотимся на себя: какой самый сложный вопрос потенциальный клиент может задать BPM-вендору?

Для меня самый сложный вопрос – «Что я с этого буду иметь?»

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

Еще не процесс

Продолжая тему предыдущего поста, является ли бизнес-процессом “Добыча нефти” или “Продвижение нового продукта”?

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

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

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

По-видимому надо принять как данность, что единого определения бизнес-процесса нет и не будет. И не имеет смысла навязывать единственно верное определение. Я этого делать и не буду, а всего лишь попытаюсь объяснить, что лично я понимаю под термином “бизнес-процесс”.

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

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

Рассмотрим в качестве примера процесс заключения договора, состоящий из трех фаз:

1. согласование содержательных условий договора
2. согласование текста договора
3. подписание договора

Зачастую приходится встречать наивные процессные диаграммы типа следующей:

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

К сожалению, вопрос “как в BPMN моделировать решения, принимаемые людьми” не относится к числу часто задаваемых.

“К сожалению” потому, что ответ, который новичку кажется очевидным, на самом деле неправилен. Это вот не развилка, это распараллеливание процесса:

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

Правильная BPMN-диаграмма выглядит так:

При этом подразумевается, что у процесса есть атрибут “Одобрено” типа boolean. Пользователь на шаге “Рассмотреть заявку” задает значение этого атрибута, а в развилке оно проверяется, и процесс продолжается по одной из ветвей.

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

Пользовательский интерфейс для шага, на котором принимается решение, выглядит примерно так:

По кнопке “Выполнено” форма закрывается, и задача считается выполненной.

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

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

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

Здесь к существующим типам потока управления Control Flow, Conditional Flow и Uncontrolled Flow добавлен еще один: Human Controlled Flow, помеченный двойной поперечной черточкой.

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

Если от человека требуют принять решение, то форма должна выглядеть так:

Кнопки можно было бы создавать автоматически исходя из приведенной выше диаграммы.

Впрочем, такой подход можно ведь практиковать и для стандартных BPMN-диаграмм:

Нужно убрать кнопку “Выполнено”, а вместо нее добавить кнопки “Одобрить” и “Отказать”, привязав к каждой по два действия: присвоить значение атрибуту и завершить задачу.

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

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

Фактически речь идет о двух способах решения задач:

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

Какое-то мутноватое получается объяснение, не так ли? Добавляет путаницы то, что английские “template” и “pattern” зачастую оба переводят как “шаблон”, и смысл при этом частично теряется.

Думая о том, как это можно объяснить “на пальцах”, нашел аналогию в шахматах:

• Дебюты из шахматных учебников - это шаблоны: учи и разыгрывай, в учебнике все расписано от стартовой позиции и на 20 ходов вперед.
• Типовые комбинации миттельшпиля - это паттерны. Например, “вилка” - это паттерн: увидел в позиции возможность ее сделать - делай, или угрожай, что сделаешь. Сдвоенные по вертикали ладьи - это паттерн, а сдвоенные пешки - это антипаттерн: если есть возможность, старайся избегать таких позиций. Но в учебнике нет и не может быть инструкции как, начав партию, сделать противнику вилку.

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

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

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

Паттерны в BPM - это типовые фрагменты процессов или межпроцессного взаимодействия (некоторые примеры).

Уместно спросить: от чего больше пользы? Мое мнение - от паттернов:

• Шаблоны специфичны (один процесс - один шаблон), паттерны универсальны. Хороший паттерн можно использовать в самых разных бизнес-процессах независимо от отраслевой специфики.
• Польза от шаблона на практике оказывается меньше ожидаемой. Как правило, позаимствовать удается только магистральный путь (happy path), а дьявол оказывается в деталях - в обходных путях, в обработке нештатных ситуаций.
• Эффект от использования правильного паттерна может быть очень большим. Например, в нашей практике был случай, когда процесс, изображенный на 6 склеенных друг с другом листах формата А4, за счет использования правильного паттерна удалось свести к изящной конструкции из 15 процессных шагов.
• Что касается антипаттерна, его польза в том, что в нужный момент он предостережет вас от ошибки. Цена ошибки теоретически может быть любой, и иногда реально большой.

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