Добрый день!

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

Зачем нужен хороший стиль

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


Работая с разными схемами я прочувствовал правила “хорошего стиля”, т.е. негласное соглашение о том, как лучше оформлять схемы.  Делюсь с вами.

Элементы хорошего стиля

Happy Path

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

2016-07-11_10-43-46.png

Плохо

2016-07-11_10-50-41.png

Хорошо

Почему нужно так делать

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

Наименование задачи “Глагол” + “Существительное”

Любая задача для сотрудников должна именоваться по шаблону.

Плохо

Хорошо

Заявка оформляется

Оформить заявку

Почему нужно так делать

Задачи превратятся в поручения на корпоративном портале. Сотрудникам будет понятно что делать.

Процесс без пулов

Рисуйте процесс без указания исполнителей. Концентрируйтесь на задачах и последовательностях.

2016-07-11_11-03-11.png

Плохо

2016-07-11_10-50-41.png

Хорошо

Почему нужно так делать

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

Один старт

Рисуйте схемы так, чтобы было только одно стартовое событие.

2016-07-11_11-13-02.png

Плохо

2016-07-11_11-14-27.png

Хорошо

Почему нужно так делать

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

Много завершающих событий

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

2016-07-11_11-14-27.png

Плохо

2016-07-11_11-19-19.png

Хорошо

Почему нужно так делать

В будущем вам потребуется аналитика о том, как завершаются процессы. Если они все сходятся в один END EVENT, со собрать её будет проблематично.

Нумерации и подписи шлюзов

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

2016-07-11_11-19-19.png

Плохо

2016-07-11_11-23-49-1.png

Хорошо

Почему нужно так делать

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

Путь по-умолчанию

Указывайте на шлюзах поток по-умолчанию.

2016-07-11_11-23-49-1.png

Плохо

2016-07-11_11-27-15.png

Хорошо

Почему нужно так делать

Сэкономите время себе и программисту.

Один вход, один выход в задаче

В задачу делайте один входящий поток и один выходящий, когда это возможно.

2016-07-11_11-32-02.png

Плохо

2016-07-11_11-31-13.png

Хорошо

Почему нужно так делать

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

Не используйте условный переход

Не используйте условный переход :).

2016-07-11_11-35-12.png

Плохо

Почему нужно так делать

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

Что дальше

В следующем письме будет много хороших и плохих диаграмм с простор интернета с рецензиями. Будем учится их понимать, находить ошибки и избегать их.


P.S. Бывает и по-другому - читательница Валентина в интервью рассказывает что делать, если хороший стиль мешает согласовывать схемы.