Эту статью я написал в продолжение статьи о BPM-системах. И здесь я хочу рассказать о принципах работы BPMS на примере конкретной системы — Bizagi. Я постараюсь пояснить, как происходит процесс моделирования, разработки и исполнения бизнес-процесса в этой системе на практическом примере.
Bizagi — это BPM-система, разработанная одноименной компанией, и направленная на моделирование, исполнение, автоматизацию и анализ бизнес-процессов. Система Bizagi включает 3 модуля для полноценной настройки процессов:
Рассмотрим каждый из этих модулей подробнее.
Modeler — это дизайнер бизнес-процесса, где моделируется последовательность действий и событий. Важно понимать, что созданный в Modeler бизнес-процесс — это только картинка, графическое отображение моделируемого процесса, но еще не сам автоматизированный алгоритм действий.
Непосредственно сами ответственные за бизнес-процесс, роли и бизнес-правила назначаются на следующем этапе программирования и не зависят от того, какой дизайн вы смоделировали на этом этапе. Дизайн бизнес-процесса нужен просто для того, чтобы согласовать схему работы с пользователями.
Вы можете использовать один из трех способов моделирования бизнес-процесса:
Созданный в Modeler бизнес-процесс вы можете редактировать, сохранить, экспортировать в различных форматах (pdf, html).
Моделирование бизнес-процесса производится в формате BPMN 2.0. Этот формат несколько отличается от известного многим BPMN 2.0, я с этим столкнулся на практике. Некоторых возможностей, которые подразумеваются в BPMN 2.0 и в некоторых других программах, созданных для работы исключительно с моделированием, в формате Bizagi вы не найдете. Например, здесь нет так называемой “внешней сущности”. Зато в Bizagi имеются собственные разработки, которых нет в других системах, например, Mailstone — промежуточный этап.
Созданные в Modeler карты бизнес-процессов можно как “расшаривать” на портале Bizagi, так и использовать коллаборатив, то есть несколько сотрудников могут выполнять совместную работу, что очень удобно.
Мodeler имеет русскоязычный вариант интерфейса, в отличие от двух других модулей.
Еще раз напомню, что Modeler предназначен только для моделирования бизнес-процессов. То есть если вам необходим только дизайн бизнес-процесса, этого модуля вам будет достаточно. Если же вам необходимо не только моделировать, но и разрабатывать и исполнять бизнес-процессы, вам понадобится модуль Studio, в котором есть свой моделер бизнес-процессов.
Смоделированная карта бизнес-процесса должна заработать. Пользователь должен входить в систему и взаимодействовать с различными формами. Studio позволяет разработать интерфейс и формы, с которыми будет работать человек. Ниже мы подробнее рассмотрим все аспекты разработки бизнес-процесса в Bizagi Studio.
Хочу отметить, что Modeler и Studio бесплатны. В базовый пакет Studio включены до 20 тестовых пользователей.
Engine — это среда исполнения, которая позволяет пользователям заходить в систему и работать в ней, выполняя определенные бизнес-процессы.
Лицензии Engine платные. Бесплатен только тестовый режим.
В Engine предусмотрено два вида лицензии:
При этом компаниям, в которых работает до 50 пользователей, предоставляется скидка 50% — это так называемый Starter kit, направленный на поддержку малого и среднего бизнеса. Если на предприятии работает более 50 пользователей, придется оплачивать полную стоимость лицензий.
Без модуля Engine вы не сможете полноценно работать в системе и исполнять прописанные бизнес-процессы.
Что мы делаем в Bizagi, если нам необходимо автоматизировать какой-либо бизнес-процесс? Рассмотрим алгоритм действий на примере согласования заявки на расход денежных средств. В статье про BPM-системы мы видели, как этот бизнес-процесс был реализован на реальном проекте посредством учетной системы, сейчас мы посмотрим, как это правильно организовать в системе BPM.
1. Моделирование
Моделирование бизнес-процесса происходит путем перетаскивания графических элементов, предложенных в Bizagi, в рабочую зону.
Выше я писал, что интерфейс Studio, представлен на английском языке, но в самой карте бизнес-процесса мы можем использовать русский язык.
Мы моделируем схему бизнес-процесса Payment Request: определяем начало процесса, события, оповещения, бизнес-правила и конец бизнес-процесса.
Задача заключается в контроле оплаты счетов. Последовательность действий данного бизнес-процесса выглядит так:
1. Сотрудник, которому поступает счет на оплату, должен создать запрос на оплату.
2. Руководитель должен проверить запрос и выбрать один из вариантов действия:
3. При первом варианте Сотрудник получает уведомление об отказе руководителя. На этом бизнес-процесс заканчивается.
3. Во втором случае Руководитель должен Распечатать, подписать запрос и отправить его в бухгалтерию, на этом бизнес-процесс заканчивается.
Графическая карта бизнес-процесса выглядит так:
2. Разработка структуры данных
После того, как бизнес-процесс смоделирован, мы приступаем к разработке структуры данных. На данном этапе мы прописываем, в каких формах, каких полях хранятся те или иные данные и указываем их связи.
В нашем примере мы должны разработать три сущности (Entity):
Для каждой из этих сущностей необходимо прописать атрибуты (поля), которые будут доступны для заполнения. Атрибуты делятся на:
На скриншоте видно, какие атрибуты прописаны для каждой сущности.
Также необходимо указать связи между этими сущностями. Мы прописываем, что сущности Причины отказа и Контрагенты входят в сущность Запрос на оплату счета.
3. Создание форм (пользовательского интерфейса)
После того, как мы разработали структуру данных, нам необходимо решить, как пользователь заходит в систему, как взаимодействует с ней. И вот здесь нам необходимо создать пользовательский интерфейс.
Когда мы смоделировали бизнес-процесс, мы входим в него и видим, что каждый из этих квадратиков на схеме, обозначающих этапы, — это форма, которую необходимо разработать.
Хочу обратить ваше внимание на то, что разрабатываются только те формы, над которыми работает пользователь. Если какой-то из этапов предполагает автоматическое действие (например, оповещение Сотрудника об отказе в оплате), для него форму разрабатывать не нужно.
В нашем примере необходимо разработать 3 формы:
Эти формы используют одни и те же данные. Основа в каждой из этих форм одна — запрос на оплату счета. Но каждая следующая форма имеет более расширенный функционал, чем предыдущая. Например, в форме Проверки запроса есть вся информация из формы создания запроса + статус заявки (Одобрено или нет). А следующая форма имеет по сравнению с предыдущей еще и возможность печати запроса. При необходимости ненужные поля из предыдущих форм можно скрыть.
Теперь рассмотрим сам процесс создания формы (например, Создания запроса на оплату).
Форма создается посредством выбора и перетаскивания в активное окно необходимых полей. Для выбора предлагаются поля (атрибуты), которые мы назначили конкретным формам на предыдущем этапе.
Форма создания запроса в итоге будет выглядеть так:
Здесь мы видим поля:
Также для более удобного использования форм можно воспользоваться Layot (варианты расположения частей формы).
Макет формы можно разделить:
На этапе создания форм можно настроить видимость полей и функции редактирования для разных пользователей.
Например, у следующего этапа Проверки запроса есть своя форма, в которой руководителю видны поля, созданные сотрудником на предыдущем этапе, но руководитель эти поля редактировать не может. Зато ему доступны собственные поля, которые не видны сотруднику: поле Одобрено с вариантами Yes/No.
Поле Причина отказа становится видным для руководителя, только если в поле Одобрено он выбрал вариант No. То есть видимость полей можно настроить не только в формате Видно-Не видно, но и в зависимости от каких либо условий. Это условие выглядит так
PaymentRequestApproved is equal to false
Если Руководитель установил вариант Yes, становится доступной функция распечатать запрос на оплату. Для него уже никакие функции недоступны, кроме Generate template.
4. Определение бизнес-правил
Далее необходимо разработать бизнес-правила, чтобы система автоматически делала некоторые вещи на основании каких-либо данных.
В Bizagi предусмотрено три этапа установки бизнес-правил:
Define Expressions
На этапе Define Expressions идет определение вариантов поведения системы при тех или иных условиях. В нашем случае это результат проверки запроса, два варианта (две стрелки), которые ведут от Результата проверки. При нажатии на стрелку, ведущую к следующему этапу, открывается форма, в которых заполняются условия перехода на тот или иной этап.
Если по результатам проверки руководитель отказывает, то процесс переходит в стадию Оповестить о причине отказа.
Если по результатам проверки Руководитель одобрил запрос, процесс переходит на этап Распечатать счет.
Activity Actions
На этапе Activity Actions мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):
Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:
Perfomance
Следующий шаг — это Perfomance. Здесь мы прописываем, кто на каком этапе работает с бизнес-процессом, отвечает за его выполнение.
5. Описание правил оповещения
После того, как мы прописали, как работают бизнес-правила, мы описываем правила оповещения.
Сотрудник не может постоянно находиться в одной системе, у него есть текущие дела и работа в других программах. Как он будет получать информацию об изменениях по бизнес-процессу, которые требуют его участия? Это настраивается с помощью Notification. В BPMN 2.0 есть такое понятие, как notification, и здесь мы можем оповещение привязать к системе.
Оповещения бывают двух видов:
Использовать можно оба вида оповещений одновременно.
В нашем бизнес-процессе при смене этапа (Одобрен или Не одобрен запрос на оплату), Сотруднику отправляется сообщение о том, что счет одобрен или требует уточнения.
6. Создание печатной формы
В нашем примере сотрудник, кроме электронного документа, хочет получить еще и печатную форму. То есть, если руководитель одобрил запрос на оплату, то он распечатывает, подписывает документ и отдает секретарю для дальнейшей передачи в бухгалтерию. Документ сохраняется не только в системе, но и в печатной форме.
В системе можно создавать, так называемый, document templates. Для печатной формы запроса можно использовать word, excel или простой текст. Мы создали форму, которую должен распечатать тот, на ком заканчивается процесс, и поставить свою подпись. В этой печатной форме видна вся основная информация по запросу:
При получении такой формы бухгалтерия сразу может идентифицировать счет, который необходимо оплатить.
После того, как мы разработали бизнес-процесс в системе Bizagi, необходимо создать пользователей, указать их структуру, после чего эти пользователи смогут работать в системе.
Рассмотрим, как происходит исполнение созданного нами бизнес-процесса:
Пользователь выбирает бизнес-процесс из тех, что предложены в системе. В данном случае это бизнес-процесс Request Payment. Открывается форма создания запроса.
1. Пользователь заполняет необходимые поля (поле Дата и Автор заполнены автоматически). Пользователь прикрепляет счет на оплату.
2. Руководитель получает оповещение о том, что необходимо Проверить запрос.
3. Руководитель входит в форму запроса, где видит форму проверки запроса с доступными действиями — выбрать, одобрен или не одобрен запрос.
Если руководитель выбрал Yes:
4. Появляется кнопка Generate document для распечатки запроса. Руководитель выводит печатную форму и подписывает ее.
5. Сотрудник, инициировавший запрос, получает уведомление об одобрении счета
Если руководитель выбрал No:
4. Сотрудник, инициировавший запрос, получает уведомление об отказе в оплате счета.
Бизнес-процесс исполнен.
В Bizagi вы всегда сможете посмотреть аналитику по исполнению бизнес-процессов.
В системе предусмотрена интеграция: возможно “снаружи” подключаться к Bizagi, либо из самой Bizagi подключаться к другим программам посредством API. Она использует web-сервисы и SOAP.
Необходимо также напомнить, что система имеет локализацию — варианты на разных языках. Есть в Bizagi Modeler и русский перевод. Сразу скажу, что этот перевод, к сожалению, не всегда правильный. К тому же, вся документация Bizagi представлена только на английском. Поэтому я предпочитаю работать с системой на английском языке.
В заключение хочется отметить, что создание бизнес-процесса — долгая и трудоемкая работа, так как мы пишем практически новое приложение, для которого разрабатываем с нуля структуры данных и формы.
Bizagi: Model. Build. Run
Bizagi — это BPM-система, разработанная одноименной компанией, и направленная на моделирование, исполнение, автоматизацию и анализ бизнес-процессов. Система Bizagi включает 3 модуля для полноценной настройки процессов:
- Modeler — полнофункциональная среда моделирования процессов в нотации BPMN;
- Studio — среда разработки бизнес-процессов;
- Engine — среда исполнения процессов, которая доступна пользователям в любом браузере с любого устройства.
Рассмотрим каждый из этих модулей подробнее.
Modeler
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
Смоделированная карта бизнес-процесса должна заработать. Пользователь должен входить в систему и взаимодействовать с различными формами. Studio позволяет разработать интерфейс и формы, с которыми будет работать человек. Ниже мы подробнее рассмотрим все аспекты разработки бизнес-процесса в Bizagi Studio.
Хочу отметить, что Modeler и Studio бесплатны. В базовый пакет Studio включены до 20 тестовых пользователей.
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. Во втором случае Руководитель должен Распечатать, подписать запрос и отправить его в бухгалтерию, на этом бизнес-процесс заканчивается.
Графическая карта бизнес-процесса выглядит так:
2. Разработка структуры данных
После того, как бизнес-процесс смоделирован, мы приступаем к разработке структуры данных. На данном этапе мы прописываем, в каких формах, каких полях хранятся те или иные данные и указываем их связи.
В нашем примере мы должны разработать три сущности (Entity):
- Запрос на оплату счета;
- Контрагент (поставщик, которому необходимо оплатить счет);
- Причина отказа.
Для каждой из этих сущностей необходимо прописать атрибуты (поля), которые будут доступны для заполнения. Атрибуты делятся на:
- Предустановленные (их очень много) — атрибуты, которые предлагает сама система;
- Пользовательские — те, которые пользователь создает вручную.
На скриншоте видно, какие атрибуты прописаны для каждой сущности.
Также необходимо указать связи между этими сущностями. Мы прописываем, что сущности Причины отказа и Контрагенты входят в сущность Запрос на оплату счета.
3. Создание форм (пользовательского интерфейса)
После того, как мы разработали структуру данных, нам необходимо решить, как пользователь заходит в систему, как взаимодействует с ней. И вот здесь нам необходимо создать пользовательский интерфейс.
Когда мы смоделировали бизнес-процесс, мы входим в него и видим, что каждый из этих квадратиков на схеме, обозначающих этапы, — это форма, которую необходимо разработать.
Форма — это то, с чем впоследствии будет работать пользователь.
Хочу обратить ваше внимание на то, что разрабатываются только те формы, над которыми работает пользователь. Если какой-то из этапов предполагает автоматическое действие (например, оповещение Сотрудника об отказе в оплате), для него форму разрабатывать не нужно.
В нашем примере необходимо разработать 3 формы:
- Создания запроса на оплату;
- Проверка запроса на оплату;
- Формирования печатной формы.
Эти формы используют одни и те же данные. Основа в каждой из этих форм одна — запрос на оплату счета. Но каждая следующая форма имеет более расширенный функционал, чем предыдущая. Например, в форме Проверки запроса есть вся информация из формы создания запроса + статус заявки (Одобрено или нет). А следующая форма имеет по сравнению с предыдущей еще и возможность печати запроса. При необходимости ненужные поля из предыдущих форм можно скрыть.
Здесь важно понимать, что это все-таки не одна, а три разных формы. И каждая из них создается заново либо копируется с предыдущей формы, после чего в нее вносятся необходимые изменения.
Теперь рассмотрим сам процесс создания формы (например, Создания запроса на оплату).
Форма создается посредством выбора и перетаскивания в активное окно необходимых полей. Для выбора предлагаются поля (атрибуты), которые мы назначили конкретным формам на предыдущем этапе.
Форма создания запроса в итоге будет выглядеть так:
Здесь мы видим поля:
- Срок оплаты;
- Сумма счета;
- Номер счета;
- Контрагент;
- Присоединенный файл (возможно прикрепить счет на оплату).
Также для более удобного использования форм можно воспользоваться Layot (варианты расположения частей формы).
Макет формы можно разделить:
- на три равные части (33%-34%-33%);
- на две равные (50%-50%) части;
- на две неравные (70%-30%, 30%-70%) части;
- оставить макет неделимым (Full layout).
На этапе создания форм можно настроить видимость полей и функции редактирования для разных пользователей.
Например, у следующего этапа Проверки запроса есть своя форма, в которой руководителю видны поля, созданные сотрудником на предыдущем этапе, но руководитель эти поля редактировать не может. Зато ему доступны собственные поля, которые не видны сотруднику: поле Одобрено с вариантами Yes/No.
Поле Причина отказа становится видным для руководителя, только если в поле Одобрено он выбрал вариант No. То есть видимость полей можно настроить не только в формате Видно-Не видно, но и в зависимости от каких либо условий. Это условие выглядит так
PaymentRequestApproved is equal to false
Если Руководитель установил вариант Yes, становится доступной функция распечатать запрос на оплату. Для него уже никакие функции недоступны, кроме Generate template.
4. Определение бизнес-правил
Далее необходимо разработать бизнес-правила, чтобы система автоматически делала некоторые вещи на основании каких-либо данных.
В Bizagi предусмотрено три этапа установки бизнес-правил:
- Define Expressions — предполагает обработку условий
- Activity Actions (Events) — предполагает обработку событий
- Perfomance — предполагает обработку пользователей, работающих на том или ином этапе бизнес-процесса.
Define Expressions
На этапе Define Expressions идет определение вариантов поведения системы при тех или иных условиях. В нашем случае это результат проверки запроса, два варианта (две стрелки), которые ведут от Результата проверки. При нажатии на стрелку, ведущую к следующему этапу, открывается форма, в которых заполняются условия перехода на тот или иной этап.
Если по результатам проверки руководитель отказывает, то процесс переходит в стадию Оповестить о причине отказа.
Если по результатам проверки Руководитель одобрил запрос, процесс переходит на этап Распечатать счет.
Activity Actions
На этапе Activity Actions мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):
- при открытии формы;
- при сохранении;
- при выходе из формы.
Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:
- Дата — здесь мы указываем, что дата запроса автоматически заполняется текущей датой <PaymentRequest.RequestDate>=DateTime.Today
- Автор (сотрудник) — здесь прописываем, что тот, кто инициировал документ, автоматически становится его автором <PaymentRequest.Employee>=Me.Case.Creator.Id
Perfomance
Следующий шаг — это Perfomance. Здесь мы прописываем, кто на каком этапе работает с бизнес-процессом, отвечает за его выполнение.
- На этапе Создания сделки работает сотрудник, создавший эту сделку. User Id Equal Case Creator
- На этапе Проверки запроса работает Руководитель того, кто создал документ. User Id Equals CurrentAssigneeBoss
5. Описание правил оповещения
После того, как мы прописали, как работают бизнес-правила, мы описываем правила оповещения.
Сотрудник не может постоянно находиться в одной системе, у него есть текущие дела и работа в других программах. Как он будет получать информацию об изменениях по бизнес-процессу, которые требуют его участия? Это настраивается с помощью Notification. В BPMN 2.0 есть такое понятие, как notification, и здесь мы можем оповещение привязать к системе.
Оповещения бывают двух видов:
- автоматические (в самой системе есть свой email-сервер) — например, при переходе с одной стадии в другую;
- создаваемые вручную — например, когда пользователь сам хочет отправить сообщение для какого-либо уточнения, но без изменения этапа заявки.
Использовать можно оба вида оповещений одновременно.
В нашем бизнес-процессе при смене этапа (Одобрен или Не одобрен запрос на оплату), Сотруднику отправляется сообщение о том, что счет одобрен или требует уточнения.
6. Создание печатной формы
В нашем примере сотрудник, кроме электронного документа, хочет получить еще и печатную форму. То есть, если руководитель одобрил запрос на оплату, то он распечатывает, подписывает документ и отдает секретарю для дальнейшей передачи в бухгалтерию. Документ сохраняется не только в системе, но и в печатной форме.
В системе можно создавать, так называемый, document templates. Для печатной формы запроса можно использовать word, excel или простой текст. Мы создали форму, которую должен распечатать тот, на ком заканчивается процесс, и поставить свою подпись. В этой печатной форме видна вся основная информация по запросу:
- Дата создания;
- Пользователь;
- Номер счета;
- Дата счета;
- Сумма счета;
- Основание;
- Подпись ответственного лица.
При получении такой формы бухгалтерия сразу может идентифицировать счет, который необходимо оплатить.
Исполнение бизнес-процесса
После того, как мы разработали бизнес-процесс в системе Bizagi, необходимо создать пользователей, указать их структуру, после чего эти пользователи смогут работать в системе.
Рассмотрим, как происходит исполнение созданного нами бизнес-процесса:
Пользователь выбирает бизнес-процесс из тех, что предложены в системе. В данном случае это бизнес-процесс Request Payment. Открывается форма создания запроса.
1. Пользователь заполняет необходимые поля (поле Дата и Автор заполнены автоматически). Пользователь прикрепляет счет на оплату.
2. Руководитель получает оповещение о том, что необходимо Проверить запрос.
3. Руководитель входит в форму запроса, где видит форму проверки запроса с доступными действиями — выбрать, одобрен или не одобрен запрос.
Если руководитель выбрал Yes:
4. Появляется кнопка Generate document для распечатки запроса. Руководитель выводит печатную форму и подписывает ее.
5. Сотрудник, инициировавший запрос, получает уведомление об одобрении счета
Если руководитель выбрал No:
4. Сотрудник, инициировавший запрос, получает уведомление об отказе в оплате счета.
Бизнес-процесс исполнен.
Еще несколько слов о Bizagi
В Bizagi вы всегда сможете посмотреть аналитику по исполнению бизнес-процессов.
В системе предусмотрена интеграция: возможно “снаружи” подключаться к Bizagi, либо из самой Bizagi подключаться к другим программам посредством API. Она использует web-сервисы и SOAP.
Необходимо также напомнить, что система имеет локализацию — варианты на разных языках. Есть в Bizagi Modeler и русский перевод. Сразу скажу, что этот перевод, к сожалению, не всегда правильный. К тому же, вся документация Bizagi представлена только на английском. Поэтому я предпочитаю работать с системой на английском языке.
В заключение хочется отметить, что создание бизнес-процесса — долгая и трудоемкая работа, так как мы пишем практически новое приложение, для которого разрабатываем с нуля структуры данных и формы.