Разработка и исполнение бизнес-процессов в Bizagi BPM
В бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для лучшего понимания бизнес-процессов и его специфики.
Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Данные бизнес-процессы требуют глубоких знаний BPMN, а также внимательного отношения к каждой детали, так как вы, по сути, создаете программу (алгоритм) для компьютера, просто используете для этого не текстовый язык, а графические нотации.
Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет вести контроль всех процессов в режиме реального времени, и на основе получаемых на каждом из этапов данных, руководитель компании и подразделений всегда смогут понимать, на каком этапе находится работа по тому или иному процессу. Подобный метод позволяет значительно повысить эффективность управления.
Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0, или декомпозиция IDF0 до уровня потока работ (EEPC). А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.
У нас будут смоделированы неисполняемые бизнес-процессы (бизнес-процесс разработка программного обеспечения с техническим заданием, второй — доработка программного обеспечения без технического задания, третий — заведение технического требования, и четвертый — заведение требования на документацию программного обеспечения), произведен функционально-стоимостной анализ, затем они будут доработаны до исполняемых бизнес-процессов (будут добавлены графические формы, модели данных, пользователи и тд) и произведена автоматизация действий.
В качестве средства BPM была выбрана – Bizagi. Она удовлетворяет нашим условиям выбора. Эта система является бесплатная, прекрасно интегрируется с различными веб сервисами, пользователи прекрасно интегрируются с Active Directory, система использует операционную систему семейства Windows, SQL базу данных и IIS веб сервис. Система проста для разработки в ней бизнес-процессов и удобна в использовании. Нотация для моделирования будет использоваться BPMN 2.0
В среде моделирования — Modeler будет произведено моделирование бизнес-процессов. В среде проектирования — Suit для этих процессов будет спроектирована база данных, спроектированы графические формы, будут заданы бизнес правила, заданы группа пользователей. В Engine будут произведены пуско-наладочные работы.
Пользователи будут делиться на 9 бизнес ролей: контрагент – внешний клиент, менеджер проекта, руководитель проекта, аналитик, тестировщик, программист; администратор, бизнес аналитик и аналитик (не будут участвовать в бизнес-процессах, но такие бизнес роли будут предусмотрены системой).
Бизнес-процесс «Разработка программного обеспечения с техническим заданием» будет автоматизировать бизнес-процесс начиная от момента подачи заявки клиента и заканчивая приемкой.
Процесс «Разработка программного обеспечения» осуществляется по водопадной модели жизненного цикла разработки ПО. Каскадная (водопадная) модель строго следует последовательности всех этапов разработки ПО и не предполагает возвращения с текущего этапа на предыдущий. Модель жизненного цикла будет включать следующие этапы: выработка системных требований, выработка требований к ПО, анализ, проектирование, кодирование, тестирование, эксплуатация. Разработанная схема бизнес-процесса «Разработка программного обеспечения с техническим заданием» представлена ниже
После разработки бизнес-процесса необходимо разработать модель данных.
Главная таблица «DorabotkaPO» будет иметь следующий атрибутивный состав: email, веб сайт, дата заказа, имя, мобильный телефон, номер заявки, отчество, прикрепленный документ, сообщение, статус разработки, статус тестирования, фамилия и связь с таблицей «Approval» и «Концепция». Таблица «Approval» будет иметь следующие атрибуты: визирование менеджер, визирование менеджер проекта, дата визирования менеджером, дата визирования менеджером проекта, менеджер, менеджер проекта. Таблица «Концепция»: дата заявки, дата утверждения, имя пользователя, имя утвердившего, комментарий, концепция, утверждение и связь с таблицей техническое задание. «Техническое задание» имеет следующий атрибутивный состав: стоимость аналитика, стоимость программиста, стоимость тестировщика, трудозатраты на аналитика, трудозатраты на программиста, трудозатраты на тестировщика.
После разработка модели данных необходимо разработать визуальные формы.
После разработки графических форм необходимо разработать бизнес правила. Для каждого условия «исключающие или» нам необходимо прописать правило, по которому будет проверяться условие для дальнейшего перехода к следующей функции
DorabotkaPOTZ.idKontsepsiya.Utverzhdenie is equal to true
DorabotkaPOTZ.idKontsepsiya.Utverzhdenie is equal to false
DorabotkaPOTZ.Statusrazrabotki is equal to false; DorabotkaPOTZ.Statusrazrabotki is equal to true;
DorabotkaPOTZ.Statustestirovaniya is equal to true;
DorabotkaPOTZ.Statustestirovaniya is equal to false;
После определения бизнес правил определяем исполнителей задач.
У нас будут существовать следующие роли: chief manager (руководитель проекта), devOps (системный администратор), manager (менеджер), programmer (программист), stakeholder (внешнее лицо), tester (тестировщик), admon viewer (администратор).
Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей.
Определяем условия для всех функций:
Or Role==Stakeholder or Role == Admon Viewer;
Or Role==Manager or Role == Admon Viewer;
Or Role==Chief manager or Role == Admon Viewer;
Or Role==Programmer or Role == Admon Viewer;
Or Role==DevOps or Role == Admon Viewer;
Or Role==Analyst or Role == Admon Viewer;
Or Role==Tester or Role == Admon Viewer;
Бизнес-процесс «Технологическое требование» будет автоматизировать процесс начиная от подачи заявки клиента для реализации технологического требования под необходимые нужды и заканчивая выкладыванием решения в открытый доступ. В качестве технологического требования может быть: создание серверной инфраструктуры, разворачивание необходимых виртуальных машин, настройка коммутационного оборудования и другое.
«Технологическое требование» будет включать следующие этапы: инициализация заявки, производственные работы, верификация инициатором и выкладывание в открытый доступ.
Разработанная модель данных бизнес-процесса «Технологическое требование» представлена ниже
Атрибуты главной таблицы «Требование»
Таблица WSUSER является системной, из системной таблицы мы можем получить текущего пользователя, контактные данные и всю остальную информацию. Бизнес-процесса «Технологическое требование» имеет следующие визуальные формы
Для каждого условия «исключающие или» нам необходимо прописать правило, по которому будет проверяться условие для дальнейшего перехода к следующей функции.
Tekhnologicheskoetrebova.ready is equal to true;
Tekhnologicheskoetrebova.ready is equal to false;
Tekhnologicheskoetrebova.status_analyst is equal to true;
Tekhnologicheskoetrebova. status_analyst is equal to false;
На этапе определения «Activity Action» (Events) на кнопку «Сохранить» в графическую форму процесса «Выполнение» добавляем следующие выражения:
Currenttask –в поле «номер заявки» будет подставляться системный номер заявки;
CurrentData – в поле «дата запроса» будет добавлять системная дата;
= DateTime.Now; После определения бизнес правил определяем исполнителей задач.
У нас будут существовать следующие роли: programmer (программист), stakeholder (внешнее лицо), devops (системный администратор), admon viewer (администратор), analyst (аналитик).
Мы можем определить 4 состояний задач для исполнения пользователями: по нагрузке, все, последовательны, первый доступный. Имеются условия and (и), or (или) и properties (свойства), благодаря котором мы можем масштабировать количество пользователей. Определяем условия для всех функций
Or Role==Stakeholder or Role == Admon Viewer;
Or Role==Manager or Role == Admon Viewer;
Or Role==Chief manager or Role == Admon Viewer;
Or Role==Programmer or Role == Admon Viewer;
Or Role==DevOps or Role == Admon Viewer;
Or Role==Analyst or Role == Admon Viewer;
Or Role==Tester or Role == Admon Viewer;
Для запуска бизнес-процессов в корпоративной сети необходимо развернуть серверную операционную систему Windows, настроить DNS сервер, установить IIS сервер, развернуть базу данных.
В качестве серверной операционной системы была выбрана Windows Server 2012 R2. В качестве сервера базы данных был выбран — SQL Server.
SQL Server является одной из наиболее популярных систем управления базами данных (СУБД) в мире. Данная СУБД подходит для самых различных проектов: от небольших приложений до больших высоконагруженных проектов. SQL Server характеризуется такими особенностями как: 1) производительность. SQL Server работает очень быстро; 2) надежность и безопасность. SQL Server предоставляет шифрование данных; 3) простота. С данной СУБД относительно легко работать и вести администрирование.
После установки СУБД устанавливаем оснастку IIS и проверяем работоспособность веб сервера.
Основным компонентом IIS является веб-сервер, который позволяет размещать в Интернете сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP (т.е все основные протоколы). По данным компании Netcraft на июнь 2015 года, почти 22 млн сайтов обслуживаются веб-сервером IIS, что составляет 12,32 % от общего числа веб-сайтов, остальные веб-серверы используют Apache, Nginx. Производим экспорт базы данных (формат bak) на разрабатываемой машине и импортируем ее на сервер через MSSQL Server Management
Проверяем работоспособность IIS и портала BPM Bizagi
Необходимо добавить организационные структуры, для разделения пользователей по ролям и отношению к организации
Проверка работоспособности бизнес-процессов
Экспортируем наши бизнес-процессы в статические веб страницы и создадим портал, где мы будем хранить всю документацию по бизнес-процессам, и где любой пользователь внутренней сети предприятия сможет посмотреть её
Источник
Bizagi. Описание. Пример
Обзор программной системы Bizagi. Предназначение BPM-системы. Основные функции и возможности. Возможности моделирования, разработки бизнес-процессов, модуль исполнения. Настройки доступа. Подробное описание особенностей работы в Bizagi для пользователей и разработчиков.
Эту статью я написал в продолжение статьи о BPM-системах. И здесь я хочу рассказать о принципах работы BPMS на примере конкретной системы — 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 мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):
- при открытии формы;
- при сохранении;
- при выходе из формы.
Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:
- Дата — здесь мы указываем, что дата запроса автоматически заполняется текущей датой
=DateTime.Today
Автор (сотрудник) — здесь прописываем, что тот, кто инициировал документ, автоматически становится его автором
=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, необходимо создать пользователей, указать их структуру, после чего эти пользователи смогут работать в системе.
Рассмотрим, как происходит исполнение созданного нами бизнес-процесса:
1. Пользователь выбирает бизнес-процесс из тех, что предложены в системе. В данном случае это бизнес-процесс Request Payment. Открывается форма создания запроса.
2. Пользователь заполняет необходимые поля (поле Дата и Автор заполнены автоматически).
3. Пользователь прикрепляет счет на оплату.
4. Руководитель получает оповещение о том, что необходимо «Проверить запрос».
5. Руководитель входит в форму запроса, где видит форму проверки запроса с доступными действиями: «выбрать», «одобрен или не одобрен запрос».
6. Если руководитель выбрал Yes: появляется кнопка Generate document для распечатки запроса. Руководитель выводит печатную форму и подписывает ее.
8. Сотрудник, инициировавший запрос, получает уведомление об одобрении счета.
8. Если руководитель выбрал No: сотрудник, инициировавший запрос, получает уведомление об отказе в оплате счета.
Еще несколько слов о Bizagi
В Bizagi вы всегда сможете посмотреть аналитику по исполнению бизнес-процессов. В системе предусмотрена интеграция: возможно “снаружи” подключаться к Bizagi, либо из самой Bizagi подключаться к другим программам посредством API. Она использует web-сервисы и SOAP.
Необходимо также напомнить, что система имеет локализацию — варианты на разных языках. Есть в Bizagi Modeler и русский перевод. Сразу скажу, что этот перевод, к сожалению, не всегда правильный. К тому же, вся документация Bizagi представлена только на английском. Поэтому я предпочитаю работать с системой на английском языке.
В заключение хочется отметить, что создание бизнес-процесса — долгая и трудоемкая работа, так как мы пишем практически новое приложение, для которого разрабатываем с нуля структуры данных и формы.
Источник