Bizagi: Model. Build. Run
Bizagi is the BPM system developed by the company of the same name, and directed to modeling, execution, automation and the analysis of business processes. The Bizagi system turns on 3 modules for full setup of processes:
- Modeler — the full-function environment of modeling of processes in the notation of BPMN;
- Studio — a development environment of business processes;
- Engine — the environment of execution of processes which is available to users in any browser from any device.
Let's consider each of these modules in more detail.
Modeler is a designer of business process where the sequence of actions and events is modelled. It is important to understand that the business process created in Modeler is only the picture, graphic display of the modelled process, but yet not the automated algorithm of actions.
Directly responsible for business process, roles and the business rule are assigned at the following stage of programming and do not depend on what design you simulated at this stage. The design of business process is necessary just to approve the scheme of work with users.
You can use one of three methods of modeling of business process:
- New Process — to create the new business process;
- Import Process — to import business process;
- Process Xchange — to select ready model from the base of business processes offered by the Bizagi company. Having selected a template, you can finish it under realities of the business. All provided models are written in English.
You can edit, save, export the business process created in Modeler in different formats (pdf, html).
Modeling of business process is made in the BPMN 2.0 format. This format differs from known for many BPMN 2.0 a little, I faced it in practice. And in the Bizagi format you will not find some opportunities which are meant in BPMN 2.0 in some other programs created for work only with modeling. For example, there is no so-called "external entity". But in Bizagi there are own developments which are not in other systems, for example, of Mailstone — the intermediate stage.
The cards of business processes created in Modeler can both be "shared" on the Bizagi portal, and to use kollaborativ, that is several employees can perform collaboration that is very convenient.
Modeler has Russian-speaking version of the interface, unlike two other modules.
Once again I will remind that Modeler is intended only for business process modeling. That is if only the design of business process is necessary for you, to you there will be enough this module. If to you it is necessary not only to model, but also to develop and perform business processes, you need the Studio module in which there is the modeler of business processes.
The simulated card of business process has to start working. The user has to log in and interact with different forms. Studio allows to develop the interface and forms with which the person will work. Below we will in more detail consider all aspects of development of business process in Bizagi Studio.
I want to note that Modeler and Studio are free. The basic packet of Studio included about 20 test users.
Engine is a Wednesday of execution which allows users to log into the system and to work in it, executing certain business processes.
The licenses Engine are paid. Only the test mode is free.
Two types of the license are provided in Engine:
- permanent license;
- the license for a year.
At the same time the discount of 50% is provided to the companies in which about 50 users work - it is the so-called Starter kit directed to support of small and medium business. If more than 50 users work at the enterprise, it is necessary to pay the total cost of licenses.
Engine assumes step-by-step execution of the developed business process taking into account all conditions registered in Studio.
Without Engine module you will not be able fully to work in system and to perform the registered business processes.
As Bizagi works
What do we do in Bizagi if we need to automate any business process? Let's consider algorithm of actions on the example of approval of the request for a funds expenditure. In article about BPM systems we saw how this business process was implemented on the real project by means of accounting system, now we will look how it is correct to organize it in the BPM system.
Modeling of business process happens by drag and drop of the graphic elements offered in Bizagi, in a working zone.
Above I wrote that the Studio interface, is provided in English, but in the card of business process we can use Russian.
We model the scheme of business process Payment Request: we define the beginning of process, an event, the notification, business rule and the end of business process.
The task consists in control of payment of accounts. The sequence of actions of this business process looks so:
1. The employee to whom the invoice for payment arrives has to create request for payment.
2. The head has to check request and select one of action options:
- To refuse;
- To approve.
3. At the first option the Employee receives the notice of failure of the head. On it business process comes to an end.
3. In the second case the Head has to Print, sign request and send it to accounts department, on it business process comes to an end.
The graphic card of business process looks so:
2. Development of a data structure
After business process is simulated, we start development of a data structure. At this stage we register in what forms what fields these or those data are stored we and specify their communications.
In our example we have to develop three entities (Entity):
- Request for payment of account;
- The partner (the supplier who needs to pay the bill);
- Cause of failure.
For each of these entities it is necessary to register attributes (fields) which will be available to filling. Attributes share on:
- Preset (them there is a lot of) — attributes which are offered by system;
- User — those which the user creates manually.
On a screenshot it is visible what attributes are registered for each entity.
It is also necessary to specify communications between these entities. We register that entities of the Cause of failure and Partners enter entity Request for payment of account.
3. Creation of forms (user interface)
After we developed a data structure, we need to decide how the user logs into the system as interacts with it. And here we need to create the user interface.
When we simulated business process, we enter it and we see that each of these small squares on the scheme designating stages is a form which needs to be developed.
Form is what the user will work afterwards with.
I want to pay your attention that only those forms on which the user works are developed. If some of stages assumes automatic action (for example, the notification of the Employee about failure in payment), the form does not need to be developed for it.
In our example it is necessary to develop 3 forms:
- Query designs on payment;
- Check of request for payment;
- Formations of a printing form.
These forms use the same data. A basis in each of these forms one — request for payment of account. But each following form has more expanded functionality, than previous. For example, in the form of Check of request there is all information from a query design form + the status of request (It is approved or not). And the following form has in comparison with previous also a possibility of printing of request. If necessary unnecessary fields from the previous forms can be hidden.
Here it is important to understand that it is after all not one, but three different forms. And each of them is created again or copied from the previous form then necessary changes are made to it.
Now we will consider process of creation of a form (for example, Query designs on payment).
The form is created by means of the choice and drag and drop in an active window of necessary fields. For the choice are offered weeding (attributes) which we assigned to specific forms at the previous stage.
The query design form as a result will look so:
Here we see fields:
- Payment due date;
- Account sum;
- Account number;
- The attached file (it is possible to attach the invoice for payment).
Also for more convenient use of forms it is possible to use Layot (options of an arrangement of parts of a form).
The model of a form can be separated:
- on three equal parts (33%-34%-33%);
- on two equal (50%-50%) parts;
- on two unequal (70%-30%, 30%-70%) parts;
- to leave the model to indivisible (Full layout).
At a stage of creation of forms it is possible to configure visibility of fields and editing function for different users.
For example, the following stage of Check of request has the form in which the fields created by the employee at the previous stage are visible to the head, but the head cannot edit this field. But own fields which are not visible to the employee are available to it: the field Is approved with Yes/No. options.
The Cause of failure field becomes visible to the head, only if It is in the field approved he selected No. option. That is visibility of fields can be configured not only in the Visible Not format it is visible, but also depending on any conditions. This condition looks so
PaymentRequestApproved is equal to false
If the Head set Yes option, there is available a function to print request for payment. Already any functions are unavailable to it, except Generate template.
4. Determination of business rules
Further it is necessary to develop business rules that the system automatically did some things on the basis of any data.
Three stages of installation of business rules are provided in Bizagi:
- Define Expressions — assumes processing of conditions
- Activity Actions (Events) — assumes event handling
- Perfomance — assumes processing of the users working at this or that stage of business process.
At the stage Define Expressions there is determination of options of system behavior under these or those conditions. In our case it is result of check of request, two options (two arrows) which conduct from Result of check. When clicking the arrow conducting to the following stage the form in which conditions of transition to this or that stage are filled opens.
If by results of check the head refuses, then process passes into a stage to Notify on a cause of failure.
If by results of check the Head approved request, process passes to the stage Print the Account.
At the stage Activity Actions we can register the predetermined fields. The predetermined fields can be filled in three cases (at choice):
- when opening a form;
- when saving;
- at an output from a form.
For example, at the Query design stage on payment, we can specify that when opening a form we have two predetermined weeding:
- Date — here we specify that date of request is autocompleted current date <PaymentRequest.RequestDate>=DateTime.Today
- The author (employee) — here we register that the one who initiated the document automatically becomes his author <PaymentRequest.Employee>=Me.Case.Creator.Id
The following step is Perfomance. Here we register who at what stage works with business process, is responsible for its execution.
- The employee who created this transaction works at a stage of Creation of the transaction. User Id Equal Case Creator
- The Head of the one who created the document works at a stage of Check of request. User Id Equals CurrentAssigneeBoss
5. Description of rules of the notification
After we registered as business rules work, we describe rules of the notification.
The employee cannot reside in one system, he has current affairs and work in other programs. How it will obtain information on changes on business process which demand its participation? It is configured by means of Notification. In BPMN 2.0 there is such concept as notification, and here we can tie the notification to system.
Notifications happen two types:
- automatic (in the system there is the email-server) — for example, upon transition from one stage to another;
- created manually — for example when the user himself wants to send the message for any refining, but without change of a stage of the request.
It is possible to use both types of notifications at the same time.
In our business process when changing a stage (It is approved or the request for payment is not approved), to the Employee the message that the account is approved is sent or demands refining.
6. Creation of a printing form
In our example the employee, except the electronic document, wants to receive also a printing form. That is, if the head approved request for payment, then he prints, signs the document and gives to the secretary for further transfer to accounts department. The document remains not only in system, but also in printed form.
In system it is possible to create, so-called, document templates. For a printing form of request it is possible to use word, excel or a plain text. We created a form which that on whom process comes to an end has to print and to append the signature. In this printed form all main information on request is visible:
- Date of creation;
- Account number;
- Date of the account;
- Account sum;
- Signature of the responsible person.
At receipt of such form the accounts department can identify at once the account which needs to be paid.
Business process execution
After we developed business process in the Bizagi system, it is necessary to create users, to specify their structure then these users will be able to work in system.
Let's consider how there is an execution of the business process created by us:
The user selects business process that are offered in system. In this case it is business process of Request Payment. The query design form opens.
1. The user fills necessary fields (a field Date and the Author are autocompleted). The user attaches the invoice for payment.
2. The head receives the notification that it is necessary to Check request.
3. The head enters a request form where sees a form of check of request with available actions — to select, is approved or the request is not approved.
If the head selected Yes:
4. There is a Generate document button for printout of request. The head displays a printing form and signs it.
5. The employee initiating request receives the notification on approval of the account
If the head selected No:
4. The employee initiating request receives the notice of failure in payment of account.
Business process is performed.
Some more words about Bizagi
In Bizagi you will be able always to look at analytics on execution of business processes.
Integration is provided in system: it is possible to be connected "outside" to Bizagi, or from Bizagi to be connected to other programs by means of API. She uses web services and SOAP.
It is also necessary to remind that the system has localization — options in different languages. Is in Bizagi Modeler and Russian translation. At once I will tell that this transfer, unfortunately, not always correct. Besides, all documentation of Bizagi is submitted only in English. Therefore I prefer to work with system in English.
In conclusion there is a wish to note that business process creation — a long and laborious work as we write almost new application for which we develop from scratch data structures and forms.
This article is a translation of the original post at habrahabr.ru/post/273017/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: email@example.com.
We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.