Представьте, что вам, как, например, сотруднику молочной фермы, необходимо изменить статус животного, которое перешло в категорию "готовых к осеменению". Для этого будет действовать следующий алгоритм: Поступление задачи – проверка параметров животного – внесение изменений – завершение задачи. Кажется просто и повседневно. А теперь давайте перенесем этот алгоритм на более масштабную бизнес-задачу, в которой придется учитывать не только действия одного зоотехника, но взаимодействие с прочими элементами всей системы учета и управления молочных производством (регламентированное время, выгрузка данных из карточки животного, создание и фиксация результатов проверки, отражение документов в общей базе и т.п.) И, как только вы это себе представили, усложняем. Идентичный бизнес-процесс должен проводиться с определенной периодичностью на ферме с поголовьем в 1000 коров, каждая из которых может либо соответствовать требуемым условиям, либо нет.
Согласитесь, для того, чтобы реализовать такой проект на высшем уровне и без ошибок, потребуется детальный план действий, правильное распределение обязанностей и чёткий контроль. Кроме того, придется расставить реперные точки для промежуточного подведения итогов, мониторинга соблюдения сроков и оперативного принятия решений. Для этого, например, можно применить классическую методологию оптимизации бизнес-процессов «As is и To be» (Как есть и Как будет), которая призвана разграничить анализ текущей ситуации и планирование улучшений. Удержать весь этот объем информации в голове крайне сложно, а во избежание накладок и ошибок придется как-то организовать устойчивую оперативную связь между всеми участниками процесса. Вот здесь и появляется такой незаменимый помощник, как BPMN.
Проще, удобнее и быстрее будет спроектировать общую картину визуально, без лишних отвлекающих слов, пояснений и элементов. Такие графические модели бизнес-процессов и называются нотациями. На сегодняшний день существует несколько наиболее популярных и востребованных видов нотаций:
-
IDEF0 – строится слева направо и сверху вниз по диагонали от доминирующих объектов к объектам подчиненным. Такой метод имеет высокую степень детализации, но подходит для случаев, когда бизнес-процессы представляют собой одну цепочку без «развилок». Если же в данной цепи имеются условия, предполагающие выбор между двумя и более путями развития, то такой вид нотаций перестает быть простым и удобным.
-
eEPC – за счёт разнообразия фигур по форме и цвету, это визуально более интуитивная понятная модель. Структура бизнес-процессов строится сверху вниз и лучше подходит для создания сложных развилок и длинных параллельных рядов событий. При этом для каждого элемента можно создать отдельную схему, тем самым разложив его на более мелкие составные элементы. Главным минусом EPC является вынужденная перегруженность «событиями», которые приходится создавать для всех, даже самых незначительных этапов. При создании такой нотации неизбежным станет нагромождение повторяющихся простых элементов, таких, как, например, «определить исполнителя» или «согласовать» к каждому выделенному этапу.
-
UML – это унифицированный язык моделирования, отличающийся высокой подробностью и детализацией. Однако, среди недостатков выделяют часто неоправданную избыточность и сложность, а также неспособность входа одной системы воспринимать выход другой.
-
BPMN – здесь диаграммы предназначены для изображения даже самых сложных алгоритмов максимально просто и интуитивно понятно. Чтобы успешно пользоваться таким инструментом, необходимо только освоить основополагающие базовые принципы и правила, после чего абсолютно любая масштабная и многоуровневая задача окажется буквально, как на ладони.
Простыми словами, BPMN (Business Process Model and Notation) – это
-
система моделирования бизнес-процессов;
-
алгоритм действий для достижения той или иной цели;
-
детальный путь, который предстоит преодолеть для выполнения поставленной задачи.
Само собой, у этого пути есть свой старт и свой финиш, а всё, что находится между ними – этапы, промежуточные звенья единой цепи.
Итак, BPMN-диаграмма состоит из нескольких основных элементов. На самом деле существует множество других элементов, но эти четыре являются базовыми и достаточными для проектирования большинства систем.
Событие – слово, которым уже всё сказано. Будь то поступление заявки или сообщения на почту, подписание документа или нечто другое, побуждающее к действиям. События бывают трёх основных типов, каждый из которых принято обозначать следующим образом:
Стартовые – тонкий контур
Промежуточные – двойной тонкий контур
Завершающие – жирный контур
Существуют и другие типы событий, но для базовых знаний достаточно этих трех. Помимо типов, события делятся на виды, в зависимости от характера возложенной на данный этап работы:
Пустые (Start event) – Обычно применяются для начала построения системы бизнес-процессов.
Сообщения (Message) – это как раз тот случай, когда триггером для начала процесса становится заявка, заказ, запрос и т.п.
Таймер (Timer) – процесс, завязанный на определенном времени. Например, он может обозначать начало выполнения задачи во вторник в 9:00. А, если процесс имеет регулярность и цикличность, то можно обозначить старт «ежедневно по будням с 14:00»
Условие (Conditional) – обозначает запуск события при выполнении определенных действий. Например, к следующему этапу можно будет перейти только после проверки промежуточных результатов и отметки согласования определенным сотрудником.
Ошибка (Error) – Не всегда означает что-то плохое. Таким видом не редко выделяют событие, при котором несостоявшаяся операция может быть перенаправлена на другой поток. Например, если в магазине не оказалось нужно продукта, то сотрудник воспользуется альтернативой в виде соседней торговой точки.
Есть ещё много других видов событий, которыми можно воспользоваться, в зависимости от специфики ваших потребностей. Но для проектирования подавляющего большинства основных диаграмм, обычно, достаточно тех, что указаны выше.
Действия – элементы для фиксирования конкретных задач, которые следует выполнить тому или иному сотруднику. Например, после События «получение письма с заявкой» должно происходить Действие «заполнение формы заказа». Следом могут быть обозначены другие Действия: «отправка заполненной формы в отдел комплектации» или «звонок клиенту для уточнения данных» (с установленным Таймером «в течение 30 минут после получения письма»).
Действия тоже можно разделить на два ключевых типа:
Простое или обычное – односложная задача, требующая выполнения одного конкретного действия.
Подпроцесс – действие, которое состоит из нескольких подзадач или отдельных процессов. Удобство данного типа заключается в том, что составные подпункты можно свернуть и не перегружать диаграмму.
Вариаций использования действий тоже более, чем достаточно. Вы можете задавать функцию цикличности, если выбранный процесс носит регулярный характер. Часто требуется создавать параллельные действия, когда, например, большой поток одинаковых задач выполняет одновременно несколько сотрудников. При этом к каждому отдельному действию есть возможность применять особые обозначения, такие, как процесс для конкретного пользователя, задача на вызов сервиса или выполнение определенного сценария. Это способствует быстрому ориентированию всех уполномоченных лиц внутри диаграммы бизнес-процессов.
Шлюзы – элемент BPMN, применяемый для внедрения в систему бизнес-процессов «развилок». По своей сути, это точки принятия решений. Для успешного прототипирования диаграмм достаточно знать три основных типа:
«ИЛИ» (эксклюзивный шлюз) - перенаправляет поток процесса, в зависимости от сделанного выбора. Например, клиент имеет два варианта: забрать товар самовывозом или оформить доставку на дом. Сделать и то, и другое одновременно невозможно. Поэтому, в зависимости от его выбора, шлюз направляет процесс либо в пункт выдачи, либо курьеру.
«И» (параллельный шлюз) - предназначен для тех случаев, когда процесс необходимо разделить на два и более параллельных потока. Клиент заказал несколько товаров на маркетплейсе, часть из них находится на одном складе, а часть на другом. Задача разделяется на два параллельных логистических процесса, которые в итоге приведут в финальную точку в виде пункта выдачи.
«И/ИЛИ» (неэксклюзивный шлюз) – сочетает в себе два предыдущих вида шлюза и позволяет направить поток как по одному, так и по нескольким путям сразу. В качестве примера может подойти сценарий, при котором клиент сделал заказ и решил мелкие товары забрать самостоятельно, а на крупногабаритные оформить доставку на дом.
Важно очень внимательно пользоваться шлюзами и соблюдать четкую логику их сочетания, как между собой, так и с другими элементами диаграммы. Ошибочно присвоенный вид шлюза способен привести к тому, что процесс остановится на каком-то действии, не имея пути выхода из него. В качестве простой и наглядной аналогии представьте себе электрическую цепь. Если она собрана неправильно, то ток не дойдёт до конечной цели, лампочка не загорится и появится вероятность короткого замыкания. Вот несколько наглядных примеров правильного и некорректного использования шлюзов:
-
Эксклюзивный шлюз «ИЛИ» должен выражать наиболее простой вариант выбора без перегруженности дополнительными условиями. Чтобы не запутаться, лучше выделить такие условия в отдельные логические ветки.
-
Параллельный шлюз «И» нельзя применять во взаимоисключающих действиях
-
Неэксклюзивный шлюз «И/ИЛИ» не должен противоречить логике и применяться вместе взаимоисключающими вариантами движения процессов.
Кстати, с этой точки зрения, проектирование BPMN-диаграмм прекрасно подходит для прогнозирования сроков, а также оценки вероятных рисков и потенциальных проблем. Имея перед глазами полную схему всех задействованных служб и механизмов, намного проще выявлять в этой схеме слабые места и экспериментировать с вариантами оптимизации.
Потоки – графически на BPMN-диаграммах они обозначаются обычные стрелочками, которые указывают направление и последовательность действий.
Дорожки – элемент, которым можно пренебречь, но он очень удобен для структурирования бизнес-процессов по разным признакам. Например, если при выполнении задачи задействовано несколько подразделений, сотрудников или параллельных и сопутствующих структур. Если взять уже привычный формат маркетплейса, то для клиента приобретение товара выглядит простым и коротким алгоритмом действий: выбрал – заказал – оплатил – получил. А на стороне продавца запускается сразу несколько механизмов: принятие заказа, склад, логистическая служба, пункт выдачи, а затем ещё и получение оценки качества, публикация отзыва и не редко работа с возражениями, споры, возврат и т.п.
Каждый из этих этапов имеет свою собственную систему действий со своими потоками, событиями и шлюзами. И, в зависимости от сценария, эти системы взаимодействуют друг с другом. Поэтому, чтобы не запутаться, дорожки очень сильно помогают интуитивно понятно разбить одну большую и сложную систему процессов на несколько систем поменьше, не теряя при этом целостность.
А теперь, чтобы закрепить всю полученную информацию, давайте перейдем к небольшой практике. Вернемся к ситуации из самого начала статьи, при которой на молочной ферме необходимо организовать процесс присвоения животным статуса «готова к осеменению».
Создадим простой последовательный проект BPMN-диаграммы. Делать я это буду на сервисе MAKER, так как использую его для другой работы в области прототипирования форм и создания приложений. Однако, при последнем обновлении в сервисе появился модуль BPMN, позволяющий создавать диаграммы в популярном среди разработчиков и аналитиков стиле CAMUND. Вы можете применять любой другой сервис, концептуально все они плюс-минус одинаковые. А лично мне удобно, когда вместо трех программ всё можно делать в одной. Итак, вот простой алгоритм действий:
Теперь добавим условие, при котором животное может либо пройти проверку на соответствие и получить новый статус, либо нет. И выразим это в диаграмме.
Следом задействуем сопряженные элементы всей системы управления предприятия, такие, как: ежедневное расписание, регламентное задание и предварительная проверка имеющегося статуса.
Ну, и, наконец, добавим Пользователя, а также выведем отдельной веткой действия главного зоотехника и точку его взаимодействия с системой бизнес-процессов. Его роль заключается в осуществлении контроля на стадии проверки соответствия параметров и последующая фиксация обновленных данных в базе. И сразу воспользуемся «Дорожками» для того, чтобы визуально разделить зоны ответственности всех участников бизнес-процесса.
Если вы попробуете таким же образом самостоятельно спроектировать диаграмму для ваших актуальных задач, то поймете, что одним из главных достоинств инструмента BPMN является то, что абсолютно все манипуляции, изменения и редактирования осуществляются буквально в пару кликов легкими перемещениями элементов, назначениями ролей и определением условий.
BPMN – это одновременно многофункциональный и, в то же время простой инструмент для создания проектов бизнес-процессов любого уровня сложности. Как только вы усвоите заложенные в его работу концептуальные принципы и хоть раз примените на практике, то больше не сможете представить без него свою работу. Настоятельно рекомендую всем бизнес-аналитикам, разработчикам, да и любым другим специалистам, для которых такие слова, как точность и порядок не являются пустым звуком
Используйте BPMN в Maker для моделирования бизнес-процессов
Удобный и простой инструмент: изменяйте и редактируйте всё парой кликов, просто перетаскивайте элементы, назначайте роли и задавайте условия.
