Automation of business processes in CRM. Comparison of approaches
When introducing any CRM system, one of the first stages of work is the description of business processes. It is important to study the peculiarities of the company's work, to take into account all the factors that influence a particular process, to identify the key points of work and the “thin spots”. As a result, we get a competent and detailed description of business processes that are subject to automation.
In addition, it is very important to set the environment for the execution of these processes by employees of this company. This is called the regulation of business processes.
Thus, when working on the implementation of CRM, I personally adhere to the following sequence of actions, which I also recommend to all my colleagues, as I have proved in practice my convenience and viability:
')
In many cases, the choice of a CRM system is made in advance, taking into account the cost of a software product and the skills of employees of a particular company. In this case, the description of business processes can be made immediately, taking into account the features of the selected CRM system.
And now I want to talk about two different approaches to solving these issues, which to some extent implemented in all popular CRM.
The difference between these approaches is clear from their name. In the first case, the developers use algorithmization and a certain sequence of commands, which they later implement in the CRM environment as a set of commands. In the second, business processes are represented as a graphical flowchart, the commands in which are represented as objects and arrows. Let's look at a little more with each of these options for automation.
I am not going to consider the use of BPMS systems for solving business process automation problems, those who are interested can read here .
This method is used in such popular systems as ZOHO CRM or Saleforce CRM, and consists in implementing a business process using Step by Step technology, i.e. "step by step".
At the same time, business processes can be designed in any convenient form, in the same way as when creating an algorithm before writing a program. But all processes are realized in the form of a step-by-step sequence of actions and conditions (each branch is almost always a new process).
The description of the processes in this case is made in text form with the help of commands accepted in the environment of one or another CRM. That is why such an approach can be called programming.
Let's give an example from ZOHO CRM. There are two main types of objects:
Thus, business processes are defined by defining a sequence of actions that need to be performed with a particular object, as well as the conditions depending on which particular actions will be performed.
With this approach, there is no graphic notation, only a step-by-step transition from one action to another. And if you need to change something in the business process, you will need to make a specific list of values ​​and commands, and not graphic blocks and arrows.
About this approach, we can say that the description of the algorithm is implemented in a textual way. For example, if we take a certain Provel process in ZOHO CRM, then we will need to specify for it:
In some systems, such programming is rigidly tied to certain objects, most often, to a transaction. For example, this is how the possibility of describing a business process in Megaplan is implemented. Only through a transaction can you specify what is happening in a particular case, and all actions of users and participants in the business process are necessarily tied to a specific transaction. In other systems, for example, in ZOHO CRM, we can attach actions to both the transaction and any other module in the system.
This approach is implemented, for example, in Bitrix24 CRM and 1C CRM. Here all business processes need to be drawn in a certain internal format of these systems. So, Bitrix24 has its own concept of “Business Processes”, and inside this section there is a notation in which you need to draw business processes.
This notation was created by Bitrix24 programmers, and in order to implement business processes in this system, you will need to draw them in this notation. At the same time, it is important to understand that in Bitrix24, the notation can be described both as a sequence of actions when working with the system as a whole, and separately when dealing with a transaction, since CRM is only one of the modules of the Bitrix24 system.
Similarly, 1C CRM implements its own notation, which differs from the one created by the Bitrix24 programmers. Also, in other systems adhering to the graphical approach, either fully own developments or graphical notations from third-party developers adapted to the needs of the system are used. And each time for correct work in the system, the notation will need to be studied in advance.
Practice shows that, in spite of the abundance of standard elements, the study of graphic notation takes more time than acquaintance with the rules for describing business processes in text form (the first approach). Moreover, to create a sequence of actions in CRM systems that use text-based algorithms, most often there is a convenient constructor and a lot of hints, thanks to which developers can program the necessary processes practically without first studying the environment.
The main advantage of the first approach was described above: it is very convenient for developers, does not require in-depth study of notation, and allows for the algorithming of any business processes, which are usual for programmers-developers.
The obvious disadvantage of this option: the lack of visibility for users. At the same time, no one bothers the developer to create a graphical diagram of business processes for the customer (block diagram in the form of blocks and arrows) in any convenient environment for coordination, then execute programming and familiarize users with the result. In the same way as every developer does it when creating and refining applications.
Moreover, a convenient and streamlined business process requires some changes in rare cases, usually associated with the introduction of changes in the scheme of the company itself. Therefore, the lack of clarity and the complexity of making edits for a non-specialist are not in fact a critical issue. Most likely, a customer with a ready-made system will work for years, and he will need changes when the company’s work scheme itself changes, and here it’s usually impossible to do simple business process changes, and in any case, the specialist’s participation in the development and implementation of an updated one is required. system.
In the second case, the notations invented by the creators of 1C and Bitrix24 CRM are used. On the one hand, this approach is very convenient for users, as it is clear and understandable. On the other hand, to use it, you will have to spend additional time studying the notation from 1C or Bitrix24, and there is not as much information as we would like to work with these systems.
Of course, each system provides documentation and some help sections, but there is no definite ideology in them. All information provided by the developer is the documentation from the vendor. Those. To study the notation, users are not offered a solution from business analysts and experienced users of the system, but a brief guide from the point of view of the system developers. That is why for such a method of work it is very useful to have developed abilities to visualize processes, as well as the ability to quickly adapt to unfamiliar notations.
Another disadvantage of the graphical approach is significant limitations that impose the possibility of notation on the work in the system. When programming flexibility and the list of possibilities is much higher.
As a result, I personally prefer to use a more flexible system, i.e. I program business processes, and I provide visibility for the customer by creating graphics (flowcharts) at the business process approval stage, which I usually do in IDEF 3 or BPMN ... But in fact, you can even use a regular sheet of paper and a pencil . The main thing here is mutual understanding with the customer.
On the other hand, if business processes in a company are relatively simple, and a user who is not a programmer intends to perform the work of automating processes, the graphical approach is more convenient. Clearly “draw” the process diagram and determine the hierarchy in the notation can even a user familiar with business intelligence and IT simply because the graphical version of the representation of business processes is much clearer to users. These tools are designed for them. It is to draw that the processes are correctly executed anyway, you have to involve the programmer. It is believed that the user learn the graphical notation easier than programming processes. Here everyone decides for himself what he likes more: flexibility and simplicity of programming or visibility for users and the ability to make changes in business processes without the participation of developers.
In addition, it is very important to set the environment for the execution of these processes by employees of this company. This is called the regulation of business processes.
Thus, when working on the implementation of CRM, I personally adhere to the following sequence of actions, which I also recommend to all my colleagues, as I have proved in practice my convenience and viability:
')
- Description of business processes. At this stage, the work is done on paper or in any convenient environment. Most importantly, get some kind of scheme or algorithm that will be clear to both the developer and the customer.
- Matching. The resulting description of business processes is agreed with the management of the company. At this stage, an experienced business consultant or developer can also offer optimization of certain processes and clarify all issues.
- The choice of environment for implementation. A detailed description of business processes can be considered a clear statement of the problem. And now, when the algorithm of future work is clear, the developer can independently or together with the customer choose the environment in which further work will be carried out, i.e. directly CRM system.
In many cases, the choice of a CRM system is made in advance, taking into account the cost of a software product and the skills of employees of a particular company. In this case, the description of business processes can be made immediately, taking into account the features of the selected CRM system.
And now I want to talk about two different approaches to solving these issues, which to some extent implemented in all popular CRM.
- Programming business processes.
- "Drawing" business processes.
The difference between these approaches is clear from their name. In the first case, the developers use algorithmization and a certain sequence of commands, which they later implement in the CRM environment as a set of commands. In the second, business processes are represented as a graphical flowchart, the commands in which are represented as objects and arrows. Let's look at a little more with each of these options for automation.
I am not going to consider the use of BPMS systems for solving business process automation problems, those who are interested can read here .
Business process programming
This method is used in such popular systems as ZOHO CRM or Saleforce CRM, and consists in implementing a business process using Step by Step technology, i.e. "step by step".
At the same time, business processes can be designed in any convenient form, in the same way as when creating an algorithm before writing a program. But all processes are realized in the form of a step-by-step sequence of actions and conditions (each branch is almost always a new process).
The description of the processes in this case is made in text form with the help of commands accepted in the environment of one or another CRM. That is why such an approach can be called programming.
Let's give an example from ZOHO CRM. There are two main types of objects:
- Workflow allows you to set an action depending on different fields.
- Approval process sets certain coordination processes. We can add several such processes, and they will work as follows. For each process we can indicate when it works, who approves it. And, accordingly, the system will monitor the operation of processes.
Example Approval process
Workflow Example
Thus, business processes are defined by defining a sequence of actions that need to be performed with a particular object, as well as the conditions depending on which particular actions will be performed.
With this approach, there is no graphic notation, only a step-by-step transition from one action to another. And if you need to change something in the business process, you will need to make a specific list of values ​​and commands, and not graphic blocks and arrows.
About this approach, we can say that the description of the algorithm is implemented in a textual way. For example, if we take a certain Provel process in ZOHO CRM, then we will need to specify for it:
- Criterion when it works.
- Who should approve it.
- What action needs to be done after approval, for example, create a task or send an alert within the system, send sms, etc.
- What should happen if the process has not been approved, for example, do nothing, return the task to the contractor for revision with comments, etc.
In some systems, such programming is rigidly tied to certain objects, most often, to a transaction. For example, this is how the possibility of describing a business process in Megaplan is implemented. Only through a transaction can you specify what is happening in a particular case, and all actions of users and participants in the business process are necessarily tied to a specific transaction. In other systems, for example, in ZOHO CRM, we can attach actions to both the transaction and any other module in the system.Drawing business processes
This approach is implemented, for example, in Bitrix24 CRM and 1C CRM. Here all business processes need to be drawn in a certain internal format of these systems. So, Bitrix24 has its own concept of “Business Processes”, and inside this section there is a notation in which you need to draw business processes.
An example of a business process in Bitrix CRM
This notation was created by Bitrix24 programmers, and in order to implement business processes in this system, you will need to draw them in this notation. At the same time, it is important to understand that in Bitrix24, the notation can be described both as a sequence of actions when working with the system as a whole, and separately when dealing with a transaction, since CRM is only one of the modules of the Bitrix24 system.
Similarly, 1C CRM implements its own notation, which differs from the one created by the Bitrix24 programmers. Also, in other systems adhering to the graphical approach, either fully own developments or graphical notations from third-party developers adapted to the needs of the system are used. And each time for correct work in the system, the notation will need to be studied in advance.
Sample business process in 1C CRM
Practice shows that, in spite of the abundance of standard elements, the study of graphic notation takes more time than acquaintance with the rules for describing business processes in text form (the first approach). Moreover, to create a sequence of actions in CRM systems that use text-based algorithms, most often there is a convenient constructor and a lot of hints, thanks to which developers can program the necessary processes practically without first studying the environment.
Pros and cons of approaches
The main advantage of the first approach was described above: it is very convenient for developers, does not require in-depth study of notation, and allows for the algorithming of any business processes, which are usual for programmers-developers.
The obvious disadvantage of this option: the lack of visibility for users. At the same time, no one bothers the developer to create a graphical diagram of business processes for the customer (block diagram in the form of blocks and arrows) in any convenient environment for coordination, then execute programming and familiarize users with the result. In the same way as every developer does it when creating and refining applications.
Moreover, a convenient and streamlined business process requires some changes in rare cases, usually associated with the introduction of changes in the scheme of the company itself. Therefore, the lack of clarity and the complexity of making edits for a non-specialist are not in fact a critical issue. Most likely, a customer with a ready-made system will work for years, and he will need changes when the company’s work scheme itself changes, and here it’s usually impossible to do simple business process changes, and in any case, the specialist’s participation in the development and implementation of an updated one is required. system.
In the second case, the notations invented by the creators of 1C and Bitrix24 CRM are used. On the one hand, this approach is very convenient for users, as it is clear and understandable. On the other hand, to use it, you will have to spend additional time studying the notation from 1C or Bitrix24, and there is not as much information as we would like to work with these systems.
Of course, each system provides documentation and some help sections, but there is no definite ideology in them. All information provided by the developer is the documentation from the vendor. Those. To study the notation, users are not offered a solution from business analysts and experienced users of the system, but a brief guide from the point of view of the system developers. That is why for such a method of work it is very useful to have developed abilities to visualize processes, as well as the ability to quickly adapt to unfamiliar notations.
Another disadvantage of the graphical approach is significant limitations that impose the possibility of notation on the work in the system. When programming flexibility and the list of possibilities is much higher.
As a result, I personally prefer to use a more flexible system, i.e. I program business processes, and I provide visibility for the customer by creating graphics (flowcharts) at the business process approval stage, which I usually do in IDEF 3 or BPMN ... But in fact, you can even use a regular sheet of paper and a pencil . The main thing here is mutual understanding with the customer.
On the other hand, if business processes in a company are relatively simple, and a user who is not a programmer intends to perform the work of automating processes, the graphical approach is more convenient. Clearly “draw” the process diagram and determine the hierarchy in the notation can even a user familiar with business intelligence and IT simply because the graphical version of the representation of business processes is much clearer to users. These tools are designed for them. It is to draw that the processes are correctly executed anyway, you have to involve the programmer. It is believed that the user learn the graphical notation easier than programming processes. Here everyone decides for himself what he likes more: flexibility and simplicity of programming or visibility for users and the ability to make changes in business processes without the participation of developers.
Source: https://habr.com/ru/post/278125/
All Articles