Business rule repositories and corresponding code blocks that are embedded in production

In brief, I remind you: BRMS, or Business Rule Management System, is “heavy” systems for large and very large companies that contain all those things that change frequently in IT. For example, in a bank in BRMS, most often the rules for assessing a loan and the parameters of deposits, in the cellular operator — tariffs and nuances of calculating all write-offs; in an insurance company, insurance factors, correction factors, parameters of new products.

The difference between “hands-on” and “via BRMS” is approximately the same: the guys from one insurance company, where we implemented BRMS, turned out to be one of the few last year who showed the opportunity to work very flexibly and quickly. Usually, the introduction of the coefficient with all checks takes an average of 2 weeks. Here it is done a maximum of 2 days, at least - in a matter of hours. They have statistics, to which you can quickly and quickly recheck different indicators hundreds and thousands of times. In insurance, this means that you can adjust in a very detailed manner to the current situation (region, banks) and receive much more profit.
')
We use BRMS to estimate the cost of an IT project - it is calculated on the basis of rules like “networkers or programmers are working” and dozens of variables, like the cost per hour of a specialist.

What is there in BRMS that can not be made a configuration file?

So, on the one hand - kulopanie in the production code, on the other - BRMS. Somewhere between them is the good old method of medium and small business - a configuration file, something like XML with variables.

In general, while the business is small, there is no reason to apply BRMS. Moreover, the mere purchase of a license or even the cost of introducing and honing an open-end product for themselves will hit the annual budget sharply. Even in spite of the fact that the system does not require connectors in each section, everyone has been working for a long time through a common ESB bus that calls BRMS.

And the main need for BRMS is the growing complexity of business logic. At a certain point, not everything will turn out to be driven into a simple file. Then you will need to enter roles for different users to edit. Then - write separate functions in the code for individual pieces of the rules. Make a means of finding the conflict of the rules and the "ripper" of these conflicts. Then you will need a GUI from the drawing tools of the threads, so that you can see what is going on in the process, and so that you can see all the branches. As a result, all this can be piled up with bicycles, but still get some, and BRMS.

For example, here is the simplest rule:

This is illustrated visually with a flowchart. This is convenient for all employees of the company who are responsible for money (and not IT) to understand and read. Further, when making changes, you can add a couple of arrows and blocks, and it will not be much more difficult.

Example how it works

In the insurance company there are such comrades - underwriters. They monitor the market and profitability of the company, looking for opportunities for development. Their main question is which transactions with which dealers can be concluded (simplifying what work to which counterparty to give). As soon as they find something - they form a business idea, they estimate profitability, they are protected by the management.

In the old process, the continuation of this: protected - transfer the business idea to the IT department for implementation into the system. IT specialists are included in the planned release in the next quarter, and they are starting to develop it - they distract the underwriters with questions: “What did you put here, but how exactly did you want to?” That is, they clarify the terms of reference. Develop. Are testing. At the technical testing stage, everything is standard, but then the underwriters themselves check the module logic from a business point of view. In the best case, it takes from two months to a quarter, and a difficult one - two quarters. The situation during this time is changing several times: the dealer will be deprived of the license, the prices will be changed, the train will leave, the business will turn out to be a little brake.

In the new process, all tasks are encapsulated, in essence. TK underwriters draw themselves in the form of such a flowchart as above (only more complicated and confusing). It already removes a sea of headaches. Then all this is covered by the autotest, and in a day (or two, if you are on the weekend) in technical interruptions at night - the logic is added to the industrial system.

How is BRMS built in?

What the underwriters have drawn on the flowchart above is immediately saved as a code. The code roughly corresponding to the flowchart is:

There are no rules for translating text like “Make A equal to a1 + a2”, conditions “Value for Object1 is X - Yes / No” into real code, as well as the generated code itself with Java logic. These are the deeper layers of BRMS, and this requires separate settings.

The limitation is that the underwriter uses a ready-made model of parameters. Within its framework, he manages and can do anything, there is coverage with ready-made code. Production, accordingly, refers to the rules repository as an external code library - all these call points must be registered during the integration and all must be covered with code.

When a task goes beyond the standard data model, the work of the IT department is again needed. As a rule, this happens once every couple of years, because at the time of implementation the model is set as fully as possible, the benefit is actually not that many parameters change - the relationship between them is more complicated. For example, we had 350 business fields in this insurance project at the start, in 6 years another 10 were added.

Our project costing system

About 5 years ago, when we made commercial offers, we counted the costs at the average hourly rate of the company, we also considered overhead costs not as detailed as we would like, added the possible profit and received external value for the customer. This process was not flexible, we could not afford to quickly calculate the various options, take into account factors affecting the cost of the project.

Accordingly, we needed a tool that allows us to quickly estimate the cost of a complex project based on its specificity. For example, depending on the type of activity (development or technical support services, outsourcing, construction and installation works, equipment supply or licenses), what specialties and qualifications people are involved in, etc. We have implemented BRMS to solve this problem.

In addition, on the basis of BRMS there is an engine for scrolling the “what if” scenarios, which is used to assess the company's economy as a whole with various calculation options. This makes it possible to make decisions about the allocation of costs between different types of activities to improve their efficiency, stimulate promising areas and achieve business goals (to be the number one IT service provider in the country).

Plus, our financiers can compare the data of the fact and the plan recalculated in the BRMS, to adjust the calculation factors and the "rules of the game" in the company.

How it works?

a. Getting input from the revenue and cost accounting system (ERP)
b. Getting planning data from a planning system
c. Distribution of revenue and costs for analysts (stages, types of services, directions, etc.) using special algorithms based on actual data from ERP and plans
d. (BRMS). Calculation of coefficients based on data from the ERP and previously defined analyst
e. (BRMS). The final calculation of profit and profitability of the project

If you need more details, here is a description of the project.

What else can BRMS be used for?

In general - for making decisions where quick response is needed. For example, in a case of another insurance company, the so-called investment insurance is used, actually a model of the game on the exchange. BRMS acts as a complex exchange robot that makes as many decisions as people cannot afford, but on the basis of predetermined heuristics.

Tata Global Beverages (a very large importer of tea and coffee) uses BRMS as a site builder. They have a bunch of web resources for 19 different brands, and they need to be supported on many language versions. Major updates - lists of stores, prices, cards of new varieties and products. All this is made once at the central office, then flies to translate and scattered around the sites. That is, here BRMS is somewhat similar to products that roll out a release on different servers.

MeWatt uses BRMS to reduce energy costs and CO ₂ emissions.

Your Move - a real estate company - managed to pay back the implementation of BRMS for 7 months (usually longer, I feel, there was a wide scope of breakdown that was decided by control) - their system scattered tasks for the staff as real estate objects and customers appeared. In fact, it turned out a bunch of CRM and BRMS. The same principles of the exchange robot were used: optimal rates were determined, operational tasks were hung and hundreds of variants of experiments were carried out.

Parker Hannifin, a producer of monitoring iron for the oil industry and similar fields, used BRMS as a live code repository for .NET to quickly build new dashboards to customers.

There are hundreds of stories from one of the vendors.

In Russia, with the help of BRMS, the cost of transportation is also considered (which route, through which contractor, which way to send and compose with something or not, whether to wait for seasonal changes or not, etc.). A lot of specialized banking products.

Summary

Typically, the process of implementing BRMS requires a change in the mindset of managers, and this is quite difficult. Therefore, the system multiplies by “budding”, that is, it is first placed somewhere in the same enterprise of the sphere, and then the others begin to look closely and learn from the experience. There were a couple of times that we were directly contacted with an already formed need, and the customer thought that he needed a feature for ERP or CRM. We showed both options, and once a cheap and ultra-fast crutch was chosen, and in the second - a system that in the future will add value to the company.