Introducing Decision Services

white paper

Introducing Decision Services

Smarter, More Agile Business Processes and Composite Applications Require Advanced Decision Services

Automated processes and self-service applications cannot always wait for your staff

to be available to make decisions. Yet the decisions about risk or about customer

treatment drive the results your customers and partners see when they interact

with those processes and applications. As companies migrate to a service-oriented

approach, and think about their end-to-end processes, the question of how to

automate decisions becomes critical—especially in high-volume, day-to-day processes.

Not only must these decisions be made quickly and accurately, they must recognize

the organization’s need for agility, a readiness and ability to respond quickly to

changing business conditions. As more and more companies adopt business process

management systems (BPMS) and Service-Oriented Architecture (SOA), the role

of business rules and of business rules management systems (BRMS) needs to be

examined and clarified.

This paper will outline why Decision Services matter, why a business rules approach

should be used to build Decision Services and why Decision Services should be

considered alongside business processes.

February 2010 » Summary

www.fico.com Make every decision countTM

© 2011 Fair Isaac Corporation. All rights reserved. page 2


table of contents

» Introducing Decision Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Characteristics of Decision Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Operational Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Implementing Decision Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

» Benefits of Decision Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

» Separating Decisions from Business Processes . . . . . . . . . . . . . . . . . . 8Moving to “Intelligent” Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

» Changing the Rules of Software Development . . . . . . . . . . . . . . . . . 12Composite Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Commoditization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Complex Event Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Legacy Modernization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Transitioning to an SOA-Based Environment . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Building for the Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

» Some Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15A BusIness Process Needs a Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

A Decision Requires Extra Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

A Decision Causes a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

An Example of BPMS and BRMS Integration: Marine Vessel Underwriting . . . . . . . . .18

» Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

» About FICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



It is increasingly unacceptable for decision-making in high-volume business processes or transactional systems to be manual. Processes cannot be put on hold until someone checks a work list; real-time transactions require sub-second responses and straight through processing requires transactions “untouched” by human hand. Increasingly, companies are using business process management systems (BPMS) to define, manage and execute business processes. While traditional applications might be orchestrated to do this, the use of component services is increasingly common. Services and a Service-Oriented Architecture (SOA) are the building blocks for modern processes and systems. Decision Services are the services that replace manual decision making in these processes.

Decision Services, then, are services in your Service-Oriented Architecture that automate and manage the highly targeted decisions that are part of your organization’s day-to-day operations. Decision Services “answer” business questions for other services, applications or processes. Many of the services you need to deliver the benefits of SOA need to be dynamic, configurable, platform-independent and easy to evolve as business needs change. These are likely to be Decision Services.

Characteristics of Decision ServicesA Decision Service demonstrates a number of characteristics in addition to those of any well-behaved service. In particular, a Decision Service:

• Executes behavior that is understandable to the business—The business should be able to verify exactly what is going on inside.

• Supports rapid iteration without disruption—Business decisions change all the time, so a Decision Service has to be both flexible and designed for this change.

• Integrates historical data—Business decisions are increasingly made “by the numbers” with much reference to historical data. Decision Services need a similar ability to use historical data and trends/insight extrapolated from it.

• Expects multi-channel use—Decisions must be consistent across all your channels so very different kinds of applications will use the service—everything from ATMs and SmartPhones to Call Center applications and Bill Printing.

• Manages exceptions well—Not only should it respond sensibly when it cannot decide, it should ensure that enough context is returned as to why it could not decide to assist a manual process.

• Explains its execution and is transparent—Many decisions must demonstrate compliance or conformance with policy. Any Decision Service must be able to log exactly how it decided, and that information must be accessible to non-technical users.

• Can be analyzed—The results of executing the Decision Service, the decision outcomes, can be monitored and analyzed separately from the process(es) it supports.

Operational DecisionsNot every decision is suitable for automation as a Decision Service. In general, decisions that are high volume, that must be performed in very short time windows, or that are repeatable but of moderate complexity are the best candidates. These operational decisions are common in the day-to-day processes that drive your business. You can find them by considering process definitions or use cases and looking for steps that use words like determine, validate, evaluate, calculate, review, recommend, check, identify and so on. Here are some examples from various industries:

» Introducing Decision Services



• An auto policy underwriting service that combines pricing rules and risk models to underwrite policies

• A cross-sell offer service that combines segmentation rules and response models to generate the best cross-sell offer across channels

• A fraud detection service that uses rules and a neural net to identify fraudulent credit card transactions

• A shipment routing service that routes shipments to customers based on demand, contracts and status

• A claims payment service that uses rules to check a claim for authorization to pay while also applying analytics to detect potential fraud

• An eligibility service that allows citizens to check their eligibility for benefits and applies state and federal rules appropriately

• A return authorization service that tells front-line retail staff whether a particular customer can make a particular return using return rules, purchase history and future revenue potential

Implementing Decision ServicesThe adoption of a Service-Oriented Architecture (SOA) provides businesses with the ability to rapidly deploy new applications and easily integrate with other component applications both inside and outside the organization. This decentralized application environment provides a great deal of flexibility for business units and IT departments, but it also creates difficulty in managing the consistency of business decisions delivered through various applications. While the use of coherent Decision Services goes a long way to addressing these issues, a business rules management system (BRMS) provides a mechanism for managing decision logic across Decision Services and acts as a conductor in order to align application decision behavior.

FIGURE 1: A DECISION SERVICE ARCHITECTURE

A Decision Service can help organize and improve consistency within a decentralized application environment. However, as this chart shows, a business rules management system further improves a decentralized environment with better management of decision logic across Decision Services.

BusinessIntelligence

Decision ServiceProcess Data, Rules

and Analytics toDetermine Best Decision

Analytic Development

Rules Management

DM Repository

ERP

CRM

Core Banking

Billing

Supply Chain

E-Business

OPERATIONALSYSTEMS

Customer Behavior and Strategy Performance

DecisionRequest

Decision

Data Warehouse

Marketing

Originations

CustomerManagement

Collectionand Recovery

Fraud

Transaction ExecutionDevelopment

and Management

DECISIONAPPLICATIONS



The key to a BRMS is the use of a centralized repository, within which resides the decision or business logic needed by all the applications. Instead of having this logic embedded as code, applications communicate with a Decision Service that processes those business rules specific to the decision required for the particular application and situational context.

Business rules management systems define business decision logic as rules, and these rules are stored in the rule repository. Using the BRMS rule development environment, individual rules are then combined into rulesets—functional blocks defining decision logic for a subtask. Rulesets can be combined in a procedural decision flow (ruleflow) to conditionally use the assigned rulesets in a sequence that achieves a desired business decision. This combination of ruleflows, rulesets and individual rules are utilized within rule-based services (Decision Services) that are used to guide the decision logic for a specific business process. Decision Services use the BRMS rule engine to process the inputs from operational systems or other services through rules and analytic models as required in order to return the optimal decision output back to the client application.

FIGURE 2: BUSINESS RULES MANAGEMENT SYSTEMS

Powerful Authoring Tools

StructuredRepository

DeploymentFacilities

RuleRepository

MultipleRules Engines

Java /J2EE .NET MainframeUSS / COBOL

Deployment Manager

This chart illustrates the components of the FICO™ Blaze Advisor® business rules management system. As in the Blaze Advisor system, business rules management utilizes a combination of ruleflows, rulesets and individual rules within rule-based Decision Services to guide the decision logic for a specific business process.

Recent Honors for FICO and FICO™ Blaze Advisor®• Best Business Rules Management

System for 2008—InfoWorld

• Best Business Rules-Based Decision Management for 2008—Yphise

• 2008 Innovative Implementation Award—ACORD



The differentiation between individual rules, rulesets, ruleflows and Decision Services provides the highest level of flexibility in the reuse and sharing of decision logic. As the functionality across each service is different, so too is each service’s use of rules. Several services may require a common rule, but each may have its own unique set of related rules or decision steps that need to be associated with that specific rule. Allowing this reuse of rules across services can speed their development and reduce the cost of maintenance above and beyond the improvements that come from a service orientation.

Decision Services offer a number of benefits to an organization in the areas of precision, consistency and agility. There is also a cultural component to managing Decision Services in this way. By recognizing and separating out operational decisions, you can focus your business thinking and investment on these decisions more easily. You can apply your strategic vision and proper management approaches to drive toward optimal operational decisions.

PrecisionHaving a decision in a single Decision Service makes it easier for you to improve that decision over time. You can apply predictive analytics, for instance, to the decision-making process you are automating so as to make the decision more precise. Indeed, with experience, you can apply more advanced analytics and consider the mathematical relationships between business objectives, actions, customer reactions, constraints and outcomes. This lets you take market and economic uncertainties into account and arrive at optimal decision strategies quickly while still isolating any needed changes to a single service or component. Your ROI on improvements is also higher—improvements in the decision improve results in all the applications that use the Decision Service.

ConsistencyA Decision Service isolates the logic behind business decisions, separating it from business processes and the mechanical operations of procedural application code. Treating decision logic as a manageable enterprise resource in this way means you can reuse it across multiple applications in many different operational environments. A centralized approach to decision automation can also eliminate the time, cost and technical risk of trying to reprogram multiple individual systems simultaneously to keep up with changing business requirements. For instance, the rules for pricing a product can be removed from the definition of the order processing business process. These rules can be managed independently, which is important because the pricing change cycle is different from the business cycle that drives process change. They can also be reused, for instance, to help customers understand what they will pay or to support call center agents.

AgilityIn business, being agile means that an organization has the ability to not only sense environmental change, but also has the capabilities and processes in place to efficiently and effectively respond to that change, as well as to unexpected changes. This is important for organizations wishing to stay innovative and competitive in a quickly changing, competitive business environment. In a traditional approach, any change to logic in an application must be described by line of business experts, fed into a development process and then implemented in all the systems or processes that require that change. In contrast, as Figure 3 shows, a separate Decision Service allows business owners to make their frequent changes directly and to a single point in the architecture.

» Benefits of Decision Services



When we think about how a business might respond to changes, we can define two kinds of response—changing a process or changing how a decision is made within a standard process. Let’s consider each of these in turn.

Some kinds of change require a change to a process in response. For instance, if a particular locality introduces regulations into a previously unregulated process, a compliance step might need to be added. If a new call center is opened to handle a particular class of customers, then a new branch and new steps will need to be added to the processes to handle customer interactions.

When core processes, such as order to cash, are changed, there is typically a significant impact on the organization as a whole. The changed process and the changed definitions in a BPMS are unlikely to be all there is to it. Organizational change, and perhaps new auditing, will likely be required. This kind of change is hard to make agile and will always be fairly time consuming.

Processes around the “edge” of a company with lower volumes, less repeatability and more manual steps do need to be easy to change as they are likely to change often. How calls are handled from very large customers, for instance, might be entirely defined by a custom contract that requires a distinct process.

FIGURE 3: KEEPING DECISIONING RULES IN SYNC WITH MARKET CHANGE

A Decision Service allows business experts to make frequent changes across applications, and they can make changes directly and to a single point in the architecture. This is important for businesses that need the agility to make changes—especially unexpected changes—in the business environment.

CRMsystem

Business rules“woven in”

Integrated rulesavailable to all systems

Decision Service

CRMsystem

Conventional Approach Decision Management

Other customer-facingsystems with own rules

Other customer-facingsystems with own rules

Frequent code changes

Process repeated(times x)

Frequent code changes

Policy changes

Multiple review and revision cycles asbusiness logic is translated into programming logic

Frequent policy changes implemented quicklyand easily by those closest to the market



Decision agility is needed when change is required within a process, but the process itself does not change. For instance, if a change is made to the rules for determining price discount eligibility, the process will likely not change at all—at the same point in the process, the discount will be determined and applied. Yet the decision as to what discount to offer will change. Being able to quickly change the decisions within a process, with or without a matching process change, is key to decision agility. This tends to matter most in core business processes that, while they are fairly stable in terms of steps and outcomes, can have significant variation in decision making over time.

Both process agility and decision agility are required, and they often appear together. Clearly, if a new sub-process is added to handle a new class of customers, it will likely also change the decision logic for segmenting customers to put the right customers into this new sub-process. Changing the way risk management decisions are handled might create new needs for external verification or reports, which will need their own processes. Not all decision changes require process changes, but it is common for process changes to impact a decision. Only manual processes in which everything is handled by people and worklists are likely to be exceptions.

One of the most common errors made when organizations are considering the use of business process management software and approaches is that of failing to separate decisions from processes. To use Decision Services effectively, it is essential to understand this difference.

At a fundamental level, business processes and business decisions are different things. Business processes are about how something, once decided, should be carried out, while decisions are about what should be done, and what should be decided. Process Management, and the BPMS that support it, and Decision Management, and the BRMS that support it, are likewise different.

The use of the word “decision” sometimes causes problems as there are at least three different kinds of decisions within a process: business decisions, processing/routing decisions and decisions about responding to events. In general, business decisions are what a BRMS focuses on, and most, if not all, business decisions within a process should be managed with one. Business decisions would not change if you completely re-architected your processes, and these are what you should manage as Decision Services. Routing decisions are the “rules” executed by a BPMS, e.g., to decide which branch to take in a flow. These are not “true” business decisions as they are dependent on the implementation of the process.

» Separating Decisions from Business Processes

BRMS and Decision ManagementBPMS and Process Management

Facilitate decision automation and maintenance

Business rules definition and management

Centralized business rules repository

Decision broker

Replaces manual decision making

Standardize decision making—What should the decision be based on?

Standardize processes—How should a process be carried out?

Facilitate collaboration and compliance

Process automation around decision making

Activity monitoring and exception alerts

Process reports

Integration broker

Workflow definition and management



Lastly there are the decisions involved in business activity monitoring, or BAM. Some of these are very processing- or system-centric and should be implemented in the BPMS or a related BAM product. Others represent real business decisions, or rely on business decisions, and the logic for these should be kept in a BRMS.

So if it is clear that there should be both BRMS functionality and BPMS functionality to manage rules and processes effectively, why not try to get both kinds of functionality in the same environment? What value is there in having separate, but linked, products to fulfill this? There are three core value propositions in keeping them separate: being able to change the rules for work in process, being able to reuse rules across systems and having the inherent nature of business rules as distinct from process or routing rules.

1 . Having the ability to change work in progress—Business logic within a process is typically fixed by the BPMS for a particular item of work at the time that it is instantiated. For long-running processes, this is a problem, as rules may not be current when they are evaluated. If the rules are retrieved from a BRMS at the time a decision is needed, then the rules are current, whereas if the business logic is embedded within the process map, then typically that logic is fixed for a particular item of work at the time that it is instantiated. In theory, a product that combined BPMS and BRMS functionality could allow this kind of separation, but in reality, it is going to be easier to manage with separate products focused on solving unique deployment and re-deployment issues.

2 . Using the same rules engine and rules across multiple applications—The same business rules, for example, about how you deal with a customer’s order in a particular situation should be applied identically across your CRM system, your BPMS and any other applications that they might impact. This is important for customer service—customers like to be treated consistently—but critical for compliance, where you must be able to show consistency of behavior. If a particular customer segment used a particular system more heavily, inconsistent treatment across systems could even leave you accused of bias. If all these systems retrieve their business rules from a common business rules repository at the time of execution, you get consistency, compliance and greater business agility. This is particularly true for those companies that need more than one flavor of BPMS for different projects.

3 . Business decisions are not routing decisions—One reason people get confused about having separate technologies is because they confuse routing or process rules with business rules—rules that impact business decisions. Business rules let you automate business decisions such as:

• Complex branching

• Managing task assignments

• Triggering processes

• Eliminating manual approvals

• Identifying potential fraud

• Assembling complex datasets

Not only don’t most BPMS have sufficient functionality in their in-process expression builders to offer true business rules capabilities, but these kinds of decisions are typically process- and technology-independent. You could re-platform your whole business, and the rules would stay the same. These rules are so different from what you need in a process that they should be managed and controlled separately.



There are a number of risks inherent in adopting and implementing a BPMS and in managing processes without considering decisions separately. A recent Gartner report1 talked explicitly about managing policies/rules as an important business resource. Indeed, it went further and said:

“Rules that are encased inside business processes are stealing business opportunities that depend on speed of change.”

The report suggested conducting volatility analysis to find the rules that should be externalized. Decision volatility and reuse should be considered, not just rules. All processes contain decisions that must evolve and change, and decisions are particularly prone to having most of their life be what has been called “change time”—that is time after they are first implemented during which they must evolve. The report states, that rules (decisions) buried in processes, or even worse in legacy applications orchestrated by processes, are not agile. Scenario management—having different decision approaches “on the shelf”—is another advantage of separating out decisions, and this focus on rules/decisions separate from processes also allows personalized customer treatment through transaction or customer-driven processes.

If decisions are not separated out from processes, there are a number of risks:

• Business rules are re-buried into the “new process”—One of the reasons for adopting a business rules approach and a BRMS is to avoid having rules buried in all sorts of code, manuals, people’s heads, etc. Failing to focus on business rules alongside business processes will tend to bury business rules in the first process that requires them, creating a new generation of legacy systems.

• “New process” becomes complex, burdened by the buried business rules—One of the benefits of using a BRMS to manage business decisions is that it can simplify a business process. If you try to use a BPMS to automate a decision, the process will have a large number of steps and paths that are not really about the process but about the decision. This will tend to make the process design more complex and, by failing to consider the two kinds of agility, will make it harder to change either.

• Inconsistency of business rules is likely—If business rules are buried in the first process that uses them, there is a great risk that the next time those same business rules should be used in a process they will instead be repeated. Since business decisions and business rules are not the same as business processes, the reuse mechanisms of a BPMS are unlikely to work as well for business rules. Therefore, hidden business rules will not get reused properly.

• Noncompliance due to problem business rules is likely, leading to fines—Many BPMS projects are designed to improve compliance by managing each step in the process. Compliance with business rules, however, is often more about how a specific decision was made (underwriting, origination, claims payment) and not about the process followed. Using a BPMS to demonstrate compliance with this kind of decision regulation will likely be difficult.

• Without clear decision points, it is hard to apply analytics—While you can use analytics to monitor and improve a process, it is much more effective if analytics can be applied to the decisions within a process. This will prove extremely difficult, if not impossible, if the decisions have not been identified and externalized.

1 Gartner, Inc., When Rules Go Inside Out with BPM, by Jim Sinur, March 30, 2007



All of these issues can be addressed by considering Decision Services, and the business rules that support them, distinct from the business processes that need those decisions made.

Moving to “Intelligent” Processes

“Intelligent process automation is an IDC term that describes the union of business analytics and business process management with a goal of achieving significantly better decision-making capabilities.” 2

Decision Services bring together all the elements needed for “intelligent process automation.” Decision Services make for more intelligent, more agile processes for a number of reasons:

• “New process” is simplified—Because business decisions are identified and managed as discrete elements of the new process, the process will be simpler: it will have a single decision-making activity instead of a cluster of reusable components to make the decision in the process design. This will keep the process simpler and will enable the process to be changed more easily for better process agility.

• Decisions are tied to business objectives and monitored—Decisions as reusable components can be matched to business objectives, source rules, regulations, etc. This allows for impact analysis in the BRMS (if I change this policy, which rulesets should I change?) and for improved control as business users will more readily be able to see which rules are at issue in the face of a specific business change. Although a BPMS offers this for processes, it is unlikely to do a good job for rules.

• Decisions are tied to the “new process” but not buried—Although decisions are tied into the new processes through the decision-making activities, they are not buried in them. This allows them to be reused more readily. A good BRMS will make it easy to see which processes are using which rulesets and to ensure that the processes being impacted by a change in rules can be easily identified.

• Decisions can be tied to other systems not built with the BPMS—Not all applications will be developed using a BPMS. Evidence suggests that no more than about 70% of systems can be brought to a single architecture for any definition of the word “architecture.” This means that business decisions must be made by systems built with the BPMS, as well as by legacy systems and perhaps packaged applications. Indeed with the proliferation of different flavors of BPMS, many companies may find they want to use more than one BPMS. Consistently managing the business rules across the various BPMS in use will be critical.

• Process and decision changes are managed and deployed independently—This last point is perhaps the most important. In general, rules changes (for decision agility) and process changes (for process agility) are not always linked. For example, there could be a long-running process where one of the decision steps must be compliant with changing regulations that will be different from the initiation of the process and the point at which it reaches the decision step. While there are changes that need to be synchronized, as discussed above, the more common situation will be for changes that are not synchronized.

• Analytics can be used to improve the decision—While there is value to using analytics to improve the execution of a process, the ability to apply predictive and decision analytics within a Decision Service, to make the decision more precise, is a key advantage to keeping decisions separate from processes.

2. IDC, Intelligent Process Automation: The Key to Business Process Automation, March, 2007



FIGURE 4: LEVERAGING THE POWER OF ALL YOUR INFORMATION

Multiple technologies and a focus on Decision Services is central to intelligent process automation. This chart shows how Decision Services can leverage the power of various sources of information, and from rules modeling technology.

ModelsRules

Processes supported,and triggered, bydecision services

Offline modeldevelopment

Performance managementdashboards monitor processperformance, events, etc.

Rule management isbased on ongoingmonitoring ofperformance

Events triggerdecision servicesfor processing

DecisionService

ModelDevelopment

DataEventCapture

ProcessExecution

PerformanceManagement

RuleManagement

One point to note when thinking about the combination of BRMS and BPMS: While there is much to gain from using a BPMS to automate a process that has high value each time it is executed but has low execution volume, the combination of BPMS and BRMS is ideal for delivering value in a process with high volume and a smaller potential value each time it is executed. This comes from the ability to automate a far higher percentage of the transactions, with the combination allowing for more straight-through processing, which has great value in high-volume processes.

While the improvement of business processes, and of business process management, is perhaps the most obvious benefit of Decision Services, you can also change the rules of software development in a number of other ways.

Composite ApplicationsA Decision Service can be used to provide a “brain” to your composite applications. Composite applications are an effective way to assemble existing, working functionality to serve a new business purpose. You can put together bought, built or legacy components, and create new applications more quickly. Decision Services, plugged into this approach, allow you to make these composite applications “smarter” and less reliant on people for decision making. Sometimes this will make it easier to connect existing services, and sometimes it will let you take more advantage of the services you have.

» Changing the Rules of Software Development



Performance ManagementThere is a lot of discussion today about performance management and how useful it can be in helping you improve your business by improving your visibility into processes and activities. While there is a lot to be said for performance management, there is an issue for some implementations. Some companies have invested heavily in real-time or near real-time monitoring of their businesses without thinking about the responsiveness of their IT infrastructures. What good does it do to monitor performance and activities so closely if, when that monitoring suggests that a change is needed, you are unable to make your systems reflect that change in a timely fashion? The use of BPMS and BRMS in conjunction can allow for agile systems to be built that will allow an enterprise to respond effectively to what it learns from its performance management systems..

CommoditizationOne interesting use of business rules in a business process context is the potential for business rules to help companies exploit and resist the commoditization of process. As workflow, process management and performance management are standardized or commoditized for a process, it is hard for companies to stand out. If you use these processes, and so do your competitors, how can you still differentiate yourself? You could make sure the business rules that drive the decision points in the process are unique and a match for your corporate perspective/attitude/philosophy. Using a business rules management system, you can inject automated decisioning into the processes as Decision Services, whether you run it, someone else runs it on your behalf or you use a standard one. Not only will this give you efficiency gains by eliminating manual decision-making steps, it will let you easily change the decision policies within your process, to maximize agility, allow for personalization and ensure that your customers still feel they are dealing with you, not a generic enterprise.

Complex Event ProcessingA BPMS is good for predictable processes, while complex event processing or CEP is good for responding to events (business activity monitoring or BAM is another term used here). For either of these approaches, to deliver maximum value and to deliver the rapid-response enterprise of the future, decisions must be automated.

• If you are using BPM to automate a process, and need to automate decision points within it to get straight-through processing, you cannot always refer to a person.

• If you are using CEP or BAM to respond to an event, then you need to decide which events are significant, which are not and what to do about the significant ones; again, you cannot always refer them to a person.

Regardless of what combination of these approaches you use, you must automate decisions. Ideally you should be able to be fairly relaxed about which approach is going to be best for a given project, and just make sure you get control of the decisions that underpin it.

Legacy ModernizationUsing BRMS to modernize a legacy application—to give the old application “a new brain”—is a classic way to reduce costs and improve business agility without having to rip-and-replace the whole system. Decision Services built with a BRMS for this purpose are ideal for being reused in BPMS-designed processes as they typically focus on core business decisions that will be needed in the new processes as well.

This is especially useful in legacy modernization efforts. In many cases, organizations rely on older mainframe systems to handle many crucial business functions, and it just not feasible to



completely replace these systems. Instead, a more practical approach is to slowly transition portions of functionality off of legacy systems, while allowing them to continue to perform their primary processing responsibilities. Removing decision logic from operational application code is a good initial step in legacy modernization efforts. By doing this, legacy systems are actually stabilized, since fewer changes need to be made to the core code over time. Decision logic code is replaced with a simple invocation call to a Decision Service, along with a mechanism for receiving the output from the BRMS. When decision logic (rules) is changed, the legacy system code is unaffected since the changes are made within the BRMS. Core processing functions within legacy systems can then be transitioned to new service-based applications incrementally, and legacy systems can be decommissioned as their functionality is fully replaced by newer systems.

Transitioning to an SOA-Based Environment Implementation of a BRMS is a good first step in moving to an SOA-based environment. In fact, the transition to SOA is not an all-or-none proposition; many organizations start by implementing new applications as services. It is also possible to tie new service-based applications and existing applications together using a BRMS as the common decisioning mechanism. The use of BRMS also allows for faster creation and deployment of new services within a service-oriented architecture. The decoupling of application functionality and decision logic allows developers to focus on core application functionality, while having a separate group of business analysts create the Decision Services needed. The ability to work in parallel on both application development and decision management, along with having developers focus their attention on core application functionality, greatly reduces the time required to bring new services into production. Business rules management tools also allow developers to create interfaces allowing business rules to be maintained by business users. This allows for the customization and evolution of Decision Services in even the most dynamic of environments.

Building for the FutureLastly, a note on how the combination of BRMS and BPMS allows you to build for the future. Let’s assume you have automated critical decisions within a process using business rules, then enhanced these decisions with predictive analytic models. How would this look?

• You could use business rule logging to record the critical decisions within a process instance, allowing you to investigate the realities of process execution.

• You could use rules-based and analytic model-based simulation to see how changes in the rules or models would have changed the outcome of processes. Assuming your key decisions were automated, they would determine the outcome of your process—at least the outcome that impacts the bottom line, such as the price offered or claim amount paid. This would let you evaluate the business impact of changes in policy.

• By making the rules easy to change and by combining them with regularly updated, easy-to-deploy predictive models, you could constantly improve the business process.

• By building a decision model, showing how the rules and analytic models interact, you could run simulations that would let you optimize the process, given the constraints under which you operate.

• You could end up, essentially, with a transaction that drives the process. The data in the transaction, or metadata attached to it, would determine what scores the models would generate, and the combination of scores and data would determine which rules fired. That would decide which steps to take to complete the transaction. This “inverts” the process so that it flows from the customer to the organization. An example of this would be an origination process where the data entered by the customer is used to drive models and rules that determine which products are available and what additional data and steps are required.



This kind of customer-centricity—with flexible processes based on the specifics of each transaction—is the future. BRMS and BPMS used in concert give you the platform. Decision Services are key.

To illustrate how Decision Services might be used, let’s consider a number of use cases:

• A business process reaches a point where it requires a complex automated business decision to be reached before continuing, such as origination, underwriting, fraud detection and marketing. To do this, it calls upon a Decision Service to examine the applicable data and recommend appropriate actions—recommend products/services to offer, decide who needs to be notified of current status, determine what additional data must be collected. The decision data is used by the BPM process to continue its flow.

• A Decision Service reaches a point where additional data is needed in the decision process, requiring human intervention. It initiates a BPM process to bring the right users into the flow and step them through the required tasks. When the BPM process finishes, it re-initiates the Decision Service with a saved state and new data.

• The result of a decision calls for a complex business process to be started. It calls the appropriate BPM process as the rule action, often while continuing execution of the rest of the decision.

We can consider each of these in turn.

A Business Process Needs A Decision1 . A BPMS is executing a business process and reaches a point where it requires a complex

automated business decision to be reached before continuing.

2 . It calls upon the Decision Service to examine the applicable data and recommend appropriate actions:

• Recommend products/services to offer

• Decide who needs to be notified of current status

• Approve or reject

• Determine what additional data must be collected

3 . The decision results are returned to the BPMS and used by the process to correctly navigate its flow.

4 . The BPMS continues with its process execution.

» Some Use Cases



FIGURE 5: RULES AUTOMATE AND SIMPLIFY BPM TASKS

Without rules

With rules

Newhire

Newhire

HumanResources

Incomplete

Resubmit

Allocate employee number

Wait forother tasks

Ready

Inductioncompleted

Wait forfirst day

Supervisor

Inducted

Acknowledged

EmployeestartedDay before

first day HRAssistant

Deadlinewarning

OriginatorWithdrawn

Withdrawn

HumanResources

Wait forfirst day

Withdrawn

Day beforefirst day

Employeestarted

e

eNew

employeeprocessing

Review hire

records

A Decision Requires Extra Information1 . A Decision Service is executing and reaches a point where additional data is needed in the

decision process, requiring human intervention.

2 . It initiates a BPMS process to bring the right users into the flow and step them through the required tasks. This can include:

• Long-running processes

• Waits for external events like inspections

• Human decisions or input managed with worklists

3 . When the BPMS process finishes, it reinitiates the Decision Service with a saved state and new data.

Business process management relies on rules to streamline and improve the process of executing a decision. Rules result in a much more efficient BPM flow, as this hiring example shows.



A Decision Causes A Process1 . A Decision Service is executing a decision.

2 . As a result, a complex business process must be started, either as the end result of the decision or as a side effect of a decision.

3 . The BRMS calls the appropriate BPMS process as the rule action and the process then begins executing under the control of the BPMS.

Data Collection Process

Validate Application Data

Management Analysis Process

Underwriting Decision

Decline Loan

Prequalification Analysis

Decision service initiates BPM Processes

Write Loan Decline LoanException Handling Process

Commercial Loan Origination

FIGURE 6: DECISION SERVICES CAN INVOKE BPM PROCESSES

A Decision Service will prompt a business process management activity for various reasons, such as needing more data for completing a decision, or executing certain actions based on a decision.



An Example of BPMS and BRMS integration: Marine Vessel UnderwritingThis simplified process is designed to show how the two kinds of technology can be used to accomplish the overall tasks of underwriting a vessel.

Objective

Gather customer application

“Kick out” bad applicants

Gather additional data

Validate data

Make underwriting decision

Take underwriting action

Handling exceptions

1

2

3

4

5

6

7

BPMS

Possible manual review

Schedule customer visits Manage collection of forms Worklists for coordination Collaboration between staff

Schedule inspectionsManage worklists for inspectors Track completion of inspections

Manage underwriter worklist to ensure exception handled and invoke any subsequent decisions/processes as appropriate

Decision

Does applicant pre-qualify?

What external data is required?What inspections are required?

Underwrite loan?

What paperwork is required to process loan?What paperwork is required to decline loan?

Why does this need to be referred?

Is application complete?

BRMS

Run prequalification rules (managed by business experts)and identify those that fail. Execute rejection process to send letter explaining with reasons from rule execution.

Execute rules to order third-party data, such as seaworthiness certification, if relevant. Execute rules to identify which physical inspections required. Invoke physical inspection process(es).

Execute analytic models to estimate risk. Execute rules to include risk analysis with portfolio analysis and other decision factors to make underwriting decision.

If can make decision to write loan or decline loan, then do so and invoke relevant paperwork process.

If cannot decide, then flag exceptional circumstances and invoke exception handling.

Validate data items for completeness and proper values. Refer errors for manual review if cannot be resolved.

In today’s day and age, Decision Services are essential for any business that processes large volumes of decisions, and that needs the assurance that their decisions are highly precise in order to drive profitability. Therefore, as more and more businesses evaluate and develop their business process management systems, they need to consider the technologies that will provide the power and agility that deliver the best support automation. Business rules management systems also need to play a large important role in Decision Services within an SOA.

» Conclusion

about FICO

FICO, Blaze Advisor and “Make every decision count” are trademarks or registered trademarks of Fair Isaac Corporation in the United States and in other countries. Other product and company names herein may be trademarks of their respective owners. © 2007-2011 Fair Isaac Corporation. All rights reserved.

2182WP 04/11 PDF

For more information US toll-free International email web +1 888 342 6336 +44 (0) 207 940 8718 [email protected] www.fico.com

FICO (NYSE:FICO) delivers superior predictive analytics solutions that drive smarter decisions. The company’s groundbreaking use of mathematics to predict consumer behavior has transformed entire industries and revolutionized the way risk is managed and products are marketed. FICO’s innova-tive solutions include the FICO® Score—the standard measure of consumer credit risk in the United States—along with industry-leading solutions for managing credit accounts, identifying and minimiz-ing the impact of fraud, and customizing consumer offers with pinpoint accuracy. Most of the world’s top banks, as well as leading insurers, retailers, pharmaceutical companies and government agencies, rely on FICO solutions to accelerate growth, control risk, boost profits and meet regulatory and com-petitive demands. FICO also helps millions of individuals manage their personal credit health through www.myFICO.com. Learn more at www.fico.com. FICO: Make every decision count™.


Introducing Decision Services

Technology

Transcript of Introducing Decision Services