Any end-to-end business process of a company in a normal IT system “lives” better than in regulations with diagrams and clear text. For many, this thesis is obvious, but not for everyone. Let’s consider the example of the process of selling new buildings in a development company: 1) the “life” of the sales process in the sales regulations, and 2) the “life” of the sales process in the CRM system (MS Dynamics CRM). From what point of view does the process “live” better, if by free slang we mean the execution of the process, the effectiveness of its control, and process management.
What is more effective for sales management — a good sales process regulation or a good CRM system? I will share examples from my practice. Until 2015, in one_it_doesn’t_matter_what_company, there was a “home-made” CRM system or, as it was called, “CRM”. But, its presence did not fully solve the problems of interaction between departments within the Sales Department — problems remained between sales managers and real estate sales contract executors/registrars, between sales managers and mortgage managers. There were also no clear and intelligible regulations, there were disparate fragmentary instructions on individual issues on the topic of sales. Why is it so — there was a system, but the problems remained? Because, strictly speaking, there was no System — there was a “home-made” system, there was programming at the request of the sales manager, and a certain “individual special order” on the topic of sales was built, not from the general vision of how everything should be, but from particulars, from individual operational conveniences of the current understanding of sales. Unfortunately, not all sales representatives are able to systematically and clearly express their thoughts…) It is in these situations that system analysts and business analysts come to the aid of the company’s manager…
In 2014, we (business analysts of the organizational development department) developed the regulations for the sales of new buildings — we described the process of selling new buildings step by step, and drew a graphical diagram of the process on 2 levels. The article “Development of the company’s management system through NMD (normative and methodological documentation)” was devoted to the necessary and sufficient, in the author’s opinion, requirements to describe the process, using the example of the process of selling new buildings. It is quite sufficient to describe the process in the company graphically, through a tabular presentation, through the document flow of the process, and roles in the process. The work was useful, but the scope of benefit was limited to exactly the period of time while the regulations were being developed with the participation of department heads and employees of the sales department, marketing and advertising department and other divisions. We even tested employees for knowledge of the sales regulations, and then everything quietly “died”, the manager was replaced, and the sales regulations were forgotten…
I will note another interesting feature – when drawing the sales process in the regulations, one experienced and strong analyst was confident that, by and large, the sales process is the same for different real estate sales schemes (assignment, shared participation/DDU, DCT, etc.), – because the composition of the process steps in different transaction schemes is the same, and excessive detailing of the differences in transactions only complicates the perception of the graphical diagram of the sales process. Later, when implementing a new CRM, we parted with this illusion. And perhaps the simplifications of the process that are allowed when describing the process in the regulations create a barrier that prevents IT specialists from perceiving the process regulations as the initial requirements for setting up a CRM system.
After 2 months of closely monitoring the conflict in the relationship between the Sales Department and the IT Department, the Organizational and Strategic Development Department joined the CRM system implementation project. We also had to give up the illusion that a good, detailed sales regulation would be a clear description of the initial requirements from the Sales Department for IT specialists on how to set up the sales process in the new CRM system.
The new CRM system chosen was the solution, as already mentioned, MS Dynamics CRM, which dominates the development market in Moscow and the Moscow region (in 2nd place after MS Excel 
).
I would like to note that two interrelated processes were described – the process of bringing an object to market, and the process of selling new buildings. When business analysts joined the CRM implementation project, one of the tasks was to understand the internal architecture of the new system and the internal methodology already “sewn” into the system. And this understanding determined the content of the CRM implementation plan on the one hand, and opened the way to rapprochement of the sales methodology from the regulations with the sales methodology in CRM.
Fig. 1. General sales logic in CRM: reflects which divisions of the Sales Department work with which CRM objects and how information is transferred
Figure 1 presents a description of the general sales logic with the identification of entities (in the language of the system, the main objects) through which key information of the sales process circulates in the system.
Understanding the architecture of the system and superimposing its elements on the already described processes of bringing objects to implementation (blue flows in Figure 1), sales processes (red flows in Figure 1), allowed us to formulate the requirements for setting up the system in the language of the system itself. Since the management language of sales regulations and the technical language of the CRM system are different languages, this also had to be sorted out, to “make friends” between them.
An example of a graphical representation of the process of receiving and processing requests looks like this – see Fig. 2.
The graphical representation of the same subprocess in the “system language” of MS Dynamics CRM looks like this – see Fig. 3 for a conditional example.
I will give a general description of the process of “receiving and processing requests” (Fig. 2) to understand the context: a call center employee receives and qualifies a call, fills out a call card, and based on the results of the call qualification, transfers the call to a sales manager if the topic of the call is “sale of new buildings” or to another employee if the topic of the call is different. The sales manager finds out the needs, fills out a client (potential client/lead) card, organizes a showing of the property, organizes a meeting, holds meetings, independently conducts an initial assessment of the client’s creditworthiness, and then, after qualifying the general application, concludes a Reservation Agreement. For our example, this description is enough.
Fig. 2. Level 2 process – Receiving and processing requests from clients. Transition from a call to a call center to a sales manager request.
Fig. 3. Scenarios for transition from the Call card to the Request card (General client request/lead) in CRM
Key events of the sales process from the regulations (Fig. 2) are transformed into planned tasks of the employee when working with the application (Fig. 3), which the employee can no longer ignore, since the fields are mandatory to fill in, the necessary notifications about filling/not filling in the fields of the planned task card are sent to the list of those who should, and the mechanism works. Even taking into account attempts to deceive the system, which is also possible, but if desired, it is easily and quickly detected. The complexity of all process scenarios is “hidden” in the system settings, for the user we see only their convenient interface at their workplace in the process.
After working through the process in the system, you can begin the task of generating reports to control the quality of the process, since the necessary analytical features are already embedded in the process.
Results:
The “sales manager – programmer” duo is a “narrow get-together”, a dangerous duo. Salespeople are not always able to clearly and distinctly formulate the ideology of setting up a system. IT specialists do not understand or understand the language of business in their own way. A competent methodologist from the analytical department for strategic or organizational business development can reconcile everyone. The implementation of any normal IT system is always a project of organizational business development for the strategic goals of the business as a whole, with the solution of a large number of methodological issues.
We have considered an example of a key business process from two positions: 1) from the point of view of developing process regulations, 2) from the point of view of process automation in the IT system. The IT system does not cancel the regulations. Otherwise, the refinement and development of the system is separated from the regulations/methodology of the process, after some time no one will remember what changes were made and why? The methodological settings of the system must be controlled through the regulations/methodology of the process. And the regulations themselves penetrate the system in the format of notes to fields, notifications if an employee has performed an erroneous action. Thus, the regulations do not live a separate life in a capsule, do not become obsolete, are updated faster, new employees come – through the system they will begin to understand faster what rules of the sales process must be followed.
It is dangerous to trust control of system settings only to the department that is its main user – they will start to bypass the system or manipulate the data. Methodological control of system settings should be taken out of the operational department that uses the system.
A company’s end-to-end business process “lives” better in a normal IT system than in regulations with diagrams and clear text, because the IT system already has a mechanism for monitoring its execution and the necessary analytics “bolted in”, while documentary business processes must additionally be bolted on with organizational procedures for their monitoring and development.
P.S. Clarifications on the text:
*”Normal IT system” is a free name for a fully functional, tested, mass-produced IT solution that accumulates many years of practice of many companies, regularly updated by the solution vendor.
