Bizagi modeler инструкция на русском

Время на прочтение
9 мин

Количество просмотров 92K

Эту статью я написал в продолжение статьи о 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 мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):

• при открытии формы;
• при сохранении;
• при выходе из формы.

Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:

• Дата — здесь мы указываем, что дата запроса автоматически заполняется текущей датой <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 представлена только на английском. Поэтому я предпочитаю работать с системой на английском языке.

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

Overview

Before moving into each topic we would like to give our new users a taste of with Bizagi Modeler.

To do so, we will take you through a step by step guide to diagram a common process: the Purchase Request.

Before you start

It is necessary to have Bizagi Modeler installed before starting this guide.

What you need to do

This is a guide on how to use the tool to model and document your processes. We encourage you to review in detail each step and to click the links in each section for more information.

Understand your process: Purchase Request

When modeling a process it is important to understand the steps it goes through, the routing, the inputs and outputs.

The Purchase Request process formalizes the acquisition of goods and services. Although the process can change substantially from one company to another, it is a good place to start modeling the company processes.

The Purchase request process begins with the identification of products or services needed by the applicant. According to the price of the request, it needs approval from their boss. The boss may approve the request, request changes, or reject it.

If the request is approved, the process evaluates if the boss has the level of authority to approve the amount. If the boss does not, the request is escalated to his/her boss, and so on.

Once the request has been approved, quotations are requested by the Purchasing department, to have the appropriate number of potential suppliers. Quotations are selected according to the delivery date, price, and quality.

The Purchasing department selects a supplier and generates a Purchase Order that is sent to the selected supplier and saved in the company´s ERP.

Process Modeling

To model the Purchase Request process, open Bizagi Modeler desktop application. The first thing you see in a new model is a diagram with an empty pool:

As a good practice, the pool has the same name as the process, to change the name of any element double-click it, press F2, or right-click it and select from the display menu.

Now before adding shapes to the diagram, identify the main roles (or resources) related to the process.        

In this case, there are 3 participants: the applicant, the boss, and the purchasing department. Each participant is represented by a lane. Therefore, you should add 3 lanes in the pool with their respective names.

To add any element to the diagram you can drag a drop them from the Palette on the left. Drag and drop the lanes in the pool and name them as explained before.

Then, add the shapes to the diagram.

All processes must have a Start event from which the process begins. Drag and drop the Start event into the lane of the participant that starts the process, in this case, the Applicant:

The next step is the first task: . To create the task you have two options:

•Drag and drop the task shape and connect the start event to it.

•Use the Pie Menu displayed from the start event, with this option the task is automatically connected to the start event:

Repeat this to create the task.

At this point, the phase of the process is finished and it is necessary to include its milestone. To do so drag and drop the milestone shape and rename it.

To start diagramming the phase create its milestone just like the phase.

Continue adding the required shapes until your diagram is complete.

To connect two elements in a sequence flow, using the Pie Menu, drag the corresponding shape to the second element. They will be automatically connected.

The following image displays the basic diagram of the process.

Transform elements

Once you have diagrammed the basics of the process, some adjustments are needed to reflect the reality of the process.

•The Notification Tasks consist of emails automatically sent based on a decision by the Immediate Supervisor (Boss). Therefore these tasks must be changed to Script tasks.

•The Task must be transformed to a Sub-process where several activities take place to select a supplier.

•The Task is also a Sub-process where the purchase order is sent to the Supplier and created in the ERP system.

To do these adjustments it is not necessary to introduce another element to the process, but to change the existing elements. For example to change the task, right-click it. In the display menu go to and select . Repeat this for the other two Notification tasks.

For the and tasks follow the same procedure, right-click the tasks and select .

Sub-process

Now is necessary to define the tasks that take place within each sub-process. To do so right-click the sub-process and select .

Bizagi asks if you want to create a new process for the sub-process or if you want to assign one to it. As we haven’t created any other process, a new process is needed, hence choose this option.

With this, a new diagram is created for you to model the sub-process. Repeat this for the sub-process.

In these two new diagrams, model the two sub-processes the same way we did with the process. Then rename the diagrams the same way an element is renamed.

In the sub-process, the services task might fail, because of this it is necessary to create an attached event to manage this error.

To do so right-click the task, go to and select . Then connect it to the following task.

Once you have modeled these two sub-processes you have finished modeling your first process.

The next step is to document it.

Process Documentation

Documenting a process is one of the most important steps when creating a model in Bizagi Modeler. This is where all relevant information for the process is included in the model so any user can understand it. You can include information at process level as well as detailed information at an element level in your diagram.

To add information at the process level right-click outside of the boundaries of the pool and select .

This enables the window at the right of the screen, where you can include: name, description, version, and author of the process.

You can also open this window by pressing the key.

With the displayed, select any element, and their respective properties will be shown.

Thereby, you can enter detailed information about each step of your flow (each element).

Task Documentation

In tasks documentation, you can also include Resources that are related to each role of the RACI Model.

A resource is a Business Entity or Role that controls or is responsible for a task. To define the resources of the model click the option in the tab.

, or any resource. In the model create the resources of the 3 main participants of the process: Applicant, Boss and Purchasing department.

Select and enter the name, description, and type (role or entity) of the resource.

Once the resource is created you can associate it to any task role.

Now document all the tasks of the model.

Create as many resources as necessary, however, it is not necessary to have resources in all roles of a task. For example, in a script task, as it is an automatic task, there may be no roles or just a performer.

Gateway Documentation

In the gateway’s properties, when alternative paths are available, documentation is included as conditional expressions for each decision branch representing a path.

You may define the condition for each path either in the Gateway itself, or in each of its decision branches.

To define the conditions of the gateway, on its properties window, go to the tab. In the , for each of the outbound paths there is a corresponding row identified by the branch name. In the model the gateway has 4 outbound paths: No, Changes are required, Requires another approval and Yes.

You may either define a conditional expression for the selected path or designate it as the Default path (the path that is chosen if no other conditions are met in other out coming flows). Note the visual representation of a default path is a small oblique line crossing the decision branch.

Once you have documented the basic properties of all the elements of the model. You can extend your documentation to include any type of information that you find relevant for your processes, through extended attributes.

Next steps

The Enterprise plan journey for the Bizagi Modeler services is to: create a model, which has been explained in this guide, save the model to the cloud, collaborate with your pairs or others to improve your model and finally publish the process to the end users.

There are also additional features that are useful for you:

•Compare your model with our It can be downloaded from the Bizagi Xchange web page.

•Publish your complete documentation. You can choose between multiple formats.

•Exchange your model. You can exchange your model in multiple formats.

•Simulate the process flow with Bizagi Modeler simulation tool (Only for Bizagi Modeler paid plans).

Remember that Bizagi Modeler offers advance features exclusive for certain paid plans. In the following article, you can overview the most relevant features available in each plan and choose the appropriate one for you.

В бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, 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 – в поле «дата запроса» будет добавлять системная дата;

Выражение:

<TekhnologicheskoeTrebova.Nubertrebovanie> = Me.Case.CaseNumber;:

<TekhnologicheskoeTrebova.Requestdate> = 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

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

Проверка работоспособности бизнес-процессов

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

Метки: bizagiBizAgi Process Modeler