Bizagi. Description. Example

  • Tutorial
I wrote this article as a continuation of the article on BPM systems . And here I want to talk about the principles of BPMS on the example of a specific system - Bizagi. I will try to explain how the process of modeling, development and execution of a business process in this system occurs on a practical example.

Bizagi: Model. Build. Run


Bizagi is a BPM system developed by the company of the same name and aimed at modeling, execution, automation and analysis of business processes. The Bizagi system includes 3 modules for fully configuring processes:

  • Modeler - a full-featured process modeling environment in BPMN notation;
  • Studio - a business process development environment;
  • Engine - a process runtime that is available to users in any browser from any device.

Let's consider each of these modules in more detail.

Modeler


Modeler is a business process designer that simulates a sequence of actions and events. It is important to understand that the business process created in Modeler is just a picture, a graphic display of the simulated process, but not yet an automated algorithm of actions.

Directly responsible for the business process, roles and business rules are assigned at the next stage of programming and do not depend on which design you 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:
  • New Process - create your own new business process;
  • Import Process - import a business process;
  • Process Xchange - choose a ready-made model from the database of business processes proposed by Bizagi. By choosing a template, you can refine it to suit the realities of your business. All presented models are written in English.




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 slightly different from the well-known to many BPMN 2.0, I came across this in practice. You will not find some features that are implied in BPMN 2.0 and in some other programs designed to work exclusively with modeling in the Bizagi format. For example, there is no so-called “external entity”. But in Bizagi there are own developments that are not in other systems, for example, Mailstone - an intermediate stage.

The business process cards created in Modeler can be either “shared” on the Bizagi portal or collaborative, that is, several employees can work together, which is very convenient.

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

I remind you once again that Modeler is intended only for modeling business processes. That is, if you only need a business process design, 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 a person will work with. Below we will take a closer look at all aspects of developing a business process in Bizagi Studio.

I want to note that Modeler and Studio are free. The basic Studio package includes up to 20 test users.

Engine




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

Engine licenses are paid. Only the test mode is free.

Engine has two types of licenses:
  • permanent license;
  • license for a year.

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

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


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

How Bizagi Works


What do we do at Bizagi if we need to automate a business process? Consider the algorithm of actions on the example of matching the application for cash expenditures. 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 it correctly in the BPM system.

1. Modeling

Modeling of a business process occurs by dragging the graphic elements proposed in Bizagi into the work area.

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

We simulate the scheme of the business process of the Payment Request: we determine 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 the invoice for payment must create a request for payment.
2. The manager must check the request and choose one of the options:
  • Refuse;
  • To approve.

3. In the first option, the Employee receives a notice of the refusal of the head. 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, this is where the business process ends.

The graphic map of the business process looks like this:



2. Development of the 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, which fields this or that data is stored and indicate their relationships.

In our example, we must develop three entities (Entity):
  • Request for invoice payment;
  • Counterparty (supplier who needs to pay the bill);
  • Rejection reason.

For each of these entities, it is necessary to prescribe the attributes (fields) that will be available for filling. Attributes are divided into:
  • Predefined (there are a lot of them) - attributes that the system itself offers;
  • Custom - those that the user creates manually.

The screenshot shows which attributes are registered for each entity.



It is also necessary to indicate the relationships between these entities. We prescribe that the entities Reasons for refusal and Counterparties are included in the entity Request for payment of an invoice.

3. Creating forms (user interface)

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

When we simulated a business process, we enter it and see that each of these squares in the diagram designating the stages is a form that needs to be developed.
A form is what the user will subsequently work with.

I want to draw your attention to the fact that only those forms that the user is working on are developed. If any of the steps involves an automatic action (for example, notifying the Employee about a refusal of payment), you do not need to develop a form for him.

In our example, it is necessary to develop 3 forms:
  • Create a request for payment;
  • Check request for payment;
  • Formation of the printing form.

These forms use the same data. The basis in each of these forms is one - a request for payment of an invoice. But each next 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, in comparison with the previous one, also has the ability to print a request. If necessary, unnecessary fields from previous forms can be hidden.
It is important to understand here that this is 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.

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

A form is created by selecting and dragging the required fields into the active window. The fields (attributes) that we assigned to specific forms at the previous stage are offered for selection.



The form for creating a request as a result will look like this:



Here we see the fields:
  • Due date;
  • Invoice amount;
  • Account number;
  • Counterparty
  • Attached file (it is possible to attach an invoice for payment).

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

The layout of the form can be divided:
  • into three equal parts (33% -34% -33%);
  • into two equal (50% -50%) parts;
  • into two unequal (70% -30%, 30% -70%) parts;
  • leave the layout indivisible (Full layout).




At the stage of creating forms, you can configure the visibility of fields and editing functions for different users.
For example, the next stage of 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 he has access to his own fields that are not visible to the employee: the field is Approved with Yes / No options.



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



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



4. Definition of business rules

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

Bizagi provides three steps for setting business rules:
  • Define Expressions - involves processing conditions
  • Activity Actions (Events) - involves event processing
  • Perfomance - involves the processing of users working at one stage or another of a business process.


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

If, according to the results of the audit, the manager refuses, then the process goes to the Notify the reason for the refusal stage.



If, based on the results of the audit, the Manager approved the request, the process proceeds to the Print Invoice stage.

Activity Actions
At the Activity Actions stage, we can prescribe predefined fields. Predefined fields can be filled in three cases (optional):
  • when you open the form;
  • when saving;
  • when exiting the form.

For example, at the stage of creating a request for payment, we can indicate that when opening the form we have two predefined fields:
  • Date - here we indicate that the request date is automatically filled with the current date = DateTime.Today
  • Author (employee) - here we prescribe that the one who initiated the document automatically becomes its author = Me.Case.Creator.Id




Perfomance
The next step is Perfomance. Here we prescribe who at what stage works with the business process, is responsible for its implementation.
  • At the stage of creating a transaction, the employee who created this transaction is working. User Id Equal Case Creator
  • At the stage of Request verification, the Head of the person who created the document works. User Id Equals CurrentAssigneeBoss




5. Description of notification rules
After we have registered how business rules work, we describe the notification rules.

An employee cannot constantly be in one system; he has current affairs and work in other programs. How will he receive information on 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 attach the notification to the system.

There are two types of alerts:
  • automatic (the system itself has its own email server) - for example, when moving from one stage to another;
  • manually created - for example, when the user himself wants to send a message for any clarification, but without changing the stage of the application.

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

In our business process, when a stage is changed (a request for payment is approved or not approved), a message is sent to the employee that the account has been approved or needs to be clarified.

6. Creating a printed 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 out, signs the document and gives it to the secretary for further transfer to the accounting department. The document is saved not only in the system, but also in printed form.

In the system, you can create so-called document templates. For a printable request form, you can use word, excel or plain text. We created a form, which should be printed by the one on whom the process ends, and put our signature. In this printed form you can see all the basic information on request:
  • Date of creation;
  • User;
  • Account number;
  • Invoice date;
  • Invoice amount;
  • Base;
  • Signature of the responsible person.




Upon receipt of this form, the accounting department can immediately identify the account that must be paid.

Business Process Execution


After we have developed a business process in the Bizagi system, it is necessary to create users, specify their structure, after which these users will be able to work in the system.

Consider how the execution of the business process we created is performed: The

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

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


2. The manager is notified that it is necessary to check the request.
3. The manager enters the request form, where he sees the request verification form with the available actions - select whether the request is approved or not.

If the manager selects Yes:
4. The Generate document button appears to print the request. The leader displays the printed form and signs it.
5. The employee who initiated the request receives a notification about the approval of the account

If the manager chose No:
4. The employee who initiated the request receives a notification about the refusal to pay the bill.
The business process is complete.

A Few Words About Bizagi


At Bizagi, you can always see analytics for the execution of business processes.

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

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

In conclusion, I would like to note that creating a business process is a long and laborious job, as we are writing a practically new application for which we are developing data structures and forms from scratch.

Also popular now: