Блог компании trinion

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

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

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

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

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

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

Пример 1

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

В самом начале исполнения процесса токен находится в точке входа. Далее мы начинаем его перемещать. Двигаться токен может только последовательно, переходя с этапа на этап процесса.

Таким образом, токен переходит на этап Создать документ Заявка на закупку товара. После успешного завершения этапа токен движется на этап Отправить заявку на согласование и т.д.

Если бы у нас не было такого элемента, как токен, мы бы не могли понять, где сейчас находится процесс.

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

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

В нашем случае после шлюза Заявка одобрена? получен ответ Да. И токен движется по соответствующей ветке. Финал работы точка выхода.

Пример 2

Для лучшего понимания рассмотрим тот же процесс. Но в этот раз после шлюза мы получили ответ Нет.

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

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

Пример 3

При работе с бизнес-процессом токенов может быть несколько, например, если выполняется две или более ветки процесса параллельно. Рассмотрим пример бизнес-процесса Согласование закупки.

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

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

Подведем итоги

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

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

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

Следуйте этим пунктам и составление бизнес-процесса пройдет быстро и без критических ошибок:

1. Получить список действий.

2. Определить исполнителей

3. Перевести действия в задачи.

4. Вычислить финалы процесса.

5. Назначить действия исполнителям.

6. Описать условия (шлюзы).

7. Описать внешние по отношению к процессу сущности.

8. Переложить описания в нотации.

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

Получить список действий

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

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

Как из описания сделать список действий

Давайте разберемся подробнее, как это сделать максимально быстро и корректно:

1. По итогам интервью составьте текстовое описание. Например:

При необходимости в товаре которого нет в наличии продавец создает документ Заявка на закупку и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и если закупщик разрешает закупить товар согласно документу Заявка на закупку, то продавец информируется о разрешении закупить товар, и закупщик создает документ Заказ поставщику. Иначе заявка аннулируется с комментарием содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара.

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

2. Уберите лишнее. Посмотрите на текст внимательно, избавьтесь от ненужных слов.

В приведенном примере убрать следует фразу которого нет на складе. Независимо от того, есть такой товар или нет, если возникает необходимость в товаре от поставщика, потребуетсяЗаявка на закупку.

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

3. Выделите действия. В том же примере я выделил их подчеркиванием:

При необходимости в товаре продавец создает документ Заявка на закупку и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и, если закупщик разрешает закупить товар согласно документу Заявка на закупку, то продавец информируется о разрешении закупить товар, и закупщик создает документ Заказ поставщику. Иначе заявка аннулируется с комментарием, содержащем причину отказа в закупке товара. Продавец информируется об отказе в закупке товара.

А как же вычислить действия? Обыкновенно - это глаголы. Все просто.

4. Создается список действий.

В приведенном примере он выглядит так:

1. Продавец создает документ Заявка на закупку

2. Закупщик проверяет необходимость в закупке данного товара

3. Если закупщик разрешает закупить товар

4. Продавец информируется о разрешении закупить товар

5. Закупщик создает документ Заказ поставщику

6. Иначе заявка аннулируется с комментарием

7. Продавец информируется об отказе в закупке.

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

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

Перевести действия в задачи

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

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

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

В BPMN такой возможности нет. Потому здесь задача должна быть самым простым действием. В этой нотации имеются подпроцессы (Sub-Process) или подзадачи (Sub-Task). Эти возможности мы будем рассматривать позже. Здесь и сейчас я говорю именно о задачах.

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

Назначить действия исполнителям

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

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

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

Вычислить финалы процесса

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

Например, это может быть Если необходимости в товаре нет, закупщик аннулирует заявку и отправляет уведомление продавцу.

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

Описать условия (шлюзы)

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

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

Эти условия в BPMN называются шлюзами. Их обязательно нужно предусмотреть и описать.

Описать внешние по отношению к процессу сущности

При описании любого бизнес-процесса вы столкнетесь с двумя типами сущностей:

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

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

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

Переложить описания в нотации

Вы собрали необходимую информацию, остается перенести ее в графический вид.

1. Задачи. Это прямоугольники с закругленными краями, внутри которых вы пишете название задачи.

2. Шлюзы. Условия выглядят ромбами. Разместите их на диаграмме.

3. Соедините между собой задачи и шлюзы стрелками.

4. Укажите список исполнителей, а также исполнителя для каждой задачи.

5. Сверху разместите внешний пул, т.е. все внешние сущности, и свяжите их с нужными задачами.

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

Взаимодействие диаграммы и описания диаграммы

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

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

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

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

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

Советы по описанию

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

1. Чем меньше задач, тем лучше. Не стоит детализировать работу больше, чем это действительно необходимо. Причина проста: чем больше элементов на диаграмме, тем проще запутаться. К тому же с возрастанием количества элементов на диаграмме увеличивается ее сложность, а соответственно и труднее соблюсти баланс между информативностью и легкостью восприятия.

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

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

4. Старайтесь быть лаконичными. Избегайте больших текстов.

5. Никогда не пользуйтесь в описании задач союзом и. Недопустимо называть задачу договориться о доставке и подготовить заказ к отгрузке. Это две отдельные задачи.

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

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