Geekly Articles each Day
📜 ⬆️ ⬇️

Bizagi. Description. Example

I wrote this article in continuation of an article on BPM systems . And here I want to talk about the principles of BPMS on the example of a particular system - Bizagi. I will try to explain how the process of modeling, developing and executing a business process in this system takes place on a practical example.

Bizagi: Model. Build. Run


Bizagi is a BPM system developed by the eponymous company and aimed at modeling, execution, automation and analysis of business processes. The Bizagi system includes 3 modules for full process setup:


Consider each of these modules in more detail.

Modeler


Modeler is a business process designer where a sequence of actions and events is modeled. It is important to understand that the business process created in Modeler is only a picture, a graphic representation of the process being modeled, but not the automated algorithm itself.
')
Directly responsible for the business process, the roles and business rules are assigned at the next stage of programming and do not depend on what design you have modeled at this stage. The design of a business process is needed simply to agree on a scheme for working with users.

You can use one of three ways to model a business process:




The business process created in Modeler can be edited, saved, exported in various formats (pdf, html).

Business process modeling is performed in BPMN 2.0 format. This format is somewhat different from the well-known many BPMN 2.0, I ran into this in practice. Some features that are implied in BPMN 2.0 and in some other programs designed to work exclusively with modeling, you will not find in Bizagi format. For example, there is no so-called “external entity”. But Bizagi has its own development, which is not in other systems, for example, Mailstone - an intermediate stage.

Business process maps created in Modeler can be “shared” on the Bizagi portal or used as a collaborator, that is, several employees can work together, which is very convenient.

Modeller has a Russian-language interface, unlike the other two modules.

Let me remind you once again that Modeler is intended only for modeling business processes. That is, if you need only the design of a business process, this module will be enough for you. If you need not only to model, but also to develop and execute business processes, you will need the Studio module, which has its own business process modeler.

Studio




A simulated business process card should work. The user must log in and interact with various forms. Studio allows you to develop an interface and forms that people will work with. Below we take a closer look at all aspects of business process development at Bizagi Studio.

I want to note that Modeler and Studio are free. Up to 20 test users are included in the basic Studio package.

Engine




Engine is a runtime environment that allows users to log into the system and work on it, performing certain business processes.

Engine licenses are paid. Only test mode is free.

Engine has two types of license:

At the same time, companies with up to 50 users receive a 50% discount - this is the so-called Starter kit, aimed at supporting small and medium-sized businesses. If the company employs more than 50 users, you will have to pay the full cost of the licenses.

Engine involves step-by-step execution of the developed business process, taking into account all the conditions specified in Studio.


Without the Engine module, you cannot fully work in the system and execute the specified business processes.

How does bizagi work


What do we do in Bizagi if we need to automate any business process? Consider the algorithm of actions on the example of the approval of the application for cash flow. In the article about BPM systems we saw how this business process was implemented on a real project through the accounting system, now we will see how to organize this correctly in the BPM system.

1. Modeling

Business process modeling is performed by dragging graphic elements proposed in Bizagi into the work area.

Above, I wrote that the Studio interface is in English, but in the business process map itself we can use the Russian language.

We model the Payment Request business process diagram: we define the beginning of the process, events, alerts, business rules and the end of the business process.

The task is to control the payment of bills. The sequence of actions of this business process is as follows:
1. The employee who receives an invoice for payment must create a request for payment.
2. The manager must verify the request and select one of the following options:

3. In the first option, the Employee receives a notice of the manager’s refusal. This is where the business process ends.
3. In the second case, the Manager must Print, sign the request and send it to the accounting department, the business process ends there.

The graphic map of the business process looks like this:



2. Development of data structure

After the business process is modeled, we proceed to the development of the data structure. At this stage, we prescribe, in what forms, what fields are stored certain data and indicate their relationship.

In our example, we need to develop three entities (Entity):

For each of these entities, it is necessary to prescribe attributes (fields) that will be available for filling. Attributes are divided into:

In the screenshot you can see which attributes are registered for each entity.



It is also necessary to indicate the relationship between these entities. We prescribe that entities Causes of Failure and Counterparties are included in the essence of the Invoice Payment Request.

3. Creating forms (user interface)

After we have developed the data structure, we need to decide how the user logs into the system, how it interacts with it. And here we need to create a user interface.

When we have modeled a business process, we enter it and see that each of these boxes in the diagram designating the stages is a form that needs to be developed.
The form is what the user will work with later.

I want to draw your attention to the fact that only those forms are developed that the user is working on. If any of the steps implies an automatic action (for example, notifying the Employee of the refusal to pay), there is no need to develop a form for it.

In our example, it is necessary to develop 3 forms:

These forms use the same data. There is one basis in each of these forms - a request to pay the bill. But each following form has more advanced functionality than the previous one. For example, in the Request Verification form there is all the information from the request creation form + application status (approved or not). And the next form is compared with the previous one and the ability to print the request. If necessary, unnecessary fields from the previous forms can be hidden.
Here it is important to understand that it is still not one, but three different forms. And each of them is recreated or copied from the previous form, after which the necessary changes are made to it.

Now consider the process of creating a form (for example, Creating a request for payment).

The form is created by selecting and dragging the required fields into the active window. To select the proposed fields (attributes), which we assigned to specific forms in the previous step.



The request creation form will look like this:



Here we see the fields:

Also for more convenient use of forms, you can use Layot (options for the location of parts of the form).

Layout of the form can be divided:




At the stage of creating forms, you can customize the visibility of fields and editing functions for different users.
For example, the next stage of the Request Verification has its own form in which the manager can see the fields created by the employee at the previous stage, but the manager cannot edit these fields. But it has its own fields that are not visible to the employee: the field is Approved with options Yes / No.



The Reason for Failure field becomes visible to the manager only if he selected option No. in the Approved field. That is, the visibility of the fields can be configured not only in the Visible-Not Visible format, but also depending on any conditions. This condition looks like this.
PaymentRequestApproved is equal to false



If the Manager has set the option Yes, the function becomes available to print a request for payment. For him, no functions are available except Generate template.



4. Defining business rules

Next, you need to develop business rules so that the system automatically does some things based on any data.

Bizagi has three stages of setting business rules:


Define expressions
At the stage of Define Expressions, the system’s behavior under certain conditions is determined. In our case, this is the result of checking the request, two options (two arrows) that lead from the result of the check. Clicking on the arrow leading to the next stage opens a form in which the conditions for the transition to this or that stage are filled.

If, based on the results of the inspection, the manager refuses, then the process moves to the Stage about the reason for the refusal.



If, as a result of the audit, the Manager approved the request, the process goes to the Print invoice stage.

Activity Actions
At the stage of Activity Actions, we can write the predefined fields. Predefined fields can be filled in three cases (optional):

For example, at the stage of creating a request for payment, we can indicate that when opening a form, we have two predefined fields:




Perfomance
The next step is Perfomance. Here we prescribe who at what stage works with the business process, is responsible for its implementation.




5. Description of alert rules
Once we have prescribed how the business rules work, we describe the alert rules.

The employee can not always be in one system, he has current affairs and work in other programs. How will he receive information about changes in the business process that require his participation? This is configured using Notification. In BPMN 2.0, there is such a thing as notification, and here we can tie a notification to the system.

Alerts are of two types:

You can use both types of alerts at the same time.

In our business process, at a change of stage (Approved or Unapproved request for payment), a message is sent to the Employee that the invoice is approved or needs clarification.

6. Creating a print form

In our example, an employee, in addition to an electronic document, also wants to get a printed form. That is, if the manager approved the request for payment, he prints, signs the document and gives it to the secretary for onward transmission to the accounting department. The document is stored not only in the system, but also in printed form.

The system can create so-called document templates. For the print request form, you can use word, excel or plain text. We created a form that should be printed out by the one on whom the process ends, and put his signature. In this print form, you can see all the basic information on request:




Upon receipt of this form of accounting, it can immediately identify the invoice to be paid.

Business Process Execution


After we have developed a business process in the Bizagi system, you need to create users, specify their structure, after which these users can work in the system.

Consider how the execution of the business process created by us takes place:

The user selects a business process from those proposed in the system. In this case, the Request Payment business process. The request creation form opens.

1. The user fills in the required fields (the Date and Author fields are filled in automatically). The user attaches an invoice for payment.


2. The manager receives an alert that it is necessary to check the request.
3. The manager enters the request form, where he sees the request validation form with the available actions - choose, approved or not approved the request.

If the manager chose Yes:
4. The Generate document button appears to print the request. The head displays the printed form and signs it.
5. The employee who initiated the request is notified of the approval of the account.

If the manager chose No:
4. The employee who initiated the request is notified of the refusal to pay the bill.
Business process is executed.

A few more words about Bizagi


In Bizagi you can always see analytics on the execution of business processes.

The system provides for integration: it is possible to “outside” connect to Bizagi, or from Bizagi itself to connect to other programs via the API. It uses web services and SOAP.

It is also necessary to remind that the system has localization - options in different languages. There are in Bizagi Modeler and Russian translation. I must say that this translation, unfortunately, is not always correct. In addition, all Bizagi documentation is presented only in English. Therefore, I prefer to work with the system in English.

In conclusion, I would like to note that the creation of a business process is a long and laborious work, since we are writing a practically new application for which we are developing from scratch data structures and forms.

Source: https://habr.com/ru/post/273017/

More articles:


All Articles