Bizagi. Описание. Пример
Бизнес анализ
58 минуты
Эту статью я написал в продолжение статьи о BPM-системах. И здесь я хочу рассказать о принципах работы BPMS на примере конкретной системы — Bizagi. Я постараюсь пояснить, как происходит процесс моделирования, разработки и исполнения бизнес-процесса в этой системе на практическом примере.
Bizagi: Model. Build. Run
Bizagi — это BPM-система, разработанная одноименной компанией, и направленная на моделирование, исполнение, автоматизацию и анализ бизнес-процессов. Система Bizagi включает 3 модуля для полноценной настройки процессов:
- Modeler — полнофункциональная среда моделирования процессов в нотации BPMN;
- Studio — среда разработки бизнес-процессов;
- Engine — среда исполнения процессов, которая доступна пользователям в любом браузере с любого устройства.
Рассмотрим каждый из этих модулей подробнее.
Modeler
![](/sites/default/files/inline-images/a40.png)
Modeler — это дизайнер бизнес-процесса, где моделируется последовательность действий и событий. Важно понимать, что созданный в Modeler бизнес-процесс — это только картинка, графическое отображение моделируемого процесса, но еще не сам автоматизированный алгоритм действий. Непосредственно сами ответственные за бизнес-процесс, роли и бизнес-правила назначаются на следующем этапе программирования и не зависят от того, какой дизайн вы смоделировали на этом этапе. Дизайн бизнес-процесса нужен просто для того, чтобы согласовать схему работы с пользователями. Вы можете использовать один из трех способов моделирования бизнес-процесса:
- New Process — создать свой новый бизнес-процесс;
- Import Process — импортировать бизнес-процесс;
- Process Xchange — выбрать готовую модель из базы бизнес-процессов, предложенной компанией Bizagi. Выбрав шаблон, вы можете доработать его под реалии своего бизнеса. Все представленные модели написаны на английском языке.
Созданный в Modeler бизнес-процесс вы можете редактировать, сохранить, экспортировать в различных форматах (pdf, html). Моделирование бизнес-процесса производится в формате BPMN 2.0. Этот формат несколько отличается от известного многим BPMN 2.0, я с этим столкнулся на практике. Некоторых возможностей, которые подразумеваются в BPMN 2.0 и в некоторых других программах, созданных для работы исключительно с моделированием, в формате Bizagi вы не найдете. Например, здесь нет так называемой “внешней сущности”. Зато в Bizagi имеются собственные разработки, которых нет в других системах, например, Mailstone — промежуточный этап. Созданные в Modeler карты бизнес-процессов можно как “расшаривать” на портале Bizagi, так и использовать коллаборатив, то есть несколько сотрудников могут выполнять совместную работу, что очень удобно. Мodeler имеет русскоязычный вариант интерфейса, в отличие от двух других модулей. Еще раз напомню, что Modeler предназначен только для моделирования бизнес-процессов. То есть если вам необходим только дизайн бизнес-процесса, этого модуля вам будет достаточно. Если же вам необходимо не только моделировать, но и разрабатывать и исполнять бизнес-процессы, вам понадобится модуль Studio, в котором есть свой моделер бизнес-процессов.
Studio
![](/sites/default/files/inline-images/a41.png)
Смоделированная карта бизнес-процесса должна заработать. Пользователь должен входить в систему и взаимодействовать с различными формами. Studio позволяет разработать интерфейс и формы, с которыми будет работать человек. Ниже мы подробнее рассмотрим все аспекты разработки бизнес-процесса в Bizagi Studio. Хочу отметить, что Modeler и Studio бесплатны. В базовый пакет Studio включены до 20 тестовых пользователей.
![](/sites/default/files/inline-images/a42.png)
Engine
Engine - это среда исполнения, которая позволяет пользователям заходить в систему и работать в ней, выполняя определенные бизнес-процессы. Лицензии Engine платные. Бесплатен только тестовый режим. В Engine предусмотрено два вида лицензии:
- постоянная лицензия;
- лицензия на год.
При этом компаниям, в которых работает до 50 пользователей, предоставляется скидка 50% — это так называемый Starter kit, направленный на поддержку малого и среднего бизнеса. Если на предприятии работает более 50 пользователей, придется оплачивать полную стоимость лицензий.
Engine предполагает пошаговое исполнение разработанного бизнес-процесса с учетом всех прописанных в Studio условий.
Без модуля Engine вы не сможете полноценно работать в системе и исполнять прописанные бизнес-процессы.
Как работает Bizagi
Что мы делаем в Bizagi, если нам необходимо автоматизировать какой-либо бизнес-процесс? Рассмотрим алгоритм действий на примере согласования заявки на расход денежных средств. В статье про BPM-системы мы видели, как этот бизнес-процесс был реализован на реальном проекте посредством учетной системы, сейчас мы посмотрим, как это правильно организовать в системе BPM.
1. Моделирование Моделирование бизнес-процесса происходит путем перетаскивания графических элементов, предложенных в Bizagi, в рабочую зону. Выше я писал, что интерфейс Studio, представлен на английском языке, но в самой карте бизнес-процесса мы можем использовать русский язык. Мы моделируем схему бизнес-процесса Payment Request: определяем начало процесса, события, оповещения, бизнес-правила и конец бизнес-процесса. Задача заключается в контроле оплаты счетов. Последовательность действий данного бизнес-процесса выглядит так:
1. Сотрудник, которому поступает счет на оплату, должен создать запрос на оплату.
2. Руководитель должен проверить запрос и выбрать один из вариантов действия:
- Отказать;
- Одобрить.
3. При первом варианте Сотрудник получает уведомление об отказе руководителя. На этом бизнес-процесс заканчивается. 3. Во втором случае Руководитель должен Распечатать, подписать запрос и отправить его в бухгалтерию, на этом бизнес-процесс заканчивается. Графическая карта бизнес-процесса выглядит так:
![](/sites/default/files/inline-images/a43.png)
2. Разработка структуры данных После того, как бизнес-процесс смоделирован, мы приступаем к разработке структуры данных. На данном этапе мы прописываем, в каких формах, каких полях хранятся те или иные данные и указываем их связи. В нашем примере мы должны разработать три сущности (Entity):
- Запрос на оплату счета;
- Контрагент (поставщик, которому необходимо оплатить счет);
- Причина отказа.
Для каждой из этих сущностей необходимо прописать атрибуты (поля), которые будут доступны для заполнения. Атрибуты делятся на:
- Предустановленные (их очень много) — атрибуты, которые предлагает сама система;
- Пользовательские — те, которые пользователь создает вручную.
На скриншоте видно, какие атрибуты прописаны для каждой сущности.
![](/sites/default/files/inline-images/a44.png)
Также необходимо указать связи между этими сущностями. Мы прописываем, что сущности Причины отказа и Контрагенты входят в сущность Запрос на оплату счета. 3. Создание форм (пользовательского интерфейса) После того, как мы разработали структуру данных, нам необходимо решить, как пользователь заходит в систему, как взаимодействует с ней. И вот здесь нам необходимо создать пользовательский интерфейс. Когда мы смоделировали бизнес-процесс, мы входим в него и видим, что каждый из этих квадратиков на схеме, обозначающих этапы, — это форма, которую необходимо разработать.
Форма — это то, с чем впоследствии будет работать пользователь.
Хочу обратить ваше внимание на то, что разрабатываются только те формы, над которыми работает пользователь. Если какой-то из этапов предполагает автоматическое действие (например, оповещение Сотрудника об отказе в оплате), для него форму разрабатывать не нужно. В нашем примере необходимо разработать 3 формы:
- Создания запроса на оплату;
- Проверка запроса на оплату;
- Формирования печатной формы.
Эти формы используют одни и те же данные. Основа в каждой из этих форм одна — запрос на оплату счета. Но каждая следующая форма имеет более расширенный функционал, чем предыдущая. Например, в форме Проверки запроса есть вся информация из формы создания запроса + статус заявки (Одобрено или нет). А следующая форма имеет по сравнению с предыдущей еще и возможность печати запроса. При необходимости ненужные поля из предыдущих форм можно скрыть.
Здесь важно понимать, что это все-таки не одна, а три разных формы. И каждая из них создается заново либо копируется с предыдущей формы, после чего в нее вносятся необходимые изменения.
Теперь рассмотрим сам процесс создания формы (например, Создания запроса на оплату). Форма создается посредством выбора и перетаскивания в активное окно необходимых полей. Для выбора предлагаются поля (атрибуты), которые мы назначили конкретным формам на предыдущем этапе.
![](/sites/default/files/inline-images/a45.png)
Форма создания запроса в итоге будет выглядеть так:
![](/sites/default/files/inline-images/a46.png)
Здесь мы видим поля:
- Срок оплаты;
- Сумма счета;
- Номер счета;
- Контрагент;
- Присоединенный файл (возможно прикрепить счет на оплату).
Также для более удобного использования форм можно воспользоваться Layot (варианты расположения частей формы). Макет формы можно разделить:
- на три равные части (33%-34%-33%);
- на две равные (50%-50%) части;
- на две неравные (70%-30%, 30%-70%) части;
- оставить макет неделимым (Full layout).
![](/sites/default/files/inline-images/a47.png)
На этапе создания форм можно настроить видимость полей и функции редактирования для разных пользователей. Например, у следующего этапа Проверки запроса есть своя форма, в которой руководителю видны поля, созданные сотрудником на предыдущем этапе, но руководитель эти поля редактировать не может. Зато ему доступны собственные поля, которые не видны сотруднику: поле Одобрено с вариантами Yes/No.
![](/sites/default/files/inline-images/a48.png)
Поле Причина отказа становится видным для руководителя, только если в поле Одобрено он выбрал вариант No. То есть видимость полей можно настроить не только в формате Видно-Не видно, но и в зависимости от каких либо условий. Это условие выглядит так PaymentRequestApproved is equal to false
![](/sites/default/files/inline-images/a49.png)
Если Руководитель установил вариант Yes, становится доступной функция распечатать запрос на оплату. Для него уже никакие функции недоступны, кроме Generate template.
![](/sites/default/files/inline-images/a50.png)
4. Определение бизнес-правил Далее необходимо разработать бизнес-правила, чтобы система автоматически делала некоторые вещи на основании каких-либо данных. В Bizagi предусмотрено три этапа установки бизнес-правил:
- Define Expressions — предполагает обработку условий
- Activity Actions (Events) — предполагает обработку событий
- Perfomance — предполагает обработку пользователей, работающих на том или ином этапе бизнес-процесса.
Define Expressions На этапе Define Expressions идет определение вариантов поведения системы при тех или иных условиях. В нашем случае это результат проверки запроса, два варианта (две стрелки), которые ведут от Результата проверки. При нажатии на стрелку, ведущую к следующему этапу, открывается форма, в которых заполняются условия перехода на тот или иной этап. Если по результатам проверки руководитель отказывает, то процесс переходит в стадию Оповестить о причине отказа.
![](/sites/default/files/inline-images/a51.png)
Если по результатам проверки Руководитель одобрил запрос, процесс переходит на этап Распечатать счет. Activity Actions На этапе Activity Actions мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):
- при открытии формы;
- при сохранении;
- при выходе из формы.
Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:
- Дата — здесь мы указываем, что дата запроса автоматически заполняется текущей датой <PaymentRequest.RequestDate>=DateTime.Today
- Автор (сотрудник) — здесь прописываем, что тот, кто инициировал документ, автоматически становится его автором <PaymentRequest.Employee>=Me.Case.Creator.Id
![](/sites/default/files/inline-images/a52.png)
Perfomance Следующий шаг — это Perfomance. Здесь мы прописываем, кто на каком этапе работает с бизнес-процессом, отвечает за его выполнение.
- На этапе Создания сделки работает сотрудник, создавший эту сделку. User Id Equal Case Creator
- На этапе Проверки запроса работает Руководитель того, кто создал документ. User Id Equals CurrentAssigneeBoss
![](/sites/default/files/inline-images/a53.jpeg)
5. Описание правил оповещения После того, как мы прописали, как работают бизнес-правила, мы описываем правила оповещения. Сотрудник не может постоянно находиться в одной системе, у него есть текущие дела и работа в других программах. Как он будет получать информацию об изменениях по бизнес-процессу, которые требуют его участия? Это настраивается с помощью Notification. В BPMN 2.0 есть такое понятие, как notification, и здесь мы можем оповещение привязать к системе. Оповещения бывают двух видов:
- автоматические (в самой системе есть свой email-сервер) — например, при переходе с одной стадии в другую;
- создаваемые вручную — например, когда пользователь сам хочет отправить сообщение для какого-либо уточнения, но без изменения этапа заявки.
Использовать можно оба вида оповещений одновременно. В нашем бизнес-процессе при смене этапа (Одобрен или Не одобрен запрос на оплату), Сотруднику отправляется сообщение о том, что счет одобрен или требует уточнения. 6. Создание печатной формы В нашем примере сотрудник, кроме электронного документа, хочет получить еще и печатную форму. То есть, если руководитель одобрил запрос на оплату, то он распечатывает, подписывает документ и отдает секретарю для дальнейшей передачи в бухгалтерию. Документ сохраняется не только в системе, но и в печатной форме. В системе можно создавать, так называемый, document templates. Для печатной формы запроса можно использовать word, excel или простой текст. Мы создали форму, которую должен распечатать тот, на ком заканчивается процесс, и поставить свою подпись. В этой печатной форме видна вся основная информация по запросу:
- Дата создания;
- Пользователь;
- Номер счета;
- Дата счета;
- Сумма счета;
- Основание;
- Подпись ответственного лица.
![](/sites/default/files/inline-images/a54.png)
При получении такой формы бухгалтерия сразу может идентифицировать счет, который необходимо оплатить.
Исполнение бизнес-процесса
После того, как мы разработали бизнес-процесс в системе Bizagi, необходимо создать пользователей, указать их структуру, после чего эти пользователи смогут работать в системе. Рассмотрим, как происходит исполнение созданного нами бизнес-процесса: Пользователь выбирает бизнес-процесс из тех, что предложены в системе. В данном случае это бизнес-процесс Request Payment. Открывается форма создания запроса. 1. Пользователь заполняет необходимые поля (поле Дата и Автор заполнены автоматически). Пользователь прикрепляет счет на оплату.
2. Руководитель получает оповещение о том, что необходимо Проверить запрос. 3. Руководитель входит в форму запроса, где видит форму проверки запроса с доступными действиями — выбрать, одобрен или не одобрен запрос. Если руководитель выбрал Yes: 4. Появляется кнопка Generate document для распечатки запроса. Руководитель выводит печатную форму и подписывает ее. 5. Сотрудник, инициировавший запрос, получает уведомление об одобрении счета Если руководитель выбрал No: 4. Сотрудник, инициировавший запрос, получает уведомление об отказе в оплате счета. Бизнес-процесс исполнен.
Еще несколько слов о Bizagi
В Bizagi вы всегда сможете посмотреть аналитику по исполнению бизнес-процессов. В системе предусмотрена интеграция: возможно “снаружи” подключаться к Bizagi, либо из самой Bizagi подключаться к другим программам посредством API. Она использует web-сервисы и SOAP. Необходимо также напомнить, что система имеет локализацию — варианты на разных языках. Есть в Bizagi Modeler и русский перевод. Сразу скажу, что этот перевод, к сожалению, не всегда правильный. К тому же, вся документация Bizagi представлена только на английском. Поэтому я предпочитаю работать с системой на английском языке. В заключение хочется отметить, что создание бизнес-процесса — долгая и трудоемкая работа, так как мы пишем практически новое приложение, для которого разрабатываем с нуля структуры данных и формы.
Об авторе
Комментарии
Подписка на рассылку
Книги, постеры, новости и многое другое
Никакого спама, только важна информация от автора блога.
Приседединяйся к 4,000+ подписчиков автора.