Operational decisions are specific business decisions made every day within every business. There are millions of these taken – and thousands of different types. Every day business uses operational decisions to run day-to-day activities by different personnel. Not a day goes by without these types of decision being made in every business.
By definition, a decision means “a conclusion or resolution reached after consideration. The action or process of deciding something or of resolving a question”.
As evidenced here, a decision has both a conclusion (result or answer) and also a method of deciding or processing, which we call the decision logic. Operational decisions are no exception to this definition. Yet there are distinct differences between operational decisions and other types of decisions (i.e., strategical and tactical) that make operational decisions ideal candidates for automation.
Here are some examples of operational decisions in the day-to-day operations of a business:
- How much tax should this customer pay?
- What are the products or services that can be offered to a customer?
- Is this transaction likely to be fraudulent?
- How do we handle exceptions in this claim process?
- Are we compliant with state regulations?
Characteristics of Operational Decisions
Operational decisions are mostly structured and are typically repeated many times every day. These operational decisions can be modeled once and then reused and executed multiple times against thousands or millions of records and transactions. For example, the calculation of a tax for a portfolio of investments, or the calculation of a bill for a patient in a hospital.
An operational decision structure may be illustrated as shown below:
Operational decisions’ conclusion can be different results or actions. The conclusion can be a simple value, list, or an action that enforces a guideline.
- They can provide a calculation. For example, the billing calculation of a customer in a telecom industry.
- They can provide options. For example, the list of available treatment for a patient.
- They can create configurations. For example, the correct configuration of MRI equipment in a leasing process.
- They can offer product bundling. For example, the best options and price for up selling and product bundling.
- They can provide guidelines. For example, the right criteria of a specific procedure for a patient in a particular situation.
- They can provide judgement. For example, whether or not a pharmacist is certified to work in a pharmacy.
- They can guide a customer journey. For example, what is the best next action for students in achieving a specific goal.
- and more…
As shown here, all of these decisions require an input to describe parameters, situation and a case. Then the decision logic is run against the situation and produces a result.
The effectiveness and efficiency of these operational decisions are critical to the success of business in a rapidly changing and competitive environment. Yet the details of the decision and the decision logic are often “hidden” within the organization.
Perhaps these are also hidden within the heads of experienced employees or buried deep within applications and automated processes.
Automation of Operational Decisions
While automation helps organisations to ensure the effectiveness and efficiency of operational decisions, companies often try to automate these using traditional approaches, such as building applications using code, iBPMS and other technologies. Companies use codes and low-code platforms to build applications and automate operational decisions. Companies have also been using Excel (and other spreadsheet applications) to help operators in complex calculation. And they have been using other business-oriented solutions such as business rules management systems (BRMS), decision management solutions (DMS) and business process management (BPM) in many cases to build the automation for operational decisions.
So, what’s wrong with these traditional approaches?
In the traditional approach of automating operational decisions (explained above), whether through applications or traditional iBPMS (a more advanced flavor of BPM), all of these operational decisions are buried in process or code. When these are confronted with the required frequency of change and volume of data, it becomes critical to manage them independently. Otherwise, it makes it really hard to understand the decisions, much less understand how to use and apply them. The problem with that is simply that organisations cannot keep pace.
Also, as shown in the illustrated formula for operational decisions, these rely on data and have an action and/or judgment associated with them. Over time, the data, integration and circumstances driving different decisions changes for various situations. The actions taken mature over time based on the results of these operational decisions, as well as the decision logic itself. When automation of operational decisions is key to the success of business, hiding decisions, data and required actions within processes and applications makes it very difficult for business to keep pace. It stretches the boundaries of technology platforms and business practices, and leads to less effective results.
Today, when companies have complex operational decisions, they simply cannot scale with traditional approaches. Some have even tried to use any one of many decision management platforms to plug into data and processes. However, that approach creates a disconnected decision experience that often becomes unmanageable in complex and changing situations. That’s where we need to take another approach. The impact of the disconnected decision experience is that it puts organisations back into the first place when there is a need to balance the control between IT and business, which in turn leads organisations to implement these types of solutions in the first place.
We are going to talk more about this disconnected decision experience in future posts.
Last updated January 13th, 2020 at 06:49 am, Published April 15th, 2019 at 06:49 am