Yes! A decision engine brings many benefits, but the central reason your company NEEDS one is simple: transactional business rules belong in the business areas, not in the technology areas. Business areas are responsible for improving these rules and for the good or bad results they generate. I'll tell a story to illustrate this point, and at the end, I'll share a bit of my motivation for building a business around this idea.
Some Context
A few years ago, I took over the operation of a large service provider that handled over 2 million effective service dispatches per year, sent to about 5,000 municipalities in this vast country (we have around 5,600 in Brazil) and made more than 15 million dispatch attempts to approximately 25,000 partner service companies.
A couple of years before, I led an extensive consulting project for this same company, resulting in efficiency and quality recommendations that were diligently implemented and delivered results beyond expectations.
However, some of the most challenging recommendations, especially those proposing changes to the company's call system, were not implemented. This happened despite strong support from senior leadership, who invested, made tough decisions, and empowered teams to put these recommendations into practice. Yet, there was considerable resistance to changing the central transactional nervous system of the company, the dreaded legacy. The arguments were numerous:
Specifications between consulting, business, and technology teams riddled with misunderstandings and conceptual flaws.
Lack of documentation or record of the current "algorithm" in use.
Knowledge scattered across different parts of the system among various developers, many of whom were no longer with the company.
Fear of changing the dispatch system, the company's core system, risking penalties for relevant B2B contracts.
Operational areas' habit of "maneuvering" the system using the same limited set of variables and data.
Technology areas' obsession with reliability, preventing the implementation of certain more complex functionalities.
The Problem
The marginal most impacting levers for operational efficiency were at the company's core system. There was an existential problem: the operations department, responsible for improving quality and reducing costs, lacked all the internal levers to do so and was particularly vulnerable when it came to system-dependent matters.
I understand the dilemma that technology departments face. On one hand, there is the risk of complex deployments, subject to rollbacks that consume valuable rest hours, peace of mind, and, in some cases, can lead to unpleasant conflicts or even corporate upheaval. On the other hand, they may be accused of slowness, conservatism, or being bottlenecks to improving results. Most leaders choose to stay in the middle of this spectrum, avoiding the risks that loom over the extremes.
The Solution
But, Rafa, is there a solution?
Yes! The solution lies in putting the right domains in the hands of the right experts. Business rules are the responsibility of the business areas. Only with this concept-solution did I begin to realize how pervasive the problem is in the corporate world. I dare say that all companies with significant transactional volume have faced this problem at some point in their histories, and the vast majority are dealing with it today.
But how can we put the domain of business rules in the hands of business experts? Through a system called a decision engine, which allows:
Creating business rules without using code or programming (although it is possible if the user desires).
Executing rules at the transactional level through a high-performance, reliable, and available API.
Accessing organizational data and external data (e.g., credit scores, real-time geolocation and traffic, open banking data, etc.).
Documenting rules in a user-friendly and intuitive format, typically using workflows along with expressions, external data, and decision tables.
Segmenting decisions according to objective criteria, allowing different rules for customer segments or different transactions.
Enhancing governance over business rules with clear visualization and auditing of what was executed, rule versioning, user permission systems, and transparent verification of management actions.
Conducting experiments on sample subgroups before applying hypotheses to the entire set, thus validating them in a controlled manner.
This last point is the icing on the cake. Just as technology areas fear causing disruptions in system evolution, so do business areas. Conducting controlled A/B tests empowers the organization to make controlled mistakes and, in the process, seek the adjustments that will enhance efficiency and competitiveness.
Many argue that implementing these systems is challenging because it involves detailed mapping of current rules, and then configuring these rules within the decision engine. It's true, but it's also true that companies learn a lot during this process and already reap direct benefits from this exercise.
Some say these rules are core to the company and shouldn't be placed in a third-party system. Here, I draw an analogy to ERPs or CRMs. Are the rules truly more core than the company's customers or finances?
Follow the discussion on Linkedin
Comments