I was recently asked by a client, “What is a litmus test when identifying components for Decision Management?” This was a great question that unfortunately is all too often not considered during Decision Management projects. Using criteria to determine suitable decisions is needed in order to effectively implement Decision Management. This post will provide the main characteristics to identify suitable candidates for Decision Management components during the Decision Discovery phase of a Decision Management project. Decision Discovery is the initial phase of a Decision Management project that involves identifying decisions, designing the decisions, and then modeling the decisions.
Organizations make numerous types of decisions as part of their day to day operations, yet not all these decisions are suitable for Decision Management. It is important to understand the characteristics of suitable decisions in order to streamline critical decision making processes. The Decision Discovery process begins with Identifying the Business Decisions that need to be automated. The following are specific characteristics which can help guide you in identifying suitable decisions: repeatable, non-trivial, and measurable business impact.
Operation decisions are repeatable. This is the most important characteristic of a business decision. By nature, operational decisions occur repetitively, for each customer or each product. For example, the same eligibility criteria is applied whenever a person applies for an insurance benefit. If the decision is not repeatable it does not provide value to automate it within Decision Management. The following are some questions you can ask when determining if a decision is repeatable:
- Does the operational decision occur within a defined time? Most organizations have already defined a point in time when a decision needs to occur in the context of a business process. For example, a loan application needs to be analyzed to detect fraud prior to the next step of being evaluated for regulatory compliance. If it is possible to say when the decision occurs, it can be considered repeatable.
- Does the operational decision contain a consistent set of information? In order to understand what information is used to make the decision, it should contain a consistent set of information between decisions. To answer this question, you must identify which set of information is used to determine the outcome of the decision. For example, on an insurance application, you always need to know information about the applicants’ age, gender, driving record, previous claims, and credit information. These are identifiable, fixed sets of information that is required from each applicant in order to make a decision on whether or not to provide an insurance benefit.
- Does the operational decision produce predictable outcomes? Using the same insurance application example, an insurance organization would be determining whether or not the application meets their criteria for a person to receive benefits and how much to quote for a premium. The outcomes are predictable and can be measured for success over time.
Operational Decisions are non-trivial. The second characteristic of suitable business decisions is whether or not the decision is complex. If the operational decisions are trivial or straight forward they can be easily maintained in application code. The typical type of decisions which are considered complex are government regulations, compliance policies, risk assessment of large sets of data or decisions which require a deep understanding of domain knowledge. In certain circumstances, the decisions may be straight forward but may need to be updated often, which results in them being given the distinction of non-trivial. Building automated business decisions around complex human tasks or business processes which require frequent updates will result in a high return on investment (ROI).
Operational Decisions have measurable business impact. Suitable business decisions need to have definitive and measurable business impact. One must define the business motivations and goals as part of the Decision Discovery. If an organization wishes to measure success in terms of improving customer retention or reduce overall lending portfolio risk, the Decision Management implementation can focus on replacing decision components on legacy systems or identify appropriate decisions which make them more agile in achieving these goals. Measuring the impact of single operational decisions might be inconsequential, however, when decisions are analyzed collectively over a period of time, they represent a significant impact to the business. It is recommended to begin by selecting operational decisions which have the biggest impact to the business.
The operational decisions should be candidates for automation. In order for a decision to be a candidate for automation, the business should not believe it relies on human judgment. There is no value in automating a decision if the business does not believe it is necessary, resulting in unuse. If human judgment is being used to determine a decision based on guideline or regulation, these are typically good candidates for decision automation. Some examples of candidates for automation are eligibility operational decisions that determine if a person is eligible for a product or service. Validation operational decisions are decisions which enforce policies or risk assessment which determine how risky a customer or transaction are. However, if the organization believes the decision requires human judgment, then it is not a good candidate for automation.
So one may wonder, how can suitable business decisions be found for determining these characteristics? This can be done by analyzing business processes for key words such as “Determine”, “Decide”, “Compute”, “Validate”, “Assess”, and “Select”. Another method is to analyze legacy systems. The decisions can be buried deep in code and may not be easily identifiable as business decisions. But decision components can be identified by how frequently they change. It is highly likely that these are candidates for automated decisions, especially when there are regular change requests. You can also look for legacy code that is implemented in a table-driven approach. Table-driven or parameterized approach in which logic is implemented in table format was previously used as a way to make code more flexible and easier to change when developing legacy systems. This may provide flexibility, but not to the extent of Decision Management. The business is still dependent on IT resources and delivery schedule and at times may have a large number of change requests impacting the ability of the business to respond to changing market conditions. Decision Management eliminates this dependency.
Once the decisions have been identified they need to be documented and modeled. More details will be provided on these steps in my next post.
At Perficient we recommend that our clients attempt to identify an ROI and a quick win candidate for the business. Clients are guided to should focus on a specific area of the business and develop high ROI decisions to prove the approach and to provide immediate value. Using the Agile Development methodology, you can incrementally develop decision services over time. This provides execution transparency into the policies driving business decisions as a result of the logic being published outside application code. As a result, the business is flexible and able to respond quickly to rapidly changing market conditions.
References:
Decision Requirements Modeling for Business Rules Projects [White Paper], Decision Management Solutions
Business Rule Concepts [Kindle Edition], Ronald G. Ross (Author)
Writing Effective Business Rules [Kindle Edition], Graham Witt (Author)
Demonstrating the value that can be derieved from using Policy and Rules [developerWorks Technical Library] Maryann Hondo (Author), Jerome Boyer (Author), Andy Ritchie (Author)
