Case Management
Technical Series: Decision Management Platform Integrations
Decision Management and Business Rules Management platforms cater to the needs of business oriented roles (business analysts, business owners, etc.) involved in operational decisions. But they also need to take into account the constraints of the enterprise and its technology environment.
Among those constraints are the ones that involve integrations. This is the first series of posts exploring the requirements, approaches and trade-offs for decision management platform integrations with the enterprise eco-system.
Why integrate?
Operational decisions do not exist in a vacuum. They
- are embedded in other systems, applications or business processes
- provide operational decisions that other systems carry out
- are core contributors to the business performance of automated systems
- are critical contributors to the business operations and must be under tight control
- must remain compliant, traced and observed
- yet must remain flexible for business-oriented roles to make frequent changes to them
Each and every one of these aspects involves more than just the decision management platform. Furthermore, more than one enterprise system provides across-application support for these. Enterprises want to use such systems because they reduce the cost and risk involved in managing applications.
For example, authentication across multiple applications is generally centralized to allow for a single point of control on who has access to them. Otherwise, each application implements its own and managing costs and risk skyrocket.
In particular, decision management platforms end up being a core part of the enterprise applications, frequently as core as databases. It may be easy and acceptable to use disconnected tools to generate reports, or write documents; but it rarely is acceptable to not manage part of core systems. In effect, there is little point in offering capabilities which cannot cleanly fit into the management processes for the enterprise; the gain made by giving business roles control of the logic is negated by the cost and risk in operating the platform.
In our customer base, most do pay attention to integrations. Which integrations are involved, and with which intensity, depends on the customer. However, it is important to realize that the success of a decision management platform for an enterprise also hinges on the quality of its integrations to its systems.
Which integrations matter?
We can group the usual integrations for decision management platforms in the following groups:
- Authentication and Access Control
- Implementation Support
- Management Audit
- Life-cycle management
- Execution
- Execution Audit
- Business Performance Tracking
Authentication and access control integrations are about managing which user has access to the platform, and, beyond that, to which functionality within the platform.
Implementation support integrations are those that facilitate the identification, implementation, testing and optimization of decisions within the platform: import/export, access to data, etc.
Management audit integrations enable enterprise systems to track who has carried out which operations and when within the platform.
Life-cycle management integrations are those that support the automated or manual transitioning of decisions through their cycles: from inception to implementation and up to production and retirement.
Similarly, execution integrations enable the deployment of executable decisions within the context of the enterprise operational systems: business process platforms, micro-services platforms, event systems, etc. Frequently, these integrations also involve logging or audit systems.
Finally, performance tracking integrations are about using the enterprise reporting environment to get a business-level view of how well the decisions perform.
Typically, different types of integrations interest different roles within the enterprise. The security and risk management groups will worry about authentication, access control and audit. The IT organization will pay attention to life-cycle management and execution. Business groups will mostly focus on implementation support and performance tracking.
The upcoming series of blog posts will focus on these various integrations: their requirements, their scope, their challenges and how to approach them.
In the meantime, you can read the relevant posts in the “Best Practices” series:
Part 3: Decision Management and Case Management
In Part 1 of this series, we reviewed how decision management, decision analytics and case management combine in systems that support automated decisions. In Part 2, we explored how modern decision management can help case workers accelerate their daily work, while at the same time allowing the organization to progressively capture the knowledge they use.
Decision Management Support for Investigative Case Management
Investigative case management can be significantly helped by the strong decision analytics included in modern decision management solutions.
Typically, an investigative case manager will use a variety of tools to analyze the decisions and their outcomes, focusing in particular on those that led to cases being processed through case management. During this analysis, the key objective is to identify the reasons why processing the case manually was required, and to find changes to the automated decision so that the manual case management can be eliminated or reduced.
A modern decision management tool such as SMARTS has built-in capabilities to help facilitate this search:
- Traceability understandable by an investigator of what the decision logic is that led to the generation of a case to work on. We saw this in the previous part (add link), since it also helps the operational case worker.
- Ability to leverage built-in decision analytics in order to identify patterns in the data and the way the decision logic leverage it leading to too many cases being created, using business level metrics, simulation and predictive analytics capabilities.
For example, the investigator may build reports that track different risk assessment measures:
and relate the decision made to business outcomes:
- Ability for an investigator to modify the decision logic without modifying the currently deployed one in order to run experiments, potentially in champion-challenger mode to test alternatives to the current decision logic. For example, the investigator might have used the decision analytics and predictive analytics capabilities highlighted before to create a couple of alternative ways of managing the decision. Using the built-in Experimental Design capability in SMARTS, he can test the current implementation (champion) against the two alternatives (challenger) and measure the business effectiveness through multiple KPIs and reports.
These capabilities extend the reach of what the investigator can do – going further than simply pin pointing correlations and letting others do the exploration in terms of the business logic.
Why Decision Management Should Be Part of Your Case Management Strategy
Making SMARTS fully part of your case management strategy in addition to your decision management strategy allows you to have very strong support for both your operational case workers and your investigators, and efficiently manage your decisions so as to keep your case load as reduced as possible without losing flexibility. You may even combine it with your adaptive case management support, making it very easy for you to keep track of the core expertise those systems allow you to put in operation while processing cases.
If you are interested in knowing more about Sparkling Logic SMARTS, contact us, or request a free SMARTS evaluation.
Part 2: Decision Management and Case Management
In Part 1 of this series, we reviewed how decision management, decision analytics and case management combine in systems that support automated decisions.
Aspects of Case Management: Operational and Investigative
Case management has two key aspects to it:
- Working on cases the automated system could not process or reportedly did not process well (operational or intervention case management)
- Investigate sets of such cases in order to identify how the automated decision could be changed to do a better job and reduce the load on the more expensive case management (investigation case management)
While the distinction may appear arbitrary and there are situations in which the case worker will straddle across both worlds, we can still separate the two aspects for the purpose of this discussion.
In this part, we’ll focus on the first of these aspects. Typically, case workers will be involved for various reasons – for example
- Handling cases where the data is incomplete
- Handling cases which present too much risk for the automated system to take the final decision, but present enough potential for them to be considered by humans, as is the case in a number of loan origination situations
- Handling cases which require interactions with human customers to get to a conclusion on the decision, as is for example the case in credit card transaction fraud in which a call may settle the decision on whether to authorize or not a transaction
Responsibilities of Operational Case Workers
Operational or intervention case workers tend to work with a case at a time, and to review the specifics of the case using forms. They review the case in the representation, and based on their expertise and their hunches will:
- Try to understand why the automated system did not take a decision or why the decision was reportedly incorrect
- Decide what the next step in the processing of the case should be (ask for more information, take a decision for the case, etc)
Decision Management to the Rescue of Case Workers
Decision analytics and modern decision management user interfaces can help.
SMARTS offers the RedPen™ approach to managing decisions. This approach presents the decision information in the context of cases and groups of cases, and lets the case worker interact with decisions within the forms that they are used to in everyday work.
What’s more, SMARTS allows case workers, in order to get support and to track the reasons for which decisions are overridden and/or modified, to use the same system as the business users managing automated decisions.
In the following SMARTS screen in RedPen mode, the case worker looking at the current case (1/100 in Census 2000) immediately understands the reasons for the automated decision (“High Risk” rule fired because “AverageAge” is between 16 and 25 and set the “Assigned Risk Level” to “High Risk”).
Furthermore, the case worker can use the same tool in order to explore how to propose a modification to the decision logic in order to take care of the case being worked on. For example, the case worker can decide that even though the average age is quite young, the total work/school mileage is below 50 miles and that the organization should grant a lower risk level. The case worker can do that by directly manipulating the decision within the tool, creating an exception rule to the “High Risk” rule and changing the conclusions for the cases where, in addition to AverageAge being in the specified range, the corresponding mileage is below 50 miles.
The exception rule thus created may then be fed back to the automated decision, shared with other case workers who can continue refining it. And they can do that with full understanding of the consequences on the various groups of cases and business performance objectives. This is a great example of “design by doing” and adaptive case management.
This approach allows case workers to benefit from the systematic capture of decisions within the system, yet gives them the flexibility to adapt the logic to the situations they are dealing with. It also allows the organization to capture in a systematic way this highly valuable information which otherwise gets lost or is not efficiently communicated.
It is not even required that the case worker actually configure the logic – just highlighting the reasons why the decision needs to be adjusted for this case is valuable information that can be tracked in the decision management tool in order to further improve the decision.
If you are interested in knowing more about Sparkling Logic SMARTS, contact us, or request a free evaluation of SMARTS Decision Manager.
Part 1: Decision Management and Case Management
Risk and Configuration at the Core of all Business Decisions
Most business decisions that are worth automating involve a combination of two key aspects, in various forms and under various names, but that boil down to risk and complex configuration. Take a loan application:
- The loan product is complex to configure, must take into account your business procedures, legal compliance requirements, customer desires, your competitive landscape, etc…
- You are also taking risks every time you originate a loan: a risk the loan is not paid back, the payment schedule is not respected, the interest rates vary significantly, etc… The risk is both on a per-loan, and on a per loan portfolio basis.
This is of course obvious, but most decisions actually do present the same two key aspects, be it in Financial Services, Healthcare, Marketing and Advertising, or other industries. It is thus not surprising that decision management solutions are applied to these problems.
Role of Decision Management, Decision Analytics, and Case Management
One important aspect of these decisions is that the systems that support them tend to combine a number of key architecture pieces: decision management, decision analytics and case management.
- Decision management is used to capture, test, optimize and manage the decisions to be rendered automatically,
- Decision analytics is used to measure the actual business performance of the decision being rendered automatically,
- and Case management is used to both take care of the case that the automated decision cannot take care of automatically (operational case management), and to investigate the reasons behind that failure (investigative case management).
Case management (operational and/or investigative) are present in one or another form, and they are particularly prevalent in systems that support decisions involving money transfer or healthcare impacting decisions.
The Importance of Decision Analytics
We have talked elsewhere in this blog (see From Decision Management to Prescriptive Analytics and Improve Your Automated Decisions with Decision Simulation) on how it is essential to have decision analytics included as part of any decision management solution. The previous generation of BRMS and predictive analytics tools fails at this by narrowly focusing on just the capture of expertise from experts or data, and (sometimes) its automation but not the management of its business quality. Next generation decision management tools, led by ours, SMARTS Decision Manager, make decision analytics core to the approach.
What is less obvious is that combining decision analytics and innovative expertise capture approaches, decision management can help provide a significant enhancement to traditional case management approaches by both assisting the case workers, and efficiently capturing the expertise applied by the case workers. That will be the subject of the next installment of our series.